That %install definition is a bug in its own right: #2204 - yes, this is an
upstream issue.
As for build-in-place alternatives, not really, the very concept of building
from whatever happens to be around is alien to rpm's design of pristine
sources.
--
Reply to this email directly or view
@mlschroe there are still DSA keys in use somewhere?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2723#issuecomment-2059388504
You are receiving this because you are subscribed to this thread.
Message ID:
Oh it's certainly not the best way imaginable, it'd be nice to move this all to
a script or something, but ... its complicated. The decision to create
debuginfo packages must happen before %install in the spec is parsed, because
*extracting* debuginfo is hooked into %__spec_install_post based
@nmanthey pushed 1 commit.
2c26ff0d2f023e24c65b57b1bc25256b5e8846e8 rpmbuild,check: verify file hashes
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3039/files/9c34a39a7716123e3ad2adf755db12f5db83dc98..2c26ff0d2f023e24c65b57b1bc25256b5e8846e8
You are receiving this
Excellent, thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3034#issuecomment-2058321276
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint
Merged #3034 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3034#event-12482993321
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
An alternative implementation to #3036
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3040#issuecomment-2058639717
You are receiving this because you are subscribed to this thread.
Message ID:
Rpm allows URLs as cli parameters. The files are then automatically
downloaded with %_urlhelper which defaults to curl(1). For far failures
have been ignored right away and error messages are generated later when
the file was not found on disk.
Issue a meaningful error message at least when the
This really needs to be done with `%_enable_debug_packages 1` as default in
macros.in.
With that, this fails on 332 and 409, so there's at least that much more work
to do.
--
Reply to this email directly or view it on GitHub:
! This removes the %ifnarch noarch check. We need to find a solution for this
before merging (or decise it is just an optimization we dont really need)
All these years, enabling debuginfo has required distros to hijack the spec
%install section with a macro like this:
%install
**Describe the bug**
The %install to make debuginfo work is currently defined as follows on Fedora:
```
%install %{?_enable_debug_packages:%{?buildsubdir:%{debug_package}}}\
%%install\
%{nil}
```
The `--build-in-place` documentation says:
```
--build-in-place
Build from
Like #3040, this would need to pass with `%_enable_debug_packages 1` in the
main macros file (currently it fails a bunch).
It's an interesting solution, but I don't see making it any less magic, perhaps
to the contrary.
--
Reply to this email directly or view it on GitHub:
AFAIK for `--build-in-place`, `%buildsubdir` doesn't need to be defined. If I
remove the check from the `%install` override, debuginfo packages are generated
without problems.
--
Reply to this email directly or view it on GitHub:
Would be great if https://github.com/rpm-software-management/rpm/issues/3042
could also be fixed at the same time as it touches the same logic.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3040#issuecomment-2058887932
You are
--build-in-place is a hack that doesn't fit well into rpm's view of the world,
I doubt debuginfo is the only thing that doesn't work with that. Thanks for the
report though.
--
Reply to this email directly or view it on GitHub:
Now with debug packages enabled by default.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3036#issuecomment-2058940742
You are receiving this because you are subscribed to this thread.
Message ID:
With this, #3036 now passes with debuginfo enabled by default.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3043#issuecomment-2058941726
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #3043 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3043#event-12488348307
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
@pmatilai Is there by any chance a better way than `--build-in-place` to do
builds using a local checkout of the sources? I'd be happy to switch to
something else that fits more within rpm's view of the world if that exists.
--
Reply to this email directly or view it on GitHub:
I think you broke DSA signatures: it calls `EVP_PKEY_verify` with `padded_sig`
which is constructed from just `sig->r`. But `constructDSASignature` (called
at the beginning) takes `sig->r` and `sig->s` and creates a DSA_SIG from it.
I'm pretty sure PKEY_verify to be passed something DER
As we need to check all file lists we need to have them parsed - even if %build
and %install have not been run due to --short-circuit
Tested manually with #3040. There is fixes test 334.
You can view, comment on, or merge this pull request online at:
@pmatilai pushed 2 commits.
63cdb8add41c1708f23e681239f628ba7fd00e3d Add proper program logic for
debuginfo enablement
33068282eef319bfe7687d177718962dd904c32f Enable debuginfo package generation
by default now that we can
--
View it on GitHub:
> @mlschroe there are still DSA keys in use somewhere?
[FESCO decided](https://pagure.io/fesco/issue/2960) decided that Fedora 38
would continue to accept DSA keys, and that Fedora 39 should disable them.
Looking at the fedora crypto policies repository, however, [they appear to
still be
@keszybz I filed this here given
https://github.com/rpm-software-management/rpm/pull/3040 and
https://github.com/rpm-software-management/rpm/pull/3036 are going to move this
into rpm itself
--
Reply to this email directly or view it on GitHub:
Actually, this is probably not the right tracker for this bug.
The problematic definition is from
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/macros#_302,
so maybe it'd be better to file a bug against the package.
--
Reply to this email directly or view it on GitHub:
25 matches
Mail list logo
