|
220 | Packages | Bug Report | Very High | Critical | [python] completly broken | Closed | |
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 | Packages | Bug Report | High | Critical | [zstd] 1.5.1, zstd compressed ramdisk fails to load pro ... | Closed | |
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..
|
|
103 | Packages: Stable | Bug Report | Medium | Low | yarn segfaults | New | |
Task Description
experienced when building buildbot-www
/bin/sh: line 1: 4744 Segmentation fault (core dumped) yarn install –pure-lockfile
|
|
165 | Packages | Bug Report | Medium | Low | xorgproto check() fails | Closed | |
Task Description
———————————– output ———————————– stderr: Traceback (most recent call last):
File "/build/xorgproto/src/xorgproto-2021.3/scripts/keysym-generator.py", line 18, in <module>
import libevdev
ModuleNotFoundError: No module named ‘libevdev’
root cause is python-libevdev not building:
Theme error: sphinx_rtd_theme is no longer a hard dependency since version 1.4.0. Please install it manually.(pip install sphinx_rtd_theme)
another victim of documentation generation..
|
|
39 | Packages: Stable | Bug Report | Medium | Low | xorg modesetting module fails with illegal instruction | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Andreas Baumann - 13.06.2018 Last edited by Andreas Baumann - 13.09.2018
FS#39 - xorg modesetting module fails with illegal instruction
[ 22.717] (EE) Illegal instruction at address 0xb632cd37 [ 22.718] (EE) Fatal server error: [ 22.718] (EE) Caught signal 4 (Illegal instruction). Server aborting [ 22.719] (EE)
PID: 242 (Xorg)
UID: 0 (root)
GID: 0 (root)
Signal: 6 (ABRT)
Timestamp: Wed 2018-06-13 20:53:43 CEST (41s ago)
Command Line: /usr/lib/Xorg :0
Executable: /usr/lib/Xorg
Control Group: /user.slice/user-0.slice/session-c1.scope
Unit: session-c1.scope
Slice: user-0.slice
Session: c1
Owner UID: 0 (root)
Boot ID: ea12301d13874fac8112dad7bf566bdb
Machine ID: 2f98089cbe8d40cb8776a580d6803b58
Hostname: arch32-staging
Storage: /var/lib/systemd/coredump/core.Xorg.0.ea12301d13874fac8112dad7bf566bdb.242.1528916023000>
Message: Process 242 (Xorg) of user 0 dumped core.
Stack trace of thread 242:
#0 0x00000000b7f58d21 __kernel_vsyscall (linux-gate.so.1)
#1 0x00000000b7d749c2 raise (libc.so.6)
#2 0x00000000b7d5e71e abort (libc.so.6)
#3 0x000000000056b555 OsAbort (Xorg)
#4 0x000000000056b5d2 FatalError (Xorg)
#5 0x000000000060a93a n/a (Xorg)
#6 0x00000000b7f58d38 __kernel_rt_sigreturn (linux-gate.so.1)
#7 0x00000000b632cd37 n/a (kms_swrast_dri.so)
#8 0x00000000b5f0181f n/a (kms_swrast_dri.so)
#9 0x00000000b7f698b3 call_init.part.0 (ld-linux.so.2)
#10 0x00000000b7f699b2 _dl_init (ld-linux.so.2)
#11 0x00000000b7f6d7e0 dl_open_worker (ld-linux.so.2)
#12 0x00000000b7e7bc91 _dl_catch_exception (libc.so.6)
#13 0x00000000b7f6d077 _dl_open (ld-linux.so.2)
#14 0x00000000b7b8cb73 n/a (libdl.so.2)
#15 0x00000000b7e7bc91 _dl_catch_exception (libc.so.6)
#16 0x00000000b7e7bd40 _dl_catch_error (libc.so.6)
#17 0x00000000b7b8d333 n/a (libdl.so.2)
#18 0x00000000b7b8cc16 dlopen (libdl.so.2)
#19 0x00000000b7f2eb6e n/a (libgbm.so.1)
#20 0x00000000b7f2ecb3 n/a (libgbm.so.1)
#21 0x00000000b7f2ee24 n/a (libgbm.so.1)
#22 0x00000000b7f2f0d7 n/a (libgbm.so.1)
#23 0x00000000b7f2c9ba gbm_create_device (libgbm.so.1)
#24 0x00000000b6ef4ee4 glamor_egl_init (libglamoregl.so)
#25 0x00000000b7f49b4a n/a (modesetting_drv.so)
#26 0x000000000051c169 InitOutput (Xorg)
#27 0x000000000049d8e1 n/a (Xorg)
#28 0x00000000b7d60041 __libc_start_main (libc.so.6)
#29 0x000000000049e7e2 _start (Xorg)
Comments (7)
Related Tasks (0/0)
Admin Andreas Baumann commented on 14.06.2018 15:53
#0 0xb7f3ad21 in kernel_vsyscall () [- #1 0xb7d579c2 in raise () from /usr/lib/libc.so.6 #2 0xb7d4171e in abort () from /usr/lib/libc.so.6 #3 0x005855f5 in OsAbort () at ../xorg-server-1.20.0/os/utils.c:1350 #4 0×00585672 in AbortServer () at ../xorg-server-1.20.0/os/log.c:877 #4 0×00585672 in AbortServer () at ../xorg-server-1.20.0/os/log.c:877 #5 FatalError (f=0x65e1bc “Caught signal %d (%s). Server aborting\n”) at ../xorg-server-1.20.0/os/log.c:1015 #6 0x00624b5a in OsSigHandler (signo=, sip=, unused=, signo=, sip=, unused
at ../xorg-server-1.20.0/os/osinit.c:156 #7 #8 0xb62d5d37 in SwrJit::X86Intrinsic::X86Intrinsic (this=0xbf955e24) at ../mesa-18.1.1/src/gallium/drivers/swr/rasterizer/jitter/functionpasses/lower_x86.cpp:66 #9 std::pair, std::allocator > const, SwrJit::X86Intrinsic>::pair (this=0xbf955e0c, x=…, y=…) at /usr/include/c++/8.1.1/bits/stl_pair.h:301 #10 0xb5eaa81f in static_initialization_and_destruction_0(int, int) [clone .constprop.236] ()
at /usr/include/c++/8.1.1/new:169
#11 0xb7f4b8b3 in call_init.part () from /lib/ld-linux.so.2 #12 0xb7f4b9b2 in _dl_init () from /lib/ld-linux.so.2 #13 0xb7f4f7e0 in dl_open_worker () from /lib/ld-linux.so.2 #14 0xb7e5ec91 in _dl_catch_exception () from /usr/lib/libc.so.6 #15 0xb7f4f077 in _dl_open () from /lib/ld-linux.so.2 #16 0xb7b6fb73 in ?? () from /usr/lib/libdl.so.2 #17 0xb7e5ec91 in _dl_catch_exception () from /usr/lib/libc.so.6 #18 0xb7e5ed40 in _dl_catch_error () from /usr/lib/libc.so.6 —Type to continue, or q to quit— #19 0xb7b70333 in ?? () from /usr/lib/libdl.so.2 #20 0xb7b6fc16 in dlopen () from /usr/lib/libdl.so.2 #21 0xb7f10b6e in dri_open_driver (dri=, dri
at ../mesa-18.1.1/src/gbm/backends/dri/gbm_dri.c:354
#22 0xb7f10cb3 in dri_load_driver (dri=0x17e9660) at ../mesa-18.1.1/src/gbm/backends/dri/gbm_dri.c:439 #23 dri_screen_create_dri2 (dri=dri@entry=0x17e9660, driver_name
at ../mesa-18.1.1/src/gbm/backends/dri/gbm_dri.c:439
#24 0xb7f10e24 in dri_screen_create_sw (dri=0x17e9660)
at ../mesa-18.1.1/src/gbm/backends/dri/gbm_dri.c:539
#25 0xb7f110d7 in dri_device_create (fd=13) at ../mesa-18.1.1/src/gbm/backends/dri/gbm_dri.c:1429 #26 0xb7f0e9ba in gbm_create_device (fd=13) at ../mesa-18.1.1/src/gbm/main/gbm.c:137 #27 0xb6ebaee4 in glamor_egl_init (scrn=0x17e83a0, fd=13)
at ../xorg-server-1.20.0/glamor/glamor_egl.c:894
#28 0xb7f2bb4a in try_enable_glamor (pScrn=0x17e83a0)
at ../xorg-server-1.20.0/hw/xfree86/drivers/modesetting/driver.c:753
#29 PreInit (pScrn=, flags
at ../xorg-server-1.20.0/hw/xfree86/drivers/modesetting/driver.c:972
#30 0×00536209 in InitOutput (pScreenInfo=0x6fd520 , argc=6, argv=0xbf957944)
at ../xorg-server-1.20.0/hw/xfree86/common/xf86Init.c:536
#31 0x004b7991 in dix_main (envp=, argv=, argc
at ../xorg-server-1.20.0/dix/main.c:193
#32 main (argc=, argv=, envp
at ../xorg-server-1.20.0/dix/stubmain.c:34
=> 0xb62d5d37 <+71>: vmovq -0×20(%ebp),%xmm0
0xb62d5d3c <+76>: vmovq %xmm0,0x18(%esi)
Looks like AVX optimized code in libswr though I’m deleting -D swr-arches=avx,avx2 in the diff-PKGBUILD (maybe wrongly)? Admin Andreas Baumann commented on 14.06.2018 17:55
So, I read OpenSWR requires at least AVX, so we can safely drop the library for 32-bit machines, right?
So removing swr from the gallium-drivers, then I get croaks about gallium-nine requiring a pipe.
I’ll continue to drop options in arch-meson in PKGBUILD till I get a working build..
Any help welcome. Admin Andreas Baumann commented on 14.06.2018 18:13
Some docu:
http://openswr.org/build-linux.html
https://www.mesa3d.org/envvars.html
https://www.felixcloutier.com/x86/MOVQ.html
Trying the following patch at the moment:
eval “$(
declare -f build | \
sed '
/-D gallium-drivers=/s/,swr//g
s/-D swr-arches=avx,avx2//g
/gallium-drivers/s/,swr//g
s/-D gallium-nine=true/-D gallium-nine=false/g
s/-D osmesa=gallium/-D osmesa=classic/g
s/dri-drivers=/dri-drivers=swrast,/g
'
)”
Admin Erich Eckner commented on 14.06.2018 20:54
only glitch I see with your fix is, that the options are in one line in `declare -f build`, so the line-matching makes no sense Admin Andreas Baumann commented on 15.06.2018 06:07
one line? It should actually be one line each and it worked for me? *puzzle* Admin Andreas Baumann commented on 15.06.2018 08:55
This seems to work. But I’m disabling and changing an awful lot of stuff:
# disable AVX/AVX2 in openswf, makes no sense with old CPUs eval “$(
declare -f build | \
sed '
/-D gallium-drivers=/s/,swr//g
s/-D swr-arches=avx,avx2//g
/gallium-drivers/s/,swr//g
s/-D gallium-nine=true/-D gallium-nine=false/g
s/-D osmesa=gallium/-D osmesa=classic/g
s/dri-drivers=/dri-drivers=swrast,/g
'
declare -f package_mesa | \
sed '
s@_install fakeinstall/usr/lib/d3d@#\0@g
s@_install fakeinstall/usr/lib/libswrAVX.*@#\0@g
'
)”
Admin Andreas Baumann commented on 13.09.2018 08:34
Fails again with (mesa 18.1.8 on testing):
Program received signal SIGILL, Illegal instruction. 0xb627e167 in ?? () from /usr/lib/dri/kms_swrast_dri.so => 0xb627e167: c5 fa 7e 45 e0 vmovq -0×20(%ebp),%xmm0
Google Cache
Bing Cache
|
|
148 | Packages | Bug Report | Medium | Low | xfce4-power-man crashes | Closed | |
Task Description
Feb 12 12:00:29 arch32-testing-pentium4 kernel: audit: type=1130 audit(1613127629.283:106): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@0-9938-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 12 12:00:31 arch32-testing-pentium4 systemd-coredump[9939]: [🡕] Process 9886 (xfce4-power-man) of user 1000 dumped core.
Stack trace of thread 9886:
#0 0x00000000b6fb37b4 g_log_structured_array (libglib-2.0.so.0 + 0x557b4)
#1 0x00000000b6fb3cdc g_log_default_handler (libglib-2.0.so.0 + 0x55cdc)
#2 0x00000000b6fb5224 g_logv (libglib-2.0.so.0 + 0x57224)
#3 0x00000000b6fb5485 g_log (libglib-2.0.so.0 + 0x57485)
#4 0x000000000041a4cf n/a (xfce4-power-manager + 0x64cf)
#5 0x00000000b6b5498d __libc_start_main (libc.so.6 + 0x1e98d)
#6 0x000000000041aa75 n/a (xfce4-power-manager + 0x6a75)
Stack trace of thread 9901:
#0 0x00000000b7f12549 __kernel_vsyscall (linux-gate.so.1 + 0x549)
#1 0x00000000b6c22117 __poll (libc.so.6 + 0xec117)
#2 0x00000000b7000125 n/a (libglib-2.0.so.0 + 0xa2125)
#3 0x00000000b6faba46 g_main_context_iteration (libglib-2.0.so.0 + 0x4da46)
#4 0x00000000b6fabaa1 n/a (libglib-2.0.so.0 + 0x4daa1)
#5 0x00000000b6fda93e n/a (libglib-2.0.so.0 + 0x7c93e)
#6 0x00000000b6cfe39f start_thread (libpthread.so.0 + 0x839f)
#7 0x00000000b6c2db6a __clone (libc.so.6 + 0xf7b6a)
Feb 12 12:00:31 arch32-testing-pentium4 kernel: audit: type=1131 audit(1613127631.393:107): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@0-9938-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
|
|
149 | Packages | Bug Report | Medium | Low | xfce desktop doesn't start | Closed | |
Task Description
no task description |
|
94 | Packages: Testing | Bug Report | Medium | Low | Weechat needs a rebuild | Closed | |
Task Description
Since the uprgade to python from testing, weechat has broken it’s python support, which at least knocks out the plugin I use to keep in touch with my old workmates over slack.
# weechat
| ___ __ ______________ _____
| __ | / /___________ ____/__ /_______ __ /_
| __ | /| / /_ _ \ _ \ / __ __ \ __ `/ __/
| __ |/ |/ / / __/ __/ /___ _ / / / /_/ // /_
| ____/|__/ \___/\___/\____/ /_/ /_/\__,_/ \__/
| WeeChat 2.6 [compiled on Nov 12 2019 13:06:27]
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| Error: unable to load plugin "/usr/lib/weechat/plugins/python.so": libpython3.7m.so.1.0: cannot open shared object file:
| No such file or directory
Inside /usr/lib/weechat/plugins there is a file named python.so, but its not any kind of link. I expect it to be fixed up if it were to be rebuilt.
|
|
74 | Packages: Stable | Bug Report | Medium | Low | webkit2gtk requires SSE2 | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Andreas Baumann - 16.05.2019
FS#74 - webkit2gtk requires SSE2
– Performing Test HAVE_SSE2_EXTENSIONS – Performing Test HAVE_SSE2_EXTENSIONS - Failed CMake Error at CMakeLists.txt:115 (message):
SSE2 support is required to compile WebKit
not quite clear yet, what happens, if it gets disabled forcefully..
Comments (5)
Related Tasks (0/0)
Admin Andreas Baumann commented on 16.05.2019 18:43
Let’s see, what happens if we just comment out the SSE2 test in CMakeLists.txt.. Admin Andreas Baumann commented on 17.05.2019 11:54
Rebuilding runs in issues like:
make[2]: *** No rule to make target ‘JavaScriptCore-4.0.gir’, needed by ‘WebKit2-4.0.gir’. Stop.
Using in ‘build’ make JavaScriptCore-4-gir VERBOSE=1 reveils the true nature of the bug:
/usr/lib/gcc/i686-pc-linux-gnu/8.3.0/include/stddef.h:435: syntax error, unexpected identifier in ' float128 max_align_f128 attribute1)));’ at ‘__float128’
So again, the 128-bit alignment hack in glibc spreading everywhere. Admin Andreas Baumann commented on 17.05.2019 11:56
Also the make error sounds suspicious, like cmake/make generated files are not really tested. Admin Andreas Baumann commented on 17.05.2019 11:59
The 128-alignment issue is hopefully just a warning.. Admin Andreas Baumann commented on 17.05.2019 12:55
patched build in the queue..
Google Cache
|
|
139 | Packages | Bug Report | Medium | Low | webkit2gtk doesn't build | Closed | |
Task Description
This blocks tons of packages..
|
|
38 | Packages: Testing | Bug Report | Medium | Low | Using SDDM, X and LXDE segfaults and logs automatically ... | Closed | |
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
|
|
130 | Packages | Bug Report | Medium | Low | user-manager and plasma-meta are in conflict | Closed | |
Task Description
:: removing user-manager breaks dependency ‘user-manager’ required by plasma-meta
|
|
196 | Packages | Bug Report | Medium | Low | update filesystem | New | |
Task Description
b3da2fc1c25065a1bd09f9930eeed1d11dc312e4 only updated half the package - we’re missing:
- update the logo - update the url (?) - only if both are done: updating the hash on top of the PKGBUILD
|
|
90 | Packages | Bug Report | Medium | Low | Unknown Bug FS#90 | Closed | |
Task Description
no task description |
|
89 | Packages | Bug Report | Medium | Low | Unknown Bug FS#89 | Closed | |
Task Description
no task description |
|
88 | Packages | Bug Report | Medium | Low | Unknown Bug FS#88 | Closed | |
Task Description
no task description |
|
84 | Packages | Bug Report | Medium | Low | Unknown bug FS#84 | Closed | |
Task Description
no task description |
|
7 | Packages | Bug Report | Medium | Low | unknown bug FS#7 | Closed | |
Task Description
no task description |
|
55 | Packages | Bug Report | Medium | Low | Unknown bug FS#55 | Closed | |
Task Description
no task description |
|
42 | Packages | Bug Report | Medium | Low | Unknown bug FS#42 | Closed | |
Task Description
no task description |
|
34 | Packages | Bug Report | Medium | Low | unknown bug FS#34 | Closed | |
Task Description
no task description |
|
25 | Packages | Bug Report | Medium | Low | unknown bug FS#25 | Closed | |
Task Description
no task description |
|
19 | Packages | Bug Report | Medium | Low | unknown bug FS#19 | Closed | |
Task Description
no task description |
|
11 | Packages | Bug Report | Medium | Low | unknown bug FS#11 | Closed | |
Task Description
no task description |
|
10 | Packages | Bug Report | Medium | Low | unknown bug FS#10 | Closed | |
Task Description
no task description |
|
59 | Packages | Bug Report | Medium | Low | unison segfault | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Andreas Baumann - 10.01.2019 Last edited by Andreas Baumann - 10.01.2019
FS#59 - unison segfault
Calling unison, a file synchronizer written in Ocaml. Segfaults. Most likely a string optimization inside Ocaml itself or a non-matching library somewhere (recompile ocaml?)
(gdb) bt #0 0x006782df in caml_string_equal () #1 0x005ce0d8 in camlUpdatearchiveMode_802888 () #2 0x005ce6e5 in 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
|
|
51 | Packages | Bug Report | Medium | Low | ufw needs rebuild for python 3.7 | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Paul Gover - 07.09.2018 Last edited by Erich Eckner - 24.09.2018
FS#51 - ufw needs rebuild for python 3.7
Been using ufw for some time. Today, I wanted to turn logging off. Command “ufw logging off” should just work. Instead it gives:
ufw logging off Traceback (most recent call last):
File “/usr/bin/ufw”, line 26, in
import ufw.frontend
ModuleNotFoundError: No module named ‘ufw’
which I trace to the fact ufw is installed in /usr/lib/python3.6/site-packages/ufw and there’s no longer a python 3.6 executable; it’s all 3.7 now. Closed by Erich Eckner 24.09.2018 07:32 Reason for closing: Fixed
Comments (3)
Related Tasks (0/0)
Admin Erich Eckner commented on 07.09.2018 09:46
ufw-0.35-5.0 from [community-testing] should work - I’m moving it to [community] just now Paul Gover commented on 07.09.2018 09:48
Sorry to add to your workload. I assumed a UFW problem was local to me. Now I’ve read the furore about python 3.7 etc. on the forums, my apologies. I’ll try the community-testing version. Thanks for the speedy response. Paul Gover commented on 11.09.2018 15:21
To confirm, UFW is working fine for me now. Thanks.
Google Cache
|
|
79 | Packages: Stable | Bug Report | Medium | Low | trojita libstdc++ ABI mismatch | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Andreas Baumann - 06.07.2019 Last edited by Andreas Baumann - 11.08.2019
FS#79 - trojita libstdc++ ABI mismatch
trojita trojita: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.26’ not found (required by /usr/lib/libQt5WebKit.so.5) Closed by Andreas Baumann 11.08.2019 06:01 Reason for closing: Not a bug Additional comments about closing:
Temporary glitch, glibc got published, trojita didn’t get rebuild.
Comments (1)
Related Tasks (0/0)
Admin Andreas Baumann commented on 06.07.2019 09:17
This goes into the same ABI mismatches as Qt5. The problem here is: qt5-webkit refuses to build on machines without SSE2 currently, but glibc is supposed to be backwards compatible, but not libstdc++).
Google Cache
|
|
146 | Packages: Upstream | Bug Report | Medium | Low | trojita doesn't build, missing a patch, failures on qt ... | Closed | |
Task Description
=⇒ ERROR: Failure while downloading https://cgit.kde.org/trojita.git/patch/?id=cf2364b8
SHA1 in https://anongit.kde.org/trojita):
cf2364b80fa8ae844df8350cd5833d47cce235f2
Fix possible crash when downloading attachments
Yep, promising, lets download the patch and add it to the package.
Original bug: https://bugs.kde.org/show_bug.cgi?id=417697
–
/build/trojita/src/trojita-0.7/src/Gui/Window.cpp:981:26: error: aggregate ‘QPainterPath path’ has incomplete type and cannot be defined
981 | QPainterPath path;
| ^~~~
needs a #include <QPainterPath>
Reported as https://bugs.kde.org/show_bug.cgi?id=432827
|
|
349 | Packages | Bug Report | Medium | Low | top print "get_mempolicy: Function not implemented" on ... | New | |
Task Description
no task description |
|
143 | Packages | Bug Report | Medium | Low | thunderbird doesn't build and run | New | |
Task Description
still linked against icu67.
Same here, I cannot believe that somebody is actually using thunderbird on Archlinux32 anymore.
Triggered rebuild, doesn’t build currently.
|
|
2 | Packages: Stable | Bug Report | Medium | Low | this is a test-issue for [lapack] (not a real bug) - Ar ... | Closed | |
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 …
|
|
78 | Packages: Stable | Bug Report | Medium | Low | The qt5 group contains packages of different versions. | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Erling Hellenäs - 05.07.2019
FS#78 - The qt5 group contains packages of different versions.
The qt5 group contains a qt5-base which is of a later revision, 5.12.4 instead of 5.12.3. pyside2 is also of a this later revision, but I don’t use it. I guess the group should be fixed.
Workaround: I downgraded qt5-base and it is working again.
I get this error: sddm-greeter[441]: Cannot mix incompatible Qt library (version 0x50c03) with this library (version 0x50c04) Then systemd dumps core.
Excerpt from my journal: External Link
The group definition as seen when installing the group with pacman: External Link
My architecture is i686.
I consider it critical since QT is not working.
Google Cache
|
|
36 | Packages: Testing | Bug Report | Medium | Low | texlive-core: SSE2 required | New | |
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
|
|
58 | Packages: Stable | Bug Report | Medium | Low | texlive-bin doesn't build | Closed | |
Task Description
22.12.2018 - g++ -DHAVE_CONFIG_H -I. -I../../../texk/web2c -I./w2c -I/build/texlive-bin/src/texlive-source/Work/texk -I/build/texlive-bin/src/texlive-source/texk …
|
|
35 | Packages: Stable | Bug Report | Medium | Low | texlive errors while installing (missing icu 60) | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Andreas Baumann - 12.04.2018 Last edited by Andreas Baumann - 13.04.2018
FS#35 - texlive errors while installing (missing icu 60)
(16/19) Updating TeXLive format files… xetex: error while loading shared libraries: libicuuc.so.60: cannot open shared object file: No such file or directory xetex: error while loading shared libraries: libicuuc.so.60: cannot open shared object file: No such file or directory xetex: error while loading shared libraries: libicuuc.so.60: cannot open shared object file: No such file or directory xetex: error while loading shared libraries: libicuuc.so.60: cannot open shared object file: No such file or directory fmtutil [ERROR]: running `xetex -ini -jobname=xetex -progname=xetex -etex xetex.ini /null’ return status 127 fmtutil [ERROR]: return error due to options –strict fmtutil [ERROR]: running `xetex -ini -jobname=cont-en -progname=context -8bit *cont-en.mkii /null’ return status 127 fmtutil [ERROR]: return error due to options –strict fmtutil [ERROR]: running `xetex -ini -jobname=pdfcsplain -progname=pdfcsplain -etex csplain.ini /null’ return status 127 fmtutil [ERROR]: return error due to options –strict fmtutil [ERROR]: running `xetex -ini -jobname=xelatex -progname=xelatex -etex xelatex.ini /null’ return status 127 fmtutil [ERROR]: return error due to options –strict error: command failed to execute correctly (17/19) Updating TeXLive font maps… (18/19) Updating the desktop file MIME type cache… (19/19) Updating the MIME type database…
Not had the time to actually test TexLive, it may work despite the errors.
An ldd on texlive-bin shows me:
/usr/bin/upmendex:
linux-gate.so.1 (0xb7f53000)
libkpathsea.so.6 => /usr/lib/libkpathsea.so.6 (0xb7ee9000)
libicui18n.so.60 => not found
libicuuc.so.60 => not found
libc.so.6 => /usr/lib/libc.so.6 (0xb7d14000)
/lib/ld-linux.so.2 => /usr/lib/ld-linux.so.2 (0xb7f55000)
/usr/bin/xelatex:
linux-gate.so.1 (0xb7f36000)
libharfbuzz-icu.so.0 => /usr/lib/libharfbuzz-icu.so.0 (0xb7b42000)
libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0xb7a85000)
libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0xb7a55000)
libicuuc.so.60 => not found
libpthread.so.0 => /usr/lib/libpthread.so.0 (0xb7a36000)
libpoppler.so.72 => /usr/lib/libpoppler.so.72 (0xb77c0000)
/usr/bin/xetex:
linux-gate.so.1 (0xb7f0e000)
libharfbuzz-icu.so.0 => /usr/lib/libharfbuzz-icu.so.0 (0xb7b1a000)
libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0xb7a5d000)
libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0xb7a2d000)
libicuuc.so.60 => not found
So a rebuild of texlive is maybe an option? Closed by Andreas Baumann 13.04.2018 08:07 Reason for closing: Fixed Additional comments about closing:
Linked against icu.61 now. Ok.
Comments (1)
Related Tasks (0/0)
Admin Andreas Baumann commented on 13.04.2018 08:07
PANIC: unprotected error in call to Lua API (CPU with SSE2 required). Lua also seems to go the way of all interpreters with micro-optimizations everywhere.
Google Cache
|
|
48 | Packages: Testing | Bug Report | Medium | Low | Testing repo missing a new version of python-six | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Levi - 19.08.2018 Last edited by Erich Eckner - 24.09.2018
FS#48 - Testing repo missing a new version of python-six
I’ve become aware that python-six doesn’t identify that it depends specifically on python3.6 (it claims in the text that it’s for python 3 as well as python 2, which I don’t believe can be true; it only puts python files in /usr/lib/python3.6).
It has however allowed python 3.7 into the testing repo while no new version of python-six is available, and this version of python3 can no longer find a version of six when you import it.
As far as I know this is not an issue for anyone strictly on the release repos yet, and still won’t be an issue for anyone not using python-six either directly or indirectly. Steps to reproduce
(upgrade at least python from the testing repos) # python # import six > … > ModuleNotFoundError: No module named ‘six’ Steps to fix
A new version of python-six that supplies its files to python3.7/site-packages should be built and uploaded to the testing repos, and it should probably identify its dependent versions better.
I note arch64 has a newer python-six that supplies its libs to python3.7 just fine, although it also doesn’t identify its versions to my liking. Closed by Erich Eckner 24.09.2018 08:45 Reason for closing: Fixed
Comments (2)
Related Tasks (0/0)
Admin Erich Eckner commented on 20.08.2018 04:26
python-six-1.11.0-3.0 in [staging] is made for python 3.7
The issue is known, (internally) documented and won’t be fixed within the next weeks, but hopefully I have time to look into this after my holidays. Levi commented on 27.08.2018 16:39
Thanks, I see this is available in the testing repo already, and I’ve just tested it. I don’t seem to have rights to comment and close (or perhaps this bug needs to be further progressed before that become available, I dunno), but I’ve tried to reproduce this after upgrading, and it now works for me, so I can confirm that I consider this issue resolved and closed, unless you want to keep it open as a note that I don’t think this has been pushed through the the mainline repos yet, while python 3.7 is there already.
Powered by Flyspray
Google Cache
|
|
98 | Packages: Testing | Bug Report | Medium | Low | swap encryption fails | Closed | |
Task Description
I tried to get encrypted swap following the guide in the wiki.
However, ultimately,
/usr/lib/systemd/systemd-cryptsetup attach 'swap' '/dev/disk/by-uuid/13b0e159-8573-40f8-a308-b34f1bbf1a6f' '/dev/urandom' 'swap,offset=2048'
fails, which works on upstream archlinux. It gives:
Set cipher aes, mode cbc-essiv:sha256, key size 256 bits for device /dev/disk/by-uuid/13b0e159-8573-40f8-a308-b34f1bbf1a6f.
device-mapper: reload ioctl on failed: No such file or directory
Failed to activate with key file '/dev/urandom'. (Key file missing?)
Please enter passphrase for disk Ultra_Line (swap):
Loading of cryptographic parameters failed: Invalid argument
In the middle, it asks for a passphrase. On archlinux, the output is:
Set cipher aes, mode cbc-essiv:sha256, key size 256 bits for device /dev/loop0.
are we missing ciphers here somewhere (where?)?
As usual (for my boxes), everything is up-to-date on that machine: cryptsetup 2.2.2-1.0 linux 5.1.15.arch1-1.0 systemd 243.162-2.0
Cheers, Erich
|
|
163 | Packages | Bug Report | Medium | Low | sphinx_rtd_theme is used to build documentation but doe... | New | |
Task Description
build
running build_py
npm WARN npm npm does not support Node.js v15.9.0
npm WARN npm You should probably upgrade to a newer version of node as we
npm WARN npm can't make any promises that npm will work with this version.
npm WARN npm Supported releases of Node.js are the latest release of 6, 8, 9, 10, 11, 12, 13.
npm WARN npm You can find the latest version at https://nodejs.org/
> sphinx_rtd_theme@0.5.1 preinstall /build/python-sphinx_rtd_theme/src/sphinx_rtd_theme-0.5.1
> bin/preinstall.js
Traceback (most recent call last):
File "/build/python-sphinx_rtd_theme/src/sphinx_rtd_theme-0.5.1/setup.py", line 86, in <module>
setup(
File "/usr/lib/python3.9/site-packages/setuptools/__init__.py", line 153, in setup
return distutils.core.setup(**attrs)
File "/usr/lib/python3.9/distutils/core.py", line 148, in setup
dist.run_commands()
File "/usr/lib/python3.9/distutils/dist.py", line 966, in run_commands
self.run_command(cmd)
File "/usr/lib/python3.9/distutils/dist.py", line 985, in run_command
cmd_obj.run()
File "/usr/lib/python3.9/distutils/command/build.py", line 135, in run
self.run_command(cmd_name)
File "/usr/lib/python3.9/distutils/cmd.py", line 313, in run_command
self.distribution.run_command(command)
File "/usr/lib/python3.9/distutils/dist.py", line 985, in run_command
cmd_obj.run()
File "/build/python-sphinx_rtd_theme/src/sphinx_rtd_theme-0.5.1/setup.py", line 22, in run
subprocess.run(['npm', 'install'], check=True)
File "/usr/lib/python3.9/subprocess.py", line 524, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['npm', 'install']' died with <Signals.SIGSEGV: 11>.
==> ERROR: A failure occurred in build().
Aborting...
==> ERROR: Build failed, check /var/lib/archbuild/staging-pentium4/abaumann/build
|
|
52 | Packages | Bug Report | Medium | Low | Some packages are built by "Unknown Packager" | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Luke Shumaker - 21.09.2018
FS#52 - Some packages are built by “Unknown Packager”
Some packages have
packager = Unknown Packager
, which is caused by
makepkg.conf:PACKAGER
not being set.
I analyzed every .pkg.tar.xz file in the Arch 32 repos (all architectures). The earliest Unknown Packager package was built on June 9, 2017, and they’ve been intermittent since then. Here’s a listing of how many times each packager appears:
2 Dave Reisner
2 Fabio Castelli (Muflone)
2 Giancarlo Razzolini
2 Jelle van der Waa
2 Laurent Carlier
2 S?bastien Luttringer
2 schuay
3 Florian Pritz
3 Johannes L?thberg
4 Alexander R?dseth
4 Andreas Radke
4 Eli Schwartz
4 Tobias Powalowski
5 Gaetan Bisson
5 Jonathan Steel
6 Bart?omiej Piotrowski
6 Erich Eckner
7 Kyle Keen
8 Evangelos Foutras
8 Maxime Gauduin
9 Jaroslav Lichtblau
9 Lukas Fleischer
18 BlackEagle
21 Sergej Pupykin
22 Guillaume ALAUX
29 Sven-Hendrik Haase
32 Levente Polyak
35 Jan Alexander Steffens (heftig)
39 Felix Yan
43 Jan de Groot
44 Andreas Baumann
75 Ball? Gy?rgy
81 Antonio Rojas
6592 Unknown Packager
20577 Erich Eckner
------------------------------------------------------------------
27707 total
This causes a problem for us in Parabola, because we just started applying the usual upload checks from
db-update
to packages that we import.
Comments (3)
Related Tasks (0/0)
bill auger commented on 24.09.2018 05:20
i was trying to make sense of this today and my results were pretty strange
i wrote a script to extract ‘Unknown Packager’ from the db caches in /var/lib/pacman/sync/ and i got very different counts then what luke reported - i ran the same script on both parabola i686 and again on arch32 - it did show that all of the packages by ‘Unknown Packager’ are in [extra], [community], and [core]
<pre> $ wc -l ./unknown-packagers-parabola 1800 ./unknown-packagers-parabola
$ wc -l ./unknown-packagers-arch32 2250 ./unknown-packagers-arch32 </pre>
one thing i noted was that one of the packages (4ti2) that arch32 has by ‘Unknown Packager’ for v1.6.7 shows as v1.6.9 packaged by ‘Erich Eckner’ on parabola and the parabola package has a higher version number and later build date - maybe my mirrorlist is wonky on arch32 but it is the default one that was installed
<pre> arch32: package: 4ti2-1.6.7-1 build date: 1497644502 packager: Unknown Packager
parabola: package: 4ti2-1.6.9-1.0 build date: 1536224793 packager: Erich Eckner </pre>
the script i used is attached to the corresponding parabola bug report https://labs.parabola.nu/issues/1652 https://labs.parabola.nu/attachments/444/find-unknown-packagers Admin Erich Eckner commented on 24.09.2018 08:47
The buildmaster now rejects package built by “Unknown Packager” - what remains is to rebuild all packages, that are already committed. Admin Erich Eckner commented on 24.09.2018 08:54
btw: operating on the package database is much faster than extracting every single package:
find . -name ‘*.db.tar.gz’ | \
while read -r repo; do
tar -Oxzf "${repo}" --wildcards '*/desc' | \
sed -n '/^%FILENAME%$\|^%PACKAGER%$/{N;s/\n/ /;p;d;}'
done | \
sed '/^%FILENAME% /{N;/\n%PACKAGER% Unknown Packager$/!d;s/\n.*//;s/^%FILENAME% //;}'
Google Cache
|
|
260 | Packages | Bug Report | Medium | Low | segfaults in pacstrap on 2022.05.02 ISO | Closed | |
Task Description
ISO segfaults when pacstrapping.
Several (if not all) build slaves show key verification errors.
I don’t think, it’s the keys, but gnupg slowly failing us on 32-bit.
Workaround as always: SigLevel=Never
Trick question (and possibly bonus points): what to do, if gnupg cannot be fixed..
|
|
125 | Packages | Bug Report | Medium | Low | seamonkey broken on i686 | Closed | |
Task Description
breaks in more SIMD optimizations.
|
|
62 | Packages: Testing | Bug Report | Medium | Low | sddm-greeter aborts | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Andreas Baumann - 01.02.2019 Last edited by Andreas Baumann - 12.05.2019
FS#62 - sddm-greeter aborts
(gdb) bt #0 0xb7fbea41 in kernel_vsyscall () #1 0xb6418746 in raise () from /usr/lib/libc.so.6 #2 0xb64021e3 in abort () from /usr/lib/libc.so.6 #3 0xb6793775 in QMessageLogger::fatal(char const*, …) const () from /usr/lib/libQt5Core.so.5 #4 0xb74da6fc in QV4::Compiler::Codegen::visit(QQmlJS::AST::UiProgram*) () from /usr/lib/libQt5Qml.so.5 #5 0xb756f446 in QJSEngine::QJSEngine(QJSEnginePrivate&, QObject*) () from /usr/lib/libQt5Qml.so.5 #6 0xb76afe1d in QQmlEngine::QQmlEngine(QObject*) () from /usr/lib/libQt5Qml.so.5 #7 0xb7cf93bb in QQuickViewPrivate::init(QQmlEngine*) () from /usr/lib/libQt5Quick.so.5 #8 0x0050c571 in SDDM::GreeterApp::addViewForScreen(QScreen*) () #9 0x0050d1a4 in SDDM::GreeterApp::startup() () #10 0xb69a6a4e in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5 #11 0xb697a565 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5 #12 0xb697d8c6 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt5Core.so.5 #13 0xb697dcd9 in QCoreApplication::sendPostedEvents(QObject*, int) () from /usr/lib/libQt5Core.so.5 #14 0xb69d4f74 in ?? () from /usr/lib/libQt5Core.so.5 #15 0xb55bca1e in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #16 0xb55beafa in ?? () from /usr/lib/libglib-2.0.so.0 #17 0xb55beb46 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #18 0xb69d44bb in QEventDispatcherGlib::processEvents(QFlags) () –Type for more, q to quit, c to continue without paging–
from /usr/lib/libQt5Core.so.5 #19 0xb6978ff6 in QEventLoop::exec(QFlags) () from /usr/lib/libQt5Core.so.5 #20 0xb698188b in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5 #21 0x004ed3d0 in main ()
There seems to be a problem around Javascript and Qt5
Comments (1) Related Tasks (0/0)
Admin Andreas Baumann commented on 12.05.2019 18:25
New bug on pentium4:
Stack trace of thread 387: #0 0x00000000b7fa8841 kernel_vsyscall (linux-gate.so.1)
#1 0x00000000b63311b6 raise (libc.so.6)
#2 0x00000000b631b1e3 abort (libc.so.6)
#3 0x00000000b66b2773 _ZNK14QMessageLogger5fatalEPKcz (libQt5Core.so.5)
#4 0x00000000b7b98592 _ZN13QSGRenderLoop28handleContextCreationFailureEP12QQuickWindowb (libQt5Quick.so.5)
#5 0x00000000b7b99a1d n/a (libQt5Quick.so.5)
#6 0x00000000b7b9a35b n/a (libQt5Quick.so.5)
#7 0x00000000b6c95427 _ZN7QWindow5eventEP6QEvent (libQt5Gui.so.5)
#8 0x00000000b7c22c60 _ZN12QQuickWindow5eventEP6QEvent (libQt5Quick.so.5)
#9 0x00000000b68a8845 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5)
#10 0x00000000b6c898ab _ZN22QGuiApplicationPrivate18processExposeEventEPN29QWindowSystemInterfacePrivate11ExposeEventE (libQt5Gui.so.5)
#11 0x00000000b6c89bda _ZN22QGuiApplicationPrivate24processWindowSystemEventEPN29QWindowSystemInterfacePrivate17WindowSystemEventE (libQt5Gui.so.5)
#12 0x00000000b6c5e085 _ZN22QWindowSystemInterface22sendWindowSystemEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Gui.so.5)
#13 0x00000000b0b7631d n/a (libQt5XcbQpa.so.5)
#14 0x00000000b54ddb1e g_main_context_dispatch (libglib-2.0.so.0)
#15 0x00000000b54dfbfa n/a (libglib-2.0.so.0)
#16 0x00000000b54dfc46 g_main_context_iteration (libglib-2.0.so.0)
#17 0x00000000b690172b _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)
#18 0x00000000b68a72d6 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5)
#19 0x00000000b68af8db _ZN16QCoreApplication4execEv (libQt5Core.so.5)
#20 0x00000000004a4330 main (sddm-greeter)
#21 0x00000000b631c669 __libc_start_main (libc.so.6)
#22 0x00000000004a4635 _start (sddm-greeter)
Stack trace of thread 388:
#0 0x00000000b7fa8841 __kernel_vsyscall (linux-gate.so.1)
#1 0x00000000b63e0ed3 __poll (libc.so.6)
#2 0x00000000b7a236ce n/a (libxcb.so.1)
#3 0x00000000b7a25864 xcb_wait_for_event (libxcb.so.1)
#4 0x00000000b0b751ea n/a (libQt5XcbQpa.so.5)
#5 0x00000000b66f39e0 n/a (libQt5Core.so.5)
#6 0x00000000b620dab2 start_thread (libpthread.so.0)
#7 0x00000000b63ea96a __clone (libc.so.6)
Stack trace of thread 389:
#0 0x00000000b7fa8841 __kernel_vsyscall (linux-gate.so.1)
#1 0x00000000b63e0ed3 __poll (libc.so.6)
#2 0x00000000b54dfb55 n/a (libglib-2.0.so.0)
#3 0x00000000b54dfc46 g_main_context_iteration (libglib-2.0.so.0)
#4 0x00000000b690172b _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)
#5 0x00000000b68a72d6 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5)
#6 0x00000000b66f2412 _ZN7QThread4execEv (libQt5Core.so.5)
#7 0x00000000b0a20cdd n/a (libQt5DBus.so.5)
#8 0x00000000b66f39e0 n/a (libQt5Core.so.5)
#9 0x00000000b620dab2 start_thread (libpthread.so.0)
#10 0x00000000b63ea96a __clone (libc.so.6)
Stack trace of thread 391:
#0 0x00000000b7fa8841 __kernel_vsyscall (linux-gate.so.1)
#1 0x00000000b63e0ed3 __poll (libc.so.6)
#2 0x00000000b54dfb55 n/a (libglib-2.0.so.0)
#3 0x00000000b54dfc46 g_main_context_iteration (libglib-2.0.so.0)
#4 0x00000000b690172b _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5)
#5 0x00000000b68a72d6 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5)
#6 0x00000000b66f2412 _ZN7QThread4execEv (libQt5Core.so.5)
#7 0x00000000b77189c3 n/a (libQt5Qml.so.5)
#8 0x00000000b66f39e0 n/a (libQt5Core.so.5)
#9 0x00000000b620dab2 start_thread (libpthread.so.0)
#10 0x00000000b63ea96a __clone (libc.so.6)
Google Cache
|
|
166 | Packages | Bug Report | Medium | Low | s2n-tls: failing tests | New | |
Task Description
The following tests FAILED:
91 - s2n_pq_kem_hybrid_kat_test (Failed)
145 - s2n_session_ticket_test (Failed)
154 - s2n_stuffer_network_order_test (Failed)
184 - s2n_x509_validator_test (Failed)
https://github.com/aws/s2n-tls/issues/2405 https://github.com/aws/s2n-tls/issues/2406 https://github.com/aws/s2n-tls/issues/2404
3 are known upstream too.
|
|
181 | Packages | Bug Report | Medium | Low | rust 1.51.0 recompilation issues | Closed | |
Task Description
Compiling same-file v1.0.6
| ^^^
= note: `-D non-fmt-panic` implied by `-D warnings`
= note: this is no longer accepted in Rust 2021
help: add a "{}" format string to Display the message
|
1493 | panic!("{}", out);
| ^^^^^
help: or use std::panic::panic_any instead
|
1493 | std::panic::panic_any(out);
| ^^^^^^^^^^^^^^^^^^^^^^
Brilliantly fast changing language..
|
|
129 | Packages | Bug Report | Medium | Low | rust 1.47 is outdated | Closed | |
Task Description
either building 1.49 via 1.48, via 1.47 or we have to bootstrap from a binary version again.
|
|
47 | Packages: Stable | Bug Report | Medium | Low | rankmirrors $repo guessing broken in i686 only | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Levi - 26.07.2018 Last edited by Erich Eckner - 27.07.2018
FS#47 - rankmirrors $repo guessing broken in i686 only
I usually use rankmirrors on my mirrorlist prior to installing them fully to sort them such that the quickest mirrors are listed first.
I found that when using them to sort my mirrorlist.pacnew, it would claim each server target was unreachable, and reproduce them in their original order, making the tool rather useless. Workaround
I also discovered that I can work around the problem by passing an argument of ‘-r core’ to the invocation, e.g. ‘$ rankmirrors -r core /etc/pacman.d/mirrorlist.pacnew > mirrorlist.temp’ Steps to reproduce
rankmirrors -t /etc/pacman.d/mirrorlist.pacnew
This -t option prints out the timings, or unreachable if it failed to create a valid uri. Investigation
My investigations thus far show that /usr/bin/rankmirrors is a bash script, and it looks like the if statement starting on line 79 in the current version (the first if statement in the getfetchurl function) is designed to replace the $repo string with whatever $TARGETREPO is, else ‘core’ which suggests it should work by default.
The only consistent difference in the format of the mirrorlist file between here and on my x64 machine (where rankmirrors continues to work fine) is that on x64 the repos almost all have /os before /$repo while we often have it at the root of the public filesystem, or under something other than /os.
Unfortunately the vagaries of bash string substitution are something I rarely touch and never touch again provided they continue to work, so I can’t guess why this would have stopped working for us. If I have time to dig further I’ll comment here though, of course. Closed by Erich Eckner 27.07.2018 04:22 Reason for closing: Fixed Additional comments about closing:
note, that this deliberately does not work with upstream’s mirror layout
Comments (2)
Related Tasks (0/0)
Admin Erich Eckner commented on 26.07.2018 19:13
ok, I just checked - with my mirrorlist, it works (this is not the default mirrorlist) - so I suspect, it breaks due to our format of the urls ($root/$arch/$repo instead of $root/$repo/os/$arch) - I’ll look into this Admin Erich Eckner commented on 26.07.2018 19:38
I think, I fixed it - let’s see if it “compiles” and runs
Google Cache
|
|
116 | Packages | Bug Report | Medium | Low | Race causes iptables not to be ready after startup | New | |
Task Description
Nov 06 08:04:01 eurohp1 systemd[1]: Starting IPv4 Packet Filtering Framework… Nov 06 08:04:01 eurohp1 iptables-restore[287]: Another app is currently holding the xtables lock. Perhap> Nov 06 08:04:01 eurohp1 systemd[1]: iptables.service: Main process exited, code=exited, status=4/NOPERMI> Nov 06 08:04:01 eurohp1 systemd[1]: iptables.service: Failed with result ‘exit-code’. Nov 06 08:04:01 eurohp1 systemd[1]: Failed to start IPv4 Packet Filtering Framework.
Works when starting iptables later manually.
This is security relevant as not having a firewall after startup puts the system at risk.
|
|
43 | Packages: Build-list | Bug Report | Medium | Low | qt5-webengine, firefox, firefox-developer-edition use t ... | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Andreas Baumann - 16.06.2018 Last edited by Andreas Baumann - 02.10.2019
FS#43 - qt5-webengine, firefox, firefox-developer-edition use too much memory
In file included from gen/third_party/WebKit/public/platform/modules/presentation/presentation.mojom-shared.h:24,
from gen/third_party/WebKit/public/platform/modules/presentation/presentation.mojom.h:37,
from ../../../../qtwebengine-everywhere-src-5.11.0/src/3rdparty/chromium/content/browser/frame_host/render_frame_host_impl.h:66,
from ../../../../qtwebengine-everywhere-src-5.11.0/src/3rdparty/chromium/content/browser/frame_host/frame_tree_node.h:18,
from ../../../../qtwebengine-everywhere-src-5.11.0/src/3rdparty/chromium/content/browser/devtools/browser_devtools_agent_host.cc:21:
gen/third_party/WebKit/public/platform/modules/presentation/presentation.mojom-shared-internal.h:139:35: warning: alignment 1 of ‘blink::mojom::internal::PresentationConnectionMessage_Data’ is less than 8 [-Wpacked-not-aligned] class MOJOM_SHARED_CONTENT_EXPORT PresentationConnectionMessage_Data {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
virtual memory exhausted: Cannot allocate memory ninja: build stopped: subcommand failed.
Also in firefox:
91:37.06 ../../build/unix/gold/ld: fatal error: libxul.so: mmap: failed to allocate 1703955732 bytes for output file: Cannot allocate memory 91:37.06 collect2: error: ld returned 1 exit status 91:37.06 make[4]: * [/build/firefox/src/mozilla-unified/config/rules.mk:701: libxul.so] Error 1 91:37.06 make[3]: * [/build/firefox/src/mozilla-unified/config/recurse.mk:73: toolkit/library/target] Error 2 91:37.06 make[2]: * [/build/firefox/src/mozilla-unified/config/recurse.mk:33: compile] Error 2 91:37.06 make[1]: * [/build/firefox/src/mozilla-unified/config/rules.mk:434: default] Error 2 91:37.06 make: *** [client.mk:168: build] Error 2
Closed by Andreas Baumann 02.10.2019 19:26 Reason for closing: Fixed Additional comments about closing:
Currently firefox and qt5-webengine build. firefox-developer-edition is blacklisted as it causes too much trouble already as the official released version, so we don’t to beta testing here..
Comments (10)
Related Tasks (0/0)
Admin Andreas Baumann commented on 16.06.2018 05:33
Build slaves should have a 4GB swap space (if they are virtual machines), and sysctl vm.mmap_min_addr=0 should be set.
For containers I don’t know what’s best becauste systemd-nspawn has a mind of its own. sysctl vm.mmap_min_addr=0 on the host helped here too. Admin Andreas Baumann commented on 16.06.2018 05:37
Another solution could be not to use the gold-ld. Admin Andreas Baumann commented on 16.06.2018 06:26
and another one:
CodeCache::InnerPointerToCodeCacheEntry’; use assignment or value-initialization instead [-Wclass-memaccess]
memset(&cache_[0], 0, sizeof(cache_));
^
../../../../qtwebengine-everywhere-src-5.11.0/src/3rdparty/chromium/v8/src/frames.h:36:10: note: ‘struct v8::internal::InnerPointerToCodeCache::InnerPointerToCodeCacheEntry’ declared here
struct InnerPointerToCodeCacheEntry {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
{standard input}: Assembler messages: {standard input}:15117: Warning: end of file not at end of a line; newline inserted {standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive g++: fatal error: Terminated signal terminated program cc1plus compilation terminated. ninja: build stopped: subcommand failed.
This looks like truncated assembly to me. Maybe using tmpfile instead of -pipe? Admin Andreas Baumann commented on 17.06.2018 06:24
qt5-webkit fails now much later in a build race in a plugin. removing -pipe could also help for all other packages running out of virtual memory, so maybe changing the global build options to ‘-j1’ and not ‘-pipe’ in makepkg.conf is an idea. Or we patch the affected packages only, but patching away a -pipe might not be as easy as one may think. Admin Andreas Baumann commented on 20.06.2018 05:01
Still trouble with firefox and firefox-developer-edition, -pipe gets added somewhere even if I change it in the build chroot configuration in makepkg.conf.. Admin Andreas Baumann commented on 21.06.2018 11:46
-pipe doens’t have a huge impact.
So I’ll try with some special LDFLAGS -Wl,–no-keep-memory, after a hint in:
https://bugzilla.mozilla.org/show_bug.cgi?id=854535 Admin Andreas Baumann commented on 23.06.2018 07:56
A top on a 64-bit Archlinux shows me the following during a build:
26963 arch 20 0 6336364 1.8g 1468 R 7.0 91.8 1:44.14 dump_syms
0 S arch 26958 26956 0 80 0 - 25355 - 20:29 pts/0 00:00:00 /data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/_virtualenv/bin/python /data/firefox/src/mozilla-unified/toolkit/crashreporter/tools/symbolstore.py -c –vcs-info –install-manifest=/data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/_build_manifests/install/dist_include,/data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/include -s /data/firefox/src/mozilla-unified /data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/host/bin/dump_syms /data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/crashreporter-symbols /data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/toolkit/library/libxul.so 0 D arch 26963 26958 7 80 0 - 1146305 - 20:29 pts/0 00:00:34 /data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/dist/host/bin/dump_syms /data/firefox/src/mozilla-unified/obj-x86_64-pc-linux-gnu/toolkit/library/libxul.so
So, this dump_syms program will never work in an 32-bit address room. The question is, can it be tuned or hacked? The question, why did it work till now and what changed so it doesn’t work currently? Admin Andreas Baumann commented on 02.07.2018 15:58
Another try using the standard linker instead of the gold one. Admin Andreas Baumann commented on 02.07.2018 19:43
I think, I’m in the wrong movie:
36:53.02 libxul.so 37:13.26 /usr/bin/ld: out of memory allocating 1000 bytes after a total of 898674688 bytes 37:13.26 collect2: error: ld returned 1 exit status
Admin Andreas Baumann commented on 02.10.2019 19:24
Rust things also run out of memory (firefox), disabling some debug info with debug_info=1 makes the builds succeed.
Google Cache
|
|
158 | Packages | Bug Report | Medium | Low | protobuf python bindings fail to build | Closed | |
Task Description
OK (skipped=10) Traceback (most recent call last):
File "/usr/lib/python3.9/site-packages/packaging/version.py", line 57, in parse
return Version(version)
File "/usr/lib/python3.9/site-packages/packaging/version.py", line 298, in __init__
raise InvalidVersion("Invalid version: '{0}'".format(version))
packaging.version.InvalidVersion: Invalid version: ‘/build/protobuf/src/protobuf’
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/build/protobuf/src/protobuf-3.12.4/python/setup.py", line 251, in <module>
setup(
File "/usr/lib/python3.9/site-packages/setuptools/__init__.py", line 153, in setup
return distutils.core.setup(**attrs)
File "/usr/lib/python3.9/distutils/core.py", line 148, in setup
dist.run_commands()
File "/usr/lib/python3.9/distutils/dist.py", line 966, in run_commands
self.run_command(cmd)
File "/usr/lib/python3.9/distutils/dist.py", line 985, in run_command
cmd_obj.run()
File "/usr/lib/python3.9/site-packages/setuptools/command/test.py", line 232, in run
self.run_tests()
File "/usr/lib/python3.9/contextlib.py", line 124, in __exit__
next(self.gen)
File "/usr/lib/python3.9/site-packages/setuptools/command/test.py", line 169, in project_on_sys_path
working_set.__init__()
File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 552, in __init__
self.add_entry(entry)
File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 608, in add_entry
for dist in find_distributions(entry, True):
File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 2059, in find_on_path
path_item_entries = _by_version_descending(filtered)
File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 2029, in _by_version_descending
return sorted(names, key=_by_version, reverse=True)
File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 2027, in _by_version
return [packaging.version.parse(part) for part in parts]
File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 2027, in <listcomp>
return [packaging.version.parse(part) for part in parts]
File "/usr/lib/python3.9/site-packages/packaging/version.py", line 59, in parse
return LegacyVersion(version)
File "/usr/lib/python3.9/site-packages/packaging/version.py", line 127, in __init__
warnings.warn(
DeprecationWarning: Creating a LegacyVersion has been deprecated and will be removed in the next major release =⇒ ERROR: A failure occurred in check().
Aborting...
=⇒ ERROR: Build failed, check /var/lib/archbuild/staging-pentium4/abaumann/build
both i686 and pentium4
|