Bug 253964 - games/bzflag: Update to 2.4.22
Summary: games/bzflag: Update to 2.4.22
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Neel Chauhan
URL: https://forums.bzflag.org/viewtopic.p...
Keywords:
Depends on:
Blocks:
 
Reported: 2021-03-02 20:18 UTC by Kevin Zheng
Modified: 2021-03-10 20:20 UTC (History)
2 users (show)

See Also:


Attachments
Patch (2.67 KB, patch)
2021-03-02 20:18 UTC, Kevin Zheng
kevinz5000: maintainer-approval+
Details | Diff
Follow-up patch (734 bytes, patch)
2021-03-04 05:08 UTC, Kevin Zheng
no flags Details | Diff
Follow-up patch 2 (763 bytes, patch)
2021-03-10 00:55 UTC, Kevin Zheng
kevinz5000: maintainer-approval+
Details | Diff
Follow-up patch 3 (990 bytes, patch)
2021-03-10 19:43 UTC, Kevin Zheng
kevinz5000: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Zheng 2021-03-02 20:18:15 UTC
Created attachment 222924 [details]
Patch
Comment 1 Neel Chauhan freebsd_committer 2021-03-02 22:19:50 UTC
A tip: You should set the maintainer-approval to + if you want your patch to get committed.
Comment 2 Kevin Zheng 2021-03-02 22:22:09 UTC
I've been told by ports-triage *not* to set maintainer-approval unless triage asks for it.
Comment 3 Kevin Zheng 2021-03-02 22:24:50 UTC
(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."
Comment 4 Rainer Hurling freebsd_committer 2021-03-03 11:15:31 UTC
(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
Comment 5 Kevin Zheng 2021-03-03 18:50:52 UTC
(In reply to Rainer Hurling from comment #4)
I see, thanks for the clarification. I've set maintainer-approval for the patch.
Comment 6 Neel Chauhan freebsd_committer 2021-03-03 18:56:30 UTC
Committed!
Comment 7 commit-hook freebsd_committer 2021-03-03 18:56:34 UTC
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
Comment 8 Kevin Zheng 2021-03-04 01:54:07 UTC
(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?
Comment 9 Neel Chauhan freebsd_committer 2021-03-04 04:56:05 UTC
I guess that's the way to go.

If you do patch, you do not need to bump PORTREVISION on a build failure/fallout.
Comment 10 Kevin Zheng 2021-03-04 05:08:51 UTC
Created attachment 222962 [details]
Follow-up patch

This patch should fix the build.
Comment 11 Neel Chauhan freebsd_committer 2021-03-04 05:19:37 UTC
Committed the fix!
Comment 12 commit-hook freebsd_committer 2021-03-04 05:20:22 UTC
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
Comment 13 Kevin Zheng 2021-03-09 19:03:36 UTC
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
Comment 14 Kevin Zheng 2021-03-09 19:05:13 UTC
(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.
Comment 15 Kevin Zheng 2021-03-10 00:55:45 UTC
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?
Comment 16 Rainer Hurling freebsd_committer 2021-03-10 12:39:52 UTC
(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.
Comment 17 Kevin Zheng 2021-03-10 19:42:39 UTC
(In reply to Rainer Hurling from comment #16)
Thanks, I didn't know about DEVELOPER=yes.
Comment 18 Kevin Zheng 2021-03-10 19:43:06 UTC
Created attachment 223170 [details]
Follow-up patch 3
Comment 19 Rainer Hurling freebsd_committer 2021-03-10 19:50:27 UTC
(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 :)
Comment 20 Kevin Zheng 2021-03-10 19:52:24 UTC
(In reply to Rainer Hurling from comment #19)
Thanks, and yes, please commit this fix.
Comment 21 Rainer Hurling freebsd_committer 2021-03-10 20:20:08 UTC
Committed the fix with r568040. I hope this fixes your pkg-fallout issues ;)