Re: Deactivate currently active version of a port before building?

[Ryan Schmidt]

On Aug 15, 2013, at 21:51, Leo Singer wrote:

> I am working on updating the htcondor port to version 8.1.0. It turns out 
> that the htcondor build produces a faulty binary if an older version of 
> htcondor is already installed. Is there a way to deactivate any installed 
> version of a port before entering the configure phase?

PortGroup conflicts_build 1.0

conflicts_build ${name}


> Are there any examples of ports that do that?


https://trac.macports.org/browser/trunk/dports/devel/thrift/Portfile

https://trac.macports.org/browser/trunk/dports/graphics/podofo/Portfile

https://trac.macports.org/browser/trunk/dports/mail/notmuch/Portfile


Ideally, however, you'd fix the real problem (rearrange the -L and/or -I flags 
so that /opt/local/lib and /opt/local/include appear *after* any paths for the 
work directory).

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

Deactivate currently active version of a port before building?

[Leo Singer]

Hello,

I am working on updating the htcondor port to version 8.1.0. It turns out that 
the htcondor build produces a faulty binary if an older version of htcondor is 
already installed. Is there a way to deactivate any installed version of a port 
before entering the configure phase? Are there any examples of ports that do 
that?

Thanks,
Leo Singer
Graduate Student @ LIGO-Caltech
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [109478] trunk/dports/

[Blair Zajac]

On 08/15/2013 07:15 PM, Blair Zajac wrote:

On 08/15/2013 07:04 PM, Ryan Schmidt wrote:


On Aug 15, 2013, at 20:53, bl...@macports.org wrote:


Revision: 109478
  https://trac.macports.org/changeset/109478
Author:   bl...@macports.org
Date: 2013-08-15 18:53:39 -0700 (Thu, 15 Aug 2013)
Log Message:
---
Set svn:auto-props so svn >= 1.8 clients will set correct props on
Portfile.

http://wiki.apache.org/subversion/Inheritable-Ignores-AutoProps

Property Changed:

trunk/dports/


Property changes on: trunk/dports
___
Added: svn:auto-props
   + Portfile = svn:eol-style=native;svn:keywords=Id


Thanks for reminding us about this new Subversion 1.8 feature. This is
the value I'd set, but I was thinking we should set it directly on
trunk, so that Portfiles in the users directory and elsewhere (there's
one in the documentation directory in base…) get the property too.


Are you referring to https://svn.macports.org/repository/macports/users/
?  This is a peer of trunk though.

We could set it on the repo root, that should be safe.


I'd add auto-props for *.tcl files too with the same value.


Likewise on the repo root.


We should also add svn:global-ignores set to "work". We've had
inadvertent commits of the work symlink before.


Feel free to make any change you like.


I did the changes in r109479 and r109480 on the repo root.

Blair

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

Re: [109478] trunk/dports/

[Blair Zajac]

On 08/15/2013 07:04 PM, Ryan Schmidt wrote:


On Aug 15, 2013, at 20:53, bl...@macports.org wrote:


Revision: 109478
  https://trac.macports.org/changeset/109478
Author:   bl...@macports.org
Date: 2013-08-15 18:53:39 -0700 (Thu, 15 Aug 2013)
Log Message:
---
Set svn:auto-props so svn >= 1.8 clients will set correct props on Portfile.

http://wiki.apache.org/subversion/Inheritable-Ignores-AutoProps

Property Changed:

trunk/dports/


Property changes on: trunk/dports
___
Added: svn:auto-props
   + Portfile = svn:eol-style=native;svn:keywords=Id


Thanks for reminding us about this new Subversion 1.8 feature. This is the 
value I'd set, but I was thinking we should set it directly on trunk, so that 
Portfiles in the users directory and elsewhere (there's one in the 
documentation directory in base…) get the property too.


Are you referring to https://svn.macports.org/repository/macports/users/ 
?  This is a peer of trunk though.


We could set it on the repo root, that should be safe.


I'd add auto-props for *.tcl files too with the same value.


Likewise on the repo root.


We should also add svn:global-ignores set to "work". We've had inadvertent 
commits of the work symlink before.


Feel free to make any change you like.

Blair

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

Re: [109478] trunk/dports/

[Ryan Schmidt]

On Aug 15, 2013, at 20:53, bl...@macports.org wrote:

> Revision: 109478
>  https://trac.macports.org/changeset/109478
> Author:   bl...@macports.org
> Date: 2013-08-15 18:53:39 -0700 (Thu, 15 Aug 2013)
> Log Message:
> ---
> Set svn:auto-props so svn >= 1.8 clients will set correct props on Portfile.
> 
> http://wiki.apache.org/subversion/Inheritable-Ignores-AutoProps
> 
> Property Changed:
> 
>trunk/dports/
> 
> 
> Property changes on: trunk/dports
> ___
> Added: svn:auto-props
>   + Portfile = svn:eol-style=native;svn:keywords=Id

Thanks for reminding us about this new Subversion 1.8 feature. This is the 
value I'd set, but I was thinking we should set it directly on trunk, so that 
Portfiles in the users directory and elsewhere (there's one in the 
documentation directory in base…) get the property too.

I'd add auto-props for *.tcl files too with the same value.

We should also add svn:global-ignores set to "work". We've had inadvertent 
commits of the work symlink before.


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

Re: [109465] trunk/dports/java

[Blair Zajac]

On 08/15/2013 06:47 PM, Joshua Root wrote:

On 2013-8-16 11:16 , Blair Zajac wrote:

Ryan: BTW, in svn 1.8 we can add 'svn:auto-props' to do Portfile.  What
is the proper setting we should use, this is what I have:

Portfile = svn:eol-style=native;svn:keywords=Id


That looks fine. We've been recommending this for a long time:




Added in https://trac.macports.org/changeset/109478.

Blair

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

Re: [109465] trunk/dports/java

[Joshua Root]

On 2013-8-16 11:16 , Blair Zajac wrote:
> Ryan: BTW, in svn 1.8 we can add 'svn:auto-props' to do Portfile.  What
> is the proper setting we should use, this is what I have:
> 
> Portfile = svn:eol-style=native;svn:keywords=Id

That looks fine. We've been recommending this for a long time:



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

Re: [109465] trunk/dports/java

[Blair Zajac]

On 08/15/2013 05:59 PM, Ryan Schmidt wrote:


On Aug 15, 2013, at 17:39, easie...@macports.org wrote:


Revision: 109465
  https://trac.macports.org/changeset/109465
Author:   easie...@macports.org
Date: 2013-08-15 15:39:45 -0700 (Thu, 15 Aug 2013)
Log Message:
---
maven-devel: track maven-3.1.0.

Maven 3.1.x replaces the Sonatype Aether connector with the new
Apache-engineered one.  Should be a good thing over time, but will be
"bumpy" for tools that use Aether to introspect the distributed POM
graph (like lang/abcl).



Added: trunk/dports/java/maven-devel/Portfile



+supported_archs noarch



+use_configure no
+# hmm?
+universal_variant no


"universal_variant no" is implied by both "use_configure no" (because the default universal variant 
is for autotools configure scripts, and "use_configure no" means you don't have a configure script) and 
"supported_archs noarch" (because if you're not installing any architecture-specific files then there is no 
such thing as a universal build of that).


A couple of other things:

1) Use 'svn copy' when making a copy of a port.  I did this in r109477 
[1] to retain history of the port by deleting the port and making a 
fresh 'svn copy' and rsyncing your work over it.


2) Ensure that auto-props are set in your Subversion config to add the 
proper properties to new Portfiles.


Ryan: BTW, in svn 1.8 we can add 'svn:auto-props' to do Portfile.  What 
is the proper setting we should use, this is what I have:


Portfile = svn:eol-style=native;svn:keywords=Id

Blair

[1] https://trac.macports.org/changeset/109477

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

Re: [109465] trunk/dports/java

[Ryan Schmidt]

On Aug 15, 2013, at 17:39, easie...@macports.org wrote:

> Revision: 109465
>  https://trac.macports.org/changeset/109465
> Author:   easie...@macports.org
> Date: 2013-08-15 15:39:45 -0700 (Thu, 15 Aug 2013)
> Log Message:
> ---
> maven-devel: track maven-3.1.0.
> 
> Maven 3.1.x replaces the Sonatype Aether connector with the new
> Apache-engineered one.  Should be a good thing over time, but will be
> "bumpy" for tools that use Aether to introspect the distributed POM
> graph (like lang/abcl).

> Added: trunk/dports/java/maven-devel/Portfile

> +supported_archs noarch

> +use_configure no
> +# hmm?  
> +universal_variant no 

"universal_variant no" is implied by both "use_configure no" (because the 
default universal variant is for autotools configure scripts, and 
"use_configure no" means you don't have a configure script) and 
"supported_archs noarch" (because if you're not installing any 
architecture-specific files then there is no such thing as a universal build of 
that).


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

Re: [109460] trunk/dports/security/certsync/Portfile

[Joshua Root]

On 2013-8-16 08:15 , Daniel J. Luke wrote:
> On Aug 15, 2013, at 6:09 PM, Joshua Root  wrote:
>>> Revision: 109460
>>>  https://trac.macports.org/changeset/109460
>>> Author:   landonf at macports.org
>>> Date: 2013-08-15 15:01:38 -0700 (Thu, 15 Aug 2013)
>>> Log Message:
>>> ---
>>> Enable 10.5 as a minimum target version
>>>
>>> Modified Paths:
>>> --
>>>trunk/dports/security/certsync/Portfile
>>>
>>> Modified: trunk/dports/security/certsync/Portfile
>>> ===
>>> --- trunk/dports/security/certsync/Portfile 2013-08-15 21:57:55 UTC (rev 
>>> 109459)
>>> +++ trunk/dports/security/certsync/Portfile 2013-08-15 22:01:38 UTC (rev 
>>> 109460)
>>> @@ -38,7 +38,7 @@
>>> build {
>>> system -W ${worksrcpath} "${configure.objc} \
>>> ${configure.objcflags} \
>>> -   -mmacosx-version-min=10.6 \
>>> +   -mmacosx-version-min=10.5 \
>>
>> Shouldn't this be using $macosx_deployment_target?
>>
>> And presumably this means that the code doesn't work on 10.4, so other
>> ports shouldn't depend on certsync on 10.4?
> 
> 
> do we care about 10.4 (I don't think we should). The only reason why it's a 
> little bit reasonable to care about 10.5 is that it's the last release that 
> runs on ppc machines.
> 
> In both cases, Apple isn't releasing updates for them anymore...

Sure, everything < 10.6 is nominally unsupported. Base still works back
to 10.4 and some maintainers choose to support those versions.

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

Re: [109460] trunk/dports/security/certsync/Portfile

[Craig Treleaven]

until the next generation MacBook Pros are announced, which I'm 
hoping is on September 10th.


I think the chances of that are slim to none.  Doesn't make sense for 
Apple to 'dilute' an iPhone event with Mac announcements.


Craig
(Not that I have any inside information.)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [109460] trunk/dports/security/certsync/Portfile

[Blair Zajac]

On 08/15/2013 03:15 PM, Daniel J. Luke wrote:

do we care about 10.4 (I don't think we should). The only reason why it's a 
little bit reasonable to care about 10.5 is that it's the last release that 
runs on ppc machines.


Yes, please, our 5 year iMac went belly up so all I'm left with is our 
PPC PowerBook until the next generation MacBook Pros are announced, 
which I'm hoping is on September 10th.


Blair


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

Re: error on build through MacPorts but not on manual build (pkg-config problem?)

[Davide Liessi]

2013/8/15 Davide Liessi:
> Anyway the Portfile seems to work correctly when not using trace mode,
[...]
> I still would like to test trace mode in MacPorts trunk.

I did a couple of changes to the Portfile.
I installed MacPorts from current trunk and tried to install
py27-python-poppler-qt4 with trace mode.
It builds and installs correctly.

Thanks for your help.

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

Re: [109460] trunk/dports/security/certsync/Portfile

[Daniel J. Luke]

On Aug 15, 2013, at 6:09 PM, Joshua Root  wrote:
>> Revision: 109460
>>  https://trac.macports.org/changeset/109460
>> Author:   landonf at macports.org
>> Date: 2013-08-15 15:01:38 -0700 (Thu, 15 Aug 2013)
>> Log Message:
>> ---
>> Enable 10.5 as a minimum target version
>> 
>> Modified Paths:
>> --
>>trunk/dports/security/certsync/Portfile
>> 
>> Modified: trunk/dports/security/certsync/Portfile
>> ===
>> --- trunk/dports/security/certsync/Portfile  2013-08-15 21:57:55 UTC (rev 
>> 109459)
>> +++ trunk/dports/security/certsync/Portfile  2013-08-15 22:01:38 UTC (rev 
>> 109460)
>> @@ -38,7 +38,7 @@
>> build {
>>  system -W ${worksrcpath} "${configure.objc} \
>>  ${configure.objcflags} \
>> --mmacosx-version-min=10.6 \
>> +-mmacosx-version-min=10.5 \
> 
> Shouldn't this be using $macosx_deployment_target?
> 
> And presumably this means that the code doesn't work on 10.4, so other
> ports shouldn't depend on certsync on 10.4?


do we care about 10.4 (I don't think we should). The only reason why it's a 
little bit reasonable to care about 10.5 is that it's the last release that 
runs on ppc machines.

In both cases, Apple isn't releasing updates for them anymore...
--
Daniel J. Luke  
 
++  
  
| * dl...@geeklair.net * |  

| *-- http://www.geeklair.net -* |  

++  
  
|   Opinions expressed are mine and do not necessarily   |  

|  reflect the opinions of my employer.  |  

++



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

[109458] trunk/dports/security/certsync

[Joshua Root]

> Revision: 109458
>   https://trac.macports.org/changeset/109458
> Author:   landonf at macports.org
> Date: 2013-08-15 14:38:43 -0700 (Thu, 15 Aug 2013)
> Log Message:
> ---
> Add work-arounds for Mac OS X 10.5, based on patch from dluke.
> 
> Issue: 40082

Trac will generate a link to the ticket if you prefix the ticket number
with '#' or 'ticket:', JFYI.

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

Re: fail2ban update to v0.8.10 - commit needed

[Lawrence Velázquez]

On Aug 15, 2013, at 5:48 PM, Francois Claire  wrote:

> Can someone please check ticket #40121 and commit the files ?

Thanks. https://trac.macports.org/changeset/109462

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

[109460] trunk/dports/security/certsync/Portfile

[Joshua Root]

> Revision: 109460
>   https://trac.macports.org/changeset/109460
> Author:   landonf at macports.org
> Date: 2013-08-15 15:01:38 -0700 (Thu, 15 Aug 2013)
> Log Message:
> ---
> Enable 10.5 as a minimum target version
> 
> Modified Paths:
> --
> trunk/dports/security/certsync/Portfile
> 
> Modified: trunk/dports/security/certsync/Portfile
> ===
> --- trunk/dports/security/certsync/Portfile   2013-08-15 21:57:55 UTC (rev 
> 109459)
> +++ trunk/dports/security/certsync/Portfile   2013-08-15 22:01:38 UTC (rev 
> 109460)
> @@ -38,7 +38,7 @@
>  build {
>   system -W ${worksrcpath} "${configure.objc} \
>   ${configure.objcflags} \
> - -mmacosx-version-min=10.6 \
> + -mmacosx-version-min=10.5 \

Shouldn't this be using $macosx_deployment_target?

And presumably this means that the code doesn't work on 10.4, so other
ports shouldn't depend on certsync on 10.4?

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

fail2ban update to v0.8.10 - commit needed

[Francois Claire]

Hi,

Can someone please check ticket #40121 and commit the files ?

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

Re: distfiles fetched via get variables

[Bradley Giesbrecht]

On Aug 15, 2013, at 10:33 AM, Rainer Müller wrote:

> On 2013-08-14 19:12, Bradley Giesbrecht wrote:
>> name pcsxr
>> version 1.9.92
>> 
>> Fetch via curl:
>> curl 
>> "http://download-codeplex.sec.s-msft.com/Download/Release?ProjectName=pcsxr&DownloadId=140521&FileTime=12925482962180&Build=20686";
>>  -o pcsxr-1.9.92.tar.bz2
>> 
>> Are there fetch variables, something like fetch.url, that can be used in a 
>> Portfile to fetch such a url?
> 
> This recipe should cover this problem:
> https://trac.macports.org/wiki/PortfileRecipes#fetchwithgetparams

Thank you Rainer.


Regards,
Bradley Giesbrecht (pixilla)

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

Re: distfiles fetched via get variables

[Rainer Müller]

On 2013-08-14 19:12, Bradley Giesbrecht wrote:
> name pcsxr
> version 1.9.92
> 
> Fetch via curl:
> curl 
> "http://download-codeplex.sec.s-msft.com/Download/Release?ProjectName=pcsxr&DownloadId=140521&FileTime=12925482962180&Build=20686";
>  -o pcsxr-1.9.92.tar.bz2
> 
> Are there fetch variables, something like fetch.url, that can be used in a 
> Portfile to fetch such a url?

This recipe should cover this problem:
https://trac.macports.org/wiki/PortfileRecipes#fetchwithgetparams

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

Re: [109338] trunk/dports/archivers/lzip/Portfile

[Rainer Müller]

On 2013-08-15 10:08, Ryan Schmidt wrote:
>> Modified Paths:
>> --
>>trunk/dports/archivers/lzip/Portfile
> 
>> +checksums   rmd160  cab15b04900c9355e4b2f6eec3c07c756046195d \
>> +sha256  
>> 7ff5cc521560edb2a0a6cdf258cf3afdaeb1dbcc354d96d011d0dd7ec584cbe7
>> +
>> +configure.args  CXX=${configure.cxx} \
>> +CXXFLAGS=${configure.cxxflags} \
>> +CPPFLAGS=${configure.cppflags} \
>> +LDFLAGS=${configure.ldflags}
> 
> This doesn't work right, because these values could (and as of MacPorts 2.2, 
> configure.ldflags does) contain spaces; only the first value before the space 
> was actually used.
> 
> In addition, this doesn't include -arch flags, so the universal variant 
> wasn't actually universal.
> 
> Fixed: https://trac.macports.org/changeset/109418

Ugh, how could I be this wrong? Usually I know this stuff (especially
the quotes) and right now I am even fully aware of
[get_canonical_archflags].

Thank you!

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

Re: [109415] trunk/dports

[Ryan Schmidt]

On Aug 15, 2013, at 11:38, Jeremy Huddleston Sequoia  
wrote:

> 
> On Aug 14, 2013, at 23:58, ryandes...@macports.org wrote:
> 
>> Revision
>> 109415
>> Author
>> ryandes...@macports.org
>> Date
>> 2013-08-14 23:58:50 -0700 (Wed, 14 Aug 2013)
>> Log Message
>> 
>> revbump ports that link with libgd in their default configuration to rebuild 
>> with gd2 @2.1.0 (libgd.3.dylib)
> 
> Shouldn't we be revbumping ports that link against gd2 in non-default 
> variants as well?

I did not think so, because most users aren't using those variants, our 
buildbots haven't built packages of them, and any users who are using them will 
automatically get those ports rebuilt via rev-upgrade.

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

Re: [109415] trunk/dports

[Jeremy Huddleston Sequoia]

On Aug 14, 2013, at 23:58, ryandes...@macports.org wrote:

> Revision
> 109415
> Author
> ryandes...@macports.org
> Date
> 2013-08-14 23:58:50 -0700 (Wed, 14 Aug 2013)
> Log Message
> 
> revbump ports that link with libgd in their default configuration to rebuild 
> with gd2 @2.1.0 (libgd.3.dylib)

Shouldn't we be revbumping ports that link against gd2 in non-default variants 
as well?




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

Re: [109428] trunk/dports/science/gnuradio/Portfile

[Ryan Schmidt]

On Aug 15, 2013, at 08:23, michae...@macports.org wrote:

> Revision: 109428
>  https://trac.macports.org/changeset/109428
> Author:   michae...@macports.org
> Date: 2013-08-15 06:23:19 -0700 (Thu, 15 Aug 2013)
> Log Message:
> ---
> gnuradio: VOLK requires an Apple GCC variant (including the ones from 
> MacPorts), for now; blacklist all others, for now.  Addresses ticket #37979.
> 
> Modified Paths:
> --
>trunk/dports/science/gnuradio/Portfile
> 
> Modified: trunk/dports/science/gnuradio/Portfile
> ===
> --- trunk/dports/science/gnuradio/Portfile2013-08-15 13:11:47 UTC (rev 
> 109427)
> +++ trunk/dports/science/gnuradio/Portfile2013-08-15 13:23:19 UTC (rev 
> 109428)
> @@ -139,14 +139,14 @@
> configure.dir   ${vpath}
> build.dir   ${vpath}
> 
> -# VOLK compiles best with GCC of some type;
> -# print a warning if using clang
> +# VOLK requires an Apple GCC variant (including the ones from
> +# MacPorts), for now; blacklist all others, for now.
> 
> -pre-configure {
> -if {${configure.compiler} == "clang"} {
> -ui_msg "WARNING: GNU Radio's VOLK component (which handles vector 
> optimized instructions and routines) compiles best when using GCC.  The 
> selected compiler is CLANG, which will result in a fully functioning GNU 
> Radio install but the VOLK component will not utilize the CPU's capabilities."
> -}
> -}
> +compiler.blacklist \
> +clang macports-gcc-4.1 macports-gcc-4.2 macports-gcc-4.3 \
> +macports-gcc-4.4 macports-gcc-4.5 macports-gcc-4.6 macports-gcc-4.7 \
> +macports-gcc-4.8 macports-clang-2.9 macports-clang-3.0 \
> +macports-clang-3.1 macports-clang-3.2

Note that there is no gcc41 port; the gcc42 port will be deleted soon; there 
are gcc49, clang33 and clang34 ports which you may also want to blacklist.

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

Re: [109333] trunk/dports/devel/akonadi/Portfile

[Bradley Giesbrecht]

On Aug 14, 2013, at 8:32 PM, Joshua Root wrote:

> On 2013-8-15 11:53 , Ryan Schmidt wrote:
>> 
>> On Aug 13, 2013, at 10:01, ni...@macports.org wrote:
>> 
>>> +variant no_root description {Run the akonadi server start as MacPorts 
>>> install user.} {
>>> +pre-fetch {
>>> +if { ${install.user}=="root" || ${install.group}=="wheel" } {
>>> +ui_error "The akonadi server should not be run as root with 
>>> no_root variant."
>>> +error "Please do not use this variant with your MacPorts 
>>> configuration."
>>> +}
>>> +}
>>> +
>>> +set startup_root  [join [lrange [exec /usr/bin/dscl . -read 
>>> Users/${install.user} NFSHomeDirectory] 1 end]]
>>> +# Files are installed into user's startup directory.
>>> +destroot.violate_mtree  yes
>>> +}
>> 
>> Variant names beginning with "no_" are deprecated; please don't create new 
>> ones. Usually you should instead use a positively-named variant and use 
>> default_variants to turn it on by default, but in this case that would be 
>> weird too since this variant implements a nonstandard function. Is a variant 
>> really needed at all? Couldn't the port detect whether the user's MacPorts 
>> install is as root or not, and react accordingly? That would seem best.
> 
> Yes it could check [getuid], but since this is affecting where the plist
> is installed, that wouldn't help if the port is built (as root) on a
> different machine than it's installed on (as not-root).
> 
> This whole installing the plist in the user's home dir thing seems odd
> though, as all the ports using base's StartupItem code don't do that for
> non-root installs. The plist is still present in
> ${prefix}/Library/LaunchDaemons even if it's not linked into
> /Library/LaunchDaemons, and presumably you could tell the user to load
> it from there.


Right, doesn't installing anything in the users home potentially break for 
multiple user systems?


Regards,
Bradley Giesbrecht (pixilla)

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

Re: error on build through MacPorts but not on manual build (pkg-config problem?)

[Clemens Lang]

On Thu, Aug 15, 2013 at 02:25:00PM +0200, Davide Liessi wrote:
> I still would like to test trace mode in MacPorts trunk. Should I
> replace my MacPorts 2.2 installation or install to a different
> MacPorts prefix?

You can overwrite your installation of 2.2. No internal data structures
(like the layout of the registry db) are modified, so you can also go
back to 2.2 by installing it over your trunk installation.

-- 
Clemens Lang

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

Re: Geant4 Licence and binary distributability

[Mojca Miklavec]

On Mon, Jul 8, 2013 at 2:14 PM, Joshua Root wrote:
> On 2013-7-8 18:39 , Mojca Miklavec wrote:
>> On Sun, Jul 7, 2013 at 11:22 PM, Joshua Root wrote:
>>>
>>> Be careful not to conflate "free", "permissive", and "distributable".
>>
>> Like Ryan said: I have no idea what each term means and I'm not an
>> expert (and don't want to be).
>
> Getting this stuff wrong potentially causes us to break the law. You
> don't have to be a legal expert, and I'm certainly not one, but you do
> need to at least read and understand the software's license, and make
> some effort to think through its implications, before you set the
> license field in a portfile.
>
> "Free" has no special meaning for us and is kind of a fuzzy term in
> general use. "Distributable" simply means that we are allowed to
> distribute binaries. That's not used in the license field, because
> whether we can distribute a port depends on its dependencies' licenses
> as well as the port's own.
>
> "Permissive" for us roughly means a license that has no more
> restrictions than the MIT/X11, (new) BSD, or zlib licenses. Because it's
> a general category rather than a specific license, it shouldn't be used
> for any license that conflicts with another license, since those
> conflicts will be specific to that one license and not the entire category.
>
>>> This is certainly not as permissive as MIT or BSD, and it looks to me
>>> like it would conflict with the GPL. Debian agrees:
>>
>> So in short: Should I use one of those terms (say, "distributable", if
>> permissive is not appropriate) or should MacPorts core know about the
>> Geant licence?
>
> Not sure. At worst you could probably call it Restrictive/Distributable.

I checked the binary distributability with
port_binary_distributable.tcl -v geant4.9.6

It turns out that iAIDA's dependency grace->pdflib makes iAIDA
nondistributable, but iAIDA doesn't seem to be required for Geant4 any
more. (On the other hand Geant4 doesn't provide any switch to turn it
on or off - it's used if it's found.)

If I remove iAIDA from the list of dependencies then:
- "Permissive" lincence allows distributability of Geant4
- "Restrictive/Distributable" licence prevents distributability
because of root's dependency on gsl which is 'GPL-3+'

I tried to remove +gsl from Root and then it would be stuck at
root->graphviz->gts->jbigkit. So after removing "+gsl +graphviz" from
root and removing "iAIDA" from Geant4, Geant4 becomes binary
distributable if "Restrictive/Distributable" licence is used.

The reason why I'm so concerned about binary distributability is
because it takes ages to compile Geant4 (I think it's 40 minutes on 2
core 2,26 MHz laptop).

But I guess that there is not much that could be done in this case?

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

Re: error on build through MacPorts but not on manual build (pkg-config problem?)

[Davide Liessi]

2013/8/15 Clemens Lang :
> On Thu, Aug 15, 2013 at 02:24:38AM +0200, Davide Liessi wrote:
>> /opt/local/include/poppler/qt4/poppler-qt4.h is provided by: poppler
>> /opt/local/include/poppler/qt4/poppler-link.h is provided by: poppler
>
> it seems to me those files are only provided by poppler when installed
> with the +qt4 variant.

Correct.

> Make sure you also have that enabled on your
> current installation of poppler

It is. In fact the port is correctly built if I don't use trace mode.

> (or use the active_variants 1.1
> portgroup).

I did, as suggested by Ryan Schmidt.

Anyway the Portfile seems to work correctly when not using trace mode,
so I think I'll submit a ticket in short time.
I attach the latest version of my Portfile.

I still would like to test trace mode in MacPorts trunk.
Should I replace my MacPorts 2.2 installation or install to a
different MacPorts prefix?

Thanks.
Davide Liessi


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

Re: wxPython versus wxWidgets

[Mojca Miklavec]

On Thu, Aug 15, 2013 at 2:04 AM, Ryan Schmidt wrote:
> On Aug 14, 2013, at 09:17, Mojca Miklavec wrote:
>> On Wed, Aug 14, 2013 at 3:29 PM, Michael Dickens wrote:
>>> Other questions:
>>>
>>> + Why set "dist_subdir ${distname}/${version}"?  Why not just
>>> ${distname}?
>>
>> Simply because that's the way it's set up in current
>> wxWidgets/wxWidgets30/wxWidgets-devel Portfiles and the new ports
>> would use the existing distfiles. If that sounds like deprecated
>> behaviour, it can easily be changed.
>>
>> I checked and one of my other ports, gnuplot, also uses this strategy,
>> mainly because the pdf documentation always has the same name (it
>> comes from a different location, but under the same filename).
>
> Stealth updates are one reason why we change a port's dist_subdir; sharing 
> distfiles with other ports, to avoid users having to download (or our mirrors 
> having to mirror) the same file multiple times is another. If the setting 
> you've chosen will result in users and mirrors not having to download a 
> second copy of a file they already have, then by all means please keep it, 
> but consider changing it back to the default if and when the ports are 
> updated to a version that has not yet been fetched by anybody.

OK, this makes perfect sense. So I won't change dist_subdir of
wxWidgets until the next version of wxWidgets gets released. OK, users
will then end up with something like
/opt/local/var/macports/distfiles/wxWidgets/2.8.12/wxWidgets-2.8.12.tar.bz2
/opt/local/var/macports/distfiles/wxWidgets/2.9.0/wxWidgets-2.9.0.tar.bz2
...
/opt/local/var/macports/distfiles/wxWidgets/2.9.5/wxWidgets-2.9.5.tar.bz2
/opt/local/var/macports/distfiles/wxWidgets/wxWidgets-2.9.6.tar.bz2
but so be it.

But I have a question about wxPython. The port py-wxpython30 seems to
store the file(s) to
/opt/local/var/macports/distfiles/py-wxpython30/wxPython-src-2.9.4.0.tar.bz2
and py-wxpython-devel seems to store *the same* file to
/opt/local/var/macports/distfiles/python/wxPython-src-2.9.4.0.tar.bz2

The first one (py-wxpython30) seems a bit unfortunate to keep because
py-wxpython30 will be gone (and so will py-wxpython). Many py-foo
ports store the files to /opt/local/var/macports/distfiles/py-foo, but
I've seen some in /opt/local/var/macports/distfiles/python. I don't
know why, but I do have both
/opt/local/var/macports/distfiles/py-numpy/numpy-1.6.1.tar.gz
/opt/local/var/macports/distfiles/python/numpy-1.6.1.tar.gz
for example.

But to continue ...

The port py-wxpython stores the file(s) to
/opt/local/var/macports/distfiles/py-wxpython/wxPython-src-2.8.12.1.tar.bz2
and wxWidgets-python stores *the same* file to

/opt/local/var/macports/distfiles/wxWidgets-python/wxPython-src-2.8.12.0.tar.bz2
(ok, not exactly the same because "the nomaintainer" forgot to update it)
while py26-wxpython stores what's also supposed to be the same file to
/opt/local/var/macports/distfiles/python/wxPython-src-2.8.10.1.tar.bz2

Plus, I'm actually surprised to see that 2.8.10 and 2.8.12 work with
each other: py26-wxpython namely depends on wxWidgets-python.

Which one should be used in long term and which one should I keep now?

And how exactly should I set "dist_subdir" inside
wxPython(-from-wxWidgets)-3.0 which will share the sources with
py-wxpython-3.0? Given the zillions of different locations that
apparently store the same file I'm not even sure if the argument "use
the same location that is being used at the moment" can be applied in
a meaningful way.

I was first planning to keep using
   /opt/local/var/macports/distfiles/wxWidgets/2.8.12
   /opt/local/var/macports/distfiles/wxWidgets/2.9.5
   /opt/local/var/macports/distfiles/wxWidgets/2.9.6
and in the same spirit use
   /opt/local/var/macports/distfiles/wxPython/2.9.4.0
but I can easily change it to whatever feels more appropriate.

Please advise.

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

Re: error on build through MacPorts but not on manual build (pkg-config problem?)

[Clemens Lang]

Hi,

On Thu, Aug 15, 2013 at 02:24:38AM +0200, Davide Liessi wrote:
> /opt/local/include/poppler/qt4/poppler-qt4.h is provided by: poppler
> /opt/local/include/poppler/qt4/poppler-link.h is provided by: poppler

it seems to me those files are only provided by poppler when installed
with the +qt4 variant. Make sure you also have that enabled on your
current installation of poppler (or use the active_variants 1.1
portgroup).

-- 
Clemens Lang

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

Re: py-poppler variants vs separate ports

[Davide Liessi]

2013/8/15 Sterling Smith :
> Also, we should try to avoid collisions in filespace; here are the contents 
> of my py-poppler (sub)port
> {{{
> $ port contents py-poppler
> Port py-poppler contains:
>   /opt/local/share/doc/py-poppler/README
> $ port contents py27-poppler
> Port py27-poppler contains:
>   
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/poppler.la
>   
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/poppler.so
> }}}

There shouldn't be any collisions:

$ port contents py27-python-poppler-qt4
Port py27-python-poppler-qt4 contains:
  
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/popplerqt4.so
  
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/python_poppler_qt4-0.16.3-py2.7.egg-info/PKG-INFO
  
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/python_poppler_qt4-0.16.3-py2.7.egg-info/SOURCES.txt
  
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/python_poppler_qt4-0.16.3-py2.7.egg-info/dependency_links.txt
  
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/python_poppler_qt4-0.16.3-py2.7.egg-info/top_level.txt

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

Re: Resolving Python conflicts (in wxPython)

[Mojca Miklavec]

On Thu, Aug 15, 2013 at 2:07 AM, Ryan Schmidt wrote:
> If possible, ports should not conflict. The way to make them not conflict is 
> not to try to install the same file to the same location from multiple ports. 
> Rename the files or install them to different locations.
>
> There may be places in the code of the project where the files are referenced 
> by name or location which would have to be patched to accommodate the rename 
> or move. And if it is a public file that other ports are expected to use, 
> then that magnifies the problem since they all would need to know about the 
> rename or move as well.

I inspected the situation a bit.

(1) First about the conflict between py26-* and py27-* (an ancient
ticket is here for example: https://trac.macports.org/ticket/19190).
They seem to install exactly the same files to exactly the same
location (header files, swig interface, python files, ... - all just
literal copies from the sources). I can resolve the conflict by:
- manually copying (a nontrivial subset of the files) from sources
when installing the main py-* port
- deleting these files in post-destroot phase of py2X-*.
- making py-* a dependency of py2X-*.
It will be ugly and I'm not sure that many users really need that
functionality (at the moment py26-wxpython30 doesn't even exist), but
if that's desirable, I can do it. An alternative is to make the port
provide just "python.versions 27" ;) which is what it does now and
only implement that ugly hack if py28 or py33 will ever be needed. Or
maybe do this just for wxPython 2.8 which currently provides support
for four versions of python.

(2) About the conflict between wxPython 2.8 and 2.9: I didn't inspect
closely yet, but this seems a bigger problem. Most probably because
users simply do
   import wx
inside the python sources and I have no clue how to tell python that a
different version of "wx" should be used.

The easiest workaround is probably to install py27-wxpython-3.0 and
py26-wxpython-2.8 which means that wxWidgets 2.8 would be used with
Python 2.6 and wxWidgets 2.9 would be used with Python 2.7. But maybe
someone else can enlighten me by pointing out a possible solution.

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

Re: [109338] trunk/dports/archivers/lzip/Portfile

[Ryan Schmidt]

On Aug 13, 2013, at 11:18, rai...@macports.org wrote:

> Revision: 109338
>  https://trac.macports.org/changeset/109338
> Author:   rai...@macports.org
> Date: 2013-08-13 09:18:20 -0700 (Tue, 13 Aug 2013)
> Log Message:
> ---
> archives/lzip:
> Update to version 1.14
> 
> Modified Paths:
> --
>trunk/dports/archivers/lzip/Portfile

> +checksums   rmd160  cab15b04900c9355e4b2f6eec3c07c756046195d \
> +sha256  
> 7ff5cc521560edb2a0a6cdf258cf3afdaeb1dbcc354d96d011d0dd7ec584cbe7
> +
> +configure.args  CXX=${configure.cxx} \
> +CXXFLAGS=${configure.cxxflags} \
> +CPPFLAGS=${configure.cppflags} \
> +LDFLAGS=${configure.ldflags}

This doesn't work right, because these values could (and as of MacPorts 2.2, 
configure.ldflags does) contain spaces; only the first value before the space 
was actually used.

In addition, this doesn't include -arch flags, so the universal variant wasn't 
actually universal.

Fixed: https://trac.macports.org/changeset/109418


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