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
>
>