scfc reported a new issue against the project: `releng` that you are following: `` For mass rebuilds, the `Release:` header is bumped with `rpmdev-bumpspec`. This does not work properly for spec files that are using special magic:
Version: %{major}.%{minor} -Release: %{?gh_date:1%{specrel}.%{?prever}%{!?prever:%{gh_date}git%{gh_short}}}%{!?gh_date:%{specrel}}%{?dist} +Release: %{?gh_date:1%{specrel}.%{?prever}%{!?prever:%{gh_date}git%{gh_short}}}%{!?gh_date:%{specrel}}%{?dist}.1 Summary: PHP code coverage information
Version: %{major}.%{minor} -Release: %{?gh_date:1%{specrel}.%{?prever}%{!?prever:%{gh_date}git%{gh_short}}}%{!?gh_date:%{specrel}}%{?dist}.1 +Release: %{?gh_date:1%{specrel}.%{?prever}%{!?prever:%{gh_date}git%{gh_short}}}%{!?gh_date:%{specrel}}%{?dist}.2 Summary: PHP code coverage information
In Fedora 29, there are `dnf repoquery '*fc29.[1-9]*' | wc -l` = 291 packages where these bumps apparently did not work as expected. While they are benign, they are confusing.
It is probably not possible to come up with a way to reliably bump all imaginable release strings. However, a good indicator that something is amiss is when `rpmdev-bumpspec` wants to add `.1` to the previous:
[tim@passepartout ~/src/fedora/rpms/php-phpunit-PHP-CodeCoverage]$ rpmdev-bumpspec --verbose php-phpunit-PHP-CodeCoverage.spec php-phpunit-PHP-CodeCoverage.spec - %{?gh_date:1%{specrel}.%{?prever}%{!?prever:%{gh_date}git%{gh_short}}}%{!?gh_date:%{specrel}}%{?dist} + %{?gh_date:1%{specrel}.%{?prever}%{!?prever:%{gh_date}git%{gh_short}}}%{!?gh_date:%{specrel}}%{?dist}.1
[tim@passepartout ~/src/fedora/rpms/php-phpunit-PHP-CodeCoverage]$ ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8411
mohanboddu added a new comment to an issue you are following: `` Ping @ngompa @kevin ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8411
The status of the issue: `Version bump is not working properly for a variety of packages` of project: `releng` has been updated to: Closed as Can't Fix by ignatenkobrain.
ignatenkobrain added a new comment to an issue you are following: `` Please report this to the https://pagure.io/rpmdevtools, it is that tool which is responsible for that. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8411
scfc added a new comment to an issue you are following: `` I won't (apart from someone apparently already having done that at rpmdevtools#18):
- It is probably technically impossible to solve this issue from within `rpmdev-bumpspec`. - I'm not using `rpmdev-bumpspec` to produce broken release tags, Release Engineering is. The issue does not lie with `rpmdev-bumpspec`, but with `scripts/mass-rebuild.py` et al.'s use of it. I have outlined above a way to detect when that fails; adding this check to `scripts/mass-rebuild.py` et al. is not rocket science. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8411
mohanboddu added a new comment to an issue you are following: ``
I'm not using rpmdev-bumpspec to produce broken release tags, Release Engineering is. The issue does not lie with rpmdev-bumpspec, but with scripts/mass-rebuild.py et al.'s use of it. I have outlined above a way to detect when that fails; adding this check to scripts/mass-rebuild.py et al. is not rocket science.
What are we gaining from adding the check? We will either skip them from rebuilding (which isn't an option) or somehow rebuild them either manually or automatically. Manually is a cumbersome job and automatically means finding a way to bump the spec which can be fixed in `rpmdev-bumpspec` itself. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8411
zbyszek added a new comment to an issue you are following: `` Making mass-rebuild.py not rebuild packages is the least attractive option imho. Making rpmdev-bumpspec smarter would be attractive, but I don't think it's realistic. But there's another way: with the acceptance of ~ and ^ in rpm-4.15, there should be no need for such crazy macros. Those new operators allow the github date to be finally included in the version field where it belongs, and the release field becomes simple.
So I think @ignatenkobrain is correct to close this bug, because this is not the right place to fix this. Instead, we should work to update the guidelines to use ~ and ^ and then work to switch packages (those 291 that you mention) to the new scheme. Then the problem should be solved. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8411
zbyszek added a new comment to an issue you are following: `` (https://pagure.io/packaging-committee/issue/904) ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8411
scfc added a new comment to an issue you are following: `` Okay, I'll bite :-): Suppose the guidelines are amended, and all spec files are updated to use the new syntax, even those by maintainers who want to keep them identical for Fedora, RHEL, CentOS, etc. where RPM 4.15 might not be used (yet), and `rpmdev-bumpspec` will be able to reliably increment those release tags, how will a regression by someone using macros in the release tag (copy & paste from an old spec file, some obsolete advice on the web, etc.) be detected? ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8411
zbyszek added a new comment to an issue you are following: `` Most likely like you did: by looking for packages where nevra does not match the expected pattern. I'm sure we'll have to do this repeatedly for a long time, because the folklore of release tag manipulation is so deeply ingrained that it will be a while before people accept that it's not needed.
Mass rebuilds are the wrong place to do this. A mass rebuild is scripted, and package builds should not fail if at all possible. In particular, a FTBFS package can block many other packages. If there are things like this, that can be automatically detected, this detection should either be done asynchronously be running some query, or should be added to tools like rpmlint, or ideally both.
``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8411
scfc added a new comment to an issue you are following: `` To me, it feels like a huge waste of human resources to have a machine automatically mangle release tags, a third party asynchronously notice that, create and file 291 pull requests, on occasion wait several months for a reaction by the maintainer (not meaning Remi here), and then repeat this cycle every six months. But if someone specifically wants to do that instead of something else: Fine with me. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/8411
rel-eng@lists.fedoraproject.org
-
Igor Gnatenko -
Mohan Boddu
-
Tim Landscheidt
-
Zbigniew Jędrzejewski-Szmek