|
72 | Packages: Stable | Bug Report | Medium | Low | [mpd] icu version mismatch | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by bill auger - 13.05.2019 Last edited by Andreas Baumann - 28.08.2019
FS#72 - [mpd] icu version mismatch
$ mpd mpd: error while loading shared libraries: libicui18n.so.63: cannot open shared object file: No such file or directory
Closed by Andreas Baumann 28.08.2019 16:59 Reason for closing: Fixed Additional comments about closing:
works for me after the rebuild.
Comments (2)
Related Tasks (0/0)
Levi commented on 13.05.2019 20:33
This also affects libreoffice from libreoffice-stable. Run it from a terminal and the splash screen briefly loads before closing, and it spits out to STDERR: [quote]usr/lib/libreoffice/program/soffice.bin: error while loading shared libraries: libicuuc.so.63: cannot open shared object file: No such file or directory[/quote]
My icu package is currently at version 64.2-1.0 and from the core repo (nothing in testing, apparently). I’m currently on the pentium4 binary branch, by the way, but I think this issue affects us all at present.
I suspect if the maintainer just rebuilds libreoffice-stable and mpd with icu 64.2 in the environment it may resolve this. Looking at the libreoffice web site, version 6.1.6 is already available for download, while I still have 6.1.5 installed and there’s nothing in the download tubes just yet. Although 6.1.5 is still available on libreoffices download page along with 6.1.6 and 6.2.3, so maybe we don’t get the upgrade till 6.1.5 expires, I’ve not checked before. I also can’t find when anything libreoffice produces got released; their release notes don’t express patch levels and they don’t expose their download folder for my perusal. I did manage to find their announcements for what becomes libreoffice-fresh on their twitter feed, but they only announce the fresh releases there. Presumably 6.1.6 got released following 6.2.3, since presumably it fixes the same bugs backported though. Admin Andreas Baumann commented on 28.08.2019 16:58
Should be solved with rebuilding libreoffice, mpd etc.
Google Cache
|
|
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
|
|
76 | Packages: Stable | Bug Report | Medium | Low | libreoffice-fresh needs to be rebuild against icu | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Raphael Scholer - 25.05.2019
FS#76 - libreoffice-fresh needs to be rebuild against icu
Comments (1)
Related Tasks (0/0)
Levi commented on 25.05.2019 18:22
This bug is already captured 90% by https://bugs.archlinux32.org/index.php?do=details&task_id=72 (see my comment underneath it), although to be fair I noted it against libreoffice-stable since that’s what I use.
Google Cache
|
|
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
|
|
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
|
|
81 | Packages: Stable | Bug Report | Medium | Low | KDE/Plasma crashes on startup (i686) | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Andreas Baumann - 07.07.2019
FS#81 - KDE/Plasma crashes on startup (i686)
Application: ksplashqml (ksplashqml), signal: Aborted Using host libthread_db library “/usr/lib/libthread_db.so.1”. [Current thread is 1 (Thread 0xb21d5900 (LWP 427))]
Thread 3 (Thread 0xaa75cb40 (LWP 429)): #0 0xb4b95418 in g_main_context_prepare () from /usr/lib/libglib-2.0.so.0 #1 0xb4b959f7 in ?? () from /usr/lib/libglib-2.0.so.0 #2 0xb4b95be6 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0xb6e75ce5 in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/libQt5Core.so.5 #4 0xb6e18ef5 in QEventLoop::exec(QFlags) () from /usr/lib/libQt5Core.so.5 #5 0xb6c5fe1a in QThread::exec() () from /usr/lib/libQt5Core.so.5 #6 0xb66317c3 in ?? () from /usr/lib/libQt5Qml.so.5 #7 0xb6c611cc in ?? () from /usr/lib/libQt5Core.so.5 #8 0xb5e34018 in start_thread () from /usr/lib/libpthread.so.0 #9 0xb697c25a in clone () from /usr/lib/libc.so.6
Thread 2 (Thread 0xb1a18b40 (LWP 428)): #0 0xb7f6a82d in kernel_vsyscall () #1 0xb6972873 in poll () from /usr/lib/libc.so.6 #2 0xb550c6ce in ?? () from /usr/lib/libxcb.so.1 #3 0xb550e864 in xcb_wait_for_event () from /usr/lib/libxcb.so.1 #4 0xb1bad3da in ?? () from /usr/lib/libQt5XcbQpa.so.5 #5 0xb6c611cc in ?? () from /usr/lib/libQt5Core.so.5 #6 0xb5e34018 in start_thread () from /usr/lib/libpthread.so.0 #7 0xb697c25a in clone () from /usr/lib/libc.so.6
Thread 1 (Thread 0xb21d5900 (LWP 427)): [KCrash Handler] #6 0xb7f6a82d in kernel_vsyscall () #7 0xb68c4376 in raise () from /usr/lib/libc.so.6 #8 0xb68ae299 in abort () from /usr/lib/libc.so.6 #9 0xb6c1f873 in QMessageLogger::fatal(char const*, …) const () from /usr/lib/libQt5Core.so.5 #10 0xb6387c44 in QV4::Compiler::Codegen::visit(QQmlJS::AST::UiProgram*) () from /usr/lib/libQt5Qml.so.5 #11 0xb64298d6 in QJSEngine::QJSEngine(QJSEnginePrivate&, QObject*) () from /usr/lib/libQt5Qml.so.5 #12 0xb6575fcd in QQmlEngine::QQmlEngine(QObject*) () from /usr/lib/libQt5Qml.so.5 #13 0xb6888bc4 in KDeclarative::QmlObjectSharedEngine::QmlObjectSharedEngine(QObject*) () from /usr/lib/libKF5Declarative.so.5 #14 0xb7f0fb00 in KQuickAddons::QuickViewSharedEngine::QuickViewSharedEngine(QWindow*) () from /usr/lib/libKF5QuickAddons.so.5 #15 0x0040a29b in ?? () #16 0x00408e7a in ?? () #17 0x004095a2 in ?? () #18 0x004081de in ?? () #19 0xb68af7b9 in __libc_start_main () from /usr/lib/libc.so.6 #20 0x004082e5 in _start () [Inferior 1 (process 427) detached]
Google Cache
|
|
83 | Packages: Stable | Bug Report | Medium | Low | kdeinit5 is filling the systemd journal with nonsensica ... | Closed | |
Task Description
Attached to Project: Archlinux32 Opened by Andreas Baumann - 13.07.2019
FS#83 - kdeinit5 is filling the systemd journal with nonsensical messages
Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”)) Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: () Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”)) Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”)) Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: () Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”)) Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”)) Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: () Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”)) Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”)) Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: () Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”)) Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: (QUrl(”tags:/”)) Jul 13 20:12:45 arch32-stable-pentium4 kdeinit5[1037]: ()
225 root 20 0 359832 225172 224128 S 24.5 29.5 0:45.52 systemd-journal
Upstream too? Or is it fast enough if one core is dedicated to output nonsensical output.. :->
Google Cache
|
|
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
|
|
93 | Packages: Stable | Bug Report | Very Low | Medium | pyparsing error is preventing applications from startin ... | Closed | |
Task Description
Came across this after completing a system update two days ago.
I run Radicale and that is refusing to start with the following error:
Traceback (most recent call last):
File "/usr/bin/radicale", line 6, in <module>
from pkg_resources import load_entry_point
File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 84, in <module>
__import__('packaging.requirements')
File "/usr/lib/python3.7/site-packages/packaging/requirements.py", line 9, in <module>
from pyparsing import stringStart, stringEnd, originalTextFor, ParseException
ModuleNotFoundError: No module named 'pyparsing'
When attempting to run pip to see if that might correct the issue, I got the following error:
Traceback (most recent call last):
File "/usr/bin/pip", line 6, in <module>
from pkg_resources import load_entry_point
File "/usr/lib/python3.7/site-packages/pkg_resources/__init__.py", line 84, in <module>
__import__('packaging.requirements')
File "/usr/lib/python3.7/site-packages/packaging/requirements.py", line 9, in <module>
from pyparsing import stringStart, stringEnd, originalTextFor, ParseException
ModuleNotFoundError: No module named 'pyparsing'
It looks as though something recently broke pyparsing and that’s had a knockon effect for a few packages.
|
|
95 | Packages: Stable | Bug Report | Very Low | High | KDE broken since KDE Frameworks 5.64 update | Closed | |
Task Description
KDE applications fail to start with the following error:
symbol lookup error: /usr/lib/libKF5QuickAddons.so.5: undefined symbol: _ZNK19KCoreConfigSkeleton10isDefaultsEv
The affected applications I’ve found so far are: dolphin 19.08.3-1.0 kwin 5.17.3-1.0 plasma-workspace 5.17.0-2.0
After downgrading kdeclarative to 5.63.0-1.0 kwin and plasma start but dolphin fails with a new error:
dolphin: symbol lookup error: /usr/lib/libKF5KCMUtils.so.5: undefined symbol: _ZNK12KQuickAddons12ConfigModule11errorStringEv
Downgrading kcmutils to 5.63.0-1.0 finally fixed dolphin.
|
|
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.
|
|
97 | Packages: Stable | Bug Report | Very Low | Low | mesa-vdpau /usr/lib/dri/r300_dri.so links to wrong libL ... | Closed | |
Task Description
grep LLVM /var/log/Xorg.0.log
[ 29.423] (EE) AIGLX error: dlopen of /usr/lib/dri/r300_dri.so failed (libLLVM-8.so: cannot open shared object file: No such file or directory)
[ 29.424] (EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed (libLLVM-8.so: cannot open shared object file: No such file or directory)
ldd /usr/lib/dri/r300_dri.so
linux-gate.so.1 (0xb7f26000)
libdrm.so.2 => /usr/lib/libdrm.so.2 (0xb6836000)
libLLVM-8.so => not found
libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb680a000)
libdl.so.2 => /usr/lib/libdl.so.2 (0xb6804000)
libsensors.so.5 => /usr/lib/libsensors.so.5 (0xb67f3000)
libdrm_radeon.so.1 => /usr/lib/libdrm_radeon.so.1 (0xb67e4000)
libelf.so.1 => /usr/lib/libelf.so.1 (0xb67c6000)
libdrm_amdgpu.so.1 => /usr/lib/libdrm_amdgpu.so.1 (0xb67b9000)
libdrm_nouveau.so.2 => /usr/lib/libdrm_nouveau.so.2 (0xb67ae000)
libglapi.so.0 => /usr/lib/libglapi.so.0 (0xb678d000)
libz.so.1 => /usr/lib/libz.so.1 (0xb6773000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb6595000)
libm.so.6 => /usr/lib/libm.so.6 (0xb64c3000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb64a6000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0xb6483000)
libc.so.6 => /usr/lib/libc.so.6 (0xb62d3000)
/usr/lib/ld-linux.so.2 (0xb7f27000)
ls /usr/lib/libLLVM*
/usr/lib/libLLVM-9.0.0.so /usr/lib/libLLVM-9.so /usr/lib/libLLVM.so
|
|
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”
|
|
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
|
|
114 | Packages: Stable | Bug Report | Very Low | Medium | Kmail: symbol lookup error | Closed | |
Task Description
Kmail 20.08.1-1.0 fails to start with symbol lookup error.
Steps to reproduce: invoking kmail on the console shows:
kmail: symbol lookup error: /usr/lib/libKF5MailImporter.so.5: undefined symbol: _ZN9PimCommon15CustomLogWidgetC1EP7QWidget
Downgrading messagelib fixes this issue but generates other issues (missing files or other undefined symbols).
After all I didn’t find a solution.
|
|
167 | Packages: Stable | Bug Report | Very Low | Medium | Kernel lost crypto support necessary for iwd | Closed | |
Task Description
With linux 5.11.1.arch1-1.0, iwd no longer works for associating with WPA2 access points. On attempting to start the service, the journal reads:
iwd: RC4 support not found
iwd: The following options are missing in the kernel:
iwd: CONFIG_CRYPTO_USER_API_SKCIPHER
iwd: CONFIG_CRYPTO_ECB
iwd: CONFIG_CRYPTO_ARC4
It would be nice to have these options enabled in the kernel config, so as to continue support for the iwd package.
|
|
179 | Packages: Stable | Bug Report | Very Low | Medium | Snapper needs rebuild from icu upgrade | Closed | |
Task Description
icu69.1-1.0 however snapper still links against libicuuc.so.68
Running snapper now gives the following error:
# snapper list /
snapper: error while loading shared libraries: libicuuc.so.68: cannot open shared object file: No such file or directory
|
|
180 | Packages: Stable | Bug Report | Very Low | Low | Pandoc requires specific-version haskell dependencies | Closed | |
Task Description
# pandoc --version
pandoc: error while loading shared libraries: libHSzip-archive-0.4.1-4yLWnBS0zifKkvfHVbmUo1-ghc8.10.2.so: cannot open shared object file: No such file or directory
<code>
Versions:
<code>
# pacman -Q | grep haskell
haskell-aeson 1.5.4.1-19.0
haskell-aeson-pretty 0.8.8-94.0
haskell-ansi-terminal 0.11-17.0
haskell-asn1-encoding 0.9.6-58.0
haskell-asn1-parse 0.9.5-58.0
haskell-asn1-types 0.3.4-37.0
haskell-assoc 1.0.2-27.0
haskell-async 2.2.2-40.0
haskell-attoparsec 0.13.2.4-36.0
haskell-base-compat 0.11.2-4.2
haskell-base-compat-batteries 0.11.2-11.0
haskell-base-orphans 0.8.3-14.0
haskell-base16-bytestring 0.1.1.7-3.0
haskell-base64-bytestring 1.2.0.1-3.0
haskell-basement 0.0.11-10.1
haskell-bifunctors 5.5.8-13.0
haskell-blaze-builder 0.4.2.1-2.1
haskell-blaze-html 0.9.1.2-57.0
haskell-blaze-markup 0.8.2.7-41.0
haskell-byteable 0.1.1-22.1
haskell-case-insensitive 1.2.1.0-39.0
haskell-cereal 0.5.8.1-9.0
haskell-citeproc 0.3.0.9-9.0
haskell-cmdargs 0.10.21-1.0
haskell-colour 2.3.5-75.0
haskell-commonmark 0.1.1.2-2.0
haskell-commonmark-extensions 0.2.0.3-1.0
haskell-commonmark-pandoc 0.2.0.1-24.0
haskell-comonad 5.0.6-58.0
haskell-conduit 1.3.4-3.0
haskell-conduit-extra 1.3.5-70.0
haskell-connection 0.3.1-99.0
haskell-cookie 0.4.5-9.1
haskell-cryptonite 0.27-32.0
haskell-data-default 0.7.1.1-87.0
haskell-data-default-class 0.1.2.0-21.1
haskell-data-default-instances-containers 0.0.1-33.1
haskell-data-default-instances-dlist 0.0.1-100.0
haskell-data-default-instances-old-locale 0.0.1-33.1
haskell-data-fix 0.3.0-35.0
haskell-digest 0.0.1.2-22.1
haskell-distributive 0.6.2-40.0
haskell-dlist 1.0-23.0
haskell-doclayout 0.3-45.0
haskell-doctemplates 0.9-40.0
haskell-emojis 0.1-47.0
haskell-erf 2.0.0.0-21.0
haskell-errors 2.3.0-59.1
haskell-file-embed 0.0.13.0-3.1
haskell-glob 0.10.1-28.0
haskell-haddock-library 1.9.0-58.0
haskell-hashable 1.3.0.0-36.0
haskell-hourglass 0.2.12-82.0
haskell-hslua 1.3.0-2.0
haskell-hslua-module-system 0.2.2.1-17.0
haskell-hslua-module-text 0.3.0.1-5.0
haskell-hsyaml 0.2.1.0-52.0
haskell-http 4000.3.15-49.0
haskell-http-client 0.7.6-14.0
haskell-http-client-tls 0.3.5.3-359.0
haskell-http-types 0.12.3-100.0
haskell-hxt 9.3.1.18-196.0
haskell-hxt-charproperties 9.5.0.0-1.0
haskell-hxt-regex-xmlschema 9.2.0.7-2.0
haskell-hxt-unicode 9.0.2.4-22.0
haskell-indexed-traversable 0.1.1-3.1
haskell-integer-logarithms 1.0.3.1-3.1
haskell-ipynb 0.1.0.1-192.0
haskell-jira-wiki-markup 1.3.2-27.0
haskell-juicypixels 3.3.5-37.0
haskell-memory 0.15.0-49.0
haskell-mime-types 0.1.0.9-11.1
haskell-mono-traversable 1.0.15.1-74.0
haskell-network 3.1.2.1-1.0
haskell-network-uri 2.6.3.0-217.0
haskell-old-locale 1.0.0.7-27.1
haskell-old-time 1.1.0.3-27.1
haskell-pandoc-types 1.22-13.0
haskell-pem 0.2.4-114.0
haskell-primitive 0.7.1.0-29.0
haskell-quickcheck 2.14.2-11.0
haskell-random 1.2.0-54.0
haskell-resourcet 1.2.4.2-31.0
haskell-safe 0.3.19-5.1
haskell-scientific 0.3.6.2-53.0
haskell-sha 1.6.4.4-16.1
haskell-skylighting 0.10.2-24.0
haskell-skylighting-core 0.10.2-24.0
haskell-socks 0.6.1-90.0
haskell-split 0.2.3.4-88.0
haskell-splitmix 0.1.0.3-5.0
haskell-streaming-commons 0.2.2.1-28.1
haskell-strict 0.4.0.1-1.0
haskell-syb 0.7.1-8.0
haskell-tagged 0.8.6.1-2.2
haskell-tagsoup 0.14.8-75.0
haskell-temporary 1.3-130.0
haskell-texmath 0.12.0.3-40.0
haskell-text-conversions 0.3.1-62.0
haskell-text-icu 0.7.0.1-37.1
haskell-th-abstraction 0.4.2.0-2.2
haskell-th-compat 0.1-12.0
haskell-these 1.1.1.1-28.0
haskell-time-compat 1.9.5-1.0
haskell-tls 1.5.5-3.0
haskell-transformers-compat 0.6.6-3.1
haskell-typed-process 0.2.6.0-63.0
haskell-unicode-transforms 0.3.7.1-42.0
haskell-uniplate 1.6.13-4.0
haskell-unliftio-core 0.2.0.1-6.1
haskell-unordered-containers 0.2.13.0-11.0
haskell-utf8-string 1.0.1.1-20.0
haskell-uuid-types 1.0.3-58.0
haskell-vector 0.12.1.2-64.0
haskell-vector-algorithms 0.8.0.4-1.0
haskell-x509 1.7.5-137.0
haskell-x509-store 1.6.7-136.0
haskell-x509-system 1.6.6-204.0
haskell-x509-validation 1.6.11-136.0
haskell-xml 1.3.14-27.2
haskell-xml-conduit 1.9.0.0-77.0
haskell-xml-types 0.3.8-5.1
haskell-zip-archive 0.4.1-66.0
haskell-zlib 0.6.2.2-4.0
|
|
182 | Packages: Stable | Bug Report | Very Low | Low | [blender] cannot resolve dependency to opensubdiv | Closed | |
Task Description
# pacman -S blender
resolving dependencies… warning: cannot resolve "opensubdiv”, a dependency of "blender” :: The following package cannot be upgraded due to unresolvable dependencies:
blender
:: Do you want to skip the above package for this upgrade? [y/N] error: failed to prepare transaction (could not satisfy dependencies) :: unable to satisfy dependency 'opensubdiv’ required by blender
|
|
184 | Packages: Stable | Bug Report | Very Low | Low | [ffmpeg] error loading share library libaom.so.2 | Closed | |
Task Description
$ ffmpeg -v ffmpeg: error while loading shared libraries: libaom.so.2: cannot open shared object file: No such file or directory
From pacman: extra/aom 3.0.0-2.1 [installed]
|
|
190 | Packages: Stable | Bug Report | Very Low | Critical | mpv-1:0.33.1-2.0-pentium4 aborts immediately | Closed | |
Task Description
Here’s 1:0.33.1-1.0-pentium4:
$ pacman -Qs mpv
local/mpv 1:0.33.1-1.0
a free, open source, and cross-platform media player
$ 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
Here’s 1:0.33.1-2.0-pentium4:
$ pacman -Qs mpv
local/mpv 1:0.33.1-2.0
a free, open source, and cross-platform media player
$ mpv --msg-level=all=trace --version
libavutil: 56.70.100 -> 56.51.100
Aborted (core dumped)
Looks to me like it might be a library version thing (I’m up-to-date according to
pacman -Syu
), but I’ve only been running Arch32 for 24 hours so I’m not sure where further to dig.
|
|
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?
|
|
251 | Packages: Stable | Bug Report | Very Low | Low | [pavucontrol] libcanberra/libcanberra-pulse dependency ... | Closed | |
Task Description
There is currently a problem preventing the installation of pavucontrol on i686:
resolving dependencies...
warning: cannot resolve "libcanberra=0.30+2+gc0620e4-3.2", a dependency of "libcanberra-pulse"
warning: cannot resolve "libcanberra-pulse", a dependency of "pavucontrol"
:: The following package cannot be upgraded due to unresolvable dependencies:
pavucontrol
error: failed to prepare transaction (could not satisfy dependencies)
:: unable to satisfy dependency 'libcanberra=0.30+2+gc0620e4-3.2' required by libcanberra-pulse
:: unable to satisfy dependency 'libcanberra-pulse' required by pavucontrol
|
|
273 | Packages: Stable | Bug Report | Very Low | Medium | Quazip Qt5 package contains Qt6 libraries | Closed | |
Task Description
The quazip-qt5 package for both i686 and pentium4 contains the Qt6 libraries instead of the Qt5 ones.
The quazip package also no longer seems to exist upstream and should probably be removed in Arch32 as well.
|
|
279 | Packages: Stable | Bug Report | Very Low | Medium | Telegram Desktop doesn't start | Closed | |
Task Description
Telegram Desktop fails to start with an error about incompatible Qt libraries, I think it needs to be rebuilt.
|
|
305 | Packages: Stable | Bug Report | Very Low | Medium | [chezmoi] i686 and i486 packages are way out of date, p ... | Closed | |
Task Description
I did not see a way to report a package outdated (unlike upstream arch linux) so here is a bug report.
chezmoi (a dot file manager for your home directory) is way outdated in arch32, especially the non-pentium4 versions. This makes it unusable for me as my config depends on newer features.
I would at least expect arch32 to have the same version for i686 and pentium4.
|
|
315 | Packages: Stable | Bug Report | Very Low | Low | [ncmpcpp] requires wrongly boost libraries | Closed | |
Task Description
ncmpcpp-git compiles on AUR with no problem with all dependencies found on AL32 repositories.
|
|
63 | Packages: Stable | Bug Report | Medium | Low | nodejs crashes in libuv when cleaning up FSReqCallback | New | |
Task Description
Attached to Project: Archlinux32 Opened by Andreas Baumann - 07.02.2019 FS#63 - nodejs crashes in libuv when cleaning up FSReqCallback
Program terminated with signal SIGSEGV, Segmentation fault. #0 0×00945919 in node::fs::FSReqCallback::~FSReqCallback() () [Current thread is 1 (Thread 0xb5614880 (LWP 2013))] (gdb) bt #0 0×00945919 in node::fs::FSReqCallback::~FSReqCallback() () #1 0×00937274 in node::fs::FSReqAfterScope::~FSReqAfterScope() () #2 0x0093767d in node::fs::AfterInteger(uv_fs_s*) () #3 0xb7e910e0 in uv.work_done () from /usr/lib/libuv.so.1 #4 0xb7e9526e in ?? () from /usr/lib/libuv.so.1 #5 0xb7ea51f8 in uv.io_poll () from /usr/lib/libuv.so.1 #6 0xb7e95c51 in uv_run () from /usr/lib/libuv.so.1 #7 0x00905d37 in node::Start(v8::Isolate*, node::IsolateData*, std::vector, std::allocator >, std::allocator, std::allocator > > > const&, std::vector, std::allocator >, std::allocator, std::allocator > > > const&) () #8 0×00903655 in node::Start(int, char**) () #9 0x008acef1 in main ()
This affects gyp, vault and probably some other packages, depending whether those callbacks are used or not.
Comments (1)
Related Tasks (0/0)
Admin Andreas Baumann commented on 07.02.2019 09:36
See also mailing list thread:
https://lists.archlinux.org/pipermail/arch-ports/2018-November/000835.html
Google Code
|
|
82 | Packages: Stable | Bug Report | Medium | Low | [glibc] ld warning: /usr/lib32/ld-linux.so.2: corrupt G... | New | |
Task Description
Attached to Project: Archlinux32 Opened by Jeff Hodd - 11.07.2019 Last edited by Andreas Baumann - 09.08.2019 FS#82 - [glibc] ld warning: /usr/lib32/ld-linux.so.2: corrupt GNU_PROPERTY_TYPE (5) size: 0
All software builds are producing this warning. Some builds are failing because of the error return on linking. I’m also seeing failures on LD_PRELOADs.
/bin/ld: warning: /usr/lib/ld-linux.so.2: corrupt GNU_PROPERTY_TYPE (5) size: 0
Easy to reproduce. Just build this program:
# test.c # Compiled with ‘gcc test.c’ int main() {
return 0;
}
This was reported at bugs.archlinux.org (reference https://bugs.archlinux.org/task/63015) where it was closed and considered fixed if built using the –enable-cet flag. I built glibc with the –enable-cet flag, but am still seeing the failures, so not fixed. Closed by Andreas Baumann 09.08.2019 11:44 Reason for closing: Fixed
Comments (6)
Related Tasks (0/0)
Jeff Hodd commented on 16.07.2019 03:29
I’ve narrowed down the glibc upgrade to glibc-2.29-1.26 -> glibc-2.29-1.27. The error doesn’t occur with glibc-2.29-1.26. There were 3 changes made to the arch32 PKGBUILD for the glibc-2.29-1.27 release. One of them caused this issue. Admin Andreas Baumann commented on 16.07.2019 05:33
There is another thing which can change: the toolchain. This GNU_PROPERTY error is something the compiler emits (we think it’s CET stuff, but it’s badly documented). Binutils ld seems not to like this ELF section.
The error is the same as in:
https://bugs.archlinux.org/task/63015
What’s puzzling me: –enable-cet is there in glibc, gcc, binutils (just not for i486, as CET doesn’t\ work for older CPUs).
Commit: 09d03cbd4c57b8eabfadd22b67929d958b2409d7 and d57a456faa674c24e8869a26a14c497c95accf1f in glibc are mine, they try to change stack alignment and handling of SSE for pentium4 for Java, also without effect. Admin Andreas Baumann commented on 16.07.2019 05:35
About linker warnings being turned to errors (as for compiler warnings turned to errors): this is something the DEVELOPER should do, NOT the PACKAGER. Released software should: - NOT include asserts - NOT include debug code - NOT include code only used for running tests - NOT use -Werror - NOT use -Wl,–fatal-warnings
See for instance extra-cmake-modules-5.59.0-ld-no-fatal-warning.patch. Jeff Hodd commented on 16.07.2019 21:50
I knew about the cet issue. Did quite abit of looking around to get some insight into it (even looked at the code - elf-properties.c - and it looks like the Elf_Internal_Note description size is coming back with a value of 0. the other possibility is that (size % 4) is something other than 0 which is less likely). From what i could gather, cet is supposed to be enabled in the latest builds of glibc for i686 even though, as you pointed out, it’s not well documented. I did do a 2.29-4 i686 build with cet enabled and it made no difference vis-a-vis the warning. I also checked the upstream diff between 2.29-1.26 and 2.29-1.27 and noticed the addition of –enable-static-pie and thought maybe position independent executables may explain it. Did another glibc build with static pie disabled and that made no difference. Am about to go back and check the diff again and see what else may have changed.
I did check the CMakeLists.txt file for my failing build and it uses -Werror and -Wl,–fatal-warnings so I will remove those. But that doesn;t actually fix the underlying issue of the warning which we shouldn;t be seeing.
It is up to the developer, but too often one has to show that a change fixes an issue before you’ll get any attention. I may not be THE developer for this particular package, but I am A developer (in general), so I don;t feel uncomfortable making code changes.
I’ll keep looking around for differences between the 1.26 and 1.27 builds. Jeff Hodd commented on 16.07.2019 22:15
if (note->descsz < 8 || (note->descsz % align_size) != 0)
{
bad_size:
_bfd_error_handler
(_("warning: %pB: corrupt GNU_PROPERTY_TYPE (%ld) size: %#lx"),
abfd, note->type, note->descsz);
return FALSE;
}
The warning is printing out the description size - and that’s 0.
Apparently it’s supposed to be >= 8 and divisible by 4:
unsigned int align_size = bed->s->elfclass == ELFCLASS64 ? 8 : 4;
I am assuming that arch32 doesn’t support ELFCLASS64. Jeff Hodd commented on 22.07.2019 17:13
https://bbs.archlinux32.org/viewtopic.php?id=2770
Google Cache
|
|
100 | Packages: Stable | Bug Report | Very Low | Low | mldonkey crashes | Unconfirmed | |
Task Description
All versions of mldonkey crash in arch32 updated. (segmentation fault and core dumped)
|
|
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
|
|
322 | Packages: Stable | Bug Report | Very Low | Medium | file header absent | New | |
Task Description
on fresh install file /usr/lib/libbfd.so lacks header “/* GNU ld script */” so I see complains on terminal
|
|
351 | Packages: Stable | Bug Report | Very Low | Medium | Various python-X packages building for Python 3.10 and ... | New | |
Task Description
yes, confirmed, that’s because python 3.11 is the only package building and being published to stable, the python modules need bootstrapping (since months).
|
|
108 | Packages: Staging | Bug Report | Very Low | High | lldb fails to run any binary (error: failed to launch o... | Unconfirmed | |
Task Description
Very easy to reproduce. lldb version 10.0.0, just try to run any binary.
[aeden@arch32 bin]$ lldb $(which date) (lldb) target create “/usr/bin/date” Current executable set to ‘/usr/bin/date’ (i386). (lldb) run error: failed to launch or debug process (lldb)
|
|
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
|
|
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?
|
|
195 | Packages: Testing | Bug Report | Very Low | Low | libreoffice-fresh and libreoffice-still will not start | Closed | |
Task Description
There is a problem with libreoffice-fresh and libreoffice-still which appears to be caused by the last update to boost and boost-libs which are now at version 1.76.0-1.3
~]$ libreoffice
javaldx: Could not find a Java Runtime Environment!
Warning: failed to read path from javaldx
/usr/lib/libreoffice/program/soffice.bin: error while loading shared libraries: libboost_locale.so.1.75.0: cannot open shared object file: No such file or directory
|
|
221 | Packages: Testing | Bug Report | Very Low | Critical | [exim] / is stuck in testing since a month | Closed | |
Task Description
Hi!
I just mentioned that exim stopped sending me emails… So I just upgraded to the package in community-testing… And now exim sends me emails, that complain about things like this: “warning: exim: local (4.95-2.0) is newer than community (4.95-1.0)”
Is there a reason, that the fresh package is being tested since a month now?
Thx.
Bye.
|
|
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
|
|
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
|