Re: [gentoo-dev] Getting rid of USE=unicode
On 12/30/20 1:34 PM, Andreas K. Huettel wrote: > Am Mittwoch, 30. Dezember 2020, 19:53:25 EET schrieb Aisha Tammy: >> >> Yes, this sounds nice. >> What about packages which rely on/give unicode support outside of this flag? >> Like the global icu flag, which supposedly needs dev-libs/icu ? >> > > Hmmm... good point. I thought too simple. > > 1) We want to enable unicode unconditionally whereever that is possible > without much impact. > 2) If that pulls in large libraries like icu, a useflag remains useful. > > So maybe instead of any use.forcing we should just go through the ebuilds and > > a) reduce the number of occurences of IUSE=unicode as much as possible > b) switch to IUSE=icu or similar where that makes sense > dilfridge++ Sounds awesome.
Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?
On Wed, Dec 30, 2020 at 9:50 PM Peter Stuge wrote: > > 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. I'm having trouble making sense of this sentence. Did you mean to write "libressl" instead of "libretls" somewhere? Anyway, it seems like the people maintaining libressl in Gentoo are really not interested in keeping it going. A libtls wrapper around openssl seems much more manageable to me, and that should probably be the default option for people.
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] Getting rid of USE=unicode
there are not too many packages to look at:
:; git grep -P IUSE.+unicode.*\"|awk -F/ '{print $1 "/" $2}'|sort -u|wc -l
82
so it should ot take too uch effort.
and it definitely would be worth it!
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
[gentoo-dev] Reminder: Python 2.7 & 3.6 cleanup incoming
Hello, everyone. I would like to issue one final reminder that Python 2.7 and 3.6 support in Gentoo is nearing its end. Per the timeline announced earlier: 1. On 2021-01-01 the remaining blocker packages will be last rited, with non-extensible 30 day removal time. This means specifically: py2 package: games-engines/renpy its dependency: dev-python/numpy-python2 its revdeps: games-misc/katawa-shoujo games-rpg/asphyxia games-rpg/sakura-spirit games-rpg/the-royal-trap 2. Starting 2021-01-01, I will aggressively push towards stabilizing and cleaning up packages whose old versions block py2.7 or py3.6 removal. 3. As soon as all blockers are gone, I will disable py2.7 and py3.6 in the eclasses (py2.7 will still be permitted for python-any-r1). 4. After disabling py3.6, I will last rite the remaining backports with 14 day removal time: dev-python/aiocontextvars dev-python/contextvars dev-python/dataclasses Note that as indicated earlier, we are not going to remove Python 2.7 support entirely -- we will only prohibit installing any packages using Python 2.7 at runtime. The python-any-r1 eclass will continue supporting it for the time being (I will submit a patch for review later on). Python 3.6 support will be removed entirely from the eclasses but the interpreter will stay for as long as it continues being maintainable. Upstream is planning to issues security fixes until 2021-12, and after that we will move it to ::python. Both Python 2.7 and Python 3.6 will still be usable inside virtualenv (though note that new versions of virtualenv may remove support for py2.7). -- Best regards, Michał Górny
Re: [gentoo-dev] Getting rid of USE=unicode
On 12/30/20 12:46 PM, Andreas K. Huettel wrote: > Hi all, > > since utf8 encoding is everywhere by now, and since switching the useflag > unicode off without taking precautions is a way to hose your installation, I > would propose to medium-term get rid of this flag. > > Suggestion: > > 1) use.force unicode now/soon in the default profiles > > 2) step by step, modify ebuilds to enable the functionality unconditionally > (and if necessary fix depstrings) > > 3) at some point the flag is gone > > Opinions? > > Cheers, > Andreas > Yes, this sounds nice. What about packages which rely on/give unicode support outside of this flag? Like the global icu flag, which supposedly needs dev-libs/icu ? Cheers, Aisha
Re: [gentoo-dev] Getting rid of USE=unicode
Am Mittwoch, 30. Dezember 2020, 19:53:25 EET schrieb Aisha Tammy: > > Yes, this sounds nice. > What about packages which rely on/give unicode support outside of this flag? > Like the global icu flag, which supposedly needs dev-libs/icu ? > Hmmm... good point. I thought too simple. 1) We want to enable unicode unconditionally whereever that is possible without much impact. 2) If that pulls in large libraries like icu, a useflag remains useful. So maybe instead of any use.forcing we should just go through the ebuilds and a) reduce the number of occurences of IUSE=unicode as much as possible b) switch to IUSE=icu or similar where that makes sense -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Getting rid of USE=unicode
Hi all, since utf8 encoding is everywhere by now, and since switching the useflag unicode off without taking precautions is a way to hose your installation, I would propose to medium-term get rid of this flag. Suggestion: 1) use.force unicode now/soon in the default profiles 2) step by step, modify ebuilds to enable the functionality unconditionally (and if necessary fix depstrings) 3) at some point the flag is gone Opinions? Cheers, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?
On Wed, 2020-12-30 at 15:02 +, Peter Stuge wrote: > 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. dev-libs/libretls already does that. -- Best regards, Michał Górny
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?
On 12/29/20 6:06 PM, David Seifert wrote: > > If you want to provide an alternative, you have to subsume the API, not > make it superficially compatible, only to find out that the you need to > mask out a ton of stuff with macros. Agreed. If libressl hadn't failed on this point, we would not be having this conversation. They promised it would be API compatible and it started that way, but not anymore. This became annoying even to me with my other packages like stunnel, where with every bump I had to create a new patch with macros based on versions. This is not something we want to saddle the rest of Gentoo with. Nor do we want to burden upstream teams to have to follow libressl's insanity. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On 12/29/20 5:41 PM, Peter Stuge wrote: > 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. > I am sympathetic to not degrading into a monoculture. If I would characterize my contribution to Gentoo over the years it would be "alt-everything". The reason being that competition between alternatives is a good thing and time will tell which way is best. But <- here's the "but" At some point a particular path may have to be dropped because it just doesn't provide any clear advantages. There was nothing wrong with adding libressl as an alternative in 2014 since it had promise. And now, years later, I see nothing wrong with removing it. It hasn't delivered. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
> > 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. Exactly that is what would require even more hacks. Given how many different and more or less hackish build systems exist in the Gentoo tree, this is just not feasible. > > -> 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. Dito... Please remember, the point is to keep this somewhat maintainable. > > 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. Well, if it just drops the library somewhere where nothing can use it... that can for sure be done, but also does not really help anyone. > > 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? No idea to be honest, and not much opinion on this. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice)
[gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?
On Mon, 2020-12-28 at 09:56 +0100, Michał Górny wrote: > TL;DR: is there really a point in continuing the never-ending always- > regressing struggle towards supporting LibreSSL in Gentoo? Since the discussion has grown quite, let's summarize what was said so far. It seems that all respondents so far unanimously agree that the current state of libressl is suboptimal. Unless I've missed something, we also all agree that developers shouldn't put additional work to continue supporting it in their packages. What we don't seem to agree on is how we should proceed with libressl itself and its existing support in the future. I think the key points right now are that: 1. Users shouldn't take switching between OpenSSL and LibreSSL lightly. 2. We should probably discourage users from using LibreSSL on new systems for the time being. 3. We need to establish the way forward and inform the users about it. 4. We should probably wait for USE=bindist updates (due to patents expiring) and dev-libs/libretls support (whenever possible) before doing anything. In my opinion, the bare minimum we should do is to mask the libressl flag. This should ensure that users do not take it lightly, and can get an appropriate warning (from the mask message) if they really wish to switch. The downside of that is that it will implicitly force switching back existing systems, unless sysadmins take care to unmask the flag first. I think this can be solved by issuing a news item in advance. However, if we stop proactive downstream patching of LibreSSL support (which we seem to agree on), the existing LibreSSL systems may become unmaintainable (I can already imagine the super-unreadable Portage slot conflict messages). A reasonable compromise could be to maintain the necessary patching in libressl overlay. If LibreSSL team (or anybody else) is willing to take care of that, we should mention that in the news item. The fate of LibreSSL is a congestion point here. While I don't mind keeping it by itself, I don't think it's prudent to keep it if it becomes practically impossible to use it, and what I'd really like to avoid is giving users false hope. The news item should clearly indicate what's going to happen and at least approximately when. I think the three main ways forward from here would be to either: 1. Keep LibreSSL for indefinite time (possibly masked) but indicate that using it will become more and more difficult. Users will either have to use libressl overlay or local hacks to avoid conflicts with packages that do not support it. 2. Eventually move LibreSSL to libressl overlay. I think this is the best option if overlay is going to be actively maintained. It also opens other interesting options, such as providing a dev-libs/openssl meta-replacement to avoid the added complexity of USE=libressl while providing clean subslot rebuilds. 3. Eventually remove LibreSSL. I think that we should first reach an agreement on how to proceed, then start preparing the news item with clear deadlines for each step. -- Best regards, Michał Górny
Re: [gentoo-dev] Last rites: media-libs/jpeg
On Wed, 30 Dec 2020 12:54:59 +0100 Michał Górny wrote: > # Michał Górny (2020-12-30) > # Unmaintained. Entirely replaced by media-libs/libjpeg-turbo, > # to the point that reverse dependencies no longer build with > # media-libs/jpeg. The two libraries are binary-incompatible, > # and the current method of switching between them is incorrect. > # Removal in 30 days. Bug #762634. > media-libs/jpeg It's worth noting that libjpeg-turbo is now an official reference implementation. https://jpeg.org/items/20190204_press.html Also of interest is the fact that libjpeg-turbo can be built to be ABI-compatible with jpeg-7 and jpeg-8, though not the current jpeg-9. I added a turbo-based media-libs/jpeg-compat for version 8 to steam-overlay. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpAmU8tbJTZQ.pgp Description: OpenPGP digital signature
[gentoo-dev] Last rites: media-libs/jpeg
# Michał Górny (2020-12-30) # Unmaintained. Entirely replaced by media-libs/libjpeg-turbo, # to the point that reverse dependencies no longer build with # media-libs/jpeg. The two libraries are binary-incompatible, # and the current method of switching between them is incorrect. # Removal in 30 days. Bug #762634. media-libs/jpeg -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Wed, 2020-12-30 at 11:41 +0100, m1027 wrote: > mgorny: > > > On Tue, 2020-12-29 at 16:12 +0100, Toralf Förster wrote: > > > On 12/29/20 2:57 PM, m1027 wrote: > > > > - removing libressl, installing openssl, maybe wget then, followed > > > > by the rest? > > > remove is sufficient b/c emerge then immediately advices a > > > @preserved-rebuild - at least that's the way it works here at the > > > tinderbox (in the opposite direction FWIW) > > > > > > > I'm not sure if you meant it but it reads as if you were talking about > > removing the package. This is incorrect. > > > > You need to disable the USE flag and then --changed-use (or --newuse) > > rebuild everything with the flag. If the depgraph is clean, emerge > > should happily trigger the rebuild along with automatic replacement of > > dev-libs/libressl with dev-libs/openssl. > > > > However, it's a good idea to run the same command with --fetchonly > > first, to make sure that all distfiles are in place, in case wget got > > broken in the process. > > It might not be the place to discuss emerge dependency details here, > take it as some initial feedback on the transition from libressl to > openssl. > > The general way to go seems indeed: > > - remove libressl from USE flags, also adjusting curl_ssl > - initial emerge ... --fetchonly: to my surprise not always required > - emerge -autDUN @world > - finally the usual @preserved-rebuild I'm surprised this is necessary. -N should have rebuilt everything, unless: 1) you had some packages installed that are no longer in @world depgraph, or 2) packages have automagic dependencies. If you see things like this, it's worth investigating and reporting bugs if it's 2. > - On some systems another @world update revealed again a lot > - This also worked over ssh > > The systems I tried so far > > - 2x Gnome desktop systems, close to the USE defaults, went smoothly > - 1x Raspberry Pi over ssh: still working, ;-) okay so far > - 1x Developer system with some smaller issues > > The issues I had: > > - hostapd: when with +internal-tls, some build issue with > libtommath; when with -internal-tls it required openssl -bindist; > I did not investigate, just uninstalled hostapd yet > > - openssl+bind+openssh: conflict triggered to do +/-bindist for > openssl; solution was -bindist everywhere (see other posts on > bindist already) As mentioned somewhere else in this thread, USE=bindist is going to be revisited in the next few days, since some significant patents expire by 2021. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
mgorny: > On Tue, 2020-12-29 at 16:12 +0100, Toralf Förster wrote: > > On 12/29/20 2:57 PM, m1027 wrote: > > > - removing libressl, installing openssl, maybe wget then, followed > > > by the rest? > > remove is sufficient b/c emerge then immediately advices a > > @preserved-rebuild - at least that's the way it works here at the > > tinderbox (in the opposite direction FWIW) > > > > I'm not sure if you meant it but it reads as if you were talking about > removing the package. This is incorrect. > > You need to disable the USE flag and then --changed-use (or --newuse) > rebuild everything with the flag. If the depgraph is clean, emerge > should happily trigger the rebuild along with automatic replacement of > dev-libs/libressl with dev-libs/openssl. > > However, it's a good idea to run the same command with --fetchonly > first, to make sure that all distfiles are in place, in case wget got > broken in the process. It might not be the place to discuss emerge dependency details here, take it as some initial feedback on the transition from libressl to openssl. The general way to go seems indeed: - remove libressl from USE flags, also adjusting curl_ssl - initial emerge ... --fetchonly: to my surprise not always required - emerge -autDUN @world - finally the usual @preserved-rebuild - On some systems another @world update revealed again a lot - This also worked over ssh The systems I tried so far - 2x Gnome desktop systems, close to the USE defaults, went smoothly - 1x Raspberry Pi over ssh: still working, ;-) okay so far - 1x Developer system with some smaller issues The issues I had: - hostapd: when with +internal-tls, some build issue with libtommath; when with -internal-tls it required openssl -bindist; I did not investigate, just uninstalled hostapd yet - openssl+bind+openssh: conflict triggered to do +/-bindist for openssl; solution was -bindist everywhere (see other posts on bindist already) - old android-tools-6.0.1_p79: build issue mentioning ssl; not ivestigated further, just uninstalled Thanks
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Wed, 2020-12-30 at 09:08 +0100, Marcel Schilling wrote: > On Tue, Dec 29, 2020 at 11:31:32PM +0100, Michał Górny wrote: > > What I'm really missing in all the replies is a single reason why > > LibreSSL would be better for anyone. Not 'it's an alternative', not > > 'I don't trust' but a real proper, verifiable argument 'LibreSSL is > > better in this regard'. > > I guess that is due the fact that you dismiss arguments that are valid > reasons for others (incl. me) but apparently not sufficient for you, > like my situation where 'It works on all my systems, and switching would > mean work for me and at least a risk of downtimes'. I don't dismiss that. If I had, I wouldn't be bothering with the whole discussion and just kill it. I just draw a different conclusion than you do. Having systems that do work with LibreSSL today doesn't guarantee the same for the foreseeable future. If anything, I prefer to ask the existing users to perform a conscious migration today, than wait till things become really unusable and more users are forced to migrate their systems without realizing the risks. It's all nice to say that LibreSSL will be usable in the near future but that's just plain lying. We're between LibreSSL upstream that explicitly rejects any idea of interoperability with OpenSSL, and other upstreams that plain reject the idea of bending their software to work with LibreSSL. I'm sorry to say but in my opinion LibreSSL's team attitude is to blame in the first place here. If someone forks something, deliberately breaks compatibility and then tries everyone to use his work, what else would you expect to happen? -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
On Tue, Dec 29, 2020 at 11:31:32PM +0100, Michał Górny wrote: > What I'm really missing in all the replies is a single reason why > LibreSSL would be better for anyone. Not 'it's an alternative', not > 'I don't trust' but a real proper, verifiable argument 'LibreSSL is > better in this regard'. I guess that is due the fact that you dismiss arguments that are valid reasons for others (incl. me) but apparently not sufficient for you, like my situation where 'It works on all my systems, and switching would mean work for me and at least a risk of downtimes'. I understand that if security of OpenSSL is much better than LibreSSL (I have also not seen 'proof' of this, just 'more users mean better security per se', so I guess I should switch from Gentoo to Ubuntu for my desktops and CentOS for my servers if I care about security), I should switch back, but for me, not having to touch working systems is a valid reason to keep the system around. Since I can't contribute the work needed to keep it around, I'll have to live with the consequences of whatever the devs decide. And I will. Just don't expect me to pretend like you are doing me a favour. ;-) Best, Marcel
