Why is bullseye-backports recommended on bookworm?

Vincent Lefevre

unread,

Nov 14, 2023, 7:10:07 AM11/14/23

to

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 <vin...@vinc17.net> - 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)

Greg Wooledge

unread,

Nov 14, 2023, 7:40:07 AM11/14/23

to

On Tue, Nov 14, 2023 at 01:00:47PM +0100, Vincent Lefevre wrote:
> 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|?]?

Looks like something that can be ignored. They're probably both the
same kernel source anyway, just built in different environments.

Max Nikulin

unread,

Nov 14, 2023, 12:00:07 PM11/14/23

to

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?

apt policy
apt policy linux-image-amd64

Vincent Lefevre

unread,

Nov 14, 2023, 4:30:06 PM11/14/23

to

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['oldstable']
oldstable_pu = oldstable + '-pu'
oldstable_backports = oldstable + '-backports'
oldstable_security = oldstable + '-security'

But it doesn't seem to be used.

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

# The page looks like this:
#
# $ wget -qO- 'https://qa.debian.org/madison.php?package=emacs&text=on&s=oldstable,stable,testing,unstable,experimental&a=source,all,x86_64'

but that's a comment.

Greg Wooledge

unread,

Nov 14, 2023, 4:40:05 PM11/14/23

to

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.

That's why I suggested ignoring the message.

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

When you mix binary repositories of unstable, testing and bookworm,
you are by definition running unstable. "But pinning!" Nope. It's an
unstable system, no matter how many hoops you jump through trying to
control the frankendebian.

Vincent Lefevre

unread,

Nov 14, 2023, 5:10:07 PM11/14/23

to

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.

Max Nikulin

unread,

Nov 14, 2023, 10:20:06 PM11/14/23

to

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.

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

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.

Tap-to-click with one, two, or three fingers has no such issue.

Have you tried tools specific to libinput instead of xinput?

Perhaps the that thread on touchpad would be more appropriate for this part.

didier gaumet

unread,

Nov 15, 2023, 3:00:07 AM11/15/23

to

Le 14/11/2023 à 23:01, Vincent Lefevre a écrit :
[...]

> Then why does reportbug mention the bullseye-backports kernel?

[...]

Hello,

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

Curt

unread,

Nov 15, 2023, 11:40:06 AM11/15/23

to

On 2023-11-14, Vincent Lefevre <vin...@vinc17.net> 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.

Vincent Lefevre

unread,

Nov 15, 2023, 12:10:07 PM11/15/23

to

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.

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 Lefevre

unread,

Nov 15, 2023, 12:20:06 PM11/15/23

to

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 Lefevre

unread,

Nov 15, 2023, 12:20:07 PM11/15/23

to

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

Tixy

unread,

Nov 15, 2023, 1:10:07 PM11/15/23

to

On Wed, 2023-11-15 at 18:15 +0100, Vincent Lefevre wrote:
> On 2023-11-15 16:39:15 -0000, Curt wrote:
> > On 2023-11-14, Vincent Lefevre <vin...@vinc17.net> 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? bookworm-backports has a linux-6.5
package which is not a newer version of the linux-6.1 package it's
totally separate as far as the packaging system is concerned.

--
Tixy

Vincent Lefevre

unread,

Nov 15, 2023, 2:10:07 PM11/15/23

to

On 2023-11-15 18:06:45 +0000, Tixy wrote:
> On Wed, 2023-11-15 at 18:15 +0100, Vincent Lefevre wrote:
> > On 2023-11-15 16:39:15 -0000, Curt wrote:
> > > On 2023-11-14, Vincent Lefevre <vin...@vinc17.net> 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.

David Wright

unread,

Nov 15, 2023, 3:00:06 PM11/15/23

to

On Wed 15 Nov 2023 at 20:01:20 (+0100), Vincent Lefevre wrote:
> On 2023-11-15 18:06:45 +0000, Tixy wrote:
> > On Wed, 2023-11-15 at 18:15 +0100, Vincent Lefevre wrote:
> > > On 2023-11-15 16:39:15 -0000, Curt wrote:
> > > > On 2023-11-14, Vincent Lefevre <vin...@vinc17.net> 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.

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

$ zgrep -A3 '^Package: linux-image' Packages.xz | paste - - - - - | sed 's/Package: //;s/\tSource:/ src/;s/\tVersion:/ ver/;s/\tInstalled-Size:/ isize/;s/\t--//'
linux-image-6.1.0-0.deb11.11-amd64-dbg src linux ver 6.1.38-4~bpo11+1 isize 6336657
linux-image-6.1.0-0.deb11.11-amd64-unsigned src linux ver 6.1.38-4~bpo11+1 isize 499959
linux-image-6.1.0-0.deb11.11-cloud-amd64-dbg src linux ver 6.1.38-4~bpo11+1 isize 2051897
linux-image-6.1.0-0.deb11.11-cloud-amd64-unsigned src linux ver 6.1.38-4~bpo11+1 isize 145318
linux-image-6.1.0-0.deb11.11-rt-amd64-dbg src linux ver 6.1.38-4~bpo11+1 isize 6404909
linux-image-6.1.0-0.deb11.11-rt-amd64-unsigned src linux ver 6.1.38-4~bpo11+1 isize 518751
linux-image-6.1.0-0.deb11.13-amd64-dbg src linux ver 6.1.55-1~bpo11+1 isize 6340686
linux-image-6.1.0-0.deb11.13-amd64-unsigned src linux ver 6.1.55-1~bpo11+1 isize 499954
linux-image-6.1.0-0.deb11.13-cloud-amd64-dbg src linux ver 6.1.55-1~bpo11+1 isize 2051852
linux-image-6.1.0-0.deb11.13-cloud-amd64-unsigned src linux ver 6.1.55-1~bpo11+1 isize 145473
linux-image-6.1.0-0.deb11.13-rt-amd64-dbg src linux ver 6.1.55-1~bpo11+1 isize 6409844
linux-image-6.1.0-0.deb11.13-rt-amd64-unsigned src linux ver 6.1.55-1~bpo11+1 isize 518558
linux-image-amd64-dbg src linux ver 6.1.55-1~bpo11+1 isize 13
linux-image-amd64-signed-template src linux ver 6.1.55-1~bpo11+1 isize 3884
linux-image-cloud-amd64-dbg src linux ver 6.1.55-1~bpo11+1 isize 13
linux-image-rt-amd64-dbg src linux ver 6.1.55-1~bpo11+1 isize 13
linux-image-6.1.0-0.deb11.11-amd64 src linux-signed-amd64 (6.1.38+4~bpo11+1) ver 6.1.38-4~bpo11+1 isize 501754
linux-image-6.1.0-0.deb11.11-cloud-amd64 src linux-signed-amd64 (6.1.38+4~bpo11+1) ver 6.1.38-4~bpo11+1 isize 145823
linux-image-6.1.0-0.deb11.11-rt-amd64 src linux-signed-amd64 (6.1.38+4~bpo11+1) ver 6.1.38-4~bpo11+1 isize 520577
linux-image-6.1.0-0.deb11.9-amd64 src linux-signed-amd64 (6.1.27+1~bpo11+1) ver 6.1.27-1~bpo11+1 isize 501563
linux-image-6.1.0-0.deb11.9-cloud-amd64 src linux-signed-amd64 (6.1.27+1~bpo11+1) ver 6.1.27-1~bpo11+1 isize 145610
linux-image-6.1.0-0.deb11.9-rt-amd64 src linux-signed-amd64 (6.1.27+1~bpo11+1) ver 6.1.27-1~bpo11+1 isize 520274
linux-image-amd64 src linux-signed-amd64 (6.1.38+4~bpo11+1) ver 6.1.38-4~bpo11+1 isize 13
linux-image-cloud-amd64 src linux-signed-amd64 (6.1.38+4~bpo11+1) ver 6.1.38-4~bpo11+1 isize 13
linux-image-rt-amd64 src linux-signed-amd64 (6.1.38+4~bpo11+1) ver 6.1.38-4~bpo11+1 isize 13
$

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

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.

Cheers,
David.

Vincent Lefevre

unread,

Nov 16, 2023, 7:10:06 AM11/16/23

to

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 +0000, Tixy wrote:
> > > On Wed, 2023-11-15 at 18:15 +0100, Vincent Lefevre wrote:
> > > > On 2023-11-15 16:39:15 -0000, Curt wrote:
> > > > > On 2023-11-14, Vincent Lefevre <vin...@vinc17.net> 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 Lefevre

unread,

Nov 16, 2023, 7:30:06 AM11/16/23

to

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 +0000, 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".

David Wright

unread,

Nov 16, 2023, 3:10:05 PM11/16/23

to

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.

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

I didn't know that, and at least one post in this thread suggests otherwise.

> > 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 "+").

Yes, and I assumed that might be because sources are being looked up
as well as binaries. Looking at the list I posted, the top half has
the Sources (src) specified as plain "linux". The bottom half is more
forthcoming, with versions in parentheses. I can only assume that
these are source versions and that's the reason for their + signs.

But this is way deeper than I have plumbed in version numbering.
I used to compile custom kernels when the hardware was much simpler,
but my versioning was always protected by a nice big Epoch.

Cheers,
David.

Vincent Lefevre

unread,

Nov 17, 2023, 7:40:07 AM11/17/23

to

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

Tixy

unread,

Nov 17, 2023, 9:10:07 AM11/17/23

to

There is no binary package called 'linux-image'. My PC has 'linux-
image-amd64' installed which is a meta package who's description says
'This package depends on the latest Linux kernel and modules for use on
PCs with AMD64'.

At time of writing, that depended on package in stable is called
'linux-image-6.1.0-13-amd64' and the version of that package is
'6.1.55-1'. This is the kernel installed on my machine.

In the original post that sparked this thread, Vincent showed reportbug
saying that same binary package (linux-image-6.1.0-13-amd64) had a
newer version available in backports, with the version number
6.1.55+1~bpo11+1.

Report bug is correct, that is a newer version by Debian versioning
rules, there is no 'fuzzy' matching involved...

$ dpkg --compare-versions 6.1.55+1~bpo11+1 gt 6.1.55-1; then echo True; else echo False; fi
True

Now, I admit, looking in a prior releases backports for a newer version
seems wrong, assuming the machine in question didn't have that release
in it's source.list.

--
Tixy

David Wright

unread,

Nov 18, 2023, 1:30:07 AM11/18/23

to

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. 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."’

Cheers,
David.

David Wright

unread,

Nov 18, 2023, 1:30:07 AM11/18/23

to

On Fri 17 Nov 2023 at 14:07:54 (+0000), Tixy wrote:
> On Thu, 2023-11-16 at 14:04 -0600, David Wright wrote:
> > On Thu 16 Nov 2023 at 13:02:28 (+0100), Vincent Lefevre wrote:
> > > 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 +0000, Tixy wrote:
> > > > > > On Wed, 2023-11-15 at 18:15 +0100, Vincent Lefevre wrote:
> > > > > > > On 2023-11-15 16:39:15 -0000, Curt wrote:
> > > > > > > > On 2023-11-14, Vincent Lefevre <vin...@vinc17.net> 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...).

This is the bit I don't agree with. Perhaps just terminology…

> > > > > 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.
> >
> > 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.
>
> There is no binary package called 'linux-image'.

Of course, the names of Debian packaged binary kernel images are an
agglomeration of 'linux-image', flavour, upstream version, and a
Debian version counter, incremented AIUI when the internal interfaces
change (so that the modules will stay in step).

> My PC has 'linux-
> image-amd64' installed which is a meta package who's description says
> 'This package depends on the latest Linux kernel and modules for use on
> PCs with AMD64'.
>
> At time of writing, that depended on package in stable is called
> 'linux-image-6.1.0-13-amd64' and the version of that package is
> '6.1.55-1'. This is the kernel installed on my machine.

And AIUI that version is the upstream source version, and a Debian
counter for that source. The counter is rarely used, AFAICT, and can
cause consternation when it is, because it means the kernel gets
upgraded 'in place', making it tricky to revert if you wanted to.
(That shouldn't normally be necessary.) And I'm sure you know all
this, or something like it.

> In the original post that sparked this thread, Vincent showed reportbug
> saying that same binary package (linux-image-6.1.0-13-amd64) had a
> newer version available in backports, with the version number
> 6.1.55+1~bpo11+1.
>
> Report bug is correct, that is a newer version by Debian versioning
> rules, there is no 'fuzzy' matching involved...
>

if↘

> $ dpkg --compare-versions 6.1.55+1~bpo11+1 gt 6.1.55-1; then echo True; else echo False; fi
> True
>
> Now, I admit, looking in a prior releases backports for a newer version
> seems wrong, assuming the machine in question didn't have that release
> in it's source.list.

It is fuzzy in one sense. When APT and dpkg compare versions, they use
the version numbers exposed in the name of the .deb file, which in
your case above, are 6.1.55-1~bpo11+1 and 6.1.55-1:

$ if dpkg --compare-versions 6.1.55-1~bpo11+1 gt 6.1.55-1; then echo True; else echo False; fi
False
$

This is caused by the use of ~bpo rather than -bpo, to make sure that
backports get replaced, similar to the ~rc trick for release candidates.
Otherwise you would get:

$ if dpkg --compare-versions 6.1.55-1-bpo11+1 gt 6.1.55-1; then echo True; else echo False; fi
True
$

The 'fuzziness' is that your comparison is made using the /source/
version, which is why I included the Source field (src) in my listing.
What I can't answer is why the top half of the list has their sources
only specified as plain "linux". It's very easy to extract the source
version from the package version, however (ie change the first - to +).

But that question is moot, as it appears that reportbug may look on
the internet, and could be doing something completely different anyway.

Cheers,
David.

Greg Wooledge

unread,

Nov 18, 2023, 9:20:07 AM11/18/23

to

On Sat, Nov 18, 2023 at 12:24:30AM -0600, David Wright wrote:
> On Fri 17 Nov 2023 at 14:07:54 (+0000), Tixy wrote:
> > At time of writing, that depended on package in stable is called
> > 'linux-image-6.1.0-13-amd64' and the version of that package is
> > '6.1.55-1'. This is the kernel installed on my machine.
>
> And AIUI that version is the upstream source version, and a Debian
> counter for that source. The counter is rarely used, AFAICT, and can
> cause consternation when it is, because it means the kernel gets
> upgraded 'in place', making it tricky to revert if you wanted to.
> (That shouldn't normally be necessary.) And I'm sure you know all
> this, or something like it.

Debian kernel images have a complex naming system, to be sure. Let's
look at the package name first: linux-image-6.1.0-13-amd64

The "linux-image-" part is obvious. That's static.

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.

The "13" is the ABI (Application Binary Interface) identifier. This
gets incremented each time the kernel's internal structures change in
a way that would require kernel modules to be recompiled.

And finally, the "-amd64" part is the architecture.

Next, look at the package version string: 6.1.55-1

The "6.1.55" part is the upstream release number. In this case, this
is the 55th point release in the upstream 6.1.x series.

The "-1" indicates that this is the first Debian package built from
this upstream release, by the Debian kernel image maintainers.

Now, let's say a major bug is found in this kernel, and the maintainers
decide to release a new kernel package built from the same upstream
source, but with a fix. Depending on the changes they make, one of two
things can happen:

1) If the fix doesn't require an ABI change (old modules can be loaded
by the new kernel), then they only have to increment the package
version number. So they'll release package linux-image-6.1.0-13-amd64
version 6.1.55-2. (Or if it were the security team doing it, then
the version number would be something like 6.1.55-1+deb12u1 instead.)

2) If the fix requires an ABI change, then a new package name has to
be created. In this case, they'll release a new package
linux-image-6.1.0-14-amd64 with version 6.1.55-1 (or something
like 6.1.55-0+deb12u1 maybe, although the security team is much
less likely to invoke an ABI change).

In practice, though, new kernel images are most likely to be released
after a whole bunch of upstream point releases have occurred, and
will roll up all of those upstream changes into one gigantic change.
So we would most likely jump from linux-image-6.1.0-13-amd64 version
6.1.55-1 to linux-image-6.1.0-14-amd64 version 6.1.72-1 (or something
along those lines). Because so many changes get amalgamated together,
it's vanishingly rare for the ABI counter *not* to increment.

steve

unread,

Nov 18, 2023, 9:40:07 AM11/18/23

to

Thanks Greg for the precise explanation. I would suggest to put it in the
Debian Wiki for futur reference.

Vincent Lefevre

unread,

Nov 18, 2023, 5:30:06 PM11/18/23

to

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 Lefevre

unread,

Nov 18, 2023, 5:40:07 PM11/18/23

to

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.

Tim Woodall

unread,

Nov 19, 2023, 12:00:06 AM11/19/23

to

On Tue, 14 Nov 2023, Vincent Lefevre wrote:

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

I'm not exactly sure how numbering works with unstable but
6.1.55+1~bpo11+1 comes after 6.1.55-1 but before 6.1.55+1

I'm not sure how you've ended up with a version with a '-' or bpo has
ended up with a '+'.

I thought the whole point of the bpo numbering was so it sorted before
the next release.

David Wright

unread,

Nov 19, 2023, 12:50:06 AM11/19/23

to

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.

Cheers,
David.

David Wright

unread,

Nov 19, 2023, 12:50:06 AM11/19/23

to

On Sat 18 Nov 2023 at 15:29:51 (+0100), steve wrote:
> Le 18-11-2023, à 09:18:56 -0500, Greg Wooledge a écrit :
> > On Sat, Nov 18, 2023 at 12:24:30AM -0600, David Wright wrote:
> > > On Fri 17 Nov 2023 at 14:07:54 (+0000), Tixy wrote:
> > > > At time of writing, that depended on package in stable is called
> > > > 'linux-image-6.1.0-13-amd64' and the version of that package is
> > > > '6.1.55-1'. This is the kernel installed on my machine.
> > >
> > > And AIUI that version is the upstream source version, and a Debian
> > > counter for that source. The counter is rarely used, AFAICT, and can
> > > cause consternation when it is, because it means the kernel gets
> > > upgraded 'in place', making it tricky to revert if you wanted to.
> > > (That shouldn't normally be necessary.) And I'm sure you know all
> > > this, or something like it.
> >
> > Debian kernel images have a complex naming system, to be sure. Let's
> > look at the package name first: linux-image-6.1.0-13-amd64
> >
> > The "linux-image-" part is obvious. That's static.
> >
> > 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.
> >
> > The "13" is the ABI (Application Binary Interface) identifier. This
> > gets incremented each time the kernel's internal structures change in
> > a way that would require kernel modules to be recompiled.
> >
> > And finally, the "-amd64" part is the architecture.

I used the term flavour, to encompass the variety within the i386
architecture: {3,4,5,6}86[-pae][-smp] and so on. I don't follow
other architectures enough to know whether a similar variety
exists elsewhere.

> > Next, look at the package version string: 6.1.55-1
> >
> > The "6.1.55" part is the upstream release number. In this case, this
> > is the 55th point release in the upstream 6.1.x series.
> >
> > The "-1" indicates that this is the first Debian package built from
> > this upstream release, by the Debian kernel image maintainers.
> >
> > Now, let's say a major bug is found in this kernel, and the maintainers
> > decide to release a new kernel package built from the same upstream
> > source, but with a fix. Depending on the changes they make, one of two
> > things can happen:
> >
> > 1) If the fix doesn't require an ABI change (old modules can be loaded
> > by the new kernel), then they only have to increment the package
> > version number. So they'll release package linux-image-6.1.0-13-amd64
> > version 6.1.55-2. (Or if it were the security team doing it, then
> > the version number would be something like 6.1.55-1+deb12u1 instead.)

We saw that happening in July with linux-image-5.10.0-23-amd64
(bullseye), when there were three versions (sources 5.10.179-{1,2,3})
in use over a period of 12 weeks (6 CVEs).

> > 2) If the fix requires an ABI change, then a new package name has to
> > be created. In this case, they'll release a new package
> > linux-image-6.1.0-14-amd64 with version 6.1.55-1 (or something
> > like 6.1.55-0+deb12u1 maybe, although the security team is much
> > less likely to invoke an ABI change).
> >
> > In practice, though, new kernel images are most likely to be released
> > after a whole bunch of upstream point releases have occurred, and
> > will roll up all of those upstream changes into one gigantic change.
> > So we would most likely jump from linux-image-6.1.0-13-amd64 version
> > 6.1.55-1 to linux-image-6.1.0-14-amd64 version 6.1.72-1 (or something
> > along those lines). Because so many changes get amalgamated together,
> > it's vanishingly rare for the ABI counter *not* to increment.
>

> Thanks Greg for the precise explanation. I would suggest to put it in the
> Debian Wiki for futur reference.

Cheers,
David.

David Wright

unread,

Nov 19, 2023, 12:50:06 AM11/19/23

to

On Sat 18 Nov 2023 at 23:24:25 (+0100), Vincent Lefevre wrote:
> 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.

As I wrote elsewhere, I think we're using the 'rename' differently.

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

I wasn't implying that reportbug downloaded Packages files from
anywhere. You might have thought I did because /I/ downloaded the
backports Packages file, but that was because I don't know how to
use your 'various means' to get package information from the web.

My point was that Greg's post suggested reportbug could range much
further afield than your computer's APT lists and sources.list.

Cheers,
David.

Vincent Lefevre

unread,

Nov 20, 2023, 5:20:06 AM11/20/23

to

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

David Wright

unread,

Nov 20, 2023, 10:40:06 PM11/20/23

to

On Mon 20 Nov 2023 at 11:12:03 (+0100), Vincent Lefevre wrote:
> 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.

There aren't really three numbers, and it's the software that's wrong,
perhaps written back in the days of 2.6.26 (lenny) or earlier.

Cheers,
David.