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

[Hans van Kranenburg]

On 10/08/2018 06:36 PM, Ian Jackson wrote:
> 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.)

No, unfortunately peanut butter. :|

What about doing some kind of call-for-signs-of-life in places to find
out if those are used, and who is using them? It would seem quite useful
to have those users on the mailing list and see if there's any of them
who would like to help testing packages.

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

I'll probably put it in a branch and ask you to review.

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

Aha! I think I start to understand how this works.

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

Hans