Le 6 nov. 08 à 10:44, Ryan Schmidt a écrit :
I would still like this discussion to take place on macports-dev,
not macports-mgr.
True.
A quick summary for macports-dev: the discussion is about r41526 and
r41527, i.e. allowing a new syntax for dependencies in the next
release without
Le 5 nov. 08 à 23:38, Ryan Schmidt a écrit :
Obviously! I didn't even know we had tests.
What should we be doing before committing changes to base? Is it
just make test?
Indeed.
Paul
___
macports-dev mailing list
Le 17 juin 08 à 16:45, Blair Zajac a écrit :
Hi,
The upgrade to Ruby 1.8.7 breaks on PPC mac:
http://trac.macports.org/ticket/15635
I haven't seen a response on the ticket yet. Should we back the
port down to the previous stable version, which did work?
It's one thing to have a
Le 14 janv. 08 à 23:32, Simon Ruderich a écrit :
- [EMAIL PROTECTED]: dvipdfmx
dvipdfmx is provided by texlive_base, but it's an older version that
actually crashes when doing some operations.
Paul
___
macports-dev mailing list
Le 10 janv. 08 à 12:21, Ryan Schmidt a écrit :
build dependencies are checked _after_ configure, so they're
useless for pkg-config...
depends_lib
List of dependencies to check before configure, build,
destroot,
install, and package targets.
depends_build
Le 4 nov. 07 à 18:51, Simon Ruderich a écrit :
On Wed, Oct 17, 2007 at 02:48:43PM -0700, James Berry wrote:
I'd like to point out that mpwa, as deployed at http://
db.macports.org has
schema support for most of what is required for this, including
problem
reports and build output/logs from
Le 1 sept. 07 à 01:26, Ryan Schmidt a écrit :
I work on a MacBook with Mac OS X 10.4 and with gcc 4.2.1
Ah, OK... The Portfile is probably not set up to handle the
FSF GCC but assumes you are using the Apple GCC (/usr/bin/gcc).
If you have such a non-standard gcc in your path, then you'll
On Jul 16, 2007, at 3:26 AM, Ryan Schmidt wrote:
For ImageMagick I had this livecheck defined:
livecheck.check moddate
livecheck.url ftp://ftp.imagemagick.net/pub/${name}/$
{name}.tar.bz2
When the portfile was up to date, sudo port livecheck ImageMagick
returned quickly.
On Jun 24, 2007, at 7:00 AM, Ryan Schmidt wrote:
On Jun 23, 2007, at 16:27, Juan Manuel Palacios wrote:
I'm curious about why we provide facilities to alter the
configure environment in many ways but practically none to alter
the build environment. I know that in the ideal case (a
On Jun 24, 2007, at 8:37 AM, Ryan Schmidt wrote:
On Jun 23, 2007, at 18:16, Paul Guyot wrote:
On Jun 24, 2007, at 6:12 AM, Juan Manuel Palacios wrote:
About this commit though it was discussed on the this list
some time ago whether GSoC work should be committed to trunk
On May 27, 2007, at 3:59 PM, Ryan Schmidt wrote:
On May 26, 2007, at 04:44, Paul Guyot wrote:
On May 26, 2007, at 5:48 AM, N_Ox wrote:
The new configure flags change made in 1.4 seems to cause
problems with some ports (at least 2, maybe more).
This change introduces things like default
On May 26, 2007, at 5:48 AM, N_Ox wrote:
Hello,
The new configure flags change made in 1.4 seems to cause problems
with some ports (at least 2, maybe more).
This change introduces things like default ldflags -L/opt/local/lib.
The problem with these flags is that some ports write ENV flags
So maybe it's time for 1.4.41 :D
Paul
On May 8, 2007, at 5:04 PM, Jordan K. Hubbard wrote:
AFAIK, the fix hasn't even been committed to trunk yet...
- Jordan
On May 8, 2007, at 1:01 AM, Ryan Schmidt wrote:
MacPorts 1.4.40 was released, so I hope the fix made it into that...
--
On Apr 29, 2007, at 11:04 AM, Ryan Schmidt wrote:
-# Untested but should probably work on FreeBSD/Linux.
-platform darwin freebsd linux
+platforms darwin
How should a port developer set the platforms declaration? What
is its significance? I've
On Apr 25, 2007, at 9:02 AM, Ryan Schmidt wrote:
I propose we start with those two trees and fill them up as
necessary, the first one being the existing trunk/dports which
would *have* to stay in sync with base/branches/release_x_y and
the second being a testbed for Portfiles that need
On Apr 16, 2007, at 5:02 PM, Jordan K. Hubbard wrote:
dports/lang/squeak
But every target fails, as I said - not just livecheck. build
does the same thing.
Are you running trunk?
Could you please confirm that you have the latest code from trunk or
1.4.1, as well as the latest version
On Apr 16, 2007, at 5:17 PM, Jordan K. Hubbard wrote:
Yes, as I noted in my original message:
I'm seeing this from any port and any operation, so it looks like
something has gone south in ToT
Sorry, ToT (Top Of Tree) is how we refer to Trunk around here so
I'm more accustomed to using
On Apr 16, 2007, at 6:10 PM, Jordan K. Hubbard wrote:
Well, yes, they do. But that should come as no surprise. :)
Well, I have exactly the same diff with the configuration files (the
file:/// url is different, but that's all). I'm out of clues.
The error (extra characters after
On Apr 15, 2007, at 1:42 PM, Ryan Schmidt wrote:
Ok, that's what I'm doing (in sleepwatcher), but it's resulting in
weirdness: port info shows two universal variants; see:
$ port info sleepwatcher | head -n 1
sleepwatcher 2.0.4, Revision 2, sysutils/sleepwatcher (Variants:
universal,
On Apr 16, 2007, at 10:20 AM, Ryan Schmidt wrote:
On Apr 15, 2007, at 10:35, James Berry wrote:
- Add -I${prefix}/include -L${prefix}/lib to the default
configure
flags (pguyot in r23246 and r23291).
Ok, so after r23291, we're adding these in cppflags and ldflags,
and -O2 in
On Apr 14, 2007, at 12:44 AM, Weissmann Markus wrote:
I'll have to chime in on this one: I also prefer to (i) get
maintainers to add livecheck and (ii) get information if I have to
actually do something.
Actually, Kevin reverted to the initial behavior, while maintaining
his fixes and
On Apr 14, 2007, at 11:10 AM, James Berry wrote:
In an effort to expedite small releases of MacPorts, such as 1.4.1,
I'd like to suggest that we keep trunk as usable as possible,
whenever we can.
As an example, it's been suggested that the universal variant
support in trunk is
On Apr 14, 2007, at 6:16 AM, Ryan Schmidt wrote:
On Apr 13, 2007, at 08:49, Daniel J. Luke wrote:
On Apr 12, 2007, at 10:37 PM, Boey Maun Suang wrote:
As far as I can tell, however, work on base to allow for
executing ${build} in multiple directories would probably be
necessary to deal
On Apr 12, 2007, at 8:54 PM, [EMAIL PROTECTED] wrote:
Revision: 23888
http://trac.macosforge.org/projects/macports/changeset/23888
Author: [EMAIL PROTECTED]
Date: 2007-04-12 04:54:10 -0700 (Thu, 12 Apr 2007)
Log Message:
---
Fix livecheck to check for master_sites
Hi folks,
We cannot simply autoconf for readline for the following reasons:
(a) readline comes with two incompatible APIs.
(b) Apple's gcc reads /usr/local/include before /usr/include
(c) Apple's ld reads /usr/lib/libreadline.dylib before /usr/local/lib/
libreadline.a when provided with
Hi all,
Trunk contains new code for configure flags and default universal
variant code.
It would be great if this could be tested more and released as soon
as possible:
- it would allow maintainers to work on universal variants
- it would allow us to simplify many portfiles by removing:
On Mar 28, 2007, at 1:13 PM, Daniel J. Luke wrote:
On Mar 27, 2007, at 9:35 PM, Paul Guyot wrote:
Besides, trunk code produces -O2 binaries for autoconf-based
ports, while any such port with the previous line is compiled -O0
with 1.4.0.
Might -Os be a better choice for the default?
-O2
On Mar 25, 2007, at 9:00 AM, Ryan Schmidt wrote:
What is this new mechanism you're working on? I would have thought
that MacPorts already somewhere defines what default environment
variables to use, and that the -L and -I options could simply be
added to it, without requiring any major
prunille:~ locate libreadline.dylib
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libreadline.dylib
/opt/local/lib/libreadline.dylib
/opt/local/var/db/dports/build/
_Users_vinc17_software_darwinports_dports_devel_readline/work/
destroot/opt/local/lib/libreadline.dylib
the system installation of readline.
Paul
Le 15 mars 07 à 22:37, Vincent Lefevre a écrit :
On 2007-03-15 19:03:37 +0900, Paul Guyot wrote:
prunille:~ locate libreadline.dylib
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libreadline.dylib
/opt/local/lib/libreadline.dylib
/opt/local/var/db/dports/build
On 2007-03-15 12:05:03 +0900, Paul Guyot wrote:
Please uninstall your other copy of readline and try again.
I don't want to do that as ports depend on it:
It's not what I meant.
You probably have three copies of readline:
- System's readline
- MP's readline
- Another copy.
This is the other
-devel ports instead of allowing a port to be
available as multiple branches? like bash 3.1.17 and 3.2.9 as a
3.1 and a 3.2 branch (yes, i'm thinking of gentoo - stable,
testing, etc)?
Regards,
Elias Pipping
On Feb 26, 2007, at 5:45 AM, Paul Guyot wrote:
Dear all,
I've just implemented
On Feb 26, 2007, at 18:58, Ryan Schmidt wrote:
You are right. This will not work on 10.3 simply because 10.3
installations are not capable of building universal binaries. I
have just added a warning (we could transform it into an error)
when the +universal variant is selected on machines
On Feb 26, 2007, at 19:00, Blair Zajac wrote:
Hello Paul,
Yes, I would love to have a single Universal MacPorts build, but
since I need to support 10.3, that won't be happening.
But shouldn't the code adding this feature check to see if it's on
10.3 before adding the -isysroot and other
On Feb 20, 2007, at 16:52, Juan Manuel Palacios wrote:
Finding out which options are up for user interaction (and
therefore documentable) and which aren't was also one of my
explicit goals; comments like yours, stay away from those!, is
what I was looking for with my mail. I didn't get
Juan,
I am confused. These so-called options are undocumented but should
not be used by any user because their semantics could change any
time. For example, xcodeversion only means how to handle xcode
related tools and the most frequent value (2.1), as Kevin notes it,
only means 2.1 or
On 12 févr. 07, at 22:02, Kevin Ballard wrote:
Who here is actively modifying, or considering modifying, base/? I
ask because, in order to resolve the Spacing issue, we need to
simply make a decision one way or the other and stop debating it.
And frankly, this is only going to affect
On Feb 4, 2007, at 19:26, Juan Manuel Palacios wrote:
There is also the ruby port group changes that currently make many
ports only compatible with HEAD.
Did you author the group? Do you happen to know in what revision
it was committed?
I just authored some changes:
On 31 janv. 07, at 02:47, Juan Manuel Palacios wrote:
-) anything else I'm missing...? Anyone care to diff the two code
bases? ;-)
Diffing should definitely be done. I can't do it for the next three
weeks, though.
There is also the ruby port group changes that currently make many
Le 26 janv. 07 à 01:42, Kevin Ballard a écrit :
On Jan 24, 2007, at 6:48 PM, Paul Guyot wrote:
Le 24 janv. 07 à 07:12, Kevin Ballard a écrit :
Hrm, nobody has responded. I guess nobody cares?
If I don't hear anything back in the next few days, I'll go ahead
and commit the change.
I
40 matches
Mail list logo
