[Pkg-xen-devel] Plans for buster

[Hans van Kranenburg]

On 08/23/2018 07:12 PM, Ian Jackson wrote:
> Hans van Kranenburg writes ("Re: Plans for buster"):
>> This can be done from tag debian/4.11.1_pre+1.733450b39b-1_exp1 (which
>> is right now the same as the master branch).
> 
> Thanks for doing all this work.  I have just sent it to experimental.
> 
> I did some reviewing and diffing.  I have some comments, or, at least,
> things I noticed.  None of them were IMO blockers for experimental.
> Hence the upload.  (But I think some of them are blockers for sid.)
> 
> * libxtoolcore has the wrong soname.  Upstream it is 1.

Aha.

>  IDK if this
>   should have its own deb.  Putting it in the libxenstore one is
>   probably tolerable.

Yes, shipping a 4.x specific file in libxenstore3.0 (which happens now)
is not right. But, if the library ABI is independent from the 4.x
versions, then it can be done.

When starting to add more things which are not libxenstore3.0 to the
libxenstore3.0 package, shouldn't we find a different name for that
binary package that covers the content better?

>  Hans, I know you know there's a problem here.
>   I haven't investigated what happens with that patch reverted, yet.

This happens:
https://salsa.debian.org/xen-team/debian-xen/issues/8#note_39872

I guess that this is because libxenstore3.0 does not depend on libxen-4.x.

> * I don't understand why all the Linux module API stuff is needed.
>   Xen does not have modules.  So VERSION_UPSTREAM, VERSION_BINNMU,
>   etc., are maybe not needed ?

That is probably cruft yes.

> * The patch to reintroduce xs_restrict should go upstream.  I think
>   that, upstream, it would be a backport candidate, thus meaning
>   Debian wouldn't have to carry it.  (And I'm a tools maintainer and a
>   stable maintainer upstream, so my initial opinion is fairly
>   predictive...)

How do you want to track such TODO items? Because now we have 1) the bts
and 2) salsa issues and 3) things mentioned somewhere in emails. ;]

> * I don't think renaming the patches was particularly helpful.  It
>   generates noise in diffs.  (But please don't rename them back.)
> 
> * I noticed this in debian/rules:
>      SHELL := sh -e
>   Does that actually work ?  Colour me surprised.  I wonder why it
>   isn't done more widely.
> 
> * There were a bunch of complaints from lintian.
> 
> * I followed the instructions in debian/README.source.md and
>   my first attempt to build a source package failed [1].  Using
>      dpkg-buildpackage -uc -ui -us -B
>   instead worked.  This should be documented in README.source.md.
>   If we don't change the whole git workflow; I'm afraid I'm going
>   to reopen that, but that'll be a separate message.
> 
> Thanks,
> Ian
> 
> [1]
> zealot:xen> dpkg-source -b .
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: error: unwanted binary file: debian/lib/python/debian_linux/__pycache__/gencontrol.cpython-35.pyc
> dpkg-source: error: unwanted binary file: debian/lib/python/debian_linux/__pycache__/utils.cpython-35.pyc
> dpkg-source: error: unwanted binary file: debian/lib/python/debian_linux/__pycache__/__init__.cpython-35.pyc
> dpkg-source: error: unwanted binary file: debian/lib/python/debian_linux/__pycache__/debian.cpython-35.pyc
> dpkg-source: error: unwanted binary file: debian/lib/python/debian_linux/__pycache__/config.cpython-35.pyc
> dpkg-source: error: unwanted binary file: debian/lib/python/debian_xen/__pycache__/__init__.cpython-35.pyc
> dpkg-source: error: unwanted binary file: debian/lib/python/debian_xen/__pycache__/debian.cpython-35.pyc
> dpkg-source: error: detected 7 unwanted binary files (add them in debian/source/include-binaries to allow their inclusion).
> zealot:xen> 
> 
>