[ovs-dev] [PKG-Openstack-devel] Bug#878249: recent OVS upload
zigo at debian.org
Thu Oct 26 23:07:10 UTC 2017
On 10/27/2017 12:45 AM, Ben Pfaff wrote:
> 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.
You can simply rename it as "debian-upstream" or something. The other
way is to push the debian folder in a separate packaging branch.
I by the way saw a lot of differences between the Debian packaging and
the upstream one, which is a major issue, and the main reason why having
a debian folder upstream is a bad idea: there's 2 source of "truth", and
that should be avoided.
> 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.
Which is why I wrote a debian/README.source explaining the facts. Is
that enough for you? Alternatively, I could use "debian1", but I don't
think a lot of people will even notice, and even less, understand the
> I see a number of failed builds here:
> Let me analyze them:
> * mips, powerpc, and ppc64 should be fixed by this commit that is
> already on branch-2.8:
I can incorporate this patch, no pb.
> * 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.
Right, we shall not care.
> * 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
Sparc64 isn't an official port either. See here:
I don't think we should care.
> * 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.)
In such a case, I'd strongly suggest removing this unit test until
further investigation. Is that ok for you too?
> 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.
Well, in such a case, I'd suggest upstream to release more bugfix
releases then! :)
> Thanks again,
My pleasure. I hope the other changes I made are ok with you. Did you
read the debian/changelog? I removed lots of binary packages that were
not technically needed, because that's best practice in Debian (ie: the
FTP masters recommend this). All of them have a Provides: equivalent.
This also simplifies packaging a lot (ie: all /usr/bin things and
manpages are going into openvswitch-common, etc.).
BTW, I always wanted to know: is there a way to do VXLan with OpenStack
and the OpenVSwitch plugin?
Thomas Goirand (zigo)
More information about the dev