@pmatilai commented on this pull request.
> @@ -56,6 +56,8 @@ contains an OpenPGP signature on the header + payload data.
> The PGP
tag is used for RSA signatures and the GPG tag is used for DSA
signatures.
+Note: the signature tags overlap with those of the main header.
What I mean by
@pmatilai converted this issue into discussion #2864.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2862#event-11552920204
You are receiving this because you are subscribed to this thread.
Message ID:
The more I looked at this and the existing docs, the more clear it became that
the stuff needs more than a touch-up job to be credible.
I ended up rewriting much of bit of it, updating and preserving the v3 docs too
for historians and the like: #2861. That was quite the pile to chew out in a
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2861
-- Commit Summary --
* Use markdown formatting features for package format, fix links
* Split the lead and header structure to their own documents
* Fix some
On a related note, it wouldn't hurt to ship the manual in html format in our
tarballs. I guess we'd need Mr Jekyll for that too.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2854#issuecomment-1900072519
You are receiving this
Well, I always intended systemd-sysusers to be the native and default "backend"
of this feature because ... it is.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2857#issuecomment-1899950764
You are receiving this because you are
@pmatilai commented on this pull request.
>
return 0;
}
const char * rpmugUname(uid_t uid)
{
-static uid_t lastUid = (uid_t) -1;
-static char * lastUname = NULL;
-
-if (uid == (uid_t) -1) {
- lastUid = (uid_t) -1;
Yup, and as an added bonus it now never contains
For someone like me who's utterly unaware of the Ruby ecosystem, setting up the
jekyll server for locally testing docs changes is a rather terrifying
experience.
We should have a cmake target that sets it up and runs it in a hands-free
manner. Something along the lines of "make docs-server"
@pmatilai pushed 1 commit.
58b13066e4b540d6440c41becaf3690663cd46d2 Simplify the cache lookup logic, no
functional changes
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2843/files/d23eb53abdde25ad2c45d20c32dde255fb36384d..58b13066e4b540d6440c41becaf3690663cd46d2
Merged #2852 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2852#event-11521524070
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Ack, one of many many many many tiny things that fell through the cracks,
probably a case of "I'll fix this later". Thanks for the patch!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2852#issuecomment-1897951171
You are receiving this
Merged #2853 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2853#event-11521499719
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
The feature is no longer "autobuild" so there's nothing to rename.
Thanks for the patch!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2853#issuecomment-1897947879
You are receiving this because you are subscribed to this thread.
Just FWIW, https://gitlab.kitware.com/cmake/cmake/-/issues/22852 describes this
very case.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2820#issuecomment-1895869882
You are receiving this because you are subscribed to this thread.
@pmatilai requested changes on this pull request.
I came *this* close to merging, but testing made me remember why it's done the
way it is: we want the tarballs always recreated on "dist". With this patch,
that no longer happens.
Of course loops can't be right either, but I can't apply this
Oh indeed. I tweaked the commit message to elaborate on when it happens (this
only affects building from git without doxygen, release tarballs have the html
content prebuilt) and applied manually as commit
6098fe1e9f735ab3a603eb429e01300ae48bf4fe
Thanks for the patch!
--
Reply to this email
Closed #2848.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2848#event-11510440839
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
@pmatilai converted this issue into discussion #2851.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2389#event-11510089819
You are receiving this because you are subscribed to this thread.
Message ID:
I think it's slighly more subtle: whether a file is a %license or not has
little relevance to verify results. However a content mismatch on a %config
file is something entirely different (with possible noreplace/missingok
modifiers) and yet again quite different for a %ghost which can also have
Closed #2817 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2817#event-11508091602
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
> MANY projects have not updated .po files
I fail to see any relevance to rpm.
In any case, this is supposedly fixed in
b4dc72f4b92489f77de9b0ae0bed754875d37ece.
--
Reply to this email directly or view it on GitHub:
Split to refactor + thread-safe fix, and restored that rpmugFree() on librpm
exit that had gone missing at some point.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2843#issuecomment-1893715068
You are receiving this because you are
@pmatilai pushed 3 commits.
4945ad298058fd3c325c6b803ef6c3e2cb2d97aa Remember to free user/group cache on
librpm shutdown (again)
8656e2e0327a9af38ef180eb014bac9271b3f8df Centralize user/group lookup caching
into a single data structure
d23eb53abdde25ad2c45d20c32dde255fb36384d Make
Oh, except that rpmugGname() and rpmugUname() additionally rely on central
storage of the returned values so simple mutex locking doesn't work for those.
So those would have to be changed to return malloced data for a simple fix (it
wont break any users because there aren't any, at the moment).
It wouldn't be hard to introduce per-thread locking instead. The bigger deal
here is the new central struct that makes it possible to do stuff, perhaps I
should actually split that into a separate commit and then consider the thread
safety separately. The reason its lumped into one is basically
Yup, but this patch doesn't change that, the "leak" is already there. This only
makes it per-thread.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2843#issuecomment-1893568039
You are receiving this because you are subscribed to this
It does leak, should've mentioned that in the commit message. In the sense that
each thread calling it will leave one cache around and reachable. It's far from
ideal but it's basically an emergency bandaid.
What do you mean about ending itself?
--
Reply to this email directly or view it on
Added buildroot itself to the description, there's no reason whatsoever to
scatter the built content around multiple directories if we have that one
top-level directory to rule it all.
--
Reply to this email directly or view it on GitHub:
Right, that one. An architecture change is a fairly special operation, I'm not
convinced it needs to "just work" with regular update, it just needs to be
doable. Eg, using --replacepkgs, which back then it wasn't. Also, an i686
package *can* be considered an update to an i586 package, but a
> Couldn't we just make `%setup -c` the default behavior and then strip the top
> level directory automatically when extracting an archive?
This directory needs to be set up regardless of whether a spec uses %setup or
not. And, extracting the sources to the topmost directory would defeat some
> What's so special about an identical NEVR? The content may still be
> different, we had a couple of bug reports about same NEVR with different
> files and rpm not doing the correct thing.
Because by the very definition of rpm, release must change any time content
changes?
That people
Closed #1087 as completed via f02ddfd121d91ea00a534a0e04374c478f56d437.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1087#event-11487059627
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #2774 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2774#event-11487059342
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Okay I guess we've had all the feedback we're going to get on this.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2774#issuecomment-1891987087
You are receiving this because you are subscribed to this thread.
Message ID:
(commit message tweaked somewhat in the later pushes)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2843#issuecomment-1891985861
You are receiving this because you are subscribed to this thread.
Message ID:
This seems like a huge overkill when in 4.19.1 theres exactly one
rpmfiStat() call that unnecessarily invokes an rpmug lookup in a threaded
scenario, but then rpmfiStat() and rpmfilesStat() are public APIs that people
expect to be safe for use within the originating thread.
Collect all the
No colors are involved in this case (no files, but yes rpmteColorDS() is the
key to the coloring thing. It's weird alright.
I guess I thought thought the patch only affected --replacepkgs behavior when
that's what the commit message talks about and that's the testcase that chances
as well. But
FWIW, this isn't an rpm issue at all. It's like any old feature test, you test
for the symbol in cmake, and define something you *can* test with ifdef. There
are multiple ways to do that.
--
Reply to this email directly or view it on GitHub:
Bisecting points the regression to commit
21836bc7524f8fc07972e0e56eed1c3b68775368
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2837#issuecomment-110637
You are receiving this because you are subscribed to this thread.
Message
Easily reproduced with that. This is not just a bug but a regression too, 4.14
doesn't behave this way.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2837#issuecomment-1888743606
You are receiving this because you are subscribed to
Rpm erasing the older versions is more or less expected (see below), but that
the equal version too seems bizarre and buggy alright. Can you provide the
reproducer for B, as simple as it may be?
For the erasure of older versions, the behavior depends on the package colors,
not architecture,
@pmatilai converted this issue into discussion #2841.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2840#event-11466189810
You are receiving this because you are subscribed to this thread.
Message ID:
The last commit to not ship our example buildsystem macros could/should be
merged into the "Implement..." commit instead, just made it separate to make it
easy to back out if necessary.
--
Reply to this email directly or view it on GitHub:
@pmatilai pushed 5 commits.
6805bd7fded2d83369d9317c7fdeb1063f2d1af4 Use rpmSpecGetSection() internally
where appropriate
40c0721f8055378bdc3461b155c97438945bc498 Store spec section string buffers as
an array
ddb1c4bdf23ab1074049d827990170074e02901f Implement declarative buildsystem
support
@pmatilai pushed 1 commit.
c4be21841fbdde56f647247758f54e31eb99fc31 Define a global %clean default, reuse
for the non-buildsystem, case too
--
View it on GitHub:
Merged #2838 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2838#event-11454466451
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Oh, nice catch. I guess I thought/assumed implementing EQ will do the right
thing with NE too because .. well, it's just the opposite, right?
Guess not. Thanks for the patch!
--
Reply to this email directly or view it on GitHub:
@pmatilai commented on this pull request.
> @@ -24,16 +24,19 @@ package file is divided in 4 logical sections:
```
All 2 and 4 byte "integer" quantities (int16 and int32) are stored in
Sorry, forgot to mention this yesterday: we also have 64bit integers where this
also applies.
--
Reply
@pmatilai commented on this pull request.
> @@ -264,3 +256,101 @@ could start at byte 589, byte that is an improper
> boundary for an INT32.
As a result, 3 null bytes are inserted and the date for the SIZE actually
starts at byte 592: "00 09 9b 31", which is 629553).
+### Immutable header
Again, these are just (sub)architectures, and as always, the arch is present in
the rpm package file name.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2825#discussioncomment-8076099
You are receiving this because you are
Oh. Any resemblance to Flatpak is purely coincidental, I swear :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2774#issuecomment-1883072742
You are receiving this because you are subscribed to this thread.
Message ID:
@pmatilai commented on this pull request.
> +without the parenthesis defaults to configuration. In other words,
+these two lines are exactly equivalent:
+
+```
+BuildOption: --enable-fu
+BuildOption(conf): --enable-fu
+```
+
+Passing these per-section options to the actual buildsystem of the
@pmatilai commented on this pull request.
> @@ -0,0 +1,22 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ''
+labels: RFE
+assignees: ''
+
+---
+
+If your feature need figuring out how to implement it or needs feedback from
the wider comunity, please open a
@pmatilai commented on this pull request.
> @@ -0,0 +1,22 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ''
+labels: RFE
+assignees: ''
+
+---
+
+If your feature need figuring out how to implement it or needs feedback from
the wider comunity, please open a
Closed #2752 as completed via #2836.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2752#event-11429242342
You are receiving this because you are subscribed to this thread.
Message ID:
___
Merged #2836 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2836#event-11429242051
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Right, I remember encountering this pattern somewhere. Always looked like one
of those cmake WTFs for me, which is probably why I tried to find some other
way to do it. And as such, it was probably always for the worse.
I'll accept changing this for correctness, but note that we officially only
@pmatilai commented on this pull request.
> @@ -434,17 +434,17 @@ function(add_tarball targetname namever treeish)
set(distname ${tarname}.bz2)
set(docname ${namever}-doc.${distfmt})
- add_custom_target(${docname}
- DEPENDS man apidoc
+ file(GLOB
@pmatilai commented on this pull request.
> +they store can be found [here](signatures_digests.md).
+
+RPM v4 packages are expected to contain at least one of SHA1HEADER or
SHA256HEADER
+tags, providing a cryptographic digest of the main header, and may contain one
+or both of the
@pmatilai commented on this pull request.
> @@ -435,7 +435,7 @@ typedef enum rpmSigTag_e {
RPMSIGTAG_RESERVEDSPACE = 1008,/*!< internal space reserved for signatures
*/
RPMSIGTAG_BADSHA1_1= RPMTAG_BADSHA1_1, /*!< internal Broken
SHA1, take 1. */
RPMSIGTAG_BADSHA1_2
@pmatilai commented on this pull request.
>
Tag Name | Value| Type | Description
--|--|--|
-Dsaheader | 267 | bin | OpenPGP DSA signature of the header
(if thus signed)
-Longsigsize | 270 | int64|
@pmatilai commented on this pull request.
> +unique tags (just like the Header). Details about these tags and the
> information
+they store can be found [here](signatures_digests.md).
+
+RPM v4 packages are expected to contain at least one of SHA1HEADER or
SHA256HEADER
+tags, providing a
@pmatilai commented on this pull request.
> -header structure:
-
-```
- NameTag Header Type
- ---
- SIZE1000INT_32
- MD5 1001BIN
- PGP 1002BIN
-```
-
-The MD5 signature is 16 bytes, and the PGP signature
@pmatilai commented on this pull request.
>
```
0008: 00 01 72 70 6d 2d 32 2e..rpm-2.
```
-The next two bytes (8-9) form an int16 that indicates the architecture
-the package was built for. While this is used by file(1), the true
-architecture is stored as a string in the
@pmatilai commented on this pull request.
> @@ -23,17 +23,20 @@ package file is divided in 4 logical sections:
. Payload -- compressed archive of the file(s) in the package (aka "payload")
```
-All 2 and 4 byte "integer" quantities (int16 and int32) are stored in
-network byte order.
@pmatilai commented on this pull request.
> # Package format
-This document describes the RPM file format version 3.0, which is used
-by RPM versions 2.1 and greater. The format is subject to change, and
-you should not assume that this document is kept up to date with the
-latest RPM code.
The arch levels are not a new feature, just new sub-architectures. Think i386
getting expanded to i486, i586 and i686 back then, and similar levels exist on
arm already. The rpm arch only works as package level differentiator and to
ensure you can't install a package eg for level 4 on a level 3
%readme as a spec directive may be obsolete, but there's no reason to drop
support for the virtual file attribute. On the contrary, if it was properly
integrated with %doc it would be nice to 'rpm --show-readme mypackage' instead
of having to chase around in /usr/share/doc.
--
Reply to this
File-based self-dependencies are not going anywhere in general, because rpm
uses that info for its own purposes. Besides, they serve as a dependency
generation sanity check, and avoid surprises when (not if) packages get split
to smaller pieces.
Whether those %config() deps in particular serve
See
https://web.archive.org/web/20070621191805/https://www.redhat.com/archives/rpm-list/2001-April/msg00283.html
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8061569
You are receiving this because you are
It may be considered legacy in Fedora but I disagree. It's not going anywhere.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8061517
You are receiving this because you are subscribed to this thread.
OTOH, %pre should become rare again once the native user/group handling starts
getting actually used.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2834#issuecomment-1882534469
You are receiving this because you are subscribed to
And yup, most of rpm documentation is either really old, or really recent, with
a circa 20 year gap in between. I try to leave some old stuff around just for
the historical context/curiosity, but that statement about %pre rarity is just
wrong and needs to go.
--
Reply to this email directly
Merged #2831 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2831#event-11418620125
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Oh okay, arm64, that's a difference. But then it doesn't happen on Fedora koji
builds on that platform, eg here:
https://kojipkgs.fedoraproject.org//packages/rpm/4.19.1/1.fc39/data/logs/aarch64/build.log
Could be a difference in installed packages perhaps, maybe there's a cmake
module that
This seems pretty bizarre, all I get is
```
[...]
-- Looking for sys/auxv.h
-- Looking for sys/auxv.h - found
-- Looking for major
-- Looking for major - found
-- Performing Test found
-- Performing Test found - Success
[...]
```
And that's how it goes in all our CI builds, Fedora packages and
Huh. That's where our CI is building every PR on the project, and what I use
locally. Without seeing any errors from this.
Can you provide a full reproducer for getting to that failure, I'd like to try
and understand what's going on here.
--
Reply to this email directly or view it on GitHub:
@pmatilai commented on this pull request.
> @@ -0,0 +1,22 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ''
+labels: RFE
+assignees: ''
+
+---
+
+If your feature need figuring out how to implement it or needs feedback from
the wider comunity, please open a
I'm afraid it's undocumented except for the release notes:
https://rpm.org/wiki/Releases/4.15.0
The meaning of a numberless `Patch:` has varied over the years. Initially it
was equal to Patch0, then was a special entry of its own, and then, because it
was already broken and ambiguous, it was
There's just one flag for it all (`RPMFILE_MISSINGOK`) so `%config(missingok)`
equals `%config %missingok`. The standalone `%missingok` was only added in 2016
(8efe51e8c24b7739f0bf7680e21083c8964633f5) so relatively late.
--
Reply to this email directly or view it on GitHub:
They're just copy-paste/thinkos because the tags have the *in part, but %pre
and %post don't.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2834#issuecomment-1880766241
You are receiving this because you are subscribed to this
Closed #2807 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2807#event-11415849160
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
As per above report, fixed by #2812
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2807#issuecomment-1880745280
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #2812 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2812#event-11415830473
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
As per
https://github.com/rpm-software-management/rpm/issues/2807#issuecomment-1877296382
mission accomplished.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2812#issuecomment-1880742543
You are receiving this because you are
Excellent! :partying_face:
And again, thank you for reporting, suggesting fixes and testing. This is how
it works :+1:
It's also worth noting that absolutely nothing at all here was specific to
macOS, just more fallout from the cmake switch.
--
Reply to this email directly or view it on
The patch is correct of course, but I'm curious: what cmake version is failing
due to this? Because the project is certainly building fine on several
platforms/distros as is.
--
Reply to this email directly or view it on GitHub:
@pmatilai commented on this pull request.
> @@ -0,0 +1,22 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ''
+labels: RFE
+assignees: ''
+
+---
+
+If your feature need figuring out how to implement it or needs feedback from
the wider comunity, please open a
The thing to ponder about is whether there are other arguments that should be
passed in addition or in stead of these. The only "vision" or "design" behind
this ticket description is "something close enough to other scriptlets that
someone familiar with should feel at home". Which may leave
Aggregate is what I thought of when writing the description, I don't see
anything else making much sense. But, it's not like I've given this any deep
meditation. Usefulness is all that matters for the arguments, otherwise we
could just as well not bother :sweat_smile:
--
Reply to this email
Oops, there was an unrelated extra commit from work related to #2803, must've
gotten my local branches mixed up...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2774#issuecomment-1876881461
You are receiving this because you are
Merged #2803 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2803#event-11388155549
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Three weeks should be enough think-time for this and since I didn't come up
with anything...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2803#issuecomment-1876872414
You are receiving this because you are subscribed to this thread.
Pushed another update to the PR, hopefully that covers these final bits too.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2807#issuecomment-1876776814
You are receiving this because you are subscribed to this thread.
Message ID:
@pmatilai pushed 3 commits.
052e8f4d8778330e6e4c7b418bae33953187e640 Fix libintl linkage and include
directories (cmake transition fallout)
2dd2f95806440eb4f59916112160511e58bb300d Drop unnecessary rpmcli.h include
from rpmbuild.h
0adda3dac4d511f36b7c6d7ec061035b6def3793 rpmcli.h forces a
Hmm, actually there shouldn't be any need for rpmbuild.h to include rpmcli.h
either.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2807#issuecomment-1876732638
You are receiving this because you are subscribed to this thread.
> include/rpm/rpmcli.h:10:10: fatal error: 'popt.h' file not found
>
> Added to python/CMakeLists.txt:
> target_include_directories(_rpm PRIVATE ${POPT_INCLUDE_DIRS})
Actually popt needs to be a public include directory for rpm because of that
rpmcli.h include, I didn't realize/remember we had
@pmatilai commented on this pull request.
> @@ -0,0 +1,22 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ''
+labels: RFE
+assignees: ''
+
+---
+
+If your feature need figuring out how to implement it or needs feedback from
the wider comunity, please open a
@pmatilai commented on this pull request.
> +**To Reproduce**
+Steps to reproduce the behavior:
+1. Start condition e.g. installed packages
+2. Command (line) executed
+3. Error encountered
+
+Please link or attach the packages or spec files involved.
+
+**Expected behavior**
+A clear and
The height of embarrasment with this crash is that rpm has zero use for the
uid/gid info in this case, we could just skip the rpmug lookups entirely
because the uid/gid is never written to the archive, only the names are.
--
Reply to this email directly or view it on GitHub:
1001 - 1100 of 7944 matches
Mail list logo
