[Pkg-xen-devel] Bug#710650: Bug#718767: transition: ocaml 4.00.1

[Thomas Goirand]

On 09/06/2013 02:42 PM, Stéphane Glondu wrote:
> Le 05/09/2013 23:18, Julien Cristau a écrit :
>> tracker adjusted.  xen-api is currently broken though, so you'll need to
>> get that fixed before starting.
> 
> I've just fixed a blocking bug (#713349) which was due to the renaming
> of an OCaml library (type-conv -> type_conv).

Hi,

I had a patch from upstream that he gave me a few days ago about it, and
thought I would work on it. Thanks for your upload though.


> Now, xen-api FTBFS because of what looks like an API change in some (C)
> dependency:
>
>> [...]
>> + gcc -g -O2 -DCOMPILE_NATIVE -I/usr/lib/ocaml -I/usr/include -I. -c -o xenguest_stubs.o xenguest_stubs.c
>> In file included from xenguest_stubs.c:24:0:
>> /usr/include/xs.h:1:2: warning: #warning xs.h is deprecated use xenstore.h instead [-Wcpp]
>>  #warning xs.h is deprecated use xenstore.h instead
>>   ^
>> xenguest_stubs.c: In function 'dispatch_suspend':
>> xenguest_stubs.c:197:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
>>   int domid = (int) arg;
>>               ^
>> xenguest_stubs.c: In function 'hvm_build_set_params':
>> xenguest_stubs.c:360:8: error: 'struct hvm_info_table' has no member named 'acpi_enabled'
>>   va_hvm->acpi_enabled = f.acpi;
>>         ^
>> xenguest_stubs.c: At top level:
>> xenguest_stubs.c:470:3: warning: initialization from incompatible pointer type [enabled by default]
>>    .postcopy = switch_qemu_logdirty,
>>    ^
>> [...]

Upstream from Citrix is preparing a new version of XCP, and Xen 4.3 has
just been uploaded. So probably it will be solved "soon". I wasn't
supposed to announce it, so don't consider this as an announcement, just
be aware that we're working on it.

> On the other hand, there is a new upstream release (upstream version is
> 1.6 and unstable version is 1.3.2).

I wrote it many time to many people. Please don't just read 1.6 as "new
upstream release" for XCP. That's unfortunately not the way it works.
Upstream version for Debian and the one they do for CentOS are
different, and just using upstream 1.6 doesn't cut it. It needs to be
ported to Debian, and that's far from a trivial work (as Michael Tokarev
wrote, it's not "just replacing /usr/libexec/ into /usr/lib/ and the like").

However, as I wrote it, it's going to happen, so please be patient about
it. IMO, this shouldn't block any transition though. If the release team
is reading: just let everything transition to testing, and remove the
old version of XCP 1.3.2 in testing if that helps, plus add some
blocking bugs so that the rest of Debian isn't affected by the (not
finished) work on XCP 1.6 for Debian.

> It doesn't make sense to me to
> invest time in this without updating the package, which goes beyond the
> scope of an NMU. Fixing #713349 was already borderline since there is
> also a new upstream release there... but it was easy.

Indeed.

> The FTBFS bug has been reported in June. I told some of the maintainers
> (in-person, in CC) to update this package during debconf. No activity
> since them. IMHO, this package is neglected and should be removed from
> testing.

No, the package isn't neglected. It's simply more complicated than it
seems. I'm currently dealing with upstream about it.

I by the way don't mind if 1.3.2 is removed from testing, as we will
need to package the next version anyway.

> There are a few reverse-dependencies, but they all look somehow
> connected: nova, guest-templates, xcp-*... My take would be to remove
> (from testing) all of them.

The problem for Nova is different. It's depending on sqlalchemy-migrate
(python-migrate in Debian), which is blocked by Alembic, AFAIK. As for
guest-templates, I don't see why it is affected.

I hope the above helps,

Cheers,

Thomas Goirand (zigo)