Tracker bug for removing pdftk
# Jeremy Olexa <darkside@gentoo.org> (20 Dec 2008) # Removed in 60 days. Many issues including a gcc-4.3 failure and dead upstream # see tracker bug (bug 251796) app-text/pdftk media-gfx/keyjnote
Do you know an alternative for this? I am currently using it for merging pdf files in one and I need this Thanks!
(In reply to comment #2) > Do you know an alternative for this? I am currently using it for merging pdf > files in one and I need this > > Thanks! > https://bugs.gentoo.org/show_bug.cgi?id=225709#c14 suggests pdfjam. You are welcome to fix up pdftk. A hack would be to make it require !gcc-4.3, but working patch preferred of course! (And/or take this package to sunrise after 60 days)
pdfjam seems good enough for me, thanks! (maybe should be noted in mask message) About trying to fix it, I tried to search for other distributions shipping it, but I only found debian patches at http://patch-tracking.debian.net/package/pdftk/1.41-3 and an opensuse package at http://download.opensuse.org/factory/repo/src-oss/suse/src/pdftk-1.41-103.10.src.rpm but I am not sure if they would fix current problems (well, reading opensuse's package changelog seems that changes are recent, then, maybe opensuse's maintainer fixed some of the problems) Sorry, but I am unable to help on this now (I will be also out from tomorrow to 5th or 6th January)
I am also using pdftk sometimes - not often, but when I need to cut pages from several presentations and put them together in a new one, it's very useful. It's a pity to remove it from Gentoo.
(In reply to comment #5) > I am also using pdftk sometimes - not often, but when I need to cut pages from > several presentations and put them together in a new one, it's very useful. > It's a pity to remove it from Gentoo. > Can you try jpdftweak from bug #251424? We may add it as a replacement.
Please do not remove this package from portage. It works fine. I use it in production scripts for publishing. jpdftweak is a Java Swing application and does not work in a script. pdfjam does not have the stamping feature that I need, plus it removes hyperlinks.
I expect next message to be "Here is an working patch for latest gcj." or "Removed from tree.", otherwise please stay quiet.
I think pdftk's author (who happens to be alive) would be interested in knowing that his software has troubles with the latest gcj, and may gladly fix it. If contact hasn't been made, please tell it here, so maybe someone else can do it. I'm not using keyjnote so I care less about it, but I imagine it would be the same.
Created attachment 176181 [details, diff] Patch to make pdftk-1.41 compile with gcc-4.3 Thanks to Debian pdftk package maintainers.
Created attachment 176183 [details] Revised ebuild for pdftk that works with gcc 4.3 Tested on x86 and amd64.
keyjnote has been renamed to "impressive", which was just featured in this week's lwn, and the upstream is certainly still active. Please don't get rid of keyjnote ; instead it should be transitioned to the new name. The pdftk dependency is actually optional (but recommended) http://impressive.sourceforge.net/manual.php#req
(In reply to comment #10) > Created an attachment (id=176181) [edit] > Patch to make pdftk-1.41 compile with gcc-4.3 > > Thanks to Debian pdftk package maintainers. Thanks, fixed all bugs in pdftk-1.41-r1 and removed from package.mask. Also removed keyjnote because it seemed to me that the pdftk dep is the only thing directly threatening it. Not a maintainer though.
(In reply to comment #12) > keyjnote has been renamed to "impressive", which was just featured in this > week's lwn, and the upstream is certainly still active. Please don't get rid of > keyjnote ; instead it should be transitioned to the new name. The pdftk > dependency is actually optional (but recommended) > http://impressive.sourceforge.net/manual.php#req see bug 236316
(In reply to comment #13) > Thanks, fixed all bugs in pdftk-1.41-r1 and removed from package.mask. Caster, you could have at least adapted andrex's ebuild... now pdftk-1.41-r1 depends on >=gcc-4.3, whereas 1.41 depends on >=3.3, I don't see the point in imposing this. And if the patch breaks compilation with grandpa's gcc, I'm pretty sure some eclass provides you the way to apply the 4.3 patch only if gcj's version is >=4.3.
