@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
@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
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:
___
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
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
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:
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:
@pmatilai pushed 2 commits.
67a2f8fe7c8ae7488d4485b4c0475f3816e57860 Fix --noprep regression from
introducing %mkbuilddir
2542a424cb90a7cab24fd240221eb5a3e238fd47 Drop an accidentally added duplicated
test
--
View it on GitHub:
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:
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
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:
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
@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
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
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
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
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
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:
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
@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:
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
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:
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
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: ___
@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
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 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
#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,
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
@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:
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
--
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:
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
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
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
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
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
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
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
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:
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
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
--
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
@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:
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
@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
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
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
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
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,
@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,
@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
@pmatilai pushed 1 commit.
05f1578f82cb5d2fc8911c6c14ccb78e4f87f5f8 Replace rpmhash with STL
unordered_multimap in file rename tracking
--
View it on GitHub:
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,
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
@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
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
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: ___
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
> 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
> 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
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:
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:
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:
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
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
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.
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
@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:
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
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
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
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
...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: ___
@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
...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
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
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
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
@pmatilai pushed 2 commits.
85b181479291fa0f1a5a7f202fc1849c998b3faf Natively allocate the main file
trigger structs
cbbfe1ee74859818cf45c4a7b2812541216ef51f Convert packageHash to STL
unordered_map
--
View it on GitHub:
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
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
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
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
@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 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
1 - 100 of 7772 matches
Mail list logo
