On Fri, Oct 20, 2017 at 08:56:24PM +0200, Thomas Goirand wrote: > I don't mind becoming a co-maintainer, though there's a few things that > need to change to facilitate packaging. First of all, I'd like to switch > to a Git packaging workflow, using git-buildpackage. The debian folder > upstream here should be removed: > > https://github.com/openvswitch/ovs/tree/master/debian > > otherwise, it will clash with what we have in Alioth. Then I'll push > openvswitch in the Alioth git repository under /git/third-party. > > Also, I will remove the debian/automake.mk and the d/copyright hack. > Indeed, Debian needs list of copyright holders, not authors. > > Is that fine for you? I'm starting...
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. 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. Would you mind choosing a different suffix? 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 * 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. * 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). * 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.) 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. Thanks again, Ben.
