-
Notifications
You must be signed in to change notification settings - Fork 359
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RPM 4.20.0 ALPHA2 #3107
Merged
Merged
RPM 4.20.0 ALPHA2 #3107
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This makes the file mtime more reproducible and consistent. The package build time is set before the build is started, so every new file will get the same time. (cherry picked from commit efdc489)
Adapt the test cases. Also add a test for the new clamp_to_buildtime policy. (cherry picked from commit 9059e6a)
(cherry picked from commit aa7c57c)
(cherry picked from commit 2fe4a48)
(cherry picked from commit 6ea1082)
C++ doesn't like this... (cherry picked from commit b75565a)
(cherry picked from commit 495552c)
In particular, spec->nextline is written to, so pointing it to a string literal is undefined behavior. NULL seems to achieve the same. (cherry picked from commit 9eb8490)
rpmTag doesn't include anything suitable for a sentinel value, so don't use it in array initializers. rpmTagVal works for that, but it's an unsigned type so use 0 instead of -1. (cherry picked from commit 7bb2dcd)
(cherry picked from commit 5bf65de)
rpmTagVal is unsigned so we can't really have these -1's in there. Tag works for this purpose just as well - assuming I spotted all the explicit comparisons to -1 in the depMsgs code. (cherry picked from commit 4d63588)
(cherry picked from commit 1e97f44)
(cherry picked from commit 850b301)
(cherry picked from commit d4b0663)
(cherry picked from commit 401d845)
This hack here is illegal in c++. Just strdup() the silly little string, it's not like this is a performance critical spot. (cherry picked from commit 3a2b04c)
This really belongs to a separate function in the first place, and doing so allows us to turn 'b' into a const char *, which in turn makes the assignment to string literal "" in the url2path case legitimate. Fun times and no functional changes. (cherry picked from commit 7445a09)
Forward declarations to structs like we have in rpmio isn't legitimate C++, as a minimal bandaid solution declare them as extern in the internal header, and limit visibility. (cherry picked from commit 5010191)
Otherwise we'd need casts for each of these accesses, having a function allows doing more if necessary. (cherry picked from commit f75cd15)
Cleaner than void pointer and avoid casting. (cherry picked from commit 9a345d1)
(cherry picked from commit ce6c381)
(cherry picked from commit 38b2602)
(cherry picked from commit bb24c99)
(cherry picked from commit ace5dc5)
ARGV_const_t is defined the way it is for compatibility with exec*(), which expects "char *argv[]" arguments, as explained in eg https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html Since that const mismatch is inherently unfixable, fix the place that we can - the pointers to string literals in our structs - and cast away what we cannot hope to fix. (cherry picked from commit 8a141a1)
Capital .C is sometimes used for C++ which this file certainly is not... (cherry picked from commit fbcc57c)
(cherry picked from commit 689554a)
(cherry picked from commit 8866314)
(cherry picked from commit 4174de5)
Moving logic from switch-cases to data structures is always good, and so is reducing duplication of names and the like. (cherry picked from commit d5c8423)
The append and prepend modes got added before the declarative Buildsystem, and did not get thoroughly tested with it. The existing %build -a test didn't actually work but automake handling the build in %install masked the issue embarrasingly. As the Buildsystem is parsed after everything else, there's no way the previous append/prepend implementation could work correctly with it. Do what we should've done from the start: collect any prepend/append stuff into separate data structures and apply them after everything else has been parsed. This also lifts the artificial sounding restriction wrt the corresponding main section:it's really the right thing to do, even if it's a bit more code. Make the tests wrt buildsystem much more thorough to ensure it all really works, blush. Fixes: rpm-software-management#3024 (cherry picked from commit bf46dcf)
We define two new test macros RPMOUTPUT_SEQUOIA and RPMOUTPUT_LEGACY to make it easier to write parser dependent test output in the test cases. (cherry picked from commit 68d0f31)
freeArgs() only popped any local macros once, so if a local macro was pushed multiple times, whether through %define or multiple identical options getting passed, we leaked any remaining macros to the outside scope. Simply pop the local macros in a loop to fix. Have the internal popMacro() return the previous pointer (if any) to simplify the job. We even had an expected-fail test for this, now passing, but add a more straightforward reproducer too. This bug was circa 26 years old. Some might call it vintage at this point. Fixes: rpm-software-management#3056 (cherry picked from commit 695b5c2)
rpmlog() predates rvasprintf() by something like two decades, but no reason not to use it now. One malloc() down, yay. (cherry picked from commit e2722fd)
(cherry picked from commit 667e32c)
If sources or patches in the spec are defined via a macro that does not yet exist, it'll still work for building if the macro has been defined by that time as there's another round of expansion there. But this can leave the source/patch names inserted to the header disagreeing with what actually ended up in the source package, eg in the testcase you'd previously get '%{somemacro}-2.0.tar.gz' in the header whereas the src.rpm had the right contents. While defining sources this way seems mad and brittle, it does actually work for building rpms and there's a whole ecosystem of packages relying on it in Fedora. So lets at least be consistent about it, and re-expand the source paths once more before inserting in the header, because that's what happens for them in the actual build as well. Originally reported at https://bugzilla.redhat.com/show_bug.cgi?id=2233878 (cherry picked from commit b8d8bfa)
This causes more issues than it solves, at least presently. For one, when BuildArch is used it typically causes the path to disagree with the actual arch (eg on noarch packages). Which looks weird and causes yet other issues in turn. The other issue, raised by Neal Gompa, is that it can cause superfluous path differences in noarch subpackages, which sharing the noarch package across multiple architectures in at least koji. Use -build suffix instead of %{_arch}. -build may seem redundant since by default it's in BUILD directory already, but this makes it more obvious in cases where the default is overridden (eg fedpkg overrides to current directory), and helps differentiating it from the %buildsubdir directory commonly created by %setup. Suggested-by: Neal Gompa <[email protected]> (cherry picked from commit dde4fe5)
When BuildArch is encountered during spec parse, rpm recurses the parse, but this doesn't reset/reload the global configuration and macros to match. So eg a "BuildArch: noarch" package gets built with a dramatically different macros depending on whether "--target noarch" was used or not, whereas people expect it to be the same - after all we give zero indication that anything might be wrong when --target wasn't specified. Automatically detect and handle this condition in the rpmbuild tool: if the spec parse architecture disagrees with our loaded configuration, request a reparse with reloaded configuration for the matching target. This ensures 'rpmbuild -bb noarch.spec' and 'rpmbuild -bb --target noarch noarch.spec' run with the same exact configuration. Doing this also fixes the situation where build-time macro expansion of build scriptlets (for template bits and dynamically generated spec parts) yields totally different (bogus) than in the initial spec parse. This also goes for RPM_ARCH environment and similar. Avoid --undefine for dependency generation test, it doesn't work. --undefine with --target was always broken, now it's just more visible since it automatically applies to BuildArch too. Fixing that is a separate matter (rpm-software-management#3070). A more sophisticated fix could be having a stack of macro contexts that we copy, push and pop as necessary. That ought to solve the undefine too. Fixes: rpm-software-management#3049 (cherry picked from commit 96467dc)
While these were necessary to get things going, they are only counterproductive now: we want to be able to freely use C++ features inside rpm. (cherry picked from commit 18f7e53)
rpmfi always internally stores 64bit sizes since 4.6.0, there's no reason to do anything else with replaced sizes either. (cherry picked from commit 0f6ed3c)
Realize that rpmExpand() can be passed everything that rstrscat(), only it expands too. Silly me. (cherry picked from commit 570f3b6)
There's no reason %specpartsdir should be dependent on %setup use, just create it when we create the build directory too. Update tests accordingly. The spec parse test is noteworthy, the specparts dir creation no longer shows up in spec parse output, which certainly is the way it should be: this is rpm internal infrastructure stuff and nothing to do with spec *parse*, this all only takes place during builds. Fixes: rpm-software-management#3063 (cherry picked from commit f3f9f2c)
All these years, enabling debuginfo has required distros to hijack the spec %install section with a macro like this: %install %{?_enable_debug_packages:%{?buildsubdir:%{debug_package}}}\ %%install\ %{nil} This for a widely used, longtime upstream supported feature is just gross, and also very non-obvious, feeble and whatnot. And totally prevents the new append/prepend options from being used with %install. Take advantage of several newish features to make this happen: we need expressions to properly handle the numeric %_enable_debug_packages value from a macro, and if enabled, output the debuginfo template as a dynamic .specpart. Enable debuginfo on Linux by default in the platform configuration. Notably noarch should not have debuginfo so it's disabled in the platform configuration - since 96467dc we can now actually rely on the platform configuration being valid, so we can drop the "%ifnarch noarch" from the debug package check. Further streamlining should be possible. Note that the old %install hack MUST BE REMOVED from distros now. As a nice bonus, this makes debuginfo work for packages that don't use %setup. Add an explicit test for this in the "rpmbuild %caps" test. specstep.spec needs to be made noarch here, otherwise it'll now try to produce debuginfo and fail. Co-authored-by: Florian Festi <[email protected]> Fixes: rpm-software-management#2204 Fixes: rpm-software-management#1878 (cherry picked from commit 8535694)
os-release parsing is only needed for OCI usage, so move it inside the appropriate branch. Saves some operations at build time when not needed, and also it is necessary as not all OSes define VERSION_ID (e.g.: Debian Unstable and Archlinux) (cherry picked from commit 71f2ca4)
Multiple tests are failing on Fedora 40 due to their distro-wide C modernization effort, which cause our ancient "hello world" package to fail due to implicit printf() function usage. There are two separate issues here: - hello-autopatch.spec had off-by-one in its patch application, causing the modernization patch to not apply (see rpm-software-management#3093 for the reason) - others were using the original hello-1.0-1.src.rpm from 2007 with some very outdated practises, code and md5 hashes Update the src.rpm, removing silly fubar while we're at it. Regenerated now on x86_64 so adjust the test-expectation, and update the python archive test to calculate sha256 instead. And, fix the autopatch test numbers. (cherry picked from commit ed1f2da)
This keeps the old behaviour of overriding the cookie. This may not me correct as the code looks like it reads the cookie from the srpm when doing rpmbuild --rebuild for the purpose of preserving it. Otoh the current behaviour with overriding it even in this case has been around for years. This whole cookie business seems to have some other issues, too, and needs further investigation. Here we are only trying to fix the memory leak. (cherry picked from commit 54a3912)
Move the enablement logic to %__spec_install_template where it can be buried with relatively little danger of being overridden by distros or packagers. It's moderately annoying as the logic isn't no longer neatly in one spot, but %__spec_install_post is commonly overridden by distros and even packages, and in particular we don't want to have packages copy-paste all this stuff along, because that makes making any changes to this stuff even harder than it already is. This should be entirely backwards compatible with all the pre-existing %__spec_install_post overrides. Co-authored-by: Florian Festi <[email protected]> (cherry picked from commit 69c837a)
Apply the attributes in applyAttr() as per the name, and pass *that* index array to rpmfcHelper() which only needs to concern itself with generating the path arrays as per the used protocol. No functional changes, doing this in "raw C" because this refactor is worth cherry-picking to 4.20 too, but also because doing this first makes converting to STL easier. (cherry picked from commit 4fc4ee9)
There were no tests whatsoever for versioned file dependency normalization, add some. This reveals that only filter unversioned dependencies, but we do not filter multiple versions. I don't know whether this is intended or not, but considering this is only done for requires, recommends and suggests, we probably should. (cherry picked from commit fac825c)
Commit 5ce5604 added a new public API function so bump the minor lib version, "pin" the new test hashes also.
Le ven. 17 mai 2024 à 13:37, Michal Domonkos ***@***.***> a
écrit :
Merged #3107 <#3107>
into rpm-4.20.x.
—
Reply to this email directly, view it on GitHub
<#3107 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAXGVEIQAUGIDQRJCUCKQETZCXTXBAVCNFSM6AAAAABH34XQOWVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJSHA2DMOBZHAZTAOA>
.
You are receiving this because you are subscribed to this thread.
We are hitting 3 issues on Mageia with 4.20.x.
Note that we all those upstream patches have been backported:
0001-Ensure-noarch-packages-don-t-get-debuginfo.patch
0001-Fix-noprep-regression-from-introducing-mkbuilddir.patch
0002-Drop-an-accidentally-added-duplicated-test.patch
0003-Make-build-in-place-much-less-of-a-hack-and-also-wor.patch
0001-Fix-incomplete-header-on-plain-src.rpm-build-modes-r.patch
0001-Hammer-in-no-debuginfo-for-noarch-packages-damn-it-r.patch
0001-Fix-regression-on-subpackage-debuginfo-RPMTAG_SOURCE.patch
1) signatures being refused
This one seems to be on Mageia :
error: Verifying a signature using certificate
00EDB89585B012A8916F0DF8B742FA8B80420F66 (Mageia Packages <
***@***.***>):
1. Certificiate B742FA8B80420F66 invalid: certificate is not alive
because: The primary key is not live
because: Expired on 2012-03-13T12:10:11Z
2. Key B742FA8B80420F66 invalid: key is not alive
because: The primary key is not live
because: Expired on 2012-03-13T12:10:11Z
However this break "urpmi --no-verify" which used to behave like rpm
--no-verify
But now only rpm --nosignature can bypass this check, whereas rpm
--no-verify used to do the same, which looks like regression ?
2) this breaks perl-RPM4's testsuite:
See
https://gitweb.mageia.org/software/rpm/perl-RPM4/tree/RPM4/t/04spec.t#n57
This can be run with: cd RPM4; perl Makefile.PL; make && make test
With rpm-4.19:
ok 13 - simulate rpm -bp (check prep)
Executing(%build): /bin/sh -e /tmp/7ICL2x4Fnn/rpm-tmp.MpqXIY
With rpm-4.20:
+not ok 13 - simulate rpm -bp (check prep)
+# Failed test 'simulate rpm -bp (check prep)'
+# at t/04spec.t line 57.
+Executing(%build): /bin/sh -e /tmp/Cb7Sykk9CP/rpm-tmp.H778zX
+/tmp/Cb7Sykk9CP/rpm-tmp.H778zX: line 31: cd:
/tmp/Cb7Sykk9CP/test-rpm-1.0-build: No such file or directory
+error: Bad exit status from /tmp/Cb7Sykk9CP/rpm-tmp.H778zX (%build)
There's a regression here: it doesn' create the directory anymore.
Is this a rpm regression or does RPM4 needs to be adjusted?
Both builddir and topdir are absolute
The test spec file it loads is
https://gitweb.mageia.org/software/rpm/perl-RPM4/tree/RPM4/t/test-rpm.spec
I'd really like to have a feedback for this one.
3) urpmi testsuite fails b/o of missing debuginfo:
error: Empty %files file
/home/tv/mga/git/mga/urpmi/t/tmp/BUILD/a-1-build/debugsourcefiles.list
error: Empty %files file
/home/tv/mga/git/mga/urpmi/t/tmp/BUILD/b-1-build/debugsourcefiles.list
But it's silly to try to extract debuginfo when there's no
I could make those pkgs noarch or set debug_package to %{nil}
On second though I wonder why this wasn't an issue before ?
I fixed those ones in urpmi.
But then I'm hitting this one:
error: Bad exit status from /home/tv/mga/git/mga/urpmi/t/tmp/rpm-tmp.h09qUo
(%install)
# Failed test 'rpmbuild --quiet --define '_topdir
/home/tv/mga/git/mga/urpmi/t/tmp' --define '_tmppath
/home/tv/mga/git/mga/urpmi/t/tmp' -bb --clean --nodeps --define
'__os_install_post %nil' --define 'rpm_version %(rpm -q --queryformat
"%{VERSION}" rpm|sed -e "s/\\.//g")' data/SPECS/buildroot_default.spec'
will
This can be reproduced by running:
rpmbuild -bb --clean t/data/SPECS/buildroot_default.spec
I've attached the rpmbuild output for both 4.19 & 4.20 which shows the
regression
Compare:
rpm-4.19.1.1:
$ rpm --eval %buildroot
/home/tv/rpmbuild/BUILDROOT/%{NAME}-%{VERSION}-%{RELEASE}.x86_64
rpm-4.19.91:
$ rpm --eval %buildroot
%buildroot
I just saw commit 0310a23 (" Fix a
%buildroot regression on an early %__spec_install_pre %global override"),
I'll try again with that commit backported, even though the context is
different as it happens quite a lot later, at the end of the build process.
See you
Message ID: <rpm-software-management/rpm/pull/3107/issue_event/12846898308@
github.com>
$ LC_ALL=C rpmbuild -bb --clean t/data/SPECS/buildroot_default.spec
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.DxJCOX
+ umask 022
+ cd /home/tv/rpmbuild/BUILD
+ '[' 1 -eq 1 ']'
+ '[' /home/tv/rpmbuild/BUILDROOT/buildroot-1-1.x86_64 '!=' / ']'
+ rm -rf /home/tv/rpmbuild/BUILDROOT/buildroot-1-1.x86_64
++ dirname /home/tv/rpmbuild/BUILDROOT/buildroot-1-1.x86_64
+ mkdir -p /home/tv/rpmbuild/BUILDROOT
+ mkdir /home/tv/rpmbuild/BUILDROOT/buildroot-1-1.x86_64
+ '[' 1 -eq 1 ']'
++ echo /home/tv/rpmbuild/BUILDROOT/buildroot-1-1.x86_64
++ sed 's!//!/!'
+ wanted=/home/tv/rpmbuild/BUILDROOT/buildroot-1-1.x86_64
+ echo 'buildroot should be /home/tv/rpmbuild/BUILDROOT/buildroot-1-1.x86_64 instead of /home/tv/rpmbuild/BUILDROOT/buildroot-1-1.x86_64'
buildroot should be /home/tv/rpmbuild/BUILDROOT/buildroot-1-1.x86_64 instead of /home/tv/rpmbuild/BUILDROOT/buildroot-1-1.x86_64
+ '[' /home/tv/rpmbuild/BUILDROOT/buildroot-1-1.x86_64 = /home/tv/rpmbuild/BUILDROOT/buildroot-1-1.x86_64 ']'
+ '[' /home/tv/rpmbuild/BUILDROOT/buildroot-1-1.x86_64 = /home/tv/rpmbuild/BUILDROOT/buildroot-1-1.x86_64 ']'
++ echo /home/tv/rpmbuild/BUILDROOT/buildroot-1-1.x86_64
+ '[' /home/tv/rpmbuild/BUILDROOT/buildroot-1-1.x86_64 = /home/tv/rpmbuild/BUILDROOT/buildroot-1-1.x86_64 ']'
+ mkdir -p /home/tv/rpmbuild/BUILDROOT/buildroot-1-1.x86_64/etc
+ echo foo
+ /usr/lib/rpm/check-buildroot
+ '[' -n '' ']'
+ /usr/share/spec-helper/clean_files
+ '[' -n '' ']'
+ /usr/share/spec-helper/compress_files .xz
+ '[' -n '' ']'
+ /usr/share/spec-helper/relink_symlinks
+ '[' -n '' ']'
+ /usr/share/spec-helper/clean_perl
+ '[' -n '' ']'
+ /usr/share/spec-helper/lib_symlinks
+ '[' -n '' ']'
+ /usr/share/spec-helper/gprintify
+ '[' -n '' ']'
+ /usr/share/spec-helper/fix_mo
+ '[' -n '' ']'
+ /usr/share/spec-helper/fix_pamd
+ '[' -n '' ']'
+ /usr/share/spec-helper/remove_info_dir
+ '[' -n '' ']'
+ /usr/share/spec-helper/fix_eol
+ '[' -n '' ']'
+ /usr/share/spec-helper/check_desktop_files
+ '[' -n '' ']'
+ /usr/share/spec-helper/check_elf_files
+ /usr/lib/rpm/brp-strip /usr/bin/strip
+ /usr/lib/rpm/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump
+ /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/check-rpaths
+ /usr/lib/rpm/brp-remove-la-files
+ /usr/lib/rpm/redhat/brp-mangle-shebangs
+ env -u SOURCE_DATE_EPOCH /usr/lib/rpm/redhat/brp-python-bytecompile '' 1 0 -j8
+ /usr/lib/rpm/redhat/brp-python-hardlink
Processing files: buildroot-1-1.x86_64
Provides: buildroot = 1-1 buildroot(x86-64) = 1-1
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/tv/rpmbuild/BUILDROOT/buildroot-1-1.x86_64
Wrote: /home/tv/rpmbuild/RPMS/x86_64/buildroot-1-1.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.ic66NI
+ umask 022
+ cd /home/tv/rpmbuild/BUILD
+ /usr/bin/rm -rf /home/tv/rpmbuild/BUILDROOT/buildroot-1-1.x86_64
+ RPM_EC=0
++ jobs -p
+ exit 0
Executing(rmbuild): /bin/sh -e /var/tmp/rpm-tmp.VAy57Q
+ umask 022
+ cd /home/tv/rpmbuild/BUILD
+ rm -rf '/home/tv/rpmbuild/BUILD/%{buildsubdir}-SPECPARTS'
+ RPM_EC=0
++ jobs -p
+ exit 0
$ LC_ALL=C rpmbuild -bb --clean t/data/SPECS/buildroot_default.spec
Executing(%mkbuilddir): /bin/sh -e /var/tmp/rpm-tmp.JMrjIu
+ umask 022
+ cd /home/tv/rpmbuild/BUILD/buildroot-1-build
+ test -d /home/tv/rpmbuild/BUILD/buildroot-1-build
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w /home/tv/rpmbuild/BUILD/buildroot-1-build
+ /usr/bin/rm -rf /home/tv/rpmbuild/BUILD/buildroot-1-build
+ /usr/bin/mkdir -p /home/tv/rpmbuild/BUILD/buildroot-1-build
+ /usr/bin/mkdir -p /home/tv/rpmbuild/BUILD/buildroot-1-build/SPECPARTS
+ RPM_EC=0
++ jobs -p
+ exit 0
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.1a2BZR
+ umask 022
+ cd /home/tv/rpmbuild/BUILD/buildroot-1-build
+ '[' 1 -eq 1 ']'
+ '[' /home/tv/rpmbuild/BUILD/buildroot-1-build/BUILDROOT '!=' / ']'
+ rm -rf /home/tv/rpmbuild/BUILD/buildroot-1-build/BUILDROOT
++ dirname /home/tv/rpmbuild/BUILD/buildroot-1-build/BUILDROOT
+ mkdir -p /home/tv/rpmbuild/BUILD/buildroot-1-build
+ mkdir /home/tv/rpmbuild/BUILD/buildroot-1-build/BUILDROOT
+ '[' 1 -eq 1 ']'
++ echo '%{_buildrootdir}/buildroot-1-1.x86_64'
++ sed 's!//!/!'
+ wanted='%{_buildrootdir}/buildroot-1-1.x86_64'
+ echo 'buildroot should be %{_buildrootdir}/buildroot-1-1.x86_64 instead of /home/tv/rpmbuild/BUILD/buildroot-1-build/BUILDROOT'
buildroot should be %{_buildrootdir}/buildroot-1-1.x86_64 instead of /home/tv/rpmbuild/BUILD/buildroot-1-build/BUILDROOT
+ '[' /home/tv/rpmbuild/BUILD/buildroot-1-build/BUILDROOT = '%{_buildrootdir}/buildroot-1-1.x86_64' ']'
+ echo 'buildroot should be %{_buildrootdir}/buildroot-1-1.x86_64 instead of /home/tv/rpmbuild/BUILD/buildroot-1-build/BUILDROOT'
buildroot should be %{_buildrootdir}/buildroot-1-1.x86_64 instead of /home/tv/rpmbuild/BUILD/buildroot-1-build/BUILDROOT
+ exit 1
error: Bad exit status from /var/tmp/rpm-tmp.1a2BZR (%install)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.1a2BZR (%install)
|
Le sam. 1 juin 2024 à 17:59, Thierry Vignaud ***@***.***> a
écrit :
Le ven. 17 mai 2024 à 13:37, Michal Domonkos ***@***.***> a
écrit :
> Merged #3107 <#3107>
> into rpm-4.20.x.
>
> —
> Reply to this email directly, view it on GitHub
> <#3107 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAXGVEIQAUGIDQRJCUCKQETZCXTXBAVCNFSM6AAAAABH34XQOWVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJSHA2DMOBZHAZTAOA>
> .
> You are receiving this because you are subscribed to this thread.
>
We are hitting 3 issues on Mageia with 4.20.x.
Note that we all those upstream patches have been backported:
0001-Ensure-noarch-packages-don-t-get-debuginfo.patch
0001-Fix-noprep-regression-from-introducing-mkbuilddir.patch
0002-Drop-an-accidentally-added-duplicated-test.patch
0003-Make-build-in-place-much-less-of-a-hack-and-also-wor.patch
0001-Fix-incomplete-header-on-plain-src.rpm-build-modes-r.patch
0001-Hammer-in-no-debuginfo-for-noarch-packages-damn-it-r.patch
0001-Fix-regression-on-subpackage-debuginfo-RPMTAG_SOURCE.patch
1) signatures being refused
This one seems to be on Mageia :
error: Verifying a signature using certificate
00EDB89585B012A8916F0DF8B742FA8B80420F66 (Mageia Packages <
***@***.***>):
1. Certificiate B742FA8B80420F66 invalid: certificate is not alive
because: The primary key is not live
because: Expired on 2012-03-13T12:10:11Z
2. Key B742FA8B80420F66 invalid: key is not alive
because: The primary key is not live
because: Expired on 2012-03-13T12:10:11Z
However this break "urpmi --no-verify" which used to behave like rpm
--no-verify
But now only rpm --nosignature can bypass this check, whereas rpm
--no-verify used to do the same, which looks like regression ?
2) this breaks perl-RPM4's testsuite:
See
https://gitweb.mageia.org/software/rpm/perl-RPM4/tree/RPM4/t/04spec.t#n57
This can be run with: cd RPM4; perl Makefile.PL; make && make test
With rpm-4.19:
ok 13 - simulate rpm -bp (check prep)
Executing(%build): /bin/sh -e /tmp/7ICL2x4Fnn/rpm-tmp.MpqXIY
With rpm-4.20:
+not ok 13 - simulate rpm -bp (check prep)
+# Failed test 'simulate rpm -bp (check prep)'
+# at t/04spec.t line 57.
+Executing(%build): /bin/sh -e /tmp/Cb7Sykk9CP/rpm-tmp.H778zX
+/tmp/Cb7Sykk9CP/rpm-tmp.H778zX: line 31: cd:
/tmp/Cb7Sykk9CP/test-rpm-1.0-build: No such file or directory
+error: Bad exit status from /tmp/Cb7Sykk9CP/rpm-tmp.H778zX (%build)
There's a regression here: it doesn' create the directory anymore.
Is this a rpm regression or does RPM4 needs to be adjusted?
Both builddir and topdir are absolute
The test spec file it loads is
https://gitweb.mageia.org/software/rpm/perl-RPM4/tree/RPM4/t/test-rpm.spec
I'd really like to have a feedback for this one.
3) urpmi testsuite fails b/o of missing debuginfo:
error: Empty %files file
/home/tv/mga/git/mga/urpmi/t/tmp/BUILD/a-1-build/debugsourcefiles.list
error: Empty %files file
/home/tv/mga/git/mga/urpmi/t/tmp/BUILD/b-1-build/debugsourcefiles.list
But it's silly to try to extract debuginfo when there's no
I could make those pkgs noarch or set debug_package to %{nil}
On second though I wonder why this wasn't an issue before ?
I fixed those ones in urpmi.
But then I'm hitting this one:
error: Bad exit status from
/home/tv/mga/git/mga/urpmi/t/tmp/rpm-tmp.h09qUo (%install)
# Failed test 'rpmbuild --quiet --define '_topdir
/home/tv/mga/git/mga/urpmi/t/tmp' --define '_tmppath
/home/tv/mga/git/mga/urpmi/t/tmp' -bb --clean --nodeps --define
'__os_install_post %nil' --define 'rpm_version %(rpm -q --queryformat
"%{VERSION}" rpm|sed -e "s/\\.//g")' data/SPECS/buildroot_default.spec'
will
This can be reproduced by running:
rpmbuild -bb --clean t/data/SPECS/buildroot_default.spec
I've attached the rpmbuild output for both 4.19 & 4.20 which shows the
regression
Compare:
rpm-4.19.1.1:
$ rpm --eval %buildroot
/home/tv/rpmbuild/BUILDROOT/%{NAME}-%{VERSION}-%{RELEASE}.x86_64
rpm-4.19.91:
$ rpm --eval %buildroot
%buildroot
I just saw commit 0310a23 (" Fix a
%buildroot regression on an early %__spec_install_pre %global override"),
I'll try again with that commit backported, even though the context is
different as it happens quite a lot later, at the end of the build process.
That commit didn't helped at all sadly
The issue is that the _buildrootdir macro disappeared in commit
9d35c8d
I fear it'll break quite a lot of existing spec files :-(
|
@soig, a closed PR is not a place to report, much less track issues. Open a new ticket per issue to have them looked at, please. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Mostly all cherry picks from master, with the exception of the C++ conversion patches. The preparation work (such as type cleanups) for the C++ conversion is included here, though, to make backporting patches onto this stable branch easier going forward.
Here's a full gitrebase todo for completeness: