uninitialized value at Fetchware.pm line 811 #4

Closed
wbiker opened this Issue Dec 12, 2013 · 1 comment

Comments

Projects
None yet
2 participants

wbiker commented Dec 12, 2013

Hi,

I just updated Fetchware and created a new fetchware file for freetds.

URL path: ftp://ftp.freetds.org/pub/freetds/current/

After creation I say Y to start the installation process.
Fetchware downloaded the directory listing, but unforutnately something goes wrong if parsing the files timestamp:
Use of uninitialized value in numeric comparison (<=>) at /usr/local/share/perl5/App/Fetchware.pm line 811.

I checked the array at line 811:
my @sorted_listing = sort { $b->[1] <=> $a->[1] } @$file_listing;
It starts with:
$VAR1 = [
[
'freetds-dev.0.92.377.tar.gz',
undef
],
[
'freetds-dev.0.92.377.tar.gz.md5',
undef
],
[

I checked the freetds webside again and realised that the undef entries are the one that are linked to by the freetds-current.tgz and .md5 links.

Owner

deeelwy commented Dec 14, 2013

Yeah, the two that parsed as undef were from the first two, which are symbolic links. I've never run into symbolic links before, so my timestamp parser failed when it ran into them. I fixed this bug by having the parser use regular, positive array indexes instead of the negative, "backwards," ones it was using. This was fixed in commit 16f330a .

The actual bug causing freetds to fail installation was due to fetchware's md5sum checking code. It used a very simple parser that could only parse the output of the md5sum or sha1sum programs. Freetds uses some other method for calculating the md5sums and stores that output in a format different than the one fetchware assumes.
So, fetchware's crummy md5sum parser was made more reliable in commit f641f64 .

These fixes are available in fetchware 1.010, which was just released to CPAN.

Thanks for the bug report,
Dave.

deeelwy closed this Dec 14, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment