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
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...
Oh, truly. Let me drop that, too, then. One can never be overly conservative
with updates :smile:
> * split testing population into a script
@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
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
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
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
> 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`
> 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 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:
%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
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
> > 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.
>
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
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)"
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
16 matches
Mail list logo
