Re: [gentoo-dev] RFC: banning "AI"-backed (LLM/GPT/whatever) contributions to Gentoo
Am Dienstag, 27. Februar 2024, 18:50:15 CET schrieb Roy Bamford: > On 2024.02.27 14:45, Michał Górny wrote: > > Hello, > > > > [...] > > > > Gentoo has always stood out as something different, something that > > worked for people for whom mainstream distros were lacking. I think > > adding "made by real people" to the list of our advantages would be > > a good thing — but we need to have policies in place, to make sure > > shit > > doesn't flow in. > > > > Compare with the shitstorm at: > > https://github.com/pkgxdev/pantry/issues/5358 > > Michał, > > An excellent piece of prose setting out the rationale. > I fully support it. I would like to add the following: Last year we had a chatbot in our Gentoo forum that posted 76 posts on 2024-12-19. An inexperienced moderator (me) then asked his colleagues on the basis of which forum rules we can ban this chatbot: "Do we have a rule somewhere that an AI and a chatbot are not allowed to log in? I have read our Guideĺines ( https://forums.gentoo.org/viewtopic-t-525.html ) and found no such prohibition. On what basis could we even block a chatbot ?" The answer from two experienced colleagues was that this is already covered by our forum rules, because chatbots usually cannot (yet) fulfill the requirements of a forum post and therefore violate our Guideĺines. To be honest, I asked myself at the time what would happen if we had a clearly recognizable AI as a user that made (reasonably) sensible posts. We would then have no chance of banning this AI user without an explicit prohibition. I would be much more comfortable if we clearly communicated that we do not accept an AI as a user. Yes, I would also be very happy to see this proposal implemented. -- Best regards, Peter (aka pietinger)
Re: [gentoo-dev] [PATCH] 2024-01-02-separate-usr-now-requires-an-initramfs: add news item
Hello Eli, Maybe add also a link to: https://wiki.gentoo.org/wiki/Early_Userspace_Mounting (IMHO this article is a better starting point than https://wiki.gentoo.org/wiki/Custom_Initramfs ) Many Greetings, Peter
Re: [gentoo-dev] Gentoo LTS or: proper backward compatibility?
m1027 wrote: > Wow, wasn't aware of catalyst at all. What a beast in terms of control. It's not so well-known maybe because it was created by and for gentoo-releng but if you know what you want it's a fantastic tool. > (FYI: I enjoyed the links on catalyst you sent me directly. > Unfortunatelly I cannot answer you directly due to the default > TLS guarantee Thanks! Glad you liked them. And yes, TLS is on my list. > While being able to build exact environments with catalyst I wonder > how it could help fixing the issue of my original post. Thank you for connecting back to the original post! Let's see: > Whenever we need to deliver a updated app to customers whose OS is > too old (but updating it is too risky), we could either > a) keep evenly outdated dev build OSes around forever (oh no!), or > b) post our newly built app in a container (leaving the lovely native > world); and both ignore the fact that customers wish maintenance of > the entire OS actually, too. > So, ideally, there is c): In a hypothetic case we would prepare a > entire OS incl. our app (maybe via catalyst?) which would require > a bootloader-like mini-OS on the customer's side, to receive updates > over the internet, switch the OS at boot time, and fallback. I had a) in mind. Why "oh no!" ? I didn't mean forever. I think it's already a very good value proposition that you can deliver updates of your apps for the particular systems that your customers run. catalyst building specific, "old-like" OSes on which you build new (binpkg) versions of your app to be installable by emerge on old customer OSes is admittedly a lot of work, at least initially. Separate from those app updates you can then use catalyst to also tackle OS maintenance/updates. You can create either full milestone OSes or just individual (binpkg) packages through which customers' OSes can become less fragmented over time, at the pace each customer is comfortable with. OS updates can take only small steps at a time, since catalyst allows exact control. This could reduce target OS diversity drastically over time with probably relatively moderate development effort. More effort might go into holding customer hands along the bespoke update paths. So, I see controlled paths forward in both problem dimensions. I don't know if the effort is actually practical for you but it /is/ doable and most importantly it can be customized for the individual systems currently in production at your customers. //Peter
Re: [gentoo-dev] Gentoo LTS or: proper backward compatibility?
Peter Stuge wrote: > Essentially you will be maintaining a private fork of gentoo.git, If this seems too heavy handed then you can just as well do the reverse: Maintain an overlay repo with the packages you care to control in the state you care to have them, set that in the catalyst stage4.spec portage_overlay and add unwanted package versions in gentoo.git to the package.mask directory used by catalyst. This may sound complicated but it isn't bad at all. For total control also make your own profile, e.g. based on embedded, but that's not per se neccessary, only if the standard profiles has too much conflicts with what you want in @system. catalyst will rebuild @system according to spec file but with too much difference that just becomes annoying and feels more trouble than a controlled profile. This approach falls somewhere between your options (1) and (5). Good luck! //Peter
Re: [gentoo-dev] Gentoo LTS or: proper backward compatibility?
Hi, m1027 wrote: > So, what we've thought of so far is: > > (1) Keeping outdated developer boxes around and compile there. We > would freeze portage against accidental emerge sync by creating a > git branch in /var/db/repos/gentoo. This feels hacky and requires a > increating number of develper VMs. And sometimes we are hit by a > silent incompatibility we were not aware of. .. > (5) Inventing a full fledged OTA Gentoo OS updater and distribute > that together with the apps... Nah. > > Hm... Comments welcome. I recommend taking ownership (and responsibility) of your OS. Gentoo tooling (catalyst) is really fantastic for doing so. Essentially you will be maintaining a private fork of gentoo.git, but one where you only really need to manually process the packages you care to control, only when you care to control them. Use catalyst to build tarballs (and binpkgs) from snapshots of that repo. emerge can install binpkg at least from FTP. //Peter
Re: [gentoo-dev] New category: media-print/
Hi Marco, mscard...@icloud.com wrote: > Looking at packages seems there’s not any package strictly related > to net (tell me if You think some of these should remains to it). .. > things more common-used like cups). cups certainly has a network component both as server and as client. It's one of a few different methods (by far the most common) to access networked printers so it may not be so misplaced in net-print. //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
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] 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: > 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
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
John Helmert III wrote: > # John Helmert III (2022-11-27) > # Unmaintained upstream, several unresolved public vulnerabilities, > # Removal in 30 days. Bug #882773. > www-servers/boa This is bogus, please revert. Who are you to declare unmaintained? It's a simple program so maybe it simply needs no further change. Anyway, none of the three CVEs you list in #882773 are valid. CVE-2022-44117 is an empty claim with no detail at all. And as mgorny points out, boa does not have anything to do with SQL. CVE-2021-33558 and CVE-2017-9833 refer to issues in applications or appliances which use boa. They have nothing to do with boa itself. The named files do not exist in the boa package. Shouldn't this process work a lot better? Thanks //Peter
Re: [gentoo-dev] Last rites: net-mail/vchkuser
John Helmert III wrote: > > Searching for the repo name on GitHub finds this however: > > > > https://github.com/bdrewery/vchkuser > > > > ..which seems to be a 2010 version of the code. I did a test, it works > > fine. Maybe just change the SRC_URI. > > Can you produce a guarantee that the code there is equal to the code > which the ebuild currently refers to? Or maybe that it's equivalent to > the now-removed repository? Git thinks so. I unpacked vchkuser-0.4.tar.gz from a Gentoo mirror on top of a bdrewery/vchkuser checkout and: $ git status # On branch master nothing to commit, working directory clean $ The v0.4 tag in bdrewery/vchkuser also equals the commit hash in the directory name of the .tar.gz. (This is of course weak.) //Peter
Re: [gentoo-dev] Last rites: net-mail/vchkuser
John Helmert III wrote: > > Jonas Stein wrote: > > > # Dead upstream > > > # Removal after 2023-01-01. Bug #881249. > > > net-mail/vchkuser > > > > Was there an actual issue with the package that prompted you to do > > this - something that a package maintainer should have resolved? > > > > I think it's a bad idea to remove a package if "Upstream Homepage and > > SRC_URI is gone" and "Gentoo is the last distro with this package" > > are the only reasons... > > Do you use it? Is it still functional? I don't use it, I use something else for the same task. Looking up the GitHub user that person seems present, just that particular repo is no longer there. Searching for the repo name on GitHub finds this however: https://github.com/bdrewery/vchkuser ..which seems to be a 2010 version of the code. I did a test, it works fine. Maybe just change the SRC_URI. //Peter
Re: [gentoo-dev] Last rites: net-mail/vchkuser
Jonas Stein wrote: > # Dead upstream > # Removal after 2023-01-01. Bug #881249. > net-mail/vchkuser Was there an actual issue with the package that prompted you to do this - something that a package maintainer should have resolved? I think it's a bad idea to remove a package if "Upstream Homepage and SRC_URI is gone" and "Gentoo is the last distro with this package" are the only reasons... Thanks //Peter
Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt
Mikhail Koliada wrote: > This idea has been fluctuating in my head for quite a while given > that the migration had happened a while ago [0] and some other > major distributions have already adopted yescrypt as their default algo > by now [1]. Please only do that based on proven merit and nothing else. Fedora or anyone else for that matter making a change is a truly terrible reason to take any action whatsoever, since other organizations are driven by /their/ interests - with Fedora in particular being driven by the business interests of Red Hat. I consider Gentoo a leader in many regards and it makes me really sad whenever Gentoo changes based on nothing more than "others did it". Thanks and kind regards //Peter
Re: [gentoo-dev] Deprecating repoman
Matt Turner wrote: > repoman is inferior to other tooling mentioned. The other tooling is > actually run in CI. The problem seems to be that CI is running something other than developers run, not the other way around. > Developers should get the same warnings locally as in CI. I agree. And developers and their tools should not have to bend to whatever CI does, I think the other way around makes more sense. CI doesn't use repoman because of performance issues. What if pkgcore evolves to provide a portage-compatible API? Then CI could use repoman without performance problems, and developers would also enjoy improved performance, without spending time on replacing tooling which already works for them. Looking into the future then maybe portage could even come to use pkgcore for the low-level things that pkgcore does, then even users could enjoy improved performance. Right? //Peter
Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust
Dear Developers, I like your goal to make Gentoo more user-friendly but Gentoo is a source based distribution and I dont like binary versions as a default. My question is: Who has problems with "big" packages like rust or firefox ? Only User which doesnt know there is a binary version. So, in every case we need to describe it in our AMD64 handbook. Am Freitag, 21. Januar 2022, 10:22:14 CET schrieb Mart Raudsepp: > Anyhow, my vote is to default to rust-bin - people can easily be told > to move to dev-lang/rust at their convenience and then explicitly > depclean rust-bin. I am dreaming about another solution where this is not needed: In our /etc/portage/make.conf we can have a new: MAKEBIN="rust firefox" ... resulting in an automatic switch to the binary version of all included packages ... of course this is also as recommendation in our AMD64 handbook (with a clue to delete it if not desired). Kind reagards, Peter
Re: [gentoo-dev] Maintainer needed: dev-db/sqlite
Mike Gilbert wrote: > The current (proxied) maintainer is somewhat difficult to work with Why is Arfrever being treated so bad here? To me, it looks like you're the one who is difficult to work with. :\ Jakov Smolić wrote: > From what I've investigated, other major distributions don't apply > any similar patches which means that we are likely to stop carrying > most (or even all) of the current patches. What kind of silly groupthink is this? I expect Gentoo to champion choice. Mike Gilbert wrote: > There is an open QA bug [1] regarding the large set of undocumented > patches that are being applied in the stable ebuilds. Arfrever is active in the bug you linked, has provided explanations for the patches and prepared to restructure the patches so that they can be gated by local USE flags, has made several different concrete suggestions for possible implementations and requested feedback, but has received no reply in the bug and instead there's now this backstabbing discussion on this list. Really? //Peter
Re: [gentoo-dev] Guidance on adding kernel config checks to ebuilds
Mike Gilbert wrote: > > > It's a waste of time and effort to pepper random ebuilds with checks > > > for options that everyone should have enabled in the first place. > > > > It's not for you to say what everyone should have enabled in their kernel. > > Do you not agree that there are some options that should always be > enabled, or at least that we can assume are enabled? "Should be enabled" no, but I agree with the latter - some assumed set should be fine. I think it would be good if it's (somehow) documented though. > To use my earlier example, should every package that uses AF_INET > check for CONFIG_INET in the kernel? CONFIG_INET is a perhaps surprisingly tricky example! A package could e.g. use getaddrinfo() with no address family hint but because of USE=-ipv6 exclude all AF_INET6 address results and so end up using AF_INET based on whether it's available in the running kernel or even based on third party DNS entries. I'm not sure about the best approach for very basic options, CONFIG_NET could be another such candidate. Thinking towards robbat2's proposal (which I like) it might make sense to try to map requirements of packages, but there will probably be cases where it can't really be done successfully. Ultimately that work should not be the responsibility of distribution package maintainers but something upstreams deliver, similar to systemd units, but maybe we'll invent it (if noone else has).. //Peter
Re: [gentoo-dev] moving kernel config checks forward: potential config checking tool
Robin H. Johnson wrote: > We have some set of packages (A) which collectively depend on one or > more kernel options being set in specific ways, and the options need to > REMAIN set if you want the packages to continue work. .. > Can we consider moving the checks for set A somewhere else, such that we > don't check the kernel config during package compile & install time, but > only check it later? I only see one problem with this; that USE flags could influence which kernel options are required, which would be useful to know at/before compile time. > It would need to keep long-term state about which packages want > specific options set/unset/modular, as well as short-term state > about the config from each boot. It's a cool idea. A standardized solution would be quite nice for the whole Linux ecosystem. //Peter
Re: [gentoo-dev] Guidance on adding kernel config checks to ebuilds
Mike Gilbert wrote: > It's a waste of time and effort to pepper random ebuilds with checks > for options that everyone should have enabled in the first place. It's not for you to say what everyone should have enabled in their kernel. There's significant value in ebuilds documenting required kernel options in a structured manner. So I welcome simplifications in the checking to achieve millisecond test times. But the benefit of structured requirements is given even without any runtime checking at all, as long as required options continue to be codified /somehow/. Thank you for your work! //Peter
Re: [gentoo-dev] Guidance on distributed patented software
Joshua Kinard wrote: > > I'm not entirely sure what you'd like to ask the libtomcrypt authors. > > "We think there may be patents, but we don't know. Did you consider > > that?" > > No, actually, I was thinking something more along the lines of "Hey, are you > aware of these supposed patent claims about ECC/ECDSA implementations that > Red Hat says exist, and if so, did you do any research on them that you > could possibly share that led you to feeling confident to release your > implementation into the public domain". > > But I am open to better language. There's not neccessarily a conflict between a patented idea and a public domain implementation of that idea. Take a fictional example: You and I independently invent the same thing. You patent it, then write and publish an LGPL implementation. I, ignorant of your accomplishment, later write and publish a different implementation, placing it in the public domain. You having a patent doesn't neccessarily matter to me publishing my implementation. It can be problematic for *users*. They might violate your patent terms (or not; it depends on your terms in the patent) if they use *any* implementation without having licensed the right to use your patented idea from you. (Of course only until your patent expires.) What users have to do is determined by the terms set forth in the patent. E.g.: the QR-code patent has (I believe) not expired yet but has always permitted using the idea without any explicit license under the condition that all use is actually spec conformant. The license for a software isn't connected to patents unless it explicitly states so, like GPL-3 Section 11 or Apache-2.0 Section 3. Public domain has no license text, so can have no such language. :) You seem to expect some due diligence from libtomcrypt authors before having decided to publish their work and I don't find that reasonable. I hope I've managed to explain why? Kind regards //Peter
Re: [gentoo-dev] Guidance on distributed patented software
Joshua Kinard wrote: > Hmm, it looks like dropbear is relying heavily on the ecc/ecdsa functions > provided in libtomcrypt, and that library's homepage states all its code is > public domain. Our ebuild has no bindist restrictions on that library. > Perhaps that is how dropbear, and thus Red Hat, avoids the issues with > licensing or patents? Licenses apply to implementations and patents apply to inventions/ideas. A software license can allow you to theoretically use an implementation while a patent says no you can't without licensing that right separately. The reverse is equally possible; an expired patent means that using the invention/idea is not restricted by the patent anymore, but there may still be no free/open source implementation (yet). AIUI USE=-bindist is all three variants (swlicense_says_no || patent_says_no) while USE=bindist promises that (swlicense_says_yes && patent_says_yes) is guaranteed to be true at the cost of functionality? //Peter
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
Sam James wrote: > > https://www.fsfla.org/pipermail/linux-libre/2020-August/003404.html > > > > it seems that it may be possible to need only very simple tools for the > > deblob program(s). > > Instead of linking to a huge release announcement, could you summarise it? Fair enough - though the relevant part is the short commentary preceding the perhaps mechanical release announcement. The deblob program(s) previously used sed and awk instead of python or perl and seem to have switched more because of performance than because of any features in either python or perl. A quick look into the source code seems to confirm that there's no strong tie to Python. //Peter
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
Alice wrote: > +++ b/eclass/kernel-2.eclass .. > - PYTHON_COMPAT=( python2_7 ) > + PYTHON_COMPAT=( python3_{7..10} ) From https://www.fsfla.org/pipermail/linux-libre/2020-August/003404.html it seems that it may be possible to need only very simple tools for the deblob program(s). I think that would be a worthwhile improvement and it would probably also simplify integration of deblob not only in Gentoo. That said, if python2_7 is not a thing in Gentoo anymore then the patch makes sense to me. I think the discussion on merits concluded well - kernel maintainers who want can support it. Everyone who considers it pointless can ignore it. All good. Kind regards //Peter
Re: [gentoo-dev] Packages up for grab
Marco Scardovi wrote: > mail-filter/bogofilter I'd like to proxy-maintain this. //Peter
Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults
Ben Kohler wrote: > Nobody is "disabling choice" here, Fair! Sorry about the hyperbole. > a change in defaults doesn't remove your ability to choose something else. True. My argument is more specificically that setting USE flags by default in a "low-level" profile goes in the wrong direction. > And I understand your sentiment that adding more default-on flags goes > against YOUR goals of a minimal gentoo, but I'd like to remind you and > others that this minimalism is not the goal of every gentoo user. It's important that this is a low-ish-level profile. Unfortunately Matt didn't respond to my question/point about profile inheritance. I don't expect a gentoo desktop system to be minimal. I would however like being able to build upon a minimal profile (not a desktop one) with nothing in it, as opposed to having to essentially create a new profile for each of my configurations. > I want to be clear that I'm not saying you are wrong, but remember that > your perspective is not the only correct one on this topic. Maybe the discussion should focus on different kinds of profiles? I'm not concerned about typical "user-facing" profiles here, it can make plenty sense to enable these USE flags by default in those. Michael Orlitzky wrote: > all I personally want is to be reasonably sure what my configurations > are going to do without having to list every individual package and > USE flag explicitly. Exactly this. Unfortunately I've had to give up on it, as USE flags are set by default here and there, but I'd love to be able to rely on a minimal starting point that will stay minimal. Thank you for your mail Michael, you expressed my concern very well. Kind regards //Peter
Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults
Matt Turner wrote: > > > If you can find a case where you wouldn't want to enable one of these > > > USE flags, please let me know and I'll reconsider my position. > > > > My catalyst spec files all have use: -* foo bar x y z > > specifically because the defaults are never what I want for any given > > system. I build desktops, servers, containers, VM appliance images and > > embedded system, and I know what I want in each one. Especially the > > latter frequently have only very few USE flags set and I want zero > > extra dependencies. > > I think you're making a great argument that you'd be completely > unaffected by any of the suggestions in this thread. I don't consider needing "use: -*" at all a desirable situation. This catalyst warning might support that: Warning!!! The use of -* in $stage/use will cause portage to ignore package.use in the profile and portage_confdir. You've been warned! I see it as a shortcoming of the standard profiles that I have to essentially create my own in order to get what I want, as opposed to being able to build upon something truly minimal. > > > I'd claim most of these packages' bzip2/lzma/zstd USE flags should > > > be removed in favor of statically enabling them > > > > That is the direct opposite of Gentoo's single most core value: choice > > Choice makes sense when there's a legitimate trade-off to be made. I explained that and why I frequently do not want those USE flags set, demonstrating that I want choice here. You can of course dismiss any concern which disagrees with your opinion as illegitimate. Please do not bother asking questions if that's your style. > Choice isn't dogma. Is there a difference between dogma and value? I understand choice to be a core value in Gentoo. Maybe that's wrong (now)? Core values are more important than pretty much anything else. Choice isn't always possible. That's not this case. If choice is indeed a core value then where choice is pretty easy (this case) in my mind there needs to be an overwhelmingly strong argument to conciously and intentionally disable choice. > > Just don't do it. Kthx. > > This kind of thing is nothing but irritating. Please don't do this. I'm sorry if it wasn't clear that "Just don't do it. Kthx." meant exactly what you wrote: This kind of thing (increase default USE-flags) is nothing but irritating. Please don't do this. Kind regards //Peter
Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults
Matt Turner wrote: > If you can find a case where you wouldn't want to enable one of these > USE flags, please let me know and I'll reconsider my position. My catalyst spec files all have use: -* foo bar x y z specifically because the defaults are never what I want for any given system. I build desktops, servers, containers, VM appliance images and embedded system, and I know what I want in each one. Especially the latter frequently have only very few USE flags set and I want zero extra dependencies. I completely agree that the default USEs should rather be reduced, not increased. Isn't this what profile inheritance is for? It would be great if I didn't essentially have to create my own profile when I want a very minimal system. Matt Turner wrote: > I'd claim most of these packages' bzip2/lzma/zstd USE flags should > be removed in favor of statically enabling them That is the direct opposite of Gentoo's single most core value: choice Just don't do it. Kthx. //Peter
Re: [gentoo-dev] [PATCH] qmail.eclass: simplify is_prime()
Rolf Eike Beer wrote: > The previous algorithm would scan for all primes for a given number, > which takes needlessly long. Please also mention how this caused a problem for you in the commit message, to help us understand why you're proposing to change this. > +++ b/eclass/qmail.eclass > -# @FUNCTION: is_prima > +# @FUNCTION: is_prime > # @USAGE: > # @DESCRIPTION: > # Checks wether a number is a prime number Maybe name the algorithm? Looks like an optimization of the sieve of Eratosthenes? > is_prime() { > local number=${1} i > - for i in $(primes ${number} ${number}) > + > + if [[ $[number % 2] == 0 ]]; then > + return 1 > + fi While 2 itself is prime the above returns 1 for any even number. > + for ((i = 3; i * i <= number; i += 2)) > do > - [[ ${i} == ${number} ]] && return 0 > + if [[ $[number % i ] == 0 ]]; then An inconsistent space after "% i" here. I don't know what style is correct. //Peter
Re: [gentoo-dev] EAPI 8 is here!
Sam James wrote: > * Brings IDEPEND, usev enhancements, --disable-static by default, and more! How to undo that --disable-static ? I'm asking both for my own ebuilds and as a regular portage user. //Peter
Re: [gentoo-dev] Packages up for grabs
David Seifert wrote: > mail-filter/bogofilter In principle I'm interested in proxy-maintaining this but do not have cycles immediately. The current ebuild has little special stuff so probably also works for the #763024 bump without much change - though I'd like to rework the rather messy database USE logic.. //Peter
Re: [gentoo-dev] Package up for grabs: sys-boot/lilo
Hi Joshua, Joshua Kinard wrote: > > The base system project is dropping LILO: it really needs to be > > maintained by someone who actually uses it. > > I'll claim it. Awesome, thanks a lot. > Never took a liking to GRUB. Simpler is better +1 > However, I am very time-limited, so I will defer to Hank or Peter if they > wish to tackle any open bugs and I'll serve as final reviewer, tester, and > committer. Fair enough, I'll follow up in the bugs. I think my #741912 patch works but I want to look closer at the clang/musl suggestions. Thanks a lot for researching that issue! //Peter
Re: [gentoo-dev] Package up for grabs: sys-boot/lilo
Mike Gilbert wrote: > The base system project is dropping LILO: it really needs to be > maintained by someone who actually uses it. I also use it. Hank Leininger wrote: > I still use/prefer LILO; I'll take a look at the open bugs and > consider submitting PRs for them & taking on p-m of it. Hank, please feel free to ping me for another pair of eyes or Cc me on bugs. //Peter
Re: [gentoo-dev] Gentoo 18th Anniversary Edition - Help Needed
Great idea and happy anniversary! :) Roy Bamford wrote: > Here's where I reed your help. I can't help with that. Roy Bamford wrote: > I have a similar media problem with a pile of 5 1/4" floppies. A have a > drive that reads all the 5 1/4" formats and a motherboard to connect it > to ... until I replace this 12 year old system. > > USB to Floppy interfaces won't do it as they are all made for the data > rate used in 3 1/2" floppies. But with this. Look at these projects: https://cowlark.com/fluxengine/ https://github.com/keirf/Greaseweazle And these ready-to-buy products: https://shop.deviceside.com/prod/FC5025 https://www.kryoflux.com/ Kind regards //Peter
Re: [gentoo-dev] Idea: User centric kernel configuration
Hi, Gerion Entrup wrote: > the Linux kernel has _a lot of_ configuration options, way too many to > configure them by hand. I actually disagree strongly with that; I think it's important to actively decide what kernels include, and I routinely do, but of course not everyone will. I've made sure to include a kernel build when teaching systems administration courses and would again. As the kernel becomes more complex the threshold for the first configuration also rises, but it's still completely possible to learn what you need in order to successfully configure your own kernel. I guess it's on the order of a weekend project given some basic understanding of computer architecture and programming. > This requires a mapping between user oriented "features" and the kernel > internal configuration options. So the challenge here is that the kernel is disjoint from user space, and while the kernel API remains stable over time consumer requirements such as "docker" or "cryptsetup" will mean different things for different versions of particular user space software. > Do you think that it is useful and feasible to combine these two mechanisms? AFAIK there's no generic method for formal kernel requirements in user space packages and there's also no sanctioned method for quering kernel capabilities. The only thing available is /proc/config if that was enabled in the kernel build, and there are of course reasons to leave it out, and it only applies to the particular running kernel, e.g. useless for cross-compilation. There, it would be possible to read the kernel configuration file if the kernel source code is available when the userspace package is being built, but that's not guaranteed. In Gentoo, linux-info.eclass provides linux_config_exists() to do all of this, but order to become a widespread success there would have to be one method for upstreams to maintain these requirements as part of their packages, rather than forcing the burden on package maintainers to repeat the same detective task in every single distribution. I think it would be very useful to create something generic for that, but that's certainly no small task. And realistically I only see it succeeding if Linux Foundation decides to push it onto the world. > A possible way could be to automatically extract the kernel config > flags from the wiki pages and map them to Kconfig options. At very best that will only be valid for some particular point in time, like current CONFIG_CHECK in ebuilds using linux_config_exists() are only valid for particular package versions. At worst it's plain wrong because the requirements have to be reverse-engineered downstream. //Peter
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
Mike Gilbert wrote: > > > The first big blocker we're going to hit is trustme [3] package that > > > relies on cryptography API pretty heavily to generate TLS certs for > > > testing. > > > > For which testing? Could it be changed to generate certs differently? > > He is probably referring to the test suite in dev-python/urllib3, > which uses the python "trustme" package in several places. > > https://github.com/urllib3/urllib3/search?q=trustme > > Someone would need to convince the urllib3 developers to use something > else to manage certificates in their unit tests. Ah - non-Gentoo packages - thanks, I understand. The trustme API isn't very large, so it seems doable to create a different implementation of it without rust dependencies, add virtual/trustme and be done? //Peter
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
Michał Górny wrote: > I'm seriously wondering why I'm wasting so much effort on open source. Open source only ever works when taking responsibility for one's problems. > I don't see a good way out of it. I see a couple. Of course all require some effort. One was already mentioned; move Gentoo package management from Python to some compiled language. High effort but maximum independence/reward. Another option, less effort and less reward, is to investigate how much CPython portage in fact requires, and make that a special package in Gentoo. This essentially means a special-purpose fork of CPython, only for running portage. Obviously portage development must then be comfortable without using the latest shiny Python language stuff that only future RustPython will offer. I guess that's not a problem. Yet another is a variant on the previous, but even less effort and much less reward; freeze what language stuff is allowed in portage code and always run portage with some chosen existing/later CPython version. Like libressl and gtk2 this thread also converges on the common point in my argumentation: it's not per se bad, and sometimes supremely wise, to quit chasing the latest version, and rest on a known platform. Coupled with independent efforts to place security-relevant parts in isolated environments (see sandbox) - ongoing effort regardless of Python - I don't see why portage couldn't depend on a CPython interpreter of its own, some last version that works well and is then copied and renamed. It seems like that would be rather straightforward. It might also be a good thing to take portage out of the overall Gentoo Python picture? I don't know here - this bit is just a guess. > arrogant zealots who want to destroy everything in their path LOL, priceless. > The first big blocker we're going to hit is trustme [3] package that > relies on cryptography API pretty heavily to generate TLS certs for > testing. For which testing? Could it be changed to generate certs differently? CAs aren't magic. Attached is a basic script of mine. //Peter mkca.sh Description: Bourne shell script
Re: [gentoo-dev] A script to pick next free UID/GID for your acct-* packages
Joonas Niilola wrote: > There's a script by jkroon in data/api.git > (https://gitweb.gentoo.org/data/api.git/) that prints the next available > UID/GID pair for new acct-* packages. This is super nice! Thanks a lot jkroon! > It is not forbidden to mix and mash UID/GID between different packages, > but I'd still suggest to find a new "pair" even if you push just an UID > or GID. Since we don't seem to be in danger of running out any time soon. Mh - so the obvious first feature request for the script is to also output Free UID+GID pairs. Counting them manually in your screenshot I get 36. That's not a whole lot; just 7% of 500. //Peter
Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3
John Helmert III wrote: > > Until there's a relevant flaw that will remain unfixed or there is > > significant incompatibility with infrastructure (recurse my argument) > > no signs actually exist. > > Waiting until such a problem pops up and bites everyone before doing > anything about it doesn't sound like a good way to handle it. I guess that's a matter of opinion. But more importantly, "anything" can mean a lot, and removing gtk2 is the ultimate sledgehammer. Deciding to certainly use it at an unknown point in the future seems unneccessary and premature to me. > If an application never ports, do you expect the distribution to > maintain that package ad infinitum? As always it depends on the required effort. When keeping the package requires little or no effort I *do* expect it to not be removed solely because there will be no more releases, which is really what was stated in the announcement, and why I piped up. Alec Warner wrote: > - I expect gtk2 (the library) to be around for a while. As written it > gets at least one more release. Ack. My point isn't about immediate action, rather about what drives decisions. > - I expect Gentoo to come after gtk2-only leaf packages pretty hard; > either to get upstream to port, or to remove them. >- This is true even if the packages are fully functional with gtk2, > or don't have other bugs. >- This is because we will eventually remove gtk2 from the tree > (which will make these packages unbuildable, and cause their removal.) That's indeed what I'm trying to give more perspective to. If there's in fact no other reason to "come after packages hard" and "remove gtk2" than "no more releases" then I'm strongly against doing so. > I'm less clear why we would keep libgtk2 in the tree for years and > years (just to keep nominally unmaintained gtk2 leaf packages buildable?) This assumes that "maintained" neccessarily means "will port from gtk2" which I don't agree with at all. There are many reasons to not port from gtk2 to something else. As long as there are no concrete problems, especially if one knows the relevant parts of gtk2 well and is convinced that they are free of issues, there is in fact no reason *to* port from gtk2. Except if distributions create one. It's awfully unneccessary to do that without good reason. > > Assuming that there will be a significant maintenance burden which > > affects all uses doesn't seem rational - hence my question. > > I think you need to keep gtk2 (the library) for a fair bit (just like > we kept python2.7; the interpreter; for a fair while after its EOL.) I'd argue that python2.7 should remain until demonstrably untenable, ideally indefinitely. At some point probably no longer within Gentoo's Python infrastructure - but at a minimum as a trivial package. //Peter
Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3
Hanno Böck wrote: > > "It does mean, however, that GTK 2 has reached the end of its life. > > We will do one final 2.x release in the coming days, and we encourage > > everybody to port their GTK 2 applications to GTK 3 or 4." > > I read that as there will be one more gtk2 release and none after that. > > This seems to imply: > * When there's a security flaw in gtk2 there won't be a fix from > upstream. > * When there's an incompatibility with new infrastructure (e.g. new gcc > version / new glibc / changing API of libraries gtk depends on) there > will be no updates from upstream. > > This means in all those instances maintainers will have to get patches > from somewhere. We'll likely end up with some form of > gtk-2.x-r[largenumber] with a large patchset at some point. > Maintaining that will be an increasing burden. > > No urgency, but a sign to slowly move off gtk2. Until there's a relevant flaw that will remain unfixed or there is significant incompatibility with infrastructure (recurse my argument) no signs actually exist. Assuming that there will be a significant maintenance burden which affects all uses doesn't seem rational - hence my question. The blog post shouldn't be misunderstood. The intended audience seems to be application developers, encouraging them to port applications, not so much distributions. Distributions quite often overlook that they wield much power, and thus also have much responsibility. Of course, GTK maintainers in Gentoo choose what to work on, and have made many (only?) excellent choices. I'm merely pleading for rational choices based on actual problems. //Peter
Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3
Peter Stuge wrote: > We will do one final 2.x release in the coming days, and we encourage > everybody to port their GTK 2 applications to GTK 3 or 4." > > > The recommendation in the blog post is for application developers to > port to 3 or 4, nothing more and nothing less. Correction: It /encourages/ porting to 3 or 4. It's not even a recommendation. > What's the reasoning for this driving "killing off GTK:2" in Gentoo? > > Are there (presently or foreseeable) technical issues with GTK:2? > > > Many thanks and kind regards //Peter
Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3
Aisha Tammy wrote: > We are now in the process of cleaning up GTK:2 ebuilds and moving the > packages to use GTK:3 and drop GTK:2 support. Quoting the blog post you linked to: (thanks for including the link!) "It does mean, however, that GTK 2 has reached the end of its life. We will do one final 2.x release in the coming days, and we encourage everybody to port their GTK 2 applications to GTK 3 or 4." The recommendation in the blog post is for application developers to port to 3 or 4, nothing more and nothing less. What's the reasoning for this driving "killing off GTK:2" in Gentoo? Are there (presently or foreseeable) technical issues with GTK:2? Many thanks and kind regards //Peter
Re: [gentoo-dev] [RFC] Dealing with global /usr/bin/libtool use vs CC/CXX etc.
Jaco Kroon wrote: > > I can think of two ways of solving it: > > > > 1. We could patch system-installed libtool to respect environment > > > > 2. We could regenerate libtool and force local instance of libtool > > in the packages needing it. > > 3. Have it always use some fixed compiler somewhere (ie, compile it 4. Make gcc-config regenerate libtool, otherwise as 2. //Peter
Re: [gentoo-dev] Static libraries
Alessandro Barbieri wrote: > > Obviously this will only be useful for packages wanting to statically link > > with libressl lib{crypto,ssl} > > There is an ongoing effort to remove static libraries from packages. I know, and I couldn't disagree more with that effort. > > but I think that's far better than removing libressl. > > No, it's not better, it's more work for the security team. The security team isn't be responsible for what people do. Flip side: The security team is also not entitled to decide what people can and can not do. Security is a policy and technology generally needs to avoid forcing policy onto humans, but enable human decisions. You can tell that I value choice. It's certainly a good default to use shared libraries, but it's no good at all to hamper legitimate functionality under a guise of security. That's a far too common and really diseased pattern throughout society, and it makes me sad that it proliferates also in Gentoo. //Peter
Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?
nly be as a special case, and it looks like that would require only very little upfront effort and zero recurring effort. Thanks a lot for your thoughtful response! I hope I could clarify some things. Kind regards //Peter
Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?
Mike Gilbert wrote: > > It is important to me that you can choose dev-libs/libretls instead of > > having any libretls code on your systems, but I reject you forcing that > > choice of yours on everyone else. > > I'm having trouble making sense of this sentence. Did you mean to > write "libressl" instead of "libretls" somewhere? Sorry, yes, that's right. "having any libressl code" is what I intended. > Anyway, it seems like the people maintaining libressl in Gentoo are > really not interested in keeping it going. I don't know? There wasn't much discussion about my suggestion to keep libressl code available in Gentoo in some ways causing no interference with same SONAMEs openssl. So again what I'm advocating for is creative ways to at the very least not have to remove it completely, which I think becomes easy, by redefining what a libressl ebuild installs for now. At the moment I'm thinking about these two: 1. no-brainer: libtls .so with libressl implementation 2. more novel: lib{crypto,ssl} static-libs in non-standard location with libressl.pc in default search path > A libtls wrapper around openssl seems much more manageable to me, > and that should probably be the default option for people. I disagree on both points. I'm still working on checking what 1. above requires. So far it looks like the answer will be "nothing"; an ebuild wouldn't need any patch at all, meaning zero overhead on bumps. And I for one certainly expect libressl libtls to be the default - that is the canonical upstream. Thanks //Peter
Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?
Michał Górny wrote: > > > I think the three main ways forward from here would be to either: > > > > > > 1. Keep LibreSSL for indefinite time (possibly masked) > > > 2. Eventually move LibreSSL to libressl overlay. > > > 3. Eventually remove LibreSSL. > > > > 4. A libressl or libressl-libtls ebuild installs only libtls. > > dev-libs/libretls already does that. dev-libs/libretls doesn't install a libressl libtls. This thread is obviously about how the libressl implementation remains in use. It's clear now that you want to hinder that in Gentoo at any cost to the community, but that's not useful, so please take a step back unless you are actually going to be constructive. My proposition 4. (which I suggested already earlier - you shouldn't have ignored it) is obviously not about having any libtls provider in the tree, but to model reality accurately and ensure that libretls is the primary and prefered libtls provider, since it is literally the libtls upstream. It is important to me that you can choose dev-libs/libretls instead of having any libretls code on your systems, but I reject you forcing that choice of yours on everyone else. //Peter
Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?
Michał Górny wrote: > let's summarize what was said so far. Thanks for the good summary! > I think the three main ways forward from here would be to either: > > 1. Keep LibreSSL for indefinite time (possibly masked) > 2. Eventually move LibreSSL to libressl overlay. > 3. Eventually remove LibreSSL. 4. A libressl or libressl-libtls ebuild installs only libtls. //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
We could clearly discuss forever, but since you refuse to engage with my constructive proposition and my ask for feedback there's no point, is there? It's super sad that you behave like that in Gentoo. Michał Górny wrote: > Choice for the sake of choice is meaningless. Far from it. > So far nobody has been able to find a strong argument for choosing > LibreSSL. There are strong arguments for using OpenSSL instead. That's like your opinion, man. :) > Maybe LibreSSL had promised a better taste in the beginning but today > 9 out of 10 consumers say OpenSSL tastes much better. It's usually harmful to optimize for popularity; smoking isn't a good idea even if everyone in school does it. > The only difference is that you don't have to pay > for it (but we do!), so you think that it's free. Please stop playing the victim and engage with my proposal instead. I'd appreciate feedback from everyone. Thanks a lot //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
David Seifert wrote: > > Maybe because it is so well-known that monoculture is harmful per se, > > which is why the commitment to choice in Gentoo is very valuable. > > > > Further, LibreSSL comes out of the OpenBSD project, which has a good > > reputation on code quality. > > Like strong-arming 99% of the users of OpenSSH because they were > unwilling to port to the OpenSSL 1.1 API, fully well knowing that most > of the OpenSSH consuming world doesn't actually use libressl? How is > explicitly tying OpenSSH to libressl not a form of monoculture? Now we're properly off-topic :) but considering that OpenSSH is developed for OpenBSD and that openssh-portable is merely provided as a service to other systems it's easy to understand why OpenSSH (remember, part of OpenBSD) uses the libressl API for crypto, and why the -portable team is not so keen on maintaining patches for other crypto providers. Another example is systemd binding tightly to Linux. In both cases it's understandable, but also quite unfortunate; better portability would be better. > Case in point: Have you tried using the official libjpeg package instead > of libjpeg-turbo? Go ahead, give it a try. I'll take a look. I chose libjpeg-turbo for a project because it cross-compiled better. > "Monoculture"s are mostly a coincidence, not some sinister conspiracy. I don't claim conspiracy, I just say that it's healthy to avoid them. > Implementation-diversity-but-API-compatibility is mostly a > pipe dream, as libav, imagemagick, libjpeg have shown. I've been fortunate to have a different experience with other codebases. It's completely possible, but takes (extra!) effort, meaning you have to really want it. If there is some rivalry then it's also quite easy to sabotage your colleagues. //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Michał Górny wrote: > > I would be happier if some other developers were able and willing to > > participate actively in the LibreSSL project. > > But why would they do that? What I'm really missing in all the replies > is a single reason why LibreSSL would be better for anyone. Maybe because it is so well-known that monoculture is harmful per se, which is why the commitment to choice in Gentoo is very valuable. Further, LibreSSL comes out of the OpenBSD project, which has a good reputation on code quality. > a real proper, verifiable argument 'LibreSSL is better in this regard'. Choice is about enabling people to decide for themselves. Choice is /not/ about forcing people to formally prove utility to yourself. I acknowledge that what I suggest isn't immediately enabling libressl as a choice either, but it is at least far less destructive than masking and removal. //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Matt Turner wrote: > > I think many mails in this thread suffer from some tunnel vision, expecting > > that a libressl ebuild in the tree must continue to work exactly like the > > openssl ebuild - I'm saying to stop that but do keep a libressl ebuild. To clarify, by "stop that" I mean "stop efforts to make libressl a drop-in replacement". > If they suffer from tunnel vision, it's because the intersection of > "people who care about libressl" and "people who have patches in > gentoo.git" is the empty set. Tunnel vision refered not to people but what a libressl ebuild delivers, which you seems to have turned into an ad hominem against me? Who will do actual work is a separate question, of course if noone wants to then nothing matters, but it seems that some people /do/ care about libressl; I suppose the 61 patches mgorny found were committed by someone. If you were somehow trying to belittle /me/ then it's certainly true that I'm not a Gentoo developer, but there are some patches by me in gentoo.git. > I think we all understand your points: libressl could be kept in-tree > and allow people to play with it. Unfortunately that requires much > more work than removing it, and I haven't seen evidence that you're > prepared to contribute to the required effort. > > I don't think you're going to convince a bunch of people with little > interest in libressl per se to continue allowing the extra burden > unless you do the work that's needed to keep it in-tree (e.g., to > allow it to be installed beside openssl). You seem to not understand my point at all. As I've written I (like others) argue against "continue allowing extra burden" and I've suggested and offered to help with one approach to keep a libressl ebuild in the tree. //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Andreas K. Huettel wrote: > > I agree completely that it's unreasonable for Gentoo (worse, 1 person!) > > to continuosly patch the entire world for libressel. > > > > I'm asking to stop doing that, yet still enable the choice between > > openssl and libressl where that is possible without patches, even > > if that's only openntpd and one other package. > > a) The two cannot be installed concurrently. To fix that would require even > more hacks. As we've discussed in another part of the thread, that's not really true. Both can for sure be installed, just not in the same place and/or with same names. > -> all relevant ssl consumers on the user's system must be linked against > the one selected Also not the case. Considering the two installed in different paths with same names it's still easy for consumers to use one or the other with -rpath at link time. I do agree that the two are not always 1:1 replacements for each other. If they are API incompatible somewhere then for sure not. I think many mails in this thread suffer from some tunnel vision, expecting that a libressl ebuild in the tree must continue to work exactly like the openssl ebuild - I'm saying to stop that but do keep a libressl ebuild. > b) The libraries are not guaranteed to be binary compatible, so switching > implementation requires rebuilding consumers. We can only consider ABI compatibility if we have API compatibility, which might not even be a given. > c) If a single package that the user wants to install is not "fixed" for > one ssl library, it blocks that option for all packages. Please think of a libressl ebuild in a new way. > I guess if you can come up with a solution that > * provides secure usage of the libraries, > * provides choice to the user, and > * doesn't lead to unupgradeable systems or unresolvable dependencies > we'd all be happier. So far we haven't found one. Right! I think letting a libressl ebuild install only libtls could be a good start, because it provides a stable situation, without risking conflicts. Would you agree? Thanks //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
David Seifert wrote: > > > I mean, you have to explicitly support the choice in ebuilds, > > > and this means making things even harder for newcomers. > > > > pkg-config/pkgconf and .pc files can help with this part, taking care > > of all abstraction if/when downstream uses a libressl.pc. > > As we have learned from the ncurses[tinfo] debacle, 80% of build systems > don't use the .pc files, and just guess "-lssl" flags and a bunch of > include dirs. Did the debacle actually involve -lssl ? I guess that it depends on the particular library - with an old library such as ncurses I can imagine that .pc is much less established, and I have indeed seen pretty ugly OpenSSL detection in configure.acs, they could still remain, and would then simply never catch libressl, I think that would be fine. > > > The big problem is that (unless I'm mistaken) we won't be able to > > > load LibreSSL and OpenSSL to the same executable. > > > > I'd suggest investigating whether symbol versioning could help with > > this, or if the only way forward would indeed be to require some symbol > > mangling/rewriting. > > While this sounds like a theoretical solution, it isn't tractable because > 1. We're inventing our own ABI that is incompatible with everyone else's ABI for a given library doesn't neccessarily matter beyond the individual system, does it? For something like reproducible builds of course it does. > 2. We'd have to maintain a huge swamp of downstream patches Nono, no patches of course, it would have to be automatic, if only for the local system. > 3. ABI can still break even with perfect symbol versioning Oh? This may be unrelated, but can you tell more or provide a pointer? Thanks! //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Michał Górny wrote: > > 2. Install them into different prefixes (eg /usr/lib/openssl + > > /usr/lib/libressl and have the linker link to a specific version, > > /usr/include/{openssl,libressl} too). > > For the record, this is something I've been wondering about for a long > time. However, there are two problems with that: a small one > and a huge one. > > The small problem is that this requires a lot of additional downstream > work. I mean, you have to explicitly support the choice in ebuilds, > and this means making things even harder for newcomers. pkg-config/pkgconf and .pc files can help with this part, taking care of all abstraction if/when downstream uses a libressl.pc. > The big problem is that (unless I'm mistaken) we won't be able to load > LibreSSL and OpenSSL to the same executable. So we'd actually have to > enforce that the whole link chain links to the same SSL provider, > and effectively land pretty close to where we are now. I'd suggest investigating whether symbol versioning could help with this, or if the only way forward would indeed be to require some symbol mangling/rewriting. //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Michał Górny wrote: > > net-misc/openntpd > > I've just tested it and it builds fine against dev-libs/libretls. I hope you're not planning to suggest that dev-libs/libretls should be the only libtls on Gentoo, since that would be an arbitrary and artificial limitation - the very opposite of choice. I'm strongly against that. Jaco Kroon wrote: > > I'm asking to stop doing that, yet still enable the choice between > > openssl and libressl where that is possible without patches, even > > if that's only openntpd and one other package. > > Are you willing to put in the work to allow installing openssl and > libressl concurrently on the same system? I'm willing to help. I know that it's one or the other. And I have experience with distributions making arbitrary decisions about libraries, and I think I have an idea about the challenges and possibilities. > The only real solution then to make libressl viable is to make it > co-exist with openssl reliably. Ack. > Of course there are various strategies (or combination of), to mention > but a few: > > 1. Use a virtual/??? (but since the APIs aren't compatible despite the > libressl promise thereto ...) > 2. Install them into different prefixes (eg /usr/lib/openssl + > /usr/lib/libressl and have the linker link to a specific version, > /usr/include/{openssl,libressl} too). > 3. Make ssl USE flag another single-choice USE_EXPAND, posibly by way > of openssl.eclass. These are all interesting and I think worth exploring! But also non-trivial, so maybe better saved for later? What do you think about my suggestion in a previous email to have the libressl ebuild install only libtls .so and .a files built from static libs/objects, so that there are no conflicting shared objects? I can certainly help accomplish that if there is interest. > would be in willing and in support of updating the packages I maintain > to assist with libressl support if the eco system can be improved. Cool! I really appreciate your openness. I'm asking essentially to keep options open, so that the ecosystem can be improved step by step. Thanks //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Michał Górny wrote: > 1. Stuff that does not build against LibreSSL. > 2. Stuff that builds just fine but fails at runtime in unpredictable > ways (e.g. Tor mentioned today). > 3. Stuff that builds and works 'fine' but ends up being crippled (e.g. > doesn't support new algorithms). > > The first one is somewhat easy to test (e.g. via tinderbox). The other > two are very hard. Nod. > > > Actually, I see that someone has apparently forked libtls into > > > libretls (the irony!) that works against OpenSSL [1]. > > > > To me, that proves value in the libtls API and in keeping libressl in > > the tree in some capacity, even if not as an alternative to openssl. > > > > Maybe with a USE flag which makes it install only libtls (built from > > libressl static libs), which could be one provider for a > > virtual/libtls. > > I don't see why we would put an effort into that. In my very next sentence (not quoted in your reply) I wrote explicitly that I do /not/ ask anyone to do so, but ask that you don't hinder it by masking libressl and also don't remove existing work potentially supporting such efforts, ie. the libressl ebuild. > I've just packaged dev-libs/libretls Thanks! That seems useful. > Trying to get the same result from libressl is just repeating the work. Maybe for you, and I'm saying that you should be able to make that choice for your systems, but also that you should not hinder others from making another choice, where that's possible and as I wrote without needing Gentoo to patch the world. Thanks a lot //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Michał Górny wrote: > > I'm sure that there are numerous cases where libressl doesn't work, > > but that's no reason to dismiss cases where it *does*. > > Are you asking people to put an effort into maintaining something that > can't be practically installed? No, I'm rather asking to change the level of commitment. I agree completely that it's unreasonable for Gentoo (worse, 1 person!) to continuosly patch the entire world for libressel. I'm asking to stop doing that, yet still enable the choice between openssl and libressl where that is possible without patches, even if that's only openntpd and one other package. The method for that choice could of course depend on the number of packages where it applies. > A side effect of this approach is that users will be tricked into using > LibreSSL, only to discover that they eventually have to transition > their systems back. I believe I'm asking for the opposite. I think it's fine to say that libressl has to be a deliberate choice rather than a default. > > Did anyone gather actual numbers? > > $ find -name '*libressl*.patch' | grep -v dev-libs/libressl | wc -l > 61 I'm more interested in the number of packages which can use either library without patches (like openntpd?). This may be tricky to find out. :\ > > > > B. It brings its own TLS API, a unique feature which by itself > > > > warrants the package. > > > > > > ...which by itself has no future > > > > That's arrogant and silly coming from anywhere but upstream. > > > > You can argue that you will never use the API in your TLS programs, > > but even then that says really nothing about the API provider itself. > > That's my opinion and I have a right to have it without being insulted. You absolutely have a right to your opinion but you stated it as fact, that made me react so strongly. > I don't dispute whether it's good. I dispute whether tightly binding > it to a problematic LibreSSL is a good idea. I agree with this, but only in cases where libressl is indeed problematic. I can think of systems where it isn't, there the choice is a good thing. > Actually, I see that someone has apparently forked libtls into libretls > (the irony!) that works against OpenSSL [1]. To me, that proves value in the libtls API and in keeping libressl in the tree in some capacity, even if not as an alternative to openssl. Maybe with a USE flag which makes it install only libtls (built from libressl static libs), which could be one provider for a virtual/libtls. Note: I'm not at all expecting anyone to do such work for me, I just don't want it to become impossible (libressl mask) or any existing effort supporting something like the above to be sunset. Does that make sense? Thanks! //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Michał Górny wrote: > > A. It is a distinct implementation with probably /quite some/ stable > > compatibility, meaning that it will work perfectly fine as an > > alternative in many cases. > > Except that it doesn't, as has been proven numerous times. I'm sure that there are numerous cases where libressl doesn't work, but that's no reason to dismiss cases where it *does*. Did anyone gather actual numbers? > > B. It brings its own TLS API, a unique feature which by itself > > warrants the package. > > ...which by itself has no future That's arrogant and silly coming from anywhere but upstream. You can argue that you will never use the API in your TLS programs, but even then that says really nothing about the API provider itself. > > More elaborate OpenSSL API users can (arguably should) just block on > > libressl instead of requiring patch work. > > It's all nice theory but in practice it means that nobody will be able > to install libressl because some important system packages will block it. Gentoo can't be expected to do magic. If libressl would conflict on another system then of course it will on Gentoo too. Give users more credit here. Also, think more about other use cases than your own. I mentioned one; non-releng stages. The point here is that it's possible to deliberately create a system using libressl by making tradeoffs, e.g. not using some "important" system packages which would block it. Finally, I find it quite beautiful if Gentoo can clearly show that important system packages have slipped far down a monoculture slope - this is a great incentive for new projects which tackle creating alternatives for those packages. > waste our users' time pretending that we do support LibreSSL, > while anyone actually trying it will hit a brick wall. You shouldn't pretend to be something you are not. With a little effort to set users' expectations according to the technical reality (a function of upstreams; rather unrelated to Gentoo) I don't expect wasted time. //Peter
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Michał Górny wrote: > I would like to discuss the possibility of discontinuing LibreSSL > support in Gentoo in favor of sticking with OpenSSL. I think that's a horrible idea, since Gentoo is about choice and this particular component is one of the most important in a system. But "support" can mean different things... > LibreSSL users, does LibreSSL today have any benefit over OpenSSL? Yes, at least two: A. It is a distinct implementation with probably /quite some/ stable compatibility, meaning that it will work perfectly fine as an alternative in many cases. B. It brings its own TLS API, a unique feature which by itself warrants the package. > All this considered, provided that nobody is able to find a good reason > to use LibreSSL, I would like to propose that we stop patching > packages, discontinue support for it and last rite it. There is no reason at all to do all three of those atomically: 1. Stop patching packages to make them build also against libressl 2. Stop maintaining libressl-*.ebuild 3. package.mask I think the complaint is really only about 1. and I can understand that the effort here outweighs the perceived benefit, that's fine, I don't think it's the responsibility of Gentoo developers to patch the world to build also against libressl. But as long as a single package can be built with either openssl or libressl without changes I consider it appropriate to maintain both libressl ebuilds and either virtual/openssl or another way to decide system-wide to use libressl instead of openssl. This remains very valuable especially for non-releng stages. More elaborate OpenSSL API users can (arguably should) just block on libressl instead of requiring patch work. //Peter
Re: [gentoo-dev] libressl / libtls
Paul B. Henson wrote: > Would it be possible to have a use flag such as 'libtlsonly' or whatever > for the ebuild which only installs libtls, Sure. > Or have a separate ebuild just for libtls (which couldn't > be installed with the full libressl ebuild or vice versa) That's also technically possible. I'd personally prefer the latter. //Peter
Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider
Georgy Yakovlev wrote: > I'll be switching default tmpfiles provider to sys-apps/systemd-tmpfiles > by the end of the week by updating virtual/tmpfiles ebuild. Michael Orlitzky wrote: > Corollary: the tmpfiles.d specification can only be implemented (safely) > on Linux after all. So should virtual/tmpfiles differentiate based on system? //Peter
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
Andreas K. Hüttel wrote: > it's probably time to deprecate the amd64 17.0 profiles! I for one am not so excited about the amd64 17.1 profiles. On the surface it appeared to me that one developer has "taken over" just about everything, which (regardless of the individual) can't be a good thing.. Jaco Kroon wrote: > ...just wondering where the lib32 => lib symlink comes from now. baselayout contains a conversion to/from lib symlink(s). Kind regards //Peter
Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
Michał Górny wrote: > Read: it's important to slap users to satisfy developer's wannabes. LOL! Michał, you managed to squeeze both misrepresentation and ad hominem into so few words. Please take care. Anyway, you missed my point: It's important that (the project) developers set accurate expectations for contributors. Michał Górny wrote: > If user puts effort to make a good contribution, the developer > shouldn't be rejecting it to 'demonstrate other methods'. Here you confused a couple of different things, maybe you didn't understand what I meant. "demonstrate other methods" is something that the Gentoo project does by enabling choice also in the development process. This is made possible by self-determined infrastructure in parallel with GitHub. This is important and valuable both philosophically and practically, and I think Gentoo should be both proud of it and also proud to present it. "rejecting" would require an action, that's not the case; we're talking about simply documenting which developers don't use GitHub, so that contributions can know the right place to go. Then there's your opinion that developers should do all that contributors want. I disagree with that for two reasons: 1. it doesn't scale, and 2. developers too work in their spare time, and choose how they do so > This is the horrible attitude that kills the project. In general I think that individual lack of reflection is a far greater problem than developer workflow choices within community projects. For Gentoo specifically I think that a fairly small number of structures are the main reason to rather spend time on other projects - that's off topic for this thread though. Assuming good faith and asking for clarification when something seems negative is always a good idea. //Peter
Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
Joonas Niilola wrote: > some of you may already have seen the new packages.gentoo.org page, > https://packages.gentoo.org/ I had not seen that - that's wonderful! I would just request that /packages/ is removed from the start of package URLs. I understand how this makes request routing more complicated, but I consider it a significant usability improvement. ..anyway: > I'm suggesting of adding a new metadata flag to our Wiki's > User:/Project: page which then prints a message to this page saying > whether the maintainer (be it project or user), "accepts" or "deals > with" Github contributions. The wording can be a bit better, but it'd be > there to **notify** our **contributors** whether their time and effort > will most likely be wasted making a pull request for this particular > maintainer. I think this is a very good feature. If I ever do become a proper Gentoo developer I will certainly not spend any time on anything to do with GitHub, and in my current position of occasional contributor I don't either. The workflow imposed by GitHub isn't good and it's important to demonstrate other methods. //Peter
Re: [gentoo-dev] Last-rites: dev-libs/liboobs
Jimi Huotari wrote: > # Jimi Huotari (2020-08-04) > # No consumers since 2015, and no known stand-alone use. > # Removal in 30 days. > dev-libs/liboobs Wut - isn't that a really poor reason to remove from the tree? :\ Why not just keep it unless there is an actual technical problem? (Security, maintainability, etc.) If there is, then please mention it. //Peter
Re: [gentoo-dev] Last rites: */* More Py2 only items
Remco Rijnders wrote: > I'd like to volunteer myself as proxy maintainer for this package. As > this would be the first package in gentoo I'd be working on, I ask for > advice on the following two points: Note that I'm no developer but have been proxy-maint for some time. > - Can the removal of this package from gentoo be pushed backwards with > a month or so to allow me to work on packaging this new version as well > as do some rudimentary testing to ensure it works properly with Gentoo? I have no idea about this one. > - As upstream for this program would be changed, should the name > getmail in gentoo be kept or would it better to use getmail6, and if > so, what would be the best way to go about this? Since you want to avoid clobbering the existing name outside of Gentoo I think you should strive for the same also within Gentoo. That said, if the two are interchangeable then a virtual/getmail ebuild would probably be reasonable. //Peter
Re: [gentoo-dev] Gentoo/OpenBSD current status
Benda Xu wrote: > > I was wondering if the openbsd prefix support is something > > that is still garnering any interest from gentoo? > > There is still interest in Gentoo. But no one seems to have energy to > take care of it. FWIW I have interest in this as well. > Your contribution is welcomed. What contributions are known to be needed at the moment? Kind regards //Peter
Re: [gentoo-dev] [RFC] Anti-spam for goose
Kent Fredric wrote: > > While services such as reCAPTCHA are (as said) massively intrusive, there > > are other, much less intrusive and even terminal-compatible ways to > > construct > > a CAPTCHA. Hello game developers, you have 80x23 "pixels" to render a puzzle > > for a human above the response input line - that's not so bad. > > Well, they kinda have to be, I disagree with that, especially for this service, that was the point I wanted to make. :) > the state of AI is increasing so much that current captcha systems > undoubtedly also develop their own adversarial AI to try beat their > own captcha. > > I don't think we have the sort of power to develop this. In any case I don't think that's required. > And the inherently low entropy of only having 80x23 with so few > (compared to full RGB) bits per pixel, A character doesn't compare too bad to RGB. See aalib, or if you will risk exclusion of color-vision-impaired humans libcaca. > this gives any would-be AI a substantial leg up. > > Using text distortion is amateur hour these days. > > (and there's always mechanical-turk anyway) Except this isn't for some web-scale disruptive startup, it's a statistics/reputation system for an advanced, super-nerdy Linux distribution. Please think more about the threat model, and remember the rate limit knob. The bar only needs to be raised high enough. //Peter
Re: [gentoo-dev] [RFC] Bootloader use in eclean-kernel
Michał Górny wrote: > Hence my question: do you find 'do not remove kernels listed > in bootloader config' feature useful? Do you think it should remain > the default? Do you think it is worthwhile to continue supporting it? I continue to use LILO because simpler and more mature code is good, especially in the boot code path. I used GRUB for a short while but when I saw it fail to boot from one start to another (without any OS changes) I ended that experiment. I also wasn't impressed by the GRUB2 code quality and tendency to become a mini-OS, trendy as that is. I don't use eclean-kernel, but FWIW I think there is clear value in supporting the LILO-style approach with explicit installation/configuration of the bootloader in advance. //Peter
Re: [gentoo-dev] [RFC] Anti-spam for goose
Stop motivated attackers or keep low barrier to entry; pick any one. :) Michał Górny wrote: > CAPTCHA > == > A traditional way of dealing with spam -- require every new system > identifier to be confirmed by solving a CAPTCHA (or a few identifiers > for one CAPTCHA). > > The advantage of this method is that it requires a real human work to be > performed, effectively limiting the ability to submit spam. > The disadvantage is that it is cumbersome to users, so many of them will > just resign from participating. While services such as reCAPTCHA are (as said) massively intrusive, there are other, much less intrusive and even terminal-compatible ways to construct a CAPTCHA. Hello game developers, you have 80x23 "pixels" to render a puzzle for a human above the response input line - that's not so bad. Attacking something like a server-generated maths challenge rendered in a randomly chosen and maybe distorted font would require OCR and/or ML, which is fairly annoying. The only real problem then would be with OCR packages. ;) Combine with a rate limit that is increased manually as the service grows more popular. It can be a soft limit which doesn't report failure but results in queueing+maybe vetting of reports, to allow some elasticity for peaks. //Peter
[gentoo-dev] user.eclass ignores ROOT/SYSROOT
Hi, I'm trying something out over here and I'm surprised to find that acct-group/* do not work with ROOT+SYSROOT != "/". Should I file yet another bug about this? I suppose the limitation is in user.eclass, but what about the 11 bugs already filed about exactly this problem? They are easy to see in the dup bug list at https://bugs.gentoo.org/53269 Unfortunately mgorny closed 53269 WONTFIX because GLEP-27 is Deferred, causing all dup and dep bugs to be forgotten. Sad panda. --8<-- reproduce # export r=$(mktemp -d) # ROOT=$r SYSROOT=$r strace -fe execve emerge baselayout acct-group/ftp 2>&1 | grep groupadd [pid 13269] execve("/usr/sbin/groupadd", ["groupadd", "-r", "-g", "21", "ftp"], 0x5d7e299e2340 /* 227 vars */) = 0 groupadd: cannot lock /etc/group; try again later. * groupadd -r ${opts} "${egroup}" || die * groupadd -r ${opts} "${egroup}" || die -->8-- In my particular case -R $r would work just fine, but as can be seen in several of those 11 dup bugs it is not a general solution. Any ideas on how to solve this? Thanks //Peter
Re: [gentoo-dev] zoom concerns
Kent Fredric wrote: > Syntax above not expected verbatim, just food for thought, I think this is a really good and useful idea. I would love to see it. > the nature of this metadata is that it SHOULD NOT be in the ebuild > itself, as it is inherently "repo based", the installed values of > these are worthless. E.g. for auditing the installed values of these could be worth a lot. Thanks! //Peter
Re: [gentoo-dev] ceph's static-libs
James Le Cuirot wrote: > Damn, I realised just as I hit send that there's a caveat here and > that's sub-dependencies. If you're building a partially static binary > then I think you're okay. A fully static binary obviously needs all its > dependencies to be static and that includes any sub-dependencies. Note that there isn't really a way to express "partially static" to the toolchain when building a binary. If you link a binary -static then that is always "fully static". No .so will satisfy any -l options. The only way a "partially static" binary gets created is when linking *without* -static but some -l libraries only exist as static libraries, or if a library/object archive is specified with full .a filename, without using -l. And "partially static" also only means that some dependencies were included into the binary, but unlike "fully static" the binary is not runnable without ld.so and a fitting libc. > If an executable statically links libwebp.a with JPEG support but you > don't have libjpeg.a then you'll end up with undefined references. It's a bit more complicated.. Assume: ( note: without -static ) gcc -o binary source.c /usr/lib/libwebp.a If libwebp requires libjpeg, and libwebp was not built to include libjpeg.a then the above will not build. So we try: gcc -o binary source.c /usr/lib/libwebp.a /usr/lib/libjpeg.a If both .a exist this builds, but binary is still *not* linked statically, at a minimum, ld.so and libc are still required to run it. If we do: gcc -o binary source.c /usr/lib/libwebp.a -ljpeg Then the compiler will pick any libjpeg that is available, preferably .so but if that can't be found then it will also look for .a. binary is still *not* static. Finally consider: gcc -static -o binary source.c -lwebp -ljpeg gcc -static -o binary source.c /usr/lib/libwebp.a /usr/lib/libjpeg.a The above two are equivalent, but only thanks to -static. This fails if either library .a is not found. When this succeeds, we have a static binary, which runs anywhere regardless of ld.so and libc. pkg-config .pc files for libraries are a very convenient solution to the problem of sub-dependencies. In the above case, libwebp.pc would perhaps have -lwebp in Libs and libjpeg in Requires.private (or maybe -ljpeg in Libs.private). > That probably explains why the ceph dependencies are as they are I think USE=static-libs is nice to have, and ideally (IMHO) it would be a global USE flag, respected by every package that installs a library. The flag says nothing about consumers, it only promises availability of the .a files, which I think is nice. One technical reason for a consumer to DEPEND on libotherpackage[static-libs] would be if an upstream Makefile has /usr/lib/libother.a instead of -lother, arguably it would make more sense to apply a patch to the Makefile then. Another technical reason would be that libotherpackage doesn't adhere to common sense/best practice for library ABI/API compatibility, and make the static library *different* from the shared object. If libotherpackage maintainer heroines have made it possible to have one SLOT installed as static library and another, incompatible, SLOT installed as shared object and the consumer maintainer might know that only the static variant works. This one is very hard to do anything about about in Gentoo, but it is also a very construed case. The closest I've seen to this is giflib, which changed API and ABI without bumping SONAME. //Peter
Re: [gentoo-dev] Use acct-* for qmail users
Mike Gilbert wrote: > Do the users actually need home directories? Technically probably no, but ~qmail is easier to type than /var/qmail. TBH I actually always type it out anyway. Mike Gilbert wrote: > If you don't want to maintain them, you'll need to find someone else > to do it. If noone else wants to take this then you can add me as proxied maintainer. //Peter
Re: [gentoo-dev] Gentoo i486 support
Rich Freeman wrote: > Is there a large population that actually runs x86 on modern > hardware, or is ancient hardware a significant use case? There are current products with pre-686 instruction sets. Companies such as DM&P still produce 586-class SoCs for embedded and industrial. These[1][2] are current products. And Intel Quark[3] is another one. I prefer option number 1 as suggested in the initial mail. //Peter [1] https://en.wikipedia.org/wiki/Vortex86 [2] http://www.vortex86.com/?p=264 [3] https://en.wikipedia.org/wiki/Intel_Quark
Re: [gentoo-dev] News item review: OpenSSH LDAP support
Hi Thomas, I suggest some improvements.. Thomas Deutschmann wrote: > Title: OpenSSH LDAP support Perhaps qualify this a bit, e.g. "Migration required for OpenSSH with LDAP" > When your sshd authenticates against LDAP, you have to migrate your s,When,If, > current setup to a new one using sshd's "AuthorizedKeysCommand" option and > use s, use,, > a wrapper provided by packages like the new sys-auth/ssh-ldap-pubkey > because beginning with net-misc/openssh-7.7_p1, deprecated OpenSSH-LPK > patch set no longer applies. Maybe "because beginning with net-misc/openssh-7.7_p1 the OpenSSH-LPK patch set is deprecated and no longer applies." Thanks a lot! //Peter
Re: [gentoo-dev] Adding USE=udev to linux profiles
Mart Raudsepp wrote: > > * USE=udev means different things for different packages. You think > > it "makes udev work" or whatever, but nobody has any idea what it > > does for half of the packages that use it. The meaning is package- > > specific, so the default should be package-specific. > > It makes hardware work without static configurations, including when > hotplugged. That's not really a complete description... 1. Linux always sends netlink messages on device changes. 2a. If running, udevd receives those messages and executes all udev rules. 2b. udevd then sends its own netlink messages, after executing rules. 3. libudev consumers receive messages from 2b. libudev and udev in general is thus an abstraction of the kernel information exposed in 1. It is possible, easy, and at times strongly preferable to skip the udev stack and just consume 1. messages directly. I know of at least one package which does exactly that on USE=-udev, I can only emphasize that the meaning of USE=udev is completely package-specific. There are several possibilities what to do in an upstream package when libudev can or should not be used, and I for one don't think profiles/ebuilds should neccessarily model them. > It should be enable by default for all Linux users. I disagree. Linux is used more widely than that. > The default shouldn't be "nothing works, until you make it work". I agree completely, but please don't assume that no Linux system will work without USE=udev. I think the viewpoint of rearranging profile inheritance makes a lot of sense. Profiles are super powerful, expressive, and cheap! I think it would be fine to add another level of inheritance for udev. Maybe there is a clever trick with a profile for each desired USE flag? Somehow dynamic profiles? Dunno - just an idea. Thanks! //Peter
Re: [RFC] Commit messages - WAS Re: [gentoo-dev] Re: What means bup?
M. J. Everitt wrote: > I'm thinking something along the lines of the following: > - Line one is limited to / and some Key Word that defines the > type of change made, similar to bugzilla perhaps eg. "REVBUMP, VERBUMP, > EAPIBUMP, BUGFIX, PATCH, FEATUREREQ, OTHER". This would get around the > issue of long package-names and/or overlays and other lengthy prefixes. This would remove one of two information atoms in commit messages, reducing human expression in commit messages to mere 50%, or to 0% for --oneline output. I think that's unacceptably poor usability. > This should satisfy line length limitations, My counter-proposal is to bup the repoman line length limitation. //Peter
Re: [gentoo-dev] x11-terms/xterm up for grabs
Johannes Huber wrote: > I will take it. Thanks. I can help as proxy-maintainer if you like. //Peter
Re: [gentoo-dev] newsitem: baselayout 2.5 changes (round 2)
William Hubbs wrote: > The first change is that ROOTPATH is no longer set. This means all of > the *sbin directories will be added to the default path for all users > instead of just the root user. Maybe add a sentence about why this is changing or even neccessary, to avoid perception of weakened security. //Peter
Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list
Maybe this is a discussion for -project, then? Andreas K. Huettel wrote: > a few outside trolls who > * keep pushing their personal agenda in endless threads, > * confuse their own inability to contribute with being a mistreated underdog, > * and keep commenting opinionated on technical things they plainly have no > clue about (while whining when are told they sprout bulls##t). .. > Andreas K. Hüttel .. > (council, toolchain, perl, libreoffice, comrel) You Sir are IMHO neither fit for the office of council nor of comrel, solely based on your communication style in that one mail. I would not vote for you, and would vote against you if that's even possible. //Peter
Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change
On Wed, Jan 10, 2018 at 9:31 PM, Aaron W. Swenson wrote: > Title: GnuCash 2.7+ Breaking Change > Aaron, but why do we need this news item? 2.7 version is a development version that is not supposed to be used by end users. As far as I understand this backup is a temporary measure until stable release will be out. It's much better to have this version package masked. Then in package mask comment we could note the need for backup. -- Peter.
Re: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)
Andreas K. Huettel wrote: > > Independent of whether William now unsubscribed or not, he's now enjoying a > lengthy (1 year until review) vacation from all Gentoo communication channels. > I don't understand two things about Gentoo: 1. style: How can anyone consider "enjoying a vacation" to be appropriate wording in this context? That is at a minimum tasteless. 2. substance: Why would William be blocked from Gentoo for a year? How and/or where will these two points be clarified? Thanks //Peter
Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists
Daniel Campbell wrote: > On Sun, Dec 03, 2017 at 12:18:04AM +0100, Michał Górny wrote: > > I'd like to establish the following changes to the mailing lists: > > > > 1. Posting to gentoo-dev@ and gentoo-project@ mailing lists will be > > initially restricted to active Gentoo developers. > > I don't think this plan will have the effect you're going for, I agree, and I'll double down on my previous comment on this proposal: I consider the proposal to be the wrong solution. > but let's be honest here: the "RFC" is just a formality; the decision's > already been made. I hope that a mere proposal doesn't automatically mean policy change. > If the "real leaders" of Gentoo want to divide and fragment the > community, it's their prerogative. When there is a request for comments, there should also be comments. :) Far too many fall into the simple trap that is tribalism, and I'd like to encourage everyone on this list to not be that kind of person, because there really is no "us and them", there is only "us". > As we tell users who do something they're not supposed to: You get > to keep the pieces. Well, let's see what happens, now that both developers and non-developers have clearly spoken out *against* this proposal. Kind regards //Peter
Re: [gentoo-dev] We Are All wltjr On This Blessed Day
William L. Thomson Jr. wrote: > No one questions why I stepped down. I have wondered what happened, but haven't felt able to investigate. Please know that I wouldn't take sides without investigating, and I think that an overwhelming majority is also like that. A problem is that you'll only ever hear from those who do take sides, but I think the vast majority doesn't. In the end I think giving up any position comes down to one of two things: either feeling that one can not sufficiently meet expectations, or feeling that others do not meet one's own expectations. I've experienced both. How those happen is probably always a sad story of personal differences. :\ > I let others convince me I was the problem so I went away. Yet things > did not improve in my absence. Maybe I wasn't the problem I hope that everyone always learns. I think almost everyone does. William L. Thomson Jr. wrote: > > doing whatever you did to get banned from GitHub > > You tell me does this make any sense to ban someone from Gentoo's Github? > https://github.com/gentoo/gentoo/pull/1721#issuecomment-300178677 It doesn't make sense to me, because you're trying to help inform a community contributor. But I also don't know any of the "Gentoo Java" context - which I think also matters. Reading the motivation for the ban "not the place to post comments and recount how Gentoo Java is struggling with its staffing needs" and "GitHub .. [is] for code-centric feedback and technical discussions, not about Gentoo-meta issues or the like" I can understand that someone would feel that your comment was out of place, but I don't think that a 14 day ban is an appropriate first response. That said, expectations were clearly not met, all around. The expectations of the community contributor were not met by Gentoo, since (as is mentioned in the ban mail) Gentoo is not a typical GitHub project, where a PR is the entire process into the repo. I think it is perfectly fine to communicate about this in a PR, and I think a Gentoo policy never to do so is a mistake. The expectations of the Gentoo GitHub Project were not met by you, since it seems a PR policy is "Everyone can review pull requests. However, please make sure that your comments are correct and on topic." and your comment was also trying to inform about the larger context, not strictly limited to technical details. I personally disagree with such expectations in the GitHub team, but I can't even be bothered to become a proper Gentoo developer, because the threshold is just too high for me. I would attribute the contributor's (very valid) disappointment to lack of communication, ie. to Gentoo not having set accurate expectations. It is probably true that Gentoo isn't equipped to do so at the moment, so everyone has to learn on their own. Some will get burnt in the process. :\ > https://github.com/gentoo/gentoo/pull/6033 > I felt I should have responded to not be rude. I agree with you, and you seem to always respond politely. While I sometimes find it a bit difficult to understand what you intend to say because of your writing style, it looks to me like you always intend to equip others with useful information. > I still do not respond in kind to others. I think that shows good character. Please keep that up, no matter what others do. To the actual topic of Gentoo Java I think the best you can do is essentially what you are already doing - work on solving your own problems in your own overlay, if there is a kind of informal team working mostly to provide life support. You can try to support them, but you may have very different needs, and if communication doesn't work so well then there can't be an actual team. I rarely use Java, but what I do know about Java supports your argument that Gentoo could need a lot of work for JDK 9, because the expectations/assumptions of the Java ecosystem are quite far apart from those of the Gentoo ecosystem, and if a great solution is even achievable at all then it certainly requires mastering both Java and Gentoo, which likely requires Java people to get into Gentoo rather than the other way around, and both environments have long learning curves, and until there is a critical mass of developers mastering both, there can't really be a team. :\ Kind regards //Peter
Re: [gentoo-dev] We Are All wltjr On This Blessed Day
I'm quite unimpressed by how mgorny and jstein behave there. I wouldn't accept that, were I leading the project. //Peter
Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists
Hi Michał, Michał Górny wrote: > major problems with some of the posters for more than a year. Please believe me when I say that I know what this feels like. I want to applaud and thank everyone who has been tackling/discussing this issue in private, and I especially want to applaud taking action! I however disagree with the proposal to move the problem. I would like to encourage everyone, but in particular devs, to watch this 18 min talk by Donnie Berkholz from 2012, about Gentoo actually: Assholes are Ruining Your Project https://www.youtube.com/watch?v=-ZSli7QW4rg If you don't want to, then the most important take-away as stated by Donnie and supported by my own experience having "my" project ruined is: Do not tolerate bad behavior by anyone! > The problems of more abusive behavior from some of the mailing list > members have been reported to ComRel numerous times. After the failure > of initial enforcement, I'm not aware of ComRel doing anything to solve > the problem. While reading your message, I kept thinking to myself: "isn't this the very purpose of ComRel?" I only have a non-dev understanding of ComRel, but I agree with Matt that inaction in this situation is a failure of ComRel, and that should not be to the detriment of any constructive contributor on gentoo-dev. > A. Bans can be trivially evaded > B. People should be allowed to express their opinion Mh, so-so. It is important to take action which clearly rejects unacceptable behavior. Otherwise any behavior is per definition implicitly accepted, which attracts assholes. > C. The replies of Gentoo developers were worse This should *also* not be accepted. Equal standards for what is acceptable and what is not must apply to everyone. It could be argued that different people deserve different sanctions. I would agree with that only as far as there is a mentoring process in place, requiring a third party to work on eliminating bad behavior. I think that's the purpose of DevRel for developer<->developer, and ComRel for developer<->non-developer. Yes, such mentoring requires a non-negligable committment to non-trivial work. It is clearly not always possible to mentor bad behavior away. Then that person must be shut out to save the environment, whether a long-standing developer or not! Coming back to the concrete proposal, I think a better course of action is to demonstrate strong leadership, by speaking out in force against bad behavior, every time. In order to have something to lean on, it can be super helpful to have a code-of-conduct in place, and was already mentioned. I had to think about code-of-conduct for a long time, before my mental model of them "clicked". I consider them to be about explicitly stating the community expectations for good behavior, and as an agreed-upon reference for (sometimes unpleasant, but incredibly important) forceful action in reponse to bad behavior. > The alternative suggested by ComRel pretty much boiled down to 'ignore > the trolls'. I find this highly inadequate. I urge either ComRel or other leadership to take as forceful action as is neccessary against bad behavior, to uphold a healthy environment. Selective moderation is a more technically sophisticated ban. If possible that's cool. If not possible that's perfectly fine. Just ban. Keep banning if the bad behavior resurfaces with another identity. Please do not relent. It is not fair to yourself or your colleagues. Thank you and keep up the excellent effort everyone //Peter
Re: [gentoo-dev] Re: cmake + ninja vs autotools
William L. Thomson Jr. wrote: > Or uber minimal, can't get much smaller still 5.20s > https://travis-ci.org/Obsidian-StudiosInc/asspr#L165 > https://github.com/Obsidian-StudiosInc/asspr/blob/master/configure.ac Consider AM_INIT_AUTOMAKE([foreign no-define no-installinfo no-installman]) foreign in particular if you would like to skip the various UPPERCASE files in the project root. //Peter
Re: [gentoo-dev] Re: cmake + ninja vs autotools
William L. Thomson Jr. wrote: > Or uber minimal, can't get much smaller still 5.20s > https://travis-ci.org/Obsidian-StudiosInc/asspr#L165 > https://github.com/Obsidian-StudiosInc/asspr/blob/master/configure.ac That takes 2.0s here, on quite old hardware, though with primed cache. > #secondsmatter :) Yeah! :) > The dependency aspect I agree with 100%. I think even cmake has more. cmake itself is the dependency. ;) > Or who cares about end users, its all about saving devs time, no clue. > #mesonbandwagon End users generally consume behind a distribution build process, so yes, it's all optimization for development time, which makes some sense. //Peter
Re: [gentoo-dev] Re: cmake + ninja vs autotools
William L. Thomson Jr. wrote: > I cannot understand why systems get faster, yet configure seems to > take the same amount of time and is super slow. The generated configure scripts can be fork intensive, which is still fairly expensive. But I think the problem is more with poorly written configure source, which is the argument about mastering.. > On small projects configure can take longer than compile... Configure > is my main gripe against make/autotools. Plus all the other stuff, > auto-reconf, autogen, etc. configure having zero dependencies is the killer feature compared to all other options. The tight integration between configure and cross-toolchains is also a very strong point. > The larger the project, the slower configure can be. Doesn't have to be, but it's easy to write poor configure source and difficult to write good source. //Peter
Re: [gentoo-dev] Re: cmake + ninja vs autotools
Martin Vaeth wrote: > > 1. Doing a full clean build [..] the speed of make or ninja is hugely > > offset by the compilation speed, and their overhead is negligible. > > It depends on the definition of negligible. For huge projects like > boost or chromium it is several minutes It's arguably a bug that a projects gets huge. The simplicity of configure+make is difficult to beat, but I also agree that it's difficult or at least tedious to master autotools. That is arguably reason enough to choose meson, but I think I will stay with autotools for a while.. //Peter
Re: [gentoo-dev] Java 9 on Gentoo
William L. Thomson Jr. wrote: > > If you have any suggestions as to what I should look at to better > > understand the OpenJDK build system I would very much appreciate > > them. .. > Build OpenJDK stand alone. Get familiar with that. It used to be that one could not build OpenJDK without already having a working JDK. Has that changed with OpenJDK 9 (IIRC it was planned for OpenJDK 7 :) or not yet, and that is a reason for having icedtea in the mix? //Peter
Re: [gentoo-dev] Open Build Service
On Tue, Nov 14, 2017 at 4:47 AM, Samuel Bernardo < samuelbernardo.m...@gmail.com> wrote: The only feature that would be useful for now is emerge obtaining the > precompiled binary packages to install in containers/VMs from http > rather than nfs[1]. > Samuel, probably I miss something but this should work out of box: https://wiki.gentoo.org/wiki/Binary_package_guide#Web_based_binary_package_host Or do you mean something else? -- Peter.
Re: [gentoo-dev] Package up for grabs
Michał Górny wrote: > W dniu nie, 23.07.2017 o godzinie 16∶13 +0200, użytkownik Manuel Rüger > napisał: > > dev-libs/libgit2 > > I'm going to co-maintain this with the full set (-glib, pygit2). I've > used it in the past, and I think it'll still come in handy > in the future. I too have some interest in libgit2, but not much experience with upstream. I'm thrilled that leio and mgorny are on it, I don't think I can contribute much. > > net-libs/libssh2 > > I'll co-maintain this as well as an important dep of libgit2. FYI I'm part of upstream. The project mailing list is a perfect point of contact, but you can reach out to me as well. //Peter
Re: [gentoo-dev] Changing PMS to Portage Manager Specification
Alexander Berntsen wrote: > While the PMS perhaps hasn't been an unequivocal success, it's still a > good effort with some success. I would be disappointed to see the > proposed change, and view it as a bad sign for Gentoo. As far as technical documentation about how ebuilds work (the core of Gentoo, but also many other distributions; I have created several of my own), PMS is an absolutely amazing document! It comes down to whether Gentoo is a "meta-distribution" with absolutely amazing generic tooling (including portage), or "simply" a source-based distribution with an arbitrary package format. PMS has tremendous value, and yes, EAPI is a process, and I am sure that portage developers gnash their teeth at blockers stemming from PMS, but I wholeheartedly believe that Gentoo, PMS and Portage are all better off for it. Without knowing specifics I guess I would suggest to the original poster to create new tooling for the job that needs to be done. Maybe even a fork of portage, at first only used in your (derivative) Gentoo distribution? Just my idea for a possible solution. //Peter
Re: [gentoo-dev] Allow variable refs in HOMEPAGE
Michael Orlitzky wrote: > All this is to say that "easy to read" is in the eye of the beholder. > For ebuilds in the tree, the beholder is usually the maintainer, which > is why I think the choice should be left up to him. I think what mgorny says is that locality of ebuilds is an important factor. > Our ebuilds are bash programs, and in source code, "as little > duplication as possible" is a strong contributor to "easy to read." Here's an idea: Could a little bit of automated (but obviously checked!) de-duplication be made [an optional] part of adding an ebuild into the tree, and please everyone? //Peter
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On Mon, Jul 31, 2017 at 6:11 PM, Rich Freeman wrote: > On Mon, Jul 31, 2017 at 10:52 AM, Alec Warner wrote: > > Sorry, to be clear the conclusion I was hoping to draw is that one has 2 > > repos instead of 1. > > > > 1) Rolling. > > 2) Stable. > > > > Rolling is typical ~arch Gentoo. People in rolling can do whatever they > > want; they can't affect stable at all. > > > > Stable is an entirely separate repo, a fork, where CPVs are pulled from > > Rolling into Stable. If Stable wants to keep a gnarly old version of some > > package around; great! But the rolling people don't have to care. > > > > This seems like it would be fairly painful to maintain. You'd need to > constantly pull in new packages, and prune out old ones. It would > duplicate many of the functions maintainers already do. I doubt > anybody would go to the trouble to make this happen. > Long time ago releng team did something similar. We defined stable as tested distribution that has all security updates merged back. From my experience what made that efforts very tedious was that there were packages that do not specify minimum required versions for dependencies. Thus we had to duplicate maintainer's work and check lot's of dependencies again. Also when we speak about stable tree we first should define what stability are we talking about? What do we guarantee? ABI/API compatibility or that it is expected "just work" (whatever this means)? -- Peter.