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

2020-10-23 Thread Panu Matilainen
Merged #1411 into master.

-- 
You are receiving this 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#event-3913752156___
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 Panu Matilainen
Thanks :)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1411#issuecomment-715316965___
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 Panu Matilainen
@pmatilai commented on this pull request.



> @@ -948,7 +948,7 @@ grabArgs(MacroBuf mb, const rpmMacroEntry me, const char 
> * se,
splitQuoted(, s, " \t");
free(s);
 
-   cont = ((*lastc == '\0' || *lastc == '\n') && *(lastc-1) != '\\') ?
+   cont = *lastc == '\0' || (*lastc == '\n' && *(lastc-1) != '\\') ?

Care to add parenthesis around `*lastc == '\0'` to make it a bit more obvious?

-- 
You are receiving this 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#pullrequestreview-515618314___
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 warnings from set but unused, variables in macro.c and rpmlua.c (#1410)

2020-10-23 Thread Panu Matilainen
Merged #1410 into master.

-- 
You are receiving this 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/1410#event-3913626616___
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 Panu Matilainen
Updated to preserve the scoped macro behavior, ie the example case now expands 
to `hello` again.
Just wondering now whether all these macro tables actually make sense - with 
these semantics we could probably get by with just two tables for global and 
non-global macros. It's the argv stuff that needs an actual stack, the macro 
table is a stack in itself...

-- 
You are receiving this 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-715280048___
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 Panu Matilainen
Oh and FWIW, I've various other doubts and reservations about this 
implementation so there's a good chance that it'll end up trashed (or at least 
drastically revised) anyhow. If getting an actual definition and some testcases 
of how macro scoping is supposed to work comes out of it, that alone would make 
it well worth the trouble :smile: 

The little language hygienist in me thinks non-global macros should be local to 
the scope defined in, ie what's implemented in this PR, and communication 
between macros should be options and arguments instead. There seems to be (from 
this and past discussions) to be varying opinions about that though.

If the general consensus is that the existing scoping should be kept I guess I 
can live with that, but then we need to define what %undefine does: does it 
simply act on the local-most define, regardless of where in the local-global 
axle that happens to be in? It's simple enough as a rule, but I find macros 
undefining allegedly local macros from others somewhat ugly.

-- 
You are receiving this 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-715248421___
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 Panu Matilainen
Right, I forgot that user-defined scoped macros follow different rules from 
automatic macros as it is. Which is of course undocumented behavior, like most 
of all this...

What's implemented here is a strict local stack for parametric macros, so no, 
it no longer expands to `hello` unless you change the `%define` to `%global`. 
So I guess this would be more drastic change than I initially thought - and I 
admit this isn't all that thoroughly thought out in the first place, hence RFC 
only.

Breaking things is not a goal here, eliminating buggy and ambiguous behavior 
is. But I suppose we should really start by defining and documenting the 
expected behavior wrt scopes and all...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1409#issuecomment-715216459___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[Rpm-maint] [rpm-software-management/rpm] Fix warnings from set but unused, variables in macro.c and rpmlua.c (#1410)

2020-10-23 Thread Panu Matilainen
macro.c: In function ‘mbopt’:
macro.c:895:19: warning: unused variable ‘me’ [-Wunused-variable]
  895 | rpmMacroEntry me = mb-me;
  |   ^~

rpmlua.c: In function ‘fd_seek’:
rpmlua.c:985:22: warning: unused variable ‘mode’ [-Wunused-variable]
  985 | static const int mode[] = {SEEK_SET, SEEK_CUR, SEEK_END};
  |  ^~~~

The former is actually unused, the latter should be used.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Fix warnings from set but unused, variables in macro.c and rpmlua.c

-- File Changes --

M rpmio/macro.c (1)
M rpmio/rpmlua.c (2)

-- Patch Links --

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


Re: [Rpm-maint] [PATCH] Remove set, but unused, variables in macro.c and rpmlua.c

2020-10-23 Thread Panu Matilainen

On 10/23/20 1:58 PM, Mark Wielaard wrote:

macro.c: In function ‘mbopt’:
macro.c:895:19: warning: unused variable ‘me’ [-Wunused-variable]
   895 | rpmMacroEntry me = mb->me;
   |   ^~

rpmlua.c: In function ‘fd_seek’:
rpmlua.c:985:22: warning: unused variable ‘mode’ [-Wunused-variable]
   985 | static const int mode[] = {SEEK_SET, SEEK_CUR, SEEK_END};
   |  ^~~~
---
  rpmio/macro.c  | 1 -
  rpmio/rpmlua.c | 1 -
  2 files changed, 2 deletions(-)

diff --git a/rpmio/macro.c b/rpmio/macro.c
index 800861418..1edcb39e6 100644
--- a/rpmio/macro.c
+++ b/rpmio/macro.c
@@ -892,7 +892,6 @@ static void splitQuoted(ARGV_t *av, const char * str, const 
char * seps)
  static int mbopt(int c, const char *oarg, int oint, void *data)
  {
  MacroBuf mb = data;
-rpmMacroEntry me = mb->me;
  char *name = NULL, *body = NULL;
  
  /* Define option macros. */


Oops, seems my local builds had a leftover override to disable these 
warnings. This is indeed an unused variable...



diff --git a/rpmio/rpmlua.c b/rpmio/rpmlua.c
index 8314a296c..2ea985e6e 100644
--- a/rpmio/rpmlua.c
+++ b/rpmio/rpmlua.c
@@ -982,7 +982,6 @@ static int fd_flush(lua_State *L)
  
  static int fd_seek(lua_State *L)

  {
-static const int mode[] = {SEEK_SET, SEEK_CUR, SEEK_END};
  static const char *const modenames[] = {"set", "cur", "end", NULL};
  FD_t *fdp = checkfd(L, 1);
  int op = luaL_checkoption(L, 2, "cur", modenames);



...but this is actually points out a bug, it should be instead:

@@ -988,7 +988,7 @@ static int fd_seek(lua_State *L)
 int op = luaL_checkoption(L, 2, "cur", modenames);
 off_t offset = luaL_optinteger(L, 3, 0);

-op = Fseek(*fdp, offset, op);
+op = Fseek(*fdp, offset, mode[op]);

 if (op < 0 || Ferror(*fdp)) {
return luaL_error(L, "%s: seek failed: %s",

I'll fixup and commit, thanks!

- Panu -

___
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-22 Thread Panu Matilainen
FWIW, the macro argument argv needs similar treatment but I'm out of steam for 
the day...

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


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

2020-10-22 Thread Panu Matilainen
Mixing up local stack and global data never was such a hot idea, as locals 
could get trapped between globals and not freed at appropriate times etc.

This clears the semantics wrt that, fixing a long-standing expected failure in 
the test-suite. Another semantics change is that you can no longer undefine a 
locally defined macro, which eliminates the ambiguity of what should happen 
on %undefine if both global and local macros exist. As such, theres of 
course some potential for breakage too.

Besides clear semantics, this should speed up parametric macro execution as we 
no longer need to huff and puff the global table up and down on entry and exit. 
Furthermore, this paves way to using a hash for the macro table.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Separate macro table from the context
  * Implement a real stack for parametric macro locals

-- File Changes --

M build/rpmfc.c (2)
M rpmio/macro.c (180)
M rpmio/rpmmacro.h (1)
M tests/rpmmacro.at (3)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/1409.patch
https://github.com/rpm-software-management/rpm/pull/1409.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/1409
___
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 preliminary support for dynamic built-in macro registration (#1406)

2020-10-22 Thread Panu Matilainen
Pushed a bit more elaborate/sophisticated version...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1406#issuecomment-714317770___
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 Panu Matilainen
> I'll try to get it into a submittable state tomorrow or so.

...except that nope, didn't see a way to achieve this with a reasonable effort. 
Doesn't necessarily mean there isn't one, but I lost my appetite for now. I 
might revisit at some later time, but if somebody wants to pick up the pieces 
in the meanwhile, feel free.

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


[Rpm-maint] [rpm-software-management/rpm] Add preliminary support for dynamic built-in macro registration (#1406)

2020-10-21 Thread Panu Matilainen
Add the necessary infra to pass and carry dofoo/parse function pointers
in macro entries, define our basic built-in primitives at macro
initialization and adapt the built-in calling logic in expandMacro()
to look up the info from macro entry instead of the builtin table.

This has various nice benefits, such as allowing simple testing whether
rpm supports a given primitive by testing whether said macro is defined.
It also paves way for later implementing various spec constructs as
actual macros instead of the confusing pseudo-macros they are now.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Add preliminary support for dynamic built-in macro registration

-- File Changes --

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

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/1406.patch
https://github.com/rpm-software-management/rpm/pull/1406.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/1406
___
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 Panu Matilainen
No worries. I got tangled in the argument/option parsing/passing recursion - 
I've a feeling the mb->args vs argument macros and all isn't quite right as it 
is, and just ran out of steam for now. So I was actually kinda hoping you'd say 
that...

Meanwhile, here's a related step towards making builtins more accessible: #1406 

-- 
You are receiving this 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-713513326___
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 Panu Matilainen
Closed #1398.

-- 
You are receiving this 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#event-3902168598___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Mark man pages with RPMFILE_MAN and info pages with RPMFILE_INFO (#1404)

2020-10-20 Thread Panu Matilainen
Closed #1404.

-- 
You are receiving this 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/1404#event-3897185281___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Mark man pages with RPMFILE_MAN and info pages with RPMFILE_INFO (#1404)

2020-10-20 Thread Panu Matilainen
Sorry but no: a bitfield does not scale for classifying individual file 
formats, and that's not what the virtual file attributes are for. 

A `file` magic string is attached to most files (RPMTAG_FILECLASS extension) 
which can be used for further identification, but it's not terribly reliable as 
the libmagic strings evolve over time. MIME classification should be more 
usable when we get that done (#1096)

-- 
You are receiving this 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/1404#issuecomment-71277___
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 Panu Matilainen
>  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.

@mlschroe , it's not so much that I disagree, it's just that it's easier said 
than done :sweat_smile: 
Took a good part of the afternoon but I have it more or less working now, I'll 
try to get it into a submittable state tomorrow or so.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1398#issuecomment-712172840___
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 Panu Matilainen
Now that the table version exists, I don't feel any particular need to hang on 
to the multi-argument auto-join thing. The convenience of not having to 
manually and tediously construct the string was the point of that, but since 
*that* can be avoided with the table syntax, eliminating the string catenation 
neatly eliminates the problem of quoting - it's simply up to the caller. I'll 
update that part.

As for builtins, I know. One possibility would be hiding the different calling 
convention in the call, so eg `rpm.expand("%{uncompress:...}")` becomes just 
`macros.uncompress(...)`, but I actually think it'd be saner to expose them via 
an entirely different "namespace" because builtins can't be overridden, so 
they'd need annoying extra checks in the macros table. Maybe 
`builtin.uncompress(...)` or something.

The macro argument expansion is a stickier issue because it's a rather 
fundamental part of the parametric macro calling convention. If different means 
of calling the same macro can behave differently, it can create strange 
situations (and bugs). I think. Note that I've been toying with an idea of some 
sort of "native Lua macro" concept that would by definition bypass the normal 
%{1} etc argument processing and just call the other macro as a normal Lua 
function, but that's just a very vague idea at this point.

-- 
You are receiving this 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-711905618___
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 Panu Matilainen
Rebased again to include the other new Lua/macro stuff and a new snapshot build 
at https://copr.fedorainfracloud.org/coprs/pmatilai/rpm-snapshot/build/1712012/

-- 
You are receiving this 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-711862781___
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: add some syntax to specify a macro should not fail when used with a flag not declared to rpm argument parsing (#547)

2020-10-19 Thread Panu Matilainen
Closed #547 via #1392.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/547#event-3892043975___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Get rid of the Lua variable wrapper API (#1402)

2020-10-19 Thread Panu Matilainen
Okay, guess nobody's complaining about getting rid of piles of dusty-moldy 
code...

-- 
You are receiving this 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/1402#issuecomment-711818068___
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 Panu Matilainen
After some more consideration, renamed to `macros`. This is more in line with 
our other globals (sources, patches) and leaves room for iteration options 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/1398#issuecomment-711811478___
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 Panu Matilainen
@pmatilai pushed 1 commit.

81e1068bf1193bceb0ca8c6abb3be95c250eb3ee  Implement a table-like shortcut to 
rpm macros in Lua


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1398/files/252c9360f6572836f903c05470f7ced5c09e57e8..81e1068bf1193bceb0ca8c6abb3be95c250eb3ee
___
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 Panu Matilainen
Updated to have function calls only accept a single string or table. 

-- 
You are receiving this 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-712094055___
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 Panu Matilainen
@pmatilai pushed 1 commit.

7d1d772be5f2cdf8d4ecb0a0dcc79514ab1c9658  Implement a table-like shortcut to 
rpm macros in Lua


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1398/files/ce550fb8d6cbcb82dcb6cb695496c7fe8886024b..7d1d772be5f2cdf8d4ecb0a0dcc79514ab1c9658
___
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 Panu Matilainen
On a related note on the builtins: I've been thinking about turning the 
builtins into parametric macros, or at least blur the difference considerably 
(and allow dynamic registering of builtins). The syntax differs a bit and the 
calling convention much more, so it's not entirely straightforward/obvious how 
to proceed there. If they're technically merged into regular macros, the 
macros/builtins split wouldn't probably make much sense.

-- 
You are receiving this 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-712048854___
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-19 Thread Panu Matilainen
Merged #1392 into master.

-- 
You are receiving this 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#event-3892043957___
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-19 Thread Panu Matilainen
Since there's no further feedback...

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


Re: [Rpm-maint] [rpm-software-management/rpm] Get rid of the Lua variable wrapper API (#1402)

2020-10-19 Thread Panu Matilainen
Merged #1402 into master.

-- 
You are receiving this 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/1402#event-3891995092___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[Rpm-maint] [rpm-software-management/rpm] Get rid of the Lua variable wrapper API (#1402)

2020-10-15 Thread Panu Matilainen
See commits for details, the main point is getting rid of an unmaintained, 
undocumented and unloved intermediate Lua variable API. As an example, the 
sources/patches table manipulation is converted to use native Lua operations, 
and is actually less code and easier to understand that the helper 
layer.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Consolidate librpmbuild Lua code to one place
  * Add function for fetching the underlying Lua state from rpmlua
  * Convert sources/patches table manipulation to native Lua API
  * Lose the internal Lua variable API

-- File Changes --

M build/Makefile.am (4)
M build/parsePreamble.c (29)
M build/rpmbuild_internal.h (11)
M build/spec.c (15)
A build/speclua.c (51)
M rpmio/rpmlua.c (331)
M rpmio/rpmlua.h (26)

-- Patch Links --

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


Re: [Rpm-maint] [rpm-software-management/rpm] Get rid of the Lua variable wrapper API (#1402)

2020-10-15 Thread Panu Matilainen
@pmatilai pushed 2 commits.

0a2f461c9194f6c18090f6efea783506e81f80e3  Convert sources/patches table 
manipulation to "native" Lua API
5881539aee1888156a4316d5be941a4ba26af38a  Lose the internal Lua variable API


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1402/files/fed41651c16c6ccdd3d5feb559aef096585f3879..5881539aee1888156a4316d5be941a4ba26af38a
___
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-15 Thread Panu Matilainen
Okay, iteration is a fair point. The catch is that we don't support that at 
all, and I'm not sure we ever will.

-- 
You are receiving this 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-709229056___
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-15 Thread Panu Matilainen
Updated:
- macro call arguments are auto-quoted if passed as a table
- more docs on the behavior
- build the strings on Lua side and use Lua rpm.expand() call consistently for 
all macro expansions

-- 
You are receiving this 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-709058344___
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-15 Thread Panu Matilainen
@pmatilai pushed 1 commit.

252c9360f6572836f903c05470f7ced5c09e57e8  Implement a table-like shortcut to 
rpm macros in Lua


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1398/files/8c52d03979b303c318e5086462dc7c6706d2d1c8..252c9360f6572836f903c05470f7ced5c09e57e8
___
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-15 Thread Panu Matilainen
The plural form could be argued, yes. I considered it, but somehow it seems 
weird to me in this context, in particular the dot-syntax (eg 
`macros.with('foo')`). Do you have some concrete reason why `macro['_libdir']` 
seems objectionable to you? I'm just curious, as I actually find that more 
natural than the plural form, but I'd be hard-pressed to explain *why* 
:sweat_smile: 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1398#issuecomment-708995157___
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 Panu Matilainen
Regarding the auto-quotation behavior, I think we could leave that up to the 
caller, the Lua table syntax lends itself to this nicely:

```
res = macro.foo(1, 2, 3)
res = macro.foo({1, 2, 3})
```

In the first case, no automatic quotation is done so it's *literally* 
equivalent of joining the arguments with " " and tossing to rpm.expand() so 
there's no if's or buts about deviation in behavior. In the second case the 
syntax nicely hints towards quotation, and it has room for other enhancements 
via further arguments.

-- 
You are receiving this 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-708503862___
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 Panu Matilainen
@pmatilai approved this pull request.

Nice spotting, thanks!



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1400#pullrequestreview-508206977___
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 Panu Matilainen
This is starting to spin out of scope...

This PR is not about changing parametric macro semantics at all, it's about 
making them more accessible from Lua, and basically I think results need to be 
identical between `rpm.expand('%foo [...])` and `macro.foo([...])` or everybody 
will go crazy. Which is why I'm starting to think the automatic quoting is a 
bad idea, because it causes a deviation, and where there's one... it's easy to 
end up with more, whether due to side-effect pileup or otherwise.

We "just" changed the macro arguments to be expanded in 4.14 and it took 
multiple attempts to get the worst kinks out, I'm not all that eager to 
experiment in that area but if people want to discuss that, please open a 
separate ticket.

-- 
You are receiving this 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-708300274___
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 Panu Matilainen
Updated:
- rename the global `m` table to `macro`, it's indeed better for readability
- implement undefine via nil assignment
- automatically quote parametric macro arguments when called as Lua function
- rebased
- new build of this state at 
https://copr.fedorainfracloud.org/coprs/pmatilai/rpm-snapshot/build/1706906/

-- 
You are receiving this 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-708256809___
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 Panu Matilainen
@pmatilai pushed 1 commit.

495252a69443f1987990404aa8b211d0f6bc2148  Implement a table-like shortcut to 
rpm macros in Lua


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1398/files/58990c5b5be41fbb9fa6ae3815c6bf561a719086..495252a69443f1987990404aa8b211d0f6bc2148
___
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 Panu Matilainen
> 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.

Hmm. I fail to see the problem here, it's just a shortcut for building that 
string yourself, ie these two should be equal:

```
res = rpm.expand('%foo'..' '..opt..' '..arg1..' '..arg2)
res = macro.foo(opt, arg1, arg2)
```

We could of course have the latter understand other forms too, such as passing 
(opt, arg) tables (which again are just automatically flattened to the actual 
macro string).

-- 
You are receiving this 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-708347919___
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 Panu Matilainen
Merged #1400 into master.

-- 
You are receiving this 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#event-3875857202___
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 Panu Matilainen
Ah but it's just for the empty %{} case, which shouldn't be all that common, 
initially thought it covered other undefined stuff too.

-- 
You are receiving this 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-708311835___
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 Panu Matilainen
It's also old... that assignment traces back all the way to the initial 
addition of the current macro system in 1998 (commit 
94f5fbeec363059ca9eb986ee294ffcdf20bcb04)

-- 
You are receiving this 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-708308721___
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 Panu Matilainen
Oh fun.

I wonder how many spec oddities ("just how many :cursing_face: percents do I 
need to escape this..." etc) are explained by this... 

-- 
You are receiving this 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-708305652___
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 Panu Matilainen
But in the function call, we just catenate the args into a string that gets 
passed plain old rpmExpand(), so if one method expands them and the other 
doesn't, you can get quite different results. Which doesn't seem sane.

-- 
You are receiving this 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-708278572___
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 Panu Matilainen
@pmatilai pushed 1 commit.

5125725009f5ad50adf5a574b9e9f2fac16af13b  fixup! Wrap getopt() usage into 
internal helper


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1392/files/359b380a026b35d8f9fe27c66a20d272437dc6e5..5125725009f5ad50adf5a574b9e9f2fac16af13b
___
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 Panu Matilainen
Oh, another good point. I probably had some vague idea about letting the 
callback handle errors if it wants, but it wasn't all that carefully thought 
out as you can see :sweat_smile:

I'll drop optopt from being passed, the current implementation doesn't need it 
and this is a private helper function so we can always just add it back if it 
becomes necessary. Just realized it's also missing RPM_GNUC_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/1392#issuecomment-708273973___
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 Panu Matilainen
Calling a parametric macro as a function vs traditional rpm.expand() needs to 
behave identically as the *called* macro will have no idea about any of this. 
Auto-quoting is of course already on a slippery slope.

-- 
You are receiving this 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-708262086___
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 Panu Matilainen
Fixed to pass optopt around instead of opterr.

-- 
You are receiving this 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-708228238___
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 Panu Matilainen
Yeah, thanks for spotting. Will fix.

-- 
You are receiving this 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-708172511___
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 Panu Matilainen
Yup. The reason it's not there now is that from wherever I had this idea it 
might prevent macro expansion in said arguments, and somehow never got around 
to check what it actually did :roll_eyes:  (I'm getting old, it's just three 
years since I added that thing...)

Now actually checking, yeah always quoting the args is quite clearly the right 
thing to do for this.

-- 
You are receiving this 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-708171844___
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 Panu Matilainen
Other random remarks of the day:
- We could of course put it into rpm namespace, and macro-heavy users can 
declare their own shortcut, eg `m = rpm.macro; m._libdir = "foo"`, but then if 
every Lua macro starts with that, we've failed somewhere
- This doesn't enable *anything* new, it's all just for convenience. And as 
such, all this could be also implemented in pure Lua instead. Doing that might 
open some other possibilities, OTOH keeping things in one place and one 
language has other benefits.
- I realized this is missing the mapping for Lua native deletion, ie `m[key] = 
nil` to undefine. Will add in a later version.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1398#issuecomment-707708538___
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 Panu Matilainen
Could of course call the table `macro`to make it blindingly obvious what that 
is, although I do think the context makes it quite clear anyhow. It's not like 
rpm macros ever were nice or readable to begin with 
:stuck_out_tongue_winking_eye: 

Macros are by far the most accessed thing from rpm Lua so I think sheer 
convenience should be high on priorities.

-- 
You are receiving this 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-707669189___
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 Panu Matilainen
It stops being nice and short if we put it into the rpm namespace :-/ 

Unlike a generic Lua library extension, rpm owns the environment in which these 
things run so I don't see a reason we couldn't maximise the convenience. Too 
bad `%` is not a legitimate character in Lua names... OTOH, `_` is and could be 
used, but underscores tend to hint at something you shouldn't touch, which is 
not the case here.

-- 
You are receiving this 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-707657758___
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 Panu Matilainen
https://copr.fedorainfracloud.org/coprs/pmatilai/rpm-snapshot/ has pre-built 
binaries for Fedora, updated manually once/twice a week. Usually those are 
strictly from rpm git master but it's not like I can't make exceptions... 
https://copr.fedorainfracloud.org/coprs/pmatilai/rpm-snapshot/build/1705701/ 
has this PR included (this also includes the native option/argument stuff from 
last week of course)

-- 
You are receiving this 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-707647304___
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 Panu Matilainen
See the docs + test cases in the commit for details, if something isn't covered 
then do ask.

There's ample potential for bikeshedding here (eg what to call the global 
table), should it do some sort of auto-quoting for empty strings as arguments 
etc.

Tagging @hroncok @nim-nim @mlschroe @jasontibbitts for past interest/activities 
in this area, feel free to invite more. 

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


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

2020-10-13 Thread Panu Matilainen
Add rpm macro context as a global table-like entity named m for
typing convenience into the Lua environment.

Support basic access with table indexing syntaxes (m[k] and m.k),
undefined macros return nil here. As a specialty, parametric macros
are returned as native callable variadic Lua functions, arguments
are converted to strings.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Implement a table-like shortcut to rpm macros in Lua

-- File Changes --

M doc/manual/lua.md (22)
M rpmio/rpmlua.c (72)
M tests/rpmmacro.at (18)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/1398.patch
https://github.com/rpm-software-management/rpm/pull/1398.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/1398
___
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: add variable named scoping to rpm (#1150)

2020-10-12 Thread Panu Matilainen
Coming across this again - nope. Understanding what happens where and when 
across the boundary between macros and build scriptlets is hard enough as it 
is, adding namespaces and scopes would only make it so much worse. 

Judging by the examples given, the idea is to better support multiple different 
projects from a single spec.
The basic rpm design is that a single spec represents a single software 
project, although that content can be divided across sub-packages for various 
well-known reasons. I believe that is a sane and sound principle, and we 
shouldn't add features to the contrary.

-- 
You are receiving this 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/1150#issuecomment-707128466___
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] Autogenerate source archive decompression dependencies (#1396)

2020-10-12 Thread Panu Matilainen
Yup, it's not a new idea, we've even had a ticket for it but that's probably 
gotten lost in the jump to GH.

I had a PoC that threw sources at %{uncompress:...} and grabbed the result up 
to the first space, which kinda works but of course has the limitation of not 
supporting executables with whitespace in the name (dunno if we care...), but 
also has the issue of whining unnecessarily on spec parse (non-build) where 
sources are not present. It probably needs a bit of API work to make the 
required stuff meaningfully available. Incidentally I was just looking around 
this neighborhood last week or so when adding Lua bindings for rpmio files: rpm 
doesn't currently know how to convert a result from rpmFileIsCompressed() into 
a Fopen() mode for that compression type...

-- 
You are receiving this 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/1396#issuecomment-707094153___
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-12 Thread Panu Matilainen
@nim-nim : 

One shouldn't expect `nil == false` any more than one would expect `"yes" == 
true`, although both sides *evaluate to* true, ie `("yes" and true)` *is* true. 
The language documentation is quite explicit about this, and this has 
wonderfully little to do with rpm or the interface it provides.

Now, there are no clear concise examples provided, so I can only assume some of 
this confusion comes from expecting rpm.expand() on conditionals to evaluate 
somehow specially, but such evaluation *is not possible*. Rpm macro expansion 
is a *string processor* which simply produces a string of zero or more 
characters according to its own rules (think printf() on steroids), any 
interpretation of the returned string is solely up to the user. If you expect 
something else and additionally have misunderstandings about Lua language 
fundamentals, I'm sure it's going to be a painful experience.  I could've 
clarified this anytime if you had just asked. Also, adding separate API to 
return a nice little boolean whether a macro is defined or not was a matter of 
like 15min of work. All these years and nobody thought to ask for such a simple 
thing!

I was hoping for some constructive feedback on the newly added things that are 
intended to help that very case, including discussion about usage scenarios 
with the specific Lua semantics in mind, but instead I get the same old whining 
about how everything is awful (which sure gets tiresome after all these years), 
quite clearly without so much as a glance to look at what's being done to 
improve things. 

I'm not particularly proud of the blown fuse on Friday, but not everything is 
rpm's fault.

-- 
You are receiving this 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-707076354___
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 Panu Matilainen
And here's the buildroot policy approach: #1395

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1393#issuecomment-707023565___
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-12 Thread Panu Matilainen
> What I objected here is exposing false instead of nil when something is unset.

But there's no such thing in the PR linked to this item at all! That's what's 
so frustrating to me here and why I've been urging you to look at what was 
actually implemented for this ticket: 
https://github.com/rpm-software-management/rpm/commit/67abf72ef57e58251271f5b218f867357d78a4e0

"opts" table always exists so you don't need to test *that* against nil each 
and every time, and beyond that you get nil's for undefined options, and 
strings for defined (empty vs non-empty depending on whether it takes an 
argument or not). The other part is "arg" table (also always existing) where 
you get leftover arguments as a native Lua sequence, accessible with arg[n] and 
count with #arg. 

Other improvements in this area are in the works and some already done, but 
that's beyond the scope here.


-- 
You are receiving this 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-707141799___
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: add variable named scoping to rpm (#1150)

2020-10-12 Thread Panu Matilainen
Closed #1150.

-- 
You are receiving this 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/1150#event-3866708604___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Generate requires for "pure" ELF DSO's regardless of executable bit (#1394)

2020-10-12 Thread Panu Matilainen
This is RFC only as it's not clear we actually want this particular behavior, 
there might be better ways to achieve the goal of not having a system full of 
non-executable files with executable 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/1394#issuecomment-707001388___
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 Panu Matilainen
A different kind of approach to the issue could be continuing to require 
executable bit for requires generation, but have a brp-script strip the x-bits 
from all ET_DYN files that are not actually executable. eu-elfclassify could 
probably be used for that...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1393#issuecomment-706985092___
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 a build root policy for removing executable bits from shared libr… (#1395)

2020-10-12 Thread Panu Matilainen
@pmatilai pushed 1 commit.

d276158ec495c5ac919b95a7bf82d7d5fa946da9  Add a build root policy for removing 
executable bits from shared libraries


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1395/files/4e16ec582ebf511013f689f7f8bb6839ca3db448..d276158ec495c5ac919b95a7bf82d7d5fa946da9
___
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 a build root policy for removing executable bits from shared libr… (#1395)

2020-10-12 Thread Panu Matilainen
@pmatilai pushed 1 commit.

4e16ec582ebf511013f689f7f8bb6839ca3db448  Add a build root policy for removing 
executable bits from shared libraries


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1395/files/b76f58803e61ef3a825f622c7c61566372b6a4dd..4e16ec582ebf511013f689f7f8bb6839ca3db448
___
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 Panu Matilainen
> Specifically you may want to lookup
is_executable () and is_program (), is_library () and is_shared () for
some of the tricky corner cases

Truly :laughing: 

Also interesting material in the linked email-discussion in 
https://sourceware.org/legacy-ml/libc-alpha/2015-03/msg00541.html

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1393#issuecomment-707035168___
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 Panu Matilainen
I agree with @mikhailnov this seems to be a somewhat strange way to go about 
this. Maybe it's been the path of least disruption for adding a distro-specific 
patch, but I think for upstreaming purposes the logic of this all needs 
reconsidering.

This breaks a fairly fundamental and long-standing principle of requires only 
being added to executables, so if you want to disable dependency tracking for a 
file you just chmod a-x it. For a long, long time this was the only means of 
affecting dependency generation on per-file basis. OTOH in those simpler days 
we also didn't have ELF executables masquerading as ET_DYN. Honoring the x-bit 
for one but not the other would only seem to make things inconsistent to me, 
especially as an increasing number of *executables* are ET_DYN these days, so 
they'll end up getting their requires extracted whether x mode bit is set or 
not.

This also breaks anything overriding __elf_* dependency generation in a spec, 
but maybe that's not as common as I wouldn't thought (doesn't seem to be any 
cases in Fedora, shockingly). 

Those breakages will need to be considered and at the very least noted when 
changing such behavior.

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


[Rpm-maint] [rpm-software-management/rpm] Add a build root policy for removing executable bits from shared libr… (#1395)

2020-10-12 Thread Panu Matilainen
…aries

Rpm has traditionally used executable bit on files to determine whether
requires for that file should be generated, but the downside is that we
have systems full of executable files that cannot actually be executed.
When available, use eu-elfclassify to determine files that are pure,
non-executable shared objects and remove executable bits from them
as a buildroot policy. This preserves the traditional behavior wrt
dependency generation but gets rid of the unwanted executable bits.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Add a build root policy for removing executable bits from shared libraries

-- File Changes --

M platform.in (2)
M scripts/Makefile.am (4)
A scripts/brp-elfperm (13)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/1395.patch
https://github.com/rpm-software-management/rpm/pull/1395.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/1395
___
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 Panu Matilainen
Alternative version based around PT_INTERP submitted as #1394 for 
reference/discussion.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1393#issuecomment-706989909___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[Rpm-maint] [rpm-software-management/rpm] Generate requires for "pure" ELF DSO's regardless of executable bit (#1394)

2020-10-12 Thread Panu Matilainen
ELF ET_DYN files can be shared libraries, executable files or both.
Requiring shared libraries that cannot actually be executed (or segfault
when you do so) is dumb, but rpm has traditionally required executable
bit to be set for requires to be generated.

Change the definition of executable to mean files that actually 
*can*
be executed, ie those with PT_INTERP, and only require executable bit
to be set for requires-dependencies generation on those. In other words,
pure shared libraries will have requires generated regardless of their
permission, but executable files can disable that by disabling the on-disk
executable bit.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Generate requires for pure ELF DSOs regardless of 
executable bit

-- File Changes --

M tools/elfdeps.c (9)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/1394.patch
https://github.com/rpm-software-management/rpm/pull/1394.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/1394
___
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 Panu Matilainen
Yup, but as many/most executables these days are in fact ET_DYN... For example, 
on my system there are 1686 ELF files in /bin/, and of those only 52 are 
ET_EXEC.

-- 
You are receiving this 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-706958737___
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 Panu Matilainen
After consulting the dog [*]:

The problem here is that we're trying to classify a hermaphrodite entity into 
one of two sexes. ET_EXEC is clear, but ET_DYN can be either an executable, a 
dynamic shared library *or both*. Until we embrace this fact, we'll get it 
wrong half of the time. 

So we need to stop trying to decide what *it is* and instead ask it what it's 
*capable of*, and act accordingly.
libmagic doesn't know nearly enough to handle this, so the logic needs to live 
inside elfdeps or we need to enhance the classifier somehow (wouldn't be a bad 
thing at all but perhaps out of scope here). Which means a split on the .attr 
level likely isn't going to be meaningful.

If we want to preserve the behavior where executables can disable dependency 
generation by stripping x, we need to come up with a new way of defining an 
executable. Given the nature of modern ELF, I think the only meaningful way is 
to draw the line at: regardless of it's possible other capabilities, does it do 
something if executed? Which AIUI in technical terms comes down to: does it 
have PT_INTERP? elfdeps looks that info up as it is, but it's not wired in a 
meaningful way at the moment.

[*] A running joke in the team, walking the dog has proven to be an excellent 
way of problem solving, but this only really holds for our older dog, called 
Wizard :smile:

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1393#issuecomment-706936121___
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-09 Thread Panu Matilainen
Merged #1383 into master.

-- 
You are receiving this 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#event-3859368672___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Do not fail if there is no "$temp"/res.* file (#1391)

2020-10-09 Thread Panu Matilainen
Ok. Just put that rationale into the commit message and I'm fine with it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1391#issuecomment-706171388___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Do not fail if there is no "$temp"/res.* file (#1391)

2020-10-09 Thread Panu Matilainen
The all-important question "why?" is unanswered in the commit message.

What's the scenario where this happens? I'm not that familiar with the 
debuginfo stuff, but on the outset it looks like something failed if no res.* 
files were created...

-- 
You are receiving this 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/1391#issuecomment-706141333___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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

2020-10-09 Thread Panu Matilainen
Macros might want to pass along options meant for others while perhaps 
modifying some of them, without exposing it all to users.

Have - as the parametric macro opts string disable all options 
processing in rpm, allowing the macro to handle the raw argument list as they 
place.

Fixes: #547

The first two commits are infrastructure pre-requisites.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Wrap getopt() usage into internal helper
  * Dont muck with parametric macro arguments of cli defines
  * Allow parametric macros to opt out of option processing (#547)

-- File Changes --

M doc/manual/macros.md (3)
M lib/poptALL.c (2)
M rpmio/Makefile.am (2)
M rpmio/macro.c (84)
A rpmio/rgetopt.c (44)
M rpmio/rpmlua.c (41)
M rpmio/rpmmacro_internal.h (4)
M tests/rpmmacro.at (12)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/1392.patch
https://github.com/rpm-software-management/rpm/pull/1392.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/1392
___
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 Fseek for offset > 2GiB (#1381)

2020-10-09 Thread Panu Matilainen
Hmm, for some reason CI is refusing to run for this. I'll open a separate PR 
for this, there doesn't seem to be any way to force it through here. No clue...

-- 
You are receiving this 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/1381#issuecomment-706021393___
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 Lua bindings for rpm version objects and io streams (#1380)

2020-10-09 Thread Panu Matilainen
Since there are no comments...

-- 
You are receiving this 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/1380#issuecomment-706086548___
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 Lua bindings for rpm version objects and io streams (#1380)

2020-10-09 Thread Panu Matilainen
Merged #1380 into master.

-- 
You are receiving this 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/1380#event-3859370428___
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-09 Thread Panu Matilainen
Thanks for the review.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1383#issuecomment-706086342___
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-09 Thread Panu Matilainen
Closed #1092 via 67abf72ef57e58251271f5b218f867357d78a4e0.

-- 
You are receiving this 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#event-3859368773___
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-09 Thread Panu Matilainen
Sigh. *Obviously* nil is not *equal to* false, any more than, say, None and 
False in Python. It would be one bizarre language if they were!

Point out concrete problems in the pull-request, or shut up.

-- 
You are receiving this 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-706078696___
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 Fseek for offset > 2GiB (#1381)

2020-10-09 Thread Panu Matilainen
Merged via #1390, no idea why this wasn't running the CI. Anyway, thanks again.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1381#issuecomment-706027988___
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 Fseek for offset > 2GiB (#1381)

2020-10-09 Thread Panu Matilainen
Closed #1381.

-- 
You are receiving this 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/1381#event-385610___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Make fdSeek return 0 on success, -1 on error (#1390)

2020-10-09 Thread Panu Matilainen
Merged #1390 into master.

-- 
You are receiving this 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/1390#event-3858886028___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[Rpm-maint] [rpm-software-management/rpm] Make fdSeek return 0 on success, -1 on error (#1390)

2020-10-09 Thread Panu Matilainen
This code eliminates a false positive failure when the destination position is 
 2GiB. This is done by changing the contract for `Fseek`. Now it returns 
`0` on success instead of an `int` offset. Care should be used to interpret the 
result as there is a difference in semantics between the POSIX `fseek(2)`. 
Existing code is correct: negative results are still failures.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Make fdSeek return 0 on success, -1 on error

-- File Changes --

M rpmio/rpmio.c (2)

-- Patch Links --

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


Re: [Rpm-maint] [rpm-software-management/rpm] rpmbuild generates srpm with invalid spec file name (#1386)

2020-10-08 Thread Panu Matilainen
Thanks for reporting, we'll look into it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1386#issuecomment-705979947___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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

2020-10-08 Thread Panu Matilainen
Merged #1388 into master.

-- 
You are receiving this 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#event-3858526116___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


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

2020-10-08 Thread Panu Matilainen
@pmatilai approved this pull request.

Nice, thanks!



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1388#pullrequestreview-505375459___
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 Fseek for offset > 2GiB (#1381)

2020-10-08 Thread Panu Matilainen
@pmatilai approved this pull request.

Third time the charm... Thanks for the patch and perseverance! :sweat_smile: 



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1381#pullrequestreview-505374447___
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-08 Thread Panu Matilainen
Oh, looking closer:

> @nim-nim wrote
> [...]
> exist because nil is not the same as false or empty

Yes, nil is not same as empty. It however very explicitly is same as false, 
quoting https://www.lua.org/manual/5.4/manual.html#2.1:
> Both nil and false make a condition false; they are collectively called false 
> values. Any other value makes a condition true. 

It doesn't get much more clearer than that. If you've assumed otherwise then 
that's your headache. If you look closer, this PR specifically *relies* on the 
fundamental language behavior of empty meaning true and nil being false. I'm 
not aware of anything in rpm assuming otherwise, but if there was that'd simply 
be a bug that needs fixing.

-- 
You are receiving this 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-705566832___
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-08 Thread Panu Matilainen
And none of us here would have the slightest clue as to what those fragments 
are supposed to be doing and in what context. As I'm sure you know perfectly 
well, the devil is in the details.

If you're not interested in testing and reviewing *this* implementation that's 
fine, just don't come complaining about it later then.

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


[Rpm-maint] [rpm-software-management/rpm] Tag documentation updates (#1387)

2020-10-08 Thread Panu Matilainen
Organize the stuff a little and fill in blanks
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Fix RPMTAG_SUGGESTVERSION and -FLAGS info, theyre not extensions
  * Organize tag documentation to rough tag groups for some sanity
  * Supply tag numbers for special/signature/digest tags where missing

-- File Changes --

M doc/manual/tags.md (430)
M lib/rpmtag.h (4)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/1387.patch
https://github.com/rpm-software-management/rpm/pull/1387.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/1387
___
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-08 Thread Panu Matilainen
@nim-nim, if there's a concrete problem with how testing for option presence is 
handled here, lets hear it out. To me it seems to work exactly like one would 
expect it to, but sorry ponies not included.

-- 
You are receiving this 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-705485732___
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-08 Thread Panu Matilainen
The Lua native arguments have to match those of non-Lua macros, otherwise 
everybody goes crazy.

For more advanced use there will be that option to let the macro do its own 
processing.

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


  1   2   3   4   5   6   7   8   9   10   >