From: "SZEDER Gábor" <firstname.lastname@example.org>
To: Taylor Blau <email@example.com>
Cc: "brian m. carlson" <firstname.lastname@example.org>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Subject: Re: Travis not looking so good
Date: Thu, 27 Jun 2019 15:23:19 +0200 [thread overview]
Message-ID: <20190627132319.GB21574@szeder.dev> (raw)
On Wed, Jun 26, 2019 at 03:35:59PM -0500, Taylor Blau wrote:
> Hi Gábor,
> On Sun, Jun 02, 2019 at 01:22:39PM +0200, SZEDER Gábor wrote:
> > On Sat, Jun 01, 2019 at 12:41:43AM +0000, brian m. carlson wrote:
> > > On 2019-05-30 at 19:32:41, Johannes Schindelin wrote:
> > > > Hi Gábor,
> > > >
> > > > do you have any idea why Travis is failing like this in the macOS/gcc
> > > > job?
> > > >
> > > > > +case "$jobname" in
> > > > > +brew link gcc@8
> > > > > Error: No such keg: /usr/local/Cellar/gcc@8
> > > > > The command "ci/install-dependencies.sh" failed and exited with 1 during .
> > > >
> > > > I usually only look at the Azure Pipelines (which gives me plenty enough
> > > > to do, what with pu's individual branches being tested individually), but
> > > > couldn't fail to notice that *all* four branches (maint, master, next and
> > > > pu) fail in Travis' macOS/gcc job (and only there, the Azure Pipelines are
> > > > all green):
> > > >
> > > > https://github.com/git/git/branches/all
> > > >
> > > > What's going on?
> > The usual: Homebrew desperately tries to be overly clever and helpful,
> > but ends up being dumb and annoying. :)
> > I was hoping that this issue will just solve itself, like several
> > other brew breakages in the past, but apparently it won't...
> I have noticed this as well on my own fork's TravisCI builds.
> > > I suspect if we want to use GCC 8, we need to explicitly install it by
> > > using "brew install gcc@8", or we can just pick the latest released GCC
> > > by using "brew install gcc" if we like that better. We will still need
> > > to do "brew link gcc" (or "gcc@8"), since I suspect Homebrew won't
> > > auto-link it since macOS provides a gcc binary.
> > Yeah, installing gcc@8 or gcc works. Back in 2c8921db2b (travis-ci:
> > build with the right compiler, 2019-01-17) I opted for simply linking
> > the already installed gcc@8 package, because GCC is big, installing it
> > takes time, and the macOS build jobs have always been prone to
> > exceeding the time limit.
Oh, and now I recall that simply running 'brew install gcc@8' back
then (or running it before 'brew update' nowadays) errored out with
something along the lines of "gcc@8 is already installed, you only
have to link it".
> > (Note that these packages provide 'gcc-8'
> > and 'gcc-9' binaries, not 'gcc', and after 'brew install'-ing them we
> > won't need an additional link step (I'm not sure why linking is
> > necessary with the gcc@8 package already installed in the Travis CI
> > image).)
> I wrote something like this up in  before I realized that you had
> your own patches in . This did fix things, but it's kind of awkward
> in the sense that we're not really "installing" anything (in fact, the
> patch in  incorrectly indicates that we are), but instead nudging it
> after it discovers v8.3.
> > Another possibilities are:
> > - Running 'brew link gcc@8' before 'brew update' works:
> > https://travis-ci.org/szeder/git/jobs/540027012#L139
> > - Not running 'brew update' at all works as well:
> > https://travis-ci.org/szeder/git/jobs/514960153#L179
> I'd be just as happy to do something similar to what I did as really
> either of these. Getting rid of 'brew update' entirely would make me
> happiest, since it takes a *long* time for one of these to complete.
I would love to see 'brew update' go away, partly because it takes so
long, and partly because the update of Homebrew itself broke our
builds once or twice in the past (though they usually sorted out the
breakage in a few days) .
However, we've always used the macOS build jobs as "build and test
with the latest and greatest", i.e. they install the latest available
Perforce and Git-LFS. To keep up with this tradition we'd need to run
'brew update' and in turn would need to 'brew install gcc'.
 See e.g. a1ccaedd62 (travis-ci: make the OSX build jobs' 'brew
update' more quiet, 2019-02-02) or
> But, I'd almost prefer explicitly running 'brew install gcc@8' to
> running 'brew link gcc@8' before 'brew update'. The later seems fragile
> and awfully prone to break, especially when we are just doing it to try
> and work around a Homebrew quirk.
> If you don't have any plans to send your patches upstream, and feel OK
> running 'brew install', let me know and I will send my patch in .
> : https://github.com/ttaylorr/git/commit/a20e34d143a4a15b6b15ccb5bfb996fab9551b76
> : https://github.com/szeder/git/commit/ca29709d09a440d98857efb2575a3f92feaab29f
next prev parent reply other threads:[~2019-06-27 13:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-30 19:32 Travis not looking so good Johannes Schindelin
2019-06-01 0:41 ` brian m. carlson
2019-06-02 11:22 ` SZEDER Gábor
2019-06-26 20:35 ` Taylor Blau
2019-06-27 13:23 ` SZEDER Gábor [this message]
2019-06-27 16:46 ` Junio C Hamano
2019-06-29 17:01 ` SZEDER Gábor
2019-07-03 10:47 ` [PATCH 1/2] ci: don't update Homebrew SZEDER Gábor
2019-07-03 10:47 ` [PATCH 2/2] ci: disable Homebrew's auto cleanup SZEDER Gábor
2019-07-03 11:49 ` Johannes Schindelin
2019-07-03 12:26 ` Thomas Braun
2019-07-03 13:04 ` SZEDER Gábor
2019-07-03 16:58 ` Junio C Hamano
2019-07-06 16:16 ` [PATCH] ci/lib.sh: update a comment about installed P4 and Git-LFS versions SZEDER Gábor
2019-07-06 16:21 ` [PATCH v1.1] " SZEDER Gábor
2019-07-08 10:00 ` Johannes Schindelin
2019-07-09 16:32 ` [PATCH 1/2] ci: don't update Homebrew Taylor Blau
2019-07-10 22:33 ` Junio C Hamano
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).