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

Reply via email to