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
