Re: [Rpm-maint] [rpm-software-management/rpm] Disable implicit database creation on read-only handle (#1443)

2020-11-19 Thread Michael Schroeder
The backends are pretty different, so I don't think it's reasonable to demand 
that they all behave the same.
For ndb, you should open the Packages.db read-only but Index.db read-write. 
With that you get exactly what this pull request is about, i.e. disabling the 
implicit database creation.

-- 
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/1443#issuecomment-730231102___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Disable implicit database creation on read-only handle (#1443)

2020-11-18 Thread Michael Schroeder
The ndb index is opened rw so that rpm can regenerate missing/outdated index 
tables.

-- 
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/1443#issuecomment-729688226___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Warn and fall back to dummy database on unknown database backend config (471b7be)

2020-11-18 Thread Michael Schroeder
Ok, I may be a bit dense here, but: what exactly does the commit guard? The 
only thing it seems to do is disabling autoprobing of the database if there is 
a unknown database backend config, but why is this a bad thing?

I.e. why would it fallback to bdb?

-- 
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/commit/471b7be4bd5cc7f245f9aa00c7784a7056e439b7#commitcomment-44294491___
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 special conditional syntaxes from builtin macros (#1421)

2020-11-09 Thread Michael Schroeder
I'm not super happy about the lua change, but I guess everybody builds rpm with 
lua support enabled so that the missing error generation will not matter much.

-- 
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/1421#issuecomment-723977595___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[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 revert commit 
7f220202f20c69d6f3fd957325cdbe692bbabedd. It's weird that printExpansion() uses 
rpmlog, but printMacro() does not. Also, the line is printed with multiple 
rpmlog calls, leading to `D:` being spread into the output.

The commit does not include a rationale, so it's hard to tell why this was 
changed in the first place.

-- 
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/1418___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/issues/1418#issuecomment-717833573___
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 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:
https://github.com/rpm-software-management/rpm/pull/1414#issuecomment-717260763___
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 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 mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/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:
https://github.com/rpm-software-management/rpm/pull/1414#issuecomment-717171232___
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 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:
https://github.com/rpm-software-management/rpm/pull/1414/files/91d60615dc967fb4ebd90b05101a389795b2b306..6c96d96a091dd97ab52af44ebb09845e94549bf2
___
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 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 success, NULL on 
failure.

-- 
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-717090028___
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 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:
https://github.com/rpm-software-management/rpm/pull/1414#issuecomment-716487117___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[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 expandMarco()
  * Split mbCreate() function from doExpandMacros()
  * Add new rpmExpandThisMacro() public method

-- File Changes --

M rpmio/macro.c (311)
M rpmio/rpmmacro.h (16)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/1414.patch
https://github.com/rpm-software-management/rpm/pull/1414.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/1414
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[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 expandMacro()
  * Split setupArgs() function from grabArgs()
  * Simplify grabArgs() usage

-- File Changes --

M rpmio/macro.c (88)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/1412.patch
https://github.com/rpm-software-management/rpm/pull/1412.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/1412
___
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 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:
https://github.com/rpm-software-management/rpm/pull/1411/files/83aca0a579a86d19ca84a6a322e6069a06ae7ff9..0809ae46d9445374f8942e462ec4c10321ef8707
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[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:

  https://github.com/rpm-software-management/rpm/pull/1411

-- Commit Summary --

  * Fix logic error in grabArgs()

-- File Changes --

M rpmio/macro.c (2)
M tests/rpmmacro.at (5)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/1411.patch
https://github.com/rpm-software-management/rpm/pull/1411.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/1411
___
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 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
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1409#issuecomment-715202404___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/pull/1398#issuecomment-713382429___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 any expansion.

Now I just need to convince you that:
- you should drop that misleading autojoin feature and just accept one optional 
argument which can either be a string or a table
- you should add a `rpmExpandThisMacro(rpmMacroContext mc, const char *n, 
ARGV_t args)` function which can be used to expand macro `n` with the provided 
args without needing the rpmExpand arg hackery. Note that this call would not 
expand the arguments.

Btw, what about builtins? They currently cannot be accessed.

-- 
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/1398#issuecomment-711883941___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 append/prepend that 0x1f 
character even if it somewhat breaks abstraction.

-- 
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/1398#issuecomment-708334228___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[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:

  https://github.com/rpm-software-management/rpm/pull/1400

-- Commit Summary --

  * Treat unparsable macros like undefined macros

-- File Changes --

M rpmio/macro.c (1)
M tests/rpmmacro.at (5)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/1400.patch
https://github.com/rpm-software-management/rpm/pull/1400.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/1400
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/pull/1398#issuecomment-708335319___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/pull/1400#issuecomment-708327537___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 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/1398#issuecomment-708264463___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 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/1392#issuecomment-708262363___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1398#issuecomment-708257629___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/pull/1392#issuecomment-707994114___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/pull/1398#issuecomment-707990875___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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

-- 
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/1393#issuecomment-706952463___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[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 error handling for versions in expressions

-- File Changes --

M rpmio/expression.c (15)
M tests/rpmmacro.at (8)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/1388.patch
https://github.com/rpm-software-management/rpm/pull/1388.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/1388
___
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 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 = getopt(argc, args, opts)) != -1) {
+   char key[2] = { c, '\0' };
+   if (c == '?' || strchr(opts, c) == NULL) {
+   rpmlog(RPMLOG_ERR, _("Unknown option %c in %s(%s)\n"),
+   (char)optopt, name, opts);
+   lua_pop(L, 2);

oh wait, it also pops the script. Ignore 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/1383#discussion_r501566277___
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 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 = getopt(argc, args, opts)) != -1) {
+   char key[2] = { c, '\0' };
+   if (c == '?' || strchr(opts, c) == NULL) {
+   rpmlog(RPMLOG_ERR, _("Unknown option %c in %s(%s)\n"),
+   (char)optopt, name, opts);
+   lua_pop(L, 2);

Shouldn't that pop just one element?

-- 
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-504573607___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1092#issuecomment-704832591___
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 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 appear as a local arg[n] table in the script */
+   char *s = rstrscat(NULL, argvp ? "arg = {...}\n" : "", script, NULL);

argvp can not be NULL so you might want to drop the test. (The rest of the code 
already assumes that it is not NULL.)

-- 
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-503662862___
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 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___
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 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
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1359#issuecomment-694781781___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[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 not seem to work for the arch element, which is set to the 
architecture of the host where rpm --delsign is called.

Oh, I just saw that rpmLeadFromHeader() has a FIXME comment about that that 
references RhBug:717898

-- 
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/1326___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/pull/1303#issuecomment-663449659___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/pull/1303#issuecomment-663438048___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/issues/1314#issuecomment-662072704___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/pull/1303#issuecomment-658039886___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1303#issuecomment-658036765___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/pull/1303#issuecomment-658032466___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/pull/1303#issuecomment-658032043___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1303#issuecomment-658026374___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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. initialize `threads` with 0 instead of -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/pull/1303#issuecomment-658021442___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/issues/1306#issuecomment-656772125___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 this was 
the problem with parallel bzip2/xz compression.

-- 
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-656002046___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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___
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 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:
https://github.com/rpm-software-management/rpm/pull/1255#issuecomment-645250342___
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 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), "/"))
+   state->logging = 0;
+
+/* Don't open */
+if (!state->logging || state->bus)
+   return RPMRC_OK;
+
+if (lstat("/run/systemd/system/", ) == 0) {
+if (S_ISDIR(st.st_mode)) {

Pardon my ignorance, but why is this depending on some systemd directory? Does 
dbus need systemd?

-- 
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/1255#pullrequestreview-426476154___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 about different signature systems)

-- 
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/1202#issuecomment-634037280___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 */
-PGPPUBKEYALGO_DH   = 21/*!< Diffie-Hellman (X9.42) */
+PGPPUBKEYALGO_DH   = 21,   /*!< Diffie-Hellman (X9.42) */
+PGPPUBKEYALGO_EDDSA= 22/*!< EdDSA */

It's now also in the commit message ;)

-- 
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/1202#discussion_r430381333___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 */
-PGPPUBKEYALGO_DH   = 21/*!< Diffie-Hellman (X9.42) */
+PGPPUBKEYALGO_DH   = 21,   /*!< Diffie-Hellman (X9.42) */
+PGPPUBKEYALGO_EDDSA= 22/*!< EdDSA */

I added it to the header file, I hope that's also ok

-- 
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/1202#discussion_r430378716___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 */
-PGPPUBKEYALGO_DH   = 21/*!< Diffie-Hellman (X9.42) */
+PGPPUBKEYALGO_DH   = 21,   /*!< Diffie-Hellman (X9.42) */
+PGPPUBKEYALGO_EDDSA= 22/*!< EdDSA */

I don't know why this is not accepted yet. The draft is by Werner Koch, the gpg 
upstream. It's the value gpg uses when you ask it to create a ed25519 pubkey 
(you need the --expert --full-gen-key options for this).

gpg with EDDSA support is released since some years, so I don't see how the 
value can change in the future.

-- 
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/1202#discussion_r430316926___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/pull/1220#issuecomment-628682647___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/pull/1220#issuecomment-628650459___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/pull/1220#issuecomment-628647876___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/issues/1215#issuecomment-627852393___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/pull/1202#issuecomment-625769798___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-625726930___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-625719009___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 unsupported pubkeys? We currently do not 
allow that, my preference is to keep it that way.

Bonus questions:

- what is RPMRC_NOTTRUSTED?
- what is `sinfo->sigalgo`? It does not seem to be set anywhere.

-- 
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/1202#issuecomment-625704348___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/pull/1209#issuecomment-625694952___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/pull/1202#issuecomment-621251757___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[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

-- File Changes --

M rpmio/digest.h (3)
M rpmio/digest_beecrypt.c (2)
M rpmio/digest_libgcrypt.c (130)
M rpmio/digest_nss.c (2)
M rpmio/digest_openssl.c (121)
M rpmio/rpmpgp.c (45)
M rpmio/rpmpgp.h (27)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/1202.patch
https://github.com/rpm-software-management/rpm/pull/1202.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/1202
___
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 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___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 gpg for 
verification.

But we're hijacking this issue about signify by discussing something completely 
different. Could you please open another 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/1193#issuecomment-617742461___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1193#issuecomment-617726007___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/issues/1193#issuecomment-617723867___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/issues/1193#issuecomment-617701734___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1193#issuecomment-617694555___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1189#issuecomment-617686841___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 
the packages it builds. For example, gcc.spec might have a `BuildRequires: gcc`.

-- 
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/1189#issuecomment-617664388___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 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/1193#issuecomment-61766___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 
the packages it builds. For example, gcc.spec might have a `BuildRequires: gcc`.

-- 
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-617650646___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1193#issuecomment-617641451___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[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 get 
fixed, I opened this issue just to make this problem known.

-- 
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___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[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 get 
fixed, I opened this issue just to make this problem known.

-- 
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___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[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 an installed package.

I.e.:
```
error: Failed build dependencies:
bash <= 2.0.4-21 conflicts with (installed) setup-2.8.71-2.fc20.noarch
```

-- 
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/1189___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/issues/1104#issuecomment-616423526___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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
- global: put macro in global namespace
- expand: expand macro right away
- once: cache expanded macro (this issue)

So %global is %define plus the global + expand flags.

Macro names can't start with a `-`, so we could make use normal options:
```
%global foo bar
%define -g -x foo bar
```

As next step can can discuss how we support this in the macro files ;)

-- 
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/1155#issuecomment-614169509___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 something I wanted to have since quite some time.

The downside is of course that people will start to try to use %if statements, 
because the macro file looks too much like a spec file.

-- 
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/1155#issuecomment-614012836___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1170#issuecomment-614010307___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 can opt to have them as ghosts in the header and do some magic at install 
time, but I'm not sure if it's worth the trouble as config files tend to be 
small. 

-- 
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/1178#issuecomment-613447480___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[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 more gracefully

To support this, we just need to change the build part. No incompatibilities 
arise.

-- 
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/1178___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[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:

  https://github.com/rpm-software-management/rpm/pull/1176

-- Commit Summary --

  * ndb: also copy the mapped pointer when keeping a slot
  * ndb: do not map the index databases read-write all the time
  * ndb: do not map xdbs header read-write all the time
  * ndb: unmap xdbs header when closing the xdb database
  * Add an index sync call at the end of a database rebuild
  * ndb: make rpmxdbWriteHeader a void function

-- File Changes --

M lib/backend/ndb/glue.c (11)
M lib/backend/ndb/rpmidx.c (8)
M lib/backend/ndb/rpmidx.h (2)
M lib/backend/ndb/rpmxdb.c (67)
M lib/rpmdb.c (1)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/1176.patch
https://github.com/rpm-software-management/rpm/pull/1176.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/1176
___
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 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___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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:
https://github.com/rpm-software-management/rpm/issues/1173#issuecomment-611485340___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 that initial expansion. The question is whether 
we should go back to expanding the source/patch tags twice for compatibility 
reasons. Even if it's an undocumented and unclean feature that wasn't intended 
that way-

(The downside of expanding multiple times is that it is not easy to have a 
literal '%' character in the patch 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/issues/1161#issuecomment-611201614___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[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 rpmio/digest_libgcrypt.c (6)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/1168.patch
https://github.com/rpm-software-management/rpm/pull/1168.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/1168
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1161#issuecomment-610474749___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 do with the order of the tags.

I'd *hate* if rpm would insist on some specific order, though.

-- 
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/1161#issuecomment-610317827___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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 % and _ characters.


-- 
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#issuecomment-603164781___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


  1   2   3   4   5   6   >