Pkg xen devel - Sep 2013 - Bug#710650: Bug#718767: transition: ocaml 4.00.1

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

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,
>    ^
> [...]
On the other hand, there is a new upstream release (upstream version is
1.6 and unstable version is 1.3.2). 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.

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.

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.


Cheers,

-- 
St?phane

06.09.2013 10:42, St?phane Glondu write:
[]
> Now, xen-api FTBFS because of what looks like an API change in some (C)
> dependency:
[]
> On the other hand, there is a new upstream release (upstream version is
> 1.6 and unstable version is 1.3.2). 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.
>
> 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.
The situation with xen-api, as far as I can see from my non-maintainer
not xen-related view - is quite a bit difficult.

The upstream is very much redhat-specific, and they "ported" the
previous
version "to debian", which required quite some work.  I don't know
the
details there, but I looked briefly at the git diff between "redhat"
and "deboan" versions - it was quite large and didn't end up just
replacing /usr/libexec/ into /usr/lib/ and the like.

Now, it looks like similar "porting" effort is needed to
"port" the
new upstream version.  Which no one want to do, apparently... ;)

That's the reason - again, as far as I can see - why the inactivity
is happening.

I tried to do something with it because xen-api stops qemu migration
and users are asking about it quite often.  But I don't know anything
about either xen or ocaml or other related stuff, and especially
with this "porting" stuff, it looks like I'm not the right
candidate
to sort it out.
> 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.
I'd vote for the same, but again, I'm not a user of any of these,
so it's easy for me... ;)

Thanks,

/mjt

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)

On Fri, Sep  6, 2013 at 08:42:29 +0200, St?phane Glondu wrote:
> 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.
> 
> 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.
> 
I'd rather not remove nova.  One option would be to temporarily disable
its xen bits though.

Cheers,
Julien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL:
<http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130906/1d695d6f/attachment.sig>

Le 06/09/2013 10:14, Thomas Goirand a ?crit :
> 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").
That is not the way it should work. Upstream version should not be
specific to either Debian or CentOS. There should be only one version,
and it is the job of each distribution (yours, here) to do the
specialization work. If you can't, then arrange for its removal from
testing.
> 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.
There are reverse-dependencies so it cannot be easily removed from
testing. And this situation IS blocking other people's work. And has
been for (at least) one month.
> No, the package isn't neglected. It's simply more complicated than
it
> seems. I'm currently dealing with upstream about it.
While doing so, please make sure future versions are trivial to port to
Debian. It should have been done during the initial packaging.
> 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.
Then, could you give the list of packages that should be removed from
testing? Remember, testing should be self-contained, so it means remove
all reverse dependencies as well.
>> 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.
guest-templates build-depends on libxenapi-ocaml-dev, which is built by
xen-api.
> I hope the above helps,
And nothing has changed since...


Cheers,

-- 
St?phane

Le 06/09/2013 10:14, Thomas Goirand a ?crit :
> 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.
More than two weeks later, xen-api is still in testing, and preventing
the start of the OCaml transition.

If I remove all binary packages of xen-api from testing, the following
new packages are broken: xcp-guest-templates, nova-xcp-plugins,
nova-compute-xen.

xcp-guest-templates is built by guest-templates which seems to be a leaf
package and could be removed from testing.

On the other hand, both nova-* packages are built by nova which Julien
wants to keep in testing. The last changelog entry advertises the
removal of nova-xcp-plugins, but it is still there.

Thomas, could you please upload a new nova without nova-xcp-plugins and
nova-compute-xen?


Cheers,

-- 
St?phane