Bug#1030248: [PATCH] kexec: make -a the default
On Fri, Feb 03, 2023 at 12:10:18AM +0100, Ahelenia Ziemiańska wrote: > AFAICT, there's no downside to this, and running into this each time > I want to kexec (and, presumably, a significant chunk of the population, > since lockdown is quite popular) on some machines, > then going to the manual, then finding out I want the /auto/ flag(!) > is quite annoying: > # kexec -l /boot/vmlinuz-6.1.0-3-amd64 --initrd > /boot/initrd.img-6.1.0-3-amd64 --reuse-cmdline > kexec_load failed: Operation not permitted > entry = 0x46eff7760 flags = 0x3e > nr_segments = 7 > segment[0].buf = 0x557cd303efa0 > segment[0].bufsz = 0x70 > segment[0].mem = 0x10 > segment[0].memsz = 0x1000 > segment[1].buf = 0x557cd3046fe0 > segment[1].bufsz = 0x190 > segment[1].mem = 0x101000 > segment[1].memsz = 0x1000 > segment[2].buf = 0x557cd303f6e0 > segment[2].bufsz = 0x30 > segment[2].mem = 0x102000 > segment[2].memsz = 0x1000 > segment[3].buf = 0x7f658fa37010 > segment[3].bufsz = 0x12a51b5 > segment[3].mem = 0x46a55a000 > segment[3].memsz = 0x12a6000 > segment[4].buf = 0x7f6590ce1210 > segment[4].bufsz = 0x7e99e0 > segment[4].mem = 0x46b80 > segment[4].memsz = 0x377c000 > segment[5].buf = 0x557cd3039350 > segment[5].bufsz = 0x42fa > segment[5].mem = 0x46eff2000 > segment[5].memsz = 0x5000 > segment[6].buf = 0x557cd3032000 > segment[6].bufsz = 0x70e0 > segment[6].mem = 0x46eff7000 > segment[6].memsz = 0x9000 > > Closes: https://bugs.debian.org/1030248 > Signed-off-by: Ahelenia Ziemiańska Thanks, applied.
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#896165: linux: request packaging of bpftool
On Fri, Dec 14, 2018 at 11:16:10AM +0100, Simon Horman wrote: > On Wed, Nov 28, 2018 at 07:49:50PM -0800, Noah Meyerhans wrote: > > On Tue, Nov 27, 2018 at 09:50:17AM -0800, Jakub Kicinski wrote: > > > > > Please see > > > > > https://salsa.debian.org/kernel-team/linux/merge_requests/72 > > > > > > > > Ugh. We cannot currently package bpftool in Debian. There are several > > > > GPLv2-only files in its source tree, and it links unconditionally > > > > against the GPLv3 libbfd. :( > > > > > > If we relicense the GPLv2-only files to be GPLv2-only OR BSD-2-Clause > > > - like the majority of bpftool sources - would that work? > > > > > > I wanted to make sure GPLv2-only + BSD-2-Clause will satisfy the > > > license requirement when linking against libbfd, before I start chasing > > > people for acks on the relicense :) > > > > Yes, the BSD 2-clause license is OK. GPLv2 or greater would be OK, too. > > It's really just GPLv2-only in this case that's causing the problem. > > Hi, > > the following merge-commit, which has been accepted into bpf-next > for inclusion in v4.21, addresses the problem raised above by > clarifying that the licence of bpftool is GPLv2-only + BSD-2-Clause. > > commit 00842be52f2015c3c1028e16b565f325f4ca20fc > Merge: 8f9a8a619311 907b22365115 > Author: Daniel Borkmann > Date: Thu Dec 13 12:08:45 2018 +0100 > > Merge branch 'bpf-bpftool-license-update' > > Jakub Kicinski says: > > > We are changing/clarifying the license on bpftool to GPLv2-only + > BSD-2-Clause for all files. Current license mix is incompatible > with libbfd (which is GPLv3-only) and therefore Debian maintainers > are apprehensive about packaging bpftool. > > Acks include authors of code which has been copied into bpftool (e.g. > JSON writer from iproute2, code from tools/bpf, code from BPF samples > and selftests, etc.) > > Thanks again to all the authors who acked the change! > > > Acked-by: Roman Gushchin > Acked-by: YueHaibing > Acked-by: Yonghong Song > Acked-by: Stanislav Fomichev > Acked-by: Sean Young > Acked-by: Jiri Benc > Acked-by: David Calavera > Acked-by: Andrey Ignatov > Acked-by: Joe Stringer > Acked-by: David Ahern > Acked-by: Alexei Starovoitov > Acked-by: Petar Penkov > Acked-by: Sandipan Das > Acked-by: Prashant Bhole > Acked-by: Stephen Hemminger > Acked-by: John Fastabend > Acked-by: Taeung Song > Acked-by: Jiri Olsa > Acked-by: Daniel Borkmann > CC: okash.khaw...@gmail.com > Signed-off-by: Daniel Borkmann Hi Noah, I believe that the above commit resolves the licence problem that was raised earlier. Is it possible to find a way to move forwards on packaging bpftool?
Bug#896165: linux: request packaging of bpftool
On Wed, Nov 28, 2018 at 07:49:50PM -0800, Noah Meyerhans wrote: > On Tue, Nov 27, 2018 at 09:50:17AM -0800, Jakub Kicinski wrote: > > > > Please see https://salsa.debian.org/kernel-team/linux/merge_requests/72 > > > > > > Ugh. We cannot currently package bpftool in Debian. There are several > > > GPLv2-only files in its source tree, and it links unconditionally > > > against the GPLv3 libbfd. :( > > > > If we relicense the GPLv2-only files to be GPLv2-only OR BSD-2-Clause > > - like the majority of bpftool sources - would that work? > > > > I wanted to make sure GPLv2-only + BSD-2-Clause will satisfy the > > license requirement when linking against libbfd, before I start chasing > > people for acks on the relicense :) > > Yes, the BSD 2-clause license is OK. GPLv2 or greater would be OK, too. > It's really just GPLv2-only in this case that's causing the problem. Hi, the following merge-commit, which has been accepted into bpf-next for inclusion in v4.21, addresses the problem raised above by clarifying that the licence of bpftool is GPLv2-only + BSD-2-Clause. commit 00842be52f2015c3c1028e16b565f325f4ca20fc Merge: 8f9a8a619311 907b22365115 Author: Daniel Borkmann Date: Thu Dec 13 12:08:45 2018 +0100 Merge branch 'bpf-bpftool-license-update' Jakub Kicinski says: We are changing/clarifying the license on bpftool to GPLv2-only + BSD-2-Clause for all files. Current license mix is incompatible with libbfd (which is GPLv3-only) and therefore Debian maintainers are apprehensive about packaging bpftool. Acks include authors of code which has been copied into bpftool (e.g. JSON writer from iproute2, code from tools/bpf, code from BPF samples and selftests, etc.) Thanks again to all the authors who acked the change! Acked-by: Roman Gushchin Acked-by: YueHaibing Acked-by: Yonghong Song Acked-by: Stanislav Fomichev Acked-by: Sean Young Acked-by: Jiri Benc Acked-by: David Calavera Acked-by: Andrey Ignatov Acked-by: Joe Stringer Acked-by: David Ahern Acked-by: Alexei Starovoitov Acked-by: Petar Penkov Acked-by: Sandipan Das Acked-by: Prashant Bhole Acked-by: Stephen Hemminger Acked-by: John Fastabend Acked-by: Taeung Song Acked-by: Jiri Olsa Acked-by: Daniel Borkmann CC: okash.khaw...@gmail.com Signed-off-by: Daniel Borkmann
Bug#896165: linux: request packaging of bpftool
Source: linux Version: 4.9.65-3+deb9u2 Severity: wishlist Dear Maintainer, I would like to request packaging of bpftool which has been included in upstream Linux tree since v4.15-rc1. I expect this can be done in a similar manner to the way that perf, also present in the upstream Linux kernel tree, is packaged. The purpose of bpftool is to allow querying and updating BPF objects on the system. It is actively developed and maintained by upstream. Kind regards, Simon *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-0.bpo.2-amd64 (SMP w/4 CPU cores) Locale: LANG=nl_NL.utf8, LC_CTYPE=nl_NL.utf8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE=nl_NL.utf8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#776949: fake: please make the build reproducible
On Mon, Jan 09, 2017 at 11:10:05AM +, Chris Lamb wrote: > Dear Maintainer, > > > Source: fake > > Version: 1.1.11-1 > > Tags: patch > > Alas, there hasn't seem to be any further update to this bug in 148 days. > Would you consider applying this patch and uploading prior to the upcoming > release? :) Sure, will do.
Bug#787998: perdition: FTBFS with openssl 1.1.0
tags 828494 +pending
thanks
This problem should be resolved by the following patch:
# HG changeset patch
# User Simon Horman <ho...@verge.net.au>
# Date 1477918609 -3600
# Mon Oct 31 13:56:49 2016 +0100
# Node ID 798cc9df07879d58db9096456b43948159c2825b
# Parent 96a24b495d6bac69e5fb450718163e741da7f147
Allow compilation against OpenSSL 1.1
diff -r 96a24b495d6b -r 798cc9df0787 debian/changelog
--- a/debian/changelog Thu May 12 16:56:30 2016 +0900
+++ b/debian/changelog Mon Oct 31 13:56:49 2016 +0100
@@ -4,8 +4,10 @@
(closes: #765867)
* Make builds reproducible
(closes: #787998)
+ * Allow compilation against OpenSSL 1.1
+(closes: #828494)
- -- Simon Horman <ho...@debian.org> Sat, 13 Jun 2015 09:05:34 +0900
+ -- Simon Horman <ho...@debian.org> Mon, 31 Oct 2016 13:55:18 +0100
perdition (2.1-2) unstable; urgency=medium
diff -r 96a24b495d6b -r 798cc9df0787 perdition/ssl.c
--- a/perdition/ssl.c Thu May 12 16:56:30 2016 +0900
+++ b/perdition/ssl.c Mon Oct 31 13:56:49 2016 +0100
@@ -262,10 +262,9 @@
return 0;
}
- if (__perdition_verify_result(ctx->error, cert)
- == X509_V_OK) {
+ if (__perdition_verify_result(X509_STORE_CTX_get_error(ctx),
+ cert) == X509_V_OK)
return 1;
- }
return ok;
}
@@ -910,7 +909,6 @@
__perdition_ssl_check_common_name(X509 *cert, const char *key)
{
int i;
- X509_NAME_ENTRY *e;
X509_NAME *name;
name = X509_get_subject_name(cert);
@@ -922,6 +920,9 @@
i = -1;
while (1) {
+ X509_NAME_ENTRY *e;
+ ASN1_STRING *data;
+
i = X509_NAME_get_index_by_NID(name, NID_commonName, i);
if (i == -1)
break;
@@ -933,8 +934,14 @@
return -1;
}
- if (!__perdition_ssl_compare_key(key, e->value->data,
-e->value->length))
+ data = X509_NAME_ENTRY_get_data(e);
+ if (!data) {
+ VANESSA_LOGGER_DEBUG_RAW_UNSAFE("warning: could not "
+ "extract data for name entry %d", i);
+ return -1;
+ }
+
+ if (!__perdition_ssl_compare_key(key, data->data, data->length))
return 0;
}
Bug#787998: perdition: Request for Forward Secrecy
tags 787998 +pending thanks Hi, thanks for the contributions contained in this bug report. I have queued them up in the perdition mercurial repository[1] and they should appear in the next upload of perdition. [1] http://hg.vergenet.net/perdition/perdition/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765867: perdition: Request for Forward Secrecy
tags 765867 +pending thanks Hi Matthias, Hi Sergio, thanks for the contributions contained in this bug report. I have queued them up in the perdition mercurial repository[1] and they should appear in the next revision of perdition. [1] http://hg.vergenet.net/perdition/perdition/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773535: release.debian.org: openvswitch-switch/2.3.0+git20140819-3
Package: release.debian.org
Severity: normal
Please unblock package openvswitch-switch
This release fixes an RC bug:
- Open vSwitch configuration through /etc/network/interfaces does not work
#771863
I chose to resolve this problem using the fix that has been
accepted upstream.
The new package does not make any other changes.
The debdiff is attached; it is not large.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=ja_JP.utf8, LC_CTYPE=ja_JP.utf8 (charmap=UTF-8) (ignored: LC_ALL
set to ja_JP.utf8)
Shell: /bin/sh linked to /bin/bash
diff -Nru openvswitch-2.3.0+git20140819/debian/changelog openvswitch-2.3.0+git20140819/debian/changelog
--- openvswitch-2.3.0+git20140819/debian/changelog 2014-08-21 00:35:32.0 +0900
+++ openvswitch-2.3.0+git20140819/debian/changelog 2014-12-19 12:32:53.0 +0900
@@ -1,3 +1,15 @@
+openvswitch (2.3.0+git20140819-3) unstable; urgency=medium
+
+ * Don't depened on $RUNLEVEL at startup to create bridges.
+This should allow Open vSwitch configuration through
+/etc/network/interfaces where $RUNLEVEL is not set.
+This change is upstream commit 238324bd73b031635
+(debian: Don't depened on $RUNLEVEL at startup to create bridges.)
+Closes: #771863
+ *
+
+ -- Simon Horman ho...@debian.org Fri, 19 Dec 2014 10:54:08 +0900
+
openvswitch (2.3.0+git20140819-2) unstable; urgency=low
* debian/rules: Rerun checks on tests that fail the first time. Skip
diff -Nru openvswitch-2.3.0+git20140819/debian/openvswitch-switch.init openvswitch-2.3.0+git20140819/debian/openvswitch-switch.init
--- openvswitch-2.3.0+git20140819/debian/openvswitch-switch.init 2014-08-20 00:30:43.0 +0900
+++ openvswitch-2.3.0+git20140819/debian/openvswitch-switch.init 2014-12-19 11:18:44.0 +0900
@@ -31,7 +31,6 @@
test -e /etc/default/openvswitch-switch . /etc/default/openvswitch-switch
network_interfaces () {
-[ -z ${RUNLEVEL} ] return
INTERFACES=/etc/network/interfaces
[ -e ${INTERFACES} ] || return
bridges=`awk '{ if ($1 == allow-ovs) { print $2; } }' ${INTERFACES}`
@@ -62,11 +61,13 @@
fi
set $@ $OVS_CTL_OPTS
$@ || exit $?
-[ $2 = start ] network_interfaces ifup
+if [ $2 = start ] [ $READ_INTERFACES != no ]; then
+network_interfaces ifup
+fi
}
stop () {
-network_interfaces ifdown
+[ $READ_INTERFACES != no ] network_interfaces ifdown
ovs_ctl stop
}
@@ -101,8 +102,8 @@
start restart
fi
else
-stop
-start
+READ_INTERFACES=no stop
+READ_INTERFACES=no start
fi
}
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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#716429: Bug report on libvanessa-socket-pipe: vanessa_socket_pipe crashes with exit status 139
Hi,
sorry for letting this slip through the cracks.
I believe that the attached patch resolves the problem
that you have reported by only checking the value a pointer
if it is non-NULL.
# HG changeset patch
# User Simon Horman ho...@verge.net.au
# Date 1410401069 -32400
# Thu Sep 11 11:04:29 2014 +0900
# Node ID 72a72638d1771fb2066f3ff9036fc9957afc666d
# Parent bc7779a3aa2c146d904d06a40851fba8049c1904
Check pointers are non-NULL before checking their values
When a pointer is returned by a function check that it is
non-NULL before checking its value.
This is a resolution to the problem reported in Debian Bug #716429
See: https://bugs.debian.org/716429
That bug report exercises the problem of the return value
of the call to vanessa_socket_server_bindv() in
vanessa_socket_server_connectv().
Signed-off-by: Simon Horman ho...@verge.net.au
diff -r bc7779a3aa2c -r 72a72638d177 libvanessa_socket/vanessa_socket_server.c
--- a/libvanessa_socket/vanessa_socket_server.c Thu Sep 11 10:41:40 2014 +0900
+++ b/libvanessa_socket/vanessa_socket_server.c Thu Sep 11 11:04:29 2014 +0900
@@ -388,7 +388,7 @@
for(;;) {
addrlen = sizeof(from);
*g = accept(listen_socket, (struct sockaddr *) from, addrlen);
- if (*g 0) {
+ if (!g || *g 0) {
if (opt O_NONBLOCK
(errno == EAGAIN || errno == EWOULDBLOCK))
return -1; /* Don't log EAGAIN or EWOULDBLOCK */
@@ -755,7 +755,7 @@
int g;
s = vanessa_socket_server_bindv(fromv, flag);
- if(*s 0) {
+ if(!s || *s 0) {
VANESSA_LOGGER_DEBUG(vanessa_socket_server_bind_sockaddr_in);
return (-1);
}
Bug#751430: perdition 2.1 available upstream
On Thu, Jun 12, 2014 at 03:35:24PM -0400, Daniel Kahn Gillmor wrote: Source: perdition Severity: wishlist Since February 6, perdition 2.1 has been available: http://horms.org/pleb_blossom/permalink/2014/2014-02-06T16_51_24.shtml It would be great to have this version in debian! Indeed it would. I would be quite happy for someone to help out there. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729028: perdition: ssl_outgoing_ciphers not applied to STARTTLS connections
On Thu, Nov 07, 2013 at 11:31:16PM -0500, Daniel Kahn Gillmor wrote:
Package: perdition
Version: 1.19~rc4-2
Control: found -1 1.19~rc5-1
Control: found -1 2.0-1
Tags: patch security upstream
Forwarded: perdition-us...@vergenet.net
Perdition(8) says:
--ssl_outgoing_ciphers STRING:
Cipher list when making outgoing SSL or TLS connections as
per ciphers(1). If empty () then openssl's default will
be used. (default )
However, this is only the case for outgoing connections that do not use
STARTTLS (the perdition terminology is confusing here, since what it
calls TLS actually means start as cleartext, negotiate to encrypted
via STARTTLS and what it calls SSL actually means start SSL or TLS
session, run service inside that).
Here's the fix:
diff -r 046a7b19cd5b perdition/perdition.c
--- a/perdition/perdition.c Thu Nov 07 21:23:31 2013 -0500
+++ b/perdition/perdition.c Thu Nov 07 21:49:39 2013 -0500
@@ -985,7 +985,7 @@
else if((opt.ssl_mode SSL_MODE_TLS_OUTGOING)
(status PROTOCOL_S_STARTTLS)) {
server_io=perdition_ssl_client_connection(server_io, opt.ssl_ca_file,
- opt.ssl_ca_path, opt.ssl_listen_ciphers, servername);
+ opt.ssl_ca_path, opt.ssl_outgoing_ciphers, servername);
if(!server_io) {
VANESSA_LOGGER_DEBUG(perdition_ssl_connection outgoing);
VANESSA_LOGGER_ERR(Fatal error establishing SSL connection);
This is a security concern because it means that perdition is not
obeying the specifications of the administrator, and may accept weaker
ciphersuites than instructed on its backhaul connections.
Consider the case where an administrator wants to offer relatively
promiscuous IMAP connections to their end users -- if the user's MUA
only has some weak cipher suite or cleartext IMAP, we want to accept the
weak ciphersuite as better than nothing. However, the admin's backend
IMAP servers are all under her control, and she knows that they are
capable of stronger ciphersuites. in this case, ssl_listen_ciphers will
allow weak ciphers, and ssl_outgoing_ciphers will be strict and require
high security, to at least protect the link between perdition and the
backend IMAP server.
However, if this outgoing connection happens to use IMAP+STARTTLS
instead of IMAPS, the bug described here will offer weak ciphersuites to
the backend IMAP server.
All versions of perdition in debian currently have this flaw. I've
reported it to the upstream mailing list, but for whatever reason the
message hasn't cleared that mailing list yet.
Hi Daniel,
thanks for bringing this to my attention and sorry
for not noticing the mailing list post: I'm not suer what happened there.
I think that the best thing to do is both:
* Update the Debian packages with this fix and;
* Release a fresh upstream version of perdition with this fix.
signature.asc
Description: Digital signature
Bug#729028: perdition: ssl_outgoing_ciphers not applied to STARTTLS connections
On Tue, Nov 12, 2013 at 11:59:15PM -0500, Daniel Kahn Gillmor wrote: Hi Simon-- Re: http://bugs.debian.org/729028: On Tue 2013-11-12 23:04:07 -0500, Simon Horman wrote: Thanks for bringing this to my attention and sorry for not noticing the mailing list post: I'm not suer what happened there. dunno if you care to investigate the mailing list situation further. if you do, the post to the mailing list was Message-ID: 87zjpfwqft@alice.fifthhorseman.net The handoff to the vergenet MX looked like this from my side: Nov 7 21:57:50 che postfix/smtp[32630]: 7E90AF984: to=perdition-us...@vergenet.net, relay=mail.au.vergenet.net[202.4.237.240]:25, delay=5.2, delays=0.55/0.01/3.6/1, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as B4DE9266CEF) The message doesn't seem to have made it through to the pipermail archives, which see no messages for November 2013 at all: http://lists.vergenet.net/pipermail/perdition-users/ I think that the best thing to do is both: * Update the Debian packages with this fix and; * Release a fresh upstream version of perdition with this fix. This sounds like a reasonable approach to me. I'm cc'ing the security team so that they're aware of the problem and the potential security-fix upload(s). Would you like me to request a CVE for tracking this issue, or do you intend to request one yourself? If you could request one that would be great. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692721: perdition: Perdition aborts after an accept() error
On Thu, Nov 08, 2012 at 09:52:02AM +, Russell Coker wrote:
Package: perdition
Version: 1.19~rc4-2
Severity: normal
The following is an strace of a repeated perdition abort that is happening on
one of my servers.
I presume it's related to something on the Internet because the system has
been
running Squeeze for ages without trouble and it's crashed about a dozen times
today without having crashed before.
fcntl(3, F_SETFL, O_RDWR) = 0
poll([{fd=3, events=POLLIN}], 1, -1)= 1 ([{fd=3, revents=POLLIN}])
fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)= 0
accept(3, 0x7fffadc5b900, [128])= -1 ECONNABORTED (Software caused
connection abort)
accept(3, 0x7fffadc5b900, [128])= -1 EAGAIN (Resource temporarily
unavailable)
fcntl(3, F_SETFL, O_RDWR) = 0
gettimeofday({1352367448, 368675}, NULL) = 0
socket(PF_FILE, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 4
connect(4, {sa_family=AF_FILE, path=/dev/log}, 110) = 0
sendto(4, 131Nov 8 09:37:28 perdition.imap4[725]: Fatal error accepting
child connection. Exiting.\n, 92, MSG_NOSIGNAL, NULL, 0) = 92
It looks like a good way forward would be to simply jump back to the top of
the main loop if accept() fails and errno is EAGAIN or ECONNABORTED. Do
you think there are any other errno values that should also be ignored?
-- System Information:
Debian Release: 6.0.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Versions of packages perdition depends on:
ii libc6 2.11.3-4 Embedded GNU C Library: Shared
lib
ii libdb4.8 4.8.30-2 Berkeley v4.8 Database Libraries
[
ii libgdbm3 1.8.3-9GNU dbm database routines
(runtime
ii libidn11 1.15-2 GNU Libidn library,
implementation
ii libpam0g 1.1.1-6.1+squeeze1 Pluggable Authentication Modules
l
ii libpopt0 1.16-1 lib for parsing cmdline
parameters
ii libssl0.9.8 0.9.8o-4squeeze13 SSL shared libraries
ii libvanessa-adt1 0.0.9-1Library of Abstract Data Types
ii libvanessa-logger00.0.10-1.1 Generic Logging Library
ii libvanessa-socket20.0.12-1 Library to simplify TCP socket
ope
perdition recommends no packages.
Versions of packages perdition suggests:
pn perdition-ldapnone (no description available)
ii perdition-mysql 1.19~rc4-2 Library to allow perdition to
acce
pn perdition-odbcnone (no description available)
pn perdition-postgresql none (no description available)
-- Configuration Files:
/etc/default/perdition changed:
RUN_PERDITION=yes
FLAGS=--no_bind_banner
POP3=yes
POP3_FLAGS=-t 600
POP3S=yes
POP3S_FLAGS=-t 600 --ssl_mode=ssl_listen --outgoing_port=110
IMAP4=yes
IMAP4_FLAGS=
IMAP4S=yes
IMAP4S_FLAGS=--ssl_mode=ssl_listen --outgoing_port=143
MANAGESIEVE=yes
MANAGESIEVE_FLAGS=
/etc/perdition/perdition.conf changed:
authenticate_timeout 120
domain_delimiter :
log_facility local0
group perdition
imap_capability IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT
LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS UIDPLUS LIST-EXTENDED
I18NLEVEL=1 QUOTA
\IMPLEMENTATION\ \perdition\ \
\SIEVE\ \comparator-i;octet \
comparator-i;ascii-casemap \
fileinto \
reject \
envelope \
encoded-character \
vacation \
subaddress \
comparator-i;ascii-numeric \
relational \
regex \
imap4flags \
copy i\
nclude \
variables \
body \
enotify \
environment \
mailbox \
date\ \
\SASL\ \PLAIN\ \
\NOTIFY\ \mailto\ \
\VERSION\ \1.18\
connection_limit 0
lower_case all
map_library /usr/lib/libperditiondb_mysql.so.0
map_library_opt db2:3306:bluebottle:map:perdition:nuchohB2
timeout 3600
username perdition
ssl_ca_chain_file /etc/ssl/certs/RapidSSL_CA_bundle.pem
ssl_ca_path /etc/perdition/
ssl_cert_file /etc/ssl/certs/20110822-star.bluebottle.com.crt
ssl_cert_accept_expired
ssl_cert_verify_depth 9
ssl_key_file /etc/ssl/certs/20110822-star.bluebottle.com.key
ssl_no_cn_verify
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681954: [ovs-dev] Bug#681954: openvswitch-brcompat - Init script switch and different package
On Thu, Jul 26, 2012 at 10:59:52AM +0200, Bastian Blank wrote: On Wed, Jul 18, 2012 at 06:47:24AM -0700, Ben Pfaff wrote: On Wed, Jul 18, 2012 at 09:55:56AM +0200, Bastian Blank wrote: Installing openvswitch-brcompat is not enough to actually enable it. There is an additional switch in /etc/defaults/openvswitch-switch to enable it. It's documented in the package description: Once this package is installed, adding BRCOMPAT=yes in /etc/default/openvswitch-switch enables bridge compatibility. Why do you consider it a bug? Because it takes two operations. It is already a different package. Why does it need another modification to work? Is the argument that an /etc/defaults file should always enable the base features of the package it corresponds to? -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-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-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682187: [ovs-dev] [PATCH] debian: Remove controller keys on openvswitch-controller package purge.
On Fri, Jul 20, 2012 at 09:24:01AM -0700, Ben Pfaff wrote: A Debian package is expected to remove all its configuration files (which includes all files in /etc) when it is purged, but the openvswitch-controller package wasn't doing that. This fixes the problem. Debian bug #682187. CC: 682...@bugs.debian.org Reported-by: Andreas Beckmann deb...@abeckmann.de Signed-off-by: Ben Pfaff b...@nicira.com Acked-by: Simon Horman ho...@verge.net.au --- debian/automake.mk |1 + debian/openvswitch-controller.postrm | 44 ++ 2 files changed, 45 insertions(+), 0 deletions(-) create mode 100755 debian/openvswitch-controller.postrm diff --git a/debian/automake.mk b/debian/automake.mk index ae82168..b6cb12e 100644 --- a/debian/automake.mk +++ b/debian/automake.mk @@ -22,6 +22,7 @@ EXTRA_DIST += \ debian/openvswitch-controller.install \ debian/openvswitch-controller.manpages \ debian/openvswitch-controller.postinst \ + debian/openvswitch-controller.postrm \ debian/openvswitch-datapath-module-_KVERS_.postinst.modules.in \ debian/openvswitch-datapath-dkms.postinst \ debian/openvswitch-datapath-dkms.prerm \ diff --git a/debian/openvswitch-controller.postrm b/debian/openvswitch-controller.postrm new file mode 100755 index 000..64b7909 --- /dev/null +++ b/debian/openvswitch-controller.postrm @@ -0,0 +1,44 @@ +#!/bin/sh +# postrm script for openvswitch-controller +# +# see: dh_installdeb(1) + +set -e + +# summary of how this script can be called: +#* postrm `remove' +#* postrm `purge' +#* old-postrm `upgrade' new-version +#* new-postrm `failed-upgrade' old-version +#* new-postrm `abort-install' +#* new-postrm `abort-install' old-version +#* new-postrm `abort-upgrade' old-version +#* disappearer's-postrm `disappear' overwriter +# overwriter-version +# for details, see http://www.debian.org/doc/debian-policy/ or +# the debian-policy package + + +case $1 in +purge) +cd /etc/openvswitch-controller +rm -f cacert.pem cert.pem privkey.pem req.pem +;; + +remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear) +;; + +*) +echo postrm 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 ___ dev mailing list d...@openvswitch.org http://openvswitch.org/mailman/listinfo/dev -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680086: perdition should depends on dpkg-dev (=1.16.1) package
On Tue, Jul 03, 2012 at 03:36:59PM +0200, Laurento Frittella wrote: Package: perdition Version: 1.19~rc5-1+b1 Severity: normal Tags: patch Dear Maintainer, considering that perdition package uses dpkg-buildflags --export=configure in its rules file and that option, accordingly with the dpkg changelog, has been added since the 1.16.1 version I think perdition should explicitly depends on dpkg-dev (=1.16.1) Thanks, I will fix this in the next upload. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609654: error: unable to get local issuer certificate
On Tue, Jan 11, 2011 at 10:47:22AM +0100, mmattern wrote: Package: perdition Version: 1.19~rc4-2 Severity: normal If using client certificates with IMAP4S I get this log: perdition.imaps[32227]: error: unable to get local issuer certificate perdition.imaps[32227]: __perdition_ssl_connection: error:0200100D:system library:fopen:Permission denied perdition.imaps[32227]: __perdition_ssl_connection: error:20074002:BIO routines:FILE_CTRL:system lib perdition.imaps[32227]: __perdition_ssl_connection: error:0B06F002:x509 certificate routines:X509_load_cert_file:system lib perdition.imaps[32227]: __perdition_ssl_connection: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned perdition.imaps[32227]: __perdition_ssl_connection: SSL_accept perdition.imaps[32227]: __perdition_ssl_connection: timeout or no shared ciphers? perdition.imaps[32227]: perdition_ssl_server_connection: perdition_ssl_connection perdition.imaps[32227]: main: perdition_ssl_server_connection SSL perdition.imaps[32227]: Fatal error establishing SSL connection to client I use Thunderbird 3.1.7 as client. It shows the message Errorcode: ssl_error_unknown_ca_alert. I tested running perdition as user root. Then it works fine. Hi, I suspect that the problem here is that the user perdition has been configured to request a client certificate but Thunderbird hasn't been configured with one. I suggest changing the configuration on either end accordingly. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633184: #633184: perdition: Getting rid of unneeded *.la / emptying dependency_libs
tag 633184 +pending A fix for this has been committed upstream and should be included in the next release. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664645: ldirectord: suspicious init script
On Tue, Mar 20, 2012 at 10:51:59AM +0100, Ferenc Wagner wrote: Simon Horman ho...@verge.net.au writes: On Mon, Mar 19, 2012 at 03:23:24PM +0100, Ferenc Wagner wrote: The /etc/init.d/ldirectord init script contains the lines: exec $DAEMON $CONFIG_FILE $1 RC=$? [...] Since the exec shell builtin does not return if $DAEMON is executable, the error checking and logging after it makes me suspicious: is that exec really intentional? For me it looks like it should be removed. I believe that the intention of the code is that the error handling is performed if and only if exec fails, e.g. because $DAEMON is not executable. The upstream version of the init script has the exec without the RC handling, which seems to indicate that the exec is intentional. Hi Simon, Then in my opinion the upstream exec is indeed intentional, but it should be removed in the Debian version, because it breaks the output of the log_daemon_msg/log_end_msg pair (by skipping the latter; this is a rather ugly can of worms, though, see the last comment of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=208010 for example). Point taken. Do you think that removing the exec is sufficient or does more work need to be done? -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664645: ldirectord: suspicious init script
On Mon, Mar 19, 2012 at 03:23:24PM +0100, Ferenc Wagner wrote: Package: ldirectord Version: 1:3.9.2-5 Severity: normal Hi, The /etc/init.d/ldirectord init script contains the lines: exec $DAEMON $CONFIG_FILE $1 RC=$? [...] Since the exec shell builtin does not return if $DAEMON is executable, the error checking and logging after it makes me suspicious: is that exec really intentional? For me it looks like it should be removed. Hi, I believe that the intention of the code is that the error handling is performed if and only if exec fails, e.g. because $DAEMON is not executable. The upstream version of the init script has the exec without the RC handling, which seems to indicate that the exec is intentional. -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627670: [Debian-ha-maintainers] Bug#627670: update drbd8 to 8.3.10 (or later if available)
On Wed, Mar 14, 2012 at 08:05:02PM +0100, Daniel Baumann wrote: any answer to this bug, almost a year ago? from looking at the package and the bts, it doesn't look like this package is maintained. are you still interested in it, or do you want me to take over? Hi Daniel, FWIW, I would be happy to see someone working on this package. -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660735: SEGFAULT in strcasestr when using sieve protocol
On Tue, Feb 21, 2012 at 12:47:42PM +0100, Matthias Hunstock wrote: Package: perdition Version: 1.19~rc4-4 Severity: important Tags: upstream patch Hi, I have tried to use perdition as a proxy for the sieve protocol. Unfortunately, whenever an arbitrary user is connecting and authenticating the corresponding child process is terminated by a SEGFAULT. I originally discovered this issue in 1.19~rc4-2 and thought it is fixed in 1.19~rc4-4, but it is NOT the problem with too long credentials. Thanks, I will make a fresh upload. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655412: Please enabled hardened build flags
tag 655412 +pending On Tue, Jan 10, 2012 at 11:16:11PM +0100, Moritz Muehlenhoff wrote: Package: perdition Version: 1.19~rc4-4 Severity: important Tags: patch Please enabled hardened build flags through dpkg-buildflags. Thanks, I will include this in the next upload. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609654: error: unable to get local issuer certificate
On Tue, Jan 11, 2011 at 10:47:22AM +0100, mmattern wrote: Package: perdition Version: 1.19~rc4-2 Severity: normal If using client certificates with IMAP4S I get this log: perdition.imaps[32227]: error: unable to get local issuer certificate perdition.imaps[32227]: __perdition_ssl_connection: error:0200100D:system library:fopen:Permission denied perdition.imaps[32227]: __perdition_ssl_connection: error:20074002:BIO routines:FILE_CTRL:system lib perdition.imaps[32227]: __perdition_ssl_connection: error:0B06F002:x509 certificate routines:X509_load_cert_file:system lib perdition.imaps[32227]: __perdition_ssl_connection: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned perdition.imaps[32227]: __perdition_ssl_connection: SSL_accept perdition.imaps[32227]: __perdition_ssl_connection: timeout or no shared ciphers? perdition.imaps[32227]: perdition_ssl_server_connection: perdition_ssl_connection perdition.imaps[32227]: main: perdition_ssl_server_connection SSL perdition.imaps[32227]: Fatal error establishing SSL connection to client I use Thunderbird 3.1.7 as client. It shows the message Errorcode: ssl_error_unknown_ca_alert. I tested running perdition as user root. Then it works fine. Hi, It looks like the non-root user that you were running perdition as does not have permission to access your certificate file. -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-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-dist-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-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653645: [PATCH] Debian: Depend on python (= 2.7) | python-argparse
Depend on python (= 2.7) | python-argparse instead of
python-argparse to avoid pulling in python2.6
See: http://bugs.debian.org/653645
Signed-off-by: Simon Horman ho...@verge.net.au
---
debian/changelog |3 +++
debian/control |6 --
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index e0acd8d..823a610 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -24,6 +24,9 @@ openvswitch (1.4.0-1) unstable; urgency=low
and connectivity issues. This tool currently is not included in RH or
Xen packages.
- RHEL packaging now supports integration with Red Hat network scripts.
+- Debian: Depend on python (= 2.7) | python-argparse instead of
+ python-argparse to avoid pulling in python2.6
+ (closes: #653645)
-- Open vSwitch team d...@openvswitch.org Mon, xx xxx 23:36:00 +
diff --git a/debian/control b/debian/control
index c350fac..5861447 100644
--- a/debian/control
+++ b/debian/control
@@ -33,7 +33,9 @@ Description: Open vSwitch datapath module source - DKMS
version
Package: openvswitch-common
Architecture: linux-any
-Depends: ${shlibs:Depends}, openssl, ${misc:Depends}, python, python-argparse
+Depends:
+ ${shlibs:Depends}, openssl, ${misc:Depends}, python,
+ python (= 2.7) | python-argparse
Suggests: ethtool
Description: Open vSwitch common components
openvswitch-common provides components required by both openvswitch-switch
@@ -141,7 +143,7 @@ Description: Open vSwitch graphical monitoring tool
Package: openvswitch-test
Architecture: all
-Depends: python-twisted-web, python-argparse
+Depends: python-twisted-web, python (= 2.7) | python-argparse
Description: Open vSwitch test package
This package contains utilities that are useful to diagnose
performance and connectivity issues in Open vSwitch setup.
--
1.7.6.3
--
To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642206: [ovs-dev] [PATCH] debian: Correct path to ovs-controller in init script.
Thanks, let me know if you think this warrants a fresh upload to Debian before the next (1.2?) release. On Tue, Sep 20, 2011 at 11:00:47AM -0700, Ben Pfaff wrote: Thanks, I pushed this to master and branch-1.2. On Tue, Sep 20, 2011 at 10:23:02AM -0700, Justin Pettit wrote: Looks good. --Justin On Sep 20, 2011, at 9:39 AM, Ben Pfaff wrote: Reported-by: George Shuklin ama...@desunote.ru Bug-report: http://bugs.debian.org/642206 --- AUTHORS|1 + debian/openvswitch-controller.init |2 +- 2 files changed, 2 insertions(+), 1 deletions(-) diff --git a/AUTHORS b/AUTHORS index da8210f..c7d56fd 100644 --- a/AUTHORS +++ b/AUTHORS @@ -62,6 +62,7 @@ Dave Walker davewal...@ubuntu.com Derek Cormier derek.corm...@lab.ntt.co.jp DK Moon dkm...@nicira.com Gaetano Catalli gaetano.cata...@gmail.com +George Shuklin ama...@desunote.ru Ghanem Bahribahri.gha...@gmail.com Giuseppe de Candia giuseppe.decan...@gmail.com Gordon Good gg...@nicira.com diff --git a/debian/openvswitch-controller.init b/debian/openvswitch-controller.init index 1638f14..a5403b8 100755 --- a/debian/openvswitch-controller.init +++ b/debian/openvswitch-controller.init @@ -31,7 +31,7 @@ PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin -DAEMON=/usr/sbin/ovs-controller # Introduce the server's location here +DAEMON=/usr/bin/ovs-controller # Introduce the server's location here NAME=ovs-controller # Introduce the short server's name here DESC=ovs-controller # Introduce a short description here LOGDIR=/var/log/openvswitch # Log directory to use -- 1.7.4.4 ___ 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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642206: [ovs-dev] [PATCH] debian: Correct path to ovs-controller in init script.
Understood. Delaying the next upload is fine by me. On Tue, Sep 20, 2011 at 03:58:41PM -0700, Ben Pfaff wrote: I'm in favor of releasing 1.2.2 really soon, so it's probably not needed. Thanks, Ben. On Wed, Sep 21, 2011 at 07:56:49AM +0900, Simon Horman wrote: Thanks, let me know if you think this warrants a fresh upload to Debian before the next (1.2?) release. On Tue, Sep 20, 2011 at 11:00:47AM -0700, Ben Pfaff wrote: Thanks, I pushed this to master and branch-1.2. On Tue, Sep 20, 2011 at 10:23:02AM -0700, Justin Pettit wrote: Looks good. --Justin On Sep 20, 2011, at 9:39 AM, Ben Pfaff wrote: Reported-by: George Shuklin ama...@desunote.ru Bug-report: http://bugs.debian.org/642206 --- AUTHORS|1 + debian/openvswitch-controller.init |2 +- 2 files changed, 2 insertions(+), 1 deletions(-) diff --git a/AUTHORS b/AUTHORS index da8210f..c7d56fd 100644 --- a/AUTHORS +++ b/AUTHORS @@ -62,6 +62,7 @@ Dave Walker davewal...@ubuntu.com Derek Cormier derek.corm...@lab.ntt.co.jp DK Moon dkm...@nicira.com Gaetano Catalli gaetano.cata...@gmail.com +George Shuklin ama...@desunote.ru Ghanem Bahribahri.gha...@gmail.com Giuseppe de Candia giuseppe.decan...@gmail.com Gordon Good gg...@nicira.com diff --git a/debian/openvswitch-controller.init b/debian/openvswitch-controller.init index 1638f14..a5403b8 100755 --- a/debian/openvswitch-controller.init +++ b/debian/openvswitch-controller.init @@ -31,7 +31,7 @@ PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin -DAEMON=/usr/sbin/ovs-controller # Introduce the server's location here +DAEMON=/usr/bin/ovs-controller # Introduce the server's location here NAME=ovs-controller # Introduce the short server's name here DESC=ovs-controller # Introduce a short description here LOGDIR=/var/log/openvswitch # Log directory to use -- 1.7.4.4 ___ 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-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530062: csync2: bashism in /bin/sh script
On Thu, Mar 24, 2011 at 07:15:35AM -0500, Jonathan Nieder wrote: tags 530062 + upstream quit Simon Horman wrote: I wasn't aware that using ksh as /bin/sh ws part of goal-dash. Am I mistaken? No, but more to the point, it is a long-term goal and a reasonable possibility for upstream packages to take into account. Are you in contact with upstream? If so, would you be willing to pass on this patch? Yes, sure, I'll see about getting it merged upstream. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612678: Fwd: Bug#612678: default timeout smaller than the advised one - results in WARNING message
Hi Pacemaker upstream people, could someone comment on this bug report. The bug report can be seen at http://bugs.debian.org/612678 CCing 612...@bugs.debian.org should append any responses to the but report. Thanks - Forwarded message from Michael Prokop m...@debian.org - Date: Wed, 09 Feb 2011 23:23:17 +0100 From: Michael Prokop m...@debian.org To: Debian Bug Tracking System sub...@bugs.debian.org Subject: Bug#612678: default timeout smaller than the advised one - results in WARNING message Resent-From: Michael Prokop m...@debian.org Package: pacemaker Version: 1.0.9.1+hg15626-1 Severity: minor When running something like: # crm configure primitive ssh-stonith stonith:ssh params hostlist=$HOSTS op monitor interval=60s [...] you'll notice: WARNING: ssh-stonith: default timeout 20s for start is smaller than the advised 60 WARNING: ssh-stonith: default timeout 20s for monitor_0 is smaller than the advised 60 If the advised timeout is 60 then either the default timeout should be =60, the advised timeout should be revised to 20s or it shouldn't warn the user about it, IMHO. regards, -mika- - End forwarded message - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608274: Please allow cluster-agents 1:1.0.3-4
Hi, there is a small bug in cluster-agents that it would be rather nice to fix for squeeze. The problem is that the mysql resource agent uses paths different from those on Debian. The fix is trivial. 1.0.3-4 also adds a build dependency on python to resolve a build problem - configure bombs out complaining that python isn't installed. I observed this using pbuilder. I am unsure why it hasn't cropped up before. The diff between the 1:1.0.3-3.1 and 1:1.0.3-4 follows. diff -Nru cluster-agents-1.0.3/debian/changelog cluster-agents-1.0.3/debian/changelog --- cluster-agents-1.0.3/debian/changelog 2010-10-19 19:35:00.0 +0900 +++ cluster-agents-1.0.3/debian/changelog 2011-02-04 07:46:43.0 +0900 @@ -1,3 +1,12 @@ +cluster-agents (1:1.0.3-4) unstable; urgency=low + + * Use correct paths on Debian/GNU Linux in MySQL resource agent +(Closes: #608274) + * Add build dependency on python +- Fixes build failure on both unstable and testing + + -- Simon Horman ho...@debian.org Fri, 04 Feb 2011 07:46:13 +0900 + cluster-agents (1:1.0.3-3.1) unstable; urgency=low * Non-maintainer upload. diff -Nru cluster-agents-1.0.3/debian/control cluster-agents-1.0.3/debian/control --- cluster-agents-1.0.3/debian/control 2010-10-17 02:13:29.0 +0900 +++ cluster-agents-1.0.3/debian/control 2011-02-04 07:46:07.0 +0900 @@ -3,7 +3,7 @@ Priority: optional Maintainer: Debian HA Maintainers debian-ha-maintain...@lists.alioth.debian.org Uploaders: Martin Loschwitz madk...@debian.org, Anibal Monsalve Salazar ani...@debian.org, Simon Horman ho...@debian.org, Frederik Schüler f...@debian.org -Build-Depends: libcluster-glue-dev, cluster-glue-dev, libnet1-dev, debhelper (= 7), docbook-xsl, automake, autoconf, libtool, pkg-config, libglib2.0-dev, xsltproc, docbook-xml +Build-Depends: libcluster-glue-dev, cluster-glue-dev, libnet1-dev, debhelper (= 7), docbook-xsl, automake, autoconf, libtool, pkg-config, libglib2.0-dev, xsltproc, docbook-xml, python Standards-Version: 3.8.4 Homepage: http://hg.linux-ha.org/agents/ XS-Python-Version: current diff -Nru cluster-agents-1.0.3/debian/patches/mysql-path.patch cluster-agents-1.0.3/debian/patches/mysql-path.patch --- cluster-agents-1.0.3/debian/patches/mysql-path.patch1970-01-01 09:00:00.0 +0900 +++ cluster-agents-1.0.3/debian/patches/mysql-path.patch2011-02-04 07:42:43.0 +0900 @@ -0,0 +1,22 @@ +--- x/heartbeat/mysql 2010-07-08 12:21:55.0 +0200 x/heartbeat/mysql 2010-12-29 16:23:12.0 +0100 +@@ -60,14 +60,14 @@ + OCF_RESKEY_enable_creation_default=0 + OCF_RESKEY_additional_parameters_default= + else +-OCF_RESKEY_binary_default=/usr/bin/safe_mysqld +-OCF_RESKEY_config_default=/etc/my.cnf ++OCF_RESKEY_binary_default=/usr/bin/mysqld_safe ++OCF_RESKEY_config_default=/etc/mysql/my.cnf + OCF_RESKEY_datadir_default=/var/lib/mysql + OCF_RESKEY_user_default=mysql + OCF_RESKEY_group_default=mysql +-OCF_RESKEY_log_default=/var/log/mysqld.log +-OCF_RESKEY_pid_default=/var/run/mysql/mysqld.pid +-OCF_RESKEY_socket_default=/var/lib/mysql/mysql.sock ++OCF_RESKEY_log_default=/var/log/mysql.log ++OCF_RESKEY_pid_default=/var/run/mysqld/mysqld.pid ++OCF_RESKEY_socket_default=/var/run/mysqld/mysqld.sock + OCF_RESKEY_test_user_default=root + OCF_RESKEY_test_table_default=mysql.user + OCF_RESKEY_test_passwd_default= diff -Nru cluster-agents-1.0.3/debian/patches/series cluster-agents-1.0.3/debian/patches/series --- cluster-agents-1.0.3/debian/patches/series 2010-10-19 19:36:12.0 +0900 +++ cluster-agents-1.0.3/debian/patches/series 2011-02-04 07:33:05.0 +0900 @@ -1,2 +1,3 @@ CVE-2010-3389--bug598549.patch spelling-fixes.patch +mysql-path.patch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608274: [Debian-ha-maintainers] Bug#608274: Bug#608274: Squeeze
On Fri, Jan 28, 2011 at 02:06:09PM +0100, Raoul Bhatia [IPAX] wrote: On 01/28/2011 01:54 PM, Laurent Léonard wrote: Any chance to get this issue solved in Squeeze ? Thank you, i would be willing to help with/test this. would you like to see mysql only or *all* ras? ;) mysql should be pretty trivial, but going through *all* agents would require some tim. I think it would be an worthwhile improvement to just fix MySQL. OF course, it would be more of an important to fix other agents too. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608275: [Debian-ha-maintainers] Bug#608275: libcrmcommon2-dev: missing dependency on cluster-glue-dev
Ooops, thanks for the fix.
I think that I will go with the versioned change as per
your patch below.
Regards
On Sun, Jan 16, 2011 at 04:47:22PM -0500, Andres Rodriguez wrote:
Simon,
The patch you have applied actually breaks the installation of
libcrmcommon2. The reason is because adding the dependency to
cluster-glue-dev ( = ${binary:Version}), will try to install a
cluster-glue-dev versioned with the same version of pacemaker
(${binary:Version}). To fix this, is either drop the versioning for such
dependency or apply the following (Just to note, in Ubuntu I have dropped
such change):
diff -Nru pacemaker-1.0.10/debian/control pacemaker-1.0.10/debian/control
--- pacemaker-1.0.10/debian/control 2011-01-03 22:55:35.0 -0500
+++ pacemaker-1.0.10/debian/control 2011-01-16 16:43:32.0 -0500
@@ -93,7 +94,7 @@
Section: libdevel
Depends:
${misc:Depends}, libcrmcommon2 (= ${binary:Version}),
- cluster-glue-dev (= ${binary:Version})
+ cluster-glue-dev (= 1.0.7-1)
Replaces: pacemaker-dev (= 1.0.9.1+hg15626-2)
Conflicts: pacemaker-dev (= 1.0.9.1+hg15626-2)
Description: Development file for pacemaker's common library
On Mon, Jan 3, 2011 at 11:00 PM, Simon Horman ho...@verge.net.au wrote:
On Wed, Dec 29, 2010 at 04:38:33PM +0100, Jeremy Laine wrote:
Package: libcrmcommon2-dev
Version: 1.0.10-1
Severity: normal
The following file, which is shipped in libcrmcommon2-dev:
/usr/include/pacemaker/crm/common/xml.h
.. includes the following, which is shipped in cluster-glue-dev:
/usr/include/heartbeat/ha_msg.h
So libcrmcommon2-dev should depend on cluster-glue-dev.
Hi,
thanks for reporting this problem.
I have applied the following patch which should
be included in the next upload.
# HG changeset patch
# User Simon Horman ho...@verge.net.au
# Date 1294113375 -32400
# Branch sid
# Node ID f6cf9f4597f30b60db31748fa1ab23649b0c544f
# Parent 5b152f75d6670f67634f2bbec8dc4c43a321ff58
Add dependency on cluster-glue-dev to libcrmcommon2-dev
diff -r 5b152f75d667 -r f6cf9f4597f3 debian/changelog
--- a/debian/changelog Mon Dec 20 15:32:20 2010 +0900
+++ b/debian/changelog Tue Jan 04 12:56:15 2011 +0900
@@ -1,3 +1,10 @@
+pacemaker (1.0.10-4) unstable; urgency=low
+
+ * Add dependency on cluster-glue-dev to libcrmcommon2-dev
+Closes: #608275
+
+ -- Simon Horman ho...@debian.org Tue, 04 Jan 2011 12:53:31 +0900
+
pacemaker (1.0.10-3) unstable; urgency=low
* Use correct names for libpe-rules2-dev and libpe-status2-dev
diff -r 5b152f75d667 -r f6cf9f4597f3 debian/control
--- a/debian/controlMon Dec 20 15:32:20 2010 +0900
+++ b/debian/controlTue Jan 04 12:56:15 2011 +0900
@@ -91,7 +91,9 @@
Package: libcrmcommon2-dev
Architecture: any
Section: libdevel
-Depends: ${misc:Depends}, libcrmcommon2 (= ${binary:Version})
+Depends:
+ ${misc:Depends}, libcrmcommon2 (= ${binary:Version}),
+ cluster-glue-dev (= ${binary:Version})
Replaces: pacemaker-dev (= 1.0.9.1+hg15626-2)
Conflicts: pacemaker-dev (= 1.0.9.1+hg15626-2)
Description: Development file for pacemaker's common library
___
Debian-ha-maintainers mailing list
debian-ha-maintain...@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/debian-ha-maintainers
--
Andres Rodriguez (RoAkSoAx)
Ubuntu MOTU Developer
Systems Engineer
--
To UNSUBSCRIBE, email to debian-bugs-dist-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#609480: libpe-rules2: upgrade failure
On Sun, Jan 09, 2011 at 09:17:30PM +0100, Lech Karol Pawłaszek wrote: Package: libpe-rules2 Severity: normal libpe-rules2 and libpe-status2 fails to install over libpe-rules-2 and libpe-status-2 Thanks for pointing that out. It looks like we need to add the appropriate conflicts and provides to the new packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608274: [Debian-ha-maintainers] Bug#608274: Issue isn't limited to the mysql agent
On Tue, Jan 04, 2011 at 09:58:02AM +0100, Florian Haas wrote: On 2011-01-04 05:06, Simon Horman wrote: On Mon, Jan 03, 2011 at 12:50:18PM +0100, Florian Haas wrote: The issue you are highlighting isn't specific to the ocf:heartbeat:mysql RA. There are several resource agents where the upstream default does not match the Debian default. This means we should either fix this for _all_ resource agents that ship in the cluster-agents package, or leave it to users to set the proper path in the resource configuration (which is perfectly possible, which is why I'm downgrading the severity to normal here). Thoughts? Horms, maybe? Thought: wow, what a mess! I think that the best thing to do would be to incorporate changes such as the one that Laurent posted as they are found. Probably as patches in debian/patches. Well, it's actually a mess with two sides, the mysql RA interestingly exposing both: * Some upstream defaults are just horribly outdated (such as the mysql binary defaulting to safe_mysqld, which IIRC MySQL 3.23 was the last version to ship with). And I believe those should be fixed upstream. That sounds fine to me. * Other upstream defaults merely don't match what the specific distro considers the default (such as, with mysql, config). Established precedent, from SLES, is that distro packaging substitutes the correct distro default. That also sounds fine to me. Perhaps you can handle the upstream side of things and I'll handle the Debian side of things by putting Laurent's patch into debian/patches? I can make a new upload too. We could talk also with upstream about making these per-distro configurations made at ./configure time. Ugh. That sounds like making things worse. No I think pretty much everyone upstream agrees that distro specific stuff should be covered in distro packaging. Ok, sure, I'll drop that portion of my thought on the floor right now. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608275: libcrmcommon2-dev: missing dependency on cluster-glue-dev
On Wed, Dec 29, 2010 at 04:38:33PM +0100, Jeremy Laine wrote:
Package: libcrmcommon2-dev
Version: 1.0.10-1
Severity: normal
The following file, which is shipped in libcrmcommon2-dev:
/usr/include/pacemaker/crm/common/xml.h
.. includes the following, which is shipped in cluster-glue-dev:
/usr/include/heartbeat/ha_msg.h
So libcrmcommon2-dev should depend on cluster-glue-dev.
Hi,
thanks for reporting this problem.
I have applied the following patch which should
be included in the next upload.
# HG changeset patch
# User Simon Horman ho...@verge.net.au
# Date 1294113375 -32400
# Branch sid
# Node ID f6cf9f4597f30b60db31748fa1ab23649b0c544f
# Parent 5b152f75d6670f67634f2bbec8dc4c43a321ff58
Add dependency on cluster-glue-dev to libcrmcommon2-dev
diff -r 5b152f75d667 -r f6cf9f4597f3 debian/changelog
--- a/debian/changelog Mon Dec 20 15:32:20 2010 +0900
+++ b/debian/changelog Tue Jan 04 12:56:15 2011 +0900
@@ -1,3 +1,10 @@
+pacemaker (1.0.10-4) unstable; urgency=low
+
+ * Add dependency on cluster-glue-dev to libcrmcommon2-dev
+Closes: #608275
+
+ -- Simon Horman ho...@debian.org Tue, 04 Jan 2011 12:53:31 +0900
+
pacemaker (1.0.10-3) unstable; urgency=low
* Use correct names for libpe-rules2-dev and libpe-status2-dev
diff -r 5b152f75d667 -r f6cf9f4597f3 debian/control
--- a/debian/controlMon Dec 20 15:32:20 2010 +0900
+++ b/debian/controlTue Jan 04 12:56:15 2011 +0900
@@ -91,7 +91,9 @@
Package: libcrmcommon2-dev
Architecture: any
Section: libdevel
-Depends: ${misc:Depends}, libcrmcommon2 (= ${binary:Version})
+Depends:
+ ${misc:Depends}, libcrmcommon2 (= ${binary:Version}),
+ cluster-glue-dev (= ${binary:Version})
Replaces: pacemaker-dev (= 1.0.9.1+hg15626-2)
Conflicts: pacemaker-dev (= 1.0.9.1+hg15626-2)
Description: Development file for pacemaker's common library
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608274: [Debian-ha-maintainers] Bug#608274: Issue isn't limited to the mysql agent
On Mon, Jan 03, 2011 at 12:50:18PM +0100, Florian Haas wrote: The issue you are highlighting isn't specific to the ocf:heartbeat:mysql RA. There are several resource agents where the upstream default does not match the Debian default. This means we should either fix this for _all_ resource agents that ship in the cluster-agents package, or leave it to users to set the proper path in the resource configuration (which is perfectly possible, which is why I'm downgrading the severity to normal here). Thoughts? Horms, maybe? Thought: wow, what a mess! I think that the best thing to do would be to incorporate changes such as the one that Laurent posted as they are found. Probably as patches in debian/patches. We could talk also with upstream about making these per-distro configurations made at ./configure time. That would help people who compile from upstream's source for one reason or another. -- To UNSUBSCRIBE, email to debian-bugs-dist-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 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-dist-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-dist-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-dist-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-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598549: cluster-agents: CVE-2010-3389: insecure library loading
On Tue, Oct 19, 2010 at 01:40:38PM +0300, Jari Aalto wrote:
Simon Horman ho...@verge.net.au writes:
Its unclear to me that this patch covers all cases.
e.g
$ DIR_EXECUTABLE=/abc
$ LD_LIBRARY_PATH=::
$ /bin/echo $DIR_EXECUTABLE${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
/abc:::
Am I missing something?
Julien Cristau from release team suggests that:
IRC #debian-qa
jcristau if the user set LD_LIBRARY_PATH=:: then they shot
themselves in the foot, and you're not
supposed to clean up after them.
So, we use revert back to simple approach:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598549#40
If that is fine by them, its fine by me too.
I'm now comfortable with this upload.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598549: [Debian-ha-maintainers] Bug#598549: cluster-agents: NMU diff for 1:1.0.3-3.1 (Intent to NMU)
On Sat, Oct 16, 2010 at 08:40:30PM +0300, jari.aa...@cante.net wrote:
Dear maintainer,
Here is the NMU diff according to DevRef 5.11.1[1][2] for bug: #598549.
See the debian/patches directory for the important fixes.
Let me know if it's okay to proceed with the NMU.
Thank you for maintaining the package,
Hi Jari,
Its unclear to me that this patch covers all cases.
e.g
$ DIR_EXECUTABLE=/abc
$ LD_LIBRARY_PATH=::
$ /bin/echo $DIR_EXECUTABLE${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
/abc:::
Am I missing something?
Jari Aalto
[1] http://www.debian.org/doc/developers-reference/pkgs.html#nmu
[2] http://dep.debian.net/deps/dep1.html
lsdiff(1) of changes:
cluster-agents-1.0.3/debian/changelog
cluster-agents-1.0.3/debian/patches/CVE-2010-3389--bug598549.patch
cluster-agents-1.0.3/debian/patches/series
diffstat for cluster-agents-1.0.3 cluster-agents-1.0.3
changelog |8
patches/CVE-2010-3389--bug598549.patch | 53
+
patches/series |1
3 files changed, 62 insertions(+)
diff -Nru cluster-agents-1.0.3/debian/changelog
cluster-agents-1.0.3/debian/changelog
--- cluster-agents-1.0.3/debian/changelog 2010-05-04 16:04:18.0
+0300
+++ cluster-agents-1.0.3/debian/changelog 2010-10-16 20:28:40.0
+0300
@@ -1,3 +1,11 @@
+cluster-agents (1:1.0.3-3.1) unstable; urgency=low
+
+ * debian/patches
+- (CVE-2010-3389--bug598549): New. Correct LD_LIBRARY_PATH handling.
+ (important, security; Closes: #598549).
+
+ -- Jari Aalto jari.aa...@cante.net Sat, 16 Oct 2010 20:28:40 +0300
+
cluster-agents (1:1.0.3-3) unstable; urgency=low
* Add build dependency on docbook-xml. (Closes: #579623)
diff -Nru cluster-agents-1.0.3/debian/patches/CVE-2010-3389--bug598549.patch
cluster-agents-1.0.3/debian/patches/CVE-2010-3389--bug598549.patch
--- cluster-agents-1.0.3/debian/patches/CVE-2010-3389--bug598549.patch
1970-01-01 02:00:00.0 +0200
+++ cluster-agents-1.0.3/debian/patches/CVE-2010-3389--bug598549.patch
2010-10-16 20:26:28.0 +0300
@@ -0,0 +1,53 @@
+From a4afa69fda9a375d7763e335c556231eaefe516d Mon Sep 17 00:00:00 2001
+From: Jari Aalto jari.aa...@cante.net
+Date: Sat, 16 Oct 2010 20:26:25 +0300
+Subject: [PATCH] CVE-2010-3389: insecure library loading
+Organization: Private
+Content-Type: text/plain; charset=utf-8
+Content-Transfer-Encoding: 8bit
+
+Signed-off-by: Jari Aalto jari.aa...@cante.net
+---
+ heartbeat/SAPDatabase |7 +--
+ heartbeat/SAPInstance |7 +--
+ 2 files changed, 10 insertions(+), 4 deletions(-)
+
+diff --git a/heartbeat/SAPDatabase b/heartbeat/SAPDatabase
+index 5e07046..e9574ea 100755
+--- a/heartbeat/SAPDatabase
b/heartbeat/SAPDatabase
+@@ -966,8 +966,11 @@ else
+ fi
+
+ # as root user we need the library path to the SAP kernel to be able to
call executables
+-if [ `echo $LD_LIBRARY_PATH | grep -c ^$DIR_EXECUTABLE\` -eq 0 ]; then
+- LD_LIBRARY_PATH=$DIR_EXECUTABLE:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH
++if [ $DIR_EXECUTABLE ]; then
++ if [ `echo $LD_LIBRARY_PATH | grep -c ^$DIR_EXECUTABLE\` -eq 0 ]; then
++ LD_LIBRARY_PATH=$DIR_EXECUTABLE${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
++ export LD_LIBRARY_PATH
++ fi
+ fi
+ sidadm=`echo $SID | tr [:upper:] [:lower:]`adm
+
+diff --git a/heartbeat/SAPInstance b/heartbeat/SAPInstance
+index 08f47f8..d7dea78 100755
+--- a/heartbeat/SAPInstance
b/heartbeat/SAPInstance
+@@ -296,8 +296,11 @@ sapinstance_init() {
+ fi
+
+ # as root user we need the library path to the SAP kernel to be able to
call sapcontrol
+- if [ `echo $LD_LIBRARY_PATH | grep -c ^$DIR_EXECUTABLE\` -eq 0 ]; then
+-LD_LIBRARY_PATH=$DIR_EXECUTABLE:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH
++ if [ $DIR_EXECUTABLE ]; then
++if [ `echo $LD_LIBRARY_PATH | grep -c ^$DIR_EXECUTABLE\` -eq 0 ];
then
++LD_LIBRARY_PATH=$DIR_EXECUTABLE${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
++export LD_LIBRARY_PATH
++fi
+ fi
+
+ sidadm=`echo $SID | tr [:upper:] [:lower:]`adm
+--
+1.7.1
+
diff -Nru cluster-agents-1.0.3/debian/patches/series
cluster-agents-1.0.3/debian/patches/series
--- cluster-agents-1.0.3/debian/patches/series2010-05-03
20:31:33.0 +0300
+++ cluster-agents-1.0.3/debian/patches/series2010-10-16
20:26:49.0 +0300
@@ -1 +1,2 @@
+CVE-2010-3389--bug598549.patch
spelling-fixes.patch
___
Debian-ha-maintainers mailing list
debian-ha-maintain...@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/debian-ha-maintainers
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530062: [Debian-ha-maintainers] Bug#530062: csync2: bashism in /bin/sh script
On Tue, Oct 05, 2010 at 06:41:13PM -0500, Jonathan Nieder wrote: severity 530062 minor tags 530062 + patch quit Raphael Geissert wrote: Usertags: goal-dash [...] possible bashism in ./usr/share/csync2/csync2_locheck.sh line 31 (should be read [-r] variable): if read -p Do you really want to logout? in This works fine in dash, but not in ksh derivatives (e.g., ksh93), which use -p for something else. So it is still not policy-compliant for an sh script. In general, read -p should be replaced with printf followed by read. More to the point, this is a sample .bash_logout file. Patch follows. I wasn't aware that using ksh as /bin/sh ws part of goal-dash. Am I mistaken? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598549: [Linux-ha-dev] Fwd: [Debian-ha-maintainers] Bug#598549: cluster-agents: CVE-2010-3389: insecure library loading
On Fri, Oct 01, 2010 at 07:55:02PM +1000, Aníbal Monsalve Salazar wrote:
On Thu, Sep 30, 2010 at 10:44:42AM +0900, Simon Horman wrote:
I received this through the Debian bug tracker.
Its not immediately clear to me what an appropriate fix would be.
The following diff shows how I fixed qtparted: CVE-2010-3375: insecure
library loading bug.
-export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH
+LD_LIBRARY_PATH=$( echo $LD_LIBRARY_PATH | sed s/\s//g )
+if [ -n $LD_LIBRARY_PATH ]
+then
+ export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH
+else
+ export LD_LIBRARY_PATH=$QTDIR/lib
+fi
export PATH=/sbin:/usr/sbin:/bin:/usr/bin:$PATH
Please note that if you also set PATH as above, you'll have to check
$PATH before adding it with :$PATH to PATH.
if $PATH is empty then :$PATH is equivalent to :. and you don't want
to add . to the path search.
Thanks Aníbal,
poking a little further it seems that the problem has been addressed
by the following recent upstream patch. Do you have any thoughts on it?
# HG changeset patch
# User Dejan Muhamedagic de...@hello-penguin.com
# Date 1284894558 -7200
# Node ID 2773e5850003fb90995a27811752224fde96c2b7
# Parent 9d67fff01b34e87b6a855f1ea9b8a8accb771680
Low: SAPDatabase,SAPInstance: improve LD_LIBRARY_PATH processing (bnc#640026)
diff -r 9d67fff01b34 -r 2773e5850003 heartbeat/SAPDatabase
--- a/heartbeat/SAPDatabase Thu Sep 16 09:48:04 2010 +0200
+++ b/heartbeat/SAPDatabase Sun Sep 19 13:09:18 2010 +0200
@@ -967,7 +967,8 @@
# as root user we need the library path to the SAP kernel to be able to call
executables
if [ `echo $LD_LIBRARY_PATH | grep -c ^$DIR_EXECUTABLE\` -eq 0 ]; then
- LD_LIBRARY_PATH=$DIR_EXECUTABLE:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH
+ LD_LIBRARY_PATH=$DIR_EXECUTABLE${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH
+ export LD_LIBRARY_PATH
fi
sidadm=`echo $SID | tr [:upper:] [:lower:]`adm
diff -r 9d67fff01b34 -r 2773e5850003 heartbeat/SAPInstance
--- a/heartbeat/SAPInstance Thu Sep 16 09:48:04 2010 +0200
+++ b/heartbeat/SAPInstance Sun Sep 19 13:09:18 2010 +0200
@@ -297,7 +297,8 @@
# as root user we need the library path to the SAP kernel to be able to call
sapcontrol
if [ `echo $LD_LIBRARY_PATH | grep -c ^$DIR_EXECUTABLE\` -eq 0 ]; then
-LD_LIBRARY_PATH=$DIR_EXECUTABLE:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH
+LD_LIBRARY_PATH=$DIR_EXECUTABLE${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH
+export LD_LIBRARY_PATH
fi
sidadm=`echo $SID | tr [:upper:] [:lower:]`adm
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598549: [Debian-ha-maintainers] Bug#598549: cluster-agents: CVE-2010-3389: insecure library loading
Thanks, I will discuss getting this resolved with the upstream developers. On Thu, Sep 30, 2010 at 12:36:56AM +, Raphael Geissert wrote: Package: cluster-agents Version: 1:1.0.3-3 Severity: important Tags: security User: t...@security.debian.org Usertags: ldpath Hello, During a review of the Debian archive, I've found your package to contain a script that can be abused by an attacker to execute arbitrary code. The vulnerability is introduced by an insecure change to LD_LIBRARY_PATH, an environment variable used by ld.so(8) to look for libraries on a directory other than the standard paths. Vulnerable code follows: /usr/lib/ocf/resource.d/heartbeat/SAPDatabase line 969: if [ `echo $LD_LIBRARY_PATH | grep -c ^$DIR_EXECUTABLE\` -eq 0 ]; then /usr/lib/ocf/resource.d/heartbeat/SAPDatabase line 970: LD_LIBRARY_PATH=$DIR_EXECUTABLE:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH /usr/lib/ocf/resource.d/heartbeat/SAPInstance line 299: if [ `echo $LD_LIBRARY_PATH | grep -c ^$DIR_EXECUTABLE\` -eq 0 ]; then /usr/lib/ocf/resource.d/heartbeat/SAPInstance line 300: LD_LIBRARY_PATH=$DIR_EXECUTABLE:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH When there's an empty item on the colon-separated list of LD_LIBRARY_PATH, ld.so treats it as '.' (i.e. CWD/$PWD.) If the given script is executed from a directory where a potential, local, attacker can write files to, there's a chance to exploit this bug. This vulnerability has been assigned the CVE id CVE-2010-3389. Please make sure you mention it when forwarding this report to upstream and when fixing this bug (everywhere: upstream and here at Debian.) [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3389 [1] http://security-tracker.debian.org/tracker/CVE-2010-3389 Sincerely, Raphael Geissert ___ Debian-ha-maintainers mailing list debian-ha-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-ha-maintainers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598549: Fwd: [Debian-ha-maintainers] Bug#598549: cluster-agents: CVE-2010-3389: insecure library loading
Hi linux-ha-dev, I received this through the Debian bug tracker. Its not immediately clear to me what an appropriate fix would be. - Forwarded message from Raphael Geissert geiss...@debian.org - Date: Thu, 30 Sep 2010 00:36:56 + From: Raphael Geissert geiss...@debian.org To: sub...@bugs.debian.org Subject: [Debian-ha-maintainers] Bug#598549: cluster-agents: CVE-2010-3389: insecure library loading Resent-From: Raphael Geissert geiss...@debian.org Package: cluster-agents Version: 1:1.0.3-3 Severity: important Tags: security User: t...@security.debian.org Usertags: ldpath Hello, During a review of the Debian archive, I've found your package to contain a script that can be abused by an attacker to execute arbitrary code. The vulnerability is introduced by an insecure change to LD_LIBRARY_PATH, an environment variable used by ld.so(8) to look for libraries on a directory other than the standard paths. Vulnerable code follows: /usr/lib/ocf/resource.d/heartbeat/SAPDatabase line 969: if [ `echo $LD_LIBRARY_PATH | grep -c ^$DIR_EXECUTABLE\` -eq 0 ]; then /usr/lib/ocf/resource.d/heartbeat/SAPDatabase line 970: LD_LIBRARY_PATH=$DIR_EXECUTABLE:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH /usr/lib/ocf/resource.d/heartbeat/SAPInstance line 299: if [ `echo $LD_LIBRARY_PATH | grep -c ^$DIR_EXECUTABLE\` -eq 0 ]; then /usr/lib/ocf/resource.d/heartbeat/SAPInstance line 300: LD_LIBRARY_PATH=$DIR_EXECUTABLE:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH When there's an empty item on the colon-separated list of LD_LIBRARY_PATH, ld.so treats it as '.' (i.e. CWD/$PWD.) If the given script is executed from a directory where a potential, local, attacker can write files to, there's a chance to exploit this bug. This vulnerability has been assigned the CVE id CVE-2010-3389. Please make sure you mention it when forwarding this report to upstream and when fixing this bug (everywhere: upstream and here at Debian.) [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3389 [1] http://security-tracker.debian.org/tracker/CVE-2010-3389 Sincerely, Raphael Geissert ___ Debian-ha-maintainers mailing list debian-ha-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/debian-ha-maintainers - End forwarded message - -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598220: unblock: perdition/1.19~rc4-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package perdition/1.19~rc4-2 which contains the following change only. . * Clean up use of 4/8 byte types on architectures such as amd64 where ssize_t and long are 8 bytes white but int is only 4 bytes wide. - Fix possible premature connection closure. - Fix possible stack corruption in odbc module. - Critical portions of upstream patch http://hg.vergenet.net/perdition/perdition/rev/57268f4aaa94 - (closes: 59791) I intend to make a simmilar (though longer as other changes are needed) update for lenny. unblock perdition/1.19~rc4-2 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.35-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=ja_JP.utf8, LC_CTYPE=ja_JP.utf8 (charmap=UTF-8) (ignored: LC_ALL set to ja_JP.utf8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597914: [SRM] Stable update for perdition (1.17.1-2+lenny2)
Hi,
I would like the upload of 1.17.1-2+lenny2 considered.
My proposed upload resolves the following problems.
* mysql: Don't store MYSQL * return values in a long
- This seems problematic on architectures such as amd64 where
pointers are 8 bytes wide but long is only 4 bytes wide.
- As per upstream patch
http://hg.vergenet.net/perdition/perdition/rev/db00825e370f
* Resolve 4/8 byte problems raised in bug #595432)
- odbc: pass a SQLLEN instead of an SQLINTEGER to SQLBindCol()
+ This seems problematic on architectures such as amd64 where
size_t (SQLLEN) is 8 bytes wide but int (SQLINTEGER) is only
4 bytes wide.
+ As per upstream patch
http://hg.vergenet.net/perdition/perdition/rev/57268f4aaa94
- core: the return value of callbacks to vanessa_socket_pipe_func()
should be a ssize_t not an int.
+ This seems problematic on architectures such as amd64 where
ssize_t is 8 bytes wide but int is only 4 bytes wide.
+ As per upstream patch
http://hg.vergenet.net/perdition/perdition/rev/57268f4aaa94
- (closes: #595432)
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,27 @@
+perdition (1.17.1-2+lenny2) stable; urgency=low
+
+ * mysql: Don't store MYSQL * return values in a long
+- This seems problematic on architectures such as amd64 where
+ pointers are 8 bytes wide but long is only 4 bytes wide.
+- As per upstream patch
+ http://hg.vergenet.net/perdition/perdition/rev/db00825e370f
+ * Resolve 4/8 byte problems raised in bug #595432)
+- odbc: pass a SQLLEN instead of an SQLINTEGER to SQLBindCol()
+ + This seems problematic on architectures such as amd64 where
+size_t (SQLLEN) is 8 bytes wide but int (SQLINTEGER) is only
+4 bytes wide.
+ + As per upstream patch
+http://hg.vergenet.net/perdition/perdition/rev/57268f4aaa94
+- core: the return value of callbacks to vanessa_socket_pipe_func()
+ should be a ssize_t not an int.
+ + This seems problematic on architectures such as amd64 where
+ssize_t is 8 bytes wide but int is only 4 bytes wide.
+ + As per upstream patch
+http://hg.vergenet.net/perdition/perdition/rev/57268f4aaa94
+- (closes: #595432)
+
+ -- Simon Horman ho...@debian.org Tue, 28 Sep 2010 00:35:13 +0900
+
perdition (1.17.1-2+lenny1) stable; urgency=low
* Don't call make from perdition prerm script
only in patch2:
unchanged:
--- perdition-1.17.1.orig/perdition/io.c
+++ perdition-1.17.1/perdition/io.c
@@ -517,7 +517,9 @@
*
**/
-static int __io_pipe_read(int fd, void *buf, size_t count, void *data){
+static ssize_t
+__io_pipe_read(int fd, void *buf, size_t count, void *data)
+{
io_t *io;
io_select_t *s;
ssize_t bytes;
@@ -550,7 +552,9 @@
}
-static int __io_pipe_write(int fd, const void *buf, size_t count, void *data){
+static ssize_t
+__io_pipe_write(int fd, const void *buf, size_t count, void *data)
+{
io_t *io;
io_select_t *s;
only in patch2:
unchanged:
--- perdition-1.17.1.orig/perdition/db/mysql/perditiondb_mysql.c
+++ perdition-1.17.1/perdition/db/mysql/perditiondb_mysql.c
@@ -206,21 +206,18 @@
size_t *len_return
){
MYSQL db;
- long rc;
MYSQL_RES *res;
MYSQL_ROW row;
char sqlstr[PERDITIONDB_MYSQL_QUERY_LENGTH];
size_t servername_len;
- rc = mysql_init(db);
- if(!rc){
+ if (!mysql_init(db)) {
perditiondb_mysql_log(mysql_init, db);
vanessa_dynamic_array_destroy(a);
return(-1);
}
- rc = mysql_real_connect(db,dbhost,dbuser,dbpwd,dbname,dbport,NULL,0);
- if(!rc){
+ if (!mysql_real_connect(db,dbhost,dbuser,dbpwd,dbname,dbport,NULL,0)) {
perditiondb_mysql_log(mysql_connect, db);
mysql_close(db);
return(-1);
@@ -256,8 +253,7 @@
}
}
- rc = mysql_query(db, sqlstr);
- if(rc){
+ if (mysql_query(db, sqlstr)) {
perditiondb_mysql_log(mysql_query, db);
mysql_close(db);
return(-1);
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597914: [SRM] Stable update for perdition (1.17.1-2+lenny2)
On Tue, Sep 28, 2010 at 12:42:08AM +0900, Simon Horman wrote:
Hi,
I would like the upload of 1.17.1-2+lenny2 considered.
My proposed upload resolves the following problems.
* mysql: Don't store MYSQL * return values in a long
- This seems problematic on architectures such as amd64 where
pointers are 8 bytes wide but long is only 4 bytes wide.
- As per upstream patch
http://hg.vergenet.net/perdition/perdition/rev/db00825e370f
* Resolve 4/8 byte problems raised in bug #595432)
- odbc: pass a SQLLEN instead of an SQLINTEGER to SQLBindCol()
+ This seems problematic on architectures such as amd64 where
size_t (SQLLEN) is 8 bytes wide but int (SQLINTEGER) is only
4 bytes wide.
+ As per upstream patch
http://hg.vergenet.net/perdition/perdition/rev/57268f4aaa94
- core: the return value of callbacks to vanessa_socket_pipe_func()
should be a ssize_t not an int.
+ This seems problematic on architectures such as amd64 where
ssize_t is 8 bytes wide but int is only 4 bytes wide.
+ As per upstream patch
http://hg.vergenet.net/perdition/perdition/rev/57268f4aaa94
- (closes: #595432)
Sorry, this should read
- (closes: #597914)
I will fix my proposed package accordingly.
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,27 @@
+perdition (1.17.1-2+lenny2) stable; urgency=low
+
+ * mysql: Don't store MYSQL * return values in a long
+- This seems problematic on architectures such as amd64 where
+ pointers are 8 bytes wide but long is only 4 bytes wide.
+- As per upstream patch
+ http://hg.vergenet.net/perdition/perdition/rev/db00825e370f
+ * Resolve 4/8 byte problems raised in bug #595432)
+- odbc: pass a SQLLEN instead of an SQLINTEGER to SQLBindCol()
+ + This seems problematic on architectures such as amd64 where
+size_t (SQLLEN) is 8 bytes wide but int (SQLINTEGER) is only
+4 bytes wide.
+ + As per upstream patch
+http://hg.vergenet.net/perdition/perdition/rev/57268f4aaa94
+- core: the return value of callbacks to vanessa_socket_pipe_func()
+ should be a ssize_t not an int.
+ + This seems problematic on architectures such as amd64 where
+ssize_t is 8 bytes wide but int is only 4 bytes wide.
+ + As per upstream patch
+http://hg.vergenet.net/perdition/perdition/rev/57268f4aaa94
+- (closes: #595432)
+
+ -- Simon Horman ho...@debian.org Tue, 28 Sep 2010 00:35:13 +0900
+
perdition (1.17.1-2+lenny1) stable; urgency=low
* Don't call make from perdition prerm script
only in patch2:
unchanged:
--- perdition-1.17.1.orig/perdition/io.c
+++ perdition-1.17.1/perdition/io.c
@@ -517,7 +517,9 @@
*
**/
-static int __io_pipe_read(int fd, void *buf, size_t count, void *data){
+static ssize_t
+__io_pipe_read(int fd, void *buf, size_t count, void *data)
+{
io_t *io;
io_select_t *s;
ssize_t bytes;
@@ -550,7 +552,9 @@
}
-static int __io_pipe_write(int fd, const void *buf, size_t count, void
*data){
+static ssize_t
+__io_pipe_write(int fd, const void *buf, size_t count, void *data)
+{
io_t *io;
io_select_t *s;
only in patch2:
unchanged:
--- perdition-1.17.1.orig/perdition/db/mysql/perditiondb_mysql.c
+++ perdition-1.17.1/perdition/db/mysql/perditiondb_mysql.c
@@ -206,21 +206,18 @@
size_t *len_return
){
MYSQL db;
- long rc;
MYSQL_RES *res;
MYSQL_ROW row;
char sqlstr[PERDITIONDB_MYSQL_QUERY_LENGTH];
size_t servername_len;
- rc = mysql_init(db);
- if(!rc){
+ if (!mysql_init(db)) {
perditiondb_mysql_log(mysql_init, db);
vanessa_dynamic_array_destroy(a);
return(-1);
}
- rc = mysql_real_connect(db,dbhost,dbuser,dbpwd,dbname,dbport,NULL,0);
- if(!rc){
+ if (!mysql_real_connect(db,dbhost,dbuser,dbpwd,dbname,dbport,NULL,0)) {
perditiondb_mysql_log(mysql_connect, db);
mysql_close(db);
return(-1);
@@ -256,8 +253,7 @@
}
}
- rc = mysql_query(db, sqlstr);
- if(rc){
+ if (mysql_query(db, sqlstr)) {
perditiondb_mysql_log(mysql_query, db);
mysql_close(db);
return(-1);
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597914: [SRM] Stable update for perdition (1.17.1-2+lenny2)
On Mon, Sep 27, 2010 at 06:35:57PM +0200, Julien Cristau wrote: On Tue, Sep 28, 2010 at 00:42:08 +0900, Simon Horman wrote: Hi, I would like the upload of 1.17.1-2+lenny2 considered. My proposed upload resolves the following problems. * mysql: Don't store MYSQL * return values in a long - This seems problematic on architectures such as amd64 where pointers are 8 bytes wide but long is only 4 bytes wide. - As per upstream patch http://hg.vergenet.net/perdition/perdition/rev/db00825e370f long and void * are the same size on all Debian architectures (amd64 has 8-byte longs), so the proposed change is effectively a nop. My bad, I'll drop that portion. * Resolve 4/8 byte problems raised in bug #595432) - odbc: pass a SQLLEN instead of an SQLINTEGER to SQLBindCol() + This seems problematic on architectures such as amd64 where size_t (SQLLEN) is 8 bytes wide but int (SQLINTEGER) is only 4 bytes wide. + As per upstream patch http://hg.vergenet.net/perdition/perdition/rev/57268f4aaa94 That doesn't seem to be included in your proposed diff. Sorry, I'll send a revised version that includes that portion. - core: the return value of callbacks to vanessa_socket_pipe_func() should be a ssize_t not an int. + This seems problematic on architectures such as amd64 where ssize_t is 8 bytes wide but int is only 4 bytes wide. + As per upstream patch http://hg.vergenet.net/perdition/perdition/rev/57268f4aaa94 That one looks reasonable. Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597914: [SRM] Stable update for perdition (1.17.1-2+lenny2)
Hi Julien,
I have addressed your two concerns and the
change now looks the same as the one between 1.19~rc4-1 and 1.19~rc4-2.
The new changelog is:
* Resolve 4/8 byte problems raised in bug #597914)
- odbc: pass a SQLLEN instead of an SQLINTEGER to SQLBindCol()
+ This seems problematic on architectures such as amd64 where
size_t (SQLLEN) is 8 bytes wide but int (SQLINTEGER) is only
4 bytes wide.
+ As per upstream patch
http://hg.vergenet.net/perdition/perdition/rev/57268f4aaa94
- core: the return value of callbacks to vanessa_socket_pipe_func()
should be a ssize_t not an int.
+ This seems problematic on architectures such as amd64 where
ssize_t is 8 bytes wide but int is only 4 bytes wide.
+ As per upstream patch
http://hg.vergenet.net/perdition/perdition/rev/57268f4aaa94
- (closes: #597914)
And the new diff is:
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,22 @@
+perdition (1.17.1-2+lenny2) stable; urgency=low
+
+ * Resolve 4/8 byte problems raised in bug #597914)
+- odbc: pass a SQLLEN instead of an SQLINTEGER to SQLBindCol()
+ + This seems problematic on architectures such as amd64 where
+size_t (SQLLEN) is 8 bytes wide but int (SQLINTEGER) is only
+4 bytes wide.
+ + As per upstream patch
+http://hg.vergenet.net/perdition/perdition/rev/57268f4aaa94
+- core: the return value of callbacks to vanessa_socket_pipe_func()
+ should be a ssize_t not an int.
+ + This seems problematic on architectures such as amd64 where
+ssize_t is 8 bytes wide but int is only 4 bytes wide.
+ + As per upstream patch
+http://hg.vergenet.net/perdition/perdition/rev/57268f4aaa94
+- (closes: #597914)
+
+ -- Simon Horman ho...@debian.org Tue, 28 Sep 2010 09:44:37 +0900
+
perdition (1.17.1-2+lenny1) stable; urgency=low
* Don't call make from perdition prerm script
only in patch2:
unchanged:
--- perdition-1.17.1.orig/perdition/io.c
+++ perdition-1.17.1/perdition/io.c
@@ -517,7 +517,9 @@
*
**/
-static int __io_pipe_read(int fd, void *buf, size_t count, void *data){
+static ssize_t
+__io_pipe_read(int fd, void *buf, size_t count, void *data)
+{
io_t *io;
io_select_t *s;
ssize_t bytes;
@@ -550,7 +552,9 @@
}
-static int __io_pipe_write(int fd, const void *buf, size_t count, void *data){
+static ssize_t
+__io_pipe_write(int fd, const void *buf, size_t count, void *data)
+{
io_t *io;
io_select_t *s;
only in patch2:
unchanged:
--- perdition-1.17.1.orig/perdition/db/odbc/perditiondb_odbc.c
+++ perdition-1.17.1/perdition/db/odbc/perditiondb_odbc.c
@@ -214,7 +214,7 @@
char **str_return, size_t * len_return)
{
SQLINTEGER rc;
- SQLINTEGER rc2;
+ SQLLEN rc2;
int status = -1;
SQLHENV env;
SQLHDBC hdbc;
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597914: perdition: type mismatch in call to vanessa_socket_pipe_func
On Sat, Sep 25, 2010 at 11:10:53PM +0200, Sergio Gelato wrote:
* Simon Horman [2010-09-25 21:34:02 +0900]:
On Fri, Sep 24, 2010 at 10:36:09AM +0200, Sergio Gelato wrote:
The main problem is that perdition/io.c:io_pipe() and its caller
perdition/perdition.c:perdition_log_close() use int counters
while the corresponding arguments in vanessa_socket_pipe_func()
are declared size_t. I'd worry about stack corruption on platforms
where sizeof(size_t) sizeof(int).
Suggested fix: declare those counters size_t, and (for cosmetic purposes)
cast them to unsigned long before formatting them with %lu instead of %d.
Thanks, I'll fix that.
Do you think it warrants an update to the testing (= already frozen squeeze)
package?
I do: amd64 has sizeof(size_t)==8 and sizeof(int)==4.
Hi,
could you take a look at the following patch and see what you think?
I have isolated three integer/size_t with problems.
1) perdition_log_close() takes integer arguments but the counters are
actually size_t.
I think that the resulting bug is cosmetic.
2) __io_pipe_read() and __io_pipe_write() return an int but
the counter in question is a ssize_t.
I actually don't think this can manifest in a problem as the maximum
return value is limited by the count argument, which is 1024
(=BUFFER_SIZE). If count was greater than 2^31 then a problem could
occur whereby a large read was mis-read as an error and the connection
would be prematurely closed.
3) perditiondb_odbc.c:dbserver_get() passes the address of
an SQLINTEGER instead of the address of a SQLLEN to the
odbc library call SQLBindCol() twice.
This seems like it could cause a stack corruption on
systems such as amd64 where SQLINTEGER (= typdef int) is 4 bytes wide
but SQLLEN (= typdef long) is 8 bytes wide.
Index: perdition/perdition/perdition.c
===
--- perdition.orig/perdition/perdition.c2010-09-26 15:42:17.0
+0900
+++ perdition/perdition/perdition.c 2010-09-26 15:42:30.0 +0900
@@ -309,14 +309,14 @@ static void perdition_log_close_early(co
}
static void perdition_log_close(const char *from_to_host_str,
- struct auth *auth, int received, int sent)
+ struct auth *auth, size_t received, size_t sent)
{
struct quoted_str authorisation_id = quote_str(auth-authorisation_id);
VANESSA_LOGGER_ERR_UNSAFE(Closing session:%s
authorisation_id=%s%s%s
authentication_id=\%s\
- received=%d sent=%d,
+ received=%zu sent=%zu,
from_to_host_str,
authorisation_id.quote,
authorisation_id.str,
Index: perdition/perdition/io.c
===
--- perdition.orig/perdition/io.c 2010-09-26 15:42:17.0 +0900
+++ perdition/perdition/io.c2010-09-26 15:55:41.0 +0900
@@ -655,7 +655,7 @@ err:
* 0 otherwise (one of io_a or io_b closes gracefully)
**/
-static int __io_pipe_read(int fd, void *buf, size_t count, void *data){
+static ssize_t __io_pipe_read(int fd, void *buf, size_t count, void *data){
io_t *io;
io_select_t *s;
ssize_t bytes;
@@ -693,7 +693,9 @@ err:
}
-static int __io_pipe_write(int fd, const void *buf, size_t count, void *data){
+static ssize_t
+__io_pipe_write(int fd, const void *buf, size_t count, void *data)
+{
io_t *io;
io_select_t *s;
Index: perdition/perdition/db/odbc/perditiondb_odbc.c
===
--- perdition.orig/perdition/db/odbc/perditiondb_odbc.c 2010-09-26
15:42:17.0 +0900
+++ perdition/perdition/db/odbc/perditiondb_odbc.c 2010-09-26
15:42:30.0 +0900
@@ -214,7 +214,7 @@ int dbserver_get(const char *key_str, co
char **str_return, size_t * len_return)
{
SQLINTEGER rc;
- SQLINTEGER rc2;
+ SQLLEN rc2;
int status = -1;
SQLHENV env;
SQLHDBC hdbc;
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#597914: perdition: type mismatch in call to vanessa_socket_pipe_func
On Sun, Sep 26, 2010 at 01:20:14PM +0200, Sergio Gelato wrote:
* Simon Horman [2010-09-26 16:58:05 +0900]:
On Sat, Sep 25, 2010 at 11:10:53PM +0200, Sergio Gelato wrote:
* Simon Horman [2010-09-25 21:34:02 +0900]:
On Fri, Sep 24, 2010 at 10:36:09AM +0200, Sergio Gelato wrote:
The main problem is that perdition/io.c:io_pipe() and its caller
perdition/perdition.c:perdition_log_close() use int counters
while the corresponding arguments in vanessa_socket_pipe_func()
are declared size_t. I'd worry about stack corruption on platforms
where sizeof(size_t) sizeof(int).
Suggested fix: declare those counters size_t, and (for cosmetic
purposes)
cast them to unsigned long before formatting them with %lu instead of
%d.
Thanks, I'll fix that.
Do you think it warrants an update to the testing (= already frozen
squeeze)
package?
I do: amd64 has sizeof(size_t)==8 and sizeof(int)==4.
Hi,
could you take a look at the following patch and see what you think?
I have isolated three integer/size_t with problems.
1) perdition_log_close() takes integer arguments but the counters are
actually size_t.
I think that the resulting bug is cosmetic.
I stand corrected. On looking more carefully at the various versions of
perdition I'm interested in, I now see that changeset 695 actually did
fix the problem I was most concerned with. (You didn't update the comments,
but that's also cosmetic.) Then I see no need to push this fix into
squeeze. (lenny, on the other hand, might benefit from that changeset 695.)
2) __io_pipe_read() and __io_pipe_write() return an int but
the counter in question is a ssize_t.
I actually don't think this can manifest in a problem as the maximum
return value is limited by the count argument, which is 1024
(=BUFFER_SIZE). If count was greater than 2^31 then a problem could
occur whereby a large read was mis-read as an error and the connection
would be prematurely closed.
I wouldn't be so sure. On platforms where int is shorter than ssize_t,
vanessa_socket_pipe_read_write_func() will use data that may not have been
initialised properly. Even if it has been zeroed, depending on endianness
the effect could be equivalent to a shift, or the result may not be
sign-extended correctly. amd64 seems to fall into this last category:
storing (-1) into %eax zeroes the upper half of %rax, which should
defeat the error handling in your code.
*This* fix would therefore be welcome for squeeze according to my criteria.
I'm not entirely convinced, but I do agree that the current situation
is precarious and fixing it in squeeze seems worthwhile.
3) perditiondb_odbc.c:dbserver_get() passes the address of
an SQLINTEGER instead of the address of a SQLLEN to the
odbc library call SQLBindCol() twice.
This seems like it could cause a stack corruption on
systems such as amd64 where SQLINTEGER (= typdef int) is 4 bytes wide
but SQLLEN (= typdef long) is 8 bytes wide.
I agree with you here (except that I, and my compiler, count three instances
of the problem, not two; but that doesn't affect the patch). Also a candidate
for squeeze, I would think.
Ok, perhaps I counted wrong.
In any case, can I confirm that we agree that the io.c and perditiondb_odbc.c
portions of the change below should go into squeeze?
And for Lenny, I'll look into adding 695 + the io.c and perditiondb_odbc.c
portions of the change below. Does that sounds good to you?
Index: perdition/perdition/perdition.c
===
--- perdition.orig/perdition/perdition.c2010-09-26 15:42:17.0
+0900
+++ perdition/perdition/perdition.c 2010-09-26 15:42:30.0 +0900
@@ -309,14 +309,14 @@ static void perdition_log_close_early(co
}
static void perdition_log_close(const char *from_to_host_str,
- struct auth *auth, int received, int sent)
+ struct auth *auth, size_t received, size_t sent)
{
struct quoted_str authorisation_id = quote_str(auth-authorisation_id);
VANESSA_LOGGER_ERR_UNSAFE(Closing session:%s
authorisation_id=%s%s%s
authentication_id=\%s\
- received=%d sent=%d,
+ received=%zu sent=%zu,
from_to_host_str,
authorisation_id.quote,
authorisation_id.str,
Index: perdition/perdition/io.c
===
--- perdition.orig/perdition/io.c 2010-09-26 15:42:17.0 +0900
+++ perdition/perdition/io.c2010-09-26 15:55:41.0 +0900
@@ -655,7 +655,7 @@ err:
* 0 otherwise (one of io_a or io_b
Bug#597914: perdition: type mismatch in call to vanessa_socket_pipe_func
On Sun, Sep 26, 2010 at 10:37:57PM +0900, Simon Horman wrote:
On Sun, Sep 26, 2010 at 01:20:14PM +0200, Sergio Gelato wrote:
* Simon Horman [2010-09-26 16:58:05 +0900]:
On Sat, Sep 25, 2010 at 11:10:53PM +0200, Sergio Gelato wrote:
* Simon Horman [2010-09-25 21:34:02 +0900]:
On Fri, Sep 24, 2010 at 10:36:09AM +0200, Sergio Gelato wrote:
The main problem is that perdition/io.c:io_pipe() and its caller
perdition/perdition.c:perdition_log_close() use int counters
while the corresponding arguments in vanessa_socket_pipe_func()
are declared size_t. I'd worry about stack corruption on platforms
where sizeof(size_t) sizeof(int).
Suggested fix: declare those counters size_t, and (for cosmetic
purposes)
cast them to unsigned long before formatting them with %lu instead
of %d.
Thanks, I'll fix that.
Do you think it warrants an update to the testing (= already frozen
squeeze)
package?
I do: amd64 has sizeof(size_t)==8 and sizeof(int)==4.
Hi,
could you take a look at the following patch and see what you think?
I have isolated three integer/size_t with problems.
1) perdition_log_close() takes integer arguments but the counters are
actually size_t.
I think that the resulting bug is cosmetic.
I stand corrected. On looking more carefully at the various versions of
perdition I'm interested in, I now see that changeset 695 actually did
fix the problem I was most concerned with. (You didn't update the comments,
but that's also cosmetic.) Then I see no need to push this fix into
squeeze. (lenny, on the other hand, might benefit from that changeset 695.)
2) __io_pipe_read() and __io_pipe_write() return an int but
the counter in question is a ssize_t.
I actually don't think this can manifest in a problem as the maximum
return value is limited by the count argument, which is 1024
(=BUFFER_SIZE). If count was greater than 2^31 then a problem could
occur whereby a large read was mis-read as an error and the connection
would be prematurely closed.
I wouldn't be so sure. On platforms where int is shorter than ssize_t,
vanessa_socket_pipe_read_write_func() will use data that may not have been
initialised properly. Even if it has been zeroed, depending on endianness
the effect could be equivalent to a shift, or the result may not be
sign-extended correctly. amd64 seems to fall into this last category:
storing (-1) into %eax zeroes the upper half of %rax, which should
defeat the error handling in your code.
*This* fix would therefore be welcome for squeeze according to my criteria.
I'm not entirely convinced,
To clarify, what I mean is. My testing didn't show up a problem.
But I am prepared to accept that there is a problem. So, actually,
I am convinced.
but I do agree that the current situation
is precarious and fixing it in squeeze seems worthwhile.
3) perditiondb_odbc.c:dbserver_get() passes the address of
an SQLINTEGER instead of the address of a SQLLEN to the
odbc library call SQLBindCol() twice.
This seems like it could cause a stack corruption on
systems such as amd64 where SQLINTEGER (= typdef int) is 4 bytes wide
but SQLLEN (= typdef long) is 8 bytes wide.
I agree with you here (except that I, and my compiler, count three instances
of the problem, not two; but that doesn't affect the patch). Also a
candidate
for squeeze, I would think.
Ok, perhaps I counted wrong.
In any case, can I confirm that we agree that the io.c and perditiondb_odbc.c
portions of the change below should go into squeeze?
And for Lenny, I'll look into adding 695 + the io.c and perditiondb_odbc.c
portions of the change below. Does that sounds good to you?
Index: perdition/perdition/perdition.c
===
--- perdition.orig/perdition/perdition.c 2010-09-26 15:42:17.0
+0900
+++ perdition/perdition/perdition.c 2010-09-26 15:42:30.0
+0900
@@ -309,14 +309,14 @@ static void perdition_log_close_early(co
}
static void perdition_log_close(const char *from_to_host_str,
- struct auth *auth, int received, int sent)
+ struct auth *auth, size_t received, size_t sent)
{
struct quoted_str authorisation_id = quote_str(auth-authorisation_id);
VANESSA_LOGGER_ERR_UNSAFE(Closing session:%s
authorisation_id=%s%s%s
authentication_id=\%s\
- received=%d sent=%d,
+ received=%zu sent=%zu,
from_to_host_str,
authorisation_id.quote,
authorisation_id.str,
Index: perdition
Bug#597914: perdition: type mismatch in call to vanessa_socket_pipe_func
On Fri, Sep 24, 2010 at 10:36:09AM +0200, Sergio Gelato wrote: Package: perdition Version: 1.19~rc3-1 (A look at the Mercurial repository shows that the problem is still present in the latest upstream version.) I noticed the following in my logs today (irrelevant information censored): Sep 23 22:34:27 hostname perdition[31439]: Close: IP1-IP2 user=username received=150480 sent=-1801249610 The main problem is that perdition/io.c:io_pipe() and its caller perdition/perdition.c:perdition_log_close() use int counters while the corresponding arguments in vanessa_socket_pipe_func() are declared size_t. I'd worry about stack corruption on platforms where sizeof(size_t) sizeof(int). Suggested fix: declare those counters size_t, and (for cosmetic purposes) cast them to unsigned long before formatting them with %lu instead of %d. Thanks, I'll fix that. Do you think it warrants an update to the testing (= already frozen squeeze) package? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#596670: unblock: perdition/1.19~rc3-1
On Mon, Sep 13, 2010 at 07:58:23PM +0100, Adam D. Barratt wrote: On Mon, 2010-09-13 at 18:17 +0900, Horms wrote: Perdition 1.19~rc4-1 includes several important fixes and I would like it considered for inclusion in Squeeze. As it coincides with an upstream release (1.19-rc4) it also contains one or two (minor) changes that don't strictly meet the criteria for the freeze. Does the versioning imply that 1.19 is likely to be released soon? If so, are you likely to be requesting a further exception for that? Ideally I would like to release 1.19 soon. Although I don't know of any outstanding problems, I had it in mind to wait to see if any bugs show up. If it makes a difference to you I could change my plan and turn 1.19-rc4 into 1.19. What I had in mind was that if any serious bugs showed up then I would a freeze exception accordingly. I don't have it in mind to request a freeze just to bump the version to 1.19. changeset: 867:86df56cded53 user:Christophe Ségui christophe.se...@math.univ-toulouse.fr date:Thu Sep 09 21:34:24 2010 +0900 summary: Correct parsing of NIS map This is a bug that I believe is worthy of fixing for Squeeze This appears to be #596102 (the attribution above matches the bug's submitter), although that isn't mentioned in the changelog. Sorry, yes it is #596102. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#592459: oh this is a bug in the changelog
On Fri, Sep 03, 2010 at 03:07:04PM -0400, Micah Anderson wrote: The changelog says: * BuildDepend on libvanessa-logger-dev (= 0.0.12) instead of (= 0.0.10). (closes: #592459) but that should actually be libvanessa-socket-dev as that is what you changed in debian/control and the bug report was about. I was very confused for a while. Sorry about that, my butter fingers. I will make a note in the changelog for the next upload. The effect of the change is that if you try to build 1.19~rc3 against libvanessa-socket-dev 0.0.12 then the build will fail. 0.0.12 is required for the tcp_keepalive option which was introduced in 1.19~rc1, but I made typo (an ongoing theme :-() when updating debian/control at that time. In retrospect, I probably should have also bumped the so for libvanessa-socket at that time. The run-time effect is that --tcp_keepalive will be ignored if perdition is linked against an older libvanessa-socket. 0.0.11 is the only other release with so version 2. There is a known bug [1] in 1.19-rc3. So perhaps the following would be a good course of action: * Add a versioned binary dependency on libvanessa-socket2 0.0.12. * Release 1.19-rc4 with the bug fix (there are very few other changes) [1] http://hg.vergenet.net/perdition/perdition/rev/263c96021ef9 -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595207: [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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595207: perdition: thunderbird 3.1 and CVE-2009-3555
On Wed, Sep 01, 2010 at 05:23:59PM -0700, Matt Taggart wrote: Package: perdition Version: 1.17.1-2 Hi Simon, I saw on http://lists.vergenet.net/pipermail/perdition-users/2010-July/002353.html that you have a fix for CVE-2009-3555 upstream. I also see that it made it into 1.19~rc3 and thus in the versions in testing/unstable. Would it be possible to add to the stable version? I think it's probably appropriate for a stable release, both from a security perspective and for fixing new clients like TB 3.1. Hi Matt, as I recall things the fix was quite simple so there should be no problem in making something clean to resolve the problem in 1.17.1. With regards to Lenny, do you think it would be best to handle this through a security update or just through a regular stable update? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
