There seems to be a behavior difference when executing `rpm -qa` or `rpm -qa
--qf %{NAME}` via sudo vs a non-privileged user. When executing via sudo its
been shown to error out with a bad DB:
```
hirpmdb: Thread/process 85454/140624466790144 failed: Thread died in Berkeley
DB library
error:
Currently i have:
```
pcmsi-i7-4790k:~ # rpm -qa wine
wine-7.21-lp154.1505.2.x86_64
wine-7.22-lp154.970.1.x86_64
pcmsi-i7-4790k:~ #
```
well it IS only installed once, so this is strange as such.
i remove the one existing version
```
pcmsi-i7-4790k:~ # rpm -ev wine-7.22-lp154.970.1.x86_64
I double checked the spec file and it's not messing with the mode and the
source filed themselves are set exactly like the other 1200 files. Let me see
if I can work up a reproducable example.
--
Reply to this email directly or view it on GitHub:
> For backward-compatibility and to avoid surprises, default to building x86_64
> even on v2+ capable machines.
> Tested by running rpm --eval %_target_cpu and using rpmbuild with various
> BuildArch values on a x86_64_v3 host.
Looks like my fix for the platform macros generation broke that
The documentation is somewhat lacking, but it seems to me that once upon a time
specifying multiple elements in BuildArch resulted in multiple builds being
done (if the buildarch is deemed compatible).
I think this was broken in 2001 with commit
c3835f5ca0e3ea856213a22367233e148ea26550, which
I think it'd be worth looking at @dmach / @ffesti's
[libparch](https://github.com/rpm-software-management/libparch) to get us a
consistent way to handle all this. Then everything in the ecosystem can rely on
a single mechanism (libsolv, librpm, libdnf, etc.).
--
Reply to this email directly
I think it'd be worth looking at @dmach/@ffesti's
[libparch](https://github.com/rpm-software-management/libparch) to get us a
consistent way to handle all this. Then everything in the ecosystem can rely on
a single mechanism (libsolv, librpm, libdnf, etc.).
--
Reply to this email directly or
To the best of my knowledge, hwcaps are _not supported_ by musl-libc
(@richfelker, can you confirm?) and other non-glibc platforms that RPM is
commonly used on.
--
Reply to this email directly or view it on GitHub:
About the glibc mismatch:
The missing BMI and BMI2 are included in git master with
https://sourceware.org/pipermail/libc-alpha/2022-October/142395.html meanwhile.
OSXSAVE was still missing, I sent a patch for that:
https://sourceware.org/pipermail/libc-alpha/2022-December/143936.html
Once
It's absurd that rpm has all manner of assembler magic to perform cpu
detection. Rpm is not interested in the cpu bits and flags and their weird
names at all, the only really relevant thing is somehow mapping toolchain
optimizations to packages, and their compatibility with whatever is we're
After some further processing:
Seeing now a concrete way out of this arch detection madness, I can accept the
current version as-is, just considering it a temporary measure (for some
definition of temporary). Let's see if there's further feedback over the
weekend or so, and then I'll just hit
Well. Of course it's exported by glibc through the dlopen() search path: we
just build + place dso's into the paths where glibc looks for and then dlopen()
that rpm_platform.so (or such) from rpmrc.c. At the minimum, the dso merely
needs to return an arch string, but there are almost certainly
If the main concern is the addition of assembly, there are options:
* https://github.com/anrieff/libcpuid which is packaged in many distributions
already for handling cpu feature detection via cpuid
* *cough* parsing /proc/cpuinfo for level determination
--
Reply to this email directly or view
Ack.
In the meanwhile I managed to dig up some additional background on this, eg
https://sourceware.org/pipermail/libc-alpha/2020-July/116135.html,
https://lwn.net/Articles/844831/ and
https://antlarr.io/2021/03/hackweek-20-glibc-hwcaps-in-opensuse/ (which even
routes back here :laughing: ).
14 matches
Mail list logo
