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 Type  ascPrioritySeveritySummaryStatusProgress
 220 PackagesBug ReportVery HighCritical [python] completly broken Closed
100%
Task Description

Traceback (most recent call last):

File "/usr/lib/python3.9/site-packages/mercurial/policy.py", line 69, in _importfrom
  fakelocals[modname] = mod = getattr(pkg, modname)
File "/usr/lib/python3.9/site-packages/mercurial/pycompat.py", line 307, in w
  return f(object, sysstr(name), *args)

AttributeError: module ‘mercurial.cext’ has no attribute ‘parsers’

During handling of the above exception, another exception occurred:

Traceback (most recent call last):

File "/usr/bin/hg", line 61, in <module>
  dispatch.run()
File "/usr/lib/python3.10/importlib/util.py", line 247, in __getattribute__
  self.__spec__.loader.exec_module(self)
File "<frozen importlib._bootstrap_external>", line 883, in exec_module
File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
File "/usr/lib/python3.9/site-packages/mercurial/dispatch.py", line 21, in <module>
  from .i18n import _
File "/usr/lib/python3.10/importlib/util.py", line 247, in __getattribute__
  self.__spec__.loader.exec_module(self)
File "/usr/lib/python3.9/site-packages/mercurial/i18n.py", line 123, in <module>
  if _plain():
File "/usr/lib/python3.9/site-packages/mercurial/i18n.py", line 115, in _plain
  b'HGPLAIN' not in encoding.environ
File "/usr/lib/python3.10/importlib/util.py", line 247, in __getattribute__
  self.__spec__.loader.exec_module(self)
File "/usr/lib/python3.9/site-packages/mercurial/encoding.py", line 41, in <module>
  charencode = policy.importmod('charencode')
File "/usr/lib/python3.9/site-packages/mercurial/policy.py", line 116, in importmod
  mod = _importfrom(pn, mn)
File "/usr/lib/python3.9/site-packages/mercurial/policy.py", line 71, in _importfrom
  raise ImportError('cannot import name %s' % modname)

ImportError: cannot import name parsers

for instance when building nss.

 225 PackagesBug ReportHighCritical [zstd] 1.5.1, zstd compressed ramdisk fails to load pro ...Closed
100%
Task Description

kernel issue with some network card and/or
systemd subservice not working add all

I cannot login remotely or locally.

System drops to maintainance shell..

Not a single systemd subdaemon is working..

This also effectively kills all i486 build machines..

 2 Packages: StableBug ReportMediumLow this is a test-issue for [lapack] (not a real bug) - Ar ...Closed
100%
Task Description

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

 3 Packages: StableBug ReportMediumLow [ffmpeg] missing FLAC codec Closed
100%
Task Description

Opened by Andreas Baumann - 07.11.2017
Last edited by Erich Eckner - 07.11.2017
 FS#3  - [ffmpeg] missing FLAC codec

Playing 10.Motion_Picture_Soundtrack.flac.
Audio only file format detected.
Load subtitles in ./

Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
[flac @ 0xb68902c0]Got unexpected packet size after a partial decode
[flac @ 0xb68902c0]Got unexpected packet size after a partial decode
[flac @ 0xb68902c0]Got unexpected packet size after a partial decode
[flac @ 0xb68902c0]Got unexpected packet size after a partial decode
[flac @ 0xb68902c0]Got unexpected packet size after a partial decode
[flac @ 0xb68902c0]Got unexpected packet size after a partial decode
ADecoder init failed sad
ADecoder init failed sad
Cannot find codec for audio format 0x43614C66.
Audio: no sound
Video: no video

Levi commented on 16.05.2019 20:08

How do I check this? I tested inputting a file to ffmpeg using the -i option and it acted like the output of ffprobe reporting things like the duration correctly before barfing that I hadn’t supplied it with any outputs. Is this fixed therefore?
Admin
Andreas Baumann commented on 17.08.2019 12:23

Output #0, flac, to ‘Kid A (2000)/10.Motion_Picture_Soundtrack.flac’:
Output file #0 does not contain any stream

and this on 64-bit.

I don’t think, flac support is there in ffmpeg

Google Cache

Bing Cache

 4 Packages: StableBug ReportMediumLow [virtualbox-guest-utils] 5.2.0 version broken  Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 07.11.2017
Last edited by Andreas Baumann - 17.12.2017
 FS#4  - [virtualbox-guest-utils] 5.2.0 version broken

When starting a virtual machine you get:

VBoxClient: VBoxClient (seamless): failed to start. Stage: Setting guest IRQ filter mask Error: VERR_INTERNAL_ERROR

The solution is to use the guest ISO 5.2.1 for now till the package is upgraded.
Closed by Andreas Baumann
17.12.2017 20:22
Reason for closing: Fixed
Additional comments about closing:

Seems to work now. the modules load, the desktop adapts nicely. mouse works. closing this one.

Comments

Admin
Erich Eckner commented on 17.12.2017 18:46

is this still the case with 5.2.2?
Admin
Andreas Baumann commented on 17.12.2017 18:52

I’ll have to test on a virtualbox vm..

Google Cache

Bing Cache

 5 PackagesBug ReportMediumLow [sbcl] fails to compile - Arch Linux Closed
100%
Task Description

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

 6 PackagesBug ReportMediumLow [libreoffice-still] 5.3.7-4 crashes when opening a ... Closed
100%
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 …

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

no task description

 8 Packages: Build-listBug ReportMediumLow [skia-sharp] [skia-sharp58] build fails Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Erich Eckner - 11.11.2017
Last edited by Andreas Baumann - 12.11.2017
 FS#8  - [skia-sharp] [skia-sharp58] build fails

/startdir/PKGBUILD: line 63: bin/gn: No such file or directory

strange about this:
- works on x86_64
- bin/gn is there and executable
Closed by Andreas Baumann
12.11.2017 14:19
Reason for closing: Won’t implement
Additional comments about closing:

blacklist, no visible 32-bit support.

Comments (7)

Admin
Andreas Baumann commented on 12.11.2017 12:29

When compiling on 64-bit I get several binaries:

src/depot_tools/gn
src/skia/gn
src/skia/buildtools/linux64/gn
src/skia/bin/gn

maybe one with linux32 is missing?
Admin
Andreas Baumann commented on 12.11.2017 12:30

Other things in PKGBUILD:

export PYTHON=’/usr/bin/pyton2’

This hardly works. :-) Admin
Andreas Baumann commented on 12.11.2017 12:31

The line with bin/gn is a little bit tricky. I’ll try to put an absolute path there..
Admin
Andreas Baumann commented on 12.11.2017 12:32

I also don’t like the ideas of pushd and popd everywhere..
Admin
Andreas Baumann commented on 12.11.2017 12:33

file bin/gn
bin/gn: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.26, BuildID[sha1]=6d551c57efec95b400b9890f89a18e407396c917, stripped

So the file not found means: it exists, but has not been compiled for the correct architecture.
Admin
Andreas Baumann commented on 12.11.2017 13:57

So, removing bin/gn and calling python2 tools/git-sync-deps fetches me a new copy.
Admin
Andreas Baumann commented on 12.11.2017 14:14

So tools/git-sync-deps does:

   subprocess.check_call(
  [sys.executable,
   os.path.join(os.path.dirname(deps_file_path), 'bin', 'fetch-gn')])

which has:

gn_path = ‘buildtools/linux64/gn’ if ‘linux’ in sys.platform else \

      'buildtools/mac/gn'     if 'darwin' in sys.platform else \
      'buildtools/win/gn.exe'

fetching things from Chromium:

f.write(urllib2.urlopen('https://chromium-gn.storage-download.googleapis.com/' + sha1).read())

Changing linux64 to linux32 in a naive approach didn’t fetch a bin/gn.

So I would actually blacklist both packages.

Google Cache

 9 Packages: Build-listBug ReportMediumLow [ffmpeg] [ffmpeg2.8] libtheora not found Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Erich Eckner - 11.11.2017
Last edited by Andreas Baumann - 12.11.2017
 FS#9  - [ffmpeg] [ffmpeg2.8] libtheora not found

==&gt; Starting build()… ERROR: libtheora not found

… but it’s there:
/var/lib/archbuild/staging-i686/erich/usr/lib/libtheora.so.0.3.10
/var/lib/archbuild/staging-i686/erich/usr/lib/libtheora.so.0
/var/lib/archbuild/staging-i686/erich/usr/lib/libtheora.so

strange … Closed by Andreas Baumann
12.11.2017 15:40
Reason for closing: Fixed
Additional comments about closing:

fixed in libogg.

  Comments (5)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 12.11.2017 14:29

more ffbuild/config.log

BEGIN /tmp/ffconf.6IlfdMzU/test.c

  1   #include 
  2   #include 
  3   long check_th_info_init(void) { return (long) th_info_init; }
  4   int main(void) { int ret = 0;
  5    ret |= ((intptr_t)check_th_info_init) &amp; 0xFFFF;
  6   return ret; }

END /tmp/ffconf.6IlfdMzU/test.c
gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=
600 -DPIC -std=c11 -fomit-frame-pointer -fPIC -pthread -I/usr/include/p11-kit-1 -I/usr/include/freetype2
-I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/us
r/include/fribidi -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include
/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/har
/
…skipping
In file included from /usr/include/ogg/os_types.h:144:0,

               from /usr/include/ogg/ogg.h:25,
               from /usr/include/theora/theoraenc.h:24,
               from /tmp/ffconf.6IlfdMzU/test.c:1:

/usr/include/ogg/config_types.h:4:10: fatal error: config_types-32.h: No such file or directory
#include “config_types-32.h”

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

compilation terminated.
ERROR: libtheora not found

Admin
Andreas Baumann commented on 12.11.2017 14:31

/usr/include/ogg/config_types.h

#if WORDSIZE == 32
#include “config_types-32.h” #elif
WORDSIZE == 64
#include “config_types-64.h” #else
#error “Unknown word size” #endif

ls /usr/include/ogg/
config_types-64.h config_types.h ogg.h os_types.h

So ogg misses the 32-bit types header file.. I’ll check there..
Admin
Andreas Baumann commented on 12.11.2017 14:54

Trying a patch in libogg:

sed

  s|mv "${pkgdir}"/usr/include/ogg/config_types{,-64}.h|mv "${pkgdir}"/usr/include/ogg/config_types{,-32}.h|

Admin
Andreas Baumann commented on 12.11.2017 14:57

acutally: better remove the whole multilib stuff on 32-bit..
Admin
Andreas Baumann commented on 12.11.2017 15:39

eval “$(

declare -f package | \
  sed '
    /^.*Resolve multilib conflict/,/^}$/{//p;d;}
  '

)”

Back to first version, I’m not a sed-king (rather the very opposite).

Google Cache

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

no task description

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

no task description

 12 Packages: Build-listBug ReportMediumLow [python-setuptools] check() fails (due to some mpmath i ...Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Erich Eckner - 15.11.2017
Last edited by Andreas Baumann - 02.10.2019
 FS#12  - [python-setuptools] check() fails (due to some mpmath issue?)

during check():
_ sympy/polys/tests/test_rootoftools.py:test_CRootOf_evalf _

File “/build/python-sympy/src/sympy-sympy-1.1.1-py2/sympy/polys/tests/test_rootoftools.py”, line 225, in test_CRootOf_evalf

a, b = rootof(eq, 1).n(2).as_real_imag()

File “sympy/core/evalf.py”, line 1394, in evalf

result = evalf(self, prec + 4, options)

File “sympy/core/evalf.py”, line 1292, in evalf

xe = x._eval_evalf(prec)

File “sympy/polys/rootoftools.py”, line 644, in _eval_evalf

x0 = mpc(*map(str, interval.center))

File “/usr/lib/python2.7/site-packages/mpmath/ctx_mp_python.py”, line 374, in new

imag = cls.context.mpf(imag)

File “/usr/lib/python2.7/site-packages/mpmath/ctx_mp_python.py”, line 77, in new

v._mpf_ = mpf_pos(cls.mpf_convert_arg(val, prec, rounding), prec, rounding)

File “/usr/lib/python2.7/site-packages/mpmath/ctx_mp_python.py”, line 84, in mpf_convert_arg

if isinstance(x, basestring): return from_str(x, prec, rounding)

File “/usr/lib/python2.7/site-packages/mpmath/libmp/libmpf.py”, line 1300, in from_str

return from_rational(int(p), int(q), prec, rnd)

ValueError: invalid literal for int() with base 10: ‘-2163048125L’
tests finished: 6841 passed, 185 skipped, 1 exceptions, in 4352.49 seconds

DO *NOT* COMMIT!
test process starts

executable: /usr/bin/python2 (2.7.14-final-0) [CPython]
architecture: 32-bit
cache: yes
ground types: gmpy 2.0.8
hash randomization: on (PYTHONHASHSEED=3003103148)
Closed by Andreas Baumann
02.10.2019 19:15
Reason for closing: Fixed
Additional comments about closing:

Seems to run the tests just fine on i686 and pentium4.

Google Cache

Bing Cache

 13 PackagesBug ReportMediumLow [fox-devel] fails on 32-bit Intel - Arch Linux Closed
100%
Task Description

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 …

 14 PackagesBug ReportMediumLow [ghc-mod] Needs rebuilt Closed
100%
Task Description

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

 15 Packages: StableBug ReportMediumLow [extra/m17n-lib] needs rebuilt for icu 60 Closed
100%
Task Description

Attached to Project: Archlinux32
Opened by Luke Shumaker - 22.11.2017
Last edited by Erich Eckner - 28.11.2017
 FS#15  - [extra/m17n-lib] needs rebuilt for icu 60

extra/m17n-lib 1.7.0-1 is built against icu 59; it needs rebuilt against icu 60 (which moved from staging to stable on Monday).
Closed by Erich Eckner
28.11.2017 08:14
Reason for closing: Fixed
Additional comments about closing:

unfortunately, the fixed package has same version - so you need to force update that one.

  Comments (1)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 23.11.2017 09:55

I checked on stable, seems ok to me now:

ldd /usr/lib/libm17n.so.0.4.1

    linux-gate.so.1 (0xb7f9c000)
    libm17n-core.so.0 =&gt; /usr/lib/libm17n-core.so.0 (0xb7f12000)
    libdl.so.2 =&gt; /usr/lib/libdl.so.2 (0xb7f0d000)
    libc.so.6 =&gt; /usr/lib/libc.so.6 (0xb7d37000)
    libxml2.so.2 =&gt; /usr/lib/libxml2.so.2 (0xb7bb7000)
    libz.so.1 =&gt; /usr/lib/libz.so.1 (0xb7b9e000)
    liblzma.so.5 =&gt; /usr/lib/liblzma.so.5 (0xb7b72000)
    libicui18n.so.60 =&gt; /usr/lib/libicui18n.so.60 (0xb78bc000)
    libicuuc.so.60 =&gt; /usr/lib/libicuuc.so.60 (0xb7702000)
    libicudata.so.60 =&gt; /usr/lib/libicudata.so.60 (0xb5d6c000)
    libm.so.6 =&gt; /usr/lib/libm.so.6 (0xb5c70000)
    /usr/lib/ld-linux.so.2 (0xb7f9e000)
    libpthread.so.0 =&gt; /usr/lib/libpthread.so.0 (0xb5c4f000)
    libstdc++.so.6 =&gt; /usr/lib/libstdc++.so.6 (0xb5ad5000)
    libgcc_s.so.1 =&gt; /usr/lib/libgcc_s.so.1 (0xb5ab8000)

Google Cache

 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

20Packages: Build-listBug ReportMediumLow[sagemath-doc] building documentation using Sphinx segf...New
0%
Task Description

[tutorial ] Saved pickle file: citations.pickle
[tutorial ] Exception occurred:
[tutorial ] File “/usr/lib/python2.7/site-packages/sphinx/environment/init.py”, line 152, in dump
[tutorial ] pickle.dump(env, f, pickle.HIGHEST_PROTOCOL)
[tutorial ] MemoryError
[tutorial ] The full traceback has been saved in /tmp/sphinx-err-kSNZ9A.log, if you want to report the issue to the developers.
[tutorial ] Please also report this if it was a user error, so that a better error message can be provided next time.
[tutorial ] A bug report can be filed in the tracker at . Thanks!
Build finished. The built documents can be found in /build/sagemath-doc/src/sage-8.1/src/doc/html/ja/tutorial
/startdir/PKGBUILD: line 79: 2540 Segmentation fault (core dumped) python2 sage_setup/docbuild –no-pdf-links -k all html
==&gt; ERROR: A failure occurred in build().

  Aborting...

==&gt; ERROR: Build failed, check /data/archbuild/staging-i686/copy/build

Bing Cache

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

 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.
==&gt; ERROR: A failure occurred in build().

  Aborting...

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

28Packages: Build-listBug ReportMediumLowpostgrest: checks start a Postgresql server and then te...New
0%
Task Description

Starting check()… WARNING [pifpaf.drivers] `psutil.Popen(pid=2683, status=’terminated’)` is already gone, sending SIGKILL to its process group
WARNING [pifpaf.drivers] `psutil.Popen(pid=2671, status=’terminated’)` is already gone, sending SIGKILL to its process group
WARNING [pifpaf.drivers] `psutil.Popen(pid=2669, status=’terminated’)` is already gone, sending SIGKILL to its process group
ERROR [pifpaf] Error while running command: [b’/usr/bin/pg_ctl’, ‘-w’, ‘-o’, ‘-k /tmp/tmp5_5e9_hy -p 5432 -h “127.0.0.1”‘, ‘start’]
createdb: could not connect to database template1: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket “/run/postgresql/.s.PGSQL.5432”? ERROR: A failure occurred in check().
Aborting…
ERROR: Build failed, check /data/archbuild/staging-i686/arch32/build

Disabling tests for now.

  Comments (1)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 15.02.2018 16:56

Didn’t pifpaf itself had problems building? Maybe it’s a pifpaf issue..

Bing 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

==&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.
==&gt; 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&gt; kwin_x11
kwin_x11: error while loading shared libraries: libicui18n.so.60: cannot open shared object file: No such file or directory
[/quote]

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

Actually, also gdal is fine on staging.

  Comments (1)
  Related Tasks (0/0)

Admin
Erich Eckner commented on 11.04.2018 11:59

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

Google Cache

 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 =&gt; /usr/lib/libkpathsea.so.6 (0xb7ee9000)
      libicui18n.so.60 =&gt; not found
      libicuuc.so.60 =&gt; not found
      libc.so.6 =&gt; /usr/lib/libc.so.6 (0xb7d14000)
      /lib/ld-linux.so.2 =&gt; /usr/lib/ld-linux.so.2 (0xb7f55000)

/usr/bin/xelatex:

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

/usr/bin/xetex:

      linux-gate.so.1 (0xb7f0e000)
      libharfbuzz-icu.so.0 =&gt; /usr/lib/libharfbuzz-icu.so.0 (0xb7b1a000)
      libharfbuzz.so.0 =&gt; /usr/lib/libharfbuzz.so.0 (0xb7a5d000)
      libgraphite2.so.3 =&gt; /usr/lib/libgraphite2.so.3 (0xb7a2d000)
      libicuuc.so.60 =&gt; 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

36Packages: TestingBug ReportMediumLowtexlive-core: SSE2 requiredNew
0%
Task Description

Attached to Project: Archlinux32
Opened by Andreas Baumann - 14.04.2018
Last edited by Andreas Baumann - 16.04.2018
FS#36 - texlive-core: SSE2 required

(4/5) Updating TeXLive format files… PANIC: unprotected error in call to Lua API (CPU with SSE2 required)
fmtutil [ERROR]: running `luajittex -ini -jobname=luajittex -progname=luajittex luatex.ini /null’ return status 1
fmtutil [ERROR]: return error due to options –strict
error: command failed to execute correctly
(5/5) Updating TeXLive font maps…

So, the problem seems to be in lua itself?

Bing 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&gt;
     Message: Process 242 (Xorg) of user 0 dumped core.
              
              Stack trace of thread 242:
              #0  0x00000000b7f58d21 __kernel_vsyscall (linux-gate.so.1)
              #1  0x00000000b7d749c2 raise (libc.so.6)
              #2  0x00000000b7d5e71e abort (libc.so.6)
              #3  0x000000000056b555 OsAbort (Xorg)
              #4  0x000000000056b5d2 FatalError (Xorg)
              #5  0x000000000060a93a n/a (Xorg)
              #6  0x00000000b7f58d38 __kernel_rt_sigreturn (linux-gate.so.1)
              #7  0x00000000b632cd37 n/a (kms_swrast_dri.so)
              #8  0x00000000b5f0181f n/a (kms_swrast_dri.so)
              #9  0x00000000b7f698b3 call_init.part.0 (ld-linux.so.2)
              #10 0x00000000b7f699b2 _dl_init (ld-linux.so.2)
              #11 0x00000000b7f6d7e0 dl_open_worker (ld-linux.so.2)
              #12 0x00000000b7e7bc91 _dl_catch_exception (libc.so.6)
              #13 0x00000000b7f6d077 _dl_open (ld-linux.so.2)
              #14 0x00000000b7b8cb73 n/a (libdl.so.2)
              #15 0x00000000b7e7bc91 _dl_catch_exception (libc.so.6)
              #16 0x00000000b7e7bd40 _dl_catch_error (libc.so.6)
              #17 0x00000000b7b8d333 n/a (libdl.so.2)
              #18 0x00000000b7b8cc16 dlopen (libdl.so.2)
              #19 0x00000000b7f2eb6e n/a (libgbm.so.1)
              #20 0x00000000b7f2ecb3 n/a (libgbm.so.1)
              #21 0x00000000b7f2ee24 n/a (libgbm.so.1)
              #22 0x00000000b7f2f0d7 n/a (libgbm.so.1)
              #23 0x00000000b7f2c9ba gbm_create_device (libgbm.so.1)
              #24 0x00000000b6ef4ee4 glamor_egl_init (libglamoregl.so)
              #25 0x00000000b7f49b4a n/a (modesetting_drv.so)
              #26 0x000000000051c169 InitOutput (Xorg)
              #27 0x000000000049d8e1 n/a (Xorg)
              #28 0x00000000b7d60041 __libc_start_main (libc.so.6)
              #29 0x000000000049e7e2 _start (Xorg)
  Comments (7)
  Related Tasks (0/0)

Admin
Andreas Baumann commented on 14.06.2018 15:53

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

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

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

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

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

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

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

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

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

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

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

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

#29 PreInit (pScrn=, flags=)

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

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

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

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

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

#32 main (argc=, argv=, envp=)

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

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

 0xb62d5d3c &lt;+76&gt;:    vmovq  %xmm0,0x18(%esi)

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

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

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

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

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

Some docu:

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

Trying the following patch at the moment:

eval “$(

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

)”

Admin
Erich Eckner commented on 14.06.2018 20:54

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

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

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

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

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

)”

Admin
Andreas Baumann commented on 13.09.2018 08:34

Fails again with (mesa 18.1.8 on testing):

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

Google Cache

Bing Cache

 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(&amp;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
&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

 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 &gt; mirrorlist.temp’
Steps to reproduce

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

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

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

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

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

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

  Comments (2)
  Related Tasks (0/0)

Admin
Erich Eckner commented on 26.07.2018 19:13

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

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

Google Cache

 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
&gt; … &gt; ModuleNotFoundError: No module named ‘six’
Steps to fix

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

I note arch64 has a newer python-six that supplies its libs to python3.7 just fine, although it also doesn’t identify its versions to my liking.
Closed by Erich Eckner
24.09.2018 08:45
Reason for closing: Fixed

  Comments (2)
  Related Tasks (0/0)

Admin
Erich Eckner commented on 20.08.2018 04:26

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

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

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

Powered by Flyspray

Google Cache

 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

Showing tasks 1 - 50 of 351 Page 1 of 81 - 2 - 3 - 4 - 5 - Last >>

Available keyboard shortcuts

Tasklist

Task Details

Task Editing