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

Let's get this straight: it is entirely normal for a #OpenSource project to accumulate bug reports over time. They're not a thing to be ashamed of.

On the contrary, if you see a nontrivial project with a very small number of bug reports, it usually means one of the following:

a. you've hit a malicious fake,
b. the project is very young and it doesn't have many users (so it's likely buggy),
c. the project is actively shoving issues under the carpet.

None of that is a good sign. You don't want to use that (except for b., if you're ready to be the beta tester).

#FreeSoftware #Gentoo #Python

How to absolutely *not* do #OpenSource: require people to commit to work on other issues with your project in order to file bugs. So, sorry, #Typer, I won't be filing bugs. You figure out how you messed up your release yourself.

https://github.com/fastapi/typer/discussions/new?category=questions

#FastAPI #Python #FreeSoftware #Gentoo

#SigStore / #PyPI attestations: #PGP is hard! We must invent a new signing scheme that's so much easier on users.

The tools, after I've spent hours *integrating* them into #Gentoo, and getting them working for everything before:
* Verifying google_auth-2.46.0.tar.gz ...
Provenance signed by a Google Cloud account, but no service account provided; use '--gcp-service-account'

Yeah, I'm sure that's *so much simpler* than PGP.

#security

Yeah, why not neglect all the good recommendations in the #Python ecosystem, and instead fork your own C extension package, force people to build it with #ZigLang (it's still C), add unconditional dependency on that, and on top of that, refuse to publish wheels, "allowing for optimised compilation according to your machine's specific architecture and capabilities, instead of some (low performance) common denominator."

Fortunately, looks like #Gentoo can just ignore all the fancy crap and compile it with GCC.

https://pypi.org/project/ruamel.yaml.clibz/

@itsfoss
Migrating from #Debian to #Gentoo.

#Linux #LinuxWomen

Going to #39c3 this weekend, am excited!

Will any #gentoo people be there? Would love to meet up.

I'm building webkit-gtk right now. It's one of these messy packages where a few source files need a lot of memory to compile, and ninja can randomly order jobs so that all of them suddenly start compiling simultaneously. So to keep things going smoothly without OOM-ing, I've been dynamically adjusting the available job count via steve the #jobserver.

While doing that, I've noticed that ninja isn't taking new jobs immediately after I increased the job count. So I've started debugging steve, and couldn't find out anything wrong with it. Finally, I've looked into ninja and realized how lazy their code is.

So, there are two main approaches to acquiring job tokens. Either you do blocking reads, and therefore wait for a token to become available, or you use polling to get noticed when it becomes available. Ninja instead does non-blocking reads, and if there are no more tokens available… it waits till one of its own jobs finish.

This roughly means that as other processes release tokens, ninja won't take them until one of its own jobs finish. And if ninja didn't manage to acquire any job tokens to begin with, it is just running a single process via implicit slot, and that process finishing provides it with the only chance to acquire additional tokens. So realistically speaking, as long as there are other build jobs running in parallel, ninja is going to need to be incredibly lucky to ever get a job token, since all other processes will grab the available tokens immediately.

This isn't something that steve can fix.

#Gentoo #NinjaBuild

Started for the adventure, stayed for the stability. 🐧

#linux #gentoo #debian

Alt...

Me adventuring with Gentoo in 2015: A picture of a man who has hope in his eyes and color in his life. Me using Debian to save time in 2025: A picture of a man who is dead inside looking for the smallest bit of hope. There is no color in his black-and-white life.

Why not switch your crappy software from crappy #SCons build system to even more crappy #Bazel build system over a patch release, call it "fully backwards compatible", and then effectively leave all the distros stuck on old versions with half a dozen vulnerabilities?

Yeah, just a random reminder that #MongoDB is total crap, and you shouldn't use it. Or expect people to package it for you.

https://jira.mongodb.org/browse/SERVER-103927

#Gentoo

#Sphinx joined the list of packages dropping #Python 3.11 (and therefore #PyPy) support. Of course, we could just go through the effort of dropping it from respective packages in #Gentoo, given it's not technically that common… but honestly, at this point I have zero motivation to put the extra effort for this, just to learn that next month some core package starts requiring Python 3.12.

So, would anyone really mind if I removed Python 3.11 and PyPy support completely from Gentoo packages?

0 days since it turned out that GNU #make does not respect the #jobserver protocol it designed itself in yet another way. Or to put it otherwise, I've wasted my whole morning implemented something that cannot work because it didn't occur to me that GNU make people only set rules without caring to actually follow them.

https://savannah.gnu.org/bugs/index.php?67822

#Gentoo #Linux

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-