Bug 2262430
| Summary: | rpm packaging, with multiple forge sources, fails to unpack correct source/target dirs | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | pgnd <pgnd> |
| Component: | forge-srpm-macros | Assignee: | Maxwell G <maxwell> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | ajax, carl, ffesti, fweimer, igor.raits, j, maxwell, mhroncok, ngompa13, nickc, pmatilai, sipoyare, torsava |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://copr.fedorainfracloud.org/coprs/pgfed/test/builds/ | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2024-02-02 20:06:56 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
pgnd
2024-02-02 18:28:48 UTC
I was going to assign this to forge-srpm-macros, but apparently in Fedora 39, this still lives in redhat-rpm-config :( Anyway, assigning Maxwell. hopefully a bit clearer, e.g., with .spec ... %prep %forgesetup -z 0 %forgesetup -z 1 ... where Packaging variables read or set by %forgemeta ... forgesource0: https://api.github.com/repos/pgnd/testrepo0/tarball/e93e20d forgesetupargs0: -n pgnd-testrepo0-e93e20d ... extractdir0: pgnd-testrepo0-e93e20d ... Packaging variables read or set by %forgemeta ... forgesource1: https://api.github.com/repos/pgnd/testrepo1/tarball/51d7e48 forgesetupargs1: -n pgnd-testrepo1-51d7e48 extractdir1: pgnd-testrepo1-51d7e48 ... then, enterint %prep, Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.TmIXbW @ `%forgesetup -z 0` ... + cd /builddir/build/BUILD + rm -rf pgnd-testrepo0-e93e20d + /usr/lib/rpm/rpmuncompress -x /builddir/build/SOURCES/e93e20d ... + cd pgnd-testrepo0-e93e20d & @ `%forgesetup -z 1` ... + cd /builddir/build/BUILD + rm -rf pgnd-testrepo1-51d7e48 <---- *correct* target + /usr/lib/rpm/rpmuncompress -x /builddir/build/SOURCES/e93e20d <---- *incorrect* target ... + cd pgnd-testrepo1-51d7e48 resulting in RPM build errors: /var/tmp/rpm-tmp.TmIXbW: line 53: cd: pgnd-testrepo1-51d7e48: No such file or directory > I was going to assign this to forge-srpm-macros, but apparently in Fedora 39, this still lives in redhat-rpm-config :( I wanted to apply the same change to Fedora 39, but nobody responded to my PR. I do not plan to make any further changes to the forge macros contained within redhat-rpm-config. I just rebased https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/264 if someone wants to take a look at it. In the meantime, I will retarget this against forge-srpm-macros, as I could reproduce this with the current version of that. Thanks for the report! It seems the issue here is that you're overriding %forgesetupargs (and many of the other macros that %forgemeta set). I'm not sure why you're doing that. The whole point of the forge macros is that they determine those values for you. For the %forgesetupargs case, %forgemeta sets that macro so that the second %forgesetup invocation unpacks the second source archive on top of the first one. You're overriding %forgesetupargs1 to `-n %{archivename1}` which incorrectly tries to unpack the first archive using the top directory name of the second. Usually, the forge macros would set "%forgesetupargs1" to "-T -D -b 1 -n %{extractdir1}" which works as expected.
If you have any further questions, feel free to stop by the forge-srpm-macros mailing list: https://lists.sr.ht/~gotmax23/forge-srpm-macros/ Thanks again!
Can you clarify what's occurring @ + rm -rf pgnd-testrepo1-51d7e48 <---- *correct* target + /usr/lib/rpm/rpmuncompress -x /builddir/build/SOURCES/e93e20d <---- *incorrect* target the `rm` clearly has the correct target the immediately subsequent `rpmuncompress` has the incorrect target since both steps are (?) expanded from the same `-%forgesetup -z 1`, shouldn't both be targeting the same target? I don't fully understand your question. It's unpacking Source0 because that's what you overrode %forgesetupargs1 to do. `%forgesetup -z1` just calls `%setup %{forgesetupargs1}`. You set `%forgesetupargs1` to ` -n %{archivename1}`. Passing `-n` tells `%setup` what the name of the top-level directory in the source archive is, but it still unpacks the first archive (i.e., Source0) unless you pass the appropriate -a / -b flags to change that.
`%forgesetup -z 1`, this line + rm -rf pgnd-testrepo1-51d7e48 'uses' the 2nd target. what 'tells' the `rm` to use the 2nd target, if not `forgesetup` ? the very next line, + /usr/lib/rpm/rpmuncompress -x /builddir/build/SOURCES/e93e20d "switches back to", and uses the 1st target. http://ftp.rpm.org/max-rpm/s1-rpm-inside-macros.html#S2-RPM-INSIDE-SETUP-MACRO provides more information about how the %setup macro works and can explain it better than I can. > + rm -rf pgnd-testrepo1-51d7e48 This has nothing to do with "targets." You explicitly "told" the %setup macro (by passing `-n pgnd-testrepo1-51d7e48`) that `pgnd-testrepo1-51d7e48` is the top-level directory of the archive. %setup tries to clean up that top-level directory name before decompressing the archive. That is separate from the decompression of the new archive which defaults to Source0. |