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

[Bernhard Rosenkraenzer]

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:
https://github.com/rpm-software-management/rpm/issues/3115#issuecomment-2133642333
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] %_enable_debug_packages can cause debuginfo on noarch packages (Issue #3115)

[Bernhard Rosenkraenzer]

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:
https://github.com/rpm-software-management/rpm/issues/3115#issuecomment-2133324663
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: support conditional patch application in %autosetup (Issue #3110)

[Bernhard Rosenkraenzer]

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 (e.g. chromium -- and yes I agree they should be 
sent to hell for internalizing half an OS) and keeping patches in sync with the 
corresponding system libraries, or when dealing with something like 
wine-staging (where it may be necessary to apply some patches only after the 
staging script has run).

e.g. in wine-staging
```
%autosetup -p1
[regular patches are applied]
./staging/patchinstall.py
%autopatch -p1 -k staging
[patches specific to -staging applied now]
```

or for a chromium-like example
```
%autosetup -p1
[regular patches are applied]
cd third_party/libevent
%autopatch -p1 -k  libevent
[libevent patches are applied]
```

Of course in the latter example, you could also modify the patch files to 
prefix `third_party/libevent` to all the files being patched, but that would 
make it harder to keep the patches in sync with the system libevent package.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3110#issuecomment-2132416454
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] %_enable_debug_packages can cause debuginfo on noarch packages (Issue #3115)

[Bernhard Rosenkraenzer]

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`.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3115#issuecomment-2132414675
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] `%patchlist` should have a way to group patches (Issue #3109)

[Bernhard Rosenkraenzer]

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`, e.g.

```
Patch0: https://github.com/upstream-project/pull/1234.patch
Patch1: https://github.com/upstream-project/pull/1235.patch
Patch100: https://github.com/other-project/pull/5678.patch
Patch101: https://github.com/other-project/pull/5679.patch
[...]
%autopatch -M 99
cd evil-internalized-copies-of-3rd-party-libs/other-project
%autopatch -m 100
```

(And yes, the correct fix for this is to not use the bundled copy - but it's 
not always possible, e.g. if the internalized version is modified)

With `%patchlist`, there is currently no way [at least none that I'm aware of, 
if it exists, it needs to be documented] to mark which patches should belong to 
which group. It would be nice to be able to do something like

```
%patchlist
https://github.com/upstream-project/pull/1234.patch
https://github.com/upstream-project/pull/1235.patch
100:https://github.com/other-project/pull/5678.patch
https://github.com/other-project/pull/5679.patch
```

where the added `100:` for the first patch from `other-project` would increment 
the internal counter to 100, so
`1234.patch` would be `0`, `1235.patch` would be 1, `5678.patch` would be `100` 
and `5679.patch` would be `101`.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3109
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] `%build -a` and `%install -a` overwrite build/installation instructions from `%buildsystem_*_*` (Issue #3024)

[Bernhard Rosenkraenzer]

**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 Reproduce**
Steps to reproduce the behavior:
Simplified version of the macros I've been playing with (simplified to not call 
any other macros etc. for easier reproducibility etc.):
```
%buildsystem_autotools_conf() \
./configure --prefix=/usr %*
%buildsystem_autotools_build() \
make %*
%buildsystem_autotools_install() \
make install %*
```

Everything works as expected if I don't have any `%build` section in the spec - 
but if I add
```
%build -a
echo test
```
in the spec, only `echo test` is executed, not `make`.

**Expected behavior**
The code is built (`make`), and afterwards `test` is printed.

**Output**
`test` is printed, without any signs of running `make`.

**Environment**
 - OS / Distribution: OpenMandriva Cooker
 - Version rpm-4.19.90

**Additional context**
There's no funky stuff like macros redefining `%build` or something (that 
actually used to be present in older Mandriva versions).
```
$ rpmbuild --eval '%{build}'
%{build}
```

Simplified spec that works:
```
Summary:A utility for determining file types
Name:   file
Version:5.45
Release:1
License:BSD
Url:https://www.darwinsys.com/file/
Source0:ftp://ftp.astron.com/pub/file/%{name}-%{version}.tar.gz
BuildSystem: autotools
BuildOption: --enable-static

%description
A utility for determining file types

%files
/usr
```

Modified version of the spec that shows the problem:
```
Summary:A utility for determining file types
Name:   file
Version:5.45
Release:1
License:BSD
Url:https://www.darwinsys.com/file/
Source0:ftp://ftp.astron.com/pub/file/%{name}-%{version}.tar.gz
BuildSystem: autotools
BuildOption: --enable-static

%description
A utility for determining file types

%build -a
echo test

%install -a
echo test

%files
/usr
```

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3024
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] Odd handing of URLs containing a ? in Source*:/Patch*: lines (#1407)

[Bernhard Rosenkraenzer]

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 just calling both 
chromium-vaapi is problematic.

-- 
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/issues/1407#issuecomment-720126833___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

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

[Bernhard Rosenkraenzer]

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: 
https://aur.archlinux.org/cgit/aur.git/plain/chromium-skia-harmony.patch?h=chromium-vaapi
Patch2: 
https://aur.archlinux.org/cgit/aur.git/plain/fix-invalid-end-iterator-usage-in-CookieMonster.patch?h=chromium-vaapi
results in references to 2 files called "chromium-vaapi", when any regular 
parsing of the URL would expect it to become chromium-skia-harmony.patch and 
fix-invalid-end-iterator-usage-in-CookieMonster.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/issues/1407___
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: read sources checksums from the SPEC file and verify them (#463)

[Bernhard Rosenkraenzer]

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 don't think we want to end 
up with a mess similar to what dpkg has in those debian directories.

-- 
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/issues/463#issuecomment-602719980___
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: read sources checksums from the SPEC file and verify them (#463)

[Bernhard Rosenkraenzer]

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:
https://github.com/rpm-software-management/rpm/issues/463#issuecomment-601710242___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

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

[Bernhard Rosenkraenzer]

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 would be automatically Provide:d by rpm looking at the 
likes of /proc/cpuinfo, and could be manually provided by stuff like 
qemu-binfmt* packages.

Of course it gets a lot trickier when we're dealing with the per-file 
libc.so.6()(64bit) bits, not sure we want something huge like Provides: 
libc.so.6(x86_64)(mmx)(sse)(sse2)(ssse3)(sse4)(sse4_1)(sse4_2)(avx)(avx2) and 
obviously something requiring that wouldn't necessarily know that 
libc.so.6(x86_64) or libc.so.6(x86_64)(mmx) would be sufficient to fulfill the 
dependency.
But obviously the nice thing about it would be that tools like dnf could 
automatically pick between 
libc.so.6(x86_64)(mmx)(sse)(sse2)(ssse3)(sse4)(sse4_1)(sse4_2)(avx)(avx2), 
libc.so.6(x86_64)(mmx)(sse)(sse2) and libc.so.6(x86_64) if multiple options are 
provided.

Of course going down further that route, it may also be necessary to provide 
information about CPU timings to allow picking between e.g. an Intel optimized 
and an AMD optimized build even if both will work on either type 
(-march=generic -mtune=whatever).
But something like
libc.so.6(x86_64)(mmx)(sse)(sse2)(ssse3)(sse4)(sse4_1)(sse4_2)(avx)(avx2)(tune:amd)
can get pretty long...

-- 
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/1038#issuecomment-597692182___
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 znver1 arches with 32-bit + 64-bit variants and proper CPU detection (#1035)

[Bernhard Rosenkraenzer]

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 packages you're intending to use 
with qemu static emulation.
Also installing something that is only available for the wrong architecture 
would know what qemu package it needs to pull in (imagine "dnf install 
my-prehistoric-binary-only-i386-custom-solution" on an ARM box)

-- 
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/1035#issuecomment-588253676___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

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

[Bernhard Rosenkraenzer]

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@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

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

[Bernhard Rosenkraenzer]

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 man/info pages

-- File Changes --

M scripts/brp-compress (5)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/997.patch
https://github.com/rpm-software-management/rpm/pull/997.diff

-- 
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
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

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

[Bernhard Rosenkraenzer]

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 similar compiler 
flags. (Build packages from the same src.rpm on a real OS and on Windoze with 
the M$ compiler or something? Probably nobody is doing that in the real world)

-- 
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/813#issuecomment-520852984___
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 armv8* arch variants to rpmrc.in (#425)

[Bernhard Rosenkraenzer]

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 implemented, probably needs a new name (if not a variant of 
aarch64, given it's closer to aarch64 than to armv7hnl? I'd be leaning towards 
aarch64_32 or something like that)

-- 
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/425#issuecomment-382123819___
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 %arm macro to include newer processor types (#428)

[Bernhard Rosenkraenzer]

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:
https://github.com/rpm-software-management/rpm/pull/428#issuecomment-380203509___
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 %arm macro to include newer processor types (#428)

[Bernhard Rosenkraenzer]

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@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

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

[Bernhard Rosenkraenzer]

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)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/428.patch
https://github.com/rpm-software-management/rpm/pull/428.diff

-- 
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
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

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

[Bernhard Rosenkraenzer]

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@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

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

[Bernhard Rosenkraenzer]

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 Summary --

  * Improve ARM detection

-- File Changes --

M lib/rpmrc.c (32)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/427.patch
https://github.com/rpm-software-management/rpm/pull/427.diff

-- 
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
___
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 armv8* arch variants to rpmrc.in (#425)

[Bernhard Rosenkraenzer]

@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 and NEON are required in 
all standard ARMv8 implementations. However, implementations targeting 
specialized markets may support the following combinations:
No NEON [...]"

Neither gcc nor clang support aarch64 ABI without NEON for now, so targeting 
such a CPU is hypothetical anyway.
So far, the only specialized implementations were 32-bit anyway, but we can't 
rule out a special purpose aarch64 CPU without neon coming out at some point.
Given those (if they ever appear) will be rare and non-standard, if they're 
worth supporting at all they should probably get a modifier instead of 
discouraging people targeting aarch64 from using neon.

For crypto, a modifier may well be useful, aarch64 CPUs exist both with and 
without the crypto extensions.
Do we want to go there even though we don't have something comparable in the 
x86_64 world where it may make sense to have modifiers for SSE4, AVX, AVX2, 
SSE4a, SSE4.1, SSE4.2, .?


-- 
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/425#issuecomment-378906558___
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 armv8* arch variants to rpmrc.in (#425)

[Bernhard Rosenkraenzer]

@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 email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/425#issuecomment-378774168___
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 armv8* arch variants to rpmrc.in (#425)

[Bernhard Rosenkraenzer]

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 -mfloat-abi=hard -mfpu=neon
+optflags: armv8l -O2 -g -march=armv8-a

@kwizart yes, implicit still is -mfloat-abi=soft (both in clang and gcc) even 
though I haven't seen that used on any general purpose CPU in ages -- nobody 
wants to change what everyone has come to expect.

-- 
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/425#discussion_r179052079___
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 armv8* arch variants to rpmrc.in (#425)

[Bernhard Rosenkraenzer]

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 floating-point." -- so armv8hl without n can make some sense for 
specialized CPU variants. Should probably strongly encourage armv8hnl w/ 
buildarchtranslate though, given mostly everyone will target standard armv8...

-- 
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/425#issuecomment-30112___
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 armv8* arch variants to rpmrc.in (#425)

[Bernhard Rosenkraenzer]

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 -mfloat-abi=hard -mfpu=neon
+optflags: armv8l -O2 -g -march=armv8-a
+optflags: armv8hl -O2 -g -march=armv8-a -mfloat-abi=hard -mfpu=neon

Same here, since NEON is mandatory for ARMv8 (that's why there is no -mfpu= 
switch in the aarch64-* compilers), armv8hl and armv8hnl are the same and 
-mfpu=neon will do the right thing.

I don't see any use case for the combination of armv8-a and -mfpu=something 
other than neon, except in the softfloat case (armv8l) if you need to use a 
binary-only library that still doesn't support hardfloat (Android...)

-- 
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/425#discussion_r178352048___
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 armv8* arch variants to rpmrc.in (#425)

[Bernhard Rosenkraenzer]

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 armv8hl are the same thing, so 
it does describe a true superset to subset case. (To be even more correct, 
should probably add arch_compat: armv8hl: armv8hnl -- but I don't think 
circular loops there are a good idea.)

It may be worth arguing armv8hnl shouldn't exist at all (because armv8hl is the 
same and therefore the extra n is superfluous) or armv8hl shouldn't exist at 
all (because armv8hnl is the same and having the n in there is consistent with 
what was done on armv7) -- I've put in both for now to be compatible with what 
either side would expect.

-- 
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/425#discussion_r178351499___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

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

[Bernhard Rosenkraenzer]

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 Changes --

M rpmrc.in (16)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/425.patch
https://github.com/rpm-software-management/rpm/pull/425.diff

-- 
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/425
___
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 division by zero in prelink detection, issue 420 (#421)

[Bernhard Rosenkraenzer]

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 mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

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

[Bernhard Rosenkraenzer]

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 --

  * Fix division by zero in prelink detection, issue 420

-- File Changes --

M rpmio/rpmfileutil.c (2)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/421.patch
https://github.com/rpm-software-management/rpm/pull/421.diff

-- 
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
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

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

[Bernhard Rosenkraenzer]

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 /usr/lib64/librpmio.so.8


gdb backtrace:
#0  0x77f03055 in rpmDoDigest () from /usr/lib64/librpmio.so.8
#1  0x77f87a21 in genCpioListAndHeader () from 
/usr/lib64/librpmbuild.so.8
#2  0x77f89a97 in processBinaryFiles () from /usr/lib64/librpmbuild.so.8
#3  0x77f85a5d in buildSpec () from /usr/lib64/librpmbuild.so.8
#4  0x00402bf3 in buildForTarget ()
#5  0x004025b7 in build ()
#6  0x004022a4 in main ()


-- 
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/issues/420___
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 %optional tag (#417)

[Bernhard Rosenkraenzer]

@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 cross-compilers from the same source 
package, it can be useful to tell the corresponding packages to include 
xmmintrin.h if it's there (target = x86 or x86_64 or x32) and not barf if it 
isn't there (e.g. while building ARM targets).
It gets more complicated than just %ifarch because of cross-compilers (arm 
crosscompiler built on x86_64 won't have xmmintrin.h), so it can get a little 
convoluted.
(And no, just including /usr/lib64/gcc/*/*/include/*.h or the likes doesn't do 
the trick because some of those headers go into C++ or Fortran specific 
subpackages).

The libreoffice language pack bits would be as simple as you're saying if 
libreoffice didn't invent its own directory structure.
We have:
%{_libdir}/libreoffice/program/resource/$LANGNAME <--- contains translations
%{_libdir}/libreoffice/readmes/README_$LANGNAME <--- translated README file
%{_libdir}/libreoffice/share/autotext/$LANGNAME <--- per-language 
auto-completions
%{_libdir}/libreoffice/share/registry/Langpack-$LANGNAME.xcd <--- translation 
metadata
%{_libdir}/libreoffice/share/registry/res/*_$LANGNAME.xcd <--- translated 
resource metadata
%{_libdir}/libreoffice/help/$LANGNAME <--- help files
It was even worse in some older versions with extras along the lines of
%{_datadir}/hyphen/$LANGNAME <--- hyphenation rules
%{_datadir}/autocorr/$LANGNAME <--- autocorrection
(those have moved to separate libraries lately).
There's loads of different combinations of incomplete translations -- some 
languages have translations, but no README, no auto-completion, no help, others 
have a translation, a README, auto-completion, no help, others have only 
translated help, ...

Of course it's possible to generate the help packages by specifying what's 
there for every language (and keep that up to date with every update that has a 
new language related feature or that drops a language), but this is far 
simpler, more readable and less of a pain to maintain:
%optional %{_libdir}/libreoffice/program/resource/$LANGNAME
%optional %{_libdir}/libreoffice/readmes/README_$LANGNAME
%optional %{_libdir}/libreoffice/share/autotext/$LANGNAME
%optional %{_libdir}/libreoffice/share/registry/Langpack-$LANGNAME.xcd
%optional %{_libdir}/libreoffice/share/registry/res/*_$LANGNAME.xcd
%optional %{_libdir}/libreoffice/help/$LANGNAME
%optional %{_datadir}/hyphen/$LANGNAME
%optional %{_datadir}/autocorr/$LANGNAME


-- 
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-373242839___
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 %optional tag (#417)

[Bernhard Rosenkraenzer]

@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 and adapt to changes in new situations automatically 
(e.g. do the right thing for a new architecture in use case 1, addition of 
hyphenator for another language in the 2nd use case).

-- 
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-373227038___
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 %optional tag (#417)

[Bernhard Rosenkraenzer]

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 directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/417#issuecomment-373209826___
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 %optional tag (#417)

[Bernhard Rosenkraenzer]

@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
___
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 %optional tag (#417)

[Bernhard Rosenkraenzer]

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___
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 %optional tag (#417)

[Bernhard Rosenkraenzer]

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@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

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

[Bernhard Rosenkraenzer]

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 all
architectures that have the file -- will also automatically do the right
thing on a new architecture being added)

Another typical use case is in autogenerated file lists, e.g.
per-language subpackages in the likes of libreoffice where all languages
include translations, some languages additionally include dictionaries,
etc. -- with %optional, the same file list can be used for every
language subpackage.

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/417

-- Commit Summary --

  * Add %optional tag

-- File Changes --

M build/files.c (5)
M lib/rpmfiles.h (1)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/417.patch
https://github.com/rpm-software-management/rpm/pull/417.diff

-- 
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
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint