Re: [macports-ports] branch master updated: berkeleygw: Remove svn $Id$ line.

[Sean Farley]

Rainer Müller <rai...@macports.org> writes:

> On 2016-11-01 19:23, Sean Farley wrote:
>> Lawrence Velázquez <lar...@macports.org> writes:
>> 
>>> You should set your repository's user.email to your MacPorts email address.
>> 
>> Is this really necessary? I've seen mention of a mailmap but that hardly
>> seems like a big enough reason to force us to change user.email.
>> 
>> I'm pushing back on this, by the way, because I'd like to keep the fact
>> that I have one email for all the projects I've contributed to and this
>> is the first time there's been an email requirement.
>
> This is no hard requirement. However, all your existing commits were
> attributed to your @macports.org mail address.

Ah, I forgot I did my own custom map since I was using hgsubversion.

> I am only aware of one case where the commit author email address will
> be used:
>
> When you close a ticket with "Closes
> ​https://trac.macports.org/ticket/...; in a commit message, a comment
> will automatically be added to the corresponding ticket. This comment
> will be attributed to the author of the commit. By using the same email
> address for your commits that is also configured in Trac, you ensure
> that these comments will be properly attributed to you.

That is a fairly compelling reason so I'll go with that.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [macports-ports] branch master updated: berkeleygw: Remove svn $Id$ line.

[Sean Farley]

Lawrence Velázquez  writes:

> You should set your repository's user.email to your MacPorts email address.

Is this really necessary? I've seen mention of a mailmap but that hardly
seems like a big enough reason to force us to change user.email.

I'm pushing back on this, by the way, because I'd like to keep the fact
that I have one email for all the projects I've contributed to and this
is the first time there's been an email requirement.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Sean Farley]

Lawrence Velázquez <lar...@macports.org> writes:

>> On Oct 31, 2016, at 5:50 PM, Sean Farley <s...@macports.org> wrote:
>> 
>> I'm not sure I agree with attempting to modify the git repo at all. For
>> example, what if I'm in the middle of bisecting and need to add/remove a
>> port? Why does 'port sync' call at all what the state is?
>
> Updating the repository is the whole point of "port sync". If you just
> want to refresh your portindex, you should be running "portindex
> /path/to/ports/tree".

Alrighty then. I'll change my alias.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Sean Farley]

Ryan Schmidt  writes:

> I don't want to understand git's theory or to be given lots of options 
> amongst which to choose; I just want to be told how to get my work done.

I had a thoroughly good chuckle reading this. It is the number one sin
of the design of git, IMHO.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Sean Farley]

"Eric A. Borisch"  writes:

> Thanks for all the hard work with this transition! I'm sure once we're all
> "over the hump" we'll look back and wonder why we waited so long.
>
> Just so I'm clear on this, is the desired approach for each committer to:
>
> == setup ==
> 1) clone macports/macports-ports to the local filesystem
> == every change ==
> 2) make changes
> 3) 'add' changes
> 4) 'commit' changes
> 5) 'push' changes (to macports-ports)
>
> Oh, and and to capture upstream changes, somewhere after 1 and before 5 (4?
> 3?),
>
> a) git fetch
> b) git rebase origin/master
> It looks like git pull --rebase does both of those, so that's not too bad.

I've noticed that when I do this and I run 'port sync', macports
apparently tries to rebase? 9 times out of 10 I wind up in a detached
head state.

I'm not sure I agree with attempting to modify the git repo at all. For
example, what if I'm in the middle of bisecting and need to add/remove a
port? Why does 'port sync' call at all what the state is?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Objection to restoring deprecated Python subports

[Sean Farley]

Lawrence Velázquez  writes:

> Fred Wright recently opened several tickets that suggest restoring
> several Python subports that were deprecated and moved to the Python
> graveyard a long time ago.
>
> https://trac.macports.org/ticket/52636
> https://trac.macports.org/ticket/52637
> https://trac.macports.org/ticket/52638
> https://trac.macports.org/ticket/52639
> https://trac.macports.org/ticket/52640
> https://trac.macports.org/ticket/52641
> https://trac.macports.org/ticket/52642
>
> I strenuously object to these proposals.

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

Re: port:lapack useful?

[Sean Farley]

Takeshi Enomoto  writes:

> Dear David,
>
>> I just noticed that you created a port lapack (including BLAS) in r146856. 
>> Is this really useful? We already have the ATLAS port which provides BLAS 
>> and LAPACK; the OpenBLAS port which provides exactly the same implementation 
>> of LAPACK from netlib as your port lapack; and the built-in Accelerate 
>> Framework and the vecLibFort port providing a Fortran interface for it. All 
>> of these are optimized and therefore should be faster than the 
>> straightforward netlib implementation, and use directly of 
>> Accelerate/vecLibFort is of course by far the fastest to install. So, what 
>> is the use of a separate port lapack? I suspect its main effect will be to 
>> have users or port packagers use this one instead of an optimized 
>> implementation because they do not realize the optimized ones exist. For 
>> example, see the recent r153943. I would suggest removing it.
>
> I started LAPACK port to provide man pages after Apple removed them.
> Some email exchanges with the LAPACK developers I became aware of the 
> followings:
>
> * LAPACK from netlib is active.

So many things I could say but I will refrain.

> * the man pages can be generated from LAPACK source by make man.
> * the most of the performance gain is due to BLAS, which can be obtained from 
> BLAS.
> * CBLAS and LAPACKE can be provided.
>
> I believe that there is nothing to be harmful to leave the port.

Yeah, that's fine with me. I see there's a linear_algebra portgroup
which should abstract away all these ports, correct (perhaps with some
extra work)?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [152202] trunk/dports/devel

[Sean Farley]

Ryan Schmidt  writes:

>> On Aug 31, 2016, at 3:59 PM, s...@macports.org wrote:
>> 
>> Revision
>> 152202
>> Author
>> s...@macports.org
>> Date
>> 2016-08-31 13:59:44 -0700 (Wed, 31 Aug 2016)
>> Log Message
>> 
>> folly: add new port
>> Added Paths
>> 
>>  • trunk/dports/devel/folly/
>> 
>
>> +depends_lib-append  port:boost \
>> +port:python27 \
>> +port:gflags \
>> +port:google-glog \
>> +port:double-conversion \
>> +port:libevent \
>> +port:snappy \
>> +port:lz4 \
>> +port:lzma \
>> +port:xz \
>> +port:openssl \
>> +port:zlib \
>> +port:zstd
>
> A dependency on openssl should be written "path:lib/libssl.dylib:openssl" 
> unless you know of a reason why it does not work with libressl.

Ah, I forgot that libressl exists. Unfortunately, it does indeed fail to
build with libressl. I'll add a comment to the portfile.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Rev bumping mpi dependents

[Sean Farley]

Joshua Root <j...@macports.org> writes:

> On 2016-7-21 09:24 , Brandon Allbery wrote:
>> On Wed, Jul 20, 2016 at 7:21 PM, Sean Farley <s...@macports.org
>> <mailto:s...@macports.org>> wrote:
>>
>> OpenMPI just released 2.0 which will change the name of the libraries.
>> I'm guessing I should revbump all the dependents to force a rebuild but
>> is this something that `port rev-upgrade` should handle?
>>
>>
>> I think you can get into trouble with the automatic rev-upgrade catching
>> it, if it causes an upgrade for other reasons to fail? At the very least
>> it could be inefficient by causing multiple rounds of rebuilding
>> triggered during the rev-upgrade at the end of a normal upgrade.
>
> The biggest reason to rev bump is that if you don't, the archives are 
> useless. They get downloaded and installed, then rev-upgrade immediately 
> detects that the linking is broken and rebuilds from source.

Ah, of course, good point.

> If the original question was about whether the rev bumping should be 
> automated, well, maybe. We could certainly run rev-upgrade in report 
> mode on all a port's dependents after it is updated. Do we then want the 
> system automatically committing a rev bump? I'm not so sure. It might be 
> better to just email a warning to the maintainers.

One day, I'd like bots that try to update a port automatically and send
the patch to the maintainers. Hopefully, this would include rev bumping
but that's a far off dream right now.

> A concept of an archive revision as distinct from a port revision might 
> be useful here.

Yeah, that's not a bad idea either.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Rev bumping mpi dependents

[Sean Farley]

OpenMPI just released 2.0 which will change the name of the libraries.
I'm guessing I should revbump all the dependents to force a rebuild but
is this something that `port rev-upgrade` should handle?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [150004] trunk/dports/python/py-ipython/Portfile

[Sean Farley]

Rainer Müller  writes:

> On 2016-07-08 10:34, Clemens Lang wrote:
>> - On 8 Jul, 2016, at 07:59,  s...@macports.org wrote:
>> 
>>> [150004] trunk/dports/python/py-ipython/Portfile
>>> Revision 150004
>>> Author s...@macports.org
>>> Date 2016-07-07 22:59:39 -0700 (Thu, 07 Jul 2016)
>>> Log Message py-ipython: update to 5.0.0
>> 
>> I'm seeing a checksum failure for this change when fetched from 
>> https://github.com/ipython/ipython/tarball/5.0.0:
>> 
>> --->  Checksumming ipython-5.0.0.tar.gz
>> Error: Checksum (rmd160) mismatch for ipython-5.0.0.tar.gz
>> Portfile checksum: ipython-5.0.0.tar.gz rmd160 
>> 9160a6f37e8364d0dce6fc7a41ed4e1c1b81dbb3
>> Distfile checksum: ipython-5.0.0.tar.gz rmd160 
>> 2bd45ecded8dd0425db4604675f8ef709ad7189a
>> Error: Checksum (sha256) mismatch for ipython-5.0.0.tar.gz
>> Portfile checksum: ipython-5.0.0.tar.gz sha256 
>> 7ec0737169c74056c7fc8298246db5478a2d6c90cfd19c3253222112357545df
>> Distfile checksum: ipython-5.0.0.tar.gz sha256 
>> 7e0023896ceca69d3150cef76276b1c0e825e84eee287c7d0717703ceb3c8818
>> The correct checksum line may be:
>> checksums   rmd160  2bd45ecded8dd0425db4604675f8ef709ad7189a \
>> sha256  
>> 7e0023896ceca69d3150cef76276b1c0e825e84eee287c7d0717703ceb3c8818
>> Error: Failed to checksum py27-ipython: Unable to verify file checksums
>
> I guess you first fetched the file from pypi and updated the checksums,
> before switching to the github portgroup. As the distfile already
> existed locally, it was never fetched again during testing. I verified
> the checksums matched against pypi, so my theory seems correct.
>
> I went ahead and udpated the checksums for github:
> http://trac.macports.org/changeset/150006

D'oh! You are correct. That is exactly what happened.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [146550] trunk/dports/devel/libgit2/Portfile

[Sean Farley]

David Evans <dev...@macports.org> writes:

> On 3/14/16 4:38 PM, Sean Farley wrote:
>> Thanks for following through!
>> 
>> libgit2 makes so many breaking api changes that its subprojects (pygit2,
>> libgit2-glib, etc.) should really be part of the same repo so that they
>> all get updated and released at the same time.
>
> libgit2-glib is actually a subproject of and maintained as a component of 
> gitg.  It only exists because libgit2 doesn't
> provide the introspection data required by gitg which is written in vala.

Personal rant: something, something same repo. (pygit2 might even be
worse in this regard)

>> I've already forked pygit2 to download and install the corresponding
>> libgit2 version so that it can be installed into a virtualenv. Quite the
>> hack, but seems to work for now.
>
> libgit2 and libgit2-glib updated to version 0.24.0 in r146698 after a quick 
> response
> from the gitg developers.
>
> Sorry you had to do this.  Hopefully, we can coordinate better in the future.

No worries. I think this is a great example of having per branch builds
/ code review before things go into main.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [146550] trunk/dports/devel/libgit2/Portfile

[Sean Farley]

David Evans <dev...@macports.org> writes:

> On 3/14/16 10:53 AM, Sean Farley wrote:
>> 
>> David Evans <dev...@macports.org> writes:
>> 
>>> On 3/11/16 2:55 PM, s...@macports.org wrote:
>>>> Revision
>>>> 146550 <https://trac.macports.org/changeset/146550>
>>>> Author
>>>> s...@macports.org
>>>> Date
>>>> 2016-03-11 14:55:34 -0800 (Fri, 11 Mar 2016)
>>>>
>>>>
>>>>   Log Message
>>>>
>>>> libgit2: update to 0.24.0
>>>>
>>>>
>>>>   Modified Paths
>>>>
>>>>   * trunk/dports/devel/libgit2/Portfile <#trunkdportsdevellibgit2Portfile>
>>>>
>>>>
>>>>   Diff
>>>>
>>>>
>>>> Modified: trunk/dports/devel/libgit2/Portfile (146549 => 146550)
>>>>
>>>> --- trunk/dports/devel/libgit2/Portfile 2016-03-11 22:55:33 UTC (rev 
>>>> 146549) +++ trunk/dports/devel/libgit2/Portfile
>>>> 2016-03-11 22:55:34 UTC (rev 146550) @@ -8,8 +8,7 @@ cmake.out_of_source 
>>>> yes # don't forget to update libgit2-glib as
>>>> well -github.setup libgit2 libgit2 0.23.4 v -revision 4 +github.setup 
>>>> libgit2 libgit2 0.24.0 v categories devel
>>>> platforms darwin maintainers juanrgar devans openmaintainer
>>>>
>>>>
>>>>
>>>>
>>>
>>> I've been holding off on updating this port to version 0.24.0 due to the 
>>> fact that the current version of libgit2-glib
>>> will only build with the previous version.
>> 
>> And other ports must suffer for some lame glib fork?
>
>> 
>>> Would appreciate it if you would revert this update until a compatible 
>>> version is available upstream.
>> 
>> Now pygit2 is broken. Thanks for wrecking my work day. If you must have
>> an older version, the usual way to create another port (e.g. libgit23).
>
> I note that you updated the version of libgit2 without checking with me or 
> checking the compatibility of
> dependents other than those you are interested in. I would have told you 
> there was an issue that was blocking
> the upgrade.
>
> This is the second time that you've arbitrarily modified this port without 
> consultation or regard for the consequences
> to other ports.
>
> pygit2 is only broken because you updated to a version that requires 0.24.0.  
> It was working fine with the previous version.
>
> I expect the problem with libgit2-glib to be resolved shortly.  If not, of 
> course, I will do as you say and create a
> compatibility version of libgit2 but as of now that doesn't seem necessary.
>
> I'm glad to work with you to come to a resolution of this problem that 
> doesn't cause breakage of any ports.  However,
> I've got to say that I'm a bit put off by your arrogant attitude and your 
> unwillingness to work cooperatively with others.

If I come off as arrogant, my apologies. I like to move fast and this
makes working with me difficult.

For what it's worth, I'm testing a script that automatically updates a
port so we can (potentially) have a bot that tries to update every
outdated port and report what breaks. This caused me to miss your
comment.

But I understand that not many people like working with me and my
efforts are rarely appreciated. Though I still think libgit2-glib is a
sorry excuse for a project.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [146550] trunk/dports/devel/libgit2/Portfile

[Sean Farley]

David Evans  writes:

> On 3/11/16 2:55 PM, s...@macports.org wrote:
>> Revision
>> 146550 
>> Author
>> s...@macports.org
>> Date
>> 2016-03-11 14:55:34 -0800 (Fri, 11 Mar 2016)
>> 
>> 
>>   Log Message
>> 
>> libgit2: update to 0.24.0
>> 
>> 
>>   Modified Paths
>> 
>>   * trunk/dports/devel/libgit2/Portfile <#trunkdportsdevellibgit2Portfile>
>> 
>> 
>>   Diff
>> 
>> 
>> Modified: trunk/dports/devel/libgit2/Portfile (146549 => 146550)
>> 
>> --- trunk/dports/devel/libgit2/Portfile 2016-03-11 22:55:33 UTC (rev 146549) 
>> +++ trunk/dports/devel/libgit2/Portfile
>> 2016-03-11 22:55:34 UTC (rev 146550) @@ -8,8 +8,7 @@ cmake.out_of_source yes 
>> # don't forget to update libgit2-glib as
>> well -github.setup libgit2 libgit2 0.23.4 v -revision 4 +github.setup 
>> libgit2 libgit2 0.24.0 v categories devel
>> platforms darwin maintainers juanrgar devans openmaintainer
>> 
>> 
>> 
>>
>
> I've been holding off on updating this port to version 0.24.0 due to the fact 
> that the current version of libgit2-glib
> will only build with the previous version.

And other ports must suffer for some lame glib fork?

> Would appreciate it if you would revert this update until a compatible 
> version is available upstream.

Now pygit2 is broken. Thanks for wrecking my work day. If you must have
an older version, the usual way to create another port (e.g. libgit23).
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [144621] trunk/dports/python/py-numpy/Portfile

[Sean Farley]

Joshua Root <j...@macports.org> writes:

> On 2016-1-15 05:51 , Sean Farley wrote:
>> 
>> Joshua Root <j...@macports.org> writes:
>> 
>>>> Revision: 144621
>>>>   https://trac.macports.org/changeset/144621
>>>> Author:   sean at macports.org
>>>> Date: 2016-01-13 23:29:24 -0800 (Wed, 13 Jan 2016)
>>>> Log Message:
>>>> ---
>>>> py-numpy: numpy needs fortran, so require it
>>>
>>> We've been through this before; numpy does not need fortran, its fortran
>>> support is optional.
>> 
>> No, it is not optional. Trying running 'numpy.test()'. Or try compiling
>> with 'atlas +nofortran'. Not having fortran will generate a broken numpy
>> library.
>> 
>> Side note: We should consider getting rid of 'atlas +nofortran'. I
>> haven't found a port that depends on atlas but works without fortran.
>
> What you're saying is that to use fortran with numpy you need to enable
> its fortran support. Well, yes.
>
> If you're just using, say, pyopengl, then no, you don't need fortran
> support.

While a project *might* not need numpy's fortran, numpy expects a
fortran compiler:

"you’ll also need a FORTRAN 77 compiler installed." [1]

This means any dependent of numpy is correct in assuming that the python
compiler wrappers that numpy provide will have fortran. The amount of
headache this solves for us, I believe, far outweighs not having
fortran.

Until we can reliably depend on variants, I don't want a broken numpy
library installed (same with my feelings of removing atlas +nofortran).
It just causes too much headache.

[1] http://docs.scipy.org/doc/numpy-1.10.1/user/install.html
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [144621] trunk/dports/python/py-numpy/Portfile

[Sean Farley]

Joshua Root  writes:

>> Revision: 144621
>>   https://trac.macports.org/changeset/144621
>> Author:   sean at macports.org
>> Date: 2016-01-13 23:29:24 -0800 (Wed, 13 Jan 2016)
>> Log Message:
>> ---
>> py-numpy: numpy needs fortran, so require it
>
> We've been through this before; numpy does not need fortran, its fortran
> support is optional.

No, it is not optional. Trying running 'numpy.test()'. Or try compiling
with 'atlas +nofortran'. Not having fortran will generate a broken numpy
library.

Side note: We should consider getting rid of 'atlas +nofortran'. I
haven't found a port that depends on atlas but works without fortran.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Survey: How do you commit?

[Sean Farley]

Ryan Schmidt  writes:

> Quick survey for committers:
>
> How do you commit to the MacPorts Subversion repository?
>
> Using a Subversion working copy and "svn commit"?
> Using a Git clone and git-svn?
> Some other method?

hgsubversion :-)

> Do you have any complaints about that method or are you happy with it?

It's alright. I prefer Mercurial, of course, but it seems like git is
the de facto standard for open source nowadays.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [143330] trunk/dports/devel/docker-machine/Portfile

[Sean Farley]

Sean Farley <s...@macports.org> writes:

> Ryan Schmidt <ryandes...@macports.org> writes:
>
>>> On Dec 12, 2015, at 11:31 AM, s...@macports.org wrote:
>>> 
>>> Revision
>>> 143330
>>> Author
>>> s...@macports.org
>>> Date
>>> 2015-12-10 16:21:17 -0800 (Thu, 10 Dec 2015)
>>> Log Message
>>> 
>>> docker-machine: add bash variant and fix build; closes #49952
>>> Modified Paths
>>> 
>>> • trunk/dports/devel/docker-machine/Portfile
>>> Diff
>>> 
>>> Modified: trunk/dports/devel/docker-machine/Portfile (143329 => 143330)
>>> 
>>
>>> +eval xinstall -m 755 [glob ${worksrcpath}/bin/*] 
>>> ${destroot}${prefix}/bin/
>>> +
>>> +if {[variant_isset bash_completion]} {
>>> +set completions_path ${prefix}/share/bash-completion/completions
>>> +xinstall -d ${destroot}${completions_path}
>>> +eval xinstall -m 644 [glob 
>>> ${worksrcpath}/contrib/completion/bash/*.bash] 
>>> ${destroot}${completions_path}/
>>> +}
>>
>> See port lint in trunk:
>>
>>
>> $ port lint docker-machine
>> --->  Verifying Portfile for docker-machine
>> Warning: Line 37 should use the expansion operator instead of the eval 
>> procedure. Change
>> Warning: eval xinstall -m 755 [glob ${worksrcpath}/bin/*] 
>> ${destroot}${prefix}/bin/
>> Warning: to
>> Warning: xinstall -m 755 {*}[glob ${worksrcpath}/bin/*] 
>> ${destroot}${prefix}/bin/
>> Warning: Line 42 should use the expansion operator instead of the eval 
>> procedure. Change
>> Warning: eval xinstall -m 644 [glob 
>> ${worksrcpath}/contrib/completion/bash/*.bash] 
>> ${destroot}${completions_path}/
>> Warning: to
>> Warning: xinstall -m 644 {*}[glob 
>> ${worksrcpath}/contrib/completion/bash/*.bash] 
>> ${destroot}${completions_path}/
>
> Huzzah! Will do.

It seems there is an error in our linter:

--->  Verifying Portfile for docker-machine
Warning: Line 37 should use the expansion operator instead of the eval 
procedure. Change
Warning: eval xinstall -m 755 {*}[glob ${worksrcpath}/bin/*] 
${destroot}${prefix}/bin/
Warning: to
Warning: xinstall -m 755 {*}{*}[glob ${worksrcpath}/bin/*] 
${destroot}${prefix}/bin/
Warning: Line 42 should use the expansion operator instead of the eval 
procedure. Change
Warning: eval xinstall -m 644 {*}[glob 
${worksrcpath}/contrib/completion/bash/*.bash] ${destroot}${completions_path}/
Warning: to
Warning: xinstall -m 644 {*}{*}[glob 
${worksrcpath}/contrib/completion/bash/*.bash] ${destroot}${completions_path}/
--->  0 errors and 2 warnings found.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [143330] trunk/dports/devel/docker-machine/Portfile

[Sean Farley]

Ryan Schmidt  writes:

>> On Dec 12, 2015, at 11:31 AM, s...@macports.org wrote:
>> 
>> Revision
>> 143330
>> Author
>> s...@macports.org
>> Date
>> 2015-12-10 16:21:17 -0800 (Thu, 10 Dec 2015)
>> Log Message
>> 
>> docker-machine: add bash variant and fix build; closes #49952
>> Modified Paths
>> 
>>  • trunk/dports/devel/docker-machine/Portfile
>> Diff
>> 
>> Modified: trunk/dports/devel/docker-machine/Portfile (143329 => 143330)
>> 
>
>> +eval xinstall -m 755 [glob ${worksrcpath}/bin/*] 
>> ${destroot}${prefix}/bin/
>> +
>> +if {[variant_isset bash_completion]} {
>> +set completions_path ${prefix}/share/bash-completion/completions
>> +xinstall -d ${destroot}${completions_path}
>> +eval xinstall -m 644 [glob 
>> ${worksrcpath}/contrib/completion/bash/*.bash] 
>> ${destroot}${completions_path}/
>> +}
>
> See port lint in trunk:
>
>
> $ port lint docker-machine
> --->  Verifying Portfile for docker-machine
> Warning: Line 37 should use the expansion operator instead of the eval 
> procedure. Change
> Warning: eval xinstall -m 755 [glob ${worksrcpath}/bin/*] 
> ${destroot}${prefix}/bin/
> Warning: to
> Warning: xinstall -m 755 {*}[glob ${worksrcpath}/bin/*] 
> ${destroot}${prefix}/bin/
> Warning: Line 42 should use the expansion operator instead of the eval 
> procedure. Change
> Warning: eval xinstall -m 644 [glob 
> ${worksrcpath}/contrib/completion/bash/*.bash] ${destroot}${completions_path}/
> Warning: to
> Warning: xinstall -m 644 {*}[glob 
> ${worksrcpath}/contrib/completion/bash/*.bash] ${destroot}${completions_path}/

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

Re: New Mac OS Forge administrator

[Sean Farley]

Ryan Schmidt  writes:

> Dear MacPorts users and developers,
>
> I'm pleased finally to be able to tell you that I have been hired to be your 
> new Mac OS Forge administrator. I have been involved in improving MacPorts 
> for years as a committer and as a manager, and now as a Mac OS Forge 
> administrator I will work on ensuring our infrastructure runs smoothly too.
>
> I apologize for the downtime we've experienced in the past months. My 
> priority right now is to resolve the existing issues, as I become familiar 
> with the systems.
>
> Please continue to report new problems with MacPorts infrastructure (server 
> not working) as you have before, using the server/hosting component in Trac 
> or via email to admin at macosforge dot org. And continue to report MacPorts 
> administrative issues (mailing list issues, commit access requests) to 
> portmgr at macports dot org.
>
> Thanks for your patience and support and thank you for using MacPorts.

This is great for MacPorts! Congrats!
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Owner of MacPorts account on GitHub

[Sean Farley]

Clemens Lang <c...@macports.org> writes:

> Hi,
>
> - On 12 Nov, 2015, at 19:48, Sean Farley s...@macports.org wrote:
>
>> Sure, it could include Jira, HipChat, and Bamboo, if you want. I only
>> said 'lost cause' because GitHub is so popular for open source projects.
>
> I don't think we would have a use case for HipChat, but I like Jira (even
> though Trac isn't too bad either and moving would be considerable effort).

I, too, like IRC more than HipChat :-) So much so that I wrote an ERC
module to make the bitlbee support better:

http://bitbucket.org/seanfarley/erc-hipchatify

> The Bamboo agent runs on OS X, which could be used with our build servers,
> but support for older Java versions is deprecated, which could become a
> problem for our older OS buildbots :/

That's a good point.

> Is Crucible possible as well? Not that we currently do any code reviews,
> but it could become a useful development model to make contributions
> easier.

Sure but I've actually never used it. I mostly just use Bitbucket
commenting.

>> We have the Bamboo service which integrates with Bitbucket and we can
>> set up for open source projects. I can do it personally so as to skip
>> the form filling out.
>
>> Bamboo just spins up Amazon vms but having these dedicated machines from
>> MacOSForge is pretty nice.
>
> Yeah, the Amazon VMs don't really buy us anything apart from the Linux
> base builder, which is the least of our problems. OS X on Amazon EC2 isn't
> going to happen.

Yeah, I totally didn't even think about that. >_< We'd still need
somewhere that has physical Apple hardware (I'm pretty sure there is
some extra hardware here, I'd just need to ask IT).
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Owner of MacPorts account on GitHub

[Sean Farley]

Ryan Schmidt <ryandes...@macports.org> writes:

> On Nov 12, 2015, at 3:04 AM, Mojca Miklavec wrote:
>> On Wed, Nov 11, 2015 at 11:37 AM, Ryan Schmidt wrote:
>>> On Nov 10, 2015, at 10:57 PM, Mojca Miklavec wrote:
>>>> 
>>>> At the moment it's the lack of Trac's functionality to browse the tree
>>>> and the logs that has triggered the "demand" for this.
>>> 
>>> That will get fixed. In asking about github, we're just trying to explore 
>>> all options.
>> 
>> I hope so at least. But until this gets fixed (and it might take a
>> while before it does), it would be extremely helpful to have an
>> up-to-date git mirror to be able to browse through the changes in a
>> slightly more "user-friendly" way than with the command-line only.
>> 
>> I could use
>>https://github.com/neverpanic/macports-ports
>> now that you mentioned it, but that one is also not being synced
>> automatically (yet).
>> 
>> Clemens, are you willing to set up some (temporary) repository with
>> regular updates, even if it's not perfect yet, just so that we can
>> follow the changes? (I can offer to run a script for incremental
>> updates on my server if there is a need for that.)
>
> We will get the existing infrastructure back up and running soon. Please bear 
> with us a little while longer.
>
>
>> On Wed, Nov 11, 2015 at 11:39 PM, Sean Farley wrote:
>>> Clemens Lang writes:
>>> 
>>>> [1] https://github.com/neverpanic?tab=repositories
>>>> [2] https://github.com/neverpanic/svn2git
>>>> [3] https://github.com/neverpanic/macports-svn2git-rules
>>> 
>>> Sounds like this is a lost cause for me, but for what it's worth, I work
>>> at Bitbucket now and we could offer hosting (plus direct admin support).
>> 
>> What exactly do you consider "lost" and why?
>
> Good to know, Sean, and thanks for the offer. Would that refer only to the 
> usual services that BitBucket offers, or additional services as well? Mac OS 
> Forge currently provides us much more than just repository, issue tracker and 
> wiki.

Sure, it could include Jira, HipChat, and Bamboo, if you want. I only
said 'lost cause' because GitHub is so popular for open source projects.

>> At the moment we are (hopefully) discussing just a mirror of the code
>> being put on some server, still hoping that everything will get back
>> to normal. This mirroring can be done on any of the existing services
>> (github, bitbucket, gitlab, ...) or even on all of them at the same
>> time.
>> 
>> Mojca
>> 
>> (Off-topic, but: If we were discussing other services, the biggest
>> problem would probably be all the buildbots anyway, and I doubt that
>> BitBucket would be interested in helping out with that. Purchasing the
>> necessary hardware alone would be expensive enough. We currently have
>> 10 virtual machines and we could easily request 5 or more right now
>> [two for 10.11, three for libc++ on 10.6-10.8, potentially another
>> bunch of them for universal binaries] and two new ones each year after
>> the release of a new OS. All of that has to run on Macs with
>> sufficient memory, disk space and potentially more than one core per
>> buildbot.)

We have the Bamboo service which integrates with Bitbucket and we can
set up for open source projects. I can do it personally so as to skip
the form filling out.

> There are currently six buildbot slave VMs, five of which run OS X (Snow 
> Leopard, Lion, Mountain Lion, Mavericks, Yosemite) and run two buildbot 
> builders each -- one for ports, one for base -- and one which runs Oracle 
> Linux with a single buildbot builder for base. A seventh VM has been 
> requested for El Capitan and I've been told that should be a resource 
> problem, it's just a matter of setting it up, which will happen soon.
>
> Hardware for a replacement buildbot system is not a problem, if that becomes 
> necessary.

Bamboo just spins up Amazon vms but having these dedicated machines from
MacOSForge is pretty nice.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Owner of MacPorts account on GitHub

[Sean Farley]

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://www.macosforge.org/post/git-mirrors/
>>> but since they are not up to date anyway, it would be better to make
>>> new ones from scratch and also include a semi-hand-crafted authors
>>> transformation file.
>> 
>> I did some experiments on working with git-svn and documented the work
>> on the wiki. Clemens did more exhaustive experiments for a Git
>> conversion (keeping branches etc).
>
> I have a work-in-progress state up to r14 pushed at my github account
> [1] (see all repos with a macports- prefix). Feel free to go through that
> and check whether anything is missing that you would need.
>
> I took the liberty of shuffling some things around (e.g. I moved the
> Pallet code into a separate repository).
>
> I used svn2git from the KDE project, with a patch to fix an issue with
> SVN 1.9. My source is at [2]. The scripts and rules I used to convert
> are available at [3]. Those already include a complete authors file.
>
> What would still need to be done:
>  - Clean up tags that were created and deleted by excluding the revisions
>that created and deleted them in the svn2git rules.
>  - Check that the history is nice and clean, especially when it comes to
>merges in repositories that were in the same repo in SVN, but no longer
>are after the conversion.
>  - Automate this to a point where it will continuously mirror the SVN.
>
> [1] https://github.com/neverpanic?tab=repositories
> [2] https://github.com/neverpanic/svn2git
> [3] https://github.com/neverpanic/macports-svn2git-rules

Sounds like this is a lost cause for me, but for what it's worth, I work
at Bitbucket now and we could offer hosting (plus direct admin support).
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Persistent copy of a [git] repository

[Sean Farley]

Mojca Miklavec  writes:

> Reposting the question ... I would be grateful for some feedback (and
> someone who could help me move the code to the core or some PortGroup
> in case that the approach sounds reasonable enough).

Have we looked into wrapping git/hg commands so that we could just keep
the working tree? Something like,

# keep a pristine copy
git clone URL /path/to/distfiles/on/disk

# "extract" the repo
git clone /path/to/distfiles/on/disk /path/to/worksrcpath
git checkout HASH_FROM_PORTFILE

Then, if the portfile changes, we can delete the worksrcpath like normal
and probably just run 'git fetch' to make sure the pristine copy is up
to date.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Showing the full ./configure command also with -v, not just with -d

[Sean Farley]

Mojca Miklavec  writes:

> Hi,
>
> I would really appreciate it if I could see the complete configure
> command already in verbose mode (port -v configure), not just debug
> mode (port -d configure). The same applies to build/make, but usually
> that one doesn't contain so much extra parameters.
>
> The command "port -d ..." is wy too verbose, hardly useful for any
> port maintainer, and it's sometimes very difficult to find the
> relevant output, while "port -v ..." seems just perfect for showing
> that. We already get hundreds of lines of output during "./configure",
> so one extra line would bring a lot of benefit with hardly any
> penalty.
>
> (Environmental variables would also be very helpful, even though I
> wouldn't know whether they make more sense in verbose or debug mode. I
> would like to see them in verbose mode as well, but it's still ok if
> they are more hidden than the configure command itself.)

I have wanted this for a very long time!
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [140114] trunk/dports/lang/julia/Portfile

[Sean Farley]

Ryan Schmidt  writes:

>> On Sep 9, 2015, at 4:27 PM, s...@macports.org wrote:
>> 
>> Revision
>> 140114
>> Author
>> s...@macports.org
>> Date
>> 2015-09-09 14:27:38 -0700 (Wed, 09 Sep 2015)
>> Log Message
>> 
>> julia: fix livecheck to not include release candidates
>
>> Modified: trunk/dports/lang/julia/Portfile (140113 => 140114)
>
>> +livecheck.regex archive/[join ${github.tag_prefix} 
>> ""](\[^"-\]+)${extract.suffix}
>
> It would be nice if the github portgroup would default to only showing stable 
> releases so that ports would not have to override livecheck.regex. There 
> could be a switch ports could flip if they really want other versions. See 
> the php 1.1 portgroup which has such a switch for ports hosted on pecl 
> (php.pecl.prerelease yes). Though it might be harder to implement. The php 
> 1.1 portgroup has it easy in that pecl tags each release as "beta" or 
> "stable"; with github we might have to guess based on the format of the 
> version number.

That sounds good. If I recall correctly, you were the original author of
that portgroup, so I support your efforts :-) (I am seriously low on
time).
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [140120] trunk/dports/devel/mercurial/Portfile

[Sean Farley]

Ryan Schmidt  writes:

> On Sep 9, 2015, at 4:27 PM, s...@macports.org wrote:
>
>> Revision
>> 140120
>> Author
>> s...@macports.org
>> Date
>> 2015-09-09 14:27:44 -0700 (Wed, 09 Sep 2015)
>> Log Message
>> 
>> mercurial-devel: update to newest commit
>
>> Modified: trunk/dports/devel/mercurial/Portfile (140119 => 140120)
>
>> +post-extract {
>> +reinplace "s,A list of merge success-checking options::,A list of 
>> merge success-checking options:," ${worksrcpath}/mercurial/help/config.txt
>> +}
>
> This should be done in a patchfile rather than by using reinplace.

I disagree. It's already fixed upstream and was a quick hack so I could
proceed with clearing out my backlog. The next update will delete it.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Upgrading rust to 1.2.0

[Sean Farley]

I've been looking at rust and thought I'd upgrade it to 1.2.0. I think
the bootstrapping is no longer needed since version 1.0 (the one we were
using was old as well).

Here is the patch I've come up with for upgrading. I was hoping to get
some feedback from those that know rust better than I. Thanks!


# HG changeset patch
# User Sean Farley <s...@farley.io>
# Date 1441301774 25200
#  Thu Sep 03 10:36:14 2015 -0700
# Node ID 7e8d821769e7bd4fd3083688841bc505afe5e779
# Parent  b7d548b79f4fec0a1126d3a47e96c12584ff975e
rust: update to 1.2.0 and prefer clang

This also drops the code to download a specific staging distribution because
rust has been able to do that since 1.0.0.

diff --git a/dports/lang/rust/Portfile b/dports/lang/rust/Portfile
--- a/dports/lang/rust/Portfile
+++ b/dports/lang/rust/Portfile
@@ -4,11 +4,11 @@
 PortSystem  1.0
 PortGroup   active_variants 1.1
 PortGroup   compiler_blacklist_versions 1.0
 
 namerust
-version 1.0.0
+version 1.2.0
 categories  lang devel
 platforms   darwin
 supported_archs i386 x86_64
 # https://github.com/mozilla/rust/issues/2024
 universal_variant   no
@@ -37,43 +37,18 @@ pre-fetch {
 # snapshot compiler, we let base treat it as the distfile and deal with
 # the actual Rust source "manually".
 
 # Download the snapshot compiler; see src/snapshots.txt in the Rust
 # distribution.
-master_siteshttps://static.rust-lang.org/dist/:main \
-https://static.rust-lang.org/stage0-snapshots/:snap
+master_siteshttps://static.rust-lang.org/dist/:main
 
 distfiles   ${name}c-${version}-src${extract.suffix}:main
 worksrcdir  ${name}c-${version}
 
 checksums   ${name}c-${version}-src${extract.suffix} \
-rmd160  b1127e616619fcd981e33896d4f00c4bf548ce6b \
-sha256  
c304cbd4f7b25d116b73c249f66bdb5c9da8645855ce195a41bda5077b995eba
-
-set stage0(distdir) rust-stage0
-set stage0(date)2015-03-27
-set stage0(rev) 5520801
-set stage0(platform)macos-${configure.build_arch}
-set stage0(hash)[expr {${configure.build_arch} eq "i386" ?
-"0310b1a970f2da7e61770fd14dbbbdca3b518234" :
-"5f35d9c920b8083a7420ef8cf5b00d5ef3085dfa"}]
-
-set stage0_name [join "rust stage0 ${stage0(date)}
-   ${stage0(rev)}
-   ${stage0(platform)}
-   ${stage0(hash)}" -].tar.bz2
-
-distfiles-append${stage0_name}:snap
-
-switch ${configure.build_arch} {
-i386{checksums-append   ${stage0_name} \
-rmd160  15a0ffbcee0def1a056d69aa851edf2b8ca490b6 \
-sha256  
0cc20c5f3c808d6332bcc192b60d6a1e9ee313d481030d8d07ff42a831492ba2}
-default {checksums-append   ${stage0_name} \
-rmd160  a5ef6ad68e6e49b40d045e45227ad858b0935988 \
-sha256  
38076751be5a52a61285cced36879832a7a106d7ce0bfd2b2080c3cfc42de1ce}
-}
+rmd160  83a98c67a0aca97467d21150fa6a95fc77d10cc1 \
+sha256  
ea6eb983daf2a073df57186a58f0d4ce0e85c711bec13c627a8c85d51b6a6d78
 
 # Only use compilers supported by upstream
 # (https://github.com/rust-lang/rust#building-from-source).
 compiler.blacklist  {clang < 211} \
 *dragonegg* \
@@ -112,13 +87,12 @@ if {${configure.build_arch} eq "i386"} {
 # We need to use "--enable-rpath" as of a0546de, otherwise the build
 # produces improperly linked binaries.
 # (https://github.com/rust-lang/rust/issues/11747)
 # TODO: Build docs also, probably in a subport.
 configure.args  --disable-docs \
---enable-local-rust \
 --enable-rpath \
---local-rust-root=${workpath}/${stage0(distdir)}
+--enable-clang
 
 build.type  gnu
 build.args  VERBOSE=1 \
 CC=${configure.cc} \
 CXX=${configure.cxx} \
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: llvm-3.7 release and OpenMP

[Sean Farley]

Jeremy Huddleston Sequoia  writes:

>> On Sep 3, 2015, at 09:21, Jack Howarth  wrote:
>> 
>>   You really will want to rewrite the llvm37 Portfile to use a cmake
>> build.
>
> Not unless we can depend on cmake existing out-of-tree.  If we need to depend 
> on port:cmake, that introduces cycles.


How? I only see these as dependencies for cmake:

$ port rdeps cmake
The following ports are dependencies of cmake @3.3.1_0:
  curl
pkgconfig
  libiconv
gperf
zlib
  xz
gettext
  expat
  ncurses
openssl
curl-ca-bundle
  perl5
perl5.16
  gdbm
  bzip2
  libarchive
libxml2
lzo2

I see that libomp depends on cmake but cmake doesn't depend on libomp
nor llvm so how is it a cycle?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: llvm-3.7 release and OpenMP

[Sean Farley]

Jeremy Huddleston Sequoia <jerem...@macports.org> writes:

>> On Sep 3, 2015, at 10:32, Sean Farley <s...@macports.org> wrote:
>> 
>> 
>> Jeremy Huddleston Sequoia <jerem...@macports.org> writes:
>> 
>>>> On Sep 3, 2015, at 09:21, Jack Howarth <howarth.at.macpo...@gmail.com> 
>>>> wrote:
>>>> 
>>>>  You really will want to rewrite the llvm37 Portfile to use a cmake
>>>> build.
>>> 
>>> Not unless we can depend on cmake existing out-of-tree.  If we need to 
>>> depend on port:cmake, that introduces cycles.
>> 
>> 
>> How? I only see these as dependencies for cmake:
>> 
>> $ port rdeps cmake
>> The following ports are dependencies of cmake @3.3.1_0:
>>  curl
>>pkgconfig
>>  libiconv
>>gperf
>>zlib
>>  xz
>>gettext
>>  expat
>>  ncurses
>>openssl
>>curl-ca-bundle
>>  perl5
>>perl5.16
>>  gdbm
>>  bzip2
>>  libarchive
>>libxml2
>>lzo2
>> 
>> I see that libomp depends on cmake but cmake doesn't depend on libomp
>> nor llvm so how is it a cycle?
>
> You're not looking at build dependencies.
>
> On older OS veersions, cmake requires either macports-clang-X.Y (for libc++ 
> clients) or macports-gcc-X.Y (for libstdc++ clients) to compile due to its 
> C++11 requirement.

Ah, I see more dependencies now. The only C++11 requirements I see
though are with the 'gui' variant. So, wouldn't we be able to depend on
'cmake -gui' or am I missing something else?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [MacPorts] #48721: unable to import py27-netcdf4

[Sean Farley]

Oliver Angélil molofi...@gmail.com writes:

 The following ports are currently installed:

   netcdf @4.3.3.1_2+dap+netcdf4 (active)

Please comment on the issue page and not the mailing list. Thanks.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: El Capitan Buildbot

[Sean Farley]

Ryan Schmidt ryandes...@macports.org writes:

 On Aug 16, 2015, at 4:21 PM, Sean Farley wrote:
 
 Ryan Schmidt writes:
 
 On Aug 16, 2015, at 14:49, Sean Farley wrote:
 
 Since the public beta of El Capitan has been out for a while, is there
 any chance we can get a buildbot set up so that we're ready for the
 release?
 
 In the past, we haven't set up a build server for an OS until it public 
 release. It's conceivable that something would change between now and final 
 release that would necessitate rebuilding packages...
 
 Well, it's a buildbot. We could just, you know, rebuild things.

 We've never had the situation arise before, so we don't have a procedure in 
 place for accomplishing that, so I'd rather not risk getting into that 
 situation.

So maybe we should create a procedure for that?

 In the
 recent past, the main delay has been allocating the resources for a new
 buildbot, so I figured getting the ball rolling now might help getting
 the buildbot sooner.

 This is true, and I've put in a request:

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

Thanks!

 I think this would be a great time to get reports on which packages have
 trouble building on El Capitan before the main release.

 Perhaps, but after a buildbot build server is initially set up, it takes 
 weeks to build all ports. The resulting log would surely be gigabytes in 
 size. I doubt anyone would be interested in downloading and analyzing that.

I definitely would.

 If you have 10.11 beta installed, I recommend you install the ports you 
 maintain, and work on fixing any problems you encounter (both with your ports 
 directly or with their dependencies, with proper maintainer approval, of 
 course). If everyone does this in advance of the 10.11 release, that'll be a 
 great help.

Sure, but as a fair warning to others, El Capitan broke things[1] so I
needed to install 10.11 on an extra computer.

[1] 
http://superuser.com/questions/935756/mac-os-el-capitan-10-11-not-able-to-connect-to-wifiwpa-2-enterprise
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: El Capitan Buildbot

[Sean Farley]

Jeremy Lavergne jer...@lavergne.gotdns.org writes:

 While the beta is a public release, it is under NDA.

 Don’t blog, post screen shots, tweet, or publicly post information about the 
 public beta software, and don't discuss the public beta software with or 
 demonstrate it to others who are not in the Apple Beta Software Program. If 
 Apple has publicly disclosed technical information about the public beta 
 software, it is no longer considered confidential.
 https://beta.apple.com/sp/betaprogram/faq

 Sadly, one must say this means a buildslave is not yet a viable option—even 
 though the beta OS release is open the public.

Darn. Could we at least allocate another buildslave with Yosemite so
that when El Capitan is release, we could at least upgrade right away?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: El Capitan Buildbot

[Sean Farley]

Jeremy Lavergne jer...@lavergne.gotdns.org writes:

 That's a good idea. We could actually schedule downtime for the Yosemite box 
 to be cloned then :-o (we could clear out all artifacts to possibly speed up 
 the process).

 But once it's released: how quickly could someone update the OS on this new 
 buildslave?

 It's still a blackbox of hope.

Tears of unfathomable sadness :'(
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: El Capitan Buildbot

[Sean Farley]

Ryan Schmidt ryandes...@macports.org writes:

 On Aug 16, 2015, at 14:49, Sean Farley wrote:
 
 Since the public beta of El Capitan has been out for a while, is there
 any chance we can get a buildbot set up so that we're ready for the
 release?

 In the past, we haven't set up a build server for an OS until it public 
 release. It's conceivable that something would change between now and final 
 release that would necessitate rebuilding packages...

Well, it's a buildbot. We could just, you know, rebuild things. In the
recent past, the main delay has been allocating the resources for a new
buildbot, so I figured getting the ball rolling now might help getting
the buildbot sooner.

I think this would be a great time to get reports on which packages have
trouble building on El Capitan before the main release.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

El Capitan Buildbot

[Sean Farley]

Since the public beta of El Capitan has been out for a while, is there
any chance we can get a buildbot set up so that we're ready for the
release?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [138907] trunk/dports/devel

[Sean Farley]

Ryan Schmidt ryandes...@macports.org writes:

 On Jul 22, 2015, at 4:33 PM, s...@macports.org wrote:
 
 Revision
 138907
 Author
 s...@macports.org
 Date
 2015-07-22 14:33:13 -0700 (Wed, 22 Jul 2015)
 Log Message
 
 editorconfig-core-c: add new port for editor config files
 Added Paths
 
  • trunk/dports/devel/editorconfig-core-c/
  • trunk/dports/devel/editorconfig-core-c/Portfile
 Diff
 
 Added: trunk/dports/devel/editorconfig-core-c/Portfile (0 = 138907)
 
 --- trunk/dports/devel/editorconfig-core-c/Portfile  
 (rev 0)
 +++ trunk/dports/devel/editorconfig-core-c/Portfile  2015-07-22 21:33:13 UTC 
 (rev 138907)
 
 @@ -0,0 +1,26 @@
 
 +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
 c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
 +# $Id$
 +
 +PortSystem  1.0
 +PortGroup   github 1.0
 +PortGroup   cmake 1.0
 +
 +github.setupeditorconfig editorconfig-core-c 0.12.0 v
 +license BSD
 +categories  devel
 +maintainers sean openmaintainer
 +description EditorConfig makes it easy to maintain the correct 
 coding style
 +long_description \
 +   This code produces a program that accepts a filename as input and will \
 +   look for .editorconfig files with sections applicable to the given file, 
 \
 +   outputting any properties found.
 +
 +platforms   darwin
 +
 +depends_build   port:cmake

 The cmake 1.0 portgroup adds the build dependency on the cmake port for you.

Ah, right, thanks for pointing that out.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Variants +clang3{0,1,2} ...

[Sean Farley]

Ryan Schmidt ryandes...@macports.org writes:

 On Apr 25, 2015, at 11:53 AM, petr wrote:
 
 On 25 Apr 2015, at 17:49, Lawrence Velázquez wrote:
 
 On Apr 25, 2015, at 5:49 AM, petr wrote:
 
 To my understanding the +clang3{0,1,2} refer to clang-3.{0,1,2} 
 respectively.
 
 Yup.
 
 These clang ports are no obsolete.
 
 Yup.
 
 However, there are still quite some ports around with these variants, so I 
 guess these clang3{0,1,2} variants (and maybe others) should be removed?
 
 Yup.
 
 Okay,
 anything else which should be considered for a variant cleanup? 
 
 I guess the same applies to dragonegg3?  dragonegg33. I would also propose 
 to remove all +gcc4?  gcc47 and all related openmpi and mpich variants. I 
 am CCing Sean and Eric explicitly for their involvement in compiler 
 Portgroup, openmpi or mpich, respectively.

 The clang30, clang31 and clang32 variants should be removed from any ports 
 where they exist because the clang-3.0, clang-3.1 and clang-3.2 ports they 
 depend on are already marked as being replaced by clang-3.4, so they already 
 cannot be installed and those variants are already broken.

 The gcc variants you mention, on the other hand, should still be working 
 fine, since the corresponding gcc ports still exist and should still work 
 fine. So I have no particular rush or inclination to do any mass removal of 
 these variants. Or would removing them solve some problem you're having?

Yeah, I would agree with Ryan here. I can work on updating the compilers
portgroup and see where that leads.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Current best practice to select GCC compiler in Portfile

[Sean Farley]

David Strubbe writes:

 Hi Rainer,

 Sean did indeed add the default_variants to the compilers portgroup in the
 last month or two. Perhaps you were trying before then.

Thanks for following up, David :-)

@Rainer, yes, it should definitely handle default_variants. Please let
me know otherwise (preferably with a reproducible test case!). 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Python PortGroup environment variables

[Sean Farley]

Is there any reason that the configure.env variables are automatically
copied to the build and destroot phases?

I ask because most python packages do not use the traditional
'./configure; make; make install' method and instead set things like the
prefix and whatnot in the build or destroot phase.

Should we just add those variables (CC, CFLAGS, CXX, etc.) to build and
destroot phases?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [130954] trunk/dports/python/py-numpy/Portfile

[Sean Farley]

Joshua Root writes:

 Revision: 130954
   https://trac.macports.org/changeset/130954
 Author:   sean at macports.org
 Date: 2015-01-03 22:01:06 -0800 (Sat, 03 Jan 2015)
 Log Message:
 ---
 py-numpy: refactor port to use compilers portgroup
 
 This is a big refactor that cleans up a lot of old and now incorrect logic,
 mostly with ATLAS. This changeset is accomplishes:
 
 - ensure that numpy has a fortran compiler
 - ensure that compilers match the same ones as ATLAS
 - remove python 3.2
 
 Modified Paths:
 --
 trunk/dports/python/py-numpy/Portfile
 
 Modified: trunk/dports/python/py-numpy/Portfile
 ===
 --- trunk/dports/python/py-numpy/Portfile2015-01-04 06:01:04 UTC (rev 
 130953)
 +++ trunk/dports/python/py-numpy/Portfile2015-01-04 06:01:06 UTC (rev 
 130954)
 @@ -4,9 +4,11 @@
  PortSystem  1.0
  PortGroup   python 1.0
  PortGroup   github 1.0
 +PortGroup   compilers 1.0
  
  github.setupnumpy numpy 1.9.1 v
  namepy-numpy
 +revision1
  categories-append   math
  license BSD
  platforms   darwin
 @@ -17,8 +19,10 @@
  checksums   rmd160  c043ce0045166762e36c513458abc499d36bbcf5 \
  sha256  
 504b7cbc3b47df592d683e0f3b992cfa4d29338f8d23fca07f040164018b607f
  
 -python.versions 26 27 32 33 34
 +python.versions 26 27 33 34
  
 +compilers.setup require_fortran -clang -dragonegg -gcc44 -gcc45 
 -gcc46 -g95

 Is it really necessary to make all numpy users install gcc? Anyone who
 is just using numpy arrays for something like py-opengl is going to find
 it a large and useless extra dependency.

As far as I can tell, numpy requires a fortran compiler. Not installing
one is what leads to errors in #43321. Any port touching computation
(i.e. blas/lapack) almost certainly will have to install some kind of
fortran compiler.

I think this kind of dependency is unavoidable if we want to maintain
consistency and reproducibility. :-/
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [130159] trunk/dports/python

[Sean Farley]

Lawrence Velázquez writes:

 On Jan 2, 2015, at 3:22 AM, Sean Farley s...@macports.org wrote:

 I just saw that you pushed a few conflicts to my stack (py-netcdf4,
 py-mdb-toolkit, and py-nibabel). This actually helped me realize that my
 graveyard changes had an off-by-one error :-) The ones I have on my
 stack are:
 
 py-numpy
  py-pyfftw
  py-pyfits
py-pywcs
  py-pygrib
  py-pymc
  py-quantities
  py-scipy
py-scikit-learn
py-scikits-bootstrap
  py-svipc
 
 Have you already done some of these?

 Yes, these are now in the graveyard:
 - py32-pyfftw
 - py32-pyfits
 - py32-pygrib
 - py32-pymc
 - py32-pywcs

Ok, cool. I only have py-asciitable in my stack now. If you want to
finish the ones that aren't py-numpy or py-scipy, then fine by me :-)
Otherwise, I'll check on them tomorrow.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [130159] trunk/dports/python

[Sean Farley]

Lawrence Velázquez writes:

 On Dec 31, 2014, at 8:57 PM, Sean Farley s...@macports.org wrote:

 Yep, that looks like the same list I found. How did you search? I just
 used regex + codesearch.

 `grep` and `port info` :)

I just saw that you pushed a few conflicts to my stack (py-netcdf4,
py-mdb-toolkit, and py-nibabel). This actually helped me realize that my
graveyard changes had an off-by-one error :-) The ones I have on my
stack are:

py-numpy
  py-pyfftw
  py-pyfits
py-pywcs
  py-pygrib
  py-pymc
  py-quantities
  py-scipy
py-scikit-learn
py-scikits-bootstrap
  py-svipc

Have you already done some of these?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [130159] trunk/dports/python

[Sean Farley]

Lawrence Velázquez writes:

 On Jan 2, 2015, at 3:38 AM, Sean Farley s...@macports.org wrote:

 Ok, cool. I only have py-asciitable in my stack now. If you want to
 finish the ones that aren't py-numpy or py-scipy, then fine by me :-)
 Otherwise, I'll check on them tomorrow.

 Okay, I just did 
 py32-{asciitable,quantities,scikit-learn,scikits-bootstrap,svipc}. You should 
 be clear to do py32-{numpy,scipy}.

Wow, awesome, thanks!
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [130159] trunk/dports/python

[Sean Farley]

Michael Dickens writes:

 I ment to send this to macports-dev, not macports-changes. So, echoing
 what Josh just wrote:

 On Wed, Dec 31, 2014, at 11:08 AM, Michael Dickens wrote:

 py*-cython is still used by py*-scipy and py*-numpy (edit: among other
 ports). If we're ready to disable non-Python 2.7 and 3.4 scipy and
 numpy, then let's keep this change  I'll update those Portfiles (and
 add the non-ones to the graveyard). Otherwise, this change needs to be
 reverted. - MLD

I'm actually working on big refactorings of scipy and numpy to fix their
compilers, so if you could hold off, that'd be great. Also, I can make
these changes if need be.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [130159] trunk/dports/python

[Sean Farley]

Lawrence Velázquez writes:

 On Dec 31, 2014, at 3:11 PM, Lawrence Velázquez lar...@macports.org wrote:

 I'll fix the Cython situation.

 Dependents of py{24,25,31,32}-cython retired:
 http://trac.macports.org/log?rev=130551stop_rev=130546

 py{26,33}-cython resurrected:
 http://trac.macports.org/changeset/130553/

 The last stumbling block is py32-numpy.

I've removed that locally. Will push soon.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [130159] trunk/dports/python

[Sean Farley]

Sean Farley writes:

 Lawrence Velázquez writes:

 On Dec 31, 2014, at 3:11 PM, Lawrence Velázquez lar...@macports.org wrote:

 I'll fix the Cython situation.

 Dependents of py{24,25,31,32}-cython retired:
 http://trac.macports.org/log?rev=130551stop_rev=130546

 py{26,33}-cython resurrected:
 http://trac.macports.org/changeset/130553/

 The last stumbling block is py32-numpy.

 I've removed that locally. Will push soon.

There are about 15 ports that dynamically depend on py32-numpy. I'll
also go ahead and move those to the graveyard tonight. Since tomorrow's
a holiday for me, I should have the time to push it all out then.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [130159] trunk/dports/python

[Sean Farley]

Lawrence Velázquez writes:

 On Dec 31, 2014, at 6:53 PM, Lawrence Velázquez lar...@macports.org wrote:

 On Dec 31, 2014, at 6:36 PM, Sean Farley s...@macports.org wrote:
 
 I'll also go ahead and move those to the graveyard tonight. Since 
 tomorrow's a holiday for me, I should have the time to push it all out then.
 
 Sounds good. Be sure to deal with any recursive dependencies beforehand.

 The only one I found was py32-lmfit (depends on py32-scipy).

Yep, that looks like the same list I found. How did you search? I just
used regex + codesearch.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [129987] trunk/dports/devel/boost

[Sean Farley]

Ryan Schmidt writes:

 On Dec 23, 2014, at 6:42 PM, s...@macports.org wrote:
 
 Revision
 129987
 Author
 s...@macports.org
 Date
 2014-12-23 16:42:44 -0800 (Tue, 23 Dec 2014)
 Log Message
 
 boost: update to 1.57; closes #46156

 Modified: trunk/dports/devel/boost/Portfile (129986 = 129987)
 -# Although bjam can supposedly use parallel builds, it has random failures. 
 See #28878 and #23531.
 -# To re-enable it, comment out the below and add '-j${build.jobs}' to 
 'build.args', also below.
 -#
 -use_parallel_build  no
 +# Ever since the tickets #28878 and #23531 disabled parallel builds, boost 
 has
 +# had many releases. We enable parallel builds back but can disable again if
 +# problems arise.
 +# use_parallel_build no

 You didn't add -j${build.jobs} to build.args, so it's still not doing a 
 parallel build.

Oops, I missed that. Thanks.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Adding MPI back to Boost

[Sean Farley]

Anyone opposed to me pushes the proposed changes and marking them fixed?

Sean Farley writes:

 Ryan Schmidt writes:

 On Dec 14, 2014, at 12:21 PM, Sean Farley wrote:
 
 Ryan Schmidt writes:
 
 So, this would add clang33, clang34, clang35 variants, for example? But 
 these would be different from the clang 3.x provided by Xcode in some way? 
 The MacPorts clang ports would be able to use MPI somehow, while Xcode 
 clang would not?
 
 ... ?

 That's a bit how I feel about this mpi business, yes.

 :-/

 First of all, for the sake of completeness, the list of variants would
 be:
 
 $ port info boost
 boost @1.56.0_2 (devel)
 Variants: clang31, clang32, clang33, clang34, clang35, debug, 
 mpich, mpich_devel, [+]no_single, [+]no_static, openmpi, openmpi_devel, 
 python25, python26, [+]python27, python31, python32, python33, python34, 
 regex_match_extra, universal
 
 The reason I wrote the mpi and compilers portgroup was because there was
 no way to make sure the same compiler for both is selected. For example,
 
 $ port install boost +clang35 +mpich
 
 will install mpich (built with clang35 compilers) and boost (built with
 clang35 compilers).

 Only if mpich had not already been installed with a different variant, since 
 MacPorts does not have the capability to declare dependencies on variants 
 (ticket #126).

 Not in this case. The mpi portgroup forces the same active compilers.

 Is the correspondence of variants between e.g. boost and mpich required? In 
 other words, if mpich is installed with +clang35, does that mean boost 
 *must* use the +clang35 variant as well if one wants to use the +mpich 
 variant, or would it work if +clang34 or clang from Xcode is used for boost?

 Yes, the same must be used across the board.

 The clang provided by Xcode can be used, of course, which is the
 default:
 
 $ port install boost +mpich
 
 will install mpich (built with Xcode compilers) and boost (built with
 Xcode compilers). This will change depending on the OS version.

 Under what circumstances would using Xcode clang not be sufficient? In other 
 words, why would we ever want MacPorts clang variants?

 As Eric pointed out, it's for experimenting. This is exactly the same as
 the reason ATLAS uses different compilers: sometimes there is a speed
 improvement.

 Perhaps you're missing that MPI is a library that provide compiler
 *wrappers*? If a package needs MPI then that package is compiled with:
 
 CC=mpicc
 CXX=mpicxx
 FC=mpifort
 etc.

 Sure, I'm missing that, and probably a lot of other things. For example: 
 what is the goal? What does adding mpi support to boost do? Why would 
 someone want this?

 So that a package could use Boost.MPI (such as dolfin does).

 MPI falls under the category of scientific computing. This changes a few
 presumptions: the goal here is numerical computation (matrix vector
 operations).

 Having one implementation just isn't feasible. Science users want to
 experiment with each combination. You could say it's part of their
 nature.

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

Adding MPI back to Boost

[Sean Farley]

So, I've added support into the compilers portgroup for working with
the compiler.blacklist variable but that doesn't fix the issue that Ryan
tried to fix with r125939:

https://trac.macports.org/changeset/125939

It seems instead that the fix is just to remove the gcc variants:

mpi.setup -gcc

Is there anything wrong with this proposed fix? If no one objects, I'll
push my changesets which 1) add blacklist support to the compilers
portgroup and 2) add mpi portgroup to boost (but remove gcc variants).
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Adding MPI back to Boost

[Sean Farley]

Mark Moll writes:

 On Dec 14, 2014, at 2:28 AM, Sean Farley s...@macports.org wrote:
 
 So, I've added support into the compilers portgroup for working with
 the compiler.blacklist variable but that doesn't fix the issue that Ryan
 tried to fix with r125939:
 
 https://trac.macports.org/changeset/125939
 
 It seems instead that the fix is just to remove the gcc variants:
 
 mpi.setup -gcc
 
 Is there anything wrong with this proposed fix? If no one objects, I'll
 push my changesets which 1) add blacklist support to the compilers
 portgroup and 2) add mpi portgroup to boost (but remove gcc variants).

 This seems like a good idea. Unless (a) you can use gcc for all of boost’s 
 dependents and (b) there are actual use cases where this would be useful, I’d 
 say that removing gcc variants is a good idea. Mixing libc++ and libstdc++ in 
 boost dependents is bound to lead to problems.

(a) That would require depending on a variant which I don't want to put
the work into. I wrote a script to do this manually for myself but
it is still a headache.

(b) Depends on how useful you think testing different compiler speed /
output is: I would have used it to test dolfin (FEniCS) builds with
gcc vs clang.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Adding MPI back to Boost

[Sean Farley]

Ryan Schmidt writes:

 On Dec 14, 2014, at 2:28 AM, Sean Farley wrote:

 So, I've added support into the compilers portgroup for working with
 the compiler.blacklist variable but that doesn't fix the issue that Ryan
 tried to fix with r125939:
 
 https://trac.macports.org/changeset/125939
 
 It seems instead that the fix is just to remove the gcc variants:
 
 mpi.setup -gcc
 
 Is there anything wrong with this proposed fix? If no one objects, I'll
 push my changesets which 1) add blacklist support to the compilers
 portgroup and 2) add mpi portgroup to boost (but remove gcc variants).

 Right, using gcc variants causes the use of libstdc++ which causes the 
 problem on Mavericks and later.

 So, without gcc variants, what variants remain?

clang 3.x and all versions of dragonegg. Multiple that set with all the
mpi choices, too.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Adding MPI back to Boost

[Sean Farley]

Ryan Schmidt writes:

 On Dec 14, 2014, at 11:41 AM, Sean Farley wrote:

 Ryan Schmidt writes:
 
 On Dec 14, 2014, at 2:28 AM, Sean Farley wrote:
 
 So, I've added support into the compilers portgroup for working with
 the compiler.blacklist variable but that doesn't fix the issue that Ryan
 tried to fix with r125939:
 
 https://trac.macports.org/changeset/125939
 
 It seems instead that the fix is just to remove the gcc variants:
 
 mpi.setup -gcc
 
 Is there anything wrong with this proposed fix? If no one objects, I'll
 push my changesets which 1) add blacklist support to the compilers
 portgroup and 2) add mpi portgroup to boost (but remove gcc variants).
 
 Right, using gcc variants causes the use of libstdc++ which causes the 
 problem on Mavericks and later.
 
 So, without gcc variants, what variants remain?
 
 clang 3.x and all versions of dragonegg. Multiple that set with all the
 mpi choices, too.

 So, this would add clang33, clang34, clang35 variants, for example? But these 
 would be different from the clang 3.x provided by Xcode in some way? The 
 MacPorts clang ports would be able to use MPI somehow, while Xcode clang 
 would not?

... ?

First of all, for the sake of completeness, the list of variants would
be:

$ port info boost
boost @1.56.0_2 (devel)
Variants: clang31, clang32, clang33, clang34, clang35, debug, 
mpich, mpich_devel, [+]no_single, [+]no_static, openmpi, openmpi_devel, 
python25, python26, [+]python27, python31, python32, python33, python34, 
regex_match_extra, universal

The reason I wrote the mpi and compilers portgroup was because there was
no way to make sure the same compiler for both is selected. For example,

$ port install boost +clang35 +mpich

will install mpich (built with clang35 compilers) and boost (built with
clang35 compilers).

The clang provided by Xcode can be used, of course, which is the
default:

$ port install boost +mpich

will install mpich (built with Xcode compilers) and boost (built with
Xcode compilers). This will change depending on the OS version.

Perhaps you're missing that MPI is a library that provide compiler
*wrappers*? If a package needs MPI then that package is compiled with:

CC=mpicc
CXX=mpicxx
FC=mpifort
etc.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Adding MPI back to Boost

[Sean Farley]

Ryan Schmidt writes:

 On Dec 14, 2014, at 12:21 PM, Sean Farley wrote:
 
 Ryan Schmidt writes:
 
 So, this would add clang33, clang34, clang35 variants, for example? But 
 these would be different from the clang 3.x provided by Xcode in some way? 
 The MacPorts clang ports would be able to use MPI somehow, while Xcode 
 clang would not?
 
 ... ?

 That's a bit how I feel about this mpi business, yes.

:-/

 First of all, for the sake of completeness, the list of variants would
 be:
 
 $ port info boost
 boost @1.56.0_2 (devel)
 Variants: clang31, clang32, clang33, clang34, clang35, debug, 
 mpich, mpich_devel, [+]no_single, [+]no_static, openmpi, openmpi_devel, 
 python25, python26, [+]python27, python31, python32, python33, python34, 
 regex_match_extra, universal
 
 The reason I wrote the mpi and compilers portgroup was because there was
 no way to make sure the same compiler for both is selected. For example,
 
 $ port install boost +clang35 +mpich
 
 will install mpich (built with clang35 compilers) and boost (built with
 clang35 compilers).

 Only if mpich had not already been installed with a different variant, since 
 MacPorts does not have the capability to declare dependencies on variants 
 (ticket #126).

Not in this case. The mpi portgroup forces the same active compilers.

 Is the correspondence of variants between e.g. boost and mpich required? In 
 other words, if mpich is installed with +clang35, does that mean boost *must* 
 use the +clang35 variant as well if one wants to use the +mpich variant, or 
 would it work if +clang34 or clang from Xcode is used for boost?

Yes, the same must be used across the board.

 The clang provided by Xcode can be used, of course, which is the
 default:
 
 $ port install boost +mpich
 
 will install mpich (built with Xcode compilers) and boost (built with
 Xcode compilers). This will change depending on the OS version.

 Under what circumstances would using Xcode clang not be sufficient? In other 
 words, why would we ever want MacPorts clang variants?

As Eric pointed out, it's for experimenting. This is exactly the same as
the reason ATLAS uses different compilers: sometimes there is a speed
improvement.

 Perhaps you're missing that MPI is a library that provide compiler
 *wrappers*? If a package needs MPI then that package is compiled with:
 
 CC=mpicc
 CXX=mpicxx
 FC=mpifort
 etc.

 Sure, I'm missing that, and probably a lot of other things. For example: what 
 is the goal? What does adding mpi support to boost do? Why would someone want 
 this?

So that a package could use Boost.MPI (such as dolfin does).

MPI falls under the category of scientific computing. This changes a few
presumptions: the goal here is numerical computation (matrix vector
operations).

Having one implementation just isn't feasible. Science users want to
experiment with each combination. You could say it's part of their
nature.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

GitHub Portgroup

[Sean Farley]

I have a port (julia) that extracts as julia-0.3 which breaks the
globbing done by the Portgroup: ${github.author}-${github.project}-*.

Would it make sense to change this to *${github.project}? Or am I
missing something?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [128125] trunk/dports/lang/julia/Portfile

[Sean Farley]

Ryan Schmidt writes:

 On Nov 13, 2014, at 6:16 PM, s...@macports.org wrote:
 
 Revision
 128125
 Author
 s...@macports.org
 Date
 2014-11-13 16:16:29 -0800 (Thu, 13 Nov 2014)
 Log Message
 
 julia: use a release tarball to avoid git submodules
 Modified Paths
 
  • trunk/dports/lang/julia/Portfile
 Diff
 
 Modified: trunk/dports/lang/julia/Portfile (128124 = 128125)

 -github.setupJuliaLang julia 0.3.2 v
 
 +namejulia
 +version 0.3.2
 +revision1

 -# julia's build system uses git submodules
 -fetch.type  git
 +homepagehttp://julialang.org
 +master_sites
 https://github.com/JuliaLang/julia/releases/download/v${version}
  

 Since the project is still hosted at github, you should continue to use the 
 github portgroup. Set github.tarball_from releases.

Ah, right, I keep forgetting about that. Thanks!
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Please start commit message with port name.

[Sean Farley]

Vincent Habchi writes:

 Ciao Petr,

 I'd like to propose to start commit messages with the port name. This helps 
 very much to read them for example in the Timeline.
 
 For example:
 
 https://trac.macports.org/changeset/127794 -- Correct various bugs. Bump to 
 revision 1.
 https://trac.macports.org/changeset/127795 -- Bump to version 2.1.4
 
 could become:
 
 - gdal: Correct various bugs. Bump to revision 1.
 and
 - postgis2: Bump to version 2.1.4
 respectively.

 Fine. Ottima idea. 
 Thanks for the suggestion!

Small nit: I think it's easier to read one-liners when they are all
lowercase:

gdal: correct various bugs and bump revision
postgis2: bump to version 2.1.4

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

Re: need a help with PortGroup compilers

[Sean Farley]

Takeshi Enomoto writes:

 I am developing a port that relies on makefiles.
 I need to set fortran and c++ compilers so I use PortGroup mpi 1.0.
 ${configure.cxx} has a default value,
 but ${configure.f90} is empty.

This is a good question. And I wish I could solve this problem easier.

 As far as I read compilers-1.0.tcl ${configure.f90} should be set.

You are correct and I am also stumped.

 In wgrib2 I manually set ${configure.f90}.

 What is wrong?

 A part of a pseudo Portfile:

 PortGroup   mpi 1.0
 use_configure   no
 compilers.choosef90 cxx
 compilers.setup require_fortran
 build.env   F90=${configure.f90} \
 CXX=${configure.cxx}

The compilers should very much be set at this point but I don't know why
they are not. If anyone can shed some light on this, that'd be so
helpful.

A stopgap solution for now is to set build.env in a 'pre-build {}'
block.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Getting the entire configure.cflags variable

[Sean Farley]

Ryan Schmidt writes:

 On Oct 2, 2014, at 4:24 PM, Sean Farley wrote:
 
 The petsc port, in an attempt to help users, ignores CFLAGS (and
 friends) from the environment due to many users that accidentally had
 them defined. So, I'm trying to pass the exact same CFLAGS to
 configure.args.

 I see their configure script is some python monstrosity and that one of the 
 files it includes contains:


   def resetEnvCompilers(self):
 ignoreEnv = ['CC','CFLAGS','CXX','CXXFLAGS','FC','FCFLAGS','F77','FFLAGS',
  'F90','F90FLAGS','CPP','CPPFLAGS','CXXCPP','CXXCPPFLAGS',
  'LDFLAGS','LIBS','MPI_DIR','RM','MAKEFLAGS','AR']
 for envVal in ignoreEnv:
   if envVal in os.environ:
 self.logPrintBox('* WARNING: '+envVal+' (set to 
 '+os.environ[envVal]+') found in environment variables - ignoring \n use 
 ./configure '+envVal+'=$'+envVal+' if you really want to use that value 
 **')
 del os.environ[envVal]
 return


 Perhaps that can be simply ripped out to allow env vars to work.

I work on the PETSc project, and yes, it is a python monstrosity. I
could easily patch this but that isn't the point. For starters, patching
a port for this would mean extra burden for the author.

It would seem better to fix the MacPorts internals but I was never that
good at Jenga.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: RFC: Drop PPC support

[Sean Farley]

Takeshi Enomoto writes:

 Historically we officially support the current and previous Mac OS X release 
 (while not doing anything to on-purpose break older releases / being willing 
 to accept patches to make things work on older releases).

 If we are not going to change this policy,
 PPC is no longer supported.
 It is up to the maintainers or the port.
 We don't have to remove what are still available for PPC.

 Personally I still use a big-endian Power Mac and try to maintain some ports
 as far as I can.

I think that's fine but as a policy (meaning: written as a FAQ or a
documentation of some kind) the first answer for PPC tickets should be:
you're on your own.

If a macports dev wants to help out personally, then sure, go for it.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Getting the entire configure.cflags variable

[Sean Farley]

This seems very odd but is there a variable that stores the complete
string of what will eventually be CFLAGS in the environment
(e.g. CFLAGS=foo ./configure --args) passed to a command?

If you're like me, you're thinking: Of course there is, use
configure.cflags! But that only holds a substring:

pre-configure {
  puts configure.cflags: ${configure.cflags}
}

will output: configure.cflags: -Os

but the actual environment variable is set to -pipe -Os -arch
x86_64. The arch argument is supplied by the configure.cc_archflags
variable.

So, is there a way to get the entire environment variable CFLAGS (and
friends) within a portfile?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Getting the entire configure.cflags variable

[Sean Farley]

Ryan Schmidt writes:

 On Oct 2, 2014, at 3:25 PM, Sean Farley wrote:

 This seems very odd but is there a variable that stores the complete
 string of what will eventually be CFLAGS in the environment
 (e.g. CFLAGS=foo ./configure --args) passed to a command?
 
 If you're like me, you're thinking: Of course there is, use
 configure.cflags! But that only holds a substring:
 
 pre-configure {
  puts configure.cflags: ${configure.cflags}
 }
 
 will output: configure.cflags: -Os
 
 but the actual environment variable is set to -pipe -Os -arch
 x86_64. The arch argument is supplied by the configure.cc_archflags
 variable.
 
 So, is there a way to get the entire environment variable CFLAGS (and
 friends) within a portfile?

 Unfortunately as far as I can tell the answer is no. Many variables are added 
 to ${configure.cflags} right before the command is run and after the port has 
 any opportunity to intercept it or learn about it.

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

Re: Getting the entire configure.cflags variable

[Sean Farley]

Ryan Schmidt writes:

 On Oct 2, 2014, at 4:10 PM, Lawrence Velázquez wrote:

 On Oct 2, 2014, at 5:08 PM, Sean Farley wrote:
 
 Ryan Schmidt writes:
 
 Unfortunately as far as I can tell the answer is no. Many variables are 
 added to ${configure.cflags} right before the command is run and after the 
 port has any opportunity to intercept it or learn about it.
 
 This seems ... unfortunate.

 I think so too. What's your use case for needing it at this moment?

The petsc port, in an attempt to help users, ignores CFLAGS (and
friends) from the environment due to many users that accidentally had
them defined. So, I'm trying to pass the exact same CFLAGS to
configure.args.

 I suspect the idea is to prevent ports from clearing CFLAGS and such.

 I think it's more that in many cases -- arch flags for example, or which C++ 
 stdlib flag to use -- MacPorts won't know what to put in the cflags until 
 after the rest of the port has been processed. What if you append something 
 to configure.cflags, then later turn on (or turn off) the universal variant? 
 Then the wrong arch flags will be in configure.cflags. This is why (as I 
 understand it) MacPorts doesn't put them in until the port has been 
 completely evaluated.

Should we go all the way to evaluate which CFLAGS are defined? That
seems fragile and error-prone.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: mpi

[Sean Farley]

vincent writes:

 Yes, atlas has a bunch of compiler variants. I would love for most or all of 
 them to go away. But part of atlas needs fortran so it needs to deal with 
 that at least. And I believe Vince argued that for atlas and other 
 performance-critical scientific software it is beneficial to be able to try 
 different compilers to get the absolute best performance. I'm not sure who 
 actually has time to do that however. Also, atlas already builds itself 
 multiple times with different compiler options to get best performance, 
 which is why building atlas takes so long.

 This is mainly historical now. Clang has gone a long way from what it was two 
 years ago and can now outperform GCC on most kernels. But modern clang 
 versions are not available on all platforms (10.5 PPC). Besides, fortran is 
 still required for Atlas as long as you decide to build the  BLAS/LAPACK 
 interface, which almost all other ports depend on. The idea of keeping 
 multiple gcc variants was to avoid  the installation of a fresh copy of GCC 
 in case the version the user had installed and the one Atlas required weren't 
 the same, knowing that the version number is nowhere near to be important as 
 long as the fortran compiler is available (it's just to build the API).

The development burden of all these gcc versions is pretty high now. I
would suggest a (perhaps controversial) simpler approach:

- Always build BLAS/LAPACK for ATLAS (testing for its existence in a
  dependent port is burdensome)

- Always use clang for C/C++

- Drop PPC support

 I just wish llvm had a fortran front-end to avoid this mess. And, needless to 
 say, I'll welcome any suggestion to improve the layout of the port.

Ain't that the truth.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

RFC: Renaming GCC ports and variants

[Sean Farley]

Proposal:

Since it seems that we are flat-out disallowing gcc being used as a
C/C++ compiler, I think it's time to do some clean up of the code:

1) Rename gccXY to gcc-X.Y

2) Rename +gccXY variants to +gfortranXY

3) Start moving away from configure.compiler=macports-gcc*

I think it's important for (2) to happen because it make the variant
clear as to what it is adding (namely, just a fortran compiler).

There are about ~100 ports with gcc variants / configure.compiler being
set so, while not being trivial, it's not *that* bad.

Due to development burden, I think this kind of decision needs to be
across the board (e.g. not be conditional on the OS used). For this
proposal, it will hopefully clear up some C++ linking bugs.

As a first wave, these would be some ports to tackle:

atlas
dotwrp
julia
mpich-*
octave
openmpi-*
petsc
py-scipy
qrupdate
slepc

And, of course, update the compilers and mpi portgroups to use the
configure.compiler specified. If we can agree on a plan, I can volunteer
to do this work and submit my work to be reviewed before committing.

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

RFC: Drop PPC support

[Sean Farley]

As discussed in the MPI thread, PPC is very old and is causing quite the
development burden. I would be in favor of discussing how much effort we
really want to spend supporting them (similar to supporting libstdc++ on
Mavericks).

We could tag some known version of the MacPorts svn tree for PPC users
and be done with it. This would allow us to concentrate on other issues.

We could also talk about how far of an OS back do we really want to
support. Tiger and Leopard are decrepit. We don't even have buildbots
for PPC nor OSes below Lion.

Should we finally drop some of this older stuff?

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

Re: mpi

[Sean Farley]

Daniel J. Luke writes:

 On Oct 1, 2014, at 1:36 PM, Brandon Allbery allber...@gmail.com wrote:
 
 On Wed, Oct 1, 2014 at 1:30 PM, Sean Farley s...@macports.org wrote:
 - Always use clang for C/C++
 - Drop PPC support
 
 There are a lot of people relying on MacPorts to keep PPCs running.

 they probably shouldn't be.

 I don't think any apple-provided OS that PPC machines can run gets security 
 patches from Apple anymore...

I agree. The development burden of PPC is much, much too high nowadays.
Also, having conditional code for which compiler to use based on the OS
(and sprinkled all throughout the code) is a maintenance headache.

I'll post a new thread about PPC to not derail this one.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: RFC: Renaming GCC ports and variants

[Sean Farley]

Ryan Schmidt writes:

 On Oct 1, 2014, at 12:48 PM, Sean Farley wrote:

 Proposal:
 
 Since it seems that we are flat-out disallowing gcc being used as a
 C/C++ compiler, I think it's time to do some clean up of the code:
 
 1) Rename gccXY to gcc-X.Y

 As I proposed earlier, we might want to avoid using a dash in a port name, 
 because it is nice to have the port name and variant name be the same, 
 therefore I proposed gccX.Y instead of gcc-X.Y. However, renaming existing 
 ports is a pain, and going forward new versions of gcc starting with gcc5 
 will just have a single major version number so no change would be necessary 
 there.

We really should be consistent then. I personally don't care what the
new name is but we should either have clangX.Y / gccX.Y or clangXY /
gccXY.

 2) Rename +gccXY variants to +gfortranXY

 Note that some ports use gcc variants not for fortran support but for java 
 support. I'm thinking here of my much-neglected pdftk port, though for that I 
 may just remove the variants and use a single known-good java compiler.

I think the name of the compiler would be more appropriate. In this
case, +gcjXY.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: RFC: Drop PPC support

[Sean Farley]

Bradley Giesbrecht writes:

 On Oct 1, 2014, at 10:58 AM, Sean Farley s...@macports.org wrote:

 As discussed in the MPI thread, PPC is very old and is causing quite the
 development burden. I would be in favor of discussing how much effort we
 really want to spend supporting them (similar to supporting libstdc++ on
 Mavericks).
 
 We could tag some known version of the MacPorts svn tree for PPC users
 and be done with it. This would allow us to concentrate on other issues.
 
 We could also talk about how far of an OS back do we really want to
 support. Tiger and Leopard are decrepit. We don't even have buildbots
 for PPC nor OSes below Lion.

 There are buildbots for Snow Leopard.
 https://build.macports.org/buildslaves

Whoops, I missed that.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: RFC: Renaming GCC ports and variants

[Sean Farley]

Frank Schima writes:

 On Oct 1, 2014, at 12:26 PM, Sean Farley s...@macports.org wrote:

 Ryan Schmidt writes:
 
 On Oct 1, 2014, at 12:48 PM, Sean Farley wrote:
 
 Proposal:
 
 Since it seems that we are flat-out disallowing gcc being used as a
 C/C++ compiler, I think it's time to do some clean up of the code:
 
 1) Rename gccXY to gcc-X.Y
 
 As I proposed earlier, we might want to avoid using a dash in a port name, 
 because it is nice to have the port name and variant name be the same, 
 therefore I proposed gccX.Y instead of gcc-X.Y. However, renaming existing 
 ports is a pain, and going forward new versions of gcc starting with gcc5 
 will just have a single major version number so no change would be 
 necessary there.
 
 We really should be consistent then. I personally don't care what the
 new name is but we should either have clangX.Y / gccX.Y or clangXY /
 gccXY.

 I say we use gccX.Y. Just renaming gcc ports (for now) won’t be too hard. 

Sure, that's fine, we just all need to decide on something.

 2) Rename +gccXY variants to +gfortranXY

 Sounds good to me, though we should use +gfortranX.Y if we switch the gcc 
 ports to gccX.Y. 

Yep, agreed.

 3) Start moving away from configure.compiler=macports-gcc*

 This seems like a good idea. In fact, that made me realize what I was doing 
 wrong in #44631. 

:-)

 We should move all ports with gccXY variants to the compilers portgroup. 

This is one of my goals. Having this logic in one place would cut down
on a lot of code duplication and unexpected behavior.

 Sean, I hereby give you permission to fix all of my ports (ifeffit, py-qutip, 
 py-usadel1 at least). Once all or most ports use it, then maybe we can switch 
 to gcc49 (really gfortran4.9) as Ryan proposed earlier. 

That would be a great benefit of everything using one port group for
this: easily changing the default gfortran for all ports.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Recommendations for version numbers in port names

[Sean Farley]

Lawrence Velázquez writes:

 Resurrecting this thread. Let's keep general renaming discussion here.

Sure, sounds good.

 On Sep 16, 2014, at 5:22 PM, Ryan Schmidt ryandes...@macports.org wrote:

 It's been proposed on this list that we should rename MySQL ports e.g. 
 mysql51 - mysql-5.1; this would be to match the existing new ports 
 mariadb-10.0 and mariadb-10.1. Consistency is good, especially within a 
 particular type of software (e.g. MySQL in this case) but renaming MySQL 
 ports is more problematic than renaming most ports, because MySQL ports are 
 database servers and users may have databases and config files in their 
 default version-specific directories which the user would manually have to 
 move.

 Consistency is good, but I'd argue not especially critical. If migrating a 
 particular port or set of ports would be too much work, it would not be the 
 end of the world if we left it/them.

 Consistency of variant names is probably more important than consistency of 
 port names, since it affects variant inheritance.

This is an important point, thanks.

 The problem with dashes in port names is that a dash is not a legal 
 character in a variant name because it is confused with the syntax for 
 disabling a variant, and often when there are multiple versions of a port, 
 other ports will want to reference those multiple versions in corresponding 
 variants.

 True, but we already have tons of ports with hyphens in their names. It seems 
 odd to me to use hyphens in some places (e.g., `py34-requests`) but avoid 
 them in others (`gcc49`).

Very much agreed.

 The problem with dots in port names is that so far port lint has declared 
 the dot an illegal character in a variant name. This has led the perl5 port 
 for example to adopt variant names like perl5_16 which I've always found a 
 little confusing. It has been nice that under the original naming scheme, 
 one could assume that in many cases the variant name matches the name of the 
 dependency that will be added. If you want to use the python27 port, you use 
 a port's +python27 variant, etc.

 Matching variants and dependencies is certainly nice, but I don't think we 
 should get hung up on it, since the dependencies are added automatically. I 
 personally would be entirely fine with `+gcc4.9` pulling in `gcc-4.9`, and I 
 think the hyphenated port names look cleaner. This is entirely subjective, of 
 course.

 The only disadvantage I see to the old naming scheme is ambiguity when a 
 version number component reaches two digits, e.g. is the scala210 port 
 version 2.1.0 or 2.10? (It's 2.10.) Is the ruby186 port version 1.8.6 or 
 1.86? (It's 1.8.6 -- perhaps this port should have been named ruby18 
 instead.) Leaving the dot in would remove the ambiguity, as demonstrated by 
 the Perl ports, and port lint may be overly cautious in its prohibition of 
 the dot in variant names. Someone should do some tests. Make variants with 
 dots, like mysql5.1, and see if they work correctly. Can you install the 
 port? Can you upgrade the port? Can you uninstall the port? What if other 
 variants are also selected? If everything works fine we can relax this lint 
 restriction.

 I haven't done any tests, but I'd much prefer adding the periods, if possible.

I agree with this, too.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: mpi

[Sean Farley]

Ryan Schmidt writes:

 We've had multiple bug reports from users who had installed boost with one of 
 the gcc variants. Either the build failed when using those variants, or the 
 build of boost succeeded but then the build of another port that depends on 
 boost failed. We attributed this to the mixing of C++ runtimes on 10.9+. I 
 removed the compiler variants from the boost port, but this has the effect of 
 making it impossible to install boost with mpi support, which apparently some 
 ports like dolphin require.

 I have to say I have no understanding of what mpi is or what the mpi 
 portgroup is doing. Sean, could you explain?


Introduction


MPI is a way to do parallel programming and stands for 'message passing
interface.' There are two major implementations: OpenMPI and
MPICH. Simply put, they are just libraries. A (IMHO, bad) decision was
made long ago to provide a compiler wrapper that would link the MPI
libraries so that a user could type:

mpicc test.c

--
First step
--

This made the first step of trying to build MPI ports in MacPorts
apparent: provide a way to supply the MPI compiler wrapper to a port.

That means providing a way to obtain values from the matrix of compilers
and MPI libraries: (fixed width font below)

 clang  clang  ...   gcc   gcc   ...   gcc   ...  dragonegg  ...
  3.13.2 4.4   4.5 4.9   3.1
+--+-+-+-+-+-+-+-+-+-+
MPICH   |  | | | | | | | | | |
+--+-+-+-+-+-+-+-+-+-+
OpenMPI |  | | | | | | | | | |
+--+-+-+-+-+-+-+-+-+-+

---
Fortran
---

While the above matrix was relatively straight-forward to implement
there was one glaring problem: fortran. LLVM / clang does not provide
it. Wonderful.

This creates the scenario of: does the port want the full suite of, for
example, gcc (meaning both C and fortran) or just the fortran
compiler. This led to the creation of the 'require_fortran' monstrosity.

-
Complications
-

There are two complications with this implementation. The first is that
there is no knowledge of configure.compiler (used for blacklisting).

The second, more difficult, complication is that this implementation
uses variants meaning only one version can be active at a time. This is
the very core of issue 126: https://trac.macports.org/ticket/126

Some package managers treat variants as subports. This would mean
installing each version / variant of a port into its own unique
path. For example,

foo-1.0: /opt/local/foo-1.0
foo-1.0+variantA: /opt/local/foo-1.0+variantA
foo-1.1+variantB: /opt/local/foo-1.1+variantB

For the convenience of building software outside the MacPorts tree, you
could set the active version of a port by symlinking its files into
/opt/local.

Changing MacPorts to this model would be no easy task.

Hopefully, now we can see the reason for the original problem: variant
dependence. If a user wants dolfin with gcc49:

$ port install dolfin +mpich +gcc49

Then this installs boost with +mpich +gcc49, forcing everything linking
to this version of boost to be compiled (and linked) with gcc's C++
compiler.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [123602] trunk/dports/python/py-astropy/Portfile

[Sean Farley]

Daniel J. Luke writes:

 On Aug 12, 2014, at 11:11 AM, Ryan Schmidt ryandes...@macports.org wrote:
 
 It's still not totally automatic: the developer still has to update the 
 checksums, so if the developer is sufficiently aware that the checksums need 
 to be updated, why can't the developer also follow the stealth update 
 recipe? This hasn't been a problem before.

 I don't necessarily disagree, but I also don't think it's a bad idea to at 
 least think about possible ways to reduce friction for people contributing to 
 MacPorts.

Sorry for the delay; I just moved across the country and started a new
job (Hello, Bay Area people!).

Daniel did a great job of reading my mind in this thread :-) I am trying
to brainstorm about possible ways to help people contribute.

As for this exact issue, it could be something as simple as a fallback
test:

if checksum doesn't match and revision is new:
  try downloading again
  write state so we don't download in an infinite loop
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: mpi

[Sean Farley]

Ryan Schmidt writes:

 This creates the scenario of: does the port want the full suite of, for
 example, gcc (meaning both C and fortran) or just the fortran
 compiler.

 And which of these two strategies does the mpi portgroup employ?

Both, that's why there is a 'require_fortran' variable.

 This led to the creation of the 'require_fortran' monstrosity.

 With the release of OS X 10.9 and its use of libc++ we seem to have found the 
 use of gcc ports as values for configure.compiler untenable, giving rise to 
 the fortran recipe which just sets the fortran compiler and leaves the 
 C/C++/ObjC/ObjC++ compilers alone:

 https://trac.macports.org/wiki/PortfileRecipes#fortran

 I'm not sure if or how this relates to the require_fortran that you mentioned 
 above.

The portfile recipe would be the equivalent of something like +clang
+gfortran which would give you the clang compilers for C and gfortran
4.8 for fortran code. There is also the choice of +g95 in the compilers
portgroup but that doesn't work as well in my experience.

 -
 Complications
 -
 
 There are two complications with this implementation. The first is that
 there is no knowledge of configure.compiler (used for blacklisting).

 I don't understand the situation in depth, but if mpi is requested, shouldn't 
 we just inspect the value of configure.cc / configure.cxx / configure.obcj / 
 configure.objcxx / configure.fc etc. (in a pre-configure block, to give a 
 port time to change compiler.blacklist / compiler.whitelist / 
 compiler.fallback), and replace them with their corresponding mpi wrappers? 
 If a port needs a Fortran compiler then it would also need to provide gcc 
 variants which would select only the fortran compiler, a la the fortran 
 recipe.

This is pretty much was is done (modulo the blacklist). If I understand
correctly, though, you want to remove gcc from being able to be used as
a compiler? This would be a serious limitation.

Instead, I'd like to make it easier to say: take the port 'mpich' and
make all of its dependents use the same compilers. That's what the mpi
portgroup tries to mitigate.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [123602] trunk/dports/python/py-astropy/Portfile

[Sean Farley]

Ryan Schmidt writes:

 On Sep 30, 2014, at 4:55 PM, Sean Farley wrote:

 As for this exact issue, it could be something as simple as a fallback
 test:
 
 if checksum doesn't match and revision is new:
  try downloading again
  write state so we don't download in an infinite loop

 That's a conceivable change. But let's look at what problems that particular 
 change would involve:

 * MacPorts would need to gain the capability to go back to a previous phase 
 (fetch) after it has already been completed. Or perhaps simpler, MacPorts 
 would need the ability to automatically clean a port and try it from the 
 beginning based on some criteria. This would be quite useful for a number of 
 issues MacPorts users currently experience, but it's not a capability that 
 exists today.

This is a very real issue. Difficult to do in today's code base.

 * It assumes the port's revision will be increased. That's not always 
 necessary. Sometimes the only change in the distfile is the name of (or 
 presence of) the enclosing directory, or there are only changes in comments 
 or documentation files or other files that don't affect the build, and in 
 those cases there would be zero benefit to increasing the port's revision and 
 forcing everyone to rebuild or redownload.

That's true. In this case, we should borrow an idea from DVCSes: use a
hash to see if something has changed (probably something like a Merkle
tree). This would be a nontrivial amount of work but would help mitigate
the whole 'epoch' business.

 * The old distfile would get removed from our mirrors, making it impossible 
 for anyone to later determine what exactly changed in the stealth update. 
 Many maintainers handle stealth updates incorrectly. It is nice for others to 
 be able to investigate after the fact.

If we used hashes in the distfile naming, we wouldn't be overwriting
things.

These are all just ideas / vague shots in the dark. I'm not volunteering
to do this work :-P
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: mpi

[Sean Farley]

Ryan Schmidt writes:

 On Sep 30, 2014, at 7:04 PM, Sean Farley wrote:

 This is pretty much was is done (modulo the blacklist). If I understand
 correctly, though, you want to remove gcc from being able to be used as
 a compiler? This would be a serious limitation.

 Removed as a C/C++/ObjC/ObjC++ compiler, yes. In what situations do you find 
 that using gcc as the C/C++/ObjC/ObjC++ compiler is still necessary?

Of course there are many situations. We're talking about numerical code
here, so these projects are sometimes pushing the boundaries of what the
compilers can optimize. It is a great help if one can test both of these
cases out.

Flat out removing all gcc compilers is dead on arrival and will
ultimately drive people to ditch MacPorts.

Using gcc for C and fortran, is not a problem. The only issue, of
course, is C++. Even then, using C++ is only a problem when trying to
mix libc++ and libstdc++. The question, to me, is: why is it still not
possible to distinguish foo+gcc and foo+clang in MacPorts?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [123602] trunk/dports/python/py-astropy/Portfile

[Sean Farley]

Ryan Schmidt writes:

 * It assumes the port's revision will be increased. That's not always 
 necessary. Sometimes the only change in the distfile is the name of (or 
 presence of) the enclosing directory, or there are only changes in comments 
 or documentation files or other files that don't affect the build, and in 
 those cases there would be zero benefit to increasing the port's revision 
 and forcing everyone to rebuild or redownload.
 
 That's true. In this case, we should borrow an idea from DVCSes: use a
 hash to see if something has changed (probably something like a Merkle
 tree).

 I'm not familiar with a Merkle tree. I skimmed the wikipedia page but I'm not 
 sure what you're suggesting here. What should be hashed, by whom, at what 
 time?

It's just a fancy way to help detect if a tree has changed. Might not be
helpful here, exactly.

 This would be a nontrivial amount of work but would help mitigate
 the whole 'epoch' business.

 I don't see what the epoch field has to do with this discussion at all.

It's an orthogonal discussion which I'll save for another time.

 * The old distfile would get removed from our mirrors, making it impossible 
 for anyone to later determine what exactly changed in the stealth update. 
 Many maintainers handle stealth updates incorrectly. It is nice for others 
 to be able to investigate after the fact.
 
 If we used hashes in the distfile naming, we wouldn't be overwriting
 things.

 Ok, that's another good suggestion. I've seen that approach used by debian 
 which puts each distfile in a directory whose name is the hash of the 
 distfile.

 ~


 Let me just once again make sure that I understand the situation that we're 
 discussing here. Here are the facts as I understand them. Let me know if I've 
 misunderstood our goal in this discussion or if there are any other aspects.


 1. It is the maintainer's responsibility to notice when a stealth update has 
 occurred.

 2. It is the maintainer's responsibility to obtain the new distfile and place 
 its new checksums into the portfile, after verifying that the new distfile is 
 correct and is not malicious.

 3. It is the maintainer's responsibility to decide whether this change 
 requires users to rebuild their ports, and on the basis of this determination 
 to increase the port's revision or not.

 4. It is considered too onerous for the maintainer to need to insert the line 
 dist_subdir ${name}/${version}_1 into the portfile when a stealth update 
 occurs, and we would like to make this step unnecessary.

That sounds right. What I'm attempting to improve (or, rather, stir up
awareness) are the many steps that are manual. Being that stealth
updates are infrequent, I usually forgot to check for them. I think 

A workflow I am trying to strive for (which maybe should be another email):

Task: update outdated ports

$ port echo maintainer:sean | parallel --trim lr port livecheck {}
mercurial seems to have been updated (port version: 3.0, new version: 3.1)

$ port maintainerupdate mercurial
  # this would replace the previous version string with the new one and
  # accept the checksum changes

$ hg ci -m mercurial: update to 3.1
$ hg push try-server

# this is where a buildbot would test the change and tell me a few
# common issues:
#   - was there a stealth update
#   - did I Use The Right Compiler
#   - run port test (or something similar)

If all the tests pass (and perhaps all the dependent ports pass) then it
would be allowed to be pushed to the central repository.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: mpi

[Sean Farley]

Ryan Schmidt writes:

 On Sep 30, 2014, at 8:08 PM, Sean Farley wrote:
 
 Ryan Schmidt writes:
 
 On Sep 30, 2014, at 7:04 PM, Sean Farley wrote:
 
 This is pretty much was is done (modulo the blacklist). If I understand
 correctly, though, you want to remove gcc from being able to be used as
 a compiler? This would be a serious limitation.
 
 Removed as a C/C++/ObjC/ObjC++ compiler, yes. In what situations do you 
 find that using gcc as the C/C++/ObjC/ObjC++ compiler is still necessary?
 
 Of course there are many situations. We're talking about numerical code
 here, so these projects are sometimes pushing the boundaries of what the
 compilers can optimize. It is a great help if one can test both of these
 cases out.
 
 Flat out removing all gcc compilers is dead on arrival and will
 ultimately drive people to ditch MacPorts.

 What also causes people to ditch MacPorts, or at least to file bug reports 
 about it, is when ports like boost offer variants, which the user rightly 
 assumes they can use, but whose use causes the port to either fail to compile 
 or causes other ports using that port to fail to compile.

 Of course we'll keep the gcc ports in MacPorts, we just can't really offer 
 the option of compiling arbitrary ports with g++ at the user's whim.


 Using gcc for C and fortran, is not a problem. The only issue, of
 course, is C++.

 True.

 Even then, using C++ is only a problem when trying to
 mix libc++ and libstdc++.

 Yup.

 The question, to me, is: why is it still not
 possible to distinguish foo+gcc and foo+clang in MacPorts?

 I'm not sure what you mean.

Why can't all a port's variants be installed at the same time?

$ port install boost
$ port install boost +gcc48

Every port could have its own custom prefix and only the active one
would be a symlink in /opt/local.

My point is that these issues all relate to depending on a port's
variant. This would be a powerful and very rich improvement to
MacPorts. A hacky alternative would be to provide a 'boost-stdlib' (or
whatever name) port that could be installed into a custom prefix for use
in this situation.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: mpi

[Sean Farley]

Ryan Schmidt writes:

 On Sep 30, 2014, at 9:08 PM, Sean Farley wrote:

 Ryan Schmidt writes:
 
 The question, to me, is: why is it still not
 possible to distinguish foo+gcc and foo+clang in MacPorts?
 
 I'm not sure what you mean.
 
 Why can't all a port's variants be installed at the same time?
 
 $ port install boost
 $ port install boost +gcc48
 
 Every port could have its own custom prefix and only the active one
 would be a symlink in /opt/local.

 That's not what variants are for. That's what subports are for.

Subports are trying to solve this but expose the implementation level
too far up. Only one solution should exist to depending on a
variant. Subports, unfortunately, put all the burden on the portfile
author and bloat the output of the list of ports.

$ port echo mpich*
mpich
mpich-clang
mpich-clang31
mpich-clang32
mpich-clang33
mpich-clang34
mpich-clang35
mpich-default
mpich-devel
mpich-devel-clang
mpich-devel-clang31
mpich-devel-clang32
mpich-devel-clang33
mpich-devel-clang34
mpich-devel-clang35
mpich-devel-default
mpich-devel-dragonegg31
mpich-devel-dragonegg32
mpich-devel-dragonegg33
mpich-devel-gcc43
mpich-devel-gcc44
mpich-devel-gcc45
mpich-devel-gcc46
mpich-devel-gcc47
mpich-devel-gcc48
mpich-devel-gcc49
mpich-devel-llvm
mpich-dragonegg31
mpich-dragonegg32
mpich-dragonegg33
mpich-gcc43
mpich-gcc44
mpich-gcc45
mpich-gcc46
mpich-gcc47
mpich-gcc48
mpich-gcc49
mpich-llvm

Why should this be exposed to the user? Imagine, now, if there were no
such thing as a variant. This would solve all the dependence issues on a
port's variant.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: mpi

[Sean Farley]

Lawrence Velázquez writes:

 On Sep 30, 2014, at 10:52 PM, Ryan Schmidt ryandes...@macports.org wrote:

 I understand the proposal, but I don't agree that we should implement it.

 It does seem like it would introduce a great deal of complexity to address 
 what is clearly (to me, at least) an antipattern (using variants to select 
 build options).

The complexity is much greater, indeed. And not something I wish to
implement in tcl.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: mpi

[Sean Farley]

Ryan Schmidt writes:

 On Sep 30, 2014, at 9:25 PM, Sean Farley wrote:
 
 That's not what variants are for. That's what subports are for.
 
 Subports are trying to solve this but expose the implementation level
 too far up. Only one solution should exist to depending on a
 variant. Subports, unfortunately, put all the burden on the portfile
 author and bloat the output of the list of ports.
 
 $ port echo mpich*
 mpich
 mpich-clang
 mpich-clang31
 mpich-clang32
 mpich-clang33
 mpich-clang34
 mpich-clang35
 mpich-default
 mpich-devel
 mpich-devel-clang
 mpich-devel-clang31
 mpich-devel-clang32
 mpich-devel-clang33
 mpich-devel-clang34
 mpich-devel-clang35
 mpich-devel-default
 mpich-devel-dragonegg31
 mpich-devel-dragonegg32
 mpich-devel-dragonegg33
 mpich-devel-gcc43
 mpich-devel-gcc44
 mpich-devel-gcc45
 mpich-devel-gcc46
 mpich-devel-gcc47
 mpich-devel-gcc48
 mpich-devel-gcc49
 mpich-devel-llvm
 mpich-dragonegg31
 mpich-dragonegg32
 mpich-dragonegg33
 mpich-gcc43
 mpich-gcc44
 mpich-gcc45
 mpich-gcc46
 mpich-gcc47
 mpich-gcc48
 mpich-gcc49
 mpich-llvm
 
 Why should this be exposed to the user? Imagine, now, if there were no
 such thing as a variant. This would solve all the dependence issues on a
 port's variant.

 I'm trying to explain that this is not what variants were made for.

 Variants are supposed to be for adding optional functionality, or choosing 
 between options.

Variants create a new node in the dependency DAG. Subports create a new
node in the dependency DAG. There is no topological difference. The only
difference is in how they were implemented.

It is understandable to not want to implement the greater complexity.
Your proposal is to get rid of gcc for compiling C/C++. If that's the
direction MacPorts wants to go, then I'd request that it be uniform: no
port has any variant to change the C/C++ compilers.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [123602] trunk/dports/python/py-astropy/Portfile

[Sean Farley]

Ryan Schmidt writes:

 That sounds right. What I'm attempting to improve (or, rather, stir up
 awareness) are the many steps that are manual. Being that stealth
 updates are infrequent, I usually forgot to check for them. I think 
 
 A workflow I am trying to strive for (which maybe should be another email):
 
 Task: update outdated ports
 
 $ port echo maintainer:sean | parallel --trim lr port livecheck {}
 mercurial seems to have been updated (port version: 3.0, new version: 3.1)

 For this I use my portmylivecheck script:

 https://svn.macports.org/repository/macports/users/ryandesign/scripts/

 $ port maintainerupdate mercurial
  # this would replace the previous version string with the new one and
  # accept the checksum changes

 For this I use my portcheckup script:

 https://svn.macports.org/repository/macports/users/ryandesign/scripts/

I have my own scripts (some based of yours) that help me but I would
suggest something more or less built-in (or at the very least installed
in /opt/local somewhere and easy to find).

I believe that would help us guide ticket reporters to take a more
active role in contributing patches.

 $ hg ci -m mercurial: update to 3.1
 $ hg push try-server

 If you're suggesting this just as a personal workflow for you, ok. But if 
 you're suggesting this would be an infrastructure available to everyone, then 
 we're either back at the old discussion of switching the MacPorts repository 
 from Subversion to git or mercurial or something else, which we agreed before 
 was too much effort, or we're talking about introducing a second version 
 control system into the mix somehow, which sounds really confusing to me.

I mean more of a having a fleet of buildbot(-ish) servers to help
developers run a suite of tests. I personally do not have enough
machines to test every OS. I am willing to pay for some virtual private
servers but I think there would need to be some improvement of MacPorts
infrastructure to allow easy deploy on test machines.

 # this is where a buildbot would test the change and tell me a few
 # common issues:
 #   - was there a stealth update

 We could perhaps enhance the buildbot scripts to re-fetch the upstream 
 distfile every time you commit the port and to let you know if its checksums 
 no longer match those in the portfile. But if so, only a human can determine 
 if that was because of a stealth update or because of something else. It 
 feels like this would be a waste of bandwidth and server resources, however.

This would at least save you the trouble of emailing the port author.

 #   - did I Use The Right Compiler

 You can of course use the setup documented at the bottom of the 
 UsingTheRightCompiler wiki page to determine this on your local machine prior 
 to committing.

This is manual and therefore missed by some developers (including me
when I got a new machine).

 If you're wanting the buildbot to automate testing this for you, then I 
 suppose instead of the current placeholder script that prints an error and 
 exits (which can sometimes be missed because the output is discarded or 
 hidden on a config.log or other log file), we could have the placeholder 
 script create a log file of its own, followed by actually invoking the 
 compiler so that the build succeeds anyway, then do something with the 
 logfile later.

Yes, this would be a great addition. Having better output, in general,
would be helpful for tickets, too.

 #   - run port test (or something similar)

 Yup, we've discussed previously that it would be nice if tests could be 
 automatically run, however many ports' tests do currently fail, and some 
 others take a very very very long time.

My hope would be for these failures to get better coverage (or in some
cases not tested, e.g. ATLAS).
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: mpi

[Sean Farley]

Ryan Schmidt writes:

 On Sep 30, 2014, at 10:35 PM, Sean Farley wrote:

 Lawrence Velázquez writes:
 
 On Sep 30, 2014, at 10:52 PM, Ryan Schmidt wrote:
 
 I understand the proposal, but I don't agree that we should implement it.
 
 It does seem like it would introduce a great deal of complexity to address 
 what is clearly (to me, at least) an antipattern (using variants to select 
 build options).
 
 The complexity is much greater, indeed. And not something I wish to
 implement in tcl.

 It's not just the complexity of modifying base. You're proposing that instead 
 of each port being installed to the same /opt/local prefix, each port would 
 be installed to its own prefix. This would probably require rebuilding all 
 ports, not to mention manually editing most of the portfiles (to change how 
 they find their dependencies), of which there are about 10,000 at this point. 
 I just don't see how anybody's ever going to have the time to do that.

Yes, might as well start over at that point :-)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: mpi

[Sean Farley]

Ryan Schmidt writes:

 On Sep 30, 2014, at 11:25 PM, Sean Farley wrote:
 
 Ryan Schmidt writes:
 
 On Sep 30, 2014, at 10:48 PM, Sean Farley wrote:
 
 Variants create a new node in the dependency DAG. Subports create a new
 node in the dependency DAG. There is no topological difference. The only
 difference is in how they were implemented.
 
 As far as I understand, variants are not involved in the dependency DAG in 
 MacPorts at this time. Only ports/subports are.
 
 Variants *in MacPorts* are not involved in the DAG *due to
 implementation*. They do indeed change the graph.

 I guess I'm not familiar with what graph you're talking about. I'm only 
 concerned with how dependencies work in MacPorts, not some other real or 
 hypothetical package manager.

I'm not talking about a package manager, just the dependency graph. What
I'm trying to point out is that variants change the graph. For example,
look at the wonky code of the dependents of cairo, checking for
cairo+quartz vs. cairo+x11.

It seems that you want to define variants as things that do not change
the graph. If so, MacPorts would (and should) have to ensure that
variant blocks don't change the dependencies (but then how to check the
dependents of a port?).

You would have a simpler definition of a variant (something that enables
an option but doesn't change the graph) but would end up with more
(sub)ports.

 It is understandable to not want to implement the greater complexity.
 Your proposal is to get rid of gcc for compiling C/C++. If that's the
 direction MacPorts wants to go, then I'd request that it be uniform: no
 port has any variant to change the C/C++ compilers.
 
 As I understand it, it is indeed our goal for ports not to have variants 
 that change the C/C++ compilers. However, many ports have gcc variants from 
 years ago before we fully understood the C++ standard library mismatch 
 issues and they have not been updated. For each port that has compiler 
 variants, we would need to examine them to see why they do that, and how to 
 safely remove them.
 
 The thorny ports (perhaps more) will be ATLAS and boost. A good place to
 start would be to simplify the ports that use the compilers port group
 and refactor that to make it use the configure.compiler logic. After
 that, there are approximately 118 ports that use gcc as a compiler.

 Yes, atlas has a bunch of compiler variants. I would love for most or all of 
 them to go away. But part of atlas needs fortran so it needs to deal with 
 that at least.

I would love for fortran to go away, too, but certain packages will need
different compilers.

 I already fixed boost by removing the use of the mpi portgroup. If mpi 
 support needs to be brought back, then a general solution needs to be found 
 for the mpi portgroup, which based on what you said earlier might be as 
 simple as deferring its work until the pre-configure block.

MPI support is definitely needed. I did not say earlier that would
work. I said that would only work if you and MacPorts decide to get rid
of gcc C/C++ compilers (and unify compilers-group with
configure.compilers).

I am a little worried that you glossed over the amount of work needed to
make a general solution. There are two big choices:

1) does the MacPorts community decide to tackle variants, subports,
   graphs, etc.?

2) does the MacPorts community drop support for gcc as a C/C++ compiler?

(2) is certainly less work but would also lose some advantage over other
package managers.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: RFC: Python maintenance policy

[Sean Farley]

Brandon Allbery writes:

 On Tue, Sep 23, 2014 at 12:49 AM, Sean Farley s...@macports.org wrote:

 I actually have the back story for this from the last PyCon. Suffice to
 say, it's because of Python 3 screwing up the treatment of unicode
 strings.


 Huh. I'd assumed arm-twisting from Red Hat, possibly with an education
 about enterprise support windows.

Here is a good article that outlines the frustration with unicode for
python libraries:

http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [125581] trunk/dports/science/abinit/Portfile

[Sean Farley]

Ryan Schmidt writes:

 On Sep 22, 2014, at 12:21 AM, dstru...@macports.org wrote:
 
 Revision
 125581
 Author
 dstru...@macports.org
 Date
 2014-09-21 22:21:07 -0700 (Sun, 21 Sep 2014)
 Log Message
 
 abinit: temporarily include config.log in main log file for debugging 
 buildbot configure failure on Mountain Lion.
 Modified Paths
 
  • trunk/dports/science/abinit/Portfile

 +# This is a temporary measure for debugging configure failure on Mountain 
 Lion buildslave.
 +
 +#checking for gcc... mpicc-mpich-mp
 +#checking whether the C compiler works... no
 +
 +post-configure {
 +system -W ${worksrcpath} cat config.log
 +}

 Good idea! Unfortunately because the configure script fails, the 
 post-configure block doesn't get run.

 You'd have to do something like set the configure.cmd to ./configure || true 
 to continue on even when in fails.

Why don't we always include config.log in the output for a failure?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [125581] trunk/dports/science/abinit/Portfile

[Sean Farley]

Ryan Schmidt writes:

 On Sep 22, 2014, at 1:27 AM, Sean Farley wrote:
 
 
 Ryan Schmidt writes:
 
 On Sep 22, 2014, at 12:21 AM, dstru...@macports.org wrote:
 
 Revision
 125581
 Author
 dstru...@macports.org
 Date
 2014-09-21 22:21:07 -0700 (Sun, 21 Sep 2014)
 Log Message
 
 abinit: temporarily include config.log in main log file for debugging 
 buildbot configure failure on Mountain Lion.
 Modified Paths
 
• trunk/dports/science/abinit/Portfile
 
 +# This is a temporary measure for debugging configure failure on Mountain 
 Lion buildslave.
 +
 +#checking for gcc... mpicc-mpich-mp
 +#checking whether the C compiler works... no
 +
 +post-configure {
 +system -W ${worksrcpath} cat config.log
 +}
 
 Good idea! Unfortunately because the configure script fails, the 
 post-configure block doesn't get run.
 
 You'd have to do something like set the configure.cmd to ./configure || 
 true to continue on even when in fails.
 
 Why don't we always include config.log in the output for a failure?

 IIRC, last time this came up we decided the config.log is enormous and might 
 make it harder to see the error printed by the configure script, which is 
 sometimes easier to understand than the extensive information in the 
 config.log. Therefore we settled on just printing the location of the 
 config.log.

This is a conundrum now since we can't (easily) access the config.log on
the buildbots. We could probably just zip the log file and print from
that since it'd be fairly easy. It'd also save a step for the end user:
they'd get a location to a single zipped logfile to upload to a ticket.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: RFC: Python maintenance policy

[Sean Farley]

Lawrence Velázquez writes:

 Maintaining old versions of CPython that aren't supported upstream is
 annoying and a poor use of our time, so I'd like to propose
 a maintenance policy. After we chit-chat about it, I'll write something
 up on the wiki (hopefully a little clearer) and inform macports-users.

 The term replaced by signifies using the replaced_by Portfile option
 to obsolete a port.

 The term X.Y refers to the CPython series in question.

 The term A.B refers to the latest release on X.Y's development branch
 *at the time of deprecation*. (The policy will ignore new upstream
 releases made during the deprecation period.)

 The term M.N refers to an arbitrary release between X.Y and A.B.


 == POLICY ==

 The deprecation period for the X.Y series begins when the pythonXY port
 is updated to the final upstream bugfix release and ends when the port
 is replaced by pythonAB. Upstream security fixes may still be applied to
 pythonXY during this period.

 Once pythonXY is deprecated:

   - New ports must not use pythonXY or create pyXY subports.

   - After all dependents have been migrated, ports that use pythonXY
 must switch to pythonAB.

   - After all dependents have been retired, pyXY-foo ports must be
 replaced by pyAB-foo. A pyXY-foo module that has been subsumed into
 the A.B standard library must be replaced by pythonAB, although any
 intermediate pyMN-foo ports may remain.

   - Retired subports must be moved to a graveyard metaport so that
 subsequent changes to their superports do not trigger spurious
 failures on the buildslaves.

 The pythonXY port is replaced by pythonAB one to two years after it is
 updated to the final upstream bugfix release. At this point, the
 deprecation period concludes, and the X.Y series is considered retired.


 = SCHEDULE =

 My short-term goal is to cut us back to the two most recent releases on
 each CPython dev branch. Thus, the following series are deprecated and
 will be retired on 1 January 2015:

 - 2.4 series
 - 2.5 series
 - 3.1 series
 - 3.2 series

 The following series have also seen their final upstream bugfix release
 and should thus be considered deprecated. They will be retired on
 1 January 2016:

 - 2.6 series
 - 3.3 series

Sure, that all sounds fine.

 The following series seems to be undead and/or immortal. We'll pencil it
 in for Ragnarok or thereabouts:

 - 2.7 series

I actually have the back story for this from the last PyCon. Suffice to
say, it's because of Python 3 screwing up the treatment of unicode
strings.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: We have a spam problem

[Sean Farley]

Frank Schima writes:

 Hi all,


 I just spent the last half hour closing about 40 spam tickets which arrived 
 last night - most in a 15 minute period. We need to do something about the 
 spam problem because it seems to be getting worse. I just tested creating a 
 new account and only a simple email verification goes out. I tested that I 
 could indeed not login until I clicked the verification URL that was emailed 
 to me. What else can we do about this?

 While I was wasting my time doing the same repetitive keystrokes on most of 
 the spam, I have some ideas which might be nice:
  - Implement a captcha per ticket #42484 [1]
  - Implement a rather onerous password policy to make it harder to sign up. 
 Right now we have no password policy. 
  - Delay maybe 30 minutes before sending out the verification email. 
  - Add a “mark spam” button to the wiki which changes the summary, 
 description and keywords to “spam” and closes the ticket as invalid in a 
 single click - maybe with a checkbox next to it to prevent mistakenly 
 pressing it? Obviously only Macports committers should be able to do this. 
  - For all new accounts, have a 24 (48 or 72?) hour waiting period where the 
 user can only create a single ticket or add a single comment. 
  - If we want to get serious, we could have the registration page have some 
 fields such as “why are you creating an account?” and have all registrations 
 be approved by a Macports committer. But that would be a last resort only. 

Yes, please. I am getting really tired of spam in my inbox.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Retiring Python 2.4 and 2.5

[Sean Farley]

Frank Schima writes:

 On Sep 15, 2014, at 7:56 PM, Lawrence Velázquez lar...@macports.org wrote:

 I'm trying to adapt Ned Deily's patches for Yosemite[1] to the Python ports. 
 Adapting them to all the Python 3.x ports was tedious enough, but now I've 
 made it to Python 2.4 and 2.5. I feel like I'm slapping bandages onto 
 patients who have been brain-dead for 5.74 and 3.31 years, respectively.
 
 Is there some overwhelmingly good reason we still provide these, given that 
 2.7 is still alive and kicking? Can we please stop providing them?
 
[1] http://bugs.python.org/issue21811

 Yes, remove them. We have talked about and even made progress towards 
 removing python 2.4 in the past. 

Apparently, I am the only one still using them (for testing purposes).
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Retiring Python 2.4 and 2.5

[Sean Farley]

Lawrence Velázquez writes:

 On Sep 16, 2014, at 1:30 AM, Clemens Lang c...@macports.org wrote:

 If I were you, I'd set a timeout and if nobody argues that we should keep 
 them
 for a good reason, delete them once the timeout has passed. Probably ask 
 -users,
 too.

 I like this.

 While we're at it, isn't 2.6 unsupported as well?

 Yes, and so are 3.1 through 3.3. Frankly, I'd fully support replacing all of 
 them with python2 @2.7.8 and python3 @3.4.1 (which would also make it easy to 
 comply with PEP 394*), but that might be a wee bit radical for some.

 My problem with python24 and python25 (aside from having to maintain dead 
 software) is that they aren't framework installations, making them even more 
 of a pain to deal with. Note the 2.4/2.5-specific logic in python-1.0, for 
 example. python26 is pretty similar to python27, at least.

All good points. I guess I'd be ok with removing them as well.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Non versioned ports

[Sean Farley]

Vincent Habchi writes:

 Le 24 août 2014 à 18:53, Sean Farley s...@macports.org a écrit :

 Why not use the bitbucket port group?
 
 PortGroup   bitbucket 1.0
 bitbucket.setup petebunting rsgislib 52fb22e
 version 0.0.20140822

 Uh, I tried that and it works (fetch okay), but then I have a problem.

 The fetch creates a subdirectory ‘52fb22e' under ‘work’ and in this 
 subdirectory, I find the ‘trunk’ directory which contains the code. Now if I 
 try to modify worksrcdir to point to ‘52fb22e/trunk’, then the fetch is 
 placed under this new arborescence rather than directly under ‘52fb22e’, so 
 the code is now in ‘52fb22e/trunk/trunk’. Etc. Sounds like the bitbucket port 
 uses ‘worksrcdir’ to create the directory in which to store the code. Any 
 workaround?

 Vincent

There are a few ways to work around this. In the dolfin port, I do:

configure.dir   ${worksrcpath}/build
build.dir   ${worksrcpath}/build

You could try changing the worksrcpath but I don't know if that would
work. Or maybe just changing the worksrcdir in a different phase.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Non versioned ports

[Sean Farley]

Vincent writes:

 From the command line, you can use revsets:
 $ hg log -G -r 'date(2014-08-22)'
 
 On the MacPorts repo, that will result in a lot of changesets. For a
 portfile, you really must specify a commit hash.

 I suppose that’s what I did, but since you seem to master Mercurial much 
 better than me (frankly, I am a rookie), I’d rather call on your expertise:

 I looked at the website of the repository, « commits » page. There are three 
 columns: author, commit # and a comment. I surmised that the commit # would 
 be the right information to be put after the -u option of the ‘clone’ 
 command, so I wrote this for the fetch phase (assuming 52fb22e is the commit 
 #):

 fetch {
system -W ${workpath} \
${prefix}/bin/hg clone -u 52fb22e 
 https://bitbucket.org/petebunting/rsgislib rsgislib »
 }

 Is that correct?

Why not use the bitbucket port group?

PortGroup   bitbucket 1.0
bitbucket.setup petebunting rsgislib 52fb22e
version 0.0.20140822
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Non versioned ports

[Sean Farley]

Lawrence Velázquez writes:

 On Aug 23, 2014, at 7:25 AM, Vincent vi...@macports.org wrote:

 However, I’ll have a look a ‘mercurial’ (unless someone out there is a guru 
 of this yet-another-DRC and can advise me directly) to figure out if there 
 is a way to specify a date as a revision. In which case, yes, that would 
 make sense.

 http://www.selenic.com/mercurial/hg.1.html#date-formats

From the command line, you can use revsets:

$ hg log -G -r 'date(2014-08-22)'

On the MacPorts repo, that will result in a lot of changesets. For a
portfile, you really must specify a commit hash. In the
py-sphinx-contrib port, I use '0.0.MMDD' for the version. If the
project ever decides to tag a version, then that will be higher than the
one I made up. Also, it's clear from reading the version that it's a
made up one.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: new ports and maintainer

[Sean Farley]

Daniel J. Luke writes:

 On Aug 9, 2014, at 3:11 PM, Sean Farley s...@macports.org wrote:
 
 In fact I've proposed combining openmaintainer and nomaintainer before. But 
 would this actually get us anything useful?
 
 For one, it would save the manual work of reminding devs that forget.
 For another, it would be consolidate some of the work that it takes to
 remind people on Trac.

 what?

 how does changing the label in the portfile do any of that?

It saves the emailing and new commits to change openmaintainer to
nomaintainer for mistakes. Furthermore, it makes removing a name from a
maintainer list a simple task of search and replace, rather than
figuring out if that name was the last one so nomaintainer can be added
(and also checking that openmaintainer wasn't in that list). This change
would be a small step in streamlining macports development.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [123602] trunk/dports/python/py-astropy/Portfile

[Sean Farley]

Ryan Schmidt writes:

 On Aug 11, 2014, at 10:32 AM, robitai...@macports.org wrote:
 
 Revision
 123602
 Author
 robitai...@macports.org
 Date
 2014-08-11 08:32:31 -0700 (Mon, 11 Aug 2014)
 Log Message
 
 py-astropy: updated checksums following change in tar file
 Modified Paths
 
  • trunk/dports/python/py-astropy/Portfile
 Diff
 
 Modified: trunk/dports/python/py-astropy/Portfile (123601 = 123602)
 
 --- trunk/dports/python/py-astropy/Portfile  2014-08-11 14:32:31 UTC (rev 
 123601)
 +++ trunk/dports/python/py-astropy/Portfile  2014-08-11 15:32:31 UTC (rev 
 123602)
 
 @@ -5,6 +5,7 @@
 
  PortGroup   python 1.0
 
  namepy-astropy
 
  version 0.4.1
 
 +revision1
 
  maintainers robitaille
 
  
 
  categories-append   science
 
 @@ -18,9 +19,9 @@
 
  homepagehttp://www.astropy.org
  master_siteshttp://pypi.python.org/packages/source/a/astropy/
  distnameastropy-${version}
 
 -checksums   md5 1a37a582e57ea391955a0dcc46185953 \
 -sha19d03b5fd3d9de4ce48cc855a4d7b75cbc8570dd9 \
 -rmd160  cb283ee6a4dd8e52ef27796735e5dd797cd8e697
 
 +checksums   md5 3e52e2f86aa962b4fcd8eef0f75752de \
 +sha1b089606990026e31ca3977fb983151e1ed2ab449 \
 +rmd160  7498aa95f36cfa0fa62c34ed14fca7fbb119322c

 Anyone who had the previous file, including our automated systems, will now 
 encounter a checksum mismatch. To fix this please follow the recipe for 
 stealth updates:

 http://trac.macports.org/wiki/PortfileRecipes#stealth-updates

Why isn't this automatically done for revision bumps? This seems like
another task that is needlessly manual.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [123602] trunk/dports/python/py-astropy/Portfile

[Sean Farley]

Daniel J. Luke writes:

 On Aug 11, 2014, at 1:39 PM, Sean Farley s...@macports.org wrote:
 
 Anyone who had the previous file, including our automated systems, will now 
 encounter a checksum mismatch. To fix this please follow the recipe for 
 stealth updates:
 
 http://trac.macports.org/wiki/PortfileRecipes#stealth-updates
 
 Why isn't this automatically done for revision bumps? This seems like
 another task that is needlessly manual.

 probably because no one has submitted a patch to automate it?

 Most projects avoid doing stealth-updates, so this problem doesn't come up 
 extremely often (which maybe explains why no one has been motivated to make 
 the procedure more automated yet?)

True. Though, I've seen it come up enough that I've thought about
writing a patch for it. I should probably add a ticket for it so others
could reference it.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: new ports and maintainer

[Sean Farley]

Ryan Schmidt writes:

 On Aug 8, 2014, at 11:48 PM, Sean Farley wrote:

 Ryan Schmidt writes:
 
 On Aug 8, 2014, at 10:59 PM, Ryan Schmidt wrote:
 
 port echo name:^p5- and maintainer:nomaintainer
 
 How would you produce that list if nomaintainer and openmaintainer 
 were combined into a single value?
 
 Thinking about it a bit more, I guess the answer is that it is a regular 
 expression search so I could just anchor it to the beginning and end.
 
 Ports I am the only maintainer of:
 
 
 $ port echo maintainer:^ryandesign$|wc -l
 357
 
 
 Ports I maintain with others or openly:
 
 
 $ port echo maintainer:ryandesign|wc -l
 908
 
 :-)
 
 In general, these kinds of problems are a matter of implementation, not
 design. For instance, we could augment this language to have finer grain
 search operators:
 
 $ port echo maintainer:(ryandesign and not openmaintainer)

 That can already be done:


 $ port echo maintainer:ryandesign and not maintainer:openmaintainer | wc -l
  369


 Although that search takes a lot longer than it really should.

 But the issue at hand was not finding maintained ports without 
 openmaintainer; the issue was differentiating maintained-but-open ports from 
 unmaintained ports in a hypothetical future where we no longer use separate 
 terms, and I used my own handle as an example. But as I said using a 
 double-anchored regular expression would work.

 In fact I've proposed combining openmaintainer and nomaintainer before. But 
 would this actually get us anything useful?

For one, it would save the manual work of reminding devs that forget.
For another, it would be consolidate some of the work that it takes to
remind people on Trac.

But really, it's just about cleaning up code and streamlining some of
this review process for the MacPorts community.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: new ports and maintainer

[Sean Farley]

Daniel J. Luke writes:

 On Jul 25, 2014, at 7:21 AM, Ryan Schmidt ryandes...@macports.org wrote:
 
 On Jul 24, 2014, at 5:08 PM, Sean Farley wrote:
 The maintainer is supposed to hold the consolidated knowledge of that 
 software as relates to building it within MacPorts, and may have very good 
 reasons for why a port does or does not do something and doesn't want it 
 changed by someone who may not be aware of all the implications.

 +1 for this.

 Especially since the maintainer has signed on to handle primary support for 
 the port(s) she/he has agreed to maintain.

Yes. Consolidated knowledge is something that is hard to manage and
share. The best I've seen how other projects deal is to leave
constructive and helpful comments as to why something is done the way it
is.

Admittedly, that is a lot of work.

 We do have exceptions where others may commit to non-open ports.

 Yes - if a port is broken (build failure, upstream security release/patch) - 
 where the smallest reasonable change can be applied immediately (although 
 notifying the maintainer in this case is always a good idea).

 If we need to change policy to make this easier (give more general 
 exceptions, make the timeouts shorter, proactively figure out when 
 maintainers leave, etc.) we should do so. I think this is one of two things 
 Sean is getting at (if I understand correctly).

Yes, indeed. That's something I was trying to get at.

 On Jul 24, 2014, at 8:06 PM, Mihai Moldovan wrote:
 I do not want to have to update a timestamp in every portfile periodically. 
 That's just busywork. We have other ways to see if a maintainer is active.

 +1 for this too. I have at least one non-openmaintainer port that went ~9 
 years between upstream releases - I'm not going to remember to check in a 
 mostly meaningless timestamp update every 6 months just to keep it 
 non-openmaintainer.

Updating some timestamp is doomed to fail.

 I agree we have a problem with maintainers disappearing and it taking some 
 time for us to notice and react. But we do have a port abandonment 
 procedure, and I would instead focus on improvements to that procedure, and 
 better maintainer education. For example, we could improve the port 
 abandonment procedure to include all other ports by the same maintainer; 
 that's how I usually file the tickets anyway.

 +1

Yes, improving this procedure would be great and go a long ways, I think.

 We could mention in the guide what our expectations are when a maintainer no 
 longer has the time or interest for maintaining. We could recommend the 
 addition of openmaintainer when someone assumes maintainership, especially 
 for non-committers. We could include information on how to retire in the 
 email that management sends to approved committers.
 
 There was a recent discussion about manually sending out a maintainer 
 survey, but it would be nice not to bother maintainers who are clearly 
 active. We could develop an automated way to survey maintainers about their 
 continued involvement. An automated system could estimate a maintainer's 
 level of current involvement in the project by checking for tickets filed, 
 commits made, mailing list posts sent, and only send such emails 
 periodically to developers who have not been active in the last 3 months, 
 say. A maintainer could reply to such an email to indicate whether they are 
 still active; a no response or multiple unanswered emails could trigger 
 the port abandonment procedure, e.g. by automatically filing a port 
 abandonment ticket or even by automatically removing them as maintainer of 
 their ports.

 I wouldn't mind responding to an email (or filling out a web form linked from 
 an email) periodically even if there's other evidence that I'm active.

How about we just have a policy (or just a community understanding) that
if a developer timed out (for whatever reason) and then comes back, that
he/she can re-add their name?

This would be something akin to garbage collection in a programming
language :-)

 I /think/ this addresses (or starts to address) half of what Sean is asking 
 for. The other half seems to be distaste for trac and the current ticket 
 workflow (and reminds me of earlier conversations about moving to github). 
 I'm pretty indifferent to that, since I think trac works well enough for the 
 most part and am not convinced that the effort of moving to something 
 different will really pay off in any way. I'm pretty indifferent to it, 
 though.

 Sean - did I get that right? You're suggesting that 1. Maintainer Timeout / 
 Port abandonment procedure is too hard and takes too long and 2. trac (as 
 currently configured) is not good enough?

Yep, pretty much. It took a while (since I was traveling) to collect my
thoughts on the matter and respond. One of my points is that there is no
real difference between 'openmaintainer' and 'nomaintainer'. One has
other devs listed, the other does not, so why not combine the names?
It's easy enough to see