I tried to install archlinux32 using the archinstall installer, which is shipped with the installation medium.
Installation is working fine until pacstrap, where it will crash because all mirrors will return 404. I checked
my connection and it is working and dns also works. When I viewed the /etc/pacman.d/mirrorlist file, I saw that the script
wrote the default archlinux mirrors for the region specified in the installer to the file and the don’t contain the 32bit packages.

This seems to be a problem of either update-archlinux32-package in devops or of the (commented) code path in the PKGBUILD which gets executed by this script.

+ exec setarch i486 systemd-nspawn -q -D /var/lib/archbuild/staging-i486/root -E PATH=/usr/local/sbin:/usr/local/bin:/usr/bin –register=no –keep-unit –as-pid2 –bind=/var/cache/archbuild32 pacman -Syuu –noconfirm
error: failed to initialize alpm library

https://www.tomshardware.com/news/linux-removes-486-cpu-support

486 will be removed from the kernel and especially from 6.1 onwards rust will be integrated with the kernel…

———————————– output ———————————– stderr:
Traceback (most recent call last):

File "/build/xorgproto/src/xorgproto-2021.3/scripts/keysym-generator.py", line 18, in <module>
  import libevdev

ModuleNotFoundError: No module named ‘libevdev’

root cause is python-libevdev not building:

Theme error:
sphinx_rtd_theme is no longer a hard dependency since version 1.4.0. Please install it manually.(pip install sphinx_rtd_theme)

another victim of documentation generation..

Feb 12 12:00:29 arch32-testing-pentium4 kernel: audit: type=1130 audit(1613127629.283:106): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@0-9938-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 12 12:00:31 arch32-testing-pentium4 systemd-coredump[9939]: [🡕] Process 9886 (xfce4-power-man) of user 1000 dumped core.
                                                                
                                                                Stack trace of thread 9886:
                                                                #0  0x00000000b6fb37b4 g_log_structured_array (libglib-2.0.so.0 + 0x557b4)
                                                                #1  0x00000000b6fb3cdc g_log_default_handler (libglib-2.0.so.0 + 0x55cdc)
                                                                #2  0x00000000b6fb5224 g_logv (libglib-2.0.so.0 + 0x57224)
                                                                #3  0x00000000b6fb5485 g_log (libglib-2.0.so.0 + 0x57485)
                                                                #4  0x000000000041a4cf n/a (xfce4-power-manager + 0x64cf)
                                                                #5  0x00000000b6b5498d __libc_start_main (libc.so.6 + 0x1e98d)
                                                                #6  0x000000000041aa75 n/a (xfce4-power-manager + 0x6a75)
                                                                
                                                                Stack trace of thread 9901:
                                                                #0  0x00000000b7f12549 __kernel_vsyscall (linux-gate.so.1 + 0x549)
                                                                #1  0x00000000b6c22117 __poll (libc.so.6 + 0xec117)
                                                                #2  0x00000000b7000125 n/a (libglib-2.0.so.0 + 0xa2125)
                                                                #3  0x00000000b6faba46 g_main_context_iteration (libglib-2.0.so.0 + 0x4da46)
                                                                #4  0x00000000b6fabaa1 n/a (libglib-2.0.so.0 + 0x4daa1)
                                                                #5  0x00000000b6fda93e n/a (libglib-2.0.so.0 + 0x7c93e)
                                                                #6  0x00000000b6cfe39f start_thread (libpthread.so.0 + 0x839f)
                                                                #7  0x00000000b6c2db6a __clone (libc.so.6 + 0xf7b6a)
Feb 12 12:00:31 arch32-testing-pentium4 kernel: audit: type=1131 audit(1613127631.393:107): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@0-9938-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

no task description

Installing wireguard-dkms fails with:

(2/2) Install DKMS modules
==> dkms install wireguard/0.0.20200318 -k 5.5.8-arch1-1.0
Error! Bad return status for module build on kernel: 5.5.8-arch1-1.0 (i686)
Consult /var/lib/dkms/wireguard/0.0.20200318/build/make.log for more information.

The file /var/lib/dkms/wireguard/0.0.20200318/build/make.log contains the following messages:

DKMS make.log for wireguard-0.0.20200318 for kernel 5.5.8-arch1-1.0 (i686)
Fri 03 Apr 2020 10:11:21 PM CEST
make: Entering directory '/usr/lib/modules/5.5.8-arch1-1.0/build'
  AR      /var/lib/dkms/wireguard/0.0.20200318/build/built-in.a
  CC [M]  /var/lib/dkms/wireguard/0.0.20200318/build/main.o
cc1: error: incompatible gcc/plugin versions
cc1: error: fail to initialize plugin ./scripts/gcc-plugins/structleak_plugin.so
make[1]: *** [scripts/Makefile.build:266: /var/lib/dkms/wireguard/0.0.20200318/build/main.o] Error 1
make: *** [Makefile:1693: /var/lib/dkms/wireguard/0.0.20200318/build] Error 2
make: Leaving directory '/usr/lib/modules/5.5.8-arch1-1.0/build'

This blocks tons of packages..

:: removing user-manager breaks dependency ‘user-manager’ required by plasma-meta

no task description

no task description

no task description

no task description

no task description

no task description

no task description

no task description

no task description

no task description

no task description

no task description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 10.01.2019
Last edited by Andreas Baumann - 10.01.2019
 FS#59  - unison segfault

Calling unison, a file synchronizer written in Ocaml. Segfaults.
Most likely a string optimization inside Ocaml itself or a non-matching
library somewhere (recompile ocaml?)

(gdb) bt
#0 0x006782df in caml_string_equal ()
#1 0x005ce0d8 in camlUpdatearchiveMode_802888 ()
#2 0x005ce6e5 in camlUpdatesetArchiveData_802926 ()
#3 0x005da668 in camlGlobalsfun_802549 ()
#4 0x005fed99 in camlLwt_utilmap_1080 ()
#5 0x005fedac in camlLwt_utilmap_1080 ()
#6 0x005da5b9 in camlGlobalsallRootsMap_301891 ()
#7 0x005cea7f in camlUpdateloadArchives_802958 ()
#8 0x005d4637 in camlUpdatefindUpdatesOnPaths_2603478 ()
#9 0x005b36f5 in camlUitextsynchronizeOnce_1102725 ()
#10 0x005b4041 in camlUitextloop_1203129 ()
#11 0x005b41d6 in camlUitextsynchronizeUntilDone_1203134 ()
#12 0x005b442e in camlUitextstart_1303143 ()
#13 0x005acc54 in camlMainBody_401249 ()
#14 0x005ac19d in camlLinktextentry ()
#15 0x005a8220 in caml_program ()
#16 0x0068b64d in caml_start_program ()
#17 0x0068b9f1 in caml_startup_common ()
#18 0x0068ba6a in caml_startup ()
#19 0x005a7c25 in main ()

Closed by Andreas Baumann
10.01.2019 14:15
Reason for closing: Not a bug
Additional comments about closing:

Cannot reprodduce but on a single machine. Might as well be something completly different..

  Comments (6)
  Related Tasks (0/0)

Admin
Erich Eckner commented on 10.01.2019 08:31

easy trials first: let’s recompile ocaml
Admin
Andreas Baumann commented on 10.01.2019 09:30

Some things seem to be wrong here:

Warning 3: deprecated: Stdlib.String.capitalize
Use String.capitalize_ascii instead.
File “/build/unison/src/unison-2.51.2/build/src/uigtk2.ml”, line 1:
Error: /usr/lib/ocaml/lablgtk2/pango.cmi
is not a compiled interface for this version of OCaml.
It seems to be for an older version of OCaml.
make[1]: * [Makefile.OCaml:423: uigtk2.cmx] Error 2
make[1]: Leaving directory ‘/build/unison/src/unison-2.51.2/build/src’ make: * [Makefile:14: src] Error 2

Admin
Andreas Baumann commented on 10.01.2019 09:56

rebuilding lablgtk2 now.
Admin
Andreas Baumann commented on 10.01.2019 11:29

rebuilding unison didn’t help.
Admin
Andreas Baumann commented on 10.01.2019 11:35

Ok, let’s rebuild ocaml itself.
Admin
Andreas Baumann commented on 10.01.2019 12:51

works on two vms (libvirt and Virtualbox), but not on my real eeepc.

Google Cache

# pacman -Sy ffmpeg
:: Synchronizing package databases… core is up to date
extra is up to date
community is up to date
resolving dependencies… warning: cannot resolve “libx264.so=163-32”, a dependency of “ffmpeg” :: The following package cannot be upgraded due to unresolvable dependencies:

    ffmpeg

Attached to Project: Archlinux32
Opened by Paul Gover - 07.09.2018
Last edited by Erich Eckner - 24.09.2018
 FS#51  - ufw needs rebuild for python 3.7

Been using ufw for some time. Today, I wanted to turn logging off.
Command “ufw logging off” should just work. Instead it gives:

ufw logging off
Traceback (most recent call last):

File “/usr/bin/ufw”, line 26, in

import ufw.frontend

ModuleNotFoundError: No module named ‘ufw’

which I trace to the fact ufw is installed in
/usr/lib/python3.6/site-packages/ufw
and there’s no longer a python 3.6 executable; it’s all 3.7 now.
Closed by Erich Eckner
24.09.2018 07:32
Reason for closing: Fixed

  Comments (3)
  Related Tasks (0/0)

Admin
Erich Eckner commented on 07.09.2018 09:46

ufw-0.35-5.0 from [community-testing] should work - I’m moving it to [community] just now
Paul Gover commented on 07.09.2018 09:48

Sorry to add to your workload. I assumed a UFW problem was local to me. Now I’ve read the furore about python 3.7 etc. on the forums, my apologies. I’ll try the community-testing version. Thanks for the speedy response.
Paul Gover commented on 11.09.2018 15:21

To confirm, UFW is working fine for me now. Thanks.

Google Cache

Supertux needs to be rebuilt as it currently depends on the wrong version of libboostfilesystem.

https://www.archlinux32.org/packages/i686/community/supertux/ not satisfiable dependency: “libboost_filesystem.so.1.72.0” (link)
not satisfiable dependency: “libboost_locale.so.1.72.0” (link)

This affects all architectures (i686 and pentium4)

it is not possible to enable staging

$ sudo pacman -Syuu
:: Synchronizing package databases...
 core-staging is up to date
 core is up to date
 extra-staging                      2.5 MiB  2.22 MiB/s 00:01 [##################################] 100%
 extra is up to date
 community-staging is up to date
 community is up to date
:: Starting full system upgrade...
resolving dependencies...
:: There are 2 providers available for dbus-units:
:: Repository core-staging
   1) dbus-broker-units  2) dbus-daemon-units

Enter a number (default=1): 
looking for conflicting packages...
:: cryptsetup and mkinitcpio are in conflict. Remove mkinitcpio? [y/N] y
error: failed to prepare transaction (could not satisfy dependencies)
:: unable to satisfy dependency 'initramfs' required by linux

SPAM

SPAM

SPAM

SPAM

SPAM

no task description

no task description

no task description

Attached to Project: Archlinux32
Opened by Luke Shumaker - 21.09.2018
 FS#52  - Some packages are built by “Unknown Packager”

Some packages have

packager = Unknown Packager

, which is caused by

makepkg.conf:PACKAGER

not being set.

I analyzed every .pkg.tar.xz file in the Arch 32 repos (all architectures). The earliest Unknown Packager package was built on June 9, 2017, and they’ve been intermittent since then. Here’s a listing of how many times each packager appears:

    2  Dave Reisner 
    2  Fabio Castelli (Muflone) 
    2  Giancarlo Razzolini 
    2  Jelle van der Waa 
    2  Laurent Carlier 
    2  S?bastien Luttringer 
    2  schuay 
    3  Florian Pritz 
    3  Johannes L?thberg 
    4  Alexander R?dseth 
    4  Andreas Radke 
    4  Eli Schwartz 
    4  Tobias Powalowski 
    5  Gaetan Bisson 
    5  Jonathan Steel 
    6  Bart?omiej Piotrowski 
    6  Erich Eckner 
    7  Kyle Keen 
    8  Evangelos Foutras 
    8  Maxime Gauduin 
    9  Jaroslav Lichtblau 
    9  Lukas Fleischer 
   18  BlackEagle 
   21  Sergej Pupykin 
   22  Guillaume ALAUX 
   29  Sven-Hendrik Haase 
   32  Levente Polyak 
   35  Jan Alexander Steffens (heftig) 
   39  Felix Yan 
   43  Jan de Groot 
   44  Andreas Baumann 
   75  Ball? Gy?rgy 
   81  Antonio Rojas 
 6592  Unknown Packager
20577  Erich Eckner 
------------------------------------------------------------------
27707  total

This causes a problem for us in Parabola, because we just started applying the usual upload checks from

db-update

to packages that we import.

  Comments (3)
  Related Tasks (0/0)

bill auger commented on 24.09.2018 05:20

i was trying to make sense of this today and my results were pretty strange

i wrote a script to extract ‘Unknown Packager’ from the db caches in /var/lib/pacman/sync/ and i got very different counts then what luke reported - i ran the same script on both parabola i686 and again on arch32 - it did show that all of the packages by ‘Unknown Packager’ are in [extra], [community], and [core]

<pre>
$ wc -l ./unknown-packagers-parabola
1800 ./unknown-packagers-parabola

$ wc -l ./unknown-packagers-arch32
2250 ./unknown-packagers-arch32
</pre>

one thing i noted was that one of the packages (4ti2) that arch32 has by ‘Unknown Packager’ for v1.6.7 shows as v1.6.9 packaged by ‘Erich Eckner’ on parabola and the parabola package has a higher version number and later build date - maybe my mirrorlist is wonky on arch32 but it is the default one that was installed

<pre>
arch32:
package: 4ti2-1.6.7-1
build date: 1497644502
packager: Unknown Packager

parabola:
package: 4ti2-1.6.9-1.0
build date: 1536224793
packager: Erich Eckner
</pre>

the script i used is attached to the corresponding parabola bug report
https://labs.parabola.nu/issues/1652 https://labs.parabola.nu/attachments/444/find-unknown-packagers Admin
Erich Eckner commented on 24.09.2018 08:47

The buildmaster now rejects package built by “Unknown Packager” - what remains is to rebuild all packages, that are already committed.
Admin
Erich Eckner commented on 24.09.2018 08:54

btw: operating on the package database is much faster than extracting every single package:

find . -name ‘*.db.tar.gz’ | \

while read -r repo; do
  tar -Oxzf "${repo}" --wildcards '*/desc' | \
    sed -n '/^%FILENAME%$\|^%PACKAGER%$/{N;s/\n/ /;p;d;}'
done | \
sed '/^%FILENAME% /{N;/\n%PACKAGER% Unknown Packager$/!d;s/\n.*//;s/^%FILENAME% //;}'

Google Cache

When trying to install the package, packman complies about the the key to be of unknown trust. Cheking the keyring the associated key appers to be expired.

ISO segfaults when pacstrapping.

Several (if not all) build slaves show key verification errors.

I don’t think, it’s the keys, but gnupg slowly failing us on 32-bit.

Workaround as always: SigLevel=Never

Trick question (and possibly bonus points): what to do, if gnupg cannot be fixed..

breaks in more SIMD optimizations.

   Compiling same-file v1.0.6
     |                        ^^^
     = note: `-D non-fmt-panic` implied by `-D warnings`
     = note: this is no longer accepted in Rust 2021
help: add a "{}" format string to Display the message
     |
1493 |                 panic!("{}", out);
     |                        ^^^^^
help: or use std::panic::panic_any instead
     |
1493 |                 std::panic::panic_any(out);
     |                 ^^^^^^^^^^^^^^^^^^^^^^

Brilliantly fast changing language..

either building 1.49 via 1.48, via 1.47 or we have to bootstrap from a binary version again.