Re: Travis not looking so good

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [1] before I realized that you had
> your own patches in [2]. 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 [1] 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) [1].

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'.

[1] See e.g. a1ccaedd62 (travis-ci: make the OSX build jobs' 'brew
    update' more quiet, 2019-02-02) or

    https://public-inbox.org/git/20180907032002.23366-1-szeder.dev@xxxxxxxxx/T/#u


> 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 [1].
> 
> Thanks,
> Taylor
> 
> [1]: https://github.com/ttaylorr/git/commit/a20e34d143a4a15b6b15ccb5bfb996fab9551b76
> [2]: https://github.com/szeder/git/commit/ca29709d09a440d98857efb2575a3f92feaab29f



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux