Re: [gentoo-dev] musl, sbcl, and ros
On Fri, 2 Dec 2022, Sam James wrote: If the dependencies are optional (at least for some), we should indeed (package.)use.mask sbcl on musl to reduce the damage, then package.mask the remaining unconditional reverse dependencies. But I cannot do these this myself. I use neither musl nor ros. I suppose ros developers should update their ebuilds to conditionalize as many uses of sbcl as possible. It would be good to call this USE flag "sbcl". 2 packages (sci-mathematics/maxima and sci-mathematics/fricas) already use this name, and I have included it in profiles/features/musl/use.mask. Thanks, Andrey
[gentoo-dev] Question about python compatibility in dev-python/pathlib2
Hi all, I noticed that a package from an overlay fails to install due to it requiring pathlib2 with python_targets with 3.10 and/or 3.11. So I checked pathlib2's setup.py [0] that it supports newer python versions and wanted to update the ebuild, but noticed My question is whether I should: 1) do some more research/work to bump the versions or 2) update the upstream in case this is something deprecated order 3) whether the updated ebuild with newer python versions should live in the overlay instead. Thanks for any (non-null) pointers, Martin [0] https://github.com/jazzband/pathlib2/blob/develop/setup.py#L39
Re: [gentoo-dev] musl, sbcl, and ros
For the record I've had sbcl building and running on musl for months without issue (at one point I even had static linking working). You have to cross compile a musl version and then side load the binary instead of using one of the distributed binaries. See https://github.com/tgbugs/dockerfiles/blob/master/source.org#sbcl-bootstrap for reference. See also https://hub.docker.com/r/tgbugs/musl/tags?page=1&name=sbcl. Thus I'd very much appreciate if it sbcl were not masked on those profiles. Best, Tom
Re: [gentoo-dev] musl, sbcl, and ros
On Fri, 2 Dec 2022, Tom Gillespie wrote: For the record I've had sbcl building and running on musl for months without issue (at one point I even had static linking working). You have to cross compile a musl version and then side load the binary instead of using one of the distributed binaries. See https://github.com/tgbugs/dockerfiles/blob/master/source.org#sbcl-bootstrap for reference. See also https://hub.docker.com/r/tgbugs/musl/tags?page=1&name=sbcl. Yes. Either cross-compiling, or (with some luck) using some other lisp for bootstrap. Thus I'd very much appreciate if it sbcl were not masked on those profiles. The sbcl ebuild from the Gentoo tree is useless on musl. And hence it should be masked. Otherwise somebody would think that [s]he can simply emerge sbcl on a musl profile, and will be disappointed. Andrey
Re: [gentoo-dev] musl, sbcl, and ros
> The sbcl ebuild from the Gentoo tree is useless on musl. And hence it should be masked. Otherwise somebody would think that [s]he can simply emerge sbcl on a musl profile, and will be disappointed. Ah, I see. That makes sense, and I think I can just unmask it in my custom musl profile. Thanks! Tom
Re: [gentoo-dev] Question about python compatibility in dev-python/pathlib2
Hi, Pathlib2 is a backport, as such it doesn't really make sense to add 3.10 and 3.11 to compat. The package from the overlay probably should adjust its dependencies to only depend on pathlib2 when instaling for 3.9 or 3.8. This can be accomplished with the python_gen_cond_dep function (see docmenttion of python-r1.eclass). Best regards, Andrew On December 2, 2022 10:04:02 AM GMT+01:00, Martin Kletzander wrote: >Hi all, > >I noticed that a package from an overlay fails to install due to it >requiring pathlib2 with python_targets with 3.10 and/or 3.11. So I >checked pathlib2's setup.py [0] that it supports newer python versions >and wanted to update the ebuild, but noticed > >My question is whether I should: > >1) do some more research/work to bump the versions or > >2) update the upstream in case this is something deprecated order > >3) whether the updated ebuild with newer python versions should live in > the overlay instead. > >Thanks for any (non-null) pointers, >Martin > >[0] https://github.com/jazzband/pathlib2/blob/develop/setup.py#L39 >
Re: [gentoo-dev] Question about python compatibility in dev-python/pathlib2
Thanks, I now understand what pathlib2 does, but more importantly found out it is not really needed in that case making the fix even easier =) On Fri, Dec 02, 2022 at 11:35:06AM +0100, Andrew Ammerlaan wrote: Hi, Pathlib2 is a backport, as such it doesn't really make sense to add 3.10 and 3.11 to compat. The package from the overlay probably should adjust its dependencies to only depend on pathlib2 when instaling for 3.9 or 3.8. This can be accomplished with the python_gen_cond_dep function (see docmenttion of python-r1.eclass). Best regards, Andrew On December 2, 2022 10:04:02 AM GMT+01:00, Martin Kletzander wrote: Hi all, I noticed that a package from an overlay fails to install due to it requiring pathlib2 with python_targets with 3.10 and/or 3.11. So I checked pathlib2's setup.py [0] that it supports newer python versions and wanted to update the ebuild, but noticed My question is whether I should: 1) do some more research/work to bump the versions or 2) update the upstream in case this is something deprecated order 3) whether the updated ebuild with newer python versions should live in the overlay instead. Thanks for any (non-null) pointers, Martin [0] https://github.com/jazzband/pathlib2/blob/develop/setup.py#L39
Re: [gentoo-dev] Last rites: www-servers/boa
Michał Górny wrote: > > Shouldn't this process work a lot better? > > Processes tend to work better when people are contributing towards > making the processes work better rather than complaining from their > comfy armchairs that they tend to confuse with thrones. LOL! Are you honestly arguing that the Gentoo lastriting process relies on third party contributions to work or improve? That would amount to declaring Gentoo (developers) incapable of self-improvement, something that would be absolutely unacceptable to say about any one or any group of people. If you feel that Gentoo is unsustainable like that then please think about how you should react to it. Instead of writing a passive aggressive response to my demonstration of this process failure I wish that you would have drawn on your knowledge of the process and the learnings in my mail to 1. educate us on what gaps you see, if any, that caused this particular error, and maybe even 2. suggest some improvements. Expecting and/or demanding that from me because I dared describe a symptom and question the process is neither reasonable nor fair nor useful. Shooting the messenger reveals that you can't deal with the message, but that's a you problem, it's not okay to project that onto the messenger or anyone else. If you wanted to encourage me to become a Gentoo developer and (among other things) improve the lastriting process then you missed the mark, in fact your behavior consistently remains one strong reason for me to *not* become a Gentoo developer. Kind regards //Peter
Re: [gentoo-dev] Last rites: www-servers/boa
On Fri, Dec 2, 2022 at 12:20 PM Peter Stuge wrote: > If you wanted to encourage me to become a Gentoo developer and (among > other things) improve the lastriting process then you missed the mark, > in fact your behavior consistently remains one strong reason for me > to *not* become a Gentoo developer. I doubt that's the most significant thing standing in the way.
Re: [gentoo-dev] Last rites: www-servers/boa
So much yapping on the mailing lists, and no response in the bug which triggered the last rites... So, Peter, do you use Boa? If you do, what niche does it fill that isn't filled by anything else? There are multiple CVEs for it, is it really on us to discriminate between which CVEs are valid and which are not? We can't possibly hope to do that accurately in all cases. On Fri, Dec 02, 2022 at 05:20:40PM +, Peter Stuge wrote: > Michał Górny wrote: > > > Shouldn't this process work a lot better? > > > > Processes tend to work better when people are contributing towards > > making the processes work better rather than complaining from their > > comfy armchairs that they tend to confuse with thrones. > > LOL! > > Are you honestly arguing that the Gentoo lastriting process relies on > third party contributions to work or improve? That would amount to > declaring Gentoo (developers) incapable of self-improvement, something > that would be absolutely unacceptable to say about any one or any group > of people. > > If you feel that Gentoo is unsustainable like that then please think > about how you should react to it. > > > Instead of writing a passive aggressive response to my demonstration > of this process failure I wish that you would have drawn on your > knowledge of the process and the learnings in my mail to 1. educate > us on what gaps you see, if any, that caused this particular error, > and maybe even 2. suggest some improvements. > > Expecting and/or demanding that from me because I dared describe a > symptom and question the process is neither reasonable nor fair nor > useful. Shooting the messenger reveals that you can't deal with the > message, but that's a you problem, it's not okay to project that onto > the messenger or anyone else. > > > If you wanted to encourage me to become a Gentoo developer and (among > other things) improve the lastriting process then you missed the mark, > in fact your behavior consistently remains one strong reason for me > to *not* become a Gentoo developer. > > > Kind regards > > //Peter > signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: www-servers/boa
John Helmert III wrote: > So much yapping on the mailing lists, and no response in the bug which > triggered the last rites... Apologies if I responed in the wrong forum. I thought on list would be good, why are those mails on the list if not? > So, Peter, do you use Boa? Not right now, but I have before and I might again. > If you do, what niche does it fill that isn't filled by anything else? That's a strange question. Why should I agree with or even reconfigure because of something that is in fact an error? I ask you to revert the lastrite not because it would break a use case of mine but because the CVEs do not apply to boa itself but to some unknown appliance that uses boa to serve unknown buggy CGI scripts. > There are multiple CVEs for it, is it really on us to discriminate > between which CVEs are valid and which are not? Yes. You are obviously /not/ responsible for what bogus CVEs people may report, but we're all responsible for the commits we create. I assume that everyone wants to improve the overall state with each commit - that we want to make things more correct since that's what enables reliability, hence yes: it really is on every one of us to verify our inputs before taking action on them. > We can't possibly hope to do that accurately in all cases. Some times it will be easy, other times less easy. In this case the CVEs could be dismissed by searching the source code for the file names in the CVEs. Or by having experience with what the package provides, in particular that it doesn't include any CGI scripts. Maybe the accurate bigger picture is that no (current) Gentoo developer knows enough about the package and thus can't be expected to action such bogus CVEs correctly without a couple of minutes of investigation, which would be too long, then I guess maintainer-needed is the most honest? The mere existance of CVEs can not be reason enough for any change, that would mean resignation to fear instead of encouraging rational behavior as required to actually improve technology. It would also create incentive for permanent denial-of-service attacks by way of bogus CVEs manipulating people into incorrect lastrites and other changes. I don't want that to become common. My question about the lastriting process was not an attack but a genuine inquiry. The answer I receive so far is something like "it can't work better because we react indiscriminately to CVEs", that's an honest answer (thank you!) but not great quality. Does everyone mostly agree with that policy? Thanks //Peter
Re: [gentoo-dev] Last rites: www-servers/boa
On Fri, Dec 02, 2022 at 06:29:28PM +, Peter Stuge wrote: > John Helmert III wrote: > > So much yapping on the mailing lists, and no response in the bug which > > triggered the last rites... > > Apologies if I responed in the wrong forum. I thought on list would > be good, why are those mails on the list if not? > > > > So, Peter, do you use Boa? > > Not right now, but I have before and I might again. > > > > If you do, what niche does it fill that isn't filled by anything else? > > That's a strange question. Why should I agree with or even > reconfigure because of something that is in fact an error? > > I ask you to revert the lastrite not because it would break a use > case of mine but because the CVEs do not apply to boa itself but to > some unknown appliance that uses boa to serve unknown buggy CGI scripts. > > > > There are multiple CVEs for it, is it really on us to discriminate > > between which CVEs are valid and which are not? > > Yes. > > You are obviously /not/ responsible for what bogus CVEs people may > report, but we're all responsible for the commits we create. > > I assume that everyone wants to improve the overall state with each > commit - that we want to make things more correct since that's what > enables reliability, hence yes: it really is on every one of us to > verify our inputs before taking action on them. > > > > We can't possibly hope to do that accurately in all cases. > > Some times it will be easy, other times less easy. > > In this case the CVEs could be dismissed by searching the source code > for the file names in the CVEs. Or by having experience with what the > package provides, in particular that it doesn't include any CGI scripts. > > Maybe the accurate bigger picture is that no (current) Gentoo developer > knows enough about the package and thus can't be expected to action > such bogus CVEs correctly without a couple of minutes of investigation, > which would be too long, then I guess maintainer-needed is the most honest? No, when a package is believed to be vulnerable, it is not responsible for us to just leave it as maintainer-needed, that's not an accurate reflection of the situation. If you think the CVEs are invalid, maybe talk to upstream? Or MITRE? Or anybody that isn't only a CVE downstream? I also note that very few distributions package Boa: https://repology.org/project/boa/versions This is a good way to measure how many people care about the package (and thus, its security health). If the commercial distributions don't carry a package, nobody cares for it, and thus security issues are unlikely to be tracked and handled well. > The mere existance of CVEs can not be reason enough for any change, > that would mean resignation to fear instead of encouraging rational > behavior as required to actually improve technology. It would also > create incentive for permanent denial-of-service attacks by way of > bogus CVEs manipulating people into incorrect lastrites and other > changes. I don't want that to become common. That's not a real concern. We're not going to last rite something like nginx simply because there's a CVE against it. In the case of Boa, which doesn't seem to have been touched in approaching 20 years, the impact of last rites is minimal. > My question about the lastriting process was not an attack but a > genuine inquiry. The answer I receive so far is something like > "it can't work better because we react indiscriminately to CVEs", > that's an honest answer (thank you!) but not great quality. Does > everyone mostly agree with that policy? It generally can't work better with MITRE being useless in many cases. Yes, the CVEs seem garbage, but I can't say that authoritatively, so I don't. > > Thanks > > //Peter > signature.asc Description: PGP signature
Re: [gentoo-dev] musl, sbcl, and ros
Andrey Grozin wrote: > This means that no user of the musl profiles has ever been able to emerge > all these packages (because they did not have sbcl). And all these > packages should be pmasked in the musl profiles. Is the last sentence actually true? Shouldn't only ebuilds with actual problems be masked? Even if there's currently no possibility to emerge other packages which depend on that it seems incorrect to mask those other packages only because a dependency can't be emerged? I don't think portage cares; it will show sbcl masked if it is a dependency, right? Thanks //Peter
Re: [gentoo-dev] Last rites: www-servers/boa
John Helmert III wrote: > > > There are multiple CVEs for it, is it really on us to discriminate > > > between which CVEs are valid and which are not? > > > > Yes. .. > > > We can't possibly hope to do that accurately in all cases. > > > > Some times it will be easy, other times less easy. .. > > Maybe the accurate bigger picture is that no (current) Gentoo developer > > knows enough about the package and thus can't be expected to action > > such bogus CVEs correctly without a couple of minutes of investigation, > > which would be too long, then I guess maintainer-needed is the most honest? > > No, when a package is believed to be vulnerable, it is not responsible > for us to just leave it as maintainer-needed, that's not an accurate > reflection of the situation. Do you continue to believe that boa has vulnerabilites involving files and functionality (as mentioned by the maintainer mgorny in #882773#c1) which do not exist in the package? I wanted my mail to change that belief. If I've failed so far can you tell me how I can accomplish it, ie. what it would take for you to please revert the lastrite commit? > If you think the CVEs are invalid, maybe talk to upstream? Or MITRE? The CVEs are obviously invalid and yes someone could contribute time to clean up NVD but I honestly don't think that either upstream or myself can reasonably be made responsible for invalid CVEs submitted by third parties. > Or anybody that isn't only a CVE downstream? I expect every downstream of everything to apply themselves in order to improve quality of what they consume, not reduce it. To be clear: It's also not your job to improve NVD but at least don't lastrite in Gentoo because of invalid CVEs. > I also note that very few distributions package Boa: > > https://repology.org/project/boa/versions > > This is a good way to measure how many people care about the package > (and thus, its security health). I disagree, that's only a good way to measure how many distributions care. Each distribution has its own dynamic (but actually distributions also tend to herd behavior) and especially commercial distributions are more often than not bound by law to be driven only by profit, with *everything* else secondary. This includes software quality and/or "security health". > If the commercial distributions don't carry a package, nobody cares for > it, and thus security issues are unlikely to be tracked and handled well. This seems based on an assumption that only commercial software has high value? I could not disagree more with that. But if we play out the argument then CVEs for packages not in many distributions would more likely be invalid than others. While true in this case I don't find it convincing as a general conclusion. These things can all be true at once: 1. a package is secure 2. the package is not popular 3. a CVE for the package is invalid but not (yet) rejected 4. another CVE for the package is valid (low severity; still secure) Only 1. says something about "security health" (whatever that means). I think it's both irresponsible and wrong to indiscriminately give authority to CVEs. People are wrong on the internet all the time, some even intentionally, it's not correct to blindly believe CVEs any more than tweets. > > The mere existance of CVEs can not be reason enough for any change, > > that would mean resignation to fear instead of encouraging rational > > behavior as required to actually improve technology. > > That's not a real concern. We're not going to last rite something like > nginx simply because there's a CVE against it. In the case of Boa, > which doesn't seem to have been touched in approaching 20 years, the > impact of last rites is minimal. All packages are equal but some are more equal than others? ;) Again: Impact shouldn't matter, correctness should. > > The answer I receive so far is something like > > "it can't work better because we react indiscriminately to CVEs", > > that's an honest answer (thank you!) but not great quality. Does > > everyone mostly agree with that policy? > > It generally can't work better with MITRE being useless in many > cases. Yes, the CVEs seem garbage, but I can't say that > authoritatively, so I don't. What would convince you? Thanks a lot //Peter
Re: [gentoo-dev] Last rites: www-servers/boa
On Fri, Dec 2, 2022 at 12:30 PM Peter Stuge wrote: > > John Helmert III wrote: > > > > There are multiple CVEs for it, is it really on us to discriminate > > > > between which CVEs are valid and which are not? > > > > > > Yes. > .. > > > > We can't possibly hope to do that accurately in all cases. > > > > > > Some times it will be easy, other times less easy. > .. > > > Maybe the accurate bigger picture is that no (current) Gentoo developer > > > knows enough about the package and thus can't be expected to action > > > such bogus CVEs correctly without a couple of minutes of investigation, > > > which would be too long, then I guess maintainer-needed is the most > > > honest? > > > > No, when a package is believed to be vulnerable, it is not responsible > > for us to just leave it as maintainer-needed, that's not an accurate > > reflection of the situation. > > Do you continue to believe that boa has vulnerabilites involving files > and functionality (as mentioned by the maintainer mgorny in #882773#c1) > which do not exist in the package? > > I wanted my mail to change that belief. If I've failed so far can you > tell me how I can accomplish it, ie. what it would take for you to > please revert the lastrite commit? I'll repaint a narrative: Currently mgorny is the listed maintainer of boa. What if instead of a bunch of CVEs he just decided he had better things to do with his time. He last-rites the package, giving a 90d deadline for the package to find a new owner. No one cares to maintain boa, so no one steps up, and the package is removed after 90d. The fact is that in Gentoo, packages need a maintainer that will do the work to keep the package around. Packages that don't have maintainers have no advocate in the development community, and get removed. Gentoo has taken strides to make things easier (e.g. packages can move to GURU, or be proxy-maintained by community members and stay in ::gentoo.) However, the existing project structure gives maintainers and committers a lot of power to do ..basically whatever. I do not expect these facts to change. The last rights process relies on someone stepping up to care for the package. Either its you (and you find someone to commit your proxy commits), it's some other volunteer, or it's no one (in which case the package goes away.) > > > > If you think the CVEs are invalid, maybe talk to upstream? Or MITRE? > > The CVEs are obviously invalid and yes someone could contribute time > to clean up NVD but I honestly don't think that either upstream or > myself can reasonably be made responsible for invalid CVEs submitted > by third parties. > > > > Or anybody that isn't only a CVE downstream? > > I expect every downstream of everything to apply themselves in order to > improve quality of what they consume, not reduce it. To be clear: It's > also not your job to improve NVD but at least don't lastrite in Gentoo > because of invalid CVEs. > > > > I also note that very few distributions package Boa: > > > > https://repology.org/project/boa/versions > > > > This is a good way to measure how many people care about the package > > (and thus, its security health). > > I disagree, that's only a good way to measure how many distributions care. > > Each distribution has its own dynamic (but actually distributions also > tend to herd behavior) and especially commercial distributions are more > often than not bound by law to be driven only by profit, with *everything* > else secondary. This includes software quality and/or "security health". I think the current state is that no one with commit access to ::gentoo cares, so it will be removed unless someone changes their mind. > > > > If the commercial distributions don't carry a package, nobody cares for > > it, and thus security issues are unlikely to be tracked and handled well. > > This seems based on an assumption that only commercial software has > high value? I could not disagree more with that. > > But if we play out the argument then CVEs for packages not in many > distributions would more likely be invalid than others. While true > in this case I don't find it convincing as a general conclusion. > > These things can all be true at once: > > 1. a package is secure > 2. the package is not popular > 3. a CVE for the package is invalid but not (yet) rejected > 4. another CVE for the package is valid (low severity; still secure) > > Only 1. says something about "security health" (whatever that means). > > I think it's both irresponsible and wrong to indiscriminately give > authority to CVEs. People are wrong on the internet all the time, > some even intentionally, it's not correct to blindly believe CVEs > any more than tweets. > > > > > The mere existance of CVEs can not be reason enough for any change, > > > that would mean resignation to fear instead of encouraging rational > > > behavior as required to actually improve technology. > > > > That's not a real concern. We're not going to last rite something like > > n
Re: [gentoo-dev] Last rites: www-servers/boa
On Fri, Dec 02, 2022 at 08:30:03PM +, Peter Stuge wrote: > John Helmert III wrote: > > > > There are multiple CVEs for it, is it really on us to discriminate > > > > between which CVEs are valid and which are not? > > > > > > Yes. > .. > > > > We can't possibly hope to do that accurately in all cases. > > > > > > Some times it will be easy, other times less easy. > .. > > > Maybe the accurate bigger picture is that no (current) Gentoo developer > > > knows enough about the package and thus can't be expected to action > > > such bogus CVEs correctly without a couple of minutes of investigation, > > > which would be too long, then I guess maintainer-needed is the most > > > honest? > > > > No, when a package is believed to be vulnerable, it is not responsible > > for us to just leave it as maintainer-needed, that's not an accurate > > reflection of the situation. > > Do you continue to believe that boa has vulnerabilites involving files > and functionality (as mentioned by the maintainer mgorny in #882773#c1) > which do not exist in the package? Just like it isn't your responsibility to "cleanup NVD", it's not my responsibility to authoritatively verify every CVE that Gentoo Security acts upon. Even if I did make such a judgement, I will *not* risk my being wrong and exposing Gentoo users to vulnerabilities unecessarily, even when prompted to by users on mailing lists. > I wanted my mail to change that belief. If I've failed so far can you > tell me how I can accomplish it, ie. what it would take for you to > please revert the lastrite commit? I (or smoeone else) will drop the last rites message when the package is removed. > > > If you think the CVEs are invalid, maybe talk to upstream? Or MITRE? > > The CVEs are obviously invalid and yes someone could contribute time > to clean up NVD but I honestly don't think that either upstream or > myself can reasonably be made responsible for invalid CVEs submitted > by third parties. Again, we're not making judgements about "obviously invalid". The time you've spent arguing with us on gentoo-dev could've been easily spent asking upstream about the issue. > > Or anybody that isn't only a CVE downstream? > > I expect every downstream of everything to apply themselves in order to > improve quality of what they consume, not reduce it. To be clear: It's > also not your job to improve NVD but at least don't lastrite in Gentoo > because of invalid CVEs. > > > > I also note that very few distributions package Boa: > > > > https://repology.org/project/boa/versions > > > > This is a good way to measure how many people care about the package > > (and thus, its security health). > > I disagree, that's only a good way to measure how many distributions care. Which is *precisely* the point I'm making. If distributions with many times the resources of Gentoo don't care to package it, that's a bad indicator of how well the package is taken care of. > Each distribution has its own dynamic (but actually distributions also > tend to herd behavior) and especially commercial distributions are more > often than not bound by law to be driven only by profit, with *everything* > else secondary. This includes software quality and/or "security health". > > > > If the commercial distributions don't carry a package, nobody cares for > > it, and thus security issues are unlikely to be tracked and handled well. > > This seems based on an assumption that only commercial software has > high value? I could not disagree more with that. Nope, not the point I was making. See above. > But if we play out the argument then CVEs for packages not in many > distributions would more likely be invalid than others. While true > in this case I don't find it convincing as a general conclusion. > > These things can all be true at once: > > 1. a package is secure > 2. the package is not popular > 3. a CVE for the package is invalid but not (yet) rejected > 4. another CVE for the package is valid (low severity; still secure) > > Only 1. says something about "security health" (whatever that means). > > I think it's both irresponsible and wrong to indiscriminately give > authority to CVEs. People are wrong on the internet all the time, > some even intentionally, it's not correct to blindly believe CVEs > any more than tweets. > > > > > The mere existance of CVEs can not be reason enough for any change, > > > that would mean resignation to fear instead of encouraging rational > > > behavior as required to actually improve technology. > > > > That's not a real concern. We're not going to last rite something like > > nginx simply because there's a CVE against it. In the case of Boa, > > which doesn't seem to have been touched in approaching 20 years, the > > impact of last rites is minimal. > > All packages are equal but some are more equal than others? ;) > > Again: Impact shouldn't matter, correctness should. And again, I'm generally not going to be validating every CVE ever for c
Re: [gentoo-dev] musl, sbcl, and ros
> On 2 Dec 2022, at 19:28, Peter Stuge wrote: > > Andrey Grozin wrote: >> This means that no user of the musl profiles has ever been able to emerge >> all these packages (because they did not have sbcl). And all these >> packages should be pmasked in the musl profiles. > > Is the last sentence actually true? > > Shouldn't only ebuilds with actual problems be masked? > > Even if there's currently no possibility to emerge other packages > which depend on that it seems incorrect to mask those other packages > only because a dependency can't be emerged? No, that's not how it works, because right now, you can end up with something that depends on sbcl on a musl system where you can't actually install it. signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] musl, sbcl, and ros
On Fri, Dec 2, 2022 at 11:28 AM Peter Stuge wrote: > > Andrey Grozin wrote: > > This means that no user of the musl profiles has ever been able to emerge > > all these packages (because they did not have sbcl). And all these > > packages should be pmasked in the musl profiles. > > Is the last sentence actually true? > > Shouldn't only ebuilds with actual problems be masked? > > Even if there's currently no possibility to emerge other packages > which depend on that it seems incorrect to mask those other packages > only because a dependency can't be emerged? > > I don't think portage cares; it will show sbcl masked if it is a > dependency, right? The project has a (somewhat implicit) goal to prefer installable depgraphs. We use software like pkgcheck to verify these (and there are CI failures if the depgraph is broken, and we make developers fix such things.) So if we had like, A -> B -> C, and C is profile-masked on some profile, we should be masking A and B (so we avoid users seeing a broken depgraph.) You might think "well I see A -> B[foo] all the time, and portage will make me set USE=foo on B." This is generally true except: - Oftentimes if this is a sane default, B will have USE="+foo" (e.g. foo will be on by default) and this requirement will not be visible to users. - USE flags are intended to be toggled and most USE flag values are supported by Gentoo (except for REQUIRED_USE restrictions.) - Portage has an autounmask flag that will configure things so B is installable (by flipping foo on for you); but this function does not exist for profile-masks. We do not expect users to "undo" profile-masks, so when things are profile-masked we value the user experience (if X is visible, X should be installable) rather than minimal masking. -A > > > Thanks > > //Peter >
Re: [gentoo-dev] Last rites: www-servers/boa
Alec Warner wrote: > Currently mgorny is the listed maintainer of boa. What if instead of a > bunch of CVEs he just decided he had better things to do with his > time. > He last-rites the package, giving a 90d deadline for the package to > find a new owner. > No one cares to maintain boa, so no one steps up, and the package is > removed after 90d. That would be perfectly fine of course. Note that mgorny protested in the lastrite bug way before my mail. > I think the current state is that no one with commit access to > ::gentoo cares, so it will be removed unless someone changes their > mind. That seems accurate. John Helmert III wrote: > > Do you continue to believe that boa has vulnerabilites involving files > > and functionality (as mentioned by the maintainer mgorny in #882773#c1) > > which do not exist in the package? > > Just like it isn't your responsibility to "cleanup NVD", it's not my > responsibility to authoritatively verify every CVE that Gentoo > Security acts upon. Of course not by others in Gentoo Security, but I think it is for inputs that you yourself act on. (Everyone of course and I am mindful to do it too.) > Even if I did make such a judgement, I will *not* risk my being > wrong and exposing Gentoo users to vulnerabilities unecessarily, > even when prompted to by users on mailing lists. Your nginx example seemed to say otherwise. It's good to be afraid of being wrong but then please work with trusted peers to feel confident about being right instead of racing to bottom quality. Since you don't trust my analysis of both versions of the source code published by upstream please do collect further analysis from peers, so as to not be wrong in the opposite. > > The CVEs are obviously invalid and yes someone could contribute time > > to clean up NVD but I honestly don't think that either upstream or > > myself can reasonably be made responsible for invalid CVEs submitted > > by third parties. > > Again, we're not making judgements about "obviously invalid". I do think Gentoo Security needs to validate. *scratches head* This is obviously the most interesting part of this thread. > The time you've spent arguing with us on gentoo-dev could've been > easily spent asking upstream about the issue. I verified the three CVEs to be non-issues, what is there for me to ask upstream about? I analyzed the source code before sending my first mail and confirmed that the CVEs do not exist in boa. That's why I sent the mail saying that the reports are false. A lastrite commit in Gentoo based on invalid CVEs has little to do with upstream. You're reversing the burden of proof based on a false claim. > > I disagree, that's only a good way to measure how many distributions care. > > Which is *precisely* the point I'm making. If distributions with many > times the resources of Gentoo don't care to package it, that's a bad > indicator of how well the package is taken care of. How can you know why someone else does or *doesn't* do something? That's absurd. > > Each distribution has its own dynamic (but actually distributions also > > tend to herd behavior) You really leaned into the herd behavior there. :\ > > Again: Impact shouldn't matter, correctness should. > > And again, I'm generally not going to be validating every CVE ever for > correctness. Only those you act on. > > > It generally can't work better with MITRE being useless in many > > > cases. Yes, the CVEs seem garbage, but I can't say that > > > authoritatively, so I don't. > > > > What would convince you? > > Anything from upstream, or a withdrawal of the CVEs, or a notice from > the CVE reproters that they're invalid. But I really don't understand > why anybody cares about this leaf package that nobody actually seems > to use, including you. Imagine that I fork boa to a project called boah, change nothing but the version number, create a release and then tell you again that the three CVEs are invalid for both boa and boah. //Peter
[gentoo-dev] Last rites: x11-themes/mate-themes-meta
# Oz Tiram (2022-12-03) # Mate-desktop no longer supports gtk+:2, so there is # no need for this package. Removal on 2023-01-03. x11-themes/mate-themes-meta signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] musl, sbcl, and ros
[2022-12-02 05:11:15+] Andrey Grozin: In principle, one can try a workaround: use some other lisp (say, clisp or ecl) as the bootstrap lisp. This way is at best brittle: there is no guarantee that these external lisps will compile the sbcl sources successfully. People say that sometimes this works. Well Alpine is using the ecl route: https://git.alpinelinux.org/aports/tree/community/sbcl/APKBUILD And GNU GuixSD is using the clisp route but per the comments ecl would be better: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/lisp.scm#n424
Re: [gentoo-dev] musl, sbcl, and ros
On Sat, 2022-12-03 at 02:59 +0100, Haelwenn (lanodan) Monnier wrote: > [2022-12-02 05:11:15+] Andrey Grozin: > > In principle, one can try a workaround: use some other lisp (say, clisp or > > ecl) as the bootstrap lisp. This way is at best brittle: there is no > > guarantee that these external lisps will compile the sbcl sources > > successfully. People say that sometimes this works. > > Well Alpine is using the ecl route: > https://git.alpinelinux.org/aports/tree/community/sbcl/APKBUILD ECL is a good choice. Upstream is active and friendly. but: The current and only version of ECL in the tree has a bug that makes it unusable for compiling SBCL: * https://bugs.launchpad.net/sbcl/+bug/1956852 * https://gitlab.com/embeddable-common-lisp/ecl/-/issues/667 A fix was committed, but there hasn't been a new release yet.
Re: [gentoo-dev] musl, sbcl, and ros
On Sat, 3 Dec 2022, Haelwenn (lanodan) Monnier wrote: Well Alpine is using the ecl route: https://git.alpinelinux.org/aports/tree/community/sbcl/APKBUILD And GNU GuixSD is using the clisp route but per the comments ecl would be better: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/lisp.scm#n424 In principle, we can do something similar: 1. If elibc_musl, sbcl should BDEPEND on ecls (or maybe clisp) 2. In the same case, the build system should be patched to use another bootstrap lisp 3. For elibc_glibc nothing should change 4. All this should be tested on a computer running a musl profile Personally I can do nothing of this list. I have no computer with musl profile. Does any developer running such a system volunteer to do this work - to be a co-maintained of sbcl on musl? If not, I'll go forward and pmask all packages which unconditionally depend on sbcl (maybe via some intermediates) in profiles/features/musl/use.mask. Andrey
[gentoo-dev] [PATCH] app-alternatives.eclass: New eclass to streamline app-alternatives/*
Signed-off-by: Michał Górny
---
eclass/app-alternatives.eclass | 84 ++
1 file changed, 84 insertions(+)
create mode 100644 eclass/app-alternatives.eclass
PR with examples: https://github.com/gentoo/gentoo/pull/28515
diff --git a/eclass/app-alternatives.eclass b/eclass/app-alternatives.eclass
new file mode 100644
index ..69315e4bc985
--- /dev/null
+++ b/eclass/app-alternatives.eclass
@@ -0,0 +1,84 @@
+# Copyright 2022 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: app-alternatives.eclass
+# @MAINTAINER:
+# Michał Górny
+# @AUTHOR:
+# Michał Górny
+# @SUPPORTED_EAPIS: 8
+# @BLURB: Common logic for app-alternatives/*
+# @DESCRIPTION:
+# This eclass provides common logic shared by app-alternatives/*
+# ebuilds. A global ALTERNATIVES variable needs to be declared
+# that lists available options and their respective dependencies.
+# HOMEPAGE, S, LICENSE, SLOT, IUSE, REQUIRED_USE and RDEPEND are set.
+# A get_alternative() function is provided that prints the determines
+# the selected alternative and prints its respective flag name.
+
+case ${EAPI} in
+ 8) ;;
+ *) die "${ECLASS}: EAPI ${EAPI} unsupported."
+esac
+
+if [[ ! ${_APP_ALTERNATIVES_ECLASS} ]]; then
+_APP_ALTERNATIVES_ECLASS=1
+
+# @ECLASS_VARIABLE: ALTERNATIVES
+# @PRE_INHERIT
+# @REQUIRED
+# @DESCRIPTION:
+# Array of "flag:dependency" pairs specifying the available
+# alternatives. The default provider must be listed first.
+
+# @FUNCTION: _app-alternatives_set_globals
+# @INTERNAL
+# @DESCRIPTION:
+# Set ebuild metadata variables.
+_app-alternatives_set_globals() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ if [[ $(declare -p ALTERNATIVES) != "declare -a"* ]]; then
+ die 'ALTERNATIVES must be an array.'
+ elif [[ ${#ALTERNATIVES[@]} -eq 0 ]]; then
+ die 'ALTERNATIVES must not be empty.'
+ fi
+
+ HOMEPAGE="https://wiki.gentoo.org/wiki/Project:Base/Alternatives";
+ S=${WORKDIR}
+
+ LICENSE="CC0-1.0"
+ SLOT="0"
+
+ # yep, that's a cheap hack adding '+' to the first flag
+ IUSE="+${ALTERNATIVES[*]%%:*}"
+ REQUIRED_USE="^^ ( ${ALTERNATIVES[*]%%:*} )"
+ RDEPEND=""
+
+ local flag dep
+ for flag in "${ALTERNATIVES[@]}"; do
+ [[ ${flag} != *:* ]] && die "Invalid ALTERNATIVES item: ${flag}"
+ dep=${flag#*:}
+ flag=${flag%%:*}
+ RDEPEND+="
+ ${flag}? ( ${dep} )
+ "
+ done
+}
+_app-alternatives_set_globals
+
+# @FUNCTION: get_alternative
+# @DESCRIPTION:
+# Get the flag name for the selected alterantive (i.e. the USE flag set).
+get_alternative() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ local flag
+ for flag in "${ALTERNATIVES[@]%%:*}"; do
+ usev "${flag}" && return
+ done
+
+ die "No selected alternative found (REQUIRED_USE ignored?!)"
+}
+
+fi
--
2.38.1
[gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
Hi, I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug states with a simple NEW state. Why? 1. Only a handful of developers actually uses these two statuses in a meaningful way. 2. Some users are confused and demotivated by having their bugs stay UNCONFIRMED for a long time. -- Best regards, Michał Górny
[gentoo-dev] Last rites: dev-ruby/rspec-retry
# Hans de Graaff (2022-12-03) # ruby27-only packages. No recent releases. No reverse dependencies # anymore. Maksed for removal in 30 days. dev-ruby/rspec-retry signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Removing the distinction between UNCONFIRMED and CONFIRMED bugs
> On 3 Dec 2022, at 07:09, Michał Górny wrote: > > Hi, > > I'd like to propose replacing the current UNCONFIRMED and CONFIRMED bug > states with a simple NEW state. Why? > > 1. Only a handful of developers actually uses these two statuses > in a meaningful way. > > 2. Some users are confused and demotivated by having their bugs stay > UNCONFIRMED for a long time. > Yes please. We can always revisit if an actual issue arises wrt needing to show things as "CONFIRMED", but I've not seen any usage of UNCONFIRMED vs CONFIRMED in a way that matters other than helping out confused users. While at it, I'd love to talk about UPSTREAM [0] , but that's for another day :) [0] https://archives.gentoo.org/gentoo-project/message/a16cedda9f4b3f8d88e3291d5d0201da best. sam signature.asc Description: Message signed with OpenPGP
