| Summary: | dnf tracebacks when doing update while adding new repos via CLI | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tomas Tomecek <ttomecek> |
| Component: | dnf | Assignee: | rpm-software-management |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | urgent | ||
| Version: | rawhide | CC: | ignatenko, mluscon, ngompa13, packaging-team-maint, pnemade, rpm-software-management, tmlcoch, uberDoward, vmukhame |
| Target Milestone: | --- | Keywords: | Regression, Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-12-07 06:33:05 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Tomas Tomecek
2016-10-21 18:45:53 UTC
Seems like CPython's librepo bug. Igor, could you shed some light on how librepo is used by DNF when this error occurs? What is happening? Package download? Repodata download? How the callback function look like? Etc. *** Bug 1394893 has been marked as a duplicate of this bug. *** I'm encountering the same issue in Mageia Cauldron, with exactly the same error by running the following command: sudo dnf --disablerepo=* --repofrompath=mga,https://mirrors.kernel.org/mageia/distrib/6/x86_64/media/core/release/ --enablerepo=mga6 install qupzilla TL;DR: dnf.repo.Repo() is broken. Details below. The stage in which this is happening is when it has added the repository to the sack and is starting the repodata download. Stepping through the program's execution using pudb, it looks like MDPayload doesn't have a text attribute to return for dnf.cli.progress.progress(). The steps that seem to occur at the breaking function call are: MDPayload::_progress_cb(self=MDPayload, cbdata=None, total=0.0) -> self.progress.progress(self=MDPayload, payload=MDPayload, done=0.0) -> unicode(payload=MDPayload) -> MDPayload::__str__(self=MDPayload) -> return self._text The "return self._text" returns None, rather than a string. Going a bit deeper, it seems that when _md_pload.start(self.name) is called in dnf.repo Repo::_handle_load_core(), the self.name has no value when you do --repofrompath (that is, it seems that the name I gave it is not being written in, which in this case is "mga"). With self.name=None, it propagates through until it breaks at _progress_cb(). If I do the exact same operation, but replace all the repo switches with "--refresh" and trace it again, "self.name" is filled in with a string. In my case, it is "Mageia Cauldron - x86_64". This seems like the issue is in DNF itself, rather than librepo, as the None value breaks the rendering of the progress text, causing the crash. The new livecd-creator ported over to DNF has the same problem, caused by the name being passed in the Repo() call not being carried into the program. Here are the relevant bits: * https://github.com/rpm-software-management/dnf/blob/master/dnf/cli/progress.py#L70 * https://github.com/rpm-software-management/dnf/blob/master/dnf/repo.py#L395 * https://github.com/rpm-software-management/dnf/blob/master/dnf/repo.py#L616 * https://github.com/rhinstaller/livecd-tools/blob/master/imgcreate/dnfinst.py#L153 * https://github.com/rpm-software-management/dnf/blob/master/dnf/repo.py#L454 This needs to be fixed before the next DNF 2.0 RC goes out. There was a slight problem with the fix, as the long form name was always overridden with the repo ID. Pull request with fix submitted: https://github.com/rpm-software-management/dnf/pull/674 *** Bug 1419615 has been marked as a duplicate of this bug. *** |