Your message dated Sun, 12 Jul 2020 20:54:28 +0100
with message-id
<1758475518f55594c13b2672923c0740dec3a775.ca...@adam-barratt.org.uk>
and subject line Re: Bug#887736: stretch-pu: package
openvswitch/2.6.2~pre+git20161223-3
has caused the Debian Bug report #887736,
regarding stretch-pu: package openvswitch/2.6.2~pre+git20161223-3
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
887736: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887736
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
Tags: stretch
User: [email protected]
Usertags: pu
Dear release team,
I started maintaining OpenVSwitch long after the Stretch release, and
discovered #858418, which is very annoying for OpenVSwitch users.
tl;dr: #858418 prevent anyone that has a valid /etc/network/interfaces
with OpenVSwitch directive from having a working network at boot. The
init script uses a non-documented, not-to-be-used systemd internal,
which is miserably failing.
After a long discussion with the bug reporter (which can be read on the
BTS), I came to the conclusion that he's right, and that the most
reasonable and safe way to fix the current situation is to apply the
patch he suggested (and which resulting debdiff I attached to this bug).
The resulting sbuild binary package is available here:
http://sid.gplhost.com/stretch-proposed-updates/openvswitch/
Please allow me to upload it to Stretch. I'll try to come with a better
way to fix in Sid, probably importing the work from Ubuntu that they
did with an ifupdown hook.
Cheers,
Thomas Goirand (zigo)
diff -Nru openvswitch-2.6.2~pre+git20161223/debian/changelog
openvswitch-2.6.2~pre+git20161223/debian/changelog
--- openvswitch-2.6.2~pre+git20161223/debian/changelog 2017-01-09
23:46:48.000000000 +0100
+++ openvswitch-2.6.2~pre+git20161223/debian/changelog 2018-01-19
13:46:44.000000000 +0100
@@ -1,3 +1,11 @@
+openvswitch (2.6.2~pre+git20161223-3+deb9u1) stretch; urgency=medium
+
+ * Added SYSTEMCTL_SKIP_REDIRECT=yes on top of existing
+ _SYSTEMCTL_SKIP_REDIRECT=yes in the openvswitch-switch init script
+ (Closes: #858418).
+
+ -- Thomas Goirand <[email protected]> Fri, 19 Jan 2018 13:46:44 +0100
+
openvswitch (2.6.2~pre+git20161223-3) unstable; urgency=medium
* Avoid installing ovs-vswitchd.conf.db.5 manpage into directory for
diff -Nru openvswitch-2.6.2~pre+git20161223/debian/openvswitch-switch.init
openvswitch-2.6.2~pre+git20161223/debian/openvswitch-switch.init
--- openvswitch-2.6.2~pre+git20161223/debian/openvswitch-switch.init
2016-09-30 17:27:55.000000000 +0200
+++ openvswitch-2.6.2~pre+git20161223/debian/openvswitch-switch.init
2018-01-19 13:46:44.000000000 +0100
@@ -28,6 +28,7 @@
(test -x /usr/sbin/ovs-vswitchd && test -x /usr/sbin/ovsdb-server) || exit 0
_SYSTEMCTL_SKIP_REDIRECT=yes
+SYSTEMCTL_SKIP_REDIRECT=yes
. /usr/share/openvswitch/scripts/ovs-lib
test -e /etc/default/openvswitch-switch && . /etc/default/openvswitch-switch
--- End Message ---
--- Begin Message ---
On Mon, 2020-06-15 at 20:18 +0100, Adam D. Barratt wrote:
> On Wed, 2019-08-21 at 15:28 -0400, Felipe Sateler wrote:
> >
> > On Tue, Aug 20, 2019 at 6:23 PM Adam D. Barratt <
> > [email protected]> wrote:
> > > Control: tags -1 + moreinfo
> > >
> > > On Fri, 2018-01-19 at 15:21 +0100, Thomas Goirand wrote:
> > > > I started maintaining OpenVSwitch long after the Stretch
> > > > release,
> > > and
> > > > discovered #858418, which is very annoying for OpenVSwitch
> > > > users.
> > > >
> > > > tl;dr: #858418 prevent anyone that has a valid
> > > > /etc/network/interfaces
> > > > with OpenVSwitch directive from having a working network at
> > > > boot.
> > > The
> > > > init script uses a non-documented, not-to-be-used systemd
> > > internal,
> > > > which is miserably failing.
> > > >
> > > > After a long discussion with the bug reporter (which can be
> > > > read
> > > on
> > > > the BTS), I came to the conclusion that he's right, and that
> > > > the
> > > most
> > > > reasonable and safe way to fix the current situation is to
> > > > apply
> > > the
> > > > patch he suggested (and which resulting debdiff I attached to
> > > this
> > > > bug).
> > >
> > > As I understand things, that fix swaps use of one systemd
> > > internal
> > > for another, which doesn't seem like a great plan.
> > >
> > > When this was discussed (some time ago) on IRC, one of the
> > > systemd
> > > maintainers essentially said "don't do that". With apologies for
> > > the delay in doing so, I've CCed the maintainer list to see if we
> > > can find a mutually acceptable solution.
> >
> > Both `service` and `invoke-rc.d` wrappers have a few safeguards
> > against running in unwanted contexts. Have you tried using one of
> > them?
>
> Ping? We're heading towards the final point release for stretch
> before
> it moves to LTS, so need to decide what to do with this request.
The window for getting fixes into that point release just closed, so
I'm afraid that I'm going to close this request now.
Regards,
Adam
--- End Message ---
