Bug#1111903:
On 2025-12-11 14:43, Roman Lebedev wrote: > Looking at /usr/share/perl5/Debian/DistroInfo.pm, > there's relevant 'created' and 'release' fields with dates > for each codename, so in principle one could > just hardcode the last bad(first good?) distro > and compare the dates. > Not sure if i'm pointing out something that was already obvious. I guess something like that would be doable, though I'm not confident enough to propose it as the current solution is pretty good and trivial, and changing this IMO would add complexity to address all but irrelevant edge cases. My reluctance stems from similar "older distro" issues in autopkgtest, the handling of which really adds some complexity in total. Best, Christian
Bug#1111903:
On Thu, Dec 11, 2025 at 4:28 PM Christian Kastner wrote: > > On 2025-12-11 14:10, Roman Lebedev wrote: > > I'm not at all convinced that detecting ubuntu mirror > > by matching for ubuntu in domain name makes any sense. > > There's plenty of mirrors that contain that substring in URI > > and not in domain name. > > The substring test is on the full URI, not just the domain name. Ok, apologies. I was under impression that it was about the domain name only. > > Why can't the DistroInfo approach be used? > > DistroInfo can tell you whether it's a Debian or Ubuntu release, but it > can't (AFAICT) tell you whether codename X is older than codename Y, > which is one of the problems we are facing here. Looking at /usr/share/perl5/Debian/DistroInfo.pm, there's relevant 'created' and 'release' fields with dates for each codename, so in principle one could just hardcode the last bad(first good?) distro and compare the dates. Not sure if i'm pointing out something that was already obvious. > > Why can't the detection be codename-based? > > That's what I meant below, with the hard-coded approach. > > >> If you want to go ahead, search for "jessie" in autopkgtest-build-qemu > >> and see that there is already a hard-coded list for older releases in > >> there. It would probably be the easiest to just follow that, for the > >> older releases. autopkgtest depends on python3-distro-info but I didn't > >> see a ranking/sorting function there. > Best, > Christian Thank you. Roman.
Bug#1111903:
On 2025-12-11 14:10, Roman Lebedev wrote: > I'm not at all convinced that detecting ubuntu mirror > by matching for ubuntu in domain name makes any sense. > There's plenty of mirrors that contain that substring in URI > and not in domain name. The substring test is on the full URI, not just the domain name. > Why can't the DistroInfo approach be used? DistroInfo can tell you whether it's a Debian or Ubuntu release, but it can't (AFAICT) tell you whether codename X is older than codename Y, which is one of the problems we are facing here. > Why can't the detection be codename-based? That's what I meant below, with the hard-coded approach. >> If you want to go ahead, search for "jessie" in autopkgtest-build-qemu >> and see that there is already a hard-coded list for older releases in >> there. It would probably be the easiest to just follow that, for the >> older releases. autopkgtest depends on python3-distro-info but I didn't >> see a ranking/sorting function there. Best, Christian
Bug#1111903:
On Thu, Dec 11, 2025 at 11:47 AM Christian Kastner wrote: > > Hi, > > On 2025-12-10 10:29, Johannes Schauer Marin Rodrigues wrote: > > Quoting Christian Kastner (2025-12-10 09:35:26) > >> On 2025-12-10 09:24, Johannes Schauer Marin Rodrigues wrote: > I guess for bullseye+ and the equivalent in Ubuntu, linux-image-generic > could > be proposed? Would you like to do this, or would you prefer I do it? > >>> > >>> Proposed? You mean to autopkgtest itself? > >> Yes. If I understood one of your earlier mails correctly, you'd like to > >> have this aligned (which of course makes sense). > > > > Please go ahead and feel free to cc me if you like. > I didn't manage to get to this yesterday, but taking a look today I > don't feel confident enough to propose a change on my behalf. > > First, there is a bit of work involved, namely determining which Ubuntu > and Debian codenames first supported linux-image-generic. > > For all that didn't, we'd fall back to the previous logic, which we'd > have to keep around until those distros stop being supported. > This is all fair and good of course, except that I believe the very > simple heuristic we discussed yesterday is already good enough. Yes, it > produces a few false negatives, but it feels a bit wrong to me to add > code just to accommodate a handful of mirrors that can't spell "ubuntu" > correctly. I'm not at all convinced that detecting ubuntu mirror by matching for ubuntu in domain name makes any sense. There's plenty of mirrors that contain that substring in URI and not in domain name. Why can't the DistroInfo approach be used? Why can't the detection be codename-based? > If you want to go ahead, search for "jessie" in autopkgtest-build-qemu > and see that there is already a hard-coded list for older releases in > there. It would probably be the easiest to just follow that, for the > older releases. autopkgtest depends on python3-distro-info but I didn't > see a ranking/sorting function there. > > Best, > Christian Thank you! Roman.
Bug#1111903:
Hi, On 2025-12-10 10:29, Johannes Schauer Marin Rodrigues wrote: > Quoting Christian Kastner (2025-12-10 09:35:26) >> On 2025-12-10 09:24, Johannes Schauer Marin Rodrigues wrote: I guess for bullseye+ and the equivalent in Ubuntu, linux-image-generic could be proposed? Would you like to do this, or would you prefer I do it? >>> >>> Proposed? You mean to autopkgtest itself? >> Yes. If I understood one of your earlier mails correctly, you'd like to >> have this aligned (which of course makes sense). > > Please go ahead and feel free to cc me if you like. I didn't manage to get to this yesterday, but taking a look today I don't feel confident enough to propose a change on my behalf. First, there is a bit of work involved, namely determining which Ubuntu and Debian codenames first supported linux-image-generic. For all that didn't, we'd fall back to the previous logic, which we'd have to keep around until those distros stop being supported. This is all fair and good of course, except that I believe the very simple heuristic we discussed yesterday is already good enough. Yes, it produces a few false negatives, but it feels a bit wrong to me to add code just to accommodate a handful of mirrors that can't spell "ubuntu" correctly. If you want to go ahead, search for "jessie" in autopkgtest-build-qemu and see that there is already a hard-coded list for older releases in there. It would probably be the easiest to just follow that, for the older releases. autopkgtest depends on python3-distro-info but I didn't see a ranking/sorting function there. Best, Christian
Bug#1111903:
Quoting Christian Kastner (2025-12-10 09:35:26) > On 2025-12-10 09:24, Johannes Schauer Marin Rodrigues wrote: > >> I guess for bullseye+ and the equivalent in Ubuntu, linux-image-generic > >> could > >> be proposed? Would you like to do this, or would you prefer I do it? > > > > Proposed? You mean to autopkgtest itself? > Yes. If I understood one of your earlier mails correctly, you'd like to > have this aligned (which of course makes sense). Please go ahead and feel free to cc me if you like. I have a full day of lectures today so it will be a bit until I get to do it myself. Thank you for taking care of it! cheers, josch signature.asc Description: signature
Bug#1111903:
On 2025-12-10 09:24, Johannes Schauer Marin Rodrigues wrote: >> I guess for bullseye+ and the equivalent in Ubuntu, linux-image-generic could >> be proposed? Would you like to do this, or would you prefer I do it? > > Proposed? You mean to autopkgtest itself? Yes. If I understood one of your earlier mails correctly, you'd like to have this aligned (which of course makes sense). LG Christian
Bug#1111903:
Hi, Quoting Christian Kastner (2025-12-10 08:55:05) > On 2025-12-10 01:53, Johannes Schauer Marin Rodrigues wrote: > > On Debian, linux-image-generic is a virtual package provided by the > > architecture-specific meta-packages like linux-image-arm64. On Ubuntu, > > linux-image-generic is a meta-package which then depends on, for example > > linux-image-6.17.0-5-generic which is the same package that would've been > > pulled in by installing linux-image-virtual. > > > > Is there a reason to use the Ubuntu-specific linux-image-virtual if > > linux-image-generic which seems to work for both distros seems to do the > > same > > thing? > I wasn't aware that both Ubuntu and Debian both had linux-image-generic. > It looks as if this would indeed simplify things. > > However autopkgtest aims to support releases going far back, and at > least stretch doesn't have linux-image-generic yet. I couldn't check > buster because I've stumbled into image problems; bullseye seems to have it. > > I guess for bullseye+ and the equivalent in Ubuntu, linux-image-generic could > be proposed? Would you like to do this, or would you prefer I do it? Proposed? You mean to autopkgtest itself? There is prior art for using linux-image-generic in debvm: https://sources.debian.org/src/debvm/0.5.0/share/debvm/customize-kernel.sh#L111 Thanks! cheers, josch signature.asc Description: signature
Bug#1111903:
Good morning, On 2025-12-10 01:53, Johannes Schauer Marin Rodrigues wrote: > On Debian, linux-image-generic is a virtual package provided by the > architecture-specific meta-packages like linux-image-arm64. On Ubuntu, > linux-image-generic is a meta-package which then depends on, for example > linux-image-6.17.0-5-generic which is the same package that would've been > pulled in by installing linux-image-virtual. > > Is there a reason to use the Ubuntu-specific linux-image-virtual if > linux-image-generic which seems to work for both distros seems to do the same > thing? I wasn't aware that both Ubuntu and Debian both had linux-image-generic. It looks as if this would indeed simplify things. However autopkgtest aims to support releases going far back, and at least stretch doesn't have linux-image-generic yet. I couldn't check buster because I've stumbled into image problems; bullseye seems to have it. I guess for bullseye+ and the equivalent in Ubuntu, linux-image-generic could be proposed? Would you like to do this, or would you prefer I do it? Best, Christian
Bug#1111903:
Hi, Quoting Roman Lebedev (2025-12-10 01:23:50) > > how would it be able to do that? All we have at that point is the user > > arguments. > Looking at /usr/share/perl5/Debian/DistroInfo.pm, i think you'd want to call > `UbuntuDistroInfo::new()->valid(codename)`. ah by going through the release name rather than the mirror address. Yes, that is also what mmdebstrap does to find a mirror for the desired release. That loglic already exists. Quoting Christian Kastner (2025-12-10 01:16:49) > If an exact solution is the goal, one approach might be to rely on RELEASE > and see if debootstrap's /usr/share/debootstrap/scripts can be used to map to > Ubuntu. And mentioned logic does exactly that already: https://sources.debian.org/src/mmdebstrap/1.5.7-3/mmdebstrap#L5197 > > There is also another option: convince Debian kernel maintainers to add > > linux-image-virtual to their list of meta-packages and let it depend on the > > right meta-package depending on the architecture. Then both > > autopkgtest-virt-qemu as well as mmdebstrap-autopkgtest-build-qemu could > > simplify their code and just depend on linux-image-virtual. > > Yes, please! I've filed such an issue before: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1116120 Talking about meta-packages there might be another option. How about instead of depending on linux-image-virtual, we let it depend on linux-image-generic. On Debian, linux-image-generic is a virtual package provided by the architecture-specific meta-packages like linux-image-arm64. On Ubuntu, linux-image-generic is a meta-package which then depends on, for example linux-image-6.17.0-5-generic which is the same package that would've been pulled in by installing linux-image-virtual. Is there a reason to use the Ubuntu-specific linux-image-virtual if linux-image-generic which seems to work for both distros seems to do the same thing? Thanks! cheers, josch signature.asc Description: signature
Bug#1111903:
On Wed, Dec 10, 2025 at 3:01 AM Johannes Schauer Marin Rodrigues wrote: > > Hi, > > Quoting Roman Lebedev (2025-12-10 00:36:05) > > There's https://packages.debian.org/sid/libdistro-info-perl > > Should it be used to detect which distro it is? > > how would it be able to do that? All we have at that point is the user > arguments. Looking at /usr/share/perl5/Debian/DistroInfo.pm, i think you'd want to call `UbuntuDistroInfo::new()->valid(codename)`. > And another question that I forgot to ask: is the ubuntu kernel named the same > independent of the architecture? > > Quoting Christian Kastner (2025-12-10 00:37:50) > > A cursory examination of the URIs all have "ubuntu" somewhere in their > > name, so the check would return true > > Not true. There is https://mirror.famaserver.com/archive/ or > https://mirror.maeen.sa/apt-mirror/ There are also "mis-spelling" of ubuntu > like rsync://mirror.flokinet.net/ubntu/ and there are spellings with the first > letter upper-case http://mirrors.arpnetworks.com/Ubuntu/ > > > Though not impossible, I think it very unlikely that there will be many > > false > > positives, ie: a non-Ubuntu URI would containing "ubuntu". > > The test has both false positives and false negatives. It's a bad test. It is > maybe a good heuristic but if one adds a heuristic to software, then one must > also add a way to override it. > There is also another option: convince Debian kernel maintainers to add > linux-image-virtual to their list of meta-packages and let it depend on the > right meta-package depending on the architecture. Then both > autopkgtest-virt-qemu as well as mmdebstrap-autopkgtest-build-qemu could > simplify their code and just depend on linux-image-virtual. Yes, please! I've filed such an issue before: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1116120 > Thanks! > > cheers, josch Roman.
Bug#1111903:
On 2025-12-10 01:01, Johannes Schauer Marin Rodrigues wrote: > Quoting Christian Kastner (2025-12-10 00:37:50) >> A cursory examination of the URIs all have "ubuntu" somewhere in their >> name, so the check would return true > > Not true. There is https://mirror.famaserver.com/archive/ or > https://mirror.maeen.sa/apt-mirror/ There are also "mis-spelling" of ubuntu > like rsync://mirror.flokinet.net/ubntu/ and there are spellings with the first > letter upper-case http://mirrors.arpnetworks.com/Ubuntu/ Hence "cursory" :) >> Though not impossible, I think it very unlikely that there will be many false >> positives, ie: a non-Ubuntu URI would containing "ubuntu". > > The test has both false positives and false negatives. It's a bad test. Sure, it's not perfect, but it's better than not working at all. The heuristic seemed good enough at first glance, and autopkgtest-build-qemu seems to have dealt well with it over time, hence why I proposed simply carrying over the code. > There is also another option: convince Debian kernel maintainers to add > linux-image-virtual to their list of meta-packages and let it depend on the > right meta-package depending on the architecture. Then both > autopkgtest-virt-qemu as well as mmdebstrap-autopkgtest-build-qemu could > simplify their code and just depend on linux-image-virtual. I guess this could be raised with the Kernel Team, though I suspect it might take a bit of convincing. If an exact solution is the goal, one approach might be to rely on RELEASE and see if debootstrap's /usr/share/debootstrap/scripts can be used to map to Ubuntu. Best, Christian
Bug#1111903:
Hi, Quoting Roman Lebedev (2025-12-10 00:36:05) > There's https://packages.debian.org/sid/libdistro-info-perl > Should it be used to detect which distro it is? how would it be able to do that? All we have at that point is the user arguments. And another question that I forgot to ask: is the ubuntu kernel named the same independent of the architecture? Quoting Christian Kastner (2025-12-10 00:37:50) > A cursory examination of the URIs all have "ubuntu" somewhere in their > name, so the check would return true Not true. There is https://mirror.famaserver.com/archive/ or https://mirror.maeen.sa/apt-mirror/ There are also "mis-spelling" of ubuntu like rsync://mirror.flokinet.net/ubntu/ and there are spellings with the first letter upper-case http://mirrors.arpnetworks.com/Ubuntu/ > Though not impossible, I think it very unlikely that there will be many false > positives, ie: a non-Ubuntu URI would containing "ubuntu". The test has both false positives and false negatives. It's a bad test. It is maybe a good heuristic but if one adds a heuristic to software, then one must also add a way to override it. There is also another option: convince Debian kernel maintainers to add linux-image-virtual to their list of meta-packages and let it depend on the right meta-package depending on the architecture. Then both autopkgtest-virt-qemu as well as mmdebstrap-autopkgtest-build-qemu could simplify their code and just depend on linux-image-virtual. Thanks! cheers, josch signature.asc Description: signature
Bug#1111903:
There's https://packages.debian.org/sid/libdistro-info-perl Should it be used to detect which distro it is? Roman. On Wed, Dec 10, 2025 at 2:21 AM Johannes Schauer Marin Rodrigues wrote: > > Hi, > > Quoting Roman Lebedev (2025-12-09 14:25:26) > > Also hitting this issue. > > Would be awesome if this could be merged. > > I'm not happy with how autopkgtest-build-qemu checks for ubuntu just by the > string "ubuntu" appearing anywhere in the mirror URL. > > Can you confirm that the following regex would match commonly used official > ubuntu mirrors? > > echo $MIRROR | grep "^https\\?://[^/]\\+\\.ubuntu\\.com/" > > I can file a merge request against autopkgtest-build-qemu to update their > check > accordingly. I assume it was only done the way it is done out of laziness. > > Thanks! > > cheers, josch
Bug#1111903:
Hi Josch, On 2025-12-10 00:21, Johannes Schauer Marin Rodrigues wrote: > Quoting Roman Lebedev (2025-12-09 14:25:26) > I'm not happy with how autopkgtest-build-qemu checks for ubuntu just by the > string "ubuntu" appearing anywhere in the mirror URL. > > Can you confirm that the following regex would match commonly used official > ubuntu mirrors? > > echo $MIRROR | grep "^https\\?://[^/]\\+\\.ubuntu\\.com/" I'm don't have much experience with Ubuntu, but at first glance, that would only match the canonical names of the mirrors. The official list [1] has a bunch of mirror URIs from 600+ other sites, which would not get recognized by this. > I can file a merge request against autopkgtest-build-qemu to update their > check > accordingly. I assume it was only done the way it is done out of laziness. That might have been a factor, but I suspect the above list might have been the dominant one. A cursory examination of the URIs all have "ubuntu" somewhere in their name, so the check would return true positives. Though not impossible, I think it very unlikely that there will be many false positives, ie: a non-Ubuntu URI would containing "ubuntu". Best, Christian [1]: https://launchpad.net/ubuntu/+archivemirrors
Bug#1111903:
Hi, Quoting Roman Lebedev (2025-12-09 14:25:26) > Also hitting this issue. > Would be awesome if this could be merged. I'm not happy with how autopkgtest-build-qemu checks for ubuntu just by the string "ubuntu" appearing anywhere in the mirror URL. Can you confirm that the following regex would match commonly used official ubuntu mirrors? echo $MIRROR | grep "^https\\?://[^/]\\+\\.ubuntu\\.com/" I can file a merge request against autopkgtest-build-qemu to update their check accordingly. I assume it was only done the way it is done out of laziness. Thanks! cheers, josch signature.asc Description: signature
Bug#1111903:
Also hitting this issue. Would be awesome if this could be merged. Roman.
Bug#1111903: mmdebstrap-autopkgtest-build-qemu: Install the right kernel on Ubuntu
Package: mmdebstrap
Version: 1.5.7-1
Severity: normal
Tags: patch
Dear Maintainer,
mmdebstrap-autopkgtest-build-qemu fails for Ubuntu releases because the
kernel package is called differently there.
The attached patch matches the solution that autopkgtest-build-qemu uses.
Best,
Christian
-- System Information:
Debian Release: 13.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.41+deb13-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages mmdebstrap depends on:
ii apt 3.0.3
ii perl 5.40.1-6
ii python3 3.13.5-1
Versions of packages mmdebstrap recommends:
ii arch-test0.22-1
ii gpg 2.4.7-21+b3
ii libdistro-info-perl 1.13
ii libdpkg-perl 1.22.21
ii mount2.41-5
ii uidmap 1:4.17.4-2
Versions of packages mmdebstrap suggests:
pn apt-transport-tor
ii apt-utils 3.0.3
ii bzip2 1.0.8-6
ii ca-certificates 20250419
ii debootstrap 1.0.141
ii distro-info-data0.66
ii dpkg-dev1.22.21
ii e2fsprogs 1.47.2-3+b3
pn fakechroot
ii fakeroot1.37.1.1-1
pn genext2fs
ii libarchive13t64 [libarchive13] 3.7.4-4
pn lz4
ii lzop1.04-2
pn ncompress
pn perl-doc
ii qemu-user 1:10.0.2+ds-2+deb13u1
pn qemu-user-static
pn squashfs-tools-ng
ii systemd 257.7-1
ii xz-utils5.8.1-1
ii zstd1.5.7+dfsg-1
-- no debconf informationFrom 728065589efab4436631b6497dedd2456b98597f Mon Sep 17 00:00:00 2001
From: Christian Kastner
Date: Sat, 23 Aug 2025 15:57:33 +0200
Subject: [PATCH] mm-a-b-q: Install the right kernel on Ubuntu
Ubuntu uses linux-image-virtual across all architectures.
The test for "ubuntu" in the mirror URI is crude, but matches what
autopkgtest-build-qemu does.
---
mmdebstrap-autopkgtest-build-qemu | 4
1 file changed, 4 insertions(+)
diff --git a/mmdebstrap-autopkgtest-build-qemu b/mmdebstrap-autopkgtest-build-qemu
index bb7bce0..f90125a 100755
--- a/mmdebstrap-autopkgtest-build-qemu
+++ b/mmdebstrap-autopkgtest-build-qemu
@@ -286,6 +286,10 @@ case "$ARCHITECTURE" in
die "unsupported architecture: $ARCHITECTURE"
;;
esac
+# Ubuntu uses the same settings as above, except for the kernel
+if echo "$MIRROR" | grep -q "ubuntu"; then
+ LINUXIMAGE=linux-image-virtual
+fi
if test "$(dpkg-query -f '${db:Status-Status}' -W binutils-multiarch)" = installed; then
GNU_PREFIX=
--
2.47.2
