Bugs in Archlinux32 packages, specific to 32-bit issues.

Bugs  FS#2  to  FS#92  have been recovered and may be incomplete, the
recovered Google/Bing cache data can be found here.

IDCategoryTask TypePrioritySeveritySummaryStatusProgress  desc
 16 PackagesBug ReportMediumLow [libreoffice-still] still using icu 59 - Arch Linux Closed
100%
Task Description

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

 17 PackagesBug ReportMediumLow nvidia and nvidia-lts kernel module build failure on 32 ...Closed
100%
Task Description

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

 18 PackagesBug ReportMediumLow  [android-tools] missing a -latomic when linking adb .. Closed
100%
Task Description

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

 19 PackagesBug ReportMediumLow unknown bug FS#19 Closed
100%
Task Description

no task description

 21 PackagesBug ReportMediumLow [ceph] unit tests failing or segfault Closed
100%
Task Description

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

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

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

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

blacklisted ceph

Comments (9)

Admin
Erich Eckner commented on 17.12.2017 19:11

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

ceph goes heavy non-i686:

shell#> cmake ….

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

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

Call Stack (most recent call first):

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

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

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

New try, same bugs:

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

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

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

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

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

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

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

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

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

ah, that’s because you already removed the dependencies :-)

Google Cache

Bing Cache

 22 Packages: Build-listBug ReportMediumLow [firefox-developer-edition] build fails with out of mem ...Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 16.12.2017
Last edited by Erich Eckner - 17.12.2017
 FS#22  - [firefox-developer-edition] build fails with out of memory when using rust

49:50.05 note: rustc 1.22.1 running on i686-unknown-linux-gnu
49:50.05
49:50.05 note: run with `RUST_BACKTRACE=1` for a backtrace
49:50.05
49:50.05 thread ‘rustc’ panicked at ‘called `Result::unwrap()` on an `Err` value: Error { repr: Custom(Custom { kind: Other, error: StringError(”Cannot allocate memory”) }) }’, src/libcore/result.rs:906:4
49:50.05 stack backtrace:
49:50.05 0: 0xf7caf5ea - rust_metadata_std_a60a98c24b539dcf2508f3d395979a97
49:50.05 1: 0xf7caa43e - rust_metadata_std_a60a98c24b539dcf2508f3d395979a97
49:50.05 2: 0xf7cbb31c - rust_metadata_std_a60a98c24b539dcf2508f3d395979a97
49:50.05 3: 0xf7cbb051 - rust_metadata_std_a60a98c24b539dcf2508f3d395979a97
49:50.05 4: 0xf7cbb82b - std::panicking::rust_panic_with_hook::h269fa2b74a2a0cee
49:50.05 5: 0xf7cbb6f6 - rust_metadata_std_a60a98c24b539dcf2508f3d395979a97
49:50.05 6: 0xf7cbb616 - std::panicking::begin_panic_fmt::hfe3f4b4d254fe489
49:50.05 7: 0xf7cbb57d - rust_begin_unwind
49:50.05 8: 0xf7d10dd6 - core::panicking::panic_fmt::h39c7136c9dc224e1
49:50.05 9: 0xf791f50a - rust_metadata_rustc_trans_73f1dcf221d7505426c13ccaa7d81bf3
49:50.05 10: 0xf79558dc - rust_metadata_rustc_trans_73f1dcf221d7505426c13ccaa7d81bf3
49:50.05 11: 0xf794f7e6 - rustc_trans::back::link::each_linked_rlib::h1e799094f6b686fb
49:50.05 12: 0xf794ff56 - rust_metadata_rustc_trans_73f1dcf221d7505426c13ccaa7d81bf3
49:50.05 13: 0xf794f19b - rustc_trans::back::link::link_binary::ha97335099e542ac0
49:50.06 14: 0xf79f455e - ::link_binary::h62e43ed882d32b44
49:50.06 15: 0xf7e686c5 - rustc_driver::driver::compile_input::hfa914359aa3118bb
49:50.06 16: 0xf7e82a2a - rustc_driver::run_compiler::hcd191a8815d2728b
49:50.06 17: 0xf7d9cc8f - rust_metadata_rustc_driver_e8ab70a79951e31413d2f7ce5f23c51c
49:50.06 18: 0xf7cc5542 - rust_maybe_catch_panic
49:50.06 19: 0xf7dd6891 -
49:50.06 20: 0xf7cba2db - rust_metadata_std_a60a98c24b539dcf2508f3d395979a97
49:50.06 21: 0xf622ee55 - start_thread
49:50.06 22: 0xf7b6dd05 -
clone
49:50.06 23: 0×0 -
49:50.06
49:50.23 error: Could not compile `gkrust`.
49:50.23
49:50.23 To learn more, run the command again with –verbose.
49:50.24 make[4]: * [/build/firefox-developer-edition/src/mozilla-unified/config/rules.mk:953: force-cargo-library-build] Error 101
49:50.24 make[3]:
* [/build/firefox-developer-edition/src/mozilla-unified/config/recurse.mk:73: toolkit/library/rust/target] Error 2
49:50.24 make[2]: * [/build/firefox-developer-edition/src/mozilla-unified/config/recurse.mk:33: compile] Error 2
49:50.24 make[1]:
* [/build/firefox-developer-edition/src/mozilla-unified/config/rules.mk:432: default] Error 2
49:50.24 make: *** [client.mk:274: build] Error 2
49:50.28 635 compiler warnings present.
49:50.44 Notification center failed: Install notify-send (usually part of the libnotify package) to get a notification when the build finishes.
==> ERROR: A failure occurred in build().

  Aborting...

==> ERROR: Build failed, check /var/lib/archbuild/staging-with-build-support-i686/erich/build

Closed by Erich Eckner
17.12.2017 19:10
Reason for closing: Not a bug

  Comments (0)

Google Cache

 23 Packages: Build-listBug ReportMediumLow libretro* packages failing, seem unsupported for 32-bit ...Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 04.01.2018
Last edited by Erich Eckner - 26.01.2018
 FS#23  - libretro* packages failing, seem unsupported for 32-bit Intel/Linux

This affects the following packages:
- libretro-citra (unsuported architecture in dynarmic submodule)
- libretro-parallel-n64: tons of assembly errors
- libretro-ppsspp: linking issues with ffmpeg
- libretro-mupen64plus: direct GOT relocation R_386_GOT32X against _ZN9PluginAPI3getEv PluginAPI::get()

blacklisting all.
Closed by Erich Eckner
26.01.2018 17:08
Reason for closing: Won’t fix
Additional comments about closing:

blacklisted

  Comments (0)

Google Cache

 24 PackagesBug ReportMediumLow [extra/viewnior] Needs rebuild against exiv2=0.26 Closed
100%
Task Description

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

 25 PackagesBug ReportMediumLow unknown bug FS#25 Closed
100%
Task Description

no task description

 26 PackagesBug ReportMediumLow [texlive] partially linked against old libmpfr Closed
100%
Task Description

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

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

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

  Comments (0)

Google Cache

 27 PackagesBug ReportMediumLow man breaks on gdbm sobump Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 02.02.2018
Last edited by Andreas Baumann - 03.02.2018
 FS#27  - man breaks on gdbm sobump

man
man: error while loading shared libraries: libgdbm.so.4: cannot open shared object file: No such file or directory

either you must link against libgdbm_compat.so.4 or against libgdbm.5
Closed by Andreas Baumann
03.02.2018 07:47
Reason for closing: Fixed
Additional comments about closing:

fixed in man-db-2.7.6.1-3.1, installing that package from testing as temporary is the better
solution than adding a symlink you make forget to delete..

  Comments (4)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 02.02.2018 17:50

temporary workaround: ln -fs libgdbm_compat.so.4 /usr/lib/libgdbm.so.4
Admin
Andreas Baumann commented on 02.02.2018 17:53

weird: Archlinux has:

/usr/bin/man is owned by man-db 2.7.6.1-3
gdbm 1.14.1-1

Archlinux 32 has:

man-db 2.7.6.1-3.0
gdbm 1.14.1-1.0

This seems to be pretty much the same version.
Admin
Erich Eckner commented on 02.02.2018 18:15

it’s amazing what packages we managed to break :-/ I scheduled man-db for a rebuild
Admin
Andreas Baumann commented on 02.02.2018 20:38

man-db is rebuilding on my slave. *fingers crossed*

Google Cache

 29 Packages: Build-listBug ReportMediumLow [haskell-hslua] check() fails Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Erich Eckner - 18.02.2018
 FS#29  - [haskell-hslua] check() fails

several failures during check() - disabling for now

==> Starting check()… Running 1 test suites… Test suite test-hslua: RUNNING… hslua

Haskell version of the C API
  copy
    copies stack elements using positive indices:               OK
    copies stack elements using negative indices:               OK
  insert
    inserts stack elements using negative indices:              OK
    inserts stack elements using negative indices:              OK
  absindex:                                                     OK
  gettable gets a table value:                                  FAIL
    test/Test/HsLua/Util.hs:35:
    lua operation returned false
  strlen, objlen, and rawlen all behave the same:               OK
  Type checking
    isfunction:                                                 OK
    isnil:                                                      OK
    isnone:                                                     OK
    isnoneornil:                                                OK
  CFunction handling:                                           OK
  getting values
    tointegerx returns numbers verbatim:                        OK
    tointegerx accepts strings coercible to integers:           OK
    tointegerx returns Nothing when given a boolean:            OK
    tonumberx returns numbers verbatim:                         OK
    tonumberx accepts strings as numbers:                       OK
    tonumberx returns Nothing when given a boolean:             OK
  setting and getting a global works:                           OK
  can push and receive a thread:                                OK
  different threads are not equal:                              OK
  thread status:                                                OK
  loading
    loadstring status:                                          OK
    dostring loading:                                           OK
    dofile loading:                                             OK
  pcall status:                                                 OK
  garbage collection:                                           OK
  compare
    identifies strictly smaller values:                         FAIL
      *** Failed! Assertion failed (after 1 test): 
      LuaInteger 0
      Use --quickcheck-replay=586817 to reproduce.
    identifies smaller or equal values:                         FAIL
      *** Failed! Assertion failed (after 1 test): 
      LuaInteger 0
      Use --quickcheck-replay=316579 to reproduce.
    identifies equal values:                                    OK
      +++ OK, passed 100 tests.
  lessthan works:                                               FAIL
    *** Failed! Assertion failed (after 2 tests): 
    LuaNumber (-0.35170612)
    LuaNumber 0.84471506
    Use --quickcheck-replay=507888 to reproduce.
  order of Lua types is consistent:                             OK
    +++ OK, passed 100 tests.
  functions can throw a table as error message:                 OK
  handling table errors won't leak:                             OK
Interoperability
  call haskell functions from lua
    push haskell function to lua:                               OK
    push multi-argument haskell function to lua:                OK
    argument type errors are propagated:                        OK
    convert haskell function to c function:                     OK
    Error in Haskell function is converted into Lua error:      OK
  call lua function from haskell
    test equality within lua:                                   FAIL
      test/Foreign/Lua/FunctionCallingTest.hs:106:
      raw equality test failed
      expected: True
       but got: False
    failing lua function call:                                  OK
    print the empty string via lua procedure:                   

OK

    failing lua procedure call:                                 OK
Utilities
  Optional return the value if it exists:                       OK
  Optional can deal with missing values:                        OK
  raiseError causes a Lua error:                                OK
Sendings and receiving values from the stack
  peek and push are well behaved
    Peek can act as left inverse of push
      round-tripping unit:                                      OK
        +++ OK, passed 100 tests.
      booleans remain equal under push/peek:                    OK
        +++ OK, passed 100 tests.
      lua numbers (i.e., doubles) remain equal under push/peek: FAIL
        *** Failed! Assertion failed (after 2 tests): 
        LuaNumber (-1.926296)
        Use --quickcheck-replay=670723 to reproduce.
      lua integers remain equal under push/peek:                IGNORED
      bytestring remain equal under push/peek:                  OK
        +++ OK, passed 100 tests.
      round-tripping strings:                                   OK (0.01s)
        +++ OK, passed 100 tests.
      lists of boolean remain equal under push/peeks:           OK
        +++ OK, passed 100 tests.
      lists of lua integers remain equal under push/peek:       IGNORED
      lists of bytestrings remain equal under push/peek:        OK (0.15s)
        +++ OK, passed 100 tests.
      text:                                                     OK
        +++ OK, passed 100 tests.
      map of strings to LuaNumber:                              FAIL
        *** Failed! Assertion failed (after 2 tests and 1 shrink): 
        fromList [("",LuaNumber (-0.9010369))]
        Use --quickcheck-replay=119067 to reproduce.
      tuples
        pair of LuaNumbers:                                     FAIL
          *** Failed! Assertion failed (after 2 tests): 
          (LuaNumber (-0.34098855),LuaNumber 0.2441068)
          Use --quickcheck-replay=296075 to reproduce.
        triple of LuaNumbers:                                   FAIL
          *** Failed! Assertion failed (after 2 tests): 
          (LuaNumber 0.46677026,LuaNumber 0.9009714,LuaNumber 0.2326173)
          Use --quickcheck-replay=85608 to reproduce.
        quadruple of LuaNumbers:                                FAIL
          *** Failed! Assertion failed (after 2 tests): 
          (LuaNumber 1.8909019,LuaNumber (-0.85486156),LuaNumber (-4.0685906),LuaNumber (-12.583851))
          Use --quickcheck-replay=305430 to reproduce.
        quintuple of LuaNumbers:                                FAIL
          *** Failed! Assertion failed (after 2 tests): 
          (LuaNumber 0.2735047,LuaNumber 2.1247218,LuaNumber 0.1806469,LuaNumber 0.9455812,LuaNumber 0.98733383)
          Use --quickcheck-replay=608867 to reproduce.
        hextuple of Text, LuaNumbers and Booleans:              FAIL
          *** Failed! Assertion failed (after 2 tests and 1 shrink): 
          (False,LuaNumber (-2.381176),"",False,LuaNumber (-0.8418731),LuaNumber (-0.39977068))
          Use --quickcheck-replay=572229 to reproduce.
        septuple of Text, LuaNumber and Booleans:               FAIL
          *** Failed! Assertion failed (after 2 tests and 3 shrinks): 
          ("",False,LuaNumber 1.3463217,False,False,LuaNumber (-1.4167022),False)
          Use --quickcheck-replay=692263 to reproduce.
        octuple of Strings and Booleans:                        OK (0.03s)
          +++ OK, passed 100 tests.
    Random stack values
      can push/pop booleans:                                    OK (0.01s)
        +++ OK, passed 100 tests.
      can push/pop lua integers:                                OK (0.01s)
        +++ OK, passed 100 tests.
      can push/pop lua numbers:                                 FAIL
        *** Failed! Assertion failed (after 3 tests): 
        LuaNumber 1.5588847
        Ordered {getOrdered = [Positive {getPositive = LuaInteger 1},Positive {getPositive = LuaInteger 2}]}
        Use --quickcheck-replay=197445 to reproduce.
      can push/pop bytestrings:                                 OK (0.02s)
        +++ OK, passed 100 tests.
      can push/pop lists of booleans:                           OK (0.04s)
        +++ OK, passed 100 tests.
      can push/pop lists of LuaIntegers:                        OK (0.04s)
        +++ OK, passed 100 tests.
      can push/pop lists of bytestrings:                        OK (0.19s)
        +++ OK, passed 100 tests.
  FromLuaStack
    receives basic values from the stack:                       OK
    returns an error if the types don't match:                  OK
    list cannot be read if a list element fails:                OK
    stack is unchanged if getting a list fails:                 OK
    stack is unchanged if getting key-value pairs fails:        OK
  ToLuaStack
    pushing simple values to the stack
      Boolean can be pushed correctly:                          OK
      LuaNumbers can be pushed correctly:                       FAIL
        test/Foreign/Lua/Types/ToLuaStackTest.hs:105:
        5::LuaNumber was not pushed
      LuaIntegers can be pushed correctly:                      FAIL
        test/Foreign/Lua/Types/ToLuaStackTest.hs:105:
        42::LuaInteger was not pushed
      ByteStrings can be pushed correctly:                      OK
      Unit is pushed as nil:                                    OK
      Pointer is pushed as light userdata:                      OK
    pushing a value increases stack size by one
      LuaInteger:                                               OK
        +++ OK, passed 100 tests.
      LuaNumber:                                                OK
        +++ OK, passed 100 tests.
      ByteString:                                               OK
        +++ OK, passed 100 tests.
      String:                                                   OK
        +++ OK, passed 100 tests.
      list of booleans:                                         OK
        +++ OK, passed 100 tests.
lua integration tests
  print version:                                                OK
  functions stored in / retrieved from registry:                OK
  getting a nested global works:                                OK
  setting a nested global works:                                OK
  table reading:                                                OK
  Getting strings to and from the stack
    unicode ByteString:                                         OK
    ByteString should survive after GC/Lua destroyed:           OK
    String with NUL byte should be pushed/popped correctly:     OK
  luaopen_* functions
    opendebug:                                                  OK
    openio:                                                     OK
    openmath:                                                   OK
    openos:                                                     OK
    openpackage:                                                OK
    openstring:                                                 OK
    opentable:                                                  OK
  luaopen_base returns the right number of tables
    openbase:                                                   OK
  C functions
    Registering a C function and calling it from Lua:           FAIL
      test/Foreign/LuaTest.hs:162:
      greeting function failed
      expected: Right ["Caffeine","induced","nonsense"]
       but got: Right []
    pushing a C closure to and calling it from Lua:             OK
  error handling
    lua errors are caught:                                      OK
    error-less code gives in 'Right' result:                    OK
    catching lua errors within the lua type:                    OK
    second alternative is used when first fails:                OK
    Applicative.empty implementation throws an exception:       OK
    catching error of a failing meta method:                    OK
    calling a function that errors throws exception:            OK

17 out of 112 tests failed (0.60s)
Test suite test-hslua: FAIL
Test suite logged to: dist/test/hslua-0.9.5-test-hslua.log
0 of 1 test suites (0 of 1 test cases) passed.
==> ERROR: A failure occurred in check().

Bing Cache

 30 PackagesBug ReportMediumLow libaio, will fail with stack smash protection enabled . ...Closed
100%
Task Description

12.04.2018 - io_queue_run.os: In function `io_queue_run’: io_queue_run.c:(.text+0×71): undefined reference to `__stack_chk_fail_local’ io_getevents.os: In …

 31 PackagesBug ReportMediumLow librsvg fails with invalid opcode on 2.42.1 and newer Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Swift Geek - 16.03.2018
Last edited by Andreas Baumann - 26.03.2018
 FS#31  - librsvg fails with invalid opcode on 2.42.1 and newer

traps: gtk3-demo[365] trap invalid opcode ip:aedd3e15 sp:bffc64c0 error:0 in librsvg-2.so.2.42.3[aed27000+11a000]

Downgrading to 2.40.19 seems to help.
https://archive.archlinux32.org/repos/2017/11/01/extra/os/i686/librsvg-2:2.40.19-1-i686.pkg.tar.xz

This could be related to machine not having SSE2 (Pentium III-M Tualin)

Related bbs thread: https://bbs.archlinux32.org/viewtopic.php?id=1369 Closed by Andreas Baumann
26.03.2018 15:02
Reason for closing: Fixed

  Comments (1)
  Related Tasks (0/0)

Paul Gover commented on 26.03.2018 11:03

For me, librsvg-2:2.42.3-1.2 fixes the problem

Google Cache

 32 PackagesBug ReportMediumLow [samba] faileure to start due to linking issues Closed
100%
Task Description

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

 33 Packages: TestingBug ReportMediumLow [icu] sobump mismatch Closed
100%
Task Description

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

 34 PackagesBug ReportMediumLow unknown bug FS#34 Closed
100%
Task Description

no task description

 35 Packages: StableBug ReportMediumLow texlive errors while installing (missing icu 60) Closed
100%
Task Description

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

 37 PackagesBug ReportMediumLow ISO 2018.05.01 is not bootable with qemu or Virtualbox Closed
100%
Task Description

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

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

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

It also panics in Virtualbox.

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

works

  Comments (6)
  Related Tasks (0/0)

Admin
Tyzoid commented on 10.05.2018 10:49

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

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

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

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

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

So, if I start qemu with:

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

it works.

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

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

The 2019.01.04 ISO works with Virtualbox 6.0.0.

Google Cache

 38 Packages: TestingBug ReportMediumLow Using SDDM, X and LXDE segfaults and logs automatically ...Closed
100%
Task Description

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

 39 Packages: StableBug ReportMediumLow xorg modesetting module fails with illegal instruction Closed
100%
Task Description

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 > const, SwrJit::X86Intrinsic>::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

=> 0xb62d5d37 <+71>: 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
=> 0xb627e167: c5 fa 7e 45 e0 vmovq -0×20(%ebp),%xmm0

Google Cache

Bing Cache

 40 Packages: StableBug ReportMediumLow [extra/gimp] is uninstallable because [extra/gegl02 ... Closed
100%
Task Description

20.06.2018 - [extra/gegl02] (which provided gegl=0.2; [extra/gegl] is 0.3) was removed, despite that it was still needed by [extra/gimp]. [extra/gimp] is an old …

 41 PackagesBug ReportMediumLow [extra/vlc] is uninstallable because [extra/ffmpeg2.8]  ...Closed
100%
Task Description

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

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

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

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

  Comments (3)
  Related Tasks (0/0)

Admin
Tyzoid commented on 13.06.2018 21:39

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

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

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

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

vlc 3.0.3 works fine on testing.

Google Cache

 42 PackagesBug ReportMediumLow Unknown bug FS#42 Closed
100%
Task Description

no task description

 43 Packages: Build-listBug ReportMediumLow qt5-webengine, firefox, firefox-developer-edition use t ...Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 16.06.2018
Last edited by Andreas Baumann - 02.10.2019
 FS#43  - qt5-webengine, firefox, firefox-developer-edition use too much memory

In file included from gen/third_party/WebKit/public/platform/modules/presentation/presentation.mojom-shared.h:24,

               from gen/third_party/WebKit/public/platform/modules/presentation/presentation.mojom.h:37,
               from ../../../../qtwebengine-everywhere-src-5.11.0/src/3rdparty/chromium/content/browser/frame_host/render_frame_host_impl.h:66,
               from ../../../../qtwebengine-everywhere-src-5.11.0/src/3rdparty/chromium/content/browser/frame_host/frame_tree_node.h:18,
               from ../../../../qtwebengine-everywhere-src-5.11.0/src/3rdparty/chromium/content/browser/devtools/browser_devtools_agent_host.cc:21:

gen/third_party/WebKit/public/platform/modules/presentation/presentation.mojom-shared-internal.h:139:35: warning: alignment 1 of ‘blink::mojom::internal::PresentationConnectionMessage_Data’ is less than 8 [-Wpacked-not-aligned]
class MOJOM_SHARED_CONTENT_EXPORT PresentationConnectionMessage_Data {

                                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

virtual memory exhausted: Cannot allocate memory
ninja: build stopped: subcommand failed.

Also in firefox:

91:37.06 ../../build/unix/gold/ld: fatal error: libxul.so: mmap: failed to allocate 1703955732 bytes for output file: Cannot allocate memory
91:37.06 collect2: error: ld returned 1 exit status
91:37.06 make[4]: * [/build/firefox/src/mozilla-unified/config/rules.mk:701: libxul.so] Error 1
91:37.06 make[3]:
* [/build/firefox/src/mozilla-unified/config/recurse.mk:73: toolkit/library/target] Error 2
91:37.06 make[2]: * [/build/firefox/src/mozilla-unified/config/recurse.mk:33: compile] Error 2
91:37.06 make[1]:
* [/build/firefox/src/mozilla-unified/config/rules.mk:434: default] Error 2
91:37.06 make: *** [client.mk:168: build] Error 2

Closed by Andreas Baumann
02.10.2019 19:26
Reason for closing: Fixed
Additional comments about closing:

Currently firefox and qt5-webengine build.
firefox-developer-edition is blacklisted as it causes too much trouble
already as the official released version, so we don’t to beta testing
here..

  Comments (10)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 16.06.2018 05:33

Build slaves should have a 4GB swap space (if they are virtual machines),
and sysctl vm.mmap_min_addr=0 should be set.

For containers I don’t know what’s best becauste systemd-nspawn has
a mind of its own. sysctl vm.mmap_min_addr=0 on the host helped here too.
Admin
Andreas Baumann commented on 16.06.2018 05:37

Another solution could be not to use the gold-ld.
Admin
Andreas Baumann commented on 16.06.2018 06:26

and another one:

CodeCache::InnerPointerToCodeCacheEntry’; use assignment or value-initialization instead [-Wclass-memaccess]

   memset(&cache_[0], 0, sizeof(cache_));
                                       ^

../../../../qtwebengine-everywhere-src-5.11.0/src/3rdparty/chromium/v8/src/frames.h:36:10: note: ‘struct v8::internal::InnerPointerToCodeCache::InnerPointerToCodeCacheEntry’ declared here

 struct InnerPointerToCodeCacheEntry {
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

{standard input}: Assembler messages:
{standard input}:15117: Warning: end of file not at end of a line; newline inserted
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive
g++: fatal error: Terminated signal terminated program cc1plus
compilation terminated.
ninja: build stopped: subcommand failed.

This looks like truncated assembly to me. Maybe using tmpfile instead of -pipe?
Admin
Andreas Baumann commented on 17.06.2018 06:24

qt5-webkit fails now much later in a build race in a plugin. removing -pipe could
also help for all other packages running out of virtual memory, so maybe changing
the global build options to ‘-j1’ and not ‘-pipe’ in makepkg.conf is an idea.
Or we patch the affected packages only, but patching away a -pipe might not be as
easy as one may think.
Admin
Andreas Baumann commented on 20.06.2018 05:01

Still trouble with firefox and firefox-developer-edition, -pipe gets added
somewhere even if I change it in the build chroot configuration in makepkg.conf..
Admin
Andreas Baumann commented on 21.06.2018 11:46

-pipe doens’t have a huge impact.

So I’ll try with some special LDFLAGS -Wl,–no-keep-memory, after a hint in:

https://bugzilla.mozilla.org/show_bug.cgi?id=854535 Admin
Andreas Baumann commented on 23.06.2018 07:56

A top on a 64-bit Archlinux shows me the following during a build:

26963 arch 20 0 6336364 1.8g 1468 R 7.0 91.8 1:44.14 dump_syms

0 S arch 26958 26956 0 80 0 - 25355 - 20:29 pts/0 00:00:00 /data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/_virtualenv/bin/python /data/firefox/src/mozilla-unified/toolkit/crashreporter/tools/symbolstore.py -c –vcs-info –install-manifest=/data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/_build_manifests/install/dist_include,/data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/include -s /data/firefox/src/mozilla-unified /data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/host/bin/dump_syms /data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/crashreporter-symbols /data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/toolkit/library/libxul.so
0 D arch 26963 26958 7 80 0 - 1146305 - 20:29 pts/0 00:00:34 /data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/host/bin/dump_syms /data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/toolkit/library/libxul.so

So, this dump_syms program will never work in an 32-bit address room. The question
is, can it be tuned or hacked? The question, why did it work till now and what
changed so it doesn’t work currently?
Admin
Andreas Baumann commented on 02.07.2018 15:58

Another try using the standard linker instead of the gold one.
Admin
Andreas Baumann commented on 02.07.2018 19:43

I think, I’m in the wrong movie:

36:53.02 libxul.so
37:13.26 /usr/bin/ld: out of memory allocating 1000 bytes after a total of 898674688 bytes
37:13.26 collect2: error: ld returned 1 exit status

Admin
Andreas Baumann commented on 02.10.2019 19:24

Rust things also run out of memory (firefox), disabling some debug info
with debug_info=1 makes the builds succeed.

Google Cache

 44 PackagesBug ReportMediumLow [qt5-webengine] fatal error: QtUiPlugin ... Closed
100%
Task Description

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

 45 PackagesBug ReportMediumLow doublecmd: access violation - Arch Linux Closed
100%
Task Description

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

 46 Packages: Build-listBug ReportMediumLow electron - pic issues Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Erich Eckner - 27.06.2018
 FS#46  - electron - pic issues

/usr/bin/clang++ -Wl,-O1,–sort-common,–as-needed,-z,relro,-z,now -Wl,-z,noexecstack -Wl,-rpath=\$ORIGIN -rdynamic -Wl,–export-dynamic -pthread -Wl,–no-keep-memory –sysroot=/ -Lusr/lib/libfakeroot -Wl,-rpath-link=usr/lib/libfakeroot -m32 -Wl,-z,noexecstack -Wl,-O1 -Wl,–as-needed -Wl,–gc-sections -flto=thin -fuse-ld=lld -Wl,–icf=all -Wl,–lto-O0 -Wl,-mllvm,-function-sections -Wl,-mllvm,-data-sections -Wl,-rpath-link=lib/ -o electron -Wl,–start-group obj/atom/app/electron.atom_main.o obj/libelectron_lib.a obj/brightray/libbrightray.a obj/vendor/breakpad/libbreakpad_client.a -Wl,–end-group lib/libnode.so -Wl,–start-group /build/electron/src/electron/vendor/libchromiumcontent/dist/main/static_library/libangle.a /build/electron/src/electron/vendor/libchromiumcontent/dist/main/static_library/libbase.a /build/electron/src/electron/vendor/libchromiumcontent/dist/main/static_library/libcc.a /build/electron/src/electron/vendor/libchromiumcontent/dist/main/static_library/libchromiumcontent.a /build/electron/src/electron/vendor/libchromiumcontent/dist/main/static_library/libcomponents.a /build/electron/src/electron/vendor/libchromiumcontent/dist/main/static_library/libmedia.a /build/electron/src/electron/vendor/libchromiumcontent/dist/main/static_library/libnet.a /build/electron/src/electron/vendor/libchromiumcontent/dist/main/static_library/libpdfium.a /build/electron/src/electron/vendor/libchromiumcontent/dist/main/static_library/libppapi.a /build/electron/src/electron/vendor/libchromiumcontent/dist/main/static_library/libservices.a /build/electron/src/electron/vendor/libchromiumcontent/dist/main/static_library/libskia.a /build/electron/src/electron/vendor/libchromiumcontent/dist/main/static_library/libwebkit.a /build/electron/src/electron/vendor/libchromiumcontent/dist/main/static_library/libwebkitbindings.a /build/electron/src/electron/vendor/libchromiumcontent/dist/main/static_library/libwebkitcore.a /build/electron/src/electron/vendor/libchromiumcontent/dist/main/static_library/libwebkitmodules.a /build/electron/src/electron/vendor/libchromiumcontent/dist/main/static_library/libwebrtc.a -Wl,–end-group -lpthread -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -lfribidi -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -ldbus-1 -lX11-xcb -lxcb -lXi -lXcursor -lXdamage -lXrandr -lXcomposite -lXext -lXfixes -lXrender -lX11 -lXtst -lXss -lgconf-2 -lgmodule-2.0 -lglib-2.0 -lssl3 -lsmime3 -lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lasound -lcap -lcups -lrt -ldl -lresolv -lfontconfig -lexpat -lavcodec -lavformat -lavutil -levent -lFLAC -lharfbuzz-icu -lharfbuzz -ljsoncpp -lminizip -lpulse -lvpx -lwebpdemux -lwebpmux -lwebp -lxslt -lm -lxml2 -lz -ljpeg -lre2 -lsnappy -latomic
/usr/bin/ld.lld: error: can’t create dynamic relocation R_386_32 against local symbol in readonly segment; recompile object files with -fPIC
>>> defined in /build/electron/src/electron/vendor/libchromiumcontent/dist/main/static_library/libchromiumcontent.a(dct.o)
>>> referenced by ../../third_party/openh264/src/codec/common/x86/dct.asm
>>> dct.o:(.text+0×337) in archive /build/electron/src/electron/vendor/libchromiumcontent/dist/main/static_library/libchromiumcontent.a

I doubt, that this file gets compiled at all - the only occurences upto the above are:
[29/30] AR obj/chromiumcontent/libchromiumcontent.a
and
[34/16236] COPY /build/electron/src/electron/vendor/libchromiumcontent/src/out-ia32/static_library/obj/chromiumcontent/libchromiumcontent.a

  Comments (1)
  Related Tasks (0/0)

Admin
Erich Eckner commented on 27.07.2018 04:23

I tried to remove all *.a and *.o files first, but this just creates other issues

Google Search

 47 Packages: StableBug ReportMediumLow rankmirrors $repo guessing broken in i686 only Closed
100%
Task Description

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

 48 Packages: TestingBug ReportMediumLow Testing repo missing a new version of python-six Closed
100%
Task Description

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

 49 PackagesBug ReportMediumLow ffmpeg update failures in release and testing Closed
100%
Task Description

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

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

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

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

This is reportedly also a problem on the release branches.

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

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

$ pacman -Syu

Workaround

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

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

  Comments (0)

Google Cache

Bing Cache

 50 PackagesBug ReportMediumLow [imagemagick] is not installable because of [perl] Closed
100%
Task Description

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

 51 PackagesBug ReportMediumLow ufw needs rebuild for python 3.7 Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Paul Gover - 07.09.2018
Last edited by Erich Eckner - 24.09.2018
 FS#51  - ufw needs rebuild for python 3.7

Been using ufw for some time. Today, I wanted to turn logging off.
Command “ufw logging off” should just work. Instead it gives:

ufw logging off
Traceback (most recent call last):

File “/usr/bin/ufw”, line 26, in

import ufw.frontend

ModuleNotFoundError: No module named ‘ufw’

which I trace to the fact ufw is installed in
/usr/lib/python3.6/site-packages/ufw
and there’s no longer a python 3.6 executable; it’s all 3.7 now.
Closed by Erich Eckner
24.09.2018 07:32
Reason for closing: Fixed

  Comments (3)
  Related Tasks (0/0)

Admin
Erich Eckner commented on 07.09.2018 09:46

ufw-0.35-5.0 from [community-testing] should work - I’m moving it to [community] just now
Paul Gover commented on 07.09.2018 09:48

Sorry to add to your workload. I assumed a UFW problem was local to me. Now I’ve read the furore about python 3.7 etc. on the forums, my apologies. I’ll try the community-testing version. Thanks for the speedy response.
Paul Gover commented on 11.09.2018 15:21

To confirm, UFW is working fine for me now. Thanks.



Google Cache

 52 PackagesBug ReportMediumLow Some packages are built by "Unknown Packager" Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Luke Shumaker - 21.09.2018
 FS#52  - Some packages are built by “Unknown Packager”

Some packages have

packager = Unknown Packager

, which is caused by

makepkg.conf:PACKAGER

not being set.

I analyzed every .pkg.tar.xz file in the Arch 32 repos (all architectures). The earliest Unknown Packager package was built on June 9, 2017, and they’ve been intermittent since then. Here’s a listing of how many times each packager appears:

    2  Dave Reisner 
    2  Fabio Castelli (Muflone) 
    2  Giancarlo Razzolini 
    2  Jelle van der Waa 
    2  Laurent Carlier 
    2  S?bastien Luttringer 
    2  schuay 
    3  Florian Pritz 
    3  Johannes L?thberg 
    4  Alexander R?dseth 
    4  Andreas Radke 
    4  Eli Schwartz 
    4  Tobias Powalowski 
    5  Gaetan Bisson 
    5  Jonathan Steel 
    6  Bart?omiej Piotrowski 
    6  Erich Eckner 
    7  Kyle Keen 
    8  Evangelos Foutras 
    8  Maxime Gauduin 
    9  Jaroslav Lichtblau 
    9  Lukas Fleischer 
   18  BlackEagle 
   21  Sergej Pupykin 
   22  Guillaume ALAUX 
   29  Sven-Hendrik Haase 
   32  Levente Polyak 
   35  Jan Alexander Steffens (heftig) 
   39  Felix Yan 
   43  Jan de Groot 
   44  Andreas Baumann 
   75  Ball? Gy?rgy 
   81  Antonio Rojas 
 6592  Unknown Packager
20577  Erich Eckner 
------------------------------------------------------------------
27707  total

This causes a problem for us in Parabola, because we just started applying the usual upload checks from

db-update

to packages that we import.

  Comments (3)
  Related Tasks (0/0)

bill auger commented on 24.09.2018 05:20

i was trying to make sense of this today and my results were pretty strange

i wrote a script to extract ‘Unknown Packager’ from the db caches in /var/lib/pacman/sync/ and i got very different counts then what luke reported - i ran the same script on both parabola i686 and again on arch32 - it did show that all of the packages by ‘Unknown Packager’ are in [extra], [community], and [core]

<pre>
$ wc -l ./unknown-packagers-parabola
1800 ./unknown-packagers-parabola

$ wc -l ./unknown-packagers-arch32
2250 ./unknown-packagers-arch32
</pre>

one thing i noted was that one of the packages (4ti2) that arch32 has by ‘Unknown Packager’ for v1.6.7 shows as v1.6.9 packaged by ‘Erich Eckner’ on parabola and the parabola package has a higher version number and later build date - maybe my mirrorlist is wonky on arch32 but it is the default one that was installed

<pre>
arch32:
package: 4ti2-1.6.7-1
build date: 1497644502
packager: Unknown Packager

parabola:
package: 4ti2-1.6.9-1.0
build date: 1536224793
packager: Erich Eckner
</pre>

the script i used is attached to the corresponding parabola bug report
https://labs.parabola.nu/issues/1652 https://labs.parabola.nu/attachments/444/find-unknown-packagers Admin
Erich Eckner commented on 24.09.2018 08:47

The buildmaster now rejects package built by “Unknown Packager” - what remains is to rebuild all packages, that are already committed.
Admin
Erich Eckner commented on 24.09.2018 08:54

btw: operating on the package database is much faster than extracting every single package:

find . -name ‘*.db.tar.gz’ | \

while read -r repo; do
  tar -Oxzf "${repo}" --wildcards '*/desc' | \
    sed -n '/^%FILENAME%$\|^%PACKAGER%$/{N;s/\n/ /;p;d;}'
done | \
sed '/^%FILENAME% /{N;/\n%PACKAGER% Unknown Packager$/!d;s/\n.*//;s/^%FILENAME% //;}'

Google Cache

 53 PackagesBug ReportMediumLow [gnome-terminal]: fails to star Closed
100%
Task Description

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

 54 Packages: StableBug ReportMediumLow [pam] links against libaudit, but doesn't declare a dep ...Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Luke Shumaker - 09.10.2018
 FS#54  - [pam] links against libaudit, but doesn’t declare a dependency on [audit]

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

0×00000001 (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.

  Comments (4)
  Related Tasks (0/0)

Admin
Erich Eckner commented on 09.10.2018 20:42

pam also links against libaudit.so.1 iff rebuilt for x86_64 - but not the currently built one for x86_64:

— /dev/fd/63 2018-10-09 22:41:57.015507993 +0200
+++ /dev/fd/62 2018-10-09 22:41:57.015507993 +0200
@@ -3,9 +3,9 @@
pkgbase = pam
pkgver = 1.3.1-1
pkgarch = x86_64
-pkgbuild_sha256sum = 3a72016938e6f3e8660a0f8774b576bf58aa4c7b218948e1fadcf39a3e7ebf9d
-packager = Erich Eckner
-builddate = 1539104335
+pkgbuild_sha256sum = e178fcb37ae20afe3f75b66ec5c29bb9eaf5d5e25d032d62e01e2fc54cf2ed32
+packager = Tobias Powalowski
+builddate = 1529655718
builddir = /build
buildenv = !distcc
buildenv = color
@@ -23,129 +23,129 @@
options = !upx
options = !debug
installed = acl-2.2.53-1-x86_64
-installed = archlinux-keyring-20181003-1-any
+installed = archlinux-keyring-20180404-1-any
installed = argon2-20171227-3-x86_64
installed = attr-2.4.48-1-x86_64
-installed = audit-2.8.4-2-x86_64
installed = autoconf-2.69-4-any
-installed = automake-1.16.1-1-any
+installed = automake-1.15.1-1-any
installed = bash-4.4.023-1-x86_64
-installed = binutils-2.31.1-3-x86_64
+installed = binutils-2.30-5-x86_64
installed = bison-3.0.5-1-x86_64
-installed = bzip2-1.0.6-8-x86_64
-installed = ca-certificates-20180821-1-any
-installed = ca-certificates-mozilla-3.39-1-x86_64
-installed = ca-certificates-utils-20180821-1-any
-installed = coreutils-8.30-1-x86_64
+installed = bzip2-1.0.6-7-x86_64
+installed = ca-certificates-20170307-1-any
+installed = ca-certificates-cacert-20140824-4-any
+installed = ca-certificates-mozilla-3.37.3-1-x86_64
+installed = ca-certificates-utils-20170307-1-any
+installed = coreutils-8.29-1-x86_64
installed = cracklib-2.9.6-1-x86_64
-installed = cryptsetup-2.0.4-1-x86_64
-installed = curl-7.61.1-3-x86_64
+installed = cryptsetup-2.0.3-2-x86_64
+installed = curl-7.60.0-1-x86_64
installed = db-5.3.28-4-x86_64
-installed = dbus-1.12.10-2-x86_64
-installed = device-mapper-2.02.181-1-x86_64
+installed = dbus-1.12.8-1-x86_64
+installed = device-mapper-2.02.177-5-x86_64
installed = diffutils-3.6-1-x86_64
-installed = docbook-xml-4.5-8-any
+installed = docbook-xml-4.5-7-any
installed = docbook-xsl-1.79.2-4-any
-installed = e2fsprogs-1.44.4-1-x86_64
-installed = expat-2.2.6-1-x86_64
-installed = fakeroot-1.23-1-x86_64
-installed = file-5.34-1-x86_64
-installed = filesystem-2018.8-1-x86_64
+installed = e2fsprogs-1.44.2-1-x86_64
+installed = expat-2.2.5-1-x86_64
+installed = fakeroot-1.22-1-x86_64
+installed = file-5.33-3-x86_64
+installed = filesystem-2018.1-2-x86_64
installed = findutils-4.6.0-2-x86_64
installed = flex-2.6.4-1-x86_64
installed = gawk-4.2.1-1-x86_64
-installed = gc-7.6.8-1-x86_64
-installed = gcc-8.2.1+20180831-1-x86_64
-installed = gcc-libs-8.2.1+20180831-1-x86_64
-installed = gdbm-1.18-1-x86_64
+installed = gc-7.6.6-1-x86_64
+installed = gcc-8.1.1+20180531-1-x86_64
+installed = gcc-libs-8.1.1+20180531-1-x86_64
+installed = gdbm-1.14.1-1-x86_64
installed = gettext-0.19.8.1-2-x86_64
-installed = glib2-2.58.1-1-x86_64
-installed = glibc-2.28-4-x86_64
+installed = glib2-2.56.1-1-x86_64
+installed = glibc-2.27-3-x86_64
installed = gmp-6.1.2-1-x86_64
-installed = gnupg-2.2.10-1-x86_64
-installed = gnutls-3.5.19-2-x86_64
-installed = gpgme-1.11.1-2-x86_64
-installed = gpm-1.20.7.r27.g1fd1941-1-x86_64
+installed = gnupg-2.2.8-1-x86_64
+installed = gnutls-3.5.18-1-x86_64
+installed = gpgme-1.11.1-1-x86_64
+installed = gpm-1.20.7-8-x86_64
installed = grep-3.1-1-x86_64
installed = groff-1.22.3-7-x86_64
-installed = guile-2.2.4-1-x86_64
+installed = guile-2.2.3-1-x86_64
installed = gzip-1.9-1-x86_64
-installed = hwids-20180518-1-any
-installed = iana-etc-20180913-1-any
-installed = icu-62.1-1-x86_64
-installed = iptables-1:1.6.2-3-x86_64
-installed = json-c-0.13.1-2-x86_64
+installed = hwids-20171003-1-any
+installed = iana-etc-20180221-1-any
+installed = icu-61.1-1-x86_64
+installed = iptables-1.6.2-2-x86_64
+installed = json-c-0.13.1-1-x86_64
installed = kbd-2.0.4-1-x86_64
-installed = keyutils-1.5.11-1-x86_64
+installed = keyutils-1.5.10-2-x86_64
installed = kmod-25-1-x86_64
installed = krb5-1.16.1-1-x86_64
installed = less-530-1-x86_64
-installed = libarchive-3.3.3-1-x86_64
+installed = libarchive-3.3.2-2-x86_64
installed = libassuan-2.5.1-1-x86_64
-installed = libatomic_ops-7.6.6-1-x86_64
+installed = libatomic_ops-7.6.4-1-x86_64
installed = libcap-2.25-1-x86_64
installed = libcap-ng-0.7.9-1-x86_64
-installed = libelf-0.174-1-x86_64
+installed = libelf-0.171-1-x86_64
installed = libffi-3.2.1-2-x86_64
installed = libgcrypt-1.8.3-1-x86_64
-installed = libgpg-error-1.32-1-x86_64
+installed = libgpg-error-1.31-1-x86_64
+installed = libidn-1.34-2-x86_64
installed = libidn2-2.0.5-1-x86_64
installed = libksba-1.3.5-1-x86_64
-installed = libldap-2.4.46-2-x86_64
+installed = libldap-2.4.46-1-x86_64
installed = libmnl-1.0.4-1-x86_64
installed = libmpc-1.1.0-1-x86_64
-installed = libnftnl-1.1.1-1-x86_64
-installed = libnghttp2-1.33.0-1-x86_64
+installed = libnftnl-1.1.0-1-x86_64
+installed = libnghttp2-1.31.1-1-x86_64
installed = libnl-3.4.0-1-x86_64
-installed = libpcap-1.9.0-1-x86_64
+installed = libpcap-1.8.1-2-x86_64
installed = libpsl-0.20.2-1-x86_64
-installed = libsasl-2.1.26-13-x86_64
-installed = libseccomp-2.3.3-1-x86_64
+installed = libsasl-2.1.26-12-x86_64
+installed = libseccomp-2.3.2-2-x86_64
installed = libsecret-0.18.6-1-x86_64
installed = libssh2-1.8.0-2-x86_64
-installed = libsystemd-239.2-1-x86_64
+installed = libsystemd-238.133-4-x86_64
installed = libtasn1-4.13-1-x86_64
-installed = libtirpc-1.1.4-1-x86_64
-installed = libtool-2.4.6+42+gb88cebd5-2-x86_64
+installed = libtirpc-1.0.3-2-x86_64
+installed = libtool-2.4.6+40+g6ca5e224-7-x86_64
installed = libunistring-0.9.10-1-x86_64
installed = libusb-1.0.22-1-x86_64
-installed = libutil-linux-2.32.1-2-x86_64
-installed = libxml2-2.9.8-5-x86_64
+installed = libutil-linux-2.32-3-x86_64
+installed = libxml2-2.9.8-2-x86_64
installed = libxslt-1.1.32+3+g32c88216-1-x86_64
-installed = linux-api-headers-4.17.11-1-any
-installed = lz4-1:1.8.3-1-x86_64
+installed = linux-api-headers-4.16.1-1-any
+installed = lz4-1:1.8.2-2-x86_64
installed = m4-1.4.18-1-x86_64
installed = make-4.2.1-2-x86_64
installed = mpfr-4.0.1-1-x86_64
installed = ncurses-6.1-3-x86_64
installed = nettle-3.4-1-x86_64
-installed = npth-1.6-1-x86_64
-installed = openssl-1.1.1-1-x86_64
-installed = p11-kit-0.23.14-1-x86_64
-installed = pacman-5.1.1-1-x86_64
-installed = pacman-mirrorlist-20180912-1-any
-installed = pam-1.3.1-1-x86_64
+installed = npth-1.5-1-x86_64
+installed = openssl-1.1.0.h-1-x86_64
+installed = p11-kit-0.23.12-1-x86_64
+installed = pacman-5.1.0-2-x86_64
+installed = pacman-mirrorlist-20180524-1-any
+installed = pam-1.3.0-2-x86_64
installed = pambase-20171006-1-any
-installed = patch-2.7.6-3-x86_64
+installed = patch-2.7.6-1-x86_64
installed = pcre-8.42-1-x86_64
-installed = pcre2-10.32-1-x86_64
-installed = perl-5.28.0-1-x86_64
-installed = pinentry-1.1.0-4-x86_64
-installed = pkgconf-1.5.3-1-x86_64
+installed = pcre2-10.31-1-x86_64
+installed = perl-5.26.2-1-x86_64
+installed = pinentry-1.1.0-3-x86_64
+installed = pkgconf-1.4.2-2-x86_64
installed = popt-1.16-9-x86_64
installed = procps-ng-3.3.15-1-x86_64
installed = readline-7.0.005-1-x86_64
installed = sed-4.5-1-x86_64
-installed = shadow-4.6-1-x86_64
-installed = sqlite-3.25.2-1-x86_64
-installed = sudo-1.8.25.p1-1-x86_64
-installed = systemd-239.2-1-x86_64
+installed = shadow-4.5-4-x86_64
+installed = sqlite-3.24.0-1-x86_64
+installed = sudo-1.8.23-2-x86_64
+installed = systemd-238.133-4-x86_64
installed = tar-1.30-1-x86_64
installed = texinfo-6.5-1-x86_64
-installed = tzdata-2018e-2-x86_64
-installed = util-linux-2.32.1-2-x86_64
+installed = tzdata-2018e-1-any
+installed = util-linux-2.32-3-x86_64
installed = w3m-0.5.3.git20180125-1-x86_64
installed = which-2.21-2-x86_64
installed = xz-5.2.4-1-x86_64
-installed = zlib-1:1.2.11-3-x86_64
-installed = zstd-1.3.5-1-x86_64
+installed = zlib-1:1.2.11-2-x86_64
Admin
Erich Eckner commented on 09.10.2018 20:47

As can be seen, the new version of systemd pulls in audit, against which then the linking happens.
I would not do anything about this issue (if that’s ok with you, Luke), because:
1st it only affects systems w/o systemd - e.g. non-standard systems
2nd it will solve itself with the next (upstream) release/rebuild of pam (or at least, if upstream does not add audit to the depends, it will become an upstream bug which we should report to them)

regards,
Erich
Luke Shumaker commented on 09.10.2018 21:28

Parabola supports OpenRC, so this risks breaking sudo for Parabola OpenRC users, making it more severe for us downstream than it is for you.

That isn’t to say that you have to take actionand fix it for us; it is a low-priority bug for Arch Linux 32 users, so if you want to wait for it to be resolved in upsteam Arch, that’s your prerogative. But it means that in the mean-time, Parabola will have to repackage it to avoid breaking our OpenRC users’ boxes.
bill auger commented on 10.10.2018 01:16

related to: https://bugs.archlinux.org/task/60365

Google Cache

 55 PackagesBug ReportMediumLow Unknown bug FS#55 Closed
100%
Task Description

no task description

 56 PackagesBug ReportMediumLow libreoffice-fresh 6.1.3-1.0 in [extra] is not build aga ...Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Raphael Scholer - 11.11.2018
Last edited by Erich Eckner - 14.11.2018
 FS#56  - libreoffice-fresh 6.1.3-1.0 in [extra] is not build against packages in it

libreoffice-fresh seems not to be build against packages in [extra], but rather against packages in [*testing].

Running libreoffice produces the following error message:

/usr/lib/libreoffice/program/soffice.bin: error while loading shared libraries: liborcus-0.14.so.0: cannot open shared object file: No such file or directory

extra/liborcus is 0.13.4-3.1
testing/liborcus is 0.14.1-1.0
Closed by Erich Eckner
14.11.2018 18:05
Reason for closing: Fixed

  Comments (1)
  Related Tasks (0/0)

Admin
Erich Eckner commented on 12.11.2018 10:37

I moved liborcus and libixion from testing to extra - now it should work.

Google Cache

 57 Packages: StableBug ReportMediumLow libc fails on AMD-K6 Closed
100%
Task Description

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 &lt;+0&gt;:     test   %al,%al
 0xb7ff22f2 &lt;+2&gt;:     jne    0xb7ff22e8
 0xb7ff22f4 &lt;+4&gt;:     xor    %eax,%eax
 0xb7ff22f6 &lt;+6&gt;:     ret    
 0xb7ff22f7 &lt;+7&gt;:     mov    $0x1,%eax
 0xb7ff22fc &lt;+12&gt;:    mov    $0xffffffff,%ecx

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

 0xb7ff2304 &lt;+20&gt;:    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

 58 Packages: StableBug ReportMediumLow texlive-bin doesn't build Closed
100%
Task Description

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 …

 59 PackagesBug ReportMediumLow unison segfault Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 10.01.2019
Last edited by Andreas Baumann - 10.01.2019
 FS#59  - unison segfault

Calling unison, a file synchronizer written in Ocaml. Segfaults.
Most likely a string optimization inside Ocaml itself or a non-matching
library somewhere (recompile ocaml?)

(gdb) bt
#0 0x006782df in caml_string_equal ()
#1 0x005ce0d8 in camlUpdatearchiveMode_802888 ()
#2 0x005ce6e5 in camlUpdate
setArchiveData_802926 ()
#3 0x005da668 in camlGlobalsfun_802549 ()
#4 0x005fed99 in camlLwt_util
map_1080 ()
#5 0x005fedac in camlLwt_utilmap_1080 ()
#6 0x005da5b9 in camlGlobals
allRootsMap_301891 ()
#7 0x005cea7f in camlUpdateloadArchives_802958 ()
#8 0x005d4637 in camlUpdate
findUpdatesOnPaths_2603478 ()
#9 0x005b36f5 in camlUitextsynchronizeOnce_1102725 ()
#10 0x005b4041 in camlUitext
loop_1203129 ()
#11 0x005b41d6 in camlUitextsynchronizeUntilDone_1203134 ()
#12 0x005b442e in camlUitext
start_1303143 ()
#13 0x005acc54 in camlMainBody_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 ()

Closed by Andreas Baumann
10.01.2019 14:15
Reason for closing: Not a bug
Additional comments about closing:

Cannot reprodduce but on a single machine. Might as well be something completly different..

  Comments (6)
  Related Tasks (0/0)

Admin
Erich Eckner commented on 10.01.2019 08:31

easy trials first: let’s recompile ocaml
Admin
Andreas Baumann commented on 10.01.2019 09:30

Some things seem to be wrong here:

Warning 3: deprecated: Stdlib.String.capitalize
Use String.capitalize_ascii instead.
File “/build/unison/src/unison-2.51.2/build/src/uigtk2.ml”, line 1:
Error: /usr/lib/ocaml/lablgtk2/pango.cmi
is not a compiled interface for this version of OCaml.
It seems to be for an older version of OCaml.
make[1]: * [Makefile.OCaml:423: uigtk2.cmx] Error 2
make[1]: Leaving directory ‘/build/unison/src/unison-2.51.2/build/src’ make:
* [Makefile:14: src] Error 2

Admin
Andreas Baumann commented on 10.01.2019 09:56

rebuilding lablgtk2 now.
Admin
Andreas Baumann commented on 10.01.2019 11:29

rebuilding unison didn’t help.
Admin
Andreas Baumann commented on 10.01.2019 11:35

Ok, let’s rebuild ocaml itself.
Admin
Andreas Baumann commented on 10.01.2019 12:51

works on two vms (libvirt and Virtualbox), but not on my real eeepc.

Google Cache

 60 Packages: Build-listBug ReportMediumLow lightdm gtk greeter fails Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 10.01.2019
Last edited by Andreas Baumann - 20.01.2019
 FS#60  - lightdm gtk greeter fails

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)

Closed by Andreas Baumann
20.01.2019 16:04
Reason for closing: Fixed
Additional comments about closing:

hotfixed in lightdm-1:1.28.0-1.3

  Comments (12)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 19.01.2019 07:49

So, this happens when registering a signal handler: g_unix_signal_add.

Usually this points into the direction of ABI mismatches..
Admin
Andreas Baumann commented on 19.01.2019 08:07

[+0.83s] DEBUG: Session pid=3468: Running command /usr/bin/lightdm-gtk-greeter
[+0.83s] DEBUG: Creating shared data directory /var/lib/lightdm-data/lightdm
[+0.83s] DEBUG: Session pid=3468: Logging to /var/log/lightdm/seat0-greeter.log
[+1.45s] DEBUG: Seat seat0: Stopping; failed to start a greeter

the logfile is empty.

So, the question is, why doesn’t the greeter start and segfault.
Admin
Andreas Baumann commented on 19.01.2019 09:19

rebuilt both lightdm-gtk-greeter and glib2 with debugging information (options=debug in PKGBUILD).

Now the stacktrace looks like:

#0 0xb7178b25 in _g_log_abort (breakpoint=1) at ../glib/glib/gmessages.c:554
554 G_BREAKPOINT ();
(gdb) bt
#0 0xb7178b25 in _g_log_abort (breakpoint=1) at ../glib/glib/gmessages.c:554
#1 0xb716d230 in g_log_default_handler

  (log_domain=0xb71b40d0 "GLib", log_level=6, message=0x78ee60 "creating thread 'gmain': Error creating thread: Resource temporarily unavailable", unused_data=0x0) at ../glib/glib/gmessages.c:3111

#2 0xb7178d7d in g_logv

  (log_domain=0xb71b40d0 "GLib", log_level=G_LOG_LEVEL_ERROR, format=0xb7207a67 "creating thread '%s': %s", args=0xbf85e91c "\262\320 \267") at ../glib/glib/gmessages.c:1350

#3 0xb7178f55 in g_log

  (log_domain=0xb71b40d0 "GLib", log_level=G_LOG_LEVEL_ERROR, format=0xb7207a67 "creating thread '%s': %s") at ../glib/glib/gmessages.c:1413

#4 0xb715f67a in g_thread_new (name=0xb720d0b2 “gmain”, func=0xb7180b70 , data=0×0)

  at ../glib/glib/gthread.c:830

#5 0xb717fa1e in g_get_worker_context () at ../glib/glib/gmain.c:5888
#6 0xb717fa7a in ref_unix_signal_handler_unlocked (signum=15, signum=)

  at ../glib/glib/gmain.c:5224

#7 0xb71348d7 in _g_main_create_unix_signal_watch (signum=15) at ../glib/glib/gmain.c:5332
#8 0xb71348d7 in g_unix_signal_source_new (signum=15, signum=)

  at ../glib/glib/glib-unix.c:222

#9 0xb71373ef in g_unix_signal_add_full

  (priority=0, signum=15, handler=0x495f90 , user_data=0x1, notify=0x0)
  at ../glib/glib/glib-unix.c:252

#10 0xb7137463 in g_unix_signal_add (signum=15, handler=0x495f90 , user_data=0×1)
–Type for more, q to quit, c to continue without paging–

  at ../glib/glib/glib-unix.c:283

#11 0×00490145 in main (argc=, argv=) at lightdm-gtk-greeter.c:2768

Admin
Andreas Baumann commented on 19.01.2019 09:44

creating thread ‘gmain’: Error creating thread: Resource temporarily unavailable

This is the interesting one. Why should creating a thread run out of resources? And which
resources?
Admin
Andreas Baumann commented on 19.01.2019 09:47

This is not by any chance an unhandled EAGAIN?
Admin
Andreas Baumann commented on 19.01.2019 10:04

[pid 6607] execve(”/usr/bin/core_perl/plymouth”, [”plymouth”, “–ping”], 0xbfa9086c /* 22 vars */) = -1 ENOENT (No such file or directory)

this seems a collateral damage (aka hard-coded call to the bootup manager plymouth), not every
Linux distribution has a plymouth, so I hope, this is actually optional..
The -ping indicates, that plymouth is started with ping, to see whether it is around.
It doesn’t seem to have something to do with our problem though..

There is a strace entry showing the greeter gets started:

[pid 6616] execve(”/usr/bin/lightdm-gtk-greeter”, [”/usr/bin/lightdm-gtk-greeter”], 0xf61510 /* 15 vars */) = 0

later the sighandler tries to open a new thread:

825 GThread *thread;
826
827 thread = g_thread_new_internal (name, g_thread_proxy, func, data, 0, &amp;error);
828
829 if G_UNLIKELY (thread == NULL)
830 g_error (”creating thread ‘%s’: %s”, name ? name : ““, error-&gt;message);
831
832 return thread;

So, if it runs out of resources here (due to a systemd limit, rlimit thing), this would
explain the startup issues..

There is also a suspicious:

[pid 6616] mmap2(NULL, 8392704, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = -1 EAGAIN (Resource temporarily unavailable)

So, I check the rlimit settings used by systemd for login session..
Admin
Andreas Baumann commented on 20.01.2019 09:21

Sounds related:

https://github.com/abrt/faf/issues/212 Admin
Andreas Baumann commented on 20.01.2019 10:37

mmh. why does lightdm-gtk-greeter work on 64-bit Archlinux?
Admin
Andreas Baumann commented on 20.01.2019 10:55

aha. the mmap works there.
Admin
Andreas Baumann commented on 20.01.2019 13:54

lightdm-gtk-greeter.c

mlockall (MCL_CURRENT | MCL_FUTURE);

commenting that out lets the mmap2 succeed.

As we deal with passwords, just disabling the locking is maybe not the best idea.

Incrementing the systemd limit in lightdm.conf LimitMEMLOCK=2684354560
didn’t help at all.
Admin
Andreas Baumann commented on 20.01.2019 13:58

Locking the whole greeter with all GTK inside is maybe also not the wisest idea..
Admin
Andreas Baumann commented on 20.01.2019 14:03

LimitMEMLOCK=infinity in /lib/systemd/system/lightdm.service seemed so help.

Google Cache

 61 Packages: StableBug ReportMediumLow dmd fails to build with evalu8.d:function evalu8(elem . ...Closed
100%
Task Description

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

 62 Packages: TestingBug ReportMediumLow sddm-greeter aborts Closed
100%
Task Description

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

 64 Packages: StableBug ReportMediumLow [wireguard] wireguard-arch-0.0.20190227-3.0-i686 does n ...Closed
100%
Task Description

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

 65 Packages: StableBug ReportMediumLow [qt5-styleplugins] incompatile QT version Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by bill auger - 08.04.2019
 FS#65  - [qt5-styleplugins] incompatile QT version

i can not get any QT program to start while that is installed - they complain about mixed QT versions

it looks like qt5-styleplugins was built with the [testing] repo enabled, with qt5-base-5.12.2, while other QT-base programs were built against qt5-base-5.12.1

  Comments (4)
  Related Tasks (0/0)

bill auger commented on 08.04.2019 16:47

$ qv4l2
Cannot mix incompatible Qt library (version 0x50c02) with this library (version 0x50c01)
Aborted (core dumped)
$ sudo octopi
Cannot mix incompatible Qt library (version 0x50c02) with this library (version 0x50c01)
Aborted
$ sudo calamares
Cannot mix incompatible Qt library (version 0x50c02) with this library (version 0x50c01)
Aborted
$ sudo qtox
[16:43:22.069 UTC] :0 : Fatal: Cannot mix incompatible Qt library (version 0x50c02) with this library (version 0x50c01)
Aborted

Admin
Erich Eckner commented on 08.04.2019 19:36

where does qt see this versions?
The symbols in e.g. usr/lib/libQt5-Widgets.so.5.* do not have the least version part:

14 0×02 0x08a28110 Qt_5.10

    Qt_5.9 

15 0×02 0x08a28111 Qt_5.11

    Qt_5.10 

16 0×00 0x08a28112 Qt_5.12

    Qt_5.11 

required from libQt5Core.so.5:

0x08a28112 0x00 22 Qt_5.12
0x00058a25 0x00 03 Qt_5

required from libQt5Widgets.so.5:

0x00058a25 0x00 02 Qt_5

bill auger commented on 30.04.2019 11:16

i read on the web somewhere that all QT programs search the system very aggressively searching for any QT libs it can find (and presumably selecting the newest)

what i have noticed is that this is an interaction between the packages: ‘qt5-styleplugins’ (the themes) and ‘qt5ct’ (the config system) - the presence of either package alone is not enough to cause the problem - the problem occurs only when the ‘gtk2’ theme is selected in the qt5ct config - this is the default configuration that the parabola LXDE liveISO boots into, that config is prepared when building the ISO; so i did not notice this before; but on a manual install, i noticed the qt5ct program crashes when selecting the theme

to reproduce this symptom:
install both ‘qt5-styleplugins’ and ‘qt5ct’ launch qt5ct
select gtk2 from the “Style” select options

$ gdb qt5ct
GNU gdb (GDB) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type “show copying” and “show warranty” for details.
This GDB was configured as “i686-pc-linux-gnu”.
Type “show configuration” for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:

  .

For help, type “help”.
Type “apropos word” to search for commands related to “word”… Reading symbols from qt5ct…(no debugging symbols found)…done.
(gdb) run
Starting program: /usr/bin/qt5ct
[Thread debugging using libthread_db enabled]
Using host libthread_db library “/usr/lib/libthread_db.so.1”.
[New Thread 0xb3c40b40 (LWP 9932)]

(qt5ct:9928): dbind-WARNING : 11:06:08.450: Couldn’t connect to accessibility bus: Failed to connect to socket /tmp/dbus-nltxAHENFr: Connection refused
Configuration path: “/home/bill/.config/qt5ct” Shared QSS paths: (”/home/bill/.local/share/qt5ct/qss”, “/usr/local/share/qt5ct/qss”, “/usr/share/qt5ct/qss”, “/usr/share/gdm/qt5ct/qss”, “/var/lib/menu-xdg/qt5ct/qss”)
Shared color scheme paths: (”/home/bill/.local/share/qt5ct/colors”, “/usr/local/share/qt5ct/colors”, “/usr/share/qt5ct/colors”, “/usr/share/gdm/qt5ct/colors”, “/var/lib/menu-xdg/qt5ct/colors”)
[New Thread 0xb1ff2b40 (LWP 9933)]
libEGL warning: DRI2: failed to authenticate
libEGL warning: MESA-LOADER: failed to open swrast (search paths /usr/lib/dri) libEGL warning: MESA-LOADER: failed to open swrast (search paths /usr/lib/dri) libEGL warning: DRI2: failed to authenticate
libEGL warning: MESA-LOADER: failed to open swrast (search paths /usr/lib/dri) libEGL warning: MESA-LOADER: failed to open swrast (search paths /usr/lib/dri) [this is where i selected the GTK theme] Cannot mix incompatible Qt library (version 0x50c02) with this library (version 0x50c01) Thread 1 “qt5ct” received signal SIGABRT, Aborted.
0xb7fd5841 in kernel_vsyscall ()
(gdb) bt
#0 0xb7fd5841 in
kernel_vsyscall ()
#1 0xb6a2e746 in raise () at /usr/lib/libc.so.6
#2 0xb6a181e3 in abort () at /usr/lib/libc.so.6
#3 0xb6da9775 in () at /usr/lib/libQt5Core.so.5
#4 0xb6dc09d1 in () at /usr/lib/libQt5Core.so.5
#5 0xb1268540 in () at /usr/lib/qt/plugins/styles/libqgtk2style.so
#6 0xb125620b in () at /usr/lib/qt/plugins/styles/libqgtk2style.so
#7 0xb126b3ad in () at /usr/lib/qt/plugins/styles/libqgtk2style.so
#8 0xb79ecd9a in QStyleFactory::create(QString const&amp;) () at /usr/lib/libQt5Widgets.so.5
#9 0x00411d2f in ()
#10 0x0042e2fd in ()
#11 0x0042e4a3 in ()
#12 0xb6fbc929 in QMetaObject::activate(QObject*, int, int, void
) ()

  at /usr/lib/libQt5Core.so.5

#13 0xb7a85121 in QComboBox::activated(QString const&amp;) () at /usr/lib/libQt5Widgets.so.5
#14 0xb7a876d4 in () at /usr/lib/libQt5Widgets.so.5
#15 0xb7a8a454 in () at /usr/lib/libQt5Widgets.so.5
#16 0xb7a90276 in () at /usr/lib/libQt5Widgets.so.5
#17 0xb6fbc861 in QMetaObject::activate(QObject*, int, int, void) ()
at /usr/lib/libQt5Core.so.5
#18 0xb7a853c1 in QComboBoxPrivateContainer::itemSelected(QModelIndex const&amp;) ()
at /usr/lib/libQt5Widgets.so.5
#19 0xb7a85ae0 in QComboBoxPrivateContainer::eventFilter(QObject*, QEvent*) ()
at /usr/lib/libQt5Widgets.so.5
#20 0xb6f908cc in QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*)
() at /usr/lib/libQt5Core.so.5
#21 0xb79708b8 in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
at /usr/lib/libQt5Widgets.so.5
#22 0xb7979108 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5
#23 0xb6f90bc5 in QCoreApplication::notifyInternal2(QObject*, QEvent*) ()
at /usr/lib/libQt5Core.so.5
#24 0xb7977e61 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWid– get*, QWidget
, QPointer&amp;, bool, bool) () at /usr/lib/libQt5Widgets.so.5
#25 0xb79d636c in () at /usr/lib/libQt5Widgets.so.5
#26 0xb79d90ea in () at /usr/lib/libQt5Widgets.so.5
#27 0xb79708c9 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5
#28 0xb7978aa2 in QApplication::notify(QObject*, QEvent*) () at /usr/lib/libQt5Widgets.so.5
#29 0xb6f90bc5 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib/libQt5Core.so.5
#30 0xb735fb9e in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) () at /usr/lib/libQt5Gui.so.5
#31 0xb7361172 in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) () at /usr/lib/libQt5Gui.so.5
#32 0xb73358c5 in QWindowSystemInterface::sendWindowSystemEvents(QFlags) () at /usr/lib/libQt5Gui.so.5
#33 0xb3f5b0ad in () at /usr/lib/libQt5XcbQpa.so.5
#34 0xb602792e in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#35 0xb60299ea in () at /usr/lib/libglib-2.0.so.0
#36 0xb6029a36 in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#37 0xb6feaceb in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/libQt5Core.so.5
#38 0xb6f8f656 in QEventLoop::exec(QFlags) () at /usr/lib/libQt5Core.so.5
#39 0xb6f97eeb in QCoreApplication::exec() () at /usr/lib/libQt5Core.so.5
#40 0x0040d36d in ()
#41 0xb6a19a49 in __libc_start_main () at /usr/lib/libc.so.6
#42 0x0040d505 in ()
(gdb)

bill auger commented on 08.05.2019 15:39

it looks like the latest rebuilds have leap-frogged the version conflict

previously:

Cannot mix incompatible Qt library (version 0x50c02) with this library (version 0x50c01)

today:

Cannot mix incompatible Qt library (version 0x50c02) with this library (version 0x50c03)

my guess is that either ‘qt5-styleplugins’ or ‘qt5ct’ still need a rebuild

Google Cache

Bing Cache

 66 Packages: StableBug ReportMediumLow clang is broken due to library dependencies Closed
100%
Task Description

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 …

 67 Packages: StableBug ReportMediumLow ldc segfault - Arch Linux Closed
100%
Task Description

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 …

 69 Packages: Build-listBug ReportMediumLow firefox breaks heavily in micro-optimized code Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 09.05.2019
Last edited by Andreas Baumann - 09.05.2019
 FS#69  - firefox breaks heavily in micro-optimized code

The root cause is rust is not recompiling currently.

The log in detail:

14:57.22 error[E0432]: unresolved import `simd_funcs`
14:57.22 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/x_user_defined.rs:16:1 3
14:57.22 |
14:57.22 16 | use simd_funcs::*;
14:57.22 | ^^^^^^^^^^ maybe a missing `extern crate simd_funcs;`?
14:57.22 error[E0432]: unresolved import `packed_simd`
14:57.22 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/x_user_defined.rs:17:1 3
14:57.22 |
14:57.22 17 | use packed_simd::u16x8;
14:57.22 | ^^^^^^^^^^^ maybe a missing `extern crate packed_simd;`?
14:57.45 error[E0425]: cannot find function `load16_unaligned` in this scope
14:57.45 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/x_user_defined.rs:120 :34
14:57.45 |
14:57.45 120 | let input = unsafe { load16_unaligned(src_ptr.add(i * 16)) };
14:57.45 | ^^^^^^^^^^^^^^^^ not found in this scope
14:57.45 error[E0425]: cannot find function `simd_unpack` in this scope
14:57.45 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/x_user_defined.rs:121 :35
14:57.45 |
14:57.45 121 | let (first, second) = simd_unpack(input);
14:57.45 | ^^^^^^^^^^^ not found in this scope
14:57.45 error[E0425]: cannot find function `store8_unaligned` in this scope
14:57.45 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/x_user_defined.rs:123 :17
14:57.45 |
14:57.45 123 | store8_unaligned(dst_ptr.add(i * 16), shift_upper(first));
14:57.45 | ^^^^^^^^^^^^^^^^ not found in this scope
14:57.45 error[E0425]: cannot find function `store8_unaligned` in this scope
14:57.45 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/x_user_defined.rs:124 :17
14:57.45 |
14:57.45 124 | store8_unaligned(dst_ptr.add1);
14:57.45 | ^^^^^^^^^^^^^^^^ not found in this scope
14:57.46 error[E0412]: cannot find type `u16x8` in this scope
14:57.46 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:121:40
14:57.46 |
14:57.46 121 | pub fn simd_at(&amp;self, i: usize) -&gt; u16x8 {
14:57.46 | ^^^^^ not found in this scope
14:57.46 error[E0425]: cannot find value `SIMD_STRIDE_SIZE` in this scope
14:57.46 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:122:21
14:57.46 |
14:57.46 122 | assert!(i + SIMD_STRIDE_SIZE / 2 &lt;= self.len);
14:57.46 | ^^^^^^^^^^^^^^^^ help: a constant with a similar name exists: `ALU_STR IDE_SIZE`
14:57.47 error[E0425]: cannot find function `to_u16_lanes` in this scope
14:57.47 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:124:18
14:57.47 |
14:57.47 124 | unsafe { to_u16_lanes(load16_unaligned(self.ptr.add(byte_index))) }
14:57.47 | ^^^^^^^^^^^^ not found in this scope
14:57.47 error[E0425]: cannot find function `load16_unaligned` in this scope
14:57.47 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:124:31
14:57.47 |
14:57.47 124 | unsafe { to_u16_lanes(load16_unaligned(self.ptr.add(byte_index))) }
14:57.47 | ^^^^^^^^^^^^^^^^ not found in this scope
14:57.47 error[E0425]: cannot find value `SIMD_STRIDE_SIZE` in this scope
14:57.47 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:145:12
14:57.47 |
14:57.47 145 | if SIMD_STRIDE_SIZE / 2 &lt;= self.len {
14:57.47 | ^^^^^^^^^^^^^^^^ help: a constant with a similar name exists: `ALU_STRIDE_SIZE`
14:57.48 error[E0425]: cannot find value `SIMD_STRIDE_SIZE` in this scope
14:57.48 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:146:47
14:57.48 |
14:57.48 146 | let len_minus_stride = self.len - SIMD_STRIDE_SIZE / 2;
14:57.48 | ^^^^^^^^^^^^^^^^ help: a constant with a sim ilar name exists: `ALU_STRIDE_SIZE`
14:57.48 error[E0425]: cannot find function `simd_byte_swap` in this scope
14:57.48 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:150:28
14:57.48 |
14:57.48 150 | simd = simd_byte_swap(simd);
14:57.48 | ^^^^^^^^^^^^^^ not found in this scope
14:57.49 error[E0425]: cannot find function `store8_unaligned` in this scope
14:57.49 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:153:21
14:57.49 |
14:57.49 153 | store8_unaligned(other.as_mut_ptr().add(offset), simd);
14:57.49 | ^^^^^^^^^^^^^^^^ not found in this scope
14:57.49 error[E0425]: cannot find function `contains_surrogates` in this scope
14:57.49 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:155:20
14:57.49 |
14:57.49 155 | if contains_surrogates(simd) {
14:57.49 | ^^^^^^^^^^^^^^^^^^^ not found in this scope
14:57.49 error[E0425]: cannot find value `SIMD_STRIDE_SIZE` in this scope
14:57.49 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:158:27
14:57.49 |
14:57.49 158 | offset += SIMD_STRIDE_SIZE / 2;
14:57.49 | ^^^^^^^^^^^^^^^^ help: a constant with a similar name exists: `A LU_STRIDE_SIZE`
14:57.50 error[E0425]: cannot find value `SIMD_STRIDE_SIZE` in this scope
14:57.50 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:237:8
14:57.50 |
14:57.50 237 | if SIMD_STRIDE_SIZE &lt;= len {
14:57.50 | ^^^^^^^^^^^^^^^^ help: a constant with a similar name exists: `ALU_STRIDE_SIZE`
14:57.50 error[E0425]: cannot find value `SIMD_STRIDE_SIZE` in this scope
14:57.50 error[E0425]: cannot find value `SIMD_STRIDE_SIZE` in this scope
14:57.50 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:237:8
14:57.50 |
14:57.50 237 | if SIMD_STRIDE_SIZE &lt;= len {
14:57.50 | ^^^^^^^^^^^^^^^^ help: a constant with a similar name exists: `ALU_STRIDE_SIZE`
14:57.50 error[E0425]: cannot find value `SIMD_STRIDE_SIZE` in this scope
14:57.50 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:238:38
14:57.50 |
14:57.50 238 | let len_minus_stride = len - SIMD_STRIDE_SIZE;
14:57.50 | ^^^^^^^^^^^^^^^^ help: a constant with a similar name exists: `ALU_STRIDE_SIZE`
14:57.51 error[E0425]: cannot find value `SIMD_STRIDE_SIZE` in this scope
14:57.51 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:241:52
14:57.51 |
14:57.51 241 | let mut second = src.simd_at(offset + (SIMD_STRIDE_SIZE / 2));
14:57.51 | ^^^^^^^^^^^^^^^^ help: a constant with a similar name exists: `ALU_STRIDE_SIZE`
14:57.51 error[E0425]: cannot find function `simd_byte_swap` in this scope
14:57.51 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:243:25
14:57.51 |
14:57.51 243 | first = simd_byte_swap(first);
14:57.51 | ^^^^^^^^^^^^^^ not found in this scope
14:57.52 error[E0425]: cannot find function `simd_byte_swap` in this scope
14:57.52 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:244:26
14:57.52 |
14:57.52 244 | second = simd_byte_swap(second);
14:57.52 | ^^^^^^^^^^^^^^ not found in this scope
14:57.52 error[E0425]: cannot find function `simd_is_basic_latin` in this scope
14:57.52 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:246:17
14:57.52 |
14:57.52 246 | if !simd_is_basic_latin(first | second) {
14:57.52 | ^^^^^^^^^^^^^^^^^^^ help: a function with a similar name exists: `ascii_to_basic_latin`
14:57.52 error[E0425]: cannot find function `simd_pack` in this scope
14:57.52 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:249:26
14:57.52 |
14:57.52 249 | let packed = simd_pack(first, second);
14:57.52 | ^^^^^^^^^ not found in this scope
14:57.53 error[E0425]: cannot find function `store16_unaligned` in this scope
14:57.53 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:251:17
14:57.53 |
14:57.53 251 | store16_unaligned(dst.as_mut_ptr().add(offset), packed);
14:57.53 | ^^^^^^^^^^^^^^^^^ not found in this scope
14:57.53 error[E0425]: cannot find value `SIMD_STRIDE_SIZE` in this scope
14:57.53 –&gt; /build/firefox/src/mozilla-unified/third_party/rust/encoding_rs/src/handles.rs:253:23
14:57.53 |
14:57.53 253 | offset += SIMD_STRIDE_SIZE;
14:57.53 | ^^^^^^^^^^^^^^^^ help: a constant with a similar name exists: `ALU_STRIDE_SIZE`
14:59.28 error: aborting due to 25 previous errors
14:59.28 Some errors occurred: E0412, E0425, E0432.
14:59.28 For more information about an error, try `rustc –explain E0412`.
14:59.44 error: Could not compile `encoding_rs`.

  Comments (5)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 09.05.2019 19:36

Compilation of firefox continues..

14:59.44 To learn more, run the command again with –verbose.
14:59.45 make[4]: * [/build/firefox/src/mozilla-unified/config/rules.mk:1027: force-cargo-library-build] Error 101
14:59.45 make[3]:
* [/build/firefox/src/mozilla-unified/config/recurse.mk:74: toolkit/library/rust/target] Error 2
14:59.45 make[3]: * Waiting for unfinished jobs….
17:24.43 Compiling lalrpop v0.16.0 good build system :-&gt;
Admin
Andreas Baumann commented on 09.05.2019 19:38 Let’s see how bad the situation is on pentium4, could easily be Mozilla projects get
build only for pentium4 in the future..
Admin
Andreas Baumann commented on 09.05.2019 19:46 Aha: i686 finally failed: 17:24.43 Compiling lalrpop v0.16.0
21:26.67 Compiling webidl v0.8.0
22:03.14 Compiling binjs_meta v0.4.3
22:25.46 Compiling binast v0.1.1 (/build/firefox/src/mozilla-unified/js/src/frontend/binsource)
22:58.29 Finished release [optimized] target(s) in 17m 41s
22:58.32 make[2]:
* [/build/firefox/src/mozilla-unified/config/recurse.mk:34: compile] Error 2
22:58.32 make[1]: * [/build/firefox/src/mozilla-unified/config/rules.mk:415: default] Error 2
22:58.32 make:
* [client.mk:125: build] Error 2
22:58.33 0 compiler warnings present.

Admin
Andreas Baumann commented on 10.05.2019 05:59

pentium4 seems to work fine.
Levi commented on 16.05.2019 21:08

So, is this getting dropped for i686 then? Probably no great loss; I remember when I was using a P3 in my server box, I gave up trying to use anything graphical, and just used links when I needed to look something up on t’internet.

I note in the i686 repo there’s currently a firefox 65.x rather than the 66.x we’ve got in pentium4, and some language packs that are 66 and some that are 65. English and all its variants are still on 65.x, but I note that it looks broken to me for German or Finnish users. Time to put it out of its misery?

Google Cache

1) i * 16) + 8), shift_upper(second
 71 Packages: StableBug ReportMediumLow FS#71 - rust doesn't rebuild Closed
100%
Task Description

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&gt;/dev/null || true
done &amp;
_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 "--&gt; 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

Showing tasks 51 - 100 of 349 Page 2 of 7 - 1 - 2 - 3 - 4 - 5 - Last >>

Available keyboard shortcuts

Tasklist

Task Details

Task Editing