I just tried using jhalfs with a current CLFS system (using a few things
from LFS) as a host, and it failed attempting to download packages.
Specifically, basename complained about an extra parameter, which
happened to be the package's md5sum. After a bit of debugging, I found
that the problem comes from this command that jhalfs tries to run:
echo http://download.savannah.gnu.org/releases/acl/acl-2.2.52.src.tar.gz
ftp://ftp.lfs-matrix.net/pub/clfs/conglomeration/acl/acl-2.2.52.src.tar.gz
a61415312426e9c2212bd7dc7929abda | cut -d" " -f2
This should result in the the 2nd URL listed, but instead it gives this
output:
http://download.savannah.gnu.org/releases/acl/acl-2.2.52.src.ta
ftp://ftp.lfs-matrix.net/pub/clfs/conglomeration/acl/acl-2.2.52
a61415312426e9c2212bd7dc7929abda
The problem is that the "cut" program isn't giving the expected output.
After some further experimentation, and checking with William Harrington
in IRC who got the same results, this problem only occurs when using
Coreutils 8.25 with the i18n patch that's in LFS. When using 8.24, or
8.25 without the patch, I get the expected result and jhalfs runs fine.
After some further testing, cut appears to screw up whenever the first
field is >=64 characters. The patch defines MIN_CHUNK in cut.c with a
value of 64, and when I increased that to 128 I could use cut
successfully with the first field up to 128 characters. I don't think
MIN_CHUNK is supposed to be an *upper* limit for field length, but
apparently that it is being used as.
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
