Bug 485641 - Review Request: pdftk - The PDF Toolkit
Summary: Review Request: pdftk - The PDF Toolkit
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Orcan Ogetbil
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2009-02-15 19:46 UTC by Jochen Schmitt
Modified: 2009-03-18 19:06 UTC (History)
6 users (show)

Fixed In Version: 1.41-13.fc10
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-03-14 15:59:40 UTC
Type: ---
jochen: fedora_requires_release_note?
oget.fedora: fedora-review+
kevin: fedora-cvs+

Attachments (Terms of Use)

Description Jochen Schmitt 2009-02-15 19:46:40 UTC
Spec URL: http://www.herr-schmitt.de/pub/pdftk/pdftk.spec
SRPM URL: http://www.herr-schmitt.de/pub/pdftk/pdftk-1.41-7.fc10.src.rpm

If PDF is electronic paper, then pdftk is an electronic staple-remover,
hole-punch, binder, secret-decoder-ring, and X-Ray-glasses. Pdftk is a simple
tool for doing everyday things with PDF documents. Keep one in the top drawer
of your desktop and use it to:

    * Merge PDF Documents
    * Split PDF Pages into a New Document
    * Decrypt Input as Necessary (Password Required)
    * Encrypt Output as Desired
    * Burst a PDF Document into Single Pages
    * Report on PDF Metrics, including Metadata and Bookmarks
    * Uncompress and Re-Compress Page Streams
    * Repair Corrupted PDF (Where Possible)

Pdftk is also an example of how to use a library of Java classes in a
stand-alone C++ program. Specifically, it demonstrates how GCJ and CNI allow
C++ code to use iText's (itext-paulo) Java classes.

Additional Information:
This package was retiered from Fredora caused by licensing issues from the bundled iText library. Now we have a new iText library in the Fedora collection which doewn't has this licensing issues. So I have to wipe out the bundled iText library from pdftk and apply the patach provided by Andrew.Haley.

Unfortunately, I will get the following issue during installing the package:

$ 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

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.

Perhaps someone has a hint to solve this issue.

Comment 1 Orcan Ogetbil 2009-02-16 07:40:24 UTC
I think that we will need to hack either the provides list of itext, or the requires list of pdftk. I'm not sure which one is the best solution. Let's consult to fedora-java people.

Comment 2 Andrew Haley 2009-02-16 09:35:14 UTC
Yes, this must be caused by automatic dependency generation in RPM.
I suppose the best thing usually is to tell the truth: pdftk needs the
library and itext provides it.

Comment 3 Andrew Haley 2009-02-16 12:33:43 UTC
Thinking about this some more, simply exporting itext-2.1.4.jar.so is probably wrong.  When itext gets rebuilt, we need to rebuild pdftk as well.  So I think
we're going to need a versioned symlink:

  itext-2.1.4.jar.so -> itext-2.1.4-1.fc10.jar.so

and export the full version rather than itext-2.1.4.jar.so.

We don't know for certain that any minor change to itext will require pdftk to be
recompiled. but it might. so it's safer to insist on an exact build match.

Comment 5 Orcan Ogetbil 2009-02-19 21:09:49 UTC
Finally, we can review this package :)
Here are my notes:

* rpmlint says
   pdftk.src: W: mixed-use-of-spaces-and-tabs (spaces: line 30, tab: line 1)
   pdftk.src: W: patch-not-applied Patch0: pdftk-1.41-rpmopt.patch
   pdftk.src: W: patch-not-applied Patch1: pdftk-1.41-system-libgcj.patch
   pdftk.src: W: patch-not-applied Patch2: pdftk-1.41-gcjh.patch

   - We can get rid of those patches that are commented out. We will not need them anymore.
   - The mixed spaces/tabs is easy to fix.

* The package needs
   BuildRequires:  java-devel >= 1:1.6.0
otherwise, it will not build with mock.

* rm -rf java_libs/gnu_local java_libs/java_local java_libs/gnu
can be replaced with just
  rm -rf java_libs

* The guidelines say: "If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc."

So I think, we should remove Source1.

* %defattr(-,root,root,-) is preferred.

* There is a convenient %{_javadir} macro. You can replace the instances of
Sorry, this one is my bad. I should have told you this properly before.

* Parallel make must be supported whenever possible. If it is not supported, this should be noted in the SPEC file as a comment.

Comment 6 Orcan Ogetbil 2009-02-28 22:47:58 UTC
As noted, in the devel ML:

it is pdftk that has the wrong Requires.

'The dependency should either be: "itext-2.1.4.jar.so()(64bit)" or then for the actual file: "/usr/lib64/gcj/itext/itext-2.1.4.jar.so"'

Right now the dependency is 
which is meaningless.

So shall we work around the automatic dependency generation of pdftk?

Comment 7 Orcan Ogetbil 2009-02-28 22:51:51 UTC
Well, since both solutions (1- adding the "meaningless" Provides on itext and 2- hacking the dependencies of pdftk) are both workarounds and not actual solutions, I'm leaving it to Jochen to decide.

Comment 9 Orcan Ogetbil 2009-03-04 03:52:31 UTC
* We still have the rpmlint:
   pdftk.src: W: mixed-use-of-spaces-and-tabs (spaces: line 27, tab: line 1)

* To fix the dependency you can add this to the end of the %install section:

# Fix the weird dependency, e.g.
# /usr/lib64/gcj/itext/itext-x.y.z.jar.so()(64bit)  to
# /usr/lib64/gcj/itext/itext-x.y.z.jar.so
%define _use_internal_dependency_generator 0
cat << \EOF > %{name}.req
grep -v %{_docdir} - | %{__find_requires} $* \
     | sed 's@\(itext-[0-9.]*\.jar\.so\)\(()(64bit)\)\?@\1@'

%define __find_requires %{_builddir}/%{name}-%{version}/%{name}.req
chmod +x %{__find_requires}
Note that you will need to remove
   Requires:      %{_libdir}/gcj/itext/itext-2.1.4.jar.so
now. Also not that this won't break anything in 32bit systems. I am rebuilding itext with proper provides now.

* Unfortunately, we have a bigger issue. pdftk fails to compile with gcc44:

/usr/lib/gcc/x86_64-redhat-linux/4.4.0/../../../../include/c++/4.4.0/ostream:514:   instantiated from 'std::basic_ostream<char, _Traits>& std::operator<<(std::basic_ostream<char, _Traits>&, const char*) [with _Traits = std::char_traits<char>]'
pdftk.cc:119:   instantiated from here
/usr/lib/gcc/x86_64-redhat-linux/4.4.0/../../../../include/c++/4.4.0/bits/ostream_insert.h:107: error: mixing C++ and Java catches in a single translation unit

I don't know (yet) how to solve this. Andrew?

Comment 10 Andrew Haley 2009-03-04 09:49:05 UTC
OK, I'm on it.  In the meantime, is there any plan to patch itext to provide the entry points used by pdftk?

Comment 11 Orcan Ogetbil 2009-03-04 15:57:04 UTC
There is a question rather than a plan for now: 
   Do we really need to? 
I can do basic operations with pdftk. It just works. I don't know what that code that we removed does.

Comment 12 Andrew Haley 2009-03-05 09:58:37 UTC
I created a new bugzilla entry for the gcc bug mentioned above.  It's http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39380

We should be able to get a patched gcc fairly soon.  In the meantime we'll
have to build the C++ components of pdftk with -O0.

Comment 14 Orcan Ogetbil 2009-03-05 19:10:17 UTC
Great, there is one thing we missed: We need to replace both
with the system macro

Other than this, I confirm that our pdftk does the basic tasks. But we removed some of its code (they are marked in pdftk-use-internal-itext.patch as "// Absent from itext-2.1.4" ). What kind of regressions does this removal bring? Jochen, did you run any tests on our version of pdftk?

Comment 15 Jochen Schmitt 2009-03-05 19:44:44 UTC
New release:

Spec URL: http://www.herr-schmitt.de/pub/pdftk/pdftk.spec
SRPM URL: http://www.herr-schmitt.de/pub/pdftk/pdftk-1.41-10.fc11.src.rpm 

I have done the %{_javadir] stuff. In addtional I have done some basic testing without issues. Unfortunately, I didn't have a password protected pdf file for some special tests.

Comment 16 Orcan Ogetbil 2009-03-05 20:09:13 UTC
Thanks. But -O0 is not being passed to the compiler. Can you fix this?

Andrew, shall we approve this package now, or shall we wait for the gcc bug to be fixed. What do you think?

For the missing features, I would say, let's see if there are any complaints from users. If no one is using these features, we do not need to re-introduce them.

Comment 18 Tom Davidson 2009-03-06 00:34:50 UTC
Somewhere in this thread, Jochen switched from building for fc10 to fc11 (at least according to the filename).

When I try to 'rpmbuild --rebuild' the latest src.rpm on my F10 system, I get an error telling me that my java-devel needs to be 1:1.6.0. The previous src.rpm versions are no longer available, so I can't attest that this used to work.

Was this change intentional? Will the package be released for F10 after review?

Thanks much!

Comment 19 Orcan Ogetbil 2009-03-06 01:52:49 UTC
You need to have the java-1.6.0-openjdk-devel package which will provide java-devel = 1:1.6.0

Also, if you want to build pdftk on F-10, you will need to download the latest F-11 itext SRPM (actually itext-2.1.4-3 or above) and build and install it on F-10 first.

I didn't push this itext update on F-10 stable yet, because first I want to make sure that everything works right. We are close.

Comment 20 Tom Davidson 2009-03-06 16:43:20 UTC
Thanks Orcan, I was able to successfully build pdftk once I updated these packages. 

I didn't have to rebuild the F11 itext rpm from source; the one from ftp://download.fedora.redhat.com/pub/fedora/linux/development/i386/os/Packages/itext-2.1.4-5.fc11.src.rpm installed on my F10 install just fine.

I think that Jochen may have accidentally incremented from fc10 to fc11 in his pdftk spec file. The versions above go:

1.41.10.fc11 <--incremented wrong '10'?

Comment 21 Tom Davidson 2009-03-06 16:46:05 UTC
Sorry, wrong URL there, I meant that I was able to install the F11 itext binary package on F10:

Comment 22 Orcan Ogetbil 2009-03-07 01:24:19 UTC
Tom, can you test and see if pdftk works the way you want it?

Comment 23 Tom Davidson 2009-03-07 02:38:55 UTC
Yes, after rebuilding it myself as described above, i.e.:

$ wget ftp://fr.rpmfind.net/linux/fedora/development/i386/os/Packages/itext-2.1.4-5.fc11.i586.rpm 
$ wget http://www.herr-schmitt.de/pub/pdftk/pdftk-1.41-12.fc11.src.rpm
$ sudo yum install java-1.6.0-openjdk-devel
$ sudo yum localinstall itext-2.1.4-5.fc11.i586.rpm --nogpgcheck
$ rpmbuild --rebuild pdftk-1.41-12.fc11.src.rpm
$ sudo yum localinstall ~/rpmbuild/RPMS/i386/pdftk-1.41-12.fc10.i386.rpm

...I can merge pdfs using pdftk. I Haven't really stress-tested it, but so far no problems. (In particular pdftk has better handling of colorspaces than pdfmerge, which seems to just call ghostscript)

Thanks! Tom

Comment 24 Jochen Schmitt 2009-03-10 16:34:27 UTC
Because iText-2.1.5 was released, I have updated the iText package and the pdftk package for this new release.

New release:

Spec URL: http://www.herr-schmitt.de/pub/pdftk/pdftk.spec
SRPM URL: http://www.herr-schmitt.de/pub/pdftk/pdftk-1.41-13.fc10.src.rpm

Comment 25 Orcan Ogetbil 2009-03-10 21:00:44 UTC
Since we got no objections, I'm approving the package. We should keep an eye on that gcc bug Andrew submitted.

Jochen, do we want pdftk on F-9 or F-10?  How shall we handle this?

This package (pdftk) is APPROVED by oget

Comment 26 Jochen Schmitt 2009-03-10 21:05:29 UTC
I want to try getting pdftk into F-10 and F-9 if possible.

Comment 27 Orcan Ogetbil 2009-03-10 21:18:22 UTC
I am fine with F-10. Do you want to update itext yourself or should I do it?

Meanwhile for F-9, it is a little bit of a problem. itext (and many of its dependencies) is not available on that branch. You can take over the F-9 branch if you want.

Comment 28 Orcan Ogetbil 2009-03-11 03:52:45 UTC
I just did the itext update on F-10 and submitted it to testing. You'll need to file a ticket to releng to tag it in the buildroot for building pdftk.

Comment 29 Jochen Schmitt 2009-03-11 16:15:50 UTC
New Package CVS Request
Package Name: pdftk
Short Description: the PDF Toolkit
Owners: s4504kr, oget
Branches: F-10

Attention: This is the resurrection of a retiered package.

Comment 30 Orcan Ogetbil 2009-03-11 18:16:44 UTC
I'm setting the fedora-cvs flag to ?.

Comment 31 Kevin Fenzi 2009-03-13 02:45:12 UTC
cvs done.

Comment 32 Fedora Update System 2009-03-14 15:57:33 UTC
pdftk-1.41-13.fc10 has been submitted as an update for Fedora 10.

Comment 33 Orcan Ogetbil 2009-03-14 15:59:40 UTC
I built pdftk for devel and for F-10-testing. Closing the bug.

Comment 34 Jochen Schmitt 2009-03-15 19:50:20 UTC

thank you for your help. Unfortunately, bodhi let not allow me to mark the pacage as stable, if the update was pushed by a comaintainer. So it may be nice, if you can take over this task.

Comment 35 Orcan Ogetbil 2009-03-16 05:13:09 UTC
I just pushed itext to stable. We (you or me) should be able to push pdftk to stable as soon as it is in the testing repo. It should be in there in a day or two. Do you want me to revoke my testing request?

Comment 36 Fedora Update System 2009-03-18 19:06:26 UTC
pdftk-1.41-13.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

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