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) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52298ee7.5010...@debian.org
