On Sep 1, 2009, at 15:20, narf...@macports.org wrote:
Revision: 56717
http://trac.macports.org/changeset/56717
Author: narf...@macports.org
Date: 2009-09-01 13:20:30 -0700 (Tue, 01 Sep 2009)
Log Message:
---
Updated to 0.7701.
Modified Paths:
--
On Sep 1, 2009, at 22:37, j...@macports.org wrote:
Revision: 56777
http://trac.macports.org/changeset/56777
Author: j...@macports.org
Date: 2009-09-01 20:37:21 -0700 (Tue, 01 Sep 2009)
Log Message:
---
add python31 portgroup
Added Paths:
---
On Sep 1, 2009, at 19:26, vin...@macports.org wrote:
Revision: 56752
http://trac.macports.org/changeset/56752
Author: vin...@macports.org
Date: 2009-09-01 17:26:55 -0700 (Tue, 01 Sep 2009)
Log Message:
---
optipng: workaround for problem with MacPorts 1.8.0, which adds
On Sep 1, 2009, at 19:05, narf...@macports.org wrote:
Revision: 56741
http://trac.macports.org/changeset/56741
Author: narf...@macports.org
Date: 2009-09-01 17:05:02 -0700 (Tue, 01 Sep 2009)
Log Message:
---
Added missing dependency.
If you want to make whitespace
On 2009-09-02 01:57:27 -0500, Ryan Schmidt wrote:
They do point out indirectly that not all software supports this
configure argument. For software that doesn't, your solution is
fine. But I would not characterize it as a problem with MacPorts to
be worked around; rather, it's simply a
On Sep 2, 2009, at 03:39, Vincent Lefevre wrote:
The GNU Coding Standards don't mention --disable-dependency-tracking
because it is not an option universally recognized. In fact, this is
a specific option defined by automake. Software not based on automake
probably don't have such an option.
On Sep 2, 2009, at 04:45, illogic...@macports.org wrote:
Revision: 56794
http://trac.macports.org/changeset/56794
Author: illogic...@macports.org
Date: 2009-09-02 02:45:30 -0700 (Wed, 02 Sep 2009)
Log Message:
---
Build libspectre without documentation, to avoid x11
On 2009-09-02 08:33 , Ryan Schmidt wrote:
This doesn't seem right. Besides the obvious point that Markus did not
commit this portgroup and it is not 2007, does it make sense for
portgroups to be marked as copyrighted by a particular person? We
don't do that for portfiles. Some of the
On Snow Leopard, we build x86_64 by default. But there are some ports,
e.g. wine, that cannot build 64-bit, so they force themselves to build
32-bit instead. But that means all the dependencies must also be 32-
bit, or 32-/64-bit universal. So it seems like it should probably be
our
On Snow Leopard, we build x86_64 by default. But there are some
ports, e.g. wine, that cannot build 64-bit, so they force themselves
to build 32-bit instead. But that means all the dependencies must
also be 32-bit, or 32-/64-bit universal. So it seems like it should
probably be our
On Snow Leopard, we build x86_64 by default. But there are some
ports, e.g. wine, that cannot build 64-bit, so they force
themselves to build 32-bit instead. But that means all the
dependencies must also be 32-bit, or 32-/64-bit universal. So it
seems like it should probably be our
On Sep 2, 2009, at 08:26, Jeremy Lavergne wrote:
I guess there are several ports that will not work 64-bit, we just
haven't come across them yet. I imagine a lot of the bugs currently
classified as Snow Leopard-related issues are in fact 64-bit-
related. So far I see the following ports
On Aug 31, 2009, at 19:09, Rainer Müller wrote:
I am totally in favor of a batch change, but I would like to give
users
a few days of grace period for updating their MacPorts installations.
Let's say a week is enough? That would be next friday.
Note that we already crippled MacPorts for
I've been hoping for an ALSA port for OS X since the early days of
Darwin. Unfortunately, it largely consists of kernel modules, so it
really ain't gonna happen.
I have thought about writing a bridging interface between ALSA and
CoreAudio...but a project like that would likely take years.
I'll
Sounds reasonable, however I wonder if this is a temporary issue
that impacts a handful of ports. Do you know if there are many
projects apart from wine that need 32-bit?
I'd say that, if it does impact several ports to go for it. If
it's only wine or one or two other ports, I'd leave
On Sep 2, 2009, at 07:51, Ryan Schmidt wrote:
On Aug 31, 2009, at 19:09, Rainer Müller wrote:
I am totally in favor of a batch change, but I would like to give
users
a few days of grace period for updating their MacPorts installations.
Let's say a week is enough? That would be next
On 2009-09-02 17:46 , Jeremy Huddleston wrote:
On Sep 2, 2009, at 07:51, Ryan Schmidt wrote:
Note that we already crippled MacPorts for users of 1.7.1 and
earlier on August 29 by adding license info to 35 ports, including
openssl (which has 274 dependents) and most of the gcc ports (50
On Sep 2, 2009, at 9:06 AM, Ryan Schmidt wrote:
On Snow Leopard, we build x86_64 by default. But there are some
ports, e.g. wine, that cannot build 64-bit, so they force themselves
to build 32-bit instead. But that means all the dependencies must
also be 32-bit, or 32-/64-bit universal.
Maybe there can be a note in the parse-error notification for users:
Sometime a parse error can occur when features of a new MacPorts
release are included in Portfiles. Please run 'sudo port -v
selfupdate' to ensure you have the latest MacPorts base distribution.
On Sep 2, 2009, at 08:51,
Not installing dependencies universal causes issues like this:
http://trac.macports.org/ticket/20912
Its just my opinion of course but I intensely dislike the idea of
being forced to build all of my numerous ports universal instead
of just fixing the ones that need to be 32 bit.
While
On Sep 2, 2009, at 12:08 PM, Jeremy Huddleston wrote:
Not installing dependencies universal causes issues like this:
http://trac.macports.org/ticket/20912
Its just my opinion of course but I intensely dislike the idea of
being forced to build all of my numerous ports universal instead
On Sep 2, 2009, at 12:14 PM, William Davis wrote:
While some (xulrunner, firefox) just need new inline-asm to be
written for 64bit support, others (wine) may *NEVER* actually work
in 64bit. It may be the case that users need a 32bit wine for
win32 and a 64bit wine for win64. ... so it's
On Sep 2, 2009, at 09:14, William Davis wrote:
On Sep 2, 2009, at 12:08 PM, Jeremy Huddleston wrote:
Not installing dependencies universal causes issues like this:
http://trac.macports.org/ticket/20912
Its just my opinion of course but I intensely dislike the idea of
being forced to build
On Sep 2, 2009, at 11:04, William Davis wrote:
On Sep 2, 2009, at 9:06 AM, Ryan Schmidt wrote:
On Snow Leopard, we build x86_64 by default. But there are some
ports, e.g. wine, that cannot build 64-bit, so they force
themselves to build 32-bit instead. But that means all the
On Wed, Sep 2, 2009 at 02:16, Ryan Schmidtryandes...@macports.org wrote:
On Sep 2, 2009, at 03:39, Vincent Lefevre wrote:
The GNU Coding Standards don't mention --disable-dependency-tracking
because it is not an option universally recognized. In fact, this is
a specific option defined by
On Sep 2, 2009, at 11:56, Toby Peterson wrote:
I don't know what dependency tracking does, but since the default
is to
enable it, I assume it's useful for something. Does anybody know
what it's
for or what consequences disabling it could have?
The primary consequence is that builds would
On Wed, Sep 2, 2009 at 09:59, Ryan Schmidtryandes...@macports.org wrote:
On Sep 2, 2009, at 11:56, Toby Peterson wrote:
I don't know what dependency tracking does, but since the default is to
enable it, I assume it's useful for something. Does anybody know what
it's
for or what consequences
On Sep 2, 2009, at 12:46 PM, Ryan Schmidt wrote:
On Sep 2, 2009, at 11:04, William Davis wrote:
On Sep 2, 2009, at 9:06 AM, Ryan Schmidt wrote:
On Snow Leopard, we build x86_64 by default. But there are some
ports, e.g. wine, that cannot build 64-bit, so they force
themselves to build
On Sep 2, 2009, at 12:35 PM, Daniel J. Luke wrote:
On Sep 2, 2009, at 12:14 PM, William Davis wrote:
While some (xulrunner, firefox) just need new inline-asm to be
written for 64bit support, others (wine) may *NEVER* actually work
in 64bit. It may be the case that users need a 32bit wine
Has anyone else noticed that archive mode always places things in
darwin/i386 even when doing other architectures?
Bug or just careless directory scheme?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
On Sep 2, 2009, at 1:38 PM, Jeremy Lavergne wrote:
Has anyone else noticed that archive mode always places things in
darwin/i386 even when doing other architectures?
It's probably using the arch of the build host and not the arch that
you are building (on my ppc machine, the packages are
Has anyone else noticed that archive mode always places things in
darwin/i386 even when doing other architectures?
It's probably using the arch of the build host and not the arch that
you are building (on my ppc machine, the packages are all in /opt/
On 2009-9-3 03:35, William Davis wrote:
It just seems simpler to me to have port rebuild
dependents as universal whenever that was needed instead of building
them all universal, whether needed or not.
Well of course that's simpler for you, but it's not simpler for whoever
has to implement that
Hi,
python23 is very old and outdated. It is a non-framework build, not
supported by python_select and should not be used anymore.
There are a few dependents, most of which have also not been updated in
years, so I assume nobody cares anymore.
nonpareil
zope
zopeedit
gwee
waitfor
Martin, if
On Sep 2, 2009, at 5:31 PM, Joshua Root wrote:
On 2009-9-3 03:35, William Davis wrote:
It just seems simpler to me to have port rebuild
dependents as universal whenever that was needed instead of building
them all universal, whether needed or not.
Well of course that's simpler for you, but
35 matches
Mail list logo
