This is pentium4 related problem. Firefox crashes on startup with following messages:

ExceptionHandler::GenerateDump cloned child 814
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...

Screenshot. Firefox folder after crash.

Temporary solution is to change in /etc/pacman/conf

Architecture=i686

, delete firefox for pentium4 from pacman cache and reinstall firefox

firefox-106.0.3.1.1-i686

Installing yay from AUR

git clone https://aur.archlinux.org/yay.git
cd yay
makepkg -sri

gives following error

go: updates to go.sum needed, disabled by -mod=readonly

Reason - outdated version of go in i686 architecture

Temporary solution - use go for pentium4 (change temporarily architecture to pentium4 in /etc/pacman.conf)

After updating my system I found that sshd.service will no longer start.

As a temporary work round I downgraded openssl from 3.2.1-1.0 to 3.1.4-1.0

[keith@Arch32 ~]$ sudo pacman -Syu
:: Synchronising package databases...
 core-testing is up to date
 core is up to date
 extra-testing is up to date
 extra is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...

Package (1)           Old Version  New Version  Net Change

core-testing/openssl  3.1.4-1.0    3.2.1-1.0      1.03 MiB

Total Installed Size:  10.54 MiB
Net Upgrade Size:       1.03 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%
(1/1) checking available disk space                                                            [--------------------------------------------------------] 100%
:: Processing package changes...
(1/1) upgrading openssl                                                                        [--------------------------------------------------------] 100%
:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...
[keith@Arch32 ~]$ systemctl restart sshd.service
[keith@Arch32 ~]$ systemctl status sshd.service
× sshd.service - OpenSSH Daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: disabled)
     Active: failed (Result: exit-code) since Tue 2024-02-13 05:36:11 GMT; 6s ago
   Duration: 9ms
    Process: 1008 ExecStart=/usr/bin/sshd -D (code=exited, status=255/EXCEPTION)
   Main PID: 1008 (code=exited, status=255/EXCEPTION)
        CPU: 9ms

Feb 13 05:36:11 Arch32 systemd[1]: sshd.service: Scheduled restart job, restart counter is at 5.
Feb 13 05:36:11 Arch32 systemd[1]: Stopped OpenSSH Daemon.
Feb 13 05:36:11 Arch32 systemd[1]: sshd.service: Start request repeated too quickly.
Feb 13 05:36:11 Arch32 systemd[1]: sshd.service: Failed with result 'exit-code'.
Feb 13 05:36:11 Arch32 systemd[1]: Failed to start OpenSSH Daemon.
[keith@Arch32 ~]$ sudo downgrade openssl
loading packages...
warning: downgrading package openssl (3.2.1-1.0 => 3.1.4-1.0)
resolving dependencies...
looking for conflicting packages...

Package (1)  Old Version  New Version  Net Change

openssl      3.2.1-1.0    3.1.4-1.0     -1.03 MiB

Total Installed Size:   9.51 MiB
Net Upgrade Size:      -1.03 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%
(1/1) checking available disk space                                                            [--------------------------------------------------------] 100%
:: Processing package changes...
(1/1) downgrading openssl                                                                      [--------------------------------------------------------] 100%
:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...
add openssl to IgnorePkg? [y/N] 
[keith@Arch32 ~]$ systemctl restart sshd.service
[keith@Arch32 ~]$ systemctl status sshd.service
● sshd.service - OpenSSH Daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: disabled)
     Active: active (running) since Tue 2024-02-13 05:37:20 GMT; 5s ago
   Main PID: 1138 (sshd)
      Tasks: 1 (limit: 2293)
     Memory: 772.0K
        CPU: 61ms
     CGroup: /system.slice/sshd.service
             └─1138 "sshd: /usr/bin/sshd -D [listener] 0 of 10-100 startups"

Feb 13 05:37:20 Arch32 systemd[1]: Started OpenSSH Daemon.
Feb 13 05:37:20 Arch32 sshd[1138]: Server listening on 0.0.0.0 port 22.
Feb 13 05:37:20 Arch32 sshd[1138]: Server listening on :: port 22.
[keith@Arch32 ~]$ 

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.

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)

asp32 fails to export/checkout anything.

Esample:

# asp32 export pacman
fatal: unable to update url base from redirection:

asked for: https://git.archlinux.org/svntogit/packages.git/info/refs?service=git-upload-pack
 redirect: https://gitlab.archlinux.org/explore/groups

error: failed to update remote packages64

When you have system update there is this warning:

Warn about old perl modules
WARNING: '/usr/lib/perl5/5.34' contains data from at least 1 packages which will NOT be used by the installed perl interpreter.
 -> Run the following command to get a list of affected packages: pacman -Qqo '/usr/lib/perl5/5.34'

After searching you see it’s caused by

$ pacman -Qqo '/usr/lib/perl5/5.34'
perl-term-readline-gnu

So this package should be rebulded, because in repositories is perl 5.36

More info and problem description https://forum.manjaro.pl/t/archlinux32-ostrzezenie-od-perl/2356

$ paccheck pacman
pacman: all dependencies satisfied
zsh: segmentation fault (core dumped) paccheck pacman

It seems to be in the –files check (as with that the crash happens quicker).

Debuginfod doesn’t seem to work for ArchLinux32 (unlike standard ArchLinux) so no debug symbols, but here is the gdb backtrace:

(gdb) bt
#0 0xb7d1989a in strnlen () from /usr/lib/libc.so.6
#1 0xb7d197ac in strncpy () from /usr/lib/libc.so.6
#2 0x00402abe in ?? ()
#3 0x0040244a in ?? ()
#4 0xb7c96129 in ?? () from /usr/lib/libc.so.6
#5 0xb7c961fd in __libc_start_main () from /usr/lib/libc.so.6
#6 0x004026f5 in ?? ()

Valgrind does not seem to work properly on Arch32 either, so I can’t test that.

While installing qemu-desktop for Archlinux32 following error appears:

/usr/bin/gtk-query-immodules-3.0: symbol lookup error: /usr/liblibpango-1.0.so.0: undefined symbol: hb_ot_color_has_paint

Pango version pango-1:1.50.14-1.0-pentium4. This is a problem of Archlinux32 only - in Archlinux there is no error.

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

The linux kernel seems to be stuck at version 6.1.12.arch1-1.0. The build log of the latest stable kernel (linux-6.6.4.arch1-1.0) shows the following error:

=⇒ ERROR: Integrity checks (sha256) differ in size from the source array.
erich@rechenknecht

The pactree tool in pacman-contrib 1.10.5 requires libalpm.so.13 which belongs to an older version of pacman. Rebuilding pacman-contrib with the latest version of pacman installed should resolve the issue.

16.12.2017 - The best, I can get is trying to compile the git HEAD with clisp (instead of sbcl). However, this still errors with: entering make-target-2.sh

07.11.2017 - Nov 07 18:19:32 arch32-testing systemd[1]: Started Process Core Dump (PID 643/UID 0). Nov 07 18:19:35 arch32-testing …

no task description

no task description

no task description

16.11.2017 - It’s the development version of the FOX toolkit. Breaks in some int/FXival/void * abstractions: FXWSQueue.cpp: In member function ‘FX::FXbool …

Attached to Project: Archlinux32
Opened by Luke Shumaker - 21.11.2017
Last edited by Erich Eckner - 25.11.2017
 FS#14  - [ghc-mod] Needs rebuilt

Yesterday, I mentioned on IRC that many haskell packages need rebuilt. In response, deep42thought moved a bunch of packages from staging to stable, and told me to open a bug report if the issue persisted.

For the most part, this seems resolved. Some pacman -Qo/-Ql/ldd/grep magic tells me that all of the haskell packages I have are fine, except for [ghc-mod].
Closed by Erich Eckner
25.11.2017 14:58
Reason for closing: Fixed
Additional comments about closing:

removed - upstream removed it, too

  Comments (1)
  Related Tasks (0/0)

Luke Shumaker commented on 23.11.2017 04:47

deep42thought has removed ghc-mod, reflecting its removal in Arch. Requesting closure.

Google Cache

 FS#16  : [libreoffice-still] still using icu 59 - Arch Linux
28.11.2017 - /usr/lib/libreoffice/program/soffice.bin: error while loading shared libraries: libicuuc.so.59: cannot open shared object file: No such file or …

26.11.2017 - In file included from ./arch/x86/include/asm/page.h:75:0, from ./arch/x86/include/asm/thread_info.h:11, from ./include/linux/thread_info.h:37, …

08.12.2017 -  FS#18  - [android-tools] missing a -latomic when linking adb (and maybe other utilities). Didn’t find the place where to report this upstream!?

no task description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 13.12.2017
Last edited by Erich Eckner - 03.01.2018
 FS#21  - [ceph] unit tests failing or segfault

5/142 Test   #3: test_objectstore_memstore.sh ............***Failed    1.13 sec
7/142 Test   #1: run-rbd-unit-tests.sh ...................***Failed    1.49 sec

46/142 Test #57: unittest_util ………………………*Failed 0.05 sec
51/142 Test #59: unittest_lru ……………………….*Failed 0.57 sec
92/142 Test #100: unittest_erasure_code_shec_arguments ….*Failed 0.63 sec
96/142 Test #102: unittest_journal ……………………*Exception: SegFault 0.90 sec
98/142 Test #106: unittest_mds_sessionfilter …………..*Exception: SegFault 1.02 sec
106/142 Test #116: unittest_bluefs …………………….*Exception: SegFault 0.66 sec
107/142 Test #117: unittest_bluestore_types …………….*Exception: SegFault 1.25 sec
108/142 Test #119: unittest_memstore_clone ……………..*Exception: SegFault 2.51 sec
114/142 Test #124: unittest_osdscrub …………………..*Exception: SegFault 0.63 sec
115/142 Test #125: unittest_pglog ……………………..*Exception: SegFault 1.23 sec
116/142 Test #126: unittest_hitset …………………….*Failed 0.52 sec
125/142 Test #134: test_ceph_argparse.py ……………….*Failed 1.64 sec
130/142 Test #6: run-tox-ceph-disk …………………..*Failed 94.75 sec
132/142 Test #142: unittest_rbd_mirror …………………*Exception: SegFault 0.51 sec
140/142 Test #2: run-cli-tests ………………………*Failed 167.72 sec
141/142 Test #110: mgr-dashboard-smoke.sh ………………*Failed 301.60 sec

Closed by Erich Eckner
03.01.2018 21:15
Reason for closing: Won’t fix
Additional comments about closing:

blacklisted ceph

Comments (9)

Admin
Erich Eckner commented on 17.12.2017 19:11

I’ll build it w/o check(), but we should definitely look into this (later)
Admin
Andreas Baumann commented on 19.12.2017 12:09

ceph goes heavy non-i686:

shell#> cmake ….

Error at cmake/modules/BuildDPDK.cmake:61 (message):

not able to build DPDK support: unsupported target.
"i686-native-linuxapp-gcc" not listed in

Call Stack (most recent call first):

cmake/modules/BuildDPDK.cmake:83 (do_build_dpdk)
cmake/modules/BuildSPDK.cmake:4 (build_dpdk)
CMakeLists.txt:239 (build_spdk)

I suspect libvirt and the other packages can use ceph, but do not require it
really. I would make ceph an optdepend.
Admin
Andreas Baumann commented on 19.12.2017 12:10

Using it without check is no option IMHO.
Admin
Andreas Baumann commented on 03.01.2018 19:29

New try, same bugs:

        1 - run-rbd-unit-tests.sh (Failed)
        2 - run-cli-tests (Failed)
        3 - test_objectstore_memstore.sh (Failed)
       59 - unittest_lru (Failed)
      100 - unittest_erasure_code_shec_arguments (Failed)
      102 - unittest_journal (SEGFAULT)
      106 - unittest_mds_sessionfilter (SEGFAULT)
      116 - unittest_bluefs (SEGFAULT)
      117 - unittest_bluestore_types (SEGFAULT)
      119 - unittest_memstore_clone (SEGFAULT)
      124 - unittest_osdscrub (SEGFAULT)
      125 - unittest_pglog (SEGFAULT)
      126 - unittest_hitset (Failed)
      134 - test_ceph_argparse.py (Failed)
      142 - unittest_rbd_mirror (SEGFAULT)

Decision: remove ceph dependency on libvirt (more?), then blacklist the package.

Reason: we cannot maintain all software for companies upstream.
Admin
Andreas Baumann commented on 03.01.2018 19:45

mmh, a (most likely incomplete) list of software using ceph:

- libvirt: seems to be an optional storage method
- qemu: obvious, if used in combination with libvirt to store the disk image with ceph
- pifpaf: “Suite of tools and fixtures to manage daemons for testing”, ceph used in tests only
- fio: “Scriptable I/O tool for storage benchmarks and drive testing”, ceph seems to be optional

So, all seem to work fine without ceph.
Admin
Andreas Baumann commented on 03.01.2018 19:53

ceph on gihub: a project with pull requests only and no bug reports.. ok then.
Admin
Erich Eckner commented on 03.01.2018 20:59

agreed: I’ll blacklist it, once I compiled a list of ceph dependent packages.
Admin
Erich Eckner commented on 03.01.2018 21:04

I only see libvirt, python-pifpaf and qemu depending on ceph
Admin
Erich Eckner commented on 03.01.2018 21:07

ah, that’s because you already removed the dependencies

Google Cache

Bing Cache

I scheduled a rebuild of viewnior, let me know if viewnior 1.6-3.1 works.

no task description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 02.02.2018
Last edited by Andreas Baumann - 02.02.2018
 FS#26  - [texlive] partially linked against old libmpfr

( 9/18) Updating TeXLive filename database… texlua: error while loading shared libraries: libmpfr.so.4: cannot open shared object file: No such file or directory

Triggered a forced rebuild of textlive-core and texlive-bin.
Closed by Andreas Baumann
02.02.2018 10:15
Reason for closing: Fixed

  Comments (0)

Google Cache

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

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 …

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

11.04.2018 - samba-4.7.5-1.0 smbclient-4.7.5-1.0 libwbclient-4.7.6-1.0. Downgrading those three packages to 4.7.4 as a temporary workaround.

no task description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 10.05.2018
Last edited by Andreas Baumann - 23.01.2019
 FS#37  - ISO 2018.05.01 is not bootable with qemu or Virtualbox

I tried the i686 image. Booting leads to kernel panic.
Adding an explicit init=/lib/systemd/systemd parameter also panics.

qemu-system-i386 -cdrom archlinux-2018.05.01-i686.iso

It also panics in Virtualbox.

The same ISO works with libvirtd though.
Closed by Andreas Baumann
23.01.2019 18:29
Reason for closing: Fixed
Additional comments about closing:

works

  Comments (6)
  Related Tasks (0/0)

Admin
Tyzoid commented on 10.05.2018 10:49

i686 iso works fine in virtualbox on both a windows and linux host from my testing.
Admin
Tyzoid commented on 10.05.2018 11:04

Issue confirmed on qemu-system-i386 and qemu-system-x86_64. archlinux-2018.04.01-i686.iso fails to boot correctly as well.

Screenshot of the issue on i386 qemu: https://i.imgur.com/KRt21gI.png Screenshot of the issue on x86_64 qemu: https://i.imgur.com/wozM2hb.png Admin
Andreas Baumann commented on 11.05.2018 09:02

So /lib/systemd/systemd is either not found or cannot be executed, maybe because of a wrong
shared library dependency? I doubt it has to do with the kernel itself, as the log message
indicates the initial ram disk has been loaded.
Admin
Andreas Baumann commented on 16.06.2018 18:35

The write error indicates that the ramdisk could not be extracted.

So, if I start qemu with:

qemu-system-i386 -enable-kvm -cpu pentium3 -m 2048 -cdrom archlinux-2018.06.01-i686.iso

it works.

The default in qemu is 128MB Admin
Andreas Baumann commented on 16.06.2018 18:48

Sadly this is not the cause for VirtualBox, there it still fails even with 2048MB memory.
Admin
Andreas Baumann commented on 23.01.2019 18:18

The 2019.01.04 ISO works with Virtualbox 6.0.0.

Google Cache

Attached to Project: Archlinux32
Opened by Luke Shumaker - 13.06.2018
Last edited by Erich Eckner - 28.06.2018
 FS#41  - [extra/vlc] is uninstallable because [extra/ffmpeg2.8] was removed

[extra/ffmpeg2.8] (which provided ffmpeg=2.8; [extra/ffmpeg] is 3.4) was removed, despite that it was still needed by [extra/vlc].

[extra/vlc] is an old version (2.2); the current version (3.0), which no longer depends on ffmpeg2.8, is currently in [testing].

(I am unsure if [testing/vlc] depends on extra/ffmpeg=3.4 or testing/ffmpeg=4.0)
Closed by Erich Eckner
28.06.2018 20:25
Reason for closing: Fixed

  Comments (3)
  Related Tasks (0/0)

Admin
Tyzoid commented on 13.06.2018 21:39

Checking https://packages.archlinux32.org/extra/i686/vlc/ vs https://packages.archlinux32.org/testing/i686/vlc/, it appears that the extra/ffmpeg satisfies the testing/vlc requirements.

Here’s from vlc in testing:
libavcodec.so.58 (ffmpeg)
libavformat.so.58 (ffmpeg)
libavutil.so.56 (ffmpeg)

vs vlc in extra:
not satisfiable dependency: “libavcodec.so.56” not satisfiable dependency: “libavformat.so.56” not satisfiable dependency: “libavutil.so.54” Admin
Erich Eckner commented on 18.06.2018 09:37

vlc 3.0.3 is now in extra
Admin
Andreas Baumann commented on 21.06.2018 11:36

vlc 3.0.3 works fine on testing.

Google Cache

no task description

20.06.2018 - In file included from /root/qt5-webengine/src/qtwebengine-everywhere-src-5.11.0/src/plugins/qwebengineview/qwebengineview_plugin.cpp:40:

21.06.2018 - Both the gtk2 and the qt5 version fail with: [FORMS.PP] ExceptionOccurred Sender=EAccessViolation Exception=Access violation Stack trace: …

Attached to Project: Archlinux32
Opened by Levi - 20.08.2018
Last edited by Erich Eckner - 29.10.2018
 FS#49  - ffmpeg update failures in release and testing

When I have done a pacman -Syu recently, it offers to update libx264 with x264:

:: Replace libx264 with testing/x264? [Y/n]
resolving dependencies… looking for conflicting packages… error: failed to prepare transaction (could not satisfy dependencies)
:: removing libx264 breaks dependency ‘libx264.so=152-32’ required by ffmpeg

As can be seen there, it fails because a dependency is not met.

This is reportedly also a problem on the release branches.

Using pacman’s query functionality I can see that x264 claims to provide libx264.so=155-32 rather than 152-32 i.e. x264 is too new for the current version of ffmpeg.

I consider this a high priority defect because ffmpeg is used by rather a lot of a/v playback and transcoding software.
Steps to reproduce

$ pacman -Syu

Workaround

Press n and enter when it offers to upgrade libx264. Ensure you’re not using multiple -ys on your pacman invocation.
Suggested fix

Provide an updated ffmpeg.
Closed by Erich Eckner
29.10.2018 11:50
Reason for closing: Fixed

  Comments (0)

Google Cache

Bing Cache

24.09.2018 - The current extra/imagemagick depends on ‘perl<5.27’, but core/perl is 5.28. $ pacman -Si imagemagick perl Repository : extra Name …

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

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

26.09.2018 - using openbox (not gnome) $ gnome-terminal # Couldn’t register with accessibility bus: Did not receive a reply. Possible causes include: the …

no 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