Flyspray:: Flyspray::Archlinux32: Recently opened tasks https://bugs.archlinux32.org/ 2019-02-07T09:35:43Z FS#63: nodejs crashes in libuv when cleaning up FSReqCallback 2019-02-07T09:35:43Z 2019-02-07T09:35:43Z
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00945919 in node::fs::FSReqCallback::~FSReqCallback() ()
[Current thread is 1 (Thread 0xb5614880 (LWP 2013))]
(gdb) bt
#0  0x00945919 in node::fs::FSReqCallback::~FSReqCallback() ()
#1  0x00937274 in node::fs::FSReqAfterScope::~FSReqAfterScope() ()
#2  0x0093767d in node::fs::AfterInteger(uv_fs_s*) ()
#3  0xb7e910e0 in uv.work_done () from /usr/lib/libuv.so.1
#4  0xb7e9526e in ?? () from /usr/lib/libuv.so.1
#5  0xb7ea51f8 in uv.io_poll () from /usr/lib/libuv.so.1
#6  0xb7e95c51 in uv_run () from /usr/lib/libuv.so.1
#7  0x00905d37 in node::Start(v8::Isolate*, node::IsolateData*, std::vector, std::allocator >, std::allocator, std::allocator > > > const&, std::vector, std::allocator >, std::allocator, std::allocator > > > const&) ()
#8  0x00903655 in node::Start(int, char**) ()
#9  0x008acef1 in main ()

This affects gyp, vault and probably some other packages, depending whether those callbacks are used or not.

Andreas Baumann https://bugs.archlinux32.org/:63
FS#62: sddm-greeter aborts 2019-02-02T07:50:13Z 2019-02-01T07:55:15Z
(gdb) bt
#0  0xb7fbea41 in __kernel_vsyscall ()
#1  0xb6418746 in raise () from /usr/lib/libc.so.6
#2  0xb64021e3 in abort () from /usr/lib/libc.so.6
#3  0xb6793775 in QMessageLogger::fatal(char const*, ...) const () from /usr/lib/libQt5Core.so.5
#4  0xb74da6fc in QV4::Compiler::Codegen::visit(QQmlJS::AST::UiProgram*) () from /usr/lib/libQt5Qml.so.5
#5  0xb756f446 in QJSEngine::QJSEngine(QJSEnginePrivate&, QObject*) () from /usr/lib/libQt5Qml.so.5
#6  0xb76afe1d in QQmlEngine::QQmlEngine(QObject*) () from /usr/lib/libQt5Qml.so.5
#7  0xb7cf93bb in QQuickViewPrivate::init(QQmlEngine*) () from /usr/lib/libQt5Quick.so.5
#8  0x0050c571 in SDDM::GreeterApp::addViewForScreen(QScreen*) ()
#9  0x0050d1a4 in SDDM::GreeterApp::startup() ()
#10 0xb69a6a4e in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5
#11 0xb697a565 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5
#12 0xb697d8c6 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
   from /usr/lib/libQt5Core.so.5
#13 0xb697dcd9 in QCoreApplication::sendPostedEvents(QObject*, int) () from /usr/lib/libQt5Core.so.5
#14 0xb69d4f74 in ?? () from /usr/lib/libQt5Core.so.5
#15 0xb55bca1e in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#16 0xb55beafa in ?? () from /usr/lib/libglib-2.0.so.0
#17 0xb55beb46 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#18 0xb69d44bb in QEventDispatcherGlib::processEvents(QFlags) ()
--Type  for more, q to quit, c to continue without paging--
   from /usr/lib/libQt5Core.so.5
#19 0xb6978ff6 in QEventLoop::exec(QFlags) () from /usr/lib/libQt5Core.so.5
#20 0xb698188b in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#21 0x004ed3d0 in main ()

There seems to be a problem around Javascript and Qt5

Andreas Baumann https://bugs.archlinux32.org/:62
FS#61: dmd fails to build with evalu8.d:function evalu8(elem*, unsigned int): error: undefined reference to 2019-01-31T15:34:53Z 2019-01-31T15:34:53Z

From the discusison in:

https://forum.dlang.org/thread/dsrjmpnavxqsjqmlvotf@forum.dlang.org

Well the problem is that the mangling produced by g++ is _Z7_moduloee but the mangling produced with ldc 1.13.0 on my environment is _Z7_moduloeS_ .
The first is a valid mangling according to some online demanglers but the last one isn't.
I then tried to compile evalu8 [1] with ldc 1.11.0 and dmd 2.081.2 and they both produced the correct name mangling.

The mangling is done by LDC itself, not LLVM, and so it is a bug in LDC. In this particular case, the second argument of _modulo is the same as the first and the mangler is (incorrectly) replacing the type of the second with a backreference to the first type. That's what the mangler should do for user types, but not for builtin types.

They reference to:

https://github.com/ldc-developers/ldc/issues/2954

Andreas Baumann https://bugs.archlinux32.org/:61
FS#60: lightdm gtk greeter fails 2019-01-20T16:04:15Z 2019-01-10T11:55:51Z
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)

Andreas Baumann https://bugs.archlinux32.org/:60
FS#59: unison segfault 2019-01-10T14:15:43Z 2019-01-10T08:29:02Z

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 ()
Andreas Baumann https://bugs.archlinux32.org/:59
FS#58: texlive-bin doesn't build 2018-12-22T07:16:59Z 2018-12-20T09:24:44Z
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
Andreas Baumann https://bugs.archlinux32.org/:58
FS#57: libc fails on AMD-K6 2019-01-31T13:50:02Z 2018-11-15T10:11:26Z

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.

Andreas Baumann https://bugs.archlinux32.org/:57
FS#56: libreoffice-fresh 6.1.3-1.0 in [extra] is not build against packages in it 2018-11-14T18:05:17Z 2018-11-11T18:14:01Z

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

Raphael Scholer https://bugs.archlinux32.org/:56
FS#55: protobuf 3.6.0 needs pushing from testing to stable 2018-10-28T18:03:16Z 2018-10-28T17:30:25Z

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.

Levi https://bugs.archlinux32.org/:55
FS#54: [pam] links against libaudit, but doesn't declare a dependency on [audit] 2018-10-09T15:47:30Z 2018-10-09T15:47:30Z

Both core/pam 1.3.1-1.2 and staging/pam 1.3.1-1.3 have their libpam.so link against libaudit:

$ readelf --dynamic /usr/lib/libpam.so.0.84.2 

Dynamic section at offset 0xfdbc contains 27 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libaudit.so.1]
…

However, the package does not declare depends=(audit) (’audit’ is the package that contains libaudit.so).

This is normally a fairly invisible mistake because recent versions of systemd depend on audit, so systemd-users (i.e. most users) will have audit installed anyway.

This affects `su` (of util-linux) and `sudo` (of sudo), which both link against libpam.

Luke Shumaker https://bugs.archlinux32.org/:54