[PKG-Openstack-devel] Bug#878249: Bug#878249: recent OVS upload

[Thomas Goirand]

Hi Ben,

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
difference.

> I see a number of failed builds here:
> https://buildd.debian.org/status/package.php?p=openvswitch&suite=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

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
>   now).

Sparc64 isn't an official port either. See here:
https://www.debian.org/ports/

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?

Cheers,

Thomas Goirand (zigo)