Eh, except that we create our scriptlets, including the one that creates the
builddir, in %_tmppath so we there's a tiny :egg: - :chicken: matter there. Oh
well, maybe later.
--
Reply to this email directly or view it on GitHub:
Yet another use-case: we can override build-time %_tmpdir to something inside
this build area, at which point a build is pretty thoroughly contained within
this one directory where it needs write-permissions.
--
Reply to this email directly or view it on GitHub:
@pmatilai commented on this pull request.
> @@ -42,6 +41,20 @@ static struct poptOption optionsTable[] = {
POPT_TABLEEND
};
+static ARGV_t gpgkeyargs(ARGV_const_t args) {
+ARGV_t gpgargs = argvNew();
+for (char * const * arg = args; *arg; arg++) {
+ if (strncmp(*arg,
@pmatilai commented on this pull request.
> @@ -42,6 +41,20 @@ static struct poptOption optionsTable[] = {
POPT_TABLEEND
};
+static ARGV_t gpgkeyargs(ARGV_const_t args) {
+ARGV_t gpgargs = argvNew();
argvNew() is wholly unnecessary here (it almost always is), just initialize to
Closed #2931.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2931#event-11931992514
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Gone in 217e217d92ec660f42ad8bfe979503d3ab556a54
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2931#issuecomment-1965941397
You are receiving this because you are subscribed to this thread.
Message ID:
Oh. Actually, that whole sentence is wrong/misleading, rpm2cpio requires a
functional librpm just as much as rpm2archive does. I'll just delete it, but
thanks for pointing this out!
--
Reply to this email directly or view it on GitHub:
No, because I had no idea. I don't particularly follow sqlite developments
because there aren't any active developments or plans in that direction. But
clearly we need to do something about it sooner or later then, filed
https://github.com/rpm-software-management/rpm/issues/2925 so it gets
### Discussed in https://github.com/rpm-software-management/rpm/discussions/2924
Originally posted by **vbrahmajosyula1** February 22, 2024
sqlite 3 deprecates pragma_case_sensitive_like from 3.44
https://www.sqlite.org/changes.html.
Following patch introduced case_sensitive_like in RPM.
Eliminating any ideas of shared build/buildroot content and associated
shenanigans (and consequent problems) is one of the *goals* of this PR.
Utopistic-ideally, a build would not have access to any content outside this
dedicated build directory.
--
Reply to this email directly or view it on
> Well, I stuck to the names that were in the code...
I know. My not-so-thoroughly thought up names from 10+ years ago, and a fine
example of why not to leave such half-assed pieces laying around in the
codebase :laughing:
> It also uses "--delete" while rpm itself uses "--erase". Not sure if
Heh, I didn't remember the workaround for 3.x, that's pretty funny. That
would've been added by a rather green me, probably in 2007 or so, thinking this
checking is a good thing. And then nobody thought to update the name when the
new payload format was added years later. It's annoying how much
@pmatilai commented on this pull request.
> headerDel(pkg->header, RPMTAG_PAYLOADDIGEST);
headerPutString(pkg->header, RPMTAG_PAYLOADDIGEST, pld);
headerDel(pkg->header, RPMTAG_PAYLOADDIGESTALT);
headerPutString(pkg->header, RPMTAG_PAYLOADDIGESTALT, upld);
pld =
Oh, RPMSIGTAG_FILESIGNATURELENGTH needs to be dropped because it's just broken.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8543365
You are receiving this because you are subscribed to this thread.
Closed #2811 as completed via 126b7ab7af60f79fe1912dec19c865f2ea74965a.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2811#event-11874943984
You are receiving this because you are subscribed to this thread.
Message ID:
I wont claim to have digested all that, but just a high level confirmation:
what I really would like to see is a coherent (re)design for reproducible
builds, where you basically just flick it on and be done with it, whereas the
existing flags reflect the organic growth process over the years
Closed #2833 as completed via b2638067fce9a32cba03f5c0198ea50a33ff6d3d.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2833#event-11874285931
You are receiving this because you are subscribed to this thread.
Message ID:
### Discussed in https://github.com/rpm-software-management/rpm/discussions/2872
Originally posted by **pmatilai** January 24, 2024
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
> With our build system, passing constants into a build is much easier than
> passing in a variable %_buildtime.
Sorry but I have no idea this means. What are these "constants" and how are
they being passed to a build?
(a %_buildtime macro could be set either via rpmbuild command line --define
@pmatilai commented on this pull request.
> case MODE_LISTKEY:
+ if (args != NULL) {
+ argerror(_("--list-keys does not take any arguments"));
+ }
+ ARGV_t query = argvSplitString("gpg-pubkey", " ", ARGV_NONE);
It's a bit creative way to initialize an argv... I
@pmatilai commented on this pull request.
> case MODE_LISTKEY:
+ if (args != NULL) {
+ argerror(_("--list-keys does not take any arguments"));
I think it should (take optional arguments), actually. It could be useful for
eg checking whether a particular key is imported,
Hum, forgotten to close this.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1240#issuecomment-1956106945
You are receiving this because you are subscribed to this thread.
Message ID: ___
Closed #1240 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1240#event-11872482217
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
I don't see this happening in 4.20, dropping from the milestone.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1956097606
You are receiving this because you are subscribed to this thread.
Message ID:
I think I initially wanted to add a sane API for these and then have rpmkeys
use that, and when that seemed painful I gave up. But the user wont care *how*
it's achieved if it works in a meaningful manner. And, for the user this is far
saner than 'rpmkeys --import -> rpm -q -> rpm --erase'.
@pmatilai commented on this pull request.
> @@ -75,7 +74,29 @@ int main(int argc, char *argv[])
break;
/* XXX TODO: actually implement these... */
Maybe delete this comment while at it? :smile: A fine example of why comments
are so bad - they don't get updated along with the
@pmatilai commented on this pull request.
> @@ -75,7 +74,29 @@ int main(int argc, char *argv[])
break;
/* XXX TODO: actually implement these... */
case MODE_DELKEY:
+ struct rpmInstallArguments_s * ia =
+ ARGV_t gpgargs = argvNew();
+ for (char * const * arg
Forward-looking defaults aside...
Do you agree with the idea that there should be a single macro to set the
buildtime source (clock/macro/source_date_epoch), and then have a separate flag
for clamping mtimes to buildtime, or am I again missing some finer detail here?
I've nothing against
(and fwiw, pulling that path change into 4.19.x makes no difference whatsoever
because the translations should NOT be updated in the branches, and hence
there's no reason to do so)
--
Reply to this email directly or view it on GitHub:
So with the submodule update done, this can be closed. Sorry @dmnks for
stealing your ticket :sweat_smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2899#issuecomment-1956028313
You are receiving this because you are subscribed
Closed #2899 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2899#event-11871913923
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Well yeah, *ideally* you'd have an official string freeze period with
translation notifications for major releases. And ideally you'd also have
per-release branches for translations because over time they grow different so
you can't safely pull updated translations to stable releases.
Why we
Because in rpm < 4.18, we have this silly check in there:
```
if (lead->major < 3 || lead->major > 4) {
*msg = xstrdup(_("unsupported RPM package version"));
return RPMRC_FAIL;
}
```
Putting 6 in the otherwise unused lead would render v6 packages unreadable by a
huge
Figuring out what to do with this is one of the next things on my plate.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8529580
You are receiving this because you are subscribed to this thread.
Message ID:
There's now also a draft PR that implements mosts of this draft, as far as
package generation goes:
https://github.com/rpm-software-management/rpm/pull/2920
--
Reply to this email directly or view it on GitHub:
@pmatilai pushed 2 commits.
30d352e1c188a68fdeb97fd1737d3eba891a19ee Don't populate os and arch in the
lead structure
01df85ccec5c00ebd46802a67fcc53f8274926a3 Bump the rpm version in the lead to 4
for v6 packages
--
View it on GitHub:
This should fairly closely reflect the latest v6 draft just published at
https://github.com/rpm-software-management/rpm/discussions/2919
The focus here is on the generation of v6 format packages, asserting various
aspects of the format is mostly a post 4.20 topic.
You can view, comment on, or
There's now what should be much closer to final (but isn't yet, certainly)
draft with clarified scope and compatibility info at
https://github.com/rpm-software-management/rpm/discussions/2919
Closing this topic as it has served its purpose and is getting too cluttered to
follow.
Thanks
Closed #2374 as resolved.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Based on the feedback on the [initial
draft](https://github.com/rpm-software-management/rpm/discussions/2374) and
work in the background, here's a major update to the v6 package format draft.
Starting a new topic as the original one is getting bogged down in details that
are no longer
Coming back to this: to avoid gratuitious compatibility breakage, we can't put
either 0 or 6 in there.
The best we can do is put 4 in there because all of rpm 4.x used 3 as the major
version for alleged LSB compatibility, so it at least differentiates it a bit.
It's not such a terrible lie even
@pmatilai commented on this pull request.
> @@ -21,6 +21,11 @@
#define ALLOWED_CHARS_EVR ALLOWED_CHARS_VERREL "-:"
#define LEN_AND_STR(_tag) (sizeof(_tag)-1), (_tag)
+enum parseStages {
+SPECFILE,
+BUILDSYS,
+GENERATED,
Use some unique prefix on the enum names, makes it easier
@pmatilai commented on this pull request.
> + if (stage == GENERATED) {
+ switch (tag) {
+ case RPMTAG_SOURCE:
+ case RPMTAG_PATCH:
+ case RPMTAG_NOSOURCE:
+ case RPMTAG_NOPATCH:
+
Just a random observation: Fedora is being used as the example here, but Fedora
does NOT preserve the updates history in the repository, only the first (in the
base repo) and the last are kept. So any of this basically requires maintaining
a local mirror which never deletes packages. And with
Merged #2916 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2916#event-11848850444
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Details in the commits, but basically add a new test group for package format
matters + a test for v4 package format utilizing rpmdump.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2916
-- Commit Summary --
* Split our
Merged #2915 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2915#event-11848573139
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Yeah this doesn't seem particularly relevant to rpm itself. But if people want
to use this as a depsolver agnostic place to discuss it, you're welcome to do
so.
--
Reply to this email directly or view it on GitHub:
We have the list of tests in cmake, we can just as well generate the master
rpmtests.at file from there.
As the order of tests now depends on the list in tests/CMakeLists.txt, update
it to match the former order in rpmtests.at. As arbitrary as that order is,
people seem to get attached to
@pmatilai requested changes on this pull request.
These are all optional dependencies and must remain that way, some of these
dependencies aren't available outside Linux at all. Without the corresponding
cmake options this is a no-go.
--
Reply to this email directly or view it on GitHub:
Merged #2913 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2913#event-11847031818
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
All your remarks should be covered now, just squashed the fixups in the last
push.
Oh and thanks for the review! I'm not friends with escapes so I conveniently
tend to forget all about them. My main motivation with this one was human
consumption more than computer, but of course if we claim
@pmatilai pushed 1 commit.
ce82dcaaa71f990054cb22b72553f6dac05ea433 fixup! Implement --json query format
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2913/files/479795192525cd1a282d279215deff7fb7f3e492..ce82dcaaa71f990054cb22b72553f6dac05ea433
You are receiving
@pmatilai pushed 1 commit.
479795192525cd1a282d279215deff7fb7f3e492 fixup! Implement --json query format
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2913/files/34667b308a14992e4fae15a5cc4ce803fddbaa78..479795192525cd1a282d279215deff7fb7f3e492
You are receiving
There you go, that hopefully covers it. Annoyingly this also easily doubles the
patch size, as these things always do.
Also all this string appending is of course all horribly inefficient, but that
can be improved later.
--
Reply to this email directly or view it on GitHub:
@pmatilai pushed 1 commit.
34667b308a14992e4fae15a5cc4ce803fddbaa78 fixup! Implement --json query format
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2913/files/cb102a6dd315c1d89da8f38b6fa83b83f4d1..34667b308a14992e4fae15a5cc4ce803fddbaa78
You are receiving
Oh, indeed. It's just the kind of dumb luck to miss such characters in the
test-material you try to reparse for validation :sweat_smile: The newlines in
base64Format() was trying to ring some bells but was too busy hacking the rest
of it up.
--
Reply to this email directly or view it on
The existing --xml output is extremely useful when inspecting oddities but the
format is such an eyesore. JSON is much saner to look at.
Details in the commits and their messages, but the first commits are just
refactoring to make this feasible. The actual feature in the last commit is
quite
@pmatilai commented on this pull request.
> if (rpmGlob(attrPath, NULL, ) == 0) {
- nattrs = argvCount(files);
- fc->atypes = xcalloc(nattrs + 1, sizeof(*fc->atypes));
- for (int i = 0; i < nattrs; i++) {
- char *bn = basename(files[i]);
-
Allow declaring file attributes from the spec via %_local_file_attrs macro.
This allows enabling file attributes and their dependency generators even if
they are only shipped in the package itself and are not yet installed.
The names need to be separated by colons (:).
Co-authored-by: Florian
%global expands it's the macro body at the time of definition rather than at
the time of use, so it cannot possibly work for the function-like parametric
macros.
I do agree it should raise an error, thanks for reporting.
--
Reply to this email directly or view it on GitHub:
> As a matter of fact, if I turn this on via:
>
> ```
> echo "Y" > /sys/module/overlay/parameters/redirect_dir
> ```
> the command succeeds
This is an interesting bit that I haven't seen before. That clue reveals what
is no doubt another wonderful rabbithole...
I don't know what rpmlint does, it's a separate project.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2875#issuecomment-1943732006
You are receiving this because you are subscribed to this thread.
Message ID:
That said, you can already make rpm ignore unpackaged files. Just flip
%_unpackaged_files_terminate_build to zero.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2907#discussioncomment-8464016
You are receiving this because you
That's a workflow problem really. Making rpm look the other way is not a
solution.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2907#discussioncomment-8463982
You are receiving this because you are subscribed to this thread.
Right. Well, that's exactly why the *packager* needs to decide where those
files belong.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2907#discussioncomment-8462949
You are receiving this because you are subscribed to this
Yeah, could be a rebase incident. It's dead code anyhow.
Not exactly a bug, but thanks for reporting.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2904#issuecomment-1943317701
You are receiving this because you are subscribed to
Closed #2904 as completed via 41974f46f90473e395731e22fb2f89c561971e33.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2904#event-11798578252
You are receiving this because you are subscribed to this thread.
Message ID:
No.
systemd is widely packaged already, I'd pick up an existing spec as a basis
instead of reinventing the wheel.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2907#discussioncomment-8462832
You are receiving this because you
Closed #2857 as completed via #2903.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2857#event-11798448522
You are receiving this because you are subscribed to this thread.
Message ID:
___
Merged #2903 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2903#event-11798448279
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
This isn't the only place where a misplaced %config can yield weird results
though. I think we should just strip the %config bit out from the file flags
entirely, in rpmfilesPopulate() probably. Kinda like we fixup missing rpmlib()
flags in rpmdsNewPool().
--
Reply to this email directly or
@pmatilai commented on this pull request.
> if (rpmGlob(attrPath, NULL, ) == 0) {
- nattrs = argvCount(files);
- fc->atypes = xcalloc(nattrs + 1, sizeof(*fc->atypes));
- for (int i = 0; i < nattrs; i++) {
- char *bn = basename(files[i]);
-
@pmatilai commented on this pull request.
> if (rpmGlob(attrPath, NULL, ) == 0) {
- nattrs = argvCount(files);
- fc->atypes = xcalloc(nattrs + 1, sizeof(*fc->atypes));
- for (int i = 0; i < nattrs; i++) {
- char *bn = basename(files[i]);
-
Mmm, but with current master the test would be running on Fedora because
there's no native test-suite for Ubuntu? Those matryoshkas as really out to get
us now.
--
Reply to this email directly or view it on GitHub:
@pmatilai pushed 1 commit.
3b787e5c375f830180c2e0bc8643cb80c23cc277 Let eBPF ELF files be packaged in
noarch packages
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2902/files/91f4d3fd56c41faa2f21db17f4bdff10cb01d746..3b787e5c375f830180c2e0bc8643cb80c23cc277
You are
eBPF ELF represents a virtual machine where our file colors make no sense at
all. Filter out the color from these files to avoid a Arch dependent
binaries in noarch package error from them in noarch packages.
We dont want to pull in clang to the check images just because of this, so
add a
Merged #2901 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2901#event-11784881206
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Ninja doesnt support passing environment as command line arguments like
make does, access TESTOPTS through environment instead of the make syntax to
make it work for both generators.
You can view, comment on, or merge this pull request online at:
Merged #2900 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2900#event-11784582614
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Merged #2898 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2898#event-11784579272
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Solved a bit differently by just dropping the bogus BYPRODUCTS directives:
#2900
Thanks for reporting, and the patch even if it didn't get used as-is!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2820#issuecomment-1940624460
You are
Closed #2820.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2820#event-11784571037
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
BYPRODUCTS is only relevant for Ninja generator which we officially dont
even support, but on which these usages cause Ninja to error out with
phony target names itself as an input messages.
I dont remember why exactly I put these BYPRODUCTS in there, but I know it
was NOT to support Ninja
You compile it the same as any autotools software: grab the release tarball
(not git branch), ./configure and so on. The rpm version being several years
older than the distro you'd be compiling it on could cause issues with library
and compiler compatibility and such. Any breakage you get to
There hasn't been much direct activity here recently, but doesn't mean no work
has been going on. I'm planning to produce an updated version of the draft in
the coming weeks, but the main point is going to be:
The overriding priority for V6 is the obsolence of V4 crypto. We need a
replacement
FWIW, this is now (briefly) documented in
https://rpm-software-management.github.io/rpm/manual/format_header.html#immutable-regions
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8439422
You are receiving
I only remember a couple of tickets where the issue was rpmbuild being
interactive, eg #978.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2898#issuecomment-1938331913
You are receiving this because you are subscribed to this thread.
Yup, there's a lot of related detail which deserves to be documented, but this
must not become a 1000 page packaging guide. My primary goal here is a TLDR
version of the higher level principles behind rpm operation, such as pristine
sources and unattended operation, that you can point the
> Was it ever possible, at any point in the history of RPM, for a RPM package
> to be created without a version or a release?
No. Absolutely not.
A package with empty or missing name, version, release, arch, os, license or
summary tags is simply invalid, and rpm could and should (but
Even max-rpm philosophy section points out that rpm builds are unattended, but
then we do nothing at all to prevent it? I first though maybe this regressed
when we switched the build scripts to use rpmfcExec() a few years ago, but
there wasnt anything before that either. Weird.
You can view,
Max-rpm has a section on
[philosophy](https://ftp.osuosl.org/pub/rpm/max-rpm/ch-rpm-philosophy.html) but
it's a source one doesn't really want to link to because it's *s* outdated
now. We should have a section explaining the fundamental design principles of
rpm in our reference manual,
In other words, this all would make a whole lot more sense to me if there was a
switch that decides where the buildtime gets set from
(clock/macro/source_date_epoch), and then the clamping options relate to
*buildtime* and not source_date_epoch. @ffesti mentioned elsewhere that maybe,
instead
We have `%_buildhost` macro which seems like it should be paired with
`%_buildtime` so adding that seems to make sense, but I guess the latter is
missing because you can set it with SOURCE_DATE_EPOCH if you care. I'd totally
fine with adding `%_buildtime` override if that means tossing the
Dropping from 4.20, as there's zero benefit to doing so just now. We're not
bumping the soname in 4.20 so we couldn't remove rpmGetArchInfo() /
rpmGetOsInfo() from the API and so we couldn't remove the associated number
data yet either. We've waited this long, we can wait a little more.
--
Closed #2755 as completed via 7f59c7dd2f4ff1476bec5c59f37babb1fd231e5a.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2755#event-11755075899
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #2883 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2883#event-11755075580
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
After mulling on it for a few days, I don't know what *else* we should do with
this really. And, it doesn't seem to be pulling a whole lot of attention
either. Let's just merge.
--
Reply to this email directly or view it on GitHub:
@pmatilai commented on this pull request.
> @@ -2413,6 +2414,7 @@ runroot rpm -q --provides -p
> /build/RPMS/noarch/bcondtest-1.0-1.noarch.rpm |
],
[])
+
Couple of unrelated empty lines getting added here and above, and also just
before and between the new tests. It's a good idea to
Closed #2886.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2886#event-11754968569
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
601 - 700 of 7772 matches
Mail list logo
