This doesn't fix a visible bug, since there's no epoch in the Open vSwitch
version used in Debian, but some Nicira internal build scripts were
inserting an epoch so it was visible in our builds.
Reported-by: Edwin Chiu <echiu@nicira.com>
ovs-vswitchd.conf.db is distributed so it's in the source directory not
the build directory.
This fixes a Debian package build failure introduced by commit 9840bdbd
"debian: Install ovs-vswitchd.conf.db(5) manpage." I did test that commit
but the build failure didn't show up in my environment (probably I had a
stray file left over from development).
This manpage wasn't getting installed. This fixes it.
The --language=C option to dh_installman is necessary to keep that script
from thinking that the ".db" suffix indicates a translation into the "db"
language (which doesn't actually exist) and therefore installing it into
the wrong directory with the .db suffix stripped.
Bug #8138.
Reported-by: Ethan Jackson <ethan@nicira.com>
The problem is that postrm script is unable to remove
contents of /var/log/openvswitch/ directory in case if
it contains any other directories. Steps to reproduce
on Ubuntu 11.04:
1. apt-get install openvswitch-switch
2. dpkg --purge openvswitch-switch
3. observe that purge failed, because of an empty "cores"
directory inside /var/log/openvswitch/
The version of groff on RHEL 5 doesn't include the .SY, .OP, or .YS macros
that ovs-benchmark.1 uses, so the manpage-check target fails on that
platform. This commit adds the groff definitions of those macros to a
file and includes it into ovs-benchmark.1.
I tested that this allows RHEL 5 to pass manpage-check.
ovs-monitor-ipsec uses the OVS database to get configuration, so don't
bother starting the daemon until it's up.
Debian recently switched to using the LSB fields in the header of init
scripts to allow dependency-based boots. This is described in the
following page:
http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot
This commit makes use of those fields to get the ordering we want.
I skipped writing a unit test for this feature on the first go-around, and
of course that meant it didn't work.
Bug #7693.
Reported-by: Michael Hu <mhu@nicira.com>
Commit 201bf205 "ovs-monitor-ipsec: Convert to vlog." only
partially updated ovs-monitor-ipsec to the new vlog module. This
commit completes the process.
The ovs-monitor-ipsec init script used the old "pidfile-name"
instead of the new "pidfile" option. This should cause it to fail
when starting.
This patch also causes ovs-monitor-ipsec to create a log file.
The only difference between the Python files that are installed and the
Python files found in the source tree is in the ovs.dirs module, but this
is a very important difference: we want the directories used to be the ones
configured in (e.g. /usr/share/openvswitch), not the only used by default
by the source tree's dirs.py (e.g. /usr/local/share/openvswitch).
I verified with "dpkg-deb -x" and "diff -ur" that in fact this is the only
change that this commit makes.
This bug has been in place since at least commit 1d273d6d8 "debian: Rename
openvswitch-python to python-openvswitch" from over a year ago, but until
now the packaged Python files didn't actually use any directories that
differed between the two versions of dirs.py, so only now has the problem
manifested.
This problem prevented ovs-monitor-ipsec from finding the OVSDB schema
file.
Reported-by: Ethan Jackson <ethan@nicira.com>
The dh_python2 helper in Debian squeeze has a limitation that is not
mentioned anywhere, as far as I can tell: Python files must be in
/usr/lib/python#.#/site-packages to be installed. The version in Debian
wheezy does not have the same limitation.
This meant that building the Debian packages on squeeze silently produced
a broken python-openvswitch package, whereas building the same thing on
wheezy built a working package.
This fixes the problem by putting the .py files where squeeze expects them.
It works on wheezy too.
Bug #7510.
Reported-by: Michael Hu <mhu@nicira.com>
Tested-by: Simon Horman <horms@verge.net.au>
Argparse has some convenient advantages over optparse including the
ability to handle optional arguments to flags. It also supports
parsing arguments as well as options.
This patch copies argparse.py from Python 2.7 into a newly created
compat directory. It made some very minor syntactic updates in the
process. Platforms which have a Python version too old to include
argparse by default will have this compat version installed as a
workaround.
Until now, the Python bindings for OVSDB have not supported writing to the
database. Instead, writes had to be done with "ovs-vsctl" subprocesses.
This commit adds write support and brings the Python bindings in line with
the C bindings.
This commit deletes the Python-specific IDL tests in favor of using the
same tests as the C version of the IDL, which now pass with both
implementations.
This commit updates the two users of the Python IDL to use the new write
support. I tested this updates only by writing unit tests for them,
which appear in upcoming commits.
Until now ovs.db.types.BaseType has kept track of the name of the
referenced table but not a reference to it. This commit renames the
ref_table attribute to ref_table_name and adds a new ref_table attribute
whose value is a reference to the named table.
This will be useful in an upcoming commit where table references are
actually followed.
By registering an error-handler for the init script used
in openvswitch-switch.postinst and detecting if module insertion fails,
it is possible to avoid failure to install in the case where the
openvswitch_mod module is not available.
This is done without altering the behaviour that the start target
of the openvswitch-switch init script will fail if module insertion fails.
This patch also adds a friendly hint as as to why starting
openvswitch-switch has failed if it is due to failure to insert
the openvswtich_mod. This message is displayed as necessary both
on package install and other calls to the start target of the
init script.
[Ben Pfaff fixed up == to = in postinst]
If /dev/log doesn't exist or cannot be contacted, ovs-monitor-ipsec would
abort with an exception. This allows it to start up and run.
It's pretty common for a chroot used for testing not to have a syslogd
instance set up and running, so this limitation caused testing problems.
Reported-by: Simon Horman <horms@verge.net.au>
Tested-by: Simon Horman <horms@verge.net.au>
dh_pysupport that the packaging used until now is deprecated, with
dh_python2 as its successor.
This commit removes the PYTHONPATH setting from
debian/openvswitch-ipsec.init because it is not needed, as the Python
packaging is public. In fact, the Python packaging was public,
unintentionally, before, so the PYTHONPATH could have been removed earlier.
I tested that installing openvswitch-datapath-dkms worked OK on my own
Debian machine.
The bulk of this patch is taken from downstream Ubuntu DKMS support written
by Chuck Short <zulcss@ubuntu.com>, version 1.2.0-1ubuntu1. I made the
following changes:
* Update debian/.gitignore.
* Update debian/automake.mk.
* Correct description in debian/control (it was a cut-and-paste from
the openvswitch-datapath-source description without editing).
* Fix up for --with-l26 to --with-linux and datapath/linux-2.6 to
datapath/linux transitions.
CC: Chuck Short <zulcss@ubuntu.com>
CC: Dave Walker <DaveWalker@ubuntu.com>
Acked-by: Simon Horman <horms@verge.net.au>
As reported by lintian:
The maintainer script doesn't seem to set the -e flag which ensures
that the script's execution is aborted when any executed command
fails.
Refer to Debian Policy Manual section 10.4 (Scripts) for details.
Add dependency on ${misc:Depends} to openvswitch-brcompat and ovsdbmonitor.
As reported by Lintian:
The source package uses debhelper, but it does not include
${misc:Depends} in the given binary package's debian/control entry.
Any debhelper command may add dependencies to ${misc:Depends} that
are required for the work that it does, so recommended best
practice is always add ${misc:Depends} to the dependencies of each
binary package if debhelper is in use.
Refer to the debhelper(7) manual page for details.
This is just a typo introduced in commit 57483aeda (debian: Fix bug from
commit 211b05b5 "debian: Modernize use of dh_install.) that caused the
ovsdbmonitor package to install too many files.
Bug-report: http://bugs.debian.org/636815
Reported-by: Ralf Treinen <treinen@free.fr>
It would be better to use ovs-ctl from this script, but until now this is
an adequate solution.
Reported-by: Jibesh Patra
Bug-report: https://bugs.launchpad.net/bugs/822142
ovs-vswitchd in the openvswitch-switch package is tightly coupled to its
database schema. During development, it's possible to change the schema
without changing the Open vSwitch version number, which makes it possible
for the openvswitch-switch and openvswitch-common packages to get out of
sync: openvswitch-switch requires the same version of openvswitch-common,
but if the version number doesn't get updated that has no effect.
Actually putting the schema and ovs-vswitchd (its primary user) in the
same package prevents them from getting out-of-sync. This commit also
moves ovsdb-tool because that program often works directly with OVSDB
schemas and so there's not much point having it around without a schema to
work with.
Commit 211b05b5 "debian: Modernize use of dh_install" caused build failures
in clean environments because debian/ovsdbmonitor.install now installed
files that were never created in such an environment. It didn't cause a
build failure in my own testing because I still had old files around.
This fixes the problem.
It seems to be necessary to run "make install" once for each of binary-arch
and binary-indep, because dh_prep always deletes debian/tmp. It is
logically not necessary but I don't see a clean and robust way to avoid it.
Originally I intended this as just a cleanup, but as a side effect it also
installs some files from the install tree in debian/tmp instead of from
_debian. This should avoid a reported problem in which ovs-bugtool was
being created in the source directory instead of the build directory (I
still don't see why this happened).
Reported-by: Sébastien RICCIO <sr@swisscenter.com>
Tested-by: Sébastien RICCIO <sr@swisscenter.com>
Acked-by: Simon Horman <horms@verge.net.au>
CC: Simon Horman <horms@verge.net.au>
All of the xen-bugtool plugins that OVS has previously installed only under
XenServer are equally useful with Debian and other distributions, so
this commit installs and uses them everywhere.
ovs-bugtool is no longer Debian-specific, so install it everywhere. (On
XenServer, specifically, we do not install it, because there xen-bugtool
already exists.)
ovs-bugtool was originally xen-bugtool from Citrix XenServer. We modified
it for OVS by tailoring it to work better on Debian, updating file
locations and removing features that were specific to XenServer or that
work with packages not installed by default on Debian.
This commit reverts many of those changes. This commit:
- Adds back code that works with RHEL features not installed by default
on Debian (but not XenServer-specific features, since xen-bugtool works
nicely on XenServer).
- Switches from hard-coded paths for utilities to searching the
superuser's typical $PATH (because RHEL and Debian disagree on the
location for some utilities).
- In a few cases merges lists, e.g. now it looks for logs under the names
used in both Debian and RHEL.
- Fixes a few spurious differences between ovs-bugtool and xen-bugtool,
e.g. in white space.
The linux-2.6 and compat-2.6 directories apply equally to the upcoming
Linux 3.0 release, so this drops the 2.6 suffix and updates Makefiles.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
This is my preferred package format as it allows changes
to be added as patches when the Debian package needs to
be updated between upstream releases.
I have been making this change in the Debian packages
so it seems as well to include it upstream.
[Update to debian/automake.mk by Ben Pfaff.]
On startup, some OVS initscripts insert an iptables rule to allow GRE
traffic (because GRE support is an important OVS feature). I noticed that,
each time I restarted OVS, this added another GRE-related rule to the
iptables chain. This is wasteful, because each additional rule increases
the time it takes to process a packet in the IP stack.
This commit avoids the problem by inserting an iptables rule when there
isn't already an appropriate rule. It also avoids inserting an iptables
rule if the iptables policy is ACCEPT, meaning that packets are accepted
by default; in such a case, if the GRE packet would be dropped, it is
because the system administrator made that decision explicitly.
Signed-off-by: Ben Pfaff <blp@nicira.com>
