Bug#1071576: bugs.debian.org: bug subscription no longer possible: no "Please confirm subscription" e-mail

[Vincent Lefevre]

On 2024-05-21 14:45:02 -0400, David Mandelberg wrote:
> I'm having the same problem. Could it be related to #1071469 which also
> involves mail issues around the same time?

At https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071469
Louis-Philippe Véronneau says

"It seems that a debian.org mail infrastructure breakage happened 
sometime between 2024-05-17 and 2024-05-18"

and

"I dug a little bit more and it seems the outage happened between
2024-05-17 ~2200 and and 2024-05-18 0110UTC."

But since the outage ended on 2024-05-18 (and the issue with bug
subscription seemed to have started before the outage), this seems
to be a different problem... unless someone did a series of changes
in the mail config on 2024-05-17 and early 2024-05-18.

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

Bug#1071576: bugs.debian.org: bug subscription no longer possible: no "Please confirm subscription" e-mail

[Vincent Lefevre]

On 2024-05-21 15:04:44 +0200, Vincent Lefevre wrote:
> It is no longer possible to subscribe to bugs as
> "Please confirm subscription" e-mail messages are no longer sent.
> 
> On 2024-05-10, this was working, but since 2024-05-20 at least,
> this is no longer working. I had sent:
> 
> From: Vincent Lefevre 
> To: 1071372-subscr...@bugs.debian.org
> Subject: subscribe
> Date: Mon, 20 May 2024 00:56:07 +0200
> Message-ID: <20240519225607.ge2...@qaa.vinc17.org>
> 
> The issue remains with attempts today (2024-05-21) at 14:26:56 +0200
> and 14:47:15 +0200 for another bug.

Actually, after a look at the logs on my mail server, this was still
working at the following date:

2024-05-11T11:57:13.575225+02:00 joooj postfix/smtp[74387]: AB7C1812: 
to=<1070891-subscr...@bugs.debian.org>, 
relay=buxtehude.debian.org[2607:f8f0:614:1::1274:39]:25, delay=3.9, 
delays=0.04/0.11/2.8/0.89, dsn=2.0.0, status=sent (250 OK id=1s5jTe-00BPwE-Lt)

with a reply ("Please confirm subscription" e-mail):

2024-05-11T12:00:14.976146+02:00 joooj postfix/qmgr[70857]: E359C13E: 
from=<1070891-ign...@bugs.debian.org>, size=4289, nrcpt=1 (queue active)

But this was no longer working at the following date:

2024-05-17T15:51:22.974407+02:00 joooj postfix/smtp[164605]: 8556DACB: 
to=<1071274-subscr...@bugs.debian.org>, 
relay=buxtehude.debian.org[209.87.16.39]:25, delay=4.4, 
delays=0.03/0.04/3.4/0.94, dsn=2.0.0, status=sent (250 OK id=1s7xzY-00CaPs-2o)

(I did not get the reply).

-- 
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#1071576: bugs.debian.org: bug subscription no longer possible: no "Please confirm subscription" e-mail

[Vincent Lefevre]

Package: bugs.debian.org
Severity: important

It is no longer possible to subscribe to bugs as
"Please confirm subscription" e-mail messages are no longer sent.

On 2024-05-10, this was working, but since 2024-05-20 at least,
this is no longer working. I had sent:

From: Vincent Lefevre 
To: 1071372-subscr...@bugs.debian.org
Subject: subscribe
Date: Mon, 20 May 2024 00:56:07 +0200
Message-ID: <20240519225607.ge2...@qaa.vinc17.org>

The issue remains with attempts today (2024-05-21) at 14:26:56 +0200
and 14:47:15 +0200 for another bug.

-- 
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#1071372: emacs: it hangs saving .gpg files (without using cpu)

[Vincent Lefevre]

On 2024-05-20 01:03:00 +0200, Vincent Lefevre wrote:
> The issue remains after downgrading the emacs packages to testing
> (1:29.3+1-2).

And it disappears after downgrading the packages of gnupg2 source
to 2.2.40-3.

The issue about the file disappearing does not occur with "emacs -Q"
(I'll have to find the exact cause). This is a more general issue,
but this bug about emacs hanging just makes it much worse.

I'm using

(defun find-backup-file-name (fn)
   (list (concat "~/.poub/" (file-name-nondirectory fn) "~")))

and there's actually a backup there, but this should be regarded as
very temporary, as I sometimes clean up this directory. Files should
never expected to be *only* there. I suspect wrong logic in Emacs,
because with the downgraded gnupg, the file disappearance occurs
only after the first save (according to strace, Emacs does a rename
to create the backup instead of copying the file).

-- 
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#1071372: emacs: it hangs saving .gpg files (without using cpu)

[Vincent Lefevre]

Control: found -1 1:29.3+1-2

On 2024-05-20 00:45:40 +0200, Vincent Lefevre wrote:
> On 2024-05-18 01:22:03 +0200, Alex Andreotti wrote:
> > [...] Probably a "recent" apt upgrade broke it but I don't know
> > exactly which one, before this problem I used to save .gpg files
> > often
> 
> Here, there was no such issue on May 1, where I had emacs 1:29.3+1-2.
> But gnupg2 has also been upgraded from 2.2.40-3 to 2.2.43-3, though.

The issue remains after downgrading the emacs packages to testing
(1:29.3+1-2).

Note: When Emacs hangs, the gpg process is still running. Something
of the form:

  gpg --no-tty --status-fd 1 --yes --use-agent --enable-progress-filter 
--command-fd 0 --output epg-outputsyl2kr --encrypt -r ***

-- 
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#1071372: emacs: it hangs saving .gpg files (without using cpu)

[Vincent Lefevre]

Control: severity -1 critical

due to data loss.

I have the same issue. Worse, in one of my tests, where I tried
various things before quitting Emacs (without saving the file,
because this is just not possible due to this bug), like switching
the current buffer (which had no effect), the file got removed!
However, I can't reproduce that, and I don't remember what I did
exactly. I suspect that Emacs got in an inconsistent state.

Well, after typing "C-x C-s", the file is no longer there, and
I cannot see any backup! A C-g restores it, but apparently, not
after some condition. Anyway, the fact that the file is temporarily
removed is a major issue.

On 2024-05-18 01:22:03 +0200, Alex Andreotti wrote:
> Package: emacs
> Version: 1:29.3+1-3
> Severity: normal
> X-Debbugs-Cc: alex.andreo...@gmail.com
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> For years I have normally used emacs (GUI) to create gpg files (.org.gpg or 
> .md.gpg) where I save relatively sensitive information using a key installed 
> in the system (with password). Last week when I created a file and saved it, 
> emacs asked me to mark the key to use, and when I pressed OK to save the file 
> it hung. Probably a "recent" apt upgrade broke it but I don't know exactly 
> which one, before this problem I used to save .gpg files often

Here, there was no such issue on May 1, where I had emacs 1:29.3+1-2.
But gnupg2 has also been upgraded from 2.2.40-3 to 2.2.43-3, though.

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

Bug#1009665: ghostscript: with -dNEWPDF=false, the ToUnicode CMap sometimes has an incorrect mapping

[Vincent Lefevre]

On 2024-05-13 20:37:40 -0400, Alex Cherepanov wrote:
> The problem was in pdftotext, rather than ps2pdf.
> Starting from the v. 10.0.0 of Ghostscript, pdftotext
> produces correct output from the attached PDF file.

pdftotext is based on poppler. It doesn't use Ghostscript at all,
AFAIK.

In any case, pdftotext still produces the incorrect "Šê" with the
buggy PDF file generated by ps2pdf (attached).

Note: -dNEWPDF=false no longer has any effect with Ghostscript 10,
but according to upstream, there may still be issues with the new
PDF interpreter (indeed, I did find issues, which have been fixed
now, but there might still remain other ones).

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


chartest7-gs.pdf
Description: Adobe PDF document

Bug#1070891: apt-show-versions: Permission denied on a bad pathname

[Vincent Lefevre]

On 2024-05-14 09:47:02 +0200, Christoph Martin wrote:
> You could try to prepend strace to your cron call like:
> 
> strace -o /tmp/asv.$$ -e trace=file apt-show-versions -u
> 
> and look for the failed syscall.

The issue is that this is not reproducible, but see below.

> Did you look for selinux or apparmor messages in syslog?

No messages in the journalctl output.

The failure occurred on 2024-05-11 00:04:01 +0200.
In the journalctl output:

May 11 00:03:49 qaa su[315536]: (to root) vinc17 on pts/18
May 11 00:03:49 qaa su[315536]: pam_unix(su:session): session opened for user 
root(uid=0) by vinc17(uid=1000)
May 11 00:03:55 qaa accounts-daemon[1127]: Language 'C.utf8' set for user 
vinc17 is invalid
May 11 00:04:01 qaa CRON[316214]: pam_unix(cron:session): session opened for 
user vinc17(uid=1000) by vinc17(uid=0)
May 11 00:04:01 qaa CRON[316215]: (vinc17) CMD (apt-show-versions -u | grep 
manually)
May 11 00:04:01 qaa CRON[316214]: pam_unix(cron:session): session closed for 
user vinc17
May 11 00:04:01 qaa postfix/pickup[314458]: 6682BCA011C: uid=1000 from=
May 11 00:04:01 qaa postfix/cleanup[316242]: 6682BCA011C: 
message-id=<20240510220401.6682bca0...@qaa.vinc17.org>
May 11 00:04:01 qaa postfix/qmgr[2011]: 6682BCA011C: from=, 
size=750, nrcpt=1 (queue active)
May 11 00:04:01 qaa postfix/local[316244]: 6682BCA011C: 
to=, orig_to=, relay=local, delay=0.05, 
delays=0.03/0/0/0.02, dsn=2.0.0, status=sent (delivered to command: procmail -a 
"$EXTENSION")
May 11 00:04:01 qaa postfix/qmgr[2011]: 6682BCA011C: removed

Indeed, I have in my crontab:

4 */6 * * * apt-show-versions -u | grep manually

The mail message is due to the error (normally, there is none).

I logged as root a few seconds before, for an upgrade. I can see
in /var/log/apt/term.log:

Log started: 2024-05-11  00:13:28
[...]

So, perhaps I did an "apt update" around 00:04, and I can see with
"strace -f -o str.out apt update":

914566 
chmod("/var/lib/apt/lists/debug.mirrors.debian.org_debian-debug_dists_stable-debug_InRelease",
 0600) = 0

before doing later

914566 
chmod("/var/lib/apt/lists/debug.mirrors.debian.org_debian-debug_dists_stable-debug_InRelease",
 0644 

This could explain the error.

I'm wondering why apt plays with the permissions. This is confusing.
Or should there be a locking mechanism?

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

Bug#1070891: apt-show-versions: Permission denied on a bad pathname

[Vincent Lefevre]

On 2024-05-13 15:34:31 +0200, Vincent Lefevre wrote:
> > Which user does the cronjob run with?
> 
> root, AFAIK (the mail was from root).

Actually by the user (vinc17, i.e. me). I shouldn't have looked
at the "From:" header of the mail for that. Anyway, this shouldn't
matter because the permissions are "-rw-r--r--".

-- 
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#1070891: apt-show-versions: Permission denied on a bad pathname

[Vincent Lefevre]

On 2024-05-13 17:12:57 +0200, Christoph Martin wrote:
> Hi Vincent,
> 
> Am 13.05.24 um 15:34 schrieb Vincent Lefevre:
> 
> > > > I don't know why could cause the error, but the pathname with "//"
> > > > is incorrect.
> > > 
> > > // in the path should not be a problem.
> > 
> > zsh completion cannot handle it, so I was wondering.
> 
> Please try to access the file e.g. 'less 
> /var/lib/apt/lists//debug.mirrors.debian.org_debian-debug_dists_stable-debug_InRelease'

No problems.

> > > Can you do a 'ls -l /var/lib/apt/lists/' to see the permissions?
> > 
> > lrwxrwxrwx 1 root root   25 2024-05-11 22:36:06 
> > _var_local_apt_._Packages -> /var/local/apt/./Packages
> > drwxr-xr-x 2 _apt root 4096 2023-10-07 13:42:54 auxfiles
> > -rw-r--r-- 1 root root52957 2024-05-11 16:15:34 
> > debug.mirrors.debian.org_debian-debug_dists_proposed-updates-debug_InRelease
> > -rw-r--r-- 1 root root   308541 2024-05-08 22:34:42 
> > debug.mirrors.debian.org_debian-debug_dists_proposed-updates-debug_main_binary-amd64_Packages
> > -rw-r--r-- 1 root root49779 2024-02-10 12:17:11 
> > debug.mirrors.debian.org_debian-debug_dists_stable-debug_InRelease
> > -rw-r--r-- 1 root root 14314273 2024-02-10 10:44:17 
> > debug.mirrors.debian.org_debian-debug_dists_stable-debug_main_binary-amd64_Packages
> 
> What is _var_local_apt_._Packages?

Perhaps because on my local repository:

deb [trusted=yes] file:///var/local/apt ./

> Can you access this files content?

Yes, the file can be read.

-- 
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#1070891: apt-show-versions: Permission denied on a bad pathname

[Vincent Lefevre]

Hi Christoph,

On 2024-05-13 15:20:28 +0200, Christoph Martin wrote:
> Am 11.05.24 um 11:53 schrieb Vincent Lefevre:
> > Package: apt-show-versions
> > Version: 0.22.15
> > Severity: normal
> > 
> > When running "apt-show-versions -u" in a cron script, I got
> > 
> > Failed to open file 
> > /var/lib/apt/lists//debug.mirrors.debian.org_debian-debug_dists_stable-debug_InRelease
> >  for reading: Permission denied
> > 
> > I don't know why could cause the error, but the pathname with "//"
> > is incorrect.
> 
> // in the path should not be a problem.

zsh completion cannot handle it, so I was wondering.

> Can you do a 'ls -l /var/lib/apt/lists/' to see the permissions?

lrwxrwxrwx 1 root root   25 2024-05-11 22:36:06 _var_local_apt_._Packages 
-> /var/local/apt/./Packages
drwxr-xr-x 2 _apt root 4096 2023-10-07 13:42:54 auxfiles
-rw-r--r-- 1 root root52957 2024-05-11 16:15:34 
debug.mirrors.debian.org_debian-debug_dists_proposed-updates-debug_InRelease
-rw-r--r-- 1 root root   308541 2024-05-08 22:34:42 
debug.mirrors.debian.org_debian-debug_dists_proposed-updates-debug_main_binary-amd64_Packages
-rw-r--r-- 1 root root49779 2024-02-10 12:17:11 
debug.mirrors.debian.org_debian-debug_dists_stable-debug_InRelease
-rw-r--r-- 1 root root 14314273 2024-02-10 10:44:17 
debug.mirrors.debian.org_debian-debug_dists_stable-debug_main_binary-amd64_Packages
-rw-r--r-- 1 root root56601 2024-05-11 16:15:45 
debug.mirrors.debian.org_debian-debug_dists_unstable-debug_InRelease
-rw-r--r-- 1 root root11867 2024-05-11 16:07:07 
debug.mirrors.debian.org_debian-debug_dists_unstable-debug_main_Contents-amd64.lz4
-rw-r--r-- 1 root root 15598917 2024-05-11 16:07:09 
debug.mirrors.debian.org_debian-debug_dists_unstable-debug_main_binary-amd64_Packages
-rw-r--r-- 1 root root12615 2024-05-11 16:07:07 
debug.mirrors.debian.org_debian-debug_dists_unstable-debug_main_i18n_Translation-en
-rw-r--r-- 1 root root   101035 2024-05-11 16:15:38 
ftp.debian.org_debian_dists_experimental_InRelease
-rw-r--r-- 1 root root  6832935 2024-05-11 16:10:22 
ftp.debian.org_debian_dists_experimental_main_Contents-all.lz4
-rw-r--r-- 1 root root  2536358 2024-05-11 16:10:42 
ftp.debian.org_debian_dists_experimental_main_Contents-amd64.lz4
-rw-r--r-- 1 root root  3972604 2024-05-11 16:10:44 
ftp.debian.org_debian_dists_experimental_main_binary-amd64_Packages
-rw-r--r-- 1 root root  2424480 2024-05-11 16:10:15 
ftp.debian.org_debian_dists_experimental_main_i18n_Translation-en
-rw-r--r-- 1 root root  3112151 2024-05-11 16:11:36 
ftp.debian.org_debian_dists_experimental_main_source_Sources
-rw-r--r-- 1 root root55443 2024-05-11 16:15:26 
ftp.debian.org_debian_dists_stable-updates_InRelease
-rw-r--r-- 1 root root  317 2024-02-16 21:02:45 
ftp.debian.org_debian_dists_stable-updates_contrib_Contents-amd64.lz4
-rw-r--r-- 1 root root 1224 2024-02-16 21:01:38 
ftp.debian.org_debian_dists_stable-updates_contrib_binary-amd64_Packages
-rw-r--r-- 1 root root  538 2024-02-16 21:01:38 
ftp.debian.org_debian_dists_stable-updates_contrib_i18n_Translation-en
-rw-r--r-- 1 root root 1251 2024-02-16 21:01:38 
ftp.debian.org_debian_dists_stable-updates_contrib_source_Sources
-rw-r--r-- 1 root root   351371 2023-12-29 15:14:53 
ftp.debian.org_debian_dists_stable-updates_main_Contents-all.lz4
-rw-r--r-- 1 root root   429325 2024-04-23 22:45:52 
ftp.debian.org_debian_dists_stable-updates_main_Contents-amd64.lz4
-rw-r--r-- 1 root root73340 2024-04-23 22:45:52 
ftp.debian.org_debian_dists_stable-updates_main_binary-amd64_Packages
-rw-r--r-- 1 root root90213 2024-04-23 22:45:51 
ftp.debian.org_debian_dists_stable-updates_main_i18n_Translation-en
-rw-r--r-- 1 root root   333130 2024-04-23 22:46:05 
ftp.debian.org_debian_dists_stable-updates_main_source_Sources
-rw-r--r-- 1 root root  361 2024-02-16 21:02:46 
ftp.debian.org_debian_dists_stable-updates_non-free-firmware_Contents-amd64.lz4
-rw-r--r-- 1 root root 1446 2024-02-16 21:01:38 
ftp.debian.org_debian_dists_stable-updates_non-free-firmware_binary-amd64_Packages
-rw-r--r-- 1 root root  696 2024-02-16 21:01:38 
ftp.debian.org_debian_dists_stable-updates_non-free-firmware_i18n_Translation-en
-rw-r--r-- 1 root root12123 2024-02-16 21:01:38 
ftp.debian.org_debian_dists_stable-updates_non-free-firmware_source_Sources
-rw-r--r-- 1 root root27884 2024-02-16 21:02:46 
ftp.debian.org_debian_dists_stable-updates_non-free_Contents-amd64.lz4
-rw-r--r-- 1 root root   101751 2024-02-16 21:01:39 
ftp.debian.org_debian_dists_stable-updates_non-free_binary-amd64_Packages
-rw-r--r-- 1 root root64597 2024-02-16 21:01:39 
ftp.debian.org_debian_dists_stable-updates_non-free_i18n_Translation-en
-rw-r--r-- 1 root root 6231 2024-02-16 21:01:39 
ftp.debian.org_debian_dists_stable-updates_non-free_source_Sources
-rw-r--r-- 1 root root   151082 2024-02-10

Bug#1070891: apt-show-versions: Permission denied on a bad pathname

[Vincent Lefevre]

Package: apt-show-versions
Version: 0.22.15
Severity: normal

When running "apt-show-versions -u" in a cron script, I got

Failed to open file 
/var/lib/apt/lists//debug.mirrors.debian.org_debian-debug_dists_stable-debug_InRelease
 for reading: Permission denied

I don't know why could cause the error, but the pathname with "//"
is incorrect.

-- 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 apt-show-versions depends on:
ii  apt  2.9.2
ii  libapt-pkg-perl  0.1.40+b5
ii  perl [libstorable-perl]  5.38.2-4

apt-show-versions recommends no packages.

apt-show-versions 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#1070713: how-can-i-help: undefined local variable or method autorm_header_done

[Vincent Lefevre]

On 2024-05-10 12:20:43 +0200, Diederik de Haas wrote:
> Control: severity -1 grave
> 
> On 07 May 2024 19:35:30 +0200 Nicolas Noirbent  wrote:
> > Package: how-can-i-help
> > Version: 18
> > Severity: important
> > Tags: patch
> > 
> > Running how-can-i-help outputs nothing past the initial banner, due to an
> > undefined variable:
> 
> Which makes the package unusable, so upgrading severity accordingly

More or less. I got the error after a bug listed at
"New bugs where assistance is requested":

New bugs where assistance is requested (tagged 'help'):
 - libglib2.0-dev - https://bugs.debian.org/1070773 - libglib2.0-dev:i386 on 
amd64 should not require qemu-user

/usr/bin/how-can-i-help:338:in `': undefined local variable or method 
`autorm_header_done' for main:Object (NameError)

autorm_header_done == 0
^^
Did you mean?  autorm_date

BTW, I hadn't got any error after 6 upgrades (not involving ruby) with
how-can-i-help 18, but now I get an error. It should probably have a
testsuite to be able to trigger issues under various conditions.

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

Bug#1070695: server-control.html: ambiguous text bug bugs assigned to 2 packages

[Vincent Lefevre]

Package: debbugs-web
Version: 2.6.0
Severity: normal

At https://www.debian.org/Bugs/server-control.en.html (coming from
html/server-control.html.in in debbugs):

  The bug tracking system uses this information, in conjunction with
  fixed versions recorded when closing bugs, to display lists of bugs
  open in various versions of each package. It considers a bug to be
  open when it has no fixed version, or when it has been found more
  recently than it has been fixed.

But this text is ambiguous when a bug is assigned to 2 different
packages and is marked as fixed in only one of these packages.

-- 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.6.15-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 debbugs-web depends on:
ii  apache2 [httpd]  2.4.59-2
pn  libdebbugs-perl  
ii  perl 5.38.2-4

debbugs-web recommends no packages.

Versions of packages debbugs-web suggests:
ii  libapache2-mod-perl2  2.0.13-1+b3
pn  libcgi-alert-perl 

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

Bug#1068349: nbsphinx/nbconvert broken by lxml 5.2: lxml.html.clean

[Vincent Lefevre]

Control: reopen -1

On 2024-05-07 11:25:05 +0200, Vincent Lefevre wrote:
> What's the status of this bug?
> 
> apt-listbugs still reports python3-lxml as buggy:
> 
> serious bugs of python3-lxml (5.1.0-1 → 5.2.1-1) 
>  b1 - #1068349 - nbsphinx/nbconvert broken by lxml 5.2: lxml.html.clean 
> (Fixed: nbconvert/6.5.3-5)
> Summary:
>  python3-lxml(1 bug)
> 
> Indeed, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068349
> says: "Found in versions nbconvert/6.5.3-4, lxml/5.2.1-1".
> 
> So python3-lxml 5.2.1-1 is regarded as buggy.

And this bug prevents the migration to testing:

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

testing migrations
[...]
Issues preventing migration:
∙ ∙ Updating lxml would introduce bugs in testing: #1068349

It seems that this bug (assigned to 2 different packages) has been
closed by mistake, due to the fix of nbconvert:

Format: 1.8
Date: Sun, 14 Apr 2024 16:52:34 +0100
Source: nbconvert
Architecture: source
Version: 6.5.3-5
[...]
Closes: 1042699 1068349
[...]
   * (Build-)depend on python3-lxml-html-clean (closes: #1068349).

But this is inconsistent with the fact that lxml is still marked as
unfixed. So, reopening.

-- 
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#1068349: nbsphinx/nbconvert broken by lxml 5.2: lxml.html.clean

[Vincent Lefevre]

On 2024-04-07 22:06:05 +0100, Rebecca N. Palmer wrote:
> To avoid being blocked by this bug, the pandas version I just uploaded
> temporarily disables the documentation.
> 
> This is also an option for any other affected packages that urgently need to
> be uploaded.  (I don't know whether the other two listed Blocks/Affects are
> that urgent.)

What's the status of this bug?

apt-listbugs still reports python3-lxml as buggy:

serious bugs of python3-lxml (5.1.0-1 → 5.2.1-1) 
 b1 - #1068349 - nbsphinx/nbconvert broken by lxml 5.2: lxml.html.clean (Fixed: 
nbconvert/6.5.3-5)
Summary:
 python3-lxml(1 bug)

Indeed, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068349
says: "Found in versions nbconvert/6.5.3-4, lxml/5.2.1-1".

So python3-lxml 5.2.1-1 is regarded as buggy.

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

Bug#1070677: fail2ban fails: "Failed during configuration: Have not found any log file for sshd jail"

[Vincent Lefevre]

On 2024-05-07 03:57:44 +0200, Vincent Lefevre wrote:
> sshd_backend = systemd

BTW, that would fix the issue only for sshd. But what about the other
jails the user could have enabled in /etc/fail2ban/jail.local? The
user configuration may rely on systemd being the default backend, at
least the configured backend for these jails.

For instance, concerning postfix, both paths-arch.conf and
paths-opensuse.conf have "postfix_backend = systemd", but not
paths-debian.conf. Other jails may be concerned.

paths-arch.conf has

# These services will log to the journal via syslog, so use the journal by
# default.
syslog_backend = systemd
sshd_backend = systemd
dropbear_backend = systemd
proftpd_backend = systemd
pureftpd_backend = systemd
wuftpd_backend = systemd
postfix_backend = systemd
dovecot_backend = systemd

and paths-opensuse.conf has

# These services will log to the journal via syslog, so use the journal by
# default.
syslog_backend = systemd
sshd_backend = systemd
dropbear_backend = systemd
proftpd_backend = systemd
pureftpd_backend = systemd
wuftpd_backend = systemd
postfix_backend = systemd
dovecot_backend = systemd
mysql_backend = systemd

But the user may also have his own services with associated jails...

Either there should be a better fix or the change should be announced
in NEWS.Debian, with a clear explanation on what to do.

-- 
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#1070677: fail2ban fails: "Failed during configuration: Have not found any log file for sshd jail"

[Vincent Lefevre]

On 2024-05-07 03:28:28 +0200, Vincent Lefevre wrote:
> May 07 03:01:28 qaa fail2ban-server[557228]: 2024-05-07 03:01:28,226 fail2ban 
>[557228]: ERROR   Failed during configuration: Have not found 
> any log file for sshd jail

I suppose that this is because sshd no longer uses the systemd
backend. This is wrong. If I understand correctly, the point of

https://github.com/fail2ban/fail2ban/issues/3292#issuecomment-2078361360

is to no longer use the systemd backend for all jails, but for
sshd only. So "backend = systemd" has been removed from DEFAULT,
but the above comment also points to

https://github.com/fail2ban/fail2ban/commit/85a4881a9a818b6a746109f74980919296eedad0

which adds for DEFAULT in paths-debian.conf:


banaction = nftables
banaction_allports = nftables[type=allports]

sshd_backend = systemd


But paths-debian.conf has not changed in the fail2ban 1.1.0-1 package.

-- 
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#1070677: fail2ban fails: "Failed during configuration: Have not found any log file for sshd jail"

[Vincent Lefevre]

Package: fail2ban
Version: 1.1.0-1
Severity: grave
Justification: renders package unusable

After the upgrade to 1.1.0-1, "systemctl status" gives

× fail2ban.service - Fail2Ban Service
 Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; enabled; preset: 
enabled)
 Active: failed (Result: exit-code) since Tue 2024-05-07 03:01:28 CEST; 
25min ago
   Duration: 58ms
   Docs: man:fail2ban(1)
   Main PID: 557228 (code=exited, status=255/EXCEPTION)
CPU: 55ms

May 07 03:01:28 qaa systemd[1]: Started fail2ban.service - Fail2Ban Service.
May 07 03:01:28 qaa fail2ban-server[557228]: 2024-05-07 03:01:28,226 fail2ban   
 [557228]: ERROR   Failed during configuration: Have not found any 
log file for sshd jail
May 07 03:01:28 qaa fail2ban-server[557228]: 2024-05-07 03:01:28,230 fail2ban   
 [557228]: ERROR   Async configuration of server failed
May 07 03:01:28 qaa systemd[1]: fail2ban.service: Main process exited, 
code=exited, status=255/EXCEPTION
May 07 03:01:28 qaa systemd[1]: fail2ban.service: Failed with result 
'exit-code'.

-- 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.6.15-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.11.8-1
ii  python3-systemd  235-1+b3

Versions of packages fail2ban recommends:
ii  iptables   1.8.10-3
ii  nftables   1.0.9-1+b2
ii  python3-pyinotify  0.9.6-2
ii  whois  5.5.22

Versions of packages fail2ban suggests:
ii  mailutils [mailx]  1:3.17-1.1+b2
pn  monit  
ii  sqlite33.45.3-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#1070652: ruby-json: breaks how-can-i-help

[Vincent Lefevre]

Package: ruby-json
Version: 2.7.2+dfsg-1
Severity: grave
Justification: renders package unusable

This new ruby-json version breaks how-can-i-help:

[...]
Unpacking ruby-json:amd64 (2.7.2+dfsg-1) over (2.6.3+dfsg-1+b2) ...
Setting up ruby-json:amd64 (2.7.2+dfsg-1) ...
/usr/bin/how-can-i-help:155:in `': uninitialized constant OpenStruct 
(NameError)

proxy_uri = $proxy_url.nil? ? OpenStruct.new : URI.parse($proxy_url)
  ^^

-- 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.6.15-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 ruby-json depends on:
ii  libc6  2.38-7
ii  libruby1:3.1+nmu1
ii  libruby3.1t64  3.1.2-8.3

ruby-json recommends no packages.

ruby-json 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#1070293: xkb-data: typo in URL in the copyright file

[Vincent Lefevre]

Package: xkb-data
Version: 2.41-2
Severity: minor

In /usr/share/doc/xkb-data/copyright the URL

  https://xorg.freedesktop.orgreleases/individual/data/xkeyboard-config

is incorrect. A slash is missing before "releases". A trailing slash
should also be added to avoid a redirection.

Correct URL:

  https://xorg.freedesktop.org/releases/individual/data/xkeyboard-config/

-- 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.6.15-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

-- no debconf information

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

Bug#1070152: chkrootkit: duplicate line from ifpromisc

[Vincent Lefevre]

On 2024-05-02 08:57:10 +0100, Richard Lewis wrote:
> On Thu, 2 May 2024, 03:45 Vincent Lefevre,  wrote:
> 
> > On 2024-05-01 19:05:06 +0100, Richard Lewis wrote:
> > > I agree that you should be able to filter out duplicate lines. And i
> > think
> > > this is possible with a  custom filter.
> >
> > Yes, but "sed" may not be the best tool for that. With sed, removing
> > lines containing only the usual network managers is easier.
> 
> you dont have to use sed, you can set anything. id use awk or sort.

Using sort is not possible here, as the whole file would be sorted.

> but then you dont know if things have disappeared.

which can already happen with the default filter, because the actual
list is replaced by
  systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager

The default filter is either doing too little or doing too much.

> > > I dont think it should be the default - most chkrootkit users have a more
> > > static network setup,
> >
> > If they have a static network setup, why hiding the interface name?
> 
> i believe this was because if you have multiple interfaces they may not
> have static names (in the days where these were eth0 vs eth1 ) and because
> eg dhcpcd was set up to listen on eth0 and wlan0 even if eth0 wasnt used.
> maybe some of these assumptions are out of date?

AFAIK, systemd uses more complex names for predictability/stability.
For instance, on one of my machines, I have "enp0s25". See

  
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Alternatively, users can define "persistent net" udev rules, such as
giving the interface name based on the MAC address of the interface:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="", 
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

> > But are lines containing *only* the usual network managers suspicious?
> 
> no, but it is suspicious is anything changed.

With the default filter, it will not detect all changes.

IMHO, either only the PID should be hidden (this is typically the
only thing that changes in static network setups) or the usual
network managers should entirely be ignored, such as with...

> Please also see the manpage which tells you how to use -s to remove these
> lines. The config file can easily be used to use -s each time.

Yes, I think that -s is the best solution for a laptop, but there
are issues in the man page. I've just reported bug 1070231.

-- 
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#1070231: chkrootkit -s in man page: bad example and confusing

[Vincent Lefevre]

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

The "chkrootkit -s" example in the man page is

  chkrootkit -s '(systemd-netword|NetworkManager|wpa_supplicant)'

but if an unrecognized packet sniffer is added on one of the
interfaces, it will not be detected.

And "where the argument lists whicher managers you expect to be
present" is confusing (BTW, "whicher" is wrong). The match is
not done on individual managers, but on the whole line output
by ifpromisc.

If I understand correctly, it should be something more like

  chkrootkit -s '^[[:alnum:]]+: PACKET 
SNIFFER\(((/usr/lib/systemd/systemd-networkd|/usr/sbin/(dhclient|dhcpc?d[0-9]*|wpa_supplicant|NetworkManager))\[[0-9]+\](,
 )?)+\)$'

(inspired by the default FILTER).

Or the -s option could be "fixed" to match on individual managers.

-- 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.6.15-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 chkrootkit depends on:
ii  libc6  2.37-19

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

chkrootkit suggests no packages.

-- Configuration Files:
/etc/chkrootkit/chkrootkit.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#1070152: chkrootkit: duplicate line from ifpromisc

[Vincent Lefevre]

On 2024-05-01 19:05:06 +0100, Richard Lewis wrote:
> I agree that you should be able to filter out duplicate lines. And i think
> this is possible with a  custom filter.

Yes, but "sed" may not be the best tool for that. With sed, removing
lines containing only the usual network managers is easier.

> I dont think it should be the default - most chkrootkit users have a more
> static network setup,

If they have a static network setup, why hiding the interface name?
Doing that makes the output more confusing, and the replacement of
an interface by another one would not be detected.

> and the alert shows something has changed. For laptops where
> networking is more dynamic it's hard to design something that works
> for everyone without also hiding information for other people.

But are lines containing *only* the usual network managers suspicious?

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

Bug#1069268: gnulib: package version is long

[Vincent Lefevre]

Hi Simon,

On 2024-05-01 11:36:56 +0200, Simon Josefsson wrote:
> Vincent Lefevre  writes:
> > IMHO, for additional version information, the Debian changelog is a
> > good place for the user + output from a standard command providing
> > the version, e.g. "gnulib-tool --version". Scripts can use such a
> > command to record the necessary information about software in log
> > files. By "standard", I mean that it needs to exist upstream.
> >
> > For instance, for GCC, there is "gcc --version", where Debian adds
> > some information. In particular for gcc-snapshot:
> >
> > $ gcc-snapshot --version
> > gcc (Debian 20240117-1) 14.0.1 20240117 (experimental) [master 
> > r14-8187-gb00be6f1576]
> > [...]
> >
> > One has all the details... When compiling software, this can be
> > found in the generated config.log file, which is really nice for
> > bug reports and debugging.
> >
> > And the gcc-snapshot version string is basically just a date.
> 
> Right.  There is one implementation problem: gnulib-tool is patched to
> read the version from /usr/share/doc/gnulib/changelog.Debian.gz now, but
> if we change changelog to only be a date, we would want to change this
> logic to actually print the useful git commit version information, and
> I'm not yet sure how to do that.

IMHO, changelog.Debian.gz should contain complete information about
the version, not in the Debian package version, but in the log. It
already has lines like:

  * New upstream snapshot from stable branch stable-202401.

You may choose some fixed format such that it is parsable by both
humans and the machine, i.e. something that a human can understand,
but simple enough to that a script can produce a more compact version
for gnulib-tool.

However, the Debian policy

  https://www.debian.org/doc/debian-policy/ch-docs.html

says

  Packages must not require the existence of any files in
  /usr/share/doc/ in order to function.[6] Any files that are used or
  read by programs but are also useful as stand alone documentation
  should be installed elsewhere, such as under /usr/share/package/,
  and then included via symbolic links in /usr/share/doc/package.

  [6] The system administrator should be able to delete files in
  /usr/share/doc/ without causing any programs to break.

BTW, since gnulib-tool is already in /usr/share/gnulib, it would
make sense to have version information there too (perhaps just in
the compact form, for gnulib-tool).

> There is also the "risk" that upstream gnulib eventually release
> versioned archives.  There is a recently added v1.0 tag in git for
> example, suggesting things may change.  Since we haven't used the
> 0~20240501* pattern for gnulib version historically, to move to a

(Anyway, the 0~20240501* pattern would have been a bad idea, IMHO,
because AFAIK, there is no version 0 in gnulib, and that would have
confused the user.)

> version based approach we would need an epoch like 1:1.3-1 or (more
> likely) 1:1.3+20250314-2 since I think we need to package more recent
> git commits than what's in any most recent gnulib git tags.  However I
> don't think the upstream version number is relevant either, for the same
> reasons we realized the upstream commit id or branches weren't.  So we
> can continue to use dates for package versions even if upstream start to
> release packaged archives.
> 
> I'm now inclinced to use a pure date-based version string like
> 20240501-1 going forward.  Any objections?

This is OK for me. Until there would be an obvious advantage to
change, I'd say that it is better to still use just the date.

> We then also have to fix Debian's gnulib-tool --version output to embed
> the latest git commit information from upstream that we package --
> possibly using the new git bundle as a source?  Instead of parsing
> /usr/share/doc/gnulib/changelog.Debian.gz, which may not be present in
> stripped down images anyway.

Well, you must not use files under /usr/share/doc (see above).

I saw that you now ship gnulib.bundle, but I don't know whether
this is a good thing (usefulness in practice vs the fact that
it makes the package significantly larger).

> Since gnulib is a fairly large package, I would prefer to not spam the
> archive with new *.orig.tar.gz uploads too often.  So I prefer to not
> fix this bug until we have to upload a more recent gnulib into the
> archive for other reasons.  I don't expect that to take long: I'm
> planning to do new release of several projects (oath-toolkit, libidn2,
> inetutils, etc) that use gnulib, and work on making those Debian
> packages use the Debian gnulib package instead of vendored code would
> require a new gnulib Debian package upload.

OK. I reverted to 20240117+stable-1 on my machines. IIRC, I had
inst

Bug#1070152: chkrootkit: duplicate line from ifpromisc

[Vincent Lefevre]

On 2024-05-01 01:29:10 +0200, Vincent Lefevre wrote:
> For instance, /var/log/chkrootkit/log.expected contains
> 
> WARNING: Output from ifpromisc:
> lo: not promisc and no packet sniffer sockets
> : PACKET 
> SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})
> 
> But /var/log/chkrootkit/log.today currently has a duplicate line:
> 
> WARNING: Output from ifpromisc:
> lo: not promisc and no packet sniffer sockets
> : PACKET 
> SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})
> : PACKET 
> SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})
> 
> which has the effect to generate an alert.

This is actually due to the filter in /etc/chkrootkit/chkrootkit.conf,
which obfuscates the output.

The unfiltered output:

lo: not promisc and no packet sniffer sockets
eth0: PACKET SNIFFER(/usr/sbin/NetworkManager[1261])
wlp0s20f3: PACKET SNIFFER(/usr/sbin/NetworkManager[1261], 
/usr/sbin/wpa_supplicant[1263])

But for a laptop, there is not always an Ethernet cable plugged in.

IMHO, known packet sniffers should be filtered out.

-- 
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#1070152: chkrootkit: duplicate line from ifpromisc

[Vincent Lefevre]

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

In the generated log, I sometimes get a duplicate line from ifpromisc.

For instance, /var/log/chkrootkit/log.expected contains

WARNING: Output from ifpromisc:
lo: not promisc and no packet sniffer sockets
: PACKET 
SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})

But /var/log/chkrootkit/log.today currently has a duplicate line:

WARNING: Output from ifpromisc:
lo: not promisc and no packet sniffer sockets
: PACKET 
SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})
: PACKET 
SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})

which has the effect to generate an alert.

-- 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.6.15-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 chkrootkit depends on:
ii  libc6  2.37-19

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

chkrootkit 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#1070120: postfix: can't send mail due to obsolete /var/spool/postfix/etc/resolv.conf on new network

[Vincent Lefevre]

Control: tags -1 security

On 2024-04-30 16:33:14 +0200, Vincent Lefevre wrote:
> If I try to restart postfix, I get:
> 
> postfix/postfix-script: warning: /var/spool/postfix/etc/resolv.conf and 
> /etc/resolv.conf differ

BTW, note that this is a security issue, because with wifi,
the DNS server often corresponds to the local router (e.g.
10.3.0.1), and it may happen that the obsolete IP address
may correspond to some random machine on the network, which
could act as a malicious DNS server.

> Indeed, /var/spool/postfix/etc/resolv.conf contains obsolete data.
> 
> I had to do "cp /etc/resolv.conf /var/spool/postfix/etc/resolv.conf".

I don't know how the update should be done. I suppose that
/etc/network/if-up.d/postfix is pointless in case of wifi as
it says "Called when a new interface comes up", but for wifi,
this is the same interface, only a new network.

And I don't understand why restarting postfix did not update
the file.

BTW, even ethernet connections may be affected in case of
network reconfiguration.

-- 
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#1065625: libmtp9t64 / libmtp-runtime dependency problem makes dpkg fail with attempt of removal of libmtp-common

[Vincent Lefevre]

On 2024-04-30 11:49:57 +0200, Julian Andres Klode wrote:
> This bug has since been reassigned to aptitude. Solver limitations
> in aptitude wrt t64 handling should not be considered release critical,
> it makes no sense to remove aptitude from testing for it; there are
> still plenty of other valid use cases that are unaffected by these
> particular bugs, so I am downgrading it to important.

OK, but note that this is a rather serious bug somewhere (perhaps
in aptitude, but really, I'm not sure since according to aptitude's
debug log, everything is fine on its side), not just a solver
limitation: if this were a solver limitation, aptitude would have
at least said that the upgrade was not possible because some
dependency could not be satisfied (this is what it usually does);
but this is not what happened.

In short, something attempts to remove a package that has *not*
been marked as to be removed. Fortunately, when trying to remove
the package, dpkg detects a dependency issue. But I fear, that in
some cases (e.g. when the unannounced package to be removed would
not have a dependency on it), this could potentially completely
break the system.

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

Bug#1070120: postfix: can't send mail due to obsolete /var/spool/postfix/etc/resolv.conf on new network

[Vincent Lefevre]

Package: postfix
Version: 3.9.0-2
Severity: important

While being connected in the train, mailq gives:

-Queue ID-  --Size-- Arrival Time -Sender/Recipient---
24FC2CA011A2232 Tue Apr 30 16:21:46  vinc...@vinc17.net
(Host or domain name not found. Name service error for name=joooj.vinc17.net 
type=: Host not found, try again)
[...]

while "host joooj.vinc17.net" gives no issues.

If I try to restart postfix, I get:

postfix/postfix-script: warning: /var/spool/postfix/etc/resolv.conf and 
/etc/resolv.conf differ

Indeed, /var/spool/postfix/etc/resolv.conf contains obsolete data.

I had to do "cp /etc/resolv.conf /var/spool/postfix/etc/resolv.conf".

-- 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.6.15-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 postfix depends on:
ii  adduser3.137
ii  cpio   2.15+dfsg-1
ii  debconf [debconf-2.0]  1.5.86
ii  dpkg   1.22.6
ii  e2fsprogs  1.47.0-2.4
ii  init-system-helpers1.66
ii  libc6  2.37-19
ii  libdb5.3t645.3.28+dfsg2-7
ii  libicu72   72.1-4+b1
ii  libnsl21.3.0-3+b2
ii  libsasl2-2 2.1.28+dfsg1-6
ii  libssl3t64 3.2.1-3
ii  netbase6.4
ii  ssl-cert   1.1.2

Versions of packages postfix recommends:
ii  ca-certificates  20240203
ii  python3  3.11.8-1

Versions of packages postfix suggests:
ii  emacs-gtk [mail-reader]   1:29.3+1-2
ii  libsasl2-modules  2.1.28+dfsg1-6
ii  mailutils [mail-reader]   1:3.17-1.1+b2
ii  mutt [mail-reader]2.2.12-0.1+b1
pn  postfix-cdb   
ii  postfix-doc   3.9.0-2
pn  postfix-ldap  
pn  postfix-lmdb  
pn  postfix-mongodb   
pn  postfix-mta-sts-resolver  
pn  postfix-mysql 
ii  postfix-pcre  3.9.0-2
pn  postfix-pgsql 
pn  postfix-sqlite
ii  procmail  3.22-27
pn  resolvconf
pn  ufw   

-- debconf information:
* postfix/mailname: qaa.vinc17.org
* postfix/root_address:
  postfix/not_configured:
* postfix/destinations: qaa.vinc17.org, 135.197.67.86.rev.sfr.net, , localhost
  postfix/relayhost:
* postfix/protocols: all
* postfix/chattr: false
  postfix/newaliases: false
* postfix/procmail: true
* postfix/recipient_delim: -
* postfix/mynetworks: 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
* postfix/main_mailer_type: Internet Site
* postfix/mailbox_limit: 0
  postfix/bad_recipient_delimiter:
  postfix/rfc1035_violation: false

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

Bug#1070027: fdisk: dependency problems prevent configuration of fdisk

[Vincent Lefevre]

On 2024-04-29 03:05:50 +0200, Guillem Jover wrote:
> I don't think dpkg is at fault here, I assume something else is either
> getting activated in the middle of the transaction while the package
> manager frontend driving dpkg has released the lock (which it should
> not), or the package manager frontend driving dpkg is performing the
> locking dance incorrectly.

Isn't dpkg able to install/uninstall a set of packages in an atomic
way (where dpkg itself would set a lock at the beginning and release
the lock once every install/uninstall has been done, so that a lock
failure would not be possible in the middle of the installation)?

> > > with fdisk.
> > 
> > I see no evidence of that in the log.
> 
> Right, it seems to me, like when dpkg fails due to the already held
> lock, then the frontend is not recomputing the transaction and keeps
> as if nothing had gone incorrectly, until it then notices later on.

Alternatively, if this is too complicated, it could abort and let
the user fix things (which is currently needed anyway).

> In any case, given that dpkg is not being very helpful in diagnosing
> this, I'll implement support to print the process name in addition to
> the pid, as this has also hit me, and it's never clear what was the
> actual culprit. So that's why I'm leaving this assigned to dpkg, but
> with a lower severity. If you'd like to file this elsewhere, then
> please clone and reassign that.

It seems that the "dpkg frontend lock is locked by another process"
error almost always occurs with the same packages: either util-linux
or apt. See bugs

* 95

Unpacking util-linux (2.34-0.1) over (2.33.1-0.1) ...
dpkg: error: dpkg frontend lock is locked by another process

Setting up apt (2.6.1) ...
dpkg: error: dpkg frontend lock was locked by another process with pid 4191235

* 940961

Unpacking apt (1.8.4) over (1.8.3) ...
dpkg: error: dpkg frontend lock is locked by another process

* 1069183

Setting up util-linux-extra (2.38.1-5+deb12u1) ...
dpkg: error: dpkg frontend lock was locked by another process with pid 1064194

* 1070027 (this bug)

Setting up util-linux (2.40-8) ...
fstrim.service is a disabled or a static unit not running, not starting it.
dpkg: error: dpkg frontend lock was locked by another process with pid 58569

I'm wondering whether there could be a reason...

But there's also bug 1062190:

Unpacking locales (2.36-9+deb12u4) over (2.36-9+deb12u3) ...
dpkg: error: dpkg frontend lock was locked by another process with pid 567573

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

Bug#1065625: libmtp9t64 / libmtp-runtime dependency problem makes dpkg fail with attempt of removal of libmtp-common

[Vincent Lefevre]

Hi,

On 2024-04-28 19:21:18 -0300, Facundo Gaich wrote:
> Today I upgraded one of my unstable machines and saw several instances of
> something I believe is the same bug. The resolver seems to be failing to
> choose to upgrade certain dependencies. What's more, in the aptitude GUI
> I can see the rightmost "latest available version" column change on the fly
> when I select certain packages for upgrade.
> 
> For example, I currently have libnm0 and libnm0:i386 installed at 1.46.0-1
> and I can see the latest version is 1.46.0-2. If I go into the GUI and
> choose
> to "Install" libnm0, the latest version column for libnm0:i386 will change
> from 1.46.0-2 to 1.46.0-1. Choosing "Install" on libnm0:i386 will then
> effectively
> do a keep of libnm0 at 1.46.0-1. To fix this, I can either go into
> libnm0:i386 and
> explicitly choose the newest version or I can restart the GUI and then it
> will
> list and choose the latest version correctly when I do Install libnm0:i386.
> 
> aptitude version: 0.8.13-6

This is not the same bug. In my case, the resolver chose to do exactly
what I was asking to. This is also what appears in the aptitude logs.
However, what really happened is something completely different:
libmtp-common was attempted to be removed while no such removal was
shown on the aptitude side (not even in its debug logs). This is not
an issue with the resolver, but what happens somewhere between aptitude
and dpkg.

The "the latest version column for libnm0:i386 will change from
1.46.0-2 to 1.46.0-1" with the TUI corresponds to

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

which I had reported 3 years ago and still occurs regularly.

Concerning the buggy dependency resolutions (showing that aptitude
does not favor the most obvious solutions, whether the TUI is used
or not):

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

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

Bug#1070027: fdisk: dependency problems prevent configuration of fdisk

[Vincent Lefevre]

Here's the /var/log/apt/history.log part that corresponds to this
upgrade:

Start-Date: 2024-04-28  22:05:30
Upgrade: libsmartcols1:amd64 (2.40-6, 2.40-8), libvpx8:amd64 (1.13.1-2, 
1.13.1-2+b1), libltdl7:amd64 (2.4.7-7, 2.4.7-7+b1), libpaper1:amd64 (1.1.29, 
1.1.29+b1), libnftnl11:amd64 (1.2.6-2, 1.2.6-2+b1), asymptote:amd64 
(2.87+ds-1+b1, 2.89+ds-1), va-driver-all:amd64 (2.20.0-2, 2.20.0-2+b1), 
libdevel-size-perl:amd64 (0.83-2+b3, 0.84-1), libxrender1:amd64 (1:0.9.10-1.1, 
1:0.9.10-1.1+b1), util-linux-locales:amd64 (2.40-6, 2.40-8), libglvnd0:amd64 
(1.7.0-1, 1.7.0-1+b1), perl:amd64 (5.38.2-3.2+b2, 5.38.2-4), libx11-xcb1:amd64 
(2:1.8.7-1, 2:1.8.7-1+b1), libxshmfence1:amd64 (1.3-1, 1.3-1+b1), 
libxml2-dev:amd64 (2.9.14+dfsg-1.3+b2, 2.9.14+dfsg-1.3+b3), 
libmatch-simple-xs-perl:amd64 (0.001-4, 0.002-1), libunwind8:amd64 (1.6.2-3, 
1.6.2-3+b1), libldap-common:amd64 (2.5.16+dfsg-2, 2.5.17+dfsg-1), 
libxml2-utils:amd64 (2.9.14+dfsg-1.3+b2, 2.9.14+dfsg-1.3+b3), libxkbfile1:amd64 
(1:1.1.0-1, 1:1.1.0-1+b1), libfile-mimeinfo-perl:amd64 (0.34-1, 0.35-1), 
xsltproc:amd64 (1.1.35-1, 1.1.35-1+b1), libpciaccess0:amd64 (0.17-3, 
0.17-3+b1), libxcursor1:amd64 (1:1.2.1-1, 1:1.2.1-1+b1), codespell:amd64 
(2.2.6-1, 2.2.6-2), libmime-tools-perl:amd64 (5.514-1, 5.515-1), libglx0:amd64 
(1.7.0-1, 1.7.0-1+b1), vim-common:amd64 (2:9.1.0199-1, 2:9.1.0377-1), 
libsigsegv2:amd64 (2.14-1, 2.14-1+b1), libmaa4:amd64 (1.4.7-1, 1.4.7-1+b1), 
libva-x11-2:amd64 (2.20.0-2, 2.20.0-2+b1), libgsm1:amd64 (1.0.22-1, 
1.0.22-1+b1), libmount1:amd64 (2.40-6, 2.40-8), libxau6:amd64 (1:1.0.9-1, 
1:1.0.9-1+b1), libxcomposite1:amd64 (1:0.4.5-1, 1:0.4.5-1+b1), 
libxs-parse-keyword-perl:amd64 (0.39-1+b2, 0.41-1), libatasmart4:amd64 (0.19-5, 
0.19-5+b1), libdevel-callchecker-perl:amd64 (0.008-2+b2, 0.009-1), 
libxdamage1:amd64 (1:1.1.6-1, 1:1.1.6-1+b1), libsepol2:amd64 (3.5-2, 3.5-2+b1), 
libmnl0:amd64 (1.0.5-2, 1.0.5-2+b1), libxml2:amd64 (2.9.14+dfsg-1.3+b2, 
2.9.14+dfsg-1.3+b3), util-linux:amd64 (2.40-6, 2.40-8), libvdpau1:amd64 (1.5-2, 
1.5-2+b1), util-linux-extra:amd64 (2.40-6, 2.40-8), libldap-2.5-0:amd64 
(2.5.16+dfsg-2, 2.5.17+dfsg-1), libgav1-1:amd64 (0.19.0-2, 0.19.0-2+b1), 
libgpg-error0:amd64 (1.47-3, 1.47-3+b1), libxss1:amd64 (1:1.2.3-1, 
1:1.2.3-1+b1), libxcvt0:amd64 (0.1.2-1, 0.1.2-1+b1), libassuan-dev:amd64 
(2.5.6-1, 2.5.6-1+b1), libcompress-raw-lzma-perl:amd64 (2.211-1, 2.212-1), 
libcdr-0.1-1:amd64 (0.1.7-1, 0.1.7-1+b1), fdisk:amd64 (2.40-6, 2.40-8), 
libgles2:amd64 (1.7.0-1, 1.7.0-1+b1), libyaml-0-2:amd64 (0.2.5-1, 0.2.5-1+b1), 
libxxf86dga1:amd64 (2:1.1.5-1, 2:1.1.5-1+b1), libxfont2:amd64 (1:2.0.6-1, 
1:2.0.6-1+b1), libfdisk1:amd64 (2.40-6, 2.40-8), libassuan0:amd64 (2.5.6-1, 
2.5.6-1+b1), libsoxr0:amd64 (0.1.3-4, 0.1.3-4+b1), eject:amd64 (2.40-6, 
2.40-8), libltdl-dev:amd64 (2.4.7-7, 2.4.7-7+b1), libxkbcommon0:amd64 (1.6.0-1, 
1.6.0-1+b1), libxtst6:amd64 (2:1.2.3-1.1, 2:1.2.3-1.1+b1), 
vdpau-driver-all:amd64 (1.5-2, 1.5-2+b1), libnet-dns-sec-perl:amd64 (1.23-1+b2, 
1.24-1), libuuid1:amd64 (2.40-6, 2.40-8), libvisual-0.4-0:amd64 (0.4.2-2, 
0.4.2-2+b1), libjpeg62-turbo:amd64 (1:2.1.5-2+b2, 1:2.1.5-3), libgcrypt20:amd64 
(1.10.3-2, 1.10.3-2+b1), python3-numpy:amd64 (1:1.26.4+ds-6, 1:1.26.4+ds-8), 
perl-doc:amd64 (5.38.2-3.2, 5.38.2-4), vim-tiny:amd64 (2:9.1.0199-1, 
2:9.1.0377-1), xcvt:amd64 (0.1.2-1, 0.1.2-1+b1), libice6:amd64 (2:1.0.10-1, 
2:1.0.10-1+b1), liburing2:amd64 (2.5-1, 2.5-1+b1), libid3tag0:amd64 
(0.15.1b-14, 0.15.1b-14+b1), asymptote-doc:amd64 (2.87+ds-1, 2.89+ds-1), 
libopengl0:amd64 (1.7.0-1, 1.7.0-1+b1), libxslt1.1:amd64 (1.1.35-1, 
1.1.35-1+b1), libglu1-mesa:amd64 (9.0.2-1.1, 9.0.2-1.1+b1), 
librevenge-0.0-0:amd64 (0.0.5-3, 0.0.5-3+b1), libogg0:amd64 (1.3.5-3, 
1.3.5-3+b1), libxinerama1:amd64 (2:1.1.4-3, 2:1.1.4-3+b1), mount:amd64 (2.40-6, 
2.40-8), perl-base:amd64 (5.38.2-3.2+b2, 5.38.2-4), libpaper-utils:amd64 
(1.1.29, 1.1.29+b1), libjaylink0:amd64 (0.3.1-1, 0.3.1-1+b1), ed:amd64 
(1.20.1-1.1, 1.20.2-2), libblkid1:amd64 (2.40-6, 2.40-8), libxvmc1:amd64 
(2:1.0.12-2, 2:1.0.12-2+b1), libva-drm2:amd64 (2.20.0-2, 2.20.0-2+b1), 
perl-modules-5.38:amd64 (5.38.2-3.2, 5.38.2-4), libgl1:amd64 (1.7.0-1, 
1.7.0-1+b1), libegl1:amd64 (1.7.0-1, 1.7.0-1+b1), libx11-6:amd64 (2:1.8.7-1, 
2:1.8.7-1+b1), libperl5.38t64:amd64 (5.38.2-3.2+b2, 5.38.2-4), 
libxkbcommon-x11-0:amd64 (1.6.0-1, 1.6.0-1+b1), liblz1:amd64 (1.14-1, 
1.15~pre1-1), libemf1:amd64 (1.0.13-7, 1.0.13-7+b1), libwpg-0.3-3:amd64 
(0.3.4-3, 0.3.4-3+b1), libgpg-error-dev:amd64 (1.47-3, 1.47-3+b1), 
libedit2:amd64 (3.1-20230828-1, 3.1-20230828-1+b1), bsdutils:amd64 (1:2.40-6, 
1:2.40-8), libsm6:amd64 (2:1.2.3-1, 2:1.2.3-1+b1), libva2:amd64 (2.20.0-2, 
2.20.0-2+b1), bsdextrautils:amd64 (2.40-6, 2.40-8), libxfixes3:amd64 
(1:6.0.0-2, 1:6.0.0-2+b1), libxdmcp6:amd64 (1:1.1.2-3, 1:1.1.2-3+b1), 
libxv1:amd64 (2:1.0.11-1.1, 2:1.0.11-1.1+b1), libutempter0:amd64 (1.2.1-3, 
1.2.1-3+b1), libspectre1:amd64 (0.2.12-1, 0.2.12-1+b1), libevdev2:amd64 
(1.13.1+dfsg-1, 

Bug#1070027: fdisk: dependency problems prevent configuration of fdisk

[Vincent Lefevre]

Package: fdisk
Version: 2.40-8
Severity: serious

During an upgrade with aptitude 0.8.13-6, I got:

Extracting templates from packages: 100%
Preconfiguring packages ...
(Reading database ... 417244 files and directories currently installed.)
Preparing to unpack .../bsdutils_1%3a2.40-8_amd64.deb ...
Unpacking bsdutils (1:2.40-8) over (1:2.40-6) ...
Setting up bsdutils (1:2.40-8) ...
(Reading database ... 417244 files and directories currently installed.)
Preparing to unpack .../libperl5.38t64_5.38.2-4_amd64.deb ...
Unpacking libperl5.38t64:amd64 (5.38.2-4) over (5.38.2-3.2+b2) ...
Preparing to unpack .../perl_5.38.2-4_amd64.deb ...
Unpacking perl (5.38.2-4) over (5.38.2-3.2+b2) ...
Preparing to unpack .../perl-base_5.38.2-4_amd64.deb ...
Unpacking perl-base (5.38.2-4) over (5.38.2-3.2+b2) ...
Setting up perl-base (5.38.2-4) ...
(Reading database ... 417241 files and directories currently installed.)
Preparing to unpack .../0-perl-modules-5.38_5.38.2-4_all.deb ...
Unpacking perl-modules-5.38 (5.38.2-4) over (5.38.2-3.2) ...
Preparing to unpack .../1-eject_2.40-8_amd64.deb ...
Unpacking eject (2.40-8) over (2.40-6) ...
Preparing to unpack .../2-bsdextrautils_2.40-8_amd64.deb ...
Unpacking bsdextrautils (2.40-8) over (2.40-6) ...
Preparing to unpack .../3-util-linux-extra_2.40-8_amd64.deb ...
Adding 'diversion of /sbin/ctrlaltdel to /sbin/ctrlaltdel.usr-is-merged by 
util-linux-extra'
Adding 'diversion of /sbin/fsck.cramfs to /sbin/fsck.cramfs.usr-is-merged by 
util-linux-extra'
Adding 'diversion of /sbin/fsck.minix to /sbin/fsck.minix.usr-is-merged by 
util-linux-extra'
Adding 'diversion of /sbin/mkfs.bfs to /sbin/mkfs.bfs.usr-is-merged by 
util-linux-extra'
Adding 'diversion of /sbin/mkfs.cramfs to /sbin/mkfs.cramfs.usr-is-merged by 
util-linux-extra'
Adding 'diversion of /sbin/mkfs.minix to /sbin/mkfs.minix.usr-is-merged by 
util-linux-extra'
Unpacking util-linux-extra (2.40-8) over (2.40-6) ...
Preparing to unpack .../4-fdisk_2.40-8_amd64.deb ...
Unpacking fdisk (2.40-8) over (2.40-6) ...
Preparing to unpack .../5-libsmartcols1_2.40-8_amd64.deb ...
Unpacking libsmartcols1:amd64 (2.40-8) over (2.40-6) ...
Setting up libsmartcols1:amd64 (2.40-8) ...
(Reading database ... 417253 files and directories currently installed.)
Preparing to unpack .../libblkid1_2.40-8_amd64.deb ...
Unpacking libblkid1:amd64 (2.40-8) over (2.40-6) ...
Setting up libblkid1:amd64 (2.40-8) ...
(Reading database ... 417253 files and directories currently installed.)
Preparing to unpack .../libmount1_2.40-8_amd64.deb ...
Unpacking libmount1:amd64 (2.40-8) over (2.40-6) ...
Setting up libmount1:amd64 (2.40-8) ...
(Reading database ... 417253 files and directories currently installed.)
Preparing to unpack .../mount_2.40-8_amd64.deb ...
Unpacking mount (2.40-8) over (2.40-6) ...
Preparing to unpack .../libuuid1_2.40-8_amd64.deb ...
Unpacking libuuid1:amd64 (2.40-8) over (2.40-6) ...
Setting up libuuid1:amd64 (2.40-8) ...
(Reading database ... 417253 files and directories currently installed.)
Preparing to unpack .../util-linux_2.40-8_amd64.deb ...
Unpacking util-linux (2.40-8) over (2.40-6) ...
Setting up util-linux (2.40-8) ...
fstrim.service is a disabled or a static unit not running, not starting it.
dpkg: error: dpkg frontend lock was locked by another process with pid 58569
Note: removing the lock file is always wrong, can damage the locked area
and the entire system. See .
==  How can you help?  (doc: https://wiki.debian.org/how-can-i-help ) ==

-  Show old opportunities as well as new ones: how-can-i-help --old  -
E: Sub-process /usr/bin/dpkg returned an error code (2)
Setting up bsdextrautils (2.40-8) ...
dpkg: dependency problems prevent configuration of fdisk:
 fdisk depends on libfdisk1 (= 2.40-8); however:
  Version of libfdisk1:amd64 on system is 2.40-6.

dpkg: error processing package fdisk (--configure):
 dependency problems - leaving unconfigured
Setting up eject (2.40-8) ...
Setting up perl-modules-5.38 (5.38.2-4) ...
Setting up mount (2.40-8) ...
Setting up libperl5.38t64:amd64 (5.38.2-4) ...
Setting up util-linux-extra (2.40-8) ...
Setting up perl (5.38.2-4) ...
Processing triggers for libc-bin (2.37-19) ...
Processing triggers for man-db (2.12.1-1) ...
Processing triggers for mailcap (3.70+nmu1) ...
Errors were encountered while processing:
 fdisk

There seem to be 2 issues: one with the dpkg lock (which may be
bug 1069183 in aptitude) and one with fdisk.

It is not clear whether they are related. At least, bug 1069183
shouldn't be the cause of a bad ordering between package unpacking
and setup, which would rather be due to a dependency problem, as
indicated by the dpkg error message.

-- 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, 

Bug#1069860: lightdm-gtk-greeter: should not recommend the transitional package policykit-1

[Vincent Lefevre]

Package: lightdm-gtk-greeter
Version: 2.0.9-1
Severity: normal

lightdm-gtk-greeter 2.0.9-1 has

  Recommends: [...], polkitd | policykit-1

policykit-1 is now a transitional package. lightdm-gtk-greeter should
not recommend it (even in an OR dependency), otherwise apt or aptitude
cannot propose its removal.

This is even more important now that deborphan has been removed from
Debian.

-- 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.6.15-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 lightdm-gtk-greeter depends on:
ii  libayatana-ido3-0.4-00.10.1-1+b2
ii  libayatana-indicator3-7  0.9.4-1
ii  libc62.37-18
ii  libcairo21.18.0-3+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b3
ii  libglib2.0-0t64  2.78.4-7
ii  libgtk-3-0t643.24.41-4
ii  liblightdm-gobject-1-0   1.32.0-5
ii  libx11-6 2:1.8.7-1

Versions of packages lightdm-gtk-greeter recommends:
ii  adwaita-icon-theme  46.0-1
ii  desktop-base12.0.6+nmu1
ii  gnome-themes-extra  3.28-2+b2
ii  policykit-1 124-2
ii  polkitd 124-2

lightdm-gtk-greeter suggests no packages.

-- Configuration Files:
/etc/lightdm/lightdm-gtk-greeter.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#1023192: linux-image-6.0.0-2-amd64: Bluetooth no longer works: hci0: Reading Intel version command failed (-110)

[Vincent Lefevre]

Control: tags -1 unreproducible - fixed-upstream
Control: close -1

On 2022-11-09 17:16:06 +0100, Vincent Lefevre wrote:
> I've tried a couple of cold boots, but this did not reproduce the
> issue. Perhaps the bug is rare with my laptop and more common with
> some other hardware.

AFAIK, I've never had the issue again.

On 2024-04-25 17:39:16 +, Debian Bug Tracking System wrote:
> > # remote status report for #1023192 (http://bugs.debian.org/1023192)
> > # Bug title: linux-image-6.0.0-2-amd64: Bluetooth no longer works: hci0: 
> > Reading Intel version command failed (-110)
> > #  * http://bugzilla.kernel.org/show_bug.cgi?id=215167
> > #  * remote status changed: NEW -> RESOLVED
> > #  * remote resolution changed: (?) -> OBSOLETE
> > #  * closed upstream
> > tags 1023192 + fixed-upstream

No, the bug was closed as OBSOLETE, with the following comment:

"This bug report has become unintelligible. 

Please file a new one if you're still affected.

Make sure you have verified kernel 6.6.13 or 6.7.1 with the latest firmware."

So I'm retagging and closing the bug (I was the reporter, and no other
users got affected).

-- 
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#1069268: gnulib: package version is long

[Vincent Lefevre]

Hi Simon,

On 2024-04-19 09:13:01 +0200, Simon Josefsson wrote:
> Vincent Lefevre  writes:
> 
> > Package: gnulib
> > Version: 20240412~dfb7117+stable202401.20240408~aa0aa87-2
> > Severity: normal
> >
> > A long package version is annoying for the user (for the "dpkg -l"
> > output and other reasons). I doubt that such a long version is
> > necessary;

I would also add that long version strings are truncated in the
aptitude TUI due to the limited terminal width.

> Hi Vincent and thanks for the report.
> 
> Yeah, I can sympathise with this concern, and deciding on the version
> scheme probably took me the most time in the last update.  Some
> discussion would help.  Quoting README.source:
[...]

Thanks for the explanations. However, I think that it is not the
goal of the Debian version string to entirely reflect all the
Debian-side and upstream-side versions involved. This may be a
good idea when the obtained version string is short enough and
easy to understand, but here, this is not the case. There are
probably better places to give such information, in a clearer
way. This could be in well-chosen files and/or output from
commands like "gnulib-tool --version" (see below).

> The only superflous information in the version strings are the dates,
> but removing them does not seem like it would improve on your concern,
> rather the opposite.  Maybe the dates are what makes sense for users.
> 
> And something like dates are needed for dpkg version ordering.

Yes, for version strings, dates are much more important than things
like commit ids (which just look like random characters).

> Some ideas for improvement:
> 
> 20240411+stable-1 - revert to earlier pattern, this loses the commit id
> information and which stable branch was used, potentially making it
> impossible to use the same pattern in the future if there is one Debian
> upload of 20240411+stable-1 and somehow upstream gnulib commits an
> important patch on the same date that we need to package.

In the *rare* case of an upstream commit at the same date, a suffix
can be used, something like 20240411-2+stable-1.

BTW, is the "+stable" really useful in the version string?
Such information could be given in the Debian changelog
(which is already the case) and at some other places.

If it is dropped, there's also:
  20240411-1 (first version)
  20240411a-1 (additional commit on the same date)

[...]
> To be honest, after writing all this, I'm no longer certain why anyone
> would really look at the version number at all for the gnulib Debian
> package.  A sequentially increasing number is sufficient for packaging
> reasons: if anyone really wants to know what git commits are inside the
> package, just read the source code in the package to find out.

IMHO, for additional version information, the Debian changelog is a
good place for the user + output from a standard command providing
the version, e.g. "gnulib-tool --version". Scripts can use such a
command to record the necessary information about software in log
files. By "standard", I mean that it needs to exist upstream.

For instance, for GCC, there is "gcc --version", where Debian adds
some information. In particular for gcc-snapshot:

$ gcc-snapshot --version
gcc (Debian 20240117-1) 14.0.1 20240117 (experimental) [master 
r14-8187-gb00be6f1576]
[...]

One has all the details... When compiling software, this can be
found in the generated config.log file, which is really nice for
bug reports and debugging.

And the gcc-snapshot version string is basically just a date.

Regards,

-- 
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#1069681: less does not escape special characters when outputting the filename

[Vincent Lefevre]

Package: less
Version: 590-2.1
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

"less" does not escape special characters when outputting the
filename, either in the status line or in an error message.

With untrusted filenames (like in CVE-2024-32487), weird things
can happen in the terminal, which might be used for attacks.

For instance,

$ echo foo > test$'\033'\[\?40h$'\033'\[\?3h
$ less test$'\033'\[\?40h$'\033'\[\?3h

(in shells that understand the $'...' syntax, such as bash or zsh)
resizes the xterm window from 80 columns to 132 columns.

I can't reproduce this issue with the upstream version when the
file is viewable (the status line can be a bit incorrect, though);
I suppose that there was some fix in the recent past. When the
file is not viewable, same problem due to the error message. I've
reported the bug here:

  https://github.com/gwsw/less/issues/503

-- 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.6.15-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 less depends on:
ii  libc6  2.37-18
ii  libtinfo6  6.4+20240414-1

less recommends no packages.

less 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#1055190: apt: autoremove forgets a package

[Vincent Lefevre]

On 2024-04-22 03:19:36 +0200, Vincent Lefevre wrote:
> On 2024-04-21 12:03:05 +0200, David Kalnischkies wrote:
> > Controlling autoremoval behaviour is `APT::AutoRemove::SuggestsImportant`
> > which defaults to `true` as the autoremover could potentially break some
> > usecase for you that the suggests enabled and you have grown attached to
> > even through the suggests was once installed for another reason.
> 
> OK, I had actually that on my old machines, but for some reason,
> I didn't remember that and didn't notice that this was missing on
> new machines (and there was a bug in my script that checked the
> consistency of the config between machines).

I meant that I had

  APT::AutoRemove::SuggestsImportant "false";

in a config file on old machines (added 6 years ago), but this
file was missing on the new machines, and I did not remember of
the existence of this setting because:

> But the fact that this is a hidden setting did not help, i.e. it is
> not mentioned in the documentation (apt(8), apt-get(8), apt.conf(5),
> apt-config(8) man pages, APT User's Guide), while the description of
> "apt autoremove" is misleading ("dependencies" is used twice in the
> same sentence with 2 different meanings!).

-- 
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#1055190: apt: autoremove forgets a package

[Vincent Lefevre]

On 2024-04-21 12:03:05 +0200, David Kalnischkies wrote:
> On Sun, Apr 21, 2024 at 03:35:28AM +0200, Vincent Lefevre wrote:
> > > root@qaa:~# dpkg -s libtest-fatal-perl:amd64
> > > dpkg-query: package 'libtest-fatal-perl' is not installed and no 
> > > information is available
> > > Use dpkg --info (= dpkg-deb --info) to examine archive files.
[...]
> > Well, this isn't really the right explanation. This is due to an
> > output bug in apt, which should have output "libtest-fatal-perl:all"
> > instead of "libtest-fatal-perl:amd64".
> 
> That might be your preference (now), but it would be wrong in terms of
> apt and I am sure if you think a bit more about it you will agree:
> 
> A package is not arch:all. People say that all the time, but only
> because they mean that "this version of the package is arch:all" as we
> tend to talk about a *.deb file as a package and that contains
> a specific version.
> 
> If apt were to display "libtest-fatal-perl:all" it would mean that if
> that package becomes arch:any in the next version apt would need
> to show "removing: libtest-fatal-perl:all" and "new install:
> libtest-fatal-perl:amd64" instead of as an "upgrade" among many other
> very annoying things around architectures.
> 
> So, for apt, "libtest-fatal-perl:all" is treated like
> "libtest-fatal-perl:native" aka "libtest-fatal-perl:amd64" for you, so
> that if a binary package is arch:any or arch:all is an implementation
> detail for a user – as it should be – as that changes over time.
> The native architecture does not change as often, if at all.
> 
> So, in other words, for apt a "package" is usually a set of versions
> which can have different architectures, while for dpkg a package is
> a single version (except if it is not, like in that same arch:all to
> arch:any flip; but users don't speak to dpkg that often and especially
> not in that moment. apt does for them…).
> 
> In a way, you could complain that dpkg is so anal about the arch
> instead, but in its own world and context, it makes sense.

But here, "apt install ..." outputs libtest-fatal-perl:amd64, which is
a particular version of this package. And just after the installation,
"dpkg -s ..." refers to exactly the same version. So one should expect
that both tools use a common name to designate the package.

> > So, there's only a "Suggests", and note that I do not install
> > "Suggests" by default.
> 
> While you don't install Suggests via `APT::Install-Suggests` which is
> `false` by default, that has no bearing on the autoremoval.
> 
> Controlling autoremoval behaviour is `APT::AutoRemove::SuggestsImportant`
> which defaults to `true` as the autoremover could potentially break some
> usecase for you that the suggests enabled and you have grown attached to
> even through the suggests was once installed for another reason.

OK, I had actually that on my old machines, but for some reason,
I didn't remember that and didn't notice that this was missing on
new machines (and there was a bug in my script that checked the
consistency of the config between machines).

But the fact that this is a hidden setting did not help, i.e. it is
not mentioned in the documentation (apt(8), apt-get(8), apt.conf(5),
apt-config(8) man pages, APT User's Guide), while the description of
"apt autoremove" is misleading ("dependencies" is used twice in the
same sentence with 2 different meanings!).

-- 
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#1069585: apt: autoremoval forgets transitional packages in a OR dependency

[Vincent Lefevre]

Control: retitle -1 synaptic: should not depend on the transitional package 
policykit-1

On 2024-04-21 12:25:45 +0200, David Kalnischkies wrote:
> synaptics could drop the or on policykit-1 – or if for some reason
> keeping it is desirable make it a versioned on, like:
> |   pkexec | policykit-1 (<< first-transitional-version~)

OK. I've also reported a bug against network-manager, which has the
same issue.

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

Bug#1069636: network-manager: should not depend on the transitional package policykit-1

[Vincent Lefevre]

Package: network-manager
Version: 1.46.0-1+b2
Severity: normal

network-manager currently has

  Depends: [...] polkitd | policykit-1

policykit-1 is now a transitional package. network-manager should not
depend on it (even in an OR dependency), otherwise apt or aptitude
cannot propose its removal.

This is even more important now that deborphan has been removed from
Debian.

-- 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.6.15-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 network-manager depends on:
ii  adduser 3.137
ii  dbus [default-dbus-system-bus]  1.14.10-4+b1
ii  libaudit1   1:3.1.2-2.1
ii  libbluetooth3   5.73-1
ii  libc6   2.37-18
ii  libcurl3t64-gnutls  8.7.1-3
ii  libglib2.0-0t64 2.78.4-6
ii  libgnutls30t64  3.8.5-2
ii  libjansson4 2.14-2+b2
ii  libmm-glib0 1.22.0-3+b1
ii  libndp0 1.8-1
ii  libnewt0.52 0.52.24-2
ii  libnm0  1.46.0-1+b2
ii  libpsl5t64  0.21.2-1.1
ii  libreadline8t64 8.2-4
ii  libselinux1 3.5-2+b2
ii  libsystemd0 255.4-1+b1
ii  libteamdctl01.31-1
ii  libudev1255.4-1+b1
ii  policykit-1 124-2
ii  polkitd 124-2
ii  udev255.4-1+b1

Versions of packages network-manager recommends:
ii  dnsmasq-base [dnsmasq-base]  2.90-3
ii  libpam-systemd   255.4-1+b1
ii  modemmanager 1.22.0-3+b1
ii  ppp  2.5.0-1+2
ii  wireless-regdb   2022.06.06-1
ii  wpasupplicant2:2.10-21+b1

Versions of packages network-manager suggests:
ii  iptables   1.8.10-3
pn  libteam-utils  

Versions of packages network-manager is related to:
ii  isc-dhcp-client  4.4.3-P1-5

-- no debconf information

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

Bug#1069632: viking: ruler tool makes viking hang due to uninitialized value

[Vincent Lefevre]

Package: viking
Version: 1.10-3
Severity: important
Tags: upstream fixed-upstream patch

The ruler tool makes viking hang due to an uninitialized value.

Until now I was using the attached patch fixing this problem, from

https://github.com/viking-gps/viking/pull/175/commits/a68acdedbe7421e9980b6611229f92f5be2b65fb

See https://github.com/viking-gps/viking/pull/175

-- 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.6.15-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 viking depends on:
ii  gpsbabel 1.9.0+ds-2+b2
ii  libbz2-1.0   1.0.8-5.1
ii  libc62.37-18
ii  libcairo21.18.0-3+b1
ii  libcurl3t64-gnutls   8.7.1-3
ii  libexpat12.6.2-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b3
ii  libgeoclue-2-0   2.7.1-2+b1
ii  libgexiv2-2  0.14.2-2+b2
ii  libglib2.0-0t64  2.78.4-6
ii  libgps30t64  3.25-3+b1
ii  libgtk-3-0t643.24.41-4
ii  libjson-glib-1.0-0   1.8.0-2+b1
ii  libmagic1t64 1:5.45-3
ii  libnettle8t643.9.1-2.2
ii  liboauth01.0.3-5+b1
hi  libpango-1.0-0   1.51.0+ds-4
hi  libpangocairo-1.0-0  1.51.0+ds-4
ii  libsqlite3-0 3.45.3-1
ii  libx11-6 2:1.8.7-1
ii  libzip4t64   1.7.3-1.1+b1
ii  zlib1g   1:1.3.dfsg-3.1

Versions of packages viking recommends:
ii  expect [expect-dev]  5.45.4-3

Versions of packages viking suggests:
pn  gpsd  
ii  yelp  42.2-1+b2

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
diff --git a/src/vikviewport.c b/src/vikviewport.c
index 85adb891..3f696ab2 100644
--- a/src/vikviewport.c
+++ b/src/vikviewport.c
@@ -2026,6 +2026,7 @@ void vik_viewport_compute_bearing ( VikViewport *vp, gint 
x1, gint y1, gint x2,
 *baseangle = M_PI - atan2(tx-x1, ty-y1);
 *angle -= *baseangle;
   } else{
+*baseangle = 0;
 *angle = atan2((y2-y1), (x2-x1)) + M_PI_2;
   }
 

Bug#477166: aptitude: Does not automatically remove python-elementtree after upgrading python to 2.5

[Vincent Lefevre]

On 2008-04-21 19:13:43 -0700, Daniel Burrows wrote:
[...]
>   The autoremoval stuff is designed to be conservative in what it
> removes: it only removes packages if it can prove that nothing depends
> on them.  This sometimes results in oddities like the above, but those
> are much better than the alternative.  *Even if* a complicated algorithm
> existed to decide what should be removed (and as I noted above, I don't
> believe any such algorithm exists because the package that should be
> removed is not a function of the inputs to the dependency resolver), I
> think the grounds of simplicity and comprehensibility argue in favor of
> aptitude's current behavior.  When it misbehaves, you can understand why
> without reading an AI textbook first. :)

Since this does not apply to transitional packages, I've submitted
a new bug for the case where such packages appear in a OR dependency:

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

This now also becomes more important as deborphan has been removed
from Debian, so that one can only rely on "apt autoremove".

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

Bug#1069585: apt: autoremoval forgets transitional packages in a OR dependency

[Vincent Lefevre]

Package: apt
Version: 2.9.1
Severity: normal

There is the wontfix bug

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

"apt: autoremoval keeps all branches of an OR on the system even if
I don't want one".

While I can understand the reason why this is wontfix, this reason
makes no sense on transitional packages.

As an example:

qaa:~> apt autoremove -s
NOTE: This is only a simulation!
  apt needs root privileges for real execution.
  Keep also in mind that locking is deactivated,
  so don't depend on the relevance to the real current situation!
Summary:
  Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 82

but policykit-1 (marked as automatically installed) could be removed:

qaa:~> aptitude remove -s policykit-1
The following packages will be REMOVED:  
  policykit-1 
0 packages upgraded, 0 newly installed, 1 to remove and 82 not upgraded.
Need to get 0 B of archives. After unpacking 34.8 kB will be freed.
Would download/install/remove packages.

I suppose that "apt autoremove" doesn't remove it because of
the OR dependency:

qaa:~> aptitude why policykit-1
i   synaptic Depends pkexec | policykit-1

(at least, this seems to be one of the reasons).

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Key "";
APT::Key::Assert-Pubkey-Algo ">=rsa2048,ed25519,ed448";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::AutoRemove "";
APT::AutoRemove::SuggestsImportant "false";
APT::Clean-Installed "false";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "test -x /usr/bin/apt-show-versions || exit 
0 ; apt-show-versions -i";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/swcatalog -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh --source=os > /dev/null || 
true; fi";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary 

Bug#1055190: apt: autoremove forgets a package

[Vincent Lefevre]

Control: found -1 2.9.1

On 2023-11-01 21:53:26 +0100, Vincent Lefevre wrote:
> Package: apt
> Version: 2.6.1
> Severity: normal
> 
> I've installed several -perl packages with "apt install", including
> libio-async-perl, and libtest-fatal-perl:amd64 was automatically
> installed as a dependency:
> 
> Start-Date: 2023-11-01  21:03:35
> Commandline: apt install libio-async-perl
> Install: libdevel-mat-dumper-perl:amd64 (0.46-1+b1, automatic), 
> libio-async-perl:amd64 (0.802-1), libtest-fatal-perl:amd64 (0.017-1, 
> automatic), libtest-metrics-any-perl:amd64 (0.01-2, automatic), 
> libsereal-perl:amd64 (5.003-1, automatic), libmetrics-any-perl:amd64 (0.09-1, 
> automatic), libstruct-dumb-perl:amd64 (0.14-1, automatic), 
> libtest-refcount-perl:amd64 (0.10-4, automatic), 
> libasync-mergepoint-perl:amd64 (0.04-4, automatic)
> End-Date: 2023-11-01  21:03:39
> 
> A bit later, I found that this was not needed, so that I removed the
> packages and also did a "apt autoremove --purge". Now, this command
> says:
> 
> root@qaa:~# apt autoremove --purge
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> 
> but while libtest-fatal-perl:amd64 (from /var/log/apt/history.log
> above) isn't installed, libtest-fatal-perl still is:
> 
> root@qaa:~# dpkg -s libtest-fatal-perl:amd64
> dpkg-query: package 'libtest-fatal-perl' is not installed and no information 
> is available
> Use dpkg --info (= dpkg-deb --info) to examine archive files.
> 
> root@qaa:~# dpkg -s libtest-fatal-perl
> Package: libtest-fatal-perl
> Status: install ok installed
> Priority: optional
> Section: perl
> Installed-Size: 43
> Maintainer: Debian Perl Group 
> Architecture: all
> Multi-Arch: foreign
> Version: 0.017-1
> Depends: perl:any, libtry-tiny-perl

Well, this isn't really the right explanation. This is due to an
output bug in apt, which should have output "libtest-fatal-perl:all"
instead of "libtest-fatal-perl:amd64".

> So "apt autoremove" forgot it.

And I can reproduce the issue on another machine:

disset:~> apt-mark showauto | grep libtest-fatal-perl
libtest-fatal-perl

disset:~> apt autoremove -s
NOTE: This is only a simulation!
  apt needs root privileges for real execution.
  Keep also in mind that locking is deactivated,
  so don't depend on the relevance to the real current situation!
Summary:
  Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 18

disset:~> aptitude why libtest-fatal-perl
i   libmastodon-client-perl Depends  libdatetime-perl  
i A libdatetime-perlDepends  libspecio-perl
i A libspecio-perl  Suggests libtest-fatal-perl

disset:~> aptitude remove -s libtest-fatal-perl
The following packages will be REMOVED:  
  libtest-fatal-perl 
0 packages upgraded, 0 newly installed, 1 to remove and 18 not upgraded.
Need to get 0 B of archives. After unpacking 44.0 kB will be freed.
Would download/install/remove packages.

So, there's only a "Suggests", and note that I do not install
"Suggests" by default.

The only place this package appears in the history is

Start-Date: 2024-01-06  02:53:49
Commandline: apt install libhtml-gumbo-perl libidn-dev libimage-exiftool-perl 
libipc-run-perl liblinux-inotify2-perl libmastodon-client-perl
Install: libdevel-mat-dumper-perl:amd64 (0.47-1, automatic), 
libclass-load-perl:amd64 (0.25-2, automatic), libsafe-isa-perl:amd64 
(1.10-1, automatic), libmastodon-client-perl:amd64 (0.017-2), 
libhash-multivalue-perl:amd64 (0.16-3, automatic), 
libimage-base-bundle-perl:amd64 (1.0.7-3.5, automatic), libio-async-perl:amd64 
(0.802-2, automatic), libtest-fatal-perl:amd64 (0.017-1, automatic), 
pkgconf:amd64 (1.8.1-1, automatic), libtest-metrics-any-perl:amd64 (0.01-2, 
automatic), libcompress-raw-lzma-perl:amd64 (2.206-2, automatic), 
libsereal-perl:amd64 (5.004-1, automatic), libio-async-ssl-perl:amd64 (0.25-1, 
automatic), libidn-dev:amd64 (1.41-1), libhtml-gumbo-perl:amd64 (0.18-3+b2), 
libimage-info-perl:amd64 (1.44-1, automatic), libimage-exiftool-perl:amd64 
(12.67+dfsg-1), libmetrics-any-perl:amd64 (0.10-1, automatic), 
libcompress-bzip2-perl:amd64 (2.28-1+b3, automatic), pkg-config:amd64 (1.8.1-1, 
automatic), libfuture-perl:amd64 (0.50-1, automatic), 
liblinux-inotify2-perl:amd64 (1:2.3-2), libstruct-dumb-perl:amd64 (0.14-1, 
automatic), pkgconf-bin:amd64 (1.8.1-1, automatic), 
libtypes-path-tiny-perl:amd64 (0.006-2, automatic), libtest-refcount-perl:amd64 
(0.10-4, automatic), libpkgconf3:amd64 (1.8.1-1, automatic), 
libasync-mergepoint-perl:amd64 (0.04-4, automatic), libhttp-thin-perl:amd64 
(0.006-2, automatic), libnet-async-http-perl:amd64 (0.49-1, automatic), 
librole-eventemitter-p

Bug#1067316: gnucash-docs: FTBFS: Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: libharfbuzz.so.0: cannot open shared object file:

[Vincent Lefevre]

[Not reassigning yet to openjdk-17-jre-headless, as the change
was done on purpose, but Cc-ing the OpenJDK Team.]

Hi,

Since no-one looked at this issue in a month and gnucash-docs
has now been removed from testing...

On 2024-03-20 22:03:18 +0100, Lucas Nussbaum wrote:
[...]
> > Exception in thread "main" java.lang.UnsatisfiedLinkError: 
> > /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: libharfbuzz.so.0: 
> > cannot open shared object file: No such file or directory
[...]

Indeed, on my machine

qaa:~> ldd /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so | grep 
libharfbuzz
libharfbuzz.so.0 => /lib/x86_64-linux-gnu/libharfbuzz.so.0 
(0x7fe984534000)

where /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so
comes from openjdk-17-jre-headless, but the build log shows
that libharfbuzz0b is not installed, while being recommended by
openjdk-17-jre-headless. However, I would say that even though
libharfbuzz.so.0 is used by a particular library, this should
be a "Depends:", not a "Recommends:". In any case, I think
that gnucash-docs is not supposed to know the libfontmanager.so
internals, i.e. this cannot be a bug in gnucash-docs.

But also

qaa:~> ldd /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so | grep 
freetype
libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 
(0x7f835ed1d000)

while libfreetype6 is also only recommended.

openjdk-17 (17.0.10+7-3) unstable; urgency=medium
[...]
  * Make the dependencies for libfontmanager.so and libjsound.so
recommendations in jre-headless, and dependencies in jre.
[...]
 -- Matthias Klose   Mon, 11 Mar 2024 16:08:33 +0100

which was done in commit

https://salsa.debian.org/openjdk-team/openjdk/-/commit/6f0e4b17a1ff58aaf32da9be9abcf0224c481885

But why?

A warning has been added in

https://salsa.debian.org/openjdk-team/openjdk/-/commit/8010273018af3ada65de8901735ab60bb0dd5c0e

but this is the kind of things that building systems will ignore.

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

Bug#885414: base-files: lack of quoting in shell variable expansions in /etc/profile

[Vincent Lefevre]

On 2024-04-20 19:40:16 +0100, Richard Lewis wrote:
> fwiw my understanding is that release-notes should be used less often, than
> NEWS.Debian because
> - it only covers stable-to-stable upgrades (i doubt many unstable users
> read it at all - certainly at the moment i don't think there is any single
> post-bookworm content)
> - release-notes will only be ready once, on stable upgrades, whereas
> NEWS.Debian might be more useful for people tracking unstable (personally i
> would hope everything in release-notes is covered in NEWS.Debian for that
> reason!)
> - release-notes is meant to be understandable by less experienced
> non-technical "users" (all documentation should of course aim for that, in
> theory)
> - NEWS.Debian is "opt-in": if you install apt-listchanges you'll see
> NEWS.Debian, but that package isnt installed by the default. Even fewer
> users will read the changelog (although apt-listchanges can email that as
> well)

As a user of both Debian/stable and Debian/unstable machines,
I have apt-listchanges installed on all machines, but this is
most useful for Debian/unstable (I also have a quick look at
the changelog). I don't remember about the release notes with
stable upgrades.

BTW, during the package upgrade, if there are /etc/profile.d files
that were sourced but that will no longer be, I think that the user
should specifically be warned about them.

I'm also wondering whether some message should be output on the
standard error if there are *.sh files that do not satisfy the
regexp (but run-parts cannot do that).

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

Bug#990264: ksh: output error is not checked for some builtins

[Vincent Lefevre]

Control: reassign -1 ksh93u+m
Control: found -1 1.0.4-3
Control: found -1 1.0.8-1
Control: tag -1 upstream
Control: forwarded -1 https://github.com/ksh93/ksh/issues/313

Forgot the "Control:".

Also: note the reassign due to the package rename of ksh to ksh93u+m
in September 2021. 1.0.4-3 is the current stable, and 1.0.8-1 the
current unstable version.

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

Bug#990264: ksh: output error is not checked for some builtins

[Vincent Lefevre]

reassign -1 ksh93u+m
found -1 1.0.4-3
found -1 1.0.8-1
tag -1 upstream
forwarded -1 https://github.com/ksh93/ksh/issues/313

Bug#1069341: ksh93u+m should not be advertised as being POSIX compliant

[Vincent Lefevre]

Package: ksh93u+m
Version: 1.0.8-1
Severity: minor

The ksh93u+m package description contains

 KornShell is an interactive UNIX command interpreter as well as a POSIX
   ^
 compliant scripting language which is a superset of sh(1), the System
 ^
 V UNIX shell.
 .
 The ksh93 version of KornShell has the functionality of other scripting
 languages such as AWK, Icon, Perl, Rexx, Tcl and is a full-featured,
 expressive scripting language which complies with POSIX.2 Shell and
   ^
 Utilities (IEEE Std 1003.2-1992).
 

But POSIX compliance is not true by default. So this is misleading,
and the references to the POSIX compliance should be removed.

-- 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.6.15-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 ksh93u+m depends on:
ii  libc6  2.37-17

ksh93u+m recommends no packages.

Versions of packages ksh93u+m suggests:
pn  binfmt-support  

-- no debconf information

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

Bug#1052451: when receiving a SIGINT, unison should send it to the process group, not just to ssh

[Vincent Lefevre]

While doing tests, I've noticed a similar issue when I don't type
the passphrase and wait. In this case, there is a timeout from
unison: "Timed out negotiating connection with the server".
This corresponds (in src/remote.ml) to

let initConnection ?(connReady=fun () -> ()) ?cleanup in_ch out_ch =
  (* [makeConnection] is not expected to raise any recoverable exceptions.
 If this assumption changes in the future then [in_ch] and [out_ch] must
 be closed in the recovery code. *)
  let conn = makeConnection false in_ch out_ch in
  let close_on_fail t =
Lwt.catch (fun () -> t) (fun e -> closeConnection conn; Lwt.fail e)
  in
  let with_timeout t =
Lwt.choose [t;
  Lwt_unix.sleep 120. >>= fun () ->
  Lwt.fail (Util.Fatal "Timed out negotiating connection with the server")]
  in
  close_on_fail (with_timeout (
peekWithBlocking conn.inputBuffer >>= fun _ ->
connReady (); Lwt.return () >>= fun () -> (* Connection working, notify *)
checkHeader conn >>=
checkServerUpgrade conn >>=
checkServerVersion conn)) >>= fun () ->
  registerConnCleanup conn cleanup;
[...]

I can see that the process gets a SIGTERM.

But at least in this case, I think that unison is correct, and that my
wrapper should catch the signal and kill its child process if there is
one. And it could do that for SIGINT too (original issue).

In short, it may not be worth to change unison.

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

Bug#1069268: gnulib: package version is long

[Vincent Lefevre]

Package: gnulib
Version: 20240412~dfb7117+stable202401.20240408~aa0aa87-2
Severity: normal

A long package version is annoying for the user (for the "dpkg -l"
output and other reasons). I doubt that such a long version is
necessary; I'm wondering whether it is intended or is due to a
bug in a script (the "Fix gnulib-tool --version" seems to have
done nothing significant).

-- 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.6.15-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

gnulib depends on no packages.

Versions of packages gnulib recommends:
ii  autoconf 2.71-3+local2
ii  automake 1:1.16.5-1.3
ii  autopoint0.21-14
ii  bison2:3.8.2+dfsg-1+b1
ii  build-essential  12.10
ii  gettext  0.21-14+b1
ii  gperf3.1-1
ii  libtool  2.4.7-7
ii  m4   1.4.19-4
ii  texinfo  7.1-3

Versions of packages gnulib suggests:
pn  clisp
ii  git  1:2.43.0-1+b1
ii  perl 5.38.2-3.2+b2
ii  python3  3.11.8-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#885414: base-files: lack of quoting in shell variable expansions in /etc/profile

[Vincent Lefevre]

Hi,

On 2024-04-17 13:55:31 +0200, Santiago Vila wrote:
> The problem, more than lack of quoting, is that there is no specification
> anywhere about what should be allowed and what should not.
> 
> But we are not late to begin such specification.
> Here is my current plan:
> 
> --- a/share/profile
> +++ b/share/profile
> @@ -25,7 +25,7 @@ if [ "${PS1-}" ]; then
>  fi
>  if [ -d /etc/profile.d ]; then
> -  for i in /etc/profile.d/*.sh; do
> +  for i in $(run-parts --list --regex '^[a-zA-Z0-9._-]+.sh$' 
> /etc/profile.d); do
>  if [ -r $i ]; then
>. $i
>  fi

This is wrong in multiple ways:
  * It would now include "hidden" files (i.e. with a name starting
with a "."). And I think that filenames starting with "-" should
also be ignored.
  * It would include the .csh files, such as "gawk.csh".

So I think that the --regex argument should be

  '^[a-zA-Z0-9_][a-zA-Z0-9._-]*\.sh$'

Regards,

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

Bug#1069123: RM: libreoffice != 24.3/experimental [armhf ppc64el s390x mips64el riscv64] -- ROM, NVIU; obsolete cruft

[Vincent Lefevre]

Hi,

Has the removal request been done by mistake?

Note that *all* the bugs against libreoffice (sources package
and binary packages) have been closed.

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

Bug#1069139: developers-reference: out-of-date section "Make transition packages deborphan compliant"

[Vincent Lefevre]

Package: developers-reference
Version: 13.5
Severity: normal

Now that the deborphan package has been removed from unstable,
the section "Make transition packages deborphan compliant" in
"Best Packaging Practices" is out of date and should be updated.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065312
where "apt-mark auto ..." (for autoremove) is suggested as a
replacement. But with it, putting transition packages to oldlibs
is even more necessary.

-- 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.6.15-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

developers-reference depends on no packages.

Versions of packages developers-reference recommends:
ii  debian-policy4.7.0.0
ii  libjs-sphinxdoc  7.2.6-6
ii  sensible-utils   0.0.22

Versions of packages developers-reference suggests:
pn  doc-base   
ii  elinks [www-browser]   0.16.1.1-4.1+b2
ii  firefox [www-browser]  124.0.1-1
ii  firefox-esr [www-browser]  115.9.1esr-1
ii  links [www-browser]2.29-1+b3
ii  links2 [www-browser]   2.29-1+b3
ii  lynx [www-browser] 2.9.0rel.0-2+b1
ii  w3m [www-browser]  0.5.3+git20230121-2+b3

-- no debconf information

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

Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Vincent Lefevre]

On 2024-04-17 01:39:48 +0200, Vincent Lefevre wrote:
> On 2024-03-11 15:18:44 +0100, Chris Hofstaedtler wrote:
> > Thus, a good approximation of the default deborphan functionality
> > (no additional options passed) is:
> > 
> > $ apt-mark auto '~i !~M 
> > (~slibs|~soldlibs|~slibdevel|~sintrospection|~sdebug)'
> > possibly followed by
> 
> No, to mimic deborphan, you should exclude ~slibdevel and ~sdebug
> from this list. So
> 
>   apt-mark auto '~i !~M (~slibs|~soldlibs|~sintrospection)'
[...]

I forgot: deborphan also had other rules. Something useful is that
it could detect dummy / transitional packages. It seems that apt
patterns cannot work on the package description.

https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html

recommends "Also, it is recommended to adjust its section to oldlibs
and its priority to optional in order to ease deborphan's job." but
this is not always done (this was not absolutely necessary for
deborphan, which could also look at the package descrption, but
for apt-mark, this is now a must).

-- 
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#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Vincent Lefevre]

On 2024-03-11 15:18:44 +0100, Chris Hofstaedtler wrote:
> Thus, a good approximation of the default deborphan functionality
> (no additional options passed) is:
> 
> $ apt-mark auto '~i !~M (~slibs|~soldlibs|~slibdevel|~sintrospection|~sdebug)'
> possibly followed by

No, to mimic deborphan, you should exclude ~slibdevel and ~sdebug
from this list. So

  apt-mark auto '~i !~M (~slibs|~soldlibs|~sintrospection)'

Let's recall the deborphan(1) man page:

  The default operation is to search within the libs, oldlibs and
  ^^^
  introspection sections to hunt down unused libraries.
  ^

Indeed, -dev packages are necessary to do development work on
non-Debian software (or just build such software); so, if such
packages have been manually installed, they must probably remain
installed and not be marked as auto.

Similarly, -dbgsym packages are typically installed by the user for
debugging purpose. However, such packages should be removed when
the associated library package would be removed if the -dbgsym
package were not there, but the above pattern will not catch that.
This was already an issue with deborphan:

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

On 2024-03-17 15:54:27 +0200, Martin-Éric Racine wrote:
> Another issue I've run into to try and replace deborphan with some
> apt-mark recipe: apt-mark's regex syntax is not documented. The man
> page merely lists the commands and options available.

I suspect that this is apt-patterns(7). The apt-mark(8) man page just
gives a reference to apt-get(8), which mentions apt-patterns(7), but
I think that a more direct reference should be given.

> For instance, I have no idea how you came up with the above regex
> recipe, or how I would tell apt-mark to never mark as "auto" anything
> with a priority important or higher.

I don't think that you should care of the priority. This was needed
for deborphan in order to ignore the "required" priority, but AFAIK,
apt will never propose to remove such packages.

The only thing that is missing with patterns is to be able to specify
a package list from a file, in order to mimic deborphan's keep-list:
/var/lib/deborphan/keep

But one could still write a simple wrapper to add "!?name(package_name)"
to the pattern for each package_name found in a keep-list file. It could
even be possible to provide regular expressions, which deborphan did not
support. For instance you could have a pattern_file file with

  ~i !~M (~slibs|~soldlibs|~sintrospection) !~n(pkg1|pkg2|pkg3)

and use

  apt-mark auto "$(cat /path/to/pattern_file)"

Before doing that, you could check with

  apt-mark showmanual "$(cat /path/to/pattern_file)"

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

Bug#1068787: dmeventd: inconsistent /etc/systemd/system/sockets.target.wants/dm-event.socket symlinks

[Vincent Lefevre]

Package: dmeventd
Version: 2:1.02.196-1+b1
Severity: normal

On this machine, I have

lrwxrwxrwx 1 root root 35 2023-10-07 13:43:24 
/etc/systemd/system/sockets.target.wants/dm-event.socket -> 
/lib/systemd/system/dm-event.socket

while on another machine (installed more recently):

lrwxrwxrwx 1 root root 39 2024-01-05 16:54:09 
/etc/systemd/system/sockets.target.wants/dm-event.socket -> 
/usr/lib/systemd/system/dm-event.socket

I suppose that the second one is the correct canonical path.

-- 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.6.15-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 dmeventd depends on:
ii  libc6 2.37-15.1
ii  libdevmapper-event1.02.1  2:1.02.196-1+b1
ii  libdevmapper1.02.12:1.02.196-1+b1
ii  liblvm2cmd2.032.03.22-1+b1

dmeventd recommends no packages.

dmeventd 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#1017720: nfs-common: No such file or directory

[Vincent Lefevre]

On 2024-04-09 14:09:43 +0200, Vincent Lefevre wrote:
> Some additional information: created only once, but data may be
> appended (on the creator's side, the file is created for writing,
> and data are written occasionally, and at some point, the file is
> closed). The error with "open" may occur even several hours after
> the last time data were written to the file.

This is actually reproducible with a read-only directory.
I've attached a Perl script to reproduce the issue, just
based on "stat".

The conditions seem to be:
  * The directory and the files need to be recent enough: I can't
reproduce the issue with an old directory, even if I add many
new files into it.
  * Concurrent "stat": with the attached script, the issue is
reproducible with 2 threads or more, but not with a single
thread.

Example of errors:

./dir-stat: can't stat . (x 2)
./dir-stat: can't stat 775 (x 148)
./dir-stat: can't stat 772 (x 1)
./dir-stat: can't stat 415 (x 1)
./dir-stat: can't stat 716 (x 1)
./dir-stat: can't stat 453 (x 1)
./dir-stat: can't stat 9 (x 1)
./dir-stat: can't stat 201 (x 1)
./dir-stat: can't stat 981 (x 1)
./dir-stat: can't stat 660 (x 1)
./dir-stat: can't stat 120 (x 1)
./dir-stat: can't stat 127 (x 1)
./dir-stat: can't stat 663 (x 1)

-- 
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)
#!/usr/bin/env perl

# Create a directory with several hundreds of files, for instance with
#   mkdir test && cd test && touch `seq 999`
# then run this Perl script with the directory name in argument.

use strict;
use threads;

my $maxthreads = 2;
my $nthreads = 0;

@ARGV == 1 or die "Usage: $0 \n";
my $dir = $ARGV[0];
-d $dir or die "$0: $dir is not a directory\n";

sub thr ($) {
  my $file = $_[0];
  my $err = 0;
  until (stat "$dir/$file")
{
  $err++;
  sleep 0.25;
}
  warn "$0: can't stat $file (x $err)\n" if $err;
}

sub join_threads () {
  my @thr;
  sleep 0.25 until @thr = threads->list(threads::joinable);
  foreach my $thr (@thr)
{ $thr->join(); }
  $nthreads -= @thr;
}

opendir DIR, $dir or die "$0: opendir failed ($!)\n";
while (my $file = readdir DIR)
  {
$nthreads < $maxthreads or join_threads;
$nthreads++ < $maxthreads or die "$0: internal error\n";
threads->create(\, $file);
  }
closedir DIR or die "$0: closedir failed ($!)\n";
join_threads while $nthreads;

Bug#1017720: nfs-common: No such file or directory

[Vincent Lefevre]

On 2024-04-04 14:56:47 +0200, Vincent Lefevre wrote:
> On 2023-11-29 16:19:02 +0100, Vincent Lefevre wrote:
> > I have the same kind of issue at my lab with one of my programs:
> > a readdir lists the file, but then a stat sometimes gives a
> > "No such file or directory" error. Some clients are more affected
> > that others.
> 
> And sometimes, the "stat" succeeds as expected, but the "open" that
> follows gives a "No such file or directory" error.
> 
> Also note that in my case, the file under this filename is unique:
> it is created only once (never deleted then recreated).

Some additional information: created only once, but data may be
appended (on the creator's side, the file is created for writing,
and data are written occasionally, and at some point, the file is
closed). The error with "open" may occur even several hours after
the last time data were written to the file.

-- 
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#1068637: apt does not always install Recommends

[Vincent Lefevre]

On 2024-04-08 19:26:42 +0200, David Kalnischkies wrote:
> On Mon, Apr 08, 2024 at 01:05:40PM +0200, Vincent Lefevre wrote:
> > On 2024-04-08 12:29:17 +0200, Julian Andres Klode wrote:
> > > On Mon, Apr 08, 2024 at 11:50:04AM +0200, Vincent Lefevre wrote:
> > > > The lvm2 package is installed, but not thin-provisioning-tools,
> > > > though lvm2 recommends it. This can yield a broken system:
> […]
> > It is not mandatory in all cases, but it some cases. In any case,
> > the "Recommends:" must be honored.
> 
> You haven't mentioned AT ALL if we are talking about upgrade or a fresh
> install of lvm2, for the later see below. For the former:

It was not an upgrade. For one of the machines, this was the status
a bit after the installation of bookworm. For the other machine, this
was the status just a bit after the installation of a weekly build on
2024-01-05.

Then, I don't know the internals. But according to Bastian Blank[*]:
"It is installed like everything else." (but see the details below).

[*] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068560#22

> > No, lvm2 was installed before the time_t transition. It actually
> > affects plain bookworm installations (on a machine where I installed
> > Debian 12.1 on 2023-10-07); you can see with the attached
> > "dpkg --get-selections" output I had at that time.
>   
> 
> What time? Before you installed lvm2? That output says lvm2 is
> installed. So after it, but what are you trying to tell us then?

A few hours after the installation of bookworm. You can see that lvm2
is installed, but not thin-provisioning-tools (which is the bug).
I mean that this has always been like that (so, if you think that
thin-provisioning-tools could have been installed as a Recommends,
then removed later, this is not the case).

> I just bootstrapped a minimal stable chroot with mmdebstrap and behold:
> | # apt install --install-recommends lvm2
> | Reading package lists... Done
> | Building dependency tree... Done
> | Reading state information... Done
> | The following additional packages will be installed:
> |   dmeventd dmsetup libaio1 libdevmapper-event1.02.1 libdevmapper1.02.1 
> liblvm2cmd2.03 thin-provisioning-tools
> | The following NEW packages will be installed:
> |   dmeventd dmsetup libaio1 libdevmapper-event1.02.1 libdevmapper1.02.1 
> liblvm2cmd2.03 lvm2 thin-provisioning-tools
> | 0 upgraded, 8 newly installed, 0 to remove and 0 not upgraded.
> | Need to get 2662 kB of archives.
> | After this operation, 9729 kB of additional disk space will be used.
> | Do you want to continue? [Y/n] n
> | Abort.
> 
> In other words your issue with a "plain bookworm" install is
> unreproducible

But what about the usual Debian installation on a real machine?

For the first machine (bookworm), I used an image via
  https://cdimage.debian.org/debian-cd/current/amd64/jigdo-cd/
namely, debian-12.1.0-amd64-netinst.iso, and I did the installation
by using a USB memory stick.

> So, if you want to have any chance of us investigating your problem as
> a bug rather than as a user-error you will have to tell us what you did
> exactly, preferably with easy to follow steps and output. Failing that,
> on your bookworm install you might be lucky and still have the
> installation/upgrade and such of lvm2 in your history.log(s).
> That might shine some light on it as well.

Indeed, in /var/log/apt/history.log.6.gz (note that I did not type
this command; so it came from the Debian installer):

Start-Date: 2023-10-07  13:43:22
Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o 
APT::Keep-Fds::=6 -q -y --no-remove install lvm2
Install: dmeventd:amd64 (2:1.02.185-2, automatic), libaio1:amd64 (0.3.113-4, 
automatic), liblvm2cmd2.03:amd64 (2.03.16-2, automatic), lvm2:amd64 
(2.03.16-2), libdevmapper-event1.02.1:amd64 (2:1.02.185-2, automatic)
End-Date: 2023-10-07  13:43:28

And for the second machine (weekly build):

Start-Date: 2024-01-05  16:54:09
Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o 
APT::Keep-Fds::=6 -q -y --no-remove install lvm2
Install: dmeventd:amd64 (2:1.02.185-2, automatic), libaio1:amd64 (0.3.113-5, 
automatic), liblvm2cmd2.03:amd64 (2.03.16-2, automatic), lvm2:amd64 
(2.03.16-2), libdevmapper-event1.02.1:amd64 (2:1.02.185-2, automatic)
End-Date: 2024-01-05  16:54:14

Now, this is clear that the recommended thin-provisioning-tools
package was not installed together with lvm2.

-- 
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#1068637: apt does not always install Recommends

[Vincent Lefevre]

On 2024-04-08 12:29:17 +0200, Julian Andres Klode wrote:
> On Mon, Apr 08, 2024 at 11:50:04AM +0200, Vincent Lefevre wrote:
> > The lvm2 package is installed, but not thin-provisioning-tools,
> > though lvm2 recommends it. This can yield a broken system:
> > 
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857142
> > 
> > the fix of this bug being
> > 
> >* Make lvm2 recommend thin-provisioning-tools. (closes: #857142)
> 
> That's a packaging bug. If the tool is mandatory for correct behavior
> of the system it should be a Depends.

It is not mandatory in all cases, but it some cases. In any case,
the "Recommends:" must be honored.

> In this particular instance you're getting bit by time_t transition
> issues and Recommends disappear on you (even if they may be satisfiable
> it may simply be easier to break the Recommends for apt than to figure
> out the right solution).

No, lvm2 was installed before the time_t transition. It actually
affects plain bookworm installations (on a machine where I installed
Debian 12.1 on 2023-10-07); you can see with the attached
"dpkg --get-selections" output I had 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)
accountsservice install
acl install
adduser install
adwaita-icon-theme  install
aisleriot   install
alsa-topology-conf  install
alsa-ucm-conf   install
alsa-utils  install
anacron install
analog  install
apache2 install
apache2-bin install
apache2-datainstall
apache2-doc install
apache2-utils   install
apg install
apparmorinstall
appstream   install
apt install
apt-config-iconsinstall
apt-listchanges install
apt-utils   install
aspell  install
aspell-en   install
at-spi2-common  install
at-spi2-coreinstall
avahi-autoipd   install
avahi-daemoninstall
baobab  install
base-files  install
base-passwd install
bashinstall
bash-completion install
bc  install
bind9-dnsutils  install
bind9-host  install
bind9-libs:amd64install
bluetooth   install
bluez   install
bluez-obexd install
bogofilter  install
bogofilter-bdb  install
bogofilter-common   install
boltinstall
brasero-common  install
bsdextrautils   install
bsdutilsinstall
bubblewrap  install
busybox install
bzip2   install
ca-certificates install
cdrdao  install
cheese  install
cheese-common   install
chrome-gnome-shell  install
coinor-libcbc3:amd64install
coinor-libcgl1:amd64install
coinor-libclp1:amd64install
coinor-libcoinmp1v5:amd64   install
coinor-libcoinutils3v5:amd64install
coinor-libosi1v5:amd64  install
colord  install
colord-data install
console-setup

Bug#1068637: apt does not always install Recommends

[Vincent Lefevre]

Package: apt
Version: 2.7.14
Severity: serious

The lvm2 package is installed, but not thin-provisioning-tools,
though lvm2 recommends it. This can yield a broken system:

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

the fix of this bug being

   * Make lvm2 recommend thin-provisioning-tools. (closes: #857142)

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Key "";
APT::Key::Assert-Pubkey-Algo ">=rsa2048,ed25519,ed448";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "test -x /usr/bin/apt-show-versions || exit 
0 ; apt-show-versions -i";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::extended_states "extended_states";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache "var/cache/apt";
Dir::Cache::archives "archives/";
Dir::Cache::srcpkgcache "srcpkgcache.bin";
Dir::Cache::pkgcache "pkgcache.bin";
Dir::Etc "etc/apt";
Dir::Etc::sourcelist "sources.list";
Dir::Etc::sourceparts "sources.list.d";
Dir::Etc::main "apt.conf";
Dir::Etc::netrc "auth.conf";
Dir::Etc::netrcparts "auth.conf.d";
Dir::Etc::parts "apt.conf.d";
Dir::Etc::preferences "preferences";
Dir::Etc::preferencesparts "preferences.d";
Dir::Etc::trusted "trusted.gpg";
Dir::Etc::trustedparts "trusted.gpg.d";
Dir::Etc::apt-listchanges-main "listchanges.conf";
Dir::Etc::apt-listchanges-parts "listchanges.conf.d";
Dir::Etc::apt-file-main "apt-file.conf";
Dir::Bin "";
Dir::Bin::methods "/usr/lib/apt/methods";
Dir::Bin::solvers "";
Dir::Bin::solvers:: "/usr/lib/apt/solvers";
Dir::Bin::planners "";
Dir::Bin::planners:: "/usr/lib/apt/planners";
Dir::Bin::dpkg "/usr/bin/dpkg";
Dir::Bin::gzip "/bin/gzip";
Dir::Bin::bzip2 "/bin/bzip2";
Dir::Bin::xz "/usr/bin/xz";
Dir::Bin::lz4 "/usr/bin/lz4";
Dir::Bin::zstd "/usr/bin/zstd";
Dir::Bin::lzma "/usr/bin/xz";

Bug#1068560: "Recommends: thin-provisioning-tools" is insufficient or unnecessary

[Vincent Lefevre]

Control: reopen -1

On 2024-04-08 09:35:35 +0200, Bastian Blank wrote:
> On Sun, Apr 07, 2024 at 11:39:12AM +0200, Vincent Lefevre wrote:
> > Due to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857142
> > lvm2 currently has "Recommends: thin-provisioning-tools".
> > But in new Debian installations, lvm2 is installed without
> > this package. If thin-provisioning-tools is really expected
> > to be installed by default, something else needs to be done.
> > Otherwise this Recommends is just unnecessary.
> 
> It is necessary to implement the cache and thin parts.

So, if it is necessary, you need to make sure that it is installed.
I repeat: thin-provisioning-tools is *not* installed by default,
contrary to lvm2. The "Recommends:" does *nothing* for core packages
like lvm2.

For instance, on a machine recently installed (which was the status
just after the installation):

disset:~> dpkg -s lvm2
Package: lvm2
Status: install ok installed
[...]

disset:~> dpkg -s thin-provisioning-tools
dpkg-query: package 'thin-provisioning-tools' is not installed and no 
information is available

-- 
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#1068560: "Recommends: thin-provisioning-tools" is insufficient or unnecessary

[Vincent Lefevre]

Package: lvm2
Version: 2.03.22-1+b1
Severity: normal

Due to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857142
lvm2 currently has "Recommends: thin-provisioning-tools".
But in new Debian installations, lvm2 is installed without
this package. If thin-provisioning-tools is really expected
to be installed by default, something else needs to be done.
Otherwise this Recommends is just unnecessary.

-- 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.6.15-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 lvm2 depends on:
ii  dmeventd  2:1.02.196-1+b1
ii  dmsetup   2:1.02.196-1+b1
ii  libaio1t640.3.113-8
ii  libblkid1 2.39.3-11
ii  libc6 2.37-15.1
ii  libdevmapper-event1.02.1  2:1.02.196-1+b1
ii  libedit2  3.1-20230828-1
ii  libselinux1   3.5-2+b1
ii  libsystemd0   255.4-1+b1
ii  libudev1  255.4-1+b1

Versions of packages lvm2 recommends:
pn  thin-provisioning-tools  

lvm2 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#1064969: aptitude: broken dependency resolution

[Vincent Lefevre]

Control: found -1 0.8.13-6
Control: retitle -1 aptitude: broken dependency resolution

Bug still present.

For instance, the following works as expected:

cventin:~> aptitude install -s grub-common libefiboot1t64 libefivar1t64
The following NEW packages will be installed:
  libefiboot1t64 libefivar1t64 
The following packages will be REMOVED:
  libefiboot1{a} libefivar1{a} 
The following packages will be upgraded:
  grub-common 
1 packages upgraded, 2 newly installed, 2 to remove and 53 not upgraded.
Need to get 2981 kB of archives. After unpacking 6144 B will be used.
The following packages have unmet dependencies:
 grub-pc-bin : Depends: grub-common (= 2.12-1) but 2.12-1.1 is to be installed
 grub2-common : Depends: grub-common (= 2.12-1) but 2.12-1.1 is to be installed
 grub-pc : Depends: grub-common (= 2.12-1) but 2.12-1.1 is to be installed
The following actions will resolve these dependencies:

 Upgrade the following packages:  
1) grub-pc [2.12-1 (now, testing) -> 2.12-1.1 (unstable)] 
2) grub-pc-bin [2.12-1 (now, testing) -> 2.12-1.1 (unstable)] 
3) grub2-common [2.12-1 (now, testing) -> 2.12-1.1 (unstable)]

But just "aptitude install -s grub-common" does not. This is
surprising because the new grub-common package depends on both
libefiboot1t64 and libefivar1t64, so that one should expect a
similar result.

"aptitude install -s grub-common" does not propose *any* acceptable
solution. The first solution is to do nothing, which is obviously
not helpful. The fifth solution is correct concerning the libraries,
but aptitude wants to remove grub-pc and grub2-common instead of
upgrading them:

 Remove the following packages:   
1) grub-pc [2.12-1 (now, testing)]
2) grub2-common [2.12-1 (now, testing)]   
3) libefiboot1 [38-3 (now, testing, unstable)]
4) libefivar1 [38-3 (now, testing, unstable)] 

 Install the following packages:  
5) libefiboot1t64 [38-3.1 (unstable)] 
6) libefivar1t64 [38-3.1 (unstable)]  

This is silly.

Going further, aptitude wants to remove more and more packages.

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

Bug#1017720: nfs-common: No such file or directory

[Vincent Lefevre]

On 2023-11-29 16:19:02 +0100, Vincent Lefevre wrote:
> I have the same kind of issue at my lab with one of my programs:
> a readdir lists the file, but then a stat sometimes gives a
> "No such file or directory" error. Some clients are more affected
> that others.

And sometimes, the "stat" succeeds as expected, but the "open" that
follows gives a "No such file or directory" error.

Also note that in my case, the file under this filename is unique:
it is created only once (never deleted then recreated).

> The clients are Debian 11.8 machines (also nfs-common 1:1.3.4-6;
> 5.10.0-26-amd64 kernel).

Still the same problem with a Debian 12.5 machine (nfs-common 1:2.6.2-4;
6.1.0-18-amd64 (6.1.76-1) kernel) on the client side.

-- 
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#1068340: ksh93u+m: "test a = a b": undetected error

[Vincent Lefevre]

Package: ksh93u+m
Version: 1.0.8-1
Severity: normal

$ test a = a b ; echo $?
0

while this should be an error.

-- 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.6.15-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 ksh93u+m depends on:
ii  libc6  2.37-15.1

ksh93u+m recommends no packages.

Versions of packages ksh93u+m suggests:
pn  binfmt-support  

-- no debconf information

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

Bug#1068338: ksh93u+m: "test ! = -o a" exits with 0 instead of 1

[Vincent Lefevre]

Package: ksh93u+m
Version: 1.0.8-1
Severity: normal

$ test ! = -o a ; echo $?
0

while I get 1 with dash 0.5.12-6, mksh 59c-35, bash 5.2.21-2,
coreutils 9.4-3.1 and zsh 5.9-6.

POSIX[*] says for 4 arguments:

  If $1 is '!', negate the three-argument test of $2, $3, and $4.

Even with ksh93:

$ test = -o a ; echo $?
0

and negated, this would be 1.

[*] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html

-- 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.6.15-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 ksh93u+m depends on:
ii  libc6  2.37-15.1

ksh93u+m recommends no packages.

Versions of packages ksh93u+m suggests:
pn  binfmt-support  

-- no debconf information

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

Bug#1041089: thin-provisioning-tools FTBFS with googletest 1.13.0

[Vincent Lefevre]

On 2024-01-13 10:23:06 +0100, Bastian Blank wrote:
> On Sat, Jan 13, 2024 at 01:03:17AM +0100, Karsten Kruse wrote:
> > Is there something else that needs to be done to get the package back into
> > testing?
> 
> Yes,
> https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/547

Any news?

Note that lvm2 recommends this package.

-- 
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]

Hi,

Some additional information about the VT100.reverseWrap xterm setting:

On 2024-03-26 23:58:47 +0100, Vincent Lefevre wrote:
> I've eventually found the cause concerning the xterm behavior:
> I had
> 
> *VT100.reverseWrap: true
> 
> for XTerm, and this, since at least April 2002.

I've actually found an old config of mine with this setting
from June 1996. So, this is really old!

> It seems to have been the default in the past (I could see in my
> mail archives that other users had it too), and I had never changed
> this part of my config since then.

Or it was the usual workaround to be able to go backward to the
previous line in cooked mode, which was used very often at that
time. This is the first issue of
  https://gitlab.gnome.org/GNOME/vte/-/issues/62
which you mentioned.

After testing, another nice thing it can do is to be able to solve
an issue with the background color when scrolling occurs. This is
a hack, but I haven't seen any serious drawback.

See

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15444#38

and the following messages.

On 2024-03-26 08:00:37 +0100, Egmont Koblinger wrote:
> Most of the terminals that behave like you wish to, i.e. print "abc",
> suffer from bug https://bugzilla.gnome.org/show_bug.cgi?id=731155, the test
> ncurses app there incorrectly prints "50" instead of the expected "50%".

FYI, I think I've never found any drawback in practice. But for zsh,
I have the default ZLE_RPROMPT_INDENT (mentioned in this bug) to
avoid the issue with reverseWrap.

-- 
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#456943: bug#15444: One character can be lost if colors are enabled

[Vincent Lefevre]

On 2024-03-26 11:47:26 -0600, Paul Eggert wrote:
> On 3/25/24 08:49, Vincent Lefevre wrote:
> > This works fine in Xterm, giving on a 80-column terminal:
> > 
> > ...
> > However, this triggers the bug in GNOME Terminal (and other
> > libvte-based terminals):
> 
> That's not good. Is there some escape sequence that will work on
> both xterm and libvte? I assume the space+backspace trick you
> suggested later assumes xterm behavior.

I've eventually found that this works in xterm only because
I have the reverseWrap option set (a setting I've had since
at least June 1996... so that I forgot about it). In the past,
I think that I set it in order to be able to go backward to
the previous line in cooked mode. But this is not the default
behavior in xterm (at least nowadays).

It could still be nice to have this trick in grep as an *option*
for GREP_COLORS (just like one already has "ne").

But perhaps the best solution would be to make terminals implement
new escape sequences to enable/disable the use of the default
background color (instead of the current background color, which
is the current behavior and the cause of this bug) for the new line
when scrolling, or something similar.

-- 
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#1067679: libvte-2.91-0: backspace character (code 8) output at the end of a line goes 2 columns backward

[Vincent Lefevre]

Hi,

On 2024-03-26 08:00:37 +0100, Egmont Koblinger wrote:
> For me, xterm behaves exactly like vte, it prints "ac".
> 
> Could you please share your xterm version, configuration, and anything
> printed to the terminal prior to this test that might be relevant?

I've eventually found the cause concerning the xterm behavior:
I had

*VT100.reverseWrap: true

for XTerm, and this, since at least April 2002. It seems to have been
the default in the past (I could see in my mail archives that other
users had it too), and I had never changed this part of my config
since then.

So I suppose that this bug can be closed.

I'll probably remove this setting if I cannot find any information
about why it was set...

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

Bug#456943: (no subject)

[Vincent Lefevre]

On 2024-03-25 15:49:52 +0100, Vincent Lefevre wrote:
> A solution for "grep" would be to add a space+backspace before the
> escape sequence.

An additional note: One of the following is needed:

* Detect the end of line (this may be tricky) and split the coloring
  into 2 parts (each one with space + backspace + escape sequence)
  at this point. If this detection is incorrect, then the background
  problem would still be visible, but with no major drawbacks.

* Split the coloring so that each matching character gets a space +
  backspace + escape sequence. I think that this is acceptable since
  this trick should be used only when the output is a tty (i.e. it
  is not redirected to a file / not piped to a pager or something
  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#456943: (no subject)

[Vincent Lefevre]

On 2016-07-14 14:22:15 -0700, Vincent Lefevre wrote:
> On 2016-07-14 09:02:48 +0200, Walter Doekes wrote:
> > Leon Meier wrote:
> > > As of today, the test case [...] still fails in (u)xterm.
> > > Any resolution in sight?
> > 
> > I tried to reproduce, and indeed, it fails on xterm (without the 'ne' grep
> > option), but not in gnome-terminal.
> > 
> > Does that mean that this is an xterm bug again and not a grep bug?
> 
> It is GNOME Terminal that is buggy, so that the grep bug is not
> visible.

A solution for "grep" would be to add a space+backspace before the
escape sequence.

Testcase:

for i in `seq 5` ; do printf "%0$(($(tput cols)+i-5))dab \bc\n" ; done | \
  GREP_COLORS="mt=41;97:ne" grep --color c

This works fine in Xterm, giving on a 80-column terminal:

abc
0abc
00abc
000abc
abc

where only the "c" has the red background.

However, this triggers the bug in GNOME Terminal (and other
libvte-based terminals):

abc
0ac 
00abc
000abc
abc

-- 
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#1067679: libvte-2.91-0: backspace character (code 8) output at the end of a line goes 2 columns backward

[Vincent Lefevre]

Package: libvte-2.91-0
Version: 0.75.92-1
Severity: normal

A backspace character (code 8) output at the end of a physical line
goes 2 columns backward.

For instance, in a 80-column libvte-based terminal (such as
GNOME Terminal or Sakura), I get

$ for i in $(seq 4 $(tput cols)) ; do printf "." ; done ; printf "ab \bc\n"
.ac

Xterm does not have such an issue:

$ for i in $(seq 4 $(tput cols)) ; do printf "." ; done ; printf "ab \bc\n"
.abc

-- 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.6.15-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 libvte-2.91-0 depends on:
ii  libatk1.0-0t64   2.51.90-4
ii  libc62.37-15.1
ii  libcairo-gobject21.18.0-1+local1
ii  libcairo21.18.0-1+local1
ii  libfribidi0  1.0.13-3+b1
ii  libgcc-s114-20240315-1
ii  libglib2.0-0t64  2.78.4-6
ii  libgnutls30t64   3.8.3-1.1+b1
ii  libgtk-3-0t643.24.41-3
ii  libicu72 72.1-4+b1
ii  liblz4-1 1.9.4-1+b2
hi  libpango-1.0-0   1.51.0+ds-4
hi  libpangocairo-1.0-0  1.51.0+ds-4
ii  libpcre2-8-0 10.42-4+b1
ii  libstdc++6   14-20240315-1
ii  libsystemd0  255.4-1+b1
ii  libvte-2.91-common   0.75.92-1

libvte-2.91-0 recommends no packages.

libvte-2.91-0 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#991520: checkrestart: "lsof: WARNING: can't stat() fuse.gvfsd-fuse file system..."

[Vincent Lefevre]

Control: found -1 0.88.1

On 2021-07-26 14:33:38 +0200, Vincent Lefevre wrote:
> When running checkrestart, I get the following warnings from lsof:
> 
> lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/118/gvfs
>   Output information may be incomplete.
> lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
>   Output information may be incomplete.
> 
> or only the second one.

This is still reproducible. Actually, now

lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
  Output information may be incomplete.
lsof: WARNING: can't stat() fuse.portal file system /run/user/1000/doc
  Output information may be incomplete.

-- 
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#758969: bash: "! true &" sets $? to 1

[Vincent Lefevre]

Hi,

On 2024-03-24 00:57:26 +0100, Gioele Barabucci wrote:
> this issue does not seem to affect version 5.0-6 and later of bash.
> 
> $ ! true &
> [1] 2264193
> [1]+  Donetrue
> $ echo $?
> 0
> 
> Please reopen this bug if you can still reproduce this issue.

I confirm that this is now correct. Moreover, in the
/usr/share/doc/bash/changelog.gz file:

  This document details the changes between this version, bash-4.4-alpha, and
  the previous version, bash-4.3-release.
  [...]
  jj. Asynchronous commands now always set $? to 0 and are not affected by
  whether or not the command's exit status is being inverted.

which corresponds to this bug (I had reported the bug upstream,
see the "Forwarded" URL, and it got fixed at that time).

So it was fixed in bash 4.4.

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

Bug#1067523: firefox: CVE-2024-29943 / CVE-2024-29944 critical bugs, fixed in FF 124.0.1

[Vincent Lefevre]

Package: firefox
Version: 124.0-1
Severity: grave
Tags: security upstream fixed-upstream
Justification: user security hole
X-Debbugs-Cc: Debian Security Team 

Firefox 124.0.1 is available upstream, which fixes 2 critical bugs:
  https://www.mozilla.org/en-US/security/advisories/mfsa2024-15/

-- Package-specific info:


-- Addons package 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.6.15-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 firefox depends on:
ii  debianutils  5.17
ii  fontconfig   2.15.0-1.1
ii  libasound2t641.2.11-1+b1
ii  libatk1.0-0t64   2.51.90-4
ii  libc62.37-15.1
ii  libcairo-gobject21.18.0-1+local1
ii  libcairo21.18.0-1+local1
ii  libdbus-1-3  1.14.10-4+b1
ii  libevent-2.1-7t642.1.12-stable-8.1+b1
ii  libffi8  3.4.6-1
ii  libfontconfig1   2.15.0-1.1
ii  libfreetype6 2.13.2+dfsg-1+b2
ii  libgcc-s114-20240315-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b2
ii  libglib2.0-0t64  2.78.4-5
ii  libgtk-3-0t643.24.41-3
ii  libnspr4 2:4.35-1.1+b1
ii  libnss3  2:3.99-1
ii  libpango-1.0-0   1.51.0+ds-4
ii  libstdc++6   14-20240315-1
ii  libvpx8  1.13.1-2
ii  libx11-6 2:1.8.7-1
ii  libx11-xcb1  2:1.8.7-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.4-1
ii  procps   2:4.0.4-4
ii  zlib1g   1:1.3.dfsg-3.1

Versions of packages firefox recommends:
ii  libavcodec60  7:6.1.1-3

Versions of packages firefox suggests:
ii  fonts-lmodern   2.005-1
ii  fonts-stix [otf-stix]   1.1.1-5
ii  libcanberra0t64 [libcanberra0]  0.30-12.2
ii  libgssapi-krb5-21.20.1-6
ii  pulseaudio  16.1+dfsg1-3+b1

-- no debconf information

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

Bug#1066828: xz-utils: worse compression ratio should be announced in NEWS.Debian

[Vincent Lefevre]

On 2024-03-14 00:35:53 +0100, Vincent Lefevre wrote:
> Since this affects what the user gets and is some kind of regression,
> this should be announced in NEWS.Debian, IMHO.

As an example of how this can affect the user, this introduced a
serious bug in pristine-tar:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063252
(what is expected here can also be expected by the end user for
his own needs...)

-- 
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#618332: rxvt-unicode: screen contents not restored when detaching a "screen" session

[Vincent Lefevre]

Control: forwarded -1 https://savannah.gnu.org/bugs/?65506

On 2024-03-22 15:59:31 +0100, Vincent Lefevre wrote:
> Actually it still occurs in rxvt-unicode 9.31-3 from Debian/unstable.
> I might have done something wrong.

and I've just reported the bug upstream (GNU Screen).

-- 
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#618332: rxvt-unicode: screen contents not restored when detaching a "screen" session

[Vincent Lefevre]

On 2024-03-22 15:09:17 +0100, Vincent Lefevre wrote:
> The bug no longer occurs in rxvt-unicode 9.31-3 from Debian/unstable,
> but it still occurs in rxvt-unicode 9.30-2 from Debian 12 (stable).

Actually it still occurs in rxvt-unicode 9.31-3 from Debian/unstable.
I might have done something wrong.

-- 
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#618332: rxvt-unicode: screen contents not restored when detaching a "screen" session

[Vincent Lefevre]

Control: found -1 4.8.0-6
Control: found -1 4.9.0-4
Control: found -1 4.9.1-1

On 2011-03-14 12:56:42 +0100, Vincent Lefevre wrote:
> The screen contents are not restored when detaching a "screen" session.
> To reproduce the problem:
> 
> 1. Run rxvt-unicode.
> 2. Run some commands, just to generate contents in the screen.
> 3. Run the "screen" utility.
> 4. Detach the "screen" session ([Cmd key] d), or simpler: terminate
>the shell (this will close the session and quit screen).
> 
> The bug: The contents one had before running "screen" are not restored.
> 
> I don't have this problem with xterm, aterm or gnome-terminal.

The bug no longer occurs in rxvt-unicode 9.31-3 from Debian/unstable,
but it still occurs in rxvt-unicode 9.30-2 from Debian 12 (stable).

-- 
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#421591: bash: test builtin (or [) does not behave correctly

[Vincent Lefevre]

On 2024-03-21 02:38:10 +0100, Gioele Barabucci wrote:
> On Mon, 11 Feb 2008 13:20:25 +0100 Vincent Lefevre 
> wrote:
> > As a summary, the following test at least does not behave correctly:
> > 
> > vlefevre@vin:~$ test \( ! -e \) ; echo $?
> > bash: test: `)' expected
> > 2
> > 
> > And I think this one is also buggy:
> > 
> > vlefevre@vin:~$ test true -a \( ! -a \) ; echo $?
> > bash: test: `)' expected
> > 2
> > 
> > FYI, the coreutils and zsh test utility both output 1 on these tests;
> > so does dash on the second one only.

dash now gives 1 on both cases, as expected. But for the second one,
zsh now gives an error and 2 like bash; I would see this as a bug,
like for bash.

Note that

  $ test \( ! -a \) ; echo $?
  1

for both bash and zsh, so "test true -a \( ! -a \)" should really
behave in the same way.

-- 
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#1065331: libhdf5-103-1t64: depends on libcurl4 instead of libcurl4t64

[Vincent Lefevre]

On 2024-03-18 20:58:02 +0100, Gilles Filippini wrote:
> Vincent Lefevre a écrit le 03/03/2024 à 01:08 :
> > Package: libhdf5-103-1t64
> > Version: 1.10.10+repack-3.1
> > Severity: serious
> > 
> > libhdf5-103-1t64 depends on libcurl4 instead of libcurl4t64.
> > This makes the upgrade of curl impossible.
> 
> How am I expected to solve this issue? As I understand it a binNMU should
> suffice. Am I right?

I think that the issue has now been fixed on the curl side:

https://salsa.debian.org/debian/curl/-/commit/40bdd3894230d325d382d59684c32d74202eee5c

-- 
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#1066861: apt-get wants to remove packages instead of upgrading

[Vincent Lefevre]

Package: apt
Version: 2.7.13+b1
Severity: important

When I type "apt-get install libreoffice" to upgrade libreoffice,
apt-get wants to remove wine32:i386, while
"apt-get install libreoffice wine32:i386" shows that the upgrade
is actually possible without removing wine32:i386.

Debug information (attached) shows that in the former case:

Broken libgav1-1:i386 Depends on libabsl20220623:i386 < 20220623.1-3 @ii pmR > 
(>= 0~20220623.0-1)
  Considering libabsl20220623:i386 0 as a solution to libgav1-1:i386 2
  Added libabsl20220623:i386 to the remove list

while it could be upgraded to libabsl20220623t64:i386 instead.

I've attached the output of the following commands:

apt-get install -s -o Debug::pkgProblemResolver=true -o 
Debug::pkgDepCache::AutoInstall=true libreoffice >& out1

apt-get install -s -o Debug::pkgProblemResolver=true -o 
Debug::pkgDepCache::AutoInstall=true libreoffice wine32:i386 >& out2

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Key "";
APT::Key::Assert-Pubkey-Algo ">=rsa2048,ed25519,ed448";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::AutoRemove "";
APT::AutoRemove::SuggestsImportant "false";
APT::Clean-Installed "false";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "test -x /usr/bin/apt-show-versions || exit 
0 ; apt-show-versions -i";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Architectures:: "i386";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::extended_states "extended_states";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache "var/cache/apt";
Dir::Cache::archives "archives/";
Dir::Cache::srcpkgcache "srcpkgcache.bin";
Dir::Cache::pkgcache "pkgcache.bin";
Dir::Etc "etc/apt";
Dir::Etc::sourcelist "sources.list";
Dir::Etc::sourceparts "sources.list.d";
Dir::Etc::main "apt.conf";
Dir::Etc::netrc "auth.conf";
Dir::Etc::netrcparts "auth.conf.d";
Dir::Etc::parts 

Bug#1066857: doc-debian: /usr/share/doc/debian/bug-reporting.txt should not be compressed

[Vincent Lefevre]

Package: doc-debian
Version: 11.3+nmu1
Severity: wishlist

The bug-reporting.txt file is rather small, thus it does not need to
be compressed. Having it compressed like currently breaks references,
such as in the apt-get(8) man page, which says

  APT bug page[1]. If you wish to report a bug in APT, please see
  /usr/share/doc/debian/bug-reporting.txt or the reportbug(1) command.

and in /usr/share/doc/debian/FAQ/support.en.html too, while only
/usr/share/doc/debian/bug-reporting.txt.gz exists.

-- 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.6.15-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

doc-debian depends on no packages.

Versions of packages doc-debian recommends:
ii  debian-faq  11.1

Versions of packages doc-debian suggests:
ii  atril [postscript-viewer]   1.26.2-1.1+b1
ii  elinks [www-browser]0.16.1.1-4.1+b2
ii  firefox [www-browser]   123.0.1-1
hi  firefox-esr [www-browser]   92.0-local
ii  ghostscript [postscript-viewer] 10.02.1~dfsg-3+b1
ii  gv [postscript-viewer]  1:3.7.4-2+local1
ii  links [www-browser] 2.29-1+b3
ii  links2 [www-browser]2.29-1+b3
ii  lynx [www-browser]  2.9.0rel.0-2+b1
ii  qpdfview-ps-plugin [postscript-viewer]  0.5.0+ds-4
ii  w3m [www-browser]   0.5.3+git20230121-2+b3
ii  zathura-ps [postscript-viewer]  0.2.7-2+b2

-- no debconf information

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

Bug#1066856: apt: please update the URLs in the man pages

[Vincent Lefevre]

Package: apt
Version: 2.7.13+b1
Severity: minor

The URLs in the man pages should be updated. For instance, concerning
the b.d.o URLs in the various man pages, "http" should be changed to
"https".

In the apt-cache(8) man page:

http://www.research.att.com/sw/tools/graphviz/ gives a "Page Not Found"
error.

http://rw4.cs.uni-sb.de/users/sander/html/gsvcg1.html should be
changed to
https://www.rw.cdl.uni-saarland.de/people/sander/private/html/gsvcg1.html


-- Package-specific info:

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


-- (/etc/apt/preferences.d/no-adobe-flash-plugin present, but not submitted) --


-- (/etc/apt/preferences.d/no-pipewire present, but not submitted) --


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


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


-- 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.6.15-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 apt depends on:
ii  adduser 3.137
ii  base-passwd 3.6.3
ii  debian-archive-keyring  2023.4
ii  gpgv2.2.40-2
ii  libapt-pkg6.0t642.7.13+b1
ii  libc6   2.37-15.1
ii  libgcc-s1   14-20240303-1
ii  libgnutls30t64  3.8.3-1.1
ii  libseccomp2 2.5.5-1
ii  libstdc++6  14-20240303-1
ii  libsystemd0 255.4-1+b1

Versions of packages apt recommends:
ii  ca-certificates  20240203

Versions of packages apt suggests:
ii  apt-doc 2.7.13
ii  aptitude0.8.13-5+b2
ii  dpkg-dev1.22.6
ii  gnupg   2.2.40-2
ii  powermgmt-base  1.37

-- no debconf information

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

Bug#1066828: xz-utils: worse compression ratio should be announced in NEWS.Debian

[Vincent Lefevre]

Package: xz-utils
Version: 5.6.0-0.2
Severity: wishlist

After upgrading xz-utils from 5.4.5-0.3 to 5.6.0-0.2, the compression
ratio with "xz -9" has decreased. For instance, on 3 files:

Old   118822308   146463040   157197172
New   121120576   148930624   161255000

It took me some time to figure out. This is the reason:

/usr/share/doc/xz-utils/NEWS.gz

5.6.0 (2024-02-24)

[...]
* xz:

- Multithreaded mode is now the default. This improves
  compression speed and creates .xz files that can be
  decompressed in multithreaded mode. The downsides are
  increased memory usage and slightly worse compression ratio.
[...]

Using -T1 restores the old behavior.

Since this affects what the user gets and is some kind of regression,
this should be announced in NEWS.Debian, IMHO.

Note also that this change might affect diffs between .xz files (e.g.
after something is appended to the uncompressed file), though I have
not checked.

-- 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.6.15-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 xz-utils depends on:
ii  libc6 2.37-15.1
ii  liblzma5  5.6.0-0.2

xz-utils recommends no packages.

xz-utils 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#1065626: libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common

[Vincent Lefevre]

And on a 3rd machine, where I used

  aptitude --log-file=/tmp/aptitude.log --log-level=info


dpkg: dependency problems prevent removal of libb2-1:amd64:
 libqt6core6t64:amd64 depends on libb2-1 (>= 0.98.1).

dpkg: error processing package libb2-1:amd64 (--purge):
 dependency problems - not removing
(Reading database ... 795189 files and directories currently installed.)
Purging configuration files for libts0:amd64 (1.22-1+b1) ...
Errors were encountered while processing:
 libb2-1:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)


In the logs, this package libb2-1 appears only twice:

2024-03-13 01:33:14 [140549832112320] aptcache.cc:2323 INFO aptitude.apt.cache 
- aptitudeDepCache::sweep(): reinstating libb2-1:amd64

2024-03-13 01:34:48 [140549832112320] aptcache.cc:2323 INFO aptitude.apt.cache 
- aptitudeDepCache::sweep(): reinstating libb2-1:amd64

I've attached the compressed log file corresponding to this upgrade.

The packages that appear as REMOVE/INSTALL/UPGRADE in /var/log/aptitude:

[REMOVE, NOT USED] libatrildocument3:amd64 1.26.2-1
[REMOVE, NOT USED] libatrilview3:amd64 1.26.2-1
[REMOVE, NOT USED] libgxps2:amd64 0.3.2-3
[INSTALL, DEPENDENCIES] libatrildocument3t64:amd64 1.26.2-1.1+b1
[INSTALL, DEPENDENCIES] libatrilview3t64:amd64 1.26.2-1.1+b1
[INSTALL, DEPENDENCIES] libgxps2t64:amd64 0.3.2-4+b1
[INSTALL, DEPENDENCIES] libpoppler-cpp0t64:amd64 22.12.0-2.2
[INSTALL, DEPENDENCIES] libpoppler-glib8t64:amd64 22.12.0-2.2
[INSTALL, DEPENDENCIES] libpoppler-qt5-1t64:amd64 22.12.0-2.2
[INSTALL, DEPENDENCIES] libpoppler-qt6-3t64:amd64 22.12.0-2.2
[INSTALL, DEPENDENCIES] libpoppler126t64:amd64 22.12.0-2.2
[INSTALL, DEPENDENCIES] libqt6core6t64:amd64 6.4.2+dfsg-21.1+b1
[INSTALL, DEPENDENCIES] libqt6dbus6t64:amd64 6.4.2+dfsg-21.1+b1
[INSTALL, DEPENDENCIES] libqt6gui6t64:amd64 6.4.2+dfsg-21.1+b1
[INSTALL, DEPENDENCIES] libts0t64:amd64 1.22-1.1
[REMOVE, DEPENDENCIES] libpoppler-cpp0v5:amd64 22.12.0-2+b1
[REMOVE, DEPENDENCIES] libpoppler-glib8:amd64 22.12.0-2+b1
[REMOVE, DEPENDENCIES] libpoppler-glib8-dbgsym:amd64 22.12.0-2+b1
[REMOVE, DEPENDENCIES] libpoppler-qt5-1:amd64 22.12.0-2+b1
[REMOVE, DEPENDENCIES] libpoppler-qt6-3:amd64 22.12.0-2+b1
[REMOVE, DEPENDENCIES] libpoppler126:amd64 22.12.0-2+b1
[REMOVE, DEPENDENCIES] libpoppler126-dbgsym:amd64 22.12.0-2+b1
[REMOVE, DEPENDENCIES] libqt6core6:amd64 6.4.2+dfsg-21
[REMOVE, DEPENDENCIES] libqt6dbus6:amd64 6.4.2+dfsg-21
[REMOVE, DEPENDENCIES] libqt6gui6:amd64 6.4.2+dfsg-21
[REMOVE, DEPENDENCIES] libts0:amd64 1.22-1+b1
[UPGRADE] atril:amd64 1.26.2-1 -> 1.26.2-1.1+b1
[UPGRADE] atril-common:amd64 1.26.2-1 -> 1.26.2-1.1
[UPGRADE] libpoppler-dev:amd64 22.12.0-2+b1 -> 22.12.0-2.2
[UPGRADE] libpoppler-private-dev:amd64 22.12.0-2+b1 -> 22.12.0-2.2
[UPGRADE] poppler-utils:amd64 22.12.0-2+b1 -> 22.12.0-2.2

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


aptitude.log.xz
Description: Binary data

Bug#1065626: libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common

[Vincent Lefevre]

The same problem occurred on another machine, with other packages:

dpkg: dependency problems prevent removal of libjte2:amd64:
 libisofs6t64:amd64 depends on libjte2.

dpkg: error processing package libjte2:amd64 (--purge):
 dependency problems - not removing
(Reading database ... 708510 files and directories currently installed.)
Purging configuration files for libts0:amd64 (1.22-1+b1) ...
dpkg: dependency problems prevent removal of libid3tag0:amd64:
 libimlib2t64:amd64 depends on libid3tag0 (>= 0.15.1b).

dpkg: error processing package libid3tag0:amd64 (--purge):
 dependency problems - not removing
Errors were encountered while processing:
 libjte2:amd64
 libid3tag0:amd64

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

Bug#1065626: libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common

[Vincent Lefevre]

On 2024-03-07 17:15:05 +, Simon McVittie wrote:
> I can confirm that version 2.24.33-4 of libgtk2.0-common, libgtk2.0-0t64
> and libgtk2.0-bin are, in fact, installable (I have them installed
> right now). I can't see any dependency relationships between them that
> look suspicious.
> 
> If dpkg is removing libgtk2.0-common, then something must surely be
> asking dpkg to remove it?

But if it were aptitude, I would assume that it would have
a REMOVE line with this package in its logs.

> I notice that you have reported at least three bugs that are "the same
> shape" with three unrelated libraries, which suggests that this might
> be more of an aptitude problem than a GTK problem.

Some aptitude developer told me that installation issues were
in general due to declarations by packages.

> Other logs, in particular /var/log/apt/term.log, might provide more
> information about what actually happened.

I've attached the corresponding part of this file.
Note that libgtk2.0-common is mentioned only at the end
(what I had already given).

> Alternatively, if there is some heuristic about "try to keep packages
> from the same source at the same version" being applied, perhaps waiting
> for libgtk2.0-common_2.24.33-4 to become available from the
> Architecture: all buildd would help?

It was already available. And I installed it just after the error.
aptitude should obviously have proposed it for upgrade. I don't
know whether this is a bug in aptitude or something wrong in the
dependencies.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Log started: 2024-03-07  16:01:43
(Reading database ...  (Reading database ... 5% (Reading database ... 10% 
(Reading database ... 15% (Reading database ... 20% (Reading database ... 25% 
(Reading database ... 30% (Reading database ... 35% (Reading database ... 40% 
(Reading database ... 45% (Reading database ... 50% (Reading database ... 55% 
(Reading database ... 60% (Reading database ... 65% (Reading database ... 70% 
(Reading database ... 75% (Reading database ... 80% (Reading database ... 85% 
(Reading database ... 90% (Reading database ... 95% (Reading database ... 100% 
(Reading database ... 655929 files and directories currently installed.)
Preparing to unpack .../libgtk2.0-bin_2.24.33-4_amd64.deb ...
Unpacking libgtk2.0-bin (2.24.33-4) over (2.24.33-3) ...
Preparing to unpack .../libgail-common_2.24.33-4_amd64.deb ...
Unpacking libgail-common:amd64 (2.24.33-4) over (2.24.33-3) ...
dpkg: libgail18:amd64: dependency problems, but removing anyway as you 
requested:
 libgnomecanvas2-0:amd64 depends on libgail18 (>= 1.18.0).

(Reading database ...  (Reading database ... 5% (Reading database ... 10% 
(Reading database ... 15% (Reading database ... 20% (Reading database ... 25% 
(Reading database ... 30% (Reading database ... 35% (Reading database ... 40% 
(Reading database ... 45% (Reading database ... 50% (Reading database ... 55% 
(Reading database ... 60% (Reading database ... 65% (Reading database ... 70% 
(Reading database ... 75% (Reading database ... 80% (Reading database ... 85% 
(Reading database ... 90% (Reading database ... 95% (Reading database ... 100% 
(Reading database ... 655928 files and directories currently installed.)
Removing libgail18:amd64 (2.24.33-3) ...
Selecting previously unselected package libgail18t64:amd64.
(Reading database ...  (Reading database ... 5% (Reading database ... 10% 
(Reading database ... 15% (Reading database ... 20% (Reading database ... 25% 
(Reading database ... 30% (Reading database ... 35% (Reading database ... 40% 
(Reading database ... 45% (Reading database ... 50% (Reading database ... 55% 
(Reading database ... 60% (Reading database ... 65% (Reading database ... 70% 
(Reading database ... 75% (Reading database ... 80% (Reading database ... 85% 
(Reading database ... 90% (Reading database ... 95% (Reading database ... 100% 
(Reading database ... 655923 files and directories currently installed.)
Preparing to unpack .../libgail18t64_2.24.33-4_amd64.deb ...
Unpacking libgail18t64:amd64 (2.24.33-4) ...
dpkg: libgtk2.0-0:amd64: dependency problems, but removing anyway as you 
requested:
 xournal depends on libgtk2.0-0 (>= 2.14.0).
 pinentry-gtk2 depends on libgtk2.0-0 (>= 2.18.0).
 pavumeter depends on libgtk2.0-0 (>= 2.8.0).
 libgtkmm-2.4-1v5:amd64 depends on libgtk2.0-0 (>= 2.24.0).
 libgnomecanvas2-0:amd64 depends on libgtk2.0-0 (>= 2.8.17).
 libgimp2.0:amd64 depends on libgtk2.0-0 (>= 2.24.10).
 ibus-gtk:amd64 depends on libgtk2.0-0 (>= 2.24.0).
 gromit depends on libgtk2.0-0 (>= 2.24.0).
 gkrellweather depends on libgtk2.0-0 (>= 2.8.0).
 gkrellm-volume depends on libgtk2.0-0 (>= 2.8.0).
 gkrellm depends on libgtk2.0-0 (>= 2.24.0).
 gimp depends on libgtk2.0-0 (>= 2.24.10).

(Reading database ...  (Reading database ... 5% (Reading database ... 10% 
(Reading database ... 15% 

Bug#1065625: libmtp9t64 / libmtp-runtime dependency problem makes dpkg fail with attempt of removal of libmtp-common

[Vincent Lefevre]

On 2024-03-07 16:00:35 +0100, Vincent Lefevre wrote:
> Will install 11 packages, and remove 3 packages.
> 8192 B of disk space will be used
> 
> [...]
> [HOLD, DEPENDENCIES] libmtp-common:amd64 1.1.21-3
> [...]
> [INSTALL, DEPENDENCIES] libgphoto2-6t64:amd64 2.5.31-2.1
> [INSTALL, DEPENDENCIES] libgphoto2-port12t64:amd64 2.5.31-2.1
> [INSTALL, DEPENDENCIES] libmtp9t64:amd64 1.1.21-3.1
> [REMOVE, DEPENDENCIES] libgphoto2-6:amd64 2.5.31-2
> [REMOVE, DEPENDENCIES] libgphoto2-port12:amd64 2.5.31-2
> [REMOVE, DEPENDENCIES] libmtp9:amd64 1.1.21-3
> [...]
> [UPGRADE] gvfs:amd64 1.53.90-2 -> 1.53.90-3
> [UPGRADE] gvfs-backends:amd64 1.53.90-2 -> 1.53.90-3
> [UPGRADE] gvfs-common:amd64 1.53.90-2 -> 1.53.90-3
> [UPGRADE] gvfs-daemons:amd64 1.53.90-2 -> 1.53.90-3
> [UPGRADE] gvfs-fuse:amd64 1.53.90-2 -> 1.53.90-3
> [UPGRADE] gvfs-libs:amd64 1.53.90-2 -> 1.53.90-3
> [UPGRADE] libgphoto2-l10n:amd64 2.5.31-2 -> 2.5.31-2.1
> [UPGRADE] libmtp-runtime:amd64 1.1.21-3 -> 1.1.21-3.1
> 

Note that libmtp-common:amd64 1.1.21-3.1 was available, but for
some unknown reason, aptitude did not propose its upgrade.

-- 
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#1065626: libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common

[Vincent Lefevre]

Package: libgtk2.0-0t64
Version: 2.24.33-4
Severity: serious

During an upgrade with aptitude:

dpkg: dependency problems prevent removal of libgtk2.0-common:
 libgtk2.0-bin depends on libgtk2.0-common.
 libgtk2.0-0t64:amd64 depends on libgtk2.0-common.

dpkg: error processing package libgtk2.0-common (--purge):
 dependency problems - not removing
Errors were encountered while processing:
 libgtk2.0-common

Note that "apt install -f" has nothing to fix; this upgrade just
triggered a dpkg error (similar to bugs 1065603 and 1065625).

Moreover, like in these bugs, aptitude did not propose the removal
of libgtk2.0-common:

Aptitude 0.8.13: log report
Thu, Mar  7 2024 16:01:36 +0100

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 5 packages, and remove 2 packages.
2048 B of disk space will be used

[...]
[HOLD, DEPENDENCIES] libgtk2.0-common:amd64 2.24.33-3
[...]
[INSTALL, DEPENDENCIES] libgail18t64:amd64 2.24.33-4
[INSTALL, DEPENDENCIES] libgtk2.0-0t64:amd64 2.24.33-4
[REMOVE, DEPENDENCIES] libgail18:amd64 2.24.33-3
[REMOVE, DEPENDENCIES] libgtk2.0-0:amd64 2.24.33-3
[...]
[UPGRADE] gtk2-engines-pixbuf:amd64 2.24.33-3 -> 2.24.33-4
[UPGRADE] libgail-common:amd64 2.24.33-3 -> 2.24.33-4
[UPGRADE] libgtk2.0-bin:amd64 2.24.33-3 -> 2.24.33-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)

Kernel: Linux 6.6.15-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 libgtk2.0-0t64 depends on:
ii  adwaita-icon-theme   46~rc-1
ii  gnome-icon-theme 3.12.0-5
ii  hicolor-icon-theme   0.17-2
ii  libatk1.0-0t64   2.51.90-2
ii  libc62.37-15.1
ii  libcairo21.18.0-1+b1
ii  libcups2t64  2.4.7-1.2+b1
ii  libfontconfig1   2.15.0-1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b1
ii  libglib2.0-0t64  2.78.4-3
pn  libgtk2.0-common 
ii  libpango-1.0-0   1.51.0+ds-4
ii  libpangocairo-1.0-0  1.51.0+ds-4
ii  libpangoft2-1.0-01.51.0+ds-4
ii  libx11-6 2:1.8.7-1
ii  libxcomposite1   1:0.4.5-1
ii  libxcursor1  1:1.2.1-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxi6   2:1.8.1-1
ii  libxinerama1 2:1.1.4-3
ii  libxrandr2   2:1.5.2-2+b1
ii  libxrender1  1:0.9.10-1.1
ii  shared-mime-info 2.4-1

Versions of packages libgtk2.0-0t64 recommends:
ii  libgail-common   2.24.33-4
ii  libgtk2.0-bin2.24.33-4
ii  librsvg2-common  2.54.7+dfsg-2

Versions of packages libgtk2.0-0t64 suggests:
ii  gvfs  1.53.90-3

-- no debconf information

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

Bug#1065625: libmtp9t64 / libmtp-runtime dependency problem makes dpkg fail with attempt of removal of libmtp-common

[Vincent Lefevre]

Package: libmtp9t64
Version: 1.1.21-3.1
Severity: serious

During an upgrade with aptitude:

dpkg: dependency problems prevent removal of libmtp-common:
 libmtp9t64:amd64 depends on libmtp-common.
 libmtp-runtime depends on libmtp-common.

dpkg: error processing package libmtp-common (--purge):
 dependency problems - not removing
Errors were encountered while processing:
 libmtp-common

Note that "apt install -f" has nothing to fix; this upgrade just
triggered a dpkg error (similar to bug 1065603).

Moreover, like in bug 1065603, aptitude did not propose the removal
of libmtp-common:

Aptitude 0.8.13: log report
Thu, Mar  7 2024 15:49:03 +0100

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 11 packages, and remove 3 packages.
8192 B of disk space will be used

[...]
[HOLD, DEPENDENCIES] libmtp-common:amd64 1.1.21-3
[...]
[INSTALL, DEPENDENCIES] libgphoto2-6t64:amd64 2.5.31-2.1
[INSTALL, DEPENDENCIES] libgphoto2-port12t64:amd64 2.5.31-2.1
[INSTALL, DEPENDENCIES] libmtp9t64:amd64 1.1.21-3.1
[REMOVE, DEPENDENCIES] libgphoto2-6:amd64 2.5.31-2
[REMOVE, DEPENDENCIES] libgphoto2-port12:amd64 2.5.31-2
[REMOVE, DEPENDENCIES] libmtp9:amd64 1.1.21-3
[...]
[UPGRADE] gvfs:amd64 1.53.90-2 -> 1.53.90-3
[UPGRADE] gvfs-backends:amd64 1.53.90-2 -> 1.53.90-3
[UPGRADE] gvfs-common:amd64 1.53.90-2 -> 1.53.90-3
[UPGRADE] gvfs-daemons:amd64 1.53.90-2 -> 1.53.90-3
[UPGRADE] gvfs-fuse:amd64 1.53.90-2 -> 1.53.90-3
[UPGRADE] gvfs-libs:amd64 1.53.90-2 -> 1.53.90-3
[UPGRADE] libgphoto2-l10n:amd64 2.5.31-2 -> 2.5.31-2.1
[UPGRADE] libmtp-runtime:amd64 1.1.21-3 -> 1.1.21-3.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.6.15-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 libmtp9t64 depends on:
ii  libc6  2.37-15.1
ii  libgcrypt201.10.3-2
pn  libmtp-common  
ii  libusb-1.0-0   2:1.0.27-1

Versions of packages libmtp9t64 recommends:
ii  libmtp-runtime  1.1.21-3.1
ii  udev255.3-2

libmtp9t64 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#731140: ghostscript: on PDF files with embedded fonts, ps2pdf changes the way fonts are rendered

[Vincent Lefevre]

On 2024-02-28 23:04:41 -0600, Steven Robbins wrote:
> On Mon, 2 Dec 2013 13:54:19 +0100 Vincent Lefevre  wrote:
> > font1.pdf is the original file (generated by pdflatex).
> > font2.pdf is the file obtained with "ps2pdf font1.pdf font2.pdf".
> > font.png shows the text of font1.pdf (left) and font2.pdf (right),
> > as obtained with xpdf.
> 
> I have repeated the test with ghostscript 10.02.1 and I cannot see any 
> difference (using xpdf, or using evince) between font1 and the output of 
> ps2pdf.

Well, with the font*.pdf files I had attached in my bug report, I can
no longer see any difference between font1.pdf and font2.pdf with xpdf
(or zathura). So I assume that this was actually a bug in xpdf (or
poppler), which did something wrong concerning font2.pdf.

I've also compared the rendering of these attached files on a Debian 11
machine with xpdf, and I cannot see any difference either.

So I suppose that this bug can be closed.

Regards,

-- 
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#1065605: aptitude: useless backup of pkgstates

[Vincent Lefevre]

Package: aptitude
Version: 0.8.13-5+b2
Severity: minor

I ran aptitude to do an upgrade from the TUI (dpkg failed), then
quit just after it. This was before 11:28, since I reported this
failure at this time.

But /var/lib/aptitude contains

-rw-r--r-- 1 root root 10438852 2024-03-07 11:29:40 pkgstates
-rw-r--r-- 1 root root 10438852 2024-03-07 11:29:39 pkgstates.old

and these files have the same contents, which is useless.

I don't see what could have modified pkgstates... or perhaps from
the journalctl output:

Mar 07 11:22:25 qaa systemd[1]: Started packagekit.service - PackageKit Daemon.
[...]
Mar 07 11:30:11 qaa systemd[1]: packagekit.service: Deactivated successfully.

I could see nothing else.

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

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

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

aptitude linkage:
linux-vdso.so.1 (0x7fff813f9000)
libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 
(0x7f8fcf2bd000)
libapt-pkg.so.6.0 => /lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7f8fcea0)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7f8fcf283000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7f8fcf24e000)
libsigc-2.0.so.0 => /lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f8fcf245000)
libcwidget.so.4 => /lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7f8fcecfc000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f8fce88a000)
libboost_iostreams.so.1.83.0 => 
/lib/x86_64-linux-gnu/libboost_iostreams.so.1.83.0 (0x7f8fcece2000)
libxapian.so.30 => /lib/x86_64-linux-gnu/libxapian.so.30 
(0x7f8fce60)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f8fce20)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f8fce521000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f8fcecb3000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8fce01e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f8fcecae000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f8fceca9000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f8fcec8a000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f8fcec77000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f8fce4e4000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x7f8fcec4f000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7f8fcdf5d000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f8fce857000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7f8fcde7b000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7f8fcdd33000)
libxxhash.so.0 => /lib/x86_64-linux-gnu/libxxhash.so.0 
(0x7f8fcec3a000)
/lib64/ld-linux-x86-64.so.2 (0x7f8fcf2e5000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f8fce4da000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x7f8fce4ce000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7f8fce4a5000)

-- 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.6.15-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 aptitude depends on:
ii  aptitude-common   0.8.13-5
ii  libapt-pkg6.0t64  2.7.13+b1
ii  libboost-iostreams1.83.0  1.83.0-2.1
ii  libc6 2.37-15.1
ii  libcwidget4   0.5.18-6+b1
ii  libgcc-s1 14-20240303-1
ii  libncursesw6  6.4+20240113-1
ii  libsigc++-2.0-0v5 2.12.1-1
ii  libsqlite3-0  3.45.1-1
ii  libstdc++614-20240303-1
ii  libtinfo6 6.4+20240113-1
ii  libxapian30   1.4.22-1+b1

Versions of packages aptitude recommends:
ii  libdpkg-perl1.22.5
ii  sensible-utils  0.0.22

Versions of packages aptitude suggests:
ii  apt-xapian-index0.55
ii  aptitude-doc-en [aptitude-doc]  0.8.13-5
pn  debtags 
ii  tasksel 3.75

-- no debconf information

-- 
Vincent Lefèvre  - Web: 

Bug#1065603: libdebuginfod1t64 dependency problem breaks the upgrade

[Vincent Lefevre]

Control: retitle -1 libdebuginfod1t64 dependency problem makes dpkg fail with 
attempt of removal of libdebuginfod-common

On 2024-03-07 11:28:21 +0100, Vincent Lefevre wrote:
> When I wanted to upgrade, this ended up with
> 
> dpkg: dependency problems prevent removal of libdebuginfod-common:
>  libdebuginfod1t64:amd64 depends on libdebuginfod-common (>= 0.190-1.1).
> 
> dpkg: error processing package libdebuginfod-common (--purge):
>  dependency problems - not removing
> (Reading database ... 655945 files and directories currently installed.)
> Errors were encountered while processing:
>  libdebuginfod-common

Well, the issue just seems to be a dpkg failure. "apt install -f"
shows nothing to fix.

So I'm wondering why dpkg wanted to remove libdebuginfod-common.

FYI, I did the upgrade via aptitude, and this package wasn't proposed
for removal. In /var/log/aptitude, after discarding the HOLD lines
(which correspond to no changes for these packages):

Aptitude 0.8.13: log report
Thu, Mar  7 2024 11:24:24 +0100

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 15 packages, and remove 6 packages.
5096 kB of disk space will be freed

[...]
[INSTALL, DEPENDENCIES] libasm1t64:amd64 0.190-1.1
[INSTALL, DEPENDENCIES] libdebuginfod1t64:amd64 0.190-1.1
[INSTALL, DEPENDENCIES] libdw1t64:amd64 0.190-1.1
[INSTALL, DEPENDENCIES] libelf1t64:amd64 0.190-1.1
[INSTALL, DEPENDENCIES] libglib2.0-0t64:amd64 2.78.4-3
[REMOVE, DEPENDENCIES] libasm1:amd64 0.190-1+b1
[REMOVE, DEPENDENCIES] libdebuginfod1:amd64 0.190-1+b1
[REMOVE, DEPENDENCIES] libdw1:amd64 0.190-1+b1
[REMOVE, DEPENDENCIES] libelf1:amd64 0.190-1+b1
[REMOVE, DEPENDENCIES] libglib2.0-0:amd64 2.78.4-1
[REMOVE, DEPENDENCIES] libglib2.0-0-dbgsym:amd64 2.78.4-1
[...]
[UPGRADE] elfutils:amd64 0.190-1+b1 -> 0.190-1.1
[UPGRADE] gir1.2-freedesktop:amd64 1.78.1-15 -> 1.78.1-16
[UPGRADE] gir1.2-freedesktop-dev:amd64 1.78.1-15 -> 1.78.1-16
[UPGRADE] gir1.2-girepository-2.0:amd64 1.78.1-15 -> 1.78.1-16
[UPGRADE] gir1.2-glib-2.0:amd64 1.78.1-15 -> 1.78.1-16
[UPGRADE] gir1.2-glib-2.0-dev:amd64 1.78.1-15 -> 1.78.1-16
[UPGRADE] libelf-dev:amd64 0.190-1+b1 -> 0.190-1.1
[UPGRADE] libglib2.0-bin:amd64 2.78.4-1 -> 2.78.4-3
[UPGRADE] libglib2.0-dev:amd64 2.78.4-1 -> 2.78.4-3
[UPGRADE] libglib2.0-dev-bin:amd64 2.78.4-1 -> 2.78.4-3


-- 
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#1065603: libdebuginfod1t64 dependency problem breaks the upgrade

[Vincent Lefevre]

Package: libdebuginfod1t64
Version: 0.190-1.1
Severity: serious

When I wanted to upgrade, this ended up with

dpkg: dependency problems prevent removal of libdebuginfod-common:
 libdebuginfod1t64:amd64 depends on libdebuginfod-common (>= 0.190-1.1).

dpkg: error processing package libdebuginfod-common (--purge):
 dependency problems - not removing
(Reading database ... 655945 files and directories currently installed.)
Errors were encountered while processing:
 libdebuginfod-common

-- 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.6.15-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 libdebuginfod1t64 depends on:
ii  libc6 2.37-15.1
ii  libcurl3t64-gnutls [libcurl3-gnutls]  8.6.0-3.2
pn  libdebuginfod-common  
ii  libdw1t64 0.190-1.1
ii  libelf1t640.190-1.1

libdebuginfod1t64 recommends no packages.

libdebuginfod1t64 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)