Closed #2426 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2426#event-8723256067
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint ma
I figured out my problem: [In fedora 36, the rpm dbpath changed from
`/var/lib/rpm` to
`/usr/lib/sysimage/rpm`](https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr).
To demonstrate the fact that using the correct dbpath works:
`ID="$(podman create registry.access.redhat.com/ubi8/ubi:latest)"
While debugging https://github.com/OpenSCAP/openscap/issues/1942 I discovered
that a newer version of rpm cannot read older rpm databases. I expected this to
work, as I thought rpm was backwards compatible in this way and I haven't been
able to find documentation that says otherwise.
I did some
> > 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.
>
Right, but that says that (at least one) v4 release will be able to handle v6
packages to a large degree, and this is a preresquisite.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2423#issuecomment-1464288871
You are receiving this b
%bcond_set_libmpeg does not carry enough meaning. The other two proposals do
and I don't have a preference.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2405#issuecomment-1464010710
You are receiving this because you are subscribed to
> It's not implemented by clang.
https://github.com/llvm/llvm-project/issues/59961
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1463940613
You are receiving this because you are subscribed to this thread.
Message ID:
> 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 featu
> It's just not documented... Is that an option for RPM? I guess not. It's not
> implemented by clang.
It's documented here:
https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html#index-_005f_005fbuiltin_005fcpu_005fsupports-1
(though we wrongly documented that under `__builtin_cpu_is`
Sorry for not commenting earlier, this was a busy week.
It's true that this can be done in the specfile, but that can lead to each
individual package maintainer using a different way. I think it's worthwhile
that the mechanism is the same for all distributions. The goal is exactly that
it work
RPMFI_NOFILESIGNATURES and RPMFI_NOVERITYSIGNATURES should be included in the
RPMFI_FLAGS_ONLY_FILENAMES mask but are not, so eg `rpmfiNew (ts, h,
RPMTAG_BASENAMES, RPMFI_FLAGS_ONLY_FILENAMES)` ends up loading both IMA and
FSVERITY signatures into the file iterator when it should not.
The signa
Another update, this time removing the following:
8a74780c0 check-buildroot: harden $tmp creation
fb6ad2c74 check-buildroot script: use if-then-else
f2b4c647c check-buildroot: Redirect xargs stderr to $tmp
11458278a check-buildroot script: Double-Quote the variables
fd3ef9b09 check-buildroot scrip
@dmnks pushed 78 commits.
2c0459a25aa9174373bb514bd8bb4246b03b56c0 Document need to do history research
on behavior changes
49b5fffd958c532497d7e223ff1c9429e9f31a17 Add more on pull requests to
CONTRIBUTING
dae67690507ef192d64b0029105614615418293a Fix potential uninitialized variable
use in
> If you want to trim your budget more:
>
> * the check-buildroot cleanups, that script has been there for > 20 years
> without those changes...
Oh, truly. Let me drop that, too, then. One can never be overly conservative
with updates :smile:
> * split testing population into a script
rpm-sequoia 1.3 returns NOTTRUSTED instead of BAD, causing those two tests to
fail.
I don't think it's worth it trying to come up with a solution to support both
behaviors, we'll just fix the test-suite behavior once we get rpm-sequoia 1.3
in our CI environment, one way or the other.
--
Reply
If you want to trim your budget more:
- the check-buildroot cleanups, that script has been there for > 20 years
without those changes...
- split testing population into a script
- drop historic remnants from test-suite PATH (unless something later depends
on these two test-suite changes)
Not tha
16 matches
Mail list logo