Re: [Rpm-maint] [rpm-software-management/rpm] Add proper logic for debuginfo enablement (PR #3085)
It'd probably be possible to further drop the __debug_package logic and merge __debug_install_post into this, and maybe this should be in couple of separate commits, just wanted to get this out before the weekend :sweat_smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3085#issuecomment-2104585532 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add proper logic for debuginfo enablement (PR #3085)
The first two commits are simply #3084 which is needed for this to work. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3085#issuecomment-2104577668 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add proper logic for debuginfo enablement (PR #3085)
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 its disabled in the platform
configuration - since 96467dce18f264b278e17ffe1859c88d9b5aa4b6 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.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/3085
-- Commit Summary --
* Simplify doBuildDir() and use appropriate macros as well
* Always create %specpartsdir on build
* Add proper logic for debuginfo enablement
-- File Changes --
M build/build.c (12)
M build/parsePrep.c (10)
M installplatform (6)
M macros.in (2)
M platform.in (3)
M tests/data/SPECS/specstep.spec (1)
M tests/data/macros.debug (10)
M tests/rpmbuild.at (1)
M tests/rpmspec.at (2)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/3085.patch
https://github.com/rpm-software-management/rpm/pull/3085.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3085
You are receiving this because you are subscribed to this thread.
Message ID: rpm-software-management/rpm/pull/3...@github.com
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Always create %specpartsdir on build (PR #3084)
Theres 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: #3063 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3084 -- Commit Summary -- * Simplify doBuildDir() and use appropriate macros as well * Always create %specpartsdir on build -- File Changes -- M build/build.c (11) M build/parsePrep.c (10) M tests/rpmbuild.at (1) M tests/rpmspec.at (2) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3084.patch https://github.com/rpm-software-management/rpm/pull/3084.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3084 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/3...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement merging of new key material when importing pubkeys (PR #3083)
Oh, nice. Didn't look at details yet but the functionality is pretty desperately needed indeed. The current behavior of just bailing out if main keyid is already there predates the subkey support by many years and was only ever intended as a stop-gap behavior until something better gets done. Well, here we are, finally :+1: @nwalfield , thoughts from rpm-sequoia POV (or otherwise)? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3083#issuecomment-2100369992 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Use an STL vector for the transaction main rpmte pointer storage (PR #3081)
Merged #3081 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3081#event-12738970571 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Use an STL vector for the transaction main rpmte pointer storage (PR #3081)
@pmatilai pushed 2 commits. 28a786b73ead3aba89e2401a98027083b7ffb532 Use an STL vector for the transaction main rpmte pointer storage ae207825b46202e62c3da8873ab7feadf18fae31 Convert orderInfo array to a vector -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3081/files/64961459fd3219355aee87641e7e682ef441a30b..ae207825b46202e62c3da8873ab7feadf18fae31 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Replace the annoying keyid stash with an STL set (PR #3080)
Merged #3080 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3080#event-12738874129 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Simplify rpmfi replaced sized management (PR #3079)
Merged #3079 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3079#event-12738873271 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Replace rpmhash with STL unordered_map in headerformat cache (PR #3078)
Merged #3078 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3078#event-12738871940 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Convert packageHash to STL unordered_map (PR #3077)
Merged #3077 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3077#event-12738870990 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Convert packageHash to STL unordered_map (PR #3077)
...plus a bunch of other hashes... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3077#issuecomment-2098143569 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Convert packageHash to STL unordered_map (PR #3077)
@pmatilai pushed 1 commit. 24b61052131553275d5818e1a47bce6a3c80f7ba Replace dependency lookup cache with an STL unordered map -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3077/files/cce0bdbc8c1e48cb03bb2905d4c7cbd3340a..24b61052131553275d5818e1a47bce6a3c80f7ba You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Use an STL vector for the transaction main rpmte pointer storage (PR #3081)
...and orderInfo array too You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3081 -- Commit Summary -- * Replace the annoying keyid stash with an STL set * Use an STL vector for the transaction main rpmte pointer storage * Convert orderInfo array to a vector -- File Changes -- M lib/depends.c (26) M lib/order.c (45) M lib/package.c (28) M lib/rpmte.c (2) M lib/rpmts.c (21) M lib/rpmts_internal.h (7) M lib/transaction.c (6) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3081.patch https://github.com/rpm-software-management/rpm/pull/3081.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3081 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/3...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Replace the annoying keyid stash with an STL set (PR #3080)
It still needs to die, but theres less code that needs dying... You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3080 -- Commit Summary -- * Replace the annoying keyid stash with an STL set -- File Changes -- M lib/package.c (28) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3080.patch https://github.com/rpm-software-management/rpm/pull/3080.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3080 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/3...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Simplify rpmfi replaced sized management (PR #3079)
rpmfi always internally stores 64bit sizes since 4.6.0, theres no reason to do anything else with replaced sizes either. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3079 -- Commit Summary -- * Simplify rpmfi replaced sized management -- File Changes -- M lib/rpmfi.c (25) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3079.patch https://github.com/rpm-software-management/rpm/pull/3079.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3079 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/3...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Replace rpmhash with STL unordered_map in headerformat cache (PR #3078)
A notable difference is that were now storing the rpmtd structs themselves in the hash, rather than pointers to them. A minor side-cleanup is that headerGet() does not return data on failure so theres no need to free anything in that case. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3078 -- Commit Summary -- * Replace rpmhash with STL unordered_map in headerformat cache -- File Changes -- M lib/headerfmt.c (50) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3078.patch https://github.com/rpm-software-management/rpm/pull/3078.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3078 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/3...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Convert packageHash to STL unordered_map (PR #3077)
@pmatilai pushed 2 commits. 85b181479291fa0f1a5a7f202fc1849c998b3faf Natively allocate the main file trigger structs cbbfe1ee74859818cf45c4a7b2812541216ef51f Convert packageHash to STL unordered_map -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3077/files/fb9815b7934782330779fa2334393de9ef3e179a..cbbfe1ee74859818cf45c4a7b2812541216ef51f You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Implement proper user/group lookup caching with STL maps (PR #3076)
Merged #3076 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3076#event-12724208939 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Convert packageHash to STL unordered_map (PR #3077)
This was a particularly ugly case as it was defined in multiple places. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3077 -- Commit Summary -- * Convert packageHash to STL unordered_map -- File Changes -- M lib/depends.c (17) M lib/order.c (2) M lib/psm.c (3) M lib/rpmdb.c (13) M lib/rpmdb_internal.h (13) M lib/rpmtriggers.c (25) M lib/rpmts.c (18) M lib/transaction.c (7) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3077.patch https://github.com/rpm-software-management/rpm/pull/3077.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3077 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/3...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Convert rpmal to use STL containers (PR #3075)
Merged #3075 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3075#event-12723879896 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Implement proper user/group lookup caching with STL maps (PR #3076)
It may not make much difference for performance for our current use-cases, but since its not really any more code now... Natively allocate the rpmug struct to enable this. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3076 -- Commit Summary -- * Implement proper user/group lookup caching with STL maps -- File Changes -- M lib/rpmug.c (81) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3076.patch https://github.com/rpm-software-management/rpm/pull/3076.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3076 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/3...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Convert rpmal to use STL containers (PR #3075)
@pmatilai pushed 1 commit. edf4f7ca46eff2c3626e4ef16640b78abfd32fad Replace home-grown hashes with STL unordered_map in rpmal -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3075/files/1844c24d487f0a5cc48cc0b842657ba0a226d718..edf4f7ca46eff2c3626e4ef16640b78abfd32fad You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Convert rpmal to use STL containers (PR #3075)
You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3075 -- Commit Summary -- * Use vectors for returning multiple values from rpmalAll*() * Natively allocate rpmal struct itself * Use a vector for rpmal available package storage * Replace home-grown hashes with STL unordered_map in rpmal -- File Changes -- M lib/depends.c (38) M lib/rpmal.c (325) M lib/rpmal.h (7) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3075.patch https://github.com/rpm-software-management/rpm/pull/3075.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3075 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/3...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove C++ guards from internal headers (PR #3074)
Merged #3074 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3074#event-12712137504 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Remove C++ guards from internal headers (PR #3074)
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. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3074 -- Commit Summary -- * Remove C++ guards from internal headers -- File Changes -- M build/rpmbuild_internal.h (8) M build/rpmbuild_misc.h (8) M lib/backend/dbi.h (8) M lib/backend/dbiset.h (7) M lib/cpio.h (8) M lib/fprint.h (8) M lib/fsm.h (7) M lib/header_internal.h (7) M lib/manifest.h (8) M lib/misc.h (8) M lib/rpmal.h (8) M lib/rpmchroot.h (9) M lib/rpmdb_internal.h (8) M lib/rpmds_internal.h (7) M lib/rpmfi_internal.h (7) M lib/rpmfs.h (8) M lib/rpmgi.h (8) M lib/rpmlead.h (8) M lib/rpmlock.h (8) M lib/rpmplugins.h (7) M lib/rpmscript.h (7) M lib/rpmte_internal.h (8) M lib/rpmtriggers.h (8) M lib/rpmts_internal.h (7) M lib/rpmug.h (9) M lib/rpmvs.h (8) M lib/signature.h (8) M rpmio/rpmhook.h (8) M rpmio/rpmio_internal.h (8) M rpmio/rpmlua.h (8) M rpmio/rpmmacro_internal.h (8) M sign/rpmsignfiles.h (8) M sign/rpmsignverity.h (8) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3074.patch https://github.com/rpm-software-management/rpm/pull/3074.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3074 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/3...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %_target_cpu and various other macros are wrong in during build in BuildArch packages (Issue #3049)
Closed #3049 as completed via #3071. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3049#event-12711076211 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Automatically reload rpm configuration on mismatching BuildArch (PR #3071)
Merged #3071 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3071#event-12711076023 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Cleanups and improvements in tests/rpmpgppubkeyfingerprint.c (PR #3072)
Closed #3072. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3072#event-12710658133 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Cleanups and improvements in tests/rpmpgppubkeyfingerprint.c (PR #3072)
Sorry but I agree with @nwalfield , this is just strange churn for churn's sake. Like advertising use of goto but then still using return for the cases that *could* use a central clean-up point. Even the changes that I could use because I suggested them are mixed with unrelated other changes, moving stuff around needlessly etc. Even the change to "rpm coding style" is anything but, the code is almost 100% that already. A 118 line simple program that only ever executes as a part of the test-suite does not need much in the way of cleanup, really. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3072#issuecomment-2095296257 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] API improvement to accommodate for RPM CoW (PR#1470) (Discussion #2057)
v6 will have signed payload size information : https://github.com/rpm-software-management/rpm/pull/3017/commits/784bb9076d614da33d29123f5ef6236a57d38463 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2057#discussioncomment-9324984 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Is there a way to detect `SRPM` / `RPM` build? (Discussion #3046)
> So is there a way to detect the SRPM build? Whether an SRPM gets generated by a build is not something the spec should be aware of. It's not a separate thing - it may take place as an isolated step or as a part of a binary build. A plain SRPM build does not invoke the dynamic spec generation features at all. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/3046#discussioncomment-9324896 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Automatically reload rpm configuration on mismatching BuildArch (PR #3071)
Sub-package noarch's a special case hack that doesn't cause spec parse recursion. So the answer is: nothing. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3071#issuecomment-2095257485 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Automatically reload rpm configuration on mismatching BuildArch (PR #3071)
@pmatilai pushed 1 commit. a5ea8c6db14455399d5447601ab0b5ebe7896878 Automatically reload rpm configuration on mismatching BuildArch -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3071/files/d09c5e9543dedac603f95e7a3252b10fecea5d85..a5ea8c6db14455399d5447601ab0b5ebe7896878 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Automatically reload rpm configuration on mismatching BuildArch (PR #3071)
Eh, including the test-spec in the commit improves the chances of success... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3071#issuecomment-2084986916 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Automatically reload rpm configuration on mismatching BuildArch (PR #3071)
@pmatilai pushed 1 commit. d09c5e9543dedac603f95e7a3252b10fecea5d85 Automatically reload rpm configuration on mismatching BuildArch -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3071/files/c0504d9e64896e0487d9b3e6401cfa257e671f8f..d09c5e9543dedac603f95e7a3252b10fecea5d85 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Automatically reload rpm configuration on mismatching BuildArch (PR #3071)
The way buildForTarget() now serves two quite different purposes is a bit ugly of course but keeps the patch small. I'd rather live with this for now and address the whole thing at a more fundamental level later on. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3071#issuecomment-2084980688 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Automatically reload rpm configuration on mismatching BuildArch (PR #3071)
When BuildArch is encountered during spec parse, rpm recurses the parse, but this doesnt 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 wasnt 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 doesnt work. --undefine with --target was always broken, now its just more visible since it automatically applies to BuildArch too. Fixing that is a separate matter (#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: #3049 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3071 -- Commit Summary -- * Dont emit target build into on --quiet * Automatically reload rpm configuration on mismatching BuildArch -- File Changes -- M tests/rpmbuild.at (46) M tools/rpmbuild.c (39) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3071.patch https://github.com/rpm-software-management/rpm/pull/3071.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3071 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/3...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] --undefine doesn't work with --target (Issue #3070)
--target causes the entire rpm configuration to be reloaded from scratch, and since --undefine operates on the init macro context at program startup, the rpmPopMacro()'s it does get lost in the reload. Filing this as "documentation" for the issue: if nothing else, it's inconsistent behavior. Of course what's --undefine'd may get defined by a thousand other means too, it's just not a realiable way to do stuff in rpm. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3070 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] API improvement to accommodate for RPM CoW (PR#1470) (Discussion #2057)
Thing is, since the payload is typically compressed, offsets are useless because they'd just point to somewhere in the middle of a compression stream. If the files in the payload were individually compressed, it'd seem quite reasonable to have offsets stored. Of course that would likely loose something in the compression ratio. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2057#discussioncomment-9271027 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] API improvement to accommodate for RPM CoW (PR#1470) (Discussion #2057)
There are no offsets stored, so I don't think there is. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2057#discussioncomment-9271000 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Drop architecture from %builddir path (PR #3069)
Merged #3069 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3069#event-12652696073 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix header source/patch names disagreeing with src.rpm contents (PR #3067)
Merged #3067 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3067#event-12652692342 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Convert a bunch of librpm stuff to native C++ allocation (and containers) (PR #3066)
Merged #3066 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3066#event-12652691270 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Convert macro table to STL containers + native strings (PR #3062)
Merged #3062 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3062#event-12652690152 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] API improvement to accommodate for RPM CoW (PR#1470) (Discussion #2057)
> The rpm payload format isn't modified, although there's a slight "bending" of > the cpio/newc spec to use the filename field for padding. zstandard frames > making up the compressed rpm payload explicitly carry both compressed and > uncompressed lengths, to allow detection of filesystem-supported I/O sizes. Note that the cpio/newc format is on its way out, you don't want to design too much around that. In rpm v4 it's used for packages where all contained files are below 4GB, but v6 will always use the newer rpm-specific format which doesn't carry any file metadata in the payload: https://rpm-software-management.github.io/rpm/manual/format_v6.html#payload -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2057#discussioncomment-9270749 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Drop architecture from %builddir path (PR #3069)
@pmatilai pushed 1 commit. 658bc4f097fd0dd050e10b3ee31a31d25fa35be1 Drop architecture from %builddir path -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3069/files/60ca0113b7a935f3e670e390b4720def7fbadd62..658bc4f097fd0dd050e10b3ee31a31d25fa35be1 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] API improvement to accommodate for RPM CoW (PR#1470) (Discussion #2057)
The compressed and uncompressed digests are *alternatives*, both cannot be valid at the same time. Rpm calculates both but uses the one that matches (if any). This is to allow freely changing between uncompressed and compressed format of the same content, which "obviously" must be a legit case. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2057#discussioncomment-9270613 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Drop architecture from %builddir path (PR #3069)
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. Suggested-by: Neal Gompa n...@gompa.dev You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3069 -- Commit Summary -- * Drop architecture from %builddir path -- File Changes -- M build/parsePreamble.c (2) M tests/rpmbuild.at (34) M tests/rpmspec.at (6) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3069.patch https://github.com/rpm-software-management/rpm/pull/3069.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3069 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/3...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Code cleanups in tests/rpmpgppubkeyfingerprint.c (PR #3068)
> I took the liberty to make this whole source look better. Better is subjective. The indentation was mostly following rpm coding style, now it's not. See Coding style / Indentation in CONTRIBUTING.md. Never, ever make formatting changes at the same time as other changes, and in particular, don't break what wasn't broken. It's impossible to review a change like this. In the light of recent events, "small test stuff" certainly needs reviewing too. One thing that did catch my eye despite that is pointless NULL checks before freeing. Don't do that, free() will do it for you anyhow. In the meanwhile, there *are* real cleanups/simplifications to be made. Like manually calculating string sizes when it could use rasprintf(), and manual getcwd() when we have rpmGetCwd() and malloc() with OOM checking for what's a static buffer that wouldn't need freeing. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3068#issuecomment-2084396253 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add error messages for url helper calls (PR #3041)
Hmm, and of course we have entirely different way of reporting the error on install, eg: > [root@localhost _build]# ./tools/rpm --define "_urlhelper /bad" -U --nodeps > --root /srv/test > https://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/0/0x-0.10-7.fc40.x86_64.rpm error: Could not find url helper: "/bad": No such file or directory error: skipping https://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/0/0x-0.10-7.fc40.x86_64.rpm - transfer failed Which isn't so bad. But probably --import and all have their own more cryptic variants like the query above. Anyway, if we accept that we call rpmlog() from that location, it is an improvement for the user. Which is what matters in the end I guess. Besides tests there are some improvements you can make here: The exec() can fail for other reasons besides not found, so I'd use a more generic error message there. Maybe just "failed to execute url helper". The exact error code is available in the child if we move the log there (ignoring the wrath of rpmlog after fork), or we could extend our use of the bash scheme started in faaa0305f5. From bash(1): "If a command is not found, the child process created to execute it returns a status of 127. If a command is found but is not executable, the return status is 126." -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3041#issuecomment-2082634102 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Fix header source/patch names disagreeing with src.rpm contents (PR #3067)
If sources or patches in the spec are defined via a macro that does not yet
exist, itll still work for building if the macro has been defined by that
time as theres 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 youd 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 theres 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 thats what happens
for them in the actual build as well.
Originally reported at https://bugzilla.redhat.com/show_bug.cgi?id=2233878
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/3067
-- Commit Summary --
* Fix header source/patch names disagreeing with src.rpm contents
-- File Changes --
M build/parseSpec.c (6)
A tests/data/SPECS/macrosource.spec (15)
M tests/rpmbuild.at (31)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/3067.patch
https://github.com/rpm-software-management/rpm/pull/3067.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3067
You are receiving this because you are subscribed to this thread.
Message ID: rpm-software-management/rpm/pull/3...@github.com
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] how should a test on given argument --noclean (Discussion #3065)
You can't. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/3065#discussioncomment-9261221 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Convert macro table to STL containers + native strings (PR #3062)
The final commit turns the macro entry stack into an STL container too, making the macro entries themselves freestanding and since all this is now standard library stuff we don't need to manually clean up and deallocate etc. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3062#issuecomment-2082100677 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Convert a bunch of librpm stuff to native C++ allocation (and containers) (PR #3066)
Nothing hugely interesting in here, see commit 0d1071b99ada2df920ba657d9e015e0c2259d4b6 for rationale. There are bits and pieces to finish in librpmio side still but moving on to librpm as some of this stuff is linked, eg string pool cannot use C++ containers before rpmds is updated to clean up after itself, otherwise there will be an unfixable indirect leak from rpmlibProvides_s struct on process exit :zany_face: You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3066 -- Commit Summary -- * Natively allocate rpmte structs and temporary colors vector * Natively allocate rpmts, rpmtsi, rpmtxn and tsMembers * Natively allocate rpmds, rpmfiles and rpmfi mains structs * Natively allocate rpmps and rpmprob structs, use vector for prob storage * Natively allocate main header related structs * Natively allocate bunch of miscellaneous librpm structs * Natively allocate main rpmdb related structs * Use a vector for index iterator offset storage * Use an unordered map for the rpmdb verify cache * Natively allocate rpmfs structs * Natively allocate fingerprint cache * Natively allocate plugin structures, use a vector for storage -- File Changes -- M lib/backend/dbi.h (6) M lib/cpio.c (4) M lib/fprint.c (6) M lib/header.c (14) M lib/psm.c (5) M lib/rpmdb.c (75) M lib/rpmds.c (5) M lib/rpmfi.c (13) M lib/rpmfs.c (57) M lib/rpmgi.c (6) M lib/rpmlock.c (6) M lib/rpmplugins.c (67) M lib/rpmprob.c (4) M lib/rpmps.c (46) M lib/rpmscript.c (8) M lib/rpmtd.c (4) M lib/rpmte.c (11) M lib/rpmts.c (19) M lib/rpmvs.c (4) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3066.patch https://github.com/rpm-software-management/rpm/pull/3066.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3066 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/3...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Convert macro table to STL containers + native strings (PR #3062)
@pmatilai pushed 3 commits. 9c28251cdb3664839a5a03b6f6b15f096653483b Add copy control and in particular, destructor to the macro context 3ff1f78c49d63d75b30cc46607edfb148cb5e948 Convert macro table to STL containers + native strings a06877ec1ed1fd5ac8cbaae8100288a2b220fd5c Untangle the per-name stack from the macro entry struct -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3062/files/e551a36f8300347f90a54e25e73e32c53cfb0a37..a06877ec1ed1fd5ac8cbaae8100288a2b220fd5c You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Sending multiple identical options to a macro will leak them to the next macro accepting the same option (Issue #3056)
No, we'll cherry-pick obvious fixes when doing the next release. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3056#issuecomment-2078687995 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support building other projects as part of test image (Issue #2877)
Have local recipes from building from those upstream sources, install in suitable prefix with LD_LIBRARY_PATH. In a word, painfully? :smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2877#issuecomment-2077175576 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Convert macro table to STL containers + native strings (PR #3062)
Use an STL map for the macro entry table, this matches exactly the behavior we manually did with the C array. The variable length array at end of macro entry structs is not really C++, use native strings for the storage. Its slower, but not tragically so. For now, keep name, opts and body as const char pointers though to the c_str() items to avoid having to change everything at once. Popping macros is a bit clunky and repetitive, well clean it up later. findEntry() returns a pointer to the macro entry itself instead of pointer to pointer, which simplifies things a bit further. This is a wee bit slower than the raw C counterpart, but by no means tragically so and moving to native structures opens up other opportunities in turn, both optimization and feature wise. Further work will be easier now that the highly optimized but also tangled up data structure is (mostly) untangled. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3062 -- Commit Summary -- * Add copy control and in particular, destructor to the macro context * Convert macro table to STL containers + native strings -- File Changes -- M rpmio/macro.c (245) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3062.patch https://github.com/rpm-software-management/rpm/pull/3062.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3062 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/3...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Another bunch of misc C++ conversion/cleanups (PR #3060)
Merged #3060 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3060#event-12605908368 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Another bunch of misc C++ conversion/cleanups (PR #3060)
@pmatilai pushed 2 commits. 666caf176f6845cca30ab8c697cea48d05ca38db Replace a couple of local IO buffers with a vector aae0ee12c4f6b9aac19be04654d83ed7500901a2 Replace temporary argv array in Lua posix.exec() with a vector -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3060/files/c6993a9ec1ad203f19709df3a1b8f74e073df8ec..aae0ee12c4f6b9aac19be04654d83ed7500901a2 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Another bunch of misc C++ conversion/cleanups (PR #3060)
You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3060 -- Commit Summary -- * Take advantage of rvasprintf() in rpmlog() * Use strings as keyid and STL map for keyring storage * Replace homegrown mallocing getcwd() with filesystem::current_path() * Replace a couple of local IO buffers with a vector * Replace temporary argv array in Lua posix.exec() with a vector -- File Changes -- M rpmio/lposix.c (13) M rpmio/macro.c (7) M rpmio/rpmfileutil.c (23) M rpmio/rpmkeyring.c (56) M rpmio/rpmlog.c (14) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3060.patch https://github.com/rpm-software-management/rpm/pull/3060.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3060 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/3...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Sending multiple identical options to a macro will leak them to the next macro accepting the same option (Issue #3056)
Oh and thanks for reporting! Like the testcase shows, we *kinda* knew about this all along but had forgotten, and who knows how long more this might've lurked along :smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3056#issuecomment-2074560391 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] debuginfo generation does not work with --build-in-place (Issue #3042)
I totally get the testing use-case, we have -bb --short-circuit for similar reasons. Only with --short-circuit we "poison" the produced packages to prevent people from distributing them (accidentally or otherwise). Anyway, I agree there seems to be a bug - or more likely a few - in there. There are zero tests for --build-in-place are it basically just jumps off the cliff and hopes for the best. I'm more surprised it works at all as it is. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3042#issuecomment-2074465530 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] 4.19.1.1: source and patrches listed in NoSoure: ans NoPatch: are not removed when is used --rmsource (Issue #3037)
We discussed this at some length, and actually the current behavior seems correct. Nosource items are not managed by rpm in any way: they don't get pulled into src.rpm's, and if you want to rebuild an src.rpm utilizing nosources, you need to manually copy any nosource items in place. It's then only consistent that rpm doesn't remove them either. Plus, by definition they are non-sources, so it seems consistent with that as well. This just needs to be documented. Thanks for the report btw. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3037#issuecomment-2074454785 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix multiply defined local macros escaping scope (PR #3059)
@pmatilai pushed 1 commit. 6e816f3f05c0c3f7f123e2bb0e7d8c11d7acd506 Fix multiply defined local macros escaping scope -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3059/files/e2cba360ec40d34538de99ebf4c007821b847866..6e816f3f05c0c3f7f123e2bb0e7d8c11d7acd506 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Fix multiply defined local macros escaping scope (PR #3059)
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, which now passes. This bug was circa 26 years old. Some might call it vintage at this point. Fixes: #3056 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3059 -- Commit Summary -- * Fix multiply defined local macros escaping scope -- File Changes -- M rpmio/macro.c (19) M tests/rpmmacro.at (1) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3059.patch https://github.com/rpm-software-management/rpm/pull/3059.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3059 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/3...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] 4.19.1.1: source and patrches listed in NoSoure: ans NoPatch: are not removed when is used --rmsource (Issue #3037)
This gets kinda philosophical: --rmsource removes sources, but is a "nosource" a source? The name seems to indicate it's not. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3037#issuecomment-2074167627 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Fopen() and friends don't validate the mode (Issue #3058)
This should fail instead of quietly falling back to fdio.
$ python -c "import rpm; print(rpm.fd('/dev/null', 'w', 'aaaiiiooo'))"
Besides being ugly buggy, it kinda prevents us from testing optional io types
as well.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3058
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Sending multiple identical options to a macro will leak them to the next macro accepting the same option (Issue #3056)
It's a bug alright. I actually just stumbled on that code a couple of days ago
thinking this doesn't look right. It isn't.
It's not just multiple identical options, it's any local macro multiply
defined, issue being that freeArgs() only ever pops once. Easily reproduced
with eg
> rpm --define "aa 0" --define "my() %{define:aa 1} %{define:aa 2}" --eval
> "%my" --eval "%aa"
> warning: Macro %aa defined but not used within scope
>
>1
It should "obviously" output 0.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3056#issuecomment-2074090243
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Pass arg3 to regular and file trigger scripts (PR #3018)
@pmatilai commented on this pull request.
> @@ -248,4 +248,29 @@ char *argvJoin(ARGV_const_t argv, const char *sep)
return dest;
}
-
+
+ARGV_t argvFromVaList(const char *fmt, va_list ap)
+{
+ARGV_t argv = argvNew();
No need for argvNew(), argvAdd*() handles that as needed. Without this, an
invalid fmt will return NULL which is what we probably want.
I think I'd also make this a private helper inside rpmscript.c, all of argv.*
is considered deprecated going forward so maybe we shouldn't add more public
APIs there.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3018#pullrequestreview-2016536902
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Upstream debuginfo enablement (PR #3040)
@pmatilai commented on this pull request.
> @@ -145,6 +145,9 @@
#%__systemd_sysusers @__SYSTEMD_SYSUSERS@
%__systemd_sysusers%{_rpmconfigdir}/sysusers.sh
+# enable debug package generation
+%_enable_debug_packages 1
I realized this doesn't belong to the main macros.in, really - it should
probably be in platform.in instead. For one, this is a Linux-only feature due
to the ties elfutils, but also: we don't want debug packages for noarch
packages, *that* is the place to express it. Sadly we'll still need the other
noarch checks because the platform files aren't reread on spec parse recursion,
but it's the right direction anyhow.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3040#pullrequestreview-2016452103
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Upstream debuginfo enablement (PR #3040)
@pmatilai commented on this pull request.
> %global __debug_package 1\
+%(cat > "%{specpartsdir}/rpm-debuginfo.specpart" << EOL\
I'd like it a whole lot more if the `cat` was in the template part. This is an
ugly side-effect for a macro to have, eg somebody doing `rpm --eval
"%{debug_package}"` to see what it's made of.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3040#pullrequestreview-2016438413
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Adapt tests to current state of the "legacy" parser (PR #3055)
Nice, thanks! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3055#issuecomment-2071520497 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Adapt tests to current state of the "legacy" parser (PR #3055)
Merged #3055 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3055#event-12570092472 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] `%build -a` and `%install -a` overwrite build/installation instructions from `%buildsystem_*_*` (Issue #3024)
Closed #3024 as completed via #3047. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3024#event-12570032397 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix build scriptlet append/prepend interaction with Buildsystem (PR #3047)
Merged #3047 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3047#event-12570032216 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Convert a bunch of librpmio stuff to native C++ (PR #3054)
Merged #3054 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3054#event-12570029080 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Convert a bunch of librpmio stuff to native C++ (PR #3054)
Added a bunch of rationale/background to the first commit message, no code changes. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3054#issuecomment-2071512091 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add the "Primary Binding" pgp signature type (PR #3051)
Would really be nice to get rid of this stuff in rpm... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3051#issuecomment-2069259429 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add the "Primary Binding" pgp signature type (PR #3051)
Merged #3051 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3051#event-12558970441 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Convert a bunch of librpmio stuff to native C++ (PR #3054)
Convert a bunch of dynamic allocations in librpmio to native C++ new/delete to enable use of native structures in those structs and then take advantage of it. Misc other string/vector conversions too. This is a pretty random stuff, the primary points being to bring the number of raw C allocations down, and to make the first real step into the C++ land. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3054 -- Commit Summary -- * Minimally convert digest code to native c++ allocation * Natively allocate rpmio structs * Natively allocate internal rpmlua structs * Replace internal Lua print buffer with a C++ string * Replace internal Lua printing stack with a C++ stack * Use C++ constructs for rpmlog internal storage * Use a c++ string for macro expansion buffer * Use c++ string for rpmExpand() helper buffer * Natively allocate keyring + pubkey structs * Natively allocate keyring and pubkey structs * Natively allocate expression most parser structs -- File Changes -- M include/rpm/rpmtypes.h (2) M rpmio/digest.c (5) M rpmio/digest_libgcrypt.c (6) M rpmio/digest_openssl.c (19) M rpmio/expression.c (53) M rpmio/macro.c (120) M rpmio/rpmio.c (38) M rpmio/rpmkeyring.c (30) M rpmio/rpmlog.c (51) M rpmio/rpmlua.c (78) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3054.patch https://github.com/rpm-software-management/rpm/pull/3054.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3054 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/3...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: support isolation between %prep/%build/%install/%check (Issue #3050)
Yup. Note "ideally" in there - this is stuff to explore with, and indeed for packaging hygiene reasons rather than any "security" thing. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3050#issuecomment-2065908096 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: ensure unwritable buildroot during %check (Issue #3010)
Closing in favor of a more generic #3050 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3010#issuecomment-2065857806 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: ensure unwritable buildroot during %check (Issue #3010)
Closed #3010 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3010#event-12533384975 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] RFE: support isolation between %prep/%build/%install/%check (Issue #3050)
Ideally, the build scriptlets would be isolated from each other: - %prep unpacks the source, and %build takes place in a separate directory against a read-only source. Obviously not all software can be built outside the source tree, but this would be a nice addon to vpath builds (#2985) - %install wipes buildroot on start, so %build cannot accidentally install stuff. But ideally %install should run with a read-only build directory - install should install, not build. This would've caught #3024. - %check should run with read-only buildroot to prevent tests from affecting packaged content. It probably does need writable build-dir because those tests do need to write someplace. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3050 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] [RFC] rpmbuild, check: verify file hashes (PR #3039)
Rpm already hashes any packaged content cryptographically (SHA256 by default), any such mechanism should utilize that to minimize the extra cost. But this seems like a big extra cost with limited benefit, we're more interested in *preventing* writes across the different stages. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3039#issuecomment-2065842355 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Move OpenSSL code to newer API (PR #2723)
Seems I've managed to throroughly confuse myself with the recent split :joy: So yup, we still need to support the internal parser in 4.19.x but *this* change is not there, and while we still have openssl-related code in >= 4.20, DSA is not part of it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2723#issuecomment-2065833452 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: ensure unwritable buildroot during %check (Issue #3010)
This is not about "preventing XZ", it's just somewhat inspired by it. I really don't know why multiple people are arguing against rpm looking to do some extra packaging hygiene enforcement here. In a similar vein, rpm would prefer an unwritable build directory during %install. Hashing the content is not something this ticket is about. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3010#issuecomment-2065824195 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] %_target_cpu and various other macros are wrong in during build in BuildArch packages (Issue #3049)
One report of the issue is here: https://bugzilla.redhat.com/show_bug.cgi?id=2069163 but also ran into this in various other circumstances, eg #2319 and %ifarch not working in dynamic spec parts. The spec parsing recurses through build architectures, pushing and popping %_target_cpu as it goes, and the last pop leaves the value to whatever the host is, ie almost certainly wrong and always wrong for noarch packages. It's not just %_target_cpu though, RPM_ARCH environment variable in the build scriptlets gets set from %_arch which is similarly off, and then there's %_libdir, %optflags and all. This affects both dynamically generated .specpart and the templated parts that get expanded during doScript(). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3049 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Relax openssl version requirement (PR #3045)
Merged #3045 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3045#event-12520804092 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Relax openssl version requirement (PR #3045)
Oh, of course. I'm already forgetting I just split a good chunk of that code out :laughing: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3045#issuecomment-2063473913 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Move OpenSSL code to newer API (PR #2723)
There may not be DSA keys in active use but they do exist in old distros and packages people may want to install for whatever reason. If we broke it we should fix it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2723#issuecomment-2063471380 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add error messages for url helper calls (PR #3041)
There should be a test for the case where the urlhelper is missing - it's what we can easily test, and also happens to be the case we're also most interested in for the bug. > $ ./tools/rpm --define "_urlhelper /not/there" -qp > https://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/updates/39/Everything/x86_64/Packages/3/389-ds-base-snmp-2.4.5-1.fc39.x86_64.rpm error: Could not find url helper: "/not/there" error: open of https://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/updates/39/Everything/x86_64/Packages/3/389-ds-base-snmp-2.4.5-1.fc39.x86_64.rpm failed: No such file or directory Like I said (elsewhere), I've poked at this thing before. And I remember now, the reason I abandoned it was because I didn't like the "improved" behavior that great either - the latter message is pretty misleading even if the reason is in the line above. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3041#issuecomment-2063440048 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Relax openssl version requirement (PR #3045)
So the API we updated to just now was there all this time? Oh well... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3045#issuecomment-2063422093 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix build scriptlet append/prepend interaction with Buildsystem (PR #3047)
...aaand then in the exact reverse order to make up a nice refactoring series. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3047#issuecomment-2063363180 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix build scriptlet append/prepend interaction with Buildsystem (PR #3047)
@pmatilai pushed 3 commits. 9e9a3fa747a285876726c33ca8d4df15a6f6759b Refactor getSection() to more generally useful 106c81b7050c255e4281eb3f4717c601e40fb7e9 Refactor build script parse calls to a helper 39ff076a33d645ec4e40b0ca07c7ecad74df0912 Fix build scriptlet append/prepend interaction with Buildsystem -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3047/files/b50ac2d506491e3651797b4a4e2f133731c2ddb0..39ff076a33d645ec4e40b0ca07c7ecad74df0912 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix build scriptlet append/prepend interaction with Buildsystem (PR #3047)
@pmatilai pushed 1 commit. b50ac2d506491e3651797b4a4e2f133731c2ddb0 Refactor getSection() to more generally useful -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3047/files/3bf011d4aa230f120f07d205d5e9bff710b5e8c6..b50ac2d506491e3651797b4a4e2f133731c2ddb0 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix build scriptlet append/prepend interaction with Buildsystem (PR #3047)
@pmatilai pushed 1 commit. 3bf011d4aa230f120f07d205d5e9bff710b5e8c6 Refactor parseBuildScript() to take spec PART_* numbers instead of names -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3047/files/4a8d86ea57040ff73d5b32a65a28a9e8cec6ff14..3bf011d4aa230f120f07d205d5e9bff710b5e8c6 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add prepend and append modes for all our normal build scriptlets (PR #2728)
@pmatilai commented on this pull request. > @@ -461,6 +461,13 @@ when name is omitted, the description refers to the main > package. Package build is divided into multiple separate steps, each executed in a separate shell. +Only one of each section can be present in a spec, but all build scriptlets +except for `%prep` accept options `-a` and `-p`, for append and prepend mode. +Append and prepend append or prepend lines to the section in the order they +appear in the spec. Both append and prepend can be used multiple times and +without other restrictions, but a section without either mode can only +appear first (eg `%build` cannot follow `%build -p`). Turns out what felt artificial, was in fact an artificial limit of the implementation. https://github.com/rpm-software-management/rpm/pull/3047 does away with that limitation, -a/-p are always applied relative to the main section if it exists, otherwise the first fragment is used as the base. Makes a lot more sense that way. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2728#discussion_r1570157804 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
