> This seems to defeat the point. The point of this is to clamp the times to
> the date stamp in the changelog. If you're doing automatic rebuilds, you
> should not use that feature, full stop.
:+1:
It looks like an attempt to eat and keep the cake, and we all know how well
that works.
>
Details in commits, but in short
- fix a bunch of leaks + other issues found by ASAN
- add ENABLE_ASAN build-option to cmake, and enable it on CI going forward
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2879
-- Commit
There are some pretty nasty bugs in 4.19.1 still, I think we should put out an
expedited bugfix release to address at least these regressions:
- https://github.com/rpm-software-management/rpm/pull/2843
- https://github.com/rpm-software-management/rpm/pull/2818
Other, less nasty stuff:
-
Can you point me to such a specimen?
Rpm doesn't know anything about EBPF, the warning/error is based on detecting
ELF files which up to now have been pretty arch-specific.
--
Reply to this email directly or view it on GitHub:
Yep, both rpm-sequoia and popt are something we'd occasionally want to build
from sources instead of packaged versions. So this is actually fairly important
piece, even if we have managed without it so far.
--
Reply to this email directly or view it on GitHub:
One thing just for the record, up to now elfdeps has been path agnostic by
design to match the dynamic linker: it doesn't matter where those libraries
come from as long as they're in the runtime path. Of course it's not an "end
user tool" but having consistent output regardless of the file
Actually, we'll need to have this path-discovery wrapped in some libc specific
helper script in rpm because this eg musl has an entirely different library
search path mechnism. That's fine though, for glibc we could implement our own
ld.so.conf parser for the immediate use and then once the
Yeah elfdeps basically ignores all path-aspects, it only really handles
DT_NEEDED and DT_SONAME.
One thing here though: a manually added require/provide is not equal to one
discovered by rpm, the latter are tracked on file-level and rpm actually uses
this information. That's why I'm so
> If there was some macro with package name, I think I could simplify this:
>
> %{gem_extdir_mri}
> %dir %{gem_instdir}
> %{gem_libdir}
> %{gem_spec -d}
If you declared these macros in terms including some %{name} then ... you'd
have X number of such identical %files sections, now just even
Note that I'm specifically avoiding talking about filtering these dependencies
out because I think in many cases its more useful to turn them into something
else instead.
--
Reply to this email directly or view it on GitHub:
Yes, that possible ld.so.conf fragment in the buildroot needs to be covered.
But, I think the hosts ld.so.conf[.d] needs to be processed as well. The
currently building package could be installing to a subdirectory that some
other package (which would have to be a build-dependency) has declared
No no. What I'm telling you is to script the file section generation. Something
like
```
for n in psych mental; do
cat << EOF > ${n}.txt
%{ruby_libdir}/${n}
%{ruby_libdir}/${n}.rb
%{ruby_libarchdir}/${n}.so
#...
EOF
done
```
...and include from %files with -f. Or make that a spec local macro
If you have lots of those with nothing but the name changing, no macros will
help with that. Generate those files manifests programmatically from %install
and include with %files -f.
--
Reply to this email directly or view it on GitHub:
:monocle_face: seems most appropriate here...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2874#issuecomment-1910081323
You are receiving this because you are subscribed to this thread.
Message ID:
So this is actually another bug fixed by
a0553eb38a01772254cd48fef7ad116294cf801a
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2874#issuecomment-1910075031
You are receiving this because you are subscribed to this thread.
Message
Looking at `cpio -t` output is proving more helpful :smile:
This from the Ubuntu-created file:
> [pmatilai︎localhost tmp]$ cpio -tv < out |head -4
6 blocks
drwx-- 1 root root0 Jun 28 2011 ./a/dir
-r 1 root root 15 Jun 28 2011 ./a/file
drwx--
Okay, the headers are otherwise identical so it's the payload that has to
differ then, and that payloaddigest changing throws everything else off too.
And indeed, extracting the rpm2cpio output shows some differences (from `diff
-u -a` output), eg:
```
The above *almost* works. It's just that the ld.so.conf from Fedora causes an
"ldconfig: need absolute file name for configuration file when using -r" error
from ldconfig. Had me scratching hair for a bit because I thought it ws
complaining about the path I was passing in -f which *was*
4.18.2 would be missing at least this: 7ec148c1d61e0b526ae5c917f0ddc2b4a3222146
which could affect it.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2874#issuecomment-1909841982
You are receiving this because you are subscribed to
I remember a case or two where the checksums mismatch due to different libmagic
versions producing different strings. I also remember tweaking the test to
avoid relying on libmagic stuff there, but don't remember when exactly. But
yes, it's fragile. Very.
--
Reply to this email directly or
If guessing and trying fails, 'runroot rpm -qp --xml
/build/RPMS/noarch/attrtest-1.0-1.noarch.rpm' is your friend, one can then diff
the output of that between working and non-working files. We should probably
dump that output anyway to make it more debuggable.
--
Reply to this email directly
Yes, a clean way to discover the system library paths searched by the dynamic
loader would go a long way.
Hmm. I guess this is kinda doable by running `ldconfig -r ` followed
by `ldconfig -r -p` from which you can pull the directories (so
effectively the path) or the files themselves. Just do
FWIW, I think we should follow the [Python
lead](https://github.com/rpm-software-management/python-rpm-packaging) and call
it perl-rpm-packaging to allow for all sorts of helper material to live there
and not just macros/scripts and the like. A bit of consistency is a nice bonus.
--
Reply to
@pmatilai commented on this pull request.
> @@ -78,16 +84,81 @@ static char *doUncompress(const char *fn)
return cmd;
}
+/**
+ * Detect if an archive has a single top level entry, and it's a directory.
+ *
+ * @param path path of the archive
+ * @return 1 if archive as only a
Static checking in RHEL discovered exactly one place where we still had time_t
conversion to signed integers: getBuildTime(). Fixed that in
https://github.com/rpm-software-management/rpm/commit/97aa64d8281974fb369c66d5aef8650515b89c52,
I think we can consider this done now.
--
Reply to this
Closed #1228 as completed via 97aa64d8281974fb369c66d5aef8650515b89c52.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1228#event-11582158266
You are receiving this because you are subscribed to this thread.
Message ID:
This is one of those topics that gets raised semi-annually at least. To point
out a couple, https://bugzilla.redhat.com/show_bug.cgi?id=2259260 and
https://bugzilla.redhat.com/show_bug.cgi?id=1464368 and
https://github.com/rpm-software-management/rpm/issues/1227 but there are
certainly more
Thanks for the patch!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2856#issuecomment-1905777264
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint
Merged #2856 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2856#event-11568363991
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
I'm not actually finished with this, but I do have a local backup anyway,
closing is okay.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2835#issuecomment-1905561075
You are receiving this because you are subscribed to this thread.
@pmatilai commented on this pull request.
> @@ -532,7 +532,7 @@ static int filerequireTag(Header h, rpmtd td,
> headerGetFlags hgflags)
/* I18N look aside diversions */
-#if defined(ENABLE_NLS)
+#if defined(ENABLE_NLS) && (defined(__GLIBC__) || !defined(__linux__))
AFAICS this isn't
I'm glad this ended up on your plate, I never found the patience to sort this
out :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2871#issuecomment-1905533378
You are receiving this because you are subscribed to this thread.
Merged #2871 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2871#event-11566516191
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
I find `packaged` quite misleading, because the case is to allow for attributes
and generators that are local to the *build*. Those attributes *may also* be
packaged, but that's not relevant for this feature. I see two separate main
cases for this:
- build a package with the generator it ships
@pmatilai converted this issue into discussion #2870.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2863#event-11556184345
You are receiving this because you are subscribed to this thread.
Message ID:
@pmatilai converted this issue into discussion #2869.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1595#event-11556131967
You are receiving this because you are subscribed to this thread.
Message ID:
Actually, there is a kind of a way to access the values from Lua even now.
%-f* macro has the last definition of the macro. If you pop (ie undefine) it,
you get the one underneath. And with that, you can walk all the values. It wont
work on normal macros as "%undefine -f*" is not permitted, but
Just realized %{-f} and %{-f*} explictly documented as being the last
occurence. So yep, we can't change that.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2449#issuecomment-1903868651
You are receiving this because you are subscribed
I know its that way historically, just doubtful of people actually relying on
multivalues being handled that way. But then, I wouldn't know.
Yet another possibility could be letting macros declare the way they want their
arguments, ie "I can handle multiple values, bring em on", just like we
@pmatilai commented on this pull request.
> + int r, ret, rootLen;
+ char *rootName;
+
+ a = archive_read_new();
+ archive_read_support_filter_all(a);
+ archive_read_support_format_all(a);
+ r = archive_read_open_filename(a, path, 10240);
+ if (r !=
@pmatilai commented on this pull request.
> @@ -78,16 +84,81 @@ static char *doUncompress(const char *fn)
return cmd;
}
+/**
+ * Detect if an archive has a single top level entry, and it's a directory.
+ *
+ * @param path path of the archive
+ * @return 1 if archive as only a
@pmatilai commented on this pull request.
> @@ -78,16 +84,81 @@ static char *doUncompress(const char *fn)
return cmd;
}
+/**
+ * Detect if an archive has a single top level entry, and it's a directory.
+ *
+ * @param path path of the archive
+ * @return 1 if archive as only a
Like I said before, I'm not convinced this is the way we want to represent the
multivalue case.
Assuming we can technically do this now, is there a reason not to put those
values into the normal -x* macro? It seems to me we can't really break any
significant existing users as we just haven't
Closed #2109 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2109#event-11555365840
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
What's considered rpm-level C code no longer knows about such packet level
details, backends will need to deal with RFC compliancy on their own.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2109#issuecomment-1903798717
You are
Closed #2826 as completed via #2843.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2826#event-11555214340
You are receiving this because you are subscribed to this thread.
Message ID:
___
Merged #2843 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2843#event-11555214102
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
> It seems like the commit hash mentioned in the commit message isn't correct
> (it's the "Bump CI" commit which doesn't seem to have anything to do with
> this).
It's actually explained in the message:
> rpmugUname() and rpmugGname() are have no users in the current codebase,
> so this was
Yep. The gaps in our documentation are so enormous they're difficult to see.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2867#issuecomment-1903746094
You are receiving this because you are subscribed to this thread.
Message ID:
As a closing note, catching up 20 years of documentation neglet doesn't happen
in a single PR. I've no illusions about this being complete or error-free, just
that it's a basis on which more can be built.
--
Reply to this email directly or view it on GitHub:
Closed #2462 as completed via 1b32d3c87f41a5f821e066e17918adb782068b45.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2462#event-11554951324
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #2861 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2861#event-11554950922
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Closed #1481 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1481#event-11554939051
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
The region tag and the trailer are now documented in #2861.
I'm not going to document common sense like no data can overlap. This is also
not a wishlist, refining further limitations belongs to v6.
--
Reply to this email directly or view it on GitHub:
@pmatilai pushed 6 commits.
2e2fe7350f8e6e2f2693a70225aabb9b46afebf2 Use markdown formatting features for
package format, fix links
ae0d06db4e7db78c069cfb912bdefc362da025bf Split the lead and header structure
to their own documents
4719e49d4e33e9e3bcad0e159ae88cb0b606d83e Fix some
@pmatilai commented on this pull request.
> @@ -17,6 +17,7 @@ target_link_libraries(rpmlua PRIVATE LUA::LUA)
target_link_libraries(rpmbuild PRIVATE librpmbuild)
target_link_libraries(rpmspec PRIVATE librpmbuild)
target_link_libraries(rpmdeps PRIVATE librpmbuild)
Another fine idea by @dralley: in the 25+ years of rpm format, the packages in
the wild have any number of various quirks (bugs, design mistakes, forks and
whatnot) that rpm and other software may need to deal with. I can recall at
least half a dozen off-hand but that info should instead be
The IMA signatures and their journey from there to here are a tragic mess, just
opened up a new ticket to remind me: #2865
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2462#issuecomment-1903493987
You are receiving this because you
The IMA file signature tags are a mess: they were originally added to the main
header so the tags were defined in the > 5000 range. They were moved to the
signature header where they belong in later releases, and new tags in the
signature range (256-999) were reserved for the use there. These
@pmatilai commented on this pull request.
> +## Lead Format
+
+The Lead is stored as a C structure:
+
+```
+struct rpmlead {
+unsigned char magic[4];
+unsigned char major, minor;
+short type;
+short archnum;
+char name[66];
+short osnum;
+short signature_type;
+
@pmatilai commented on this pull request.
> +0048: 00 00 00 00 00 01 00 05
+```
+
+Bytes 76-77 ("00 01" above) form an int16 that indicates the OS the
+package was built for. In this case, 1 == Linux. The next 2 bytes
+(78-79) form an int16 that indicates the signature type.
@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
1001 - 1100 of 8005 matches
Mail list logo
