Bug#910446: NMU diff (substantive patches in git-format-patch form)
Guido Günther writes ("Re: Bug#910446: NMU diff (substantive patches in
git-format-patch form)"):
> It's not that much trouble for me but rather sad that people spent time
> on (in this case) just tedious work while they could fix other stuff
> in the same time since the maintainer is already on it.
Ah. Well, then, thanks for your consideration.
I hope you are able to use most of what I did. I expect if you rebase
my series onto your master with a conflict strategy of just taking
master's version, you'll have most of it done.
As an aside, I looked for a way to *extend* rather than *specify* the
flake8 ignore list. I found that it is possible to fish the existing
list out of the relevant python module, but I didn't know how to write
such a programmatic thing in setup.cfg.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#910446: NMU diff (substantive patches in git-format-patch form)
Hi,
On Sun, Oct 14, 2018 at 10:55:10PM +0100, Ian Jackson wrote:
> Guido Günther writes ("Re: Bug#910446: NMU diff (substantive patches in
> git-format-patch form)"):
> > On Sun, Oct 14, 2018 at 03:36:49PM +0100, Ian Jackson wrote:
> > > Hi. I fixed this bug, and some other FTBFS, and am about to upload
> > > the result. I'm doing this myself, right away, because this is an RC
> > > bug which has triggered the autoremover to want to remove dgit.
> > >
> > > Following the recommendation in dev ref 5.11.1, I have not use
> > > DELAYED; and because I doubt that actually uploading it now will cause
> > > you any difficulty. I hope that's OK.
> > >
> > > The patches I made are attached. You can also find this as a git
> > > branch, here:
> ...>
> > That's actually not what I prefer since I
>
> Sorry about that. But,
>
> I did look in the bug [1] before starting work, this lunchtime UK
> time, and there was no response there.
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910446
>
> I have just checked the bug again, and your message to it crossed with
> my decision to go ahead with the upload. The timestamp on the
> relevant .changes file shows that I did my formal build-for-upload at
> 14:28 UTC. I and evidently spent a few minutes getting my NMU diff
> email into shape and I sent that email at 14:36 and did the actual
> dgit push at 14:37.
>
> Your message to the bug was at 14:31 UTC. I confess didn't check the
> bug again in the 9 minutes between `dgit sbuild' and `dgit push'.
>
> To be honest, if you had said any time in the past week, in the bug,
> that you were intending to fix it I would have been quite happy to
> leave the work to you. But there was nothing from you in the bug and
> the upstream git server (which I was able to see via http, even if the
> git interface was giving me trouble) showed no recent activiy.
To be honest I saw that bug but forgot about it until I saw the
autoremoval mail. I then notified the BTS so reverse dependencies don't
need to worry.
> > - there's plenty of time until the autoremoval hits us
>
> I'm generally quite busy and I had time and headspace to do this
> technical work now. I wasn't confident that that would occur again in
> the next few weeks.
>
> I'm sorry to be told that I have engaged in "sub par interaction". I
> was trying to help. Can you explain to me what concrete problem my
> action has caused you ?
It's not that much trouble for me but rather sad that people spent time
on (in this case) just tedious work while they could fix other stuff
in the same time since the maintainer is already on it.
> I appreciate that being the recipient, several times a year, of
> autoremoval notifications (not just from gbp) is a hazard of sitting
> on top of a large dependency stack. But it would be nice to be able
> to at least fix these things oneself without being criticised.
>
> It would be really helpful if people would respond to RC bugs *before*
> their entire reverse dependency stack has received an `autoremoval'
> email.
Yept, that's totally true but I think the reverse holds as well: if
things are flagged check with the maintainer(s) how this happened
(in this case it was just an oversight). They might either be working on
a fix or might be happy about an NMU.
> I guess I can be criticised for not emailing the bug before starting
> work. Looking at my irc transcript it looks like I started at 12:00
> UTC or so. Of course once one has started on something like this it
> is very discouraging to be told to stop and throw one's work away -
> and I guess your message to the bug was prompted by the autoremoval
> mail which had been sent ovrnight, so an additional mail from me would
> have waited anyway. So probably in this case if I had emailed the bug
> at 12:00ish UTC it would have made no difference.
That's why I at least check with maintainers before starting work on
things. Even then it doesn't always help to avoid duplicated work (since
some times there's more than two parties involved) but most of the time
it does.
I should have used better words in my previous mail. Sorry if this came
over rougher than it meat to be.
Cheers,
-- Guido
Bug#910446: NMU diff (substantive patches in git-format-patch form)
Guido Günther writes ("Re: Bug#910446: NMU diff (substantive patches in
git-format-patch form)"):
> On Sun, Oct 14, 2018 at 03:36:49PM +0100, Ian Jackson wrote:
> > Hi. I fixed this bug, and some other FTBFS, and am about to upload
> > the result. I'm doing this myself, right away, because this is an RC
> > bug which has triggered the autoremover to want to remove dgit.
> >
> > Following the recommendation in dev ref 5.11.1, I have not use
> > DELAYED; and because I doubt that actually uploading it now will cause
> > you any difficulty. I hope that's OK.
> >
> > The patches I made are attached. You can also find this as a git
> > branch, here:
...>
> That's actually not what I prefer since I
Sorry about that. But,
> - said I'm about to fix this
I did look in the bug [1] before starting work, this lunchtime UK
time, and there was no response there.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910446
I have just checked the bug again, and your message to it crossed with
my decision to go ahead with the upload. The timestamp on the
relevant .changes file shows that I did my formal build-for-upload at
14:28 UTC. I and evidently spent a few minutes getting my NMU diff
email into shape and I sent that email at 14:36 and did the actual
dgit push at 14:37.
Your message to the bug was at 14:31 UTC. I confess didn't check the
bug again in the 9 minutes between `dgit sbuild' and `dgit push'.
To be honest, if you had said any time in the past week, in the bug,
that you were intending to fix it I would have been quite happy to
leave the work to you. But there was nothing from you in the bug and
the upstream git server (which I was able to see via http, even if the
git interface was giving me trouble) showed no recent activiy.
> - there's plenty of time until the autoremoval hits us
I'm generally quite busy and I had time and headspace to do this
technical work now. I wasn't confident that that would occur again in
the next few weeks.
I'm sorry to be told that I have engaged in "sub par interaction". I
was trying to help. Can you explain to me what concrete problem my
action has caused you ?
I appreciate that being the recipient, several times a year, of
autoremoval notifications (not just from gbp) is a hazard of sitting
on top of a large dependency stack. But it would be nice to be able
to at least fix these things oneself without being criticised.
It would be really helpful if people would respond to RC bugs *before*
their entire reverse dependency stack has received an `autoremoval'
email.
I guess I can be criticised for not emailing the bug before starting
work. Looking at my irc transcript it looks like I started at 12:00
UTC or so. Of course once one has started on something like this it
is very discouraging to be told to stop and throw one's work away -
and I guess your message to the bug was prompted by the autoremoval
mail which had been sent ovrnight, so an additional mail from me would
have waited anyway. So probably in this case if I had emailed the bug
at 12:00ish UTC it would have made no difference.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#910446: NMU diff (substantive patches in git-format-patch form)
Hi, On Sun, Oct 14, 2018 at 03:36:49PM +0100, Ian Jackson wrote: > Hi. I fixed this bug, and some other FTBFS, and am about to upload > the result. I'm doing this myself, right away, because this is an RC > bug which has triggered the autoremover to want to remove dgit. > > Following the recommendation in dev ref 5.11.1, I have not use > DELAYED; and because I doubt that actually uploading it now will cause > you any difficulty. I hope that's OK. > > The patches I made are attached. You can also find this as a git > branch, here: > git://git.chiark.greenend.org.uk/~ianmdlvl/git-buildpackage.git -b dgit/sid > (commit hash 0259f5979f5adf1a4826344813a1b0294a01638b) > > https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=git-buildpackage.git;a=shortlog;h=refs/heads/dgit/sid > or of course from the Debian archive and dgit git server with > dgit clone git-buildpackage > or in a git working tree of git-buildpackage > dgit fetch > (which will produce a ref remotes/dgit/dgit/sid). > That's actually not what I prefer since I - said I'm about to fix this - there's plenty of time until the autoremoval hits us So this is really sub par interaction. -- Guido
Bug#910446: NMU diff (substantive patches in git-format-patch form)
Hi. I fixed this bug, and some other FTBFS, and am about to upload
the result. I'm doing this myself, right away, because this is an RC
bug which has triggered the autoremover to want to remove dgit.
Following the recommendation in dev ref 5.11.1, I have not use
DELAYED; and because I doubt that actually uploading it now will cause
you any difficulty. I hope that's OK.
The patches I made are attached. You can also find this as a git
branch, here:
git://git.chiark.greenend.org.uk/~ianmdlvl/git-buildpackage.git -b dgit/sid
(commit hash 0259f5979f5adf1a4826344813a1b0294a01638b)
https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=git-buildpackage.git;a=shortlog;h=refs/heads/dgit/sid
or of course from the Debian archive and dgit git server with
dgit clone git-buildpackage
or in a git working tree of git-buildpackage
dgit fetch
(which will produce a ref remotes/dgit/dgit/sid).
Unfortunately my git branch is based not on the upstream history but
on the .dsc imported by dgit (because the last upload to sid was
.dsc-based rather than done with dgit push). I did try to fetch from
the upstream git server git.sigxcpu.org but I got very long delays and
strange errors and a semi-corrupted git repository (!). Sadly I was
not able to reproduce the malfunction to report it, but it scared me
off.
You should be able to rebase my series without trouble onto your own
history, though.
I hope you find this helpful and that rebasing the regexp fixes onto
your master tip is not too tiresome. I left them as the 11 separate
commits as I thought that would be more convenient.
Regards,
Ian.
>From d20c8b1efd7198af5be7836c9777c5982dd117b1 Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Sun, 14 Oct 2018 13:34:04 +0100
Subject: [PATCH 01/20] .gitignore: Fetch from vcs-git (upstream)
https://git.sigxcpu.org/cgit/git-buildpackage/plain/.gitignore
This file was left out of the source package due to this bug:
#908747 Default -I and -i option should not exclude .ignore
Signed-off-by: Ian Jackson
---
.gitignore | 30 ++
1 file changed, 30 insertions(+)
create mode 100644 .gitignore
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..94c9c6e
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,30 @@
+*.pyc
+.noseids
+.coverage
+.tox/
+.ropeproject/
+coverage.xml
+gbp/version.py
+build/
+gbp.egg-info/
+nosetests.xml
+*~
+*.sw?
+\#*#
+.#*
+
+docs/*.1
+docs/*.5
+docs/buildxref/
+docs/manual-html/
+docs/manpage.links
+docs/manpage.refs
+docs/version.ent
+
+debian/git-buildpackage*.debhelper*
+debian/python-module-stampdir/
+debian/files
+debian/git-buildpackage*.substvars
+debian/git-buildpackage/
+debian/git-buildpackage-rpm/
+debian/tmp/
--
2.11.0
>From ce37f3d6396387d55af43b2372351d63a6530a23 Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Sun, 14 Oct 2018 13:36:50 +0100
Subject: [PATCH 02/20] .gitignore: Add .pybuild
Signed-off-by: Ian Jackson
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 94c9c6e..3b0f8d6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1,5 @@
*.pyc
+.pybuild
.noseids
.coverage
.tox/
--
2.11.0
>From 646c33a7c86e5d2a5532a9b67396a80a963b029c Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Sun, 14 Oct 2018 14:32:32 +0100
Subject: [PATCH 03/20] rfc822_date_to_git: Fix docstring for new
dateutil.parser.parse
dateutil.parser.parse now, on failure, throws ValueError containing a
tuple - now it has the troublesome string too.
This causes the tests to fail in Debian sid.
Signed-off-by: Ian Jackson
---
gbp/git/__init__.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gbp/git/__init__.py b/gbp/git/__init__.py
index b3bc599..4bb8588 100644
--- a/gbp/git/__init__.py
+++ b/gbp/git/__init__.py
@@ -41,7 +41,7 @@ def rfc822_date_to_git(rfc822_date, fuzzy=False):
>>> rfc822_date_to_git('So, 26 Feb 1998 8:50:00 +0100')
Traceback (most recent call last):
...
-ValueError: Unknown string format
+ValueError: ('Unknown string format:', 'So, 26 Feb 1998 8:50:00 +0100')
>>> rfc822_date_to_git('So, 26 Feb 1998 8:50:00 +0100', fuzzy=True)
'888479400 +0100'
"""
--
2.11.0
>From 8df9c5df4e01c34fac368840ab78fb592461e73b Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Sun, 14 Oct 2018 14:52:28 +0100
Subject: [PATCH 04/20] Makefile: Set HOME when running tests
A nonexistent directory is sufficient.
Otherwise the tests can pick up the user's git configuration, which is
undesirable. For example, I have
[branch]
autoSetupMerge = false
which causes this test
>>> clone.create_branch('foo', 'origin/foo')
>>> clone.get_merge_branch('foo')
'origin/foo'
to fail.
Signed-off-by: Ian Jackson
---
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index e791e9f..908d992 100644
--- a/Makefile
+++ b/Makefile
@@ -14,6 +14,7 @@ test:
export GIT_COMMITTER_NAME=$$GIT_AUTHOR_NAME;\
