Currently, there's no callback type that would be issued per each
transaction element. RPMCALLBACK_TRANS_ST* are only issued during the
prepare phase but not when packages are actually installed or erased.
Likewise, RPMCALLBACK_INST_ST* and RPMCALLBACK_UNINST_ST* won't be
issued if an install or
Hi Florian,
What's the estimate for the next upstream or downstream (F22+) release of rpm?
The thing is, we would like to have this patch shipped since a bug fix in dnf
depends on it. The bug is low-priority, though, so there's no hurry. We'd
like to know the NEVRA on which to depend on, at
dmnks commented on this pull request.
> @@ -276,7 +282,26 @@ static int runGPG(sigTarget sigt, const char *sigfile)
rpmPopMacro(NULL, "__plaintext_filename");
rpmPopMacro(NULL, "__signature_filename");
+/* The child GPG process may terminate without ever opening the pipe (such
+
dmnks commented on this pull request.
> @@ -276,7 +282,26 @@ static int runGPG(sigTarget sigt, const char *sigfile)
rpmPopMacro(NULL, "__plaintext_filename");
rpmPopMacro(NULL, "__signature_filename");
+/* The child GPG process may terminate without ever opening the pipe (such
+
dmnks commented on this pull request.
> @@ -276,7 +282,26 @@ static int runGPG(sigTarget sigt, const char *sigfile)
rpmPopMacro(NULL, "__plaintext_filename");
rpmPopMacro(NULL, "__signature_filename");
+/* The child GPG process may terminate without ever opening the pipe (such
+
> A SIGCHLD can happen all the time for whatever reason, you need at least to
> check if the process still exists and retry the Fopen if it does and the
> error is EINTR.
Could you please elaborate? The thing is, what we're trying to do here is to
actually get Fopen unblock when a SIGCHLD
> (A different fix that might also work (untested) would be to simply open the
> named pipe for reading before doing the exec call. You can even do that
> before the fork(). The opened file descriptor will not be used by gpg, but
> that shouldn't hurt.)
Turns out this won't work. When calling
> (A different fix that might also work (untested) would be to simply open the
> named pipe for reading before doing the exec call. You can even do that
> before the fork(). The opened file descriptor will not be used by gpg, but
> that shouldn't hurt.)
This actually sounds pretty good. I'll
Corrected patch in progress, will push tomorrow.
--
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-555122938___
dmnks commented on this pull request.
> fnamedPipe = Fopen(namedPipeName, "w");
+
+if (errno == EINTR) {
+ /* We got interrupted while waiting on the reader side to open the
Hmm, seems like the mix of tabs and spaces confuses github's diff viewer :)
--
You are receiving this
@dmnks pushed 1 commit.
394a50b2eeaba90256d54cc26c44b8aa67cff827 Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
The GPG subprocess may not open the named pipe that we create for
feeding it the package to sign (such as when the key is expired, as seen
in the linked bug), in which case RPM hangs up for the user due to the
blocking open(2) call on that pipe.
The fix is easy: just register an empty SIGCHLD
@dmnks pushed 1 commit.
124cb1c74587e26afc43882a8468088dd0862de0 Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 1 commit.
1c92f7bbd135e60468dda7ff0e79cdc284dbeaa1 Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Sorry for the delay; I just pushed a reworked version of this patch, please
re-review.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@dmnks pushed 1 commit.
f4d2e9ebf21660ece2986879d6602fc7fa88aea3 Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
dmnks commented on this pull request.
> @@ -238,11 +239,25 @@ static rpmtd makeSigTag(Header sigh, int ishdr, uint8_t
> *pkt, size_t pktlen)
return sigtd;
}
+pid_t gpgPid = 0;
Indeed. No rush!
Declaration fixed.
--
You are receiving this because you are subscribed to this thread.
I also tried putting the `open()` call in the forked process just before we
replace it with GPG with `execve()`, but the result was the same as above.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
It does block on `waitpid()`. But that could be a different problem. 'll try to
investigate. I would go with this kind of solution too, for its simplicity.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> Regarding opening the pipe for reading: oh yeah, that's right. You can't do
> it before the fork. But it should work if you do it after the fork.
Actually it does not! :) I tried opening it after the fork (in the RPM
process), just before the writer end is opened:
```
Fopen(namedPipeName,
FTR, I can make the RPM process unblock (and fail gracefully) when I use the
following instead:
`open(namedPipeName, O_NONBLOCK, "r");`
However, this only helps in the GPG failure case (expired keys). If the keys
are OK and GPG gets around to opening the pipe eventually, the RPM process
hangs
Previously, we assumed a backslash character would always be followed by
a character to be escaped, and advanced our start pointer by two
places before the next iteration. However, this assumption breaks if
the lonely backslash happens to be the last character in the query
string, in which case
@Conan-Kudo Fair enough. Could you please open an issue for that? And perhaps
include additional details, preferably a use case that you encountered in the
past that would be easier with this feature?
--
You are receiving this because you are subscribed to this thread.
Reply to this email
dmnks commented on this pull request.
> @@ -1415,8 +1467,23 @@ static int rpmtsSetup(rpmts ts, rpmprobFilterFlags
> ignoreSet)
return 0;
}
+/* Enable / disable optimizations for solid state disks */
+static void setSSD(int enable)
+{
+if (enable) {
+ rpmlog(RPMLOG_DEBUG,
@ascherer Thanks for the fast reply!
@pmatilai Do we want to pursue this change in the long run (and thus should
keep it open)?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I think we should reconsider this one. Returning
`RPMBUILD_MISSINGBUILDREQUIRES` when `--nodeps` is in effect [doesn't
seem](https://github.com/rpm-software-management/mock/issues/434#issuecomment-577086572)
right.
--
You are receiving this because you are subscribed to this thread.
Reply to
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-2969273020___
Rpm-maint mailing list
(Please ignore the "mention" above, I used the wrong link there.)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Note: Based on a chat with @praiskup, a fix (if any) should not happen until
mock has fixed (worked around this) itself, otherwise we would run a risk of
breaking it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Discussed here:
https://github.com/rpm-software-management/mock/issues/434#issuecomment-576703484
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Closed #150.
--
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/150#event-2966453116___
Rpm-maint mailing list
Closing as per
https://github.com/rpm-software-management/rpm/issues/150#issuecomment-278279277.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
In an attempt to revive this work:
I think what @pmatilai meant to suggest above was to allow for a generic way to
pass arguments to programs invoked as part of the %setup macro, as opposed to
handling each extractor (and the respective macro) separately. The pending
patch does the latter and
}/libfoo_light4.so
%files heavy1
%{_libdir}/libfoo_heavy1.so
%changelog
* Mon Mar 2 2020 Michal Domonkos
-
```
On my laptop, the total build time is `~1:35s` and `~1:20s` before and after
the patch, respectively. Not a huge difference here, but thread utilization is
be a bit better now
}/libfoo_light4.so
%files heavy1
%{_libdir}/libfoo_heavy1.so
%changelog
* Mon Mar 2 2020 Michal Domonkos
-
```
On my laptop, the total build time is `~1:35` and `~1:20` before and after the
patch, respectively. Not a huge difference here, but thread utilization is be a
bit better now
Binary packages come in different sizes and so their build time can vary
greatly. Dynamic scheduling, which we currently use for parallel
building, is a good strategy to combat such differences and load-balance
the available CPU cores.
That said, knowing that the build time of a package is
@dmnks pushed 1 commit.
7ab76d425d3660a3bfc83009f7cd77096bdb8881 fixup! build: prioritize large
packages
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
Good point on the backwards loop; it really shouldn't scream "look ma, reverse
loop for no obvious reason, go figure out yourself!".
Instead, I'll just make the reverse ordering explicit by simply inverting the
`compareBinaries()` function, and push a fixup commit right away.
--
You are
Thanks for the feedback.
I also noticed `readFilesManifest()` as being one potential source of problems
here. Indeed, with a dirty patch that I'm currently testing out, I got a few
random crashes (possibly due to that).
However, in those cases where it worked, the build time of a kernel on
My preliminary testing shows a promising reduction of build time (with the
kernel package) when doing this, but I still have to analyze and understand the
code better, to see if it really is safe to do and nothing breaks as a result.
--
You are receiving this because you are subscribed to this
@dmnks pushed 1 commit.
b5700cb7e707b4b38fa431d25f44df0ff7a5a9b2 build: prioritize large packages
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@pmatilai Fixed and rebased.
Note that I changed `RPMTAG_SIZE` to `RPMTAG_LONGSIZE` because I realized the
former may not be set if the total size is greater than 32 bits (details
[here](https://rpm.org/devel_doc/large_files.html)).
--
You are receiving this because you are subscribed to this
Good to know! No PR yet, but I'll create one soon-ish and reference this issue
in it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@dmnks pushed 1 commit.
7ba7f3a0d2a9a2edfb03dda2e045e8f570487514 Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 1 commit.
a1c384cd841bc6da2f2805fb4000b3a2e24254d8 Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 2 commits.
1cd747fa9599424fcb0151518f4ff50e116c993e Exit
7b2074b61be01dba7568e4a8bafb8956693aa49f Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 2 commits.
7730c3f31e73e2ae290f8aab2caee33fca905361 Rename
b98ad2d140a924f6794dbff2eb3c842cd79f200e Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 1 commit.
5f583ba5136d94f5189fe2d044c0c215c9a69f7e Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 2 commits.
b9b42ef226facad6a632404aa385dffb30c28794 Exit
ad7d340e08d1e43a692805fc3077c33cad12e6f9 Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 1 commit.
f343661ecb7eedf95c2206de57ad83ec71a0af3c Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 1 commit.
787f80c2340544fd55c0a1eb7dcdb6adcbe199e1 Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 2 commits.
3173e9a82f1a7a66264d0e092c1a338be3a1456a Rename
1a1bf9a336294539befd81c6a4519bda2e45f843 Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 1 commit.
a1a343679f089380af6192f6fa07f73b1e7310e8 Stop blocking when GPG process dies
prematurely (RhBug:1746353)
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
> 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"
@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
@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
@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:
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,
> 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"
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
> 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
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
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:
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
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
@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
> 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:
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
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
@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
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:
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
@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:
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
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
@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:
@dmnks pushed 2 commits.
f1df9c9bd2f7e9955932a63930c008e97440c9e8 GPG: Switch back to pipe(7) for
signing
285d1823ca30f4a19bf7058b248d2dfba428a11b GPG: refactor: exit label
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@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:
@dmnks pushed 2 commits.
ab87b1ef439f7bc74302cf4e36720711d2ae93f5 GPG: Switch back to pipe(7) for
signing
940b93a130654f4d7bb0a94cacda395c26d7c7e2 GPG: refactor: exit label
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks pushed 1 commit.
2d0b1f6c07dce3885d7d2761c6e1c98aa22b83b0 GPG: refactor: exit label
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@dmnks commented on this pull request.
> if (fnamedPipe)
Fclose(fnamedPipe);
-if (pid)
- waitpid(pid, , 0);
+if (gpgPid)
+ waitpid(gpgPid, , 0);
Hopefully resolved in the second commit :)
--
You are receiving this because you are subscribed to this
@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:
@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:
> 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
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
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
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
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
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
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:
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
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:
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
@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:
@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:
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:
@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
1 - 100 of 1013 matches
Mail list logo
