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/ > > > >