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:
```
#===
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
> 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 basicall
> 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, the
> 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,
> th
> 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
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/
The algorithm used for installing hardlinks does not handle the case where a
package upgrade includes additional names for an inode. It iterates the list of
files from the beginning until the end and only writes content and metadata for
the last occurence of an inode.
For upgrades, there is no h
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-6474
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
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
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
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 acc
I see. For this case at least the mapping is not really useful.
How did this work with the old dep generators? Not at all, I assume?
--
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/
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 i
> 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 s
> 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 beca
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+
> 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 r
> 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 l
@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 p
> > 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
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
> 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
> > 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 bro
> > 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 merg
> 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: __
@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 p
> 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 effec
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
> 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-64afd6a
> 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
> > 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.
>
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
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...:
```
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-soft
@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-
> __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#issuec
@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 i
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/250
> 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
> 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
@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-
> 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 somethin
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").
45 matches
Mail list logo
