On 3/3/09, Ryan Schmidt wrote:
>
> On Mar 2, 2009, at 10:24, de...@macports.org wrote:
>
> > +build.target build_ext
> > +build.args -I/opt/local/include
> >
>
> You must not hard-code /opt/local into portfiles because MacPorts may be in
> a different prefix. Use ${prefix} instead.
On Mar 2, 2009, at 10:24, de...@macports.org wrote:
+build.target build_ext
+build.args -I/opt/local/include
You must not hard-code /opt/local into portfiles because MacPorts may
be in a different prefix. Use ${prefix} instead.
Also note -I${prefix}/include is really more o
On Mon, Mar 02, 2009 at 06:11:32PM +0100, Olivier Le Floch said:
> Hi,
>
> The php5 port has recently been updated to version 5.2.9. Such an update
> forces users to recompile php5-eaccelerator for compatibility. Should we
> bump php5-eaccelerator's revision when updating php5's ? The same is
>
On Mon, Mar 02, 2009 at 12:34:57AM -0800, Jordan K. Hubbard said:
> Thanks for the correction - I have a hard time keeping the various
> releases straight since they all seem to kind of blend into one another
> for some reason. :-)
>
> I don't think the question is "whether to exclude Panther" (
Not exactly...
tkined is just a wish script. It doesn't need anything from xorg-libs
directly. It just needs wish. wish is provided by its other
dependencies.
In fact, tkined doesn't even run here. It tries to use the system
wish (which isn't X11 based, btw) and fails with:
/opt/loc
Hi,
The php5 port has recently been updated to version 5.2.9. Such an
update forces users to recompile php5-eaccelerator for compatibility.
Should we bump php5-eaccelerator's revision when updating php5's ? The
same is probably true for php5-xdebug and other php5 extensions. If we
do bump
Hi Jeremy,
Ok now I remember. There is a tkined X11 editor that gets installed by
scotty. So I supposed that I should include it as a dependency, though I
doubt anyone would use it these days anyway.
But I didn't think that whether or not a port links against a library
should determine whether
Ryan Schmidt wrote:
> On Mar 2, 2009, at 07:39, Joshua Root wrote:
>> Seriously though, it's going to be up to whoever builds the dmgs in the
>> end.
>
> I would say it's up to all of us developing the software up to the point
> when we want to make a release. The person packaging the release can'
On Mar 2, 2009, at 07:39, Joshua Root wrote:
Ryan Schmidt wrote:
On Mar 2, 2009, at 04:30, Anders F Björklund wrote:
Last time this was discussed, the decision was that
MacPorts 1.7.x would support Panther but not 1.8...
Well, inasmuch as we "support" anything. The default response to
Pa
Ryan Schmidt wrote:
>
> On Mar 2, 2009, at 04:30, Anders F Björklund wrote:
>
>> Last time this was discussed, the decision was that
>> MacPorts 1.7.x would support Panther but not 1.8...
Well, inasmuch as we "support" anything. The default response to Panther
issues is "patches welcome", wherea
On Mar 2, 2009, at 05:34, Anders F Björklund wrote:
Ryan Schmidt wrote:
Last time this was discussed, the decision was that
MacPorts 1.7.x would support Panther but not 1.8...
For next release, it should drop 10.3 and add 10.6
At least as far as the DMG disk images go, that is...
I don't
Ryan Schmidt wrote:
Last time this was discussed, the decision was that
MacPorts 1.7.x would support Panther but not 1.8...
For next release, it should drop 10.3 and add 10.6
At least as far as the DMG disk images go, that is...
I don't remember agreeing to drop Panther for MacPorts 1.8.0. :
On Mar 2, 2009, at 04:30, Anders F Björklund wrote:
Jeremy Huddleston wrote:
Isn't Panther *already* not "officially" supported anymore?
http://www.macports.org says:
"""
We provide a single software tree that attempts to track the
latest release of every software title (port) we distribut
Jeremy Huddleston wrote:
Isn't Panther *already* not "officially" supported anymore?
http://www.macports.org says:
"""
We provide a single software tree that attempts to track the latest
release of every software title (port) we distribute, without
splitting them into “stable” Vs. “unstable
Isn't Panther *already* not "officially" supported anymore?
http://www.macports.org says:
"""
We provide a single software tree that attempts to track the latest
release of every software title (port) we distribute, without
splitting them into “stable” Vs. “unstable” branches, targetting
ma
On Mon, Mar 2, 2009 at 05:50, Bryan Blackburn wrote:
> On Mon, Mar 02, 2009 at 05:12:45AM +0100, Rasmus Andersson said:
> [...]
>>
>> It is not a valid argument in the Python 3.0 I have got from MacPorts.
>> Was this patched recently? (my installation might be about a month
>> old)
>
> Yeah, your
On Mon, Mar 02, 2009 at 02:15:38AM -0600, Ryan Schmidt said:
[...]
>
> I have not tested whether this information is still accurate. But even if
> it is, I don't think this is any reason to kill all hopes of running
> MacPorts 1.8.0 on Panther, especially since it would be no different than
> an
On Mar 1, 2009, at 04:27, Joshua Root wrote:
Ryan Schmidt wrote:
But I would like to know how it came to be that the file was on
all of
our mirrors in October 2008 but then disappeared from two of them
since
then.
Portmirror deletes files when the checksums don't match.
Hmm. Well on t
Thanks for the correction - I have a hard time keeping the various
releases straight since they all seem to kind of blend into one
another for some reason. :-)
I don't think the question is "whether to exclude Panther" (though at
almost 6 years old, one wonders how long users might expect o
On Mar 2, 2009, at 01:38, Jordan K. Hubbard wrote:
On Mar 1, 2009, at 10:53 PM, Bryan Blackburn wrote:
The problem is that 10.3 doesn't support lchown() which means that
currently
trunk fails to build there. Using a HAVE_LCHOWN test, we could
fall back to
using just chown() but then we're
20 matches
Mail list logo
