That is very surprising!
yum has supported bz2 files forever......
Can you send me the bug info so I can join the watch list?
Pat
On 06/03/2013 03:01 PM, Paul Robert Marino wrote:
Resolved sort of.
Ill file a bug report with spacewalk
I just figured out whats causing it its the updateinfo.bz2 file apparently spacewalk-repo-sync doesn't know how this file in bz2 format.
On Thu, May 30, 2013 at 11:58 AM, Pat Riehecky <[log in to unmask]> wrote:
I believe I've just reconfigured apache to not compress .gz/.bz2 files again. They joy of adding compression by encoding type rather than filename.
Pat
On 05/30/2013 05:13 AM, Ansgar Hockmann-Stolle wrote:
Maybe an issue with the web server?
Downloading the file with firefox and wget will give different files:
216856 May 30 11:38 firefox/comps-sl6-x86_64.xml.gz
216991 Mar 22 19:10 wget/comps-sl6-x86_64.xml.gz
The Apache is zipping the file on the fly again, but firefox does not unzip it right:
firefox/comps-sl6-x86_64.xml: gzip compressed data, from Unix, max compression
firefox/comps-sl6-x86_64.xml.gz: gzip compressed data, from Unix
wget/comps-sl6-x86_64.xml: XML document text
wget/comps-sl6-x86_64.xml.gz: gzip compressed data, from Unix, max compression
firefox/comps-sl6-x86_64.xml is the original zipped file!
Sniffing while downloading with firefox:
GET /linux/scientific/6.4/x86_64/os/repodata/comps-sl6-x86_64.xml.gz HTTP/1.1[...]
Host: ftp.scientificlinux.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Referer: http://ftp.scientificlinux.org/linux/scientific/6.4/x86_64/os/repodata/
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
HTTP/1.1 200 OK
Date: Thu, 30 May 2013 09:38:04 GMT
Server: Apache
Last-Modified: Fri, 22 Mar 2013 18:10:26 GMT
ETag: "3fa15b6f-34f9f-4d8875e974880"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Security-Policy: default-src 'self'; style-src 'self' unsafe-inline;
X-Content-Security-Policy: allow 'self'; default-src 'self'; style-src 'self' unsafe-inline;
Keep-Alive: timeout=3, max=200
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/x-gzip
1faa
Sniffing while downloading with wget:
GET /linux/scientific/6.4/x86_64/os/repodata/comps-sl6-x86_64.xml.gz HTTP/1.1[...]
User-Agent: Wget/ (linux-gnu)
Accept: */*
Host: ftp.scientificlinux.org
Connection: Keep-Alive
HTTP/1.1 200 OK
Date: Thu, 30 May 2013 09:49:27 GMT
Server: Apache
Last-Modified: Fri, 22 Mar 2013 18:10:26 GMT
ETag: "3fa15b6f-34f9f-4d8875e974880"
Accept-Ranges: bytes
Content-Length: 216991
Vary: Accept-Encoding
Content-Security-Policy: default-src 'self'; style-src 'self' unsafe-inline;
X-Content-Security-Policy: allow 'self'; default-src 'self'; style-src 'self' unsafe-inline;
Keep-Alive: timeout=3, max=200
Connection: Keep-Alive
Content-Type: application/x-gzip
^_213^H^@^@^@^@^@^B^C254Z333s333֙^?357_qV/j247U330vvgvv\v353244333d266323355244
I think apache should be configured not to zip already zipped files.
Ciao
Ansgar
Am 28.05.2013 17:25, schrieb Pat Riehecky:
When I run less on the file, it show the text as expected.
Spacewalk is not really my area of expertise.... is your Spacewalk
server fully updated?
Pat
On 05/28/2013 10:16 AM, Paul Robert Marino wrote:
I downloaded it with wget and used the less command on it.
sure enough when i use cat on it it returns binary data but it still
doesn't explain why this only happens with scientific Linux repos. Im
wondering if its because there is both a comps-sl6-x86_64.xml.gz and a
comps-sl6-x86_64.xml file in the repo. or if spacewalk is complaining
about an other file the error is somewhat vague the only reason I
thought the comps file might be the issue is because its mentioned
right before the error.
On Tue, May 28, 2013 at 10:31 AM, Pat Riehecky <[log in to unmask]
<mailto:[log in to unmask]>> wrote:
On 05/28/2013 09:19 AM, Paul Robert Marino wrote:
Hello
I have been having issues with spacewalk and Scientific Linux 6.4
and 6 rolling repos
after investigation I found 2 errors
first
"
Repo
http://ftp.scientificlinux.org/linux/scientific/6.4/x86_64/os/
has comps file comps-sl6-x86_64.xml.gz.
ERROR: Not a gzipped file
"
The second is spacewalk 1.8 doesn't handle the error gracefully
but version 1.9 does.
note version 1.8 does not produce the "ERROR: Not a gzipped file"
instead it does a trace back about an unknown error code.
Ive checked
http://ftp.scientificlinux.org/linux/scientific/6.4/x86_64/os/repodata/comps-sl6-x86_64.xml.gz
and been able to confirm that indeed it is not gziped this should
be corrected in whatever script is generating it.
Thank You
Paul Robert Marino
Thanks for the report,
The comps.xml files for SL6.4 were compressed with zopfli in gzip
compatibility mode. This resulted in a 11% size savings on my
limited testing.
They decompress correctly with gzip (just tested again)
$ gzip -dc comps-sl6-x86_64.xml.gz |wc -l
16830
and they are correctly identified by 'file' as being gzip
compressed data.
$ file comps-sl6-x86_64.xml.gz
comps-sl6-x86_64.xml.gz: gzip compressed data, from Unix, max
compression
How did you check the comps-sl6-x86_64.xml.gz file that it
reported as a non-gzip file?
Pat
--
Pat Riehecky
Scientific Linux developer
http://www.scientificlinux.org/