Hiya, I was just writing up a quick ebuild for a new version of scapy. It's now packaged in a zip file, and I changed the SRC_URI and DEPEND strings accordingly. When I tried it out, I got the following lines: warning [/var/tmp/portage/net-analyzer/scapy-2.0.0.5/distdir/scapy-2.0.0.5.zip]: 60 extra bytes at beginning or within zipfile (attempting to process anyway) * * ERROR: net-analyzer/scapy-2.0.0.5 failed. * Call stack: * ebuild.sh, line 49: Called src_unpack * environment, line 2342: Called unpack 'scapy-2.0.0.5.zip' * ebuild.sh, line 356: Called die * The specific snippet of code: * unzip -qo "${srcdir}${x}" || die "$myfail" I checked in /var/tmp/portage/blah/blah/blah/scapy/work/ and it unpacked successfully. I then took a quick check over the man page for unzip, which has the following: The exit status (or error level) approximates the exit codes defined by PKWARE and takes on the following values, except under VMS: 0 normal; no errors or warnings detected. 1 one or more warning errors were encountered, but processing completed successfully anyway. This includes zipfiles where one or more files was skipped due to unsupported compression method or encryption with an unknown password. 2 a generic error in the zipfile format was detected. Processing may have completed successfully anyway; some broken zipfiles created by other archivers have simple work-arounds. There are more, but they're mostly immediate type errors. I would suggest supporting both error codes 0 and 1 as valid, but the description for error code 1 suggests that not all files may be extracted. This won't be the case with passwords (since the built-in unpack doesn't support them), so that only leaves possibly unknown compression methods, which seems a remote possibility. Here are the options for a solution as I see it: 1. Contact upstream about the issue, and treat this as a one-off. 2. Repackage the zip files so they don't have any errors. 3. Accept 0 & 1 error codes and assume the bad cases happen too infrequently to be a problem. 4. Do some weird grep type solution to help determine noncritical warnings. 5. Look for another unzip package. 3 would be my prefered candidate followed up by 1 (not a solution to the underlying problem, but a solution non-the-less) then followed by 2. Any thoughts?
Ok, rather oddly, I found out what's up with the zipfiles. Apparently he prepends: #! /bin/sh PYTHONPATH=$0/scapy-2.0.0.4 exec python -m scapy to the start of them. It seems to be a hidden feature of python, and allows you to run the zip file directly. Most zip programs decode it correctly, and for those that want, you can run the package directly. Unfortunately, that means the author's intentionally added this as a feature and so is unlikely to want to remove it. I'm wondering if I should write a little script to remove the bytes before the PK header and then unpack the results?
Since the unzip program can return an exit code of 1 even when it skips some files, it's not likely that portage will ever accept that exit code as "success". You can either fix the distfiles yourself and upload a new copy to the mirrors or add a bit to src_unpack that strips the bits off the downloaded zip file. Unfortunately, the second choice would modify the downloaded file in the distfiles dir, which would cause it to fail validation on a subsequent emerge. The other option might be to use the 'zip' utility instead of the 'unzip' utility to handle ZIP files in portage. It doesn't appear to use the exit code of 1. However, the man page for it says that an exit code of 0 is for "no errors or warnings detected".
For an immediate solution, I'd suggest overriding src_unpack and calling zip or unzip directly instead of via unpack(). The problem with changing unpack() to call some tool other than unzip is that ebuilds are supposed to have DEPEND="app-arch/unzip" if they have a zip file in SRC_URI. Changing would effectively be an EAPI change.
Ok, I got around this with a little dd-ing and a DEPEND on coreutils. I'm happy to mark this as LATER, if everyone else is...
Are you copying the distfile to a temporary location being running dd on it, or are you doing the dd and piping into unzip?
I'm dd with if=${DISTDIR}/blah-broken.zip and of=${WORKDIR}/blah.zip, and then running unpack on that (with a relative path, because absolutes don't seem to work...). It seemed a reasonable solution, and won't break the manifests or anything...
