Bug#783722: jessie-pu: package ganeti/2.12.3-0+deb8u1
On 2015-04-29 18:45:56, Apollon Oikonomopoulos wrote: Hi, On 16:37 Wed 29 Apr , Adam D. Barratt wrote: Unstable and stable currently have the same version of ganeti; as a rule of thumb, unless there's a really good reason then we always want fixes to have been proven in unstable before being backported to stable - that applies for small fixes, but certainly for a change of the size proposed. What's the plan for getting unstable updated? I originally intended to upload 2.12.3 to unstable today and then prepare 2.12.3-1~deb8u1, precisely to get more testing. Unfortunately, unstable moved on to GHC 7.8 right after the freeze ended, which introduced some backwards-incompatible changes causing ganeti 2.12 to FTBFS on sid. I know upstream is working on GHC 7.8 support, but it is not yet clear how long it will take and whether the fix will target 2.12 or a later stable release. Not the best possible situation I have to admit. FYI, upstream seems to have fixed this on the 2.15 branch, and manually applying some of the changed done by Niklas (search on git.ganeti.org for 7.8, see especially commits b78a2c3013c16395c48e055de82c4f93d9b41c38, 083776b9dbd7e704357841e6a8a4fce6802199fc and 1ad14f38083d7d7702154f791070a92e241320e0) gets the build progressing quite far, until the lens 4.4 changes which removed defaultRules (see https://code.google.com/p/ganeti/issues/detail?id=981). Applying on top commits cfd9c8a82550df4e29ebeee2158f1d7fb864d531 and 14a85a6fa426e3088423923094cd6d574fe91d3f results in the build failing only due to -Werror, which can be patched out (and there are fixes for that as well in git). So the upstream git tree contains all changes needed, but spread around different branches. It should be easy for upstream to make a new 2.12 release, but it's even more simple for Debian to patch 2.12 in-place by cherry-picking these patches, they are rather trivial. I make my tests based on 2.12.0 source as retrieved by apt-get source. Not sure if 2.12.3 contains further fixes or changes that would make this more difficult. Just FYI :) regards, iustin signature.asc Description: Digital signature
Bug#683200: unblock: ganeti/2.5.2-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package ganeti Hi release team, I would kindly ask you to unblock the ganeti package. As upstream, we have released version 2.5.2 especially to fix the outstanding issues that ganeti has in testing (and that were fixable without invasive changes). You can see the upstream commits here: http://git.ganeti.org/?p=ganeti.git;a=shortlog;h=refs/tags/v2.5.2;hp=refs/tags/v2.5.1 The debdiff between testing and unstable is a bit more hairy due to the HTML doc being regenerated, so I won't include it; let me know if you want to take a look at it. Beside the upstream changes, on the debian packaging side there are two extra changes: - a patch to fix the -no-kvm parameter (not upstreamed yet) - a fix to dh_installinit invocation (the fix for #677674) Let me know if unblocking is possible or not. Thanks! unblock ganeti/2.5.2-1 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.23-ruru1 (SMP w/4 CPU cores) Locale: LANG=ro_RO.UTF-8, LC_CTYPE=ro_RO.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash signature.asc Description: Digital signature
Freeze exception pre-request for ganeti
Hi, I send this exception request a bit in advance, since all bugs were opened and known from before the freeze, and I'd like to know if we can still fix them in Wheezy; due to lack of time I wasn't able to prepare all in time. Sorry! By next weekend, once we sort a bug upstream, I would like to request an exception for fixing the following bugs: - #624256, needs an upstream fix, but will be non-invasive - #676930, needs cherry-picking two patches from upstream - #677674, needs a trivial typo fix in the Debian packaging - #682333, which is the most important one because is completely breaks KVM+Ganeti; this will be a change in the configure-time options for Ganeti, so packaging change only See also https://groups.google.com/forum/?fromgroups#!topic/ganeti-devel/BGSipGhYugA for a more in-depth email regarding Ganeti in Wheezy. I will send a debdiff once we have everything in place, but this is an early request to see if there are any potential issues. thanks, iustin signature.asc Description: Digital signature
Proposed upload for fixing 613648 (in stable)
Hi, I would like to upload a fixed ganeti package in order to close #613648 (very stupid bug, sorry). Attached are the proposed changes, as formatted with git format-patch on top of our git tree (change not pushed yet). I confirm that the patch fixes the problem and that basic functionality has been tested for the updated package. It's a long time since I did a stable fix, so I might have gotten the distribution or the versioning wrong; please let me know! regards, iustin From a1ff159ddfdc99b953428e032e335cba8030827b Mon Sep 17 00:00:00 2001 From: Iustin Pop ius...@debian.org Date: Sat, 12 Mar 2011 14:27:32 +0100 Subject: [PATCH] Release 2.1.6-1+squeeze1, closing 613648 --- debian/changelog|7 +++ debian/patches/fix-octal-mode.patch | 29 + debian/patches/series |1 + 3 files changed, 37 insertions(+), 0 deletions(-) create mode 100644 debian/patches/fix-octal-mode.patch diff --git a/debian/changelog b/debian/changelog index 9946b15..4620f2b 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +ganeti (2.1.6-1+squeeze1) stable; urgency=low + + * Fix Wrong permissions for /var/lock after 'gnt-node add' (applied +patch fixing octal mode usage) (Closes: #613648) + + -- Iustin Pop ius...@debian.org Sat, 12 Mar 2011 14:24:52 +0100 + ganeti (2.1.6-1) unstable; urgency=low * New upstream version(s) diff --git a/debian/patches/fix-octal-mode.patch b/debian/patches/fix-octal-mode.patch new file mode 100644 index 000..70c2cdc --- /dev/null +++ b/debian/patches/fix-octal-mode.patch @@ -0,0 +1,29 @@ +Description: Fix octal mode usage for os.chmod + In Python 2.x, octal values need to be prefixed with '0', and Ganeti has two occurences + where this doesn't happen, leading to the mode being interpreted as decimal +Origin: vendor, http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=ganeti.patch;att=1;bug=613648 +Bug-Debian: http://bugs.debian.org/613648 +From: Ronny Lindner ronny.lind...@unister-gmbh.de +Acked-by: Iustin Pop ius...@debian.org +--- a/daemons/ganeti-confd b/daemons/ganeti-confd +@@ -288,7 +288,7 @@ + constants.RELEASE_VERSION) + + dirs = [(val, constants.RUN_DIRS_MODE) for val in constants.SUB_RUN_DIRS] +- dirs.append((constants.LOCK_DIR, 1777)) ++ dirs.append((constants.LOCK_DIR, 01777)) + daemon.GenericMain(constants.CONFD, parser, dirs, CheckConfd, ExecConfd) + + +--- a/daemons/ganeti-noded b/daemons/ganeti-noded +@@ -893,7 +893,7 @@ + + dirs = [(val, constants.RUN_DIRS_MODE) for val in constants.SUB_RUN_DIRS] + dirs.append((constants.LOG_OS_DIR, 0750)) +- dirs.append((constants.LOCK_DIR, 1777)) ++ dirs.append((constants.LOCK_DIR, 01777)) + daemon.GenericMain(constants.NODED, parser, dirs, CheckNoded, ExecNoded, + console_logging=True) + diff --git a/debian/patches/series b/debian/patches/series index 62f588b..9416400 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1,2 +1,3 @@ +fix-octal-mode.patch fix-startup-with-old-config.patch cfgupgrade12-remove-old-ssconf.patch -- 1.7.4.1 signature.asc Description: Digital signature
Re: Proposed upload for fixing 613648 (in stable)
On Sat, Mar 12, 2011 at 02:10:23PM +, Adam D. Barratt wrote: On Sat, 2011-03-12 at 14:49 +0100, Iustin Pop wrote: I would like to upload a fixed ganeti package in order to close #613648 (very stupid bug, sorry). Attached are the proposed changes, as formatted with git format-patch on top of our git tree (change not pushed yet). I confirm that the patch fixes the problem and that basic functionality has been tested for the updated package. Why is ganeti changing the permissions of /var/lock at all? (Rather than a file within that directory, or a sub-directory if need be). That's a bug by itself; however, for stable, I'd rather just fix the permissions. If you think it's better to fix it as to not touch /var/lock, that can be done, but it'll be a slightly bigger patch. It's a long time since I did a stable fix, so I might have gotten the distribution or the versioning wrong; please let me know! Looking at the bug log, it appears that this also affects unstable, and has not yet been fixed there. Is that correct? It has been fixed, as the version in unstable uses /bin/chmod, not Python's os.chmod. /bin/chmod always takes octal, so chmod 1777 is a right call. The fact that ganeti from unstable still touches /var/lock (at all) is indeed a bug, that will be fixed separately. Let me know how to proceed. thanks, iustin signature.asc Description: Digital signature
Re: Proposed upload for fixing 613648 (in stable)
On Sat, Mar 12, 2011 at 03:11:45PM +, Adam D. Barratt wrote: On Sat, 2011-03-12 at 16:03 +0100, Iustin Pop wrote: On Sat, Mar 12, 2011 at 02:10:23PM +, Adam D. Barratt wrote: On Sat, 2011-03-12 at 14:49 +0100, Iustin Pop wrote: I would like to upload a fixed ganeti package in order to close #613648 (very stupid bug, sorry). Attached are the proposed changes, as [...] Why is ganeti changing the permissions of /var/lock at all? (Rather than a file within that directory, or a sub-directory if need be). That's a bug by itself; however, for stable, I'd rather just fix the permissions. If you think it's better to fix it as to not touch /var/lock, that can be done, but it'll be a slightly bigger patch. Let's just go with fixing the immediate bug to start with; at least the permissions it's trying to assign to /var/lock/ are those which it will have by default on a Debian system anyway. Yep, that was the original intention. If you look at the original commit http://git.ganeti.org/?p=ganeti.git;a=commit;h=f2ffd244aed2749f719b2c1811dd715be9ae6a26: ganeti-noded: Create LOCK_DIR if missing We need this directory for locks, so if for any reason it's not there we'll create it. The permissions are the standard /var/lock permissions. The bug is that even if it exists, we will change its permissions. Please go ahead with the stable upload. Done. I hope that simply dput ftp-master was the right thing. It's a long time since I did a stable fix, so I might have gotten the distribution or the versioning wrong; please let me know! Looking at the bug log, it appears that this also affects unstable, and has not yet been fixed there. Is that correct? It has been fixed, as the version in unstable uses /bin/chmod, not Python's os.chmod. /bin/chmod always takes octal, so chmod 1777 is a right call. In that case, the fixed versions of #613648 should be updated to indicate that it doesn't apply to the version in unstable; maybe track the don't touch /var/lock's permissions as a separate cloned bug? Done, #617928 is the new bug. thanks! iustin signature.asc Description: Digital signature
Re: Permission to upload ganeti-instance-debootstrap 0.9-2
On Wed, Sep 15, 2010 at 08:17:40PM +0200, Julien Cristau wrote: On Tue, Sep 14, 2010 at 21:08:59 +0200, Iustin Pop wrote: On Sun, Sep 12, 2010 at 08:54:01PM +0200, Iustin Pop wrote: Hi, I'd like to upload version 0.9-2 which fixes #596009 and a so-far-unreported bug. The ganeti-instance-debootstrap package contains an OS definition for the Ganeti virtualization manager. […] Kind and hopefully non-intrusive ping? Please upload. Thanks. As expected, after uploading, and after pushing the changes to our git repo, and watching the commit emails, I saw a minor issue. So I uploaded 0.9-3, with this interdiff: diff -Nru ganeti-instance-debootstrap-0.9/debian/changelog ganeti-instance-debootstrap-0.9/debian/changelog --- ganeti-instance-debootstrap-0.9/debian/changelog2010-09-12 20:36:27.0 +0200 +++ ganeti-instance-debootstrap-0.9/debian/changelog2010-09-15 22:27:01.0 +0200 @@ -1,3 +1,9 @@ +ganeti-instance-debootstrap (0.9-3) unstable; urgency=low + + * Fix the mountpoint check in the recently-added hooks + + -- Iustin Pop ius...@debian.org Wed, 15 Sep 2010 22:26:24 +0200 + ganeti-instance-debootstrap (0.9-2) unstable; urgency=low * Add a hook for fixing Xen PVM console issues (Closes: #596009) diff -Nru ganeti-instance-debootstrap-0.9/debian/hooks/clear-root-password ganeti-instance-debootstrap-0.9/debian/hooks/clear-root-password --- ganeti-instance-debootstrap-0.9/debian/hooks/clear-root-password 2010-09-12 20:36:27.0 +0200 +++ ganeti-instance-debootstrap-0.9/debian/hooks/clear-root-password 2010-09-15 22:27:01.0 +0200 @@ -8,7 +8,7 @@ exit 1 fi -if [ $(mountpoint /) = $(mountpoint $TARGET) ]; then +if [ $(mountpoint -d /) = $(mountpoint -d $TARGET) ]; then echo The target directory seems to be the root dir, aborting. 12 exit 1 fi diff -Nru ganeti-instance-debootstrap-0.9/debian/hooks/xen-hvc0 ganeti-instance-debootstrap-0.9/debian/hooks/xen-hvc0 --- ganeti-instance-debootstrap-0.9/debian/hooks/xen-hvc0 2010-09-12 20:36:27.0 +0200 +++ ganeti-instance-debootstrap-0.9/debian/hooks/xen-hvc0 2010-09-15 22:27:01.0 +0200 @@ -8,7 +8,7 @@ exit 1 fi -if [ $(mountpoint /) = $(mountpoint $TARGET) ]; then +if [ $(mountpoint -d /) = $(mountpoint -d $TARGET) ]; then echo The target directory seems to be the root dir, aborting. 12 exit 1 fi The changes is adding -d to mountpoint, as the intention is that we don't operate on the root filesystem. I understand if you don't unblock this, it's entirely my fault. regards, iustin signature.asc Description: Digital signature
Re: Permission to upload ganeti-instance-debootstrap 0.9-2
On Sun, Sep 12, 2010 at 08:54:01PM +0200, Iustin Pop wrote: Hi, I'd like to upload version 0.9-2 which fixes #596009 and a so-far-unreported bug. The ganeti-instance-debootstrap package contains an OS definition for the Ganeti virtualization manager. […] Kind and hopefully non-intrusive ping? thanks, iustin signature.asc Description: Digital signature
Permission to upload ganeti-instance-debootstrap 0.9-2
Hi,
I'd like to upload version 0.9-2 which fixes #596009 and a
so-far-unreported bug. The ganeti-instance-debootstrap package contains
an OS definition for the Ganeti virtualization manager.
This OS creation can be customized using hooks (which are run via
run-parts), so I've added two hook to fix these issues.
#596009 is about the fact that Xen in squeeze uses hvc0 as the console
name, not tty0, so I've added a hook to add a getty on hvc0.
The other hook I've added removes root's password, since I realized that
the change to enable shadow by default makes root's account (after a
plain debootstrap run) have a disabled password, which makes login
impossible (and need manual editing). Since the Ganeti gnt-instance
console command which accesses the virtual machine console can only be
run by root, this is IMHO safe.
For these hooks I've used the mountpoint command, so I've added a
dependency on initscripts (non-versioned, as Lenny has the right
version, and possibly even Etch).
The other changes is the bumping of Standards version and replacing
Conflicts with Breaks. Both these are unimportant and can be reverted if
you think they shouldn't go in.
I've tested the new package and it makes creations of Xen instance work
fine again. Let me know if uploading is allright, and/or any comments
you might have. Attached is the debdiff on the dsc's, and the debs.
thanks!
iustin
diff -Nru ganeti-instance-debootstrap-0.9/debian/changelog
ganeti-instance-debootstrap-0.9/debian/changelog
--- ganeti-instance-debootstrap-0.9/debian/changelog2010-04-18
13:54:36.0 +0200
+++ ganeti-instance-debootstrap-0.9/debian/changelog2010-09-12
20:36:27.0 +0200
@@ -1,3 +1,12 @@
+ganeti-instance-debootstrap (0.9-2) unstable; urgency=low
+
+ * Add a hook for fixing Xen PVM console issues (Closes: #596009)
+ * Add a hook to set the root account to no password, to allow the
+initial login to proceed
+ * Standards version 3.9.1 (replace Conflicts with Breaks)
+
+ -- Iustin Pop ius...@debian.org Sun, 12 Sep 2010 19:58:52 +0200
+
ganeti-instance-debootstrap (0.9-1) unstable; urgency=low
* New Upstream version
diff -Nru ganeti-instance-debootstrap-0.9/debian/control
ganeti-instance-debootstrap-0.9/debian/control
--- ganeti-instance-debootstrap-0.9/debian/control 2010-04-18
13:54:36.0 +0200
+++ ganeti-instance-debootstrap-0.9/debian/control 2010-09-12
20:36:27.0 +0200
@@ -4,15 +4,15 @@
Maintainer: Debian Ganeti Team pkg-ganeti-de...@lists.alioth.debian.org
Uploaders: Guido Trotter ultrot...@debian.org, Iustin Pop ius...@debian.org
Build-Depends: debhelper (= 7)
-Standards-Version: 3.8.4
+Standards-Version: 3.9.1
Homepage: http://code.google.com/p/ganeti/
Vcs-Browser: http://git.debian.org/?p=pkg-ganeti/instance-debootstrap.git
Vcs-Git: git://git.debian.org/pkg-ganeti/instance-debootstrap.git
Package: ganeti-instance-debootstrap
Architecture: all
-Depends: ${misc:Depends}, debootstrap, dump, kpartx
-Conflicts: ganeti ( 1.2.7)
+Depends: ${misc:Depends}, debootstrap, dump, kpartx, initscripts
+Breaks: ganeti ( 1.2.7)
Enhances: ganeti
Description: debootstrap-based instance OS definition for ganeti
Ganeti is a virtual server cluster management software tool built on
diff -Nru ganeti-instance-debootstrap-0.9/debian/hooks/clear-root-password
ganeti-instance-debootstrap-0.9/debian/hooks/clear-root-password
--- ganeti-instance-debootstrap-0.9/debian/hooks/clear-root-password
1970-01-01 01:00:00.0 +0100
+++ ganeti-instance-debootstrap-0.9/debian/hooks/clear-root-password
2010-09-12 20:36:27.0 +0200
@@ -0,0 +1,21 @@
+#!/bin/sh
+
+set -e
+
+# Make sure we're not working on the root directory
+if [ -z $TARGET -o $TARGET = / ]; then
+echo Invalid target directory '$TARGET', aborting. 12
+exit 1
+fi
+
+if [ $(mountpoint /) = $(mountpoint $TARGET) ]; then
+echo The target directory seems to be the root dir, aborting. 12
+exit 1
+fi
+
+# Disable root's password, as the switch to enable shadow by default
+# has left root with a disabled password, preventing the initial login
+echo Disabling root's password
+chroot $TARGET passwd -d root
+
+exit 0
diff -Nru ganeti-instance-debootstrap-0.9/debian/hooks/xen-hvc0
ganeti-instance-debootstrap-0.9/debian/hooks/xen-hvc0
--- ganeti-instance-debootstrap-0.9/debian/hooks/xen-hvc0 1970-01-01
01:00:00.0 +0100
+++ ganeti-instance-debootstrap-0.9/debian/hooks/xen-hvc0 2010-09-12
20:36:27.0 +0200
@@ -0,0 +1,24 @@
+#!/bin/sh
+
+set -e
+
+# Make sure we're not working on the root directory
+if [ -z $TARGET -o $TARGET = / ]; then
+echo Invalid target directory '$TARGET', aborting. 12
+exit 1
+fi
+
+if [ $(mountpoint /) = $(mountpoint $TARGET) ]; then
+echo The target directory seems to be the root dir, aborting. 12
+exit 1
+fi
+
+# Fix the console information for xen-pvm mode
+if [ $HYPERVISOR = xen-pvm ]; then
+echo xen-pvm hypervisor detected
Question - is there an automatic unblock for fixed RC bugs?
Hi all, I did a NMU and a QA upload two weeks ago, both fixing an RC bug, and today I wanted to send the request for unblocking these. However—lo and behold—both were unblocked over the weekend. Was this an automatic unblock, because RC bugs were fixed, or a manual one? I'm just curious, to understand how the freeze exceptions work, that's all—I don't complain about the unblocks! The packages in question are localpurge and qtparted. thanks, iustin -- 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/20100906092149.ga14...@teal.hq.k1024.org
Re: Freeze exception (python-pylibacl, python-pyxattr)?
On Tue, Aug 17, 2010 at 10:05:10PM +0200, Iustin Pop wrote: On Tue, Aug 17, 2010 at 09:27:18AM +0200, Philipp Kern wrote: Iustin, sorry for not coming back to you earlier. Not a problem, I was on vacation :) On 08/07/2010 12:36 PM, Iustin Pop wrote: Oh, these are old conflicts from etch (IIRC) from when the python policy was to generate separate packages for each Python version, and I just changed them to Breaks according to the policy 3.9.0. I guess they can be dropped completely, but I wanted to do that only after squeeze. Did I misread the policy regarding when to use conflicts/breaks? I don't think you should change those old Conflicts to Breaks, though. The issue is not transient and there is nothing to upgrade to. I have to admit that this new policy requirement was new to me, but considering that we had some trouble ensuring proper upgrade paths when Breaks were used, Conflicts seem more appropriate to leave. I see. But FWIW we do not support skipping stable releases. So if you are certain that they were not in Lenny (and already conflicted against), then you can just drop it. Yes, Lenny has the 0.4.0 version of pyxattr, and the conflict is against 0.2.1-1.1. Similar for pylibacl. In this case, I will prepare a new upload to unstable, which removes the Replaces and Breaks entirely. I'll ping this thread again once the usual 10-day have passed and the packages would otherwise be ready for migration. OK, these should be fine to go in now. Could you please unblock them? thanks, iustin signature.asc Description: Digital signature
Re: Freeze exception (python-pylibacl, python-pyxattr)?
On Tue, Aug 17, 2010 at 09:27:18AM +0200, Philipp Kern wrote: Iustin, sorry for not coming back to you earlier. Not a problem, I was on vacation :) On 08/07/2010 12:36 PM, Iustin Pop wrote: Oh, these are old conflicts from etch (IIRC) from when the python policy was to generate separate packages for each Python version, and I just changed them to Breaks according to the policy 3.9.0. I guess they can be dropped completely, but I wanted to do that only after squeeze. Did I misread the policy regarding when to use conflicts/breaks? I don't think you should change those old Conflicts to Breaks, though. The issue is not transient and there is nothing to upgrade to. I have to admit that this new policy requirement was new to me, but considering that we had some trouble ensuring proper upgrade paths when Breaks were used, Conflicts seem more appropriate to leave. I see. But FWIW we do not support skipping stable releases. So if you are certain that they were not in Lenny (and already conflicted against), then you can just drop it. Yes, Lenny has the 0.4.0 version of pyxattr, and the conflict is against 0.2.1-1.1. Similar for pylibacl. In this case, I will prepare a new upload to unstable, which removes the Replaces and Breaks entirely. I'll ping this thread again once the usual 10-day have passed and the packages would otherwise be ready for migration. thank you! iustin signature.asc Description: Digital signature
Re: Freeze exception (python-pylibacl, python-pyxattr)?
On Fri, Aug 06, 2010 at 02:49:47PM -0400, Philipp Kern wrote: Iustin, On 08/06/2010 01:11 PM, Iustin Pop wrote: I uploaded these two packages yesterday, and I was hoping they will get into testing. But I see now both marked as Not touching package due to block request by freeze. Even though they were uploaded yesterday :) The only difference from current testing version is the new -dbg package, which eliminates the delta between Debian and Ubuntu. So it's not a big issues if they don't migrate, but it would be nice… so what about this: -Conflicts: python2.3-pylibacl ( 0.2.1-3.1), python2.4-pylibacl ( 0.2.1-3.1) +Breaks: python2.3-pylibacl ( 0.2.1-3.1), python2.4-pylibacl ( 0.2.1-3.1) It's not mentioned in the changelog at all and I'm unsure what you want to achieve with that, given that neither of them is even in stable and also given that it would only help if there were actually a new version of them, no? Same for python-pyxattr... Oh, these are old conflicts from etch (IIRC) from when the python policy was to generate separate packages for each Python version, and I just changed them to Breaks according to the policy 3.9.0. I guess they can be dropped completely, but I wanted to do that only after squeeze. Did I misread the policy regarding when to use conflicts/breaks? thanks, iustin signature.asc Description: Digital signature
Freeze exception (python-pylibacl, python-pyxattr)?
Hi, I uploaded these two packages yesterday, and I was hoping they will get into testing. But I see now both marked as Not touching package due to block request by freeze. Even though they were uploaded yesterday :) The only difference from current testing version is the new -dbg package, which eliminates the delta between Debian and Ubuntu. So it's not a big issues if they don't migrate, but it would be nice… thanks for considering, iustin signature.asc Description: Digital signature
Re: Bits from the Release Team: What should go into squeeze?
On Sun, Mar 14, 2010 at 09:42:58PM +0100, Philipp Kern wrote: Dear fellow developers, we all want to get out squeeze as soon as possible. Currently we are still at 400 bugs concerning the next stable release, with 300 of them not yet fixed in unstable. We would like to know what needs attention, what bugs still need to be fixed in your package before squeeze is released, which features or new upstream versions you want to see in squeeze which are not ready yet. Furthermore we would like to get an overview of the remaining transitions that need to be done. Does your request for information apply to packages with low popcount count? If so, then read on… On behalf of a very very small team, with very few packages: we'd like to ship Ganeti 2.1 in Squeeze instead of the current 2.0. The delta between these is big, but as upstream we can confirm that 2.1 is stable and has a lot of general bug fixes compared to 2.0, and the only reason why we haven't yet uploaded it to unstable is that we're still debating the preferred migration path from Lenny's 1.2 to 2.1 (as upstream we supported only 1.2→2.0 and 2.0→2.1, but we're close to a working solution for 1.2→2.1 upgrade). Unless there's any issue preventing this, our plans were to upload 2.1 this coming weekend. There are some other small incremental releases in the other packages we maintain, but nothing major there. thanks, iustin -- 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/20100315201137.gb15...@teal.hq.k1024.org
Re: Bug#540317: libcompizconfig0: Uninstalable due to libprotobuf3 removal
On Sat, Aug 22, 2009 at 11:19:07PM +0200, Philipp Kern wrote: On Fri, Aug 07, 2009 at 09:29:04AM +0200, Jean-Luc Coulon (f5ibh) wrote: libprotobuf3 has been removed. So libcompizconfig0 (and the whole compiz stack) is uninstalable. I've scheduled binNMUs for this package now. (Seems to be the only rdep of libprotobuf3 apart from protobuf itself.) Iustin, as you have rdeps now on that library, please notify -release on a transition next time. Thanks. Sorry, I did notify the maintainers of the rdeps of libprotobufN (a while ago) but I didn't realise that I need to notify -release. My apologies. thanks, iustin -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Stable update proposed for ganeti (fixing #528618)
On Tue, Aug 04, 2009 at 05:01:39PM +0100, Adam D. Barratt wrote: Iustin Pop wrote: On Tue, Jul 28, 2009 at 08:05:15PM +0200, Iustin Pop wrote: Hi, I'd like to update ganeti to stable-proposed-updates to fix the above bug. It's a simple one-line change; I see only one potential breakage out of it - if people already did the symlink fix pointed out in the bug, but with the symlink pointing to a different version of Xen, then this version will change what xen version they use. More clearly: - if currently /usr/lib/xen points to anything else than /usr/lib/xen-3.2-1, then - this upload will break people's HVM-based clusters Here is the proposed diff: […] Let me know if this is OK or not, or if you need more information. Ping? Did I miss some crucial information that is needed? The one thing that concerns me is the potential breakage you raised yourself. Is it possible to detect that the user has moved the symlink and leave it as-is? Well, if we're looking at a minimal diff then not. Basically, upstream has hardcoded /usr/lib/xen, but Lenny has /usr/lib/xen-3.2-1. The current patch just changes the hardcoded path. A flexible solution would be to change this to /usr/lib/xen-ganeti, which would be a symlink created at package install time to point to either /usr/lib/xen (if it already exists, which means users have customized their system to fit the current buggy upstream) or to /usr/lib/xen-3.2-1 (or the first xen directory found). This would mean a bigger diff, and seems to me slightly worse than a NEWS.Debian entry detailing the change; but granted, it would be automatic. What is usually done in a such a situation? Another alternative would be to abort install if /usr/lib/xen points to something else. But this would be bad. thanks! iustin -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Stable update proposed for ganeti (fixing #528618)
On Tue, Jul 28, 2009 at 08:05:15PM +0200, Iustin Pop wrote: Hi, I'd like to update ganeti to stable-proposed-updates to fix the above bug. It's a simple one-line change; I see only one potential breakage out of it - if people already did the symlink fix pointed out in the bug, but with the symlink pointing to a different version of Xen, then this version will change what xen version they use. More clearly: - if currently /usr/lib/xen points to anything else than /usr/lib/xen-3.2-1, then - this upload will break people's HVM-based clusters Here is the proposed diff: […] Let me know if this is OK or not, or if you need more information. Ping? Did I miss some crucial information that is needed? thanks in advance, iustin -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Stable update proposed for ganeti (fixing #528618)
Hi, I'd like to update ganeti to stable-proposed-updates to fix the above bug. It's a simple one-line change; I see only one potential breakage out of it - if people already did the symlink fix pointed out in the bug, but with the symlink pointing to a different version of Xen, then this version will change what xen version they use. More clearly: - if currently /usr/lib/xen points to anything else than /usr/lib/xen-3.2-1, then - this upload will break people's HVM-based clusters Here is the proposed diff: diff -u ganeti-1.2.6/debian/changelog ganeti-1.2.6/debian/changelog --- ganeti-1.2.6/debian/changelog +++ ganeti-1.2.6/debian/changelog @@ -1,3 +1,10 @@ +ganeti (1.2.6-3+lenny1) stable; urgency=low + + * Fix hvmloader path to match Lenny's xen-utils-3.2-1 +(Closes: #528618) + + -- Iustin Pop iu...@k1024.org Tue, 28 Jul 2009 19:29:14 +0200 + ganeti (1.2.6-3) unstable; urgency=low * Cherry-pick commit 2461 from upstream, fixing (yet again, hopefully only in patch2: unchanged: --- ganeti-1.2.6.orig/debian/patches/01-fix-lenny-hvmloader.patch +++ ganeti-1.2.6/debian/patches/01-fix-lenny-hvmloader.patch @@ -0,0 +1,16 @@ +This is a fix for #528618 + +Iustin Pop, iu...@k1024.org Tue, 28 Jul 2009 18:18:40 +0200 +diff --git a/lib/hypervisor.py b/lib/hypervisor.py +index 4a8d892..d76c773 100644 +--- a/lib/hypervisor.py b/lib/hypervisor.py +@@ -635,7 +635,7 @@ class XenHvmHypervisor(XenHypervisor): + + config = StringIO() + config.write(# this is autogenerated by Ganeti, please do not edit\n#\n) +-config.write(kernel = '/usr/lib/xen/boot/hvmloader'\n) ++config.write(kernel = '/usr/lib/xen-3.2-1/boot/hvmloader'\n) + config.write(builder = 'hvm'\n) + config.write(memory = %d\n % instance.memory) + config.write(vcpus = %d\n % instance.vcpus) Let me know if this is OK or not, or if you need more information. thanks, iustin -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
ganeti-1.2.6-3 for Lenny? Lenny r1?
Hi, I'm more seeking clarification than requesting unblock. Yesterday ganeti-1.2.6-3 was uploaded to unstable, fixing a bug we (upstream) have been hunting for around a month. The bug (510965) is a real bug that affects all users, however in some cases it (as in my virtualbox VMs) it has no impact. When it does affect a user, the package stops working (completely). So the bug was only 'important' and not 'grave'. Now the question is, since it's very very late for Lenny release, could this go into the next Lenny release? The debdiff between the 1.2.6-2 and 1.2.6-3 is only the patch + a debian/watch change, we have not uploaded new upstream versions in order to minimize the impact of late changes. thanks, iustin -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Please allow ganeti into Lenny
Hi, The ganeti package was removed from testing a while ago because Xen was no longer available in Lenny (see bug #474452). IOW the reason for removal was not the package itself, but unfulfillable recommends. However, now Xen is available again and I'm wondering if we can get ganeti back into testing, and hopefully released in Lenny. There are no other bugs on this package, and as upstream I can confirm this version is stable for production use. thanks, iustin -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
