Stéphane Glondu
2013-Sep-10 07:17 UTC
[Pkg-xen-devel] Bug#710650: Bug#718767: transition: ocaml 4.00.1
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
Thomas Goirand
2013-Sep-10 13:09 UTC
[Pkg-xen-devel] Bug#710650: Bug#718767: transition: ocaml 4.00.1
On 09/10/2013 03:17 PM, St?phane Glondu wrote:> 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.Well, I agree, and upstream agrees as well. There's an ongoing work to have this happen.> 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.Right. Though the month of August isn't the best time for things to move on, as people go in holidays, go in Debconf, and so on... :)>> 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.Yes, it should have. Though it's not as easy as it sounds in your wording, and this work was done by upstream. I have no time for doing the work myself.>> 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.I'm currently removing the xcp-plugins from Nova. As for the list of packages, it's rather easy, they are all listed here: http://qa.debian.org/developer.php?login=pkg-xen-devel at lists.alioth.debian.org (of course, that doesn't include the "xen" package which is the hypervisor which is also listed) Cheers, Thomas Goirand (zigo)
Jon Ludlam
2013-Sep-10 13:44 UTC
[Pkg-xen-devel] Bug#710650: Bug#718767: transition: ocaml 4.00.1
On 10/09/13 14:09, Thomas Goirand wrote:> On 09/10/2013 03:17 PM, St?phane Glondu wrote: >> 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. > Well, I agree, and upstream agrees as well. There's an ongoing work to > have this happen. >Certainly we do :-) There is indeed ongoing work, but it's not yet in a state to be able to be uploaded. However, fixing the xenguest compile problem looks fairly straightforward - I can try and provide a patch for that today. Would that help? As for becoming more upstream-friendly, there are now several of us working to make that happen. Euan Harris is working hard on actually creating packages from this work, though the shape of these packages is quite different from that of the old-style 1.3.2 packages. We should start a conversation on pkg-xen-devel to make sure what he's doing is acceptable to you guys. Jon
Jon Ludlam
2013-Sep-10 14:07 UTC
[Pkg-xen-devel] Bug#710650: Bug#718767: transition: ocaml 4.00.1
Hmm, I'm not having much success in replicating the build environment for this - however, I did notice two patches in the ubuntu xen-api package that look relevant. The build failure appears to be related to xenguest, and there is a patch 'xenguest-4.2.patch' which looks worth a test. Also, I noticed another patch 'fix-xen-4.2-paths.patch' that might be relevant. Thomas, could you try these patches? If they don't work, perhaps you could (off list) advise me on how to set up the environment for building. Thanks!