Package: mesa
Version: 21.2.1-2
Control: notfound -1 21.1.6-1
Control: found -1 21.2.0-1
The mesa DRI drivers (and possibly other binary packages I haven't
tested) appear to violate the i386 baseline by using SSE2
unconditionally, even if the host CPU doesn't support it (tested on a
Pentium III),
control: fixed -1 86.0.1-1
This bug has been fixed upstream, likely by
https://phabricator.services.mozilla.com/D100293, and the Firefox
version currently in sid works fine on that hardware. As I don't know
how to close bug reports, or if it's even possible at all, I'm leaving
that to you.
Package: firefox
Version: 83.0-1
Firefox crashes with SIGILL on CPUs that don't support SSE2, even
though Debian's baseline doesn't require it.
The crash manifests itself in qcms_transform_data_bgra_out_lut_sse2,
which uses SSE2 intrinsics, and so should never be reached on CPUs
that don't suppor
I can confirm that mesa 18.3.4-2 fixes the issue.
Michael Biebl wrote:
> For processes that are spawned by PID 1, the limits are set differently
> though, so the unlimited rlimit for PID 1 should have no effect on other
> processes.
>
> Problem is, pam_limits.so in Debian ships a custom patch, which reads
> the limits from PID 1 and set those for
Sorry, the first message accidentally got sent while I was still
writing it, intended full text below:
Installing systemd 240-1 breaks plasma-workspace: xinit
/usr/bin/startkde hangs with a black screen, with kdeinit5 stuck at
100% CPU usage. Attaching strace to kdeinit5 reveals that it's trying
t
Package: systemd
Version: 240-1
Severity: critical
Installing systemd 240-1 breaks plasma-workspace: xinit
/usr/bin/startkde hangs with a black screen, with kdeinit5 stuck at
100% CPU usage. Attaching strace to kdeinit5 reveals that it's trying
to close bogus file descriptors:
[..]
close(39936688
śr., 28 lis 2018 o 09:55 Sylvestre Ledru napisał(a):
> Excellent, many thanks.
>
> Could you please do a MR here
> https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/tree/7/ ?
Sure, done.
I've verified that adding the following to the llvm-toolchain-7's
debian/rules and rebuilding fixes the issue:
ifneq (,$(filter $(DEB_HOST_ARCH),i386))
# Clang default to baseline-violating -march setting on i386.
CFLAGS_EXTRA += -march=i686
CXXFLAGS_EXTRA += -march=i686
endif
On Wed, 4 Apr 2018 22:08:16 +0200 Sylvestre Ledru wrote:
> As this has been the case for a long time, it shows that it isn't a severe
> issue.
It's not a severe issue because it's easy to fix/work around: just
passing -march=i686 to Clang is enough. I was never hit by this
problem because I'm in
I fail to see how #914770 and #914838 are related in any way at all,
the former blockers of #894840 and #632472 are much more relevant in
my opinion, even if still not ideal.
Anyway, it's still a baseline violation that affects *binary packages
already in sid*, in my case breaking seemingly unrela
Source: llvm-toolchain-7
Version: 1:7.0.1~+rc2-7
Severity: grave
LLVM violates the i386 baseline by using SSE2, which on this Pentium
III machine results in a crash when starting xorg due to an illegal
instruction:
[ 112.413] (EE)
[ 112.413] (EE) Backtrace:
[ 112.414] (EE) 0: /usr/lib/xorg/
Just tested it on a ThinkPad T23 (which features a Pentium III), it's
definitely fixed. Thank you!
The bug has been fixed upstream in (not yet released) version 3.34,
feel free to close the report.
Oh, I forgot: obviously we're talking i386 here, which is nowadays
pretty much reduced to legacy machines like the ThinkPad in question.
Isn't almost everyone using amd64, which for obvious reasons would be
unaffected, anyway?
2017-10-01 23:10 GMT+02:00 Sylvestre Ledru :
> However, if I were, I would won't fix this bug. CPU without SSE2 are now
> rare
Well, my ThinkPad T23 still works and despite the claims of some
people, is still perfectly capable of browsing the web ;)
> and the performance drop for not using SSE2 b
Package: firefox
Version: 56.0-2
Severity: important
Visiting certain sites such as github crashes with SIGILL on Pentium
III and other CPUs with no SSE2 support due to some parts of Firefox
code assuming SSE2 unconditionally. While the upstream doesn't support
pre-SSE2 processors anymore, my unde
Package: libnss3
Version: 2:3.32-2
Severity: important
Even after the latest change, libnss3 on i386 still requires SSE2 to
run, because freebl's rijndael.c and gcm.c are still compiled with
-mclmul and -maes, which imply -msse2, and since these files contain
the software fallbacks, the generated
Source: nss
Version: 2:3.32-1
Severity: normal
Dear Maintainer,
libnss version 2:3.32-1 on i386 is built with SSE2 on, which prevents
it from running on pre-SSE2 systems. On my Pentium III system, this
results in Firefox crashing at startup inside libfreeblpriv3.so with
SIGLL on a movq from memor
Tags: patch
Patch that fixes the build (tested locally):
Description: add missing #include to fix ftbfs with GCC 7
Author: Fanael Linithien
---
--- a/kadu-core/plugin/dependency-graph/plugin-dependency-graph-builder.h
+++ b/kadu-core/plugin/dependency-graph/plugin-dependency-graph-builder.h
The problem is caused by missing #include in
kadu-core/plugin/dependency-graph/plugin-dependency-graph-builder.h.
2016-07-10 6:51 GMT+02:00 Sean Whitton :
> perhaps users would want it (for example,
> to test their own Emacs config).
But it's hardly useful for that. Most of the tests assume the default
settings and hardcode the expected faces. If the user changes, say,
rainbow-delimiters-pick-face-function, o
Package: elpa-rainbow-delimiters
Version: 2.1.3-1
Severity: minor
The test suite is installed, even though it's not needed. It doesn't really
affect much, if anything, it merely looks kinda untidy IMO, especially as the
test suite is kinda hard to use, see the incantations in .travis.yml. It also
23 matches
Mail list logo