Tootfinder

Opt-in global Mastodon full text search. Join the index!

@knurd42@social.linux.pizza
2025-06-28 16:16:33

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

@lil5@social.linux.pizza
2025-06-28 08:31:08

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

you can do this with any pc

Not with SteamOS you can't

What's the advantage of steamos over bazzite?

SteamOS will support 32bit games in the future.
(Fedora are ditching 32bit)
@knurd42@social.linux.pizza
2025-06-24 10:49:38

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-

@penguin42@mastodon.org.uk
2025-08-23 14:28:33

PSA/TIL #fedora dracut does an fsfreeze on /boot - so do not do something like:
cd /boot
dracut --debug ... > dracut.debug 2>&1
because then the system starts locking up on any access to /boot with unkillable processes.
Discovered the hard way.

@knurd42@social.linux.pizza
2025-06-25 19:23:13

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

@usul@piaille.fr
2025-06-09 12:01:35

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

@freeminded@tooting.ch
2025-07-01 12:13:31

Does anyone know what happend to #fedora #Anitya

@penguin42@mastodon.org.uk
2025-08-23 20:40:54

I've just fought #fedora 42's into submission on my desktop. I added a 'omit_dracutmodules' to a /etc/dracut.conf.d/99davefix-2025.conf with a whole bunch of unused things and it's booting happily now.
It looks like the problem is that, somewhere about a month ago, as a 42 update, Dracut got bumped, and a lot more devices were added as default in the 'host_only (n…

@knurd42@social.linux.pizza
2025-06-24 10:20:18

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

@penguin42@mastodon.org.uk
2025-08-07 12:16:42

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.

@mgorny@social.treehouse.systems
2025-07-05 15:24:22

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.
github.com/gentoo/gentoo/pull/ (yes, we haven't moved yet)
github.com/pypy/pypy/issues/53

@knurd42@social.linux.pizza
2025-08-06 10:53:15

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

A graphic showing what the footnote of https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories#Choose_the_kernel_vanilla_copr_matching_your_needs explains
@knurd42@social.linux.pizza
2025-07-07 06:45:49

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,…

@mgorny@social.treehouse.systems
2025-08-18 04:11:41

Once again, a #CMake project is breaking compatibility with systems that aren't building its dependencies via CMake (but are using Meson instead). Because why use pkg-config when you can use generated CMake configs instead?
#VcPkg. Surely accidental, but why not bash #Microsoft for breaking Linux packages anyway?
#Fedora #Gentoo #packaging