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. IDK if this
should have its own deb. Putting it in the libxenstore one is
probably tolerable. Hans, I know you know there's a problem here.
I haven't investigated what happens with that patch reverted, yet.
* 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 ?
* 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...)
* 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>
--
Ian Jackson <ijackson at chiark.greenend.org.uk> These opinions are my
own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
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> > >
Hans van Kranenburg writes ("Re: Plans for
buster"):> On 08/23/2018 07:12 PM, Ian Jackson wrote:
> > 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?
Mmm, quite possibly. libxenbasic mabye ?
There's an awkwardness that its version will have to change when the
soname of *ether* xenstore *or* toolcore change.
> > 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.
You mean at the package level ? libxenstore ought not to - see above.
I don't understand the message at the shlibs level. I think it is
probably that libxentoolcore isn't installed. But it may be due to
the soname being wrong.
> > * 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. ;]
Awkward since we still don't have it in experimental. Maybe we should
use Salsa for short term things and the BTS for things that we expect
will remain open for longer ?
Ian.