[MacPorts] #56300: Travis build failure of xorg-libXau

MacPorts noreply at macports.org
Wed Jun 20 12:59:44 UTC 2018


#56300: Travis build failure of xorg-libXau
-----------------------------+----------------------
  Reporter:  ryandesign      |      Owner:  admin@…
      Type:  defect          |     Status:  reopened
  Priority:  Normal          |  Milestone:
 Component:  server/hosting  |    Version:
Resolution:                  |   Keywords:
      Port:                  |
-----------------------------+----------------------

Comment (by l2dy):

 Replying to [comment:12 l2dy]:
 > Replying to [comment:11 ryandesign]:
 > On second thought, cleaning `/opt/local/var/macports/build/*` after each
 build may fix some issues. And it's also probably the cause of skipped
 phases: build failed when installing dependencies of a previous port due
 to connectivity issue, and then another port also has a dependency on this
 port which hasn't been cleaned. Reopening then.

 I now recall that I deliberately skipped the clean phase to save some
 precious build time (If a port failed, why should I spend the time on
 cleaning it and then re-extract and rebuild it again?), but I didn't
 consider network failure by then. So "skipping phases they shouldn't skip"
 was somewhat working as intended.

 Idea: `find /opt/local/var/macports/build -type d -mindepth 4 -maxdepth 4
 -print0 | sudo xargs -0 rm -rf` would be ideal if network is stable and
 port is really failing (saves more time by making the next phase fail
 immediately). Use `mpbb cleanup` for unstable network, which also does
 other cleanups including deactivate ports.

 >> dependencies that shouldn't already be installed are

 Idea: executing `port -fp deactivate active and rleaves` after `mpbb
 install-dependencies` may solve this.

 >> dependencies that are declared aren't installed

 Maybe `mpbb`'s fault? I'm just calling it to installing the
 dependencies...

 Ultimately, if MacStadium's network is stable and CI builds can get
 undistributable binary archives, all these probably would not happen. I
 think when I closed the issue I was thinking that the ticket summary is
 for a specific port and the issue is caused by a network problem (which I
 consider temporary), so let's track actual issues in different tickets and
 close this one.

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


More information about the macports-tickets mailing list