Re: [Rpm-maint] [rpm-software-management/rpm] Implement merging of new key material when importing pubkeys (PR #3083)
@pmatilai commented on this pull request.
> @@ -229,6 +229,28 @@ char * rpmPubkeyBase64(rpmPubkey key)
return enc;
}
+rpmRC rpmPubkeyMerge(rpmPubkey oldkey, rpmPubkey newkey, rpmPubkey *mergedkeyp)
+{
+rpmPubkey mergedkey = NULL;
+uint8_t *mergedpkt = NULL;
+size_t mergedpktlen = 0;
+rpmRC rc;
+
+pthread_rwlock_rdlock(>lock);
+pthread_rwlock_rdlock(>lock);
I don't think we have a defined locking order for anything in rpm. The locks on
they keys are probably a bit hokey to begin with because librpm and threads is
playing with fire anyway.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3083#discussion_r1611406952
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 merging of new key material when importing pubkeys (PR #3083)
@pmatilai commented on this pull request. > @@ -509,6 +509,19 @@ int pgpSignatureType(pgpDigParams sig); */ char *pgpIdentItem(pgpDigParams digp); +/** \ingroup rpmpgp + * Merge the PGP packets of two public keys + * @param pkts1OpenPGP pointer to a buffer of first certificates + * @param pkts1len length of the buffer with first certificates + * @param pkts2OpenPGP pointer to a buffer of second certificates + * @param pkts2len length of the buffer with second certificates + * @param pktsm[out] merged certificates (malloced) + * @param pktsmlen[out]length of merged certificates + * @param flagsmerge flags (currently not implemented) I'd rather have a flags arg we never end up using than not having it when we need it. Rpm is traditionally terribly sloppy with these, but indeed it'd be good to state the only legit value now is 0 so people don't end up passing random stuff that hurts us later (been there). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3083#discussion_r1611400268 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] %mkbuilddir breaks the %generate_buildrequires implementation in mock (Issue #3121)
Closed #3121 as completed via #3122. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3121#event-12906903696 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 --noprep regression from introducing %mkbuilddir (PR #3122)
Merged #3122 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3122#event-12906903427 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 STL conversions (PR #3119)
Merged #3119 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3119#event-12906806871 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] %mkbuilddir breaks the %generate_buildrequires implementation in mock (Issue #3121)
The biggest issue here was really that there were no tests on --noprep whatsoever, so when I wasn't even aware of the feature... luckily this was easy enough to sort out. *knocks wood* -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3121#issuecomment-2126664965 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] %mkbuilddir breaks the %generate_buildrequires implementation in mock (Issue #3121)
I'm not sure there's much to do about that now, the ship sailed a long ago. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3121#issuecomment-2126653511 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 --noprep regression from introducing %mkbuilddir (PR #3122)
@pmatilai pushed 2 commits. 67a2f8fe7c8ae7488d4485b4c0475f3816e57860 Fix --noprep regression from introducing %mkbuilddir 2542a424cb90a7cab24fd240221eb5a3e238fd47 Drop an accidentally added duplicated test -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3122/files/3df37d50f4633a8319623aa1606547780a428939..2542a424cb90a7cab24fd240221eb5a3e238fd47 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] %mkbuilddir breaks the %generate_buildrequires implementation in mock (Issue #3121)
Thanks BTW @hroncok and @praiskup for the detailed reports! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3121#issuecomment-2126518649 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] Make --build-in-place much less of a hack and also, work (PR #3124)
Instead of skipping everything in %setup, take advantage of it: we shouldnt unpack any sources but otherwise we can just let it fall through it, defining buildsubdir and everything, if we let rpm do its normal %mkbuilddir thing and just symlink to the in-place tree from rpms %builddir. This way its not such an ugly duckling interfering with how normal rpms are built, and even honors %setup flags to a degree. This fixes two regressions: one introduced when adding %mkbuilddir that nukes your current directory with no questions asked if --build-in-place is used before it even starts, and an earlier one from commit b34333fa021c0ee7215714eeef96d1a2843ea08e that would nuke your precious in-place directory afterwards. And as a side-effect of all this, debuginfo generation also now works with --build-in-place. Fixes: #3122 Fixes: #3042 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3124 -- Commit Summary -- * Make --build-in-place much less of a hack and also, work -- File Changes -- M build/parsePrep.c (17) M tests/rpmbuild.at (55) M tools/rpmbuild.c (8) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3124.patch https://github.com/rpm-software-management/rpm/pull/3124.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3124 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] --build-in-place regression from %mkbuilddir (Issue #3123)
Okay, but then --build-in-place has required --noclean to avoid the directory getting nuked since commit b34333fa021c0ee7215714eeef96d1a2843ea08e. Which is another regression actually, in rpm 4.18 I guess. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3123#issuecomment-2126345882 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] --build-in-place regression from %mkbuilddir (Issue #3123)
Similar and related to #3121, --build-in-place got very much broken by %mkbuilddir, and will *erase* the directory you're trying to build in. If that happens to be a source directory you're developing something in, you could lose actual data. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3123 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 --noprep regression from introducing %mkbuilddir (PR #3122)
@pmatilai pushed 1 commit. 3df37d50f4633a8319623aa1606547780a428939 Drop an accidentally added duplicated test -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3122/files/36bcf4f817636b1ac36c994da85e72787d891780..3df37d50f4633a8319623aa1606547780a428939 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 --noprep regression from introducing %mkbuilddir (PR #3122)
Commit 9d35c8df497534e1fbd806a4dc78802bcf35d7cb added a new step into the build process but I literally wasnt even aware we have a --noprep switch in rpmbuild, much less that its used. Quite widely even, by mock. Luckily this seems simple to fix, just skip %mkbuilddir in --noprep. Extend the dynamic buildrequires test to mimick what mock does. Fixes: #3121 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3122 -- Commit Summary -- * Fix --noprep regression from introducing %mkbuilddir -- File Changes -- M tests/rpmbuild.at (27) M tools/rpmbuild.c (2) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3122.patch https://github.com/rpm-software-management/rpm/pull/3122.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3122 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] %mkbuilddir breaks the %generate_buildrequires implementation in mock (Issue #3121)
As I said in #3120, my first reaction was: we have --noprep? :flushed: Git reveals the following: ``` commit 4f69f8b482e1bd61d5a7e1c8214e2ebc6cb66c5d Author: David Greaves Date: Tue May 26 12:31:51 2015 +0200 rpmbuild: Add "--noprep" to not execute %prep stage ``` So, no wonder I didn't remember that option because I wasn't doing rpm in 2015. Those couple of years are this annoying blank in my memory, all sorts of surprises creep up from there :laughing: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3121#issuecomment-2126192177 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] The --noprep option executes %mkbuilddir which breaks %generate_buildrequires in Mock (Issue #3120)
Okay #3121 has closer details + reproducer info, closing this as a dupe despite being the earlier one. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3120#issuecomment-2126182238 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] The --noprep option executes %mkbuilddir which breaks %generate_buildrequires in Mock (Issue #3120)
Closed #3120 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3120#event-12903005315 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] The --noprep option executes %mkbuilddir which breaks %generate_buildrequires in Mock (Issue #3120)
One takeaway from this is that we need some tests that mimick what mock does. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3120#issuecomment-2126177062 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] The --noprep option executes %mkbuilddir which breaks %generate_buildrequires in Mock (Issue #3120)
My first reaction to this is: "we have --noprep? :flushed: " I mean, in my 20+ years of life around rpm I must've seen that option *somewhere* but I had absolutely norecollection it existed. Much less that anybody would be using it. I can see why mock would use such a thing, but I'm not really comfortable with that because it seems that mock is now driving the build and not rpmbuild. And this means any changes to rpmbuild are even more difficult than they are otherwise. That said, I'm not exactly surprised that %mkbuilddir breaks *something* because it is quite a big change. Lets see what we can do about it, on the outset --noprep disabling %mkbuilddir seems reasonable but I'm only halfway into my first coffee... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3120#issuecomment-2126174025 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 STL conversions (PR #3119)
@pmatilai pushed 2 commits. ac97ea7655476f45e20fe8f73c2b008cc6cb91ff Convert a local array to vector in markReplacedFiles() fc259230aa930846e773898d4db90874a7c550bd Convert triggers run tracking from local array to vector -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3119/files/1a5d530720564a49931ce284f3a934961082119b..fc259230aa930846e773898d4db90874a7c550bd 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 STL conversions (PR #3119)
This time including string usages that speed up json and xml query formatting enormously. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3119 -- Commit Summary -- * Use STL string for header query formatting internal buffer * Take advantage of STL string for tag name formatting in queryformat * Use STL string for json escaping, speeds it up like 20x * Use STL string for xml escaping too, its a huge speedup * Replace manual allocations with vectors in skipInstallFiles() -- File Changes -- M lib/formats.c (68) M lib/headerfmt.c (107) M lib/transaction.c (14) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3119.patch https://github.com/rpm-software-management/rpm/pull/3119.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3119 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] Add proper logic for debuginfo enablement (PR #3085)
Oh, yup. I thought I made a further comment here but apparently didn't... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3085#issuecomment-2122295789 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: enable relevant debuginfo configs by default (Issue #3117)
We're now by default enabling debug packages on Linux since 8535694599ee7f35747d44e2ea0a62dc5e8880e5 but there are a thousand tunables that are not. Go through the knobs and tunables and set reasonable presets. At least %_debuginfo_subpackages and %_debugsource_packages should be enabled by default, there may be other stuff. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3117 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] Ensure noarch packages don't get debuginfo (PR #3116)
And now with a test-case... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3116#issuecomment-2122208337 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] Ensure noarch packages don't get debuginfo (PR #3116)
@pmatilai pushed 1 commit. 4631a3f4c03afbe41ef2a96c5d43a44a82e28b69 Ensure noarch packages don't get debuginfo -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3116/files/1eb269872142982dd21dce3015c2cd67d824e1e9..4631a3f4c03afbe41ef2a96c5d43a44a82e28b69 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] Ensure noarch packages don't get debuginfo (PR #3116)
Add back the %ifnarch noarch test overconfidently removed in commit 8535694599ee7f35747d44e2ea0a62dc5e8880e5, its more complicated than that. This is band-aid for #3115. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3116 -- Commit Summary -- * Ensure noarch packages dont get debuginfo -- File Changes -- M macros.in (2) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3116.patch https://github.com/rpm-software-management/rpm/pull/3116.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3116 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] %_enable_debug_packages can cause debuginfo on noarch packages (Issue #3115)
Commit 8535694599ee7f35747d44e2ea0a62dc5e8880e5 hinged the entire debuginfo generation logic around %_enable_debug_packages, including getting it right (disabled) for noarch packages from the platform configuration macros. The problem with that, %_enable_debug_packages is *intended* to be a distro/user configuration knob, whose configuration is read after the platform config. So when a distro explicitly enables sets `%_enable_debug_packages 1` it overrides it even for noarch, causing build failures. Luckily its easy to work around: add back the ifnarch test to %debug_macro (or comment out %_enable_debug_packages from distro config for now). But this clearly shows that setting this in platform configuration doesn't cut it, we need to rethink our approach. %_enable_debug_packages is this high-level knob where 0 means "never" and 1 means "create when possible/relevant", and we currently interpret as "always" instead. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3115 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: proper error reporting for fsm operations (Issue #3114)
#3100 started life as a report on unintelligible error message on install failure, and it's far from an isolated case. When an occurs inside the fsm, we save the path but not the errno. and when the error eventually does get reported there have been any arbitrary number of places that could, and often have, modified it. So what goes back to the user is unintelligible at best, misleading at worst. We need a better error reporting mechanism than rpmfileStrerror(), one that stores the actual context and result of the failure. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3114 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 rpmfi(les) hardlink discovery + lookup with STL containers (PR #3112)
Merged #3112 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3112#event-12874452602 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 merging of new key material when importing pubkeys (PR #3083)
@pmatilai approved this pull request. Looks fine to me! @nwalfield, if you can afford a few cycles to look at this before I hit merge, I'd appreciate... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3083#pullrequestreview-2067603707 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] Replace rpmfi(les) hardlink discovery + lookup with STL containers (PR #3112)
This was a fairly tricky one, details in commits. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3112 -- Commit Summary -- * Replace hardlink storage in rpmfi with STL * Replace hardlink discovery rpmhash with STL -- File Changes -- M lib/rpmfi.c (130) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3112.patch https://github.com/rpm-software-management/rpm/pull/3112.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3112 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] `%patchlist` should have a way to group patches (Issue #3109)
Closing in favor of #3110, but thanks for the initiative. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3109#issuecomment-2119881885 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] `%patchlist` should have a way to group patches (Issue #3109)
Closed #3109 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3109#event-12862536394 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 the various dependency checking hashes from rpmhash to STL (PR #3108)
Merged #3108 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3108#event-12861266300 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] inconsistency fix (PR #3105)
Closed #3105. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3105#event-12861262645 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] inconsistency fix (PR #3105)
Sorry but these kind of "fixes" are not worth the noise they make in commit history. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3105#issuecomment-2119713930 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 conditional patch application in %autosetup (Issue #3110)
Currently %autosetup only supports conditional patch application by either conditionalizing the patch declarations (which leads to inconsistent src.rpms). The other alternative is falling back to %autosetup -N and manual patch application with (ranged) %autopatch and/or plain %patch, both of which are error-prone. While ideally you don't carry conditional patches, real world often disagrees. We need a better way to handle this, something that removes the need for humans to deal with individual patch numbers while preserving them all in the src.rpm. One possible idea could be supporting multiple (named) %patchlist sections that are generally applied in the order they appear in the spec, but allow conditionalizing by the name/keyword, eg `%patchlist -k s390` whose patches are only applied if %bcond s390 is true. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3110 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] `%patchlist` should have a way to group patches (Issue #3109)
I'd rather see something like multiple %patchlists whose application can be controlled by something else. Patch numbers don't really cut it :sweat_smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3109#issuecomment-2117544777 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] `%patchlist` should have a way to group patches (Issue #3109)
Automatic patch numbering (whether %patchlist or unnumbered patches) and manual patch application based on them is a recipe for disaster that's best avoided IMO. The raison d'être of %patchlist is to minimize boilerplate in the common case where you just want to apply all patches. If you need precise control over patch numbers, better do so explicitly. One possible solution for this is to use manual Patch5123: numbering for those patches you need conditions on, just pick a sufficiently large starting number so the list doesn't clash (but it'll error out if that hapens). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3109#issuecomment-2117538261 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 the various dependency checking hashes from rpmhash to STL (PR #3108)
This isnt very idiomatic C++ but NULL pointers are used for logic so references wont do, and as for filedepHashFree() and depexistsHashFree(): deleting and NULLing all these pointers manually adds up. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3108 -- Commit Summary -- * Convert the various dependency checking hashes from rpmhash to STL -- File Changes -- M lib/depends.c (103) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3108.patch https://github.com/rpm-software-management/rpm/pull/3108.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3108 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] Fix a regression on dependency generator namespace directive (PR #3104)
Merged #3104 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3104#event-12844716539 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 a regression on dependency generator namespace directive (PR #3104)
Commit ce6c3812af4c2a9e9fc6c2dc77e00e1e1487bb83 accidentally changed this namespace string literal too, oops. Possible because there was no test on it, so add one. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3104 -- Commit Summary -- * Fix a regression on dependency generator namespace directive -- File Changes -- M build/rpmfc.c (2) M tests/rpmbuild.at (3) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3104.patch https://github.com/rpm-software-management/rpm/pull/3104.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3104 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 various dependency generator data structures over to STL (PR #3102)
Merged #3102 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3102#event-12844595239 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 various dependency generator data structures over to STL (PR #3102)
@pmatilai pushed 2 commits. e0e17dd305b83d8a2fd169ed231b6e1dd535efe6 Replace a manually allocated local array with a vector in depgen 155af57fe761ed1ea75203d121117a630cbe3993 Use an STL string for constructing the macro in rpmfcAttrMacroV() -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3102/files/cff4264d45e092722d0441356a8d86a2d9f2437a..155af57fe761ed1ea75203d121117a630cbe3993 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] C++ transition, guidelines and todo (Issue #3103)
For the lack of better place and to allow commenting/questions, putting this
here for now. Think of this as a forever work-in-progress doc on the subject.
Rpm being an old-school C project started in the nineties, transitioning it to
anything resembling a modern C++ codebase will be a long road. We're doing this
in multiple stages over years as time permits, with the initial priority being
on *enabling* use of C++ STL types and algorithms internally throughout the
code: stages 1 and 2. We are relative C++ newbies and will be missing tricks
and best practises, so questions and suggestions are quite welcome, *but*,
please understand the constraints we're living with:
- these guidelines are specifically for controlled, gradual transition towards
C++, for this particular project. It's *not* how a new C++ project should be
written.
- C++17 is the C++ standard versions we'll be using initially. We will upgrade
the standard as tooling matures, but fussing and buzzing how this or that is
done in C++23 is not helpful just now. I expect us to move to C++20 in a couple
of years. There are several things to look forward in that.
- rpm needs to maintain a stable C API and ABI
- these guidelines are specicially for that
== Stage 1, native allocation ==
Convert heap-allocated data structures to use new/delete or STL containers
instead of malloc/calloc/realloc/free. This is a practical requirement to allow
those structs to contain non-trivial C++ types like strings and containers.
Practicalities:
- things that API user needs to free() cannot be converted, new/delete must
always pair up. This may not always not always be obvious at the outset: if we
have fooNew() and fooFree() API, its okay to convert, but eg headerExport()
returns a blob that must be free()'d, and sometimes the implementation leaks
into the API in surprising ways.
- memset() cannot be used for initialization in C++, always use `new {}` to
ensure similar effect (`mytype_s foo {}` for local structs)
- realloc() always calls for an STL container (or string, we realloc those a
lot too)
- DON'T use raw C++ arrays (ie new[]/delete[]), they're just painful
STL notes:
- watch out when storing data that requires manual freeing in containers (see
stage 2)
- vector is your Swiss army knife for transition work, in particular it exposes
its raw data via non-const .data() which can be passed around to unsuspecting C
code without modifications to keep changes local and minimal (as long as it's
not free()'d)
- rpmhash is a flexible beast that supports multiple values per key and also
set semantics, replacing rpmhash calls for one of unordered_multimap,
unordered_map (depending on use), or unordered_set.
- when passing containers as arguments, prefer references over raw pointers
(for safety, but also eg vector[index] becomes annoying otherwise)
== Stage 2, native objects ==
This is basically the flip-side of the stage 1 coin, the objective being to
make rpm structs RAII compatible native objects and safe for use in STL
containers. Meaning construcors/destructors and copy-control (see rule-of-five)
Practicalities:
- default-initialize the struct members in the struct declaration itself, this
ensures you never end up with uninitialized members no matter what
- if unsure, mark it as deleted. The compiler will tell you if it needs it, but
it will *not* tell you the default-generated method is unsafe for a given
datatype
== Stage ??, fancy pants ==
Look at things like smart pointers. Rpm is full of pointers that we'd prefer
automatically freed, and many of those are manually reference counted too. Many
of them will also get passed to C which limits our options.
== Source (re)naming ==
We'll rename all the C++ sources to an appropriate extension somewhere around
rpm 4.20 beta/rc release, at any rate during 2024. This is lessons learned from
similar transition in gcc who only renamed things 10+ years after the fact.
Having C++ in files called .c is painful for a whole number or reasons,
including
- build systems will fight you back
- syntax highlighting will fight you back
- its just confusing
== C++ APIs ==
Sooner than later we'll need to start adding C++ native APIs to move things
forward. Initially these will be internal only to allow us to learn the ropes
before heading to open seas.
Some immediate needs that have risen already and have a wide impact internally:
- macro expansion that accepts and returns STL strings
- argvSplit() and argvJoin() counterparts
Any new APIs should be written with RAII in mind. Macros make for a nice
example: the macro context is mutex-protected, and each rpmExpand() call is
forced to take and release a lock, and anything at all can happen between two
expands. The sane way to do this is to acquire a local context object which is
allows you to do your business and at the end of scope the variable goes out of
scope and so does the lock.
== C++ hygiene ==
- change C standard library
Re: [Rpm-maint] [rpm-software-management/rpm] Convert various dependency generator data structures over to STL (PR #3102)
@pmatilai pushed 1 commit. cff4264d45e092722d0441356a8d86a2d9f2437a Use STL vector file attribute types too -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3102/files/cbe0386ef31aa62735f7c1601039b464314e0f01..cff4264d45e092722d0441356a8d86a2d9f2437a 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 various dependency generator data structures over to STL (PR #3102)
You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3102 -- Commit Summary -- * Permit appending native strings to StringBuf * Use STL vector and strings for file and type in file classifier * Use STL string for file classifier buildroot * Use vectors for various file classifier storages * Replace all ARGI_t uses with STL vector in file classifier * Add tests for file dependency normalization behavior * Use STL vector for dependency generator file dependency storage -- File Changes -- M build/misc.c (2) M build/rpmbuild_internal.h (2) M build/rpmbuild_misc.h (4) M build/rpmfc.c (236) M tests/rpmbuild.at (17) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3102.patch https://github.com/rpm-software-management/rpm/pull/3102.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3102 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 major librpmbuild structs to native C++ allocation / initialization (PR #3099)
Merged #3099 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3099#event-12828183731 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] Clean up applyAttr() and rpmfcHelper() interaction (PR #3101)
Merged #3101 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3101#event-12827802004 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] Clean up applyAttr() and rpmfcHelper() interaction (PR #3101)
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. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3101 -- Commit Summary -- * Clean up applyAttr() and rpmfcHelper() interaction -- File Changes -- M build/rpmfc.c (49) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3101.patch https://github.com/rpm-software-management/rpm/pull/3101.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3101 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 major librpmbuild structs to native C++ allocation / initialization (PR #3099)
@pmatilai commented on this pull request.
> }
StringBuf freeStringBuf(StringBuf sb)
{
-if (sb) {
- sb->buf = _free(sb->buf);
- sb = _free(sb);
-}
-return sb;
+delete sb;
There will also need to be stuff like mass-moving to the C++-versions of C
headers, converting NULL to nullptr and whatnot.
And I really need to write this stuff down someplace where people can see...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3099#discussion_r1602643629
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 major librpmbuild structs to native C++ allocation / initialization (PR #3099)
@pmatilai commented on this pull request.
> }
StringBuf freeStringBuf(StringBuf sb)
{
-if (sb) {
- sb->buf = _free(sb->buf);
- sb = _free(sb);
-}
-return sb;
+delete sb;
Oh, absolutely. This is really just stage 1 of the C++ onboarding, with many
more to follow as time permits. The early steps look something like this:
Stage 1: natively allocate everything to allow use of non-trivial structures
within
Stage 2: make our structs behave in STL containers (ie add destructors and
copy-control)
Stage 3: take advantage of smart pointers and similar (look to replace manual
reference counting, mutex locking and such)
...
And of course, look for opportunities to move stuff over to STL types is an
on-going thing. I've been eliminating explicit new/delete where easily achieved
when moving to STL containers. Stage 1 is sticking with these manual
allocations just to keep things simple, just moving to STL containers presents
plenty enough of unexpected side-effects :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3099#discussion_r1602639404
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 major librpmbuild structs to native C++ allocation / initialization (PR #3099)
@pmatilai pushed 1 commit. 05f1578f82cb5d2fc8911c6c14ccb78e4f87f5f8 Replace rpmhash with STL unordered_multimap in file rename tracking -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3099/files/46e7fbfcd4a8534395f0a13c1d6b982410fa3916..05f1578f82cb5d2fc8911c6c14ccb78e4f87f5f8 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 major librpmbuild structs to native C++ allocation / initialization (PR #3099)
Details in the commits, in brief this brings the major data structures of librpmbuild under C++ native allocation and initialization, making it possible to use native data types in said structs. A few obvious cases converted to STL too, but plenty more to do on that department. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3099 -- Commit Summary -- * Natively allocate rpmfc main structures * Natively allocate the spec and its package structs * Natively initialize the file list structure * Natively allocate special dir structs and related entries * Natively allocate spec read and file stacks * Use a C++ string for StringBuf internally * Natively allocate the spec listiter macro fu * Store trigger file info natively in STL vectors * Natively allocate spec source and selinux policy structs * Use an STL vector for spec file records storage -- File Changes -- M build/files.c (153) M build/misc.c (59) M build/pack.c (34) M build/parsePreamble.c (2) M build/parseScript.c (28) M build/parseSpec.c (8) M build/policies.c (4) M build/rpmbuild_internal.h (8) M build/rpmfc.c (11) M build/spec.c (49) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3099.patch https://github.com/rpm-software-management/rpm/pull/3099.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3099 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)
> the "legacy" backend @mlschroe , I didn't quite expect you to start so actively hacking on it, more like terminal care and hence the name. If you intend to continue developing it, I'm okay with renaming it to something else than "legacy". Only it can't be "internal" anymore because it's not :sweat_smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3083#issuecomment-2111729619 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] Improve the debuginfo enablement backwards compatibility (PR #3098)
Merged #3098 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3098#event-12800386736 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] Dynamic generator generates "invalid" srpm (Issue #3096)
Summary is a mandatory field on rpm packages, we cannot very well write illegal packages. If we don't have a meaningful value we need to stick *something* in it. That said, this is probably a bridge too far and seems easily avoided by requiring the mandatory base tags to be supplied by the spec. They are not that many. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3096#issuecomment-2109839116 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 git-bisect in the test-suite in a friendly way (Issue #3097)
Yeah I'd prefer a place for ad-hoc tests, because whenever you need to bisect something you almost certainly want to add it to the test-suite afterwards. So if it's already in the test format, you just move it around without having to rewrite from some custom logic. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3097#issuecomment-2109587183 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] Improve the debuginfo enablement backwards compatibility (PR #3098)
Move the enablement logic to %__spec_install_template where it can be buried with relatively little danger of being overridden by distros or packagers. Its moderately annoying as the logic isnt no longer neatly in one spot, but %__spec_install_post is commonly overridden by distros and even packages, and in particular we dont 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. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3098 -- Commit Summary -- * Improve the debuginfo enablement backwards compatibility -- File Changes -- M platform.in (6) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3098.patch https://github.com/rpm-software-management/rpm/pull/3098.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3098 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] Free old cookie value to prevent a memory leak (PR #3095)
Merged #3095 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3095#event-12797198526 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] Free old cookie value to prevent a memory leak (PR #3095)
AIUI the cookie is intended to link packages from a single build together, and apparently I even documented that: "An opaque value for tracking packages from a single build operation" So this seems the right thing to do there, not that I know anybody using the cookie for anything... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3095#issuecomment-2109456672 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 test-suite under Fedora 40 modern C rules (PR #3094)
The modernization patch never was included in the src.rpm, it's only in separate specs based off that hello.spec. And, we still have the original hello-1.0.tar.gz to which the modernize patch applies (and is applied) in various other tests. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3094#issuecomment-2107560693 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 test-suite under Fedora 40 modern C rules (PR #3094)
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 #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 were 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. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3094 -- Commit Summary -- * Fix test-suite under Fedora 40 modern C rules -- File Changes -- M tests/data/SPECS/hello-autopatch.spec (4) M tests/data/SRPMS/hello-1.0-1.src.rpm (0) M tests/rpmpython.at (2) M tests/rpmquery.at (2) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3094.patch https://github.com/rpm-software-management/rpm/pull/3094.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3094 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] %autopatch -m/-M fall through silently if no patches are in range (Issue #3093)
hello-autopatch.spec in our testsuite has this: ``` %patchlist hello-1.0-modernize.patch hello-1.0-install.patch %prep %autosetup -N %autopatch 1 %autopatch -m 2 ``` Spot the error? Automatic patch numbers start from zero, so we're telling it to apply hello-1.0-install.patch and then any higher numbered patches, so the modernize patch is never applied. There are legitimate reasons to conditionally skip patches, but having a ranged patch that doesn't actually do anything should at least emit a warning. How did we find out? Fedora 40 introduced stricter, more modern C compilation settings (https://fedoraproject.org/wiki/Changes/PortingToModernC ) and suddenly we had a test-case go red because it wasn't applying a patch it's supposed to, to address this very issue. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3093 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)
Just noting it here that since distros are widely overriding %__spec_install_post, they'll need to update that to match the new logic in there. @ffesti's version placed the %_enable_debuginfo_packages test into %__spec_install_pre which isn't as widely overridden and so would be more backwards compatible, but then it wouldn't be all in one place. It's a hugely annoying mess :unamused: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3085#issuecomment-2107200152 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: cleanly support post-stripping actions in spec (Issue #3092)
Looking at Fedora packages, there's a very distinct use-case for which multiple packages have to override the entire %__spec_install_post section: stripping changes checksums and the like, and any embedded signatures in files will have to be (re)done after the stripping. As the kernel.spec puts it: ``` # Disgusting hack alert! We need to ensure we sign modules *after* all # invocations of strip occur, which is in __debug_install_post if # find-debuginfo.sh runs, and __os_install_post if not. ``` This pattern causes a verbatim copy of %__spec_install_post to be carried in affected packages (nettle, nss, openssl, gnutls, libgcrypt, you get the picture), and as ever with copies, they get out of sync and lack features/fixes when there are changes to the original. We need to offer a clean way to do this without needing ugly copies and overrides. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3092 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: drop rpmlib() poisoning from --short-circuit'ed binaries (Issue #3091)
The bad is that it disagrees with rpm design philosophy where the package goes from a source to a binary in one uninterrupted reproducible (in a sense) go. It's of course possible to circumvent that in any number of ways, but encouraging it by making it easy is a whole can of worms. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3091#issuecomment-2107164699 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)
Had a brief look at killing %__debug_package, but that gets more complicated
than it should (and who's surprised?) So many packages rely on redefining
%debug_package to %{nil} for disabling debuginfo generation that we just have
to preserve that for the time being, and having %debug_package define something
else as a side-effect is an easy (if ugly) way to handle this. Not worth
messing with just now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3085#issuecomment-2106828884
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)
Mentioned the %setup-less debuginfo case and added an explicit sub-test for it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3085#issuecomment-2106811147 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)
@pmatilai pushed 1 commit. 8abfcff2ec15d750f9f92d7a8053413fe888172e Add proper logic for debuginfo enablement -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3085/files/d8ad95f93cfb362390e3f0249d9bcbcad7eb4d5a..8abfcff2ec15d750f9f92d7a8053413fe888172e 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 program logic for debuginfo enablement (PR #3036)
Closed #3036. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3036#event-12782153559 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 program logic for debuginfo enablement (PR #3036)
Closing in favor of #3085 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3036#issuecomment-2106783596 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)
Yeah it's nice to be able to use the dynamic spec stuff for our own purposes. To clarify, #3084 is only needed for the "rpmbuild %caps" test which intentionally does not use %setup to test that case, and whose debuginfo now gets generated. So that's basically another bug fixed / limitation eliminated, I could've sworn we have a ticket on debuginfo requiring %setup but can't find it. I haven't tested but it may well cure #3042 too because the combo means it no longer requires the full %setup thing to run. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3085#issuecomment-2106780415 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: drop rpmlib() poisoning from --short-circuit'ed binaries (Issue #3091)
> The whole idea of "prevent people from distributing them" doesn't make much > sense. You cannot build a package with --short-circuit "accidentally". It's a > very long option that you need to insert in the right place. And I guess > "otherwise" means "maliciously" here Obviously you can't use --short-circuit accidentally, the accident refers to distributing a binary built that way. Think of a lone developer uploading a binary built on their own system to the net for others to use. That's not as common these days as it once was, nowadays thankfully most people use actual build systems. The "otherwise" doesn't refer to malice, but ignorance. There have been people wanting to distribute packages built with short-circuit, just to shorten their build times basically. But 14 years later (7583fcc3416e5e4accf1c52bc8903149b1314145) and hopefully a bit wiser too: a gentler version would be simply to "watermark" short-circuited builds somehow. It doesn't have to be a install-breaking dependency, just something that you can check. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3091#issuecomment-2106778640 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] --short-circuit poisons the produced packages (Issue #3091)
> Only with --short-circuit we "poison" the produced packages to prevent people from distributing them (accidentally or otherwise). It is a misfeature. It means that the produced packages cannot be compared and tested properly. In particular, `--short-circuit` is very often used to tweak and test details of `Obsoletes` and `Requires` and such. Not being able to produce the package that looks *exactly* like the normal output makes the build not useful. The whole idea of "prevent people from distributing them" doesn't make much sense. You cannot build a package with `--short-circuit` "accidentally". It's a very long option that you need to insert in the right place. And I guess "otherwise" means "maliciously" here, and that's even less useful, because the person doing the build has full control over what is built, so they don't need to use `--short-circuit` to achieve malicious goals. Instead of using `--short-circuit`, people are forced to either wait for full package builds (which can be hours), or do dirty tricks like comment out part of the spec file. Those solutions are much worse (and much more likely to go wrong), than the problem being solved, i.e. people forgetting that they used `--short-circuit` and distributing those packages. Please drop this whole protection and let people use `--short-circuit` without any limitations. _Originally posted by @keszybz in https://github.com/rpm-software-management/rpm/issues/3042#issuecomment-2074531384_ -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3091 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] Always create %specpartsdir on build (PR #3084)
With this, %specpartsdir gets created *before* %prep. The idea being that %specpartsdir, just like %builddir, are rpm provided infrastructure that can be counted on always being there no matter what the spec does (or doesn't) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3084#issuecomment-2106711798 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)
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
