Description of problem: When I try to use dnf rather than yum, it dies immediately with a complaint about the ascii coded trying to decode byte 0xc3. It happens only when I do it as my regular user id, not when doing it as root, or when other users run it. It appears to be related to my username having non-ascii letters. My login is "göran". Version-Release number of selected component (if applicable): dnf-0.5.2-1.fc20.noarch How reproducible: Every time Steps to Reproduce: 1. dnf list kernel Actual results: Config error: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128) Expected results: List of installed and available kernel package. Additional info: I've tried to debug this using pdb. If I understand things correctly, the problem happens in dnf/yum/misc.py, on line 565 in getCacheDir. There it tries to put together a path in this way: prefix = '%s-%s-' % (dnf.const.PREFIX, username) This apparently fails when username isn't pure ascii. I compared to yum, where the corresponding function has a second step when it calculates "username". username = usertup[0] # we prefer ascii-only paths username = urllib.quote(username) Maybe this code could be ported to dnf too?
Hello, thank you for the report and all the useful information. We'll take a look.
Hm, wasn't quite as easy as that. Now I get errors like this: 23:51 mimmi$ dnf repolist Fel: Failed to synchronize cache for repo 'fedora': Cannot prepare internal mirrorlist: Curl error: Couldn't read a file:// file for file:///var/tmp/dnf-g%C3%B6ran-9TL5Zi/x86_64/20/fedora/metalink.xml Checking with "strace", I see it tries to open a file where the "%C3%B6" part has been decoded back again: open("/var/tmp/dnf-g\303\266ran-9TL5Zi/x86_64/20/fedora/metalink.xml", O_RDONLY) = -1 ENOENT (No such file or directory) This is after a while in the trace. It has accessed things under "/var/tmp/dnf-g%C3%B6ran-9TL5Zi/" many times first. So the string gets interpreted some of the time, but mostly not. Given the error message, I'm guessing this is in libcurl, called via librepo. But that's just a guess so far. I just wanted to make a note right away so you know my suggested fix was insufficient.
I am unable to reproduce this. How did you set user name with non ascii characters? I tried to add new user by useradd, system-config-users and gnome user settings and all of them says that these characters are not allowed. I am using Fedora 19 and I tried it also in Fedora 20 docker image.
I don't remember exactly what method I used to create the account. It's a very long time ago. But for the purpose of this experiment, why not just create an account without any special characters. Then edit /etc/passwd and /etc/shadow manually, and do "mv" on the home directory. (Strictly speaking, I guess you don't need to change the home directory name to reproduce this. It is enough with the login name.)
Fixed in the upstream.
hawkey-0.4.18-2.fc20, dnf-0.5.4-1.fc20, libsolv-0.6.4-0.git2a5c1c4.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/hawkey-0.4.18-2.fc20,dnf-0.5.4-1.fc20,libsolv-0.6.4-0.git2a5c1c4.fc20
hawkey-0.4.18-2.fc20, dnf-0.5.4-1.fc20, libsolv-0.6.4-0.git2a5c1c4.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.