Some tar archives has paths like these in them: ..././... when trying to unpack these archives with tar 1.13.92 it gives the following warning: tar: Removing leading ... Confirmed tarballs that suffers from this are: libpcap-0.8.1, tcpdump-3.8.1 and iptables-1.2.9
The tar problem manifests itself like this: >>> md5 src_uri ;-) tcpdump-3.8.1.tar.gz >>> Unpacking source... >>> Unpacking tcpdump-3.8.1.tar.gz to /var/tmp/portage/tcpdump-3.8.1/work tar: Removing leading `tcpdump-3.8.1/./' from member names >>> Source unpacked. !!! ERROR: net-analyzer/tcpdump-3.8.1 failed. !!! Function econf, Line 341, Exitcode 1 !!! no configure script found And those weird paths are actually in the mentioned tar's: tcpdump-3.8.1/./ tcpdump-3.8.1/./lbl/ tcpdump-3.8.1/./lbl/os-osf4.h (truncated)
The result is that tar strips out the subdir in the tarball unpacking it directly to $PORTAGE_TMDIR/work and not $PORTAGE_TMPDIR/work/libpcap-0.8.1
A fragment from tar-1.13.92/ChangeLog One entry seems relevant, marked with <!> 003-11-14 Sergey Poznyakoff <gray@Mirddin.farlep.net> * src/tar.h (archive_format): USTAR_FORMAT: New type. * src/create.c: Added POSIX.1-1988 support. <!>* src/names.c (safer_name_suffix): Skip leading ./ * src/tar.c: New option --format=ustar forces POSIX.1-1988 archive format. * tests/delete03.sh: Updated. * tests/extrac04.sh: Updated. * tests/multiv01.sh: Updated.
Looks as if the "P" option to tar (--absolute-names) disables the check. Playing around with this.
Created attachment 23085 [details, diff] ebuild.sh.diff This adds --absolute-names to the unpack command in ebuild.sh and allows me to install libpcap. Please perform a sanity check on this and treat it with care until I've tested more thoroughly.
i dont really think the way to go is patching ebuild.sh it's obvious it's a bug in tar, fix tar and we dont have to screw around with releasing another portage
Tested with: libpcap-0.8.1, tcpdump-3.8.1 and iptables-1.2.9 These weren't willing to install earlier and work now. Tested with: kdegames-3.2.0_beta2, tar-1.13.92 and portage-2.0.49-r20 These worked before, and still work now.
I'm not a C coder though. Could mask the tar version, file a bug upstream or have someone else hack on names.c, I guess. Anyway, should anyone be willing to take this route, it will work.
Created attachment 23092 [details, diff] 1.13.92-disable-dotslash-check.diff This hardcodes the (apparently buggy) check to disabled in the tar sources. Basically, this is the same solution as provided earlier, but then in a way that doesn't require a portage upgrade (which would be tedious indeed, SpanKY, agreed).
Created attachment 23093 [details, diff] tar-1.13.92.ebuild.diff And ofcourse the diff to the tar ebuild to apply this diff. How's this? (Tested again, same 6 packages)
absolute_names_option is referenced in both src/extract.c and src/names.c, so perhaps the better way of doing it is to patch src/tar.c around line 1246 with absolute_names_option = true;
Created attachment 23099 [details, diff] 1.13.92-hardcode-absolute-names-to-on.diff Redoing things the hardcoded way, in tar.c, as asked.
Created attachment 23100 [details, diff] tar-1.13.92.ebuild.diff And the ebuild change to have the patch applied. Bugfixes to order, anyone else that would like a change? :)
*** Bug 37157 has been marked as a duplicate of this bug. ***
*** Bug 37170 has been marked as a duplicate of this bug. ***
*** Bug 36810 has been marked as a duplicate of this bug. ***
*** Bug 37103 has been marked as a duplicate of this bug. ***
*** Bug 37176 has been marked as a duplicate of this bug. ***
*** Bug 37190 has been marked as a duplicate of this bug. ***
*** Bug 37195 has been marked as a duplicate of this bug. ***
thanks for the patch, Tony, added to portage and reporting this issue upstream
*** Bug 37202 has been marked as a duplicate of this bug. ***
*** Bug 37203 has been marked as a duplicate of this bug. ***
*** Bug 37287 has been marked as a duplicate of this bug. ***
For the slow people among us (who need everything spelled out), the fix is to: a) emerge tar, and then b) emerge libpcap. tar version app-arch/tar-1.13.92-r1 seems to address the problem mentioned here.
I do not think this is the proper fix ..
Created attachment 23245 [details, diff] tar-1.13.92-fix-pathstrip.patch The problem is the strip code also strip './', and not just '../'. I do not see why the code also strip './', as it refers to the current dir (or the proper file if you append the path given to -C arg), and as we all know, RH etc starts to ship tarballs that have pathnames start with './' for security reasons - same reason why unzip add './' to all paths. Anyhow, attached is patch that fixes the code not to stip './'. Comments?
On another matter - if you look at the following code: -- if (p[0] == '.') { if (p[1] == '.' && (ISSLASH (p[2]) || !p[2])) prefix_len = p + 2 - file_name; else if (ISSLASH (p[1])) prefix_len = p + 1 - file_name; } -- from src/names.c ('safer_name_suffix' function), is it safe? I see no test to see if the lenght of the input filename is >= 3 chars, but still the code checks p[0], p[1] and p[2] without checking if its valid (sure, there is the '!p[2]' check, but that follows 'ISSLASH (p[2])'). My C is a bit rustic, so I might see something where there is none ...
if the string is 0 terminated should not be a problem: if p[1] == 0 it exits and won't check the other conditions. Maybe I forgot something, from a quick look at the rest of the code it should not cause any harm.
If p[2] is out of bounds, the 'ISSLASH (p[2])' will touch it. The p==0 test is only after, and this is not part of that while loop ...
Ok, here is the proper fix: http://savannah.gnu.org/cgi-bin/viewcvs/tar/tar/src/names.c.diff?r1=1.36&r2=1.37&diff_format=u I missed a change it seems :) I'll commit tonight if somebody do not get there before me.
I suffered from the exact same problem. After upgrading app-arch/tar-1.13.92 to 1.13.92-r1, I was able to successfully upgrade libpcap and iptables.
*** Bug 37352 has been marked as a duplicate of this bug. ***
Comment on attachment 23099 [details, diff] 1.13.92-hardcode-absolute-names-to-on.diff This workaround is no longer necessary now that the true cause is found. Obsoleting.
*** Bug 37610 has been marked as a duplicate of this bug. ***
http://bugs.gentoo.org/show_bug.cgi?id=37728 Seems to be a duplicate of this one too, openoffice and openoffice-ximian both break with the current unstable app-arch/tar-1.13.92-r1
Added -r2 with new patch - can we verify that it still works?
Ok, seems this also fixes the openoffice issues with -r1 (bug #37610).
*** Bug 38739 has been marked as a duplicate of this bug. ***
