Bug 195014
|
Description
lightside
2014-11-14 17:24:38 UTC
Created attachment 149409 [details]
The poudriere testport log (FreeBSD 10 amd64)
Created attachment 149410 [details]
The poudriere testport log (FreeBSD 9.3 amd64)
Created attachment 149411 [details]
The poudriere testport log (FreeBSD 8.4 amd64)
To commiter/portmgr: Consider adding following line to port's Makefile: MANUAL_PACKAGE_BUILD= yes because of extensive use of resources on creation of the package. Created attachment 149412 [details] Patch to increase a number of joystick buttons to 98 In case, somebody uses a joystick with more than 32 buttons, there is a patch to increase a number of buttons to 98: http://scp.indiegames.us/mantis/view.php?id=2651 but I didn't include it to the port, because of following forum's discussion: http://www.hard-light.net/forums/index.php?topic=88047.0 Still, if you need it, I included it to this bug report. You could place it to the port's files directory. Created attachment 149413 [details]
The port in shar format (with extra patch)
I added mentioned patch as EXTRA_PATCHES, which could be enabled by using INCJOYBTNS option.
Created attachment 149416 [details]
The port in shar format (with extra patch)
Fixed some typos.
Created attachment 149428 [details]
The port in shar format (with extra patch). Another version
There is another way to run fs2_open_diaspora executable by changing current directory before running it, instead of using the patch for fixed DATADIR directory. So, it might be possible to use the same executable to run from other data directories specified by the user.
The dependencies are the same. The "make check-plist" result is follows:
====> Checking for pkg-plist issues (check-plist)
===> Parsing plist
===> Checking for items in STAGEDIR missing from pkg-plist
===> Checking for items in pkg-plist which are not in STAGEDIR
===> No pkg-plist issues found (check-plist)
The only complaint I have with a quick review is this line: Xpost-install: .SILENT Why ".SILENT" ? We specifically want all install commands (other than mkdir) to be shown on logs. This would prevent that. Created attachment 149435 [details] The port in shar format (with extra patch). Another version Hello John Marino. (In reply to John Marino from comment #9) > Why ".SILENT" ? Mainly, because of TMPPLIST generation commands on post-install stage. I removed it for post-install stage on your request. Other than this, the attached logs are still valid. And portlint output: # cd diaspora && portlint -AC . looks fine. I can see the argument for it. How many @dir lines are we talking about? The general guideline is not to use autogen plist unless there is a really good reason (e.g. 20,000 line pkg-plist). If we are talking like 10 @dirrm lines, I'd rather just move PLIST_FILES to pkg-plist and add @dir lines statically. I guess, we are talking about following command:
cd ${WRKDIR_DIASPORA} && ${FIND} data -type d -empty | ${SORT} |\
${XARGS} -L 1 -I '{}' ${ECHO_CMD} "@dir ${DATADIR}/{}"\
>> ${TMPPLIST}
From my point of view, the good reason about using dynamic generation package list is adaptation for contents of the package, if there is a possible case for different contents of files (and/or directories) from version to version. Since, I created this port, it is my choose to use static package list inside of pkg-plist file or Makefile with PLIST_FILES. I choose PLIST_FILES and PORTDATA, PORTDOCS facilities.
The empty directories is a different case, related to stage capabilities, where it choose not to use empty directories, where they might be needed. To overcome this, I made following command (converted to show a real case):
# cd Diaspora_R1_Linux/Diaspora && find data -type d -empty | sort | xargs -L 1 -I '{}' echo "@dir /usr/local/share/{}"
Its current result is follows:
@dir /usr/local/share/data/Info
@dir /usr/local/share/data/cache
@dir /usr/local/share/data/cbanims
@dir /usr/local/share/data/config
@dir /usr/local/share/data/effects
@dir /usr/local/share/data/fonts
@dir /usr/local/share/data/force feedback
@dir /usr/local/share/data/hud
@dir /usr/local/share/data/intelanims
@dir /usr/local/share/data/interface
@dir /usr/local/share/data/maps
@dir /usr/local/share/data/missions
@dir /usr/local/share/data/models
@dir /usr/local/share/data/multidata
@dir /usr/local/share/data/music
@dir /usr/local/share/data/players/images
@dir /usr/local/share/data/players/multi/inferno
@dir /usr/local/share/data/players/single/inferno
@dir /usr/local/share/data/players/squads
@dir /usr/local/share/data/scripts
@dir /usr/local/share/data/sounds
@dir /usr/local/share/data/tables
@dir /usr/local/share/data/voice/briefing
@dir /usr/local/share/data/voice/command_briefings
@dir /usr/local/share/data/voice/debriefing
@dir /usr/local/share/data/voice/personas
@dir /usr/local/share/data/voice/special
But since I use ">> ${TMPPLIST}" additional command at the end, this output will be redirected and added to the ${TMPPLIST} file and will not be shown to the user.
Some additional comment: Of course, the Makefile's command will generate "/usr/local/share/diaspora" for DATADIR, not a "/usr/local/share", used for example. (In reply to lightside from comment #12) > From my point of view, the good reason about using dynamic generation > package list is adaptation for contents of the package, if there is a > possible case for different contents of files (and/or directories) from > version to version. But this is exactly why autogen is frowned upon -- it adapts to the differences and that can cause surprises when changes are obscured, especially between platforms. Since we are only talking about a pkg-plist of about 30 lines, I think this should be converted to the static pkg-plist file. Created attachment 149457 [details] The port in shar format (In reply to John Marino from comment #14) > But this is exactly why autogen is frowned upon -- it adapts to the > differences and that can cause surprises when changes are obscured, > especially between platforms. Since we are only talking about a pkg-plist > of about 30 lines, I think this should be converted to the static pkg-plist > file. I meant, it adapts to differences of the package contents, which is based on contents of the distfiles, in case there are new or deleted files in specified directories. The files are installed in correct places, specified at package creation or manual build time. About the pkg-plist discussion: I think, this is a maintainer/creator's choice. The static pkg-plist or PLIST_FILES are correct choices, because they lead to the same result: correctly installed port. The logs shows correct results for current method. I don't intend to change it because of "count of files" argument. Even if there was only one file, e.g. bin/fs2_open_diaspora inside of PLIST_FILES or pkg-plist file are correct choices. Do you talk about the platforms, which are not working, may be? I tested it on amd64 only. If this port will not work for some platform, the commiter could specify these restrictions later. Moreover, I suggested to add MANUAL_PACKAGE_BUILD=yes to Makefile, because of the size of the distfiles/package and resources they use by extract/creation stage(s). I didn't include it, because of poudriere testport logs. By the way, I specified README*.txt files instead of just *.txt inside of ${WRKDIR} directory for copy to ${STAGEDIR}${DOCSDIR} directory in the new attached shar file. (In reply to lightside from comment #15) > I meant, it adapts to differences of the package contents, which is based on > contents of the distfiles, in case there are new or deleted files in > specified directories. The files are installed in correct places, specified > at package creation or manual build time. I know what you meant. We could easily remove every pkg-plist in the entire tree and have it autogen'd based on what is in the stage. Then it would "adapt" to every new version without breaking the port. But we don't do that -- there's a reason. > > About the pkg-plist discussion: > I think, this is a maintainer/creator's choice. The static pkg-plist or > PLIST_FILES are correct choices, because they lead to the same result: > correctly installed port. That's a claim you can't back up. By definition, every build will be "correctly installed". Without a manifest, there's nothing to check again, so nobody can verify if it's installed correct or not. Maintainer's don't really have the freedom to do something against policy. Personally, I'm not going to approve an autogen list for this port. Maybe somebody else will. > The logs shows correct results for current method. > I don't intend to change it because of "count of files" argument. Even if > there was only one file, e.g. bin/fs2_open_diaspora inside of PLIST_FILES or > pkg-plist file are correct choices. count of files kicks in at like 5,000 files, not 30. > Do you talk about the platforms, which are not working, may be? I tested it > on amd64 only. If this port will not work for some platform, the commiter > could specify these restrictions later. Moreover, I suggested to add > MANUAL_PACKAGE_BUILD=yes to Makefile, because of the size of the > distfiles/package and resources they use by extract/creation stage(s). I > didn't include it, because of poudriere testport logs. The point is a manifest is needed to detect issues, and issues are more likely to happen on platforms you didn't check. no manifest means every port passes by default, even if it's missing files or has extra files which can easily occur. > By the way, I specified README*.txt files instead of just *.txt inside of > ${WRKDIR} directory for copy to ${STAGEDIR}${DOCSDIR} directory in the new > attached shar file. If you aren't going to change this submission, it's up to you. I'll just remove myself off of CC and you can hope the next guy that reviews it thinks it's okay. I guess your chances of that are okay because it's only empty directories you are autogenning and in the end that is not as critical as files. (In reply to John Marino from comment #16) > The point is a manifest is needed to detect issues, and issues are more > likely to happen on platforms you didn't check. no manifest means every > port passes by default, even if it's missing files or has extra files which > can easily occur. This port builds only one file: fs2_open_diaspora, which is known and specified at configure stage. The distifle contents is also known and didn't change, while distinfo is correct for distfiles. If distinfo is changed, the maintainer will need to check plist issues again, regardless of the method used. The port also control the do-install stage. (In reply to John Marino from comment #16) > If you aren't going to change this submission, it's up to you. I'll just > remove myself off of CC and you can hope the next guy that reviews it thinks > it's okay. I guess your chances of that are okay because it's only empty > directories you are autogenning and in the end that is not as critical as > files. Well, if you want to check issues of this port, you will need to check attached logs, check-plist and portlint results, which means to use poudriere (or tinderbox), either just install/deinstall the port (and games/wxlauncher, which is needed from 195013 bug report). But beware, this might take many hours (depending from the test method used and hardware capabilities). I did it and I know what I talking about. Personally, I used dynamic package list generation for many ports and they are still works. (In reply to lightside from comment #17) > If distinfo is changed, the > maintainer will need to check plist issues again, regardless of the method > used. The port also control the do-install stage. If the distfile changes and the maintainer *doesn't* check the plist, it will pass even if the empty directories change. So nothing forces the maintainer to actually check -- only if a new file gets install would a problem be detected by qa checks. > Well, if you want to check issues of this port, you will need to check > attached logs, check-plist and portlint results, which means to use > poudriere (or tinderbox), either just install/deinstall the port (and > games/wxlauncher, which is needed from 195013 bug report). But beware, this > might take many hours (depending from the test method used and hardware > capabilities). I did it and I know what I talking about. You're missing the point. If there is a static manifest (pkg-plist), anybody can run QA checks on any platform and be confident what is installed is what the maintainer intended. This is impossible for ports with autogen plists. > > Personally, I used dynamic package list generation for many ports and they > are still works. dynamic plists are scrutinized now. I would wager if this "many ports" are still active today, many would face recommendations to convert them to a static pkg-plist. Of course, I'm just guessing without having seen these ports. I acknowledge this is a very low-risk port in any case. I'll promote the PR to the next level with a static plist. If you insist on a dynamic plist then I'll let someone else promote it. Created attachment 149465 [details] The port in shar format (In reply to John Marino from comment #18) > If the distfile changes and the maintainer *doesn't* check the plist, it > will pass even if the empty directories change. So nothing forces the > maintainer to actually check -- only if a new file gets install would a > problem be detected by qa checks. Actually, I tested the port (poudriere testport) without using empty directories package list generation at first and I got stage-qa issue about stage directories not in a package list. These directories might be important for users, if they wanted to add files to them (either by root privileges or copy/link the share/diaspora directory to a different location). Therefore, I added dynamic generation for empty directories to ${TMPPLIST}. After this, the stage-qa was ok: ====> Running Q/A tests (stage-qa) ====> Checking for pkg-plist issues (check-plist) ===> Parsing plist ===> Checking for items in STAGEDIR missing from pkg-plist ===> Checking for items in pkg-plist which are not in STAGEDIR ===> No pkg-plist issues found (check-plist) ====>> Checking for staging violations... done After discussion, I changed the generation of empty directory list to the following command: cd ${STAGEDIR}${DATADIR} && ${FIND} data -type d -empty | ${SORT} |\ ${XARGS} -L 1 -I '{}' ${ECHO_CMD} "@dir ${DATADIR}/{}"\ >> ${TMPPLIST} The ${STAGEDIR}${DATADIR} is more appropriate place. In the next message I will attach the ${WRKDIR} directory archive of the files after "make check-plist" command. It contains .* hidden files, which you could examine about correctness, especially .PLIST.mktmp, .plist-dirs-sorted-no-comments, .plist-files-no-comments. (In reply to John Marino from comment #18) > I acknowledge this is a very low-risk port in any case. I'll promote the PR > to the next level with a static plist. If you insist on a dynamic plist > then I'll let someone else promote it. I understood. I just think that my method is also correct. Moreover, I have documented results of it written to logs, which is about 3 hours of computer time (because of package generation) for three FreeBSD versions, not counting undocumented computer time for correct result, even on one FreeBSD version. The easy way to check this is just install the port, then find empty "/usr/local/share/diaspora/data" directories, next deinstall the port and find that there is no "/usr/local/share/diaspora" directory, e.g.: # portmaster -Bd games/diaspora # find /usr/local/share/diaspora/data -type d -empty | sort # pkg delete -x diaspora # ls /usr/local/share/diaspora What I could offer is another poudriere testport log of current changes for FreeBSD 10 amd64 version. Created attachment 149466 [details]
Diaspora ${WRKDIR} directory files (including hidden files)
Created attachment 149467 [details]
The poudriere testport log (FreeBSD 10 amd64)
(In reply to lightside from comment #19) > What I could offer is another poudriere testport log of current changes for > FreeBSD 10 amd64 version. You're not addressing the real concern which is that we want dynamic plists to be limited to either ports mechanisms (e.g. python's auto plist), ports with extremely long manifests (5000 - 35000 lines or more), or ports with a zillion options where it's hard to get a static plist correct with all the permutations. This port doesn't fit into those three categories. I think your main motivation is to ease maintenance of this port for future versions and that's at direct odds with policy, which doesn't want these changes to be adjusted for. But in the end, what you are doing isn't any different than putting PORTSDOCS=* so I will begrudingly accept this with the following change: compound commands like X cd ${WRKDIR_DIASPORA} && ${COPYTREE_SHARE} "*.pdf *.rtf README.txt" \ X ${STAGEDIR}${DOCSDIR} need to be wrapped in parentheses like X (cd ${WRKDIR_DIASPORA} && ${COPYTREE_SHARE} "*.pdf *.rtf README.txt" \ X ${STAGEDIR}${DOCSDIR}) Fix those and I'll promote it. Created attachment 149500 [details] The port in shar format (In reply to John Marino from comment #22) > I think your main motivation is to ease maintenance of this port for future > versions Yes, this is one of the reasons. The correct manifest exists inside of created package and correct ${TMPPLIST} could be gathered after regular make (usually, inside of ${WRKDIR} directory), either you operate on fake-pkg automation, which is not a fault of maintainer. (In reply to John Marino from comment #22) > But in the end, what you are doing isn't any different than putting > PORTSDOCS=* so I will begrudingly accept this with the following change: > > compound commands like > > X cd ${WRKDIR_DIASPORA} && ${COPYTREE_SHARE} "*.pdf *.rtf README.txt" \ > X ${STAGEDIR}${DOCSDIR} > > need to be wrapped in parentheses like > > X (cd ${WRKDIR_DIASPORA} && ${COPYTREE_SHARE} "*.pdf *.rtf README.txt" \ > X ${STAGEDIR}${DOCSDIR}) > > Fix those and I'll promote it. Ok, I fixed it for new shar file, after some checks. Thanks for your attention. okay, thanks. Promoting as promised. Created attachment 149580 [details] The port in shar format Added following mirror for Diaspora_R1_Linux.tar.lzma file: http://www.freespacemods.net/download.php?view.858 Created attachment 149659 [details]
The poudriere testport log (FreeBSD 10 i386)
Comment on attachment 149580 [details] The port in shar format The port quality is already good but there're a few minor nits: >XLICENSE_NAME_CCBYNCSAv3= Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported license CCbyNCSA3 spelling is more common under games/. >XSPEECH_CONFIGURE_ON= --enable-speech Use SPEECH_CONFIGURE_ENABLE=speech unless --disable-speech is broken. >X.if ${PORT_OPTIONS:MINCJOYBTNS} >XEXTRA_PATCHES= ${FILESDIR}/extra-patch-increase_joy_buttons_fixed.patch >X.endif Can you leverage option helpers? INCJOYBTNS_EXTRA_PATCHES=${FILESDIR}/extra-patch-increase_joy_buttons_fixed.patch >Xpost-install: >X# Add empty directories to TMPPLIST >X (cd ${STAGEDIR}${DATADIR} && ${FIND} data -type d -empty | ${SORT} |\ >X ${XARGS} -L 1 -I '{}' ${ECHO_CMD} "@dir ${DATADIR}/{}"\ >X >> ${TMPPLIST}) Nowadays, pkg-delete(8) removes empty dirs under PREFIX automatically but even before that PORTDATA added @dirrm recursively. One may want @dir the game doesn't run without *some* empty directories or if some of the data is mutable (games group) but cannot live under /var/games. >X.if ${PORT_OPTIONS:MWXLAUNCHER} >X# Create a symbolic link and add it to TMPPLIST, which used by launcher >X ${LN} -sf ${PREFIX}/libexec/fs2_open_${PORTNAME} ${STAGEDIR}${DATADIR} Why ${LN} line here and not under do-install? It's perfectly legal to make links to non-existing files. /etc/malloc.conf is notorious example. >X ${ECHO_CMD} ${DATADIR}/fs2_open_${PORTNAME} >> ${TMPPLIST} Why not replace with PLIST_FILES ? >sed 's/^X//' >diaspora/files/extra-patch-increase_joy_buttons_fixed.patch << 'd26dbe503c4133ddd5e224c46d369bc0' >XIndex: code/controlconfig/controlsconfigcommon.cpp >X=================================================================== >X--- code/controlconfig/controlsconfigcommon.cpp (revision 8781) >X+++ code/controlconfig/controlsconfigcommon.cpp (working copy) Can you include a comment about origin of the patch? It may help track upstreaming state for the next maintainer. (In reply to Jan Beich from comment #27) >>Xpost-install: >>X# Add empty directories to TMPPLIST >>X (cd ${STAGEDIR}${DATADIR} && ${FIND} data -type d -empty | ${SORT} |\ >>X ${XARGS} -L 1 -I '{}' ${ECHO_CMD} "@dir ${DATADIR}/{}"\ >>X >> ${TMPPLIST}) > > Nowadays, pkg-delete(8) removes empty dirs under PREFIX automatically > but even before that PORTDATA added @dirrm recursively. Ah, reading comment 12 the Makefile should probably explain "why" instead of "what": # Keep empty dirs to help with system-wide customization Created attachment 150544 [details] The port in shar format Hello, Jan Beich. (In reply to Jan Beich from comment #27) > CCbyNCSA3 spelling is more common under games/ It's more common to use CC BY-NC-SA 3.0: http://creativecommons.org/licenses/by-nc-sa/3.0/deed or CC BY NC SA: http://en.unesco.org/open-access/terms-use-ccbyncsa-en I use capital chars for port's licenses (except for (v)ersion, to distinguish it, as for GPLv2, etc.). Not sure why others started to do otherwise. It's ok in my case and on the following image: https://licensebuttons.net/l/by-nc-sa/3.0/88x31.png The BY here means Attribution, this is not just an adverb or preposition. (In reply to Jan Beich from comment #27) > Use SPEECH_CONFIGURE_ENABLE=speech unless --disable-speech is broken. It's disabled by default for configure, but ok. (In reply to Jan Beich from comment #27) > Nowadays, pkg-delete(8) removes empty dirs under PREFIX automatically > but even before that PORTDATA added @dirrm recursively. The PORTDATA and current stage capabilities doesn't use empty directories, but warning about them on stage-qa (make check-plist), if they exists and not added to package list. (In reply to Jan Beich from comment #28) > Ah, reading comment 12 the Makefile should probably explain "why" instead of "what": > # Keep empty dirs to help with system-wide customization I added the "required" word. This is "what" and "why" in the same time: # Add required empty directories to TMPPLIST (In reply to Jan Beich from comment #27) > Can you leverage option helpers? > Why not replace with PLIST_FILES ? > Can you include a comment about origin of the patch? Ok, done. Thanks for review. Created attachment 150838 [details]
The port in shar format
Added sed patch for ${CONFIGURE_WRKSRC}/configure.ac file to support other BSD operating systems, based on ${OPSYS:tl}.
Created attachment 150978 [details]
The port in shar format
Fixed libpng.so dependency, after graphics/png update.
Created attachment 152424 [details]
The port in shar format
Replaced following regular expression:
s/3.7.1/${PORTNAME}/
with:
/^AC_INIT/s/3\.7\.1/${PORTNAME}/
for following search string:
AC_INIT(fs2_open, 3.7.1)
Replaced method for empty directories in plist with following method:
-8<--
add-plist-post: build-plist-empty
build-plist-empty: .SILENT
${FIND} ${STAGEDIR}${DATADIR}/data -type d -empty | \
${SED} -e 's|^${STAGEDIR}|@dir |' >> ${TMPPLIST}
-->8-
ACK! You should have put a huge giant warning that this thing has 2Gb worth of distfiles. Some of us have strict datacaps coupled with a very fast internet. "Accidentally" downloading 2Gb is a big impact. that also means we need set this to manual build like the other huge games. by the way, please don't compress logs that are less than 1Mb. The first log I checked was only 300k expanded. A commit references this bug: Author: marino Date: Fri Feb 6 11:15:05 UTC 2015 New revision: 378527 URL: https://svnweb.freebsd.org/changeset/ports/378527 Log: Add new port: games/diaspora PR: 195014 Submitted by: lightside (gmx.com) Diaspora: Shattered Armistice is a single and multiplayer space fighter combat game set in the reimagined Battlestar Galactica universe. It is based on FreeSpace 2 Open Source Code Project engine. Changes: head/games/Makefile head/games/diaspora/ head/games/diaspora/Makefile head/games/diaspora/distinfo head/games/diaspora/files/ head/games/diaspora/files/extra-patch-increase_joy_buttons_fixed.patch head/games/diaspora/files/fs2_open_diaspora.in head/games/diaspora/files/fs2_open_diaspora_launcher.in head/games/diaspora/pkg-descr Okay, I took a bit of risk committing this. I am really not the best suited to commit this port. 1) It's huge. I can't download such huge files 2) It's Linux, so I can't test it on DragonFly builders which don't have download limitations I took the risk because it was poudriere tested although those test logs are pretty old now. Hopefully this doesn't come back to bite me in the butt. I added the MANUAL_PACKAGE_BUILD line. This literally might be the biggest port in the tree in terms of distinfo size. If not the biggest it's probably in the top 5. hmm, am I wrong about this being linux? Other than the file name, I don't see anything that pulls in the linux emulator. (In reply to comment #37) > I added the MANUAL_PACKAGE_BUILD line. This literally might be > the biggest port in the tree in terms of distinfo size. Agreed, I suggested this in comment #4. (In reply to comment #33) > You should have put a huge giant warning that this thing has 2Gb worth of distfiles Related to previous comment. The size of distfiles is in distinfo file, if needed. (In reply to comment #37) > I took the risk because it was poudriere tested although those test logs > are pretty old now. Hopefully this doesn't come back to bite me in the butt. Recently, I rebuilt/reinstalled the port (and did "make check-plist") with latest ports changes, when I wrote comment #32. I think, it should be ok. (In reply to comment #35) > by the way, please don't compress logs that are less than 1Mb. > The first log I checked was only 300k expanded. I created these logs way before this discussion (in other PR). And as you read, I have own meaning of this (about sizes of log files). If log files are small, in my opinion, I post them as uncompressed, of course. (In reply to comment #38) > hmm, am I wrong about this being linux? > Other than the file name, I don't see anything that pulls in the linux emulator. This is native port. The "Linux" is in distfile(s) name only. It might be built for DragonFly BSD also. I added this possibility with following sed patch (fragment only): -8<-- ${REINPLACE_CMD} -e 's/freebsd/${OPSYS:tl}' \ ${CONFIGURE_WRKSRC}/configure.ac -->8- The possibility to build on FreeBSD was done by other people: http://www.hard-light.net/forums/index.php?topic=82425.0 http://www.hard-light.net/forums/index.php?topic=82797.0 Thanks for commit, Jonh Marino. (In reply to lightside from comment #39) > Agreed, I suggested this in comment #4. I didn't read the comment history. In fact, I completely forgot that I comment on this PR before. I didn't realize that until just now and seeing my comments in the log. > Related to previous comment. The size of distfiles is in distinfo file, if needed. Well sure, but who cats a distinfo by habit? I only realized the file was huge when the fetch took more than a few seconds. Maybe I should, but I don't check distinfo before before trying to build a port. I pretty much should do that for all games ports though. > Recently, I rebuilt/reinstalled the port (and did "make check-plist") with latest ports changes, when I wrote > comment #32. I think, it should be ok. ok, good. > I created these logs way before this discussion (in other PR). And as you read, I have own meaning of this > (about sizes of log files). If log files are small, in my opinion, I post them as uncompressed, of course. I recall some kind of discussion like that, I didn't know who it was with. I think we concluded that no judgement call is needed -- the cutoff is 1Mb because that's what bugzilla accepts. > This is native port. The "Linux" is in distfile(s) name only. It might be built for DragonFly BSD also. > I added this possibility with following sed patch (fragment only): Thanks. > Thanks for commit, Jonh Marino. You're welcome. I don't know why it stayed in the queue so long (probably distfile size) |
