[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Hi, Johann.

First of all, thank you for updating the packaging of pdftk. I've been
thinking about doing something like that, but just didn't have the time.

IANADD, but I'm interested in the package and I have some things to say.


just saw some things
here.

On Sep 14 2009, Johann Felix Soden wrote:
> Dear mentors,
> 
> I am looking for a sponsor for my NMU of the package "pdftk".
> 
> In the last month, I sent two mails to its maintainer (Aurélien GÉRÔME)
> concerning his package/this NMU but got no reply.
> 
> To solve the (RC) bugs, I have to change lots of things. See below for
> the shortened changelog. So this is not a normal small-diff NMU.

Yes, this is a well deserved facelift. You may, BTW, like to consider
the following:

* refresh the quilt patches, so that they apply without fuzz;

* 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'
`----

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

* 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?).


* 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$ 
`----

>   * DFSG-repack and use extern libitext-java (Closes: #519466)

Thank you very much for the size reduction in the package.

It seems fine otherwise and would be a very welcome update so that the
package doesn't drag even more useless dependencies/deprecated libraries.


Regards, Rogério Brito.

-- 
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org


Reply to: