Bug#264500: fmtools: fmscan patch to allow choice of threshold signal strength (attached)
I incorporated this patch into fmtools 1.0 back in 2004. It is in the current Debian release (version 2.0.8). The bug can be closed. On Mon, Apr 22, 2024 at 4:53 PM Petter Reinholdtsen wrote: > > Control: tags -1 + patch > > [Gregory P. Smith] 2004-08-08] > > The fmscan utility is not nearly as useful as it could be without > > this patch. this adds the -t command line option to allow control of > > the threshold signal strength that fmscan uses to decide if a station > > can be received. please apply to future debian packages of this tool > > and submit to the upstream maintainer. > > Thank you for the patch. I am sad to see it has lingered here for so > long. CC to the upstream email address, in the hope that upstream can > have a look at the patch in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=264500 >. Not > convinced that the old email address still work, but it is worth a try. > :) > -- > Happy hacking > Petter Reinholdtsen
Bug#983316: openvswitch-switch: Hard-coded log levels, no way to configure them
On Mon, Feb 22, 2021 at 12:25:22PM +0100, Benjamin Drung wrote: > Package: openvswitch-switch > Version: 2.15.0+ds1-2 > Severity: normal > > Hi, > > Since we run into a log spam issue (probably upstream bug #135 [1]), we > want to raise the log level and disable the logging to file (syslog is > enough for us). > > Sadly `/usr/share/openvswitch/scripts/ovs-ctl` (called by > ovsdb-server.service) hard-codes the log levels and has no way to > configure them: > > ``` > set "$@" -vconsole:emer -vsyslog:err -vfile:info > ``` > > Please support configuring the log levels via > `/etc/default/openvswitch-switch`. I think you can do that already in /etc/default/openvswitch-switch with OVS_CTL_OPTS='--ovs-vswitchd-options=-vwhatever' It can undoubtedly be improved (I'm not sure multiword options will work). Open vSwitch works pretty hard to not spam log files, so I'd encourage you to report whatever excessive logging you're seeing to upstream.
Bug#977331: O: autoconf -- automatic configure script builder
Package: wnpp Severity: normal This package is going to require some work from someone who is already familiar with Autoconf. A major new release (2.70) has come out following more than 8 years of upstream development without one. Whoever adopts it will have to figure out whether it makes sense to package 2.70 under the name "autoconf" (and create a compatibility package for 2.69, as was done previously with autoconf2.13), to instead package 2.70 as "autoconf2.70", or to do something else. I do not have the motivation and the time to commit to this myself. I hope that someone out there does! This package is pretty important to developers: popularity-contest (https://qa.debian.org/popcon.php?package=autoconf) shows it installed on over 55,000 machines. This package has several bugs. I expect that the 2.70 release fixes a number of them (and introduces more).
Bug#977321: O: autoconf2.13 -- automatic configure script builder (obsolete version)
Package: wnpp Severity: normal This package is really obsolete. It has several bug reports but the right thing to do is probably to get any packages that use autoconf2.13 updated to use something else. (Or removed; they are antiques themselves.) This package still has about 1000 installs according to popularity-contest (https://qa.debian.org/popcon.php?package=autoconf2.13) but only about 100 of them use it regularly, so a lot of those installs are probably unnecessary.
Bug#977317: O: fmtools -- FM radio tuner
Package: wnpp Severity: normal This package has two bugs. One might be obsolete (it was reported against an old kernel and might not even be valid) and the other is a feature request that includes a patch, that might be worth applying. This package has about 80 users according to popularity-contest (https://qa.debian.org/popcon.php?package=fmtools). I'm orphaning it because I am no longer spending much time on Debian.
Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye
[adding d...@openvswitch.org] On Thu, Nov 12, 2020 at 04:09:20PM +, Luca Boccassi wrote: > Source: openvswitch > Version: 2.13.0+dfsg1-12 > Severity: normal > X-Debbugs-CC: pkg-dpdk-de...@lists.alioth.debian.org > christian.ehrha...@canonical.com > Tags: bullseye > > Dear Openvswitch Maintainers, > > We are scoping the src:dpdk 19.11 -> 20.11 transition. If possible, > we'd really like to go to bullseye with the latest upstream LTS, as > 19.11 is EOL at the end of next year. > > OVS support for DPDK 20.11 will be released upstream in v2.15, which is > due for release on February 15 [1]. > Bullseye transition freeze is on January 12 [2], so the dates > don't align very well. > > So we are looking to formulate a plan that you can agree with, to sort > this out. > > Based on experience, what Ubuntu usually does to meet release deadlines > is to upload from git earlier than the release, so that all major > incompatibilities can be sorted. And then after the freeze, once the > release is officially out, do a final upgrade to the released version - > since a similar enough version was uploaded from git, and at the end of > a release cycle it's mostly bug fixes that land upstream, such an > upload is acceptable. > > So we'd like to propose the following ideas: > > - between now and December: upload v2.14, to minimize the later jump > - by the first week of January: upload 2.15~git from the tip of the > master branch to experimental > - stabilize and sort eventual build issues > - upload dpdk 20.11 and ovs 2.15~git to unstable > - upload 2.15 proper in February as a bug fix upload to unstable > > What do you think? Does this sound like a workable plan? > > We are of course happy to help - Ubuntu will go through the exact same > process for 21.04, so a lot of the work is "shared". > > Thank you! > > -- > Kind regards, > Luca Boccassi > > [1] https://docs.openvswitch.org/en/latest/internals/release-process/ > [2] https://release.debian.org/bullseye/freeze_policy.html
Bug#942056: [ovs-dev] [PATCH] debian: Update list of copyright holders.
On Wed, Nov 27, 2019 at 10:25:36AM -0800, Yi-Hung Wei wrote: > On Wed, Oct 9, 2019 at 10:35 AM Ben Pfaff wrote: > > > > The list of copyright holders was incomplete and out of date. This > > updates it based on a "grep" for copyright notices, which I reviewed by > > hand. > > > > CC: 942...@bugs.debian.org > > Reported-by: Chris Lamb > > Reported-at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942056 > > Signed-off-by: Ben Pfaff > > --- > > LGTM. > > Acked-by: Yi-Hung Wei Thanks, applied to master.
Bug#942609: pspp: build with -O2 to avoid misbuild with CFLAGS=-O3
On Fri, Oct 18, 2019 at 4:27 PM Steve Langasek wrote: > > Package: pspp > Version: 1.2.0-3 > Severity: minor > Tags: patch > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu focal ubuntu-patch > > Dear maintainers, > > In Ubuntu, pspp was failing to build on ppc64el because the Ubuntu ppc64el > port, unlike Debian's, uses -O3 as the default optimization level; and when > built this way, at least on ppc64el the package fails one of its tests: > > [...] > ## ## > Failed tests: > GNU PSPP 1.2.0 test suite test groups: > > NUM: FILE-NAME:LINE TEST-GROUP-NAME > KEYWORDS > > 126: sys-file-reader.at:2951 zero or one variable in mrset > sack synthetic system file negative multiple response > > ## -- ## > ## Detailed failed tests. ## > ## -- ## > > # -*- compilation -*- > 126. sys-file-reader.at:2951: testing zero or one variable in mrset ... > ./sys-file-reader.at:2970: sack --$variant sys-file.sack > sys-file.sav > ./sys-file-reader.at:2973: pspp -O format=csv sys-file.sps > --- - 2019-01-16 11:24:48.338741568 + > +++ /<>/tests/testsuite.dir/at-groups/126/stdout 2019-01-16 > 11:24:48.335475863 + > @@ -1,3 +1,5 @@ > +warning: `sys-file.sav' near offset 0xd8: Missing new-line parsing variable > names at offset 22 in MRSETS record. Thank you very much for the note and the patch. Do you have any idea whether this is likely to be a previously unknown bug in PSPP (as opposed to a bug somewhere else, such as in GCC)? I feel like I ought to invest some time into trying to find a PSPP bug here, but on the other hand I don't want to chase a ghost.
Bug#942056: [PATCH] debian: Update list of copyright holders.
The list of copyright holders was incomplete and out of date. This updates it based on a "grep" for copyright notices, which I reviewed by hand. CC: 942...@bugs.debian.org Reported-by: Chris Lamb Reported-at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942056 Signed-off-by: Ben Pfaff --- debian/copyright.in | 80 - 1 file changed, 64 insertions(+), 16 deletions(-) diff --git a/debian/copyright.in b/debian/copyright.in index 9ad00340f6bb..3669255c75cd 100644 --- a/debian/copyright.in +++ b/debian/copyright.in @@ -8,22 +8,70 @@ Upstream Authors (from AUTHORS): Upstream Copyright Holders: -Copyright (c) 2007, 2008, 2009, 2010, 2011, 2012, 2013 Nicira, Inc. -Copyright (c) 2010 Jean Tourrilhes - HP-Labs. -Copyright (c) 2008,2009,2010 Citrix Systems, Inc. -and authors listed above. -Copyright (c) 2011 Gaetano Catalli -Copyright (C) 2000-2003 Geoffrey Wossum (gwos...@acm.org) -Copyright (C) 2000 The NetBSD Foundation, Inc. -Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project. -Copyright (c) 1982, 1986, 1990, 1993 The Regents of the University of California. -Copyright (c) 2008, 2012 Vincent Bernat -Copyright (c) 2014 Michael Chapman -Copyright (c) 2014 WindRiver, Inc. -Copyright (c) 2014 Avaya, Inc. -Copyright (c) 2001 Daniel Hartmeier -Copyright (c) 2002 - 2008 Henning Brauer -Copyright (c) 2012 Gleb Smirnoff +6WIND S.A. +Alexandru Copot , with support from IXIA. +Alexey I. Froloff. +Amir Vadai +Arm Limited +Avaya, Inc. +Benjamin Kosnik +Cisco Systems, Inc +Citrix Systems, Inc. +Cloudbase Solutions Srl +Cumulus Netowkrs +Daniel Baluta +Daniel Hartmeier +Dan Nicholson +Dustin J. Mitchell +Ed Maste +Eelco Chaudron +Ericsson AB +Free Software Foundation, Inc., +Gaetano Catalli +Gary S. Brown. +Geoffrey Wossum (gwos...@acm.org) +Gleb Smirnoff +Grant Jenks +Henning Brauer +Hewlett Packard Enterprise Development LP +Horms Solutions Ltd. +IBM +Ilya Maximets +Javier Fernandez-Sanguino +Jean Tourrilhes - HP-Labs. +Jiri Pirko +Kmindg +Krzesimir Nowak +M3S, Srl - Italy +Mark Pilgrim +Mellanox Technologies, Ltd. +Michael Chapman +Moritz Klammler +Netronome +Nicira, Inc. +Open Networking Foundation +Paolo Abeni +Paul Norman +Red Hat, Inc. +Roy Stogner +Samsung Electronics Co.,Ltd. +Scott James Remnant +Scott Pakin +Siemens AG +Sten Spans +Stephen Finucane +The Board of Trustees of The Leland Stanford Junior University +The NetBSD Foundation, Inc. +The Regents of the University of California. +The University of Waikato +USAGI/WIDE Project +Vincent Bernat +VMware, Inc. +WIDE Project. +WindRiver, Inc. +YAMAMOTO Takashi +Zack Weinberg +Zmanda Inc. <http://www.zmanda.com/> License: -- 2.21.0
Bug#937216: openvswitch: Python2 removal in sid/bullseye
On Sat, Sep 21, 2019 at 09:44:14PM +0200, Thomas Goirand wrote: > On 9/19/19 4:59 PM, Ben Pfaff wrote: > > On Fri, Aug 30, 2019 at 07:29:41AM +, Matthias Klose wrote: > >> Python2 becomes end-of-live upstream, and Debian aims to remove > >> Python2 from the distribution, as discussed in > >> https://lists.debian.org/debian-python/2019/07/msg00080.html > >> > >> Your package either build-depends, depends on Python2, or uses Python2 > >> in the autopkg tests. Please stop using Python2, and fix this issue > >> by one of the following actions. > > > > For what it's worth, we're doing a Python 3-only conversion in the > > upstream repo at the moment: > > > > https://mail.openvswitch.org/pipermail/ovs-dev/2019-September/362813.html > > > > However, the code already supported Python 3 almost everywhere before > > this, so it's probably not necessary to backport this series for Debian. > > Hi Ben, > > What's hard is more to get rid of python2, like shebangs, etc. If you're > doing it upstream, that's great, thanks. When do you think that will be > done, and a new stable release will be done? Can you ping me when that's > the case? I think it will be done soon, within a week or two. It's just a matter of getting a little bit of review bandwidth from someone. Our release process calls for the next stable release to branch off of master on Jan. 15 and to release on Feb. 15. Are you interested in hearing about the patches being committed or the release coming out? If it's just the latter, we have a very low-bandwidth ovs-announce mailing list that you could subscribe.
Bug#937216: openvswitch: Python2 removal in sid/bullseye
On Fri, Aug 30, 2019 at 07:29:41AM +, Matthias Klose wrote: > Python2 becomes end-of-live upstream, and Debian aims to remove > Python2 from the distribution, as discussed in > https://lists.debian.org/debian-python/2019/07/msg00080.html > > Your package either build-depends, depends on Python2, or uses Python2 > in the autopkg tests. Please stop using Python2, and fix this issue > by one of the following actions. For what it's worth, we're doing a Python 3-only conversion in the upstream repo at the moment: https://mail.openvswitch.org/pipermail/ovs-dev/2019-September/362813.html However, the code already supported Python 3 almost everywhere before this, so it's probably not necessary to backport this series for Debian.
Bug#923417: pspp: CVE-2019-9211
On Wed, Feb 27, 2019 at 10:31:58PM +0100, Salvatore Bonaccorso wrote:
> Source: pspp
> Version: 1.2.0-2
> Severity: normal
> Tags: security upstream
>
> Hi,
>
> The following vulnerability was published for pspp.
>
> CVE-2019-9211[0]:
> | There is a reachable assertion abort in the function
> | write_long_string_missing_values() in data/sys-file-writer.c in
> | libdata.a in GNU PSPP 1.2.0 that will lead to denial of service.
I fixed this on PSPP master with commit 0b842a843537 ("sys-file-writer:
Remove assertions based on file position.").
As has become usual, this bug was reported to Debian and Red Hat and
MITRE and never to me, the upstream author. If you know any way to
de-anonymize whoever is actually finding these bugs, I'd appreciate it.
Whoever it is deserves education.
Bug#916902: pspp: CVE-2018-20230
On Fri, Feb 22, 2019 at 10:57:20PM +0100, Moritz Mühlenhoff wrote:
> On Wed, Dec 19, 2018 at 10:07:59PM -0800, Ben Pfaff wrote:
> > On Thu, Dec 20, 2018 at 06:22:14AM +0100, Salvatore Bonaccorso wrote:
> > > Source: pspp
> > > Version: 1.2.0-2
> > > Severity: important
> > > Tags: security upstream
> > >
> > > Hi,
> > >
> > > The following vulnerability was published for pspp.
> > >
> > > CVE-2018-20230[0]:
> > > | An issue was discovered in PSPP 1.2.0. There is a heap-based buffer
> > > | overflow at the function read_bytes_internal in
> > > | utilities/pspp-dump-sav.c, which allows attackers to cause a denial of
> > > | service (application crash) or possibly have unspecified other impact.
> >
> > This is another instance of a recurring problem with PSPP, in which some
> > anonymous person reports a vulnerability to MITRE, but not to the
> > upstream authors or the pspp-security list, and so the authors only hear
> > about it when Red Hat and Debian file bugs based on it. It makes me
> > really mad.
>
> Regardless of the questionable reporting done here, do you know if this
> bug has been addressed/reported upstream?
Yes, I fixed it upstream with commit abd1f816ca3b ("pspp-dump-sav: Issue
error message for too-large extension records.") on January 1.
Bug#916902: pspp: CVE-2018-20230
On Thu, Dec 20, 2018 at 06:22:14AM +0100, Salvatore Bonaccorso wrote: > Source: pspp > Version: 1.2.0-2 > Severity: important > Tags: security upstream > > Hi, > > The following vulnerability was published for pspp. > > CVE-2018-20230[0]: > | An issue was discovered in PSPP 1.2.0. There is a heap-based buffer > | overflow at the function read_bytes_internal in > | utilities/pspp-dump-sav.c, which allows attackers to cause a denial of > | service (application crash) or possibly have unspecified other impact. This is another instance of a recurring problem with PSPP, in which some anonymous person reports a vulnerability to MITRE, but not to the upstream authors or the pspp-security list, and so the authors only hear about it when Red Hat and Debian file bugs based on it. It makes me really mad. So, how did you find out about this vulnerability? I haven't found a way to monitor the MITRE database for PSPP-related vulnerabilities. They don't provide a way to do that (I even asked them a while back). Thanks, Ben.
Bug#908978: openvswitch: FTBFS on armel, mips, mips64el, mipsel
On Mon, Sep 17, 2018 at 09:41:50AM +0200, Thomas Goirand wrote: > On 09/17/2018 12:50 AM, Ivo De Decker wrote: > > package: openvswitch > > version: 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-3 > > severity: serious > > > > Hi, > > > > The latest version of openvswitch in unstable fails on armel, mips, > > mips64el, > > mipsel: > > > > https://buildd.debian.org/status/package.php?p=openvswitch > > > > Cheers, > > > > Ivo > > Hi, > > We know, and we're already working on it. But I've been traveling in Japan for the last week and so not making progress. I'm back Wednesday, though.
Bug#901281: O: doschk -- SYSV and DOS filename conflicts check
Package: wnpp Severity: normal This package has no reported bugs, the last upstream release was in 1993, and zero recent users according to popularity-contest (https://qa.debian.org/popcon.php?package=doschk). It has questionable value these days. If no one wants to adopt it, it can probably be removed from Debian.
Bug#813116: /usr/sbin/ovs-vswitchd: segfault when push_mpls flow action is applied
On Fri, Dec 01, 2017 at 02:24:13PM +0100, Ferenc Wágner wrote: > Yesterday an upstream switch reboot segfaulted all our ovs-vswitchd > instances at the same time. There's no MPLS or flow config in our OVS > setups, they run a bridge over a bond and several 802.1q interfaces. I > mention it here, though, as the backtrace starts similarly, so maybe > this is a more general issue: Thank you for the report. What version of Open vSwitch is this?
Bug#842569: mark autoconf2.13 Multi-Arch: foreign
On Mon, Nov 13, 2017 at 09:22:01AM +0100, Manuel A. Fernandez Montecelo wrote: > Hi, > > 2017-11-13 1:27 GMT+01:00 Ben Pfaff <b...@cs.stanford.edu>: > > On Sat, Nov 11, 2017 at 02:48:31PM +0100, Manuel A. Fernandez Montecelo > > wrote: > >> Hi Ben, > >> > >> 2016-10-30 13:48 Helmut Grohne: > >> >Package: autoconf2.13 > >> >Version: 2.13-67 > >> >Tags: patch > >> >User: helm...@debian.org > >> >Usertags: rebootstrap > >> >Control: affects -1 + src:firefox src:firefox-esr src:gcc-3.3 > >> >src:gcc-m68hc1x src:grass src:icedove src:postgis src:vflib3 > >> > > >> >The affected packages fail to satisfy their cross Build-Depends, because > >> >their dependency on autoconf2.13 is not satisfiable. In general, > >> >Architecture: all packages cannot satisfy cross build dependencies > >> >unless marked Multi-Arch: foreign. > >> > >> The patch is simple enough and affects important packages. > >> > >> Would it be possible to apply it in your next uploads? > > > > As far as I can tell, this was applied in 2.13-67 and is still in > > 2.13-68. What is missing? > > Right, so the header is there but this bug is not mentioned in those > changelog entris and this bug is not closed. > > It seem that the M-A:foreign wasn't present in -67, that's why Helmut > reported it, but it's there in -68, uploaded this august: > > https://sources.debian.net/src/autoconf2.13/2.13-67/debian/control/ > https://sources.debian.net/src/autoconf2.13/2.13-67/debian/control/ > > Should we close then the bug as fixed in -68? Oh, the problem is just that the bug wasn't closed? That's easy enough to fix. I'll close the bug.
Bug#842569: mark autoconf2.13 Multi-Arch: foreign
On Sat, Nov 11, 2017 at 02:48:31PM +0100, Manuel A. Fernandez Montecelo wrote: > Hi Ben, > > 2016-10-30 13:48 Helmut Grohne: > >Package: autoconf2.13 > >Version: 2.13-67 > >Tags: patch > >User: helm...@debian.org > >Usertags: rebootstrap > >Control: affects -1 + src:firefox src:firefox-esr src:gcc-3.3 > >src:gcc-m68hc1x src:grass src:icedove src:postgis src:vflib3 > > > >The affected packages fail to satisfy their cross Build-Depends, because > >their dependency on autoconf2.13 is not satisfiable. In general, > >Architecture: all packages cannot satisfy cross build dependencies > >unless marked Multi-Arch: foreign. > > The patch is simple enough and affects important packages. > > Would it be possible to apply it in your next uploads? As far as I can tell, this was applied in 2.13-67 and is still in 2.13-68. What is missing? Thanks, Ben.
Bug#878249: recent OVS upload (was: Re: Bug#878249: Please package >= 2.7.0)
On Thu, Oct 26, 2017 at 03:45:48PM -0700, Ben Pfaff wrote: > I see a number of failed builds here: > https://buildd.debian.org/status/package.php?p=openvswitch=experimental > > Let me analyze them: > > * mips, powerpc, and ppc64 should be fixed by this commit that is > already on branch-2.8: > https://github.com/openvswitch/ovs/commit/2906ff5e7eb1fb39b497dc05e471 > > * m68k is because of looser alignment rules than on other platforms. I > don't care much about m68k, and it's not a Debian required platform, > so I don't plan to fix this. > > * sparc64 failures are due to bus errors. I would like to investigate, > but I don't know how, because there is only one sparc64 machine listed > at https://db.debian.org/machines.cgi, and that machine appears to be > down (it is not accepting SSH connections at least when I tried just > now). > > * The ppc64el failure is a hang during the testsuite. Test 2332, which > appears to be "ovn -- icmp_reply: 1 HVs, 2 LSs, 1 lport/LS, 1 LR", > hung. I will try to reproduce and fix this. Even if we do not fix > it, it might not recur in later runs, because it indicates a race > condition in the testsuite. (This is almost certainly a bug in the > testsuite rather than in OVS itself.) There's now a failure on hppa, too, which bears investigation. I'll try to look at that soon.
Bug#878249: recent OVS upload (was: Re: Bug#878249: Please package >= 2.7.0)
On Fri, Oct 20, 2017 at 08:56:24PM +0200, Thomas Goirand wrote: > I don't mind becoming a co-maintainer, though there's a few things that > need to change to facilitate packaging. First of all, I'd like to switch > to a Git packaging workflow, using git-buildpackage. The debian folder > upstream here should be removed: > > https://github.com/openvswitch/ovs/tree/master/debian > > otherwise, it will clash with what we have in Alioth. Then I'll push > openvswitch in the Alioth git repository under /git/third-party. > > Also, I will remove the debian/automake.mk and the d/copyright hack. > Indeed, Debian needs list of copyright holders, not authors. > > Is that fine for you? I'm starting... Thanks for doing an upload. Open vSwitch users expect to be able to build packages for whatever version of Open vSwitch they're using, which is most easily satisfied by keeping the Debian packaging with the rest of the tree. Any other solution makes it harder to keep the code in sync with the packaging. Removing the debian directory would frustrate this. I'm not a fan of the "dfsg" suffix because it implies that DFSG-noncompliant material was removed. There is nothing DFSG-noncompliant about the Debian directory, it is simply inconvenient for the way you prefer to maintain the packaging. Would you mind choosing a different suffix? I see a number of failed builds here: https://buildd.debian.org/status/package.php?p=openvswitch=experimental Let me analyze them: * mips, powerpc, and ppc64 should be fixed by this commit that is already on branch-2.8: https://github.com/openvswitch/ovs/commit/2906ff5e7eb1fb39b497dc05e471 * m68k is because of looser alignment rules than on other platforms. I don't care much about m68k, and it's not a Debian required platform, so I don't plan to fix this. * sparc64 failures are due to bus errors. I would like to investigate, but I don't know how, because there is only one sparc64 machine listed at https://db.debian.org/machines.cgi, and that machine appears to be down (it is not accepting SSH connections at least when I tried just now). * The ppc64el failure is a hang during the testsuite. Test 2332, which appears to be "ovn -- icmp_reply: 1 HVs, 2 LSs, 1 lport/LS, 1 LR", hung. I will try to reproduce and fix this. Even if we do not fix it, it might not recur in later runs, because it indicates a race condition in the testsuite. (This is almost certainly a bug in the testsuite rather than in OVS itself.) It has been my practice to package the tip of whatever release branch we're using, for example in this case to package from the tip of branch-2.8. OVS release branches only accept bug fixes, so this works well for getting bug fixes that have not yet made it into an "official" release. In this case, this would have picked up the fix that caused three of the builds to fail while running the testsuite. Thanks again, Ben.
Bug#878249: Please package >= 2.7.0
On Wed, Oct 11, 2017 at 06:31:17PM +0200, Thomas Goirand wrote: > Hi Ben (and others?), > > OpenStack Pike needs ovs >= 2.7.0. We're about to release it to Debian > unstable, > as it is currently staging in Experimental. Please package this ASAP. I'm currently seeking a new maintainer or co-maintainer for Open vSwitch for Debian. My previous inquiries along these lines have not produced any success, but if you or someone you know is motivated to join in, I would appreciate that.
Bug#877543: CVE-2017-14970
On Mon, Oct 02, 2017 at 08:33:30PM +0200, Moritz Mühlenhoff wrote: > On Mon, Oct 02, 2017 at 10:33:06AM -0700, Ben Pfaff wrote: > > On Mon, Oct 02, 2017 at 07:17:59PM +0200, Moritz Muehlenhoff wrote: > > > Source: openvswitch > > > Severity: important > > > Tags: security > > > > > > Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14970 > > > > We don't think that these memory leaks are important because they can > > only come from the OpenFlow controller, which has more powerful ways to > > force memory allocations; for example, by inserting large numbers of > > flows. > > Ok. We've only learned about this CVE ID from the daily feed updates > from MITRE. Since you're upstream, could you contact MITRE via > https://cveform.mitre.org (and selecting the "Request an update to an > existing CVE Entry" option) to have them mark the CVE ID as disputed > or rejected? OK, done.
Bug#877543: CVE-2017-14970
On Mon, Oct 02, 2017 at 07:17:59PM +0200, Moritz Muehlenhoff wrote: > Source: openvswitch > Severity: important > Tags: security > > Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14970 We don't think that these memory leaks are important because they can only come from the OpenFlow controller, which has more powerful ways to force memory allocations; for example, by inserting large numbers of flows.
Bug#850329: autoconf tries to execute foreign binaries
I'm adding the autoconf mailing list. For more background, take a look at the Debian bug log: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850329 On Sun, Aug 20, 2017 at 09:18:44PM +0200, Vincent Lefevre wrote: > On 2017-08-20 11:01:28 -0700, Ben Pfaff wrote: > > This bug regards how Autoconf decides whether it's cross-compiling. > > This is a somewhat tricky issue. The following is summarized from > > https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Hosts-and-Cross_002dCompilation.html > > (and quotes come from there): > > > >1. Without --host or --build, Autoconf aborts if it can't run the > > binaries that the compiler produces. It assumes that's a > > problem in the system configuration, such as a broken > > compiler. > > > >2. With --host and --build, Autoconf decides that it's > > cross-compiling if the host and the build system are > > different. > > > > "If you specify both, and they're different, configure enters > > cross compilation mode, so it doesn't run any tests that > > require execution." > > > >3. With --host, but not --build, Autoconf decides that it's > > cross-compiling if it can't run a binary produced by the > > compiler: > > > > "If you specify --host, but not --build, when configure > > performs the first compiler test it tries to run an executable > > produced by the compiler. If the execution fails, it enters > > cross-compilation mode. This is fragile. Moreover, by the time > > the compiler test is performed, it may be too late to modify > > the build-system type: other tests may have already been > > performed." > > > > The issue here is what Autoconf should do in case #3, which is what wine > > is doing. Is there a better way to detect whether the system can run a > > binary, than to try to run the binary? Or is there a way to avoid the > > broken dash behavior? > > In case 3, can't Autoconf use the guessed value of BUILD, so that > it would be like case 2? > > > But I am a little concerned about whether we should do anything at all, > > because case #3 is deprecated: > > > > "**Do not rely on [case 3]**, as it will be removed in the near > > future... Therefore, whenever you specify --host, be sure to > > specify --build too." > > As the --build value can be guessed, I think that it would be annoying > for the user to force him to use --build in case of cross-compilation. > IMHO, making case 3 like case 2 with the guessed value of BUILD (as > I've proposed above) would make sense. That would be the typical case > for cross-compilation, as in general, one builds on the machine where > one runs configure. Hmm. I'm comfortable with the idea of trying to figure out some way to avoid trying to execute binaries as if they were shell scripts. On the other hand, while I don't personally object to changing this basic Autoconf behavior, this is getting well into the territory where I'd be uncomfortable proposing it myself. Does anyone on the autoconf mailing list have thoughts?
Bug#850329: autoconf tries to execute foreign binaries
This bug regards how Autoconf decides whether it's cross-compiling. This is a somewhat tricky issue. The following is summarized from https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Hosts-and-Cross_002dCompilation.html (and quotes come from there): 1. Without --host or --build, Autoconf aborts if it can't run the binaries that the compiler produces. It assumes that's a problem in the system configuration, such as a broken compiler. 2. With --host and --build, Autoconf decides that it's cross-compiling if the host and the build system are different. "If you specify both, and they're different, configure enters cross compilation mode, so it doesn't run any tests that require execution." 3. With --host, but not --build, Autoconf decides that it's cross-compiling if it can't run a binary produced by the compiler: "If you specify --host, but not --build, when configure performs the first compiler test it tries to run an executable produced by the compiler. If the execution fails, it enters cross-compilation mode. This is fragile. Moreover, by the time the compiler test is performed, it may be too late to modify the build-system type: other tests may have already been performed." The issue here is what Autoconf should do in case #3, which is what wine is doing. Is there a better way to detect whether the system can run a binary, than to try to run the binary? Or is there a way to avoid the broken dash behavior? But I am a little concerned about whether we should do anything at all, because case #3 is deprecated: "**Do not rely on [case 3]**, as it will be removed in the near future... Therefore, whenever you specify --host, be sure to specify --build too." I believe this means that if wine followed the Autoconf manual's recommendations, there would be no problem, because Autoconf would know a priori that it was cross-compiling. Any thoughts? Thanks, Ben.
Bug#863662: openvswitch: CVE-2017-9265
On Thu, Jul 06, 2017 at 10:49:30PM +0200, Moritz Muehlenhoff wrote: > On Mon, May 29, 2017 at 10:16:50PM +0200, Salvatore Bonaccorso wrote: > > Source: openvswitch > > Version: 2.6.2~pre+git20161223-3 > > Severity: normal > > Tags: upstream patch security > > > > Hi, > > > > the following vulnerability was published for openvswitch. > > > > CVE-2017-9265[0]: > > | In Open vSwitch (OvS) v2.7.0, there is a buffer over-read while parsing > > | the group mod OpenFlow message sent from the controller in > > | `lib/ofp-util.c` in the function `ofputil_pull_ofp15_group_mod`. > > > > this should be only in the OpenFlow 1.5+ support, not sure the message > > mentions this is not enabled by default. Affected source it as least > > there. > > Maintainers, can you please clarify what > > | This bug is part of OpenFlow 1.5 support. Open vSwitch does not enable > | OpenFlow 1.5 support by default. > > entails, is that something that's not compiled-in in the Debian package > or what "does not support" mean exactly? OpenFlow 1.5 support is incomplete in OVS 2.7, which makes it not very useful. So an administrator has to enable it explicitly, and probably won't (because it's not very useful).
Bug#860786: [ovs-dev] Bug#860786: README.Debian: include IPv6 in examples for /etc/network/interfaces
On Thu, Apr 20, 2017 at 08:00:20AM +0200, Daniel Pocock wrote: > Package: openvswitch-switch > Version: 2.3.0+git20140819-3+deb8u1 > Severity: wishlist > > > Looking at the examples for /etc/network/interfaces, none of them > include IPv6. > > I've tried configuring it using the example below and it appears to be > working fine in a dual stack DHCP environment. > > In another environment, I used an "up ip addr add [ipv6 addr] ..." > command in the inet stanza > > Please confirm if the inet6 stanza is fully supported and if this is the > right way to use it and consider adding it to README.Debian: > > > > > # This file describes the network interfaces available on your system > # and how to activate them. For more information, see interfaces(5). > > # The loopback network interface > auto lo > iface lo inet loopback > > auto ovsbr0 > iface ovsbr0 inet dhcp > ovs_type OVSBridge > ovs_ports eth0 > > iface ovsbr0 inet6 dhcp > ovs_type OVSBridge > ovs_ports eth0 > > allow-ovsbr0 eth0 > iface eth0 inet manual > ovs_bridge ovsbr0 > ovs_type OVSPort I think there is a missing space between "allow-ovs" and "br0" above. Guru, do these examples look correct otherwise? Would it make sense to include an inet6 example like the one above? Thanks, Ben.
Bug#866890: pspp - cve-2017-10791 - cve-2017-10792
I applied fixes for both of these bugs to the PSPP repository, as the following commits. The fixes will be in the next PSPP release. commit 41c6f5447941e5d36d0554ba874671649353752f Author: Ben Pfaff <b...@cs.stanford.edu> Date: Tue Jul 4 12:58:55 2017 -0400 sys-file-reader: Fix integer overflows in parse_long_string_missing_values(). Crafted system files caused integer overflow errors that in turn caused aborts. This fixes the problem. CVE-2017-10791. See also https://bugzilla.redhat.com/show_bug.cgi?id=1467004. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866890. See also https://security-tracker.debian.org/tracker/CVE-2017-10791. Found by team OWL337, using the collAFL fuzzer. commit bf03b53a3c0f0d1066062f37919015a8fa6ad436 Author: Ben Pfaff <b...@cs.stanford.edu> Date: Tue Jul 4 12:54:47 2017 -0400 sys-file-reader: Avoid null dereference skipping bad extension record 18. read_record() assumed that read_extension_record() never set its output argument to NULL when it returned true, but this is possible in an error case. CVE-2017-10792. See also https://bugzilla.redhat.com/show_bug.cgi?id=1467005. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866890. See also https://security-tracker.debian.org/tracker/CVE-2017-10792. Reported by team OWL337, with fuzzer collAFL.
Bug#866890: pspp - cve-2017-10791 - cve-2017-10792
The attribution of the problem to the hash function is probably wrong, since that function is purely combinatorial logic, but the report as a whole is right because the attachment in the bug report at https://bugzilla.redhat.com/show_bug.cgi?id=1467004 does cause pspp-convert to assert-fail. I'm looking into it. On Mon, Jul 03, 2017 at 08:50:56PM +0200, John Darrington wrote: > I suspect this report is mistaken. But this bit is Ben's code, so I'll let > him comment on > that. > > J' > > On Mon, Jul 03, 2017 at 07:22:57AM +0200, Friedrich Beckmann wrote: > Dear owl337 team, > > thanks for looking at pspp and finding the security problems > > https://security-tracker.debian.org/tracker/CVE-2017-10791 > > and > > https://security-tracker.debian.org/tracker/CVE-2017-10792 > > in pspp! Your reports are quite detailed. Could you describe how you > found the problems, i.e. do > you have some information about collAFL? > > Regards > > Friedrich > > > > ___ > pspp-dev mailing list > pspp-...@gnu.org > https://lists.gnu.org/mailman/listinfo/pspp-dev > > -- > Avoid eavesdropping. Send strong encrypted email. > PGP Public key ID: 1024D/2DE827B3 > fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 > See http://sks-keyservers.net or any PGP keyserver for public key. >
Bug#863661: openvswitch: CVE-2017-9264
severity 863661 normal thanks On Mon, May 29, 2017 at 10:14:49PM +0200, Salvatore Bonaccorso wrote: > Source: openvswitch > Version: 2.6.2~pre+git20161223-3 > Severity: important > Tags: patch upstream security > > Hi, > > the following vulnerability was published for openvswitch. > > CVE-2017-9264[0]: > | In lib/conntrack.c in the firewall implementation in Open vSwitch (OvS) > | 2.6.1, there is a buffer over-read while parsing malformed TCP, UDP, > | and IPv6 packets in the functions `extract_l3_ipv6`, `extract_l4_tcp`, > | and `extract_l4_udp` that can be triggered remotely. > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. This only affects the userspace datapath, most often used in the context of DPDK, which isn't enabled in the Debian packaging. In addition, the fact that it's a buffer overread (which makes it difficult to use to crash OVS or change its behavior) and the fact that end-to-end TCP checksum verification would catch it leads me to believe that this is only "normal" severity, so I'm updating it (with this email). Thanks, Ben.
Bug#863655: openvswitch: CVE-2017-9263
notfound 863655 2.3.0+git20140819-1 found 863655 2.6.2~pre+git20161223-3 severity 863655 normal thanks On Mon, May 29, 2017 at 09:44:13PM +0200, Salvatore Bonaccorso wrote: > Source: openvswitch > Version: 2.3.0+git20140819-1 > Severity: important > Tags: security upstream patch > > Hi, > > the following vulnerability was published for openvswitch. > > CVE-2017-9263[0]: > | In Open vSwitch (OvS) 2.7.0, while parsing an OpenFlow role status > | message, there is a call to the abort() function for undefined role > | status reasons in the function `ofp_print_role_status_message` in > | `lib/ofp-print.c` that may be leveraged toward a remote DoS attack by a > | malicious switch. This doesn't really make sense. For a "malicious switch" to leverage this as a remote DoS, the controller that it talks to has to be implemented using the OVS code in question. OVS 2.3 as packaged for Debian doesn't include a controller, Open vSwitch 2.6.2 includes two controllers. The first one, ovs-testcontroller, is not vulnerable to this in the default configuration, because it does not print such messages even if it receives them, unless it is specially configured to do so. The second one, ovn-controller, only talks to Open vSwitch directly, not to arbitrary switches, and only over a trusted Unix domain socket anyway. In any case, if either of these crashes due to this bug, they automatically restart themselves. So, while it is a good idea to fix this, it's not high severity.
Bug#860479: [ovs-dev] Bug#860479: openvswitch-datapath-dkms (and openvswitch-datapath-source) fail compiling on fresh install of 7.11
On Mon, Apr 17, 2017 at 07:04:12PM +0300, Bogdan Ilisei wrote: > Package: openvswitch-datapath-dkms > Version: 1.4.2+git20120612-9.1~deb7u1.1 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > Installing openvswitch-datapath-dkms (OR openvswitch-datapath-source) is > currently broken in Wheezy 7.11. Yes. The openvswitch-datapath-dkms package was removed from later releases because it was impossible to make them work with every kernel that Debian supports.
Bug#842641: Sv: Bug#842641: RFS: autoconf/2.69-10~bpo8+1
On Mon, Oct 31, 2016 at 04:50:49PM +, Kristian Klausen wrote: > BTW Ben if you want to take care for the backport by yourself, I'm happy to > cancel > or give you the task :) Please, be my guest, you are welcome to take this. Thank you.
Bug#842641: RFS: autoconf/2.69-10~bpo8+1
On Mon, Oct 31, 2016 at 04:24:10PM +0100, Alexander Wirt wrote: > On Mon, 31 Oct 2016, Ben Pfaff wrote: > > > On Mon, Oct 31, 2016 at 11:16:18AM +0100, Gianfranco Costamagna wrote: > > > Hi Ben, > > > > > > > I am looking for a sponsor for my package "autoconf". > > > > Some packages depends on the new --runstatedir option which was added > > > > in 2.69-9, > > > > before they can be built for jessie-backports. Ex connman. > > > > Is this request okay with you Ben, or do you want to handle it? > > > > > > I sponsored this upload in deferred/10, let me know if it sounds good to > > > you > > > (being in lowNMU threshold helps here :) thanks for that) > > > > Thanks for helping. I was planning to sponsor, but it's even easier > > since you got to it first. > Autoconf is a very important package and I don't think we want a backport > that is not maintained by a regular uploader. Gianfranco, are you planning to take responsibility for uploading this as it changes in Debian proper? It is probably not a big responsibility, because autoconf changes rarely. I'm willing to sponsor the uploads.
Bug#842641: RFS: autoconf/2.69-10~bpo8+1
On Mon, Oct 31, 2016 at 11:16:18AM +0100, Gianfranco Costamagna wrote: > Hi Ben, > > > I am looking for a sponsor for my package "autoconf". > > Some packages depends on the new --runstatedir option which was added in > > 2.69-9, > > before they can be built for jessie-backports. Ex connman. > > Is this request okay with you Ben, or do you want to handle it? > > I sponsored this upload in deferred/10, let me know if it sounds good to you > (being in lowNMU threshold helps here :) thanks for that) Thanks for helping. I was planning to sponsor, but it's even easier since you got to it first.
Bug#108504: nqc bugs in debian
On Wed, Oct 12, 2016 at 01:38:16PM +0200, Petter Reinholdtsen wrote: > [Ben Pfaff 2007-06-21]: > > I think that it's a udev vs. no-udev issue. The udev rules I see > > here show that the legousbtower0 device should be created in > > /dev/usb. If you're not using udev, and you created the device > > by hand, perhaps it's in /dev instead of /dev/usb. > > Hi. I am looking at the udev and appstream setup for nqc, and would like to > ensure these USB towers work as they should. Can one of you provide the > output > from 'lsusb' and udevadm info /dev/bus/usb/XXX/YYY' for the device when such > tower is plugged into a machine. I would like to help, it looks like I don't have the hardware anymore. > Btw, are you aware of the newly formed Debian LEGO team? It is an effort to > improve the situation for LEGO related packages in Debian. You are most > welcome to > join the IRC channel and mailing list. :) Thanks for the invitation!
Bug#828478: [ovs-dev] [PATCH v2] ovs-pki: Use SHA-512 instead of SHA-1 as message digest.
On Wed, Jul 13, 2016 at 10:06:53PM -0500, Ryan Moats wrote:
> "dev" <dev-boun...@openvswitch.org> wrote on 07/01/2016 08:05:40 PM:
>
> > From: Ben Pfaff <b...@ovn.org>
> > To: d...@openvswitch.org
> > Cc: Ben Pfaff <b...@ovn.org>, Kurt Roeckx <k...@roeckx.be>,
> > 828...@bugs.debian.org
> > Date: 07/01/2016 08:06 PM
> > Subject: [ovs-dev] [PATCH v2] ovs-pki: Use SHA-512 instead of SHA-1
> > as message digest.
> > Sent by: "dev" <dev-boun...@openvswitch.org>
> >
> > The upcoming OpenSSL 1.1.0 release disables use of SHA-1, which breaks
> the
> > OVS unit tests, which use SHA-1. We last tried to switch to SHA-512 in
> > 2014 with commit 9ff33ca75e9fcc ("ovs-pki: Use SHA-512 instead of MD5 as
> > message digest."), but we had to downgrade to SHA-1 in commit
> 4a1f9610682d
> > ("ovs-pki: Use SHA-1 instead of SHA-512 as message digest.") because
> > XenServer did not support SHA-512. It has been a few years, so let's try
> > again.
> >
> > CC: 828...@bugs.debian.org
> > Reported-at: https://bugs.debian.org/828478
> > Reported-by: Kurt Roeckx <k...@roeckx.be>
> > Signed-off-by: Ben Pfaff <b...@ovn.org>
> > ---
>
> I'm sorta surprised there's been no action on this...
>
> I admit that I don't have XenServer to test against, but
> if they still aren't supporting SHA-512, then this would be
> another good reason for them to do so...
>
> Acked-by: Ryan Moats <rmo...@us.ibm.com>
Thanks for the review, I applied this to master and branch-2.5.
Now I need to do a new Debian upload.
Bug#828478: [PATCH v2] ovs-pki: Use SHA-512 instead of SHA-1 as message digest.
The upcoming OpenSSL 1.1.0 release disables use of SHA-1, which breaks the
OVS unit tests, which use SHA-1. We last tried to switch to SHA-512 in
2014 with commit 9ff33ca75e9fcc ("ovs-pki: Use SHA-512 instead of MD5 as
message digest."), but we had to downgrade to SHA-1 in commit 4a1f9610682d
("ovs-pki: Use SHA-1 instead of SHA-512 as message digest.") because
XenServer did not support SHA-512. It has been a few years, so let's try
again.
CC: 828...@bugs.debian.org
Reported-at: https://bugs.debian.org/828478
Reported-by: Kurt Roeckx <k...@roeckx.be>
Signed-off-by: Ben Pfaff <b...@ovn.org>
---
v1->v2: Suggested by Kurt Roeckx;
- Use sha512 unconditionally.
- Drop AUTHORS update.
- Add NEWS update.
NEWS | 4
utilities/ovs-pki.in | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/NEWS b/NEWS
index 802e7f8..e7b43d2 100644
--- a/NEWS
+++ b/NEWS
@@ -75,6 +75,10 @@ Post-v2.5.0
watch with tcpdump
- Introduce --no-self-confinement flag that allows daemons to work with
sockets outside their run directory.
+ - ovs-pki: Changed message digest algorithm from SHA-1 to SHA-512 because
+ SHA-1 is no longer secure and some operating systems have started to
+ disable it in OpenSSL.
+
v2.5.0 - 26 Feb 2016
-
diff --git a/utilities/ovs-pki.in b/utilities/ovs-pki.in
index 9b2b5aa..7a992a5 100755
--- a/utilities/ovs-pki.in
+++ b/utilities/ovs-pki.in
@@ -274,7 +274,7 @@ private_key= $dir/private/cakey.pem# CA private key
RANDFILE = $dir/private/.rand# random number file
default_days = 3650 # how long to certify for
default_crl_days= 30 # how long before next CRL
-default_md = sha1 # message digest to use
+default_md = sha512# message digest to use
policy = policy# default policy
email_in_dn= no# Don't add the email into cert DN
name_opt = ca_default# Subject name display option
--
2.1.3
Bug#828478: [PATCH] ovs-pki: Use SHA-512 message digest when available.
On Sun, Jun 26, 2016 at 08:55:04PM +0200, Kurt Roeckx wrote:
> On Sun, Jun 26, 2016 at 11:05:35AM -0700, Ben Pfaff wrote:
> > The upcoming OpenSSL 1.1.0 release disables use of SHA-1, which breaks the
> > OVS unit tests, which use SHA-1. We last tried to switch to SHA-512 in
> > 2014 with commit 9ff33ca75e9fcc ("ovs-pki: Use SHA-512 instead of MD5 as
> > message digest."), but we had to downgrade to SHA-1 in commit 4a1f9610682d
> > ("ovs-pki: Use SHA-1 instead of SHA-512 as message digest.") because
> > XenServer did not support SHA-512.
> >
> > This commit detects support for SHA-512 and uses it if available, so it
> > should avoid the problem encountered previously.
>
> Note that openssl has supported SHA-512 for a while. It's been
> supported since 0.9.8 which was released in 2005. So that support
> detection doesn't look like a good idea.
>
> You indicated that XenServer didn't support it. Did that change?
I don't know.
I guess we could always just try again and see if XenServer folks
complain again.
Honestly I'd prefer to have a fixed choice.
> From what I understand of the log it's that the certificate still
> using a weak digest. I guess we started to rejected SHA-1 by
> default now, which is actually a good thing. The browsers should
> stop supporting it soon too.
>
> I suggest you just switch to SHA-256 or SHA-512 by default.
>
> > diff --git a/AUTHORS b/AUTHORS
> > index 704ba40..a893330 100644
> > --- a/AUTHORS
> > +++ b/AUTHORS
> > @@ -367,6 +367,7 @@ Konstantin Khorenko khore...@openvz.org
> > Kris zhang zhang.k...@gmail.com
> > Krishna Miriyalakris...@nicira.com
> > Krishna Mohan Elluruelluru.kri.mo...@hpe.com
> > +Kurt Roeckx k...@roeckx.be
>
> There really is no reason to add me, it's not like I contributed
> anything, someone else tried to build it and I just filed bugs
> based on that.
OK. I habitually add people who report bugs, since bug reporting is a
kind of public service. I'll drop it for v2.
Thanks,
Ben.
Bug#826780: Please package OVS >= 2.6.0.dev1
On Thu, Jun 09, 2016 at 01:23:12AM +0200, Thomas Goirand wrote: > Source: openvswitch > Version: 2.3.0+git20140819-4 > Severity: normal > > Hi, > > OpenStack Neutron currently has: > > ovs>=2.5.0;python_version=='2.7' # Apache-2.0 > ovs>=2.6.0.dev1;python_version>='3.4' # Apache-2.0 > > in its requirements.txt. Please package this at least to Debian Experimental, > so that I can package Neutron Newton Beta 1. I uploaded openvswitch_2.5.1~pre+git20160626-1 a couple of hours ago. It's going through NEW processing. I suspect that it will take a couple of trial uploads to get the tests to pass reliably and on all architectures. I'm going to be traveling Monday through Thursday, with limited time for computers, so absent helpful NMUs (which are welcome) there will probably be at least limited breakage until Friday. I honestly meant to upload this to experimental for the first one or two tries but screwed up so it's destined for unstable.
Bug#828478: [PATCH] ovs-pki: Use SHA-512 message digest when available.
The upcoming OpenSSL 1.1.0 release disables use of SHA-1, which breaks the
OVS unit tests, which use SHA-1. We last tried to switch to SHA-512 in
2014 with commit 9ff33ca75e9fcc ("ovs-pki: Use SHA-512 instead of MD5 as
message digest."), but we had to downgrade to SHA-1 in commit 4a1f9610682d
("ovs-pki: Use SHA-1 instead of SHA-512 as message digest.") because
XenServer did not support SHA-512.
This commit detects support for SHA-512 and uses it if available, so it
should avoid the problem encountered previously.
CC: 828...@bugs.debian.org
Reported-at: https://bugs.debian.org/828478
Reported-by: Kurt Roeckx <k...@roeckx.be>
Signed-off-by: Ben Pfaff <b...@ovn.org>
---
AUTHORS | 1 +
utilities/ovs-pki.in | 15 +--
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/AUTHORS b/AUTHORS
index 704ba40..a893330 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -367,6 +367,7 @@ Konstantin Khorenko khore...@openvz.org
Kris zhang zhang.k...@gmail.com
Krishna Miriyalakris...@nicira.com
Krishna Mohan Elluruelluru.kri.mo...@hpe.com
+Kurt Roeckx k...@roeckx.be
Len Gao l...@vmware.com
Logan Rosen logatron...@gmail.com
Luca Falavigna dktrkr...@debian.org
diff --git a/utilities/ovs-pki.in b/utilities/ovs-pki.in
index 9b2b5aa..17497a8 100755
--- a/utilities/ovs-pki.in
+++ b/utilities/ovs-pki.in
@@ -248,7 +248,18 @@ if test "$command" = "init"; then
# Write CA configuration file.
if test ! -e ca.cnf; then
-sed "s/@ca@/$ca/g;s/@curr_date@/$curr_date/g" > ca.cnf <<'EOF'
+ if echo | openssl dgst -sha512 >/dev/null 2>&1; then
+ md=sha512
+ elif echo | openssl dgst -sha1 >/dev/null 2>&1; then
+ md=sha1
+ else
+ echo "$0: openssl does not support sha512 or sha1" >&2
+ exit 1
+ fi
+sed "s/@ca@/$ca/g
+s/@curr_date@/$curr_date/g
+s/@md@/$md/g
+" > ca.cnf <<'EOF'
[ req ]
prompt = no
distinguished_name = req_distinguished_name
@@ -274,7 +285,7 @@ private_key= $dir/private/cakey.pem# CA private key
RANDFILE = $dir/private/.rand# random number file
default_days = 3650 # how long to certify for
default_crl_days= 30 # how long before next CRL
-default_md = sha1 # message digest to use
+default_md = @md@ # message digest to use
policy = policy# default policy
email_in_dn= no# Don't add the email into cert DN
name_opt = ca_default# Subject name display option
--
2.1.3
Bug#826780: [ovs-dev] Bug#826780: Please package OVS >= 2.6.0.dev1
On Fri, Jun 10, 2016 at 04:42:11PM -0400, Russell Bryant wrote: > On Fri, Jun 10, 2016 at 4:38 PM, Ben Pfaff <b...@ovn.org> wrote: > > > On Thu, Jun 09, 2016 at 04:07:13AM -0400, Russell Bryant wrote: > > > I uploaded "2.6.0.dev1". This was to enable OpenStack CI to start > > running > > > tests using the version of the Python library that includes Python 3. I > > > followed some python packaging / pypi versioning guidelines to pick that > > > number. It indicates that it's a dev snapshot of what will eventually > > > (presumably) be 2.6.0. I know OVS generates 2.5.90, but I don't find > > that > > > appropriate to use, as it isn't 2.5 at all. > > > > The .90 suffix is supposed to indicate that it's much greater than 2.5, > > but less than 2.6. > > > > dpkg considers 2.6.0.dev1 to be greater than 2.6.0: > > $ if dpkg --compare-versions 2.6.0.dev1 gt 2.6.0; then echo greater; > > else echo less; fi > > greater > > so it seems like a poor choice for anything in Debian. > > > > (I guess you must know the rules for Fedora, so presumably this works > > there? Those rules seem to involve separate Version and Release fields > > and I really don't understand them. On the other hand, according to > > https://www.redhat.com/archives/rpm-list/2005-January/msg5.html, > > developers are discouraged from understanding details of the version > > numbering rules for RPM...) > > This was just a dev snapshot for PyPI (Python Package Index), not intended > to be packaged anywhere else. > > https://www.python.org/dev/peps/pep-0440/ OK, great, I didn't realize that.
Bug#826780: [ovs-dev] Bug#826780: Please package OVS >= 2.6.0.dev1
On Thu, Jun 09, 2016 at 04:07:13AM -0400, Russell Bryant wrote: > I uploaded "2.6.0.dev1". This was to enable OpenStack CI to start running > tests using the version of the Python library that includes Python 3. I > followed some python packaging / pypi versioning guidelines to pick that > number. It indicates that it's a dev snapshot of what will eventually > (presumably) be 2.6.0. I know OVS generates 2.5.90, but I don't find that > appropriate to use, as it isn't 2.5 at all. The .90 suffix is supposed to indicate that it's much greater than 2.5, but less than 2.6. dpkg considers 2.6.0.dev1 to be greater than 2.6.0: $ if dpkg --compare-versions 2.6.0.dev1 gt 2.6.0; then echo greater; else echo less; fi greater so it seems like a poor choice for anything in Debian. (I guess you must know the rules for Fedora, so presumably this works there? Those rules seem to involve separate Version and Release fields and I really don't understand them. On the other hand, according to https://www.redhat.com/archives/rpm-list/2005-January/msg5.html, developers are discouraged from understanding details of the version numbering rules for RPM...)
Bug#826780: Please package OVS >= 2.6.0.dev1
On Thu, Jun 09, 2016 at 01:23:12AM +0200, Thomas Goirand wrote: > Source: openvswitch > Version: 2.3.0+git20140819-4 > Severity: normal > > Hi, > > OpenStack Neutron currently has: > > ovs>=2.5.0;python_version=='2.7' # Apache-2.0 > ovs>=2.6.0.dev1;python_version>='3.4' # Apache-2.0 > > in its requirements.txt. Please package this at least to Debian Experimental, > so that I can package Neutron Newton Beta 1. I can package 2.5.x, though there are reports that there's one testsuite failure on big-endian architectures. OVS 2.6.0 doesn't exist yet, so it can't be packaged. When Neutron asks for 2.6.0 what does it mean?
Bug#818855: autoscan: unescaped left brace regex deprecation warning from perl
On Mon, Mar 21, 2016 at 10:32:25AM +0800, Paul Wise wrote:
> Package: autoconf
> Version: 2.69-9
> Severity: minor
> File: /usr/bin/autoscan
>
> Whenever I run autoscan I get this warning:
>
> Unescaped left brace in regex is deprecated, passed through in regex; marked
> by <-- HERE in m/\${ <-- HERE [^\}]*}/ at /usr/bin/autoscan line 361.
Thanks for the report.
I didn't see this while running autoscan on GNU Hello, but the fix
seemed obvious, so I uploaded it as 2.69-10. If that doesn't fix the
problem, please let me know and I'll look deeper.
Thanks,
Ben.
Bug#801885: autoconf2.13: Package contains /usr/share/man/man1/ChangeLog.1.gz if built under certain locales
On Thu, Oct 15, 2015 at 05:27:00PM +, Santiago Vila wrote: > Ooops! Sorry, didn't test it well enough. > > This seems to work: > > export LC_ALL=C && cp [a-z]*.1 $M Thanks for the report. I decided to fix this by just adding the line "export LC_ALL = C" at the top level of debian/rules, so that everything in debian/rules executes with the C locale. I uploaded a new version of the package.
Bug#796857: pspp: halts when reading sintax file
On Mon, Aug 24, 2015 at 09:36:14PM -0430, alvaro rincon wrote: > Package: pspp > Version: 0.7.9+git20120620-1.1 > Severity: important > > Dear Maintainer, > *** Please consider answering these questions, where appropriate *** > >* What led up to the situation? > > when you run the sintax file > >* What exactly did you do (or not do) that was effective (or > ineffective)? > > changing the sintax stops the problem What syntax file causes the problem?
Bug#759647: runstatedir in autoconf
On Fri, Aug 21, 2015 at 10:28:46AM +0100, Jonathan McDowell wrote: I don't see any sign that autoconf 2.70 is imminent, and I'd quite like to be able to make use of this macro. Any ETA for when it might possibly hit the Debian 2.69 package? Thanks for the reminder. I applied the patch in question to the package and uploaded it as 2.69-9, just now. Please do test it.
Bug#793647: systemd: missing build conflict vs autoconf2.13 - AM_COND_IF: no such condition ARCH_IA32
On Sun, Jul 26, 2015 at 03:30:58AM +0200, Michael Biebl wrote: Am 26.07.2015 um 02:55 schrieb Ben Pfaff: It might be time to remove the autoconf2.13 wrapper, since there is so little software that still uses Autoconf 2.13, but I'd prefer to know more about the bug first. I think so too. Apparently the wrapper is too brittle when it's used in combination with other build tools. I decided that I knew enough that it was time to remove the autoconf wrapper script. I've uploaded a new version of autoconf2.13, 2.13-64, to experimental. I would upload it to unstable, instead, except that I'm leaving Tuesday on a 2-week vacation and it seems irresponsible to make a major change and then leave without being able to immediately mop up any bugs that it causes. Anyway, please do feel free to take a look at it and let me know if you have any concerns. After I get back from vacation I'll contact the maintainers of packages that build-depend on autoconf2.13 and make sure they're aware of the impending change, and then I'll upload the new version to unstable. 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#793647: systemd: missing build conflict vs autoconf2.13 - AM_COND_IF: no such condition ARCH_IA32
On Sun, Jul 26, 2015 at 01:25:03AM +0200, Michael Biebl wrote: Am 25.07.2015 um 23:45 schrieb Alban Browaeys: Package: systemd Version: 222-2 Severity: normal Dear Maintainer, Building systemd from package source, on arm 32 bits, I get : configure.ac:1135: error: AM_COND_IF: no such condition ARCH_IA32 /usr/share/aclocal-1.15/cond-if.m4:23: AM_COND_IF is expanded from... configure.ac:1135: the top level autom4te: /usr/bin/m4 failed with exit status: 1 aclocal: error: echo failed with exit status: 1 autoreconf: aclocal failed with exit status: 1 debian/rules:257: recipe for target 'autoreconf' failed make[2]: *** [autoreconf] Error 1 make[2]: Leaving directory '/home/prahal/Projects/Admin/systemd-222' dh_autoreconf: debian/rules autoreconf returned exit code 2 debian/rules:261: recipe for target 'override_dh_autoreconf' failed make[1]: *** [override_dh_autoreconf] Error 2 make[1]: Leaving directory '/home/prahal/Projects/Admin/systemd-222' debian/rules:281: recipe for target 'build' failed make: *** [build] Error 2 From similar issue against gummiboot : https:bugs.debian.org/cgi-bin/bugreport.cgi?bug=754911 there is a missing conflict with autoconf2.13. I'm not convinced this makes sense. My gut feeling is, that we have several thousand source packages which have AC_PREREQ([2.50]) in the archive and many packages nowadays run autoreconf during build [1]. Adding a Build-Conflicts against autconf2.13 to all of those packages seems like busy work without real gain. I think, autoconf2.13 should stop diverting /usr/bin/autoconf and related binaries (autoheader, autoreconf). dak finds only 14 packages which require autoconf2.13. It makes much more sense to me, if those packages are updated to call /usr/bin/autoconf2.13 directly. CCed the autoconf2.13 maintainer for their input. The wrapper in the autoconf2.13 package is supposed to automatically determine which version of Autoconf is necessary. I see a bug, however, which makes it fail to do that correctly with gummiboot. I can fix that, but I can't reproduce the same problem with systemd. With gummiboot, I just had to type autoreconf -f -i to get the error reported in bug #754911. I don't see that error, though, when I do the same with systemd (or if I run dpkg-buildpackage). Alban or Michael, how do you see the problem? (I tested against a slightly older systemd version, 215-17+deb8u1, not version 222-2. If there's been some important change since then, let me know, and I'll retest.) It might be time to remove the autoconf2.13 wrapper, since there is so little software that still uses Autoconf 2.13, but I'd prefer to know more about the bug first. 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#782584: openvswitch: NDP is dropped
On Tue, Apr 14, 2015 at 03:45:12PM +0200, Mikael Frykholm wrote: Package: openvswitch-common Version: 2.3.0+git20140819-3 Severity: important File: openvswitch Tags: ipv6 Dear Maintainer, * What led up to the situation? Virtual machine running in libvirt stops respoding on the network ip -6 neigh do not show the expected neighbours I reverted to old bridge via brctl and it worked again. This seems related: http://openvswitch.org/pipermail/dev/2014-July/042548.html Thanks for the report. Debian is currently in a freeze, so this bug cannot be fixed until Jessie is released (see https://release.debian.org/jessie/freeze_policy.html). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#776559: autoupdate: add option that reports needed updates to configure.ac
The following feature request was reported against the Debian packaging for Autoconf as bug #776559. I'm forwarding it to the autoconf mailing list in case anyone wants to comment or implement this feature request. I'd appreciate it if followups would retain the CC to 776...@bugs.debian.org, because that allows the Debian bug tracker to automatically track the conversation. Thanks, Ben. - Forwarded message from Paul Wise p...@debian.org - Date: Thu, 29 Jan 2015 17:43:19 +0800 From: Paul Wise p...@debian.org To: Debian Bug Tracking System sub...@bugs.debian.org Subject: Bug#776559: autoupdate: add option that reports needed updates to configure.ac X-Mailer: Evolution 3.12.9-1+b1 Package: autoconf Severity: wishlist File: /usr/bin/autoupdate Usertags: check-all-the-things I would like to have an option for autoupdate that doesn't modify configure.ac but instead reports the needed changes to stdout. This is needed to non-destructively report that configure.ac needs updating. In addition it should use a temporary directory for autom4te.cache/ so that the existing one if any doesn't get modified. The context is that I'm working on a tool to check all of the files in a source package and I would like to check the autotools parts too. https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git -- bye, pabs https://wiki.debian.org/PaulWise - 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#763428: test with kernel 3.18.4
Did you mean to reassign this bug to linux-image-3.16-0-4-amd64? To do so, you must CC cont...@bugs.debian.org and put the command at the top of the email, not the bottom. On Wed, Jan 28, 2015 at 06:20:09PM +0100, Mehdi Abaakouk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I have retested with kernel 3.18.4, and now it works again. I have dig into changelogs since the latest kernel I have tested, and the only relevant change around ixgbe and ovs I have found is https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=927a171886e895b174ed99a06d31fc05bc03750e Cheers, reassign 763428 linux-image-3.16.0-4-amd64 - -- Mehdi Abaakouk mail: sil...@sileht.net irc: sileht -BEGIN PGP SIGNATURE- Version: OpenPGP.js v.1.20131017 Comment: http://openpgpjs.org wsFcBAEBCAAQBQJUyRpJCRAYkrQvzqrryAAAZkoP/RcX9I081zu2abbDHTIc R8JnVmEutaf4hgSdr4RbeKlrNq0MFSbLgaVHBi65EomyQ4J1fKSL2u+k/7sx tTyF0ldrTYcFmxHAvZwkRsSVHHJ1dnGZBADUX8nGgPLiaVgxFaJlVeYbSTay CvolIgikxsMam78H1WLBJ9EHo6xuB4zfxBsUwAmBwf07a7aiQUkvGy3IQshw DbBDkYCTHtvaoiM/UdbEq2kpDovhAQyU5PPUVHwSineA1EkPV+ojS76wczT5 W1rzunB79Dia0WiCsM/3Dv9jzXaj6sqta9hKkuzzaX0VroyR0UhEBMv6U66H MeczxeiVJAg3WiYv0Q57ilMaZpfU1kVo10zSv25UDsA0LitYvkCOtXQXN7rC 0OpmXRKzkkAa8RKO3Rp0dBnQiLF/0VKnzK31hZsd4UuPqXen5XRMYSAWoh6S 5+ElFCgjBO15ScgJL7y1If0THYps0Cu7bnvMjr0Ue8sU4YAgTz7eaTxGhjlc Zw0foecEf0MAVeI/AojbBCPbLFuPZDBKna+MtNKP0OsuuFMPonH2a9f4D3Tz zsJuJzKBslS7IzYuu9XVNJobgjukA2hYjW31tM5xOkeSTcNe9OuC9Gxbi4jd jIeO/1Jiw086xscYcNwl8+QIf3fd9wdo6mafmbw8WIgJkD3Z6haEi+UnMd47 ST0F =MReY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771507: openvswitch-switch: missing systemd files
On Sun, Nov 30, 2014 at 05:53:17AM -0500, westlake wrote: Package: openvswitch-switch Version: 2.3.90-1 Severity: important openvswitch is missing systemd files in order for other network services to work. over here ssh would not bind to an address unless ovs has been started prior. please fix No version 2.3.90-1 or any similar version is in Debian. What version are you using? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#48123: wont fix this 15-year-old bug
tags 48123 + wontfix thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768095: openvswitch-datapath-dkms fails to build on Debian 7.7 3.2.0-4-amd64 (3.2.63-2+deb7u1)
On Mon, Nov 17, 2014 at 04:38:27PM +0100, Jonathan Dupart wrote: Hi, I have been bittend by this bug. I am raising this bug severity to grave, as it renders openvswitch unusable after upgrading to the last stable kernel. I tested the patch and it works flawlessly. It should be quite easy to update the package in stable. I'm quite busy this week. I would be grateful for an NMU. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764847: openvswitch-switch: tuntap issues (commands)
On Sat, Oct 11, 2014 at 11:24:19AM -0400, westlake wrote: Package: openvswitch-switch Version: 2.3.0+git20140819-2 Severity: important (I gave a previous message containing a link to the thread http://openvswitch.org/pipermail/discuss/2011-October/005914.html , but over here in Debian, the device creates half-way) ovs-vsctl add-port bridge name tap dev -- set Interface tap dev type=tap ifconfig -a , would show it is created and in the down state applying, ip link set tap device up, ten starting a kvm reveals.. dev/net/tun (tap device): Device or resource busy So the tap device gets created half-way.. You filed this as a second bug report. Was this meant as additional information for your first bug report (#764843)? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764843: openvswitch-switch: tuntap creation failure
On Sat, Oct 11, 2014 at 11:12:32AM -0400, westlake wrote: Package: openvswitch Version: 2.3.0+git20140819-2 Severity: important http://openvswitch.org/pipermail/discuss/2011-October/005922.html An old bug is lingering somewhere in this latest edition.. Either it is recursive or something else is causing it. Can you provide an actual bug report? So far, all I have is that you think there's a bug related to tap devices, and a link to a report from 2011 about tap devices. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763428: [ovs-dev] Bug#763428: openvswitch-switch: openvswitch doesn't work anymore since kernel 3.16 update
On Mon, Oct 13, 2014 at 10:47:19AM +0200, Laurent GUERBY wrote: On Wed, 8 Oct 2014 13:02:42 -0700 Ben Pfaff b...@nicira.com wrote: I can't reproduce this problem with OVS master and upstream kernel 3.16, or with OVS branch-2.3 on the commit from which the Debian packages were made. Now I'm downloading a Debian ISO so that I can try it with the exact kernel and OVS packaging against which the bug was reported. Did you manage to reproduce the bug with debian ISO? OVS also works OK for me with linux-image-3.16-2-686-pae version 3.16.3-2 and openvswitch-switch 2.3.0+git20140819-2. The configuration I tested was very simple: remove IP address from eth0, create bridge br0 and add eth0 to the bridge, then run dhclient on br0 and verify connectivity. I then verified with ovs-dpctl show and ovs-dpctl dump-flows that traffic was passing through Open vSwitch. With a simple setup like that, does OVS work for you? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763428: openvswitch-switch: openvswitch doesn't work anymore since kernel 3.16 update
On Wed, Oct 08, 2014 at 03:17:56PM +0200, Mehdi Abaakouk wrote: root@g3:/var/lib/openvswitch# /etc/init.d/openvswitch-switch start [ 382.897893] openvswitch: Open vSwitch switching datapath Inserting openvswitch module. /etc/openvswitch/conf.db does not exist ... (warning). Creating empty database /etc/openvswitch/conf.db. Starting ovsdb-server. Configuring Open vSwitch system IDs. Starting ovs-vswitchd. Enabling remote OVSDB managers. root@g3:/var/lib/openvswitch# ovs-vsctl add-br br-eth0 [ 387.549586] device ovs-system entered promiscuous mode [ 387.551218] openvswitch: netlink: Unknown key attribute (type=20, max=19). [ 387.553223] openvswitch: netlink: Unknown key attribute (type=62, max=19). [ 387.568880] device br-eth0 entered promiscuous mode I still have this errors when I create the bridge root@g3:/var/lib/openvswitch# ovs-vsctl add-port br-eth0 eth0 [ 2279.939240] device eth0 entered promiscuous mode None of the above messages indicates an error. root@g3:/var/lib/openvswitch# ip link set eth0 up root@g3:/var/lib/openvswitch# ip link set br-eth0 up # ovs-vsctl show 321f5ebc-adf4-4fe5-ab2c-5ccca143f366 Bridge br-eth0 Port eth0 Interface eth0 Port br-eth0 Interface br-eth0 type: internal ovs_version: 2.3.0 But this bridge doesn't works. I test by just setting a ip on br-eth0 and pinging an other machine on the same lan. OK, that is an indication that something is wrong. With the ping ongoing in the background, run ovs-dpctl dump-flows and show us the output. 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#763428: [ovs-dev] Bug#763428: openvswitch-switch: openvswitch doesn't work anymore since kernel 3.16 update
On Wed, Oct 08, 2014 at 08:20:25AM -0700, Madhu Challa wrote: When I was testing this with 3.17 I had seen similar errors. It was because the kernel module loaded was the one that came with 3.17 kernel and not the one I compiled with the latest ovs. I remember they get installed in different locations. Could you pl check your /lib/modules directory and make sure the right module is getting loaded. OVS should work with any version of the kernel module. If it doesn't, that's a serious bug (and please report it if you see evidence of it happening). I'll take a look at this myself later today. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763428: [ovs-dev] Bug#763428: Bug#763428: openvswitch-switch: openvswitch doesn't work anymore since kernel 3.16 update
On Wed, Oct 08, 2014 at 11:51:25AM -0700, Madhu Challa wrote: I tried the latest ovs with linux-next openvswitch.ko and the one from latest ovs. I see no errors in when I use the driver from latest ovs. When I use the in kernel driver I see this error : [ 2497.408140] openvswitch: netlink: Key attribute has unexpected length (type=21, length=4, expected=0). when adding the bridge. And this is because in the latest ovs attr 21 is OVS_KEY_ATTR_MPLS This is an expected message. It does not indicate a problem. It is suppressed on recent master via a special attribute. whereas with the openvswitch.ko coming from linux-next attr 21 is OVS_KEY_ATTR_TUNNEL_INFO. Note that in the latest ovs attr OVS_KEY_ATTR_TUNNEL_INFO is changed to 22. OVS_KEY_ATTR_TUNNEL_INFO is only used within the kernel module. It's not exported to userspace. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763428: [ovs-dev] Bug#763428: openvswitch-switch: openvswitch doesn't work anymore since kernel 3.16 update
I can't reproduce this problem with OVS master and upstream kernel 3.16, or with OVS branch-2.3 on the commit from which the Debian packages were made. Now I'm downloading a Debian ISO so that I can try it with the exact kernel and OVS packaging against which the bug was reported. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763428: openvswitch-switch: openvswitch doesn't work anymore since kernel 3.16 update
On Tue, Sep 30, 2014 at 10:20:31AM +0200, Mehdi Abaakouk wrote: Package: openvswitch-switch Version: 2.3.0+git20140819-2 Severity: important Since the update of kernel in jessie to 3.16, my openvswitch setups won't work anymore, I have to keep the kernel 3.14 to have openvswitch working. That isn't a very helpful bug report, can you please give us more information? Open vSwitch should work fine with Linux 3.16, using the kernel module that accompanies the kernel. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686518: network_interfaces() does not work with systemd
On Thu, Sep 11, 2014 at 01:04:57PM +0200, Philipp S. Schmidt wrote:
It seems that most of the problem is fixed in the recent version
as ifup --allow=ovs [bridges?]? is called in the network_interfaces()
function.
Sadly, when using systems, this function just return and does not
execute ifup as ${RUNLEVEL} is not set.
I have no idea what purpose the line [ -z ${RUNLEVEL} ] return?
in network_interfaces has, but it prevents this bug from being fixed
when systemd is used as init :(
Guru sent out a proposed fix:
http://openvswitch.org/pipermail/dev/2014-September/045570.html
Can you try this and see whether it solves the problem?
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#760841: pspp: random testsuite failures
On Mon, Sep 08, 2014 at 02:49:46PM +0100, Steven Chamberlain wrote:
retitle 760841 pspp: random testsuite failures
thanks
Affects GNU/Linux too! It's odd the issue has only been seen yet on
kfreebsd rather than linux buildds; I reproduced it on linux-amd64, and
with similar ~2% probability:
~/pspp-0.8.3$ for i in $(seq 1 1000) ; do printf
'e\0n\0t\0r\0\351\0e\0\n\0' | tests/libpspp/u8-istream-test read - Auto |
xxd ; done | sort | uniq -c | sort -bn
21 000: 6500 6e00 7400 7200 c3a9 0065 000a 00e.n.t.re...
979 000: 656e 7472 c3a9 650a entr..e.
For sanity, I've checked that printf is working correctly:
~/pspp-0.8.3$ for i in $(seq 1 1000) ; do printf
'e\0n\0t\0r\0\351\0e\0\n\0' | xxd ; done | sort | uniq -c | sort -bn
1000 000: 6500 6e00 7400 7200 e900 6500 0a00 e.n.t.r...e...
So it may be related to how the tests/libpspp/u8-istream-test program
does its reads from stdin? I'm also curious why the read is truncated
only sometimes - possibly a glibc issue there?
Thanks for the analysis.
This is a PSPP bug in the library that u8-istream-test uses. I pushed
the following fix to the PSPP upstream repository. Friedrich, do you
want to apply that to the PSPP packaging? I'll sponsor the upload for
you.
Thanks,
Ben.
--8--cut here--8--
From: Ben Pfaff b...@cs.stanford.edu
Date: Tue, 9 Sep 2014 08:51:44 -0700
Subject: [PATCH] u8-istream: Fix handling of partial reads.
The u8-istream code did not retry upon a partial read, assuming that that
was the end of the file. When the partial read was shorter than
ENCODING_GUESS_MIN, this could cause the encoding guesser, in turn, to
guess the wrong encoding (especially if the encoding was really UTF-16 and
the partial read was an odd number of bytes).
Reported at https://bugs.debian.org/760841.
Reported by Friedrich Beckmann and Steven Chamberlain.
---
src/libpspp/u8-istream.c| 20 ++--
tests/libpspp/u8-istream.at | 4 +++-
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/src/libpspp/u8-istream.c b/src/libpspp/u8-istream.c
index 2486ca1..6347a67 100644
--- a/src/libpspp/u8-istream.c
+++ b/src/libpspp/u8-istream.c
@@ -1,5 +1,5 @@
/* PSPP - a program for statistical analysis.
- Copyright (C) 2010, 2011, 2012, 2013 Free Software Foundation, Inc.
+ Copyright (C) 2010, 2011, 2012, 2013, 2014 Free Software Foundation, Inc.
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@@ -203,14 +203,22 @@ fill_buffer (struct u8_istream *is)
is-head = is-buffer;
/* Read more input. */
+ n = 0;
do
{
- n = read (is-fd, is-buffer + is-length,
-U8_ISTREAM_BUFFER_SIZE - is-length);
+ ssize_t retval = read (is-fd, is-buffer + is-length,
+ U8_ISTREAM_BUFFER_SIZE - is-length);
+ if (retval 0)
+{
+ n += retval;
+ is-length += retval;
+}
+ else if (retval == 0)
+return n;
+ else if (errno != EINTR)
+return n 0 ? n : -1;
}
- while (n 0 errno == EINTR);
- if (n 0)
-is-length += n;
+ while (is-length U8_ISTREAM_BUFFER_SIZE);
return n;
}
diff --git a/tests/libpspp/u8-istream.at b/tests/libpspp/u8-istream.at
index 24af08c..5b5b4e0 100644
--- a/tests/libpspp/u8-istream.at
+++ b/tests/libpspp/u8-istream.at
@@ -140,7 +140,9 @@ AT_CLEANUP
AT_SETUP([read UTF-16 as Auto])
AT_KEYWORDS([u8_istream])
AT_CHECK([i18n-test supports_encodings UTF-16 UTF-16BE UTF-16LE])
-AT_CHECK([printf '\0e\0n\0t\0r\0\351\0e\0\n' | u8-istream-test read - Auto],
+dnl The sleep 1 checks for a bug in which u8-istream did not properly
+dnl handle receiving data in multiple chunks.
+AT_CHECK([{ printf '\0e\0n\0t\0'; sleep 1; printf 'r\0\351\0e\0\n'; } |
u8-istream-test read - Auto],
[0], [entr??e
])
AT_CHECK([printf 'e\0n\0t\0r\0\351\0e\0\n\0' | u8-istream-test read - Auto],
--
1.9.1
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759647: autoconf: please support configure --runstatedir
On Thu, Sep 04, 2014 at 08:14:28PM -0400, Benjamin Kaduk wrote: On Sun, 31 Aug 2014, Ben Pfaff wrote: On Fri, Aug 29, 2014 at 12:25:33AM -0400, Benjamin Kaduk wrote: Package: autoconf Version: 2.69-7 Severity: wishlist Upstream autoconf has introduced the ability to set runstatedir with an argument to configure, for the 2.70 release. I would like to use this feature for krb5, to put a socket used at runtime in /run instead of /etc/. It looks like Autoconf 2.70 is not yet released. I am nervous, in any case, about upgrading Debian is a whole new version of Autoconf at this stage in the release. I don't think I was intending to suggest a wholesale upgrade, rather that we investigate applying a patch to the Debian package. Have you taken a look at what patches would be required to add just this feature to Autoconf 2.69? If they are small, then it might be appropriate to apply just those patches to the Debian package. I had not previously looked, but it appears to be just a single commit, http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=a197431414088a417b407b9b20583b2e8f7363bd It looks low-risk to me, and I agree that it is potentially beneficial. I will plan to apply this to the Debian package for 2.69. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759647: autoconf: please support configure --runstatedir
On Fri, Aug 29, 2014 at 12:25:33AM -0400, Benjamin Kaduk wrote: Package: autoconf Version: 2.69-7 Severity: wishlist Upstream autoconf has introduced the ability to set runstatedir with an argument to configure, for the 2.70 release. I would like to use this feature for krb5, to put a socket used at runtime in /run instead of /etc/. It looks like Autoconf 2.70 is not yet released. I am nervous, in any case, about upgrading Debian is a whole new version of Autoconf at this stage in the release. Have you taken a look at what patches would be required to add just this feature to Autoconf 2.69? If they are small, then it might be appropriate to apply just those patches to the Debian package. 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#750252: autoconf: FTBFS: error: pdfetex (file cm-super-t1.enc): cannot open encoding file for reading
On Mon, Jun 02, 2014 at 08:32:05PM +0200, David Su??rez wrote: Source: autoconf Version: 2.69-6 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20140601 qa-ftbfs Justification: FTBFS on amd64 ... !pdfTeX error: pdfetex (file cm-super-t1.enc): cannot open encoding file for re ading == Fatal error occurred, no output PDF file produced! /usr/bin/texi2dvi: pdfetex exited with bad status, quitting. make[3]: *** [autoconf.pdf] Error 1 The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2014/06/01/autoconf_2.69-6_unstable.log I don't really understand this bug. The autoconf package source doesn't mention such a file cm-super-t1.enc, and the error doesn't occur in clean pbuilder builds on my own machine. Nevertheless, I guess that the problem is a missing font. It seems that adding a dependency on cm-super will pull in cm-super-minimal, which contains cm-super-t1.enc. I'll add that dependency and mark the bug as closed (since that ought to at least fix the proximate cause of the bug). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757761: [ovs-dev] [PATCH v2] test-controller: Rename to ovs-testcontroller, again install.
On Fri, Aug 22, 2014 at 04:31:11PM -0700, Justin Pettit wrote: On Fri, Aug 15, 2014 at 10:28 AM, Ben Pfaff b...@nicira.com wrote: diff --git a/NEWS b/NEWS index 1ea7bda..656f750 100644 --- a/NEWS +++ b/NEWS @@ -17,6 +17,9 @@ Post-v2.3.0 * OpenFlow 1.5 (draft) Copy-Field action is now supported. * OpenFlow 1.3+ table features requests are now supported (read-only). * Nicira extension move actions may now be included in action sets. + - test-controller has been rename ovs-testcontroller at request of users s/rename/renamed Thanks, fixed. v2.3.0 - 14 Aug 2014 diff --git a/README b/README index fa41c16..0e034ef 100644 --- a/README +++ b/README @@ -72,6 +72,9 @@ Open vSwitch also provides some tools: * ovs-pki, a utility for creating and managing the public-key infrastructure for OpenFlow switches. +* ovs-testcontroller, a simple OpenFlow controller that is useful + for testing (though not for production). If you want to dissuade people, do you want to use language such as may be useful? Thanks. I switched to that wording. Otherwise: Acked-by: Justin Pettit jpet...@nicira.com Thanks, I'll test this and push it in a few minutes. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757761: Bug #757761 -- needed for jessie?
Is your mininet packaging targeted at jessie? That is, do you need ovs-testcontroller in jessie or just in jessie+1? It makes a difference because jessie will have Open vSwitch 2.3, but the ovs-testcontroller change will only be in 2.4, and I do not want to backport the change to 2.3 unless I really need to. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757761: [ovs-dev] [PATCH] test-controller: Rename to ovs-testcontroller, again install.
On Thu, Aug 14, 2014 at 12:59:05PM -0700, Justin Pettit wrote: On August 14, 2014 at 11:16:51 AM, Ben Pfaff (b...@nicira.com) wrote: diff --git a/FAQ b/FAQ index 3470983..7fbf9a9 100644 --- a/FAQ +++ b/FAQ @@ -89,9 +89,10 @@ A: Distributed vswitch applications (e.g., VMware vNetwork distributed environments: OpenFlow, which exposes flow-based forwarding state, and the OVSDB management protocol, which exposes switch port state. In addition to the switch implementation itself, Open vSwitch - includes tools (ovs-ofctl, ovs-vsctl) that developers can script and - extend to provide distributed vswitch capabilities that are closely - integrated with their virtualization management platform. + includes tools (ovs-ofctl, ovs-vsctl, ovs-appctl) that developers Did you mean to introduce ovs-appctl in this patch? ??It seems unrelated. Dropped. +# Short-Description: Simple OpenFLow controller for testing The L in OpenFlow is mistakenly capitalized. Oops, fixed. diff --git a/lib/ssl-bootstrap.man b/lib/ssl-bootstrap.man index c112f9a..37ed791 100644 --- a/lib/ssl-bootstrap.man +++ b/lib/ssl-bootstrap.man @@ -14,7 +14,9 @@ for bootstrapping. .IP This option is only useful if the SSL peer sends its CA certificate as part of the SSL certificate chain. The SSL protocol does not require -the server to send the CA certificate. +the server to send the CA certificate, but +\fB\*(SN\fR(8) can be configured to do so with the +\fB\-\-peer\-ca\-cert\fR option. .IP This option is mutually exclusive with \fB\-C\fR and \fB\-\-ca\-cert\fR. Did you mean to include this patch? ??It also seems unrelated. Dropped. I'm not sure what happened--this started out as a revert of the commit that renamed ovs-controller to test-controller. Something odd got mixed in, not sure what. +utilities/ovs-controller.8: \ + utilities/ovs-controller.8.in \ Should these references to ovs-controller be here? That's a generated file. I'll fix it. diff --git a/ovsdb/ovsdb-client.1.in b/ovsdb/ovsdb-client.1.in index fbb7148..5704127 100644 --- a/ovsdb/ovsdb-client.1.in +++ b/ovsdb/ovsdb-client.1.in @@ -8,6 +8,8 @@ .TH ovsdb\-client 1 @VERSION@ Open vSwitch Open vSwitch Manual .\ This program's name: .ds PN ovsdb\-client +.\ SSL peer program's name: +.ds SN ovsdb\-server . .SH NAME ovsdb\-client \- command-line interface to \fBovsdb-server\fR(1) diff --git a/ovsdb/ovsdb-server.1.in b/ovsdb/ovsdb-server.1.in index ec408a6..db0c216 100644 --- a/ovsdb/ovsdb-server.1.in +++ b/ovsdb/ovsdb-server.1.in @@ -7,6 +7,8 @@ .TH ovsdb\-server 1 @VERSION@ Open vSwitch Open vSwitch Manual .\ This program's name: .ds PN ovsdb\-server +.\ SSL peer program's name: +.ds SN ovsdb\-client . .SH NAME ovsdb\-server \- Open vSwitch database server diff --git a/rhel/openvswitch-fedora.spec.in b/rhel/openvswitch-fedora.spec.in These changes also seem unrelated. Dropped. --- a/utilities/bugtool/ovs-bugtool.in +++ b/utilities/bugtool/ovs-bugtool.in @@ -13,8 +13,8 @@ # License along with this library; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # -# Copyright (c) 2005, 2007 XenSource Ltd. -# Copyright (c) 2010, 2011, 2012, 2013 Nicira, Inc. +# Copyright (c) 2005, 2007, 2014 XenSource Ltd. +# Copyright (c) 2010, 2011, 2012 Nicira, Inc. This removes 2013 from our copyright. I'm going to just drop the ovs-bugtool changes entirely. I don't care about bugtool for a test controller. diff --git a/utilities/ovs-ofctl.8.in b/utilities/ovs-ofctl.8.in index aafda23..989eca4 100644 --- a/utilities/ovs-ofctl.8.in +++ b/utilities/ovs-ofctl.8.in @@ -2162,5 +2162,6 @@ Prints the flow entries in the switch. .SH SEE ALSO . .BR ovs\-appctl (8), +.BR ovs\-controller (8), I assume this should be ovs\-testcontroller. I think I'll just drop that. I don't want lots of references to a test controller. .BR ovs\-vswitchd (8) .BR ovs\-vswitchd.conf.db (8) diff --git a/utilities/ovs-pki.8.in b/utilities/ovs-pki.8.in index 9c3019b..6d042b4 100644 --- a/utilities/ovs-pki.8.in +++ b/utilities/ovs-pki.8.in @@ -236,3 +236,7 @@ Sets the log file to \fIfile\fR. Default: .IP \fB\-h\fR .IQ \fB\-\^\-help\fR Prints a help usage message and exits. + +.SH SEE ALSO + +.BR ovs\-controller (8). Again, I assume this should be ovs\-testcontroller. Dropped. .SH NAME -test\-controller \- simple OpenFlow controller for testing +ovs\-testcontroller \- simple OpenFlow controller for for...testing? Thanks, fixed. \fB% ovs\-vsctl \-t0 \-\-db=pssl: \-\-certificate=cert.pem \-\-ca\-cert=none \-\-private\-key=privkey.pem -\-\-peer\-ca\-cert=cacert.pem set\-controller ssl:\fIip\fR +\-\-peer\-ca\-cert=cacert.pem set\-testcontroller ssl:\fIip\fR I think this should stay as set\-controller. Search and replace strikes again
Bug#757761: [PATCH v2] test-controller: Rename to ovs-testcontroller, again install.
mininet uses the Open vSwitch controller by default, for testing. CC: 757...@bugs.debian.org Reported-at: https://bugs.debian.org/757761 Requested-by: Tomasz Buchert tomasz.buch...@inria.fr Requested-by: Dariusz Dwornikowski dariusz.dwornikow...@cs.put.poznan.pl Signed-off-by: Ben Pfaff b...@nicira.com --- v1-v2: Drop numerous incorrectly included changes. Fix various typos. INSTALL.SSL|8 +- INSTALL.XenServer |2 +- NEWS |3 + README |3 + debian/.gitignore |1 + debian/automake.mk |8 + debian/changelog |5 + debian/control | 17 +- debian/openvswitch-testcontroller.README.Debian| 12 + debian/openvswitch-testcontroller.default | 29 ++ debian/openvswitch-testcontroller.dirs |1 + debian/openvswitch-testcontroller.init | 278 debian/openvswitch-testcontroller.install |1 + debian/openvswitch-testcontroller.manpages |1 + debian/openvswitch-testcontroller.postinst | 60 + debian/openvswitch-testcontroller.postrm | 44 manpages.mk| 40 +-- rhel/openvswitch-fedora.spec.in|2 + rhel/openvswitch.spec.in |4 +- tests/.gitignore |2 - tests/automake.mk |7 - utilities/.gitignore |2 + utilities/automake.mk |7 + .../ovs-testcontroller.8.in| 48 ++-- .../ovs-testcontroller.c |0 xenserver/openvswitch-xen.spec.in |4 +- 26 files changed, 523 insertions(+), 66 deletions(-) create mode 100644 debian/openvswitch-testcontroller.README.Debian create mode 100644 debian/openvswitch-testcontroller.default create mode 100644 debian/openvswitch-testcontroller.dirs create mode 100755 debian/openvswitch-testcontroller.init create mode 100644 debian/openvswitch-testcontroller.install create mode 100644 debian/openvswitch-testcontroller.manpages create mode 100755 debian/openvswitch-testcontroller.postinst create mode 100755 debian/openvswitch-testcontroller.postrm rename tests/test-controller.8.in = utilities/ovs-testcontroller.8.in (77%) rename tests/test-controller.c = utilities/ovs-testcontroller.c (100%) diff --git a/INSTALL.SSL b/INSTALL.SSL index 061af97..a6931d2 100644 --- a/INSTALL.SSL +++ b/INSTALL.SSL @@ -115,10 +115,10 @@ that contains the PKI structure: % ovs-pki req+sign ctl controller ctl-privkey.pem and ctl-cert.pem would need to be copied to the -controller for its use at runtime. If you were to use test-controller, -the simple OpenFlow controller included with Open vSwitch, then the ---private-key and --certificate options, respectively, would point to -these files. +controller for its use at runtime. If, for testing purposes, you were +to use ovs-testcontroller, the simple OpenFlow controller included +with Open vSwitch, then the --private-key and --certificate options, +respectively, would point to these files. It is very important to make sure that no stray copies of ctl-privkey.pem are created, because they could be used to impersonate diff --git a/INSTALL.XenServer b/INSTALL.XenServer index 1e23634..8c07d24 100644 --- a/INSTALL.XenServer +++ b/INSTALL.XenServer @@ -172,7 +172,7 @@ controller on XenServer and, as a consequence of the step above that deletes all of the bridges at boot time, controller configuration only persists until XenServer reboot. The configuration database manager can, however, configure controllers for bridges. See the BUGS section -of test-controller(8) for more information on this topic. +of ovs-testcontroller(8) for more information on this topic. * The Open vSwitch startup script automatically adds a firewall rule to allow GRE traffic. This rule is needed for the XenServer feature diff --git a/NEWS b/NEWS index 1ea7bda..656f750 100644 --- a/NEWS +++ b/NEWS @@ -17,6 +17,9 @@ Post-v2.3.0 * OpenFlow 1.5 (draft) Copy-Field action is now supported. * OpenFlow 1.3+ table features requests are now supported (read-only). * Nicira extension move actions may now be included in action sets. + - test-controller has been rename ovs-testcontroller at request of users + who find it useful for testing basic OpenFlow setups. It is still not + a necessary or desirable part of most Open vSwitch deployments. v2.3.0 - 14 Aug 2014 diff --git a/README b/README index fa41c16..0e034ef 100644 --- a/README +++ b/README @@ -72,6 +72,9 @@ Open vSwitch also provides some tools
Bug#757761: openvswitch-switch: Please include ovsk-controller
On Tue, Aug 12, 2014 at 01:37:07PM +0200, Tomasz Buchert wrote: On 11/08/14 14:28, Ben Pfaff wrote: On Mon, Aug 11, 2014 at 08:17:19PM +0200, Dariusz Dwornikowski wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11.08.2014 17:38, Ben Pfaff wrote: On Mon, Aug 11, 2014 at 09:53:09AM +0200, Dariusz Dwornikowski wrote: Source: openvswitch Severity: wishlist Dear Maintainer, Tomasz Buchert and I are working on introducing mininet, an SDN emulator (http://mininet.org/) to Debian. Mininet heavily depends on ovsk to provide OpenFlow switch but also an OpenFlow controller. Ovsk starting from version 2.1 ships ovsk-controller as test-controller and resides in tests/ directory of the main source. Why can't mininet use a real controller instead of the useless test program from OVS? Mininet is just an emulator, using test controller from OVS makes it easy to start with and use by people who start with OpenFlow and SDNs. Using an OVS controller is one of the major options in mininet, and in fact the default behavior. You can always use external controller with - --remote option in mininet. If we ship mininet package without having OVS controller to use, we will be shipping partially unusable software. I don't understand why the OVS controller is useful. OVS has a larger set of features, and performs better, with no controller, than it does with the test-controller. Why do mininet users want to use ovs-controller instead of no controller at all? mininet users want to see mininet work - I doubt that they care, at least at the beginning, how it works internally. Mininet is basically an OpenFlow testing framework and therefore *always* runs with an OpenFlow controller and hence *always* needs one. Therefore, replacing it with OVS without OF controller is not feasible and probably discouraged by the architecture of mininet. OK. I've proposed to bring it back upstream: http://openvswitch.org/pipermail/dev/2014-August/044113.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757761: [PATCH] test-controller: Rename to ovs-testcontroller, again install.
mininet uses the Open vSwitch controller by default, for testing. CC: 757...@bugs.debian.org Reported-at: https://bugs.debian.org/757761 Requested-by: Tomasz Buchert tomasz.buch...@inria.fr Requested-by: Dariusz Dwornikowski dariusz.dwornikow...@cs.put.poznan.pl Signed-off-by: Ben Pfaff b...@nicira.com --- FAQ| 7 +- INSTALL.SSL| 8 +- INSTALL.XenServer | 2 +- NEWS | 4 +- README | 3 + debian/.gitignore | 1 + debian/automake.mk | 8 + debian/changelog | 5 + debian/control | 17 +- debian/openvswitch-testcontroller.README.Debian| 12 + debian/openvswitch-testcontroller.default | 29 +++ debian/openvswitch-testcontroller.dirs | 1 + debian/openvswitch-testcontroller.init | 278 + debian/openvswitch-testcontroller.install | 1 + debian/openvswitch-testcontroller.manpages | 1 + debian/openvswitch-testcontroller.postinst | 60 + debian/openvswitch-testcontroller.postrm | 44 lib/ssl-bootstrap.man | 4 +- manpages.mk| 38 +-- ovsdb/ovsdb-client.1.in| 2 + ovsdb/ovsdb-server.1.in| 2 + rhel/openvswitch-fedora.spec.in| 2 + rhel/openvswitch.spec.in | 4 +- tests/.gitignore | 2 - tests/automake.mk | 7 - utilities/.gitignore | 2 + utilities/automake.mk | 7 + utilities/bugtool/ovs-bugtool.in | 5 +- utilities/ovs-ofctl.8.in | 1 + utilities/ovs-pki.8.in | 4 + .../ovs-testcontroller.8.in| 50 ++-- .../ovs-testcontroller.c | 0 utilities/ovs-vsctl.8.in | 6 +- vswitchd/ovs-vswitchd.8.in | 2 + vtep/vtep-ctl.8.in | 2 + xenserver/openvswitch-xen.spec.in | 4 +- 36 files changed, 551 insertions(+), 74 deletions(-) create mode 100644 debian/openvswitch-testcontroller.README.Debian create mode 100644 debian/openvswitch-testcontroller.default create mode 100644 debian/openvswitch-testcontroller.dirs create mode 100755 debian/openvswitch-testcontroller.init create mode 100644 debian/openvswitch-testcontroller.install create mode 100644 debian/openvswitch-testcontroller.manpages create mode 100755 debian/openvswitch-testcontroller.postinst create mode 100755 debian/openvswitch-testcontroller.postrm rename tests/test-controller.8.in = utilities/ovs-testcontroller.8.in (76%) rename tests/test-controller.c = utilities/ovs-testcontroller.c (100%) diff --git a/FAQ b/FAQ index 3470983..7fbf9a9 100644 --- a/FAQ +++ b/FAQ @@ -89,9 +89,10 @@ A: Distributed vswitch applications (e.g., VMware vNetwork distributed environments: OpenFlow, which exposes flow-based forwarding state, and the OVSDB management protocol, which exposes switch port state. In addition to the switch implementation itself, Open vSwitch - includes tools (ovs-ofctl, ovs-vsctl) that developers can script and - extend to provide distributed vswitch capabilities that are closely - integrated with their virtualization management platform. + includes tools (ovs-ofctl, ovs-vsctl, ovs-appctl) that developers + can script and extend to provide distributed vswitch capabilities + that are closely integrated with their virtualization management + platform. Q: Why doesn't Open vSwitch support distribution? diff --git a/INSTALL.SSL b/INSTALL.SSL index 061af97..a6931d2 100644 --- a/INSTALL.SSL +++ b/INSTALL.SSL @@ -115,10 +115,10 @@ that contains the PKI structure: % ovs-pki req+sign ctl controller ctl-privkey.pem and ctl-cert.pem would need to be copied to the -controller for its use at runtime. If you were to use test-controller, -the simple OpenFlow controller included with Open vSwitch, then the ---private-key and --certificate options, respectively, would point to -these files. +controller for its use at runtime. If, for testing purposes, you were +to use ovs-testcontroller, the simple OpenFlow controller included +with Open vSwitch, then the --private-key and --certificate options, +respectively, would point to these files. It is very important to make sure that no stray copies of ctl-privkey.pem are created, because they could be used to impersonate diff --git a/INSTALL.XenServer b
Bug#757761: openvswitch-switch: Please include ovsk-controller
On Mon, Aug 11, 2014 at 09:53:09AM +0200, Dariusz Dwornikowski wrote: Source: openvswitch Severity: wishlist Dear Maintainer, Tomasz Buchert and I are working on introducing mininet, an SDN emulator (http://mininet.org/) to Debian. Mininet heavily depends on ovsk to provide OpenFlow switch but also an OpenFlow controller. Ovsk starting from version 2.1 ships ovsk-controller as test-controller and resides in tests/ directory of the main source. From the NEWS of ovsk source: - ovs-controller has been renamed test-controller. It is no longer packaged or installed by default, because too many users assumed incorrectly that ovs-controller was a necessary or desirable part of an Open vSwitch deployment. Why do you keep referring to ovs as ovsk? We have never shipped anything under that name. Why can't mininet use a real controller instead of the useless test program from OVS? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757761: openvswitch-switch: Please include ovsk-controller
On Mon, Aug 11, 2014 at 08:17:19PM +0200, Dariusz Dwornikowski wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11.08.2014 17:38, Ben Pfaff wrote: On Mon, Aug 11, 2014 at 09:53:09AM +0200, Dariusz Dwornikowski wrote: Source: openvswitch Severity: wishlist Dear Maintainer, Tomasz Buchert and I are working on introducing mininet, an SDN emulator (http://mininet.org/) to Debian. Mininet heavily depends on ovsk to provide OpenFlow switch but also an OpenFlow controller. Ovsk starting from version 2.1 ships ovsk-controller as test-controller and resides in tests/ directory of the main source. Why can't mininet use a real controller instead of the useless test program from OVS? Mininet is just an emulator, using test controller from OVS makes it easy to start with and use by people who start with OpenFlow and SDNs. Using an OVS controller is one of the major options in mininet, and in fact the default behavior. You can always use external controller with - --remote option in mininet. If we ship mininet package without having OVS controller to use, we will be shipping partially unusable software. I don't understand why the OVS controller is useful. OVS has a larger set of features, and performs better, with no controller, than it does with the test-controller. Why do mininet users want to use ovs-controller instead of no controller at all? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754268: commandline-specified CFLAGS override -std= parameter from AC_PROG_CC_C99
[resending due to wrong @bugs address in last copy, sorry]
On Wed, Jul 09, 2014 at 09:50:08AM +0200, Wouter Verhelst wrote:
Package: autoconf
Version: 2.69-7
Severity: normal
Hi,
The nbd configure.ac contains:
AC_PROG_CC_C99
because I use a number of C99 constructs in the code. When, however, I
run configure like so:
./configure CFLAGS='-g -O0 -Wall -Werror'
because I want to clean up the code a bit, I get an error message at
compile time:
nbdsrv.c: In function 'getmaskbyte':
nbdsrv.c:116:2: error: 'for' loop initial declarations are only allowed in
C99 or C11 mode
for(int i = 7; i + masklen 7; i--) {
^
which is surprising, since I asked for C99 mode. If I specify CFLAGS so
it also contains '-std=gnu99', then everything compiles cleanly (apart
from the bits that are caused by the -Wall -Werror, that is).
Specifying -Werror in CFLAGS to configure is almost always a mistake.
It screws up Autoconf tests, because some Autoconf tests unavoidably
provoke warnings. Remove -Werror and you'll get better results.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753170: RM: autoconf2.13 -- ROM, NVIU; dead upstream, superseded by autoconf
Package: ftp.debian.org Severity: normal Please remove autoconf2.13. It is long obsolete, superseded by autoconf in 2001. It has no reverse dependencies in unstable (I just uploaded a autoconf 2.69-7 that removes the only one). This request is prompted by the removal of automake1.4, the automake version that was contemporary with the use of Autoconf 2.13. See also bug #752291. perl-base does declare a Breaks: relationship on an old version of autoconf2.13. After autoconf2.13 is removed I will file a bug to get that fixed. (If you prefer, I can file the bug now.) 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#752291: autoconf2.13: recommends automake1.4 which is going away
On Mon, Jun 23, 2014 at 11:00:47PM -0700, Ben Pfaff wrote: On Sun, Jun 22, 2014 at 11:11:05AM +0200, Ansgar Burchardt wrote: Package: autoconf2.13 Version: 2.13-62 Severity: important autoconf2.13 recommends automake1.4 which is going away[1]. [1] https://bugs.debian.org/733705 Thanks. I see that autoconf2.13 has no reverse dependencies. I am inclined to request its removal. Do you (or anyone else) have any objection? I filed bug #753170 requesting removal of autoconf2.13. When that package removal is processed, I believe that it will automatically close this bug (and all bugs assigned to autoconf2.13). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752291: autoconf2.13: recommends automake1.4 which is going away
On Sun, Jun 22, 2014 at 11:11:05AM +0200, Ansgar Burchardt wrote: Package: autoconf2.13 Version: 2.13-62 Severity: important autoconf2.13 recommends automake1.4 which is going away[1]. [1] https://bugs.debian.org/733705 Thanks. I see that autoconf2.13 has no reverse dependencies. I am inclined to request its removal. Do you (or anyone else) have any objection? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701760: [ovs-dev] Bug#701760: [PATCH] debian: Stop openvswitch after VMs managed by libvirt.
On Tue, May 20, 2014 at 10:29:11AM +0900, YAMAMOTO Takashi wrote: On Mon, Mar 31, 2014 at 08:37:48AM -0700, Ben Pfaff wrote: When openvswitch stops before libvirt shuts down VMs, it makes it hard for libvirt to remove virtual network interfaces (ovs-vsctl cannot access the database socket, which has been removed). This commit should ensure that the VMs get shut down before openvswitch. CC: 701...@bugs.debian.org Reported-by: Ernesto Domato edo...@gmail.com Suggested-by: Lukasz Szotek szot...@gmail.com Signed-off-by: Ben Pfaff b...@nicira.com This still needs a review (from ovs-dev). is this still useful? my installation of ubuntu 13.10 doesn't seem to have libvirt-guests. Ansis told me the same thing. It seems package names have changed from the version of libvirt that the reporter uses, to the version of libvirt that is currently in the Debian archive. But Ansis also brought up the point that it might make more sense for libvirt to add this dependency in the reverse direction. I will consult with the libvirt team (probably by reassigning this bug to libvirt with a query). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701760: [ovs-dev] Bug#701760: [PATCH] debian: Stop openvswitch after VMs managed by libvirt.
On Tue, May 20, 2014 at 07:24:35AM -0700, Ben Pfaff wrote: On Tue, May 20, 2014 at 10:29:11AM +0900, YAMAMOTO Takashi wrote: On Mon, Mar 31, 2014 at 08:37:48AM -0700, Ben Pfaff wrote: When openvswitch stops before libvirt shuts down VMs, it makes it hard for libvirt to remove virtual network interfaces (ovs-vsctl cannot access the database socket, which has been removed). This commit should ensure that the VMs get shut down before openvswitch. CC: 701...@bugs.debian.org Reported-by: Ernesto Domato edo...@gmail.com Suggested-by: Lukasz Szotek szot...@gmail.com Signed-off-by: Ben Pfaff b...@nicira.com This still needs a review (from ovs-dev). is this still useful? my installation of ubuntu 13.10 doesn't seem to have libvirt-guests. Ansis told me the same thing. It seems package names have changed from the version of libvirt that the reporter uses, to the version of libvirt that is currently in the Debian archive. Actually, looking at the latest version of libvirt in the Debian archive, version 1.2.4-3, I see that it has /etc/init.d/libvirt-guests, same as previous versions. Ansis and Yamamoto-san, are you aware that the dependencies in these init.d files are the names of init.d scripts, not the names of packages? So I think that this change will have the desired effect, considering Ansis's comment below as a separate topic: But Ansis also brought up the point that it might make more sense for libvirt to add this dependency in the reverse direction. I will consult with the libvirt team (probably by reassigning this bug to libvirt with a query). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701760: [PATCH] debian: Stop openvswitch after VMs managed by libvirt.
On Mon, Mar 31, 2014 at 08:37:48AM -0700, Ben Pfaff wrote: When openvswitch stops before libvirt shuts down VMs, it makes it hard for libvirt to remove virtual network interfaces (ovs-vsctl cannot access the database socket, which has been removed). This commit should ensure that the VMs get shut down before openvswitch. CC: 701...@bugs.debian.org Reported-by: Ernesto Domato edo...@gmail.com Suggested-by: Lukasz Szotek szot...@gmail.com Signed-off-by: Ben Pfaff b...@nicira.com This still needs a review (from ovs-dev). 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#744769: closed by Ben Pfaff pfaff...@debian.org (Bug#744769: fixed in openvswitch 2.1.0+git20140411-2)
No, that's a job for the buildds. On Apr 14, 2014 9:24 AM, Powers, Joshua joshua.pow...@hp.com wrote: Ben, Architecture: source i386 all Will you also be building the amd64 packages? Thanks, Josh
Bug#744136: ovsdbmonitor lacks depends on python-zope.interface and python-twisted-conch
On Thu, Apr 10, 2014 at 05:14:46PM +0200, Santiago wrote: Package: ovsdbmonitor Version: 2.1.0+git20140325-1 Severity: important Hi, ovsdbmonitor requires these two packages to run. Oops. I think the best solution is probably to remove ovsdbmonitor entirely, since it isn't well maintained and I'm not sure it works. It was already removed from OVS master but persists in 2.1. I've started a discussion to remove it from 2.1 also: http://openvswitch.org/pipermail/dev/2014-April/038754.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740983: Bug #740983: use the upstream kernel module instead
severity 740983 normal thanks This bug was submitted with: Severity: grave Justification: renders package unusable because the DKMS module does not build with Linux kernel 3.13. While this is true, it does not render the package unusable by any stretch of the imagination, because Linux kernel 3.13, like every kernel from version 3.3 onward, has a built-in openvswitch kernel module that works perfectly well. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701760: [PATCH] debian: Stop openvswitch after VMs managed by libvirt.
When openvswitch stops before libvirt shuts down VMs, it makes it hard for libvirt to remove virtual network interfaces (ovs-vsctl cannot access the database socket, which has been removed). This commit should ensure that the VMs get shut down before openvswitch. CC: 701...@bugs.debian.org Reported-by: Ernesto Domato edo...@gmail.com Suggested-by: Lukasz Szotek szot...@gmail.com Signed-off-by: Ben Pfaff b...@nicira.com --- AUTHORS| 2 ++ debian/openvswitch-switch.init | 3 ++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/AUTHORS b/AUTHORS index b189957..4945e7d 100644 --- a/AUTHORS +++ b/AUTHORS @@ -164,6 +164,7 @@ Derek Cormier derek.corm...@lab.ntt.co.jp Dhaval Badiani dbadi...@vmware.com DK Moon dkm...@nicira.com Edwin Chiu ec...@nicira.com +Ernesto Domato edo...@gmail.com Eivind Bulie Haanaes Eric Lopez elo...@nicira.com Frido Roose fr.ro...@gmail.com @@ -209,6 +210,7 @@ Len Gao l...@vmware.com Logan Rosen logatron...@gmail.com Luca Falavigna dktrkr...@debian.org Luiz Henrique Ozaki luiz.oz...@gmail.com +Lukasz Szotek szot...@gmail.com Maxime Brun m.b...@alphalink.fr Michael A. Collins mike.a.coll...@ark-net.org Michael Hu m...@nicira.com diff --git a/debian/openvswitch-switch.init b/debian/openvswitch-switch.init index 481b29c..98a69f7 100755 --- a/debian/openvswitch-switch.init +++ b/debian/openvswitch-switch.init @@ -1,6 +1,6 @@ #! /bin/sh # -# Copyright (C) 2011, 2012 Nicira, Inc. +# Copyright (C) 2011, 2012, 2014 Nicira, Inc. # # Licensed under the Apache License, Version 2.0 (the License); # you may not use this file except in compliance with the License. @@ -18,6 +18,7 @@ # Provides: openvswitch-switch # Required-Start:$network $named $remote_fs $syslog # Required-Stop: $remote_fs +# X-Stop-After: libvirt-guests # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Open vSwitch switch -- 1.8.5.3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733696: [PATCH] debian: Depend on 'kmod' instead of module-init-tools.
CC: 733...@bugs.debian.org
Reported-by: m...@linux.it (Marco d'Itri)
Signed-off-by: Ben Pfaff b...@nicira.com
---
AUTHORS| 1 +
debian/control | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/AUTHORS b/AUTHORS
index b189957..e853887 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -209,6 +209,7 @@ Len Gao l...@vmware.com
Logan Rosen logatron...@gmail.com
Luca Falavigna dktrkr...@debian.org
Luiz Henrique Ozaki luiz.oz...@gmail.com
+Marco d'Itrim...@linux.it
Maxime Brun m.b...@alphalink.fr
Michael A. Collins mike.a.coll...@ark-net.org
Michael Hu m...@nicira.com
diff --git a/debian/control b/debian/control
index b3e89df..1aed8e7 100644
--- a/debian/control
+++ b/debian/control
@@ -65,7 +65,7 @@ Description: Open vSwitch common components
Package: openvswitch-switch
Architecture: linux-any
Suggests: openvswitch-datapath-module
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends},
openvswitch-common (= ${binary:Version}), module-init-tools, procps,
uuid-runtime, netbase, python-argparse
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends},
openvswitch-common (= ${binary:Version}), kmod, procps, uuid-runtime, netbase,
python-argparse
Description: Open vSwitch switch implementations
Open vSwitch is a production quality, multilayer, software-based,
Ethernet virtual switch. It is designed to enable massive network
--
1.8.5.3
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733696: [ovs-dev] [PATCH] debian: Depend on 'kmod' instead of module-init-tools.
Thanks, applied to master and branch-2.1.
On Mon, Mar 31, 2014 at 01:29:06PM -0700, Justin Pettit wrote:
Acked-by: Justin Pettit jpet...@nicira.com
--Justin
Ben Pfaff wrote:
CC: 733...@bugs.debian.org
Reported-by: m...@linux.it (Marco d'Itri)
Signed-off-by: Ben Pfaffb...@nicira.com
---
AUTHORS| 1 +
debian/control | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/AUTHORS b/AUTHORS
index b189957..e853887 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -209,6 +209,7 @@ Len Gao l...@vmware.com
Logan Rosen logatron...@gmail.com
Luca Falavigna dktrkr...@debian.org
Luiz Henrique Ozaki luiz.oz...@gmail.com
+Marco d'Itrim...@linux.it
Maxime Brun m.b...@alphalink.fr
Michael A. Collins mike.a.coll...@ark-net.org
Michael Hu m...@nicira.com
diff --git a/debian/control b/debian/control
index b3e89df..1aed8e7 100644
--- a/debian/control
+++ b/debian/control
@@ -65,7 +65,7 @@ Description: Open vSwitch common components
Package: openvswitch-switch
Architecture: linux-any
Suggests: openvswitch-datapath-module
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends},
openvswitch-common (= ${binary:Version}), module-init-tools, procps,
uuid-runtime, netbase, python-argparse
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends},
openvswitch-common (= ${binary:Version}), kmod, procps, uuid-runtime,
netbase, python-argparse
Description: Open vSwitch switch implementations
Open vSwitch is a production quality, multilayer, software-based,
Ethernet virtual switch. It is designed to enable massive network
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738402: autoconf: FTBFS: grep: ecrm1095.log: No such file or directory
reassign 738402 texlive-latex-recommended thanks [...lots of output from texinfo.tex...] kpathsea: Running mktexmf ecrm1095 ! I can't find file `ecrm1095'. * ...ljfour; mag:=1; nonstopmode; input ecrm1095 Please type another input file name ! Emergency stop. * ...ljfour; mag:=1; nonstopmode; input ecrm1095 This bug results from a change from wheezy to jessie that moved the ecrm font family from texlive-latex-recommended to texlive-fonts-recommended. I guess that this is likely to break any package that build-depends on the former and builds PDF for Texinfo documentation. TeXLive maintainers: I assume that this was an unintended consequence that should be fixed globally by moving the ecrm fonts back into texlive-latex-recommended. If not, or if I otherwise misunderstand the situation, please reassign this bug back to autoconf and I'll add texlive-fonts-recommended to the Autoconf build-depends. 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#738451: autoconf: FTBFS: I can't find file `ecrm1095'.
reassign 738451 texlive-latex-recommended merge 738451 738402 thanks On Sun, Feb 09, 2014 at 11:10:13AM -0800, Daniel Schepler wrote: Source: autoconf Version: 2.69-2 Severity: serious Same as #738402, reassigning and merging (with this email). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738402: FTBFS autoconf
On Mon, Feb 10, 2014 at 09:00:09AM +0900, Norbert Preining wrote: Anyway, Ben, it was *not* an unintended consequence. Please adjust the build deps to include texlive-fonts-recommended Thanks for clarifying. I'll upload autoconf with the additional build dependency in a few minutes. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#48123: AC_FUNC_GETPGRP macro is broken
On Tue, Feb 04, 2014 at 12:14:08PM +0100, =?UTF-8?Q?forum wrote: Control: retitle 48123 AC_FUNC_GETPGRP macro is broken with C++ Control: tags 48123 + confirmed Control: thanks indeed. the attached configure.in exposes the problem. when using autoconf2.13 to create the configure-script, it will wrongly detect that getpgrp() requires an argument: checking whether getpgrp takes no argument... no when using autoconf-2.69, this will correctly detect: checking whether getpgrp requires zero arguments... yes It's nice that you confirmed it. However, I doubt confirming a 15-year-old bug in a version of software that has been obsolete for about 14 of those years will prompt anyone to fix it. I hope that you don't really expect any action on this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734104: autoconf: uses old-style function definition, thus fails with -Werror=old-style-definition
On Thu, Jan 09, 2014 at 01:30:25PM +0100, Vincent Lefevre wrote: On 2014-01-08 21:55:56 -0800, Ben Pfaff wrote: On Wed, Jan 08, 2014 at 09:44:20AM +0100, Vincent Lefevre wrote: On 2014-01-07 21:30:29 -0800, Ben Pfaff wrote: On Fri, Jan 03, 2014 at 10:22:27PM +0100, Vincent Lefevre wrote: I suggest adding such flags after configure tests have been run, as with the --enable-Werror configure flag supported by Open vSwitch: dnl OVS_ENABLE_WERROR AC_DEFUN([OVS_ENABLE_WERROR], [AC_ARG_ENABLE( [Werror], [AC_HELP_STRING([--enable-Werror], [Add -Werror to CFLAGS])], [], [enable_Werror=no]) AC_CONFIG_COMMANDS_PRE( [if test X$enable_Werror = Xyes; then CFLAGS=$CFLAGS -Werror fi])]) This doesn't solve the problem at all: whether -Werror is used via --enable-Werror or via ./configure ... CFLAGS=... -Werror the same errors will occur. No, configuration time errors will not occur with this macro, because this macro adds -Werror only after all of the configuration tests have already run. Some configure tests *must* be done with the same options as the compilation, so that some features in the program or the tests can be disabled (via the preprocessor) if they are not supported due to the use of -Werror. What's an example? I guess that -Werror=old-style-definition is somewhat more restricted, but a similar solution can be used. Actually I wasn't using -Werror=old-style-definition directly, but ./configure CFLAGS=-Wall -Wold-style-declaration -Wold-style-definition -Wmissing-parameter-type -Wmissing-prototypes -Wmissing-declarations -Wmissing-field-initializers -Werror If you did the same thing but dropped -Werror from CFLAGS and added --enable-Werror, there would be no problem with configuration tests. But the build (of the software or the tests) could fail due to a feature that should have been disabled by an error detected with -Werror at configure time. I can't think of any example, can you please explain? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734104: autoconf: uses old-style function definition, thus fails with -Werror=old-style-definition
On Fri, Jan 10, 2014 at 03:32:12AM +0100, Vincent Lefevre wrote: On 2014-01-09 09:04:02 -0800, Ben Pfaff wrote: On Thu, Jan 09, 2014 at 01:30:25PM +0100, Vincent Lefevre wrote: Some configure tests *must* be done with the same options as the compilation, so that some features in the program or the tests can be disabled (via the preprocessor) if they are not supported due to the use of -Werror. What's an example? Building MPFR trunk succeeds with $ ./configure CC=gcc-snapshot CFLAGS=-Wall -pedantic $ make and $ ./configure CC=gcc-snapshot CFLAGS=-Wall -pedantic -Werror $ make but fails with: $ ./configure --enable-Werror CC=gcc-snapshot CFLAGS=-Wall -pedantic $ make Threading support is checked at configure time. It is not supported with -pedantic -Werror (due to use of extensions). If -Werror is used at build time but not at configure time, the configure script will detect that threading is supported (due to the missing -Werror), though actually it isn't, so that the build fails. So threading is supported with -pedantic but yields warnings? Then I'd want the build to fail with -Werror, exactly so that I can fix the warnings. I don't see a problem here. In my opinion, -Werror is a developer tool, not a mode for building. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734104: autoconf: uses old-style function definition, thus fails with -Werror=old-style-definition
On Wed, Jan 08, 2014 at 09:44:20AM +0100, Vincent Lefevre wrote: On 2014-01-07 21:30:29 -0800, Ben Pfaff wrote: On Fri, Jan 03, 2014 at 10:22:27PM +0100, Vincent Lefevre wrote: A developer may want to test his software with -Werror=old-style-definition (in particular because such definitions could be a real bug in the software). But configure fails because autoconf generates such a function definition. For instance: In my opinion, it's a mistake to run configure tests with -Werror. I don't see why. As compilers evolve, they will inevitably come to issue new warnings, some of which will be triggered by configure tests. Authors of Autoconf tests cannot possibly write them to avoid all warnings issued by future versions of GCC. I suggest adding such flags after configure tests have been run, as with the --enable-Werror configure flag supported by Open vSwitch: dnl OVS_ENABLE_WERROR AC_DEFUN([OVS_ENABLE_WERROR], [AC_ARG_ENABLE( [Werror], [AC_HELP_STRING([--enable-Werror], [Add -Werror to CFLAGS])], [], [enable_Werror=no]) AC_CONFIG_COMMANDS_PRE( [if test X$enable_Werror = Xyes; then CFLAGS=$CFLAGS -Werror fi])]) This doesn't solve the problem at all: whether -Werror is used via --enable-Werror or via ./configure ... CFLAGS=... -Werror the same errors will occur. No, configuration time errors will not occur with this macro, because this macro adds -Werror only after all of the configuration tests have already run. I guess that -Werror=old-style-definition is somewhat more restricted, but a similar solution can be used. Actually I wasn't using -Werror=old-style-definition directly, but ./configure CFLAGS=-Wall -Wold-style-declaration -Wold-style-definition -Wmissing-parameter-type -Wmissing-prototypes -Wmissing-declarations -Wmissing-field-initializers -Werror If you did the same thing but dropped -Werror from CFLAGS and added --enable-Werror, there would be no problem with configuration tests. IMHO, this is a good thing developers test that their software doesn't generate warnings, possibly with some exceptions; some errors can be avoided with -Wno-error=..., e.g. one needs -Wno-error=unused-function in the case of MPFR (and also gcc-snapshot). The -Werror allows one to do that in automatic tests without filtering the output. Indeed if some new code generates a new warning, it may correspond to a bug. In the particular case of -Werror=old-style-definition, this has corresponded to an obsolescent feature of C for more than 14 years, so that there are no reasons why programs would still use this old style definition. My proposed patch concerning autoconf: http://lists.gnu.org/archive/html/autoconf-patches/2014-01/msg3.html You reported this upstream? I'm not sure why you're reporting it to Debian also, then. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734104: autoconf: uses old-style function definition, thus fails with -Werror=old-style-definition
On Fri, Jan 03, 2014 at 10:22:27PM +0100, Vincent Lefevre wrote: Package: autoconf Version: 2.69-2 Severity: minor A developer may want to test his software with -Werror=old-style-definition (in particular because such definitions could be a real bug in the software). But configure fails because autoconf generates such a function definition. For instance: In my opinion, it's a mistake to run configure tests with -Werror. I suggest adding such flags after configure tests have been run, as with the --enable-Werror configure flag supported by Open vSwitch: dnl OVS_ENABLE_WERROR AC_DEFUN([OVS_ENABLE_WERROR], [AC_ARG_ENABLE( [Werror], [AC_HELP_STRING([--enable-Werror], [Add -Werror to CFLAGS])], [], [enable_Werror=no]) AC_CONFIG_COMMANDS_PRE( [if test X$enable_Werror = Xyes; then CFLAGS=$CFLAGS -Werror fi])]) I guess that -Werror=old-style-definition is somewhat more restricted, but a similar solution can be used. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732260: roger that
On Wed, Dec 18, 2013 at 07:39:00AM +0200, Aleksi Suhonen wrote: OVS 1.9 doesn't support Linux 3.11 as it predates the release of that kernel. However, in many cases you can use the in-tree version of the kernel module directly (namely, if you aren't using tunneling). Otherwise, the fix you suggested is the one used in later versions of OVS. Oh wait, OVS has been merged into Linux 3.11? That's great news. Since older kernels don't exist anymore in Debian/unstable, will the openvswitch-datapath-* packages be removed soon? OVS was merged in Linux 3.3, if I recall correctly. With those kernels, you can use the in-tree or the out-of-tree modules. Features usually make into the out-of-tree module and then get merged into some upstream kernel, so there can be advantages to using the out-of-tree module even with newer kernels. If not, you could consider adding a DKMS exception that prevents compilation with 3.11 with a more descriptive reason. That's an option, yes. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
