Re: [Rpm-maint] [rpm-software-management/rpm] Create content handler plugin hook (PR #2416)
@rphibel pushed 1 commit. 8a7cd8139b759d1711273839a6502333e3c0f914 Create content handler plugin hook -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2416/files/5965d2be5b80eea738b767a5b48c5bff50c87da3..8a7cd8139b759d1711273839a6502333e3c0f914 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] RPM with Copy on Write (PR #2378)
I referenced this effort in https://marc.info/?l=linux-fsdevel=167794198604510=2 - my PoV is that the rpm-cow effort makes some sense. I thought a lot though about hard requiring reflinks for ostree though and determined it was not viable. There are too many people that use e.g. ext4. And even if we stopped supporting new installs with that, IMO we need to support in-place upgrades for rpm systems deployed w/ext4 (or xfs without `-m reflink=1`) for a (really) long time. On the ostree side I thought about hard requiring reflinks and just concluded it was not viable to have two different code paths. What ultimately I think will work better here is using overlay-style filesystems. From my PoV composefs or something similar is the successor to ostree. And that type of overlayfs style approach Just Works even on non-reflink filesystems (albeit less efficiently sometimes). So there's no concerns with in-place upgrades, and that's ultimately why I think it's a more viable approach for both bootable host systems and containers. (Now, how exactly one would try to tie something composefs-like into something that feels more traditional-rpm like is a bit more of an open question; would a higher level tool like yum/zypper end up making composefs snapshots locally, etc? We'll be doing this for rpm-ostree at least, but it was designed from the start for that) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2378#issuecomment-1458653493 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] Create content handler plugin hook (PR #2416)
@rphibel pushed 1 commit. 5965d2be5b80eea738b767a5b48c5bff50c87da3 Create content handler plugin hook -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2416/files/82b6cfe2cfdc981cc7fcda4ecd473c8729aa6920..5965d2be5b80eea738b767a5b48c5bff50c87da3 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] Replace rpmTagType_e with a list of defines and an rpmTagType typedef (PR #2417)
I ran in to a problem with some versions of clang building rpm where the value of RPM_MASK_TYPE (0x) triggered an overflow error. Per the C standard, the underlying type of the enum is implementation defined. It should be an int unless the values of the enum cannot fit in an int or unsigned int. I think that gcc is more forward thinking here than clang because with clang this particular enum becomes an int and when RPM_MASK_TYPE is used, you get an overflow error. RPM_MASK_TYPE is not part of the enum. I generally find enums in header files to lead to confusion and problems anyway. And especially in cases like this where developers may be expecting to use the preprocessor to determine if values are defined or not. Changing this enum to be a list of defined macros resolves the issue for me. I retained the rpmTagType variable type as well, but made it be a uint32_t. I originally wanted to make it a uint16_t because RPM_MASK_TYPE is 0x, but that causes overflow warnings as well because rpmTagType sometimes gets RPMTAG_NOT_FOUND, which is a uint32_t. So just use uint32_t consistently. If this looks reasonable to people, I do not mind fixing up the other enums in header files. I just wanted to start with this one. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2417 -- Commit Summary -- * Replace rpmTagType_e with a list of defines and an rpmTagType typedef -- File Changes -- M include/rpm/rpmtag.h (34) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2417.patch https://github.com/rpm-software-management/rpm/pull/2417.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2417 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] RPM v6 package format, first public draft for commenting (Discussion #2374)
probably not `tar`, but why not `pax`? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-5230414 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] RPM v6 package format, first public draft for commenting (Discussion #2374)
So reading through https://github.com/rpm-software-management/rpm/commit/68c7cf80d7b763498d0077daa91f649bc209e7ae the new format is 'stripped cpio' or did I completely misread that patch. [I guess moving to pax or tar would be a bridge too far :scream_cat: ] -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-5230366 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] Fix ignoring exit code of child scripts in case of EINTR (PR #2398)
@socketpair commented on this pull request. > @@ -273,8 +273,16 @@ static int runGPG(sigTarget sigt, const char *sigfile) if (pipefd[1]) close(pipefd[1]); -(void) waitpid(pid, , 0); OK -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2398#discussion_r1128077640 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] Fix ignoring exit code of child scripts in case of EINTR (PR #2398)
@socketpair commented on this pull request.
> @@ -402,7 +402,19 @@ static int getOutputFrom(ARGV_t argv,
reap:
/* Collect status from prog */
-reaped = waitpid(child, , 0);
+
+do {
+ reaped = waitpid(child, , 0);
+} while (reaped == -1 && errno == EINTR);
+
+// It's not allowed to call WIFEXITED or WEXITSTATUS if waitpid return -1.
+// Note, all bits set, since -1 == 0x
Fixed
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2398#discussion_r1128077353
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] Fix ignoring exit code of child scripts in case of EINTR (PR #2398)
@socketpair pushed 1 commit. 8cb5c6a31a475067d41923b8306f8625dde4a71f Fix ignoring exit code of child scripts in case of EINTR -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2398/files/e36832755b35ae9aa4b5103987e9375e86e08ba3..8cb5c6a31a475067d41923b8306f8625dde4a71f 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] python: Use Py_hash_t instead of long in hdr_hash (PR #2408)
> What tooling/versions is giving this error? I don't doubt that Py_hash_t is > the more proper type here, just that I've never seen the compiler complain > about this. clang16+ -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2408#issuecomment-1458361863 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] RPM v6 package format, first public draft for commenting (Discussion #2374)
Ah, so to be clear the payload is still a CPIO archive, just with the metadata stripped and stored in a within the RPM header? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-5229948 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] RPM 4.18.1 bugfix update (PR #2406)
Maybe a bit too late of an addition, but since #2396 was merged today (thank you!), I wondered if it could also make it into this release, with it being a fix for a regression and all. It would really help us out, thank you! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2406#issuecomment-1458311797 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] GPG key interpreted as PGP key (Issue #2410)
Along with that unconventional issue, the user is probably left with an
unknown: _How to determine how or by who the Red Hat GPG/DSA key was imported?_
Could it be me that imported a such package?
```
$ rpm -qa --scripts gpg-pubkey* --qf '%{version}-%{release} %{packager}\n'
5323552a-6112bcdc Fedora (37)
ba3c3a2c-5eb88cc6 https://packagecloud.io/shiftkey/desktop
(https://packagecloud.io/docs#gpg_signing)
```
I understand that so-called _fake_ package is created in order to satisfy a
non-critical dependency. Then it would be expected to have as output here a
package it is required by. However it is not so. That's confusing.
```
$ rpm -q --whatrequires gpg-pubkey-5323552a-6112bcdc
no package requires gpg-pubkey-5323552a-6112bcdc
```
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2410#issuecomment-1458295913
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 x86-64 architecture levels (v2-v4) as architectures (PR #2315)
> GCC's __builtin_cpu_supports does unfortunately not support all features
> needed to detect these levels properly.
Looks like since GCC 12.2 it actually can do
`__builtin_cpu_supports("x86-64-v3")`:
https://github.com/gcc-mirror/gcc/commit/8ea292591e42aa4d52b4b7a00b86335bfd2e2e85#diff-64afd6a149a7486d332f3d75ac9479f58d0fb674be6920a6e7db0e54cd205e70R38
It's just not documented... Is that an option for RPM? I guess not. It's not
implemented by clang.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1458293778
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] Rpm chroot operations use user/group info from the host (#882)
@pmatilai Is it an option to use `fgetpwent()` and `fgetgrent()` to circumvent glibc's caching? I'm not sure if rpm needs to take into account nsswitch. If it doesn't, using those two functions could be an option. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/882#issuecomment-1458154427 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] Fix ignoring exit code of child scripts in case of EINTR (PR #2398)
@pmatilai commented on this pull request. > @@ -273,8 +273,16 @@ static int runGPG(sigTarget sigt, const char *sigfile) if (pipefd[1]) close(pipefd[1]); -(void) waitpid(pid, , 0); rpmfc lives in a separate library (librpmbuild) which isn't available to librpmsign, but I don't think we'd want to involve that particular mess here anyhow :D -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2398#discussion_r1127793607 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] GPG key interpreted as PGP key (Issue #2410)
Yep, the actual issue here (there *is* one) is that we're calling those keys gpg-anything, when they should be openpgp-pubkey. But renaming would break a lot of 3rd party tooling, and we'd really rather get rid of those entries in the package db to begin with. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2410#issuecomment-1458099635 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] The bit for LZCNT is in CPUID 0x80000001, not 1 (PR #2412)
Merged #2412 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2412#event-8685139800 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] The bit for LZCNT is in CPUID 0x80000001, not 1 (PR #2412)
I'll just take your word on it :see_no_evil: Thanks for the patch! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2412#issuecomment-1458082079 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] Fix ignoring exit code of child scripts in case of EINTR (PR #2398)
@pmatilai commented on this pull request.
> @@ -402,7 +402,19 @@ static int getOutputFrom(ARGV_t argv,
reap:
/* Collect status from prog */
-reaped = waitpid(child, , 0);
+
+do {
+ reaped = waitpid(child, , 0);
+} while (reaped == -1 && errno == EINTR);
+
+// It's not allowed to call WIFEXITED or WEXITSTATUS if waitpid return -1.
+// Note, all bits set, since -1 == 0x
See
https://github.com/rpm-software-management/rpm/blob/master/CONTRIBUTING.md#comments
for comment style.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2398#pullrequestreview-1328280833
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] package after `rpm --delsign` differs from original, unsigned package (Issue #2382)
Closed #2382 as completed via be950eabb84a88e5773e096435c37b92e3d47ebb. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2382#event-8685024651 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] rpm --delsign changes the arch element of the lead (#1326)
Closed #1326 as completed via #2396. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1326#event-8685024394 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] Fix couple of --addsign/--delsign regressions (PR #2396)
Merged #2396 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2396#event-8685024179 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] python: Use Py_hash_t instead of long in hdr_hash (PR #2408)
What tooling/versions is giving this error? I don't doubt that Py_hash_t is the more proper type here, just that I've never seen the compiler complain about this. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2408#issuecomment-1458064636 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] python: Use Py_hash_t instead of long in hdr_hash (PR #2409)
Closed #2409. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2409#event-8684890900 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] python: Use Py_hash_t instead of long in hdr_hash (PR #2409)
Thanks for the backport, but we generally only accept PR's on master branch, backports are cherry-picked at the time of release-creation. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2409#issuecomment-1458038219 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] Drop support for rpm v3 packages (#1107)
There are multiple differences between v3 and v4 packages on the "metadata" level, but perhaps the single most important thing is v4 having immutable header regions. Related to that, v4 has header-only digests and signatures whereas v3 digests and signatures are always on header+payload. The last rpm version that could produce v3 packages was released in 2000. The last significant v3 packaging out there was Sun Java runtime/SDK which only got updated to v4 something like ... ten years ago maybe, and that was five years after everybody else had. In practise, you need to go to a museum to find a v3 package these days. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1107#issuecomment-1457971605 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] Create content handler plugin hook (PR #2416)
### Description This change creates a new `content_handler` plugin hook. This hook can be used by plugins to claim responsability for the package payload. The plugin will then be responsible for: - reading the payload - verifying it - installing the files The main motivation for this change is to enable features like [RPMCoW](https://fedoraproject.org/wiki/Changes/RPMCoW) where the package payload is not in a `cpio` format. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2416 -- Commit Summary -- * Create content handler plugin hook -- File Changes -- M include/rpm/rpmte.h (62) M include/rpm/rpmts.h (12) M include/rpm/rpmtypes.h (10) M lib/depends.c (16) M lib/fsm.c (101) M lib/fsm.h (14) M lib/rpmplugin.h (12) M lib/rpmplugins.c (28) M lib/rpmplugins.h (9) M lib/rpmte.c (38) M lib/transaction.c (34) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2416.patch https://github.com/rpm-software-management/rpm/pull/2416.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2416 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
[Rpm-maint] [rpm-software-management/rpm] Generate user/group provides from systemd sysusers files (Issue #2415)
@lnussel mentioned in https://github.com/rpm-software-management/rpm/discussions/2277#discussioncomment-4145964 that openSUSE already generates user and group provides from systemd-sysusers files. This should be upstreamed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2415 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
