Patchwork [7,of,7,stable] packaging: fix buildrpm whitespace

login
register
mail settings
Submitter Mads Kiilerich
Date Oct. 27, 2019, 11:37 p.m.
Message ID <c84f1465c44ebc539b80.1572219435@xps>
Download mbox | patch
Permalink /patch/42606/
State Accepted
Headers show

Comments

Mads Kiilerich - Oct. 27, 2019, 11:37 p.m.
# HG changeset patch
# User Mads Kiilerich <mads@kiilerich.com>
# Date 1572203819 -3600
#      Sun Oct 27 20:16:59 2019 +0100
# Branch stable
# Node ID c84f1465c44ebc539b803b876206712e0ebd78b4
# Parent  8c18adcd0177f3ca35f7f20f52f27f5a13ac9f90
packaging: fix buildrpm whitespace
Augie Fackler - Oct. 30, 2019, 8:14 p.m.
On Mon, Oct 28, 2019 at 12:37:15AM +0100, Mads Kiilerich wrote:
> # HG changeset patch
> # User Mads Kiilerich <mads@kiilerich.com>
> # Date 1572203819 -3600
> #      Sun Oct 27 20:16:59 2019 +0100
> # Branch stable
> # Node ID c84f1465c44ebc539b803b876206712e0ebd78b4
> # Parent  8c18adcd0177f3ca35f7f20f52f27f5a13ac9f90
> packaging: fix buildrpm whitespace

Queued, many thanks - I have been meaning to try and fix our in-tree
RPM building for a while. Let's plan to switch this to py3 by default
for 5.2.1?
Mads Kiilerich - Oct. 30, 2019, 10:57 p.m.
On 10/30/19 9:14 PM, Augie Fackler wrote:
> On Mon, Oct 28, 2019 at 12:37:15AM +0100, Mads Kiilerich wrote:
>> # HG changeset patch
>> # User Mads Kiilerich <mads@kiilerich.com>
>> # Date 1572203819 -3600
>> #      Sun Oct 27 20:16:59 2019 +0100
>> # Branch stable
>> # Node ID c84f1465c44ebc539b803b876206712e0ebd78b4
>> # Parent  8c18adcd0177f3ca35f7f20f52f27f5a13ac9f90
>> packaging: fix buildrpm whitespace
> Queued, many thanks - I have been meaning to try and fix our in-tree
> RPM building for a while. Let's plan to switch this to py3 by default
> for 5.2.1?


I can see Debian packaging already did switched to py3. So perhaps just 
do the same already now for 5.2.0? Change the buildrpm default to py3 
and provide a --python2 option? While it is late and risky for 5.2.0, it 
seems even more risky to do it for 5.2.1.

I don't know if it makes sense to switch over the old Fedora targets. 
Fedora 31 is out now, 28 was EOL 5 months ago, and 29 is EOL in a month. 
Perhaps just delete them and rely on the generic `make rpm` target instead?

The docker targets are a bit more tricky to make more durable and 
low-maintenance. They can't as easily be generic. But it could perhaps 
be done with something like `make docker-fedora FEDORA=31` .

For centos, we should perhaps keep 5 and 6 on py2 for now ... also 
because we don't yet have means for building our own py3 for these RPMs. 
Building Python is a bit more tricky than building Mercurial, and it 
would require more testing.

/Mads
Augie Fackler - Oct. 31, 2019, 1:16 p.m.
> On Oct 30, 2019, at 18:57, Mads Kiilerich <mads@kiilerich.com> wrote:
> 
> On 10/30/19 9:14 PM, Augie Fackler wrote:
>> On Mon, Oct 28, 2019 at 12:37:15AM +0100, Mads Kiilerich wrote:
>>> # HG changeset patch
>>> # User Mads Kiilerich <mads@kiilerich.com>
>>> # Date 1572203819 -3600
>>> #      Sun Oct 27 20:16:59 2019 +0100
>>> # Branch stable
>>> # Node ID c84f1465c44ebc539b803b876206712e0ebd78b4
>>> # Parent  8c18adcd0177f3ca35f7f20f52f27f5a13ac9f90
>>> packaging: fix buildrpm whitespace
>> Queued, many thanks - I have been meaning to try and fix our in-tree
>> RPM building for a while. Let's plan to switch this to py3 by default
>> for 5.2.1?
> 
> 
> I can see Debian packaging already did switched to py3. So perhaps just do the same already now for 5.2.0? Change the buildrpm default to py3 and provide a --python2 option? While it is late and risky for 5.2.0, it seems even more risky to do it for 5.2.1.

Honestly either way is fine, as long as nothing will be broken or excluded from F31 repos long-term.

> I don't know if it makes sense to switch over the old Fedora targets. Fedora 31 is out now, 28 was EOL 5 months ago, and 29 is EOL in a month. Perhaps just delete them and rely on the generic `make rpm` target instead?
> 
> The docker targets are a bit more tricky to make more durable and low-maintenance. They can't as easily be generic. But it could perhaps be done with something like `make docker-fedora FEDORA=31` .

I'll see if I can poke at this a bit - it feels like it should be doable, though I think we may as well drop all the fedoras prior to 30 since they're EOL or almost-EOL.

> For centos, we should perhaps keep 5 and 6 on py2 for now ... also because we don't yet have means for building our own py3 for these RPMs. Building Python is a bit more tricky than building Mercurial, and it would require more testing.

*nod* Sounds sensible. Thanks again for fixing this stuff up!

> 
> /Mads
>

Patch

diff --git a/contrib/packaging/buildrpm b/contrib/packaging/buildrpm
--- a/contrib/packaging/buildrpm
+++ b/contrib/packaging/buildrpm
@@ -51,7 +51,7 @@  fi
 gethgversion
 
 if [ -z "$type" ] ; then
-   release=1
+    release=1
 else
     release=0.9_$type
 fi