Dinko, do you think does it make sense to use scripted brew instead of travis plugin ?
if so, we can try to "brew instal blah-blah-blah || ok, we failed, lets' update and install one more time" чт, 9 июл. 2020 г. в 13:07, Илья Шипицин <chipits...@gmail.com>: > we have homebrew --> update --> true > > https://github.com/haproxy/haproxy/blob/master/.travis.yml#L26 > > > if we remove it, brew will not get updated. > > > most of the time it is not an issue and we can install socat. but under > some circumstances socat refuses to install without brew update > > чт, 9 июл. 2020 г. в 12:42, Dinko Korunic <dinko.koru...@gmail.com>: > >> I would suggest using HOMEBREW_NO_AUTO_UPDATE environment variable to >> avoid Brew auto-updating where it’s not really needed, for instance as in: >> >> HOMEBREW_NO_AUTO_UPDATE=1 brew install socat >> >> If that doesn’t work (but I think it should), pinning will cause none of >> dependancies to be installed automatically and only through manual install: >> >> brew list | xargs brew pin >> brew install socat >> >> >> On 9 Jul 2020, at 09:19, Илья Шипицин <chipits...@gmail.com> wrote: >> >> We install socat, because it is (or was?) needed for some tests. OSX >> requires to update whole brew for that. Otherwise it works unstable >> >> On Thu, Jul 9, 2020, 9:16 AM Willy Tarreau <w...@1wt.eu> wrote: >> >>> Hi Ilya, >>> >>> is it normal that the OSX build procedure in travis pulls gigabytes of >>> ruby and python crap, including fonts, libgpg, gnutls, qt, postgresql >>> and whatnot for many minutes ? >>> >>> https://travis-ci.com/github/haproxy/haproxy/jobs/359124175 >>> >>> It's been doing this for more than 12 minutes now without even starting >>> to build haproxy. I'm suspecting that it's reinstalling a full-featured >>> desktop operating system, which seems awkward and counter productive at >>> best. >>> >>> I don't know if that's automatically done based on broken dependencies >>> or if it is caused by a preliminary upgrade of the whole system, but I >>> think we need to address this as it's quite not efficient in this form. >>> >>> Thanks! >>> Willy >>> >> >> -- >> Dinko Korunic ** Standard disclaimer applies ** >> Sent from OSF1 osf1v4b V4.0 564 alpha >> >>