There was a progress in the status bar ? 

Thierry, side effect of the oxygen theme ?

Assignee: bugsquad => thierry.vignaud
Source RPM: (none) => drakx-installer-stage2

No progress in progress bar.
Also, when switching back from text terminal: no text & no bar.

The installer doesn't use the oxygen theme.
We don't redraw the GUI when switching back from the console.

Priority: Normal => Low
Severity: normal => enhancement

When is it supposed to be redrawn?

When download has progressed a little bit to the point we've to move the progress bar. Else we're literally waiting for the download program (curl, aria2) to display a significant progress

BTW, did the installer uses aria2c or curl?
You could try restarting the install, remove the one that was used in the previous run by going into console 2 and remove it from /usr/bin) and see if the install works better with the other

I could add some signal making it force refreshing every 10s (with gdk_threads_enter()/leave() ) but ideally we would have to fork the whole install in another process (heavy work) or have the WM keeping images of the windows

Keywords: (none) => NEEDINFO

#5: The display was showing 7 hours left, and same package for minutes. (i had it show details)  But i saw in my server urpmi-proxy.log that it downloaded different packages. So I changed to a text terminal where i saw downloader progressing file after file.  Changed back to graphic screen.  No updates.  I let it finish, and screen came to live in post install configuration (screen, mouse etc)

#6: I used network install, so I or anyone else can repeat. I do not know how to see which downloader is used?  Will it be the same now after installation, as it was during network installation?

Having a signal to refresh every 5 second (after latest file retrieval) sounds like a good measure. ( If it can refresh on terminal shift or some key press or mouse click even better. )

Humm, the global progress bar will only updated after significant changes, so it may takes several packages to do so.

The bug is also in the installed system!
fully updated mga2 (=beta1 at least.)

Running MCC->Add/remove programs:  Now i noticed that also the graphical progress bar of downloading each rpm, can stop:
I see in my scrolling log of urpmi-proxy that it keep fetching packages, but the progress dialog stopped fifteen minutes ago at 8% of package "pingus", although it is currently downloading the next package "vdrift" since ten minutes or more.

I can switch screens, apps, minimise/restore - it redraws but still no progress update.

@ Thierry

This bug still has the NEEDINFO keyword, but I'm not sure about removing it (you didn't get the answer to your aria2c/curl question in comment 6, but you didn't answer Morgan's question in comment 7 about how to see which one is used, either)

CC: (none) => marja11

urpmi -v or urpmi -v --debug would show
Might be a urpmi-proxy issue.
Could you try beta2?

Thanks for info.  Possibly I will try fresh install next week.

no, i think i can confirm this with network installs (likely unrelated to urpmi-proxy though:

what happens is: the total install takes about 7 hours at first.

in the beginning, there is no progress indication, it's still calculating.

if you install a full thing over network install, and it takes 7 hours, you'll need at least 20 à 30min before it shows progress, simply because there is no "significant progress".

the fact that the user reports that text install is installing packages, (in a full install, it'll need like 2000 or 3000 packages, so it's only normal it takes ages like this.

the sad part is that when you switch to text mode and switch back, that's when a refresh could be usefull, because there's only a partial result.

same thing happens when you switch to details or back, it takes a while before it starts displaying again.

of course, this being urpmi-proxy, next time he does it, it'll go blindingly fast, since it's all in cache...

i've seen this since mandriva times in the rpmdrake too, if it's installing and you go away to come back later, it's not updated at all...

repaint shouldn't be blocked by getting the actual progress, it would be better to decouple the paint and getting the results. and cache the result settings in the middle and have paint keep doing whatever it does normally.

i guess for more info to get this fixed, one would have to see how the Gtk stuff works.

but i'm 100% sure i've seen this since my earliest mandrake install.

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

This is an installer/enhancement request, so keeping as a cauldron report.

Keywords: NEEDINFO => (none)
CC: (none) => davidwhodgins

This is one of 8 hyper-stale bugs and enhancement requests (other than package requests) that are now being closed as old.

Each of them
* is still assigned to BugSquad instead of to a maintainer
* did not see any action since June 2012

If this one is still valid, then please reopen it. 

In that case: don't be shocked that I closed it:
There is more chance it'll get fixed after it's wrongly closed and then reopened again (because of the mails Bugzilla sends to many packagers etc. when there is some action in a bug), than when nothing happens in this report for some more years :-)

Status: NEW => RESOLVED
Resolution: (none) => OLD