Congratulations to all the selected GSOC students and projects

Rainer Müller raimue at macports.org
Mon May 8 20:56:40 UTC 2017


On 2017-05-08 21:57, Clemens Lang wrote:
>> I'm trying to install MacPorts on Travis VMs. I want to avoid syncing
>> the ports tree to save more time for actual testing. Since the .pkg
>> installer would automatically call `port -v selfupdate` I've modified
>> .travis.yml in base to produce an archive of /opt/local after
>> executing `sudo port install`. To create the "macports" user I also
>> added the postflight script into the archive at
>> https://github.com/macports-staging/macports-base/releases. After
>> extracting the archive, patching conf files and running postflight, I
>> tried to install getopt for mpbb but that failed with
>>
>> Error: Updating database of binaries failed
>> Error: rev-upgrade failed: can't read "env(COLUMNS)": no such variable
>> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
> 
> I think this happens because MacPorts for some reason thinks stdout is
> connected to a terminal, but ioctl(STDOUT_FILENO, TIOCGWINSZ) does not
> return useful sizes and the environment variables COLUMNS and LINES are
> not set either.

Seems like the implementation of the pseudo tty in Travis CI is not
complete, but this is a known problem:

https://github.com/travis-ci/travis-ci/issues/5407

Exporting COLUMNS sounds like a workaround good enough for now. Although
I am not sure if the progress bar will be useful here at all. Will this
print all the escape sequences to a log file, with the result being
unreadable garbage...?

> You can probably work around the problem by either setting COLUMNS and
> LINES, or providing the -v flag to enable verbose output and disable
> progress bars (which trigger this code path).

The verbose mode with -v would still use progress bars, so if you need
to avoid them, either use debug mode with -d or quiet mode with -q.

>> Please help. Even though I could just install the .pkg but using
>> archives allows me to deploy it on Linux too so we could use a
>> different CI for lint tests and only test PRs on Travis.
> 
> A MacPorts installation contains binaries that will very likely not run
> on Linux like this (unless you also want to build a copy of MacPorts for
> Linux on a Linux buildmachine, which is possible if the right
> dependencies are installed).

A pre-compiled tarball of /opt/local for each system (OS version, arch,
Xcode version, etc.) seems the right way to me to get the base system to
the worker as quick as possible.

The base tarball creation itself should be a job on Travis CI to easily
create it for each new base release.

Rainer


More information about the macports-dev mailing list