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