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]> 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/<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/<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<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/ <http://www.scientificlinux.org/> >>>> >>>> >>>> >>> >>> -- >>> Pat Riehecky >>> >>> Scientific Linux developer >>> http://www.scientificlinux.**org/ <http://www.scientificlinux.org/> >>> >>> >> >> > > -- > Pat Riehecky > > Scientific Linux developer > http://www.scientificlinux.**org/ <http://www.scientificlinux.org/> > >