Ooops, what does this error suddenly happen?
---
---> Updating MacPorts base sources using rsync
MacPorts base version 2.3.4 installed,
MacPorts base version 2.3.4 downloaded.
---> Updating the ports tree
---> MacPorts base is already the latest version
The ports tree has been updated. To upgr
Clemens Lang writes:
> Hi,
>
> - On 11 Nov, 2015, at 11:03, Rainer Müller rai...@macports.org wrote:
>
>> On 2015-11-11 05:57, Mojca Miklavec wrote:
>>> Is there any chance that we put mirrors of the SVN repository there?
>>>
>>> I would suggest to use these for simplicity:
>>> https://
On Nov 11, 2015, at 10:46 AM, Ryan Schmidt wrote:
> I would imagine that most users who bought a Mac want to run Mac OS, not any
> other OS.
yes, and it's unfortunate that Apple doesn't have a clearly published policy of
how long they continue to support OS releases (and that they don't continu
On Nov 11, 2015, at 9:43 AM, Daniel J. Luke wrote:
> On Nov 11, 2015, at 10:37 AM, Ryan Schmidt wrote:
>> I suspect there will be more than you would probably like. :) I realize
>> older systems don't get updates from Apple anymore. That makes it even more
>> important that they should continue t
On Nov 11, 2015, at 10:37 AM, Ryan Schmidt wrote:
> I suspect there will be more than you would probably like. :) I realize older
> systems don't get updates from Apple anymore. That makes it even more
> important that they should continue to get updates from MacPorts, doesn't it?
No, it makes
On Nov 11, 2015, at 9:33 AM, Daniel J. Luke wrote:
> On Nov 11, 2015, at 9:38 AM, Ryan Schmidt wrote:
>> I think the order of operations would be:
>>
>> - Figure out a way to have libstdc++ and libc++ archives coexist on the
>> packages server by either modifying the archive filename or by setti
On Nov 11, 2015, at 9:38 AM, Ryan Schmidt wrote:
> I think the order of operations would be:
>
> - Figure out a way to have libstdc++ and libc++ archives coexist on the
> packages server by either modifying the archive filename or by setting up a
> second packages server (or subdirectory of the
On Nov 11, 2015, at 9:25 AM, Rainer Müller wrote:
>> Having all of a port's packages -- for all platforms, variants and
>> build options -- in a single directory is nice though because it's a
>> single directory listing to look at to figure out if a particular
>> binary exists. I use this all the
On Nov 11, 2015, at 8:25 AM, Rainer Müller wrote:
> On 2015-11-11 14:18, Ryan Schmidt wrote:
>>> You usually do not want to fetch archives for
>>> anything else than the current OS,
>>
>> Of course we would not want that.
>>
>>> so it is implicit.
>>
>> I don't know what you mean by this.
>
>
On 2015-11-11 14:18, Ryan Schmidt wrote:
>> You usually do not want to fetch archives for
>> anything else than the current OS,
>
> Of course we would not want that.
>
>> so it is implicit.
>
> I don't know what you mean by this.
I meant there are no settings in archive_sites.tcl or
archive_sit
On Nov 11, 2015, at 7:05 AM, Rainer Müller wrote:
>
> On 2015-11-11 12:17, Ryan Schmidt wrote:
>>
>> On Nov 10, 2015, at 12:21 PM, Joshua Root wrote:
>>
>>> On 2015-11-11 00:26 , Mojca Miklavec wrote:
If we start including macosx_deployment_target, macosx_sdk,
prefix, applications_dir,
On 2015-11-11 12:17, Ryan Schmidt wrote:
>
> On Nov 10, 2015, at 12:21 PM, Joshua Root wrote:
>
>> On 2015-11-11 00:26 , Mojca Miklavec wrote:
>>> If we start including macosx_deployment_target, macosx_sdk,
>>> prefix, applications_dir, frameworks_dir, ... we'll sooner or
>>> later end up in an e
On Nov 10, 2015, at 12:21 PM, Joshua Root wrote:
> On 2015-11-11 00:26 , Mojca Miklavec wrote:
>> If we start including macosx_deployment_target, macosx_sdk, prefix,
>> applications_dir, frameworks_dir, ... we'll sooner or later end up in
>> an exponential mess
>
> These are the type of settings
On Nov 10, 2015, at 7:26 AM, Mojca Miklavec wrote:
> But cxxstdlib is one of the most important variable that would be a
> prerequisite for allowing modern sofware to be built on older systems.
> I believe it would be worth adding it (even if we won't ever manage to
> get new buildslaves added to
Me again :-/
Still working on those KF5 frameworks, which come in different tiers that
correspond to the level of inter-frameworks dependencies: tier 2 frameworks can
depend on tier 1 frameworks (which don't depend on other KF5 stuff), tier 3
frameworks can depend on tier 2s and/or tier 1s, and
Hi,
- On 11 Nov, 2015, at 11:03, Rainer Müller rai...@macports.org wrote:
> On 2015-11-11 05:57, Mojca Miklavec wrote:
>> Is there any chance that we put mirrors of the SVN repository there?
>>
>> I would suggest to use these for simplicity:
>> https://www.macosforge.org/post/git-mirrors
On Nov 10, 2015, at 10:57 PM, Mojca Miklavec wrote:
>
> On Wed, Nov 11, 2015 at 12:58 AM, Lawrence Velázquez wrote:
>> On Nov 9, 2015, at 4:45 PM, Rainer Müller wrote:
>>
>>> On 2015-11-09 21:01, Mojca Miklavec wrote:
Does anyone know who owns
https://github.com/MacPorts
?
>>>
>
On Wednesday November 11 2015 11:30:11 René J.V. Bertin wrote:
sh@@t, sorry for the noise, turns out [info exists dep] doesn't check for the
variable dep, but the variable it links to:
>upvar #0 kf5.${name}_dep dep
R.
___
macports-dev mailing list
Hi,
I'm working on KF5 Portfiles, and have the following routine to help defining
dependencies in the PortGroup:
{{{
# variables to facilitate setting up dependencies to KF5 frameworks that may
(or not)
# also exist as port:kf5-foo-devel .
proc kf5.framework_dependency {name {library 0}} {
On 2015-11-11 05:57, Mojca Miklavec wrote:
> On Wed, Nov 11, 2015 at 12:58 AM, Lawrence Velázquez wrote:
>> Surprise! It's me.
>
> Great.
Good to know! I am glad we found you. :-)
> Is there any chance that we put mirrors of the SVN repository there?
>
> I would suggest to use these for simplic
20 matches
Mail list logo
