debian packaging cleanup

debian packaging cleanup

[Daniel Kahn Gillmor]

The following patch series should be fairly unobjectionable cleanup of
the debian packaging for notmuch.

Let me know if you think there are problems with any of it.

    --dkg

[PATCH 1/5] debian/control: build-depend on python3-sphinx instead of python-sphinx

[Daniel Kahn Gillmor]

python2 is going to be deprecated, and python3-sphinx is available all
the way back to oldoldstable.  let's use the more modern version.
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 20b8a2db..3a624fdc 100644
--- a/debian/control
+++ b/debian/control
@@ -18,7 +18,7 @@ Build-Depends:
  python3-all (>= 3.1.2-7~),
  dh-python,
  dh-elpa (>= 1.3),
- python-sphinx (>= 1.0),
+ python3-sphinx,
  ruby, ruby-dev (>>1:1.9.3~),
  emacs25-nox | emacs25 (>=25~) | emacs25-lucid (>=25~) |
  emacs24-nox | emacs24 (>=24~) | emacs24-lucid (>=24~) |
-- 
2.15.0

Re: [PATCH 1/5] debian/control: build-depend on python3-sphinx instead of python-sphinx

[Daniel Kahn Gillmor]

On Thu 2017-11-30 04:40:39 -0500, Daniel Kahn Gillmor wrote:
> python2 is going to be deprecated, and python3-sphinx is available all
> the way back to oldoldstable.  let's use the more modern version.
> ---
>  debian/control | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/debian/control b/debian/control
> index 20b8a2db..3a624fdc 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -18,7 +18,7 @@ Build-Depends:
>   python3-all (>= 3.1.2-7~),
>   dh-python,
>   dh-elpa (>= 1.3),
> - python-sphinx (>= 1.0),
> + python3-sphinx,
>   ruby, ruby-dev (>>1:1.9.3~),
>   emacs25-nox | emacs25 (>=25~) | emacs25-lucid (>=25~) |
>   emacs24-nox | emacs24 (>=24~) | emacs24-lucid (>=24~) |

hm, on further reflection, this one is specifically problematic because
of the use of:

    ${python} -m sphinx.writers.manpage

in ./configure, used to test for the presence of the sphinx module.

This can be fixed by preferring python3 here:

--- a/configure
+++ b/configure
@@ -557,7 +557,7 @@ fi
 printf "Checking for python... "
 have_python=0
 
-for name in ${PYTHON} python python2 python3; do
+for name in ${PYTHON} python3 python python2; do
     if command -v $name > /dev/null; then
        have_python=1
        python=$name

any thoughts or preferences on this?

        --dkg

Re: [PATCH 1/5] debian/control: build-depend on python3-sphinx instead of python-sphinx

[Tomi Ollila]

On Thu, Nov 30 2017, Daniel Kahn Gillmor wrote:

> On Thu 2017-11-30 04:40:39 -0500, Daniel Kahn Gillmor wrote:
>> python2 is going to be deprecated, and python3-sphinx is available all
>> the way back to oldoldstable.  let's use the more modern version.
>> ---
>>  debian/control | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/debian/control b/debian/control
>> index 20b8a2db..3a624fdc 100644
>> --- a/debian/control
>> +++ b/debian/control
>> @@ -18,7 +18,7 @@ Build-Depends:
>>   python3-all (>= 3.1.2-7~),
>>   dh-python,
>>   dh-elpa (>= 1.3),
>> - python-sphinx (>= 1.0),
>> + python3-sphinx,
>>   ruby, ruby-dev (>>1:1.9.3~),
>>   emacs25-nox | emacs25 (>=25~) | emacs25-lucid (>=25~) |
>>   emacs24-nox | emacs24 (>=24~) | emacs24-lucid (>=24~) |
>
> hm, on further reflection, this one is specifically problematic because
> of the use of:
>
>     ${python} -m sphinx.writers.manpage
>
> in ./configure, used to test for the presence of the sphinx module.
>
> This can be fixed by preferring python3 here:
>
> --- a/configure
> +++ b/configure
> @@ -557,7 +557,7 @@ fi
>  printf "Checking for python... "
>  have_python=0
>  
> -for name in ${PYTHON} python python2 python3; do
> +for name in ${PYTHON} python3 python python2; do

>      if command -v $name > /dev/null; then
>         have_python=1
>         python=$name
>
> any thoughts or preferences on this?

I'd like this change. I was going to suggest "${PYTHON}" there
but perhaps if one sets e.g.

PYTHON='/usr/local/bin/python3 -B -E -u'

The above would still work (I'd say this is potentially more useful
than supporting whitespace in paths).

Tomi


>
>         --dkg

Re: [PATCH 1/5] debian/control: build-depend on python3-sphinx instead of python-sphinx

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 2437 bytes --]

On Sun 2017-12-03 15:35:04 +0200, Tomi Ollila wrote:
> On Thu, Nov 30 2017, Daniel Kahn Gillmor wrote:
>
>> On Thu 2017-11-30 04:40:39 -0500, Daniel Kahn Gillmor wrote:
>>> python2 is going to be deprecated, and python3-sphinx is available all
>>> the way back to oldoldstable.  let's use the more modern version.
>>> ---
>>>  debian/control | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/debian/control b/debian/control
>>> index 20b8a2db..3a624fdc 100644
>>> --- a/debian/control
>>> +++ b/debian/control
>>> @@ -18,7 +18,7 @@ Build-Depends:
>>>   python3-all (>= 3.1.2-7~),
>>>   dh-python,
>>>   dh-elpa (>= 1.3),
>>> - python-sphinx (>= 1.0),
>>> + python3-sphinx,
>>>   ruby, ruby-dev (>>1:1.9.3~),
>>>   emacs25-nox | emacs25 (>=25~) | emacs25-lucid (>=25~) |
>>>   emacs24-nox | emacs24 (>=24~) | emacs24-lucid (>=24~) |
>>
>> hm, on further reflection, this one is specifically problematic because
>> of the use of:
>>
>>     ${python} -m sphinx.writers.manpage
>>
>> in ./configure, used to test for the presence of the sphinx module.
>>
>> This can be fixed by preferring python3 here:
>>
>> --- a/configure
>> +++ b/configure
>> @@ -557,7 +557,7 @@ fi
>>  printf "Checking for python... "
>>  have_python=0
>>  
>> -for name in ${PYTHON} python python2 python3; do
>> +for name in ${PYTHON} python3 python python2; do
>
>>      if command -v $name > /dev/null; then
>>         have_python=1
>>         python=$name
>>
>> any thoughts or preferences on this?
>
> I'd like this change. I was going to suggest "${PYTHON}" there
> but perhaps if one sets e.g.
>
> PYTHON='/usr/local/bin/python3 -B -E -u'
>
> The above would still work (I'd say this is potentially more useful
> than supporting whitespace in paths).

does it work?  i think the -B -E -u will all be tried as possible python
implementations separately, no?  and $python itself will just get set to
/usr/local/bin/python3 with the arguments dropped :(

0 dkg@alice:~$ x="a b c"
0 dkg@alice:~$ for y in ${x} d e; do printf ':%s\n' "$y"; done
:a
:b
:c
:d
:e
0 dkg@alice:~$ 

While i think this doesn't support Tomi's extended use case, i still
think it's the right direction to move in.

Does anyone have any objection to the preference order change above?  Is
there any reason we should be preferring python 2 to python3 as we move
forward?

        --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: [PATCH 1/5] debian/control: build-depend on python3-sphinx instead of python-sphinx

[Tomi Ollila]

On Mon, Dec 04 2017, Daniel Kahn Gillmor wrote:

> On Sun 2017-12-03 15:35:04 +0200, Tomi Ollila wrote:
>> On Thu, Nov 30 2017, Daniel Kahn Gillmor wrote:
>>
>>> On Thu 2017-11-30 04:40:39 -0500, Daniel Kahn Gillmor wrote:
>>>> python2 is going to be deprecated, and python3-sphinx is available all
>>>> the way back to oldoldstable.  let's use the more modern version.
>>>> ---
>>>>  debian/control | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/debian/control b/debian/control
>>>> index 20b8a2db..3a624fdc 100644
>>>> --- a/debian/control
>>>> +++ b/debian/control
>>>> @@ -18,7 +18,7 @@ Build-Depends:
>>>>   python3-all (>= 3.1.2-7~),
>>>>   dh-python,
>>>>   dh-elpa (>= 1.3),
>>>> - python-sphinx (>= 1.0),
>>>> + python3-sphinx,
>>>>   ruby, ruby-dev (>>1:1.9.3~),
>>>>   emacs25-nox | emacs25 (>=25~) | emacs25-lucid (>=25~) |
>>>>   emacs24-nox | emacs24 (>=24~) | emacs24-lucid (>=24~) |
>>>
>>> hm, on further reflection, this one is specifically problematic because
>>> of the use of:
>>>
>>>     ${python} -m sphinx.writers.manpage
>>>
>>> in ./configure, used to test for the presence of the sphinx module.
>>>
>>> This can be fixed by preferring python3 here:
>>>
>>> --- a/configure
>>> +++ b/configure
>>> @@ -557,7 +557,7 @@ fi
>>>  printf "Checking for python... "
>>>  have_python=0
>>>  
>>> -for name in ${PYTHON} python python2 python3; do
>>> +for name in ${PYTHON} python3 python python2; do
>>
>>>      if command -v $name > /dev/null; then
>>>         have_python=1
>>>         python=$name
>>>
>>> any thoughts or preferences on this?
>>
>> I'd like this change. I was going to suggest "${PYTHON}" there
>> but perhaps if one sets e.g.
>>
>> PYTHON='/usr/local/bin/python3 -B -E -u'
>>
>> The above would still work (I'd say this is potentially more useful
>> than supporting whitespace in paths).
>
> does it work?  i think the -B -E -u will all be tried as possible python
> implementations separately, no?  and $python itself will just get set to
> /usr/local/bin/python3 with the arguments dropped :(

Ahh, you're right. Alternative would be to check whether "${PYTHON-}" is
a nonempty string and use that...

Tomi

>
> 0 dkg@alice:~$ x="a b c"
> 0 dkg@alice:~$ for y in ${x} d e; do printf ':%s\n' "$y"; done
> :a
> :b
> :c
> :d
> :e
> 0 dkg@alice:~$ 
>
> While i think this doesn't support Tomi's extended use case, i still
> think it's the right direction to move in.
>
> Does anyone have any objection to the preference order change above?  Is
> there any reason we should be preferring python 2 to python3 as we move
> forward?
>
>         --dkg

Re: [PATCH 1/5] debian/control: build-depend on python3-sphinx instead of python-sphinx

[Tomi Ollila]

On Mon, Dec 04 2017, Tomi Ollila wrote:

> On Mon, Dec 04 2017, Daniel Kahn Gillmor wrote:
>
>> On Sun 2017-12-03 15:35:04 +0200, Tomi Ollila wrote:
>>> On Thu, Nov 30 2017, Daniel Kahn Gillmor wrote:
>>>
>>>>
>>>> hm, on further reflection, this one is specifically problematic because
>>>> of the use of:
>>>>
>>>>     ${python} -m sphinx.writers.manpage
>>>>
>>>> in ./configure, used to test for the presence of the sphinx module.
>>>>
>>>> This can be fixed by preferring python3 here:
>>>>
>>>> --- a/configure
>>>> +++ b/configure
>>>> @@ -557,7 +557,7 @@ fi
>>>>  printf "Checking for python... "
>>>>  have_python=0
>>>>  
>>>> -for name in ${PYTHON} python python2 python3; do
>>>> +for name in ${PYTHON} python3 python python2; do
>>>
>>>>      if command -v $name > /dev/null; then
>>>>         have_python=1
>>>>         python=$name
>>>>
>>>> any thoughts or preferences on this?
>>>
>>> I'd like this change. I was going to suggest "${PYTHON}" there
>>> but perhaps if one sets e.g.
>>>
>>> PYTHON='/usr/local/bin/python3 -B -E -u'
>>>
>>> The above would still work (I'd say this is potentially more useful
>>> than supporting whitespace in paths).
>>
>> does it work?  i think the -B -E -u will all be tried as possible python
>> implementations separately, no?  and $python itself will just get set to
>> /usr/local/bin/python3 with the arguments dropped :(
>
> Ahh, you're right. Alternative would be to check whether "${PYTHON-}" is
> a nonempty string and use that...

Now that I said it, I'm compelled to write an example. Simpler
alternative is to just have what you Daniel first wrote...

.. so I'm, fine with original  for name in ${PYTHON} python3 python python2; do


have_python=0

if test "${PYTHON-}"; then
    name=${PYTHON%%[$IFS]*}
    if command -v $name > /dev/null; then
        have_python=1
        python=$name
    fi
fi
if [ $have_python -eq 0 ]; then
    for name in python3 python python2; do
        if command -v $name > /dev/null; then
            have_python=1
            python=$name
        fi
    done
fi

>
> Tomi
>
>>
>> 0 dkg@alice:~$ x="a b c"
>> 0 dkg@alice:~$ for y in ${x} d e; do printf ':%s\n' "$y"; done
>> :a
>> :b
>> :c
>> :d
>> :e
>> 0 dkg@alice:~$ 
>>
>> While i think this doesn't support Tomi's extended use case, i still
>> think it's the right direction to move in.
>>
>> Does anyone have any objection to the preference order change above?  Is
>> there any reason we should be preferring python 2 to python3 as we move
>> forward?
>>
>>         --dkg

[PATCH v2] debian/control: build-depend on python3-sphinx instead of python-sphinx

[Daniel Kahn Gillmor]

python2 is going to be deprecated, and python3-sphinx is available all
the way back to oldoldstable.  let's use the more modern version.

To make this work and still ship the manpages, tell ./configure to
prefer python3 over python, if it exists.
---
 configure      | 2 +-
 debian/control | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index f1974520..b177b141 100755
--- a/configure
+++ b/configure
@@ -557,7 +557,7 @@ fi
 printf "Checking for python... "
 have_python=0
 
-for name in ${PYTHON} python python2 python3; do
+for name in ${PYTHON} python3 python python2; do
     if command -v $name > /dev/null; then
 	have_python=1
 	python=$name
diff --git a/debian/control b/debian/control
index c53ba20a..51129886 100644
--- a/debian/control
+++ b/debian/control
@@ -18,7 +18,7 @@ Build-Depends:
  python3-all (>= 3.1.2-7~),
  dh-python,
  dh-elpa (>= 1.3),
- python-sphinx (>= 1.0),
+ python3-sphinx,
  ruby, ruby-dev (>>1:1.9.3~),
  emacs25-nox | emacs25 (>=25~) | emacs25-lucid (>=25~) |
  emacs24-nox | emacs24 (>=24~) | emacs24-lucid (>=24~) |
-- 
2.15.0

Re: [PATCH v2] debian/control: build-depend on python3-sphinx instead of python-sphinx

[David Bremner]

Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

> python2 is going to be deprecated, and python3-sphinx is available all
> the way back to oldoldstable.  let's use the more modern version.
>
> To make this work and still ship the manpages, tell ./configure to
> prefer python3 over python, if it exists.

pushed.

d

[PATCH 2/5] debian/changelog: remove trailing whitespace

[Daniel Kahn Gillmor]

---
 debian/changelog | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 67282a07..decef1e9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -836,7 +836,7 @@ notmuch (0.9~rc2-1) experimental; urgency=low
     - New SONAME for libnotmuch
     - bindings changes for ruby and python
   * Less non-text parts reported in replies.
-  * emacs: provide button action to fetch unknown gpg keys 
+  * emacs: provide button action to fetch unknown gpg keys
 
  -- David Bremner <bremner@debian.org>  Fri, 07 Oct 2011 18:53:04 -0300
 
@@ -845,7 +845,7 @@ notmuch (0.9~rc1-1) experimental; urgency=low
   * Upstream release candidate
     - Atomicity improvements, thanks to Austin Clements
     - Add missing call to g_type_init, thanks to Aaron Ecay
-  * notmuch-emacs: add versioned dependency on notmuch.  
+  * notmuch-emacs: add versioned dependency on notmuch.
     (Closes: #642240).
 
  -- David Bremner <bremner@debian.org>  Sun, 25 Sep 2011 11:26:01 -0300
@@ -854,7 +854,7 @@ notmuch (0.8-1) unstable; urgency=low
 
   * New upstream version.
     - Improved handling of message/rfc822 parts
-    - Improved Build system portability 
+    - Improved Build system portability
     - Documentation update for Ruby bindings
     - Unicode, iterator, PEP8 changes for python bindings
 
@@ -936,7 +936,7 @@ notmuch (0.6~254) experimental; urgency=low
 
   [ Jameson Rollins ]
   * Bump standards version to 3.9.2 (No changes).
-  
+
  -- David Bremner <bremner@debian.org>  Thu, 23 Jun 2011 07:50:05 -0300
 
 notmuch (0.6~237) experimental; urgency=low
@@ -981,8 +981,8 @@ notmuch (0.6~171) experimental; urgency=low
   * notmuch reply: Avoid segmentation fault when printing multiple parts
   * notmuch show: New part output handling.
   * emacs: Show cleaner `From:' addresses in the summary line.
-  * emacs: Add custom `notmuch-show-elide-same-subject', 
-    `notmuch-show-always-show-subject' 
+  * emacs: Add custom `notmuch-show-elide-same-subject',
+    `notmuch-show-always-show-subject'
   * emacs: Render text/x-vcalendar parts.
   * emacs: Add `notmuch-show-multipart/alternative-discouraged'.
   * vim: parse 'from' address, use sendmail directly, implement archive in
@@ -1114,7 +1114,7 @@ notmuch (0.2) unstable; urgency=low
   * Fix headers to be properly decoded in "notmuch reply"
   * emacs: Show the last few lines of citations as well as the first few lines.
   * emacs: The '+' and '-' commands can now add and remove tags by region.
-  * emacs: More meaningful buffer names for thread-view buffers. 
+  * emacs: More meaningful buffer names for thread-view buffers.
   * emacs: Customized colors of threads in search view based on tags.
 
  -- Carl Worth <cworth@debian.org>  Fri, 16 Apr 2010 10:20:23 -0700
-- 
2.15.0

[PATCH 3/5] debian/control: Priority: extra is deprecated

[Daniel Kahn Gillmor]

Move transitional package to to "oldlibs/optional"

This resolves two lintian warnings:

W: notmuch-emacs: transitional-package-should-be-oldlibs-optional oldlibs/extra
W: notmuch-emacs: priority-extra-is-replaced-by-priority-optional
---
 debian/control | 1 -
 1 file changed, 1 deletion(-)

diff --git a/debian/control b/debian/control
index 3a624fdc..bb88b0f7 100644
--- a/debian/control
+++ b/debian/control
@@ -113,7 +113,6 @@ Description: Ruby interface to the notmuch mail search and index library
 
 Package: notmuch-emacs
 Section: oldlibs
-Priority: extra
 Architecture: all
 Depends: elpa-notmuch, ${misc:Depends}
 Description: thread-based email index, search and tagging (transitional package)
-- 
2.15.0

[PATCH 4/5] debian: bump Standards-Version to 4.1.1

[Daniel Kahn Gillmor]

No minor changes were necessary to become compliant with Debian policy
version 4.1.1, so this is basically a freebie.
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index bb88b0f7..51129886 100644
--- a/debian/control
+++ b/debian/control
@@ -28,7 +28,7 @@ Build-Depends:
  gpgsm <!nocheck>,
  gnupg <!nocheck>,
  bash-completion (>=1.9.0~)
-Standards-Version: 4.0.0
+Standards-Version: 4.1.1
 Homepage: https://notmuchmail.org/
 Vcs-Git: git://notmuchmail.org/git/notmuch
 Vcs-Browser: https://git.notmuchmail.org/git/notmuch
-- 
2.15.0

Re: [PATCH 4/5] debian: bump Standards-Version to 4.1.1

[David Bremner]

Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

> No minor changes were necessary to become compliant with Debian policy
> version 4.1.1, so this is basically a freebie.

pushed 2,3,4. Waiting for you and Tomi to reach a fixed point on
1. Skeptical of 5; I tend to think lintian is wrong here. Not sure if I
care enough to override it.

d

Re: [PATCH 4/5] debian: bump Standards-Version to 4.1.1

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

On Mon 2017-12-04 21:30:00 -0400, David Bremner wrote:
> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
>
>> No minor changes were necessary to become compliant with Debian policy
>> version 4.1.1, so this is basically a freebie.
>
> pushed 2,3,4. Waiting for you and Tomi to reach a fixed point on
> 1.

Tomi seemed to say "I'm, fine with original" in
id:m28teiw635.fsf@guru.guru-group.fi though i confess his punctuation is
a little confusing to me.

so i think that's an agreement that my proposal (preferring python3) is
acceptable.  Maybe Tomi will propose a concrete patch if he wants
something fancier.

> Skeptical of 5; I tend to think lintian is wrong here. Not sure if I
> care enough to override it.

I'm fine if you want to drop #5, as long as you file a bug report
against lintian explaining why you think it's wrong :)

thanks for the review!

        --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[PATCH 5/5] debian/control: put elpa-notmuch in Section: lisp.

[Daniel Kahn Gillmor]

This makes lintian stop complaining about:

W: elpa-notmuch: wrong-section-according-to-package-name elpa-notmuch => lisp
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 51129886..cff610cf 100644
--- a/debian/control
+++ b/debian/control
@@ -121,6 +121,7 @@ Description: thread-based email index, search and tagging (transitional package)
 Package: elpa-notmuch
 Architecture: all
 Depends: ${misc:Depends}, ${elpa:Depends}
+Section: lisp
 Description: thread-based email index, search and tagging (emacs interface)
  Notmuch is a system for indexing, searching, reading, and tagging
  large collections of email messages in maildir or mh format. It uses
-- 
2.15.0

Re: [PATCH 5/5] debian/control: put elpa-notmuch in Section: lisp.

[Daniel Kahn Gillmor]

On Thu 2017-11-30 04:40:43 -0500, Daniel Kahn Gillmor wrote:
> This makes lintian stop complaining about:
>
> W: elpa-notmuch: wrong-section-according-to-package-name elpa-notmuch => lisp

I'm withdrawing this patch for consideration.  I'm convinced by
bremner's argument in https://bugs.debian.org/883772 that
language-specific sections are a bad idea!

                  --dkg

Re: debian packaging cleanup

[David Bremner]

Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:

> The following patch series should be fairly unobjectionable cleanup of
> the debian packaging for notmuch.
>
> Let me know if you think there are problems with any of it.
>

Not problems per se, but I would expect several of these things to be
documented in debian/changelog, including the standards version change.

d

Re: debian packaging cleanup

[Daniel Kahn Gillmor]

On Thu 2017-11-30 08:01:18 -0400, David Bremner wrote:
> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
>
>> The following patch series should be fairly unobjectionable cleanup of
>> the debian packaging for notmuch.
>>
>> Let me know if you think there are problems with any of it.
>
> Not problems per se, but I would expect several of these things to be
> documented in debian/changelog, including the standards version change.

I was presuming to do one rollup patch to build out the debian/changelog
entry as release time approaches, rather than including changelog
messages in the patches themselves.

That rollup patch should be fairly easy to do with, e.g.:

    gbp dch --new-version=0.26-1 debian/

I prefer this approach because:

 (a) it doesn't confuse changelog messages with patches, and

 (b) it means that we don't end up with heavily-ordered patches, where
     it's more difficult merge some patches from a series than others,
     because each patch to d/changelog depends on the immediately prior
     changeset.

I'd much rather you (or anyone else reviewing) can immediately and
trivially pull the changes you like from the series while leaving the
ones you're less certain about unmerged, for further discussion.

Case in point here, the change to python3-sphinx might be more
problematic than i'd originally expected.  I wouldn't want anyone to
have to rewrite the subsequent trivial patches just to leave that one
behind.

Is there a reason to prefer patching d/changelog in each individual
changeset?

        --dkg