Travis CI timeouts for MacPorts builds

Mojca Miklavec mojca at
Mon Sep 7 17:20:05 UTC 2020

On Mon, 7 Sep 2020 at 18:44, Ralph Seichter wrote:
> * Joshua Root:
> >> [1]
> >
> > It's just a matter of how long your port takes to build (including
> > installing all its dependencies).
> Notmuch, which is what was built in the job [1], is small and builds in
> less than a minute on my MacBook once the prerequisites are installed.
> Perhaps you'd like to try it for yourself.
> Is the Travis-based build just installing the dependencies (as in: the
> binary packages), or does it also build the dependencies from source?

It tries to install dependencies as binaries, provided the binaries
are available.

The job [1] clearly times out during installation of dependencies.
We should figure out:
- which dependencies time out
- why they are not installed from (the private) binary package repository

> I suspect the latter. I actually tried that here, and it took ages,
> even on my octa-core machine.

There are some packages that are not distributable for licence
conflicts. On your own machine they would always be installed from
source unless we figure out that the licence conflict resolution is
too greedy and fix it by either removing some dependencies or by
explicitly declaring a dependency as a non-conflicting one.

But on Travis & Azure those dependencies should be fetched from the
private archive. If we find out why they are not, we might easily find
the cure for your particular case (or maybe for many other cases as
well). We could start by investigating the logs revealing which
packages built from source on Azure.

Generally we mostly ignore Travis results, so there's no real reason
to worry in your case. It's just that we might be able to solve a
larger cluster of builds if we diagnose & fix the problem.

(We should probably write the list of dependencies as they are being
installed on stdout inside the CI script, without the debug output of


More information about the macports-dev mailing list