Mikeserv Support Forum

At this point which would you say is the more difficult one to deal with, Arch or Manjaro updates?

Well, Manjaro updates are Arch updates, but delayed. Most of Manjaro is just their own PKGBUILDs that follow Arch. So in Manjaro, if I was following their updates, I'd simply have a lot more rubbish to deal with at once, rather than something stupid to piss me off every day.

I just need to have things normal, I don't want my image libraries loading in bubblewrap containers set up by systemd. Gnome and systemd can fuck all the way off. I just want to use the GTK+3 environment.

It's the distro trying to keep the system Gnome compatible that's the problem here.

It looks like Arch fixed this:

https://gitlab.archlinux.org/archlinux/ ... 49e51f103f

GdkPixbuf-WARNING **: 11:51:10.109: Error loading XPM image loader: Image type “legacy-xpm” is not supported

Apparently was removed from gdk-pixbuf, moved to glycin, but glycin implementation is incapable of handling "gdk_pixbuf_new_from_xpm_data" thus returned to pixbuf and disabled by default

These two things, a cherry pick "patch" and enabling legacy_xpm. This was also broken with glycin too, not only for me.

# Unbreak gdk_pixbuf_new_from_xpm_data
# https://gitlab.archlinux.org/archlinux/ ... k_items/13
git cherry-pick -n 62b8f9fd0bb3b862823cd34afce4b389fbd27569

-D legacy_xpm=enabled

That's it for me though, I'll be maintaining gdk-pixbuf2 myself from now on. I'm not having that bollocks.

This sounds like what happened in the CachyOS forums.

What a bunch of fuckweasels. XLibre is an alternative that plenty of people will like to use, once Xorg X11 stops being viable. I have no reason to now, but hope that fork sees some contributions between now and then. I don't think one guy would be able to maintain it for very long, once things get out of whack. I see XLibre shunned by some people (e.g. chimps at Phoronix) because they want everything to be Wayland. There could be some of that going on here, it really doesn't make sense.

Telling subreddit moderators to censor people talking about age verification too. Fuck them... I'm not having that, as a matter of principle.

So, earlier in the week Arch upgraded wayland, but not lib32-wayland. It is not possible to compile lib32-mesa in that situation, because it's the wrong version of wayland-scanner (64 bit, common between). I had to fix it (compile lib32-wayland 1.25... I was just using the distro package for the lib32) but they STILL have not fixed that. See, they wouldn't care because they don't need to compile mesa, yet (they are still on mesa-26.0.5 and they probably won't be doing another until 26.1.1). They don't care about anything but the distro packages they distribute. There's no way I'd leave that broken for 4 days if it were my distro. It especially irks me, because I don't even use Wayland, but it's a system dependency.

I'm on the 26.1 branch, currently mesa 26.1.0-rc2.221275.9445e5d0a6c as of a few minutes ago. It's shaping up to be pretty good.

Arch broke my fucking claws-mail again. This time with nettle 4.0 (.so.9 now). It's yet another crypto library.

libnettle.so.8 => not found

This breaks my gstreamer, xorg, curl and other shit I haven't realized yet. Oh, since typing I've also realized that even my wget is broken lol

I can't get rid of nettle, but maybe I can configure some important things without it. This isn't the first time nettle has broken my shit.

For my mail I might go back to Sylpheed, that could run for literally a decade without getting broken. I usually don't recompile that for the lifetime of the system.

If I said I was getting tired of Arch's silliness I'd be repeating myself incessantly. Oh wait...

P.S. I decided to make nettle-compat and lib32-nettle-compat packages for nettle 3.10.2 (.so.8) to fix all my broken shit until I get it recompiled. Libraries only. You can do that with most library packages, simply by removing the unwanted shit during the packaging step (also change any $pkgname variables to the base package name as -compat would get in the paths). It will work for satisfying library dependencies, anyway, if not for the entire implementation (i.e. I've got the programs in bin from the newer nettle package in this case)

Arrrrgh.... nettle! It stings.

lutris-wrapper: EA App
Started initial process 835 from /usr/bin/wine /storage3/shit/EA_App/drive_c/Program Files/Electronic Arts/EA Desktop/EA Desktop/EADesktop.exe
Start monitoring process.
wineserver: NTSync up and running!
[0513/005205.361:ERROR:network_change_notifier_win.cc(224)] WSALookupServiceBegin failed with: 0
[0513/005205.522:ERROR:network_change_notifier_win.cc(224)] WSALookupServiceBegin failed with: 0
[0513/005209.979:WARNING:spdy_session.cc(3487)] Received HEADERS for invalid stream 179
[0513/005210.378:WARNING:angle_platform_impl.cc(48)] HLSLCompiler.cpp:282 (compileToBinary):
C:\fakepath(136,3-70): warning X3557: loop only executes for 1 iteration(s), forcing loop to unroll

S~QN0\\Core\ActivationUI.exe: ecc-random.c:62: _nettle_ecc_mod_random: Assertion `nbytes <= m->size * sizeof (mp_limb_t)' failed.
wine: Assertion failed at address F7F16A4C (thread 0bec), starting debugger...

My Mass Effect Andromeda game suddenly stopped working (hadn't tested it in the last few days). I tried different Mesas, dxvk's and then I thought hmm... I didn't even try logging. It's fucking nettle related, I probably have to recompile my Wine.

Funny... my Dragon Age Veilguard and Mass Effect Legendary Edition games are fine. They must use a different activation check program.

P.S. No, recompiling my wine didn't help. I think wine dlopens that. It's barfing on the new nettle, that's what's happening. (I took off my nettle-compat packages)

Ahh... that's not actually MY nettle, it's the function in the ActivationUI.exe program that's hitting the assertion. Wine doesn't use nettle (gnutls does). Something at the back end has changed (e.g. gnutls or something... also dlopened) and that program doesn't like it.

It'll be the 32 bit gnutls that's the problem, I can't see what else it could be (EA's ActivationUI.exe for the game is a 32 bit program) that has changed on the system, and is the back end for that shit. I was thinking of downgrading that, but remembered that I also have Mass Effect Andromeda on Steam. Since I've been building my proton-tkg's in Valve's container environment, it's linked against the runtimes in the Steam Linux runtime containers, where there are sane versions of the libraries. The game launches there. Not that there was anything wrong with the game, just EA's asshole Activation check.

The problem IS nettle 4.0. This started when Arch upgraded that and then pushed out the rebuilt gnutls packages (lib32 is the problem, for the activation client). I know I tested this game when I upgraded to wine 11.8 and played it since then. While I understand the problem, I'm fucked here, I can't fix this without downgrading the whole crypto stack. gnutls and nettle are circular dependencies, and the lib32 builds need the includes and stuff from the 64 bit packages. So I can't downgrade lib32-nettle or lib32-gnutls (won't compile against nettle includes). If I downgrade nettle and gnutls I'll have to recompile a ton of stuff now, mine and distro.

It's probably security updates breaking lib32, I think.

So, I'm getting tired of Arch breaking my shit. I might have to figure something else out for my gaming setup. The trouble is, I hate everything. I'd have the same problems (and probably more) with CachyOS and Artix would be following Arch package versions too for the most part. Gentoo is too rigid (miserable for me). I hate rpm and deb distros too much for any of those. So that leaves me fighting with Arch.

So that leaves me running Mass Effect Andromeda (I've been playing that again lately, enjoying this playthrough) on Steam in its runtime container and hoping that none of my other EA games break on activation check. I know I have one other that will (similar activation check from the same era), Star Wars Battle Front 2, but I don't have that installed right now. Only they do cunty things like that, despite having a client login as gatekeeper.

Would Slackware-Current make a good base for gaming? I know it's not like it used to be but at least you'd have more control. I see some people using Tumbleweed for gaming, it does use RPM based package management but it otherwise has no connection to Red Hat. I've used it before, it's rolling like Arch so the packages are pretty recent.