On Sun 2020-04-19 10:42:33 +0200, Bertrand Marc wrote: > As a general rule concerning your changes, I would prefer not mixing > packaging style and trailing whitespaces changes with bug fixes.
I agree with that; the individual git commits should indeed separate those things. The canonicalization of whitespace and line-wrapping that i did in that series is intended to make the specific functional changes easier to read. > But if you'd like to co-maintain the package, we could also implement > your wrap-and-sort choices of course. I'd be happy to help co-maintain, but if i do that, there are some conventions that i think collectively make it easier to handle shared development: - I note that you preferred wrap-and-sort -as over wrap-and-sort -ast. But -t is useful because it makes every line identical, so that a diff that appends to a list looks the same as a diff that inserts an element elsewhere in the list. - I prefer to use gbp pq-style patch queues in debian/patches (using the standard "git format-patch" format). Compared to DEP-3 patches, which are a debian-specific format, pq-style patches integrate better into common uses of git, both for upstream and for other downstreams that also use git. Also, it is easy/comfortable to use "gbp pq" to tweak and maintain them. - I'd prefer to rely on DEP-14-style branch naming -- i would be happy to do the branch rename shuffle for the repository and to add a debian/gbp.conf if you're ok with that. And two more changes that would only likely apply going forward (to new upstream releases): - I find it really useful to have debian packaging git branch connected to the upstream git branches -- that is, the "upstream/latest" branch is an overlay that inherits from upstream git tags, connected with gbp's "upstream-vcs-tag" feature. And debian packaging represents a series of commits branching from there. This approach gives git a better understanding of how packaging and upstream work intersects, and can make it easier to interact with upstream in their preferred development environment. - I tend to prefer to have gbp import-orig filter out most or all of the generated files from the tarball (in particular, the files that we aim to regenerate with modern debhelper's default autoreconf steps). The technique i use would only apply going forward, and of course the stashed pristine-tar orig tarballs are *not* filtered out, so we would still work with whatever tarballs are distributed by upstream. i can also provide an updated debian/gbp.conf to do that, if you're interested. You can see examples of these approaches in recent versions of https://salsa.debian.org/debian/libgpg-error if you want. If none of the above sounds horrible to you, feel free to add me to the Maintainers: or Uploaders: field. Please let me know if you do! > Concerning the new version, I am aware of the issue with parallel > building. Actually, I was the one signalling the issue [1]. i saw that, thanks! I was just trying to pull in the fixes that upstream proposed to make the relevant tests run serially rather than in parallel. > However, I am still puzzled by another testing issue: on my box, > test_upgrade_tls and test_upgrade_large_tls fail randomly when built > with git-buildpackage and cowbuilder, but not with debuild and > dpkg-buildpackage. Therefore I suspect the use of chroots, but I did > not manage to locate properly the issue. I also submit the problem > upstream, without success yet [2]. Your help would be much welcome on > this one. Interesting, i'm not seeing the failure on my side for 0.9.70-1 with either git-buildpackage or cowbuilder based on the current master branch in salsa, though maybe i just haven't run a build repeatedly enough to hit whatever corner case you're seeing? fwiw, i think it's worth going ahead and uploading 0.9.70-1 of the package even if you see intermittent failures on some local cowbuilder instances. Failure logs produced by debian build daemons are very handy artifacts for upstream debugging. Thanks a lot for your work on libmicrohttpd in debian! --dkg
signature.asc
Description: PGP signature
