[MacPorts] #54370: gmic @2.0.2: buildbot build gets cancelled because 20 minutes go by with no output

[MacPorts]

#54370: gmic @2.0.2: buildbot build gets cancelled because 20 minutes go by with no
output
-------------------------+-------------------------
  Reporter:  ryandesign  |      Owner:  Schamschula
      Type:  defect      |     Status:  closed
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:
Resolution:  fixed       |   Keywords:  haspatch
      Port:  gmic        |
-------------------------+-------------------------

Comment (by ryandesign):

 Replying to [comment:10 mascguy]:
 > Is there any other way to fix this...?

 My preferred fix would be to implement #62554. Then a port could override
 MacPorts' expectation that a compile job won't exceed 1GB RAM. For
 example, gmic might set that new variable to 4 instead of 1 (assuming we
 write the formula to leave some RAM for the OS, or if we don't, then gmic
 could set the variable to e.g. 4.1). If your computer has more than 8 GB
 RAM then you would still build in parallel, and on our build VMs with 8GB
 they would build with just one job.

 The largest issues have already been resolved by
 [changeset:4741bb1e3ba33f3526b4186bc8a8bf94305a39ea/macports-ports
 splitting the gmic port into several subports].

 Replying to [comment:12 mascguy]:
 > Can a port override the timeout at present?

 No. The timeout is set in the buildbot configuration. It is unreasonable
 for any software build to go for over an hour without printing anything,
 so I would not want to spend any time implementing a way for ports to
 override this timeout. The timeout should no longer happen for gmic now
 that it has been split into subports.

 > If not, are there any alternative mechanisms, such as generating dummy
 output at regular intervals...?

 It's not about printing dummy output, it's about not wanting to use more
 RAM than the system has available, to avoid swapping which is what slows
 down the build and, in the case of the Sierra buildbot worker just before
 I revisited this ticket a few days ago,
 [https://build.macports.org/builders/ports-10.12_x86_64-builder/builds/153501
 caused the worker VM to completely crash] and require a hard reboot. At
 least, it is my guess that excessive memory/swap use might have exposed a
 bug in Sierra that caused the crash. Or the VM crash could have been
 coincidental and not have had anything to do with the memory use. Some of
 the VMs do crash like this from time to time.

-- 
Ticket URL: <https://trac.macports.org/ticket/54370#comment:13>
MacPorts <https://www.macports.org/>
Ports system for macOS