How to get a package removed from #Gentoo?

1. Add a new #NIH dependency.
2. The dependency turns out to use coherent.build. Nightmare! Oh, wait, apparently coherent.build generates source distributions that use flit.core (understandable; coherent.build is unusable).
3. The dependency depends on chardet (the project famous for GPL copywashing). Okay, technically it works with the older version, and the dependency is optional with poor person's fallback, so I guess it would be fine.
4. But hey, this package is not used by anything, and the last package using it in Gentoo was removed in 2020, after not being touched for 4 years already. Also, it is unmaintained upstream since 2017, so I guess there's negligible risk of it ever coming back.

#Python

Fun oneliner:

gpy-impl -@dead -3.11 -pypy3_11 *.ebuild && copybump $(git diff --relative --name-only .) && { check-revdep && pkgcommit -sS . -m 'Remove py3.11 (per scipy)' || git restore -WS .; }

#Gentoo

Kinda related to https://social.treehouse.systems/@ariadne/116418712432034431

People are sometimes like "${BigCompany} uses #Gentoo, so cool" or "they stopped using it, so sad". And I'm like, "why should we care?"

Do they donate money to Gentoo? They don't. And if they did, it would probably come with obligations making this not worth it.

Do they contribute back? Rarely, and if they do, they are unreliable. They benefit more than we do. They just want to dump the packages they need, quickly duct taped together, so that we would maintain them going forward. Their employees rarely reveal that they're paid to do this, and if they do, it's not so they'd be held to higher standards, but to emphasize their importance: "you must placate us."

Well, sometimes they hire Gentoo developers. It's nice that these developers get some gratification for their work, especially if they're able to continue contributing on work time. But in the end, company priorities win. We are either left with loads of new packages with no maintainer and unclear significance, or a Google employee who appeared every once in a while to dump a bunch of ChromeOS patches and never bothered handling the fallout.

So, sorry, but I'd rather care for volunteers who want to make Gentoo better, than companies who see some profit incentive in it.

PS. I'm probably focusing too much on the negative aspects, and we likely had some positive interactions that are far less known and usually don't meet with such fanfare.

PSA: The yearly #Gentoo #Python switch planned for 2026-06-01. CPython 3.14 becomes the default, 3.11 and #PyPy 3.11 go out. The latter fills me with sadness but keeping it is unrealistic now that projects are aggressively pushing for 3.12+.

Of course, we'll continue shipping the interpreters, so you can use venvs if you like. However, that's going to become harder to use since many projects either don't ship PyPy wheels or don't work on PyPy at all without patching.

We will revisit PyPy support if a version compatible with Python 3.12 appears in reasonable time.

https://public-inbox.gentoo.org/gentoo-dev/20260412164104.429630-1-mgorny@gentoo.org/T/#u
https://public-inbox.gentoo.org/gentoo-dev/58cefccb3d0758671537715f4ddb34d59c938461.camel@gentoo.org/T/#u

It's really great that #Gentoo no longer has to rely on such uncultured solutions as using scp / rsync to push a bunch of distfiles to a public_html directory that's then exposed on a HTTP server. Now I just have to… [checks notes]

1. Use 'kup putraw' to put the kernel patchset on distfiles mirror.
2. Wait an hour for mirrors to sync.
3. Start building new kernels.
4. Rsync kernels from build hosts to the local machine.
5. Use a complex script involving 'kup ls ... | grep' and `kup putraw ...` to upload the built kernels.
6. Wait an hour for mirrors to sync.
7. Check if all kernels were uploaded correctly.
8. Push new kernels.

If you're wondering what I'm doing on this fine morning: I'm recursively wgetting ~140G of old #Gentoo dist-kernel binary packages (that nobody really cares about) just to re-kup-load it to the same hypervisor after renaming and PGP-signing them. At roughly 14 MiB/s.

Praise be overengineered solutions.

Yes, I could be instead spending hours trying to figure out PGP agent forwarding.

Gentoo Linux Begins Codeberg Migration In Moving Away From GitHub, Avoiding Copilot
https://www.phoronix.com/news/Gentoo-Starts-Codeberg-Use

#ai #copilot #github #gentoo #opensource

Inevitable moment:

f4e4ddaf69337 dev-build/steve: is no longer simple

#Gentoo

New on my #Gentoo blog: One #jobserver to rule them all

"""
A common problem with running Gentoo builds is concurrency. Many packages include extensive build steps that are either fully serial, or cannot fully utilize the available CPU threads throughout. This problem becomes less pronounced when running building multiple packages in parallel, but then we are risking overscheduling for packages that do take advantage of parallel builds.

Fortunately, there are a few tools at our disposal that can improve the situation. Most recently, they were joined by two experimental system-wide jobservers: #guildmaster and #steve. In this post, I’d like to provide the background on them, and discuss the problems they are facing.
"""

https://blogs.gentoo.org/mgorny/2025/11/30/one-jobserver-to-rule-them-all/

If you think #Gentoo was boring recently, I've been doing some stuff to make it more interesting. No need to thank me.

#FlexiBLAS: now default in order to break more ~arch systems
#FreePG: available as an alternative on ~arch, but dependencies need to be updated still to allow it more
#ZlibNG: started experimenting with it locally, flag still masked

I have the—perhaps incorrect—impression that the Gentoo project depends on a lot of custom (an sometimes legacy) software, and is suffering from decisions made decades ago...
Well, that and the fact that some components of it are incredibly complex (sob Portage <3 sob).

But maybe I'm missing the point here... -c-