For pre-release software, i.e. with a release number starting with "0.", the auto-rebuild release bump should add a .1 to the end (or bump an existing number at the end).
In this case I have gdl 0.9-0.pre6.fc9. It got bumped to 0.9-1.pre6.fc9. It should be 0.9-0.pre6.fc9.1.
On Tue, 19 Feb 2008 10:16:33 -0700, Orion Poplawski wrote:
For pre-release software, i.e. with a release number starting with "0.", the auto-rebuild release bump should add a .1 to the end (or bump an existing number at the end).
In this case I have gdl 0.9-0.pre6.fc9. It got bumped to 0.9-1.pre6.fc9. It should be 0.9-0.pre6.fc9.1.
However, it should have been
0.9-0.1.pre6%{?dist} ^^ (!)
to begin with, not
0.9-0.pre6%{?dist}
On Tue, 19 Feb 2008 18:30:57 +0100 Michael Schwendt mschwendt@gmail.com wrote:
In this case I have gdl 0.9-0.pre6.fc9. It got bumped to 0.9-1.pre6.fc9. It should be 0.9-0.pre6.fc9.1.
However, it should have been
0.9-0.1.pre6%{?dist} ^^ (!)
to begin with, not
0.9-0.pre6%{?dist}
that is correct. Your original scheme did not follow the guidelines, thus the bumper didn't deal with it as if it were a pre-release. Please follow the guidelines next time.
On Tue, 2008-02-19 at 13:17 -0500, Jesse Keating wrote:
On Tue, 19 Feb 2008 18:30:57 +0100 Michael Schwendt mschwendt@gmail.com wrote:
In this case I have gdl 0.9-0.pre6.fc9. It got bumped to 0.9-1.pre6.fc9. It should be 0.9-0.pre6.fc9.1.
However, it should have been
0.9-0.1.pre6%{?dist} ^^ (!)
to begin with, not
0.9-0.pre6%{?dist}
that is correct. Your original scheme did not follow the guidelines, thus the bumper didn't deal with it as if it were a pre-release. Please follow the guidelines next time.
I have also noticed that all the jpp based java packages have been updated incorrectly, and those are following the fedora jpackage package naming guidelines: http://fedoraproject.org/wiki/Packaging/JPackagePolicy
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Fri, 22 Feb 2008 15:32:00 -0500, Matt Wringe wrote:
In this case I have gdl 0.9-0.pre6.fc9. It got bumped to 0.9-1.pre6.fc9. It should be 0.9-0.pre6.fc9.1.
However, it should have been
0.9-0.1.pre6%{?dist} ^^ (!)
to begin with, not
0.9-0.pre6%{?dist}
that is correct. Your original scheme did not follow the guidelines, thus the bumper didn't deal with it as if it were a pre-release. Please follow the guidelines next time.
I have also noticed that all the jpp based java packages have been updated incorrectly, and those are following the fedora jpackage package naming guidelines: http://fedoraproject.org/wiki/Packaging/JPackagePolicy
And still nobody has said what script was used to bump the spec files. The one in cvs/fedora originally came from either notting/sopwith and was improved for the fedora extras mass-rebuilds. It could be enhanced to support the jpp scheme and also add a "bump-least-significant" fallback for any "invalid" versioning schemes. But if a different and secret script is used, that's not helpful.
On Sat, 23 Feb 2008 00:44:42 +0100 Michael Schwendt mschwendt@gmail.com wrote:
And still nobody has said what script was used to bump the spec files. The one in cvs/fedora originally came from either notting/sopwith and was improved for the fedora extras mass-rebuilds. It could be enhanced to support the jpp scheme and also add a "bump-least-significant" fallback for any "invalid" versioning schemes. But if a different and secret script is used, that's not helpful.
I used the one that was mentioned on list very recently, from cvs/fedora/rebuild-scripts.
Most the jpp packages I looked at seemed fine. Which ones didn't get bumped right?
On Sat, 23 Feb 2008 03:15:16 +0000 (UTC), Kevin Kofler wrote:
Jesse Keating <jkeating <at> redhat.com> writes:
Most the jpp packages I looked at seemed fine. Which ones didn't get bumped right?
They all got bumped to m+1jpp.something instead of mjpp.n+1.
This is supported in cvs now.
According to the Wiki, the numbering scheme seems to be
Xjpp.Y%{?dist}
where Y is to be bumped and X is the original jpackage release.
$ bumpspecfile.py jpackage-utils.spec -2jpp.9%{?dist} +2jpp.10%{?dist}
Also added in cvs is a fallback, where a release string that doesn't match at all is tried to be bumped at the very right, and if that is not possible, ".1" is appended.
Michael Schwendt <mschwendt <at> gmail.com> writes:
Also added in cvs is a fallback, where a release string that doesn't match at all is tried to be bumped at the very right, and if that is not possible, ".1" is appended.
Are you sure you want to autobump Release entries which don't match any of the templates in the guidelines? They could contain really anything, e.g. hardcoded disttags, which "bumping at the very right" could accidentally turn from .fc9 into .fc10, or some other unforeseeable weird stuff.
Kevin Kofler
On Sat, 23 Feb 2008 11:38:17 +0000 (UTC), Kevin Kofler wrote:
Michael Schwendt <mschwendt <at> gmail.com> writes:
Also added in cvs is a fallback, where a release string that doesn't match at all is tried to be bumped at the very right, and if that is not possible, ".1" is appended.
Are you sure you want to autobump Release entries which don't match any of the templates in the guidelines? They could contain really anything, e.g. hardcoded disttags, which "bumping at the very right" could accidentally turn from .fc9 into .fc10, or some other unforeseeable weird stuff.
1) Hardcoded disttags are not permitted in Fedora, afaik.
2) How weird (and in violation of the guidelines) would a release value need to be before the script fails to match at all?
I don't talk about some of the "got it almost right" cases here, such as:
$ bumpspecfile.py testinvalid1.spec WARNING: Bad pre-release versioning scheme! testinvalid1.spec -0.rc2%{?dist} +0.rc2%{?dist}.1
$ bumpspecfile.py testinvalid1.spec WARNING: Bad pre-release versioning scheme! testinvalid1.spec -0.rc2%{?dist}.1 +0.rc2%{?dist}.2
Or:
$ bumpspecfile.py testcvs.spec WARNING: Bad pre-release versioning scheme! testcvs.spec -0.20080101cvs +0.20080101cvs.1
where the current patterns don't match fully. There's room for improvement with very strict regexp that never bump any left number unless it is fully compliant with the Fedora guidelines.
Very special cases like the following are not recognised at all:
rc9.1%{?dist}
One could bump at the very right pos then, too.
On Sat, 23 Feb 2008 16:46:35 +0100, Michael Schwendt wrote:
On Sat, 23 Feb 2008 11:38:17 +0000 (UTC), Kevin Kofler wrote:
Michael Schwendt <mschwendt <at> gmail.com> writes:
Also added in cvs is a fallback, where a release string that doesn't match at all is tried to be bumped at the very right, and if that is not possible, ".1" is appended.
Are you sure you want to autobump Release entries which don't match any of the templates in the guidelines? They could contain really anything, e.g. hardcoded disttags, which "bumping at the very right" could accidentally turn from .fc9 into .fc10, or some other unforeseeable weird stuff.
- Hardcoded disttags are not permitted in Fedora, afaik.
Btw, currently the script tries to match "dot number" and therefore would bump ".fc9" to ".fc9.1" instead.
On Sat, 23 Feb 2008 11:38:17 +0000 (UTC), Kevin Kofler wrote:
Also added in cvs is a fallback, where a release string that doesn't match at all is tried to be bumped at the very right, and if that is not possible, ".1" is appended.
Are you sure you want to autobump Release entries which don't match any of the templates in the guidelines?
Some numbers from a couple of background test-runs with rawhide cvs:
5472 spec files use an ordinary "Release:" tag close to the guidelines
10 spec files do "%define release ..." or "%define RELEASE ..."
6 spec files do "%define rel ..."
19 spec files do "Release: %release_func ..."
1 spec file does "%define baserelease ..."
~38 spec files are macro-overloaded beyond recognition, a few of them even pull %version and %release from %SOURCE1 using awk
Of the 5472, some get the pre-release versioning scheme wrong or use lots of macros to make it less readable (also for any security response team people who may need to touch something like that), e.g.
ghdl.spec : 0.%{ghdlsvnver}svn.7%{?dist} ochusha.spec : 0.%{vendor_rel}.%{strtag}%{?dist} gnome-mount.spec : 0.svn20080225.4%{?dist} libapreq2.spec : 0.rc2.14%{?dist}
*eewh*:
%define rel %{?minorver:0.}%{fedorarel}%{?minorver:.%minorver}
*ouch*:
gdm.spec -0.2008.02.29.3%{?dist} +0.2009.02.29.3%{?dist}
Stuff appended right of the dist-tag could be recognised and deleted to be less ugly,
cups-pdf.spec -6%{?dist}.2 +7%{?dist}.2
but then the bumper would still not round to integer values in corner-cases like
crash.spec -6.0.5 +7.0.5
because the context of the least-significant numbers is unknown.
On 02/23/2008 05:32 AM, Michael Schwendt wrote:
$ bumpspecfile.py jpackage-utils.spec
Can we please get bumpspecfile.py into a fedora package? I don't care if bumpspecfile.py is far from perfect, but at least we can start being imperfect together and maybe try and make it better.
On Sunday 24 February 2008 22:20:10 Christopher Aillon wrote:
On 02/23/2008 05:32 AM, Michael Schwendt wrote:
$ bumpspecfile.py jpackage-utils.spec
Can we please get bumpspecfile.py into a fedora package? I don't care if bumpspecfile.py is far from perfect, but at least we can start being imperfect together and maybe try and make it better.
It would fit into: https://fedorahosted.org/fedora-packager/
Regards, Till
On Mon, 25 Feb 2008 01:05:28 +0100, Till Maas wrote:
On Sunday 24 February 2008 22:20:10 Christopher Aillon wrote:
On 02/23/2008 05:32 AM, Michael Schwendt wrote:
$ bumpspecfile.py jpackage-utils.spec
Can we please get bumpspecfile.py into a fedora package? I don't care if bumpspecfile.py is far from perfect, but at least we can start being imperfect together and maybe try and make it better.
It would fit into: https://fedorahosted.org/fedora-packager/
Or the rpmdevtools package where other useful scripts have gone.
devel@lists.stg.fedoraproject.org
-
Christopher Aillon -
Jesse Keating -
Kevin Kofler -
Matt Wringe -
Michael Schwendt -
Orion Poplawski -
Till Maas