Created attachment 147013 [details] Updates graphics/openjump to 1.7.1 Update from version 1.6.3 to 1.7.1: Many improvements and bug fixes like + PostGIS plugin gives writable access to databases + PDF printing capability, and and and, see http://sourceforge.net/projects/jump-pilot/files/OpenJUMP/1.7.1/ The port does - Update to recent version - Correct license - Improvements of the startup shell script (diagnostic 'echo comments' are intentional) - Enable displaying memory management in 'About:Information' - Move readme.txt to enable showing in the programs 'About:About' dialog The port is tested on RedPorts (including QATty and EXP1): [1] https://redports.org/buildarchive/20140907133411-02782 [2] https://redports.org/buildarchive/20140907135644-82874
Great submission Rainer! Also attach: * portlint -AC output (after addressing any outstanding issues)
Thanks, Kubilay. Here it is: #portlint -AC WARN: Makefile: possible direct use of "files" " @${ECHO_CMD} "---> Installing JAR files"" found. if so, use ${FILESDIR} instead. WARN: Makefile: for new port, make $FreeBSD$ tag in comment section empty, to make SVN happy. 0 fatal errors and 2 warnings found. The first warning I was aware of. But I think the message is worth this warning?
(In reply to Rainer Hurling from comment #2) > The first warning I was aware of. But I think the message is worth this > warning? First one is technically a false positive Q: Should ECHO_CMD messages be except from string match rules? Adding portlint maintainer for expertise. The second may be related to the method by which you update ports: Are you using an SVN ports tree, or do you copy a port directory somewhere, change it, and diff back to original in a standalone and manual manner?
My method is very ancient. I am using own copies of my "upcoming" port versions within the regulary svn ports tree, without registering them into svn. All is manual and it works for years now without problems. I know this can be done better ;)
If you're interested, let's get you onto modifying an upstream ports tree (via a mirror), so you can unlock the following achievements: * renaming or deleting a port (requires category/Makefile modifications) * Adding a port (with related category/Makefile addition) It's not at all a different from your current workflow from a standalone port poinrt of view, with changes within a single directory, and there a couple of other benefits to be had :) Basically the only the that's different is you maintain a second 'dev' tree rather than utilising usr/ports, and you use svn diff to produce patches.
Sounds interesting. At the moment, with my testings on RedPorts, I am using some kind of a second svn tree on my systems. Of course, without the possibility of modifying categories and higher-level Makefiles. And because of this, without the risk of breaking anything in the 'real' ports world. Is there any document, I can read about?
A commit references this bug: Author: wen Date: Wed Oct 1 10:58:44 UTC 2014 New revision: 369712 URL: https://svnweb.freebsd.org/changeset/ports/369712 Log: - Update to recent version - Correct license - Improvements of the startup shell script (diagnostic 'echo comments' are intentional) - Enable displaying memory management in 'About:Information' - Move readme.txt to enable showing in the programs 'About:About' dialog PR: 193430 Submitted by: Rainer Hurling<rhurlin@gwdg.de>(maintainer) Changes: head/graphics/openjump/Makefile head/graphics/openjump/distinfo head/graphics/openjump/files/patch-bin__oj_linux.sh head/graphics/openjump/pkg-plist