Is it time to remove opensaf?

Is it time to remove opensaf?

[Peter Kjellerstedt]

I am currently working on patches for OE-Core to report QA warnings 
in case some directories that are expected to be empty have some 
files installed into them. As part of the review process, Khem 
reported failures for some recipes in OpenEmbedded due to this, 
opensaf being one of them.

Now I have tried to build and run opensaf in a QEMU image, but I 
cannot get it to work. The sysvinit initscript relies on 
/lib/lsb/init-functions, which AFAICT has not existed since lsb 
was removed from OE-Core two years ago, and opensaf has never 
depended on lsb in the first place. As for systemd, the service 
file uses the same sysvinit scripts so it has the same problem. 
And in addition, the script is in /etc/init.d, which 
systemd.bbclass removes unless both sysvinit and systemd are 
enabled in DISTRO_FEATURES.

And in addition to this, if I just try to start the opensafd binary 
it seg faults immediately.

So all in all, even if opensaf has been updated regularly, it 
doesn't seem like anyone is actually using it. Which brings me to 
my actual question: should I just send a patch to remove it?

Alternatively I can fix the creation of the /var/log/opensaf 
directory, which was the error Khem saw with my patch for OE-Core 
applied, but it seems like wasted work in case no one is actually 
using the recipe...

//Peter

RE: [oe] Is it time to remove opensaf?

[Peter Kjellerstedt]

> -----Original Message-----
> From: akuster808 <akuster808@gmail.com>
> Sent: den 2 november 2021 20:41
> To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; OE Development
> (openembedded-devel@lists.openembedded.org) <openembedded-
> devel@lists.openembedded.org>
> Subject: Re: [oe] Is it time to remove opensaf?
> 
> Peter,
> 
> On 11/2/21 9:33 AM, Peter Kjellerstedt wrote:
> > I am currently working on patches for OE-Core to report QA warnings
> > in case some directories that are expected to be empty have some
> > files installed into them. As part of the review process, Khem
> > reported failures for some recipes in OpenEmbedded due to this,
> > opensaf being one of them.
> >
> > Now I have tried to build and run opensaf in a QEMU image, but I
> > cannot get it to work. The sysvinit initscript relies on
> > /lib/lsb/init-functions, which AFAICT has not existed since lsb
> > was removed from OE-Core two years ago, and opensaf has never
> > depended on lsb in the first place. As for systemd, the service
> > file uses the same sysvinit scripts so it has the same problem.
> > And in addition, the script is in /etc/init.d, which
> > systemd.bbclass removes unless both sysvinit and systemd are
> > enabled in DISTRO_FEATURES.
> >
> > And in addition to this, if I just try to start the opensafd binary
> > it seg faults immediately.
> >
> > So all in all, even if opensaf has been updated regularly, it
> > doesn't seem like anyone is actually using it. Which brings me to
> > my actual question: should I just send a patch to remove it?
> >
> > Alternatively I can fix the creation of the /var/log/opensaf
> > directory, which was the error Khem saw with my patch for OE-Core
> > applied, but it seems like wasted work in case no one is actually
> > using the recipe...
> 
> Thanks for the analysis. Does the current mechanism to blacklist a
> recipe help possible finding users of this recipe?  Is your concern
> carrying this in the next LTS as well?

I guess adding a PNBLACKLIST for it would work too (I have never used 
it, so I did not think off it). My concern was mainly that I had to 
spend time on fixing the recipe to support that /var/volatile is now 
checked for being empty, for a recipe that apparently is broken. So 
if a PNBLACKLIST helps the next person that does changes to the system 
from having to care about the broken opensaf recipe, then that is fine 
with me. ;)

In the end I did send a patch that changes the opensaf recipe to create 
/var/log/opensaf in runtime, by copying the solution for one of the 
other recipes I was fixing. So I am in the clear for my change to 
OE-Core. But opensaf is still as broken as before when it comes to 
actually starting the service...

> -armin
> >
> > //Peter

//Peter

Re: [oe] Is it time to remove opensaf?

[Khem Raj]

On Tue, Nov 2, 2021 at 1:11 PM Peter Kjellerstedt
<peter.kjellerstedt@axis.com> wrote:
>
> > -----Original Message-----
> > From: akuster808 <akuster808@gmail.com>
> > Sent: den 2 november 2021 20:41
> > To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; OE Development
> > (openembedded-devel@lists.openembedded.org) <openembedded-
> > devel@lists.openembedded.org>
> > Subject: Re: [oe] Is it time to remove opensaf?
> >
> > Peter,
> >
> > On 11/2/21 9:33 AM, Peter Kjellerstedt wrote:
> > > I am currently working on patches for OE-Core to report QA warnings
> > > in case some directories that are expected to be empty have some
> > > files installed into them. As part of the review process, Khem
> > > reported failures for some recipes in OpenEmbedded due to this,
> > > opensaf being one of them.
> > >
> > > Now I have tried to build and run opensaf in a QEMU image, but I
> > > cannot get it to work. The sysvinit initscript relies on
> > > /lib/lsb/init-functions, which AFAICT has not existed since lsb
> > > was removed from OE-Core two years ago, and opensaf has never
> > > depended on lsb in the first place. As for systemd, the service
> > > file uses the same sysvinit scripts so it has the same problem.
> > > And in addition, the script is in /etc/init.d, which
> > > systemd.bbclass removes unless both sysvinit and systemd are
> > > enabled in DISTRO_FEATURES.
> > >
> > > And in addition to this, if I just try to start the opensafd binary
> > > it seg faults immediately.
> > >
> > > So all in all, even if opensaf has been updated regularly, it
> > > doesn't seem like anyone is actually using it. Which brings me to
> > > my actual question: should I just send a patch to remove it?
> > >
> > > Alternatively I can fix the creation of the /var/log/opensaf
> > > directory, which was the error Khem saw with my patch for OE-Core
> > > applied, but it seems like wasted work in case no one is actually
> > > using the recipe...
> >
> > Thanks for the analysis. Does the current mechanism to blacklist a
> > recipe help possible finding users of this recipe?  Is your concern
> > carrying this in the next LTS as well?
>
> I guess adding a PNBLACKLIST for it would work too (I have never used
> it, so I did not think off it). My concern was mainly that I had to
> spend time on fixing the recipe to support that /var/volatile is now
> checked for being empty, for a recipe that apparently is broken. So
> if a PNBLACKLIST helps the next person that does changes to the system
> from having to care about the broken opensaf recipe, then that is fine
> with me. ;)

Generally, I would refrain from excluding recipes via PNBLACKLIST if they can be
brought to support whatever improvements we are doing in Core or other
dependencies
thats the price of accepting recipes into a layer in the first place.
If its broken such that
it can not be fixed then we should perhaps exclude it.

It was added via below commit, so perhaps Bian could be much better suited to
say if it is still in use or not.

 commit e18830c2b4323487f9afa5205f13579903c7f9d4
  Author: Bian Naimeng <biannm@cn.fujitsu.com>
  Date:   Wed Dec 31 16:22:06 2014 +0800

      opensaf: add recipe

      OpenSAF is an open source implementation of the SAF AIS specification

      Signed-off-by: Bian Naimeng <biannm@cn.fujitsu.com>
      Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
      Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>


>
> In the end I did send a patch that changes the opensaf recipe to create
> /var/log/opensaf in runtime, by copying the solution for one of the
> other recipes I was fixing. So I am in the clear for my change to
> OE-Core. But opensaf is still as broken as before when it comes to
> actually starting the service...


Thanks for fixing the bunch of recipes for this,. Really helpful.

>
> > -armin
> > >
> > > //Peter
>
> //Peter
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#93792): https://lists.openembedded.org/g/openembedded-devel/message/93792
> Mute This Topic: https://lists.openembedded.org/mt/86770394/1997914
> Group Owner: openembedded-devel+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

RE: [oe] Is it time to remove opensaf?

[Peter Kjellerstedt]

> -----Original Message-----
> From: openembedded-devel@lists.openembedded.org <openembedded-
> devel@lists.openembedded.org> On Behalf Of Khem Raj
> Sent: den 2 november 2021 21:20
> To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> Cc: akuster808 <akuster808@gmail.com>; OE Development (openembedded-
> devel@lists.openembedded.org) <openembedded-devel@lists.openembedded.org>
> Subject: Re: [oe] Is it time to remove opensaf?
> 
> On Tue, Nov 2, 2021 at 1:11 PM Peter Kjellerstedt
> <peter.kjellerstedt@axis.com> wrote:
> >
> > > -----Original Message-----
> > > From: akuster808 <akuster808@gmail.com>
> > > Sent: den 2 november 2021 20:41
> > > To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; OE Development
> > > (openembedded-devel@lists.openembedded.org) <openembedded-
> > > devel@lists.openembedded.org>
> > > Subject: Re: [oe] Is it time to remove opensaf?
> > >
> > > Peter,
> > >
> > > On 11/2/21 9:33 AM, Peter Kjellerstedt wrote:
> > > > I am currently working on patches for OE-Core to report QA warnings
> > > > in case some directories that are expected to be empty have some
> > > > files installed into them. As part of the review process, Khem
> > > > reported failures for some recipes in OpenEmbedded due to this,
> > > > opensaf being one of them.
> > > >
> > > > Now I have tried to build and run opensaf in a QEMU image, but I
> > > > cannot get it to work. The sysvinit initscript relies on
> > > > /lib/lsb/init-functions, which AFAICT has not existed since lsb
> > > > was removed from OE-Core two years ago, and opensaf has never
> > > > depended on lsb in the first place. As for systemd, the service
> > > > file uses the same sysvinit scripts so it has the same problem.
> > > > And in addition, the script is in /etc/init.d, which
> > > > systemd.bbclass removes unless both sysvinit and systemd are
> > > > enabled in DISTRO_FEATURES.
> > > >
> > > > And in addition to this, if I just try to start the opensafd binary
> > > > it seg faults immediately.
> > > >
> > > > So all in all, even if opensaf has been updated regularly, it
> > > > doesn't seem like anyone is actually using it. Which brings me to
> > > > my actual question: should I just send a patch to remove it?
> > > >
> > > > Alternatively I can fix the creation of the /var/log/opensaf
> > > > directory, which was the error Khem saw with my patch for OE-Core
> > > > applied, but it seems like wasted work in case no one is actually
> > > > using the recipe...
> > >
> > > Thanks for the analysis. Does the current mechanism to blacklist a
> > > recipe help possible finding users of this recipe?  Is your concern
> > > carrying this in the next LTS as well?
> >
> > I guess adding a PNBLACKLIST for it would work too (I have never used
> > it, so I did not think off it). My concern was mainly that I had to
> > spend time on fixing the recipe to support that /var/volatile is now
> > checked for being empty, for a recipe that apparently is broken. So
> > if a PNBLACKLIST helps the next person that does changes to the system
> > from having to care about the broken opensaf recipe, then that is fine
> > with me. ;)
> 
> Generally, I would refrain from excluding recipes via PNBLACKLIST if they
> can be brought to support whatever improvements we are doing in Core or 
> other dependencies thats the price of accepting recipes into a layer in 
> the first place. If its broken such that it can not be fixed then we 
> should perhaps exclude it.

I took a turn down memory lane and checked through the git log for the 
opensaf recipe. It seems the problem with the service file for systemd 
relying on files in /etc/init.d was discovered and hacked around in 
April 2016 and then later broken again in November 2016 because the 
previous hack was misunderstood... This I can solve properly, and I 
will send a patch for it (based on top of the series I sent earlier) 
so that there is at least one less problem.

Unfortunately that will not solve the problem that the intscript relies 
on /lib/lsb/init-functions, which has not existed since the lsb recipe 
was removed from OE-Core two years ago (though the opensaf recipe has 
never depended on the lsb recipe even though it should have).

I could write a comment in the commit message if you want, stating that 
my fix for the file in /etc/init.d will not actually make the service 
file work so that there is at least some track of this information for 
the next person that comes looking at the recipe.

> It was added via below commit, so perhaps Bian could be much better suited to
> say if it is still in use or not.
> 
>  commit e18830c2b4323487f9afa5205f13579903c7f9d4
>   Author: Bian Naimeng <biannm@cn.fujitsu.com>
>   Date:   Wed Dec 31 16:22:06 2014 +0800
> 
>       opensaf: add recipe
> 
>       OpenSAF is an open source implementation of the SAF AIS specification
> 
>       Signed-off-by: Bian Naimeng <biannm@cn.fujitsu.com>
>       Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
>       Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>

Bian hasn't been active in the community for over six years, so that is 
probably hoping for much.

> > In the end I did send a patch that changes the opensaf recipe to create
> > /var/log/opensaf in runtime, by copying the solution for one of the
> > other recipes I was fixing. So I am in the clear for my change to
> > OE-Core. But opensaf is still as broken as before when it comes to
> > actually starting the service...
> 
> Thanks for fixing the bunch of recipes for this,. Really helpful.

Well, it was my change to OE-Core that broke them, so of course I will 
fix them.

> > > -armin
> > > >
> > > > //Peter
> >
> > //Peter

//Peter

Re: [oe] Is it time to remove opensaf?

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 6161 bytes --]

On Tue, Nov 2, 2021 at 3:35 PM Peter Kjellerstedt <
peter.kjellerstedt@axis.com> wrote:

> > -----Original Message-----
> > From: openembedded-devel@lists.openembedded.org <openembedded-
> > devel@lists.openembedded.org> On Behalf Of Khem Raj
> > Sent: den 2 november 2021 21:20
> > To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> > Cc: akuster808 <akuster808@gmail.com>; OE Development (openembedded-
> > devel@lists.openembedded.org) <openembedded-devel@lists.openembedded.org
> >
> > Subject: Re: [oe] Is it time to remove opensaf?
> >
> > On Tue, Nov 2, 2021 at 1:11 PM Peter Kjellerstedt
> > <peter.kjellerstedt@axis.com> wrote:
> > >
> > > > -----Original Message-----
> > > > From: akuster808 <akuster808@gmail.com>
> > > > Sent: den 2 november 2021 20:41
> > > > To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; OE Development
> > > > (openembedded-devel@lists.openembedded.org) <openembedded-
> > > > devel@lists.openembedded.org>
> > > > Subject: Re: [oe] Is it time to remove opensaf?
> > > >
> > > > Peter,
> > > >
> > > > On 11/2/21 9:33 AM, Peter Kjellerstedt wrote:
> > > > > I am currently working on patches for OE-Core to report QA warnings
> > > > > in case some directories that are expected to be empty have some
> > > > > files installed into them. As part of the review process, Khem
> > > > > reported failures for some recipes in OpenEmbedded due to this,
> > > > > opensaf being one of them.
> > > > >
> > > > > Now I have tried to build and run opensaf in a QEMU image, but I
> > > > > cannot get it to work. The sysvinit initscript relies on
> > > > > /lib/lsb/init-functions, which AFAICT has not existed since lsb
> > > > > was removed from OE-Core two years ago, and opensaf has never
> > > > > depended on lsb in the first place. As for systemd, the service
> > > > > file uses the same sysvinit scripts so it has the same problem.
> > > > > And in addition, the script is in /etc/init.d, which
> > > > > systemd.bbclass removes unless both sysvinit and systemd are
> > > > > enabled in DISTRO_FEATURES.
> > > > >
> > > > > And in addition to this, if I just try to start the opensafd binary
> > > > > it seg faults immediately.
> > > > >
> > > > > So all in all, even if opensaf has been updated regularly, it
> > > > > doesn't seem like anyone is actually using it. Which brings me to
> > > > > my actual question: should I just send a patch to remove it?
> > > > >
> > > > > Alternatively I can fix the creation of the /var/log/opensaf
> > > > > directory, which was the error Khem saw with my patch for OE-Core
> > > > > applied, but it seems like wasted work in case no one is actually
> > > > > using the recipe...
> > > >
> > > > Thanks for the analysis. Does the current mechanism to blacklist a
> > > > recipe help possible finding users of this recipe?  Is your concern
> > > > carrying this in the next LTS as well?
> > >
> > > I guess adding a PNBLACKLIST for it would work too (I have never used
> > > it, so I did not think off it). My concern was mainly that I had to
> > > spend time on fixing the recipe to support that /var/volatile is now
> > > checked for being empty, for a recipe that apparently is broken. So
> > > if a PNBLACKLIST helps the next person that does changes to the system
> > > from having to care about the broken opensaf recipe, then that is fine
> > > with me. ;)
> >
> > Generally, I would refrain from excluding recipes via PNBLACKLIST if they
> > can be brought to support whatever improvements we are doing in Core or
> > other dependencies thats the price of accepting recipes into a layer in
> > the first place. If its broken such that it can not be fixed then we
> > should perhaps exclude it.
>
> I took a turn down memory lane and checked through the git log for the
> opensaf recipe. It seems the problem with the service file for systemd
> relying on files in /etc/init.d was discovered and hacked around in
> April 2016 and then later broken again in November 2016 because the
> previous hack was misunderstood... This I can solve properly, and I
> will send a patch for it (based on top of the series I sent earlier)
> so that there is at least one less problem.
>
> Unfortunately that will not solve the problem that the intscript relies
> on /lib/lsb/init-functions, which has not existed since the lsb recipe
> was removed from OE-Core two years ago (though the opensaf recipe has
> never depended on the lsb recipe even though it should have).
>
> I could write a comment in the commit message if you want, stating that
> my fix for the file in /etc/init.d will not actually make the service
> file work so that there is at least some track of this information for
> the next person that comes looking at the recipe.


Absolutely that’s fine

>
>
> > It was added via below commit, so perhaps Bian could be much better
> suited to
> > say if it is still in use or not.
> >
> >  commit e18830c2b4323487f9afa5205f13579903c7f9d4
> >   Author: Bian Naimeng <biannm@cn.fujitsu.com>
> >   Date:   Wed Dec 31 16:22:06 2014 +0800
> >
> >       opensaf: add recipe
> >
> >       OpenSAF is an open source implementation of the SAF AIS
> specification
> >
> >       Signed-off-by: Bian Naimeng <biannm@cn.fujitsu.com>
> >       Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> >       Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
>
> Bian hasn't been active in the community for over six years, so that is
> probably hoping for much.
>
> > > In the end I did send a patch that changes the opensaf recipe to create
> > > /var/log/opensaf in runtime, by copying the solution for one of the
> > > other recipes I was fixing. So I am in the clear for my change to
> > > OE-Core. But opensaf is still as broken as before when it comes to
> > > actually starting the service...
> >
> > Thanks for fixing the bunch of recipes for this,. Really helpful.
>
> Well, it was my change to OE-Core that broke them, so of course I will
> fix them.
>
> > > > -armin
> > > > >
> > > > > //Peter
> > >
> > > //Peter
>
> //Peter
>
>

[-- Attachment #2: Type: text/html, Size: 8647 bytes --]