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

Rainer Müller <rai...@macports.org> writes: > On 2016-11-01 19:23, Sean Farley wrote: >> Lawrence Velázquez <lar...@macports.org> writes: >> >>> You should set your repository's user.email to your MacPorts email address. >> >> Is this

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

Lawrence Velázquez writes: > You should set your repository's user.email to your MacPorts email address. Is this really necessary? I've seen mention of a mailmap but that hardly seems like a big enough reason to force us to change user.email. I'm pushing back on this, by

Re: GitHub desired workflow...

Lawrence Velázquez <lar...@macports.org> writes: >> On Oct 31, 2016, at 5:50 PM, Sean Farley <s...@macports.org> wrote: >> >> I'm not sure I agree with attempting to modify the git repo at all. For >> example, what if I'm in the middle of bisecting and ne

Re: Working with Git

Ryan Schmidt writes: > I don't want to understand git's theory or to be given lots of options > amongst which to choose; I just want to be told how to get my work done. I had a thoroughly good chuckle reading this. It is the number one sin of the design of git, IMHO.

Re: GitHub desired workflow...

"Eric A. Borisch" writes: > Thanks for all the hard work with this transition! I'm sure once we're all > "over the hump" we'll look back and wonder why we waited so long. > > Just so I'm clear on this, is the desired approach for each committer to: > > == setup == > 1)

Re: Objection to restoring deprecated Python subports

Lawrence Velázquez writes: > Fred Wright recently opened several tickets that suggest restoring > several Python subports that were deprecated and moved to the Python > graveyard a long time ago. > > https://trac.macports.org/ticket/52636 >

Re: port:lapack useful?

Takeshi Enomoto writes: > Dear David, > >> I just noticed that you created a port lapack (including BLAS) in r146856. >> Is this really useful? We already have the ATLAS port which provides BLAS >> and LAPACK; the OpenBLAS port which provides exactly the same

Re: [152202] trunk/dports/devel

Ryan Schmidt writes: >> On Aug 31, 2016, at 3:59 PM, s...@macports.org wrote: >> >> Revision >> 152202 >> Author >> s...@macports.org >> Date >> 2016-08-31 13:59:44 -0700 (Wed, 31 Aug 2016) >> Log Message >> >> folly: add new port >> Added Paths >> >> •

Re: Rev bumping mpi dependents

Joshua Root <j...@macports.org> writes: > On 2016-7-21 09:24 , Brandon Allbery wrote: >> On Wed, Jul 20, 2016 at 7:21 PM, Sean Farley <s...@macports.org >> <mailto:s...@macports.org>> wrote: >> >> OpenMPI just released 2.0 which will change the

Rev bumping mpi dependents

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

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

Rainer Müller writes: > On 2016-07-08 10:34, Clemens Lang wrote: >> - On 8 Jul, 2016, at 07:59, s...@macports.org wrote: >> >>> [150004] trunk/dports/python/py-ipython/Portfile >>> Revision 150004 >>> Author s...@macports.org >>> Date 2016-07-07 22:59:39 -0700 (Thu, 07

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

David Evans <dev...@macports.org> writes: > On 3/14/16 4:38 PM, Sean Farley wrote: >> Thanks for following through! >> >> libgit2 makes so many breaking api changes that its subprojects (pygit2, >> libgit2-glib, etc.) should really be part of the same rep

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

David Evans <dev...@macports.org> writes: > On 3/14/16 10:53 AM, Sean Farley wrote: >> >> David Evans <dev...@macports.org> writes: >> >>> On 3/11/16 2:55 PM, s...@macports.org wrote: >>>> Revision >>>> 146550 &

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

David Evans writes: > On 3/11/16 2:55 PM, s...@macports.org wrote: >> Revision >> 146550 >> Author >> s...@macports.org >> Date >> 2016-03-11 14:55:34 -0800 (Fri, 11 Mar 2016) >> >> >> Log Message >> >>

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

Joshua Root <j...@macports.org> writes: > On 2016-1-15 05:51 , Sean Farley wrote: >> >> Joshua Root <j...@macports.org> writes: >> >>>> Revision: 144621 >>>> https://trac.macports.org/changeset/144621 >>>> Author:

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

Joshua Root writes: >> Revision: 144621 >> https://trac.macports.org/changeset/144621 >> Author: sean at macports.org >> Date: 2016-01-13 23:29:24 -0800 (Wed, 13 Jan 2016) >> Log Message: >> --- >> py-numpy: numpy needs fortran, so require it > > We've

Re: Survey: How do you commit?

Ryan Schmidt writes: > Quick survey for committers: > > How do you commit to the MacPorts Subversion repository? > > Using a Subversion working copy and "svn commit"? > Using a Git clone and git-svn? > Some other method? hgsubversion :-) > Do you have any complaints

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

Sean Farley <s...@macports.org> writes: > Ryan Schmidt <ryandes...@macports.org> writes: > >>> On Dec 12, 2015, at 11:31 AM, s...@macports.org wrote: >>> >>> Revision >>> 143330 >>> Author >>> s...@macports.org &

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

Ryan Schmidt writes: >> On Dec 12, 2015, at 11:31 AM, s...@macports.org wrote: >> >> Revision >> 143330 >> Author >> s...@macports.org >> Date >> 2015-12-10 16:21:17 -0800 (Thu, 10 Dec 2015) >> Log Message >> >> docker-machine: add bash variant and fix build; closes

Re: New Mac OS Forge administrator

Ryan Schmidt writes: > Dear MacPorts users and developers, > > I'm pleased finally to be able to tell you that I have been hired to be your > new Mac OS Forge administrator. I have been involved in improving MacPorts > for years as a committer and as a manager, and

Re: Owner of MacPorts account on GitHub

Clemens Lang <c...@macports.org> writes: > Hi, > > - On 12 Nov, 2015, at 19:48, Sean Farley s...@macports.org wrote: > >> Sure, it could include Jira, HipChat, and Bamboo, if you want. I only >> said 'lost cause' because GitHub is so popular for open source

Re: Owner of MacPorts account on GitHub

t perfect yet, just so that we can >> follow the changes? (I can offer to run a script for incremental >> updates on my server if there is a need for that.) > > We will get the existing infrastructure back up and running soon. Please bear > with us a little while longer. &

Re: Owner of MacPorts account on GitHub

Clemens Lang writes: > Hi, > > - On 11 Nov, 2015, at 11:03, Rainer Müller rai...@macports.org wrote: > >> On 2015-11-11 05:57, Mojca Miklavec wrote: >>> Is there any chance that we put mirrors of the SVN repository there? >>> >>> I would suggest to use these for

Re: Persistent copy of a [git] repository

Mojca Miklavec writes: > Reposting the question ... I would be grateful for some feedback (and > someone who could help me move the code to the core or some PortGroup > in case that the approach sounds reasonable enough). Have we looked into wrapping git/hg commands so that

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

Mojca Miklavec writes: > Hi, > > I would really appreciate it if I could see the complete configure > command already in verbose mode (port -v configure), not just debug > mode (port -d configure). The same applies to build/make, but usually > that one doesn't contain so

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

Ryan Schmidt writes: >> On Sep 9, 2015, at 4:27 PM, s...@macports.org wrote: >> >> Revision >> 140114 >> Author >> s...@macports.org >> Date >> 2015-09-09 14:27:38 -0700 (Wed, 09 Sep 2015) >> Log Message >> >> julia: fix livecheck to not include release candidates >

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

Ryan Schmidt writes: > On Sep 9, 2015, at 4:27 PM, s...@macports.org wrote: > >> Revision >> 140120 >> Author >> s...@macports.org >> Date >> 2015-09-09 14:27:44 -0700 (Wed, 09 Sep 2015) >> Log Message >> >> mercurial-devel: update to newest commit > >> Modified:

Upgrading rust to 1.2.0

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

Re: llvm-3.7 release and OpenMP

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

Re: llvm-3.7 release and OpenMP

Jeremy Huddleston Sequoia <jerem...@macports.org> writes: >> On Sep 3, 2015, at 10:32, Sean Farley <s...@macports.org> wrote: >> >> >> Jeremy Huddleston Sequoia <jerem...@macports.org> writes: >> >>>> On Sep 3, 2015, at 09:

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

Oliver Angélil molofi...@gmail.com writes: The following ports are currently installed: netcdf @4.3.3.1_2+dap+netcdf4 (active) Please comment on the issue page and not the mailing list. Thanks. ___ macports-dev mailing list

Re: El Capitan Buildbot

Ryan Schmidt ryandes...@macports.org writes: On Aug 16, 2015, at 4:21 PM, Sean Farley wrote: Ryan Schmidt writes: On Aug 16, 2015, at 14:49, Sean Farley wrote: Since the public beta of El Capitan has been out for a while, is there any chance we can get a buildbot set up so that we're

Re: El Capitan Buildbot

Jeremy Lavergne jer...@lavergne.gotdns.org writes: While the beta is a public release, it is under NDA. Don’t blog, post screen shots, tweet, or publicly post information about the public beta software, and don't discuss the public beta software with or demonstrate it to others who are

Re: El Capitan Buildbot

Jeremy Lavergne jer...@lavergne.gotdns.org writes: That's a good idea. We could actually schedule downtime for the Yosemite box to be cloned then :-o (we could clear out all artifacts to possibly speed up the process). But once it's released: how quickly could someone update the OS on

Re: El Capitan Buildbot

Ryan Schmidt ryandes...@macports.org writes: On Aug 16, 2015, at 14:49, Sean Farley wrote: Since the public beta of El Capitan has been out for a while, is there any chance we can get a buildbot set up so that we're ready for the release? In the past, we haven't set up a build server

El Capitan Buildbot

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

Re: [138907] trunk/dports/devel

Ryan Schmidt ryandes...@macports.org writes: On Jul 22, 2015, at 4:33 PM, s...@macports.org wrote: Revision 138907 Author s...@macports.org Date 2015-07-22 14:33:13 -0700 (Wed, 22 Jul 2015) Log Message editorconfig-core-c: add new port for editor config files Added Paths •

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

Ryan Schmidt ryandes...@macports.org writes: On Apr 25, 2015, at 11:53 AM, petr wrote: On 25 Apr 2015, at 17:49, Lawrence Velázquez wrote: On Apr 25, 2015, at 5:49 AM, petr wrote: To my understanding the +clang3{0,1,2} refer to clang-3.{0,1,2} respectively. Yup. These clang

Re: Current best practice to select GCC compiler in Portfile

David Strubbe writes: Hi Rainer, Sean did indeed add the default_variants to the compilers portgroup in the last month or two. Perhaps you were trying before then. Thanks for following up, David :-) @Rainer, yes, it should definitely handle default_variants. Please let me know otherwise

Python PortGroup environment variables

Is there any reason that the configure.env variables are automatically copied to the build and destroot phases? I ask because most python packages do not use the traditional './configure; make; make install' method and instead set things like the prefix and whatnot in the build or destroot phase.

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

Joshua Root writes: Revision: 130954 https://trac.macports.org/changeset/130954 Author: sean at macports.org Date: 2015-01-03 22:01:06 -0800 (Sat, 03 Jan 2015) Log Message: --- py-numpy: refactor port to use compilers portgroup This is a big refactor that cleans

Re: [130159] trunk/dports/python

Lawrence Velázquez writes: On Jan 2, 2015, at 3:22 AM, Sean Farley s...@macports.org wrote: I just saw that you pushed a few conflicts to my stack (py-netcdf4, py-mdb-toolkit, and py-nibabel). This actually helped me realize that my graveyard changes had an off-by-one error :-) The ones I

Re: [130159] trunk/dports/python

Lawrence Velázquez writes: On Dec 31, 2014, at 8:57 PM, Sean Farley s...@macports.org wrote: Yep, that looks like the same list I found. How did you search? I just used regex + codesearch. `grep` and `port info` :) I just saw that you pushed a few conflicts to my stack (py-netcdf4, py-mdb

Re: [130159] trunk/dports/python

Lawrence Velázquez writes: On Jan 2, 2015, at 3:38 AM, Sean Farley s...@macports.org wrote: Ok, cool. I only have py-asciitable in my stack now. If you want to finish the ones that aren't py-numpy or py-scipy, then fine by me :-) Otherwise, I'll check on them tomorrow. Okay, I just did

Re: [130159] trunk/dports/python

Michael Dickens writes: I ment to send this to macports-dev, not macports-changes. So, echoing what Josh just wrote: On Wed, Dec 31, 2014, at 11:08 AM, Michael Dickens wrote: py*-cython is still used by py*-scipy and py*-numpy (edit: among other ports). If we're ready to disable

Re: [130159] trunk/dports/python

Lawrence Velázquez writes: On Dec 31, 2014, at 3:11 PM, Lawrence Velázquez lar...@macports.org wrote: I'll fix the Cython situation. Dependents of py{24,25,31,32}-cython retired: http://trac.macports.org/log?rev=130551stop_rev=130546 py{26,33}-cython resurrected:

Re: [130159] trunk/dports/python

Sean Farley writes: Lawrence Velázquez writes: On Dec 31, 2014, at 3:11 PM, Lawrence Velázquez lar...@macports.org wrote: I'll fix the Cython situation. Dependents of py{24,25,31,32}-cython retired: http://trac.macports.org/log?rev=130551stop_rev=130546 py{26,33}-cython resurrected

Re: [130159] trunk/dports/python

Lawrence Velázquez writes: On Dec 31, 2014, at 6:53 PM, Lawrence Velázquez lar...@macports.org wrote: On Dec 31, 2014, at 6:36 PM, Sean Farley s...@macports.org wrote: I'll also go ahead and move those to the graveyard tonight. Since tomorrow's a holiday for me, I should have the time

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

Ryan Schmidt writes: On Dec 23, 2014, at 6:42 PM, s...@macports.org wrote: Revision 129987 Author s...@macports.org Date 2014-12-23 16:42:44 -0800 (Tue, 23 Dec 2014) Log Message boost: update to 1.57; closes #46156 Modified: trunk/dports/devel/boost/Portfile (129986 = 129987) -#

Re: Adding MPI back to Boost

Anyone opposed to me pushes the proposed changes and marking them fixed? Sean Farley writes: Ryan Schmidt writes: On Dec 14, 2014, at 12:21 PM, Sean Farley wrote: Ryan Schmidt writes: So, this would add clang33, clang34, clang35 variants, for example? But these would be different from

Adding MPI back to Boost

So, I've added support into the compilers portgroup for working with the compiler.blacklist variable but that doesn't fix the issue that Ryan tried to fix with r125939: https://trac.macports.org/changeset/125939 It seems instead that the fix is just to remove the gcc variants: mpi.setup -gcc

Re: Adding MPI back to Boost

Mark Moll writes: On Dec 14, 2014, at 2:28 AM, Sean Farley s...@macports.org wrote: So, I've added support into the compilers portgroup for working with the compiler.blacklist variable but that doesn't fix the issue that Ryan tried to fix with r125939: https://trac.macports.org

Re: Adding MPI back to Boost

Ryan Schmidt writes: On Dec 14, 2014, at 2:28 AM, Sean Farley wrote: So, I've added support into the compilers portgroup for working with the compiler.blacklist variable but that doesn't fix the issue that Ryan tried to fix with r125939: https://trac.macports.org/changeset/125939

Re: Adding MPI back to Boost

Ryan Schmidt writes: On Dec 14, 2014, at 11:41 AM, Sean Farley wrote: Ryan Schmidt writes: On Dec 14, 2014, at 2:28 AM, Sean Farley wrote: So, I've added support into the compilers portgroup for working with the compiler.blacklist variable but that doesn't fix the issue that Ryan

Re: Adding MPI back to Boost

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

GitHub Portgroup

I have a port (julia) that extracts as julia-0.3 which breaks the globbing done by the Portgroup: ${github.author}-${github.project}-*. Would it make sense to change this to *${github.project}? Or am I missing something? ___ macports-dev mailing list

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

Ryan Schmidt writes: On Nov 13, 2014, at 6:16 PM, s...@macports.org wrote: Revision 128125 Author s...@macports.org Date 2014-11-13 16:16:29 -0800 (Thu, 13 Nov 2014) Log Message julia: use a release tarball to avoid git submodules Modified Paths •

Re: Please start commit message with port name.

Vincent Habchi writes: Ciao Petr, I'd like to propose to start commit messages with the port name. This helps very much to read them for example in the Timeline. For example: https://trac.macports.org/changeset/127794 -- Correct various bugs. Bump to revision 1.

Re: need a help with PortGroup compilers

Takeshi Enomoto writes: I am developing a port that relies on makefiles. I need to set fortran and c++ compilers so I use PortGroup mpi 1.0. ${configure.cxx} has a default value, but ${configure.f90} is empty. This is a good question. And I wish I could solve this problem easier. As far

Re: Getting the entire configure.cflags variable

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

Re: RFC: Drop PPC support

Takeshi Enomoto writes: Historically we officially support the current and previous Mac OS X release (while not doing anything to on-purpose break older releases / being willing to accept patches to make things work on older releases). If we are not going to change this policy, PPC is no

Getting the entire configure.cflags variable

This seems very odd but is there a variable that stores the complete string of what will eventually be CFLAGS in the environment (e.g. CFLAGS=foo ./configure --args) passed to a command? If you're like me, you're thinking: Of course there is, use configure.cflags! But that only holds a substring:

Re: Getting the entire configure.cflags variable

Ryan Schmidt writes: On Oct 2, 2014, at 3:25 PM, Sean Farley wrote: This seems very odd but is there a variable that stores the complete string of what will eventually be CFLAGS in the environment (e.g. CFLAGS=foo ./configure --args) passed to a command? If you're like me, you're

Re: Getting the entire configure.cflags variable

Ryan Schmidt writes: On Oct 2, 2014, at 4:10 PM, Lawrence Velázquez wrote: On Oct 2, 2014, at 5:08 PM, Sean Farley wrote: Ryan Schmidt writes: Unfortunately as far as I can tell the answer is no. Many variables are added to ${configure.cflags} right before the command is run and after

Re: mpi

vincent writes: Yes, atlas has a bunch of compiler variants. I would love for most or all of them to go away. But part of atlas needs fortran so it needs to deal with that at least. And I believe Vince argued that for atlas and other performance-critical scientific software it is

RFC: Renaming GCC ports and variants

Proposal: Since it seems that we are flat-out disallowing gcc being used as a C/C++ compiler, I think it's time to do some clean up of the code: 1) Rename gccXY to gcc-X.Y 2) Rename +gccXY variants to +gfortranXY 3) Start moving away from configure.compiler=macports-gcc* I think it's

RFC: Drop PPC support

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

Re: mpi

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

Re: RFC: Renaming GCC ports and variants

Ryan Schmidt writes: On Oct 1, 2014, at 12:48 PM, Sean Farley wrote: Proposal: Since it seems that we are flat-out disallowing gcc being used as a C/C++ compiler, I think it's time to do some clean up of the code: 1) Rename gccXY to gcc-X.Y As I proposed earlier, we might want

Re: RFC: Drop PPC support

Bradley Giesbrecht writes: On Oct 1, 2014, at 10:58 AM, Sean Farley s...@macports.org wrote: As discussed in the MPI thread, PPC is very old and is causing quite the development burden. I would be in favor of discussing how much effort we really want to spend supporting them (similar

Re: RFC: Renaming GCC ports and variants

Frank Schima writes: On Oct 1, 2014, at 12:26 PM, Sean Farley s...@macports.org wrote: Ryan Schmidt writes: On Oct 1, 2014, at 12:48 PM, Sean Farley wrote: Proposal: Since it seems that we are flat-out disallowing gcc being used as a C/C++ compiler, I think it's time to do some

Re: Recommendations for version numbers in port names

Lawrence Velázquez writes: Resurrecting this thread. Let's keep general renaming discussion here. Sure, sounds good. On Sep 16, 2014, at 5:22 PM, Ryan Schmidt ryandes...@macports.org wrote: It's been proposed on this list that we should rename MySQL ports e.g. mysql51 - mysql-5.1; this

Re: mpi

Ryan Schmidt writes: We've had multiple bug reports from users who had installed boost with one of the gcc variants. Either the build failed when using those variants, or the build of boost succeeded but then the build of another port that depends on boost failed. We attributed this to

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

Daniel J. Luke writes: On Aug 12, 2014, at 11:11 AM, Ryan Schmidt ryandes...@macports.org wrote: It's still not totally automatic: the developer still has to update the checksums, so if the developer is sufficiently aware that the checksums need to be updated, why can't the developer

Re: mpi

Ryan Schmidt writes: This creates the scenario of: does the port want the full suite of, for example, gcc (meaning both C and fortran) or just the fortran compiler. And which of these two strategies does the mpi portgroup employ? Both, that's why there is a 'require_fortran' variable.

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

Ryan Schmidt writes: On Sep 30, 2014, at 4:55 PM, Sean Farley wrote: As for this exact issue, it could be something as simple as a fallback test: if checksum doesn't match and revision is new: try downloading again write state so we don't download in an infinite loop That's

Re: mpi

Ryan Schmidt writes: On Sep 30, 2014, at 7:04 PM, Sean Farley wrote: This is pretty much was is done (modulo the blacklist). If I understand correctly, though, you want to remove gcc from being able to be used as a compiler? This would be a serious limitation. Removed as a C/C++/ObjC/ObjC

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

Ryan Schmidt writes: * It assumes the port's revision will be increased. That's not always necessary. Sometimes the only change in the distfile is the name of (or presence of) the enclosing directory, or there are only changes in comments or documentation files or other files that don't

Re: mpi

Ryan Schmidt writes: On Sep 30, 2014, at 8:08 PM, Sean Farley wrote: Ryan Schmidt writes: On Sep 30, 2014, at 7:04 PM, Sean Farley wrote: This is pretty much was is done (modulo the blacklist). If I understand correctly, though, you want to remove gcc from being able to be used

Re: mpi

Ryan Schmidt writes: On Sep 30, 2014, at 9:08 PM, Sean Farley wrote: Ryan Schmidt writes: The question, to me, is: why is it still not possible to distinguish foo+gcc and foo+clang in MacPorts? I'm not sure what you mean. Why can't all a port's variants be installed at the same time

Re: mpi

Lawrence Velázquez writes: On Sep 30, 2014, at 10:52 PM, Ryan Schmidt ryandes...@macports.org wrote: I understand the proposal, but I don't agree that we should implement it. It does seem like it would introduce a great deal of complexity to address what is clearly (to me, at least) an

Re: mpi

Ryan Schmidt writes: On Sep 30, 2014, at 9:25 PM, Sean Farley wrote: That's not what variants are for. That's what subports are for. Subports are trying to solve this but expose the implementation level too far up. Only one solution should exist to depending on a variant. Subports

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

Ryan Schmidt writes: That sounds right. What I'm attempting to improve (or, rather, stir up awareness) are the many steps that are manual. Being that stealth updates are infrequent, I usually forgot to check for them. I think A workflow I am trying to strive for (which maybe should be

Re: mpi

Ryan Schmidt writes: On Sep 30, 2014, at 10:35 PM, Sean Farley wrote: Lawrence Velázquez writes: On Sep 30, 2014, at 10:52 PM, Ryan Schmidt wrote: I understand the proposal, but I don't agree that we should implement it. It does seem like it would introduce a great deal of complexity

Re: mpi

Ryan Schmidt writes: On Sep 30, 2014, at 11:25 PM, Sean Farley wrote: Ryan Schmidt writes: On Sep 30, 2014, at 10:48 PM, Sean Farley wrote: Variants create a new node in the dependency DAG. Subports create a new node in the dependency DAG. There is no topological difference. The only

Re: RFC: Python maintenance policy

Brandon Allbery writes: On Tue, Sep 23, 2014 at 12:49 AM, Sean Farley s...@macports.org wrote: I actually have the back story for this from the last PyCon. Suffice to say, it's because of Python 3 screwing up the treatment of unicode strings. Huh. I'd assumed arm-twisting from Red Hat

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

Ryan Schmidt writes: On Sep 22, 2014, at 12:21 AM, dstru...@macports.org wrote: Revision 125581 Author dstru...@macports.org Date 2014-09-21 22:21:07 -0700 (Sun, 21 Sep 2014) Log Message abinit: temporarily include config.log in main log file for debugging buildbot configure

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

Ryan Schmidt writes: On Sep 22, 2014, at 1:27 AM, Sean Farley wrote: Ryan Schmidt writes: On Sep 22, 2014, at 12:21 AM, dstru...@macports.org wrote: Revision 125581 Author dstru...@macports.org Date 2014-09-21 22:21:07 -0700 (Sun, 21 Sep 2014) Log Message abinit: temporarily

Re: RFC: Python maintenance policy

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

Re: We have a spam problem

Frank Schima writes: Hi all, I just spent the last half hour closing about 40 spam tickets which arrived last night - most in a 15 minute period. We need to do something about the spam problem because it seems to be getting worse. I just tested creating a new account and only a simple

Re: Retiring Python 2.4 and 2.5

Frank Schima writes: On Sep 15, 2014, at 7:56 PM, Lawrence Velázquez lar...@macports.org wrote: I'm trying to adapt Ned Deily's patches for Yosemite[1] to the Python ports. Adapting them to all the Python 3.x ports was tedious enough, but now I've made it to Python 2.4 and 2.5. I feel

Re: Retiring Python 2.4 and 2.5

Lawrence Velázquez writes: On Sep 16, 2014, at 1:30 AM, Clemens Lang c...@macports.org wrote: If I were you, I'd set a timeout and if nobody argues that we should keep them for a good reason, delete them once the timeout has passed. Probably ask -users, too. I like this. While we're

Re: Non versioned ports

Vincent Habchi writes: Le 24 août 2014 à 18:53, Sean Farley s...@macports.org a écrit : Why not use the bitbucket port group? PortGroup bitbucket 1.0 bitbucket.setup petebunting rsgislib 52fb22e version 0.0.20140822 Uh, I tried that and it works (fetch okay

Re: Non versioned ports

Vincent writes: From the command line, you can use revsets: $ hg log -G -r 'date(2014-08-22)' On the MacPorts repo, that will result in a lot of changesets. For a portfile, you really must specify a commit hash. I suppose that’s what I did, but since you seem to master Mercurial much

Re: Non versioned ports

Lawrence Velázquez writes: On Aug 23, 2014, at 7:25 AM, Vincent vi...@macports.org wrote: However, I’ll have a look a ‘mercurial’ (unless someone out there is a guru of this yet-another-DRC and can advise me directly) to figure out if there is a way to specify a date as a revision. In

Re: new ports and maintainer

Daniel J. Luke writes: On Aug 9, 2014, at 3:11 PM, Sean Farley s...@macports.org wrote: In fact I've proposed combining openmaintainer and nomaintainer before. But would this actually get us anything useful? For one, it would save the manual work of reminding devs that forget

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

Ryan Schmidt writes: On Aug 11, 2014, at 10:32 AM, robitai...@macports.org wrote: Revision 123602 Author robitai...@macports.org Date 2014-08-11 08:32:31 -0700 (Mon, 11 Aug 2014) Log Message py-astropy: updated checksums following change in tar file Modified Paths •

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

Daniel J. Luke writes: On Aug 11, 2014, at 1:39 PM, Sean Farley s...@macports.org wrote: Anyone who had the previous file, including our automated systems, will now encounter a checksum mismatch. To fix this please follow the recipe for stealth updates: http://trac.macports.org/wiki

Re: new ports and maintainer

Ryan Schmidt writes: On Aug 8, 2014, at 11:48 PM, Sean Farley wrote: Ryan Schmidt writes: On Aug 8, 2014, at 10:59 PM, Ryan Schmidt wrote: port echo name:^p5- and maintainer:nomaintainer How would you produce that list if nomaintainer and openmaintainer were combined into a single

Re: new ports and maintainer

Daniel J. Luke writes: On Jul 25, 2014, at 7:21 AM, Ryan Schmidt ryandes...@macports.org wrote: On Jul 24, 2014, at 5:08 PM, Sean Farley wrote: The maintainer is supposed to hold the consolidated knowledge of that software as relates to building it within MacPorts, and may have very good

  1   2   3   4   >