Problem with perl upstream link

Problem with perl upstream link

[Andrei Gherzan]

[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]

From time to time my build crashes after trying to unpack the downloaded
perl package:
Check the log here:

ERROR: Logfile of failure stored in:
BUILD/tmp-eglibc-eglibc/work/i686-linux/perl-native-5.14.2-r0/temp/log.do_unpack.14775
Log data follows:
| NOTE: Unpacking
BUILD/tmp-eglibc-eglibc/work/i686-linux/perl-native-5.14.2-r0/
|
| gzip: stdin: invalid compressed data--crc error
| tar: Child returned status 1
| tar: Error is not recoverable: exiting now
| ERROR: Function failed: Unpack failure for URL: '
http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz'. Unpack command PATH="..."
tar xz --no-same-owner -f DOWNLOADS/perl-5.14.2.tar.gz failed with return
value 2
NOTE: package perl-native-5.14.2-r0: task do_unpack: Failed

To check the remote i did a simple test:

wget http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz
--2012-03-28 21:09:11--  http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz
Resolving www.cpan.org... 207.171.7.177, 199.15.176.140,
2620:101:d000:8::140:1, ...
Connecting to www.cpan.org|207.171.7.177|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 15223598 (15M) [application/octet-stream]
Saving to: `perl-5.14.2.tar.gz'

100%[=======================================================================================================================================>]
15,223,598  1.07M/s   in 99s

2012-03-28 21:10:52 (151 KB/s) - `perl-5.14.2.tar.gz' saved
[15223598/15223598]

tar xz --no-same-owner -f
/media/HDD-WRS/yocto/2012-03-28-18-49-yocto-ve/../downloads/perl-5.14.2.tar.gz

gzip: stdin: invalid compressed data--crc error
tar: Child returned status 1
tar: Exiting with failure status due to previous errors

Anybody knows about this issue?
@g

[-- Attachment #2: Type: text/html, Size: 2385 bytes --]

Re: Problem with perl upstream link

[Richard Purdie]

On Wed, 2012-03-28 at 21:02 +0300, Andrei Gherzan wrote:
> From time to time my build crashes after trying to unpack the
> downloaded perl package:
> Check the log here:
>
> ERROR: Logfile of failure stored in:
> BUILD/tmp-eglibc-eglibc/work/i686-linux/perl-native-5.14.2-r0/temp/log.do_unpack.14775
> Log data follows:
> | NOTE: Unpacking
> BUILD/tmp-eglibc-eglibc/work/i686-linux/perl-native-5.14.2-r0/
> |
> | gzip: stdin: invalid compressed data--crc error
> | tar: Child returned status 1
> | tar: Error is not recoverable: exiting now
> | ERROR: Function failed: Unpack failure for URL:
> 'http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz'. Unpack command
> PATH="..." tar xz --no-same-owner -f DOWNLOADS/perl-5.14.2.tar.gz
> failed with return value 2
> NOTE: package perl-native-5.14.2-r0: task do_unpack: Failed
>
> To check the remote i did a simple test:
>
> wget http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz
> --2012-03-28 21:09:11--
>  http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz
> Resolving www.cpan.org... 207.171.7.177, 199.15.176.140,
> 2620:101:d000:8::140:1, ...
> Connecting to www.cpan.org|207.171.7.177|:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 15223598 (15M) [application/octet-stream]
> Saving to: `perl-5.14.2.tar.gz'
>
> 100%[=======================================================================================================================================>] 15,223,598  1.07M/s   in 99s
>
> 2012-03-28 21:10:52 (151 KB/s) - `perl-5.14.2.tar.gz' saved
> [15223598/15223598]
>
> tar xz --no-same-owner
> -f /media/HDD-WRS/yocto/2012-03-28-18-49-yocto-ve/../downloads/perl-5.14.2.tar.gz
>
> gzip: stdin: invalid compressed data--crc error
> tar: Child returned status 1
> tar: Exiting with failure status due to previous errors
>
> Anybody knows about this issue?

I tried the above and it seems to be ok for me.

Several things come to mind:

a) Is the checksum of the file ok?
b) what versions of tar and gzip do you have?

If the checksum is ok, I suspect the problem is in b). We do have some
workarounds in the system to deal with broken versions of tar and gzip.
You'd have to see the logs to see which versions were problematic. We do
usually avoid problems but there was recently a regression in that code
which was subsequently fixed which might have exposed you to this.

If the checksum is not ok, I'd have to wonder why the fetch didn't fail
with a bad checksum.

Cheers,

Richard