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) _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev