|
168 | Devops | Bug Report | Medium | Low | i486 slaves are no longer working | Closed | |
Task Description
+ 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
|
|
178 | Devops | Bug Report | Very Low | Low | New installer overwrites pacman mirrors | Closed | |
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.
|
|
187 | Devops | Bug Report | Medium | Low | linux-pae is for x86_64? | Closed | |
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.
|
|
302 | Devops | Feature Request | Very Low | Low | Are you gonna continue 486 support? | Closed | |
Task Description
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…
|
|
141 | Devops | Bug Report | Medium | Low | make iso build more reliably | New | |
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)
|
|
176 | Devops | Feature Request | Medium | Low | bring back archiso32 dual boot | New | |
Task Description
We should make archiso32 be able to build a i686- and x86_64-bootable iso, again. This is really handy on a usb stick as a rescue system.
The problem with the old dual iso is, that I had to do the i686 iso from scratch, because upstream changed from build.sh to putting everything into mkarchiso. Now, everything is steered from a profile file.
So either, we find a way to make a profile for multiple architectures, or we need to patch mkarchiso to do that for us - and maybe upstream these changes.
|
|
5 | Packages | Bug Report | Medium | Low | [sbcl] fails to compile - Arch Linux | Closed | |
Task Description
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
|
|
6 | Packages | Bug Report | Medium | Low | [libreoffice-still] 5.3.7-4 crashes when opening a ... | Closed | |
Task Description
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 …
|
|
7 | Packages | Bug Report | Medium | Low | unknown bug FS#7 | Closed | |
Task Description
no task description |
|
10 | Packages | Bug Report | Medium | Low | unknown bug FS#10 | Closed | |
Task Description
no task description |
|
11 | Packages | Bug Report | Medium | Low | unknown bug FS#11 | Closed | |
Task Description
no task description |
|
13 | Packages | Bug Report | Medium | Low | [fox-devel] fails on 32-bit Intel - Arch Linux | Closed | |
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 …
|
|
14 | Packages | Bug Report | Medium | Low | [ghc-mod] Needs rebuilt | Closed | |
Task Description
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
|
|
16 | Packages | Bug Report | Medium | Low | [libreoffice-still] still using icu 59 - Arch Linux | Closed | |
Task Description
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 …
|
|
17 | Packages | Bug Report | Medium | Low | nvidia and nvidia-lts kernel module build failure on 32 ... | Closed | |
Task Description
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, …
|
|
18 | Packages | Bug Report | Medium | Low | [android-tools] missing a -latomic when linking adb .. | Closed | |
Task Description
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!?
|
|
19 | Packages | Bug Report | Medium | Low | unknown bug FS#19 | Closed | |
Task Description
no task description |
|
21 | Packages | Bug Report | Medium | Low | [ceph] unit tests failing or segfault | Closed | |
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
|
|
24 | Packages | Bug Report | Medium | Low | [extra/viewnior] Needs rebuild against exiv2=0.26 | Closed | |
Task Description
I scheduled a rebuild of viewnior, let me know if viewnior 1.6-3.1 works.
|
|
25 | Packages | Bug Report | Medium | Low | unknown bug FS#25 | Closed | |
Task Description
no task description |
|
26 | Packages | Bug Report | Medium | Low | [texlive] partially linked against old libmpfr | Closed | |
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
|
|
27 | Packages | Bug Report | Medium | Low | man breaks on gdbm sobump | Closed | |
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
|
|
30 | Packages | Bug Report | Medium | Low | libaio, will fail with stack smash protection enabled . ... | Closed | |
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 …
|
|
31 | Packages | Bug Report | Medium | Low | librsvg fails with invalid opcode on 2.42.1 and newer | Closed | |
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
|
|
32 | Packages | Bug Report | Medium | Low | [samba] faileure to start due to linking issues | Closed | |
Task Description
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.
|
|
34 | Packages | Bug Report | Medium | Low | unknown bug FS#34 | Closed | |
Task Description
no task description |
|
37 | Packages | Bug Report | Medium | Low | ISO 2018.05.01 is not bootable with qemu or Virtualbox | Closed | |
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
|
|
41 | Packages | Bug Report | Medium | Low | [extra/vlc] is uninstallable because [extra/ffmpeg2.8] ... | Closed | |
Task Description
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
|
|
42 | Packages | Bug Report | Medium | Low | Unknown bug FS#42 | Closed | |
Task Description
no task description |
|
44 | Packages | Bug Report | Medium | Low | [qt5-webengine] fatal error: QtUiPlugin ... | Closed | |
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:
|
|
45 | Packages | Bug Report | Medium | Low | doublecmd: access violation - Arch Linux | Closed | |
Task Description
21.06.2018 - Both the gtk2 and the qt5 version fail with: [FORMS.PP] ExceptionOccurred Sender=EAccessViolation Exception=Access violation Stack trace: …
|
|
49 | Packages | Bug Report | Medium | Low | ffmpeg update failures in release and testing | Closed | |
Task Description
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
|
|
50 | Packages | Bug Report | Medium | Low | [imagemagick] is not installable because of [perl] | Closed | |
Task Description
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 …
|
|
51 | Packages | Bug Report | Medium | Low | ufw needs rebuild for python 3.7 | Closed | |
Task Description
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
|
|
52 | Packages | Bug Report | Medium | Low | Some packages are built by "Unknown Packager" | Closed | |
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
|
|
53 | Packages | Bug Report | Medium | Low | [gnome-terminal]: fails to star | Closed | |
Task Description
26.09.2018 - using openbox (not gnome) $ gnome-terminal # Couldn’t register with accessibility bus: Did not receive a reply. Possible causes include: the …
|
|
55 | Packages | Bug Report | Medium | Low | Unknown bug FS#55 | Closed | |
Task Description
no task description |
|
56 | Packages | Bug Report | Medium | Low | libreoffice-fresh 6.1.3-1.0 in [extra] is not build aga ... | Closed | |
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
|
|
59 | Packages | Bug Report | Medium | Low | unison segfault | Closed | |
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
|
|
73 | Packages | Bug Report | Medium | Low | [gajim] fails to launch when (optional) gupnp-igd is in ... | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by bill auger - 13.05.2019 Last edited by Andreas Baumann - 02.10.2019
FS#73 - [gajim] fails to launch when (optional) gupnp-igd is installed
$ gajim No translations found Dirs searched: [PosixPath(’/usr/local/share’), PosixPath(’/usr/share’), PosixPath(’/usr/share/gdm’), PosixPath(’/var/lib/menu-xdg’)]
(gajim:1588): dbind-WARNING : 15:14:29.481: Couldn’t connect to accessibility bus: Failed to connect to socket /tmp/dbus-Nv1LTXmb8O: Connection refused
(gajim:1588): WARNING **: 15:14:29.534: Failed to load shared library ‘libgupnp-igd-1.0.so.4’ referenced by the typelib: libgupnp-1.2.so.0: cannot open shared object file: No such file or directory /usr/lib/python3.7/site-packages/gajim/common/app.py:281: Warning: cannot retrieve class for invalid (unclassed) type ‘void’
gupnp_igd = GUPnPIgd.SimpleIgd()
Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/gajim/application.py", line 185, in _startup
app.detect_dependencies()
File "/usr/lib/python3.7/site-packages/gajim/common/app.py", line 281, in detect_dependencies
gupnp_igd = GUPnPIgd.SimpleIgd()
TypeError: could not get a reference to type class Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/gajim/application.py", line 220, in _activate
self.interface = Interface()
File "/usr/lib/python3.7/site-packages/gajim/gui_interface.py", line 2615, in __init__
cfg_was_read = parser.read()
File "/usr/lib/python3.7/site-packages/gajim/common/optparser.py", line 86, in read
self.update_config(old_version, new_version)
File "/usr/lib/python3.7/site-packages/gajim/common/optparser.py", line 158, in update_config
caps_cache.capscache.initialize_from_db()
AttributeError: ‘NoneType’ object has no attribute ‘initialize_from_db’ Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/gajim/application.py", line 269, in do_shutdown
app.logger.commit()
AttributeError: ‘NoneType’ object has no attribute ‘commit’
Closed by Andreas Baumann 02.10.2019 19:36 Reason for closing: Fixed Additional comments about closing:
Seems to work on pentium4/stable. Feel free to reopen if you it crashes for you..
Google Cache
|
|
84 | Packages | Bug Report | Medium | Low | Unknown bug FS#84 | Closed | |
Task Description
no task description |
|
87 | Packages | Bug Report | Medium | Low | firefox doesn't rebuild | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Andreas Baumann - 21.09.2019 Last edited by Andreas Baumann - 21.09.2019
FS#87 - firefox doesn’t rebuild
OOM when build gkrust:
patching out debug_level=2 in moz.configure/toolchain.configure
thanks BoidLinux for the hint.
Comments (3)
Related Tasks (0/0)
Admin Andreas Baumann commented on 21.09.2019 17:05
A test is executed testing the generated Gecko rust library (a static library), whether it contains references to networking functions, this fails on IA32:
https://hg.mozilla.org/mozilla-central/rev/47cd8671b12c
$(call py_action,check_binary,–target –networking $@)
Solution is just not to execute this check in config/makefiles/rust.mk Admin Andreas Baumann commented on 21.09.2019 17:08
187:52.88 toolkit/library/libxul.so 190:00.47 readelf: Error: Unable to seek to 0x801db328 for section headers 190:01.36 out of memory allocating 3761314508 bytes after a total of 1595923192 bytes 190:01.47 File “/build/firefox/src/firefox-69.0.1/python/mozbuild/mozbuild/action/check_binary.py”, line 361, in
=> python/readelf combo reads whole generated libxul.so into memory in order to do some ELF fidding.
190:01.48 make[4]: *** [/build/firefox/src/firefox-69.0.1/config/rules.mk:661: libxul.so] Error 1
shows us:
$(SHARED_LIBRARY): $(OBJS) $(RESFILE) $(RUST_STATIC_LIB) $(STATIC_LIBS) $(EXTRA_DEPS) $(GLOBAL_DEPS)
$(REPORT_BUILD)
ifndef INCREMENTAL_LINKER
$(RM) $@
endif
$(MKSHLIB) $($@_$(OBJS_VAR_SUFFIX)) $(RESFILE) $(LDFLAGS) $(STATIC_LIBS) $(RUST_STATIC_LIB) $(SHARE
$(call py_action,check_binary,--target $@)
Trying to comment that out too (the python check). Admin Andreas Baumann commented on 22.09.2019 07:46
Now libxul.so misses some libraries, like libmozsandbox.so, liblgpllibs.so, … The libraries exists, but most likely libxul.so cannot find them (rpath ELF fiddling?).
As a workaround I’ll set LD_LIBRARY_PATH=/usr/lib/firefox in the startup wrapper scripts /usr/bin/firefox.
Google Cache
|
|
88 | Packages | Bug Report | Medium | Low | Unknown Bug FS#88 | Closed | |
Task Description
no task description |
|
89 | Packages | Bug Report | Medium | Low | Unknown Bug FS#89 | Closed | |
Task Description
no task description |
|
90 | Packages | Bug Report | Medium | Low | Unknown Bug FS#90 | Closed | |
Task Description
no task description |
|
92 | Packages | Bug Report | Medium | Low | nfs mounts with sec=krb5 fail with 'stale file handle' ... | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Markus Schaaf - 22.10.2019
FS#92 - nfs mounts with sec=krb5 fail with ‘stale file handle’ for everyone but root
rpc.gssd bug due to missing syscall (setgroups). See https://bugzilla.linux-nfs.org/show_bug.cgi?id=340 `journalctl –unit=rpc-gssd.service` shows:
WARNING: unable to drop supplimentary groups! WARNING: failed to change identity: Function not implemented
Until a fixed upstream release, use $ cat abs/packages/nfs-utils/trunk/setgroups32.patch — nfs-utils-2.4.1/utils/gssd/gssd_proc.c.orig 2019-10-22 11:26:48.059877484 +0200 +++ nfs-utils-2.4.1/utils/gssd/gssd_proc.c 2019-10-22 11:28:03.874553996 +0200 @@ -437,7 +437,7 @@
int res;
/* drop list of supplimentary groups first */
- if (syscall(SYS_setgroups, 0, 0) != 0) { + if (syscall(SYS_setgroups32, 0, 0) != 0) {
printerr(0, "WARNING: unable to drop supplimentary groups!");
return errno;
}
Google Cache
|
|
104 | Packages | Bug Report | Medium | High | [glibc] 2.31-1.0 broken | Closed | |
Task Description
Real machines (i686) break apart in mutliple ways: systemd-journald fails to start, also udev seems to have trouble. This leaves one with a rescue console. And at least in my rescue console, my keyboard did not work. I also have a pentium4 vm which won’t boot currently (I might give some details, when I have a little more time).
|
|
106 | Packages | Bug Report | Medium | Low | packages are unstripped? | Closed | |
Task Description
looks, like the new devtools do not strip packages anymore - maybe it was only an intermediate version, that lacked automatic stripping.
|
|
107 | Packages | Bug Report | Very Low | Low | wireguard-dkms-0.0.20200318-1.0 does not build with 5.5 ... | Closed | |
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'
|
|
110 | Packages | Bug Report | Very Low | Low | [syslog-ng] is built without systemd support | Closed | |
Task Description
The packages for syslog-ng since version 3.27.1-1.0 appears to have been built without systemd support. Although their PKGBUILD runs configure with –enable-systemd, running syslog-ng –version shows Enable-Systemd: off. The official Arch x86_64 package (at version 3.28.1-1) doesn’t exhibit this problem.
I tried building the package locally on i686 using the official Arch PKGBUILD and could not reproduce the problem. My locally built version correctly finds libsystemd during configure, and gets built with systemd support. This leads me to believe the problem happens somewhere in the Archlinux32 build process.
The practical upshot of the problem is that the systemd unit file supplied with syslog-ng lists it as a Type=notify service, but when it fails to notify systemd after startup, systemd eventually kills it and restarts it repeatedly:
Jul 24 07:32:31 wolfie systemd[1]: Starting System Logger Daemon "default" instance...
Jul 24 07:32:32 wolfie syslog-ng[18977]: syslog-ng starting up; version='3.28.1'
Jul 24 07:34:01 wolfie systemd[1]: syslog-ng@default.service: start operation timed out. Terminating.
Jul 24 07:34:01 wolfie syslog-ng[18977]: syslog-ng shutting down; version='3.28.1'
Jul 24 07:34:01 wolfie systemd[1]: syslog-ng@default.service: Failed with result 'timeout'.
Jul 24 07:34:01 wolfie systemd[1]: Failed to start System Logger Daemon "default" instance.
Jul 24 07:34:02 wolfie systemd[1]: syslog-ng@default.service: Scheduled restart job, restart counter is at 1.
Jul 24 07:34:02 wolfie systemd[1]: Stopped System Logger Daemon "default" instance.
Jul 24 07:34:02 wolfie systemd[1]: Starting System Logger Daemon "default" instance...
|