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.

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.

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.

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-7.fc10.src.rpm

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
   /usr/share/java
   %{_datadir}/java
with 
   %{_javadir}
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.

As noted, in the devel ML:
    http://osdir.com/ml/fedora-devel-list/2009-02/msg01692.html

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 
   /usr/lib64/gcj/itext/itext-2.1.4.jar.so()(64bit)
which is meaningless.

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

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.

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-9.fc10.src.rpm

* 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
#!%{_buildshell}
grep -v %{_docdir} - | %{__find_requires} $* \
     | sed 's@\(itext-[0-9.]*\.jar\.so\)\(()(64bit)\)\?@\1@'
EOF

%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?

OK, I'm on it.  In the meantime, is there any plan to patch itext to provide the entry points used by pdftk?

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.

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.

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.fc10.src.rpm

Great, there is one thing we missed: We need to replace both
   /usr/share/java
   %{_datadir}/java
with the system macro
   %{_javadir}


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?

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.

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.

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-12.fc11.src.rpm

Hello, 
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!
Tom

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.

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.9.fc10
1.41.10.fc10
1.41.10.fc11 <--incremented wrong '10'?
1.41.12.fc11

Sorry, wrong URL there, I meant that I was able to install the F11 itext binary package on F10:
ftp://fr.rpmfind.net/linux/fedora/development/i386/os/Packages/itext-2.1.4-5.fc11.i586.rpm

Tom, can you test and see if pdftk works the way you want it?

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

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

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
----------------------------------------

I want to try getting pdftk into F-10 and F-9 if possible.

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.

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.

New Package CVS Request
=======================
Package Name: pdftk
Short Description: the PDF Toolkit
Owners: s4504kr, oget
Branches: F-10
InitialCC: 

Attention: This is the resurrection of a retiered package.

I'm setting the fedora-cvs flag to ?.

cvs done.

pdftk-1.41-13.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/pdftk-1.41-13.fc10

I built pdftk for devel and for F-10-testing. Closing the bug.

@Orcan,

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.

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?

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.