Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #263526 > unrolled thread

Why is bullseye-backports recommended on bookworm?

Back to article view | Back to linux.debian.user

Contents

  Why is bullseye-backports recommended on bookworm? Vincent Lefevre <vincent@vinc17.net> - 2023-11-14 13:10 +0100
    Re: Why is bullseye-backports recommended on bookworm? Greg Wooledge <greg@wooledge.org> - 2023-11-14 13:40 +0100
    Re: Why is bullseye-backports recommended on bookworm? Max Nikulin <manikulin@gmail.com> - 2023-11-14 18:00 +0100
      Re: Why is bullseye-backports recommended on bookworm? Vincent Lefevre <vincent@vinc17.net> - 2023-11-14 22:30 +0100
        Re: Why is bullseye-backports recommended on bookworm? Greg Wooledge <greg@wooledge.org> - 2023-11-14 22:40 +0100
          Re: Why is bullseye-backports recommended on bookworm? Vincent Lefevre <vincent@vinc17.net> - 2023-11-14 23:10 +0100
            Re: Why is bullseye-backports recommended on bookworm? Max Nikulin <manikulin@gmail.com> - 2023-11-15 04:20 +0100
              Re: Why is bullseye-backports recommended on bookworm? Vincent Lefevre <vincent@vinc17.net> - 2023-11-15 18:10 +0100
            Re: Why is bullseye-backports recommended on bookworm? didier gaumet <didier.gaumet@gmail.com> - 2023-11-15 09:00 +0100
              Re: Why is bullseye-backports recommended on bookworm? Vincent Lefevre <vincent@vinc17.net> - 2023-11-15 18:20 +0100
            Re: Why is bullseye-backports recommended on bookworm? Curt <curty@free.fr> - 2023-11-15 17:40 +0100
              Re: Why is bullseye-backports recommended on bookworm? Vincent Lefevre <vincent@vinc17.net> - 2023-11-15 18:20 +0100
                Re: Why is bullseye-backports recommended on bookworm? Tixy <tixy@yxit.co.uk> - 2023-11-15 19:10 +0100
                  Re: Why is bullseye-backports recommended on bookworm? Vincent Lefevre <vincent@vinc17.net> - 2023-11-15 20:10 +0100
                    Re: Why is bullseye-backports recommended on bookworm? David Wright <deblis@lionunicorn.co.uk> - 2023-11-15 21:00 +0100
                      Re: Why is bullseye-backports recommended on bookworm? Vincent Lefevre <vincent@vinc17.net> - 2023-11-16 13:10 +0100
                        Re: Why is bullseye-backports recommended on bookworm? David Wright <deblis@lionunicorn.co.uk> - 2023-11-16 21:10 +0100
                          Re: Why is bullseye-backports recommended on bookworm? Vincent Lefevre <vincent@vinc17.net> - 2023-11-17 13:40 +0100
                            Re: Why is bullseye-backports recommended on bookworm? David Wright <deblis@lionunicorn.co.uk> - 2023-11-18 07:30 +0100
                              Re: Why is bullseye-backports recommended on bookworm? Vincent Lefevre <vincent@vinc17.net> - 2023-11-18 23:30 +0100
                                Re: Why is bullseye-backports recommended on bookworm? David Wright <deblis@lionunicorn.co.uk> - 2023-11-19 06:50 +0100
                          Re: Why is bullseye-backports recommended on bookworm? Tixy <tixy@yxit.co.uk> - 2023-11-17 15:10 +0100
                            Re: Why is bullseye-backports recommended on bookworm? David Wright <deblis@lionunicorn.co.uk> - 2023-11-18 07:30 +0100
                              Re: Why is bullseye-backports recommended on bookworm? Greg Wooledge <greg@wooledge.org> - 2023-11-18 15:20 +0100
                                Re: Why is bullseye-backports recommended on bookworm? steve <dlist@bluewin.ch> - 2023-11-18 15:40 +0100
                                  Re: Why is bullseye-backports recommended on bookworm? David Wright <deblis@lionunicorn.co.uk> - 2023-11-19 06:50 +0100
                                Re: Why is bullseye-backports recommended on bookworm? Vincent Lefevre <vincent@vinc17.net> - 2023-11-18 23:40 +0100
                                  Re: Why is bullseye-backports recommended on bookworm? David Wright <deblis@lionunicorn.co.uk> - 2023-11-19 06:50 +0100
                                    Re: Why is bullseye-backports recommended on bookworm? Vincent Lefevre <vincent@vinc17.net> - 2023-11-20 11:20 +0100
                                      Re: Why is bullseye-backports recommended on bookworm? David Wright <deblis@lionunicorn.co.uk> - 2023-11-21 04:40 +0100
                      Re: Why is bullseye-backports recommended on bookworm? Vincent Lefevre <vincent@vinc17.net> - 2023-11-16 13:30 +0100
    Re: Why is bullseye-backports recommended on bookworm? Tim Woodall <debianuser@woodall.me.uk> - 2023-11-19 06:00 +0100

Page 1 of 2  [1] 2  Next page →

#263526 — Why is bullseye-backports recommended on bookworm?

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

[toc] | [next] | [standalone]

#263528

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.

[toc] | [prev] | [next] | [standalone]

#263532

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

[toc] | [prev] | [next] | [standalone]

#263538

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.

-- 
Vincent Lefèvre <vincent@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)

[toc] | [prev] | [next] | [standalone]

#263540

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.

[toc] | [prev] | [next] | [standalone]

#263541

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

[toc] | [prev] | [next] | [standalone]

#263545

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.

[toc] | [prev] | [next] | [standalone]

#263552

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

[toc] | [prev] | [next] | [standalone]

#263547

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

[toc] | [prev] | [next] | [standalone]

#263553

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

[toc] | [prev] | [next] | [standalone]

#263551

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

 
 

[toc] | [prev] | [next] | [standalone]

#263554

On 2023-11-15 16:39:15 -0000, Curt wrote:
> On 2023-11-14, Vincent Lefevre <vincent@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?

-- 
Vincent Lefèvre <vincent@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)

[toc] | [prev] | [next] | [standalone]

#263556

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 <vincent@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

[toc] | [prev] | [next] | [standalone]

#263557

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

-- 
Vincent Lefèvre <vincent@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)

[toc] | [prev] | [next] | [standalone]

#263558

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

[toc] | [prev] | [next] | [standalone]

#263588

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 <vincent@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 Lefèvre <vincent@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)

[toc] | [prev] | [next] | [standalone]

#263606

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

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.

[toc] | [prev] | [next] | [standalone]

#263624

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

[toc] | [prev] | [next] | [standalone]

#263638

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.

[toc] | [prev] | [next] | [standalone]

#263672

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web