=⇒ ERROR: Failure while downloading https://cgit.kde.org/trojita.git/patch/?id=cf2364b8

SHA1 in https://anongit.kde.org/trojita):

cf2364b80fa8ae844df8350cd5833d47cce235f2

    Fix possible crash when downloading attachments

Yep, promising, lets download the patch and add it to the package.

Original bug: https://bugs.kde.org/show_bug.cgi?id=417697

–

/build/trojita/src/trojita-0.7/src/Gui/Window.cpp:981:26: error: aggregate ‘QPainterPath path’ has incomplete type and cannot be defined
  981 |             QPainterPath path;
      |                          ^~~~

needs a #include <QPainterPath>

Reported as https://bugs.kde.org/show_bug.cgi?id=432827

Since the uprgade to python from testing, weechat has broken it’s python support, which at least knocks out the plugin I use to keep in touch with my old workmates over slack.

# weechat
|   ___       __         ______________        _____ 
|   __ |     / /___________  ____/__  /_______ __  /_
|   __ | /| / /_  _ \  _ \  /    __  __ \  __ `/  __/
|   __ |/ |/ / /  __/  __/ /___  _  / / / /_/ // /_  
|   ____/|__/  \___/\___/\____/  /_/ /_/\__,_/ \__/  
| WeeChat 2.6 [compiled on Nov 12 2019 13:06:27]
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| Error: unable to load plugin "/usr/lib/weechat/plugins/python.so": libpython3.7m.so.1.0: cannot open shared object file:
| No such file or directory

Inside /usr/lib/weechat/plugins there is a file named python.so, but its not any kind of link. I expect it to be fixed up if it were to be rebuilt.

Attached to Project: Archlinux32
Opened by Andreas Baumann - 25.05.2018
Last edited by Andreas Baumann - 18.06.2018
 FS#38  - Using SDDM, X and LXDE segfaults and logs automatically out

May 25 08:01:07 arch32-testing systemd-coredump[4620]: Process 4326 (X) of user 0 dumped core.

                                                     
                                                     Stack trace of thread 4326:
                                                     #0  0x00000000b7f64d21 __kernel_vsyscall (linux-ga

te.so.1)

                                                     #1  0x00000000b7d835e2 raise (libc.so.6)
                                                     #2  0x00000000b7d84a61 abort (libc.so.6)
                                                     #3  0x000000000052e5b5 OsAbort (Xorg)
                                                     #4  0x000000000052e632 FatalError (Xorg)
                                                     #5  0x00000000005cd9da n/a (Xorg)
                                                     #6  0x00000000b7f64d38 __kernel_rt_sigreturn (linux-gate.so.1)
                                                     #7  0x00000000b6ed12ca n/a (n/a)

The question is: is this a generic problem of new Xorg? Or just in combination with a specific window
manager, sound system, login manager?
Closed by Andreas Baumann
18.06.2018 11:51
Reason for closing: Duplicate
Additional comments about closing:

Diplicate of FS32#39

  Comments (3)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 25.05.2018 06:14

Ok, happens also without login manager, without sound manager, with startx and notion (wm).
So, this seems to be an internal xorg bug (or we have sort of a mixup in X libraries).
Admin
Andreas Baumann commented on 25.05.2018 06:19

Xorg.log says:

[ 1061.212] (EE) Backtrace:
[ 1061.212] (EE) 0: /usr/bin/X (xorg_backtrace+0×52) [0x68a862]
[ 1061.213] (EE) 1: /usr/bin/X (0x4f5000+0×195992) [0x68a992]
[ 1061.213] (EE) 2: linux-gate.so.1 (__kernel_rt_sigreturn+0×0) [0xb7f83d38]
[ 1061.213] (EE) 3: ?? [0xb6ef02ca]
[ 1061.215] (EE) 4: /usr/lib/dri/kms_swrast_dri.so (0xb5fbc000+0xc069f) [0xb607c69f]
[ 1061.215] (EE)
[ 1061.215] (EE) Segmentation fault at address 0x2103a0
[ 1061.215] (EE)
Fatal server error:
[ 1061.215] (EE) Caught signal 11 (Segmentation fault). Server aborting

Admin
Andreas Baumann commented on 25.05.2018 06:21

Ok, this is inside a virtual box with vesa video driver.

Google Cache

Attached to Project: Archlinux32
Opened by Levi - 19.08.2018
Last edited by Erich Eckner - 24.09.2018
 FS#48  - Testing repo missing a new version of python-six

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
&gt; … &gt; 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.
Closed by Erich Eckner
24.09.2018 08:45
Reason for closing: Fixed

  Comments (2)
  Related Tasks (0/0)

Admin
Erich Eckner commented on 20.08.2018 04:26

python-six-1.11.0-3.0 in [staging] is made for python 3.7

The issue is known, (internally) documented and won’t be fixed within the next weeks, but hopefully I have time to look into this after my holidays.
Levi commented on 27.08.2018 16:39

Thanks, I see this is available in the testing repo already, and I’ve just tested it. I don’t seem to have rights to comment and close (or perhaps this bug needs to be further progressed before that become available, I dunno), but I’ve tried to reproduce this after upgrading, and it now works for me, so I can confirm that I consider this issue resolved and closed, unless you want to keep it open as a note that I don’t think this has been pushed through the the mainline repos yet, while python 3.7 is there already.

Powered by Flyspray

Google Cache

I tried to get encrypted swap following the guide in the wiki.

However, ultimately,

/usr/lib/systemd/systemd-cryptsetup attach 'swap' '/dev/disk/by-uuid/13b0e159-8573-40f8-a308-b34f1bbf1a6f' '/dev/urandom' 'swap,offset=2048'

fails, which works on upstream archlinux. It gives:

Set cipher aes, mode cbc-essiv:sha256, key size 256 bits for device /dev/disk/by-uuid/13b0e159-8573-40f8-a308-b34f1bbf1a6f.
device-mapper: reload ioctl on   failed: No such file or directory
Failed to activate with key file '/dev/urandom'. (Key file missing?)
Please enter passphrase for disk Ultra_Line (swap): 
Loading of cryptographic parameters failed: Invalid argument

In the middle, it asks for a passphrase. On archlinux, the output is:

Set cipher aes, mode cbc-essiv:sha256, key size 256 bits for device /dev/loop0.

are we missing ciphers here somewhere (where?)?

As usual (for my boxes), everything is up-to-date on that machine:
cryptsetup 2.2.2-1.0
linux 5.1.15.arch1-1.0
systemd 243.162-2.0

Cheers,
Erich

Attached to Project: Archlinux32
Opened by Andreas Baumann - 01.02.2019
Last edited by Andreas Baumann - 12.05.2019
 FS#62  - sddm-greeter aborts

(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&amp;, 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 Comments (1)
Related Tasks (0/0) Admin
Andreas Baumann commented on 12.05.2019 18:25 New bug on pentium4:
Stack trace of thread 387:
#0 0x00000000b7fa8841 kernel_vsyscall (linux-gate.so.1)

         #1  0x00000000b63311b6 raise (libc.so.6)
         #2  0x00000000b631b1e3 abort (libc.so.6)
         #3  0x00000000b66b2773 _ZNK14QMessageLogger5fatalEPKcz (libQt5Core.so.5)
         #4  0x00000000b7b98592 _ZN13QSGRenderLoop28handleContextCreationFailureEP12QQuickWindowb (libQt5Quick.so.5)
         #5  0x00000000b7b99a1d n/a (libQt5Quick.so.5)
         #6  0x00000000b7b9a35b n/a (libQt5Quick.so.5)
         #7  0x00000000b6c95427 _ZN7QWindow5eventEP6QEvent (libQt5Gui.so.5)
         #8  0x00000000b7c22c60 _ZN12QQuickWindow5eventEP6QEvent (libQt5Quick.so.5)
         #9  0x00000000b68a8845 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5)
         #10 0x00000000b6c898ab _ZN22QGuiApplicationPrivate18processExposeEventEPN29QWindowSystemInterfacePrivate11ExposeEventE (libQt5Gui.so.5)
         #11 0x00000000b6c89bda _ZN22QGuiApplicationPrivate24processWindowSystemEventEPN29QWindowSystemInterfacePrivate17WindowSystemEventE (libQt5Gui.so.5)
         #12 0x00000000b6c5e085 _ZN22QWindowSystemInterface22sendWindowSystemEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Gui.so.5)
         #13 0x00000000b0b7631d n/a (libQt5XcbQpa.so.5)
         #14 0x00000000b54ddb1e g_main_context_dispatch (libglib-2.0.so.0)
         #15 0x00000000b54dfbfa n/a (libglib-2.0.so.0)
         #16 0x00000000b54dfc46 g_main_context_iteration (libglib-2.0.so.0)
         #17 0x00000000b690172b _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)
         #18 0x00000000b68a72d6 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5)
         #19 0x00000000b68af8db _ZN16QCoreApplication4execEv (libQt5Core.so.5)
         #20 0x00000000004a4330 main (sddm-greeter)
         #21 0x00000000b631c669 __libc_start_main (libc.so.6)
         #22 0x00000000004a4635 _start (sddm-greeter)
         
         Stack trace of thread 388:
         #0  0x00000000b7fa8841 __kernel_vsyscall (linux-gate.so.1)
         #1  0x00000000b63e0ed3 __poll (libc.so.6)
         #2  0x00000000b7a236ce n/a (libxcb.so.1)
         #3  0x00000000b7a25864 xcb_wait_for_event (libxcb.so.1)
         #4  0x00000000b0b751ea n/a (libQt5XcbQpa.so.5)
         #5  0x00000000b66f39e0 n/a (libQt5Core.so.5)
         #6  0x00000000b620dab2 start_thread (libpthread.so.0)
         #7  0x00000000b63ea96a __clone (libc.so.6)
         
         Stack trace of thread 389:
         #0  0x00000000b7fa8841 __kernel_vsyscall (linux-gate.so.1)
         #1  0x00000000b63e0ed3 __poll (libc.so.6)
         #2  0x00000000b54dfb55 n/a (libglib-2.0.so.0)
         #3  0x00000000b54dfc46 g_main_context_iteration (libglib-2.0.so.0)
         #4  0x00000000b690172b _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)
         #5  0x00000000b68a72d6 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5)
         #6  0x00000000b66f2412 _ZN7QThread4execEv (libQt5Core.so.5)
         #7  0x00000000b0a20cdd n/a (libQt5DBus.so.5)
         #8  0x00000000b66f39e0 n/a (libQt5Core.so.5)
         #9  0x00000000b620dab2 start_thread (libpthread.so.0)
         #10 0x00000000b63ea96a __clone (libc.so.6)
         
         Stack trace of thread 391:
         #0  0x00000000b7fa8841 __kernel_vsyscall (linux-gate.so.1)
         #1  0x00000000b63e0ed3 __poll (libc.so.6)
         #2  0x00000000b54dfb55 n/a (libglib-2.0.so.0)
         #3  0x00000000b54dfc46 g_main_context_iteration (libglib-2.0.so.0)
         #4  0x00000000b690172b _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)
         #5  0x00000000b68a72d6 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5)
         #6  0x00000000b66f2412 _ZN7QThread4execEv (libQt5Core.so.5)
         #7  0x00000000b77189c3 n/a (libQt5Qml.so.5)
         #8  0x00000000b66f39e0 n/a (libQt5Core.so.5)
         #9  0x00000000b620dab2 start_thread (libpthread.so.0)
         #10 0x00000000b63ea96a __clone (libc.so.6)

Google Cache

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

~]$ libreoffice
javaldx: Could not find a Java Runtime Environment!
Warning: failed to read path from javaldx
/usr/lib/libreoffice/program/soffice.bin: error while loading shared libraries: libboost_locale.so.1.75.0: cannot open shared object file: No such file or directory

Attached to Project: Archlinux32
Opened by Andreas Baumann - 05.04.2018
Last edited by Andreas Baumann - 11.04.2018
 FS#33  - [icu] sobump mismatch

For instance:

[quote]
shell&gt; kwin_x11
kwin_x11: error while loading shared libraries: libicui18n.so.60: cannot open shared object file: No such file or directory
[/quote]

Seen similar on ArchlinuxARM, so I guess it’s an undetected SO-bump from upstream..
Closed by Andreas Baumann
11.04.2018 16:47
Reason for closing: Fixed
Additional comments about closing:

Actually, also gdal is fine on staging.

  Comments (1)
  Related Tasks (0/0)

Admin
Erich Eckner commented on 11.04.2018 11:59

I can only see gdal being still wrongly linked against icu-60 in testing or staging - can you confirm?

Google Cache

$ cc –version
cc: CPU ISA level is lower than required

The same happens in a chroot for [staging].

$ pacman -Qo /usr/bin/cc
/usr/bin/cc is owned by gcc 10.2.0-6.0

$ pacman -Q glibc
glibc 2.33-4.0

Does that mean, anything building with gcc is doomed on i686, currently?

Hi!

I just mentioned that exim stopped sending me emails… So I just upgraded to the package in community-testing… And now exim sends me emails, that complain about things like this:
“warning: exim: local (4.95-2.0) is newer than community (4.95-1.0)”

Is there a reason, that the fresh package is being tested since a month now?

Thx.

Bye.

Attached to Project: Archlinux32
Opened by Andreas Baumann - 13.06.2018
Last edited by Andreas Baumann - 13.09.2018
 FS#39  - xorg modesetting module fails with illegal instruction

[ 22.717] (EE) Illegal instruction at address 0xb632cd37
[ 22.718] (EE)
Fatal server error:
[ 22.718] (EE) Caught signal 4 (Illegal instruction). Server aborting
[ 22.719] (EE)

               PID: 242 (Xorg)
         UID: 0 (root)
         GID: 0 (root)
      Signal: 6 (ABRT)
   Timestamp: Wed 2018-06-13 20:53:43 CEST (41s ago)
Command Line: /usr/lib/Xorg :0
  Executable: /usr/lib/Xorg

Control Group: /user.slice/user-0.slice/session-c1.scope

        Unit: session-c1.scope
       Slice: user-0.slice
     Session: c1
   Owner UID: 0 (root)
     Boot ID: ea12301d13874fac8112dad7bf566bdb
  Machine ID: 2f98089cbe8d40cb8776a580d6803b58
    Hostname: arch32-staging
     Storage: /var/lib/systemd/coredump/core.Xorg.0.ea12301d13874fac8112dad7bf566bdb.242.1528916023000>
     Message: Process 242 (Xorg) of user 0 dumped core.
              
              Stack trace of thread 242:
              #0  0x00000000b7f58d21 __kernel_vsyscall (linux-gate.so.1)
              #1  0x00000000b7d749c2 raise (libc.so.6)
              #2  0x00000000b7d5e71e abort (libc.so.6)
              #3  0x000000000056b555 OsAbort (Xorg)
              #4  0x000000000056b5d2 FatalError (Xorg)
              #5  0x000000000060a93a n/a (Xorg)
              #6  0x00000000b7f58d38 __kernel_rt_sigreturn (linux-gate.so.1)
              #7  0x00000000b632cd37 n/a (kms_swrast_dri.so)
              #8  0x00000000b5f0181f n/a (kms_swrast_dri.so)
              #9  0x00000000b7f698b3 call_init.part.0 (ld-linux.so.2)
              #10 0x00000000b7f699b2 _dl_init (ld-linux.so.2)
              #11 0x00000000b7f6d7e0 dl_open_worker (ld-linux.so.2)
              #12 0x00000000b7e7bc91 _dl_catch_exception (libc.so.6)
              #13 0x00000000b7f6d077 _dl_open (ld-linux.so.2)
              #14 0x00000000b7b8cb73 n/a (libdl.so.2)
              #15 0x00000000b7e7bc91 _dl_catch_exception (libc.so.6)
              #16 0x00000000b7e7bd40 _dl_catch_error (libc.so.6)
              #17 0x00000000b7b8d333 n/a (libdl.so.2)
              #18 0x00000000b7b8cc16 dlopen (libdl.so.2)
              #19 0x00000000b7f2eb6e n/a (libgbm.so.1)
              #20 0x00000000b7f2ecb3 n/a (libgbm.so.1)
              #21 0x00000000b7f2ee24 n/a (libgbm.so.1)
              #22 0x00000000b7f2f0d7 n/a (libgbm.so.1)
              #23 0x00000000b7f2c9ba gbm_create_device (libgbm.so.1)
              #24 0x00000000b6ef4ee4 glamor_egl_init (libglamoregl.so)
              #25 0x00000000b7f49b4a n/a (modesetting_drv.so)
              #26 0x000000000051c169 InitOutput (Xorg)
              #27 0x000000000049d8e1 n/a (Xorg)
              #28 0x00000000b7d60041 __libc_start_main (libc.so.6)
              #29 0x000000000049e7e2 _start (Xorg)

  Comments (7)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 14.06.2018 15:53

#0 0xb7f3ad21 in kernel_vsyscall () [-
#1 0xb7d579c2 in raise () from /usr/lib/libc.so.6
#2 0xb7d4171e in abort () from /usr/lib/libc.so.6
#3 0x005855f5 in OsAbort () at ../xorg-server-1.20.0/os/utils.c:1350
#4 0×00585672 in AbortServer () at ../xorg-server-1.20.0/os/log.c:877
#4 0×00585672 in AbortServer () at ../xorg-server-1.20.0/os/log.c:877
#5 FatalError (f=0x65e1bc “Caught signal %d (%s). Server aborting\n”)
at ../xorg-server-1.20.0/os/log.c:1015
#6 0x00624b5a in OsSigHandler (signo=, sip=, unused=,
signo=, sip=, unused at ../xorg-server-1.20.0/os/osinit.c:156
#7
#8 0xb62d5d37 in SwrJit::X86Intrinsic::X86Intrinsic (this=0xbf955e24)
at ../mesa-18.1.1/src/gallium/drivers/swr/rasterizer/jitter/functionpasses/lower_x86.cpp:66
#9 std::pair, std::allocator &gt; const, SwrJit::X86Intrinsic&gt;::pair (this=0xbf955e0c, x=…, y=…)
at /usr/include/c++/8.1.1/bits/stl_pair.h:301
#10 0xb5eaa81f in static_initialization_and_destruction_0(int, int) [clone .constprop.236] ()

  at /usr/include/c++/8.1.1/new:169

#11 0xb7f4b8b3 in call_init.part () from /lib/ld-linux.so.2
#12 0xb7f4b9b2 in _dl_init () from /lib/ld-linux.so.2
#13 0xb7f4f7e0 in dl_open_worker () from /lib/ld-linux.so.2
#14 0xb7e5ec91 in _dl_catch_exception () from /usr/lib/libc.so.6
#15 0xb7f4f077 in _dl_open () from /lib/ld-linux.so.2
#16 0xb7b6fb73 in ?? () from /usr/lib/libdl.so.2
#17 0xb7e5ec91 in _dl_catch_exception () from /usr/lib/libc.so.6
#18 0xb7e5ed40 in _dl_catch_error () from /usr/lib/libc.so.6
—Type to continue, or q to quit— #19 0xb7b70333 in ?? () from /usr/lib/libdl.so.2
#20 0xb7b6fc16 in dlopen () from /usr/lib/libdl.so.2
#21 0xb7f10b6e in dri_open_driver (dri=, dri

  at ../mesa-18.1.1/src/gbm/backends/dri/gbm_dri.c:354

#22 0xb7f10cb3 in dri_load_driver (dri=0x17e9660) at ../mesa-18.1.1/src/gbm/backends/dri/gbm_dri.c:439
#23 dri_screen_create_dri2 (dri=dri@entry=0x17e9660, driver_name

  at ../mesa-18.1.1/src/gbm/backends/dri/gbm_dri.c:439

#24 0xb7f10e24 in dri_screen_create_sw (dri=0x17e9660)

  at ../mesa-18.1.1/src/gbm/backends/dri/gbm_dri.c:539

#25 0xb7f110d7 in dri_device_create (fd=13) at ../mesa-18.1.1/src/gbm/backends/dri/gbm_dri.c:1429
#26 0xb7f0e9ba in gbm_create_device (fd=13) at ../mesa-18.1.1/src/gbm/main/gbm.c:137
#27 0xb6ebaee4 in glamor_egl_init (scrn=0x17e83a0, fd=13)

  at ../xorg-server-1.20.0/glamor/glamor_egl.c:894

#28 0xb7f2bb4a in try_enable_glamor (pScrn=0x17e83a0)

  at ../xorg-server-1.20.0/hw/xfree86/drivers/modesetting/driver.c:753

#29 PreInit (pScrn=, flags

  at ../xorg-server-1.20.0/hw/xfree86/drivers/modesetting/driver.c:972

#30 0×00536209 in InitOutput (pScreenInfo=0x6fd520 , argc=6, argv=0xbf957944)

  at ../xorg-server-1.20.0/hw/xfree86/common/xf86Init.c:536

#31 0x004b7991 in dix_main (envp=, argv=, argc

  at ../xorg-server-1.20.0/dix/main.c:193

#32 main (argc=, argv=, envp

  at ../xorg-server-1.20.0/dix/stubmain.c:34

=&gt; 0xb62d5d37 &lt;+71&gt;: vmovq -0×20(%ebp),%xmm0

 0xb62d5d3c <+76>:    vmovq  %xmm0,0x18(%esi)

Looks like AVX optimized code in libswr though I’m deleting -D swr-arches=avx,avx2 in
the diff-PKGBUILD (maybe wrongly)?
Admin
Andreas Baumann commented on 14.06.2018 17:55

So, I read OpenSWR requires at least AVX, so we can safely drop the library for 32-bit
machines, right?

So removing swr from the gallium-drivers, then I get croaks about gallium-nine requiring
a pipe.

I’ll continue to drop options in arch-meson in PKGBUILD till I get a working build..

Any help welcome. Admin
Andreas Baumann commented on 14.06.2018 18:13

Some docu:

  http://openswr.org/build-linux.html
  https://www.mesa3d.org/envvars.html
  https://www.felixcloutier.com/x86/MOVQ.html

Trying the following patch at the moment:

eval “$(

declare -f build | \
  sed '
    /-D gallium-drivers=/s/,swr//g
    s/-D swr-arches=avx,avx2//g
    /gallium-drivers/s/,swr//g
    s/-D gallium-nine=true/-D gallium-nine=false/g
    s/-D osmesa=gallium/-D osmesa=classic/g
    s/dri-drivers=/dri-drivers=swrast,/g
  '

)”

Admin
Erich Eckner commented on 14.06.2018 20:54

only glitch I see with your fix is, that the options are in one line in `declare -f build`, so the line-matching makes no sense
Admin
Andreas Baumann commented on 15.06.2018 06:07

one line? It should actually be one line each and it worked for me? *puzzle*
Admin
Andreas Baumann commented on 15.06.2018 08:55

This seems to work. But I’m disabling and changing an awful lot of stuff:

# disable AVX/AVX2 in openswf, makes no sense with old CPUs
eval “$(

declare -f build | \
  sed '
    /-D gallium-drivers=/s/,swr//g
    s/-D swr-arches=avx,avx2//g
    /gallium-drivers/s/,swr//g
    s/-D gallium-nine=true/-D gallium-nine=false/g
    s/-D osmesa=gallium/-D osmesa=classic/g
    s/dri-drivers=/dri-drivers=swrast,/g
  '
declare -f package_mesa | \
  sed '
    s@_install fakeinstall/usr/lib/d3d@#\0@g
    s@_install fakeinstall/usr/lib/libswrAVX.*@#\0@g
  '

)”

Admin
Andreas Baumann commented on 13.09.2018 08:34

Fails again with (mesa 18.1.8 on testing):

Program received signal SIGILL, Illegal instruction.
0xb627e167 in ?? () from /usr/lib/dri/kms_swrast_dri.so
=&gt; 0xb627e167: c5 fa 7e 45 e0 vmovq -0×20(%ebp),%xmm0

Google Cache

Bing Cache

Attached to Project: Archlinux32
Opened by Andreas Baumann - 16.05.2019
 FS#74  - webkit2gtk requires SSE2

– Performing Test HAVE_SSE2_EXTENSIONS
– Performing Test HAVE_SSE2_EXTENSIONS - Failed
CMake Error at CMakeLists.txt:115 (message):

SSE2 support is required to compile WebKit

not quite clear yet, what happens, if it gets disabled forcefully..

  Comments (5)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 16.05.2019 18:43

Let’s see, what happens if we just comment out the SSE2 test in CMakeLists.txt.. Admin
Andreas Baumann commented on 17.05.2019 11:54

Rebuilding runs in issues like:

make[2]: *** No rule to make target ‘JavaScriptCore-4.0.gir’, needed by ‘WebKit2-4.0.gir’. Stop.

Using in ‘build’ make JavaScriptCore-4-gir VERBOSE=1 reveils the true nature of the bug:

/usr/lib/gcc/i686-pc-linux-gnu/8.3.0/include/stddef.h:435: syntax error, unexpected identifier in ' float128 max_align_f128 attribute1)));’ at ‘__float128’

So again, the 128-bit alignment hack in glibc spreading everywhere.
Admin
Andreas Baumann commented on 17.05.2019 11:56

Also the make error sounds suspicious, like cmake/make generated files are not really tested.
Admin
Andreas Baumann commented on 17.05.2019 11:59

The 128-alignment issue is hopefully just a warning..
Admin
Andreas Baumann commented on 17.05.2019 12:55

patched build in the queue..

Google Cache

Attached to Project: Archlinux32
Opened by Andreas Baumann - 06.07.2019
Last edited by Andreas Baumann - 11.08.2019
 FS#79  - trojita libstdc++ ABI mismatch

trojita
trojita: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.26’ not found (required by /usr/lib/libQt5WebKit.so.5)
Closed by Andreas Baumann
11.08.2019 06:01
Reason for closing: Not a bug
Additional comments about closing:

Temporary glitch, glibc got published, trojita didn’t get rebuild.

  Comments (1)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 06.07.2019 09:17

This goes into the same ABI mismatches as Qt5. The problem here is: qt5-webkit refuses
to build on machines without SSE2 currently, but glibc is supposed to be backwards compatible,
but not libstdc++).

Google Cache

07.11.2017 -  FS#2  - this is a test-issue for [lapack] (not a real bug). human: ignore this build master: do not ignore this. Closed by Erich Eckner 07.11.2017 …

Attached to Project: Archlinux32
Opened by Erling Hellenäs - 05.07.2019
 FS#78  - The qt5 group contains packages of different versions.

The qt5 group contains a qt5-base which is of a later revision, 5.12.4 instead of 5.12.3. pyside2 is also of a this later revision, but I don’t use it. I guess the group should be fixed.

Workaround: I downgraded qt5-base and it is working again.

I get this error: sddm-greeter[441]: Cannot mix incompatible Qt library (version 0x50c03) with this library (version 0x50c04)
Then systemd dumps core.

Excerpt from my journal: External Link

The group definition as seen when installing the group with pacman: External Link

My architecture is i686.

I consider it critical since QT is not working.

Google Cache

22.12.2018 - 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 …

Attached to Project: Archlinux32
Opened by Andreas Baumann - 12.04.2018
Last edited by Andreas Baumann - 13.04.2018
 FS#35  - texlive errors while installing (missing icu 60)

(16/19) Updating TeXLive format files… xetex: error while loading shared libraries: libicuuc.so.60: cannot open shared object file: No such file or directory
xetex: error while loading shared libraries: libicuuc.so.60: cannot open shared object file: No such file or directory
xetex: error while loading shared libraries: libicuuc.so.60: cannot open shared object file: No such file or directory
xetex: error while loading shared libraries: libicuuc.so.60: cannot open shared object file: No such file or directory
fmtutil [ERROR]: running `xetex -ini -jobname=xetex -progname=xetex -etex xetex.ini /null’ return status 127
fmtutil [ERROR]: return error due to options –strict
fmtutil [ERROR]: running `xetex -ini -jobname=cont-en -progname=context -8bit *cont-en.mkii /null’ return status 127
fmtutil [ERROR]: return error due to options –strict
fmtutil [ERROR]: running `xetex -ini -jobname=pdfcsplain -progname=pdfcsplain -etex csplain.ini /null’ return status 127
fmtutil [ERROR]: return error due to options –strict
fmtutil [ERROR]: running `xetex -ini -jobname=xelatex -progname=xelatex -etex xelatex.ini /null’ return status 127
fmtutil [ERROR]: return error due to options –strict
error: command failed to execute correctly
(17/19) Updating TeXLive font maps… (18/19) Updating the desktop file MIME type cache… (19/19) Updating the MIME type database…

Not had the time to actually test TexLive, it may work despite the errors.

An ldd on texlive-bin shows me:

/usr/bin/upmendex:

      linux-gate.so.1 (0xb7f53000)
      libkpathsea.so.6 => /usr/lib/libkpathsea.so.6 (0xb7ee9000)
      libicui18n.so.60 => not found
      libicuuc.so.60 => not found
      libc.so.6 => /usr/lib/libc.so.6 (0xb7d14000)
      /lib/ld-linux.so.2 => /usr/lib/ld-linux.so.2 (0xb7f55000)

/usr/bin/xelatex:

      linux-gate.so.1 (0xb7f36000)
      libharfbuzz-icu.so.0 => /usr/lib/libharfbuzz-icu.so.0 (0xb7b42000)
      libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0xb7a85000)
      libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0xb7a55000)
      libicuuc.so.60 => not found
      libpthread.so.0 => /usr/lib/libpthread.so.0 (0xb7a36000)
      libpoppler.so.72 => /usr/lib/libpoppler.so.72 (0xb77c0000)

/usr/bin/xetex:

      linux-gate.so.1 (0xb7f0e000)
      libharfbuzz-icu.so.0 => /usr/lib/libharfbuzz-icu.so.0 (0xb7b1a000)
      libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0xb7a5d000)
      libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0xb7a2d000)
      libicuuc.so.60 => not found

So a rebuild of texlive is maybe an option?
Closed by Andreas Baumann
13.04.2018 08:07
Reason for closing: Fixed
Additional comments about closing:

Linked against icu.61 now. Ok.

  Comments (1)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 13.04.2018 08:07

PANIC: unprotected error in call to Lua API (CPU with SSE2 required).
Lua also seems to go the way of all interpreters with micro-optimizations everywhere.

Google Cache

Telegram Desktop fails to start with an error about incompatible Qt libraries, I think it needs to be rebuilt.

icu69.1-1.0 however snapper still links against libicuuc.so.68

Running snapper now gives the following error:

# snapper list /
snapper: error while loading shared libraries: libicuuc.so.68: cannot open shared object file: No such file or directory

Attached to Project: Archlinux32
Opened by Levi - 26.07.2018
Last edited by Erich Eckner - 27.07.2018
 FS#47  - rankmirrors $repo guessing broken in i686 only

I usually use rankmirrors on my mirrorlist prior to installing them fully to sort them such that the quickest mirrors are listed first.

I found that when using them to sort my mirrorlist.pacnew, it would claim each server target was unreachable, and reproduce them in their original order, making the tool rather useless.
Workaround

I also discovered that I can work around the problem by passing an argument of ‘-r core’ to the invocation, e.g. ‘$ rankmirrors -r core /etc/pacman.d/mirrorlist.pacnew &gt; mirrorlist.temp’
Steps to reproduce

  rankmirrors -t /etc/pacman.d/mirrorlist.pacnew

This -t option prints out the timings, or unreachable if it failed to create a valid uri.
Investigation

My investigations thus far show that /usr/bin/rankmirrors is a bash script, and it looks like the if statement starting on line 79 in the current version (the first if statement in the getfetchurl function) is designed to replace the $repo string with whatever $TARGETREPO is, else ‘core’ which suggests it should work by default.

The only consistent difference in the format of the mirrorlist file between here and on my x64 machine (where rankmirrors continues to work fine) is that on x64 the repos almost all have /os before /$repo while we often have it at the root of the public filesystem, or under something other than /os.

Unfortunately the vagaries of bash string substitution are something I rarely touch and never touch again provided they continue to work, so I can’t guess why this would have stopped working for us. If I have time to dig further I’ll comment here though, of course.
Closed by Erich Eckner
27.07.2018 04:22
Reason for closing: Fixed
Additional comments about closing:

note, that this deliberately does not work with upstream’s mirror layout

  Comments (2)
  Related Tasks (0/0)

Admin
Erich Eckner commented on 26.07.2018 19:13

ok, I just checked - with my mirrorlist, it works (this is not the default mirrorlist) - so I suspect, it breaks due to our format of the urls ($root/$arch/$repo instead of $root/$repo/os/$arch) - I’ll look into this
Admin
Erich Eckner commented on 26.07.2018 19:38

I think, I fixed it - let’s see if it “compiles” and runs

Google Cache

The quazip-qt5 package for both i686 and pentium4 contains the Qt6 libraries instead of the Qt5 ones.

The quazip package also no longer seems to exist upstream and should probably be removed in Arch32 as well.

Came across this after completing a system update two days ago.

I run Radicale and that is refusing to start with the following error:

Traceback (most recent call last):
  File "/usr/bin/radicale", line 6, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 84, in <module>
    __import__('packaging.requirements')
  File "/usr/lib/python3.7/site-packages/packaging/requirements.py", line 9, in <module>
    from pyparsing import stringStart, stringEnd, originalTextFor, ParseException
ModuleNotFoundError: No module named 'pyparsing'

When attempting to run pip to see if that might correct the issue, I got the following error:

Traceback (most recent call last):
  File "/usr/bin/pip", line 6, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 84, in <module>
    __import__('packaging.requirements')
  File "/usr/lib/python3.7/site-packages/packaging/requirements.py", line 9, in <module>
    from pyparsing import stringStart, stringEnd, originalTextFor, ParseException
ModuleNotFoundError: No module named 'pyparsing'

It looks as though something recently broke pyparsing and that’s had a knockon effect for a few packages.

# pandoc --version
pandoc: error while loading shared libraries: libHSzip-archive-0.4.1-4yLWnBS0zifKkvfHVbmUo1-ghc8.10.2.so: cannot open shared object file: No such file or directory
<code>

Versions:
<code>
# pacman -Q | grep haskell
haskell-aeson 1.5.4.1-19.0
haskell-aeson-pretty 0.8.8-94.0
haskell-ansi-terminal 0.11-17.0
haskell-asn1-encoding 0.9.6-58.0
haskell-asn1-parse 0.9.5-58.0
haskell-asn1-types 0.3.4-37.0
haskell-assoc 1.0.2-27.0
haskell-async 2.2.2-40.0
haskell-attoparsec 0.13.2.4-36.0
haskell-base-compat 0.11.2-4.2
haskell-base-compat-batteries 0.11.2-11.0
haskell-base-orphans 0.8.3-14.0
haskell-base16-bytestring 0.1.1.7-3.0
haskell-base64-bytestring 1.2.0.1-3.0
haskell-basement 0.0.11-10.1
haskell-bifunctors 5.5.8-13.0
haskell-blaze-builder 0.4.2.1-2.1
haskell-blaze-html 0.9.1.2-57.0
haskell-blaze-markup 0.8.2.7-41.0
haskell-byteable 0.1.1-22.1
haskell-case-insensitive 1.2.1.0-39.0
haskell-cereal 0.5.8.1-9.0
haskell-citeproc 0.3.0.9-9.0
haskell-cmdargs 0.10.21-1.0
haskell-colour 2.3.5-75.0
haskell-commonmark 0.1.1.2-2.0
haskell-commonmark-extensions 0.2.0.3-1.0
haskell-commonmark-pandoc 0.2.0.1-24.0
haskell-comonad 5.0.6-58.0
haskell-conduit 1.3.4-3.0
haskell-conduit-extra 1.3.5-70.0
haskell-connection 0.3.1-99.0
haskell-cookie 0.4.5-9.1
haskell-cryptonite 0.27-32.0
haskell-data-default 0.7.1.1-87.0
haskell-data-default-class 0.1.2.0-21.1
haskell-data-default-instances-containers 0.0.1-33.1
haskell-data-default-instances-dlist 0.0.1-100.0
haskell-data-default-instances-old-locale 0.0.1-33.1
haskell-data-fix 0.3.0-35.0
haskell-digest 0.0.1.2-22.1
haskell-distributive 0.6.2-40.0
haskell-dlist 1.0-23.0
haskell-doclayout 0.3-45.0
haskell-doctemplates 0.9-40.0
haskell-emojis 0.1-47.0
haskell-erf 2.0.0.0-21.0
haskell-errors 2.3.0-59.1
haskell-file-embed 0.0.13.0-3.1
haskell-glob 0.10.1-28.0
haskell-haddock-library 1.9.0-58.0
haskell-hashable 1.3.0.0-36.0
haskell-hourglass 0.2.12-82.0
haskell-hslua 1.3.0-2.0
haskell-hslua-module-system 0.2.2.1-17.0
haskell-hslua-module-text 0.3.0.1-5.0
haskell-hsyaml 0.2.1.0-52.0
haskell-http 4000.3.15-49.0
haskell-http-client 0.7.6-14.0
haskell-http-client-tls 0.3.5.3-359.0
haskell-http-types 0.12.3-100.0
haskell-hxt 9.3.1.18-196.0
haskell-hxt-charproperties 9.5.0.0-1.0
haskell-hxt-regex-xmlschema 9.2.0.7-2.0
haskell-hxt-unicode 9.0.2.4-22.0
haskell-indexed-traversable 0.1.1-3.1
haskell-integer-logarithms 1.0.3.1-3.1
haskell-ipynb 0.1.0.1-192.0
haskell-jira-wiki-markup 1.3.2-27.0
haskell-juicypixels 3.3.5-37.0
haskell-memory 0.15.0-49.0
haskell-mime-types 0.1.0.9-11.1
haskell-mono-traversable 1.0.15.1-74.0
haskell-network 3.1.2.1-1.0
haskell-network-uri 2.6.3.0-217.0
haskell-old-locale 1.0.0.7-27.1
haskell-old-time 1.1.0.3-27.1
haskell-pandoc-types 1.22-13.0
haskell-pem 0.2.4-114.0
haskell-primitive 0.7.1.0-29.0
haskell-quickcheck 2.14.2-11.0
haskell-random 1.2.0-54.0
haskell-resourcet 1.2.4.2-31.0
haskell-safe 0.3.19-5.1
haskell-scientific 0.3.6.2-53.0
haskell-sha 1.6.4.4-16.1
haskell-skylighting 0.10.2-24.0
haskell-skylighting-core 0.10.2-24.0
haskell-socks 0.6.1-90.0
haskell-split 0.2.3.4-88.0
haskell-splitmix 0.1.0.3-5.0
haskell-streaming-commons 0.2.2.1-28.1
haskell-strict 0.4.0.1-1.0
haskell-syb 0.7.1-8.0
haskell-tagged 0.8.6.1-2.2
haskell-tagsoup 0.14.8-75.0
haskell-temporary 1.3-130.0
haskell-texmath 0.12.0.3-40.0
haskell-text-conversions 0.3.1-62.0
haskell-text-icu 0.7.0.1-37.1
haskell-th-abstraction 0.4.2.0-2.2
haskell-th-compat 0.1-12.0
haskell-these 1.1.1.1-28.0
haskell-time-compat 1.9.5-1.0
haskell-tls 1.5.5-3.0
haskell-transformers-compat 0.6.6-3.1
haskell-typed-process 0.2.6.0-63.0
haskell-unicode-transforms 0.3.7.1-42.0
haskell-uniplate 1.6.13-4.0
haskell-unliftio-core 0.2.0.1-6.1
haskell-unordered-containers 0.2.13.0-11.0
haskell-utf8-string 1.0.1.1-20.0
haskell-uuid-types 1.0.3-58.0
haskell-vector 0.12.1.2-64.0
haskell-vector-algorithms 0.8.0.4-1.0
haskell-x509 1.7.5-137.0
haskell-x509-store 1.6.7-136.0
haskell-x509-system 1.6.6-204.0
haskell-x509-validation 1.6.11-136.0
haskell-xml 1.3.14-27.2
haskell-xml-conduit 1.9.0.0-77.0
haskell-xml-types 0.3.8-5.1
haskell-zip-archive 0.4.1-66.0
haskell-zlib 0.6.2.2-4.0

/proc/cpuinfo:
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 15
model name : VIA Nano U3400@800MHz
stepping : 10
cpu MHz : 798.016
cache size : 2048 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush acpi mmx fxsr sse sse2 ss tm syscall nx lm constant_tsc arch_perfmon rep_good cpuid pni monitor vmx est tm2 ssse3 cx16 xtpr sse4_1 popcnt rng rng_en ace ace_en ace2 phe phe_en pmm pmm_en lahf_lm tpr_shadow vnmi vpid ida
vmx flags : vnmi tsc_offset vtpr
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
bogomips : 1596.53
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:

Other machine, also with via processor:

/proc/cpuinfo:
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 13
model name : VIA C7-D Processor 1800MHz
stepping : 0
cpu MHz : 1596.326
cache size : 128 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx cpuid pni est tm2 xtpr rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
bogomips : 3193.67
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 32 bits virtual
power management:

All the __builtin_cpu_supports() and __builtin_cpu_is() tests fail. Thus, pacman thinks, it’s not capable of sse2 and installs i686 packages instead of pentium4 ones.

Should we complain at gcc upstream? How does the kernel compile this line in /proc/cpuinfo? What checks does it perform?

Attached to Project: Archlinux32
Opened by Andreas Baumann - 14.09.2019
Last edited by Andreas Baumann - 14.09.2019
 FS#86  - newsboat contains SSE2 instuctions

shell&gt; newsboat

Program received signal SIGILL, Illegal instruction.
0x005f5cd9 in ?? ()
=&gt; 0x005f5cd9: f2 0f 10 06 movsd (%esi),%xmm0
(gdb) bt
#0 0x005f5cd9 in ?? ()
#1 0x005f40fa in ?? ()
#2 0x005f3f3b in ?? ()
#3 0x0072e9fd in ?? ()
#4 0×00661600 in ?? ()
#5 0×00659435 in ?? ()
#6 0x0061fe88 in ?? ()
#7 0x0065770c in ?? ()
#8 0x005ea416 in ?? ()
#9 0x0044ca68 in ?? ()
#10 0xb76f9859 in __libc_start_main () from /usr/lib/libc.so.6
#11 0x0044da75 in ?? ()

This actually looks like glibc got a SSE2 infection on i686.

Google Cache

Here’s 1:0.33.1-1.0-pentium4:

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

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

Here’s 1:0.33.1-2.0-pentium4:

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

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

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

pacman -Syu

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

grep LLVM /var/log/Xorg.0.log
[    29.423] (EE) AIGLX error: dlopen of /usr/lib/dri/r300_dri.so failed (libLLVM-8.so: cannot open shared object file: No such file or directory)
[    29.424] (EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed (libLLVM-8.so: cannot open shared object file: No such file or directory)

ldd /usr/lib/dri/r300_dri.so 
        linux-gate.so.1 (0xb7f26000)
        libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb6836000)
        libLLVM-8.so => not found
        libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb680a000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0xb6804000)
        libsensors.so.5 => /usr/lib/libsensors.so.5 (0xb67f3000)
        libdrm_radeon.so.1 => /usr/lib/libdrm_radeon.so.1 (0xb67e4000)
        libelf.so.1 => /usr/lib/libelf.so.1 (0xb67c6000)
        libdrm_amdgpu.so.1 => /usr/lib/libdrm_amdgpu.so.1 (0xb67b9000)
        libdrm_nouveau.so.2 => /usr/lib/libdrm_nouveau.so.2 (0xb67ae000)
        libglapi.so.0 => /usr/lib/libglapi.so.0 (0xb678d000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb6773000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6595000)
        libm.so.6 => /usr/lib/libm.so.6 (0xb64c3000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb64a6000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0xb6483000)
        libc.so.6 => /usr/lib/libc.so.6 (0xb62d3000)
        /usr/lib/ld-linux.so.2 (0xb7f27000)

ls /usr/lib/libLLVM*
/usr/lib/libLLVM-9.0.0.so  /usr/lib/libLLVM-9.so  /usr/lib/libLLVM.so

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

  Comments (1)
  Related Tasks (0/0)

Levi commented on 25.05.2019 18:22

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

Google Cache

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

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

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

So, getting the exact failing opcode is hard.

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

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

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

works with glibc-2.28-5.5-i486

  Comments (11)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 10.01.2019 08:27

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

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

pacstrap /test bash

Then debugging the chroot call:

gdb –args /usr/bin/chroot /test

yields:

Dump of assembler code for function memcpy:

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

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

 0xb7ff2304 <+20>:    ret    

End of assembler dump.

So, we got cmov creeping in.

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

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

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

Checking in glibc: this is the offending opcode

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

L(neq): movl $1, %eax

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

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

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

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

This breaks every build on i486!

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

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

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

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

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

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

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

The man page of setarch documents the bug:

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

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

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

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

setarch bug reported here:

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

and here:

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

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

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

The CLFS uname hack solution.

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

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

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

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

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

insmod uname_hack.ko

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

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

Google Cache

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

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

Steps to reproduce: invoking kmail on the console shows:

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

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

After all I didn’t find a solution.

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

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

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

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

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

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

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

Google Cache

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

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

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

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

Google Cache

KDE applications fail to start with the following error:

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

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

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

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

Downgrading kcmutils to 5.63.0-1.0 finally fixed dolphin.

Seen with trojita:
Cannot mix incompatible Qt library (version 0x50d02) with this library (version 0x50d01)

We need llvm 7.0 instead of 7.1.
If we muss a llvm update, bootstrapping rust fails (due to a to old libLLVM.so).
defined multiple times

1. &gt; /build/rust/src/rustc-1.34.1-src/build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-02dad87448159bce/out/consts.rs:2112:5

2110 | pub type U1024 = UInt, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;;

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

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

 |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `U1024` redefined here

https://github.com/paholg/typenum/commit/14a3322d1081fd63d5eb44bf8ab8f90676208228

Can anobody tell me, how we apply patches to downloaded artifacts while building?!

  Comments (32)
  Related Tasks (0/0)

Admin
Erich Eckner commented on 13.05.2019 04:32

&gt; Can anobody tell me, how we apply patches to downloaded artifacts while building?!

I only have a racy solutions for that. Put the following at the start of build():

while true; do
find $rust-build-dir-path -type f -name $name-to-patch -execdir patch -p1 -i $srcdir/patch \; &amp;&amp; break
done &amp;
Admin
Erich Eckner commented on 29.07.2019 09:25

trying to compile rust 1.34 with llvm-libs 7:

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

1. -&gt; /build/rust/src/rustc-1.34.0-src/build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-101079a7a9ba8c17/out/consts.rs:2112:5

|
2110 | pub type U1024 = UInt, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;;

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

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

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

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

1. -&gt; /build/rust/src/rustc-1.34.0-src/build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-101079a7a9ba8c17/out/consts.rs:2113:5

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

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

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

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

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

1. -&gt; /build/rust/src/rustc-1.34.0-src/build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-101079a7a9ba8c17/out/consts.rs:2113:35

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

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

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

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

error: aborting due to 3 previous errors

Admin
Erich Eckner commented on 29.07.2019 09:32

let’s try again with:

while true; do
  sed -i '
    2112 { /pub type U1024/ d }
    2113 { /pub type P1024/ d }
  ' build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-101079a7a9ba8c17/out/consts.rs 2>/dev/null || true
done &

injected in build() … which is the mother of all race conditions
Admin
Erich Eckner commented on 30.07.2019 08:36

current error:

error: this file contains an un-closed delimiter

1. -&gt; /build/rust/src/rustc-1.34.0-src/build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-101079a7a9ba8c17/out/consts.rs:482:56

|
54 | pub mod consts {

  |                - un-closed delimiter

… 482 | pub type U210 = UInt`, const, identifier, lifetime, or type, found `}`

1. -&gt; /build/rust/src/rustc-1.34.0-src/build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-101079a7a9ba8c17/out/consts.rs:482:55

|
482 | pub type U210 = UInt`, const, identifier, lifetime, or type here

error: aborting due to 2 previous errors

error: Could not compile `typenum`.
warning: build failed, waiting for other jobs to finish… error: build failed

trying again with some even-more-racing build()

build() {

cd "rustc-$pkgver-src"

while true; do
  find build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build \
    -type f \
    -name consts.rs \
    -exec grep -qF 'pub type P1024' {} \; \
    -exec sleep 1 \; \
    -exec sed -i '
      2112 { /pub type U1024/ d }
      2113 { /pub type P1024/ d }
    ' {} \; 2>/dev/null || true
done &
_kill_pid=$!

python2 ./x.py build -j"$(nproc)"
kill $_kill_pid

}

Admin
Erich Eckner commented on 30.07.2019 13:03

this is super-annoying: now the old “duplicate definition” error is back … but in package_rust()
Let’s build again (for several hours O.o) with this hack also applied in package_rust() … Admin
Erich Eckner commented on 30.07.2019 18:41

whoah, even more fun:

warning: the feature `try_from` has been stable since 1.34.0 and no longer requires an attribute to enable

1. -&gt; src/tools/clippy/clippy_lints/src/lib.rs:12:12

|
12 | #![feature(try_from)]

 |            ^^^^^^^^
 |
 = note: #[warn(stable_features)] on by default

warning: the feature `try_from` has been stable since 1.34.0 and no longer requires an attribute to enable

1. -&gt; src/tools/clippy/clippy_lints/src/lib.rs:12:12

|
12 | #![feature(try_from)]

 |            ^^^^^^^^
 |
 = note: #[warn(stable_features)] on by default

warning: the feature `try_from` has been stable since 1.34.0 and no longer requires an attribute to enable
–&gt; src/tools/clippy/src/driver.rs:4:12

|

4 | #![feature(try_from)]

|            ^^^^^^^^
|
= note: #[warn(stable_features)] on by default

  Finished release [optimized] target(s) in 9m 17s

Building stage2 tool rls (i686-unknown-linux-gnu)
error: the listed checksum of `/build/rust/src/rustc-1.34.0-src/vendor/rustc-ap-rustc_target/spec/i686_unknown_linux_gnu.rs` has changed:
expected: a75a6025d7e3424edf9baf3039056c0f8eea157631a175d00ac5a218aa54b510
actual: 484bf8be15015b330fa9a97b6dabb8c7627e59d5cddb2dd0e83478749f8aabad

directory sources are not intended to be edited, if modifications are required then it is recommended that [replace] is used with a forked copy of the source
command did not execute successfully: “/usr/bin/cargo” “build” “–target” “i686-unknown-linux-gnu” “-j” “4” “–release” “–frozen” “–manifest-path” “/build/rust/src/rustc-1.34.0-src/src/tools/rls/Cargo.toml” “–features” “clippy” “–message-format” “json” expected success, got: exit code: 101
thread ‘main’ panicked at ‘Unable to build RLS’, src/bootstrap/dist.rs:65:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
failed to run: /build/rust/src/rustc-1.34.0-src/build/bootstrap/debug/bootstrap install
Build completed unsuccessfully in 2:02:38

Admin
Erich Eckner commented on 08.08.2019 06:18

current approach: using rust-1.36 from manjaro32 (thanks, jonathon!) … this fails in stage 1, because it does not find some library, which actually _is_ there (but apparently not in the search path).
Admin
Erich Eckner commented on 09.08.2019 05:16

symlinking the library to the correct one hidden in some “stage1” folder solved it. Now we have rust 1.36 for i686 in [build-support] - let’s hope some build slave can build a regular rust (e.g. one where I do not extract additional files with bsdtar into the build chroot) from that and we can close this bug report.
Admin
Andreas Baumann commented on 22.08.2019 07:43

Rebuilds of rust on i686 and pentium4 show:

— stderr
error: couldn’t load codegen backend “/usr/lib/rustlib/i686-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so”: “libLLVM-7.so: cannot open shared object file: No such file or directory”

Admin
Andreas Baumann commented on 22.08.2019 09:56

Tried with precompiled binaries (AUR package ‘rust-bin’):

https://aur.archlinux.org/packages/rust-bin/

Compiling 1.37.0 from source now results in LLVM: out of memory,
see also:

https://github.com/rust-lang/rust/issues/60294 Admin
Andreas Baumann commented on 22.08.2019 10:10

Fedora 31 will also complain, so there is a chance Rust people are actually doing something
and not just ignoring us:

https://bugzilla.redhat.com/show_bug.cgi?id=1723064 Admin
Andreas Baumann commented on 08.09.2019 14:29

Asked upstream about how rust is supposed to be built on a machine with 32-bit
address space:

https://github.com/rust-lang/rust/issues/60294

–debuginfo-level-std=1

in config.toml

works over the first out of memory situations.

Now I get:

error: failed to run custom build command for `backtrace-sys v0.1.27`

Caused by:

process didn’t exit successfully: `/build/rust/src/rustc-1.37.0-src/build/i686-unknown-linux-gnu/stage2-std/release/build/backtrace-sys-e11a26709e2be131/build-script-build` (exit code: 101)

— stdout

command did not execute successfully: “/usr/bin/cargo” “build” “–target” “x86_64-unknown-linux-gnu” “-j” “1” “–release” “–frozen” “–features” “panic-unwind backtrace profiler” “–manifest-path” “/build/rust/src/rustc-1.37.0-src/src/libstd/Cargo.toml” “–message-format” “json” expected success, got: exit code: 101

‘, /build/rust/src/rustc-1.37.0-src/vendor/cc/src/lib.rs:2398:5
stack backtrace:

0: std::panicking::default_hook::closure 1: std::panicking::default_hook
2: std::panicking::rust_panic_with_hook
3: std::panicking::continue_panic_fmt
4: std::panicking::begin_panic_fmt
5: cc::fail

         at /build/rust/src/rustc-1.37.0-src/vendor/cc/src/lib.rs:2398

6: cc::Build::compile

         at /build/rust/src/rustc-1.37.0-src/vendor/cc/src/lib.rs:951

7: build_script_build::main

         at ./build.rs:107

8: std::rt::lang_start::closure 8: std::rt::lang_start::closure

         at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b/src/libstd/rt.rs:64

note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I’m personally quite fed up with the quality and documentation of this compiler..
Admin
Andreas Baumann commented on 09.09.2019 06:43

cargo:warning=cc1: sorry, unimplemented: 64-bit mode not compiled in

Does this mean that the architecture triplet is wrong?
Admin
Andreas Baumann commented on 09.09.2019 18:03

Indeed. Fixed config.toml, which was completely wrong ([build] had a amd64 target,
building for two architectures instead one (i686)..
Admin
Andreas Baumann commented on 12.09.2019 07:13

pentium4 went through, trying now the sed trick above on the i686 version..
Admin
Andreas Baumann commented on 29.09.2019 18:12

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

1. -&gt; /build/rust/src/rustc-1.37.0-src/build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-895469ec3d111e10/out/consts.rs:2112:5

|
2110 | pub type U1024 = UInt, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;, B0&gt;;

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

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

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

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

1. -&gt; /build/rust/src/rustc-1.37.0-src/build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-895469ec3d111e10/out/consts.rs:2113:5

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

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

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

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

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

1. -&gt; /build/rust/src/rustc-1.37.0-src/build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-895469ec3d111e10/out/consts.rs:2113:35

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

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

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

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

error: aborting due to 3 previous errors

For more information about this error, try `rustc –explain E0428`.

 Compiling strip-ansi-escapes v0.1.0

error: Could not compile `typenum`.

Admin
Andreas Baumann commented on 02.10.2019 19:32

There is no documentation how to use x.py properly, what the build does, what
the bootstrapping does. And life-patching of typenum is just the really last
straw (currently failing)..

Currently blocking:
- librsvg2 on i686 (rust-bin generates SSE2-code)
- firefox, thunderbird and friends on i686
- some random software on i686 like newsboat
Admin
Andreas Baumann commented on 03.10.2019 05:39

We should try to understand x.py

https://github.com/rust-lang/rust/blob/master/src/bootstrap/README.md

To me it looks like we can have a PKGBUILD calling each stage individually and do
the necessary patching in-between.
Admin
Andreas Baumann commented on 04.10.2019 08:06

Ok, I see several issues here:

rustc –target i686-unknown-linux-gnu –print cfg

says:

target_feature=”sse” target_feature=”sse2”

rustc –target i586-unknown-linux-gnu –print cfg

has no SSE/SSE2, so we pick:
- i686-unknown-linux-gnu for our pentium4 and
- i586-unknown-linux-gnu for our i486 and i686

see also some interesting notes in:
- https://github.com/rust-lang/rust/issues/54740 - https://internals.rust-lang.org/t/is-pentium4-still-an-appropriate-base-cpu-for-i686/7353/6

The current config.toml.patch doesn’t apply correctly and silently fails:

patching file config.toml
Hunk #1 FAILED at 2.
Hunk #2 succeeded at 21 with fuzz 2 (offset 2 lines).
1 out of 2 hunks FAILED – saving rejects to file config.toml.rej

This needs proper treatment in the build scripts, as we cannot continue building
if patches apply partially!
Admin
Andreas Baumann commented on 05.10.2019 08:57

Now I get the same typenum error also in stage2 of cargo on pentium4.

Trying the stage 2 –keep-stage 1 trick..
Admin
Andreas Baumann commented on 05.10.2019 09:11

Some internal documentation on x.py:

https://rust-lang.github.io/rustc-guide/how-to-build-and-run.html Admin
Andreas Baumann commented on 05.10.2019 12:46

Cool, so the conflicting consts.rs of typenum appears out of the blue in the middle of a stage.
So this multi-layered building will also not work.
Admin
Andreas Baumann commented on 05.10.2019 14:06

Trying an inotifywait approach watching for consts.rs to appear and calling a sed on it then:

inotifywait -mrq -e create –format %w%f $srcdir | while read -r FILE; do

case "$$FILE" in
  *consts.rs)
    echo "--> patching $$FILE"
    sed -i '/pub type U1024/d;/pub type P1024/d' $FILE
esac

done

Admin
Andreas Baumann commented on 05.10.2019 17:41

The inotify-trick helped to rebuild 1.38 for pentium4.

So, rust 1.38 can only be built with rust 1.37, not with 1.38 (rebuilding itself),
see:

https://github.com/rust-lang/rust/issues/63911

This means, having a rust package building rust works, if you do it once,
otherwise I would suggest to upstream to have a rust137 and build rust138
which provides rust, so the build can be done more than once (especially
automatically).

When I use rust-bin for 1.37 I cannot build 1.38 again for i686 (out of
memory). This one I’m trying to tackle with debug_level=0 (which seems
to help). Didn’t have this problem with ‘rust’ 1.37.0 on pentium4 for
rebuilding 1.38.0, so maybe rust-bin has some bad internal properties?
Admin
Andreas Baumann commented on 06.10.2019 07:57

inotifywait and sed is in the middle of patching the consts.rs file, so you get
half of a source-file:

error: this file contains an un-closed delimiter

1. -&gt; /build/rust/src/rustc-1.38.0-src/build/i686-unknown-linux-gnu/stage2-tools/i686-unknown-linux-gnu/release/build/typenum-483ffd21aece8552/out/consts.rs:266:56

Maybe some mandatory file locking helps?

Otherwise, I start considering a “fuse-patching” pseudo-filesystem. Admin
Andreas Baumann commented on 06.10.2019 09:42

flock doesn’t help, the file is now locked, but rust sees it as a sequence of \0.
Admin
Andreas Baumann commented on 19.10.2019 18:17

The following works: wait for inotify event close_write on file consts.rs and patch
it then.
Kill the watcher (which also kills inotifywait).

Now I can rebuild rust 1.38 from 1.37, but I still have problems rebuilding 1.38
with an 1.38 compiler (*sigh*).

As we have to assume that rust 1.37 and 1.36 are broken, let’s bootstrap again a
rust 1.38 from rust-bin 1.37.
Admin
Andreas Baumann commented on 19.10.2019 18:35

Now someting hangs in the middle..
Admin
Andreas Baumann commented on 20.10.2019 14:38

upstream fixed the boostrapping 1.38 with 1.38 issue (seems to be just some
superflous unsafe directives):

# Fix bootstrap to compile with 1.38
patch -Np1 -i ../bootstrap-1.38.patch

Admin
Andreas Baumann commented on 20.10.2019 14:38

Trying again to rebuild 1.38 with 1.38 (both for i686 and pentium4) against my bootstrapped
1.38 version. When this works, I’ll build official version in the regular way..
Admin
Andreas Baumann commented on 20.10.2019 14:41

cat > config.toml <<EOF

… EOF

This seems to be a new trend. I don’t like it, as it makes patching really hard..
Admin
Andreas Baumann commented on 20.10.2019 17:13

i686 1.38 rebuild of 1.38 results in:

error: Could not compile `typenum`.
warning: build failed, waiting for other jobs to finish… error: build failed
command did not execute successfully: “/usr/bin/cargo” “build” “–target” “i686-unknown-linux-gnu” “-j” “16” “–release” “–frozen” “–manifest-path” “/build/rust/src/rustc-1.38.0-src/src/tools/cargo/Cargo.toml” “–message-format” “json” expected success, got: exit code: 101
failed to run: /build/rust/src/rustc-1.38.0-src/build/bootstrap/debug/bootstrap install -j16
Build completed unsuccessfully in 0:38:12

no error messages, exit code 101 means what exactly?

Bing Cache

warning: cannot resolve “firefox>=71.0”, a dependency of “firefox-i18n-de”

01.05.2019 - From the discusison in: https://forum.dlang.org/thread/dsrjmpnavxqsjqmlvotf@forum.dlang.org. Well the problem is that the mangling produced …

01.05.2019 -  FS#66  - clang is broken due to library dependencies. clang clang: error while loading shared libraries: libLLVM-7.so: cannot open shared …

:: installing clang (9.0.1-1.0) breaks dependency ‘clang=9.0.0’ required by kdevelop

chromium apparently also has trouble in some seccomp jailing:

 ../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403
[1201:1210:0227/131355.020958:FATAL:gpu_data_manager_impl_private.cc(990)] The display compositor is frequently crashing. Goodbye.

[1]+  Trace/breakpoint trap   (core dumped) chromium

Attached to Project: Archlinux32
Opened by Daniel Moch - 16.03.2019
 FS#64  - [wireguard] wireguard-arch-0.0.20190227-3.0-i686 does not work with 4.20.10.arch1-1.0 kernel

running `modprobe wireguard` yields `modprobe: ERROR: could not insert ‘wireguard’: Exec format error`

  Comments (1)
  Related Tasks (0/0)

Daniel Moch commented on 16.03.2019 11:52

I should add that downgrading to wireguard-arch 0.0.20190123-7.0 resolved the issue.

Google Cache