4 p.m.
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
10:44 a.m.
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
3:46 p.m.
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.
https://pagure.io/releng/issue/8411
3:46 p.m.
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
5:56 p.m.
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
8:31 a.m.
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
9 a.m.
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
9:01 a.m.
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
8:37 a.m.
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
8:44 a.m.
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
9:36 a.m.
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
1833
days inactive
1843
days old
rel-eng@lists.fedoraproject.org
10 comments
4 participants
participants (4)
-
Igor Gnatenko -
Mohan Boddu
-
Tim Landscheidt
-
Zbigniew Jędrzejewski-Szmek