Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RPM 4.19.1 bugfix update #2791

Merged
merged 108 commits into from
Dec 12, 2023
Merged

Conversation

dmnks
Copy link
Contributor

@dmnks dmnks commented Nov 28, 2023

Here's a rebase-like todo list listing all commits on master since 4.19.0 (generated with git-cherry-plan), with the corresponding picks and drops added by me: https://gist.github.com/dmnks/ab3e59cd9500c4975b4795e4ff9d0a25

I've attached the plan file just in case someone wants to look at the commits/PRs that I decided to drop as those obviously aren't included in this PR.

pmatilai and others added 30 commits November 28, 2023 12:59
rpm-sequoia >= 1.4.0 has been in stable updates for a good while now.

(cherry picked from commit 2085295)
No functional changes.

(cherry picked from commit 7478388)
Having stuff in the top-level directory is messy and prevents control
over what you can include from where. No functional changes.

(cherry picked from commit d4eb1f2)
These are nothing like normal sources and are not compiled into librpm,
but having them in lib/ makes it appear they are. Which also confuses
the issue of where they are usable which is everywhere within the source
tree, not just places linking to librpm. No functional changes.

(cherry picked from commit 13eb82e)
Having stuff in the top-level directory is messy, and the top-level
cmake file is plenty big enough without all this. No code changes,
no functional changes.

(cherry picked from commit 86d99a1)
Having everything accessible to everything encourages fast and loose
includes from places one shouldn't be using, and makes it easy for
those cases to hide in plain sight as well. There were reasons for
the top-level include back in 2007 but our codebase is a rather
different beast these days. Limiting access through per-target
include directories on everything nicely highlights the exceptions
and makes the whole more controllable and manageable.

This change looks huge, but it's just due to stripping no longer valid
prefixes from all the gazillion internal includes. No rpm-side
functionality is affected, this is just source-level hygiene operation.

(cherry picked from commit 1c98b67)
Should've been in 6ec0e40 but at that
time cmake in Fedora had a dependency on rpm making this hard or
at least ugly. With that dependency fixed, we can now run cmake in there.

(cherry picked from commit 1120c8c)
Some packages in Fedora provide shared RPM lua code that's used by other
packages.
It would be nice to have automatic Provides for this code like we have
for rpm macros themselves.

Usecase:

Recently, forge.lua that's used by go-srpm-macros and fonts-srpm-macros
moved out of redhat-rpm-config.
I would like to be able to add `Requires: rpm_lua(fedora.srpm.forge)`
to those packages instead of having to rely on it being implicitly
pulled in by redhat-rpm-config or adding conditional dependencies on
forge-srpm-macros.

(cherry picked from commit 6867ef9)
The COMMAND for tagtbl.C generation dumps the file in the top-level
build directory whereas the OUTPUT is specified in the current (lib/)
directory.  This leads to unnecessary relinking of all the libraries on
each make invocation because OUTPUT is always missing.

Fix this by outputting the file in the current directory where OUTPUT
can find it.

No functional change, just makes rebuilds quicker.

(cherry picked from commit a25d881)
Debug builds/modes of Python will complain loudly about unclosed files,
making tests fail.

(cherry picked from commit 5802192)
It's fairly amusing how various aspects of integrating autotest seems
easier with cmake than autoconf/automake.

(cherry picked from commit ea6dab8)
Mark all the program and library path details as advanced, they're not
something you need to be acutely aware of when compiling rpm. This
way -L[H] actually shows the "user configurable" parts.

(cherry picked from commit 56558a5)
Running the test-suite obviously requires on having the project completely
built first. The test-suite was relying on the cli tools in the top level
directory for this, but now that we moved the tools elsewhere there are
zero targets at the top-level. Oops.

Update the property get_property() path accordingly, this should've been
in commit 1c98b67. Rename the variable
and add commentary on why we're doing this the way we are, it's not entirely
obvious.

Suggested-by: Michal Domonkos <mdomonko@redhat.com>
(cherry picked from commit ea19571)
This will be needed in the following commits where snapshot() will be
used standalone (in CI), much like how mktree.podman is used currently.

Do this by removing the @foo@ style variable references, namely @bwrap@
and @CMAKE_INSTALL_FULL_BINDIR@.  The former can just be "bwrap" and for
the latter, use the host's shell default, sane value instead.

(cherry picked from commit cca5d1b)
This will make it easier to reuse the function in a mktree backend
without having to source all of atlocal (to be utilized in the next
commits).

Also drop the "function" keyword (a Bashism) while at it.

No functional change.

(cherry picked from commit 09e4720)
As in "Autotest shell".  We all know naming is hard but this is perhaps
going to be more accurate and also consistent with "make shell".  It may
confuse someone's muscle memory but hopefully nobody (besides me) has
really been using this (rather new) feature just yet.

(cherry picked from commit 46c64c3)
RPM still *is* installed in the final image so keep the record.  That
way, it won't be pulled back in by DNF in "make atshell" when installing
additional packages into $RPMTEST.

This is already worked around with the explicit exclude in the DNF
command line in mktree.fedora but that will go away in the next commits.

The version we build and install is likely newer than what the original
record claims but that doesn't matter, we really just want to satisfy
the dependency.

(cherry picked from commit 7e87a27)
Split the build into two stages, "base" and "full", the former of which
contains rpm's build, runtime and test dependencies but no rpm install.

The "base" stage will effectively replace mktree.fedora in the next
commits.

Since this moves the self-removal of rpm in front of the cmake configure
step, we need to put a workaround in place for /usr/bin/pkg-config which
is a shim that calls the rpm binary, see the inline comment.

See --target in podman-build(1) for more info on how this can be used.

No functional change.

(cherry picked from commit d1fd06c)
These are rather different than the "general" tests otherwise,
might as well have them in their own set.

(cherry picked from commit f5e0cba)
Stuff has moved around, these are just leftovers.

(cherry picked from commit 314faf5)
Don't stop if there's a base tree already, this way we'll install any
newly added packages while still letting DNF skip over those already
installed.

The original intent of this short-circuit conditional was to avoid the
output noise but then, it's not really that bad and we'll avoid
unnecessary rebuilds in the next commit anyway.

(cherry picked from commit 3a1fb2e)
Turn the tree (mktree.output) into a proper build artifact and let cmake
do its job in determining when to remake it, instead of doing that
always.

Keep the "tree" target though, it's still useful when you want to build
the tree manually.

(cherry picked from commit d4e808e)
We want these to always be 0 so that cmake doesn't print an "error" when
leaving the shell (if the last command happened to fail).

However, since it's a cmake thing, handle that in cmake instead of
mktree backends.

No functional change, just cosmetic.

(cherry picked from commit dd66984)
Instead, just use absolute paths everywhere.

No functional change.

(cherry picked from commit a50e092)
giving a rough outline of the different doc parts.

Related: rpm-software-management#2259
(cherry picked from commit e0dd875)
Fixes `cmake --install` failing on these files as the working directory
is "unexpected" from the trad. makefile POV.

Reported-by: Tomasz Kłoczko <kloczek@github.com>
(cherry picked from commit f410403)
On Rocky Linux /etc/os-release contains not only ID="rocky", but also
ID_LIKE="rhel centos fedora" and the grepping got that wrong. Let
the shell do the work for us.

Reported-by: Dmitry Mikushin <dmitry@kernelgen.org>
(cherry picked from commit 20c476f)
This is one of those cases where the answer to "What on earth were you
thinking?" is "I wasn't".

Fixes: 20c476f
(cherry picked from commit 0c7a3be)
pmatilai and others added 15 commits December 4, 2023 12:20
The dir argument to fsmOpenpath() is supposed to be a rough O_DIRECTORY
equivalent, and if the path is actually a misowned symlink it should
return ENOTDIR instead of ELOOP. Makes the resulting error messages
at least a little more comprehensible.

(cherry picked from commit 89ce4e7)
This should've been in commit 96ec957
but back then we didn't have a good way to test ownership matters.

(cherry picked from commit 0091214)
Add the missing sanity check/fixup for memory starved systems where
we end up returning zero cpus. Should've been in commit
deaebd0 originally.

Reported in https://issues.redhat.com/browse/RHEL-16557

(cherry picked from commit 6714ec7)
Since commit a9cca03 we've only
returned signing capable subkeys, but this has seemed like an
implementation detail. Make it explicit.

Fixes: rpm-software-management#2515
(cherry picked from commit 01fb42d)
Commit deaebd0 assumed there would
always be args, but in the macro existence test none are set up.

Reported as a side-issue in https://issues.redhat.com/browse/RHEL-16557

(cherry picked from commit c110ad1)
Fixes: rpm-software-management#2611
(cherry picked from commit 949f281)
The full path is visible in the actual file operations later, but the
pre-flight disposition diagnostics is unreadable without the full path.
This regressed in the switch to relative paths for the *at() API family
for the symlink CVE fixes.

(cherry picked from commit c140768)
Multi-character character constants are implementation defined, and
while it MAY be reliable enough on i386 gcc, even that produces a
warning. I don't have a test-Robinson here so rather than risk a
conversion to string comparison like the other is_arch() tests are,
just write out the integer and leave the character constant as a
reference comment.

(cherry picked from commit d0e03b2)
"long int" on at least x86 Linux is exactly the same as a plain "int",
so calculations can easily overflow. 32bit systems are not expected to
have hundreds of gigabytes of memory but a 32bit process on a x86_64 can
run into all sorts of funny things, such having 500GB system memory. At
which point the type capable of addressing all of process memory is
absolutely useless for calculating the total memory.

Use uint64_t in the memory calculations to make the size explicit. Of course
one day we may cross that border too, but I hope to be retired by then.

Fixes https://issues.redhat.com/browse/RHEL-16557

(cherry picked from commit 1cd9f90)
Both process exactly one ASCII-armored block, this wasn't clear in
the docs.

Fixes: rpm-software-management#2387
(cherry picked from commit bccf58f)
No functional changes, just docs.

(backported from commit 06ea603)
pmatilai and others added 11 commits December 12, 2023 11:38
These litter our build logs with redundant noise from undocumented
macros and typedefs that aren't really worth the trouble to document.
Sadly Doxygen doesn't have fine-grained controls for emitted warnings.

(cherry picked from commit c47ee24)
(cherry picked from commit 5d7a192)
This simply uses terminology better suited for C, such as "data
structures" instead of "classes" and so on.

(cherry picked from commit 15bd653)
No particular reason this time, but nice to be on the same page with
the system rpm.

(cherry picked from commit c576d96)
There's no situation where rpmbuild should use uid/gid from either
the filesystem or current user. The former made sense in the
pre-historic times before Buildroot was a thing, but in the last 20+
years that's always the wrong thing to do. Always. The only user/group
info rpm can legitimately use is the one that is explicitly specified in
the packaging, and otherwise fallback to root/equivalent.

Besides fixing a long-standing annoyance with src.rpm file ownership,
this also fixes a regression in 4.19.0 where a non-local or otherwise
unresolvable user info could cause a segfault during rpmbuild (RhBug:2248763).

Fixes: rpm-software-management#2604
(backported from commit a0553eb)
Right now, we "leak" any local branch or tag names into the ChangeLog
which is unnecessary (e.g. "experiment-foo-123") and also just pollutes
the diff when comparing ChangeLogs between releases.  Only show the
plain log.

Fixes: rpm-software-management#2647
(cherry picked from commit 017b5a4)
Commit 1870f4d stopped the installation
of man pages for disabled features.  We were still building them all,
though, so they appeared in dist tarballs as they should have.

This was lost in the cmake translation where the opposite problem was
introduced: only man pages for enabled features are now built, meaning
that when preparing a tarball, you need to make sure all the features
are enabled in your build in order to have all the man pages pre-built
and bundled.

Fix this "regression" by building all man pages unconditionally again
while only installing those that are enabled.

(backported from commit ddc0ad8)
No functional changes, just reduces verbosity a bit.

(cherry picked from commit 014b09d)
For normal debug output the basename of the files are sufficient as when
debugging is enabled the directories are also printed. But here the
warning is given without a debug flag so we need the full context right
there.

(cherry picked from commit dcf8c5a)
@dmnks dmnks marked this pull request as ready for review December 12, 2023 10:57
@dmnks dmnks merged commit 98b301e into rpm-software-management:rpm-4.19.x Dec 12, 2023
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release Release creation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants