Bug#999659: perdition: diff for NMU version 2.2-3.2
On Sat, Apr 02, 2022 at 01:44:41PM -0300, Marcos Talau wrote: > Control: tags 999659 + patch > Control: tags 999659 + pending > > Dear maintainer, > > I've prepared an NMU for perdition (versioned as 2.2-3.2) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. Thanks, this is very much appreciated. Please go ahead, I see no reason to delay.
Bug#768618: Bug#768922: Bug#768618: pacemaker: FTBFS in jessie: build-dependency not installable: libqb-dev (= 0.16.0.real)
On Mon, Jan 19, 2015 at 09:26:36AM +0900, Christian Balzer wrote: Well... Meanwhile, here in what it what we tenuously call reality one can observe the following things: 1. Pacemaker broken in Jessie for more than 2 months now. 2. Silence on this bug for more than one month. 3. Pacemaker was recently removed from Jessie. 4. The February 5th deadline is rapidly approaching, cue the laughingstock. Between systemd and this gem Jessie is shaping up to be the best Debian release ever... I wonder if there are any active members of the Debian linux-ha team. Speaking for and pointing the finger at myself for one who has been inactive for several years. I for one would be happy to see an NMU here. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771863: [ovs-dev] Bug#771863: [PKG-Openstack-devel] Bug#771863: Service does not start or parse interfaces correctly
On Fri, Dec 19, 2014 at 06:39:39PM +0800, Thomas Goirand wrote: On 12/19/2014 11:50 AM, Simon Horman wrote: On Thu, Dec 18, 2014 at 05:30:42PM -0800, Joe Stringer wrote: On 18 December 2014 at 01:00, Fabio Fantoni fabio.fant...@m2r.biz wrote: One maintainer or debian developer can do a new build of ovs with the fix available in 2.3.1 please? * Version 2.3.0+git20140819-2 of openvswitch is marked for autoremoval from testing on 2015-01-15. * It is affected by RC bug #771863 https://bugs.debian.org/771863. Without this fix openvswitch will be removed from Jessie and I think this would be a bad thing. Thanks for any reply and sorry for my bad english. Ben usually takes care of this sort of thing, but he is out on holiday through to Christmas. Simon, would you be able to take care of this? Sure, I have uploaded a fresh package which attempts to do so. It contains no other changes. Simon, Did you ask for an unblock to the release team? Hi Thomas, I would be grateful for some assistance understanding what needs to be done there. At this point I have not made any unblock requests. But the intention of this upload was to provide something to be included in Jessie and thus it needs to migrate to testing somehow. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771863: [PKG-Openstack-devel] [ovs-dev] Bug#771863: Bug#771863: Service does not start or parse interfaces correctly
On Fri, Dec 19, 2014 at 11:43:42PM +0800, Thomas Goirand wrote: On 12/19/2014 11:32 PM, Thomas Goirand wrote: On 12/19/2014 10:25 PM, Simon Horman wrote: On Fri, Dec 19, 2014 at 06:39:39PM +0800, Thomas Goirand wrote: On 12/19/2014 11:50 AM, Simon Horman wrote: On Thu, Dec 18, 2014 at 05:30:42PM -0800, Joe Stringer wrote: On 18 December 2014 at 01:00, Fabio Fantoni fabio.fant...@m2r.biz wrote: One maintainer or debian developer can do a new build of ovs with the fix available in 2.3.1 please? * Version 2.3.0+git20140819-2 of openvswitch is marked for autoremoval from testing on 2015-01-15. * It is affected by RC bug #771863 https://bugs.debian.org/771863. Without this fix openvswitch will be removed from Jessie and I think this would be a bad thing. Thanks for any reply and sorry for my bad english. Ben usually takes care of this sort of thing, but he is out on holiday through to Christmas. Simon, would you be able to take care of this? Sure, I have uploaded a fresh package which attempts to do so. It contains no other changes. Simon, Did you ask for an unblock to the release team? Hi Thomas, I would be grateful for some assistance understanding what needs to be done there. At this point I have not made any unblock requests. But the intention of this upload was to provide something to be included in Jessie and thus it needs to migrate to testing somehow. I'm sending the unblock request as we speak. Thomas https://bugs.debian.org/773534 Thanks. I sent one too, following Fabio Fantoni's excellent advice. I suppose the two bugs can be merged if/when mine shows up in the bug tracker. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771863: [ovs-dev] Bug#771863: Service does not start or parse interfaces correctly
On Thu, Dec 18, 2014 at 05:30:42PM -0800, Joe Stringer wrote: On 18 December 2014 at 01:00, Fabio Fantoni fabio.fant...@m2r.biz wrote: One maintainer or debian developer can do a new build of ovs with the fix available in 2.3.1 please? * Version 2.3.0+git20140819-2 of openvswitch is marked for autoremoval from testing on 2015-01-15. * It is affected by RC bug #771863 https://bugs.debian.org/771863. Without this fix openvswitch will be removed from Jessie and I think this would be a bad thing. Thanks for any reply and sorry for my bad english. Ben usually takes care of this sort of thing, but he is out on holiday through to Christmas. Simon, would you be able to take care of this? Sure, I have uploaded a fresh package which attempts to do so. It contains no other changes. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681880: [ovs-dev] [debian 1/9] lockfile: Fix hang locking through a dangling symlink.
On Mon, Jul 30, 2012 at 03:18:16PM -0700, Ben Pfaff wrote: open() with O_CREAT|O_EXCL yields EEXIST if the file being opened is a symlink. lockfile_try_lock() interpreted that error code to mean that some other process had created the lock file in the meantime, so it went around its loop again, which found out the same thing, which led to a hang. This commit fixes the problem by dropping O_EXCL. I don't see any reason that it's actually necessary. That means that the loop itself is unnecessary, so this commit drops that too. Debian bug #681880. CC: 681...@bugs.debian.org Reported-by: Bastian Blank wa...@debian.org Signed-off-by: Ben Pfaff b...@nicira.com Reviewed-by: Simon Horman ho...@verge.net.au -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681880: [ovs-dev] [debian 2/9] ovsdb: Make ovsdb-tool create work through a dangling symlink.
On Mon, Jul 30, 2012 at 03:18:17PM -0700, Ben Pfaff wrote: open() with O_CREAT|O_EXCL yields EEXIST if the name passed in is a symlink, but we would like ovsdb-tool create /etc/openvswitch/conf.db to work if /etc/openvswitch/conf.db is a symlink to elsewhere in the file system. This commit fixes the problem. It introduces a theoretical race, but no one should be doing ovsdb-tool create in parallel anyhow; O_EXCL is just an idiot check here, not required to be fail-safe. Debian bug #681880. CC: 681...@bugs.debian.org Reported-by: Bastian Blank wa...@debian.org Signed-off-by: Ben Pfaff b...@nicira.com Reviewed-by: Simon Horman ho...@verge.net.au -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681880: [ovs-dev] [debian 3/9] debian: Move database from /etc/openvswitch to /var/lib/openvswitch.
On Mon, Jul 30, 2012 at 03:18:18PM -0700, Ben Pfaff wrote: Debian bug #681880. CC: 681...@bugs.debian.org Reported-by: Bastian Blank wa...@debian.org Reviewed-by: Simon Horman ho...@verge.net.au -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681880: [ovs-dev] Bug#681880: openvswitch-switch - Automatic changed file in /etc/
On Thu, Jul 26, 2012 at 10:59:05AM +0200, Bastian Blank wrote: On Wed, Jul 18, 2012 at 07:01:42AM -0700, Ben Pfaff wrote: On Wed, Jul 18, 2012 at 10:00:49AM +0200, Bastian Blank wrote: No. It is no configuration file if it is not static. The FHS defines static as: Static files include binaries, libraries, documentation files and other files that do not change without system administrator intervention. Variable files are files that are not static. The system administrator runs ovs-vsctl to change /etc/openvswitch/conf.db. You forget all virtualization stuff. There no admin intervention is used. Is the argument that if a file is ever modified other than directly by the administrator it is not a configuration file? How does modifying this file with an editor work? It's somewhat challenging, because you have to calculate a sha1sum with the sha1sum program, and the format isn't really intended for direct human editing. But, as I said before (you dropped the quote), I do not see anything in 10.7 that says that the administrator must be able to edit a configuration file with a text editor. So it is not meant to be modified by a user. Is the format of a file relevant to determining if it is a configuration file or not? How does it survive read-only /etc? If you have read-only /etc, then you can't modify your configuration, in the same way you can't modify other parts of your configuration. conf.db is open read-write by ovsdb-server. Bastian -- Deflector shields just came on, Captain. ___ dev mailing list d...@openvswitch.org http://openvswitch.org/mailman/listinfo/dev -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681880: [ovs-dev] [bug 681880 2/3] ovsdb: Make ovsdb-tool create work through a dangling symlink.
On Thu, Jul 26, 2012 at 02:48:52PM -0700, Ben Pfaff wrote:
open() with O_CREAT|O_EXCL yields EEXIST if the name passed in is a
symlink, but we would like ovsdb-tool create /etc/openvswitch/conf.db to
work if /etc/openvswitch/conf.db is a symlink to elsewhere in the file
system. This commit fixes the problem. It introduces a theoretical race,
but no one should be doing ovsdb-tool create in parallel anyhow; O_EXCL
is just an idiot check here, not required to be fail-safe.
I'm comfortable with this provided that the location of conf.db is
a directory that is is only accessible by the administrator. Else I think
there may be some problems from a security POV.
Debian bug #681880.
CC: 681...@bugs.debian.org
Reported-by: Bastian Blank wa...@debian.org
Signed-off-by: Ben Pfaff b...@nicira.com
---
ovsdb/log.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/ovsdb/log.c b/ovsdb/log.c
index ab4a150..9b882dc 100644
--- a/ovsdb/log.c
+++ b/ovsdb/log.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2009, 2010, 2011 Nicira, Inc.
+/* Copyright (c) 2009, 2010, 2011, 2012 Nicira, Inc.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
@@ -95,7 +95,16 @@ ovsdb_log_open(const char *name, enum ovsdb_log_open_mode
open_mode,
} else if (open_mode == OVSDB_LOG_READ_WRITE) {
flags = O_RDWR;
} else if (open_mode == OVSDB_LOG_CREATE) {
-flags = O_RDWR | O_CREAT | O_EXCL;
+if (stat(name, s) == -1 errno == ENOENT
+ lstat(name, s) == 0 S_ISLNK(s.st_mode)) {
+/* 'name' is a dangling symlink. We want to create the file that
+ * the symlink points to, but POSIX says that open() with O_EXCL
+ * must fail with EEXIST if the named file is a symlink. So, we
+ * have to leave off O_EXCL and accept the race. */
+flags = O_RDWR | O_CREAT;
+} else {
+flags = O_RDWR | O_CREAT | O_EXCL;
+}
} else {
NOT_REACHED();
}
--
1.7.2.5
___
dev mailing list
d...@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681880: [ovs-dev] [bug 681880 3/3] debian: Move database from /etc/openvswitch to /var/lib/openvswitch.
Acked-by: Simon Horman ho...@verge.net.au On Thu, Jul 26, 2012 at 02:48:53PM -0700, Ben Pfaff wrote: Debian bug #681880. CC: 681...@bugs.debian.org Reported-by: Bastian Blank wa...@debian.org Signed-off-by: Ben Pfaff b...@nicira.com --- REPORTING-BUGS |2 +- debian/automake.mk |1 + debian/openvswitch-switch.dirs |1 + debian/openvswitch-switch.postinst | 15 +++ debian/openvswitch-switch.postrm |4 +- debian/openvswitch-switch.prerm| 50 6 files changed, 70 insertions(+), 3 deletions(-) create mode 100755 debian/openvswitch-switch.prerm diff --git a/REPORTING-BUGS b/REPORTING-BUGS index 86510d2..af0096b 100644 --- a/REPORTING-BUGS +++ b/REPORTING-BUGS @@ -32,7 +32,7 @@ The following are also handy sometimes: your OS (e.g. Centos 5.0). * The contents of the vswitchd configuration database (usually - /etc/openvswitch/conf.db). + /etc/openvswitch/conf.db or /var/lib/openvswitch/conf.db). * The output of ovs-dpctl show. diff --git a/debian/automake.mk b/debian/automake.mk index b6cb12e..b025cdd 100644 --- a/debian/automake.mk +++ b/debian/automake.mk @@ -44,6 +44,7 @@ EXTRA_DIST += \ debian/openvswitch-switch.manpages \ debian/openvswitch-switch.postinst \ debian/openvswitch-switch.postrm \ + debian/openvswitch-switch.prerm \ debian/openvswitch-switch.template \ debian/openvswitch-switch.links \ debian/openvswitch-test.dirs \ diff --git a/debian/openvswitch-switch.dirs b/debian/openvswitch-switch.dirs index 0b1f281..ccbbbf7 100644 --- a/debian/openvswitch-switch.dirs +++ b/debian/openvswitch-switch.dirs @@ -1,2 +1,3 @@ /etc/openvswitch +/var/lib/openvswitch /usr/share/openvswitch/switch diff --git a/debian/openvswitch-switch.postinst b/debian/openvswitch-switch.postinst index 7b9d7bc..38e1eee 100755 --- a/debian/openvswitch-switch.postinst +++ b/debian/openvswitch-switch.postinst @@ -33,6 +33,21 @@ case $1 in fi done fi + + # Ensure that /etc/openvswitch/conf.db links to /var/lib/openvswitch, + # moving an existing file if there is one. + # + # Ditto for .conf.db.~lock~. + for base in conf.db .conf.db.~lock~; do + new=/var/lib/openvswitch/$base + old=/etc/openvswitch/$base + if test -f $old test ! -e $new; then + mv $old $new + fi + if test ! -e $old test ! -h $old; then + ln -s $new $old + fi + done ;; abort-upgrade|abort-remove|abort-deconfigure) diff --git a/debian/openvswitch-switch.postrm b/debian/openvswitch-switch.postrm index 88bf9fc..ff4ae4a 100755 --- a/debian/openvswitch-switch.postrm +++ b/debian/openvswitch-switch.postrm @@ -21,8 +21,8 @@ set -e case $1 in purge) -rm -f /etc/openvswitch/conf.db -rm -f /etc/openvswitch/.conf.db.~lock~ +rm -f /etc/openvswitch/conf.db /etc/openvswitch/.conf.db.~lock~ +rm -f /var/lib/openvswitch/conf.db /var/lib/openvswitch/.conf.db.~lock~ rm -f /etc/default/openvswitch-switch rm -f /var/log/openvswitch/ovs-vswitchd.log* || true rm -f /var/log/openvswitch/ovsdb-server.log* || true diff --git a/debian/openvswitch-switch.prerm b/debian/openvswitch-switch.prerm new file mode 100755 index 000..9221ef1 --- /dev/null +++ b/debian/openvswitch-switch.prerm @@ -0,0 +1,50 @@ +#!/bin/sh +# prerm script for openvswitch-switch +# +# see: dh_installdeb(1) + +set -e + +# summary of how this script can be called: +#* prerm `remove' +#* old-prerm `upgrade' new-version +#* new-prerm `failed-upgrade' old-version +#* conflictor's-prerm `remove' `in-favour' package new-version +#* deconfigured's-prerm `deconfigure' `in-favour' +# package-being-installed version `removing' +# conflicting-package version +# for details, see http://www.debian.org/doc/debian-policy/ or +# the debian-policy package + + +case $1 in +upgrade) +# Ensure that conf.db and its lockfile in /etc/openvswitch are not +# dangling symlinks, because this caused ovsdb-server to hang at +# startup in versions of OVS older than 1.4.2+git20120612-7. +for base in conf.db .conf.db.~lock~; do +fn=/etc/openvswitch/$base +if test -h $fn test ! -e $fn; then +rm -f $fn +fi +done +;; + +remove|deconfigure) +;; + +failed-upgrade) +;; + +*) +echo prerm called with unknown argument \`$1' 2 +exit 1 +;; +esac + +# dh_installdeb will replace this with shell code automatically +# generated by other debhelper scripts. + +#DEBHELPER# + +exit 0 -- 1.7.2.5
Bug#681880: [ovs-dev] [bug 681880 1/3] lockfile: Fix hang locking through a dangling symlink.
On Thu, Jul 26, 2012 at 02:48:51PM -0700, Ben Pfaff wrote: open() with O_CREAT|O_EXCL yields EEXIST if the file being opened is a symlink. lockfile_try_lock() interpreted that error code to mean that some other process had created the lock file in the meantime, so it went around its loop again, which found out the same thing, which led to a hang. This commit fixes the problem by dropping O_EXCL. I don't see any reason that it's actually necessary. That means that the loop itself is unnecessary, so this commit drops that too. Acked-by: Simon Horman ho...@verge.net.au Debian bug #681880. CC: 681...@bugs.debian.org Reported-by: Bastian Blank wa...@debian.org Signed-off-by: Ben Pfaff b...@nicira.com --- lib/lockfile.c| 50 +++- tests/lockfile.at |1 + tests/test-lockfile.c | 38 - 3 files changed, 54 insertions(+), 35 deletions(-) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681955: [ovs-dev] [PATCH] ovs-ctl: Start the rest of Open vSwitch if loading brcompat module fails.
On Thu, Jul 26, 2012 at 03:01:26PM -0700, Ben Pfaff wrote:
This may be more useful in practice than failing the entire OVS startup
sequence.
Acked-by: Simon Horman ho...@verge.net.au
Debian bug #681955.
CC: 681...@bugs.debian.org
Reported-by: Bastian Blank wa...@debian.org
Signed-off-by: Ben Pfaff b...@nicira.com
---
utilities/ovs-ctl.in |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in
index 552cef3..9925fdb 100755
--- a/utilities/ovs-ctl.in
+++ b/utilities/ovs-ctl.in
@@ -64,7 +64,12 @@ insert_brcompat_mod_if_required () {
insert_mod_if_required () {
insert_openvswitch_mod_if_required || return 1
if test X$BRCOMPAT = Xyes; then
-insert_brcompat_mod_if_required || return 1
+if insert_brcompat_mod_if_required; then
+:
+else
+log_warning_msg brcompat module could not be loaded, disabling
bridge compatibility
+BRCOMPAT=no
+fi
fi
}
--
1.7.2.5
___
dev mailing list
d...@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681880: [ovs-dev] [bug 681880 2/3] ovsdb: Make ovsdb-tool create work through a dangling symlink.
On Thu, Jul 26, 2012 at 06:10:26PM -0700, Ben Pfaff wrote: On Fri, Jul 27, 2012 at 09:47:49AM +0900, Simon Horman wrote: On Thu, Jul 26, 2012 at 02:48:52PM -0700, Ben Pfaff wrote: open() with O_CREAT|O_EXCL yields EEXIST if the name passed in is a symlink, but we would like ovsdb-tool create /etc/openvswitch/conf.db to work if /etc/openvswitch/conf.db is a symlink to elsewhere in the file system. This commit fixes the problem. It introduces a theoretical race, but no one should be doing ovsdb-tool create in parallel anyhow; O_EXCL is just an idiot check here, not required to be fail-safe. I'm comfortable with this provided that the location of conf.db is a directory that is is only accessible by the administrator. Else I think there may be some problems from a security POV. Good point. It's a symlink from /etc/openvswitch to /var/lib/openvswitch. Both of those are only writable by the admin, so I think we're safe on that account. Thanks, I am comfortable with that. Acked-by: Simon Horman ho...@verge.net.au -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682384: [ovs-dev] [PATCH] Fix race condition in parallel execution of make install.
On Mon, Jul 23, 2012 at 09:58:19AM -0700, Ben Pfaff wrote: ovs-vsctl is listed, incorrectly, in both bin_PROGRAMS and bin_SCRIPTS. This meant that make install with the -j option could try to install ovs-vsctl two times in parallel, a race that occasionally caused a build failure, e.g.: http://buildd.debian.org/status/fetch.php?pkg=openvswitcharch=s390ver=1.4.2%2Bgit20120612-5stamp=1342851603 Debian bug #682384. CC: 682...@bugs.debian.org Reported-by: Bastian Blank wa...@debian.org Signed-off-by: Ben Pfaff b...@nicira.com --- I already uploaded this to Debian as -6. I'll wait for a review before pushing it to the OVS repository. Ouch. Acked-by: Simon Horman ho...@verge.net.au -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680537: [ovs-dev] [PATCH] debian: Do not change iptables rules by default.
On Thu, Jul 12, 2012 at 09:17:11PM -0700, Ben Pfaff wrote:
Debian kernel maintainer Bastian Blank writes, at
http://bugs.debian.org/680537:
The netfilter rules are a shared resource. There is no synchronization,
so the admin have the last word. As kernel maintainer, I see it similar
to a configuration file, so §10.7 policy applies.
The purpose of openvswitch is to provide support for switching, not to
setup filter rules. This means it violates the principle of least
surprise.
I believe that the argument by analogy to configuration files is weak,
given that the Debian policy section in question is very specifically about
files, not about general principles. On the other hand, Debian does not
install any firewall by default, so the presence of a rule that blocks GRE
traffic is a sign that the administrator has taken an explicit action to
install a firewall that blocks GRE, and therefore it is rather rude to
override this. Therefore, this patch simply turns off this behavior on
Debian, given that in ordinary Debian installations it will have no
adverse effect on Open vSwitch.
FWIW, I am in complete agreement with Ben on this.
Debian bug #680537.
CC: 680...@bugs.debian.org
Reported-by: Bastian Blank wa...@debian.org
Signed-off-by: Ben Pfaff b...@nicira.com
---
debian/openvswitch-switch.init |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/debian/openvswitch-switch.init b/debian/openvswitch-switch.init
index 3c93720..f650f87 100755
--- a/debian/openvswitch-switch.init
+++ b/debian/openvswitch-switch.init
@@ -72,8 +72,6 @@ start () {
fi
set $@ $OVS_CTL_OPTS
$@ || exit $?
-
-ovs_ctl --protocol=gre enable-protocol
}
stop () {
--
1.7.2.5
___
dev mailing list
d...@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680537: [ovs-dev] [PATCH] debian: Do not change iptables rules by default.
On Thu, Jul 12, 2012 at 09:48:34PM -0700, Ben Pfaff wrote: On Fri, Jul 13, 2012 at 01:46:39PM +0900, Simon Horman wrote: On Thu, Jul 12, 2012 at 09:17:11PM -0700, Ben Pfaff wrote: Debian kernel maintainer Bastian Blank writes, at http://bugs.debian.org/680537: The netfilter rules are a shared resource. There is no synchronization, so the admin have the last word. As kernel maintainer, I see it similar to a configuration file, so §10.7 policy applies. The purpose of openvswitch is to provide support for switching, not to setup filter rules. This means it violates the principle of least surprise. I believe that the argument by analogy to configuration files is weak, given that the Debian policy section in question is very specifically about files, not about general principles. On the other hand, Debian does not install any firewall by default, so the presence of a rule that blocks GRE traffic is a sign that the administrator has taken an explicit action to install a firewall that blocks GRE, and therefore it is rather rude to override this. Therefore, this patch simply turns off this behavior on Debian, given that in ordinary Debian installations it will have no adverse effect on Open vSwitch. FWIW, I am in complete agreement with Ben on this. Want to give me an Acked-by? Acked-by: Simon Horman ho...@verge.net.au -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663051: [ovs-dev] [PATCH] debian: Use a different way to avoid failing install without kernel module.
On Mon, Mar 19, 2012 at 11:16:32AM -0700, Ben Pfaff wrote: On Fri, Mar 16, 2012 at 03:49:13PM -0700, Ben Pfaff wrote: On Sat, Mar 17, 2012 at 07:16:04AM +0900, Simon Horman wrote: On Fri, Mar 16, 2012 at 02:19:31PM -0700, Ben Pfaff wrote: On Thu, Mar 15, 2012 at 09:30:24AM +0900, Simon Horman wrote: On Wed, Mar 14, 2012 at 02:49:08PM -0700, Ethan Jackson wrote: This looks fine to me, I don't know much about debian though. If you feel confident in it I'm fine with merging it. Otherwise someone else should look at it. I am happy with this change. Reviewed-by: Simon Horman ho...@verge.net.au Thank you. I pushed this to master. Simon, I haven't backported this or the previous series of Debian changes to 1.4. Do you want me to do that? How far away do you think 1.5 is? Personally, I think that if its more than a few weeks away then I think that fixing up the Debian packaging in 1.4 would be worthwhile. I'll do the backport. I backported to 1.[456]. Hi Ben, do you think there will be a point release of 1.4 in the near future? If not, I'll go ahead and prepare a fresh upload ASAP. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663051: [ovs-dev] [PATCH] debian: Use a different way to avoid failing install without kernel module.
On Fri, Mar 16, 2012 at 02:19:31PM -0700, Ben Pfaff wrote: On Thu, Mar 15, 2012 at 09:30:24AM +0900, Simon Horman wrote: On Wed, Mar 14, 2012 at 02:49:08PM -0700, Ethan Jackson wrote: This looks fine to me, I don't know much about debian though. If you feel confident in it I'm fine with merging it. Otherwise someone else should look at it. I am happy with this change. Reviewed-by: Simon Horman ho...@verge.net.au Thank you. I pushed this to master. Simon, I haven't backported this or the previous series of Debian changes to 1.4. Do you want me to do that? How far away do you think 1.5 is? Personally, I think that if its more than a few weeks away then I think that fixing up the Debian packaging in 1.4 would be worthwhile. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663051: [ovs-dev] [PATCH] debian: Use a different way to avoid failing install without kernel module.
On Fri, Mar 16, 2012 at 03:49:13PM -0700, Ben Pfaff wrote: On Sat, Mar 17, 2012 at 07:16:04AM +0900, Simon Horman wrote: On Fri, Mar 16, 2012 at 02:19:31PM -0700, Ben Pfaff wrote: On Thu, Mar 15, 2012 at 09:30:24AM +0900, Simon Horman wrote: On Wed, Mar 14, 2012 at 02:49:08PM -0700, Ethan Jackson wrote: This looks fine to me, I don't know much about debian though. If you feel confident in it I'm fine with merging it. Otherwise someone else should look at it. I am happy with this change. Reviewed-by: Simon Horman ho...@verge.net.au Thank you. I pushed this to master. Simon, I haven't backported this or the previous series of Debian changes to 1.4. Do you want me to do that? How far away do you think 1.5 is? Personally, I think that if its more than a few weeks away then I think that fixing up the Debian packaging in 1.4 would be worthwhile. I'll do the backport. I'm not sure whether Debian should upgrade to 1.5 when it comes out anyway. OVS 1.4 is a branch that we are planning to support for an extended period of time. If wheezy freezes in June, then 1.4 will be the last such release before the freeze. Understood, in that case I agree that backporting makes sense. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663051: [ovs-dev] [PATCH] debian: Use a different way to avoid failing install without kernel module.
On Wed, Mar 14, 2012 at 02:49:08PM -0700, Ethan Jackson wrote:
This looks fine to me, I don't know much about debian though. If you
feel confident in it I'm fine with merging it. Otherwise someone else
should look at it.
I am happy with this change.
Reviewed-by: Simon Horman ho...@verge.net.au
Ethan
On Mon, Mar 12, 2012 at 11:27, Ben Pfaff b...@nicira.com wrote:
The dh_installinit --error-handler option makes a lot of sense, but after
playing with it for a while I could not figure out a nice way to use it
only for openvswitch-switch without either duplicating the dh_installinit
fragments in postinst and prerm (the actual bug that was reported) or
omitting them for some package.
Also, we forgot to write the error handler function for the prerm.
This commit switches to a different way to avoid failing the install when
the kernel module is not available, without using --error-handler.
CC: 663...@bugs.debian.org
Reported-by: Thomas Goirand z...@debian.org
Signed-off-by: Ben Pfaff b...@nicira.com
---
debian/openvswitch-switch.init | 7 +++
debian/openvswitch-switch.postinst | 18 ++
debian/rules | 3 +--
3 files changed, 10 insertions(+), 18 deletions(-)
diff --git a/debian/openvswitch-switch.init b/debian/openvswitch-switch.init
index 98863e3..aebf21e 100755
--- a/debian/openvswitch-switch.init
+++ b/debian/openvswitch-switch.init
@@ -58,6 +58,13 @@ start () {
echo For instructions, read
fi
echo /usr/share/doc/openvswitch-datapath-source/README.Debian
+
+ if test X$OVS_MISSING_KMOD_OK = Xyes; then
+ # We're being invoked by the package postinst. Do not
+ # fail package installation just because the kernel module
+ # is not available.
+ exit 0
+ fi
fi
set ovs_ctl ${1-start} --system-id=random
if test X$FORCE_COREFILES != X; then
diff --git a/debian/openvswitch-switch.postinst
b/debian/openvswitch-switch.postinst
index c50853a..7b9d7bc 100755
--- a/debian/openvswitch-switch.postinst
+++ b/debian/openvswitch-switch.postinst
@@ -44,25 +44,11 @@ case $1 in
;;
esac
-HAVE_KMOD=no
-
-init_script_error () {
- if test X$HAVE_KMOD = Xno; then
- exit 0
- fi
- exit 1
-}
-
# Do not fail package installation just because the kernel module
# is not available.
-if test -x /etc/init.d/openvswitch-switch; then
- if invoke-rc.d openvswitch-switch load-kmod; then
- HAVE_KMOD=yes
- fi
-fi
+OVS_MISSING_KMOD_OK=yes
+export OVS_MISSING_KMOD_OK
#DEBHELPER#
exit 0
-
-
diff --git a/debian/rules b/debian/rules
index 4160025..24c9850 100755
--- a/debian/rules
+++ b/debian/rules
@@ -134,8 +134,7 @@ binary-common:
dh_installexamples
dh_installdebconf
dh_installlogrotate
- dh_installinit -R -Nopenvswitch-switch
- dh_installinit -R -popenvswitch-switch
--error-handler=init_script_error
+ dh_installinit -R
dh_installcron
dh_installman --language=C
dh_link
--
1.7.2.5
___
dev mailing list
d...@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
d...@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663051: [ovs-dev] Bug#663051: Lots of (sometimes serious) lintian errors
On Thu, Mar 08, 2012 at 04:27:39PM +0800, Thomas Goirand wrote: Package: openvswitch Version: 1.4.0-2+nmu1 Severity: serious Hi there! First, thanks for allowing me to do the NMU fixing the dkms module. I just did it, and checked that it was fixing my issue, which it does. Before uploading version 1.4.0-2+nmu1, I ran Lintian, as I always do, and I have found out that lots of Lintian warnings and errors were not addressed: Hi Thomas, patches for any and all of the problems below would, as always, be gratefully appreciated. In particular I am unsure of how to resolve the openvswitch-datapath-dkms issues, do you have any ideas? There are also a number of problems flagged below that I do not understand the source of: * I am unsure why there are errors in the openvswitch-ipsec postinst and postrm scripts as that package does not provide such scripts. * Likewise, the openvswitch-controller package does not supply a postrm script but an error is flagged against it. Also, it would be useful to know specifically which of the issues listed below you regards as serious. P: openvswitch source: package-lacks-versioned-build-depends-on-debhelper 7 I: openvswitch source: debian-watch-file-is-missing I: openvswitch-switch: init.d-script-missing-lsb-description etc/init.d/openvswitch-switch I: openvswitch-switch: spelling-error-in-manpage usr/share/man/man1/ovsdb-server.1.gz noticable noticeable W: openvswitch-switch: manpage-has-bad-whatis-entry usr/share/man/man5/ovs-vswitchd.conf.db.5.gz I: openvswitch-switch: hyphen-used-as-minus-sign usr/share/man/man5/ovs-vswitchd.conf.db.5.gz:1529 I: openvswitch-switch: hyphen-used-as-minus-sign usr/share/man/man5/ovs-vswitchd.conf.db.5.gz:2900 I: openvswitch-switch: spelling-error-in-manpage usr/share/man/man8/ovs-vswitchd.8.gz noticable noticeable I: python-openvswitch: extended-description-is-probably-too-short E: openvswitch-ipsec: duplicate-updaterc.d-calls-in-postinst openvswitch-ipsec E: openvswitch-ipsec: duplicate-updaterc.d-calls-in-postrm openvswitch-ipsec I: openvswitch-ipsec: init.d-script-missing-lsb-description etc/init.d/openvswitch-ipsec E: openvswitch-controller: duplicate-updaterc.d-calls-in-postinst openvswitch-controller E: openvswitch-controller: duplicate-updaterc.d-calls-in-postrm openvswitch-controller I: openvswitch-controller: init.d-script-missing-lsb-description etc/init.d/openvswitch-controller P: openvswitch source: package-lacks-versioned-build-depends-on-debhelper 7 I: openvswitch source: debian-watch-file-is-missing I: openvswitch-switch: init.d-script-missing-lsb-description etc/init.d/openvswitch-switch I: openvswitch-switch: spelling-error-in-manpage usr/share/man/man1/ovsdb-server.1.gz noticable noticeable W: openvswitch-switch: manpage-has-bad-whatis-entry usr/share/man/man5/ovs-vswitchd.conf.db.5.gz I: openvswitch-switch: hyphen-used-as-minus-sign usr/share/man/man5/ovs-vswitchd.conf.db.5.gz:1529 I: openvswitch-switch: hyphen-used-as-minus-sign usr/share/man/man5/ovs-vswitchd.conf.db.5.gz:2900 I: openvswitch-switch: spelling-error-in-manpage usr/share/man/man8/ovs-vswitchd.8.gz noticable noticeable I: python-openvswitch: extended-description-is-probably-too-short E: openvswitch-ipsec: duplicate-updaterc.d-calls-in-postinst openvswitch-ipsec E: openvswitch-ipsec: duplicate-updaterc.d-calls-in-postrm openvswitch-ipsec I: openvswitch-ipsec: init.d-script-missing-lsb-description etc/init.d/openvswitch-ipsec E: openvswitch-controller: duplicate-updaterc.d-calls-in-postinst openvswitch-controller E: openvswitch-controller: duplicate-updaterc.d-calls-in-postrm openvswitch-controller I: openvswitch-controller: init.d-script-missing-lsb-description etc/init.d/openvswitch-controller W: openvswitch-datapath-dkms: extra-license-file usr/src/openvswitch-1.4.0/COPYING W: openvswitch-datapath-dkms: extra-license-file usr/src/openvswitch-1.4.0/ovsdb/ovsdbmonitor/COPYING W: openvswitch-datapath-dkms: extra-license-file usr/src/openvswitch-1.4.0/xenserver/LICENSE E: openvswitch-datapath-dkms: python-script-but-no-python-dep usr/src/openvswitch-1.4.0/build-aux/check-structs E: openvswitch-datapath-dkms: python-script-but-no-python-dep usr/src/openvswitch-1.4.0/build-aux/extract-ofp-errors W: openvswitch-datapath-dkms: script-not-executable usr/src/openvswitch-1.4.0/debian/openvswitch-datapath-dkms.postinst W: openvswitch-datapath-dkms: script-not-executable usr/src/openvswitch-1.4.0/debian/openvswitch-datapath-dkms.prerm E: openvswitch-datapath-dkms: python-script-but-no-python-dep usr/src/openvswitch-1.4.0/debian/ovs-monitor-ipsec E: openvswitch-datapath-dkms: shell-script-fails-syntax-check usr/src/openvswitch-1.4.0/rhel/kmodtool-openvswitch-el5.sh E: openvswitch-datapath-dkms: python-script-but-no-python-dep usr/src/openvswitch-1.4.0/xenserver/etc_xapi.d_plugins_openvswitch-cfg-update E: openvswitch-datapath-dkms:
Bug#659685: [ovs-dev] Bug#659685: Can we have a fix please?
On Wed, Mar 07, 2012 at 04:48:55PM +0800, Thomas Goirand wrote:
Hi,
I had a look to the current packaging of openvswitch, in order to fix
this bug (eg: #659685) With all due respect... it's a mess.
The only reason why you are using Quilt is to patch files that are in
your openvswitch_version.debian.tar.gz. Please don't abuse quilt like
this! There's no reason to patch things under the debian folder, it
should come already patched.
Your debian-changes-1.4.0-2 is reverting some of the patches previously
applied, and which would have otherwise let the DKMS module.
I have attached a patch which removes all patches in debian/patches,
since they aren't needed at all. Also, with this patch,
openvswitch-datapath-dkms works as expected (eg: it build the kernel
module), because using ${kernel_source_dir} as it should be. Please
apply this patch and upload a new 1.4.0-3 of openvswitch.
Hi Thomas,
It is my understanding that placing patches under debian/patches is part of
the 3.0 (quilt) package format. Is OVS using the format incorrectly in some
way? Does that format interact with DKMS poorly in some way?
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659685: [ovs-dev] Bug#659685: Bug#659685: Can we have a fix please?
On Wed, Mar 07, 2012 at 10:49:33PM +0800, Thomas Goirand wrote: Hi, I'm sorry, I think I didn't express myself correctly. Please read this: http://lintian.debian.org/tags/patch-modifying-debian-files.html As you can see, lintian did catch issues in your openvswitch package! :) So, if you have changes to make in let's say debian/control, then edit the file, don't produce a patch for it in debian/patches. Same for debian/python-openvswitch.install, or debian/dkms.conf.in. Did you get it this time? Or should I explain further? Thanks, that make it clear to me. Unfortunately I'm not in a position to make a fresh upload this week. I'm happy for someone else to make an upload if they see fit. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659685: [ovs-dev] Bug#659685: Bug#659685: Bug#659685: Can we have a fix please?
On Wed, Mar 07, 2012 at 12:55:03PM -0800, Ben Pfaff wrote: On Wed, Mar 07, 2012 at 11:26:39PM +0800, Thomas Goirand wrote: If you agree with my patch, I can do an NMU. Is that ok? Speaking as co-maintainer, yes, your patch looks correct, please NNU. Likewise, please NMU. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659685: [ovs-dev] [PATCH] configure: Try to extract kernel source directory from build Makefile.
On Thu, Feb 16, 2012 at 04:53:35PM -0800, Ben Pfaff wrote: On Thu, Feb 16, 2012 at 04:32:57PM -0800, Jesse Gross wrote: On Thu, Feb 16, 2012 at 10:36 AM, Ben Pfaff b...@nicira.com wrote: OVS needs to inspect the headers in the kernel source directory at build time. Debian keeps moving the source directory relative to the build directory and doesn't provide an obvious way to find the source directory, so in the past we've used some name-based heuristics to essentially guess where it is. This commit introduces a new heuristic that I hope will be more reliable: extracting the source directory from the Makefile in the build directory. In Debian's case, it looks like the Makefile generally contains a line of the form MAKEARGS := -C srcdir O=outdir. This commit extracts the source directory from that line. To avoid regressions this commit retains the older heuristics as fallbacks. CC: 659...@bugs.debian.org Reported-by: Thomas Goirand z...@debian.org Signed-off-by: Ben Pfaff b...@nicira.com It seems OK to me. Thanks. Pushed to master and branch-1.[2345]. How do other packages solve this problem? It seems like we have a particularly bad time. I've been unable to locate other modules that do this kind of thing. I looked at virtualbox, the nvidia drivers, ndiswrapper, xtables-addons. Curious. I'm fine with your patch as it seems to improve things. But it would be nice not to have to jump thorough hoops like this. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659685: [ovs-dev] Bug#659685: fails to build the kernel module
On Mon, Feb 13, 2012 at 04:10:06PM +0800, Thomas Goirand wrote: Package: openvswitch-datapath-dkms Version: 1.4.0-1 Severity: grave Hi there! First, thanks for maintaining OVS, this is a very nice software, which I will use with XCP (for which I'm working on the packaging, together with people from Citrix). Now, the less nice stuff... :) openvswitch-datapath-dkms fails to build its kernel module when I tried to install it in SID. Here's the relevant log: Building module: cleaning build area(bad exit status: 2) ./configure --with-linux=/usr/src/linux-headers-3.1.0-1-686-pae ; make -C datapath/linux..(bad exit status: 2) Error! Bad return status for module build on kernel: 3.1.0-1-686-pae (i686) Consult /var/lib/dkms/openvswitch/1.4.0/build/make.log for more information. and the make.log contains: make: Entering directory `/var/lib/dkms/openvswitch/1.4.0/build/datapath/linux' make: *** No targets specified and no makefile found. Stop. make: Leaving directory `/var/lib/dkms/openvswitch/1.4.0/build/datapath/linux' I believe that the step building the Makefile was never run (but I didn't investigate more and used the module-assistant version). Indeed: Strange, I think that the Makefile should be created by ./configure, which features in the debian/dkms.conf.in. Would it be possible for you to provide your make.log? root@hostname:~# ls /var/lib/dkms/openvswitch/1.4.0/build/datapath/linux compat Kbuild.in Makefile.in Makefile.main.in Modules.mk If I add in debian/dkms.conf.in something like this: -MAKE=./configure --with-linux=/usr/src/linux-headers-`uname -r` ; make -C datapath/linux +MAKE=./configure --with-linux=/usr/src/linux-headers-`uname -r` ; cp datapath/linux/Makefile.in datapath/linux/Makefile ; cp datapath/linux/Makefile.main.in datapath/linux/Makefile.main ; make -C datapath/linux then I have further errors: checking for Linux source directory... configure: error: cannot find source directory (please use --with-linux-source) make: Entering directory `/var/lib/dkms/openvswitch/1.4.0/build/datapath/linux' Makefile.main:8: @abs_srcdir@/../Modules.mk: No such file or directory Makefile.main:9: @abs_srcdir@/Modules.mk: No such file or directory Makefile.main:55: *** Linux kernel source not configured - missing version.h. Stop. make: Leaving directory `/var/lib/dkms/openvswitch/1.4.0/build/datapath/linux' That figures. The Makefile should be created using Makefile.in as a template and part of that process is to substitute @..@ sequences for their desired values. Note that *I do* have linux-headers-3.1.0-1-686-pae, linux-headers-3.1.0-1-common and linux-kbuild-3.1 installed on my server, so it should be able to find what it needs. I used 3.1 because 3.2 just crashes when I boot with it, but as I wanted to make sure, I also tried to install and run Linux 3.2, and the issue was the same (so it's not a Debian Linux 3.1 kernel specific issue, it's really general, and also is present when running with latest 3.2 kernel in SID). This makes the package unusable, which in Debian books is an RC bug. A fix correcting this issue ASAP would be really appreciated. :) Curiously installing openvswitch-datapath-dkms 1.4.0-1 does seem to work for me, also 3.1 but on amd64, though that may be a legacy of my environment. I'll try and set up pbuilder on this machine to test that theory, but it may not be until tomorrow. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659685: [ovs-dev] Bug#659685: Bug#659685: fails to build the kernel module
On Mon, Feb 13, 2012 at 10:10:18AM -0800, Ben Pfaff wrote: On Tue, Feb 14, 2012 at 01:54:28AM +0800, Thomas Goirand wrote: On 02/14/2012 01:22 AM, Ben Pfaff wrote: Would it be possible for you to provide your make.log? I've attached it to this mail. Here's the root of the problem: checking for Linux build directory... /usr/src/linux-headers-3.1.0-1-686-pae checking for Linux source directory... configure: error: cannot find source directory (please use --with-linux-source) I see that this was already fixed on master with the following commit: -- From 715a77b74caf22e38d1f232d1cc45036b9b83e62 Mon Sep 17 00:00:00 2001 From: Ben Pfaff b...@nicira.com Date: Tue, 10 Jan 2012 14:22:22 -0800 Subject: [PATCH] debian: Look in /lib/modules instead of /usr/src for DKMS kernel sources. DKMS packages usually look in /lib/modules for kernel sources, since that is the standard location, but our packages was looking directly in /usr/src. This fixes the problem. Reported-by: Alban Browaeys pra...@yahoo.com Tested-by: Alban Browaeys pra...@yahoo.com Signed-off-by: Ben Pfaff b...@nicira.com --- AUTHORS |1 + debian/dkms.conf.in |2 +- 2 files changed, 2 insertions(+), 1 deletions(-) diff --git a/AUTHORS b/AUTHORS index d413523..87b3ccd 100644 --- a/AUTHORS +++ b/AUTHORS @@ -60,6 +60,7 @@ provided helpful bug reports or suggestions. Aaron M. Ucko u...@debian.org Aaron Rosen aro...@clemson.edu Ahmed Bilal numan...@gmail.com +Alban Browaeys pra...@yahoo.com Alex Yipa...@nicira.com Alexey I. Froloff ra...@altlinux.org Bob Ballbob.b...@citrix.com diff --git a/debian/dkms.conf.in b/debian/dkms.conf.in index 56c6398..a6dc316 100644 --- a/debian/dkms.conf.in +++ b/debian/dkms.conf.in @@ -1,6 +1,6 @@ PACKAGE_NAME=openvswitch PACKAGE_VERSION=__VERSION__ -MAKE=./configure --with-linux=/usr/src/linux-headers-`uname -r` ; make -C datapath/linux +MAKE=./configure --with-linux=/lib/modules/`uname -r`/build ; make -C datapath/linux BUILT_MODULE_NAME[0]=openvswitch_mod BUILT_MODULE_NAME[1]=brcompat_mod BUILT_MODULE_LOCATION[0]=datapath/linux/ -- Somehow this bug fix did not make it to branches for 1.3 or 1.4. I've now cherry-picked it to both branches, so the next Debian upload should incorporate the fix. I see that we should really be using ' instead of ; in the make rule. I sent out a patch. Thanks Ben, I plan to make make a fresh upload for this. During the course of upgrading XCP from 1.3 to 1.3.2, I've hit 3 bugs already. I really hope that's going to be it! :) I hope so too. I hope that the others have been adequately addressed; let me know if not. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659685: [ovs-dev] Bug#659685: Bug#659685: fails to build the kernel module
On Mon, Feb 13, 2012 at 05:35:15PM -0800, Ben Pfaff wrote: On Tue, Feb 14, 2012 at 09:31:18AM +0900, Simon Horman wrote: On Mon, Feb 13, 2012 at 10:10:18AM -0800, Ben Pfaff wrote: On Tue, Feb 14, 2012 at 01:54:28AM +0800, Thomas Goirand wrote: On 02/14/2012 01:22 AM, Ben Pfaff wrote: Would it be possible for you to provide your make.log? I've attached it to this mail. Here's the root of the problem: checking for Linux build directory... /usr/src/linux-headers-3.1.0-1-686-pae checking for Linux source directory... configure: error: cannot find source directory (please use --with-linux-source) I see that this was already fixed on master with the following commit: Subject: [PATCH] debian: Look in /lib/modules instead of /usr/src for DKMS kernel sources. DKMS packages usually look in /lib/modules for kernel sources, since that is the standard location, but our packages was looking directly in /usr/src. This fixes the problem. Reported-by: Alban Browaeys pra...@yahoo.com Tested-by: Alban Browaeys pra...@yahoo.com Signed-off-by: Ben Pfaff b...@nicira.com --- Somehow this bug fix did not make it to branches for 1.3 or 1.4. I've now cherry-picked it to both branches, so the next Debian upload should incorporate the fix. I see that we should really be using ' instead of ; in the make rule. I sent out a patch. Thanks Ben, I plan to make make a fresh upload for this. Thanks. It might be wise to hold off for: http://openvswitch.org/pipermail/dev/2012-February/014947.html or to plan to make another new upload after it hits. I am planing to include that patch in my upload. I was not planing to wait for it to hit the git repo but I can if you prefer. I have confirmed that with the patch at the link above and other patches it depends on applied the resulting package installs on my system - though it should be said that the package that is currently present in the archive is also installable on my system. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659685: [ovs-dev] [PATCH] debian: Use provided kernel source dir instead of host kernel version.
I have tested this patch and the path and resulting package
appear to be correct.
I see ./configure --with-linux=/usr/src/linux-headers-3.1.0-1-amd64
in the resulting config.log
On Mon, Feb 13, 2012 at 06:05:19PM -0800, Justin Pettit wrote:
Assuming it's the fully correct path, it looks reasonable to me.
--Justin
On Feb 13, 2012, at 4:15 PM, Ben Pfaff wrote:
DKMS passes in an explicit variable for the kernel source directory, so we
should use that instead of `uname -r`.
CC: 659...@bugs.debian.org
Reported-by: Thomas Goirand tho...@goirand.fr
Signed-off-by: Ben Pfaff b...@nicira.com
---
debian/dkms.conf.in |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/debian/dkms.conf.in b/debian/dkms.conf.in
index ae1fc7a..d5bc37e 100644
--- a/debian/dkms.conf.in
+++ b/debian/dkms.conf.in
@@ -1,6 +1,6 @@
PACKAGE_NAME=openvswitch
PACKAGE_VERSION=__VERSION__
-MAKE=./configure --with-linux=/lib/modules/`uname -r`/build make -C
datapath/linux
+MAKE=./configure --with-linux='${kernel_source_dir}' make -C
datapath/linux
BUILT_MODULE_NAME[0]=openvswitch_mod
BUILT_MODULE_NAME[1]=brcompat_mod
BUILT_MODULE_LOCATION[0]=datapath/linux/
--
1.7.2.5
___
dev mailing list
d...@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
___
dev mailing list
d...@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659685: [ovs-dev] Bug#659685: Bug#659685: fails to build the kernel module
On Mon, Feb 13, 2012 at 08:07:36PM -0800, Ben Pfaff wrote: On Tue, Feb 14, 2012 at 12:16:25PM +0900, Simon Horman wrote: On Mon, Feb 13, 2012 at 05:35:15PM -0800, Ben Pfaff wrote: On Tue, Feb 14, 2012 at 09:31:18AM +0900, Simon Horman wrote: On Mon, Feb 13, 2012 at 10:10:18AM -0800, Ben Pfaff wrote: On Tue, Feb 14, 2012 at 01:54:28AM +0800, Thomas Goirand wrote: On 02/14/2012 01:22 AM, Ben Pfaff wrote: Would it be possible for you to provide your make.log? I've attached it to this mail. Here's the root of the problem: checking for Linux build directory... /usr/src/linux-headers-3.1.0-1-686-pae checking for Linux source directory... configure: error: cannot find source directory (please use --with-linux-source) I see that this was already fixed on master with the following commit: Subject: [PATCH] debian: Look in /lib/modules instead of /usr/src for DKMS kernel sources. DKMS packages usually look in /lib/modules for kernel sources, since that is the standard location, but our packages was looking directly in /usr/src. This fixes the problem. Reported-by: Alban Browaeys pra...@yahoo.com Tested-by: Alban Browaeys pra...@yahoo.com Signed-off-by: Ben Pfaff b...@nicira.com --- Somehow this bug fix did not make it to branches for 1.3 or 1.4. I've now cherry-picked it to both branches, so the next Debian upload should incorporate the fix. I see that we should really be using ' instead of ; in the make rule. I sent out a patch. Thanks Ben, I plan to make make a fresh upload for this. Thanks. It might be wise to hold off for: http://openvswitch.org/pipermail/dev/2012-February/014947.html or to plan to make another new upload after it hits. I am planing to include that patch in my upload. That makes sense. I was not planing to wait for it to hit the git repo but I can if you prefer. I don't think that is necessary. I tested it before I posted it, and you said that you tested it too, and that is good enough for me. Thanks, I have now uploaded 1.4.0-2. I have confirmed that with the patch at the link above and other patches it depends on applied the resulting package installs on my system - though it should be said that the package that is currently present in the archive is also installable on my system. As on mine. Thanks, Ben. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651798: [ovs-dev] Bug#651798: Fails to build against Linux 3.1
On Mon, Dec 12, 2011 at 08:00:25AM +, Ben Hutchings wrote: Package: openvswitch-datapath-source Version: 1.2.2-2 Severity: grave This module fails to build against Linux 3.1: make[3]: Entering directory `/usr/src/linux-headers-3.1.0-1-amd64' /usr/src/linux-headers-3.1.0-1-common/arch/x86/Makefile:81: stack protector enabled but no compiler support CC [M] /usr/src/modules/openvswitch-datapath/openvswitch/datapath/linux/genetlink-brcompat.o CC [M] /usr/src/modules/openvswitch-datapath/openvswitch/datapath/linux/brcompat.o CC [M] /usr/src/modules/openvswitch-datapath/openvswitch/datapath/linux/actions.o CC [M] /usr/src/modules/openvswitch-datapath/openvswitch/datapath/linux/checksum.o CC [M] /usr/src/modules/openvswitch-datapath/openvswitch/datapath/linux/datapath.o /usr/src/modules/openvswitch-datapath/openvswitch/datapath/linux/datapath.c:58:2: error: #error Kernels before 2.6.18 or after 3.0 are not supported by this version of Open vSwitch. make[6]: *** [/usr/src/modules/openvswitch-datapath/openvswitch/datapath/linux/datapath.o] Error 1 make[5]: *** [_module_/usr/src/modules/openvswitch-datapath/openvswitch/datapath/linux] Error 2 make[4]: *** [sub-make] Error 2 make[3]: *** [all] Error 2 make[3]: Leaving directory `/usr/src/linux-headers-3.1.0-1-amd64' Since a version of Open vSwitch has been accepted for inclusion in mainline Linux 3.3, perhaps it could be included in Debian kernel packages starting with Linux 3.2 and then this binary package could be removed. However I don't know whether the mainline version is fully- featured. Hi Ben, the mainline version is fully featured and I envisage that the openvswitch-datapath package can be removed from the archive at some point. I would value your input on how that might be best achieved. As for the compile problem below, this is intended by upstream, though perhaps isn't appropriate for Debian. I'll take guidance on that issue from upstream. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651798: [ovs-dev] Bug#651798: Bug#651798: Fails to build against Linux 3.1
On Mon, Dec 12, 2011 at 11:57:29AM -0800, Jesse Gross wrote: On Mon, Dec 12, 2011 at 12:26 AM, Simon Horman ho...@verge.net.au wrote: On Mon, Dec 12, 2011 at 08:00:25AM +, Ben Hutchings wrote: Since a version of Open vSwitch has been accepted for inclusion in mainline Linux 3.3, perhaps it could be included in Debian kernel packages starting with Linux 3.2 and then this binary package could be removed. However I don't know whether the mainline version is fully- featured. Hi Ben, the mainline version is fully featured and I envisage that the openvswitch-datapath package can be removed from the archive at some point. I would value your input on how that might be best achieved. The upstream version is actually not quite fully featured. There is currently no support for tunneling upstream because we wanted to spent some time thinking about the interfaces before finalizing them. We did quite a bit of this for the main components of Open vSwitch and thought it was better to get that upstream first since it was ready and more or less independent. The other piece that is not upstream is support for bridge compatibility (although the bulk of this is in a separate module, it requires some hooks into the main one). We hope that this continues to become less necessary over time and aren't planning to propose that for upstream Linux. I stand corrected. As Ben mentioned, the best solution for now to just upload OVS 1.3. Sure, will do. But it may not be until the end of the week. As for the compile problem below, this is intended by upstream, though perhaps isn't appropriate for Debian. I'll take guidance on that issue from upstream. The #error message is only intended to make the source of the problem obvious to users who are compiling the module out-of-tree. Compilation would have failed anyways due to changes in the kernel headers. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630325: [ovs-dev] Bug#630325: openvswitch: FTBFS on big-endian architectures
On Mon, Jun 13, 2011 at 12:22:52AM +0200, Aurelien Jarno wrote: Package: openvswitch Version: 1.1.0-1 Severity: serious openvswitch FTBFS on big endian architectures (mips, powerpc, s390 and sparc) due to a failure in the testsuite. Full build logs are available: https://buildd.debian.org/status/fetch.php?pkg=openvswitcharch=mipsver=1.1.0-1stamp=1303899320 https://buildd.debian.org/status/fetch.php?pkg=openvswitcharch=powerpcver=1.1.0-1stamp=1303898110 https://buildd.debian.org/status/fetch.php?pkg=openvswitcharch=s390ver=1.1.0-1stamp=1303899173 https://buildd.debian.org/status/fetch.php?pkg=openvswitcharch=sparcver=1.1.0-1stamp=1303898134 Hi ovs-dev, all of the logs above indicate failure in 359: ofproto.at:45 ofproto - basic flow_mod commands Unfortunately I'm not familiar enough with the output to determine the problem without digging much further. Perhaps you have some ideas. The detailed output from sparc is below. I believe that the output is similar if not the same on the other three architectures. ## -- ## ## Detailed failed tests. ## ## -- ## # -*- compilation -*- 359. ofproto.at:45: testing ... ../../tests/ofproto.at:46: ovs-openflowd --detach --pidfile --enable-dummy --log-file dummy@br0 none --datapath-id=fedcba9876543210 stderr: Apr 27 09:52:29|1|vlog|INFO|opened log file /build/buildd-openvswitch_1.1.0-1-sparc-z51Ogn/openvswitch-1.1.0/_debian/tests/testsuite.dir/359/ovs-openflowd.log Apr 27 09:52:29|2|openflowd|INFO|Open vSwitch version 1.1.0+build0 Apr 27 09:52:29|3|openflowd|INFO|OpenFlow protocol version 0x01 Apr 27 09:52:29|4|ofproto|INFO|using datapath ID 002320864689 Apr 27 09:52:29|5|ofproto|INFO|datapath ID changed to fedcba9876543210 stdout: ../../tests/ofproto.at:47: ovs-ofctl dump-flows br0 | sed 's/ (xid=0x[0-9a-fA-F]*)//' ../../tests/ofproto.at:49: echo 'in_port=1,actions=0' | ovs-ofctl add-flows br0 - ../../tests/ofproto.at:50: ovs-ofctl add-flow br0 in_port=0,actions=1 ../../tests/ofproto.at:51: ovs-ofctl dump-flows br0 | sed 's/ (xid=0x[0-9a-fA-F]*)//' | sed 's/\bduration=[0-9.]*s/duration=?s/' --- - 2011-04-27 09:52:29.977325874 + +++ /build/buildd-openvswitch_1.1.0-1-sparc-z51Ogn/openvswitch-1.1.0/_debian/tests/testsuite.dir/at-groups/359/stdout 2011-04-27 09:52:29.0 + @@ -1,4 +1,4 @@ NXST_FLOW reply: - cookie=0x0, duration=?s, table_id=0, n_packets=0, n_bytes=0, in_port=1 actions=output:0 cookie=0x0, duration=?s, table_id=0, n_packets=0, n_bytes=0, in_port=65534 actions=output:1 + cookie=0x0, duration=?s, table_id=0, n_packets=0, n_bytes=0, in_port=1 actions=output:0 ovs-openflowd.log: Apr 27 09:52:29|1|vlog|INFO|opened log file /build/buildd-openvswitch_1.1.0-1-sparc-z51Ogn/openvswitch-1.1.0/_debian/tests/testsuite.dir/359/ovs-openflowd.log Apr 27 09:52:29|2|openflowd|INFO|Open vSwitch version 1.1.0+build0 Apr 27 09:52:29|3|openflowd|INFO|OpenFlow protocol version 0x01 Apr 27 09:52:29|4|ofproto|INFO|using datapath ID 002320864689 Apr 27 09:52:29|5|ofproto|INFO|datapath ID changed to fedcba9876543210 Apr 27 09:52:29|6|ofp_util|INFO|normalization changed ofp_match, details: Apr 27 09:52:29|7|ofp_util|INFO| pre: wildcards= 0x3820fe in_port=1 dl_src=00:00:00:00:00:00 dl_dst=00:00:00:00:00:00 dl_vlan=0 dl_vlan_pcp= 0 dl_type= 0 nw_tos= 0 nw_proto= 0 nw_src= 0 nw_dst= 0 tp_src=0 tp_dst=0 Apr 27 09:52:29|8|ofp_util|INFO|post: wildcards= 0x3e in_port=1 dl_src=00:00:00:00:00:00 dl_dst=00:00:00:00:00:00 dl_vlan=0 dl_vlan_pcp= 0 dl_type= 0 nw_tos= 0 nw_proto= 0 nw_src= 0 nw_dst= 0 tp_src=0 tp_dst=0 Apr 27 09:52:29|9|ofp_util|INFO|normalization changed ofp_match, details: Apr 27 09:52:29|00010|ofp_util|INFO| pre: wildcards= 0x3820fe in_port=65534 dl_src=00:00:00:00:00:00 dl_dst=00:00:00:00:00:00 dl_vlan=0 dl_vlan_pcp= 0 dl_type= 0 nw_tos= 0 nw_proto= 0 nw_src= 0 nw_dst= 0 tp_src=0 tp_dst=0 Apr 27 09:52:29|00011|ofp_util|INFO|post: wildcards= 0x3e in_port=65534 dl_src=00:00:00:00:00:00 dl_dst=00:00:00:00:00:00 dl_vlan=0 dl_vlan_pcp= 0 dl_type= 0 nw_tos= 0 nw_proto= 0 nw_src= 0 nw_dst= 0 tp_src=0 tp_dst=0 359. ofproto.at:45: 359. ofproto - basic flow_mod commands (ofproto.at:45): FAILED (ofproto.at:51) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630325: [ovs-dev] Bug#630325: Bug#630325: openvswitch: FTBFS on big-endian architectures
On Tue, Jun 14, 2011 at 07:56:52PM -0700, Ben Pfaff wrote: On Wed, Jun 15, 2011 at 10:51:24AM +0900, Simon Horman wrote: Unfortunately I'm not familiar enough with the output to determine the problem without digging much further. Perhaps you have some ideas. The detailed output from sparc is below. I believe that the output is similar if not the same on the other three architectures. Yes, I looked at this today. I'll send out a fix for it tomorrow. It's a bug in the testsuite, I think, not in OVS itself. Understood. Could you CC me or this bug on the fix? Then I can push it into an upload to Debian.Org and the buildds can verify the change. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609506: [ovs-dev] Bug#609506: [Y2011 3/3] tests: Fix Y2011 bug in testsuite.
Thanks Justin, Thanks Ben, I'll try to get new packages uploaded today. Otherwise, I will have time tomorrow. On Tue, Jan 11, 2011 at 12:09:09AM -0800, Justin Pettit wrote: [Our mailing list server got stuck earlier today, and it appears to be dribbling out queued messages from earlier.] As I mentioned out of band, this series looks good. And you pushed it... --Justin On Jan 10, 2011, at 12:54 PM, Ben Pfaff wrote: The tests have been failing for a few days now, because the PKI expired a few days into 2011. This commit instead generates the PKI at make check time, which has the additional benefit of getting some test exposure for the ovs-pki program. Reported-by: Aaron M. Ucko u...@debian.org CC: 609...@bugs.debian.org --- AUTHORS|1 + Makefile.am|7 +++- README |2 +- tests/automake.mk | 44 ++- tests/ovsdb-server.at |4 +- tests/testpki-cacert.pem | 70 tests/testpki-cert.pem | 70 tests/testpki-cert2.pem| 70 tests/testpki-privkey.pem | 27 - tests/testpki-privkey2.pem | 27 - tests/testpki-req.pem | 63 --- tests/testpki-req2.pem | 63 --- tests/vconn.at |2 +- 13 files changed, 46 insertions(+), 404 deletions(-) delete mode 100644 tests/testpki-cacert.pem delete mode 100644 tests/testpki-cert.pem delete mode 100644 tests/testpki-cert2.pem delete mode 100644 tests/testpki-privkey.pem delete mode 100644 tests/testpki-privkey2.pem delete mode 100644 tests/testpki-req.pem delete mode 100644 tests/testpki-req2.pem diff --git a/AUTHORS b/AUTHORS index 3eb47a4..c57d43b 100644 --- a/AUTHORS +++ b/AUTHORS @@ -36,6 +36,7 @@ Yu Zhiguo y...@cn.fujitsu.com The following additional people are mentioned in commit logs as having provided helpful bug reports or suggestions. +Aaron M. Ucko u...@debian.org Alexey I. Froloff ra...@altlinux.org Brad Hall b...@nicira.com Brandon Heller brand...@stanford.edu diff --git a/Makefile.am b/Makefile.am index eef8eb6..689fd6c 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1,4 +1,4 @@ -# Copyright (C) 2007, 2008, 2009, 2010 Nicira Networks, Inc. +# Copyright (C) 2007, 2008, 2009, 2010, 2011 Nicira Networks, Inc. # # Copying and distribution of this file, with or without modification, # are permitted in any medium without royalty provided the copyright @@ -27,6 +27,7 @@ endif ALL_LOCAL = BUILT_SOURCES = CLEANFILES = +CLEAN_LOCAL = DISTCLEANFILES = EXTRA_DIST = \ CodingStyle \ @@ -60,6 +61,7 @@ noinst_PROGRAMS = noinst_SCRIPTS = OVSIDL_BUILT = SUFFIXES = +check_DATA = # This ensures that files added to EXTRA_DIST are always distributed, # even if they are inside an Automake if...endif conditional block that is @@ -124,7 +126,8 @@ CLEANFILES += distfiles dist-hook: $(DIST_HOOKS) all-local: $(ALL_LOCAL) -.PHONY: $(DIST_HOOKS) +clean-local: $(CLEAN_LOCAL) +.PHONY: $(DIST_HOOKS) $(CLEAN_LOCAL) include lib/automake.mk include ofproto/automake.mk diff --git a/README b/README index 16f2ee6..114878d 100644 --- a/README +++ b/README @@ -104,7 +104,7 @@ INSTALL.KVM. To install Open vSwitch without using a kernel module, read INSTALL.userspace. -To learn set up SSL support for Open vSwitch, read INSTALL.SSL. +To learn how to set up SSL support for Open vSwitch, read INSTALL.SSL. Each Open vSwitch userspace program is accompanied by a manpage. Many of the manpages are customized to your configuration as part of the diff --git a/tests/automake.mk b/tests/automake.mk index c50b62e..0098c20 100644 --- a/tests/automake.mk +++ b/tests/automake.mk @@ -281,14 +281,6 @@ tests_test_uuid_LDADD = lib/libopenvswitch.a noinst_PROGRAMS += tests/test-vconn tests_test_vconn_SOURCES = tests/test-vconn.c tests_test_vconn_LDADD = lib/libopenvswitch.a $(SSL_LIBS) -EXTRA_DIST += \ - tests/testpki-cacert.pem \ - tests/testpki-cert.pem \ - tests/testpki-cert2.pem \ - tests/testpki-privkey.pem \ - tests/testpki-privkey2.pem \ - tests/testpki-req.pem \ - tests/testpki-req2.pem noinst_PROGRAMS += tests/test-byte-order tests_test_byte_order_SOURCES = tests/test-byte-order.c @@ -301,3 +293,39 @@ EXTRA_DIST += \ tests/test-jsonrpc.py \ tests/test-ovsdb.py \ tests/test-reconnect.py + +if HAVE_OPENSSL +TESTPKI_FILES = \ + tests/testpki-cacert.pem \ + tests/testpki-cert.pem \ + tests/testpki-privkey.pem \ + tests/testpki-req.pem \ + tests/testpki-cert2.pem \ +
Bug#601807: heartbeat: Segfault while using a failover IPv6 address
On Sun, Dec 12, 2010 at 04:54:19PM +0100, Laurent CARON wrote: On 07/11/2010 12:02, Laurent CARON wrote: On 07/11/2010 02:27, Simon Horman wrote: On Sat, Nov 06, 2010 at 08:07:13PM +0100, Laurent CARON wrote: On 30/10/2010 08:54, Simon Horman wrote: On Sat, Oct 30, 2010 at 08:18:33AM +0200, Laurent Caron wrote: On Sat, Oct 30, 2010 at 02:11:57PM +0900, Simon Horman wrote: On Fri, Oct 29, 2010 at 10:54:55PM +0200, Laurent Caron wrote: could you give a little bit more detail on the configuration that you have that segfaults? Hi Simon, Here you go: $ /etc/ha.d/resource.d/IPv6addr abcd:abc:abc:a::b/64/bond0 start *** glibc detected *** /usr/lib/ocf/resource.d//heartbeat/IPv6addr: free(): invalid next size (fast): 0x006042b0 *** [ snip ] Thanks Hi Simon, Do you have any input on this ? Hi, I haven't had time to look into this. But I would start by seeing if the bug has been fixed upstream - I seem to recall a fix for a problem like this. Did check it: http://rpmfind.net/linux/RPM/opensuse/11.3/x86_64/heartbeat-resources-2.99.3-18.2.x86_64.html * Wed Jan 21 2009 l...@suse.de - RA: IPv6addr: Fix crash on x86_64 (LF#2034). Can you please push this fix to the debian package ? Thanks Hi Simon, Did you update the debian package with the IPv6 patch ? Sorry, no, not yet. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601807: heartbeat: Segfault while using a failover IPv6 address
On Mon, Dec 13, 2010 at 06:30:33AM +0900, Simon Horman wrote: On Sun, Dec 12, 2010 at 04:54:19PM +0100, Laurent CARON wrote: On 07/11/2010 12:02, Laurent CARON wrote: On 07/11/2010 02:27, Simon Horman wrote: On Sat, Nov 06, 2010 at 08:07:13PM +0100, Laurent CARON wrote: On 30/10/2010 08:54, Simon Horman wrote: On Sat, Oct 30, 2010 at 08:18:33AM +0200, Laurent Caron wrote: On Sat, Oct 30, 2010 at 02:11:57PM +0900, Simon Horman wrote: On Fri, Oct 29, 2010 at 10:54:55PM +0200, Laurent Caron wrote: could you give a little bit more detail on the configuration that you have that segfaults? Hi Simon, Here you go: $ /etc/ha.d/resource.d/IPv6addr abcd:abc:abc:a::b/64/bond0 start *** glibc detected *** /usr/lib/ocf/resource.d//heartbeat/IPv6addr: free(): invalid next size (fast): 0x006042b0 *** [ snip ] Thanks Hi Simon, Do you have any input on this ? Hi, I haven't had time to look into this. But I would start by seeing if the bug has been fixed upstream - I seem to recall a fix for a problem like this. Did check it: http://rpmfind.net/linux/RPM/opensuse/11.3/x86_64/heartbeat-resources-2.99.3-18.2.x86_64.html * Wed Jan 21 2009 l...@suse.de - RA: IPv6addr: Fix crash on x86_64 (LF#2034). Can you please push this fix to the debian package ? Thanks Hi Simon, Did you update the debian package with the IPv6 patch ? Sorry, no, not yet. Hi, I took a look and that patch is as follows. However the line that it changes doesn't exist in the lenny4 package. I guess we need to poke a bit harder. # HG changeset patch # User Dejan Muhamedagic de...@hello-penguin.com # Date 1257196243 -3600 # Node ID c9d24c4d9149b99fd967f67ff7e40926014d0c83 # Parent cdf5dc51eeec038bbc94ec4958a098d6efe68007 Medium: IPv6addr: ifdef out the ip offset hack for libnet v1.1.4 (LF 2034) diff -r cdf5dc51eeec -r c9d24c4d9149 heartbeat/IPv6addr.c --- a/heartbeat/IPv6addr.c Mon Nov 02 22:09:27 2009 +0100 +++ b/heartbeat/IPv6addr.c Mon Nov 02 22:10:43 2009 +0100 @@ -450,7 +450,9 @@ 255,*(struct libnet_in6_addr*)src_ip, dst_ip,NULL,0,l,0); /* Hack: adjust the correct checksum offset. see LF #2034 */ +#ifndef HAVE_LIBNET_1_1_4_API libnet_pblock_record_ip_offset(l, l-total_size); +#endif if (libnet_write(l) == -1) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606048: Perdition package upgrade removes and does not regenerate .db files
On Thu, Dec 09, 2010 at 11:12:05AM +0100, Cesare Leonardi wrote: I just upgraded to the latest lenny perdition package. The upgrade resulted in the /etc/perdition/popmap.*.db files being removed and not regenerated. I confirm this too. Today i upgraded from 1.17.1-2 to 1.17.1-2+lenny2 and after a reboot for a kernel upgrade, some user started complaining about authentication errors. So i observed what Tim reported. Hi Cesare, Hi Tim, I am a bit confused as to if this is a new problem or not. I initially thought that Tim's idea that this was a result of the change made to resolve #595207 was correct, but now I'm not so sure. The change made for #595207 was to remove the portion of the postrm script that removes the .db files. So its expected (though entirely undesirable) that 1.17.1-2 removes them, while 1.17.1-2+lenny2 should not. However, I don't think that installing (or upgrading) perdition has ever created the .db files. So I'm unsure why this problem hasn't been observed. As for a fix, I wonder if it is appropriate to have perdition run make to create the .db files in its postinst. And having an dependency on make accordingly. Moving forwards this shouldn't be necessary, as the db files aren't removed by postrm any more. But there is no telling what version a user might be upgrading from. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601989: Permission to upload vanessa-logger_0.0.10-1.1 (NMU)
On Sun, Nov 14, 2010 at 02:06:20AM +0100, Luca Falavigna wrote: Hi, I'm attaching a debdiff of a proposed NMU I plan to upload to DELAYED/2 to fix bug #601989. Release Team, would you consider an unblock request for this upload? I have no objections to this. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601807: heartbeat: Segfault while using a failover IPv6 address
On Sat, Oct 30, 2010 at 08:18:33AM +0200, Laurent Caron wrote: On Sat, Oct 30, 2010 at 02:11:57PM +0900, Simon Horman wrote: On Fri, Oct 29, 2010 at 10:54:55PM +0200, Laurent Caron wrote: could you give a little bit more detail on the configuration that you have that segfaults? Hi Simon, Here you go: $ /etc/ha.d/resource.d/IPv6addr abcd:abc:abc:a::b/64/bond0 start *** glibc detected *** /usr/lib/ocf/resource.d//heartbeat/IPv6addr: free(): invalid next size (fast): 0x006042b0 *** [ snip ] Thanks -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601807: heartbeat: Segfault while using a failover IPv6 address
On Fri, Oct 29, 2010 at 10:54:55PM +0200, Laurent Caron wrote: Package: heartbeat Version: 2.1.3-6lenny4 Severity: grave Justification: renders package unusable Hi, Heartbeat doesn't seem to play nice with ipv6. It segfaults while trying to add an IPv6 address. Hi Laurent, could you give a little bit more detail on the configuration that you have that segfaults? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595432: Bug#595207: [SRM] Stable update for perdition (1.17.1-2+lenny1)
On Mon, Sep 06, 2010 at 01:16:49PM +0100, Adam D. Barratt wrote: On Mon, September 6, 2010 04:24, Simon Horman wrote: I would like the upload of 1.17.1-2+lenny1 considred. My proposal resolves two bugs. * 595207: This is a fix for CVE-2009-3555 and enables session renegotiation to work with Thunderbird 3.1. This was resolve din 1.19~rc3-1 by making an appropriate call to SSL_CTX_set_session_id_context(). I propose the same fix for 1.17.1-2+lenny1 * 595432: Perdition calls make in its postrm but has no dependency on make. This was resolved in 1.18~rc2-1 by removing the call to make. I propose the same fix for 1.17.1-2+lenny1 This seems like a somewhat odd thing to be doing in a postrm script in the first place, imho. Agreed. Please go ahead with the upload. Done :-) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595432: perdition: Missing dependency: make
fixed 595432 1.18~rc1-3 thanks On Fri, Sep 03, 2010 at 04:43:05PM -0400, Micah Anderson wrote: Package: perdition Version: 1.17.1-2 Severity: serious Justification: Policy 3.5 I tried to install my backport of perdition onto my lenny box and got this: (Reading database ... 36581 files and directories currently installed.) Preparing to replace perdition 1.17.1-2 (using perdition_1.19~rc3-1~bpo50+1_i386.deb) ... /var/lib/dpkg/info/perdition.prerm: line 6: make: command not found Unpacking replacement perdition ... dpkg: error processing perdition (--install): dependency problems - leaving unconfigured Processing triggers for man-db ... Errors were encountered while processing: perdition hrm, looks like perdition requires make in the postinst. Perhaps this could be fixed in a point release? This was fixed in 1.18-rc3 with the following change. I am happy to include this in any point release. # HG changeset patch # User Simon Horman ho...@verge.net.au # Date 1252026632 -36000 # Node ID 5425b7c0637b171e2f5c4ac2839dde7c517e12ea # Parent 0deee2fe5c2e42072e0f7a1a4288912c76646f0b Debian: Don't call make from perdition prerm script * Make may not be installed * Unnecessary cleaning up of user-generated files Signed-off-by: Simon Horman ho...@verge.net.au diff -r 0deee2fe5c2e -r 5425b7c0637b debian/changelog --- a/debian/changelog Thu Sep 03 23:39:11 2009 +1000 +++ b/debian/changelog Fri Sep 04 11:10:32 2009 +1000 @@ -1,3 +1,11 @@ +perdition (1.18~rc1-3) unstable; urgency=low + + * don't call make from perdition prerm script +- make may not be installed +- unnecessary clean up of user-generated files + + -- Simon Horman ho...@debian.org Fri, 04 Sep 2009 11:09:42 +1000 + perdition (1.18~rc1-2) unstable; urgency=low * Update build dependency on libvanessa-socket-dev to 0.0.8. diff -r 0deee2fe5c2e -r 5425b7c0637b debian/perdition.prerm --- a/debian/perdition.prermThu Sep 03 23:39:11 2009 +1000 +++ b/debian/perdition.prermFri Sep 04 11:10:32 2009 +1000 @@ -5,8 +5,6 @@ set -e -make -C /etc/perdition/ clean /dev/null - if [ $1 = purge -o $1 = remove ]; then if [ -f /etc/init.d/perdition ]; then invoke-rc.d perdition stop -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595432: [SRM] Stable update for perdition (1.17.1-2+lenny1)
Hi,
I would like the upload of 1.17.1-2+lenny1 considred.
My proposal resolves two bugs.
* 595207: This is a fix for CVE-2009-3555 and enables
session renegotiation to work with Thunderbird 3.1.
This was resolve din 1.19~rc3-1 by making an appropriate
call to SSL_CTX_set_session_id_context().
I propose the same fix for 1.17.1-2+lenny1
* 595432: Perdition calls make in its postrm but has no dependency
on make. This was resolved in 1.18~rc2-1 by removing the call to
make. I propose the same fix for 1.17.1-2+lenny1
The diff of the proposed changes is as follows:
diff -u perdition-1.17.1/debian/changelog perdition-1.17.1/debian/changelog
--- perdition-1.17.1/debian/changelog
+++ perdition-1.17.1/debian/changelog
@@ -1,3 +1,19 @@
+perdition (1.17.1-2+lenny1) stable; urgency=low
+
+ * Don't call make from perdition prerm script
+- make may not be installed
+- unnecessary clean up of user-generated files
+- Upstream patch:
+ http://hg.vergenet.net/perdition/perdition/rev/5425b7c0637b
+- (closes: #595432)
+ * ssl: Set session_id
+- CVE-2009-3555
+- Upstream patch:
+ http://hg.vergenet.net/perdition/perdition/rev/6d85be38374c
+- (closes: #595207)
+
+ -- Simon Horman ho...@debian.org Mon, 06 Sep 2010 11:36:02 +0900
+
perdition (1.17.1-2) unstable; urgency=low
* Add LSB tags to init script
only in patch2:
unchanged:
--- perdition-1.17.1.orig/debian/perdition.prerm
+++ perdition-1.17.1/debian/perdition.prerm
@@ -3,8 +3,6 @@
#DEBHELPER#
-make -C /etc/perdition/ clean /dev/null
-
if [ $1 = purge -o $1 = remove ]; then
if [ -f /etc/init.d/perdition ]; then
invoke-rc.d perdition stop
only in patch2:
unchanged:
--- perdition-1.17.1.orig/perdition/ssl.c
+++ perdition-1.17.1/perdition/ssl.c
@@ -443,6 +443,15 @@
return NULL;
}
+ /* Set context for session */
+ if (!SSL_CTX_set_session_id_context(ssl_ctx,
+ (unsigned char *)PACKAGE,
+ strlen(PACKAGE))) {
+ VANESSA_LOGGER_DEBUG(SSL_CTX_set_session_id_context);
+ SSL_CTX_free(ssl_ctx);
+ return NULL;
+ }
+
/*
* Set the available ciphers
*/
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592498: [Debian-ha-maintainers] Bug#592498: Bug#592498: pacemaker-mgmt: FTBFS: Build-depends on libsnmp10-dev
On Tue, Aug 10, 2010 at 07:22:13PM +0200, Kurt Roeckx wrote: On Tue, Aug 10, 2010 at 11:32:59AM -0400, Simon Horman wrote: On Tue, Aug 10, 2010 at 05:07:58PM +0200, Kurt Roeckx wrote: Source: pacemaker-mgmt Version: 2.0.0+hg1141-1 Severity: serious Hi, There was an error while trying to autobuild your package. You have: Build-Depends: debhelper (= 5.0.37.2), libsnmp10-dev | libsnmp-dev, libglib2.0-dev, net-tools, python, libtool, libcurl4-openssl-dev | libcurl3-openssl-dev, libxml2-dev, bison, flex, uuid-dev, lynx, libbz2-dev, zlib1g-dev, libltdl3-dev, swig, libgnutls-dev, python-central (= 0.5), python-dev, libpam0g-dev, libncurses5-dev, intltool, pacemaker-dev (= 1.0.9.1+hg15626), quilt (= 0.46-7~) The problem is that the buildds will only try libsnmp10-dev and not libsnmp-dev. Is the correct change to depend on libsnmp10-dev | libsnmp-dev, or to just depend on libsnmp-dev? libsnmp10-dev does not exists and is not provided by any package. libsnmp-dev does exists, even in stable. So I suggest you just change it to libsnmp-dev. Thanks. (Other) debian-ha-maintainers, is there any objection to uploading with this single change? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592498: [Debian-ha-maintainers] Bug#592498: pacemaker-mgmt: FTBFS: Build-depends on libsnmp10-dev
On Tue, Aug 10, 2010 at 05:07:58PM +0200, Kurt Roeckx wrote: Source: pacemaker-mgmt Version: 2.0.0+hg1141-1 Severity: serious Hi, There was an error while trying to autobuild your package. You have: Build-Depends: debhelper (= 5.0.37.2), libsnmp10-dev | libsnmp-dev, libglib2.0-dev, net-tools, python, libtool, libcurl4-openssl-dev | libcurl3-openssl-dev, libxml2-dev, bison, flex, uuid-dev, lynx, libbz2-dev, zlib1g-dev, libltdl3-dev, swig, libgnutls-dev, python-central (= 0.5), python-dev, libpam0g-dev, libncurses5-dev, intltool, pacemaker-dev (= 1.0.9.1+hg15626), quilt (= 0.46-7~) The problem is that the buildds will only try libsnmp10-dev and not libsnmp-dev. Is the correct change to depend on libsnmp10-dev | libsnmp-dev, or to just depend on libsnmp-dev? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582874: [Debian-ha-maintainers] [PATCH] debian/rules: force bash for configure (#582874)
On Wed, May 26, 2010 at 06:04:38PM +0900, Simon Horman wrote: [CCed bug] On Wed, May 26, 2010 at 08:38:52AM +0200, Florian Haas wrote: On 05/26/2010 02:00 AM, Simon Horman wrote: On Tue, May 25, 2010 at 12:32:57PM +0200, Florian Haas wrote: # HG changeset patch # User Florian Haas florian.h...@linbit.com # Date 1274778576 -7200 # Branch sid # Node ID 8c7e088098feba1d4bae115acb3d646b743e2462 # Parent 01459d573bc597a83911cdb78deba704dea0ad79 debian/rules: force bash for configure (#582874) Fix debian/rules to explicitly invoke bash for running configure (see BTS #582874). Is forcing bash the best solution to this problem? I figured it was, as it was one of the suggested solutions mentioned in the bug report. But other reporters apparently mentioned that export CONFIG_SHELL=/bin/bash worked better for them. As for whether export -n in that autoconf script is actually needed I'm not certain -- please look into it, that part is from you. :) Point taken. I'm surprised that if fails given that the line in question is export -n CFLAGS || true Hi, I propose the following patch as a solution to this problem: unset CFLAGS in a dash-friendly way According to the dash man page, the only way to unexport a variable is to unset it. This also works in bash. For the record, the reason that CFLAGS is exported from the environment to configure and configure appends -Werror to the CFLAGS then it will be re-exported by configure and has been observed to cause trouble when configure runs a separate configure is the libltdl directory. Signed-off-by: Simon Horman ho...@verge.net.au diff -r cc74c5d2e9f3 configure.ac --- a/configure.ac Sun May 16 21:10:59 2010 +0200 +++ b/configure.ac Mon Jun 07 16:55:53 2010 +0900 @@ -1140,7 +1140,10 @@ CC_EXTRAS= if export | fgrep CFLAGS= /dev/null; then - export -n CFLAGS || true # We don't want to bomb out if this fails + SAVED_CFLAGS=$CFLAGS + unset CFLAGS + CFLAGS=$SAVED_CFLAGS + unset SAVED_CFLAGS fi if test $GCC != yes; then -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582875: [Debian-ha-maintainers] Bug#582875: cluster-glue: FTBFS: export: 16139: Illegal option -n
There is some discussion of this problem in the cluster-glue edition of this patch, #582874 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582874: [Debian-ha-maintainers] [PATCH] debian/rules: force bash for configure (#582874)
[CCed bug] On Wed, May 26, 2010 at 08:38:52AM +0200, Florian Haas wrote: On 05/26/2010 02:00 AM, Simon Horman wrote: On Tue, May 25, 2010 at 12:32:57PM +0200, Florian Haas wrote: # HG changeset patch # User Florian Haas florian.h...@linbit.com # Date 1274778576 -7200 # Branch sid # Node ID 8c7e088098feba1d4bae115acb3d646b743e2462 # Parent 01459d573bc597a83911cdb78deba704dea0ad79 debian/rules: force bash for configure (#582874) Fix debian/rules to explicitly invoke bash for running configure (see BTS #582874). Is forcing bash the best solution to this problem? I figured it was, as it was one of the suggested solutions mentioned in the bug report. But other reporters apparently mentioned that export CONFIG_SHELL=/bin/bash worked better for them. As for whether export -n in that autoconf script is actually needed I'm not certain -- please look into it, that part is from you. :) Point taken. I'm surprised that if fails given that the line in question is export -n CFLAGS || true -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552690: mknod-in-maintainer-script postinst:39
On Sun, Jan 24, 2010 at 09:02:50PM -0800, Steve Langasek wrote: I'm reluctant to upload because of it. But I can if people feel strongly about it. The practical impact here is that until this bug is fixed, due to the archive lintian checks currently in place, this package can't be uploaded - including for security NMUs. So I would suggest that you upload, even though IMHO there's no reason to consider fifos device files under 10.6 and we should fix lintian as well. (Policy doesn't talk about mknod, it talks about device files; so 'mknod p' and 'mkfifo' are equally valid or invalid.) I see your point. I'll get the upload done ASAP. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552690: mknod-in-maintainer-script postinst:39
On Sat, Jan 23, 2010 at 07:42:47PM +0100, Jan Wagner wrote: Hi there, On Thursday 29 October 2009, Manoj Srivastava wrote: You may use mkfifo instead of mknod, since there is no policy prohibition on mkfifo (and it can't be used to make special files). Perhaps we can add a footnote to policy mentioning mkfifo where the mknod prohibition is written? what about the suggested change? Is anything blocking this fix? :) The suggested change seems entirely reasonable to me. I'm reluctant to upload because of it. But I can if people feel strongly about it. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559845: CVE-2009-3736 local privilege escalation
On Tue, Dec 08, 2009 at 10:41:20AM +1100, Simon Horman wrote: On Mon, Dec 07, 2009 at 11:12:32PM +1100, Simon Horman wrote: On Mon, Dec 07, 2009 at 12:11:07AM -0500, Michael Gilbert wrote: Package: heartbeat Severity: grave Tags: security Hi, The following CVE (Common Vulnerabilities Exposures) id was published for libtool. I see that heartbeat in unstable no longer embeds libtool, but it appears that etch and lenny still have it. I am not sure if it is actually used in the binary packages though. Please check. If those packages are not affected, please close the bug. CVE-2009-3736[0]: | ltdl.c in libltdl in GNU Libtool 1.5.x, and 2.2.6 before 2.2.6b, | attempts to open a .la file in the current working directory, which | allows local users to gain privileges via a Trojan horse file. Note that this problem also affects etch and lenny, so if your package is affected, please coordinate with the security team to release the DSA for the affected packages. If you fix the vulnerability please also make sure to include the CVE id in your changelog entry. For further information see: [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3736 http://security-tracker.debian.org/tracker/CVE-2009-3736 Hi, Thanks for bringing this to my attention. First, for clarification, I believe the relevant packages that are potentially affected are: Etch (oldstable): heartbeat 1.2.5-3, heartbeat-2 2.0.7-2 Etch-backports:2.1.3-6~bpo40+2 Lenny (stable):heartbeat 2.1.3-6lenny4 Lenny-backports: 2.1.4-7~bpo50+1 Squeeze (testing): heartbeat 2.1.4-7 Sid (unstable):heartbeat 2.1.4-7 Experimental: heartbeat 2.99.2+sles11r9-1 With reference to https://bugzilla.redhat.com/show_bug.cgi?id=537941, which seems to be the most comprehensive source of information on this topic from a coding point of view, I have noted the following: * In the Etch, Lenny, Sqeeze and Sid versions of heartbeat (and heartbeat-2) .la files are only provided in -dev packages, which I suspect would not ordinarily be installed. I am unsure of the status of this with regards to the Experimental version. * In the Etch version the only place that lt_dlopen*() appears to be called is inside the PILS library. And in a somewhat verbose way PILS ensures that the argument passed to lt_dlopen() is an absolute path which begins with /usr/lib/heartbeat/plugins (PLUGIN_DIR, set at compile time). I will verify this in the other versions. Probably tomorrow. The Etch, Etch-backports, Lenny and Lenny-backports versions seem to share the property that lt_dlopen is always passed a fully qualified path, and its always under the somewhat secure directory /usr/lib/heartbeat * The Squeeze, Sid and Experimental versions do not use their own ltdl. With the latter point in mind I am suspecting that heartbeat (and heartbeat-2) is not vulnerable to this problem. I would greatly appreciate other opinions on this. Ping: Any comment on this analysis? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559845: CVE-2009-3736 local privilege escalation
On Mon, Dec 07, 2009 at 12:11:07AM -0500, Michael Gilbert wrote: Package: heartbeat Severity: grave Tags: security Hi, The following CVE (Common Vulnerabilities Exposures) id was published for libtool. I see that heartbeat in unstable no longer embeds libtool, but it appears that etch and lenny still have it. I am not sure if it is actually used in the binary packages though. Please check. If those packages are not affected, please close the bug. CVE-2009-3736[0]: | ltdl.c in libltdl in GNU Libtool 1.5.x, and 2.2.6 before 2.2.6b, | attempts to open a .la file in the current working directory, which | allows local users to gain privileges via a Trojan horse file. Note that this problem also affects etch and lenny, so if your package is affected, please coordinate with the security team to release the DSA for the affected packages. If you fix the vulnerability please also make sure to include the CVE id in your changelog entry. For further information see: [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3736 http://security-tracker.debian.org/tracker/CVE-2009-3736 Hi, Thanks for bringing this to my attention. First, for clarification, I believe the relevant packages that are potentially affected are: Etch (oldstable): heartbeat 1.2.5-3, heartbeat-2 2.0.7-2 Lenny (stable):heartbeat 2.1.3-6lenny4 Squeeze (testing): heartbeat 2.1.4-7 Sid (unstable):heartbeat 2.1.4-7 Experimental: heartbeat 2.99.2+sles11r9-1 With reference to https://bugzilla.redhat.com/show_bug.cgi?id=537941, which seems to be the most comprehensive source of information on this topic from a coding point of view, I have noted the following: * In the Etch, Lenny, Sqeeze and Sid versions of heartbeat (and heartbeat-2) .la files are only provided in -dev packages, which I suspect would not ordinarily be installed. I am unsure of the status of this with regards to the Experimental version. * In the Etch version the only place that lt_dlopen*() appears to be called is inside the PILS library. And in a somewhat verbose way PILS ensures that the argument passed to lt_dlopen() is an absolute path which begins with /usr/lib/heartbeat/plugins (PLUGIN_DIR, set at compile time). I will verify this in the other versions. Probably tomorrow. With the latter point in mind I am suspecting that heartbeat (and heartbeat-2) is not vulnerable to this problem. I would greatly appreciate other opinions on this. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#559845: CVE-2009-3736 local privilege escalation
On Mon, Dec 07, 2009 at 11:12:32PM +1100, Simon Horman wrote: On Mon, Dec 07, 2009 at 12:11:07AM -0500, Michael Gilbert wrote: Package: heartbeat Severity: grave Tags: security Hi, The following CVE (Common Vulnerabilities Exposures) id was published for libtool. I see that heartbeat in unstable no longer embeds libtool, but it appears that etch and lenny still have it. I am not sure if it is actually used in the binary packages though. Please check. If those packages are not affected, please close the bug. CVE-2009-3736[0]: | ltdl.c in libltdl in GNU Libtool 1.5.x, and 2.2.6 before 2.2.6b, | attempts to open a .la file in the current working directory, which | allows local users to gain privileges via a Trojan horse file. Note that this problem also affects etch and lenny, so if your package is affected, please coordinate with the security team to release the DSA for the affected packages. If you fix the vulnerability please also make sure to include the CVE id in your changelog entry. For further information see: [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3736 http://security-tracker.debian.org/tracker/CVE-2009-3736 Hi, Thanks for bringing this to my attention. First, for clarification, I believe the relevant packages that are potentially affected are: Etch (oldstable): heartbeat 1.2.5-3, heartbeat-2 2.0.7-2 Etch-backports:2.1.3-6~bpo40+2 Lenny (stable):heartbeat 2.1.3-6lenny4 Lenny-backports: 2.1.4-7~bpo50+1 Squeeze (testing): heartbeat 2.1.4-7 Sid (unstable):heartbeat 2.1.4-7 Experimental: heartbeat 2.99.2+sles11r9-1 With reference to https://bugzilla.redhat.com/show_bug.cgi?id=537941, which seems to be the most comprehensive source of information on this topic from a coding point of view, I have noted the following: * In the Etch, Lenny, Sqeeze and Sid versions of heartbeat (and heartbeat-2) .la files are only provided in -dev packages, which I suspect would not ordinarily be installed. I am unsure of the status of this with regards to the Experimental version. * In the Etch version the only place that lt_dlopen*() appears to be called is inside the PILS library. And in a somewhat verbose way PILS ensures that the argument passed to lt_dlopen() is an absolute path which begins with /usr/lib/heartbeat/plugins (PLUGIN_DIR, set at compile time). I will verify this in the other versions. Probably tomorrow. The Etch, Etch-backports, Lenny and Lenny-backports versions seem to share the property that lt_dlopen is always passed a fully qualified path, and its always under the somewhat secure directory /usr/lib/heartbeat * The Squeeze, Sid and Experimental versions do not use their own ltdl. With the latter point in mind I am suspecting that heartbeat (and heartbeat-2) is not vulnerable to this problem. I would greatly appreciate other opinions on this. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552690: mknod-in-maintainer-script postinst:39
On Tue, Oct 27, 2009 at 04:24:24PM -0500, Manoj Srivastava wrote: Package: heartbeat Version: 2.1.4-7 Severity: serious User: lintian-ma...@debian.org Usertags: mknod-in-maintainer-script Justification: Maintainer scripts must not create device files directly. Refer to Debian Policy Manual section 10.6 (Device files) for details. Could you suggest a policy-compliant method of creating fifos for the package? At the time that I added mknod to the maintainer script the consensus that this was the best option available. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#548054: server null response with perdition-ldap
On Wed, Sep 23, 2009 at 03:58:08PM +0200, Peter Mann wrote: Package: perdition Version: 1.18~rc1-2 Severity: grave Justification: renders package unusable perdition-ldap 1.18~rc1-2 doesn't work, but i found solution on: http://lists.vergenet.net/pipermail/perdition-users/2009-September/002183.html please, update debian package Thanks, I'll get that fix into rc2. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521394: Pre-approval for heartbeat stable-proposed-updates upload (2.1.3-6lenny3)
On Wed, Apr 22, 2009 at 08:51:32AM +0200, Luk Claes wrote: Simon Horman wrote: Hi, I would like to upload a(nother) fresh version of heartbeat to fix a but in the o2cf resource. Without the simple fix suggested by Michel, the script is completely broken - though I should not that the script was first deprecated and more recently removed from upstream. So maybe it's better to not fix it in stable as it's deprecated anyway? I am of two minds of this. But as the fix is rather simple, it does seem to be worthwhile to fix the problem in stable. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521394: heartbeat: ocf resources script o2cb doesn't work
This bug is from upstream, it was present in umpstream 2.1.3 and thus Debian 2.1.3-1. It is probably also present in earlier versions. To the best of my knowlege, is not present in versions beyond 2.1.4, as o2cb appears to have been removed from upstream after that release. -- Simon Horman VA Linux Systems Japan K.K., Sydney, Australia Satellite Office H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521394: heartbeat: ocf resources script o2cb doesn't work
On Fri, Mar 27, 2009 at 10:56:30AM +0100, Michel Rode wrote: Package: heartbeat Version: 2.1.3-6lenny0 Severity: critical Tags: patch Justification: breaks the whole system ocf resources script doe't start because there is a missing $ in line 314. Thanks, I will see about getting this included in the next Lenny update. -- Simon Horman VA Linux Systems Japan K.K., Sydney, Australia Satellite Office H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521394: heartbeat: ocf resources script o2cb doesn't work
found 521394 2.1.3-1 fixed 521394 2.1.4-1 thanks Update: This bug is from upstream, it was present in umpstream 2.1.3 and thus Debian 2.1.3-1. It is probably also present in earlier versions. This bug is not was fixed upstream prior to the release of 2.1.4. Subsequent to the release of 2.1.4 o2cb appears to have been removed from upstream. -- Simon Horman VA Linux Systems Japan K.K., Sydney, Australia Satellite Office H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521394: Pre-approval for heartbeat stable-proposed-updates upload (2.1.3-6lenny3)
Hi, I would like to upload a(nother) fresh version of heartbeat to fix a but in the o2cf resource. Without the simple fix suggested by Michel, the script is completely broken - though I should not that the script was first deprecated and more recently removed from upstream. The fix itself is as follows: --- heartbeat-2.1.3.orig/resources/OCF/o2cb +++ heartbeat-2.1.3/resources/OCF/o2cb @@ -311,7 +311,7 @@ ;; esac -RCO2CB=INITDIR/o2cb +RCO2CB=$INITDIR/o2cb # RCO2CB=/etc/init.d/o2cb if [ ! -x $RCO2CB ]; then This problem is being tracked as #521394 The debdiff below is between 2.1.3-6lenny1 (the current version in lenny) and the most recent proposed version, 2.1.3-6lenny3. 2.1.3-6lenny2 was proposed, but I don't think that it was ever uploaded. It change still appears to be worthy to me. The packages are available for anyone who is intersted at http://packages.vergenet.net/stable-proposed-updates/heartbeat/ Debdiff: diff -u heartbeat-2.1.3/version.Debian heartbeat-2.1.3/version.Debian --- heartbeat-2.1.3/version.Debian +++ heartbeat-2.1.3/version.Debian @@ -1 +1 @@ -2.1.3-6lenny1 +2.1.3-6lenny3 diff -u heartbeat-2.1.3/debian/changelog heartbeat-2.1.3/debian/changelog --- heartbeat-2.1.3/debian/changelog +++ heartbeat-2.1.3/debian/changelog @@ -1,3 +1,20 @@ +heartbeat (2.1.3-6lenny3) stable-proposed-updates; urgency=low + + * Fix syntax error in o2cb which prevented it from working +Upstream-status: o2cb has been removed from upstream +(closes: #521394) + + -- Simon Horman ho...@debian.org Tue, 14 Apr 2009 18:55:26 +1000 + +heartbeat (2.1.3-6lenny2) stable-proposed-updates; urgency=low + + * IPv6addr: Fix handling of /64 prefixes +Upstream-Status: commit 6d5f0f600c0b2147490af0c5e592fc995336902a + IPv6addr fails on /64 prefixes +(closes: #515662) + + -- Simon Horman ho...@debian.org Fri, 20 Feb 2009 02:34:29 + + heartbeat (2.1.3-6lenny1) stable-proposed-updates; urgency=low * dopd: fix basic failover; fix hb message corruption by fprintf(stderr) only in patch2: unchanged: --- heartbeat-2.1.3.orig/resources/OCF/o2cb +++ heartbeat-2.1.3/resources/OCF/o2cb @@ -311,7 +311,7 @@ ;; esac -RCO2CB=INITDIR/o2cb +RCO2CB=$INITDIR/o2cb # RCO2CB=/etc/init.d/o2cb if [ ! -x $RCO2CB ]; then only in patch2: unchanged: --- heartbeat-2.1.3.orig/resources/OCF/IPv6addr.c +++ heartbeat-2.1.3/resources/OCF/IPv6addr.c @@ -487,7 +487,10 @@ n = plen / 32; memset(mask.s6_addr32 + n + 1, 0, (3 - n) * 4); s = 32 - plen % 32; - mask.s6_addr32[n] = 0x s; + if (s == 32) + mask.s6_addr32[n] = 0x0; + else + mask.s6_addr32[n] = 0x s; mask.s6_addr32[n] = htonl(mask.s6_addr32[n]); } only in patch2: unchanged: --- heartbeat-2.1.3.orig/debian/patches/o2cb-INITDIR.patch +++ heartbeat-2.1.3/debian/patches/o2cb-INITDIR.patch @@ -0,0 +1,144 @@ +From horms Sun Mar 29 21:28:35 2009 +Return-Path: bounces+20090327-horms=debian@packages.qa.debian.org +X-Spam-Checker-Version: SpamAssassin 3.2.5-kirsty.vergenet.net_2007012401 + (2008-06-10) on kirsty.vergenet.net +X-Spam-Level: +X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW + autolearn=ham version=3.2.5-kirsty.vergenet.net_2007012401 +X-Original-To: ho...@verge.net.au +Delivered-To: ho...@vergenet.net +Received: from mail.au.vergenet.net [202.4.237.240] + by yukiko.kent.sydney.vergenet.net with POP3 (fetchmail-6.3.9-rc2) + for ho...@localhost (single-drop); Mon, 30 Mar 2009 08:28:35 +1100 (EST) +Received: from master.debian.org (master.debian.org [70.103.162.29]) + by kirsty.vergenet.net (Postfix) with ESMTP id A38DD24060 + for ho...@verge.net.au; Fri, 27 Mar 2009 21:06:11 +1100 (EST) +Received: from qa by master.debian.org with local (Exim 4.69) + (envelope-from bounces+20090327-horms=debian@packages.qa.debian.org) + id 1Ln8x0-TZ-48; Fri, 27 Mar 2009 10:06:10 + +Received: from rietz.debian.org ([140.211.166.43]) by master.debian.org + with esmtp (Exim 4.69)(envelope-from debb...@rietz.debian.org) id + 1Ln8wz-TK-N2 for heartb...@packages.qa.debian.org; Fri, 27 Mar 2009 + 10:06:09 + +Received: from debbugs by rietz.debian.org with local (Exim 4.63) + (envelope-from debb...@rietz.debian.org)id 1Ln8r6-0004Ok-JC; Fri, + 27 Mar 2009 10:00:04 + +X-Loop: ow...@bugs.debian.org +Subject: Bug#521394: heartbeat: ocf resources script o2cb doesn't work +Reply-To: Michel Rode rmic...@devnu11.net, 521...@bugs.debian.org +Resent-From: Michel Rode rmic...@devnu11.net +Resent-To: debian-bugs-d...@lists.debian.org +Resent-CC: Simon Horman ho...@debian.org +Resent-Date: Fri, 27 Mar 2009 10:00:02 + +Resent-Message-ID: handler.521394.b
Bug#488636: file conflicts between packages
reassign 488636 pacemaker thanks Hi, Firstly a bit of background. Pacemaker contains a lot of code that used to be part of heartbeat. A split was made. Code was moved into different development trees, and several versions of pacemaker have been released. However a new version of heartbeat is yet to be released. Thus the heartbeat 2.1.3 package, which is based on the latest release, contains files which are also contained in pacemaker. This also means that the heartbeat 2.1.3 does not make use of pacemaker. It is envisaged that when the next relese of heartbeat comes along the code that is now in pacemaker will have been removed. And, more imporantly, heartbaet will require pacemaker. In the mean time Anibal and I think that it is best to reassign this RC bug to pacemaker to prevent it making it into testing. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488636: file conflicts between packages
On Mon, Jun 30, 2008 at 11:03:57AM +0200, Michael Ablassmeier wrote: Package: heartbeat, pacemaker Severity: serious Justification: policy violation hi, both heartbeat and pacemaker ship `/usr/sbin/crm_verify' but do neither conflict, nor add a diversion, thus fail to be installed in the same environment: Unpacking pacemaker (from .../pacemaker_0.6.5-1_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/pacemaker_0.6.5-1_amd64.deb (--unpack): trying to overwrite `/usr/sbin/crm_verify', which is also in package heartbeat dpkg-deb: subprocess paste killed by signal (Broken pipe) bye, - michael Hi Michael, thanks for bringing this to my attention. Anibal, what is the best way forward with this? Should we just make the packages conflict until such time as there is a new release of heartbeat that uses pacemaker? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455255: heartbeat: FTBFS: debian/tmp/usr/lib/ocf/resource.d/heartbeat/IPv6addr not found
On Sun, Dec 09, 2007 at 03:58:27PM +0100, Kurt Roeckx wrote: Package: heartbeat Version: 2.1.2+hg.11310.702e4f418ca8-2 Severity: serious Hi, Your package is failing to build on ia64 with the following error: checking for linux/icmpv6.h... no [...] chown hacluster /build/buildd/heartbeat-2.1.2+hg.11310.702e4f418ca8/debian/tmp//var/lib/heartbeat/crm chown: `hacluster': invalid user make[4]: [install-exec-local] Error 1 (ignored) chgrp haclient /build/buildd/heartbeat-2.1.2+hg.11310.702e4f418ca8/debian/tmp//var/lib/heartbeat/crm chgrp: invalid group `haclient' make[4]: [install-exec-local] Error 1 (ignored) [...] dh_movefiles --source=debian/tmp dh_movefiles: debian/tmp/usr/lib/ocf/resource.d/heartbeat/IPv6addr not found (supposed to put it in heartbeat) make: *** [install-stamp] Error 1 The chown calls failing are probably unrelated to the IPv6addr not found error. Configure seems to find the hacluster/haclient uid, so I don't know why those failed and the other buildds don't show it. Thanks for pointing this out. It looks like a reapearnce of a bug that I fixed a few months ago. It shouldn't be too hard to refix. I'll try and find some time to investigate shortly. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424192: heartbeat - FTBFS: dh_movefiles: debian/tmp//etc/ha.d/resource.d/ldirectord not found (supposed to put it in ldirectord-2)
On Tue, May 15, 2007 at 11:08:14PM +0200, Bastian Blank wrote: Package: heartbeat Version: 2.0.8-3 Severity: serious There was an error while trying to autobuild your package: Thanks, I will look into it ASAP -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422107: uninstallable
On Fri, May 04, 2007 at 11:31:06AM +0200, Steinar H. Gunderson wrote: On Fri, May 04, 2007 at 11:49:20AM +0900, Simon Horman wrote: heartbeat is uninstallable in unstable: My gut feeling is that libsnmp9 shouldn't have been removed while packages still depend on it. But apparently it was. Yes. I don't know why, you might want to check the removal logs. :-) I guess that the best way forward is to simp0le rebuild heartbeat against libsnmp10 and upload. Yes. Ask the RMs and they can probably schedule binNMUs for you. I'm sorry, but I don't understand that a binNMU is. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422107: uninstallable
On Thu, May 03, 2007 at 02:06:52PM +0200, Steinar H. Gunderson wrote: Package: heartbeat Version: 1.2.5-3 Severity: serious Tags: sid heartbeat is uninstallable in unstable: [EMAIL PROTECTED]:/# apt-get install heartbeat Reading package lists... Done Building dependency tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: heartbeat: Depends: libsnmp9 (= 5.2.3) but it is not installable Depends: libstonith0 (= 1.2.5) libsnmp9 no longer exists in unstable; it might be that a simple binNMU will fix this. Thanks for bringing this to my attention. My gut feeling is that libsnmp9 shouldn't have been removed while packages still depend on it. But apparently it was. I guess that the best way forward is to simp0le rebuild heartbeat against libsnmp10 and upload. Opinions? -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#421415: ldirectord: Ldirectord crashed because of missing dep on libmail-pop3client-perl
Thanks, I'll get this fixed in the next release. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419617: uim-common: postinst script fails (in init.scm?)
On Fri, Apr 20, 2007 at 01:00:53PM +0900, Simon Horman wrote:
On Fri, Apr 20, 2007 at 05:32:26AM +0900, Masahito Omote wrote:
I confirmed this behavior. This happens only when uim-common only is
upgradeed and
other uim related packages are not upgreaded.
This situation only becomes only when you take shotgun approach in
upgrading.
It does not happen if all uim packages are in archive(In i386 uim cannot be
built
because of dbus problem. Check
http://buildd.debian.org/build.php?pkg=uimver=1%3A1.4.1-2arch=i386file=log
for more details.).
Therefore I close this bug.
Hi Omote-san,
assuming that your shotgun theory is correct, shouldn't the packages
have relevant dependancies in place? Furthermore, shouldn't the bug be
reopend pending the addition of such dependancies? I'm currently
experiencing this problem as part of an apt-get upgrade, which isn't
really ideal.
I looked a little more closer, and I guess that for
uim-module-manager to execute correctly in the postinst libuim5 needs
to be installed. But because I was doing an aptitude upgrade and
not an aptitude dist-upgrade I still had the older libuim3.
I think that either the postinst needs to be reworked (I don't
even know if that makes sense) or uim-common needs to depend on
libuim5 (= ${binary:Version})
I made a package with this change and after this uim-common was
held-back during an aptitude upgrade, which seems to be correct. When I
subsequently did a aptitude dist-upgrade then all the uim packages
were upgraded without incident.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419617: uim-common: postinst script fails (in init.scm?)
On Fri, Apr 20, 2007 at 05:32:26AM +0900, Masahito Omote wrote: I confirmed this behavior. This happens only when uim-common only is upgradeed and other uim related packages are not upgreaded. This situation only becomes only when you take shotgun approach in upgrading. It does not happen if all uim packages are in archive(In i386 uim cannot be built because of dbus problem. Check http://buildd.debian.org/build.php?pkg=uimver=1%3A1.4.1-2arch=i386file=log for more details.). Therefore I close this bug. Hi Omote-san, assuming that your shotgun theory is correct, shouldn't the packages have relevant dependancies in place? Furthermore, shouldn't the bug be reopend pending the addition of such dependancies? I'm currently experiencing this problem as part of an apt-get upgrade, which isn't really ideal. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
