Based on a quick look, the changes did what I asked for so it's all good. If
you want to add extra tests later, that's of course okay.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2944#issuecomment-2039346604
You are receiving this
Ack, s*** happens. No worries.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2944#issuecomment-2039332804
You are receiving this because you are subscribed to this thread.
Message ID: ___
@pmatilai pushed 9 commits.
e6f9853c2112c8e7258623ed901a3e6b0804e4ef Introduce and use RPMRICHOP_NONE to
fix int/enum mismatches
0a60357815b5bf0b49b245e4418a8e601804eacd Add c++ guards to internal headers
and sources as needed
290155872a509d017ae55f01255ecab36c78445b Avoid relying on
Another batch of delightful trivia to appease c++.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/3019
-- Commit Summary --
* Eliminate anonymous embedded struct use in filelist
* Drop a redundant helper variable
*
It's not a bad idea. Gzip is getting a bit long in the tooth, and I guess all
distros moved to something better 10-15 years ago.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-9017177
You are receiving this
Uh? This would be just an extra option, not replace any existing functionality.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1939#issuecomment-2038983260
You are receiving this because you are subscribed to this thread.
Message ID:
The tag conflicts between signature and header are gone as of #3017, what
remains is to error out if tags >= 1000 are found in v6 signature header.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1570#issuecomment-2036760091
You are
Obsolete crypto tags are gone from v6 packages in #3017 , what remains to be
done is disabling validation on those by default.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1292#issuecomment-2036758478
You are receiving this because
Closed #864 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/864#event-12355475047
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Done in #3017
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/864#issuecomment-2036747341
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing
Done in #3017
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2368#issuecomment-2036746689
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing
Closed #2368 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2368#event-12355469187
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Merged #3017 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3017#event-12355437943
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Here we go. Details in commits, and this is obviously nowhere near complete,
the v6 work will be on-going throughout the year.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/3017
-- Commit Summary --
* Start a v6 format
Closed #2988.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2988#event-12355359872
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Merged #3016 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3016#event-12354439990
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Let the floodgates open!
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/3016
-- Commit Summary --
* Bump version to 5.99.90 to begin a new devel cycle
-- File Changes --
M CMakeLists.txt (2)
M
Not so fast it seems, I just got this:
```
+++ /srv/rpmtests.dir/at-groups/353/stderr 2024-04-04 08:40:58.419002150
+
@@ -1,2 +1,2 @@
-error: Illegal char '*' (0x2a) in: *
+error: failed to write all data to /tmp/bad.req: Broken pipe
```
But at least it's now hinting at the problem.
Reopened #2470.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2470#event-12354300211
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing
Closed #2519 as completed via #3006.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2519#event-12352647496
You are receiving this because you are subscribed to this thread.
Message ID:
___
Merged #3006 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3006#event-12352647299
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
If this breaks something, we're not going to find it by studying this on a
petri-dish.
I'll merge and if all hell breaks loose in testing, we'll just revert the damn
thing.
--
Reply to this email directly or view it on GitHub:
Closed #1346 as completed via #3004.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1346#event-12352564431
You are receiving this because you are subscribed to this thread.
Message ID:
___
Merged #3004 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3004#event-12352564263
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Closed #2816 as completed via ad0eb9a461bce444271d9cf18748e8de821a8960.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2816#event-12352560560
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #2990 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2990#event-12352560333
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
> I believe this is not true. I see no code in rpmbuild that would elevate UID
> to root. Nor any consolehelper. Nor setuid bits.
In the container.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3005#issuecomment-2036268291
You are
Having a separate short-circuit for check is fine, but it's NOT the same
benefit! I get that you look at the world through mock lenses, but not
everybody does :smile:
--
Reply to this email directly or view it on GitHub:
@pmatilai approved this pull request.
Other than the dependencies doc nit, looks fine to me now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2990#pullrequestreview-1978812025
You are receiving this because you are subscribed to
@pmatilai commented on this pull request.
> @@ -25,6 +25,9 @@ user/group allocation altogether by using
## Dependencies
+Explict group membership (m) will create a dependency on both the user
+and the group name.
It's a bit weird to have this as the first thing in this section. I'd put it
Maybe not the greatest example but at least something:
https://github.com/rpm-software-management/rpm/commit/5d4a476d14998f8f7ebc7e0c15a5263ca7803f5d
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2998#issuecomment-2034434069
You are
Doubly more embarrassing as you mentioned that in the ticket description
:laughing:
Will fix.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2998#issuecomment-2034411616
You are receiving this because you are subscribed to this
Oh, thanks for pointing that out! I didn't even remember we have that in the
documentation (although it was written by me, so ... age doesn't come alone as
they say around here)
--
Reply to this email directly or view it on GitHub:
After a bit of pondering, filed
https://github.com/rpm-software-management/rpm/issues/3014 instead, we'll
revisit the aliases with this is fixed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3008#discussioncomment-8995444
You
I know the split is somewhat painful this way, but it was the least painful (or
only) way I could see to accomplish this within reasonable time/effort.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2984#issuecomment-2034208979
You are
Oh, I guess I wasn't clear: sure rpm-sequoia supports and exports all the
digest functionality rpm needs. What I mean is that it does NOT support using
libgcrypt/openssl from rpm side to do that.
libgcrypt/openssl digest support in rpm is only for the case where rpm-sequoia
is not available.
The sole reason for this exercise is to be able to build rpm *without*
rpm-sequoia.
rpm-sequoia doesn't support external digest, and wouldn't make much sense for
it to do so.
--
Reply to this email directly or view it on GitHub:
Closed #2998 as completed via #3002.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2998#event-12337492251
You are receiving this because you are subscribed to this thread.
Message ID:
___
Merged #3002 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3002#event-12337492048
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Oh and update (some of) the tests to use the new macros, optimally add a new
one for the clamp_to_buildtime behavior.
The above nits aside, I'm not going to say no to a reproducible builds patch
that appears to have consensus from everybody :sweat_smile:
--
Reply to this email directly or
After a few nights sleep - sorry but no. It'd be this strange macro you can
never use because something else might be relying on it. Just like you
shouldn't be overriding %_fixperms for your use because it breaks other things.
The idea of a pre/post action slots for macros and whatnot is not a
Closed #2961.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2961#event-12336249093
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
@pmatilai commented on this pull request.
> @@ -240,10 +240,12 @@ Supplements: (%{name} = %{version}-%{release} and
> langpacks-%{1})\
# Is ignored when SOURCE_DATE_EPOCH is not set.
%use_source_date_epoch_as_buildtime 0
-# If true, make sure that timestamps in built rpms
-#
@pmatilai commented on this pull request.
>
-/* Limit the maximum date to SOURCE_DATE_EPOCH if defined
- * similar to the tar --clamp-mtime option
- * https://reproducible-builds.org/specs/source-date-epoch/
- */
-if (srcdate &&
Coming to the conclusion that it's just not worth the trouble right now. I'll
revive this once we've fixed the order (filed a ticket for that)
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3011#issuecomment-2033714434
You are receiving
Closed #3011.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3011#event-12336023902
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
And, once we do, revive https://github.com/rpm-software-management/rpm/pull/3011
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3014#issuecomment-2033713203
You are receiving this because you are subscribed to this thread.
Message ID:
Sources and patches are stored in a singly linked list with front insertion in
the spec parser, and this implementation detail leaks into packages and rpmspec
queries: PATCH and SOURCE tags are in reverse order.
Technically changing the order *could* break somebody's carefully crafted
script
The thought crossed my mind too, I'm a bit torn on this all.
Sure, reverting the order in the aliases would be safe. But, it seems like a
bug that we're storing them in reverse order in the package in the first place,
and something we should fix instead. But, that'd break it for the alleged
Apologies for this not progressing anywhere, but the time in between has
confirmed that something like this will need a general purpose use-case in rpm
itself so that it can be regularly tested.
We'll be exploring this area in the future, but this isn't the time, we need to
focus on v6. I'm
Closed #2416.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2416#event-12335589169
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Apologies for this not progressing anywhere, but the time in between has
confirmed that something like this will need a general purpose use-case in rpm
itself so that it can be regularly tested.
We'll be exploring this area in the future, but this isn't the time, we need to
focus on v6. I'm
Closed #2557.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2557#event-12335587655
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
I thought I made it pretty damn clear in
https://github.com/rpm-software-management/rpm/pull/2378#issuecomment-1411912184:
this is not functionality that we want to see or maintain in rpm. Period.
Copy-on-write is an interesting technology in itself and we'll be exploring
that in the future,
Closed #3007.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3007#event-12335494693
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
That mock does something is not a reason to not improve rpmbuild security and
package/packaging sanity enforcement. A test-suite modifying what gets packaged
is simply *horribly wrong*, even if it's by accident. If we can catch that,
then we should. That's a no-brainer to me.
--
Reply to this
Merged #3013 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3013#event-12326180710
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Right, I remember coming across this and thinking about removing and then
postponing for whatever reason, and here we are. The positive thing is that
while it's in the API, it's not in the ABI, so we can remove without soname
bumps. Indeed nobody should be using it, and by the looks of things
@pmatilai pushed 1 commit.
f824484589b8260a59dab0265fe41901c399a4c6 Ensure binary pkg headers are
identified as such after a spec parse
--
View it on GitHub:
@pmatilai pushed 2 commits.
2831368e2b7858047e9668ef126034faf6215dce Ensure source headers are identified
as such after a spec parse
e5184ba0ad9149e72c2f076f618053157927c4b9 Ensure binary pkg headers are
identified as such after a spec parse
--
View it on GitHub:
Added a second commit there to deal with RPMTAG_SOURCERPM too:
https://github.com/rpm-software-management/rpm/pull/3012/commits/cb47d1e144cb0e83c715086423785c03f0ec51c4
--
Reply to this email directly or view it on GitHub:
@pmatilai pushed 1 commit.
cb47d1e144cb0e83c715086423785c03f0ec51c4 Populate RPMTAG_SOURCERPM early to
allow binaries to be identified
--
View it on GitHub:
Aaargh, except that the issue here was not positively identifying source
headers but binaries :facepalm:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2995#issuecomment-2031869298
You are receiving this because you are subscribed to
Nice to see somebody besides ourselves being excited about this :smile:
And yeah that is really a big part of the point: rpm's data structures aren't
really that exotic, but to someone new it's all lost in the details of this
specific implementation, and then we have like three different
BTW it's worth noting that both the patches and sources appear in a reverse
order to how they're introduced in the spec. This is basically an internal
implementation detail (linked list operation) leaking into the packages, but
because it's always been that way, "fixing" would silently break
@pmatilai pushed 1 commit.
11599c994b870444ac3cbffb61a8256152f9f27a fixup! Ensure source headers are
identified as such after a spec parse
--
View it on GitHub:
Heh, so a more careful reading of the report... the userid is *intentionally*
removed here.
So assuming that's a reasonable thing to do (considering where these keys are
coming from), the minimal fix would probably be this instead:
```
- digps[count]->userid =
Oh and, thanks @signed-log for reporting!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3001#issuecomment-2031692954
You are receiving this because you are subscribed to this thread.
Message ID:
Right, this is specific to the internal pgp parser. With rpm-sequoia I get:
> $ tools/rpmkeys --dbpath /tmp/kdb --import
> /tmp/2596A99EAAB33821893C0A79458CA832957F5868
error: Certificate 458CA832957F5868:
Policy rejects 458CA832957F5868: No binding signature at time
2024-04-02T10:42:20Z
Here's a simple and straightforward way source headers are always indentified
as such right after parse:
https://github.com/rpm-software-management/rpm/pull/3012
--
Reply to this email directly or view it on GitHub:
headerIsSource() uses RPMTAG_SOURCERPM presence to identify binary packages,
but that tag gets inserted late in an actual package build, whereas wed
like to source headers to be identifiable right after spec parse already.
Non-presence of a tag is not a very strong indicator anyhow, and even
Took a quick look at my own suggestion in the earlier comment and it brings out
some truly WTF failures :laughing:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2995#issuecomment-2031615530
You are receiving this because you are
The build code is a mess for sure, but adding hacks on top of hacks only makes
it worse.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2995#issuecomment-2031613554
You are receiving this because you are subscribed to this thread.
@pmatilai commented on this pull request.
> +[0],
+[hello-1.0-1
+],
+[])
+RPMTEST_CLEANUP
+
+AT_SETUP([rpmspec -q --srpm])
+AT_KEYWORDS([query])
+RPMTEST_CHECK([
+RPMDB_INIT
+runroot rpmspec --srpm \
+ -q /data/SPECS/hello.spec
+],
+[0],
+[hello-1.0-1.src
+],
I'd put this in the same
@pmatilai commented on this pull request.
> @@ -180,6 +180,34 @@ runroot rpmspec \
[])
RPMTEST_CLEANUP
+AT_SETUP([rpmspec -q --rpms])
+AT_KEYWORDS([query])
+RPMTEST_CHECK([
+RPMDB_INIT
+runroot rpmspec --rpms \
+ -q /data/SPECS/hello.spec | grep src
+runroot rpmspec --rpms \
+ -q
I opened this ticket from the discussion specifically because it's such a
no-brainer when you see it: "tests should not be able to affect built
binaries". How feasible it is in practise is another story, but it's worth at
least investigating.
--
Reply to this email directly or view it on
The query is not exactly obvious though, so:
https://github.com/rpm-software-management/rpm/pull/3011
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3008#discussioncomment-8980798
You are receiving this because you are subscribed
These are common needs and the query is not exactly obvious, so why not.
Hijack the otherwise unused poltest.spec for the sources test, its the
only multi-source spec we have. Only, it hasnt been parseable in about ten
years because of the Collections: tag, so remove that...
You can view,
> I'd like to be able to query a spec file for the list of its patches.
`rpmspec --srpm -q --qf "[%{PATCH}\n]" `
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3008#discussioncomment-8980564
You are receiving this because you
Opened https://github.com/rpm-software-management/rpm/issues/3010 as well.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3009#discussioncomment-8980509
You are receiving this because you are subscribed to this thread.
Message
On the heels of the xz incident, one of the ideas (from @keszybz it seems) to
harden against malicious tests is to make buildroot readonly during %check.
Picked from https://github.com/rpm-software-management/rpm/discussions/3009 as
a clear actionable item.
--
Reply to this email directly or
We've been entertaining ideas to this direction before the xz incident, eg
#2985 (for read-only source) and #2989. Read-only buildroot would be a logical
extension of this. Some of these things are stepping into "mock territory", but
then people still *do* run rpmbuild through other means as
Merged #2993 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2993#event-12280849094
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Looks fine to me, thanks for the patch!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2993#issuecomment-2025086199
You are receiving this because you are subscribed to this thread.
Message ID:
I certainly remember seeing that code, but never quite got what it actually
refers to. I doubt anybody knows of it, really.
It'd be a lot more useful if it permitted multiline macros. People seem to be
widely abusing %{expand:...} (probably without fully realizing the
consequences) to get the
FWIW, I revived my rpm-snapshot repository where you can get Fedora compatible
builds from rpm git:
https://copr.fedorainfracloud.org/coprs/pmatilai/rpm-snapshot/ so if folks want
to try this out before the soon-to-be-released 4.20 alpha, there goes.
--
Reply to this email directly or view it
Details in the commit messages, but in short: packages can leave unremovable
files in their build directory, run %_fixperms before and after to ensure
sufficient permissions to remove %builddir.
%clean is redundant since 9d35c8df497534e1fbd806a4dc78802bcf35d7cb, drop
default %clean sections
Sounds like a plan :+1:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3005#issuecomment-2024754579
You are receiving this because you are subscribed to this thread.
Message ID: ___
While investigating #2519 I realized that we're running the entire test-suite
as root. That's not how rpmbuild is intended to be used, and masks various
permission issues real-world users have, such as that #2519 which is not
reproducable in the test-suite because of this.
Adding a user to the
Taking weak dependencies into account during ordering has caused a noticeable
wave of dependency loop caused install failure bug reports at least in Fedora.
This is counter-productive: weak dependencies are commonly used to introduce
more exotic / heavier dependencies to packages without
Merged #3003 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3003#event-12268442379
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Doxygen is absolutely not required for building rpm, its only required for
building dist tarballs which come with the documentation pre-built.
Fixes: 26a1ccf2819ab148aef3cd354e1cbdb70a9fe5b7
You can view, comment on, or merge this pull request online at:
@pmatilai commented on this pull request.
> @@ -240,10 +240,12 @@ Supplements: (%{name} = %{version}-%{release} and
> langpacks-%{1})\
# Is ignored when SOURCE_DATE_EPOCH is not set.
%use_source_date_epoch_as_buildtime 0
-# If true, make sure that timestamps in built rpms
-#
The new %(auto)setup -C option complements the declarative buildsystem very
nicely: this is a trivial detail, dont bother the packager. While we
cant default to it everywhere, Buildsystem is a great opportunity to do so.
Suggested-by: Miro Hrončok m...@hroncok.cz
Fixes: #2998
You can view,
@pmatilai commented on this pull request.
> @@ -246,8 +246,8 @@ static int expandMacrosInSpecBuf(rpmSpec spec, int strip)
if ((condition) && (!condition->withArgs)) {
const char *s = lbuf + condition->textLen;
SKIPSPACE(s);
- if (s[0])
-
Closed #829 as completed via #2996.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/829#event-12265396820
You are receiving this because you are subscribed to this thread.
Message ID:
___
Merged #2996 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2996#event-12265396584
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
@pmatilai commented on this pull request.
> @@ -246,8 +246,8 @@ static int expandMacrosInSpecBuf(rpmSpec spec, int strip)
if ((condition) && (!condition->withArgs)) {
const char *s = lbuf + condition->textLen;
SKIPSPACE(s);
- if (s[0])
-
A bigger problem is that this doesn't actually work. As in, add the users into
the groups on install. The "receiving" code does not know to look for these
new provides so they end up being just decoration.
What you don't test does not work, is a good rule of thumb :smile:
--
Reply to this
Merged #3000 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3000#event-12263647886
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
101 - 200 of 7640 matches
Mail list logo
