Bug 2299818
| Summary: | regression in %setup | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dan Horák <dan> |
| Component: | rpm | Assignee: | Packaging Maintenance Team <packaging-team-maint> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | igor.raits, mdomonko, packaging-team-maint, pbrobinson, pmatilai |
| Target Milestone: | --- | Keywords: | Regression |
| 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-08-01 07:15:14 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 2300612 | ||
Most likely this:
> %global builddir %{_builddir}/%{srcdir}
%builddir is a rpm-defined macro in >= 4.20 and redefining it to something else will break stuff. Rename that to "mybuilddir" or something.
yes, renaming builddir solves the issue, thanks for the hint Ack, thanks for confirming. Ideally you'd get a meaningful warning/error message when trying to override system macros of course - and you actually do for built-in macros (eg you can't override %define), but there's nothing like that for others at the moment. Thanks, I was going to suggest something like that about emitting a warning in such cases, like for example the C/GCC preprocessor does about redefined macros. Yup. Unlike C preprocessor macros, rpm macros are by design stackable and tons of functionality depends on that behavior, so we can't just error/warn on any macro redefinition. There'd need to be some "read-only" (or non-stackable) attribute that can be applied to some carefully selected macros. And now I remember there actually is a related ticket already: https://github.com/rpm-software-management/rpm/issues/2314 |
The cross-gcc package is using %global srcdir gcc-%{version}-%{DATE} Source0: %{srcdir}.tar.xz %setup -q -n %{srcdir} -c cd %{srcdir} ... which worked fine until the last build when rpm 4.19.92 has been used. From the build.logs is clear that handling of %setup is completely different. See https://src.fedoraproject.org/rpms/cross-gcc/blob/rawhide/f/cross-gcc.spec#_270 for the spec file. ... Start: rpmbuild cross-gcc-14.1.1-1.fc41.1.src.rpm Building target platforms: aarch64 Building for target aarch64 setting SOURCE_DATE_EPOCH=1721174400 Executing(%mkbuilddir): /bin/sh -e /var/tmp/rpm-tmp.f1HpC5 + umask 022 + cd /builddir/build/BUILD/cross-gcc-14.1.1-build/gcc-14.1.1-20240508 /var/tmp/rpm-tmp.f1HpC5: line 33: cd: /builddir/build/BUILD/cross-gcc-14.1.1-build/gcc-14.1.1-20240508: No such file or directory compared to Building target platforms: x86_64 Building for target x86_64 setting SOURCE_DATE_EPOCH=1715558400 Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.QE22kf + umask 022 + cd /builddir/build/BUILD + cd /builddir/build/BUILD + rm -rf gcc-14.1.1-20240508 + /usr/bin/mkdir -p gcc-14.1.1-20240508 + cd gcc-14.1.1-20240508 + /usr/lib/rpm/rpmuncompress -x /builddir/build/SOURCES/gcc-14.1.1-20240508.tar.xz + STATUS=0 ... in the last successful build (https://koji.fedoraproject.org/koji/buildinfo?buildID=2451537) using rpm 4.19.1. Reproducible: Always