Re: GitHub desired workflow...

[Eric A. Borisch]

A newer git (2.6.0 [1]) is required for the rebase.autostash configuration
switch to work. As of Xcode 7.2, git is at 2.5.4.

With these two options set to true, (rebase.autostash and pull.rebase),
'git pull' feels like 'svn update' (at least to me) -- which is very nice
for transition documentation to note, with the caveat that you need a
new-enough git installed.

  - Eric

[1]
https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.6.0.txt

On Tue, Nov 1, 2016 at 12:53 PM, Joshua Root  wrote:

> While using the git port is a good idea for many reasons, the
> Xcode-provided git should have autostash since Xcode 5.1 or so.
>
> - Josh
>
> On 2016-11-2 03:40 , Eric A. Borisch wrote:
>
>> As should the fact that, for this to work, you need to be using a
>> new-enough git (like from ports) and not the system-provided one.
>>
>> On Tue, Nov 1, 2016 at 4:01 AM, Marko Käning > <mailto:mk-macpo...@posteo.net>> wrote:
>>
>> On 01 Nov 2016, at 01:10 , Brandon Allbery > <mailto:allber...@gmail.com>> wrote:
>>
>> > You can even configure so that becomes the default for "git pull"
>> for that repo.
>> >
>> > git config --local --bool pull.rebase true
>> > git config --local --bool rebase.autoStash true
>>
>> This should go into the wiki page!
>>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Eric A. Borisch]

As should the fact that, for this to work, you need to be using a
new-enough git (like from ports) and not the system-provided one.

On Tue, Nov 1, 2016 at 4:01 AM, Marko Käning  wrote:

> On 01 Nov 2016, at 01:10 , Brandon Allbery  wrote:
>
> > You can even configure so that becomes the default for "git pull" for
> that repo.
> >
> > git config --local --bool pull.rebase true
> > git config --local --bool rebase.autoStash true
>
> This should go into the wiki page!
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Eric A. Borisch]

I hoped someone would point me to a command like this. Thanks!

  - Eric

On Monday, October 31, 2016, Joshua Root  wrote:
>
> I'm using 'git pull --rebase --autostash' which does the stash-before and
> pop-after automatically.
>
> - Josh
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

GitHub desired workflow...

[Eric A. Borisch]

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.

If I'm wrong, or if I've missed something, please let me know; there's been
more discussion than I've had time to follow of late surrounding this
transition...

  - Eric

"Linux is like if the creator of git wrote an operating system." -
SwiftOnSecurity
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [152440] trunk/dports/net

[Eric A. Borisch]

Fixed in r152601. I flubbed the commit message, though. Only human.

  - Eric

On Monday, September 12, 2016, Ryan Schmidt  wrote:

>
> > On Sep 8, 2016, at 11:28 PM, ebori...@macports.org  wrote:
> >
> > Revision
> > 152440
> > Author
> > ebori...@macports.org 
> > Date
> > 2016-09-08 21:28:04 -0700 (Thu, 08 Sep 2016)
> > Log Message
> >
> > zabbix3: New port.
> > Modified Paths
> >
> >   • trunk/dports/net/zabbix3/Portfile
>
> > +patchfiles  log_and_pid_locations.patch
>
> This patchfile is missing.
>
>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [152440] trunk/dports/net

[Eric A. Borisch]

On Friday, September 9, 2016, Ryan Schmidt  wrote:

>
> > On Sep 8, 2016, at 11:28 PM, ebori...@macports.org  wrote:
> >
> > Revision
> > 152440
> > Author
> > ebori...@macports.org 
> > Date
> > 2016-09-08 21:28:04 -0700 (Thu, 08 Sep 2016)
> > Log Message
> >
> > zabbix3: New port.
>
>
> > Added Paths
> >
> >   • trunk/dports/net/zabbix3/
>
>
> > +--with-gnutls=/opt/local \
> > +--enable-ipv6
>
> Surely that should be "${prefix}" not "/opt/local"?
>
>
> > +eval xinstall -m 755 -W ${worksrcpath}/database/${DBFILES} \
> > +data.sql images.sql schema.sql \
> > +${destroot}${prefix}/share/zabbix/scripts
>
> It doesn't look like this needs eval -- I don't see a list. If a list were
> being used, the expansion operator ("{*}") should be used instead of eval.
>

Yes on both parts. Thanks for catching those; I'll clean them up.

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

Soliciting feedback for python port changes (libedit v. readline)

[Eric A. Borisch]

Python (in the terminal) continues to have issues with libedit when exiting
the interpreter, leaving the terminal mis-configured.

Please weigh in if you are concerned about how this is handled --
potentially by switching all python variants to default to readline, which
is what has already been done on python27.

Ideally we would track down when this (python+libedit) broke; if someone
has the time and motivation to do that, please raise your hand!

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

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

Re: port:libclang

[Eric A. Borisch]

On Wed, Mar 9, 2016 at 6:13 AM, René J.V.  wrote:

> That parser only uses libclang (and thus libLLVM), and the install
> footprint of required LLVM/Clang stuff can apparently be reduced to about
> 50Mb (on Linux or MS Windows) which is a far cry from the almost 3.5 Gb a
> full, uncompressed LLVM+Clang 3.7 install takes.
>

FWIW, if compressed with HFS+ compression (afsctool with -f -6 -s 50
options, for reference), llvm-3.7 and clang-3.7 combined take 756MB rather
than 3.4+ GB.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: about keeping a checksums table in a separate file

[Eric A. Borisch]

On Wednesday, February 3, 2016, Eric A. Borisch 
wrote:

> On Monday, February 1, 2016, Daniel J. Luke  > wrote:
>
>> On Feb 1, 2016, at 3:09 PM, René J.V. Bertin  wrote:
>> > As an example of a potentially non-trivial file for automatic checksum
>> updating
>>
>> I don't think this would be as hard to implement as you seem to think it
>> would be.
>>
>> As a first try, a really simple s/$oldchecksum/$newchecksum/ would
>> probably work (I'm perhaps not creative enough to think of a use-case where
>> that would false-positive and change something unintended).
>>
>
> I will try to check in a tool I've used to automate this later tonight; I
> just need to find a few moments to put the macports license boilerplate in
> it first. It is a python script that drives the port command to determine
> what (if any) checksums need to be updated for a port, and then uses sed to
> actually (s/old/new/) update it. It runs sed with no backup, so it is
> best used in an svn version so you can see what it has changed. (Or it
> could be modified to create a backup file easily enough.)
>

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

Re: about keeping a checksums table in a separate file

[Eric A. Borisch]

On Monday, February 1, 2016, Daniel J. Luke  wrote:

> On Feb 1, 2016, at 3:09 PM, René J.V. Bertin  > wrote:
> > As an example of a potentially non-trivial file for automatic checksum
> updating
>
> I don't think this would be as hard to implement as you seem to think it
> would be.
>
> As a first try, a really simple s/$oldchecksum/$newchecksum/ would
> probably work (I'm perhaps not creative enough to think of a use-case where
> that would false-positive and change something unintended).
>

I will try to check in a tool I've used to automate this later tonight; I
just need to find a few moments to put the macports license boilerplate in
it first. It is a python script that drives the port command to determine
what (if any) checksums need to be updated for a port, and then uses sed to
actually (s/old/new/) update it. It runs sed with no backup, so it is best
used in an svn version so you can see what it has changed. (Or it could be
modified to create a backup file easily enough.)

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

Re: HFS+ compression options (WAS: VLC cannot play MKV files?)

[Eric A. Borisch]

On Fri, Jan 29, 2016 at 9:45 AM, René J.V.  wrote:
> On Friday January 29 2016 09:23:15 Eric A. Borisch wrote:
>
>>Perhaps an opportunistic execution of afsctool on just-extracted (not
>>yet moved into place) files in portimage.tcl (similar to the
>>opportunistic use of lbzip2 or pbzip2 during extraction) could be
>>done?
>
> Sure, that's a possibility.
>
>>I'd tend towards find + xargs (possibly with -P  to speed
>
> I'm not sure why you'd want that? Even the "stock" afsctool can take a 
> directory.

Haven't played with it; that's even easier. Does it parallelize, too?

>>controlled (able to be forcefully disabled) by a config option and a
>>check that the filesystem is HFS+.
>
> Afsctool won't attempt anything if the fs isn't HFS+ or the file isn't of a 
> supported type.

One less check to perform then.

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

HFS+ compression options (WAS: VLC cannot play MKV files?)

[Eric A. Borisch]

On Wed, Jan 27, 2016 at 1:16 PM, Clemens Lang  wrote:
> On Wed, Jan 27, 2016 at 03:00:52PM +0100, Rainer Müller wrote:
>> > I think the system bsdtar doesn't support this on all OS X versions
>> > that do support hfs compression.
>>
>> Right, on my OS X 10.10.5 Yosemite it does not seem to be supported. In
>> the ticket you said it was not supported on OS X 10.9. Can anybody
>> please check whether it is actually supported on OS X 10.11 El Capitan?
>>
>> $ echo "666f6f00...00" | /usr/bin/bsdtar --hfsCompression -xqOf -
>> foo>/dev/null
>> bsdtar: Option --hfsCompression is not supported
>> Usage:
>> ...

Perhaps an opportunistic execution of afsctool on just-extracted (not
yet moved into place) files in portimage.tcl (similar to the
opportunistic use of lbzip2 or pbzip2 during extraction) could be
done? I'd tend towards find + xargs (possibly with -P  to speed
things up) but any number of approaches would work. Should likely be
controlled (able to be forcefully disabled) by a config option and a
check that the filesystem is HFS+.

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

Re: [144262] trunk/dports/lang/py-htmldocs/Portfile

[Eric A. Borisch]

On Tue, Jan 5, 2016 at 1:03 PM, Clemens Lang  wrote:
> Hi,
>
> On Tue, Jan 05, 2016 at 12:44:49PM -0600, Ryan Schmidt wrote:
>>
>> I'm not comfortable with installing unchecked files on user systems.
>> The whole point of the checksum system is to verify that the files
>> that are installed on user systems are the same files that were tested
>> by the maintainer. By skipping the checksum phase you remove that
>> safeguard.
>
> I agree, please revert that. This is an invitation for attackers.

I'd prefer to avoid it, obviously. Suggestions, then?

This is a tarball of documentation coming directly from
docs.python.org, which seem to be regenerated nightly (with new
checksums). The other versions are available in a stable form
(http://www.python.org/ftp/python/doc) but not the latest for 34
(3.4.4) or 35 (3.5.1). If there is another, stable, download location,
I'd be happy to point to it.

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

Re: [144027] trunk/dports/lang/py-htmldocs/Portfile

[Eric A. Borisch]

There's a later commit that added dist_subdir for those versions that
have been stealth-updated...

On Sat, Jan 2, 2016 at 11:05 AM, Ryan Schmidt  wrote:
>
>> On Dec 30, 2015, at 12:10 AM, ebori...@macports.org wrote:
>>
>> Revision
>> 144027
>> Author
>> ebori...@macports.org
>> Date
>> 2015-12-29 22:10:10 -0800 (Tue, 29 Dec 2015)
>> Log Message
>>
>> py-htmldocs: Update (again?) checksum for py35-htmldocs. Moved revision 
>> numbers into by-subport for bumping when checksums change. See #50172.
>> Modified Paths
>>
>>   • trunk/dports/lang/py-htmldocs/Portfile
>> Diff
>>
>> Modified: trunk/dports/lang/py-htmldocs/Portfile (144026 => 144027)
>>
>> --- trunk/dports/lang/py-htmldocs/Portfile2015-12-30 05:55:28 UTC (rev 
>> 144026)
>> +++ trunk/dports/lang/py-htmldocs/Portfile2015-12-30 06:10:10 UTC (rev 
>> 144027)
>> @@ -47,45 +47,52 @@
>>  notes   ${long_description}
>>
>>  if {${python.version} == 26} {
>> +  revision  1
>>checksums \
>>  rmd160  a7bd375ac3a62249529da805693c3b15510ff976 \
>>  sha256  
>> f3faa71f4b0cc8fa2bb6c5624233ae79983a2d5c11195fb2089668c60ceb7f1f
>>  }
>>
>>  if {${python.version} == 27} {
>> +  revision  2
>>checksums \
>>  rmd160  5962cd9d48d5678a832cfef7a693ffcadb66d55e \
>>  sha256  
>> a6b61188de5e26295533a619f0e89dd180c6b4385d27e3239581de8aa1d4ceaf
>>  }
>>
>>  if {${python.version} == 31} {
>> +  revision  1
>>checksums \
>>  rmd160  29717979d6a8b4e970a4747e101259da3e3890c1 \
>>  sha256  
>> ff327cfaa1219d8d82fcb4f3bae3ec4ce28567982a49784004130521d282faa0
>>  }
>>
>>  if {${python.version} == 32} {
>> +  revision  1
>>checksums \
>>  rmd160  039539fc90454d35525c8b9478156f7135b86622 \
>>  sha256  
>> b746ef40a29abe7949e5f183e236a0734c58b841c0600043160a518390704c13
>>  }
>>
>>  if {${python.version} == 33} {
>> +  revision  1
>>checksums \
>>  rmd160  84290bfaea54b943025f7088268f256d4a50cf71 \
>>  sha256  
>> 54da33f8a91be819e7ac22fdc88c5125bdd4c67494f52dd79d6b603572c41fb0
>>  }
>>
>>  if {${python.version} == 34} {
>> +  revision  1
>>checksums \
>>  rmd160  3cfdc8682fee199be83163026aa2a387f36e14af \
>>  sha256  
>> 62690cf2d6781cf761aa4ae3c81b8a794700f6b61e4cef0cadbcf4f96a5b7da1
>>  }
>>
>>  if {${python.version} == 35} {
>> +  revision  2
>>checksums \
>> -rmd160  dc49af77633fbb4c4766cd313f1609295d5a0438 \
>> -sha256  
>> 1bf4aa73555eb1c38504ab4ef8368c15d6e026b0669d477f7e7d3db8edfae75b
>> +rmd160  708cb554c1b80bcf795f89936ca9bdac11abffb5 \
>> +sha256  
>> ad75e90b950c6abfae550680576ad8ffa48d8ef579fcb98687037590c7576d98
>>  }
>
> Stealth updates need to be handled per this recipe:
>
> https://trac.macports.org/wiki/PortfileRecipes#stealth-updates
>
> py-htmldocs is not handling the dist_subdir correctly.
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [143618] trunk/dports/lang/py-htmldocs/Portfile

[Eric A. Borisch]

On Tuesday, December 15, 2015, Ryan Schmidt  wrote:

>
> > On Dec 15, 2015, at 5:40 PM, ebori...@macports.org  wrote:
> >
> > Revision
> > 143618
> > Author
> > ebori...@macports.org 
> > Date
> > 2015-12-15 15:40:40 -0800 (Tue, 15 Dec 2015)
> > Log Message
> >
> > py-htmldocs: Remove 25, add 35. Update download / regex checks. Set
> license to restrictive to avoid having MacPorts 'build' packages (which are
> essentially re-archiving the exctraction of the distfile.) installs_lib is
> 'no', so this won't impact other packages distribution.
> > Modified Paths
> >
> >   • trunk/dports/lang/py-htmldocs/Portfile
>
> > -license {PSF}
> >
> > +# Not really, but don't bother serving up archives from
> packages.macports.org
> > +# when they would (effectively) be a re-packaging of the distribution
> file.
> > +# installs_libs below keeps this from impacting any (if they exist)
> ports
> > +# depending on this one.
> > +license restrictive
>
> Why prevent this? This will prevent users from installing the port if they
> have "buildfromsource never" set in macports.conf.
>

Was just trying to save some resources on the build bots / mirrors; seemed
silly to download and unzip it just to zip it and upload it somewhere
else. Easy
enough to take back out.

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

Re: Why py-spyder{,-devel} depends on py-htmldocs.

[Eric A. Borisch]

Petr,

1) it is a trivial install -- just download and extract -- so
hopefully it's not a big issue. We can always move it into a variant.
2) Spyder has a menu link to go to python documentation, which I patch
to go to the installed documentation. (hence the dependency.)

 - Eric

On Tue, Dec 15, 2015 at 3:05 PM, petr <9...@ingv.it> wrote:
>
> Hi Eric,
>
> why does py-spyder{,-devel} actually depend (library dependency) on 
> py-htmldocs. I understand that the py??-htmldocs provides the respective 
> python documentation, so why would I need it as dependency of a python 
> module/application? I think py-spyder{,-devel} to do so.
>
> Thanks for the clarification!
> ~petr
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: llvm-3.7 release and OpenMP

[Eric A. Borisch]

I was deferring to someone else the re-tool for cmake. ;) There also
seem to be many patchfiles that you've been maintaining, which I
haven't tried to grok at all...

Thanks,
  - Eric

On Tue, Oct 13, 2015 at 2:51 AM, Jeremy Huddleston Sequoia
 wrote:
> Hey Eric,
>
> Last month, you mentioned rewriting the llvm Portfile to use the cmake build 
> system.  I think now might be an opportune time to do that in llvm-3.8.  Have 
> you looked into that yet?
>
> --Jeremy
>
>> On Sep 3, 2015, at 10:10, Eric A. Borisch  wrote:
>>
>> I'll defer on rewriting the portfile for cmake.
>>
>> I guess I like having libomp separate for now as it's much quicker to
>> update (build) it stand-alone while it's still getting frequent
>> updates. Note that (apparently) llvm is also packaging the OpenMP
>> runtime separately for now -- see the pre-built binaries section of
>> http://llvm.org/releases/download.html
>>
>> I like your patch to teach clang where to look -- I'll add that when I
>> have a chance.
>>
>>
>> On Thu, Sep 3, 2015 at 11:21 AM, Jack Howarth
>>  wrote:
>>>   You really will want to rewrite the llvm37 Portfile to use a cmake
>>> build. The openmp 3.7 can be built in-tree using cmake (with the
>>> sources placed at projects/openmp. Also the default for -fopenmp is
>>> still left as -fopenmp=libgomp in 3.7.0 but this can be changed
>>> with...
>>>
>>> --- cfe-3.7.0.src/CMakeLists.txt.orig 2015-09-02 12:21:32.0 -0400
>>> +++ cfe-3.7.0.src/CMakeLists.txt 2015-09-02 12:21:51.0 -0400
>>> @@ -182,7 +182,7 @@
>>> set(DEFAULT_SYSROOT "" CACHE PATH
>>>   "Default  to all compiler invocations for --sysroot=." )
>>>
>>> -set(CLANG_DEFAULT_OPENMP_RUNTIME "libgomp" CACHE STRING
>>> +set(CLANG_DEFAULT_OPENMP_RUNTIME "libomp" CACHE STRING
>>>   "Default OpenMP runtime used by -fopenmp.")
>>>
>>> set(CLANG_VENDOR "" CACHE STRING
>>>
>>> In fink, we set the explicit location of the buried libomp.dylib with...
>>>
>>> --- cfe-3.7.0.src/lib/Driver/Tools.cpp.orig 2015-07-02
>>> 09:10:45.0 -0400
>>> +++ cfe-3.7.0.src/lib/Driver/Tools.cpp  2015-07-03 21:43:42.0 -0400
>>> @@ -6368,12 +6368,18 @@
>>>options::OPT_fno_openmp, false)) {
>>> switch (getOpenMPRuntime(getToolChain(), Args)) {
>>> case OMPRT_OMP:
>>> +  // Help clang find libomp.dylib
>>> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>>>   CmdArgs.push_back("-lomp");
>>>   break;
>>> case OMPRT_GOMP:
>>> +  // Help clang find libgomp.dylib
>>> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>>>   CmdArgs.push_back("-lgomp");
>>>   break;
>>> case OMPRT_IOMP5:
>>> +  // Help clang find libiomp5.dylib
>>> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>>>   CmdArgs.push_back("-liomp5");
>>>   break;
>>> case OMPRT_Unknown:
>>> @@ -8079,9 +8085,13 @@
>>> // Also link the particular OpenMP runtimes.
>>> switch (getOpenMPRuntime(ToolChain, Args)) {
>>> case OMPRT_OMP:
>>> + // Help clang find libomp.dylib
>>> + CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>>>   CmdArgs.push_back("-lomp");
>>>   break;
>>> case OMPRT_GOMP:
>>> +  // Help clang find libgomp.dylib
>>> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>>>   CmdArgs.push_back("-lgomp");
>>>
>>>   // FIXME: Exclude this for platforms with libgomp that don't 
>>> require
>>> @@ -8089,6 +8099,8 @@
>>>   CmdArgs.push_back("-lrt");
>>>   break;
>>> case OMPRT_IOMP5:
>>> + // Help clang find libiomp5.dylib
>>> + CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>>>   CmdArgs.push_back("-liomp5");
>>>   break;
>>> case OMPRT_Unknown:
>>>
>>> to produce -L/sw/opt/llvm-3.7/lib on the linkage. Lastly, to build the
>>> fat binary of libomp,
>>> you need to pass cmake the flag -DLIBOMP_OSX_ARCHITECTURES="x86_64;i

Re: OpenCoarrays Portfile ticket response?

[Eric A. Borisch]

Done.

On Wednesday, September 30, 2015, Damian Rouson <
dam...@sourceryinstitute.org> wrote:

>
>
> On Sep 30, 2015, at 5:50 PM, Brandon Allbery  > wrote:
>
> On Wed, Sep 30, 2015 at 8:43 PM, Damian Rouson <
> dam...@sourceryinstitute.org
> > wrote:
>
>> Wow.  I assume that means we’ll be in the next release.  Hooray!  Thanks
>> for the great news.  It’s time to open a bottle of champagne.
>
>
> Port updates are completely independent of MacPorts releases. If it's been
> committed to the tree, it should be available to "port sync" (or "port
> selfupdate" which also does a sync) about 30 minutes later.
> In other words, it should already be "live”.
>
>
> Got it. Thanks.  I just ran “port selfupdate” and then “sudo port install
> opencoarrays”.  It appears to have worked (I’m doing a happy dance over
> here) but it installed OpenCoarrays 1.0.0.  The current version is 1.0.2,
> which Alessandro Fanfarillo just created yesterday.  If it’s easy, would
> someone please update the port so that it installs the latest version from,
> which is available at the following URL?
>
>
> https://github.com/sourceryinstitute/opencoarrays/releases/download/1.0.2/opencoarrays-1.0.2.tar.gz
>
> Thanks.
>
> Damian
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: OpenCoarrays Portfile ticket response?

[Eric A. Borisch]

I've committed up a working (I believe) version.

On Friday, September 25, 2015, Damian Rouson 
wrote:

> * PING ***
>
>
> > On Sep 21, 2015, at 11:31 PM, Mojca Miklavec  > wrote:
> >
> > On Tue, Sep 22, 2015 at 7:27 AM, Damian Rouson wrote:
> >> Alessandro Fanfarillo submitted a Portfile for installing OpenCoarrays (
> www.opencoarrays.org) four months ago.   We hope the Portfile will be
> included in Macports soon.  We have responded to every concern raised and
> have been waiting two weeks for feedback on Alessandro’s latest response.
> We would greatly appreciate any advice on how to further improve the patch
> or how to attain final approval or even just how to get a response.  We
> released OpenCoarrays 1.0.0 on July 26 and have been hearing from users who
> would prefer to use a package installer such as Macports rather than to
> build from source.  We will be very appreciative of any assistance in this
> regard.
> >
> > Here's the link to the ticket (for others reading the mailing list and
> > not familiar with the ticket):
> >http://trac.macports.org/ticket/47806
> >
> > Mojca
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org 
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Python + libedit woes

[Eric A. Borisch]

On Wednesday, September 16, 2015, Joshua Root  wrote:

> On 2015-9-16 15:00 , Eric A. Borisch wrote:
> >> On Tuesday, September 15, 2015, Joshua Root  > wrote:
> >>>
> >>> On 2015-9-16 11:42 , Eric A. Borisch wrote:
> >>>> Any thoughts on this? Are most users not impacted, or have most not
> >>>> tried?
> >>>>
> >>>> https://trac.macports.org/ticket/48807
> >>>> <https://trac.macports.org/ticket/48807#comment:15>
> >>>>
> >>>> I'm clearly not the only one. :)
> >>>>
> >>>>   - Eric
> >>> [...]
> >>> I don't see the other more serious problems though. It may have
> >>> something to do with the declared terminal type?
> >>>
> >>> - Josh
> >>
> >>
> >> I also have one system where it is working, and another where it is
> not. If
> >> there was ever a need for an interrobang, this is it.
> >
> > Eureka.
> >
> > It appears the problem exists (on my two systems) whenever
> > py27-readline is not installed. Can others confirm this? Still not
> > quite sure what to think of that, but it's progress...
>
> I was just about to suggest installing py-readline as an alternative
> workaround. Its readline module overrides the built-in one.
>
> I don't have it installed though...
>
> - Josh
>

This successfully treats the symptom, but not the cause, then.

I'm up for further testing, but I'm running out of ideas... I was hoping
you had it installed -- its presence or absence makes my two machines at
least at the same.

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

Re: Python + libedit woes

[Eric A. Borisch]

> On Tuesday, September 15, 2015, Joshua Root  wrote:
>>
>> On 2015-9-16 11:42 , Eric A. Borisch wrote:
>> > Any thoughts on this? Are most users not impacted, or have most not
>> > tried?
>> >
>> > https://trac.macports.org/ticket/48807
>> > <https://trac.macports.org/ticket/48807#comment:15>
>> >
>> > I'm clearly not the only one. :)
>> >
>> >   - Eric
>> [...]
>> I don't see the other more serious problems though. It may have
>> something to do with the declared terminal type?
>>
>> - Josh
>
>
> I also have one system where it is working, and another where it is not. If
> there was ever a need for an interrobang, this is it.

Eureka.

It appears the problem exists (on my two systems) whenever
py27-readline is not installed. Can others confirm this? Still not
quite sure what to think of that, but it's progress...

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

Re: Python + libedit woes

[Eric A. Borisch]

On Tuesday, September 15, 2015, Joshua Root  wrote:

> On 2015-9-16 11:42 , Eric A. Borisch wrote:
> > Any thoughts on this? Are most users not impacted, or have most not
> tried?
> >
> > https://trac.macports.org/ticket/48807
> > <https://trac.macports.org/ticket/48807#comment:15>
> >
> > I'm clearly not the only one. :)
> >
> >   - Eric
> [...]
> I don't see the other more serious problems though. It may have
> something to do with the declared terminal type?
>
> - Josh
>

I also have one system where it is working, and another where it is not. If
there was ever a need for an interrobang, this is it.

I can't for the life of me figure out what is causing the difference. Same
OS (10.10.5) same Xcode (6.4 / 6E35b) ... I can run with "env -i
/opt/local/bin/python" (remove all envs) and the one still works while the
other is still broken. I even tried forcefully removing and reinstalling
rdepof:python27 (and python27) and re-installing (they all came down from
the buildbot) but it's still broken on one and working on the other...

Hopefully someone else has an idea. I'll have to revisit this another day.
As mentioned, I can fix it by disabling libedit in the Portfile (and let it
use / add dependency upon readline)...

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

Python + libedit woes

[Eric A. Borisch]

Any thoughts on this? Are most users not impacted, or have most not tried?

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


I'm clearly not the only one. :)

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

Re: llvm-3.7 release and OpenMP

[Eric A. Borisch]

I've created a ticket with some additional info.

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

Note that the subversion sync seems to not be running, but at least trac is up!

On Thu, Sep 3, 2015 at 1:12 PM, Jeremy Huddleston Sequoia
 wrote:
>
>> On Sep 3, 2015, at 10:51, Sean Farley  wrote:
>>
>>
>> Jeremy Huddleston Sequoia  writes:
>>
 On Sep 3, 2015, at 10:32, Sean Farley  wrote:


 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?
>>>
>>> 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?
>
> We don't have support for expressing that well in base, so I'm just very 
> conservative about bringing in any dependencies into the toolchain.  I'm 
> happy to add non-default variants to llvm and clang, but adding a new 
> dependency (especially one that can bring in both perl and python) is a bit 
> scary. =/
>
> Note that building a newer toolchain on Tiger is a bit of a challenge, and we 
> ended up using a +bootstrap variant in the apple-gcc42 port to help out with 
> that, but I'd prefer not to have to resort to such tactics for more recent OS 
> versions.  Specifically, I'd prefer to not have to tell people to install 
> cmake -gui, then clang-3.7, then cmake with their desired variants.
>
> I guess it would be ok to have such users use clang-3.4 to build cmake to 
> build clang-3.8, but that's also sub-optimal.  I'm certainly not against it, 
> though, since it is only an issue for older OS versions.
>
> If you (or someone else) wants to take a shot at this, please do so.  I think 
> at minimum, we'd need to:
> a) Update the llvm-3.8 port with a dependency on port:cmake and relevant 
> other changes
> b-1) Update the cmake port to check if clang-3.8 is installed and 
> blacklist it if it isn't
> b-2) Come up with a better way (in base) of ensuring that a compiler is 
> not used to satisfy its own dependencies if it is not already installed
>
> --Jeremy
>
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: llvm-3.7 release and OpenMP

[Eric A. Borisch]

I'll defer on rewriting the portfile for cmake.

I guess I like having libomp separate for now as it's much quicker to
update (build) it stand-alone while it's still getting frequent
updates. Note that (apparently) llvm is also packaging the OpenMP
runtime separately for now -- see the pre-built binaries section of
http://llvm.org/releases/download.html

I like your patch to teach clang where to look -- I'll add that when I
have a chance.


On Thu, Sep 3, 2015 at 11:21 AM, Jack Howarth
 wrote:
>You really will want to rewrite the llvm37 Portfile to use a cmake
> build. The openmp 3.7 can be built in-tree using cmake (with the
> sources placed at projects/openmp. Also the default for -fopenmp is
> still left as -fopenmp=libgomp in 3.7.0 but this can be changed
> with...
>
> --- cfe-3.7.0.src/CMakeLists.txt.orig 2015-09-02 12:21:32.0 -0400
> +++ cfe-3.7.0.src/CMakeLists.txt 2015-09-02 12:21:51.0 -0400
> @@ -182,7 +182,7 @@
>  set(DEFAULT_SYSROOT "" CACHE PATH
>"Default  to all compiler invocations for --sysroot=." )
>
> -set(CLANG_DEFAULT_OPENMP_RUNTIME "libgomp" CACHE STRING
> +set(CLANG_DEFAULT_OPENMP_RUNTIME "libomp" CACHE STRING
>"Default OpenMP runtime used by -fopenmp.")
>
>  set(CLANG_VENDOR "" CACHE STRING
>
> In fink, we set the explicit location of the buried libomp.dylib with...
>
> --- cfe-3.7.0.src/lib/Driver/Tools.cpp.orig 2015-07-02
> 09:10:45.0 -0400
> +++ cfe-3.7.0.src/lib/Driver/Tools.cpp  2015-07-03 21:43:42.0 -0400
> @@ -6368,12 +6368,18 @@
> options::OPT_fno_openmp, false)) {
>  switch (getOpenMPRuntime(getToolChain(), Args)) {
>  case OMPRT_OMP:
> +  // Help clang find libomp.dylib
> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>CmdArgs.push_back("-lomp");
>break;
>  case OMPRT_GOMP:
> +  // Help clang find libgomp.dylib
> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>CmdArgs.push_back("-lgomp");
>break;
>  case OMPRT_IOMP5:
> +  // Help clang find libiomp5.dylib
> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>CmdArgs.push_back("-liomp5");
>break;
>  case OMPRT_Unknown:
> @@ -8079,9 +8085,13 @@
>  // Also link the particular OpenMP runtimes.
>  switch (getOpenMPRuntime(ToolChain, Args)) {
>  case OMPRT_OMP:
> + // Help clang find libomp.dylib
> + CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>CmdArgs.push_back("-lomp");
>break;
>  case OMPRT_GOMP:
> +  // Help clang find libgomp.dylib
> +  CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>CmdArgs.push_back("-lgomp");
>
>// FIXME: Exclude this for platforms with libgomp that don't 
> require
> @@ -8089,6 +8099,8 @@
>CmdArgs.push_back("-lrt");
>break;
>  case OMPRT_IOMP5:
> + // Help clang find libiomp5.dylib
> + CmdArgs.push_back("-L@FINK_PREFIX@/opt/llvm-@BRV@/lib");
>CmdArgs.push_back("-liomp5");
>break;
>  case OMPRT_Unknown:
>
> to produce -L/sw/opt/llvm-3.7/lib on the linkage. Lastly, to build the
> fat binary of libomp,
> you need to pass cmake the flag -DLIBOMP_OSX_ARCHITECTURES="x86_64;i386".
>        Jack
> ps Note that the perl-based Makefile build is no longer functional in
> 3.7.0 and is in the process of being completely removed for the 3.8.0
> release.
>
> On Wed, Sep 2, 2015 at 9:59 PM, Jeremy Huddleston Sequoia
>  wrote:
>> Looks good to me.  Could you go ahead and push this to svn and also do 
>> similar changes to the llvm-3.8 port for your openmp variant?
>>
>> Thanks,
>> Jeremy
>>
>>> On Sep 2, 2015, at 15:34, Eric A. Borisch  wrote:
>>>
>>> Would have done a ticket, but with trac down
>>>
>>> Attached is a patch to update to the released llvm/clang-3.7 (this comments 
>>> out the svn fetch code, removes the default +assertions, and adds checksums)
>>>
>>> As OpenMP is one of the much discussed items that llvm-3.7 brings to the 
>>> table, I've added a +openmp variant to clang-3.7. This variants pulls in 
>>> port:libomp and sets up clang such that "-fopenmp" will use it by default. 
>>> This makes it much more likely for tools like autoconf to detect OpenMP 
>>> support. (Without the variant,

llvm-3.7 release and OpenMP

[Eric A. Borisch]

Would have done a ticket, but with trac down

Attached is a patch to update to the released llvm/clang-3.7 (this comments
out the svn fetch code, removes the default +assertions, and adds checksums)

As OpenMP is one of the much discussed items that llvm-3.7 brings to the
table, I've added a +openmp variant to clang-3.7. This variants pulls in
port:libomp and sets up clang such that "-fopenmp" will use it by default.
This makes it much more likely for tools like autoconf to detect OpenMP
support. (Without the variant, openmp support is still there, but it
requires -fopenmp=libomp, which isn't in the set of standard "can we do
OpenMP" flags.) If people are supportive of it, I would suggest making it a
default variant.

Note that -I/opt/local/include and -L/opt/local/lib (assuming standard
MacPorts install location) are required with -fopenmp for things to work
and not complain about missing omp.h or -lomp.

If there is someone more familiar with clang/llvm building (of the tools
themselves), it might be interesting to consider baking in those -I/-L
flags (or move the libomp include/lib install directories so they only have
omp.h and the libomp*.dylib files and using those) so -fopenmp would "just
work." (Without the extra -I and -L)... Let me know if there is interest
and I can rework the libomp port to support this.

Thanks,
  - Eric


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

trac is down

[Eric A. Borisch]

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

python + libedit issues

[Eric A. Borisch]

I've recently noticed (not sure when it changed) that when I enter and then
exit() the python (using python27 in particular) interpreter built against
libedit, the tty flags (as reported by stty -a) aren't getting reset when
exiting python -- most noticeably the echo flag is getting turned off. Yes,
yes, reset will fix it, but still.

If I build python27 against libreadline instead of libedit (by disabling
the libedit patch file) it works as expected.

All up-to-date as far as ports go... (r139788)

Any thoughts?

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

Re: [138813] trunk/dports/lang

[Eric A. Borisch]

On Mon, Jul 20, 2015 at 11:51 PM, Ryan Schmidt 
wrote:

> On Jul 20, 2015, at 6:20 PM, ebori...@macports.org wrote:
> >
> > Revision
> > 138813
> > Author
> > ebori...@macports.org
> > Date
> > 2015-07-20 16:20:10 -0700 (Mon, 20 Jul 2015)
> > Log Message
> >
> > libomp: New port; LLVM project's OpenMP runtime.
>
> > Added: trunk/dports/lang/libomp/Portfile (0 => 138813)
>
> > +namelibomp
> > +version 0.0
> > +revision242604
>
> > +svn.revision${revision}
>
> revision and svn.revision are not meant to be the same thing. revision is
> meant to be MacPorts-specific, independent of any upstream versioning. It
> is meant to be an integer that starts at 0 for every version of the port,
> and is incremented by 1 every time the port needs to be rebuilt but the
> upstream version has not changed.
>

I understand; but as there isn't currently a 'release' of the upstream
project (but I assume there will be at some point in the future) I'm just
tracking their SVN revisions; seemed like a logical thing to do until they
actually 'release.' I concede your point that this isn't the intended
design -- and my intention is to move away from it as soon as possible
(once a release exists.) I didn't want to start making (bogus) version
numbers only to have to revert to an epoch once upstream has a version
number. Not fixed / hoping upstream cuts a release and it goes away. ;)


> > +notes {
> > +Use with llvm-3.7/clang-3.7 (BOTH BUILT WITH THE '-assertions'
> VARIANT) via:
> > +  -I${prefix}/include -L${prefix}/lib -fopenmp=libomp
> > +}
>
> Variables are not interpolated within strings delimited by curly braces {}.
>

Yep. Patched up for lint without re-checking output. Fixed in r138841.


> The wording "built with the '-assertions' variant" is confusing. Did you
> mean: "with the assertions variant enabled" (in other words: +assertions)
> or "with the assertions variant disabled" (in other words: -assertions)?
>

Changed wording in r138841.


> If this port requires that the llvm-3.7/clang-3.7 ports are built with (or
> without) a particular variant, that should be enforced by using the
> require_active_variants proc in the active_variants 1.1 portgroup.
>

It does not require 3.7 at all to be *built* -- you can happily build it
with 3.3-3.7. To actively *use* it (in compilation; header + dylib) 3.7 is
required with '-assertions' -- at least in my testing. One can, however,
compile and link with 3.7 and libomp, and then uninstall 3.7 and still
*use* it (dylib) with the compiled program. So it's a bit of an odd case of
a library requiring a particular compiler -- but only when the library is
being used in the compilation & linking steps something else.

It's not depends_build or even depends_run, then, on 3.7. It would make the
most sense to have an +openmp (conflicts with +assertions) variant for
{llvm,clang}-3.7 which depends_run on libomp (which would then certainly
need to not depend on llvm-3.7) ... It's also a possibility that it will be
absorbed into llvm/clang builds at some point; I'm not crystal clear on
what llvm's (the project) plan is.

I made the Portfile so I could kick the tires of Clang's
(Intel-contributed) OpenMP implementation. I thought others might find it
useful for development/testing.

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

Re: [138675] trunk/dports/gnome/gdmap/Portfile

[Eric A. Borisch]

On Thu, Jul 16, 2015 at 1:44 PM, David Evans  wrote:

>  It may work but your port continues to require the perl version and
> intltools perl module dependencies to be explicitly specified and
> you don't get the benefits of any improvements in the current version of
> intltool.  The reason intltool-merge.in exists in your tarball is because
> it is the result of upstream running intltoolize with an outdated version
> of intltool (in autogen.sh). 
>
> If you fix the port as Ryan and I have suggested you can remove the
> reference to INTLTOOL_PERL and the dependency on p5.22-xml-parser and just
> replace
> them with a dependency on intltool.  Having done this you'll be completely
> immune to future changes in perl version because intltool will handle it
> for you and you'll have the additional benefit of any enhancements that
> have been made in intltool since upstream last updated intltool and ran
> intltoolize on their distribution.
>
> I really recommend you update your port to use our version of intltool.
>
> Dave
>


I suppose I was going with the "smallest touch" approach here. If you're
interested in preparing a patch, I'm happy to apply it (or indeed, please
feel free to go ahead and apply it) but I wasn't planning to spend the
extra ergs on a package that hasn't been updated upstream in 7 years and is
working fine -- as measured by successfully building working software on
all the buildbots in its current configuration.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [138675] trunk/dports/gnome/gdmap/Portfile

[Eric A. Borisch]

On Wed, Jul 15, 2015 at 8:54 PM, Ryan Schmidt 
wrote:

>
> > On Jul 15, 2015, at 4:53 PM, ebori...@macports.org wrote:
> > +configure.env-appendINTLTOOL_PERL=${prefix}/bin/perl5.22
>
> I guess this port uses intltool? So it should really have a build
> dependency on intltool, not p5.22-xml-parser.
>
> The problem is you don't know for what version of perl the user has
> installed intltool -- you don't know what variant of the intltool port the
> user has used. So instead of setting INTLTOOL_PERL, our preferred way of
> dealing with this issue is to autoreconf, which will regenerate the
> configure script using our patched copy of intltool.m4 installed by the
> intltool port, which no longer uses the INTLTOOL_PERL environment variable.
>

Passes in trace mode; looking at what happens, it has its own
intltool-merge.in that gets updated with INTLTOOL_PERL at configure time on
its shebang line. Buildbots also all completed without error.

So -- thanks for the catch, but I think we're ok on this one.

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

Re: macports with closed stdout

[Eric A. Borisch]

On Tue, May 5, 2015 at 1:23 PM, René J.V.  wrote:

> On Tuesday May 05 2015 19:58:44 Clemens Lang wrote:
> >That sounds like a perfect use case for screen or tmux.
>
> I might check out tmux, but screen gets in my way by trying to be too
> clever. The easiest would be to redirect all output (">&") to file and then
> use tail -f until I decide to disconnect. Or maybe it'll be enough to pipe
> all output to cat, or otherwise an application that redirects it output
> elsewhere if stdout/stderr are closed (I think I must have something like
> that lying around). More often than not all that interests me when
> reconnecting is if the port command completed successfully, because if not
> there are logs already.


Here's the (bash) you're looking for:

nohup [your command here] &> outputs.log < /dev/null &

You can happily tail -f outputs.log, or close the ssh session, or have the
connection drop, without "hanging up" on the command. Starts in the
background so you don't even have to do that. Obviously of no use for
interactive tools (stdin redirected from /dev/null.)

You could even create a bash function that wraps all this (nohup invocation
& log tail-ing) for you.

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

Re: Using xz by default for compression

[Eric A. Borisch]

FYI, lbzip2 is what you probably want, as it *can* decompress a 'stock'
archive faster. From the man page:

"The lbzip2 utility employs multiple threads and an input-bound splitter
even when decompressing .bz2 files created by standard bzip2."

That said, I'm in favor of having a list of valid suffixes that it can
search for archives against. Doesn't seem too outlandish. A simple script
could be provided for users who would like to recompress their local
archives.

As I posted earlier the benefits of xz (especally xz -9) for clang, llvm,
gcc, and boost (some of the biggest archives in my install) were fairly
significant: clang-3.5 (50% reduction) llvm-3.5 (49% reduction) and gcc48
and 49 (both ~50% the tbz2 size; only saved 20% with "xz" (no -9)).


 - Eric

On Sun, Jan 25, 2015 at 4:31 PM, Ryan Schmidt 
wrote:

>
> On Jan 25, 2015, at 3:27 PM, René J.V. Bertin wrote:
>
> > On Sunday January 25 2015 14:29:01 Daniel J. Luke wrote:
> >
> >> and how much more time does it take to compress/decompress?
> >
> > Decompression is not noticeably slower or faster, compression is. I'd
> say that shouldn't be an issue for the build bots, and every user can
> decide for him/herself whether it is locally.
> >
> > I'm not working on patches because the support is already there, and
> requires a point edit in macports.conf to be activated. I'm not familiar
> with installer development, otherwise I'd propose a patch presenting the
> user with the choice between xz (slower but more space-efficient
> compression) and bzip2.
>
> I'm in favor of making xz the default (there is no need to ask the user
> about this), the trick would be handling existing installations, which have
> bz2 archives, without problems, and figuring out how best to handle the
> pre-built binary packages situation (either write a script to recompress
> everything as xz, or find a way to have MacPorts check for both).
>
> One thing to consider is that we somewhat recently made MacPorts base
> capable of using pbzip2 if it is installed, a parallel bzip2 implementation
> which uses more than 1 processor core for compression of bz2 files, and
> uses more than 1 processor core for decompression of bz2 files created with
> pbzip2. I worked with the developer of pbzip2 recently to improve its build
> system and to report an intermittent crashing bug, which got fixed, and
> this now seems to work stably on my system, where I don't use the binaries
> from the packages server. However since our buildbot builders do not have
> pbzip2 active, the archives created by the buildbot builders are not able
> to be decompressed more quickly by pbzip2 than by bzip2, so it is of
> limited value. I had considered bundling a copy of pbzip2 with MacPorts to
> solve this. There seem to be some parallel xz implementations; we should
> see if any of them is stable enough, and using a suitably compatible
> license, to consider being included in MacPorts.
>
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [130886] trunk/dports/graphics

[Eric A. Borisch]

On Sat, Jan 3, 2015 at 10:47 PM, Ryan Schmidt 
wrote:

>
> > On Jan 3, 2015, at 12:44 PM, ebori...@macports.org wrote:
> >
> > Revision
> > 130886
> > Author
> > ebori...@macports.org
> > Date
> > 2015-01-03 10:44:45 -0800 (Sat, 03 Jan 2015)
> > Log Message
> >
> > libpgf: New port for Digikam support.
>
> > Added: trunk/dports/graphics/libpgf/Portfile (0 => 130886)
>
> > +depends_build   port:dos2unix \
> > +port:doxygen \
> > +port:graphviz \
>
> Dependencies on ports that have -devel counterparts, like graphviz, should
> be written such that the -devel counterpart could satisfy it. In this case,
> that means it should be written:
>
> path:bin/dot:graphviz
>
>
> > +post-extract {
> > +reinplace "s/libtoolize/glibtoolize/" autogen.sh
>
> reinplace is typically done in post-patch, and unless there are
> extenuating circumstances, such as the need to replace a variable, or an
> inordinately high number of replacements, it should actually be a
> patchfile, not a reinplace.
>
> > +system -W ${worksrcpath} "dos2unix configure.ac"
>
> In the post-extract block, the build dependencies have not necessarily
> been installed yet, so this could fail if someone runs "sudo port extract
> libpgf". You could make dos2unix an extract dependency instead of a build
> dependency, but it would be better to do this with a reinplace and no
> dependency. Here is how I do it when I encounter this need:
>
> post-extract {
> # DOS to UNIX line endings.
> reinplace "s|\r||g" ${worksrcpath}/configure.ac
> }
>
>
> > +post-destroot {
> > +delete ${destroot}/${prefix}/share/man
>
> There should not be a "/" before "${prefix}" because the value of
> ${prefix} already begins with a slash.
>
> > +copy ${worksrcpath}/COPYING \
> > +${destroot}/${prefix}/share/doc/${name}-${version}/
>
> Same here. In addition, we would prefer to use a non-versioned directory
> for documentation (i.e. ${name}, not ${name}-${version}).
>

Addressed most comments in r130798; kept reinplace rather than adding a
more brittle patch file for autogen.sh fix.

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

Re: Adding MPI back to Boost

[Eric A. Borisch]

On Sunday, December 14, 2014, Ryan Schmidt  wrote:

>
> 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).
>
> 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?
>
>
> > 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?
>

Because people using mpich are typically interested in how their code
compiles under multiple different compilers, because they are
often targeting systems other than their mac with the software.

And the different compiler wrapping versions are not variants of mpich, but
are sub-ports that can be installed side by side and explicitly depended
upon.

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

Re: [120646] trunk/dports/python/py-spyder-devel

[Eric A. Borisch]

On Wed, Jun 4, 2014 at 9:30 PM, Ryan Schmidt 
wrote:

>
> On Jun 4, 2014, at 11:40 AM, ebori...@macports.org wrote:
> > +variant noAntiAlias description {Use non-anti-aliased fonts in
> editor.} {
> > +patchfiles-append   no_AA.diff
> > +}
>
> Note that variant names are treated case-sensitively, unlike port names. I
> think this is a bug, which I filed as:
>
> https://trac.macports.org/ticket/25970
>
> But it is not fixed yet. And this is one of the reasons we usually use
> lowercase letters for variant names, often with underscores separating
> words, instead of using camelCase names.
>

Addressed in r120677.

Thanks for the heads-up,
   - Eric
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Any thoughts on changing configure...

[Eric A. Borisch]

On Thursday, April 24, 2014, Jeremy Lavergne 
wrote:

> I remember “-dc” being used for mp_tarball_extract_cmd in place of “-d < “
> for compat:
> https://trac.macports.org/changeset/118736/trunk/base/aclocal.m4
>
> That should not be forgotten in that ticket’s patch.
>
> On Apr 24, 2014, at 13:11, Clemens Lang >
> wrote:
>
> > Hi,
> >
> >> See this ticket : https://trac.macports.org/ticket/43204#comment:12
> >> Anyone? I'm ready to commit this up if there are no concerns.
> >
> > I have no particularly strong feelings either way. But since this might
> > be a regression in 2.3, you should probably merge the change back into
> > the release_2_3 branch as well, if you commit it.
> >
> > --
> > Clemens Lang
> > ___
> > macports-dev mailing list
> > macports-dev@lists.macosforge.org 
> > https://lists.macosforge.org/mailman/listinfo/macports-dev
>

That change ( -dc vs. -d <) didn't really fix things, it was more of a
"fails/warns gracefully but still runs" ...

This is discussed in the comments to ticket 43204 :
https://trac.macports.org/ticket/43204#comment:9

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

Re: Any thoughts on changing configure...

[Eric A. Borisch]

On Wed, Apr 23, 2014 at 6:23 PM, Eric A. Borisch wrote:

> See this ticket : https://trac.macports.org/ticket/43204#comment:12
>
> Specifically, this would change the tool settings from environment
> variables (TOOL=/usr/bin/tool ./configure) to arguments (./configure
> --with-tool=/usr/bin/tool)
>

Anyone? I'm ready to commit this up if there are no concerns.

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

Any thoughts on changing configure...

[Eric A. Borisch]

See this ticket : https://trac.macports.org/ticket/43204#comment:12

Specifically, this would change the tool settings from environment
variables (TOOL=/usr/bin/tool ./configure) to arguments (./configure
--with-tool=/usr/bin/tool)

This also fixes an issue where bzip2 (and lbzip2) use BZIP2 as an argument.

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

Buildbots rejecting certificate of svn.macports.org

[Eric A. Borisch]

Perhaps I missed it being mentioned on the list, but the Lion, Mountain
Lion, and Mavericks build bots are rejecting server certificates and
failing.

You can see them all start to fail in this view:
https://build.macports.org/waterfall?last_time=1397200915

First failing one: (Picked Mavericks)
https://build.macports.org/builders/buildports-mavericks-x86_64/builds/2642

Error:
  svn: OPTIONS of 'https://svn.macports.org/repository/macports/contrib/mpab':
Server certificate verification failed: issuer is not trusted (
https://svn.macports.org)

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

Re: Move part of macports infrastructure to GitHub

[Eric A. Borisch]

A related item that bubbled on the mailing list for a while would be to get
the http://trac.edgewall.org/wiki/CommitTicketUpdater configured for MP.
This would let us refer to and take actions on ("ref #1234" or "closes
#5432") tickets in commit messages, which ties a nice bow around commits
tied to a ticket. It's not at github pull request / comments / sugar-ness
level, but it's a nice feature if we could enable it.

Any chance of getting that done?

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

Re: MacPorts automake and python

[Eric A. Borisch]

On Thursday, March 20, 2014, David Evans  wrote:

> On 3/20/14 3:01 PM, Adam Mercer wrote:
> > On Thu, Mar 20, 2014 at 4:51 PM, Eric A. Borisch 
> > >
> wrote:
> >
> >> What was broken that needed fixing (by the original change)? Is there a
> >> particular port that needed the change? Is there another way to fix it
> >> without modifying automake?
> >>
> The answer is yes, any port that uses AM_PYTHON_PATH to discover the
> Python install
> prefix will fail on MacPorts (or any other installation of Python into a
> non-standard path)
> without intervention and there are quite a few.
>
> In the past this has been handled typically by applying a similar patch
> to the configure file
> provided with each project being ported.  This works and the patch here
> does not interfere
> with this because the configure file is not being regenerated.
>
> However, increasingly, ports need to use autoreconf or even autogen.sh
> to regenerate configuration
> files prior to build for some other reason (intltool perl issues for
> instance).  This again effects a
> large number of ports.  In this case, patching of the configure file is
> impractical and the required
> patch to configure.ac amounts to replacing AM_PYTHON_PATH with custom
> code that is often
> package specific.  This change to automake makes that unnecessary.
>
> Have to head home now but will follow up later this evening.  In the
> meantime, please don't revert
> this change on your own as there are many ports that WILL be broken.
> If, we, as a group decide
> that that is the preferred approach, I will make the change after the
> effected ports have been re-written.
>
> Thanks
>
> PS What ever happened to the doctrine that if you mix code in other
> installation prefixes with MacPorts
> ports, all bets are off and results are not guaranteed?
>

Dave,

Any updates on the ports that were fixed / simplified by this patch? I've
heard it said, and seen multiple requests for "which ones?" and "where are
the tickets?"

Can you please shed some light on this?

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

MacPorts automake and python

[Eric A. Borisch]

On Thursday, March 20, 2014, Sean Farley
>
wrote:

>
> Adam Mercer  writes:
>
> > On Thu, Mar 20, 2014 at 4:01 PM, Sean Farley  wrote:
> >
> >> Before: my project installed into /path/foo/a
> >> After:  my project installed into /path/foo/b
> >
> > Got you, if I configured using: ./configure --prefix=$HOME/opt
> >
> > the the Python modules would be installed in:
> > $HOME/opt/lib/python2.7/site-packages
> >
> > After the change it wants to install them in:
> >
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/
>
> Ok, yeah, that's what I was wondering. Hacking autotools to change this
> behavior is ludicrous. This change most certainly needs to be
> reverted.
>
> Honestly, I don't know why we're messing with automake at all. If this
> is just to make installing ports (from the perspective of the portfile
> author) easier then why can't this type of change go in the python
> portgroup?
>

That's what I was trying to get at - my guess it is not py-* ports that
benefitted from the change, but ports that include some pythonic parts.
Fixing one or two problem ports would be a better fix than patching the
build environment (automake).

devans@macports, what was the reason for the change? I don't see a ticket
referenced?

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

Re: MacPorts automake and python

[Eric A. Borisch]

Brining back to dev list; seems like the right place.

On Thu, Mar 20, 2014 at 4:01 PM, Sean Farley  wrote:

>
> Adam Mercer  writes:
>
> > On Thu, Mar 20, 2014 at 2:55 PM, Sean Farley  wrote:
> >
> >> I tend to agree with you but need help seeing how this worked
> >> before. What path did automake pick up before this change?
> >
> > If you look at the patch you can see the original paths:
> >
> > <
> http://trac.macports.org/browser/trunk/dports/devel/automake/files/patch-m4-python.m4.diff
> >
> >
> > The original paths are:
> >
> > AC_SUBST([PYTHON_PREFIX], ['${prefix}'])
> > AC_SUBST([PYTHON_EXEC_PREFIX], ['${exec_prefix}'])
> >
> > Just to clarify this isn't the MacPorts prefix but the prefix for the
> > running configure process.
>
> Right, sorry, I meant more along the lines of:
>
> Before: my project installed into /path/foo/a
> After:  my project installed into /path/foo/b


I think the issue here is that automake is getting patched to *only*
support MacPorts-managed builds, but really automake should still be
available for use to build non-MP software.

What was broken that needed fixing (by the original change)? Is there a
particular port that needed the change? Is there another way to fix it
without modifying automake?

Assuming the change is/was needed (and the best solution), perhaps setting
an environment variable during MP managed builds could be used here to
switch the behavior? Something along the lines of:

AC_SUBST([PYTHON_PREFIX], [`[ ${__MP_BUILD__} ] && $PYTHON -c "import sys;
sys.stdout.write(sys.prefix);" || echo -n ${prefix}`])

where __MP_BUILD__=1 during a managed build, and undefined otherwise?

This way when a user outside of MacPorts is installing a
python-using-software (built against MP-provided python) and they have set
$prefix via configure, it doesn't get crowbarred into /opt/local/ (or
wherever MP is installed.) (Granted, as the .m4 file notes, they will need
to set PYTHONPATH or tell python about it in some manner to use it.)

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

Buildbot fails to upload packages...

[Eric A. Borisch]

Just making sure this hasn't dropped off the radar.

Just picking the latest build:
https://build.macports.org/builders/buildports-lion-x86_64/builds/18908/steps/deploy%20archives/logs/stdio

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

Re: [116291] trunk/dports/_resources/port1.0/group/debug-1.0.tcl

[Eric A. Borisch]

On Fri, Jan 24, 2014 at 10:51 AM, Sean Farley  wrote:
>
> eg...@gwmail.gwu.edu writes:
>
>> Just so it can remove it with the `+debug` variant that it adds, it looks
>> like...
>
> Eric is correct. In hindsight, I am now doubting adding
> -mtune=native. Maybe just the -O3 -Ofast etc.?
>
>> On Thu, Jan 23, 2014 at 10:32 PM, Joshua Root  wrote:
>>
>>> On 2014-1-24 09:50 , Sean Farley wrote:
>>> >
>>> > lar...@macports.org writes:
>>> >
>>> >> (a) There's already a configure.mtune option. You should use that
>>> ("configure.mtune native") instead of appending to all the flags options.
>>> >
>>> > Oh, awesome, thanks for the tip.
>>> >
>>> >> (b) Don't you have to disable binary archives if you set
>>> "-mtune=native"?
>>> >
>>> > Probably so. Luckily, there are no ports using this port group so this
>>> > kind of feedback is appreciated.
>>>
>>> (c) Why is a portgroup called "debug" adding -mtune=native anyway?
>>>
>>> - Josh
>>> ___
>>> macports-dev mailing list
>>> macports-dev@lists.macosforge.org
>>> https://lists.macosforge.org/mailman/listinfo/macports-dev
>>>
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

-mtune=native also breaks gcc prior to 4.4(? Prior to some version. ;)
... and similar (llvm-gcc-4.2)

I would take it out, not to mention that anything built with
-mtune=native may not be the best choice for binary distribution.
(Although it should be OK; -march=native would be a definite no-no.)

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

Re: What should be done about tickets that seem to be forgotten?

[Eric A. Borisch]

On Mon, Dec 23, 2013 at 11:38 AM, Eric Gallager  wrote:
> Is there a trac plugin or setting that we could use to have our trac
> automatically close tickets like that, too?

Sure is: http://trac.edgewall.org/wiki/CommitTicketUpdater.

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

Re: What should be done about tickets that seem to be forgotten?

[Eric A. Borisch]

I failed to manually close the ticket. (I'm used to a Trac that scans
commit messages for closes #)

Sorry for the confusion. The port is there now -- give it a shot.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Archive vs. local build selection (10.8.5, XCode 5.0.2)

[Eric A. Borisch]

On Tue, Dec 17, 2013 at 4:49 PM, Ryan Schmidt wrote:

>
> On Dec 17, 2013, at 08:28, Eric A. Borisch wrote:
>
> > This ticket https://trac.macports.org/ticket/41836 describes an issue
> where (apparently, I don't have a matching system to test) 10.8.5 and XCode
> 5.0.2 are installed.
> >
> > The user installed (I'm guessing from buildbot archive) mpich-default,
> which wraps /usr/bin/llvm-gcc-4.2. In the setup mentioned, this doesn't
> exist. (Which is why I'm saying it came from the archive rather than a
> local build -- mpich wraps the compiler it was built with.)
> >
> > Any thoughts on how to fix this? What version of Xcode (esp. clang) is
> on the 10.8 buildbot?
> > llvm-gcc-4.2 gets used if clang is blacklisted:
> >
> > < from the Portfile>
> > # Linker for Apple clang version 421.11.66 segfaults
> > # See https://trac.macports.org/ticket/36654#comment:9
> > compiler.blacklist-append   {clang >= 421.11.66 < 425.0.24}
> > 
>
> Evidently the 10.8 buildbot has a version of Xcode that has a version of
> clang in that build number range.
>
> I guess the user should rebuild mpich-default from source (the “-s”) flag,
> or not use mpich-default. Ports that hardcode compilers discovered at build
> time are considered a bug, so you’re on your own since that bug appears to
> be your intention with this port.
>

Well, MPICH provides compiler wrappers (in addition to libraries.) Kinda
hard to be a compiler wrapper without naming the compiler. :)

I had the user rebuild from source already, and that proved to fix the
issue -- we have nailed down what is happening.

Perhaps it would be best if I mark the port as not binary distributable. Or
I could as a post-activate check that would alert the user if the embedded
compiler doesn't exist on the system. Decisions, decisions.

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

Archive vs. local build selection (10.8.5, XCode 5.0.2)

[Eric A. Borisch]

This ticket https://trac.macports.org/ticket/41836 describes an issue where
(apparently, I don't have a matching system to test) 10.8.5 and XCode 5.0.2
are installed.

The user installed (I'm guessing from buildbot archive) mpich-default,
which wraps /usr/bin/llvm-gcc-4.2. In the setup mentioned, this doesn't
exist. (Which is why I'm saying it came from the archive rather than a
local build -- mpich wraps the compiler it was built with.)

Any thoughts on how to fix this? What version of Xcode (esp. clang) is on
the 10.8 buildbot?
llvm-gcc-4.2 gets used if clang is blacklisted:

< from the Portfile>
# Linker for Apple clang version 421.11.66 segfaults
# See https://trac.macports.org/ticket/36654#comment:9
compiler.blacklist-append   {clang >= 421.11.66 < 425.0.24}


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

Re: [114668] trunk/dports/security/KeePassX/Portfile

[Eric A. Borisch]

On Fri, Dec 13, 2013 at 12:33 PM, Ryan Schmidt wrote:

>
> On Dec 13, 2013, at 11:25, ebori...@macports.org wrote:
>
> > +platform darwin {
> > +if {${os.major} < 13} {
> > +# Build fails with clang: unsupported
> -stack-protector-buffer-size=4
> > +# (even though clang -help lists option)
> > +compiler.blacklist  clang
>
> This is probably wrong; you should probably base the blacklisting of clang
> on its version, not on the OS version. Use the compiler_blacklist_versions
> portgroup. Also list any affected MacPorts clang ports.
>

Agreed, I was just trying to push some ports out of c++ lib limbo land. :)

Taking a look closer, I really want - in order to be as close to what the
original option was doing, while still moving to libc++ - a clang that
supports -fsanitize=address, which the OSX version doesn't:

http://www.opensource.apple.com/source/clang/clang-425.0.24/src/tools/clang/test/Driver/darwin-asan-nofortify.c

I was thinking of just setting the compiler to be macports-clang-3.3 (which
does support it) and then adding the cxx_stdlib switch you also suggested
for CXX11 support on/off. Does that sound reasonable?

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

Re: [111271] trunk/dports/science/ocaml-mpi/Portfile

[Eric A. Borisch]

On Wed, Sep 18, 2013 at 10:14 PM, Ryan Schmidt wrote:

>
> On Sep 18, 2013, at 21:45, Eric A. Borisch wrote:
>
> >> > -depends_lib port:ocaml port:ocaml-findlib
> path:bin/mpicc:mpich
> >> > +depends_lib port:ocaml port:ocaml-findlib
> path:bin/mpicc-mp:mpich-default
> >
> >> > +if {[file exists ${prefix}/lib/mpich-mp]} then {
> >> > +   build.env   MPIINCDIR=${prefix}/include
> MPILIBDIR=${prefix}/lib/mpich-mp
> >> > +} else {
> >> > +   build.env   MPIINCDIR=${prefix}/include
> MPILIBDIR=${prefix}/lib/mpich-devel-mp
> >> > +}
> >>
> >> This is concerning, because it means the port builds differently
> depending on what ports the user already has installed. This won't work
> right if the user gets a pre-compiled package from the buildbot and is
> generally a bad idea.
> >
> > True, but the only people it will be any issue for are those that have
> intentionally installed mpich-devel-default, and for those, rev-upgrade
> will rebuild it locally (the libs are in different locations; no chance of
> something subtle slipping by.) The two potential satisfying ports conflict
> with each other, so only one can possibly be installed.
> >
> > These are people who have chosen to go off the beaten path intentionally.
> >
> > Your thoughts?
> >   - Eric
>
> At the time that this code is evaluated:
>
> if {[file exists ${prefix}/lib/mpich-mp]} then {
> build.env   MPIINCDIR=${prefix}/include
> MPILIBDIR=${prefix}/lib/mpich-mp
> } else {
> build.env   MPIINCDIR=${prefix}/include
> MPILIBDIR=${prefix}/lib/mpich-devel-mp
> }
>
> the dependencies haven't necessarily been installed yet. If they haven't,
> then the code will set MPILIBDIR=${prefix}/lib/mpich-devel-mp, but the
> dependency path:bin/mpicc-mp:mpich-default will install mpich-default not
> mpich-devel-default.
>
> This will affect any users who haven't already installed mpich-default by
> the time they ask to install ocaml-mpi. That includes new users and the
> buildbots, and therefore also any users who get the precompiled binaries.
>
> I tried it just now and the build succeeded, but I don't know what effect
> the incorrect MPILIBDIR had.
>
> You could fix this by changing the if statement. Check for a file from
> mpich-devel-default (not mpich-default). If it's not there, assume either
> mpich-default is installed, or will automatically be.
>
>
Got it -- tripped up by when things are evaluated. Thanks for the subtle
catch!

Fixed in r111343.

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

Re: [111271] trunk/dports/science/ocaml-mpi/Portfile

[Eric A. Borisch]

On Wednesday, September 18, 2013, Ryan Schmidt wrote:

> On Sep 17, 2013, at 22:06, ebori...@macports.org  wrote:
>
> > Revision: 111271
> >  https://trac.macports.org/changeset/111271
> > Author:   ebori...@macports.org 
> > Date: 2013-09-17 20:06:42 -0700 (Tue, 17 Sep 2013)
> > Log Message:
> > ---
> > ocaml-mpi: Update to use new mpich-default
> >
> > Modified Paths:
> > --
> >trunk/dports/science/ocaml-mpi/Portfile
> >
> > Modified: trunk/dports/science/ocaml-mpi/Portfile
> > ===
> > --- trunk/dports/science/ocaml-mpi/Portfile   2013-09-18 02:18:42 UTC
> (rev 111270)
> > +++ trunk/dports/science/ocaml-mpi/Portfile   2013-09-18 03:06:42 UTC
> (rev 111271)
> > @@ -4,7 +4,7 @@
> >
> > nameocaml-mpi
> > version 1.01
> > -revision4
> > +revision5
> > categories  science devel ml
> > maintainers mww
> > license LGPL-2
> > @@ -21,7 +21,7 @@
> > sha14f836f02f7e8852ba72d4293aea43cf7a3438b0f \
> > rmd160  c0a08090073c54e130cd2712c7d1cfbeb8d17793
> >
> > -depends_lib port:ocaml port:ocaml-findlib path:bin/mpicc:mpich
> > +depends_lib port:ocaml port:ocaml-findlib
> path:bin/mpicc-mp:mpich-default
> >
> > patchfiles  Makefile.diff
> >
> > @@ -32,7 +32,12 @@
> > use_configure   no
> > use_parallel_build  no
> >
> > -build.env   MPIINCDIR=${prefix}/include/mpich2
> MPILIBDIR=${prefix}/lib
> > +if {[file exists ${prefix}/lib/mpich-mp]} then {
> > +   build.env   MPIINCDIR=${prefix}/include
> MPILIBDIR=${prefix}/lib/mpich-mp
> > +} else {
> > +   build.env   MPIINCDIR=${prefix}/include
> MPILIBDIR=${prefix}/lib/mpich-devel-mp
> > +}
>
> This is concerning, because it means the port builds differently depending
> on what ports the user already has installed. This won't work right if the
> user gets a pre-compiled package from the buildbot and is generally a bad
> idea.
>

True, but the only people it will be any issue for are those that have
intentionally installed mpich-devel-default, and for those, rev-upgrade
will rebuild it locally (the libs are in different locations; no chance of
something subtle slipping by.) The two potential satisfying ports conflict
with each other, so only one can possibly be installed.

These are people who have chosen to go off the beaten path intentionally.

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

Of variants and revbumping.

[Eric A. Borisch]

I'm preparing to commit the changes to mpich that have been discussed on
the mailing list [1] and a ticket [2].

I will revbump port that depend on mpich by default so new distributable
archives can be built.

But for other modified ports, I have a quick question of preferences:
should I revbump ports that optionally (and not by default) depend on
mpich, or just let rev-upgrade catch those?

For users installed without the specific (typically +mpich or +mpi) variant
selected, the revbump would be a gratuitous rebuild, even though the
Portfile has changed in the variant sections to select the newly supplied
bin/libs from mpich[-devel]-default...

I can go either way -- I'll be modifying the Portfiles already. Is
"rev-upgrade will catch it" an acceptable answer?

Thanks,
 Eric

[1]
https://lists.macosforge.org/pipermail/macports-dev/2013-August/024170.html
[2] https://trac.macports.org/ticket/40375
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Of variants and revbumping.

[Eric A. Borisch]

On Mon, Sep 16, 2013 at 6:55 PM, Jeremy Huddleston Sequoia <
jerem...@macports.org> wrote:

>
> On Sep 16, 2013, at 16:49, Ryan Schmidt  wrote:
>
> >
> > On Sep 16, 2013, at 18:41, Jeremy Huddleston Sequoia wrote:
> >
> >> On Sep 16, 2013, at 15:46, Ryan Schmidt wrote:
> >>
> >>> On Sep 16, 2013, at 12:54, Eric A. Borisch wrote:
> >>>
> >>>> I'm preparing to commit the changes to mpich that have been discussed
> on the mailing list [1] and a ticket [2].
> >>>>
> >>>> I will revbump port that depend on mpich by default so new
> distributable archives can be built.
> >>>>
> >>>> But for other modified ports, I have a quick question of preferences:
> should I revbump ports that optionally (and not by default) depend on
> mpich, or just let rev-upgrade catch those?
> >>>>
> >>>> For users installed without the specific (typically +mpich or +mpi)
> variant selected, the revbump would be a gratuitous rebuild, even though
> the Portfile has changed in the variant sections to select the newly
> supplied bin/libs from mpich[-devel]-default...
> >>>>
> >>>> I can go either way -- I'll be modifying the Portfiles already. Is
> "rev-upgrade will catch it" an acceptable answer?
> >>>
> >>> That's the way I went when I updated gd2 to 2.1.0 recently. I think
> it's reasonable. What do others think?
> >>
> >> I don't think "rev-upgrade will catch it" is reasonable ... if
> installed files change in a meaningful way (such as location of linked
> dependencies), it needs a revbump.  Otherwise the binary packages we ship
> to customers won't be right.
> >
> > We are only talking about non-default variants. We don't ship binary
> packages using non-default variants. When default variants are affected,
> absolutely the revision should be increased to fix the binary packages.
>
> True, but someone *could* setup a repository with additional packages for
> non-default variants.
>
> My $0.02 is that I'd do the bump to be on the safe side.
>

If there is a use case (your 'someone could') that is negatively impacted
by not rev-bumping, I'm fine with it.

As I stated from the get-go, anything with a default dependency would
certainly be rev-bumped, but that's two or three of the twenty or so
packages that will be (unnecessarily, for most) rebuilt if I bump
everything. Of course, for any of those that are distributable, the compile
time will be farmed out to the buildbots...

I'll go ahead and bump everything when I get around to committing this
unless there's a uproar. :)

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

Possible mpich changes / resolution [Was re: Fortran recipe]

[Eric A. Borisch]

> I think it comes down to "I'm installing X (from MP) so I need this
> thing I've never met called MPICH that is required" or "I'm installing
> MPICH so I can write an MPI program, and I want to use *cc because of
> Z." Perhaps the best way to serve both ends is to create sub-ports as
> I mentioned above.

I've put (in a separate branch [1]) changes in place to provide
mpich-default (which creates mpicc-mp, mpicxx-mp, and mpifNN-mp by
default) as well as a number of mpich-COMPILER ports to be installed
side-by-side, along with a mpich_select port to facilitate changing
what mpicc/mpicxx/mpifNN point to for the user. I would (assuming
people are OK with this approach) have ports that depend on mpich
(which itself is now a stub and depends on mpich-default) now use
MPICC=${prefix}/bin/mpicc-mp (or whatever is required for the
particular package) and depend on path:bin/mpicc-mp:mpich (might be
satisfied by mpich-devel-default) to insulate packages from the
current 'port select --set mpich mpich-XXX' setting. All of the
flavors use mpich-default's headers (and therefore depend on
mpich-default).

The mpich-default package builds just like (or at least is intended
to) the current mpich (system default CC/CXX; variant requested
fortran (gcc48 by default)) using the "fortran recipe." The other
mpich-COMPILER flavors are intended for users where mpich is the
endpoint of MP support, and the tools created are being used for
"external" work. These wrap the requested CC/CXX in addition to
fortran (depending on variant; using the recipe for non-gccNN ports,
and the matching gfortan for the gccNN ones.)

There is also a set of conflicting mpich-devel packages set up in the same way.

Let me know what you think / if that seems reasonable and I'll make
the changes (in the branch) to ports depending on mpich and then merge
everything at once back into trunk.

Thanks,
 Eric
[1] http://trac.macports.org/changeset/110432
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Fortran recipe

[Eric A. Borisch]

On Wed, Aug 28, 2013 at 9:14 PM, Jeremy Huddleston Sequoia
 wrote:
>
> On Aug 28, 2013, at 18:06, Eric A. Borisch  wrote:
>> Because when _I_ install mpich +gcc47 and then call mpicc/mpicxx, I want to 
>> get gcc47 (c/c++) behind it. Perhaps I'm doing a hybrid model with OpenMP 
>> and can't use clang.
>
> Hmm... but isn't mpicc and mpicxx a wrapper?  Why do you need to make that 
> decision at build time?  Can't you let the user decide what C++ compiler 
> mpicxx uses at runtime?

Yes, it is a wrapper, but there are also the compiled libraries that
actually supply the MPI functions. Yes, you can pass '-cc=XX'  or use
MPICH_CC, but the first reaction if something doesn't work right is to
"try reconfiguring MPICH with the new compiler and installing MPICH in
a separate location." (mpicc manpage) I take from that (and
experience) that the best practice is to avoid this (crow-baring of
compiler after the fact) approach unless it is unavoidable.

I've been considering splitting out the different variants into
(non-conflicting) subports; this would allow users to have different
mpicc/compiler combinations installed at the same time. Perhaps this
is also a solution to the problem here; the default / depended upon
(mpich) based on /gfortran and the separate versions
(mpich_gcc44, mpich_clang33) being installed for outside-of-MP-scope
development for those who want them.

> I think the only time it would use llvm-gcc is on Xcode 4.0 and 4.1, which 
> aren't supported configurations.  I think we officially just support 3.2.6 on 
> SL, 4.2 on SL, and 4.6 on Lion/ML.  That means that the compilers we really 
> care about are gcc-4.2 and clang.

>From the guide: llvm-gcc-4.2 with Xcode 4.0 and 4.1 on Mac OS X 10.6
and 10.7. Perhaps that doesn't mean supported, but it certainly is
described / exists. (And happens to be what I'm sitting at.)

>> If I'm the only one that wants it this way anymore, then I can always keep 
>> my own private version for myself, I suppose.
>
> No, if you want this, chances are someone else wants it as well... but I 
> would like to understand exactly *why* you want it.  Are there performance 
> bugs with clang or the code it generates that I should be aware of?  Are 
> there compatibility concerns?

Did clang grow OpenMP support yet? There's no OpenMP in mpich, but can
certainly show up in programs compiled with mpich. I also like to be
able to build/test with the different compiler versions we also have
installed and various linux systems. Granted, there are other
differences, but OSX+gcc44 is "closer to" linux+gcc44 than OSX+clang
is.

I think it comes down to "I'm installing X (from MP) so I need this
thing I've never met called MPICH that is required" or "I'm installing
MPICH so I can write an MPI program, and I want to use *cc because of
Z." Perhaps the best way to serve both ends is to create sub-ports as
I mentioned above.

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

Re: Fortran recipe

[Eric A. Borisch]

[Re-sent to list from correct address]

On Wed, Aug 28, 2013 at 4:50 PM, Jeremy Huddleston Sequoia
 wrote:
>
> On Aug 28, 2013, at 12:00, Eric A. Borisch  wrote:
>
>> Sorry for the blank email. Gmail interface whoops.
>>
>> So I come back from vacation and find the mpich port (I'm maintainer;
>> with openmaintainer) has been completely [1] revamped.
>>
>> The variants no longer do what I intended them to do. MPICH provides a
>> set of compiler wrappers (mpicc, mpicxx, etc.) that wrap compilers to
>> support MPI compilation as defined by the MPI standard. Previously the
>> variants (eg +gcc46) would wrap gcc-mp-4.6, g++-mp-4.6, etc. The
>> variants have been modified to now only wrap the fortran supplied from
>> the variant, and the CC and CXX are left to whatever MacPorts is
>> selecting as default on the system. Some of the variants (+clang and
>> friends) have been nuked completely.
>>
>> Now, I see from the thread (tl;dr) that there's been some thought put
>> in to what's going on here, and in other ports that use fortran from
>> gccXX, but I'd like to put mpich back to wrapping the requested
>> compiler suite (and not just fortran.)
>
> If that happens, then mpich cannot be used to build C++ code in other ports.  
> If that is something you're ok with, then fine... we can remove the mpich 
> variant from other ports that would be using it for C++ code.

So the issue here is we need to nuke any g++-mp-NN code out of
existence if it's going was to be used as a dependency? Just making
sure I understand the concern.

>> Sooo. I'm considering reverting the changes made to the mpich
>> portgroup over the past week.
>
> Please do not do that without discussing here as that will just reintroduce 
> the problems.

Well, that's why I'm here. :)

>
>> Given that the assumption at the
>> beginning of this thread - "If the port also has C and C++ sources,
>> then it would be preferable to leave configure.cc and configure.cxx
>> alone and just choose a fortran compiler" -- isn't correct in this
>> case, is there any reason _not_ to revert these changes?
>
> Why do you think that is not correct in this case?

Because when _I_ install mpich +gcc47 and then call mpicc/mpicxx, I
want to get gcc47 (c/c++) behind it. Perhaps I'm doing a hybrid model
with OpenMP and can't use clang.

I believe there has been discussion about what mpich +gccNN should
mean in the past, and I'm not the only one with this expectation /
desire.

Not sure what the best way is to balance this desire with the other
(dependencies) concern. But making mpich +gcc47 where mpicc and mpicxx
call llvm-gcc or clang (depending on build platform), but mpif77 calls
gfortran-mp-47 is not what I would expect or want from the variant.

If I'm the only one that wants it this way anymore, then I can always
keep my own private version for myself, I suppose.

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

Re: Fortran recipe

[Eric A. Borisch]

On Wed, Aug 28, 2013 at 4:54 PM, Jeremy Huddleston Sequoia
 wrote:
>
> On Aug 28, 2013, at 12:30, Michael Dickens  wrote:
>
>> Your "recipe" was pretty concise (unlike
>> others which declare each variant explicitly and separately), and it
>> does what -you- as the port maintainer want it to do.
>
> Actually, it didn't.  I used the old mpich Portfile as an example of broken 
> variant conflicts in my email yesterday.

I had noticed the lint behavior, and had added (but not yet committed)
separate sections to try to handle/report the conflicts; if the new
way fixes it the right way, then huzzah! I was trying to figure out
why port variants was reporting things correctly; and your explanation
(in the other thread; interpreted as one string) clears that up.

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

Re: Fortran recipe

[Eric A. Borisch]

Sorry for the blank email. Gmail interface whoops.

So I come back from vacation and find the mpich port (I'm maintainer;
with openmaintainer) has been completely [1] revamped.

The variants no longer do what I intended them to do. MPICH provides a
set of compiler wrappers (mpicc, mpicxx, etc.) that wrap compilers to
support MPI compilation as defined by the MPI standard. Previously the
variants (eg +gcc46) would wrap gcc-mp-4.6, g++-mp-4.6, etc. The
variants have been modified to now only wrap the fortran supplied from
the variant, and the CC and CXX are left to whatever MacPorts is
selecting as default on the system. Some of the variants (+clang and
friends) have been nuked completely.

Now, I see from the thread (tl;dr) that there's been some thought put
in to what's going on here, and in other ports that use fortran from
gccXX, but I'd like to put mpich back to wrapping the requested
compiler suite (and not just fortran.)

There was some separate discussion about a multiplecompilers port
group to handle some of these issues. Again, I haven't had time to go
back through all the messages to see what's going on with that and why
these changes were made instead.

Sooo. I'm considering reverting the changes made to the mpich
portgroup over the past week. Given that the assumption at the
beginning of this thread - "If the port also has C and C++ sources,
then it would be preferable to leave configure.cc and configure.cxx
alone and just choose a fortran compiler" -- isn't correct in this
case, is there any reason _not_ to revert these changes?

Thanks,
 Eric

[1] 
https://trac.macports.org/changeset?reponame=&new=110168%40trunk%2Fdports%2Fscience%2Fmpich%2FPortfile&old=108404%40trunk%2Fdports%2Fscience%2Fmpich%2FPortfile
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Fortran recipe

[Eric A. Borisch]

>>>>>>   }
>>>>>>
>>>>>>   set over_no_dot [join [split ${over} "."] ""]
>>>>>>   variant gcc${ver_no_dot} conflicts gcc${over_no_dot} {}
>>>>>> }
>>>>>>
>>>>>> variant g95 conflicts gcc${ver_no_dot} {}
>>>>>>
>>>>>> if {[variant_isset gcc${ver_no_dot}]} {
>>>>>>   set default_fortran_variant ""
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> variant g95 description {build with g95} {
>>>>>> depends_build-append port:g95
>>>>>> configure.fc ${prefix}/bin/g95
>>>>>> configure.f77 ${prefix}/bin/g95
>>>>>> configure.f90 ${prefix}/bin/g95
>>>>>> }
>>>>>>
>>>>>> if {[variant_isset g95]} {
>>>>>> set default_fortran_variant ""
>>>>>> }
>>>>>>
>>>>>> if {${default_fortran_variant} != ""} {
>>>>>> default_variants ${default_fortran_variant}
>>>>>> }
>>>>>
>>>>>
>>>>> ___
>>>>> macports-dev mailing list
>>>>> macports-dev@lists.macosforge.org
>>>>> https://lists.macosforge.org/mailman/listinfo/macports-dev
>>>>
>>>
>>> ___
>>> macports-dev mailing list
>>> macports-dev@lists.macosforge.org
>>> https://lists.macosforge.org/mailman/listinfo/macports-dev
>>
>> ___
>> macports-dev mailing list
>> macports-dev@lists.macosforge.org
>> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev



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

Re: Request for comments: mpi and using multiple compilers

[Eric A. Borisch]

On Mon, Aug 5, 2013 at 6:09 PM, Sean Farley  wrote:
>
> ebori...@macports.org writes:
>> I personally swap back and forth between variants of mpich
>> when I'm testing my own MPI code (why, oh why, doesn't clang have
>> OpenMP support yet?)
>
> Because there is almost no benefit for parallel applications? ;-)
> Really, though, if you're in the domain where OpenMP can help
> (computation bound, dense linear algebra) then your time is better spent
> on using CUDA.

Hrmm, not on the Intel PHI we're using. :) (Obviously not MacPorts
related, but I often develop on my mac, so it's nice to be able to
compile & check the OpenMP code.)

> To help get things moving along, I'd suggest we concentrate on the
> +gfortran variant (and therefore having mpich / openmpi use 'PortGroup
> multiplecompilers 1.0'). What would be holding back using the
> multiplecompilers group with active_variants?

I have no qualms moving to the portgroup; any concerns on the list
with adding the portgroup [1] to trunk?

Would you consider modifying it (perhaps it does and I missed it) to
support something like "multiplecompilers.dragonegg = 0" to disable a
family (or particular version) rather than making the variants
explicitly and having them error out in the Portfile?

Thanks,
  Eric

[1] 
https://bitbucket.org/seanfarley/scienceports/src/2832e9d9716e178f20b5ab0eb563f40d7fcce730/_resources/port1.0/group/multiplecompilers-1.0.tcl?at=default
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Request for comments: mpi and using multiple compilers

[Eric A. Borisch]

On Thu, Jul 25, 2013 at 9:31 PM, Sean Farley  wrote:
>
> ebori...@macports.org writes:
>
>> On Thursday, July 25, 2013, Sean Farley wrote:
>>
>>>
>>> ebori...@ieee.org  writes:
>>>
>>> > On Thursday, July 25, 2013, Sean Farley wrote:
>>> >>
>>> >> But really, we're at the whim of what the macports community whats to do
>>> >> in this situation. Since my Ph.D is riding on getting a working mpi +
>>> >> fortran, I'd very much like to iron out these issues and get the ports
>>> >> chugging along!
>>> >>
>>> >
>>> > Does mpich +gccXX not get you to working fortran and MPI?
>>> >
>>> > I'll try to read through some of this thread later, but just looking for
>>> > clarification on that point.
>>>
>>> Again, the issue is when using libraries dependent on mpi and
>>> exacerbated on dependents of those dependents. This usually results in
>>> breakage with the inability to specify which compiler to use in the n-th
>>> dependent.
>>>
>>
>> Again, I haven't scoured the whole thread, but would making sub-ports
>> rather than variants for the different compilers help? The
>> dependent's +gcc44+mpich could require the mpich-gcc44 package, for example.
>
> Not really. It just changes the name to the same problem.

Except for the fact that you can *depend* on the package (user gets
warnings if they try to install it) but MP will happily let the user
change the variants without warning to the (active) dependents of that
package. I personally swap back and forth between variants of mpich
when I'm testing my own MPI code (why, oh why, doesn't clang have
OpenMP support yet?) Hopefully rev-upgrade will catch that something
has (potentially) gone south, but it won't likely be able to rebuild
things back to their initial state without some hand-holding.

We could setup the different packages to avoid naming conflicts (much
like gcc44, gcc45) so multiple versions could be installed
side-by-side. An mpich_select could even be put together to redirect
mpicc -> mpicc-gccNN.

I'm not saying it's necessarily the right idea, I'm just throwing it out there.

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

Re: Request for comments: mpi and using multiple compilers

[Eric A. Borisch]

On Thursday, July 25, 2013, Sean Farley wrote:

>
> ebori...@ieee.org  writes:
>
> > On Thursday, July 25, 2013, Sean Farley wrote:
> >>
> >> But really, we're at the whim of what the macports community whats to do
> >> in this situation. Since my Ph.D is riding on getting a working mpi +
> >> fortran, I'd very much like to iron out these issues and get the ports
> >> chugging along!
> >>
> >
> > Does mpich +gccXX not get you to working fortran and MPI?
> >
> > I'll try to read through some of this thread later, but just looking for
> > clarification on that point.
>
> Again, the issue is when using libraries dependent on mpi and
> exacerbated on dependents of those dependents. This usually results in
> breakage with the inability to specify which compiler to use in the n-th
> dependent.
>

Again, I haven't scoured the whole thread, but would making sub-ports
rather than variants for the different compilers help? The
dependent's +gcc44+mpich could require the mpich-gcc44 package, for example.

I've also been playing with having the fortran compiler specified
separately with a gfortNN variant, so one could build +clangXX+gfortNN.
This opens up an entire new realm of possible breakage, however.

  - Eric


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

RE Request for comments: mpi and using multiple compilers

[Eric A. Borisch]

On Thursday, July 25, 2013, Sean Farley wrote:
>
> But really, we're at the whim of what the macports community whats to do
> in this situation. Since my Ph.D is riding on getting a working mpi +
> fortran, I'd very much like to iron out these issues and get the ports
> chugging along!
>

Does mpich +gccXX not get you to working fortran and MPI?

I'll try to read through some of this thread later, but just looking for
clarification on that point.

  - Eric



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

Re: port list confusion

[Eric A. Borisch]

Oh, and 'port outdated' is nice, too. I haven't used 'port list
' in years.

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

Re: port list confusion

[Eric A. Borisch]

Just to add my 2c; I find 'port echo active', 'port echo inactive',
and 'port echo outdated' to be my most used (not to mention much
faster than than similar list commands.)

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

Re: Accept to GSoC 2013

[Eric A. Borisch]

On Tue, Apr 9, 2013 at 3:58 AM, Rainer Müller  wrote:

> On 2013-04-08 21:16, Jeremy Lavergne wrote:
> > MacPorts has been accepted to GSoC 2013.
> >
> > Kudos to Clemens (cal), Rainer (raimue) and Lawrence (larryv) for their
> continued assistance and leadership this year.
> >
> > We're looking for additional mentors and ideas to help make this a
> success for students and MacPorts. Be sure to view our current listing:
> > https://trac.macports.org/wiki/SummerOfCode
>
> This is great news after the rejection in last year's edition of GSoC.
>
> So if there is anything you always wanted to see in base, but never had
> time to implement yourself or don't know how to do so, just propose it!
>

Can we finally get some usage reporting (downloads from the packages site,
if nothing else) implemented so we know what ports are used
frequently/infrequently. This can help with pruning in the future (if a
package is broken, and no one is using it, perhaps it's time to cull.)

I think this was a former GSoC project that never got carried across the
finish line?

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

Re: hpc gfortran

[Eric A. Borisch]

On Mon, Mar 25, 2013 at 12:16 PM, Sean Farley  wrote:

>
> Eric A. Borisch writes:
>
> > On Sunday, March 24, 2013, Joshua Root wrote:
> >
> >> On 2013-3-25 03:45 , Sean Farley wrote:
> >> > I know I've brought this up before but I'd like to get some resolution
> >> > on the following issues,
> >> >
> >> > 1) HPC gfortran
> >> >
> >> > Due to a lack of a standalone gfortran compiler, most users that need
> it
> >> > seem to go to hpc.sourceforge.net and download the version there.
> This
> >> > is all kinds of unwanted behavior that could be fixed with a
> standalone
> >> > gfortran port.
> >> >
> >> > 2) clang + fortran
> >> >
> >> > Clang is the only compiler suite so far that has no fortran
> >> > component. There is dragonegg but that also has its own c compiler.
> The
> >> > de facto standard for a (free) fortran compiler seems to have fallen
> to
> >> > gfortran. So, the issue here that I see is when a port wants the clang
> >> > compiler + a fortran compiler. Currently, in macports it is up to the
> >> > portfile author to decide to use the default c compiler or to use
> gcc4X
> >> > (as opposed to letting the user decide).
> >> >
> >> > 3) compiler wrappers
> >> >
> >> > So far, this only applies to MPI but it could also apply to packages
> >> > like TAU [1]. When a package depends on MPI, the standard implies
> there
> >> > will be at least mpicc and mpifc. Again, the issue here could be
> solved
> >> > with a standalone gfortran port.
> >> >
> >> > Having a standalone gfortran compiler would be able to solve (1-3)
> >> > but I haven't gotten good feedback on that so far. So, I'm asking the
> >> > macports devs for some ways to solve the above issues that everyone
> >> > would be comfortable with.
> >>
> >> I don't think anyone would object to splitting gfortran (and gcj) out in
> >> subports of the various gccXY and dragonegg ports. It's just that so
> >> far, nobody did the work.
> >>
> >> - Josh
> >>
> >
> > I'm all for it. It's likely less of an issue for many now that the
> > buildbots pull so much of the install/upgrade times down. I'm happy to
> > update mpich to have separate fortranNN and gcc/clang/llvm selectors.
>
> Great, thanks!
>
> > Looking forward, should a gccNN require the matching gfortranNN?
>
> Good question.
>

Is it worth it to split out gfortran? Is, for example, installing the
current gcc47 port *that* much of an issue for those that require
bin/gfortran-mp-4.7?

If the answer is no, it's not much of an issue, and you just want the mpi
ports to break-out fortran selection, shouldn't we just handle it in those
use cases?

It would be nice to have 'configure compiler macports-gfortran-4.7' work to
fill in just the configure.f* flags for this use case.

If the desire is to really split it out, I would float the possibility
having the gccNN port require the gfortranNN port. This would remove the
requirement to update all of the ports currently using gccNN and expecting
to get gfortranNN.

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

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

[Eric A. Borisch]

On Mon, Mar 25, 2013 at 8:38 AM, Joshua Root  wrote:

> On 2013-3-26 00:27 , Joshua Root wrote:
> > On 2013-3-26 00:22 , Eric A. Borisch wrote:
> >> I've pondered ones like this one before. Shouldn't the binary packages
> >> be updated (and would they without the revbump)? Don't we want the
> >> binary to match (as close as possible) what would happen if someone
> >> built from source? And related, if someone installs (source or binary)
> >> rev1 (new install, pre-change) today, and someone else installs (source)
> >> rev1 (if it hadn't been bumped) new tomorrow don't we want those to
> match?
> >
> > That might be relevant if the py*-numpy binaries used any gcc variant.
>
> To be clear, I mean relevant to this particular case. Your concerns are
> valid in the general case. Yes, MPAB should check that the existing
> archive has the current default variants before deciding to skip the build.
>
> - Josh
>

Alas, I forgot +atlas (and associated +gccNN) had been dropped from numpy's
default.

It would be nice if 'sudo port upgrade' could detect something (in the
general, not this particular) case like:

  NOTE: default variants for port "python" changed from "+eggs" to
"+eggs+spam" since installed.
  Follow change of defaults [y/N] ?

Not sure how feasible this is with what is currently stored in the
registry, but this would be a nice feature to keep binary package usage
high.

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

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

[Eric A. Borisch]

On Mon, Mar 25, 2013 at 7:03 AM, Joshua Root  wrote:

> > Revision: 104383
> >   https://trac.macports.org/changeset/104383
> > Author:   stromnov at macports.org
> > Date: 2013-03-24 04:29:11 -0700 (Sun, 24 Mar 2013)
> > Log Message:
> > ---
> > py-numpy: set default gcc47 variant, add gcc48 variant
> >
> > Modified Paths:
> > --
> > trunk/dports/python/py-numpy/Portfile
> >
> > Modified: trunk/dports/python/py-numpy/Portfile
> > ===
> > --- trunk/dports/python/py-numpy/Portfile 2013-03-24 11:27:23 UTC
> (rev 104382)
> > +++ trunk/dports/python/py-numpy/Portfile 2013-03-24 11:29:11 UTC
> (rev 104383)
> > @@ -7,7 +7,7 @@
> >
> >  github.setupnumpy numpy 1.6.2 v
> >  namepy-numpy
> > -revision1
> > +revision2
>
> A rev bump was not warranted here. Making everyone rebuild accomplishes
> nothing; everyone who currently has the port installed will still have
> the same gcc variant selected after they upgrade.
>
> - Josh
>

I've pondered ones like this one before. Shouldn't the binary packages be
updated (and would they without the revbump)? Don't we want the binary to
match (as close as possible) what would happen if someone built from
source? And related, if someone installs (source or binary) rev1 (new
install, pre-change) today, and someone else installs (source) rev1 (if it
hadn't been bumped) new tomorrow don't we want those to match?

I understand the upgrading point, which brings up another question I've had
- should we highlight for users (especially those less interested in the
guts, and just in "does it work" and "homebrew is so much faster") in some
fashion when default variants have changed, causing their previously quick
binary upgrades into unexpected source builds?

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

Re: hpc gfortran

[Eric A. Borisch]

On Sunday, March 24, 2013, Joshua Root wrote:

> On 2013-3-25 03:45 , Sean Farley wrote:
> > I know I've brought this up before but I'd like to get some resolution
> > on the following issues,
> >
> > 1) HPC gfortran
> >
> > Due to a lack of a standalone gfortran compiler, most users that need it
> > seem to go to hpc.sourceforge.net and download the version there. This
> > is all kinds of unwanted behavior that could be fixed with a standalone
> > gfortran port.
> >
> > 2) clang + fortran
> >
> > Clang is the only compiler suite so far that has no fortran
> > component. There is dragonegg but that also has its own c compiler. The
> > de facto standard for a (free) fortran compiler seems to have fallen to
> > gfortran. So, the issue here that I see is when a port wants the clang
> > compiler + a fortran compiler. Currently, in macports it is up to the
> > portfile author to decide to use the default c compiler or to use gcc4X
> > (as opposed to letting the user decide).
> >
> > 3) compiler wrappers
> >
> > So far, this only applies to MPI but it could also apply to packages
> > like TAU [1]. When a package depends on MPI, the standard implies there
> > will be at least mpicc and mpifc. Again, the issue here could be solved
> > with a standalone gfortran port.
> >
> > Having a standalone gfortran compiler would be able to solve (1-3)
> > but I haven't gotten good feedback on that so far. So, I'm asking the
> > macports devs for some ways to solve the above issues that everyone
> > would be comfortable with.
>
> I don't think anyone would object to splitting gfortran (and gcj) out in
> subports of the various gccXY and dragonegg ports. It's just that so
> far, nobody did the work.
>
> - Josh
>

I'm all for it. It's likely less of an issue for many now that the
buildbots pull so much of the install/upgrade times down. I'm happy to
update mpich to have separate fortranNN and gcc/clang/llvm selectors.
Looking forward, should a gccNN require the matching gfortranNN?

  - Eric


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

Re: [MacPorts] #36459: doxygen @1.8.1: graphiz dependency problem?

[Eric A. Borisch]

On Mon, Feb 18, 2013 at 6:39 PM, Ryan Schmidt wrote:

>
> On Feb 18, 2013, at 18:32, Lawrence Velázquez  wrote:
>
> > On Feb 18, 2013, at 7:19 PM, Ryan Schmidt 
> wrote:
> >
> >> On Feb 18, 2013, at 14:26, Lawrence Velázquez 
> wrote:
> >>
> >>> Why does doxygen have a dependency on graphviz, anyway? I'm aware that
> Doxygen can use Graphviz if it's available,
> >>
> >> The second sentence is the answer to the first.
> >
> > Sure, but as far as I can tell, it's a runtime thing, and Graphviz is
> not *necessary* unless you actually want Doxygen to generate advanced class
> diagrams. And if you want that, you can install graphviz whenever you feel
> like.
> >
> > http://www.stack.nl/~dimitri/doxygen/manual/diagrams.html
> >
> > As it stands, installing doxygen forces you to pull in graphviz and its
> huge dependency tree, even if you have no intention of making diagrams.
>
> What about the ports that declare build dependencies on doxygen? Do any of
> them use this diagramming capability?
>
>
FWIW, FreeBSD's port requires graphviz [1] and many Linux RPMs don't [2]
... so there's no consensus to be had by looking for what others are doing.

I use doxygen with graphviz, but most of utility exists without it. The
differences between the dependencies with [3] and without [4] are striking.

Perhaps a default variant (+diagrams)?

This doesn't address if any other ports depending on doxygen use the dot
capability, but it would be easy enough for those ports to declare the
graphviz requirement themselves. A default doxyfile (doxygen -g output)
currently has HAVE_DOT set to NO, regardless of its presence at build- or
runtime.

 - Eric

[1] http://www.freshports.org/devel/doxygen
[2]
http://rpmfind.net//linux/RPM/fedora/devel/rawhide/x86_64/d/doxygen-1.8.3.1-1.fc19.x86_64.html
[3] https://www.dropbox.com/s/3jqatlydyxpjydy/doxygen.png
[4] https://www.dropbox.com/s/ahedegu0m28qh5m/doxygen_no_graphviz.png
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [103053] trunk/dports/net/zabbix2/Portfile

[Eric A. Borisch]

On Mon, Feb 18, 2013 at 8:55 PM, Eric A. Borisch wrote:

>
>
> On Monday, February 18, 2013, Ryan Schmidt wrote:
>
>>
>> On Feb 18, 2013, at 12:00, ebori...@macports.org wrote:
>>
>> > Revision: 103206
>> >  https://trac.macports.org/changeset/103206
>> > Author:   ebori...@macports.org
>> > Date: 2013-02-18 10:00:16 -0800 (Mon, 18 Feb 2013)
>> > Log Message:
>> > ---
>> > zabbix2[-agent]: Upgrade to 2.0.5; Update dependencies.
>> >
>> > Modified Paths:
>> > --
>> >trunk/dports/net/zabbix2/Portfile
>>
>> > @@ -75,13 +75,13 @@
>> > array set DBLIST {
>> > mysql5  {"MySQL 5.x"
>>  path:bin/mysql_config5:mysql5-server \
>> >  mysql=${prefix}/lib/mysql5/bin/mysql_config}
>> > -pgsql81 {"PostgreSQL 8.1.x" port:postgresql81 \
>> > +pgsql81 {"PostgreSQL 8.1.x" port:postgresql81-server \
>> >  pgsql=${prefix}/lib/postgresql81/bin/pg_config}
>> > -pgsql82 {"PostgreSQL 8.2.x" port:postgresql82 \
>> > +pgsql82 {"PostgreSQL 8.2.x" port:postgresql82-server \
>> >  pgsql=${prefix}/lib/postgresql82/bin/pg_config}
>> > -pgsql83 {"PostgreSQL 8.3.x" port:postgresql83 \
>> > +pgsql83 {"PostgreSQL 8.3.x" port:postgresql83-server \
>> >  pgsql=${prefix}/lib/postgresql83/bin/pg_config}
>> > -pgsql84 {"PostgreSQL 8.4.x" port:postgresql84 \
>> > +pgsql84 {"PostgreSQL 8.4.x" port:postgresql84-server \
>> >  pgsql=${prefix}/lib/postgresql84/bin/pg_config}
>> > sqlite3 {"SQLite 3.x"   port:sqlite3 \
>> >  sqlite3=${prefix}}
>>
>> Again I must ask: why is a database server now required on the same
>> machine? Why is it not sufficient for the database server to be on another
>> machine
>
>
> I suppose one could. I'll switch it back (for MySQL as well) - or you can,
> it's nomaintainer.
>

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

Re: [103204] trunk/dports

[Eric A. Borisch]

On Mon, Feb 18, 2013 at 6:45 PM, Ryan Schmidt wrote:

>
> On Feb 18, 2013, at 10:09, ebori...@macports.org wrote:
>
> > +variant mpich2 requires mpich description {Variant renamed as +mpich} {}
>
> You should use "Legacy compatibility variant" as the description in these
> cases.
>
>
Done. r103217.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [103053] trunk/dports/net/zabbix2/Portfile

[Eric A. Borisch]

On Monday, February 18, 2013, Ryan Schmidt wrote:

>
> On Feb 18, 2013, at 12:00, ebori...@macports.org  wrote:
>
> > Revision: 103206
> >  https://trac.macports.org/changeset/103206
> > Author:   ebori...@macports.org 
> > Date: 2013-02-18 10:00:16 -0800 (Mon, 18 Feb 2013)
> > Log Message:
> > ---
> > zabbix2[-agent]: Upgrade to 2.0.5; Update dependencies.
> >
> > Modified Paths:
> > --
> >trunk/dports/net/zabbix2/Portfile
>
> > @@ -75,13 +75,13 @@
> > array set DBLIST {
> > mysql5  {"MySQL 5.x"
>  path:bin/mysql_config5:mysql5-server \
> >  mysql=${prefix}/lib/mysql5/bin/mysql_config}
> > -pgsql81 {"PostgreSQL 8.1.x" port:postgresql81 \
> > +pgsql81 {"PostgreSQL 8.1.x" port:postgresql81-server \
> >  pgsql=${prefix}/lib/postgresql81/bin/pg_config}
> > -pgsql82 {"PostgreSQL 8.2.x" port:postgresql82 \
> > +pgsql82 {"PostgreSQL 8.2.x" port:postgresql82-server \
> >  pgsql=${prefix}/lib/postgresql82/bin/pg_config}
> > -pgsql83 {"PostgreSQL 8.3.x" port:postgresql83 \
> > +pgsql83 {"PostgreSQL 8.3.x" port:postgresql83-server \
> >  pgsql=${prefix}/lib/postgresql83/bin/pg_config}
> > -pgsql84 {"PostgreSQL 8.4.x" port:postgresql84 \
> > +pgsql84 {"PostgreSQL 8.4.x" port:postgresql84-server \
> >  pgsql=${prefix}/lib/postgresql84/bin/pg_config}
> > sqlite3 {"SQLite 3.x"   port:sqlite3 \
> >      sqlite3=${prefix}}
>
> Again I must ask: why is a database server now required on the same
> machine? Why is it not sufficient for the database server to be on another
> machine


I suppose one could. I'll switch it back (for MySQL as well) - or you can,
it's nomaintainer.


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

Ports depending on mpich2: move to mpich

[Eric A. Borisch]

On Jan 26, 2013, at 8:15 AM, Ryan Schmidt
>
wrote:

> We could rename the manpages ourselves.

#11576



-- 
Eric A. Borisch
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Ports depending on mpich2: move to mpich

[Eric A. Borisch]

On Friday, January 25, 2013, Sean Farley wrote:

> On Fri, Jan 25, 2013 at 3:29 PM, Eric A. Borisch 
> >
> wrote:
> > The MPICH project has named version 3 of the software as MPICH v3.0
> (rather
> > than continuing on MPICH2 to become MPICH3.) The mpich[-devel] port has
> been
> > moved (r100087) to this up-to-date version.
> >
> > At this time, I'm ready to move all ports that depend on MPICH2 to MPICH
> > (v3), as well as to mark MPICH2 as replaced_by MPICH. (These two steps
> could
> > be done separately -- suggestions on if this should be an atomic change,
> or
> > two changes -- and in which order?)
> >
> > I have attached a patch that does just that, and have copied all portfile
> > owners associated on the ticket https://trac.macports.org/ticket/37785with
> > the diff attached.
> >
> > I plan to apply the patch next week unless there are concerns raised.
>
> Cleaning up the mpi ports is fantastic! Could we also use this time to
> remove lammpi (it has long since died and been replaced by openmpi)?
> The only issue I can remember is that the simultaneous installation of
> openmpi and mpich is broken.
>
> Also, I still would like all mpi ports (mpich and openmpi … are there
> any others still working?) to always have a fortran compiler, would it
> be reasonable to talk about that here?
>

Simultaneous openmpi and mpich is (if I recall) down to some man page
conflicts. (Openmpi is renaming their bins, but not the associated mans.)

Re:fortran, how would you propose 'mpich +clang' (for example) address
Fortran? I personally use mpich (cc/ccx) extensively without Fortran;
should I be required to install a fortran compiler & wrapper I don't need?
If installed with a +gcc variant (and therefore a fort compiler is present)
mpich enables fortran.

I'm dead set not against it, but I suppose I need some convincing.

Thanks,
  Eric


-- 
Eric A. Borisch
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Ports depending on mpich2: move to mpich

[Eric A. Borisch]

The MPICH project has named version 3 of the software as MPICH v3.0 (rather
than continuing on MPICH2 to become MPICH3.) The mpich[-devel] port has
been moved (r100087) to this up-to-date version.

At this time, I'm ready to move all ports that depend on MPICH2 to MPICH
(v3), as well as to mark MPICH2 as replaced_by MPICH. (These two steps
could be done separately -- suggestions on if this should be an atomic
change, or two changes -- and in which order?)

I have attached a patch that does just that, and have copied all portfile
owners associated on the ticket https://trac.macports.org/ticket/37785 with
the diff attached.

I plan to apply the patch next week unless there are concerns raised.
Thanks,
 Eric
-- 
Eric A. Borisch
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

hdf5-18 upgrade pending

[Eric A. Borisch]

For the record on the list, I've made this ticket to stage an hdf5-18
upgrade and associated rev-bumps.

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

Please review if interested.

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

Re: gfortran standalone port

[Eric A. Borisch]

On Thu, Jan 17, 2013 at 5:25 PM, Sean Farley  wrote:

> On Thu, Jan 17, 2013 at 4:54 PM, Jeremy Huddleston Sequoia
>  wrote:
> > On Jan 17, 2013, at 14:44, Joshua Root  wrote:
> >> On 2013-1-18 08:09 , Jeremy Huddleston Sequoia wrote:
> >>> It would be nice if 'port lint' would report about missing license
> lines in dependencies as well.  Maybe 'port lint -R' could be made to do
> this.
> >>
> >> I'm not sure linting all the dependencies is really what you're after
> >> here. You can check for dependencies without licenses with:
> >>
> >> port echo rdepof:myport and license:unknown
> >>
> >> Would doing this in the post-commit hook be useful or just annoying?
> >
> > That would be useful.  The message could state, "This port will not be
> prepared as a binary package because the following ports do not have known
> licenses:
>

WRT detecting what ports are blocking a binary distributable, isn't this
the right tool [1]: "port_binary_distributable.tcl -v portname"? Or perhaps
the suggestion is for port lint to report this information?

Admittedly, I believe this just returns the first blocker.

I didn't mean to derail this thread with an offhanded comment about
> the binary package, sorry. Regardless of having a binary package or
> not, we still have a problem with dependencies:
>
> $ port install mpich -> no fortran enabled
> [ ... ]

This, again, relates to ticket 126 and not having a way to query
> variants. The active-variant port group doesn't really help because
> many variants (any +gcc4X) would satisfy the fortran need. A decent
> workaround is to "close" all ports that have no fortran enabled
> without +gcc4X and to provide both g95 and gfortran for these ports.
> So, we could have:
>
> $ port install mpich -> fortran enabled with gfortran, clang for other
> compiler
>

I could certainly (in mpich[-deve]) attempt (not disable) a fortran build
by let configure auto-detect without any variants selected, but then you
get an opportunistic, and not recorded, dependency against whatever
actually provided the fortran compiler. I don't think that's a desirable
situation.

Thanks,
   Eric

[1]
https://trac.macports.org/browser/trunk/base/portmgr/jobs/port_binary_distributable.tcl
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [101627] trunk/dports/python/py-spyder-devel/Portfile

[Eric A. Borisch]

On Wednesday, January 16, 2013, Ryan Schmidt wrote:

>
> On Jan 16, 2013, at 00:21, Eric A. Borisch wrote:
> > Ok. I kind like the date formatted ones (has more information encoded in
> it than '1') and they seem to meet the "only requirements" from the guide.
> But if minimal bumps are desired, so be it.
>
> But it doesn't encode any information, at least, not any that the user can
> rely upon.
>

I disagree - the trivial information it encoded (for me, the port
maintainer) is when the epoch was last changed. Certainly SVN blame (or
praise) can provide the same information. If whitespace changes happen
later, svn blame may require you to parse back a few levels, but you can
still dig it out.

Trivial? Yes. Useless? Debatable. None of any use to anyone? No.

And I'm not the only one who thinks so -- see python3[23] and py-tkinter /
py-gdbm for an example complete with a comment re:why. There 30+ ports that
are currently in a date-based epoch, for better or for worse.

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

Portfile Workflow Advice

[Eric A. Borisch]

On Jan 15, 2013, at 11:18 PM, Sean Farley >
wrote:

>>>> How and when is the csearch index updated? I like that grep gets me
completely up-to-date results every time.
>>>
>>> It's manual but cindex updates itself in ~7s (depending on the number
>>> of changed files) for me and is more than just macports (it's all my
>>> code on my hard drive, in fact). I usually run it after pulling new
>>> changes. But really, for me at least, code doesn't change fast enough
>>> for me to care about hitting false-postives or whatnot; plus what I'm
>>> usually searching for is an example so all I really want is the
>>> location of a handful of files.
>>
>> That is true.
>
> Side note: search all projects comes in really handy when working with
> dependencies (i.e. definitions / examples would sometimes live in
> another project's root).

I *think* you only get false negatives for  modified files. (It seams to
search the files it selects as containing a match for the actual matches.)

A cron job every night is the easy way to reindex for large source trees.
[1] You can always kick of a manual refresh if you are looking for more
recent changes. Works wonderfully for finding what ports (beyond what is
installed and reported by rdependentof) depend upon the one I'm currently
breaking.

   - Eric

[1]
http://code.google.com/p/codesearch/source/browse/cmd/cindex/cindex.go#38


-- 
Eric A. Borisch
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Man page re-compression in parallel?

[Eric A. Borisch]

Any thoughts on performing the man page (re)compression in parallel
(multiple jobs)? It seems like reasonably low-hanging fruit, and on a port
with lots of man pages, it can take a while. Not gobs of time, mind you,
but enough to make me ask the question.

Thanks,
  Eric


-- 
Eric A. Borisch
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [101627] trunk/dports/python/py-spyder-devel/Portfile

[Eric A. Borisch]

On Tuesday, January 15, 2013, Ryan Schmidt wrote:

>
> On Jan 15, 2013, at 08:51, ebori...@macports.org  wrote:
>
> > Revision: 101627
> >  https://trac.macports.org/changeset/101627
> > Author:   ebori...@macports.org 
> > Date: 2013-01-15 06:51:39 -0800 (Tue, 15 Jan 2013)
> > Log Message:
> > ---
> > py-spyder-devel: Update to 2.2.0beta
> >
> > Modified Paths:
> > --
> >trunk/dports/python/py-spyder-devel/Portfile
> >
> > Modified: trunk/dports/python/py-spyder-devel/Portfile
> > ===
> > --- trunk/dports/python/py-spyder-devel/Portfile  2013-01-15
> 12:32:40 UTC (rev 101626)
> > +++ trunk/dports/python/py-spyder-devel/Portfile  2013-01-15
> 14:51:39 UTC (rev 101627)
> > @@ -3,8 +3,9 @@
> >
> > PortSystem  1.0
> > namepy-spyder-devel
> > -version 2.2.0-dev
> > +version 2.2.0beta1
> > revision0
> > +epoch   20130115
>
> It can't be changed for py-spyder-devel now, but for other ports in the
> future, please just increase the epoch by one when it's needed. There's no
> reason for the epoch to be formatted to look like a date, and doing so will
> just be confusing years down the road.
>
> http://guide.macports.org/chunked/reference.html#reference.keywords
>

Ok. I kind like the date formatted ones (has more information encoded in it
than '1') and they seem to meet the "only requirements" from the guide. But
if minimal bumps are desired, so be it.

Thanks,
  Eric


-- 
Eric A. Borisch
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [100629] trunk/dports/science/mpich/Portfile

[Eric A. Borisch]

On Mon, Dec 17, 2012 at 11:43 PM, Ryan Schmidt wrote:

>
> On Dec 17, 2012, at 22:16, ebori...@macports.org wrote:
>
> > Revision: 100629
> >  https://trac.macports.org/changeset/100629
> > Author:   ebori...@macports.org
> > Date: 2012-12-17 20:16:28 -0800 (Mon, 17 Dec 2012)
> > Log Message:
> > ---
> > mpich[-devel]: Update to use compiler_blacklist_versions. Only create
> clang variant when compatible.
> >
> > Modified Paths:
> > --
> >trunk/dports/science/mpich/Portfile
> >
> > Modified: trunk/dports/science/mpich/Portfile
> > ===
> > --- trunk/dports/science/mpich/Portfile   2012-12-18 00:57:35 UTC
> (rev 100628)
> > +++ trunk/dports/science/mpich/Portfile   2012-12-18 04:16:28 UTC
> (rev 100629)
> > @@ -2,6 +2,7 @@
> > # $Id$
> >
> > PortSystem  1.0
> > +PortGroup   compiler_blacklist_versions 1.0
> >
> > namempich
> > set pkgname mpich2
> > @@ -84,6 +85,9 @@
> >
> > depends_lib-append  port:libxml2
> >
> > +# Linker for Apple clang version 431.11.66 currently segfaults
> > +# See https://trac.macports.org/ticket/36654#comment:9
> > +compiler.blacklist-append   {clang >= 421.11.66}
>
> 431.11.66 or 421.11.66?
>
>
I think the one that is evaluated (421.11.66) is the correct one, but I'll
have to check on my ML machine this evening.

I'm debating having the +clang variant set as default (when not
blacklisted) and the +llvm variant set as default otherwise, and
potentially adding a check that one of the compiler variants must be
selected (so it is explicit which compiler is being wrapped.) Any thoughts
on that (wrt old systems?)

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

Re: mpich3 -> mpich rename opinions?

[Eric A. Borisch]

Again for anyone joining in, these gyrations are due to upstream naming
changes and trying to minimize user confusion. There was once MPICH, and
then there was MPICH2, and now there is once again MPICH (v3.0).

For clarity below:
 * Upstream package names in CAPS
 * Port names in lowercase

My current plan (after more discussions with MPICH developers) is to soon:

0) Make sure gnudatalanguage and any others I missed compile fine with
mpich2 (MPICH2 v1.5) (It sounds like Sean has already confirmed this for
gnudatalanguage.)
1) Move mpich to be the same codebase as mpich2 (MPICH2 v1.5)
2) Create mpich-devel as mpich (MPICH v3.0rc1)

And once MPICH v3.0 is released:

0) Move mpich to be MPICH v3.0 (mpich-devel will match / track HEAD)
1) Set mpich3 to be 'replaced_by' mpich
2) Test other dependencies as time / motivation permits and migrate to
mpich (now at MPICH v3.0)
3) Set mpich2 to be 'replaced_by' mpich once there are no dependencies left.

 -- Eric


On Fri, Nov 16, 2012 at 5:20 PM, Sean Farley
wrote:

> On Fri, Nov 16, 2012 at 4:56 PM, Ryan Schmidt 
> wrote:
> >
> > On Nov 16, 2012, at 14:58, Eric A. Borisch wrote:
> >
> >> I'm considering updating the 'mpich' portfile to version 3.0rc1; this
> is currently available as 'mpich3.'
> >>
> >> Background: The upstream project has changed naming conventions; they
> previously had mpich (now at 1.2.7p1) and mpich2 (at 1.5). With the
> implementation of the MPI-3 standard (mpich2 was MPI-2, etc.) they've gone
> back to the mpich name, and they've requested that our (my) mpich3 port
> replace the (nomaintainer) mpich port for consistency.
> >>
> >> There are no ports that currently depend on 'mpich' .. any other
> concerns with making this change (and setting a replaced_by in mpich3 for
> the next year before pruning it?)
> >
> > There is one port that depends on mpich: gnudatalanguage
>
> I once maintained a version of gnudatalanguage that used mpich2:
>
>
> https://bitbucket.org/seanfarley/scienceports/src/32b478a0654b/math/gnudatalanguage/Portfile?at=default
>
> It is a trivial change.
>
> > But your plan sounds good to me.
> >
> > Will the mpich2 port survive or will it also be replaced by the mpich
> port? There are many ports depending on mpich2.
>
> It is planned to replace mpich2 by mpich 3.0. As someone that works in
> the same department as the mpich group and, more importantly, someone
> that actually uses mpi, I have the following suggestions:
>
> * remove lammpi; it has long since been abandoned for openmpi
> * have openmpi{,-devel} conflict with mpich{,2,-devel} and drop the
> openmpicc business (so that all dependent ports can check for
> path:bin/mpicc)
> * replace mpich by mpich 3.0
> * leave mpich2 for now
>
> I have implemented these changes in my scienceports repo (with the
> added compiler variants via my custom portgroup [1]), so feel free to
> pick and chose which parts you want to copy:
>
>
> https://bitbucket.org/seanfarley/scienceports/src/b4bac6a7317a8f94c29ce39e81ae693d5a3503f0/science/openmpi/Portfile?at=default
>
> https://bitbucket.org/seanfarley/scienceports/src/b4bac6a7317a8f94c29ce39e81ae693d5a3503f0/science/mpich/Portfile?at=default
>
> Hmmm, be careful if you copy the version as 3.0rc1. I was being lazy
> about that but I'd prefer not to force an epoch increase, if possible.
>
> [1]: https://trac.macports.org/ticket/35360
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [99761] trunk/dports/devel -- and broken SL buildbot?

[Eric A. Borisch]

Yep, missed those in converting it from the other version (Sean Farley's).
Those could be added to lint checks, no?

I'll get to it tonight. Or anyone else can if they are ambitious.

In other news, is the buildbot broken?
https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/12421/steps/gather%20archives/logs/stdio

 -Eric


On Fri, Nov 16, 2012 at 4:23 PM, Frank Schima
wrote:

>
> On Nov 16, 2012, at 3:17 PM, ebori...@macports.org wrote:
>
>   Revision 99761  Author
> ebori...@macports.org Date 2012-11-16 14:17:56 -0800 (Fri, 16 Nov 2012) Log
> Message
>
> codesearch: New port. Closes #37007.
>
> Added Paths
>
>- trunk/dports/devel/codesearch/
>- trunk/dports/devel/codesearch/Portfile
>
>  Diff
> Added: trunk/dports/devel/codesearch/Portfile (0 => 99761)
>
> --- trunk/dports/devel/codesearch/Portfile(rev 0)
> +++ trunk/dports/devel/codesearch/Portfile2012-11-16 22:17:56 UTC (rev 
> 99761)@@ -0,0 +1,56 @@+# -*- 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$
> +
> +# Adapted from 
> https://bitbucket.org/seanfarley/scienceports/src/de7cc636fbec/devel/codesearch/Portfile?at=default
> +
> +PortSystem  1.0
> +
> +namecodesearch
> +version 20121021
> +categories  devel
> +maintainers openmainter
>
>
> "openmainter" is not a valid maintainer. Neither is "openmaintainer" by
> itself. You want "nomaintainer" if there is no maintainer.
>
> +description Indexed regular expression-based search
> +long_description \
> +Code Search is a tool for indexing and then performing regular \
> +expression searches over large bodies of source code. It is a \
> +set of command-line programs written in Go
> +
> +license BSD
> +homepagehttp://code.google.com/p/codesearch/
> +master_siteshttp://codesearch.googlecode.com/files/
> +
> +depends_lib port:go
> +
> +worksrcdir  src/code.google.com/p/codesearch
> +
> +distname${name}-${version}
>
>
> This is the default distname and thus should be deleted.
>
> +extract.suffix  .tgz
> +
> +post-extract {
> +xinstall -d ${workpath}/src/code.google.com/p
> +move ${workpath}/${name} ${workpath}/src/code.google.com/p
> +}
> +
> +use_configure   no
> +set progs   [list cgrep csearch cindex]
> +
> +build {
> +  foreach prog ${progs} {
> +system -W ${worksrcpath} \
> + "GOPATH=${workpath} go build cmd/${prog}/${prog}.go"
> +  }
> +}
> +
> +destroot {
> +  foreach prog ${progs} {
> +xinstall ${worksrcpath}/${prog} ${destroot}${prefix}/bin
> +  }
> +}
> +
> +checksums \
> +rmd160  28e1c25f4fe5381d84c8ad4280b70a4bc2fd0427 \
> +sha256  cec62d9951fa4fb29a212139b1f2ddbab7536b3fb3fe2067840596cb482191c6
> +
> +livecheck.type  regex
> +livecheck.url   http://code.google.com/p/codesearch/downloads/list
> +livecheck.regex ${name}-(\\d+).tgzProperty changes on: 
> trunk/dports/devel/codesearch/Portfile___
>
>  Added: svn:keywords
>  Added: svn:eol-style
>  ___
> macports-changes mailing list
> macports-chan...@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-changes
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

mpich3 -> mpich rename opinions?

[Eric A. Borisch]

I failed to update the topic on my previous message. Here it is again for
the record and clarity.

On Fri, Nov 16, 2012 at 1:14 PM, Eric A. Borisch wrote:

> I'm considering updating the 'mpich' portfile to version 3.0rc1; this is
> currently available as 'mpich3.'
>
> Background: The upstream project has changed naming conventions; they
> previously had mpich (now at 1.2.7p1) and mpich2 (at 1.5). With the
> implementation of the MPI-3 standard (mpich2 was MPI-2, etc.) they've gone
> back to the mpich name, and they've requested that our (my) mpich3 port
> replace the (nomaintainer) mpich port for consistency.
>
> There are no ports that currently depend on 'mpich' .. any other concerns
> with making this change (and setting a replaced_by in mpich3 for the next
> year before pruning it?)
>
> Thanks,
>  Eric
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Java Open Source software in MacPorts?

[Eric A. Borisch]

I'm considering updating the 'mpich' portfile to version 3.0rc1; this is
currently available as 'mpich3.'

Background: The upstream project has changed naming conventions; they
previously had mpich (now at 1.2.7p1) and mpich2 (at 1.5). With the
implementation of the MPI-3 standard (mpich2 was MPI-2, etc.) they've gone
back to the mpich name, and they've requested that our (my) mpich3 port
replace the (nomaintainer) mpich port for consistency.

There are no ports that currently depend on 'mpich' .. any other concerns
with making this change (and setting a replaced_by in mpich3 for the next
year before pruning it?)

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

Re: [99497] trunk/dports/net

[Eric A. Borisch]

On Wed, Nov 7, 2012 at 3:04 PM, Ryan Schmidt wrote:

> Looks like a file needs to be added because the buildbot fails with:
>
> Error: org.macports.destroot for port zabbix2 returned: xinstall: Cannot
> stat: /Volumes/work/mports/dports/net/zabbix2/files/zabbix_server.init, No
> such file or directory
>
>
Fixed.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [97883] trunk/dports/sysutils/OpenIPMI/Portfile

[Eric A. Borisch]

On Thu, Sep 20, 2012 at 11:56 PM, Ryan Schmidt  wrote:
>
> On Sep 18, 2012, at 15:43, ebori...@macports.org wrote:
>
>> Revision: 97883
>>  http://trac.macports.org//changeset/97883
>> Author:   ebori...@macports.org
>> Date: 2012-09-18 13:43:40 -0700 (Tue, 18 Sep 2012)
>> Log Message:
>> ---
>> Improved build process.
>>
>> Modified Paths:
>> --
>>trunk/dports/sysutils/OpenIPMI/Portfile
>>
>> Modified: trunk/dports/sysutils/OpenIPMI/Portfile
>> ===
>> --- trunk/dports/sysutils/OpenIPMI/Portfile   2012-09-18 19:54:49 UTC (rev 
>> 97882)
>> +++ trunk/dports/sysutils/OpenIPMI/Portfile   2012-09-18 20:43:40 UTC (rev 
>> 97883)
>> @@ -4,6 +4,7 @@
>>
>> nameOpenIPMI
>> version 2.0.19
>> +revision1
>> license {GPL-2 LGPL-2}
>> categories  sysutils
>> platforms   darwin
>> @@ -29,9 +30,6 @@
>> patchfiles  weak_symbols.patch \
>> configure.in.patch
>>
>> -depends_build   port:autoconf \
>> -port:automake
>> -
>> depends_lib port:popt \
>> port:gsed
>>
>> @@ -63,9 +61,7 @@
>> "grep -R 'LD_PRELOAD' -l * | xargs sed -i '' -e '${REPLSTR}'"
>> }
>>
>> -post-patch {
>> -system -W ${worksrcpath} "autoreconf"
>> -}
>> +use_autoreconf  yes
>
> For future reference, since this doesn't affect the files that ultimately get 
> installed by the port, no revision increase was necessary.

Some of the installed files *are* slightly different (in the comments
of some of the .la files) ... just for completeness I revbumped it.

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

Re: hdf5-18 openmpi conflicting with gcc46

[Eric A. Borisch]

On Thu, Sep 6, 2012 at 11:10 PM, Lawrence Velázquez
 wrote:
> On Sep 6, 2012, at 11:26 p.m., Srinath Vadlamani wrote:
>
>> This was not the case a few months ago, but now it is.
>>
>> Why?
>
> The openmpi variant now forces the use of the compiler that was used to build 
> openmpi. It conflicts with all gccXY variants.
>
> vq

If you want hdf5-18 installed with gcc46's fortran and openmpi, do this:

sudo port install openmpi +gcc46 (openmpif90 wraps gcc46's fortran)
sudo port install hdf5-18 +openmpi+fortran (uses openmpi(cc|cxx|f90)
as the compilers)

Similarly for mpich2, but for mpich2, all the gccNN compilers
(c/c++/fort) are used, not just fortran.

This was done to avoid failures when competing gccNN (or lack thereof)
versions were selected for mpich2/openmpi and hdf5-18 +openmpi /
+mpich2.

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

Re: science ports upgrade to gcc47

[Eric A. Borisch]

On Mon, Aug 6, 2012 at 11:44 AM, Sean Farley
 wrote:
>> arpack
>> cfitsio
>> dotwrp
>> fftw-3
>> fftw-3-long
>> fftw-3-single
>> qrupdate
>> wgrib2
>
> These are all bogus because they only have a +gcc4X for the fortran
> compiler. The C/C++ code is still compiled with clang (or whichever is
> the default C compiler from MacPorts).

I'm curious where the consensus lies with respect to this difference.

I've taken the approach (in the ports I manage with said variants)
that +gccNN means "please ignore all other compilers and use this
(family) for everything." Other ports, like those above and some
others, use the +gccNN flag just to enable fortran bindings, an choose
to only use the gccNN port's gfortran as described by Sean above.

Any thoughts / best practices for this? I'm in favor of the all-in
approach when a compiler variant is provided, but perhaps there are
counter-examples where this is broken?

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

Usage reporting status?

[Eric A. Borisch]

What ever became of doing some basic port usage statictics (based on
downloads / attempts from pakages.macports.org, perhaps)? I recall
there was some activity (last summer?) to put together some
reporting...

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

Re: New PPL breaks gcc4*. (Also: trac e-mail notifications missing/delayed?)

[Eric A. Borisch]

On Mon, Jul 2, 2012 at 12:02 PM, Eric A. Borisch  wrote:
> I don't seem to be getting (CC:) e-mails from trac, either, FWIW.
> Perhaps they're just delayed.

Scratch that; one just showed up.

The gcc issue remains.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

New PPL breaks gcc4*. (Also: trac e-mail notifications missing/delayed?)

[Eric A. Borisch]

Just wanted to raise the visibility on this one.
https://trac.macports.org/ticket/35057

Most (all?) gcc4* ports expect PPL version 0.(>=11); The new PPL is
version 1.0 (gcc4* builds break) with a new dylib (rev-upgrade hits,
forces a re-build doomed to fail).

I don't seem to be getting (CC:) e-mails from trac, either, FWIW.
Perhaps they're just delayed.

 -Eric
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [93767] trunk/dports/python/py-spyder

[Eric A. Borisch]

On Wednesday, May 30, 2012, Jeremy Lavergne wrote:

> > They won't be changed every time they upgrade; python27 will point to
> > ~/.spyder2-27, and 26 to ~/.spyder2-26
>
> Sorry, I meant every major upgrade of Python. When upgrading from python26
> to python27 a user will (probably unexpectedly since an upgrade like that
> would have gobs of python-related package noise and miss the log messages)
> lose their preferences--unless they're watching the pages of MacPorts
> output.
>
> > If people installed both (for testing codes with 26 and 27, for
> > example) previously, both would run only one (26 or 27, depending on
> > which made the preference files) python in the interactive
> > interpreters... This seems worse than having two preference
> > directories.
>
> I'm not familiar with spyder, so I defer use cases all back to you :-) I'm
> just asking if it's a typical use case, as it seems odd to me to have
> version-specific preferences and the associated upgrade headaches thrown
> upon everyone unless it is deemed necessary.
>
> You're the authority on saying it's a good idea :-) just want to
> understand that it is typical to run two different versions at the same
> time, that most users benefit from this.
>

Perhaps a +multiversion variant and setting the pyNN-spyder variants to
conflict with each other unless installed with +multiversion (which would
enable the separate preference directories.)

Spyder is a development environment, so I don't think having multiple
versions is too far-fetched. And the step of having to rename the directory
for a new version just might remind the user to double-check that settings
are correct for the new version...

-- 
Eric A. Borisch
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: [93767] trunk/dports/python/py-spyder

[Eric A. Borisch]

On Wed, May 30, 2012 at 12:45 PM, Jeremy Lavergne
 wrote:
>> py-spyder: Upgrade to 2.1.10; Move user preferences dir from ~/.spyder2 to 
>> ~/.spyder2-NN to make -26 and -27 flavors coexist nicely.
>
> This makes me uneasy. Everyone's preferences are now broken, and will be 
> every time they upgrade.
>
> Are multiple versions of py-spyder typically installed concurrently?

They won't be changed every time they upgrade; python27 will point to
~/.spyder2-27, and 26 to ~/.spyder2-26

If people installed both (for testing codes with 26 and 27, for
example) previously, both would run only one (26 or 27, depending on
which made the preference files) python in the interactive
interpreters... This seems worse than having two preference
directories.

 -Eric
-- 
Eric A. Borisch
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Re: py-h5py port issues with HDF5 version

[Eric A. Borisch]

On Tue, May 15, 2012 at 8:32 AM, Jeremy Lavergne
 wrote:
>> I tried
>> uninstalling and re-installing h5py, which used to work, but now that
>> we have binary packages, this no longer works
>
> `port -s ...` will make MacPorts work with sources only, rather than pulling 
> binary packages if available.
>
> Also, the library version mismatch shouldn't be an issue if the library 
> numbers are done properly (that is, they're compatible 1.8.8 and 1.8.9). If 
> it works by just setting the environment variable, then perhaps the package 
> should be bundled so that the binary is in libexec/ and a wrapper script 
> takes its place in bin/.

HDF5 takes a very conservative approach and checks compiled with /
running with version numbers at launch. It's software designed for
maintaining huge and potentially expensive / impossible to replace
scientific data, so they go with error out and print a message rather
than any tiny chance of cross-version issues. These errors can be
suppressed and it will run, as mentioned in the original message to
the list. This isn't the recommended mode of operation.

I'm about to revbump the portfile, which will fix these issues, as the
binary package will get recompiled against the new hdf5-18. I try to
keep on top if it (the hdf5-18 portfile change happened 48 hours ago
or so) but I am still recovering from jet lag...

 - Eric

-- 
Eric A. Borisch
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev