Bug#1082745: aptitude: information mismatch for package removal

[Vincent Lefevre]

Control: retitle -1 aptitude: removes a kernel package not requested to be 
removed
Control: severity -1 grave

Wow! This is much worse than expected! When I typed 'g' to remove the
3 packages, aptitude also removed the linux-image-6.10.7-amd64 kernel
package, which was *not* in the list of packages to be removed.

Performing actions...
(Reading database ... 752963 files and directories currently installed.)
Removing linux-headers-6.10.7-amd64 (6.10.7-1) ...
Removing linux-headers-6.10.7-common (6.10.7-1) ...
Removing linux-image-6.10.7-amd64 (6.10.7-1) ...
/etc/kernel/prerm.d/dkms:
dkms: removing: nvidia-legacy-390xx 390.157 (6.10.7-amd64) (x86_64)
Module nvidia-legacy-390xx-390.157 for kernel 6.10.7-amd64 (x86_64).
Before uninstall, this module version was ACTIVE on this kernel.

nvidia-legacy-390xx.ko.xz:
 - Uninstallation
   - Deleting from: /lib/modules/6.10.7-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.

nvidia-legacy-390xx-modeset.ko.xz:
 - Uninstallation
   - Deleting from: /lib/modules/6.10.7-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.

nvidia-legacy-390xx-drm.ko.xz:
 - Uninstallation
   - Deleting from: /lib/modules/6.10.7-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.

nvidia-legacy-390xx-uvm.ko.xz:
 - Uninstallation
   - Deleting from: /lib/modules/6.10.7-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.
do_depmod 6.10.7-amd64

/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-6.10.7-amd64
/etc/kernel/postrm.d/zz-update-grub:
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-6.10.11-amd64
Found initrd image: /boot/initrd.img-6.10.11-amd64
Found linux image: /boot/vmlinuz-6.10.9-amd64
Found initrd image: /boot/initrd.img-6.10.9-amd64
Found linux image: /boot/vmlinuz-6.1.0-25-amd64
Found initrd image: /boot/initrd.img-6.1.0-25-amd64
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done
Removing linux-kbuild-6.10.7 (6.10.7-1) ...

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1082745: aptitude: information mismatch for package removal

[Vincent Lefevre]

Package: aptitude
Version: 0.8.13-6.1
Severity: normal

4005 kB + 61.4 MB + 2264 kB does not give 172 MB.

 Actions  Undo  Package  Resolver  Search  Options  Views  Help
C-T: Menu  ?: Help  q: Quit  u: Update  g: Preview/Download/Install/Remove Pkgs
PackagesPreview
aptitude 0.8.13 @ cventinDisk: -172 MB
--\ Packages being removed because they are no longer used (3)  
ipA linux-headers-6. -4005 kB  6.10.7-1   
ipA linux-headers-6. -61.4 MB  6.10.7-1   
ipA linux-kbuild-6.1 -2264 kB  6.10.7-1   
--- Packages being held back (12)
--- Packages being automatically held in their current state (29)

IIRC, the "Disk" value changed when I hit "_" over the
"Packages being removed because they are no longer used"
section.

-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 14.2.0
Compiled against:
  apt version 6.0.0
  NCurses version 6.5
  libsigc++ version: 2.12.1
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.5.20240427
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-vdso.so.1 (0x7f205b411000)
libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 
(0x7f205b3df000)
libapt-pkg.so.6.0 => /lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7f205aa0)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7f205b3a5000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7f205b37)
libsigc-2.0.so.0 => /lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f205b367000)
libcwidget.so.4 => /lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7f205acfe000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f205a88)
libboost_iostreams.so.1.83.0 => 
/lib/x86_64-linux-gnu/libboost_iostreams.so.1.83.0 (0x7f205b34c000)
libxapian.so.30 => /lib/x86_64-linux-gnu/libxapian.so.30 
(0x7f205a60)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f205a20)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f205a51a000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f205b31d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f205a00a000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f205b2fe000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f205b2eb000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f205b2bb000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x7f205b297000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7f2059f42000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f205acb9000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7f2059e59000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7f2059cbc000)
libxxhash.so.0 => /lib/x86_64-linux-gnu/libxxhash.so.0 
(0x7f205b282000)
/lib64/ld-linux-x86-64.so.2 (0x7f205b413000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f205acaf000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x7f205aca3000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7f205ac79000)

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.10.9-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.13-6.1
ii  libapt-pkg6.0t64  2.9.8
ii  libboost-iostreams1.83.0  1.83.0-3.2
ii  libc6 2.40-3
ii  libcwidget4   0.5.18-6+b1
ii  libgcc-s1 14.2.0-5
ii  libncursesw6  6.5-2
ii  libsigc++-2.0-0v5 2.12.1-2
ii  libsqlite3-0  3.46.1-1
ii  libstdc++614.2.0-5
ii  libtinfo6 6.5-2
ii  libxapian30   1.4.25-1

Versions of packages aptitude recommends:
ii  libdpkg-perl1.22.11
ii  sensible-utils  0.0.24

Versions of packages aptitude suggests:
pn  apt-xapian-index
ii  aptitude-doc-en [aptitude-doc]  0.8.13-6.1
pn  debtags   

Bug#1078402: gimp: FTBFS: dh_install: error: missing files, aborting

[Vincent Lefevre]

Any news?

gimp has just been removed from testing because of this bug.
Nothing has been done upstream for a backport for autoconf.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#948892: Please document that apt does not keep files in /var/cache/apt/archives

[Vincent Lefevre]

On 2024-09-23 17:52:33 +, Helge Kreutzmann wrote:
> Hello David,
> Am Thu, Sep 19, 2024 at 09:55:28PM +0200 schrieb David Kalnischkies:
> > So, if you are interested in the config differences:
> > | apt-config dump Binary::apt
> 
> This is a very helpful hint, and I would strongly support having these
> two lines in apt(8).

I agree. Moreover, this is a bit surprising, because there is no such
thing for apt-get: "apt-config dump Binary::apt-get" returns nothing.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1080330: coreutils: who no longer works

[Vincent Lefevre]

Control: retitle -1 coreutils: "who" should support wtmpdb (y2038)
Control: severity -1 wishlist
Control: tags -1 upstream

[Cc Luca Boccassi  so that he gets aware of this
issue. In short, "who" from coreutils still relies on utmp.]

On 2024-09-20 11:39:55 -0300, Adilson dos Santos Dantas wrote:
> I think that this bug should be closed since they re-enable utmp
> support in systemd.

Thanks for the information. I hadn't noticed this new systemd version
as I had put the old working version on hold, and aptitude doesn't
have a feature to signal new versions (and I was also busy at other
things).

I confirm that systemd 256.6-1 fixes the issue for "who". Rather than
closing the bug, I've turned it into a wishlist, as in a longer term,
I suppose that the change should be done.

> systemd (256.6-1) unstable; urgency=medium
[...]
>   [ Luca Boccassi ]
>   * Re-enable utmp support, tmux's autopkgtests require it. This will
> break as logind writing into utmp will wrap around, so Trixie won't be
> y2038 ready after all

BTW, disabling utmp is the kind of thing that should be announced
in NEWS.Debian.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1076308: wtmpdb: wtmp.db created with wrong mode with system-wide umask 077

[Vincent Lefevre]

On 2024-07-14 13:22:08 +0200, Chris Hofstaedtler wrote:
> On Sat, Jul 13, 2024 at 11:33:01PM -0400, ov2k wrote:
> > wtmpdb respects the system-wide umask when creating
> > /var/lib/wtmpdb/wtmp.db.  This is inappropriate when the system-wide
> > umask is 077 or something similarly restrictive, as wtmp.db can no
> > longer be read by others
> 
> That however might be the intention of a local configuration. IOW
> admins might want to set it up so that login records are not leaked
> to non-root.

I agree. I've checked the status of a multi-user bookworm machine
at my lab, and it has:

-rw-rw 1 root utmp 384384 2024-09-19 09:52:09 /var/log/wtmp

So an admin may want the same thing for wtmp.db.

Isn't there an API to read information from this file, with specific
handling of permissions, e.g. so that a user can get his own
information?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1064982: gnuplot-qt: gnuplot displays a window with nothing in it

[Vincent Lefevre]

Control: found -1 1.54.0+ds-2

And this still occurs with the latest libpango-1.0-0 version
when testing with

  echo 'set terminal wxt; plot x' | gnuplot -persist

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1064982: gnuplot-qt: gnuplot displays a window with nothing in it

[Vincent Lefevre]

Control: reassign -1 libpango-1.0-0 1.52.0+ds-1
Control: retitle -1 libpango-1.0-0: hangs in pango_fc_patterns_get_font_pattern 
(echo 'set terminal wxt; plot x' | gnuplot -persist)
Control: forwarded -1 https://gitlab.gnome.org/GNOME/pango/-/issues/784
Control: affects -1 gnuplot-qt gnuplot-x11

On 2024-02-29 16:10:06 +0100, Vincent Lefevre wrote:
> I've identified the "problematic" commit in Pango, and I would tend
> to say that this is the reason:
> 
> https://gitlab.gnome.org/GNOME/pango/-/commit/89442dae443eba2aa0f0a526b4d6d39c0c9b13c6
> 
> According to the commit message, a new thread was created "for every
> single fontconfig call". Now "a single fontconfig thread per fontmap"
> is used. So I suppose that this makes Pango faster, triggering the
> race condition in gnuplot.

(now a single thread using a queue instead of a thread per request)

> I've updated the upstream gnuplot bug and opened a bug in Pango,
> hoping confirmation:
> 
> https://gitlab.gnome.org/GNOME/pango/-/issues/784

The backtrace I posted in the gnuplot and pango bugs shows that
the hang occurs in pango_fc_patterns_get_font_pattern, i.e. in
pango, in the source file changed by the above commit. So it is
probably a bug in this new pango code, which is visible only
under some conditions.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1014124: nomacs: CVE-2020-23884

[Vincent Lefevre]

Control: tags -1 - fixed-upstream
Control: reassign -1 qt5-image-formats-plugins
Control: retitle -1 buffer overflow in the mng plugin for Qt (CVE-2020-23884)

The upstream fix in Nomacs was for MS Windows only:

"I removed the qmng.dll plugin from Windows version. MNG files will
not work by default in nomacs on Windows."

because the MS Windows version of Nomacs was providing this pluging.
And this is not a Nomacs bug for Debian (see below).

On 2023-06-06 22:27:01 +0930, and...@lists.savchenko.net wrote:
> I think this should be filled against
> https://tracker.debian.org/pkg/qtimageformats-opensource-src
> 
> Explanation:
> https://github.com/nomacs/nomacs/issues/516#issuecomment-1578313635

If I understand correctly, the buffer overflow was in the qmng.dll
plugin for Windows (which Nomacs for MS Windows was including). And
the explanation says "the problem affects other Qt-based viewers too"
if Debian's libqmng.so is buggy too. This plugin comes from the
qt5-image-formats-plugins package, so I'm reassigning the bug,
assuming that the bug was in common Qt code for both Windows and
Linux.

If the bug was in Windows-only code, it can be closed.

BTW, I don't understand

  https://github.com/nomacs/nomacs/issues/516#issuecomment-667859911

which says "Qt does not support it anymore" about mng. The given
link is

  https://doc.qt.io/qt-5/qtimageformats-index.html

where I can see:

  MNG / Multiple-image Network Graphics / Read / Yes (Not bundled)

So it is claimed to be supported (for reading), as long as
a 3rd party codec is provided, which is the case in Debian:

cventin:~> ldd /usr/lib/x86_64-linux-gnu/qt5/plugins/imageformats/libqmng.so
[...]
libmng.so.1 => /lib/x86_64-linux-gnu/libmng.so.1 (0x7fc3c360)
[...]

provided by the libmng1 package.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1081219: manpages: libc(7) bad display with "info glibc"

[Vincent Lefevre]

Package: manpages
Version: 6.8-2
Severity: normal

When I type "info glibc", this gives the libc(7), and I get

[...]
   glibc
   By far the most widely used C library on Linux is the ^[]8;;http://www.g\
nu.org/software/libc/^[\GNU C Library^[]8;;^[\, of‐
[...]
   Other C libraries
   There  are  various other less widely used C libraries for Linux.  These
   libraries are generally smaller than glibc, both in  terms  of  features
   and  memory  footprint,  and often intended for building small binaries,
   perhaps targeted at development for embedded Linux systems.  Among  such
   libraries  are  ^[]8;;http://www.uclibc.org/^[\uClibc^[]8;;^[\,  ^[]8;;h\
ttp://www.fefe.de/dietlibc/^[\dietlibc^[]8;;^[\,  and ^[]8;;http://www.musl-lib\
c.org/^[\musl libc^[]8;;^[\.  Details of these li‐
   braries are covered by the man-pages project, where they are known.
[...]

which is incorrect.

Note that "info sin" also falls back to a man page, sin(3), and there
are no such issues with it, despite the https URL at the end.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.10.7-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

manpages depends on no packages.

manpages recommends no packages.

Versions of packages manpages suggests:
ii  man-db [man-browser]  2.13.0-1

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1078127: libc6: mcheck(NULL) fails even at the beginning of a program

[Vincent Lefevre]

Control: tags -1 upstream
Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=32156

On 2024-09-09 11:42:43 +0200, Bernhard Übelacker wrote:
[...]
> In Bookworm and Trixie [3] the function mcheck always returns -1,
> because "IS_IN (libc)" seems to be true at compile time.
> 
> Reading the upstream commit comment [4] it looks like mcheck should
> just work when using libc_malloc_debug.so.
> 
> And indeed following also prints 0 in Trixie:
>   LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libc_malloc_debug.so.0 ./mcheck-test
[...]

Thanks. I've just reported the bug upstream.

In short:

Returning -1 is incorrect as it can introduce an error, while
not preloading libc_malloc_debug is not an error (this just
means that one does not wish to check memory). Returning 0
would be OK, since when one does not check memory, mcheck()
is never called too late (as its call should not have any
consequence).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1080978: libreoffice: steals the PRIMARY selection

[Vincent Lefevre]

Control: found -1 4:24.2.5-4

BTW, testing is affected (and maybe earlier versions too: I do not
use LibreOffice often).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1080972: guile-3.0: triggers lots of warnings in gnucash

[Vincent Lefevre]

[Cc'ing the gnucash maintainer. As a summary, the downgrade of the
guile-3.0 packages to upstream's 3.0.9 with 3.0.10+really3.0.9-1
prevents gnucash from using the compiled files, with consequences:
lots of warnings and slowness.]

On 2024-09-08 16:26:57 -0500, Rob Browning wrote:
> Vincent Lefevre  writes:
> 
> > The current gnucash version is
> >
> > gnucash (1:5.8-1) unstable; urgency=medium
> >
> >   * New upstream release.
> > + fixed FTBFS in "gtest-gnc-int128.cpp" (Closes: #1077415).
> >
> >  -- Dmitry Smirnov   Thu, 01 Aug 2024 19:40:30 +1000
> >
> > so guile-3.0 3.0.10 was in unstable at that time.
> 
> Ahh, OK, then I suspect this may be a gnucash package issue, i.e. needs
> a rebuild/upload after the downgrade (if it's including compiled files).

I can see in libguile/loader.c:

uint16_t major = dyn[i].d_un.d_val >> 16;
uint16_t minor = dyn[i].d_un.d_val & 0x;
switch (major)
  {
  case 0x0300:
bytecode_kind = BYTECODE_KIND_GUILE_3_0;
if (minor < SCM_OBJCODE_MINIMUM_MINOR_VERSION)
  return "incompatible bytecode version";
if (minor > SCM_OBJCODE_MINOR_VERSION)
  return "incompatible bytecode version";
break;
  default:
return "incompatible bytecode kind";
  }
break;

I suppose that the compatiblity of gnucash with the major version is
ensured by the dependency on guile-3.0-libs.

There can still be issues if
  * gnucash is upgraded by the user while guile-3.0-libs has not been
upgraded yet (e.g. due to a major bug or a dependency that blocks
the guile-3.0-libs upgrade);
  * if SCM_OBJCODE_MINIMUM_MINOR_VERSION is increased, and gnucash
is not upgraded at the same time as guile-3.0-libs.

So, to ensure that everything is fine in the future, shouldn't
gnucash depend on the exact guile-3.0-libs version against which
it has been built?

Alternatively, if SCM_OBJCODE_MINOR_VERSION doesn't change often,
shouldn't guile-3.0-libs provide virtual packages that correspond
to the supported bytecode versions (so that packages that distribute
compiled files could depend on the one that corresponds to the
build)? Thus this dependency would ensure that the above conditions
on minor are satisfied, without being too strict.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1080972: guile-3.0: triggers lots of warnings in gnucash

[Vincent Lefevre]

On 2024-09-08 13:05:09 +0200, Vincent Lefevre wrote:
> On 2024-09-07 17:43:07 -0500, Rob Browning wrote:
> > Was just wondering if that was causing unexpected errors and
> > auto-re-compilation, and if gnucash was built against that version
> > (don't know how it handles its .go files), then that might also be
> > related.
> 
> The current gnucash version is
> 
> gnucash (1:5.8-1) unstable; urgency=medium
> 
>   * New upstream release.
> + fixed FTBFS in "gtest-gnc-int128.cpp" (Closes: #1077415).
> 
>  -- Dmitry Smirnov   Thu, 01 Aug 2024 19:40:30 +1000
> 
> so guile-3.0 3.0.10 was in unstable at that time.

Note that gnucash has un unversioned dependency on guile packages:

  guile-3.0 | guile-2.2 | guile-2.0

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1080972: guile-3.0: triggers lots of warnings in gnucash

[Vincent Lefevre]

On 2024-09-07 17:43:07 -0500, Rob Browning wrote:
> Vincent Lefevre  writes:
> 
> > And in particular, it makes the loading very slow.
> 
> Did you ever install the (unstable only) 3.0.10 package?  Unfortunately
> we had to downgrade it because it isn't compatible with 32-bit
> architectures.  (Presumably that'll be fixed in 11).

Yes, it was installed in June. This version had been in unstable
for about 2 months.

> Was just wondering if that was causing unexpected errors and
> auto-re-compilation, and if gnucash was built against that version
> (don't know how it handles its .go files), then that might also be
> related.

The current gnucash version is

gnucash (1:5.8-1) unstable; urgency=medium

  * New upstream release.
+ fixed FTBFS in "gtest-gnc-int128.cpp" (Closes: #1077415).

 -- Dmitry Smirnov   Thu, 01 Aug 2024 19:40:30 +1000

so guile-3.0 3.0.10 was in unstable at that time.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1081071: gtk3-nocsd: Vcs information is obsolete: move to salsa

[Vincent Lefevre]

Source: gtk3-nocsd
Version: 3-1
Severity: normal

In the debian/control file:

Vcs-Git: https://anonscm.debian.org/git/collab-maint/gtk3-nocsd.git -b 
debian/master
Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/gtk3-nocsd.git

With the move to salsa, I think that this should now be:

Vcs-Git: https://salsa.debian.org/debian/gtk3-nocsd.git -b debian/master
Vcs-Browser: https://salsa.debian.org/debian/gtk3-nocsd

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#825989: gtk3-nocsd: unclear comment in /etc/X11/Xsession.d/01gtk3-nocsd

[Vincent Lefevre]

On 2024-09-08 00:19:36 +0200, Vincent Lefevre wrote:
> Hmm... This bug has been marked a pending since 2016!
> 
> And the commit is no longer available, as the Git repository
> no longer exists! At the PTS page
> 
>   https://tracker.debian.org/pkg/gtk3-nocsd
> 
> the Git link https://anonscm.debian.org/git/collab-maint/gtk3-nocsd.git
> gives "Not Found".

I've eventually found that it has moved to

https://salsa.debian.org/debian/gtk3-nocsd/-/commit/80fa53e7b8212f4a9459a6f90c5960577af9ff57

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#825989: gtk3-nocsd: unclear comment in /etc/X11/Xsession.d/01gtk3-nocsd

[Vincent Lefevre]

On 2024-09-07 22:03:10 +0200, Enrique Garcia wrote:
> I saw this but in the "Bug of the Day" page and since I am using it I just
> wanted to check. As the last comment mentions, the comment in
> /etc/X11/Xsession.d/01gtk3-nocsd seems fine now (confirmed in the last version
> of gtk3-nocsd in Debian testing).

Hmm... This bug has been marked a pending since 2016!

And the commit is no longer available, as the Git repository
no longer exists! At the PTS page

  https://tracker.debian.org/pkg/gtk3-nocsd

the Git link https://anonscm.debian.org/git/collab-maint/gtk3-nocsd.git
gives "Not Found".

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1080978: libreoffice: steals the PRIMARY selection

[Vincent Lefevre]

Control: forwarded -1 https://bugs.documentfoundation.org/show_bug.cgi?id=162821

I've just reported the bug upstream.

On 2024-09-06 11:17:43 +0200, Vincent Lefevre wrote:
> To reproduce:
> 
> 1. Open a .odt file with LibreOffice.

Actually, other LibreOffice applications list Calc and Draw are also
affected, not just Writer.

> 2. Type Ctrl-F to start a search.
> 3. Type some text to search (a single character is sufficient).
> 4. Select some text in another application, e.g. xterm.
> 5. Move the cursor over the LibreOffice window so that this window
>gets the focus.
> 
> Result: The text in the LibreOffice search field automatically gets
> selected and becomes the new PRIMARY selection.

This can be seen by pasting the PRIMARY selection (i.e. with the
middle button) somewhere else.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1080978: libreoffice: steals the PRIMARY selection

[Vincent Lefevre]

Package: libreoffice
Version: 4:24.2.6-1
Severity: important
Tags: security

LibreOffice steals the PRIMARY selection when a search is active,
just when the mouse happens to move over the LibreOffice window.
The PRIMARY selection should be changed only when the user selects
something, not by just moving the mouse!

There are possible security implications: if the search text contains
private data, and the PRIMARY selection is pasted in a web browser,
such private data may be sent to some remote site. Note that the user
does not necessarily know that the PRIMARY selection has been stolen.
So what he pastes may not be what he thinks.

To reproduce:

1. Open a .odt file with LibreOffice.
2. Type Ctrl-F to start a search.
3. Type some text to search (a single character is sufficient).
4. Select some text in another application, e.g. xterm.
5. Move the cursor over the LibreOffice window so that this window
   gets the focus.

Result: The text in the LibreOffice search field automatically gets
selected and becomes the new PRIMARY selection.

Note that with xterm, xterm unhighlight its selected text when the
PRIMARY selection has changed, so it's easier to see the issue.

-- Package-specific info:
All deployed bundled extensions:

Identifier: com.sun.wiki-publisher
  Version: 1.2.0
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher
  is registered: yes
  Media-Type: application/vnd.sun.star.package-bundle
  Description: The Wiki Publisher enables you to create Wiki articles on 
MediaWiki servers without having to know the syntax of the MediaWiki markup 
language. Publish your new and existing documents transparently with the Writer 
to a wiki page.

  bundled Packages: {
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/help
  is registered: yes
  Media-Type: application/vnd.sun.star.help
  Description: 

  URL: 
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/WikiExtension.xcs
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-schema
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/WikiEditor/
  is registered: yes
  Media-Type: application/vnd.sun.star.basic-library
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/components.rdb
  is registered: yes
  Media-Type: application/vnd.sun.star.uno-components
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/Addons.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: 
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/ProtocolHandler.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: 
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/WikiExtension.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: 
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/OptionsDialog.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/Filter.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/Types.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/Paths.xcu
  is registered: yes
  Media-Type: application/vnd.sun.star.configuration-data
  Description: 

  }

Identifier: com.sun.star.comp.Calc.NLPSolver
  Version: 0.9
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/nlpsolver
  is registered: yes
  Media-Type: application/vnd.sun.star.package-bundle
  Description: This extension integrates into Calc and offers new Solver 
engines to use for optimizing nonlinear programming models.

  bundled Packages: {
  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/nlpsolver/help
  is registered: yes
  Media-Type: application/vnd.sun.star.help
  Description: 

  URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/nlpsolver/components.rdb
  is registered: yes
  Media-Type: application/vnd.sun.star.uno-components
  Description: 

  }

All deployed shared extensions:


All deployed user extensions:



Experimental features enabled:

Installed VCLplugs:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++----===
ii  libreoffice-gtk3 4:24.2.6-1   amd64office productivity suite -- 
GTK+ 3 integration
un

Bug#1080972: guile-3.0: triggers lots of warnings in gnucash

[Vincent Lefevre]

On 2024-09-06 08:08:43 +0200, Vincent Lefevre wrote:
> Package: guile-3.0
> Version: 3.0.10+really3.0.9-1
> Severity: important
> 
> This latest version triggers lots of warnings in gnucash:
> 
> ;;; WARNING: loading compiled file 
> /usr/lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/utilities.go failed:
> ;;; In procedure load-thunk-from-memory: incompatible bytecode version
> ;;; WARNING: loading compiled file 
> /usr/lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/utilities.go failed:
> ;;; In procedure load-thunk-from-memory: incompatible bytecode version
> ;;; WARNING: loading compiled file 
> /usr/lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/core-utils.go failed:
> [...]

And in particular, it makes the loading very slow.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1080972: guile-3.0: triggers lots of warnings in gnucash

[Vincent Lefevre]

Package: guile-3.0
Version: 3.0.10+really3.0.9-1
Severity: important

This latest version triggers lots of warnings in gnucash:

;;; WARNING: loading compiled file 
/usr/lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/utilities.go failed:
;;; In procedure load-thunk-from-memory: incompatible bytecode version
;;; WARNING: loading compiled file 
/usr/lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/utilities.go failed:
;;; In procedure load-thunk-from-memory: incompatible bytecode version
;;; WARNING: loading compiled file 
/usr/lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnucash/core-utils.go failed:
[...]

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages guile-3.0 depends on:
ii  guile-3.0-libs  3.0.10+really3.0.9-1

guile-3.0 recommends no packages.

Versions of packages guile-3.0 suggests:
pn  guile-3.0-doc  

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1080492: firmware-nonfree: [i915] With 20240709-2, the external monitors randomly blank for 2-3 seconds (regression)

[Vincent Lefevre]

Source: firmware-nonfree
Version: 20240709-2
Severity: important

First, some context: I have a Dell laptop with 2 external monitors
connected via a dock. With 6.8+ Linux kernels, one of the external
monitors randomly blanks for 2-3 seconds (no such issue with earlier
kernels); not always the same monitor, but in most cases, not both
at the same time. I had reported the following bugs about this issue:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072063
  https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11821

This blanking issue can occur several times per day.

After the upgrade of the binary packages of firmware-nonfree source
to 20240709-2, a new issue appeared: *both* external monitors randomly
blank for 2-3 seconds. Worse:
  * With a (non-Debian) 6.11.0-rc2+ test kernel (which I used in the
context of the other bug), this issue occurs very often: up to
several times per minute!
  * With the linux-image-6.7.12-amd64 Debian kernel, this issue also
occurs (but not often), while this kernel does not have the bug
mentioned above.

Downgrading to 20240709-1 made the issue disappear, at least with
the linux-image-6.7.12-amd64 Debian kernel (I have not tried the
6.11.0-rc2+ test kernel yet, but note that I was already using it
with 20240709-1 before September 2).

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1067679: libvte-2.91-0: backspace character (code 8) output at the end of a line goes 2 columns backward

[Vincent Lefevre]

Control: retitle -1 libvte-2.91-0: backspace character (code 8) output at the 
end of a line goes 2 columns backward (no reverse-wraparound)
Control: close -1

On 2024-09-04 08:00:31 -0400, Jeremy Bícha wrote:
> I don't think there is anything we are going to change directly in the
> vte packaging for this. I suggest closing this bug and working on
> upstream's bug tracker if you have any remaining or related followup
> issues?
> 
> https://gitlab.gnome.org/GNOME/vte/-/issues

OK, as libvte matches the xterm default behavior.

Actually, the fact is that in the libvte-based terminals, there isn't
reverse-wraparound at all: if one types "cat" (without arguments) then
a line longer than the terminal width, then the Backspace key several
times, the cursor remains at the beginning of the new line instead of
going backward to the previous line. In xterm, the reverseWrap setting
(which is not the default) solves this issue.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1080330: coreutils: who no longer works

[Vincent Lefevre]

On 2024-09-04 11:15:26 +0200, Chris Hofstaedtler wrote:
> On Mon, Sep 02, 2024 at 11:15:19AM -0400, Michael Stone wrote:
> > On Mon, Sep 02, 2024 at 01:07:59PM +0200, Vincent Lefevre wrote:
> > > Severity: grave
> > > Justification: renders package unusable
> > 
> > That's a ridiculous severity/rationale

I completely disagree. "who" is a standard POSIX utility:

https://pubs.opengroup.org/onlinepubs/9799919799/utilities/who.html

So, in addition to prevent the use in an interactive shell (without
any workaround), you are also likely to break existing scripts.
This is a major regression for users of this utility; the current
workaround is to stick to systemd 256.5-1.

> Ack.
> 
> I'll also note that for *currently* logged in sessions, wtmpdb is
> not useful. logind knows

So you mean that the following changelog is incorrect?

systemd (256.5-2) unstable; urgency=medium
[...]
  [ Luca Boccassi ]
  * Disable utmp support, replaced by wtmpdb. utmp is not y2038-safe, util-
linux has now turned it off and relies on logind, so disable utmp
support in logind too, as it is no longer necessary. wtmpdb replaces
the functionality.

> (and I think w(1) asks logind).

Note that w is currently buggy in Debian/unstable (even with
systemd 256.5-1), while it seems fine in bookworm. But no related
changes are mentioned in the changelog. So it might also be another
regression introduced by an earlier systemd version.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1080413: fail2ban: very old FSF address in debian/fail2ban.default

[Vincent Lefevre]

Package: fail2ban
Version: 1.1.0-7
Severity: minor

The debian/fail2ban.default file (installed as /etc/default/fail2ban)
contains a very old FSF address (it has changed twice):

# You should have received a copy of the GNU General Public License
# along with Fail2Ban; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

It is now suggested to use the web page:

  if not, see .

Also, please check whether other parts of this file are up-to-date.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fail2ban depends on:
ii  python3  3.12.5-1
ii  python3-systemd  235-1+b4

Versions of packages fail2ban recommends:
ii  iptables1.8.10-4
ii  nftables1.1.0-2
ii  python3-pyinotify   0.9.6-4
ii  python3-setuptools  73.0.1-1
ii  whois   5.5.23

Versions of packages fail2ban suggests:
ii  mailutils [mailx]  1:3.17-2+b1
pn  monit  
ii  sqlite33.46.1-1
pn  system-log-daemon  

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1080336: reportbug: incorrect "Configuration Files" for procps

[Vincent Lefevre]

Package: reportbug
Version: 13.0.1
Severity: minor

When I want to report a bug for procps, I get in the generated e-mail
template:

[...]
-- Configuration Files:
/etc/sysctl.conf [Errno 2] No such file or directory: '/etc/sysctl.conf'
[...]

But /etc/sysctl.conf is no longer a configuration file:

procps (2:4.0.4-5) unstable; urgency=medium
[...]
  * Remove /etc/sysctl.conf as using /etc/sysctl.d/*.conf is better

-- Package-specific info:
** Environment settings:
EDITOR="/home/vlefevre/bin/eclient"
PAGER="less -Lis"
VISUAL="/home/vlefevre/bin/eclient"
EMAIL="vinc...@vinc17.net"
INTERFACE="text"

** /home/vlefevre/.reportbugrc:
reportbug_version "2.10"
mode advanced
ui text
realname "Vincent Lefevre"
email "vinc...@vinc17.net"
mua mutt
cc
timeout 20

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.10.6-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages reportbug depends on:
ii  apt2.9.8
ii  python33.12.5-1
ii  python3-reportbug  13.0.1
ii  sensible-utils 0.0.24

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
ii  debconf1.5.87
pn  debsums
ii  dlocate1.14
hi  emacs-bin-common   1:27.1+1-3.1+b1
ii  exim4  4.98-1
ii  exim4-daemon-light [mail-transport-agent]  4.98-1
ii  file   1:5.45-3
ii  gnupg  2.2.43-8
pn  python3-urwid  
pn  reportbug-gtk  
ii  xdg-utils  1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.9.8
ii  file   1:5.45-3
ii  python33.12.5-1
ii  python3-apt2.9.0+b1
ii  python3-debian 0.1.49
ii  python3-debianbts  4.1.1
ii  python3-requests   2.32.3+dfsg-1
ii  sensible-utils 0.0.24

python3-reportbug suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1080335: w: missing tty information

[Vincent Lefevre]

Package: procps
Version: 2:4.0.4-5
Severity: normal

cventin:~> w
 13:48:17 up 2 days, 23:50,  4 users,  load average: 0.16, 0.15, 0.10
USER TTY  FROM LOGIN@   IDLE   JCPU   PCPU WHAT
vlefevre  -Fri13   22:45m  0.00s  0.25s /usr/lib/system
vlefevre  140.77.51.8  11:20   22:45m  0.00s  0.03s sshd-session: v
vlefevre  -12:48   22:45m  0.00s  0.03s lightdm --sessi

TTY information is missing.

The w(1) man page says:

  The  following  entries  are displayed for each user: login name, the
  tty name, the remote host, login time, idle time, JCPU, PCPU, and the
  
  command line of their current process.

Note: this issues occurs before and after the upgrade to
systemd 256.5-2.

No such issue on Debian 12.7 (bookworm), which has procps 2:4.0.2-3.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.10.6-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages procps depends on:
ii  init-system-helpers  1.66
ii  libc62.40-2
ii  libncursesw6 6.5-2
ii  libproc2-0   2:4.0.4-5
ii  libsystemd0  256.5-1
ii  libtinfo66.5-2

Versions of packages procps recommends:
ii  linux-sysctl-defaults  4.10.1
ii  psmisc 23.7-1

procps suggests no packages.

-- Configuration Files:
/etc/sysctl.conf [Errno 2] No such file or directory: '/etc/sysctl.conf'

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1080333: procps: w(1) man page: obsolete contents about /var/run/utmp

[Vincent Lefevre]

Package: procps
Version: 2:4.0.4-5
Severity: normal

The w(1) man page contains:

   /var/run/utmp
  information about who is currently logged on

and in SEE ALSO: "utmp(5)".

As of systemd 256.5-2, utmp support is disabled (/var/run/utmp
no longer exists), while w is still working. So it seems that
/var/run/utmp is no longer used.

According to strace, wtmpdb isn't used either. So, how is the
information obtained?

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.11.0-rc2+ (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages procps depends on:
ii  init-system-helpers  1.66
ii  libc62.40-2
ii  libncursesw6 6.5-2
ii  libproc2-0   2:4.0.4-5
ii  libsystemd0  256.5-2
ii  libtinfo66.5-2

Versions of packages procps recommends:
ii  linux-sysctl-defaults  4.10.1
ii  psmisc 23.7-1

procps suggests no packages.

-- Configuration Files:
/etc/sysctl.conf [Errno 2] No such file or directory: '/etc/sysctl.conf'

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1080330: coreutils: who no longer works

[Vincent Lefevre]

BTW, note that the "w" utility from procps still works, but according
to strace, it doesn't seem to use wtmpdb. However, though the w(1) and
who(1) man pages are similar ("show who is logged on"), w misses some
information.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1080330: coreutils: who no longer works

[Vincent Lefevre]

Control: retitle -1 coreutils: "who" no longer works with systemd 256.5-2 (utmp 
is now disabled, use wtmpdb instead)

(title with more details)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1080332: chkrootkit: chkutmp failure - obsolete as utmp is now disabled

[Vincent Lefevre]

Package: chkrootkit
Version: 0.58b-1+b4
Severity: normal

With systemd 256.5-2, I now get:


Checking `chkutmp'...   WARNING

WARNING: chkutmp output: 
failed opening utmp !


This test should be removed (or there should be an automatic
detection) as utmp is now disabled:

systemd (256.5-2) unstable; urgency=medium
[...]
  [ Luca Boccassi ]
  * Disable utmp support, replaced by wtmpdb. utmp is not y2038-safe, util-
linux has now turned it off and relies on logind, so disable utmp
support in logind too, as it is no longer necessary. wtmpdb replaces
the functionality.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.11.0-rc2+ (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chkrootkit depends on:
ii  libc6  2.40-2

Versions of packages chkrootkit recommends:
ii  anacron 2.3-40
ii  binutils2.43.1-3
ii  cron [cron-daemon]  3.0pl1-189
ii  iproute26.10.0-2
ii  mailutils [mailx]   1:3.17-2+b1
ii  net-tools   2.10-1.1
ii  postfix [mail-transport-agent]  3.9.0-3
ii  procps  2:4.0.4-5
ii  systemd-sysv256.5-2

chkrootkit suggests no packages.

-- Configuration Files:
/etc/chkrootkit/chkrootkit.conf changed:
RUN_DAILY="true"
RUN_DAILY_OPTS="-s '^[[:alnum:]]+: PACKET 
SNIFFER\(((/usr/lib/systemd/systemd-networkd|/usr/sbin/(dhclient|dhcpc?d[0-9]*|wpa_supplicant|NetworkManager))\[[0-9]+\](,
 )?)+\)$'"
DIFF_MODE="true"
FILTER="sed -re 's/(! [[:alnum:]+-]+)\s+[0-9]+/\1 {PID}/'"
IGNORE_FILE="/etc/chkrootkit/chkrootkit.ignore"
MAILTO="root"


-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1080331: manpages: utmp(5): should warn that utmp is now obsolete

[Vincent Lefevre]

Package: manpages
Version: 6.8-2
Severity: normal

The utmp file is now obsolete. There should be a warning about that
in the utmp(5) man page.

FYI:

systemd (256.5-2) unstable; urgency=medium
[...]
  [ Luca Boccassi ]
  * Disable utmp support, replaced by wtmpdb. utmp is not y2038-safe, util-
linux has now turned it off and relies on logind, so disable utmp
support in logind too, as it is no longer necessary. wtmpdb replaces
the functionality.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.11.0-rc2+ (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

manpages depends on no packages.

manpages recommends no packages.

Versions of packages manpages suggests:
ii  man-db [man-browser]  2.13.0-1

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1080330: coreutils: who no longer works

[Vincent Lefevre]

Package: coreutils
Version: 9.4-3.1
Severity: grave
Justification: renders package unusable

Though the whole package is not unusable, an important utility is
now unusable because coreutils still hasn't switched to wtmpdb.
This must be fixed before the next Debian release.

With systemd 256.5-2, "who" returns nothing because /var/run/utmp
no longer exists. I should use wtmpdb instead.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.10.6-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages coreutils depends on:
ii  libacl1  2.3.2-2
ii  libattr1 1:2.5.2-1
ii  libc62.40-2
ii  libgmp10 2:6.3.0+dfsg-2+b1
ii  libselinux1  3.7-3
ii  libssl3t64   3.3.1-7

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1079922: texlive-base: pathname missing in tl-paper output for context

[Vincent Lefevre]

Package: texlive-base
Version: 2024.20240706-1
Severity: normal

disset:~> tl-paper
Current context paper size (from ): A4
Current dvipdfmx paper size (from /var/lib/texmf/dvipdfmx/dvipdfmx-paper.cfg): 
a4
Current dvips paper size (from /var/lib/texmf/dvips/config/config-paper.ps): a4
Current pdftex paper size (from 
/var/lib/texmf/tex/generic/tex-ini-files/pdftexconfig.tex): a4
Current xdvi paper size (from /var/lib/texmf/xdvi/XDvi-paper): a4

The pathname for context is missing.

-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 2992 2024-08-28 12:24:51 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 2022-10-12 23:25:33 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 2024-07-11 23:31:48 
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 2024-07-11 23:31:48 
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 2024-01-06 02:46:17 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 2024-07-11 23:31:48 
/usr/share/texmf/web2c/fmtutil.cnf -> /var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 2024-07-11 23:31:48 /usr/share/texmf/web2c/updmap.cfg 
-> /var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5334 2024-07-28 04:48:55 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 2019-04-01 18:36:11 mktex.cnf
-rw-r--r-- 1 root root 475 2024-01-06 02:46:17 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.10.6-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.87
ii  libpaper-utils 1.1.29+b1
ii  sensible-utils 0.0.24
ii  tex-common 6.18
ii  texlive-binaries   2024.20240313.70630+ds-4
ii  ucf3.0043+nmu1
ii  xdg-utils  1.1.3-4.1

Versions of packages texlive-base recommends:
ii  lmodern  2.005-1

Versions of packages texlive-base suggests:
ii  ghostscript [postscript-viewer]   10.03.1~dfsg-2
pn  perl-tk   
ii  xpdf [pdf-viewer] 3.04+git20240613-1+b1
pn  xzdec 
ii  zathura-pdf-poppler [pdf-viewer]  0.3.3-1

Versions of packages tex-common depends on:
ii  ucf  3.0043+nmu1

Versions of packages tex-common suggests:
ii  debhelper  13.20

Versions of packages texlive-base is related to:
ii  tex-common6.18
ii  texlive-binaries  2024.20240313.70630+ds-4

-- debconf information:
  texlive-base/binary_chooser: pdftex, dvips, dvipdfmx, x

Bug#1079786: texlive-latex-base: buggy testpage.tex: missing \usepackage{geometry}

[Vincent Lefevre]

On 2024-08-27 22:44:13 +0900, Norbert Preining wrote:
> What youare asking is a fix to testpage.tex, to use geometry or some
> other ways to set the *physical* page size. But that is as said not the
> basic assumption. You can use testpage, and then print it on the correct
> page size.

The goal of testpage.tex is to match the output to the physical
page size, and the default paper size must *not* be used since the
file explicitly asks for a paper size. Hence the need for a fix.

> > According to the TeX Live mailing-list, this is a Debian-specific
> > issue.
> 
> paperconf is Debian specific, so the default physical page size setup is
> Debian specific (TeX defaults to letter).

Note that paperconf is designed to allow a user-level default.
However, TeX uses a system-level default only. For instance, with

  PAPERSIZE=a5 pdflatex 
/usr/share/texlive/texmf-dist/tex/latex/base/testpage.tex

the generated PDF file still has the A4 page size, because A4 is still
the system-level default for TeX.

Changing the paperconf default has the effect of reconfiguring the TeX
defaults, like that:

Replacing config file /etc/papersize with new version
tl-paper: setting paper size for context to A4: 
/var/lib/texmf/tex/context/user/cont-sys-paper.tex
tl-paper: setting paper size for dvipdfmx to a4: 
/var/lib/texmf/dvipdfmx/dvipdfmx-paper.cfg
tl-paper: setting paper size for dvips to a4: 
/var/lib/texmf/dvips/config/config-paper.ps
tl-paper: setting paper size for pdftex to a4: 
/var/lib/texmf/tex/generic/tex-ini-files/pdftexconfig.tex
tl-paper: setting paper size for xdvi to a4: /var/lib/texmf/xdvi/XDvi-paper
Running mktexlsr. This may take some time... done.
Building format(s) --refresh.
This may take some time... done.

(This may take several minutes.)

Said otherwise, the end user cannot choose the default for TeX
(not even statically).

BTW, the TeX-level configuration isn't even always consistent.
For instance, tl-paper was giving

Current context paper size (from 
/var/lib/texmf/tex/context/user/cont-sys-paper.tex): letter
Current dvipdfmx paper size (from /var/lib/texmf/dvipdfmx/dvipdfmx-paper.cfg): 
a4
Current dvips paper size (from /var/lib/texmf/dvips/config/config-paper.ps): a4
Current pdftex paper size (from 
/var/lib/texmf/tex/generic/tex-ini-files/pdftexconfig.tex): a4
Current xdvi paper size (from /var/lib/texmf/xdvi/XDvi-paper): a4

This is crap design.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1079786: texlive-latex-base: buggy testpage.tex: missing \usepackage{geometry}

[Vincent Lefevre]

Package: texlive-latex-base
Version: 2024.20240706-1
Severity: normal

I've tried

  pdflatex /usr/share/texlive/texmf-dist/tex/latex/base/testpage.tex

under Debian/unstable (TeX Live packages 2024.20240706-1) with

\papertype=a5paper
\doublesided=n

(when asked to the question).

The contents assume A5, but the paper size itself is still A4
(thus with blanks on the right and at the bottom), and pdfinfo
says:

Page size:   595.276 x 841.89 pts (A4)

\usepackage{geometry} should be added after the
\documentclass[\papertype]{article} line to fix the issue.

According to the TeX Live mailing-list, this is a Debian-specific
issue.

-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 4292 2024-08-05 12:26:37 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 2022-10-12 23:25:33 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 2024-07-11 23:31:48 
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 2024-07-11 23:31:48 
/usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 2023-11-23 14:52:42 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 2024-07-11 23:31:48 
/usr/share/texmf/web2c/fmtutil.cnf -> /var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 2024-07-11 23:31:48 /usr/share/texmf/web2c/updmap.cfg 
-> /var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5334 2024-07-30 10:50:39 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 2015-09-03 02:24:29 mktex.cnf
-rw-r--r-- 1 root root 475 2023-11-23 14:52:42 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.10.6-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages texlive-latex-base depends on:
ii  fonts-lmodern 2.005-1
ii  tex-common6.18
ii  texlive-base  2024.20240706-1
ii  texlive-binaries  2024.20240313.70630+ds-4

texlive-latex-base recommends no packages.

Versions of packages texlive-latex-base suggests:
ii  texlive-latex-base-doc  2024.20240706-1
pn  wp2latex

Versions of packages tex-common depends on:
ii  ucf  3.0043+nmu1

Versions of packages tex-common suggests:
ii  debhelper  13.20

Versions of packages texlive-latex-base is related to:
ii  tex-common6.18
ii  texlive-binaries  2024.20240313.70630+ds-4

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validate

Bug#1032609: zathura: immediate segmentation fault on some PDF file

[Vincent Lefevre]

Control: forwarded -1 https://github.com/pwmt/zathura/issues/395

Updating upstream bug number (duplicate of this bug).

Other users have reported crashes under similar conditions.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#640462: libreoffice: default window appears partly off-screen

[Vincent Lefevre]

Control: retitle -1 libreoffice: default/document window can appear partly 
off-screen
Control: found -1 4:24.2.5-3

I ran libreoffice with "libreoffice Downloads/n3148.doc", and most
of the document appeared off-screen. I think that the center of the
document window was positioned at the top-left corner of the screen.
Weird.

Just in case: The monitor for this desktop machine has never changed.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1079283: zathura: the first pages of a PDF document can appear as black

[Vincent Lefevre]

Control: severity -1 important

Raising to important because on very large PDF files, such as the
"Arm Architecture Reference Manual", the bug is always reproducible
without any good workaround. Switching to dual view makes the
problem disappear, but this is very slow and may require a lot of
memory, e.g. 20 GB, which triggers the OOM killer on my laptop.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1079283: zathura: the first pages of a PDF document can appear as black

[Vincent Lefevre]

Control: retitled -1 zathura: the first pages of a large PDF file can appear as 
black
Control: tags -1 upstream
Control: forwarded -1 https://github.com/pwmt/zathura/issues/365

There are 2 very similar issues open upstream:

* https://github.com/pwmt/zathura/issues/65 (reported on 2018-06-13)
"Large document is not drawn correctly" saying

  I am trying to open a large PDF with zathura but all I see is black
  screen. I try to scroll up and down - status bar shows pages are
  changed, but it does not improve the screen issue.

which is what I noticed (but the user doesn't say whether only the
first pages are black).

BTW, this was also with "Intel® 64 and IA-32 Architectures Software
Developer's Manual".

* https://github.com/pwmt/zathura/issues/365 (reported on 2022-12-15)
"Large PDF (ARMv8 reference manual) renders black pages with mupdf
backend"

But note that the issue was also reproducible with the poppler backend,
as used in Debian. Other users confirmed the issue, each time with a
large PDF file. Last week, a user said

  I am experiencing similar issues. I was also trying to view that
  same ARMv8 reference that lead me here. I can't see any pages until
  about page 6000 or so when it does finally render a page. [...]

So, like in my case, after some page, the issue disappears.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1079283: zathura: the first pages of a PDF document can appear as black

[Vincent Lefevre]

I restarted Firefox, so that the .local/share/zathura directory
did not exist yet (as it is local to the sandbox), and I couldn't
reproduce the problem at this point. I tried again several times
after removing the .local/share/zathura directory.

The real bug may be that bookmarks.sqlite became "corrupt" (?)
in some sense.

The fact that the problem is reproducible with such a corrupt
bookmarks.sqlite file may be a consequence of this bug, but I
don't know the zathura internals.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1079283: zathura: the first pages of a PDF document can appear as black

[Vincent Lefevre]

Package: zathura
Version: 0.5.8-1
Severity: normal

I opened

  
https://www.intel.fr/content/www/fr/fr/content-details/782158/intel-64-and-ia-32-architectures-software-developer-s-manual-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4.html

with Firefox, which runs in firejail (firefox profile). This had the
effect to download a PDF file ("Intel® 64 and IA-32 Architectures
Software Developer’s Manual", June 2023), which I viewed in zathura
(in my Firefox "Applications" settings, for PDF, I have "Always ask").

But pages 1 to 876 appeared as black (by that, I mean that the pages
were entirely in black color). Pages 877 to 5066 were OK. Navigating
through the document with PageDown, PageUp, End, Home did not change
this fact.

I tried again from Firefox 3 times by reloading the page with Ctrl-R,
and these times, pages 1 to 175 were black.

In a terminal, from a normal shell, I couldn't reproduce this issue,
even after removing the ~/.config/zathura directory. But in firejail
in the same sandbox as firefox

  firejail --join=firefox

the issue occurs all the time, with pages 1 to 175 appearing as
black. Then, still from the firejail sandbox, I moved out the
.local/share/zathura/bookmarks.sqlite file, and the problem
disappeared.

Then I tried with the bookmarks.sqlite culprit file in a normal
shell, and the problem appeared. I've attached this file (it
doesn't seem to contain too private data). This problem is
reproducible with the PDF file named as

  325462-sdm-vol-1-2abcd-3abcd-4.pdf

but it seems that the filename doesn't matter: the file is recognized
by its contents (md5sum 0934be26f994c0ef4292d2242da27e25).

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.10.6-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages zathura depends on:
ii  libc62.39-7
ii  libcairo21.18.0-3+b1
ii  libgirara-gtk3-4 0.4.4-1
ii  libglib2.0-0t64  2.81.2-1
ii  libgtk-3-0t643.24.43-2
ii  libjson-glib-1.0-0   1.8.0-2+b1
ii  libmagic1t64 1:5.45-3
hi  libpango-1.0-0   1.51.0+ds-4
ii  libseccomp2  2.5.5-1+b1
ii  libsqlite3-0 3.46.1-1
ii  libsynctex2  2024.20240313.70630+ds-4
ii  zathura-pdf-poppler  0.3.3-1

zathura recommends no packages.

Versions of packages zathura suggests:
ii  elinks [www-browser]   0.17.0-2
ii  firefox [www-browser]  129.0.2-1
ii  firefox-esr [www-browser]  115.14.0esr-1
ii  links [www-browser]2.29-1+b3
ii  links2 [www-browser]   2.29-1+b3
ii  lynx [www-browser] 2.9.2-1
ii  w3m [www-browser]  0.5.3+git20230121-2+b3
pn  zathura-cb 
pn  zathura-djvu   
pn  zathura-ps 

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


bookmarks.sqlite
Description: Binary data

Bug#1079088: diffutils: diff -d can be very slow, affecting GNU Emacs

[Vincent Lefevre]

On 2024-08-20 02:10:08 +0200, Vincent Lefevre wrote:
> I've just reported the following bug upstream:
> 
> --
> When opening a .diff file, GNU Emacs runs "diff -ad" on 2 files
> it has built (I suppose that the reason is to get a word diff),
> and this can be very slow, even though the original .diff file
> is rather simple.
> 
> I've attached a slow-diff.tar.xz archive with:
>   * diff1L52tn0 and diff2U4TVho (files built be GNU Emacs).
>   * file.diff the original .diff file.

I'm attaching it in this message for the Debian bug.

> When running "/usr/bin/emacs -Q file.diff.xz", I could see what
> takes the whole time with ps or top. Here I could see
> 
>   diff -ad /tmp/diff1L52tn0 /tmp/diff2U4TVho
> 
> As this is slow, I could obtain these files.
> 
> On my recent machine, "diff -ad diff1L52tn0 diff2U4TVho" takes
> 27 seconds.
> --
> 
> Note that Emacs cannot even be interrupted with C-g (this may be
> an additional bug in Emacs).

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


slow-diff.tar.xz
Description: Binary data

Bug#1079088: diffutils: diff -d can be very slow, affecting GNU Emacs

[Vincent Lefevre]

Package: diffutils
Version: 1:3.10-1
Severity: important
Affects: emacs-gtk
Forwarded: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=72723

I've just reported the following bug upstream:

--
When opening a .diff file, GNU Emacs runs "diff -ad" on 2 files
it has built (I suppose that the reason is to get a word diff),
and this can be very slow, even though the original .diff file
is rather simple.

I've attached a slow-diff.tar.xz archive with:
  * diff1L52tn0 and diff2U4TVho (files built be GNU Emacs).
  * file.diff the original .diff file.

When running "/usr/bin/emacs -Q file.diff.xz", I could see what
takes the whole time with ps or top. Here I could see

  diff -ad /tmp/diff1L52tn0 /tmp/diff2U4TVho

As this is slow, I could obtain these files.

On my recent machine, "diff -ad diff1L52tn0 diff2U4TVho" takes
27 seconds.
--

Note that Emacs cannot even be interrupted with C-g (this may be
an additional bug in Emacs).

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.11.0-rc2+ (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages diffutils depends on:
ii  libc6  2.39-7

diffutils recommends no packages.

Versions of packages diffutils suggests:
ii  diffutils-doc  1:3.10-1
ii  wdiff  1.2.2-6

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1079014: bugs.debian.org: unknown maintainers reported on bembo

[Vincent Lefevre]

On 2024-08-18 23:55:18 +0200, Chris Hofstaedtler wrote:
> Control: retitle -1 bugs.debian.org: unknown maintainers reported on bembo
> 
> The problem is not limited to specific packages, but to the specific
> BTS installation on bembo.

Indeed, I can see this issue for other package names, while this was
working correctly in the recent past.

However, for this bug,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079014 gives
the maintainer:

  Package: bugs.debian.org; Maintainer for bugs.debian.org is Debian Bug 
Tracking Team ;
[...]
  [...] Machine Name: bembo

That said, bugs.debian.org is not a real source package, and I suppose
that this is the reason.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1079014: bugs.debian.org: says that the maintainer is unknown for src:gcc-doc-defaults and src:gcc-13-doc

[Vincent Lefevre]

Package: bugs.debian.org
Severity: normal

On https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078158

  Package: src:gcc-doc-defaults; Maintainer for src:gcc-doc-defaults is 
(unknown);

and on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079010

  Package: src:gcc-13-doc; Maintainer for src:gcc-13-doc is (unknown);

In the above cases, the maintainer is unknown, while it is known
according to the PTS pages:

https://tracker.debian.org/pkg/gcc-doc-defaults has

  source: gcc-doc-defaults (contrib)
  maintainer: Debian GCC Maintainers (archive) (DMD)

https://tracker.debian.org/pkg/gcc-13-doc has

  source: gcc-13-doc (non-free)
  maintainer: Dmitry Baryshkov (DMD)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1078939: zsh: incorrect expansion with expand-or-complete and single quote

[Vincent Lefevre]

Package: zsh
Version: 5.9-8
Severity: normal
Forwarded: https://zsh.org/workers/53040

Consider a directory with the following 3 files: a'1 a'2 ab

I get as expected:

disset% echo a\'*
a'1 a'2

But if I type [Tab] (expand-or-complete) after a\'*, I get

disset% echo a\'1 a\'2 ab

instead of

disset% echo a\'1 a\'2

Now, consider a directory with the following 2 files: a'b'1 a'b'2

I get as expected:

disset% echo a\'b\'*
a'b'1 a'b'2

But if I type [Tab] (expand-or-complete) after a\'b\'*, this is not
expanded, while I should have obtained

disset% echo a\'b\'1 a\'b\'2

-- Package-specific info:

Packages which provide vendor completions:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++----===
ii  curl 8.9.1-2  amd64command line tool for 
transferring data with URL syntax
ii  dpkg-dev 1.22.11  all  Debian package development tools
ii  mercurial-common 6.8-3all  easy-to-use, scalable 
distributed version control system (common files)
ii  systemd  256.4-3  amd64system and service manager
ii  udev 256.4-3  amd64/dev/ and hotplug management 
daemon
ii  zathura  0.5.8-1  amd64document viewer with a 
minimalistic interface

dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.10.4-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages zsh depends on:
ii  debianutils  5.20
ii  libc62.39-7
ii  libcap2  1:2.66-5
ii  libtinfo66.5-2
ii  zsh-common   5.9-8

Versions of packages zsh recommends:
ii  libgdbm6t64   1.24-2
ii  libncursesw6  6.5-2
ii  libpcre2-8-0  10.42-4+b1

Versions of packages zsh suggests:
ii  zsh-doc  5.9-8

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1078158: gcc-doc-defaults: switch to GCC 14

[Vincent Lefevre]

On 2024-08-07 15:13:52 +0200, Andreas Beckmann wrote:
> gcc-doc-defaults started to FTBFS when the default compiler has been
> switched to GCC 14. Please update the doc package to GCC 14, too.

But gcc-14-doc is not available in Debian yet.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1051496: mailgraph: does not support the new syslog format

[Vincent Lefevre]

(Replying only now because I haven't received some of these messages,
though I'm normally subscribed to this bug.)

On 2024-03-28 18:23:33 +0100, Jörg Frings-Fürst wrote:
> We are using mailgraph one multiple server with Debian Bullseye,
> Bookworm and Trixie without any failure.

This is normal for Bullseye, but the syslog format changed in Bookworm,
which still has mailgraph 1.14-20. So, how can this work?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#708979: closed by Gioele Barabucci (Re: Bug#708979: bash (readline): Something is wrong with binding keys to functions)

[Vincent Lefevre]

At http://www.catb.org/esr/jargon/html/M/meta-bit.html it is written

meta bit: n.

  The top bit of an 8-bit character, which is on in character values
  128--255. Also called high bit, alt bit. Some terminals and consoles
  (see space-cadet keyboard) have a META shift key. [...]



That's probably why readline regards "\M-" as setting the meta bit,
i.e. the 8th bit. This could be useful with the ASCII charset, where
the 8th bit could be stripped by the terminal and interpreted in
some special way (e.g. "\M-" commands), but this no longer makes
any sense with true characters having the 8th bit set.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#708979: closed by Gioele Barabucci (Re: Bug#708979: bash (readline): Something is wrong with binding keys to functions)

[Vincent Lefevre]

On 2024-08-13 16:28:42 +0100, Reuben Thomas wrote:
> I'm not quite sure I understand you here: are you saying that it's
> documented somewhere that one should use the "\e" form?

I'm saying that since the documentation says that the Meta key
may generate an Escape character (which is actually the case in
general), you should use the \e form as a consequence.

I think that knowing how things work exactly is complex due to
the various variables. From the readline(3readline) man page,
in particular:

  convert-meta (On)
If  set  to  On, readline will convert characters with the eighth
bit set to an ASCII key sequence by stripping the eighth bit  and
prefixing it with an escape character (in effect, using escape as
the meta prefix).  The default is On, but readline will set it to
Off  if  the locale contains eight-bit characters.  This variable
is dependent on the LC_CTYPE locale category, and may  change  if
the locale is changed.

  enable-meta-key (On)
When set to On, readline will try to enable any meta modifier key
the terminal claims to support when it is called.  On many termi‐
nals, the meta key is used to send eight-bit characters.

(Note: This is wrong, nowadays, the Meta key generates an Escape
character.)

  input-meta (Off)
If set to On, readline will enable eight-bit input (that  is,  it
will  not  clear  the eighth bit in the characters it reads), re‐
gardless of what the terminal claims it can  support.   The  name
meta-flag  is  a  synonym for this variable.  The default is Off,
but readline will set it to On if the locale  contains  eight-bit
characters.   This  variable  is dependent on the LC_CTYPE locale
category, and may change if the locale is changed.

> As I said in my original report, "\M-" worked fine in readline 5.0.
> So as far as I can tell, it's a regression.

Indeed, you said:

"With readline 5.0 they work fine, but with 5.1 they don't work."

In the CHANGES file:


This document details the changes between this version, readline-5.1,
and the previous version, readline-5.0.
[...]
m.  Fixed a bug that caused "\M-x" style key bindings to not obey the setting
of the `convert-meta' variable.


So you can get the previous behavior about the .inputrc file with

  set convert-meta On

but this means that non-ASCII characters (i.e. with the 8th bit set)
will be regarded as ASCII characters with the Meta key.

> In any case, I can't see any sense in requiring \e for some keys and
> not others.

I suppose that this was historical. IMHO, any behavior based on the
8th bit should be removed. Nowadays, the 8th bit should be used for
non-ASCII characters, not to provide meta key information. This
would mean that "\M-" in the .inputrc file should behave like "\e".

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#708979: closed by Gioele Barabucci (Re: Bug#708979: bash (readline): Something is wrong with binding keys to functions)

[Vincent Lefevre]

On 2024-08-10 15:50:55 +0100, Reuben Thomas wrote:
> On Sat, 10 Aug 2024 at 10:03, Debian Bug Tracking System <
> ow...@bugs.debian.org> wrote:
> > -- Forwarded message --
> > From: Gioele Barabucci 
> > To: 708979-d...@bugs.debian.org
> > Cc:
> > Bcc:
> > Date: Sat, 10 Aug 2024 11:01:07 +0200
> > Subject: Re: Bug#708979: bash (readline): Something is wrong with binding
> > keys to functions
> > Version: 5.2.21-2.1
> >
> > On Wed, 19 Apr 2006 15:11:20 +0100 Reuben Thomas  wrote:
> > > In my .inputrc I have the following lines:
> > >
> > > "\M-n": history-search-forward
> > > "\M-p": history-search-backward
> > > "\C-u": kill-whole-line
> > >
> > > With readline 5.0 they work fine, but with 5.1 they don't work.
> >
> > this issue does not seem to affect version 5.2.21 of bash and
> > libreadline8 version 8.2-4.
> 
> Thank for looking into this issue!
> 
> I just tried on my Bookworm system (bash 5.2.15-2+b7) and the bug
> with \M-p and \M-n still seems present there.

For \M-p and \M-n, this may be a documentation inaccuracy. The
readline(3readline) man page says

  An Emacs-style notation is used to denote keystrokes.  Control keys are
  denoted by C-key, e.g., C-n means Control-N.  Similarly, meta keys  are
  denoted  by  M-key,  so M-x means Meta-X.  (On keyboards without a meta
  key, M-x means ESC x, i.e., press the Escape key then the x key.   This
  makes  ESC the meta prefix.  The combination M-C-x means ESC-Control-x,
  or press the Escape key then hold the Control key while pressing the  x
  key.)

However, even if the keyboard has a Meta key, it has the effect to
generate an Escape character, so that one should use the \e form in
the .inputrc file. For instance, with

"\ep": history-search-backward

M-p does a history-search-backward with libreadline8 (I've tried with
gp from the pari-gp package).

I think that this is just a notation issue. In GNU Emacs, if I type
ESC x, then M-x is displayed.

Perhaps readline should make \M- equivalent to \e for the .inputrc
file.

The behavior is the same in bash. BTW, with the default bindings,
"bind -p" shows only \e forms; there are no bindings with "\M-".
And note that if I use

"\M-p": history-search-backward

in the .inputrc file, "bind -p" gives for this binding:

"\360": history-search-backward

This is the octal value of the ASCII code of the character "p" (\160)
with the 8th bit set (→ \360). AFAIK, setting the 8th bit was an old,
optional way the Meta key was behaving with xterm, but with the
non-ASCII locales, this is now completely obsolete.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1078208: fail2ban: sshd.conf filter does not works with OpenSSH 9.8

[Vincent Lefevre]

Control: tags -1 patch

I've attached a patch fixing both issues.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
--- fail2ban-1.1.0-a/config/filter.d/sshd.conf
+++ fail2ban-1.1.0-b/config/filter.d/sshd.conf
@@ -16,7 +16,7 @@
 
 [DEFAULT]
 
-_daemon = sshd
+_daemon = sshd(?:-session)?
 
 # optional prefix (logged from several ssh versions) like "error: ", "error: 
PAM: " or "fatal: "
 __pref = (?:(?:error|fatal): (?:PAM: )?)?
@@ -126,7 +126,7 @@
 
 maxlines = 1
 
-journalmatch = _SYSTEMD_UNIT=sshd.service + _COMM=sshd
+journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd
 
 # DEV Notes:
 #

Bug#1078208: fail2ban: sshd.conf filter does not works with OpenSSH 9.8

[Vincent Lefevre]

On 2024-08-11 02:53:27 +0200, Vincent Lefevre wrote:
> On 2024-08-08 11:25:07 +0200, Vincent Lefevre wrote:
> > As seen at https://github.com/fail2ban/fail2ban/pull/3782/files
> > the change is quite simple: change
> > 
> > _daemon = sshd
> > 
> > to
> > 
> > _daemon = sshd(?:-session)?
> 
> Unfortunately this change alone does not solve the issue.
> 
> I'm wondering whether this depends on another change.

I've found the issue. One also needs

  
https://github.com/fail2ban/fail2ban/commit/6fce23e7baa484c7d1f9b0c9a11986f3916c41dd

i.e. change

  journalmatch = _SYSTEMD_UNIT=sshd.service + _COMM=sshd

to

  journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd

Indeed, "journalctl -u sshd.service" does not find any entry,
contrary to "journalctl -u ssh.service".

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1078208: fail2ban: sshd.conf filter does not works with OpenSSH 9.8

[Vincent Lefevre]

On 2024-08-08 11:25:07 +0200, Vincent Lefevre wrote:
> As seen at https://github.com/fail2ban/fail2ban/pull/3782/files
> the change is quite simple: change
> 
> _daemon = sshd
> 
> to
> 
> _daemon = sshd(?:-session)?

Unfortunately this change alone does not solve the issue.

I'm wondering whether this depends on another change.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#708979: \C-u still broken

[Vincent Lefevre]

On 2024-08-10 11:35:21 +0200, Vincent Lefevre wrote:
> On 2024-08-10 09:03:04 +, Debian Bug Tracking System wrote:
> > On Wed, 19 Apr 2006 15:11:20 +0100 Reuben Thomas  wrote:
> > > In my .inputrc I have the following lines:
> > > 
> > > "\M-n": history-search-forward
> > > "\M-p": history-search-backward
> > > "\C-u": kill-whole-line
> > > 
> > > With readline 5.0 they work fine, but with 5.1 they don't work.
> > 
> > Hi,
> > 
> > this issue does not seem to affect version 5.2.21 of bash and libreadline8
> > version 8.2-4.
> > 
> > Please reopen this bug if you can still reproduce this issue.
> 
> \C-u is still broken: it kills only the characters before the cursor
> instead of the whole line as documented in the bash(1) man page:
> 
>   kill-whole-line
> Kill all characters on the current line, no matter where point is.

history-search-forward and history-search-backward seem also buggy,
but it may be a documentation issue (they behave in a slightly
different way).

These issues are still present in readline. I've just reported the
following bug against libreadline8t64 for \C-u:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078428

(the old bugs in obsolete readline binary packages had been closed).

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1078428: libreadline8t64: \C-u kill-whole-line kills only the characters before the cursor instead of the whole line if ^U is the kill character

[Vincent Lefevre]

Package: libreadline8t64
Version: 8.2-4
Severity: normal

With

  "\C-u": kill-whole-line

in the .inputrc file, if ^U is the kill character (usual tty settings),
\C-u kills only the characters before the cursor instead of the whole
line.

This bug was already present in some old libreadline versions:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363502
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708978

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.11.0-rc2+ (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libreadline8t64 depends on:
ii  libc62.39-6
ii  libtinfo66.5-2
ii  readline-common  8.2-4

libreadline8t64 recommends no packages.

libreadline8t64 suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#708979: \C-u still broken

[Vincent Lefevre]

Control: reopen -1
Control: found -1 5.2.21-2.1

On 2024-08-10 09:03:04 +, Debian Bug Tracking System wrote:
> On Wed, 19 Apr 2006 15:11:20 +0100 Reuben Thomas  wrote:
> > In my .inputrc I have the following lines:
> > 
> > "\M-n": history-search-forward
> > "\M-p": history-search-backward
> > "\C-u": kill-whole-line
> > 
> > With readline 5.0 they work fine, but with 5.1 they don't work.
> 
> Hi,
> 
> this issue does not seem to affect version 5.2.21 of bash and libreadline8
> version 8.2-4.
> 
> Please reopen this bug if you can still reproduce this issue.

\C-u is still broken: it kills only the characters before the cursor
instead of the whole line as documented in the bash(1) man page:

  kill-whole-line
Kill all characters on the current line, no matter where point is.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1078255: xterm: segmentation fault when clicking on the right button

[Vincent Lefevre]

On 2024-08-09 15:01:17 -0400, Thomas Dickey wrote:
> On Fri, Aug 09, 2024 at 02:44:46PM -0400, Thomas Dickey wrote:
> > Is this something that you might reproduce, to provide test-data?

I tried to reproduce it, but I couldn't.

> ld could be null if there's some inconsistency in the select begin/end
> bookkeeping, or if (for example) in selecting from the scrollback and
> there's some inconsistency in the function that retrieves a pointer
> to the line.  Adding a check in okPosition can help some, but a bug
> in the scrollback logic will probably surface in some other place.

I may have clicked in the scrollback. I don't remember.

> If it's an inconsistency in the select begin/end bookkeeping, that's
> something that you might recall the sequence of operations which triggered
> the problem.  The stack trace says that the beginning of the selection
> has no valid line pointer.

I had clicked with the right button by mistake (which sometimes
happens when I move the mouse). So I did not explicitly set the
beginning of the selection.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1078255: xterm: segmentation fault when clicking on the right button

[Vincent Lefevre]

Package: xterm
Version: 393-1
Severity: important

I got a segmentation fault when clicking on the right button.

Core was generated by `/usr/bin/xterm -xrm *printFileOnXError: 
/home/vinc17/private/xterm-saved-172316'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  class_of (cell=0x7fb5479b9da8, ld=0x0) at ../button.c:3606

The full backtrace:

Thread 1 (Thread 0x7fb547a6a280 (LWP 5045)):
#0  class_of (cell=0x7fb5479b9da8, ld=0x0) at ../button.c:3606
temp = {row = , col = 0}
result = 0
temp = 
result = 
#1  ComputeSelect (xw=xw@entry=0x7fb5479ad010, extend=extend@entry=0, normal=1, 
endc=0x7fb5479b9dd8, startc=0x7fb5479b9dd0) at ../button.c:4160
mark = 
screen = 0x7fb5479ad1d0
cclass = 
first = {row = -260, col = 0}
last = 
ignored = 0 '\000'
ld = {startSel = 0x0, endSel = 0x559b94310190}
ltmp = 
#2  0x559b7d2adf6d in ExtendExtend (xw=xw@entry=0x7fb5479ad010, 
cell=cell@entry=0x7fffa94a9be8) at ../button.c:3319
screen = 0x7fb5479ad1d0
coord = 
#3  0x559b7d2ae065 in EndExtend (xw=xw@entry=0x7fb5479ad010, 
event=event@entry=0x7fffa94aa0a0, params=params@entry=0x559b941ab410, 
num_params=2, use_cursor_loc=use_cursor_loc@entry=0) at ../button.c:3101
cell = {row = 19, col = 10}
screen = 0x7fb5479ad1d0
#4  0x559b7d2afcf6 in do_select_end (num_params=, 
use_cursor_loc=0, params=0x559b941ab410, event=0x7fffa94aa0a0, 
xw=0x7fb5479ad010) at ../button.c:1573
screen = 
screen = 
#5  do_select_end (use_cursor_loc=0, num_params=0x559b941ab3b0, 
params=0x559b941ab410, event=0x7fffa94aa0a0, xw=0x7fb5479ad010) at 
../button.c:1553
screen = 0x7fb5479ad1d0
screen = 
#6  HandleSelectEnd (w=, event=0x7fffa94aa0a0, 
params=0x559b941ab410, num_params=0x559b941ab3b0) at ../button.c:1591
xw = 0x7fb5479ad010
#7  0x7fb548071d1f in HandleActions (w=w@entry=0x7fb5479ad010, 
event=0x7fffa94aa0a0, stateTree=0x559b941abf80, accelWidget=, 
procs=0x559b941efe58, actions=actions@entry=0x559b941ab3a0) at 
../../src/TMstate.c:653
actionHookList = 0x0
bindWidget = 
#8  0x7fb5480725e1 in HandleSimpleState (w=w@entry=0x7fb5479ad010, 
tmRecPtr=tmRecPtr@entry=0x7fb5479ad058, 
curEventPtr=curEventPtr@entry=0x7fffa94a9df0) at ../../src/TMstate.c:878
bindData = 
procs = 
accelWidget = 
xlations = 0x559b941c83f0
contextPtr = 0x7fb5479ad068
i = 
actions = 
matchExact = 
match = 
complexMatchState = 
typeIndex = 
modIndex = 
matchTreeIndex = 
#9  0x7fb548073508 in _XtTranslateEvent (w=w@entry=0x7fb5479ad010, 
event=event@entry=0x7fffa94aa0a0) at ../../src/TMstate.c:1076
tmRecPtr = 
curEvent = {xev = 0x7fffa94aa0a0, event = {modifiers = 3072, 
modifierMask = 0, lateModifiers = 0x0, eventType = 5, eventCode = 4, 
eventCodeMask = 0, matchEvent = 0x0, standard = 0 '\000'}}
current_state = 
#10 0x7fb54804aa0b in XtDispatchEventToWidget 
(widget=widget@entry=0x7fb5479ad010, event=event@entry=0x7fffa94aa0a0) at 
../../src/Event.c:932
p = 
was_dispatched = 
call_tm = 
cont_to_disp = 1 '\001'
mask = 
app = 
#11 0x7fb54804b152 in _XtDefaultDispatcher (event=0x7fffa94aa0a0) at 
../../src/Event.c:1406
mask = 8
dspWidget = 0x7fb5479ad010
was_filtered = 
widget = 0x7fb5479ad010
grabType = remap
pdi = 0x559b9418a640
grabList = 0x0
was_dispatched = 0 '\000'
app = 
#12 0x7fb54804b2b1 in XtDispatchEvent (event=event@entry=0x7fffa94aa0a0) at 
../../src/Event.c:1480
was_dispatched = 
safe = 
dispatch_level = 1
starting_count = 0
pd = 
time = 
dispatch = 
app = 0x559b941824e0
#13 0x559b7d2eadf7 in mergeButtonEvents (target=) at 
../misc.c:534
next_event = {type = 5, xany = {type = 5, serial = 26860, send_event = 
0, display = 0x559b941837d0, window = 35651612}, xkey = {type = 5, serial = 
26860, send_event = 0, display = 0x559b941837d0, window = 35651612, root = 
1662, subwindow = 0, time = 22007178, x = 131, y = 431, x_root = 350, y_root = 
521, state = 3072, keycode = 4, same_screen = 1}, xbutton = {type = 5, serial = 
26860, send_event = 0, display = 0x559b941837d0, window = 35651612, root = 
1662, subwindow = 0, time = 22007178, x = 131, y = 431, x_root = 350, y_root = 
521, state = 3072, button = 4, same_screen = 1}, xmotion = {type = 5, serial = 
26860, send_event = 0, display = 0x559b941837d0, window = 35651612, root = 
1662, subwindow = 0, time = 22007178, x = 131, y = 431, x_root = 350, y_root = 
521, state = 3072, is_hint = 4 '\004', same_screen = 1}, xcrossing = {type = 5, 
serial = 26860, send_event = 0, display = 0x559b941837d0, window = 35651612, 
root = 1662, subwindow = 0, time = 22007178, x = 131, y = 431,

Bug#1078208: fail2ban: sshd.conf filter does not works with OpenSSH 9.8

[Vincent Lefevre]

Package: fail2ban
Version: 1.1.0-4
Severity: serious
Tags: upstream fixed-upstream

The fail2ban sshd.conf filter does not works with OpenSSH 9.8.
This is due to

openssh (1:9.8p1-1) unstable; urgency=medium

  * New upstream release (https://www.openssh.com/releasenotes.html#9.8p1):
[...]
- sshd(8): several log messages have changed.  In particular, some log
  messages will be tagged with as originating from a process named
  "sshd-session" rather than "sshd".

This was fixed upstream several weeks ago:

  https://github.com/fail2ban/fail2ban/pull/3782

As seen at https://github.com/fail2ban/fail2ban/pull/3782/files
the change is quite simple: change

_daemon = sshd

to

_daemon = sshd(?:-session)?

(As sshd.conf is a conffile, the user might already fix this on his
side, but it must be correct by default, in particular for the next
Debian release.)

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.10.3-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fail2ban depends on:
ii  python3  3.12.4-1
ii  python3-systemd  235-1+b4

Versions of packages fail2ban recommends:
ii  iptables   1.8.10-4
ii  nftables   1.1.0-2
ii  python3-pyinotify  0.9.6-3
ii  whois  5.5.23

Versions of packages fail2ban suggests:
ii  mailutils [mailx]  1:3.17-2+b1
pn  monit  
ii  sqlite33.46.0-1
pn  system-log-daemon  

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1076449: Re-assigning to mercurial, should be fixed there

[Vincent Lefevre]

On 2024-08-07 15:55:14 +0200, Matthias Klose wrote:
> Python 3.12.5 released with that patch, so I assume upstream will not fix
> that.
> 
> The Debian bug contains a proposal for a less invasive fix in mercurial,
> therefore re-assigning and keeping the bug open

Note that this has already been fixed in the mercurial package:

mercurial (6.8-2) unstable; urgency=high

  * Fix demandimport breakage with recent python changes (see #1076449).

 -- Julien Cristau   Mon, 22 Jul 2024 18:26:26 +0200

Is there something else to do or should this bug just be closed?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1078166: apt-daily.service is sometimes executed during package installation

[Vincent Lefevre]

On 2024-08-07 16:42:56 +0200, Julian Andres Klode wrote:
> As I mentioned in the other thread, we do not do anything with the
> systemd services. We do restart the timers, which I guess could mess
> up the randomization or something?
> 
> But I don't know, I'd need more info from systemd people.

Additional details: I can see in the apt-daily.timer file

[Timer]
OnCalendar=*-*-* 6,18:00
RandomizedDelaySec=12h
Persistent=true

and it seems that

  systemctl --system daemon-reload >/dev/null || true

sometimes has the effect to execute the service immediately, thus
ignoring the randomization.

If randomization is currently ignored for some reason, there should
at least be an option to preserve the randomization at the reload
of the daemons. The observed behavior of systemd does not seem to
be documented in the systemd.timer(5) man page.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1070027: apt: daily systemd service handles dpkg frontend locking incorrectly?

[Vincent Lefevre]

On 2024-08-07 14:16:59 +0200, Julian Andres Klode wrote:
> On upgrades, we do not restart or reload or otherwise interact with
> either apt-daily service, and the services are ordered so they do not
> run at the same time either; so you won't see races between the services
> or races from the service being restarted and lose to a parent apt
> process.

You're wrong about that. An upgrade / package installation
occasionally executes the apt-daily service, i.e. precisely at the
worst time for that! This is precisely why the issue with aptitude
is so frequent. I've submitted a new bug about this.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1078166: apt-daily.service is sometimes executed during package installation

[Vincent Lefevre]

Package: apt
Version: 2.9.7
Severity: normal

The installation/upgrade of some packages reloads the systemd daemons,
which occasionally has the effect to execute the apt-daily service,
which runs "/usr/lib/apt/apt.systemd.daily update".

This is silly, because precisely at this time, either there already
is a /var/lib/dpkg/lock-frontend lock (due to the installation) and
the command fails, or if the frontend, like aptitude, releases the
lock temporarily, this may make installation by the frontend fail.
In any case, this is not satisfactory.

If the "apt.systemd.daily update" must be run at this time (reload
of systemd daemons), there is a major problem. Otherwise, it should
be run at a later time, so that there is a high probability that
the installation has finished, avoiding a lock failure. Or why not
completely relying on a randomized timer?

-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (no /etc/apt/preferences.d/* present) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (no /etc/apt/sources.list.d/* present) --


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.10.3-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt depends on:
ii  adduser 3.137
ii  base-passwd 3.6.4
ii  debian-archive-keyring  2023.4
ii  gpgv2.2.43-8
ii  libapt-pkg6.0t642.9.7
ii  libc6   2.39-6
ii  libgcc-s1   14.2.0-1
ii  libgnutls30t64  3.8.6-2
ii  libseccomp2 2.5.5-1+b1
ii  libstdc++6  14.2.0-1
ii  libsystemd0 256.4-2

Versions of packages apt recommends:
ii  ca-certificates  20240203

Versions of packages apt suggests:
ii  apt-doc 2.9.7
ii  aptitude0.8.13-6
ii  dpkg-dev1.22.11
ii  gnupg   2.2.43-8
pn  powermgmt-base  

-- Configuration Files:
/etc/logrotate.d/apt changed [not included]

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1070027: apt: daily systemd service handles dpkg frontend locking incorrectly?

[Vincent Lefevre]

On 2024-08-07 11:56:56 +0200, Julian Andres Klode wrote:
> Control: reassign -1 aptitude
> Control: retitle -1 aptitude: frontend lock support
> 
> On Wed, Aug 07, 2024 at 11:38:35AM GMT, Vincent Lefevre wrote:
> > On 2024-08-07 11:04:15 +0200, Guillem Jover wrote:
> > > On Thu, 2024-07-25 at 11:03:50 +0200, Vincent Lefevre wrote:
> > [...]
> > > > With VERBOSE=2, I could get more details about this failure:
> > > > 
> > > > Jul 25 13:22:16 qaa systemd[1]: Starting apt-daily.service - Daily apt 
> > > > download activities...
> > > > Jul 25 13:22:16 qaa apt.systemd.daily[378644]: E: Could not get lock 
> > > > /var/lib/dpkg/lock-frontend. It is held by process 378454 (apt)
> > > > Jul 25 13:22:16 qaa apt.systemd.daily[378644]: E: Unable to acquire the 
> > > > dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process 
> > > > using it?
> > > > Jul 25 13:22:16 qaa apt.systemd.daily[378637]: error encountered in 
> > > > cron job with "apt-get check".
> > > > Jul 25 13:22:16 qaa systemd[1]: apt-daily.service: Deactivated 
> > > > successfully.
> > > > Jul 25 13:22:16 qaa systemd[1]: Finished apt-daily.service - Daily apt 
> > > > download activities.
> > > > 
> > > > Here, the failure occurs in the apt.systemd.daily, because the
> > > > process used for the upgrade got the lock first. But it could
> > > > be the other way round, as this could be seen with aptitude.
> > > 
> > > So, as mentioned above, and as we saw earlier in the bug report, it looks
> > > like the lock handling in the apt-daily.service is not working, and is
> > > interfering with the current run. This needs to be fixed there
> > > somehow. Reassigning.
> > 
> > OK. So, in short, apt keeps the lock for too long. The lock should
> > be released by apt for triggers since a lock may be needed by some
> > process run by a trigger.
> 
> No that's nonsense. The frontend lock is exactly supposed to be held
> while running dpkg (which runs the lock). This is working as designed.

WRONG! You can see above an error *without* using aptitude.
Even though there may be a bug in aptitude, there is also
a bug related to apt.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1070027: apt: daily systemd service handles dpkg frontend locking incorrectly?

[Vincent Lefevre]

On 2024-08-07 11:04:15 +0200, Guillem Jover wrote:
> On Thu, 2024-07-25 at 11:03:50 +0200, Vincent Lefevre wrote:
[...]
> > With VERBOSE=2, I could get more details about this failure:
> > 
> > Jul 25 13:22:16 qaa systemd[1]: Starting apt-daily.service - Daily apt 
> > download activities...
> > Jul 25 13:22:16 qaa apt.systemd.daily[378644]: E: Could not get lock 
> > /var/lib/dpkg/lock-frontend. It is held by process 378454 (apt)
> > Jul 25 13:22:16 qaa apt.systemd.daily[378644]: E: Unable to acquire the 
> > dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using 
> > it?
> > Jul 25 13:22:16 qaa apt.systemd.daily[378637]: error encountered in cron 
> > job with "apt-get check".
> > Jul 25 13:22:16 qaa systemd[1]: apt-daily.service: Deactivated successfully.
> > Jul 25 13:22:16 qaa systemd[1]: Finished apt-daily.service - Daily apt 
> > download activities.
> > 
> > Here, the failure occurs in the apt.systemd.daily, because the
> > process used for the upgrade got the lock first. But it could
> > be the other way round, as this could be seen with aptitude.
> 
> So, as mentioned above, and as we saw earlier in the bug report, it looks
> like the lock handling in the apt-daily.service is not working, and is
> interfering with the current run. This needs to be fixed there
> somehow. Reassigning.

OK. So, in short, apt keeps the lock for too long. The lock should
be released by apt for triggers since a lock may be needed by some
process run by a trigger.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1078128: libc6: mtrace() + malloc() do not generate data

[Vincent Lefevre]

Package: libc6
Version: 2.39-6
Severity: normal

When testing the example given in the mtrace(3) man page,
no data are generated:

$ cat t_mtrace.c
#include 
#include 
#include 

int
main(void)
{
  mtrace();

  for (unsigned int j = 0; j < 2; j++)
malloc(100);/* Never freed--a memory leak */

  calloc(16, 16); /* Never freed--a memory leak */
  exit(EXIT_SUCCESS);
}

$ cc -g t_mtrace.c -o t_mtrace
t_mtrace.c: In function ‘main’:
t_mtrace.c:11:5: warning: ignoring return value of ‘malloc’ declared with 
attribute ‘warn_unused_result’ [-Wunused-result]
   11 | malloc(100);/* Never freed--a memory leak */
  | ^~~
t_mtrace.c:13:3: warning: ignoring return value of ‘calloc’ declared with 
attribute ‘warn_unused_result’ [-Wunused-result]
   13 |   calloc(16, 16); /* Never freed--a memory leak */
  |   ^~
$ export MALLOC_TRACE=/tmp/t
$ ./t_mtrace
$ mtrace ./t_mtrace $MALLOC_TRACE
Cannot open mtrace data file at /bin/mtrace line 152,  line 4.
$ ls $MALLOC_TRACE
ls: cannot access '/tmp/t': No such file or directory

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc6 depends on:
ii  libgcc-s1  14.2.0-1

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.7-2

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.87
ii  glibc-doc  2.39-6
ii  libc-l10n  2.39-6
pn  libnss-nis 
pn  libnss-nisplus 
ii  locales2.39-6

-- debconf information:
  glibc/disable-screensaver:
  glibc/kernel-not-supported:
  glibc/restart-services:
  glibc/upgrade: true
  glibc/kernel-too-old:
  glibc/restart-failed:
* libraries/restart-without-asking: true

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1078127: libc6: mcheck(NULL) fails even at the beginning of a program

[Vincent Lefevre]

Package: libc6
Version: 2.39-6
Severity: normal

The following program

#include 
#include 

int main (void)
{
  int r;

  r = mcheck (NULL);
  printf ("%d\n", r);
  return 0;
}

outputs -1, which is incorrect. It should have been 0.

The glibc manual says

  It is too late to begin allocation checking once you have allocated
  anything with ‘malloc’.  So ‘mcheck’ does nothing in that case.
  The function returns ‘-1’ if you call it too late, and ‘0’
  otherwise (when it is successful).

Since there hasn't been any malloc yet, 0 should have been output.

Similarly, the example given in the mcheck(3) man page fails
unexpectedly.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc6 depends on:
ii  libgcc-s1  14.2.0-1

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.7-2

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.87
ii  glibc-doc  2.39-6
ii  libc-l10n  2.39-6
pn  libnss-nis 
pn  libnss-nisplus 
ii  locales2.39-6

-- debconf information:
  glibc/restart-failed:
* libraries/restart-without-asking: true
  glibc/disable-screensaver:
  glibc/upgrade: true
  glibc/restart-services:
  glibc/kernel-not-supported:
  glibc/kernel-too-old:

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1076729: libwayland: breaks plasma desktop start after last upgrade to version 1.23.0-1

[Vincent Lefevre]

On 2024-08-05 12:42:42 +0200, Vincent Lefevre wrote:
> This bug was closed, but has not been marked as fixed in
> libwayland-client0, so that the current version is still
> regarded as buggy, as reported by apt-listbugs:
> 
> serious bugs of libwayland-client0 (1.22.0-2.1+b1 → 1.23.0-1)  some Version>
>  b1 - #1076729 - libwayland: breaks plasma desktop start after last upgrade 
> to version 1.23.0-1 (Fixed: kwin/4:5.27.11-2)
[...]
> If this is regarded as a bug in libwayland-client0, this bug should
> still remain open until it is fixed *in wayland*. Otherwise it should
> be reassigned to kwin-wayland.

BTW, this is also signaled in the PTS (not just by apt-listbugs):

https://tracker.debian.org/pkg/wayland

Migration status for wayland (1.22.0-2.1 to 1.23.0-1): BLOCKED: 
Rejected/violates migration policy/introduces a regression
Issues preventing migration:
∙ ∙ Updating wayland would introduce bugs in testing: #1076729

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1076729: libwayland: breaks plasma desktop start after last upgrade to version 1.23.0-1

[Vincent Lefevre]

This bug was closed, but has not been marked as fixed in
libwayland-client0, so that the current version is still
regarded as buggy, as reported by apt-listbugs:

serious bugs of libwayland-client0 (1.22.0-2.1+b1 → 1.23.0-1) 
 b1 - #1076729 - libwayland: breaks plasma desktop start after last upgrade to 
version 1.23.0-1 (Fixed: kwin/4:5.27.11-2)

One currently has

Package: libwayland-client0
Affects: kwin-wayland
Severity: serious
Found in version wayland/1.23.0-1
Fixed in version kwin/4:5.27.11-2

If this is regarded as a bug in libwayland-client0, this bug should
still remain open until it is fixed *in wayland*. Otherwise it should
be reassigned to kwin-wayland.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1032609: zathura: immediate segmentation fault on some PDF file

[Vincent Lefevre]

Control: retitle -1 zathura: crash when quitting before PDF rendering is 
complete
Control: forwarded -1 https://github.com/pwmt/zathura/issues/656

I've submitted an issue upstream.

On 2024-08-05 10:03:45 +0200, Vincent Lefevre wrote:
> I can still reproduce the segmentation fault on the same machine
> before the upgrade to the latest version, and after the upgrade.

And even on a newer machine, but this is more difficult, probably
because it is much faster. So I had the idea to try on larger
PDF files, with large images, and I can reproduce the crash all
the time. I just need to quit fast enough (with 'q'), apparently
before rendering is complete.

This is not always a segmentation fault, but this can be

zathura: ../../../src/cairo-pattern.c:1155: cairo_pattern_destroy: Assertion 
`CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&pattern->ref_count)' failed.
zsh: IOT instruction (core dumped)  zathura wd/doc/lyon/tcl/lignes-fortes.pdf

zathura: ../../../src/cairo-pattern.c:1093: cairo_pattern_reference: Assertion 
`CAIRO_REFERENCE_COUNT_HAS_REFERENCE (&pattern->ref_count)' failed.
zsh: IOT instruction (core dumped)  zathura 
visorando-circuit-des-chapelles-a-sainte-catherine.pdf

According to the zathura source, zathura uses threading. So the
cause might be that when zathura receives 'q', it starts to free
some data structures while rendering is still done in another
thread.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1032609: zathura: immediate segmentation fault on some PDF file

[Vincent Lefevre]

Control: found -1 0.5.6-1
Control: found -1 0.5.8-1

I can still reproduce the segmentation fault on the same machine
before the upgrade to the latest version, and after the upgrade.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1077886: xterm: spurious characters in reverse video in scrollback buffer

[Vincent Lefevre]

On 2024-08-05 04:17:16 +0200, Vincent Lefevre wrote:
> Unfortunately, I can't reproduce the issue with a simple testcase.

The issue might be due to the progress bar, which is kept at the
bottom of the xterm window while there is scrolling output above
it. This probably involves some special technique (margins?) that
could confuse xterm for the tracking of the selected text. Just a
supposition...

This is reproducible with the attached tty session in a 80x60 xterm,
to be played by "xterm -e ttyplay ttyrecord". Just double-click on
"Summary:", and scroll backward and forward...

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


ttyrecord
Description: Binary data

Bug#1074390: "SyntaxWarning: invalid escape sequence" with python 3.12

[Vincent Lefevre]

Control: tags -1 upstream fixed-upstream
Control: forwarded -1 
https://gitlab.gnome.org/GNOME/rhythmbox/-/merge_requests/188

On 2024-08-04 17:29:54 -0500, john faulk wrote:
> this bug appears to still exist in Trixie as of 8/4/20204, in version 3.4.7-2

Yes, it was reported against this version.

It is fixed upstream:

https://gitlab.gnome.org/GNOME/rhythmbox/-/merge_requests/188
"Fix Python3 invalid escape sequences."

(merged on July 18), which references this Debian bug.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1077886: xterm: spurious characters in reverse video in scrollback buffer

[Vincent Lefevre]

On 2024-08-04 18:56:11 -0400, Thomas Dickey wrote:
> On Sun, Aug 04, 2024 at 03:34:12AM +0200, Vincent Lefevre wrote:
> > Some characters in the scrollback buffer can appear in reverse video.
> > But after scrolling again, they appear as normal, even when there was
> > no output.
> 
> so...
> 
> a) is this something that you can reproduce?

No, but after thinking about it, I now suppose that what occurred
is the following issue, which I can reproduce with

  apt install --reinstall linux-image-6.1.0-18-amd64 
linux-headers-6.1.0-18-amd64

(which recompiles the drivers, so generates some output).

It is possible that I had selected some text, so that this text was
in reverse video, then I forgot about it. But when there is output,
some other part of the text becomes in reverse video, hence my
surprise about random text being in reverse video when I was scrolling
backward.

I can reproduce that. It seems that this happens as soon as the
selection reaches the scrollback buffer. Note that the range of
columns of the part in reverse video remains the same, and despite
the change of the text in reverse video, the selection remains the
same when I paste it.

Unfortunately, I can't reproduce the issue with a simple testcase.

> b) were the characters in the scrollback supposed to be reversed, and then
>incorrectly reset?

The reverse video disappeared. But if this is the above issue with the
selection, the selection automatically disappears just by clicking in
the xterm, which I might have done.

> c) is this with bitmap fonts, or TrueType?

Vector fonts, so TrueType? But I can reproduce the above selection
issue with bitmap fonts too.

> d) there's no screenshot or other clue to see how to proceed.

The above command should give a hint.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1077961: zathura: useless message about the database on a new machine

[Vincent Lefevre]

Package: zathura
Version: 0.5.8-1
Severity: normal

I've just installed zathura on a new machine (Debian/unstable),
i.e. it does not come from an upgrade.

Each time I run it, I get the following useless message:

info: Opening plain database via sqlite backend.
info: No plain database available. Continuing with sqlite database.

IMHO, for new installations, the sqlite database should be the default.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.9.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages zathura depends on:
ii  libc62.39-6
ii  libcairo21.18.0-3+b1
ii  libgirara-gtk3-4 0.4.4-1
ii  libglib2.0-0t64  2.81.1-3
ii  libgtk-3-0t643.24.43-1
ii  libjson-glib-1.0-0   1.8.0-2+b1
ii  libmagic1t64 1:5.45-3
hi  libpango-1.0-0   1.51.0+ds-4
ii  libseccomp2  2.5.5-1+b1
ii  libsqlite3-0 3.46.0-1
ii  libsynctex2  2024.20240313.70630+ds-4
ii  zathura-pdf-poppler  0.3.3-1

zathura recommends no packages.

Versions of packages zathura suggests:
ii  elinks [www-browser]   0.17.0-2
ii  firefox [www-browser]  128.0.3-2
ii  firefox-esr [www-browser]  115.13.0esr-2
ii  links [www-browser]2.29-1+b3
ii  links2 [www-browser]   2.29-1+b3
ii  lynx [www-browser] 2.9.2-1
ii  w3m [www-browser]  0.5.3+git20230121-2+b3
pn  zathura-cb 
pn  zathura-djvu   
pn  zathura-ps 

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1077886: xterm: spurious characters in reverse video in scrollback buffer

[Vincent Lefevre]

Package: xterm
Version: 393-1
Severity: normal

Some characters in the scrollback buffer can appear in reverse video.
But after scrolling again, they appear as normal, even when there was
no output.

This occurred while I was upgrading packages with apt on a remote
machine (via ssh in xterm), perhaps due to the progress bar, which
uses reverse video. But this was still occurring after the upgrade
terminated (so there was no output at this time).

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.9.12-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xterm depends on:
ii  libc6   2.39-6
ii  libfontconfig1  2.15.0-1.1
ii  libfreetype62.13.2+dfsg-1+b4
ii  libice6 2:1.0.10-1+b1
ii  libtinfo6   6.5-2
ii  libutempter01.2.1-3+b1
ii  libx11-62:1.8.7-1+b1
ii  libxaw7 2:1.0.14-1+b2
ii  libxext62:1.3.4-1+b1
ii  libxft2 2.3.6-1+b1
ii  libxinerama12:1.1.4-3+b1
ii  libxmu6 2:1.1.3-3+b2
ii  libxpm4 1:3.5.17-1+b1
ii  libxt6t64   1:1.2.1-1.2
ii  xbitmaps1.1.1-2.2

Versions of packages xterm recommends:
ii  luit [luit]  2.0.20221028-1
ii  x11-utils7.7+6+b1

Versions of packages xterm suggests:
pn  xfonts-cyrillic  

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1072063: one of the external monitors randomly blank for 2-3 seconds with 6.8/6.9 Linux kernels (regression)

[Vincent Lefevre]

Control: found -1 6.9.12-1
Control: forwarded -1 
https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11821

On 2024-07-31 20:21:12 +0200, Ben Hutchings wrote:
> Could you please report this upstream following
> ?

Done: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11821

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1077587: still occurs (reply to Sylvestre Ledru ) (Bug#1077587: fixed in llvm-toolchain-18 1:18.1.8-8)

[Vincent Lefevre]

On 2024-08-01 14:02:15 +0200, Vincent Lefevre wrote:
> On 2024-07-30 09:39:08 +, Debian Bug Tracking System wrote:
> > Changes:
> >  llvm-toolchain-18 (1:18.1.8-8) unstable; urgency=medium
> >  .
> >* Fix breaks/replaces (Closes: #1077587)
> 
> Package: llvm-18-dev
> Source: llvm-toolchain-18
> Version: 1:18.1.8-8
> Installed-Size: 334825
> Maintainer: LLVM Packaging Team 
> Architecture: amd64
> Depends: libffi-dev, llvm-18 (= 1:18.1.8-8), libllvm18 (= 1:18.1.8-8), 
> libncurses-dev, llvm-18-tools (= 1:18.1.8-8), libclang-cpp18 (= 1:18.1.8-8), 
> libz3-dev, libxml2-dev
> [...]
> 
> There are no breaks/replaces. So, still the same error:
> 
> Unpacking llvm-18-dev (1:18.1.8-8) over (1:18.1.8-5) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-fbXaHi/14-llvm-18-dev_1%3a18.1.8-8_amd64.deb (--unpack):
>  trying to overwrite '/usr/lib/llvm-18/lib/libLLVM-18.so.1', which is also in 
> package libllvm18:amd64 1:18.1.8-5

The breaks/replaces have been added on libllvm18, while the issue
is for llvm-18-dev (assuming that libLLVM-18.so.1 is now intended
to be in llvm-18-dev).

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1077587: still occurs (reply to Sylvestre Ledru ) (Bug#1077587: fixed in llvm-toolchain-18 1:18.1.8-8)

[Vincent Lefevre]

Control: reopen -1
Control: found -1 1:18.1.8-8

On 2024-07-30 09:39:08 +, Debian Bug Tracking System wrote:
> Changes:
>  llvm-toolchain-18 (1:18.1.8-8) unstable; urgency=medium
>  .
>* Fix breaks/replaces (Closes: #1077587)

Package: llvm-18-dev
Source: llvm-toolchain-18
Version: 1:18.1.8-8
Installed-Size: 334825
Maintainer: LLVM Packaging Team 
Architecture: amd64
Depends: libffi-dev, llvm-18 (= 1:18.1.8-8), libllvm18 (= 1:18.1.8-8), 
libncurses-dev, llvm-18-tools (= 1:18.1.8-8), libclang-cpp18 (= 1:18.1.8-8), 
libz3-dev, libxml2-dev
[...]

There are no breaks/replaces. So, still the same error:

Unpacking llvm-18-dev (1:18.1.8-8) over (1:18.1.8-5) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-fbXaHi/14-llvm-18-dev_1%3a18.1.8-8_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/llvm-18/lib/libLLVM-18.so.1', which is also in 
package libllvm18:amd64 1:18.1.8-5

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1021533: pinfo: cat: /usr/share/info/python3.10: Is a directory

[Vincent Lefevre]

Control: retitle -1 pinfo: "pinfo " fails if  also exists 
as a directory

On 2022-10-10 11:31:57 +0200, Jakub Wilk wrote:
>$ pinfo python3.10
>Przemek's Info Viewer v0.6.13
>cat: /usr/share/info/python3.10: Is a directory
>Failed to execute command 'cat /usr/share/info/python3.10> 
> /tmp/pinfo.pkwiHn': 1

Ditto with "pinfo emacs". This is because /usr/share/info contains
both the info file ("emacs.info.gz") and a directory with that name
("emacs").

There's also the same issue if it exists as any file.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1077605: pinfo: copies a file from the current directory to /tmp

[Vincent Lefevre]

Package: pinfo
Version: 0.6.13-1.3+b1
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: Debian Security Team 

When running "pinfo mpfr", I can see in the strace output:

execve("/bin/sh", ["sh", "-c", "--", "cat ./mpfr> /tmp/pinfo.tVVaeB"], 
0x7ffc16308110 /* 135 vars */ 

This is the case including when the argument is a symbolic link.

This means that private data can end up in /tmp (the file seems
private by default as created with 0600, but the fact that it can
escape the original file system is bad).

This is also bad in case of a symbolic link to some special file,
such as a dev file.

Like "info" and "man", pinfo should not look into the current
directory (except explicitly requestion via the INFOPATH
environment variable).

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.9.12-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pinfo depends on:
ii  install-info 7.1-3+b1
ii  libc62.39-6
ii  libncursesw6 6.5-2
ii  libreadline8t64  8.2-4
ii  libtinfo66.5-2

pinfo recommends no packages.

pinfo suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1077587: llvm-18-dev: tries to overwrite '/usr/lib/llvm-18/lib/libLLVM-18.so.1', which is also in libllvm18 1:18.1.8-5

[Vincent Lefevre]

Package: llvm-18-dev
Version: 1:18.1.8-7
Severity: serious

When upgrading the llvm-toolchain-18 packages:

Unpacking llvm-18-dev (1:18.1.8-7) over (1:18.1.8-5) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-LjdMdY/04-llvm-18-dev_1%3a18.1.8-7_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/llvm-18/lib/libLLVM-18.so.1', which is also in 
package libllvm18:amd64 1:18.1.8-5

Similar to bug 1076469 in 1:18.1.8-3 (fixed in 1:18.1.8-4).

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.9.11-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages llvm-18-dev depends on:
ii  libclang-cpp18  1:18.1.8-7
ii  libffi-dev  3.4.6-1
ii  libllvm18   1:18.1.8-7
ii  libncurses-dev  6.5-2
ii  libxml2-dev 2.12.7+dfsg-3+b1
ii  libz3-dev   4.8.12-3.1+b2
ii  llvm-18 1:18.1.8-7
ii  llvm-18-tools   1:18.1.8-7

llvm-18-dev recommends no packages.

llvm-18-dev suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1076582: Bug#1077274: Excessive initramfs size with firmware-nvidia-graphics and plymouth

[Vincent Lefevre]

On 2024-07-29 15:59:14 +0200, Rodrigo Campos wrote:
> On 7/28/24 10:33 PM, Ben Hutchings wrote:
> > This issue was fixed by initramfs-tools version 0.143 in experimental.
> > I have just uploaded version 0.143.1 to unstable, so you should be able
> > to get the fix through a regular upgrade in a few hours (if using
> > unstable) or days (if using testing).
> 
> I've tested it and seems to work fine for me. Thanks!

Currently, this works for me too. But if the temporary backup
is still stored in /boot, there may be issues in the future
once all the initrd files become bigger.

Unfortunately I need the firmware-nvidia-graphics package.
But I'm wondering how this worked before the 40 MB increase!
There must be lots of things there I actually don't need.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1076582: Processed (with 1 error): tagging 1076539, forcibly merging 1076582 1076539

[Vincent Lefevre]

Control: notfixed -1 0.143
Control: fixed -1 initramfs-tools/0.143

There's a bug in the BTS software, which forgot the source package
name for bug 1076582.

On 2024-07-28 20:27:17 +, Debian Bug Tracking System wrote:
> After four attempts, the following changes were unable to be made:
> fixed_versions of #1076695 is 'initramfs-tools/0.143' not '0.143'
> fixed_versions of #1077274 is 'initramfs-tools/0.143' not '0.143'
> fixed_versions of #1076539 is 'initramfs-tools/0.143' not '0.143'
> fixed_versions of #1076561 is 'initramfs-tools/0.143' not '0.143'
> Failed to forcibly merge 1076582: Unable to modify bugs so they could be 
> merged.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#929777: Bug#1076503: Removed package(s) from unstable

[Vincent Lefevre]

On 2024-07-28 15:35:35 +, Debian FTP Masters wrote:
> Version: 10.5.0-4+rm
> 
> Dear submitter,
> 
> as the package gcc-10 has just been removed from the Debian archive
> unstable we hereby close the associated bug reports.  We are sorry
> that we couldn't deal with your issue properly.
[...]

No need to reassign this bug or open a new one: it was fixed for
GCC 12 (see upstream bug).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#930430: Bug#1076502: Removed package(s) from unstable

[Vincent Lefevre]

Control: reopen -1
Control: reassign -1 libasan8 14.1.0-5

On 2024-07-28 15:27:28 +, Debian FTP Masters wrote:
> Version: 9.5.0-6+rm
> 
> Dear submitter,
> 
> as the package gcc-9 has just been removed from the Debian archive
> unstable we hereby close the associated bug reports.  We are sorry
> that we couldn't deal with your issue properly.
[...]

Instead of closing the bug, let's reassign it to the current
package name (the problem is still there).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1075301: mutt: ftbfs with GCC-14

[Vincent Lefevre]

On 2024-07-03 12:37:27 +, Matthias Klose wrote:
> gcc -DPKGDATADIR=\"/usr/share/mutt\" -DSYSCONFDIR=\"/etc\" 
> -DBINDIR=\"/usr/bin\" -DMUTTLOCALEDIR=\"/usr/share/locale\" -DHAVE_CONFIG_H=1 
> -I. -I../..  -I. -I../.. -I../../imap-Wdate-time -D_FORTIFY_SOURCE=2 
> -isystem /usr/include/mit-krb5  -Wall -pedantic -Wno-long-long -g -O2 
> -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -fstack-clash-protection -Wformat 
> -Werror=format-security -fcf-protection -c -o buffy.o ../../buffy.c
> ../../attach.c: In function ‘mutt_view_attachment’:
> ../../attach.c:392:14: error: passing argument 1 of ‘chmod’ from incompatible 
> pointer type [-Wincompatible-pointer-types]
>   392 |   chmod (tempfile, 0400);
>   |  ^~~~
>   |  |
>   |  BUFFER *
> In file included from ../../mutt.h:30,
>  from ../../attach.c:24:
> /usr/include/x86_64-linux-gnu/sys/stat.h:352:31: note: expected ‘const char 
> *’ but argument is of type ‘BUFFER *’
>   352 | extern int chmod (const char *__file, __mode_t __mode)
>   |   ^~
> ../../attach.c:604:11: error: passing argument 1 of ‘chmod’ from incompatible 
> pointer type [-Wincompatible-pointer-types]
>   604 | chmod(tempfile, 0600);
>   |   ^~~~
>   |   |
>   |   BUFFER *
> /usr/include/x86_64-linux-gnu/sys/stat.h:352:31: note: expected ‘const char 
> *’ but argument is of type ‘BUFFER *’
>   352 | extern int chmod (const char *__file, __mode_t __mode)
>   |   ^~

This code comes from the following patch:
upstream/528233-readonly-open.patch

which dates back to 2014. But in 2018, the type of tempfile changed:

commit c619d5cbc428de3632c55bac2e79c7b06d6a030a
Author: Kevin McCarthy 
Date:   2018-10-14 21:52:30 +0200

Convert mutt_get_tmp_attachment to use BUFFER.

diff --git a/attach.c b/attach.c
index 2a2661f4..89574f50 100644
--- a/attach.c
+++ b/attach.c
@@ -46,38 +46,46 @@
 int mutt_get_tmp_attachment (BODY *a)
 {
   char type[STRING];
-  char tempfile[_POSIX_PATH_MAX];
-  rfc1524_entry *entry = rfc1524_new_entry();
+  BUFFER *tempfile = NULL;
+  rfc1524_entry *entry = NULL;
[...]

and the patch became incorrect as a consequence (BUFFER is a struct).
If this was still working, this was only by chance. Since the meaning
of a pointer changed, this could give memory corruption and things
like that.

Here, it seems that in the patch, "tempfile" should be replaced by
"mutt_b2s (tempfile)", because the current code also has

  safe_fopen(mutt_b2s (tempfile), "w")

and

  mutt_rename_file (mutt_b2s (tempfile), a->filename)

It happens that with the chosen structure, this does not change the
address:

/* Convert a buffer to a const char * "string" */
#define mutt_b2s(b) (b->data ? (const char *)b->data : "")

and data is the first field of the structure:

typedef struct
{
  char *data;   /* pointer to data */
  char *dptr;   /* current read/write position */
  size_t dsize; /* length of data */
} BUFFER;

But this could have been different.

I'm wondering why the code still compiled at that time.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1077187: procps: please drop/replace the obsolete sysctl.conf(5) man page

[Vincent Lefevre]

On 2024-07-26 15:27:25 +0200, Vincent Lefevre wrote:
> The sysctl.conf(5) man page is still there and yields confusion.
> 
>sysctl.conf - sysctl preload/configuration file
> [...]
>/etc/sysctl.conf
> 
> It should be dropped or replaced under a new name, with up-to-date
> information.

Since systemd already provides /usr/share/man/man5/sysctl.d.5.gz,
I suppose that the sysctl.conf(5) man page should be dropped,
and any reference to it (e.g. in /etc/sysctl.d/README.sysctl)
should be removed.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1077187: procps: please drop/replace the obsolete sysctl.conf(5) man page

[Vincent Lefevre]

Package: procps
Version: 2:4.0.4-5
Severity: normal

The sysctl.conf(5) man page is still there and yields confusion.

   sysctl.conf - sysctl preload/configuration file
[...]
   /etc/sysctl.conf

It should be dropped or replaced under a new name, with up-to-date
information.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.9.10-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages procps depends on:
ii  init-system-helpers  1.66
ii  libc62.39-6
ii  libncursesw6 6.5-2
ii  libproc2-0   2:4.0.4-5
ii  libsystemd0  256.2-1
ii  libtinfo66.5-2

Versions of packages procps recommends:
ii  linux-sysctl-defaults  4.10.1
ii  psmisc 23.7-1

procps suggests no packages.

-- Configuration Files:
/etc/sysctl.conf changed [not included]

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1076352: procps: leftover conffiles

[Vincent Lefevre]

Control: severity -1 serious

Raising to serious because systemd has now removed the
/etc/sysctl.d/99-sysctl.conf symlink, which yields *silent* breakage.

Make sure that the end user is aware of this change.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1077184: systemd: /etc/sysctl.conf is no longer read

[Vincent Lefevre]

Package: systemd
Version: 256.4-2
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: Debian Security Team 

The /etc/sysctl.conf file is no longer read, while I have security
settings there.

I suspect that the cause is

  * Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships
/etc/sysctl.conf (Closes: #1076190)

which is wrong!

cventin:~> dpkg -S /etc/sysctl.conf
procps: /etc/sysctl.conf

with procps 2:4.0.4-5.

Perhaps procps no longer ships /etc/sysctl.conf *by default*, but
existing installations still have it (a machine I installed in
January still has this file).

-- Package-specific info:

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.9.10-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  libacl12.3.2-2
ii  libapparmor1   3.1.7-1+b1
ii  libaudit1  1:3.1.2-4+b1
ii  libblkid1  2.40.2-1
ii  libc6  2.39-6
ii  libcap21:2.66-5
ii  libmount1  2.40.2-1
ii  libpam0g   1.5.3-7
ii  libseccomp22.5.5-1+b1
ii  libselinux13.5-2+b3
ii  libssl3t64 3.2.2-1
ii  libsystemd-shared  256.4-2
ii  libsystemd0256.4-2
ii  mount  2.40.2-1

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.14.10-4+b1
ii  libzstd1 1.5.6+dfsg-1
ii  linux-sysctl-defaults4.10.1
ii  systemd-cryptsetup   256.4-2
ii  systemd-timesyncd [time-daemon]  256.4-2

Versions of packages systemd suggests:
ii  libcryptsetup12   2:2.7.2-2
ii  libgcrypt20   1.11.0-2
ii  libidn2-0 2.3.7-2
ii  liblz4-1  1.9.4-3
ii  liblzma5  5.6.2-2
pn  libtss2-rc0t64
pn  libtss2-tcti-device0  
ii  polkitd   124-3
pn  systemd-boot  
pn  systemd-container 
pn  systemd-homed 
pn  systemd-repart
pn  systemd-resolved  
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.10-4+b1
pn  dracut 
ii  initramfs-tools0.142
ii  libnss-systemd 256.4-2
ii  libpam-systemd 256.4-2
ii  udev   256.4-2

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1077048: /usr/share/gtk-doc/python/gtkdoc/scan.py: warnings with python3.12

[Vincent Lefevre]

Package: gtk-doc-tools
Version: 1.34.0-1
Severity: normal

During upgrade, I get the following warnings for
/usr/share/gtk-doc/python/gtkdoc/scan.py:

Setting up python3 (3.12.4-1) ...
running python rtupdate hooks for python3.12...
/usr/share/gtk-doc/python/gtkdoc/scan.py:44: SyntaxWarning: invalid escape 
sequence '\s'
  VAR_TYPE_MODIFIER = '(?:' + '|'.join([t + '\s+' for t in TYPE_MODIFIERS]) + 
')*'
/usr/share/gtk-doc/python/gtkdoc/scan.py:45: SyntaxWarning: invalid escape 
sequence '\s'
  RET_TYPE_MODIFIER = '(?:' + '|'.join([t + '\s+' for t in TYPE_MODIFIERS + 
['G_CONST_RETURN']]) + ')*'
/usr/share/gtk-doc/python/gtkdoc/scan.py:238: SyntaxWarning: invalid escape 
sequence '\('
  ignore_decorators = '|' + options.ignore_decorators.replace('()', '\(\w*\)')
/usr/share/gtk-doc/python/gtkdoc/scan.py:239: SyntaxWarning: invalid escape 
sequence '\s'
  optional_decorators_regex = '(?:\s+(?:%s))?' % ignore_decorators[1:]
/usr/share/gtk-doc/python/gtkdoc/scan.py:487: SyntaxWarning: invalid escape 
sequence '\('
  ignore_decorators = '|' + options.ignore_decorators.replace('()', '\(\w*\)')
/usr/share/gtk-doc/python/gtkdoc/scan.py:488: SyntaxWarning: invalid escape 
sequence '\s'
  optional_decorators_regex = '(?:\s+(?:%s))?' % ignore_decorators[1:]

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.9.9-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gtk-doc-tools depends on:
ii  docbook-to-man1:2.0.0-47
ii  docbook-xml   4.5-13
ii  docbook-xsl   1.79.2+dfsg-7
ii  pkgconf   1.8.1-3
ii  python3   3.12.4-1
ii  python3-lxml  5.2.2-1
ii  python3-pygments  2.18.0+dfsg-1
ii  xsltproc  1.1.35-1.1

gtk-doc-tools recommends no packages.

Versions of packages gtk-doc-tools suggests:
ii  dblatex  0.3.12py3-4

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#932360: systemctl daemon-reload not added in postinst script in --no-start --no-restart-after-upgrade case

[Vincent Lefevre]

On 2019-07-18 16:50:20 +0200, Michael Biebl wrote:
> My idea was, to avoid unnecessary daemon-reloads as much as possible.
> 
> If your use case is, that at some point in the future, the user might
> (re)start the service, then it is sufficient if we do a single
> daemon-reload after the dpkg run.
> 
> Let's say we have 10 packages using "--no-start
> --no-restart-after-upgrade", then a single daemon-reload at the end
> would be sufficient instead of having to directly call daemon-reload
> from postinst.
> 
> On the other hand, having a dpkg file-trigger for /lib/system/system
> would mean we trigger daemon-reload at least twice for the common case
> (one via postinst and one via file trigger).

In any case, reloading daemons during the upgrade process is current
buggy as this can yield a race for the dpkg frontend lock:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070027

Depending on which gets the lock first:
  * This can make (at least) aptitude fail, leaving the system
in an inconsistent state.
  * This can make the apt.systemd.daily script fail.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1070027: in package dpkg marked as pending

[Vincent Lefevre]

On 2024-07-25 11:49:42 +0200, Vincent Lefevre wrote:
> The reload is triggered with just
> 
>   dpkg -i /var/cache/apt/archives/dpkg_1.22.9_amd64.deb
> 
> so aptitude and even apt aren't even involved in this bug:
> 
> Jul 25 11:47:56 qaa systemd[1]: Reload requested from client PID 333083 
> ('systemctl') (unit session-2.scope)...
> Jul 25 11:47:56 qaa systemd[1]: Reloading...
> Jul 25 11:47:56 qaa systemd[1]: Reloading finished in 139 ms.

And if the timer time has been reached, the apt-daily service is run.

To try to reproduce the issue, I've copied

  /usr/lib/systemd/system/apt-daily.service
  /usr/lib/systemd/system/apt-daily.timer

into /etc/systemd/system and edited them.

For /etc/systemd/system/apt-daily.service, I've changed the ExecStart
script pathname and edited the copy of the apt.systemd.daily script to
set VERBOSE=1 and ducplicate the following lines

# check if we can lock the cache and if the cache is clean
if command -v apt-get >/dev/null && ! eval apt-get check $XAPTOPT $XSTDERR ; 
then
debug_echo "error encountered in cron job with \"apt-get check\"."
exit 0
fi

6 times (as "apt-get check" attempts to lock the cache, thus
giving more chance of failure).

For /etc/systemd/system/apt-daily.timer, I've changed the following
lines to get

OnCalendar=*-*-* *:*:00
RandomizedDelaySec=1m

thus reaching the timer time more often.

Now, whether I use

  aptitude reinstall dpkg dpkg-dev
or
  apt install --reinstall dpkg dpkg-dev
or
  dpkg -i /var/cache/apt/archives/dpkg_1.22.9_amd64.deb \
  /var/cache/apt/archives/dpkg-dev_1.22.9_all.deb

I can get a failure in the apt.systemd.daily script:

Jul 25 12:59:17 qaa systemd[1]: Starting apt-daily.service - Daily apt download 
activities...
Jul 25 12:59:17 qaa apt.systemd.daily[370789]: error encountered in cron job 
with "apt-get check".
Jul 25 12:59:17 qaa systemd[1]: apt-daily.service: Deactivated successfully.
Jul 25 12:59:17 qaa systemd[1]: Finished apt-daily.service - Daily apt download 
activities.

With VERBOSE=2, I could get more details about this failure:

Jul 25 13:22:16 qaa systemd[1]: Starting apt-daily.service - Daily apt download 
activities...
Jul 25 13:22:16 qaa apt.systemd.daily[378644]: E: Could not get lock 
/var/lib/dpkg/lock-frontend. It is held by process 378454 (apt)
Jul 25 13:22:16 qaa apt.systemd.daily[378644]: E: Unable to acquire the dpkg 
frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
Jul 25 13:22:16 qaa apt.systemd.daily[378637]: error encountered in cron job 
with "apt-get check".
Jul 25 13:22:16 qaa systemd[1]: apt-daily.service: Deactivated successfully.
Jul 25 13:22:16 qaa systemd[1]: Finished apt-daily.service - Daily apt download 
activities.

Here, the failure occurs in the apt.systemd.daily, because the
process used for the upgrade got the lock first. But it could
be the other way round, as this could be seen with aptitude.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1070027: in package dpkg marked as pending

[Vincent Lefevre]

Control: retitle -1 dpkg failure at "Setting up" due to dpkg frontend lock by 
apt-get via apt-daily.service

On 2024-07-25 11:03:50 +0200, Vincent Lefevre wrote:
> According to the journalctl output:
> 
> Jul 25 10:30:36 qaa systemd[1]: Reload requested from client PID 326242 
> ('systemctl') (unit session-2.scope)...
> Jul 25 10:30:36 qaa systemd[1]: Reloading...
> Jul 25 10:30:37 qaa systemd[1]: Reloading finished in 153 ms.
> Jul 25 10:30:37 qaa systemd[1]: Starting apt-daily.service - Daily apt 
> download activities...
> Jul 25 10:30:37 qaa systemd[1]: apt-daily.service: Deactivated successfully.
> Jul 25 10:30:37 qaa systemd[1]: Finished apt-daily.service - Daily apt 
> download activities.
> 
> but again, I did *not* do a systemctl. So either systemd is completely
> broken, or perhaps the systemctl was done by dpkg itself.

In /var/lib/dpkg/info/dpkg.postinst I can see

systemctl --system daemon-reload >/dev/null || true

I'm wondering whether this is the cause.

This line is there due to

# Due to #932360 in debhelper we need to explicitly tell systemd to reload.

> Note that in this latter case (I would not be surprised, because
> when this happens, this is *always* during an upgrade), even if
> aptitude had some fix of frontend locking, there would still be a
> conflict between aptitude and dpkg, both leading to a request a
> lock.

The reload is triggered with just

  dpkg -i /var/cache/apt/archives/dpkg_1.22.9_amd64.deb

so aptitude and even apt aren't even involved in this bug:

Jul 25 11:47:56 qaa systemd[1]: Reload requested from client PID 333083 
('systemctl') (unit session-2.scope)...
Jul 25 11:47:56 qaa systemd[1]: Reloading...
Jul 25 11:47:56 qaa systemd[1]: Reloading finished in 139 ms.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1070027: in package dpkg marked as pending

[Vincent Lefevre]

Control: reopen -1
Control: severity -1 important

On 2024-07-11 00:49:20 +0200, Guillem Jover wrote:
> libdpkg: Try to print the executable name of the lock contending process
> 
> Just printing the PID is not very useful to try to track down the
> contending process as its presence might be momentary and might no
> longer be present when the user tries to look for that specific PID.
> 
> Try to get the executable name to give a better hint to what might be
> going wrong.
> 
> Closes: #1070027

Since the problem occurred again, this time on the dpkg upgrade itself:

Unpacking dpkg (1.22.9) over (1.22.7) ...
Setting up dpkg (1.22.9) ...
dpkg: error: dpkg frontend lock was locked by /usr/bin/apt-get process with pid 
326336

But this is rather useless information. Perhaps it should also
write the full "ps -ef" output (something like that) to a file,
though this may be too late.

According to the journalctl output:

Jul 25 10:30:36 qaa systemd[1]: Reload requested from client PID 326242 
('systemctl') (unit session-2.scope)...
Jul 25 10:30:36 qaa systemd[1]: Reloading...
Jul 25 10:30:37 qaa systemd[1]: Reloading finished in 153 ms.
Jul 25 10:30:37 qaa systemd[1]: Starting apt-daily.service - Daily apt download 
activities...
Jul 25 10:30:37 qaa systemd[1]: apt-daily.service: Deactivated successfully.
Jul 25 10:30:37 qaa systemd[1]: Finished apt-daily.service - Daily apt download 
activities.

but again, I did *not* do a systemctl. So either systemd is completely
broken, or perhaps the systemctl was done by dpkg itself. Note that in
this latter case (I would not be surprised, because when this happens,
this is *always* during an upgrade), even if aptitude had some fix of
frontend locking, there would still be a conflict between aptitude and
dpkg, both leading to a request a lock.

The PPID (with the process name) of 326242 would have been useful,
but systemd does not give it.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1076944: w3m: with -dump and large -cols, w3m inserts line breaks at column 1024 or before

[Vincent Lefevre]

Package: w3m
Version: 0.5.3+git20230121-2+b3
Severity: normal

With -dump and large -cols, w3m inserts line breaks to make lines
no longer than 1024 characters.

Testcase:

$ { echo "" ; seq 2000 ; } > a.html
$ w3m -dump -cols 99 a.html

w3m inserts a line break after 283, 539, 795, 1040, 1244, 1448, 1652
and 1856 instead of outputting a single line.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
(500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.9.10-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages w3m depends on:
ii  libc6   2.39-6
ii  libgc1  1:8.2.6-2
ii  libgpm2 1.20.7-11
ii  libssl3t64  3.2.2-1
ii  libtinfo6   6.5-2
ii  zlib1g  1:1.3.dfsg+really1.3.1-1

Versions of packages w3m recommends:
ii  ca-certificates  20240203

Versions of packages w3m suggests:
pn  brotli  
ii  bzip2   1.0.8-5.1
pn  cmigemo 
pn  compface
ii  curl8.8.0-4
ii  dict1.13.1+dfsg-1
ii  dict-wn 1:3.0-37
ii  dictd   1.13.1+dfsg-1
pn  libsixel-bin
hi  mailcap 3.70+nmu1
ii  man-db  2.12.1-2
ii  media-types 10.1.0
ii  sensible-utils  0.0.24
ii  w3m-el  1.4.632+0.20210201.2305.54c3ccd-3
ii  w3m-img 0.5.3+git20230121-2+b3
ii  wget1.24.5-1
ii  xdg-utils   1.1.3-4.1
pn  xsel

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)