Summary: | [MAINTAINER] graphics/openjump: update to 1.7.1 | ||||||
---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Rainer Hurling <rhurlin> | ||||
Component: | Individual Port(s) | Assignee: | freebsd-ports-bugs (Nobody) <ports-bugs> | ||||
Status: | Closed FIXED | ||||||
Severity: | Affects Only Me | CC: | marcus, rhurlin, wen | ||||
Priority: | Normal | Keywords: | patch | ||||
Version: | Latest | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
Attachments: |
|
Description
Rainer Hurling
2014-09-07 15:32:46 UTC
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 |