[Rpm-maint] [rpm-software-management/rpm] Dynamic generator generates "invalid" srpm (Issue #3096)
~~~ $ curl -OL https://github.com/rpm-software-management/rpm/raw/master/tests/data/SPECS/dynamic.spec % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 1695 100 16950 0 3367 0 --:--:-- --:--:-- --:--:-- 3367 # rpmbuild -D "_sourcedir ." -D "_srcrpmdir ." -D "FULLDYNAMIC 1" -bs dynamic.spec dynamic.spec setting SOURCE_DATE_EPOCH=1666569600 Wrote: ./dynamic-1.0-1.src.rpm Wrote: ./dynamic-1.0-1.src.rpm $ rpm -q --info dynamic-1.0-1.src.rpm Name: dynamic Version : 1.0 Release : 1 Architecture: noarch Install Date: (not installed) Group : (none) Size: 1695 Signature : (none) Source RPM : (none) Build Date : Mon May 13 18:20:44 2024 Build Host : fedora Summary : (none) Description : Simple rpm demonstration. ~~~ I don't think it would be possible to generate RPM without e.g. `Summary`. It also differs to SRPM generated with `-ba`, which contains the summary just fine: ~~~ $ rpm -q --info dynamic-1.0-1.src.rpm Name: dynamic Version : 1.0 Release : 1 Architecture: noarch Install Date: (not installed) Group : Utilities Size: 1695 License : GPL Signature : (none) Source RPM : (none) Build Date : Mon May 13 18:22:44 2024 Build Host : fedora URL : http://rpm.org Summary : dynamic hello -- hello, world rpm Description : Simple rpm demonstration. ~~~ -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3096 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] Free old cookie value to prevent a memory leak (PR #3095)
This keeps the old behaviour of overriding the cookie. This may not me correct as the code looks like it reads the cookie from the srpm when doing rpmbuild --rebuild for the purpose of preserving it. Otoh the current behaviour with overriding it even in this case has been around for years. This whole cookie business seems to have some other issues, too, and needs further investigation. Here we are only trying to fix the memory leak. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3095 -- Commit Summary -- * Free old cookie value to prevent a memory leak -- File Changes -- M build/pack.c (1) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3095.patch https://github.com/rpm-software-management/rpm/pull/3095.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3095 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] sysusers.d support applies %attr() ownership before creating sysusers (Issue #3073)
I started a discussion on the Fedora devel list: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/IKWECWMBWN2IDKLHK3Q2TZKVSVFTXUNA/ -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3073#issuecomment-2107596045 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 test-suite under Fedora 40 modern C rules (PR #3094)
Merged #3094 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3094#event-12787374762 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 test-suite under Fedora 40 modern C rules (PR #3094)
Oh, right, my bad... The SRPM is of course not used in the autopatch test specifically (the tarball is separate indeed). And it's fixed in the SRPM for a reason (to avoid the compiler warning, now error). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3094#issuecomment-2107566757 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 test-suite under Fedora 40 modern C rules (PR #3094)
The modernization patch never was included in the src.rpm, it's only in separate specs based off that hello.spec. And, we still have the original hello-1.0.tar.gz to which the modernize patch applies (and is applied) in various other tests. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3094#issuecomment-2107560693 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 test-suite under Fedora 40 modern C rules (PR #3094)
IOW, it seems like a noop patch now (haven't tested manually). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3094#issuecomment-2107558740 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 test-suite under Fedora 40 modern C rules (PR #3094)
I wonder what happened to the "modernization" patch, though :smile: Since the `hello.c` file now has the patch "applied" in the SRPM. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3094#issuecomment-2107555261 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] cmake: move os-release parsing into oci branch (PR #3052)
(As a cosmetic touch up, I've also switched up the lines with the `find_program()` ones so that the conditional below reads more naturally.) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3052#issuecomment-2107493844 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] cmake: move os-release parsing into oci branch (PR #3052)
Merged #3052 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3052#event-12786825281 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 test-suite under Fedora 40 modern C rules (PR #3094)
Multiple tests are failing on Fedora 40 due to their distro-wide C modernization effort, which cause our ancient hello world package to fail due to implicit printf() function usage. There are two separate issues here: - hello-autopatch.spec had off-by-one in its patch application, causing the modernization patch to not apply (see #3093 for the reason) - others were using the original hello-1.0-1.src.rpm from 2007 with some very outdated practises, code and md5 hashes Update the src.rpm, removing silly fubar while were at it. Regenerated now on x86_64 so adjust the test-expectation, and update the python archive test to calculate sha256 instead. And, fix the autopatch test numbers. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3094 -- Commit Summary -- * Fix test-suite under Fedora 40 modern C rules -- File Changes -- M tests/data/SPECS/hello-autopatch.spec (4) M tests/data/SRPMS/hello-1.0-1.src.rpm (0) M tests/rpmpython.at (2) M tests/rpmquery.at (2) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3094.patch https://github.com/rpm-software-management/rpm/pull/3094.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3094 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] cmake: move os-release parsing into oci branch (PR #3052)
The `DOCKERFILE` variable also needs to be set inside the block (since it uses `OS_NAME` as well). I've fixed up the commit accordingly. Otherwise, looks good, thanks for the patch! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3052#issuecomment-2107446933 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] cmake: move os-release parsing into oci branch (PR #3052)
@dmnks pushed 1 commit. 4a8634a5776ce301c9145bffc27152923b3e4c8a cmake: move os-release parsing into oci branch -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3052/files/c93c0530c6930165c7bbebd644050b7c14d14cea..4a8634a5776ce301c9145bffc27152923b3e4c8a 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] %autopatch -m/-M fall through silently if no patches are in range (Issue #3093)
hello-autopatch.spec in our testsuite has this: ``` %patchlist hello-1.0-modernize.patch hello-1.0-install.patch %prep %autosetup -N %autopatch 1 %autopatch -m 2 ``` Spot the error? Automatic patch numbers start from zero, so we're telling it to apply hello-1.0-install.patch and then any higher numbered patches, so the modernize patch is never applied. There are legitimate reasons to conditionally skip patches, but having a ranged patch that doesn't actually do anything should at least emit a warning. How did we find out? Fedora 40 introduced stricter, more modern C compilation settings (https://fedoraproject.org/wiki/Changes/PortingToModernC ) and suddenly we had a test-case go red because it wasn't applying a patch it's supposed to, to address this very issue. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3093 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: drop rpmlib() poisoning from --short-circuit'ed binaries (Issue #3091)
I think we just see this a bit differently… I don't think it's "encouraging" to allow something to be done via an explicit option. The reason why I'd prefer to have no marking at all is that personally, most commonly I use short-circuit to do repeat builds while tweaking either the %install or %files sections or the Provies/Obsoletes/Conflicts sections and compare the results using `rpmdiff` and `diffoscope`. Injection of the marking is going to show up in those listings. Obviously it can be filtered out or ignored, but it's always an additional step to take, and it's be just more convenient to not have to do that. (Obviously, just a "watermark" is much better than the previous state where the rpms were not installable without `--nodeps`, making them unusable for many tests.) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3091#issuecomment-2107348162 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 proper logic for debuginfo enablement (PR #3085)
Just noting it here that since distros are widely overriding %__spec_install_post, they'll need to update that to match the new logic in there. @ffesti's version placed the %_enable_debuginfo_packages test into %__spec_install_pre which isn't as widely overridden and so would be more backwards compatible, but then it wouldn't be all in one place. It's a hugely annoying mess :unamused: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3085#issuecomment-2107200152 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: cleanly support post-stripping actions in spec (Issue #3092)
Looking at Fedora packages, there's a very distinct use-case for which multiple packages have to override the entire %__spec_install_post section: stripping changes checksums and the like, and any embedded signatures in files will have to be (re)done after the stripping. As the kernel.spec puts it: ``` # Disgusting hack alert! We need to ensure we sign modules *after* all # invocations of strip occur, which is in __debug_install_post if # find-debuginfo.sh runs, and __os_install_post if not. ``` This pattern causes a verbatim copy of %__spec_install_post to be carried in affected packages (nettle, nss, openssl, gnutls, libgcrypt, you get the picture), and as ever with copies, they get out of sync and lack features/fixes when there are changes to the original. We need to offer a clean way to do this without needing ugly copies and overrides. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3092 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: drop rpmlib() poisoning from --short-circuit'ed binaries (Issue #3091)
The bad is that it disagrees with rpm design philosophy where the package goes from a source to a binary in one uninterrupted reproducible (in a sense) go. It's of course possible to circumvent that in any number of ways, but encouraging it by making it easy is a whole can of worms. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3091#issuecomment-2107164699 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: drop rpmlib() poisoning from --short-circuit'ed binaries (Issue #3091)
Just a watermark would be much better than _status quo_. > There have been people wanting to distribute packages built with > short-circuit, just to shorten their build times basically. Actually, I don't think this would be so bad. There are countless ways in which somebody can mess up a package build. In particular, just put wrong files or badly compiled files in the package and there isn't much that the build system can do against that. If somebody is savvy enough to successfully set a build system that uses some form of caching and short-circuit, why would this be a problem? I think trying to prevent this is similar to trying to prevent somebody from using inappropriate build flags, i.e. not possible to actually implement and actually not useful. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3091#issuecomment-2107148807 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] Upstream debuginfo enablement (PR #3040)
Closed #3040. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3040#event-12783537201 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] Upstream debuginfo enablement (PR #3040)
This is superseded by #3085 which solves is similarly but even a bit cleaner. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3040#issuecomment-2106981500 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] rpmspec does not expect debuginfo rpm for a subpackage (Issue #1878)
Closed #1878 as completed via #3085. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1878#event-12783522217 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] Properly upstream debuginfo enablement (Issue #2204)
Closed #2204 as completed via #3085. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2204#event-12783522105 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 proper logic for debuginfo enablement (PR #3085)
Merged #3085 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3085#event-12783521877 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] rpmspec does not expect debuginfo rpm for a subpackage (Issue #1878)
Closed #1878 as completed via 8535694599ee7f35747d44e2ea0a62dc5e8880e5. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1878#event-12783522273 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 proper logic for debuginfo enablement (PR #3085)
Release notes need to mention this and that distribution need to drop the
```
%install %{?_enable_debug_packages:%{?buildsubdir:%{debug_package}}}\
%%install\
%{nil}
```
hack in *-pm-config. So this probably needs to go into the "Compatibility"
section at least in parts.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3085#issuecomment-2106940575
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 proper logic for debuginfo enablement (PR #3085)
This is even cleaner than my own variant. Great so see we got this to the point where it can be done this cleanly. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3085#issuecomment-2106923789 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] Always create %specpartsdir on build (PR #3084)
Merged #3084 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3084#event-12783120373 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] Dynamic spec generation depends on %setup (for no good reason) (Issue #3063)
Closed #3063 as completed via #3084. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3063#event-12783120658 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] Always create %specpartsdir on build (PR #3084)
Guess this is how the %specpartsdir should have been created in the first place. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3084#issuecomment-2106916674 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 proper logic for debuginfo enablement (PR #3085)
Had a brief look at killing %__debug_package, but that gets more complicated
than it should (and who's surprised?) So many packages rely on redefining
%debug_package to %{nil} for disabling debuginfo generation that we just have
to preserve that for the time being, and having %debug_package define something
else as a side-effect is an easy (if ugly) way to handle this. Not worth
messing with just now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3085#issuecomment-2106828884
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 proper logic for debuginfo enablement (PR #3085)
Mentioned the %setup-less debuginfo case and added an explicit sub-test for it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3085#issuecomment-2106811147 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 proper logic for debuginfo enablement (PR #3085)
@pmatilai pushed 1 commit. 8abfcff2ec15d750f9f92d7a8053413fe888172e Add proper logic for debuginfo enablement -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3085/files/d8ad95f93cfb362390e3f0249d9bcbcad7eb4d5a..8abfcff2ec15d750f9f92d7a8053413fe888172e 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 proper program logic for debuginfo enablement (PR #3036)
Closed #3036. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3036#event-12782153559 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 proper program logic for debuginfo enablement (PR #3036)
Closing in favor of #3085 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3036#issuecomment-2106783596 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 proper logic for debuginfo enablement (PR #3085)
Yeah it's nice to be able to use the dynamic spec stuff for our own purposes. To clarify, #3084 is only needed for the "rpmbuild %caps" test which intentionally does not use %setup to test that case, and whose debuginfo now gets generated. So that's basically another bug fixed / limitation eliminated, I could've sworn we have a ticket on debuginfo requiring %setup but can't find it. I haven't tested but it may well cure #3042 too because the combo means it no longer requires the full %setup thing to run. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3085#issuecomment-2106780415 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: drop rpmlib() poisoning from --short-circuit'ed binaries (Issue #3091)
> The whole idea of "prevent people from distributing them" doesn't make much > sense. You cannot build a package with --short-circuit "accidentally". It's a > very long option that you need to insert in the right place. And I guess > "otherwise" means "maliciously" here Obviously you can't use --short-circuit accidentally, the accident refers to distributing a binary built that way. Think of a lone developer uploading a binary built on their own system to the net for others to use. That's not as common these days as it once was, nowadays thankfully most people use actual build systems. The "otherwise" doesn't refer to malice, but ignorance. There have been people wanting to distribute packages built with short-circuit, just to shorten their build times basically. But 14 years later (7583fcc3416e5e4accf1c52bc8903149b1314145) and hopefully a bit wiser too: a gentler version would be simply to "watermark" short-circuited builds somehow. It doesn't have to be a install-breaking dependency, just something that you can check. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3091#issuecomment-2106778640 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] --short-circuit poisons the produced packages (Issue #3091)
> Only with --short-circuit we "poison" the produced packages to prevent people from distributing them (accidentally or otherwise). It is a misfeature. It means that the produced packages cannot be compared and tested properly. In particular, `--short-circuit` is very often used to tweak and test details of `Obsoletes` and `Requires` and such. Not being able to produce the package that looks *exactly* like the normal output makes the build not useful. The whole idea of "prevent people from distributing them" doesn't make much sense. You cannot build a package with `--short-circuit` "accidentally". It's a very long option that you need to insert in the right place. And I guess "otherwise" means "maliciously" here, and that's even less useful, because the person doing the build has full control over what is built, so they don't need to use `--short-circuit` to achieve malicious goals. Instead of using `--short-circuit`, people are forced to either wait for full package builds (which can be hours), or do dirty tricks like comment out part of the spec file. Those solutions are much worse (and much more likely to go wrong), than the problem being solved, i.e. people forgetting that they used `--short-circuit` and distributing those packages. Please drop this whole protection and let people use `--short-circuit` without any limitations. _Originally posted by @keszybz in https://github.com/rpm-software-management/rpm/issues/3042#issuecomment-2074531384_ -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3091 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
