vcswatch reports that
this package seems to have a new changelog entry (version
9.11~, distribution
unstable) and new commits
in its VCS. You should consider whether it's time to make
an upload.
Here are the relevant commit messages:
commit d12484c1ff2e57d1bf6f0ad5f9604fa4059ffa6d
Author: Ian Jackson <ijackson@chiark.greenend.org.uk>
Date: Mon Feb 3 08:55:40 2020 +0000
changelog: Start 9.11
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
commit 4f41d991f1343912b5bd704be1e1cbb1ace52dba
Author: Ian Jackson <ijackson@chiark.greenend.org.uk>
Date: Mon Feb 3 08:41:23 2020 +0000
changelog: Finalise 9.10
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
commit 635b2a6e7d55503a75ace034d96326d5b2197798
Author: Ian Jackson <ijackson@chiark.greenend.org.uk>
Date: Sun Feb 2 16:55:52 2020 +0000
changelog: Document changes so far since 9.9
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
commit 9bdd848102280e5f633db852c1b15ff27716c1c0
Author: Ian Jackson <ijackson@chiark.greenend.org.uk>
Date: Sun Feb 2 16:50:41 2020 +0000
i18n-commit - autogenerated
commit 0193f7cd974e8c4a15a41d26b8a43c8f9fcb79b7
Author: Frans Spiesschaert <Frans.Spiesschaert@yucom.be>
Date: Sun Feb 2 16:48:50 2020 +0000
i18n: Updated nl.po file
Closes: #945356
commit bc83ffe7319cab9f1b76b47de9426340836872fe
Author: Sean Whitton <spwhitton@spwhitton.name>
Date: Thu Jul 25 07:03:36 2019 +0100
dgit-maint-debrebase(7): Import tarball before committing gbp.conf
The workflow given previously fails to produce a history that can work
with git-debrebase, because it has the first commit introducing
debian/ be an ancestor of the first import of the upstream source.
This is the final part of #932954.
Closes: #932954.
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
commit 8f086237a8e78c4bd7d018f70818092eb27a5440
Author: Sean Whitton <spwhitton@spwhitton.name>
Date: Wed Jul 24 20:08:23 2019 +0100
d-m-{merge,debrebase}(7): Set 'merge' in gbp.conf
This enables simplifying runes which are more frequently to be typed.
'merge-mode' no longer need be set since in the only case where the
manpages recommend allowing `gbp import-orig` to perform a merge, a
different merge mode is required (and specified in that rune).
This is part of #932954.
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
commit 22c53928460b993bddadb72e8fd51dd916e29cfc
Author: Sean Whitton <spwhitton@spwhitton.name>
Date: Wed Jul 24 20:05:34 2019 +0100
d-m-{merge,debrebase}(7): Use an 'upstream/' tag prefix in gbp.conf
This is a useful convention to distinguish actual upstream tags from
upstream tarball-representing tags created by the Debian package
maintainer.
Note that use of this convention is already recommended in section
"Using untagged upstream commits".
This is part of #932954.
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
commit 3c8aa06111f498377f39f0f0d34d17fe7e187448
Author: Ian Jackson <ijackson@chiark.greenend.org.uk>
Date: Sun Feb 2 16:40:09 2020 +0000
dgit(1): Do not talk about `intermediate' uploads
Incorporate Sean's review comment in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928473#57
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
commit 60bbeaf9fb39b5d8d73ae3cf309ff29e8b705af3
Author: Ian Jackson <ijackson@chiark.greenend.org.uk>
Date: Thu Sep 5 11:26:16 2019 +0100
Terminology: Change "rewind" to "rewrite" where appropriate
In #928473, Colin Watson writes:
> the use of "rewind" as a synonym for "non-fast-forwarding", while
> somewhat common in git terminology, is unfortunate. The terms seem
> to be borrowed from video playback systems, where "rewind" is often
> just the exact opposite of "fast-forward", and so when I see
> "rewinding history" in a few places in dgit(1) my initial
> interpretation is that it must mean "updating a ref to point to an
> ancestor of the commit that it previously pointed to", whereas I
> think dgit(1) means "any push that isn't a fast-forward". I don't
> know if I'm the only one for whom it has that connotation.
This makes sense. So, I am changing uses of "rewind" which do not
mean precisely going back to an ancestor.
I think we can often use the word "rewrite" for the more general
case, but there are some places where another wording is better.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
commit 209b87ba971701dffcd97a7fd9593cea51f62000
Author: Ian Jackson <ijackson@chiark.greenend.org.uk>
Date: Thu Sep 5 11:21:35 2019 +0100
dgit(1): Cover more cases of --overwrite and --deliberately
Closes: #928473
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
commit 70df464217c2b96ea481cb3b28210b53a2d7e040
Author: Sean Whitton <spwhitton@spwhitton.name>
Date: Sat Oct 19 10:33:10 2019 -0700
git-debpush: avoid a pipefail problem in get_file_from_ref
`grep -q` exits as soon as it finds a matching line, potentially
sending a SIGPIPE to git-ls-tree. We have pipefail turned on, so that
can make the whole pipeline exit nonzero, which is wrong when grep did
in fact find a match.
This solution is more readable than disabling pipefail just for this
line (as is done elsewhere in git-debpush).
Closes: #940588
Reported-by: Andrej Shadura <andrewsh@debian.org>
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
commit 134addbf3309871ef36016dd136c362b9cade482
Author: Ian Jackson <ijackson@chiark.greenend.org.uk>
Date: Sun Feb 2 12:34:04 2020 +0000
tests: import-dsc: Test corrupted ENV (#950446)
Closes: #950326
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
commit ccebebe13a570e7432416817f09306e068928e96
Author: Ian Jackson <ijackson@chiark.greenend.org.uk>
Date: Sat Feb 1 21:12:25 2020 +0000
dgit: absurd: Work around mangled env metadata from gbp
Some versions of gbp pq will pass broken metadata from patch files
into the env vars for git-commit-tree. Eg, #950446/#950326 where gbp
pq from buster cannot cope with binutils_2.33.90.20200122-2.dsc,
setting GIT_AUTHOR_DATE to "???" (literally, three ? marks, as copied
from the patch file libctf-soname.diff).
Work around this as follows:
* Try git-commit-tree of an empty commit message. Does it work?
If so, workaround is not needed.
* Try resetting GIT_AUTHOR_* to GIT_COMMITTER_*. Does it work now?
Ah, that is the fix!
* Otherwise, just run git-commit-tree as usual.
This code makes some perhaps-unreasonable assumptions:
* gbp's git commit-tree has the tree object as 2nd argument
(really shonky command line parsing). However, if this
assumption is violated, the result is that the git-commit-tree
attempts either fail harmlessly, or succeed harmlessly, defeating
the workaround but with no other implications.
* if a workaround is needed, it is best to throw away all the
author information, rather that try to pick and choose, or to
fix it up.
These are IMO tolerable because I think it's gbp's job to get this
right. The output from dgit (if it succeeds) will be right in terms
of tree and even in terms of commit structure.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
commit 0bbccf3893a0c5a2ce38bb0d9c5ce3e975ae1775
Author: Ian Jackson <ijackson@chiark.greenend.org.uk>
Date: Sat Feb 1 21:08:02 2020 +0000
dgit: absurd: Break out PATH filtering
Actually this function just sets it to the already-computed $npath,
but this is an implementation detail.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
commit ece5816db28a48e097d99da1bfaf4d853726b851
Author: Ian Jackson <ijackson@chiark.greenend.org.uk>
Date: Sat Feb 1 21:04:56 2020 +0000
dgit: absurd: Provide a way for absurd git to print warnings
The file ../../absurd-apply-warnings is dumped to dgit's stderr.
Nothing writes to it yet, so no overall functional change.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
commit 524d221c7e3b70db546be01d4929a1e9a56e14b7
Author: Ian Jackson <ijackson@chiark.greenend.org.uk>
Date: Sat Sep 14 21:37:15 2019 +0100
changelog: start 9.10
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
![[bug history graph]](https://qa.debian.org/data/bts/graphs/d/dgit.png){kind=link}