A 19-year-old NEWS.Debian file has been added in this version:
/usr/share/doc/libx11-6/NEWS.Debian.gz
which contains
libx11 (2:1.1-1) experimental; urgency=low
[ Josh Triplett, Jamey Sharp ]
libx11 1.1 includes our work on Xlib/XCB, which uses XCB as the Xlib
transport layer, and allows a client to use both Xlib and XCB on the
same connection. This allows clients to transition from Xlib to XCB
incrementally. libx11-6 1.1 is API- and ABI-compatible with previous
versions, and does not require any software or package changes.
Ideally, you will not notice any
change at all. However, Xlib/XCB includes some additional
code to check for bugs in calling software. If you encounter a problem, you
will most likely just see an application disappear, due to having triggered
an assertion and aborted. If you ran the application from a terminal, you
can look there to see error output and get more details; otherwise, look at
~/.xsession-errors. These assertions look like one of these:
xcb_xlib.c:41: xcb_xlib_lock: Assertion `!c->xlib.lock' failed.
xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Both of these represent bugs in a caller of libX11, and *not* in
libX11 or libxcb. The first assertion means that a caller attempted
to lock the display while already locked. The second assertion means
that a caller attempted to unlock the display without having it
locked. If you encounter such bugs, please report a bug against the
offending software (*not* libx11-6 or libxcb), provide a backtrace,
and X-Debbugs-CC: xcb@lists.freedesktop.org if you need help tracking
down the problem. If the bug always consistently occurs when running
the application (or in the case of a library, invoking the library),
use severity "important", and raise to "grave" after the etch release.
Vincent Lefevre kirjoitti 24.2.2026 klo 13.21: What do you mean by "added"? It hasn't been touched since 2008. If you saw it only now, then it must be due to something else.
No, it has just been added into "/usr/share/doc/libx11-6". On a machine with libx11-6 2:1.8.12-1, I have: qaa% ls -l /usr/share/doc/libx11-6 total 284 -rw-r--r-- 1 root root 2104 2025-03-21 07:30:50 changelog.Debian.gz -rw-r--r-- 1 root root 235772 2025-03-09 00:53:24 changelog.gz -rw-r--r-- 1 root root 47102 2025-03-21 07:30:50 copyright On a machine with libx11-6 2:1.8.13-1, I have: disset% ls -l /usr/share/doc/libx11-6 total 292 -rw-r--r-- 1 root root 963 2026-02-24 08:22:14 NEWS.Debian.gz -rw-r--r-- 1 root root 2134 2026-02-24 08:22:14 changelog.Debian.gz -rw-r--r-- 1 root root 238637 2026-02-07 23:26:57 changelog.gz -rw-r--r-- 1 root root 47102 2026-02-24 08:22:14 copyright See the difference? No, it is this file: disset% gunzip -c /usr/share/doc/libx11-6/NEWS.Debian.gz libx11 (2:1.1-1) experimental; urgency=low [...] -- Josh Triplett <josh@freedesktop.org> Fri, 24 Nov 2006 17:36:55 -0800
Vincent Lefevre kirjoitti 24.2.2026 klo 19.53: still not due to something changing in the package, which you can see by doing a debdiff
The Debian changelog file says: libx11 (2:1.8.3-2) unstable; urgency=medium [...] * rules: NEWS got removed, don't try to install it. [...] -- Timo Aaltonen <tjaalton@debian.org> Tue, 20 Dec 2022 17:02:56 +0200 I suspect that it has been reinstalled by mistake in 2:1.8.13-1.
Timo Aaltonen kirjoitti 24.2.2026 klo 20.02: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1128414
Hi,
Should this bugreport be reassigned and merged into #1128414?
It was nice beeing reminded of for instance
tor (0.2.0.26-rc-1) experimental; urgency=critical
* weak cryptographic keys
It has been discovered that the random number generator in Debian's
openssl package is predictable. This is caused by an incorrect
Debian-specific change to the openssl package (CVE-2008-0166). As a
result, cryptographic key material may be guessable.
See Debian Security Advisory number 1571 (DSA-1571) for more information:
http://lists.debian.org/debian-security-announce/2008/msg00152.html
If you run a Tor server using this package please see
/var/lib/tor/keys/moved-away-by-tor-package/README.REALLY
Hi, Note that fixing #1128414 will not fix the binary package, which will have to be rebuilt. If there is no automatic rebuild of packages affected by #1128414, I would say that #1128905 should remain a separate bug and remain open until a new version of libx11 is released.