This issue appeared first in https://bodhi.fedoraproject.org/updates/FEDORA-2024-cb9b99c813 The changes in that build are small and should not affect how the project is built. It seems that rpm 4.19.91 is always setting `Vendor = pc`. From an official Fedora build we get: $ rpm -qip zlib-ng-2.1.6-5.fc41.x86_64.rpm | grep Vendor Vendor : pc I expected to see: Vendor : Fedora Project I get the same results from a mockbuild, while I expected to see no output from the Vendor field. Reproducible: Always Steps to Reproduce: 1. git clone https://src.fedoraproject.org/rpms/zlib-ng.git 2. cd zlib-ng 3. fedpkg mockbuild 4. rpm -qip results_zlib-ng/2.1.6/5.fc41/zlib-ng-2.1.6-5.fc41.x86_64.rpm | grep Vendor Vendor : pc Actual Results: Vendor : pc Expected Results: No output
Notice this issue is blocking packages to reach stable in rawhide because the test that is failing is not waivable.
(In reply to Tulio Magno Quites Machado Filho from comment #1) > Notice this issue is blocking packages to reach stable in rawhide because > the test that is failing is not waivable. Actually things are a bit worse than that. On rpminspect it is unwaivable, but the rpminspect test on bodhi is not blocking for all packages. This issue though, should be blocking on all packages though. Hopefully though it's only affecting rawhide if the source is indeed the rpm update.
Note that this creates serious problems for Fedora Asahi Remix, as this creates a "vendor change" between Fedora 39~40 and Fedora 41, which will make upgrades fail and break the intent of using DNF's vendor locking mechanism.
This is peculiar, builds in koji generally seem to have the right "Fedora Project" vendor and this seems like an isolated case. I'll look into it of course.
It's an isolated case alright, zlib-ng has this in the spec: %ifarch x86_64 %global vendor pc %else %global vendor unknown %endif Which is telling rpm to use either "pc" or "unknown" as the Vendor. There's a change of behavior from rpm side in that these "auxiliarly" tags like vendor, packager and so on are filled much later to allow for dynamic spec generation, but it's not a regression. Just use a non-reserved macro name instead of "vendor" to solve, that this ever worked was luck rather than intended behavior. Anyway, thanks for the report.
Thanks for the check. I wrote a quick patch [1]. In my search [2] this is the only repo that needs to patched. Hopefully I didn't forget another syntax that could override it like that. [1]: https://src.fedoraproject.org/rpms/zlib-ng/pull-request/19 [2]: https://sourcegraph.com/search?q=context:global+file:.*%5C.spec%24+repo:src.fedoraproject.org+%22%25global+vendor%22&patternType=keyword&sm=0
Thanks Panu! I apologize for the noise!
No worries at all, on the contrary it's important to ensure build failures aren't due to some accidental breakage by rpm. It's both highly useful but also fascinating for me to see what kind of issues people running into, whether rpm regressions or not. These are some of the biggest changes to rpmbuild in 15-20 years.