On Sun, Aug 20, 2017 at 7:18 PM, Martín Ferrari <tin...@tincho.org> wrote: > On 20/08/17 17:35, Martín Ferrari wrote: >> So, my turn to describe workflows. > > Some things I forgot in my previous email: > > * I am not married to the idea of dch + debcommit, specially when I have > merge conflicts. I understand the merits of git commit + gbp dch. > * The export=WC option in gbp.conf is to make sure my uncommitted > changes are taken into account when building, which allows me to > experiment and test before committing. > > Some notes not about workflow, but about packaging strategies: > > 1. debian/control > > I wrap and sort all multi-entry fields, with a trailing comma at every > line (to minimise diffs). I always did this by hand (or with my > pkg-go-common-fixes script), but a friend just recommended the > wrap-and-sort script from devscripts, and I think we should all use that > with the same options. > > Even if this does not match what I am currently doing (indent after > colon), I think it makes more sense: > > $ wrap-and-sort -st > > Add myself as Uploader for any package where I do some non-trivial > amount of work. Although I think this usage of Uploaders is being > challenged project-wise.
Strong +1. Let’s auto-format all things we can reasonably auto-format. debian/control files are a good candidate for that :). > > Add Testsuite: autopkgtest-pkg-go to every package. > > 2. debian/rules > > Keep it as minimal as possible. > > To add extra needed files (for tests and the such) use > DH_GOLANG_INSTALL_EXTRA, no manual copying and no DH_GOLANG_INSTALL_ALL. > > To avoid compilation and testing of some packages use DH_GOLANG_EXCLUDES. > > If I need to do something in the build directory, pass --builddirectory > to dh, so it is a known location (as opposed to getting the weird path > from debhelper) > > Gccgo has many quirks. One is that it does not use the vendor directory > (I need to check if this is true with the latest version), so you might > need to copy vendor into the builddirectory. …hopefully only temporarily, though, right? Ideally, we wouldn’t have any vendored source in our packages. > > For detecting gccgo, and doing special things: > > GCCGO := $(strip $(shell go version | grep gccgo)) > ifneq ($(GCCGO),) > .. > endif > > Many programs include versions, build info, date, etc, through linker > variables. To make it consistent and reproducible I use this: > > DEBVERS ?= $(shell dpkg-parsechangelog -SVersion) > VERSION ?= $(shell echo '$(DEBVERS)' | sed 's/^[[:digit:]]*://; > s/[-].*//') > DEBDATE ?= $(shell dpkg-parsechangelog -SDate) > REV := $(DEBVERS) > BRANCH := debian/sid > USER := pkg-go-maintainers@lists.alioth.debian.org > HOSTNAME := debian > BUILD_DATE := $(shell date --utc --date='$(DEBDATE)' +%Y%m%d-%H:%M:%S) > GO_VERSION := $(shell go version | sed 's/go version \(\S*\).*/\1/') > BUILDFLAGS := -ldflags \ > " -X $(METAPKG)/version.Version=$(VERSION)\ > -X $(METAPKG)/version.Revision=$(REV)\ > -X $(METAPKG)/version.Branch=$(BRANCH)\ > -X $(METAPKG)/version.BuildUser=$(USER)\ > -X $(METAPKG)/version.BuildDate=$(BUILD_DATE)\ > -X $(METAPKG)/version.GoVersion=$(GO_VERSION)" What does METAPKG resolve to? We should consider centralizing these definitions somewhere. -- Best regards, Michael _______________________________________________ Pkg-go-maintainers mailing list Pkg-go-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers