Bug 471811 - RfE: Need CNI sub package to resurrect pdftk
Summary: RfE: Need CNI sub package to resurrect pdftk
Alias: None
Product: Fedora
Classification: Fedora
Component: itext
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Orcan Ogetbil
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-11-16 20:35 UTC by Jochen Schmitt
Modified: 2009-03-16 21:32 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-03-16 21:32:18 UTC
Type: ---

Attachments (Terms of Use)
link to internal itext library (15.35 KB, patch)
2009-02-12 19:58 UTC, Orcan Ogetbil
no flags Details | Diff

Description Jochen Schmitt 2008-11-16 20:35:03 UTC
During a licensing issue with the iText release which was bundled on pdftk, this package was remove from the Fedora collection. Because this issue was fixed in the most recent release of iText, I want to resurect this package.

Unfortnately, I need a JNI subpackage which allow me to use the system iText package instead of the iText package bundled in pdftk which we can't use for Fedora.

Comment 1 Orcan Ogetbil 2008-11-17 04:35:08 UTC
I've been making queries about the pdftk as well. I asked FE-Legal about the issue. pdftk contains three types of itext files:

1- Free itext code: We are fine with these ones.
2- Code that was not free, but is free now in the latest version of itext: People of FE-Legal told me that we can use these files in pdftk if we can prove that they are freed, which is doable.
3- Old itext code that is still non-free: pdftk refers to some postscript processing libraries which contain proprietary code. This code has been removed from the current itext version. So if we are to build pdftk these references have to be patched out.

Now you are saying that we should link pdftk to a shared itext library, rather than linking it statically. We can do it this way too but I'm not very familiar with "creating a JNI subpackage". Are there any examples or guidelines that I can follow? Can't we achieve what we want with GCJ-AOT-bits?

Meanwhile I emailed the pdftk author last week and asked him if he will update pdftk to use the recent itext. But he doesn't seem much interested since he didn't reply.

Comment 2 Jochen Schmitt 2008-11-17 17:11:49 UTC
I would to suggest, that you may ask to the fedora-devel-java list for assitance.

Comment 3 Andrew Overholt 2008-11-18 16:50:00 UTC
What do you mean by "a JNI subpackage"?  If iText uses JNI there's no point putting it in a sub-package 'cause it'll be useless without the main package.

Comment 4 Jochen Schmitt 2008-11-18 19:39:30 UTC
I want to access on i in the pdftk package.

The origianl pdftk package contains a iText distributation which is prepared for it, but I don't want't use it, because there is a license issue with it.

pdftk itself will be build with gcj.

Comment 5 Andrew Overholt 2008-11-18 19:43:18 UTC

(In reply to comment #4)
> I want to access on i in the pdftk package.

I'm not sure what you mean.

> The origianl pdftk package contains a iText distributation which is prepared
> for it, but I don't want't use it, because there is a license issue with it.

Can you explain more about the iText "distribution" included with pdftk?  Is it a JAR?

> pdftk itself will be build with gcj.

Okay, that's independent of JNI, though.

Comment 6 Mark Wielaard 2008-11-19 08:23:18 UTC
pdftk is a c++ program that uses CNI.

Comment 7 Andrew Overholt 2008-11-19 14:25:07 UTC
I've modified the summary to reflect what is actually requested.

Though I'm not sure what is the best way to proceed here.  I suspect iText is noarch, meaning we'll need to have an arch-specific sub-package of a noarch main package.  I heard this was possible with the latest rpm but I'm not 100% on that.

Just for own sake, please clarify if this is what needs to happen:

- iText's .spec should have a sub-package -cni (or something)
- as part of iText's %build, the .java files would be compiled directly to a .so using gcj (using the C++ ABI)
- pdftk would BR: itext-cni and build against/link to the .so included in itext-cni

Alternatively, we could include a copy of iText's source in the pdftk SRPM and build the .so directly there.


Comment 8 Orcan Ogetbil 2008-11-20 05:56:12 UTC
This is a long task. Really...
I believe that what needs to be done is to build -cni subpackages not only for itext but all of itext's dependencies, which have changed significantly since the release that's included in pdftk.

I don't have time and energy to do all this. Plus, to do this, I need to learn all this cni business which I doubt I will ever use again. Plus plus, the pdftk author doesn't care, so why should I?

If there's anyone who wants to do it, go ahead, file co-maintainership requests on itext and all its dependencies. I don't mind having comaintainers.

But in my opinion, an easier solution would be to do what pdftk used to do. Link to itext statically, but this time using the license-trouble-free itext code.

Comment 9 Orcan Ogetbil 2009-01-25 02:37:32 UTC
Well, nobody stepped up to patch neither itext nor pdftk to make pdftk link to our itext dynamically. This task is rather involved as it will require JNI knowledge and possibly some java fixes within pdftk which might be incompatible with the current version of itext and bouncycastle we have. I am no java programmer.

But I got several user requests at fedoraforum to package pdftk. We can do this at rpmfusion. If someone does the necessary work (and keeps doing it for every itext update), we'll drop pdftk from rpmfusion and put it back here.

Jochen, would you like to do the packaging at rpmfusion (I will review it there) or do you want me to do it?

Closing the bug as WONTFIX.

Comment 10 Jochen Schmitt 2009-01-25 20:13:16 UTC
Ok, I'll introduced pdftk onto pdftk in the current state. If anyone have done some work which allow us to link pdftk agains the current iText, we may reintroduced it on Fedora.

Comment 11 Orcan Ogetbil 2009-02-12 19:55:27 UTC
Andrew Haley sent me a patch that should be applied to pdftk to make it link to itext dynamically (Andrew, please correct me if there is any missing or wrong information in this post). I rebuilt itext on rawhide for proper linking:
We must make sure that pdftk depends on this *exact version* of itext. 

Here is what should be done to package pdftk:

- The java_libs directory should be wiped out from the pdftk tarball. We cannot ship this directory in our SRPM since it contains some proprietary code.

- The patch that I will attach should be applied to the pdftk tree.

- Afterwards, pdftk should be built via (on the base of the pdftk tree):
    jar tf /usr/share/java/itext-2.1.4.jar | grep '\.class$' | sed 's/\.class//' | sed 's|/|\.|g' > classes
    gjavah -d java_libs -cni -classpath=%{_datadir}/java/itext-2.1.4.jar `cat classes`
    cd pdftk
    make -f Makefile.RedHat LIBDIR=%{_libdir}

- Again, pdftk must require itext-2.1.4-2. This is important. Whenever there is an update to itext, we will need to rebuild pdftk. So we should work in coordination here.

Now there is an issue that we may need to work on. The itext source that is in the pdftk tarball has some extra methods (not many, only 3 or 4) that are put in there by the pdftk author. These are denoted by him in the code as: 
    // ssteward, pdftk 1.10
Since these parts are not present in itext-2.1.4, the patch I am going to post removes the calls from pdftk to these methods. The patch denotes them by: 
    // Absent from itext-2.1.4
Now, there is a possibility that this breaks some pdftk functionality. I tested some basic commands on pdftk and didn't encounter any errors but I encourage people who know pdftk better to do more extensive tests to see if there is any breakage. If there is, we might patch itext to add these additional methods.

Jochen, are you still interested in packaging pdftk by following the above guidelines? If you are, you can request comaintainership of itext (which I maintain) on pkgdb, so that you don't need to wait for me if we need to make changes in itext.

I am grateful to Andrew Haley for his work. Without his help, we wouldn't have made this progress.

Comment 12 Orcan Ogetbil 2009-02-12 19:58:28 UTC
Created attachment 331737 [details]
link to internal itext library

Comment 13 Jochen Schmitt 2009-02-12 20:56:28 UTC
At first thank you for your help. I have tried to build itext and pdftk locally as descript above. But when I try to install the created binary rpm of pdftk on my system, I will get the following error message:

$ export LANG="C"; rpm -i pdftk-1.41-6.fc10.x86_64.rpm
error: Failed dependencies:
        /usr/lib64/gcj/itext/itext-2.1.4.jar.so()(64bit) is needed by pdftk-1.41-6.fc10.x86_64

But the /usr/lib64/gcj/itext/ directory contains the following files:

-rw-r--r-- 1 root root   40960 Feb 12 21:29 itext-2.1.4.jar.db
-rwxr-xr-x 1 root root 7122584 Feb 12 21:29 itext-2.1.4.jar.so

It will be nice, if you have a hint to solve this issue.

Comment 14 Orcan Ogetbil 2009-02-12 21:13:32 UTC
Did you try it with the itext that is in the above koji link?

Open a review request bug, and I'll have a look.

Comment 15 Jochen Schmitt 2009-02-15 19:47:27 UTC
I have open https://bugzilla.redhat.com/show_bug.cgi?id=485641 as an review request to resurrecting pdftk.

Comment 16 Orcan Ogetbil 2009-03-16 21:32:18 UTC
I think we are done with this bug. Closing...

Note You need to log in before you can comment on or make changes to this bug.