Tootfinder

Can't find a vagrant image fedora/42-cloud-base
41 is present anyone knows why 42 is absent?
#fedora #vagrant

Hmm my #Fedora 42 is unhappy with yesterdays 6.15.9-201 - falling back to 8-200 is fine.
Got as far as 'basic target' but no further; it's not hung (caps lock and ctrl-alt-del work). Time to break out some systemd options to get some more debug. Nothing hit the logs on disk.

Added a graphic showing the dependency tree of the #Linux @kernel-vanilla #Fedora coprs to https://fedoraproject.org/wi…

You can already find the #fedora foot gun ricochet, all before any gun was fired.
#bazitte #gamingonlinux

Wondering why the aarch64 and ppc64le numbers for my #Linux #kernel vanilla mainline copr (left in the screenshot) for #Fedora are higher than for the mainline-wo-mergew copr; they should be lower,…

Another change proposal was submitted to the Fedora Engineering Steering Committee (FESCo) for approval[1]:
Replace the #Xorg #Xserver with the X11Libre Xserver for #Fedora 43-

A while ago, I've followed the example given by #Fedora and unbundled ensurepip wheels from #Python in #Gentoo (just checked — "a while ago" was 3 years ago). This had the important advantage that it enabled us to update these wheels along with the actual pip and setuptools packages, meaning new virtual environments would get fresh versions rather than whatever CPython happened to bundle at the time of release.
I had considered using our system packages to prepare these wheels, but since we were already unbundling dependencies back then, that couldn't work. So I just went with fetching upstream wheels from PyPI. Why not build them from source instead? Well, besides feeling unnecessary (it's not like the PyPI wheels are actually binary packages), we probably didn't have the right kind of eclass support for that at the time.
Inspired by @…, today I've tried preparing new revisions of ensurepip packages that actually do build everything from source. So what changed, and why should building from source matter now? Firstly, as part of the wheel reuse patches, we do have a reasonably clean architecture to grab the wheels created as part of the PEP517 build. Secondly, since we're unbundling dependencies from pip and setuptools, we're effectively testing different packages than these installed as ensurepip wheels — and so it would be meaningful to test both variants. Thirdly, building from source is going to make patching easier, and at the very least enable user patching.
While at it, I've refreshed the test suite runs in all three regular packages (pip, setuptools and wheel — we need an "ensurepip" wheel for the last because of test suites). And of course, I hit some test failures in testing the versions with bundled dependencies, and I've discovered a random bug in #PyPy.
https://github.com/gentoo/gentoo/pull/42882 (yes, we haven't moved yet)
https://github.com/pypy/pypy/issues/5306

The proposal to "Drop 32-bit multilib support on x86_64 #Fedora Linux and stop building packages for i686"[1] has been withdrawn:
https://

Kevin Kofler withdrew his #Fedora 43 change proposal[1] which proposed switching from the #Xorg Xserver to #X11libre:

A change that proposes to drop i686 packages from x86_64 #Fedora 44 was just published:
https://lists.fedoraproject.org/archiv…

Nested virt is always fun; #fedora42 /virt-manager/#qemu/kvm running #AlmaLinux 10/cockpit-virt/qemu/kvm running #debian 12 plain qemu/kvm running