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