Need to know what actions I need to take to get the following tickets resolved ...

[Edward Maros]

https://trac.macports.org/ticket/51625 - Instead of being obsoleted, a
meta-package has been uploaded as requested.

https://trac.macports.org/ticket/51626 - I have committed to resolve the
issue with the next official release of the software

https://trac.macports.org/ticket/51627

https://trac.macports.org/ticket/51628

https://trac.macports.org/ticket/51629

https://trac.macports.org/ticket/51630

https://trac.macports.org/ticket/51631

https://trac.macports.org/ticket/51632

The need for these packages has increased as another package is now
dependent upon them:

  lalframe


Thanks,

Ed

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

Re: libcxx on older systems (eg 10.6) test and fixes format

[Ken Cunningham]

Thanks for the rescue :>

That looks like what I was after. It's easy to spot in the portfile, clear, and 
can be very specific for snowleopard, or generalized up to the 10.8 & earlier 
if the fixes work all the way up to there with a simple, easily recognized 
change.

Re: overly specific -- Indeed, I'm trying hard to stay well clear of the other 
systems to avoid any chance of causing unforeseen trouble - supporting snow 
leopard is not on many people's radar perhaps, and I certainly don't want to 
trigger some Portfile frustrations that triggers support to drop completely in 
the process.

Ken






On 2016-08-13, at 8:44 AM, Lawrence Velázquez wrote:

> On Aug 13, 2016, at 11:11 AM, Ken Cunningham
>  wrote:
> 
>> I just realized that MINOR is a qt4-mac specific global, not
>> a Macports global. And it seemed so handy for what I wanted to do.
>> 
>> Damn. Bad start to this thread. Let me try again another day.
> 
> No need:
> 
>   if {${os.platform} eq "darwin" && ${os.major} <= 10
>   && ${configure.cxx_stdlib} eq "libc++"} {
>   # Snow Leopard and earlier
>   }
> 
> Tiger is 8, Leopard 9, etc.
> 
> As I mentioned in one of the tickets you opened, I don't see a need to
> check the OS unless the fix actually breaks things on newer OSes,
> although I guess there's something to be said for being as specific as
> possible.
> 
> vq
> 

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

Re: libcxx on older systems (eg 10.6) test and fixes format

[Lawrence Velázquez]

On Aug 13, 2016, at 11:11 AM, Ken Cunningham
 wrote:

> I just realized that MINOR is a qt4-mac specific global, not
> a Macports global. And it seemed so handy for what I wanted to do.
> 
> Damn. Bad start to this thread. Let me try again another day.

No need:

if {${os.platform} eq "darwin" && ${os.major} <= 10
&& ${configure.cxx_stdlib} eq "libc++"} {
# Snow Leopard and earlier
}

Tiger is 8, Leopard 9, etc.

As I mentioned in one of the tickets you opened, I don't see a need to
check the OS unless the fix actually breaks things on newer OSes,
although I guess there's something to be said for being as specific as
possible.

vq

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

Re: libcxx on older systems (eg 10.6) test and fixes format

[Ken Cunningham]

Oh - crap.

I just realized that MINOR is a qt4-mac specific global, not a Macports global. 
And it seemed so handy for what I wanted to do.

Damn. Bad start to this thread. Let me try again another day.

Ken




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

Re: libcxx on older systems (eg 10.6) test and fixes format

[Ken Cunningham]

Hah, hah. Pre-coffee.

Great start -- Mountain Lion is 10.8 -- and I think that's the last one we need 
to test for instead of 10.9, if I recall Jeremy's note correctly. 


So with 10.8, here:


# Snow Leopard with cxx_stdlib=libc++ fix
platform darwin { 
if {{${MINOR} == 6} && {${configure.cxx_stdlib} eq "libc++"}} { 

#do stuff like configure.ldflags-append"-lc++" 

} 
} 


and for 10.8 or lower with libcxx, use this:

# Mountain Lion or older with cxx_stdlib=libc++ fix
platform darwin { 
if {{${MINOR} <= 8} && {${configure.cxx_stdlib} eq "libc++"}} { 

#do stuff like configure.ldflags-append"-lc++" 

} 
} 



Ken

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

libcxx on older systems (eg 10.6) test and fixes format

[Ken Cunningham]

Hello,

I've been submitting portfile fixes for the above system as I come across them.

I've submitted fixes for qt4-mac, aria2, and lilypond so far.

But each has a slightly different test format, and there are different opinions 
about how to do it, so I'd like to standardize that test now.

I propose for a specific snowleopard with libcxx fix, use this:

# Snow Leopard with cxx_stdlib=libc++ fix
platform darwin { 
if {{${MINOR} == 6} && {${configure.cxx_stdlib} eq "libc++"}} { 

#do stuff like configure.ldflags-append"-lc++" 

} 
} 


and for 10.9 or lower with libcxx, use this:

# Mountain Lion or older with cxx_stdlib=libc++ fix
platform darwin { 
if {{${MINOR} <= 9} && {${configure.cxx_stdlib} eq "libc++"}} { 

#do stuff like configure.ldflags-append"-lc++" 

} 
} 


To change from one to the other requires changing only two characters in the 
MINOR test, and it seems suitably specific, concise, and clear.

Feedback or thoughts?

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

Re: How to discontinue ports completely (py26 deprecation) ...

[Christopher Jones]

> On 12 Aug 2016, at 11:30 pm, Fred Wright  wrote:
> 
> 
> On Fri, 12 Aug 2016, Chris Jones wrote:
>> On 11/08/16 20:40, Fred Wright wrote:
> [...]
>>> Well, leaving something alone that's working just fine is hardly much of a
>>> maintenance burden.
>> 
>> On the other hand, whats the rationale for keeping 2.6, given 2.7 is the
>> official upstream production version of the 2.x series. What use case
>> requires 2.6 and cannot move to 2.7 ?
> 
> Testing code against 2.6 (among others), because it's intended to run on a
> wide range of platforms, and one wants to make as few assumptions as
> possible about what Python version(s) the end user might have installed.
> Some distros lag *way* behind in versions of various things, including
> Python.
> 
> If the python.org folks had their way, all 2.x versions would be
> eradicated, but there were too many pitchforks at the gates to let that
> happen. :-)

I agree there is no way to migrate completely to 3.x, but I am still not really 
convinced keeping both the 2.6 and 2.7 versions in MacPorts is worth the 
effort. 2.6 needs to be dropped sometime...

Chris

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



smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev