You are not logged in.
Several critical GNOME packages based on 43.1 were pushed into stable recently. This seriously broke GNOME desktop usability on ArchLinux32. The following GNOME core critical packages seemed to be out of coordination to ensure smooth rolling updates on GNOME desktop.
gnome-shell
gnome-control-center
gnome-settings-daemon
mutter
Any plan to address such incoordination?
Offline
Well, all of the gnome- packages are listed as broken in the build reports. That might be an indication of some problem that needs to be fixed.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Package "js102" isn't available on ArchLinux32. This is required for GNOME 43.
Package "js91" isn't available on ArchLinux32. This is required for GNOME 42.
It is not surprising that those recent "js > 78" could have been broken for 32-bit architecture. If this is the case, then ArchLinux32 should have retained GNOME 41. I understand that all these are being managed with automation, but specifically for 32-bit distros it would be handy to be able to block broken 32-bit packages and retain the last known good version.
There are other lingering issues such as libgweather and libsoup deprecation on GNOME > 42 for libgweather-4 and libsoup3. GNOME gnome-shell/mutter does not seem to be able to handle mixing up those libraries with plugins or loadable modules. This is the cause of "Oops" during display manager startup.
Offline
The answer is complicated.
Breakages occur, because at a certain point low-level dependencies have updated and something breaks building up to Gnome.
Keeping old versions would require to fork a lot of packages like js91, js102. Now even if that is done, there is no guarantee that
jsXX can be built on 32-bit. jsxXX versions are forked from firefox and use specific rust versions to build (js91 needs rust148).
This needs bootstrapping of specific rust versions, the effort is just too high. There are other Javascript interpreters out there
which are much easier to build (see for instance polkit -> duktape-polkit, there is simply no reason to build a browser with
it's convoluted build system just to get a Javascript interpreter just to edit some config file).
Currently rust is broken and some parts of Gnome start to indirecly depend on it. Rust is currently in limbo as I cannot rebuild
it on a 32-bit chroot (https://bugs.archlinux32.org/index.php? … ask_id=316). The only way out is most likely cross-
compliation of packages like rust, but this needs some non-trivial changes to the build system.
Gnome got overly complex IMHO and the dependency tree is just madness. KDE, XFCE, LXQt and all the others are not
close as complex..
Nobody of the Arch32 team uses any modern window manager on old machines (as they are really only usable maybe on
a virtual machine), so nobody is testing it. :-)
Currently the buildmaster is slower than ever, every operation like forcing a package rebuild or pushing it to stable takes
literaly hours. This needs some non-trivial tuning or even rewrite of some mysql-queries.
On a more philosophical note: Arch32 is supposed to be bleeding edge as upstream (that's sort of the mission of the project).
If this means that more and more software is no longer supporting 32-bit, the consequence is to drop this packages (or
leave them in the repos till they no longer work).
Snap, appimages and alike get more and more popular, Linux distros will and are using that to mitigate shared library breakages,
well they will even link statically inside those. Software is shared in source by copying the code (like chromium) or is shared
in weird remote systems like cargo. This all leads to the point where shared libraries, stable ABI/APIs will be a thing of the
past. We will have to buy 20TB hard disks to install a base version of Linux.. (which is good for a certain industry) because
even 'ls' and 'ps' need their own container.. :-)
Offline
Hi Thanks for the answer. Sorry about the late response.
You're right, my sole purpose for ArchLinux32 is for virtual machine, though I had it on my EeePC 701. Nowadays virtual machines on modern laptops are faster and offer much better usability experience than having the little EeePC 701.
And, I also agree with you that GNOME 4 is overly complex and the effort is huge. I was hoping 32-bit distros such as ArchLinux32 would just let go everything on GNOME 4 and locked down GNOME desktop environment with the last GNOME 3.38.x branch. At least, it still offers a usable GNOME desktop environment instead of letting the GNOME desktop option rotting by not keeping up with upstream.
I guess that would also imply that the distro may not be keeping with mesa upstream, too, as mesa 22.3.x now requires rust to build. This is quite a let-down unfortunately because mesa 22.3.x enables support for VENUS (Vulkan for virtio-gpu) and VA-API video acceleration for virtual machines.
Offline
It's quite tricky to just freeze the latest Gnome something and dependencies, it would require copying all packages to the AUR (as it is done for instance for older php or python version). I fear you end up basically in fork of most packages.
I personally think that a stable release distro is better suited to keep a last working version alive.
Rust is available for i686 and pentium4 and mesa usually should build (just not currently, as rust is not rebuilding properly). For i486
the situation though looks worse, but there is mesa-amber, which should cover old GPUs.
Offline
Well, there aren't many 32-bit distros left and probably none based on PKGBUILD pacman packaging. I guess if I had wished for stable distro, then I would have settled for Debian.
I guess the existing automation relies on build break to stop the packages from upstream update. Perhaps some efforts are needed there to mark the packages as "never-update" or at least a 2nd-level dependency chain for packages such as GNOME to remain in testing/staging until they are ready to be pushed into stable. This will keep the distro usable at least, unlike having the lone "mutter 43.1" in stable with a broken "gnome-shell" stuck in build break. Yes, all this requires additional efforts and this is the cost of keeping 32-bit distro running. I currently locked down my GNOME desktop using pacman.conf "IgnorePkg" for
gnome-desktop
gnome-desktop-common
gnome-session
mutter
libnautilus-extension
nautilus
And rebuild the latest GNOME 41.x branch for
gnome-control-center 41.7
gnome-settings-daemon 41.0
gnome-shell 41.9
mutter 41.9
This keeps a simple, GNOME desktop-lite alive for ArchLinux32 VM.
For virtual machines, mesa-amber isn't the right solution at all. The upstream VIRTIO-GPU/virglrenderer is bleeding-edge development, especially on bleeding-edge Linux hosts such as ArchLinux x86.64.
Offline
Yes, mesa-amber is more for old machines with old GPUs. What always puzzles me, why people think they should install 32-bit VMs. :-)
The only use cases I see (and that's the ones I'm using it for) is to test Arch32 and to develop and maintain 32-bit software (I have
a 32-bit Arch32 LXC and a libvirt/qemy installation on my 64-bit laptop for easier development). I'm curious, what 32-bit VMs are used for, otherwise.. :-)
Another argument might be that 32-bit VMS are more efficient (from a resource point of view, mainly memory), but for some reason almost
no distro builds a X32 version (64-bit kernel and registers but 32-bit address space per user process). Debian and T2SDE are the only binary distros
I know with a X32 version, Gentoo has an X32 experimental branch too..
The dependencies are managed in the buildmaster database and usually nothing gets simply pushed to stable, which has non-rebuildable dependencies.
But the problem is, that you end up in other packages breaking, because they need a newer version of something (the famous icu, boost, etc. problems
we sometimes have). This we try to fix with boost180-libs and alike, so people can keep old versions alive while newer software uses boost-libs (1.81).
Currently my main concern is, that some 32-bit software gets into the embedded build land (it requires cross-compilation): rust, firefox, virtualbox are some
of the prominent ones. There is simply no infrastructure available for that in the build system. Also I'm hesitating to go this way, as it leaves the possibility
of Arch32 being self-hosted (which is an important property IMHO). The other option I'm sometimes considering is to go full-binary-only for things like rust,
but this has other implications, as i486 or other stranger architectures are left behind then.
Offline
It's a rare use case ;-) 32-bit VM is more efficient at running 32-bit software/games without the multi-libs cluttering. It is a prime usage for both legacy Linux/Windows 32-bit software, especially games, with Windows Games on Wine. Wine will eventually support 32-bit software through 64-bit thunking without the need of multi-libs and by then 32-bit Linux on VM would be pointless.
I put some efforts trying to understand how to improve existing situation. I will leave it to you if you would adopt it.
1. Remove the annoying mutter 43.x from stable repo. It is preventing simple "# pacman -Syu" just to keep up with the updates.
2. Since we can't have JS91, gnome-shell should be rebuilt with "-D soup2=false" and libgweather-4. This makes it go along well with the rest of GNOME stuffs.
3. Update gnome-online-accounts to 3.46 from upstream to get rid of libsoup2 and rest (legacy).
4. Rebuild gnome-settings-daemon 41.x with libgweather-4 and geocode-glib-2.
5. Rebuild gnome-control-center 41.x to remove libsoup2. Patch available at a9c398e5d9d45fb4638b38d6bb3f677a2b12b249
With all the steps taken, GNOME desktop is essentially locked at GNOME 41 without the need to use "IgnorePkg =" in pacman.conf. Slow updates is OK and better than broken stable repo that preventing any updates without messing with default pacman.conf. I don't know if GNOME Mutter is usable as standalone window manager/compositor without GNOME shell. As I said, it shouldn't have been pushed into stable repo without the matching GNOME shell.
Offline