I just git a "broken dependencies" notice for a package that I maintain. The reason is that "pdftk" got retired just the other day.
I may have missed a corresponding post on fedora-devel, but I think a heads up notice to maintainers of depending packages may be in order before you retire a package, as a general idea.
You see, unretiring a package is so much more work than changing maintainership.
As for pdftk: I see 2 failed builds for version 1.45 and none for the current version 2.02 (which probably breaks the api anyways). What are the plans? Retire pdftk completely? Start fresh with pdftk2?
pdflabs, the maker of pdftk, provide binary as well as source rpms for pdftk 2.02, by the way. I might even look into packaging it but don't want to duplicate any existing efforts.
Michael
On Thu, 06 Mar 2014 11:31:18 +0100 Michael J Gruber mjg@fedoraproject.org wrote:
I just git a "broken dependencies" notice for a package that I maintain. The reason is that "pdftk" got retired just the other day.
I may have missed a corresponding post on fedora-devel, but I think a heads up notice to maintainers of depending packages may be in order before you retire a package, as a general idea.
You see, unretiring a package is so much more work than changing maintainership.
As for pdftk: I see 2 failed builds for version 1.45 and none for the current version 2.02 (which probably breaks the api anyways). What are the plans? Retire pdftk completely? Start fresh with pdftk2?
pdflabs, the maker of pdftk, provide binary as well as source rpms for pdftk 2.02, by the way. I might even look into packaging it but don't want to duplicate any existing efforts.
Michael
+1
pdftk is a very important package, so new (co)maintainers shouldn't be hard to find.
On 03/06/2014 12:03 PM, Susi Lehtola wrote:
On Thu, 06 Mar 2014 11:31:18 +0100 Michael J Gruber mjg@fedoraproject.org wrote:
I just git a "broken dependencies" notice for a package that I maintain. The reason is that "pdftk" got retired just the other day.
I may have missed a corresponding post on fedora-devel, but I think a heads up notice to maintainers of depending packages may be in order before you retire a package, as a general idea.
You see, unretiring a package is so much more work than changing maintainership.
As for pdftk: I see 2 failed builds for version 1.45 and none for the current version 2.02 (which probably breaks the api anyways). What are the plans? Retire pdftk completely? Start fresh with pdftk2?
pdflabs, the maker of pdftk, provide binary as well as source rpms for pdftk 2.02, by the way. I might even look into packaging it but don't want to duplicate any existing efforts.
Michael
+1
pdftk is a very important package, so new (co)maintainers shouldn't be hard to find.
+++1
Joachim Backes
On 03/06/2014 11:31 AM, Michael J Gruber wrote:
As for pdftk: I see 2 failed builds for version 1.45 and none for the current version 2.02 (which probably breaks the api anyways). What are the plans? Retire pdftk completely? Start fresh with pdftk2?
pdftk has a hard dependency on GCJ because it's a C++ program that uses a Java library (iText) through CNI. I once tried to rewrite the C++ part in Java, but the existing command line parser is quite involved, so I didn't quite get there.
Switch to pdftk version 2 doesn't change the basic architecture of the program.
(We really want to get rid of GCJ.)
On Thu, Mar 06, 2014 at 12:03:46PM +0100, Florian Weimer wrote:
pdftk has a hard dependency on GCJ because it's a C++ program that uses a Java library (iText) through CNI. I once tried to rewrite the C++ part in Java, but the existing command line parser is quite involved, so I didn't quite get there.
Switch to pdftk version 2 doesn't change the basic architecture of the program.
(We really want to get rid of GCJ.)
An additional reason is the fact, that pdftk2 may depend on iText5 or later. For licensing reasons Fedora only provides iText-2.1.7 at the last release of iText wihout any known licensing issues.
That are the two reasons why I'm not able to support pdftk on Fedora anymore and was forced to reitred this package. I'm sorry for nayone who maintaining any package with dependencies on this package.
Best Regards:
Jochen Schmitt
On 03/06/2014 06:41 AM, Jochen Schmitt wrote:
On Thu, Mar 06, 2014 at 12:03:46PM +0100, Florian Weimer wrote:
pdftk has a hard dependency on GCJ because it's a C++ program that uses a Java library (iText) through CNI. I once tried to rewrite the C++ part in Java, but the existing command line parser is quite involved, so I didn't quite get there.
Switch to pdftk version 2 doesn't change the basic architecture of the program.
(We really want to get rid of GCJ.)
An additional reason is the fact, that pdftk2 may depend on iText5 or later. For licensing reasons Fedora only provides iText-2.1.7 at the last release of iText wihout any known licensing issues.
That are the two reasons why I'm not able to support pdftk on Fedora anymore and was forced to reitred this package. I'm sorry for nayone who maintaining any package with dependencies on this package.
This is why pdftk died. We can't include iText5+ because of its licensing issues.
~tom
== ¸.·´¯`·.´¯`·.¸¸.·´¯`·.¸><(((º> OSAS @ Red Hat University Outreach || Fedora Special Projects || Fedora Legal
On Thu, 06 Mar 2014 14:52:27 -0500 Tom Callaway tcallawa@redhat.com wrote:
That are the two reasons why I'm not able to support pdftk on Fedora anymore and was forced to reitred this package. I'm sorry for nayone who maintaining any package with dependencies on this package.
This is why pdftk died. We can't include iText5+ because of its licensing issues.
But isn't it AGPL licensed, which is a free license..?
On 03/07/2014 01:30 PM, Susi Lehtola wrote:
On Thu, 06 Mar 2014 14:52:27 -0500 Tom Callaway tcallawa@redhat.com wrote:
That are the two reasons why I'm not able to support pdftk on Fedora anymore and was forced to reitred this package. I'm sorry for nayone who maintaining any package with dependencies on this package.
This is why pdftk died. We can't include iText5+ because of its licensing issues.
But isn't it AGPL licensed, which is a free license..?
See here: https://lists.fedoraproject.org/pipermail/legal/2011-June/001656.html
Michal
Quoting Susi Lehtola jussilehtola@fedoraproject.org:
On Thu, 06 Mar 2014 14:52:27 -0500 Tom Callaway tcallawa@redhat.com wrote:
That are the two reasons why I'm not able to support pdftk on Fedora anymore and was forced to reitred this package. I'm sorry for nayone who maintaining any package with dependencies on this package.
This is why pdftk died. We can't include iText5+ because of its licensing issues.
But isn't it AGPL licensed, which is a free license..?
I've retired pdfchain from rawhide because of the broken dependency caused by pdftk.
On Thu, Mar 6, 2014 at 2:52 PM, Tom Callaway wrote:
On 03/06/2014 06:41 AM, Jochen Schmitt wrote:
On Thu, Mar 06, 2014 at 12:03:46PM +0100, Florian Weimer wrote:
pdftk has a hard dependency on GCJ because it's a C++ program that uses a Java library (iText) through CNI. I once tried to rewrite the C++ part in Java, but the existing command line parser is quite involved, so I didn't quite get there.
Switch to pdftk version 2 doesn't change the basic architecture of the program.
(We really want to get rid of GCJ.)
An additional reason is the fact, that pdftk2 may depend on iText5 or later. For licensing reasons Fedora only provides iText-2.1.7 at the last release of iText wihout any known licensing issues.
That are the two reasons why I'm not able to support pdftk on Fedora anymore and was forced to reitred this package. I'm sorry for nayone who maintaining any package with dependencies on this package.
This is why pdftk died. We can't include iText5+ because of its licensing issues.
Sorry I am missing something. Why can't we keep the old pdftk that works with itext2?
Orcan
----- Original Message -----
On Thu, Mar 6, 2014 at 2:52 PM, Tom Callaway wrote:
On 03/06/2014 06:41 AM, Jochen Schmitt wrote:
On Thu, Mar 06, 2014 at 12:03:46PM +0100, Florian Weimer wrote:
pdftk has a hard dependency on GCJ because it's a C++ program that uses a Java library (iText) through CNI. I once tried to rewrite the C++ part in Java, but the existing command line parser is quite involved, so I didn't quite get there.
Switch to pdftk version 2 doesn't change the basic architecture of the program.
(We really want to get rid of GCJ.)
An additional reason is the fact, that pdftk2 may depend on iText5 or later. For licensing reasons Fedora only provides iText-2.1.7 at the last release of iText wihout any known licensing issues.
That are the two reasons why I'm not able to support pdftk on Fedora anymore and was forced to reitred this package. I'm sorry for nayone who maintaining any package with dependencies on this package.
This is why pdftk died. We can't include iText5+ because of its licensing issues.
Sorry I am missing something. Why can't we keep the old pdftk that works with itext2?
Check the whole thread - because of GCJ dependency. iText is second issue. The first could be fixed by rewrite of offending part of code to Java but someone would have to do it first. That's how I understand this situation.
Jaroslav
Orcan
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Fri, Mar 7, 2014 at 9:32 AM, Jaroslav Reznik wrote:
Sorry I am missing something. Why can't we keep the old pdftk that works with itext2?
Check the whole thread - because of GCJ dependency. iText is second issue. The first could be fixed by rewrite of offending part of code to Java but someone would have to do it first. That's how I understand this situation.
The only things I read in the thread are "GCJ is abandoned" and "we really want to get rid of GCJ". Am I supposed to come to the conclusion that the GCJ package is dropped from Fedora? If so, where is this decision made? Why was it made without consulting GCJ users?
We have so many abandoned projects packaged in Fedora. I don't understand the rush to drop one of them.
If GCJ is not dropped, what is the reason for retiring pdftk then? (sorry it's Friday night, my deduction skill are at their lowest)
Best, Orcan
Orcan Ogetbil wrote:
The only things I read in the thread are "GCJ is abandoned" and "we really want to get rid of GCJ". Am I supposed to come to the conclusion that the GCJ package is dropped from Fedora? If so, where is this decision made? Why was it made without consulting GCJ users?
We have so many abandoned projects packaged in Fedora. I don't understand the rush to drop one of them.
+1. Both GCJ itself and pdftk are extremely useful packages that shouldn't get retired without giving other maintainers the chance to pick them up!
Kevin Kofler
On 03/08/2014 03:37 AM, Orcan Ogetbil wrote:
On Fri, Mar 7, 2014 at 9:32 AM, Jaroslav Reznik wrote:
Sorry I am missing something. Why can't we keep the old pdftk that works with itext2?
Check the whole thread - because of GCJ dependency. iText is second issue. The first could be fixed by rewrite of offending part of code to Java but someone would have to do it first. That's how I understand this situation.
The only things I read in the thread are "GCJ is abandoned" and "we really want to get rid of GCJ". Am I supposed to come to the conclusion that the GCJ package is dropped from Fedora? If so, where is this decision made? Why was it made without consulting GCJ users?
The problem is more to do with upstream maintainership. If GCJ is to be used in the future it needs to be updated to a current version of the Java class library, but that's a lot of work. GCJ is still a pretty good compiler for the Java language, but it's stuck at JDK5 (ish).
Andrew.
----- Original Message -----
On 03/08/2014 03:37 AM, Orcan Ogetbil wrote:
On Fri, Mar 7, 2014 at 9:32 AM, Jaroslav Reznik wrote:
Sorry I am missing something. Why can't we keep the old pdftk that works with itext2?
Check the whole thread - because of GCJ dependency. iText is second issue. The first could be fixed by rewrite of offending part of code to Java but someone would have to do it first. That's how I understand this situation.
The only things I read in the thread are "GCJ is abandoned" and "we really want to get rid of GCJ". Am I supposed to come to the conclusion that the GCJ package is dropped from Fedora? If so, where is this decision made? Why was it made without consulting GCJ users?
The problem is more to do with upstream maintainership. If GCJ is to be used in the future it needs to be updated to a current version of the Java class library, but that's a lot of work. GCJ is still a pretty good compiler for the Java language, but it's stuck at JDK5 (ish).
Andrew.
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
And JDK5 might be good enough for the use required. It doesn't claim to be anything more than that, so I don't see the harm in leaving it there.
Hi
And JDK5 might be good enough for the use required. It doesn't claim to be anything more than that, so I don't see the harm in leaving it
there.
We don't orphan or retire packages based on harm. We do it when there is noone volunteering to maintain it. If you care about GCJ, step up
Rahul
On 03/19/2014 10:59 PM, Andrew Hughes wrote:
----- Original Message -----
On 03/08/2014 03:37 AM, Orcan Ogetbil wrote:
On Fri, Mar 7, 2014 at 9:32 AM, Jaroslav Reznik wrote:
Sorry I am missing something. Why can't we keep the old pdftk that works with itext2?
Check the whole thread - because of GCJ dependency. iText is second issue. The first could be fixed by rewrite of offending part of code to Java but someone would have to do it first. That's how I understand this situation.
The only things I read in the thread are "GCJ is abandoned" and "we really want to get rid of GCJ". Am I supposed to come to the conclusion that the GCJ package is dropped from Fedora? If so, where is this decision made? Why was it made without consulting GCJ users?
The problem is more to do with upstream maintainership. If GCJ is to be used in the future it needs to be updated to a current version of the Java class library, but that's a lot of work. GCJ is still a pretty good compiler for the Java language, but it's stuck at JDK5 (ish).
And JDK5 might be good enough for the use required. It doesn't claim to be anything more than that, so I don't see the harm in leaving it there.
Speaking as the upstream maintainer, I do.
Andrew.
On Thu, Mar 20, 2014 at 7:24 AM, Andrew Haley wrote:
On 03/19/2014 10:59 PM, Andrew Hughes wrote:>>
And JDK5 might be good enough for the use required. It doesn't claim to be anything more than that, so I don't see the harm in leaving it there.
Speaking as the upstream maintainer, I do.
Hi Andrew, can you be a little more specific about the potential harm you see with keeping GCJ in Fedora?
Thanks, Orcan
On 03/22/2014 07:51 PM, Orcan Ogetbil wrote:
On Thu, Mar 20, 2014 at 7:24 AM, Andrew Haley wrote:
On 03/19/2014 10:59 PM, Andrew Hughes wrote:>>
And JDK5 might be good enough for the use required. It doesn't claim to be anything more than that, so I don't see the harm in leaving it there.
Speaking as the upstream maintainer, I do.
Hi Andrew, can you be a little more specific about the potential harm you see with keeping GCJ in Fedora?
I think Rahul already answered this. Do you expect me to say something different from him?
Andrew.
On Mon, Mar 24, 2014 at 6:02 AM, Andrew Haley wrote:
On 03/22/2014 07:51 PM, Orcan Ogetbil wrote:
On Thu, Mar 20, 2014 at 7:24 AM, Andrew Haley wrote:
On 03/19/2014 10:59 PM, Andrew Hughes wrote:>>
And JDK5 might be good enough for the use required. It doesn't claim to be anything more than that, so I don't see the harm in leaving it there.
Speaking as the upstream maintainer, I do.
Hi Andrew, can you be a little more specific about the potential harm you see with keeping GCJ in Fedora?
I think Rahul already answered this. Do you expect me to say something different from him?
Well, speaking of "harm", yes, I do.
Don't take me wrong. I just want to know if there is any reason beyond maintainer unwillingness/ lack of time.
Thanks, Orcan
On 03/24/2014 12:48 PM, Orcan Ogetbil wrote:
On Mon, Mar 24, 2014 at 6:02 AM, Andrew Haley wrote:
On 03/22/2014 07:51 PM, Orcan Ogetbil wrote:
On Thu, Mar 20, 2014 at 7:24 AM, Andrew Haley wrote:
On 03/19/2014 10:59 PM, Andrew Hughes wrote:>>
And JDK5 might be good enough for the use required. It doesn't claim to be anything more than that, so I don't see the harm in leaving it there.
Speaking as the upstream maintainer, I do.
Hi Andrew, can you be a little more specific about the potential harm you see with keeping GCJ in Fedora?
I think Rahul already answered this. Do you expect me to say something different from him?
Well, speaking of "harm", yes, I do.
Don't take me wrong. I just want to know if there is any reason beyond maintainer unwillingness/ lack of time.
No, I don't think there is, beyond the usual objections to leaving packages to rot.
Andrew.
On 03/06/2014 12:03 PM, Florian Weimer wrote:
On 03/06/2014 11:31 AM, Michael J Gruber wrote:
pdftk has a hard dependency on GCJ because it's a C++ program that uses a Java library (iText) through CNI. I once tried to rewrite the C++ part in Java, but the existing command line parser is quite involved, so I didn't quite get there.
Switch to pdftk version 2 doesn't change the basic architecture of the program.
(We really want to get rid of GCJ.)
What a pity that gcj (as a project) has been abandoned. Really interesting technology, now in some way reinvented many years later through Dalvik/ART.
7 years later I find this and was surprised after switching from Debian/Ubuntu. I cannot find the source or any licensing information for current versions however there are several alternatives. One which is already in the repos is pdf-stapler which is good for the basics but lacks some of the more advanced features.
Debian on the other hand now ships a port to java called pdftk-java. Maybe once I have some spare time I might look into creating a spec for it and proposing its addition to the repos.
On Thu, 2021-09-02 at 16:38 +0000, Nils K wrote:
7 years later I find this and was surprised after switching from Debian/Ubuntu. I cannot find the source or any licensing information for current versions however there are several alternatives. One which is already in the repos is pdf-stapler which is good for the basics but lacks some of the more advanced features.
Debian on the other hand now ships a port to java called pdftk-java. Maybe once I have some spare time I might look into creating a spec for it and proposing its addition to the repos.
I built it [1] with spec from opensuse [2] but we don't have gui , IIRC pdftk had a gui .
[1] https://copr.fedorainfracloud.org/coprs/sergiomb/builds_for_Stable_Releases/...
[2] https://build.opensuse.org/package/show/openSUSE%3AFactory/pdftk
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Depending on what you want to achieve, mupdf and its tools may be an option. Back then I switched impressive from pdftk to mupdf/mutool. It has python bindings, too.
As for a "swiss army knife" command line utility, qpdf is very versatile if you don't mind the learning curve. There is a gui "PDF Mix Tool" which is not in Fedora.
Alternatively, we have pdfbox in Fedora, which is a Java library including tools; and pdfjam and certainly some more.
If I remember correctly, then the licensing of the iText library which pdftk uses was the main problem in Fedora land, but I never looked back since switching away from pdftk/itext.
On Thu, 2021-09-02 at 23:29 +0100, Sérgio Basto wrote:
On Thu, 2021-09-02 at 16:38 +0000, Nils K wrote:
7 years later I find this and was surprised after switching from Debian/Ubuntu. I cannot find the source or any licensing information for current versions however there are several alternatives. One which is already in the repos is pdf-stapler which is good for the basics but lacks some of the more advanced features.
Debian on the other hand now ships a port to java called pdftk-java. Maybe once I have some spare time I might look into creating a spec for it and proposing its addition to the repos.
I built it [1] with spec from opensuse [2] but we don't have gui , IIRC pdftk had a gui .
[1]
https://copr.fedorainfracloud.org/coprs/sergiomb/builds_for_Stable_Releases/...
[2] https://build.opensuse.org/package/show/openSUSE%3AFactory/pdftk
I think the gui of pdftk that I used is pdfchain, I also built pdfchain in my copr repo [3] , if both packages works well I can unretire them .
Thank you
[3] https://copr.fedorainfracloud.org/coprs/sergiomb/builds_for_Stable_Releases/...
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 9/8/21 06:28, Sérgio Basto wrote:
I think the gui of pdftk that I used is pdfchain, I also built pdfchain in my copr repo [3] , if both packages works well I can unretire them .
Thank you
fyi, here on f34
dnf install bouncycastle rpm -Uvh \ https://download.copr.fedorainfracloud.org/results/sergiomb/builds_for_Stabl... \ https://download.copr.fedorainfracloud.org/results/sergiomb/builds_for_Stabl...
launches fine
https://i.imgur.com/NSzerXU.png
and appears to function well on initial/simple tests to concat/explode files via GUI
devel@lists.stg.fedoraproject.org
-
Andrew Haley -
Andrew Hughes -
Florian Weimer -
Jaroslav Reznik -
Joachim Backes -
Jochen Schmitt -
Kevin Kofler -
Michael J Gruber -
Michal Srb -
Nils K -
Orcan Ogetbil -
PGNet Dev -
Rahul Sundaram -
Roberto Ragusa -
Susi Lehtola -
Sérgio Basto -
Tom Callaway