The simple cache whose efficiency troubled ewt back in 1997
(see commit 97999ce92c)
has proven more than adequate over the years.
In a local testcase based on Fedora 33 server iso contents, an install
of 1765 packages consisting of 201344 files did a whopping 27 user +
groups combined. So a few more alloc+free is not going to make the
damnest difference, don't bother with reallocing the cache buffer, just
strdup() a new one when needed.
There's no telling what sort of caching getpwnam() and friends perform
behind the scenes, and worse, there's no way to explicitly reset those
caches. This can lead to chrooted operations using user/group data from
the host, which is simply wrong.
Do our own parsing of /etc/passwd and /etc/group to fix. Besides the
chroot matter, we then only ever lookup local system users and groups
and not something from eg network name services. We cannot reliably
do NSS in a chroot because doing so would require relying on binaries
in the chroot, which in itself is completely unreliable. NSS is also
unreliable in various rescue mode situations. Bottom line, local files
are the only ones that can be guaranteed for rpm operation, and this
change basically enforces that.
Technically we should track chroot status for each lookup and flush the
cache if the state changed, but this is an internal API and rpm usages
only ever call it from one side of the chroot for a given operation.
Fixes: #882, #1789
Real names in git commits has always been the expectation, even if there
have been some slippages. Make it an explicit requirement so the
contributors know what to expect.
It's not whether these are particularly important examples or not
(they're not), but adding more will be so much easier once the place
to add them has been established.
Fixes: #2075
The return value is stored in the "res" variable which is set to the return
value of parseLines early in the function. Past that point, any "goto exit;"
caused the function to return success. This was introduced by 52ce88851a
("Port parseScript() to use parseLines(), no functional changes"). To fix it,
reintroduce the nextPart variable.
sqlite3_config() affects all in-process uses of sqlite. librpm being a
low-level library, it has no business whatsoever making such decisions
for the applications running on top of it. Besides that, the callback can
easily end up pointing to an already closed database, causing an
innocent API user to crash in librpm on an entirely unrelated error on
some other database. "Oops."
The sqlite API doesn't seem to provide any per-db or non-global context
for logging errors, thus we can only remove the call and let sqlite output
errors the way it pleases (print through stderr, presumably).
Thanks to Jan Palus for spotting and reporting!
It's theoretically possible for a x86-64-v2 compatible processor to not
have CPUID leaf 7, in which case it returns the data for a lower leaf instead
(instead of a sensible value of all zeros...). While this is already covered
by the use of __builtin_cpu_supports now, do it explicitly for completeness.
Commit 6dd62720fe neglected to update
rpmpluginsCallFsmFilePost() to pass the absolute path in the case
of unowned directories. Because in that case there's no rpmfi to
pass to the plugin in that case, there's simply no way for the plugin
to know what path is being manipulated. Oops.
Fixes: #2543
Discovered via #2548, these functions merrily return zero for success
when passed NULL data. In rpm nothing bothers to check for their return
codes but it doesn't mean it's the right thing to do
per package even if we do multiple parse passes. This is a quick fix for
the dynamic spec feature that executes the parsing code multiple times.
This needs to be sorted out properly to only do the necessary things
(for the build scripts) here and postpone everything else after the
secondary parses. But that requires larger changes.
--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.
Michal Domonkos