On Nov 22, 2018, at 09:28, Ken Cunningham wrote:
>
>> On Nov 22, 2018, at 02:39, Vincent Habchi wrote:
>>
>> Ryan,
>>
>>> It failed to build on the 10.11 and older buildbot workers not because of
>>> qgis3 but because of its dependency postgresql10:
>>>
>>> https://trac.macports.org/ticket/
clock_gettime is one of the functions elegantly replaced by the legacy
Portgroup, FYI...
K
> On Nov 22, 2018, at 02:39, Vincent Habchi wrote:
>
> Ryan,
>
>> It failed to build on the 10.11 and older buildbot workers not because of
>> qgis3 but because of its dependency postgresql10:
>>
>> h
Ryan,
> It failed to build on the 10.11 and older buildbot workers not because of
> qgis3 but because of its dependency postgresql10:
>
> https://trac.macports.org/ticket/57588
Good news it built on 10.12+ though.
Turns out I’m at PostgreSQL conference today, so I’ll try to ask about that to
On Nov 21, 2018, at 03:05, Vincent Habchi wrote:
> Oops, also:
>
>>> Ok, I set configure.sdkroot and it worked fine now. Should I commit it with:
>>>
>>> if {${os.platform} eq "darwin" && ${os.major} == 18} {
>>> configure.sdkroot …
>>> }
>>>
>>> ?
>>
>>
>> If this code only gets compi
On Nov 21, 2018, at 03:02, Vincent Habchi wrote:
> Ryan,
>
> Did you file a bug report with Apple w/r to that, or do you want me to go
> ahead?
I haven't filed a bug report. My understanding is that as more people file bug
reports about an issue with Apple, the more important Apple might co
Chris,
> On 21 Nov 2018, at 10:12, Chris Jones wrote:
> Do as you like, but I suspect /usr/include being missing is not a bug but
> intentional.
I didn’t mean that. I mean the fact that when /usr/include exists, it is filled
with outdated include files.
Vincent
On 21/11/18 09:02, Vincent Habchi wrote:
Ryan,
Did you file a bug report with Apple w/r to that, or do you want me to go ahead?
Do as you like, but I suspect /usr/include being missing is not a bug
but intentional.
I've updated the buildbot machine, and it also still doesn't have /usr
Oops, also:
>> Ok, I set configure.sdkroot and it worked fine now. Should I commit it with:
>>
>> if {${os.platform} eq "darwin" && ${os.major} == 18} {
>> configure.sdkroot …
>> }
>>
>> ?
>
>
> If this code only gets compiled on 10.14, then that would work. But do you
> think (or have y
Ryan,
Did you file a bug report with Apple w/r to that, or do you want me to go ahead?
> I've updated the buildbot machine, and it also still doesn't have
> /usr/include. But I also haven't installed the command line tools there.
> Maybe if I did that, /usr/include would now show up.
Vincent
On Nov 11, 2018, at 05:15, Christopher Jones wrote:
> On 10 Nov 2018, at 11:02 pm, Ryan Schmidt wrote:
>
>> On Nov 10, 2018, at 02:53, Vincent Habchi wrote:
>>
>>> Ryan,
>>>
I don't know why Apple is doing this to us. This contradicts what we
previously knew about how SDKs were meant
> On 10 Nov 2018, at 11:02 pm, Ryan Schmidt wrote:
>
> On Nov 10, 2018, at 02:53, Vincent Habchi wrote:
>
>> Ryan,
>>
>>> I don't know why Apple is doing this to us. This contradicts what we
>>> previously knew about how SDKs were meant to function. The SDKs are
>>> supposed to be the same
On Nov 10, 2018, at 02:53, Vincent Habchi wrote:
> Ryan,
>
>> I don't know why Apple is doing this to us. This contradicts what we
>> previously knew about how SDKs were meant to function. The SDKs are supposed
>> to be the same as the system headers of a particular version. We may want to
>>
Ryan,
> Unless you do have /usr/include on your system. Do you? For users who have
> installed /usr/include using the hidden installer package, you might need to
> have the port set configure.sdkroot to the path of the SDK, even when
> MacPorts wouldn't otherwise have done so.
Ok, I set config
Ryan,
> I don't know why Apple is doing this to us. This contradicts what we
> previously knew about how SDKs were meant to function. The SDKs are supposed
> to be the same as the system headers of a particular version. We may want to
> file a bug report with Apple about this. Maybe then they w
On Nov 9, 2018, at 13:40, Vincent Habchi wrote:
>> Yup, NSAppearanceNameDarkAqua is new in macOS 10.14.
> […]
>
>> So you must be on macOS 10.13 with Xcode 10.
>
> Unfortunately not :
>> uname -a
> Darwin Air.local 18.2.0 Darwin Kernel Version 18.2.0: Sat Nov 3 12:30:49 PDT
> 2018; root:xnu-4
> On 9 Nov 2018, at 8:37 pm, Vincent Habchi wrote:
>
> Chris,
>
>>> On 9 Nov 2018, at 21:12, Chris Jones wrote:
>>>
>>> I mean I run a beta-version of 10.14.2 but the Xcode I’ve installed is
>>> 10.1, the production release.
>>> Also that doesn’t explain why the headers in /System/Library
Chris,
> On 9 Nov 2018, at 21:12, Chris Jones wrote:
>
>> I mean I run a beta-version of 10.14.2 but the Xcode I’ve installed is 10.1,
>> the production release.
>> Also that doesn’t explain why the headers in /System/Library/Frameworks are
>> one version behind…
>
> I disagree. You are runn
> On 9 Nov 2018, at 8:11 pm, Vincent Habchi wrote:
>
> Chris,
>
>>
>> Isn't it obvious ? Beta releases are more likely to have problems…
>
> I mean I run a beta-version of 10.14.2 but the Xcode I’ve installed is 10.1,
> the production release.
> Also that doesn’t explain why the headers i
Chris,
>
> Isn't it obvious ? Beta releases are more likely to have problems…
I mean I run a beta-version of 10.14.2 but the Xcode I’ve installed is 10.1,
the production release.
Also that doesn’t explain why the headers in /System/Library/Frameworks are one
version behind…
V.
On 9 Nov 2018, at 7:57 pm, Vincent Habchi wrote:
>>> Weird, no?
>>
>> Not necessarily. You are running beta versions. Anything is possible.
>>
>> Do you really need do this ? Wouldn't switching to the production version
>> not make sense now ?
>
> How do you mean?
Isn't it obvious ? Beta
>> Weird, no?
>
> Not necessarily. You are running beta versions. Anything is possible.
>
> Do you really need do this ? Wouldn't switching to the production version not
> make sense now ?
How do you mean?
V.
> On 9 Nov 2018, at 7:40 pm, Vincent Habchi wrote:
>
> Ryan,
>
>> Yup, NSAppearanceNameDarkAqua is new in macOS 10.14.
> […]
>
>> So you must be on macOS 10.13 with Xcode 10.
>
> Unfortunately not :
>> uname -a
> Darwin Air.local 18.2.0 Darwin Kernel Version 18.2.0: Sat Nov 3 12:30:49 PDT
Ryan,
> Yup, NSAppearanceNameDarkAqua is new in macOS 10.14.
[…]
> So you must be on macOS 10.13 with Xcode 10.
Unfortunately not :
> uname -a
Darwin Air.local 18.2.0 Darwin Kernel Version 18.2.0: Sat Nov 3 12:30:49 PDT
2018; root:xnu-4903.231.1~11/RELEASE_X86_64 x86_64
As you can see, I eve
23 matches
Mail list logo
