#72 spectool -g sometimes unzips downloaded source file
Opened 3 years ago by ellert. Modified 2 years ago

Forwarded from https://bugzilla.redhat.com/show_bug.cgi?id=1905439

Description of problem:

For some sources, spectool -g unzips the downloaded file.
If the same URL is downloaded using wget the file is not unzipped.
Here is an example.

$ wget -N https://src.fedoraproject.org/rpms/xrootd/raw/master/f/xrootd.spec
--2020-12-08 12:08:11-- https://src.fedoraproject.org/rpms/xrootd/raw/master/f/xrootd.spec
Resolving src.fedoraproject.org (src.fedoraproject.org)... 38.145.60.21, 38.145.60.20
Connecting to src.fedoraproject.org (src.fedoraproject.org)|38.145.60.21|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 37821 (37K) [text/plain]
Saving to: 'xrootd.spec'

xrootd.spec 100%[===================>] 36.93K --.-KB/s in 0.1s

Last-modified header missing -- time-stamps turned off.
2020-12-08 12:08:12 (314 KB/s) - 'xrootd.spec' saved [37821/37821]

$ spectool -g xrootd.spec
Downloading: http://xrootd.org/download/v5.0.3/xrootd-5.0.3.tar.gz
100% of 2.6 MiB |######################| Elapsed Time: 0:00:07 Time: 0:00:07
Downloaded: xrootd-5.0.3.tar.gz
$ mkdir wget
$ cd wget
$ wget -N http://xrootd.org/download/v5.0.3/xrootd-5.0.3.tar.gz
--2020-12-08 12:09:04-- http://xrootd.org/download/v5.0.3/xrootd-5.0.3.tar.gz
Resolving xrootd.org (xrootd.org)... 134.79.138.109
Connecting to xrootd.org (xrootd.org)|134.79.138.109|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://xrootd.slac.stanford.edu/download/v5.0.3/xrootd-5.0.3.tar.gz [following]
--2020-12-08 12:09:04-- https://xrootd.slac.stanford.edu/download/v5.0.3/xrootd-5.0.3.tar.gz
Resolving xrootd.slac.stanford.edu (xrootd.slac.stanford.edu)... 134.79.138.26
Connecting to xrootd.slac.stanford.edu (xrootd.slac.stanford.edu)|134.79.138.26|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2766694 (2.6M) [application/x-gzip]
Saving to: 'xrootd-5.0.3.tar.gz'

xrootd-5.0.3.tar.gz 100%[===================>] 2.64M 375KB/s in 7.4s

2020-12-08 12:09:12 (367 KB/s) - 'xrootd-5.0.3.tar.gz' saved [2766694/2766694]

$ cd ..
$ ls -l xrootd-5.0.3.tar.gz wget/xrootd-5.0.3.tar.gz
-rw-rw-r--. 1 ellert ellert 2766694 Nov 11 21:07 wget/xrootd-5.0.3.tar.gz
-rw-rw-r--. 1 ellert ellert 16066560 Dec 8 12:08 xrootd-5.0.3.tar.gz
$ file xrootd-5.0.3.tar.gz wget/xrootd-5.0.3.tar.gz
xrootd-5.0.3.tar.gz: POSIX tar archive
wget/xrootd-5.0.3.tar.gz: gzip compressed data, max compression, from Unix, original size modulo 2^32 16066560

As can be seen the file downloaded with spectool -g is much bigger, and is an uncompressed tar archive (even though the file extension is still .tar.gz).

Version-Release number of selected component (if applicable):

rpmdevtools-9.2-1.fc33

How reproducible:
Always for the URL that is affected.

Steps to Reproduce:
1. See description above

Actual results:
Downloaded file is unzipped.

Expected results:
Downloaded file is not unzipped.


I was working on updating another package today, and was hit by this bug again.
This is a very annoying regression. It is possible to work around it by doing:

wget -N $(spectool --source 0 HepMC3.spec | cut -d ' ' -f2)

It is very easy to miss that a package is affected by the bug which would result in source RPM with uncompressed source.

This is either a bug in requests_download or requests, because we don't have any code in rpmdev-bumpspec that would do this... @decathorpe, any thoughts?

Best I can tell, this is a "feature" of requests, insofar that it automatically decompresses a download in "stream" mode, if the appropriate HTTP headers are set ... No idea how to work around this so far.

Login to comment on this ticket.

Metadata