Pkg xen devel - May 2017 - Bug#862236: Xen jessie testing

Control: severity -1 important

(adding the bug, and my work hat, to the CC)

Moritz M?hlenhoff writes ("Re: Xen jessie
testing"):
> On Thu, May 11, 2017 at 11:04:21AM +0200, Axel Beckert wrote:
> > Moritz M?hlenhoff wrote:
> > > Ian's upload was built on i386, while the previous ones were
built
> > > on amd64.
I built it on i386 because then it would produce packages I could at
least do some kind of test of it on my system at home.  We could
rebuild it on amd64 and issue another update.  However, I think if
something was going to break it would have done already.
> The severity seems exaggarated, though. If that's really relying
> on the build architecture, this would have been broken on i386
> all the time until the DSA. And while i386 is arguably not a good
> choice to run Xen, I still think this would have been noticed earlier
> if it were a severe issue.
The only place this seems to be used is to prepend it to
the LD_LIBRARY_PATH in force during execution of the hotplug scripts.

This is inherited from upstream, where it is needed (I think) so that
in non-packaged builds of Xen, on non-Debian systems, the Xen
libraries in /usr/local are found when trying to execute the Xen tools
inside the hotplug scripts.

Our dynamic linker is clever enough to ignore irrelevant files, so I
think this is largely harmless.  Of course the noise in /etc ought to
be got rid of.

I think this should be fixed by not dropping this setting (and
probably the consequent LD_LIBRARY_PATH too).  Ideally via some kind
of upstream knob but if not by a Debian patch.

I think such a change is buster material.  For now, I suggest that I
continue to build security updates for jessie on i386 as I am able to
conveniently test that.

If I need to do another update to stretch (eg, a security update)
before its release, I will simply drop this line from this file.

Does that plan seem good ?  Obviously, feel free to try to convince me
that this is RC for stretch.  I wouldn't want to let this slide if
it's going to cause real trouble.

Thanks,
Ian.

Ian Jackson writes ("Re: Xen jessie testing"):
> I think this should be fixed by not dropping this setting (and
                         ^^^^^^^^^^^^^^^^^^^^^

Too many negatives.  I meant that the setting should be dropped.

Ian.

On Thu, May 11, 2017 at 11:00:30AM +0100, Ian Jackson
wrote:
> I think such a change is buster material.  For now, I suggest that I
> continue to build security updates for jessie on i386 as I am able to
> conveniently test that.
I agree.

Cheers,
        Moritz

On Thu, 11 May 2017 11:00:30 +0100 Ian Jackson
<ijackson at chiark.greenend.org.uk> wrote:
> [...]
> 
> The only place this seems to be used is to prepend it to
> the LD_LIBRARY_PATH in force during execution of the hotplug scripts.
> 
> This is inherited from upstream, where it is needed (I think) so that
> in non-packaged builds of Xen, on non-Debian systems, the Xen
> libraries in /usr/local are found when trying to execute the Xen tools
> inside the hotplug scripts.
> 
> Our dynamic linker is clever enough to ignore irrelevant files, so I
> think this is largely harmless.  Of course the noise in /etc ought to
> be got rid of.
[...reordered...]
> I think such a change is buster material.  For now, I suggest that I
> continue to build security updates for jessie on i386 as I am able to
> conveniently test that.
> [...]
> Obviously, feel free to try to convince me
> that this is RC for stretch.  I wouldn't want to let this slide if
> it's going to cause real trouble.
You are probably right: if it would have broken something, you'd have
gotten more reports by now.  So your conclusion sounds fine to me.
> I think this should be fixed by not dropping this setting (and
> probably the consequent LD_LIBRARY_PATH too).  Ideally via some kind
> of upstream knob but if not by a Debian patch.
> If I need to do another update to stretch (eg, a security update)
> before its release, I will simply drop this line from this file.
> 
> Does that plan seem good ?
Yes.

Thanks for looking into this!

cheers,
Stefan