Created attachment 157224 [details] Proposed patch (since 383856 revision) Patch to update games/oolite port from 1.80 to 1.82 version. Look following links for changes: https://github.com/OoliteProject/oolite/blob/1.82/Doc/CHANGELOG.TXT https://github.com/OoliteProject/oolite/releases/tag/1.82 http://aegidian.org/bb/viewtopic.php?f=1&t=17481 - Convert to USES=gnustep - Use compiler from ports in case of LLVM/Clang v3.4.1, because of errors - Wrap cd related commands to parentheses - Remove patches, which were fixed upstream - Adapt patches in files directory, after ports r383894 changes for ports-mgmt/portlint v2.16.3
Comment on attachment 157224 [details] Proposed patch (since 383856 revision) The proposed patch uses workaround for current USES=gnustep implementation inside of the port, which explained in bug 199503, comment #3. The patch for Mk/Uses/gnustep.mk file is not applied to this time to use previous approach.
Created attachment 157225 [details] The poudriere testport log (FreeBSD 10 amd64)
Created attachment 157226 [details] The poudriere testport log (FreeBSD 9.3 amd64)
Created attachment 157227 [details] The poudriere testport log (FreeBSD 8.4 amd64)
*** Bug 199503 has been marked as a duplicate of this bug. ***
Hi, Thanks for your submission. I'm testing your patch and will commit it once I'm done. I have taken a look at the gnustep USES but am really not in the position to make a decision about the changes you ask for. You'll have to find some consensus on the mailing lists, asking for opinions from people more expert about gnustep in the ports tree than me for that to happen. Since the previous maintainer(who deserves thanks for previous work and having reviewed this submission) has resigned, are you interested in taking maintainership for this port?
Hello, Guido Falsi. (In reply to comment #6) > I'm testing your patch and will commit it once I'm done. Ok. In the bug 193886 (for v1.80) I (or we) decided to use -Os optimization compiler option, but it doesn't work for LLVM/Clang 3.4.1 currently. Therefore, I chose to use LLVM/Clang 3.4.x compiler from ports in this case (also). (In reply to comment #6) > I have taken a look at the gnustep USES but am really not in the position to > make a decision about the changes you ask for. You'll have to find some > consensus on the mailing lists, asking for opinions from people more expert > about gnustep in the ports tree than me for that to happen. I contacted the people, which may be responsible about broken status of the port (bapt@ and antoine@) through e-mail, where I explained the problem and pointed to the bug 199503. The bapt@ responded on 17 April 2015, but no changes in PR still. Therefore, I chose to use a workaround, including for new release version. (In reply to comment #6) > Since the previous maintainer(who deserves thanks for previous work and > having reviewed this submission) has resigned, Yes, I'm aware about this. Thanks to Andriy Gapon about review(s) of the mentioned PRs, creation of the port and the maintainership. (In reply to comment #6) > are you interested in taking maintainership for this port? No, I just interested in concrete available update.
(In reply to lightside from comment #7) Regarding the change to gnustep uses, you should propose the change you want to apply to the file in it's own PR explaining why the change is needed. An exp-run will be required. Regarding maintainership, you have no obligation to become maintainer, obviously, I just had to ask if you were interested. I'm almost done with testing, will commit this one soon. Thanks.
(In reply to comment #8) > Regarding the change to gnustep uses, you should propose the change you want > to apply to the file in it's own PR explaining why the change is needed. Actually, the PR you talked about is bug 199503, which you closed yesterday. There was proposed a possible changes for Mk/Uses/gnustep.mk file with its application for games/oolite port (v1.80). Basically, I just re-added what was removed in older Mk/bsd.gnustep.mk file, which allowed to build games/oolite port with "USES=gnustep" and "USE_GNUSTEP=base build", like other converted ports: Reference for USE_MAKEFILE: https://svnweb.freebsd.org/ports/head/Mk/bsd.gnustep.mk?view=markup&pathrev=383625#l104 Reference for GNUSTEP_LOCAL_APPS: https://svnweb.freebsd.org/ports/head/Mk/bsd.gnustep.mk?view=markup&pathrev=383625#l150 The involved people (which are ports managers and they are CC) was informed through email on the day of PR creation (and way before, just for note). Also, it was in a mailing list(s), because of freebsd-ports-bugs assignee. I planned to close the bug 199503 in case of this PR completion or create a new patch in other case. (In reply to comment #8) > An exp-run will be required. I think, this is not needed, because there are no USE_MAKEFILE define(s) for converted (and other) ports to USES=gnustep and for files inside of Mk ports directory. (In reply to comment #8) > Regarding maintainership, you have no obligation to become maintainer, > obviously, I just had to ask if you were interested. I understood. Thanks for asking. I had experience with maintainership and related issues. There are no much difference, if you need to propose patch(es) through PR system, except other responsibility, which may be not related to the port itself. (In reply to comment #8) > I'm almost done with testing, will commit this one soon. Ok. Thanks for your attention.
(In reply to lightside from comment #9) I closed bug 199503 and marked it as duplicate of this one since I thought this one superceded it. My suggestion is to create a specific PR for gnustep.mk, with a title mentioning it and not bound to a single port. Anyway I did not mean to destroy your work by closing it. If you want to just mail me privately and I can reopen it.
A commit references this bug: Author: madpilot Date: Fri Jun 5 23:26:14 UTC 2015 New revision: 388647 URL: https://svnweb.freebsd.org/changeset/ports/388647 Log: - Update to 1.82 - Convert to USES gnustep and unbreak - Regenerate patches to silence portlint warnings PR: 200496 Submitted by: lightside at gmx.com Changes: head/games/oolite/Makefile head/games/oolite/distinfo head/games/oolite/files/patch-deps_mozilla-bug771281 head/games/oolite/files/patch-deps_mozilla_js_src_configure head/games/oolite/files/patch-deps_mozilla_js_src_configure.in head/games/oolite/files/patch-deps_mozilla_js_src_jsscript.h head/games/oolite/files/patch-deps_mozilla_js_src_jsstr.cpp head/games/oolite/files/patch-src_Core_Materials_OOPNGTextureLoader.m head/games/oolite/files/patch-src_Core_OOMaths.h head/games/oolite/files/patch-src_Core_OOOXZManager.m head/games/oolite/files/patch-src_Core_OOPointMaths.h
Committed. Thanks!
(In reply to comment #10) > I closed bug 199503 and marked it as duplicate of this one since I thought > this one superceded it. This is ok, in case of this PR completion. I think, the comment about DO_MAKE_BUILD is self-explanatory (in addition to related PR): https://svnweb.freebsd.org/ports/head/games/oolite/Makefile?annotate=388647&pathrev=388647#l32 There are other possible solutions for this case (for example, USE_GNUSTEP=makefile instead of USE_MAKEFILE), but they might need to involve ports managers, where there is a "timeout situation" already. Thanks for commit.