Re: [Rpm-maint] [rpm-software-management/rpm] %_enable_debug_packages can cause debuginfo on noarch packages (Issue #3115)

It happens here if I `mock --rebuild any.src.rpm`, nothing special required. Probably koji detects noarch packages and then puts forcearch into the config or something. -- Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] %_enable_debug_packages can cause debuginfo on noarch packages (Issue #3115)

I agree that `rpmbuild -bb --target x86_64 noarch.spec` is nonsense, but (at least here, and I don't see anything too unusual in the config) mock does that. Probably best to just not make mock pass --target unless it's crosscompiling. -- Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: support conditional patch application in %autosetup (Issue #3110)

Adding the use case that was the reason for #3109: It would be good to have a way to apply different groups of patches at different times in the spec file, and in different locations. For example, when building something that insists on bundling internal modified copies of various libraries

Re: [Rpm-maint] [rpm-software-management/rpm] %_enable_debug_packages can cause debuginfo on noarch packages (Issue #3115)

Even with this patch, it can still be triggered by using passing `--target x86_64` while building a package that switches to noarch with `BuildArch: noarch`. (`mock` does this, for example) Probably the relevant bits of the macros are now parsed before `BuildArch` but after `--target`. --

[Rpm-maint] [rpm-software-management/rpm] `%patchlist` should have a way to group patches (Issue #3109)

In a few contexts, it is necessary to make a difference between a few groups of patches that have to be applied at a different time, under different conditions, or in a different subdirectory. Using the traditional `Patch1234:` tags, this is possible with `%autopatch -m ...` / `%autopatch -M`,

[Rpm-maint] [rpm-software-management/rpm] `%build -a` and `%install -a` overwrite build/installation instructions from `%buildsystem_*_*` (Issue #3024)

**Describe the bug** I've just updated my rpm to 4.19.90, and tried out the declarative build bits. Overall, they're working nicely, but `%build -a` doesn't seem to work as documented - instead of adding to `%buildsystem_*_build`, it is treated as the only build/install script present. **To

Re: [Rpm-maint] [rpm-software-management/rpm] Odd handing of URLs containing a ? in Source*:/Patch*: lines (#1407)

I would expect it to be chromium-skia-harmony.patch or fix-invalid-end-iterator-usage-in-CookieMonster.patch because that's what you get if you use wget or curl on the same URLs, given the ? is usually a separator between address and parameters. But either of those would be fine with me, while

[Rpm-maint] [rpm-software-management/rpm] Odd handing of URLs containing a ? in Source*:/Patch*: lines (#1407)

When using an URL containing a ? in Source*:/Patch*: lines, the file name assumed by rpm is truncated to the bits after the ?, not not the filename preceding it. This makes it hard to e.g. reference a patch being "stolen" from Arch Linux since e.g. Patch1:

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: read sources checksums from the SPEC file and verify them (#463)

One problem with the `sources` file is that it is distro specific -- Fedora uses `sources`, OpenMandriva uses a similar file (though with slightly different syntax) called `.abf.yml`, probably other distributions have yet other workarounds. Another problem is that it's not the spec file -- I

Re: [Rpm-maint] [rpm-software-management/rpm] RFE: read sources checksums from the SPEC file and verify them (#463)

Would be really useful to have (of course should be optional to keep old spec files working). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] elfdeps: Add full multiarch deps support (#1038)

For the package overall, it may be best to just use the Provides/Requires mechanism with multiple things being generated, e.g. Requires: cpu(arm) Requires: cpu(neon) Requires: cpu(thumb) or Requires: cpu(x86_64) Requires: cpu(mmx) Requires: cpu(sse) Requires: cpu(sse2) where cpu(*) features

Re: [Rpm-maint] [rpm-software-management/rpm] Add znver1 arches with 32-bit + 64-bit variants and proper CPU detection (#1035)

Come to think of it, it may be best to rework architecture handling to sit on top of Provides: (where there's implied Provides: for anything supported by the CPU). That way emulators like qemu-static-arm could add Provides: arch(armv7hnl) etc. so you wouldn't need to force installation of

Re: [Rpm-maint] [rpm-software-management/rpm] brp-compress: Handle zstd compressed man/info pages (#997)

rebased -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/997#issuecomment-572734503___ Rpm-maint mailing list

[Rpm-maint] [rpm-software-management/rpm] brp-compress: Handle zstd compressed man/info pages (#997)

Handle zstd compressed man/info pages in brp-compress Signed-off-by: Bernhard Rosenkränzer b...@lindev.ch You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/997 -- Commit Summary -- * brp-compress: Handle zstd compressed

Re: [Rpm-maint] [rpm-software-management/rpm] Drop %_lto_cflags macro afterall (#813)

Should be ok -- we've had -flto and friends on regular %{optflags} forever (using %global optflags %{optflags} -fno-lto to override where necessary). The only thing I could foresee breaking (not for OMV) is if someone relies on _lto_cflags to support different compilers that don't even use

Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)

I think this makes most sense (and is what I implemented in the original patch): armv8l == old ABI compatible with armv7l armv8hl == old hardfloat EABI compatible with armv7hl armv8hnl == armv8hl + neon, compatible with armv7hnl armv8hcnl == armv8hnl + crypto extensions ILP32, if properly

Re: [Rpm-maint] [rpm-software-management/rpm] Fix %arm macro to include newer processor types (#428)

Merged into #425 (but leaving the pull request open for now in case 425 doesn't get merged for other reasons) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Fix %arm macro to include newer processor types (#428)

Cc @Conan-Kudo -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/428#issuecomment-380200296___ Rpm-maint mailing list

[Rpm-maint] [rpm-software-management/rpm] Fix %arm macro to include newer processor types (#428)

Signed-off-by: Bernhard Rosenkränzer You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/428 -- Commit Summary -- * Fix %arm macro to include newer processor types -- File Changes -- M macros.in (2) --

Re: [Rpm-maint] [rpm-software-management/rpm] Improve ARM detection (#427)

Cc @Conan-Kudo -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/427#issuecomment-380139813___ Rpm-maint mailing list

[Rpm-maint] [rpm-software-management/rpm] Improve ARM detection (#427)

Unify detection of all armv* architecture subtypes, add support for armv8hcnl (+crypto extensions) detection Signed-off-by: Bernhard Rosenkränzer You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/427 -- Commit

Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)

@mlschroe aarch64 and armv8 are the same CPU, but (obviously, given one is 32bit and one is 64bit) a different ABI -- no need to carry over the legacy float ABI. For neon, all aarch64 CPUs made so far have it, and it is part of the aarch64 core - however, ARM's docs say "Both floating-point

Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)

@n3npq At least in the arm world it's somewhat less insane: uname -m shows what it should, armv7 vs armv8 vs aarch64 etc. is 100% consistent across all processors regardless of manufacturer and marketing names. -- You are receiving this because you are subscribed to this thread. Reply to this

Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)

berolinux commented on this pull request. > @@ -80,6 +80,10 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard > -mfpu=vfp optflags: armv7l -O2 -g -march=armv7 optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 optflags: armv7hnl -O2 -g -march=armv7-a

Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)

According to http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/CJHECGIH.html, "Both floating-point and NEON are required in all standard ARMv8 implementations", but "implementations targeting specialized markets may support the following combinations: No NEON or

Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)

berolinux commented on this pull request. > @@ -80,6 +80,9 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard > -mfpu=vfp optflags: armv7l -O2 -g -march=armv7 optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 optflags: armv7hnl -O2 -g -march=armv7-a

Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)

berolinux commented on this pull request. > @@ -461,6 +472,8 @@ arch_compat: armv5tl: armv4tl arch_compat: armv4tl: armv4l arch_compat: armv4l: armv3l arch_compat: armv3l: noarch +arch_compat: armv8hnl: armv8hl +arch_compat: armv8hl: armv7hnl Since NEON is mandatory on aarch64, armv8hnl and

[Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)

armv8* is aarch64 machines in 32-bit mode Signed-off-by: Bernhard Rosenkränzer You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/425 -- Commit Summary -- * Add armv8* arch variants to rpmrc.in -- File

Re: [Rpm-maint] [rpm-software-management/rpm] Fix division by zero in prelink detection, issue 420 (#421)

Semaphore failure is unrelated to the patch. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/421#issuecomment-376515936___

[Rpm-maint] [rpm-software-management/rpm] Fix division by zero in prelink detection, issue 420 (#421)

Avoid dividing by zero when hitting an ELF section without fixed-size entries. Thanks to Michael Schroeder for helping trace the problem (in #420) You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/421 -- Commit Summary -- *

[Rpm-maint] [rpm-software-management/rpm] rpmbuild Floating Point Exception in rpmDoDigest while packaging guile 2.2.3 (#420)

Packaging guile 2.2.3 results in a Floating Point Exception from rpmbuild. A very similar error occurs while building gdb with guile support enabled. Processing files: guile-runtime-2.2.3-2.x86_64 Program received signal SIGFPE, Arithmetic exception. 0x77f03055 in rpmDoDigest () from

Re: [Rpm-maint] [rpm-software-management/rpm] Add %optional tag (#417)

@n3npq There are arch specific includes in the toolchains themselves (not necessarily located in /usr/include). I'm talking about the likes of xmmintrin.h (which is x86 specific intrinsics for x86 SIMD in gcc) and other bits in /usr/lib64/gcc/*/*/include. Especially when building compilers and

Re: [Rpm-maint] [rpm-software-management/rpm] Add %optional tag (#417)

@n3npq %optional is in rpm5 tarballs -- it originates from "wild hacking in OpenMandriva", but was upstreamed earlier. Please see the first message on this thread for 2 cases where we make use of it. Nothing that can't be done without it, but with it, the spec files can be significantly shorter

Re: [Rpm-maint] [rpm-software-management/rpm] Add %optional tag (#417)

Added tests for everything I could think of -- but couldn't run the tests (local problems related to rpm5->rpm4 switch leaving a couple of things broken), so please double-check I didn't mess them up. -- You are receiving this because you are subscribed to this thread. Reply to this email

Re: [Rpm-maint] [rpm-software-management/rpm] Add %optional tag (#417)

@berolinux pushed 1 commit. a6f4df2 Add tests for %optional -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/417/files/01ea7a2d4f2c88ea4c3ffe172e772c309ea64dd5..a6f4df21206bc0880ffc272d29b74608c05936a2

Re: [Rpm-maint] [rpm-software-management/rpm] Add %optional tag (#417)

semaphore failure seems unrelated to the patch -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/417#issuecomment-373183760___

Re: [Rpm-maint] [rpm-software-management/rpm] Add %optional tag (#417)

Cc @Conan-Kudo -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/417#issuecomment-373178479___ Rpm-maint mailing list

[Rpm-maint] [rpm-software-management/rpm] Add %optional tag (#417)

Add the %optional tag from rpm5 -- it allows to mark a file in the file list as optional, meaning if it's there, it's packaged, but if it isn't there, it will be ignored. A typical use case is %optional %{_includedir}/arch-specific-file.h (easier and shorter than using %ifarch and having to list