its here https://bugzilla.redhat.com/show_bug.cgi?id=970315
note Ive tested the patch back ported from the 1.10 master git branch to my
spacewalk 1.9 server in my test environment and it works.



On Tue, Jun 4, 2013 at 9:25 AM, Pat Riehecky <[log in to unmask]> wrote:

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