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

Also hitting this issue.
Would be awesome if this could be merged.

Roman.

Hi,

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

There's https://packages.debian.org/sid/libdistro-info-perl
Should it be used to detect which distro it is?

Roman.

Hi Josch,

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.

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

Hi,

Quoting Roman Lebedev (2025-12-10 00:36:05)
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)

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

Hence "cursory" :)

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.

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

Looking at /usr/share/perl5/Debian/DistroInfo.pm,
i think you'd want to call
`UbuntuDistroInfo::new()->valid(codename)`.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1116120

Roman.

Hi,

Quoting Roman Lebedev (2025-12-10 01:23:50)

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)

And mentioned logic does exactly that already:

https://sources.debian.org/src/mmdebstrap/1.5.7-3/mmdebstrap#L5197

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

Good morning,
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

Hi,

Quoting Christian Kastner (2025-12-10 08:55:05)

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

Yes. If I understood one of your earlier mails correctly, you'd like to
have this aligned (which of course makes sense).

LG
Christian

Quoting Christian Kastner (2025-12-10 09:35:26)

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

Hi,
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

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?

Thank you!

Roman.

The substring test is on the full URI, not just the domain name.

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.

That's what I meant below, with the hard-coded approach.
Best,
Christian

Ok, apologies. I was under impression that it was about the domain name only.

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.

Thank you.

Roman.

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