* Is it time to remove opensaf?
@ 2021-11-02 16:33 Peter Kjellerstedt
[not found] ` <083fee51-9dd8-c9d3-7f27-90f41e8d261e@gmail.com>
0 siblings, 1 reply; 5+ messages in thread
From: Peter Kjellerstedt @ 2021-11-02 16:33 UTC (permalink / raw)
To: OE Development (openembedded-devel@lists.openembedded.org)
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
^ permalink raw reply [flat|nested] 5+ messages in thread[parent not found: <083fee51-9dd8-c9d3-7f27-90f41e8d261e@gmail.com>]
* RE: [oe] Is it time to remove opensaf? [not found] ` <083fee51-9dd8-c9d3-7f27-90f41e8d261e@gmail.com> @ 2021-11-02 20:11 ` Peter Kjellerstedt 2021-11-02 20:20 ` Khem Raj 0 siblings, 1 reply; 5+ messages in thread From: Peter Kjellerstedt @ 2021-11-02 20:11 UTC (permalink / raw) To: akuster808, OE Development (openembedded-devel@lists.openembedded.org) > -----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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [oe] Is it time to remove opensaf? 2021-11-02 20:11 ` [oe] " Peter Kjellerstedt @ 2021-11-02 20:20 ` Khem Raj 2021-11-02 22:35 ` Peter Kjellerstedt 0 siblings, 1 reply; 5+ messages in thread From: Khem Raj @ 2021-11-02 20:20 UTC (permalink / raw) To: Peter Kjellerstedt Cc: akuster808, OE Development (openembedded-devel@lists.openembedded.org) 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] > -=-=-=-=-=-=-=-=-=-=-=- > ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [oe] Is it time to remove opensaf? 2021-11-02 20:20 ` Khem Raj @ 2021-11-02 22:35 ` Peter Kjellerstedt 2021-11-02 23:55 ` Khem Raj 0 siblings, 1 reply; 5+ messages in thread From: Peter Kjellerstedt @ 2021-11-02 22:35 UTC (permalink / raw) To: Khem Raj Cc: akuster808, OE Development (openembedded-devel@lists.openembedded.org) > -----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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [oe] Is it time to remove opensaf? 2021-11-02 22:35 ` Peter Kjellerstedt @ 2021-11-02 23:55 ` Khem Raj 0 siblings, 0 replies; 5+ messages in thread From: Khem Raj @ 2021-11-02 23:55 UTC (permalink / raw) To: Peter Kjellerstedt Cc: OE Development (openembedded-devel@lists.openembedded.org), akuster808 [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-11-02 23:55 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-02 16:33 Is it time to remove opensaf? Peter Kjellerstedt
[not found] ` <083fee51-9dd8-c9d3-7f27-90f41e8d261e@gmail.com>
2021-11-02 20:11 ` [oe] " Peter Kjellerstedt
2021-11-02 20:20 ` Khem Raj
2021-11-02 22:35 ` Peter Kjellerstedt
2021-11-02 23:55 ` Khem Raj
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.