PSA: after another major policy violation by user who clearly never cared about #Gentoo and joined only to ignore the rules, I've suspended processing access requests to GURU. We're already working on a new policy, and we'll go from there.

@fosdembsd Reminds me of my #Gentoo days ;)

Zero days since 83 #Gentoo developers effectively lost push access over revoked PGP key signatures because of random #LDAP hiccup.

Yes, we have error handling. And yes, we have a safety check in case error handling didn't work and LDAP returned empty list of developers. Yet apparently that's not enough either, so now we also check if the diff between old and new lists isn't too large; you know, in case ldapsearch randomly returned a subset of developers and considered it a success.

Ja rozumiem, że byłem chwilę w lesie, ale co tu się w międzyczasie wydarzyło?

Python3_12 Strikes Back? :D

CC: @mgorny

#gentoo

Alt...

Terminal, aktualizacja systemu zatrzymuje się na prośbie ustawienia zależności od starej wersji pythona.

And the next big blocker for #Python 3.15 in #Gentoo is time-machine. Which is obviously broken. There's a patch but it's complex and it's sitting for 3 months already with no reply. Because obviously patching CPython internals is so much a better idea than freezegun ever were. All these time-based tests need all the ricing you can get; portability doesn't matter.

https://github.com/adamchainz/time-machine/pull/618

#Python Hypothesis package now requires #RustLang. This is a scale of reverse dependencies I can't handle. I guess this means it's the end of WD40 profiles on #Gentoo, and therefore the end of support for Alpha, ARM<v6, HPPA, M68k, i486 and some other random subsets of architectures and profiles. Thanks for all the fish, etc.

https://github.com/HypothesisWorks/hypothesis/issues/4740

The conclusion from a big #Python 3.15 #Gentoo porting run today: the most common kind of #NIH Python package is one providing colorful output on the terminal…

I have a #Python favor to ask. Could someone look at Python 3.15 test failures in itsdangerous? It's blocking quite a large part of package dependency graph in #Gentoo, and the failure looks, errr, dangerous.

https://github.com/pallets/itsdangerous/issues/420

I've proposed that we reconsider the fully "open" access to #Gentoo GURU project, and instead requiring people to get at least one PR/patch merged before requesting push access.

https://archives.gentoo.org/gentoo-dev/e3ac4768e2ada7e58855eeb841fb0e25c1d45094.camel@gentoo.org/T/

Binary distributions give you eggs. You never value the goose. #Gentoo is all about the goose.

New on #blog: pkgbump: from a dumb tool to an irreplaceable helper

https://blogs.gentoo.org/mgorny/2026/06/21/pkgbump-from-a-dumb-tool-to-an-irreplaceable-helper/

"""
Bumping packages is one of the most common tasks of a #Gentoo developer. It shouldn’t then be surprising that it is the one most asking for some kind of automation, and that the #pkgbump script would be one of the first scripts to become a part of the mgorny-dev-scripts package.

Today’s pkgbump have come a long way from the trivial script of its first iteration. The most recent versions finally feature the feature I desired for a long time: version manipulation. This also made it possible for the script to become a complete version bumping tool rather than just a part of a larger workflow. In this post, I’d like to shortly tell the story behind the changes, and demonstrate the new options.
"""

#packaging

#TIL that instead of grepping through `git log -p` to figure out when the last dependency on a package was removed, I can just search through gentoo-commits ml archives.

#Gentoo

Given these days you can't even expect #Gentoo contributors to be respectable, I'm working on adding a git hook that rejects commits with #LLM attribution. Could you help me find all the common patterns used to mark LLM-assisted #git commits?

So far I'm checking for author and Co-authored-by using the following e-mail patterns:

• copilot@github.com
• *@anthropic.com
• claude@users.noreply.github.com
• *+claude[bot]@users.noreply.github.com
• *@openai.com
• *+chatgpt-codex-connector[bot]@users.noreply.github.com
• *@cursor.com
• *@x.ai
• *@google.com

I think some people came up with some other tags to mark LLM commits but can't find that right now.

#NoAI #NoLLM #AI

#Gentoo PSA: due to my oversight, upgrading sys-kernel/gentoo-kernel-bin to the latest versions on every branch does not result in /usr/src/linux symlink being updated. I will try to fix it in 10 hours.

A workaround is to update the symlink manually or remove it and run `emerge --config gentoo-kernel-bin`. You may need to run `@module-rebuild` afterwards.

This is a one time problem. Once the symlink is updated (or becomes invalid, e.g. through --depclean), subsequent upgrades will update it correctly.

I'm sorry for the trouble.

https://bugs.gentoo.org/977372

If you ever notice me committing ebuilds without a trailing slash in GitHub homepage, please raise an alarm; that will be an impostor!

#Gentoo

RE: https://infosec.exchange/@david_chisnall/116696597934617319

I should've tried this before I switched to Linux (chose Ubuntu at the time) but I couldn't wait. Just decided it was time to move right away around the tail end of November 2021.

There was a learning curve yeah, but it was alright. I spent most of Christmas vacation days learning.

5 months later I moved to Arch and I still rock the same install for 4 years now. I thought of moving to gentoo but it's a waste of electricity compiling.

#ubuntu #linux #archlinux #gentoo

Pink boosted

David Chisnall (*Now with 50% more sarcasm!*) » 🌐 2026-06-05
@david_chisnall@infosec.exchange

Almost 25 years ago, I wrote a blog post with the title ‘jumping ship slowly’ about leaving Windows (XP was awful, it was mind boggling to me that Vista managed to make people nostalgic for XP). My advice remains the same:

Don’t try switching OS first. The OS is the most easily replaceable bit in the stack. Switch applications first. Most ‘Linux’ apps are cross platform. They’ll run on Windows, and the few that don’t will run in WSL2. You can switch out apps one at a time, and take the time to get comfortable with the alternatives.

Once you’re comfortable not using any Windows-only apps, changing the OS but using all of the same applications is very easy to do. Changing OS and application stack at the same time is an enormous obstacle.

I believe this is also why a lot of corporate and government Linux migrations fail: they try to change everything at the same time and that’s too steep a learning curve.

Seriously, when I created the GURU project for #Gentoo, I wanted it to be the place where Gentoo users work together on #packaging. What I definitely didn't want it to be: a drive-by stop for vibe-coders to promote their crap.

https://github.com/gentoo/guru/pull/485

#AI #LLM #NoAI #NoLLM

I've just released mgorny-dev-scripts 77, with a major revamp of pkgbump, integrating the trick from bump-boto and extending it.

Now you can pass a version increment as the second argument:

pkgbump foo-1.2.3.ebuild +1 (gives 1.2.4)

You can also increment a higher version by specifying the, then subsequent components:

pkgbump foo-1.2.3.ebuild +1.0 (gives 1.3.0)

(Yeah, sorry, that doesn't catch all possible variations but it's a side feature anyway.)

You can also pass a wildcard as the source, so that the newest (non-live) version is picked:

pkgbump 'django-5.2*.ebuild' +1

Or you can skip arguments and just do:

pkgbump +2 # the newest version +2
pkgbump # the newest version +1

Now I just need to use that to make bumping kernels much more pleasant.

#Gentoo

If #Gentoo was an acronym, what would it stand for?

#Gentoo
guess who just deselected all packages from world LOL cancelled depclean just in time

Well, we've finally packaged #Valkey (another #Redis fork) in #Gentoo, along with its #Python bindings.

Not that we wanted to, but #FakeRedis now started requiring it for tests so heavily that it was too much effort to patch it out. Just to be clear, it just requires the Python bindings, because its test suite happily runs against either Redis or Valkey, and literally doesn't support testing against both simultaneously. But to add the bindings, we needed the database to test them against. And since I've added the package too, I've put a lot of effort (and swearing) to test FakeRedis against both servers.

Should you be using Valkey? Well, let's put it like this. You shouldn't be using Redis, because it's enterprise quality shit. Valkey is roughly what happens when you fork enterprise quality shit and have no clue what you're doing. Though you are able to mostly get renaming right (one valkey-py test failed over the server calling itself "Valkey" rather than "Redis").

Disclaimer: I've only looked at the Python bindings. Maybe the maintainers are more knowledgeable with the server itself.

The #Gentoo #Python 3.14 switch / 3.11+3.13t removal PR is green. Doing some final testing locally before merging it (one that involves 350 "merge wait" packages, what could possibly go wrong…).

https://codeberg.org/gentoo/gentoo/pulls/1031

Lately I've been thinking about how #Gentoo is perceived by people. So often they're stuck in the "ricer" mindset: Gentoo is being built from source, so it must be ZOMG fast. And if it isn't, then what's the point?

If I were to make four points for Gentoo (to stop myself from making more), they would be:

1. Gentoo is independent.

There is no company behind Gentoo. There is no business plan. It's made and maintained by volunteers. Driven by passion and not profit incentive. And we want to keep it that way.

2. Gentoo aims to be secure.

We are maintaining our own infrastructure to reduce the risk of being hijacked. We're securing our distribution channels and mirrors using OpenPGP. We're only using Codeberg (which we really appreciate) and GitHub as mirrors (with OpenPGP commit signatures) and contribution channels. We have a dedicated security team, who works with the developers to keep packages free of vulnerabilities and our users informed.

3. Gentoo is made by humans.

We banned LLM contributions two years ago, and never regretted it. We didn't "wait and see", we took decisive action, and if we got left behind, it's only for the better. Unfortunately, in today's LLM-ridden world we can't stop slop software from being packaged in Gentoo without sacrificing our commitment to keep packages up to date, but we try to keep the worst offenders (like copywashed chardet) at bay.

4. Gentoo supports sustainability.

This may sound ironic when so many of us build everything from source, but we're actually trying to make computing sustainable. Gentoo's source-first nature makes it inherently flexible. We try our best to support a plethora of older and less common hardware. We go against the flow and still try to provide a workable system on hardware that is not supported by Rust or V8. And on top of that, we do our best to provide binary packages for a variety of configurations.

Of course, that's not all. I want Gentoo to be reliable and stable, to be oriented towards privacy by default, to be welcome and respectful.

And all these things ultimately depend on people working on Gentoo, and contributing to Gentoo. We always need more people that share these principles and want to help us achieve them.

What do you appreciate in Gentoo?

Lately I've been thinking about how #Gentoo is perceived by people. So often they're stuck in the "ricer" mindset: Gentoo is being built from source, so it must be ZOMG fast. And if it isn't, then what's the point?

If I were to make four points for Gentoo (to stop myself from making more), they would be:

1. Gentoo is independent.

There is no company behind Gentoo. There is no business plan. It's made and maintained by volunteers. Driven by passion and not profit incentive. And we want to keep it that way.

2. Gentoo aims to be secure.

We are maintaining our own infrastructure to reduce the risk of being hijacked. We're securing our distribution channels and mirrors using OpenPGP. We're only using Codeberg (which we really appreciate) and GitHub as mirrors (with OpenPGP commit signatures) and contribution channels. We have a dedicated security team, who works with the developers to keep packages free of vulnerabilities and our users informed.

3. Gentoo is made by humans.

We banned LLM contributions two years ago, and never regretted it. We didn't "wait and see", we took decisive action, and if we got left behind, it's only for the better. Unfortunately, in today's LLM-ridden world we can't stop slop software from being packaged in Gentoo without sacrificing our commitment to keep packages up to date, but we try to keep the worst offenders (like copywashed chardet) at bay.

4. Gentoo supports sustainability.

This may sound ironic when so many of us build everything from source, but we're actually trying to make computing sustainable. Gentoo's source-first nature makes it inherently flexible. We try our best to support a plethora of older and less common hardware. We go against the flow and still try to provide a workable system on hardware that is not supported by Rust or V8. And on top of that, we do our best to provide binary packages for a variety of configurations.

Of course, that's not all. I want Gentoo to be reliable and stable, to be oriented towards privacy by default, to be welcome and respectful.

And all these things ultimately depend on people working on Gentoo, and contributing to Gentoo. We always need more people that share these principles and want to help us achieve them.

What do you appreciate in Gentoo?

New on #blog (this time with quotes from Fedi): "Why Gentoo?"

https://blogs.gentoo.org/mgorny/2026/05/28/why-gentoo/

"""
Multiple times in the past I’ve been thinking of how #Gentoo is perceived by the wider public, the non-users. What probably stands out most is compiling. Almost everyone who heard of Gentoo knows it has something to do with compiling everything. And why are we doing that? Well, besides being hardcore, the common sentiment goes for performance. So yeah, Gentoo users must be some kind of hardcore ricers who try to squeeze every last bit of their system performance.

To be honest, I don’t think that’s a good way to describe Gentoo. Yes, compiling is at the core of it. But performance? I don’t think so, at least not in the obvious, -O9999 -fzomg-fast way. The world has moved on, CPUs have gotten faster, optimizations have gotten smarter, and distributions have started optimizing more aggressively. Optimization-wise, I suspect your average Ubuntu package with generic optimizations may be no slower than the equivalent Gentoo package fine-tuned for your CPU. And if it’s not, then it probably won’t make a real difference anyway.

There’s much more to Gentoo than that. Yes, some of it comes from building from source: the flexibility. But a lot of it comes from the wider Gentoo philosophy, the philosophy that brought us all together. The idea that Gentoo is the distribution we’re making for ourselves and people who enjoy Gentoo. So if I were to make a few arguments for Gentoo, I’d focus on that. And this is what I’d like to do here.
"""

New on #blog (this time with quotes from Fedi): "Why Gentoo?"

https://blogs.gentoo.org/mgorny/2026/05/28/why-gentoo/

"""
Multiple times in the past I’ve been thinking of how #Gentoo is perceived by the wider public, the non-users. What probably stands out most is compiling. Almost everyone who heard of Gentoo knows it has something to do with compiling everything. And why are we doing that? Well, besides being hardcore, the common sentiment goes for performance. So yeah, Gentoo users must be some kind of hardcore ricers who try to squeeze every last bit of their system performance.

To be honest, I don’t think that’s a good way to describe Gentoo. Yes, compiling is at the core of it. But performance? I don’t think so, at least not in the obvious, -O9999 -fzomg-fast way. The world has moved on, CPUs have gotten faster, optimizations have gotten smarter, and distributions have started optimizing more aggressively. Optimization-wise, I suspect your average Ubuntu package with generic optimizations may be no slower than the equivalent Gentoo package fine-tuned for your CPU. And if it’s not, then it probably won’t make a real difference anyway.

There’s much more to Gentoo than that. Yes, some of it comes from building from source: the flexibility. But a lot of it comes from the wider Gentoo philosophy, the philosophy that brought us all together. The idea that Gentoo is the distribution we’re making for ourselves and people who enjoy Gentoo. So if I were to make a few arguments for Gentoo, I’d focus on that. And this is what I’d like to do here.
"""

Anything great morning.

So now #Typer, the NIH #Python CLI library, decided to start bundling #Click. Why? Of course there's a lot of marketing talk behind it. Which ofc means they just don't want to be bothered about following the API, and take the easy way out.

https://github.com/fastapi/typer/releases/tag/0.26.0

#Gentoo

I've been sad about the upcoming removal of #PyPy from #Gentoo, but given how many regressions I've been seeing recently in a variety of #Python packages, I'm eagerly waiting for the day when I'll remove the support and be able to stop having to deal with the test failures somehow. Not that at this point any other way of dealing besides skipping them makes any sense.

FYI, looks like #Migadu doesn't accept e-mail from gentoo.org (their server disconnects us after EHLO). One of their users contacted them, and they've basically replied with blanket response without doing anything to resolve the problem.

#Gentoo

I've just learned that #ReiserFS was mur… I mean, removed from the newest kernels.

In other news, one of anongit machines in #Gentoo Infra rotation is now suffering lack of data.

If #Python package releases continue at this rate, I'm going to start getting up earlier.

Or just stop doing all of them in the morning.

#Gentoo

The ebuild: I need a openapi-schema-validator newer than 0.8 and older than 0.9.

#Gentoo #Portage: okay, how about we try to simultaneously install 0.7.2 and 0.9.0?

We've also posted about our #CopyFail, #DirtyFrag, #Fragnesia handling on the #Gentoo website:

https://www.gentoo.org/news/2026/05/19/copy-fail-fragnesia-vulnerabilities.html

…and yes, another secfix round coming.

CC @wariat

I've finally finished pushing the latest update for #Gentoo Distribution Kernels, and requested their stabilization. This includes upstream releases 7.0.9, 6.18.32, 6.12.90 and 6.6.140; and Gentoo patch bumps 6.1.173_p1, 5.15.207_p1 and 5.10.256_p1.

All of these contain the v5 #Fragnesia patch. And yes, while the exploit is in the wild, upstream still hasn't merged a fix to the mainline kernel, let alone all the LTS branches.

They also include a few reverts in 6.18 and 6.6 for broken PowerPC backports that upstream didn't apparently test. 🤷

We're doing our best, but I'd still recommend running the latest 7.0.x kernel, or LTS 6.18.x, because upstream is far from reliable with the backports.

#Linux

If it wasn't enough that we have to keep building new kernels every day and backport vulnerability fixes to older LTS branches, now we also have to deal with upstream doing random backports that are completely broken and never bothering actually even checking if they build.

#Gentoo #Linux

I've done the right thing and it's going to cause pain.

#Gentoo Distribution Kernel configs are now hosted entirely on git.gentoo.org rather than GItHub. If you don't use Gentoo mirrors, you may be hitting 502s thanks to our LLM overlords now. If you use Gentoo mirrors, you may be hitting 404s if they hit 502s while trying to fetch from our Infra 🤷.

Guess what I'm doing right now.

Yes, it's now my shift to bump dist-kernels in #Gentoo.

Good news is that 6.12+ with Gentoo patches are good, and I've managed to stabilize them even. Only 6.6 and older are getting an extra upstream patches.

These days new vulnerabilities are found faster in kernels than I can manage to build patched kernels for #Gentoo.

https://lore.kernel.org/netdev/20260513041635.1289541-1-vakzz@zellic.io/
https://lore.kernel.org/netdev/agRfuVOeMI5pbHhY@v4bel/

Kudos to @thesamesam for staying on top of things.

One of my strong suites in all the packaging work is the knowledge in my head.

"Why don't you write it down for others to benefit from, then?", you'd ask.

The thing is, this knowledge is basically "hot cache". I'm bumping hundreds of #Python packages in #Gentoo, so I remember stuff. And because of that, I can quickly notice some things or answer some questions.

If that were written down, the effort needed to find it would diminish all the gain. I mean, technically *it is* already written down, and the whole point is that I have it "cached".

Did I just switch from hardcoding the #Gentoo patchset version in Distribution Kernel ebuilds (because we needed to rebase/update them so rarely) to using `${PV}`? Perhaps.

Remember how #Opera browser used not to be one huge scam?

Now they're mailing #Gentoo over dead Opera-related links on the Wiki, with random #SEO crap.