search

rpm-software-management / mock

Mock is a tool for a reproducible build of RPM packages.
GNU General Public License v2.0
376 stars 220 forks source link

openSUSE build fails in Fedora Copr #1334

Closed praiskup closed 4 months ago

praiskup commented 4 months ago

Seems like rpm in bootstrap doesn't like the dsFromHeader method:

openSUSE Tumbleweed - ppc64le - OSS              24 kB/s |  11 kB     00:00    
Traceback (most recent call last):
  File "/usr/bin/dnf-3", line 62, in <module>
    main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python3.11/site-packages/dnf/cli/main.py", line 201, in user_main
    errcode = main(args)
              ^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/dnf/cli/main.py", line 67, in main
    return _main(base, args, cli_class, option_parser_class)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/dnf/cli/main.py", line 106, in _main
    return cli_run(cli, base)
           ^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/dnf/cli/main.py", line 122, in cli_run
    cli.run()
  File "/usr/lib/python3.11/site-packages/dnf/cli/cli.py", line 1057, in run
    return self.command.run()
           ^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/dnf-plugins/builddep.py", line 137, in run
    self._src_deps(pkgspec)
  File "/usr/lib/python3.11/site-packages/dnf-plugins/builddep.py", line 195, in _src_deps
    ds = h.dsFromHeader('requirename')
         ^^^^^^^^^^^^^^
AttributeError: 'rpm.hdr' object has no attribute 'dsFromHeader'
WARNING: DNF command failed, retrying, attempt #2, sleeping 20s
FrostyX commented 4 months ago

AttributeError: 'rpm.hdr' object has no attribute 'dsFromHeader'

It's not that easy to find python RPM documentation, so I I am linking how I fixed a similar issue: https://github.com/rpm-software-management/tito/pull/488/files

praiskup commented 4 months ago

Mock has been fixed for the dsFromHeader API break: c15bd399c2c03a62ca56c3449db5da584fc2383a

This seems like a DNF4 (plugins-core?) issue in bootstrap chroot, i.e. the openSUSE native DNF bug:

sudo chroot /var/lib/mock/opensuse-tumbleweed-x86_64-bootstrap/root/
# dnf builddep /dummy-pkg-20240219_0732-1.src.rpm 
openSUSE Tumbleweed - x86_64 - OSS                                                                                                              28 MB/s |  56 MB     00:02    
Last metadata expiration check: 0:00:15 ago on Mon Feb 19 06:37:18 2024.
allow_vendor_change is disabled. This option is currently not supported for downgrade and distro-sync commands
Traceback (most recent call last):
  File "/usr/bin/dnf", line 62, in <module>
    main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python3.11/site-packages/dnf/cli/main.py", line 201, in user_main
    errcode = main(args)
              ^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/dnf/cli/main.py", line 67, in main
    return _main(base, args, cli_class, option_parser_class)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/dnf/cli/main.py", line 106, in _main
    return cli_run(cli, base)
           ^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/dnf/cli/main.py", line 122, in cli_run
    cli.run()
  File "/usr/lib/python3.11/site-packages/dnf/cli/cli.py", line 1057, in run
    return self.command.run()
           ^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/dnf-plugins/builddep.py", line 137, in run
    self._src_deps(pkgspec)
  File "/usr/lib/python3.11/site-packages/dnf-plugins/builddep.py", line 195, in _src_deps
    ds = h.dsFromHeader('requirename')
         ^^^^^^^^^^^^^^
AttributeError: 'rpm.hdr' object has no attribute 'dsFromHeader'

@Conan-Kudo would you mind taking a look, perhaps fixing DNF in Tumbleweed?

praiskup commented 4 months ago

The failure is caused by:

INFO: Buildroot is handled by package management downloaded with a bootstrap image:
  rpm-4.19.1.1-1.1.x86_64
  python3-dnf-4.18.0-4.2.noarch
  python3-dnf-plugins-core-4.3.1-2.3.noarch
Finish: chroot init

openSUSE 15.5 seems to work fine with:

  rpm-4.14.3-150400.59.3.1.x86_64
  python3-dnf-4.10.0-bp155.3.10.noarch
  python3-dnf-plugins-core-4.0.24-bp155.2.9.noarch

Edit: this was nonsense question: Is the tumbleweed image too old?

praiskup commented 4 months ago

Triage: We should turn the non-working chroot in Fedora Copr at least.

Conan-Kudo commented 4 months ago

ping @lkocman

Conan-Kudo commented 4 months ago

This is on its way to being fixed, I think? https://build.opensuse.org/request/show/1145856

praiskup commented 4 months ago

Still broken, but somewhere else:

openSUSE Tumbleweed - x86_64 - OSS                                                                                                                                                                          190 kB/s |  10 kB     00:00    
Error: 
 Problem: problem with installed package systemd-presets-branding-MicroOS-20230214-2.4.noarch
  - cannot install the best update candidate for package systemd-presets-branding-MicroOS-20230214-2.4.noarch
  - both package systemd-presets-branding-Kalpa-20231005-1.2.noarch from opensuse-tumbleweed-oss and systemd-presets-branding-Aeon-20231005-1.2.noarch from opensuse-tumbleweed-oss obsolete systemd-presets-branding-MicroOS < 20231005
  - both package systemd-presets-branding-Aeon-20231005-1.2.noarch from opensuse-tumbleweed-oss and systemd-presets-branding-Kalpa-20231005-1.2.noarch from opensuse-tumbleweed-oss obsolete systemd-presets-branding-MicroOS < 20231005
  - package systemd-presets-branding-Aeon-20231005-1.2.noarch from opensuse-tumbleweed-oss conflicts with systemd-presets-branding provided by systemd-presets-branding-Kalpa-20231005-1.2.noarch from opensuse-tumbleweed-oss
  - package systemd-presets-branding-Kalpa-20231005-1.2.noarch from opensuse-tumbleweed-oss conflicts with systemd-presets-branding provided by systemd-presets-branding-Aeon-20231005-1.2.noarch from opensuse-tumbleweed-oss
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
WARNING: DNF command failed, retrying, attempt #2, sleeping 20s
praiskup commented 4 months ago

Is the tumbleweed bootstrap image broken? Shall we disable bootstrap image for Tumbleweed?

praiskup commented 4 months ago

Fixing in #1343.

The remaining problem is s390x:

openSUSE Tumbleweed - s390x - OSS                                                                                                                                                                           965 kB/s | 988  B     00:00    
Importing GPG key 0x3DBDC284:
 Userid     : "openSUSE Project Signing Key <opensuse@opensuse.org>"
 Fingerprint: 22C0 7BA5 3417 8CD0 2EFE 22AA B88B 2FD4 3DBD C284
 From       : /usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE
Key imported successfully
openSUSE Tumbleweed - s390x - OSS                                                                                                                                                                           1.6 MB/s | 1.6 kB     00:00    
Importing GPG key 0x29B700A4:
 Userid     : "openSUSE Project Signing Key <opensuse@opensuse.org>"
 Fingerprint: AD48 5664 E901 B867 051A B15F 35A2 F86E 29B7 00A4
 From       : /usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE-Tumbleweed
Key imported successfully
Import of key(s) didn't help, wrong key(s)?
Public key for MicroOS-release-20240107-1746.1.s390x.rpm is not installed. Failing package is: MicroOS-release-20240107-1746.1.s390x
 GPG Keys are configured as: file:///usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE, file:///usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE-Tumbleweed
Public key for MicroOS-release-appliance-20240107-1746.1.s390x.rpm is not installed. Failing package is: MicroOS-release-appliance-20240107-1746.1.s390x
 GPG Keys are configured as: file:///usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE, file:///usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE-Tumbleweed
Public key for ModemManager-1.20.6-2.1.s390x.rpm is not installed. Failing package is: ModemManager-1.20.6-2.1.s390x
 GPG Keys are configured as: file:///usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE, file:///usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE-Tumbleweed
Public key for NetworkManager-1.44.2-4.2.s390x.rpm is not installed. Failing package is: NetworkManager-1.44.2-4.2.s390x
 GPG Keys are configured as: file:///usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE, file:///usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE-Tumbleweed
Public key for NetworkManager-bluetooth-1.44.2-4.2.s390x.rpm is not installed. Failing package is: NetworkManager-bluetooth-1.44.2-4.2.s390x
 GPG Keys are configured as: file:///usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE, file:///usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE-Tumbleweed
Public key for NetworkManager-branding-openSUSE-42.1-6.1.noarch.rpm is not installed. Failing package is: NetworkManager-branding-openSUSE-42.1-6.1.noarch
 GPG Keys are configured as: file:///usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE, file:///usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE-Tumbleweed
Public key for NetworkManager-wwan-1.44.2-4.2.s390x.rpm is not installed. Failing package is: NetworkManager-wwan-1.44.2-4.2.s390x
 GPG Keys are configured as: file:///usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE, file:///usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE-Tumbleweed
Public key for aaa_base-84.87+git20231023.f347d36-1.1.s390x.rpm is not installed. Failing package is: aaa_base-84.87+git20231023.f347d36-1.1.s390x
 GPG Keys are configured as: file:///usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE, file:///usr/share/distribution-gpg-keys/opensuse/RPM-GPG-KEY-openSUSE-Tumbleweed
Public key for alts-1.2+30.a5431e9-1.1.s390x.rpm is not installed. Failing package is: alts-1.2+30.a5431e9-1.1.s390x

Is Z using a different GPG?

Conan-Kudo commented 4 months ago

It shouldn't be? @lkocman, do you know?

Conan-Kudo commented 4 months ago

That said, we probably need to explicitly specify openSUSE-release rather than letting it select MicroOS-release.

lkocman commented 4 months ago

On TW these are separate projects and I believe we're switching keys ATM to post-quantum. Let me ask Sarah.

Conan-Kudo commented 4 months ago

And this reminds me that @daandemeyer also discovered we need to add systemd-presets-branding-openSUSE alongside openSUSE-release to our explicit package install set for bootstrap and chroot setup.

skriesch commented 4 months ago

Fixing in #1343.

The remaining problem is s390x:

Is Z using a different GPG?

Here is the used package openSUSE-build-key.. It seems, that there are different keys specific for the architectures in the spec file.

The SUSE Security Team is responsible for the key generation.