Re: [Rpm-maint] [rpm-software-management/rpm] Enhance the recoverability and location of database exceptions (Issue #2828)
In fact, the most difficult thing is that the database is suddenly damaged, generally don't know what caused the damage(may be a power outage or a kill process, etc.), so it is difficult to locate and repair. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2828#issuecomment-1894789114 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] Package specific prep/build/... sections (Discussion #2849)
AFACIT, the sub-package may include `Source` directive. But is there a chance to have also named prep/build/... sections? BTW wonder what happens with the string appended behind e.g. `prep`. Can I really put there any garbage I like, such as `%prep asl;dkfjsld;fkj`? But I assume this is likely going to change with #2728 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2849 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] don't attempt to install html pages if they're not built (PR #2848)
On systems without Doxygen, html pages are not built, but the install fails with: Install the project... -- Install configuration: CMake Error at docs/cmake_install.cmake:51 (file): file INSTALL cannot find /html: No such file or directory. Call Stack (most recent call first): cmake_install.cmake:47 (include) Conditionally install html docs only if we build them. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2848 -- Commit Summary -- * dont attempt to install html pages if theyre not built -- File Changes -- M docs/CMakeLists.txt (5) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2848.patch https://github.com/rpm-software-management/rpm/pull/2848.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2848 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Provide better support for versioned RPMs (Discussion #2847)
BTW looking around, `%source_name` used e.g. [here](https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros.fedora-misc-srpm) might be interesting concept and that is what I was aiming at in the last paragraph. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2847#discussioncomment-8145995 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] Provide better support for versioned RPMs (Discussion #2847)
It is pretty common to provide versioned RPMs. E.g. in Fedora, there are
[nodejs20](https://src.fedoraproject.org/rpms/nodejs20/blob/rawhide/f/nodejs20.spec),
[nodejs18](https://src.fedoraproject.org/rpms/nodejs18/blob/rawhide/f/nodejs18.spec),
[python3.x](https://src.fedoraproject.org/rpms/python3.9/blob/rawhide/f/python3.9.spec)
packages, there were added versioned
[postgresql16](https://src.fedoraproject.org/rpms/postgresql16/blob/rawhide/f/postgresql16.spec)
packages recently, etc. And I wonder if RPM could provide some basic support
to help with this scenario.
The most common issue is that typically, there is need for two "package names",
the original non versioned as well as versioned, e.g. `%{name}` and
`%{pkg_name}`. The versioned name is typically constructed from some other
major/minor/teeny version macros used as an suffix or prefix (in case of SCL).
However, which macro contains what value varies. And that is due to sub-package
naming.
The standard way is that the package declares just the suffix to the main
package name. However, for the versioned rpms, it depends if the main package
name is versioned or not, this means that the suffixes work just fine or all
package names needs to be fully named.
So I think that in short, what I am looking for is a way to have the versioned
name and a switch, which would tell RPM to use the versioned name for the
sub-packages.
BTW I think that what is also interesting with the versioned packages is that
the "main package" might not be shipped. That is for example case of the
nodejs20 package in Fedora, where the main binary package is named nodejs.
Therefore I wonder, is there a change to make the "main package" less
significant? Maybe it should be declared by `%package` declaration and treated
similarly to other sub-packages.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2847
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] Globbing inside quotes broken in %files with 4.19.1 (Issue #2824)
Closed #2824 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2824#event-11500335713 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] Globbing inside quotes broken in %files with 4.19.1 (Issue #2824)
RPM 4.18 and earlier had its own, non-standard and somewhat inconsistent glob semantics in the `%files` section. In 4.19 we changed/fixed that to use the standard, shell-like semantics, as defined in `glob(7)`. That means, among other things, that quotes now turn off the meaning of any metachars in between them. This is more in line with what one would expect and also enables use cases that weren't possible previously. If you're interested in the details, there was a series of PRs implementing this, most notably these two: https://github.com/rpm-software-management/rpm/pull/2103 and https://github.com/rpm-software-management/rpm/pull/2206. The correct fix here is to adjust the SPEC file, or in this case, the CPack generator that produces these file entries. Thanks for the linked ticket, that's indeed the right place to do it. I'm closing this one. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2824#issuecomment-1893955954 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] Attribute marker in `-V` mode undefined for multi-attribute files (Issue #2846)
**Description**
The *attribute marker* in `--verify` mode is only one character long, however
file entries may in fact have multiple attributes. For example, the following
are all valid entries:
```spec
%config %doc /etc/docfile
%config %license /etc/license
%config %ghost /etc/ghost
```
In these cases, the marker will currently show whichever attribute comes first
in the internal `attrFormat` string returned from `rpmFFlagsString()`:
```c
static int verifyHeader( ...
{
[...]
attrFormat = rpmFFlagsString(fileAttrs);
ac = rstreq(attrFormat, "") ? ' ' : attrFormat[0];
[...]
}
```
As a result, the actual marker shown in the output is not well-defined for such
combined file entries. There are two ways to fix this:
1. Define the priority of attributes, e.g. a `g` for `%ghost` is more specific
and so should be shown instead of `c` for `%config`.
2. Add new markers, e.g. as uppercase variants of the existing ones. For
example, a `%ghost` and `%config` entry would show up as a `G`.
**To Reproduce**
Steps to reproduce the behavior:
1. Build a package with the following `%build` and `%files` section:
```spec
%build
mkdir -p %{buildroot}/etc
touch %{buildroot}/etc/docfile
touch %{buildroot}/etc/license
%files
%config %doc /etc/docfile
%config %license /etc/license
%config %ghost /etc/ghost
```
3. Install the built package
4. Create the ghost file manually:
```sh
touch /etc/ghost
```
5. Modify the other files:
```sh
chmod -w /etc/docfile /etc/license
```
6. Verify the package:
```sh
rpm -V
```
**Actual output**
```sh
.M... d /etc/docfile
.M... c /etc/ghost
.M... c /etc/license
```
**Expected output**
Variant 1:
```sh
.M... d /etc/docfile
.M... g /etc/ghost
.M... l /etc/license
```
Variant 2:
```sh
.M... D /etc/docfile
.M... G /etc/ghost
.M... L /etc/license
```
**Environment**
- Fedora 39
- RPM 4.19.90 (built from master)
**Additional context**
This was originally filed in Red Hat Jira:
https://issues.redhat.com/browse/RHEL-20649
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2846
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 user/group lookup caching thread-safe (PR #2843)
Split to refactor + thread-safe fix, and restored that rpmugFree() on librpm exit that had gone missing at some point. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2843#issuecomment-1893715068 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 user/group lookup caching thread-safe (PR #2843)
@pmatilai pushed 3 commits. 4945ad298058fd3c325c6b803ef6c3e2cb2d97aa Remember to free user/group cache on librpm shutdown (again) 8656e2e0327a9af38ef180eb014bac9271b3f8df Centralize user/group lookup caching into a single data structure d23eb53abdde25ad2c45d20c32dde255fb36384d Make user/group lookup caching minimally thread-safe -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2843/files/c320341aaafa95a82428a4364ed48695034be358..d23eb53abdde25ad2c45d20c32dde255fb36384d 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: Handle DistTag (#589)
@ffesti converted this issue into discussion #2845. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/589#event-11498460864 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] Enhance the recoverability and location of database exceptions (Issue #2828)
There is `rpmdb --verifydb`. With the new rpmdb backends (sqlite and ndb) issues with the database should be incredibly rare compared to the old bdb days. If you are still experience rpmdb issues you are likely doing something wrong. May be disable measures that still are left over from the bdb times e.g. rebuilding the rpmdb on reboot or in a cron job. If this doesn't solve the issue we much rather find and solve this issue properly than putting this band aid on. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2828#issuecomment-1893670614 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 user/group lookup caching thread-safe (PR #2843)
Oh, except that rpmugGname() and rpmugUname() additionally rely on central storage of the returned values so simple mutex locking doesn't work for those. So those would have to be changed to return malloced data for a simple fix (it wont break any users because there aren't any, at the moment). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2843#issuecomment-1893599960 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 user/group lookup caching thread-safe (PR #2843)
It wouldn't be hard to introduce per-thread locking instead. The bigger deal here is the new central struct that makes it possible to do stuff, perhaps I should actually split that into a separate commit and then consider the thread safety separately. The reason its lumped into one is basically wanting a single patch to fix the issue and people to cherry-pick, but that's clearly bending other "rules" here. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2843#issuecomment-1893595508 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 user/group lookup caching thread-safe (PR #2843)
Yup, but this patch doesn't change that, the "leak" is already there. This only makes it per-thread. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2843#issuecomment-1893568039 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 user/group lookup caching thread-safe (PR #2843)
OK, "ending itself" is a bit over dramatic... rpmChrootSet instantly returns if there is now chroot so rpmugFree() is never called at all. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2843#issuecomment-1893557584 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] 4.19: GLOB_BRACE is not portable (Issue #2844)
FWIW, I think it's most easily fixable by relying on gnulib implementation? https://github.com/coreutils/gnulib/blob/master/lib/glob.c -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2844#issuecomment-1893554648 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] Support rpmver-py comparison operator inheritance (PR #2839)
Yes, this here seems save. Thanks for the patch! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2839#issuecomment-1893553825 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] Support rpmver-py comparison operator inheritance (PR #2839)
Merged #2839 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2839#event-11497627945 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] 4.19: GLOB_BRACE is not portable (Issue #2844)
Yup, we recently refactored quite a bit of code related to glob handling, and mostly went with the GNU `glob(3)` implementation, meaning that at least `GLOB_BRACE` is indeed used now. Previously, we had our own implementation of brace expansion, IIRC. I'll have a closer look but it's possible this could actually be fixed upstream. Thanks for the report! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2844#issuecomment-1893538442 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 user/group lookup caching thread-safe (PR #2843)
It does leak, should've mentioned that in the commit message. In the sense that each thread calling it will leave one cache around and reachable. It's far from ideal but it's basically an emergency bandaid. What do you mean about ending itself? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2843#issuecomment-1893529714 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: file trigger scriptlet arguments (Issue #2755)
Note that there's no technical reason for *not* adding the second argument (the number of triggering packages) to transaction scriplets here, too. It's the same code path underneath. Whether it's useful or not is another question but I'll probably lean towards consistency here and include it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2755#issuecomment-1893488090 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] 4.19: GLOB_BRACE is not portable (Issue #2844)
For completeness, we're going to patch rpm to ignore the braces if GLOB_BRACE
is absent, and if failures occur on musl systems, then they would be separately
fixed - so far none have been found:
```
>From f78e05544fb5ae9ef688963f19666f1af34c3d5c Mon Sep 17 00:00:00 2001
From: Alexander Kanavin
Date: Tue, 16 Jan 2024 09:59:26 +0100
Subject: [PATCH] rpmio/rpmglob.c: avoid using GLOB_BRACE if undefined by C
library
This addresses musl failures; if there is code out there relying on
those braces, it needs to be fixed when used on musl.
This is unlikely to be trivially fixable upstream.
Upstream-Status: Inappropriate [reported at
https://github.com/rpm-software-management/rpm/issues/2844]
Signed-off-by: Alexander Kanavin
---
rpmio/rpmglob.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/rpmio/rpmglob.c b/rpmio/rpmglob.c
index 243568766..43c27074a 100644
--- a/rpmio/rpmglob.c
+++ b/rpmio/rpmglob.c
@@ -33,6 +33,12 @@
#include "debug.h"
+/* Don't fail if the standard C library
++ * doesn't provide brace expansion */
+#ifndef GLOB_BRACE
+#define GLOB_BRACE 0
+#endif
+
/* Return 1 if pattern contains a magic char, see glob(7) for a list */
static int ismagic(const char *pattern)
{
```
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2844#issuecomment-1893487061
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 user/group lookup caching thread-safe (PR #2843)
I wonder if this leaks memory. We create a new struct for each thread. Yes, this is freed in rpmChrootSet but that is relying a lot on the right call order. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2843#issuecomment-1893419277 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: introduce an rpm-controlled per-build directory to builds (Issue #2078)
Added buildroot itself to the description, there's no reason whatsoever to scatter the built content around multiple directories if we have that one top-level directory to rule it all. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2078#issuecomment-1893297116 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] Strange behavior for multilib (Issue #2837)
Right, that one. An architecture change is a fairly special operation, I'm not convinced it needs to "just work" with regular update, it just needs to be doable. Eg, using --replacepkgs, which back then it wasn't. Also, an i686 package *can* be considered an update to an i586 package, but a i686 package is not an upgrade to x86_64 one by any stretch of imagination. Of course the starting situation here is an abnormal one, but I'd rather get an error than the outcome we now get. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2837#issuecomment-1893231695 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
