On 2013-11-13 07:26 , Peter Danecek wrote:
>
> Hi all,
>
> I just submitted a new python port. It is documented to support all version
> from 2.4 to 3.x (I did not test all).
>
> I would tend to still include 2.6 (maintenance was stopped only few day ago),
> but not 2.4 and 2.5. Anyway, I won
On 2013-11-13 14:27 , Mark Moll wrote:
>
> On Nov 12, 2013, at 5:28 PM, Lawrence Velázquez wrote:
>
>> On Nov 12, 2013, at 4:43 PM, mm...@macports.org wrote:
>>
>>> Revision: 113226
>>> https://trac.macports.org/changeset/113226
>>> Author: mm...@macports.org
>>> Date: 2013-11-12 1
On 2013-11-13 10:20 , Lawrence Velázquez wrote:
> On Nov 12, 2013, at 3:57 PM, j...@macports.org wrote:
>
>> Revision: 113224
>> https://trac.macports.org/changeset/113224
>> Author: j...@macports.org
>> Date: 2013-11-12 12:57:39 -0800 (Tue, 12 Nov 2013)
>> Log Message:
>> -
On Nov 12, 2013, at 9:27 PM, Mark Moll wrote:
>
> On Nov 12, 2013, at 5:28 PM, Lawrence Velázquez wrote:
>
>> On Nov 12, 2013, at 4:43 PM, mm...@macports.org wrote:
>>
>>> Revision: 113226
>>>https://trac.macports.org/changeset/113226
>>> Author: mm...@macports.org
>>> Date: 20
On Nov 12, 2013, at 5:28 PM, Lawrence Velázquez wrote:
> On Nov 12, 2013, at 4:43 PM, mm...@macports.org wrote:
>
>> Revision: 113226
>> https://trac.macports.org/changeset/113226
>> Author: mm...@macports.org
>> Date: 2013-11-12 13:43:58 -0800 (Tue, 12 Nov 2013)
>> Log Message:
>
On Nov 12, 2013, at 4:43 PM, mm...@macports.org wrote:
> Revision: 113226
> https://trac.macports.org/changeset/113226
> Author: mm...@macports.org
> Date: 2013-11-12 13:43:58 -0800 (Tue, 12 Nov 2013)
> Log Message:
> ---
> py-graph-tool: apparently is not part of libstdc++
On Nov 12, 2013, at 3:57 PM, j...@macports.org wrote:
> Revision: 113224
> https://trac.macports.org/changeset/113224
> Author: j...@macports.org
> Date: 2013-11-12 12:57:39 -0800 (Tue, 12 Nov 2013)
> Log Message:
> ---
> python27: version bump to 2.7.6
>
> Modified Paths:
In article ,
Peter Danecek wrote:
> Python 2.6 's last bug fix release was only few days ago, and it is still
> found around in production, so for testing it may make sense. And, there are
> as still few modules available only for py26. Python 3.1 is probably not used
> a lot (so okay), but ag
On Tue, Nov 12, 2013 at 10:52:20PM +0100, Peter Danecek wrote:
> I tried to run in trace mode, however, I have not installed base from
> trunk, so I am not sure if it is already reporting correctly.
If it doesn't outright crash or fail to build, it might be better than
nothing, but trace mode in 2
Hi all,
I tried to respect the recommendations here and this is what I came up with:
http://trac.macports.org/ticket/41337
I tried to run in trace mode, however, I have not installed base from trunk, so
I am not sure if it is already reporting correctly. It would report to a
missing libgcc de
On Nov 12, 2013, at 21:51 , Frank Schima wrote:
> I don't think we have a stated policy. Personally, I would not even add a
> python 26, 31 or 32 versions unless you need it or someone requests one. Why
> support anything but the current versions of python for a new port?
Well, in this case s
On Nov 12, 2013, at 1:48 PM, Peter Danecek wrote:
> On Nov 12, 2013, at 21:41 , "Jeremy Lavergne"
> wrote:
>
>> To avoid creating pyXY-pyshp, you'd leave out XY in python.versions. You
>> want to avoid 24 and 25 for your goal so python.versions should only have 26
>> 27 31 32 33 34.
> Yes,
On Nov 12, 2013, at 21:41 , "Jeremy Lavergne"
wrote:
> To avoid creating pyXY-pyshp, you'd leave out XY in python.versions. You want
> to avoid 24 and 25 for your goal so python.versions should only have 26 27 31
> 32 33 34.
Yes, I intentionally left the 2 older versions around as reminder. I
To avoid creating pyXY-pyshp, you'd leave out XY in python.versions. You
want to avoid 24 and 25 for your goal so python.versions should only have
26 27 31 32 33 34.
On Tue, 12 Nov 2013 15:26:20 -0500, Peter Danecek
wrote:
Anyway, I wonder if there is a clearly defined policy on which Py
Hi all,
I just submitted a new python port. It is documented to support all version
from 2.4 to 3.x (I did not test all).
I would tend to still include 2.6 (maintenance was stopped only few day ago),
but not 2.4 and 2.5. Anyway, I wonder if there is a clearly defined policy on
which Python v
Sorry I think I was confused. The ports are indeed uninstalled despite the
errors and warnings.
David
On Tue, Nov 12, 2013 at 1:41 AM, Joshua Root wrote:
> If they're not uninstalling that would be a bug in base. The files are
> meant to be uninstalled and the registry entry removed regardless
In general, I think you're better off just doing:
{{{
configure.ld_archflags
}}}
unless you are intentionally using muniversal but not allowing building
as universal. If you're not building as universal,
then configure.ld_archflags should contain just a single arch setting,
so this would be one
Thanks. Well, let us suppose I am not concerned with building universal for
time being: then it sounds like
configure.ld_archflags-delete -arch ${arch}
is the appropriate approach for gfortran, since -m32/-m64 are preserved in
the LDFLAGS. Right?
David
On Tue, Nov 12, 2013 at 10:55 AM, Michael
On Nov 12, 2013, at 9:20 AM, Ryan Schmidt wrote:
>
> On Nov 12, 2013, at 09:04, mm...@macports.org wrote:
>
>> Revision
>> 113214
>> Author
>> mm...@macports.org
>> Date
>> 2013-11-12 07:04:05 -0800 (Tue, 12 Nov 2013)
>> Log Message
>>
>> py-graph-tool: add missing build dependency for autoge
Hi David - gfortran, and non-Apple GCC in general, uses -m32 and -m64
to build for whatever the host arch is. So, if the host computer is a
PowerPC ("PPC"), then -m32 will build for 32-bit PPC ("ppc");
similarly, -m64 will build for 64-bit PPC ("ppc_64"); you won't be able
to cross-compile for Int
>
> I'm saying that if the user sets build_arch to i386 in macports.conf,
> adding '-arch i386' to LDFLAGS is one of the ways that we tell the build
> system to build for i386 and not for (say) x86_64 which is the default
> on recent systems. So if you don't do that, you may need to do something
>
On Nov 12, 2013, at 09:04, mm...@macports.org wrote:
> Revision
> 113214
> Author
> mm...@macports.org
> Date
> 2013-11-12 07:04:05 -0800 (Tue, 12 Nov 2013)
> Log Message
>
> py-graph-tool: add missing build dependency for autogen.sh
> Modified Paths
>
> • trunk/dports/python/py-graph-too
Am 11.11.2013 20:08, schrieb Mojca Miklavec:
On Sun, Nov 10, 2013 at 12:04 PM, Titus von Boxberg wrote:
Without having a system here to test my suggestions, you might be able to
- configure tiff to not define this type name (or define it correctly in the
sense of portability and compatibility, a
On 11/11/13 1526 , Ryan Schmidt wrote:
On Nov 11, 2013, at 08:20, Mark Evenson wrote:
Sure: my TCL fu is not that great, so I always a little to
hesitant
[…]
It should just be:
if {${os.platform} eq "darwin" && ${os.major} >= 11} {
configure.cflags-append -Wl,-no_pie
}
This code
24 matches
Mail list logo
