Attached to Project: Archlinux32
Opened by Markus Schaaf - 22.10.2019
 FS#92  - nfs mounts with sec=krb5 fail with ‘stale file handle’ for everyone but root

rpc.gssd bug due to missing syscall (setgroups). See https://bugzilla.linux-nfs.org/show_bug.cgi?id=340 `journalctl –unit=rpc-gssd.service` shows:

WARNING: unable to drop supplimentary groups!
WARNING: failed to change identity: Function not implemented

Until a fixed upstream release, use
$ cat abs/packages/nfs-utils/trunk/setgroups32.patch
— nfs-utils-2.4.1/utils/gssd/gssd_proc.c.orig 2019-10-22 11:26:48.059877484 +0200
+++ nfs-utils-2.4.1/utils/gssd/gssd_proc.c 2019-10-22 11:28:03.874553996 +0200
@@ -437,7 +437,7 @@

    int res;

    /* drop list of supplimentary groups first */

- if (syscall(SYS_setgroups, 0, 0) != 0) {
+ if (syscall(SYS_setgroups32, 0, 0) != 0) {

            printerr(0, "WARNING: unable to drop supplimentary groups!");
            return errno;
    }

Google Cache

no task description

no task description

no task description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 21.09.2019
Last edited by Andreas Baumann - 21.09.2019
 FS#87  - firefox doesn’t rebuild

OOM when build gkrust:

patching out debug_level=2 in moz.configure/toolchain.configure

thanks BoidLinux for the hint.

  Comments (3)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 21.09.2019 17:05

A test is executed testing the generated Gecko rust library (a static library), whether
it contains references to networking functions, this fails on IA32:

https://hg.mozilla.org/mozilla-central/rev/47cd8671b12c

$(call py_action,check_binary,–target –networking $@)

Solution is just not to execute this check in config/makefiles/rust.mk
Admin
Andreas Baumann commented on 21.09.2019 17:08

187:52.88 toolkit/library/libxul.so
190:00.47 readelf: Error: Unable to seek to 0x801db328 for section headers
190:01.36 out of memory allocating 3761314508 bytes after a total of 1595923192 bytes
190:01.47 File “/build/firefox/src/firefox-69.0.1/python/mozbuild/mozbuild/action/check_binary.py”, line 361, in

=> python/readelf combo reads whole generated libxul.so into memory in order to do
some ELF fidding.

190:01.48 make[4]: *** [/build/firefox/src/firefox-69.0.1/config/rules.mk:661: libxul.so] Error 1

shows us:

$(SHARED_LIBRARY): $(OBJS) $(RESFILE) $(RUST_STATIC_LIB) $(STATIC_LIBS) $(EXTRA_DEPS) $(GLOBAL_DEPS)

      $(REPORT_BUILD)

ifndef INCREMENTAL_LINKER

      $(RM) $@

endif

      $(MKSHLIB) $($@_$(OBJS_VAR_SUFFIX)) $(RESFILE) $(LDFLAGS) $(STATIC_LIBS) $(RUST_STATIC_LIB) $(SHARE
      $(call py_action,check_binary,--target $@)

Trying to comment that out too (the python check).
Admin
Andreas Baumann commented on 22.09.2019 07:46

Now libxul.so misses some libraries, like libmozsandbox.so, liblgpllibs.so, … The libraries exists, but most likely libxul.so cannot find them (rpath ELF fiddling?).

As a workaround I’ll set LD_LIBRARY_PATH=/usr/lib/firefox in the startup wrapper
scripts /usr/bin/firefox.

Google Cache

no task description

Attached to Project: Archlinux32
Opened by bill auger - 13.05.2019
Last edited by Andreas Baumann - 02.10.2019
 FS#73  - [gajim] fails to launch when (optional) gupnp-igd is installed

$ gajim
No translations found
Dirs searched: [PosixPath(’/usr/local/share’), PosixPath(’/usr/share’), PosixPath(’/usr/share/gdm’), PosixPath(’/var/lib/menu-xdg’)]

(gajim:1588): dbind-WARNING : 15:14:29.481: Couldn’t connect to accessibility bus: Failed to connect to socket /tmp/dbus-Nv1LTXmb8O: Connection refused (gajim:1588): WARNING **: 15:14:29.534: Failed to load shared library ‘libgupnp-igd-1.0.so.4’ referenced by the typelib: libgupnp-1.2.so.0: cannot open shared object file: No such file or directory
/usr/lib/python3.7/site-packages/gajim/common/app.py:281: Warning: cannot retrieve class for invalid (unclassed) type ‘void’

gupnp_igd = GUPnPIgd.SimpleIgd()

Traceback (most recent call last):

File "/usr/lib/python3.7/site-packages/gajim/application.py", line 185, in _startup
  app.detect_dependencies()
File "/usr/lib/python3.7/site-packages/gajim/common/app.py", line 281, in detect_dependencies
  gupnp_igd = GUPnPIgd.SimpleIgd()

TypeError: could not get a reference to type class
Traceback (most recent call last):

File "/usr/lib/python3.7/site-packages/gajim/application.py", line 220, in _activate
  self.interface = Interface()
File "/usr/lib/python3.7/site-packages/gajim/gui_interface.py", line 2615, in __init__
  cfg_was_read = parser.read()
File "/usr/lib/python3.7/site-packages/gajim/common/optparser.py", line 86, in read
  self.update_config(old_version, new_version)
File "/usr/lib/python3.7/site-packages/gajim/common/optparser.py", line 158, in update_config
  caps_cache.capscache.initialize_from_db()

AttributeError: ‘NoneType’ object has no attribute ‘initialize_from_db’ Traceback (most recent call last):

File "/usr/lib/python3.7/site-packages/gajim/application.py", line 269, in do_shutdown
  app.logger.commit()

AttributeError: ‘NoneType’ object has no attribute ‘commit’

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

Seems to work on pentium4/stable. Feel free to reopen if you it crashes
for you..

Google Cache

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

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

(gdb) bt
#0 0x006782df in caml_string_equal ()
#1 0x005ce0d8 in camlUpdatearchiveMode_802888 ()
#2 0x005ce6e5 in camlUpdatesetArchiveData_802926 ()
#3 0x005da668 in camlGlobalsfun_802549 ()
#4 0x005fed99 in camlLwt_utilmap_1080 ()
#5 0x005fedac in camlLwt_utilmap_1080 ()
#6 0x005da5b9 in camlGlobalsallRootsMap_301891 ()
#7 0x005cea7f in camlUpdateloadArchives_802958 ()
#8 0x005d4637 in camlUpdatefindUpdatesOnPaths_2603478 ()
#9 0x005b36f5 in camlUitextsynchronizeOnce_1102725 ()
#10 0x005b4041 in camlUitextloop_1203129 ()
#11 0x005b41d6 in camlUitextsynchronizeUntilDone_1203134 ()
#12 0x005b442e in camlUitextstart_1303143 ()
#13 0x005acc54 in camlMainBody_401249 ()
#14 0x005ac19d in camlLinktextentry ()
#15 0x005a8220 in caml_program ()
#16 0x0068b64d in caml_start_program ()
#17 0x0068b9f1 in caml_startup_common ()
#18 0x0068ba6a in caml_startup ()
#19 0x005a7c25 in main ()

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

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

  Comments (6)
  Related Tasks (0/0)

Admin
Erich Eckner commented on 10.01.2019 08:31

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

Some things seem to be wrong here:

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

Admin
Andreas Baumann commented on 10.01.2019 09:56

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

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

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

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

Google Cache

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

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

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

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

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

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

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

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

no 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

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

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

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

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 …

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

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

no task description

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

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#&gt; 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

no 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!?

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

 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 …

Attached to Project: Archlinux32
Opened by Luke Shumaker - 21.11.2017
Last edited by Erich Eckner - 25.11.2017
 FS#14  - [ghc-mod] Needs rebuilt

Yesterday, I mentioned on IRC that many haskell packages need rebuilt. In response, deep42thought moved a bunch of packages from staging to stable, and told me to open a bug report if the issue persisted.

For the most part, this seems resolved. Some pacman -Qo/-Ql/ldd/grep magic tells me that all of the haskell packages I have are fine, except for [ghc-mod].
Closed by Erich Eckner
25.11.2017 14:58
Reason for closing: Fixed
Additional comments about closing:

removed - upstream removed it, too

  Comments (1)
  Related Tasks (0/0)

Luke Shumaker commented on 23.11.2017 04:47

deep42thought has removed ghc-mod, reflecting its removal in Arch. Requesting closure.

Google Cache

16.11.2017 - It’s the development version of the FOX toolkit. Breaks in some int/FXival/void * abstractions: FXWSQueue.cpp: In member function ‘FX::FXbool …

no task description

no task description

no task description

07.11.2017 - Nov 07 18:19:32 arch32-testing systemd[1]: Started Process Core Dump (PID 643/UID 0). Nov 07 18:19:35 arch32-testing …

16.12.2017 - The best, I can get is trying to compile the git HEAD with clisp (instead of sbcl). However, this still errors with: entering make-target-2.sh

07.07.2019 -  FS#80  - kate refuses to build due to some broken shared library dependencies. /usr/bin/ld: warning: libgit2.so.27, needed by …

Attached to Project: Archlinux32
Opened by Andreas Baumann - 30.05.2019
 FS#77  - librsvg doesn’t rebuild

1. -&gt; /build/librsvg/src/librsvg/target/release/build/typenum-ff577e94a786118f/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/librsvg/src/librsvg/target/release/build/typenum-ff577e94a786118f/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`.
error: Could not compile `typenum`.

Caused by:

process didn't exit successfully: `rustc --crate-name typenum /build/.cargo/registry/src/github.com-1ecc6299db9ec823/typenum-1.10.0/src/lib.rs --color never --crate-type lib --emit=dep-info,link -C opt-level=3 -C debuginfo=2 -C metadata=045a2ce7f5cfaab5 -C extra-filename=-045a2ce7f5cfaab5 --out-dir /build/librsvg/src/librsvg/target/release/deps -L dependency=/build/librsvg/src/librsvg/target/release/deps --cap-lints allow -C target-cpu=pentium3 -C target-feature=-sse2` (exit code: 1)

warning: build failed, waiting for other jobs to finish… error: build failed
make[2]: * [Makefile:1934: /build/librsvg/src/librsvg/target/release/librsvg_internals.a] Error 101
make[2]: Leaving directory ‘/build/librsvg/src/librsvg’ make[1]: * [Makefile:1438: all-recursive] Error 1
make[1]: Leaving directory ‘/build/librsvg/src/librsvg’ make: *** [Makefile:931: all] Error 2

The same error with typenum as when bootstrapping rust in stage 2.

librsvg is very important as it blocks tons of other stuff (so why
again was it written in Rust?!)

I might have seen a Debian patch for it, but Debian goes a “complete
Rust micro-packaging” way, not sure whether we can apply it here?

  Comments (1)
  Related Tasks (0/0)

Levi commented on 30.05.2019 18:26

Since it looks to me like it’s redefining P1024 and N1024 the same, can’t you just eliminate one of these definitions. Sure, it makes a patch you’d have to maintain henceforth until they fix this upstream, and I don’t understand what kind of preprocessing is ending up with this particular duplication, but deleting a line is about the simplest patch you could maintain.

Google Cache

Attached to Project: Archlinux32
Opened by Andreas Baumann - 18.05.2019
Last edited by Andreas Baumann - 16.08.2019
 FS#75  - openjdk8/10/11/12 break with march=pentium4 optimization

This blocks ant, needed for building libreoffice.
Closed by Andreas Baumann
16.08.2019 13:55
Reason for closing: Fixed
Additional comments about closing:

fixed for 8, 10, 11 and 12. Not for 7.

  Comments (34)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 18.05.2019 18:18

mmh. java is fine.

java -version
openjdk version “1.8.0_212” OpenJDK Runtime Environment (build 1.8.0_212-b01)
OpenJDK Server VM (build 25.212-b01, mixed mode)

javac
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (os_linux_x86.cpp:291), pid=124, tid=0xf6dc1b40
# fatal error: An irrecoverable SI_KERNEL SIGSEGV has occurred due to unstable signal handling in this distribution.
#
# JRE version: OpenJDK Runtime Environment (8.0_212-b01) (build 1.8.0_212-b01)
# Java VM: OpenJDK Server VM (25.212-b01 mixed mode linux-x86 )
# Core dump written. Default location: /build/libreoffice-still/core or core.124
#
# An error report file with more information is saved as:
# /build/libreoffice-still/hs_err_pid124.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp #
Aborted (core dumped)

ant
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (os_linux_x86.cpp:291), pid=155, tid=0xf6d4fb40
# fatal error: An irrecoverable SI_KERNEL SIGSEGV has occurred due to unstable signal handling in this distribution.
#
# JRE version: OpenJDK Runtime Environment (8.0_212-b01) (build 1.8.0_212-b01)
# Java VM: OpenJDK Server VM (25.212-b01 mixed mode linux-x86 )
# Core dump written. Default location: /build/libreoffice-still/core or core.155
#
# An error report file with more information is saved as:
# /build/libreoffice-still/hs_err_pid155.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.java.com/bugreport/crash.jsp #
Aborted (core dumped)

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x897c76]
V [libjvm.so+0x36392a]
V [libjvm.so+0x71341f] JVM_handle_linux_signal+0x6bf
V [libjvm.so+0x70507f]
C [linux-gate.so.1+0×950] __kernel_rt_sigreturn+0×0

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j java.lang.System.nanoTime()J+0
j java.net.URLClassLoader.defineClass(Ljava/lang/String;Lsun/misc/Resource;)Ljava/lang/Class;+0
j java.net.URLClassLoader.access$100(Ljava/net/URLClassLoader;Ljava/lang/String;Lsun/misc/Resource;)Ljava/lang/Class;+3
j java.net.URLClassLoader$1.run()Ljava/lang/Class;+43
j java.net.URLClassLoader$1.run()Ljava/lang/Object;+1
v ~StubRoutines::call_stub
j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedExceptionAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+0
j java.net.URLClassLoader.findClass(Ljava/lang/String;)Ljava/lang/Class;+13
j java.lang.ClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+70
j sun.misc.Launcher$AppClassLoader.loadClass(Ljava/lang/String;Z)Ljava/lang/Class;+81
j java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class;+3
v ~StubRoutines::call_stub
j com.sun.tools.javac.main.Main.(Ljava/lang/String;Ljava/io/PrintWriter;)V+5
j com.sun.tools.javac.main.Main.(Ljava/lang/String;)V+13
j com.sun.tools.javac.Main.compile([Ljava/lang/String;)I+6
j com.sun.tools.javac.Main.main([Ljava/lang/String;)V+1
v ~StubRoutines::call_stub
Admin
Andreas Baumann commented on 18.05.2019 18:19

well. Java errors, hard to debug..
Admin
Andreas Baumann commented on 18.05.2019 18:21

Installing the i686 version in the pentium4 chroot also segfaults..
Admin
Andreas Baumann commented on 18.05.2019 18:25

Java 686 doesn’t segfault on a real i686 installed system. So, I fear, some library in pentium4
is causing java to segfault.
Admin
Andreas Baumann commented on 18.05.2019 18:36

Event: 0.057 Thread 0xf6b07c00 Exception <a> (0xd7b86ea0) thrown at [/build/javapenjdk/src/jdk8u-jdk8u212-b01/hotspot/src/share/vm/prims/jni.cp
Event: 0.057 Thread 0xf6b07c00 Exception </a><a> (0xd7b87170) thrown at [/build/javapenjdk/src/jdk8u-jdk8u212-b01/hotspot/src/share/vm/prims/jni.cpp, line 4012]
Event: 0.231 Thread 0xf6b07c00 Exception </a><a> (0xd7cc0498) thrown at [/build/javapenjdk/src/jdk8u-jdk8u212-b01/hotspot/src/share/vm/prims/jvm.cpp, line 1502]

mmh. this sounds quite internal..
</a>
Admin
Andreas Baumann commented on 18.05.2019 18:50

pentium$:
javac -version
javac 11.0.3

why is libreoffice built with java 8?
Admin
Andreas Baumann commented on 18.05.2019 19:00

weird: on my pentium4 test machine with jdk 8 and 11 installed, I can switch to java 8
and everything is fine.
Admin
Andreas Baumann commented on 18.05.2019 19:03

I remember issues with shared libraries and the way the Jvm is bootstrapping. For
instance not having a /proc causes trouble of this sort. But we have a /proc
(we are using arch-chroot and a bind mount point).
Admin
Andreas Baumann commented on 18.05.2019 19:07

using java 11 and javac 11 on pentium4 works..
Admin
Andreas Baumann commented on 18.05.2019 19:08

..and now we get to “find the 10 differences in this picture”. Admin
Andreas Baumann commented on 18.05.2019 19:14

The only thing I can think of is a different kernel (with more protection enabled):

https://bugs.openjdk.java.net/browse/JDK-8023956 https://bugs.openjdk.java.net/browse/JDK-8181068

This cries for building it on a real Pentium4 or on a properly emulated one, not
in a chroot.
Admin
Erich Eckner commented on 22.05.2019 04:34

&gt; using java 11 and javac 11 on pentium4 works..

why not simply pin the java version to 11, then?
Admin
Andreas Baumann commented on 06.06.2019 18:19

When installing the i686 version of glibc and openjdk8 there is no segfault!
So this sounds more like a new glibc and optimization triggering something in java..
Admin
Andreas Baumann commented on 07.06.2019 16:54

Actually also original SUN java 7 segfaults with this glibc.
Rebuilding glibc didn’t help. So I’m pretty sure it’s some protection thingy
getting into the way of old Java JDKs (because they always pushed their limits
and did funny tricks in the past).
Luke commented on 18.06.2019 18:27

Erich Eckner,
Ant is still broken with pentium4 build of java 11 (i686 works).

$ archlinux-java status
Available Java environments:

java-11-openjdk (default)

Admin
Andreas Baumann commented on 19.06.2019 17:57

19:40 &lt; slacka123&gt; should use “-march=i686 -msse2 -mtune=generic -mfpmath=sse -mstackrealign” instead?
19:54 &lt; slacka123&gt; Yes, it does - https://bugs.documentfoundation.org/show_bug.cgi?id=108619
19:54 &lt; phrik&gt; Title: 108619 – (32bitjavacrash) Java Crash on x86 in jfw_plugin_startJavaVirtualMachine

             w/ recent linux kernels (at bugs.documentfoundation.org)

19:55 &lt; slacka123&gt; Fedora 30 also needs that kernel parameter, “stack_guard_gap=1” to run/build

                 LibreOffice and other java apps

… 19:56 &lt; slacka123&gt; but i686 arch32 also needs it

from the chat protocol: https://mirror.archlinux32.org/irc-logs/%23archlinux32/2019-06-19.html#19:39:59 Admin
Andreas Baumann commented on 21.06.2019 08:29

See: https://src.fedoraproject.org/rpms/glibc/blob/master/f/glibc.spec Admin
Andreas Baumann commented on 21.06.2019 12:23

Thanks slacka123 for the hint. This seems to solve the java/javac crashes.

It’s fixed now in staging and will soon hop into testing.
Admin
Andreas Baumann commented on 11.08.2019 06:03

The segfaults persist through all pentium4 versions of the openjdk.
Additionally now also the 7 version of i686 and pentium4 are segfaulting.
Admin
Andreas Baumann commented on 11.08.2019 07:11

jkd7 also cannot find libattr:

https://patchwork.openembedded.org/patch/110857/ Admin
Andreas Baumann commented on 11.08.2019 07:13

On 64-bit it complains about ant:

error: target not found: apache-ant&gt;=1.8.1

flagged out-of-date upstream, unusable currently for bootstrapping.
Admin
Andreas Baumann commented on 11.08.2019 07:56

https://bugs.archlinux.org/task/63430 Admin
Andreas Baumann commented on 11.08.2019 07:56

configure: Found potential Boot JDK using java© in PATH
configure: Potential Boot JDK found at /usr/lib/jvm/java-penjdk is incorrect JDK version (#); ignoring
configure: (Your Boot JDK must be version 7 or 8)
configure: Found potential Boot JDK using well-known locations (in /usr/lib/jvm/java-penjdk)
configure: Potential Boot JDK found at /usr/lib/jvm/java-penjdk is incorrect JDK version (#); ignoring
configure: (Your Boot JDK must be version 7 or 8)
configure: Found potential Boot JDK using well-known locations (in /usr/lib/jvm/default-runtime)
configure: Potential Boot JDK found at /usr/lib/jvm/default-runtime is incorrect JDK version (#); ignoring
configure: (Your Boot JDK must be version 7 or 8)
configure: Found potential Boot JDK using well-known locations (in /usr/lib/jvm/default)
configure: Potential Boot JDK found at /usr/lib/jvm/default is incorrect JDK version (#); ignoring
configure: (Your Boot JDK must be version 7 or 8)
configure: Could not find a valid Boot JDK.
configure: This might be fixed by explicitely setting –with-boot-jdk
configure: error: Cannot continue
configure exiting with result code 1
Admin
Andreas Baumann commented on 11.08.2019 18:02

building on i686 (where openjdk8 still works) and using makepkg.conf with pentium4
cflags gives a package with wrong architecture though, but running in a pentium4
chroot if installed.

Though when I try to rebuild it with the ‘cross-compiled’ package in a pentium4
chroot, I get:

checking headful support… include support for both headful and headless
configure: Found potential Boot JDK using configure arguments
configure: Potential Boot JDK found at /usr/lib/jvm/java-penjdk is incorrect JDK version (#); ignoring
configure: (Your Boot JDK must be version 7 or 8)
configure: error: The path given by –with-boot-jdk does not contain a valid Boot JDK configure exiting with result code 1

Inside I have a hs_err_pid3361.log showing again the darn SI_KERNEL SIGSEGV.

This problem is over my head (and skills).
Admin
Andreas Baumann commented on 12.08.2019 15:26

This sounds interesting:

https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3533

related question: is -march=pentium4 changing the stack layout?
Admin
Andreas Baumann commented on 12.08.2019 15:28

Should we force stack alignment globally for all libraries which could potentially be
called from java with -mstack-alignment=16? This could break havock on other software..
Admin
Andreas Baumann commented on 12.08.2019 15:28

Also interesting:

https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3533 Admin
Andreas Baumann commented on 12.08.2019 15:30

Also: -mincoming-stack-boundary=2

https://bugs.gentoo.org/attachment.cgi?id=522650&amp;action=diff Admin
Andreas Baumann commented on 12.08.2019 16:00

So -mstackrealign in the glibc flags helps to realign the stack, so that 4 and 16 byte stacks
can coexist, but Java generates it’s own executable code, which doesn’t respect that?
Why should -mincoming-stack-boundary=2 help then?
I’ll test again a double compilation via working i686 chroot to pentium4 (with -mincoming-stack-boundary=2 in the PKGBUILD of javapenjdk), then see if it can rebuild itself in a pentium4
chroot.
Admin
Andreas Baumann commented on 13.08.2019 04:48

Apparently this helps, thanks to the Gentoo guys. Admin
Andreas Baumann commented on 13.08.2019 05:05

Now to jdk10, jdk11 and jdk12 (weirdly enough there is no jdk9?).
Admin
Andreas Baumann commented on 15.08.2019 07:32

a working JDK8 for pentium4 hit staging. now for the other versions..
Admin
Andreas Baumann commented on 15.08.2019 11:40

This helps against GOT/PLT errors:

if test ${CARCH} = i686 -o ${CARCH} = pentium4; then
  echo "Removing '-fno-plt' from CFLAGS and CXXFLAGS to prevent build fail with th
  _CFLAGS=${CFLAGS/-fno-plt/}
  _CXXFLAGS=${CXXFLAGS/-fno-plt/}
fi

Admin
Andreas Baumann commented on 15.08.2019 12:03

Finished building targets ‘images docs’ in configuration ‘linux-x86-normal-server-release’ find: &lt;80&gt;&lt;98&gt;../jdk10u-jdk-10.0.2+13/build/linux-i386-normal-server-release/images&lt;80&gt;&lt;99&gt;: No such file or directory
ESC[1mESC[31m==&gt; ERROR:ESC[m^OESC[1m A failure occurred in build().ESC[m^O
ESC[1m Aborting…ESC[m^O
==&gt; ERROR: Build failed, check /var/lib/archbuild/staging-i686/abaumann/build
(END)

needs:

case “${CARCH}” in

x86_64) _JARCH='x86_64';;
i486|i686|pentium4)   _JARCH='x86';;

esac

Google Cache

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

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

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
&gt;&gt;&gt; defined in /build/electron/src/electron/vendor/libchromiumcontent/dist/main/static_library/libchromiumcontent.a(dct.o)
&gt;&gt;&gt; referenced by ../../third_party/openh264/src/codec/common/x86/dct.asm
&gt;&gt;&gt; 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

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

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

several failures during check() - disabling for now

==&gt; 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