Bug 19930

It would ease (not "easy") the load on mirrors...

Just tried netinstall with Mageia 5.1 and the progress bar worked perfectly.

Maybe I try to Mageia 6 netinstall again to confirm if the issue is reproducible (in other words, a regression).

(In reply to Renato Dali from comment #2)
> Just tried netinstall with Mageia 5.1 and the progress bar worked perfectly.
> 
> Maybe I try to Mageia 6 netinstall again to confirm if the issue is
> reproducible (in other words, a regression).

Thierry mentioned in a recent commit that the progress bar misbehaves, and one of the QA testers confirmed it.

CC: (none) => marja11
Assignee: bugsquad => mageiatools
Source RPM: (none) => drakx-installer-stage2
Keywords: (none) => 6sta2

(changing severity to normal, because this is a regression and not an enhancement request)

Severity: enhancement => normal

(In reply to Marja van Waes from comment #3)
> Thierry mentioned in a recent commit that the progress bar misbehaves, and
> one of the QA testers confirmed it.

Yeah this is because of fix for bug #19895

CC: (none) => thierry.vignaud
Depends on: (none) => 19895

(In reply to Thierry Vignaud from comment #5)

> 
> Yeah this is because of fix for bug #19895

As you probably noticed, this bug report was opened at 2016-12-12 02:57:18 CET before the 3 last commits for that bug were pushed. Only this one was already pushed:

http://gitweb.mageia.org/software/drakx/commit/?id=08d23a39f5ff5bdfe736190b1088dc534e5b1bb9

Summary: On Mga6 netinstall, progress bar is not available when installing packages. => On Mga6 netinstall, progress bar is not available when installing packages, (at least since DrakX v17.64)

And it could way be the culprit

commit d6b9de2d5c0d748a35287dae11950afbdb848b55
Author: Pascal Terjan <pterjan@...>
Date:   Tue Dec 13 23:49:20 2016 +0000

    17.66 (should fix mga#19933 and mga#19930)
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=d6b9de2d5c0d748a35287dae11950afbdb848b55

 Bug links:
   Mageia
      https://bugs.mageia.org/19933
      https://bugs.mageia.org/19930

The problem is that $ratio is now an int64 so it can be only 0 or 1.

CC: (none) => pterjan

Yeah we've revert parts of the int64() calls.
Which shows the issue is that the division of int64 returns an int64 which converts progress_total from its intial value of "scalar ref to 0" to "ref to Int64 resulting from div)...

See eg:
$ perl -e 'use Math::Int64 "int64"; $a =int64(32); $b=int64(128); warn $a/$b'
0 at -e line 1.
$ perl -e 'use Math::Int64 ":native_if_available", "int64"; $a =int64(32); $b=int64(128); warn $a/$b'
0.25 at -e line 1.

int64_to_number() does the trick

But the ratio is absurd because it returns strings for big numbers...

I think size2time is used only for that ratio so we should be able to rewrite totally a size2time_ratio taking int64s and returning a (normal) number

I regret having listening guibo for fixing that small issue of bogus sizes printed on i586 for big packages :-(
I think I'll patch Math::Int64 in order to provide int64_to_float() or we'll just make drakx uses sg like:
sub int64_to_float { sprintf("%.2f", $_[0])*1 }

(In reply to Pascal Terjan from comment #14)
Yeah it's the only user of size2time() in all our code

It works...

Created attachment 8776 [details]
(size2time) enforce returning a float (mga#19930)

Created attachment 8777 [details]
revert forcing $progress_total & $ratio to be int64

commit 1b0aaf551631c1f9c997100b61d674abf7aead75
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Wed Dec 14 16:42:04 2016 +0100

    revert forcing $progress_total & $ratio to be int64
    
    it's bogus as then, when not using native int64 (eg: i586), the ratio
    cannot be a float between 0 & 1 and thus the progress bar can never be
    updated (mga#19930)
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=1b0aaf551631c1f9c997100b61d674abf7aead75

commit 50edb3c63a62c3b842f483588bdde8deb8a4fc84
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Wed Dec 14 16:41:26 2016 +0100

    (size2time) enforce returning a float (mga#19930)
    
    with the previous fix, the progress bar will now properly update on
    i586 will be a float between 0 & 1
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=50edb3c63a62c3b842f483588bdde8deb8a4fc84

Fixed

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

Sorry but I have to reopen.

There is no visible difference in i586 install using 
drakx-installer-stage2-17.68

* getFile install/stage2/VERSION on http://mirrors.kernel.org/mageia/distrib/cauldron/i586
* retrieving   VERSION
* '/usr/bin/curl' '-q' '--location-trusted' '-R' '-f' '--disable-epsv' '--connect-timeout' '60' '--anyauth' '-s' '--stderr' '-' '-O' 'http://mirrors.kernel.org/mageia/distrib/cauldron/i586/install/stage2/VERSION'
* retrieved   VERSION
* second stage install running (DrakX v17.68)

On this install the 'Time remaining' switched back and forth between 16:48 and 10 sec.
For a brief period every time TR showed 10 sec the 'Progress bar' would be fully populated, at All others it remained empty.

Status: RESOLVED => REOPENED
CC: (none) => cae
Resolution: FIXED => (none)

In a dvd.iso install both 'Time remaining' and 'Progress bar' are reasonably accurate through out the install.

It is only during boot.iso installs that the values are bad.

What is the drakx version used on the dvd?

(In reply to Pascal Terjan from comment #25)
> What is the drakx version used on the dvd?

17.68 is used

(In reply to Pascal Terjan from comment #25)
> What is the drakx version used on the dvd?

17.68 is used on the dvd.

Pardon my ignorance, but these estimates are based on average transfer rates, right? Because instantaneous network rates would bring trouble...

Because that is what would cause a big difference between a more-or-less steady rate device like a DVD and the totally unpredictable internet, paired with HTTP, known for quite meaningful speed variations -- not to mention ISP/mirror shaping policies...

That reminds me of something... https://xkcd.com/612/   :-)

Reinstalled Mageia 6 netinstall.

There was an error in the script to install Flashplayer-plugin... maybe that's related to the new version. Or not.

The problem still persists. 0% all the time.

As it was said that stage2 comes from the server, are we really testing the fixed version. Shouldn't we choose a specific server or are all mirrors already in sync? (I'm using http, BTW)

(In reply to Renato Dali from comment #29)

> 
> As it was said that stage2 comes from the server, are we really testing the
> fixed version. Shouldn't we choose a specific server or are all mirrors
> already in sync? (I'm using http, BTW)

After installing and rebooting into the new install, run as root:

     xzcat /root/drakx/report.bug.xz | grep DrakX


If you have the correct stage2 version, you'll see:


* second stage install running (DrakX v17.68)

http://mageia.c3sl.ufpr.br/distrib/cauldron/i586/install/stage2/ looks good, btw

Created attachment 8797 [details]
Screenshot of the package install screen

I just tried an i586 netinstall in qemu, using ftp.free.fr, and it worked well, here is a screenshot in the middle but it progressed in the right direction.

(In reply to Renato Dali from comment #28)
> Pardon my ignorance, but these estimates are based on average transfer
> rates, right? Because instantaneous network rates would bring trouble...

It is based on the number of bytes to install in total and how many have been installed so far, so it should approximate the average download + write to disk speed

Closing again, it is *fixed*

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

@ Marja

OK, it is the right version (17.68).

@Pascal

Pascal, I think we're not on the same page.

I mean, literally, as I've been using the "text" image instead of the graphical one (it's a 512MB RAM netbook).

Don't know whether this makes any difference (it shouldn't, I suppose), but the fact is that it stays at 0% during the whole package download & install.

@ Thierry

I suppose this is minor anyway, after all the installation works -- so at least it's a WORKSFORME.

But some people (like me) could be fooled into thinking it's not working and that would cause lost time and stress to mirrors...

Ah right, parts of the fixes were in gtk interface so it is likely the text version also has some problems but text had not been mentioned previously

Curses::UI does things like:
    # Compute percentage
    my $perc = ($this->{-pos}-$this->{-min})
                /($this->{-max}-$this->{-min})*100;

And we are now giving int64 for -pos and -max so yes that will be 0, we should transform the values before passing them on

We'd better open a new/separate bug for the text version, this one is already too long

(In reply to Thierry Vignaud from comment #38)
> We'd better open a new/separate bug for the text version, this one is
> already too long

Done, see bug 19973

Marja/Pascal/Thierry, thanks for answering and I'm sorry I didn't say anything about text. I try to avoid losing important details -- and it happens anyway.