On Apr 3, 2018, at 21:27, Andrew Moore wrote:
> With Apple now planning to phase out Server.app, might they be open to
> supporting MacPorts once again? Going forward, I would hope they recognize a
> vested interest in seeing that the open-source community continues to support
> them…
As you
With Apple now planning to phase out Server.app, might they be open to
supporting MacPorts once again? Going forward, I would hope they recognize a
vested interest in seeing that the open-source community continues to support
them…
-AM
> On Mar 15, 2018, at 12:19 AM, Ryan Schmidt wrote:
>
>
On Mar 15, 2018, at 07:01, db wrote:
> On 15 Mar 2018, at 05:19, Ryan Schmidt wrote:
>> On Mar 14, 2018, at 07:23, db wrote:
>>> On 14 Mar 2018, at 01:14, Rainer Müller wrote:
Are you going to sponsor a dedicated Mac server for GitLab CI?
Travis CI is available at no cost and we have no
On 15 Mar 2018, at 05:19, Ryan Schmidt wrote:
> On Mar 14, 2018, at 07:23, db wrote:
>> On 14 Mar 2018, at 01:14, Rainer Müller wrote:
>>> Are you going to sponsor a dedicated Mac server for GitLab CI?
>>> Travis CI is available at no cost and we have no funds to pay for anything.
>> If MacPorts i
On 15 Mar 2018, at 05:13, Ryan Schmidt wrote:
> Because PRs come from untrusted sources, we have to assume their contents are
> tainted. So after any PR is finished building, the VM is tainted and we have
> to throw it away and make a new one from our template for the next PR build.
> On Mar 14
On Mar 14, 2018, at 07:23, db wrote:
> On 14 Mar 2018, at 01:14, Rainer Müller wrote:
>> Are you going to sponsor a dedicated Mac server for GitLab CI?
>> Travis CI is available at no cost and we have no funds to pay for anything.
>
> If MacPorts is short on resources, these could be listed on th
On Mar 14, 2018, at 07:25, db wrote:
> On 14 Mar 2018, at 04:08, Ryan Schmidt wrote:
>> I was not aware of the existence of GitLab CI, but I haven't done a survey
>> of CI systems, mainly because we already selected one many years ago:
>> Buildbot.
>
> GitLab CI is now integrated in GitLab, but
On 14 Mar 2018, at 04:08, Ryan Schmidt wrote:
> I was not aware of the existence of GitLab CI, but I haven't done a survey of
> CI systems, mainly because we already selected one many years ago: Buildbot.
GitLab CI is now integrated in GitLab, but AFAIK doesn't integrate with GitHub
right now u
On 14 Mar 2018, at 01:14, Rainer Müller wrote:
> Are you going to sponsor a dedicated Mac server for GitLab CI?
> Travis CI is available at no cost and we have no funds to pay for anything.
If MacPorts is short on resources, these could be listed on the website. Folks
can certainly ask around.
On Mar 13, 2018, at 19:14, Rainer Müller wrote:
> On 2018-03-14 00:42, db wrote:
>> On 14 Mar 2018, at 00:22, Mojca Miklavec wrote:
>>> Because someone would need to write the code for an alternative CI
>>
>> Wouldn't self-hosted GitLab CI be good enough?
>
> Are you going to sponsor a dedicated
On 2018-03-14 00:42, db wrote:
> On 14 Mar 2018, at 00:22, Mojca Miklavec wrote:
>> Because someone would need to write the code for an alternative CI
>
> Wouldn't self-hosted GitLab CI be good enough?
Are you going to sponsor a dedicated Mac server for GitLab CI?
Travis CI is available at no co
On 14 Mar 2018, at 00:22, Mojca Miklavec wrote:
> Because someone would need to write the code for an alternative CI
Wouldn't self-hosted GitLab CI be good enough?
I get the impression that testing across the board is not a priority.
On 14 March 2018 at 00:12, db wrote:
> On 13 Mar 2018, at 17:10, Mojca Miklavec
> wrote:
>> The main problem is that Travis is *not* out main build system, we use
>> a different system for that. Travis has lots of limitations:
>
> Got it. Then why use it in the first place instead of an alternat
On 13 Mar 2018, at 17:10, Mojca Miklavec wrote:
> The main problem is that Travis is *not* out main build system, we use
> a different system for that. Travis has lots of limitations:
Got it. Then why use it in the first place instead of an alternative CI?
On 13 Mar 2018, at 15:22, Ryan Schmidt wrote:
> On Mar 13, 2018, at 08:47, db wrote:
>> On 12 Mar 2018, at 21:35, Ryan Schmidt wrote:
>>> On Mar 12, 2018, at 13:56, db wrote:
If not, shouldn't it, prior to accepting an updated port definition?
>>> The buildbot is only engaged after a commit i
On Mar 13, 2018, at 08:45, db wrote:
> On 12 Mar 2018, at 21:56, Ryan Schmidt wrote:
>> I'm not aware of any plan to notify users of the cxx_stdlib change, other
>> than the same way that users are notified of any other port update being
>> available: by the user running "sudo port selfupdate" a
On Mar 13, 2018, at 08:47, db wrote:
> On 12 Mar 2018, at 21:35, Ryan Schmidt wrote:
>> On Mar 12, 2018, at 13:56, db wrote:
>>> If not, shouldn't it, prior to accepting an updated port definition?
>> The buildbot is only engaged after a commit is in the repository master
>> branch.
>> We have a
On 12 Mar 2018, at 21:35, Ryan Schmidt wrote:
> On Mar 12, 2018, at 13:56, db wrote:
>> If not, shouldn't it, prior to accepting an updated port definition?
> The buildbot is only engaged after a commit is in the repository master
> branch.
> We have a separate system, using Travis CI, for doing
On 12 Mar 2018, at 21:56, Ryan Schmidt wrote:
> I'm not aware of any plan to notify users of the cxx_stdlib change, other
> than the same way that users are notified of any other port update being
> available: by the user running "sudo port selfupdate" and then examining the
> output of "port o
On 2018-03-12, at 5:21 PM, Michael wrote:
> Is there a reason for a universal binary on PPC anymore?
>
> Anyone running a PPC binary today will either be on a PPC machine (10.5), or
> an Intel machine with Rosetta (10.6).
> They either want a 10.5 PPC binary, or a 10.6 Intel binary.
>
> So is
Hi,
On Mon, Mar 12, 2018 at 04:45:39PM -0500, Ryan Schmidt wrote:
> You'll see each PR title has a red "X" or a green "√" next to it.
> That's the indicator of whether Travis built the PR successfully or
> not. You can click them for more information.
>
> A failed Travis CI build does not necessa
On 2018-03-12, at 4:15 PM, Kenneth F. Cunningham
wrote:
>
> On 2018-03-12, at 4:26 PM, Kenneth F. Cunningham wrote:
>>
>>
>> It _could_ be done in 10.5 Intel, but that makes not much sense. Nobody
>> should be running 10.5 intel anyway, and if we made the libc++ switch in
>> 10.5 intel we'
On 2018-03-12, at 4:26 PM, Kenneth F. Cunningham wrote:
>
>
> It _could_ be done in 10.5 Intel, but that makes not much sense. Nobody
> should be running 10.5 intel anyway, and if we made the libc++ switch in 10.5
> intel we'd be endlessly trying to figure out if we're on 10.5 PPC (libstdc++)
On 2018-03-12, at 3:42 PM, Mojca Miklavec wrote:
> On 12 March 2018 at 22:32, Michael wrote:
>> On 2018-03-08, at 9:32 AM, Ken Cunningham wrote:
>>
>>> Thank God.
>>>
>>> 10.6.8, agree.
>>
>> So PPC machines will not get this upgrade?
>
> PPC and libc++ don't particularly like each other.
Tr
On Mar 12, 2018, at 16:42, Michael wrote:
> On 2018-03-12, at 2:33 PM, Ryan Schmidt wrote:
>
>>
>> On Mar 12, 2018, at 16:31, Michael wrote:
>>>
>>> How about documenting the procedure to submit changes by poll requests,
>>
>> There's lots of documentation about how to submit a pull request,
On 12 March 2018 at 22:32, Michael wrote:
> On 2018-03-08, at 9:32 AM, Ken Cunningham wrote:
>
>> Thank God.
>>
>> 10.6.8, agree.
>
> So PPC machines will not get this upgrade?
PPC and libc++ don't particularly like each other. But we could and
should switch to making gcc 6 or 7 the default compil
On 2018-03-12, at 2:33 PM, Ryan Schmidt wrote:
>
> On Mar 12, 2018, at 16:31, Michael wrote:
>>
>> How about documenting the procedure to submit changes by poll requests,
>
> There's lots of documentation about how to submit a pull request, such as:
>
> https://help.github.com/articles/creat
On Mar 12, 2018, at 16:31, Michael wrote:
> On 2018-03-12, at 1:35 PM, Ryan Schmidt wrote:
>>
>> We have a separate system, using Travis CI, for doing test builds of updates
>> that have been submitted as pull requests but have not yet been merged into
>> the repository master branch. But most
On 2018-03-08, at 9:32 AM, Ken Cunningham
wrote:
> Thank God.
>
> 10.6.8, agree.
So PPC machines will not get this upgrade?
---
Entertaining minecraft videos
http://YouTube.com/keybounce
On 2018-03-12, at 1:35 PM, Ryan Schmidt wrote:
>
> We have a separate system, using Travis CI, for doing test builds of updates
> that have been submitted as pull requests but have not yet been merged into
> the repository master branch. But most maintainers that are committers don't
> submit
On Mar 10, 2018, at 05:38, db wrote:
> How will I know about the lib change and the availability of binaries?
The MacPorts program doesn't have a way to notify you of the availability of
binaries in advance. You try to install a port, and MacPorts checks for a
binary then, and if it's availabl
On Mar 8, 2018, at 18:27, Ryan Schmidt wrote:
> On Mar 8, 2018, at 15:26, Joshua Root wrote:
>
>> On 2018-3-9 07:07 , Ryan Schmidt wrote:
>>
>>> On Mar 8, 2018, at 11:24, Joshua Root wrote:
>>>
Code to check C++ stdlib linkage in rev-upgrade is now in master. That
takes care of the m
On Mar 9, 2018, at 08:18, Joshua Root wrote:
>> What subset of the instructions on the LibcxxOnOlderSystems page would they
>> have to follow?
>
> None of them, hopefully.
>
> We may have to create some bootstrap versions of toolchain ports in
> order to achieve this, so that they can be autom
On Mar 10, 2018, at 11:06, Kenneth F. Cunningham wrote:
> However, at some point in the next few months, when most of the dust has
> settled and most or all of the available binaries are all properly built
> against libc++, I'll change the single line in macports.conf from
> "buildfromsource a
On Mar 11, 2018, at 10:15, Rainer Müller wrote:
> On 2018-03-09 15:21, Joshua Root wrote:
>> On 2018-3-9 20:38 , db wrote:
>>> On 9 Mar 2018, at 01:27, Ryan Schmidt wrote:
When would we run this script to delete libstdc++ archives? Presumably,
after all legacy users have MacPorts 2.5 an
On Mar 12, 2018, at 13:56, db wrote:
> On 11 Mar 2018, at 15:47, Ken Cunningham wrote:
>>> On Mar 11, 2018, at 06:06, db wrote:
>>> On 11 Mar 2018, at 02:47, Kenneth F. Cunningham wrote:
> On 2018-03-10, at 12:23 PM, db wrote:
> Except for building from source for minor versions and revbum
On 11 Mar 2018, at 15:47, Ken Cunningham
wrote:
>> On Mar 11, 2018, at 06:06, db wrote:
>> On 11 Mar 2018, at 02:47, "Kenneth F. Cunningham"
>> wrote:
On 2018-03-10, at 12:23 PM, db wrote:
Except for building from source for minor versions and revbumps,
especially large binarie
On 2018-03-09 15:21, Joshua Root wrote:
> On 2018-3-9 20:38 , db wrote:
>> On 9 Mar 2018, at 01:27, Ryan Schmidt wrote:
>>> When would we run this script to delete libstdc++ archives? Presumably,
>>> after all legacy users have MacPorts 2.5 and have switched to libc++.
>>
>> How about those that
> On Mar 11, 2018, at 06:06, db wrote:
>
>> On 11 Mar 2018, at 02:47, "Kenneth F. Cunningham"
>> wrote:
>>> On 2018-03-10, at 12:23 PM, db wrote:
>>> Except for building from source for minor versions and revbumps, especially
>>> large binaries, and for ports that have open defects. Oh well…
On 11 Mar 2018, at 02:47, "Kenneth F. Cunningham"
wrote:
> On 2018-03-10, at 12:23 PM, db wrote:
>> Except for building from source for minor versions and revbumps, especially
>> large binaries, and for ports that have open defects. Oh well…
> Well, everything for 10.6.8 users on MacPorts is abo
On 2018-03-10, at 12:23 PM, db wrote:
> On 10 Mar 2018, at 18:06, "Kenneth F. Cunningham"
> wrote:
>> I think I"m likely not going to change anything on my LibcxxOnOlderSystems
>> 10.6.8 system for a while, db. It will continue to work just as it does now,
>> and I don't mind building from so
On 10 Mar 2018, at 18:06, "Kenneth F. Cunningham"
wrote:
> I think I"m likely not going to change anything on my LibcxxOnOlderSystems
> 10.6.8 system for a while, db. It will continue to work just as it does now,
> and I don't mind building from source -- kinda got used to it.
Except for build
On 2018-03-10, at 9:06 AM, Kenneth F. Cunningham wrote:
> I'll probably keep building against a current lib curl installed via
> /opt/bootstrap as well, just 'cause it works.
I meant to say I'll keep building MacPorts against a current libcurl...
> Best,
>
> Ken
On 2018-03-10, at 3:38 AM, db wrote:
> How will I know about the lib change and the availability of binaries?
> Besides rebuilding from source from time to time, I only do port sync.
I think I"m likely not going to change anything on my LibcxxOnOlderSystems
10.6.8 system for a while, db. It w
On 10 Mar 2018, at 00:09, Joshua Root wrote:
> On 2018-3-10 08:43 , db wrote:
>>
>> If I build base and ports from source, will buildfromsource be changed
>> unilaterally by MP or would it need user intervention? I also have certain
>> versions of gcc and llvm locally to avoid rebuilding after
On 2018-3-10 08:43 , db wrote:
> On 9 Mar 2018, at 15:21, Joshua Root wrote:
>> On 2018-3-9 20:38 , db wrote:
>>> On 9 Mar 2018, at 01:27, Ryan Schmidt wrote:
When would we run this script to delete libstdc++ archives? Presumably,
after all legacy users have MacPorts 2.5 and have switc
On 9 Mar 2018, at 15:21, Joshua Root wrote:
> On 2018-3-9 20:38 , db wrote:
>> On 9 Mar 2018, at 01:27, Ryan Schmidt wrote:
>>> When would we run this script to delete libstdc++ archives? Presumably,
>>> after all legacy users have MacPorts 2.5 and have switched to libc++.
>> How about those tha
> On Mar 9, 2018, at 06:18, Joshua Root wrote:
>
> We may have to create some bootstrap versions of toolchain ports in
> order to achieve this, so that they can be automatically installed as
> dependencies with no manual intervention.
Maybe we could just force clang 3.4 to build against libstd
On 2018-3-9 20:38 , db wrote:
> On 9 Mar 2018, at 01:27, Ryan Schmidt wrote:
>> When would we run this script to delete libstdc++ archives? Presumably,
>> after all legacy users have MacPorts 2.5 and have switched to libc++.
>
> How about those that build MP from source?
There are no additional
On 2018-3-9 11:27 , Ryan Schmidt wrote:
>
> When would we run this script to delete libstdc++ archives? Presumably, after
> all legacy users have MacPorts 2.5 and have switched to libc++. When is that?
> Certainly no sooner than two weeks after release since that's how long it
> takes MacPorts
On 9 Mar 2018, at 01:27, Ryan Schmidt wrote:
> When would we run this script to delete libstdc++ archives? Presumably, after
> all legacy users have MacPorts 2.5 and have switched to libc++.
How about those that build MP from source?
On 2018-03-08, at 4:27 PM, Ryan Schmidt wrote:
> How will users upgrade from libstdc++ to libc++? What subset of the
> instructions on the LibcxxOnOlderSystems page would they have to follow? What
> if they don't do that and stay on libstdc++?
We do have to ponder the bootstrap toolchain proc
On Mar 8, 2018, at 15:26, Joshua Root wrote:
> On 2018-3-9 07:07 , Ryan Schmidt wrote:
>
>> On Mar 8, 2018, at 11:24, Joshua Root wrote:
>>
>>> Code to check C++ stdlib linkage in rev-upgrade is now in master. That
>>> takes care of the main obstacle to being able to change the default stdlib.
On 2018-3-9 07:07 , Ryan Schmidt wrote:
>
> On Mar 8, 2018, at 11:24, Joshua Root wrote:
>
>> Code to check C++ stdlib linkage in rev-upgrade is now in master. That
>> takes care of the main obstacle to being able to change the default stdlib.
>
> Currently, we publish archives on packages.macpo
On Mar 8, 2018, at 11:24, Joshua Root wrote:
> Code to check C++ stdlib linkage in rev-upgrade is now in master. That
> takes care of the main obstacle to being able to change the default stdlib.
Currently, we publish archives on packages.macports.org for 10.8 and earlier
that are built for lib
Thank God.
10.6.8, agree.
I use clang 3.9 as a good balance between capability and compatability, but
might as well sort out how to use clang 5 as that is more consistent w older
systems, and I nearly have thread_local working there on 10.6
Ken
Sent from my iPhone
> On Mar 8, 2018, at 9:24
Code to check C++ stdlib linkage in rev-upgrade is now in master. That
takes care of the main obstacle to being able to change the default stdlib.
That leaves a couple of questions:
Which OS versions can we make the change on? At first glance it looks
like probably 10.6 through 10.8. 10.5 appears
57 matches
Mail list logo
