Bug 1764642

Anaconda versions:

[liveuser@localhost-live ~]$ rpm -qa|grep anaconda
anaconda-live-31.22.6-2.fc31.x86_64
anaconda-widgets-31.22.6-2.fc31.x86_64
anaconda-gui-31.22.6-2.fc31.x86_64
anaconda-31.22.6-2.fc31.x86_64
anaconda-tui-31.22.6-2.fc31.x86_64
libreport-anaconda-2.10.1-2.fc31.x86_64
anaconda-user-help-26.1-10.fc31.noarch
anaconda-core-31.22.6-2.fc31.x86_64
kdump-anaconda-addon-005-5.20190103gitb16ea2c.fc31.noarch
anaconda-install-env-deps-31.22.6-2.fc31.x86_64

Created attachment 1628466 [details]
journalctl -xe -g anaconda

Result of journalctl -xe -g anaconda

[liveuser@localhost-live ~]$ rpm -qa |grep libreport
libreport-fedora-2.10.1-2.fc31.x86_64
python3-libreport-2.10.1-2.fc31.x86_64
libreport-gtk-2.10.1-2.fc31.x86_64
libreport-filesystem-2.10.1-2.fc31.noarch
libreport-plugin-reportuploader-2.10.1-2.fc31.x86_64
libreport-cli-2.10.1-2.fc31.x86_64
libreport-anaconda-2.10.1-2.fc31.x86_64
libreport-2.10.1-2.fc31.x86_64
libreport-plugin-ureport-2.10.1-2.fc31.x86_64
libreport-plugin-logger-2.10.1-2.fc31.x86_64
libreport-plugin-systemd-journal-2.10.1-2.fc31.x86_64
libreport-web-2.10.1-2.fc31.x86_64
libreport-plugin-bugzilla-2.10.1-2.fc31.x86_64
libreport-plugin-kerneloops-2.10.1-2.fc31.x86_64

Proposed as a Blocker for 31-final by Fedora user alciregi using the blocker tracking app because:

 The installer must be able to report failures to Bugzilla, with appropriate information included.

I was able to reproduce it on a WS Live installation, the traceback looked pretty much the same, so I am not including it here.
I also tried again with the Server DVD and was able to report Anaconda failure to Bugzilla, see #1764649.

Traceback (most recent call last):
  File "/usr/lib64/python3.7/site-packages/pyanaconda/exception.py", line 119, in _main_loop_handleException
    super().handleException(dump_info)
  File "/usr/lib/python3.7/site-packages/meh/handler.py", line 123, in handleException
    responseHash[rc](dump_info.exc_info)
  File "/usr/lib/python3.7/site-packages/meh/handler.py", line 223, in runSave
    params.update(self.exn.environment_info)
  File "/usr/lib/python3.7/site-packages/meh/dump.py", line 262, in environment_info
    return self._get_environment_info()
  File "/usr/lib/python3.7/site-packages/meh/dump.py", line 235, in _get_environment_info
    pkg_info, component = get_package_and_component()
  File "/usr/lib/python3.7/site-packages/meh/dump.py", line 158, in get_package_and_component
    pkg_info = PackageInfo(header["name"].decode("utf-8"), header["version"].decode("utf-8"),
AttributeError: 'str' object has no attribute 'decode'

That looks like python-meh will need to be adjusted to a semi-recent DNF change where they unified how they return strings.

I guess you mean: https://github.com/rpm-software-management/rpm/commit/84920f898315d09a57a3f1067433eaeb7de5e830#diff-33c080669e7074507f1860a9e782d82c ?

Panu, j'accuse again: apparently this was not true - "In the almost ten years of rpm sort of supporting Python 3 bindings, quite obviously nobody has actually tried to use them." :)

It looks to me like this is going to fail any time the RPM header query finds something. And, thinking about it, that makes sense - because in the installer environment, we're never going to find the package a given file belongs to (which is what we're doing here) because we don't actually have an RPM database, really, the installer environment doesn't really have "packages installed". I just confirmed this by doing this:

import rpm
ts = rpm.TransactionSet()
mi = ts.dbMatch('basenames', '/usr/bin/xz')
next(mi)

on an installed system that gives you a result (an rpm.hdr object), but run in the installer environment it gives you StopIteration, i.e. it didn't find anything, even though /usr/bin/xz is present in both cases. In the installer environment it isn't seen as being part of an installed package.

I believe https://github.com/rhinstaller/python-meh/pull/22 should fix this.

What about:
https://github.com/rhinstaller/python-meh/pull/23

I think that one looks nicer. ;-)

comments in the review.

I just tested and both #22 and #23 do solve the problem.

+1 blocker per criterion cited in comment 4 [1]
[1] https://fedoraproject.org/wiki/Basic_Release_Criteria#Failure_reporting

+1 blocker for me too. The criterion is violated for any live install, which seems a broad enough violation to block on.

FEDORA-2019-81b2f42200 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-81b2f42200

(In reply to Fedora Update System from comment #13)
> FEDORA-2019-81b2f42200 has been submitted as an update to Fedora 31.
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-81b2f42200

I was able to successfully report a crash after applying this update.

+1 blocker

+1 Blocker

+1 Blocker

We're up to like +5/-0 now, so let's call this accepted.

Tested on RC1.9 and it works.
Thanks.

python-meh-0.48-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.