[Rpm-maint] [rpm-software-management/rpm] /usr/bin/rpmsign: Documentation bug: rpmsign vs rpm (Issue #3125)
Below is the bug report I submitted to Debian, but they wanted me to report it to you instead. Package: rpm Version: 4.18.0+dfsg-1+deb12u1 Severity: minor File: /usr/bin/rpmsign Tags: upstream Upstream documentation bug: ~>man rpmsign rpm --addsign|--resign [rpmsign-options] PACKAGE_FILE ... rpmsign-options [--rpmv3] [--fskpath KEY] [--signfiles] ~>rpm --addsign --rpmv3 rpm: --rpmv3: unknown option ~>rpm --addsign --fskpath asdasd --signfiles asd rpm: --fskpath: unknown option ~>rpm --addsign --signfiles asd rpm: --signfiles: unknown option All of these rpmsign-options can only work when running rpmsign as opposed to rpm. This bug also applies to Centos 7 and Oracle Linux 9, where I've been doing some testing. It looks like it was introduced between Centos 6 and 7, if that helps anyone. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3125 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: Standardize on OCI images for test-suite, even locally (Issue #2643)
Argh... :facepalm: :smile: re-reading mkosi's man page again, it of course supports multiple `Distribution=` values... meaning that, if that distro's package manager is available on your host, it'll be used. Either way, the point still kinda holds :smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-2127657774 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: Standardize on OCI images for test-suite, even locally (Issue #2643)
> ... however it requires a reasonably recent OS version (and/or mkosi) on the > host, as well as a reasonably recent package manager of the OS you're > targeting. Oops, I got this wrong: Mkosi doesn't require the *target* OS's package manager. It uses the *native* one, whichever it is on the host you're building the image on. The issue I wanted to get across was that the package *selection* is still tied to the native package manager (e.g. APT on Ubuntu). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-2127645197 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: Standardize on OCI images for test-suite, even locally (Issue #2643)
Oh, I'd missed your comment @DaanDeMeyer, sorry! Yep, I indeed *did* consider mkosi initially and even had a branch where I played with it for a couple of weeks. However, later I realized the philosophy of mkosi wasn't completely in line with our requirements (and that's OK!), which were: 1. Reuse the local, native cmake build directory and install those artifacts into the target image, instead of doing a separate build on the side (like `mkosi build` does). Basically, we want the test-suite to exercise the user's build directory (that they'd have anyway) rather than keeping an additional one on the side. 2. Allow for cross-building images (e.g. build a Fedora image on an Ubuntu host). This is of course the core feature of mkosi, however it requires a reasonably recent OS version (and/or mkosi) on the host, as well as a reasonably recent package manager of the OS you're targeting. This is a hard requirement for us because we need to run the test-suite in a CI environment where we can't control the host/VM OS selection. Currently, we use GitHub Actions which only has Ubuntu 22.04 LTS. And building a target image based on Ubuntu wouldn't work for us either because Ubuntu isn't RPM's main target platform and thus doesn't have the latest dependencies. 3. Rootless image building. I know this is already supported in mkosi for a while but it wasn't when I was considering it (so it was another factor). So it eventually turned out that using OCI images was the best solution for us. The tooling is ubiquitous and already preinstalled on the Ubuntu VMs in the CI (as well as typical developer systems). In retrospect, though, I would've talked to you, indeed, if just to understand the whole landscape where mkosi operates better. There certainly are nice features in mkosi that we could use, OTOH right now we're happy with the OCI setup and wouldn't gain much (if anything) by switching. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2643#issuecomment-2127616052 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] debuginfo generation does not work with --build-in-place (Issue #3042)
Closed #3042 as completed via #3124. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3042#event-12910199015 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 --build-in-place much less of a hack and also, work (PR #3124)
Merged #3124 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3124#event-12910198636 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 --build-in-place much less of a hack and also, work (PR #3124)
LGTM, thanks! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3124#issuecomment-2127226593 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] Implement merging of new key material when importing pubkeys (PR #3083)
@pmatilai commented on this pull request.
> @@ -229,6 +229,28 @@ char * rpmPubkeyBase64(rpmPubkey key)
return enc;
}
+rpmRC rpmPubkeyMerge(rpmPubkey oldkey, rpmPubkey newkey, rpmPubkey *mergedkeyp)
+{
+rpmPubkey mergedkey = NULL;
+uint8_t *mergedpkt = NULL;
+size_t mergedpktlen = 0;
+rpmRC rc;
+
+pthread_rwlock_rdlock(>lock);
+pthread_rwlock_rdlock(>lock);
I don't think we have a defined locking order for anything in rpm. The locks on
they keys are probably a bit hokey to begin with because librpm and threads is
playing with fire anyway.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3083#discussion_r1611406952
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] Implement merging of new key material when importing pubkeys (PR #3083)
@pmatilai commented on this pull request. > @@ -509,6 +509,19 @@ int pgpSignatureType(pgpDigParams sig); */ char *pgpIdentItem(pgpDigParams digp); +/** \ingroup rpmpgp + * Merge the PGP packets of two public keys + * @param pkts1OpenPGP pointer to a buffer of first certificates + * @param pkts1len length of the buffer with first certificates + * @param pkts2OpenPGP pointer to a buffer of second certificates + * @param pkts2len length of the buffer with second certificates + * @param pktsm[out] merged certificates (malloced) + * @param pktsmlen[out]length of merged certificates + * @param flagsmerge flags (currently not implemented) I'd rather have a flags arg we never end up using than not having it when we need it. Rpm is traditionally terribly sloppy with these, but indeed it'd be good to state the only legit value now is 0 so people don't end up passing random stuff that hurts us later (been there). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3083#discussion_r1611400268 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] %mkbuilddir breaks the %generate_buildrequires implementation in mock (Issue #3121)
Closed #3121 as completed via #3122. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3121#event-12906903696 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 --noprep regression from introducing %mkbuilddir (PR #3122)
Merged #3122 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3122#event-12906903427 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] Another bunch of STL conversions (PR #3119)
Merged #3119 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3119#event-12906806871 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] %mkbuilddir breaks the %generate_buildrequires implementation in mock (Issue #3121)
The biggest issue here was really that there were no tests on --noprep whatsoever, so when I wasn't even aware of the feature... luckily this was easy enough to sort out. *knocks wood* -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3121#issuecomment-2126664965 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] %mkbuilddir breaks the %generate_buildrequires implementation in mock (Issue #3121)
I'm not sure there's much to do about that now, the ship sailed a long ago. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3121#issuecomment-2126653511 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 --noprep regression from introducing %mkbuilddir (PR #3122)
@pmatilai pushed 2 commits. 67a2f8fe7c8ae7488d4485b4c0475f3816e57860 Fix --noprep regression from introducing %mkbuilddir 2542a424cb90a7cab24fd240221eb5a3e238fd47 Drop an accidentally added duplicated test -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3122/files/3df37d50f4633a8319623aa1606547780a428939..2542a424cb90a7cab24fd240221eb5a3e238fd47 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] %mkbuilddir breaks the %generate_buildrequires implementation in mock (Issue #3121)
>From @pmatilai at #3121: > I can see why mock would use such a thing, but I'm not really comfortable > with that (or the option itself) because it seems that mock is now driving > the build and not rpmbuild. And this means any changes to rpmbuild are even > more difficult than they are otherwise. Where would be the best place to discuss this further? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3121#issuecomment-2126599733 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] %mkbuilddir breaks the %generate_buildrequires implementation in mock (Issue #3121)
Seconded, these were almost unusually detailed and actionable, thanks guys! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3121#issuecomment-2126536301 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] %mkbuilddir breaks the %generate_buildrequires implementation in mock (Issue #3121)
Thanks BTW @hroncok and @praiskup for the detailed reports! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3121#issuecomment-2126518649 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 --build-in-place much less of a hack and also, work (PR #3124)
Instead of skipping everything in %setup, take advantage of it: we shouldnt unpack any sources but otherwise we can just let it fall through it, defining buildsubdir and everything, if we let rpm do its normal %mkbuilddir thing and just symlink to the in-place tree from rpms %builddir. This way its not such an ugly duckling interfering with how normal rpms are built, and even honors %setup flags to a degree. This fixes two regressions: one introduced when adding %mkbuilddir that nukes your current directory with no questions asked if --build-in-place is used before it even starts, and an earlier one from commit b34333fa021c0ee7215714eeef96d1a2843ea08e that would nuke your precious in-place directory afterwards. And as a side-effect of all this, debuginfo generation also now works with --build-in-place. Fixes: #3122 Fixes: #3042 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3124 -- Commit Summary -- * Make --build-in-place much less of a hack and also, work -- File Changes -- M build/parsePrep.c (17) M tests/rpmbuild.at (55) M tools/rpmbuild.c (8) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3124.patch https://github.com/rpm-software-management/rpm/pull/3124.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3124 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/3...@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] Add Fedora integration CI job (Issue #3118)
Here's another, even more embarrassing case that would've been discovered if Mock had been actually tested with the new stack: #3120, #3121 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3118#issuecomment-2126490849 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] --build-in-place regression from %mkbuilddir (Issue #3123)
Okay, but then --build-in-place has required --noclean to avoid the directory getting nuked since commit b34333fa021c0ee7215714eeef96d1a2843ea08e. Which is another regression actually, in rpm 4.18 I guess. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3123#issuecomment-2126345882 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] --build-in-place regression from %mkbuilddir (Issue #3123)
Similar and related to #3121, --build-in-place got very much broken by %mkbuilddir, and will *erase* the directory you're trying to build in. If that happens to be a source directory you're developing something in, you could lose actual data. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3123 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
