Hide Forgot
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 [details] 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.