Hi, I just opened this bug for a discussion on how we shall deal with the new java 1.7 update in rawhide. Currently, the pdftk uses the gcj-aot bits of itext created by aot-compile-rpm in %install section of the itext specfile. As of current rawhide, aot-compile-rpm cannot deal with the jar files created by the java 1.7. Hence we got http://koji.fedoraproject.org/koji/taskinfo?taskID=3652353 No gcj-aot compiled itext means no pdftk. Now we have a few options: - We can build itext without the gcj bits and drop pdftk. - We can ask FESCo for a bundled library exception and use the itext that comes with pdftk - We can bulid two versions of bouncycastle, bouncycastle-mail, bouncycastle-tsp, itext. Once with openjdk, once with gcj. Put the latter in compat-gcj subpackages. And make pdftk use these instead. This is a lot of work, and I am not sure if this would work anyway. What is your opinion on this?
Hallo Orcan, Solutiion one is inacceptable, because there are use of this package which will complaint, if the package willl been removed from Fedora. I personally prefer solution two. This may give me the chance for inclussion of pdftk to EL-6. The issue with EL-6 is the dependency tree which contains packages for which maven is required to build them. Unfortunately on EL-6 we doesn't have maven as a build system. Best Rebards: Jochen Schmitt
Thanks, I will file a ticket to FESCo for option 2 then. The arguments we can put down are: - gcj and openjdk are incompatible in rawhide - Option 3 may not work, even if it does, this does not help the situation much. itext2 is not maintained upstream anymore, and we cannot update to itext5 due to licence issues (I can provide the link to Fedora Legal response to my query). - Debian sid also uses the bundled version (they used to borrow our patch to link to the system version, but now it seems they just use the bundled version) - gcj itself is (almost) dead/unmaintained for a while Do you think of anything else?
Because FESCo has toldn me, that FPC is resposible for bundled library exceptions I have create Ticket #133 to FPC. Please feel free to add additional information to https://fedorahosted.org/fpc/ticket/133 if require.
Created attachment 555580 [details] Build log for bundled iText library agains Jdk-1.7.0 Unfortunately I have got an issue by my trial to build pdftk with bundled iText libary agains jdk-1.7. The reason for the issues semms to be an API change of the jdk-1.7 libraries. Best Regards: Jochen Schmitt
Hmm, I cannot find the error message in the build log. Could you attach your specfile?
Here is the reference to the reply from Fedora-Legal for the license issues with itext5 http://lists.fedoraproject.org/pipermail/legal/2011-June/001653.html This link also provides more links to previous discussions.
I'm adding Deepak and Andrew to CC as they will likely have some thoughts/hints/suggestions here.
just use -target1.5 ? Does that not work ? or compile with ecj ?
-target 1.5 does not work as is. I still get "unrecognized class file version" for the dependencies during aot-compile-rpm of itext. e.g. Exception in thread "main" java.lang.ClassFormatError: org.bouncycastle.jce.provider.BouncyCastleProvider (unrecognized class file version) I guess all of the itext dependencies need to be downgraded to target 1.5 too. But when I try -target 1.5 on bouncycastle, the build fails via javac: target release 1.5 conflicts with default source release 1.7 If I also pass -source 1.5 to bouncycastle, it builds fine. I will now try this workaround for the other itext dependencies. As for ecj, itext uses ant. I don't know how to modify build.xml to use ecj instead of javac.
Okay, I tried "-source 1.6 -target 1.6" when rebuilding bouncycastle, bouncycastle-mail, bouncycastle-tsp, rebuilt itext, and then pdftk, and now pdftk works. Now the questions are, does it have any drawbacks to set "-source 1.6 -target 1.6" ? How long will these be supported in openjdk in Fedora?
I have no idea how long they will be supported for. In the meantime, I can look at modifying gcj to support the 1.6 class file format. Please create a bug for that.
Thanks. Where exactly do I create a bug for gcj?
http://gcc.gnu.org/bugzilla/
I managed to build itext with the above changes http://koji.fedoraproject.org/koji/taskinfo?taskID=3801230 Now, before proceeding further, I want to ask a question. Lately there is a fuss (e.g. bug #758814, or the new Java packaging guidelines) about including the GCJ AOT bits in the RPM packages. We cannot remove them completely from itext since pdftk needs them. I am planning to separate the itext GCJ AOT bits into a different subpackage, so that subpackages containing the jar files will remain noarch. Does anyone have an objection?
A separate subpckage for itext with the GCJ AOT bits make sense, because es need this stuff only for pdftk.
pdftk-1.44-7.fc17,itext-2.1.7-12.fc17,bouncycastle-tsp-1.46-4.fc17,bouncycastle-mail-1.46-4.fc17,bouncycastle-1.46-4.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/pdftk-1.44-7.fc17,itext-2.1.7-12.fc17,bouncycastle-tsp-1.46-4.fc17,bouncycastle-mail-1.46-4.fc17,bouncycastle-1.46-4.fc17
Package pdftk-1.44-7.fc17, itext-2.1.7-12.fc17, bouncycastle-tsp-1.46-4.fc17, bouncycastle-mail-1.46-4.fc17, bouncycastle-1.46-4.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing pdftk-1.44-7.fc17 itext-2.1.7-12.fc17 bouncycastle-tsp-1.46-4.fc17 bouncycastle-mail-1.46-4.fc17 bouncycastle-1.46-4.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-2035/pdftk-1.44-7.fc17,itext-2.1.7-12.fc17,bouncycastle-tsp-1.46-4.fc17,bouncycastle-mail-1.46-4.fc17,bouncycastle-1.46-4.fc17 then log in and leave karma (feedback).
@oget, I must notify you, that I dislike your dicission of then naming of the new ubpackages. The most users who like to install itext assume, that the itext package contains the plain jave stuff. So I want to make the following suggestion: Renameing itext to intext-aot and itext-core to itext. The m,may caused a change of my pdftk package, but this is ok for me.
Surely we have to have a better reason to change the names of packages than "I dislike" and "most users expect".
Created attachment 564507 [details] Suggestion for renaming of iText subpackages I have trid to rename the subpackages in a better way. The main issue is, that a noarch main package can't contains arch depending subpackages.
Created attachment 564514 [details] Sugges patch to reorganization of the itext subpackages UNfortunately, We don't have a real itext binary package now, so I have set a virtual provides to itext-core. Additional question: Should we do nay action to remove the debuginfo subpackage?
Believe me, I gave some thought into this before making the changes. As you figured out, the main package cannot be noarch, since noarch packages cannot have arch-specific subpackages. Any other solution, like the one you propose, will add unnecessary complexity to the situation. After all, itext is a library. Currently the only users of itext in Fedora are the pdftk, tuxguitar and libfonts packages. pdftk needs no changes. I maintain tuxguitar and I already rebuilt it against itext-core. The itext dependency of libfonts is dropped in rawhide/F-17 recently, but I notified its maintainers anyhow, in case they want to re-enable the itext dependency. About the debuginfo package, is there a reason to drop it? It still has some debugging symbols that gdb can process.
pdftk-1.44-7.fc17, itext-2.1.7-12.fc17, bouncycastle-tsp-1.46-4.fc17, bouncycastle-mail-1.46-4.fc17, bouncycastle-1.46-4.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.