Re: [Rpm-maint] [rpm-software-management/rpm] build/pack.c: build failure due to pragma omp task untied on codesourcery-mips toolchain (#1420)
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.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] build/pack.c: build failure due to pragma omp task untied on codesourcery-mips toolchain (#1420)
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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add HACKING doc with the most important message of them all... (#1457)
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@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix 4.16.0 regression causing invalid spec file name on rpmbuild -ts (#1453)
@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(tarbuf)-1] = '\0';
+ specFinal = rpmExpand("%{_specdir}/%{basename:", tarbuf, "}", NULL);
Elegant! :smiley:
--
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/1453#pullrequestreview-544981744___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] don't error out if OpenMP is too old (#1433)
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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Really disable OpenMP if too old (#1455)
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-software-management/rpm/pull/1455.patch https://github.com/rpm-software-management/rpm/pull/1455.diff -- 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/1455 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix "#pragma omp priority" failure (#1454)
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 subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1454#issuecomment-738011787___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix "#pragma omp priority" failure (#1454)
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/rpm-software-management/rpm/pull/1454#issuecomment-737896441___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix "#pragma omp priority" failure (#1454)
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.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix "#pragma omp priority" failure (#1454)
@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? -- 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#pullrequestreview-543044491___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Fix "#pragma omp priority" failure (#1454)
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) M configure.ac (23) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1454.patch https://github.com/rpm-software-management/rpm/pull/1454.diff -- 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 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] don't error out if OpenMP is too old (#1433)
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 directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1433#issuecomment-736674484___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpmbuild: Fix `-ts` srpm specfile name (#1397)
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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpmbuild: Fix `-ts` srpm specfile name (#1397)
@dmnks commented on this pull request.
> FD_t fd = NULL;
static const char *tryspec[] = { "Specfile", "\\*.spec", NULL };
-if (!(fd = rpmMkTempFile(NULL, )))
+specDir = rpmGetPath("%{_tmppath}", NULL);
Cosmetic: For clarity, I would move this line to before the `specBase =`
assignment further down, as it's only really used in that block.
> +/* remove trailing \n */
+specBase[strlen(specBase)-1] = '\0';
+
+rasprintf(, "%s/%s", specDir, specBase);
+res = rename(tmpSpecFile, specFile);
+
+if (res) {
+ rpmlog(RPMLOG_ERR, _("Failed to rename %s to %s: %m\n"),
+ tmpSpecFile, specFile);
+ free(specFile);
+ specFile = NULL;
+} else {
+ /* mkstemp() can give unnecessarily strict permissions, fixup */
+ mode_t mask;
+ umask(mask = umask(0));
+ (void) chmod(specFile, 0666 & ~mask);
It seems like this is no longer needed - with a plain `mkstemp(3)`, the file
mode of the resulting file is undefined (as per the man page) and so needs to
be manually set, however `rpmMkTempFile()` [takes
care](https://github.com/rpm-software-management/rpm/blob/05fada7c9a1ef22bd310a9be4c6c06a4d2dd581d/rpmio/rpmfileutil.c#L58)
of that for us.
> FD_t fd = NULL;
static const char *tryspec[] = { "Specfile", "\\*.spec", NULL };
-if (!(fd = rpmMkTempFile(NULL, )))
+specDir = rpmGetPath("%{_tmppath}", NULL);
+if (!(fd = rpmMkTempFile(NULL, )))
I'm thinking if it makes sense to create this as a temp file, only to be
renamed to the real thing in the end? :)
Originally, I suppose, it was done because we didn't want to write the final
name into `_specdir` before being done with it (as to not risk leaving an
incomplete file behind in case of a failure), however now that we're keeping
the file in `_tmpdir` even after the rename, we could perhaps just use the
final name?
--
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#pullrequestreview-541126603___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] don't error out if OpenMP is too old (#1433)
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.com/rpm-software-management/rpm/pull/1325#issuecomment-684517393). -- 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-735857748___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] don't error out if OpenMP is too old (#1433)
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 supported, too - the `ENABLE_OPENMP` preprocessor macro is left undefined when either OpenMP is too old (see above), or when it is manually disabled with the `--disable-openmp` configure switch. Note that there's no need to conditionalize the individual `#pragma omp` usages - they're ignored by the compiler when the `omp.h` header is not included (which is controlled by the `ENABLE_OPENMP` macro). @ffontaine Is the above right, or am I missing something? -- 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-735850989___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Pull CI image from registry.fedoraproject.org (#1450)
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.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpmbuild logging tweaks (#1429)
@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..2730ecbae50d766829d324af2f25065037eecb76 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpmbuild logging tweaks (#1429)
@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/pull/1429/files/768b3f4bc7dedefc1df903ba2abb3b96bcc2f86e..a520b3fabbb744163cb9cad2441976e001549ec8 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpmbuild logging tweaks (#1429)
@dmnks pushed 6 commits. 1c332a1cfd24ce98c0a765f93ac3d45c819df376 Add rpmlogPrettyPrint() function 09be300f7c97f8959c2ba983af079af413ca6d72 Refactor 2f05222886e6927a97b944d3029eed52a361e8b8 Ensure EOL in last line buffer 44c98a8a0d01e9ba7bfca3a3c986df1165219335 NOEOL 3def2912c3e05662ac1a8813330c89466a08b5bd Add rpmlogGetNrecsByMask() function 755f55d64d2c12bd1b67e3d8f62f8b117a78c3fa Add summary -- 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/8173d570998a91ade0c27e35d8ecd86f21c64a19..755f55d64d2c12bd1b67e3d8f62f8b117a78c3fa ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Eliminate use of obsolete gethostbyname() function (#1428)
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 GitHub: https://github.com/rpm-software-management/rpm/pull/1428#issuecomment-732114810___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpmbuild logging tweaks (#1429)
> 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, "standardized", plus it prevents one from accidentally merging it (which probably never happens anyway, but it improves peace of mind) :) > * Do split the log message improvements to a separate PR from the rpmlog > infrastructure work Good point. I'll split it later. > * For the task of finding the last newline, the standard C library has > (for once!) strrchr() so you don't need to do that manually Oh, of course. What I wanted was the _index_ of the last non-newline char, which is why I didn't go for `strchr()` as it returns a pointer... except that it didn't occur to me that you can get the index with simple pointer arithmetic... sigh. Thanks for noticing :) -- 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/1429#issuecomment-732110842___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpmbuild logging tweaks (#1429)
@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/files/5f79f49e1b331bef57c46303f7648280b36ee9e7..8173d570998a91ade0c27e35d8ecd86f21c64a19 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpmbuild logging tweaks (#1429)
@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/5f1f9520154fc8db66cf7de18d2d781055174968..5f79f49e1b331bef57c46303f7648280b36ee9e7 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] build/pack.c: build failure due to pragma omp task untied on codesourcery-mips toolchain (#1420)
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 directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1420#issuecomment-724555218___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] rpmbuild logging tweaks (#1429)
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) -- File Changes -- M build/build.c (2) M rpmio/rpmlog.c (36) M rpmio/rpmlog.h (7) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1429.patch https://github.com/rpm-software-management/rpm/pull/1429.diff -- 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/1429 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] OpenMP & Lua fixes for configure.ac & INSTALL (#1325)
@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 mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] OpenMP & Lua fixes for configure.ac & INSTALL (#1325)
@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/rpm-software-management/rpm/pull/1325/files/b1ef1a1326f2e777ea43790a79ea5fa640fbb521..c3af4801917c6cf3d5b5153a02f4cc09f98d6ca2 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] OpenMP & Lua fixes for configure.ac & INSTALL (#1325)
> 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" instead of > implementing "auto". Nah, the logic shouldn't be much of a problem I think. -- 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-684552367___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] OpenMP & Lua fixes for configure.ac & INSTALL (#1325)
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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] OpenMP & Lua fixes for configure.ac & INSTALL (#1325)
@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 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-684476437___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] doPatch: send patch name to %__patch (#1350)
@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
`%__patch` binary, which means you can easily get that value by running
`readlink -f /dev/stdin` in your binary. Handy, isn't it? :)
--
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/1350#pullrequestreview-476938605___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] doPatch: send patch name to %__patch (#1350)
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 directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1350#issuecomment-682087507___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Collapse unexpanded macro definitions (#1198) (#1343)
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 or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1343#issuecomment-679986004___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Unclosed %if (when defined inside %define) (#1198)
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: https://github.com/rpm-software-management/rpm/issues/1198#issuecomment-679977879___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Unclosed %if (when defined inside %define) (#1198)
> 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 meant for the spec parser inline, or
> whether it's meant to be part of the macro body.
Is that a question for the parser or for the person reading the code?
If the former, that's not really the case, as it's unambiguously part of the
macro body, due to the line-continuation marker(s) preceding it. By
"collapsing" the `%define` the whole body becomes one line and the parser
continues past it.
If the latter, totally agree. But I think this is the case with any other
language as well; whenever you manually line-break statements, consider e.g. a
long `if` expression in C. It's more about the "code culture" at that point.
For specs, it's not usual to indent stuff, but that probably has to do with
insufficient support for that (is that still the case, btw?).
--
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/1198#issuecomment-679974112___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Unclosed %if (when defined inside %define) (#1198)
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, this could make spec files look a bit more messy than they already are. -- 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/1198#issuecomment-679931880___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Collapse unexpanded macro definitions (#1198) (#1343)
> 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" case only. That's not a systemic solution, just a band-aid.
> Another twist is that unlike %define, the body of the %global is expanded at
> the time of definition, which means that a %global macro defined in the spec
> itself with an %if is always broken (wrt the %if in spec context).
Wait, isn't the distinction between those two macros about the time their
*bodies* get expanded? I mean, both macros *are* expanded at definition time,
it's just that the body of a `%define` is itself only expanded when actually
used, right? Just to re-iterate - expanding a `%define` or `%global` macro
means introducing the macro that's being defined into the respective (local or
global) namespace.
--
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/1343#issuecomment-679928150___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Collapse unexpanded macro definitions (#1198) (#1343)
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 is usually not a problem since any macros found in the body itself would not be expanded anyway, but it can break the syntax check for conditionals, which follows after expansion. This is because, with the recently introduced support for line-continuation markers in %if expressions (commit 5f4fdce), the parser would be tricked into thinking that the markers belong to the %if expression itself and collapse them into a single line, including the matching %endif, and then complain about the missing %endif (which must be on a separate line). Instead, similarly to %if, we should collapse the %define/%global macro itself so that the line parser doesnt pass through the body at all. A side effect of this change (of commit 5f4fdce from a year ago, in fact) is that %if constructs are no longer syntax-checked within macros defined in false %if branches, but thats arguably correct behavior, since they only come into existence when their definition macro (%define or %global) is actually expanded, and should merely be treated as text values until that point. Fixes: #1198 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1343 -- Commit Summary -- * Collapse unexpanded macro definitions (#1198) -- File Changes -- M build/parseSpec.c (6) M build/rpmbuild_internal.h (4) A tests/data/SPECS/ifmultiline-macro.spec (22) M tests/rpmbuild.at (9) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1343.patch https://github.com/rpm-software-management/rpm/pull/1343.diff -- 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/1343 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
@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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
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 "how do we pass the script body into a non-shell-like interpreter" that I mentioned above. -- 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-675530398___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
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). -- 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-675505485___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
@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://github.com/rpm-software-management/rpm/issues/1334#issuecomment-675504028___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
> 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/rpm/issues/1334#issuecomment-675499466___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
@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 always translate well into the maintenance side of things :) But if there are real-life use cases that would be improved with this, I think we'd open for 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/1334#issuecomment-675497790___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
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 subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1334#issuecomment-675484426___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
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 view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1334#issuecomment-675476325___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Define shell to use with %() (#1334)
@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 trend, especially given that
macro processing really is a separate step in the whole spec building process.
Also, making `%()` suddenly use `%_buildshell` could cause unexpected things to
happen in spec file which already redefine it. For consistency's sake, on the
other hand, it would make sense to reuse it...
--
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-675472264___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] OpenMP & Lua fixes for configure.ac & INSTALL (#1325)
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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Unclosed %if (when defined inside %define) (#1198)
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
substituted by them, including other macros which are expanded recursively.
Now, since `%if` is not a macro per se, it won't get expanded into anything and
just pushed to the parser for further processing (which includes conditional
parsing). As a result, spec directives found inside conditionals (that are
found inside macros) are a valid construct.
In fact, we ourselves have been using this *for years* in the `%debug_package`
macro shipped with RPM:
```
%debug_package \
%ifnarch noarch\
%global __debug_package 1\
%_debuginfo_template\
%{?_debugsource_packages:%_debugsource_template}\
%endif\
%{nil}
```
That being said, there's a catch. Since conditionals are only evaluated *after*
recursive macro expansion, the `%__debug_package` macro above will *always* be
set to 1, regardless of whether `BuildArch` is `noarch`. I think this was
(quite understandably) misunderstood when the macro was written. Another
example is the one I gave in the previous comment where "hello" is always
printed due to the fact that `echo` gets expanded (and executed) before the
conditional is.
In any case, bringing back the original functionality makes sense after all,
and I'll post a PR shortly.
--
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/1198#issuecomment-675338506___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] OpenMP & Lua fixes for configure.ac & INSTALL (#1325)
@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 line of that commit message when shown in a popup box after hovering over it. It says "drop support for Lua < 5.2" with a line break after the "<" symbol which is then easy to miss :) -- 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#discussion_r466893351___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] OpenMP & Lua fixes for configure.ac & INSTALL (#1325)
> 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 skimming through a couple of random discussion threads and stackoverflow posts is very much this; while the API is well-defined, the reality is that compilers may only have partial support for certain features. With GCC, I think it's safe to assume it's fully supported, but I agree that testing for the particular feature is always the safest option. > OTOH the simplicity of being able to say "we require version X of standard Z" > can be a bliss - for example we generally require POSIX.1 >= 2001 and that > makes it fairly easy to cross-check portability issues and to say "no" to > obscure stuff that doesn't fulfil that basic requirement. Yup, I basically had the same mindset and just went with the version check, instead of checking for the priority feature alone. That also "scales" better in case we adopt some other OpenMP features in the future; instead of adding another convoluted compilation test to the configure script, we would just bump the version. That being said, especially given the nature of the non-100% compiler support, doing something like you suggested above with a custom `HAVE_OMP_PRIORITY` flag which we would set in a compilation test in `configure.ac` seems to be the best solution here. It just doesn't feel right to mandate version 4.5 (being "too new" in terms of RPM as you noted) just because of that damn priority thing which the world can live without just fine. -- 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-670390942___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] OpenMP & Lua fixes for configure.ac & INSTALL (#1325)
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 patch) because as you say, all that the keyword really does is it improves load balance a tiny little bit in specific circumstances. We could even avoid doing a `qsort()` on the package list as part of that conditional. Would that be better? -- 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-669953999___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] packageBinaries compile error when building rpm-4.16.0-beta3 from source (#1315)
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. -- 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/1315#issuecomment-669289353___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] OpenMP & Lua fixes for configure.ac & INSTALL (#1325)
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 (25) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1325.patch https://github.com/rpm-software-management/rpm/pull/1325.diff -- 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 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parallelize file processing (#1185)
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.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Parallelize file processing (#1185)
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 observed a while ago in https://github.com/rpm-software-management/rpm/issues/1185#issuecomment-617147116 were most likely just a false positive due to some internal data inconsistency caused by the "naive" patch that I tested with. With that said, I'm closing this ticket as there's no point in putting much effort in this. OTOH, parallel execution of dependency generators (`rpmfcGenerateDepends()`) is something where real improvements could be made (in the case of kernel, the cumulative runtime of these is in the order of hunderds of seconds). But that would be tracked in a separate issue. -- 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#issuecomment-666524760___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Incorrect length of unknown filedigest algos (#959)
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). When RPM 4 reads such a package, the `RPMTAG_FILEDIGESTALGO` header falls back to `PGPHASHALGO_MD5` due to `rpmDigestLength()` returning 0. Later, when dumping file information in `lib/query.c:showQueryPackage()`, the same function is called, this time returning 16 (due to `PGPHASHALGO_MD5`). As a result, the string is formatted into a 128 bit (16 byte) hex string representation in the dump. There's not much we can do without introducing proper Streebog support, I'm afraid. All we can do is suggest that you submit a PR (possibly based on the original RPM 5 patch) if you wish to have this supported. I'm closing this issue now. -- 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#issuecomment-664204486___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Incorrect length of unknown filedigest algos (#959)
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.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Docs: Revamp BUILD OPTIONS section in rpmbuild(8) (#1318)
@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/6c358561b2b7593c9717797305d96d4133140ba6..c9b9a299d93ead98e1f05098b3f80d46f8813153 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Docs: Revamp BUILD OPTIONS section in rpmbuild(8) (#1318)
@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 on GitHub: https://github.com/rpm-software-management/rpm/pull/1318#discussion_r459976548___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Docs: Revamp BUILD OPTIONS section in rpmbuild(8) (#1318)
@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 reason, in which case saying that "repeat the whole `rpmbuild -br` + `dnf builddep` process while exit code = 11" would make this into an endless loop :) -- 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/1318#discussion_r459961523___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Docs: Revamp BUILD OPTIONS section in rpmbuild(8) (#1318)
@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 can exit with 0 and still generate new deps? From what I can see in the code, this shouldn't ever happen. I know that Mock actually does check for new deps (instead of the return code), but that's because they have to use `--nodeps` (due to unrelated reasons) which always returns 11. -- 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/1318#discussion_r459927495___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Docs: Revamp BUILD OPTIONS section in rpmbuild(8) (#1318)
@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/96bf7343c84bf463baf7eb0f40a617c9019dd74f..6c358561b2b7593c9717797305d96d4133140ba6 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Docs: Revamp BUILD OPTIONS section in rpmbuild(8) (#1318)
@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/4524a18507fa3b13052ab3ae180c319aff8c4fc6..96bf7343c84bf463baf7eb0f40a617c9019dd74f ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Docs: Revamp BUILD OPTIONS section in rpmbuild(8) (#1318)
@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, \fBrpmbuild\fR exits with code 11 and does not +create the source package. +Instead, a package ending with \fIbuildreqs.nosrc.rpm\fR is created, which has +all the build requirements, including the newly generated ones. Reworded, please let me know if it's better now. -- 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/1318#discussion_r459551390___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Docs: Revamp BUILD OPTIONS section in rpmbuild(8) (#1318)
@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, \fBrpmbuild\fR exits with code 11 and does not +create the source package. +Instead, a package ending with \fIbuildreqs.nosrc.rpm\fR is created, which has +all the build requirements, including the newly generated ones. Ah, I see. The [dummy spec](https://github.com/rpm-software-management/rpm/files/3911787/dummy-pkg.spec.txt) that @hrnciar provided in the related issue actually does exactly 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/pull/1318#discussion_r459327199___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Docs: Revamp BUILD OPTIONS section in rpmbuild(8) (#1318)
@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, \fBrpmbuild\fR exits with code 11 and does not +create the source package. +Instead, a package ending with \fIbuildreqs.nosrc.rpm\fR is created, which has +all the build requirements, including the newly generated ones. @ignatenkobrain, just to clarify, is that because of the fact that a `%generate_buildrequires` macro could be generated during the previous iteration? -- 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/1318#discussion_r459324461___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Docs: Revamp BUILD OPTIONS section in rpmbuild(8) (#1318)
@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, \fBrpmbuild\fR exits with code 11 and does not +create the source package. +Instead, a package ending with \fIbuildreqs.nosrc.rpm\fR is created, which has +all the build requirements, including the newly generated ones. Oh, right. Thanks! I'll fix 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/pull/1318#discussion_r459320805___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Docs: Revamp BUILD OPTIONS section in rpmbuild(8) (#1318)
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 (60) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/1318.patch https://github.com/rpm-software-management/rpm/pull/1318.diff -- 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/1318 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Improved errors handling. (#1305)
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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Always close libelf handle (#1313)
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 http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Always close libelf handle (#1313)
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://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Document: "rpmbuild -br" always returns 11 when "--nodeps" is used (#963)
> > 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 and some *might* be missing. -- 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-660094472___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Unclosed %if (when defined inside %define) (#1198)
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. The patch in
5f4fdce interprets these markers equally, though.
This becomes a problem when a `%define` or `%global` macro is encountered in a
false branch of an `%if` statement and is therefore left unexpanded (for
obvious reasons); the spec parser just continues scanning the macro's body as
if it were part of the spec itself: it joins the inner `%if` statement into a
single line, including the inner `%endif` (since all of the lines end with an
`\`) and finally tries to match it against a corresponding `%endif`, which
fails as there's none.
The remedy here would be to completely skip the macro's body in case it's
unexpanded. In fact, there's a very simple and elegant (yet non-obvious) way to
do this: when joining multi-line `%if` conditionals, treat `%define` as a such
a conditional; that way, the whole macro (when unexpanded) collapses into a
single line and its content is not interpreted. I have a working patch here:
https://github.com/dmnks/rpm/commit/9c1c592d40777868d672a531b49c63fb6dd6ec84
That being said, it turns out that conditionals inside macros are
*unsupported*. The macro expander does *not* interpret them at all. For
example, the following construct would print "hello":
```
%define test() \
%if 0 \
%{echo:hello} \
%endif
%test
```
This is also mentioned (though not entirely clearly) in the `/doc/manual/spec`
file:
```
%if-conditionals are not macros, and are unlikely to yield expected results
if used in them.
```
@ignatenkobrain, is there a specific use case for such conditionals that I'm
missing? While there is a simple fix for this (as described above) which
shouldn't introduce any side-effects (but I am not 100% sure yet), it doesn't
make much sense to apply it if the use case being fixed is in fact unsupported.
--
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/1198#issuecomment-660079015___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Document: "rpmbuild -br" always returns 11 when "--nodeps" is used (#963)
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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Document: "rpmbuild -br" always returns 11 when "--nodeps" is used (#963)
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. -- 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-658034249___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Document: "rpmbuild -br" always returns 11 when "--nodeps" is used (#963)
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 `RPMRC_MISSINGBUILDREQUIRES` (code 11) would be described, but it still feels a bit awkward to only have that and not the others. @ffesti, do we have a plan to document exit codes across RPM at all? -- 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-658001179___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] "rpmbuild -br" returns 11 even if "--nodeps" is used (#963)
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#issuecomment-654926047___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] "rpmbuild -br" returns 11 even if "--nodeps" is used (#963)
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.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] "rpmbuild -br" returns 11 even if "--nodeps" is used (#963)
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). So, closing this now. If you still wish to have this changed, please open a new issue describing the use case. -- 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-654811474___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] "rpmbuild -br" returns 11 even if "--nodeps" is used (#963)
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.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] GPG_TTY warning causes test-suite failure in mock (#1290)
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-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] GPG: Switch back to pipe(7) for signing (#938)
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___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] GPG: Switch back to pipe(7) for signing (#938)
@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-software-management/rpm/pull/938/files/5e81da9a19f576ad35d6358ed3d29787f8a708cc..e91e2ad55e18131aea621f3c2e6772bc891d1aa4 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] GPG: Switch back to pipe(7) for signing (#938)
@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 stdin: %m\n"));
Yeah, this was a bit sloppy, I agree. The `getenv()` test was supposed to
handle the case where the automatic setup of `GPG_TTY` failed and the variable
wasn't explicitly set by the user either. Let me try to express that better in
a followup amend :)
--
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#discussion_r444301782___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] GPG: Switch back to pipe(7) for signing (#938)
@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-software-management/rpm/pull/938/files/fe877767eb2350c1537f163e5f07d9ab950f5ab6..5e81da9a19f576ad35d6358ed3d29787f8a708cc ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] GPG: Switch back to pipe(7) for signing (#938)
@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-software-management/rpm/pull/938/files/14593f9924be7fbe6a4ba9849b0fd833b8fc83a5..c471ad104992c950e42afd12079c67c43642841e ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] GPG: Switch back to pipe(7) for signing (#938)
@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-software-management/rpm/pull/938#issuecomment-637398084___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] GPG: Switch back to pipe(7) for signing (#938)
@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-management/rpm/pull/938/files/4540e1a699758cef5f33c49d37e1a6561265d9f5..a58d462040774da53f91d8388b3bdd0b86916c25 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] GPG: Switch back to pipe(7) for signing (#938)
@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-management/rpm/pull/938/files/940b93a130654f4d7bb0a94cacda395c26d7c7e2..927790f8808488626993f33c88d97ca1755d4c3d ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] GPG: Switch back to pipe(7) for signing (#938)
@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: https://github.com/rpm-software-management/rpm/pull/938/files/2d0b1f6c07dce3885d7d2761c6e1c98aa22b83b0..940b93a130654f4d7bb0a94cacda395c26d7c7e2 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] GPG: Switch back to pipe(7) for signing (#938)
@dmnks pushed 1 commit. 2d0b1f6c07dce3885d7d2761c6e1c98aa22b83b0 GPG: refactor: exit label -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/938/files/285d1823ca30f4a19bf7058b248d2dfba428a11b..2d0b1f6c07dce3885d7d2761c6e1c98aa22b83b0 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Stop blocking when GPG process dies prematurely (RhBug:1746353) (#938)
@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 thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/938#discussion_r433171564___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Stop blocking when GPG process dies prematurely (RhBug:1746353) (#938)
@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: https://github.com/rpm-software-management/rpm/pull/938/files/787f80c2340544fd55c0a1eb7dcdb6adcbe199e1..285d1823ca30f4a19bf7058b248d2dfba428a11b ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Stop blocking when GPG process dies prematurely (RhBug:1746353) (#938)
@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: https://github.com/rpm-software-management/rpm/pull/938/files/7ba7f3a0d2a9a2edfb03dda2e045e8f570487514..787f80c2340544fd55c0a1eb7dcdb6adcbe199e1 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Stop blocking when GPG process dies prematurely (RhBug:1746353) (#938)
@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: https://github.com/rpm-software-management/rpm/pull/938/files/64a58570a8583e35fc2bc8de7872e56e77f6c195..7ba7f3a0d2a9a2edfb03dda2e045e8f570487514 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Stop blocking when GPG process dies prematurely (RhBug:1746353) (#938)
@dmnks pushed 1 commit. 64a58570a8583e35fc2bc8de7872e56e77f6c195 Stop blocking when GPG process dies prematurely (RhBug:1746353) -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/938/files/7b2074b61be01dba7568e4a8bafb8956693aa49f..64a58570a8583e35fc2bc8de7872e56e77f6c195 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Stop blocking when GPG process dies prematurely (RhBug:1746353) (#938)
@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: https://github.com/rpm-software-management/rpm/pull/938/files/fbbb90ad7411b38a16eb7df47b3eb463a3f39fbc..7b2074b61be01dba7568e4a8bafb8956693aa49f ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
