Abandoned upstream, a new active fork is located here: https://github.com/leahneukirchen/netpbm-mirror/tree/advanced Please have look of this is something we can adopt
Hum... No issues or pull requests. How old is this fork?
I must've been a bit sleepy looking at this, it's a git export of https://sourceforge.net/p/netpbm/code/HEAD/tree/advanced/ which seems to be upstream repo (also by looking at https://github.com/t6/netpbm/ ) Best regards, Daniel
@tobik has solved this for now by aiming MASTER_SITES at LOCAL/tobik.
It's not fixed, it uses the same outdated snapshot as before but at a new location.
Hi, the only thing I solved is being able to delete the repository without breaking the port. ;-) t6/netpbm was never a proper mirror just an SVN export + pregenerated manuals. I recommend you setup your own git-svn based mirror (if unlike me you can be bothered to learn git-svn), or use the one Daniel mentioned. Probably would be good to ask/inform the repository maintainer first though. It's used by Void Linux: https://github.com/void-linux/void-packages/blob/master/srcpkgs/netpbm/template Netpbm doesn't put out "advanced" release tarballs. Using the "super stable" tarballs mean you fall behind Linux distributions again (i.e., you'll have missing features in FreeBSD's netpbm compared to Linux at some point etc). See http://netpbm.sourceforge.net/getting_netpbm.php The port is pretty outdated. The netpbm-version-check and netpbm-fetch targets are also broken since they still reference svnlite. FWIW, the script I used to update it and the netpbm-userguide and netpbm repositories themselves are "archived" on freefall in ~tobik/archive. Best regards, Tobi
There's also https://github.com/ceamac/netpbm-make-dist which might be a bit more distro friendly
What do people think about this: https://sourceforge.net/projects/netpbm/ I took a run at updating the port but I totally do not understand sourceforge vs. the FreeBSD ports system...
Created attachment 244644 [details] patch Here's where I'm at with this. This builds with the option configurations that remain. Remove MANPAGES (no longer included). Remove PERL (now unconditinally dependant on perl). Remove STATIC (does not build because graphics/jasper no longer installs a static library). I'd appreciate feedback on this version.
Why is GH_TUPLE used? We should probably use ceamac repo due to GitHub's recent policy change. https://docs.freebsd.org/en/books/porters-handbook/book/#makefile-master_sites-github (see warning entry)
Created attachment 244699 [details] revised patch I didn't know GH_TUPLE had fallen out of grace. Here's a new version that knows how to build a distro tarball directly from sourceforge and then fetch it from MASTER_SITES=LOCAL/... I think this is how we want to go, clearly there are other ports that are similar.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=170ff4fd76b063773fe573ede552bd9028e7afb7 commit 170ff4fd76b063773fe573ede552bd9028e7afb7 Author: Craig Leres <leres@FreeBSD.org> AuthorDate: 2023-09-10 17:42:40 +0000 Commit: Craig Leres <leres@FreeBSD.org> CommitDate: 2023-09-10 17:42:40 +0000 graphics/netpbm: Switch to 11.03.05 (advanced train) from sourceforge The sourceforge repo does not create actual releases, instead they to commit to stable and advanced branches. So build one using svn/tar and distribute via MASTER_SITES=LOCAL/... (Crib do-fetch logic from graphics/yukon and devel/libopenbsd.) Remove MANPAGES option (no longer included). Remove PERL option (we're now unconditionally dependant on perl). Remove STATIC option (does not build because graphics/jasper no longer installs a static library). Reported by: diizzy PR: 262212 graphics/netpbm/Makefile | 142 +++---- graphics/netpbm/distinfo | 6 +- .../files/patch-converter_other_pstopnm.c (gone) | 14 - graphics/netpbm/pkg-plist | 434 +-------------------- 4 files changed, 73 insertions(+), 523 deletions(-)
Great thanks! I would trying to avoid reinventing the wheel and piggy but that your solution also works just as good. I guess it's a matter of preference but Sourceforge also supports https for svn access which may be a bit more compatible with restrictive firewalls. Best regards, Daniel
I'll switch to https for the next update. I appreciate your patience leading me to this solution.
This made the man pages go away. Will they come back?