Created attachment 560891 [details] Spec file exhibiting this problem Try bumpspec on in mysql-workbench repository on commit d792f17f8dfc616ba2eecd924884ca3526fdb35e: $ rpmdev-bumpspec -c 'Test' mysql-workbench.spec You get this change: diff --git a/mysql-workbench.spec b/mysql-workbench.spec index a98892e..a8dab75 100644 --- a/mysql-workbench.spec +++ b/mysql-workbench.spec @@ -111,7 +111,7 @@ Summary: Scripts for managing and administering MySQL servers # Not yet published (else will be package separatly) # see ext/mysql-utilities/CHANGES.txt Version: 1.0.3 -Release: 0.%{mw_version}%{?dist}.%{mw_release} +Release: 0.%{mw_version}%{?dist}.%{mw_release}.1 BuildArch: noarch BuildRequires: python-devel >= 2.4 @@ -257,6 +257,9 @@ update-desktop-database &> /dev/null || : %changelog +* Fri Feb 10 2012 Petr Pisar <ppisar> - 5.2.37-4 +- Test + * Wed Feb 8 2012 Toshio Kuratomi <toshio> - 5.2.37-4 - Remove the python-sqlite2 dep as mysql-workbench will work with sqlite3 from the stdlib See the changelog header. And this is not everything: $ fedpkg --dist f18 verrel mysql-workbench-5.2.37-4.fc18 This is because rpmdev-bumpspec changes second sub-package only and it does not update main package release: $ grep Release: mysql-workbench.spec Release: %{mw_release}%{?dist} Release: 0.%{mw_version}%{?dist}.%{mw_release}.1 But fedpkg
Bumping subpackage releases is now implemented in upstream git: https://fedorahosted.org/rpmdevtools/changeset/8ab7ef7 Will look into the other issue later - in the future, please file separate bugs for separate issues for easier tracking.
rpmdevtools-8.3-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/rpmdevtools-8.3-1.fc18
rpmdevtools-8.3-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/rpmdevtools-8.3-1.fc17
rpmdevtools-8.3-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/rpmdevtools-8.3-1.fc16
Package rpmdevtools-8.3-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing rpmdevtools-8.3-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-13208/rpmdevtools-8.3-1.fc18 then log in and leave karma (feedback).
This is not fixed in rpmdevtools-8.3-1.fc17.
> -Release: 0.%{mw_version}%{?dist}.%{mw_release} > +Release: 0.%{mw_version}%{?dist}.%{mw_release}.1 This is not confusion, but the catch-all fallback that adheres to the Fedora Packaging Guidelines. Bumping the least significant portion of Release is the safe thing to do in such as case: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Minor_release_bumps_for_old_branches The script would have to become much more complex to try to guess what all those macros in "Release" do and whether it would be right to bump %mw_version and/or %mw_release, for example. The subpackage versioning scheme in the attached spec file does not match existing guidelines. It (ab)uses %version = %mw_version to construct some pre-release after the 0. prefix: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages %global mw_version 5.2.37 %global mw_release 4 %global tarversion gpl-5.2.37-src %global srcversion gpl-5.2.37-src Version: %{mw_version} Release: %{mw_release}%{?dist} %package -n mysql-utilities Version: 1.0.3 Release: 0.%{mw_version}%{?dist}.%{mw_release}
I have not problem with where you put the number. I have problem that you do not bump the main package. You do not need to understand the macros. Just find first Release tag before any %package and append `.1' (or increase last digit literal if exists (which is not this case)).
Created attachment 611412 [details] proposed fix Here's one fix proposal.
rpmdevtools-8.3-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
rpmdevtools-8.3-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
rpmdevtools-8.3-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to comment #9) > Here's one fix proposal. Appears to fix the test case and I didn't notice any regressions, thanks. Could you supply a commit message for the patch and I'll apply it?
Hmmm, a commit message for a fix like that could be: Really bump all Release values in spec file, either as recognized or via fallback.
Thanks, pushed.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I still don't get updated release string at main package. Tested with rpmdevtools-8.3-1.fc17.noarch on specfile attached in this bug report. It does not touch the Release string of main package.
rpmdevtools-8.3-1 cannot fix it, because it has been released before the patch has been applied upstream: https://fedorahosted.org/rpmdevtools/browser
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still issue in F18.
rpmdevtools-8.4-1.fc20,devscripts-2.13.4-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/rpmdevtools-8.4-1.fc20,devscripts-2.13.4-2.fc20
rpmdevtools-8.4-1.fc20, devscripts-2.13.4-2.fc20 has been pushed to the Fedora 20 testing repository.
rpmdevtools-8.4-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/rpmdevtools-8.4-2.fc20
In the current ''bad use of "Dist Tag" in some packages of rawhide'' thread on devel@ list, I've learned that the fix for this bug caused unwanted breakage. It bumps all release values (so subpackages with own Release tags are affected, too), but as a side-effect it bumps values in _competing_ places. For example: %global baserelease 5 Release: %{?rhel:0.}%{baserelease}%{?dist} It bumps both lines, because there is no method that determines whether subpackages are involved: %global baserelease 6 Release: %{?rhel:0.}%{baserelease}%{?dist}.1 That's harmless, but a superfluous least-significant bump. I'll be necessary to revise the patch.
Created attachment 819145 [details] Don't bump Release tag lines that are affected by a bumped macro definition already.
One minor weak spot that remains is if a packager uses several "release" macros with a different prefix (whether for subpackages or whatever), e.g. %global release 5 %global baserelease 2 and in the actual Release tag one could not search for '%{release}' because of multiple ways to write that, with/without braces, with '?' prefix, ...
rpmdevtools-8.4-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
I didn't notice comments 24-26 until now, prompted by bug 1043269. Patch from comment 25 applied in git, but unfortunately kernel.spec is apparently exactly the remaining weak spot :(