Re: [Rpm-maint] [rpm-software-management/rpm] RFC: Add x86-64 architecture levels (v2-v4) as architectures (PR #2315)
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: ). Indeed these progressive levels (no matter how artificial it may be) is the first glimpse of sanity in the arch space that I've seen in a while. This is something that can reasonably be packaged, and handled by package managers operating on various levels as well. So. Ack for the concept at least, I'll not let this get stuck the way the znver stuff did, because there's hope here. Thanks for the initiative, and the education. I hadn't followed the hwcap side at all really. I'd still try to see if this *really* isn't exported by glibc somehow, eg couldn't we take advantage of the glibc-hwcaps feature somehow (and if that leaves other libc's stuck with one level of x86_64, I'm not going to cry a river). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1343987606 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] RFC: Add x86-64 architecture levels (v2-v4) as architectures (PR #2315)
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 it on GitHub: https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1344024742 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] RFC: Add x86-64 architecture levels (v2-v4) as architectures (PR #2315)
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 some other interesting possibilities in that direction that would allow getting rid of other crap in rpmrc.c. Plus, perhaps things like dynamic rpmlib() provides and who knows. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1344027089 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] RFC: Add x86-64 architecture levels (v2-v4) as architectures (PR #2315)
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 merge. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1344119232 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] RFE: Utilize hwcaps mechnism for arch detection (+ more) (Issue #2318)
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 currently running on. Toolchains + libc's have their own mechanism for this: hwcaps. We can outsource the cpu capability detection to libc by pushing the rpm `uname -p` counterpart to a dynamically loaded library and let the libc load the right one for us. At the minimum, it just needs a function to return the processor name, but there are almost certainly all manner of other opportunities in this direction. Some potential uses could be - eliminate/isolate cruft rpmrc.c - dynamic rpmlib() (or similar) provides - support adding new/custom architectures without having to touch rpm code Inspired by discussion in #2315 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2318 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] RFC: Add x86-64 architecture levels (v2-v4) as architectures (PR #2315)
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 that is merged, glibc, GCC and RPM have matching definitions. LLVM does for some reason not mention OSXSAVE in its documentation, but in the code it's there, so that matches too. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1344138874 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: Utilize hwcaps mechnism for arch detection (+ more) (Issue #2318)
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: https://github.com/rpm-software-management/rpm/issues/2318#issuecomment-1344250165 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: Utilize hwcaps mechnism for arch detection (+ more) (Issue #2318)
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 view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2318#issuecomment-1344268955 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: Utilize hwcaps mechnism for arch detection (+ more) (Issue #2318)
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 view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2318#issuecomment-1344269245 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] Multiple builds via the BuildArch tag do not work (Issue #2319)
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 changed the code to always free the BASpecs array and returning the first element. After the change `spec->recursing` will always be set and the code in build.c that would loop over BASpecs is never used. Should this be made to work again or should we drop support for multiple builds? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2319 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] Multiple builds via the BuildArch tag do not work (Issue #2319)
Also, BuildArch seems to only set %_target_cpu. Shouldn't it also change the optflags? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2319#issuecomment-1344277850 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] RFC: Add x86-64 architecture levels (v2-v4) as architectures (PR #2315)
> 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 part a bit. While with `BuildArch: x86_64_v3` it spits out an `x86_64_v3` RPM, it uses the `x86_64` optflags still. The only way to end up with `x86_64_vX` optflags is by using `--target x86_64_vX`. What's the best way to end up with better semantics? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1344303671 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] "Recognition of file mtype" errors on signed-linear audio files (Discussion #2310)
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: https://github.com/rpm-software-management/rpm/discussions/2310#discussioncomment-4352248 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] RPM shows the same Package in two versions / can only be uninstalled once (Issue #2320)
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 Preparing packages... wine-7.22-lp154.970.1.x86_64 pcmsi-i7-4790k:~ # ``` which works: ``` pcmsi-i7-4790k:~ # rpm -qa wine wine-7.21-lp154.1505.2.x86_64 pcmsi-i7-4790k:~ # ``` now i want to also remove that version. ``` pcmsi-i7-4790k:~ # rpm -ev wine-7.21-lp154.1505.2.x86_64 error: package wine-7.21-lp154.1505.2.x86_64 is not installed pcmsi-i7-4790k:~ # rpm -ev --justdb wine-7.21-lp154.1505.2.x86_64 error: package wine-7.21-lp154.1505.2.x86_64 is not installed pcmsi-i7-4790k:~ # ``` ? again check versions: ``` pcmsi-i7-4790k:~ # rpm -qa wine wine-7.21-lp154.1505.2.x86_64 pcmsi-i7-4790k:~ # ``` what the heck is wrong here, how to get rid of that broken version? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2320 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] RPM Query behavior via sudo vs user (Discussion #2322)
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: db3 error(-30974) from dbenv->failchk: DB_RUNRECOVERY: Fatal error, run
database recovery
error: cannot open Packages index using db3 - (-30974)
error: cannot open Packages database in /var/lib/rpm
```
The issue is clear and the fix is known, however the same host (RedHat) without
sudo, seems to work even with the db issue.
```
% sh -c 'printf hi; /bin/rpm -qa --qf %{NAME}\\n'
hikernel-headers
at
pkgconfig
nss-sysinit
```
The question is why is the behaviour different between the command executing
as root vs a regular user?
I tried to search the code base but my knowledge is limited, and I'm guessing
it has something to do with perhaps establishing a file or db lock or
attempting to write to the db as root for some reason vs a pure read only as a
user.
Any ideas?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2322
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
