Ping @ngompa @kevin

Please report this to the https://pagure.io/rpmdevtools, it is that tool which is responsible for that.

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.

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.

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.

(https://pagure.io/packaging-committee/issue/904)

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?

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 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.