On Sun, Jul 02, 2017 at 02:41:55AM +, Zero King wrote:
Except when it's a fast-forward merge, Travis would not fetch the
commits in the PR. It only fetches the merge commit and some more
commits in master.
Except for a fast-forward merge, ...
--
Best regards,
Zero King
Don't trust the Fro
On Sat, Jul 01, 2017 at 10:53:41PM +0200, Mojca Miklavec wrote:
On 1 July 2017 at 18:51, Clemens Lang wrote:
On Sat, Jul 01, 2017 at 10:37:04AM +, Zero King wrote:
Travis only fetches the merged ref
`git fetch origin +refs/pull/542/merge:`, so it does complicate matters.
Isn't that exac
On 1 July 2017 at 18:51, Clemens Lang wrote:
> On Sat, Jul 01, 2017 at 10:37:04AM +, Zero King wrote:
>> Travis only fetches the merged ref
>> `git fetch origin +refs/pull/542/merge:`, so it does complicate matters.
Isn't that exactly what we want?
>> I thought of `grep`ing the output for "F
Hi,
Some builds seem to report build success while they in fact fail:
https://travis-ci.org/macports/macports-ports/builds/249056960
Mojca
Hi Nicolas - qmake by itself will not "do the right thing", as you note,
for pretty much any 'port' setting (CC, CXX, *FLAGS).
If you use the qmake 1.0 PortGroup, then qmake should "do the right
thing". If you're using this PG & qmake is still not doing the right
thing, then the issue is likely the
Hi,
On Sat, Jul 01, 2017 at 10:37:04AM +, Zero King wrote:
> I thought of `grep`ing the output for "Failed to parse file" and
> ignore broken Portfiles not touched by the PR like this one
> > Failed to parse file python/py-pydot/Portfile: can't read "_name": no such
> > variable
> in https://
Hello,
While trying to solve an issue where one of my ports does not respect the
compiler choice (ticket #54372, thanks Ryan for pointing that out), I realised
that qmake seems to not be respecting the choice of compiler in any case.
On Mac, qmake uses by default the 'macx-g++’ configuration,
On Sat, Jul 01, 2017 at 10:55:36AM +0200, Mojca Miklavec wrote:
I would be slightly in favour of taking the parent of PR as a
reference (that is: the exact state of the branch of the PR, so not
even trying to create portindex from master) unless that unnecessarily
complicates matters (if so, we c
On 1 July 2017 at 10:06, Zero King wrote:
> On Sat, Jul 01, 2017 at 09:21:42AM +0200, Mojca Miklavec wrote:
>>
>> I would say that
>>portindex || exit 1
>> should work.
>
> Does this make a difference? `portindex` returns 0 (success) even if
> parse error occurred.
I'm sorry, I didn't know th
On Sat, Jul 01, 2017 at 09:21:42AM +0200, Mojca Miklavec wrote:
I would say that
portindex || exit 1
should work.
Does this make a difference? `portindex` returns 0 (success) even if
parse error occurred.
When individual steps could fail and when I wanted to proceed
executing the script to
On 1 July 2017 at 09:21, Mojca Miklavec wrote:
> On 1 July 2017 at 09:04, Zero King wrote:
>> On Sat, Jul 01, 2017 at 07:51:12AM +0200, Mojca Miklavec wrote:
>>>
>>> I tried to figure out where you call (anything that calls) portindex,
>>> but no luck :).
>>
>> https://github.com/macports/macports-
On 1 July 2017 at 09:04, Zero King wrote:
> On Sat, Jul 01, 2017 at 07:51:12AM +0200, Mojca Miklavec wrote:
>>
>> I tried to figure out where you call (anything that calls) portindex,
>> but no luck :).
>
>
> https://github.com/macports/macports-ports/blob/master/_ci/bootstrap.sh#L18
I'm sorry, I
On Sat, Jul 01, 2017 at 07:51:12AM +0200, Mojca Miklavec wrote:
I tried to figure out where you call (anything that calls) portindex,
but no luck :).
https://github.com/macports/macports-ports/blob/master/_ci/bootstrap.sh#L18
--
Best regards,
Zero King
Don't trust the From address.
smime.p7
13 matches
Mail list logo
