Page 6 of 7
Re: Arch Linux 2024
Posted: Sun Jan 04, 2026 7:33 am
by Grogan
It's probably individual package maintainers making these decisions. The guy that does the grub builds would be considered their "grub expert". There'd be some committee that they'd answer to, but it would be the packagers' justifications that would get the changes accepted or not etc.
But yes, I'll be the judge of grub from now on. Judge, jury and executioner. If need be
Re: Arch Linux 2024
Posted: Sun Jan 11, 2026 3:22 am
by Grogan
Arrrghh.... what a thing to come home to on a Saturday night. I have to compile stuff before I can even say Y here... glibc, gcc and python, moreover I think I even have to do a temporary python 3.14 build first because if I have 3.13 then the python modules for gcc and stuff are going to be broken after I upgrade python. I've been dreading python 3.14 because that means everything that has anything to do with python is going to need rebuilding. (and I have to remember what I have in /usr/local and other places)
Code: Select all
[nicetry ~]# pacman -Syu
:: Synchronizing package databases...
core is up to date
extra is up to date
multilib is up to date
:: Starting full system upgrade...
warning: binutils: ignoring package upgrade (2.45.1-1 => 2.45.1+r35+g12d0a1dbc1b9-1)
warning: gcc: ignoring package upgrade (15.2.1+r301+gf24307422d1d-1 => 15.2.1+r447+g6a64f6c3ebb8-1)
warning: gcc-libs: ignoring package upgrade (15.2.1+r301+gf24307422d1d-1 => 15.2.1+r447+g6a64f6c3ebb8-1)
warning: gcc-rust: ignoring package upgrade (15.2.1+r301+gf24307422d1d-1 => 15.2.1+r447+g6a64f6c3ebb8-1)
warning: glib2: ignoring package upgrade (2.86.3-1 => 2.86.3-2)
warning: glib2-devel: ignoring package upgrade (2.86.3-1 => 2.86.3-2)
warning: glib2-docs: ignoring package upgrade (2.86.3-1 => 2.86.3-2)
warning: glibc: ignoring package upgrade (2.42+r33+gde1fe81f4714-1 => 2.42+r47+ga1d3294a5bed-1)
warning: lib32-gcc-libs: ignoring package upgrade (15.2.1+r301+gf24307422d1d-1 => 15.2.1+r447+g6a64f6c3ebb8-1)
warning: lib32-glibc: ignoring package upgrade (2.42+r33+gde1fe81f4714-1 => 2.42+r47+ga1d3294a5bed-1)
warning: libgccjit: ignoring package upgrade (15.2.1+r301+gf24307422d1d-1 => 15.2.1+r447+g6a64f6c3ebb8-1)
warning: lto-dump: ignoring package upgrade (15.2.1+r301+gf24307422d1d-1 => 15.2.1+r447+g6a64f6c3ebb8-1)
warning: meld: ignoring package upgrade (3.22.3-1 => 3.22.3-2)
warning: ninja: ignoring package upgrade (1.13.2-1 => 1.13.2-2)
warning: openresolv: ignoring package upgrade (3.16.5-1 => 3.17.4-1)
warning: python: ignoring package upgrade (3.13.11-1 => 3.14.2-2)
warning: xkeyboard-config: ignoring package upgrade (2.39-1 => 2.46-1)
resolving dependencies...
looking for conflicting packages...
Package (164) Old Version New Version Net Change Download Size
extra/at-spi2-core 2.58.2-1 2.58.3-1 0.00 MiB 0.56 MiB
core/audit 4.1.2-1 4.1.2-2 0.00 MiB 0.38 MiB
extra/avahi 1:0.9rc2-1 1:0.9rc2-3 0.00 MiB 0.43 MiB
core/brotli 1.1.0-3 1.2.0-1 0.03 MiB 0.39 MiB
extra/capstone 5.0.6-1 5.0.6-2 0.03 MiB 0.94 MiB
extra/dtc 1.7.2-4 1.7.2-5 0.00 MiB 0.15 MiB
extra/fontforge 20251009-4 20251009-5 0.00 MiB 10.22 MiB
extra/gi-docgen 2025.5-1 2025.5-2 0.09 MiB 1.21 MiB
extra/gobject-introspection 1.86.0-1 1.86.0-2 0.03 MiB 0.51 MiB
extra/gobject-introspection-runtime 1.86.0-1 1.86.0-2 0.00 MiB 0.03 MiB
extra/grpc 1.76.0-3 1.76.0-4 0.00 MiB 5.57 MiB
extra/gst-libav 1.26.10-1 1.26.10-2 0.00 MiB 0.10 MiB
extra/gst-plugins-bad 1.26.10-1 1.26.10-2 0.00 MiB 1.12 MiB
extra/gst-plugins-bad-libs 1.26.10-1 1.26.10-2 0.00 MiB 2.86 MiB
extra/gst-plugins-base 1.26.10-1 1.26.10-2 0.00 MiB 0.21 MiB
extra/gst-plugins-base-libs 1.26.10-1 1.26.10-2 0.00 MiB 2.35 MiB
extra/gst-plugins-good 1.26.10-1 1.26.10-2 0.00 MiB 2.21 MiB
extra/gst-plugins-ugly 1.26.10-1 1.26.10-2 0.00 MiB 0.17 MiB
extra/gstreamer 1.26.10-1 1.26.10-2 0.00 MiB 2.02 MiB
core/icu 78.1-1 78.2-1 0.00 MiB 11.71 MiB
extra/imath 3.2.2-2 3.2.2-3 0.04 MiB 3.92 MiB
extra/iotop 0.6-12 0.6-13 0.00 MiB 0.06 MiB
extra/lcms2 2.17-1 2.18-1 0.01 MiB 0.22 MiB
extra/ldb 2:4.23.4-1 2:4.23.4-2 0.00 MiB 0.45 MiB
extra/lensfun 1:0.3.4-5 1:0.3.4-6 0.00 MiB 0.38 MiB
multilib/lib32-icu 78.1-2 78.2-1 0.00 MiB 10.87 MiB
multilib/lib32-libtasn1 4.20.0-1 4.21.0-1 0.00 MiB 0.04 MiB
multilib/lib32-sdl2-compat 2.32.60-1 2.32.62-1 0.00 MiB 0.12 MiB
multilib/lib32-sdl3 3.2.28-1 3.4.0-1 0.34 MiB 1.11 MiB
multilib/lib32-sqlite 3.51.1-1 3.51.2-1 0.00 MiB 0.70 MiB
extra/libcaca 0.99.beta20-5 0.99.beta20-6 -0.08 MiB 0.41 MiB
extra/libcamera 0.6.0-1 0.6.0-2 0.00 MiB 0.61 MiB
extra/libcamera-ipa 0.6.0-1 0.6.0-2 0.00 MiB 2.01 MiB
core/libcap-ng 0.8.5-3 0.8.5-4 0.00 MiB 0.04 MiB
extra/libftdi 1.5-7 1.5-9 0.00 MiB 0.12 MiB
extra/libgexiv2 0.14.6-1 0.14.6-2 0.00 MiB 0.13 MiB
extra/libgirepository 1.86.0-1 1.86.0-2 0.00 MiB 0.14 MiB
extra/libieee1284 0.2.11-18 0.2.11-19 0.00 MiB 0.06 MiB
extra/liblc3 1.1.3-1 1.1.3-2 0.01 MiB 0.12 MiB
extra/libnbd 1.24.0-1 1.24.0-2 0.00 MiB 0.79 MiB
extra/libplist 2.7.0-1 2.7.0-2 -0.01 MiB 0.16 MiB
core/libseccomp 2.5.6-1 2.6.0-1 0.05 MiB 0.09 MiB
core/libtasn1 4.20.0-1 4.21.0-1 0.00 MiB 0.13 MiB
extra/libvirt-python 1:11.10.0-1 1:11.10.0-2 0.06 MiB 0.23 MiB
extra/libwbclient 2:4.23.4-1 2:4.23.4-2 0.00 MiB 0.04 MiB
core/libxml2 2.15.1-4 2.15.1-5 0.01 MiB 0.75 MiB
core/libxml2-docs 2.15.1-4 2.15.1-5 0.00 MiB 0.43 MiB
extra/libxslt 1.1.45-1 1.1.45-2 0.00 MiB 0.20 MiB
extra/lilv 0.26.2-1 0.26.2-2 0.00 MiB 0.08 MiB
extra/lirc 1:0.10.2-5 1:0.10.2-6 0.02 MiB 1.15 MiB
extra/mallard-ducktype 1.0.2-12 1.0.2-13 0.00 MiB 0.10 MiB
extra/meson 1.10.0-1 1.10.0-4 1.77 MiB 2.40 MiB
extra/net-snmp 5.9.4-7 5.9.4-8 0.00 MiB 2.02 MiB
extra/nftables 1:1.1.6-1 1:1.1.6-2 0.00 MiB 0.42 MiB
extra/perf 6.18-1 6.18-2 0.00 MiB 3.00 MiB
extra/postgresql 18.1-1 18.1-2 0.00 MiB 19.52 MiB
extra/postgresql-libs 18.1-1 18.1-2 0.00 MiB 1.90 MiB
extra/protobuf 33.1-1 33.1-3 0.00 MiB 3.61 MiB
extra/pysolfc 3.4.1-1 3.4.1-2 0.45 MiB 32.77 MiB
extra/python-annotated-types 0.7.0-2 0.7.0-3 0.01 MiB 0.02 MiB
extra/python-argcomplete 3.6.2-1 3.6.2-2 0.01 MiB 0.07 MiB
extra/python-attrs 25.4.0-1 25.4.0-3 0.02 MiB 0.11 MiB
extra/python-autocommand 2.2.2-7 2.2.2-9 0.00 MiB 0.02 MiB
extra/python-babel 2.17.0-1 2.17.0-3 0.13 MiB 6.50 MiB
extra/python-beautifulsoup4 4.14.3-1 4.14.3-2 0.12 MiB 0.20 MiB
core/python-brotli 1.1.0-3 1.2.0-1 0.04 MiB 0.34 MiB
extra/python-cairo 1.29.0-1 1.29.0-2 0.00 MiB 0.09 MiB
extra/python-certifi 2025.11.12-1 2026.01.04-1 0.00 MiB 0.01 MiB
extra/python-cffi 2.0.0-1 2.0.0-2 0.02 MiB 0.28 MiB
extra/python-charset-normalizer 3.4.4-1 3.4.4-2 -0.21 MiB 0.10 MiB
extra/python-click 8.2.1-1 8.3.1-1 0.18 MiB 0.23 MiB
extra/python-configobj 5.0.9-5 5.0.9-6 0.01 MiB 0.07 MiB
extra/python-cryptography 46.0.3-1 46.0.3-2 0.17 MiB 1.29 MiB
extra/python-dbus 1.4.0-1 1.4.0-2 0.01 MiB 0.12 MiB
extra/python-distro 1.9.0-3 1.9.0-4 0.02 MiB 0.04 MiB
extra/python-docutils 1:0.22.3-1 1:0.22.3-2 0.49 MiB 0.99 MiB
extra/python-evdev 1.9.2-1 1.9.2-2 0.15 MiB 0.12 MiB
extra/python-fastjsonschema 2.21.2-1 2.21.2-2 0.01 MiB 0.05 MiB
extra/python-filelock 3.20.0-2 3.20.2-1 0.02 MiB 0.03 MiB
extra/python-fonttools 4.61.1-1 4.61.1-2 0.82 MiB 2.91 MiB
extra/python-gobject 3.54.5-1 3.54.5-2 0.02 MiB 0.31 MiB
extra/python-idna 3.11-1 3.11-2 0.29 MiB 0.11 MiB
extra/python-imagesize 1.4.1-6 1.4.1-7 0.00 MiB 0.01 MiB
extra/python-inflect 7.5.0-1 7.5.0-2 0.03 MiB 0.08 MiB
extra/python-jaraco.collections 5.1.0-1 5.1.0-3 0.00 MiB 0.02 MiB
extra/python-jaraco.context 6.0.1-1 6.0.1-3 0.00 MiB 0.01 MiB
extra/python-jaraco.functools 4.1.0-1 4.1.0-3 0.00 MiB 0.02 MiB
extra/python-jaraco.text 4.0.0-2 4.0.0-4 0.00 MiB 0.02 MiB
extra/python-jinja 1:3.1.6-1 1:3.1.6-3 0.28 MiB 0.32 MiB
extra/python-lxml 6.0.2-1 6.0.2-2 -0.10 MiB 1.52 MiB
extra/python-magic 1:0.4.27-5 1:0.4.27-6 0.00 MiB 0.02 MiB
extra/python-mako 1.3.10-1 1.3.10-4 0.02 MiB 0.17 MiB
extra/python-markdown 3.10.0-1 3.10.0-2 0.10 MiB 0.19 MiB
extra/python-markupsafe 3.0.2-1 3.0.2-2 0.01 MiB 0.02 MiB
extra/python-moddb 0.14.0-1 0.14.0-2 0.05 MiB 0.13 MiB
extra/python-more-itertools 10.8.0-1 10.8.0-2 0.02 MiB 0.12 MiB
extra/python-ordered-set 4.1.0-7 4.1.0-8 0.01 MiB 0.02 MiB
extra/python-packaging 25.0-1 25.0-4 0.07 MiB 0.13 MiB
extra/python-pefile 2024.8.26-1 2024.8.26-2 0.02 MiB 0.17 MiB
extra/python-pillow 12.1.0-1 12.1.0-2 0.41 MiB 0.91 MiB
extra/python-pip 25.3-1 25.3-3 1.42 MiB 2.64 MiB
extra/python-pipx 1.8.0-1 1.8.0-2 0.10 MiB 0.16 MiB
extra/python-platformdirs 4.5.1-1 4.5.1-3 0.04 MiB 0.04 MiB
extra/python-ply 3.11-15 3.11-16 0.01 MiB 0.10 MiB
extra/python-pycparser 2.23-1 2.23-2 1.26 MiB 0.33 MiB
extra/python-pydantic 2.12.5-1 2.12.5-4 0.64 MiB 0.86 MiB
extra/python-pydantic-core 3:2.41.5-1 3:2.41.5-3 -0.01 MiB 1.66 MiB
extra/python-pygame 2.6.1-2 2.6.1-3 0.28 MiB 5.09 MiB
extra/python-pygments 2.19.2-1 2.19.2-3 0.92 MiB 2.43 MiB
extra/python-pyqt5 5.15.11-3 5.15.11-5 -0.12 MiB 3.71 MiB
extra/python-pyqt5-sip 12.17.2-1 12.17.2-2 0.00 MiB 0.06 MiB
extra/python-pyrate-limiter 3.9.0-1 3.9.0-2 0.04 MiB 0.07 MiB
extra/python-pysol_cards 0.24.0-1 0.24.0-2 0.00 MiB 0.03 MiB
extra/python-pytz 2025.2-1 2025.2-2 0.02 MiB 0.05 MiB
extra/python-requests 2.32.5-1 2.32.5-3 0.01 MiB 0.12 MiB
extra/python-roman-numerals-py 3.1.0-1 3.1.0-2 0.00 MiB 0.01 MiB
extra/python-setuptools 1:80.9.0-2 1:80.9.0-4 0.50 MiB 1.29 MiB
extra/python-six 1.17.0-1 1.17.0-2 0.00 MiB 0.03 MiB
extra/python-smartypants 2.0.2-1 2.0.2-2 0.00 MiB 0.02 MiB
extra/python-snowballstemmer 2.2.0-7 2.2.0-8 0.04 MiB 0.22 MiB
extra/python-soupsieve 2.8.1-1 2.8.1-3 0.05 MiB 0.09 MiB
extra/python-sphinx 8.2.3-1 8.2.3-4 1.41 MiB 2.77 MiB
extra/python-sphinx-alabaster-theme 1.0.0-4 1.0.0-6 0.00 MiB 0.02 MiB
extra/python-sphinxcontrib-applehelp 2.0.0-3 2.0.0-5 0.00 MiB 0.03 MiB
extra/python-sphinxcontrib-devhelp 2.0.0-4 2.0.0-6 0.00 MiB 0.02 MiB
extra/python-sphinxcontrib-htmlhelp 2.1.0-3 2.1.0-5 0.01 MiB 0.04 MiB
extra/python-sphinxcontrib-jsmath 1.0.1-19 1.0.1-21 0.00 MiB 0.01 MiB
extra/python-sphinxcontrib-qthelp 2.0.0-3 2.0.0-5 0.01 MiB 0.03 MiB
extra/python-sphinxcontrib-serializinghtml 2.0.0-3 2.0.0-5 0.01 MiB 0.03 MiB
extra/python-tomli 2.2.1-1 2.2.1-2 0.01 MiB 0.03 MiB
extra/python-toolz 1.1.0-1 1.1.0-2 0.01 MiB 0.14 MiB
extra/python-tqdm 4.67.1-3 4.67.1-5 0.01 MiB 0.13 MiB
extra/python-trove-classifiers 2025.12.1.14-1 2025.12.1.14-3 0.03 MiB 0.02 MiB
extra/python-typeguard 4.4.4-1 4.4.4-2 0.04 MiB 0.08 MiB
extra/python-typing-inspection 0.4.2-1 0.4.2-2 0.01 MiB 0.02 MiB
extra/python-typing_extensions 4.15.0-1 4.15.0-3 0.02 MiB 0.09 MiB
extra/python-typogrify 2.1.0-1 2.1.0-2 0.00 MiB 0.02 MiB
extra/python-urllib3 2.6.2-1 2.6.3-1 0.14 MiB 0.24 MiB
extra/python-userpath 1.9.2-3 1.9.2-4 0.00 MiB 0.02 MiB
extra/python-validate-pyproject 0.24.1-1 0.24.1-3 0.06 MiB 0.09 MiB
extra/python-wheel 0.45.1-1 0.45.1-4 0.02 MiB 0.07 MiB
extra/python-yaml 6.0.3-1 6.0.3-2 -0.01 MiB 0.19 MiB
extra/rdma-core 60.0-2 60.0-3 -0.19 MiB 2.49 MiB
extra/samba 2:4.23.4-1 2:4.23.4-2 0.00 MiB 8.45 MiB
extra/sdl2-compat 2.32.60-1 2.32.62-1 0.00 MiB 0.45 MiB
extra/sdl3 3.2.28-1 3.4.0-1 0.44 MiB 1.52 MiB
extra/smbclient 2:4.23.4-1 2:4.23.4-2 0.00 MiB 7.20 MiB
core/sqlite 3.51.1-1 3.51.2-1 0.01 MiB 2.23 MiB
extra/subversion 1.14.5-4 1.14.5-5 -0.02 MiB 8.11 MiB
core/sudo 1.9.17.p2-1 1.9.17.p2-2 0.00 MiB 1.84 MiB
extra/swig 4.4.0-1 4.4.0-2 0.00 MiB 1.19 MiB
extra/syslog-ng 4.10.2-4 4.10.2-5 0.00 MiB 1.77 MiB
extra/talloc 2.4.3-1 2.4.3-2 0.00 MiB 0.05 MiB
extra/tdb 1.4.14-1 1.4.14-2 0.00 MiB 0.07 MiB
extra/tevent 1:0.17.1-1 1:0.17.1-2 0.00 MiB 0.06 MiB
core/util-linux 2.41.3-1 2.41.3-2 0.00 MiB 5.22 MiB
core/util-linux-libs 2.41.3-1 2.41.3-2 0.00 MiB 0.48 MiB
extra/vapoursynth 73-1 73-2 0.00 MiB 0.96 MiB
extra/virt-install 5.1.0-1 5.1.0-2 0.05 MiB 1.19 MiB
extra/virt-manager 5.1.0-1 5.1.0-2 0.05 MiB 0.64 MiB
extra/vulkan-headers 1:1.4.335.0-1 1:1.4.335.0-2 0.03 MiB 1.61 MiB
extra/xcb-proto 1.17.0-3 1.17.0-4 0.01 MiB 0.13 MiB
extra/yt-dlp 2025.12.08-1 2025.12.08-2 0.86 MiB 5.05 MiB
extra/zbar 0.23.93-4 0.23.93-5 0.01 MiB 0.24 MiB
Total Download Size: 226.33 MiB
Total Installed Size: 1002.24 MiB
Net Upgrade Size: 14.36 MiB
:: Proceed with installation? [Y/n] n
P.S. That was a good few hours of work. This is the cleanest my package version ignore list warnings have been in a long time
Code: Select all
[nicetry ~]# pacman -Syu
:: Synchronizing package databases...
core is up to date
extra is up to date
multilib is up to date
:: Starting full system upgrade...
warning: openresolv: ignoring package upgrade (3.16.5-1 => 3.17.4-1)
warning: xkeyboard-config: ignoring package upgrade (2.39-1 => 2.46-1)
there is nothing to do
Re: Arch Linux 2024
Posted: Tue Jan 13, 2026 8:53 pm
by Grogan
I couldn't play my beloved EA games last night (well, 4 AM), because my EA App client wouldn't run. Parts of it would load, but not the client UI. It was behaving like busy servers ("connecting to EA App" which you shouldn't see) so I figured it was the servers not responding. Bad network programming can cause applications to stall if they don't get a response. But when it was still doing it in the light of day I knew I'd been had.
After yesterday's systemd updates I noticed a shit load of bwrap container processes loading glycin (image sandboxing). It's because of gdk-pixbuf2 (the component that uses glycin). Since my EA App was working prior to yesterday's updates, I guessed that it was because of that. Something was probably crashing in wine, or a component of the windows application when a resource couldn't load.
Can't remove glycin, and I couldn't find a systemd unit to disable that would stop this. I think it's built in behaviour, it sets up glycin sandboxes in bwrap containers for the user if its present (probably systemd-logind as it happens as soon as I log in at the console)
So I compiled a gdk-pixbuf2 with glycin disabled. It involves -D glycin=disabled but also -D jpg=enabled and gif, png and tiff if not using glycin. Arch had them listed in the PKGBUILD, but disabled, so it was obvious what I had to do. Then I was able to remove glycin. I rebooted so everything was on the same page after installing that package.
When I ran Lutris, all the tiles and buttons were messed up, missing, jumping around on mouse hover etc. Shit... what else uses glycin? Apparently nothing, dependency wise, but Arch compiles librsvg without gdk-pixbuf2 (pixbuf-loader disabled) because IT will use glycin in its stead (or glycin will use it) and Lutris uses SVG (python errors related to image loading also were a clue). So I recompiled librsvg with the pixbuff loader enabled.
Now Lutris works correctly, and my EA App launches correctly again.
Changes to gdk-pixbuf2 PKGBUILD:
Code: Select all
build() {
local meson_options=(
-D android=disabled
-D builtin_loaders=all
-D documentation=true
-D gif=enabled
-D glycin=disabled
-D gtk_doc=true
-D installed_tests=false
-D introspection=enabled
-D jpeg=enabled
-D man=true
-D others=enabled
-D png=enabled
-D thumbnailer=enabled
-D tiff=enabled
)
Image libraries enabled, glycin disabled. This also means that those image libraries will be hard dependencies for the package now, but I didn't bother adding them to the depends array. They are obviously needed for like everything anyway and I'll be compiling this package from now on.
Changes to librsvg PKGBUILD:
Code: Select all
build() {
local meson_options=(
-D avif=enabled
-D pixbuf-loader=enabled
-D vala=disabled
)
pixbuf-loader enabled, and I disabled building with vala (because I don't want it installed, I don't use Gnome and I don't care)
I'm pissed... it took me 3 hours today to figure out these dependencies. Ultimately it's systemd's fuckery, but Arch just willy nilly lets changes like that happen. All this containerization is a curse, I don't need to use my image libraries in a container.
Re: Arch Linux 2024
Posted: Wed Jan 14, 2026 10:14 am
by Grogan
So it looks like this was one big coincidence, and it's EA servers/network connectivity after all. it's probably not for everyone (there'd be Hell to pay) but whatever I connect to with the EA client. (I did a search and there were 41 reports of "EA down" on whatever "is it down" service that was, from Canada within that hour)
After doing all the above with gdk-pixbuf2 etc., the EA App just magically worked instantly. It worked most of the night, and I had the client closed and opened a few times throughout.
Then, it happened once later, at first stalled "connecting to the EA App" (which has not actually been unusual lately) and I had to kill it. Then on the next try the connection went through but the client wouldn't draw its window. Killed and tried again, and it worked. I played Mass Effect for a while and quit. Then later it was back to the bad behaviour permanently again.
Still though, I'm glad I noticed that systemd fuckery with glycin. I'm not having that even if it wasn't the cause of this, so it wasn't wasted effort.
Re: Arch Linux 2024
Posted: Wed Jan 14, 2026 5:35 pm
by Zema Bus
They're keeping you on your toes, at the same time
Re: Arch Linux 2024
Posted: Wed Jan 14, 2026 8:45 pm
by Grogan
Confuckingfirmed... the EA App gets its data feed, and draws its window if I connect through a VPN. I tried 3 times just now and it was the same, stalling on connect and then not drawing window. Connect through VPN (Toronto server) and bingo.
P.S. I had a tough time tonight even using my VPN. Eventually I got in using a Montreal presence, after a few tries. I let the client sit there with no window for about a minute and eventually it popped up, first time I've seen it actually respond when it's in that state. Loading the tiles and images were slow, and some of them didn't resolve, but my game launched.
The moral of the story is, EA blows... never underestimate just how vigorous is their fellatio
Re: Arch Linux 2024
Posted: Thu Jan 15, 2026 6:35 am
by Zema Bus
And the icing on the cake is EA now being connected to Trump's son-in-law Jared Kusher and Saudi Arabia
Re: Arch Linux 2024
Posted: Thu Jan 15, 2026 7:50 am
by Grogan
Yeah, and they are holding my games hostage. I'll bet this is happening because they canceled network provider contracts and stuff, to reduce overhead and make the company look more profitable in the short term. Or something like that, that companies in that stage like to do.
Re: Arch Linux 2024
Posted: Tue Jan 27, 2026 8:41 pm
by Grogan
New glibc AGAIN in Arch. That's 3 builds in the last week or so. This time, I don't have to do it because the only change is "remove sframe support" which I've been disabling for years. I don't do stack tracing/debugging, I build my libraries for performance. They are disabling it because binutils 2.46 is going to have a newer, incompatible version of sframe. I'll be disabling that too
Re: Arch Linux 2024
Posted: Wed Jan 28, 2026 11:05 pm
by Grogan
See why most of the time you can't do shit like this? I normally wouldn't try it, but I needed my nslookup program to work right quick. (I just compile some of the bind tools to /usr/local without bind itself being installed)
If it were a library mostly unused by a program until you go to use a function in the program it might work to satisfy the dependency, or if they just bumped the soname as a matter of practice (API/ABI hasn't actually changed) but in this case it's a big nope.
Code: Select all
[grogan@nicetry ~]$ nslookup mikeserv.com
nslookup: error while loading shared libraries: libicuuc.so.76: cannot open shared object file: No such file or directory
Code: Select all
[nicetry ~]# cd /usr/lib
[nicetry lib]# ln -s libicuuc.so.78 libicuuc.so.76]
Code: Select all
[grogan@nicetry ~]$ nslookup mikeserv.com
nslookup: symbol lookup error: /usr/local/lib/libxml2.so.2: undefined symbol: UCNV_TO_U_CALLBACK_STOP_76
Yeah, I've got an old libxml2.so.2 (for compat) in there that I had to fix too. I can probably get rid of it now (the bind libraries were probably the last thing) but it still compiles, so it can stay for anything I may have forgotten that needs the old ABI (libxml2 suddenly jumped from .so.2 to .so.16 about a year ago). It needs recompiling because of that stupid icu library as an inherited dependency, no ands, ifs or buts. ('kin libicu... I detest those libraries). It had actually been a while since I ran that old nslookup binary on Arch (I normally do work-ish things on my serious system) it was compiled last year.
Re: Arch Linux 2024
Posted: Fri Jan 30, 2026 12:37 am
by Grogan
Damn, Arch sure made the PKGBUILD for Rust more clever and difficult. I like Rust built a certain way, and I use LLVM/clang for the C and C++ parts of the build (tools, bindings etc.), after all, the rust compiler IS LLVM at the back end. I don't know why distributors all seem to insist on using gcc for the rust build, I've been doing it like this for a very long time. I also build LLVM in statically so my Rust isn't broken when I upgrade LLVM (I want to be able to use it to bootstrap a new one). That's something I probably couldn't do if I was using the distro's LLVM and GNU toolchains in the Rust build. No frame pointers and debugging options enabled for me either.
Arch builds for "x86_64-unknown-linux-gnu", "i686-unknown-linux-gnu", "x86_64-unknown-linux-musl" "aarch64-unknown-linux-gnu", "aarch64-unknown-linux-musl", "wasm32-unknown-unknown", "wasm32v1-none", "wasm32-wasip1", "wasm32-wasip1-threads" and "wasm32-wasip2". They write separate bootstrap files for x86_64 and aarch64 to bootstrap.toml and they stuck all their wasm shit in the aarch64 bootstrap file (lol... it's bytecode and it's got nothing to do with that arch specifically).
I only build the "x86_64-unknown-linux-gnu", "i686-unknown-linux-gnu" targets. There is nothing I build at this time that needs any of those other targets.
They are hard coding the build to use x86_64-pc-linux-gnu-gcc as the linker front end and such with a patch now (0006-compiler-Use-target-specific-GCC-linkers.patch) which fails my build spectacularly if applied. I use LLVM's lld for the linker.
I had to use my own sections, for example:
Code: Select all
[target.x86_64-unknown-linux-gnu]
llvm-config = "/usr/bin/llvm-config"
cc = "/usr/bin/clang"
cxx = "/usr/bin/clang++"
ar = "/usr/bin/llvm-ar"
ranlib = "/usr/bin/llvm-ranlib"
optimized-compiler-builtins = "/usr/lib/clang/21/lib/x86_64-pc-linux-gnu/libclang_rt.builtins.a"
and hard code the path to clang's built-ins because for some reason $clangdir isn't working in this build anymore. (I could probably ditch that directive though, that shouldn't need to be manually specified)
I have to gut and edit both the PKGBUILD and bootstrap.x86_64.toml now for this build.
But I have that all sorted (should be easy next time), and rebuilt yesterday's Firefox again to test toolchains and all is well.
Re: Arch Linux 2024
Posted: Mon Feb 02, 2026 11:07 am
by Grogan
You know who else did that goddamn stupid fucking shit with gdk-pixbuf and glycin? Crux! Well, they didn't do the container thing (that was systemd) but they (prt-get sysup) built my gdk-pixbuf with glycin, disabling all the other image loaders. I guess I already had glycin installed (because prt-get sysup doesn't install new dependencies) but not anymore.
What happened was I went to use my new Claws Mail program tonight, and it wasn't displaying any icons anywhere. Just text on the toolbar and no message icons. I just noticed it tonight, because I mostly check my mail in Arch and hadn't gone to use it here in some days. (I remember prt-get compiled a gdk-pixbuf update a few nights ago but I thought surely Crux wouldn't do that lol)
I first tried recompiling my Claws Mail again, thinking it needed to relink with gdk-pixbuf but when it didn't work, I checked the Pkgfile in ports and sure enough... so I compiled it without glycin, enabled all its image loaders, locked the package, removed glycin so nothing can use that poxy shit again AND... my Claws Mail program now displays icons correctly again.
Re: Arch Linux 2024
Posted: Tue Feb 10, 2026 8:17 pm
by Grogan
Arch just keeps getting more and more complicated and clever. I'm fixing up new builds for Linux 6.19 headers, glibc, gcc, binutils etc. and their new gcc PKGBUILD splits out 29 packages now. I don't think any distro is this bad for split gcc packages now.
Code: Select all
pkgname=(
gcc
gcc-ada
gcc-d
gcc-fortran
gcc-gcobol
gcc-go
gcc-libs
gcc-m2
gcc-objc
gcc-rust
lib32-gcc-libs
libasan
libatomic
libgcc
libgccjit
libgcobol
libgfortran
libgm2
libgo
libgomp
libgphobos
libitm
liblsan
libobjc
libquadmath
libstdc++
libtsan
libubsan
lto-dump
)
Now, I don't build all of that, but even so, a lot of that stuff was just in gcc-libs. That actually makes more work for me, because now I have even more stanzas to remove from the PKGBUILD and more system packages to ignore and track. I think I'm going to just fix up my glibc PKGBUILD to be more monolithic... just make install the whole thing to the pkgdir (I've been wanting to do that anyway to get the static libraries that Arch doesn't install). The lib32-gcc-libs will be a separate package.
Arch is getting ridiculous.
Re: Arch Linux 2024
Posted: Wed Feb 11, 2026 3:17 am
by Grogan
I almost had everything right in one go, but I missed a "make -C gcc DESTDIR=$pkgdir install" (which cd's into directory gcc and does make install in there only) when what I wanted was "make DESTDIR=$pkgdir install" to install all of it. I was surprised to see no failures or packaging errors... it's a good thing I extracted my package first to make sure it contained everything. The libraries were missing
It was also easier to NOT make a separate lib32-gcc-libs package, since the stuff is all built and installed with make install anyway. The original PKGBUILD removes those lib32 libraries and installs them again during the lib32-gcc-libs packaging step.
It was still prudent to build libgccjit separately though because it needs an option that we don't want for the rest of the build (--enable-host-shared). I don't even use that, it just sounds like a good thing to have (a JIT compiler).
So only two packages now, and I configured provides=, replaces= and conflicts= so any split packages would be removed first.
Code: Select all
[nicetry gcc]# pacman -U *.pkg.tar.zst
loading packages...
resolving dependencies...
looking for conflicting packages...
:: gcc-15.2.1+r604+g0b99615a8aef-1 and gcc-libs-15.2.1+r447+g6a64f6c3ebb8-1 are in conflict. Remove gcc-libs? [y/N] y
:: gcc-15.2.1+r604+g0b99615a8aef-1 and lib32-gcc-libs-15.2.1+r447+g6a64f6c3ebb8-1 are in conflict. Remove lib32-gcc-libs? [y/N] y
:: gcc-15.2.1+r604+g0b99615a8aef-1 and lto-dump-15.2.1+r447+g6a64f6c3ebb8-1 are in conflict. Remove lto-dump? [y/N] y
Package (5) Old Version New Version Net Change
gcc-libs 15.2.1+r447+g6a64f6c3ebb8-1 -7.40 MiB
lib32-gcc-libs 15.2.1+r447+g6a64f6c3ebb8-1 -35.34 MiB
lto-dump 15.2.1+r447+g6a64f6c3ebb8-1 -42.16 MiB
gcc 15.2.1+r447+g6a64f6c3ebb8-1 15.2.1+r604+g0b99615a8aef-1 73.43 MiB
libgccjit 15.2.1+r447+g6a64f6c3ebb8-1 15.2.1+r604+g0b99615a8aef-1 0.00 MiB
Total Installed Size: 320.71 MiB
Net Upgrade Size: -11.47 MiB
:: Proceed with installation? [Y/n] y
(2/2) checking keys in keyring [-----------------------------------------------------------------------------] 100%
(2/2) checking package integrity [-----------------------------------------------------------------------------] 100%
(2/2) loading package files [-----------------------------------------------------------------------------] 100%
(2/2) checking for file conflicts [-----------------------------------------------------------------------------] 100%
(5/5) checking available disk space [-----------------------------------------------------------------------------] 100%
:: Processing package changes...
(1/3) removing lto-dump [-----------------------------------------------------------------------------] 100%
(2/3) removing lib32-gcc-libs [-----------------------------------------------------------------------------] 100%
(3/3) removing gcc-libs [-----------------------------------------------------------------------------] 100%
(1/2) upgrading gcc [-----------------------------------------------------------------------------] 100%
(2/2) upgrading libgccjit [-----------------------------------------------------------------------------] 100%
:: Running post-transaction hooks...
(1/2) Arming ConditionNeedsUpdate...
(2/2) Updating the info directory file...
This installs the static libraries and all, so now I will be able to build fully static binaries on Arch when I want to. I don't get why distributors all think they should take people's options away. I've run afoul of that on Arch. No more.
Anyway, here's how I did this.
Code: Select all
# Maintainer: Giancarlo Razzolini <grazzolini@archlinux.org>
# Maintainer: Frederik Schwan <freswa at archlinux dot org>
# Contributor: Bartłomiej Piotrowski <bpiotrowski@archlinux.org>
# Contributor: Allan McRae <allan@archlinux.org>
# Contributor: Daniel Kozak <kozzi11@gmail.com>
# toolchain build order: linux-api-headers->glibc->binutils->gcc->glibc->binutils->gcc
# NOTE: libtool requires rebuilt with each new gcc version
pkgname=(
gcc
libgccjit
)
pkgver=15.2.1+r604+g0b99615a8aef
_commit=0b99615a8aef011cff76c6caa8c09434f46598b3
pkgrel=1
pkgdesc='The GNU Compiler Collection'
arch=(x86_64)
license=(GPL-3.0-with-GCC-exception GFDL-1.3-or-later)
url='https://gcc.gnu.org'
makedepends=(
binutils
doxygen
git
lib32-glibc
lib32-gcc-libs
libisl
libmpc
python
zstd
)
checkdepends=(
dejagnu
expect
inetutils
python-pytest
tcl
)
options=(
!emptydirs
!lto
)
_libdir=usr/lib/gcc/$CHOST/${pkgver%%+*}
source=(git+https://sourceware.org/git/gcc.git#commit=$_commit
c89 c99
gcc-ada-repro.patch
)
validpgpkeys=(F3691687D867B81B51CE07D9BBE43771487328A9 # bpiotrowski@archlinux.org
86CFFCA918CF3AF47147588051E8B148A9999C34 # foutrelis@archlinux.org
13975A70E63C361C73AE69EF6EEB81F8981C74C7 # richard.guenther@gmail.com
D3A93CAD751C2AF4F8C7AD516C35B99309B5FA62) # Jakub Jelinek <jakub@redhat.com>
sha256sums=('fda170be6da777107c74ad322d51a508edf448b86ce8247755eb0eb1524f38b6'
'7b09ec947f90b98315397af675369a1e3dfc527fa70013062e6e85c4be0275ab'
'44ea973558842f3f4bd666bdaf6e810fd7b7c7bd36b5cc4c69f93d2cd0124fc7'
'1773f5137f08ac1f48f0f7297e324d5d868d55201c03068670ee4602babdef2f')
pkgver() {
cd gcc
echo "$(cat gcc/BASE-VER)+$(git describe --abbrev=12 --tags | sed 's/[^-]*-[^-]*-//;s/[^-]*-/r&/;s/-/+/g;s/_/./')"
}
prepare() {
[[ ! -d gcc ]] && ln -s gcc-${pkgver/+/-} gcc
cd gcc
# Do not run fixincludes
sed -i 's@\./fixinc\.sh@-c true@' gcc/Makefile.in
# Arch Linux installs x86_64 libraries /lib
sed -i '/m64=/s/lib64/lib/' gcc/config/i386/t-linux64
# Reproducible gcc-ada
#patch -Np0 < "$srcdir/gcc-ada-repro.patch"
mkdir -p "$srcdir/gcc-build"
mkdir -p "$srcdir/libgccjit-build"
}
build() {
local _confflags=(
--prefix=/usr
--libdir=/usr/lib
--libexecdir=/usr/lib
--mandir=/usr/share/man
--infodir=/usr/share/info
--with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues \
--with-build-config=bootstrap-lto
--with-linker-hash-style=gnu
--with-system-zlib
--enable-__cxa_atexit
--disable-cet
--enable-checking=release
--enable-clocale=gnu
--enable-gnu-indirect-function
--enable-gnu-unique-object
--enable-libstdcxx-backtrace
--enable-link-serialization=1
--enable-linker-build-id
--enable-lto
--enable-multilib
--enable-plugin
--enable-shared
--enable-threads=posix
--disable-libssp
--disable-libstdcxx-pch
--disable-werror
)
cd gcc-build
# I don't enable -Werror=format-security in the first place! So it's not in my makepkg flags to remove.
#CFLAGS=${CFLAGS/-Werror=format-security/}
#CXXFLAGS=${CXXFLAGS/-Werror=format-security/}
"$srcdir/gcc/configure" \
--enable-languages=c,c++,lto \
--enable-bootstrap \
"${_confflags[@]:?_confflags unset}"
# see https://bugs.archlinux.org/task/71777 for rationale re *FLAGS handling
make -j24 -O STAGE1_CFLAGS="-O2 -march=alderlake" \
BOOT_CFLAGS="$CFLAGS" \
BOOT_LDFLAGS="$LDFLAGS" \
LDFLAGS_FOR_TARGET="$LDFLAGS" \
bootstrap
# make documentation
make -O -C $CHOST/libstdc++-v3/doc doc-man-doxygen
# Build libgccjit separately, to avoid building all compilers with --enable-host-shared
# which brings a performance penalty
cd "$srcdir"/libgccjit-build
"$srcdir/gcc/configure" \
--enable-languages=jit \
--disable-bootstrap \
--enable-host-shared \
"${_confflags[@]:?_confflags unset}"
# see https://bugs.archlinux.org/task/71777 for rationale re *FLAGS handling
make -j24 -O STAGE1_CFLAGS="-O2 -march=alderlake" \
BOOT_CFLAGS="$CFLAGS" \
BOOT_LDFLAGS="$LDFLAGS" \
LDFLAGS_FOR_TARGET="$LDFLAGS" \
all-gcc
cp -a gcc/libgccjit.so* ../gcc-build/gcc/
}
check() {
cd gcc-build
# disable libphobos test to avoid segfaults
sed -i '/maybe-check-target-libphobos \\/d' Makefile
# do not abort on error as some are "expected"
make -O -k check || true
"$srcdir/gcc/contrib/test_summary"
}
package_gcc() {
pkgdesc="The GNU Compiler Collection - C and C++ frontends"
depends=(
'binutils>=2.28'
libmpc
zstd
libisl.so
)
optdepends=(
'lib32-gcc-libs: for generating code for 32-bit ABI'
)
provides=(
$pkgname-multilib
gcc-libs
lib32-gcc-libs
libasan
libatomic
libgcc
libgm2
libgomp
libitm
liblsan
libquadmath
libstdc++
libtsan
libubsan
lto-dump
)
replaces=(
$pkgname-multilib
gcc-libs
lib32-gcc-libs
libasan
libatomic
libgcc
libgm2
libgomp
libitm
liblsan
libquadmath
libstdc++
libtsan
libubsan
lto-dump
)
conflicts=(
$pkgname-multilib
gcc-libs
lib32-gcc-libs
libasan
libatomic
libgcc
libgm2
libgomp
libitm
liblsan
libquadmath
libstdc++
libtsan
libubsan
lto-dump
)
options=(
!emptydirs
staticlibs
)
cd gcc-build
make install DESTDIR="$pkgdir"
# many packages expect this symlink
ln -s gcc "$pkgdir"/usr/bin/cc
# create cc-rs compatible symlinks
# https://github.com/rust-lang/cc-rs/blob/1.0.73/src/lib.rs#L2578-L2581
for binary in {c++,g++,gcc,gcc-ar,gcc-nm,gcc-ranlib}; do
ln -s /usr/bin/$binary "$pkgdir"/usr/bin/x86_64-linux-gnu-$binary
done
# POSIX conformance launcher scripts for c89 and c99
install -Dm755 "$srcdir/c89" "$pkgdir/usr/bin/c89"
install -Dm755 "$srcdir/c99" "$pkgdir/usr/bin/c99"
# byte-compile python libraries
python -m compileall "$pkgdir/usr/share/gcc-${pkgver%%+*}/"
python -O -m compileall "$pkgdir/usr/share/gcc-${pkgver%%+*}/"
# Install Runtime Library Exception
install -d "$pkgdir/usr/share/licenses/$pkgname/"
ln -s /usr/share/licenses/gcc-libs/RUNTIME.LIBRARY.EXCEPTION \
"$pkgdir/usr/share/licenses/$pkgname/"
}
package_libgccjit() {
pkgdesc="Just-In-Time Compilation with GCC backend"
depends=(
gcc
libisl.so
)
provides=(
libgccjit.so
)
cd gcc-build
make -C gcc DESTDIR="$pkgdir" jit.install-common jit.install-info
# Install Runtime Library Exception
install -d "$pkgdir/usr/share/licenses/$pkgname/"
ln -s /usr/share/licenses/libgcc/RUNTIME.LIBRARY.EXCEPTION \
"$pkgdir/usr/share/licenses/$pkgname/"
}
Re: Arch Linux 2024
Posted: Wed Feb 11, 2026 5:25 am
by Grogan
Success...
Code: Select all
[grogan@nicetry bin]$ ls -l node
-rwxr-xr-x 1 grogan grogan 99208152 Feb 11 00:04 node
[grogan@nicetry bin]$ file node
node: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 4.4.0, stripped
[grogan@nicetry bin]$ ldd node
not a dynamic executable
That was a test. I couldn't compile that fully static on Arch, not even with my clang because it still has to link in gcc libraries like libatomic.a and libstdc++.a and stuff. Arch was doing install-shared individually during the packaging step.
I've been meaning to fix that for some time now, and that clusterfuck of split packaging motivated me to work on the PKGBUILD.
The reason I want that static is, I'll probably use it for a long time, on both OSes. (It's still going to need a similar glibc shared library to be installed for some functions like gethostbyaddr for example, but it doesn't necessarily have to be the exact same glibc version... for example 2.43 vs. 2.42 is still OK). I only upgrade node.js when the Firefox build needs a new one, which is rare. I keep node in my build directory and always use it by full path to the binary. It has a secondary purpose now too though, yt-dlp.
Re: Arch Linux 2024
Posted: Fri Feb 13, 2026 11:03 pm
by Grogan
Ahh you can't have anything on Arch. They've broken my mpv player AGAIN. I just recompiled the fucking thing last week.
Code: Select all
mpv: error while loading shared libraries: libplacebo.so.351: cannot open shared object file: No such file or directory
Like I even give a fuck about libplacebo. It doesn't do anything
(well... it's a library for drawing custom windows, but it's a stupid one that changes its soname with every minor release)
I can't get rid of it and can't disable it in mpv (there's an option -D videotoolbox-pl=disabled but it still gets a dependency on libplacebo because of ffmpeg). Unless it's possible to compile ffmpeg without it, I'm stuck with that library.
P.S. Actually that's what I've done, I removed libplacebo and other deps I don't want, and built a leaner ffmpeg without as many dependencies. It still uses gnu autoconf and it comes with --enable/--disable options for everything that you can see in ./configure --help. That won't be so fragile now.
Unfortunately, libplacebo is forcibly enabled in mpv (no meson configure option to disable it, and that videotoolbox-pl doesn't) and it's a hard dependency. So I'm going to build libplacebo with a different package name (with provides=, replaces=, conflicts=) to disconnect it from Arch like I do with a lot of their shit, so it won't bother me, and since nothing else (on my system) will need it, I won't have to update it just because Arch thinks it should be upgraded to .so.361 next week. I'm not having my video player broken every time I go to use it. That's not much of an exaggeration, I mostly watch shows and stuff on my Crux setup while I'm in there late at night, so when I go to play a video file on Arch, it's usually broken.
Anyway, problem fucking solved.
Re: Arch Linux 2024
Posted: Mon Feb 16, 2026 8:42 pm
by Grogan
Fuck... Arch has started adding "libgcc libgcc_s.so" (as both package and library name) to dependencies. That's unnecessary to add as a dependency in the first place, most EVERYTHING (except static) compiled with gcc depends on libgcc_s.so.1. It should simply be part of the base system (and seeing as it's a separate package now, that would be practical)
So my provides=libgcc isn't enough, it tries to pull in the libgcc package because "cannot resolve "libgcc_s.so=1-64"
I have to rebuild my damned gcc package again, listing both the package and the library in the provides= array. I also see I'm going to have the same problem with libstdc++ so I have to do the same for that too. While I'm at it, I'm removing that libgccjit from my PKGBUILD so I can have a single gcc package. I haven't yet run into any software that does just-in-time compiles with gcc. I was thinking some web application, but that'd be done with web assembly in the browser.
When I first started using Arch it used to be nice and simple, and they didn't do things like that. Now they are getting down right silly with split packages and stuff. I'm not sure how much longer I can tolerate this distro, but there isn't anything else that would make me happy for gaming. I refuse to use containerized bullshit like the mainstream distros now and I need to be able to compile my own system packages, wines, tools etc. and work around the distro. About the only thing I'd consider switching to is CachyOS, but it's the same environment and I already build optimized packages (and I wouldn't use their distro kernels anyway) so it's pointless.
P.S. gcc library dependencies work now
Re: Arch Linux 2024
Posted: Tue Feb 17, 2026 7:17 am
by Zema Bus
One possible alternative is
Artix, originally based on Arch but it has since gone it's own way with it's own repositories. They don't use systemd (Artix was created back when Arch adopted systemd), instead they have options to use OpenRC, runit, s6, and dinit. I read that it was forked from pre-systemd Arch, so it's basically a continuation of that path.
Re: Arch Linux 2024
Posted: Tue Feb 17, 2026 7:51 am
by Grogan
I've heard of it, yes, I should take a look at that, thanks. It might not be any easier for me to manage though, if it follows Arch too closely.
It would be nice to ditch systemd though... and I'll never use Gnome.
Re: Arch Linux 2024
Posted: Tue Feb 17, 2026 8:27 pm
by Grogan
That Artix link reminded me about GTK+2... Arch is making noise about removing it and dumping everything that depends on it. Libraries, perfectly good applications, including Steam with native-runtime. I actually prefer GTK+2, it's light weight and good looking. My styling is for both, but it actually looks better on GTK2 applications. I have recompiled things to use GTK2, like my music player, audacious for one example. My older libreoffice (pry it from my stiff, dead fingers) is built with GTK2 also.
It's already too late, they've removed GTK2 and replaced it with a gtk2-compat package that depends on GTK3. When they remove things they delete them (PKGBUILDs etc.) so nobody can have them too. They even want people to dump stuff from AUR.
That's going to make it harder, I would have disconnected them from Arch with custom package names so they can't forcibly replace them, which they are likely to do. (I still have the gtk2 distro packages installed, I didn't get around to taking that over on this system). I probably have PKGBUILDs on the other computer, they might not have even changed much since then. Either that or I'll just compile the gtk2 stack the old fashioned way and send it to /usr/local and remove the distro packages.
Re: Arch Linux 2024
Posted: Wed Feb 18, 2026 11:51 pm
by Grogan
It looks like I caught it on time, there were gtk2 and lib32-gtk2 PKGBUILDs preserved in AUR for the last arch gtk2 PKGBUILD, gtk2-2.24.33-5, including patches, and I can still compile it.
So I built gtk2-cust and lib32-gtk2-cust with appropriate provides=gtk2, conflicts=, replaces= to disconnect it from Arch packaging to preserve it. Hopefully glib2 doesn't break its ABI any time soon (because it's common between gtk2, gtk3 and gtk4).
I don't want a "compat" library package to forcibly replace gtk2 sometime when I'm not paying attention. (they deliberately remove includes and stuff so you can't compile against it... Jawohl!)
I was just admiring some of my nice gtk2 based apps last night and vowed to take care of this today as I don't want to lose them. For example, you can't beat this UI. I compile this program against gtk2 only (--disable-qt --disable-gtk3 --enable-gtk), as it is the one that looks best. Arch disables the GTK UI completely and compiles only the QT one (barf).
audacious_gtk2.png
Re: Arch Linux 2024
Posted: Thu Feb 19, 2026 9:10 am
by Zema Bus
That does look really nice
Re: Arch Linux 2024
Posted: Sat Mar 14, 2026 1:01 am
by Grogan
LOL... I got looking through /etc/systemd/system.conf.pacnew to see if there were any new options I need to be aware of. With that, if I don't have the options in my file, new options may be enabled by default and I'll be simply unaware of them.
Here's a new one I noticed (commented out to show the default setting)
I thought, oh great, systemd now freezes your system as a new feature. I went and found what that setting does. It's worded exactly like my sarcastic vision of it.
The CrashAction=freeze setting in system.conf tells the system to freeze when a critical error occurs, allowing you to investigate the issue before taking further action. This is useful for debugging system crashes.
There was an old joke, a gif of a Windows setting dialog that had checkboxes for things like "Piss me off by crashing my programs randomly" and stuff. Well now, "freeze my computer when the system crashes"
Settings are = freeze, reboot, poweroff, or ignore
Another one I don't like
This will lock directories like /boot and /usr, depending on setting. auto, true, false. I think the default of auto makes it so service units can specify that setting. It's for containers. I'd still rather have it fuck off by default though, as I don't use containers set up through systemd (only steam bwrap containers for runtimes) and don't want any units restricting filesystem access, so I set it to false.
Re: Arch Linux 2024
Posted: Thu Mar 19, 2026 10:11 pm
by Grogan
Arch sure has been keeping me busy. harfbuzz, harfbuzz, harfbuzz just about every fucking day, ffmpeg two days in a row (today's build is adding a new dependency, lcms2 support... that's the opposite of what I want to do, add more dependencies to ffmpeg to add another soname to get broken). I compile all these packages, so it's irritating. My fault, I'm invested in the wrong distro framework for my methods (and I can't see myself using any other for my gaming OS), but jeeze.
New Rust build again today, same version, but they added PGO (profile guided optimization) taken from CachyOS (ptr1337). I build my Rust toolchain a bit differently, so I had some mcgyvering to do. I got it right on the first try but I wish I'd been here to keep an eye on the build (got called upstairs). It took a good 15 minutes longer than usual with non-profiled fat LTO (and my binaries are slightly larger) and with 3000 terminal lines and a quiet build with stuff like "-A deprecated" to suppress warnings, I was able to scroll up and see that it did the stages for the components. For example:
Code: Select all
Uplifting library (stage1:x86_64-unknown-linux-gnu -> stage2:i686-unknown-linux-gnu)
Build completed successfully in 0:18:47
Profiling instrumented compiler...
This is now the single, most time consuming build on this machine. (45m8.256s) and that's with just the parts I want. I can build both 64 and 32 bit parts of LLVM in ~30 minutes. A full PGO+LTO build of Firefox takes 40m
I'm sure it's just spinning wheels (umm, Rust is a compiler toolchain, not even shared system libraries... I doubt it matters that much to anybody), but OK. If they are doing it and I'm not, I'd feel left out
Re: Arch Linux 2024
Posted: Fri Mar 20, 2026 8:17 pm
by Grogan
Look what Arch is cramming down our throats now:
systemd System and Service Manager
CHANGES WITH 260:
Feature Removals and Incompatible Changes:
* Support for System V service scripts has been removed. Please make
sure to update your software *now* to include a native systemd unit
file instead of a legacy System V script.
The following components have been removed:
• systemd-rc-local-generator and rc-local.service,
• systemd-sysv-generator,
• systemd-sysv-install (hook for systemctl enable/disable/is-enabled).
Fuck you systemd, I was using rc.local
What a dictatorial piece of shit, to remove sysvinit compatibility.
Re: Arch Linux 2024
Posted: Sat Mar 21, 2026 7:39 am
by Zema Bus
That reminds me, I've been thinking about trying Artix
Re: Arch Linux 2024
Posted: Sat Mar 21, 2026 8:56 am
by Grogan
I have too, actually. I've been thinking of archiving that Crux setup for now and trying Artix on that partition. Get started with it, and see if I can do the same shit with it. I'd need to be able to grab all their PKGBUILDs with git etc. to be viable.
Re: Arch Linux 2024
Posted: Sat Mar 28, 2026 12:35 am
by Grogan
For now, I have taken over systemd on Arch, with custom package names so pacman won't bother me about it. I'm going to fixate that at version 260.1 unless I can't find ways to keep it compiling. I don't want anything new from systemd, I've heard quite enough. (netctl is just scripts, but it depends on systemd>=233... I have it in IgnorePkg because I don't ever want them changing that out from under foot. I'd have to see first)
Code: Select all
[grogan@nicetry ~]$ pacman -Qs systemd
local/lib32-systemd-cust 260.1-1
system and service manager (32-bit)
local/netctl 1.29-2
Profile based systemd network management
local/systemd-cust 260.1-1
system and service manager
local/systemd-libs-cust 260.1-1
systemd client libraries
local/systemd-sysvcompat-cust 260.1-1
sysvinit compat for systemd
I disabled a bunch of unwanted shit at compile time (from meson_options.txt). This is what I left enabled. I won't ever be installing that pukify thing, for unifying kernel and initramfs image (e.g. so it can be signed as a blob for secureboot). Crap like apparmor too, I don't want that and wouldn't have it as a build dep. No "remote" (journal access) or microhttpd. systemd boot can bugger off too... that'll also be a never, I use grub (which I've also taken over and fixated at a particular commit of 2.12). Fuck FIDO authentication too. I also enabled compat-sysv-interfaces=true (Arch has it false while still providing a sysvinit compat package with symlinks and stuff).
I disabled tpm and tpm2 support (I don't have it in kernel anyway)
Code: Select all
User defined options
apparmor : disabled
auto_features : enabled
b_pie : true
bootloader : disabled
bpf-framework : disabled
buildtype : plain
compat-sysv-interfaces : true
dbuspolicydir : /usr/share/dbus-1/system.d
default-dnssec : no
default-kill-user-processes : true
default-locale : C.UTF-8
dns-over-tls : openssl
dns-servers : 9.9.9.9#dns.quad9.net 2620:fe::9#dns.quad9.net 1.1.1.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 8.8.8.8#dns.google 2001:4860:4860::8888#dns.google
fallback-hostname : archlinux
ima : false
install-tests : false
libexecdir : lib
libfido2 : false
libidn2 : enabled
localegen-path : /usr/bin/locale-gen
lz4 : enabled
man : enabled
microhttpd : false
mode : release
nologin-path : /usr/bin/nologin
ntp-servers : 0.arch.pool.ntp.org 1.arch.pool.ntp.org 2.arch.pool.ntp.org 3.arch.pool.ntp.org
prefix : /usr
python.bytecompile : 1
remote : false
rpmmacrosdir : no
sbat-distro : arch
sbat-distro-pkgname : systemd
sbat-distro-summary : Arch Linux
sbat-distro-url : https://archlinux.org/packages/core/x86_64/systemd/
sbat-distro-version : 260.1
sbindir : bin
selinux : disabled
shared-lib-tag : 260.1-1
sshdprivsepdir : /usr/share/empty.sshd
sysupdated : enabled
tpm : false
tpm2 : disabled
ukify : disabled
vcs-tag : false
version-tag : 260.1-1-arch
vmlinux-h : provided
vmlinux-h-path : /usr/src/linux/vmlinux.h
wrap_mode : nodownload
xenctrl : disabled
I had to be super careful with my provides=, conflicts and replaces lines too. There are version specific dependencies for these packages. It took 3 tries to get all that right lol
I hadn't compiled this in years, and this build needs (actual) kernel headers now. I had to make a symlink, /usr/src/linux --> /lib/modules/6.19.10/build (which is itself a symlink to the kernel source tree used to build it). I added a command to my kernel install script to change (ln -sf) that symlink so I won't have to remember lol
The lib32-systemd package was more straightforward as it's just a minimal build to satisfy 32 bit dependencies, not system functionality. I only had to deal with provides, replaces and conflicts=
I'll be having another poke at this again to see what else I can get rid of from it by configuration options or barring that, scissors. I think I can work with this, rather than moving to Artix.
Re: Arch Linux 2024
Posted: Thu Apr 02, 2026 8:19 pm
by Grogan
I thought disabling BPF support at compile time would shut up the systemd warnings about it, but nooOOooo...
Code: Select all
[ 1.575460] systemd[1]: systemd-journald.service: unit configures an IP firewall, but the local system does not support BPF/cgroup firewalling.
[ 1.575460] systemd[1]: systemd-journald.service: (This warning is only shown for the first unit using IP firewalling.)
I'm determined to tame this and remove all systemd annoyances. It looks like I have 2 choices. Just go and hack the warning out of the systemd core library, or remove IpAddressDeny from all the static unit files. That would be the most "correct" thing to do, but then any time I install a new systemd build, it's going to overwrite the units in /usr/lib/systemd
Not all of these are even starting, but I'd still have to edit a lot of files to make these warnings go away. I guess I'll have to come up with a sed command to do it recursively in .conf and .service files (not all files, because of those binaries lol) because I'm going to be doing it again. When that obnoxious age verification change hits systemd, when 261 is released and Arch upgrades to it, I plan on switching to that "Liberated systemd" fork. Right now stable systemd 260.1 doesn't have that yet.
Code: Select all
[grogan@nicetry systemd]$ grep -n -i -r IPAddressDeny *
grep: libsystemd-core-260.1-1.so: binary file matches
grep: libsystemd-shared-260.1-1.so: binary file matches
portable/profile/strict/service.conf:28:IPAddressDeny=any
portable/profile/nonetwork/service.conf:30:IPAddressDeny=any
system/systemd-hostnamed.service:22:IPAddressDeny=any
system/systemd-userdbd.service:21:IPAddressDeny=any
system/systemd-journald@.service:22:IPAddressDeny=any
system/systemd-udevd.service:61:IPAddressDeny=any
system/systemd-timedated.service:22:IPAddressDeny=any
system/systemd-mountfsd.service:23:IPAddressDeny=any
system/systemd-oomd.service:30:IPAddressDeny=any
system/systemd-journald.service:38:IPAddressDeny=any
system/systemd-portabled.service:32:IPAddressDeny=any
system/systemd-coredump@.service:21:IPAddressDeny=any
system/systemd-nsresourced.service:23:IPAddressDeny=any
system/systemd-localed.service:22:IPAddressDeny=any
system/shadow.service:12:IPAddressDeny=any
system/systemd-logind.service:37:IPAddressDeny=any
system/systemd-machined.service:22:IPAddressDeny=any
user/portable/profile/strict/service.conf:26:IPAddressDeny=any
user/portable/profile/nonetwork/service.conf:28:IPAddressDeny=any
user/systemd-portabled.service:26:IPAddressDeny=any
I'm not that good with sed, so I had to break it up into 2 commands. Sed isn't recursive, so I had to exec it with the find utility. I'll just paste those commands when my unit files get overwritten again.
Code: Select all
find . -name '*.conf' -exec sed -i '/IPAddressDeny/d' '{}' \;
find . -name '*.service' -exec sed -i '/IPAddressDeny/d' '{}' \;
That simply deletes the lines when the pattern is matched (it worked as I intended).
I don't fucking like IP firewalling on my workstations, especially ones I don't understand like eBPF or NFT. I do have BPF support in my kernel in case I ever do want to run an eBPF program, but what I don't have is cgroup controllers (including CONFIG_CGROUP_BPF). I just fake cgroups because systemd will abort without it (I enable cgroup support itself so it can mount /sys/fs/cgroup). The only thing that's good for is throttling my i/o, which I never want. I'm mostly a single task guy... if I'm doing a build, I want THAT to get full attention and anything else can lag (however, the kernel is good enough with preemption that I can surf or watch videos while compiling with all cores blazing, without really noticing, for example). If I'm playing a game, I want THAT to get full attention of the hardware etc.
P.S. Actually, systemd didn't like that at all, it refuses to start targets and after gyrating for 90s, drops down to single user mode login. It won't even mount my drives (just the root fs. The files I checked looked OK (simply that IpAddressDeny directive line removed), I wonder if that's a mandatory directive or something. What I have to do now is extract my systemd package and restore /usr/lib/systemd (because I accidentally wrote to the backup I made after the first attempt) and manually edit some files and see what's going on. Find out what exactly broke it. That's a directive that should be removable.
Actually what I did was worse than that, because there are other packages (like dbus services) that no longer had their units in /usr/lib/systemd. So simply restoring it from systemd packages was not enough, it couldn't start dbus and I had no networking. So what I had to do was first restore the bad /usr/lib/systemd (that still had all the other units intact) and then cp -a the good /usr/lib/systemd extracted from my systemd packages over top.
I really hate systemd.
-----------------------------------------------
OK... analysis of what went wrong.
It wasn't removing the directive from the files that caused it. It looks like what I did with find and sed dereferenced symbolic links, which caused good old systemd to... ignore some target.wants dependencies. What a fucking piece of complex, fragile crap that it would refuse to execute target.wants if they aren't symlinks and essentially fail to use the mount command on the fstab entries that any simple shell script would have done. I still had to correct one manually, for halt.target.wants, kexec.target.wants and reboot.target.wants for mkinitcpio-generate-shutdown-ramfs.service. Fucking stupid shit that I don't use anyway (initramfs, kexec)
The reason is, that I told find to operate on all file types. I should have specified "-name -type f" to operate on regular files only. If I'd have done this, I wouldn't have broken it:
Code: Select all
find . -name '*.conf' -type f -exec sed -i '/IPAddressDeny/d' '{}' \;
find . -name '*.service' -type f -exec sed -i '/IPAddressDeny/d' '{}' \;
Now, the only services I actually had to remove IPAddressDeny from to shut up the warnings were systemd-journald.service and systemd-userdbd.service. All that breakage I caused was for nothing, but now I have it how I want it to be
journald pisses me off too, because I don't even use the journal (storage=volatile still, because if set to none, it doesn't forward, contrary to documentation) but it's still a necessary service to forward events to syslog
Re: Arch Linux 2024
Posted: Tue Apr 07, 2026 11:19 pm
by Grogan
Arch fucked me again with gdk-pixbuf2 (for the last time!). They don't care whose shit they break. (at least claws-mail will be broken in the distro right now too, not just my build)
Even built with all image loaders enabled (glycin disabled) gdk-pixbuf2 2.44.6 still broke things because they disabled "legacy" XPM support in gdk-pixbuf2, because glycin supports that now. Adding -D legacy_xpm=enabled also doesn't fix it, because the image loader is called legacy-xpm (instead of xpm) which would have to be known. I was getting errors that it's not valid when gtk applications were trying to load xpm icons.
So there's another package I can't trust Arch with at all, not even for versioning. Permanently downgraded to 2.44.4 and dependent packages I upgraded today rebuilt against it.
Code: Select all
[grogan@nicetry ~]$ pacman -Qs gdk-pixbuf2
local/gdk-pixbuf2-cust 2.44.4-1
An image loading library
local/lib32-gdk-pixbuf2-cust 2.44.4-1
An image loading library (32-bit)
I'm getting really sick of this distro.