Oh, right, in case I thought I'm going to have time to do useful things, I just realized I still need to deal with the humongous #Gentoo fallout from #Hypothesis #Python package requiring #RustLang now.

FYI, you don't want to get banned on #Gentoo org on #Microsoft #GitHub org right now, because vibe-hub is broken and I can only ban people but "something goes wrong" when I'm trying to see who's banned (and therefore I can't unban anyone).

And this "entitled prospective user" attitude. "I was planning on moving my projects to #Codeberg, but now I won't". Oh, how sad that you won't give them the benefit of using their free services (okay, I'm sure you were going to donate).

Reminds me of the "entitled prospective contributor" attitude in #Gentoo. "You never heard from me before, but I don't like this new policy. There are dozens of new contributors with me, just around the corner, and now we won't be able to contribute." (This was about the copyright policy, so they could have contributed noncontroversially for a long time, yet they never did.)

#NoAI #NoLLM

I've taken #Gentoo Bugzilla down, because it was unusable anyway. No point in feeding the #LLM scrapers that are using thousands of different IPv4 addresses, with no obvious patterns I can see.

#AI #NoAI #NoLLM

Zero days since the #Linux #kernel made a security release of all branches, containing exactly one patch, except for 6.12 which was skipped for no clear reason, and there doesn't seem to be anything about that on the ml. And now I'm scratching my head if I should do a backport for #Gentoo, or wait for the release, or perhaps there was a good reason why the patch was added to every other LTS branch but not 6.12…

I feel that #Gentoo #GURU is getting much less interest since the change of rules.

Not sure if that's a bad thing, given how much of the interest we're getting are people who just made a slopware and now are aggressively pushing it to all the distributions they can find. Some just do an automated submission without bothering to follow the rules. Other claim that they have read and agree to the rules, even though the rules explicitly forbid doing that.

Then, there are all these people who asked for access but apparently never committed anything.

#slop

Me after laboriously backporting #Python 3.15 fixes to #Django 6.0.x in #Gentoo: "oh, nice, the patchset applies cleanly to 5.2.x as well."

And today, I have to laboriously backport another patch to 6.0.x, and it turns out the backport doesn't apply cleanly to 5.2.x, so I have to laboriously backport it there as well.

I honestly *hate* Django Python version support policy. Shifting all the burden downstream.

PSA: I've just removed 344 #Gentoo #GURU committers who haven't connected to the git server in the last 6 months. This is specifically related to the change of rules. We have 205 regular committers now, plus 6 trusted contributors.

Okay, it's still rough around the edges, needs documentation, tests and other stuff I'll slowly be adding but here it is: gagit, or #Gentoo #AGit workflow tool.

https://gitweb.gentoo.org/proj/gagit.git/

#NamingIsMyPassion

I'm thinking of creating a small (they always start small) tool to help submitting pull requests via #AGit to the #Codeberg mirrors of #Gentoo repositories.

Guess how I'm going to call it.

(I'm sorry for spoiling it on IRC already.)

#NamingIsMyPassion

Once again I regret starting, but I'm done: stripped down the #Gentoo "py" package to the bare essentials that are required for pytest-forked (and the stable version of cffi).

Does anyone happen to know if there's a properly maintained alternative to pytest-forked, so we could get rid of py entirely?

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6ea613a5e9380b46b20517f03b1ef2c813ee2f78

Did I ever announce gentoo-kernel-modprep? It's the newest variation on #Gentoo Distribution Kernels: the absolute minimum kernel tree necessary for building modules. Ideal for package-building containers where a full kernel is unnecessary, yet you need to be able to build kernel modules.

Zero days since #pip added a random new functionality that depends on pip being entirely standalone and breaks when you unbundle the dependencies. And I'm unable to figure out why a bunch of tests are still failing.

#Gentoo #Python

Zero days since the #Python feedparser library switched to yet another #SGMLlib fork.

Yes, #Gentoo has only packaged the previous SGMLlib fork because of them.

I've added a "contributing" file to #Gemato:

https://github.com/gentoo/gemato/blob/master/CONTRIBUTING.rst

I guess I'm going to use this as a template for other projects of mine, hosted on the #Gentoo infrastructure and mirrored to GitHub or Codeberg.

And this "entitled prospective user" attitude. "I was planning on moving my projects to #Codeberg, but now I won't". Oh, how sad that you won't give them the benefit of using their free services (okay, I'm sure you were going to donate).

Reminds me of the "entitled prospective contributor" attitude in #Gentoo. "You never heard from me before, but I don't like this new policy. There are dozens of new contributors with me, just around the corner, and now we won't be able to contribute."

#NoAI #NoLLM

Now I really want to create a #Gentoo project called "The Butlerian Inquisition".

#NoAI #NoLLM

Zero days since #CPython broke the extension ABI at the very last minute after asking everyone repeatedly to test prereleases. And of course they don't bother tracking ABI changes in any way, so they could at least give people heads up that important pieces of their system will start segfaulting after the upgrade. All they can offer is a knee-jerk response of "we never promised ABI stability".

And yes, this is a huge PITA for #Gentoo users who opted in to helping out.

https://github.com/python/cpython/pull/152448#issuecomment-5016129511

#PSA to #Gentoo users: Please don't upgrade to #CPython 3.14.0b4, that release is borked and causes segfaults in random packages. I've just pushed a mask but warning in case you hit the upgrade before it reaches you. We'll investigate when we have more time.

#Python

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.

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

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?

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