Learn more about these different git repos.
Other Git URLs
... 2021-02-18 05:52:11,243: Downloading packages Downloading packages 2021-02-18 05:52:38,279: Preparing transaction from installation source Preparing transaction from installation source 2021-02-18 05:52:38,992: The transaction process has ended abruptly: No available modular metadata for modular package The transaction process has ended abruptly: No available modular metadata for modular package 2021-02-18 05:52:38,992: template command error in runtime-install.tmpl: template command error in runtime-install.tmpl: 2021-02-18 05:52:38,992: run_pkg_transaction run_pkg_transaction 2021-02-18 05:52:38,994: dnf.exceptions.Error: No available modular metadata for modular package dnf.exceptions.Error: No available modular metadata for modular package Traceback (most recent call last): File "/usr/sbin/lorax", line 223, in <module> main() File "/usr/sbin/lorax", line 204, in main lorax.run(dnfbase, opts.product, opts.version, opts.release, File "/usr/lib/python3.9/site-packages/pylorax/__init__.py", line 271, in run rb.install() File "/usr/lib/python3.9/site-packages/pylorax/treebuilder.py", line 136, in install self._runner.run("runtime-install.tmpl") File "/usr/lib/python3.9/site-packages/pylorax/ltmpl.py", line 149, in run self._run(commands) File "/usr/lib/python3.9/site-packages/pylorax/ltmpl.py", line 168, in _run f(*args) File "/usr/lib/python3.9/site-packages/pylorax/ltmpl.py", line 654, in run_pkg_transaction self.dbo.do_transaction(display=display) File "/usr/lib/python3.9/site-packages/dnf/base.py", line 896, in do_transaction self.transaction._populate_rpm_ts(self._ts) File "/usr/lib/python3.9/site-packages/dnf/db/group.py", line 343, in _populate_rpm_ts raise dnf.exceptions.Error(_("No available modular metadata for modular package"))
see eg. https://koji.fedoraproject.org/koji/taskinfo?taskID=62202092 for all logs
And there might have been the same issue on s390x before they started to fail due missing /mnt/koji
When do you need this? (YYYY/MM/DD) ASAP
When is this no longer needed or useful? (YYYY/MM/DD) N/A
If we cannot complete your request, what is the impact? ppc64le compose artifacts not available
Metadata Update from @mohanboddu: - Issue tagged with: high-gain, high-trouble, ops
So, I suspect this is due to us adding the filter_modules for perlbootstrap but I am not sure how.
The failure has:
2021-02-18 05:52:38,283 INFO: Running transaction check 2021-02-18 05:52:38,288 CRITICAL: No available modular metadata for modular package 'perl-Carp-1.50-467.module_f35+11292+b197191a.noarch', it cannot be installed on the system 2021-02-18 05:52:38,289 CRITICAL: No available modular metadata for modular package 'perl-Data-Dumper-2.174-467.module_f35+11292+b197191a.ppc64le', it cannot be installed on the system 2021-02-18 05:52:38,290 CRITICAL: No available modular metadata for modular package 'perl-Exporter-5.74-467.module_f35+11292+b197191a.noarch', it cannot be installed on the system 2021-02-18 05:52:38,290 CRITICAL: No available modular metadata for modular package 'perl-HTTP-Tiny-0.076-467.module_f35+11292+b197191a.noarch', it cannot be installed on the system 2021-02-18 05:52:38,291 CRITICAL: No available modular metadata for modular package 'perl-PathTools-3.78-467.module_f35+11292+b197191a.ppc64le', it cannot be installed on the system 2021-02-18 05:52:38,292 CRITICAL: No available modular metadata for modular package 'perl-Pod-Escapes-1:1.07-467.module_f35+11292+b197191a.noarch', it cannot be installed on the system 2021-02-18 05:52:38,293 CRITICAL: No available modular metadata for modular package 'perl-Pod-Perldoc-3.28.01-467.module_f35+11292+b197191a.noarch', it cannot be installed on the system 2021-02-18 05:52:38,294 CRITICAL: No available modular metadata for modular package 'perl-Scalar-List-Utils-4:1.55-467.module_f35+11292+b197191a.ppc64le', it cannot be installed on the system 2021-02-18 05:52:38,295 CRITICAL: No available modular metadata for modular package 'perl-Storable-1:3.21-467.module_f35+11292+b197191a.ppc64le', it cannot be installed on the system 2021-02-18 05:52:38,295 CRITICAL: No available modular metadata for modular package 'perl-Term-ANSIColor-5.01-467.module_f35+11292+b197191a.noarch', it cannot be installed on the system 2021-02-18 05:52:38,296 CRITICAL: No available modular metadata for modular package 'perl-Term-Cap-1.17-467.module_f35+11292+b197191a.noarch', it cannot be installed on the system 2021-02-18 05:52:38,297 CRITICAL: No available modular metadata for modular package 'perl-Text-ParseWords-3.30-467.module_f35+11292+b197191a.noarch', it cannot be installed on the system 2021-02-18 05:52:38,298 CRITICAL: No available modular metadata for modular package 'perl-Text-Tabs+Wrap-2013.0523-467.module_f35+11292+b197191a.noarch', it cannot be installed on the system 2021-02-18 05:52:38,299 CRITICAL: No available modular metadata for modular package 'perl-constant-1.33-467.module_f35+11292+b197191a.noarch', it cannot be installed on the system 2021-02-18 05:52:38,299 CRITICAL: No available modular metadata for modular package 'perl-parent-1:0.238-467.module_f35+11292+b197191a.noarch', it cannot be installed on the system 2021-02-18 05:52:38,300 CRITICAL: No available modular metadata for modular package 'perl-podlators-1:4.14-467.module_f35+11292+b197191a.noarch', it cannot be installed on the system
And those are all from: https://koji.fedoraproject.org/koji/buildinfo?buildID=1707499 which is perl-module-bootstrap module
@lsedlar can you see whats going on here? I wouldn't think it would see the metadata at all to know to pull those in? but somehow it is?
This only seems to happen on ppc64le and s390x. I do note that all the above are noarch rpms as well.
ok, some of them are ppc64le... didn't look closely enough. ;)
if you have applied the filter_modules setting around February 2nd, then it should be it ...
filter_modules
Nope.
The orig one was Jan 26th.
+filter_modules = [ + ('(Modular)$', { + '': [ + 'perl-bootstrap:', + 'rpm:*', + ] + }), +]
The updated one was Feb15th.
So, nothing matches the 2nd here. However, the 2nd was when the mass rebuild landed I think. ;( Good luck finding a needle in that haystack. ;(
openqa (https://openqa.stg.fedoraproject.org/group_overview/3?limit_builds=100) gives us some data, things were OK until Feb 1st, then there are only 2 good composes on the 10th and 11th ...
failed-composes also has the info - it'll show [FAIL] Buildinstall (variant Everything, arch ppc64le) failed and [FAIL] Buildinstall (variant Server, arch ppc64le) and so on (for all Buildinstall tasks, for ppc64le and s390x) when this happens.
[FAIL] Buildinstall (variant Everything, arch ppc64le) failed
[FAIL] Buildinstall (variant Server, arch ppc64le)
That is an interesting case. I think there's at least one possible bug involved here. The skipped modules are (correctly) not included in the compose, but Pungi still builds a repo with the packages and that repo is later visible to lorax.
Because the module is skipped from all variants, the modular metadata was not loaded and is not included in the repository. This patch should fix it by not creating the repo in the first place.
Cool. Sounds good. I can make a f33 pungi with the patch and we can see if it fixes it. :)
Seems we got everything produced with Fedora-Rawhide-20210223.n.1, thanks for the fix
Yep. Thanks!
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.