Well, I don't know if I need bother, similar issues have been reported, like: https://code.google.com/p/libarchive/issues/detail?id=299
The consensus seems to be "report broken tarballs upstream," so that's what I should do, methinks.
Search Criteria
Package Details: dparser 1.30-1
Package Actions
| Package Base: | dparser |
|---|---|
| Description: | A scannerless GLR parser generator based on the Tomita algorithm |
| Upstream URL: | http://dparser.sourceforge.net/ |
| Category: | devel |
| Licenses: | |
| Submitter: | ackalker |
| Maintainer: | None |
| Last Packager: | None |
| Votes: | 0 |
| First Submitted: | 2013-03-19 02:03 |
| Last Updated: | 2013-06-11 16:47 |
Required by (0)
Sources
Latest Comments
Comment by ackalker
Comment by ackalker
More precisely: the tarball contains two versions of my.c and of my.g each, and one pair is nothing less than a pair of self referring symlinks! 8-) Perhaps I should report a bug on bsdtar.
Comment by ackalker
@gtmanfred
Try it, if you dont believe me (comment those lines) :-) The reason I use noextract is that bsdtar barfs on this tarball: it contains duplicate files, and was probably generated incrementally.
Here's a spoiler:
-> Extracting d-1.29-src.tar.gz with bsdtar
d/my.c: Can't create 'd/my.c'
d/my.g: Can't create 'd/my.g'
bsdtar: Error exit delayed from previous errors.
Comment by gtmanfred
there is no reason to extract the tarball in the build function, makepkg already does that