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

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:

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"

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:

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

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

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

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

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

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

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,

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"

[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

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:

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

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

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:

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:

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:

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

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

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

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

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:

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

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

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

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

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

[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

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

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

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).

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

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:

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

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

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

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:

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:

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,

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,

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,

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,

[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

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:

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

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

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

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.

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:

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

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

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:

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

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

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

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___

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:

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:

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

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:

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:

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:

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:

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:

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:

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:

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

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:

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:

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:

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:

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:

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. f03324e53efdef781f4e7983c1f8e1adb5fe3b9e Exit fbbb90ad7411b38a16eb7df47b3eb463a3f39fbc Stop blocking when GPG process dies prematurely (RhBug:1746353) -- You are receiving this because you are subscribed to this thread. View it on GitHub:

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 3 commits. a14633e1e6cae90b2be8a33d069cf97125df76a9 Rename 0ddd03397b26d2c42da844fdcd0679a9e59217a6 Exit f3a520d0f1a443b3ca3f5c0a8ad894b6c0341d88 Stop blocking when GPG process dies prematurely (RhBug:1746353) -- You are receiving this because you are subscribed to this

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. b9b42ef226facad6a632404aa385dffb30c28794 Exit ad7d340e08d1e43a692805fc3077c33cad12e6f9 Stop blocking when GPG process dies prematurely (RhBug:1746353) -- You are receiving this because you are subscribed to this thread. View it on GitHub:

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. f343661ecb7eedf95c2206de57ad83ec71a0af3c Stop blocking when GPG process dies prematurely (RhBug:1746353) -- You are receiving this because you are subscribed to this thread. View it on GitHub:

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. a1c384cd841bc6da2f2805fb4000b3a2e24254d8 Stop blocking when GPG process dies prematurely (RhBug:1746353) -- You are receiving this because you are subscribed to this thread. View it on GitHub:

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. f2c7b420ec92bc976afce907599bba209943f6d7 Stop blocking when GPG process dies prematurely (RhBug:1746353) -- You are receiving this because you are subscribed to this thread. View it on GitHub:

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. 5f583ba5136d94f5189fe2d044c0c215c9a69f7e Stop blocking when GPG process dies prematurely (RhBug:1746353) -- You are receiving this because you are subscribed to this thread. View it on GitHub:

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. bb59f46c2f322ddd5b006e43e31953d9262c8234 Stop blocking when GPG process dies prematurely (RhBug:1746353) -- You are receiving this because you are subscribed to this thread. View it on GitHub:

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. 7730c3f31e73e2ae290f8aab2caee33fca905361 Rename b98ad2d140a924f6794dbff2eb3c842cd79f200e Stop blocking when GPG process dies prematurely (RhBug:1746353) -- You are receiving this because you are subscribed to this thread. View it on GitHub:

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. 3173e9a82f1a7a66264d0e092c1a338be3a1456a Rename 1a1bf9a336294539befd81c6a4519bda2e45f843 Stop blocking when GPG process dies prematurely (RhBug:1746353) -- You are receiving this because you are subscribed to this thread. View it on GitHub:

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. a1a343679f089380af6192f6fa07f73b1e7310e8 Stop blocking when GPG process dies prematurely (RhBug:1746353) -- You are receiving this because you are subscribed to this thread. View it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Parallelize file processing (#1185)

2020-05-05 Thread Michal Domonkos
Good to know! No PR yet, but I'll create one soon-ish and reference this issue in it. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Parallelize file processing (#1185)

2020-04-21 Thread Michal Domonkos
Thanks for the feedback. I also noticed `readFilesManifest()` as being one potential source of problems here. Indeed, with a dirty patch that I'm currently testing out, I got a few random crashes (possibly due to that). However, in those cases where it worked, the build time of a kernel on

Re: [Rpm-maint] [rpm-software-management/rpm] build: prioritize large packages (#1180)

2020-04-21 Thread Michal Domonkos
@dmnks pushed 1 commit. 7ab76d425d3660a3bfc83009f7cd77096bdb8881 fixup! build: prioritize large packages -- You are receiving this because you are subscribed to this thread. View it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] build: prioritize large packages (#1180)

2020-04-21 Thread Michal Domonkos
Good point on the backwards loop; it really shouldn't scream "look ma, reverse loop for no obvious reason, go figure out yourself!". Instead, I'll just make the reverse ordering explicit by simply inverting the `compareBinaries()` function, and push a fixup commit right away. -- You are

Re: [Rpm-maint] [rpm-software-management/rpm] build: prioritize large packages (#1180)

2020-04-20 Thread Michal Domonkos
@pmatilai Fixed and rebased. Note that I changed `RPMTAG_SIZE` to `RPMTAG_LONGSIZE` because I realized the former may not be set if the total size is greater than 32 bits (details [here](https://rpm.org/devel_doc/large_files.html)). -- You are receiving this because you are subscribed to this

Re: [Rpm-maint] [rpm-software-management/rpm] build: prioritize large packages (#1180)

2020-04-20 Thread Michal Domonkos
@dmnks pushed 1 commit. b5700cb7e707b4b38fa431d25f44df0ff7a5a9b2 build: prioritize large packages -- You are receiving this because you are subscribed to this thread. View it on GitHub:

[Rpm-maint] [rpm-software-management/rpm] Parallelize file generation (#1185)

2020-04-20 Thread Michal Domonkos
My preliminary testing shows a promising reduction of build time (with the kernel package) when doing this, but I still have to analyze and understand the code better, to see if it really is safe to do and nothing breaks as a result. -- You are receiving this because you are subscribed to this

Re: [Rpm-maint] [rpm-software-management/rpm] build: prioritize large packages (#1180)

2020-04-14 Thread Michal Domonkos
}/libfoo_light4.so %files heavy1 %{_libdir}/libfoo_heavy1.so %changelog * Mon Mar 2 2020 Michal Domonkos - ``` On my laptop, the total build time is `~1:35s` and `~1:20s` before and after the patch, respectively. Not a huge difference here, but thread utilization is be a bit better now

Re: [Rpm-maint] [rpm-software-management/rpm] Order Packages by size during build (#1045)

2020-04-14 Thread Michal Domonkos
}/libfoo_light4.so %files heavy1 %{_libdir}/libfoo_heavy1.so %changelog * Mon Mar 2 2020 Michal Domonkos - ``` On my laptop, the total build time is `~1:35` and `~1:20` before and after the patch, respectively. Not a huge difference here, but thread utilization is be a bit better now

[Rpm-maint] [rpm-software-management/rpm] build: prioritize large packages (#1180)

2020-04-14 Thread Michal Domonkos
Binary packages come in different sizes and so their build time can vary greatly. Dynamic scheduling, which we currently use for parallel building, is a good strategy to combat such differences and load-balance the available CPU cores. That said, knowing that the build time of a package is

Re: [Rpm-maint] [rpm-software-management/rpm] Add macros for default flags of file extractors. (#557)

2020-02-03 Thread Michal Domonkos
@Conan-Kudo Fair enough. Could you please open an issue for that? And perhaps include additional details, preferably a use case that you encountered in the past that would be easier with this feature? -- You are receiving this because you are subscribed to this thread. Reply to this email

Re: [Rpm-maint] [rpm-software-management/rpm] Auto-enable optimizations for non-rotational disks on Linux (#949)

2020-01-27 Thread Michal Domonkos
dmnks commented on this pull request. > @@ -1415,8 +1467,23 @@ static int rpmtsSetup(rpmts ts, rpmprobFilterFlags > ignoreSet) return 0; } +/* Enable / disable optimizations for solid state disks */ +static void setSSD(int enable) +{ +if (enable) { + rpmlog(RPMLOG_DEBUG,

Re: [Rpm-maint] [rpm-software-management/rpm] Add %alias_provides() as a new "useful generic macro" (#614)

2020-01-22 Thread Michal Domonkos
(Please ignore the "mention" above, I used the wrong link there.) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] "rpmbuild -br --nodeps" returns 11 even though all dependencies are satisfied (#963)

2020-01-22 Thread Michal Domonkos
Note: Based on a chat with @praiskup, a fix (if any) should not happen until mock has fixed (worked around this) itself, otherwise we would run a risk of breaking it. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] "rpmbuild -br --nodeps" returns 11 even though all dependencies are satisfied (#963)

2020-01-22 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-2969273020___ Rpm-maint mailing list

  1   2   >