From cedric.luthi at gmail.com  Sun Apr  1 00:02:46 2007
From: cedric.luthi at gmail.com (=?ISO-8859-1?Q?C=E9dric_Luthi?=)
Date: Tue Oct  9 16:40:09 2007
Subject: replace reinplace
In-Reply-To: <AF639E7D-2581-4428-AD72-FE8A0C6E4716@macports.org>
References: <1EC7E045-D110-4419-B0D6-4431590A9810@macports.org>
	<AF639E7D-2581-4428-AD72-FE8A0C6E4716@macports.org>
Message-ID: <0A3E90B8-EE8B-4484-8882-0959243320E5@gmail.com>

On 1 avr. 07, at 08:03, Ryan Schmidt wrote:

> Wouldn't most of the existing invocations of reinplace break if we  
> change that now?

I'd say no. Replacing sed -E by sed would break all those who  
actually use extended syntax but probably not the other way round. I  
don't think there are non-extended expressions that would fail as an  
extended expressions.

C?dric



From rhwood at mac.com  Sun Apr  1 02:53:03 2007
From: rhwood at mac.com (Randall Wood)
Date: Tue Oct  9 16:40:09 2007
Subject: Bad Portfiles
Message-ID: <573D181A-3E08-4FE1-97D7-F20F4A7E7656@mac.com>

Commiters:

Pay attention to emails from source_changes@macports.org with subject  
[xxxxx] trunk/dports/PortIndex!

Here's the log message from the most recent one:

Log Message

Total number of ports parsed:	3845
Ports successfully parsed:	3843	
Ports failed:			2


Failed to parse file archivers/zlib/Portfile: invalid command name  
"configure.universal_args"
Failed to parse file sysutils/passogva/Portfile: invalid command name  
"fetch.ignore_sslcert"


Randall Wood
rhwood@mac.com

"The rules are simple: The ball is round. The game lasts 90 minutes.  
All the
rest is just philosophy."



From yves at macports.org  Sun Apr  1 06:39:11 2007
From: yves at macports.org (Yves de Champlain)
Date: Tue Oct  9 16:40:09 2007
Subject: replace reinplace
In-Reply-To: <0A3E90B8-EE8B-4484-8882-0959243320E5@gmail.com>
References: <1EC7E045-D110-4419-B0D6-4431590A9810@macports.org>
	<AF639E7D-2581-4428-AD72-FE8A0C6E4716@macports.org>
	<0A3E90B8-EE8B-4484-8882-0959243320E5@gmail.com>
Message-ID: <181A5263-83F1-4D26-AA53-532FC3D0E768@macports.org>


Le 07-04-01 ? 03:02, C?dric Luthi a ?crit :

> On 1 avr. 07, at 08:03, Ryan Schmidt wrote:
>
>> Wouldn't most of the existing invocations of reinplace break if we  
>> change that now?
>
> I'd say no. Replacing sed -E by sed would break all those who  
> actually use extended syntax but probably not the other way round.  
> I don't think there are non-extended expressions that would fail as  
> an extended expressions.

There might be some breakage indeed, but certainly not a lot.  But  
such a change would also have to be syncchronized with a release, so  
I was mostly wondering why in the first place was it chosen not to  
use it ?

On the other hand, maybe some grepper could translate that in 'basic  
mode' for me ?

sed -E 's|\$\(DESTDIR\)[[:space:]]+\$\(|\$\(DESTDIR\)\$\(|g'

Now that is the first level question.

yves


From pipping at macports.org  Sun Apr  1 06:46:27 2007
From: pipping at macports.org (Elias Pipping)
Date: Tue Oct  9 16:40:09 2007
Subject: [23439] trunk/dports/archivers/zlib/Portfile
In-Reply-To: <20070401102828.964FA50EB23@cvs.opensource.apple.com>
References: <20070401102828.964FA50EB23@cvs.opensource.apple.com>
Message-ID: <DBCDE0DB-D38C-4BB4-8F09-C5C162B968B2@macports.org>

Hi,

I noticed you removed the line

   configure.universal_args ${configure.args}

the line should have read

   configure.universal_args {}

which would still break 1.4 but work as expected when running the trunk.

the reason the line can't simply be removed (doing so broke zlib  
+universal) is that the default universal variant is used, which  
includes CPPFLAGS, LDFLAGS and configure.args (--disable-dependency- 
tracking). Whereas the flags are fine and needed, the configure.args  
are not:

   <snip> ./configure <snip> --disable-dependency-tracking'
   unknown option: --disable-dependency-tracking

so i overwrote them. one way or another that has to be done - only  
way around it would be to override the default universal variant and  
add the flags in there manually, which is a pain. i tried and it  
doesn't work:

variant universal {
     set f "-arch i386 -arch ppc"
     configure.env-append \
     CFLAGS="\${CFLAGS} -isysroot /Developer/SDKs/MacOSX10.4u.sdk $ 
{f}" \
     LDFLAGS="\${LDFLAGS} ${f}"
}

make: *** Recursive variable `CFLAGS' references itself  
(eventually).  Stop.


Regards,

Elias

From pipping at macports.org  Sun Apr  1 07:05:04 2007
From: pipping at macports.org (Elias Pipping)
Date: Tue Oct  9 16:40:09 2007
Subject: replace reinplace
In-Reply-To: <181A5263-83F1-4D26-AA53-532FC3D0E768@macports.org>
References: <1EC7E045-D110-4419-B0D6-4431590A9810@macports.org>
	<AF639E7D-2581-4428-AD72-FE8A0C6E4716@macports.org>
	<0A3E90B8-EE8B-4484-8882-0959243320E5@gmail.com>
	<181A5263-83F1-4D26-AA53-532FC3D0E768@macports.org>
Message-ID: <15F277B4-0FF1-4871-944A-FB55F3759542@macports.org>

On Apr 1, 2007, at 3:39 PM, Yves de Champlain wrote:

> On the other hand, maybe some grepper could translate that in  
> 'basic mode' for me ?
>
> sed -E 's|\$\(DESTDIR\)[[:space:]]+\$\(|\$\(DESTDIR\)\$\(|g'

sed 's|\$(DESTDIR)[[:space:]][[:space:]]*\$(|FOO|g'

changes

   $(DESTDIR) $(

to

   FOO

if that is what you want.


Regards,

Elias

From rhwood at mac.com  Sun Apr  1 07:12:16 2007
From: rhwood at mac.com (Randall Wood)
Date: Tue Oct  9 16:40:09 2007
Subject: [23439] trunk/dports/archivers/zlib/Portfile
In-Reply-To: <DBCDE0DB-D38C-4BB4-8F09-C5C162B968B2@macports.org>
References: <20070401102828.964FA50EB23@cvs.opensource.apple.com>
	<DBCDE0DB-D38C-4BB4-8F09-C5C162B968B2@macports.org>
Message-ID: <6CD90A81-3D31-4B2F-9719-D8EE63A69EA1@mac.com>

This seems to be one of those "if you can't make it work in the  
current release (1.4) then you shouldn't do it situations"

Until the current release has universal support then I would not  
commit universalized ports.

On 1 Apr 2007, at 09:46, Elias Pipping wrote:

> Hi,
>
> I noticed you removed the line
>
>   configure.universal_args ${configure.args}
>
> the line should have read
>
>   configure.universal_args {}
>
> which would still break 1.4 but work as expected when running the  
> trunk.
>
> the reason the line can't simply be removed (doing so broke zlib  
> +universal) is that the default universal variant is used, which  
> includes CPPFLAGS, LDFLAGS and configure.args (--disable-dependency- 
> tracking). Whereas the flags are fine and needed, the  
> configure.args are not:
>
>   <snip> ./configure <snip> --disable-dependency-tracking'
>   unknown option: --disable-dependency-tracking
>
> so i overwrote them. one way or another that has to be done - only  
> way around it would be to override the default universal variant  
> and add the flags in there manually, which is a pain. i tried and  
> it doesn't work:
>
> variant universal {
>     set f "-arch i386 -arch ppc"
>     configure.env-append \
>     CFLAGS="\${CFLAGS} -isysroot /Developer/SDKs/MacOSX10.4u.sdk $ 
> {f}" \
>     LDFLAGS="\${LDFLAGS} ${f}"
> }
>
> make: *** Recursive variable `CFLAGS' references itself  
> (eventually).  Stop.
>
>
> Regards,
>
> Elias
> _______________________________________________
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev


Randall Wood
rhwood@mac.com

"The rules are simple: The ball is round. The game lasts 90 minutes.  
All the
rest is just philosophy."



From ryandesign at macports.org  Sun Apr  1 10:43:21 2007
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue Oct  9 16:40:09 2007
Subject: [23439] trunk/dports/archivers/zlib/Portfile
In-Reply-To: <6CD90A81-3D31-4B2F-9719-D8EE63A69EA1@mac.com>
References: <20070401102828.964FA50EB23@cvs.opensource.apple.com>
	<DBCDE0DB-D38C-4BB4-8F09-C5C162B968B2@macports.org>
	<6CD90A81-3D31-4B2F-9719-D8EE63A69EA1@mac.com>
Message-ID: <7F6CADFE-56ED-4FA6-9AB0-A261C5CE7EF7@macports.org>

On Apr 1, 2007, at 09:12, Randall Wood wrote:

> This seems to be one of those "if you can't make it work in the  
> current release (1.4) then you shouldn't do it situations"
>
> Until the current release has universal support then I would not  
> commit universalized ports.

If we don't try to make ports universal now, we'll never know what  
universal support features we need from MacPorts.

zlib +universal worked fine in MP 1.3.2 until the portfile was  
declared to be too ugly and got totally rewritten... I'll have more  
to say about that in a moment.


From pipping at macports.org  Sun Apr  1 10:54:39 2007
From: pipping at macports.org (Elias Pipping)
Date: Tue Oct  9 16:40:09 2007
Subject: [23439] trunk/dports/archivers/zlib/Portfile
In-Reply-To: <7F6CADFE-56ED-4FA6-9AB0-A261C5CE7EF7@macports.org>
References: <20070401102828.964FA50EB23@cvs.opensource.apple.com>
	<DBCDE0DB-D38C-4BB4-8F09-C5C162B968B2@macports.org>
	<6CD90A81-3D31-4B2F-9719-D8EE63A69EA1@mac.com>
	<7F6CADFE-56ED-4FA6-9AB0-A261C5CE7EF7@macports.org>
Message-ID: <1557D622-5208-4BF4-A536-3037AF13381B@macports.org>

On Apr 1, 2007, at 7:43 PM, Ryan Schmidt wrote:

> On Apr 1, 2007, at 09:12, Randall Wood wrote:
>
>> This seems to be one of those "if you can't make it work in the  
>> current release (1.4) then you shouldn't do it situations"
>>
>> Until the current release has universal support then I would not  
>> commit universalized ports.
>
> If we don't try to make ports universal now, we'll never know what  
> universal support features we need from MacPorts.
>
> zlib +universal worked fine in MP 1.3.2 until the portfile was  
> declared to be too ugly and got totally rewritten... I'll have more  
> to say about that in a moment.

the 'normal user' shouldn't be affected by universal variant
related changes until that's an official feature. so it'd probably
best to remove everything of that kind from the affected ports and
instead make patches for testers running the trunk available.

that'd affect:

   archivers/zlib/
   devel/openssl/
   devel/pcre/
   editors/vim/
   lang/scheme48/
   net/curl/
   textproc/libiconv/
   www/neon/

i'll do that as soon asap and attach the patches to the corresponding  
article in the wiki. sorry for the inconvenience cause by universal  
variants (including a broken zlib).


Regards,

Elias



From rhwood at mac.com  Sun Apr  1 11:31:23 2007
From: rhwood at mac.com (Randall Wood)
Date: Tue Oct  9 16:40:09 2007
Subject: [23439] trunk/dports/archivers/zlib/Portfile
In-Reply-To: <1557D622-5208-4BF4-A536-3037AF13381B@macports.org>
References: <20070401102828.964FA50EB23@cvs.opensource.apple.com>
	<DBCDE0DB-D38C-4BB4-8F09-C5C162B968B2@macports.org>
	<6CD90A81-3D31-4B2F-9719-D8EE63A69EA1@mac.com>
	<7F6CADFE-56ED-4FA6-9AB0-A261C5CE7EF7@macports.org>
	<1557D622-5208-4BF4-A536-3037AF13381B@macports.org>
Message-ID: <6FDC334D-2D68-4DFC-8179-6F8CCA275877@mac.com>

It may actually be best if you created a separate port tree that  
someone could include in their sources.conf file if they wanted to  
test it...

On 1 Apr 2007, at 13:54, Elias Pipping wrote:

> On Apr 1, 2007, at 7:43 PM, Ryan Schmidt wrote:
>
>> On Apr 1, 2007, at 09:12, Randall Wood wrote:
>>
>>> This seems to be one of those "if you can't make it work in the  
>>> current release (1.4) then you shouldn't do it situations"
>>>
>>> Until the current release has universal support then I would not  
>>> commit universalized ports.
>>
>> If we don't try to make ports universal now, we'll never know what  
>> universal support features we need from MacPorts.
>>
>> zlib +universal worked fine in MP 1.3.2 until the portfile was  
>> declared to be too ugly and got totally rewritten... I'll have  
>> more to say about that in a moment.
>
> the 'normal user' shouldn't be affected by universal variant
> related changes until that's an official feature. so it'd probably
> best to remove everything of that kind from the affected ports and
> instead make patches for testers running the trunk available.
>
> that'd affect:
>
>   archivers/zlib/
>   devel/openssl/
>   devel/pcre/
>   editors/vim/
>   lang/scheme48/
>   net/curl/
>   textproc/libiconv/
>   www/neon/
>
> i'll do that as soon asap and attach the patches to the  
> corresponding article in the wiki. sorry for the inconvenience  
> cause by universal variants (including a broken zlib).
>
>
> Regards,
>
> Elias
>
>


Randall Wood
rhwood@mac.com

"The rules are simple: The ball is round. The game lasts 90 minutes.  
All the
rest is just philosophy."



From landonf at macports.org  Sun Apr  1 11:34:58 2007
From: landonf at macports.org (Landon Fuller)
Date: Tue Oct  9 16:40:09 2007
Subject: [23439] trunk/dports/archivers/zlib/Portfile
In-Reply-To: <7F6CADFE-56ED-4FA6-9AB0-A261C5CE7EF7@macports.org>
References: <20070401102828.964FA50EB23@cvs.opensource.apple.com>
	<DBCDE0DB-D38C-4BB4-8F09-C5C162B968B2@macports.org>
	<6CD90A81-3D31-4B2F-9719-D8EE63A69EA1@mac.com>
	<7F6CADFE-56ED-4FA6-9AB0-A261C5CE7EF7@macports.org>
Message-ID: <2D97B933-D498-4A4B-B633-36967B12D1D9@macports.org>


On Apr 1, 2007, at 10:43 AM, Ryan Schmidt wrote:

>
> zlib +universal worked fine in MP 1.3.2 until the portfile was  
> declared to be too ugly and got totally rewritten... I'll have more  
> to say about that in a moment.

No, it did not.

The port broke because the 'command' private API was used. Period. I  
rewrote the port to remove the private APIs, which disabled the  
obviously experimental universal support.

I didn't test pipping's new universal support because I didn't write  
(or commit) the universal support.

-landonf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070401/e4e5609e/PGP.bin
From landonf at macports.org  Sun Apr  1 11:36:49 2007
From: landonf at macports.org (Landon Fuller)
Date: Tue Oct  9 16:40:09 2007
Subject: [23439] trunk/dports/archivers/zlib/Portfile
In-Reply-To: <2D97B933-D498-4A4B-B633-36967B12D1D9@macports.org>
References: <20070401102828.964FA50EB23@cvs.opensource.apple.com>
	<DBCDE0DB-D38C-4BB4-8F09-C5C162B968B2@macports.org>
	<6CD90A81-3D31-4B2F-9719-D8EE63A69EA1@mac.com>
	<7F6CADFE-56ED-4FA6-9AB0-A261C5CE7EF7@macports.org>
	<2D97B933-D498-4A4B-B633-36967B12D1D9@macports.org>
Message-ID: <4C8D77E1-3D6A-4807-B78C-27BF5FC79256@macports.org>


On Apr 1, 2007, at 11:34 AM, Landon Fuller wrote:

>
> On Apr 1, 2007, at 10:43 AM, Ryan Schmidt wrote:
>
>>
>> zlib +universal worked fine in MP 1.3.2 until the portfile was  
>> declared to be too ugly and got totally rewritten... I'll have  
>> more to say about that in a moment.
>
> No, it did not.
>
> The port broke because the 'command' private API was used. Period.  
> I rewrote the port to remove the private APIs, which disabled the  
> obviously experimental universal support.

And in case it's not clear, the port functioned correctly afterwards.

> I didn't test pipping's new universal support because I didn't  
> write (or commit) the universal support.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070401/06817a98/PGP.bin
From yves at macports.org  Sun Apr  1 12:24:51 2007
From: yves at macports.org (Yves de Champlain)
Date: Tue Oct  9 16:40:09 2007
Subject: replace reinplace
In-Reply-To: <15F277B4-0FF1-4871-944A-FB55F3759542@macports.org>
References: <1EC7E045-D110-4419-B0D6-4431590A9810@macports.org>
	<AF639E7D-2581-4428-AD72-FE8A0C6E4716@macports.org>
	<0A3E90B8-EE8B-4484-8882-0959243320E5@gmail.com>
	<181A5263-83F1-4D26-AA53-532FC3D0E768@macports.org>
	<15F277B4-0FF1-4871-944A-FB55F3759542@macports.org>
Message-ID: <773B8851-574E-467B-B2BC-16D902DED9F8@macports.org>


Le 07-04-01 ? 10:05, Elias Pipping a ?crit :

> On Apr 1, 2007, at 3:39 PM, Yves de Champlain wrote:
>
>> On the other hand, maybe some grepper could translate that in  
>> 'basic mode' for me ?
>>
>> sed -E 's|\$\(DESTDIR\)[[:space:]]+\$\(|\$\(DESTDIR\)\$\(|g'
>
> sed 's|\$(DESTDIR)[[:space:]][[:space:]]*\$(|FOO|g'
>
> changes
>
>   $(DESTDIR) $(
>
> to
>
>   FOO
>
> if that is what you want.

Thanks a lot

yves


From opendarwin.org at darkart.com  Sun Apr  1 13:31:30 2007
From: opendarwin.org at darkart.com (Eric Hall)
Date: Tue Oct  9 16:40:09 2007
Subject: Only 8 ports that now depend upon DarwinPortsStartup
In-Reply-To: <fc.004c4c580c4395c0004c4c580c4395c0.c439612@biola.edu>
References: <fc.004c4c580c4395c0004c4c580c4395c0.c439612@biola.edu>
Message-ID: <20070401203130.GG9160@darkart.com>

On Sat, Mar 31, 2007 at 12:40:42PM -0700, markd@macports.org wrote:
> FYI, there are only 8 ports left that depend upon DarwinPortsStartup.
> 
> net/net-snmp

	Make it 7, I just removed DarwinPortsStartup from net/net-snmp.
Its replacement is fake/dummy items, but the dependency is gone.  Feel
free to add in proper start/stop actions.


		-eric


From pmq at macports.org  Sun Apr  1 15:15:27 2007
From: pmq at macports.org (Pierre Queinnec)
Date: Tue Oct  9 16:40:09 2007
Subject: Only 8 ports that now depend upon DarwinPortsStartup
In-Reply-To: <fc.004c4c580c4395c0004c4c580c4395c0.c439612@biola.edu>
References: <fc.004c4c580c4395c0004c4c580c4395c0.c439612@biola.edu>
Message-ID: <46102EFF.7050704@macports.org>

Hi Mark,

I think your grep was a bit eager: fetchmail doesn't depend on 
DarwinPortsStartup. One less to go!
Regards,
-- Pierre


markd@macports.org wrote:
> FYI, there are only 8 ports left that depend upon DarwinPortsStartup.
> 
> databases/mysql
> gnome/gdm
> mail/fetchmail
> mail/mailman
> net/junkbuster
> net/net-snmp
> net/throttled
> www/abyss
> 
> Mark


From pipping at macports.org  Sun Apr  1 15:59:03 2007
From: pipping at macports.org (Elias Pipping)
Date: Tue Oct  9 16:40:09 2007
Subject: Only 8 ports that now depend upon DarwinPortsStartup
In-Reply-To: <46102EFF.7050704@macports.org>
References: <fc.004c4c580c4395c0004c4c580c4395c0.c439612@biola.edu>
	<46102EFF.7050704@macports.org>
Message-ID: <D39FD8E1-7F81-4968-8597-D4B4C9F2CB08@macports.org>

On Apr 2, 2007, at 12:15 AM, Pierre Queinnec wrote:
> Hi Mark,
>
> I think your grep was a bit eager: fetchmail doesn't depend on  
> DarwinPortsStartup. One less to go!
> Regards,
> -- Pierre


May i suggest using test.sh[1]? ;)

$test.sh DarwinPortsStartup
databases/mysql
gnome/gdm
mail/mailman
net/junkbuster
net/throttled
www/abyss
$

(six to go)

[1] http://trac.macports.org/projects/macports/browser/users/pipping/ 
test.sh


Regards,

Elias

From jkh at brierdr.com  Mon Apr  2 01:52:51 2007
From: jkh at brierdr.com (Jordan K. Hubbard)
Date: Tue Oct  9 16:40:09 2007
Subject: Why are we doing releases again?
Message-ID: <8B4EC226-3C2B-4388-A3DC-1B8CF4E57417@brierdr.com>

OK, I'm sure what I'm about to say will identify me as a total kill- 
joy who also somehow doesn't remember the bad old days of base/  
instability or synchronization issues between base/ and dports/, but  
please just take it as a given that I DO remember those problems and  
still feel compelled, given some of the more negative trade-offs I've  
been seeing, to make the following statement anyway:

I don't think MacPorts should be doing releases.

Why?   Because I think they're premature for the project in general  
(given where it is in terms of resources and technology), I think  
they're largely arbitrary in what they're able (or willing) to  
promise to users and I think that they tend to create more problems  
than they solve as users attempt to follow the releases for base/ but  
still want to effectively follow ToT for dports/, leading to  
something which looks more like FrankenPorts than a genuinely  
coherent and stable branch.

What's worse is the fact that these "releases" are highly misleading  
in the sense that a "release" for any other software product is  
something that enjoys not just a "freeze" period but some sort of  
quality control and testing which ensures that all the respective  
pieces actually hang together and there aren't any really egregious  
problems with the product on the date that it ships.  MacPorts, on  
the other hand, does not have any sort of testing infrastructure to  
guarantee (or hell, even KNOW) that a significant majority of the  
ports are working at that particular time or that base/ and dports/  
synchronization problems have not broken things in various dusty  
corners of the ports collection.   This is why I say that the  
MacPorts project itself is simply not release-ready; it's more like a  
project going through its early Alpha stages where "be careful, you  
might cut yourself!" is about the best advice any user can be given.

Of course, we could attempt to dodge the issue here and claim that  
releases were really only for base/ and dports was the uncharted  
territory, but that would be silly given that if you add up every  
single line (of anything) in base/, you're looking at 156,000 lines  
of Makefiles, C, Tcl and other miscellaneous goop whereas for dports,  
that number is over 713,000 lines.   If anything needs release  
control, it's dports/, and one possibly helpful analogy would be to  
suppose that Mac OS X was released every time xnu looked stable  
enough, never mind everything else that depended on xnu.   "Not  
really our problem", the Mac OS X engineers might say. "People will  
certainly tell us if Mail, Final Cut Pro or various 3rd party are  
completely hosed and we can always fix that in the next release."   
That would sure be a lot easier (and I could spend the bulk of the  
year on Maui instead of worrying about the bulk of the bugs I worry  
about) but it wouldn't be a release.

1.4, despite all the hard work people have put into it, is also not a  
release.  Neither was 1.3, or 1.2, or anything that DarwinPorts/ 
MacPorts has done.  They've been fingers stuck in the wind and a  
highly subjective attempt to decide "what would be a good time"  
without the benefit of any actual end-to-end testing or regression  
analysis.    If that's all they were, I also probably wouldn't say  
anything, figuring "ah, what the heck, let the kids have their fun!",  
but I'm noticing more and more that these pseudo-releases are also a  
drain on productivity and end up spending cycles doing merges and  
trying to figure out how to change the behavior of things in base/ in  
ways that might effects many different ports, even when those  
improvements are worthwhile.

My proposal is that work continue on ToT and this premature notion of  
releases be dropped until MacPorts is truly ready to run through all  
of its ports and figure out what's broken and what's not.   
Speculative development can still be done on branches and need not  
perturb ToT until all the pieces are ready to come together, but ToT  
should simply be the commonly-advancing front of MacPorts and if  
something is broken, a user who tracks it can generally be assured of  
a fix (either in base/ or dports/ as applicable) simply by keeping  
their tree up to date and waiting 24 hours.

As I've also implied in the previous paragraph, I don't think  
releases are a bad idea *eventually*, I just don't think it's  
something MacPorts should be doing until it substantially improves  
its technology to the point where the general health of MacPorts, and  
I do mean all the ports and possibly even "their popular variants"  
are testable.

- Jordan


From ryandesign at macports.org  Mon Apr  2 03:13:12 2007
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue Oct  9 16:40:09 2007
Subject: Hacking in Universal -- Don't!
In-Reply-To: <263886AD-C3A3-4D37-A9ED-3A386A8D2B60@macports.org>
References: <263886AD-C3A3-4D37-A9ED-3A386A8D2B60@macports.org>
Message-ID: <8BF204B6-72EB-436F-902C-4B71F8B99EE3@macports.org>


On Mar 31, 2007, at 12:28, Landon Fuller wrote:

> I received a bug report about the zlib port not working -- it was  
> modified to use private API in an attempt to hack in Universal  
> support.
>
> The port, which I originally wrote in 2003, went from this:
> 	http://trac.macports.org/projects/macports/browser/trunk/dports/ 
> archivers/zlib/Portfile?rev=23414
> to this:
> 	http://trac.macports.org/projects/macports/browser/trunk/dports/ 
> archivers/zlib/Portfile?rev=22776
>
> This is not an improvement! The port is literally twice as long,  
> but more importantly, it *FAILS* on different versions of MacPorts  
> because it uses MacPorts-private undocumented API calls.
>
> I believe we need a very straight-forward policy:
> 	- Do not use undocumented, private API in Portfiles. This will  
> cause breakage and make the system entirely unmaintainable.
> 	- If making a Portfile "Universal" complicates the Portfile, then  
> you need to patch the software, not the port.

I don't want to say too much more on this topic since so much has  
already been said. But just to sum up the situation with the zlib  
port from my perspective:

There was a push for universal support. I had already figured out how  
to build zlib universal outside of MacPorts and wanted to share the  
joy, since it wasn't as straightforward as it would be with a normal  
autoconf-based package. I modified the zlib portfile locally and  
tested it to ensure that it built what I believed to be a universal  
library. I submitted a ticket [1] with a patch. Kevin Ballard, who  
clearly has more portfile experience than I, posted a much cleaner  
revised version of the patch, which also improved upon the portfile  
generally by printing status messages for the static build. He, Elias  
and I all confirmed that this produced universal libraries on our  
respective systems. (I do not know which versions of MacPorts you're  
talking about on which it did not work, but I would say that  
supporting the currently released version is enough, and to my best  
ability to test it, the patch did work on the then-current version of  
MacPorts, 1.320.) After four days, you had not responded to the  
ticket, and in fact by that time you were no longer listed as the  
maintainer of the port, since you did not update your address to a  
macports.org address by the deadline and all opendarwin.org addresses  
were deleted from all ports. Since I was interested in the port, I  
took over maintainership. You did not object or provide any feedback,  
and Elias waited an additional 11 days before committing the tested  
patch. I don't recall any tickets or emails to the lists about  
problems with this version of the zlib port.

Saying not to use undocumented private APIs is difficult for me to  
comply with, since I basically do all my portfile work by example,  
and can find no current documentation about MacPorts at all. I learn  
what functions are available by looking at other ports, and I have no  
way of knowing which of them may be public or private. (In fact I  
would say if something is supposed to be private, it should not be  
architecturally possible for it to be used from a portfile.) I  
occasionally refer to the old guide at darwinports.opendarwin.org,  
but no up-to-date version of this exists on www.macports.org. And the  
old guide doesn't tell me everything that I want to know about  
portfiles, or just mentions that some feature exists without  
explaining how to properly use it, or explains it badly.

I agree that complicated universal support in a portfile probably  
points to either missing functionality in base, or a deficiency in  
the underlying software package. But there are a lot more people who  
are willing and able to tweak portfiles than change the base code. I  
think it's ok to try things out in portfiles, to get a feel for what  
new things are needed in base. So long, of course, as this playing  
around doesn't break the port for people running the latest released  
MacPorts. And as for the underlying software, sometimes the  
developers are just unwilling to make their software compile  
universal easily. For example, the developers of cairo decline to  
make a single-pass universal compilation of cairo possible; they  
require multiple configure / make passes, one for each architecture,  
followed by lipoing everything together. As the MacPorts community  
may not be able to convince all developers of such software to make  
their compilation process universal-friendly, this is a reality that  
MacPorts may also want to provide an easy solution for.


[1] http://trac.macosforge.org/projects/macports/ticket/11438


From markd at macports.org  Mon Apr  2 12:21:39 2007
From: markd at macports.org (markd@macports.org)
Date: Tue Oct  9 16:40:09 2007
Subject: linking to a library within destroot directory
Message-ID: <fc.004c4c580c466d8b004c4c580c466d8b.c469075@biola.edu>

What can we do when an app wants to link to a library that is part of the
app distro and within the destroot directory?  So that after installation
the app won't give a "Library not loaded" message because it is trying to
find it in the now non-existent destroot directory.

Mark


From roederja at student.ethz.ch  Mon Apr  2 15:24:53 2007
From: roederja at student.ethz.ch (=?UTF-8?B?SmFubiBSw7ZkZXI=?=)
Date: Tue Oct  9 16:40:09 2007
Subject: linking to a library within destroot directory
In-Reply-To: <fc.004c4c580c466d8b004c4c580c466d8b.c469075@biola.edu>
References: <fc.004c4c580c466d8b004c4c580c466d8b.c469075@biola.edu>
Message-ID: <eurvrl$1k3$1@sea.gmane.org>

You need to hack the makefile to pass the -install_name parameter to the
linker. See the mico port for an example of how to do that.

markd@macports.org wrote:
> What can we do when an app wants to link to a library that is part of the
> app distro and within the destroot directory?  So that after installation
> the app won't give a "Library not loaded" message because it is trying to
> find it in the now non-existent destroot directory.
> 
> Mark
> 


From markd at macports.org  Mon Apr  2 15:33:31 2007
From: markd at macports.org (markd@macports.org)
Date: Tue Oct  9 16:40:09 2007
Subject: linking to a library within destroot directory
In-Reply-To: <eurvrl$1k3$1@sea.gmane.org>
References: <fc.004c4c580c466d8b004c4c580c466d8b.c469075@biola.edu>
	<eurvrl$1k3$1@sea.gmane.org>
Message-ID: <fc.004c4c580c46d527004c4c580c466d8b.c46d76c@biola.edu>

Ah I see.  Thanks!  So would a patch like that be a good thing to pass
upstream, or would developers think this unnecessary and/or problematic
for general use for some reason?

Mark

Jann R?der <roederja@student.ethz.ch> on Monday, April 2, 2007 at 3:24 PM
-0800 wrote:
>You need to hack the makefile to pass the -install_name parameter to the
>linker. See the mico port for an example of how to do that.
>
>markd@macports.org wrote:
>> What can we do when an app wants to link to a library that is part of
>the
>> app distro and within the destroot directory?  So that after
>installation
>> the app won't give a "Library not loaded" message because it is trying
>to
>> find it in the now non-existent destroot directory.


From roederja at student.ethz.ch  Mon Apr  2 15:58:42 2007
From: roederja at student.ethz.ch (=?UTF-8?B?SmFubiBSw7ZkZXI=?=)
Date: Tue Oct  9 16:40:09 2007
Subject: linking to a library within destroot directory
In-Reply-To: <fc.004c4c580c46d527004c4c580c466d8b.c46d76c@biola.edu>
References: <fc.004c4c580c466d8b004c4c580c466d8b.c469075@biola.edu>	<eurvrl$1k3$1@sea.gmane.org>
	<fc.004c4c580c46d527004c4c580c466d8b.c46d76c@biola.edu>
Message-ID: <eus1r2$7nq$1@sea.gmane.org>

I think -install_name is mac OS X / darwin specific. I think on Linux
and the like, the install location of the libraries isn't coded into the
apllications that link against them. And for macports you need to use
reinplace anyway to insert the correct library path...

markd@macports.org wrote:
> Ah I see.  Thanks!  So would a patch like that be a good thing to pass
> upstream, or would developers think this unnecessary and/or problematic
> for general use for some reason?
> 
> Mark
> 
> Jann R?der <roederja@student.ethz.ch> on Monday, April 2, 2007 at 3:24 PM
> -0800 wrote:
>> You need to hack the makefile to pass the -install_name parameter to the
>> linker. See the mico port for an example of how to do that.
>>
>> markd@macports.org wrote:
>>> What can we do when an app wants to link to a library that is part of
>> the
>>> app distro and within the destroot directory?  So that after
>> installation
>>> the app won't give a "Library not loaded" message because it is trying
>> to
>>> find it in the now non-existent destroot directory.
> 


From ramercer at gmail.com  Mon Apr  2 18:31:39 2007
From: ramercer at gmail.com (Adam Mercer)
Date: Tue Oct  9 16:40:09 2007
Subject: [11712] update bazaar-ng to 0.15
Message-ID: <799406d60704021831n53e950caxd5dafb342487c2cd@mail.gmail.com>

Hi

I've submitted a ticked updating the bazaar-ng port to the recently
released 0.15. Could someone with commit access please review and
commit this?

http://trac.macports.org/projects/macports/ticket/11712

Cheers

Adam

From ryandesign at macports.org  Mon Apr  2 20:00:07 2007
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue Oct  9 16:40:09 2007
Subject: [11712] update bazaar-ng to 0.15
In-Reply-To: <799406d60704021831n53e950caxd5dafb342487c2cd@mail.gmail.com>
References: <799406d60704021831n53e950caxd5dafb342487c2cd@mail.gmail.com>
Message-ID: <6221A7BE-2B58-4BBE-B107-0580CCC2796F@macports.org>

On Apr 2, 2007, at 20:31, Adam Mercer wrote:

> I've submitted a ticked updating the bazaar-ng port to the recently
> released 0.15. Could someone with commit access please review and
> commit this?
>
> http://trac.macports.org/projects/macports/ticket/11712

Sure; done in r23494.



From ramercer at gmail.com  Mon Apr  2 20:04:03 2007
From: ramercer at gmail.com (Adam Mercer)
Date: Tue Oct  9 16:40:09 2007
Subject: [11712] update bazaar-ng to 0.15
In-Reply-To: <6221A7BE-2B58-4BBE-B107-0580CCC2796F@macports.org>
References: <799406d60704021831n53e950caxd5dafb342487c2cd@mail.gmail.com>
	<6221A7BE-2B58-4BBE-B107-0580CCC2796F@macports.org>
Message-ID: <799406d60704022004w33bbe317o97219ef4e57af849@mail.gmail.com>

On 02/04/07, Ryan Schmidt <ryandesign@macports.org> wrote:
> On Apr 2, 2007, at 20:31, Adam Mercer wrote:
>
> > I've submitted a ticked updating the bazaar-ng port to the recently
> > released 0.15. Could someone with commit access please review and
> > commit this?
> >
> > http://trac.macports.org/projects/macports/ticket/11712
>
> Sure; done in r23494.

Thanks

Cheers

Adam

From rhwood at mac.com  Tue Apr  3 01:34:53 2007
From: rhwood at mac.com (Randall Wood)
Date: Tue Oct  9 16:40:09 2007
Subject: [23503] trunk/dports/gnome
In-Reply-To: <20070403082453.A23A0510ADE@cvs.opensource.apple.com>
References: <20070403082453.A23A0510ADE@cvs.opensource.apple.com>
Message-ID: <C470F0E7-E5D4-4362-A9B4-BA355EA51B6D@mac.com>

can you put a note (even if only in comments) about why you are  
splitting libgtkhtml into versioned ports into the Portfile?

On 3 Apr 2007, at 04:24, source_changes@macosforge.org wrote:

> Revision 23503 Author mas@macports.org Date 2007-04-03 01:24:52  
> -0700 (Tue, 03 Apr 2007) Log Message NEW: libgtkhtml312 3.12.2  
> Added Paths
> trunk/dports/gnome/libgtkhtml312/
> trunk/dports/gnome/libgtkhtml312/Portfile
> Diff
> Added: trunk/dports/gnome/libgtkhtml312/Portfile (0 => 23503) ---  
> trunk/dports/gnome/libgtkhtml312/Portfile	 (rev 0) +++ trunk/dports/ 
> gnome/libgtkhtml312/Portfile	2007-04-03 08:24:52 UTC (rev 23503) @@  
> -0,0 +1,25 @@ +# $Id$ +PortSystem 1.0 +name libgtkhtml312 +version	  
> 3.12.2 +description	GTK HTML rendering engine. +long_description	 
> GtkHTML is a lightweight HTML rendering/printing/editing \ +	  
> engine. It was originally based on KHTMLW, part of the \ +	 KDE  
> project, but is now being developed independently. +maintainers	 
> mas@macports.org +categories	gnome +platforms	darwin +homepage	 
> http://www.gnome.org/ +master_sites gnome:sources/gtkhtml/3.12/  
> +distname	gtkhtml-${version} +use_bzip2	yes + +checksums	rmd160  
> c8445d3e8893c0d99da1d153e984d5f567ff1a08 + +depends_lib	\ +	 
> lib:gailutil:gail \ +	port:libgnomeui \ +	port:dbus \ +	port:dbus- 
> glib + +configure.env	GMSGFMT=${prefix}/bin/msgfmt Property changes  
> on: trunk/dports/gnome/libgtkhtml312/Portfile  
> ___________________________________________________________________  
> Name: svn:keywords + Id Name: svn:eol-style + native
> _______________________________________________
> macports-changes mailing list
> macports-changes@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-changes


Randall Wood
rhwood@mac.com

"The rules are simple: The ball is round. The game lasts 90 minutes.  
All the
rest is just philosophy."



From rhwood at mac.com  Tue Apr  3 01:46:01 2007
From: rhwood at mac.com (Randall Wood)
Date: Tue Oct  9 16:40:09 2007
Subject: [23505] trunk/dports/gnome/libgtkhtml312/Portfile
In-Reply-To: <20070403083854.CBFD4510B32@cvs.opensource.apple.com>
References: <20070403083854.CBFD4510B32@cvs.opensource.apple.com>
Message-ID: <1DAE8676-1714-4D91-A120-416CB3574E99@mac.com>

Thank you.

On 3 Apr 2007, at 04:38, source_changes@macosforge.org wrote:

> Revision 23505 Author mas@macports.org Date 2007-04-03 01:38:54  
> -0700 (Tue, 03 Apr 2007) Log Message explain why the versioned port  
> is required, as requested by Randall Wood Modified Paths
> trunk/dports/gnome/libgtkhtml312/Portfile
> Diff
> Modified: trunk/dports/gnome/libgtkhtml312/Portfile (23504 =>  
> 23505) --- trunk/dports/gnome/libgtkhtml312/Portfile	2007-04-03  
> 08:28:24 UTC (rev 23504) +++ trunk/dports/gnome/libgtkhtml312/ 
> Portfile	2007-04-03 08:38:54 UTC (rev 23505) @@ -4,8 +4,13 @@  
> version	 3.12.2 description	GTK HTML rendering engine.  
> long_description	GtkHTML is a lightweight HTML rendering/printing/ 
> editing \ -	 engine. It was originally based on KHTMLW, part of the  
> \ -	 KDE project, but is now being developed independently. +	  
> engine. libgtkhtml312 contains the last version of \ +	 libgtkhtml  
> that contains the previous printing API. \ +	 It is required for  
> some ports that have not yet \ +	 switched to the new API or cannot  
> do so for some \ +	 reason, and would break with the current  
> version of \ +	 libgtkhtml3. Several versions of libgtkhtml can \  
> +	 co-exist on the same machine. maintainers	mas@macports.org  
> categories	gnome platforms	darwin
> _______________________________________________
> macports-changes mailing list
> macports-changes@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-changes


Randall Wood
rhwood@mac.com

"The rules are simple: The ball is round. The game lasts 90 minutes.  
All the
rest is just philosophy."



From mas at seligma.com  Tue Apr  3 01:46:56 2007
From: mas at seligma.com (=?ISO-8859-1?Q?Marc_Andr=E9_Selig?=)
Date: Tue Oct  9 16:40:09 2007
Subject: [23503] trunk/dports/gnome
In-Reply-To: <C470F0E7-E5D4-4362-A9B4-BA355EA51B6D@mac.com>
References: <20070403082453.A23A0510ADE@cvs.opensource.apple.com>
	<C470F0E7-E5D4-4362-A9B4-BA355EA51B6D@mac.com>
Message-ID: <031E6F21-2CA0-44F5-AC91-C9D6AAC0E798@seligma.com>

On 03.04.2007, at 10:34, Randall Wood wrote:

> can you put a note (even if only in comments) about why you are  
> splitting libgtkhtml into versioned ports into the Portfile?

Sure. :)

--- trunk/dports/gnome/libgtkhtml312/Portfile (revision 23503)
+++ trunk/dports/gnome/libgtkhtml312/Portfile (revision 23505)
@@ -5,6 +5,11 @@
  description	GTK HTML rendering engine.
  long_description	GtkHTML is a lightweight HTML rendering/printing/ 
editing \
-			engine. It was originally based on KHTMLW, part of the \
-			KDE project, but is now being developed independently.
+			engine. libgtkhtml312 contains the last version of \
+			libgtkhtml that contains the previous printing API. \
+			It is required for some ports that have not yet \
+			switched to the new API or cannot do so for some \
+			reason, and would break with the current version of \
+			libgtkhtml3.  Several versions of libgtkhtml can \
+			co-exist on the same machine.
  maintainers	mas@macports.org
  categories	gnome

Regards,
Marc


From markd at macports.org  Tue Apr  3 08:28:40 2007
From: markd at macports.org (markd@macports.org)
Date: Tue Oct  9 16:40:09 2007
Subject: [23511] trunk/dports/x11/XFree86
In-Reply-To: <20070403125025.4B82051275C@cvs.opensource.apple.com>
References: <20070403125025.4B82051275C@cvs.opensource.apple.com>
Message-ID: <fc.004c4c580c4837323b9aca00a7e5ef19.c483959@biola.edu>

macports-dev@lists.macosforge.org on Tuesday, April 3, 2007 at 5:50 AM
-0800 wrote:
>Revision
>[ http://trac.macosforge.org/projects/macports/changeset/23511 ]23511
>Author
>yves@macports.org
>Date
>2007-04-03 05:50:24 -0700 (Tue, 03 Apr 2007)
>
>Log Message
>
>XFree86 4.6.0 with joyful enhancements like :
>
>* warn about a pre-existing Apple X11 installation before even fetching
>the sources.
>* include freetype and security patches from fink

Nice!  Will it detect when Apple's X11 is installed *without* X11DSK?  Or
the reverse, which I think is the purpose of this proposed solution in
Trac.

http://trac.macosforge.org/projects/macports/attachment/ticket/10238/patch-Portfile.diff

Mark


From yves at macports.org  Tue Apr  3 08:47:05 2007
From: yves at macports.org (Yves de Champlain)
Date: Tue Oct  9 16:40:09 2007
Subject: [23511] trunk/dports/x11/XFree86
In-Reply-To: <fc.004c4c580c4837323b9aca00a7e5ef19.c483959@biola.edu>
References: <20070403125025.4B82051275C@cvs.opensource.apple.com>
	<fc.004c4c580c4837323b9aca00a7e5ef19.c483959@biola.edu>
Message-ID: <BCF319E8-5DD3-4087-8534-13FDBFA5A3CF@macports.org>


Le 07-04-03 ? 11:28, markd@macports.org a ?crit :

> macports-dev@lists.macosforge.org on Tuesday, April 3, 2007 at 5:50 AM
> -0800 wrote:
>> Revision
>> [ http://trac.macosforge.org/projects/macports/changeset/23511 ]23511
>> Author
>> yves@macports.org
>> Date
>> 2007-04-03 05:50:24 -0700 (Tue, 03 Apr 2007)
>>
>> Log Message
>>
>> XFree86 4.6.0 with joyful enhancements like :
>>
>> * warn about a pre-existing Apple X11 installation before even  
>> fetching
>> the sources.
>> * include freetype and security patches from fink
>
> Nice!  Will it detect when Apple's X11 is installed *without*  
> X11DSK?  Or
> the reverse, which I think is the purpose of this proposed solution in
> Trac.
>
> http://trac.macosforge.org/projects/macports/attachment/ticket/ 
> 10238/patch-Portfile.diff

Good idea, I had not seen this ticket.  I'll make something up.

yves


From markd at macports.org  Tue Apr  3 09:46:21 2007
From: markd at macports.org (markd@macports.org)
Date: Tue Oct  9 16:40:09 2007
Subject: [23516] trunk/dports/x11/XFree86/Portfile
In-Reply-To: <20070403163047.923B951307C@cvs.opensource.apple.com>
References: <20070403163047.923B951307C@cvs.opensource.apple.com>
Message-ID: <fc.004c4c580c485e493b9aca005c9ceab4.c486545@biola.edu>

macports-dev@lists.macosforge.org on Tuesday, April 3, 2007 at 9:30 AM
-0800 wrote:
>Revision
>[ http://trac.macosforge.org/projects/macports/changeset/23516 ]23516
>Author
>yves@macports.org
>Date
>2007-04-03 09:30:46 -0700 (Tue, 03 Apr 2007)
>
>Log Message
>
>Make a more complete check :
>for Apple X11 with or without X11SDK (ticket:6188)
>for Apple X11SDK without X11 (ticket:10238)
>Also good for ticket:1551

Great.  Can any of the other three related to XFree be closed?

http://trac.macosforge.org/projects/macports/ticket/2102
http://trac.macosforge.org/projects/macports/ticket/3073
http://trac.macosforge.org/projects/macports/ticket/5065

Mark


From yves at macports.org  Tue Apr  3 10:27:13 2007
From: yves at macports.org (Yves de Champlain)
Date: Tue Oct  9 16:40:09 2007
Subject: [23516] trunk/dports/x11/XFree86/Portfile
In-Reply-To: <fc.004c4c580c485e493b9aca005c9ceab4.c485f52@biola.edu>
References: <20070403163047.923B951307C@cvs.opensource.apple.com>
	<fc.004c4c580c485e493b9aca005c9ceab4.c485f52@biola.edu>
Message-ID: <2404B5F0-05D0-4C8B-AD3E-EFD0B0D81B95@macports.org>


Le 07-04-03 ? 12:46, Mark Duling a ?crit :

> macports-dev@lists.macosforge.org on Tuesday, April 3, 2007 at 9:30 AM
> -0800 wrote:
>> Revision
>> [ http://trac.macosforge.org/projects/macports/changeset/23516 ]23516
>> Author
>> yves@macports.org
>> Date
>> 2007-04-03 09:30:46 -0700 (Tue, 03 Apr 2007)
>>
>> Log Message
>>
>> Make a more complete check :
>> for Apple X11 with or without X11SDK (ticket:6188)
>> for Apple X11SDK without X11 (ticket:10238)
>> Also good for ticket:1551
>
> Great.  Can any of the other three related to XFree be closed?
>
> http://trac.macosforge.org/projects/macports/ticket/2102

This one is about Xorg.  Xorg 7.2 supports GNU Hurd and Windows but  
still not darwin ... I wonder if we should not dump it altogether.   
Maybe do the same for Xfree86_44 ?

> http://trac.macosforge.org/projects/macports/ticket/3073

Don't know, I haven't tried.  But it looks like a very weird idea to me.
I mean, what can it give except loads of problems ?
But I'm still young and naive ...

> http://trac.macosforge.org/projects/macports/ticket/5065

Closed.  I did not think it was still open, never was a good idea  
anyway.

Thanks

yves


From ryandesign at macports.org  Tue Apr  3 13:58:55 2007
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue Oct  9 16:40:09 2007
Subject: [23516] trunk/dports/x11/XFree86/Portfile
In-Reply-To: <2404B5F0-05D0-4C8B-AD3E-EFD0B0D81B95@macports.org>
References: <20070403163047.923B951307C@cvs.opensource.apple.com>
	<fc.004c4c580c485e493b9aca005c9ceab4.c485f52@biola.edu>
	<2404B5F0-05D0-4C8B-AD3E-EFD0B0D81B95@macports.org>
Message-ID: <F264ACCB-79ED-44F6-BFDD-F645CD362CB0@macports.org>


On Apr 3, 2007, at 12:27, Yves de Champlain wrote:

>> http://trac.macosforge.org/projects/macports/ticket/3073
>
> Don't know, I haven't tried.  But it looks like a very weird idea  
> to me.
> I mean, what can it give except loads of problems ?
> But I'm still young and naive ...

The bug says:

"I tried to install XFree86 on MacOS 10.3 I have Apple's X11  
(including development files) installed."

As far as I can see, the user has just identified his problem right  
there. As far as I have been aware, you can either have XFree86 or  
Apple's X11 but not both because they go in the same place. I would  
close the bug as invalid, unless my understanding of this situation  
is wrong...


From yves at macports.org  Tue Apr  3 14:15:19 2007
From: yves at macports.org (Yves de Champlain)
Date: Tue Oct  9 16:40:09 2007
Subject: [23516] trunk/dports/x11/XFree86/Portfile
In-Reply-To: <F264ACCB-79ED-44F6-BFDD-F645CD362CB0@macports.org>
References: <20070403163047.923B951307C@cvs.opensource.apple.com>
	<fc.004c4c580c485e493b9aca005c9ceab4.c485f52@biola.edu>
	<2404B5F0-05D0-4C8B-AD3E-EFD0B0D81B95@macports.org>
	<F264ACCB-79ED-44F6-BFDD-F645CD362CB0@macports.org>
Message-ID: <6CB6B10D-6432-4B03-A0B5-BCCD39CA7346@macports.org>


Le 07-04-03 ? 16:58, Ryan Schmidt a ?crit :

>
> On Apr 3, 2007, at 12:27, Yves de Champlain wrote:
>
>>> http://trac.macosforge.org/projects/macports/ticket/3073
>>
>> Don't know, I haven't tried.  But it looks like a very weird idea  
>> to me.
>> I mean, what can it give except loads of problems ?
>> But I'm still young and naive ...
>
> The bug says:
>
> "I tried to install XFree86 on MacOS 10.3 I have Apple's X11  
> (including development files) installed."
>
> As far as I can see, the user has just identified his problem right  
> there. As far as I have been aware, you can either have XFree86 or  
> Apple's X11 but not both because they go in the same place. I would  
> close the bug as invalid, unless my understanding of this situation  
> is wrong...

This would be a duplicate.  What is particular here is "setting  
x11prefix" that don't work.  But is it even supposed to ?

yves


From rhwood at mac.com  Tue Apr  3 18:16:52 2007
From: rhwood at mac.com (Randall Wood)
Date: Tue Oct  9 16:40:09 2007
Subject: MPWA
Message-ID: <03CAB3E8-9CA2-4D30-A87C-2CEA54126E83@mac.com>

What is this intended to be?

Randall Wood
rhwood@mac.com

"The rules are simple: The ball is round. The game lasts 90 minutes.  
All the
rest is just philosophy."



From jberry at macports.org  Tue Apr  3 18:51:09 2007
From: jberry at macports.org (James Berry)
Date: Tue Oct  9 16:40:09 2007
Subject: MPWA
In-Reply-To: <03CAB3E8-9CA2-4D30-A87C-2CEA54126E83@mac.com>
References: <03CAB3E8-9CA2-4D30-A87C-2CEA54126E83@mac.com>
Message-ID: <CB6EE360-F7D0-4067-B99C-347FF01C8C7D@macports.org>


On Apr 3, 2007, at 6:16 PM, Randall Wood wrote:

> What is this intended to be?

A web-application to handle a network-accessible repository and human- 
readable/searchable information for ports.

mpwa stands for "macports web app".

But it's not a GUI for installing ports. It runs on the web, not on  
the local machine.

The following might give you some more clues, though it probably  
misses the big picture:

	http://trac.macosforge.org/projects/macports/browser/users/jberry/ 
mpwa/doc/design.txt

James

>
> Randall Wood
> rhwood@mac.com
>
> "The rules are simple: The ball is round. The game lasts 90  
> minutes. All the
> rest is just philosophy."
>
>


From rhwood at mac.com  Wed Apr  4 01:30:00 2007
From: rhwood at mac.com (Randall Wood)
Date: Tue Oct  9 16:40:09 2007
Subject: Uninstall an obsolete from another (conflicting) port
Message-ID: <C22560C6-5996-4676-9EDA-C86DDCD86A4B@mac.com>

What's the best way to do this?

I have seen calls in ports doing this in the past like:

pre-install {
	system "port -f uninstall xxx"
}

Which is not really the way to do it. Clearly the best way would be  
loop the list of versions of the port and uninstall each one using  
the MacPorts API, but given the state of the docs...

Randall Wood
rhwood@mac.com

"The rules are simple: The ball is round. The game lasts 90 minutes.  
All the
rest is just philosophy."



From rhwood at mac.com  Wed Apr  4 01:49:28 2007
From: rhwood at mac.com (Randall Wood)
Date: Tue Oct  9 16:40:09 2007
Subject: portindex -a
Message-ID: <13230209-40AA-4C6E-9445-B722BD22CC7B@mac.com>

Are there any mechanisms in place to take advantage of the portindex - 
a option?

Or if I have a collection of the archives created with that option  
how would I use them?

Randall Wood
rhwood@mac.com

"The rules are simple: The ball is round. The game lasts 90 minutes.  
All the
rest is just philosophy."



From rhwood at mac.com  Wed Apr  4 03:14:43 2007
From: rhwood at mac.com (Randall Wood)
Date: Tue Oct  9 16:40:09 2007
Subject: An idea for distributing ports
Message-ID: <95F55999-D4A8-44D5-ADCA-9C479F9A2BD7@mac.com>

This is one of those while doing something unrelated ideas that  
suddenly crystalizes while (classically) in the shower or attending a  
meeting...

The idea is this:

Stable and Unstable Ports trees available via both rsync and http

Port currently works by grabbing info out of the port registry and  
PortIndex file(s) on the local system and by looking at Portfiles in  
the source trees whenever it is going to change the state of the  
system by installing/uninstalling/activating/deactivating/whatever a  
port.

I see no reason to change that except to allow for http-based syncing  
of the source tree, which could work the following way:
	1) port sync/selfupdate download the PortIndex
	2) when a port operation that changes the system state is done, if  
the requested port is in the PortIndex and either the Portfile does  
not exist or the version of the Portfile is not equal to the version  
in the PortIndex, then the portfile archive (portname.tgz as  
generated by portindex -a) is downloaded, extracted, and used.

Http syncing would allow users who are having to maintain the tree in  
svn because they can not rsync do to firewall/proxy restrictions to  
no longer have to live in our working area, and would allow port to  
do the syncing in that case once again.

The Stable/Unstable port branches:
This is conceptually pretty simple, and I hope technically simple as  
well.

The current rsync sources would remain in place to support users of  
MacPorts versions that do not support the concept of stable/unstable  
branches before being turned off sometime after a version of port is  
released that understands the ides of stable/unstable branches or how  
to use the port.tgz files

Unstable:
This branch would be a new rync tree, generating its own PortIndex.  
It would be synced againt the svn source code repository multiple  
times daily, grabbing all changes in the repository. It would serve  
both rsync and http-based sync operations.

Stable:
This branch would be a new rsync tree, generating its own PortIndex.  
When this branch is started it would be a verbatim copy of the  
unstable branch, becoming stable as other rules are met. This branch  
would sync off the unstable branch only those files that have stayed  
in the unstable branch without changing within the past 2 weeks and  
would be synced daily. It would serve both rsync and http-based sync  
operations.

The idea behind the stable branch is this: When a portfile fails to  
parse in the unstable branch and causes port installation/upgrades to  
simply fail (like happened during the recent zlib problem) or causes  
other ports to break (like happened in the last gettext and  
libgtkhtml3 upgrades), it would be noticed by users of the unstable  
branch, and repair activities would prevent it from being picked up  
by the stable branch, so that once working changes were introduced  
and the port is left alone more than 2 weeks, it then becomes an  
upgrade in the stable branch.

Obviously, an rsync-based port sync operation would have to ignore  
the port.tgz files in the stable/unstable branches. It would also be  
nice to be able to have the source line in sources.conf read like  
{$sync.protocol}server/path/{$sync.branch} or something similar  
instead of having 4 different lines in there with only 1 not  
commented out.

Randall Wood
rhwood@mac.com

"The rules are simple: The ball is round. The game lasts 90 minutes.  
All the
rest is just philosophy."



From yves at macports.org  Wed Apr  4 04:21:58 2007
From: yves at macports.org (Yves de Champlain)
Date: Tue Oct  9 16:40:09 2007
Subject: Uninstall an obsolete from another (conflicting) port
In-Reply-To: <C22560C6-5996-4676-9EDA-C86DDCD86A4B@mac.com>
References: <C22560C6-5996-4676-9EDA-C86DDCD86A4B@mac.com>
Message-ID: <55EF03C6-2FE9-4A74-A1EC-4456D1893ECC@macports.org>


Le 07-04-04 ? 04:30, Randall Wood a ?crit :

> What's the best way to do this?
>
> I have seen calls in ports doing this in the past like:
>
> pre-install {
> 	system "port -f uninstall xxx"
> }
>
> Which is not really the way to do it. Clearly the best way would be  
> loop the list of versions of the port and uninstall each one using  
> the MacPorts API, but given the state of the docs...

IMHO, this should be avoided as much as possible.

But if you got to do it, deactivate should just work.

yves


From mas at seligma.com  Wed Apr  4 06:10:44 2007
From: mas at seligma.com (=?ISO-8859-1?Q?Marc_Andr=E9_Selig?=)
Date: Tue Oct  9 16:40:09 2007
Subject: An idea for distributing ports
In-Reply-To: <95F55999-D4A8-44D5-ADCA-9C479F9A2BD7@mac.com>
References: <95F55999-D4A8-44D5-ADCA-9C479F9A2BD7@mac.com>
Message-ID: <2FC35A54-1359-4577-ABFA-FAC1EB1A37E7@seligma.com>

On 04.04.2007, at 12:14, Randall Wood wrote:

> The idea behind the stable branch is this: When a portfile fails to  
> parse in the unstable branch and causes port installation/upgrades  
> to simply fail (like happened during the recent zlib problem) or  
> causes other ports to break (like happened in the last gettext and  
> libgtkhtml3 upgrades), it would be noticed by users of the unstable  
> branch, and repair activities would prevent it from being picked up  
> by the stable branch, so that once working changes were introduced  
> and the port is left alone more than 2 weeks, it then becomes an  
> upgrade in the stable branch.

Great idea!  Two problems:

(1) "Repair activities" after something is updated might not involve  
the offending port itself, but the port that was broken by it, or new  
compatibility ports made necessary by the update.  These repair  
activities can take a while.

Your suggestion, if implemented verbatim, would mean that the  
offending port (untouched since the problematic update) would become  
"stable" after two weeks, while the broken ports are still being  
updated.  IOW, the broken ports would become broken in the stable  
tree as well, and people tracking stable would only be able to fix  
their systems after "repair activities" have subsided for two weeks.

If we want to implement this, we need a "veto" system that would let  
us flag "offending ports" that are not broken in and of themselves,  
but still cause problems and breakage in other ports.  gettext or  
guile or libgtkhtml3 would have been flagged "offending", with the  
flag being removed only after all affected ports have been repaired.   
Only two weeks after removal of the flag, the port can move to stable.

(2) Some changes that affect several ports at once should really be  
handled as atomic operations.  If a new version of aqbanking will  
only work with a new version of gnucash, updating the one without  
updating the other may break both.  This is just what currently  
happens, but the existence of a stable branch (implying that things  
will work if you just track that one) should have a solution for it.   
Setting and clearing the "veto flag" or touching both ports at the  
same time might be a feasible workaround.  Having versioned  
dependencies would be even better.

Regards,
Marc


From yves at macports.org  Wed Apr  4 06:59:27 2007
From: yves at macports.org (Yves de Champlain)
Date: Tue Oct  9 16:40:09 2007
Subject: depends_lib-delete
Message-ID: <335C0475-1A78-4948-B6BE-D5B6E456DEF3@macports.org>

Is that the right syntax ?

DEBUG: can't set "depends_lib": invalid depspec:
     while executing
"set depends_lib [ldelete ${depends_lib} $val]"
     (procedure "depends_lib-delete" line 5)
     invoked from within
"depends_lib-delete      port:gimp2"
     (procedure "variant-without_gimp" line 7)
     invoked from within
"variant-without_gimp"
     invoked from within
"catch "variant-${name}" result"
Error: Error executing without_gimp: can't set "depends_lib": invalid  
depspec:
Error: Status 1 encountered during processing.

yves


From landonf at macports.org  Wed Apr  4 10:45:51 2007
From: landonf at macports.org (Landon Fuller)
Date: Tue Oct  9 16:40:09 2007
Subject: portindex -a
In-Reply-To: <13230209-40AA-4C6E-9445-B722BD22CC7B@mac.com>
References: <13230209-40AA-4C6E-9445-B722BD22CC7B@mac.com>
Message-ID: <04CD134F-8854-4BA5-97E0-AD0D00792114@macports.org>


On Apr 4, 2007, at 01:49, Randall Wood wrote:

> Are there any mechanisms in place to take advantage of the  
> portindex -a option?
>
> Or if I have a collection of the archives created with that option  
> how would I use them?

I implemented the -a option and HTTP port archive fetching in 2002,  
but it was never used -- I can't recall why.
Presumably it should still work; simply add an http URL to the  
sources.conf that points to a generated "archive" ports tree.

-landonf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070404/6b519f93/PGP.bin
From landonf at macports.org  Wed Apr  4 11:16:09 2007
From: landonf at macports.org (Landon Fuller)
Date: Tue Oct  9 16:40:10 2007
Subject: Uninstall an obsolete from another (conflicting) port
In-Reply-To: <55EF03C6-2FE9-4A74-A1EC-4456D1893ECC@macports.org>
References: <C22560C6-5996-4676-9EDA-C86DDCD86A4B@mac.com>
	<55EF03C6-2FE9-4A74-A1EC-4456D1893ECC@macports.org>
Message-ID: <C8439B44-F0D1-429A-BBE3-D9076BC2F323@macports.org>


On Apr 4, 2007, at 04:21, Yves de Champlain wrote:

>
> Le 07-04-04 ? 04:30, Randall Wood a ?crit :
>
>> What's the best way to do this?
>>
>> I have seen calls in ports doing this in the past like:
>>
>> pre-install {
>> 	system "port -f uninstall xxx"
>> }
>>
>> Which is not really the way to do it. Clearly the best way would  
>> be loop the list of versions of the port and uninstall each one  
>> using the MacPorts API, but given the state of the docs...
>
> IMHO, this should be avoided as much as possible.
>
> But if you got to do it, deactivate should just work.

There's no real safe way to do this without implementing 'conflicts'  
and 'replaces' support of some kind. The propagation of recursive  
calls to port as a work-around is unfortunate, as it's really not a  
safe thing to be doing -- there are no guarantees regarding system  
concurrency/re-entrancy.

-landonf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070404/262610d9/PGP.bin
From andre at splunk.com  Wed Apr  4 13:40:07 2007
From: andre at splunk.com (Andre Stechert)
Date: Tue Oct  9 16:40:10 2007
Subject: Please close ticket #11661 (link enclosed)
Message-ID: <68282F09-1642-44DF-B435-B8842981BF39@splunk.com>

I committed, in revision 23568, the patch in

http://trac.macports.org/projects/macports/ticket/11661

for Mark Moll (mmoll@cs.rice.edu) because he doesn't have commit  
rights, but I can't close the
bug because I don't have TRAC rights.

Thanks,
Andre

p.s. Is there some way for me to get the rights to close a bug?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2442 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070404/3bfc17cd/smime.bin
From markd at macports.org  Wed Apr  4 13:54:37 2007
From: markd at macports.org (markd@macports.org)
Date: Tue Oct  9 16:40:10 2007
Subject: Please close ticket #11661 (link enclosed)
In-Reply-To: <68282F09-1642-44DF-B435-B8842981BF39@splunk.com>
References: <68282F09-1642-44DF-B435-B8842981BF39@splunk.com>
Message-ID: <fc.004c4c580c4b58f73b9aca00ad2af796.c4b5a52@biola.edu>

Andre Stechert <andre@splunk.com> on Wednesday, April 4, 2007 at 1:40 PM
-0800 wrote:
>I committed, in revision 23568, the patch in
>
>http://trac.macports.org/projects/macports/ticket/11661
>
>for Mark Moll (mmoll@cs.rice.edu) because he doesn't have commit  
>rights, but I can't close the
>bug because I don't have TRAC rights.
>
>Thanks,
>Andre
>
>p.s. Is there some way for me to get the rights to close a bug?

I closed it.  Try sending a message to portmgr@ for get rights.

Mark


From yves at macports.org  Wed Apr  4 17:51:27 2007
From: yves at macports.org (Yves de Champlain)
Date: Tue Oct  9 16:40:10 2007
Subject: depends_lib-delete broken ?
Message-ID: <65265401-DE4C-42DE-97B1-0A03BBD28CCE@macports.org>

Could anyone verify what is going on here (or am I going nuts) ?

DEBUG: can't set "depends_lib": invalid depspec:
     while executing
"set depends_lib [ldelete ${depends_lib} $val]"
     (procedure "depends_lib-delete" line 5)
     invoked from within
"depends_lib-delete      port:gimp2"
     (procedure "variant-without_gimp" line 7)
     invoked from within
"variant-without_gimp"
     invoked from within
"catch "variant-${name}" result"
Error: Error executing without_gimp: can't set "depends_lib": invalid  
depspec:
Error: Status 1 encountered during processing.

yves


From boeyms at fastmail.fm  Wed Apr  4 20:00:53 2007
From: boeyms at fastmail.fm (Boey Maun Suang)
Date: Tue Oct  9 16:40:10 2007
Subject: (Chagrined) Could someone with commit rights apply my patch to my
	port?
Message-ID: <97B86005-1035-4247-94BD-37130BDD35B8@fastmail.fm>

Hi everyone,

Sorry to bother you with this, but I submitted a ticket (#11666) to  
update tor-devel, which I currently maintain, but forgot to CC  
macports-dev@ so that someone with commit rights could apply it.   
Would one of you mind helping me out?

Kind regards,


Maun Suang

-- 
Boey Maun Suang (Boey is my surname)
Mobile: +61 403 855 677
Email: boeyms@fastmail.fm



From jberry at macports.org  Wed Apr  4 21:36:54 2007
From: jberry at macports.org (James Berry)
Date: Tue Oct  9 16:40:10 2007
Subject: (Chagrined) Could someone with commit rights apply my patch to
	my port?
In-Reply-To: <97B86005-1035-4247-94BD-37130BDD35B8@fastmail.fm>
References: <97B86005-1035-4247-94BD-37130BDD35B8@fastmail.fm>
Message-ID: <A605BD9E-71C2-48D0-A78D-FEAF5CF6DDEF@macports.org>


On Apr 4, 2007, at 8:00 PM, Boey Maun Suang wrote:

> Hi everyone,
>
> Sorry to bother you with this, but I submitted a ticket (#11666) to  
> update tor-devel, which I currently maintain, but forgot to CC  
> macports-dev@ so that someone with commit rights could apply it.   
> Would one of you mind helping me out?
>

Maun Suang,

Applied in http://trac.macports.org/projects/macports/changeset/23603.

James

>
> Kind regards,
>
>
> Maun Suang
>
> -- 
> Boey Maun Suang (Boey is my surname)
> Mobile: +61 403 855 677
> Email: boeyms@fastmail.fm
>
>
> _______________________________________________
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev


From ryandesign at macports.org  Wed Apr  4 23:34:35 2007
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue Oct  9 16:40:10 2007
Subject: depends_lib-delete
In-Reply-To: <335C0475-1A78-4948-B6BE-D5B6E456DEF3@macports.org>
References: <335C0475-1A78-4948-B6BE-D5B6E456DEF3@macports.org>
Message-ID: <DDE83699-FAA6-40BE-B12D-4D44EE7A3D0F@macports.org>

On Apr 4, 2007, at 08:59, Yves de Champlain wrote:

> Is that the right syntax ?
>
> DEBUG: can't set "depends_lib": invalid depspec:
>     while executing
> "set depends_lib [ldelete ${depends_lib} $val]"
>     (procedure "depends_lib-delete" line 5)
>     invoked from within
> "depends_lib-delete      port:gimp2"
>     (procedure "variant-without_gimp" line 7)
>     invoked from within
> "variant-without_gimp"
>     invoked from within
> "catch "variant-${name}" result"
> Error: Error executing without_gimp: can't set "depends_lib":  
> invalid depspec:
> Error: Status 1 encountered during processing.

I think "depends_lib-delete port:gimp2" should be correct, yes. What  
port are you seeing this problem with?



From jkh at brierdr.com  Thu Apr  5 03:00:26 2007
From: jkh at brierdr.com (Jordan K. Hubbard)
Date: Tue Oct  9 16:40:10 2007
Subject: An idea for distributing ports
In-Reply-To: <95F55999-D4A8-44D5-ADCA-9C479F9A2BD7@mac.com>
References: <95F55999-D4A8-44D5-ADCA-9C479F9A2BD7@mac.com>
Message-ID: <5EB5630E-7B79-47C3-A30D-0CF0DD9B716E@brierdr.com>


On Apr 4, 2007, at 3:14 AM, Randall Wood wrote:

> The idea is this:
>
> Stable and Unstable Ports trees available via both rsync and http
>
> Port currently works by grabbing info out of the port registry and  
> PortIndex file(s) on the local system and by looking at Portfiles  
> in the source trees whenever it is going to change the state of the  
> system by installing/uninstalling/activating/deactivating/whatever  
> a port.

I think this doesn't go far enough from where we currently are to  
justify the work involved.   I'm much more enthusiastic about taking  
Kevin's "remote index" idea to its logical conclusion and also,  
rather than thinking of things in terms of "stable and unstable  
branches", go to the more powerful model of port attributes which  
allows for "stability" to be just one possible search/selection  
criteria.

For those who didn't follow the whole remote index discussion way  
back when it happened, the general concepts were as follows:

1. dports/ as a hierarchy of directories and files goes away.   It is  
replaced by a flat "database" (at least conceptually - the back-end  
implementation of this database can be done any number of ways, from  
the crude to the impressive) of port blobs, where a "blob" is  
basically everything that currently exists in a port directory  
(Portfile + files/ dir) plus a set of attributes.  The most obvious  
attributes to start with would be name, version and category, but of  
course there could be any number (including "stable", "devel" or even  
"unreviewed"), limited only by pragmatism and imagination.

2. sources.conf lists one or more database sources, by http: URL.   
Since pretty much everyone's firewall allows http access, that gets  
around that particular problem, though other types of URLs could of  
course be supported (including, of course, a local database for  
disconnected operation).

3. Assuming that a database can be contacted, "port install foo" then  
becomes:
	3a). Dispatch a search query for foo
	3b). foo is found (let's assume that) and its blob is sent back.
	3c). The blob is unpacked and port walks in there to deal with the  
Portfile (and files/) just as it does today.  For all dependencies,  
of course, repeat steps 3a-3c recursively as needed.
	3d). Clean up and remove the blob when finished.

4. Now, since we have a database, other things become possible, such  
as "port submit".   Someone who wants to create a new port and make  
it available to everyone could, conceivably, go write that port, cd  
into its directory and say "port submit foo".  This would cause foo  
to be bundled into a blob and shipped off to the remote database,  
where it would probably (as a matter of policy) be tagged with the  
"unreviewed" attribute.   Anyone else with read access to this  
database could grab that port immediately thereafter and try it for  
themselves, so the database becomes a collaborative tool as well.

It's purely a policy decision, of course, but one could even allow  
for multiple "foos" to exist at the same time, adding some sort of  
disambiguating attribute, so that several people could submit foo  
ports and let the reviewers pick the best for stamping "reviewed".   
We've had people collide in the tree before (usually submitting the  
same port in two different categories), this would simply make that  
less traumatic.  Needless to say, another policy for "port submit  
foo" could also be to emit an error if a foo already existed and  
force the submitter to disambiguate it if they really had a good  
reason for submitting another port of foo.  However we want to go,  
it's fairly simple to implement the policy once all the other work is  
done.

Needless to say, if the database is sufficiently powerful to allow  
for multiple versions of foo to co-exist (and I see no reason why it  
wouldn't be), the need to maintain dports under svn also goes pretty  
much by the wayside.  The database IS an SCM tool unto itself at that  
point.

Also pretty much needless to say, a database means that the index is  
updated whenever something is submitted or has its attributes  
changed, so there's no need to manually recreate and check in a new  
PortIndex.

- Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070405/a1541325/attachment.html
From yves at macports.org  Thu Apr  5 08:59:38 2007
From: yves at macports.org (Yves de Champlain)
Date: Tue Oct  9 16:40:10 2007
Subject: depends_lib-delete
In-Reply-To: <DDE83699-FAA6-40BE-B12D-4D44EE7A3D0F@macports.org>
References: <335C0475-1A78-4948-B6BE-D5B6E456DEF3@macports.org>
	<DDE83699-FAA6-40BE-B12D-4D44EE7A3D0F@macports.org>
Message-ID: <988D8A8B-41F2-44A8-B5CF-1C50F3332E51@macports.org>


Le 07-04-05 ? 02:34, Ryan Schmidt a ?crit :

> On Apr 4, 2007, at 08:59, Yves de Champlain wrote:
>
>> Is that the right syntax ?
>>
>> DEBUG: can't set "depends_lib": invalid depspec:
>>     while executing
>> "set depends_lib [ldelete ${depends_lib} $val]"
>>     (procedure "depends_lib-delete" line 5)
>>     invoked from within
>> "depends_lib-delete      port:gimp2"
>>     (procedure "variant-without_gimp" line 7)
>>     invoked from within
>> "variant-without_gimp"
>>     invoked from within
>> "catch "variant-${name}" result"
>> Error: Error executing without_gimp: can't set "depends_lib":  
>> invalid depspec:
>> Error: Status 1 encountered during processing.
>
> I think "depends_lib-delete port:gimp2" should be correct, yes.  
> What port are you seeing this problem with?

graphics/gimp-user-manual

thanks

yves


From jberry at macports.org  Thu Apr  5 09:21:36 2007
From: jberry at macports.org (James Berry)
Date: Tue Oct  9 16:40:10 2007
Subject: An idea for distributing ports
In-Reply-To: <5EB5630E-7B79-47C3-A30D-0CF0DD9B716E@brierdr.com>
References: <95F55999-D4A8-44D5-ADCA-9C479F9A2BD7@mac.com>
	<5EB5630E-7B79-47C3-A30D-0CF0DD9B716E@brierdr.com>
Message-ID: <33F853BC-FD97-494E-AABA-4A338A78518F@macports.org>


On Apr 5, 2007, at 3:00 AM, Jordan K. Hubbard wrote:

>
> On Apr 4, 2007, at 3:14 AM, Randall Wood wrote:
>
>> The idea is this:
>>
>> Stable and Unstable Ports trees available via both rsync and http
>>
>> Port currently works by grabbing info out of the port registry and  
>> PortIndex file(s) on the local system and by looking at Portfiles  
>> in the source trees whenever it is going to change the state of  
>> the system by installing/uninstalling/activating/deactivating/ 
>> whatever a port.
>
> I think this doesn't go far enough from where we currently are to  
> justify the work involved.   I'm much more enthusiastic about  
> taking Kevin's "remote index" idea to its logical conclusion and  
> also, rather than thinking of things in terms of "stable and  
> unstable branches", go to the more powerful model of port  
> attributes which allows for "stability" to be just one possible  
> search/selection criteria.

Thanks for the recap Jordan. And in case anybody is curious, this is  
pretty the outline of what I've been working on with my mpwa  
(MacPorts Web App) prototype:

	- "port submit" to submit a portpkg to the database which gives it a  
unique pkgid and http: url.
		(A portpkg is simply a bundled up port directory, plus any  
additional meta information we need).

	- A url that may be used to request a particular (previously  
submitted) portpkg.

	- The webapp will also generate html UI to describe and index ports.  
For each port, there is a set of portpkgs for the port, each of which  
will include additional meta information such as:
		- submitter, date, etc.
		- version, epoch, revision
		- variants, dependencies
		- tags
		- Votes (thumbs up/down)
		- Build and/or install reports (go/no-go status, logs from failed  
builds)

	- Jordan describes attributes, I'm thinking tags, since they seem  
more comfortable in these web 2.0 days, but I think they're basically  
the same ;). Some tags might be restricted (perhaps "stable"); most  
will be accessible by all. Tags should also replace the concept of  
category. But the idea is that you can search and/or browse for ports  
by tag, and you might also be able to limit installs to only ports  
that match certain tags, like "stable", or whatever.

	- Some sort of port dependency closure solver interface. So I can  
submit a query that says something like "I've got these ports, with  
these variants installed, and I'd like to end with these ports, with  
these variants, and perhaps restricted only to the latest versions of  
ports with these tags: now tell me what actions need to be taken, in  
which order, to achieve that state." And the answer would come back  
as a set of actions to be take: "remove these ports, install these  
ports/variants (and here are their urls) (and here are their  
binaries)", or "you can't do that, Dave, because you asked for stable  
ports only and version 3.6 of this port is only available without  
that tag". The nice part about doing this over the net is that the  
database of potential portpkgs to install will likely grow far bigger  
than you want to keep locally. The downside, of course, is that you  
need net reachability in order to perform the action. A middle ground  
might be that you could perform the solver query and fetch the needed  
set of portpkgs while online, and do the actual install while  
offline. The reality of MacPorts today, of course, is that you mostly  
need to be online to install anything anyway, since src needs to be  
fetched.

Anyway, those are the ideas I'm playing with. The app I've started  
writing is in Ruby on Rails, and I'm thinking the database will be  
MySQL to contain port/portpkg information, metadata, and dependency  
information.

I'm hoping that some pieces of this may come from GSoC:

	- Dependency analysis given a portpkg (what are the dependencies by  
given each variant).

	- New dependency expressions: a dependency might be expressed onto a  
particular port, plus variants, plus other metadata restrictions:  
version >= 2.5; variants requires (+server, -client); variants  
conflicts (apache); tags has (foo,bar); submitter in (jberry,mww);  
etc. Syntax tbd.

	- Dependency solver

	- Reporting of build status/logs back to the webapp.

There's some design information here, though it's pretty fluid still:  
http://trac.macosforge.org/projects/macports/browser/users/jberry/ 
mpwa/doc/design.txt.

Oh, and I guess it goes without saying that once we build the  
infrastructure do all that, we can also begin to do autobuilds of  
things and to add binaries for portpkgs.

James.




>
> For those who didn't follow the whole remote index discussion way  
> back when it happened, the general concepts were as follows:
>
> 1. dports/ as a hierarchy of directories and files goes away.   It  
> is replaced by a flat "database" (at least conceptually - the back- 
> end implementation of this database can be done any number of ways,  
> from the crude to the impressive) of port blobs, where a "blob" is  
> basically everything that currently exists in a port directory  
> (Portfile + files/ dir) plus a set of attributes.  The most obvious  
> attributes to start with would be name, version and category, but  
> of course there could be any number (including "stable", "devel" or  
> even "unreviewed"), limited only by pragmatism and imagination.
>
> 2. sources.conf lists one or more database sources, by http: URL.   
> Since pretty much everyone's firewall allows http access, that gets  
> around that particular problem, though other types of URLs could of  
> course be supported (including, of course, a local database for  
> disconnected operation).
>
> 3. Assuming that a database can be contacted, "port install foo"  
> then becomes:
> 	3a). Dispatch a search query for foo
> 	3b). foo is found (let's assume that) and its blob is sent back.
> 	3c). The blob is unpacked and port walks in there to deal with the  
> Portfile (and files/) just as it does today.  For all dependencies,  
> of course, repeat steps 3a-3c recursively as needed.
> 	3d). Clean up and remove the blob when finished.
>
> 4. Now, since we have a database, other things become possible,  
> such as "port submit".   Someone who wants to create a new port and  
> make it available to everyone could, conceivably, go write that  
> port, cd into its directory and say "port submit foo".  This would  
> cause foo to be bundled into a blob and shipped off to the remote  
> database, where it would probably (as a matter of policy) be tagged  
> with the "unreviewed" attribute.   Anyone else with read access to  
> this database could grab that port immediately thereafter and try  
> it for themselves, so the database becomes a collaborative tool as  
> well.
>
> It's purely a policy decision, of course, but one could even allow  
> for multiple "foos" to exist at the same time, adding some sort of  
> disambiguating attribute, so that several people could submit foo  
> ports and let the reviewers pick the best for stamping "reviewed".   
> We've had people collide in the tree before (usually submitting the  
> same port in two different categories), this would simply make that  
> less traumatic.  Needless to say, another policy for "port submit  
> foo" could also be to emit an error if a foo already existed and  
> force the submitter to disambiguate it if they really had a good  
> reason for submitting another port of foo.  However we want to go,  
> it's fairly simple to implement the policy once all the other work  
> is done.
>
> Needless to say, if the database is sufficiently powerful to allow  
> for multiple versions of foo to co-exist (and I see no reason why  
> it wouldn't be), the need to maintain dports under svn also goes  
> pretty much by the wayside.  The database IS an SCM tool unto  
> itself at that point.
>
> Also pretty much needless to say, a database means that the index  
> is updated whenever something is submitted or has its attributes  
> changed, so there's no need to manually recreate and check in a new  
> PortIndex.
>
> - Jordan
>
> _______________________________________________
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070405/90695ba3/attachment.html
From markd at macports.org  Thu Apr  5 12:05:49 2007
From: markd at macports.org (markd@macports.org)
Date: Tue Oct  9 16:40:10 2007
Subject: Could a base committer comment on #11012?
Message-ID: <fc.004c4c580c4df1e3004c4c580c4df1e3.c4df2d3@biola.edu>

http://trac.macosforge.org/projects/macports/ticket/11012

Can someone give some feedback on this one?  Good idea, bad, invalid? 
Thanks.

Mark


From jberry at macports.org  Thu Apr  5 12:26:10 2007
From: jberry at macports.org (James Berry)
Date: Tue Oct  9 16:40:10 2007
Subject: MacPorts v1.4.0 release announcement
Message-ID: <B2856D7B-EC1A-43D8-842D-4BCBEDF69E2F@macports.org>

The MacPorts project is pleased to announce the release of MacPorts  
v1.4.0.

Change log is at <http://trac.macosforge.org/projects/macports/ 
browser/tags/release_1_4_0/base/ChangeLog>.
Downloads are available at <http://trac.macosforge.org/projects/ 
macports/browser/downloads/MacPorts-1.4.0>.

Thanks to all project members who contributed to this release, and  
especially to Juan Manuel Palacios, who served as release manager.  
Bugs may be filed at the <http://www.macports.org/?page_id=8>.

We plan to release a v1.4.1 within weeks with some ongoing  
enhancements. Please note that our official plan is to build disk  
images only for 1.x.0 releases, and let subsequent point releases  
selfupdate from there. If you have a previous release of MacPorts  
installed, the easiest path to MacPorts 1.4.0 is simply "sudo port  
selfupdate".

? MacPorts team
From pipping at macports.org  Thu Apr  5 12:30:54 2007
From: pipping at macports.org (Elias Pipping)
Date: Tue Oct  9 16:40:10 2007
Subject: [23628] trunk/dports/lang/scala/Portfile
In-Reply-To: <20070405190912.5ED63515BFB@cvs.opensource.apple.com>
References: <20070405190912.5ED63515BFB@cvs.opensource.apple.com>
Message-ID: <1A20D7A0-C6C4-444F-861D-55F5781C767A@macports.org>

> Log Message
>
> ===========
>
> Tabify.

Why?




From blair at orcaware.com  Thu Apr  5 12:37:53 2007
From: blair at orcaware.com (Blair Zajac)
Date: Tue Oct  9 16:40:10 2007
Subject: [23628] trunk/dports/lang/scala/Portfile
In-Reply-To: <1A20D7A0-C6C4-444F-861D-55F5781C767A@macports.org>
References: <20070405190912.5ED63515BFB@cvs.opensource.apple.com>
	<1A20D7A0-C6C4-444F-861D-55F5781C767A@macports.org>
Message-ID: <46155011.1060109@orcaware.com>

Elias Pipping wrote:
>> Log Message
>>
>> ===========
>>
>> Tabify.
> 
> Why?

To prepare for my next commit.

Blair


From blair at orcaware.com  Thu Apr  5 12:54:33 2007
From: blair at orcaware.com (Blair Zajac)
Date: Tue Oct  9 16:40:10 2007
Subject: Dealing with tarballs that tarbomb
Message-ID: <461553F9.6050805@orcaware.com>

The scala tarball doesn't extract into a new subdirectory and instead 
just extracts into the directory where you run tar, i.e. a tarbomb.  So 
in work/, you see a bin/ and a share/ directory.

Is there an easy, clean way to deal with this in MacPorts?  I looked at 
specifying some extract options, but I didn't see anything.  I tried 
passing the ${distname} to tar -C's option to create the subdirectory, 
but this doesn't work, since the directory to put it in doesn't exist yet.

It looks like another way is to hack it into configure to move the 
directories down a level, but this doesn't seem clean.

Any ideas?

Regards,
Blair


From dluke at geeklair.net  Thu Apr  5 12:59:55 2007
From: dluke at geeklair.net (Daniel J. Luke)
Date: Tue Oct  9 16:40:10 2007
Subject: Dealing with tarballs that tarbomb
In-Reply-To: <461553F9.6050805@orcaware.com>
References: <461553F9.6050805@orcaware.com>
Message-ID: <A8E7E6BB-C698-4B4A-A94B-5685FEE8499C@geeklair.net>

On Apr 5, 2007, at 3:54 PM, Blair Zajac wrote:
> The scala tarball doesn't extract into a new subdirectory and  
> instead just extracts into the directory where you run tar, i.e. a  
> tarbomb.  So in work/, you see a bin/ and a share/ directory.
>
> Is there an easy, clean way to deal with this in MacPorts?  I  
> looked at specifying some extract options, but I didn't see  
> anything.  I tried passing the ${distname} to tar -C's option to  
> create the subdirectory, but this doesn't work, since the directory  
> to put it in doesn't exist yet.

You could create the subdirectory in pre-extract and then do the above.

--
Daniel J. Luke
+========================================================+
| *---------------- dluke@geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
|   Opinions expressed are mine and do not necessarily   |
|          reflect the opinions of my employer.          |
+========================================================+


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070405/7486a5c5/PGP.bin
From opendarwin.org at darkart.com  Thu Apr  5 13:13:18 2007
From: opendarwin.org at darkart.com (Eric Hall)
Date: Tue Oct  9 16:40:10 2007
Subject: Dealing with tarballs that tarbomb
In-Reply-To: <461553F9.6050805@orcaware.com>
References: <461553F9.6050805@orcaware.com>
Message-ID: <20070405201318.GN9160@darkart.com>

On Thu, Apr 05, 2007 at 12:54:33PM -0700, Blair Zajac wrote:
> The scala tarball doesn't extract into a new subdirectory and instead 
> just extracts into the directory where you run tar, i.e. a tarbomb.  So 
> in work/, you see a bin/ and a share/ directory.
> 
> Is there an easy, clean way to deal with this in MacPorts?  I looked at 
> specifying some extract options, but I didn't see anything.  I tried 
> passing the ${distname} to tar -C's option to create the subdirectory, 
> but this doesn't work, since the directory to put it in doesn't exist yet.
> 
> It looks like another way is to hack it into configure to move the 
> directories down a level, but this doesn't seem clean.
> 

	The netcat port handles this problem with:

pre-extract     { system "mkdir -p ${worksrcpath}" }
extract.dir     ${worksrcpath}


		-eric


From blair at orcaware.com  Thu Apr  5 13:42:32 2007
From: blair at orcaware.com (Blair Zajac)
Date: Tue Oct  9 16:40:10 2007
Subject: Dealing with tarballs that tarbomb
In-Reply-To: <A8E7E6BB-C698-4B4A-A94B-5685FEE8499C@geeklair.net>
References: <461553F9.6050805@orcaware.com>
	<A8E7E6BB-C698-4B4A-A94B-5685FEE8499C@geeklair.net>
Message-ID: <46155F38.2060503@orcaware.com>

Daniel J. Luke wrote:
> On Apr 5, 2007, at 3:54 PM, Blair Zajac wrote:
>> The scala tarball doesn't extract into a new subdirectory and instead 
>> just extracts into the directory where you run tar, i.e. a tarbomb.  
>> So in work/, you see a bin/ and a share/ directory.
>>
>> Is there an easy, clean way to deal with this in MacPorts?  I looked 
>> at specifying some extract options, but I didn't see anything.  I 
>> tried passing the ${distname} to tar -C's option to create the 
>> subdirectory, but this doesn't work, since the directory to put it in 
>> doesn't exist yet.
> 
> You could create the subdirectory in pre-extract and then do the above.

Thanks, that did the trick.  Reading portfile and looking through the 
source, I didn't see that option.

Regards,
Blair

From vincent-opdarw at vinc17.org  Thu Apr  5 13:46:01 2007
From: vincent-opdarw at vinc17.org (Vincent Lefevre)
Date: Tue Oct  9 16:40:10 2007
Subject: MacPorts v1.4.0 release announcement
In-Reply-To: <B2856D7B-EC1A-43D8-842D-4BCBEDF69E2F@macports.org>
References: <B2856D7B-EC1A-43D8-842D-4BCBEDF69E2F@macports.org>
Message-ID: <20070405204601.GO932@prunille.vinc17.org>

On 2007-04-05 12:26:10 -0700, James Berry wrote:
>  The MacPorts project is pleased to announce the release of MacPorts v1.4.0.
> 
>  Change log is at 
>  <http://trac.macosforge.org/projects/macports/browser/tags/release_1_4_0/base/ChangeLog>.
>  Downloads are available at 
>  <http://trac.macosforge.org/projects/macports/browser/downloads/MacPorts-1.4.0>.

There's still a bug when I try to build it:

cc -dynamiclib -L/usr/local/lib  -L/usr/lib -lcurl -lssl -lcrypto -lz Pextlib.o strsed.o fgetln.o md5cmd.o setmode.o xinstall.o find.o strcasecmp.o vercomp.o filemap.o sha1cmd.o compat.o curl.o rmd160cmd.o readline.o uid.o -o Pextlib.dylib -L/System/Library/Frameworks/Tcl.framework/Versions/8.4 -ltclstub8.4 -L/usr/local/lib  -L/usr/lib -lcurl -lssl -lcrypto -lz -lreadline  -lcrypto
ld: warning -L: directory name (/usr/local/lib) does not exist
ld: warning -L: directory name (/usr/local/lib) does not exist
ld: Undefined symbols:
_rl_completion_matches
_rl_filename_completion_function
_rl_username_completion_function
/usr/bin/libtool: internal link edit command failed

$ 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
/opt/local/var/db/dports/software/readline/5.1.004_0/opt/local/lib/libreadline.dylib
/opt/local/var/db/dports/software/readline/5.2.001_0/opt/local/lib/libreadline.dylib
/usr/lib/libreadline.dylib

-- 
Vincent Lef?vre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

From dluke at geeklair.net  Thu Apr  5 13:49:38 2007
From: dluke at geeklair.net (Daniel J. Luke)
Date: Tue Oct  9 16:40:10 2007
Subject: MacPorts v1.4.0 release announcement
In-Reply-To: <20070405204601.GO932@prunille.vinc17.org>
References: <B2856D7B-EC1A-43D8-842D-4BCBEDF69E2F@macports.org>
	<20070405204601.GO932@prunille.vinc17.org>
Message-ID: <A068372C-01AE-4214-A89C-03A7C02F21FC@geeklair.net>

On Apr 5, 2007, at 4:46 PM, Vincent Lefevre wrote:
> There's still a bug when I try to build it:
>
> cc -dynamiclib -L/usr/local/lib  -L/usr/lib -lcurl -lssl -lcrypto - 
> lz Pextlib.o strsed.o fgetln.o md5cmd.o setmode.o xinstall.o find.o  
> strcasecmp.o vercomp.o filemap.o sha1cmd.o compat.o curl.o  
> rmd160cmd.o readline.o uid.o -o Pextlib.dylib -L/System/Library/ 
> Frameworks/Tcl.framework/Versions/8.4 -ltclstub8.4 -L/usr/local/ 
> lib  -L/usr/lib -lcurl -lssl -lcrypto -lz -lreadline  -lcrypto
> ld: warning -L: directory name (/usr/local/lib) does not exist
> ld: warning -L: directory name (/usr/local/lib) does not exist
> ld: Undefined symbols:
> _rl_completion_matches
> _rl_filename_completion_function
> _rl_username_completion_function
> /usr/bin/libtool: internal link edit command failed
>
> $ 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
> /opt/local/var/db/dports/software/readline/5.1.004_0/opt/local/lib/ 
> libreadline.dylib
> /opt/local/var/db/dports/software/readline/5.2.001_0/opt/local/lib/ 
> libreadline.dylib
> /usr/lib/libreadline.dylib

The problem IIRC has to do with mismatched headers and library.

So you'll want to do

locate readline.h

and see if there's a stray one (in /usr/local/include, probably)  
that's causing the build to choke.
--
Daniel J. Luke
+========================================================+
| *---------------- dluke@geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
|   Opinions expressed are mine and do not necessarily   |
|          reflect the opinions of my employer.          |
+========================================================+


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070405/40957a14/PGP.bin
From blair at orcaware.com  Thu Apr  5 15:21:56 2007
From: blair at orcaware.com (Blair Zajac)
Date: Tue Oct  9 16:40:10 2007
Subject: Dealing with tarballs that tarbomb
In-Reply-To: <20070405201318.GN9160@darkart.com>
References: <461553F9.6050805@orcaware.com> <20070405201318.GN9160@darkart.com>
Message-ID: <46157684.2050304@orcaware.com>

Eric Hall wrote:
> On Thu, Apr 05, 2007 at 12:54:33PM -0700, Blair Zajac wrote:
>> The scala tarball doesn't extract into a new subdirectory and instead 
>> just extracts into the directory where you run tar, i.e. a tarbomb.  So 
>> in work/, you see a bin/ and a share/ directory.
>>
>> Is there an easy, clean way to deal with this in MacPorts?  I looked at 
>> specifying some extract options, but I didn't see anything.  I tried 
>> passing the ${distname} to tar -C's option to create the subdirectory, 
>> but this doesn't work, since the directory to put it in doesn't exist yet.
>>
>> It looks like another way is to hack it into configure to move the 
>> directories down a level, but this doesn't seem clean.
>>
> 
> 	The netcat port handles this problem with:
> 
> pre-extract     { system "mkdir -p ${worksrcpath}" }
> extract.dir     ${worksrcpath}

Thanks, that's what I ended up going with, however, using file mkdir 
${worksrcpath} instead of the system.

Regards,
Blair


From pipping at macports.org  Thu Apr  5 15:58:00 2007
From: pipping at macports.org (Elias Pipping)
Date: Tue Oct  9 16:40:10 2007
Subject: Dealing with tarballs that tarbomb
In-Reply-To: <46157684.2050304@orcaware.com>
References: <461553F9.6050805@orcaware.com> <20070405201318.GN9160@darkart.com>
	<46157684.2050304@orcaware.com>
Message-ID: <01E3DD0B-3CB8-4D3B-9EC8-B6B0B34E9199@macports.org>

On Apr 6, 2007, at 12:21 AM, Blair Zajac wrote:

> Thanks, that's what I ended up going with, however, using file  
> mkdir ${worksrcpath} instead of the system.
>

how about 'xinstall -d'?


Regards,

Elias

From blair at orcaware.com  Thu Apr  5 16:05:12 2007
From: blair at orcaware.com (Blair Zajac)
Date: Tue Oct  9 16:40:10 2007
Subject: Dealing with tarballs that tarbomb
In-Reply-To: <01E3DD0B-3CB8-4D3B-9EC8-B6B0B34E9199@macports.org>
References: <461553F9.6050805@orcaware.com> <20070405201318.GN9160@darkart.com>
	<46157684.2050304@orcaware.com>
	<01E3DD0B-3CB8-4D3B-9EC8-B6B0B34E9199@macports.org>
Message-ID: <461580A8.50305@orcaware.com>

Elias Pipping wrote:
> On Apr 6, 2007, at 12:21 AM, Blair Zajac wrote:
> 
>> Thanks, that's what I ended up going with, however, using file mkdir 
>> ${worksrcpath} instead of the system.
>>
> 
> how about 'xinstall -d'?

Don't the 'file subcommands' commands not shell out?  Which is a good 
thing to practice.

Regards,
Blair

From vincent-opdarw at vinc17.org  Thu Apr  5 17:12:16 2007
From: vincent-opdarw at vinc17.org (Vincent Lefevre)
Date: Tue Oct  9 16:40:10 2007
Subject: MacPorts v1.4.0 release announcement
In-Reply-To: <A068372C-01AE-4214-A89C-03A7C02F21FC@geeklair.net>
References: <B2856D7B-EC1A-43D8-842D-4BCBEDF69E2F@macports.org>
	<20070405204601.GO932@prunille.vinc17.org>
	<A068372C-01AE-4214-A89C-03A7C02F21FC@geeklair.net>
Message-ID: <20070406001216.GR932@prunille.vinc17.org>

On 2007-04-05 16:49:38 -0400, Daniel J. Luke wrote:
>  The problem IIRC has to do with mismatched headers and library.

Yes, probably because the Makefile is incorrect.

>  So you'll want to do
> 
>  locate readline.h
> 
>  and see if there's a stray one (in /usr/local/include, probably) that's 
>  causing the build to choke.

No:

prunille:~> locate include/readline/readline.h
/Developer/SDKs/MacOSX10.4u.sdk/usr/include/readline/readline.h
/opt/local/include/readline/readline.h
/opt/local/var/db/dports/build/_Users_vinc17_software_darwinports_dports_devel_readline/work/destroot/opt/local/include/readline/readline.h
/opt/local/var/db/dports/software/readline/5.1.004_0/opt/local/include/readline/readline.h
/opt/local/var/db/dports/software/readline/5.2.001_0/opt/local/include/readline/readline.h
/usr/include/readline/readline.h

The problem is a mismatch between Apple's linker and gcc. A
-I/usr/include is ignored by gcc (because it is in the system path),
while with -L/usr/lib, this directory has the precedence. In short,
using -L/usr/lib is incorrect.

-- 
Vincent Lef?vre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

From jmpp at macports.org  Thu Apr  5 20:20:54 2007
From: jmpp at macports.org (Juan Manuel Palacios)
Date: Tue Oct  9 16:40:10 2007
Subject: Dealing with tarballs that tarbomb
In-Reply-To: <461580A8.50305@orcaware.com>
References: <461553F9.6050805@orcaware.com> <20070405201318.GN9160@darkart.com>
	<46157684.2050304@orcaware.com>
	<01E3DD0B-3CB8-4D3B-9EC8-B6B0B34E9199@macports.org>
	<461580A8.50305@orcaware.com>
Message-ID: <45f405e68a1b206451c0e4286b40b9be@macports.org>


On Apr 5, 2007, at 7:05 PM, Blair Zajac wrote:

> Elias Pipping wrote:
>> On Apr 6, 2007, at 12:21 AM, Blair Zajac wrote:
>>> Thanks, that's what I ended up going with, however, using file mkdir 
>>> ${worksrcpath} instead of the system.
>>>
>> how about 'xinstall -d'?
>
> Don't the 'file subcommands' commands not shell out?  Which is a good 
> thing to practice.
>
> Regards,
> Blair


	Shelling out is indeed something to avoid, which is why xinstall is 
also a good choice as it doesn't shell out either. xinstall is a 
MacPorts built-in command written in C and defined in svn 
base/src/pextlib1.0/xinstall.{c,h}. File commands and xinstall flags 
differ in their handling of extended attributes as documented in 
portfile(7), but in the case of creating directories I'd think they're 
completely equivalent.

	HTH!

-jmpp


From jmpp at macports.org  Thu Apr  5 23:51:06 2007
From: jmpp at macports.org (Juan Manuel Palacios)
Date: Tue Oct  9 16:40:10 2007
Subject: 1.4.1 release
Message-ID: <1ad15d1a572c876bf29443d19d5d5b7b@macports.org>


	Evening everyone!

	So the 1.4.0 release is finally completed after much delay (my bad, my 
apologies!), and now we're already moving up to 1.4.1. Tonight I did 
quite some merging into the release_1_4 branch of some of the work that 
has been happening on trunk, but not all of it.

	I'm currently leaving out:

  1) r23242: Ignoring SSL certificates;
  2) r23098, r23125, r23238, r23248, 23362 and 23552: "New options for 
configure flags (C|CPP|CXX|LD)FLAGS and logic to handle that
and backward compatibility." per Paul's commit log (original and 
subsequent commits);
  3) r23246, r23249 and r23291: New -I${prefix}/include and 
-L${prefix}/lib compile time flags;
  4) r23549, 23550 and r23553: Moving port tests into a test subfolder 
in order to portindex them;
  5) Universal variant.

	On the one hand, I can't find my commit log mails for the work on the 
universal variant, so I'd appreciate it if someone could annotate my 
list with the proper revision numbers; and on the other hand, I'm not 
sure if 2) and 3) can be split like that, so (Paul) do correct me if 
I'm wrong. In any case, I'd like to discuss which of those changesets 
we're going to be including in 1.4.1, so everyone should feel free to 
ventilate all the pro's and con's about each of them, if any. We 
should, however, keep in mind that 1.4.1 is meant to be a minor, bug 
fixing release over 1.4.0 and therefore should not try to offer big and 
probably still experimental new features like the universal variant, in 
my opinion; 1.5 seems to me like more appropriate for that. But, again, 
I'm willing to be proven otherwise.

	Regards,...


-jmpp


From pguyot at kallisys.net  Fri Apr  6 00:44:04 2007
From: pguyot at kallisys.net (Paul Guyot)
Date: Tue Oct  9 16:40:10 2007
Subject: 1.4.1 release
In-Reply-To: <1ad15d1a572c876bf29443d19d5d5b7b@macports.org>
References: <1ad15d1a572c876bf29443d19d5d5b7b@macports.org>
Message-ID: <5CECD587-A270-43F9-9174-149DEC3A37DA@kallisys.net>


On Apr 6, 2007, at 3:51 PM, Juan Manuel Palacios wrote:

>
> 	Evening everyone!
>
> 	So the 1.4.0 release is finally completed after much delay (my  
> bad, my apologies!), and now we're already moving up to 1.4.1.  
> Tonight I did quite some merging into the release_1_4 branch of  
> some of the work that has been happening on trunk, but not all of it.
>
> 	I'm currently leaving out:
>
>  1) r23242: Ignoring SSL certificates;
>  2) r23098, r23125, r23238, r23248, 23362 and 23552: "New options  
> for configure flags (C|CPP|CXX|LD)FLAGS and logic to handle that
> and backward compatibility." per Paul's commit log (original and  
> subsequent commits);
>  3) r23246, r23249 and r23291: New -I${prefix}/include and -L$ 
> {prefix}/lib compile time flags;
>  4) r23549, 23550 and r23553: Moving port tests into a test  
> subfolder in order to portindex them;
>  5) Universal variant.
>
> 	On the one hand, I can't find my commit log mails for the work on  
> the universal variant, so I'd appreciate it if someone could  
> annotate my list with the proper revision numbers; and on the other  
> hand, I'm not sure if 2) and 3) can be split like that, so (Paul)  
> do correct me if I'm wrong. In any case, I'd like to discuss which  
> of those changesets we're going to be including in 1.4.1, so  
> everyone should feel free to ventilate all the pro's and con's  
> about each of them, if any. We should, however, keep in mind that  
> 1.4.1 is meant to be a minor, bug fixing release over 1.4.0 and  
> therefore should not try to offer big and probably still  
> experimental new features like the universal variant, in my  
> opinion; 1.5 seems to me like more appropriate for that. But,  
> again, I'm willing to be proven otherwise.

Could you please list what you're *not* leaving out?
What's the point in annotating what you are leaving out?
Can we simply get rid of releases, considering the time it takes you  
to sort them out?

Paul


From jochen at fhi-berlin.mpg.de  Fri Apr  6 04:18:41 2007
From: jochen at fhi-berlin.mpg.de (=?ISO-8859-1?Q?Jochen_K=FCpper?=)
Date: Tue Oct  9 16:40:10 2007
Subject: libtool problem with MacPorts 1.4
Message-ID: <DEC6E76B-3D0A-49D3-BD13-82C688AF03B5@fhi-berlin.mpg.de>

Hi,

first of all thank you all for all the work you are doing on  
MacPorts, I really like it a lot. I really just came to the Mac  
because the Intel MacBooks are so nice Unix machines;)

The first question I have here:


I just performed a port selfupdate to 1.4.0 yesterday and now try to  
install python24 / py-numpy /  matplotlib with it.

The first point that raises is the following: It installed the gcc42  
port, and I do habe /opt/local/bib/gcc-dp-4.2 and such. How is one  
suppposed to ensure these are actually used? I have set CC, CXX, and  
friends accordingly and have /opt/local/bin first in the path, but  
the ports are still build using gcc-4.0 from Apple.

Moreover, I encounter a build-problem for python24 with libtool (the  
MacPorts one):

[...]
ranlib libpython2.4.a
/opt/local/bin/ginstall -c -d -m 755 Python.framework/Versions/2.4
libtool -o Python.framework/Versions/2.4/Python -dynamic   
libpython2.4.a \
          -lSystem -lSystemStubs -arch_only i386 -install_name /opt/ 
local/Library/Frameworks/Python.framework/Versions/2.4/Python - 
compatibility_version 2.4 -current_version 2.4
libtool: unrecognized option `-o'
Try `libtool --help' for more information.
make: *** [Python.framework/Versions/2.4/Python] Error 1


If I change to the build directory

cd /opt/local/var/db/dports/build/ 
_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp 
orts_lang_python24/work/Python-2.4.3

and run the program by hand using the Apple libtool, everything seems  
fine:

sudo /usr/bin/libtool -o Python.framework/Versions/2.4/Python - 
dynamic libpython2.4.a -lSystem -lSystemStubs -arch_only i386 - 
install_name /opt/local/Library/Frameworks/Python.framework/Versions/ 
2.4/Python -compatibility_version 2.4 -current_version 2.4

I can then continue the port install, which works, and python also  
seems to work nicely so far, I can also continue to install py-numpy.

Any comments on what I might be doing wrong? tests I should perform?

Thank you for your help in advance!

Greetings,
Jochen
-- 
Fritz-Haber-Institut der MPG -- Department of Molecular Physics
Faradayweg 4-6 (C1.03)
D-14195 Berlin, Germany

phone: +49-30-84135686
fax:   +49-30-84135892



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070406/c47e640a/PGP.bin
From jochen at fhi-berlin.mpg.de  Fri Apr  6 04:23:07 2007
From: jochen at fhi-berlin.mpg.de (=?ISO-8859-1?Q?Jochen_K=FCpper?=)
Date: Tue Oct  9 16:40:10 2007
Subject: antigraingeometry vs SDL_VERSION
Message-ID: <E067587D-5CA7-4CB0-91A6-1D94955BB2BF@fhi-berlin.mpg.de>

Hi!

Another problem I get whle trying to install py-matplotlib: This  
wants to install antigraingeometry; however, this fails with

checking pkg-config is at least version 0.9.0... yes
checking for FREETYPE... yes
./configure: line 20336: syntax error near unexpected token ` 
$SDL_VERSION,'
./configure: line 20336: `AM_PATH_SDL($SDL_VERSION,'

Error: Status 1 encountered during processing.


I have no idea what SDL_VERSION should be, and a google-search did  
not turn up much either:(

Any help or hint is appreciated.

Greetings,
Jochen
-- 
Einigkeit und Recht und Freiheit                http://www.Jochen- 
Kuepper.de
     Libert?, ?galit?, Fraternit?                GnuPG key: CC1B0B4D
         Sex, drugs and rock-n-roll


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070406/3c5f11cf/PGP.bin
From dluke at geeklair.net  Fri Apr  6 06:31:56 2007
From: dluke at geeklair.net (Daniel J. Luke)
Date: Tue Oct  9 16:40:10 2007
Subject: MacPorts v1.4.0 release announcement
In-Reply-To: <20070406001216.GR932@prunille.vinc17.org>
References: <B2856D7B-EC1A-43D8-842D-4BCBEDF69E2F@macports.org>
	<20070405204601.GO932@prunille.vinc17.org>
	<A068372C-01AE-4214-A89C-03A7C02F21FC@geeklair.net>
	<20070406001216.GR932@prunille.vinc17.org>
Message-ID: <4ECB7DE2-2B06-4065-AC82-B52746FDE4BD@geeklair.net>

On Apr 5, 2007, at 8:12 PM, Vincent Lefevre wrote:
> On 2007-04-05 16:49:38 -0400, Daniel J. Luke wrote:
>>  The problem IIRC has to do with mismatched headers and library.
>
> Yes, probably because the Makefile is incorrect.

It is? Do you have a patch to fix it?

> The problem is a mismatch between Apple's linker and gcc. A
> -I/usr/include is ignored by gcc (because it is in the system path),
> while with -L/usr/lib, this directory has the precedence. In short,
> using -L/usr/lib is incorrect.

I'm confused as to why you're seeing a build a problem if you don't  
have another readline installed.

I've got both the system readline and macports readline installed and  
haven't seen that build error.
--
Daniel J. Luke
+========================================================+
| *---------------- dluke@geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
|   Opinions expressed are mine and do not necessarily   |
|          reflect the opinions of my employer.          |
+========================================================+


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070406/a1c4d0b2/PGP.bin
From vincent-opdarw at vinc17.org  Fri Apr  6 07:37:09 2007
From: vincent-opdarw at vinc17.org (Vincent Lefevre)
Date: Tue Oct  9 16:40:10 2007
Subject: MacPorts v1.4.0 release announcement
In-Reply-To: <4ECB7DE2-2B06-4065-AC82-B52746FDE4BD@geeklair.net>
References: <B2856D7B-EC1A-43D8-842D-4BCBEDF69E2F@macports.org>
	<20070405204601.GO932@prunille.vinc17.org>
	<A068372C-01AE-4214-A89C-03A7C02F21FC@geeklair.net>
	<20070406001216.GR932@prunille.vinc17.org>
	<4ECB7DE2-2B06-4065-AC82-B52746FDE4BD@geeklair.net>
Message-ID: <20070406143709.GW932@prunille.vinc17.org>

On 2007-04-06 09:31:56 -0400, Daniel J. Luke wrote:
>  On Apr 5, 2007, at 8:12 PM, Vincent Lefevre wrote:
> > On 2007-04-05 16:49:38 -0400, Daniel J. Luke wrote:
> >>  The problem IIRC has to do with mismatched headers and library.
> >
> > Yes, probably because the Makefile is incorrect.
> 
>  It is? Do you have a patch to fix it?

The use of -L/usr/lib is incorrect as it is not consistent with
the include search path. For some reason, CURL_CONFIG seems to be
set to /usr/bin/curl-config, though "which curl-config" outputs
/opt/local/bin/curl-config (that's a bug since it can lead to
inconsistent paths), and there's a bug in /usr/bin/curl-config
too:

prunille:~> /usr/bin/curl-config --libs
-L/usr/lib -lcurl -lssl -lcrypto -lz
^^^^^^^^^^
This shouldn't be there.

> > The problem is a mismatch between Apple's linker and gcc. A
> > -I/usr/include is ignored by gcc (because it is in the system path),
> > while with -L/usr/lib, this directory has the precedence. In short,
> > using -L/usr/lib is incorrect.
> 
>  I'm confused as to why you're seeing a build a problem if you don't have 
>  another readline installed.

I have one in /opt/local and this prefix is included in my various
path environment variables.

-- 
Vincent Lef?vre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

From dluke at geeklair.net  Fri Apr  6 07:55:20 2007
From: dluke at geeklair.net (Daniel J. Luke)
Date: Tue Oct  9 16:40:10 2007
Subject: MacPorts v1.4.0 release announcement
In-Reply-To: <20070406143709.GW932@prunille.vinc17.org>
References: <B2856D7B-EC1A-43D8-842D-4BCBEDF69E2F@macports.org>
	<20070405204601.GO932@prunille.vinc17.org>
	<A068372C-01AE-4214-A89C-03A7C02F21FC@geeklair.net>
	<20070406001216.GR932@prunille.vinc17.org>
	<4ECB7DE2-2B06-4065-AC82-B52746FDE4BD@geeklair.net>
	<20070406143709.GW932@prunille.vinc17.org>
Message-ID: <12570A71-0E7B-4C67-B680-5AD766F2EDDA@geeklair.net>

On Apr 6, 2007, at 10:37 AM, Vincent Lefevre wrote:
>  For some reason, CURL_CONFIG seems to be
> set to /usr/bin/curl-config, though "which curl-config" outputs
> /opt/local/bin/curl-config (that's a bug since it can lead to
> inconsistent paths),

I believe that the configure script was modified to not look in $ 
{prefix} as it could lead to bootstrap issues. (yep, see the  
OD_PATH_SCAN macro)

>>> The problem is a mismatch between Apple's linker and gcc. A
>>> -I/usr/include is ignored by gcc (because it is in the system path),
>>> while with -L/usr/lib, this directory has the precedence. In short,
>>> using -L/usr/lib is incorrect.
>>
>>  I'm confused as to why you're seeing a build a problem if you  
>> don't have
>>  another readline installed.
>
> I have one in /opt/local and this prefix is included in my various
> path environment variables.

I've got CPPFLAGS and LDFLAGS set on one of my machines with macports  
readline installed and it doesn't have this problem.

Do you have something else set that if you unset, the build works?

--
Daniel J. Luke
+========================================================+
| *---------------- dluke@geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
|   Opinions expressed are mine and do not necessarily   |
|          reflect the opinions of my employer.          |
+========================================================+


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070406/bbfe720a/PGP.bin
From vincent-opdarw at vinc17.org  Fri Apr  6 08:03:42 2007
From: vincent-opdarw at vinc17.org (Vincent Lefevre)
Date: Tue Oct  9 16:40:10 2007
Subject: MacPorts v1.4.0 release announcement
In-Reply-To: <20070406143709.GW932@prunille.vinc17.org>
References: <B2856D7B-EC1A-43D8-842D-4BCBEDF69E2F@macports.org>
	<20070405204601.GO932@prunille.vinc17.org>
	<A068372C-01AE-4214-A89C-03A7C02F21FC@geeklair.net>
	<20070406001216.GR932@prunille.vinc17.org>
	<4ECB7DE2-2B06-4065-AC82-B52746FDE4BD@geeklair.net>
	<20070406143709.GW932@prunille.vinc17.org>
Message-ID: <20070406150342.GX932@prunille.vinc17.org>

On 2007-04-06 16:37:09 +0200, Vincent Lefevre wrote:
> On 2007-04-06 09:31:56 -0400, Daniel J. Luke wrote:
> >  On Apr 5, 2007, at 8:12 PM, Vincent Lefevre wrote:
> > > On 2007-04-05 16:49:38 -0400, Daniel J. Luke wrote:
> > >>  The problem IIRC has to do with mismatched headers and library.
> > >
> > > Yes, probably because the Makefile is incorrect.
> > 
> >  It is? Do you have a patch to fix it?
> 
> The use of -L/usr/lib is incorrect as it is not consistent with
> the include search path. For some reason, CURL_CONFIG seems to be
> set to /usr/bin/curl-config, though "which curl-config" outputs
> /opt/local/bin/curl-config (that's a bug since it can lead to
> inconsistent paths), and there's a bug in /usr/bin/curl-config
> too:
> 
> prunille:~> /usr/bin/curl-config --libs
> -L/usr/lib -lcurl -lssl -lcrypto -lz
> ^^^^^^^^^^
> This shouldn't be there.

Well, I think this is a more general problem, and pkg-config does
the right thing by providing --libs-only-l and --libs-only-other.

The rule is:

  * If you are linking with curl only, using the -L flags may be
    safe.

  * If you are linking with other libraries (e.g. readline), then
    the -L flags must not be used, because they may conflict with
    each other. The cleanest way to avoid such a conflict is to
    have a global setting, e.g. via LIBRARY_PATH and ditto for
    the include search path. So, the -L flags should be filtered
    out with sed 's/-L[^ ]*//g', and with --cflags, the -I flags
    should be filtered out with sed 's/-I[^ ]*//g'.

The attach patch fixes the problem here.

-- 
Vincent Lef?vre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
-------------- next part --------------
--- aclocal.m4.bak	2007-03-27 06:24:51.000000000 +0200
+++ aclocal.m4	2007-04-06 16:56:43.000000000 +0200
@@ -701,10 +701,10 @@
 		AC_MSG_ERROR([cannot find curl-config. Is libcurl installed?])
 	fi
 
-	CFLAGS_LIBCURL=$($CURL_CONFIG --cflags)
+	CFLAGS_LIBCURL=$($CURL_CONFIG --cflags | [sed 's/-I[^ ]*//g'])
 	# Due to a bug in dist, --arch flags are improperly supplied by curl-config.
 	# Get rid of them.
-	LDFLAGS_LIBCURL=$($CURL_CONFIG --libs | [sed 's/-arch [A-Za-z0-9]* //g'])
+	LDFLAGS_LIBCURL=$($CURL_CONFIG --libs | [sed 's/-arch [A-Za-z0-9]* //g; s/-L[^ ]*//g'])
 
 	AC_SUBST(CFLAGS_LIBCURL)
 	AC_SUBST(LDFLAGS_LIBCURL)
From vincent-opdarw at vinc17.org  Fri Apr  6 08:07:08 2007
From: vincent-opdarw at vinc17.org (Vincent Lefevre)
Date: Tue Oct  9 16:40:10 2007
Subject: MacPorts v1.4.0 release announcement
In-Reply-To: <12570A71-0E7B-4C67-B680-5AD766F2EDDA@geeklair.net>
References: <B2856D7B-EC1A-43D8-842D-4BCBEDF69E2F@macports.org>
	<20070405204601.GO932@prunille.vinc17.org>
	<A068372C-01AE-4214-A89C-03A7C02F21FC@geeklair.net>
	<20070406001216.GR932@prunille.vinc17.org>
	<4ECB7DE2-2B06-4065-AC82-B52746FDE4BD@geeklair.net>
	<20070406143709.GW932@prunille.vinc17.org>
	<12570A71-0E7B-4C67-B680-5AD766F2EDDA@geeklair.net>
Message-ID: <20070406150708.GY932@prunille.vinc17.org>

On 2007-04-06 10:55:20 -0400, Daniel J. Luke wrote:
>  On Apr 6, 2007, at 10:37 AM, Vincent Lefevre wrote:
> >  For some reason, CURL_CONFIG seems to be
> > set to /usr/bin/curl-config, though "which curl-config" outputs
> > /opt/local/bin/curl-config (that's a bug since it can lead to
> > inconsistent paths),
> 
>  I believe that the configure script was modified to not look in
>  ${prefix} as it could lead to bootstrap issues. (yep, see the
>  OD_PATH_SCAN macro)

If it doesn't want to look at ${prefix}, it should do that *completely*.

> > I have one in /opt/local and this prefix is included in my various
> > path environment variables.
> 
>  I've got CPPFLAGS and LDFLAGS set on one of my machines with macports 
>  readline installed and it doesn't have this problem.

I'm not talking about the flags, but about the path variables,
as described by the gcc documentation (see LIBRARY_PATH, CPATH,
C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, OBJC_INCLUDE_PATH).

The configure script should probably remove ${prefix}-based paths
from these variables.

-- 
Vincent Lef?vre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

From roederja at student.ethz.ch  Fri Apr  6 11:15:56 2007
From: roederja at student.ethz.ch (=?UTF-8?B?SmFubiBSw7ZkZXI=?=)
Date: Tue Oct  9 16:40:10 2007
Subject: antigraingeometry vs SDL_VERSION
In-Reply-To: <E067587D-5CA7-4CB0-91A6-1D94955BB2BF@fhi-berlin.mpg.de>
References: <E067587D-5CA7-4CB0-91A6-1D94955BB2BF@fhi-berlin.mpg.de>
Message-ID: <ev62ot$sli$1@sea.gmane.org>

The probelm goes away if you install the automake port. I commited an
update yesterday which adds automake as a build requirement. So update
your ports tree and try again.

Jann

Jochen K?pper wrote:
> Hi!
> 
> Another problem I get whle trying to install py-matplotlib: This wants
> to install antigraingeometry; however, this fails with
> 
> checking pkg-config is at least version 0.9.0... yes
> checking for FREETYPE... yes
> ./configure: line 20336: syntax error near unexpected token `$SDL_VERSION,'
> ./configure: line 20336: `AM_PATH_SDL($SDL_VERSION,'
> 
> Error: Status 1 encountered during processing.
> 
> 
> I have no idea what SDL_VERSION should be, and a google-search did not
> turn up much either:(
> 
> Any help or hint is appreciated.
> 
> Greetings,
> Jochen
> --Einigkeit und Recht und Freiheit               
> http://www.Jochen-Kuepper.de
>     Libert?, ?galit?, Fraternit?                GnuPG key: CC1B0B4D
>         Sex, drugs and rock-n-roll
> 
> 


From jochen at fhi-berlin.mpg.de  Fri Apr  6 11:47:25 2007
From: jochen at fhi-berlin.mpg.de (=?ISO-8859-1?Q?Jochen_K=FCpper?=)
Date: Tue Oct  9 16:40:10 2007
Subject: antigraingeometry vs SDL_VERSION
In-Reply-To: <ev62ot$sli$1@sea.gmane.org>
References: <E067587D-5CA7-4CB0-91A6-1D94955BB2BF@fhi-berlin.mpg.de>
	<ev62ot$sli$1@sea.gmane.org>
Message-ID: <94B6344C-DB00-46DE-AE97-2C82FD4EF92B@fhi-berlin.mpg.de>

On 06.04.2007, at 20:15, Jann R?der wrote:

> The probelm goes away if you install the automake port. I commited an
> update yesterday which adds automake as a build requirement. So update
> your ports tree and try again.

Thanks for your answer, but, sorry, no it does not...  I had done a
   port selfupdate
   port upgrade installed
before and that included the automake port. That is, I already had:

 > sudo port upgrade automake

 > which automake
/opt/local/bin/automake

 > automake --version
automake (GNU automake) 1.10
Written by Tom Tromey <tromey@redhat.com>
        and Alexandre Duret-Lutz <adl@gnu.org>.

Copyright 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There  
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR  
PURPOSE.

>> Another problem I get whle trying to install py-matplotlib: This  
>> wants
>> to install antigraingeometry; however, this fails with
>>
>> checking pkg-config is at least version 0.9.0... yes
>> checking for FREETYPE... yes
>> ./configure: line 20336: syntax error near unexpected token ` 
>> $SDL_VERSION,'
>> ./configure: line 20336: `AM_PATH_SDL($SDL_VERSION,'
>>
>> Error: Status 1 encountered during processing.
>>
>>
>> I have no idea what SDL_VERSION should be, and a google-search did  
>> not
>> turn up much either:(

I simply manually removed the AM_PATH_SDL check from configure, then  
continued the install. that seemed to work, but obviouslt is not a  
real slution.

Greetings,
Jochen
-- 
Einigkeit und Recht und Freiheit                http://www.Jochen- 
Kuepper.de
     Libert?, ?galit?, Fraternit?                GnuPG key: CC1B0B4D
         Sex, drugs and rock-n-roll


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070406/a4bd3184/PGP.bin
From seanasy at gmail.com  Fri Apr  6 12:56:40 2007
From: seanasy at gmail.com (Sean Fulton)
Date: Tue Oct  9 16:40:10 2007
Subject: E-mail address change
Message-ID: <ev68lo$pv8$1@sea.gmane.org>

I was maintainer on a couple ports with an old e-mail address that I no 
longer have access to: fulton@cmu.edu

How do I get the e-mail address on those ports changed? I'd like to 
update them. Should I just submit a port enhancement ticket with my new 
address?

	Sean



From blair at orcaware.com  Fri Apr  6 13:18:20 2007
From: blair at orcaware.com (Blair Zajac)
Date: Tue Oct  9 16:40:10 2007
Subject: Dealing with tarballs that tarbomb
In-Reply-To: <45f405e68a1b206451c0e4286b40b9be@macports.org>
References: <461553F9.6050805@orcaware.com> <20070405201318.GN9160@darkart.com>
	<46157684.2050304@orcaware.com>
	<01E3DD0B-3CB8-4D3B-9EC8-B6B0B34E9199@macports.org>
	<461580A8.50305@orcaware.com>
	<45f405e68a1b206451c0e4286b40b9be@macports.org>
Message-ID: <C9EC8010-28DF-4EBE-8535-E1B85A522680@orcaware.com>


On Apr 5, 2007, at 8:20 PM, Juan Manuel Palacios wrote:

>
> On Apr 5, 2007, at 7:05 PM, Blair Zajac wrote:
>
>> Elias Pipping wrote:
>>> On Apr 6, 2007, at 12:21 AM, Blair Zajac wrote:
>>>> Thanks, that's what I ended up going with, however, using file  
>>>> mkdir ${worksrcpath} instead of the system.
>>>>
>>> how about 'xinstall -d'?
>>
>> Don't the 'file subcommands' commands not shell out?  Which is a  
>> good thing to practice.
>>
>> Regards,
>> Blair
>
>
> 	Shelling out is indeed something to avoid, which is why xinstall  
> is also a good choice as it doesn't shell out either. xinstall is a  
> MacPorts built-in command written in C and defined in svn base/src/ 
> pextlib1.0/xinstall.{c,h}. File commands and xinstall flags differ  
> in their handling of extended attributes as documented in portfile 
> (7), but in the case of creating directories I'd think they're  
> completely equivalent.
>
> 	HTH!

Thanks Jaun,

That's good information to know.

Regards,
Blair

-- 
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<blair@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/



From jmpp at macports.org  Fri Apr  6 13:54:33 2007
From: jmpp at macports.org (Juan Manuel Palacios)
Date: Tue Oct  9 16:40:10 2007
Subject: E-mail address change
In-Reply-To: <ev68lo$pv8$1@sea.gmane.org>
References: <ev68lo$pv8$1@sea.gmane.org>
Message-ID: <6059f3cb7f9c56c0302a6cd7c7c0aedd@macports.org>


On Apr 6, 2007, at 3:56 PM, Sean Fulton wrote:

> I was maintainer on a couple ports with an old e-mail address that I 
> no longer have access to: fulton@cmu.edu
>
> How do I get the e-mail address on those ports changed? I'd like to 
> update them. Should I just submit a port enhancement ticket with my 
> new address?
>

	That would be the most appropriate way, yes. Remember to forward the 
ticket number to this list once it's done, so that committers can jump 
right on it.

	HTH!


-jmpp


From roederja at student.ethz.ch  Fri Apr  6 17:04:50 2007
From: roederja at student.ethz.ch (=?UTF-8?B?SmFubiBSw7ZkZXI=?=)
Date: Tue Oct  9 16:40:10 2007
Subject: antigraingeometry vs SDL_VERSION
In-Reply-To: <94B6344C-DB00-46DE-AE97-2C82FD4EF92B@fhi-berlin.mpg.de>
References: <E067587D-5CA7-4CB0-91A6-1D94955BB2BF@fhi-berlin.mpg.de>	<ev62ot$sli$1@sea.gmane.org>
	<94B6344C-DB00-46DE-AE97-2C82FD4EF92B@fhi-berlin.mpg.de>
Message-ID: <ev6n73$s7l$1@sea.gmane.org>

I committed another fix, that hacks out the SDL stuff by default. If you
have SDL installed you don't get this error. So there's now a variant
that adds a dependecy on libsdl. Could you double check if that works now ?

Jann

Jochen K?pper wrote:
> On 06.04.2007, at 20:15, Jann R?der wrote:
> 
>> The probelm goes away if you install the automake port. I commited an
>> update yesterday which adds automake as a build requirement. So update
>> your ports tree and try again.
> 
> Thanks for your answer, but, sorry, no it does not...  I had done a
>   port selfupdate
>   port upgrade installed
> before and that included the automake port. That is, I already had:
> 
>> sudo port upgrade automake
> 
>> which automake
> /opt/local/bin/automake
> 
>> automake --version
> automake (GNU automake) 1.10
> Written by Tom Tromey <tromey@redhat.com>
>        and Alexandre Duret-Lutz <adl@gnu.org>.
> 
> Copyright 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
>>> Another problem I get whle trying to install py-matplotlib: This wants
>>> to install antigraingeometry; however, this fails with
>>>
>>> checking pkg-config is at least version 0.9.0... yes
>>> checking for FREETYPE... yes
>>> ./configure: line 20336: syntax error near unexpected token
>>> `$SDL_VERSION,'
>>> ./configure: line 20336: `AM_PATH_SDL($SDL_VERSION,'
>>>
>>> Error: Status 1 encountered during processing.
>>>
>>>
>>> I have no idea what SDL_VERSION should be, and a google-search did not
>>> turn up much either:(
> 
> I simply manually removed the AM_PATH_SDL check from configure, then
> continued the install. that seemed to work, but obviouslt is not a real
> slution.
> 
> Greetings,
> Jochen
> --Einigkeit und Recht und Freiheit               
> http://www.Jochen-Kuepper.de
>     Libert?, ?galit?, Fraternit?                GnuPG key: CC1B0B4D
>         Sex, drugs and rock-n-roll
> 
> 


From ryandesign at macports.org  Fri Apr  6 17:17:05 2007
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue Oct  9 16:40:10 2007
Subject: libtool problem with MacPorts 1.4
In-Reply-To: <DEC6E76B-3D0A-49D3-BD13-82C688AF03B5@fhi-berlin.mpg.de>
References: <DEC6E76B-3D0A-49D3-BD13-82C688AF03B5@fhi-berlin.mpg.de>
Message-ID: <91F597CC-B58D-4278-849E-387E0BBA7AA2@macports.org>

On Apr 6, 2007, at 06:18, Jochen K?pper wrote:

> I just performed a port selfupdate to 1.4.0 yesterday and now try  
> to install python24 / py-numpy /  matplotlib with it.
>
> The first point that raises is the following: It installed the  
> gcc42 port, and I do habe /opt/local/bib/gcc-dp-4.2 and such. How  
> is one suppposed to ensure these are actually used? I have set CC,  
> CXX, and friends accordingly and have /opt/local/bin first in the  
> path, but the ports are still build using gcc-4.0 from Apple.

As far as I know, all ports should continue to use the Apple gcc-4.0,  
unless the port specifically depends on the gcc42 port and redefines  
the CC, CXX, etc variables.


> Moreover, I encounter a build-problem for python24 with libtool  
> (the MacPorts one):
>
> [...]
> ranlib libpython2.4.a
> /opt/local/bin/ginstall -c -d -m 755 Python.framework/Versions/2.4
> libtool -o Python.framework/Versions/2.4/Python -dynamic   
> libpython2.4.a \
>          -lSystem -lSystemStubs -arch_only i386 -install_name /opt/ 
> local/Library/Frameworks/Python.framework/Versions/2.4/Python - 
> compatibility_version 2.4 -current_version 2.4
> libtool: unrecognized option `-o'
> Try `libtool --help' for more information.
> make: *** [Python.framework/Versions/2.4/Python] Error 1
>
>
> If I change to the build directory
>
> cd /opt/local/var/db/dports/build/ 
> _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_ 
> dports_lang_python24/work/Python-2.4.3
>
> and run the program by hand using the Apple libtool, everything  
> seems fine:
>
> sudo /usr/bin/libtool -o Python.framework/Versions/2.4/Python - 
> dynamic libpython2.4.a -lSystem -lSystemStubs -arch_only i386 - 
> install_name /opt/local/Library/Frameworks/Python.framework/ 
> Versions/2.4/Python -compatibility_version 2.4 -current_version 2.4
>
> I can then continue the port install, which works, and python also  
> seems to work nicely so far, I can also continue to install py-numpy.
>
> Any comments on what I might be doing wrong? tests I should perform?

So if it works when you manually use /usr/bin/libtool, do you have a  
different libtool somewhere else that's getting picked up first? What  
does "which libtool" say?



From seanasy at gmail.com  Fri Apr  6 19:44:15 2007
Fro