Re: [gentoo-dev] RFC: new category for container related packages, instead of app-emulation
> On Thu, Aug 5, 2021 at 2:44 PM Georgy Yakovlev wrote: > > We've been collecting more and more container related packages in > > app-emulation/* > > What do you think about finally moving those packages to separate category? > As always my opinion is that: > (a) Categories were a design mistake. > (b) The mistake is hard to fix. > (c) It's basically low-value to try to 'correctly' categorize packages because of A. > (d) Recategorizing means a bunch of stuff has to be updated. > Do people actually care what category things are in? I just use > --search or eix or whatever and the category is just this...bad > concept we attach to packages for silly historical reasons.. -A Gentoo portage has an awful lot of categories. In contrast, Void Linux has all packages not subdivided into categories. I counted for FreeBSD ports, 63 categories; pkgsrc, 48 categories (NetBSD, but ported to other mostly (quasi-)Unix OSes). My count could have been just slightly off. I count 165 for Gentoo, could be slightly off. I count 61 for Arbor, from Exherbo. I count 125 categories for Haiku ports, which is modeled after Gentoo but not nearly as many packages. Tom
Re: [gentoo-dev] [News review] LibreSSL support discontinued
> On Sun, 2021-01-03 at 21:47 +0100, MichaŠGórny wrote: > Hello, > > Please review the news item inlined below. This is based on what > > I discussed with blueness (LibreSSL team lead). The news item is kinda > > long-ish because I wanted to include the full rationale since I believe > > our users will find it desirable to know it. > > If it's ok, I'd like to push it soonish. This will give people around > > 4 weeks to prepare and/or migrate their systems manually before being > > hit by the masks. Afterwards, we'll mask libressl with a prolonged > > removal date. I'm thinking of 3 months since I suspect that our > > packages will start strongly requiring OpenSSL by then. > > I'm mentioning the LibreSSL overlay since one of our users is > > interested in maintaining it. It will probably be the best alternative > > for users who want to continue fighting the lost cause without causing > > major problems for Gentoo mainline. > Thank you all for feedback. I've just pushed the last version. > Best regards, > MichaŠGórny Just a couple days ago, I found an article through Distrowatch: Void Linux is dropping LibreSSL in favor of OpenSSL. 2021-02-28 Void to switch back to OpenSSL voidAt the start of the year we mentioned the Gentoo project was considering dropping support for LibreSSL, a fork of the OpenSSL cryptography library. While LibreSSL was intended to be smaller, lighter, and more secure, a lot of work and improvements have gone into OpenSSL while not many Linux packages are tested against LibreSSL, causing problems for their maintainers. The extra effort to maintain compatibility with LibreSSL while new features arrive in OpenSSL first has caused the Void team to switch from running LibreSSL back to OpenSSL. "The Void Linux team is switching back to OpenSSL on March 5th, 2021 (2021-03-05). For most users, there should be no noticeable change. If you have any packages installed that are no longer provided by Void, or your system has explicit dependencies on LibreSSL, you will of course need to take action to ensure your system continues to function after the switch." URL of Void Linux article is https://voidlinux.org/news/2021/02/OpenSSL.html Tom
Re: [gentoo-dev] Make 'man' global USE flag from currently local
> Hi all, > Â I am proposing to make the `man` USE flag into a global one. > Currently it is used by ~45 packages most of which have the same > description 'Build and install man pages': > https://packages.gentoo.org/useflags/man > Hopefully no objections to this part? > Cheers, > Aisha Seems like a good idea to me. Tom
Re: [gentoo-dev] RFC: dropping support for uclibc-ng
> I was using uclibc-ng builds for MIPS to build netboot images between 2017 > and 2019 to refine my build processes. uclibc-ng still produces smaller > overall binaries and libs for the netboot than musl does (usually ~1MB > smaller, which is actually significant, especially on SGI IP22 systems). > Unfortunately for uclibc-ng, it stopped working for me in ~2019. I have no > clue why, either. The March 2019 uclibc-ng MIPS stage3 I built internally > works perfectly fine when you unpack it and leave it alone, but as soon as > you compile *anything* more recent with the compiler that's when the > breaking begins. > Rebuilding ncurses in this stage3 will break Python, which breaks emerge. > Never figured it out. I can trace the failure using GDB to a point in > Python, but not much farther beyond that. I assume the true cause is > something in uclibc-ng itself. Upstream seems to like to borrow chunks of > glibc for things, and I wonder if that may be partly to blame. > I eventually gave up and went to musl for MIPS/o32. musl quite literally > JustWorks(). It's great. Even with that tiny bit of bloat in the netboot > build (workable, cause I needed to make NFS Root an option anyways). > So long story short, I won't shed any tears if uclibc-ng goes away. > Joshua Kinard I wonder if uclibc-ng people fixed the bugs since your ill fortune, or if uclibc-ng development has fallen off. Since musl works so much better for you, you will probably not want to go back. How did you build your March 2019 stage3, or where would I go on Gentoo website? I would naturally seek something more current, glibc or musl probably preferable to uclibc-ng. Tom
Re: [gentoo-dev] RFC: dropping support for uclibc-ng
from "Anthony G. Basile" date: Tue, 5 Jan 2021 16:05:44 -0500 > On 1/5/21 8:43 AM, Jaco Kroon wrote: > > Hi Thomas, > > On 2021/01/05 13:08, Thomas Mueller wrote: > >>> I'd like feedback from people about the possibility of dropping support > >>> for uclibc-ng. If you are unfamiliar, its the successor to uclibc as a > >>> C Standard Library for embedded systems, ie a replacement for glibc > >>> bloat. However, it is inferior to musl which serves the same purpose > >>> and which has now well supported in Gentoo. > >>> I know people want musl support, but does anyone even care about > >>> uclibc-ng? If not, I can work towards deprecating it and putting what > >>> little time I have towards musl. > >>> Anthony G. Basile, Ph.D. > >>> Gentoo Linux Developer [Hardened] > >> Are you the only Gentoo developer working on musl and uclibc-ng? > I'm the only one working on uclibc-ng. There are some people helping > with musl, especially the overlay. > >> One thing I might try with a Gentoo uclibc-ng system is convert to musl or > >> glibc using crossdev. > >> From what I see on the internet, there is more support for musl than > >> uclibc-ng, and more people working with musl than with uclibc-ng. > It does seem that musl is winning the embedded libc race. > >> There is a musl-cross-make cross-toolchain that can be built from non-musl > >> or even non-Linux. > >> https://github.com/richfelker/musl-cross-make > > I've used crossdev in the past. It was a nasty experience, but I > > believe crossdev in Gentoo is getting better and better, and it supports > > many more targets. I can't imagine crossdev could be nastier than Cross Linux From Scratch (CLFS). CLFS seems to have low activity, is updated only sporadically, and some of the commands have syntax errors and have to be modified to fit a different implementation of bash. Even installing Linux kernel headers does not work, fails with error messages, strange to anybody familiar with FreeBSD and NetBSD. Idea that Linux kernel headers need to be sanitized makes me wonder if this is an idiosyncrasy peculiar to Linux. "make headers_install" is not a trivial matter. > Yes it is, which is why I'm preparing pre-build stage3's on several > arches so you don't have to x-compile. I've done the nasty part for you. Maybe explain on website what it takes to prepare a pre-build stage3 (or stage1 or 2?)? There are also several cross-toolchain systems such as Pengutronix (www.ptxdist.org), OpenADK (www.openadk.org), crosstool-ng (crosstool-ng.org) that can be configured for glibc, uclibc-ng, musl, bare metal or other arches. > >> From what I have seen, musl looks more promising than uclibc-ng, and more > >> user- and developer-friendly. > >> Unless somebody wants to take over uclibc-ng for Gentoo, I say better for > >> you, with your limited time, to drop uclibc-ng in favor of musl. > Correct, if I had the time, I'd continue to support both. But my time > is limited, so I need to concentrate. I'm just looking for anyone to > scream if I'm destroying their world by dropping uclibc-ng. If no one > does, then I'll begin the process of removing it from the tree. > > Not doing embedded work at the moment, but just out of hand as of right > > now if I had to make a choice I'd definitely look at MUSL as first > > choice. So +1 for that suggestion. > > Kind Regards, > Jaco Tom
Re: [gentoo-dev] RFC: dropping support for uclibc-ng
> I'd like feedback from people about the possibility of dropping support > for uclibc-ng. If you are unfamiliar, its the successor to uclibc as a > C Standard Library for embedded systems, ie a replacement for glibc > bloat. However, it is inferior to musl which serves the same purpose > and which has now well supported in Gentoo. > I know people want musl support, but does anyone even care about > uclibc-ng? If not, I can work towards deprecating it and putting what > little time I have towards musl. > Anthony G. Basile, Ph.D. > Gentoo Linux Developer [Hardened] Are you the only Gentoo developer working on musl and uclibc-ng? One thing I might try with a Gentoo uclibc-ng system is convert to musl or glibc using crossdev. >From what I see on the internet, there is more support for musl than >uclibc-ng, and more people working with musl than with uclibc-ng. There is a musl-cross-make cross-toolchain that can be built from non-musl or even non-Linux. https://github.com/richfelker/musl-cross-make >From what I have seen, musl looks more promising than uclibc-ng, and more >user- and developer-friendly. Unless somebody wants to take over uclibc-ng for Gentoo, I say better for you, with your limited time, to drop uclibc-ng in favor of musl. Tom
[gentoo-dev] Re: Last rites: dev-ada/langkit, dev-ada/libadalang{,-tools}, dev-ada/gps, dev-ada/gnatcoll-{bindings,db}
> # Alfredo Tupone (2020-08-16) > # Ported to py3.8 but not yet released > # Masked to allow py2.7 removal > # MichaŠGórny (2021-01-01) > # Masking for removal to prevent eclass from crashing on these packages. > # Removal in 30 days. > dev-ada/langkit > dev-ada/libadalang > dev-ada/libadalang-tools > dev-ada/gps > dev-ada/gnatcoll-bindings > dev-ada/gnatcoll-db > Best regards, > MichaŠGórny What will replace (or has already replaced) these packages? What is the future of Ada support in Gentoo? Tom
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Excerpt from MichaŠGórny and previous post: > > Further, LibreSSL comes out of the OpenBSD project, which has a good > > reputation on code quality. > I could buy that if it actually said anything about LibreSSL code > quality. So far you're guessing that it might or might not, especially > given it is forked from an apparently 'inferior quality' code. > However, I do have serious doubts about LibreSSL quality given that: > 1. Non-OpenBSD systems are not first class citizens, as you yourself > pointed out. > 2. The library is an intrusive replacement for OpenSSL. In the default > setup, it is neither co-installable with OpenSSL, nor a drop-in > replacement. > 3. The upstream declares OpenSSL version constants pretty randomly, > without actually matching OpenSSL API. > 4. The upstream has actively tried to force people into using their > product by tight coupling and forced incompatibility. > 5. Apparently nobody is issuing CVEs for LibreSSL while > the vulnerabilities clearly do happen. My limited experience with OpenBSD does not give credence to their code quality. Latest experience was from liveusb-openbsd.sourceforge.net. I was able to download the image and write to 64 GB USB stick. I managed to get it to boot, but couldn't find my way around. It couldn't read my GPT-partitioned hard drive, and I was not about to take big risks regarding my data. OpenBSD fdisk is quite primitive compared to NetBSD (gpt), FreeBSD (gpart), Linux (gdisk: also available for FreeBSD, Windows and macOS). OpenBSD seems to have dubious compatibility with NetBSD, FreeBSD and Linux software packages, and is not good at peaceful coexistence with NetBSD, FreeBSD, Linux and probably other OSes on the hard drive. I looked in NetBSD pkgsrc, FreeBSD ports, Gentoo portage, and Void Linux packages, and libressl was there, which is not to say how compatible it is or how much patching is needed. Tom
[gentoo-dev] Re: Python 2.7 cleanup: plan B
> Hi, everyone. > TL;DR: we might keep Python 2.7 supported as a build-time dependency > of a few packages as necessary, while removing the eclass support for > installing packages for py2.7. > As I've mentioned earlier, the plan is to get rid of Python 2.7 target > support at the beginning of 2021. The plan was to last rite all > remaining packages failing to support Python 3 at 2021-01-01, and remove > the eclass support on 2021-02-15. At the same time, the Python > interpreter was going to stay around for as long as necessary. > I've also mentioned that there is a high risk that this will not be > possible because of a few large entities ignoring the problem > and failing to port their build system scripts away from Python 2. > We can't really last rite all major web browsers, and postponing > the deadline indefinitely is not a good solution either. > Therefore, I advise the following plan B: if it is impossible to remove > Python 2.7 support from packages entirely, the support for installing > Python packages for Python 2.7 will be removed. However, there will be > exemptions granted for build-time dependencies on the Python interpreter > to keep things working, for as long as the interpreter itself is going > to stay. > The candidates for exemptions are pypy/pypy3 (CPython 2.7 is needed for > bootstrap on new platforms), Mozilla products, WebKit and WebKit-based > browsers. > Best regards, > Micha=C5=82 G=C3=B3rny I believe net-print/hplip also depends on Python 2.7. This is print/hplip in NetBSD pkgsrc and FreeBSD ports. Or did they fix that recently? Possibly hplip is mainly for older HP printers, not sure about what's going on with HP laser printers more recently. Maybe that's why there has been reluctance to fix the Python 2.7 dependency? I have such an HP printer (LaserJet M1212nf MFP), and my experience dissuades me from ordering anything further from HP. I think most everybody involved with open-source would agree that proprietary binary plugins suck. Tom
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 What about NetBSD and FreeBSD? I use NetBSD and FreeBSD but am not interested in OpenBSD, inside or outside Gentoo. I am also curious about whether crossdev could be used to cross-compile to Linux (glibc, musl or uClibc-ng). My impression, from Gentoo website, was that (Net, Open, Free)BSD prefix support was no longer active. Tom
