Re: [Rpm-maint] [rpm-software-management/rpm] build/pack.c: build failure due to pragma omp task untied on codesourcery-mips toolchain (#1420)

2021-01-15 Thread Michal Domonkos
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)

2021-01-15 Thread Michal Domonkos
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)

2020-12-08 Thread Michal Domonkos
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)

2020-12-04 Thread Michal Domonkos
@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)

2020-12-03 Thread Michal Domonkos
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)

2020-12-03 Thread Michal Domonkos
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)

2020-12-03 Thread Michal Domonkos
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)

2020-12-03 Thread Michal Domonkos
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)

2020-12-03 Thread Michal Domonkos
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)

2020-12-02 Thread Michal Domonkos
@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)

2020-12-02 Thread Michal Domonkos

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)

2020-12-01 Thread Michal Domonkos
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)

2020-11-30 Thread Michal Domonkos
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)

2020-11-30 Thread Michal Domonkos
@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)

2020-11-30 Thread Michal Domonkos
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)

2020-11-30 Thread Michal Domonkos
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)

2020-11-30 Thread Michal Domonkos
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)

2020-11-27 Thread Michal Domonkos
@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)

2020-11-24 Thread Michal Domonkos
@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)

2020-11-24 Thread Michal Domonkos
@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)

2020-11-23 Thread Michal Domonkos
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)

2020-11-23 Thread Michal Domonkos
> 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)

2020-11-20 Thread Michal Domonkos
@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)

2020-11-10 Thread Michal Domonkos
@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)

2020-11-10 Thread Michal Domonkos
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)

2020-11-09 Thread Michal Domonkos

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)

2020-09-01 Thread Michal Domonkos
@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)

2020-09-01 Thread Michal Domonkos
@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)

2020-09-01 Thread Michal Domonkos
> 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)

2020-09-01 Thread Michal Domonkos
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)

2020-09-01 Thread Michal Domonkos
@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)

2020-08-27 Thread Michal Domonkos
@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)

2020-08-27 Thread Michal Domonkos
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)

2020-08-25 Thread Michal Domonkos
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)

2020-08-25 Thread Michal Domonkos
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)

2020-08-25 Thread Michal Domonkos
> 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)

2020-08-25 Thread Michal Domonkos
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)

2020-08-25 Thread Michal Domonkos
> 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)

2020-08-24 Thread Michal Domonkos
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)

2020-08-19 Thread Michal Domonkos
@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)

2020-08-18 Thread Michal Domonkos
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)

2020-08-18 Thread Michal Domonkos
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)

2020-08-18 Thread Michal Domonkos
@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)

2020-08-18 Thread Michal Domonkos
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)

2020-08-18 Thread Michal Domonkos
> 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)

2020-08-18 Thread Michal Domonkos
@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)

2020-08-18 Thread Michal Domonkos
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)

2020-08-18 Thread Michal Domonkos
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)

2020-08-18 Thread Michal Domonkos
@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)

2020-08-18 Thread Michal Domonkos
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)

2020-08-18 Thread Michal Domonkos
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)

2020-08-07 Thread Michal Domonkos
@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)

2020-08-07 Thread Michal Domonkos
> 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)

2020-08-06 Thread Michal Domonkos
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)

2020-08-05 Thread Michal Domonkos
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)

2020-08-05 Thread Michal Domonkos

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)

2020-07-30 Thread Michal Domonkos
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)

2020-07-30 Thread Michal Domonkos
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)

2020-07-27 Thread Michal Domonkos
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)

2020-07-27 Thread Michal Domonkos
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)

2020-07-24 Thread Michal Domonkos
@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)

2020-07-24 Thread Michal Domonkos
@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)

2020-07-24 Thread Michal Domonkos
@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)

2020-07-24 Thread Michal Domonkos
@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)

2020-07-24 Thread Michal Domonkos
@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)

2020-07-24 Thread Michal Domonkos
@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)

2020-07-23 Thread Michal Domonkos
@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)

2020-07-23 Thread Michal Domonkos
@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)

2020-07-23 Thread Michal Domonkos
@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)

2020-07-23 Thread Michal Domonkos
@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)

2020-07-23 Thread Michal Domonkos

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)

2020-07-21 Thread Michal Domonkos
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)

2020-07-21 Thread Michal Domonkos
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)

2020-07-21 Thread Michal Domonkos
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)

2020-07-17 Thread Michal Domonkos
> > 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)

2020-07-17 Thread Michal Domonkos
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)

2020-07-14 Thread Michal Domonkos
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)

2020-07-14 Thread Michal Domonkos
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)

2020-07-14 Thread Michal Domonkos
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)

2020-07-07 Thread Michal Domonkos
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)

2020-07-07 Thread Michal Domonkos
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)

2020-07-07 Thread Michal Domonkos
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)

2020-07-07 Thread Michal Domonkos
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)

2020-06-24 Thread Michal Domonkos
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)

2020-06-23 Thread Michal Domonkos
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)

2020-06-23 Thread Michal Domonkos
@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)

2020-06-23 Thread Michal Domonkos
@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)

2020-06-23 Thread Michal Domonkos
@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)

2020-06-02 Thread Michal Domonkos
@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)

2020-06-02 Thread Michal Domonkos
@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)

2020-06-01 Thread Michal Domonkos
@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)

2020-06-01 Thread Michal Domonkos
@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)

2020-06-01 Thread Michal Domonkos
@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)

2020-06-01 Thread Michal Domonkos
@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)

2020-06-01 Thread Michal Domonkos
@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)

2020-06-01 Thread Michal Domonkos
@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)

2020-05-15 Thread Michal Domonkos
@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)

2020-05-15 Thread Michal Domonkos
@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)

2020-05-15 Thread Michal Domonkos
@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)

2020-05-15 Thread Michal Domonkos
@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


  1   2   >