GNOME Bugzilla – Bug 592485
Duplicate %prep, no %revision, issues new since 1.5.9-SVN/20090814, with patch
Last modified: 2009-08-26 13:23:23 UTC
Created attachment 141269 [details] "make rpm" works again on rpm-4.4.2/CentOS-5.3 system During a "make rpm" on a recently updated (revision 705) doxygen-1.6.0-SVN on Linux (CentOS-5.3 == linux-2.6.18/gcc-4.1.2/glibc-2.5), the specfile and the base Makefile.in no longer agree. Attached patch resolves for me. Here's what I found: First, the spec file was being tarred up, then added: doxygen-1.6.0/packages/rpm/ doxygen-1.6.0/packages/rpm/doxygen.spec << already here doxygen-1.6.0/packages/rpm/doxygen.spec.in doxygen-1.6.0/Makefile.in [... now add another ...] tar -rvf doxygen-`echo 1.6.0 | tr - _`.src.tar doxygen-`echo 1.6.0 | tr - _`/packages/rpm/doxygen.spec doxygen-1.6.0/packages/rpm/doxygen.spec << there's the second The result is that two 104-line specfiles are in the archive, and the rpm-4.4.2 on this platform is combining both to a 208-line spec file with, of course, two of every section. The compile fails at duplicate %prep: The second issue with this spec file is that the %revision is no longer added to the "make dist" filename: [...] doxygen-1.6.0/packages/rpm/doxygen.spec.in doxygen-1.6.0/Makefile.in rm -rf doxygen-`echo 1.6.0 | tr - _` gzip -df doxygen-`echo 1.6.0 | tr - _`.src.tar.gz [...] rm -rf doxygen-`echo 1.6.0 | tr - _` gzip -9v doxygen-`echo 1.6.0 | tr - _`.src.tar doxygen-1.6.0.src.tar: 74.8% -- replaced with doxygen-1.6.0.src.tar.gz rpmbuild -ta doxygen-`echo 1.6.0 | tr - _`.src.tar.gz error: File /home/allanc/src/doxygen-svn/doxygen-1.6.0_1.src.tar.gz: No such file or directory make: *** [rpm] Error 1 This is resolved with a simple little patch, attached.
Thanks, I'll include your patch in the next subversion update.
This bug was previously marked ASSIGNED, which means it should be fixed in doxygen version 1.6.1. Please verify if this is indeed the case and reopen the bug if you think it is not fixed (include any additional information that you think can be relevant).
confirmed, resolved in my testing. Thanks!