Bug 1230762

Thanks for the report.

(In reply to Jean-Louis Martineau from comment #0)
> Steps to Reproduce:
> 1. mkdir tt
> 2. cd tt
> 3. mkdir foo
> 4. touch bar

s|touch bar|touch foo/bar|

> 5. tar cvf ../foo.tar .
> 6. tar tf ../foo.tar  ./foo
> ./foo/
> ./foo/bar   # both files are listed when on command line argument
> 7. echo ./foo > ../list
> 8. tar tf ../foo.tar --files-from ../list
> ./foo/      # only ./foo is listed whenusing --files-from
> 
> Actual results:
> The contents of a directory is not listed/extracted

> Additional info:
> tar-1.28 works:
>   tar-1.28/src/tar tf ../foo.tar --files-from ../list
> ./foo/
> ./foo/bar

Hmm, this does not seem to be truth.  I have just tried freshly built
tar 1.28 and it does not work for me in this case.  Jean-Louis, can you
please check again?

IMHO, git tar is OK because of this (post v1.28) commit:
http://git.savannah.gnu.org/cgit/tar.git/commit/?id=163e96a0e619a900eab6de

Ok, I see you are original upstream reporter, clearing needinfo
http://www.mail-archive.com/bug-tar@gnu.org/msg04623.html

There has been reported issue with the proposed patch by guys from Suse,
which in turn forced them to revert the backported patch
http://www.mail-archive.com/bug-tar@gnu.org/msg04750.html

I need to do better analysis before I'll think about backporting.

(In reply to Pavel Raiskup from comment #2)
> Ok, I see you are original upstream reporter, clearing needinfo
> http://www.mail-archive.com/bug-tar@gnu.org/msg04623.html

By this ^^ I meant that you are definitely aware that upstream fixed this
issue post v1.28 release.

> There has been reported issue with the proposed patch by guys from Suse,
> which in turn forced them to revert the backported patch
> http://www.mail-archive.com/bug-tar@gnu.org/msg04750.html
>
> I need to do better analysis before I'll think about backporting.

FYI, I commented directly in the upstream thread.  To me, there does not seem
to be serious issue.  It rather looks OpenSuse guys misinterpreted the
expected change as regression.

I am in favour of back-porting the fix into F21+ as there is no obvious
work-around amanda could use now.

tar-1.28-6.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/tar-1.28-6.fc22

tar-1.27.1-8.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/tar-1.27.1-8.fc21

Package tar-1.27.1-8.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing tar-1.27.1-8.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-10829/tar-1.27.1-8.fc21
then log in and leave karma (feedback).

tar-1.28-6.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

tar-1.28-6.fc22 seems to break the command "dpkg-deb". dpkg-deb now includes the "DEBIAN" directory (containing the maintenance scripts of the package) into the data-archive. Because of this, when installing the package, the DEBIAN-directory gets copied to the root of the file system. 

This currently breaks our build process.

dpkg-build calls tar with the following parameters (copied from build.c):

execlp(TAR, "tar", "-cf", "-", "--format=gnu", "--null", "--no-unquote",
                       "-T", "-", "--no-recursion", NULL);

Maybe -T does not work correctly when used together with "--no-recursion"?

Christian, ideally - dpkg-build should call tar binary with specified
--no-recursion before '-T -'.  This is semantics which was backported in
this bug -- and its the expected behavior of tar.  Any new release of GNU
tar will behave like that -- so sooner dpkg-build will be fixed, the better.

(In reply to Pavel Raiskup from comment #10)
> Christian, ideally - dpkg-build should call tar binary with specified
> --no-recursion before '-T -'.  This is semantics which was backported in
> this bug -- and its the expected behavior of tar.  Any new release of GNU
> tar will behave like that -- so sooner dpkg-build will be fixed, the better.

and on epel6 and epel7 ? dpkg-build should we do the same ?

(In reply to Sergio Monteiro Basto from comment #11)
> and on epel6 and epel7 ? dpkg-build should we do the same ?

As tar is not fixed in RHEL{6,7}, there is no need to backpatch dpkg in epel.
On the other hand, it may be fixed (via future rebase? because this needs
to be fixed upstream also).

(In reply to Pavel Raiskup from comment #12)
> On the other hand, it may be fixed (via future rebase? because this needs
> to be fixed upstream also).

Yes, I will contact upstream to include this patch in future releases, if isn't already done. I will check that .

tar-1.27.1-8.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Hi,
(In reply to Sergio Monteiro Basto from comment #13)
> (In reply to Pavel Raiskup from comment #12)
> > On the other hand, it may be fixed (via future rebase? because this needs
> > to be fixed upstream also).
> 
> Yes, I will contact upstream to include this patch in future releases, if
> isn't already done. I will check that .

I wrote to debian-dpkg Mailing List (debian-dpkg.org) [1] and 
Guillem Jover wrote: 
"Right, this was reported to me some time ago by Richard Purdie,
and got already fixed in 1.18.2, for both the dpkg-deb issue and
a potential similar issue I noticed in the perl modules:

<http://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=fcfe4f3aa2f3cb7f8179d4f2fe6dd65e75f7bbdf>
<http://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=02e2060504f1c8dbbe5dec8211beaf945350c789>

My plan was to keep it in 1.18.x for a bit, to get it tested, and then
backport it to the 1.16.x and 1.17.x branches." 

So patch is already upstreamed !  

Thanks, 

[1] http://www.eenyhelp.com/answer/patch-tar-exec-use-no-recursion-before-t-option-help-215780194.html#r