Flyspray:: https://bugs.archlinux32.org/ Flyspray::Archlinux32: Recently closed tasks 2019-01-31T13:50:02Z FS#57: libc fails on AMD-K6 https://bugs.archlinux32.org/index.php?do=details&task_id=57 2019-01-31T13:50:02Z Andreas Baumann pacstrap /test baseLD_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 instructionsets (Pentium-S, AMD Geode) are working fine. 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.

]]>
FS#37: ISO 2018.05.01 is not bootable with qemu or Virtualbox https://bugs.archlinux32.org/index.php?do=details&task_id=37 2019-01-23T18:29:02Z Andreas Baumann 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. 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.

]]>
FS#60: lightdm gtk greeter fails https://bugs.archlinux32.org/index.php?do=details&task_id=60 2019-01-20T16:04:15Z Andreas Baumann 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) 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) ]]> FS#59: unison segfault https://bugs.archlinux32.org/index.php?do=details&task_id=59 2019-01-10T14:15:43Z Andreas Baumann Calling unison, a file synchronizer written in Ocaml. Segfaults.Most likely a string optimization inside Ocaml itself or a non-matchinglibrary somewhere (recompile ocaml?) (gdb) bt #0 0x006782df in caml_string_equal () #1 0x005ce0d8 in camlUpdate__archiveMode_802888 () #2 0x005ce6e5 in camlUpdate__setArchiveData_802926 () #3 0x005da668 in camlGlobals__fun_802549 () #4 0x005fed99 in camlLwt_util__map_1080 () #5 0x005fedac in camlLwt_util__map_1080 () #6 0x005da5b9 in camlGlobals__allRootsMap_301891 () #7 0x005cea7f in camlUpdate__loadArchives_802958 () #8 0x005d4637 in camlUpdate__findUpdatesOnPaths_2603478 () #9 0x005b36f5 in camlUitext__synchronizeOnce_1102725 () #10 0x005b4041 in camlUitext__loop_1203129 () #11 0x005b41d6 in camlUitext__synchronizeUntilDone_1203134 () #12 0x005b442e in camlUitext__start_1303143 () #13 0x005acc54 in camlMain__Body_401249 () #14 0x005ac19d in camlLinktext__entry () #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 () 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 camlUpdate__archiveMode_802888 ()
#2  0x005ce6e5 in camlUpdate__setArchiveData_802926 ()
#3  0x005da668 in camlGlobals__fun_802549 ()
#4  0x005fed99 in camlLwt_util__map_1080 ()
#5  0x005fedac in camlLwt_util__map_1080 ()
#6  0x005da5b9 in camlGlobals__allRootsMap_301891 ()
#7  0x005cea7f in camlUpdate__loadArchives_802958 ()
#8  0x005d4637 in camlUpdate__findUpdatesOnPaths_2603478 ()
#9  0x005b36f5 in camlUitext__synchronizeOnce_1102725 ()
#10 0x005b4041 in camlUitext__loop_1203129 ()
#11 0x005b41d6 in camlUitext__synchronizeUntilDone_1203134 ()
#12 0x005b442e in camlUitext__start_1303143 ()
#13 0x005acc54 in camlMain__Body_401249 ()
#14 0x005ac19d in camlLinktext__entry ()
#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 ()
]]>
FS#58: texlive-bin doesn't build https://bugs.archlinux32.org/index.php?do=details&task_id=58 2018-12-22T07:16:59Z Andreas Baumann g++ -DHAVE_CONFIG_H -I. -I../../../texk/web2c -I./w2c -I/build/texlive-bin/src/texlive-source/Work/texk -I/build/texlive-bin/src/texlive-source/texk -I/usr/include/libpng16 -DPOPPLER_VERSION=\"0.71.0\" -I/usr/include/poppler -I../../../texk/web2c/libmd5 -I../../../texk/web2c/pdftexdir -D_FORTIFY_SOURCE=2 -Wreturn-type -Wno-write-strings -march=i686 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -MT pdftexdir/libpdftex_a-pdftoepdf.o -MD -MP -MF pdftexdir/.deps/libpdftex_a-pdftoepdf.Tpo -c -o pdftexdir/libpdftex_a-pdftoepdf.o `test -f 'pdftexdir/pdftoepdf.cc' || echo '../../../texk/web2c/'`pdftexdir/pdftoepdf.cc ../../../texk/web2c/pdftexdir/pdftoepdf.cc: In function ‘void copyFont(char*, Object*)’: ../../../texk/web2c/pdftexdir/pdftoepdf.cc:430:69: error: ‘std::__cxx11::basic_string’ is not an accessible base of ‘const GooString’ epdf_mark_glyphs(fd, (char *)charset.getString()->c_str()); ^ ../../../texk/web2c/pdftexdir/pdftoepdf.cc:430:69: error: ‘const _CharT* std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::c_str() const [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’ is inaccessible within this context In file included from /usr/include/c++/8.2.1/string:52, from /usr/include/poppler/goo/GooString.h:37, from ../../../texk/web2c/pdftexdir/pdftoepdf.cc:46: /usr/include/c++/8.2.1/bits/basic_string.h:2290:7: note: declared here c_str() const _GLIBCXX_NOEXCEPT ^~~~~ ../../../texk/web2c/pdftexdir/pdftoepdf.cc: In function ‘void copyObject(Object*)’: ../../../texk/web2c/pdftexdir/pdftoepdf.cc:569:30: error: ‘std::__cxx11::basic_string’ is not an accessible base of ‘GooString’ p = (char *)s->c_str(); ^ ../../../texk/web2c/pdftexdir/pdftoepdf.cc:569:30: error: ‘const _CharT* std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::c_str() const [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’ is inaccessible within this context In file included from /usr/include/c++/8.2.1/string:52, from /usr/include/poppler/goo/GooString.h:37, from ../../../texk/web2c/pdftexdir/pdftoepdf.cc:46: /usr/include/c++/8.2.1/bits/basic_string.h:2290:7: note: declared here c_str() const _GLIBCXX_NOEXCEPT ^~~~~ make[5]: *** [Makefile:16347: pdftexdir/libpdftex_a-pdftoepdf.o] Error 1 make[5]: Leaving directory '/build/texlive-bin/src/texlive-source/Work/texk/web2c' make[4]: *** [Makefile:16801: all-recursive] Error 1 make[4]: Leaving directory '/build/texlive-bin/src/texlive-source/Work/texk/web2c' make[3]: *** [Makefile:4780: all] Error 2 make[3]: Leaving directory '/build/texlive-bin/src/texlive-source/Work/texk/web2c' make[2]: *** [Makefile:911: recurse] Error 1 make[2]: Leaving directory '/build/texlive-bin/src/texlive-source/Work/texk' make[1]: *** [Makefile:488: all-recursive] Error 1 make[1]: Leaving directory '/build/texlive-bin/src/texlive-source/Work/texk' make: *** [Makefile:576: all-recursive] Error 1 ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Build failed, check /data/archbuild/chroots/staging-i686/abaumann/build g++ -DHAVE_CONFIG_H -I. -I../../../texk/web2c -I./w2c -I/build/texlive-bin/src/texlive-source/Work/texk -I/build/texlive-bin/src/texlive-source/texk -I/usr/include/libpng16 -DPOPPLER_VERSION=\"0.71.0\" -I/usr/include/poppler -I../../../texk/web2c/libmd5 -I../../../texk/web2c/pdftexdir -D_FORTIFY_SOURCE=2 -Wreturn-type -Wno-write-strings -march=i686 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -MT pdftexdir/libpdftex_a-pdftoepdf.o -MD -MP -MF pdftexdir/.deps/libpdftex_a-pdftoepdf.Tpo -c -o pdftexdir/libpdftex_a-pdftoepdf.o `test -f 'pdftexdir/pdftoepdf.cc' || echo '../../../texk/web2c/'`pdftexdir/pdftoepdf.cc ../../../texk/web2c/pdftexdir/pdftoepdf.cc: In function ‘void copyFont(char*, Object*)’: ../../../texk/web2c/pdftexdir/pdftoepdf.cc:430:69: error: ‘std::__cxx11::basic_string’ is not an accessible base of ‘const GooString’ epdf_mark_glyphs(fd, (char *)charset.getString()->c_str()); ^ ../../../texk/web2c/pdftexdir/pdftoepdf.cc:430:69: error: ‘const _CharT* std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::c_str() const [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’ is inaccessible within this context In file included from /usr/include/c++/8.2.1/string:52, from /usr/include/poppler/goo/GooString.h:37, from ../../../texk/web2c/pdftexdir/pdftoepdf.cc:46: /usr/include/c++/8.2.1/bits/basic_string.h:2290:7: note: declared here c_str() const _GLIBCXX_NOEXCEPT ^~~~~ ../../../texk/web2c/pdftexdir/pdftoepdf.cc: In function ‘void copyObject(Object*)’: ../../../texk/web2c/pdftexdir/pdftoepdf.cc:569:30: error: ‘std::__cxx11::basic_string’ is not an accessible base of ‘GooString’ p = (char *)s->c_str(); ^ ../../../texk/web2c/pdftexdir/pdftoepdf.cc:569:30: error: ‘const _CharT* std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::c_str() const [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’ is inaccessible within this context In file included from /usr/include/c++/8.2.1/string:52, from /usr/include/poppler/goo/GooString.h:37, from ../../../texk/web2c/pdftexdir/pdftoepdf.cc:46: /usr/include/c++/8.2.1/bits/basic_string.h:2290:7: note: declared here c_str() const _GLIBCXX_NOEXCEPT ^~~~~ make[5]: *** [Makefile:16347: pdftexdir/libpdftex_a-pdftoepdf.o] Error 1 make[5]: Leaving directory '/build/texlive-bin/src/texlive-source/Work/texk/web2c' make[4]: *** [Makefile:16801: all-recursive] Error 1 make[4]: Leaving directory '/build/texlive-bin/src/texlive-source/Work/texk/web2c' make[3]: *** [Makefile:4780: all] Error 2 make[3]: Leaving directory '/build/texlive-bin/src/texlive-source/Work/texk/web2c' make[2]: *** [Makefile:911: recurse] Error 1 make[2]: Leaving directory '/build/texlive-bin/src/texlive-source/Work/texk' make[1]: *** [Makefile:488: all-recursive] Error 1 make[1]: Leaving directory '/build/texlive-bin/src/texlive-source/Work/texk' make: *** [Makefile:576: all-recursive] Error 1 ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Build failed, check /data/archbuild/chroots/staging-i686/abaumann/build ]]> FS#56: libreoffice-fresh 6.1.3-1.0 in [extra] is not build against packages in it https://bugs.archlinux32.org/index.php?do=details&task_id=56 2018-11-14T18:05:17Z Raphael Scholer 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.1testing/liborcus is 0.14.1-1.0 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

]]>
FS#49: ffmpeg update failures in release and testing https://bugs.archlinux32.org/index.php?do=details&task_id=49 2018-10-29T11:50:56Z Levi 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. 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.

]]>
FS#55: protobuf 3.6.0 needs pushing from testing to stable https://bugs.archlinux32.org/index.php?do=details&task_id=55 2018-10-28T18:03:16Z Levi As per https://bbs.archlinux32.org/viewtopic.php?pid=5140 Python-protobuf 3.6.0 has already been pushed to extra for a long time now, but protobuf is still at version 3.5.2. As far as I’m aware, the set in testing all works. For completeness, puthon2-protobuf 3.6.0 probably needs to be migrated to stable extra as well. As per https://bbs.archlinux32.org/viewtopic.php?pid=5140

Python-protobuf 3.6.0 has already been pushed to extra for a long time now, but protobuf is still at version 3.5.2. As far as I’m aware, the set in testing all works.

For completeness, puthon2-protobuf 3.6.0 probably needs to be migrated to stable extra as well.

]]>
FS#48: Testing repo missing a new version of python-six https://bugs.archlinux32.org/index.php?do=details&task_id=48 2018-09-24T08:45:56Z Levi I’ve become aware that python-six doesn’t identify that it depends specifically on python3.6 (it claims in the text that it’s for python 3 as well as python 2, which I don’t believe can be true; it only puts python files in /usr/lib/python3.6). It has however allowed python 3.7 into the testing repo while no new version of python-six is available, and this version of python3 can no longer find a version of six when you import it. As far as I know this is not an issue for anyone strictly on the release repos yet, and still won’t be an issue for anyone not using python-six either directly or indirectly. Steps to reproduce (upgrade at least python from the testing repos)# python# import six> ...> ModuleNotFoundError: No module named ‘six’ Steps to fix A new version of python-six that supplies its files to python3.7/site-packages should be built and uploaded to the testing repos, and it should probably identify its dependent versions better. I note arch64 has a newer python-six that supplies its libs to python3.7 just fine, although it also doesn’t identify its versions to my liking. I’ve become aware that python-six doesn’t identify that it depends specifically on python3.6 (it claims in the text that it’s for python 3 as well as python 2, which I don’t believe can be true; it only puts python files in /usr/lib/python3.6).

It has however allowed python 3.7 into the testing repo while no new version of python-six is available, and this version of python3 can no longer find a version of six when you import it.

As far as I know this is not an issue for anyone strictly on the release repos yet, and still won’t be an issue for anyone not using python-six either directly or indirectly.

Steps to reproduce

(upgrade at least python from the testing repos)
# python
# import six
> ...
> ModuleNotFoundError: No module named ‘six’

Steps to fix

A new version of python-six that supplies its files to python3.7/site-packages should be built and uploaded to the testing repos, and it should probably identify its dependent versions better.

I note arch64 has a newer python-six that supplies its libs to python3.7 just fine, although it also doesn’t identify its versions to my liking.

]]>
FS#50: [imagemagick] is not installable because of [perl] https://bugs.archlinux32.org/index.php?do=details&task_id=50 2018-09-24T08:43:36Z Luke Shumaker The current extra/imagemagick depends on ‘perl<5.27’, but core/perl is 5.28. $ pacman -Si imagemagick perl Repository : extra Name : imagemagick Version : 7.0.7.28-1.0 … Depends On : libmagick=7.0.7.28-1.0 perl>=5.26 perl<5.27 … Repository : core Name : perl Version : 5.28.0-1.0 … The current extra/imagemagick depends on ‘perl<5.27’, but core/perl is 5.28.

$ pacman -Si imagemagick perl
Repository      : extra
Name            : imagemagick
Version         : 7.0.7.28-1.0
…
Depends On      : libmagick=7.0.7.28-1.0  perl>=5.26  perl<5.27
…

Repository      : core
Name            : perl
Version         : 5.28.0-1.0
…
]]>