Re: RFS: pdftk (major NMU, fixes RC bugs)

[Johann Felix Soden <johfel@gmx.de>]

Dear Rogério!

Thanks for the comments.
I've uploaded a new version to mentors.debian.net

On Tuesday,15.09.2009, 02:49 -0300 Rogério Brito wrote:
> * refresh the quilt patches, so that they apply without fuzz;
fixed
> 
> * you may want to patch the code to avoid the use of tmpnam (see the
>   warnings).
> ,----
> | gcj pdftk.o attachments.o report.o /usr/lib/gcj/itext-2.1.5.jar.so  -I../java_libs2 -lgcj -fdollars-in-identifiers -Wl,-Bsymbolic -Wl,--as-needed -fpic -lstdc++ -o pdftk
> | report.o: In function `ReplaceXmp(com::lowagie::text::pdf::PdfReader*, std::basic_string<char, std::char_traits<char>, std::allocator<char> >)':
> | report.cc:(.text+0x27c7): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
> | make[2]: Leaving directory `/tmp/pdftk-1.41+dfsg/pdftk'
> | make[1]: Leaving directory `/tmp/pdftk-1.41+dfsg'
> `----
done
> 
> * some programs are compiled with warnings disabled. Any reason for
>   that? I'd say that -Wall -Wextra is a good thing for the C/C++ parts,
>   as well as -Weffc++ for C++ files.
> 
>   I actually compiled it here with the warnings and it reveals some
>   "nice" things.
thanks. I've added a new patch to solve the warnings.
> 
> * there's some weird stuff going on here: if you compile the code with
>   -O2, then everything builds fine on amd64, at least. If you compile
>   with -O3, bombs with an error (not an ICE).
> 
>   I'm very ignorant about Java and stuff, but it seems to me that the
>   compiler should be consistent about compiling the code with any kind
>   of optimization levels. They are not asking the compiler to change its
>   behaviour here.
> 
>   IMVHO, you should take this upstream (perhaps it has already been
>   fixed if you build it with gcc-snapshot?).
This is g++'s PR C++/39380 which is solved at least in Debian's current
g++ 4.4.1-4. But during runtime, pdftk depends strongly on the ABI of
libitext-java-gcj which is built with gcj-4.3 at the moment. So we have
to use the same compiler version.
If there is a new version of libitext-java-gcj built with a new compiler
version, a bin-NMU of pdftk should be enough. pdftk is already buildable
with g++/gcj 4.4

> 
> * you might want to consider these lintian warnings:
> 
> ,----
> | rbrito@chagas:/tmp$ lintian -IE --pedantic pdftk_1.41+dfsg-0.1_amd64.changes 
> | I: pdftk: hyphen-used-as-minus-sign usr/share/man/man1/pdftk.1.gz:54
> | I: pdftk: hyphen-used-as-minus-sign usr/share/man/man1/pdftk.1.gz:153
> | P: pdftk: copyright-refers-to-symlink-license usr/share/common-licenses/GPL
> | P: pdftk: no-upstream-changelog
> | rbrito@chagas:/tmp$ 
> `----
fixed


Thanks again!

Best wishes
 Johann Felix Soden