Pkg xen devel - Oct 2018 - Entirely new Xen packaging [and 1 more messages]

I have now finished totally rewriting the Xen package in Debian, from
scratch.  Amazingly as soon as I got a package which was lintian-clean
and would install, it worked first time !

I have generated 18 patches to go upstream which I have sent to
xen-devel.  There are two more, xenstore ABI patches, which need a bit
of tidying up.

There is still room for improvement but it is now clearly ready for
sharing so I uploaded it.  The result is now in dgit/dgit/sid, and
salsa/master.

I do not know if it builds other than on amd64.  I hope so, because I
have stripped out a lot of cruft.  If there are build failures we will
have to fix them.

Debian FTP Masters writes
("xen_4.11.1~pre.20180911.5acdd26fdc+dfsg-1~exp1_multi.changes ACCEPTED
into experimental, experimental"):
>  xen (4.11.1~pre.20180911.5acdd26fdc+dfsg-1~exp1) experimental;
urgency=medium
>  .
>    * Update to new upstream version 4.11.1~pre.20180911.5acdd26fdc+dfsg.
>    * Remove stubdom/grub.patches/00cvs from the upstream source because
it's
>      not DFSG compliant. (license-problem-gfdl-invariants)
>    * Override statically-linked-binary lintian error about
>      usr/lib/xen-4.11/boot/xen-shim
I accidentally dropped these changes from my fisrt upload to sid.  I
noticed when I tried to push to salsa/master and discovered my branch
wasn't ff.  Hooray for git.

So I have fixed that by rebasing onto the dfsg upstreamk tag and
followed it up with a 2nd upload.  So please don't be alarmed by noise
from the archive.

Ian.

-- 
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 10/05/2018 08:04 PM, Ian Jackson wrote:
> I have now finished totally rewriting the Xen package in Debian, from
> scratch.  Amazingly as soon as I got a package which was lintian-clean
> and would install, it worked first time !
\:D/ Congrats!
> I have generated 18 patches to go upstream which I have sent to
> xen-devel.  There are two more, xenstore ABI patches, which need a bit
> of tidying up.
> 
> There is still room for improvement but it is now clearly ready for
> sharing so I uploaded it.  The result is now in dgit/dgit/sid, and
> salsa/master.
This is an amazing amount of improvements, really nice!

I've spent last hour looking around, and did build packages for stretch.
I'm going to install them probably tomorrow.

The comments about why things are in a certain place (like, in rules)
are really helpful.
> I do not know if it builds other than on amd64.  I hope so, because I
> have stripped out a lot of cruft.  If there are build failures we will
> have to fix them.
> 
> Debian FTP Masters writes
("xen_4.11.1~pre.20180911.5acdd26fdc+dfsg-1~exp1_multi.changes ACCEPTED
into experimental, experimental"):
>>  xen (4.11.1~pre.20180911.5acdd26fdc+dfsg-1~exp1) experimental;
urgency=medium
>>  .
>>    * Update to new upstream version
4.11.1~pre.20180911.5acdd26fdc+dfsg.
>>    * Remove stubdom/grub.patches/00cvs from the upstream source because
it's
>>      not DFSG compliant. (license-problem-gfdl-invariants)
>>    * Override statically-linked-binary lintian error about
>>      usr/lib/xen-4.11/boot/xen-shim
> 
> I accidentally dropped these changes from my fisrt upload to sid.  I
> noticed when I tried to push to salsa/master and discovered my branch
> wasn't ff.  Hooray for git.
> 
> So I have fixed that by rebasing onto the dfsg upstreamk tag and
> followed it up with a 2nd upload.  So please don't be alarmed by noise
> from the archive.
Ah, that's probably because I started working on that during the UK
visit, while you started working on this. :)

I plan to work on this project on tuesday (2nd tuesday of the month!),
finally processing my notes, updating TODO-list stuff and doing a few of
them.

o/
Hans

This is awesome!  What needs to be done before this can make it to
unstable?  I’d love to help if there’s anything I can do.

Stephen

On Fri, Oct 5, 2018 at 8:00 PM Hans van Kranenburg <hans at knorrie.org>
wrote:
> On 10/05/2018 08:04 PM, Ian Jackson wrote:
> > I have now finished totally rewriting the Xen package in Debian, from
> > scratch.  Amazingly as soon as I got a package which was lintian-clean
> > and would install, it worked first time !
>
> \:D/ Congrats!
>
> > I have generated 18 patches to go upstream which I have sent to
> > xen-devel.  There are two more, xenstore ABI patches, which need a bit
> > of tidying up.
> >
> > There is still room for improvement but it is now clearly ready for
> > sharing so I uploaded it.  The result is now in dgit/dgit/sid, and
> > salsa/master.
>
> This is an amazing amount of improvements, really nice!
>
> I've spent last hour looking around, and did build packages for
stretch.
> I'm going to install them probably tomorrow.
>
> The comments about why things are in a certain place (like, in rules)
> are really helpful.
>
> > I do not know if it builds other than on amd64.  I hope so, because I
> > have stripped out a lot of cruft.  If there are build failures we will
> > have to fix them.
> >
> > Debian FTP Masters writes
> ("xen_4.11.1~pre.20180911.5acdd26fdc+dfsg-1~exp1_multi.changes
ACCEPTED
> into experimental, experimental"):
> >>  xen (4.11.1~pre.20180911.5acdd26fdc+dfsg-1~exp1) experimental;
> urgency=medium
> >>  .
> >>    * Update to new upstream version
4.11.1~pre.20180911.5acdd26fdc+dfsg.
> >>    * Remove stubdom/grub.patches/00cvs from the upstream source
because
> it's
> >>      not DFSG compliant. (license-problem-gfdl-invariants)
> >>    * Override statically-linked-binary lintian error about
> >>      usr/lib/xen-4.11/boot/xen-shim
> >
> > I accidentally dropped these changes from my fisrt upload to sid.  I
> > noticed when I tried to push to salsa/master and discovered my branch
> > wasn't ff.  Hooray for git.
> >
> > So I have fixed that by rebasing onto the dfsg upstreamk tag and
> > followed it up with a 2nd upload.  So please don't be alarmed by
noise
> > from the archive.
>
> Ah, that's probably because I started working on that during the UK
> visit, while you started working on this. :)
>
> I plan to work on this project on tuesday (2nd tuesday of the month!),
> finally processing my notes, updating TODO-list stuff and doing a few of
> them.
>
> o/
> Hans
>
>
> _______________________________________________
> Pkg-xen-devel mailing list
> Pkg-xen-devel at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-xen-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/pkg-xen-devel/attachments/20181005/994b4af6/attachment-0001.html>

On 10/05/2018 08:04 PM, Ian Jackson wrote:
> [...]
> 
> There is still room for improvement but it is now clearly ready for
> sharing so I uploaded it.  The result is now in dgit/dgit/sid, and
> salsa/master.
Jumping ahead of the buster todo-list... One thing I've been wondering
about...

How does the new package play together with qemu in Debian? How far are
we now away from being able to do buster-backports without qemu problems
for whoever wants to use HVM with backports?
>From the discussion last month at Citrix I understood that qemu could
likely be changed to depend on one or more of the stable library
packages instead of libxenmisc4.y (or, libxen-4.y, including all of it now).

Also, does that mean there need to be more libxen<blaat>-dev packages,
or not?

K

Hans van Kranenburg writes ("Re: Entirely new Xen
packaging"):
> On 10/05/2018 08:04 PM, Ian Jackson wrote:
> > There is still room for improvement but it is now clearly ready for
> > sharing so I uploaded it.  The result is now in dgit/dgit/sid, and
> > salsa/master.
> 
> This is an amazing amount of improvements, really nice!
Great, thanks for the kind words.
> I've spent last hour looking around, and did build packages for
stretch.
> I'm going to install them probably tomorrow.
Any idea about the i386/armhf/arm64 builds ?  (I don't want to upload
anything else while this one sits in NEW.)
> I plan to work on this project on tuesday (2nd tuesday of the month!),
> finally processing my notes, updating TODO-list stuff and doing a few of
> them.
:-).  That's tomorrow.

I think you should push whatever improvements to salsa/master and we
can upload it when the current version is through NEW.

Hans van Kranenburg writes ("Re: Entirely new Xen
packaging"):
> How does the new package play together with qemu in Debian? How far are
> we now away from being able to do buster-backports without qemu problems
> for whoever wants to use HVM with backports?
xen.git is supposed to be decoupled from the qemu version.  I see no
reason why it wouldn't work.  (In fact, don't tell anyone, but I
tested by upload with builds on stretch because the most convenient
test box was running stretch.)
> From the discussion last month at Citrix I understood that qemu could
> likely be changed to depend on one or more of the stable library
> packages instead of libxenmisc4.y (or, libxen-4.y, including all of it
now).
I didn't test a qemu *build*.  But the qemu build-deps will be the
same because I didn't change the dev package.  The binary deps of the
resulting qemu will be different but the shlibdeps machinery will
handle it all.
> Also, does that mean there need to be more libxen<blaat>-dev
packages,
> or not?
No, we want only one libxen-dev package.

I'm currently messing about with the libxenstore and libfsimage
patches to try to make them upstreamable.

Ian.

-- 
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.