The sysutils/respond port suffers severe bitrot. It did not keep up with changes to SourceForge (its homepage was automatically removed) or the port build system. As it does not look like anyone ever used it (besides me: the author and maintainer), I do not consider it worthwhile to refresh the port and implement the necessary staging updates. The source code of respond remains available at https://github.com/joukewitteveen/respond. Fix: removal of the port altogether
Jouke, the port has now been staged as of r359583 [1], with a patch added to the source Makefile, which adds DESTDIR support: http://svnweb.freebsd.org/ports?view=revision&revision=359583 I would be happy to work with you to update your port to use the github sources (if no longer available on sourceforge). All we'll need is a tag for the 2.1 release. Would you like to update this removal request to go for that instead?
Sounds great! Unbelievable that all these nasty errors are gone with so little modifications to the port Makefile. I will get to tagging a release shortly.
Update summary with latest information.
Created attachment 144422 [details] Update to 1.3 and move to GitHub
The GH macros dazzled me. I hope this is correct. Please review and apply. Thanks a lot for your help Kubilay Kocak!
You're welcome :) For the Github bits, have a look the GH_* variables in /usr/ports/Mk/bsd.sites.mk With those bits, you dont need MASTER_SITES, DISTNAME, DISTFILES or WRKSRC overrides. If you get stuck, just let me know and I can take it from here. Rest of the patch looks good, does it pass portlint and port test? (from ports-mgmt/porttools)
Created attachment 144424 [details] Update to 1.3 and move to GitHub (using macros) This one uses the GH_ macros, which mandate specification of a commit hash.
The previous MASTER_SITES= value was taken from /usr/ports/Mk/bsd.sites.mk ("GitHub [...] without the need for any of the above"). I don't understand why the macros necessitate the specification of a hash. The revised version passes all tests.
The hash is used to derive a value WRKSRC, as the tarball contains a directory containing the hash string :)
Latest patch looks good, I'll test & commit this tomorrow morning. Great work
The 'ordinary' release tarball from GitHub (which the previous patch used) does not include the hash. I don't understand the logic behind the codeload.github/cloud.github downloads and the inclusion of the hash. If you do and it is simple to explain, please do. In any case, thanks for your guidance!
Not all projects use 'releases' or consistent naming conventions. Every account/repository on the other hand can have a tarball created/fetched via tag or hash name consistently using that system. Consider it a very solid baseline that does most if not all of the work for you.
A commit references this bug: Author: koobs Date: Mon Jul 7 04:44:08 UTC 2014 New revision: 361021 URL: http://svnweb.freebsd.org/changeset/ports/361021 Log: sysutils/respond: Update to 1.3, Add LICENSE - Update to 1.3 - Switch to GITHUB for distribution files - Add LICENSE (BSD2CLAUSE) - Remove patch-Makefile (upstreamed) - pkg-descr: Update WWW: URL Changes: https://github.com/joukewitteveen/respond/blob/1.3/NEWS PR: 191434 Submitted by: Jouke Witteveen (maintainer) Changes: head/sysutils/respond/Makefile head/sysutils/respond/distinfo head/sysutils/respond/files/ head/sysutils/respond/pkg-descr
All sorted Jouke, thanks for the effort you put in :)