Description of problem:
When running a yum which fails because another yum has a lock, I get a Python traceback rather than an error message explaining the problem.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. yum list & # Or something else that will lock for a while
2. LANG=sv_SE.utf8 yum info nettle
Traceback (most recent call last):
File "/usr/bin/yum", line 29, in <module>
File "/usr/share/yum-cli/yummain.py", line 321, in user_main
errcode = main(args)
File "/usr/share/yum-cli/yummain.py", line 124, in main
File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 1976, in doLock
msg = _('Existing lock %s: another copy is running as pid %s.') % (lockfile, oldpid)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 14: ordinal not in range(128)
Existerande lås <someFile>: en annan kopia kör som pid <pid>
for some values of someFile and pid.
There are a couple of similar reports already, but most of them have been closed. Since this still happens, I guess this is in some way different.
Hi, I think you may have non-ascii characters in your userid.
Could you run this and post the result? Thanks!
~$ python -c 'import os,pwd;print repr(pwd.getpwuid(os.geteuid()))'
I do indeed; I use my first name as userid:
mimmi$ python -c 'import os,pwd;print repr(pwd.getpwuid(os.geteuid()))'
I'm surprised that fact related to the error I reported here. The Swedish translation of
Existing lock %s: another copy is running as pid %s.
Existerande lås %s: en annan kopia kör som pid %s.
The fourteenth character is indeed non-ascii. So I thought it was that string it failed to decode.
But when testing on another account, it does indeed work as expected. I get the Swedish translation of the error message printed, and yum keeps waiting rather than crashing.
yum-3.4.3-28.fc17 has been submitted as an update for Fedora 17.
yum-3.4.3-28.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
The problem is gone in -28.
Is this bugzilla waiting for something more? Most of the time I see bugzillas closed automatically when an updated goes from testing to stable. But this update went directly to stable, and doesn't seem to have been automatically closed.
If it waits for me, I'm saying I'm happy with the fix! :-)