Bug 2216141

Summary: [abrt] fedrq: load(): repo.py:581:load:dnf.exceptions.RepoError: Failed to download metadata for repo 'updates-source': Yum repo downloading error: Downloading error(s): repodata/f72aa29c94724dc1f6b17b5b318aba13d6c902ab97f74d5c47a76730bcfb37f1-primary.xml
Product: [Fedora] Fedora Reporter: Ankur Sinha (FranciscoD) <sanjay.ankur>
Component: fedrqAssignee: Maxwell G <maxwell>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 38CC: maxwell, sanjay.ankur
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/139acb61ebc1535b80ac5018f91d4b6ff5ce326
Whiteboard: abrt_hash:bc88303ef958dd7231855e1fc3ba8f564f09df69;VARIANT_ID=compneuro;
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-06-20 16:21:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: os_info
none
File: environ
none
File: mountinfo
none
File: open_fds
none
File: namespaces
none
File: backtrace
none
File: cpuinfo none

Description Ankur Sinha (FranciscoD) 2023-06-20 09:24:28 UTC 
Description of problem:
Ran: fedrq whatrequires-src -b f38 python3-pydantic


(maybe the dnf cache was unclean, running a `dnf clean metadata` seems to have fixed it)

Version-Release number of selected component:
fedrq-0.7.1-1.fc38

Additional info:
reporter:       libreport-2.17.10
kernel:         6.3.8-200.fc38.x86_64
cmdline:        /usr/bin/python3 -sP /usr/bin/fedrq whatrequires-src -b f38 python3-pydantic
cgroup:         0::/user.slice/user-1000.slice/user/app.slice/run-r6e7ef2d081f64139b88a0cb47f7c7d43.scope
uid:            1000
reason:         repo.py:581:load:dnf.exceptions.RepoError: Failed to download metadata for repo 'updates-source': Yum repo downloading error: Downloading error(s): repodata/f72aa29c94724dc1f6b17b5b318aba13d6c902ab97f74d5c47a76730bcfb37f1-primary.xml.zck - Cannot download, all mirrors were already tried without success; repodata/aba0604ea09fdfff9f7a50fc803457ec9b4099b928e5ca99ac123d06ab274d04-filelists.xml.zck - Cannot download, all mirrors were already tried without success; repodata/3c656f828c882093561b0ffbd7cd9549ffd007d6eae412abd84ca5d3d3cc1031-updateinfo.xml.zck - Cannot download, all mirrors were already tried without success
executable:     /usr/bin/fedrq
type:           Python3
package:        fedrq-0.7.1-1.fc38
runlevel:       N 5
exception_type: libdnf._error.Error
crash_function: load
interpreter:    python3-3.11.4-1.fc38.x86_64

Truncated backtrace:
#1 [/usr/lib64/python3.11/site-packages/libdnf/repo.py:324] load
#2 [/usr/lib/python3.11/site-packages/dnf/repo.py:574] load
Comment 1 Ankur Sinha (FranciscoD) 2023-06-20 09:24:32 UTC 
Created attachment 1971682 [details]
File: os_info
Comment 2 Ankur Sinha (FranciscoD) 2023-06-20 09:24:34 UTC 
Created attachment 1971683 [details]
File: environ
Comment 3 Ankur Sinha (FranciscoD) 2023-06-20 09:24:35 UTC 
Created attachment 1971684 [details]
File: mountinfo
Comment 4 Ankur Sinha (FranciscoD) 2023-06-20 09:24:37 UTC 
Created attachment 1971685 [details]
File: open_fds
Comment 5 Ankur Sinha (FranciscoD) 2023-06-20 09:24:38 UTC 
Created attachment 1971686 [details]
File: namespaces
Comment 6 Ankur Sinha (FranciscoD) 2023-06-20 09:24:40 UTC 
Created attachment 1971687 [details]
File: backtrace
Comment 7 Ankur Sinha (FranciscoD) 2023-06-20 09:24:42 UTC 
Created attachment 1971688 [details]
File: cpuinfo
Comment 8 Maxwell G 2023-06-20 16:21:30 UTC 
Thank you for the report! I'm glad that you're finding the tool useful.

I don't think is is a bug in fedrq. We use dnf or libdnf5 (depending on what you've configured) to load the repo metadata, and that's where the exception is coming from. It's just a bunch of 404s from the mirrors. I opened https://todo.sr.ht/~gotmax23/fedrq/31 upstream to track improving the error handling here. Propagating these Exceptions directly to the user is not great. It's especially ugly here, because dnf calls libdnf to load the repodata and dnf raises another Exception on top of the Exception that libdnf raises...