Re: [Rpm-maint] [rpm-software-management/rpm] Return to Tralla La or: RPM in C++ (Discussion #2983)
> As such, moving to C++ now will probably make it harder to move to Rust later. Well, maybe. My original comment here remember was about how we very intentionally moved rpm-ostree to "C compiling as C++" explicitly to bridge with cxx.rs. This...kind of worked in some ways, and definitely didn't in others - although I'd say at least 50% of that is just not executing well enough probably. Using some C++ definitely doesn't exclude Rust in the future either. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2983#discussioncomment-8946642 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Make it possible to evaluate arbitrary macros in the context of a given spec file (Discussion #3008)
This would be tremendously useful, especially for me trying to dig through really complex packages... Some of them are just not able to be intuited by reading, and being able to probe them like this would be really useful! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/3008#discussioncomment-8945747 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Make it possible to evaluate arbitrary macros in the context of a given spec file (Discussion #3008)
Particular use case: I'd like to be able to query a spec file for the list of
its patches. Currently (on Fedora 39's 4.19.1) this is only possible using
`rpmspec --shell` but it requires parsing the output:
```
❯ echo '%patches' | rpmspec --shell ./*.spec
RPM version 4.19.1.1 macro shell
> %patches
'/home/michel/src/fedora/pkgs/other/slurm/slurm_release_version.patch'
'/home/michel/src/fedora/pkgs/other/slurm/slurm_check_version.patch'
'/home/michel/src/fedora/pkgs/other/slurm/slurm_html_doc_path.patch'
'/home/michel/src/fedora/pkgs/other/slurm/slurm_perlapi_rpaths.patch'
'/home/michel/src/fedora/pkgs/other/slurm/slurm_runtime_linking.patch'
'/home/michel/src/fedora/pkgs/other/slurm/slurm_to_python3.patch'
> ⏎
```
without shell, `rpmspec` only allows querying query tags e.g.
```
$ rpmspec --srpm --query --qf '%{name}\n' ./*.spec
slurm
$ rpmspec --srpm --query --qf '%{patches}\n' ./*.spec
error: incorrect format: unknown tag: "patches"
```
While `rpm` allows evaluating anything but only those define by shipped macros,
not definitions that are spec file specific; `rpmspec` does seem to have a `-E`
eval option but it is undocumented and does not seem to work
```
$ rpm -E '%_sysconfdir'
/etc
$ rpmspec -q -E '%patches' ./*.spec
error: lua script failed: attempt to index a nil value
```
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3008
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] RPM with Copy on Write (PR #3007)
This is part of https://fedoraproject.org/wiki/Changes/RPMCoW The majority of changes are in two new programs: ### rpm2extents Modeled as a 'stream processor'. It reads a regular .rpm file on stdin, and produces a modified .rpm file on stdout. The lead, signature and headers are preserved 1:1 to allow all the normal metadata inspection, signature verification to work as expected. Only the 'payload' is modified. The primary motivation for this tool is to re-organize the payload as a sequence of raw file extents (hence the name). The files are organized by their digest identity instead of path/filename. If any digest is repeated, then the file is skipped/de-duped. Only regular files are represented. All other entries like directories, symlinks, devices are fully described in the headers and are omitted. The files are padded so they start on `sysconf(_SC_PAGESIZE)` boundries to permit 'reflink' syscalls to work in the `reflink` plugin. At the end of the file is a footer with 3 sections: 1. List of calculated digests of the input stream. This is used in `librepo` because the file *written* is a derivative, and not the same as the repo metadata describes. `rpm2extents` takes one or more positional arguments that described which digest algorithms are desired. This is often just `SHA256`. This program is only measuring and recording the digest - it does not express an opinion on whether the file is correct. Due to the API on most compression libraries directly reading the source file, the whole file digest is measured using a subprocess and pipes. I don't love it, but it works. 2. Sorted List of file content digests + offset pairs. This is used in the plugin with a trivial binary search to locate the start of file content. The size is not needed because it's part of normal headers. 3. (offset of 1., offset of 2., 8 byte MAGIC value) triple ### reflink plugin Looks for the 8 byte magic value at the end of the rpm file. If present it alters the `RPMTAG_PAYLOADFORMAT` in memory to `clon`, and reads in the digest-> offset table. `rpmPackageFilesInstall()` in `fsm.c` is modified to alter the enumeration strategy from `rpmfiNewArchiveReader()` to `rpmfilesIter()` if not `cpio`. This is needed because there is no cpio to enumerate. In the same function, if `rpmpluginsCallFsmFilePre()` returns `RPMRC_PLUGIN_CONTENTS` then `fsmMkfile()` is skipped as it is assumed the plugin did the work. The majority of the work is in `reflink_fsm_file_pre()` - the per file hook for RPM plugins. If the file enumerated in `rpmPackageFilesInstall()` is a regular file, this function will look up the offset in the digest->offset table and will try to reflink it, then fall back to a regular copy. If reflinking does work: we will have reflinked a whole number of pages, so we truncate the file to the expected size. Therefore installing most files does involve two writes: the reflink of the full size, then a fork/copy on write for the last page worth. If the file passed to `reflink_fsm_file_pre()` is anything other than a regular file, it return `RPMRC_OK` so the normal mechanics of `rpmPackageFilesInstall()` are used. That handles directories, symlinks and other non file types. ### New API for internal use 1. `rpmReadPackageRaw()` is used within `rpm2extents` to read all the headers without trying to validate signatures. This eliminates the runtime dependency on rpmdb. 2. `rpmteFd()` exposes the Fd behind the rpmte, so plugins can interact with the rpm itself. 3. `RPMRC_PLUGIN_CONTENTS` in `rpmRC_e` for use in `rpmpluginsCallFsmFilePre()` specifically. 4. `pgpStringVal()` is used to help parse the command line in `rpm2extents` - the positional arguments are strings, and this converts the values back to the values in the table. Nothing has been removed, and none of the changes are intended to be used externally, so I don't think a soname bump is warranted here. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3007 -- Commit Summary -- * RPM with Copy on Write -- File Changes -- M include/rpm/rpmlib.h (9) M include/rpm/rpmpgp.h (9) M include/rpm/rpmte.h (2) M include/rpm/rpmtypes.h (3) M lib/depends.c (2) M lib/fsm.c (61) M lib/package.c (40) M lib/rpmplugins.c (21) M lib/rpmte.c (5) M plugins/CMakeLists.txt (1) A plugins/macros.transaction_reflink (1) A plugins/reflink.c (378) M rpmio/rpmpgp.c (28) M tools/CMakeLists.txt (4) A tools/rpm2extents.c (433) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3007.patch https://github.com/rpm-software-management/rpm/pull/3007.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3007 You are receiving this because you are subscribed to this thread. Message ID:__
Re: [Rpm-maint] [rpm-software-management/rpm] Set the charset of the libarchive strings to utf8 (PR #2993)
Merged #2993 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2993#event-12280849094 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Set the charset of the libarchive strings to utf8 (PR #2993)
Looks fine to me, thanks for the patch! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2993#issuecomment-2025086199 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Macro documentation does not mention `{body}` syntax for macro definitions (Issue #2976)
I certainly remember seeing that code, but never quite got what it actually
refers to. I doubt anybody knows of it, really.
It'd be a lot more useful if it permitted multiline macros. People seem to be
widely abusing %{expand:...} (probably without fully realizing the
consequences) to get the more function-like block syntax for multiline macros
instead of \-line continuations.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2976#issuecomment-2024950690
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Understanding of the Declarative builds, Python edition (Discussion #2997)
FWIW, I revived my rpm-snapshot repository where you can get Fedora compatible builds from rpm git: https://copr.fedorainfracloud.org/coprs/pmatilai/rpm-snapshot/ so if folks want to try this out before the soon-to-be-released 4.20 alpha, there goes. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2997#discussioncomment-8938915 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Ensure rpmbuild's cleanup doesn't fail due to permissions (PR #3006)
Details in the commit messages, but in short: packages can leave unremovable files in their build directory, run %_fixperms before and after to ensure sufficient permissions to remove %builddir. %clean is redundant since 9d35c8df497534e1fbd806a4dc78802bcf35d7cb, drop default %clean sections and document as obsolete. We still honor a %clean in spec though. Fixes: #2519 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3006 -- Commit Summary -- * Document %clean as obsolete and drop the unnecessary default %clean * Ensure %rmbuild doesn't fail due to permissions in the built content -- File Changes -- M build/build.c (8) M build/parseSpec.c (7) M docs/manual/spec.md (6) M macros.in (1) A tests/data/SPECS/noperms.spec (22) M tests/rpmbuild.at (18) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3006.patch https://github.com/rpm-software-management/rpm/pull/3006.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3006 You are receiving this because you are subscribed to this thread. Message ID:___ 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 setting the build time and clamping to the build time (PR #2944)
@keszybz commented on this pull request.
Looks nice.
> @@ -240,10 +240,12 @@ Supplements: (%{name} = %{version}-%{release} and
> langpacks-%{1})\
# Is ignored when SOURCE_DATE_EPOCH is not set.
%use_source_date_epoch_as_buildtime 0
-# If true, make sure that timestamps in built rpms
-# are not later than the value of SOURCE_DATE_EPOCH.
-# Is ignored when SOURCE_DATE_EPOCH is not set.
-%clamp_mtime_to_source_date_epoch 0
+# Defines file timestamp handling in built rpms. Possible values
+# are "clamp_to_buildtime" and "clamp_to_source_date_epoch",
+# which makes sure the the file timestamps are not later than
+# the build time of the package or the value of
I'd spell "the build time" as "BUILDTIME" to avoid ambiguity.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2944#pullrequestreview-1965645048
You are receiving this because you are subscribed to this thread.
Message ID: ___
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: execute rpmbuild tests as a regular user (Issue #3005)
Sounds like a plan :+1: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3005#issuecomment-2024754579 You are receiving this because you are subscribed to this thread. Message ID: ___ 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: execute rpmbuild tests as a regular user (Issue #3005)
Bonus point - `runroot` will finally live up to its name :smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3005#issuecomment-2024750126 You are receiving this because you are subscribed to this thread. Message ID: ___ 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: execute rpmbuild tests as a regular user (Issue #3005)
Yup, good point. I think we should actually make the `rpmtests` script (which runs in the podman container) run as a regular user there. The individual tests aren't supposed to write to the root filesystem anyway (which we prevent by making it read-only) so being root shouldn't be necessary either. Typically, the tests would run `rpm` to query something and/or prepare the `$PWD` which can be done under a regular user. Then, when a test actually needs to write to the system (and thus needs root privileges), we can escalate it (via `sudo` perhaps) in the `runroot*` functions. This is also how Toolbox works - the user in the container is mapped to your native user on the host and you have to use `sudo` in the same way as you'd on the host. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3005#issuecomment-2024739993 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] RFE: execute rpmbuild tests as a regular user (Issue #3005)
While investigating #2519 I realized that we're running the entire test-suite as root. That's not how rpmbuild is intended to be used, and masks various permission issues real-world users have, such as that #2519 which is not reproducable in the test-suite because of this. Adding a user to the test-environment is trivial enough, actually running the tests with it probably less so. Besides all rpmbuild tests, there's probably a lot of other tests too that would optimally run as non-root. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3005 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Ignore non-scriptlet weak dependencies in ordering (PR #3004)
Taking weak dependencies into account during ordering has caused a noticeable wave of dependency loop caused install failure bug reports at least in Fedora. This is counter-productive: weak dependencies are commonly used to introduce more exotic / heavier dependencies to packages without causing impossible loops, but now we're doing that to ourselves. Commit d6353c96fed98a8d30d9ebadf4d6a19a5149edee demoted scriptlet dependencies to regular ones, but this had precisely zero effect because there were no such dependencies in the wild because due to a bug that made it impossible to create such dependencies manually. That bug is now fixed, but in addition, demote non-scriptlet dependencies to meta for ordering purposes (as in, just ignore them). This helps concretely helps bringing down the number (and density) of install ordering dependency loops in the wild. It's worth mentioning that sysusers dependencies are flagged as scriptlet dependencies, so it's important that these don't get ignored even if %_use_weak_usergroup_deps is enabled. Adjust ordering tests accordingly, in particular turn the first weak dependency test into a mixed set that demonstrates the effect of this change. Fixes: #1346 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3004 -- Commit Summary -- * Ignore non-scriptlet weak dependencies in ordering -- File Changes -- M lib/order.c (18) M tests/rpmorder.at (18) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3004.patch https://github.com/rpm-software-management/rpm/pull/3004.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3004 You are receiving this because you are subscribed to this thread. Message ID:___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
