[Rpm-maint] [rpm-software-management/rpm] Possible deadlock when macro tracing and debug is turned on (#1418)

2020-10-28 Thread Michael Schroeder
This deadlocks for me: ``` rpm -vv --eval '%trace' ``` It hangs because rpmlog() tries to expand `%{?_color_output}^{!?_color_output:auto}` leading to another call to rpmlog(). We could temporarily clear print_expand_trace in the printExpansion() function but I think a better fix would be to

Re: [Rpm-maint] [rpm-software-management/rpm] Possible deadlock when macro tracing and debug is turned on (#1418)

2020-10-28 Thread Michael Schroeder
Maybe it was done because expand_trace is turned on if the macro recursion limit is reached. Hmm. Should printMacro() also use rpmlog? -- 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] Add new rpmExpandThisMacro() public method (#1414)

2020-10-27 Thread Michael Schroeder
Ok, I factored out the common code. I'm not super happy about the naming, though. Comment welcome ;) -- 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] Add new rpmExpandThisMacro() public method (#1414)

2020-10-27 Thread Michael Schroeder
I'll update the patch set after lunch. -- 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/1414#issuecomment-717177932___ Rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Add new rpmExpandThisMacro() public method (#1414)

2020-10-27 Thread Michael Schroeder
So you're suggesting that we remove the argvFree() call in the freeArgs() function? -- 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] Add new rpmExpandThisMacro() public method (#1414)

2020-10-27 Thread Michael Schroeder
@mlschroe pushed 1 commit. 6c96d96a091dd97ab52af44ebb09845e94549bf2 Remove common code from expandMacro() and expandThisMacro() -- You are receiving this because you are subscribed to this thread. View it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Add new rpmExpandThisMacro() public method (#1414)

2020-10-27 Thread Michael Schroeder
I wonder if we should make the interface more sane. I currently made it similar to rpmExpandMacro(), but that was probably a bad idea. The interface is currently return 1 on success and -1 on failure, put string in the obuf pointer. But the straightforward interface would be return string on

Re: [Rpm-maint] [rpm-software-management/rpm] Add new rpmExpandThisMacro() public method (#1414)

2020-10-26 Thread Michael Schroeder
This needs to be connected to python/lua as well. How should the interface look like? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

[Rpm-maint] [rpm-software-management/rpm] Add new rpmExpandThisMacro() public method (#1414)

2020-10-26 Thread Michael Schroeder
You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1414 -- Commit Summary -- * Make comments reflect new macro parsing reality * Move setupArgs() function so that it is next to freeArgs() * Split doExpandThisMacro() from

[Rpm-maint] [rpm-software-management/rpm] Refactor handling of parameterized macro args (#1412)

2020-10-23 Thread Michael Schroeder
This splits of a setupArgs() function that will be also used when we add a new method to expand a specific macro. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1412 -- Commit Summary -- * Split off mbAllocBuf() from

Re: [Rpm-maint] [rpm-software-management/rpm] Fix logic error in grabArgs() (#1411)

2020-10-23 Thread Michael Schroeder
@mlschroe pushed 1 commit. 0809ae46d9445374f8942e462ec4c10321ef8707 Fix logic error in grabArgs() -- You are receiving this because you are subscribed to this thread. View it on GitHub:

[Rpm-maint] [rpm-software-management/rpm] Fix logic error in grabArgs() (#1411)

2020-10-23 Thread Michael Schroeder
If there was a \ at the end of the buffer, the code would return a pointer after the trailing \0 leading to unallocated memory access and weird results in some cases. See commit 817959609b95afe34ce0f7f6c3dc5d7d0d9a8470. You can view, comment on, or merge this pull request online at:

Re: [Rpm-maint] [rpm-software-management/rpm] Fix logic error in grabArgs() (#1411)

2020-10-23 Thread Michael Schroeder
As you wish ;) -- 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/1411#issuecomment-715312258___ Rpm-maint mailing list

Re: [Rpm-maint] [rpm-software-management/rpm] Implement a real stack for parametric macro locals (#1409)

2020-10-23 Thread Michael Schroeder
I just glanced over the pull request, so this might be wrong. But shouldn't you look in the lower levels as well in findEntry? I.e. if you have: ``` %foo() %bar %foo2() %define bar hello \ %foo ``` Does %foo2 still expand to `hello`? -- You are receiving this because you are subscribed to this

Re: [Rpm-maint] [rpm-software-management/rpm] Implement a table-like shortcut to rpm macros in Lua (#1398)

2020-10-21 Thread Michael Schroeder
Sorry, I didn't want to discourage you. I'll open a pull request with that rpmExpandThisMacro() implementation. -- 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] Implement a table-like shortcut to rpm macros in Lua (#1398)

2020-10-19 Thread Michael Schroeder
Regarding the macro call feature: I was going to suggest something like that. Perl, for example, offers both `system(STRING)` and `system(LIST)`. The STRING version uses the shell to do the call, so you get argument splitting and variable expansion. The LIST version does a verbatim call without

Re: [Rpm-maint] [rpm-software-management/rpm] Implement a table-like shortcut to rpm macros in Lua (#1398)

2020-10-14 Thread Michael Schroeder
But then you should change the code so that it does not accept more than one argument. Everything else is not "identical" and does not match the user expectation. Btw, please do not use %quote, this will break if the argument contains an unmatched '}' character. It's much saner to simply

[Rpm-maint] [rpm-software-management/rpm] Treat unparsable macros like undefined macros (#1400)

2020-10-14 Thread Michael Schroeder
This seems to be the intention of the code but it did not work because macro parsing was resumed at the wrong point of the input string. Without this commit, %{} expanded to % instead of %{}. You can view, comment on, or merge this pull request online at:

Re: [Rpm-maint] [rpm-software-management/rpm] Implement a table-like shortcut to rpm macros in Lua (#1398)

2020-10-14 Thread Michael Schroeder
(Hmm, an unmatched '}' will break the expansion anyway, so nevermind about not using %quote.) -- 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] Treat unparsable macros like undefined macros (#1400)

2020-10-14 Thread Michael Schroeder
It's also for stuff like `%{ test }` or `%{:}` or `%?`. But yes, this shouldn't be common. -- 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] Implement a table-like shortcut to rpm macros in Lua (#1398)

2020-10-14 Thread Michael Schroeder
No, this is not about the called macro. My point is with macro calls via rpm.expand, we expand macros first and then split into args. With your new call from lua we already provide the args, so it's not clear if we want expansion or not. Both works, it's just a matter of documentation. -- You

Re: [Rpm-maint] [rpm-software-management/rpm] Allow parametric macros to opt out of option processing (#547) (#1392)

2020-10-14 Thread Michael Schroeder
Btw, is there a need to pass optopt? It's usually used to print an error message for unrecognized options, but in that case the callback is not called anyway. (It *is* called if your option string starts with ':' and there is no argument to an option that needs one, though.) -- You are

Re: [Rpm-maint] [rpm-software-management/rpm] Implement a table-like shortcut to rpm macros in Lua (#1398)

2020-10-14 Thread Michael Schroeder
Oh, you want the arguments in a macro call expanded? I was going to suggest that we should add code to make them stay unexpanded (i.e. double the '%' chars). There's merit in both sides, I guess. -- You are receiving this because you are subscribed to this thread. Reply to this email directly

Re: [Rpm-maint] [rpm-software-management/rpm] Allow parametric macros to opt out of option processing (#547) (#1392)

2020-10-13 Thread Michael Schroeder
I think you mean optopt instead of opterr, because opterr is for configuring getopt()'s error handling. -- 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] Implement a table-like shortcut to rpm macros in Lua (#1398)

2020-10-13 Thread Michael Schroeder
You can easily implement quoting by always surrounding the arguments with 0x1f characters, see splitQuoted() and the %quote macro. -- 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] elfdeps: Generate dependencies on non-executable shared libraries (#1393)

2020-10-12 Thread Michael Schroeder
I agree that it's better to look if there is an interpreter. Note that the patch does not strip away the capability to turn of dependency generation for executables (ET_EXEC) by stripping away the x bit. It only changes the behavior for non-executables (i.e. ET_DYN with no x bit set). --

[Rpm-maint] [rpm-software-management/rpm] Improve version support in expressions (#1388)

2020-10-08 Thread Michael Schroeder
Add stringification for versions and error out for arithmetic operations. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1388 -- Commit Summary -- * Support stringification of versions in the expression parser * Add

Re: [Rpm-maint] [rpm-software-management/rpm] Add support for passing real local arguments to Lua scriptlets (#1383)

2020-10-08 Thread Michael Schroeder
@mlschroe commented on this pull request. > +lua_newtable(L); +if (opts) { + int c, argc = argvCount(args); + +/* glibc uses optind 0 for (re)initializing internal structures, sigh */ +#ifdef __GLIBC__ + optind = 0; +#else + optind = 1; +#endif + while ((c =

Re: [Rpm-maint] [rpm-software-management/rpm] Add support for passing real local arguments to Lua scriptlets (#1383)

2020-10-08 Thread Michael Schroeder
@mlschroe commented on this pull request. > +lua_newtable(L); +if (opts) { + int c, argc = argvCount(args); + +/* glibc uses optind 0 for (re)initializing internal structures, sigh */ +#ifdef __GLIBC__ + optind = 0; +#else + optind = 1; +#endif + while ((c =

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: pass parametric macro options and arguments to Lua natively (#1092)

2020-10-07 Thread Michael Schroeder
I'd love to write: ``` %{lua: opt_z, arg = ...; } ``` i.e pass an argument for every option in the macro definition (using the order specified in the definition). Use nil if the option was not used, 0/1 for options with no argument. -- You are receiving this because you are subscribed to

Re: [Rpm-maint] [rpm-software-management/rpm] Add support for passing real local arguments to Lua scriptlets (#1383)

2020-10-07 Thread Michael Schroeder
@mlschroe commented on this pull request. > /* Lua scripts can change our cwd and umask, save and restore */ cwd = open(".", O_RDONLY); if (cwd != -1) { mode_t oldmask = umask(0); umask(oldmask); pid_t pid = getpid(); + /* Arrange arguments to

Re: [Rpm-maint] [rpm-software-management/rpm] Add support for passing real local arguments to Lua scriptlets (#1383)

2020-10-06 Thread Michael Schroeder
@mlschroe approved this pull request. -- 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/1383#pullrequestreview-502907388___

Re: [Rpm-maint] [rpm-software-management/rpm] Add support for passing real local arguments to Lua scriptlets (#1383)

2020-10-06 Thread Michael Schroeder
Oooh, nice! -- 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/1383#issuecomment-704248771___ Rpm-maint mailing list

Re: [Rpm-maint] [rpm-software-management/rpm] Add API for clone rpmps iterator (func rpmpsiClone) (#1359)

2020-09-18 Thread Michael Schroeder
Usually the C++ Compiler removes the copy creation (see https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization). But yes, I don't see why postincrement needs to be supported, preincrement should be enough. -- You are receiving this because you are subscribed to this thread.

[Rpm-maint] [rpm-software-management/rpm] rpm --delsign changes the arch element of the lead (#1326)

2020-08-07 Thread Michael Schroeder
Judging from commit 3255273ae0fabd03c9738249a29c9c1e15f28f64 which broke this you may not care about this. Opening this issue anyway for documentation purposes: rpm no longer copies over the lead data verbatim when creating or deleting signatures, but recreates it from the header. This does

Re: [Rpm-maint] [rpm-software-management/rpm] Support threading for zstd compression. (#1303)

2020-07-24 Thread Michael Schroeder
I'll implement support in deltarpm and you can port it to drpm, ok? -- 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] Support threading for zstd compression. (#1303)

2020-07-24 Thread Michael Schroeder
Looks good to me, thanks. (Of course the deltarpm and drpm need to be updated now so that they support a ZSTD_THREADED compression type as well.) -- 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] RFE: %undefine_all (#1314)

2020-07-21 Thread Michael Schroeder
_Shudder_. Please use an option flag instead. See for example the discussion in issue #1155 -- 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] Support threading for zstd compression. (#1303)

2020-07-14 Thread Michael Schroeder
$ rpm2cpio kdelibs3-3.5.5-39.i586.rpm | zstd -c --single-thread | wc -c 16307922 $ rpm2cpio kdelibs3-3.5.5-39.i586.rpm | zstd -c -T1 | wc -c 16308523 -- 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] Support threading for zstd compression. (#1303)

2020-07-14 Thread Michael Schroeder
Hmm, I don't think ZSTDMT_compress_advanced_internal is used in out use case, so disregard the comment about the influence of the thread number. (I'm not 100% sure, though, the zstd source code is somewhat cryptic to me.) -- You are receiving this because you are subscribed to this thread.

Re: [Rpm-maint] [rpm-software-management/rpm] Support threading for zstd compression. (#1303)

2020-07-14 Thread Michael Schroeder
Also note that threading mode with one thread (T1) is *not* unthreaded mode. -- 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] Support threading for zstd compression. (#1303)

2020-07-14 Thread Michael Schroeder
But was it identical? Zstd upstream said that it is different. -- 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] Support threading for zstd compression. (#1303)

2020-07-14 Thread Michael Schroeder
I'm also not so sure about the "the multi-threaded output produces the same compressed data no matter how many threads you use" statement, because the block size seems to depend on the number of workers (see ZSTDMT_compress_advanced_internal). -- You are receiving this because you are

Re: [Rpm-maint] [rpm-software-management/rpm] Support threading for zstd compression. (#1303)

2020-07-14 Thread Michael Schroeder
Note that the zstd people *did* say that threaded compression has a different output than unthreaded operation: it compresses a bit worse. So the pull request will break delta rpms. Can you please change the code so that it uses unthreaded mode if there is no 'T' in the compression flags? I.e.

Re: [Rpm-maint] [rpm-software-management/rpm] Cannot import a GPG key with signatures (#1306)

2020-07-10 Thread Michael Schroeder
I guess it can't deal with the ECDSA and EdDSA signatures. -- 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] zstd compression: port to the new API. (#1303)

2020-07-09 Thread Michael Schroeder
You need to recreate the same bytewise identical compression when applying the deltarpm. The parallel compression implementations tend to partition the data and compress the chunks individually, leading to a different result. I haven't checked the zstd implementation, I admit, I just know that

Re: [Rpm-maint] [rpm-software-management/rpm] zstd compression: port to the new API. (#1303)

2020-07-08 Thread Michael Schroeder
You're aware that this breaks delta rpms? -- 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/1303#issuecomment-655579498___

Re: [Rpm-maint] [rpm-software-management/rpm] Add dbus-announce plugin (#1255)

2020-06-17 Thread Michael Schroeder
(Colin, see issue #1124 for a solution using a named pipe) -- 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] Add dbus-announce plugin (#1255)

2020-06-08 Thread Michael Schroeder
@mlschroe commented on this pull request. > +state->logging = 1; + +/* ...don't log test transactions */ +if (rpmtsFlags(ts) & (RPMTRANS_FLAG_TEST|RPMTRANS_FLAG_BUILD_PROBS)) + state->logging = 0; + +/* ...don't log chroot transactions */ +if (!rstreq(rpmtsRootDir(ts),

Re: [Rpm-maint] [rpm-software-management/rpm] Support ed25519 signatures (#1202)

2020-05-26 Thread Michael Schroeder
Thanks for the info. Note that this pull request does not make rpm use some different signature system: it still only supports pgp (RFC4880) signatures. Only very old rpm versions used gpg to verify the signatures, rpm has its own pgp functions since ages. (See also issue #1193 for a discussion

Re: [Rpm-maint] [rpm-software-management/rpm] Support ed25519 signatures (#1202)

2020-05-26 Thread Michael Schroeder
@mlschroe commented on this pull request. > @@ -168,7 +169,8 @@ typedef enum pgpPubkeyAlgo_e { PGPPUBKEYALGO_EC = 18, /*!< Elliptic Curve */ PGPPUBKEYALGO_ECDSA= 19, /*!< ECDSA */ PGPPUBKEYALGO_ELGAMAL = 20, /*!< Elgamal */ -

Re: [Rpm-maint] [rpm-software-management/rpm] Support ed25519 signatures (#1202)

2020-05-26 Thread Michael Schroeder
@mlschroe commented on this pull request. > @@ -168,7 +169,8 @@ typedef enum pgpPubkeyAlgo_e { PGPPUBKEYALGO_EC = 18, /*!< Elliptic Curve */ PGPPUBKEYALGO_ECDSA= 19, /*!< ECDSA */ PGPPUBKEYALGO_ELGAMAL = 20, /*!< Elgamal */ -

Re: [Rpm-maint] [rpm-software-management/rpm] Support ed25519 signatures (#1202)

2020-05-26 Thread Michael Schroeder
@mlschroe commented on this pull request. > @@ -168,7 +169,8 @@ typedef enum pgpPubkeyAlgo_e { PGPPUBKEYALGO_EC = 18, /*!< Elliptic Curve */ PGPPUBKEYALGO_ECDSA= 19, /*!< ECDSA */ PGPPUBKEYALGO_ELGAMAL = 20, /*!< Elgamal */ -

Re: [Rpm-maint] [rpm-software-management/rpm] RFC: support rpm version comparison in expression parser (#1220)

2020-05-14 Thread Michael Schroeder
Yeah, I should read the comments instead of just looking at the "Files Changed" tab... -- 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] RFC: support rpm version comparison in expression parser (#1220)

2020-05-14 Thread Michael Schroeder
How about supporting EVR syntax instead of that rpmvercmp() call? -- 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] RFC: support rpm version comparison in expression parser (#1220)

2020-05-14 Thread Michael Schroeder
Another possibility would be the pythonish/perlish `v"1.2.3"`. -- 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] rpm --eval "%{lua:rpm.interactive()}" does not immediately print the output (#1215)

2020-05-13 Thread Michael Schroeder
This happens because you're in a macro expansion, so all the output is collected and returned to the macro engine. -- 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] Support ed25519 signatures (#1202)

2020-05-08 Thread Michael Schroeder
But when I asked you about that in #1050 you said: "It could be multiple groups or whatever, but certainly not about new algorithms"... -- 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] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Michael Schroeder
(But I admit that this point is moot if util-linux really switches to meson. Systemd is currently not a problem, as it is not needed for building.) -- 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] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Michael Schroeder
No, Panu is right. Rpm being behind python *is* an issue for distribution builders because it introduces a nasty dependency cycle. -- 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] Support ed25519 signatures (#1202)

2020-05-08 Thread Michael Schroeder
Things that need to be discussed: - which signature header tags to (re-)use? (My preference is the gpg tags.) - do we want to add `RPMRC_UNSUPPORTED` for unsupported algorithms/curves? Currently unsupported sigs are reported as bad, which is not nice. - do we want to allow the import of

Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)

2020-05-08 Thread Michael Schroeder
See also issue #887. The hard part is not the build process, but converting all the tests. -- 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] Support ed25519 signatures (#1202)

2020-04-29 Thread Michael Schroeder
Note that this is incomplete: there needs to be another commit to define which tag to use for ed25519 signatures. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

[Rpm-maint] [rpm-software-management/rpm] Support ed25519 signatures (#1202)

2020-04-29 Thread Michael Schroeder
You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1202 -- Commit Summary -- * Support the EdDSA public key algorithm * Support ed25519 signatures in digest_openssl.c * Support ed25519 signatures in digest_libgcrypt.c --

Re: [Rpm-maint] [rpm-software-management/rpm] Don't check source package provides against installed conflicts (#1192)

2020-04-22 Thread Michael Schroeder
@mlschroe approved this pull request. -- 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/1192#pullrequestreview-398143102___

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Signing packages with signify (#1193)

2020-04-22 Thread Michael Schroeder
You mean verification of metadata signatures? Is that what you want to change? For this it would make more sense if rpm offers an API so that it can do the verification. Currently upper layers have to export the keys from the rpmdb, import them into gpg (if they use gpg for this) and then use

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Signing packages with signify (#1193)

2020-04-22 Thread Michael Schroeder
But rpm does not use gpg for signature verification. Using PKCS#7 basically just means a different encoding format for the signature, the crypto libraries would not change at all. It's much pain with no gain. -- You are receiving this because you are subscribed to this thread. Reply to this

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Signing packages with signify (#1193)

2020-04-22 Thread Michael Schroeder
X.509? You mean PKCS#7? I don't think this would be an improvement ;-) -- 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] RFE: Signing packages with signify (#1193)

2020-04-22 Thread Michael Schroeder
I don't understand that comment. Rpm's trust model is identical to the one used in signify. -- 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] RFE: Signing packages with signify (#1193)

2020-04-22 Thread Michael Schroeder
But rpm does not use any "web of trust" concept at all. And RFC 4880 also is not about trust. In rpm a signature is valid if and only if the public key is in the database. I think you're confusing the format with the implementation. -- You are receiving this because you are subscribed to this

Re: [Rpm-maint] [rpm-software-management/rpm] NEVR provides in source package lead to rpmbuild errors (#1189)

2020-04-22 Thread Michael Schroeder
Why is that cured by #1192? It just changes things for conflicts of installed packages. My example was about a build requires being satisfied by a provides of a source package. I think this needs to be fixed in rpmal.c -- You are receiving this because you are subscribed to this thread. Reply

Re: [Rpm-maint] [rpm-software-management/rpm] NEVR provides in source package lead to rpmbuild errors (#1189)

2020-04-22 Thread Michael Schroeder
I wonder if the added provides also can lead to problems if we have a transaction with both source and binary packages. The provides from the source packages must not satisfy the dependencies of the binary packages. Another thing to test would be a spec file that has a BuildRequires to one of

Re: [Rpm-maint] [rpm-software-management/rpm] Self-conflicts and self-obsoletes don't work correctly with --replacepkgs (#1190)

2020-04-22 Thread Michael Schroeder
Oops, wrong 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/1190#issuecomment-617664011___ Rpm-maint mailing list

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Signing packages with signify (#1193)

2020-04-22 Thread Michael Schroeder
Why would we want to use a different format? There's nothing wrong with the pgp signature format. (I totally agree that the gpg code itself is horrible. Fortunately rpm does not use it.) This is like saying we should switch to dpkg's packaging format because it is used by Debian. -- You are

Re: [Rpm-maint] [rpm-software-management/rpm] Self-conflicts and self-obsoletes don't work correctly with --replacepkgs (#1190)

2020-04-22 Thread Michael Schroeder
I wonder if the added provides also can lead to problems if we have a transaction with both source and binary packages. The provides from the source packages must not satisfy the dependencies of the binary packages. Another thing to test would be a spec file that has a BuildRequires to one of

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: Signing packages with signify (#1193)

2020-04-22 Thread Michael Schroeder
You can sign with any tool you like as long as you wrap the result as a pgp signature. I don't see any reason why we should use a different *format* for the signature. (What we should do is support ed25519 though. We currently only support rsa and dsa) -- You are receiving this because you

Re: [Rpm-maint] [rpm-software-management/rpm] Self-conflicts and self-obsoletes don't work correctly with --replacepkgs (#1191)

2020-04-21 Thread Michael Schroeder
duplicate of #1190 caused by github incident. -- 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/1191#issuecomment-617316732___

Re: [Rpm-maint] [rpm-software-management/rpm] Self-conflicts and self-obsoletes don't work correctly with --replacepkgs (#1191)

2020-04-21 Thread Michael Schroeder
Closed #1191. -- 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/1191#event-3257228317___ Rpm-maint mailing list

[Rpm-maint] [rpm-software-management/rpm] Self-conflicts and self-obsoletes don't work correctly with --replacepkgs (#1190)

2020-04-21 Thread Michael Schroeder
`rpm -i --replacepkgs` will not add an erasure element for an identical installed package. This makes the dependency check see the installed package and report an error even though the package will be removed later on. I've stumbled over this in another bug report. I don't mind if it does not

[Rpm-maint] [rpm-software-management/rpm] Self-conflicts and self-obsoletes don't work correctly with --replacepkgs (#1191)

2020-04-21 Thread Michael Schroeder
`rpm -i --replacepkgs` will not add an erasure element for an identical installed package. This makes the dependency check see the installed package and report an error even though the package will be removed later on. I've stumbled over this in another bug report. I don't mind if it does not

[Rpm-maint] [rpm-software-management/rpm] NEVR provides in source package lead to rpmbuild errors (#1189)

2020-04-21 Thread Michael Schroeder
This is a regression caused by commit 75ec16e660e784d7897b37cac1a2b9b135825f25. The provides added to the source rpms will be checked against the dependencies of the installed packages. Because of this you will get an error if you try to build an rpm where the package name matches a conflict of

Re: [Rpm-maint] [rpm-software-management/rpm] Question: the way to check if "load" macro is built-in in a spec file (#1104)

2020-04-20 Thread Michael Schroeder
If you want hacks you can do something like: ``` %if "%{load:/dev/null}" == "" ``` -- 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] RFE: optional one-shot/cached macro expansion (#1155)

2020-04-15 Thread Michael Schroeder
Well, we don't need to allow %global. Anyway, let's move a step back and talk about this issue. This is about one shot macros. Implementation wise this is not hard, it's more a question of syntax. It would be nice to have the following options: - literal: do not expand the macro when using it

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: optional one-shot/cached macro expansion (#1155)

2020-04-15 Thread Michael Schroeder
Crazy thought: we could allow to use %define/%global in the macro file, as those are illegal macro names. I.e. we could allow this: ``` %foo hello %define bar world ``` (rpm internally somewhat rewrites the %foo to %define foo anyway) Then we could also allow ``` %undefine foo ``` which is

Re: [Rpm-maint] [rpm-software-management/rpm] Warn on undefined macro uses in specs (#1170)

2020-04-15 Thread Michael Schroeder
You could also just use some macro to turn it on/off like with the other rpm flags, i.e.: ``` %define _warn_on_undefined_macro_expansion 1 ``` That would make it easy to turn it on for a whole project in OBS. -- You are receiving this because you are subscribed to this thread. Reply to this

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: store a copy of files maked as config in /usr/lib/rpm/config (#1178)

2020-04-14 Thread Michael Schroeder
Regarding doing the copies at install time: The nice thing about having them as normal files in the header is that we get automatic de-dup and refcounting. I.e. we can do a 'rpm -qf ...' to find out the owners of a config file and they get automatically removed if nobody owns them anymore. We

[Rpm-maint] [rpm-software-management/rpm] RFE: store a copy of files maked as config in /usr/lib/rpm/config (#1178)

2020-04-14 Thread Michael Schroeder
If a file is marked as config file, rpmbuild could automatically create a copy and store it in `/usr/lib/rpm/config/first-digest-byte/file-digest`. We can then make use of this to: - allow to display the changes done by the user - use a three-way merge algorithm - handle digest algorithm changes

Re: [Rpm-maint] [rpm-software-management/rpm] Handle manually specified debuginfo package more gracefully (#1177)

2020-04-14 Thread Michael Schroeder
@mlschroe approved this pull request. -- 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/1177#pullrequestreview-392794740___

[Rpm-maint] [rpm-software-management/rpm] ndb: do not mmap the index database read-write all the time (#1176)

2020-04-14 Thread Michael Schroeder
Use read-only mapping for the index databases if the user only requested read-only database access. Also map the xdb database header read-only and only switch to a read-write mapping if an operation is done that needs write access. You can view, comment on, or merge this pull request online at:

Re: [Rpm-maint] [rpm-software-management/rpm] Fix regression causing all ELF files classified as OCaml (#1174)

2020-04-09 Thread Michael Schroeder
@mlschroe approved this pull request. -- 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/1174#pullrequestreview-390727170___

Re: [Rpm-maint] [rpm-software-management/rpm] Ocaml dependency generators running on all ELF files (#1173)

2020-04-09 Thread Michael Schroeder
Of course rpm can do that, you need to put "magic_and_path" in the flags. ``` %__ocaml_flags magic_and_path ``` -- 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] Discussion: spec tag order and side-effects (#1161)

2020-04-08 Thread Michael Schroeder
There is no "new evaluate on declaration thing". Rpm always evaluates macros when it parses lines. How do you think macros like ``` %perl_req Requires: perl = %{perl_version} ``` work? You can also do something like this: ``` %define p0 Patch0: patch.diff %p0 ``` There is no way to get rid of

[Rpm-maint] [rpm-software-management/rpm] Support DSA2 in digest_libgcrypt.c (#1168)

2020-04-08 Thread Michael Schroeder
For DSA2 we need to truncate the hash to the size of the pubkeys Q value. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1168 -- Commit Summary -- * Support DSA2 in digest_libgcrypt.c -- File Changes -- M

Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)

2020-04-07 Thread Michael Schroeder
Btw, what the commit changed was that the Source/Patch arguments are no longer expanded *twice*. They used to be macro expanded when the tag was parsed and then expanded again when the files were used. This issue is not a tag ordering issue at all. -- You are receiving this because you are

Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)

2020-04-07 Thread Michael Schroeder
My 2 cents: I don't see what macro expansion has to do with the free order of spec tags. It's should not surprise anybody that using %name does not work before the "Name:" tag is given. And how is the following different? ``` Patch0: %{foo} %define foo bar.diff ``` This has nothing to

Re: [Rpm-maint] [rpm-software-management/rpm] Sqlite backend's prefix match cannot deal with '%' characters (#1018)

2020-03-24 Thread Michael Schroeder
I learned a bit more about sqlite in another project. Turns out that using a custom match function is much slower than the LIKE version, because of sqlite's LIKE optimization: https://www.sqlite.org/optoverview.html#the_like_optimization So I think we should go back to use LIKE and escape the %

Re: [Rpm-maint] [rpm-software-management/rpm] Sqlite backend's prefix match cannot deal with '%' characters (#1018)

2020-03-24 Thread Michael Schroeder
Reopened #1018. -- 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/1018#event-3159073617___ Rpm-maint mailing list

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add database change notification API (#1124)

2020-03-24 Thread Michael Schroeder
A linux specific way would be to offer some functions around inotify(). We can also try something more generic: We could create a named pipe in /var/lib/rpm. At the start of the transaction we open the pipe O_WRONLY, at the end we simply close the fd. Some other process that wants to be

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add database change notification API (#1124)

2020-03-19 Thread Michael Schroeder
I don't think sqlite notification hooks work for different processes. -- 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 open (and initialize) the entire database at once (#1119)

2020-03-17 Thread Michael Schroeder
Sorry, I haven't had time to have a closer look at this. Things are a bit chaotic here at SUSE with everything being locked down because of the corona virus. But from my glancing over the changes everything looked fine. -- You are receiving this because you are subscribed to this thread.

  1   2   3   4   5   6   >