~~~
$ 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
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
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:
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
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:
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
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:
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
(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
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
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
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:
@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
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
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
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
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
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
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
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
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:
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:
___
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:
___
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
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:
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
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
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
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:
___
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:
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
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:
@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
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
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: ___
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
> 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
> 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
38 matches
Mail list logo
