Package: src:xen Version: 4.14.0+80-gd101b417b7-1 Severity: normal There is indeed something wrong that should be fixed. Creating a Debian bug for it now.
tl;dr Currently Xen package needs Python 3.9 as default /usr/bin/python3 but the Xen packages went unstable->testing while testing has 3.8 as default, causing pygrub to fail to find and import xenfsimage.cpython-39-x86_64-linux-gnu.so. On 12/5/20 10:43 AM, Alexander Dahl wrote: > Hello, > > FTR, we found what seems to be the problem in IRC yesterday, see > below. > > On Thu, Dec 03, 2020 at 10:56:12PM +0100, Alexander Dahl wrote: >> On Tue, Nov 24, 2020 at 05:41:42PM +0100, Hans van Kranenburg wrote: >>> [...] >>> >>> Any help with testing is appreciated, especially since there are so many >>> combinations of hardware, different architectures and use cases (using >>> legacy BIOS or EFI, PV, PVH, HVM, different boot loaders like pvgrub, >>> pygrub, etc etc). >> >> x86_64 host here, and some old 32 bit virtual machines, no weird >> network or hardware pass through setup, rather simple. HVM and pvgrub >> based DomU VMs run fine so far. pygrub based VMs, both 32 bit and 64 >> bit fail with the following error: >> >> Traceback (most recent call last): >> File "/usr/lib/xen-4.14/bin/pygrub", line 27, in <module> >> import xenfsimage >> ModuleNotFoundError: No module named 'xenfsimage' > > Testing has python 3.8 as default at the moment, while unstable > already has 3.9. The file packaged for testing however is > 'xenfsimage.cpython-39-x86_64-linux-gnu.so' but that seems to be for > python 3.9, not for 3.8. When starting pygrub manually with python3.9 > that error goes away, but I suppose that would not work from within > the xen config, or does it? I have not dived further into this yet, but I can think of the following TODO items, if anyone wants to help with research and fixing (yes please): * Look at the build logs (buildd logs are linked from the PTS), and try to understand why in Xen 4.11 (with Python 2) we just have fsimage.so but with 4.14 and Python 3 we have this more specific longer name with cpython-39-x86_64-linux-gnu in it. * Figure out what we need to do to make a python dependency more specific, so that the xen packages would have been blocked from the transition to testing as long as python3-defaults in testing is not pointing to the needed version. Maybe there's something to be found in the Debian Python Policy? https://www.debian.org/doc/packaging-manuals/python-policy/ Or, maybe if it's not super obvious we can ask some python packaging IRC or mailing list or otherwise debian-devel@ for help. Hans
