**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 Rep
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
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`.
--
Repl
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.
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:/
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-
Without the newline, a sysusers file like
```
u saned - "SANE daemon user" /etc/sane.d /bin/false
m saned cdwriter
m saned usb
m saned scanner
```
Results in "funny" requirements
```
group(cdwriter)user(saned)
group(usb)user(saned)
```
You can view, comment on, or merge this pull request online a
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
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 j
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 a
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@li
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-
@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
_
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 direc
@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
@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
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 /us
Seems to happen reliably with this simplified test case (even while just
building a src.rpm)
[test.zip](https://github.com/rpm-software-management/rpm/files/1851751/test.zip)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Yes, just traced it to exactly that line as well.
Adding an "if(shdr.sh_entsize == 0) continue;" just before it fixes the
problem. Will send a pull request for that...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://
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 --
* Fi
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-ma
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 rpmr
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
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=
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-poin
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
@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 e
@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
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 --
* I
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@li
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 --
ht
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@li
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#issuecomme
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 implemen
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 simil
Handle zstd compressed man/info pages in brp-compress
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/997
-- Commit Summary --
* brp-compress: Handle zstd compressed man
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.
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 packa
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 woul
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__
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 do
41 matches
Mail list logo