Bug 496445 - Fails to display download progress for Presto downloaded packages
Summary: Fails to display download progress for Presto downloaded packages
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: PackageKit
Version: rawhide
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F11Target
TreeView+ depends on / blocked
 
Reported: 2009-04-19 09:28 UTC by Martin Sourada
Modified: 2009-04-24 14:52 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-04-24 14:52:08 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Martin Sourada 2009-04-19 09:28:43 UTC
Description of problem:
The new update tool does not display download progress for packages that downloaded via yum-presto.

Version-Release number of selected component (if applicable):
gnome-packagekit-2.27.2-0.2.20090414git.fc11.i586
PackageKit-0.4.6-3.fc11.i586
yum-3.2.22-4.fc11.noarch
yum-presto-0.4.5-4.fc11.noarch

How reproducible:
Always.

Steps to Reproduce:
1. Install yum-presto on Rawhide
2. Run System -> Administration -> Software Updates
3. Update system
  
Actual results:
Download progress is shown for all packages that are being downloaded

Expected results:
Download progress is shown only for packages *not* downloaded by Presto

Additional info:
Since yum-presto is probably going to be enabled by default on F11, marking as release blocker.

Comment 1 Richard Hughes 2009-04-19 09:57:01 UTC
We've enabled presto by default post Development Freeze? How on earth am I meant to have known this, let alone tested this? Surely presto needs to work with PackageKit, rather than PackageKit work with presto?

Comment 2 Martin Sourada 2009-04-19 10:11:07 UTC
(In reply to comment #1)
> We've enabled presto by default post Development Freeze? How on earth am I
> meant to have known this, let alone tested this? Surely presto needs to work
> with PackageKit, rather than PackageKit work with presto?  
I am not privy to the reasoning behind this late and rather unpublished change. Not sure when/if it was actually enabled by deafault in comps, but delta rpms are already pushed to our mirrors and AFAIK the plan indeed is to have it enabled by deafult (if not, feel free to remove the F11Blocker). I don't know the details about presto integration with yum/PackageKit. Adding yum-presto maintainer to CC list.

Comment 3 Richard Hughes 2009-04-19 11:01:09 UTC
I've bodged in a local fix:

commit dd136f6760d375ba55ec98ab02291028c03d8b46
Author: Richard Hughes <richard>
Date:   Sun Apr 19 11:59:42 2009 +0100

    yum: Deal with Presto downloading updates in a better way

I'll build a package for you to try.

Comment 4 Richard Hughes 2009-04-19 11:28:15 UTC
Can you try http://koji.fedoraproject.org/koji/taskinfo?taskID=1307814 please. Thanks.

Comment 5 Martin Sourada 2009-04-19 11:46:17 UTC
(In reply to comment #4)
> Can you try http://koji.fedoraproject.org/koji/taskinfo?taskID=1307814 please.
> Thanks.  

I've quickly reverted one of the packages from latest updates and tried updating with PackageKit. Seems it works now as expected, I'll test it more most likely when next batch of updates is out.

Thanks.

Comment 6 Rex Dieter 2009-04-20 12:40:10 UTC
Curious, does this only affect the pk backend, or were changes required to the gui/frontend as well?  If the latter, does this affect kpackagekit as well?

Comment 7 Rex Dieter 2009-04-20 12:42:06 UTC
(Looking closer, since the assigned component is gnome-packagekit, I'll assume this is an interface issue)

Comment 8 Richard Hughes 2009-04-20 12:43:51 UTC
No, just the daemon. When using presto we get passed a YumAvailablePackageSqlite rather than a YumLocalPackage. This is used to work out which package is being downloaded and the correct signals are sent to the frontend. This fix sorts pkcon, GPK and KPK.

Comment 9 Martin Sourada 2009-04-20 19:28:56 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > Can you try http://koji.fedoraproject.org/koji/taskinfo?taskID=1307814 please.
> > Thanks.  
> 
> I've quickly reverted one of the packages from latest updates and tried
> updating with PackageKit. Seems it works now as expected, I'll test it more
> most likely when next batch of updates is out.
> 
> Thanks.  
Looks like this one was false positive or something other broke again in the meatime. During today's batch of updates only one of the Xorg server packages showed download progress and/or finished download :-/

Also changing it to block F11Target rahter the F11Blocker as suggested on devel list.

Would be nice if some of the other people CC-ed to this bug could verify if the fix works or does not works for them.

Comment 10 James Antill 2009-04-21 03:14:28 UTC
I don't think this is anything to do with presto, as I just played with PK and installed a bunch of things ... and got no progress info. on the downloads -- after a few minutes I gave up and used the yum cmd line and it worked fine (downloading them directly).

Comment 11 Martin Sourada 2009-04-21 06:40:40 UTC
Hm... at closer look the actual issue does not seem to be connected to presto. I've just installed three updates, all of which were most likely downloaded by presto, but only one of them showed download progress - the first one in the list. If I recall correctly, the only update from yesterday that showed download progress was also first in the list... Next time I'll try without presto to see if it really is another bug I am hitting now.

Comment 12 Martin Sourada 2009-04-21 07:08:33 UTC
(In reply to comment #11)
> Next time I'll try without
> presto to see if it really is another bug I am hitting now.  
So, this happens without yum-presto as well. Filled bug 496787.

Comment 13 Richard Hughes 2009-04-24 14:52:08 UTC
Build tagged for f11-final. Thanks!


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