Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 450931 - Review of an update shows no info
Summary: Review of an update shows no info
Alias: None
Product: Fedora
Classification: Fedora
Component: PackageKit
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Robin Norwood
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-06-11 19:11 UTC by Nicola Soranzo
Modified: 2008-06-19 15:41 UTC (History)
3 users (show)

Fixed In Version: 0.2.3-4.20080618.fc10
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-06-19 15:41:27 UTC

Attachments (Terms of Use)
gpk-update-viewer --verbose output (deleted)
2008-06-12 13:43 UTC, Nicola Soranzo
no flags Details
Output of /usr/sbin/packagekitd --verbose > pkd.out & (deleted)
2008-06-12 17:01 UTC, Nicola Soranzo
no flags Details
gpk-update-viewer --verbose output (deleted)
2008-06-12 17:03 UTC, Nicola Soranzo
no flags Details

Description Nicola Soranzo 2008-06-11 19:11:42 UTC
Description of problem:
When reviewing available updates, I was not able to see the info for
file-roller-2.22.3-1.fc9 package. When I select the package, the foot near
"Getting Information..." moves for a few seconds, then stops and no info is
I think the reason is the presence of some unexpected characters in the Update
Information, in fact the corresponding Fedora-package-announce email says:
"Update Information:

The latest stable upstream release of file-roller fixes a number of bugs:     *
Fixed bug #523158 – exclamation mark in RAR passwords   * Provide and install
a 24x24 application icon to prevent a blurry launcher icon in the menu   * Fixed
bug #480190 – files added to archive are wrongly placed in root"

The info for other update packages displays fine as before, but I think this bug
can be malicious.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Start PackageKit
2. Select Review
3. Select file-roller-2.22.3-1.fc9 package
Actual results:
No info for the package.

Expected results:
Update info for the package.

Additional info:

Comment 1 Richard Hughes 2008-06-12 10:50:15 UTC
Can you get the "gpk-update-viewer --verbose" output when the file-roller update
is selected please? Thanks.


Comment 2 Nicola Soranzo 2008-06-12 13:43:02 UTC
Created attachment 309069 [details]
gpk-update-viewer --verbose output

Here it is.
Thanks for the fast response.

Comment 3 Richard Hughes 2008-06-12 16:11:51 UTC
Cool, I think the dameon is being paranoid and rejecting the input as invalid.
Could you please do:

su -l
killall packagekitd
/usr/sbin/packagekitd --verbose

and then click the update in gpk-update-viewer -- you should get some output
from packagekitd about the update text. Thanks!

Comment 4 Nicola Soranzo 2008-06-12 17:01:34 UTC
Created attachment 309102 [details]
Output of /usr/sbin/packagekitd --verbose > pkd.out &

Probably this is the problem:

*** WARNING ***
TI:18:54:45	TH:0x8751458	FI:pk-spawn.c  
 - cannot covert line to UTF8: updatedetail    
file-roller;2.22.3-1.fc9;i386;updates	file-roller;2.22.1-1.fc9;i386;installed
	none	The latest stable upstream release of file-roller fixes a
number of bugs:;; * Fixed bug #523158 – exclamation mark in RAR passwords; *
Provide and install a 24x24 application icon to prevent a blurry launcher icon
in the menu; * Fixed bug #480190 – files added to archive are wrongly placed
in root

Comment 5 Nicola Soranzo 2008-06-12 17:03:07 UTC
Created attachment 309104 [details]
gpk-update-viewer --verbose output

I attach also the corresponding output.

Comment 6 Richard Hughes 2008-06-13 07:42:30 UTC
Cool, thanks for the debugging. What packagekitd is doing is the following:

message = g_locale_to_utf8 (lines[i], -1, NULL, NULL, NULL);
if (message == NULL) {
	pk_warning ("cannot covert line to UTF8: %s", lines[i]);
} else {
	pk_debug ("emitting stdout %s", message);
	g_signal_emit (spawn, signals [PK_SPAWN_STDOUT], 0, message);

So we are assuming the data from yum is in the C locale, when actually yum is
sometimes supplying valid UTF8. I've removed the conversion of g_locale_to_utf8
and updated the self check code to include an exmaple '•', and now it passes. We
already do UTF8 validation in the pk_strsafe() function, so the conversion is
safe to remove.

I'll commit this to head, and if there are no regressions, I'll backport to F9
too. Thanks!

Comment 7 Nicola Soranzo 2008-06-13 14:34:08 UTC
Ok, thank you!
If you backport to F9, I'll be happy to test it.

Comment 8 Nicola Soranzo 2008-06-19 15:41:27 UTC
I tried the last rawhide build for PackageKit and the bug is in fact resolved.

Note You need to log in before you can comment on or make changes to this bug.