#61 spectool -g seems to provide odd download times
Closed 2 years ago by decathorpe. Opened 3 years ago by kevin.

100% of 13.6 MiB |#########################################| Elapsed Time: -1 day, 17:00:04 Time: -1 day, 17:00:04

While it's transfering the ETA seems normal:

11% of 13.6 MiB |##### | Elapsed Time: -1 day, 17:00:01 ETA: 0:00:05^CTraceback (most recent call last):

also, might be nice to not traceback on control-c if possible.


This is very strange.

spectool uses requests_download in exactly the way it's presented in its README:
https://github.com/takluyver/requests_download/blob/master/README.rst

So that should not be an issue :/

Regarding traceback: Of course, that's not a good look. I can add some Ctrl-C handling.
Do you think it should remove partially downloaded files or leave them (broken) in place?

I'd rather it deleted partially downloaded files.

+1 to delete. Bonus if it told you it did so...

11% of 13.6 MiB |##### | Elapsed Time: -1 day, 17:00:01 ETA: 0:00:05^C
inturrupted: partial download removed

Better handling of KeyboardInterrupt was implemented in commit 0fa3941.

It will also delete partially downloaded files if they exist.

No idea yet how to approach the weird progress bar though, since that's all third-party stuff (progressbar2 and requests_download). :pensive:

Well, now I've upgraded to Fedora 33 and it seems that spectool -g output "wrongly" take TZ variable into account, for example:

[tasaka1@localhost master]$ TZ=Europe/London spectool -g ./xcircuit.spec 
Downloading: http://opencircuitdesign.com/xcircuit/archive/xcircuit-3.10.29.tgz
 12% of   1.5 MiB |################                                                                                                                      | Elapsed Time: 1:00:04 ETA:   0:00:31^CDownload cancelled, removing partially downloaded file.
100% of   1.5 MiB |######################################################################################################################################| Elapsed Time: 1:00:04 Time:  1:00:04
[tasaka1@localhost master]$ TZ=Asia/Tokyo spectool -g ./xcircuit.spec 
Downloading: http://opencircuitdesign.com/xcircuit/archive/xcircuit-3.10.29.tgz
 27% of   1.5 MiB |#####################################                                                                                                 | Elapsed Time: 9:00:02 ETA:   0:00:05^CDownload cancelled, removing partially downloaded file.
100% of   1.5 MiB |######################################################################################################################################| Elapsed Time: 9:00:02 Time:  9:00:02
[tasaka1@localhost master]$ TZ=Pacific/Honolulu spectool -g ./xcircuit.spec 
Downloading: http://opencircuitdesign.com/xcircuit/archive/xcircuit-3.10.29.tgz
 13% of   1.5 MiB |################                                                                                                             | Elapsed Time: -1 day, 14:00:02 ETA:   0:00:09^CDownload cancelled, removing partially downloaded file.
100% of   1.5 MiB |#####################################################################################################################| Elapsed Time: -1 day, 14:00:02 Time: -1 day, 14:00:02

I've noticed this because I live in Japan, UTC+9h and spectool -g always shows 9:00:XX ...

That sounds like a bug in requests_download and / or progressbar :(

There's zero logic for downloading files in spectool itself, only those two lines, for setting up the progress bar and the download itself:

    progress = ProgressTracker(DataTransferBar())
    download(url, path, trackers=(progress,))

https://pagure.io/rpmdevtools/blob/master/f/rpmdev-spectool#_198

So apparently reverting this change fixes this issue for me:
https://github.com/WoLpH/python-progressbar/commit/1fe36a21dcc47ab3a76ff899e10ae4857325e9c1

The problem here is that the above change is to fix a issue reported here: https://github.com/WoLpH/python-progressbar/issues/209 ... and from a quick glance, for me it seems that fromtimestamp is right here, so for now I don't what is the correct fix...

So instead of my previous comment, the below change seems to fix this issue????

# diff -up /usr/lib/python3.9/site-packages/progressbar/bar.py{.debug,}
--- /usr/lib/python3.9/site-packages/progressbar/bar.py.debug   2020-06-18 06:59:51.000000000 +0900
+++ /usr/lib/python3.9/site-packages/progressbar/bar.py 2020-09-22 23:08:04.596865595 +0900
@@ -759,6 +759,7 @@ class ProgressBar(StdRedirectMixin, Resi
             raise ValueError('max_value out of range, got %r' % self.max_value)

         self.start_time = self.last_update_time = datetime.now()
+        self.start_time = self.last_update_time = datetime.now()
         self._last_update_timer = timeit.default_timer()
         self.update(self.min_value, force=True)

My print-debugging shows that on the previous line, self.start_time is wrongly set as UTC time. With adding the same line, now self.start_time is correctly set as local time.

Now I suspect this is a bug in python itself?

I believe this is a bug in RPM, which can be workarounded by calling time.tzset() after parsing the specfile.

More info in my comments in https://bugzilla.redhat.com/show_bug.cgi?id=1881917

Sorry for taking so long to respond here.

So you think we can work around this RPM issue by using import time and adding a call of time.tzset() here:

https://pagure.io/rpmdevtools/blob/master/f/rpmdev-spectool#_207

Workaround has been merged, so this should be fixed.

Metadata Update from @decathorpe:
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata