Yeah, this perl situation drives me crazy. I always wind up accidentally
installing 5.12 when I don't want to, and I still have yet to install 5.18,
although I am looking at how to build that. I'm with Daniel. We should just
keep the latest stable(5.18) and p5-* and keep the perl5-XXs around if you
I think that's what we're getting at. I may have been imprecise in how I
described it. I think we should have sone method to download and build some
of the tools we need and set them aside.
Mark
On Monday, July 8, 2013, Clemens Lang wrote:
> Hi,
>
> On Mon, Jul 08, 2013 at 07:19:38PM -0400, Ma
Hi,
On Mon, Jul 08, 2013 at 07:19:38PM -0400, Mark Anderson wrote:
> I kind of like the idea Ryan was talking about where we build using a
> portfile or something, and then squirrel the files away someplace away
> from the main install.
So we have to create a script that will relocate an installe
Yeah, I've actually currently built against the MacPorts Tcl. I don't
recommend it, but it was the easiest way to rebuild between developer
seeds. I kind of like the idea Ryan was talking about where we build using
a portfile or something, and then squirrel the files away someplace away
from the ma
On Sun, Jul 7, 2013 at 7:20 PM, Mojca Miklavec wrote:
> On Sun, Jul 7, 2013 at 5:22 PM, Bradley Giesbrecht wrote:
>> On Jul 7, 2013, at 5:15 AM, Mojca Miklavec wrote:
>>
>>> But I still need a way to specify the path somewhere: be
>>> it by hardcoding it in Gate or by providing a function in the
>>
Hi all,
I submitted this ticket a month ago about mpich fortran support:
https://trac.macports.org/ticket/39428
It hasn't even had the owner assigned by a committer. Can someone please
take a look? I submitted a patch to fix the (fairly simple) issue, so if it
looks ok it can just be committed,
On Jul 7, 2013, at 11:00 PM, Ryan Schmidt wrote:
> In fact, just naively making MacPorts base link with libraries provided by
> MacPorts ports would be brittle and unwise, e.g. if MacPorts base used a
> library from MacPorts cURL, and the user deactivated MacPorts cURL, then
> MacPorts wouldn't
On Jul 2, 2013, at 5:29 PM, Dan Ports wrote:
> This seems like yet another instance of the current perl situation
> making it harder to maintain other ports.
yep
> Are we really getting enough benefit out of supporting multiple perl
> versions to make this worthwhile?
nope
On Jul 4, 2013, at
On Jul 8, 2013, at 4:35 AM, Johannes Kastl wrote:
> I got a mail that the ticket has been closed as fixed, but I see no
> change after
> port -d sync
> and
> port -d upgrade outdated
>
> Are the mirrors still syncing? Or what am I missing?
There's currently an issue with the primary rsync mirro
On Jul 8, 2013, at 10:44 AM, Jeremy Huddleston Sequoia
wrote:
>> do you have a reason why? We generally follow the upstream 'stable' release
>> unless we've got a specific reason not to...
>
> Well that wasn’t the case while 5.14 was stable upstream nor while 5.16 was
> stable upstream.
and
On Jul 8, 2013, at 7:17 AM, Daniel J. Luke wrote:
> On Jul 5, 2013, at 2:57 AM, Jeremy Huddleston Sequoia
> wrote:
>> TBH, I’d rather switch to 5.16 while 5.18 matures in MacPorts ...
>
> do you have a reason why? We generally follow the upstream 'stable' release
> unless we've got a specifi
On Jul 5, 2013, at 2:57 AM, Jeremy Huddleston Sequoia
wrote:
> TBH, I’d rather switch to 5.16 while 5.18 matures in MacPorts ...
do you have a reason why? We generally follow the upstream 'stable' release
unless we've got a specific reason not to...
--
Daniel J. Luke
On Sun, Jul 07, 2013 at 09:03:44PM -0500, Ryan Schmidt wrote:
> > +ARCHFLAGS=-arch i386 -arch x86_64
> > +CFLAGS+=${ARCHFLAGS}
> > +SHLIB_LDFLAGS+=${ARCHFLAGS}
> This is an Intel-only feature? Or was this commit unrelated /
> unintended?
Unintended commit. Feel free to revert it, if you're faster
On 2013-7-8 18:39 , Mojca Miklavec wrote:
> On Sun, Jul 7, 2013 at 11:22 PM, Joshua Root wrote:
>>
>> Be careful not to conflate "free", "permissive", and "distributable".
>
> Like Ryan said: I have no idea what each term means and I'm not an
> expert (and don't want to be).
Getting this stuff wr
Hi all,
I there a chance that somebody would have a closer look at Ticket #35141 ?
This ticket seems to be around for a while already. However, py-scipy is an
important dependency of a port I am trying to maintain (py-obspy) and I would
like to keep python26 as well.
From what I understand,
On Sun, Jul 7, 2013 at 11:22 PM, Joshua Root wrote:
>
> Be careful not to conflate "free", "permissive", and "distributable".
Like Ryan said: I have no idea what each term means and I'm not an
expert (and don't want to be).
> This is certainly not as permissive as MIT or BSD, and it looks to me
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/5/13 11:56 PM Lawrence Velázquez wrote:
> On Jul 5, 2013, at 4:24 PM, Johannes Kastl
> wrote:
>
>> I thought I would not need to create a ticket. ;-)
>
> Tickets are almost always better for this sort of thing, as they
> are easily queried, ass
On Mon, Jul 8, 2013 at 4:44 AM, Ryan Schmidt wrote:
>
> ${workpath}/${distname} is more simply known as ${worksrcpath}.
Thank you, fixed.
In the meantime I also tried to incorporate all the different versions
into a single port
https://trac.macports.org/browser/users/mojca/ports/science/geant
18 matches
Mail list logo
