Description of problem: For rpmbuild --rebuild pdftk-1.12-0.src.rpm the packages libgcj-devel and gcc-java are needed. It is not possible to install the compiler component and libary. Version-Release number of selected component (if applicable): gcc-java-4.1.2-33.i386 libgcj-devel-4.1.2-33.i386 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 317325 [details] Logfile for bug
I checked further that the package libjasper is also not available in the fedora repository. It provides some codec (http://www.ece.uvic.ca/~mdadams/jasper/) for pdftoolkit (http://www.accesspdf.com/article.php/20041129180128366).
I've installed libgcj-devel package without an error. The "java-plugin" gcc-java for the C-compiler causes the error. Further I've installed packages jasper-1.900.1-7.fc8.i386 jasper-libs-1.900.1-7.fc8.i386 Perhaps there are other dependencies for fc8 to build pdftk?
Why is this BZ against yum?
This BZ was primary against gcc.
Created attachment 317865 [details] Logfile for rpmbuild
That's really strange. I'm able to install the gcc-java package now. However, the rpmbuild -rebuild pdftk*.src.rpm gives an error. I've no gpgkey for source code package. Is this still a bug?
Since the dependencies regarding gcc-java seem to be resolved by an eclipse package or something like that, I've change the issue to rpmrebuild. Maybe Fedora and RedHat are not completely compatible.
FYI, I am pretty sure this isn't related to rpmrebuild, which is a different tool than rpmbuild --rebuild AS
This is not a bug in rpmrebuild, rpmbuild, yum or gcc either. Looking at the log from comment #6: + cd /usr/src/redhat/BUILD + cd pdftk-1.12 + '%{suse_update_config' '-fl}' /var/tmp/rpm-tmp.26219: line 23: fg: no job control error: Bad exit status from /var/tmp/rpm-tmp.26219 (%build) You can't take a package from one distribution (Suse in this case) and expect it to build just like that on something else (Fedora in this case). In ideal world this would work but as it is, every vendor uses their own set of macros to help building packages. Those macros are usually vital part of the build process and if they're missing things are likely to kaboom sooner or later, most likely sooner. Which is exactly what the problem here seems to be.