Re: [Rpm-maint] [rpm-software-management/rpm] Fix regression on subpackage debuginfo RPMTAG_SOURCERPM missing (PR #3134)
Merged #3134 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3134#event-12970221871 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: watermark short-circuit'ed binaries (Issue #3091)
Note that Yocto already guts our poison logic from short-circuit builds, since the entire distribution is built short-circuited. https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-devtools/rpm/files/0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3091#issuecomment-2137082520 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] Fix regression on subpackage debuginfo RPMTAG_SOURCERPM missing (PR #3134)
Didnt bisect but this is probably due to mucking around with the src.rpm name generation in dc47a50c6345a25b861305d8aa8ae464098834ff, but its also much saner this way: the info should be copied from the main debuginfo package along with all the other similar stuff. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3134 -- Commit Summary -- * Fix regression on subpackage debuginfo RPMTAG_SOURCERPM missing -- File Changes -- M build/files.c (1) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3134.patch https://github.com/rpm-software-management/rpm/pull/3134.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3134 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] RFE: watermark short-circuit'ed binaries (Issue #3091)
> They can affect the build in a different way depending whether its run > multiple times, there's no guarantee of indempotence there. It would be nice if we started a separate Mock issue, not to steal the topic here. Maybe the related #1358. There are these premises: - Mock has to repeat the process to calculate the "buildroot fixed point" - Mock only ever installs "new build deps", as provided by the last `%generate_buildrequires` feature, and never removes any (minus dependency bugs, and DNF bugs) - The %generate_buildrequires is Turing-complete, and in users' hands, the subsequent runs might well hide the previous outputs, without affecting the buildroot (build finishes fine) If we repeat %prep, are not going to install anything new by Mock (buildroot unaffected), and we may trigger a %generate_buildrequires misbehavior, and thus well bring a "new variable" into the build process rather than stability/idempotence. > let the cat out of the bag uncontrollably and prematurely. Normal evolution? :-) The %generate_buildrequires support has been happening for several years already. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3091#issuecomment-2136998043 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 attempt at restoring + sanitizing --build-in-place (PR #3133)
...but... this links it now to %mkbuilddir which gets disabled in --noprep :facepalm: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3133#issuecomment-2136951806 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] Another attempt at restoring + sanitizing --build-in-place (PR #3133)
See commit messages for details, but this partially reverts d1075106bb315913574e1acac921058d23dd5130 to avoid a dependency on %setup that seems ... wrong for what --build-in-place is. Also, take advantage of rpm macro setup to handle this, so the rpmbuild command doesnt need any logic in it. Which also means %_build_in_place can be set from a spec directly. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3133 -- Commit Summary -- * Move build-in-place logic into librpmbuild * Restore --build-in-place without %setup -- File Changes -- M build/build.c (17) M build/parsePrep.c (17) M rpmpopt.in (2) M tests/rpmbuild.at (8) M tools/rpmbuild.c (14) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3133.patch https://github.com/rpm-software-management/rpm/pull/3133.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3133 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] --build-in-place multiple flaws (Issue #3131)
Just as data point: SUSE's `build` tool (i.e. like `mock`) has both a `--rpm-build-in-place` and a `--rpm-build-in-place-noprep` option. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3131#issuecomment-2136836648 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 multiple flaws (Issue #3131)
This is all very valuable feedback, thanks! Yeah your systemd usage is a rather evolved case, with lots of external (from rpm POV) infra to support it that's not (at least currently) available to rpmbuild alone. Like the writable overlay which makes patching not an issue, but without such a thing its basically down to copy or disable (patches), because otherwise it doesn't work / is not sensible. This probably needs to be switchable somehow. Maybe there could be a macro/script hook you need to define to enable %prep processing with build-in-place, and the hook would be responsible for copying/mounting/whatever (or I guess in your case, just "nop" because its handled elsewhere) magic needed to make patching a meaningful operation. It *could* also be switching to a new temporary branch in git, where you can apply all the patches you want and then restore at end. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3131#issuecomment-2136817705 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 multiple flaws (Issue #3131)
> The more I look/think into this, it seems that --build-in-place should > entirely disable %prep and all Source/Patch processing, because .. that's > what's it all about. Or, it should take a copy of the original source > directory to preserve semi-normal functionality of rpm. So I haven't really settled on this myself yet. In the systemd case, we have two types of patches: backports from upstream and downstream patches. The backports from upstream are of course useless in the --build-in-place scenario, but the downstream patches are useful to keep sometimes. As an example, systemd has a downstream patch to match the systemd upstream PAM snippet to match the Fedora guidelines. That's one patch that is not disabled when the %upstream macro is defined. A copy of the original source directory could be rather slow depending on the project unfortunately, and one of the core benefits of --build-in-place is being able to do fast rebuilds. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3131#issuecomment-2136786731 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 multiple flaws (Issue #3131)
The more I look/think into this, it seems that --build-in-place should entirely disable %prep and all Source/Patch processing, because .. that's what's it all about. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3131#issuecomment-2136757097 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 multiple flaws (Issue #3131)
Yes we just use the fedora spec as is and include it as a git submodule so we can pin each commit in the systemd repository to a specific commit of the spec sources. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3131#issuecomment-2136754246 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 multiple flaws (Issue #3131)
Yeah I ran into some of these while looking at the usages. It doesn't seem exactly easy-to-use feature just now :laughing: Can you point me to the spec file the systemd mkosi setup uses? If it's in the repo, it's not exactly obvious to an outsider. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3131#issuecomment-2136737976 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 multiple flaws (Issue #3131)
I have run into a few of these getting --build-in-place to work for systemd, let me post my workarounds here as extra information: > the only way --build-in-place really makes sense is doing vpath builds, but > we don't natively support that in rpm (yet) I implicitly assume that I can set vpath_builddir which is luckily supported everywhere via distribution macros > %patch should be disabled with --build-in-place because it's not a pristine > source we can return to > source/patch meaning is questionable in the first place, because it's not > what we build there I added a `BuildSourcesEphemeral=` option in [mkosi](https://github.com/systemd/mkosi) which mounts a writable overlay on top of the build sources that is thrown away after the build. This way the spec can patch and change all it wants without those changes persisting after the build. > build-in-place always requires spec to be aware of the action, should it > instead be an option to %setup instead of cli? or maybe it should just skip > %prep entirely, that seems more appropriate for the cause For the systemd spec we had to add `%version_override`, `%release_override` and `%upstream` macros. The first two allow us to build rpms that are guaranteed to be newer than previous ones. We set the version override to the upstream version in git and set the release override to the timestamp of the git commit (or current unix timestamp if the tree is dirty). The upstream macro allows us to accomodate build system changes or other customizations that are only desired for --build-in-place upstream builds. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3131#issuecomment-2136723330 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)
FWIW, a closer look at --build-in-place is turning up a lot of ... stuff. Follow-up in #3131 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3042#issuecomment-2136709440 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)
@nwalfield 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);
A simple locking order would be to lock according to the memory address. But,
that is probably out of scope for this PR.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3083#discussion_r1618289297
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: watermark short-circuit'ed binaries (Issue #3091)
They can affect the build in a different way depending whether its run multiple times, there's no guarantee of indempotence there. And, I agree, rpm should provide a means to perform a continuous run in its own terms, but in the meanwhile --noprep let the cat out of the bag uncontrollably. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3091#issuecomment-2136649989 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: watermark short-circuit'ed binaries (Issue #3091)
If they can affect the build, they can do it even in -ba. If rpm wants to guarantee its own operations, it should provide an API for the caller to handle %generate_buildrequires installations (e.g. via file sockets or pipes or whatever). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3091#issuecomment-2136645805 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: watermark short-circuit'ed binaries (Issue #3091)
This is about *rpm* needing to guarantee its own operations, really. And, those dependency generator scripts can alter the build directory in arbitrary ways, mock cannot guarantee side-effects from those don't affect the build. So it really should do the last -ba run from fresh sources (and I should file this as a mock ticket of course). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3091#issuecomment-2136633104 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: watermark short-circuit'ed binaries (Issue #3091)
Mock guarantees the "production readiness" and "reproducibility" of the result. Running the final -ba without noprep would gain no benefit to mock. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3091#issuecomment-2136608224 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: watermark short-circuit'ed binaries (Issue #3091)
Came up in #3120/#3121: apparently mock uses --noprep quite liberally as an optimization, but it should let the final -ba to produce "production binaries" happen from fresh set of sources. (@praiskup @hroncok) We should also watermark binaries built this way in the future. Ditto for --build-in-place which is handy for testing but *nothing* like a pristine build that rpm promises. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3091#issuecomment-2136582078 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
