Bug 159100 - lha-114i-r6 cannot unpack quake1-demodata
|
Bug#:
159100
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: usata@gentoo.org
|
Reported By: jkt@gentoo.org
|
|
Component: Games
|
|
|
URL:
|
|
Summary: lha-114i-r6 cannot unpack quake1-demodata
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2006-12-25 15:23 0000
|
velbloud ~ # emerge -av quake1-demodata
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] games-fps/quake1-demodata-1.06 USE="-symlink" 0 kB
Total size of downloads: 0 kB
Would you like to merge these packages? [Yes/No]
>>> Emerging (1 of 1) games-fps/quake1-demodata-1.06 to /
* quake106.zip MD5 ;-) ...
[ ok ]
* quake106.zip RMD160 ;-) ...
[ ok ]
* quake106.zip SHA1 ;-) ...
[ ok ]
* quake106.zip SHA256 ;-) ...
[ ok ]
* quake106.zip size ;-) ...
[ ok ]
* checking ebuild checksums ;-) ...
[ ok ]
* checking auxfile checksums ;-) ...
[ ok ]
* checking miscfile checksums ;-) ...
[ ok ]
* checking quake106.zip ;-) ...
[ ok ]
>>> Unpacking source...
>>> Unpacking quake106.zip to /var/tmp/portage/quake1-demodata-1.06/work
LHa: Error: Checksum error (LHarc file?)
!!! ERROR: games-fps/quake1-demodata-1.06 failed.
Call stack:
ebuild.sh, line 1546: Called dyn_unpack
ebuild.sh, line 708: Called src_unpack
quake1-demodata-1.06.ebuild, line 45: Called die
!!! lha failed
!!! If you need support, post the topmost build error, and the call stack if
relevant.
velbloud ~ # emerge -pv lha
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] app-arch/lha-114i-r6 0 kB
Total size of downloads: 0 kB
Thanks for the link, I built a lha binary from ubuntu's source+diff, and indeed
emerge quake1-demodata worked fine
*** Bug 168674 has been marked as a duplicate of this bug. ***
*** Bug 184774 has been marked as a duplicate of this bug. ***
Well, there's good news and bad news. lha-114i-r5 *can* unpack that file.
It's no longer in the Portage tree, but, perhaps it should be reinstated (and
lha-114i-r6 masked) until the issues are sorted out.
lha-114i-r6 is based on a different upstream tarball that's pretty
significantly different. lha-114i-r5 did not use autotools and had a pretty
significant list of patches. lha-114i-r6 uses autotools, incorporates all of
the patches, uses getopt to parse the command line, and really includes a lot
of cleanup which generally looks good. Too bad it doesn't work.
Just as an aside, the brand new lha-114i-r7 that I just got put into the tree
with the help of the Sunrise folks *does not* address this issue. It *does*
however address *another* issue introduced with -r6. See bug #184911.
- John
Incidentally, lha-114i-r5 uses the same upstream tarball that Debian is using
right now, which explains why the Debian version is working.
- John
Okay, now I am in a quandary. lha-114i-r5 worked because it was broken.
lha-114i-r6 doesn't work because it's not broken. Read on.
lha contains a function called archive_is_msdos_sfx1() that determines whether
or not the archive file is an MS-DOS self-extracting executable archive. It
does so in a very simplistic way, by comparing the last few bytes of the file
name against a list of known executable file types (under DOS!).
In lha-114i-r5, this function was broken and almost always returned "true" but
the code to skip the embedded DOS self extraction code was smart enough to not
skip a non-existent executable blob.
In lha-114i-r6, the archive_is_msdos_sfx1() function was fixed and the skip
code was simplified. The end result is that the code will no longer correctly
process self extracting archives whose file name doesn't end in ".com", ".exe",
or ".x".
So the quandary is that lha-114i-r6 is behaving as designed and the file that
quake1-demodata cannot extract has been erroneously renamed from something.exe
to resource.1. Technically, the issue is with the quake1-demodata ebuild.
But, I'm unhappy with the archive_is_msdos_sfx1() function. It's really easy
to look into the contents of a file to tell if it's an MS-DOS executable. I'm
working on a change to the archive_is_msdos_sfx1() function so that it depends
on the contents as opposed to the name.
Advice? Opinions?
- John
*** Bug 166583 has been marked as a duplicate of this bug. ***
OK. This is FIXED now using the patch from Paul.
