Handy for debugging and experimenting with macros, in and out of
spec context.
Placed in rpmspec because we don't want readline dependency on main rpm
executable, this is more of a packager tool anyway.
The real Lua interpreter enters interactive mode if no arguments are
passed at all, iff execute was not specified, or explicitly requested.
We have no reason to behave any differently.
We don't want readline dependency in librpmio so need to do this the
hard way: add an optional callback through which rpmlua can supply
it's own readline-aware callback function.
Being able to run stuff easily in rpm context helps developing and debugging
scriptlets and macros too. Supports running one-liner statements from
the cli, regular scripts and an interactive session.
This is placed into a separate executable for, well, separation and
simplicity, but it'll also give us means to link to readline without
dragging that to main rpm dependencies (but that's left for later).
rpm.next_file() is only meaningful at all when there's a backing
function set for the scriptlet, so only expose it at those times.
We shouldn't be touching the rpm namespace at all here, but
it's required for backwards compatibility.
As the nextFileFunc is something that often is not there, this makes
testing for nextFileFunc presence a little more obvious and easy.
No actual functional change.
This screams for a closure, use one. This is not supposed to change
any functionality except, except only make the rpm.next_file() function
available in the context of scriptlets which is the only context it is
meaningful.
Builtins aren't special in >= 4.17 and the less the old special syntaxes
are documented the better.
While at it, point users to expressions and Lua for more complicated tests.
Fixes: #1864
Suppress summary output entirely on --quiet where the summary is wholly
redundant, and non-sensical (as witnessed by the test-case outputs)
at that because the summary title is omitted due to its NOTICE log level.
A build may have warnings without having any errors, lift the warnings
summary out of the rc-condition.
Finally, condense the output a bit, two empty lines at front seems a bit
excessive.
Confusingly, the "RPM build errors" section also includes messages
logged as warnings. That gives the false impression that they somehow
contributed to the actual build failure and therefore were turned into
errors.
This appears to be a historical artifact; when a message passes through
the logging system and is of the priority RPMLOG_WARNING or higher, we
save it in a global buffer (ctx->recs), which is then simply dumped with
rpmlogPrint() in the error summary. This was probably good enough when
the summary was introduced (commit f2efc72, year 2000), as there were
almost no warnings generated by RPM at that time, however as they became
more abundant, the summary code was never revisited.
There are 3 ways to fix this discrepancy:
1) Change the summary's title to "RPM build problems"
2) Remove the summary altogether
3) Don't show warnings in it
Options #1 and #2 would be too disruptive. The error summary needs to
stay as is, for the following reasons:
- While it usually just repeats the last error, not all errors
terminate a build right away, so those can get drown in the output
that follows after. Examples: "File not found" in rpmInstall(), or
macro expansion errors (note: we may have these terminate a build in
the future).
- It makes it immediately obvious that something went wrong when
examining build logs, and the title "RPM build errors" undoubtedly
has become the de-facto text string to search for.
That leaves us with option #3. To further lessen the disruption, do
keep a summary of warnings, but put them under their own heading, and
only show it on build failures. That way, we restrict all the extra
verbosity to error time (as it is now) and don't pollute the output of
otherwise good builds. There may be packages with long-standing
warnings that are not feasible to fix for any reason, and having an
indented block of text resembling "RPM build errors" at the end of every
build would do no good.
Effectively, this commit is just cosmetic - it splits the error summary
into two, without any functional or API changes (apart from two function
additions).
Fixes: #793
This is mainly to place *some* limit on number of files a package may
have. It's unlikely that rpm scales to million files in a package but
that much may actually work, whereas closer to int32 limits we run into
all manner of issues with internal types mismatching and whatnot.
Commit a79d7ae0f0 had two major flaws:
Firstly, it negletted to update the part that copies the data in place to
match the new layout where data lengths are not always equal, and the for
loop would overshoot its bounds on data shorter than maximum.
Secondly, rpmfilesFSignature() would now crash on packages with no IMA
signatures because fi->signaturelengths is not allocated. Take care not
to change API behavior wrt *len return value: set to zero if no
signatures are present.
Avoids having to manually "print()" everything, at the cost of requiring
a "return" which is not really less to type but more natural for
programming, and other benefits likely to follow.
If /etc/passwd or /etc/group was not available during building rpm itself
these ended up empty. This affects builds done later on using rpmbuild.
Resolves: #1838
At least ECDSA and RSA signatures can vary in length, but the IMA code
assumes constant lengths and thus may either place invalid signatures on
disk from either truncating or overshooting, and segfault if the stars are
just so.
Luckily the signatures are stored as strings so we can calculate the
actual lengths at runtime and ignore the stored constant length info.
Extend hex2bin() to optionally calculate the lengths and maximum,
and use these for returning IMA data from the rpmfi(les) API.
Additionally update the signing code to store the largest IMA signature
length rather than what happened to be last to be on the safe side.
We can't rely on this value due to invalid packages being out there,
but then we need to calculate the lengths on rpmfiles populate so there's
not a lot to gain anyhow.
Fixes: #1833
Only, use more descriptive names than the C-side counterparts.
Python has nice facilities for dealing with binary data so return it
as such rather than converting to hex.
Guess this is rebase considered harmful: this should've been in
commit de9cc32b98 but in that fork,
rpmluaCallStringFunction() didn't yet exist so it couldn't be
adjusted there, but merging the PR broke the build.
We pop it to print its contents, but we forgot to push an empty
print buffer afterwards. This makes a difference as a newline
is not automatically added in print statements if a buffer is used.
When trying to achieve a fully reproducible build process for an
OS image timestamps are a major source of variance. The RPM
database contains two fields in package header records that
are relevant here:
- RPMTAG_INSTALLTIME which is an explicit timestamp indicating
when the package was installed.
- RPMTAG_INSTALLTID which is an opaque value represending the
transaction ID under which a package was installed but in terms
of internal implementation is also a timestamp.
This change allows the presence of the SOURCE_DATE_EPOCH
environment variable, commonly used to override timestamps in
build systems, to institute an "override time" mode in which
values for RPMTAG_INSTALLTID and RPMTAG_INSTALLTIME become
predicatble.
If a package has multiple %transfiletriggerpostun triggers, any one
of them matching would cause all of them to run, due to disconnect
in the intel gathering stage: we'd gather all the headers with matching
files into a lump, and then add any postun triggers found in them,
but this loses the triggering file information and causes all postuns
to run.
The triggers need to be added while looping over the file matches,
like runFileTriggers() does. Doing so actually simplifies the code.
These should really be unified to use the same code, but leaving
that exercise to another rainy day.
Commit 717a3f7ecf changed Lua scriptlet
arguments from numbers to strings, and claimed that Lua will handle
this automatically so nobody will notice a thing. Not so, Lua only
converts automatically when doing so is unambiguous, such as doing
math. In comparison Lua cannot know which kind of comparison we want,
and rightly refuses to convert. Thus, the commit broke any Lua
scriptlets doing `if arg[2] > 1 then ... end` style comparisons.
As the whole rpmluav variable API is gone now, we can't just revert
the commit. Adding a preamble to the scriptlet to convert the args
to numbers may be hackish, but its a far lesser evil than bringing the
internal variable API back. Kudos to Michael Schroeder for the idea.
Fixes: #1790
Doing the function lookup with calls to lua_getfield is dangerous
because the lookup might trigger an __index function that may
contain an error. This results in the lua library calling abort()
as no exception handler is set.
So change the code to do the lookup via a pcall(). Also do the
string conversion with a pcall() because tostring is also not
safe.
Rather than laborously call tostring() in Lua, use the C-side equivalent
of luaL_tostring(). This was new as of Lua 5.2, which explains why the
original version from 2004 did things the hard way.
Also fixes a stack leak from not popping "tostring" function after use.
Panu Matilainen