Bug#842919: transition: xen (vs. grub2) [and 1 more messages]
Debian FTP Masters writes: > Accepted: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Format: 1.8 > Date: Sat, 05 Nov 2016 15:08:47 + > Source: xen > Binary: libxen-4.8 libxenstore3.0 libxen-dev xenstore-utils xen-utils-common > xen-utils-4.8 xen-hypervisor-4.8-amd64 xen-system-amd64 > xen-hypervisor-4.8-arm64 xen-system-arm64 xen-hypervisor-4.8-armhf > xen-system-armhf > Architecture: all amd64 source > Version: 4.8.0~rc3-1 Emilio Pozuelo Monfort writes: > I don't plan to binNMU any package that doesn't depend on > libxen-4.6. IOW, only qemu and libvirt will be rebuilt. Please go ahead (unless it needs to wait for xen itself to clear the buildd queues). (There are no sourceful uploads needed for this transition.) Thanks, Ian. -- Ian JacksonThese 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.
Bug#842919: transition: xen (vs. grub2)
On 05/11/16 15:40, Colin Watson wrote: > In any case, I don't think grub2 needs to be rebuilt for this > transition. I don't plan to binNMU any package that doesn't depend on libxen-4.6. IOW, only qemu and libvirt will be rebuilt. Cheers, Emilio
Bug#842919: transition: xen (vs. grub2)
On 05/11/16 18:32, Colin Watson wrote: > On Sat, Nov 05, 2016 at 02:40:45PM +, Colin Watson wrote: >> It appears that upstream took a copy a little while back (upstream >> commit e07badcc31babb24ace4f96444bc484502427d3a), but I didn't notice >> this when preparing packages of 2.02~beta3. I'll test whether the >> package still builds correctly without libxen-dev and if so I'll upload >> without that build-dependency. > > Indeed it doesn't, so I've committed that change to git. On reflection > I think it isn't terribly urgent to upload just for this? No rush, it can wait for when you have more important changes. But thanks for checking it! Cheers, Emilio
Bug#842919: transition: xen (vs. grub2)
On Sat, Nov 05, 2016 at 02:40:45PM +, Colin Watson wrote: > It appears that upstream took a copy a little while back (upstream > commit e07badcc31babb24ace4f96444bc484502427d3a), but I didn't notice > this when preparing packages of 2.02~beta3. I'll test whether the > package still builds correctly without libxen-dev and if so I'll upload > without that build-dependency. Indeed it doesn't, so I've committed that change to git. On reflection I think it isn't terribly urgent to upload just for this? -- Colin Watson [cjwat...@debian.org]
Bug#842919: transition: xen (vs. grub2)
On Fri, Nov 04, 2016 at 12:25:39AM +, Ian Jackson wrote: > Hi, grub2 maintainers. I'm CCing you into this conversation in the > hope you can help explain the semantics of the grub2 package's > build-dependency on libxen-dev. [Technically you CCed grub@p.d.o rather than grub2@p.d.o, but no matter. CC corrected.] > I don't know why grub2 Build-Depends libxen-dev. None of the binaries > in my test-rebuild end up Depending on libxen-4.8. > > Perhaps the B-D is just because it needs a copy of the Xen public > headers for the hypervisor API. This is correct. > I doubt it statically links against > libxen* libraries, but I don't think I can entirely rule it out. Indeed, it doesn't. All the Xen interaction is in freestanding boot code that has no legitimate reason to link against the userspace libraries. > grub-xen-bin contains grub compiled for the Xen PV environment: that > is, to run directly under Xen as part of a guest startup. It will > need header files describing the Xen public ABI. These are the "Xen > public headers", and because of Xen's ABI compatibility guarantees the > normal upstream recommendation is to actually copy those into the > trees of projects which are building binaries to run on Xen. (So for > example Linux has its own - modified - copies.) It appears that upstream took a copy a little while back (upstream commit e07badcc31babb24ace4f96444bc484502427d3a), but I didn't notice this when preparing packages of 2.02~beta3. I'll test whether the package still builds correctly without libxen-dev and if so I'll upload without that build-dependency. In any case, I don't think grub2 needs to be rebuilt for this transition. Thanks, -- Colin Watson [cjwat...@debian.org]
Bug#842919: transition: xen (vs. grub2)
Colin Watson writes ("Re: Bug#842919: transition: xen (vs. grub2)"):
> In any case, I don't think grub2 needs to be rebuilt for this
> transition.
Noted, thanks.
Ian.
--
Ian JacksonThese 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.
Bug#842919: transition: xen (vs. grub2)
Hi, grub2 maintainers. I'm CCing you into this conversation in the
hope you can help explain the semantics of the grub2 package's
build-dependency on libxen-dev.
I will quote the whole transition mail:
Emilio Pozuelo Monfort writes ("Re: Bug#842919: transition: xen"):
> On 02/11/16 11:47, Ian Jackson wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> >
> > Hi. This is the update from Xen 4.6 to Xen 4.8, as previously
> > discussed. (Currently, Xen 4.8.0 RC3. I expect the Xen 4.8.0 release
> > to be out by the time Debian freezes.)
> >
> > libxen-* contains libraries needed for management tools. The
> > corresponding xen-utils-* packages are intended to be coinstallable,
> > so perhaps a "smooth" transition may still be possible ? (Contrary to
> > what the autogenerated transition tracker thinks.)
> >
> > All that is needed from the build-rdeps is a rebuild. That is, of:
> > libvirt qemu xenwatch python-pyxenstore collectd grub2
> >
> > I have checked that they all build against the new libxen{-4.8,-dev},
> > at least on amd64. I don't anticipate trouble on other architectures.
>
> The ben tracker only lists qemu and libvirt as rdeps of the binaries
> that are removed in the new version. Why do the other packages need
> a rebuild? Do any of them statically link libxen or something?
(Emilio will see that I discussed other the packages in another mail.
Also, I am somewhat full of wine right now, so my answers may be
wrong. It seemed better to reply sooner. My work hat can produce
more sober replues tomorrow. Regarding grub2:)
I don't know why grub2 Build-Depends libxen-dev. None of the binaries
in my test-rebuild end up Depending on libxen-4.8.
Perhaps the B-D is just because it needs a copy of the Xen public
headers for the hypervisor API. I doubt it statically links against
libxen* libraries, but I don't think I can entirely rule it out.
There is a binary grub-xen-bin which is probably relevant.
grub-xen-bin contains grub compiled for the Xen PV environment: that
is, to run directly under Xen as part of a guest startup. It will
need header files describing the Xen public ABI. These are the "Xen
public headers", and because of Xen's ABI compatibility guarantees the
normal upstream recommendation is to actually copy those into the
trees of projects which are building binaries to run on Xen. (So for
example Linux has its own - modified - copies.)
If this is the only reason why grub2 Build-Depends libxen-dev then
there is no need to rebuild grub2.
It seems unlikely to me that grub2 could somehow statically link
actual libxen-dev library code (and statically embed it into a grub
binary), but perhaps I'm just not being imaginative enough.
And I guess it is possible that grub2 has some other function which
somehow embeds pieces from libxen-dev.
I hope the grub2 maintainers will be able to shed some light.
Thanks,
Ian.
--
Ian JacksonThese 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.
.
