Bug 253964
| Summary: | games/bzflag: Update to 2.4.22 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Kevin Zheng <kevinz5000> | ||||||||||
| Component: | Individual Port(s) | Assignee: | Neel Chauhan <nc> | ||||||||||
| Status: | Closed FIXED | ||||||||||||
| Severity: | Affects Only Me | CC: | nc, rhurlin | ||||||||||
| Priority: | --- | ||||||||||||
| Version: | Latest | ||||||||||||
| Hardware: | Any | ||||||||||||
| OS: | Any | ||||||||||||
| URL: | https://forums.bzflag.org/viewtopic.php?f=62&t=20480 | ||||||||||||
| Attachments: |
|
||||||||||||
A tip: You should set the maintainer-approval to + if you want your patch to get committed. I've been told by ports-triage *not* to set maintainer-approval unless triage asks for it. (In reply to Neel Chauhan from comment #1) For example, in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252655: "^Triage: Maintainer-feedback flag (+) not required unless requested (?) first." (In reply to Kevin Zheng from comment #3) Hi Kevin, I think this is a misunderstanding. The maintainer-approval flag is set in the attachments area next to the corresponding patch. This can be done either directly during the insertion of the patch or afterwards by going to details on the right of the patch. In the now opening edit window of the patch there is the possibility below the patch to set the maintainer-approval flag to '+' if the patch is ok (= accepted, approved). The mentioned triage refers to the maintainer-feedback flag that is located in the main window of the PR in the upper right block. This flag is used to request feedback from the maintainer and does not directly refer to an attached patch. For both there is also a context sensitive help: Just leave the mouse on the area for a while ... HTH, Rainer (In reply to Rainer Hurling from comment #4) I see, thanks for the clarification. I've set maintainer-approval for the patch. Committed! A commit references this bug: Author: nc Date: Wed Mar 3 18:56:26 UTC 2021 New revision: 567252 URL: https://svnweb.freebsd.org/changeset/ports/567252 Log: games/bzflag: Update to 2.4.22 Changes: https://forums.bzflag.org/viewtopic.php?f=62&t=20480 PR: 253964 Submitted by: Kevin Zheng <kevinz5000 AT gmail DOT com> (maintainer) Changes: head/games/bzflag/Makefile head/games/bzflag/distinfo head/games/bzflag/files/ head/games/bzflag/files/patch-configure.ac head/games/bzflag/files/patch-src_platform_EvdevJoystick.cxx (In reply to commit-hook from comment #7) Thanks for committing. Looks like there's some fallout: http://beefy10.nyi.freebsd.org/data/114i386-default/567284/logs/bzflag-2.4.22.log Looks like this is related to my patch to configure. I patched configure to avoid bringing in USES+=autoreconf, but it looks like the Makefile wants to run aclocal anyway, presumably because configure was touched. Would the best approach here to be to patch configure.ac and just bring in USES+=autoreconf? I guess that's the way to go. If you do patch, you do not need to bump PORTREVISION on a build failure/fallout. Created attachment 222962 [details]
Follow-up patch
This patch should fix the build.
Committed the fix! A commit references this bug: Author: nc Date: Thu Mar 4 05:19:33 UTC 2021 New revision: 567288 URL: https://svnweb.freebsd.org/changeset/ports/567288 Log: games/bzflag: Add autoreconf to USES. This prevents build fallouts. PR: 253964 Submitted by: Kevin Zheng <kevinz5000@gmail.com> (maintainer) Changes: head/games/bzflag/Makefile Hi there, I'm seeing a new variety of build fallout, which I cannot reproduce locally, and am having trouble understanding and fixing. It looks like as if the configure and make process for the build was not run, even though it should have (since GNU_CONFIGURE=yes). An example of the failing build are linked below: http://beefy6.nyi.freebsd.org/data/122amd64-default/567446/logs/bzflag-2.4.22.log Since I'm pretty stuck on figuring out what's going on, I appreciate another set of eyes on it. Thanks, Kevin (In reply to Kevin Zheng from comment #13) Sorry for the noise; it appears I mixed up my build log. It actually just looks like it's missing an implicit dependency SDL2. Created attachment 223137 [details]
Follow-up patch 2
Fix SDL dependency to (try) to fix build fallout.
Does anyone happen to have a poudriere to test this change?
I'm also curious: there used to be a build service called RedPorts. What happened to that?
(In reply to Kevin Zheng from comment #15) > Fix SDL dependency to (try) to fix build fallout. > > Does anyone happen to have a poudriere to test this change? With "DEVELOPER=yes" in /etc/make.conf I get: ====> Running Q/A tests (stage-qa) Error: /usr/local/bin/bzadmin is linked to /usr/local/lib/libncurses.so.6 from devel/ncurses but it is not declared as a dependency Warning: you need USES+=ncurses Error: /usr/local/bin/bzadmin is linked to /usr/local/lib/libtinfo.so.6 from devel/ncurses but it is not declared as a dependency Warning: you need USES+=ncurses Obviously, 'USES+=ncurses' is needed ... The ports builds fine in Poudriere (amd64, i386) with USES+=ncurses added :) > I'm also curious: there used to be a build service called RedPorts. > What happened to that? AFAIK, RedPorts is down now for several years. It seems it has been overcome by events (Phabricator, Poudriere, ...)? Note: I suspect there is little response to the request with your new patch because you are using the already closed PR for it. (In reply to Rainer Hurling from comment #16) Thanks, I didn't know about DEVELOPER=yes. Created attachment 223170 [details]
Follow-up patch 3
(In reply to Kevin Zheng from comment #18) Hi Kevin, As I said before, this is a closed PR. So do not expect any attention of other developers. Do you want me to commit these changes now? If yes, I would like to commit :) (In reply to Rainer Hurling from comment #19) Thanks, and yes, please commit this fix. Committed the fix with r568040. I hope this fixes your pkg-fallout issues ;) |
Created attachment 222924 [details] Patch