@dmnks pushed 2 commits.
838c9c6dbdc974563e4f8d7301638991ed247950 GPG: Switch back to pipe(7) for
signing
927790f8808488626993f33c88d97ca1755d4c3d GPG: refactor: exit label
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software
@dmnks pushed 2 commits.
88d650776bfc93bf4fd863a7081aeb889bd04bf1 GPG: Switch back to pipe(7) for
signing
a58d462040774da53f91d8388b3bdd0b86916c25 GPG: refactor: exit label
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software
@pmatilai I've taken a different approach (by re-introducing the pipe), details
in the commit message. Please review when you get a chance. Thanks!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-softw
@dmnks pushed 2 commits.
9d638d25afc3f211671ce93192cf99af8a679948 GPG: Switch back to pipe(7) for
signing
c471ad104992c950e42afd12079c67c43642841e GPG: refactor: clean up exit label
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm
@dmnks pushed 2 commits.
7080e2456d513d54538129a4d414848591b49508 GPG: Switch back to pipe(7) for
signing
5e81da9a19f576ad35d6358ed3d29787f8a708cc GPG: refactor: clean up exit label
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm
@dmnks commented on this pull request.
>
if (gpg_path && *gpg_path != '\0')
(void) setenv("GNUPGHOME", gpg_path, 1);
+ if (tty)
+ setenv("GPG_TTY", tty, 0);
+ else if (!getenv("GPG_TTY"))
+ rpmlog(RPMLOG_WARNING, _("Could not set GPG_TTY to
@dmnks pushed 2 commits.
5b3831f7d5d76bfefcd2a28a5aabddc39866da19 GPG: Switch back to pipe(7) for
signing
e91e2ad55e18131aea621f3c2e6772bc891d1aa4 GPG: refactor: clean up exit label
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm
Rebased and fixed the `%m` thing. Apologies for the long "round-trip delay
time" on this PR.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/938#issuecomment-648253508_
Oh my. Thanks for sharing, I'll check that.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1290#issuecomment-648804803___
Rpm-
Closed #963.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/963#event-3520109680___
Rpm-maint mailing list
Rpm-maint@lists.rpm
As discussed with @ffesti on IRC today, we'd rather keep this behavior as is,
although a point can be made both ways, i.e. in favor of the exit code 11 with
`--nodeps` (to signal *unchecked* dynamic deps) as well as in favor of a
different exit code (since deps weren't checked per user's request
Reopened #963.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/963#event-3520900913___
Rpm-maint mailing list
Rpm-maint@lists.r
Well, that's a good point. Reopening and rewording the title to implement a man
page update. Thank you, Pavel!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/963#issueco
Actually looking closely at the `rpmbuild(8)` man page, it seems we don't
specify any exit codes there at the moment. So I'm wondering if it really is
worth documenting them for this particular use case (`-br --nodeps`) only.
There could be a separate section called `EXIT CODES` or similar where
Had a quick chat on IRC with @ffesti and he said it's actually just three
outcomes that rpmbuild may return; success (0), error (1) or missing build deps
(11), in which case adding all three into the man page would be worthwhile.
I'll skim through the code to double-check and go ahead with that.
Possibly related: https://github.com/rpm-software-management/rpm/issues/1304
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/963#issuecomment-658035631
This issue stems from the fact that the line continuation marker `\` has
*different* semantics in the spec-level context and in a macro definition. On
the spec level, it is used to break long `%if` statements into multiple lines.
Inside macro definitions, it's the whole body that's broken down.
> > no matter if all build requires are installed
>
> because rpmbuild does not check them because `--nodeps` is specified :) So
> for rpmbuild none are installed.
Which does not necessarily mean that they are *missing*. But yeah, we still
return 11, to "signal" that the deps weren't checked an
LGTM, thanks!
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1313#issuecomment-661722877___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://li
Merged #1313 into master.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1313#event-3570031458___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
htt
Also, if we decide to go with the messages in the end, we should end them with
a `\n`.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1305#issuecomment-661791406__
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1318
-- Commit Summary --
* Docs: Revamp BUILD OPTIONS section in rpmbuild(8)
* Docs: Add note on buildreqs.nosrc.rpm and code 11
-- File Changes --
M doc/rpmbuild.8 (
@dmnks commented on this pull request.
> @@ -256,6 +266,18 @@ options are currently set in
\fIrpmrc\fR and
\fImacros\fR
configuration file(s).
+.SS "DYNAMIC BUILD REQUIREMENTS"
+.PP
+When the %generate_buildrequires stage is executed and some of the resulting
+requirements are not satisfied,
@dmnks commented on this pull request.
> @@ -256,6 +266,18 @@ options are currently set in
\fIrpmrc\fR and
\fImacros\fR
configuration file(s).
+.SS "DYNAMIC BUILD REQUIREMENTS"
+.PP
+When the %generate_buildrequires stage is executed and some of the resulting
+requirements are not satisfied,
@dmnks commented on this pull request.
> @@ -256,6 +266,18 @@ options are currently set in
\fIrpmrc\fR and
\fImacros\fR
configuration file(s).
+.SS "DYNAMIC BUILD REQUIREMENTS"
+.PP
+When the %generate_buildrequires stage is executed and some of the resulting
+requirements are not satisfied,
@dmnks commented on this pull request.
> @@ -256,6 +266,18 @@ options are currently set in
\fIrpmrc\fR and
\fImacros\fR
configuration file(s).
+.SS "DYNAMIC BUILD REQUIREMENTS"
+.PP
+When the %generate_buildrequires stage is executed and some of the resulting
+requirements are not satisfied,
@dmnks pushed 1 commit.
96bf7343c84bf463baf7eb0f40a617c9019dd74f Docs: Add note on buildreqs.nosrc.rpm
and code 11
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1318/files/4524a18507fa3b13052ab3ae180
@dmnks pushed 1 commit.
6c358561b2b7593c9717797305d96d4133140ba6 Docs: Add note on buildreqs.nosrc.rpm
and code 11
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1318/files/96bf7343c84bf463baf7eb0f40a
@dmnks commented on this pull request.
> +to run this command (followed by new dependency resolution) repeatedly until
> it
+no longer exits with code 11.
Yeah, "new dependency resolution" sounds a bit awkward and isn't exactly clear.
Will fix.
As for the "until" clause, I wonder if rpmbuild
@dmnks commented on this pull request.
> +to run this command (followed by new dependency resolution) repeatedly until
> it
+no longer exits with code 11.
OK, thinking about it more, a situation could arise where a missing dep can't
be resolved or installed (with `dnf builddep`) for whatever
@dmnks commented on this pull request.
> +to run this command (followed by new dependency resolution) repeatedly until
> it
+no longer exits with code 11.
New revision force-pushed.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it o
@dmnks pushed 1 commit.
c9b9a299d93ead98e1f05098b3f80d46f8813153 Docs: Add DYNAMIC BUILD DEPENDENCIES
section
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1318/files/6c358561b2b7593c9717797305d96d41
Closed #959.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/959#event-3588768486___
Rpm-maint mailing list
Rpm-maint@lists.rpm
This is because of the `rpmio/digest_libgcrypt.c:rpmDigestLength()` function
not recognizing the `PGPHASHALGO_GOST12_256` and `PGPHASHALGO_GOST12_512` enums
introduced in the [RPM 5 patch for
Streebog](https://abf.io/staszhukov/rpm/blob/master/1082-add-GOST-R-34.10-2012-gcrypt-imaevm.patch).
Wh
Closed #1185.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1185#event-3604860188___
Rpm-maint mailing list
Rpm-maint@lists.r
So I did some more testing and it turns out, after all, that rpmbuild only
spends a tiny fraction of time in the `processPackageFiles()` function;
dependency generators (kmod.prov in particular) are a much bigger bottleneck
but also vastly trickier to parallelize.
The speed improvements that I
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1325
-- Commit Summary --
* Check & document need for correct OpenMP version
* Bump Lua to 5.2 in configure script
-- File Changes --
M INSTALL (6)
M configure.ac
Thanks for reporting this, @pixdrift. While the only solution for you is what
Panu outlined above, I have at least updated the configure script so that it
checks for the actual OpenMP version in the compiler, and also added a short
section into the INSTALL file which states the required version.
That's a very valid point and one that I didn't consider, honestly.
A more user-friendly way of dealing with this would actually be the opposite,
i.e. making the use of the priority keyword conditional at preprocessing, based
on the detected OpenMP version (which is trivial to do as shown in the
> Sometimes it's better to test for specifics features, sometimes for versions.
> I don't know how the OpenMP landscape looks like, but sometimes
> implementations only support a subset of a newer standard in which case
> testing for specific features is the friendlier way.
My impression after
@dmnks commented on this pull request.
> @@ -761,9 +778,9 @@ AC_ARG_WITH([lua], [AS_HELP_STRING([--with-lua], [build
> with lua support])],
AS_IF([test "$with_lua" != no],[
PKG_CHECK_MODULES([LUA],
-[lua >= 5.1],
+[lua >= 5.2],
Heh, it's funny how easy is to misread the subject l
Having revisited this again, I think I have a better grasp of the whole
mechanism now. And it's way simpler than I originally thought.
First of all, there's no such thing as "support for conditionals inside macro
definitions". Macros are just that - they may contain arbitrary text to be
substit
Thanks, will tweak the PR accordingly. And yeah, I agree otherwise.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1325#issuecomment-675362444__
@pmatilai good point. That being said, @Conan-Kudo has pointed out that we do
in fact respect `%_buildshell` in other, non-build related areas as well. Doing
a quick grep reveals for example:
`macros.in:%__spec_prep_shell%{___build_shell}`
Still, that doesn't mean we should follow that tren
So something like a `%_macroshell` would be a better idea, perhaps. But I'm not
sure. I'll need to run a more comprehensive search in the code base first, to
be able to make an educated guess :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
Sure you can. It's worth noting that this RFE is mostly cosmetic; being able to
redefine a macro shell would allow you to replace all the `%(/usr/bin/bash -c
"...")` calls with `%(...)`, as well as avoid spawning a shell just to spawn
another shell.
--
You are receiving this because you are su
@voxik That's an interesting idea. You could then do something like `%(ruby:
...)` or `%(python: ...)` or what have you. Sounds cool. Not sure about the
impact of this in a broader sense, but I don't see any reason it couldn't be
done.
That said, doing something just because "we can" doesn't al
> This is not unlike [setting SHELL in
> Makefiles](https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html).
+1
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/
Oh, I think I misunderstood. As @brianjmurrell said above, any interpreter
would work, yes :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1334#issuecomment-675500681_
@brianjmurrell is correct. All we would do is pass the given string enclosed in
`%()` to the interpreter of choice, so if that's what you mean by "supported",
then sure!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https
I'm yet to understand if there are any security implications by allowing to
redefine the shell in a macro, though. But we already allow that for building
anyway, and building a spec file is no different from running a regular shell
script after all (you should audit the spec file before doing so
Yeah, I deleted that comment after realizing I misunderstood @voxik's question,
but thinking again, it really is not a bad idea at all! It would be easier than
having to redefine `%_macroshell` (or whatever we'd call it) and also cleaner,
as you say. It would also get rid of the problem with "h
@Conan-Kudo, thanks for the pointers, I had the feeling this had been discussed
in the past.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1334#issuecomment-676224334__
Since the body of a newly defined macro may span multiple lines and
contain %if expressions, we need to make sure the line parser does not
try to interpret those when the corresponding %define or %global macro
appears in a false %if branch and is therefore left unexpanded in the
line buffer.
This
> Technically %define and %global can appear anywhere at all in the spec, not
> just beginning of line
OK, true. One example: `%{!?foo:%define foo ...}` For some reason, this didn't
occur to me, sigh...
In that case, I agree it doesn't make sense to specifically handle the
"beginning of line"
Yes, this is really ugly :)
It turns out, though, these `%define` & `%if` constructs are not that rare
after all:
https://src.fedoraproject.org/rpms/kernel/blob/master/f/kernel.spec#_2778
I wonder how much disruption it would be for such packages if we start
requiring proper escaping. Also, thi
> Eliminating ambiguity (which is _always_ buggy from somebody's perspective)
> is usually worth a fair amount of disruption in the end, and messy is in the
> eye of the beholder.
>
> ```
> %define test() \
> %if 1\
> BUG\
> %endif\
> %{nil}
> ```
>
> It's not that obvious whether the %if is me
Basically the closest example from the C language would be `#define`. You have
to escape line breaks the same way, leading to the same readability issues if
done extensively :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
Maybe the correct solution would be to actually collapse *any* macro found in a
false branch, not just the conditionals, `%include`s, `%define`s and
`%global`s. But I'll have to think that through.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
Thinking about your use case, you can achieve the same (i.e. get the filename
of the patch being passed) just by running
`readlink -f /dev/stdin`
in your `%__patch` script. No need to patch RPM after all :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email
@dmnks commented on this pull request.
> } else {
- patchcmd = rpmExpand("%{__patch} ", args, " < ", fn, NULL);
+ patchcmd = rpmExpand("RPM_PATCH_NAME=", sp->path, " %{__patch} ", args,
" < ", fn, NULL);
`sp->path` is the same as `fn`, and it's what's passed to `stdin` of the
@pmatilai Coming back to this PR after a while, I wonder if silently disabling
OpenMP (if the required version isn't available) is really what we want.
Wouldn't it be better to just fail and let the user disable OpenMP explicitly
with `--disable-openmp` if he/she decides so?
--
You are receivi
Perfect, that makes sense. That's the kind of information I was looking for,
thanks!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1325#issuecomment-684541767
> The right thing to do with an incompatible OpenMP is to silently disable
> OpenMP unless explicitly requested by --enable-openmp. Whether it's worth the
> trouble is a separate question, writing configure.ac logic is ... yeah. No
> cute kittens will be harmed if we set the default to "yes" ins
@pmatilai Updated, please review.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1325#issuecomment-684947396___
Rpm-maint mailin
@dmnks pushed 2 commits.
82c5af992ed87bb6665de2d382166a563cc7b398 Check for OpenMP version at configure
time
c3af4801917c6cf3d5b5153a02f4cc09f98d6ca2 Bump Lua to 5.2 in configure script
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1429
-- Commit Summary --
* Add "each" macro for concise log queue iteration
* Extract log iteration from rpmlogPrint()
* Print only errors in rpmbuild summary (#793)
--
Correct, this is caused by the compiler not supporting some of the OpenMP
features (it's actually the `priority` clause). We've added a check into the
`configure` script recently to "fix" this: #1325
--
You are receiving this because you are subscribed to this thread.
Reply to this email direct
@dmnks pushed 1 commit.
5f79f49e1b331bef57c46303f7648280b36ee9e7 Add section for warnings to rpmbuild
output
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1429/files/5f1f9520154fc8db66cf7de18d2d78105
@dmnks pushed 2 commits.
fd4e326f52a9a62fd9a665636be13c0efbfd1b0e Ensure EOL in last line buffer
8173d570998a91ade0c27e35d8ecd86f21c64a19 NOEOL
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1429/file
> I was about to ask whether you're expecting a review on this (generally PR's
> with failing tests will not be looked at), but then I noticed this is a
> "draft", I didn't even know GH has such a (handy looking) feature so thanks
> for the tip
Yeah, it's nice. It's just the `[WIP]` prefix, "st
Sorry... wanted to give a peek, but of course, didn't make a note in my todo
list, so there you go... I'll check it nevertheless, as part of the BZ backport
that I'm assigned to :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on Gi
@dmnks pushed 6 commits.
1c332a1cfd24ce98c0a765f93ac3d45c819df376 Add rpmlogPrettyPrint() function
09be300f7c97f8959c2ba983af079af413ca6d72 Refactor
2f05222886e6927a97b944d3029eed52a361e8b8 Ensure EOL in last line buffer
44c98a8a0d01e9ba7bfca3a3c986df1165219335 NOEOL
3def2912c3e05662ac1a881333
@dmnks pushed 2 commits.
6fbfcfe7bb1dce6ce926602d6bc5800150c17994 Add rpmlogGetNrecsByMask() function
a520b3fabbb744163cb9cad2441976e001549ec8 Add summary
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pul
@dmnks pushed 1 commit.
2730ecbae50d766829d324af2f25065037eecb76 Indent
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1429/files/b45034422911ad650d39e211bb0b90a632e8eec8..2730ecbae50d766829d324af2f250
LGTM
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1450#issuecomment-735747755___
Rpm-maint mailing list
Rpm-maint@lists.rpm.or
I can see two aspects being discussed here:
1) We don't want to error out if OpenMP is older than expected. This is what
happens at the moment, though - we only error out if `--enable-openmp` is
issued, but not otherwise.
2) We want to allow builds without OpenMP support. This is already suppor
All that being said, I wonder if making OpenMP's `priority` support itself
optional (which is the reason for mandating version 4.5 in the first place)
wouldn't be better after all, especially considering that this is not the first
issue reported after the OpenMP version
[bump](https://github.co
@dmnks commented on this pull request.
> FD_t fd = NULL;
static const char *tryspec[] = { "Specfile", "\\*.spec", NULL };
-if (!(fd = rpmMkTempFile(NULL, &specFile)))
+specDir = rpmGetPath("%{_tmppath}", NULL);
Cosmetic: For clarity, I would move this line to before the `spe
Other than my inline comments, looks good to me!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1397#issuecomment-735952852___
R
Thank you. This is indeed a bug in the configure script. We shouldn't apply the
`OPENMP_CFLAGS` macro if we just evaluated that the required version of OpenMP
is not available. Let me fix that quickly.
--
You are receiving this because you are subscribed to this thread.
Reply to this email dire
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1454
-- Commit Summary --
* Fix
* Drop dependency on OpenMP 4.5
* Add conditional for OMP priority clause
-- File Changes --
M INSTALL (7)
M build/pack.c (4)
@dmnks commented on this pull request.
> @@ -22,6 +22,10 @@
#include "debug.h"
+#if _OPENMP < 201511
+#define priority(x)
Hmm, now that I think about it - wouldn't this be too brittle a macro? What if
we define/include a function `priority()` in the future? Wouldn't this replace
it?
--
Closed #1454.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1454#event-4067094114___
Rpm-maint mailing list
Rpm-maint@lists.rpm
OK. In that case, there *is* one thing to be done, which is to fix the bug in
that check (that I mentioned above). I'll do that, and close this PR. Thanks!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/r
Oh, no worries at all, we are in agreement here. That said, in this particular
case, I don't consider the time wasted since it helped me find a little bug in
the openmp check which has confused a couple of people already, and has a
trivial solution :)
--
You are receiving this because you are
Fix up for commit 6a780f1.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1455
-- Commit Summary --
* Really disable OpenMP if too old
-- File Changes --
M configure.ac (1)
-- Patch Links --
https://github.com/rpm-s
Fixed here: https://github.com/rpm-software-management/rpm/pull/1455
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1433#issuecomment-738028700_
@dmnks approved this pull request.
> @@ -383,12 +385,22 @@ static char * getTarSpec(const char *arg)
if (!gotspec) {
rpmlog(RPMLOG_ERR, _("Failed to read spec file from %s\n"), arg);
- specFile = NULL;
+} else {
+ /* remove trailing \n */
+ tarbuf[strlen(tarb
LGTM :smile:
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1457#issuecomment-740570412___
Rpm-maint mailing list
Rpm-maint@lis
Closed #1420.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1420#event-4210938187___
Rpm-maint mailing list
Rpm-maint@lists.r
This has been resolved by #1455 (as also discussed in #1433), so closing now.
Thanks again!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1420#issuecomment-760913437___
LGTM
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1535#issuecomment-778130486___
Rpm-maint mailing list
Rpm-maint@lists.rpm.or
Closed #1519.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1519#event-4324579306___
Rpm-maint mailing list
Rpm-maint@lists.r
Thanks, closing in lieu of
https://github.com/rpm-software-management/rpm-web/issues/19.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1519#issuecomment-778168786__
Perhaps we could also come up with a simple scheme to specify a list of
packages together with the desired action, for example:
```
--add-packages i:foo i:bar e:baz
```
Basically, a shorthand for:
```
--add-install foo --add-install bar --add-erase baz
```
(Could we use popt's aliasing magic here
Hmm, although it would probably be easier to just allow a list of package in
the `--add-install` and `--add-erase` options themselves:
```
--add-install foo,bar --add-erase baz
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on Git
This is a bit more complicated than one would think. The `--query` option is
deliberately hidden from the usage/help output because there simply isn't a
good help section to house it:
```
$ rpm --help
[...]
Query/Verify package selection options:
Query/Verify file selection options:
Query option
Closed #1473.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1473#event-4371833918___
Rpm-maint mailing list
Rpm-maint@lists.r
Thanks, Mirku, for looking into this! I like the simplicity of your solution,
here's how it would look like:
```
Usage: rpm [-afgplsiv?] [-a|--all] [-f|--file] [-g|--group] [-p|--package]
[--pkgid] [--hdrid] [--triggeredby] [--whatconflicts] [--whatrequires]
[--whatobsoletes] [--whatprovides]
401 - 500 of 1220 matches
Mail list logo
