Re: [MacPorts] #43311: iTerm2: update to 1.0.0.20140403

[Ryan Schmidt]

Same ticket is fine. I'll take a look at it.

> On Oct 16, 2014, at 9:35 PM, Mark Anderson  wrote:
> 
> I have a patch in this ticket to upgrade iTerm2 to v 2.0 - Should we change 
> the name of the ticket or start a new one? 
> 
> —Mark
> ___
> Mark E. Anderson 
> 
> On Sun, Oct 5, 2014 at 11:32 PM, MacPorts  wrote:
> #43311: iTerm2: update to 1.0.0.20140403
> -+--
>   Reporter:  nad@…   |  Owner:  emer@…
>   Type:  update  | Status:  new
>   Priority:  Normal  |  Milestone:
>  Component:  ports   |Version:  2.2.1
> Resolution:  |   Keywords:  haspatch
>   Port:  iTerm2  |
> -+--
> 
> Comment (by emer@…):
> 
>  Yeah, I have an incoming patch for that.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [126854] trunk/dports/devel/mpfr/Portfile

[Ryan Schmidt]

On Oct 16, 2014, at 2:19 PM, Lawrence Velázquez wrote:

> Pretty sure this has to be grouped with quotation marks or braces. As it is, 
> base will blacklist any compilers matching the patterns "llvm-gcc-4.2", "=", 
> and "2336.1.00". Needless to say, there are no compilers matching the latter 
> two patterns.

Correct. Even more importantly, I still don't believe that blacklisting 
llvm-gcc-4.2 is correct. The comment above the blacklist says clang, not 
llvm-gcc-4.2, is the problem, so blacklist Xcode 4.2's version of clang, not 
llvm-gcc-4.2

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #43311: iTerm2: update to 1.0.0.20140403

[Mark Anderson]

I have a patch in this ticket to upgrade iTerm2 to v 2.0 - Should we change
the name of the ticket or start a new one?

—Mark
___
Mark E. Anderson 

On Sun, Oct 5, 2014 at 11:32 PM, MacPorts  wrote:

> #43311: iTerm2: update to 1.0.0.20140403
> -+--
>   Reporter:  nad@…   |  Owner:  emer@…
>   Type:  update  | Status:  new
>   Priority:  Normal  |  Milestone:
>  Component:  ports   |Version:  2.2.1
> Resolution:  |   Keywords:  haspatch
>   Port:  iTerm2  |
> -+--
>
> Comment (by emer@…):
>
>  Yeah, I have an incoming patch for that.
>
> --
> Ticket URL: 
> MacPorts 
> Ports system for OS X
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [126854] trunk/dports/devel/mpfr/Portfile

[Lawrence Velázquez]

Pretty sure this has to be grouped with quotation marks or braces. As it is, 
base will blacklist any compilers matching the patterns "llvm-gcc-4.2", "=", 
and "2336.1.00". Needless to say, there are no compilers matching the latter 
two patterns.

vq

On Oct 16, 2014, at 1:14 PM, davidnich...@macports.org wrote:

> Revision
> 126854
> Author
> davidnich...@macports.org
> Date
> 2014-10-16 10:14:38 -0700 (Thu, 16 Oct 2014)
> Log Message
> 
> fixed typo
> Modified Paths
> 
> trunk/dports/devel/mpfr/Portfile
> Diff
> 
> Modified: trunk/dports/devel/mpfr/Portfile (126853 => 126854)
> 
> --- trunk/dports/devel/mpfr/Portfile  2014-10-16 17:07:56 UTC (rev 126853)
> +++ trunk/dports/devel/mpfr/Portfile  2014-10-16 17:14:38 UTC (rev 126854)
> @@ -89,7 +89,7 @@
>  # Xcode 4.2, the generic fix is to pass --disable-thread-safe to configure, 
> however this will break
>  # any project that requires a thread-safe mpfr library, therefore the Xcode 
> 4.2 compiler is
>  # blacklisted here
> -compiler.blacklist  lvm-gcc-4.2 = 2336.1.00
> +compiler.blacklist  llvm-gcc-4.2 = 2336.1.00
>  
>  test.runyes
>  test.target check
> ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-changes

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: 2.3.2

[Joshua Root]

On 2014-10-17 05:16 , Ryan Schmidt wrote:
> 
> On Oct 16, 2014, at 12:50 PM, Joshua Root wrote:
>>
>> So Yosemite is out today. Might as well tag a new release before I build
>> the pkg. Is there anything critical that needs to go onto the branch first?
> 
> Could we update the checks in configure.ac that test for outdated OS X and 
> Xcode versions?
> 
> For example, we should inform users of 10.9.4 and earlier that they should 
> update.

Sure.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: 2.3.2

[Ryan Schmidt]

On Oct 16, 2014, at 12:50 PM, Joshua Root wrote:
> 
> So Yosemite is out today. Might as well tag a new release before I build
> the pkg. Is there anything critical that needs to go onto the branch first?

Could we update the checks in configure.ac that test for outdated OS X and 
Xcode versions?

For example, we should inform users of 10.9.4 and earlier that they should 
update.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

2.3.2

[Joshua Root]

So Yosemite is out today. Might as well tag a new release before I build
the pkg. Is there anything critical that needs to go onto the branch first?

- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: CFPreferences warnings

[Craig Treleaven]

At 6:12 PM +0200 10/16/14, Rainer Müller wrote:

On 2014-10-16 17:30, Craig Treleaven wrote:

 I'm working on a new version of MythTV and building in a non-standard
 prefix (/opt/dvr).  I'm getting hundreds of warning messages like the
 following:


 2014-10-16 10:43:03.178 osacompile[23932:90b] CFPreferences: user home
 directory at file://localhost/opt/local/var/macports/home/ is
 unavailable. User domains will be volatile.




 2014-10-16 10:43:02.413 qmake[23922:903] CFPreferences: user home
 directory at file://localhost/opt/local/var/macports/home/ is
 unavailable. User domains will be volatile.


The path probably comes from the home directory of the macports user
that is used for privilege separation in several phases of the build
process of a port.

$ dscl . -read /Users/macports NFSHomeDirectory
NFSHomeDirectory: /opt/local/var/macports/home


Yes, that's it!


You macports user was added by a previous installation in the default
prefix. I suppose these messages are harmless, but you could change it
to the home directory in the prefix you are using.


Shoot, that's right.  I brainlessly ran the .dmg 
installer for MacPorts and immediately realized 
my error and deleted the /opt/local hierarchy. 
The macports user survived, however.


Did the following to change the value:

$ sudo dscl . -change /Users/macports 
NFSHomeDirectory /opt/local/var/macports/home 
/opt/dvr/var/macports/home


Hopefully that will quiet the blather!

Craig
(Keynote time, now.)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [126852] trunk/dports/devel/mpfr/Portfile

[Ryan Schmidt]

> On Oct 16, 2014, at 11:29 AM, Ryan Schmidt wrote:
> 
>> On Oct 16, 2014, at 9:24 AM, davidnich...@macports.org wrote:
>> 
>> Revision
>> 126852
>> Author
>> davidnich...@macports.org
>> Date
>> 2014-10-16 07:24:39 -0700 (Thu, 16 Oct 2014)
>> Log Message
>> 
>> blacklisted the Xcode 4.2 compiler so that the mpfr lib can be build with 
>> threading enabled and therefore programs (such as Qore) that require a 
>> thread-safe mpfr library no longer assert() and otherwise crash due to 
>> threading issues with the mpfr library
>> Modified Paths
>> 
>>  • trunk/dports/devel/mpfr/Portfile
>> Diff
>> 
>> Modified: trunk/dports/devel/mpfr/Portfile (126851 => 126852)
> 
>> @@ -84,8 +85,10 @@
>> 
>> # Due to radr://10291355 (llvm.org PR1), the new tls support enabled in 
>> clang with Xcode 4.2
>> # miscompiles mpfr. While this was fixed in Xcode 4.2.1, as the ttls support 
>> was never used prior to
>> -# Xcode 4.2, the generic fix is to pass --disable-thread-safe to configure.
>> -configure.args  --disable-thread-safe
>> +# Xcode 4.2, the generic fix is to pass --disable-thread-safe to configure, 
>> however this will break
>> +# any project that requires a thread-safe mpfr library, therefore the Xcode 
>> 4.2 compiler is
>> +# blacklisted here
>> +compiler.blacklist *llvm-gcc-4.2
> 
> I'm not sure I understand the reference to "the Xcode 4.2 compiler" here. 
> Xcode 4.2, like Xcode versions before it, comes with more than one compiler. 
> llvm-gcc-4.2 is one of them, but it also includes clang; clang is the default 
> even. So if the problem is, as the comment states, that Xcode 4.2's clang 
> miscompiles mpfr, then you need to use the compiler_blacklist_versions 
> portgroup to blacklist Xcode 4.2's version of clang.

Oh: I forgot: we changed the default compiler for Xcode 4.2 from clang to 
llvm-gcc-4.2 in r118085 to match Xcode 4.1 and 4.0.

Still, we have a mismatch between the comment and the blacklist. Either the 
comment is wrong or incomplete, or the blacklist is wrong or incomplete.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [126852] trunk/dports/devel/mpfr/Portfile

[Ryan Schmidt]

> On Oct 16, 2014, at 9:24 AM, davidnich...@macports.org wrote:
> 
> Revision
> 126852
> Author
> davidnich...@macports.org
> Date
> 2014-10-16 07:24:39 -0700 (Thu, 16 Oct 2014)
> Log Message
> 
> blacklisted the Xcode 4.2 compiler so that the mpfr lib can be build with 
> threading enabled and therefore programs (such as Qore) that require a 
> thread-safe mpfr library no longer assert() and otherwise crash due to 
> threading issues with the mpfr library
> Modified Paths
> 
>   • trunk/dports/devel/mpfr/Portfile
> Diff
> 
> Modified: trunk/dports/devel/mpfr/Portfile (126851 => 126852)

> @@ -84,8 +85,10 @@
>  
>  # Due to radr://10291355 (llvm.org PR1), the new tls support enabled in 
> clang with Xcode 4.2
>  # miscompiles mpfr. While this was fixed in Xcode 4.2.1, as the ttls support 
> was never used prior to
> -# Xcode 4.2, the generic fix is to pass --disable-thread-safe to configure.
> -configure.args  --disable-thread-safe
> +# Xcode 4.2, the generic fix is to pass --disable-thread-safe to configure, 
> however this will break
> +# any project that requires a thread-safe mpfr library, therefore the Xcode 
> 4.2 compiler is
> +# blacklisted here
> +compiler.blacklist *llvm-gcc-4.2

I'm not sure I understand the reference to "the Xcode 4.2 compiler" here. Xcode 
4.2, like Xcode versions before it, comes with more than one compiler. 
llvm-gcc-4.2 is one of them, but it also includes clang; clang is the default 
even. So if the problem is, as the comment states, that Xcode 4.2's clang 
miscompiles mpfr, then you need to use the compiler_blacklist_versions 
portgroup to blacklist Xcode 4.2's version of clang.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Releasing code as portgroup instead of in base/

[Clemens Lang]

Hi,

- On 14 Oct, 2014, at 16:12, Daniel J. Luke dl...@geeklair.net wrote:

> We do have versionability in portgroups, it just hasn't been used much so far.

Just for the record, this isn't true. The active-variants PortGroup exists in 
two
versions due to an API change.


On the issue at hand, my standpoint is that we should support common build 
systems
in base, e.g. at least autoconf and cmake. Ideally, a Portfile for an autoconf
tool would in my mind boil down to

  PortSystem 1.0
  
  # 
  build.type gnu

Along with that, we should radically speed up and improve our base release 
process,
and improve code quality and API spec in base.

-- 
Clemens Lang
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: CFPreferences warnings

[Brandon Allbery]

On Thu, Oct 16, 2014 at 12:12 PM, Rainer Müller  wrote:

> $ dscl . -read /Users/macports NFSHomeDirectory
> NFSHomeDirectory: /opt/local/var/macports/home
>

Oh, blah. I hate it when programs without specific security needs use that
instead of $HOME

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: CFPreferences warnings

[Rainer Müller]

On 2014-10-16 17:30, Craig Treleaven wrote:
> I'm working on a new version of MythTV and building in a non-standard
> prefix (/opt/dvr).  I'm getting hundreds of warning messages like the
> following:
> 
>> 2014-10-16 10:43:03.178 osacompile[23932:90b] CFPreferences: user home
>> directory at file://localhost/opt/local/var/macports/home/ is
>> unavailable. User domains will be volatile.
> 
> 
>> 2014-10-16 10:43:02.413 qmake[23922:903] CFPreferences: user home
>> directory at file://localhost/opt/local/var/macports/home/ is
>> unavailable. User domains will be volatile.

The path probably comes from the home directory of the macports user
that is used for privilege separation in several phases of the build
process of a port.

$ dscl . -read /Users/macports NFSHomeDirectory
NFSHomeDirectory: /opt/local/var/macports/home

You macports user was added by a previous installation in the default
prefix. I suppose these messages are harmless, but you could change it
to the home directory in the prefix you are using.

Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: CFPreferences warnings

[Brandon Allbery]

On Thu, Oct 16, 2014 at 11:30 AM, Craig Treleaven 
wrote:

> I'm working on a new version of MythTV and building in a non-standard
> prefix (/opt/dvr).  I'm getting hundreds of warning messages like the
> following:
>
>  2014-10-16 10:43:03.178 osacompile[23932:90b] CFPreferences: user home
>> directory at file://localhost/opt/local/var/macports/home/ is
>> unavailable. User domains will be volatile.
>>
>
This is just that these programs (in particular osacompile which is the
Applescript compiler) use the CFPreferences framework, which always looks
for stuff in $HOME before system locations, and for whatever reason the
fake home directory used by MacPorts builds is still pointing at /opt/local
instead of /opt/dvr. Since I don't see a macports.conf entry for it, this
may well indicate a shortcoming in the MacPorts base.

That said, since you are not actually (and should not be!) using the local
settings these programs are looking for, the warnings are harmless.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

CFPreferences warnings

[Craig Treleaven]

Hi:

I'm working on a new version of MythTV and building in a non-standard 
prefix (/opt/dvr).  I'm getting hundreds of warning messages like the 
following:


2014-10-16 10:43:03.178 osacompile[23932:90b] CFPreferences: user 
home directory at file://localhost/opt/local/var/macports/home/ is 
unavailable. User domains will be volatile.



2014-10-16 10:43:02.413 qmake[23922:903] CFPreferences: user home 
directory at file://localhost/opt/local/var/macports/home/ is 
unavailable. User domains will be volatile.


Note that there is no /op/local hierachy on this 'machine'; only 
/opt/dvr.  This is an OS X 10.6.8 Server virtual machine under 
Parallels Desktop with XCode 3.2.6.


So far, the build seems to have finished successully but I'm not at 
the stage of testing functionality, yet.


I have no idea where these messages are coming from.  They reference 
qmake and osacompile.  Are these harmless?  Have I missed a setting? 
A few months ago, I built I built a copy of Myth in a similar 
(non-standard) prefix and didn't experience these warnings.


Full build log attached for the terminally curious.  Messages start 
at line 3426.


Craig

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [90220] trunk/dports/devel/mpfr/Portfile

[Clemens Lang]

Hi,

- On 16 Oct, 2014, at 12:22, David Nichols davidnich...@macports.org wrote:

> This change was made three years ago in svn rev 90220 by c...@macports.org (on
> cc).

See http://trac.macports.org/ticket/33361 and 
http://llvm.org/bugs/show_bug.cgi?id=1
for rationale. I was only the committer in this, the patch came from Jack 
Howard, who
also filed the llvm bug upstream. Apparently the bug has been fixed in LLVM 3.0
meanwhile.

Please remove the flag and blacklist all broken compilers (i.e. those in Xcode 
4.2).

> I would appreciate comments on this - not sure what to do - currently the
> maintainer is "nomaintainer".

Go ahead and do whatever you want with the port in this case. Nobody's going to 
stop
you.

-- 
Clemens Lang
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [90220] trunk/dports/devel/mpfr/Portfile

[David Nichols]

Hi All,

Currently mpfr is compiled in a non-thread-safe manner due to a bug in Xcode 
4.2 (according to comments in the Portfile):

> # Due to radr://10291355 (llvm.org PR1), the new tls support enabled in 
> clang with Xcode 4.2
> # miscompiles mpfr. While this was fixed in Xcode 4.2.1, as the ttls support 
> was never used prior to
> # Xcode 4.2, the generic fix is to pass --disable-thread-safe to configure.
> configure.args  --disable-thread-safe


This change was made three years ago in svn rev 90220 by c...@macports.org (on 
cc).  Compiling mpfr with --disable-thread-safe does in fact make the mpfr 
library non-thread-safe.The qore library depends on the mpfr library in 
macports, and is unstable with this build (running on Mavericks - 10.9.5, 
building with Xcode 6.0.1).

I have to build the mpfr library with thread safety enabled to get a usable 
version of the qore library (where thread-safety is absolutely paramount).

I would like to remove this line in the Portfile - or at least find a better 
solution for Xcode 4.2.  In my opinion, the mpfr library is an important system 
library that should never be compiled in a non-thread-safe manner, so any bugs 
in Xcode that prohibit thread-safety should be considered a reason not to use 
that version of Xcode.

I would appreciate comments on this - not sure what to do - currently the 
maintainer is "nomaintainer".

thanks,
David


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev