NEW changes in stable-new
Processing changes file: stellarium_0.11.3-1+deb7u1_mips.changes ACCEPT -- 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/e1vjhj9-0002sw...@franck.debian.org
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 -- 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/522ec796.7090...@debian.org
Fwd: tzdata stable update? Asia/Jerusalem for October 2013
Hi, Per request, an updated tzdata package was uploaded to p-u, and I wish your approval for inclusion in stable. The reason for the upload is the Israe's daylight saving rules have changed (and already in effect since this Sunday). We'd like to provide a fix for this situation with the new version (2013d). Thanks, Kaplan -- Forwarded message -- From: Clint Adams cl...@debian.org Date: Tue, Sep 10, 2013 at 5:54 AM Subject: Re: tzdata stable update? Asia/Jerusalem for October 2013 To: Lior Kaplan kap...@debian.org Cc: debian-gl...@lists.debian.org, Tzafrir Cohen tzaf...@debian.org On Sun, Sep 01, 2013 at 03:25:18PM +0200, Lior Kaplan wrote: There is a recent upcoming change in the Israeli daylight saving law. It has been included upstream and in version 2013d (currenty in Sid and Jessie). Uploaded, please take care of the rest.
Re: Fwd: tzdata stable update? Asia/Jerusalem for October 2013
On 2013-09-10 9:09, Lior Kaplan wrote: Per request, an updated tzdata package was uploaded to p-u, and I wish your approval for inclusion in stable. fwiw, we get notified automatically by our tools about new uploads to p-u; I was expecting tzdata to appear at some point in any case. Is there are a plan for an upload for squeeze? The reason for the upload is the Israes daylight saving rules have changed (and already in effect since this Sunday). Wed like to provide a fix for this situation with the new version (2013d). Are there any other changes worthy of note in the update? See http://lists.debian.org/debian-stable-announce/2012/10/msg0.html for an example announcement mail we've used in the past (I'd be looking at pushing this via wheezy-updates as the Israeli changes are already in place). Regards, Adam -- 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/646f628e110e19cdab6b14f5af256...@mail.adsl.funky-badger.org
Re: Fwd: tzdata stable update? Asia/Jerusalem for October 2013
On Tue, Sep 10, 2013 at 10:42 AM, Adam D. Barratt a...@adam-barratt.org.ukwrote: On 2013-09-10 9:09, Lior Kaplan wrote: Is there are a plan for an upload for squeeze? Would be nice, but we didn't ask for it. Having it in wheezy took long enough (guess the maintainers were busy). But will check where the wind blows about another upload. The reason for the upload is the Israes daylight saving rules have changed (and already in effect since this Sunday). Wed like to provide a fix for this situation with the new version (2013d). The release announcement ( http://mm.icann.org/pipermail/tz-announce/2013-July/12.html) has two issues: Changes affecting future time stamps: Morocco's midsummer transitions this year are July 7 and August 10, not July 9 and August 8. (Thanks to Andrew Paprocki.) Israel now falls back on the last Sunday of October. (Thanks to Ephraim Silverberg.) No idea how important is the 1st one, seems a little minor (but I don't live in Moroco (: ) The Israely change was to extend DST by 6 weeks... so yes it worth a mentioning. Are there any other changes worthy of note in the update? See http://lists.debian.org/**debian-stable-announce/2012/**10/msg0.htmlhttp://lists.debian.org/debian-stable-announce/2012/10/msg0.htmlfor an example announcement mail we've used in the past (I'd be looking at pushing this via wheezy-updates as the Israeli changes are already in place). Regards, Adam
Bug#717418: transition: libudev
Am 09.09.2013 19:32, schrieb Julien Cristau: On Sun, Sep 8, 2013 at 21:56:32 +0200, Julien Cristau wrote: On Fri, Aug 23, 2013 at 09:07:30 +0200, Michael Biebl wrote: With xorg-server being fixed to no longer FTBFS, there is no more blocker for this transition afaics and we should be ready to go. We'd appreciate if we can start this transition as soon as possible, as we need a newer systemd in various other packages (among them GNOME 3.8). Also, updating udev is long overdue. Would be great if we can get an ack from the release team for the unstable upload. ATM this would clash with the libav transition. That one still has a number of build failures unfortunately :( Actually we should be ok. systemd should be able to migrate ahead of libav9 if it's ready, and britney will keep libudev0 around in testing until everything has caught up. How can systemd migrate ahead of time if the source package no longer builds libudev0. Wouldn't that block the testing migration of systemd? Or is this a special case since in testing libudev0 is built from another source package (src:udev)? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#717418: transition: libudev
On Tue, Sep 10, 2013 at 11:16:12 +0200, Michael Biebl wrote: Am 09.09.2013 19:32, schrieb Julien Cristau: On Sun, Sep 8, 2013 at 21:56:32 +0200, Julien Cristau wrote: On Fri, Aug 23, 2013 at 09:07:30 +0200, Michael Biebl wrote: With xorg-server being fixed to no longer FTBFS, there is no more blocker for this transition afaics and we should be ready to go. We'd appreciate if we can start this transition as soon as possible, as we need a newer systemd in various other packages (among them GNOME 3.8). Also, updating udev is long overdue. Would be great if we can get an ack from the release team for the unstable upload. ATM this would clash with the libav transition. That one still has a number of build failures unfortunately :( Actually we should be ok. systemd should be able to migrate ahead of libav9 if it's ready, and britney will keep libudev0 around in testing until everything has caught up. How can systemd migrate ahead of time if the source package no longer builds libudev0. Wouldn't that block the testing migration of systemd? Or is this a special case since in testing libudev0 is built from another source package (src:udev)? britney keeps old libs around in testing if they still have reverse deps. Though I had completely forgotten about the source package name change in this case, which should make this even easier. Cheers, Julien signature.asc Description: Digital signature
NEW changes in stable-new
Processing changes file: tzdata_2013d-0wheezy1_amd64.changes ACCEPT -- 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/e1vjlto-0008nx...@franck.debian.org
Bug#721075: pu: package stellarium/0.11.3-1
On 2013-09-09 14:10, Jonathan Wiltshire wrote: On 2013-09-09 08:01, Adam D. Barratt wrote: On 2013-09-09 7:37, Tomasz Buchert wrote: On 08/09/13 19:59, Adam D. Barratt wrote: Please go ahead; thanks. [...] just to be sure on that: by go ahead you mean that I can upload it? Yes. It was uploaded and I have flagged it for acceptance. It looks like the upload was built in something other than a wheezy chroot: stellarium (= 0.11.3-1+deb7u1): FAILED stellarium (= 0.11.3-1+deb7u1) depends on missing: - libc6 (= 2.15) I've scheduled a binNMU. Please make sure you build uploads for stable in an appropriate environment. Regards, Adam -- 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/88319b83eea615003fadd0221c37c...@mail.adsl.funky-badger.org
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-de...@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) -- 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/522f19f4.6050...@debian.org
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 -- 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/522f2234.30...@eu.citrix.com
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! -- 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/522f27a5.9010...@eu.citrix.com
Bug#717418: [Pkg-systemd-maintainers] Bug#717418: transition: libudev
Hi Julien, Am 10.09.2013 11:27, schrieb Julien Cristau: britney keeps old libs around in testing if they still have reverse deps. Though I had completely forgotten about the source package name change in this case, which should make this even easier. Ok, what does that mean then. Should we still wait for an ACK from the release team or are we good to go? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#718767: transition: ocaml 4.00.1
On 10.09.2013 16:07, Jon Ludlam wrote: 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. We got the xen-api-libs re-uploaded with an ocaml fix (the type-conv change I think I sent Thomas, or could be extracted quite easy from the ubuntu package). With xen-api-libs rebuild, xen-api will also rebuild without change (for xen-4.2). For the xen-4.3 work I did add a patch that updates the paths again. Unfortunately that isn't uploaded yet as xen itself needed to go first and that needed an expection now). I am still waiting to get that sponsored in ubuntu. -Stefan signature.asc Description: OpenPGP digital signature
Bug#718767: transition: ocaml 4.00.1
Hi, 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. Yes, I've already had some brief discussions with Thomas and Stefan about the packages. We're getting quite close to having working xenserver-core packages for Debian (in addition to the current versions for CentOS). I don't think you will want to use those packages directly in Debian, but as a result of trying to build our own Debian packages we have been removing as many of these distribution-specific quirks in the upstream packages as possible which should make packaging easier in future. Thanks, Euan -- 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/20130910153139.ge...@citrix.com
Bug#721075: pu: package stellarium/0.11.3-1
Sorry for that, I didn't know it's necessary... :( It's the first time I backport a package. That won't happen again. :) Tomasz On 10/09/13 12:24, Adam D. Barratt wrote: On 2013-09-09 14:10, Jonathan Wiltshire wrote: On 2013-09-09 08:01, Adam D. Barratt wrote: On 2013-09-09 7:37, Tomasz Buchert wrote: On 08/09/13 19:59, Adam D. Barratt wrote: Please go ahead; thanks. [...] just to be sure on that: by go ahead you mean that I can upload it? Yes. It was uploaded and I have flagged it for acceptance. It looks like the upload was built in something other than a wheezy chroot: stellarium (= 0.11.3-1+deb7u1): FAILED stellarium (= 0.11.3-1+deb7u1) depends on missing: - libc6 (= 2.15) I've scheduled a binNMU. Please make sure you build uploads for stable in an appropriate environment. Regards, Adam -- 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/20130910192234.ga22...@piscopia.math
Bug#715397: pu: package libdatetime-timezone-perl/1.58-1+2013d
On Mon, 2013-07-08 at 21:06 +0200, gregor herrmann wrote: A new release of the tz data (2013d) was made on Friday. I've now uploaded libdatetime-timezone-perl/1:1.60-1+2013d, which contains the OlsonDB 2013d, to unstable, and I've prepared an update for the package in stable as 1.58-1+2013d in git. [...] (And I'm fine with waiting for the tzdata package, or for 1.60-1+2013d to have some exposure before, or whatever the release team deems sensible. I'm also leaving the question of adding the proposed upload to stable-updates completely at the RT's discretion :)) To go with the tzdata SUA, SUA 37-1 was released earlier tonight to cover libdatetime-timezone-perl (https://lists.debian.org/debian-stable-announce/2013/09/msg1.html). Regards, Adam -- 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/1378843786.14702.22.ca...@jacala.jungle.funky-badger.org
Re: Fwd: tzdata stable update? Asia/Jerusalem for October 2013
On Tue, 2013-09-10 at 10:59 +0200, Lior Kaplan wrote: On Tue, Sep 10, 2013 at 10:42 AM, Adam D. Barratt a...@adam-barratt.org.uk wrote: Are there any other changes worthy of note in the update? See http://lists.debian.org/debian-stable-announce/2012/10/msg0.html for an example announcement mail we've used in the past (I'd be looking at pushing this via wheezy-updates as the Israeli changes are already in place). The release announcement (http://mm.icann.org/pipermail/tz-announce/2013-July/12.html) has two issues: Changes affecting future time stamps: Morocco's midsummer transitions this year are July 7 and August 10, not July 9 and August 8. (Thanks to Andrew Paprocki.) Israel now falls back on the last Sunday of October. (Thanks to Ephraim Silverberg.) SUA 36-1 has been released for this (https://lists.debian.org/debian-stable-announce/2013/09/msg0.html). Regards, Adam -- 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/1378843742.14702.21.ca...@jacala.jungle.funky-badger.org
NEW changes in stable-new
Processing changes file: stellarium_0.11.3-1+deb7u1+b1_amd64.changes ACCEPT -- 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/e1vjtfs-00055c...@franck.debian.org
