So this seems quite bad.
I install F19 Beta RC2 DVD, KDE package set, twice in a row. Each time I logged into the installed system and tried to install updates via apper (I just waited for the update notification to appear, and clicked on it, and followed the prompts).
Each time, shortly after I agreed to trust the Fedora GPG key, a kded crash notification appeared. It seems the update transaction also fails, leaving the package database inconsistent - 'yum check' reports several duplicate packages. 'yum-complete-transaction' cannot complete the transaction, it just gets very confused and winds up stuck in a completely wrong-headed dep resolving loop (it probably works it all out after a while, but clearly not in a way that would actually resolve things, so I ctrl-c'ed it).
Nominating as a blocker per criterion https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria#Updates :
"The installed system must be able to download and install updates with yum and with the default graphical package manager in all release-blocking desktops."
The upstream bug has a backtrace. It doesn't seem to be very copy/paste friendly, though, so I can't really add it here.
The relevant part of the backtrace:
Thread 1 (Thread 0x7f4ea7c238c0 (LWP 1402)):
#6 QCoreApplication::postEvent (receiver=0x1dd4950, event=0x1e4bfb0, priority=0) at kernel/qcoreapplication.cpp:1346
#7 0x00007f4e7490fa34 in TransactionWatcher::transactionListChanged(QStringList const&) () from /usr/lib64/kde4/kded_apperd.so
#8 0x00007f4ea4de2adc in QMetaObject::activate (sender=0x1e391c0, m=<optimized out>, local_signal_index=<optimized out>, argv=0x7fff61396c70) at kernel/qobject.cpp:3539
#9 0x00007f4e746d7195 in PackageKit::Daemon::transactionListChanged(QStringList const&) () from /lib64/libpackagekit-qt2.so.6
#10 0x00007f4e746d9315 in PackageKit::Daemon::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) () from /lib64/libpackagekit-qt2.so.6
#11 0x00007f4ea4de2adc in QMetaObject::activate (sender=0x1e49010, m=<optimized out>, local_signal_index=<optimized out>, argv=0x7fff61396df0) at kernel/qobject.cpp:3539
#12 0x00007f4e746e9425 in DaemonProxy::TransactionListChanged(QStringList const&) () from /lib64/libpackagekit-qt2.so.6
#13 0x00007f4e746e9724 in DaemonProxy::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) () from /lib64/libpackagekit-qt2.so.6
#14 0x00007f4e746ea60f in DaemonProxy::qt_metacall(QMetaObject::Call, int, void**) () from /lib64/libpackagekit-qt2.so.6
#15 0x00007f4ea5159126 in QDBusConnectionPrivate::deliverCall (this=0x1c339e0, object=0x1e49010, msg=..., metaTypes=..., slotIdx=8) at qdbusintegrator.cpp:951
#16 0x00007f4ea4de6e4e in QObject::event (this=0x1e49010, e=<optimized out>) at kernel/qobject.cpp:1194
Created attachment 749673 [details]
screnshot (i resized the window but the error window did not resize)
I installed KDE Plasma Desktop Base Environment, logged as an user and waited.
While i waited, i connected via ssh and installed perf and qt-debuginfo.
Then went back to the desktop and tried to update via the updates icon, and failed. I don't remember the first screen very well, but the second one is the screen-shot itself.
Error in the screen-shot:
Error Value: 'ascii' codec can't decode byte 0xe2 in position 40: ordinal not in range(128)
File : /usr/lib/python2.7/site-packages/yum/rpmtrans.py, line 458, in callback
self._instProgress( bytes, total, h )
File : /usr/lib/python2.7/site-packages/yum/rpmtrans.py, line 541, in _instProgress
File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 3311, in event
File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 3303, in _showName
self.base.package(package_id, status, self.curpkg.summary)
File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 324, in package
PackageKitBaseBackend.package(self, package_id, status, summary)
File : /usr/lib/python2.7/site-packages/packagekit/backend.py, line 181, in package
print("package\t$s\t$s\t$s" $ (status, package_id, _to_utf8(summary)), file=sys.stdout)
I am not sure this helps or if it is unrelated.
Looks like this is the same as bug #963810.
since that one's assigned to gnome-packagekit, does that mean both apper and gpk are suffering a similar bug and need to be fixed separately? or is it more that there's a single underlying bug in PK itself?
I think it's a bug in PackageKit's yum backend.
Yes, the file [as mentioned in the backtrace] I've touched is from
$ rpm -qf /usr/lib/python2.7/site-packages/packagekit/backend.py
so it could really affect every frontend.
Where exactly the origin of the string encoding problem is, I dunno. Strings such as the package %description are of type 'unicode' already at that point, converted to 'utf-8' once more, but there is sys.stdout print()ing involved with sys.stdout.encoding = 'None' and therefore falling back to 'ascii', which stumbles upon the utf-8 encoding.
OK, let's call it a dupe, then...
*** This bug has been marked as a duplicate of bug 963810 ***
While this backend problem causes the the apper crash ( bug #964352 ), dannti thinks we can fix that separately (undup'ing)
apper-0.8.1-0.3.20130511.fc19 has been submitted as an update for Fedora 19.
Dropping the blocker nomination here, as 963810 has been accepted as a blocker.
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing apper-0.8.1-0.3.20130511.fc19'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
apper-0.8.1-0.3.20130511.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.