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.
>
> 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.
> Ill file a bug report with spacewalk
>
>
> On Thu, May 30, 2013 at 11:58 AM, Pat Riehecky <[log in to unmask]
> <mailto:[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 <http://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 <http://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]>
> <mailto:[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/
>
>
>
>
|