Re: systemd may silently break your system!

2024-08-03 Thread Vincent Lefevre
On 2024-08-01 23:17:42 -0400, Jeffrey Walton wrote:
> The reference also says:
> 
> Only pure stable release with security updates provides the best
> stability.

But stable does not mean bugless. Unfortunately stable sometimes
has major bugs, and the only thing to do is to wait for the next
stable release (except when one is the admin, in which case, one
can patch the software and recompile).

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



Re: nvidia vs nouveau driver and initrd.* size

2024-08-03 Thread Vincent Lefevre
On 2024-08-02 14:55:31 +0200, Franco Martelli wrote:
> Sorry but have you read that bug report (#1076561)? Some users has posted
> solutions to make smaller the initrd file:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076561#10
> and
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076561#48

Increasing the compression by using lzma with compression level 9
improves the situation (I'm wondering why this isn't the default,
given the fact that many users do not have a large /boot partition)
with no visible drawback. Compression is slower, but this is not
something one does often. However, the initrd.* file is still
significantly larger (by 20 MB) than previously.

And according to the documentation, the difference between
MODULES=most (default) and MODULES=dep concerns the filesystem
and harddrive drivers, while I was concerned by the drivers for
the Nvidia cards.

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



Re: nvidia vs nouveau driver and initrd.* size

2024-08-03 Thread Vincent Lefevre
On 2024-08-01 12:12:31 -0700, Van Snyder wrote:
> On Thu, 2024-08-01 at 15:26 +0200, Vincent Lefevre wrote:
> > Should I switch to the proprietary nvidia driver on these machines?
> 
> Without NVidia's graphics accelerator, using software rendering with
> nouveau is painfully slow. Sometimes even the mouse cursor is frozen.

Well, with an old machine (~ 10 years old), nouveau was indeed
painfully slow (e.g. when moving a window or when scrolling),
but only with multiple screens. I did not have any issue with
a single screen. And my new machines are OK with nouveau.

> This is especially the case if you're looking at a web page that has an
> annoying video ad playing in a sidebar.
> 
> The NVidia 390 driver is not available for Debian 12 (and it might not
> have been available for Debian 11). I wasted a lot of my time, and a
> lot of bandwidth in this discussion list, trying to install it. On my
> desktop, I installed a Quadro K2200 card to replace by GeForce card --
> so now a computer that I use less frequently is stuck with nouveau. On
> a laptop, I'm stuck with nouveau or returning to Debian 10.

The NVidia 390 driver is still available in unstable:

zira:~> apt-show-versions -a nvidia-legacy-390xx-driver
nvidia-legacy-390xx-driver:amd64 390.157-6 install ok installed
No stable version
No stable-updates version
No testing version
nvidia-legacy-390xx-driver:amd64 390.157-8 unstable ftp.debian.org
No experimental version
nvidia-legacy-390xx-driver:amd64/unstable 390.157-6 upgradeable to 390.157-8

I suppose that you can use it even with Debian 12 (I haven't checked
the dependencies, though), but you need to request the unstable
packages in your sources.list 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)



Re: nvidia vs nouveau driver and initrd.* size

2024-08-01 Thread Vincent Lefevre
On 2024-08-01 11:32:10 -0400, Felix Miata wrote:
> Vincent Lefevre composed on 2024-08-01 17:18 (UTC+0200):
> 
> > On 2024-08-01 10:23:53 -0400, Felix Miata wrote:
> 
> >> the bug fix should trim initrd size considerably before
> >> too long.
> 
> > What do you mean?
> 
> After package containing bug fix is installed, newly generated
> initrds will be considerably smaller that they were or would have
> been before the fix arrived.

There are no fixes for the current increase. I think that you got
confused with another bug. Let me explain.

On 2024-08-01 10:23:53 -0400, Felix Miata wrote:
> Vincent Lefevre composed on 2024-08-01 15:26 (UTC+0200):
> > -rw-r--r-- 1 root root  69879473 2024-07-19 02:11:58 initrd.img-6.7.12-amd64
> > -rw-r--r-- 1 root root 112644015 2024-08-01 13:01:40 initrd.img-6.9.12-amd64
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076561

No, bug 1076561 is fixed. FYI, without this fix, the initrd file was
so big that the kernel package could not even be installed on this
machine. Now, I can install it, but the initrd file is nevertheless
much bigger.

If I understand correctly, firmware-nonfree got new drivers
for many Nvidia cards, hence the big increase; that's why
firmware-misc-nonfree was split:

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

But this is not helpful for users of Nvidia cards, despite the fact
is that in practice, one just needs a small part of these drivers.

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



Re: nvidia vs nouveau driver and initrd.* size

2024-08-01 Thread Vincent Lefevre
On 2024-08-01 10:23:53 -0400, Felix Miata wrote:
> Vincent Lefevre composed on 2024-08-01 15:26 (UTC+0200):
> 
> > I have several Debian/unstable machines, all with a Nvidia card.
> 
> > On one of them, due to a bug in nouveau in the past, I use the
> > proprietary nvidia driver: libnvidia-legacy-390xx-* packages.
> > And the initrd size is reasonable:
> 
> > -rw-r--r-- 1 root root 66937544 2024-07-30 11:27:32 initrd.img-6.9.12-amd64
> 
> > Note that on this machine, firmware-nvidia-graphics is not installed.
> > According to its description, this package is apparently for the
> > nouveau driver:
> 
> > Package: firmware-nvidia-graphics
> > [...]
> > Source: firmware-nonfree
> > Version: 20240709-1
> > Suggests: initramfs-tools
> > Conflicts: firmware-misc-nonfree (<< 20230625-3~)
> > Description: Binary firmware for Nvidia GPU chips
> >  This package contains the binary firmware for Nvidia graphics chips using
> >  the nouveau driver.
> > 
> > On other machines, I use the nouveau driver, but
> > firmware-nvidia-graphics now makes the initrd.* file much larger.
> > See the increase:
> 
> > -rw-r--r-- 1 root root  69879473 2024-07-19 02:11:58 initrd.img-6.7.12-amd64
> > -rw-r--r-- 1 root root 112644015 2024-08-01 13:01:40 initrd.img-6.9.12-amd64
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076561
> 
> > which may be a problem with the small /boot partition (500 MB).
> > This is currently OK, but if I want to have 3 or 4 kernels (e.g.
> > due to future bugs), this might not be possible.
> 
> > Should I switch to the proprietary nvidia driver on these machines?

> AIUI, those old enough to use 390 drivers won't likely have support
> much longer, if even supported now,

The machines for which I currently use nouveau are new.
So, if I switch to the proprietary nvidia driver, this will
be the latest version, not the 390 drivers.

> while the bug fix should trim initrd size considerably before
> too long.

What do you mean?

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



Re: systemd may silently break your system!

2024-08-01 Thread Vincent Lefevre
On 2024-08-01 09:37:54 -0400, Greg Wooledge wrote:
> On Thu, Aug 01, 2024 at 14:47:16 +0200, Vincent Lefevre wrote:
> > No, even for unstable, maintainers should ensure that packages are
> > upgraded in the right order.
> 
> Once again, here is my understanding of the current situation:
> 
>  1) A new procps package was uploaded, which no longer has /etc/sysctl.conf.
> 
>  2) A new systemd package was uploaded, which removes the now-dangling
> /etc/sysctl.d/99-whatever symlink.
> 
>  3) It was discovered that the new procps package fails to remove the
> existing /etc/sysctl.conf file when upgrading.  This was filed as
> a bug, and will be fixed at some point.

NO!!! This is (3) before (2).

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076352
"procps: leftover conffiles" on 14 July.

systemd (256.4-1) unstable; urgency=medium
[...]
  * Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships
/etc/sysctl.conf (Closes: #1076190)
[...]
on 24 July, i.e. 10 days later!

BTW, in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076190
"Upgraded systems will continue to have an obsolete conffile named
/etc/sysctl.conf"

so the silent breakage was known and done on purpose.

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



nvidia vs nouveau driver and initrd.* size

2024-08-01 Thread Vincent Lefevre
I have several Debian/unstable machines, all with a Nvidia card.

On one of them, due to a bug in nouveau in the past, I use the
proprietary nvidia driver: libnvidia-legacy-390xx-* packages.
And the initrd size is reasonable:

-rw-r--r-- 1 root root 66937544 2024-07-30 11:27:32 initrd.img-6.9.12-amd64

Note that on this machine, firmware-nvidia-graphics is not installed.
According to its description, this package is apparently for the
nouveau driver:

Package: firmware-nvidia-graphics
[...]
Source: firmware-nonfree
Version: 20240709-1
Suggests: initramfs-tools
Conflicts: firmware-misc-nonfree (<< 20230625-3~)
Description: Binary firmware for Nvidia GPU chips
 This package contains the binary firmware for Nvidia graphics chips using
 the nouveau driver.

On other machines, I use the nouveau driver, but
firmware-nvidia-graphics now makes the initrd.* file much larger.
See the increase:

-rw-r--r-- 1 root root  69879473 2024-07-19 02:11:58 initrd.img-6.7.12-amd64
-rw-r--r-- 1 root root 112644015 2024-08-01 13:01:40 initrd.img-6.9.12-amd64

which may be a problem with the small /boot partition (500 MB).
This is currently OK, but if I want to have 3 or 4 kernels (e.g.
due to future bugs), this might not be possible.

Should I switch to the proprietary nvidia driver on these machines?

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



Re: systemd may silently break your system!

2024-08-01 Thread Vincent Lefevre
On 2024-07-29 23:36:02 -0500, David Wright wrote:
> On Mon 29 Jul 2024 at 11:24:25 (+0200), Vincent Lefevre wrote:
> > On 2024-07-28 22:26:10 -0500, David Wright wrote:
> > > On Sun 28 Jul 2024 at 16:43:01 (+0200), Vincent Lefevre wrote:
> > > > On 2024-07-28 00:07:56 -0500, David Wright wrote:
> > > > > It looks accidental to me that systemd did that tidying up before
> > > > > procps had attempted to remove the file that it (procps) owned.
> > > > 
> > > > No, the breakage was done on purpose: my bug report specifically
> > > > about this breakage by systemd was closed in a rather abrupt way:
> > > > 
> > > >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077184
> > > 
> > > I only wrote that the /order/ was accidental:
> > 
> > If this were accidental, the bug should have been left open.
> 
> I agree with the syslogd maintainer: if you want to use what you had
> in /etc/sysctl.conf, place it in one or more of the appropriate
> directories, like /etc/sysctl.d/. Closing that bug seems fine.

But this means that by upgrading systemd, the user will suddenly
be affected by the /etc/sysctl.conf issue, without any warning
from apt-listbugs (note that systemd does not have a Breaks on
the buggy procps). This is not satisfactory.

> I think the bug is in procps, and I see that your bug is open:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077187

This one is for the documentation only. The bug about the conffile
left behind is

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

> That's a risk of running unstable: package upgrades might occur in the
> wrong order, and one needs to report bugs like #1076352.

No, even for unstable, maintainers should ensure that packages are
upgraded in the right order.

> > > > No, this is not sufficient. During an upgrade, a package is allowed
> > > > to do a merge of the new defaults (this occurs quite frequently).
> > > 
> > > That doesn't square with Policy, and this typical dialogue that
> > > we've all seen:
> > > 
> > >   Configuration file `foo'
> > >==> Modified (by you or by a script) since installation.
> > >==> Package distributor has shipped an updated version.
> > >  What would you like to do about it ?  Your options are:
> > >   Y or I  : install the package maintainer's version
> > >   N or O  : keep your currently-installed version
> > > D : show the differences between the versions
> > > Z : start a shell to examine the situation
> > >The default action is to keep your current version.
> > >   *** foo (Y/I/N/O/D/Z) [default=N] ? 
> > > 
> > > Might your merges apply to configuration files rather than conffiles?
> > 
> > There are several ways to update the configuration in an upgrade.
> > Not every package uses this method.
> 
> This is the only way for conffiles that have been modified.

So, the issue is probably for configuration files that are not
conffiles.

There's also the issue with configuration by symbolic links.
How do you tell the system that in future upgrades, you want
to keep some symbolic link (e.g. /etc/sysctl.d/99-sysctl.conf
before upgrading systemd[*])?

[*] Either in unstable, or for the future upgrade from bookworm
to trixie.

[...]
> (Unless by apparent you mean "I didn't see the bug coming."
> Well, no, that's what bugs do, pop up without notice.)

Wrong. apt-listbugs will list major bugs already reported...
but not this one!!!

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



Re: info is not dead

2024-07-30 Thread Vincent Lefevre
On 2024-07-28 22:49:43 -0500, David Wright wrote:
> On Sun 28 Jul 2024 at 16:23:48 (+0200), Vincent Lefevre wrote:
> > On 2024-07-28 00:08:51 -0500, David Wright wrote:
> > > On Sun 28 Jul 2024 at 02:06:38 (+0200), Vincent Lefevre wrote:
> > > > But for searching, how can one get the previous match with pinfo?
> > > > (info has { and } to navigate through the matches, Lynx has n and N,
> > > > but what about pinfo?)
> > > 
> > > I think you define KEY_SEARCH_AGAIN_1 to whichever keystroke you want.
> > > (AIUI it has no default already defined in /etc/.pinforc)
> > 
> > KEY_SEARCH_AGAIN_1 gives the *next* match, not the previous one.
> 
> Sorry, yes, I think it helps to be able to subconciously count (but
> avoid being afflicted by OCD), and press Home and n-1 SearchAgains.
> (Even more tedious than searching backwards and forwards in xpdf,
> where you have to toggle a button.)
> 
> Wishlist bug?

There's one upstream: https://github.com/baszoetekouw/pinfo/issues/22
(but no activity in the repository for the last 3 years).

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



Re: systemd may silently break your system!

2024-07-29 Thread Vincent Lefevre
On 2024-07-28 22:26:10 -0500, David Wright wrote:
> On Sun 28 Jul 2024 at 16:43:01 (+0200), Vincent Lefevre wrote:
> > On 2024-07-28 00:07:56 -0500, David Wright wrote:
> > > It looks accidental to me that systemd did that tidying up before
> > > procps had attempted to remove the file that it (procps) owned.
> > 
> > No, the breakage was done on purpose: my bug report specifically
> > about this breakage by systemd was closed in a rather abrupt way:
> > 
> >   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077184
> 
> I only wrote that the /order/ was accidental:

If this were accidental, the bug should have been left open.

> upgrading systemd before
> procps had removed its conffile. When the latter happens, you should
> get asked about that conffile, and if not, then that's surely a bug
> in procps, not systemd: procps owned the file, so procps disowned it.
> 
> In fact, here's procps disowning /etc/sysctl.conf:
> 
>   procps (2:4.0.4-5) unstable; urgency=medium
> 
> * Add Recommends: linux-sysctl-defaults Closes: #1074156
> * Remove /etc/sysctl.conf as using /etc/sysctl.d/*.conf is better
> 
> (the top of /usr/share/doc/procps/changelog.Debian.gz 4.0.4-5)

It was clear in my bug report that this applies only to new
installations.


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

I suspect that the cause is

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

which is wrong!

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

with procps 2:4.0.4-5.

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


> > > > > > > As it turns out, it's a combination of the two packages.  In 
> > > > > > > bookworm,
> > > > > > > /etc/sysctl.conf is a Conffile of the procps package, and
> > > > > > > /etc/sysctl.d/99-sysctl.conf is a regular file (non-Conffile) of
> > > > > > > the systemd package.
> > > 
> > > That symlink was suggested as legacy support for reading the conf file
> > > over a decade ago. Bullseye's   man 8 sysctl   indicates it still reads
> > > /etc/sysctl.conf with its --system option, but bookworm lacks that
> trixie
> > > manpage, and instead its   man 5 sysctl.d   lists only files residing
> > > in …/sysctl.d/ directories as being read; hence the legacy symlink.
> > 
> > No, I have a bookworm machine, and the sysctl.conf(5) man page is
> > still there (in addition to the sysctl.d(5) man page).
> 
> Sorry, I meant to write trixie, not bookworm; stable and oldstable are
> the same. Your complaint is with unstable.

But unstable will migrate to trixie. Nothing has been done yet to
remove the man page (and references to /etc/sysctl.conf).

> > No, this is not sufficient. During an upgrade, a package is allowed
> > to do a merge of the new defaults (this occurs quite frequently).
> 
> That doesn't square with Policy, and this typical dialogue that
> we've all seen:
> 
>   Configuration file `foo'
>==> Modified (by you or by a script) since installation.
>==> Package distributor has shipped an updated version.
>  What would you like to do about it ?  Your options are:
>   Y or I  : install the package maintainer's version
>   N or O  : keep your currently-installed version
> D : show the differences between the versions
> Z : start a shell to examine the situation
>The default action is to keep your current version.
>   *** foo (Y/I/N/O/D/Z) [default=N] ? 
> 
> Might your merges apply to configuration files rather than conffiles?

There are several ways to update the configuration in an upgrade.
Not every package uses this method.

> I would file a bug against procps rather than systemd, for dropping
> the conffile status of /etc/sysctl.conf. Once you upgrade to Debian's
> 4.0.4-5, that file becomes just any old file that you happen to have
> under /etc/, and I don't see why systemd should be obliged to retain
> the legacy symlink any longer.

No, after the upgrade to 4.0.4-5, /etc/sysctl.conf was still seen
as a conffile (and there wasn't any announcement of a change). So
there wasn't any apparent bug in procps.

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



Re: Upgrading systemd may silently break your Unstable/Sid system!

2024-07-28 Thread Vincent Lefevre
On 2024-07-28 20:01:35 -0400, Greg Wooledge wrote:
> In the interests of posting something *useful*, here's a timeline.
> As I understand it, here's what's happened so far:
> 
> 2024-06-23: bug #1074156 filed against package procps
> procps: Depend or Recommend linux-sysctl-defaults
> Bug fixed by upload, closed.
> 
> 2024-07-11: procps (unstable) upload: /etc/sysctl.conf is "removed"
> (but not when upgrading)
> Closes #1074156
> 
> 2024-07-12: bug #1076190 filed against package systemd
> Installs dangling symlink /etc/sysctl.d/99-sysctl.conf
> Bug fixed by upload, closed.
> 
> 2024-07-24: systemd (unstable) upload: /etc/sysctl.d/99-sysctl.conf
> symlink is removed (for upgrades also)
> Closes #1076190
> 
> 2024-07-26: this thread is started on debian-user
> 
> 2024-07-26: bug #1077184 filed against package systemd
> systemd: /etc/sysctl.conf is no longer read
> Bug marked as wontfix, closed.
> 
> 2024-07-26: bug #1077187 filed against package procps
> procps: please drop/replace the obsolete sysctl.conf(5) man page
> Still open.

No, this thread was started *after* bug #1077184 (which I reported)
was closed as wontfix and *after* I reported bug #1077187.

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



Re: systemd may silently break your system!

2024-07-28 Thread Vincent Lefevre
On 2024-07-28 11:21:01 -0400, Greg Wooledge wrote:
> On Sun, Jul 28, 2024 at 16:43:01 +0200, Vincent Lefevre wrote:
> > More or less. In the systemd case, for each file, either one chooses
> > it, i.e. one has all the current defaults, or one chooses to provide
> > a replacement under /etc, i.e. one entirely replaces the defaults by
> > one's own settings. An include mechanism would allow a finer control
> > of the settings. The sysctl.d configuration system does not allow one
> > to include a file (to get the current defaults and possibly change
> > some of them just after).
> 
> I really don't understand what you're asking for here.
> 
> There are defaults in /usr/lib/sysctl.d/*.conf (which is documented
> in sysctl.d(5) even in bookworm).  The files in /etc/sysctl.d/*.conf
> will override those defaults.
> 
>Configuration files are read from directories in /etc/, /run/,
>/usr/local/lib/, and /lib/, in order of precedence, as listed in the
>SYNOPSIS section above. Files must have the ".conf" extension. Files in
>/etc/ override files with the same name in /run/, /usr/local/lib/, and
>/lib/. Files in /run/ override files with the same name under /usr/.
> 
> Why do you need to see the literal word "include" in some other file?
> What benefit does that give you?

Indeed, thanks to the specified ordering (though the recommendations
are not followed by Debian), an include mechanism would probably be
useless here.

But this is an issue for tmpfiles.d, because there is no way to know
whether a file added in /etc/tmpfiles.d will come after some file in
/usr/lib/tmpfiles.d (the issue is for files that could be added in
the future).

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



Re: Upgrading systemd may silently break your Unstable/Sid system!

2024-07-28 Thread Vincent Lefevre
On 2024-07-28 14:13:09 +, Michael Kjörling wrote:
> And posting on debian-user with a bombastic Subject line which implies
> that this is a widespread issue when it really only seems to exist in
> Unstable is, quite frankly, in my opinion at best dishonest.

No, the breakage was done *on purpose* (together with the lack
of announcement).

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



Re: systemd may silently break your system!

2024-07-28 Thread Vincent Lefevre
On 2024-07-28 00:07:56 -0500, David Wright wrote:
> On Sun 28 Jul 2024 at 04:25:32 (+0200), Vincent Lefevre wrote:
> > On 2024-07-27 20:25:54 -0400, Greg Wooledge wrote:
> 
> > > On Sun, Jul 28, 2024 at 01:17:19 +0200, Vincent Lefevre wrote:
> > > > The configuration got broken by a *systemd* upgrade:
> > > > 
> > > >   * Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships
> > > > /etc/sysctl.conf (Closes: #1076190)
> > > 
> > > The systemd change was only done because of the procps change.  After
> > > the procps maintainer REMOVED the /etc/sysctl.conf file, the symlink
> > > provided by the systemd package was dangling/broken.  So the systemd
> > > maintainer removed the symlink.
> > 
> > No, the /etc/sysctl.conf file has not been removed (yet) for
> > existing installations.
> > 
> > If the goal were to fix the dangling symlink for new installations,
> > then the solution should have been to no longer generate the
> > /etc/sysctl.d/99-sysctl.conf symlink for new installations (and
> > for existing installations, possibly remove it *only* if it was
> > dangling).
> 
> It looks accidental to me that systemd did that tidying up before
> procps had attempted to remove the file that it (procps) owned.

No, the breakage was done on purpose: my bug report specifically
about this breakage by systemd was closed in a rather abrupt way:

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

> > > > > As it turns out, it's a combination of the two packages.  In bookworm,
> > > > > /etc/sysctl.conf is a Conffile of the procps package, and
> > > > > /etc/sysctl.d/99-sysctl.conf is a regular file (non-Conffile) of
> > > > > the systemd package.
> 
> That symlink was suggested as legacy support for reading the conf file
> over a decade ago. Bullseye's   man 8 sysctl   indicates it still reads
> /etc/sysctl.conf with its --system option, but bookworm lacks that
> manpage, and instead its   man 5 sysctl.d   lists only files residing
> in …/sysctl.d/ directories as being read; hence the legacy symlink.

No, I have a bookworm machine, and the sysctl.conf(5) man page is
still there (in addition to the sysctl.d(5) man page).

> > This is rather poor design, because
> >   * there isn't a way to say that some default setting must be
> > preserved;
> 
> There is: just add an empty comment line. Now you own that default.

No, this is not sufficient. During an upgrade, a package is allowed
to do a merge of the new defaults (this occurs quite frequently).

> >   * changes by a user must be respected by the package, but a package
> > may decide that such a file is no longer read!
> 
> As I said, I think that happened by accident rather than design,
> a consequence of refactorising two packages with two maintainers.

See my bug report above.

> > A better design could be to provide Debian / vendor defaults (which
> > may change) by some kind of include mechanism. This is more or less
> > what fail2ban does, with .conf files and .local files (the .conf
> > files are not meant to be changed by the user, so that /usr/lib
> > might be a better place than /etc).
> 
> Um, isn't that what systemd provides as a matter of routine?

More or less. In the systemd case, for each file, either one chooses
it, i.e. one has all the current defaults, or one chooses to provide
a replacement under /etc, i.e. one entirely replaces the defaults by
one's own settings. An include mechanism would allow a finer control
of the settings. The sysctl.d configuration system does not allow one
to include a file (to get the current defaults and possibly change
some of them just after).

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



Re: info is not dead

2024-07-28 Thread Vincent Lefevre
On 2024-07-28 00:08:51 -0500, David Wright wrote:
> On Sun 28 Jul 2024 at 02:06:38 (+0200), Vincent Lefevre wrote:
> > On 2024-07-23 11:13:47 -0500, Nate Bargmann wrote:
> > > The GNU info documentation is really intended to be read in Emacs where
> > > some nice formatting is done in the GUI Emacs version.  The stand alone
> > > GNU info browser is rather obtuse.  I found a much better option to be
> > > the independent pinfo (Debian package of the same name) browser which
> > > provides navigation up and down through the document using Lynx style
> > > key bindings.  If pinfo doesn't find an info document it will open a man
> > > page when one is available.
> > 
> > But for searching, how can one get the previous match with pinfo?
> > (info has { and } to navigate through the matches, Lynx has n and N,
> > but what about pinfo?)
> 
> I think you define KEY_SEARCH_AGAIN_1 to whichever keystroke you want.
> (AIUI it has no default already defined in /etc/.pinforc)

KEY_SEARCH_AGAIN_1 gives the *next* match, not the previous one.

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



Re: systemd may silently break your system!

2024-07-27 Thread Vincent Lefevre
On 2024-07-27 20:25:54 -0400, Greg Wooledge wrote:
> On Sun, Jul 28, 2024 at 01:04:14 +0200, Vincent Lefevre wrote:
> > On 2024-07-27 10:23:01 +0200, Michel Verdier wrote:
> > > /etc/sysctl.d/README.sysctl recommends to use a separate file such as
> > > /etc/sysctl.d/local.conf
> > 
> > No, it does *not* recommend anything:
> > 
> > 
> > Files located in this directory can set kernel parameters using the
> > sysctl(8) or systemd-sysctl(8) tool which is typically run with a
> > unit/init file started during the boot sequence.
> > 
> > For details regarding the configuration files refer to
> > sysctl.d(5) or sysctl.conf(5)
> > 
> 
> You're on unstable.  In bookworm, it says this:
> 
> 
> Kernel system variables configuration files
> 
> Files found under the /etc/sysctl.d directory that end with .conf are
> parsed within sysctl(8) at boot time.  If you want to set kernel variables
> you can either edit /etc/sysctl.conf or make a new file.
> 
> The filename isn't important, but don't make it a package name as it may clash
> with something the package builder needs later. It must end with .conf though.
> 
> My personal preference would be for local system settings to go into
> /etc/sysctl.d/local.conf but as long as you follow the rules for the names
> of the file, anything will work. See sysctl.conf(8) man page for details
> of the format.
> 
> After making any changes, please run "service procps force-reload" (or, from
> a Debian package maintainer script "deb-systemd-invoke restart 
> procps.service").
> 
> 
> (Wrong section number, too.)

In any case, there isn't any recommendation either. It even says "If
you want to set kernel variables you can either edit /etc/sysctl.conf
or [...]", so that editing /etc/sysctl.conf seems fine according to
this file.

> On Sun, Jul 28, 2024 at 01:17:19 +0200, Vincent Lefevre wrote:
> > The configuration got broken by a *systemd* upgrade:
> > 
> >   * Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships
> > /etc/sysctl.conf (Closes: #1076190)
> 
> The systemd change was only done because of the procps change.  After
> the procps maintainer REMOVED the /etc/sysctl.conf file, the symlink
> provided by the systemd package was dangling/broken.  So the systemd
> maintainer removed the symlink.

No, the /etc/sysctl.conf file has not been removed (yet) for
existing installations.

If the goal were to fix the dangling symlink for new installations,
then the solution should have been to no longer generate the
/etc/sysctl.d/99-sysctl.conf symlink for new installations (and
for existing installations, possibly remove it *only* if it was
dangling).

> > > As it turns out, it's a combination of the two packages.  In bookworm,
> > > /etc/sysctl.conf is a Conffile of the procps package, and
> > > /etc/sysctl.d/99-sysctl.conf is a regular file (non-Conffile) of
> > > the systemd package.
> > 
> > What does a regular file make different compared to a conffile
> > concerning its handling?
> 
> A conffile is user-managed, so any changes you make to a conffile must
> be respected by the package.  It can't just overwrite your changes, or
> restore a conffile if you've deleted it.

This is rather poor design, because
  * there isn't a way to say that some default setting must be
preserved;
  * changes by a user must be respected by the package, but a package
may decide that such a file is no longer read!

A better design could be to provide Debian / vendor defaults (which
may change) by some kind of include mechanism. This is more or less
what fail2ban does, with .conf files and .local files (the .conf
files are not meant to be changed by the user, so that /usr/lib
might be a better place than /etc).

> > > In unstable, apparently, *both* of them are gone.
> > 
> > No, /etc/sysctl.conf is not gone on existing installations.
> > It is just no longer read.
> 
> It's... not?  Then what the hell does the procps change text mean?
> 
> > > while 
> > > <https://metadata.ftp-master.debian.org/changelogs//main/p/procps/procps_4.0.4-5_changelog>
> > >  says:
> > > procps (2:4.0.4-5) unstable; urgency=medium
> > > 
> > >   * Add Recommends: linux-sysctl-defaults Closes: #1074156
> > >   * Remove /etc/sysctl.conf as using /etc/sysctl.d/*.conf is be

Re: bash history

2024-07-27 Thread Vincent Lefevre
On 2024-07-27 22:50:17 +0100, mick.crane wrote:
> In debian bookworm, xfce desktop, different virtual terminals have a
> different history if same user presses "up key" in different virtual
> terminals ?
> Is this something that can be changed so history is shared between virtual
> terminals?

This is possible with zsh (option SHARE_HISTORY). But I do not use
this option: if I want to retrieve a command from another terminal,
I simply re-execute the shell to get the whole history of commands
typed so far (but there are other ways to manipulate the history).

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



Re: info is not dead

2024-07-27 Thread Vincent Lefevre
On 2024-07-23 11:13:47 -0500, Nate Bargmann wrote:
> The GNU info documentation is really intended to be read in Emacs where
> some nice formatting is done in the GUI Emacs version.  The stand alone
> GNU info browser is rather obtuse.  I found a much better option to be
> the independent pinfo (Debian package of the same name) browser which
> provides navigation up and down through the document using Lynx style
> key bindings.  If pinfo doesn't find an info document it will open a man
> page when one is available.

But for searching, how can one get the previous match with pinfo?
(info has { and } to navigate through the matches, Lynx has n and N,
but what about pinfo?)

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



Re: systemd may silently break your system!

2024-07-27 Thread Vincent Lefevre
On 2024-07-27 09:26:49 -0400, Greg Wooledge wrote:
> > On 2024-07-26, Vincent Lefevre wrote:
> > 
> > > The /etc/sysctl.d/99-sysctl.conf symlink has been removed
> > > (currently in unstable) *without any announcement*, so that
> > > the /etc/sysctl.conf file (which is still documented, BTW)
> > > is no longer read.
> > >
> > > So, be careful if you have important settings there (security...).
> 
> I kept wondering: what does this have to do with the Subject
> header?  The files in question belong to the procps package, not
> to systemd, right?

The configuration got broken by a *systemd* upgrade:

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

> As it turns out, it's a combination of the two packages.  In bookworm,
> /etc/sysctl.conf is a Conffile of the procps package, and
> /etc/sysctl.d/99-sysctl.conf is a regular file (non-Conffile) of
> the systemd package.

What does a regular file make different compared to a conffile
concerning its handling?

> In unstable, apparently, *both* of them are gone.

No, /etc/sysctl.conf is not gone on existing installations.
It is just no longer read.

> <https://metadata.ftp-master.debian.org/changelogs//main/s/systemd/systemd_256.4-2_changelog>
>  says:
>   [ Luca Boccassi ]
>   * Drop /etc/sysctl.d/99-sysctl.conf symlink procps no longer ships
> /etc/sysctl.conf (Closes: #1076190)

/etc/sysctl.conf is no longer shipped only for *new* installations.
But /etc/sysctl.d/99-sysctl.conf got removed also for *existing*
installations.

> while 
> <https://metadata.ftp-master.debian.org/changelogs//main/p/procps/procps_4.0.4-5_changelog>
>  says:
> procps (2:4.0.4-5) unstable; urgency=medium
> 
>   * Add Recommends: linux-sysctl-defaults Closes: #1074156
>   * Remove /etc/sysctl.conf as using /etc/sysctl.d/*.conf is better
>   * Updated /etc/sysctld.d/README

only for *new* installations.

There's a bug about it (about existing installations). But the systemd
change should have been done *after* the future correction of procps
in order not to break configuration.

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



Re: systemd may silently break your system!

2024-07-27 Thread Vincent Lefevre
On 2024-07-27 10:23:01 +0200, Michel Verdier wrote:
> On 2024-07-26, Vincent Lefevre wrote:
> 
> > The /etc/sysctl.d/99-sysctl.conf symlink has been removed
> > (currently in unstable) *without any announcement*, so that
> > the /etc/sysctl.conf file (which is still documented, BTW)
> > is no longer read.
> >
> > So, be careful if you have important settings there (security...).
> 
> /etc/sysctl.d/README.sysctl recommends to use a separate file such as
> /etc/sysctl.d/local.conf

No, it does *not* recommend anything:


Files located in this directory can set kernel parameters using the
sysctl(8) or systemd-sysctl(8) tool which is typically run with a
unit/init file started during the boot sequence.

For details regarding the configuration files refer to
sysctl.d(5) or sysctl.conf(5)


Worse, it refers to the sysctl.conf(5) man page, which lists
/etc/sysctl.conf as the possible files:

   As the /etc/sysctl.conf file is used to override  default  kernel
  
   parameter values, only a small number of parameters is predefined
   in the file.  Use /sbin/sysctl -a or follow sysctl(8) to list all
   possible parameters. The description of individual parameters can
   be found in the kernel documentation.

and in the FILES section:

   /etc/sysctl.d/*.conf
   /run/sysctl.d/*.conf
   /usr/local/lib/sysctl.d/*.conf
   /usr/lib/sysctl.d/*.conf
   /lib/sysctl.d/*.conf
   /etc/sysctl.conf
   

So I did exactly as the documentation said, and this got broken!!!

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



Re: stty permanently undef "start"

2024-07-26 Thread Vincent Lefevre
On 2024-07-10 16:00:48 +0200, Nicolas George wrote:
> Greg Wooledge (12024-07-10):
> > You could -- but if you do so, you should definitely surround it with
> > a check for stdin being a terminal (test -t 0 or equivalent).
> 
> Does bash execute .bashrc when it is not interactive?

Yes, it may execute it. From the bash(1) man page:

  If bash determines it is being run non-interactively in this
  fashion, it reads and executes commands from /etc/bash.bashrc
  and ~/.bashrc, if these files exist and are readable.

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



Re: systemd-cryptsetup

2024-07-26 Thread Vincent Lefevre
On 2024-07-14 13:17:45 +0200, Lists wrote:
> On 2024-07-14 11:00, Nicolas George wrote:
> > Hi.
> > 
> > In case you are running unstable or testing and it recently started
> > blocking at boot waiting for encrypted swap or something to do with
> > encrypted disks:
> > 
> > Check if systemd-cryptsetup is installed.
> > 
> > HtH
> 
> Thanks for the confirmation!
> 
> I downloaded debian-installer for testing yesterday a got exactly this
> problem when setting up a new system with encrypted / and /home partitions.
> When I researched the problem I encountered some posts stating that systemd
> had its own implementation for cryptsetup and that there were compatibility
> issues. The x-initrd.attach notices were my first queue to start thinking in
> the direction of systemd.
> 
> 
> Why the *&^%#@! it is necessary to have this borg-like behaviour of systemd
> is beyond me. This is not the first time it is causing problems. TBH, this
> is more an ommission of d-i than of systemd. But then again, it would not
> have happened if there was just one implementation of cryptsetup.
> 

systemd has "Recommends: [...] systemd-cryptsetup [...]".

So this is the following bug:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931283

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



systemd may silently break your system!

2024-07-26 Thread Vincent Lefevre
The /etc/sysctl.d/99-sysctl.conf symlink has been removed
(currently in unstable) *without any announcement*, so that
the /etc/sysctl.conf file (which is still documented, BTW)
is no longer read.

So, be careful if you have important settings there (security...).

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



Re: Need help with narroely focused use case of Emacs

2024-06-29 Thread Vincent Lefevre
On 2024-06-28 20:53:50 +, Michael Kjörling wrote:
> Yes, it almost certainly can be done with a single sed (or other
> similar tool) invocation where the regular expression matches
> precisely what you want it to match. But unless this is something you
> will do very often, I tend to prefer readability over being clever,
> even if the readable version is somewhat less performant.

To match a range inside a regexp, $(rgxg range 1 119) is readable. :)

rgxg is provided by the package of the same name.

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



Re: can't connect to eduroam due to SSL3 unsupported protocol

2024-06-20 Thread Vincent Lefevre
On 2024-06-17 15:08:54 -0400, Dan Ritter wrote:
> Vincent Lefevre wrote: 
> > On 2024-06-17 08:26:39 -0400, Dan Ritter wrote:
> > > On stable:
> > > $ openssl list -disabled
> > > Disabled algorithms:
> > > IDEA
> > > MD2
> > > MDC2
> > > RC5
> > > SCTP
> > > SSL3
> > > ZLIB
> > > 
> > > So, SSL3 support was removed at least that long ago. I think it
> > > was actually dropped around 2016.
> > 
> > That's strange because when I installed the machine in October,
> > there were no issues.
> 
> Perhaps the change is not in your system but in theirs?

I've got a confirmation that their Radius servers still use SSL3,
and they said that they could not upgrade them.

But perhaps the authentication is done differently when I connect
locally (still using eduroam)?

I could try again locally if need be.

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



Re: can't connect to eduroam due to SSL3 unsupported protocol

2024-06-17 Thread Vincent Lefevre
On 2024-06-17 10:18:09 -0400, Stefan Monnier wrote:
> > Under Debian/unstable, I can't connect to eduroam due to the following
> > reason:
> 
> AFAIK, while "the eduroam" looks like one thing it's just a bunch of
> local wifi networks, each one administered&managed mostly independently
> and with different configurations.  By and large, if you can connect to
> eduroam at one place it's likely it'll also work elsewhere but it's not
> always the case.

Isn't the authentication done by the remote side, thus will always
require the same protocol for a given account?

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



Re: can't connect to eduroam due to SSL3 unsupported protocol

2024-06-17 Thread Vincent Lefevre
On 2024-06-17 08:26:39 -0400, Dan Ritter wrote:
> On stable:
> $ openssl list -disabled
> Disabled algorithms:
> IDEA
> MD2
> MDC2
> RC5
> SCTP
> SSL3
> ZLIB
> 
> So, SSL3 support was removed at least that long ago. I think it
> was actually dropped around 2016.

That's strange because when I installed the machine in October,
there were no issues.

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



can't connect to eduroam due to SSL3 unsupported protocol

2024-06-17 Thread Vincent Lefevre
Hi,

Under Debian/unstable, I can't connect to eduroam due to the following
reason:

Jun 17 13:58:31 qaa wpa_supplicant[1184]: wlp0s20f3: 
CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
Jun 17 13:58:31 qaa wpa_supplicant[1184]: wlp0s20f3: CTRL-EVENT-EAP-METHOD EAP 
vendor 0 method 25 (PEAP) selected
Jun 17 13:58:31 qaa wpa_supplicant[1184]: SSL: SSL3 alert: write (local SSL3 
detected an error):fatal:protocol version
Jun 17 13:58:31 qaa wpa_supplicant[1184]: OpenSSL: openssl_handshake - 
SSL_connect error:0A000102:SSL routines::unsupported protocol
Jun 17 13:58:36 qaa wpa_supplicant[1184]: wlp0s20f3: CTRL-EVENT-EAP-FAILURE EAP 
authentication failed

Anyone knows what's wrong?

(There were such kinds of issues several years ago, but I thought
this was fixed.)

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



Re: Copy from xterm to text editor........

2024-06-13 Thread Vincent Lefevre
On 2024-06-12 21:16:51 -0600, Charles Curley wrote:
> Note that this is very temporary storage. It will not put the text in
> the clipboard, nor will a clipboard stack program like clipman see it.

This can be changed with selectToClipboard:

  selectToClipboard (class SelectToClipboard)
  Tells  xterm whether to use the PRIMARY or CLIPBOARD for SELECT
  tokens in the selection mechanism.  The set-select  action  can
  change this at runtime, allowing the user to work with programs
  that  handle  only  one  of  these  mechanisms.  The default is
  “false”, which tells it to use PRIMARY.

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



Re: Why isn't the "whois" package (Priority: standard) installed by default?

2024-06-13 Thread Vincent Lefevre
On 2024-06-13 22:15:05 +0200, Javier Barroso wrote:
> Hello,
> 
> El jue., 13 jun. 2024 20:48, Vincent Lefevre  escribió:
> 
> > On 2024-06-13 14:43:25 -0400, Greg Wooledge wrote:
> > > On Thu, Jun 13, 2024 at 07:57:59PM +0200, Vincent Lefevre wrote:
> > > > The "whois" package has "Priority: standard".
> > >
> > > hobbit:~$ apt-cache show whois | grep Priority
> > > Priority: optional
> >
> > qaa:~> apt-cache show whois | grep Priority
> > Priority: optional
> > Priority: optional
> >
> > but
> >
> > qaa:~> dpkg -s whois | grep Priority
> > Priority: standard
> >
> I think it is ftpmaster override
> 
> See https://wiki.debian.org/FtpMaster/Override

Yes, but why isn't the priority of the package changed instead?

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



Why isn't the "whois" package (Priority: standard) installed by default?

2024-06-13 Thread Vincent Lefevre
The "whois" package has "Priority: standard".

According to the Debian policy[*]:

  standard

These packages provide a reasonably small but not too limited
character-mode system. This is what will be installed by default
if the user doesn’t select anything else. It doesn’t include many
large applications.

Two packages that both have a priority of standard or higher must
not conflict with each other.

[*] https://www.debian.org/doc/debian-policy/ch-archive.html

So, why isn't this package installed by default?

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



Re: Why isn't the "whois" package (Priority: standard) installed by default?

2024-06-13 Thread Vincent Lefevre
On 2024-06-13 14:43:25 -0400, Greg Wooledge wrote:
> On Thu, Jun 13, 2024 at 07:57:59PM +0200, Vincent Lefevre wrote:
> > The "whois" package has "Priority: standard".
> 
> hobbit:~$ apt-cache show whois | grep Priority
> Priority: optional

qaa:~> apt-cache show whois | grep Priority
Priority: optional
Priority: optional

but

qaa:~> dpkg -s whois | grep Priority
Priority: standard

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



Re: timeout in shutdown, mutt killed by SIGKILL

2024-06-03 Thread Vincent Lefevre
On 2024-05-31 19:05:45 +0700, Max Nikulin wrote:
> Do you see an attempt to send SIGTERM to mutt before timeout and SIGKILL?

Unfortunately, there was no information from systemd. Some daemons
log a received SIGTERM, but mutt isn't a daemon.

> What other processes survived first step? Are there something suspicious
> before SIGKILL stage?

According to the journalctl output, only mutt survived (the only
process to receive a SIGKILL). And nothing suspicious.

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



Re: timeout in shutdown, mutt killed by SIGKILL

2024-05-31 Thread Vincent Lefevre
On 2024-05-31 10:10:32 +0200, Vincent Lefevre wrote:
> On 2024-05-31 10:02:57 +0700, Max Nikulin wrote:
> > Do you mean that mutt properly exits unless it receives SIGTERM in the
> > course of shutdown process?
> 
> I think that this was not the first time I did a shutdown while Mutt
> was still running. But this was the first time it did not exit.

I've tried a shutdown with Mutt still running in GNU Screen
a couple of times, and I got no timeout, i.e. Mutt exited as
expected.

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



Re: timeout in shutdown, mutt killed by SIGKILL

2024-05-31 Thread Vincent Lefevre
On 2024-05-31 10:02:57 +0700, Max Nikulin wrote:
> Do you mean that mutt properly exits unless it receives SIGTERM in the
> course of shutdown process?

I think that this was not the first time I did a shutdown while Mutt
was still running. But this was the first time it did not exit.

> I would try to enable debug log in mutt. There is a chance that
> networking is already disabled (or some other system unit important
> for mutt is already stopped) when systemd tries to kill mutt first
> time.

No, according to the logs, the network was stopped after SIGKILL
was sent to Mutt:

May 29 01:55:26 qaa systemd[1]: session-2.scope: Stopping timed out. Killing.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Killing process 2990 (mutt) 
with signal SIGKILL.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Failed with result 'timeout'.
May 29 01:55:26 qaa systemd[1]: Stopped session-2.scope - Session 2 of User 
vinc17.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Consumed 8h 17min 54.832s CPU 
time.
May 29 01:55:26 qaa systemd[1]: Stopping systemd-logind.service - User Login 
Management...
[...]
May 29 01:55:26 qaa systemd[1]: Stopping NetworkManager.service - Network 
Manager...
May 29 01:55:26 qaa NetworkManager[1238]:   [1716940526.2966] caught 
SIGTERM, shutting down normally.
May 29 01:55:26 qaa NetworkManager[1238]:   [1716940526.2975] dhcp4 
(eth0): canceled DHCP transaction

Note that mutt is not the only case of timeout at shutdown. There's
also

May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: State 
'stop-sigterm' timed out. Killing.
May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: Killing process 
116031 (xdg-document-po) with signal SIGKILL.
May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: Killing process 
116037 (fusermount3) with signal SIGKILL.
May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: Main process 
exited, code=killed, status=9/KILL
May 25 22:53:32 qaa systemd[2230]: xdg-document-portal.service: Failed with 
result 'timeout'.

This one is a known issue:

https://github.com/flatpak/xdg-desktop-portal/issues/999

I'm wondering whether there could be a same cause.

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



Re: timeout in shutdown, mutt killed by SIGKILL

2024-05-30 Thread Vincent Lefevre
On 2024-05-30 00:19:30 +0700, Max Nikulin wrote:
> On 29/05/2024 07:44, Vincent Lefevre wrote:
> > But I don't understand why there was a timeout. Does this mean that
> > mutt didn't react to SIGTERM? Any reason?
> 
> Have you tried to send SIGTERM to mutt?

I didn't. AFAIK, systemd sends a SIGTERM to all the processes of the
session: that's the

May 29 01:55:05 qaa systemd[1]: Stopping session-2.scope - Session 2 of User 
vinc17...

but this timed out, apparently due to the mutt process, which was
still running, so that systemd sent a SIGKILL (which succeeded).

May 29 01:55:26 qaa systemd[1]: session-2.scope: Stopping timed out. Killing.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Killing process 2990 (mutt) 
with signal SIGKILL.

> If it ignores this signal or the reaction is some prompt then you
> need to find another way to stop mutt and to configure systemd user
> session to do it on logout (shutdown).

A SIGTERM normally kills mutt. In signal.c, signals are blocked
"while doing critical ops", namely for compressing/decompressing
(which I don't use) and when locking a mailbox (but I don't see
why this would have happened). Otherwise the signal handler just
does that:

static void exit_handler (int sig)
{
  curs_set (1);
  endwin (); /* just to be safe */

  exit_print_string (Caught_Signal_L10N ? Caught_Signal_L10N : "Caught signal 
");
#if SYS_SIGLIST_DECLARED
  exit_print_string (sys_siglist[sig]);
#else
#if (__sun__ && __svr4__)
  exit_print_string (_sys_siglist[sig]);
#else
#if (__alpha && __osf__)
  exit_print_string (__sys_siglist[sig]);
#else
  exit_print_int (sig);
#endif
#endif
#endif
  exit_print_string (Exiting_L10N ? Exiting_L10N : "...  Exiting.\n");
  exit (0);
}

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



Re: timeout in shutdown, mutt killed by SIGKILL

2024-05-30 Thread Vincent Lefevre
On 2024-05-29 16:13:05 -, Curt wrote:
> On 2024-05-29, Vincent Lefevre  wrote:
> > During the latest shutdown:
> >
> > May 29 01:55:05 qaa systemd[1]: Stopping session-2.scope - Session 2 of 
> > User vinc17...
> > [...]
> > May 29 01:55:26 qaa systemd[1]: session-2.scope: Stopping timed out. 
> > Killing.
> > May 29 01:55:26 qaa systemd[1]: session-2.scope: Killing process 2990 
> > (mutt) with signal SIGKILL.
> > May 29 01:55:26 qaa systemd[1]: session-2.scope: Failed with result 
> > 'timeout'.
> > May 29 01:55:26 qaa systemd[1]: Stopped session-2.scope - Session 2 of User 
> > vinc17.
> > May 29 01:55:26 qaa systemd[1]: session-2.scope: Consumed 8h 17min 54.832s 
> > CPU time.
> > May 29 01:55:26 qaa systemd[1]: Stopping systemd-logind.service - User 
> > Login Management...
> > May 29 01:55:26 qaa systemd[1]: Stopping user@1000.service - User Manager 
> > for UID 1000...
> > [...]
> >
> > Note: I had set DefaultTimeoutStopSec=20s because then is normally
> > sufficient.
> >
> > The mutt process was running in GNU Screen. The current mailbox
> > was just a local one. Mutt does no network connections (I do not
> > use IMAP). I general, I quit it before logging out, but this time,
> > it seems that I forgot.
> >
> > But I don't understand why there was a timeout. Does this mean that
> > mutt didn't react to SIGTERM? Any reason?
> >
> 
> sudo journalctl -b-1?

See above. There's nothing else about mutt in the journal.

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



Re: Uninstalling a package and its entourage

2024-05-28 Thread Vincent Lefevre
On 2024-05-27 18:42:48 +0300, mindaugascelies...@gmail.com wrote:
> On Monday, May 27, 2024 5:59:55 PM EEST Nicolas George wrote:
> > Eben King (12024-05-27):
> > > Is there an easier way to uninstall a package and everything it brought in
> > > at one swell foop?  Thanks.
> > 
> > The packages you did not choose to install but were installed as a
> > consequence are shown by apt-get when you do almost anything:
> > 
> > The following packages were automatically installed and are no longer
> > required: 
> > 
> > Regards,
> Hello.
> 
> You can use one simple command: sudo apt autoremove --purge

For various reasons, this may leave automatically installed packages
behind.

First, for symmetry with "apt install", you would need

APT::AutoRemove::SuggestsImportant "false";

Still, a package could have been automatically installed due to a
dependency, but it may be in another OR dependency, in which case
apt will not propose its removal, even though the OR dependency
would still be satisfied.

So, you should either look at the logs or keep trace of the packages
that are installed before installation of new packages.

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



timeout in shutdown, mutt killed by SIGKILL

2024-05-28 Thread Vincent Lefevre
During the latest shutdown:

May 29 01:55:05 qaa systemd[1]: Stopping session-2.scope - Session 2 of User 
vinc17...
[...]
May 29 01:55:26 qaa systemd[1]: session-2.scope: Stopping timed out. Killing.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Killing process 2990 (mutt) 
with signal SIGKILL.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Failed with result 'timeout'.
May 29 01:55:26 qaa systemd[1]: Stopped session-2.scope - Session 2 of User 
vinc17.
May 29 01:55:26 qaa systemd[1]: session-2.scope: Consumed 8h 17min 54.832s CPU 
time.
May 29 01:55:26 qaa systemd[1]: Stopping systemd-logind.service - User Login 
Management...
May 29 01:55:26 qaa systemd[1]: Stopping user@1000.service - User Manager for 
UID 1000...
[...]

Note: I had set DefaultTimeoutStopSec=20s because then is normally
sufficient.

The mutt process was running in GNU Screen. The current mailbox
was just a local one. Mutt does no network connections (I do not
use IMAP). I general, I quit it before logging out, but this time,
it seems that I forgot.

But I don't understand why there was a timeout. Does this mean that
mutt didn't react to SIGTERM? Any reason?

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



Re: LibreOffice removed from Debian

2024-04-17 Thread Vincent Lefevre
On 2024-04-17 16:13:30 +0200, Vincent Lefevre wrote:
> I've sent a message to bug 1069123 (which requested the removal).
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069123#20 and
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069123#25 say
> that the request was correct, but the bugs shouldn't have been
> closed. They have now been reopened.

Actually, if I understand correctly, LibreOffice will really be
removed on some architectures (armhf ppc64el s390x mips64el riscv64).
Fortunately, I am not concerned by this removal (only by the fact
that my bug reports were closed, but this has now been fixed).

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



Re: LibreOffice removed from Debian

2024-04-17 Thread Vincent Lefevre
On 2024-04-17 14:59:18 +0100, Brad Rogers wrote:
> On Wed, 17 Apr 2024 15:35:57 +0200
> Vincent Lefevre  wrote:
> 
> Hello Vincent,
> 
> >If this is not permanent, why have all the bugs been closed?
> 
> That I have no answer for.

I've sent a message to bug 1069123 (which requested the removal).

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069123#20 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069123#25 say
that the request was correct, but the bugs shouldn't have been
closed. They have now been reopened.

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



Re: LibreOffice removed from Debian

2024-04-17 Thread Vincent Lefevre
On 2024-04-17 14:26:12 +0100, Brad Rogers wrote:
> On Wed, 17 Apr 2024 15:12:39 +0200
> Vincent Lefevre  wrote:
> 
> Hello Vincent,
> 
> >Is there any reason why LibreOffice has been removed from Debian???
> 
> https://tracker.debian.org/pkg/libreoffice
> 
> Has all the info you need, and more.  Expect it to be removed from
> testing, too.

Indeed:

"This package has been requested to be removed. This means that, when
this request gets processed by an ftp-master, this package will no
longer be in unstable, and will automatically be removed from testing
too afterwards. If for some reason you want keep this package in
unstable, please discuss so in the bug. Please see bug number #1069123
for more information."

> This is not permanent.

If this is not permanent, why have all the bugs been closed?

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



Re: LibreOffice removed from Debian

2024-04-17 Thread Vincent Lefevre
On 2024-04-17 15:24:47 +0200, Vincent Lefevre wrote:
> On 2024-04-17 15:19:26 +0200, Marco Moock wrote:
> > Am 17.04.2024 um 15:12:39 Uhr schrieb Vincent Lefevre:
> > 
> > > Is there any reason why LibreOffice has been removed from Debian???
> > 
> > https://tracker.debian.org/pkg/libreoffice
> > According to the tracker, it specific release got removed from
> > experimental. This is a special repo for testing and should only be
> > used by people who want an unstable testing system.
> > 
> > It is still available in stable and also in unstable.
> 
> No, I do not use experimental (except in rare cases, but libreoffice
> was not concerned), and (all?) my bug reports against libreoffice have
> been closed due to this removal.

Not just mine. It seems that *all* bug reports against
libreoffice have been closed:

  
https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=0;ordering=normal;repeatmerged=0;src=libreoffice

Only bug 883734 is open, but this is because it has been reopened.

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



Re: LibreOffice removed from Debian

2024-04-17 Thread Vincent Lefevre
On 2024-04-17 15:19:26 +0200, Marco Moock wrote:
> Am 17.04.2024 um 15:12:39 Uhr schrieb Vincent Lefevre:
> 
> > Is there any reason why LibreOffice has been removed from Debian???
> 
> https://tracker.debian.org/pkg/libreoffice
> According to the tracker, it specific release got removed from
> experimental. This is a special repo for testing and should only be
> used by people who want an unstable testing system.
> 
> It is still available in stable and also in unstable.

No, I do not use experimental (except in rare cases, but libreoffice
was not concerned), and (all?) my bug reports against libreoffice have
been closed due to this removal.

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



LibreOffice removed from Debian

2024-04-17 Thread Vincent Lefevre
Is there any reason why LibreOffice has been removed from Debian???

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



Re: inconsistency in the symlinks under /etc/systemd

2024-04-11 Thread Vincent Lefevre
On 2024-04-10 23:47:36 -0500, David Wright wrote:
> On Thu 11 Apr 2024 at 03:36:59 (+0200), Vincent Lefevre wrote:
> > On 2024-04-10 09:52:51 -0400, Dan Purgert wrote:
> > > I'd hazard it's a consequence of usrmerge being the "default state" in
> > > one installation and not the other.
> > 
> > Both machines have always been usr-merged (i.e. from the Debian
> > installation).
> 
> This is trixie, is it not, so perhaps bugs are being fixed
> in package installation support programs. You should be able
> to see the symlinks being created in /var/log/apt/term.log*
> if they haven't yet rotated away.

On the first machine:

Setting up dmeventd (2:1.02.185-2) ...
Created symlink /etc/systemd/system/sockets.target.wants/dm-event.socket → 
/lib/systemd/system/dm-event.socket.
Setting up lvm2 (2.03.16-2) ...
Created symlink 
/etc/systemd/system/sysinit.target.wants/blk-availability.service → 
/lib/systemd/system/blk-availability.service.
Created symlink /etc/systemd/system/sysinit.target.wants/lvm2-monitor.service → 
/lib/systemd/system/lvm2-monitor.service.
Created symlink /etc/systemd/system/sysinit.target.wants/lvm2-lvmpolld.socket → 
/lib/systemd/system/lvm2-lvmpolld.socket.

On the second machine:

Setting up dmeventd (2:1.02.185-2) ...
Created symlink /etc/systemd/system/sockets.target.wants/dm-event.socket → 
/usr/lib/systemd/system/dm-event.socket.
Setting up lvm2 (2.03.16-2) ...
Created symlink 
/etc/systemd/system/sysinit.target.wants/blk-availability.service → 
/usr/lib/systemd/system/blk-availability.service.
Created symlink /etc/systemd/system/sysinit.target.wants/lvm2-monitor.service → 
/usr/lib/systemd/system/lvm2-monitor.service.
Created symlink /etc/systemd/system/sysinit.target.wants/lvm2-lvmpolld.socket → 
/usr/lib/systemd/system/lvm2-lvmpolld.socket.

> Or else, have you run systemctl on dmeventd, in order to change its
> status?

I'm not sure 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)



Re: inconsistency in the symlinks under /etc/systemd

2024-04-10 Thread Vincent Lefevre
On 2024-04-10 09:52:51 -0400, Dan Purgert wrote:
> I'd hazard it's a consequence of usrmerge being the "default state" in
> one installation and not the other.

Both machines have always been usr-merged (i.e. from the Debian
installation).

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



inconsistency in the symlinks under /etc/systemd

2024-04-10 Thread Vincent Lefevre
Hi,

On one 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

and on another one, I have

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

These symlinks were created at Debian installation time, and in
both cases, the dmeventd version is 2:1.02.196-1+b1.

Shouldn't the system ensure that symlinks are consistent on different
machines (even though the above symlinks are equivalent), for instance
to ease the comparison of configurations between machines?

For instance, shouldn't usr-is-merged convert the symlinks to a
canonical path?

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



test of a gnuplot bug visible with Pango 1.52 (Debian/unstable)

2024-02-29 Thread Vincent Lefevre
Hi,

Since the upgrade of the Pango library to 1.52 in Debian/unstable, I'm
seeing an annoying bug in gnuplot with the wxt terminal. The issue can
be reproduced with the following command:

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

A window appears, but it is not drawn and it cannot be deleted by
gnuplot. One can destroy it, but the gnuplot process is still running
(in background).

I can observe this bug with the FVWM window manager, with both
manual placement and immediate placement (manual placement can
make the problem worse). I don't think that this is a bug in
Pango: the commit that introduces the change of behavior does
some optimization in threading, which probably makes Pango a bit
faster, which triggers a race condition (note that conversely,
if I use ssh, even "ssh localhost", this makes the problem
disappear).

Details in my bug reports:
  https://sourceforge.net/p/gnuplot/bugs/2693/
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064982

Can anyone else reproduce this issue, in particular with other
window managers?

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



ata6.00: failed to IDENTIFY (I/O error, err_mask=0x100)

2024-01-12 Thread Vincent Lefevre
12 16:52:07 disset kernel: ata6: SATA link up 1.5 Gbps 
(SStatus 113 SControl 300)

journalctl-0:Jan 12 17:04:10 disset kernel: ata6: SATA max UDMA/133 abar 
m2048@0x88643000 port 0x88643380 irq 56
journalctl-0:Jan 12 17:04:10 disset kernel: ata6: SATA link up 1.5 Gbps 
(SStatus 113 SControl 300)
journalctl-0:Jan 12 17:04:10 disset kernel: ata6.00: failed to IDENTIFY (I/O 
error, err_mask=0x100)
journalctl-0:Jan 12 17:04:10 disset kernel: ata6: SATA link up 1.5 Gbps 
(SStatus 113 SControl 300)
journalctl-0:Jan 12 17:04:10 disset kernel: ata6.00: failed to IDENTIFY (I/O 
error, err_mask=0x100)
journalctl-0:Jan 12 17:04:10 disset kernel: ata6: SATA link up 1.5 Gbps 
(SStatus 113 SControl 300)
journalctl-0:Jan 12 17:04:10 disset kernel: ata6.00: failed to IDENTIFY (I/O 
error, err_mask=0x100)
journalctl-0:Jan 12 17:04:10 disset kernel: ata6: SATA link up 1.5 Gbps 
(SStatus 113 SControl 300)

Note: journalctl-9, journalctl-8 and journalctl-0 correspond to
a boot with the 6.5.0-5-amd64 kernel, and the others ones to a
boot with the 6.6.9-amd64 kernel. So this does not seems to be
related to the kernel version.

Any idea?

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



Re: Perl module installation via CPAN and signature error

2024-01-11 Thread Vincent Lefevre
With strace, I could see the command that was executed:

  gpg --verify --batch --no-tty -q --logger-fd=1 
--keyserver=hkp://pool.sks-keyservers.net:11371

on a temporary file, but almost equivalent to the CHECKSUMS file.

Now, I can try that directly:

qaa:~> gpg --verify --batch --no-tty -q --logger-fd=1 
--keyserver=hkp://pool.sks-keyservers.net:11371 
/home/vinc17/.cpan/sources/authors/id/C/CA/CAVAC/CHECKSUMS
gpg: Signature made 2023-12-17T16:29:09 CET
gpg:using RSA key 77576125A905F1BA
gpg: Good signature from "PAUSE Batch Signing Key 2024 " 
[unknown]
gpg: aka "PAUSE Batch Signing Key 2023 " 
[unknown]
gpg: aka "PAUSE Batch Signing Key 2003 " 
[unknown]
gpg: aka "PAUSE Batch Signing Key 2005 " 
[unknown]
gpg: aka "PAUSE Batch Signing Key 2007 " 
[unknown]
gpg: aka "PAUSE Batch Signing Key 2009 " 
[unknown]
gpg: aka "PAUSE Batch Signing Key 2015 " 
[unknown]
gpg: aka "PAUSE Batch Signing Key 2017 " 
[unknown]
gpg: aka "PAUSE Batch Signing Key 2019 " 
[unknown]
gpg: aka "PAUSE Batch Signing Key 2021 " 
[unknown]
gpg: aka "PAUSE Batch Signing Key 2022 " 
[unknown]
gpg: aka "PAUSE Batch Signing Key 2011 " 
[unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 2E66 557A B97C 19C7 91AF  8E20 328D A867 450F 89EC
 Subkey fingerprint: D785 7544 389C 919D 8E6D  ABBA 7757 6125 A905 F1BA

but

zira:~> gpg --verify --batch --no-tty -q --logger-fd=1 
--keyserver=hkp://pool.sks-keyservers.net:11371 
/home/vinc17/.cpan/sources/authors/id/C/CA/CAVAC/CHECKSUMS
gpg: Signature made 2023-12-17T16:29:09 CET
gpg:using RSA key 77576125A905F1BA
gpg: Can't check signature: No public key

I can notice a difference between these two machines:

qaa:~> gpg --with-subkey-fingerprint -k 2E66557AB97C19C791AF8E20328DA867450F89EC
pub   dsa1024 2003-02-03 [SC] [expires: 2024-07-01]
  2E66557AB97C19C791AF8E20328DA867450F89EC
uid   [ unknown] PAUSE Batch Signing Key 2024 
uid   [ unknown] PAUSE Batch Signing Key 2023 
uid   [ unknown] PAUSE Batch Signing Key 2003 
uid   [ unknown] PAUSE Batch Signing Key 2005 
uid   [ unknown] PAUSE Batch Signing Key 2007 
uid   [ unknown] PAUSE Batch Signing Key 2009 
uid   [ unknown] PAUSE Batch Signing Key 2015 
uid   [ unknown] PAUSE Batch Signing Key 2017 
uid   [ unknown] PAUSE Batch Signing Key 2019 
uid   [ unknown] PAUSE Batch Signing Key 2021 
uid   [ unknown] PAUSE Batch Signing Key 2022 
uid   [ unknown] PAUSE Batch Signing Key 2011 
sub   elg2048 2023-07-01 [E] [expires: 2024-07-01]
  4CA09107D9A3E6E61960A61C41C01F6387982F09
sub   rsa4096 2023-07-01 [S] [expires: 2024-07-01]
  D7857544389C919D8E6DABBA77576125A905F1BA

zira:~> gpg --with-subkey-fingerprint -k 
2E66557AB97C19C791AF8E20328DA867450F89EC
pub   dsa1024 2003-02-03 [SC] [expired: 2023-07-01]
  2E66557AB97C19C791AF8E20328DA867450F89EC
uid   [ expired] PAUSE Batch Signing Key 2023 
uid   [ expired] PAUSE Batch Signing Key 2003 
uid   [ expired] PAUSE Batch Signing Key 2005 
uid   [ expired] PAUSE Batch Signing Key 2007 
uid   [ expired] PAUSE Batch Signing Key 2009 
uid   [ expired] PAUSE Batch Signing Key 2011 
uid   [ expired] PAUSE Batch Signing Key 2015 
uid   [ expired] PAUSE Batch Signing Key 2017 
uid   [ expired] PAUSE Batch Signing Key 2022 
uid   [ expired] PAUSE Batch Signing Key 2019 
uid   [ expired] PAUSE Batch Signing Key 2021 

i.e. the subkeys are missing. Why?

Note that on zira, doing

  gpg --recv-keys 2E66557AB97C19C791AF8E20328DA867450F89EC

again doesn't change anything.

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



Perl module installation via CPAN and signature error

2024-01-11 Thread Vincent Lefevre
Hi,

I have 2 Debian/unstable machines on the same network, with the
same .cpan/CPAN/MyConfig.pm file.

On one of them, I get no errors:

qaa:~> cpan -i XML::RPC
CPAN: HTTP::Tiny loaded ok (v0.086)
CPAN: Net::SSLeay loaded ok (v1.92)
CPAN: IO::Socket::SSL loaded ok (v2.084)
Fetching with HTTP::Tiny:
https://cpan.org/authors/01mailrc.txt.gz
Reading '/home/vinc17/.cpan/sources/authors/01mailrc.txt.gz'
CPAN: Compress::Zlib loaded ok (v2.204)
DONE
Fetching with HTTP::Tiny:
https://cpan.org/modules/02packages.details.txt.gz
Reading '/home/vinc17/.cpan/sources/modules/02packages.details.txt.gz'
  Database was generated on Thu, 11 Jan 2024 21:54:02 GMT
CPAN: HTTP::Date loaded ok (v6.06)
DONE
Fetching with HTTP::Tiny:
https://cpan.org/modules/03modlist.data.gz
Reading '/home/vinc17/.cpan/sources/modules/03modlist.data.gz'
DONE
Writing /home/vinc17/.cpan/Metadata
Running install for module 'XML::RPC'
Fetching with HTTP::Tiny:
https://cpan.org/authors/id/C/CA/CAVAC/XML-RPC-2.tar.gz
CPAN: Digest::SHA loaded ok (v6.04)
Fetching with HTTP::Tiny:
https://cpan.org/authors/id/C/CA/CAVAC/CHECKSUMS
CPAN: Module::Signature loaded ok (v0.88)
WARNING: This key is not certified with a trusted signature!
Primary key fingerprint: 2E66 557A B97C 19C7 91AF  8E20 328D A867 450F 89EC
Signature for /home/vinc17/.cpan/sources/authors/id/C/CA/CAVAC/CHECKSUMS ok
Checksum for /home/vinc17/.cpan/sources/authors/id/C/CA/CAVAC/XML-RPC-2.tar.gz 
ok
Package came without SIGNATURE

CPAN: YAML loaded ok (v1.31)
[...]
  CAVAC/XML-RPC-2.tar.gz
  /bin/make install  -- OK

But on the other one (an older machine), I get an error:

zira:~> cpan -i XML::RPC
CPAN: HTTP::Tiny loaded ok (v0.086)
CPAN: Net::SSLeay loaded ok (v1.92)
CPAN: IO::Socket::SSL loaded ok (v2.084)
Fetching with HTTP::Tiny:
https://cpan.org/authors/01mailrc.txt.gz
Reading '/home/vinc17/.cpan/sources/authors/01mailrc.txt.gz'
CPAN: Compress::Zlib loaded ok (v2.206)
DONE
Fetching with HTTP::Tiny:
https://cpan.org/modules/02packages.details.txt.gz
Reading '/home/vinc17/.cpan/sources/modules/02packages.details.txt.gz'
  Database was generated on Thu, 11 Jan 2024 21:54:02 GMT
CPAN: HTTP::Date loaded ok (v6.06)
DONE
Fetching with HTTP::Tiny:
https://cpan.org/modules/03modlist.data.gz
Reading '/home/vinc17/.cpan/sources/modules/03modlist.data.gz'
DONE
Writing /home/vinc17/.cpan/Metadata
Running install for module 'XML::RPC'
Fetching with HTTP::Tiny:
https://cpan.org/authors/id/C/CA/CAVAC/XML-RPC-2.tar.gz
CPAN: Digest::SHA loaded ok (v6.04)
Fetching with HTTP::Tiny:
https://cpan.org/authors/id/C/CA/CAVAC/CHECKSUMS
CPAN: Module::Signature loaded ok (v0.88)
gpg: Signature made 2023-12-17T16:29:09 CET
gpg:using RSA key 77576125A905F1BA
gpg: Can't check signature: No public key

Signature for file /home/vinc17/.cpan/sources/authors/id/C/CA/CAVAC/CHECKSUMS 
could not be verified for an unknown reason. Distribution id = 
C/CA/CAVAC/XML-RPC-2.tar.gz
CPAN_USERID  CAVAC (Rene Schickbauer )
CALLED_FOR   XML::RPC
CHECKSUM_STATUS 
CONTAINSMODS XML::RPC
UPLOAD_DATE  2022-03-09
incommandcolor 1
localfile
/home/vinc17/.cpan/sources/authors/id/C/CA/CAVAC/XML-RPC-2.tar.gz
mandatory1
negative_prefs_cache 0
prefsHASH(0x55eef7851f20)
reqtype  c

Module::Signature verification returned value 0E0

The manual says for this case: Cannot verify the
OpenPGP signature, maybe due to the lack of a network connection to
the key server, or if neither gnupg nor Crypt::OpenPGP exists on the
system. You probably want to analyse the situation and if you cannot
fix it you will have to decide whether you want to stop this session
or you want to turn off signature verification. The latter would be
done with the command 'o conf init check_sigs'



Note that every public key given by "gpg --list-public-keys" on qaa
are on zira too.

Where does the problem come from?

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



Re: openssh: missing kex_exchange_identification ssh error messages with 1:9.5p1-2?

2023-12-14 Thread Vincent Lefevre
On 2023-12-14 14:04:08 -0500, Greg Wooledge wrote:
> On Thu, Dec 14, 2023 at 05:14:28PM +0100, Vincent Lefevre wrote:
> > I have the latest version!!! I recall that this is a Debian/unstable
> > machine, which I upgrade regularly. So, everytime I get such an error,
> > I have the latest client.
> 
> Just for the record, saying you have the "latest" version of something
> is unhelpful.  This goes double when you're on a testing or unstable
> system.  We don't know how long ago you updated, or what mirrors you're
> using, or what errors might have occurred the last time you updated,
> or whether you have a locally installed version of "ssh" in your PATH
> before /usr/bin/ssh, or... anything.  Anything at all.
> 
> When asking for help, it's best to give all of the relevant details up
> front.  Start by saying you're on Debian unstable.  Then give the
> installed package version (as printed by "dpkg -l openssh-client")
> and the output of "ssh -V".

As I've said in my message: I've upgraded to openssh-client 1:9.5p1-2.

The versions up to 9.4 were fine, i.e. I got a detailed error message.

> Since this is a problem with ssh, which uses a client/server architecture,
> giving the version of the server's sshd would also help.

openssh-server 1:7.9p1-10+deb10u3

but I don't think this is useful.

> Finally, if you've customized something that's relevant, be sure to
> include that.  For the ssh client, customizations are done in the
> /etc/ssh/ssh_config and ~/.ssh/config files.  Anything you've changed
> or added there would be important to disclose.

At the time of the test:

IdentitiesOnly yes
TCPKeepAlive no
ControlPath /tmp/ssh-%h-%p-%r
SendEnv LANG LC_*
ProxyCommand none
StrictHostKeyChecking yes

(and the last change was "KeepAlive no" → "TCPKeepAlive no"
in June 2022).

> If you've customized anything on the server end (i.e. in
> /etc/ssh/sshd_config) then you should disclose that as well.

Note that I am not the admin of the server. I can see that
MaxStartups was changed to "MaxStartups 20:30:120". But the
last change was done in June.

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



Re: openssh: missing kex_exchange_identification ssh error messages with 1:9.5p1-2?

2023-12-14 Thread Vincent Lefevre
On 2023-12-14 17:03:10 +0100, Klaus Singvogel wrote:
> Vincent Lefevre wrote:
> > Since 2 years (from early 2022 to 2023-11-26), I've got recurrent
> > errors like
> > 
> > kex_exchange_identification: read: Connection reset by peer
> > Connection reset by x.x.x.x port 22
> 
> This sounds most likely that your SSH client (program at your local
> machine) has an outdated SSH implementation. Try to update this
> program first.

I have the latest version!!! I recall that this is a Debian/unstable
machine, which I upgrade regularly. So, everytime I get such an error,
I have the latest client.

Note also that this is an error that occurs randomly.

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



openssh: missing kex_exchange_identification ssh error messages with 1:9.5p1-2?

2023-12-14 Thread Vincent Lefevre
Since 2 years (from early 2022 to 2023-11-26), I've got recurrent
errors like

kex_exchange_identification: read: Connection reset by peer
Connection reset by x.x.x.x port 22

or

kex_exchange_identification: Connection closed by remote host
Connection closed by x.x.x.x port 22

But yesterday, the errors just became

Connection closed by x.x.x.x port 22

though I suspect that this is exactly the same issue.

The sshd server and its config have not changed. Only the client has
changed: I upgraded to openssh-client 1:9.5p1-2 on 2023-11-27 (this
is a Debian/unstable machine).

Is there any explanation of such a change?

Has anyone noticed a similar change (for those who get such errors)?

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



Re: Image handling in mutt

2023-12-11 Thread Vincent Lefevre
On 2023-12-11 09:34:09 -0500, Pocket wrote:
> On 12/11/23 09:04, Vincent Lefevre wrote:
> > On 2023-12-11 08:16:30 -0500, Greg Wooledge wrote:
> > > 2) When *receiving* email, mutt will use the sender's MIME type label
> > > to decide how to deal with the attachment.
> > But the notion of filename extension is even used in this context too.
> > Quoting the Mutt manual:
> > 
> > 
> > nametemplate=
> >This field specifies the format for the file denoted by %s in
> >the command fields. Certain programs will require a certain
> >file extension, for instance, to correctly view a file. For
> >instance, lynx will only interpret a file as text/html if the
> >file ends in .html. So, you would specify lynx as a text/html
> >viewer with a line in the mailcap file like:
> > 
> > text/html; lynx %s; nametemplate=%s.html
> > 
> > 
> > This is due to
> > 
> > > 3) Many other programs besides mutt will also use file extensions to
 
> > > determine how to deal with input files.
> 
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:struct 
> filename {
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:static_assert(offsetof(struct
>  filename, iname) % sizeof(long) == 0);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
> file *file_open_name(struct filename *, int, umode_t);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
> filename *getname_flags(const char __user *, int, int *);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
> filename *getname_uflags(const char __user *, int);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
> filename *getname(const char __user *);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern struct 
> filename *getname_kernel(const char *);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs.h:extern void 
> putname(struct filename *name);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/fs_context.h:  
> struct filename *name;
> 
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_chdir(const char *filename);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_chroot(const char *filename);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_chown(const char *filename, uid_t user, gid_t group, int flags);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_chmod(const char *filename, umode_t mode);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_eaccess(const char *filename);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_stat(const char *filename, struct kstat *stat, int flags);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_mknod(const char *filename, umode_t mode, unsigned int dev);
> /usr/src/linux-headers-6.1.0-rpi7-common-rpi/include/linux/init_syscalls.h:int
> __init init_utimes(char *filename, struct timespec64 *ts);
> 
> I must be blind as I don't see extension anywhere

We're talking about programs (Mutt and others). You're quoting things
from the Linux kernel.

You probably won't see anything about the filename extensions either
in the low-level part of the MS Windows code either.

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



Re: Image handling in mutt

2023-12-11 Thread Vincent Lefevre
On 2023-12-11 15:16:57 +0100, to...@tuxteam.de wrote:
> On Mon, Dec 11, 2023 at 02:58:01PM +0100, Vincent Lefevre wrote:
> > I do not care about the "microsoft world", and I doubt that this is
> > required there at the low level (what would be the equivalent of the
> > Linux kernel) [...]
> 
> This depends: the FAT file system (which still is the lowest common
> denominator) actually reserves 8 chars for the file name and three
> for the --ahem-- extension. The dot isn't encoded explicitly on-disk.

This is unrelated to the OS. The FAT file system may be used also
under Linux (e.g. because this is what some memory sticks have),
and there are the same limitations.

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



Re: Image handling in mutt

2023-12-11 Thread Vincent Lefevre
On 2023-12-11 08:16:30 -0500, Greg Wooledge wrote:
> 2) When *receiving* email, mutt will use the sender's MIME type label
>to decide how to deal with the attachment.

But the notion of filename extension is even used in this context too.
Quoting the Mutt manual:


   nametemplate=
  This field specifies the format for the file denoted by %s in
  the command fields. Certain programs will require a certain
  file extension, for instance, to correctly view a file. For
  instance, lynx will only interpret a file as text/html if the
  file ends in .html. So, you would specify lynx as a text/html
  viewer with a line in the mailcap file like:

text/html; lynx %s; nametemplate=%s.html


This is due to

> 3) Many other programs besides mutt will also use file extensions to
>determine how to deal with input files.

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



Re: Image handling in mutt

2023-12-11 Thread Vincent Lefevre
On 2023-12-11 07:32:30 -0500, Pocket wrote:
> 
> On 12/11/23 07:12, Vincent Lefevre wrote:
> > On 2023-12-10 15:51:02 -0500, Pocket wrote:
> > > On Dec 10, 2023, at 3:05 PM, David Wright  
> > > wrote:
> > > > ¹ Re the argument raging in this thread about "extension", the
> > > >   term is clearly appropriate, as a glance at /etc/mime.types
> > > >   demonstrates. The literature is full of the term.
> > > > 
> > > >   I wouldn't want to use "suffix" myself, as it's too general:
> > > >   anything stuck on the end is a suffix, but not necessarily
> > > >   a filename extension. Suffixes are used for other purposes.
> > > Suffix is the correct term.
> > A filename extension is a suffix, but a suffix (e.g. as in POSIX)
> > is not necessarily a filename extension.
> 
> Not in the microsoft world, it is REQUIRED and that is what the OS
> needs to tell what kind of file it is dealing with.  Unix/Linux has
> no resrictions.

I do not care about the "microsoft world", and I doubt that this is
required there at the low level (what would be the equivalent of the
Linux kernel). The filename extension matters at a high level, e.g.
to select which application should be run, but similar choices are
also done under Linux, where this is implemented by utilities,
libraries, or applications themselves. There are other methods under
Linux, such as content sniffing (the method used by "file"), which
has advantages, but also drawbacks (the file needs to be readable,
and mainly for the various text formats, sniffing is unreliable;
good luck with the diff and json formats, for instance).

And even when the application is known, e.g. when the file type is
given by a MIME type, a filename extension may be necessary. See
the various "nametemplate" fields in /etc/mailcap, for instance.

> > For instance:
> > 
> > $ basename foobar bar
> > foo
> > 
> > Here, "bar" is a suffix, but it does not have the form of a
> > filename extension.
> 
> No bar is part of the filespec

No, read the POSIX standard:

  SYNOPSIS
basename string [suffix]

This is explicitly called suffix.

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



Re: Image handling in mutt

2023-12-11 Thread Vincent Lefevre
On 2023-12-10 15:51:02 -0500, Pocket wrote:
> On Dec 10, 2023, at 3:05 PM, David Wright  wrote:
> > ¹ Re the argument raging in this thread about "extension", the
> >  term is clearly appropriate, as a glance at /etc/mime.types
> >  demonstrates. The literature is full of the term.
> > 
> >  I wouldn't want to use "suffix" myself, as it's too general:
> >  anything stuck on the end is a suffix, but not necessarily
> >  a filename extension. Suffixes are used for other purposes.
> 
> Suffix is the correct term. 

A filename extension is a suffix, but a suffix (e.g. as in POSIX)
is not necessarily a filename extension.

For instance:

$ basename foobar bar
foo

Here, "bar" is a suffix, but it does not have the form of a
filename extension.

So the notion of "filename extension" is more specific.

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



Re: Image handling in mutt

2023-12-11 Thread Vincent Lefevre
On 2023-12-08 17:06:15 -0500, Pocket wrote:
> On 12/8/23 16:53, David wrote:
> > Hi, the filename extension is usually irrelevant on Linux, because
> > Linux tools typically
> > use the standard 'file' command to inspect the content of the
> > fileinstead of relying on
> > the filename to indicate content.
> 
> In Unix and Linux there isn't a file extension, that is a microsoft
> invention.

More and more applications under Linux, like atril and lynx, care
about the file extension.

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



Re: systemd-journald log location

2023-12-04 Thread Vincent Lefevre
On 2023-12-04 13:33:33 +0100, Vincent Lefevre wrote:
> On 2023-12-04 11:46:23 +, Adam Weremczuk wrote:
> > Is it a good idea to move it from /run/log/journal to e.g. /var/journal-log?
> > 
> > I can't find a suitable option in /etc/systemd/journald.conf

See the journald.conf(5) man page. :-)

> > I recently increased SystemMaxUse and RuntimeMaxUse which quickly filled up
> > all space.
> 
> On my Debian machines, /run/log/journal is empty, and everything
> goes into /var/log/journal. I haven't changed the location.

This may be because I use Storage=persistent.

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



Re: systemd-journald log location

2023-12-04 Thread Vincent Lefevre
On 2023-12-04 11:46:23 +, Adam Weremczuk wrote:
> Is it a good idea to move it from /run/log/journal to e.g. /var/journal-log?
> 
> I can't find a suitable option in /etc/systemd/journald.conf
> 
> I recently increased SystemMaxUse and RuntimeMaxUse which quickly filled up
> all space.

On my Debian machines, /run/log/journal is empty, and everything
goes into /var/log/journal. I haven't changed the location.

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



Re: Why is bullseye-backports recommended on bookworm?

2023-11-20 Thread Vincent Lefevre
On 2023-11-18 23:43:34 -0600, David Wright wrote:
> On Sat 18 Nov 2023 at 23:33:59 (+0100), Vincent Lefevre wrote:
> > On 2023-11-18 09:18:56 -0500, Greg Wooledge wrote:
> > > The "6.1.0-" part comes from the upstream release series.  All the
> > > kernel images containing "6.1.0-" in this section should come from the
> > > same upstream series (6.1.x), and should have basically the same feature
> > > set, with no major changes.
> > 
> > BTW, since this is for 6.1.x, I've always wondered why Debian uses the
> > "6.1.0-" prefix instead of "6.1-". The "6.1.0" is a bit confusing.
> 
> So as not to confuse and break software that's hardwired to expect
> three numbers in any linux kernel version.

But these numbers in the package name are not the correct ones.
If the 3 numbers matter, this could yield a potential breakage too.

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



Re: Why is bullseye-backports recommended on bookworm?

2023-11-18 Thread Vincent Lefevre
On 2023-11-18 09:18:56 -0500, Greg Wooledge wrote:
> The "6.1.0-" part comes from the upstream release series.  All the
> kernel images containing "6.1.0-" in this section should come from the
> same upstream series (6.1.x), and should have basically the same feature
> set, with no major changes.

BTW, since this is for 6.1.x, I've always wondered why Debian uses the
"6.1.0-" prefix instead of "6.1-". The "6.1.0" is a bit confusing.

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



Re: Why is bullseye-backports recommended on bookworm?

2023-11-18 Thread Vincent Lefevre
On 2023-11-18 00:20:25 -0600, David Wright wrote:
> On Fri 17 Nov 2023 at 13:30:32 (+0100), Vincent Lefevre wrote:
> > On 2023-11-16 14:04:29 -0600, David Wright wrote:
> > > On Thu 16 Nov 2023 at 13:02:28 (+0100), Vincent Lefevre wrote:
> > > > In any case, if a package is renamed (which particularly applies to
> > > > unstable, I don't know about backports), I would expect reportbug
> > > > to also consider the new name for a newer version of the package.
> > > > In short, its search for newer versions should be based on the
> > > > source package rather than the binary package.
> > > 
> > > As I said above, I don't know whether they apply any fuzziness to the
> > > version numbers in view of the multiplicity of linux-image versions
> > > (and sources). As far as a 'rename' is concerned, I don't think that
> > > linux-image has changed name since it was kernel-image in sarge.
> > 
> > The name of the binary package frequently changes. This is why Tixy
> > said "Because it's a different package?".
> 
> Tixy said that because the bookworm-backports packages are
> called "linux-image-6.4.0…" which are all from a different kernel
> source.

He didn't explain. So I thought that he meant the usual rename of
the binary packages from the same kernel source.

> I would call linux-image-x.y.z-386 → linux-image-x.y.z-486
> and suchlike a name change.
> 
> > > > Note that for the Packages files, reportbug just uses the files from
> > > > the /var/lib/apt/lists directory, but I don't have anything matching
> > > > *bullseye* there.
> > > 
> > > I didn't know that, and at least one post in this thread suggests
> > > otherwise.
> > 
> > I'm wondering why you think that.
> 
> Only because Greg wrote ‘What it said was "Hey, I looked on the
> internets and I saw this other kernel that might be newer than the
> one you're running, so maybe you wanna check this other kernel first
> and see if it's still got the same bug, before you report this."’

This does not necessarily mean that it fetches Packages files there.
There are various means to get package information on the web.

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



Re: touchpad buttons sometimes stop working for several seconds

2023-11-17 Thread Vincent Lefevre
On 2023-11-16 23:53:51 +0700, Max Nikulin wrote:
> On 16/11/2023 20:59, Vincent Lefevre wrote:
> > The question is what suppresses software buttons. If this is libinput
> > that suppresses them (just like it suppressed pointer moves when
> > typing, while pointer moves are still reported by the kernel), then
> > this is unrelated to my issue.
> 
> I am unsure if kernel is involved at all. It may be device firmware (have
> you checked for firmware updates?),

Yes, firmware is up-to-date (/etc/update-motd.d/85-fwupd signals
when new versions are available).

> it may be libinput as the device driver. Perhaps libinput may send
> some commands to touchpad to suppress generation of events for some
> interval of time.

I would have expected something in the log in such a case.

In the next few days, I'll try to look at issues more closely with
tools from libinput-tools.

> > BTW, I often accidentally touch the bottom of the touchpad with the
> > palm of my hand
> 
> I am unsure if you have read relevant parts of libinput docs
> https://wayland.freedesktop.org/libinput/doc/latest/palm-detection.html

Just a note to say that palm detection is either disabled or it does
not work (I'll try to see whether MT_TOOL_PALM can be generated).

> I hope I solved my variant of "buttons does not work for some period of
> time" by dropping a snippet into xorg.conf.d that enables tap-to-click.

I don't like tap-to-click (I don't want accidental clicks).

> For me it is more convenient than clicks in the bottom area. My
> observation is that hardware click works more reliable if I raise
> the finger for a moment after moving cursor. However in my case
> period of clickbuttons inactivity is usually just a few seconds
> (unless prolonged by repeating clicks). Sometimes clicks are ignored
> when a finger is at the bottom touchpad edge.

When I tried, I tested clicks on various parts of the touchpad.
But I would say that even if clicks are to be ignored, an event
is normally generated by the kernel. I could see that the kernel
generates a BTN_LEFT event even when it doesn't know where the
click has been done; in such a case, I get no clicks at the X11
level (obviously).

BTW, what model of touchpad do you have?

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



Re: Why is bullseye-backports recommended on bookworm?

2023-11-17 Thread Vincent Lefevre
On 2023-11-16 14:04:29 -0600, David Wright wrote:
> On Thu 16 Nov 2023 at 13:02:28 (+0100), Vincent Lefevre wrote:
> > In any case, if a package is renamed (which particularly applies to
> > unstable, I don't know about backports), I would expect reportbug
> > to also consider the new name for a newer version of the package.
> > In short, its search for newer versions should be based on the
> > source package rather than the binary package.
> 
> As I said above, I don't know whether they apply any fuzziness to the
> version numbers in view of the multiplicity of linux-image versions
> (and sources). As far as a 'rename' is concerned, I don't think that
> linux-image has changed name since it was kernel-image in sarge.

The name of the binary package frequently changes. This is why Tixy
said "Because it's a different package?".

> > Note that for the Packages files, reportbug just uses the files from
> > the /var/lib/apt/lists directory, but I don't have anything matching
> > *bullseye* there.
> 
> I didn't know that, and at least one post in this thread suggests
> otherwise.

I'm wondering why you think that. Earlier in this thread:

--------
On 2023-11-14 23:54:31 +0700, Max Nikulin wrote:
> On 14/11/2023 19:00, Vincent Lefevre wrote:
> > To my surprise, reportbug asks me to use bullseye-backports
> > (= oldstable-backports) on my bookworm (= stable) machine:
>
> Might it happen that you have bullseye-backports in apt sources.list?

No, and this is actually the complaint of reportbug, which wants
me to add it.


In my bug report (bug 1055931), Nis Martensen found where
6.1.55+1~bpo11+1 came from. As a summary from

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055931#34


On 2023-11-16 17:31:13 +0100, Nis Martensen wrote:
> I can find "6.1.55+1~bpo11+1" in https://ftp-master.debian.org/new.822
> so it must come from there.

Thanks. I had first looked at

  https://ftp-master.debian.org/new.html

(as output by reportbug), and it doesn't appear on this page
(I searched for both "linux" and "6.1.55"). Note that clicking
on "Click to toggle all/binary-NEW packages" does not make this
kernel appear either.

FYI, I later looked at https://ftp-master.debian.org/new.822 too
(as I could see it in the strace output), but only searched for
linux-image there, explaining that I didn't find it either (it
actually appears as linux-signed-amd64).

At the bottom of the new.html page:
"You can also look at the RFC822 version."

But why are the contents different? (linux-signed-amd64 appears
only in the RFC822 version.)


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



Re: touchpad buttons sometimes stop working for several seconds

2023-11-16 Thread Vincent Lefevre
On 2023-11-08 12:06:10 +0700, Max Nikulin wrote:
> On 04/11/2023 15:59, Vincent Lefevre wrote:
> > On 2023-11-03 09:48:16 +0700, Max Nikulin wrote:
> > >  From the "See ... for details" page
> > > 
> > > > Note
> > > > 
> > > > This warning is ratelimited and will stop appearing after a few times, 
> > > > even if the touchpad jumps continue.
> [...]
> > https://wayland.freedesktop.org/libinput/doc/1.22.0/touchpad-jumping-cursors.html
> 
> I think 
> <https://wayland.freedesktop.org/libinput/doc/latest/touchpad-jumping-cursors.html>
> has a bit less chance to became outdated.
> 
> > Unfortunately, this doesn't allow me to see whether this could be
> > related.
> 
> My point is that events detected as jumps may suppress software buttons.
> Since not all such events are logged, it may be not so easy to find
> correlation. Perhaps there are debugging options to enable logging of all
> jumps.

The question is what suppresses software buttons. If this is libinput
that suppresses them (just like it suppressed pointer moves when
typing, while pointer moves are still reported by the kernel), then
this is unrelated to my issue.

> Debugging an issue (that perhaps is unrelated to input devices) I have
> realized that there is an older driver xserver-xorg-input-synaptics that you
> might try instead of libinput. Several years ago I installed this package to
> make tap to click working, but likely it is not necessary any more in my
> case. I have to "upload" an update to my memory that current default driver
> for touchpad is xserver-xorg-input-libinput.

I could try, but I fear that this will not change anything as this
is the kernel that doesn't report the clicks.

BTW, I often accidentally touch the bottom of the touchpad with the
palm of my hand (this may be because the touchpad is very large),
yielding multitouch (rather annoying). It might be what causes the
issue under particular circumstances. I'm wondering whether something
can be done about that (note: if I put something thick over it, this
disables the accidental touches, but this prevents the buttons from
working, as a consequence).

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



Re: Why is bullseye-backports recommended on bookworm?

2023-11-16 Thread Vincent Lefevre
On 2023-11-15 13:54:51 -0600, David Wright wrote:
> On Wed 15 Nov 2023 at 20:01:20 (+0100), Vincent Lefevre wrote:
> > On 2023-11-15 18:06:45 +, Tixy wrote:
> > > On Wed, 2023-11-15 at 18:15 +0100, Vincent Lefevre wrote:
[...]
> > > > But the bookworm-backports kernel is even newer.
> > > > So why not this one?
> > > 
> > > Because it's a different package?
[...]
> I just downloaded 
> /debian/dists/bullseye-backports/main/binary-amd64/Packages.xz
> (2023-11-02 13:59 395K), and it contains:
[...]
> so there do appear to be 6.1.55-1~bpo11+1 candidates, like
> linux-image-6.1.0-0.deb11.13-amd64-unsigned.

Note that these 6.1.55-1~bpo11+1 candidates do not match my binary
package. So, if these were the reason of the output, then the
answer to "Because it's a different package?" above would be "No".

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



Re: Why is bullseye-backports recommended on bookworm?

2023-11-16 Thread Vincent Lefevre
On 2023-11-15 13:54:51 -0600, David Wright wrote:
> On Wed 15 Nov 2023 at 20:01:20 (+0100), Vincent Lefevre wrote:
> > On 2023-11-15 18:06:45 +, Tixy wrote:
> > > On Wed, 2023-11-15 at 18:15 +0100, Vincent Lefevre wrote:
> > > > On 2023-11-15 16:39:15 -, Curt wrote:
> > > > > On 2023-11-14, Vincent Lefevre  wrote:
> > > > > > 
> > > > > > The base number is the same, but I would have thought that this 
> > > > > > other
> > > > > > kernel might have additional patches.
> > > > > > 
> > > > > > > That's why I suggested ignoring the message.
> > > > > > 
> > > > > > Then why does reportbug mention the bullseye-backports kernel?
> > > > > 
> > > > > Because it kind of looks newer if you're a not very bright software
> > > > > construct, he opined.
> > > > 
> > > > But the bookworm-backports kernel is even newer.
> > > > So why not this one?
> > > 
> > > Because it's a different package?
> > 
> > There is no guarantee that a package with the same name in a
> > different distribution has the same meaning (because packages
> > get renamed...). So I would say that this is not a good reason.
> 
> Well, it would seem strange to provide a backport for a package
> and call it by a different name. But with kernels, there's always
> the problem of a myriad of slightly different versions, so a
> fuzzy name match might be appropriate.

In any case, if a package is renamed (which particularly applies to
unstable, I don't know about backports), I would expect reportbug
to also consider the new name for a newer version of the package.
In short, its search for newer versions should be based on the
source package rather than the binary package.

> > But I'm still wondering where reportbug gets this particular
> > version 6.1.55+1~bpo11+1, as it is not in bullseye-backports.
> 
> I just downloaded 
> /debian/dists/bullseye-backports/main/binary-amd64/Packages.xz
> (2023-11-02 13:59 395K), and it contains:
[...]

Note that for the Packages files, reportbug just uses the files from
the /var/lib/apt/lists directory, but I don't have anything matching
*bullseye* there.

> so there do appear to be 6.1.55-1~bpo11+1 candidates, like
> linux-image-6.1.0-0.deb11.13-amd64-unsigned.

Note the difference between 6.1.55-1~bpo11+1 and 6.1.55+1~bpo11+1
(a "-" has been replaced by "+").

> I don't know how reportbug operates; nor do I know how to
> drive madison—perhaps it's seeing the third from last line.
> But I'm not sure why you're making such an issue out of
> reportbug's harmless suggestion to check whether you're
> up-to-date.

/usr/lib/python3/dist-packages/reportbug/checkversions.py uses

RMADISON_URL = 'https://qa.debian.org/madison.php?package=%s&text=on'
NEWQUEUE_URL = 'http://ftp-master.debian.org/new.822'

Now, for the RMADISON_URL URL:

url = RMADISON_URL % package
if dists:
url += '&s=' + ','.join(dists)
# select only those lines that refers to source pkg
# or to binary packages available on the current arch
url += '&a=source,all,' + arch
try:
page = open_url(url, http_proxy, timeout)

If package is the binary package, I don't get the expected
version.

If I use "linux" (for the source package), I get in particular

 linux | 6.1.55-1~bpo11+1  | bullseye-backports | source

which looks like what is output, but since the 4 field is "source",
it is ignored:

if a == 'source':
continue

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



Re: Why is bullseye-backports recommended on bookworm?

2023-11-15 Thread Vincent Lefevre
On 2023-11-15 18:06:45 +, Tixy wrote:
> On Wed, 2023-11-15 at 18:15 +0100, Vincent Lefevre wrote:
> > On 2023-11-15 16:39:15 -, Curt wrote:
> > > On 2023-11-14, Vincent Lefevre  wrote:
> > > > 
> > > > The base number is the same, but I would have thought that this other
> > > > kernel might have additional patches.
> > > > 
> > > > > That's why I suggested ignoring the message.
> > > > 
> > > > Then why does reportbug mention the bullseye-backports kernel?
> > > 
> > > Because it kind of looks newer if you're a not very bright software
> > > construct, he opined.
> > 
> > But the bookworm-backports kernel is even newer.
> > So why not this one?
> 
> Because it's a different package?

There is no guarantee that a package with the same name in a
different distribution has the same meaning (because packages
get renamed...). So I would say that this is not a good reason.
But I'm still wondering where reportbug gets this particular
version 6.1.55+1~bpo11+1, as it is not in bullseye-backports.

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



Re: Why is bullseye-backports recommended on bookworm?

2023-11-15 Thread Vincent Lefevre
On 2023-11-15 16:39:15 -, Curt wrote:
> On 2023-11-14, Vincent Lefevre  wrote:
> >
> > The base number is the same, but I would have thought that this other
> > kernel might have additional patches.
> >
> >> That's why I suggested ignoring the message.
> >
> > Then why does reportbug mention the bullseye-backports kernel?
> 
> Because it kind of looks newer if you're a not very bright software
> construct, he opined.

But the bookworm-backports kernel is even newer.
So why not this one?

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



Re: Why is bullseye-backports recommended on bookworm?

2023-11-15 Thread Vincent Lefevre
On 2023-11-15 08:50:50 +0100, didier gaumet wrote:
> I don't know why particularly a Bullseye-backports kernel is promoted here
> in a mixed stable/unstable context but perhaps (I have not tested it) you
> could set check-available to 0 in /etc/reportbug.conf (1) to avoid to be
> proposed a newer kernel at all.
> 
> (1) https://manpages.debian.org/bookworm/reportbug/reportbug.conf.5.en.html

This would apply to *all* packages. I certainly don't want to do that.

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



Re: Why is bullseye-backports recommended on bookworm?

2023-11-15 Thread Vincent Lefevre
On 2023-11-15 10:15:35 +0700, Max Nikulin wrote:
> On 15/11/2023 05:01, Vincent Lefevre wrote:
> > > On Tue, Nov 14, 2023 at 10:21:13PM +0100, Vincent Lefevre wrote:
> > > > # $ wget -qO- 
> > > > 'https://qa.debian.org/madison.php?package=emacs&text=on&s=oldstable,stable,testing,unstable,experimental&a=source,all,x86_64'
> 
> The same request without s=... returns versions for all dists and it is
> valid way to call get_newqueue_available. I agree that oldstable-backports
> is confusing, but perhaps it is better to leave decision to common sense of
> users. Too strict filtering might have negative effect in corner cases.

https://qa.debian.org/madison.php?package=linux-image-6.1.0-13-amd64&text=on&a=source,all,x86_64
just gives

 linux-image-6.1.0-13-amd64 | 6.1.55-1 | bookworm | amd64

And if you mean the request

  
https://qa.debian.org/madison.php?package=linux-image-amd64&text=on&a=source,all,x86_64

then I get

 linux-image-amd64 | 3.16+63+deb8u2  | jessie | amd64, i386
 linux-image-amd64 | 3.16+63+deb8u7  | jessie-security| amd64, i386
 linux-image-amd64 | 4.9+80+deb9u11  | stretch| amd64
 linux-image-amd64 | 4.9+80+deb9u17  | stretch-security   | amd64
 linux-image-amd64 | 4.19+105+deb10u4~bpo9+1 | stretch-backports  | amd64
 linux-image-amd64 | 4.19+105+deb10u16   | buster | amd64
 linux-image-amd64 | 4.19+105+deb10u20   | buster-security| amd64
 linux-image-amd64 | 5.10.127-2~bpo10+1  | buster-backports   | amd64
 linux-image-amd64 | 5.10.191-1  | bullseye-security  | amd64
 linux-image-amd64 | 5.10.197-1  | bullseye   | amd64
 linux-image-amd64 | 6.1.38-4~bpo11+1| bullseye-backports | amd64
 linux-image-amd64 | 6.1.52-1| bookworm-security  | amd64
 linux-image-amd64 | 6.1.55-1| bookworm   | amd64
 linux-image-amd64 | 6.5.3-1~bpo12+1 | bookworm-backports | amd64
 linux-image-amd64 | 6.5.10-1| trixie | amd64
 linux-image-amd64 | 6.5.10-1| sid| amd64

But "reportbug linux-image-6.1.0-13-amd64" still says

The following newer release(s) are available in the Debian archive:
  bullseye-backports (backports-policy): 6.1.55+1~bpo11+1

This doesn't match bullseye-backports in the above list.

In any case, it would have been *much* better to give the
bookworm-backports one.

> > Yes, because the plan is to upgrade the machine to unstable.
> > But I'm trying to solve the touchpad issue first.

Since the bookworm-backports kernel is similar to unstable, perhaps
I should fully upgrade the machine to unstable, and see. In any case,
if the issue still occurs, it would not be specific to unstable.

[Off-topic for this thread...]

> I mostly use mouse, but I have realized that what you described may be
> similar to what I have seen as well. It might be intended behavior:
> 
> https://wayland.freedesktop.org/libinput/doc/latest/clickpad-softbuttons.html#id5
> > Left: moving a finger into the right button area does not trigger a 
> > right-button click.
> 
> After moving cursor, position of finger is likely determined by desired
> cursor position that may be inside the area of an arbitrary clickbutton. On
> the other hand it is too aggressive protection against clicking a wrong
> button.

When the issue occurs, the kernel does not report any click, whatever
the position of the finger. And this can last several minutes. I don't
see any reason and any relation with the libinput behavior.

Moreover, it is said "libinput ignores such button clicks, this
behavior is intentional". So it is libinput that ignores button
clicks. In my case, it is the kernel that does not generate click
events (as seen with evtest).

> Have you tried tools specific to libinput instead of xinput?

I don't use xinput. But what needs to be fixed is on the kernel 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)



Re: Why is bullseye-backports recommended on bookworm?

2023-11-14 Thread Vincent Lefevre
On 2023-11-14 16:34:18 -0500, Greg Wooledge wrote:
> On Tue, Nov 14, 2023 at 10:21:13PM +0100, Vincent Lefevre wrote:
> > On 2023-11-14 23:54:31 +0700, Max Nikulin wrote:
> > > On 14/11/2023 19:00, Vincent Lefevre wrote:
> > > > To my surprise, reportbug asks me to use bullseye-backports
> > > > (= oldstable-backports) on my bookworm (= stable) machine:
> > > 
> > > Might it happen that you have bullseye-backports in apt sources.list?
> > 
> > No, and this is actually the complaint of reportbug, which wants
> > me to add it.
> 
> That is NOT what it said, at all.
> 
> What it said was "Hey, I looked on the internets and I saw this other
> kernel that might be newer than the one you're running, so maybe you
> wanna check this other kernel first and see if it's still got the same
> bug, before you report this."
> 
> But it's NOT actually newer than yours.  It's the same as yours.  It just
> has a bigger, fancier version string because it's a backport.  So it
> kinda looks newer if you are a not very bright software construct.

The base number is the same, but I would have thought that this other
kernel might have additional patches.

> That's why I suggested ignoring the message.

Then why does reportbug mention the bullseye-backports kernel?

> > > apt policy linux-image-amd64
> > 
> > linux-image-amd64:
> >   Installed: 6.1.55-1
> >   Candidate: 6.1.55-1
> >   Version table:
> >  6.5.10-1 500
> > 500 https://ftp.debian.org/debian testing/main amd64 Packages
> > 500 https://ftp.debian.org/debian unstable/main amd64 Packages
> >  *** 6.1.55-1 900
> > 900 https://ftp.debian.org/debian stable/main amd64 Packages
> > 100 /var/lib/dpkg/status
> >  6.1.52-1 900
> > 900 https://security.debian.org/debian-security 
> > stable-security/main amd64 Packages
> 
> You are not running a "bookworm (= stable)" system.  You're running
> unstable.  This doesn't change my analysis, but it's something you should
> be aware of.

Yes, because the plan is to upgrade the machine to unstable.
But I'm trying to solve the touchpad issue first.

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



Re: Why is bullseye-backports recommended on bookworm?

2023-11-14 Thread Vincent Lefevre
On 2023-11-14 23:54:31 +0700, Max Nikulin wrote:
> On 14/11/2023 19:00, Vincent Lefevre wrote:
> > To my surprise, reportbug asks me to use bullseye-backports
> > (= oldstable-backports) on my bookworm (= stable) machine:
> 
> Might it happen that you have bullseye-backports in apt sources.list?

No, and this is actually the complaint of reportbug, which wants
me to add it.

> apt policy

Package files:
 100 /var/lib/dpkg/status
 release a=now
 500 file:/var/local/apt ./ Packages
 release c=
 900 http://debug.mirrors.debian.org/debian-debug proposed-updates-debug/main 
amd64 Packages
 release 
v=12-updates,o=Debian,a=proposed-updates-debug,n=bookworm-proposed-updates-debug,l=Debian
 debug,c=main,b=amd64
 origin debug.mirrors.debian.org
 900 http://debug.mirrors.debian.org/debian-debug stable-debug/main amd64 
Packages
 release v=12.2,o=Debian,a=stable-debug,n=bookworm-debug,l=Debian 
debug,c=main,b=amd64
 origin debug.mirrors.debian.org
 500 http://debug.mirrors.debian.org/debian-debug unstable-debug/main amd64 
Packages
 release o=Debian,a=unstable-debug,n=sid-debug,l=Debian debug,c=main,b=amd64
 origin debug.mirrors.debian.org
   1 https://ftp.debian.org/debian experimental/main amd64 Packages
 release o=Debian,a=experimental,n=rc-buggy,l=Debian,c=main,b=amd64
 origin ftp.debian.org
 500 https://ftp.debian.org/debian unstable/non-free-firmware amd64 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=non-free-firmware,b=amd64
 origin ftp.debian.org
 500 https://ftp.debian.org/debian unstable/non-free amd64 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=non-free,b=amd64
 origin ftp.debian.org
 500 https://ftp.debian.org/debian unstable/contrib amd64 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=contrib,b=amd64
 origin ftp.debian.org
 500 https://ftp.debian.org/debian unstable/main amd64 Packages
 release o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64
 origin ftp.debian.org
 500 https://ftp.debian.org/debian testing/non-free-firmware amd64 Packages
 release o=Debian,a=testing,n=trixie,l=Debian,c=non-free-firmware,b=amd64
 origin ftp.debian.org
 500 https://ftp.debian.org/debian testing/non-free amd64 Packages
 release o=Debian,a=testing,n=trixie,l=Debian,c=non-free,b=amd64
 origin ftp.debian.org
 500 https://ftp.debian.org/debian testing/contrib amd64 Packages
 release o=Debian,a=testing,n=trixie,l=Debian,c=contrib,b=amd64
 origin ftp.debian.org
 500 https://ftp.debian.org/debian testing/main amd64 Packages
 release o=Debian,a=testing,n=trixie,l=Debian,c=main,b=amd64
 origin ftp.debian.org
 900 https://ftp.debian.org/debian stable-updates/main amd64 Packages
 release 
v=12-updates,o=Debian,a=stable-updates,n=bookworm-updates,l=Debian,c=main,b=amd64
 origin ftp.debian.org
 900 https://security.debian.org/debian-security 
stable-security/non-free-firmware amd64 Packages
 release 
v=12,o=Debian,a=stable-security,n=bookworm-security,l=Debian-Security,c=non-free-firmware,b=amd64
 origin security.debian.org
 900 https://security.debian.org/debian-security stable-security/contrib amd64 
Packages
 release 
v=12,o=Debian,a=stable-security,n=bookworm-security,l=Debian-Security,c=contrib,b=amd64
 origin security.debian.org
 900 https://security.debian.org/debian-security stable-security/main amd64 
Packages
 release 
v=12,o=Debian,a=stable-security,n=bookworm-security,l=Debian-Security,c=main,b=amd64
 origin security.debian.org
 900 https://ftp.debian.org/debian stable/non-free-firmware amd64 Packages
 release 
v=12.2,o=Debian,a=stable,n=bookworm,l=Debian,c=non-free-firmware,b=amd64
 origin ftp.debian.org
 900 https://ftp.debian.org/debian stable/non-free amd64 Packages
 release v=12.2,o=Debian,a=stable,n=bookworm,l=Debian,c=non-free,b=amd64
 origin ftp.debian.org
 900 https://ftp.debian.org/debian stable/contrib amd64 Packages
 release v=12.2,o=Debian,a=stable,n=bookworm,l=Debian,c=contrib,b=amd64
 origin ftp.debian.org
 900 https://ftp.debian.org/debian stable/main amd64 Packages
 release v=12.2,o=Debian,a=stable,n=bookworm,l=Debian,c=main,b=amd64
 origin ftp.debian.org
Pinned packages:

> apt policy linux-image-amd64

linux-image-amd64:
  Installed: 6.1.55-1
  Candidate: 6.1.55-1
  Version table:
 6.5.10-1 500
500 https://ftp.debian.org/debian testing/main amd64 Packages
500 https://ftp.debian.org/debian unstable/main amd64 Packages
 *** 6.1.55-1 900
900 https://ftp.debian.org/debian stable/main amd64 Packages
100 /var/lib/dpkg/status
 6.1.52-1 900
900 https://security.debian.org/debian-security stable-security/main 
amd64 Packages

No traces of bullseye in either output.

Note that /usr/lib/python3/dist-packages/reportbug/debbugs.py has
references to oldstable, and oldstable-backports in particular:

oldstable = utils.SUITE2CODENAME[&#

Why is bullseye-backports recommended on bookworm?

2023-11-14 Thread Vincent Lefevre
To my surprise, reportbug asks me to use bullseye-backports
(= oldstable-backports) on my bookworm (= stable) machine:

Your version (6.1.55-1) of linux-image-6.1.0-13-amd64 appears to be out of date.
The following newer release(s) are available in the Debian archive:
  bullseye-backports (backports-policy): 6.1.55+1~bpo11+1
Please try to verify if the bug you are about to report is already addressed by 
these releases.  Do you still want to file a report [y|N|q|?]? 

Why?

Shouldn't a more recent kernel be available in bookworm-backports
(= stable-backports)?

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



Re: Request advice on Optimal Combo-usage of Gmail and Mailman, as mentioned in Msg-Id. "2023/11/msg00443"

2023-11-13 Thread Vincent Lefevre
On 2023-11-13 10:57:34 -0300, Eduardo M KALINOWSKI wrote:
> And those are getting rare, I can't find a nice MUA for Android with
> proper threading.

Not sure if that counts, but Mutt in Termux?

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



Re: upgrade to bookworm broke ssh x11 forwarding

2023-11-13 Thread Vincent Lefevre
On 2023-11-10 15:32:53 +, fxkl4...@protonmail.com wrote:
> On Fri, 10 Nov 2023, Vincent Lefevre wrote:
> 
> > On 2023-11-10 10:57:21 +0100, Michael wrote:
> >> On Thursday, 9 November 2023 19:08:25 CET, Greg Wooledge wrote:
> >>> No, this is not a normal phenomenon for bookworm upgrades.  I've never
> >>> heard of it happening to anyone before.
> >>
> >> i disagree. i had the same problem b/c i also had dropbear installed.
> >
> > It would be interesting to know why dropbear got installed
> 
> at sometime in the distance past i thought it would be handy
> my initial ramdisk is set up so i can remotely unlock the filesystems

This is what I've done for my old laptop, but the dropbear package
is *not* needed for that! You just need the dropbear-initramfs
package (dropbear-bin will be installed as a consequence as a
dependency, but not the dropbear package, which contains the
startup scripts). If you install the dropbear package, i.e. the
startup scripts, this means that you want dropbear as you're
main sshd daemon rather than the one from OpenSSH.

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



Re: upgrade to bookworm broke ssh x11 forwarding

2023-11-10 Thread Vincent Lefevre
On 2023-11-10 10:57:21 +0100, Michael wrote:
> On Thursday, 9 November 2023 19:08:25 CET, Greg Wooledge wrote:
> > No, this is not a normal phenomenon for bookworm upgrades.  I've never
> > heard of it happening to anyone before.
> 
> i disagree. i had the same problem b/c i also had dropbear installed.

It would be interesting to know why dropbear got installed (if
openssh-server was already installed, this is rather surprising),
e.g. with "aptitude why dropbear".

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



Re: touchpad buttons sometimes stop working for several seconds

2023-11-04 Thread Vincent Lefevre
On 2023-11-03 09:48:16 +0700, Max Nikulin wrote:
> On 03/11/2023 01:55, Vincent Lefevre wrote:
> > > > (EE) event14 - VEN_04F3:00 04F3:311C Touchpad: kernel bug: Touch jump 
> > > > detected and discarded.
> > > > See 
> > > > https://wayland.freedesktop.org/libinput/doc/1.22.1/touchpad-jumping-cursors.html
> > > >  for details
> > 
> > I can actually see 6 messages like that in /var/log/Xorg.0.log,
> > while my issue occurs much more often. So I think that this is
> > unrelated.
> 
> From the "See ... for details" page
> 
> > Note
> > 
> > This warning is ratelimited and will stop appearing after a few times, even 
> > if the touchpad jumps continue.

Thanks. The above URL is incorrect (I reported a bug about it).
A correct URL is

https://wayland.freedesktop.org/libinput/doc/1.22.0/touchpad-jumping-cursors.html

Unfortunately, this doesn't allow me to see whether this could be
related.

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



Re: touchpad buttons sometimes stop working for several seconds

2023-11-02 Thread Vincent Lefevre
Some additional details: the time during which the issue occurs
varies very much: from 25" to 6'20".

The time between two consecutive issues also varies and can be
very short, such as 30".

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



Re: touchpad buttons sometimes stop working for several seconds

2023-11-02 Thread Vincent Lefevre
On 2023-11-02 22:46:13 +0700, Max Nikulin wrote:
> On 02/11/2023 04:51, Vincent Lefevre wrote:
> > On 2023-11-01 20:15:49 +0100, Vincent Lefevre wrote:
> > > On 2023-11-01 09:09:45 +0700, Max Nikulin wrote:
> > > > Can you move cursor during these periods?
> > > 
> > > Yes, no issues with the cursor (mouse pointer).
> 
> I would still try to disable typing detection to test if it affects
> behavior of buttons.

I can see now what it does: when I'm typing, the mouse pointer
movements are disabled (but clicking is still enabled). However,
the mouse pointer events are still reported by evtest. So this
setting is unrelated to my issue, where the click events are not
reported by evtest, i.e. my issue occurs at a lower level than
libinput: the kernel driver?

> > But this is something in /var/log/lightdm/x-0.log:
> > 
> > (EE) event14 - VEN_04F3:00 04F3:311C Touchpad: kernel bug: Touch jump 
> > detected and discarded.
> > See 
> > https://wayland.freedesktop.org/libinput/doc/1.22.1/touchpad-jumping-cursors.html
> >  for details
> 
> Do these entries correlate with issues with buttons?

I can actually see 6 messages like that in /var/log/Xorg.0.log,
while my issue occurs much more often. So I think that this is
unrelated.

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



Re: touchpad buttons sometimes stop working for several seconds

2023-11-01 Thread Vincent Lefevre
On 2023-11-01 20:15:49 +0100, Vincent Lefevre wrote:
> On 2023-11-01 09:09:45 +0700, Max Nikulin wrote:
> > On 01/11/2023 00:53, Vincent Lefevre wrote:
> > > I have a new laptop. An issue I have is that the touchpad buttons often
> > > stop working for several seconds (under X11).
> > 
> > Can you move cursor during these periods?
> 
> Yes, no issues with the cursor (mouse pointer).
> 
> > I have heard about palm detection, but I am unsure if it is implemented in
> > firmware or in some user space daemons.
> > 
> > Are there any suspicious log entries in "journalctl --user" and "journalctl
> > --system" output?
> 
> Nothing suspicious. Nothing in /var/log/Xorg.0.log either.

But this is something in /var/log/lightdm/x-0.log:

(EE) event14 - VEN_04F3:00 04F3:311C Touchpad: kernel bug: Touch jump detected 
and discarded.
See 
https://wayland.freedesktop.org/libinput/doc/1.22.1/touchpad-jumping-cursors.html
 for details

several times (the issue also occurs in lightdm).

I don't know whether this is related, though. And the page no longer
exists.

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



Re: touchpad buttons sometimes stop working for several seconds

2023-11-01 Thread Vincent Lefevre
On 2023-11-01 09:09:45 +0700, Max Nikulin wrote:
> On 01/11/2023 00:53, Vincent Lefevre wrote:
> > I have a new laptop. An issue I have is that the touchpad buttons often
> > stop working for several seconds (under X11).
> 
> Can you move cursor during these periods?

Yes, no issues with the cursor (mouse pointer).

> KDE has the "disable touchpad when typing" feature (likely a kded5 plugin
> exposed as D-Bus /modules/kded_touchpad object). In your case
> 
> > libinput Disable While Typing Enabled (361):1

But since I can still move the mouse pointer, the touchpad isn't
disabled. (And I am not typing.)

> I have heard about palm detection, but I am unsure if it is implemented in
> firmware or in some user space daemons.
> 
> Are there any suspicious log entries in "journalctl --user" and "journalctl
> --system" output?

Nothing suspicious. Nothing in /var/log/Xorg.0.log either.

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



touchpad buttons sometimes stop working for several seconds

2023-10-31 Thread Vincent Lefevre
Hi,

I have a new laptop. An issue I have is that the touchpad buttons
often stop working for several seconds (under X11).

This is visible even with evtest: when I click on any of the soft
buttons, I normally get an event like

Event: time 1698773368.142943, type 1 (EV_KEY), code 272 (BTN_LEFT), value 0

But when the problem occurs, I do not get such an event.

Any idea to fix this?

The device is: VEN_04F3:00 04F3:311C

$ xinput list-props 13
Device 'VEN_04F3:00 04F3:311C Touchpad':
Device Enabled (190):   1
Coordinate Transformation Matrix (192): 1.00, 0.00, 0.00, 
0.00, 1.00, 0.00, 0.00, 0.00, 1.00
libinput Tapping Enabled (353): 0
libinput Tapping Enabled Default (354): 0
libinput Tapping Drag Enabled (355):1
libinput Tapping Drag Enabled Default (356):1
libinput Tapping Drag Lock Enabled (357):   0
libinput Tapping Drag Lock Enabled Default (358):   0
libinput Tapping Button Mapping Enabled (359):  1, 0
libinput Tapping Button Mapping Default (360):  1, 0
libinput Natural Scrolling Enabled (332):   0
libinput Natural Scrolling Enabled Default (333):   0
libinput Disable While Typing Enabled (361):1
libinput Disable While Typing Enabled Default (362):1
libinput Scroll Methods Available (334):1, 1, 0
libinput Scroll Method Enabled (335):   1, 0, 0
libinput Scroll Method Enabled Default (336):   1, 0, 0
libinput Click Methods Available (363): 1, 1
libinput Click Method Enabled (364):1, 0
libinput Click Method Enabled Default (365):1, 0
libinput Middle Emulation Enabled (366):0
libinput Middle Emulation Enabled Default (367):0
libinput Accel Speed (341): 0.00
libinput Accel Speed Default (342): 0.00
libinput Accel Profiles Available (343):1, 1
libinput Accel Profile Enabled (344):   1, 0
libinput Accel Profile Enabled Default (345):   1, 0
libinput Left Handed Enabled (346): 0
libinput Left Handed Enabled Default (347): 0
libinput Send Events Modes Available (313): 1, 1
libinput Send Events Mode Enabled (314):0, 0
libinput Send Events Mode Enabled Default (315):0, 0
Device Node (316):  "/dev/input/event14"
Device Product ID (317):1267, 12572
libinput Drag Lock Buttons (348):   
libinput Horizontal Scroll Enabled (349):   1
libinput Scrolling Pixel Distance (350):15
libinput Scrolling Pixel Distance Default (351):15
libinput High Resolution Wheel Scroll Enabled (352):1

The X input drivers:

$ dpkg -l | grep xserver-xorg-input
ii  xserver-xorg-input-all  1:7.7+23
 amd64X.Org X server -- input driver metapackage
ii  xserver-xorg-input-libinput 1.2.1-1+b1  
 amd64X.Org X server -- libinput input driver
ii  xserver-xorg-input-wacom1.1.0-1 
 amd64X.Org X server -- Wacom input driver

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



Re: using ddrescue on the root partition - boot with / as read-only

2023-09-15 Thread Vincent Lefevre
On 2023-09-14 22:24:59 -0700, David Christensen wrote:
> On 9/14/23 03:17, Vincent Lefevre wrote:
> > I get UNC errors like
> > 
> > 2023-09-10T11:50:59.858670+0200 zira kernel: ata1.00: exception Emask 0x0 
> > SAct 0xc00 SErr 0x4 action 0x0
> > 2023-09-10T11:51:00.117366+0200 zira kernel: ata1.00: irq_stat 0x4008
> > 2023-09-10T11:51:00.117431+0200 zira kernel: ata1: SError: { CommWake }
> > 2023-09-10T11:51:00.117474+0200 zira kernel: ata1.00: failed command: READ 
> > FPDMA QUEUED
> > 2023-09-10T11:51:00.117511+0200 zira kernel: ata1.00: cmd 
> > 60/00:50:b8:12:c5/02:00:1f:00:00/40 tag 10 ncq dma 262144 in
> >res 
> > 41/40:00:90:13:c5/00:02:1f:00:00/00 Emask 0x409 (media error) 
> > 2023-09-10T11:51:00.117537+0200 zira kernel: ata1.00: status: { DRDY ERR }
> > 2023-09-10T11:51:00.117560+0200 zira kernel: ata1.00: error: { UNC }
> > 2023-09-10T11:51:00.117583+0200 zira kernel: ata1.00: supports DRM 
> > functions and may not be fully accessible
> > 2023-09-10T11:51:00.117614+0200 zira kernel: ata1.00: supports DRM 
> > functions and may not be fully accessible
> > 2023-09-10T11:51:00.117651+0200 zira kernel: ata1.00: configured for 
> > UDMA/133
> > 2023-09-10T11:51:00.117681+0200 zira kernel: sd 0:0:0:0: [sda] tag#10 
> > FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
> > 2023-09-10T11:51:00.117953+0200 zira kernel: sd 0:0:0:0: [sda] tag#10 Sense 
> > Key : Medium Error [current]
> > 2023-09-10T11:51:00.118165+0200 zira kernel: sd 0:0:0:0: [sda] tag#10 Add. 
> > Sense: Unrecovered read error - auto reallocate failed
> > 2023-09-10T11:51:00.118366+0200 zira kernel: sd 0:0:0:0: [sda] tag#10 CDB: 
> > Read(10) 28 00 1f c5 12 b8 00 02 00 00
> > 2023-09-10T11:51:00.118557+0200 zira kernel: I/O error, dev sda, sector 
> > 533009296 op 0x0:(READ) flags 0x80700 phys_seg 37 prio class 2
> > 2023-09-10T11:51:00.118582+0200 zira kernel: ata1: EH complete
> > 2023-09-10T11:51:00.118608+0200 zira kernel: ata1.00: Enabling 
> > discard_zeroes_data
> 
> What is the make and model of the laptop?

HP ZBook 15 G2 (2015)

> What is the make and model of the disk drive?

Samsung 870 EVO 1TB SATA (since January 2022)

> When and where do you see the above error messages?

It seems that this occurs when bad sectors are read, either when some
files (using these bad sectors) are read or when I use the badblocks
utility (until now, I've used it only with the read test, i.e. with
no options). The messages appear in the journalctl output.

> > and after these errors, the kernel remount the root partition as
> > read-only.
> 
> That sounds like a reasonable boot loader response to an OS drive error
> during boot.

There are no errors during boot. Only when I read the affected files
or use badblocks, but only after some given number of errors.

> > Due to these errors, some files are unreadable.
> > 
> > badblocks says that there are 25252 bad blocks.
> > 
> > I'm using ddrescue before doing anything else (mainly in case things
> > would go worse), but I would essentially be interested in knowing
> > which files are affected.
> 
> Was the computer working correctly in the past?

Yes, except a few days before the first disk errors on 6 December 2022:
I got crashes from time to time (which never happened before). About
2 hours before the first errors, I upgraded the kernel and the NVIDIA
drivers from 390.154 to 390.157. In the changelog of 390.157-1:

nvidia-graphics-drivers-legacy-390xx (390.157-1) unstable; urgency=medium

  * New upstream legacy branch release 390.157 (2022-11-22).
* Fixed CVE-2022-34670, CVE-2022-34674, CVE-2022-34675, CVE-2022-34677,
  CVE-2022-34680, CVE-2022-42257, CVE-2022-42258, CVE-2022-42259.
  https://nvidia.custhelp.com/app/answers/detail/a_id/5415
  (Closes: #1025281)
* Improved compatibility with recent Linux kernels.

  [ Andreas Beckmann ]
  * Refresh patches.
  * Rename the internally used ARCH variable which might clash on externally
set values.
  * Use substitutions for ${nvidia-kernel} and friends (510.108.03-1).
  * Try to compile a kernel module at package build time (510.108.03-1).

 -- Andreas Beckmann   Sat, 03 Dec 2022 22:17:01 +0100

I'm wondering whether the crashes were due to the compatibility
with the kernel (which was the latest Debian/unstable one).

> When did you first notice the error messages?  What was the computer doing
> at the time?

I first got errors on 6 December 2022 when I was reading these files.
At that time, I identified 5 files, which I put in a
private/unreadable-files directory. Then everything was OK
until a few days ago, when I wanted to duplicate a big direct

Re: using ddrescue on the root partition - boot with / as read-only

2023-09-14 Thread Vincent Lefevre
On 2023-09-14 21:44:18 +0700, Max Nikulin wrote:
> If data are really precious then seek for a specialized service.

I normally have 2+ backups for important data. But I'd like to
double-check with what is no longer readable on the laptop disk.

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



Re: su

2023-09-14 Thread Vincent Lefevre
On 2023-09-14 21:25:56 +0700, Max Nikulin wrote:
> On 14/09/2023 17:30, Vincent Lefevre wrote:
> > Yes, XDG_RUNTIME_DIR is problematic, but as "su -" doesn't work in
> > GNU Screen (it yields major display issues), I presume that some
> > environment variables (terminal related?) are still useful.
> 
> I just have tried it. "su -" preserves TERM=screen.xterm-256color. Behavior
> is different from pure xterm-256color, but I have no guess what you may
> consider as major display issues. E.g. vim is even able to determine if
> background is dark or light and to adjust color scheme accordingly.

I noticed the issue just before the upgrade to bookworm (I wanted
to do that for the upgrade). But I can't reproduce it in bookworm.
So this may have been an old bug that has been fixed.

IIRC, this was text positioning issues, perhaps when recalling
commands from the history.

BTW, I don't think that the preservation of $TERM is sufficient.
Preserving $TERMINFO (when set) is important too.

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



Re: su

2023-09-14 Thread Vincent Lefevre
On 2023-09-06 14:36:48 +0700, Max Nikulin wrote:
> On 06/09/2023 10:41, Greg Wooledge wrote:
> > 
> > Just put "ALWAYS_SET_PATH yes" into /etc/default/su and the problem
> > is FIXED.  "su" will work properly again!
> 
> Greg, you provided a valid example when "su -" is undesirable, however in
> general "su -" is safer than just "su" since it resets some user specific
> environment variables like XDG_RUNTIME_DIR=/run/user/1000 that may cause
> creation of files that the original user can not overwrite them. So "su -"
> should have less unexpected effects.

Yes, XDG_RUNTIME_DIR is problematic, but as "su -" doesn't work in
GNU Screen (it yields major display issues), I presume that some
environment variables (terminal related?) are still useful.

FYI, I had written a su wrapper that unsets XDG_RUNTIME_DIR first.

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



Re: using ddrescue on the root partition - boot with / as read-only

2023-09-14 Thread Vincent Lefevre
On 2023-09-13 20:52:43 -0700, David Christensen wrote:
> On 9/13/23 04:54, Vincent Lefevre wrote:
> > Hi,
> > 
> > I need to use ddrescue on the root partition of my laptop.
> > 
> > So I need to have the root partition mounted in read-only mode.
> > How can I do that?
> > 
> > Note that "mount -o remount,ro /" gives an error "mount point is busy"
> > apparently because various log files are open in write mode.
> > 
> > Using the recovery mode via GRUB (which mounts / in read-only mode)
> > is useless because the system remounts it later as rw.
> > 
> > Or is there a way to force a remount in read-only mode?
> > (I could probably trigger a disk error to make the kernel remount /
> > as read-only, but well...)
> 
> What symptom(s) is your laptop exhibiting that make you think that you need
> to use ddrescue(1) on the root partition?

I get UNC errors like

2023-09-10T11:50:59.858670+0200 zira kernel: ata1.00: exception Emask 0x0 SAct 
0xc00 SErr 0x4 action 0x0
2023-09-10T11:51:00.117366+0200 zira kernel: ata1.00: irq_stat 0x4008
2023-09-10T11:51:00.117431+0200 zira kernel: ata1: SError: { CommWake }
2023-09-10T11:51:00.117474+0200 zira kernel: ata1.00: failed command: READ 
FPDMA QUEUED
2023-09-10T11:51:00.117511+0200 zira kernel: ata1.00: cmd 
60/00:50:b8:12:c5/02:00:1f:00:00/40 tag 10 ncq dma 262144 in
  res 
41/40:00:90:13:c5/00:02:1f:00:00/00 Emask 0x409 (media error) 
2023-09-10T11:51:00.117537+0200 zira kernel: ata1.00: status: { DRDY ERR }
2023-09-10T11:51:00.117560+0200 zira kernel: ata1.00: error: { UNC }
2023-09-10T11:51:00.117583+0200 zira kernel: ata1.00: supports DRM functions 
and may not be fully accessible
2023-09-10T11:51:00.117614+0200 zira kernel: ata1.00: supports DRM functions 
and may not be fully accessible
2023-09-10T11:51:00.117651+0200 zira kernel: ata1.00: configured for UDMA/133
2023-09-10T11:51:00.117681+0200 zira kernel: sd 0:0:0:0: [sda] tag#10 FAILED 
Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=0s
2023-09-10T11:51:00.117953+0200 zira kernel: sd 0:0:0:0: [sda] tag#10 Sense Key 
: Medium Error [current] 
2023-09-10T11:51:00.118165+0200 zira kernel: sd 0:0:0:0: [sda] tag#10 Add. 
Sense: Unrecovered read error - auto reallocate failed
2023-09-10T11:51:00.118366+0200 zira kernel: sd 0:0:0:0: [sda] tag#10 CDB: 
Read(10) 28 00 1f c5 12 b8 00 02 00 00
2023-09-10T11:51:00.118557+0200 zira kernel: I/O error, dev sda, sector 
533009296 op 0x0:(READ) flags 0x80700 phys_seg 37 prio class 2
2023-09-10T11:51:00.118582+0200 zira kernel: ata1: EH complete
2023-09-10T11:51:00.118608+0200 zira kernel: ata1.00: Enabling 
discard_zeroes_data

and after these errors, the kernel remount the root partition as
read-only. Due to these errors, some files are unreadable.

badblocks says that there are 25252 bad blocks.

I'm using ddrescue before doing anything else (mainly in case things
would go worse), but I would essentially be interested in knowing
which files are affected.

The laptop is in the process of being replaced, so I don't plan to
replace the disk (unless things get really wrong).

> Have you read the "GNU ddrescue Manual"?
> 
> https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html

Yes.

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



Re: using ddrescue on the root partition - boot with / as read-only

2023-09-14 Thread Vincent Lefevre
On 2023-09-13 23:00:27 -0400, Stefan Monnier wrote:
> > Or perhaps I could use /bin/sh as init, so that systemd (and its
> > remount as rw) would be avoided?
> 
> Indeed booting with `init=/bin/bash` can be a handy option I've used in
> the past: you get into the normal root (so you don't have to figure out
> how to find and mount root from the initramfs), mounted read-only.

I've used init=/bin/sh, but bash (or zsh) would have been more
practical (as dash doesn't have completions).

Two other things are needed:
  * The USB drive must be connected before booting so that the device
is recognized (otherwise lsblk doesn't list it).
  * At some point, I got too many kernel messages in the console, and
I couldn't stop them (I thought that they were due to disk errors
because of ddrescue, but Ctrl-C had no effect). The solution
I found on the web was to set kernel.printk to 3 3 3 3. I did
that with:
  sysctl kernel.printk="3 3 3 3"
Then I resumed ddrescue. Still onging...

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



Re: using ddrescue on the root partition - boot with / as read-only

2023-09-13 Thread Vincent Lefevre
On 2023-09-13 14:15:30 +0200, to...@tuxteam.de wrote:
> On Wed, Sep 13, 2023 at 01:54:04PM +0200, Vincent Lefevre wrote:
> > I need to use ddrescue on the root partition of my laptop.
> > 
> > So I need to have the root partition mounted in read-only mode.

BTW, in recovery mode, it is systemd that remounts the partition in rw
mode. From the "journalctl -b" output:

Sep 13 13:20:13 zira kernel: EXT4-fs (dm-2): mounted filesystem 
fb1e7272-f798-4ae9-a53b-e62e3139e239 ro with ordered data mode. Quota mode: 
none.

so this is initially "ro" as wanted. But later:

Sep 13 13:20:14 zira systemd[1]: Starting systemd-remount-fs.service - Remount 
Root and Kernel File Systems...
Sep 13 13:20:14 zira kernel: EXT4-fs (dm-2): re-mounted 
fb1e7272-f798-4ae9-a53b-e62e3139e239 r/w. Quota mode: none.

> > How can I do that?
> 
> In roughly ascending order of comfort (but also of "external tools
> needed"):
> 
>  - break out in the initramfs, before root is pivoted to
>your customary root partition. At this point your system
>is running on the loaded initramfs (enter 'break=pre-mount'
>at the grub command line ** NOTE: please, double check this,
>it's from memory!)

I suppose that it would be better to break after the mount
(break=mountroot or perhaps bottom or init): so the root partition
would already be mounted in read-only mode (otherwise, since this
is an encrypted partition, it would be more complex).

But this would also mean that I would have to run ddrescue from
the initramfs.

Or perhaps I could use /bin/sh as init, so that systemd (and its
remount as rw) would be avoided?

>  - use a "live" OS (either explicitly built for that, like
>Knoppix,

If I could install it on the disk used for the backup (there is enough
space) and boot from the USB drive, this could be a solution.

> or, e.g. Debian's "rescue" mode)

I suppose that this is what is actually called "recovery mode"
in GRUB. But I suppose that I would need to add init=/bin/sh
to avoid systemd (see above).

>  - extract the disk and put it (perhaps in a USB case) into
>another computer

Not really possible for me (except if everything else fails).

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



using ddrescue on the root partition - boot with / as read-only

2023-09-13 Thread Vincent Lefevre
Hi,

I need to use ddrescue on the root partition of my laptop.

So I need to have the root partition mounted in read-only mode.
How can I do that?

Note that "mount -o remount,ro /" gives an error "mount point is busy"
apparently because various log files are open in write mode.

Using the recovery mode via GRUB (which mounts / in read-only mode)
is useless because the system remounts it later as rw.

Or is there a way to force a remount in read-only mode?
(I could probably trigger a disk error to make the kernel remount /
as read-only, but well...)

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



Re: bookworm upgrade report: boring

2023-06-14 Thread Vincent Lefevre
On 2023-06-13 13:41:23 -0500, Nate Bargmann wrote:
> I have always chickened out on that option.  Looking at the ucf man page
> and the description of the three-way merge it looks like the user would
> have a yes or no option but no edit option.

One can always run an editor from a shell.

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



Re: bookworm upgrade report: boring

2023-06-13 Thread Vincent Lefevre
On 2023-06-13 06:41:41 -0500, Nate Bargmann wrote:
> I've been experimenting with Arch Linux for some time and one thing I
> like about its pacman package management system is that it has a tool
> available named 'pacdiff'.  The details are off topic but in a nutshell
> what it does is identify a locally modified config and the corresponding
> new config files and can open them in 'vimdiff' giving a nice display of
> the diff using the vim editor.  Once the editing is complete there is a
> final step to discard the new config file or replace the current one
> with it.  I do like that Debian retains the new file with various file
> name extensions for future reference.
> 
> I know that apt allows for viewing a unified diff of the files, but it
> has been quite some time since I've been presented with that menu that I
> don't recall if editing based on the diff is an option.  It certainly
> seems that calling vimdiff in that situation would be quite easy but I
> realize that not many are comfortable with vim and would want a more
> universal editor that I might not like.

This is not apt, but dpkg, which is rather limited:

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

(yes, 1999).

Some packages offer a 3-way merge, which is very useful. I think that
in this case, the configuration file handling is done via ucf (the
possibility of a merge is mentioned in its man page).

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



Re: bookworm upgrade report: boring

2023-06-13 Thread Vincent Lefevre
On 2023-06-12 13:33:02 -0400, Celejar wrote:
> Often, but apparently not always. For example, on one of my upgrades,
> the old sshd_config had:
> 
> **
> # Change to yes to enable challenge-response passwords (beware issues with
> # some PAM modules and threads)
> ChallengeResponseAuthentication no
> **
> 
> whereas the new one had:
> 
> **
> # Change to yes to enable challenge-response passwords (beware issues with
> # some PAM modules and threads)
> KbdInteractiveAuthentication no
> **

In the /usr/share/doc/openssh-server/changelog.Debian.gz file:

openssh (1:8.7p1-1) unstable; urgency=medium
[...]
- ssh(1)/sshd(8): remove references to ChallengeResponseAuthentication
  in favour of KbdInteractiveAuthentication. The former is what was in
  SSHv1, the latter is what is in SSHv2 (RFC4256) and they were treated
  as somewhat but not entirely equivalent. We retain the old name as a
  deprecated alias so configuration files continue to work as well as a
  reference in the man page for people looking for it.

> Is this important?

If the alias is still there, this is not important. Otherwise, either
the option could be ignored (so you get the default), possibly with a
warning, or there could be a fatal error (but you would have noticed
it); I don't know how sshd behaves in case of an unknown option.

But in any case, I would recommend to update the config.

> What would have happened had I left the old version,
> as opposed to switching to the new version? Presumably nothing, since
> I'm using the safer default setting in either case, and I suppose I
> could have taken the time to track down the change and its
> implications, but running into these types of situations while
> upgrading can be disconcerting.
> 
> > and reject the package version offered. Less stressful and speeds up
> > the installation. If necessary, I investigate afterwards.
> 
> This is probably the logical thing to do, but I'm always worried that
> there may be new settings that should be set, and so on.

I always look at the diffs (I track all the config files I modify),
and sometimes at the logs too. In general, I do some kind of merge.

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



Re: bookworm upgrade report: boring

2023-06-13 Thread Vincent Lefevre
On 2023-06-12 18:00:58 +0100, Joe wrote:
> Yes. I run a fairly customised exim4, and during one upgrade, I think
> either to or from etch, I kept my configuration, and it broke the exim4
> installation. Exim4 was unconfigured, so it wouldn't run, but
> dpkg-reconfigure couldn't work either. Even a purge wouldn't enable
> reinstallation, and I had to resort to manually deleting files.

What files? If these are files under directories like /etc or
/usr/local (where the user can put his one things), this is not
normal, and I suppose that a bug should be reported. Otherwise,
this is not surprising.

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



Re: X11 should not run as root or?

2023-06-04 Thread Vincent Lefevre
On 2023-06-02 22:21:56 +, therealcyclist wrote:
> Am Fri, Jun 02, 2023 at 07:07:05PM +0200 schrieb Michel Verdier:
> > Le 2 juin 2023 therealcyclist a écrit :
> > 
> > > I tried the new Debian bookworm installer rc4 and i manually installed 
> > > i3-wm.
> > > I started i3 from tty with startx command as user.
> > > to my surprise i found out that the xorg process is running as root.
> > > that can't be intentional, can it?
> > 
> > Maybe because some display managers want xorg as root
> > https://wiki.archlinux.org/title/Xorg#Rootless_Xorg
> 
> You linked to the Archlinux Wiki and I have installed i3-wm under
> archlinux and there X11 runs without root privileges by default.
> 
> I assumed that it is the same under Debian because Debian is known
> for having relatively safe default values.
> It looks like i3 doesn't need x11 as root either.

i3-wm is a window manager, not a display manager. So it depends on
what display manager you're using (if any).

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



  1   2   3   4   5   6   7   8   9   10   >