Diff looks fine. I wonder if it is a good idea to have both for some time (so that there is an easy way to the old one in case something rare is found).

The succesful build that prints a ton of Java compilation errors looks scary…

Basic functionality seems to work, I tried burst, cat with multiple files and with page selection and with rotation, stamp, background

Diff looks fine. I wonder if it is a good idea to have both for some time (so that there is an easy way to the old one in case something rare is found).

I've added a copy as pdftk-legacy, maybe after the next release that can be removed.

The succesful build that prints a ton of Java compilation errors looks scary…

It worked because those wrongly encoded chars were only in comments, I've fixed the gradle call so it's not as scary now.

I've added a copy as pdftk-legacy, maybe after the next release that can be removed.
Yes, and it could also be made loPrio (which is redundant but signals our low desire for its continued use).

I've fixed the gradle call so it's not as scary now.

Have you updated the output hash, though?

(also, @grahamc is it even possible to start detecting this on ofBorg? first build left something with the old outputHash in the store, so the new build succeeded)

I've added a copy as pdftk-legacy, maybe after the next release that can be removed.

Yes, and it could also be made loPrio (which is redundant but signals our low desire for its continued use).

I've added the lowPrio () wrapping

I've fixed the gradle call so it's not as scary now.

Have you updated the output hash, though?

That is not needed, because those comments have no effect on the output jar.

(also, @grahamc is it even possible to start detecting this on ofBorg? first build left something with the old outputHash in the store, so the new build succeeded)

Good point, also maybe now I'm breaking auto-updates via bot with this pattern?

Good point, also maybe now I'm breaking auto-updates via bot with this pattern?

Hm, I think so. Maybe this fixed-output doesn't pay off in this case…

Also, maybe add youself as a maintainer?

Ok, I double checked, ryantm actually uses TOFU :) https://github.com/ryantm/nixpkgs-update/blob/1aa24ed735ab8ce504eaa79ae34a93fe40ff230a/src/Update.hs#L188

If it looks good to you we could merge, I might be adding this way of building to other gradle derivations.

As pointed out here, java-compiler upgrades would break this, so going back to the old perl-patchery stuff.

I would just drop the old pdftk - it is unmaintained, right? No need to have both available.

Furthermore I would rename it to pdftk-java and add an alias from pdftk to pdftk-java in pkgs/top-level/aliases.nix

@Mic92 it is unmaintained but working and its domain area is not exactly changing match; the port's upstream says they are not yet fully confident in the port.

@7c6f434c I would not call it -legacy in that case but keep the old name than and name the new one pdftk-java. This should avoid confusion. I still have a hard time to believe there have been no bugs accumulated in the last 6 years since the last release of pdftk.

Given this is a semiauto port, and pdftk requires gcj requiring old gcc, I prefer the middle road of moving the old version to legacy for some time.

The old pdftk definitely has not accumulated any bugs in the last 6 years, there are of course a few cornercase bugs discovered in the past 6 years, but the port hasn't yet fixed all of them, and has definitely added a few minor bugs of its own (some of those have been fixed already, but who knows how many remain).