Bug 2284608

Summary:	zlib-ng spec file is using a reserved macro
Product:	[Fedora] Fedora	Reporter:	Tulio Magno Quites Machado Filho <tuliom>
Component:	zlib-ng	Assignee:	Tulio Magno Quites Machado Filho <tuliom>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	high
Version:	rawhide	CC:	aekoroglu, code, davide, fedora, igor.raits, kevin, ljavorsk, mdomonko, ngompa13, packaging-team-maint, pmatilai, tuliom
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2024-06-24 15:31:54 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tulio Magno Quites Machado Filho 2024-06-03 15:08:50 UTC

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

Comment 1 Tulio Magno Quites Machado Filho 2024-06-03 15:10:47 UTC

Notice this issue is blocking packages to reach stable in rawhide because the test that is failing is not waivable.

Comment 2 Cristian Le 2024-06-03 15:14:17 UTC

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

Comment 3 Neal Gompa 2024-06-03 15:46:16 UTC

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.

Comment 4 Panu Matilainen 2024-06-04 08:21:18 UTC

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.

Comment 5 Panu Matilainen 2024-06-04 08:33:41 UTC

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.

Comment 6 Cristian Le 2024-06-04 08:54:57 UTC

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

Comment 7 Tulio Magno Quites Machado Filho 2024-06-04 13:37:17 UTC

Thanks Panu!
I apologize for the noise!

Comment 8 Panu Matilainen 2024-06-04 14:04:09 UTC

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.