--xml is only really useful for diagnostics, and for that purpose in
particular, showing "(unknown)" text instead of the tag number
for unknown tags is just offensively dumb. No more!
so it can be configured from the spec file
Also move the dir beside the %buildsubdir as %{buildsubdir}-SPECPARTS so
it doesn't pollute the %buildsubdir.
Resolves: #2532
The error handling of these Lua functions is wrong in so many ways I
wont list them all here, but eg. rpm.execute() tries to find an
strerror() string for an exit code of a process, returns a waitpid()
error with code 0 and string "success" and rpm.redirect2null() always
returns a failure despite success and never any meaningful error code.
The latter probably did the right thing when it was in lposix.c but
the pushresult() and pusherror() versions in rpmlua.c are rather
different.
To sort the mess, handle the actual error code checking at call site
and the pushfoo() functions do just that: push the result on the stack
and nothing else. Add some test-cases to go.
Fixes: #2528
The code to autodetect x86 CPU model runs the cpuid instruction after
setting up 1 in eax. This gives the processor signature back in eax
which encodes the model number.
As per Intel Application Note 485 and AMD publication #25481, when
deriving model, we should look at both the base model in eax[7:4] and
the extended model in eax[19:16]. However current code is only looking
at base model and this causes some newer CPUs like Icelake(Model 0x6a)
to be detected wrongly as Pentium 3(Model 0x0a).
Note that this code is only exercised when rpm is built as 32-bit
binary because all of this is within a `#if defined(__i386__)`.
Because of this misdetection on Icelake, `setarch x86_64 rpm --showrc`
has `pentium3` as the `installed arch` instead of the expected `x86_64`.
It doesn't have `x86_64` as one of the `compatible archs` as expected.
Attempting to install a x86_64 rpm with `setarch x86_64 rpm -i` is
failing with `is intended for a different architecture` errors.
```
ARCHITECTURE AND OS:
build arch : i386
compatible build archs: pentium3 i686 i586 i486 i386 noarch fat
build os : Linux
compatible build os's : Linux
install arch : pentium3
install os : Linux
compatible archs : pentium3 i686 i586 i486 i386 noarch fat
compatible os's : Linux
```
Fix the code to also consider extended model and extended family when
applicable. The implementation is similar to the one in the linuxi
kernel.
References:
https://www.scss.tcd.ie/~jones/CS4021/processor-identification-cpuid-instruction-note.pdfhttps://www.amd.com/system/files/TechDocs/25481.pdfhttps://elixir.bootlin.com/linux/v6.3.6/source/arch/x86/lib/cpu.c#L19Fixes: #2535
Added in Fedora in 2011 to allow to %define _hardened_build 1 in one's
specfile and have all the necessary gcc and ld flags configured in the
common cases.
See also rhbz#728974 and FESCO ticket 563 (https://pagure.io/fesco/issue/563)
Users are not supposed to meddle with this. So it really should not go
into /etc.
Use the DATADIR from dbus-1 and not our own install prefix.
Resolves: #2474
Back in 1997, commit be0b90359b added a
sanity check for --rebuilddb operation, skipping headers which lack
some basic tags. Name, version and release are real requirements for
packages, but checking for buildtime is odd, and plain wrong.
Yes, we expect that to be present in packages built by rpm, but that's
not used for any processing and certainly is not required for a package
to be installable. And if it can be installed then it can't be
right to throw it away when rebuilding, leaving untrackable orphan
files in the process.
It is also documented as informational and optional by LSB. While
severely outdated, it is right on this account.
Fixes: #2527
Commit a213101bc3 changed %_smp_build_ncpus
into a parametric macro, but this breaks common usage via the Lua macros
table as parametric macros are returned as closures rather than the
expanded value.
This seems like a design flaw of the macros table, but as an immediate
remedy for the breakage, add another layer of indirection to revert
%_smp_build_ncpus back to a non-parametric macro.
Fixes %constrain_build macro in Fedora, which ironically is made obsolete by
the change that (unintentionally) broke it.
Use tables where they make sense, group builtins by category that
can be linked to, add version introduced where relevant. In addition,
some awkward/misleading wordings fixed.
Another bit lost in the cmake transition: plugin linkage to librpm and
librpmio. In rpm itself this doesn't really matter because the running
process supplies the necessary symbols but it's a different story when eg
a Python process uses dlopen()'ed bindings.
Replace 32-bit sizes in types like off_t with 64-bits when building on
32-bit architectures, to enable large file support there.
This fixes a nasty regression introduced in the cmake transition. As
autotools would set this flag to 64 automatically for us, applications
linking against librpm (such as libdnf, librepo, libsolv or drpm) are
already adapted to that and are also building with the value of 64
(explicitly, we never exported this flag through pkg-config ourselves).
However, us suddenly expecting 32-bits in those types on 32-bit systems
can blow up badly e.g. in functions that take an off_t parameter, like
Fseek().
There perhaps aren't that many low-level users of librpm but drpm is one
such example where exactly this happens when built against our current
master. It calls headerRead(), leading to Fseek() which receives a
64-bit offset parameter where it expects a 32-bit one, thus silently
overwriting the following parameter from 1 to 0 (SEEK_CUR to SEEK_SET)
which messes up the whole reading sequence in drpm's rpm_read(),
producing a failure in drpm's test suite that doesn't make any sense at
first sight.
While at it, also export the flag through pkg-config so that anyone
linking against librpm is now guaranteed to work correctly even if they
don't set the flag themselves (kudos to Petr Pisar for suggesting this).
Testing for the expansion was a cmake newbie mistake that can go wrong
in weird ways, test for the variable instead, consistently. Don't try to be
clever with for-loops, just test for each case separately. This makes it
greppable as well.
cmake variables and the derived macros.
CMAKE_INSTALL_INFODIR and CMAKE_INSTALL_MANDIR already include the
datarootdir. So just prepending the prefix is sufficient.
Our compound masks for disabling file info bits per operation never got
updated to include the two separate file signature types. This was
discovered by rpm-ostree on older rpm version crashing on an IMA signature
despite passing in RPMFI_FLAGS_ONLY_FILENAMES.
Add the file signatures to the most obvious masks, and add a simple test
as well.
Fixes: #2425
These disabler flags have little other purpose than optimizing cases
where you know you only need a certain subset of files for large
number of packages. Rather than expose all the individual flags,
export just the per-operation level masks to Python.
While many distros ship a pkg-config file for Lua, the upstream source
tree does not provide one and so we shouldn't rely on it. Turns out,
CMake provides a native Lua module so just use that.
Unfortunately, the package doesn't define any IMPORTED target so add our
own, similarly to how we did this recently with libmagic and libimaevm.
Of particular note is that this adds an implicit dependency between
CMake and Lua (e.g. Lua 5.4 support was only added in CMake 3.18), but
that hopefully won't have much impact on most OS installations out
there.
Fixes: #2247
There are multiple strange details buried in this all, such as
having to run the main tarball creation in VERBATIM mode due to
git submodule foreach variables, and because of that we can't use
globs in the other commands but have to mask them behind other rules
to do other steps and then concatenate the tarballs at end.
On the build side we need to manually test for the presence of pre-built
content in the source directory (normally that content would be in
binary directories) and install differently in absence of the tooling
that could actually build those docs.
While at it, put both the API docs and man pages in their expected
destinations, install(FILES .. TYPE MAN) is not aware of sections
(🤦) and just puts stuff into the root man directory. With
DOC that is expected, but not where packaging expects to find it.
Except that we're now *installing* the API docs too, put them under
rpm/API docs without any extra html directories in between.
We already violate the 3.12 requirement in a place or two, and
there are many nice things in the later releases. 3.18 is three years
old and is available pretty much anywhere that is even remotely relevant
for us.
Most of our dependencies are imported targets already, so while for just
one site this isn't actually any shorter in terms of LoC it's more
consistent with the surroundings in the consuming site, and more so if
we ever need to link to this from some other place.
Panu Matilainen