Pkg xen devel - Dec 2020 - Bug#976597: Xen Python dependencies are not specific enough

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:
> > If you're running Debian testing with Xen, then expect the change
to
> > arrive on your system in a few days. When using HVM, don't rush
and pull
> > the packages from unstable, since qemu still needs a rebuild to depend
> > on libxen-4.14 instead of libxen-4.11 (more about that later...).
> 
> That's the case here, running on bullseye/testing.
> 
> > -- Help testing! --
> > 
> > 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?

Greets
Alex

-- 
/"\ ASCII RIBBON | »With the first link, the chain is forged. The first
\ / CAMPAIGN     | speech censured, the first thought forbidden, the
 X  AGAINST      | first freedom denied, chains us all irrevocably.«
/ \ HTML MAIL    | (Jean-Luc Picard, quoting Judge Aaron Satie)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20201205/5dadf16d/attachment.sig>

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

Control: tags -1 + patch
Control: block -1 980303

I implemented a fix for this issue in [1], however this is currently blocked 
due to a bug in dh_python.

[1]
https://salsa.debian.org/myx/debian-xen/-/commits/myx/fix_python_dependencies
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL:
<http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20210117/8d89b047/attachment.sig>

Processing control commands:
> tags -1 + patch
Bug #976597 [src:xen] Xen Python dependencies are not specific enough
Added tag(s) patch.
> block -1 980303
Unknown command or malformed arguments to command.


-- 
976597: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976597
Debian Bug Tracking System
Contact owner at bugs.debian.org with problems