Created attachment 171113 [details] Proposed patch (since 416324 revision) Patch to unbreak games/tuxpuck port. - Bump PORTREVISION - Unbreak fetch - Add audio/libogg to library dependency - Regenerate patches The distfile is fetchable: % curl -sLI http://www.sourcefiles.org/Games/Sports/Miscellaneous/tuxpuck-0.8.2.tar.gz HTTP/1.1 200 OK Date: Mon, 06 Jun 2016 17:45:41 GMT Server: Apache/2.2.3 (Fedora) Last-Modified: Sun, 18 Mar 2007 02:01:46 GMT ETag: "1888d4-5dc09-dadaf680" Accept-Ranges: bytes Content-Length: 384009 Connection: close Content-Type: application/x-gzip
Created attachment 171114 [details] The poudriere testport log (FreeBSD 10.2 amd64)
Comment on attachment 171113 [details] Proposed patch (since 416324 revision) lightside, thanks for the patch. I confirm this builds in a 10.3 amd64 poudriere jail. I'm just not sure about those timetamp modifications in patches, as if the patch is not against the HEAD? Anyway, implicit approval, as the port has no maintainer.
Cleaning summary in favor of patch flagged maintainer-approval.
(In reply to comment #2) > I confirm this builds in a 10.3 amd64 poudriere jail. Thanks for review. (In reply to comment #2) > I'm just not sure about those timetamp modifications in > patches, as if the patch is not against the HEAD? The patches in files directory regenerated with `make makepatch` command, which uses UTC time format. This is done to fix warnings found by portlint.
Hello lightside, thanks for the patch! Since the patches did not change at all, can you please provide a diff without them? I started the testbuilds a moment ago without the patches and will let them run over night. Greetings, Torsten
Created attachment 171395 [details] Proposed patch (since 416324 revision) without regenerated patches Hello, Torsten Zuehlsdorff. (In reply to comment #5) > Since the patches did not change at all It has changes for files/patch-tuxpuck.c file, which has different position ("-17,7 +17,7" instead of "-40,7 +40,7"). (In reply to comment #5) > can you please provide a diff without them? I can, but these patches was regenerated with `make makepatch` command to fix portlint warnings, like in following kind of changes: ports r416708, ports r416584, ports r416495, etc.
Hello, since i'm new to the ports-team i asked my mentors how to handle the patches. Conclusion: regeneration of the patches for petting portlint is just fine. No need to change the patch. I will process them as they are! Thanks, Torsten
Comment on attachment 171395 [details] Proposed patch (since 416324 revision) without regenerated patches (In reply to from comment #7) > since i'm new to the ports-team i asked my mentors how to handle the patches. It's a following command, just for other people who curious: % cd tuxpack && patch -B '' < ../tuxpuck.diff assuming, that the diff file is near tuxpack directory. > Conclusion: regeneration of the patches for petting portlint is just fine. > No need to change the patch. I will process them as they are! Ok, thanks.
(In reply to comment #8) > is near tuxpack directory * tuckpuck. Also possible to backup files before patch, just in case. And checking the patch with "-C" option before apply.
(In reply to lightside from comment #8) > It's a following command, just for other people who curious: > % cd tuxpack && patch -B '' < ../tuxpuck.diff Okay, i phrased this poorly. :D I meant that i asked how to handle patch-files which just changes the generation date. I personally see no purpose in committing changes without any effect and would have excluded them. But after talking to my mentors the conclusion is, that if there are changes with effects (like your Makefile-changes) it is totally fine to pet portlint.
(In reply to comment #10) > I meant that i asked how to handle patch-files which just changes the > generation date. I understand and posted patch command just for other people, who interested to know how to apply patch(es). (In reply to comment #10) > I personally see no purpose in committing changes without any effect and > would have excluded them. Agreed, but portlint "thinks" otherwise. Therefore I did a `make makepatch` command, like other submitters/committers did. (In reply to comment #9) > * tuckpuck. * tuxpuck. Sorry about mistakes. It's a funny name for the program, I guess :)
Yes, its a funny name. Patch is fine and tests are also. :) Last question: why did you add the libogg dependency? The port wasn't modified for years and it is hard to believe it was overlooked so long. Was it? Other reasons?
(In reply to comment #12) > Patch is fine and tests are also. Thanks. (In reply to comment #12) > Last question: why did you add the libogg dependency? The port wasn't > modified for years and it is hard to believe it was overlooked so long. > Was it? Other reasons? I added audio/libogg dependency because of new stage-qa check(s), introduced in ports r415827. If you test current (without BROKEN define) revision with `make stage-qa` command, then you will get following warning: ====> Running Q/A tests (stage-qa) Error: /usr/local/bin/tuxpuck is linked to /usr/local/lib/libogg.so.0 from audio/libogg but it is not declared as a dependency Warning: you need LIB_DEPENDS+=libogg.so:audio/libogg It was ok, because there is a audio/libvorbis dependency, which also depends on audio/libogg. So called "proxy dependencies", described in /usr/ports/CHANGES file. Also, if you examine ${WRKSRC}/Makefile, then you will find "-logg" string, which links libogg(.so) library directly. As I understood, this is needed, because in case of libogg.so.0 changes in the audio/libogg port, e.g. to libogg.so.1, there is a need to rebuild the games/tuxpuck port also. So far, it didn't change, therefore without found errors.
Some words about new stage-qa checks: There are situations, when program/library may link with other library indirectly through helper program(s), e.g. `gtk-config --libs` (from x11-toolkits/gtk12), where with NLS option (by default) it adds "-lintl" and new stage-qa may suggest about USES+=gettext-runtime. But since this may depend from NLS option of other port, but not in current, e.g. security/stegdetect, there is maybe not need to add gettext-runtime to USES (and current stage-qa can't/didn't check it), as committer did in ports r417141, even if I proposed this in attachment 171590 [details]. Trust (stage-qa, in my case), but verify.
A commit references this bug: Author: tz Date: Mon Jun 27 20:02:47 UTC 2016 New revision: 417682 URL: https://svnweb.freebsd.org/changeset/ports/417682 Log: games/tuxpuck: unbreak fetch Additional changes: - Bump PORTREVISION - Add audio/libogg to library dependency - Regenerate patches PR: 210082 Approved by: junovitch (mentor) Changes: head/games/tuxpuck/Makefile head/games/tuxpuck/files/patch-Makefile head/games/tuxpuck/files/patch-tuxpuck.c
Committed, thanks! :)