Re: install/56303: On a fresh installation, /tmp on sparc64 is not sticky

[RVP <rvp%SDF.ORG@localhost>]

The following reply was made to PR install/56303; it has been noted by GNATS.

From: RVP <rvp%SDF.ORG@localhost>
To: Andreas Gustafsson <gson%gson.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost, martin%netbsd.org@localhost, roland.illig%gmx.de@localhost,
        Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>, vezhlys%gmail.com@localhost,
        christos%NetBSD.org@localhost
Subject: Re: install/56303: On a fresh installation, /tmp on sparc64 is not
 sticky
Date: Fri, 27 Aug 2021 23:21:01 +0000 (UTC)

 On Fri, 27 Aug 2021, Andreas Gustafsson wrote:
 
 >     100% |*******************************|   680 KiB  264.59 KiB/s    00:00 ETA
 >
 > The final transfer rate displayed will be based on the current time as
 > of the call to progressmeter(1), and since this call is currently made
 > after waiting for the "cmd" to exit, it _will_ reflect the total
 > execution time.
 >
 
 Yes, but should wait time (which is not IO time) be included in a xfer
 statistic? I felt that it was not, which is why I stopped the progress-bar
 before wait(). That it allowed me to get rid of 2 lines was an added
 bonus.
 
 But, really: I'm OK with progressbar(1) after the wait too. (After all,
 progress might well be called on to run a program which xfers files at 110
 baud--then you would see a different KiB/s between the 2 methods...)
 
 -RVP