rpm -t* <compressed file> don't work

Description of problem:
The -t option of rpmbuild (e.g. rpmbuild -ta mytarball.tar.bz2) doesn't work
anymore since the latest tar upgrade to FC5. The cause is an incompatible
change in tar's handling of wildcards passed on the command line. See:
http://lists.gnu.org/archive/html/bug-tar/2006-06/msg00001.html
You now have to pass the --wildcards parameter when looking for '*.spec'.

Version-Release number of selected component (if applicable):
rpm-build-4.4.2-15.2
tar-1.15.91-1.FC5

How reproducible:
Always.

Steps to Reproduce:
1. Create a tarball with a specfile in it.
2. rpmbuild -ta mytarball.tar.bz2

Actual results:
Spurious errors due to the specfile not being found, i.e.:
error: Name field must be present in package: (main package)
error: Version field must be present in package: (main package)
error: Release field must be present in package: (main package)
error: Summary field must be present in package: (main package)
error: Group field must be present in package: (main package)
error: License field must be present in package: (main package)

Expected results:
The package builds.

Additional info:
Workaround:
TAR_OPTIONS=--wildcards rpmbuild -ta mytarball.tar.bz2

Adding tar maintainer to CC.

*** Bug 207239 has been marked as a duplicate of this bug. ***

Me too on Rawhide: I end up with an empty file in rpmbuild/SPECS called:
"tar: Pattern matching characters used in file names. Please," which it tries to
interpret as the specfile, leading to the failure messages above.

Appears to prevent all of the -t options of rpmbuild from working in Rawhide
(ouch); this feels like a blocker to me.

I've written a reproducer for this here:
https://testing.108.redhat.com/source/browse/*checkout*/testing/trunk/rhts/tests/sandbox/rpm/rpm-build/run-rpmbuild-on-tarball.sh?content-type=text%2Fplain&rev=70

fails on one machine with:
tar-1.15.91-1
rpm-build-4.4.2-32

passes on another machine with:
tar-1.15.90-2
rpm-build-4.4.2-31

Other -t variants such as -tb are broken as well

*** Bug 207831 has been marked as a duplicate of this bug. ***

*** Bug 207825 has been marked as a duplicate of this bug. ***

*** Bug 208008 has been marked as a duplicate of this bug. ***

Created attachment 137388
rpmbuild patch

Hello,

I have a similar problem and after a lot of pain I created a patch and it worked
for me. I hope it helps fix this problem as well.

Check out this link which describes the problem I encountered, and attached its
the patch I created for the rpmbuild package.

https://www.redhat.com/archives/fedora-devel-list/2006-September/msg00873.html

Regards,
Marcio Oliveira

A new tar RPM was released (1.15.1-14) which fixed the problem on my
workstation. Does it work for you too?

*** Bug 208358 has been marked as a duplicate of this bug. ***

Tar was reverted to fix Bug 207115, and as a side effect this also fixes this
bug. However, it will break again when tar is upgraded again, e.g. to 1.16.0
when it will be out. But using the patch now won't work either because tar
1.15.1 won't eat the --wildcards option. So we're stuck.

Correcting myself: Actually, tar 1.15.1 does eat --wildcards, so it should be
possible to add the switch now and avoid breakage later. In tar 1.15.1, the
switch only applies to exclude patterns (and is on by default), the newer
version also makes it apply to listed files.

I can confirm that building packages with rpmbuild -ta foo.tar.gz does indeed
work on FC5.

Thanks.

(In reply to comment #12)
> A new tar RPM was released (1.15.1-14) which fixed the problem on my
> workstation. Does it work for you too?

Updated FC5 with 1.15.1-14 - works for me...

It is still broken in FC5:
tar-1.15.1-16.FC5
rpm-build-4.4.2-15.2

TAR_OPTIONS=--wildcards rpmbuild -ta xx.yy.tar.gz
does not work either (for this tar)

The script from comment #5:

Dummy package
/tmp/tmp.VqvFI31823/rpmbuild/RPMS/noarch/foobarbaz-1.0-1.noarch.rpm
Success - RPM appears to have been built successfully

$ rpm -q tar rpm-build
tar-1.15.1-14.FC5
rpm-build-4.4.2-15.2

It should be alright in all tar-1.15.1-* releases.

*** Bug 216642 has been marked as a duplicate of this bug. ***

opened because of planed tar upgrade

All the way down to FC5? FC6? Or only >=F7?

I'd hope devel/fc7. Lukas can you update the Version appropriately.

Lukas - what versions of fedora is this required for?

oh im sorry it's planned for FC7

Hi all.

I am packaging version 1.17 for FC8. After reading these comments I figured it
would be best to preserve behavior of version 1.15.1. I already have patch for that.

Wildcards will be used by default and --no-wildcards option will be also
supported to switch them off.

But I think it would be best if rpmbuild and other tools will also be patched.
They should call tar with --wildcards option if they use this feature. It does
not break anything and it works even with tar 1.15.1.

Now (and anytime in future), these tools are unable to work with raw upstream
tar. That isn't very good, imho... It's unlikely that upstream will ever restore
old behavior.

rpm 4.4.2.1 will pass --wildcards to tar on build, once it's in rawhide feel
free to drop the wildcards-by-default patch from tar (at least from rpm POV,
dunno if other tools care)

Rawhide (and F8-test1) has 4.4.2.1 now and uses --wildcards so from rpm POV the
tar patch can be dropped.

Okay, thanks. I'll probably keep the patch in for a while...

Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Unable to reproduce any more in F8+updates.