Bugs in Archlinux32 packages, specific to 32-bit issues.

Bugs  FS#2  to  FS#92  have been recovered and may be incomplete, the
recovered Google/Bing cache data can be found here.

IDCategoryTask Type  ascPrioritySeveritySummaryStatusProgress
 178 DevopsBug ReportVery LowLow New installer overwrites pacman mirrors Closed
100%
Task Description

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.

 135 PackagesBug ReportMediumLow namcap fails on libxkbcommon Closed
100%
Task Description
Checking PKGBUILD
Traceback (most recent call last):
  File "/usr/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/usr/lib/python3.9/site-packages/namcap.py", line 247, in <module>
    process_pkgbuild(package, active_modules)
  File "/usr/lib/python3.9/site-packages/namcap.py", line 153, in process_pkgbuild
    name = "PKGBUILD (" + pkginfo["name"] + ")"
  File "/usr/lib/python3.9/site-packages/Namcap/package.py", line 128, in __getitem__
    return self._data[self.canonical_varname(key)]
KeyError: 'name'
==> Running checkpkg
error: no targets specified (use -h for help)
==> WARNING: Skipped checkpkg due to missing repo packages
 124 PackagesBug ReportMediumLow mutter and gnome-shell are in confllict Closed
100%
Task Description

:: installing mutter (3.38.1-1.1) breaks dependency ‘libmutter-6.so=0-32’ required by gnome-shell

314PackagesBug ReportVery LowLowMumble requires a outdated protobuf Unconfirmed
0%
Task Description

libprotobuf=28 is a mumble (package) dependency, but protobuf package has libprotobuf=32.

I needed to downgrade to protobuf-3.17.3-1.3-pentium4.pkg.tar.zst (from the archive) to install mumble.

 121 PackagesBug ReportVery LowHigh Multiple packages need rebuild after libicu upgrade Closed
100%
Task Description

Over in  FS#119 , @abaumann mentioned that the libicu upgrade from 67 to 68 was part of what broke gdb. I missed the libicu upgrade when looking at gdb, but now that that one is resolved, I noticed a number of other packages that still link against the old and now nonexistant /usr/lib/libicu*.so.67 files. On my particular system, the following packages are installed, link to icu 67, and need rebuilt as well:

* harfbuzz-icu (2.7.0-1.0)
* mongo-c-driver (1.17.3-1.0)
* postfix (3.5.6-2.0)
* postgresql (12.4-1.0)
* postgresql-old-upgrade (12.5-1.0)
* samba (4.12.3-1.2)
* smbclient (4.12.3-1.2)
* syslog-ng (3.28.1-3.0)
* texlive-bin (2020.54586-4.0)
* xfsprogs (5.8.0-1.0)

… but I’m sure you have a way of determining all the affected packages?

As a workaround, in case others have the same problem, I manually extracted the old versioned .so files from the previous package to get things working again:

```
tar -C / -xf /var/cache/pacman/pkg/icu-67.1-1.0-i686.pkg.tar.zst –wildcards ‘usr/lib/lib*.so.*’ ```

- I’ll just have to remember to clean them up again later.

 190 Packages: StableBug ReportVery LowCritical mpv-1:0.33.1-2.0-pentium4 aborts immediately Closed
100%
Task Description

Here’s 1:0.33.1-1.0-pentium4:

$ pacman -Qs mpv
local/mpv 1:0.33.1-1.0
    a free, open source, and cross-platform media player

$ mpv --version
mpv 0.33.1-dirty Copyright © 2000-2020 mpv/MPlayer/mplayer2 projects
 built on UNKNOWN
FFmpeg library versions:
   libavutil       56.51.100
   libavcodec      58.91.100
   libavformat     58.45.100
   libswscale      5.7.100
   libavfilter     7.85.100
   libswresample   3.7.100
FFmpeg version: n4.3.2

Here’s 1:0.33.1-2.0-pentium4:

$ pacman -Qs mpv
local/mpv 1:0.33.1-2.0
    a free, open source, and cross-platform media player

$ mpv --msg-level=all=trace --version
libavutil: 56.70.100 -> 56.51.100
Aborted (core dumped)

Looks to me like it might be a library version thing (I’m up-to-date according to

pacman -Syu

), but I’ve only been running Arch32 for 24 hours so I’m not sure where further to dig.

 191 PackagesBug ReportVery LowCritical mpv links against libsrt.so.1 which does not exist Closed
100%
Task Description
$ pacman -Qs mpv
local/mpv 1:0.33.1-1.0
    a free, open source, and cross-platform media player
$ pacman -Qs srt
local/srt 1.4.3-1.0
    Secure Reliable Transport library
$ pacman -Fl srt | grep libsrt
srt usr/lib/libsrt.so
srt usr/lib/libsrt.so.1.4
srt usr/lib/libsrt.so.1.4.3
$ mpv
mpv: error while loading shared libraries: libsrt.so.1: cannot open shared object file: No such file or directory
$ ldd /usr/bin/mpv | grep srt
	libsrt.so.1 => not found
$ sudo ln -s /usr/lib/libsrt.so.1.4.3 /usr/lib/libsrt.so.1
$ mpv --version
mpv 0.33.1-dirty Copyright © 2000-2020 mpv/MPlayer/mplayer2 projects
 built on UNKNOWN
FFmpeg library versions:
   libavutil       56.51.100
   libavcodec      58.91.100
   libavformat     58.45.100
   libswscale      5.7.100
   libavfilter     7.85.100
   libswresample   3.7.100
FFmpeg version: n4.3.2

$ ldd /usr/bin/mpv | grep srt
	libsrt.so.1 => /usr/lib/libsrt.so.1 (0xb2a54000)

Running ldconfig does not create the missing symlink.

 241 PackagesBug ReportVery LowLow mpd probably needs to be rebuilt against pipewire Closed
100%
Task Description

Hi,

If I run mpd, it fails to run due to a missing PW_LOG_TOPIC_DEFAULT symbol:
> $ mpd
> mpd: symbol lookup error: mpd: undefined symbol: PW_LOG_TOPIC_DEFAULT

While I run Parabola, both mpd and pipewire comes from the i686 repository of Arch Linux 32:
> extra/mpd 0.23.5-1.2 [installed]
> Flexible, powerful, server-side application for playing music
> extra/pipewire 1:0.3.36-1.0 [installed]
> Low-latency audio/video router and processor

If I look on a x86_64 Parabola installation instead, PW_LOG_TOPIC_DEFAULT can be found in libpipewire:
> $ readelf -s /usr/lib/libpipewire-0.3.so.0 | grep PW_LOG_
> 383: 00000000000d7128 8 OBJECT GLOBAL DEFAULT 21 > PW_LOG_TOPIC_DEFAULT

But that command returns nothing on Parabola i686.

Denis.

100Packages: StableBug ReportVery LowLowmldonkey crashesUnconfirmed
0%
Task Description

All versions of mldonkey crash in arch32 updated. (segmentation fault and core dumped)

 356 PackagesBug ReportMediumLow mkinitcpio core dump Closed
100%
Task Description
double free or corruption (out)
/usr/bin/mkinitcpio: line 557:  2387 Aborted                 (core dumped) MKINITCPIO_PROCESS_PRESET="$preset_name" "$0" "${preset_cmd[@]}"
error: command failed to execute correctly

Maybe also the age of the machine, the CMOS, the RAM, the moon, the universe could be
at fault here..

 97 Packages: StableBug ReportVery LowLow mesa-vdpau /usr/lib/dri/r300_dri.so links to wrong libL ...Closed
100%
Task Description
grep LLVM /var/log/Xorg.0.log
[    29.423] (EE) AIGLX error: dlopen of /usr/lib/dri/r300_dri.so failed (libLLVM-8.so: cannot open shared object file: No such file or directory)
[    29.424] (EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed (libLLVM-8.so: cannot open shared object file: No such file or directory)
ldd /usr/lib/dri/r300_dri.so 
        linux-gate.so.1 (0xb7f26000)
        libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb6836000)
        libLLVM-8.so => not found
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb680a000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0xb6804000)
        libsensors.so.5 => /usr/lib/libsensors.so.5 (0xb67f3000)
        libdrm_radeon.so.1 => /usr/lib/libdrm_radeon.so.1 (0xb67e4000)
        libelf.so.1 => /usr/lib/libelf.so.1 (0xb67c6000)
        libdrm_amdgpu.so.1 => /usr/lib/libdrm_amdgpu.so.1 (0xb67b9000)
        libdrm_nouveau.so.2 => /usr/lib/libdrm_nouveau.so.2 (0xb67ae000)
        libglapi.so.0 => /usr/lib/libglapi.so.0 (0xb678d000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb6773000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6595000)
        libm.so.6 => /usr/lib/libm.so.6 (0xb64c3000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb64a6000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0xb6483000)
        libc.so.6 => /usr/lib/libc.so.6 (0xb62d3000)
        /usr/lib/ld-linux.so.2 (0xb7f27000)
ls /usr/lib/libLLVM*
/usr/lib/libLLVM-9.0.0.so  /usr/lib/libLLVM-9.so  /usr/lib/libLLVM.so
347PackagesBug ReportVery LowLowMeld will not start - error message -> Meld requires Gt...Unconfirmed
0%
Task Description

[keith@Arch32 ~]$ meld
Meld requires Gtk+ 3.20 or higher.
[keith@Arch32 ~]$ pacman -Qi meld
Name : meld
Version : 3.22.0-2.0
Description : Compare files, directories and working copies
Architecture : any
URL : https://meldmerge.org/ Licenses : GPL Groups : None
Provides : None
Depends On : python-gobject python-cairo gtksourceview4 gsettings-desktop-schemas dconf
Optional Deps : None
Required By : None
Optional For : None
Conflicts With : None
Replaces : None
Installed Size : 5.06 MiB
Packager : TasosSah arch32@tasossah.com Build Date : Sat 19 Aug 2023 23:25:57 BST
Install Date : Sat 26 Aug 2023 07:08:59 BST
Install Reason : Explicitly installed
Install Script : No
Validated By : Signature

[keith@Arch32 ~]$ pacman -Qi gtksourceview4
Name : gtksourceview4
Version : 4.8.4-1.0
Description : A text widget adding syntax highlighting and more to GNOME
Architecture : pentium4
URL : https://wiki.gnome.org/Projects/GtkSourceView Licenses : GPL Groups : None
Provides : libgtksourceview-4.so=0-32
Depends On : gtk3 libxml2
Optional Deps : None
Required By : meld xed
Optional For : None
Conflicts With : None
Replaces : None
Installed Size : 7.44 MiB
Packager : Andreas Baumann mail@andreasbaumann.cc Build Date : Mon 07 Nov 2022 11:50:56 GMT
Install Date : Mon 28 Nov 2022 11:49:04 GMT
Install Reason : Installed as a dependency for another package
Install Script : No
Validated By : Signature

[keith@Arch32 ~]$ pacman -Qi gtk3
Name : gtk3
Version : 1:3.24.37-1.0
Description : GObject-based multi-platform GUI toolkit
Architecture : pentium4
URL : https://www.gtk.org/ Licenses : LGPL Groups : None
Provides : gtk3-print-backends libgailutil-3.so=0-32 libgdk-3.so=0-32 libgtk-3.so=0-32
Depends On : adwaita-icon-theme atk cairo cantarell-fonts dconf desktop-file-utils fontconfig fribidi gdk-pixbuf2 glib2 harfbuzz iso-codes

                libcloudproviders  libcolord  libcups  libegl  libepoxy  libgl  librsvg  libxcomposite  libx11  libxcursor  libxdamage  libxext  libxfixes
                libxi  libxinerama  libxkbcommon  libxrandr  libxrender  pango  shared-mime-info  wayland  at-spi2-core  tracker3  gtk-update-icon-cache

Optional Deps : evince: Default print preview command
Required By : bleachbit engrampa firefox gcr gpicview gspell gtkmm3 gtksourceview4 libdbusmenu-gtk3 libgnomekbd libindicator-gtk3 libnma

                libpeas  lightdm-gtk-greeter  lxmusic  vte3  xdg-user-dirs-gtk

Optional For : avahi gvfs libcanberra libdecor libreoffice-still
Conflicts With : gtk3-print-backends
Replaces : gtk3-print-backends⇐3.22.26-1
Installed Size : 49.88 MiB
Packager : Andreas Baumann mail@andreasbaumann.cc Build Date : Sun 16 Apr 2023 11:18:09 BST
Install Date : Tue 25 Apr 2023 13:06:04 BST
Install Reason : Installed as a dependency for another package
Install Script : Yes
Validated By : Signature

[keith@Arch32 ~]$

 353 PackagesBug ReportVery LowLow mc: is broken Closed
100%
Task Description
$ mc
mc: symbol lookup error: mc: undefined symbol: g_string_new_take

$ mcedit
mcedit: symbol lookup error: mcedit: undefined symbol: g_string_new_take
 150 PackagesBug ReportMediumLow MATE doesn't start up Closed
100%
Task Description

no task description

 27 PackagesBug ReportMediumLow man breaks on gdbm sobump Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 02.02.2018
Last edited by Andreas Baumann - 03.02.2018
 FS#27  - man breaks on gdbm sobump

man
man: error while loading shared libraries: libgdbm.so.4: cannot open shared object file: No such file or directory

either you must link against libgdbm_compat.so.4 or against libgdbm.5
Closed by Andreas Baumann
03.02.2018 07:47
Reason for closing: Fixed
Additional comments about closing:

fixed in man-db-2.7.6.1-3.1, installing that package from testing as temporary is the better
solution than adding a symlink you make forget to delete..

  Comments (4)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 02.02.2018 17:50

temporary workaround: ln -fs libgdbm_compat.so.4 /usr/lib/libgdbm.so.4
Admin
Andreas Baumann commented on 02.02.2018 17:53

weird: Archlinux has:

/usr/bin/man is owned by man-db 2.7.6.1-3
gdbm 1.14.1-1

Archlinux 32 has:

man-db 2.7.6.1-3.0
gdbm 1.14.1-1.0

This seems to be pretty much the same version.
Admin
Erich Eckner commented on 02.02.2018 18:15

it’s amazing what packages we managed to break :-/ I scheduled man-db for a rebuild
Admin
Andreas Baumann commented on 02.02.2018 20:38

man-db is rebuilding on my slave. *fingers crossed*

Google Cache

141DevopsBug ReportMediumLowmake iso build more reliablyNew
0%
Task Description

Currently, the iso build are several bash scripts on several machines requiring to move stuff via sshfs and alike.

This should become more stable - ideally some single script/package/systemd-unit with proper error reporting (email or irc come to my mind)

126PackagesBug ReportMediumLowlua hooks break in TeX on i686New
0%
Task Description
PANIC: unprotected error in call to Lua API (CPU with SSE2 required)
PANIC: unprotected error in call to Lua API (CPU with SSE2 required)
fmtutil [ERROR]: running `luajittex -ini   -jobname=luajittex -progname=luajittex luatex.ini </dev/null' return status: 1
fmtutil [ERROR]: cannot copy log luajittex.log to: /var/lib/texmf/web2c/luajittex
fmtutil [ERROR]: returning error due to option --strict
fmtutil [ERROR]: running `luajithbtex -ini   -jobname=luajithbtex -progname=luajithbtex luatex.ini </dev/null' return status: 1
fmtutil [ERROR]: cannot copy log luajithbtex.log to: /var/lib/texmf/web2c/luajithbtex
fmtutil [ERROR]: returning error due to option --strict
error: command failed to execute correctly
276PackagesBug ReportMediumLowLTO optimization needs to much memoryNew
0%
Task Description

7234 build 20 0 1353768 1.2g 18020 R 96.1 64.0 4:27.92 lto1-wpa

xf86-video-intel (this is not exactly a huge package, but maybe the
included X libraries are?)

We lost it on i486 already (because it doesn’t work with newer gcc, or at least
I didn’t investigate how to make it work).

I suggest to get rid of LTO completely.
The problem is patching all the options=(lto), –enable-lto/ –without-lto -D b_lto=tru
etc. which easily creates a maintainance nightmare.

Maybe an easier way to go is to have them similar to the ‘lib32-’ stripping
in the main build scripts or hooks? Downstream this might create
trouble tough, as the build systems are different..

Upstream has options=(lto) support, but it doesn’t seen helping here as packages
need local flags everywhere..

 137 PackagesBug ReportMediumLow llvm rebuild fails (aka sphinx requires a python module ...Closed
100%
Task Description
Configuration error:
There is a programmable error in your configuration file:

Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/sphinx/config.py", line 326, in eval_config_file
    execfile_(filename, namespace)
  File "/usr/lib/python3.9/site-packages/sphinx/util/pycompat.py", line 88, in execfile_
    exec(code, _globals)
  File "/build/llvm/src/llvm-11.0.1.src/docs/conf.py", line 40, in <module>
    import recommonmark
ModuleNotFoundError: No module named 'recommonmark'
108Packages: StagingBug ReportVery LowHighlldb fails to run any binary (error: failed to launch o...Unconfirmed
0%
Task Description

Very easy to reproduce. lldb version 10.0.0, just try to run any binary.

[aeden@arch32 bin]$ lldb $(which date)
(lldb) target create “/usr/bin/date” Current executable set to ‘/usr/bin/date’ (i386).
(lldb) run
error: failed to launch or debug process
(lldb)

 238 PackagesBug ReportVery LowLow Linux-zen kernel 5.16.8.arch1-1.0 made with gcc 11.1 an ...Closed
100%
Task Description

Linux and Linux-zen kernel 5.16.8.arch1-1.0 made with gcc 11.1 and cannot build dkms modules with gcc 11.2

remake linux and linux-zen kernel with gcc version 11.2

 187 DevopsBug ReportMediumLow linux-pae is for x86_64? Closed
100%
Task Description

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.

 60 Packages: Build-listBug ReportMediumLow lightdm gtk greeter fails Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 10.01.2019
Last edited by Andreas Baumann - 20.01.2019
 FS#60  - lightdm gtk greeter fails

Jan 10 12:55:01 arch32-staging systemd-coredump[894]: Process 892 (lightdm-gtk-gre) of user 620 dumped core.

                                                    
                                                    Stack trace of thread 892:
                                                    #0  0x00000000b712bb25 n/a (libglib-2.0.so.0)
                                                    #1  0x00000000b7120230 g_log_default_handler (libglib-2.0.so.0)
                                                    #2  0x00000000b712bd7d g_logv (libglib-2.0.so.0)
                                                    #3  0x00000000b712bf55 g_log (libglib-2.0.so.0)
                                                    #4  0x00000000b711267a g_thread_new (libglib-2.0.so.0)
                                                    #5  0x00000000b7132a1e n/a (libglib-2.0.so.0)
                                                    #6  0x00000000b7132a7a n/a (libglib-2.0.so.0)
                                                    #7  0x00000000b70e78d7 g_unix_signal_source_new (libglib-2.0.so.0)
                                                    #8  0x00000000b70ea3ef g_unix_signal_add_full (libglib-2.0.so.0)
                                                    #9  0x00000000b70ea463 g_unix_signal_add (libglib-2.0.so.0)
                                                    #10 0x00000000004dc145 main (lightdm-gtk-greeter)
                                                    #11 0x00000000b6c87a49 __libc_start_main (libc.so.6)
                                                    #12 0x00000000004de7f5 _start (lightdm-gtk-greeter)

Closed by Andreas Baumann
20.01.2019 16:04
Reason for closing: Fixed
Additional comments about closing:

hotfixed in lightdm-1:1.28.0-1.3

  Comments (12)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 19.01.2019 07:49

So, this happens when registering a signal handler: g_unix_signal_add.

Usually this points into the direction of ABI mismatches..
Admin
Andreas Baumann commented on 19.01.2019 08:07

[+0.83s] DEBUG: Session pid=3468: Running command /usr/bin/lightdm-gtk-greeter
[+0.83s] DEBUG: Creating shared data directory /var/lib/lightdm-data/lightdm
[+0.83s] DEBUG: Session pid=3468: Logging to /var/log/lightdm/seat0-greeter.log
[+1.45s] DEBUG: Seat seat0: Stopping; failed to start a greeter

the logfile is empty.

So, the question is, why doesn’t the greeter start and segfault.
Admin
Andreas Baumann commented on 19.01.2019 09:19

rebuilt both lightdm-gtk-greeter and glib2 with debugging information (options=debug in PKGBUILD).

Now the stacktrace looks like:

#0 0xb7178b25 in _g_log_abort (breakpoint=1) at ../glib/glib/gmessages.c:554
554 G_BREAKPOINT ();
(gdb) bt
#0 0xb7178b25 in _g_log_abort (breakpoint=1) at ../glib/glib/gmessages.c:554
#1 0xb716d230 in g_log_default_handler

  (log_domain=0xb71b40d0 "GLib", log_level=6, message=0x78ee60 "creating thread 'gmain': Error creating thread: Resource temporarily unavailable", unused_data=0x0) at ../glib/glib/gmessages.c:3111

#2 0xb7178d7d in g_logv

  (log_domain=0xb71b40d0 "GLib", log_level=G_LOG_LEVEL_ERROR, format=0xb7207a67 "creating thread '%s': %s", args=0xbf85e91c "\262\320 \267") at ../glib/glib/gmessages.c:1350

#3 0xb7178f55 in g_log

  (log_domain=0xb71b40d0 "GLib", log_level=G_LOG_LEVEL_ERROR, format=0xb7207a67 "creating thread '%s': %s") at ../glib/glib/gmessages.c:1413

#4 0xb715f67a in g_thread_new (name=0xb720d0b2 “gmain”, func=0xb7180b70 , data=0×0)

  at ../glib/glib/gthread.c:830

#5 0xb717fa1e in g_get_worker_context () at ../glib/glib/gmain.c:5888
#6 0xb717fa7a in ref_unix_signal_handler_unlocked (signum=15, signum=)

  at ../glib/glib/gmain.c:5224

#7 0xb71348d7 in _g_main_create_unix_signal_watch (signum=15) at ../glib/glib/gmain.c:5332
#8 0xb71348d7 in g_unix_signal_source_new (signum=15, signum=)

  at ../glib/glib/glib-unix.c:222

#9 0xb71373ef in g_unix_signal_add_full

  (priority=0, signum=15, handler=0x495f90 , user_data=0x1, notify=0x0)
  at ../glib/glib/glib-unix.c:252

#10 0xb7137463 in g_unix_signal_add (signum=15, handler=0x495f90 , user_data=0×1)
–Type for more, q to quit, c to continue without paging–

  at ../glib/glib/glib-unix.c:283

#11 0×00490145 in main (argc=, argv=) at lightdm-gtk-greeter.c:2768

Admin
Andreas Baumann commented on 19.01.2019 09:44

creating thread ‘gmain’: Error creating thread: Resource temporarily unavailable

This is the interesting one. Why should creating a thread run out of resources? And which
resources?
Admin
Andreas Baumann commented on 19.01.2019 09:47

This is not by any chance an unhandled EAGAIN?
Admin
Andreas Baumann commented on 19.01.2019 10:04

[pid 6607] execve(”/usr/bin/core_perl/plymouth”, [”plymouth”, “–ping”], 0xbfa9086c /* 22 vars */) = -1 ENOENT (No such file or directory)

this seems a collateral damage (aka hard-coded call to the bootup manager plymouth), not every
Linux distribution has a plymouth, so I hope, this is actually optional..
The -ping indicates, that plymouth is started with ping, to see whether it is around.
It doesn’t seem to have something to do with our problem though..

There is a strace entry showing the greeter gets started:

[pid 6616] execve(”/usr/bin/lightdm-gtk-greeter”, [”/usr/bin/lightdm-gtk-greeter”], 0xf61510 /* 15 vars */) = 0

later the sighandler tries to open a new thread:

825 GThread *thread;
826
827 thread = g_thread_new_internal (name, g_thread_proxy, func, data, 0, &amp;error);
828
829 if G_UNLIKELY (thread == NULL)
830 g_error (”creating thread ‘%s’: %s”, name ? name : ““, error-&gt;message);
831
832 return thread;

So, if it runs out of resources here (due to a systemd limit, rlimit thing), this would
explain the startup issues..

There is also a suspicious:

[pid 6616] mmap2(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = -1 EAGAIN (Resource temporarily unavailable)

So, I check the rlimit settings used by systemd for login session..
Admin
Andreas Baumann commented on 20.01.2019 09:21

Sounds related:

https://github.com/abrt/faf/issues/212 Admin
Andreas Baumann commented on 20.01.2019 10:37

mmh. why does lightdm-gtk-greeter work on 64-bit Archlinux?
Admin
Andreas Baumann commented on 20.01.2019 10:55

aha. the mmap works there.
Admin
Andreas Baumann commented on 20.01.2019 13:54

lightdm-gtk-greeter.c

mlockall (MCL_CURRENT | MCL_FUTURE);

commenting that out lets the mmap2 succeed.

As we deal with passwords, just disabling the locking is maybe not the best idea.

Incrementing the systemd limit in lightdm.conf LimitMEMLOCK=2684354560
didn’t help at all.
Admin
Andreas Baumann commented on 20.01.2019 13:58

Locking the whole greeter with all GTK inside is maybe also not the wisest idea..
Admin
Andreas Baumann commented on 20.01.2019 14:03

LimitMEMLOCK=infinity in /lib/systemd/system/lightdm.service seemed so help.

Google Cache

 131 PackagesBug ReportMediumLow libseccomp doesn't build in python bindings Closed
100%
Task Description

no task description

 31 PackagesBug ReportMediumLow librsvg fails with invalid opcode on 2.42.1 and newer Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Swift Geek - 16.03.2018
Last edited by Andreas Baumann - 26.03.2018
 FS#31  - librsvg fails with invalid opcode on 2.42.1 and newer

traps: gtk3-demo[365] trap invalid opcode ip:aedd3e15 sp:bffc64c0 error:0 in librsvg-2.so.2.42.3[aed27000+11a000]

Downgrading to 2.40.19 seems to help.
https://archive.archlinux32.org/repos/2017/11/01/extra/os/i686/librsvg-2:2.40.19-1-i686.pkg.tar.xz

This could be related to machine not having SSE2 (Pentium III-M Tualin)

Related bbs thread: https://bbs.archlinux32.org/viewtopic.php?id=1369 Closed by Andreas Baumann
26.03.2018 15:02
Reason for closing: Fixed

  Comments (1)
  Related Tasks (0/0)

Paul Gover commented on 26.03.2018 11:03

For me, librsvg-2:2.42.3-1.2 fixes the problem

Google Cache

 77 Packages: Build-listBug ReportMediumLow librsvg doesn't rebuild Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 30.05.2019
 FS#77  - librsvg doesn’t rebuild

  1. -&gt; /build/librsvg/src/librsvg/target/release/build/typenum-ff577e94a786118f/out/consts.rs:2113:5

|
2111 | pub type P1024 = PInt; pub type N1024 = NInt;

   |     ----------------------------- previous definition of the type `P1024` here

2112 | pub type U1024 = UInt, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;;
2113 | pub type P1024 = PInt; pub type N1024 = NInt;

   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `P1024` redefined here
   |
   = note: `P1024` must be defined only once in the type namespace of this module

error[E0428]: the name `N1024` is defined multiple times

  1. -&gt; /build/librsvg/src/librsvg/target/release/build/typenum-ff577e94a786118f/out/consts.rs:2113:35

|
2111 | pub type P1024 = PInt; pub type N1024 = NInt;

   |                                   ----------------------------- previous definition of the type `N1024` here

2112 | pub type U1024 = UInt, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;;
2113 | pub type P1024 = PInt; pub type N1024 = NInt;

   |                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `N1024` redefined here
   |
   = note: `N1024` must be defined only once in the type namespace of this module

error: aborting due to 3 previous errors

For more information about this error, try `rustc –explain E0428`.
error: Could not compile `typenum`.

Caused by:

process didn't exit successfully: `rustc --crate-name typenum /build/.cargo/registry/src/github.com-1ecc6299db9ec823/typenum-1.10.0/src/lib.rs --color never --crate-type lib --emit=dep-info,link -C opt-level=3 -C debuginfo=2 -C metadata=045a2ce7f5cfaab5 -C extra-filename=-045a2ce7f5cfaab5 --out-dir /build/librsvg/src/librsvg/target/release/deps -L dependency=/build/librsvg/src/librsvg/target/release/deps --cap-lints allow -C target-cpu=pentium3 -C target-feature=-sse2` (exit code: 1)

warning: build failed, waiting for other jobs to finish… error: build failed
make[2]: * [Makefile:1934: /build/librsvg/src/librsvg/target/release/librsvg_internals.a] Error 101
make[2]: Leaving directory ‘/build/librsvg/src/librsvg’ make[1]:
* [Makefile:1438: all-recursive] Error 1
make[1]: Leaving directory ‘/build/librsvg/src/librsvg’ make: *** [Makefile:931: all] Error 2

The same error with typenum as when bootstrapping rust in stage 2.

librsvg is very important as it blocks tons of other stuff (so why
again was it written in Rust?!)

I might have seen a Debian patch for it, but Debian goes a “complete
Rust micro-packaging” way, not sure whether we can apply it here?

  Comments (1)
  Related Tasks (0/0)

Levi commented on 30.05.2019 18:26

Since it looks to me like it’s redefining P1024 and N1024 the same, can’t you just eliminate one of these definitions. Sure, it makes a patch you’d have to maintain henceforth until they fix this upstream, and I don’t understand what kind of preprocessing is ending up with this particular duplication, but deleting a line is about the simplest patch you could maintain.

Google Cache

 23 Packages: Build-listBug ReportMediumLow libretro* packages failing, seem unsupported for 32-bit ...Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 04.01.2018
Last edited by Erich Eckner - 26.01.2018
 FS#23  - libretro* packages failing, seem unsupported for 32-bit Intel/Linux

This affects the following packages:
- libretro-citra (unsuported architecture in dynarmic submodule)
- libretro-parallel-n64: tons of assembly errors
- libretro-ppsspp: linking issues with ffmpeg
- libretro-mupen64plus: direct GOT relocation R_386_GOT32X against _ZN9PluginAPI3getEv PluginAPI::get()

blacklisting all.
Closed by Erich Eckner
26.01.2018 17:08
Reason for closing: Won’t fix
Additional comments about closing:

blacklisted

  Comments (0)

Google Cache

 328 PackagesBug ReportVery LowMedium libreoffice-fresh on i686 is newer then pentium4 Closed
100%
Task Description

i686:- libreoffice-fresh 7.3.4-2.1
pentium4:- libreoffice-fresh 7.3.2-1.0

 76 Packages: StableBug ReportMediumLow libreoffice-fresh needs to be rebuild against icu Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Raphael Scholer - 25.05.2019
 FS#76  - libreoffice-fresh needs to be rebuild against icu

  Comments (1)
  Related Tasks (0/0)

Levi commented on 25.05.2019 18:22

This bug is already captured 90% by https://bugs.archlinux32.org/index.php?do=details&amp;task_id=72 (see my comment underneath it), although to be fair I noted it against libreoffice-stable since that’s what I use.

Google Cache

 195 Packages: TestingBug ReportVery LowLow libreoffice-fresh and libreoffice-still will not start  Closed
100%
Task Description

There is a problem with libreoffice-fresh and libreoffice-still which appears to be caused by the last update to boost and boost-libs which are now at version 1.76.0-1.3

~]$ libreoffice
javaldx: Could not find a Java Runtime Environment!
Warning: failed to read path from javaldx
/usr/lib/libreoffice/program/soffice.bin: error while loading shared libraries: libboost_locale.so.1.75.0: cannot open shared object file: No such file or directory
 56 PackagesBug ReportMediumLow libreoffice-fresh 6.1.3-1.0 in [extra] is not build aga ...Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Raphael Scholer - 11.11.2018
Last edited by Erich Eckner - 14.11.2018
 FS#56  - libreoffice-fresh 6.1.3-1.0 in [extra] is not build against packages in it

libreoffice-fresh seems not to be build against packages in [extra], but rather against packages in [*testing].

Running libreoffice produces the following error message:

/usr/lib/libreoffice/program/soffice.bin: error while loading shared libraries: liborcus-0.14.so.0: cannot open shared object file: No such file or directory

extra/liborcus is 0.13.4-3.1
testing/liborcus is 0.14.1-1.0
Closed by Erich Eckner
14.11.2018 18:05
Reason for closing: Fixed

  Comments (1)
  Related Tasks (0/0)

Admin
Erich Eckner commented on 12.11.2018 10:37

I moved liborcus and libixion from testing to extra - now it should work.

Google Cache

 140 PackagesBug ReportMediumLow libproxy doesn't build Closed
100%
Task Description
-- Installing: /build/libproxy/pkg/libproxy/usr/include/proxy.h
-- Installing: /build/libproxy/pkg/libproxy/usr/bin/proxy
mv: cannot stat '/build/libproxy/pkg/libproxy/usr/lib/libproxy/*/modules/pacrunner_webkit.so': No such file or directory
==> ERROR: A failure occurred in package_libproxy().
    Aborting...
 123 PackagesBug ReportMediumLow libhandy0, libhandy conflicts Closed
100%
Task Description

libhandy0: /usr/share/vala/vapi/libhandy-0.0.deps exists in filesystem (owned by libhandy)
libhandy0: /usr/share/vala/vapi/libhandy-0.0.vapi exists in filesystem (owned by libhandy)

 57 Packages: StableBug ReportMediumLow libc fails on AMD-K6 Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 15.11.2018
Last edited by Andreas Baumann - 31.01.2019
 FS#57  - libc fails on AMD-K6

pacstrap /test base
LD_LIBRARY_PATH=/test/usr/lib gdb –args /test/bin/bash results in:

Program terminated with signal SIGILL, Illegal instruction.
#0 0xb7619991 in strcmp () from /test/usr/lib/libc.so.6
(gdb) bt
#0 0xb7619991 in strcmp () from /test/usr/lib/libc.so.6
#1 0xb75bd41f in setlocale () from /test/usr/lib/libc.so.6
#2 0x0076b7f2 in ?? ()
#3 0x0053acf6 in ?? ()
#4 0xb75b3a31 in __libc_start_main () from /test/usr/lib/libc.so.6
#5 0x0053e561 in ?? ()

So, getting the exact failing opcode is hard.

2.28-5.0 was ok,
2.28-5.2 is not.

So it’s something we changed or something changed on one of the i486 build slaves.

Happens only on the AMD-K6, all other machines with CPUs with limited special instruction
sets (Pentium-S, AMD Geode) are working fine.
Closed by Andreas Baumann
31.01.2019 13:50
Reason for closing: Fixed
Additional comments about closing:

works with glibc-2.28-5.5-i486

  Comments (11)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 10.01.2019 08:27

happens on a Pentium-S now too.
Pentium-II is still fine, so is AMD Geode..
Admin
Andreas Baumann commented on 24.01.2019 10:10

Finally got around to tackle this one
installing a minimal chroot with:

pacstrap /test bash

Then debugging the chroot call:

gdb –args /usr/bin/chroot /test

yields:

Dump of assembler code for function memcpy:

 0xb7ff22f0 &lt;+0&gt;:     test   %al,%al
 0xb7ff22f2 &lt;+2&gt;:     jne    0xb7ff22e8
 0xb7ff22f4 &lt;+4&gt;:     xor    %eax,%eax
 0xb7ff22f6 &lt;+6&gt;:     ret    
 0xb7ff22f7 &lt;+7&gt;:     mov    $0x1,%eax
 0xb7ff22fc &lt;+12&gt;:    mov    $0xffffffff,%ecx

&gt; 0xb7ff2301 &lt;+17&gt;: cmovb %ecx,%eax

 0xb7ff2304 &lt;+20&gt;:    ret    

End of assembler dump.

So, we got cmov creeping in.

/proc/cpuinfo tells us that neither early Pentiums nor AMD K6 had a CMOV opcode.

Now the trick question is, why is it creeping into the C library?

Is the C library compiled with the wrong flags?
Is the gcc assuming that every CPU has a CMOV instruction? Are flags wrong there
or is CMOV suddenly the default?
Admin
Andreas Baumann commented on 24.01.2019 10:39

Checking in glibc: this is the offending opcode

i686/strcmp.S: cmovbl %ecx, %eax

L(neq): movl $1, %eax

      movl    $-1, %ecx
      cmovbl  %ecx, %eax

Now the question is, why does glibc think it’s ok to use i686 optimizations
when compiling with -march-i486.
Admin
Andreas Baumann commented on 24.01.2019 11:09

Not found an obvious reason, retriggering rebuild on known-good (hopefully) i486 build slave.
Admin
Andreas Baumann commented on 24.01.2019 20:44

config.log shows me i686 as build host. This is guessed with config.guess.
Manually executing config.guess on the build machine results in i486-pc-linux-gnu.
setarch i486 ./config.guess results in i686-pc-linux-gnu.
setarch i486 uname -m results in i686.

This breaks every build on i486!

/usr/bin/setarch is owned by util-linux 2.33.1-2.3 and is is completly broken!

And of course, it’s used in setarch “${arch}” mkarchroot in staging-i486-build.

So the consequenses are:
- devtools32 must NOT use setarch anywhere in the *i486* files
- the whole i486 toolchain and all packages have to be rebuilt (basically from the stage of last bootstrapping, every package above could contain bad opcodes!).

The irony is, that building just with makepkg on a emulated i486 virtual machine works
fine, using the devtools breaks things..
Admin
Andreas Baumann commented on 24.01.2019 21:11

Actually, thinking about it: I should try to patch setarch in coreutils for i486.
So we don’t have to fork devtools32 too much from upstream..

binutils and gcc have an explicit host and build flags, so they should be fine.
Maybe rebuilding just glibc with a fixed setarch is sufficient.
Admin
Andreas Baumann commented on 24.01.2019 21:15

If we are unlucky, utsname information in setarch.c is wrong and it’s not
a coreutils problem..
Admin
Andreas Baumann commented on 25.01.2019 08:05

The man page of setarch documents the bug:

The execution domains currently only affects the output of uname -m. For example, on an AMD64 sys-

     tem, running setarch i386 program will cause program to see i686 instead of x86_64 as  the  machine
     type.  It also allows to set various personality options.  The default program is /bin/sh.

So, we are not allowed to fix this, as other programs may rely on the bug.

So, fixing the devtools32 it is… Admin
Andreas Baumann commented on 25.01.2019 09:15

setarch bug reported here:

https://github.com/karelzak/util-linux/issues/707

and here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506632

uname -p reports unknown, this explains why config.guess relies
on uname -m to guess the CPU.

We came to those possible solutions:
- fix setarch.c (rather let it report something different than what the kernel is providing)
- add flags to devtools32 to switch off setarch usage (means, we can no longer build i486 on x86_64 slaves)
- add –build=i486-pc-linux-gnu in every configure call necessary
- go with the CLFS uname hack
- hack setarch of the host machine
Admin
Andreas Baumann commented on 27.01.2019 16:05

The CLFS uname hack solution.

http://trac.clfs.org/ticket/146

http://clfs.org/view/svn/ppc/chroot/before-chroot.html Admin
Andreas Baumann commented on 27.01.2019 18:04

wget http://clfs.org/files/extras/uname_hack-20080713.tar.bz2

PKGBUILD of linux:
_srcver=4.20.4-arch1
pkgver=${_srcver//-/.}
pkgrel=1.0
make modules_prepare

make -C /root/linux/src/archlinux-linux SUBDIRS=$PWD uname_hack_fake_machine=i486

insmod uname_hack.ko

setarch i486 uname -m
i686
setarch i486 ./config.guess
i686-pc-linux-gnu

Ok, the uname hack no longer works, or setarch doesn’t rely on this module information.



Google Cache

 212 PackagesBug ReportVery LowHigh libblockdev issue with glibc Closed
100%
Task Description

Trying to start udisks2 daemon (systemctl start udisks2.service) fails because of a library issue.

/usr/lib/udisks2/udisksd: symbol lookup error: /usr/lib/libbd_utils.so.2: undefined symbol: g_spawn_check_wait_status

Maybe libblockdev needs to be recompiled with the right glibc version.

Thus, it is not possible to auto-mount external USB drives.

 133 PackagesBug ReportMediumLow libao and libpulse mixup Closed
100%
Task Description
resolving dependencies...
warning: cannot resolve "libpulse.so=0-32", a dependency of "libao"
warning: cannot resolve "libpulse-simple.so=0-32", a dependency of "libao"
:: The following package cannot be upgraded due to unresolvable dependencies:
      libao

:: Do you want to skip the above package for this upgrade? [y/N] n
error: failed to prepare transaction (could not satisfy dependencies)
:: unable to satisfy dependency 'libpulse.so=0-32' required by libao
:: unable to satisfy dependency 'libpulse-simple.so=0-32' required by libao
 30 PackagesBug ReportMediumLow libaio, will fail with stack smash protection enabled . ...Closed
100%
Task Description

12.04.2018 - io_queue_run.os: In function `io_queue_run’: io_queue_run.c:(.text+0×71): undefined reference to `__stack_chk_fail_local’ io_getevents.os: In …

 67 Packages: StableBug ReportMediumLow ldc segfault - Arch Linux Closed
100%
Task Description

01.05.2019 - Program terminated with signal SIGSEGV, Segmentation fault. #0 0xb30d3329 in getenv () from /usr/lib/libc.so.6 (gdb) bt #0 0xb30d3329 in …

 147 PackagesBug ReportMediumLow kpgp fails at startup Closed
100%
Task Description
Feb 12 11:57:48 arch32-testing-pentium4 audit[9829]: USER_LOGIN pid=9829 uid=0 auid=1000 ses=7 msg='op=login id=1000 exe="/usr/bin/lightdm" hostname=arch32-testing-pentium4 addr=? terminal=/dev/tty7 res=success'
Feb 12 11:57:48 arch32-testing-pentium4 kernel: audit: type=1112 audit(1613127468.816:104): pid=9829 uid=0 auid=1000 ses=7 msg='op=login id=1000 exe="/usr/bin/lightdm" hostname=arch32-testing-pentium4 addr=? terminal=/dev/tty7 res=success'
Feb 12 11:57:55 arch32-testing-pentium4 kaccess[9880]: Xlib XKB extension major= 1  minor= 0
Feb 12 11:57:56 arch32-testing-pentium4 kaccess[9880]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-guest'
Feb 12 11:57:58 arch32-testing-pentium4 kaccess[9880]: "Session bus not found\nTo circumvent this problem try the following command (with Linux and bash)\nexport $(dbus-launch)"
Feb 12 11:58:00 arch32-testing-pentium4 kgpg[9909]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-guest'
Feb 12 11:58:01 arch32-testing-pentium4 kgpg[9909]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-guest'
Feb 12 11:58:01 arch32-testing-pentium4 kgpg[9909]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-guest'
Feb 12 11:58:01 arch32-testing-pentium4 kgpg[9909]: "Session bus not found\nTo circumvent this problem try the following command (with Linux and bash)\nexport $(dbus-launch)"

 160 PackagesBug ReportMediumLow konqueror fails to work Closed
100%
Task Description

re.so.8 error messages, re.so.9 is in stable

and then segfaults in libQt5WebEngineCore

 114 Packages: StableBug ReportVery LowMedium Kmail: symbol lookup error Closed
100%
Task Description

Kmail 20.08.1-1.0 fails to start with symbol lookup error.

Steps to reproduce: invoking kmail on the console shows:

kmail: symbol lookup error: /usr/lib/libKF5MailImporter.so.5: undefined symbol: _ZN9PimCommon15CustomLogWidgetC1EP7QWidget

Downgrading messagelib fixes this issue but generates other issues (missing files or other undefined symbols).

After all I didn’t find a solution.

210PackagesBug ReportVery LowMediumkeymap don't gets fixed on login as set in /etc/vconsol...Unconfirmed
0%
Task Description

gzip comes with asm code, if enabled, built a TEXTREL which gets bloqued on boot, so systemd don’t set keymap
A lot of tricks in forums, old thread more complete here $506 An old problem. Work around while asm gets fixed is call configure with DEFS=”NO_ASM” like this:

...
export DEFS="NO_ASM"
./configure ....

or,

./configure DEFS="NO_ASM" ....

I have not tested it, but gentoo on x32 have gzip like this and no TEXTRELS here.
No matter i486, i686 or pentium.

Hope it helps.

Best regards.

 167 Packages: StableBug ReportVery LowMedium Kernel lost crypto support necessary for iwd Closed
100%
Task Description

With linux 5.11.1.arch1-1.0, iwd no longer works for associating with WPA2 access points. On attempting to start the service, the journal reads:

iwd: RC4 support not found
iwd: The following options are missing in the kernel:
iwd:    CONFIG_CRYPTO_USER_API_SKCIPHER
iwd:    CONFIG_CRYPTO_ECB
iwd:    CONFIG_CRYPTO_ARC4

It would be nice to have these options enabled in the kernel config, so as to continue support for the iwd package.

 83 Packages: StableBug ReportMediumLow kdeinit5 is filling the systemd journal with nonsensica ...Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 13.07.2019
 FS#83  - kdeinit5 is filling the systemd journal with nonsensical messages

Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: ()
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: ()
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: ()
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: ()
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”))
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: ()

225 root      20   0  359832 225172 224128 S  24.5  29.5   0:45.52 systemd-journal 

Upstream too? Or is it fast enough if one core is dedicated to output
nonsensical output.. :-&gt;

Google Cache

 81 Packages: StableBug ReportMediumLow KDE/Plasma crashes on startup (i686) Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 07.07.2019
 FS#81  - KDE/Plasma crashes on startup (i686)

Application: ksplashqml (ksplashqml), signal: Aborted
Using host libthread_db library “/usr/lib/libthread_db.so.1”.
[Current thread is 1 (Thread 0xb21d5900 (LWP 427))]

Thread 3 (Thread 0xaa75cb40 (LWP 429)):
#0 0xb4b95418 in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0
#1 0xb4b959f7 in ?? () from /usr/lib/libglib-2.0.so.0
#2 0xb4b95be6 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#3 0xb6e75ce5 in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/libQt5Core.so.5
#4 0xb6e18ef5 in QEventLoop::exec(QFlags) () from /usr/lib/libQt5Core.so.5
#5 0xb6c5fe1a in QThread::exec() () from /usr/lib/libQt5Core.so.5
#6 0xb66317c3 in ?? () from /usr/lib/libQt5Qml.so.5
#7 0xb6c611cc in ?? () from /usr/lib/libQt5Core.so.5
#8 0xb5e34018 in start_thread () from /usr/lib/libpthread.so.0
#9 0xb697c25a in clone () from /usr/lib/libc.so.6

Thread 2 (Thread 0xb1a18b40 (LWP 428)):
#0 0xb7f6a82d in kernel_vsyscall ()
#1 0xb6972873 in poll () from /usr/lib/libc.so.6
#2 0xb550c6ce in ?? () from /usr/lib/libxcb.so.1
#3 0xb550e864 in xcb_wait_for_event () from /usr/lib/libxcb.so.1
#4 0xb1bad3da in ?? () from /usr/lib/libQt5XcbQpa.so.5
#5 0xb6c611cc in ?? () from /usr/lib/libQt5Core.so.5
#6 0xb5e34018 in start_thread () from /usr/lib/libpthread.so.0
#7 0xb697c25a in clone () from /usr/lib/libc.so.6 Thread 1 (Thread 0xb21d5900 (LWP 427)):
[KCrash Handler]
#6 0xb7f6a82d in
kernel_vsyscall ()
#7 0xb68c4376 in raise () from /usr/lib/libc.so.6
#8 0xb68ae299 in abort () from /usr/lib/libc.so.6
#9 0xb6c1f873 in QMessageLogger::fatal(char const*, …) const () from /usr/lib/libQt5Core.so.5
#10 0xb6387c44 in QV4::Compiler::Codegen::visit(QQmlJS::AST::UiProgram*) () from /usr/lib/libQt5Qml.so.5
#11 0xb64298d6 in QJSEngine::QJSEngine(QJSEnginePrivate&amp;, QObject*) () from /usr/lib/libQt5Qml.so.5
#12 0xb6575fcd in QQmlEngine::QQmlEngine(QObject*) () from /usr/lib/libQt5Qml.so.5
#13 0xb6888bc4 in KDeclarative::QmlObjectSharedEngine::QmlObjectSharedEngine(QObject*) () from /usr/lib/libKF5Declarative.so.5
#14 0xb7f0fb00 in KQuickAddons::QuickViewSharedEngine::QuickViewSharedEngine(QWindow*) () from /usr/lib/libKF5QuickAddons.so.5
#15 0x0040a29b in ?? ()
#16 0x00408e7a in ?? ()
#17 0x004095a2 in ?? ()
#18 0x004081de in ?? ()
#19 0xb68af7b9 in __libc_start_main () from /usr/lib/libc.so.6
#20 0x004082e5 in _start ()
[Inferior 1 (process 427) detached]

Google Cache

355PackagesBug ReportMediumCriticalKDE packages fail to install because of /libNew
0%
Task Description

Some KDE packages try to replace the ‘lib’ symlink with a directory, causing the system
to fail to start.

If you are lucky, pacman warns you about it and says:

pacman -S breeze-icons
resolving dependencies...
looking for conflicting packages...

Packages (1) breeze-icons-6.0.0-1.0

Total Installed Size:  71.92 MiB
Net Upgrade Size:       0.61 MiB

:: Proceed with installation? [Y/n] 
(1/1) checking keys in keyring                                  [##################################] 100%
(1/1) checking package integrity                                [##################################] 100%
(1/1) loading package files                                     [##################################] 100%
(1/1) checking for file conflicts                               [##################################] 100%
error: failed to commit transaction (conflicting files)
breeze-icons: /lib exists in filesystem (owned by filesystem)
Errors occurred, no packages were upgraded

I had one hard-to-reproduce case where I basically nuked my VMs with that.

The recovery procedure in this case is:

# Boot from last ISO
# mount /dev/xxx to /mnt
cd /usr
mv lib/cmake/* usr/lib/cmake/.
mv lib/qml /usr/lib/.
rmdir lib/cmake
rmdir lib
ln -s usr/lib lib

Packages known to misbehave are ‘kqtquickcharts’, ‘breeze-icons’. Surely more to follow..

 95 Packages: StableBug ReportVery LowHigh KDE broken since KDE Frameworks 5.64 update Closed
100%
Task Description

KDE applications fail to start with the following error:

symbol lookup error: /usr/lib/libKF5QuickAddons.so.5: undefined symbol: _ZNK19KCoreConfigSkeleton10isDefaultsEv

The affected applications I’ve found so far are:
dolphin 19.08.3-1.0
kwin 5.17.3-1.0
plasma-workspace 5.17.0-2.0

After downgrading kdeclarative to 5.63.0-1.0 kwin and plasma start but dolphin fails with a new error:

dolphin: symbol lookup error: /usr/lib/libKF5KCMUtils.so.5: undefined symbol: _ZNK12KQuickAddons12ConfigModule11errorStringEv

Downgrading kcmutils to 5.63.0-1.0 finally fixed dolphin.

 80 Packages: Build-listBug ReportMediumLow kate refuses to build due to some broken shared ... Closed
100%
Task Description

07.07.2019 -  FS#80  - kate refuses to build due to some broken shared library dependencies. /usr/bin/ld: warning: libgit2.so.27, needed by …

 297 PackagesBug ReportVery LowLow jack2 can not install Closed
100%
Task Description
# pacman -S jack --noconfirm
:: There are 2 providers available for jack:
:: Repository extra
   1) jack2  2) pipewire-jack

Enter a number (default=1): 
resolving dependencies...
warning: cannot resolve "libcelt0.so=2-32", a dependency of "jack2"
:: The following package cannot be upgraded due to unresolvable dependencies:
      jack2

:: Do you want to skip the above package for this upgrade? [y/N] error: failed to prepare transaction (could not satisfy dependencies)

:: unable to satisfy dependency 'libcelt0.so=2-32' required by jack2
172PackagesBug ReportVery LowMediumiwd requires some kernel flagsUnconfirmed
0%
Task Description

RC4 support not found
The following options are missing in the kernel:

CONFIG_CRYPTO_USER_API_SKCIPHER
CONFIG_CRYPTO_ECB
CONFIG_CRYPTO_ARC4
Showing tasks 101 - 150 of 350 Page 3 of 7 - 1 - 2 - 3 - 4 - 5 - Last >>

Available keyboard shortcuts

Tasklist

Task Details

Task Editing