In Makefile.Debian it looks like the TOOLPATH variable could be overridden in order to get a full toolchain tuple.
Is it possible to use a normal Java compiler instead? gcj's days are numbered and we do intend to remove it eventually.
PdfTk is now broken: mfld@home $ pdftk pdftk: error while loading shared libraries: libgcj.so.14: cannot open shared object file: No such file or directory Still requires libgcj that is no more installed, nor required as dependency: mfld@home $ equery g pdftk * Searching for pdftk ... * dependency graph for app-text/pdftk-2.02 `-- app-text/pdftk-2.02 amd64 `-- sys-devel/gcc-4.9.3 (sys-devel/gcc) amd64 [gcj] [ app-text/pdftk-2.02 stats: packages (2), max depth (1) ]
Problem solved by emerging manually, to force the update of the libgjc reference to the right & latest version.
(In reply to mfld.fr from comment #3) > Problem solved by emerging manually, to force the update of the libgjc > reference to the right & latest version. That's an entirely different bug. Please report it separately.
OK, reported as https://bugs.gentoo.org/show_bug.cgi?id=588176.
*** Bug 608246 has been marked as a duplicate of this bug. ***
Hi all, I noticed that pdftk fails to build with GCC-6.3.0 with default useflags, the only issue being that GCC-6.3.0 by default disabled gcj but still provides support for that useflag. I understand that gcj is going to be removed eventually, but that's a long-term thing and a much more near-term thing is that our dependency between pdftk and gcc[gcj] is missing in the ebuilds. Could we fix the ebuild first, talk about fixing pdftk's build system or toolchain support later? Thanks a lot.
(In reply to Yi Yang from comment #7) > Hi all, > > I noticed that pdftk fails to build with GCC-6.3.0 with default useflags, > the only issue being that GCC-6.3.0 by default disabled gcj but still > provides support for that useflag. > I don't think so. I do have the gcj use flag but it is ignored when building gcc-6.3.0
Lengthy googling found this, not tested yet... https://gist.github.com/jpmckinney/1840053
*** Bug 595414 has been marked as a duplicate of this bug. ***
Looks like a hack to me. The build system would need a rewrite to fix this, removing all the references to object files, as other JDKs don't provide ahead-of-time compilation. That patch doesn't fix that: - $(GCJ) $(GCJFLAGS) -c java_lib.jar + $(GCJ) $(GCJFLAGS) -c java_lib.jar # @todo this is a problem Is pdftk still needed? It looks like Fedora hasn't built it since 2013: https://koji.fedoraproject.org/koji/packageinfo?packageID=2742
With gcc 5 having just gone stable, we're now another step closer to dropping gcj. I took a closer look at this and it's really not just using gcj in the build system. The whole thing is wedded closely to gcj and changing that is very non-trivial. It is very telling that upstream promised a non-gcj version some two years ago and still haven't delivered. No wonder Fedora stopped packaging it. I know this software is quite unique but be prepared to let it go if upstream don't deliver.
Broken with sys-devel/gcc-6.3.0: # Magnus Granberg <zorry@gentoo.org> (18 Jan 2017) # Adding the mask so that end users and devlopers are notified of the removal and have some # time to migrate. There is no support for gcj in gcc-7 >=sys-devel/gcc-6.3.0 gcj
*** Bug 588176 has been marked as a duplicate of this bug. ***
*** Bug 617790 has been marked as a duplicate of this bug. ***
This bug becomes more important since =sys-devel/gcc-6.4.0 stabilization, that can't build stable =app-text/pdftk-2.02. Shouldn't pdftk be masked then, since gcj use flag is masked?
(In reply to Viacheslav Ostroukh from comment #16) > This bug becomes more important since =sys-devel/gcc-6.4.0 stabilization, > that can't build stable =app-text/pdftk-2.02. Shouldn't pdftk be masked > then, since gcj use flag is masked? Seconded. I just ran into this issue. Despite gcj use flags and installed pdftk the upgrade to gcc-6 stable proceeds and breaks the compile of pdftk now.
I actually sent an email to the upstream maintainer on 10 Oct, but have received no response. I couldn't find any evidence of forum or discussion area on the upstream web site. It also looks like the latest release is four years old, and the latest copyright date is 2014. I found a newer email address through his presence on the O'Reilly site, and will post back here if I get any response from that address.
(In reply to Jack from comment #18) > I actually sent an email to the upstream maintainer on 10 Oct, but have > received no response. I couldn't find any evidence of forum or discussion > area on the upstream web site. It also looks like the latest release is > four years old, and the latest copyright date is 2014. I found a newer > email address through his presence on the O'Reilly site, and will post back > here if I get any response from that address. I am far from being a maintainer, but I would really consider masking it (even for removal, may be). As I see, mutool from app-text/mupdf covers most of its functionality and actively maintained, it may be suggested as an alternative.
(In reply to Viacheslav Ostroukh from comment #19) > As I see, mutool from app-text/mupdf covers most > of its functionality and actively maintained, it may be suggested as an > alternative. Another alternative is app-text/qpdf.
I had a look to mupdf and qpdf but they doesn't cover all the functionalities of pdftk, mainly the most useful: filling forms with a fdf/xfdf file. Maybe something based on Poppler or iText could do the job.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7a0a8d6e5c3b03291d696124367821116ccbe5d4 commit 7a0a8d6e5c3b03291d696124367821116ccbe5d4 Author: Andreas K. Huettel <dilfridge@gentoo.org> AuthorDate: 2017-11-27 17:43:52 +0000 Commit: Andreas K. Huettel <dilfridge@gentoo.org> CommitDate: 2017-11-27 17:44:42 +0000 app-text/pdftk: Make this build with gcc-5 for now Hardwire pdftk to use gcc-5.4.0, and depend on it Bug: https://bugs.gentoo.org/562568 Package-Manager: Portage-2.3.16, Repoman-2.3.6 app-text/pdftk/pdftk-2.02.ebuild | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)}
Since gcc-6.4 is still supported by Gentoo and probably will continue to be supported for some more time and because pdftk works well and there seems to be neither comparable replacement nor migration to javac by upstream, I would suggest to fix ebuild like this -RDEPEND="sys-devel/gcc:5.4.0[gcj]" +RDEPEND="<sys-devel/gcc-7[gcj]" Then it would be up to the user to either unmask the package and gcj USE flag for gcc and continue to be happy until gcc-6 deprecation, or seek for ways to immediately change his/her workflow.
(In reply to Jack from comment #18) > I actually sent an email to the upstream maintainer on 10 Oct, but have received no response. [snip] I found a newer email address through his presence on the O'Reilly site, and will post back here if I get any response from that address. Now over a month later, and no reply to either email. It really does look dead upstream.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ce2f044cc673a6d08cd8a40459bd0dbf66df864e commit ce2f044cc673a6d08cd8a40459bd0dbf66df864e Author: Patrice Clement <monsieurp@gentoo.org> AuthorDate: 2018-01-04 14:30:42 +0000 Commit: Patrice Clement <monsieurp@gentoo.org> CommitDate: 2018-01-04 15:07:54 +0000 dev-python/stapler: new ebuild. stapler is a suite of tools for PDF files manipulation. It makes use of the PyPDF2 library to provide a (somewhat) lighter alternative to pdftk. See https://github.com/hellerbarde/stapler. Bug: https://bugs.gentoo.org/562568 Package-Manager: Portage-2.3.13, Repoman-2.3.3 Reviewed-by: James Le Cuirot <chewi@gentoo.org> dev-python/stapler/Manifest | 1 + dev-python/stapler/metadata.xml | 11 ++++++++++ dev-python/stapler/stapler-0.4_p20160424.ebuild | 29 +++++++++++++++++++++++++ 3 files changed, 41 insertions(+)}
Hi there! First, thank you Manuel for the suggestion. We were looking really hard for an alternative to pdftk. I think stapler is the last nail in pdftk's coffin. We encourage everybody CC'ed in to give it a go and will wait 30 days for some feedback so that you have ample time to tinker with it. If there's no objection until then, we will mask pdftk for removal.
In https://github.com/hellerbarde/stapler/blob/master/TODO there's a comparison between pdftk features and stapler features. Unfortunately, forms e.g. are not (yet?) supported. To my knowledge there's no other tool supporting this. Are we too early to nail the coffin?
We are a little earlier than we might have been. Another dev masked the gcj flag against gcc 6 even though it wasn't removed by upstream until 7. I had assumed that there was additional work needed to support it on 6 but now I think adjusting the mask is all that is needed. I'm CC'ing Zorry, who added the mask, to get his opinion.
The following third-party rewrite of pdftk to remove gcj requirement looks interesting: https://gitlab.com/marcvinyals/pdftk http://repo.or.cz/marcv-overlay.git/blob_plain/HEAD:/app-text/pdftk/pdftk-9999.ebuild Ref: https://forums.gentoo.org/viewtopic-p-8187088.html#8187088
(In reply to James Le Cuirot from comment #28) > We are a little earlier than we might have been. Another dev masked the gcj > flag against gcc 6 even though it wasn't removed by upstream until 7. I had > assumed that there was additional work needed to support it on 6 but now I > think adjusting the mask is all that is needed. > > I'm CC'ing Zorry, who added the mask, to get his opinion. Gcc 7 has allready a bug open for stabilization. So gcj's days are numbered.
(In reply to Fitzcarraldo from comment #29) > The following third-party rewrite of pdftk to remove gcj requirement looks > interesting: > > https://gitlab.com/marcvinyals/pdftk > > http://repo.or.cz/marcv-overlay.git/blob_plain/HEAD:/app-text/pdftk/pdftk- > 9999.ebuild > > Ref: https://forums.gentoo.org/viewtopic-p-8187088.html#8187088 I've compiled the pdftk-9999 (java based) gcc-5.4.0-r4 is gone and pdftk is working as it should.
(In reply to Joseph from comment #31) > I've compiled the pdftk-9999 (java based) > gcc-5.4.0-r4 is gone and pdftk is working as it should. That sounds great. Can we please have that ebuild in testing?
(In reply to Bodo Graumann from comment #32) > (In reply to Joseph from comment #31) > > I've compiled the pdftk-9999 (java based) > > gcc-5.4.0-r4 is gone and pdftk is working as it should. > > That sounds great. Can we please have that ebuild in testing? The ebuild "pdftk-9999" is here: http://repo.or.cz/marcv-overlay.git/blob_plain/HEAD:/app-text/pdftk/pdftk-9999.ebuild Forum related link: https://forums.gentoo.org/viewtopic-t-1070648-highlight-.html
(In reply to Joseph from comment #33) > (In reply to Bodo Graumann from comment #32) > > (In reply to Joseph from comment #31) > > > I've compiled the pdftk-9999 (java based) > > > gcc-5.4.0-r4 is gone and pdftk is working as it should. > > > > That sounds great. Can we please have that ebuild in testing? Here's another vote for that! > The ebuild "pdftk-9999" is here: > > http://repo.or.cz/marcv-overlay.git/blob_plain/HEAD:/app-text/pdftk/pdftk- > 9999.ebuild > > Forum related link: > https://forums.gentoo.org/viewtopic-t-1070648-highlight-.html I've switched to the ebuild above, and it works great. I looked (rather briefly) at various replacements (including stapler) and didn't find anything that could apply a watermark to a document from the command-line.
(In reply to Joseph from comment #33) > > The ebuild "pdftk-9999" is here: > > http://repo.or.cz/marcv-overlay.git/blob_plain/HEAD:/app-text/pdftk/pdftk- > 9999.ebuild > > Forum related link: > https://forums.gentoo.org/viewtopic-t-1070648-highlight-.html +1. Works great!
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=09e0550990ea6cf5232ba3c0a11c933aa01d52d6 commit 09e0550990ea6cf5232ba3c0a11c933aa01d52d6 Author: charIes17 <charles17@arcor.de> AuthorDate: 2018-03-30 14:40:11 +0000 Commit: Patrice Clement <monsieurp@gentoo.org> CommitDate: 2018-04-08 22:42:07 +0000 app-text/pdftk: add live ebuild with different upstream. Bug: https://bugs.gentoo.org/562568 See https://forums.gentoo.org/viewtopic-p-8187088.html#8187088 Package-Manager: Portage-2.3.24, Repoman-2.3.6 Closes: https://github.com/gentoo/gentoo/pull/7712 app-text/pdftk/pdftk-9999.ebuild | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+)}
Let's mark this bug as FIXED this everybody seems happy with this version of pdftk. Thanks everyone!
