|
85 | Packages: Stable | Bug Report | Medium | Low | [wireguard-arch] Package not being updated alongside ke ... | Closed | |
Task Description
The last update to this package was August 25, despite several new kernel builds since this. As a result, the package does not work and users must use …
|
|
86 | Packages: Stable | Bug Report | Medium | Low | newsboat contains SSE2 instuctions | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Andreas Baumann - 14.09.2019 Last edited by Andreas Baumann - 14.09.2019
FS#86 - newsboat contains SSE2 instuctions
shell> newsboat
Program received signal SIGILL, Illegal instruction. 0x005f5cd9 in ?? () => 0x005f5cd9: f2 0f 10 06 movsd (%esi),%xmm0 (gdb) bt #0 0x005f5cd9 in ?? () #1 0x005f40fa in ?? () #2 0x005f3f3b in ?? () #3 0x0072e9fd in ?? () #4 0×00661600 in ?? () #5 0×00659435 in ?? () #6 0x0061fe88 in ?? () #7 0x0065770c in ?? () #8 0x005ea416 in ?? () #9 0x0044ca68 in ?? () #10 0xb76f9859 in __libc_start_main () from /usr/lib/libc.so.6 #11 0x0044da75 in ?? ()
This actually looks like glibc got a SSE2 infection on i686.
Google Cache
|
|
91 | Packages: Stable | Bug Report | Medium | Low | [python2]: segfault | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by bill auger - 12.10.2019
FS#91 - [python2]: segfault
i am trying to build calibre for i686 - using the arch PKGBUILD for v3.48.0, and also the latest 4.1.0 - python2 segfults immediately in build()
possibly related to #20 https://bugs.archlinux32.org/index.php?do=details&task_id=20
“line 86” below depends on the PKGBUILD - it is the command:
LANG=’en_US.UTF-8’ python2 setup.py build
$ makepkg -sr …. ==> Starting build()…
* * Running build *
/home/auser/calibre/PKGBUILD: line 86: 7793 Segmentation fault (core dumped) LANG=’en_US.UTF-8’ python2 setup.py build ==> ERROR: A failure occurred in build().
Aborting...
$ cd src/calibre-3.48.0/ $ LANG=’en_US.UTF-8’ python2 setup.py build
* * Running build *
Segmentation fault (core dumped)
Google Cache
|
|
96 | Packages: Stable | Bug Report | Medium | Medium | [rust] broken or missing backend | Closed | |
Task Description
shell> echo > rust.rc <<EOF
fn main() {
println!( "Hello Rust! " );
}
EOF
shell> rustc rust.rs
error: failed to find a `codegen-backends` folder in the sysroot candidates:
* /usr
* /usr
Presumably the i686 folders are moved around in PKGBUILD to form lib32 libraries for rust on 64-bit.
|
|
99 | Packages: Stable | Bug Report | Medium | Low | Incompatible Qt library (version 0x50d02) with this lib ... | Closed | |
Task Description
Seen with trojita: Cannot mix incompatible Qt library (version 0x50d02) with this library (version 0x50d01)
|
|
101 | Packages: Stable | Bug Report | Medium | Low | clang 9.0.0 moved to stable too soon (breaks kdevelop) | Closed | |
Task Description
:: installing clang (9.0.1-1.0) breaks dependency ‘clang=9.0.0’ required by kdevelop
|
|
102 | Packages: Stable | Bug Report | Medium | Low | firefox-i18-n gets pushed to stable though firefox is n ... | Closed | |
Task Description
warning: cannot resolve “firefox>=71.0”, a dependency of “firefox-i18n-de”
|
|
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
|
|
105 | Packages: Stable | Bug Report | Medium | Low | chromium crash in blocked syscalls (libseccomp) | Closed | |
Task Description
chromium apparently also has trouble in some seccomp jailing:
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403
[1201:1210:0227/131355.020958:FATAL:gpu_data_manager_impl_private.cc(990)] The display compositor is frequently crashing. Goodbye.
[1]+ Trace/breakpoint trap (core dumped) chromium
|
|
193 | Packages: Stable | Bug Report | Medium | Low | pacman does not recognize sse2 on via processor | Closed | |
Task Description
/proc/cpuinfo: processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 15 model name : VIA Nano U3400@800MHz stepping : 10 cpu MHz : 798.016 cache size : 2048 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush acpi mmx fxsr sse sse2 ss tm syscall nx lm constant_tsc arch_perfmon rep_good cpuid pni monitor vmx est tm2 ssse3 cx16 xtpr sse4_1 popcnt rng rng_en ace ace_en ace2 phe phe_en pmm pmm_en lahf_lm tpr_shadow vnmi vpid ida vmx flags : vnmi tsc_offset vtpr bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips : 1596.53 clflush size : 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management:
Other machine, also with via processor:
/proc/cpuinfo: processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 13 model name : VIA C7-D Processor 1800MHz stepping : 0 cpu MHz : 1596.326 cache size : 128 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fdiv_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx cpuid pni est tm2 xtpr rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit bogomips : 3193.67 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 32 bits virtual power management:
All the __builtin_cpu_supports() and __builtin_cpu_is() tests fail. Thus, pacman thinks, it’s not capable of sse2 and installs i686 packages instead of pentium4 ones.
Should we complain at gcc upstream? How does the kernel compile this line in /proc/cpuinfo? What checks does it perform?
|
|
33 | Packages: Testing | Bug Report | Medium | Low | [icu] sobump mismatch | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Andreas Baumann - 05.04.2018 Last edited by Andreas Baumann - 11.04.2018
FS#33 - [icu] sobump mismatch
For instance:
[quote] shell> kwin_x11 kwin_x11: error while loading shared libraries: libicui18n.so.60: cannot open shared object file: No such file or directory [/quote]
Seen similar on ArchlinuxARM, so I guess it’s an undetected SO-bump from upstream.. Closed by Andreas Baumann 11.04.2018 16:47 Reason for closing: Fixed Additional comments about closing:
Actually, also gdal is fine on staging.
Comments (1)
Related Tasks (0/0)
Admin Erich Eckner commented on 11.04.2018 11:59
I can only see gdal being still wrongly linked against icu-60 in testing or staging - can you confirm?
Google Cache
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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.
|
|
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
|
|
177 | Packages: Testing | Bug Report | Medium | Medium | [gcc] CPU ISA level is lower than required | Closed | |
Task Description
$ cc –version cc: CPU ISA level is lower than required
The same happens in a chroot for [staging].
$ pacman -Qo /usr/bin/cc /usr/bin/cc is owned by gcc 10.2.0-6.0
$ pacman -Q glibc glibc 2.33-4.0
Does that mean, anything building with gcc is doomed on i686, currently?
|
|
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
|
|
178 | Devops | Bug Report | Very Low | Low | New installer overwrites pacman mirrors | Closed | |
Task Description
I tried to install archlinux32 using the archinstall installer, which is shipped with the installation medium. Installation is working fine until pacstrap, where it will crash because all mirrors will return 404. I checked my connection and it is working and dns also works. When I viewed the /etc/pacman.d/mirrorlist file, I saw that the script wrote the default archlinux mirrors for the region specified in the installer to the file and the don’t contain the 32bit packages.
|
|
302 | Devops | Feature Request | Very Low | Low | Are you gonna continue 486 support? | Closed | |
Task Description
https://www.tomshardware.com/news/linux-removes-486-cpu-support
486 will be removed from the kernel and especially from 6.1 onwards rust will be integrated with the kernel…
|
|
107 | Packages | Bug Report | Very Low | Low | wireguard-dkms-0.0.20200318-1.0 does not build with 5.5 ... | Closed | |
Task Description
Installing wireguard-dkms fails with:
(2/2) Install DKMS modules
==> dkms install wireguard/0.0.20200318 -k 5.5.8-arch1-1.0
Error! Bad return status for module build on kernel: 5.5.8-arch1-1.0 (i686)
Consult /var/lib/dkms/wireguard/0.0.20200318/build/make.log for more information.
The file /var/lib/dkms/wireguard/0.0.20200318/build/make.log contains the following messages:
DKMS make.log for wireguard-0.0.20200318 for kernel 5.5.8-arch1-1.0 (i686)
Fri 03 Apr 2020 10:11:21 PM CEST
make: Entering directory '/usr/lib/modules/5.5.8-arch1-1.0/build'
AR /var/lib/dkms/wireguard/0.0.20200318/build/built-in.a
CC [M] /var/lib/dkms/wireguard/0.0.20200318/build/main.o
cc1: error: incompatible gcc/plugin versions
cc1: error: fail to initialize plugin ./scripts/gcc-plugins/structleak_plugin.so
make[1]: *** [scripts/Makefile.build:266: /var/lib/dkms/wireguard/0.0.20200318/build/main.o] Error 1
make: *** [Makefile:1693: /var/lib/dkms/wireguard/0.0.20200318/build] Error 2
make: Leaving directory '/usr/lib/modules/5.5.8-arch1-1.0/build'
|
|
110 | Packages | Bug Report | Very Low | Low | [syslog-ng] is built without systemd support | Closed | |
Task Description
The packages for syslog-ng since version 3.27.1-1.0 appears to have been built without systemd support. Although their PKGBUILD runs configure with –enable-systemd, running syslog-ng –version shows Enable-Systemd: off. The official Arch x86_64 package (at version 3.28.1-1) doesn’t exhibit this problem.
I tried building the package locally on i686 using the official Arch PKGBUILD and could not reproduce the problem. My locally built version correctly finds libsystemd during configure, and gets built with systemd support. This leads me to believe the problem happens somewhere in the Archlinux32 build process.
The practical upshot of the problem is that the systemd unit file supplied with syslog-ng lists it as a Type=notify service, but when it fails to notify systemd after startup, systemd eventually kills it and restarts it repeatedly:
Jul 24 07:32:31 wolfie systemd[1]: Starting System Logger Daemon "default" instance...
Jul 24 07:32:32 wolfie syslog-ng[18977]: syslog-ng starting up; version='3.28.1'
Jul 24 07:34:01 wolfie systemd[1]: syslog-ng@default.service: start operation timed out. Terminating.
Jul 24 07:34:01 wolfie syslog-ng[18977]: syslog-ng shutting down; version='3.28.1'
Jul 24 07:34:01 wolfie systemd[1]: syslog-ng@default.service: Failed with result 'timeout'.
Jul 24 07:34:01 wolfie systemd[1]: Failed to start System Logger Daemon "default" instance.
Jul 24 07:34:02 wolfie systemd[1]: syslog-ng@default.service: Scheduled restart job, restart counter is at 1.
Jul 24 07:34:02 wolfie systemd[1]: Stopped System Logger Daemon "default" instance.
Jul 24 07:34:02 wolfie systemd[1]: Starting System Logger Daemon "default" instance...
|
|
111 | Packages | Bug Report | Very Low | High | [libxcrypt]: conflicts with glibc | Closed | |
Task Description
# pacman -Syu
....
error: failed to commit transaction (conflicting files)
libxcrypt: /usr/include/crypt.h exists in filesystem (owned by glibc)
libxcrypt: /usr/lib/libcrypt.so exists in filesystem (owned by glibc)
Errors occurred, no packages were upgraded.
this is a rather critical bug - it is required by gtk and qt, via libcups; so most desktop users are affected by it
|
|
112 | Packages | Bug Report | Very Low | Low | [lxpanel]: segfaults on startup | Closed | |
Task Description
# pacman -Sy lxde reboot and start lxsession lxpanel will crash immediately, with this error in dmesg
pcmanfm[501]: segfault at 2d ip b74823cf sp bf9dd0d0 error 4 in libpango-1.0.so.0.4600.0[b7466000+29000]
lxpanel does not have this problem with GTK3 # pacman -Sy lxde-gtk3 works as expectd
|
|
113 | Packages | Bug Report | Very Low | Low | [leafpad]: segfaults | Closed | |
Task Description
start leafpad everything looks fine type or paste anything and it segfaults with this error in dmesg
leafpad[550]: segfault at 1 ip b77adf13 sp bfd0eaec error 4 in libgobject-2.0.so.0.6400.3[b7787000+2f000]
|
|
117 | Packages | Bug Report | Very Low | Low | vboxdrive module missing | New | |
Task Description
vboxdrv module is missing making virtualbox unusable.
I’m currently running kernel 5.9.0-1.0-pae but it doesn’t seem to be there in any version
|
|
118 | Packages | Bug Report | Very Low | Medium | signing key is expired | Closed | |
Task Description
When trying to install the package, packman complies about the the key to be of unknown trust. Cheking the keyring the associated key appers to be expired.
|
|
119 | Packages | Bug Report | Very Low | High | [gdb] needs rebuilt after python upgrade | Closed | |
Task Description
Pacman recently upgraded python from 3.8 to 3.9, which breaks the gdb package:
% gdb
gdb: error while loading shared libraries: libpython3.8.so.1.0: cannot open shared object file: No such file or directory
|
|
120 | Packages | Bug Report | Very Low | Low | Princeton ArchLinux32 mirror has been out of date; ques ... | Closed | |
Task Description
The ArchLinux32 mirror at http[s]://mirror.math.princeton.edu/pub/archlinux32/ appears to have stopped syncing properly in October. I contacted web@math.princeton.edu on January 1 to alert them to the problem, and received the following response from a Princeton sysadmin:
Here is the configuration I am using:
archlinux32: remotesrc: “rsync://mirror.archlinux32.org/archlinux32/”
localdest: “/var/www/html/pub/archlinux32”
extraopts: “–port=22873”
Looks like at some point this stopped working from upstream:
Raw standard error: rsync: failed to connect to mirror.archlinux32.org (85.10.198.216): Connection refused (111) rsync: failed to connect to mirror.archlinux32.org (2a01:4f8:a0:5264::2): Network is unreachable (101) rsync error: error in socket IO (code 10) at clientserver.c(125) [Receiver=3.1.2]
Can you recommend a better upstream target I can use? And if there are additional constraints on checkin time or frequency.
I informed him that I am not an official member of the ArchLinux32 team, but suggested that using the regular rsync port of 873 might work as mirror.archlinux32.org appears to accept connections to that port from the Internet. As of the time of this writing, it appears that the mirror is now again up to date (although it has other issues returning HTTP error 403 for some of its files), but I promised to bring his additional questions to the official team.
So, to iterate, is this the appropriate target to mirror, or should they use some other parameters?
Thank you.
|
|
121 | Packages | Bug Report | Very Low | High | Multiple packages need rebuild after libicu upgrade | Closed | |
Task Description
Over in FS#119 , @abaumann mentioned that the libicu upgrade from 67 to 68 was part of what broke gdb. I missed the libicu upgrade when looking at gdb, but now that that one is resolved, I noticed a number of other packages that still link against the old and now nonexistant /usr/lib/libicu*.so.67 files. On my particular system, the following packages are installed, link to icu 67, and need rebuilt as well:
* harfbuzz-icu (2.7.0-1.0) * mongo-c-driver (1.17.3-1.0) * postfix (3.5.6-2.0) * postgresql (12.4-1.0) * postgresql-old-upgrade (12.5-1.0) * samba (4.12.3-1.2) * smbclient (4.12.3-1.2) * syslog-ng (3.28.1-3.0) * texlive-bin (2020.54586-4.0) * xfsprogs (5.8.0-1.0)
… but I’m sure you have a way of determining all the affected packages?
As a workaround, in case others have the same problem, I manually extracted the old versioned .so files from the previous package to get things working again:
``` tar -C / -xf /var/cache/pacman/pkg/icu-67.1-1.0-i686.pkg.tar.zst –wildcards ‘usr/lib/lib*.so.*’ ```
- I’ll just have to remember to clean them up again later.
|
|
122 | Packages | Bug Report | Very Low | Low | Permissions bits on files on the primary mirror are too ... | Closed | |
Task Description
In my quest to find a working mirror close to me, I’ve come across another issue with at least a couple of mirrors. Some mirrors respond with a HTTP 403 Forbidden for certain files, notably many of the Pacman database files. At the time of this writing, I’m aware of this problem happening with the princeton.edu and the clarkson.edu mirrors. I’ve been in contact with the admin of one of the mirrors, and they’ve pointed out that the permission bits are set to 0600 at the source. If the primary mirror could have their files be world readable, it would likely fix this problem automatically across more than one mirror.
Is that something we can do?
Steps to verify:
1. Access certain files from the primary mirror using rsync, for example:
% rsync -av rsync://mirror.archlinux32.org/archlinux32/i686/extra/extra.db.tar.gz .
receiving incremental file list
extra.db.tar.gz
sent 43 bytes received 2,044,453 bytes 371,726.55 bytes/sec
total size is 2,043,851 speedup is 1.00
2. Examine permission bits:
% ls -l extra.db.tar.gz
-rw------- 1 user user 2043851 Jan 8 11:51 extra.db.tar.gz
Should be -rw-r–r–.
|
|
134 | Packages | Bug Report | Very Low | Low | arm-none-eabi-gdb requires rebuild | Closed | |
Task Description
arm-none-eabi-gdb is broken due to not satisfiable dependency: “libpython3.8.so.1.0” After recompiling from upstream it works.
|
|
169 | Packages | Feature Request | Very Low | Low | New mirror: mirror.nw-sys.ru | Closed | |
Task Description
I didn’t found any message about reporting new mirrors of archlinux32 project, so I decided to open new FR. Sorry if I mistaken and show me the right way, please :)
Domain name: mirror.nw-sys.ru Country: Russia Supported access methods for mirror: http(s) - http(s)://mirror.nw-sys.ru/archlinux32/ rsync - rsync://mirror.nw-sys.ru/archlinux32 Mirror bandwidth - 100 Mbit/s almostly, with slight slowdowns around the day. Primary administrative contact - no1@no1sg.ru Alternative administrative contact - morgan29rus@gmail.com Source mirror - mirror.archlinux32.org
|
|
170 | Packages | Bug Report | Very Low | Low | [libarchive] zstd minimum version dependency - zstd>=1. ... | Closed | |
Task Description
libarchive has a dependency upon the zstd libzstd with a version recent enough to provide the symbol ZSTD_minCLevel.
PKGBUILD:
depends=(... 'zstd>=1.3.6')
This is an issue when upgrading pacman to support the zstd packaging format. pacman must depend upon libarchive>=3.3.3 for zstd compression support. libarchive will then depend upon zstd>=1.3.6 for the symbol ZSTD_minCLevel.
Without these, upgrading an old Arch Linux system gives the incomplete - so unhelpful - error message:
error: could not open file /var/cache/pacman/pkg/something.pkg.tar.zst: Unrecognized archive format
How does pacman recognize an archive format? If the user does not already know the answer, they are in trouble. And, mistakenly circumventing the package compression to force an upgrade of pacman alone will lead to even more trouble, since pacman itself is not the source of the problem.
|
|
171 | Packages | Bug Report | Very Low | Low | [pacman] libarchive minimum version dependency - libarc ... | Closed | |
Task Description
pacman has a dependency upon libarchive with a version recent enough to support zstd compression.
depends=(... 'libarchive>=3.3.3')
This is an issue when upgrading pacman to support the zstd packaging format. pacman must depend upon libarchive>=3.3.3 for zstd compression support. libarchive will then depend upon zstd>=1.3.6 for the symbol ZSTD_minCLevel.
Without these, upgrading an old Arch Linux system gives the incomplete - so unhelpful - error message:
error: could not open file /var/cache/pacman/pkg/something.pkg.tar.zst: Unrecognized archive format
How does pacman recognize an archive format? If the user does not already know the answer, they are in trouble. And, mistakenly circumventing the package compression to force an upgrade of pacman alone will lead to even more trouble, since pacman itself is not the source of the problem.
|
|
172 | Packages | Bug Report | Very Low | Medium | iwd requires some kernel flags | Unconfirmed | |
Task Description
RC4 support not found The following options are missing in the kernel:
CONFIG_CRYPTO_USER_API_SKCIPHER
CONFIG_CRYPTO_ECB
CONFIG_CRYPTO_ARC4
|
|
173 | Packages | Bug Report | Very Low | Medium | supertux is broken (depends on libboostfilesystem 0.72 ... | Closed | |
Task Description
Supertux needs to be rebuilt as it currently depends on the wrong version of libboostfilesystem.
https://www.archlinux32.org/packages/i686/community/supertux/ not satisfiable dependency: “libboost_filesystem.so.1.72.0” (link) not satisfiable dependency: “libboost_locale.so.1.72.0” (link)
This affects all architectures (i686 and pentium4)
|
|
175 | Packages | Bug Report | Very Low | Low | [pango]: symbol lookup error: /usr/lib/libpango-1.0.so. ... | Closed | |
Task Description
this is a rather severe bug - it prevents GTK DMs, DEs, and programs from starting (lightdm, lxdm, lxde, leafpad)
the error is evident immediately in the pacman log - see: http://termbin.com/vezp
g_module_open() failed for /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so: /usr/lib/libpango-1.0.so.0: undefined symbol: g_memdup2
/usr/bin/gtk-query-immodules-3.0: symbol lookup error: /usr/lib/libpango-1.0.so.0: undefined symbol: g_memdup2
if you disable the DM service, you can get the same error by launching the DE directly
$ startlxde
/usr/bin/lxsession: symbol lookup error: /usr/lib/libpango-1.0.so.0: undefined symbol: g_memdup2
|
|
183 | Packages | Bug Report | Very Low | Low | [gedit] error loading shared library libtepl-5.so.0 | Closed | |
Task Description
$ gedit gedit: error while loading shared libraries: libtepl-5.so.0: cannot open shared object file: No such file or directory
Exist extra/tepl 6.00.0-1.0 in the pacman. I’m not sure if gedit is old or can only be used with an older version of tepl, which is not possible because i get tepl from 3 days.
|
|
191 | Packages | Bug Report | Very Low | Critical | mpv links against libsrt.so.1 which does not exist | Closed | |
Task Description
$ pacman -Qs mpv
local/mpv 1:0.33.1-1.0
a free, open source, and cross-platform media player
$ pacman -Qs srt
local/srt 1.4.3-1.0
Secure Reliable Transport library
$ pacman -Fl srt | grep libsrt
srt usr/lib/libsrt.so
srt usr/lib/libsrt.so.1.4
srt usr/lib/libsrt.so.1.4.3
$ mpv
mpv: error while loading shared libraries: libsrt.so.1: cannot open shared object file: No such file or directory
$ ldd /usr/bin/mpv | grep srt
libsrt.so.1 => not found
$ sudo ln -s /usr/lib/libsrt.so.1.4.3 /usr/lib/libsrt.so.1
$ mpv --version
mpv 0.33.1-dirty Copyright © 2000-2020 mpv/MPlayer/mplayer2 projects
built on UNKNOWN
FFmpeg library versions:
libavutil 56.51.100
libavcodec 58.91.100
libavformat 58.45.100
libswscale 5.7.100
libavfilter 7.85.100
libswresample 3.7.100
FFmpeg version: n4.3.2
$ ldd /usr/bin/mpv | grep srt
libsrt.so.1 => /usr/lib/libsrt.so.1 (0xb2a54000)
Running ldconfig does not create the missing symlink.
|
|
192 | Packages | Bug Report | Very Low | High | [postgis] not satisfiable dependency: "libproj.so.22" | Closed | |
Task Description
The postgis package version 3.1.1-1.0 on pentium4 does not work because only libproj-1.5.so is installed, and not the required libproj-2.2.so.
On upstream there seems to have been some rebuild of newer versions of gdal 3.2.2 and proj 8.0.0: https://archlinux.org/todo/gdal-322-and-proj-800-rebuild/
|
|
194 | Packages | Bug Report | Very Low | Low | go 1.16 doesn't build. | Closed | |
Task Description
The go build fails with this error:
unsupported setting GO386=387. Consider using GO386=softfloat instead.
go tool dist: FAILED: /build/go/src/go/pkg/tool/linux_386/compile -std -pack -o /tmp/go-tool-dist-250139381/runtime/internal/atomic/_go_.a -p runtime/internal/atomic -importcfg /tmp/go-tool-dist-250139381/runtime/internal/atomic/importcfg -asmhdr /tmp/go-tool-dist-250139381/runtime/internal/atomic/go_asm.h -symabis /tmp/go-tool-dist-250139381/runtime/internal/atomic/symabis /build/go/src/go/src/runtime/internal/atomic/atomic_386.go /build/go/src/go/src/runtime/internal/atomic/stubs.go /build/go/src/go/src/runtime/internal/atomic/unaligned.go: exit status 1 go tool dist: open /tmp/go-tool-dist-250139381/runtime/internal/atomic/_go_.a: no such file or directory go tool dist: open /tmp/go-tool-dist-250139381/runtime/internal/sys/_go_.a: no such file or directory go tool dist: open /tmp/go-tool-dist-250139381/internal/cpu/_go_.a: no such file or directory unsupported setting GO386=387. Consider using GO386=softfloat instead.
go tool dist: FAILED: /build/go/src/go/pkg/tool/linux_386/compile -std -pack -o /tmp/go-tool-dist-250139381/internal/cpu/_go_.a -p internal/cpu -importcfg /tmp/go-tool-dist-250139381/internal/cpu/importcfg -asmhdr /tmp/go-tool-dist-250139381/internal/cpu/go_asm.h -symabis /tmp/go-tool-dist-250139381/internal/cpu/symabis /build/go/src/go/src/internal/cpu/cpu.go /build/go/src/go/src/internal/cpu/cpu_386.go /build/go/src/go/src/internal/cpu/cpu_x86.go: exit status 1 unsupported setting GO386=387. Consider using GO386=softfloat instead.
go tool dist: FAILED: /build/go/src/go/pkg/tool/linux_386/compile -std -pack -o /tmp/go-tool-dist-250139381/runtime/internal/sys/_go_.a -p runtime/internal/sys -importcfg /tmp/go-tool-dist-250139381/runtime/internal/sys/importcfg -asmhdr /tmp/go-tool-dist-250139381/runtime/internal/sys/go_asm.h -symabis /tmp/go-tool-dist-250139381/runtime/internal/sys/symabis /build/go/src/go/src/runtime/internal/sys/arch.go /build/go/src/go/src/runtime/internal/sys/arch_386.go /build/go/src/go/src/runtime/internal/sys/intrinsics_common.go /build/go/src/go/src/runtime/internal/sys/intrinsics_stubs.go /build/go/src/go/src/runtime/internal/sys/stubs.go /build/go/src/go/src/runtime/internal/sys/sys.go /build/go/src/go/src/runtime/internal/sys/zgoarch_386.go /build/go/src/go/src/runtime/internal/sys/zgoos_linux.go /build/go/src/go/src/runtime/internal/sys/zversion.go: exit status 1 =⇒ ERROR: A failure occurred in build().
Aborting...
Upstream discussion about this bug: https://github.com/golang/go/issues/44500
Someone mentions a fix, but it doesn’t apply for non SSE2 devices.
|
|
198 | Packages | Bug Report | Very Low | Critical | [deleted due to spam] | Closed | |
Task Description
no task description |
|
199 | Packages | Bug Report | Very Low | Low | SPAM | Closed | |
Task Description
SPAM
|
|
200 | Packages | Bug Report | Very Low | Low | SPAM | Closed | |
Task Description
SPAM
|
|
201 | Packages | Bug Report | Very Low | Low | SPAM | Closed | |
Task Description
SPAM
|
|
202 | Packages | Bug Report | Very Low | Low | SPAM | Closed | |
Task Description
SPAM
|
|
203 | Packages | Bug Report | Very Low | Low | SPAM | Closed | |
Task Description
SPAM
|
|
205 | Packages | Bug Report | Very Low | Low | SPAM | Closed | |
Task Description
no task description |