[pkg-go] golang-github-minio-cli REMOVED from testing

2017-08-20 Thread Debian testing watch 
FYI: The status of the golang-github-minio-cli source package
in Debian's testing distribution has changed.

  Previous version: 1.3.0+git20170313.0.8683fa7-1
  Current version:  (not in testing)
  Hint: 
Bug #869190: golang-github-minio-cli FTBFS: FAIL: TestFlagsFromEnv

The script that generates this mail tries to extract removal
reasons from comments in the britney hint files. Those comments
were not originally meant to be machine readable, so if the
reason for removing your package seems to be nonsense, it is
probably the reporting script that got confused. Please check the
actual hints file before you complain about meaningless removals.

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

[pkg-go] golang-github-masterzen-winrm 0.0~git20170601.0.1ca0ba6-2 MIGRATED to testing

2017-08-20 Thread Debian testing watch 
FYI: The status of the golang-github-masterzen-winrm source package
in Debian's testing distribution has changed.

  Previous version: 0.0~git20170601.0.1ca0ba6-1
  Current version:  0.0~git20170601.0.1ca0ba6-2

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

[pkg-go] golang-github-neowaylabs-wabbit 0.0~git20170406.0.cfb5237-2 MIGRATED to testing

2017-08-20 Thread Debian testing watch 
FYI: The status of the golang-github-neowaylabs-wabbit source package
in Debian's testing distribution has changed.

  Previous version: 0.0~git20170406.0.cfb5237-1
  Current version:  0.0~git20170406.0.cfb5237-2

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: [pkg-go] Minutes for the DebConf17 BoF

2017-08-20 Thread Martín Ferrari 
On 20/08/17 19:21, Michael Stapelberg wrote:

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

Gah! Another thing I forgot to talk about! go packaging is hard.. :)

Yes, most of the time I kill all vendoring, but there have been some
exceptions: 1) small, useless libraries that I see no point in packaging
separately; and 2) self-contained parts of a library, that avoid
dragging 100s of dependencies.

The latter happened to me recently with prometheus: I had removed the
vendoring of the consul API, but when I tried to backport that, I
realised I'd need to backport consul, docker, and way too many dependencies.

Sadly, even if the client API is in a different package, the source
packages have long dependency chains. I am starting to think that for
some of these packages, having a separate source package with client
APIs would make sense.


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

Ah, this is prometheus-specific. All the meta info is stored in the
prometheus/common namespace, so I defined that earlier in the rules file.


-- 
Martín Ferrari (Tincho)

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: [pkg-go] Minutes for the DebConf17 BoF

2017-08-20 Thread Michael Stapelberg 
On Sun, Aug 20, 2017 at 7:18 PM, Martín Ferrari  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

Re: [pkg-go] Minutes for the DebConf17 BoF

2017-08-20 Thread Michael Stapelberg 
On Sun, Aug 20, 2017 at 7:05 PM, Martín Ferrari  wrote:
> On 20/08/17 18:46, Michael Stapelberg wrote:
>
>> Side note, not meant to persuade anyone one way or the other: I just
>> realized why I never saw any appeal in that argument: I find git
>> packaging (or git in general?) too brittle and confusing to keep what
>> I consider are multiple projects in the same repository.
>
> Uhm.. I don't really have that feeling. Could you elaborate more?

I don’t want to derail this thread too much, so I’ll keep it brief:

Regarding repos being brittle: in the past, I’ve often found that when
messing up (e.g. when incorrectly importing a new upstream version, or
doing an incorrect merge of some sort), the easiest way to undo is to
delete the repository and start from scratch.

Regarding multiple projects being confusing: I find the history of git
repositories often not that easy to understand, even though I work
with git daily since over 9 years. When multiple branches are
involved, this becomes even harder. Before running any command in an
upstream-tracking git packaging repo, I need to stop and think about
how this affects the repo as a whole.

Maybe this gets easier over time, but I do like the mental simplicity
of having everything upstream-related nicely contained in a tarball.

>
>> When I need to find out something about upstream repositories, I
>> usually use the GitHub web interface, or my local gopath. I never use
>> the git packaging repos, regardless of whether they have history or
>> not.
>
> Heh, I hate the github web interface, can't compare to gitk, git log, etc :)
>
> Also, I don't even have a go path. To this day I get confused every time
> I try to build things by hand!
>
>
>> git config --add remote.origin.push "+refs/heads/*:refs/heads/*"
>> git config --add remote.origin.push "+refs/tags/*:refs/tags/*"
>
> The problem with this is that you push all tags and branches, even if
> they are coming from upstream (I know, not relevant for you). I try to
> keep the alioth repo free from that.
>
>> But note that gbp recently gained “gbp push”:
>> https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=cbacdfb40ca35633da06e9e05497ac0fb56cc4f9
>> It’s included in 0.9.0~exp2, but I haven’t tried it out yet.
>> Hopefully, it makes both our extra setup steps unnecessary :).
>
> Oh, cool, I should try it!
>
>> Given that you _also_ maintain history in git, using gbp dch seems
>> like significantly cutting down the number of commands. Is there any
>> rationale behind your decision to not use gbp dch, or are you just
>> used to this way? :)
>
> Mostly historical reasons and muscle memory :)
>
>
> --
> Martín Ferrari (Tincho)
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers



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

Re: [pkg-go] Minutes for the DebConf17 BoF

2017-08-20 Thread Martín Ferrari 
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.

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.

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)"


-- 
Martín Ferrari (Tincho)

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: [pkg-go] Minutes for the DebConf17 BoF

2017-08-20 Thread Martín Ferrari 
On 20/08/17 18:46, Michael Stapelberg wrote:

> Side note, not meant to persuade anyone one way or the other: I just
> realized why I never saw any appeal in that argument: I find git
> packaging (or git in general?) too brittle and confusing to keep what
> I consider are multiple projects in the same repository.

Uhm.. I don't really have that feeling. Could you elaborate more?

> When I need to find out something about upstream repositories, I
> usually use the GitHub web interface, or my local gopath. I never use
> the git packaging repos, regardless of whether they have history or
> not.

Heh, I hate the github web interface, can't compare to gitk, git log, etc :)

Also, I don't even have a go path. To this day I get confused every time
I try to build things by hand!


> git config --add remote.origin.push "+refs/heads/*:refs/heads/*"
> git config --add remote.origin.push "+refs/tags/*:refs/tags/*"

The problem with this is that you push all tags and branches, even if
they are coming from upstream (I know, not relevant for you). I try to
keep the alioth repo free from that.

> But note that gbp recently gained “gbp push”:
> https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=cbacdfb40ca35633da06e9e05497ac0fb56cc4f9
> It’s included in 0.9.0~exp2, but I haven’t tried it out yet.
> Hopefully, it makes both our extra setup steps unnecessary :).

Oh, cool, I should try it!

> Given that you _also_ maintain history in git, using gbp dch seems
> like significantly cutting down the number of commands. Is there any
> rationale behind your decision to not use gbp dch, or are you just
> used to this way? :)

Mostly historical reasons and muscle memory :)


-- 
Martín Ferrari (Tincho)

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: [pkg-go] Minutes for the DebConf17 BoF

2017-08-20 Thread Michael Stapelberg 
While we’re on the topic:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859867 discusses
making sbuild easier to install/use :)

On Sun, Aug 20, 2017 at 6:56 PM, Martín Ferrari  wrote:
> On 20/08/17 18:36, Michael Stapelberg wrote:
>> I use gbp with sbuild, and I do see different behavior with/without
>> exporting. Take for example the freeradius repository, where the build
>> fails without git-export-dir: https://paste.debian.net/982241/
>
> I guess the difference is with not having an export option at all, which
> I have never tried..
>
 2. My ~/.gbp.conf reads https://paste.debian.net/hidden/a48afca2/

Re: [pkg-go] Minutes for the DebConf17 BoF

2017-08-20 Thread Martín Ferrari 
On 20/08/17 18:36, Michael Stapelberg wrote:
> I use gbp with sbuild, and I do see different behavior with/without
> exporting. Take for example the freeradius repository, where the build
> fails without git-export-dir: https://paste.debian.net/982241/

I guess the difference is with not having an export option at all, which
I have never tried..

>>> 2. My ~/.gbp.conf reads https://paste.debian.net/hidden/a48afca2/
>>>

Re: [pkg-go] Minutes for the DebConf17 BoF

2017-08-20 Thread Michael Stapelberg 
On Sun, Aug 20, 2017 at 2:30 PM, Martín Ferrari  wrote:
> Hi Mickael,
>
> I haven't yet got the time to write down properly my workflow, but I
> will still reply to some points. :)
>
> On 15/08/17 23:02, Michael Stapelberg wrote:
>
>> 1. I store packaging in e.g. ~/d/pkg/gocryptfs and build using `gbp
>> buildpackage --git-export-dir=~/d/out/gocryptfs`. By using
>> --git-export-dir, my working copy always stays clean. By collecting the
>> output files per package, I can easily debdiff between versions. This
>> point is informational and shouldn’t have any bearing on a canonical
>> workflow.
>
> Why do you need this? I use gbp with cowbuilder, and so the working copy
> is never touched. Looking at my gbp.conf, I see my default is to export
> to '../build-area', but probably that does not change much.

I use gbp with sbuild, and I do see different behavior with/without
exporting. Take for example the freeradius repository, where the build
fails without git-export-dir: https://paste.debian.net/982241/

>
>> 2. My ~/.gbp.conf reads https://paste.debian.net/hidden/a48afca2/
>>

Re: [pkg-go] Minutes for the DebConf17 BoF

2017-08-20 Thread Martín Ferrari 
So, my turn to describe workflows.

I use gbp, pristine-tar, cowbuilder (but planning to move to sbuild),
dch, debcommit as my main tools. I have not really used dh-make-golang much.

My global gbp configuration is as follows:

[DEFAULT]
pristine-tar = True
sign-tags = True

[buildpackage]
export = WC
postbuild = lintian $GBP_CHANGES_FILE && debsign $GBP_CHANGES_FILE
export-dir = ../build-area/
tarball-dir = ../tarballs/
ignore-new = True
pbuilder = True

[import-orig]
postimport = dch -v%(version)s New upstream release.


In general, I try to keep existing structures in git, but for packages I
prepare, I use DEP14 branches and tags:

 * HEAD is debian/sid, other dists are debian/.
 * upstream/ tag for unpacked upstream source.
 * debian/ tag for uploaded packages.
 * I keep an "upstream" branch for unpackaged upstream sources, which is
tagged and then merged into the main packaging branch.

Depending on upstream having releases or not, I either use gbp
import-orig --uscan, or follow git history with an "upstream" remote. In
both cases, the sources end in a git branch.

For repackaging, I either use "excluded-files" in debian/changelog for
released projects, or create a second upstream branch "repackaged",
"unvendored", or somesuch, where I make changes and merge from
"upstream" after every import.

For the go ecosystem, I am feeling it is much more useful and productive
to keep complete upstream history than using the releases, and for some
packages with releases I started using this. It pays off every time I
need to troubleshoot api changes, backport fixes, and the such..

When I am doing this, I add this gbp.conf snippet in the debian/ directory:

[buildpackage]
dist = DEP14
upstream-tag = upstream/%(version)s
pristine-tar = True
pristine-tar-commit = True

For simplifying pushes, I also add this config:

$ git config --add remote.debian.push 'refs/heads/debian/*'
$ git config --add remote.debian.push 'refs/heads/upstream'
$ git config --add remote.debian.push 'refs/heads/pristine-tar'
$ git config --add remote.debian.push 'refs/tags/debian/*'
$ git config --add remote.debian.push 'refs/tags/upstream/*'
$ git config --add remote.debian.fetch 'refs/tags/*:refs/tags/*'


My preference for debian/changelog is:
 * distribution=UNRELEASED until the package is ready to upload.
 * I use dch for every change, and debcommit to commit with that same
message.
 * dch -r when package is ready for upload (changes dist).
 * debcommit -r after uploading (creates signed tag).


My workflow with upstream history is as this:

1. Init

(on alioth)

$ /git/pkg-go/setup-repository foo
$ git --git-dir=/git/pkg-go/packages/... symbolic-ref HEAD
refs/heads/debian/sid

(locally)
$ git remote add upstream https://...
$ git remote add debian ssh://git.debian.org/git/pkg-go/packages/...
$ git fetch --all
$ git checkout -b upstream upstream/master # or upstream tag
$ git tag upstream/0.0+gitMMDD.NNN
# optional, if repackaging is needed.
$ git ckeckout -b repackaged
$ git rm -rf vendor/; git commit -m repackage
$ git tag upstream/0.0+gitMMDD.NNN-ds
$ git checkout -b debian/sid
# create debian/* stuff, with dh-make-golang, or (usually) copy from
another package :-). Add gbp.conf snippet, git config, etc

2. Update

$ git fetch --all
$ git checkout debian/sid
$ git tag upstream/0.0+gitMMDD.NNN NNN
$ git merge upstream/0.0+gitMMDD.NNN
$ dch -v 0.0+gitMMDD.NNN-1 'New upstream snapshot.'
$ git add debian/changelog; debcommit
$ gbp buildpackage  # This also creates the pristine tar from the tag.

3. Work on the package

# Fix stuff
$ dch 'debian/foo: fix bar'; debcommit -a

# When finished
$ dch -r
$ git add debian/changelog; debcommit
$ gbp buildpackage

$ dput 
$ debcommit -r
$ git push debian


For backports is all the same, except that instead of using debian/sid,
I fork a debian/stretch-backports and work from there.

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: [pkg-go] Minutes for the DebConf17 BoF

2017-08-20 Thread Martín Ferrari 
Hey,

On 16/08/17 04:54, Michael Hudson-Doyle wrote:

> I think I /slightly/ prefer the upstream branch to be upstream's git
> history not a series of imports of tarballs. But I'm not set on it, and
> gbp doesn't really get on with this approach if you're just packaging a
> random commit rather than a tag AFAICS.

Actually, it works wonderfully: you just need to tag the right commit
with -say- `upstream/0.0+git20170808.deadbee`, and then `dch -v
0.0+git20170808.deadbeef-1`. With the right options, it creates the orig
tarball and commits it to pristine tar during the first build.

> Makes sense. Which gccgo arches are really being used today though? MIPS
> I guess, but that really should get golang-go once we figure out how to
> do that.

Not sure about being used, but we compile for mips* and arm*.

> https://nm.debian.org/process/198 :)

yay!!

-- 
Martín Ferrari (Tincho)

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: [pkg-go] Minutes for the DebConf17 BoF

2017-08-20 Thread Martín Ferrari 
Hi Mickael,

I haven't yet got the time to write down properly my workflow, but I
will still reply to some points. :)

On 15/08/17 23:02, Michael Stapelberg wrote:

> 1. I store packaging in e.g. ~/d/pkg/gocryptfs and build using `gbp
> buildpackage --git-export-dir=~/d/out/gocryptfs`. By using
> --git-export-dir, my working copy always stays clean. By collecting the
> output files per package, I can easily debdiff between versions. This
> point is informational and shouldn’t have any bearing on a canonical
> workflow.

Why do you need this? I use gbp with cowbuilder, and so the working copy
is never touched. Looking at my gbp.conf, I see my default is to export
to '../build-area', but probably that does not change much.

> 2. My ~/.gbp.conf reads https://paste.debian.net/hidden/a48afca2/
>