Problem Compiling yabridge 3.8.0: error: invalid conversion from 'uint32_t*' {aka 'unsigned int*'} to 'LPDWORD' {aka 'long unsigned int*'
by Martin Gansser
Hi,
I am trying to compile [1] yabridge 3.8.0 on Fedora 35, but I get the following error message:
[22/35] wineg++ -Isrc/wine-host/libhost_common_32bit.a.p -Isrc/wine-host -I../src/wine-host -I../src/include -Isrc/common/config -I../src/common/config -I../subprojects/bitsery/include -I../subprojects/function2/include -I../subprojects/tomlplusplus/include -I/usr/include -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -Wpedantic -std=c++2a -O3 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -msse2 -DRELEASE=1 -m32 -malign-double -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_ALL_NO_LIB -isystem../subprojects/vst3 -isystemsubprojects/vst3 -fvisibility=hidden -fvisibility-inlines-hidden -DBOOST_ASIO_DISABLE_CONCEPTS -DBOOST_POSIX_HAS_VFORK=1 -msse2 -DWITH_BITBRIDGE -DWITH_VST3 -DNOMINMAX -D__WINE_WINSOCKAPI_STDLIB_H -D_WINSOCKAPI_ -D__IFileOperation_INTERFACE_DEFINED__ -D__WINE_SAL_H__ -m32 -malign-double -MD -MQ src/wine-host/libhost_common_32bit.a.p/meson-generated_host_common_32bit-unity0.cpp.o -MF src/wine-host/libhost_common_32bit.a.p
/meson-generated_host_common_32bit-unity0.cpp.o.d -o src/wine-host/libhost_common_32bit.a.p/meson-generated_host_common_32bit-unity0.cpp.o -c src/wine-host/libhost_common_32bit.a.p/host_common_32bit-unity0.cpp
FAILED: src/wine-host/libhost_common_32bit.a.p/meson-generated_host_common_32bit-unity0.cpp.o
wineg++ -Isrc/wine-host/libhost_common_32bit.a.p -Isrc/wine-host -I../src/wine-host -I../src/include -Isrc/common/config -I../src/common/config -I../subprojects/bitsery/include -I../subprojects/function2/include -I../subprojects/tomlplusplus/include -I/usr/include -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -Wpedantic -std=c++2a -O3 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -msse2 -DRELEASE=1 -m32 -malign-double -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_ALL_NO_LIB -isystem../subprojects/vst3 -isystemsubprojects/vst3 -fvisibility=hidden -fvisibility-inlines-hidden -DBOOST_ASIO_DISABLE_CONCEPTS -DBOOST_POSIX_HAS_VFORK=1 -msse2 -DWITH_BITBRIDGE -DWITH_VST3 -DNOMINMAX -D__WINE_WINSOCKAPI_STDLIB_H -D_WINSOCKAPI_ -D__IFileOperation_INTERFACE_DEFINED__ -D__WINE_SAL_H__ -m32 -malign-double -MD -MQ src/wine-host/libhost_common_32bit.a.p/meson-generated_host_common_32bit-unity0.cpp.o -MF src/wine-host/libhost_common_32bit.a.p/meson-g
enerated_host_common_32bit-unity0.cpp.o.d -o src/wine-host/libhost_common_32bit.a.p/meson-generated_host_common_32bit-unity0.cpp.o -c src/wine-host/libhost_common_32bit.a.p/host_common_32bit-unity0.cpp
In file included from src/wine-host/libhost_common_32bit.a.p/host_common_32bit-unity0.cpp:13:
/home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/xdnd-proxy.cpp: In function 'void dnd_winevent_callback(HWINEVENTHOOK, DWORD, HWND, LONG, LONG, DWORD, DWORD)':
/home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/xdnd-proxy.cpp:756:36: error: invalid conversion from 'uint32_t*' {aka 'unsigned int*'} to 'LPDWORD' {aka 'long unsigned int*'} [-fpermissive]
756 | GetWindowThreadProcessId(hwnd, &process_id);
| ^~~~~~~~~~~
| |
| uint32_t* {aka unsigned int*}
In file included from /usr/include/wine/windows/windows.h:40,
from /home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/bridges/../utils.h:26,
from /home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/bridges/common.h:24,
from /home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/bridges/common.cpp:17,
from src/wine-host/libhost_common_32bit.a.p/host_common_32bit-unity0.cpp:9:
/usr/include/wine/windows/winuser.h:3953:61: note: initializing argument 2 of 'DWORD GetWindowThreadProcessId(HWND, LPDWORD)'
3953 | WINUSERAPI DWORD WINAPI GetWindowThreadProcessId(HWND,LPDWORD);
| ^~~~~~~
In file included from src/wine-host/libhost_common_32bit.a.p/host_common_32bit-unity0.cpp:13:
/home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/xdnd-proxy.cpp:793:22: error: invalid conversion from 'unsigned int*' to 'ULONG*' {aka 'long unsigned int*'} [-fpermissive]
793 | &num_formats);
| ^~~~~~~~~~~~
| |
| unsigned int*
In file included from /usr/include/wine/windows/objbase.h:262,
from /usr/include/wine/windows/ole2.h:25,
from /usr/include/wine/windows/wtypes.h:13,
from /usr/include/wine/windows/winscard.h:22,
from /usr/include/wine/windows/windows.h:67,
from /home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/bridges/../utils.h:26,
from /home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/bridges/common.h:24,
from /home/martin/rpmbuild/BUILD/yabridge-3.8.0/build/../src/wine-host/bridges/common.cpp:17,
from src/wine-host/libhost_common_32bit.a.p/host_common_32bit-unity0.cpp:9:
/usr/include/wine/windows/objidl.h:9511:16: note: initializing argument 3 of 'virtual HRESULT IEnumFORMATETC::Next(ULONG, FORMATETC*, ULONG*)'
9511 | ULONG *pceltFetched) = 0;
| ~~~~~~~^~~~~~~~~~~~
winegcc: /usr/bin/g++ failed
ninja: build stopped: subcommand failed.
[1] https://martinkg.fedorapeople.org/ErrorReports/yabridge/yabridge.spec
Is there any solution, how can I solve this ?
Regards
Martin
4 months
EPEL8 build problem
by Steve Cossette
Good morning... I was trying to mockbuild a package for epel8 this morning,
and got an error message that seems to have to do less with my build and
more of (maybe?) a bigger problem:
Start: dnf update
No matches found for the following disable plugin patterns: local,
spacewalk, versionlock
CentOS Stream 8 - BaseOS
19 kB/s | 3.9 kB 00:00
CentOS Stream 8 - AppStream
1.9 kB/s | 4.4 kB 00:02
CentOS Stream 8 - AppStream
9.8 MB/s | 20 MB 00:02
CentOS Stream 8 - Extras
13 kB/s | 3.0 kB 00:00
CentOS Stream 8 - PowerTools
9.0 kB/s | 4.4 kB 00:00
Extra Packages for Enterprise Linux 8 - x86_64
20 kB/s | 4.7 kB 00:00
Error:
Problem: problem with installed package rpm-build-4.14.3-21.el8.x86_64
- cannot install the best update candidate for package
rpm-build-4.14.3-21.el8.x86_64
- nothing provides rpm = 4.14.3-22.el8 needed by
rpm-build-4.14.3-22.el8.x86_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to
use not only best candidate packages)
ERROR:
Exception(/home/farchord/build/lutris/lutris/lutris-0.5.9.1-4.el8.src.rpm)
Config(centos-stream+epel-8-x86_64) 0 minutes 11 seconds
INFO: Results and/or logs in:
/home/farchord/build/lutris/lutris/results_lutris/0.5.9.1/4.el8
INFO: Cleaning up build root ('cleanup_on_failure=True')
Start: clean chroot
Finish: clean chroot
ERROR: Command failed:
# /usr/bin/systemd-nspawn -q -M 5bc8223ee6104692a8cb1c3aa3b2cf25 -D
/var/lib/mock/centos-stream+epel-8-x86_64-bootstrap/root -a
--capability=cap_ipc_lock --bind=/tmp/mock-resolv.e_p6y9ke:/etc/resolv.conf
--console=pipe --setenv=TERM=vt100 --setenv=SHELL=/bin/bash
--setenv=HOME=/var/lib/mock/centos-stream+epel-8-x86_64/root/installation-homedir
--setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin
--setenv=PROMPT_COMMAND=printf "\033]0;<mock-chroot>\007"
--setenv=PS1=<mock-chroot> \s-\v\$ --setenv=LANG=C.UTF-8
--setenv=LC_MESSAGES=C.UTF-8 --resolv-conf=off /usr/bin/dnf --installroot
/var/lib/mock/centos-stream+epel-8-x86_64/root/ -y --releasever 8
--setopt=deltarpm=False --allowerasing --disableplugin=local
--disableplugin=spacewalk --disableplugin=versionlock update
--setopt=tsflags=nocontexts
Could not execute mockbuild: Failed to execute command.
Anyone know about this?
Thank you.
4 months, 1 week
Packaging for EPEL9 question
by Steve Cossette
Hello,
So I am working on building for EPEL9 from fedora 35, but mock was
complaining it had no config file for epel9.
So I created a symlink:
epel-9-x86_64.cfg -> /etc/mock/centos-stream+epel-9-x86_64.cfg
I was looking in the doc files and couldn't find any documentation on this,
is this correct?
Thank you.
4 months, 1 week
Re: Preventing .build-id file conflicts between pypy3.7-libs-7.3.7-1.fc34.x86_64 and pypy3.8-libs-7.3.7-1.fc34.x86_64
by Sérgio Basto
On Mon, 2022-02-14 at 10:34 +0100, Michal Schorm wrote:
> The time had to come, when two packages would generate the same hash.
>
> I was hit by:
> ---
> Error: Transaction test error:
> file /usr/lib/.build-id/34/feaa549462e8818baa0629ce11da344465882b
> conflicts between attempted installs of discord-0.0.16-1.fc35.x86_64
> and skypeforlinux-8.79.0.95-1.x86_64
> ---
> some time ago but since neither is a package maintained by Fedora
> Project maintainers, no one gave a damn about the core of the issue.
> That time, I got one of the apps as a Flatpak instead, but not all
> packages have such workarounds at hand.
yeah , thank you for reminder these cases (with electron apps)
we fixed with `%global debug_package %{nil}`
> --
>
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
>
> --
>
> On Sun, Feb 13, 2022 at 2:13 PM Miro Hrončok <mhroncok(a)redhat.com>
> wrote:
> >
> > Hey,
> > apparently some ELF files are identical between Fedora's pypy3.7-
> > libs and
> > pypy3.8-libs packages.
> >
> > On Fedora 34, this leads to installation conflict:
> >
> > Error: Transaction test error:
> > file /usr/lib/.build-
> > id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/40/682aae1fc61eaa03230eac9033407ce96488c9 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/87/535f93c815a75349f4d56210c31d4ef4b797f2 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/c9/e94d839699198b0e87c334f8e03160fec054de from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> > file /usr/lib/.build-
> > id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6 from
> > install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file
> > from package
> > pypy3.8-libs-7.3.7-1.fc34.x86_64
> >
> > As reported in https://bugzilla.redhat.com/2053880
> >
> > I've read all the previous discussion about this on Fedora devel
> > list, but I
> > still have no idea what should I do to prevent this conflict.
> >
> > Moving the files to a common component seems like a bad idea given
> > it's not
> > "two packages bundle the same thing" but rather "two packages built
> > in a
> > different way".
> >
> > I see this:
> >
> > https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.i...
> >
> > %{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
> >
> > I suppose I could pass in %{NAME} as well, right?
> >
> > What are the side effects for changing the seed like this?:
> >
> > %global __debug_install_post \
> >
> > %{lua:print(rpm.expand('%__debug_install_post'):gsub('%-%-build%-
> > id%-seed%s+"',
> > rpm.expand('--build-id-seed "%{NAME}-')))}
> >
> >
> > Actually, should RPM pass %{NAME} by default? Or at least have a
> > macro I could
> > redefine in a less cryptic and fragile way?
> >
> > --
> > Miro Hrončok
> > --
> > Phone: +420777974800
> > IRC: mhroncok
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam on the list, report it:
> > https://pagure.io/fedora-infrastructure
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
--
Sérgio M. B.
4 months, 1 week
Preventing .build-id file conflicts between pypy3.7-libs-7.3.7-1.fc34.x86_64 and pypy3.8-libs-7.3.7-1.fc34.x86_64
by Miro Hrončok
Hey,
apparently some ELF files are identical between Fedora's pypy3.7-libs and
pypy3.8-libs packages.
On Fedora 34, this leads to installation conflict:
Error: Transaction test error:
file /usr/lib/.build-id/39/208b4f57aa4d5cfcbed13cf6c5ec428de27264 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/40/682aae1fc61eaa03230eac9033407ce96488c9 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/53/96df0ea06a9dd7e8eeea66aaa65dda9b64e73c from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/87/535f93c815a75349f4d56210c31d4ef4b797f2 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/c6/bff4486941a2fb3490a80eb7b7bfe3370e8ba0 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/c9/e94d839699198b0e87c334f8e03160fec054de from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/e4/a09cf0647ed5d0e730dcdfef7aff9f9a2e11a0 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/e8/1db0d87e7cce4f5fcad18063f7b7fce2eb9590 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
file /usr/lib/.build-id/ee/d5ab1faa168044b871001c4117fc8b7853b3c6 from
install of pypy3.7-libs-7.3.7-1.fc34.x86_64 conflicts with file from package
pypy3.8-libs-7.3.7-1.fc34.x86_64
As reported in https://bugzilla.redhat.com/2053880
I've read all the previous discussion about this on Fedora devel list, but I
still have no idea what should I do to prevent this conflict.
Moving the files to a common component seems like a bad idea given it's not
"two packages bundle the same thing" but rather "two packages built in a
different way".
I see this:
https://github.com/rpm-software-management/rpm/blob/rpm-4.16.1.3/macros.i...
%{?_unique_build_ids:--build-id-seed "%{VERSION}-%{RELEASE}"}
I suppose I could pass in %{NAME} as well, right?
What are the side effects for changing the seed like this?:
%global __debug_install_post \
%{lua:print(rpm.expand('%__debug_install_post'):gsub('%-%-build%-id%-seed%s+"',
rpm.expand('--build-id-seed "%{NAME}-')))}
Actually, should RPM pass %{NAME} by default? Or at least have a macro I could
redefine in a less cryptic and fragile way?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 months, 2 weeks
Re: Preventing .build-id file conflicts between pypy3.7-libs-7.3.7-1.fc34.x86_64 and pypy3.8-libs-7.3.7-1.fc34.x86_64
by Miro Hrončok
On 14. 02. 22 10:34, Michal Schorm wrote:
> The time had to come, when two packages would generate the same hash.
>
> I was hit by:
> ---
> Error: Transaction test error:
> file/usr/lib/.build-id/34/feaa549462e8818baa0629ce11da344465882b
> conflicts between attempted installs of discord-0.0.16-1.fc35.x86_64
> and skypeforlinux-8.79.0.95-1.x86_64
> ---
> some time ago but since neither is a package maintained by Fedora
> Project maintainers, no one gave a damn about the core of the issue.
> That time, I got one of the apps as a Flatpak instead, but not all
> packages have such workarounds at hand.
That's because they both ship the same electron binary.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 months, 2 weeks
GPG key error during mockbuild
by Brad Bell
During the execution of
fedpkg mockbuild
I am getting the following error message (and do not know what I should do about it) ?
... snip ...
(135/136): python3-libs-3.10.2-3.fc36.x86_64.rp 3.6 MB/s | 7.4 MB 00:02
(136/136): zlib-1.2.11-31.fc36.x86_64.rpm 834 kB/s | 91 kB 00:00
--------------------------------------------------------------------------------
Total 5.2 MB/s | 51 MB 00:09
fedora 1.6 MB/s | 1.6 kB 00:00
Importing GPG key 0x38AB71F4:
Userid : "Fedora (36) <fedora-36-primary(a)fedoraproject.org>"
Fingerprint: 53DE D2CB 922D 8B8D 9E63 FD18 999F 7CBF 38AB 71F4
From : /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-36-primary
Key imported successfully
fedora 1.6 MB/s | 1.6 kB 00:00
GPG key at file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-36-primary (0x38AB71F4)
is already installed
fedora 1.6 MB/s | 1.6 kB 00:00
Importing GPG key 0x9867C58F:
Userid : "Fedora (35) <fedora-35-primary(a)fedoraproject.org>"
Fingerprint: 787E A6AE 1147 EEE5 6C40 B30C DB46 3971 9867 C58F
From : /usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-35-primary
Key imported successfully
Import of key(s) didn't help, wrong key(s)?
Public key for alternatives-1.19-2.fc36.x86_64.rpm is not installed. Failing package is:
alternatives-1.19-2.fc36.x86_64
GPG Keys are configured as:
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-36-primary,
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-36-primary,
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-35-primary
Public key for audit-libs-3.0.7-1.fc36.x86_64.rpm is not installed. Failing package is:
audit-libs-3.0.7-1.fc36.x86_64
GPG Keys are configured as:
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-36-primary,
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-36-primary,
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-35-primary
Public key for basesystem-11-13.fc36.noarch.rpm is not installed. Failing package is:
basesystem-11-13.fc36.noarch
GPG Keys are configured as:
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-36-primary,
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-36-primary,
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-35-primary
Public key for bash-5.1.16-2.fc36.x86_64.rpm is not installed. Failing package is:
bash-5.1.16-2.fc36.x86_64
GPG Keys are configured as:
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-36-primary,
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-36-primary,
file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-35-primary
Public key for bzip2-libs-1.0.8-11.fc36.x86_64.rpm is not installed. Failing pac
... snip ...
4 months, 2 weeks
