Re: [gentoo-dev] Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run
On 05/05/2016 01:12 AM, William Hubbs wrote: > On Wed, May 04, 2016 at 07:41:39PM +1000, Sam Jorna wrote: >> On Wed, May 04, 2016 at 10:57:44AM +0200, Kristian Fiskerstrand wrote: >>> On 05/04/2016 10:52 AM, Sam Jorna wrote: On Wed, May 04, 2016 at 10:00:05AM +0200, Ulrich Mueller wrote: >> On Wed, 4 May 2016, Austin English wrote: >>> Your list of affected packages obtained with "git grep" in the >>> Portage tree will not be complete, since the command won't catch >>> any init scripts installed from elsewhere. You should look for the >>> set of installed files instead. >> How is that relevant here at all? I'm cleaning up portage installed >> init scripts, [...] > You are cleaning up only those init scripts that are installed from > FILESDIR, but you will miss the ones that are installed from a file > in SRC_URI. Perhaps an alternate way to do it would be to have a QA check look at any files installed to ${D}etc/init.d/ and throw a warning if their shebang is "#!/sbin/runscript" >>> A repoman check is a much saner approach, I'm not convinced there is >>> sufficient need for this change to begin with, in particular to start >>> touching a wide range of packages. Breaking backwards compatibility in >>> any way should have a darn good reason, and I haven't seen one yet >> I'm not arguing for or against it in general, just in terms of technical >> implementation. >> >> That being said, a repoman check would only catch those distributed in >> ${FILESDIR} as well. My thinking with the above was to also identify >> those installed from distfiles to be handled accordingly. > Actually, you won't need to worry about any qa checks in portage, > because I am going to put a deprecation warning in OpenRC upstream which > will be displayed when a service script invokes runscript instructing > you to convert to openrc-run. > > OpenRC will keep runscript, with this warning, for a while. > > So again, because I feel like either I'm too stupid to understand this, or too smart to let such an obviously bad idea continue: What problem is being solved here?
Re: [gentoo-dev] Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run
On Wed, May 04, 2016 at 07:41:39PM +1000, Sam Jorna wrote: > On Wed, May 04, 2016 at 10:57:44AM +0200, Kristian Fiskerstrand wrote: > > On 05/04/2016 10:52 AM, Sam Jorna wrote: > > > On Wed, May 04, 2016 at 10:00:05AM +0200, Ulrich Mueller wrote: > > >>> On Wed, 4 May 2016, Austin English wrote: > > >> > > Your list of affected packages obtained with "git grep" in the > > Portage tree will not be complete, since the command won't catch > > any init scripts installed from elsewhere. You should look for the > > set of installed files instead. > > >> > > >>> How is that relevant here at all? I'm cleaning up portage installed > > >>> init scripts, [...] > > >> > > >> You are cleaning up only those init scripts that are installed from > > >> FILESDIR, but you will miss the ones that are installed from a file > > >> in SRC_URI. > > > > > > Perhaps an alternate way to do it would be to have a QA check look at > > > any files installed to ${D}etc/init.d/ and throw a warning if their > > > shebang is "#!/sbin/runscript" > > > > > > > A repoman check is a much saner approach, I'm not convinced there is > > sufficient need for this change to begin with, in particular to start > > touching a wide range of packages. Breaking backwards compatibility in > > any way should have a darn good reason, and I haven't seen one yet > > I'm not arguing for or against it in general, just in terms of technical > implementation. > > That being said, a repoman check would only catch those distributed in > ${FILESDIR} as well. My thinking with the above was to also identify > those installed from distfiles to be handled accordingly. Actually, you won't need to worry about any qa checks in portage, because I am going to put a deprecation warning in OpenRC upstream which will be displayed when a service script invokes runscript instructing you to convert to openrc-run. OpenRC will keep runscript, with this warning, for a while. William signature.asc Description: Digital signature
Re: [gentoo-dev] Re : Cannot see my eclass modifications
ok, thank you.I will try the chroot stuff as soon as I have some time. As for what I'm trying to do: making portage able to add user/groups when using --root option. This is a known limitation since a long time. I'm currently also discussing this point with the "shadow" upstream team (I have some patches for useradd and groupadd) So for now I'm trying to make portage to just echo some traces when calling enewgroup for example, when I emerge sys-power/nut as a test package (that package is creating a nut user and group) I tried to put some einfo at the begining of the enewgroup function, but I do not see them. I also tryed echo "test" > /tmp/test.txt, and I do no see the file too... And I see the traces from the nut ebuild (package_setup if I remember properly). And if I remove the nut group from my /etc/group, I do see the enewgroup original traces, but not mine. It's as if portage is using a different enewgroup function, or a cached one... I tried the irc last time, but nobody was there (most likely because of the time. I will try tomorrow late afternoon) En date de : Mer 4.5.16, Ian Stakenvicius a écrit : Objet: Re: [gentoo-dev] Re : Cannot see my eclass modifications À: gentoo-dev@lists.gentoo.org Date: Mercredi 4 mai 2016, 20h28 On 04/05/16 02:30 PM, Farid BENAMROUCHE wrote: > hum... yes I've setup all the relevant settings in my /etc/portage... > I've also read the man, and still not understanding why. > > But At least you are confirming me that directly modifying the user.eclass in /usr/portage/eclass should work! > > The exact command line I've used was ROOT=/sysroot emerge -av sys-power/nut, where sysroot is a working x86 rootfs (ie, I can chroot in it) with no portage inside... > > PORTAGE_ECLASS_WARNING_ENABLE="1" in the make.conf seems to not work too... ..ok so if you've got a full chroot, you might want to use 'emerge --config-root=/path/to/chroot [stuff]' and make sure that the /etc/portage/repos.conf changes you made are in the chroot too. Barring that, though, the issue may very well be the type of changes you're trying to make to user.eclass just not working (or being called) as expected. A bunch of us hang out on irc.freenode.org in #gentoo-dev-help , and stuff like this may be easier to help with in a more interactive environment like that.
Re: [gentoo-dev] Reminder: ALLARCHES
On Wed, May 04, 2016 at 04:05:50PM -0400, Ian Stakenvicius wrote > On 04/05/16 03:43 PM, waltd...@waltdnes.org wrote: > > > > emerge --keyword-write > > > > ... similar to "emerge --autounmask-write", but have it write to > > package.accept_keywords, rather than package.unmask? > > > > That would achieve the effect that people are looking for, with less > > work. > > > > > --autounmask-write modifies package.mask, package.accept_keywords and > package.use already, FYI -- has done so since its inception so far as > I'm aware.. The emerge man page does mention unmasking packages and setting package.use with --autounmask, but not keywords --autounmask [ y | n ] Automatically unmask packages and generate package.use settings as necessary to satisfy dependencies. ***BUT*** --autounmask-unrestricted-atoms [ y | n ] If --autounmask is enabled, keyword and mask changes using the ´=´ operator will be written This is confusing, to say the least. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Reminder: ALLARCHES
On 04/05/16 03:43 PM, waltd...@waltdnes.org wrote: > > emerge --keyword-write > > ... similar to "emerge --autounmask-write", but have it write to > package.accept_keywords, rather than package.unmask? > > That would achieve the effect that people are looking for, with less > work. > --autounmask-write modifies package.mask, package.accept_keywords and package.use already, FYI -- has done so since its inception so far as I'm aware.. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Reminder: ALLARCHES
On Tue, May 03, 2016 at 09:46:10PM -0700, Matt Turner wrote > On Tue, May 3, 2016 at 5:50 PM, Mike Gilbert wrote: > > On Tue, May 3, 2016 at 5:34 PM, Jeroen Roovers wrote: > >> The solution is to have people with an actual interest in a specific > >> architecture determine whether stabilising a package is viable, and > >> taking sensible action, like dropping stable keywords where applicable. > > > > If these people do not actually exist or are not doing their job by > > culling the depgraph appropriately, we should really drop a number of > > archs from "stable" status. > > I mostly agree, modulo the comment about people "doing their jobs". > Arch testing completely sucks. > > Having built many stages for an "unstable" arch (mips) has taught me > one thing: it's awful being unstable-only. There's no end to the > compilation failures and other such headaches, none of which have > anything at all to do with the specific architecture. > > Short of adding a middle level ("stable, wink wink nudge nudge") where > things at least compile, I think the current situation is actually > significantly better than the alternative of dropping them to > unstable. Matt points out a problem with the current situation. There are basically 2 levels of unstable... 1) Ancient or really new stuff that doesn't compile, let alone run, in the presence of current libraries. 2) Stuff that actually works, but the devs have not stabilized it yet. People who accept unstable ~arch generally want the second group, but going all out ~arch brings in builds from the first group, which breaks systems. The way to get "the best of both worlds" is to start with stable, and only keyword stuff that you need, which is hopefully in the second group. That can get painfull with multiple dependancies, requiring re-iterative multiple runs and keywording. Can I make a suggestion here? Is it possible for the devs to come up with with... emerge --keyword-write ... similar to "emerge --autounmask-write", but have it write to package.accept_keywords, rather than package.unmask? That would achieve the effect that people are looking for, with less work. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Re : Cannot see my eclass modifications
On 04/05/16 02:30 PM, Farid BENAMROUCHE wrote: > hum... yes I've setup all the relevant settings in my /etc/portage... > I've also read the man, and still not understanding why. > > But At least you are confirming me that directly modifying the user.eclass in > /usr/portage/eclass should work! > > The exact command line I've used was ROOT=/sysroot emerge -av sys-power/nut, > where sysroot is a working x86 rootfs (ie, I can chroot in it) with no > portage inside... > > PORTAGE_ECLASS_WARNING_ENABLE="1" in the make.conf seems to not work too... ..ok so if you've got a full chroot, you might want to use 'emerge --config-root=/path/to/chroot [stuff]' and make sure that the /etc/portage/repos.conf changes you made are in the chroot too. Barring that, though, the issue may very well be the type of changes you're trying to make to user.eclass just not working (or being called) as expected. A bunch of us hang out on irc.freenode.org in #gentoo-dev-help , and stuff like this may be easier to help with in a more interactive environment like that. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re : Cannot see my eclass modifications
hum... yes I've setup all the relevant settings in my /etc/portage... I've also read the man, and still not understanding why. But At least you are confirming me that directly modifying the user.eclass in /usr/portage/eclass should work! The exact command line I've used was ROOT=/sysroot emerge -av sys-power/nut, where sysroot is a working x86 rootfs (ie, I can chroot in it) with no portage inside... PORTAGE_ECLASS_WARNING_ENABLE="1" in the make.conf seems to not work too... En date de : Mar 3.5.16, Mike Gilbert a écrit : Objet: Re: [gentoo-dev] Re : Cannot see my eclass modifications À: "Gentoo Dev" , fariou...@yahoo.fr Date: Mardi 3 mai 2016, 23h39 On Tue, May 3, 2016 at 5:42 PM, Farid BENAMROUCHE wrote: > Hi, > > I'm still searching for the reason why I'm not seeing my eclass modifications... no luck so far. > > What can I do to debug portage's behavior? > > Thank you > > > En date de : Sam 30.4.16, Farid BENAMROUCHE a écrit : > > Objet: Re : Cannot see my eclass modifications > À: gentoo-dev@lists.gentoo.org > Date: Samedi 30 avril 2016, 20h03 > > Hi all, > > I'm currently developping a patch for user.eclass, but I'm > banging my head against a wall... > > So for testing first, I've setup an overlay, and I now > that > it is taken in account by portage (If I rename portage's > user.eclass, emerge is still working. If I remove my > overlay, emerge complains about missing user eclass. So my > overlay is actually working) > I've modified enewgroup and egetent for example and put > some > einfo and also modified some other stuffs to be sure that > I'm entering the function > > Then emerge sys-power/nut, I can see the pkg-setup traces, > just after the call to enewgroup... but still cannot see > my > eclass modifications! > I tried to modify directly the > /usr/portage/eclass/user.eclass file, but still the same > issue... > I'm totally puzzled about this point! I'm most likely > missing a stupid point somewhere... > > Anyone knows what could be the problem? Please let me know > what traces/info you need and I will post them. > > Thank you! > > Portage will only use eclasses from your overlay for ebuilds in your overlay, at least by default. You can force it to use your overlay by setting eclass-overrides in repos.conf. I have no idea why you would experience this problem if you are modifying /usr/portage/eclass directly.
Re: [gentoo-dev] Reminder: ALLARCHES
On Wed, May 4, 2016 at 8:44 AM, Mike Gilbert wrote: > On Wed, May 4, 2016 at 10:41 AM, Peter Stuge wrote: >> Mike Gilbert wrote: >>> "doing your job" >> >> Remember that everyone is a volunteer. > > I am referring to arch testing as a job, because it only really works > if people treat it that way. If stabilization does not take place in a > timely manner, the system falls apart, and you end up with frustrated > maintainers. > > If there aren't people who are putting in that time commitment, the > arch should not be called "stable". I think it should be plainly obvious at this point why the bug tracker is full of unresolved stable requests.
Re: [gentoo-dev] Reminder: ALLARCHES
On 05/04/2016 11:41 AM, Ian Stakenvicius wrote: On 04/05/16 02:01 AM, Kent Fredric wrote: On 4 May 2016 at 16:46, Matt Turner wrote: Having built many stages for an "unstable" arch (mips) has taught me one thing: it's awful being unstable-only. There's no end to the compilation failures and other such headaches, none of which have anything at all to do with the specific architecture. Short of adding a middle level ("stable, wink wink nudge nudge") where things at least compile, I think the current situation is actually significantly better than the alternative of dropping them to unstable. I feel like there needs to be something inbetween, a mechanism where things can be deemed "tentatively stable", where in they can still be later destabilized if evidence compels it. As it is, stabilization seems one-directional. If critical defects are found in "stable" releases, they tend not to escalate in the other direction. And I understand why that is, but it doesn't stop me wishing otherwise. But instead of adding a rung between stable and unstable ... maybe the right approach is to add a layer /beneath/ stable : "Long term stable". Where long-term stable is "Known to be good at a deep and thorough level by people who use the software regularly". Long-term stable at this point is not something I'd suggest people set as their keywords in general, but it would be a thing that would only be granted to specific packages on a case-by-case basis, and it would only be encouraged to be used in the sense of /etc/portage/package.keywords , where mixing long-term stable and stable would be "supported" ... somehow. IDK, there's still a lot wrong with my ideas, but hopefully there's some ball here to run with. Rather than adding a third layer of stability and splitting the userbase even further, how about we just be less shy about dropping stable keywords on packages back to ~arch when we have bugs that can't be resolved quickly? I know this isn't ideal given everyone --sync's at different times and varying intervals, but if a particular ebuild gets stabilized on an arch and is found to really not be ready at least there's a recourse to undo the stabilization and stop -some- users from getting the new version via their -uDN @world updates. What might we need in terms of better PM support, for stable -> ~arch keywording? +1 Nice to know that when there is a bug on stable that a world upgrade will fix the issue within a reasonable time frame. Even if it means some downgrades.
Re: [gentoo-dev] Reminder: ALLARCHES
On Wed, May 4, 2016 at 10:41 AM, Peter Stuge wrote: > Mike Gilbert wrote: >> "doing your job" > > Remember that everyone is a volunteer. I am referring to arch testing as a job, because it only really works if people treat it that way. If stabilization does not take place in a timely manner, the system falls apart, and you end up with frustrated maintainers. If there aren't people who are putting in that time commitment, the arch should not be called "stable".
Re: [gentoo-dev] Reminder: ALLARCHES
On 04/05/16 02:01 AM, Kent Fredric wrote: > On 4 May 2016 at 16:46, Matt Turner wrote: >> Having built many stages for an "unstable" arch (mips) has taught me >> one thing: it's awful being unstable-only. There's no end to the >> compilation failures and other such headaches, none of which have >> anything at all to do with the specific architecture. >> >> Short of adding a middle level ("stable, wink wink nudge nudge") where >> things at least compile, I think the current situation is actually >> significantly better than the alternative of dropping them to >> unstable. > > I feel like there needs to be something inbetween, a mechanism where > things can be deemed "tentatively stable", where in they can still be > later destabilized if evidence compels it. > > As it is, stabilization seems one-directional. If critical defects are > found in "stable" releases, they tend not to escalate in the other > direction. > > And I understand why that is, but it doesn't stop me wishing otherwise. > > But instead of adding a rung between stable and unstable ... maybe the > right approach is to add a layer /beneath/ stable : "Long term > stable". > > Where long-term stable is "Known to be good at a deep and thorough > level by people who use the software regularly". > > Long-term stable at this point is not something I'd suggest people set > as their keywords in general, but it would be a thing that would only > be granted to specific packages on a case-by-case basis, and it would > only be encouraged to be used in the sense of > /etc/portage/package.keywords , where mixing long-term stable and > stable would be "supported" ... somehow. > > IDK, there's still a lot wrong with my ideas, but hopefully there's > some ball here to run with. > > Rather than adding a third layer of stability and splitting the userbase even further, how about we just be less shy about dropping stable keywords on packages back to ~arch when we have bugs that can't be resolved quickly? I know this isn't ideal given everyone --sync's at different times and varying intervals, but if a particular ebuild gets stabilized on an arch and is found to really not be ready at least there's a recourse to undo the stabilization and stop -some- users from getting the new version via their -uDN @world updates. What might we need in terms of better PM support, for stable -> ~arch keywording? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Dev retirement - Farewell message
prends soin de toi On Tue, May 3, 2016 at 11:43 AM Sven Vermeulen wrote: > On Sun, May 01, 2016 at 04:57:09PM +0200, José Fournier wrote: > > I have been a bit far from Gentoo for a rather long time now. I joined > > Gentoo in 2013 and I used to be a translator for the French language. At > > this time, I had to become a developer in order to be able to submit my > > work in the previous documentation system – but in reality I am not a > > developer at all. Nowadays, with the new wiki – which I can see grow > > and improve day after day – it is no longer necessary for people like me > > become a developer. > > > > At the beginning I could get a friendly and patient help from Sven > > Vermeulen who introduced me and was my mentor for a while. I am very > > grateful to him because it is not something obvious for someone who is > > not a computer scientist to enter a world like the Gentoo Community and > > Sven contributed a lot to make me feel at home. > > > > Recently, I decided to join the Fedora community to help as a translator > > again. It a very different distribution and community but my previous > > experience at Gentoo is very valuable. Arriving in this new home, I told > > them all the good I think of the Gentoo distribution and of its people. > > If there is one distribution which made me progress substantially in my > > understanding of the Linux system, it is Gentoo, with no doubt. > > > > Before leaving your community, I want to wish you all the best and thank > > you very much for your constant effort to make free and open source > > software available to everyone. > > > > Hi José, > > Although it's sad to see you leave, I feel it's more like a mutation than a > farewell. I'm glad you continue to contribute to the open source/free > software community, and wish you all the best within the Fedora community. > > With kind regards, > > Sven Vermeulen > aka SwifT > >
Re: [gentoo-dev] Reminder: ALLARCHES
Mike Gilbert wrote: > "doing your job" Remember that everyone is a volunteer. > dropping stable keywords on everything but the bare necessities Gentoo magically does a number of things which upstream never intended and do not intentionally support. It is amazing, and thank you so much to everyone who makes it possible! At the same time all the upstream crap is pretty tragic. I am absolutely in favor of exposing users to it, rather than the happy Gentoo garden full of magic patches :) and fast-path:ing bugs upstream when things do not work. In an ideal world, upstream would care. Of course many don't, and patches may still end up in Gentoo, but then at least users would know, and might get involved upstream, where they can actually help improve the package. Gentoo is the wrong place for that, so it doesn't make sense for them to get involved in Gentoo. I think unstable on (most) everything would be a great thing. Again: Thanks to everyone who contributes to Gentoo! :) //Peter
Re: [gentoo-dev] Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run
On 04.05.2016 14:54, Manuel Rüger wrote: > On 04.05.2016 11:19, Duncan wrote: >> Ulrich Mueller posted on Wed, 04 May 2016 10:00:05 +0200 as excerpted: >> On Wed, 4 May 2016, Austin English wrote: >>> > Your list of affected packages obtained with "git grep" in the Portage > tree will not be complete, since the command won't catch any init > scripts installed from elsewhere. You should look for the set of > installed files instead. >>> How is that relevant here at all? I'm cleaning up portage installed init scripts, [...] >>> >>> You are cleaning up only those init scripts that are installed from >>> FILESDIR, but you will miss the ones that are installed from a file in >>> SRC_URI. >> >> While you are correct, the current problem isn't lack of low hanging >> fruit to fix in the files dir, as he said there's 700 packages on the >> list already, too many to file individual bugs for. >> >> So while it is indeed worthwhile to keep in mind the init-scripts >> installed from SRC_URI... >> >> There's seven hundred "miles of open road" to cross before we have to >> worry about that SRC_URI bridge, so maybe worry about that when we're >> within 50 or 100, or even a couple hundred, "miles", not 700. =:^] >> > > Hi Austin, > > to be honest, I'm not too happy with the fixes you applied. > Although it's just a tiny change, I'd rather have expected a revision > bump to the ebuilds and a revision bump to the init files themselves > than just a in-file rewrite. > Your fix changes the content of files that are installed to ones system. > Such a change usually requires a revbump. > > > Cheers, > > Manuel > > Nevermind, I didn't see the follow-up commit in which you removed the old revision. Cheers, Manuel signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run
On 04.05.2016 11:19, Duncan wrote: > Ulrich Mueller posted on Wed, 04 May 2016 10:00:05 +0200 as excerpted: > >>> On Wed, 4 May 2016, Austin English wrote: >> Your list of affected packages obtained with "git grep" in the Portage tree will not be complete, since the command won't catch any init scripts installed from elsewhere. You should look for the set of installed files instead. >> >>> How is that relevant here at all? I'm cleaning up portage installed >>> init scripts, [...] >> >> You are cleaning up only those init scripts that are installed from >> FILESDIR, but you will miss the ones that are installed from a file in >> SRC_URI. > > While you are correct, the current problem isn't lack of low hanging > fruit to fix in the files dir, as he said there's 700 packages on the > list already, too many to file individual bugs for. > > So while it is indeed worthwhile to keep in mind the init-scripts > installed from SRC_URI... > > There's seven hundred "miles of open road" to cross before we have to > worry about that SRC_URI bridge, so maybe worry about that when we're > within 50 or 100, or even a couple hundred, "miles", not 700. =:^] > Hi Austin, to be honest, I'm not too happy with the fixes you applied. Although it's just a tiny change, I'd rather have expected a revision bump to the ebuilds and a revision bump to the init files themselves than just a in-file rewrite. Your fix changes the content of files that are installed to ones system. Such a change usually requires a revbump. Cheers, Manuel signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Reminder: ALLARCHES
On Wed, May 4, 2016 at 12:46 AM, Matt Turner wrote: > Having built many stages for an "unstable" arch (mips) has taught me > one thing: it's awful being unstable-only. There's no end to the > compilation failures and other such headaches, none of which have > anything at all to do with the specific architecture. > > Short of adding a middle level ("stable, wink wink nudge nudge") where > things at least compile, I think the current situation is actually > significantly better than the alternative of dropping them to > unstable. In that case, "doing your job" would mean dropping stable keywords on everything but the bare necessities, and refusing to stabilize packages outside of that group without good cause.
Re: [gentoo-dev] Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run
On Wed, May 04, 2016 at 10:57:44AM +0200, Kristian Fiskerstrand wrote: > On 05/04/2016 10:52 AM, Sam Jorna wrote: > > On Wed, May 04, 2016 at 10:00:05AM +0200, Ulrich Mueller wrote: > >>> On Wed, 4 May 2016, Austin English wrote: > >> > Your list of affected packages obtained with "git grep" in the > Portage tree will not be complete, since the command won't catch > any init scripts installed from elsewhere. You should look for the > set of installed files instead. > >> > >>> How is that relevant here at all? I'm cleaning up portage installed > >>> init scripts, [...] > >> > >> You are cleaning up only those init scripts that are installed from > >> FILESDIR, but you will miss the ones that are installed from a file > >> in SRC_URI. > > > > Perhaps an alternate way to do it would be to have a QA check look at > > any files installed to ${D}etc/init.d/ and throw a warning if their > > shebang is "#!/sbin/runscript" > > > > A repoman check is a much saner approach, I'm not convinced there is > sufficient need for this change to begin with, in particular to start > touching a wide range of packages. Breaking backwards compatibility in > any way should have a darn good reason, and I haven't seen one yet I'm not arguing for or against it in general, just in terms of technical implementation. That being said, a repoman check would only catch those distributed in ${FILESDIR} as well. My thinking with the above was to also identify those installed from distfiles to be handled accordingly. -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
[gentoo-dev] Re: Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run
Ulrich Mueller posted on Wed, 04 May 2016 10:00:05 +0200 as excerpted: >> On Wed, 4 May 2016, Austin English wrote: > >>> Your list of affected packages obtained with "git grep" in the Portage >>> tree will not be complete, since the command won't catch any init >>> scripts installed from elsewhere. You should look for the set of >>> installed files instead. > >> How is that relevant here at all? I'm cleaning up portage installed >> init scripts, [...] > > You are cleaning up only those init scripts that are installed from > FILESDIR, but you will miss the ones that are installed from a file in > SRC_URI. While you are correct, the current problem isn't lack of low hanging fruit to fix in the files dir, as he said there's 700 packages on the list already, too many to file individual bugs for. So while it is indeed worthwhile to keep in mind the init-scripts installed from SRC_URI... There's seven hundred "miles of open road" to cross before we have to worry about that SRC_URI bridge, so maybe worry about that when we're within 50 or 100, or even a couple hundred, "miles", not 700. =:^] -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run
On 05/04/2016 10:52 AM, Sam Jorna wrote: > On Wed, May 04, 2016 at 10:00:05AM +0200, Ulrich Mueller wrote: >>> On Wed, 4 May 2016, Austin English wrote: >> Your list of affected packages obtained with "git grep" in the Portage tree will not be complete, since the command won't catch any init scripts installed from elsewhere. You should look for the set of installed files instead. >> >>> How is that relevant here at all? I'm cleaning up portage installed >>> init scripts, [...] >> >> You are cleaning up only those init scripts that are installed from >> FILESDIR, but you will miss the ones that are installed from a file >> in SRC_URI. > > Perhaps an alternate way to do it would be to have a QA check look at > any files installed to ${D}etc/init.d/ and throw a warning if their > shebang is "#!/sbin/runscript" > A repoman check is a much saner approach, I'm not convinced there is sufficient need for this change to begin with, in particular to start touching a wide range of packages. Breaking backwards compatibility in any way should have a darn good reason, and I haven't seen one yet -- Kristian Fiskerstrand OpenPGP certificate reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run
On Wed, May 04, 2016 at 10:00:05AM +0200, Ulrich Mueller wrote: > > On Wed, 4 May 2016, Austin English wrote: > > >> Your list of affected packages obtained with "git grep" in the > >> Portage tree will not be complete, since the command won't catch > >> any init scripts installed from elsewhere. You should look for the > >> set of installed files instead. > > > How is that relevant here at all? I'm cleaning up portage installed > > init scripts, [...] > > You are cleaning up only those init scripts that are installed from > FILESDIR, but you will miss the ones that are installed from a file > in SRC_URI. Perhaps an alternate way to do it would be to have a QA check look at any files installed to ${D}etc/init.d/ and throw a warning if their shebang is "#!/sbin/runscript" -- Sam Jorna (wraeth) GnuPG Key: D6180C26 signature.asc Description: Digital signature
Re: [gentoo-dev] Reminder: ALLARCHES
On 05/04/2016 06:46 AM, Matt Turner wrote: > On Tue, May 3, 2016 at 5:50 PM, Mike Gilbert wrote: >> On Tue, May 3, 2016 at 5:34 PM, Jeroen Roovers wrote: >>> The solution is to have people with an actual interest in a specific >>> architecture determine whether stabilising a package is viable, and >>> taking sensible action, like dropping stable keywords where applicable. >> >> If these people do not actually exist or are not doing their job by >> culling the depgraph appropriately, we should really drop a number of >> archs from "stable" status. > > I mostly agree, modulo the comment about people "doing their jobs". > Arch testing completely sucks. > > Having built many stages for an "unstable" arch (mips) has taught me > one thing: it's awful being unstable-only. There's no end to the > compilation failures and other such headaches, none of which have > anything at all to do with the specific architecture. Thats bad > > Short of adding a middle level ("stable, wink wink nudge nudge") where > things at least compile, I think the current situation is actually If it doesn't compile on at least one architecture (the one where the dev is doing the work) it shouldn't be committed to the tree at all, no need for a middle layer. > significantly better than the alternative of dropping them to > unstable. In a perfect world compile testing wouldn't be sufficient for stable either, it actually should be properly tested before releasing it on users and testsuites are sadly lacking in many situations. Even worse for GUI applications that can't easily be tested without actual user interaction, but as long as we keep servers in good shape I'm not necessarily too worried about those, and it is possibly easier to spot than a miscalculation in a statistics library Maybe a workshop to write more testsuites is a fruitful event at some point in time.. -- Kristian Fiskerstrand OpenPGP certificate reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run
> On Wed, 4 May 2016, Austin English wrote: >> Your list of affected packages obtained with "git grep" in the >> Portage tree will not be complete, since the command won't catch >> any init scripts installed from elsewhere. You should look for the >> set of installed files instead. > How is that relevant here at all? I'm cleaning up portage installed > init scripts, [...] You are cleaning up only those init scripts that are installed from FILESDIR, but you will miss the ones that are installed from a file in SRC_URI. Ulrich pgpQUUlZaiquo.pgp Description: PGP signature
Re: [gentoo-dev] Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run
On 05/04/2016 02:04 AM, Ulrich Mueller wrote: >> On Tue, 3 May 2016, Austin English wrote: >> I've been working on the transition from #!/sbin/runscript to >> #!/sbin/openrc-run [1], by starting on the maintainer-needed >> packages. That's done (aside from some stabilizations needed, but >> I'll deal with that latter). The trouble is that there are roughly >> 700 packages that need to be updated, and that's an insane number of >> bugs to file. >> [1] https://bugs.gentoo.org/show_bug.cgi?id=573846 > Your list of affected packages obtained with "git grep" in the Portage > tree will not be complete, since the command won't catch any init > scripts installed from elsewhere. You should look for the set of > installed files instead. How is that relevant here at all? I'm cleaning up portage installed init scripts, what a user does outside of that is a separate problem (for the init program, not gentoo.git). > Also, what problem are you trying to solve? My guess would be that > /sbin/runscript must be kept around indefinitely in any case, in order > not to risk breakage on users' systems. > > Ulrich Again, not my issue. I'm trying to prevent the problem from spreading further. If only new scripts get openrc-run, the runscript shebang should be rare in a year now, for example. But again, that's for OpenRC to decide. That's not reason not to get away from the deprecated name now. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Transitioning from #!/sbin/runscript to,#!/sbin/openrc-run
> On Tue, 3 May 2016, Austin English wrote: > I've been working on the transition from #!/sbin/runscript to > #!/sbin/openrc-run [1], by starting on the maintainer-needed > packages. That's done (aside from some stabilizations needed, but > I'll deal with that latter). The trouble is that there are roughly > 700 packages that need to be updated, and that's an insane number of > bugs to file. > [1] https://bugs.gentoo.org/show_bug.cgi?id=573846 Your list of affected packages obtained with "git grep" in the Portage tree will not be complete, since the command won't catch any init scripts installed from elsewhere. You should look for the set of installed files instead. Also, what problem are you trying to solve? My guess would be that /sbin/runscript must be kept around indefinitely in any case, in order not to risk breakage on users' systems. Ulrich pgpC1YIuUyeGN.pgp Description: PGP signature