Re: [Rpm-maint] [rpm-software-management/rpm] Document all tags (#1384)

2020-10-06 Thread Panu Matilainen
Nobody will disagree.

The problem is that there's a mountain of undocumented stuff in the last twenty 
years, and that there's no place to put new stuff into. For example, 
documenting %artifact would essentially writing docs on *all* %files features 
first to have a meaningful place to put it into. That just doesn't happen, and 
hence this limbo goes on.

-- 
You are receiving this 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/1384#issuecomment-704699507___
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-06 Thread Panu Matilainen
@pmatilai commented on this pull request.



> @@ -382,7 +382,7 @@ static ssize_t fdWrite(FDSTACK_t fps, const void * buf, 
> size_t count)
 
 static int fdSeek(FDSTACK_t fps, off_t pos, int whence)
 {
-return lseek(fps->fdno, pos, whence);
+return (lseek(fps->fdno, pos, whence) == -1 ? -1 : 0);

Mm, sorry for missing this earlier, was just about to merge when I spotted 
something strange with the parenthesis: enclosing it all in parenthesis makes 
no sense and doesn't help readability either, it should be:

```
return (lseek(fps->fdno, pos, whence) == -1) ? -1 : 0;
```

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


[Rpm-maint] [rpm-software-management/rpm] Document all tags (#1384)

2020-10-06 Thread Miroslav Suchý
There is a lot feature in rpm which has literally no other documentation than 
source code:
 OrderWithRequires
 %artifact
 %readme
 VCS
 meta
 and a very likely a bunch of others.
 
I believe that all of this and actually every feature, tag, or modifier in 
available in the SPEC file should be documented on the rpm.org site.



-- 
You are receiving this 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/1384___
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-06 Thread malmond77
@malmond77 pushed 1 commit.

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


-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1381/files/4124cee2d134b3fca4b215e8cc7068b8eda0d3a0..fd36e8c25c93eab627824281886e5a5b9e695255
___
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-06 Thread Panu Matilainen
https://lua.programmingpedia.net/en/tutorial/4475/variadic-arguments applies, 
eg to walk through arguments:

> $ ./rpm --define "foo(..) %{lua: t = {...}; print('nargs '..rpm.expand('%{#}: 
> ')); for i, v in ipairs(t) do print(i..':'..v..' '); end}" --eval "%foo 5 4 3 
> 2 -z"
nargs 5: 1:5 2:4 3:3 4:2 5:-z 

The question mark(s) revolve around what to do with options when present in 
normal parametric macros. The current behavior is to pass them to Lua as 
arguments, and %{#} macro carries the number of non-option arguments so you can 
calculate how many option arguments there are.

> $ ./rpm --define "foo(z:) %{lua: t = {...}; print('nargs '..rpm.expand('%{#}: 
> ')); for i, v in ipairs(t) do print(i..':'..v..' '); end}" --eval "%foo 5 4 3 
> 2 -z7"
nargs 4: 1:-z7 2:5 3:4 4:3 5:2

Another possibility would be not passing options as arguments to Lua except 
when custom option processing is selected, which would *kinda* make sense, but 
also seems limiting.

-- 
You are receiving this 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-704290557___
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 Panu Matilainen
Seems this outgrew the initial description somewhat...

The last push makes the new `%foo(..)` syntax for skipping option processing 
actually usable, the earlier version from a few hours ago had several problems. 

-- 
You are receiving this 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-704258334___
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-06 Thread Panu Matilainen
Implemented in PR #1383, but not specific to Lua despite the PR title.
Simply pass '..' as the option string, eg `%foo(..)`. This will skip option 
processing in rpm, and any options that a macro might receive are simply passed 
as raw string arguments.

-- 
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#issuecomment-704249870___
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] RFE: pass parametric macro options and arguments to Lua natively (#1092)

2020-10-06 Thread Miro Hrončok
Do you have an example of usage? It's hard to find for me in 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/issues/1092#issuecomment-704199944___
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-06 Thread Panu Matilainen
Implemented now as a part of #1383. 

There are various ways this could be done, what's implemented now is that %{**} 
macro, ie the unprocessed arguments to the macro, are passed to Lua as 
arguments. The processed per-option macros are still accessible via 
rpm.expand() of course. Feedback 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/issues/1092#issuecomment-704171945___
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-06 Thread Panu Matilainen
Please leave out the return codes documentation because that only makes the 
broken -2 return documented and stand out for as something special and 
supported for Fseek() when it can happen for pretty much anything for all sorts 
of arbitrary reasons. I think we should instead fix all those cases to return 
-1 with errno set instead (but that is obviously beyond the scope of this PR)

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