Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
Hi, On Wed, 06 Feb 2013, Bdale Garbee wrote: > two at a time. Holding d-i's build dependencies static in unstable for > more than half a year is just nuts to me! Sure seems like d-i is > something we should build using the components of the release it will be > contained in and not unstable... but I haven't tried to think hard about > what that might imply that's problematic. And I certainly don't think > this is something we should even consider changing at this late date in > for wheezy release cycle! Technically d-i point release updates are built in "stable-proposed-updates" and build dependencies are satisfied in stable (+ s-p-u maybe). Similarly it should be possible to build d-i for wheezy in testing-proposed-updates right now (and have build-deps satisfied in wheezy). t-p-u is frowned upon for normal packages because the release team like the testing packages get in unstable, but in the case of d-i the only thing that needs to be tested are the installer images which end up on the mirror and not in the package repository (the installer directories are shared between wheezy and sid). That said this was never done yet and we're not sure what dak would do with the by-hand archive containing the installer images. Maybe some ftpmasters could answer on this point? I discussed this with Cyril and Julien and they were (rightfully IMO) not keen on trying this at this point of the release. That said this whole discussion is interesting and might even help up in the long term but the real problem is that Daniel is just actively working against the release team wishes and this is unacceptable to me. We all know the limitations of our processes, any help to improve them is welcome, but working against them is not acceptable. But judging the social behaviour of a developer is not really in the realm of the tech-ctte and the best technical outcome might not be in line with the release team's plans. Thus I would subject to word a resolution along the line of "The tech-ctte suggests the release team to try out because , but if the release team doesn't wish to try it out, then the release team has the right to upload an older version of syslinux to unstable (given that the maintainer deliberately ignored recommendations of the release team).". Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20130207083122.ga11...@x230-buxy.home.ouaza.com
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 07.02.2013 08:31, Raphael Hertzog wrote: Technically d-i point release updates are built in "stable-proposed-updates" and build dependencies are satisfied in stable (+ s-p-u maybe). Similarly it should be possible to build d-i for wheezy in testing-proposed-updates right now (and have build-deps satisfied in wheezy). For reference, it would also require an otherwise no-op upload of the debian-installer package to unstable, to ensure that testing <= unstable. t-p-u is frowned upon for normal packages because the release team like the testing packages get in unstable, but in the case of d-i the only thing that needs to be tested are the installer images which end up on the mirror and not in the package repository (the installer directories are shared between wheezy and sid). I believe they once were shared; that's no longer the case - to the extent that there's a "dak copy-installer" command to migrate the non-package elements. 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/fdf81293a6165c5d51397bb855d29...@mail.adsl.funky-badger.org
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
On Thu, 07 Feb 2013, Raphael Hertzog wrote: > on the mirror and not in the package repository (the installer directories > are shared between wheezy and sid). Cyril pointed out to me that this specific point is wrong, while wheezy/main/installer-* and unstable/main/installer-* have the same content right now, they are not the same (and thus not shared). There's a "dak copy-installer" involved to copy the installer from unstable to wheezy. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20130207092243.ga12...@x230-buxy.home.ouaza.com
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 02/07/2013 09:31, Raphael Hertzog wrote: > Technically d-i point release updates are built in > "stable-proposed-updates" and build dependencies are satisfied in stable > (+ s-p-u maybe). Similarly it should be possible to build d-i for wheezy > in testing-proposed-updates right now (and have build-deps satisfied in > wheezy). t-p-u is frowned upon for normal packages because the release > team like the testing packages get in unstable, but in the case of d-i the > only thing that needs to be tested are the installer images which end up > on the mirror and not in the package repository (the installer directories > are shared between wheezy and sid). > > That said this was never done yet and we're not sure what dak > would do with the by-hand archive containing the installer images. Maybe > some ftpmasters could answer on this point? Uploading d-i images to wheezy (or t-p-u) should work as far as dak is concerned. They should end in t-p-u and could be copied from there to wheezy (dak copy-installer), similar to stable updates. However I'm not sure if this has ever been tested and the RC images of d-i might not be the best time to try. I also spotted a bug when uploads would go to t-p-u instead of wheezy in the .changes (which should be fixed now)... As Adam already pointed out we would still need another d-i upload to unstable to make sure unstable has a higher-or-equal version compared to testing. Ansgar -- 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/511374cc.1090...@debian.org
Bug#699385: unblock: package quantum/2012.1-5 [pre-approval]
Hi Jonathan Now the files are uploaded. Thanks for your help. // Ola Uploading to ftp-master (via ftp to ftp.upload.debian.org): Uploading quantum_2012.1-5+deb70u1.dsc: done. Uploading quantum_2012.1-5+deb70u1.debian.tar.gz: done. Uploading quantum-server_2012.1-5+deb70u1_all.deb: done. Uploading quantum-plugin-cisco_2012.1-5+deb70u1_all.deb: done. Uploading quantum-plugin-openvswitch_2012.1-5+deb70u1_all.deb: done. Uploading quantum-plugin-sample_2012.1-5+deb70u1_all.deb: done. Uploading quantum-plugin-nicira_2012.1-5+deb70u1_all.deb: done. Uploading quantum-plugin-linuxbridge_2012.1-5+deb70u1_all.deb: done. Uploading quantum-plugin-openvswitch-agent_2012.1-5+deb70u1_all.deb: done. Uploading quantum-plugin-linuxbridge-agent_2012.1-5+deb70u1_all.deb: done. Uploading python-quantum_2012.1-5+deb70u1_all.deb: done. Uploading quantum_2012.1-5+deb70u1_i386.changes: done. On Sat, Feb 02, 2013 at 10:56:05PM +, Jonathan Wiltshire wrote: > On Sat, Feb 02, 2013 at 10:31:06PM +, Jonathan Wiltshire wrote: > > > -Original Message- > > > From: "Adam D. Barratt" > > > To: Ola Lundqvist , 699...@bugs.debian.org > > > Sent: ons, 30 jan 2013 21:53 > > > Subject: Re: Bug#699385: pu: package quantum/2012.1-5 > > > > > > user release.debian@packages.debian.org > > > usertags 699385 = unblock > > > retitle 699385 unblock: quantum/2012.1-5 [pre-approval] > > > severity 699385 normal > > > thanks > > > > > > On Wed, 2013-01-30 at 21:44 +0100, Ola Lundqvist wrote: > > > > Please note! This is a TESTING proposed update request. Not a > > > > stable proposed update request. The reason for this is explained below. > > > > You can go ahead with this upload to tpu but please use version > > 2012.1-5+deb70u1. Please ping this bug when it's uploaded. > > My mistake, that should be deb7u1. > > -- > Jonathan Wiltshire j...@debian.org > Debian Developer http://people.debian.org/~jmw > > 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 > > i have six years of solaris sysadmin experience, from > 8->10. i am well qualified to say it is made from bonghits > layered on top of bonghits -- --- Inguza Technology AB --- MSc in Information Technology / o...@inguza.comAnnebergsslingan 37\ | o...@debian.org 654 65 KARLSTAD| | http://inguza.com/Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- 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/20130207095004.ga28...@inguza.net
Bug#700006: Fix for bug #699906: python-django-horizon: "Launch from volume" broken
Package: release.debian.org
Severity: normal
Hi,
I would like to upload a fix for:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699906
The diff file is attached. If the release team thinks it is suitable for
Wheezy, please let me know, and I will upload, rename this bug and tag
accordingly.
Cheers,
Thomas Goirand (zigo)
diff -Nru horizon-2012.1.1/debian/changelog horizon-2012.1.1/debian/changelog
--- horizon-2012.1.1/debian/changelog 2012-11-18 23:10:33.0 +0800
+++ horizon-2012.1.1/debian/changelog 2013-02-07 17:59:58.0 +0800
@@ -1,3 +1,10 @@
+horizon (2012.1.1-10) unstable; urgency=low
+
+ * Added patch: Launch from volume with valid volume size. Thanks to Julien
+Cristau for reporting (Closes: 699906).
+
+ -- Thomas Goirand Thu, 07 Feb 2013 17:50:55 +0800
+
horizon (2012.1.1-9) unstable; urgency=high
* Re-uploading with urgency=high.
diff -Nru horizon-2012.1.1/debian/patches/launch-from-volume-with-valid-volume-size.patch horizon-2012.1.1/debian/patches/launch-from-volume-with-valid-volume-size.patch
--- horizon-2012.1.1/debian/patches/launch-from-volume-with-valid-volume-size.patch 1970-01-01 08:00:00.0 +0800
+++ horizon-2012.1.1/debian/patches/launch-from-volume-with-valid-volume-size.patch 2013-02-07 17:59:58.0 +0800
@@ -0,0 +1,72 @@
+Description: Launch from volume with valid volume size
+Author: Sascha Peilicke
+Origin: upstream, https://review.openstack.org/gitweb?p=openstack/horizon.git;a=patch;h=fd2291bd28a5a4331d9a7baf961c76effd17b85a
+Bug-Debian: http://bugs.debian.org/699906
+Bug-Ubuntu: https://launchpad.net/bugs/1047568
+Date: 2012-10-18
+
+diff --git a/AUTHORS b/AUTHORS
+index 4110431..677253f 100644
+--- a/AUTHORS
b/AUTHORS
+@@ -41,6 +41,7 @@ Monty Taylor
+ Neil Johnston
+ Paul McMillan
+ Sam Morrison
++Sascha Peilicke
+ Stephane Angot
+ termie
+ Thierry Carrez
+diff --git a/horizon/dashboards/nova/images_and_snapshots/images/forms.py b/horizon/dashboards/nova/images_and_snapshots/images/forms.py
+index bc4851d..a6cdbad 100644
+--- a/horizon/dashboards/nova/images_and_snapshots/images/forms.py
b/horizon/dashboards/nova/images_and_snapshots/images/forms.py
+@@ -164,7 +164,7 @@ class LaunchForm(forms.SelfHandlingForm):
+ else:
+ delete_on_terminate = 0
+ dev_mapping = {data['device_name']:
+-("%s::%s" % (data['volume'], delete_on_terminate))}
++("%s:%s" % (data['volume'], delete_on_terminate))}
+ else:
+ dev_mapping = None
+
+diff --git a/horizon/dashboards/nova/images_and_snapshots/images/tests.py b/horizon/dashboards/nova/images_and_snapshots/images/tests.py
+index aa02325..3615288 100644
+--- a/horizon/dashboards/nova/images_and_snapshots/images/tests.py
b/horizon/dashboards/nova/images_and_snapshots/images/tests.py
+@@ -118,8 +118,8 @@ class ImageViewTests(test.TestCase):
+ sec_group = self.security_groups.first()
+ USER_DATA = 'user data'
+ device_name = u'vda'
+-volume_choice = "%s:vol" % volume.id
+-block_device_mapping = {device_name: u"%s::0" % volume_choice}
++volume_choice = "%s:vol:%s" % (volume.id, volume.size)
++block_device_mapping = {device_name: u"%s:0" % volume_choice}
+
+ self.mox.StubOutWithMock(api, 'image_get_meta')
+ self.mox.StubOutWithMock(api, 'flavor_list')
+@@ -269,7 +269,7 @@ class ImageViewTests(test.TestCase):
+ sec_group = self.security_groups.first()
+ USER_DATA = 'user data'
+ device_name = u'vda'
+-volume_choice = "%s:vol" % volume.id
++volume_choice = "%s:vol:%s" % (volume.id, volume.size)
+
+ self.mox.StubOutWithMock(api, 'image_get_meta')
+ self.mox.StubOutWithMock(api, 'flavor_list')
+diff --git a/horizon/dashboards/nova/images_and_snapshots/images/views.py b/horizon/dashboards/nova/images_and_snapshots/images/views.py
+index 1803f97..0b6ec5c 100644
+--- a/horizon/dashboards/nova/images_and_snapshots/images/views.py
b/horizon/dashboards/nova/images_and_snapshots/images/views.py
+@@ -117,7 +117,7 @@ class LaunchView(forms.ModalFormView):
+ else:
+ vol_type = "vol"
+ visible_label = _("Volume")
+-return (("%s:%s" % (volume.id, vol_type)),
++return (("%s:%s:%s" % (volume.id, vol_type, volume.size)),
+ ("%s - %s GB (%s)" % (volume.display_name,
+ volume.size,
+ visible_label)))
+--
+1.7.9.5
+
diff -Nru horizon-2012.1.1/debian/patches/series horizon-2012.1.1/debian/patches/series
--- horizon-2012.1.1/debian/patches/series 2012-11-18 23:10:33.0 +0800
+++ horizon-2012.1.1/debian/patches/series 2013-02-07 17:59:58.0 +0800
@@ -1,2 +1,3 @@
CVE-2012-3540_disallow_login_redirect_other_than_same_origin.patch
keyerror-688254.patch
+launch-from-v
Fixing "lucky 13" CVE-2013-0169 in gnutls28
Hello, sadly CVE-2013-0169 also (see 699891) applies to gnutls28. I have just uploaded gnutls28_3.0.22-3 to unstable, pretty much with the same set of fixes as gnutls26 2.12.20-4 to unstable. I am not sure how you would prefer to have this fixed in testing. Could 3.0.22-3 propagate to testing? The version in testing is two upstream versions older (3.0.20-3), therefore the diff will be pretty big. Or is a tpu upload necessary? cu andreas PS: My first idea was to simply pull gnutls28, providing guile-gnutls and gnutls-bin from gnutls26 again. However there is a reverse dependency (pan) on libgnutls28 in testing nowaday. Pan is not distributable currently http://bugs.debian.org/699892 but that might still be fixed in time for the release. -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- 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/20130207105452.ga3...@downhill.g.la
Bug#700006: Fix for bug #699906: python-django-horizon: "Launch from volume" broken
On 2013-02-07 10:05, Thomas Goirand wrote: Package: release.debian.org Severity: normal Hi, I would like to upload a fix for: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699906 The diff file is attached. If the release team thinks it is suitable for Wheezy, please let me know, and I will upload, rename this bug and tag accordingly. The diff looks fine in principle, let's see how it gets on in sid. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 i have six years of solaris sysadmin experience, from 8->10. i am well qualified to say it is made from bonghits layered on top of bonghits -- 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/148973592713c1c10f1f9622b3501...@hogwarts.powdarrmonkey.net
Bug#699899: tpu: clang/3.0-6.1+deb7u0
Hi Adam, "Adam D. Barratt" writes: > I wasn't particularly suggesting re-introducing 3.0 to unstable. > However, given that packages from tpu get essentially no testing at all > (no pun intended) before hitting testing, being able to prove a patch in > unstable first avoids a number of (admittedly not all) potential > issues. Now I understand what your point was, thanks for clarifying. > Looking at the proposed tpu diff and the 3.0 -> 3.1 diff, it looks like > the armhf changes should apply "as is" to 3.1; has anyone tried that? I have ported the patches from 3.0 to 3.1 and successfully built the package on amd64, where it works. Therefore, I will now build it on armhf, which will take around a day. Sylvestre: Are you okay with me NMUing clang 3.1-8.1 to unstable in order to expose my changes to a wider audience before we do the fix via t-p-u? -- Best regards, Michael -- 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/x6zjzgialz@midna.zekjur.net
Bug#699899: tpu: clang/3.0-6.1+deb7u0
Le 02/07/13 13:15, Michael Stapelberg a écrit : > Hi Adam, > > "Adam D. Barratt" writes: >> Looking at the proposed tpu diff and the 3.0 -> 3.1 diff, it looks like >> the armhf changes should apply "as is" to 3.1; has anyone tried that? > I have ported the patches from 3.0 to 3.1 and successfully built the > package on amd64, where it works. > > Therefore, I will now build it on armhf, which will take around a day. > > Sylvestre: Are you okay with me NMUing clang 3.1-8.1 to unstable in > order to expose my changes to a wider audience before we do the fix via > t-p-u? > Please go ahread. :) Thanks again, Sylvestre -- 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/5113a015.1030...@debian.org
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
Bdale Garbee wrote: > Sure seems like d-i is something we should build using the components > of the release it will be contained in and not unstable... but I > haven't tried to think hard about what that might imply that's > problematic. And I certainly don't think this is something we should > even consider changing at this late date in for wheezy release cycle! This is not desirable outside the freeze because packages in unstable that are used to build d-i then don't get tested until they land in testing. It might be desirable during the freeze. > wiggle the d-i build processing to fetch syslinux from testing This can be done easily, just upload d-i to t-p-u. d-i uploads are already built with udebs from testing, for similar reasons. There seems to be an unholy fear of using t-p-u for anything these days, which I don't really understand. Even when not using it causes massive and unnecessary logjams in unstable during the freeze. -- see shy jo signature.asc Description: Digital signature
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
Bdale Garbee wrote: > patch d-i to build successfully against the syslinux in sid syslinux is GPL'd, so this would result in shipping d-i images in wheezy which contain a GPL'd binary for which there is no source in wheezy. -- see shy jo signature.asc Description: Digital signature
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
Joey Hess (07/02/2013): > This can be done easily, just upload d-i to t-p-u. d-i uploads are > already built with udebs from testing, for similar reasons. > > There seems to be an unholy fear of using t-p-u for anything these days, > which I don't really understand. Even when not using it causes massive > and unnecessary logjams in unstable during the freeze. Mraw, KiBi. signature.asc Description: Digital signature
Processed: Asks for unblock
Processing commands for cont...@bugs.debian.org: > usertag #76 unblock User is tho...@goirand.fr There were no usertags set. Usertags are now: unblock. > retitle #76 unblock: horizon/2012.1.1-10 Bug #76 [release.debian.org] Fix for bug #699906: python-django-horizon: "Launch from volume" broken Changed Bug title to 'unblock: horizon/2012.1.1-10' from 'Fix for bug #699906: python-django-horizon: "Launch from volume" broken' > End of message, stopping processing here. Please contact me if you need assistance. -- 76: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=76 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.136024397530065.transcr...@bugs.debian.org
Bug#700006: Fix for bug #699906: python-django-horizon: "Launch from volume" broken
On 02/07/2013 07:45 PM, Jonathan Wiltshire wrote: > > The diff looks fine in principle, let's see how it gets on in sid. > > Thanks, Uploaded. Release team bug retitled and usertaged accordingly. Thanks. Thomas -- 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/5113ada2.2030...@goirand.fr
Bug#699385: marked as done (unblock: quantum/2012.1-5 [pre-approval])
Your message dated Thu, 07 Feb 2013 14:02:14 + with message-id <0387eb18c6c9ebeccdeadaf229ef9...@hogwarts.powdarrmonkey.net> and subject line Re: Bug#699385: unblock: package quantum/2012.1-5 [pre-approval] has caused the Debian Bug report #699385, regarding unblock: quantum/2012.1-5 [pre-approval] to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 699385: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699385 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: important User: release.debian@packages.debian.org Usertags: pu Please note! This is a TESTING proposed update request. Not a stable proposed update request. The reason for this is explained below. The update is a solution for #685251. I would like you to review this to get an acceptance for this update. The diff file is available here: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=109;filename=backport-of-solution-for-685251-2012-12-29-1.patch;att=1;bug=685251 It is simply a removal of the binary package that does not work. Please let me know if this is an acceptable change and then I'll upload to testing-proposed-updates. The reason why I want to have this as a testing-proposed-update instead of a simply upload to unstable is that the version currently available in unstable have a rather compliated transition requiring a few breaks replaces rules. It is of course possible to upload to unstable but then people who have installed the unstable version would get problem to upgrade forcing them to un-install and install the new. Better to avoid that. However if you think that is an acceptable limitation then I'll upload to unstable instead. Thanks, // Ola -- System Information: --- End Message --- --- Begin Message --- On 2013-02-07 09:50, Ola Lundqvist wrote: Hi Jonathan Now the files are uploaded. Thanks for your help. Thanks, accepted. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 i have six years of solaris sysadmin experience, from 8->10. i am well qualified to say it is made from bonghits layered on top of bonghits--- End Message ---
Bug#700006: marked as done (unblock: horizon/2012.1.1-10)
Your message dated Thu, 07 Feb 2013 13:59:24 +
with message-id
and subject line Re: Bug#76: Fix for bug #699906: python-django-horizon:
"Launch from volume" broken
has caused the Debian Bug report #76,
regarding unblock: horizon/2012.1.1-10
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
76: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=76
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
Hi,
I would like to upload a fix for:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699906
The diff file is attached. If the release team thinks it is suitable for
Wheezy, please let me know, and I will upload, rename this bug and tag
accordingly.
Cheers,
Thomas Goirand (zigo)
diff -Nru horizon-2012.1.1/debian/changelog horizon-2012.1.1/debian/changelog
--- horizon-2012.1.1/debian/changelog 2012-11-18 23:10:33.0 +0800
+++ horizon-2012.1.1/debian/changelog 2013-02-07 17:59:58.0 +0800
@@ -1,3 +1,10 @@
+horizon (2012.1.1-10) unstable; urgency=low
+
+ * Added patch: Launch from volume with valid volume size. Thanks to Julien
+Cristau for reporting (Closes: 699906).
+
+ -- Thomas Goirand Thu, 07 Feb 2013 17:50:55 +0800
+
horizon (2012.1.1-9) unstable; urgency=high
* Re-uploading with urgency=high.
diff -Nru horizon-2012.1.1/debian/patches/launch-from-volume-with-valid-volume-size.patch horizon-2012.1.1/debian/patches/launch-from-volume-with-valid-volume-size.patch
--- horizon-2012.1.1/debian/patches/launch-from-volume-with-valid-volume-size.patch 1970-01-01 08:00:00.0 +0800
+++ horizon-2012.1.1/debian/patches/launch-from-volume-with-valid-volume-size.patch 2013-02-07 17:59:58.0 +0800
@@ -0,0 +1,72 @@
+Description: Launch from volume with valid volume size
+Author: Sascha Peilicke
+Origin: upstream, https://review.openstack.org/gitweb?p=openstack/horizon.git;a=patch;h=fd2291bd28a5a4331d9a7baf961c76effd17b85a
+Bug-Debian: http://bugs.debian.org/699906
+Bug-Ubuntu: https://launchpad.net/bugs/1047568
+Date: 2012-10-18
+
+diff --git a/AUTHORS b/AUTHORS
+index 4110431..677253f 100644
+--- a/AUTHORS
b/AUTHORS
+@@ -41,6 +41,7 @@ Monty Taylor
+ Neil Johnston
+ Paul McMillan
+ Sam Morrison
++Sascha Peilicke
+ Stephane Angot
+ termie
+ Thierry Carrez
+diff --git a/horizon/dashboards/nova/images_and_snapshots/images/forms.py b/horizon/dashboards/nova/images_and_snapshots/images/forms.py
+index bc4851d..a6cdbad 100644
+--- a/horizon/dashboards/nova/images_and_snapshots/images/forms.py
b/horizon/dashboards/nova/images_and_snapshots/images/forms.py
+@@ -164,7 +164,7 @@ class LaunchForm(forms.SelfHandlingForm):
+ else:
+ delete_on_terminate = 0
+ dev_mapping = {data['device_name']:
+-("%s::%s" % (data['volume'], delete_on_terminate))}
++("%s:%s" % (data['volume'], delete_on_terminate))}
+ else:
+ dev_mapping = None
+
+diff --git a/horizon/dashboards/nova/images_and_snapshots/images/tests.py b/horizon/dashboards/nova/images_and_snapshots/images/tests.py
+index aa02325..3615288 100644
+--- a/horizon/dashboards/nova/images_and_snapshots/images/tests.py
b/horizon/dashboards/nova/images_and_snapshots/images/tests.py
+@@ -118,8 +118,8 @@ class ImageViewTests(test.TestCase):
+ sec_group = self.security_groups.first()
+ USER_DATA = 'user data'
+ device_name = u'vda'
+-volume_choice = "%s:vol" % volume.id
+-block_device_mapping = {device_name: u"%s::0" % volume_choice}
++volume_choice = "%s:vol:%s" % (volume.id, volume.size)
++block_device_mapping = {device_name: u"%s:0" % volume_choice}
+
+ self.mox.StubOutWithMock(api, 'image_get_meta')
+ self.mox.StubOutWithMock(api, 'flavor_list')
+@@ -269,7 +269,7 @@ class ImageViewTests(test.TestCase):
+ sec_group = self.security_groups.first()
+ USER_DATA = 'user data'
+ device_name = u'vda'
+-volume_choice = "%s:vol" % volume.id
++volume_choice = "%s:vol:%s" % (volume.id, volume.size)
+
+ self.mox.StubOutWithMock(api, 'image_get_meta')
+ self.mox.StubOutWithMock(api, 'flavor_list')
+diff --git a/horizon/dashboards/nova/images_and_snapshots/images/views.py b/horizon/dashboards/nova/images_and_snapshots/images/views.py
+index 1803f97..0b6ec5c 100644
+--- a/horizon/dashboards/nova/images_and_snapshots/images/views.py
b/horizon/dashboards/nova/images_and_snapshots/images/views.py
+@@ -117,7
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
Cyril Brulebois wrote: > Joey Hess (07/02/2013): > > This can be done easily, just upload d-i to t-p-u. d-i uploads are > > already built with udebs from testing, for similar reasons. > > > > There seems to be an unholy fear of using t-p-u for anything these days, > > which I don't really understand. Even when not using it causes massive > > and unnecessary logjams in unstable during the freeze. > > Yes, that's a good example of spreading FUD aboput using t-p-u, rather than just using it and dealing with any breakage. -- see shy jo signature.asc Description: Digital signature
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
On 07.02.2013 14:46, Joey Hess wrote: Cyril Brulebois wrote: Joey Hess (07/02/2013): > This can be done easily, just upload d-i to t-p-u. d-i uploads are > already built with udebs from testing, for similar reasons. > > There seems to be an unholy fear of using t-p-u for anything these days, > which I don't really understand. Even when not using it causes massive > and unnecessary logjams in unstable during the freeze. Yes, that's a good example of spreading FUD aboput using t-p-u, rather than just using it and dealing with any breakage. If you want to describe being concerned with dak refusing to import the result of a britney run due to the version constraints being broken FUD, sure. Note that I didn't say it was a reason not to use tpu, just a pre-condition in this case. 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/802784afd7484f8e74647b4d60188...@mail.adsl.funky-badger.org
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
On Thu, Feb 07, 2013 at 01:55:11AM +0100, Cyril Brulebois wrote: > On a personal note, I'm unsure how we came up with a situation where a > single maintainer can *actively* stall a release… Not caring about the > release process put into place years ago is a thing. Stopping people > from fixing problems created by such carelessness is another one… Speaking as an ex-RM, I think the answer here is that it used to be that when a maintainer made such an upload (and it did happen), we would revert it without hesitation and without apology. I'm having a hard time deciding, with my TC member hat on, if I think this is actually an ok thing to do. But whether or not it's ok, I do think I would still do it today if I were in your position on the grounds that it's easier to ask forgiveness than to ask permission, and asking explicit permission from every maintainer who is in a position to become a critical blocker for the release is a good way to make sure releases don't happen. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
unblock-udeb for udev 175-7.1
Hi all,
Apologies for taking as long as I have to get around to sending this mail.
I would like to request an unblock of the udev udeb at version 175-7.1.
unblock-udeb udev/175-7.1
This package is a prerequisite for having a useful version of upstart in
wheezy (bug #686387), and the change should be a no-op with respect to the
installer:
$ debdiff ~/ftp/pool/main/u/udev/udev-udeb_175-7{,.1}_i386.udeb
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Installed-Size: [-427-] {+422+}
Version: [-175-7-] {+175-7.1+}
$
Are there any objections from the d-i side to letting this package into
testing?
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Bug#699899: tpu: clang/3.0-6.1+deb7u0
Hi Adam, Michael Stapelberg writes: > Therefore, I will now build it on armhf, which will take around a day. Update: the armhf build failed because about 100 testcases fail. I have no clue on how to fix this and can’t spend much more time on debugging this either. Given that the 3.0 version works — it passed all the clang tests and can compile non-trivial software on armhf and amd64 — can we just upload that? Or, as a last resort, re-introduce 3.0 in unstable, even if switching to an epoch is ugly? -- Best regards, Michael -- 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/x6obfwhx23@midna.zekjur.net
Bug#699899: tpu: clang/3.0-6.1+deb7u0
Le 02/07/13 18:07, Michael Stapelberg a écrit : > Hi Adam, > > Michael Stapelberg writes: >> Therefore, I will now build it on armhf, which will take around a day. > Update: the armhf build failed because about 100 testcases fail. > > I have no clue on how to fix this and can’t spend much more time on > debugging this either. > > Given that the 3.0 version works — it passed all the clang tests and can > compile non-trivial software on armhf and amd64 — can we just upload > that? Or, as a last resort, re-introduce 3.0 in unstable, even if > switching to an epoch is ugly? > Don't bother too much about the epoch, clang source package is going to be removed anyway... (I am working on a LLVM toolchain package including llvm + clang + other stuff). Sylvestre -- 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/5113f296.2030...@debian.org
Bug#698831: unblock: xen/4.1.4-2
Control: retitle -1 unblock: xen/4.1.4-2
In the meantime this is 4.1.4-2. It fixes a lot of things including a
few security problems.
xen (4.1.4-2) unstable; urgency=low
* Use pre-device interrupt remapping mode per default. Fix removing old
remappings.
CVE-2013-0153
-- Bastian Blank Wed, 06 Feb 2013 13:04:52 +0100
xen (4.1.4-1) unstable; urgency=low
* New upstream release.
- Disable process-context identifier support in newer CPUs for all
domains.
- Add workarounds for AMD errata.
- Don't allow any non-canonical addresses.
- Use Multiboot memory map if BIOS emulation does not provide one.
- Fix several problems in tmem.
CVE-2012-3497
- Fix error handling in domain creation.
- Adjust locking and interrupt handling during S3 resume.
- Tighten more resource and memory range checks.
- Reset performance counters. (closes: #698651)
- Remove special-case for first IO-APIC.
- Fix MSI handling for HVM domains. (closes: #695123)
- Revert cache value of disks in HVM domains.
-- Bastian Blank Thu, 31 Jan 2013 15:44:50 +0100
Bastian
--
Sometimes a man will tell his bartender things he'll never tell his doctor.
-- Dr. Phillip Boyce, "The Menagerie" ("The Cage"),
stardate unknown.
signature.asc
Description: Digital signature
Bug#699900: unblock: nsd3/3.2.12-2
On Wed, Feb 6, 2013 at 14:32:02 +0100, Ondřej Surý wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package nsd3 > > Hi, > > please unblock nsd3 3.2.12-2 which includes Response Rate Limiting. > Unfortunatelly the DDoSes on DNS infrastructure are very common right > now and even though the patch is quite big I think it needs to go in. > > The patch has been provided directly by upstream, and although they > have declared it's unsupported there have been so few changes between > 3.2.12 and 3.2.15 (other than this diff) that I think it's quite safe > to apply this patch. I will of course monitor new upstream versions > and cherry-pick fixes if there's the need. > debian/rules doesn't seem to have a 'clean' rule change to go with the 'autoreconf' addition? Cheers, Julien signature.asc Description: Digital signature
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
On Thu, Feb 07, 2013 at 10:33:00AM +0100, Ansgar Burchardt wrote: > As Adam already pointed out we would still need another d-i upload to > unstable to make sure unstable has a higher-or-equal version compared to > testing. Sometimes I wonder why it cannot simply propagate to the upper suite. We do that for packages from s-p-u at point release time, too. I guess the flow would be "britney import → if version > unstable → stuff the new testing version into unstable". We used to propagate security updates from stable into testing so that they only have to be done once. But I guess both times concerns about "not being built within the suite in question" might apply. But we still do that for packages installed into *stable* (i.e. across the major divergence between stable and unstable, or at least into testing). Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#699900: unblock: nsd3/3.2.12-2
On Thu, Feb 7, 2013 at 8:05 PM, Julien Cristau wrote: > debian/rules doesn't seem to have a 'clean' rule change to go with the > 'autoreconf' addition? I am not sure I get what exactly do you have in mind? Do you want to clean-up generated files (autom4ke, ...) or something else? Ondrej -- Ondřej Surý -- 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/caljhhg9ngwuafjy0oldkrg-vjih+hu5hctorvz8mo+sm3rc...@mail.gmail.com
Bug#699900: unblock: nsd3/3.2.12-2
On Thu, Feb 7, 2013 at 20:33:24 +0100, Ondřej Surý wrote: > On Thu, Feb 7, 2013 at 8:05 PM, Julien Cristau wrote: > > debian/rules doesn't seem to have a 'clean' rule change to go with the > > 'autoreconf' addition? > > I am not sure I get what exactly do you have in mind? Do you want to > clean-up generated files (autom4ke, ...) or something else? > Well, clean is supposed to undo whatever the build process did. So, yes... Cheers, Julien signature.asc Description: Digital signature
Bug#698831: marked as done (pre-approval: xen/4.1.4-1)
Your message dated Thu, 7 Feb 2013 20:52:54 +0100 with message-id <20130207195254.gp8...@radis.cristau.org> and subject line Re: Bug#698831: unblock: xen/4.1.4-2 has caused the Debian Bug report #698831, regarding pre-approval: xen/4.1.4-1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 698831: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698831 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi I'd like to update xen to 4.1.4. It contains mostly fixes on the hypervisor and some smaller ones on the tools. The hypervisor gets a lot of fixes. This includes fixes for - ignored (like CVE-2012-3497) and low impact security issues, usage of non-canonical addresses and off-by-one errors in access checks, - support and fixes for new hardware, - workarounds for CPU errata and other spec fixes and - race conditions. Some changes are also done to the userspace tools. This includes - fixes for pvscsi support in xend (not usable in Debian), - pygrub (python grub2 config parser) argument handling and - fixes to bundled qemu, MSI setup and proper default caching of backend devices. The complete update can go through unstable. The diff is a bit large for my taste, but it is better to pick the whole then picking half of the fixes. The diffstat for the effective diff (between both patched trees) looks like this: | .hg_archival.txt |4 | .hgsigs |3 | .hgtags |3 | Config.mk|6 | MAINTAINERS | 27 +++ | docs/man/xmdomain.cfg.pod.5 |6 | qemu/hw/pass-through.c |3 | qemu/hw/pt-msi.c | 14 - | qemu/hw/xen_machine_fv.c |7 | qemu/xenstore.c |2 | tools/blktap2/control/tap-ctl-list.c | 12 - | tools/blktap2/control/tap-ctl.h |2 | tools/firmware/hvmloader/xenbus.c|6 | tools/hotplug/Linux/network-nat |2 | tools/libxc/xc_cpufeature.h |2 | tools/libxc/xc_cpuid_x86.c |1 | tools/libxc/xc_hvm_build.c | 35 ++-- | tools/libxl/libxl_blktap2.c | 36 +++- | tools/libxl/libxl_device.c |2 | tools/libxl/libxl_internal.h |6 | tools/libxl/libxl_noblktap2.c|4 | tools/pygrub/src/pygrub |8 | tools/python/xen/util/vscsi_util.py | 32 ++- | tools/python/xen/xend/XendStateStore.py |2 | tools/xenballoon/xenballoond.init|2 | xen/Makefile |2 | xen/arch/x86/boot/cmdline.S |6 | xen/arch/x86/boot/edd.S |6 | xen/arch/x86/cpu/amd.c | 28 ++- | xen/arch/x86/cpu/centaur.c |3 | xen/arch/x86/cpu/common.c|5 | xen/arch/x86/cpu/cyrix.c |4 | xen/arch/x86/cpu/intel.c |5 | xen/arch/x86/cpu/mtrr/main.c | 42 | xen/arch/x86/domain.c| 27 +++ | xen/arch/x86/domctl.c| 63 ++- | xen/arch/x86/hpet.c | 18 +- | xen/arch/x86/hvm/hvm.c | 33 +++ | xen/arch/x86/hvm/mtrr.c | 24 -- | xen/arch/x86/hvm/svm/svm.c | 24 ++ | xen/arch/x86/hvm/vmx/vmx.c | 30 +++ | xen/arch/x86/io_apic.c | 18 -- | xen/arch/x86/mm.c| 28 ++- | xen/arch/x86/mm/hap/hap.c|3 | xen/arch/x86/mm/hap/p2m-ept.c|8 | xen/arch/x86/mm/p2m.c| 38 ++-- | xen/arch/x86/mm/paging.c |3 | xen/arch/x86/mm/shadow/multi.c |2 | xen/arch/x86/msi.c |7 | xen/arch/x86/oprofile/xenoprof.c | 21 +- | xen/arch/x86/physdev.c | 24 +- | xen/arch/x86/setup.c | 25 +- | xen/arch/x86/traps.c |7 | xen/arch/x86/x86_32/entry.S |3 | xen/arch/x86/x86_64/compat/entry.S |3 | xen/arch/x86/x86_64/entry.S
Bug#682906: unblock: python-defaults/2.7.3-2
On Sun, Feb 3, 2013 at 21:03:36 +0100, Piotr Ozarowski wrote: > > And as discussed on IRC the prerm/postrm changes are broken and need a > > revert. > > please be more verbose for those of us who did not participate in this > discussion (or do not remember it) - removing configuration in postrm remove is a no-no - prerm purge does not exist. Cheers, Julien signature.asc Description: Digital signature
Unblock request for polarssl 1.1.4-2
Hi, polarssl 1.1.4-2 just hit unstable. Fixes security bug #699887, CVE-2013-0169, so please unblock. Thanks! (Will contact the security team separately for the respective security update for the version in stable.) Roland -- 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/5114226f.2090...@antcom.de
Re: Unblock request for polarssl 1.1.4-2
On Thu, 2013-02-07 at 22:53 +0100, Roland Stigge wrote: > polarssl 1.1.4-2 just hit unstable. Fixes security bug #699887, > CVE-2013-0169, so please unblock. Unblocked; thanks. Please consider filing a usertagged unblock tag (e.g. via reportbug) in future. They're much easier for us to keep track of. 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/1360274369.14861.11.ca...@jacala.jungle.funky-badger.org
Bug#700052: unblock: xnbd/0.1.0-pre-hg20-e75b93a47722-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package xnbd. It fixes a local symlink attack vulnerability
being tracked as CVE-2013-0265. This upload includes a patch changing the
default logfile location to a location which is not globally writable (and more
FHS conform anyway). It also fixes a purely cosmetic spelling fix in man pages.
diff -Nru xnbd-0.1.0-pre-hg20-e75b93a47722/debian/changelog
xnbd-0.1.0-pre-hg20-e75b93a47722/debian/changelog
--- xnbd-0.1.0-pre-hg20-e75b93a47722/debian/changelog 2012-05-28
19:38:35.0 +0200
+++ xnbd-0.1.0-pre-hg20-e75b93a47722/debian/changelog 2013-02-07
22:45:21.0 +0100
@@ -1,3 +1,12 @@
+xnbd (0.1.0-pre-hg20-e75b93a47722-3) unstable; urgency=medium
+
+ * Fix "Documentation Error: Option --blocksize mistyped" use correct
+spelling(Closes: #691842)
+ * CVE-2013-0265: Fix symlink vulnerability spotted by Sebastian Pipping
+. Moreover, thanks Sebastian for providing a patch.
+
+ -- Arno Töll Thu, 07 Feb 2013 22:45:10 +0100
+
xnbd (0.1.0-pre-hg20-e75b93a47722-2) unstable; urgency=low
* Do a full source rebuild again, now that #670557 is fixed.
diff -Nru xnbd-0.1.0-pre-hg20-e75b93a47722/debian/patches/CVE-2013-0265.patch
xnbd-0.1.0-pre-hg20-e75b93a47722/debian/patches/CVE-2013-0265.patch
--- xnbd-0.1.0-pre-hg20-e75b93a47722/debian/patches/CVE-2013-0265.patch
1970-01-01 01:00:00.0 +0100
+++ xnbd-0.1.0-pre-hg20-e75b93a47722/debian/patches/CVE-2013-0265.patch
2013-02-07 22:40:22.0 +0100
@@ -0,0 +1,169 @@
+From: Sebastian Pipping
+Date: Tue, 5 Feb 2013 14:05:29 +0100
+Subject: [PATCH] Fix insecure logging location (CVE-2013-0265)
+
+* Change the default log file location from /tmp to /var/log
+* Update manpages with respect to the new default location.
+
+Origin: upstream,
http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=bdb56bac
+Bug: http://seclists.org/oss-sec/2013/q1/248
+
+---
+ trunk/doc/xnbd-server.8.sgml |2 +-
+ trunk/doc/xnbd-wrapper.8.sgml |2 +-
+ trunk/xnbd_common.c | 11 +--
+ trunk/xnbd_common.h |6 ++
+ trunk/xnbd_server.c |9 +
+ trunk/xnbd_wrapper.c | 10 +++---
+ 6 files changed, 21 insertions(+), 19 deletions(-)
+
+--- a/trunk/doc/xnbd-server.8.sgml
b/trunk/doc/xnbd-server.8.sgml
+@@ -172,7 +172,7 @@
+ --logpath FILE
+
+
+- Log informational messages to the given
FILE if given. Defaults to
/tmp/xnbd.log
++ Log informational messages to the given
FILE if given. Defaults to
/var/log/xnbd-server.log
+
+
+
+--- a/trunk/doc/xnbd-wrapper.8.sgml
b/trunk/doc/xnbd-wrapper.8.sgml
+@@ -126,7 +126,7 @@
+ --logpath FILE
+
+
+- Log informational messages to the given
FILE if given. Defaults to
/tmp/xnbd.log
++ Log informational messages to the given
FILE if given. Defaults to
/var/log/xnbd-wrapper.log
+
+
+
+--- a/trunk/xnbd_common.c
b/trunk/xnbd_common.c
+@@ -197,9 +197,9 @@
+ return (unsigned long) nblocks64;
+ }
+
+-void redirect_stderr(const char *logfile)
++void redirect_stderr(const char *logfile, const char * default_logfile)
+ {
+-int logfd = open(logfile ? logfile : DEFAULT_XNBDSERVER_LOGFILE,
++int logfd = open(logfile ? logfile : default_logfile,
+ O_WRONLY | O_CREAT | O_APPEND, S_IRUSR | S_IWUSR);
+ if (logfd < 0)
+ err("open %s, %m", logfile);
+@@ -211,7 +211,7 @@
+ close(logfd);
+ }
+
+-void detach(const char *logpath)
++void detach(const char *logpath, const char * default_logpath)
+ {
+ close(STDIN_FILENO);
+
+@@ -224,9 +224,8 @@
+ close(devnull);
+
+ if(!logpath) {
+-logpath = DEFAULT_XNBDSERVER_LOGFILE;
+-info("logfile %s", logpath);
+-redirect_stderr(logpath);
++info("logfile %s", default_logpath);
++redirect_stderr(NULL, default_logpath);
+ }
+
+ int ret = daemon(0, 1);
+--- a/trunk/xnbd_common.h
b/trunk/xnbd_common.h
+@@ -1,9 +1,7 @@
+ #ifndef XNBD_COMMON_H
+ #define XNBD_COMMON_H
+
+-#define DEFAULT_XNBDSERVER_LOGFILE "/tmp/xnbd.log"
+-
+-void redirect_stderr(const char *logfile);
+-void detach(const char *logpath);
++void redirect_stderr(const char *logfile, const char * default_logfile);
++void detach(const char *logpath, const char * default_logpath);
+
+ #endif
+--- a/trunk/xnbd_server.c
b/trunk/xnbd_server.c
+@@ -29,6 +29,7 @@
+ #include
+
+
++#define XNBD_SERVER_LOGFILE_DEFAULT "/var/log/xnbd-server.log"
+
+
+
+@@ -750,7 +751,7 @@
+ --lport listen port (default 8520)\n\
+ --daemonize run as a daemon process\n\
+ --readonly export a disk as readonly\n\
+- --logpath logfile (default /tmp/xnbd.log)\n\
++ --logpath logfile (default /var/log/xnbd-server.l
Bug#697078: tpu: xdotool/1:2.20100701.2961-3+deb7u1
On Wed 2013-02-06 17:25:37 -0500, Daniel Kahn Gillmor wrote: > If you think it's worth it, i'll set aside some time to work on this > tomorrow, to get 1:2.20100701.2961-3 to build cleanly against stock wheezy. I've just uploaded 1:2.20100701.2961-3+deb7u2 to testing-proposed-updates. --dkg pgpGEHiqODuVA.pgp Description: PGP signature
Bug#686054: Bug#682518: Bug#677565: RC bugs in msva-perl
On 02/04/2013 01:28 PM, Dominic Hargreaves wrote:
> On Sat, Feb 02, 2013 at 03:31:33PM +0100, intrigeri wrote:
>> FWIW, I've asked about the same on the Monkeysphere mailing-list last
>> October, see dkg's answer there:
>> https://lists.riseup.net/www/arc/monkeysphere/2012-10/
I've just pushed a proposed upstream msva-perl/0.8.1 targetted bugfix
tag to git://lair.fifthhorseman.net/~dkg/msva-perl, and a "wheezy"
branch that uses that and targets testing-proposed-updates.
The debdiff between 0.8-2 and the proposed 0.8.1-1 is attached here. It
is smaller than the previously-submitted changeset to 0.9.1-1, but it is
still non-trivial, alas, due to having to accomodate the new Net::Server
and the change to avoid crashing X11 sessions if the agent fails for any
reason we were not able to anticipate.
I've tested 0.8.1-1 on a wheezy system and it works for me. I plan to
upload it to t-p-u sometime tomorrow or the next day unless i hear from
anyone that it didn't work for them.
Regards,
--dkg
diff -Nru msva-perl-0.8/Changelog msva-perl-0.8.1/Changelog
--- msva-perl-0.8/Changelog 2010-12-20 16:11:39.0 -0500
+++ msva-perl-0.8.1/Changelog 2013-02-08 00:28:19.0 -0500
@@ -1,3 +1,11 @@
+msva-perl (0.8.1) upstream;
+
+ * "stable" release:
+ - cherry-picked bugfixes from 0.9 and 0.9.1; reduced refactoring
+changes to get it to work safely with wheezy.
+
+ -- Daniel Kahn Gillmor Thu, 07 Feb 2013 23:33:46
-0500
+
msva-perl (0.8) upstream;
* Minor bugfix release!
diff -Nru msva-perl-0.8/Crypt/Monkeysphere/MSVA/Client.pm
msva-perl-0.8.1/Crypt/Monkeysphere/MSVA/Client.pm
--- msva-perl-0.8/Crypt/Monkeysphere/MSVA/Client.pm 2010-12-20
16:11:39.0 -0500
+++ msva-perl-0.8.1/Crypt/Monkeysphere/MSVA/Client.pm 2013-02-08
00:28:19.0 -0500
@@ -145,7 +145,7 @@
$self->{logger} = Crypt::Monkeysphere::MSVA::Logger->new($args{log_level});
$self->{socket} = $args{socket};
-$self->{socket} = 'http://localhost:8901'
+$self->{socket} = 'http://127.0.0.1:8901'
if (! defined $self->{socket} or $self->{socket} eq '');
# create the user agent
diff -Nru msva-perl-0.8/Crypt/Monkeysphere/MSVA/Logger.pm
msva-perl-0.8.1/Crypt/Monkeysphere/MSVA/Logger.pm
--- msva-perl-0.8/Crypt/Monkeysphere/MSVA/Logger.pm 2010-12-20
16:11:39.0 -0500
+++ msva-perl-0.8.1/Crypt/Monkeysphere/MSVA/Logger.pm 2013-02-08
00:28:19.0 -0500
@@ -45,6 +45,8 @@
my $self = shift;
my $msglevel = shift;
+$msglevel = 'error'
+ if (! defined($msglevel));
if ($loglevels{lc($msglevel)} <= $self->{loglevel}) {
printf STDERR @_;
}
@@ -88,7 +90,7 @@
my $class = shift;
my $loglevel = shift;
-my $self = {loglevel => $loglevels{lc($loglevel)}};
+my $self = {loglevel => $loglevels{defined($loglevel) ? lc($loglevel) :
'error'}};
$self->{loglevel} = $loglevels{error}
if (!defined $self->{loglevel});
diff -Nru msva-perl-0.8/Crypt/Monkeysphere/MSVA/MarginalUI.pm
msva-perl-0.8.1/Crypt/Monkeysphere/MSVA/MarginalUI.pm
--- msva-perl-0.8/Crypt/Monkeysphere/MSVA/MarginalUI.pm 2010-12-20
16:11:39.0 -0500
+++ msva-perl-0.8.1/Crypt/Monkeysphere/MSVA/MarginalUI.pm 2013-02-08
00:28:19.0 -0500
@@ -46,7 +46,8 @@
}
foreach my $keyfpr (@subvalid_key_fprs) {
- my $fprx = sprintf('0x%.40s', $keyfpr->{fpr}->as_hex_string());
+ $keyfpr->{fpr}->as_hex_string() =~ /([[:xdigit:]]{0,40})/;
+ my $fprx = '0x' . $1;
$logger->log('debug', "checking on %s\n", $fprx);
foreach my $gpgkey ($gnupg->get_public_keys_with_sigs($fprx)) {
$logger->log('debug', "found key %.40s\n",
$gpgkey->fingerprint->as_hex_string);
diff -Nru msva-perl-0.8/Crypt/Monkeysphere/MSVA.pm
msva-perl-0.8.1/Crypt/Monkeysphere/MSVA.pm
--- msva-perl-0.8/Crypt/Monkeysphere/MSVA.pm2010-12-20 16:11:39.0
-0500
+++ msva-perl-0.8.1/Crypt/Monkeysphere/MSVA.pm 2013-02-08 00:28:19.0
-0500
@@ -376,7 +376,7 @@
# This is part of a spawned child process. We don't want the
# child process to destroy the update monitor when it terminates.
-$self->{updatemonitor}->forget();
+$self->{updatemonitor}->forget() if exists $self->{updatemonitor} &&
defined $self->{updatemonitor};
my $clientinfo = get_client_info(select);
my $clientuid = $clientinfo->{uid};
@@ -759,17 +759,22 @@
my $self = shift;
my $server = shift;
-$self->spawn_master_subproc($server);
+$self->spawn_as_child($server);
}
- sub master_subprocess_died {
+ sub pre_accept_hook {
my $self = shift;
my $server = shift;
-my $subproc_return = shift;
-my $exitstatus = POSIX::WEXITSTATUS($subproc_return);
-msvalog('verbose', "Subprocess %d terminated; exiting %d.\n",
$self->{child_pid}, $exitstatus);
-$server->set_exit_status($exitstatus);
+$self->parent_changed($server) if (defined $self->{parent_pid} &&
getppid() != $self->{parent_p
Bug#682906: unblock: python-defaults/2.7.3-2
You are talking about my changes apparently :) Right, prerm purge really does not exist according to the Policy. This makes me wondering how this change was fixing the problem for the original reporter.. The revert is attached and alternatively available at bzr branch bzr+ssh://bzr.debian.org/~mitya57-guest/public_bzr/python-defaults/revert-prerm-postrm -- Dmitry Shachnev On Thursday, 07/02/2013 at 22:18 +0100, Julien Cristau wrote: > On Sun, Feb 3, 2013 at 21:03:36 +0100, Piotr Ozarowski wrote: > > > > And as discussed on IRC the prerm/postrm changes are broken and need a > > > revert. > > > > please be more verbose for those of us who did not participate in this > > discussion (or do not remember it) > > - removing configuration in postrm remove is a no-no > - prerm purge does not exist. > > Cheers, > Julien === modified file 'debian/changelog' --- a/debian/changelog 2012-10-21 21:05:39 + +++ b/debian/changelog 2013-02-08 05:43:10 + @@ -1,3 +1,11 @@ +python-defaults (2.7.3-4) UNRELEASED; urgency=low + + * Revert my prerm/postrm changes: +- prerm is never called as `prerm purge`. +- configuration files shouldn't be deleted on package remove. + + -- Dmitry Shachnev Fri, 08 Feb 2013 09:40:02 +0400 + python-defaults (2.7.3-3) unstable; urgency=low [ Piotr Ożarowski ] === modified file 'debian/python.postrm.in' --- a/debian/python.postrm.in 2012-10-08 10:31:51 + +++ b/debian/python.postrm.in 2013-02-08 05:43:10 + @@ -1,7 +1,8 @@ #! /bin/sh set -e -case "$1" in remove|purge) +case "$1" in +purge) rm -rf /etc/python esac === modified file 'debian/python.prerm.in' --- a/debian/python.prerm.in 2012-10-09 10:27:24 + +++ b/debian/python.prerm.in 2013-02-08 05:43:10 + @@ -1,7 +1,8 @@ #! /bin/sh set -e -case "$1" in remove|purge) +case "$1" in +remove) rm -f /usr/share/python/pyversions.py[co] esac signature.asc Description: This is a digitally signed message part
