Re: [Rpm-maint] [rpm-software-management/rpm] Enhance requires with version information from the build root. (PR #2372)
> The other thing I'm wondering is whether we can (or should) label the > .elf-version files, so that package managers can skip installing them, the > same way that documentation is not installed in container images > (RPMTRANS_FLAG_NODOCS). The .elf-version files aren't needed at runtime, > they're only needed in build roots. It's arguably package metadata and doesn't belong in the filelist at all if possible IMO -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2010490504 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] Enhance requires with version information from the build root. (PR #2372)
> In Fedora, packages that fail to build from source are eventually retired > along with all of their dependencies, and (basically) everything is rebuilt > for every release, so we wouldn't expect old libraries to mix with new > applications, there. But if SUSE doesn't retire those packages, then they > could continue using an older library package in a new build root, when they > build a new application that depends on an old library. For Leap vs. Tumbleweed there's a ~6y gap for some packages so I don't expect any compatibility there. What can happen is that e.g Leap 15.6 with this PR builds an application against a library from 15.5 built without this PR. That still needs to be installable, either using your `.elf-version` approach or maybe some other that inspects which capabilities the library provides. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2010359486 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] Enhance requires with version information from the build root. (PR #2372)
> One of the SUSE list members mentioned that they want to continue to be able > to use LEAP packages as dependencies, and I think this approach addresses > that concern. Is it about using library packages from Leap (old) on Tumbleweed (new)? If so, I'd argue that is simply invalid and basically what this approach should protect against. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2372#issuecomment-2008954902 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] Clarify %_build*, %_host* and %_target* macros (Discussion #2889)
Thanks, so I'm not alone. I do wonder how it was initially intended to work, either the `--target` option is wrong or the `%configure` macro is... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2889#discussioncomment-8383850 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] Clarify %_build*, %_host* and %_target* macros (Discussion #2889)
I stumbled across an issue in relation to the %_host_* and %_target* macros
which subtly broke some builds because of armv7l/armv7hl differences. This led
me to dig into this a bit further and at this point I'm now unsure how those
macros are actually meant to be used.
macros.in says:
```
#==
# config.guess platform macros.
# Macro(s) similar to the tokens used by configure.
#
%_build %{_host}
%_build_alias %{_host_alias}
%_build_cpu %{_host_cpu}
%_build_vendor %{_host_vendor}
%_build_os %{_host_os}
%_host @host@
%_host_alias@host_alias@%{nil}
%_host_cpu @host_cpu@
%_host_vendor @host_vendor@
%_host_os @host_os@
%_target%{_host}
%_target_alias %{_host_alias}
%_target_cpu%{_host_cpu}
%_target_vendor %{_host_vendor}
%_target_os %{_host_os}
```
The `@host*@` placeholders are set to whatever CMake runs on (e.g.
`CMAKE_HOST_SYSTEM_PROCESSOR`), i.e. on what platform RPM was built on. I think
this is already wrong. In the (currently unlikely) case that RPM was cross
compiled, e.g. on an x86_64 machine to run on riscv64, @host_cpu@ and thus
`%_host_cpu` would be x86_64. What machine RPM was built on should not have any
effect on RPM though.
And then I'm confused about the role of build/host/target here. From my
understanding, having all three of them implies the toolchain semantics:
build -> where the build happens
host -> where the built binary runs on
target -> what the built binary (e.g. compiler) targets
Question remains from which PoV this is. From RPM's PoV or the .spec file's PoV?
The rpmbuild `--target` option changes which architecture the built RPMs can be
installed on and sets `%_target*` accordingly. This points to RPM's PoV. The
`%configure` macro however uses `%{_configure} --host=%{_host}
--build=%{_build}`, which means it's from the .spec file's PoV. This doesn't
match. Example:
```
> cat test.spec
Name: test
Version: 0
Release: 0
License: WTFPL
Summary: Test
%description
%build
echo %_target
set +e
%configure
touch l
%files
%license l
> rpmbuild -bb --target=i686-unknown-linux test.spec
Building target platforms: i686-unknown-linux
Building for target i686-unknown-linux
Executing(%build): /usr/bin/bash -e /var/tmp/rpm-tmp.AGeJEj
[...]
+ echo i686-linux
i686-linux
+ set +e
+ CONFIG_SHELL=/usr/bin/bash
+ export CONFIG_SHELL
+ CFLAGS='-O2 -g -m32 -march=i686 -mtune=i686 -fmessage-length=0
-D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
-fasynchronous-unwind-tables'
+ export CFLAGS
[...]
+ ./configure --host=x86_64-suse-linux --build=x86_64-suse-linux
--program-prefix= --disable-dependency-tracking --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib
--libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib
--mandir=/usr/share/man --infodir=/usr/share/info
/var/tmp/rpm-tmp.AGeJEj: line 46: ./configure: No such file or directory
+ touch l
+ RPM_EC=0
++ jobs -p
+ exit 0
Processing files: test-0-0.i686
[...]
Provides: test = 0-0 test(x86-32) = 0-0
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <=
4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files
/home/fvogt/rpmbuild/BUILDROOT/test-0-0.i386
Wrote: /home/fvogt/rpmbuild/RPMS/i686/test-0-0.i686.rpm
[...]
```
As you can see, configure was invoked to create a binary to run on
`x86_64-suse-linux` but it spat out an RPM for i686: `test-0-0.i686.rpm`.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2889
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] Actually return an error in parseScript if parsing fails (PR #2554)
The return value is stored in the res variable which is set to the return value of parseLines early in the function. Past that point, any goto exit; caused the function to return success. This was introduced by 52ce88851abb (Port parseScript() to use parseLines(), no functional changes). To fix it, reintroduce the nextPart variable. CC @pmatilai as author of the commit introducing the regression. Before this change, script sections with parse error caused an error message during built but then were just ignored and are missing in the binary package: ``` cat test.spec Name: pkg Summary: Nothing to see here Version: 0 Release: 0 License: WTFPL %description . %pre -p magic world.issues = 0; %files rpmbuild -bb *.spec error: line 12: unsupported internal script: magic Processing files: pkg-0-0.x86_64 Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/fabian/rpmbuild/BUILDROOT/pkg-0-0.x86_64 Wrote: /home/fabian/rpmbuild/RPMS/x86_64/pkg-0-0.x86_64.rpm Executing(%clean): /usr/bin/bash -e /var/tmp/rpm-tmp.0LZpaW + umask 022 + cd /home/fabian/rpmbuild/BUILD + /usr/bin/rm -rf /home/fabian/rpmbuild/BUILDROOT/pkg-0-0.x86_64 + RPM_EC=0 ++ jobs -p + exit 0 Executing(rmbuild): /usr/bin/bash -e /var/tmp/rpm-tmp.L5DAPK + umask 022 + cd /home/fabian/rpmbuild/BUILD + RPM_EC=0 ++ jobs -p + exit 0 echo $? 0 rpm -qp --scripts /home/fabian/rpmbuild/RPMS/x86_64/pkg-0-0.x86_64.rpm (nothing) ``` With this, the build fails: ``` LD_LIBRARY_PATH=/tmp/rpmprefix/lib64/ /tmp/rpmprefix/bin/rpmspec -P *.spec error: line 12: unsupported internal script: magic echo $? 1 ``` This issue was hit in practice through a typo in a `%transfiletriggerin`: ``` %transfiletriggerin -P 1000600 -p lua -- /usr/lib/tmpfiles.d -- This script will process files installed in /usr/lib/tmpfiles.d to create -- tmpfiles automatically. The priority is set such that it will run -- after the sysusers file trigger, but before any other triggers. -- Note: /run is never mounted during transactional updates. if posix.access(/run/systemd/system) then assert(rpm.execute(systemd-tmpfiles, --create)) endf ``` Now it fails the build with `error: invalid syntax in lua scriptlet: [string %transfiletriggerin]:7: syntax error near eof` You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2554 -- Commit Summary -- * Actually return an error in parseScript if parsing fails -- File Changes -- M build/parseScript.c (6) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2554.patch https://github.com/rpm-software-management/rpm/pull/2554.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2554 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Use __builtin_cpu_supports in x86-64 CPU feature level detection (PR #2508)
> Preprocessor is with me if that's how they're implemented in gcc and clang. Ok, done. If a compiler doesn't support `__builtin_cpu_supports`, only `x86_64` is detected. Currently this happens silently, should the stub function print something at `RPMLOG_INFO` or `RPMLOG_DEBUG`? Doing something like `#warning` for a message during build would probably get ignored anyway and `#warning' isn't standard C either... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2508#issuecomment-1594654581 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] Use __builtin_cpu_supports in x86-64 CPU feature level detection (PR #2508)
@Vogtinator pushed 2 commits. ff8538a829f64ce61a1cf852bbb8374d5a3005b0 Use __builtin_cpu_supports in x86-64 CPU feature level detection c4b5c8205fc50edfb623e4c21cd3832c70e140c5 For completeness, make sure CPUID leaf 7 is supported before using it -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2508/files/58c3ebb1e2c807aeabafa364dd7a530ce6d6bb9c..c4b5c8205fc50edfb623e4c21cd3832c70e140c5 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] Use __builtin_cpu_supports in x86-64 CPU feature level detection (PR #2508)
> We don't have any officially supported (or unsupported) compilers other than > the C99 requirement. gcc and clang are of course by far the most used ones, > so if those are covered by just testing for the availability, the platforms > that matter most are covered and everybody else (including ancient gcc/clang) > maybe gets a slightly degraded experience but that's life. Ok. Is it ok to perform this check in the preprocessor (e.g. `#if defined(__has_builtin) && __has_builtin(__builtin_cpu_supports)`) or does it have to be done in CMakeLists? If the latter, it'll be a bit annoying without `check_source_compiles` which is only in 3.19+. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2508#issuecomment-1560891244 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] Use __builtin_cpu_supports in x86-64 CPU feature level detection (PR #2508)
> I meant more like only use it if detected available. FWICT it's supported by GCC 7.1 (haven't checked older) and in clang since 2015. Are other compilers supported? > And if this whole thing relies on it, then perhaps we should only detect > these newer variants if __builtin_cpu_supports() is available. Yes. Though it's IMO weird that in under those circumstances RPM would then just ignore some architectures. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2508#issuecomment-1560847987 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] Use __builtin_cpu_supports in x86-64 CPU feature level detection (PR #2508)
FTR, the alternative is to use more inline asm... There is an `__xgetbv` intrinsic but apparently that was broken for a while on GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85684) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2508#issuecomment-1560806873 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] Use __builtin_cpu_supports in x86-64 CPU feature level detection (PR #2508)
@Vogtinator commented on this pull request.
> const unsigned int op_1_ecx_lv2 = bit_SSE3 | bit_SSSE3 | bit_CMPXCHG16B
> | bit_SSE4_1 | bit_SSE4_2 | bit_POPCNT;
if ((op_1_ecx & op_1_ecx_lv2) == op_1_ecx_lv2 && (op_8001_ecx &
bit_LAHF_LM))
level = 2;
const unsigned int op_1_ecx_lv3 = bit_FMA | bit_MOVBE | bit_OSXSAVE |
bit_AVX | bit_F16C;
const unsigned int op_7_ebx_lv3 = bit_BMI | bit_AVX2 | bit_BMI2;
-if (level == 2 && (op_1_ecx & op_1_ecx_lv3) == op_1_ecx_lv3 && (op_7_ebx &
op_7_ebx_lv3) == op_7_ebx_lv3
-&& (op_8001_ecx & bit_LZCNT))
+if (level == 2 && (op_1_ecx & op_1_ecx_lv3) == op_1_ecx_lv3
+&& op_0_eax >= 7 && (op_7_ebx & op_7_ebx_lv3) == op_7_ebx_lv3
+&& (op_8001_ecx & bit_LZCNT)
+&& __builtin_cpu_supports("avx2"))
level = 3;
Fixed
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2508#discussion_r1203772865
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] Use __builtin_cpu_supports in x86-64 CPU feature level detection (PR #2508)
> __builtin_cpu_supports() is nothing like a standard, we can't just assume it > exists. That's what I asked on the issue and nobody objected, so I took that as acknowlegement. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2508#issuecomment-1560758010 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] Use __builtin_cpu_supports in x86-64 CPU feature level detection (PR #2508)
@Vogtinator pushed 2 commits. 8fd972a3ae697402f8004e43f467ab3e29526400 Use __builtin_cpu_supports in x86-64 CPU feature level detection 58c3ebb1e2c807aeabafa364dd7a530ce6d6bb9c For completeness, make sure CPUID leaf 7 is supported before using it -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2508/files/82b5d7af7eb0527c87f2711814d0adf75bc99f04..58c3ebb1e2c807aeabafa364dd7a530ce6d6bb9c 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] Use __builtin_cpu_supports in x86-64 CPU feature level detection (PR #2508)
Just CPUID is not enough and neither is just __builtin_cpu_supports, so use both. Fixes: https://github.com/rpm-software-management/rpm/issues/2463 @fweimer Anything else this could possibly be missing? You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2508 -- Commit Summary -- * Use __builtin_cpu_supports in x86-64 CPU feature level detection * For completeness, make sure CPUID leaf 7 is supported before using it -- File Changes -- M lib/rpmrc.c (18) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2508.patch https://github.com/rpm-software-management/rpm/pull/2508.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2508 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] x86-64-v3, x86-64-v3 detection must take XCR0 into account (Issue #2463)
That indicates it uses it even for XMM, i.e. SSE might also not be available?
There's even more fun: If OSXSAVE isn't set, then xgetbv raises #UD.
However, this part can be implemented in a slightly nicer way by using compiler
runtime support, which hopefully meanwhile does it correctly...:
```
diff --git a/lib/rpmrc.c b/lib/rpmrc.c
index 66ce947ae..22659e086 100644
--- a/lib/rpmrc.c
+++ b/lib/rpmrc.c
@@ -790,11 +790,13 @@ static int get_x86_64_level(void)
const unsigned int op_1_ecx_lv3 = bit_FMA | bit_MOVBE | bit_OSXSAVE |
bit_AVX | bit_F16C;
const unsigned int op_7_ebx_lv3 = bit_BMI | bit_AVX2 | bit_BMI2;
if (level == 2 && (op_1_ecx & op_1_ecx_lv3) == op_1_ecx_lv3 && (op_7_ebx &
op_7_ebx_lv3) == op_7_ebx_lv3
-&& (op_8001_ecx & bit_LZCNT))
+&& (op_8001_ecx & bit_LZCNT)
+&& __builtin_cpu_supports("avx2"))
level = 3;
const unsigned int op_7_ebx_lv4 = bit_AVX512F | bit_AVX512DQ |
bit_AVX512CD | bit_AVX512BW | bit_AVX512VL;
-if (level == 3 && (op_7_ebx & op_7_ebx_lv4) == op_7_ebx_lv4)
+if (level == 3 && (op_7_ebx & op_7_ebx_lv4) == op_7_ebx_lv4
+&& __builtin_cpu_supports("avx512f"))
level = 4;
return level;
```
Opinions? For GCC this is documented, for clang it is not...
If this is acceptable, I'll make a PR with proper explanation.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2463#issuecomment-1494345021
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] x86-64-v3, x86-64-v3 detection must take XCR0 into account (Issue #2463)
The OSXSAVE bit should be effective for that. glibc doesn't do anything else either. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2463#issuecomment-1494301674 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] Add x86-64 architecture levels (v2-v4) as architectures (PR #2315)
> > FWICT, the auxiliary vector for HWCAPS is no longer really used and > > applications (including glibc, gcc runtime code) have to resort to methods > > like this instead. GCC's `__builtin_cpu_supports` does unfortunately not > > support all features needed to detect these levels properly. > > What feature do you miss? Note that using `__builtin_cpu_supports` would be > much cleaner code and it's supported also by LLVM. Of the one mentioned here: > AVX + AVX2 + F16C + FMA + LZCNT + MOVBE + BMI + BMI2 + OSXSAVE F16C, LZCNT, MOVBE and OSXSAVE aren't exposed through `__builtin_cpu_supports`, except by using `x86-64-v3`. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1464415351 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] The bit for LZCNT is in CPUID 0x80000001, not 1 (PR #2412)
> I'll have to reach out to the GCC maintainers to clarify what's going on > there. Reported upstream as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109081 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2412#issuecomment-1462220351 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] Add x86-64 architecture levels (v2-v4) as architectures (PR #2315)
> GCC's __builtin_cpu_supports does unfortunately not support all features
> needed to detect these levels properly.
Looks like since GCC 12.2 it actually can do
`__builtin_cpu_supports("x86-64-v3")`:
https://github.com/gcc-mirror/gcc/commit/8ea292591e42aa4d52b4b7a00b86335bfd2e2e85#diff-64afd6a149a7486d332f3d75ac9479f58d0fb674be6920a6e7db0e54cd205e70R38
It's just not documented... Is that an option for RPM? I guess not. It's not
implemented by clang.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1458293778
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] The bit for LZCNT is in CPUID 0x80000001, not 1 (PR #2412)
The GCC headers put bit_LZCNT into the list for CPUID 1 %ecx values, but that corresponds to VMX. LZCNT is actually advertised in CPUID 0x8001 %ecx, which is also referred to as ABM by AMD and some other places. This bug was partially inherited from GCC, which uses LZCNT wrongly and also has an ABM feature which maps to the same bit. Ill have to reach out to the GCC maintainers to clarify whats going on there. I hope we get some unified place for all this mess at some point... You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2412 -- Commit Summary -- * The bit for LZCNT is in CPUID 0x8001, not 1 -- File Changes -- M lib/rpmrc.c (7) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2412.patch https://github.com/rpm-software-management/rpm/pull/2412.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2412 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow to specify a default for bcond features in a macro file (PR #2405)
> Is putting something like `%bcond foo 0%{?default_foo}` in the spec file not
> an option?
Technically yes, but like bconds itself which are just syntactic sugar, it
would be nice to get something like this out of the box and working universally.
Currently the design of bconds makes them effectively worse than just plain
macros in my experience. When just using macros like this, it's possible to
provide a value in macros, allow overriding that with an `rpmbuild` parameter,
specify a default in the .spec file and it can even take arbitrary values
instead of just boolean ones!
```
%dnl Provide a default
%{!?enable_foo:%global enable_foo 1}
%dnl Or error out if unset
%{!?enable_foo:%error enable_foo not set}
%if %{enable_foo}
BuildRequires: foo
%else
BuildRequires: bar
%endif
```
The only benefit of bconds is that `rpmbuild` has nicer syntax for `--with(out)
foo` and it's easier to translate bconds into commandline switches using the
`%{?_with_foo:--foo}` syntax. I'd like something that combines the strengths of
simple macros with the special benefits of bconds.
I'm not sure what's easier: Add something to make handling of macros like this
easier or extend bconds to allow for more flexibility?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1456387757
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] Add x86-64 architecture levels (v2-v4) as architectures (PR #2315)
@Vogtinator commented on this pull request. > @@ -1063,6 +1063,10 @@ package or when debugging this package.\ # %ix86 i386 i486 i586 i686 pentium3 pentium4 athlon geode +#-- +# arch macro for all supported x86_64 processors +%x86_64x86_64 x86_64_v2 x86_64_v3 x86_64_v4 amd64 em64t IMO `x86_64v2` looks weird. If someone else also requests that I'll change it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2315#discussion_r1055308541 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] Add x86-64 architecture levels (v2-v4) as architectures (PR #2315)
> See issue #2319 Perfect match - so indeed a mostly independent topic. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1352967373 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? The reason for that is that `BuildArch` only sets `%_target_cpu`, but not anything else like `%_target` or `%optflags`: https://github.com/rpm-software-management/rpm/blob/e2c504c08381519c81774791fe6b82eb064a072e/build/parseSpec.c#L1012-L1025 IMO this can be treated as a separate bug (or is this intentional?). Opinions? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1352898530 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] 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] RFC: Add x86-64 architecture levels (v2-v4) as architectures (PR #2315)
> > FWICT, the auxiliary vector for HWCAPS is no longer really used and > > applications (including glibc, gcc runtime code) have to resort to methods > > like this instead. > > It's one thing for gcc and glibc getting their hands dirty with details and > maybe to always get the latest info you need to do it yourself, but we're not > _that_ leading edge here. > > Got any pointers indicating hwcaps being deprecated? I haven't looked at > details but I remember fairly recent activity around HWCAPS, such as > https://sourceware.org/pipermail/libc-alpha/2020-May/113757.html. I meant `AT_HWCAP`s for x86_64, which just stopped being extended with new features at some point. `AT_HWCAP` has only pre-x86_64 features and `AT_HWCAP2` has just `HWCAP2_RING3MWAIT` and `HWCAP2_FSGSBASE` . On arm64 and riscv it's much more useful instead. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1343970204 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)
@Vogtinator commented on this pull request. > @@ -1063,6 +1063,10 @@ package or when debugging this package.\ # %ix86 i386 i486 i586 i686 pentium3 pentium4 athlon geode +#-- +# arch macro for all supported x86_64 processors +%x86_64x86_64 x86_64_v2 x86_64_v3 x86_64_v4 amd64 em64t `-` is used as separator between nevra components in various places, I didn't want to cause any issues in that regard. The canonical name of those levels is `x86-64-vX`, so I just continued the `s/-/_/` trend that Linux and RPM started. I don't really care myself though. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2315#discussion_r1043570903 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)
> FWIW, I've repeatedly said "no" to attempts to add more assembly into rpm, > the only direction for assembly code is _out_. Use the auxiliary vector for > determining features, and for things that are not there, I don't think rpm > needs to care. FWICT, the auxiliary vector for HWCAPS is no longer really used and applications (including glibc, gcc runtime code) have to resort to methods like this instead. GCC's `__builtin_cpu_supports` does unfortunately not support all features needed to detect these levels properly. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1342687505 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)
> can you please include in `macros.in` also a %x86_64 macro that covers this > new family of architectures? Done, also fixed missing platform macros. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1342668471 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] RFC: Add x86-64 architecture levels (v2-v4) as architectures (PR #2315)
The x86_64 SysV psABI defines four levels of x86_64 with certain CPU features required for each level. Those definitions are meant to be generically useful and recognized as such by glibc and gcc as well. 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. This should be less controverisal than adding CPU model specific architectures such as `znver1` (https://github.com/rpm-software-management/rpm/pull/1035). There might be one slight issue: The psABI document defines x86-64-v3 as x86-64-v2 + AVX + AVX2 + F16C + FMA + LZCNT + MOVBE + BMI + BMI2 + OSXSAVE, but glibcs hwcaps code only looks at x86-64-v2 + AVX + AVX2 + F16C + FMA + LZCNT + MOVBE (no BMI, BMI2 or OSXSAVE). Not sure whether thats a bug or for some reason intentional. gcc uses the psABI definition, so code built with `-march=x86-64-v3` is not compatible with `%_libdir/glibc-hwcaps/x86-64-v3/`... CC @Conan-Kudo @dirkmueller @DimStar77 @mlschroe You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2315 -- Commit Summary -- * Add x86-64 architecture levels (v2-v4) as architectures -- File Changes -- M lib/rpmrc.c (75) M rpmrc.in (18) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2315.patch https://github.com/rpm-software-management/rpm/pull/2315.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2315 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] file trigger quirks (#1370)
> That's not true if the package containing the trigger is installed/erased > (the so called "immed" case). Here, the trigger is called with a set of files > coming from multiple packages. In that case the triggering package is the package containing the trigger. -- 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/1370#issuecomment-758575444___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] file trigger quirks (#1370)
> The problem with counting owners is that it's a per-file thing, and a > file-trigger can match any arbitrary number of them, so the count would have > to be per-file and so can't be in the global argument. I should've just > dropped both the global arguments while at it... The documentation says: "File triggers execute once for package". So unlike `%transfiletrigger`, plain `%filetrigger` is called once for each triggering package (including itself, for all matching installed files), so there is a single triggering package for each call. In the case that the triggering package is completely removed (`$1 == 0`), there's a potential issue with files owned by multiple packages, but arguably `%postun` has the same. In this particular case, only the case that `%filetriggerun` is called for all files when the package containing the trigger is upgraded is an issue, which currently can't be detected. Though I currently wonder why `%filetriggerun` is not called when a package with matching files is upgraded. That might just be a case of no (clear) documentation, as if it were called, the script couldn't tell and probably undo the work of `%filetriggerin`. -- 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/1370#issuecomment-758563971___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] file trigger quirks (#1370)
At least for `%filetriggerun`, the hardcoded `0` as argument actually makes it
really dangerous to use properly, as it is also run when the package containing
the trigger is uninstalled/upgraded from. The issue is that the
`%filetriggerun` is called after the new package's `%filetriggerin`, so it
overrides and practically reverses what `%filetriggerin` did.
e.g.
```
%filetriggerin -- %{_infodir}
...
install-info $file
%filetriggerun -- %{_infodir}
...
install-info --delete $file
```
After an upgrade of this package, every file in `%{_infodir}` gets
unregistered. Currently I can't think of a proper workaround, other than
creating and checking a flag file.
--
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/1370#issuecomment-758021866___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Redundant requires from generators are not merged (#1476)
I wrote a requires generator for `.qml` files, which converts import statements to RPM capabilities in the format ``` qt5qmlimport(QtQuick.Controls.2) >= 3 qt5qmlimport(QtQuick.Controls.Layouts.2) >= 3 ``` This works as expected, but the dependency generator is called for each file, so they accumulate. If one file needs version `2.3` and another needs `2.4`, the final package has: ``` qt5qmlimport(QtQuick.Controls.2) >= 3 qt5qmlimport(QtQuick.Controls.2) >= 4 qt5qmlimport(QtQuick.Controls.Layouts.2) >= 3 qt5qmlimport(QtQuick.Controls.Layouts.2) >= 4 ``` The dependency generator is smart enough to only print the highest required version, but that can only work if it's fed with all files inside each package. That doesn't seem to be possible without using the external dep generator... Would it be possible to merge those in RPM itself? Or even better, introduce a flag so that the generator is called only once for each package? That would also provide a speedup. -- 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/1476___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Package upgrades break if hardlinks got added (#1278)
Thanks for the quick fix! -- 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/1278#issuecomment-648050421___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Package upgrades break if hardlinks got added (#1278)
Just found out that this only happens with `%_minimize_writes` enabled, as otherwise even unchanged files are recreated correctly as hardlinks. ``` D: create 100644 2 ( 0, 0) 0 /usr/file1;5ef086f0 D: touch 100644 2 ( 0, 0) 8 /usr/file2 ``` vs. ``` D: create 100644 2 ( 0, 0) 0 /usr/file1;5ef09669 D: create 100644 2 ( 0, 0) 8 /usr/file2;5ef09669 ``` `%_minimize_writes` is the default for SSDs (and on openSUSE in general) though. -- 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/1278#issuecomment-647460998___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Package upgrades break if hardlinks got added (#1278)
I ran the commands again without `--force` and edited the post accordingly. -- 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/1278#issuecomment-647435746___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Package upgrades break if hardlinks got added (#1278)
Yes. I only used `--force` so that I can use the same commands for install, upgrade and downgrade. -- 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/1278#issuecomment-647432588___ 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 a version parsing and comparison API to librpmio (#1221)
Just to make sure, this behaviour change of `rpm.vercmp` in lua is backwards-compatible, right? I would assume so, as any segment is also a valid EVR, but there might be some edge case. Currently we're doing the parsing "by hand" in lua: https://build.opensuse.org/package/view_file/Base:System/rpm/rpmsort?expand=1 I'm really looking forward to drop that for good. -- 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/1221#issuecomment-634628732___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] WIP: RFC: Buildsystem overhaul (meson) (#1209)
> Besides the tests, and the fact that autotools is the devil I know and > prefer, rpm sits really early in the bootstrap chain, and adding significant > extra burden there is not acceptable. If glibc or gcc adopt some > non-autotools based build-system, I'm willing to reconsider. glibc already [needs Python 3 to build](https://sourceware.org/git/?p=glibc.git;a=blob;f=INSTALL;h=b7676d1c9f868e7b98bc4558349056d062182661 ), so it's almost there... I do also think that being able to bootstrap easily is a very important property though. -- 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/1209#issuecomment-625831438___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
