From febeling at macports.org  Fri Aug  1 00:12:33 2008
From: febeling at macports.org (Caspar Florian Ebeling)
Date: Fri, 1 Aug 2008 09:12:33 +0200
Subject: Weird distfile URLs
Message-ID: <5cbbe4ae0808010012m694dd3cbydac8549f403589e5@mail.gmail.com>

Is is possible to download distfiles with weird
URLs like this:
http://cvs.m17n.org/viewcvs/ruby/ruby-cvs.tar.gz?only_with_tag=ruby-cvs-0_2

Florian

-- 
Florian Ebeling
florian.ebeling at gmail.com

From ryandesign at macports.org  Fri Aug  1 00:36:29 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 1 Aug 2008 02:36:29 -0500
Subject: Weird distfile URLs
In-Reply-To: <5cbbe4ae0808010012m694dd3cbydac8549f403589e5@mail.gmail.com>
References: <5cbbe4ae0808010012m694dd3cbydac8549f403589e5@mail.gmail.com>
Message-ID: <9A58EBF2-A012-47C2-A63D-5CC125BE44C0@macports.org>

On Aug 1, 2008, at 02:12, Caspar Florian Ebeling wrote:

> Is is possible to download distfiles with weird
> URLs like this:
> http://cvs.m17n.org/viewcvs/ruby/ruby-cvs.tar.gz?only_with_tag=ruby- 
> cvs-0_2

Yes, do this:

distname ruby-cvs
master_sites http://cvs.m17n.org/viewcvs/ruby/${distfiles}? 
only_with_tag=ruby-cvs-0_2&foo=

MacPorts will still append "/${distfiles}" to the end of the URL, but  
by putting a garbage parameter "foo=" at the end of the master_sites  
URL, the site will hopefully ignore it. I had to do that recently  
when I added a port for VirtualPlanetBuilder:

http://trac.macosforge.org/projects/macports/changeset/38705



From febeling at macports.org  Fri Aug  1 03:33:57 2008
From: febeling at macports.org (Caspar Florian Ebeling)
Date: Fri, 1 Aug 2008 12:33:57 +0200
Subject: Weird distfile URLs
In-Reply-To: <9A58EBF2-A012-47C2-A63D-5CC125BE44C0@macports.org>
References: <5cbbe4ae0808010012m694dd3cbydac8549f403589e5@mail.gmail.com>
	<9A58EBF2-A012-47C2-A63D-5CC125BE44C0@macports.org>
Message-ID: <5cbbe4ae0808010333n28d7b224q6e2cff794c606010@mail.gmail.com>

it just strikes me that there was this undocumented "curl" command in
Pextlib. I'll check it later, but
it sounds exactly like what I need...

On Fri, Aug 1, 2008 at 9:36 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Aug 1, 2008, at 02:12, Caspar Florian Ebeling wrote:
>
>> Is is possible to download distfiles with weird
>> URLs like this:
>>
>> http://cvs.m17n.org/viewcvs/ruby/ruby-cvs.tar.gz?only_with_tag=ruby-cvs-0_2
>
> Yes, do this:
>
> distname ruby-cvs
> master_sites
> http://cvs.m17n.org/viewcvs/ruby/${distfiles}?only_with_tag=ruby-cvs-0_2&foo=
>
> MacPorts will still append "/${distfiles}" to the end of the URL, but by
> putting a garbage parameter "foo=" at the end of the master_sites URL, the
> site will hopefully ignore it. I had to do that recently when I added a port
> for VirtualPlanetBuilder:
>
> http://trac.macosforge.org/projects/macports/changeset/38705
>
>
>



-- 
Florian Ebeling
florian.ebeling at gmail.com

From raimue at macports.org  Fri Aug  1 07:59:11 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Fri, 01 Aug 2008 16:59:11 +0200
Subject: buildmakejobs 0 by default to allow parallel builds
In-Reply-To: <8584E065-818F-426C-ACC8-184976B59227@macports.org>
References: <8584E065-818F-426C-ACC8-184976B59227@macports.org>
Message-ID: <489324BF.4060403@macports.org>

Ryan Schmidt wrote:
> Why don't we set buildmakejobs to 0 by default in the macports.conf?  
> Setting it to 0 makes MacPorts set the number of make jobs to the  
> number of processors or processor cores. Currently, we default  
> buildmakejobs to 1, meaning software is not built in parallel.

+1
Sounds reasonable in my opinion.

> We already require individual ports to declare "use_parallel_build  
> yes" in order to get parallel building. So any ports that say  
> "use_parallel_build yes" have been specifically tested and found to  
> work in a parallel build environment. So why don't we allow users to  
> benefit from this out of the box? I would expect that many users  
> don't even know they can speed up their builds by changing  
> buildmakejobs.

As use_parallel_build was introduced, I was in favor of making 
'use_parallel_build yes' the default as it still required you to set the 
number of parallel processes you want to use. But as we now have to flag 
every individual port for parallel building, using 'buildmakejobs 0' is 
a good solution to bring this feature to all people.

> On my system, I also set buildnicevalue to 1, instead of the current  
> default of 0, so that other tasks on my computer are still snappy  
> while MacPorts is building something. IMHO something nonzero would be  
> a better default value for buildnicevalue.

I even use 'buildnicevalue 10' as I mostly run build jobs in the background.


But be aware that macports.conf is not updated automatically and we have 
no mechanism to update it, so this will only be useful for new 
installations.

Rainer

From landonf at macports.org  Fri Aug  1 08:36:59 2008
From: landonf at macports.org (Landon Fuller)
Date: Fri, 1 Aug 2008 08:36:59 -0700
Subject: Weird distfile URLs
In-Reply-To: <5cbbe4ae0808010333n28d7b224q6e2cff794c606010@mail.gmail.com>
References: <5cbbe4ae0808010012m694dd3cbydac8549f403589e5@mail.gmail.com>
	<9A58EBF2-A012-47C2-A63D-5CC125BE44C0@macports.org>
	<5cbbe4ae0808010333n28d7b224q6e2cff794c606010@mail.gmail.com>
Message-ID: <BF5C10BA-95A4-4EEE-88FF-04612ECCCB27@macports.org>


On Aug 1, 2008, at 3:33 AM, Caspar Florian Ebeling wrote:

> it just strikes me that there was this undocumented "curl" command in
> Pextlib. I'll check it later, but
> it sounds exactly like what I need...

Except then your fetch would be imperative instead of declarative, and  
you'll skip some important machinery.
The command is purposefully undocumented for Portfile use.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080801/8b24e1f4/attachment.bin 

From febeling at macports.org  Fri Aug  1 14:08:45 2008
From: febeling at macports.org (Caspar Florian Ebeling)
Date: Fri, 1 Aug 2008 23:08:45 +0200
Subject: Weird distfile URLs
In-Reply-To: <BF5C10BA-95A4-4EEE-88FF-04612ECCCB27@macports.org>
References: <5cbbe4ae0808010012m694dd3cbydac8549f403589e5@mail.gmail.com>
	<9A58EBF2-A012-47C2-A63D-5CC125BE44C0@macports.org>
	<5cbbe4ae0808010333n28d7b224q6e2cff794c606010@mail.gmail.com>
	<BF5C10BA-95A4-4EEE-88FF-04612ECCCB27@macports.org>
Message-ID: <5cbbe4ae0808011408p63cf292ci1399cc48eb13a5c1@mail.gmail.com>

On Fri, Aug 1, 2008 at 5:36 PM, Landon Fuller <landonf at macports.org> wrote:
>
> On Aug 1, 2008, at 3:33 AM, Caspar Florian Ebeling wrote:
>
>> it just strikes me that there was this undocumented "curl" command in
>> Pextlib. I'll check it later, but
>> it sounds exactly like what I need...
>
> Except then your fetch would be imperative instead of declarative, and
> you'll skip some important machinery.
> The command is purposefully undocumented for Portfile use.

Landon, I understand you have very deep knowledge here.
Which solution to the original problem do you offer?


>
>
>



-- 
Florian Ebeling
florian.ebeling at gmail.com

From wsiegrist at apple.com  Fri Aug  1 16:21:32 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Fri, 01 Aug 2008 16:21:32 -0700
Subject: Guide Regen Failure on Friday 2008-08-01 at 16:19:43
In-Reply-To: <20080801231951.5E0CA1ACC29@beta.macosforge.org>
References: <20080801231951.5E0CA1ACC29@beta.macosforge.org>
Message-ID: <1B90336B-E686-49E2-94F3-55FE05050D87@apple.com>

On Aug 1, 2008, at 4:19 PM, superwww wrote:

> /bin/mkdir -p guide/html/chunked
> /bin/cp guide/resources/docbook.css guide/html/chunked/docbook.css
> cp: guide/html/chunked/docbook.css: Permission denied
> make: *** [guide-chunked] Error 1
> make failed.

sorry for the spam, ignore these.

-Bill


----
William Siegrist
Mac OS Forge
http://macosforge.org/







-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2421 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080801/45b11b6a/attachment.bin 

From ryandesign at macports.org  Sat Aug  2 02:03:33 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 2 Aug 2008 04:03:33 -0500
Subject: Guide PNG out of date
Message-ID: <116FD63F-676D-47B2-8BA2-A29D022BFCB1@macports.org>

I committed changes to the Guide text and also to an image in r38646.  
The text changes have now shown up on guide.macports.org now, but the  
image change has not. Can this be fixed?


From ryandesign at macports.org  Sat Aug  2 03:04:37 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 2 Aug 2008 05:04:37 -0500
Subject: MacPorts mailing lists down
Message-ID: <85B7811B-091F-4272-A409-95187124AD98@macports.org>

Messages sent to the mailing lists don't seem to arrive in my mailbox  
or appear in the archives. I sent a message about a Guide issue which  
hasn't shown up on macports-dev, and the commit mails from 38884 to  
HEAD (38909) haven't shown up on macports-changes.


From randall.h.wood at alexandriasoftware.com  Sat Aug  2 05:44:06 2008
From: randall.h.wood at alexandriasoftware.com (Randall Wood)
Date: Sat, 2 Aug 2008 08:44:06 -0400
Subject: svn commit emails
Message-ID: <c24012060808020544s1cf07475wfe563f076799121a@mail.gmail.com>

svn commit emails do not seem to be working. I have not received at
least the last 11, but am getting ticket change emails.

-- 
Randall Wood
randall.h.wood at alexandriasoftware.com

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

From wsiegrist at apple.com  Sat Aug  2 11:34:12 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Sat, 02 Aug 2008 11:34:12 -0700
Subject: svn commit emails
In-Reply-To: <c24012060808020544s1cf07475wfe563f076799121a@mail.gmail.com>
References: <c24012060808020544s1cf07475wfe563f076799121a@mail.gmail.com>
Message-ID: <6B9037A3-968C-4D94-A10B-B16330F45F80@apple.com>

Mailman didnt start after last nights reboot. Its been fixed.

-Bill


On Aug 2, 2008, at 5:44 AM, Randall Wood wrote:

> svn commit emails do not seem to be working. I have not received at
> least the last 11, but am getting ticket change emails.
>
> -- 
> Randall Wood
> randall.h.wood at alexandriasoftware.com
>
> "The rules are simple: The ball is round. The game lasts 90 minutes.
> All the rest is just philosophy."
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev




----
William Siegrist
Mac OS Forge
http://macosforge.org/







-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2421 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080802/526e9bfb/attachment.bin 

From wsiegrist at apple.com  Sat Aug  2 11:34:36 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Sat, 02 Aug 2008 11:34:36 -0700
Subject: MacPorts mailing lists down
In-Reply-To: <85B7811B-091F-4272-A409-95187124AD98@macports.org>
References: <85B7811B-091F-4272-A409-95187124AD98@macports.org>
Message-ID: <5A0CED1F-6FBF-4F0C-A089-BBCEDB083A04@apple.com>

Mailman didnt start after last nights reboot. Its been fixed.

-Bill

On Aug 2, 2008, at 3:04 AM, Ryan Schmidt wrote:

> Messages sent to the mailing lists don't seem to arrive in my  
> mailbox or appear in the archives. I sent a message about a Guide  
> issue which hasn't shown up on macports-dev, and the commit mails  
> from 38884 to HEAD (38909) haven't shown up on macports-changes.
>




----
William Siegrist
Mac OS Forge
http://macosforge.org/







-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2421 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080802/e309744b/attachment.bin 

From wsiegrist at apple.com  Sat Aug  2 11:46:50 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Sat, 02 Aug 2008 11:46:50 -0700
Subject: Guide PNG out of date
In-Reply-To: <116FD63F-676D-47B2-8BA2-A29D022BFCB1@macports.org>
References: <116FD63F-676D-47B2-8BA2-A29D022BFCB1@macports.org>
Message-ID: <FE8F4DEF-DA50-433A-B89D-2877071630AC@apple.com>

On Aug 2, 2008, at 2:03 AM, Ryan Schmidt wrote:

> I committed changes to the Guide text and also to an image in  
> r38646. The text changes have now shown up on guide.macports.org  
> now, but the image change has not. Can this be fixed?
>

There was a problem with guide generation in post-commit this past  
week, but what is there now looks like the latest to me. I checked to  
see that the right image was copied to the right place. Maybe your  
browser cached it? I'll look into this deeper, but nothing obvious  
seems wrong.

-Bill







-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2421 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080802/140cf708/attachment.bin 

From ryandesign at macports.org  Sat Aug  2 14:08:55 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 2 Aug 2008 16:08:55 -0500
Subject: Guide PNG out of date
In-Reply-To: <FE8F4DEF-DA50-433A-B89D-2877071630AC@apple.com>
References: <116FD63F-676D-47B2-8BA2-A29D022BFCB1@macports.org>
	<FE8F4DEF-DA50-433A-B89D-2877071630AC@apple.com>
Message-ID: <2B4A1311-A340-4680-9518-4C1CEF513AD4@macports.org>

On Aug 2, 2008, at 13:46, William Siegrist wrote:

> On Aug 2, 2008, at 2:03 AM, Ryan Schmidt wrote:
>
>> I committed changes to the Guide text and also to an image in  
>> r38646. The text changes have now shown up on guide.macports.org  
>> now, but the image change has not. Can this be fixed?
>
> There was a problem with guide generation in post-commit this past  
> week, but what is there now looks like the latest to me. I checked  
> to see that the right image was copied to the right place. Maybe  
> your browser cached it? I'll look into this deeper, but nothing  
> obvious seems wrong.

Sorry, yes, it looks fine.



From raimue at macports.org  Sat Aug  2 17:04:40 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sun, 03 Aug 2008 02:04:40 +0200
Subject: MacPorts AutoBuild
In-Reply-To: <5BA0686A-EB83-4D30-AF09-F2F8A2B0FC6A@apple.com>
References: <86A557C5-0074-49D2-802C-A45062768220@macports.org>	<A476B440-0CEB-424A-A399-825AEEFE3F7C@geeklair.net>	<52A4B125-8E86-4007-9652-907578AC2EE8@apple.com>	<46919CDA-F5C7-4168-BDB9-B2812EAFD63F@apple.com>	<6C23581C-D11D-4030-BCCC-F534327318A4@macports.org>	<FC151844-A6CA-43F7-AE24-CE2A655A0AD3@apple.com>	<2AFAA476-7995-4C5B-8F76-D71EA42C256F@macports.org>
	<5BA0686A-EB83-4D30-AF09-F2F8A2B0FC6A@apple.com>
Message-ID: <4894F618.3010701@macports.org>

Jordan K. Hubbard wrote:
> 
> On Jun 20, 2008, at 5:06 PM, Bryan Blackburn wrote:
> 
>> Some basic stuff at <http://trac.macports.org/wiki/MPAB>, the readme  
>> in the tarball has more info currently than that wiki page.
> 
> Is there a place for ongoing development of this?  I've already got some 
> Leopard-specific changes which will result in a lot more of the 
> xcodeproject ports building, but I'm not really clear on how or where to 
> submit them.  Thanks.

I imported it to contrib/mpab today. I also added the Subversion url to 
the wiki page at <http://trac.macports.org/wiki/MPAB>.

Everybody with commit access can contribute to it.

Rainer

From raimue at macports.org  Sat Aug  2 17:08:59 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sun, 03 Aug 2008 02:08:59 +0200
Subject: Contrib area
In-Reply-To: <486C21BA.4050400@macports.org>
References: <86A557C5-0074-49D2-802C-A45062768220@macports.org>	<BE635494-5F5D-4FE3-91BD-0764C5A1BB2A@macports.org>
	<486C21BA.4050400@macports.org>
Message-ID: <4894F71B.2030405@macports.org>

Rainer M?ller wrote:
> I suggest to move the following things from other places
> into a 'contrib area':

I created a contrib area now. It is located at 
<http://svn.macports.org/repository/macports/contrib/>.

>    * MPWA (from /users/jberry/mpwa/)

Moved to contrib/mpwa.

>    * MPAB (from the wiki)

Imported to contrib/mpab.

>    * select (used for {gcc,python}_select, from /users/mww/select)

Moved to contrib/select.

>    * MacPorts Framework [1]
>    * Pallet (from /users/rhwood/Pallet)
> 
> [1] I assume that the plans are to put the framework into base
>      once it is finished. George is currently working in
>      his own branch on it, so it would be better to delay this.

I was not sure about the Framework and Pallet to be moved right now. 
I'll leave it to Randall to move these.

Rainer

From raimue at macports.org  Sat Aug  2 19:26:37 2008
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Sun, 03 Aug 2008 04:26:37 +0200
Subject: [38935] trunk/dports/irc/silc-client/Portfile
In-Reply-To: <20080803021957.57E561B78CC@beta.macosforge.org>
References: <20080803021957.57E561B78CC@beta.macosforge.org>
Message-ID: <4895175D.3070902@macports.org>

ryandesign at macports.org wrote:
> Revision: 38935
>           http://trac.macosforge.org/projects/macports/changeset/38935
> Author:   ryandesign at macports.org
> Date:     2008-08-02 19:19:56 -0700 (Sat, 02 Aug 2008)
> Log Message:
> -----------
> silc-client: perl is also required at build time, not just at runtime
> 
> Modified Paths:
> --------------
>     trunk/dports/irc/silc-client/Portfile
> 
> Modified: trunk/dports/irc/silc-client/Portfile
> ===================================================================
> --- trunk/dports/irc/silc-client/Portfile	2008-08-03 02:05:01 UTC (rev 38934)
> +++ trunk/dports/irc/silc-client/Portfile	2008-08-03 02:19:56 UTC (rev 38935)
> @@ -27,6 +27,7 @@
>                          port:glib2 \
>                          port:libiconv \
>                          port:ncurses
> +depends_build           path:${prefix}/bin/perl:perl5.8
>  depends_run             path:${prefix}/bin/perl:perl5.8

You specified the dependency twice now. If it is needed at build and 
runtime depends_lib would be appropriate - or did I miss something?

Rainer

From ryandesign at macports.org  Sat Aug  2 20:29:21 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 2 Aug 2008 22:29:21 -0500
Subject: [38935] trunk/dports/irc/silc-client/Portfile
In-Reply-To: <4895175D.3070902@macports.org>
References: <20080803021957.57E561B78CC@beta.macosforge.org>
	<4895175D.3070902@macports.org>
Message-ID: <051CD47F-B9F1-4FFE-AD6F-B7397CD3F294@macports.org>

On Aug 2, 2008, at 21:26, Rainer M?ller wrote:

> ryandesign at macports.org wrote:
>> Revision: 38935
>>           http://trac.macosforge.org/projects/macports/changeset/ 
>> 38935
>> Author:   ryandesign at macports.org
>> Date:     2008-08-02 19:19:56 -0700 (Sat, 02 Aug 2008)
>> Log Message:
>> -----------
>> silc-client: perl is also required at build time, not just at runtime
>> Modified Paths:
>> --------------
>>     trunk/dports/irc/silc-client/Portfile
>> Modified: trunk/dports/irc/silc-client/Portfile
>> ===================================================================
>> --- trunk/dports/irc/silc-client/Portfile	2008-08-03 02:05:01 UTC  
>> (rev 38934)
>> +++ trunk/dports/irc/silc-client/Portfile	2008-08-03 02:19:56 UTC  
>> (rev 38935)
>> @@ -27,6 +27,7 @@
>>                          port:glib2 \
>>                          port:libiconv \
>>                          port:ncurses
>> +depends_build           path:${prefix}/bin/perl:perl5.8
>>  depends_run             path:${prefix}/bin/perl:perl5.8
>
> You specified the dependency twice now. If it is needed at build  
> and runtime depends_lib would be appropriate - or did I miss  
> something?

I still feel that if the port is not being used as a library, then a  
library dependency is not appropriate.


From raimue at macports.org  Sat Aug  2 20:51:04 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sun, 03 Aug 2008 05:51:04 +0200
Subject: MacPorts AutoBuild
In-Reply-To: <4894F618.3010701@macports.org>
References: <86A557C5-0074-49D2-802C-A45062768220@macports.org>	<A476B440-0CEB-424A-A399-825AEEFE3F7C@geeklair.net>	<52A4B125-8E86-4007-9652-907578AC2EE8@apple.com>	<46919CDA-F5C7-4168-BDB9-B2812EAFD63F@apple.com>	<6C23581C-D11D-4030-BCCC-F534327318A4@macports.org>	<FC151844-A6CA-43F7-AE24-CE2A655A0AD3@apple.com>	<2AFAA476-7995-4C5B-8F76-D71EA42C256F@macports.org>	<5BA0686A-EB83-4D30-AF09-F2F8A2B0FC6A@apple.com>
	<4894F618.3010701@macports.org>
Message-ID: <48952B28.80501@macports.org>

Rainer M?ller wrote:
> I imported it to contrib/mpab today. I also added the Subversion url to 
> the wiki page at <http://trac.macports.org/wiki/MPAB>.

Can somebody with the appropriate permissions please remove the tarball 
from <http://trac.macports.org/wiki/MPAB> to avoid confusion?

> Everybody with commit access can contribute to it.

Reading my own sentence again, this is not correct. Of course anybody 
can contribute, you just need to send a patch! ;-)

Rainer

From wsiegrist at apple.com  Sat Aug  2 22:16:49 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Sat, 02 Aug 2008 22:16:49 -0700
Subject: MacPorts AutoBuild
In-Reply-To: <48952B28.80501@macports.org>
References: <86A557C5-0074-49D2-802C-A45062768220@macports.org>
	<A476B440-0CEB-424A-A399-825AEEFE3F7C@geeklair.net>
	<52A4B125-8E86-4007-9652-907578AC2EE8@apple.com>
	<46919CDA-F5C7-4168-BDB9-B2812EAFD63F@apple.com>
	<6C23581C-D11D-4030-BCCC-F534327318A4@macports.org>
	<FC151844-A6CA-43F7-AE24-CE2A655A0AD3@apple.com>
	<2AFAA476-7995-4C5B-8F76-D71EA42C256F@macports.org>
	<5BA0686A-EB83-4D30-AF09-F2F8A2B0FC6A@apple.com>
	<4894F618.3010701@macports.org> <48952B28.80501@macports.org>
Message-ID: <2170D97B-C18C-4CDD-A561-E81571BEAC10@apple.com>

On Aug 2, 2008, at 8:51 PM, Rainer M?ller wrote:

> Rainer M?ller wrote:
>> I imported it to contrib/mpab today. I also added the Subversion  
>> url to
>> the wiki page at <http://trac.macports.org/wiki/MPAB>.
>
> Can somebody with the appropriate permissions please remove the  
> tarball
> from <http://trac.macports.org/wiki/MPAB> to avoid confusion?
>>

Done.

-Bill




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2421 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080802/9b524e97/attachment.bin 

From vincent-opdarw at vinc17.org  Mon Aug  4 01:25:00 2008
From: vincent-opdarw at vinc17.org (Vincent Lefevre)
Date: Mon, 4 Aug 2008 10:25:00 +0200
Subject: lzma tarball support
Message-ID: <20080804082500.GD1362@prunille.vinc17.org>

Hi,

Some packages are now distributed with lzma compression instead of bzip2,
e.g. texinfo 4.12:

  http://ftp.gnu.org/gnu/texinfo/

Going back to gzip would be a regression, in particular there is a big
size difference (here 2.4 MB for gzip, 1.3 MB for lzma).

What changes does a Portfile need to select lzma?

-- 
Vincent Lef?vre <vincent at 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 jmr at macports.org  Mon Aug  4 01:54:47 2008
From: jmr at macports.org (Joshua Root)
Date: Mon, 04 Aug 2008 18:54:47 +1000
Subject: lzma tarball support
In-Reply-To: <20080804082500.GD1362@prunille.vinc17.org>
References: <20080804082500.GD1362@prunille.vinc17.org>
Message-ID: <4896C3D7.4090706@macports.org>

Vincent Lefevre wrote:
> Hi,
> 
> Some packages are now distributed with lzma compression instead of bzip2,
> e.g. texinfo 4.12:
> 
>   http://ftp.gnu.org/gnu/texinfo/
> 
> Going back to gzip would be a regression, in particular there is a big
> size difference (here 2.4 MB for gzip, 1.3 MB for lzma).
> 
> What changes does a Portfile need to select lzma?

Should just be a matter of setting extract.suffix and extract.cmd 
appropriately. But it might also be nice to add a use_lzma option that 
would do that for you, which would involve adding the option in 
port1.0/portfetch.tcl as well as another case in the fix_extract_suffix 
proc, and adding another case in the extract_init proc in 
port1.0/portextract.tcl.

- Josh

From afb at macports.org  Mon Aug  4 02:26:12 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Mon, 4 Aug 2008 11:26:12 +0200
Subject: lzma tarball support
In-Reply-To: <4896C3D7.4090706@macports.org>
References: <20080804082500.GD1362@prunille.vinc17.org>
	<4896C3D7.4090706@macports.org>
Message-ID: <6BAFE2C3-C8C3-47B7-95A4-7B718A815814@macports.org>

Joshua Root wrote:

> Vincent Lefevre wrote:
>> Hi,
>>
>> Some packages are now distributed with lzma compression instead of  
>> bzip2,
>> e.g. texinfo 4.12:
>>
>>   http://ftp.gnu.org/gnu/texinfo/
>>
>> Going back to gzip would be a regression, in particular there is a  
>> big
>> size difference (here 2.4 MB for gzip, 1.3 MB for lzma).
>>
>> What changes does a Portfile need to select lzma?
>
> Should just be a matter of setting extract.suffix and extract.cmd
> appropriately. But it might also be nice to add a use_lzma option that
> would do that for you, which would involve adding the option in
> port1.0/portfetch.tcl as well as another case in the  
> fix_extract_suffix
> proc, and adding another case in the extract_init proc in
> port1.0/portextract.tcl.

Added as http://trac.macports.org/changeset/38960

To install the "lzma" program, see port lzmautils.

--anders


From vincent-opdarw at vinc17.org  Mon Aug  4 02:59:15 2008
From: vincent-opdarw at vinc17.org (Vincent Lefevre)
Date: Mon, 4 Aug 2008 11:59:15 +0200
Subject: lzma tarball support
In-Reply-To: <6BAFE2C3-C8C3-47B7-95A4-7B718A815814@macports.org>
References: <20080804082500.GD1362@prunille.vinc17.org>
	<4896C3D7.4090706@macports.org>
	<6BAFE2C3-C8C3-47B7-95A4-7B718A815814@macports.org>
Message-ID: <20080804095915.GE1362@prunille.vinc17.org>

On 2008-08-04 11:26:12 +0200, Anders F Bj?rklund wrote:
> Added as http://trac.macports.org/changeset/38960
>
> To install the "lzma" program, see port lzmautils.

So, should the port build-depend on lzmautils?

-- 
Vincent Lef?vre <vincent at 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 afb at macports.org  Mon Aug  4 03:24:27 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Mon, 4 Aug 2008 12:24:27 +0200
Subject: lzma tarball support
In-Reply-To: <20080804095915.GE1362@prunille.vinc17.org>
References: <20080804082500.GD1362@prunille.vinc17.org>
	<4896C3D7.4090706@macports.org>
	<6BAFE2C3-C8C3-47B7-95A4-7B718A815814@macports.org>
	<20080804095915.GE1362@prunille.vinc17.org>
Message-ID: <9F59A4E8-95D6-4B51-A146-E2596E467FA5@macports.org>

Vincent Lefevre wrote:

>> To install the "lzma" program, see port lzmautils.
>
> So, should the port build-depend on lzmautils?

Probably not, lzma(1) could come from anywhere ?

The .tar.bz2 doesn't really depend on bzip2 either,
for instance. And neither does .zip on any unzip.
So I guess they all live in the grey zone between
requirements of base and requirements of ports...

Anyway, "use_lzma" should probably handle that ?
No need to have to copy/paste stuff to all ports.

--anders


From randall.h.wood at alexandriasoftware.com  Mon Aug  4 03:26:49 2008
From: randall.h.wood at alexandriasoftware.com (Randall Wood)
Date: Mon, 4 Aug 2008 06:26:49 -0400
Subject: lzma tarball support
In-Reply-To: <20080804095915.GE1362@prunille.vinc17.org>
References: <20080804082500.GD1362@prunille.vinc17.org>
	<4896C3D7.4090706@macports.org>
	<6BAFE2C3-C8C3-47B7-95A4-7B718A815814@macports.org>
	<20080804095915.GE1362@prunille.vinc17.org>
Message-ID: <c24012060808040326n7b5d3721x44b8249dafad22fd@mail.gmail.com>

For now you may want it to build_depend on bin:lzma:lzmautils so that
we are not (re)installing it if the user already has it, but it would
be best if we just made macports intelligent about any fetch commands
it needs.

On Mon, Aug 4, 2008 at 5:59 AM, Vincent Lefevre
<vincent-opdarw at vinc17.org> wrote:
> On 2008-08-04 11:26:12 +0200, Anders F Bj?rklund wrote:
>> Added as http://trac.macports.org/changeset/38960
>>
>> To install the "lzma" program, see port lzmautils.
>
> So, should the port build-depend on lzmautils?
>
> --
> Vincent Lef?vre <vincent at 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)
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>



-- 
Randall Wood
randall.h.wood at alexandriasoftware.com

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

From jmr at macports.org  Mon Aug  4 03:59:20 2008
From: jmr at macports.org (Joshua Root)
Date: Mon, 04 Aug 2008 20:59:20 +1000
Subject: lzma tarball support
In-Reply-To: <9F59A4E8-95D6-4B51-A146-E2596E467FA5@macports.org>
References: <20080804082500.GD1362@prunille.vinc17.org>	<4896C3D7.4090706@macports.org>	<6BAFE2C3-C8C3-47B7-95A4-7B718A815814@macports.org>	<20080804095915.GE1362@prunille.vinc17.org>
	<9F59A4E8-95D6-4B51-A146-E2596E467FA5@macports.org>
Message-ID: <4896E108.4070403@macports.org>

Anders F Bj?rklund wrote:
> Vincent Lefevre wrote:
> 
>>> To install the "lzma" program, see port lzmautils.
>> So, should the port build-depend on lzmautils?
> 
> Probably not, lzma(1) could come from anywhere ?
> 
> The .tar.bz2 doesn't really depend on bzip2 either,
> for instance. And neither does .zip on any unzip.
> So I guess they all live in the grey zone between
> requirements of base and requirements of ports...

Yeah. They should be bin: deps.

> Anyway, "use_lzma" should probably handle that ?
> No need to have to copy/paste stuff to all ports.

Indeed. A related ticket: <http://trac.macports.org/ticket/13981>

- Josh

From afb at macports.org  Mon Aug  4 04:48:48 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Mon, 4 Aug 2008 13:48:48 +0200
Subject: lzma tarball support
In-Reply-To: <c24012060808040326n7b5d3721x44b8249dafad22fd@mail.gmail.com>
References: <20080804082500.GD1362@prunille.vinc17.org>
	<4896C3D7.4090706@macports.org>
	<6BAFE2C3-C8C3-47B7-95A4-7B718A815814@macports.org>
	<20080804095915.GE1362@prunille.vinc17.org>
	<c24012060808040326n7b5d3721x44b8249dafad22fd@mail.gmail.com>
Message-ID: <BDAD80B1-F76A-4E56-80D6-791685E3D4C6@macports.org>

Randall Wood wrote:

> For now you may want it to build_depend on bin:lzma:lzmautils so that
> we are not (re)installing it if the user already has it, but it would
> be best if we just made macports intelligent about any fetch commands
> it needs.

No worries, we just add it to the depends_extract and... Oops. :-)

--anders


From ram at macports.org  Mon Aug  4 18:07:31 2008
From: ram at macports.org (Adam Mercer)
Date: Mon, 4 Aug 2008 20:07:31 -0500
Subject: universal ports using lipo?
Message-ID: <799406d60808041807s175e8131sb27ab844deb62c88@mail.gmail.com>

Hi

Lame does not build universally using the usual configure trick, and a
solution has been found (see #15995) that essentially builds the port
numerous times and then stitches the output together using lipo.  This
does not seem a very neat solution too me, I feel that this should be
part of base and not done at the per port level. Is there any plan to
add something like this to base?

Cheers

Adam

From raimue at macports.org  Mon Aug  4 19:30:05 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Tue, 05 Aug 2008 04:30:05 +0200
Subject: universal ports using lipo?
In-Reply-To: <799406d60808041807s175e8131sb27ab844deb62c88@mail.gmail.com>
References: <799406d60808041807s175e8131sb27ab844deb62c88@mail.gmail.com>
Message-ID: <4897BB2D.20300@macports.org>

Adam Mercer wrote:
> Lame does not build universally using the usual configure trick, and a
> solution has been found (see #15995) that essentially builds the port
> numerous times and then stitches the output together using lipo.  This
> does not seem a very neat solution too me, I feel that this should be
> part of base and not done at the per port level. Is there any plan to
> add something like this to base?

Yes, this is really neat and is usually the way to create universal 
binaries. In Google Summer of Code 2007 was a project to implement this 
in base, but it did not complete. The final result which came out is 
proc merge in port1.0/portutil.tcl. It actually does all the stuff 
needed to merge multiple trees together with lipo.

Missing is a way to run the port phases multiple times for all requested 
platforms and then call proc merge.

Rainer

From ryandesign at macports.org  Mon Aug  4 21:19:38 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 4 Aug 2008 23:19:38 -0500
Subject: universal ports using lipo?
In-Reply-To: <799406d60808041807s175e8131sb27ab844deb62c88@mail.gmail.com>
References: <799406d60808041807s175e8131sb27ab844deb62c88@mail.gmail.com>
Message-ID: <5B4AEA93-E649-4FA4-9996-29B819B64FDF@macports.org>


On Aug 4, 2008, at 20:07, Adam Mercer wrote:

> Lame does not build universally using the usual configure trick, and a
> solution has been found (see #15995) that essentially builds the port
> numerous times and then stitches the output together using lipo.  This
> does not seem a very neat solution too me, I feel that this should be
> part of base and not done at the per port level. Is there any plan to
> add something like this to base?

"merge" will be in MacPorts 1.7.0. Until then you can look at the  
ports openssl and cairo, which are the only ones I know of that do  
this themselves so far. I'll be slightly reworking the cairo port's  
universal support, just as soon as I figure out how to fix cairo so  
it can build universally. Real soon now.


From ram at macports.org  Tue Aug  5 06:11:41 2008
From: ram at macports.org (Adam Mercer)
Date: Tue, 5 Aug 2008 08:11:41 -0500
Subject: universal ports using lipo?
In-Reply-To: <5B4AEA93-E649-4FA4-9996-29B819B64FDF@macports.org>
References: <799406d60808041807s175e8131sb27ab844deb62c88@mail.gmail.com>
	<5B4AEA93-E649-4FA4-9996-29B819B64FDF@macports.org>
Message-ID: <799406d60808050611v596a48e5u14ddc7a86ecb3198@mail.gmail.com>

On Mon, Aug 4, 2008 at 11:19 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On Aug 4, 2008, at 20:07, Adam Mercer wrote:

> "merge" will be in MacPorts 1.7.0. Until then you can look at the ports
> openssl and cairo, which are the only ones I know of that do this themselves
> so far. I'll be slightly reworking the cairo port's universal support, just
> as soon as I figure out how to fix cairo so it can build universally. Real
> soon now.

Thanks Ryan, thats helpful.

Cheers

Adam

From krischik at users.sourceforge.net  Tue Aug  5 10:36:49 2008
From: krischik at users.sourceforge.net (Martin Krischik)
Date: Tue, 5 Aug 2008 19:36:49 +0200
Subject: plist trouble
Message-ID: <E6DCD504-273B-4E38-BA2A-1B8DC4ABB9B5@users.sourceforge.net>

Hi,

I am currently trying to create my for portfile (for leafnode [1]) -  
which works fine in fact. But being a but pedantic I want to provide  
best MacOS service which includes two plist files. But there is some  
trouble here.

Maybe some more experience MacOs user can help me out. The trouble  
seems to be that the inet service does not start with the right user/ 
group id.

I attached all needed file in case someone want's to try out the port.  
The problem however should be somewhere around Portfile and  
org.macports.leafnode.plist.

Thanks for any help

Martin


[1] http://leafnode.sourceforge.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Portfile
Type: application/octet-stream
Size: 2507 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080805/820e42c4/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config
Type: application/octet-stream
Size: 11710 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080805/820e42c4/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: filters
Type: application/octet-stream
Size: 529 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080805/820e42c4/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Restart_Leafnode.command
Type: application/octet-stream
Size: 362 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080805/820e42c4/attachment-0003.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Restart_Texpire.command
Type: application/octet-stream
Size: 360 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080805/820e42c4/attachment-0004.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: org.macports.leafnode.plist
Type: application/octet-stream
Size: 813 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080805/820e42c4/attachment-0005.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: org.macports.texpire.plist
Type: application/octet-stream
Size: 803 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080805/820e42c4/attachment-0006.obj 
-------------- 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/20080805/820e42c4/attachment.bin 

From ryandesign at macports.org  Tue Aug  5 14:11:11 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 5 Aug 2008 16:11:11 -0500
Subject: [38994] trunk/dports/devel/cmake/Portfile
In-Reply-To: <20080805093735.B46EF1C37E0@beta.macosforge.org>
References: <20080805093735.B46EF1C37E0@beta.macosforge.org>
Message-ID: <9D7C0783-B69C-47FC-8649-830B30D4EA39@macports.org>

On Aug 5, 2008, at 04:37, css at macports.org wrote:

> Revision: 38994
>           http://trac.macosforge.org/projects/macports/changeset/38994
> Author:   css at macports.org
> Date:     2008-08-05 02:37:35 -0700 (Tue, 05 Aug 2008)
> Log Message:
> -----------
> Updated CMake version and checksums to 2.6.1. (refs #16211)


> -# Apply bugfix http://www.cmake.org/Bug/view.php?id=7011
> -patchfiles	patch-cmake_bug_7011_fix.diff

So the files directory can be removed too, right?


From ryandesign at macports.org  Tue Aug  5 23:04:04 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 6 Aug 2008 01:04:04 -0500
Subject: Atomic portindex
Message-ID: <B7AA67D8-F2AC-494B-8E95-9A1B02D85D99@macports.org>

I sometimes have to rebuild the PortIndex locally for testing, and  
since it takes minutes to do that, I might want to install some port  
while portindex is running. But this usually doesn't work because the  
port I want to install usually has dependencies, and the portindex  
script might not yet have gotten around to adding that port to the  
new PortIndex.

I think it would be nice for the portindex script to use a temporary  
file for the new index, and only move it over the existing PortIndex  
file when it's all through. Can anyone think of a reason why that  
wouldn't work or wouldn't be desirable?


From jmr at macports.org  Tue Aug  5 23:48:11 2008
From: jmr at macports.org (Joshua Root)
Date: Wed, 06 Aug 2008 16:48:11 +1000
Subject: Atomic portindex
In-Reply-To: <B7AA67D8-F2AC-494B-8E95-9A1B02D85D99@macports.org>
References: <B7AA67D8-F2AC-494B-8E95-9A1B02D85D99@macports.org>
Message-ID: <4899492B.4010907@macports.org>

Ryan Schmidt wrote:
> I sometimes have to rebuild the PortIndex locally for testing, and  
> since it takes minutes to do that, I might want to install some port  
> while portindex is running. But this usually doesn't work because the  
> port I want to install usually has dependencies, and the portindex  
> script might not yet have gotten around to adding that port to the  
> new PortIndex.
> 
> I think it would be nice for the portindex script to use a temporary  
> file for the new index, and only move it over the existing PortIndex  
> file when it's all through. Can anyone think of a reason why that  
> wouldn't work or wouldn't be desirable?

Sounds fine to me. Another nice thing to have would be a portindex 
option that just adds or updates the index entry for a given portfile, 
instead of rebuilding the whole thing.

- Josh

From ryandesign at macports.org  Wed Aug  6 01:22:20 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 6 Aug 2008 03:22:20 -0500
Subject: Atomic portindex
In-Reply-To: <4899492B.4010907@macports.org>
References: <B7AA67D8-F2AC-494B-8E95-9A1B02D85D99@macports.org>
	<4899492B.4010907@macports.org>
Message-ID: <68DCB2B1-98A5-400F-B728-F681DA8F42DE@macports.org>

On Aug 6, 2008, at 01:48, Joshua Root wrote:

> Ryan Schmidt wrote:
>
>> I sometimes have to rebuild the PortIndex locally for testing, and
>> since it takes minutes to do that, I might want to install some port
>> while portindex is running. But this usually doesn't work because the
>> port I want to install usually has dependencies, and the portindex
>> script might not yet have gotten around to adding that port to the
>> new PortIndex.
>>
>> I think it would be nice for the portindex script to use a temporary
>> file for the new index, and only move it over the existing PortIndex
>> file when it's all through. Can anyone think of a reason why that
>> wouldn't work or wouldn't be desirable?
>
> Sounds fine to me.

Super! I filed a ticket so we don't forget:

http://trac.macports.org/ticket/16234


> Another nice thing to have would be a portindex
> option that just adds or updates the index entry for a given portfile,
> instead of rebuilding the whole thing.


Great idea. Filed here:

http://trac.macports.org/ticket/16235



From ryandesign at macports.org  Wed Aug  6 01:34:05 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 6 Aug 2008 03:34:05 -0500
Subject: [38948] trunk/dports/graphics
In-Reply-To: <20080803133434.A315E1B924F@beta.macosforge.org>
References: <20080803133434.A315E1B924F@beta.macosforge.org>
Message-ID: <9E32434B-BEF3-4074-9BDB-0C826A715F52@macports.org>

On Aug 3, 2008, at 08:34, raimue at macports.org wrote:

> Revision: 38948
>           http://trac.macosforge.org/projects/macports/changeset/38948
> Author:   raimue at macports.org
> Date:     2008-08-03 06:34:32 -0700 (Sun, 03 Aug 2008)
> Log Message:
> -----------
> graphics/dcmtk:
> New port, closes #16163.

> +variant lib description {Install libraries and include files.} {
> +	destroot.target-append install-lib
> +}
> +
> +default_variants            +lib

Can this variant be removed? The port takes over 5 minutes to build  
on a dual-core Intel Mac, and additionally building the libraries  
only takes a few additional seconds.

Was disk space the reason the variant was created? I will grant that  
the installed port occupies 52MiB of disk space without libraries vs.  
67MiB with. But disk space is cheap these days. I think most people  
won't miss the additional 15MiB.

The reason I bring it up in the first place is that MacPorts doesn't  
support negative variants fully, in that they are not remembered  
after the install is done. If someone really didn't want the  
libraries, they would "sudo port install dcmtk -lib", however the  
next time they "sudo port upgrade dcmtk" MacPorts will automatically  
add back in the +lib variant because of the default_variants  
statement and the fact that it is not recorded anywhere that the user  
requested to omit the lib variant initially.

If the variant is to be kept, it should be changed to a no_lib  
variant, as in the attached patch dcmtk-no_lib.diff. However I  
recommend removing the variant, as in the attached patch dcmtk- 
always_lib.diff


-------------- next part --------------
A non-text attachment was scrubbed...
Name: dcmtk-no_lib.diff
Type: application/octet-stream
Size: 711 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080806/5a317ea9/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dcmtk-always_lib.diff
Type: application/octet-stream
Size: 598 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080806/5a317ea9/attachment-0001.obj 

From ryandesign at macports.org  Wed Aug  6 01:44:07 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 6 Aug 2008 03:44:07 -0500
Subject: [39023] trunk/base
In-Reply-To: <3A385E41-BC9E-402A-8BD8-57ACB082DADD@macports.org>
References: <20080806080027.5511C1C7378@beta.macosforge.org>
	<3A385E41-BC9E-402A-8BD8-57ACB082DADD@macports.org>
Message-ID: <3EA138A2-447E-48CF-BD2F-75518C4D6F66@macports.org>


On Aug 6, 2008, at 03:04, Anders F Bj?rklund wrote:

>> Revision: 39023
>>           http://trac.macosforge.org/projects/macports/changeset/ 
>> 39023
>> Author:   ryandesign at macports.org
>> Date:     2008-08-06 01:00:26 -0700 (Wed, 06 Aug 2008)
>> Log Message:
>> -----------
>> ChangeLog: consolidate entries for Leopard environment variable issue
>>
>> Modified Paths:
>> --------------
>>     trunk/base/ChangeLog
>>     trunk/base/src/port1.0/portlint.tcl
>>     trunk/base/src/port1.0/portutil.tcl
>
> Hmm, I thought ChangeLog was in chronological order (which you just  
> broke) ?

Since the ChangeLog is something the casual user might be expected to  
read, it should be concise and organized.

The Subversion log is in chronological order. The ChangeLog should  
not merely duplicate the Subversion log. Rather, it should have one  
entry per logical change.

I would also say that the most important changes should be first in  
the ChangeLog, so that a user who begins to read it but gives up  
before reaching the end learns the most important things anyway.

Such rearrangement and consolidation of the ChangeLog is probably  
something the release manager should do right before a release. I'm  
just trying to get a head start.


> I assume those other two files were just innocent bystanders or  
> something :-)

Oh crap. Undone in r39025. Thanks for catching that.


From afb at macports.org  Wed Aug  6 01:48:39 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Wed, 6 Aug 2008 10:48:39 +0200
Subject: [39023] trunk/base
In-Reply-To: <3EA138A2-447E-48CF-BD2F-75518C4D6F66@macports.org>
References: <20080806080027.5511C1C7378@beta.macosforge.org>
	<3A385E41-BC9E-402A-8BD8-57ACB082DADD@macports.org>
	<3EA138A2-447E-48CF-BD2F-75518C4D6F66@macports.org>
Message-ID: <B1EC75DA-CFB4-41CF-B945-CC7D680DDA3C@macports.org>

Ryan Schmidt wrote:

>> Hmm, I thought ChangeLog was in chronological order (which you  
>> just broke) ?
>
> Since the ChangeLog is something the casual user might be expected  
> to read, it should be concise and organized.
>
> The Subversion log is in chronological order. The ChangeLog should  
> not merely duplicate the Subversion log. Rather, it should have one  
> entry per logical change.
>
> I would also say that the most important changes should be first in  
> the ChangeLog, so that a user who begins to read it but gives up  
> before reaching the end learns the most important things anyway.
>
> Such rearrangement and consolidation of the ChangeLog is probably  
> something the release manager should do right before a release. I'm  
> just trying to get a head start.

A matter of conventions, I suppose. I normally have "NEWS" as the  
user-readable, and ChangeLog for development.

The version control log is more like "end of day commit, fix typo,  
oops move that function, missed a file" etc.

--anders


From ryandesign at macports.org  Wed Aug  6 03:32:24 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 6 Aug 2008 05:32:24 -0500
Subject: [39023] trunk/base
In-Reply-To: <B1EC75DA-CFB4-41CF-B945-CC7D680DDA3C@macports.org>
References: <20080806080027.5511C1C7378@beta.macosforge.org>
	<3A385E41-BC9E-402A-8BD8-57ACB082DADD@macports.org>
	<3EA138A2-447E-48CF-BD2F-75518C4D6F66@macports.org>
	<B1EC75DA-CFB4-41CF-B945-CC7D680DDA3C@macports.org>
Message-ID: <164CB9B8-B361-4D73-938F-07398E7C0D44@macports.org>

On Aug 6, 2008, at 03:48, Anders F Bj?rklund wrote:

> Ryan Schmidt wrote:
>
>>> Hmm, I thought ChangeLog was in chronological order (which you
>>> just broke) ?
>>
>> Since the ChangeLog is something the casual user might be expected
>> to read, it should be concise and organized.
>>
>> The Subversion log is in chronological order. The ChangeLog should
>> not merely duplicate the Subversion log. Rather, it should have one
>> entry per logical change.
>>
>> I would also say that the most important changes should be first in
>> the ChangeLog, so that a user who begins to read it but gives up
>> before reaching the end learns the most important things anyway.
>>
>> Such rearrangement and consolidation of the ChangeLog is probably
>> something the release manager should do right before a release. I'm
>> just trying to get a head start.
>
> A matter of conventions, I suppose. I normally have "NEWS" as the
> user-readable, and ChangeLog for development.
>
> The version control log is more like "end of day commit, fix typo,
> oops move that function, missed a file" etc.

Hmm. Indeed, we do have a NEWS file with a much more concise summary  
of changes.

So what is the ChangeLog good for then, since anyone interested in  
detailed changes can consult the Subversion log? I seem to remember a  
discussion about this before... Let's see...


James Berry reminds us that we need to update the ChangeLog when we  
make changes to base:

http://lists.macosforge.org/pipermail/macports-dev/2007-April/ 
001324.html


Randall Wood asks why the ChangeLog can't be generated automatically  
from the Subversion log. Juan Manuel Palacios says the ChangeLog  
should summarize commit messages, not duplicate them, and that it's  
acceptable to group multiple commits or tickets into a single  
ChangeLog entry. (I would increase "acceptable" to "desirable".)

http://lists.macosforge.org/pipermail/macports-dev/2007-December/ 
003689.html


In this question I asked about the ChangeLog, right before 1.6.0's  
release, Juan Manuel mentioned having recently created the NEWS file.  
I guess it would then be the release manager's job to create the NEWS  
file, and to do so he would draw on what's in the ChangeLog file.

http://lists.macosforge.org/pipermail/macports-dev/2007-December/ 
003749.html


From afb at macports.org  Wed Aug  6 04:21:38 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Wed, 6 Aug 2008 13:21:38 +0200
Subject: [39023] trunk/base
In-Reply-To: <164CB9B8-B361-4D73-938F-07398E7C0D44@macports.org>
References: <20080806080027.5511C1C7378@beta.macosforge.org>
	<3A385E41-BC9E-402A-8BD8-57ACB082DADD@macports.org>
	<3EA138A2-447E-48CF-BD2F-75518C4D6F66@macports.org>
	<B1EC75DA-CFB4-41CF-B945-CC7D680DDA3C@macports.org>
	<164CB9B8-B361-4D73-938F-07398E7C0D44@macports.org>
Message-ID: <0DCA0522-5323-4471-81DD-137AEAE50FF6@macports.org>

Ryan Schmidt:

>> A matter of conventions, I suppose. I normally have "NEWS" as the
>> user-readable, and ChangeLog for development.
>>
>> The version control log is more like "end of day commit, fix typo,
>> oops move that function, missed a file" etc.
>
> Hmm. Indeed, we do have a NEWS file with a much more concise  
> summary of changes.
>
> So what is the ChangeLog good for then, since anyone interested in  
> detailed changes can consult the Subversion log? I seem to remember  
> a discussion about this before... Let's see...

I think there's a rather good level of detail between the
different files, ranging from Release Notes to NEWS file
to ChangeLog file to the Subversion commit comments...

For this time I think we can leave the Leopard Tcl env
issues as one bullet in the ChangeLog, but otherwise I
would prefer to have it "grow" over it being edited ?

--anders

PS. This isn't really specific to the MacPorts project.
If you look at other projects, you'll see more examples.

Some just have the change log being a time/file dump
as outputted by the VCS, others a simple bullet list.


From cssdev at mac.com  Wed Aug  6 10:33:50 2008
From: cssdev at mac.com (cssdev at mac.com)
Date: Wed, 06 Aug 2008 13:33:50 -0400
Subject: [38994] trunk/dports/devel/cmake/Portfile
In-Reply-To: <9D7C0783-B69C-47FC-8649-830B30D4EA39@macports.org>
References: <20080805093735.B46EF1C37E0@beta.macosforge.org>
	<9D7C0783-B69C-47FC-8649-830B30D4EA39@macports.org>
Message-ID: <C1F7A558-DE52-4D81-B974-496C4945342A@mac.com>

On Aug 5, 2008, at 5:11 PM, Ryan Schmidt wrote:

> On Aug 5, 2008, at 04:37, css at macports.org wrote:
>
>> Revision: 38994
>>           http://trac.macosforge.org/projects/macports/changeset/ 
>> 38994
>> Author:   css at macports.org
>> Date:     2008-08-05 02:37:35 -0700 (Tue, 05 Aug 2008)
>> Log Message:
>> -----------
>> Updated CMake version and checksums to 2.6.1. (refs #16211)
>
>
>> -# Apply bugfix http://www.cmake.org/Bug/view.php?id=7011
>> -patchfiles	patch-cmake_bug_7011_fix.diff
>
> So the files directory can be removed too, right?

Ah,yes ... good catch. I'll fix that. :)

Chris

From ryandesign at macports.org  Wed Aug  6 11:18:41 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 6 Aug 2008 13:18:41 -0500
Subject: [38948] trunk/dports/graphics
In-Reply-To: <EA7884E9-A99C-4FF8-9209-D3D688570D03@uni-koblenz.de>
References: <20080803133434.A315E1B924F@beta.macosforge.org>
	<9E32434B-BEF3-4074-9BDB-0C826A715F52@macports.org>
	<EA7884E9-A99C-4FF8-9209-D3D688570D03@uni-koblenz.de>
Message-ID: <AF74B403-63EB-4415-ABEE-22BE7F6DCDB3@macports.org>

On Aug 6, 2008, at 10:20, Guido Lorenz wrote:

> Am 06.08.2008 um 10:34 schrieb Ryan Schmidt:
>
>>> graphics/dcmtk:
>>> New port, closes #16163.
>>
>>> +variant lib description {Install libraries and include files.} {
>>> +	destroot.target-append install-lib
>>> +}
>>> +
>>> +default_variants            +lib
>>
>> Can this variant be removed? The port takes over 5 minutes to  
>> build on a dual-core Intel Mac, and additionally building the  
>> libraries only takes a few additional seconds.
>
> That's probably because the libraries are built anyway, to be  
> linked into the dcmtk applications.
>
>> Was disk space the reason the variant was created? I will grant  
>> that the installed port occupies 52MiB of disk space without  
>> libraries vs. 67MiB with. But disk space is cheap these days. I  
>> think most people won't miss the additional 15MiB.
>
> My idea was to let the user decide whether he needs the libraries  
> or not.
>
> Btw, are there any "best practice" guidelines on how much of the  
> options provided by a configure script or makefile should be made  
> available as variants in a Portfile?

Unlike a configure script, which provides options for every  
contingency, a portfile should provide just the bare minimum of  
options -- or often, no options. We want ports to build with maximal  
functionality, unless maximal functionality imposes undue hardship on  
the user*. The guideline I've used is that a variant is good if there  
is an option that some but not many people will need, and that option  
has additional dependencies, and those dependencies (or the option  
itself) take a long time to build or take a lot of disk space. But if  
it's something most users would want, or if it adds no additional  
dependency, or if the dependency it adds is small and quick, then  
forgo the variant and just build the functionality in by default.


* One example of such undue hardship can be seen here:

http://trac.macports.org/ticket/15334#comment:9


>> If the variant is to be kept, it should be changed to a no_lib  
>> variant, as in the attached patch dcmtk-no_lib.diff. However I  
>> recommend removing the variant, as in the attached patch dcmtk- 
>> always_lib.diff
>
> I'm fine with removing the variant, as it simplifies the port, and  
> the libraries are built anyway. The additional 15 MiB don't hurt,  
> either.
>
> @Ryan: Feel free to commit your dcmtk-always_lib modifications.

Done in r39039. Thanks.


From macsforever2000 at macports.org  Thu Aug  7 09:25:48 2008
From: macsforever2000 at macports.org (Frank Schima)
Date: Thu, 7 Aug 2008 10:25:48 -0600
Subject: Can't install gnucash
Message-ID: <C04E17C1-B65D-47B1-8977-CB726D0208CB@macports.org>

Hi all,


I was trying to install gnucash without success. I got stuck on  
installing p5-getopt-long. This appears to be related to the following  
bugs:

<http://trac.macports.org/ticket/12710>
<http://trac.macports.org/ticket/12875>

Now I'm no perl guy but these seem like important bugs to fix because  
it makes MacPorts Perl look broken. Is there any progress on resolving  
these bugs?

I know about forcing the install but I don't want the management mess  
associated with that and I don't consider that a fix. In any event,  
new users are certainly going to be put off by that.


Cheers!
Frank


From jmr at macports.org  Thu Aug  7 12:56:59 2008
From: jmr at macports.org (Joshua Root)
Date: Fri, 08 Aug 2008 05:56:59 +1000
Subject: Meaning of "Not a directory"
In-Reply-To: <64c81f720807160842i5cde4b5am444d8cbc6bbe4c5f@mail.gmail.com>
References: <E71BEF4E-22D6-41C5-9859-BD193D9CE738@macports.org>	<4878FAB8.1010309@macports.org>
	<487B7253.5070308@macports.org>
	<64c81f720807160842i5cde4b5am444d8cbc6bbe4c5f@mail.gmail.com>
Message-ID: <489B538B.1010909@macports.org>

Uldis Bojars wrote:
> On Mon, Jul 14, 2008 at 4:35 PM, Rainer M?ller <raimue at macports.org> wrote:
>> Rainer M?ller wrote:
>>> I think there is some problem with the python25 framework port. I can
>>> reproduce the message here and will see if I can find a solution.
>> I am still trying to figure out where graphviz or swig pick up the path
>> to the framework directory, but I can't find it. It needs to be changed
>> to point to ${prefix}/lib/python25 instead there. Any help appreciated.
> 
> Perhaps we should file a ticket for this bug (especially if we do not
> solve it right away), but what port should it be filed against?
> Python, SWIG or every individual port which has problems with
> SWIG-generated Python bindings?

Was a ticket ever filed for this? I gather that the problem is that 
activation doesn't follow directory symlinks - I wonder if making it do 
so would break anything?

Fixing the problem in the ports may be preferable though, given our 
current release rate.

- Josh

From ryandesign at macports.org  Thu Aug  7 13:53:08 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 7 Aug 2008 15:53:08 -0500
Subject: p5-getopt-long requires force (was: Re: Can't install gnucash)
In-Reply-To: <C04E17C1-B65D-47B1-8977-CB726D0208CB@macports.org>
References: <C04E17C1-B65D-47B1-8977-CB726D0208CB@macports.org>
Message-ID: <985993B8-484E-404D-B35E-51B414339F14@macports.org>


On Aug 7, 2008, at 11:25, Frank Schima wrote:

> I was trying to install gnucash without success. I got stuck on
> installing p5-getopt-long. This appears to be related to the following
> bugs:
>
> <http://trac.macports.org/ticket/12710>
> <http://trac.macports.org/ticket/12875>
>
> Now I'm no perl guy but these seem like important bugs to fix because
> it makes MacPorts Perl look broken. Is there any progress on resolving
> these bugs?
>
> I know about forcing the install but I don't want the management mess
> associated with that and I don't consider that a fix. In any event,
> new users are certainly going to be put off by that.

The current situation is an inconvenience, but things can be made to  
work.

When installing p5-getopt-long (and some others), use the -f flag to  
force it to overwrite files from the perl5.{8,10} port.

When upgrading perl, it will complain that those same files are owned  
by p5-getopt-long. In this case, you should first deactivate p5- 
getopt-long, then upgrade perl, then activate p5-getopt-long  
(forcibly) again.

A better fix for this situation that doesn't involve forcing would of  
course be great.


From ryandesign at macports.org  Thu Aug  7 13:58:43 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 7 Aug 2008 15:58:43 -0500
Subject: Meaning of "Not a directory"
In-Reply-To: <489B538B.1010909@macports.org>
References: <E71BEF4E-22D6-41C5-9859-BD193D9CE738@macports.org>	<4878FAB8.1010309@macports.org>
	<487B7253.5070308@macports.org>
	<64c81f720807160842i5cde4b5am444d8cbc6bbe4c5f@mail.gmail.com>
	<489B538B.1010909@macports.org>
Message-ID: <8B968F11-8B74-403F-B644-D83A79D65084@macports.org>


On Aug 7, 2008, at 14:56, Joshua Root wrote:

> Uldis Bojars wrote:
>
>> On Mon, Jul 14, 2008 at 4:35 PM, Rainer M?ller wrote:
>>
>>> Rainer M?ller wrote:
>>>
>>>> I think there is some problem with the python25 framework port.  
>>>> I can
>>>> reproduce the message here and will see if I can find a solution.
>>>
>>> I am still trying to figure out where graphviz or swig pick up  
>>> the path
>>> to the framework directory, but I can't find it. It needs to be  
>>> changed
>>> to point to ${prefix}/lib/python25 instead there. Any help  
>>> appreciated.
>>
>> Perhaps we should file a ticket for this bug (especially if we do not
>> solve it right away), but what port should it be filed against?
>> Python, SWIG or every individual port which has problems with
>> SWIG-generated Python bindings?
>
> Was a ticket ever filed for this?

I don't think so. But I was able to reproduce the problem too.

> I gather that the problem is that
> activation doesn't follow directory symlinks - I wonder if making  
> it do
> so would break anything?

It's worth a try to change it.

> Fixing the problem in the ports may be preferable though, given our
> current release rate.

Oh, we *will* release 1.7.0 before too much longer. Heck, I'll do it  
if nobody else does.




From usx303 at googlemail.com  Thu Aug  7 14:12:03 2008
From: usx303 at googlemail.com (Uwe Schwartz)
Date: Thu, 07 Aug 2008 23:12:03 +0200
Subject: New Port
Message-ID: <489B6523.6070400@googlemail.com>

Hi,

I recently added a Portfile to a new port request: 
(http://trac.macports.org/ticket/14403)
Maybe some commiter could review and include it.

Regards,

Uwe

From raimue at macports.org  Thu Aug  7 14:17:22 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 07 Aug 2008 23:17:22 +0200
Subject: Meaning of "Not a directory"
In-Reply-To: <489B538B.1010909@macports.org>
References: <E71BEF4E-22D6-41C5-9859-BD193D9CE738@macports.org>	<4878FAB8.1010309@macports.org>	<487B7253.5070308@macports.org>	<64c81f720807160842i5cde4b5am444d8cbc6bbe4c5f@mail.gmail.com>
	<489B538B.1010909@macports.org>
Message-ID: <489B6662.6060109@macports.org>

Joshua Root wrote:
> Was a ticket ever filed for this? I gather that the problem is that 
> activation doesn't follow directory symlinks - I wonder if making it do 
> so would break anything?

Symlinks are owned by a specific port, directories are not.

So if we follow the symlinks, stuff will end up at places it was not 
meant to be. If the port owning the symlink is deactivated/uninstalled, 
other ports could break as they are probably expecting stuff under the 
symlink.

This wouldn't be a good idea. But we could need a better error message 
than what we currently have.

Rainer

From jmr at macports.org  Thu Aug  7 14:34:24 2008
From: jmr at macports.org (Joshua Root)
Date: Fri, 08 Aug 2008 07:34:24 +1000
Subject: Meaning of "Not a directory"
In-Reply-To: <489B6662.6060109@macports.org>
References: <E71BEF4E-22D6-41C5-9859-BD193D9CE738@macports.org>	<4878FAB8.1010309@macports.org>	<487B7253.5070308@macports.org>	<64c81f720807160842i5cde4b5am444d8cbc6bbe4c5f@mail.gmail.com>
	<489B538B.1010909@macports.org> <489B6662.6060109@macports.org>
Message-ID: <489B6A60.1070709@macports.org>

Rainer M?ller wrote:
> Joshua Root wrote:
>> Was a ticket ever filed for this? I gather that the problem is that 
>> activation doesn't follow directory symlinks - I wonder if making it 
>> do so would break anything?
> 
> Symlinks are owned by a specific port, directories are not.
> 
> So if we follow the symlinks, stuff will end up at places it was not 
> meant to be. 

If I'm understanding correctly, stuff installed by the affected py-* 
ports would end up where it *is* meant to be. No?

> If the port owning the symlink is deactivated/uninstalled, 
> other ports could break as they are probably expecting stuff under the 
> symlink.

Could be a problem in some cases, but python modules already break by 
definition if you remove python.

> This wouldn't be a good idea. But we could need a better error message 
> than what we currently have.
> 
> Rainer

- Josh

From ryandesign at macports.org  Thu Aug  7 20:05:57 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 7 Aug 2008 22:05:57 -0500
Subject: New Port
In-Reply-To: <489B6523.6070400@googlemail.com>
References: <489B6523.6070400@googlemail.com>
Message-ID: <952C240F-4538-40E2-B5B2-E123680FD2B2@macports.org>

On Aug 7, 2008, at 16:12, Uwe Schwartz wrote:

> I recently added a Portfile to a new port request:
> (http://trac.macports.org/ticket/14403)
> Maybe some commiter could review and include it.

Frank committed the port. Thanks for the contribution!



From randall.h.wood at alexandriasoftware.com  Fri Aug  8 01:52:09 2008
From: randall.h.wood at alexandriasoftware.com (Randall Wood)
Date: Fri, 8 Aug 2008 04:52:09 -0400
Subject: [39091] trunk/dports/x11/gtk-engines2/Portfile
In-Reply-To: <20080808053109.A07141CFD17@beta.macosforge.org>
References: <20080808053109.A07141CFD17@beta.macosforge.org>
Message-ID: <c24012060808080152y3b2796f1tad61cec8e6588f2f@mail.gmail.com>

Is there a reason you bumped this to an unstable development version?
GTK/GNOME versions are in the form x.y.z where an even y is stable and
an odd y is unstable.

On Fri, Aug 8, 2008 at 1:31 AM,  <mcalhoun at macports.org> wrote:
> Revision 39091 Author mcalhoun at macports.org Date 2008-08-07 22:31:09 -0700
> (Thu, 07 Aug 2008)
>
> Log Message
>
> gtk-engines2: version bump to 2.15.1
>
> Modified Paths
>
> trunk/dports/x11/gtk-engines2/Portfile
>
> Diff
>
> Modified: trunk/dports/x11/gtk-engines2/Portfile (39090 => 39091)
>
> --- trunk/dports/x11/gtk-engines2/Portfile	2008-08-08 05:21:03 UTC (rev
> 39090)
> +++ trunk/dports/x11/gtk-engines2/Portfile	2008-08-08 05:31:09 UTC (rev
> 39091)
> @@ -3,8 +3,7 @@
>  PortSystem 1.0
>
>  name		gtk-engines2
> -version		2.14.1
> -revision    1
> +version		2.15.1
>  categories	x11
>  maintainers	nomaintainer
>  description	Theme engine for gtk2
> @@ -18,14 +17,15 @@
>  master_sites	gnome:sources/gtk-engines/[strsed ${version} {/\.[0-9]*$//}]
>
>  distname	gtk-engines-${version}
> -checksums	md5 eef8ee067bad0b76b9773aef1994930c \
> -		sha1 e4713d44df431c83b1640457b90abc3ddc71d9b1 \
> -		rmd160 b3595adb6f283a801b76942ed6cd058dbb12fbbb
> +checksums	md5 7235f1355e5b982137dd9a835c025d5a \
> +		sha1 f804372ee059147f493d1163c5734a5eed546e61 \
> +		rmd160 c54c18690751c5fab85ad012c0eb6289b4956d24
>
>  use_bzip2	yes
>
>  depends_build \
> -    port:p5-xml-parser
> +    port:p5-xml-parser \
> +    port:intltool
>
>  depends_lib	\
>  	port:atk \
>
> _______________________________________________
> macports-changes mailing list
> macports-changes at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes
>
>



-- 
Randall Wood
randall.h.wood at alexandriasoftware.com

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

From mcalhoun at macports.org  Fri Aug  8 02:17:11 2008
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Fri, 8 Aug 2008 09:17:11 +0000 (UTC)
Subject: [39091] trunk/dports/x11/gtk-engines2/Portfile
References: <20080808053109.A07141CFD17@beta.macosforge.org>
	<c24012060808080152y3b2796f1tad61cec8e6588f2f@mail.gmail.com>
Message-ID: <loom.20080808T090900-784@post.gmane.org>

Randall Wood <randall.h.wood at ...> writes:

> 
> Is there a reason you bumped this to an unstable development version?
> GTK/GNOME versions are in the form x.y.z where an even y is stable and
> an odd y is unstable.
> 

Sorry about that.
I inadvertently used a development patch.
I meant to upgrade to 2.14.3.
Very careless.

It should be fixed in r39104.

-Marcus






From ryandesign at macports.org  Fri Aug  8 02:50:19 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 8 Aug 2008 04:50:19 -0500
Subject: [39093] trunk/dports/databases/freetds
In-Reply-To: <20080808071445.7C94A1D0026@beta.macosforge.org>
References: <20080808071445.7C94A1D0026@beta.macosforge.org>
Message-ID: <FB91793E-7607-46AF-87F5-5834A16ECE32@macports.org>


> On Aug 8, 2008, at 02:14, mcalhoun at macports.org wrote:
>
>> Revision: 39093
>>           http://trac.macosforge.org/projects/macports/changeset/ 
>> 39093
>> Author:   mcalhoun at macports.org
>> Date:     2008-08-08 00:14:43 -0700 (Fri, 08 Aug 2008)
>> Log Message:
>> -----------
>> freetds: upgrade to version 0.82 and consolidate 6 patchfiles into  
>> reinplace commands

Looks like previously the patches were applied only for darwin 7, 8,  
and 9. Now you're applying the changes to all operating systems. Are  
these changes appropriate for operating systems other than Mac OS X?  
Did you determine why the patches were previously only being applied  
for darwin 7, 8, and 9?


On Aug 8, 2008, at 02:14, mcalhoun at macports.org wrote:

> +post-patch {
> +	reinplace "s|../replacements/libreplacements.la||g" \
> +		${worksrcpath}/src/server/Makefile.in \
> +		${worksrcpath}/src/ctlib/Makefile.in \
> +		${worksrcpath}/src/odbc/Makefile.in \
> +		${worksrcpath}/src/dblib/Makefile.in \
> +		${worksrcpath}/src/apps/Makefile.in
> +
> +	reinplace "s|../../replacements/libreplacements.la||g" \
> +		${worksrcpath}/src/apps/fisql/Makefile.in \
> +		${worksrcpath}/src/dblib/unittests/Makefile.in \
> +		${worksrcpath}/src/tds/unittests/Makefile.in
> +}
> +
>  platform darwin 7 {
> -	patchfiles	patch-src-tds-Makefile.in patch-src-server-Makefile.in \
> -		patch-src-ctlib-Makefile.in patch-src-odbc-Makefile.in \
> -		patch-src-dblib-Makefile.in patch-src-apps-Makefile.in
> -
>  	pre-build {
>  		system "cp /usr/bin/glibtool ${worksrcpath}/libtool"
>  	}
>  }
>
> -platform darwin 8 {
> -	patchfiles      patch-src-tds-Makefile.in patch-src-server- 
> Makefile.in \
> -		patch-src-ctlib-Makefile.in patch-src-odbc-Makefile.in \
> -		patch-src-dblib-Makefile.in patch-src-apps-Makefile.in
> -}
> -
>  platform darwin 9 {
> -	patchfiles      patch-src-tds-Makefile.in patch-src-server- 
> Makefile.in \
> -		patch-src-ctlib-Makefile.in patch-src-odbc-Makefile.in \
> -		patch-src-dblib-Makefile.in patch-src-apps-Makefile.in
> -	configure.compiler	gcc-4.0
> -
>  	pre-build {
>  		system "cp /usr/bin/glibtool ${worksrcpath}/libtool"
>  	}
>  }


From mcalhoun at macports.org  Fri Aug  8 03:36:31 2008
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Fri, 8 Aug 2008 10:36:31 +0000 (UTC)
Subject: [39093] trunk/dports/databases/freetds
References: <20080808071445.7C94A1D0026@beta.macosforge.org>
	<FB91793E-7607-46AF-87F5-5834A16ECE32@macports.org>
Message-ID: <loom.20080808T100717-582@post.gmane.org>

Ryan Schmidt <ryandesign at ...> writes:
 
> Looks like previously the patches were applied only for darwin 7, 8,  
> and 9. Now you're applying the changes to all operating systems. Are  
> these changes appropriate for operating systems other than Mac OS X?  
> Did you determine why the patches were previously only being applied  
> for darwin 7, 8, and 9?
> 

I was unable to determine why theses patches were needed.
A short history:
*) All traces of ${worksrcpath}/src/replacements/libreplacements.la
    are removed from Makefiles
    (henceforth known as the patches) for darwin 7 only (in r4268).
*) patches extended to darwin 8 (in r3343).
    This was part of a version update, and it was not entirely clear why the
    darwin 8 needed the patches.
*) There was some discussion of removing the patches, but since they weren't
    causing problems, it was decided that they should stay (in #10960).
*) darwin 9 required glibtool, and the fix also included the patches (in r30584).
    It is possible that the darwin 7 platform was copied verbatim without worrying
    about whether everything was needed.

freetds has been an orphan for three years.
It is possible that the patches are not needed at all
(freetds builds on my system without them).

To answer your question, I can not see any reason why
${worksrcpath}/src/replacements/libreplacements.la
would only be objectionable only on Mac OS X and not on other platforms.

-Marcus







From vincent-opdarw at vinc17.org  Fri Aug  8 03:52:05 2008
From: vincent-opdarw at vinc17.org (Vincent Lefevre)
Date: Fri, 8 Aug 2008 12:52:05 +0200
Subject: p5-getopt-long requires force (was: Re: Can't install gnucash)
In-Reply-To: <985993B8-484E-404D-B35E-51B414339F14@macports.org>
References: <C04E17C1-B65D-47B1-8977-CB726D0208CB@macports.org>
	<985993B8-484E-404D-B35E-51B414339F14@macports.org>
Message-ID: <20080808105205.GR2989@prunille.vinc17.org>

On 2008-08-07 15:53:08 -0500, Ryan Schmidt wrote:
> The current situation is an inconvenience, but things can be made to  
> work.
> 
> When installing p5-getopt-long (and some others), use the -f flag to  
> force it to overwrite files from the perl5.{8,10} port.
> 
> When upgrading perl, it will complain that those same files are owned  
> by p5-getopt-long. In this case, you should first deactivate p5- 
> getopt-long, then upgrade perl, then activate p5-getopt-long  
> (forcibly) again.

But this is a real mess, without the possibility to do things
automatically, and with the risk to do something wrong.

> A better fix for this situation that doesn't involve forcing would of  
> course be great.

Until the bug is fixed on Perl's side, it would be better to drop
the dependency on p5-getopt-long. The module from perl is sufficient,
isn't it?

-- 
Vincent Lef?vre <vincent at 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 jmr at macports.org  Fri Aug  8 10:40:50 2008
From: jmr at macports.org (Joshua Root)
Date: Sat, 09 Aug 2008 03:40:50 +1000
Subject: dep_map duplicate removal script
Message-ID: <489C8522.7020407@macports.org>

To fully resolve the issues with duplicate dependency map entries 
reported in <http://trac.macports.org/ticket/8763>, I've attached a 
small script that will remove existing duplicates. It should be run by 
the postflight script in future MP binary packages, and on selfupdate 
too if we can figure out a way of doing that.

I'm not sure where it should live though, both in the source tree and 
when installed. Any suggestions?

- Josh

From raimue at macports.org  Fri Aug  8 11:44:58 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Fri, 08 Aug 2008 20:44:58 +0200
Subject: dep_map duplicate removal script
In-Reply-To: <489C8522.7020407@macports.org>
References: <489C8522.7020407@macports.org>
Message-ID: <489C942A.80109@macports.org>

Joshua Root wrote:
> To fully resolve the issues with duplicate dependency map entries 
> reported in <http://trac.macports.org/ticket/8763>, I've attached a 
> small script that will remove existing duplicates. It should be run by 
> the postflight script in future MP binary packages, and on selfupdate 
> too if we can figure out a way of doing that.

If I remembery correctly, your concern was that it needs to run in the 
newly installed version. We could fork a new process of the newly 
installed port in 'make install' to apply the changes to the dep_map. 
The dep_map should not be opened by the selfupdate process, so this 
should be safe and should not lead to any deadlocks.

> I'm not sure where it should live though, both in the source tree and 
> when installed. Any suggestions?

I would compare this to the name upgrade from DarwinPorts to MacPorts 
which moved several files from old to new locations. This upgrade was 
only implemented in the 'make install' target. Did anybody need to run 
it manually but was not able to do so?

As duplicate entries should not happen again with your patch in the next 
release, I don't think it is necessary to install the script. It could 
be installed, but I don't know who is supposed to run the script manually.

Rainer

From ryandesign at macports.org  Fri Aug  8 13:41:00 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 8 Aug 2008 15:41:00 -0500
Subject: [39111] trunk/dports/x11/gtkglarea/Portfile
In-Reply-To: <20080808130140.638D31D12D9@beta.macosforge.org>
References: <20080808130140.638D31D12D9@beta.macosforge.org>
Message-ID: <1CC97CE4-423F-41C6-BF88-648D5513CB86@macports.org>

On Aug 8, 2008, at 08:01, digdog at macports.org wrote:

> Revision: 39111
>           http://trac.macosforge.org/projects/macports/changeset/39111
> Author:   digdog at macports.org
> Date:     2008-08-08 06:01:39 -0700 (Fri, 08 Aug 2008)
> Log Message:
> -----------
> Fix gtk1 dependency.
>
> Modified Paths:
> --------------
>     trunk/dports/x11/gtkglarea/Portfile
>
> Modified: trunk/dports/x11/gtkglarea/Portfile
> ===================================================================
> --- trunk/dports/x11/gtkglarea/Portfile	2008-08-08 11:04:13 UTC  
> (rev 39110)
> +++ trunk/dports/x11/gtkglarea/Portfile	2008-08-08 13:01:39 UTC  
> (rev 39111)
> @@ -16,7 +16,8 @@
>  master_sites    http://www.imem.unavarra.es/3d_mec/download/ 
> sources/ \
>  		http://www.cis.nctu.edu.tw/~is85005/dports/gtkglarea/
>  checksums	md5 cd82b1ca47d9bd13e0b890181b33a871
> -depends_lib	port:glib1 port:gettext
> +depends_lib	port:glib1 port:gettext \
> +                lib:libgtk.1:gtk1

Is there a special reason why you chose the lib: dependency style?  
Usually port:-style is preferred.


From ryandesign at macports.org  Fri Aug  8 14:37:33 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 8 Aug 2008 16:37:33 -0500
Subject: [39093] trunk/dports/databases/freetds
In-Reply-To: <loom.20080808T100717-582@post.gmane.org>
References: <20080808071445.7C94A1D0026@beta.macosforge.org>
	<FB91793E-7607-46AF-87F5-5834A16ECE32@macports.org>
	<loom.20080808T100717-582@post.gmane.org>
Message-ID: <34609DB7-95D8-455E-B0F1-D76F5366A0E7@macports.org>

On Aug 8, 2008, at 05:36, Marcus Calhoun-Lopez wrote:

> Ryan Schmidt <ryandesign at ...> writes:
>
>> Looks like previously the patches were applied only for darwin 7, 8,
>> and 9. Now you're applying the changes to all operating systems. Are
>> these changes appropriate for operating systems other than Mac OS X?
>> Did you determine why the patches were previously only being applied
>> for darwin 7, 8, and 9?
>
> I was unable to determine why theses patches were needed.
> A short history:
> *) All traces of ${worksrcpath}/src/replacements/libreplacements.la
>     are removed from Makefiles
>     (henceforth known as the patches) for darwin 7 only (in r4268).
> *) patches extended to darwin 8 (in r3343).
>     This was part of a version update, and it was not entirely  
> clear why the
>     darwin 8 needed the patches.
> *) There was some discussion of removing the patches, but since  
> they weren't
>     causing problems, it was decided that they should stay (in  
> #10960).
> *) darwin 9 required glibtool, and the fix also included the  
> patches (in r30584).
>     It is possible that the darwin 7 platform was copied verbatim  
> without worrying
>     about whether everything was needed.
>
> freetds has been an orphan for three years.
> It is possible that the patches are not needed at all
> (freetds builds on my system without them).
>
> To answer your question, I can not see any reason why
> ${worksrcpath}/src/replacements/libreplacements.la
> would only be objectionable only on Mac OS X and not on other  
> platforms.

Good enough! Thanks. :)


From jmr at macports.org  Fri Aug  8 23:51:31 2008
From: jmr at macports.org (Joshua Root)
Date: Sat, 09 Aug 2008 16:51:31 +1000
Subject: dep_map duplicate removal script
In-Reply-To: <489C942A.80109@macports.org>
References: <489C8522.7020407@macports.org> <489C942A.80109@macports.org>
Message-ID: <489D3E73.9050304@macports.org>

Rainer M?ller wrote:
> Joshua Root wrote:
>> To fully resolve the issues with duplicate dependency map entries 
>> reported in <http://trac.macports.org/ticket/8763>, I've attached a 
>> small script that will remove existing duplicates. It should be run by 
>> the postflight script in future MP binary packages, and on selfupdate 
>> too if we can figure out a way of doing that.
> 
> If I remembery correctly, your concern was that it needs to run in the 
> newly installed version. We could fork a new process of the newly 
> installed port in 'make install' to apply the changes to the dep_map. 
> The dep_map should not be opened by the selfupdate process, so this 
> should be safe and should not lead to any deadlocks.
> 
>> I'm not sure where it should live though, both in the source tree and 
>> when installed. Any suggestions?
> 
> I would compare this to the name upgrade from DarwinPorts to MacPorts 
> which moved several files from old to new locations. This upgrade was 
> only implemented in the 'make install' target. Did anybody need to run 
> it manually but was not able to do so?
> 
> As duplicate entries should not happen again with your patch in the next 
> release, I don't think it is necessary to install the script. It could 
> be installed, but I don't know who is supposed to run the script manually.

Right, it doesn't need to be installed if it's run during make install. 
So where are you saying it should go in the source tree?

- Josh

From raimue at macports.org  Sat Aug  9 10:30:03 2008
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Sat, 09 Aug 2008 19:30:03 +0200
Subject: [39130] trunk/dports/lang/ghc
In-Reply-To: <20080809172236.2D5151D52DA@beta.macosforge.org>
References: <20080809172236.2D5151D52DA@beta.macosforge.org>
Message-ID: <489DD41B.8090600@macports.org>

gwright at macports.org wrote:
> Revision: 39130
>           http://trac.macosforge.org/projects/macports/changeset/39130
> Author:   gwright at macports.org
> Date:     2008-08-09 10:22:34 -0700 (Sat, 09 Aug 2008)
> Log Message:
> -----------
> Patch a socket bug and minor Portfile change to allow "port build"
> to change to the working directory.
> 
> Modified Paths:
> --------------
>     trunk/dports/lang/ghc/Portfile

[...]

>  build	{
> -	system "env DYLD_FALLBACK_LIBRARY_PATH=${prefix}/lib ${build.cmd}"
> +	system "cd ${worksrcpath} && env DYLD_FALLBACK_LIBRARY_PATH=${prefix}/lib ${build.cmd}"
>  }

Any reason you don't use 'build.env' to set the environment? Then the 
build command would automatically be run in ${worksrcpath} and you don't 
need to overwrite the whole build phase.

Rainer

From raimue at macports.org  Sun Aug 10 19:35:51 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Mon, 11 Aug 2008 04:35:51 +0200
Subject: dep_map duplicate removal script
In-Reply-To: <489D3E73.9050304@macports.org>
References: <489C8522.7020407@macports.org> <489C942A.80109@macports.org>
	<489D3E73.9050304@macports.org>
Message-ID: <489FA587.9030401@macports.org>

Joshua Root wrote:
> Right, it doesn't need to be installed if it's run during make install. 
> So where are you saying it should go in the source tree?

To be available for 'make install' it has to be somewhere below base/. 
But I can't think of the "perfect" place; it does not match what we 
already have there.

Rainer

From ryandesign at macports.org  Sun Aug 10 22:05:56 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 11 Aug 2008 00:05:56 -0500
Subject: [39130] trunk/dports/lang/ghc
In-Reply-To: <20080809172236.2D5151D52DA@beta.macosforge.org>
References: <20080809172236.2D5151D52DA@beta.macosforge.org>
Message-ID: <A7E9BEA7-0805-4233-A3E2-5257877D2548@macports.org>

On Aug 9, 2008, at 12:22, gwright at macports.org wrote:

> Revision: 39130
>           http://trac.macosforge.org/projects/macports/changeset/39130
> Author:   gwright at macports.org
> Date:     2008-08-09 10:22:34 -0700 (Sat, 09 Aug 2008)
> Log Message:
> -----------
> Patch a socket bug and minor Portfile change to allow "port build"
> to change to the working directory.

[snip]

>  build	{
> -	system "env DYLD_FALLBACK_LIBRARY_PATH=${prefix}/lib ${build.cmd}"
> +	system "cd ${worksrcpath} && env DYLD_FALLBACK_LIBRARY_PATH=$ 
> {prefix}/lib ${build.cmd}"
>  }

Why override the build phase? Why not just append  
DYLD_FALLBACK_LIBRARY_PATH=${prefix}/lib to build.env?


From ryandesign at macports.org  Sun Aug 10 23:17:45 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 11 Aug 2008 01:17:45 -0500
Subject: [39128] trunk/dports/devel/darcs/Portfile
In-Reply-To: <20080809142153.015171D4E32@beta.macosforge.org>
References: <20080809142153.015171D4E32@beta.macosforge.org>
Message-ID: <4E8C6C27-63EA-465D-BD14-AF2E3EEECB39@macports.org>

On Aug 9, 2008, at 09:21, gwright at macports.org wrote:

> Revision: 39128
>           http://trac.macosforge.org/projects/macports/changeset/39128
> Author:   gwright at macports.org
> Date:     2008-08-09 07:21:51 -0700 (Sat, 09 Aug 2008)
> Log Message:
> -----------
> Add a +nolibcurl variant and make it the default. (Works around
> a bug that causes darcs built with libcurl to hang sometimes.)
>
> Modified Paths:
> --------------
>     trunk/dports/devel/darcs/Portfile
>
> Modified: trunk/dports/devel/darcs/Portfile
> ===================================================================
> --- trunk/dports/devel/darcs/Portfile	2008-08-09 11:01:16 UTC (rev  
> 39127)
> +++ trunk/dports/devel/darcs/Portfile	2008-08-09 14:21:51 UTC (rev  
> 39128)
> @@ -4,7 +4,7 @@
>
>  name            darcs
>  version         2.0.2
> -revision	1
> +revision	2
>  categories      devel
>  maintainers     gwright at macports.org
>  description     David's Advanced Revision Control System
> @@ -31,6 +31,8 @@
>  configure.args  --mandir=${prefix}/share/man	\
>  		--without-docs
>
> +default_variants	+nolibcurl
> +
>  variant docs description {Generate a printable manual} {
>  		depends_build-append	port:latex2html
>
> @@ -43,3 +45,9 @@
>  		patchfiles-append	patch-GNUmakefile.diff
>  }
>
> +variant nolibcurl description {Build darcs without libcurl} {
> +		configure.args-append	--without-libcurl
> +		depends_lib-delete	port:curl
> +		depends_run-append	port:wget
> +}

With this change, if someone really wants curl support, they will  
find it difficult to get (and keep), because they will install this way:

sudo port install darcs -nolibcurl

(to deselect the nolibcurl variant), but when they later need to  
upgrade the port (to a newer version for example) MacPorts will again  
add the +nolibcurl variant (because MacPorts does not store  
deselected variants in its registry).

So you should instead make this a positive variant called "curl".

Also, since the choice you are offering is not what one would call a  
checkbox (curl or no curl) but rather two radio buttons (curl or  
wget), you should provide two variants as in the attached patch.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: darcs-curl-wget.diff
Type: application/octet-stream
Size: 966 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080811/28674d79/attachment.obj 

From ryandesign at macports.org  Sun Aug 10 23:27:48 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 11 Aug 2008 01:27:48 -0500
Subject: [39130] trunk/dports/lang/ghc
In-Reply-To: <A7E9BEA7-0805-4233-A3E2-5257877D2548@macports.org>
References: <20080809172236.2D5151D52DA@beta.macosforge.org>
	<A7E9BEA7-0805-4233-A3E2-5257877D2548@macports.org>
Message-ID: <D25D9EE8-45D9-4A56-A90C-A4A8F1435AB7@macports.org>

Sorry, I didn't see Rainer's similar message before sending mine.

On Aug 11, 2008, at 00:05, Ryan Schmidt wrote:

> On Aug 9, 2008, at 12:22, gwright at macports.org wrote:
>
>> Revision: 39130
>>           http://trac.macosforge.org/projects/macports/changeset/ 
>> 39130
>> Author:   gwright at macports.org
>> Date:     2008-08-09 10:22:34 -0700 (Sat, 09 Aug 2008)
>> Log Message:
>> -----------
>> Patch a socket bug and minor Portfile change to allow "port build"
>> to change to the working directory.
>
> [snip]
>
>>  build	{
>> -	system "env DYLD_FALLBACK_LIBRARY_PATH=${prefix}/lib ${build.cmd}"
>> +	system "cd ${worksrcpath} && env DYLD_FALLBACK_LIBRARY_PATH=$
>> {prefix}/lib ${build.cmd}"
>>  }
>
> Why override the build phase? Why not just append
> DYLD_FALLBACK_LIBRARY_PATH=${prefix}/lib to build.env?



From pmagrath at macports.org  Mon Aug 11 09:50:26 2008
From: pmagrath at macports.org (Paul Magrath)
Date: Mon, 11 Aug 2008 17:50:26 +0100
Subject: Beta Release
Message-ID: <F522611A-E138-4671-8461-8E6F78C4329D@macports.org>

Hi,

After discussing it with Rainer, I've decided that now, one week to go  
till the Google Summer of Code deadline, is a good time to launch a  
beta release of my development branch. So, I'd like to ask all the  
developers who are interested to checkout /branches/gsoc08-privileges/ 
base from the SVN repository and let me know, preferably by email,  
what you think and any bugs you find. The idea is to shake out as much  
problems as possible so that it is in a fit state for integration into  
the trunk by the deadline.

There is a readme file in the directory that will introduce the new  
features and behavior introduced by the branch.

Thanks in advance,

Paul.



From afb at macports.org  Mon Aug 11 13:51:59 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Mon, 11 Aug 2008 22:51:59 +0200
Subject: Beta Release
In-Reply-To: <F522611A-E138-4671-8461-8E6F78C4329D@macports.org>
References: <F522611A-E138-4671-8461-8E6F78C4329D@macports.org>
Message-ID: <52F576E2-528B-4A77-B2BE-83AC5074EE0E@macports.org>

Paul Magrath wrote:

> After discussing it with Rainer, I've decided that now, one week to go
> till the Google Summer of Code deadline, is a good time to launch a
> beta release of my development branch. So, I'd like to ask all the
> developers who are interested to checkout /branches/gsoc08-privileges/
> base from the SVN repository and let me know, preferably by email,
> what you think and any bugs you find. The idea is to shake out as much
> problems as possible so that it is in a fit state for integration into
> the trunk by the deadline.

Seems to have a path bug, "port build" returned an error due to
/Users/afb/.macports/Users/afb/.macports/ being used for extract ?
Fetch seems to be using another recursion through the loop, at:
/Users/afb/.macports/Users/afb/.macports/Users/afb/.macports/...

The configure line was:
./configure --prefix=/Users/afb/.macports --with-no-root-privileges

> There is a readme file in the directory that will introduce the new
> features and behavior introduced by the branch.

So when installing to your home directory, "/Users/you/" will
be hardcoded in the binaries and in any archives/packages made ?
Unless you use --with-shared-directory and --with-install-group
to use an common (hardcoded) path accessible to all, is that it ?

Not that it isn't a much bigger task to make it all relocatable,
but still: this could be a problem when creating the binaries...

--anders


From 0x62_0x6c_0x62 at pobox.com  Mon Aug 11 14:23:18 2008
From: 0x62_0x6c_0x62 at pobox.com (Bryan Blackburn)
Date: Mon, 11 Aug 2008 15:23:18 -0600
Subject: Beta Release
In-Reply-To: <52F576E2-528B-4A77-B2BE-83AC5074EE0E@macports.org>
References: <F522611A-E138-4671-8461-8E6F78C4329D@macports.org>
	<52F576E2-528B-4A77-B2BE-83AC5074EE0E@macports.org>
Message-ID: <0DF2C267-ED6E-46B0-8C77-4AEEB0D8F499@pobox.com>

On Aug 11, 2008, at 2:51 PM, Anders F Bj?rklund wrote:

> Paul Magrath wrote:
>
>> After discussing it with Rainer, I've decided that now, one week to  
>> go
>> till the Google Summer of Code deadline, is a good time to launch a
>> beta release of my development branch. So, I'd like to ask all the
>> developers who are interested to checkout /branches/gsoc08- 
>> privileges/
>> base from the SVN repository and let me know, preferably by email,
>> what you think and any bugs you find. The idea is to shake out as  
>> much
>> problems as possible so that it is in a fit state for integration  
>> into
>> the trunk by the deadline.
>
> Seems to have a path bug, "port build" returned an error due to
> /Users/afb/.macports/Users/afb/.macports/ being used for extract ?
> Fetch seems to be using another recursion through the loop, at:
> /Users/afb/.macports/Users/afb/.macports/Users/afb/.macports/...
>
> The configure line was:
> ./configure --prefix=/Users/afb/.macports --with-no-root-privileges
>

I see a similar odd path for distfiles here, though my configure was a  
bit different:

$ ./configure --prefix=/Users/blb/devel/mp-priv --with-no-root- 
privileges --with-applications-dir=/Users/blb/devel/mp-priv/ 
Applications --with-frameworks-dir=/Users/blb/devel/mp-priv/Frameworks  
--with-tclpackage=/Users/blb/devel/mp-priv/Tcl

This is meant to contain it all within the mp-priv directory (I've  
been using similar settings for a test install off trunk, another off  
1.6 branch, etc).  The distfile location it used was:

DEBUG: Going to use /Users/blb/.macports/Users/blb/.macports/Users/blb/ 
devel/mp-priv/var/macports/distfiles for fetch.

It also created some other interesting paths:

/Users/blb/.macports/Users/blb/devel/macports/trunk/dports/devel/ 
pkgconfig where it appears to have copied pkgconfig's Portfile and the  
work symlink (I'm guessing it would have copied files/ over as well,  
if pkgconfig had one?)

/Users/blb/.macports/Users/blb/devel/mp-priv/var/macports/build/ 
_Users_blb_devel_macports_trunk_dports_devel_pkgconfig which is where  
it created the actual work directory for building, so this one is the  
one I most expected to see.


Note however that it did successfully build pkgconfig.  However, when  
it reached the install phase it wanted me to authenticate to sudo even  
though I used '--with-no-root-privileges'.  Finally, when I just hit  
enter at the sudo password prompt to get it to exit, port dumped a  
long trace (I think you need a catch around the 'exec sudo port...'):

child process exited abnormally
     while executing
"exec sudo port $target $portname"
     invoked from within
"if { [geteuid] != 0 && $result == 2} {
			# mportexec will return an error result code 2 if eval_targets  
fails due to insufficient privileges.
			ui_i..."
     ("uplevel" body line 54)
     invoked from within
"uplevel 1 $block"
     (procedure "foreachport" line 16)
     invoked from within
"foreachport $portlist {
         set target $action

         # If we have a url, use that, since it's most specific
         # otherwise try to map the ..."
     (procedure "action_target" line 7)
     invoked from within
"$action_proc $action $portlist [array get global_options]"
     (procedure "process_cmd" line 86)
     invoked from within
"process_cmd $remaining_args"
     invoked from within
"if { [llength $remaining_args] > 0 } {

     # If there are remaining arguments, process those as a command

     # Exit immediately, by default, unless..."
     (file "/Users/blb/devel/mp-priv/bin/port" line 3252)

Bryan


>
...
> --anders
>

From ryandesign at macports.org  Mon Aug 11 23:24:11 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 12 Aug 2008 01:24:11 -0500
Subject: [39179] trunk/dports/games/rrgbis
In-Reply-To: <20080811143823.5F5ED1DB0DE@beta.macosforge.org>
References: <20080811143823.5F5ED1DB0DE@beta.macosforge.org>
Message-ID: <88CAAADB-4339-4D61-8D19-225359477B58@macports.org>

On Aug 11, 2008, at 09:38, simon at macports.org wrote:

> Revision: 39179
>           http://trac.macosforge.org/projects/macports/changeset/39179
> Author:   simon at macports.org
> Date:     2008-08-11 07:38:21 -0700 (Mon, 11 Aug 2008)
> Log Message:
> -----------
> games/rrgbis: Updated to 1.11.
>
> Modified Paths:
> --------------
>     trunk/dports/games/rrgbis/Portfile

[snip]

> -use_configure       no
> +configure {
> +    system "cd ${worksrcpath}/src/FTGL; ${configure.env} ./ 
> configure ${configure.pre_args}"
> +}


[snip]

Why override the configure phase? Why not just:

configure.dir       ${worksrcpath}/src/FTGL

(warning: untested)


From afb at macports.org  Tue Aug 12 05:19:31 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Tue, 12 Aug 2008 14:19:31 +0200
Subject: Beta Release
In-Reply-To: <9673b3e00808120425x3ea47251xa9dace9482e8dd54@mail.gmail.com>
References: <F522611A-E138-4671-8461-8E6F78C4329D@macports.org>
	<52F576E2-528B-4A77-B2BE-83AC5074EE0E@macports.org>
	<9673b3e00808120425x3ea47251xa9dace9482e8dd54@mail.gmail.com>
Message-ID: <3F0BF6D7-A785-480D-8272-96EB6A201D6C@macports.org>

Paul Magrath wrote:

> Seems to have a path bug, "port build" returned an error due to
> /Users/afb/.macports/Users/afb/.macports/ being used for extract ?
> Fetch seems to be using another recursion through the loop, at:
> /Users/afb/.macports/Users/afb/.macports/Users/afb/.macports/...
>
> I'm having difficulty reproducing that bug. Would you mind sending  
> me more details of how exactly you did it?
>
> I've done this just now and it has worked fine on my machine:
>
> ./configure --prefix=/Users/paul/.macports --with-no-root-privileges
> make install
> cd ~/.macports/bin
> ./port build cowsay

I did something like this:

./configure --prefix=/Users/afb/.macports --with-no-root-privileges
make
make test
make install
# enabled archivemode and disabled autoclean in macports.conf, as usual
# untarred a fresh tree from http://www.macports.org/files/ports.tar.gz
~/.macports/bin/port archive zip
~/.macports/bin/port archive gzip

Something that I found to be strange was why I would want to install
MacPorts into the config directory of ~/.macports (next to history),
and this is probably aggrevated by being hidden from Finder et. al ?
(At least /opt/local is not hidden, while /usr/local normally is.)

> So when installing to your home directory, "/Users/you/" will
> be hardcoded in the binaries and in any archives/packages made ?
>
> Yes. However, I'd recommend you use the default /opt install  
> location if you were planning on distributing binaries/archives/ 
> packages.

Sounds like a good recommendation, although it is /opt/local... :-)
A common misunderstanding is that ${prefix} is /opt, which is wrong.

> Unless you use --with-shared-directory and --with-install-group
> to use an common (hardcoded) path accessible to all, is that it ?
>
> That is an alternative, yes. However, you can use a normal "./ 
> configure" without any arguments and install in /opt and still get  
> a lot of benefit from the work done in the branch on dropping  
> privileges, etc.

I suspect the majority would install from either the disk image
constructed by the port, or from whatever "port selfupdate" does...

--anders



From pmagrath at macports.org  Tue Aug 12 10:13:03 2008
From: pmagrath at macports.org (Paul Magrath)
Date: Tue, 12 Aug 2008 18:13:03 +0100
Subject: macports-dev Digest, Vol 24, Issue 15
In-Reply-To: <mailman.14.1218549610.90517.macports-dev@lists.macosforge.org>
References: <mailman.14.1218549610.90517.macports-dev@lists.macosforge.org>
Message-ID: <46738FE4-63B0-46C2-85E3-D3DCE673EBA6@macports.org>

Hi Bryan,

Thanks for taking the time to have a look! Appreciate it!

I've fixed the "interesting" paths bug now I think and have committed  
that fix.

> From: Bryan Blackburn <0x62_0x6c_0x62 at pobox.com>
> Subject: Re: Beta Release
>
> It also created some other interesting paths:
>
> /Users/blb/.macports/Users/blb/devel/macports/trunk/dports/devel/ 
> pkgconfig where it appears to have copied pkgconfig's Portfile and  
> the work symlink (I'm guessing it would have copied files/ over as  
> well, if pkgconfig had one?)

Yep.

> /Users/blb/.macports/Users/blb/devel/mp-priv/var/macports/build/ 
> _Users_blb_devel_macports_trunk_dports_devel_pkgconfig which is  
> where it created the actual work directory for building, so this one  
> is the one I most expected to see.

It should be using /Users/blb/.macports/devel/mp-priv/var/macports/ 
build/_devel_macports_trunk_dports_devel_pkgconfig or something along  
those lines. Hopefully should be now.

> Note however that it did successfully build pkgconfig.  However,  
> when it reached the install phase it wanted me to authenticate to  
> sudo even though I used '--with-no-root-privileges'.

Ah, yes. That is due to the Portfile format now having a new option  
called install.asroot which defaults to "yes". This is to be set to  
"no" in the portfile if it is okay to install the port without using  
root privileges. It is probably too conservative a behaviour really.  
configure.asroot, patch.asroot, destroot.asroot and build.asroot  
default to "no".

> Finally, when I just hit enter at the sudo password prompt to get it  
> to exit, port dumped a long trace (I think you need a catch around  
> the 'exec sudo port...'):

Hmmm, yes that does seem like a good idea!

Please check the code out again in a couple of days. I'm going to do  
my best to fix every thing people report as quickly as I can.

Thanks again,

Paul.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080812/d587b6d7/attachment.html 

From ryandesign at macports.org  Tue Aug 12 19:22:02 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 12 Aug 2008 21:22:02 -0500
Subject: [39210] trunk/dports/net
In-Reply-To: <20080812163813.8B93C1E1FE1@beta.macosforge.org>
References: <20080812163813.8B93C1E1FE1@beta.macosforge.org>
Message-ID: <56B81FD3-17FF-40CB-900A-4754E77A8ECF@macports.org>

On Aug 12, 2008, at 11:38, rene at macports.org wrote:

> +extract.suffix      .tar.gz

FYI, you can remove that line; it's the default.


From ryandesign at macports.org  Tue Aug 12 19:22:49 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 12 Aug 2008 21:22:49 -0500
Subject: [39194] trunk/dports/office/taskjuggler/Portfile
In-Reply-To: <20080812110627.117051E0D8A@beta.macosforge.org>
References: <20080812110627.117051E0D8A@beta.macosforge.org>
Message-ID: <28128F3A-D980-4031-A189-40127DCF6808@macports.org>


On Aug 12, 2008, at 06:06, rene at macports.org wrote:

> Revision: 39194
>           http://trac.macosforge.org/projects/macports/changeset/39194
> Author:   rene at macports.org
> Date:     2008-08-12 04:06:26 -0700 (Tue, 12 Aug 2008)
> Log Message:
> -----------
> office/taskjuggler: Fix missing dot in extract.suffix.


> -extract.suffix      tar.bz2
> +extract.suffix      .tar.bz2
>  use_bzip2           yes


You can just remove the extract.suffix line. .tar.bz2 is already the  
default extract suffix when you set use_bzip2 to yes.


From pmagrath at macports.org  Wed Aug 13 00:47:22 2008
From: pmagrath at macports.org (Paul Magrath)
Date: Wed, 13 Aug 2008 08:47:22 +0100
Subject: Beta Release
In-Reply-To: <3F0BF6D7-A785-480D-8272-96EB6A201D6C@macports.org>
References: <F522611A-E138-4671-8461-8E6F78C4329D@macports.org>
	<52F576E2-528B-4A77-B2BE-83AC5074EE0E@macports.org>
	<9673b3e00808120425x3ea47251xa9dace9482e8dd54@mail.gmail.com>
	<3F0BF6D7-A785-480D-8272-96EB6A201D6C@macports.org>
Message-ID: <B464AAD8-5769-4E3B-A3EC-F42140F52DE7@macports.org>

Hi Anders,

On 12 Aug 2008, at 13:19, Anders F Bj?rklund wrote:
> I did something like this:
>
> ./configure --prefix=/Users/afb/.macports --with-no-root-privileges
> make
> make test
> make install
> # enabled archivemode and disabled autoclean in macports.conf, as  
> usual
> # untarred a fresh tree from http://www.macports.org/files/ 
> ports.tar.gz
> ~/.macports/bin/port archive zip
> ~/.macports/bin/port archive gzip

That is working okay for me now after a few small fixes. If you have a  
chance, checkout the new code from the svn and let me know if it works  
okay for you.

> Something that I found to be strange was why I would want to install
> MacPorts into the config directory of ~/.macports (next to history),
> and this is probably aggrevated by being hidden from Finder et. al ?
> (At least /opt/local is not hidden, while /usr/local normally is.)

Yes, I've changed the suggested configure to "./configure --prefix=/ 
Users/{your-user-name}/.macports/opt --with-no-root-privileges" now to  
better separate the two.

>> So when installing to your home directory, "/Users/you/" will
>> be hardcoded in the binaries and in any archives/packages made ?
>>
>> Yes. However, I'd recommend you use the default /opt install  
>> location if you were planning on distributing binaries/archives/ 
>> packages.
>
> Sounds like a good recommendation, although it is /opt/local... :-)
> A common misunderstanding is that ${prefix} is /opt, which is wrong.

I was just using /opt as shorthand for /opt/local.

>> Unless you use --with-shared-directory and --with-install-group
>> to use an common (hardcoded) path accessible to all, is that it ?
>>
>> That is an alternative, yes. However, you can use a normal "./ 
>> configure" without any arguments and install in /opt and still get  
>> a lot of benefit from the work done in the branch on dropping  
>> privileges, etc.
>
> I suspect the majority would install from either the disk image
> constructed by the port, or from whatever "port selfupdate" does...

I suspect so. But it should be possible to add options to the  
installer provided by the disk image if there is demand for an easy  
way to use the new install options. Alternatively, one of these  
options could be made the new default (the shared directory with  
macports install group option perhaps as it would be the most useful I  
think).

Paul.


From afb at macports.org  Wed Aug 13 00:54:50 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Wed, 13 Aug 2008 09:54:50 +0200
Subject: Beta Release
In-Reply-To: <B464AAD8-5769-4E3B-A3EC-F42140F52DE7@macports.org>
References: <F522611A-E138-4671-8461-8E6F78C4329D@macports.org>
	<52F576E2-528B-4A77-B2BE-83AC5074EE0E@macports.org>
	<9673b3e00808120425x3ea47251xa9dace9482e8dd54@mail.gmail.com>
	<3F0BF6D7-A785-480D-8272-96EB6A201D6C@macports.org>
	<B464AAD8-5769-4E3B-A3EC-F42140F52DE7@macports.org>
Message-ID: <404EF059-F955-48C1-9654-254B97FA4F17@macports.org>

Paul Magrath wrote:

>>> Yes. However, I'd recommend you use the default /opt install  
>>> location if you were planning on distributing binaries/archives/ 
>>> packages.
>>
>> Sounds like a good recommendation, although it is /opt/local... :-)
>> A common misunderstanding is that ${prefix} is /opt, which is wrong.
>
> I was just using /opt as shorthand for /opt/local.

You mean just like "/usr" is a shorthand for "/usr/local" ? ;-)

I'm sure you know the difference, but sometimes the misunderstanding
is promoted to advise like "to uninstall MacPorts, wipe out /opt" -
which is bound to eventually take out some innocent bystanders too,
even if Apple doesn't install into there someone else might have...

--anders


From afb at macports.org  Wed Aug 13 01:13:45 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Wed, 13 Aug 2008 10:13:45 +0200
Subject: Beta Release
In-Reply-To: <B464AAD8-5769-4E3B-A3EC-F42140F52DE7@macports.org>
References: <F522611A-E138-4671-8461-8E6F78C4329D@macports.org>
	<52F576E2-528B-4A77-B2BE-83AC5074EE0E@macports.org>
	<9673b3e00808120425x3ea47251xa9dace9482e8dd54@mail.gmail.com>
	<3F0BF6D7-A785-480D-8272-96EB6A201D6C@macports.org>
	<B464AAD8-5769-4E3B-A3EC-F42140F52DE7@macports.org>
Message-ID: <EA5F43D6-705B-4989-8C50-31A6FCCA7923@macports.org>

Paul Magrath wrote:

> That is working okay for me now after a few small fixes. If you  
> have a chance, checkout the new code from the svn and let me know  
> if it works okay for you.

Seems that the default Tcl location has a slight bug with DESTDIR,
in that if you install like "make install DESTDIR=/tmp/mp" then
it will put the files in "/tmp/mp~afb/Library/Tcl" instead of in
"/tmp/mp/Users/afb/Library/Tcl" like it was supposed to do...

So most likely that needs to be expanded to an absolute path ?


Other than that little problem (not likely to affect everyone),
it seemed to install and work fine from ~afb/.macports/opt now.

Not sure why installing ports requires root privileges, though ?
Seemed to work just fine with install.asroot=no for most ports...

--anders


From afb at macports.org  Wed Aug 13 01:28:22 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Wed, 13 Aug 2008 10:28:22 +0200
Subject: Beta Release
In-Reply-To: <B464AAD8-5769-4E3B-A3EC-F42140F52DE7@macports.org>
References: <F522611A-E138-4671-8461-8E6F78C4329D@macports.org>
	<52F576E2-528B-4A77-B2BE-83AC5074EE0E@macports.org>
	<9673b3e00808120425x3ea47251xa9dace9482e8dd54@mail.gmail.com>
	<3F0BF6D7-A785-480D-8272-96EB6A201D6C@macports.org>
	<B464AAD8-5769-4E3B-A3EC-F42140F52DE7@macports.org>
Message-ID: <6E2F4C98-189B-40A6-BD82-49C8417335B3@macports.org>

Paul Magrath wrote:

>> Something that I found to be strange was why I would want to install
>> MacPorts into the config directory of ~/.macports (next to history),
>> and this is probably aggrevated by being hidden from Finder et. al ?
>> (At least /opt/local is not hidden, while /usr/local normally is.)
>
> Yes, I've changed the suggested configure to "./configure --prefix=/ 
> Users/{your-user-name}/.macports/opt --with-no-root-privileges" now  
> to better separate the two.

Cool, I was mostly wondering why it would pick a hidden location and
not something user visible like ~/MacPorts as the prefix location ?

Whether applications/frameworks/tcl should be inside or outside is
another discussion, I am only talking about recommended --prefix.

--anders


From pmagrath at macports.org  Wed Aug 13 07:49:25 2008
From: pmagrath at macports.org (Paul Magrath)
Date: Wed, 13 Aug 2008 15:49:25 +0100
Subject: Beta Release
In-Reply-To: <6E2F4C98-189B-40A6-BD82-49C8417335B3@macports.org>
References: <F522611A-E138-4671-8461-8E6F78C4329D@macports.org>
	<52F576E2-528B-4A77-B2BE-83AC5074EE0E@macports.org>
	<9673b3e00808120425x3ea47251xa9dace9482e8dd54@mail.gmail.com>
	<3F0BF6D7-A785-480D-8272-96EB6A201D6C@macports.org>
	<B464AAD8-5769-4E3B-A3EC-F42140F52DE7@macports.org>
	<6E2F4C98-189B-40A6-BD82-49C8417335B3@macports.org>
Message-ID: <CDFBF61F-5D27-4113-981C-B0092F17E66F@macports.org>

On 13 Aug 2008, at 09:28, Anders F Bj?rklund <afb at macports.org> wrote:
>>
> Cool, I was mostly wondering why it would pick a hidden location and
> not something user visible like ~/MacPorts as the prefix location ?

Well, by default most of the unix folders like /etc and /var are  
hidden by Apple so that seems to be the de facto standard. But it is  
just an example. Nothing stopping anyone changing it.

Paul.


From pmagrath at macports.org  Wed Aug 13 07:53:48 2008
From: pmagrath at macports.org (Paul Magrath)
Date: Wed, 13 Aug 2008 15:53:48 +0100
Subject: Beta Release
In-Reply-To: <EA5F43D6-705B-4989-8C50-31A6FCCA7923@macports.org>
References: <F522611A-E138-4671-8461-8E6F78C4329D@macports.org>
	<52F576E2-528B-4A77-B2BE-83AC5074EE0E@macports.org>
	<9673b3e00808120425x3ea47251xa9dace9482e8dd54@mail.gmail.com>
	<3F0BF6D7-A785-480D-8272-96EB6A201D6C@macports.org>
	<B464AAD8-5769-4E3B-A3EC-F42140F52DE7@macports.org>
	<EA5F43D6-705B-4989-8C50-31A6FCCA7923@macports.org>
Message-ID: <66FF50DB-5F11-4EC9-8729-CF8A20164B9E@macports.org>

On 13 Aug 2008, at 09:13, Anders F Bj?rklund <afb at macports.org> wrote:

> Paul Magrath wrote:
>
>> That is working okay for me now after a few small fixes. If you  
>> have a chance, checkout the new code from the svn and let me know  
>> if it works okay for you.
>
> Seems that the default Tcl location has a slight bug with DESTDIR,
> in that if you install like "make install DESTDIR=/tmp/mp" then
> it will put the files in "/tmp/mp~afb/Library/Tcl" instead of in
> "/tmp/mp/Users/afb/Library/Tcl" like it was supposed to do...

Can you describe in detail how to reproduce the bug please?
> Other than that little problem (not likely to affect everyone),
> it seemed to install and work fine from ~afb/.macports/opt now.

Good to hear! :)

> Not sure why installing ports requires root privileges, though ?
> Seemed to work just fine with install.asroot=no for most ports...

This was just me erring on the conservative side. I think I might  
finetune that behavior a bit.

Thanks again for being a willing guinea pig!

Paul.


From afb at macports.org  Wed Aug 13 08:08:06 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Wed, 13 Aug 2008 17:08:06 +0200
Subject: Beta Release
In-Reply-To: <66FF50DB-5F11-4EC9-8729-CF8A20164B9E@macports.org>
References: <F522611A-E138-4671-8461-8E6F78C4329D@macports.org>
	<52F576E2-528B-4A77-B2BE-83AC5074EE0E@macports.org>
	<9673b3e00808120425x3ea47251xa9dace9482e8dd54@mail.gmail.com>
	<3F0BF6D7-A785-480D-8272-96EB6A201D6C@macports.org>
	<B464AAD8-5769-4E3B-A3EC-F42140F52DE7@macports.org>
	<EA5F43D6-705B-4989-8C50-31A6FCCA7923@macports.org>
	<66FF50DB-5F11-4EC9-8729-CF8A20164B9E@macports.org>
Message-ID: <A37641AC-F78E-493D-808F-F9E99E71D22F@macports.org>

Paul Magrath wrote:

>> Seems that the default Tcl location has a slight bug with DESTDIR,
>> in that if you install like "make install DESTDIR=/tmp/mp" then
>> it will put the files in "/tmp/mp~afb/Library/Tcl" instead of in
>> "/tmp/mp/Users/afb/Library/Tcl" like it was supposed to do...
>
> Can you describe in detail how to reproduce the bug please?

Sure, if you look in src/macports1.0/Makefile there's a line like:
INSTALLDIR=	${DESTDIR}${TCL_PACKAGE_DIR}/macports1.0

This doesn't work when TCL_PACKAGE_DIR='~afb/Library/Tcl' and
DESTDIR is anything other than empty, due to ~ not expanding.
Creative workarounds to this problem include something like:
"${DESTDIR}`cd ${TCL_PACKAGE_DIR} && pwd`/macports1.0"


As mentioned briefly above, the reproducer is:
make install DESTDIR=/tmp/mp && ls -d /tmp/mp*

It is supposed to list just /tmp/mp, but lists:
/tmp/mp         /tmp/mp~afb

--anders

PS.
It is possible that this expansion should be done by configure.
Most likely, applications and frameworks have the same problem.


From jkh at apple.com  Wed Aug 13 09:52:55 2008
From: jkh at apple.com (Jordan K. Hubbard)
Date: Wed, 13 Aug 2008 09:52:55 -0700
Subject: Beta Release
In-Reply-To: <404EF059-F955-48C1-9654-254B97FA4F17@macports.org>
References: <F522611A-E138-4671-8461-8E6F78C4329D@macports.org>
	<52F576E2-528B-4A77-B2BE-83AC5074EE0E@macports.org>
	<9673b3e00808120425x3ea47251xa9dace9482e8dd54@mail.gmail.com>
	<3F0BF6D7-A785-480D-8272-96EB6A201D6C@macports.org>
	<B464AAD8-5769-4E3B-A3EC-F42140F52DE7@macports.org>
	<404EF059-F955-48C1-9654-254B97FA4F17@macports.org>
Message-ID: <E1A630E8-6782-4B59-B22B-79940E18F71D@apple.com>


On Aug 13, 2008, at 12:54 AM, Anders F Bj?rklund wrote:

> I'm sure you know the difference, but sometimes the misunderstanding
> is promoted to advise like "to uninstall MacPorts, wipe out /opt" -
> which is bound to eventually take out some innocent bystanders too,
> even if Apple doesn't install into there someone else might have...

Good advice, particularly since Apple does install stuff under /opt if  
you install MacOSX Server..

- Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080813/6189c9fe/attachment.html 

From ryandesign at macports.org  Wed Aug 13 14:15:41 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 13 Aug 2008 16:15:41 -0500
Subject: MacPorts 1.7.0 without GSoC contributions
Message-ID: <646382D6-E669-44EC-BC7C-F520A6FCBEA3@macports.org>

I would think we would want to release MacPorts 1.7.0 without the  
Google Summer of Code contributions, simply since I expect most users  
haven't tested that code yet and we want to release code that's well- 
tested. We probably don't need to make a 1.7 branch right now, but I  
would keep this in mind so that whenever we do create 1.7.0 we do so  
from a point before the GSoC code is merged in (and then merge into  
the 1.7 branch changes made on trunk after the GSoC merges if  
necessary).


From randall.h.wood at alexandriasoftware.com  Thu Aug 14 03:15:29 2008
From: randall.h.wood at alexandriasoftware.com (Randall Wood)
Date: Thu, 14 Aug 2008 06:15:29 -0400
Subject: Fwd: MacPorts 1.7.0 without GSoC contributions
In-Reply-To: <c24012060808140315q5339043eya2ad3941369edaca@mail.gmail.com>
References: <646382D6-E669-44EC-BC7C-F520A6FCBEA3@macports.org>
	<c24012060808140315q5339043eya2ad3941369edaca@mail.gmail.com>
Message-ID: <c24012060808140315p1cd4f574v24fdd8ad7ba1943c@mail.gmail.com>

Sorry, failed to reply to all.


---------- Forwarded message ----------
From: Randall Wood <randall.h.wood at alexandriasoftware.com>
Date: Thu, Aug 14, 2008 at 6:15 AM
Subject: Re: MacPorts 1.7.0 without GSoC contributions
To: Ryan Schmidt <ryandesign at macports.org>


Why not call it 1.6.1 and branch 1.7.0 once the GSoC privileges code
is integrated? The Framework is (being) designed to ship as a port.

On Wed, Aug 13, 2008 at 5:15 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> I would think we would want to release MacPorts 1.7.0 without the
> Google Summer of Code contributions, simply since I expect most users
> haven't tested that code yet and we want to release code that's well-
> tested. We probably don't need to make a 1.7 branch right now, but I
> would keep this in mind so that whenever we do create 1.7.0 we do so
> from a point before the GSoC code is merged in (and then merge into
> the 1.7 branch changes made on trunk after the GSoC merges if
> necessary).
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>



--
Randall Wood
randall.h.wood at alexandriasoftware.com

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



-- 
Randall Wood
randall.h.wood at alexandriasoftware.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  Thu Aug 14 04:19:24 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 14 Aug 2008 06:19:24 -0500
Subject: MacPorts 1.7.0 without GSoC contributions
In-Reply-To: <c24012060808140315q5339043eya2ad3941369edaca@mail.gmail.com>
References: <646382D6-E669-44EC-BC7C-F520A6FCBEA3@macports.org>
	<c24012060808140315q5339043eya2ad3941369edaca@mail.gmail.com>
Message-ID: <DC15DEF5-B6F7-42D9-B016-8B6AE65D2692@macports.org>

We have 9 months of development on trunk since 1.6.0. It has several  
new features, not just bugfixes, so it seems big enough and different  
enough to warrant the 1.7.0 version number. Also, we have a bug in  
the 1.6.0 disk image installer whereby the .profile doesn't get  
created. Policy thus far has been to only create disk images for .0  
releases so 1.7.0 would be the first version that could fix that (not  
that I like this policy...).

On Aug 14, 2008, at 05:15, Randall Wood wrote:

> Why not call it 1.6.1 and branch 1.7.0 once the GSoC privileges code
> is integrated? The Framework is (being) designed to ship as a port.
>
> On Wed, Aug 13, 2008 at 5:15 PM, Ryan Schmidt wrote:
>
>> I would think we would want to release MacPorts 1.7.0 without the
>> Google Summer of Code contributions, simply since I expect most users
>> haven't tested that code yet and we want to release code that's well-
>> tested. We probably don't need to make a 1.7 branch right now, but I
>> would keep this in mind so that whenever we do create 1.7.0 we do so
>> from a point before the GSoC code is merged in (and then merge into
>> the 1.7 branch changes made on trunk after the GSoC merges if
>> necessary).



From florian.ebeling at gmail.com  Thu Aug 14 04:46:56 2008
From: florian.ebeling at gmail.com (Caspar Florian Ebeling)
Date: Thu, 14 Aug 2008 13:46:56 +0200
Subject: MacPorts 1.7.0 without GSoC contributions
In-Reply-To: <DC15DEF5-B6F7-42D9-B016-8B6AE65D2692@macports.org>
References: <646382D6-E669-44EC-BC7C-F520A6FCBEA3@macports.org>
	<c24012060808140315q5339043eya2ad3941369edaca@mail.gmail.com>
	<DC15DEF5-B6F7-42D9-B016-8B6AE65D2692@macports.org>
Message-ID: <5cbbe4ae0808140446j7af5bcaagb10061b468a24e15@mail.gmail.com>

In general I think it is not good to hold back features, they should
rather be there and usable once created.

That said, I can understand Ryan's worry very well. There hasn't been
a release in ages, and if the next release cycle is as long as the
current one, the upcoming release better be good, not buggy.

But the real problem is the frequence of releases. Ideally there
would be a release every 4 to 6 weeks, plus bugfix releases, IMHO.
Using such a policy, new features could be integrated immediately
because the cost of a bug would be rather minimal.

If the current release manager does not have the time to do releases,
why can't a new one be appointed, at least for the time being.
It's no shame to be too involved in a day-job or whatever to run an open source
project in the evening, but it's also not helpful not to deal with
consequences. Ryan has hinted several times that he would
not shy away from this job, apparently he has some time at his
hands to work on the project, and he certainly has the necessary
attention to detail. Shouldn't we ask him? And who has to decide this
ultimately?

Florian


On Thu, Aug 14, 2008 at 1:19 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> We have 9 months of development on trunk since 1.6.0. It has several
> new features, not just bugfixes, so it seems big enough and different
> enough to warrant the 1.7.0 version number. Also, we have a bug in
> the 1.6.0 disk image installer whereby the .profile doesn't get
> created. Policy thus far has been to only create disk images for .0
> releases so 1.7.0 would be the first version that could fix that (not
> that I like this policy...).
>
> On Aug 14, 2008, at 05:15, Randall Wood wrote:
>
>> Why not call it 1.6.1 and branch 1.7.0 once the GSoC privileges code
>> is integrated? The Framework is (being) designed to ship as a port.
>>
>> On Wed, Aug 13, 2008 at 5:15 PM, Ryan Schmidt wrote:
>>
>>> I would think we would want to release MacPorts 1.7.0 without the
>>> Google Summer of Code contributions, simply since I expect most users
>>> haven't tested that code yet and we want to release code that's well-
>>> tested. We probably don't need to make a 1.7 branch right now, but I
>>> would keep this in mind so that whenever we do create 1.7.0 we do so
>>> from a point before the GSoC code is merged in (and then merge into
>>> the 1.7 branch changes made on trunk after the GSoC merges if
>>> necessary).
>
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>



-- 
Florian Ebeling
florian.ebeling at gmail.com

From afb at macports.org  Thu Aug 14 04:49:17 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Thu, 14 Aug 2008 13:49:17 +0200
Subject: MacPorts 1.7.0 without GSoC contributions
In-Reply-To: <DC15DEF5-B6F7-42D9-B016-8B6AE65D2692@macports.org>
References: <646382D6-E669-44EC-BC7C-F520A6FCBEA3@macports.org>
	<c24012060808140315q5339043eya2ad3941369edaca@mail.gmail.com>
	<DC15DEF5-B6F7-42D9-B016-8B6AE65D2692@macports.org>
Message-ID: <1C879485-51E0-490A-9FDB-9A10D84EAAB8@macports.org>

Ryan Schmidt wrote:

> We have 9 months of development on trunk since 1.6.0. It has several
> new features, not just bugfixes, so it seems big enough and different
> enough to warrant the 1.7.0 version number. Also, we have a bug in
> the 1.6.0 disk image installer whereby the .profile doesn't get
> created. Policy thus far has been to only create disk images for .0
> releases so 1.7.0 would be the first version that could fix that (not
> that I like this policy...).
>
> On Aug 14, 2008, at 05:15, Randall Wood wrote:
>
>> Why not call it 1.6.1 and branch 1.7.0 once the GSoC privileges code
>> is integrated? The Framework is (being) designed to ship as a port.

You can always cherry-pick stuff from trunk and call it "1.7.0",
and then go on developing anything remaining as "1_8" instead...
Unless there is some feature that would merit keeping with 1.6.x
and splitting base into 1.6.1 "stable" and 1.7.0 "unstable" now ?

Either way, it would need a new Release Manager to be appointed.
http://trac.macports.org/browser/trunk/base/portmgr/ReleaseProcess

Some other things that could be discussed would be Panther support
(Fink dropped 10.3 recently) and fixing some ports before archiving.
Like if the changes to Python and Ruby (maybe even Perl ?) should
happen before this release, or if they should go with the next one.

--anders


From afb at macports.org  Thu Aug 14 04:59:35 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Thu, 14 Aug 2008 13:59:35 +0200
Subject: MacPorts 1.7.0 without GSoC contributions
In-Reply-To: <5cbbe4ae0808140446j7af5bcaagb10061b468a24e15@mail.gmail.com>
References: <646382D6-E669-44EC-BC7C-F520A6FCBEA3@macports.org>
	<c24012060808140315q5339043eya2ad3941369edaca@mail.gmail.com>
	<DC15DEF5-B6F7-42D9-B016-8B6AE65D2692@macports.org>
	<5cbbe4ae0808140446j7af5bcaagb10061b468a24e15@mail.gmail.com>
Message-ID: <C28E8DB2-2DF2-4823-AAA8-C38651CC43E0@macports.org>

Caspar Florian Ebeling wrote:

> In general I think it is not good to hold back features, they should
> rather be there and usable once created.

There's plenty of features not being added to MacPorts just because
they would mix with daily usage of trunk since there is no stable...
Some of these are being held in private repositories or branches,
and some might simply not be implemented - in any reasonable pace.

Releasing something/anything would open up the experimentation again.
Or at least that is how it works in other projects, that do releases ?

> That said, I can understand Ryan's worry very well. There hasn't been
> a release in ages, and if the next release cycle is as long as the
> current one, the upcoming release better be good, not buggy.

Then something needs to be set up for testing ("Release Candidate"
or more like alpha/beta perhaps) this - sooner rather than later ?

I did some of the patches/coding that are in trunk currently, and
I've been over them with respect to release status before - and I
could do it again with a new release manager should it be needed...
But I do not want to take on that position myself, though. Sorry.

--anders


From florian.ebeling at gmail.com  Thu Aug 14 07:57:14 2008
From: florian.ebeling at gmail.com (Caspar Florian Ebeling)
Date: Thu, 14 Aug 2008 16:57:14 +0200
Subject: MacPorts 1.7.0 without GSoC contributions
In-Reply-To: <C28E8DB2-2DF2-4823-AAA8-C38651CC43E0@macports.org>
References: <646382D6-E669-44EC-BC7C-F520A6FCBEA3@macports.org>
	<c24012060808140315q5339043eya2ad3941369edaca@mail.gmail.com>
	<DC15DEF5-B6F7-42D9-B016-8B6AE65D2692@macports.org>
	<5cbbe4ae0808140446j7af5bcaagb10061b468a24e15@mail.gmail.com>
	<C28E8DB2-2DF2-4823-AAA8-C38651CC43E0@macports.org>
Message-ID: <5cbbe4ae0808140757m4c6af6d6la0fbff598af8d1b8@mail.gmail.com>

> Releasing something/anything would open up the experimentation again.

That's my hope as well.

>> That said, I can understand Ryan's worry very well. There hasn't been
>> a release in ages, and if the next release cycle is as long as the
>> current one, the upcoming release better be good, not buggy.
>
> Then something needs to be set up for testing ("Release Candidate"
> or more like alpha/beta perhaps) this - sooner rather than later ?

Didn't mean to scare anyone with my "better be good". The argument also
works the other way around, after all. If releases come more frequently,
the individual one need not be as perfect, because the next release gives
oppotunity to fix things. That's probably the rationale of "Release early,
release often." And if your changes are in trunk, then I'm quite confident
that they are well-tested already. I don't really see a need for a long Beta
since many people run trunk already, me included.

Florian

-- 
Florian Ebeling
florian.ebeling at gmail.com

From sal at ri.cmu.edu  Thu Aug 14 09:50:15 2008
From: sal at ri.cmu.edu (Salvatore Domenick Desiano)
Date: Thu, 14 Aug 2008 12:50:15 -0400
Subject: p5-error (Ticket #16297)
Message-ID: <48A46247.8080407@ri.cmu.edu>

Can someone please commit this? I don't have my commit bit set and don't 
have time to take care of that this month.

Thank you.

-- sal
smile.

From ryandesign at macports.org  Thu Aug 14 14:32:54 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 14 Aug 2008 16:32:54 -0500
Subject: MacPorts 1.7.0 without GSoC contributions
In-Reply-To: <5cbbe4ae0808140757m4c6af6d6la0fbff598af8d1b8@mail.gmail.com>
References: <646382D6-E669-44EC-BC7C-F520A6FCBEA3@macports.org>
	<c24012060808140315q5339043eya2ad3941369edaca@mail.gmail.com>
	<DC15DEF5-B6F7-42D9-B016-8B6AE65D2692@macports.org>
	<5cbbe4ae0808140446j7af5bcaagb10061b468a24e15@mail.gmail.com>
	<C28E8DB2-2DF2-4823-AAA8-C38651CC43E0@macports.org>
	<5cbbe4ae0808140757m4c6af6d6la0fbff598af8d1b8@mail.gmail.com>
Message-ID: <0D4BC9F9-DEF4-4132-8CD4-3074495878D9@macports.org>


On Aug 14, 2008, at 09:57, Caspar Florian Ebeling wrote:

>> Releasing something/anything would open up the experimentation again.
>
> That's my hope as well.
>
>>> That said, I can understand Ryan's worry very well. There hasn't  
>>> been
>>> a release in ages, and if the next release cycle is as long as the
>>> current one, the upcoming release better be good, not buggy.
>>
>> Then something needs to be set up for testing ("Release Candidate"
>> or more like alpha/beta perhaps) this - sooner rather than later ?
>
> Didn't mean to scare anyone with my "better be good".

Oh, I agree, 1.7.0 better be good. :) And I'm all for a release  
candidate or two; we do, after all, need to test the dmg  
installer's .profile creation code, which is not getting exercised by  
any of us running self-compiled trunk builds.

> The argument also
> works the other way around, after all. If releases come more  
> frequently,
> the individual one need not be as perfect, because the next release  
> gives
> oppotunity to fix things. That's probably the rationale of "Release  
> early,
> release often." And if your changes are in trunk, then I'm quite  
> confident
> that they are well-tested already. I don't really see a need for a  
> long Beta
> since many people run trunk already, me included.

That's why I want to release what we've been testing on trunk as  
1.7.0, rather than include the untested (by me at least) GSoC  
contributions which are about to get merged into trunk (as I  
understand it).


From armahg at gmail.com  Thu Aug 14 14:49:16 2008
From: armahg at gmail.com (George Armah)
Date: Thu, 14 Aug 2008 14:49:16 -0700
Subject: MacPorts 1.7.0 without GSoC contributions
In-Reply-To: <0D4BC9F9-DEF4-4132-8CD4-3074495878D9@macports.org>
References: <646382D6-E669-44EC-BC7C-F520A6FCBEA3@macports.org>	<c24012060808140315q5339043eya2ad3941369edaca@mail.gmail.com>	<DC15DEF5-B6F7-42D9-B016-8B6AE65D2692@macports.org>	<5cbbe4ae0808140446j7af5bcaagb10061b468a24e15@mail.gmail.com>	<C28E8DB2-2DF2-4823-AAA8-C38651CC43E0@macports.org>	<5cbbe4ae0808140757m4c6af6d6la0fbff598af8d1b8@mail.gmail.com>
	<0D4BC9F9-DEF4-4132-8CD4-3074495878D9@macports.org>
Message-ID: <48A4A85C.2080105@gmail.com>

Ryan Schmidt wrote:
> On Aug 14, 2008, at 09:57, Caspar Florian Ebeling wrote:
>
>   
>>> Releasing something/anything would open up the experimentation again.
>>>       
>> That's my hope as well.
>>
>>     
>>>> That said, I can understand Ryan's worry very well. There hasn't  
>>>> been
>>>> a release in ages, and if the next release cycle is as long as the
>>>> current one, the upcoming release better be good, not buggy.
>>>>         
>>> Then something needs to be set up for testing ("Release Candidate"
>>> or more like alpha/beta perhaps) this - sooner rather than later ?
>>>       
>> Didn't mean to scare anyone with my "better be good".
>>     
>
> Oh, I agree, 1.7.0 better be good. :) And I'm all for a release  
> candidate or two; we do, after all, need to test the dmg  
> installer's .profile creation code, which is not getting exercised by  
> any of us running self-compiled trunk builds.
>
>   
>> The argument also
>> works the other way around, after all. If releases come more  
>> frequently,
>> the individual one need not be as perfect, because the next release  
>> gives
>> oppotunity to fix things. That's probably the rationale of "Release  
>> early,
>> release often." And if your changes are in trunk, then I'm quite  
>> confident
>> that they are well-tested already. I don't really see a need for a  
>> long Beta
>> since many people run trunk already, me included.
>>     
>
> That's why I want to release what we've been testing on trunk as  
> 1.7.0, rather than include the untested (by me at least) GSoC  
> contributions which are about to get merged into trunk (as I  
> understand it).
>   

If 1.7.0 has enough new additions that will be beneficial to users I 
don't think its release
should be held up by GSoC. The GSoC contributions will need some testing 
period and
could be added later on in say a 1.7.1 release.


> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080814/809e8477/attachment.html 

From ryandesign at macports.org  Fri Aug 15 17:34:02 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 15 Aug 2008 19:34:02 -0500
Subject: [39286] trunk/dports/databases/oracle-instantclient/Portfile
In-Reply-To: <5050E6DA-A326-4017-88B9-FF70FD56261D@geeklair.net>
References: <20080815224327.123E41F02AE@beta.macosforge.org>
	<5050E6DA-A326-4017-88B9-FF70FD56261D@geeklair.net>
Message-ID: <D8A23420-7E8B-48ED-BC22-FC3AB70CD118@macports.org>

On Aug 15, 2008, at 18:08, Daniel J. Luke wrote:

> On Aug 15, 2008, at 6:43 PM, ryandesign at macports.org wrote:
>
>> +    # This is really awful. Oracle provides different version  
>> numbers of the
>> +    # Instant Client library for PowerPC and Intel. You should  
>> not change the
>> +    # version number of a port conditionally like this. But I  
>> don't know how \
>> +    # else to handle this here. Hopefully Oracle will release a  
>> new version \
>> +    # of the libraries with the same version number on both  
>> PowerPC and Intel.
>
> An alternate way of handling this would be to make the oracle- 
> instantclient port an empty port that just depends on either the  
> PPC or intel version of the client (which you would make new ports  
> for).


How do I handle upgrading from the current port to that? If oracle- 
instantclient is changed to depend on oracle-instantclient-intel,  
say, and oracle-instantclient-intel installs the files that are  
currently installed by oracle-instantclient, then MacPorts will try  
to install oracle-instantclient-intel first before uninstalling the  
old oracle-instantclient and it'll have an activation error because  
the files are still there.


From dluke at geeklair.net  Sat Aug 16 07:53:35 2008
From: dluke at geeklair.net (Daniel J. Luke)
Date: Sat, 16 Aug 2008 10:53:35 -0400
Subject: [39286] trunk/dports/databases/oracle-instantclient/Portfile
In-Reply-To: <D8A23420-7E8B-48ED-BC22-FC3AB70CD118@macports.org>
References: <20080815224327.123E41F02AE@beta.macosforge.org>
	<5050E6DA-A326-4017-88B9-FF70FD56261D@geeklair.net>
	<D8A23420-7E8B-48ED-BC22-FC3AB70CD118@macports.org>
Message-ID: <E6E6F4D7-435D-43F8-9DAF-DEF6CFC1678C@geeklair.net>

On Aug 15, 2008, at 8:34 PM, Ryan Schmidt wrote:
>> An alternate way of handling this would be to make the oracle- 
>> instantclient port an empty port that just depends on either the  
>> PPC or intel version of the client (which you would make new ports  
>> for).
>
> How do I handle upgrading from the current port to that? If oracle- 
> instantclient is changed to depend on oracle-instantclient-intel,  
> say, and oracle-instantclient-intel installs the files that are  
> currently installed by oracle-instantclient, then MacPorts will try  
> to install oracle-instantclient-intel first before uninstalling the  
> old oracle-instantclient and it'll have an activation error because  
> the files are still there.


I don't know of a good way of doing it.

I think it's preferable to suffer some immediate pain (with ui_msg  
instructions to tell people to uninstall the old instantclient) in  
order to get it fixed, though.

You could also change where things get installed so that the platform- 
specific instantclients don't conflict with the current port, but  
that's probably not a great solution.

--
Daniel J. Luke
+========================================================+
| *---------------- dluke at 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: 194 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080816/067ce913/attachment.bin 

From ryandesign at macports.org  Mon Aug 18 01:38:00 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 18 Aug 2008 03:38:00 -0500
Subject: [39320] trunk/dports/net
In-Reply-To: <20080818080515.107231F6B81@beta.macosforge.org>
References: <20080818080515.107231F6B81@beta.macosforge.org>
Message-ID: <1384F4A0-79B9-4CA9-B62E-FCA364B1F244@macports.org>

You can't hardcode /opt/local into the patchfiles like that. MacPorts  
may be installed into a different prefix. You need to handle this  
with a reinplace, not patchfiles.

On Aug 18, 2008, at 03:05, rene at macports.org wrote:

> Revision: 39320
>           http://trac.macosforge.org/projects/macports/changeset/39320
> Author:   rene at macports.org
> Date:     2008-08-18 01:05:13 -0700 (Mon, 18 Aug 2008)
> Log Message:
> -----------
> net/gajim: New port. (0.11.4) A full featured Jabber client.
>
> Added Paths:
> -----------
>     trunk/dports/net/gajim/
>     trunk/dports/net/gajim/Portfile
>     trunk/dports/net/gajim/files/
>     trunk/dports/net/gajim/files/patch-scripts-gajim-remote.in.diff
>     trunk/dports/net/gajim/files/patch-scripts-gajim.in.diff
>     trunk/dports/net/gajim/files/patch-src-Makefile.in.diff
>
> Added: trunk/dports/net/gajim/Portfile
> ===================================================================
> --- trunk/dports/net/gajim/Portfile	                        (rev 0)
> +++ trunk/dports/net/gajim/Portfile	2008-08-18 08:05:13 UTC (rev  
> 39320)
> @@ -0,0 +1,80 @@
> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode:  
> nil; c-basic-off    set: 4 -*-  
> vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
> +# $Id$
> +
> +PortSystem          1.0
> +
> +name                gajim
> +version             0.11.4
> +homepage            http://www.gajim.org/
> +categories          net chat x11
> +
> +description         A full featured and easy to use Jabber client.
> +long_description    The goal of Gajim is to provide a full  
> featured and \
> +                    easy to use Jabber client. Gajim works nicely  
> with \
> +                    GNOME, but does not require it to run.
> +
> +maintainers         rene
> +
> +platforms           darwin
> +
> +master_sites        http://www.gajim.org/downloads/
> +distname            ${name}-${version}
> +use_bzip2           yes
> +checksums           md5 53eb80b280674678f6615eae4a552374 \
> +                    sha1 66c3c2aba9cea8e0e48581e87e412b445040ac15 \
> +                    rmd160 77ddba3f06c1b4dc80c0c3efe1951cbb0fac07e0
> +
> +depends_lib         port:gettext \
> +                    port:gtk2 \
> +                    port:py25-gtk \
> +                    port:py25-gobject \
> +                    port:py25-docutils \
> +                    port:py25-socket-ssl \
> +                    port:dbus-python25
> +
> +patchfiles          patch-scripts-gajim.in.diff \
> +                    patch-scripts-gajim-remote.in.diff \
> +                    patch-src-Makefile.in.diff
> +
> +configure.args      --disable-trayicon \
> +                    --enable-idle \
> +                    --disable-gtkspell \
> +                    --enable-remote \
> +                    --enable-nls
> +
> +variant gnome description {Add GNOME support} {
> +    depends_lib-append      port:gnome-python-desktop
> +}
> +
> +variant zeroconf description {Add zeroconf (Bonjour) support} {
> +    depends_lib-append      port:dbus-glib \
> +                            port:avahi
> +}
> +
> +variant trayicon description {Add trayicon support} {
> +    configure.args-delete   --disable-trayicon
> +    configure.args-append   --enable-trayicon
> +}
> +
> +variant noidle description {Disable idle support} {
> +    configure.args-delete   --enable-idle
> +    configure.args-append   --disable-idle
> +}
> +
> +variant noremote description {Add remote support} {
> +    configure.args-delete   --disable-remote
> +    configure.args-append   --enable-remote
> +    depends_lib-append      port:dbus
> +}
> +
> +variant nonls description {Disable native language support} {
> +    configure.args-delete   --enable-nls
> +    configure.args-append   --disable-nls
> +}
> +
> +variant gtkspell description {Add gtkspell support} {
> +    configure.args-delete   --disable-gtkspell
> +    configure.args-append   --enable-gtkspell
> +    depends_lib-append      port:gtkspell2
> +}
> +
>
>
> Property changes on: trunk/dports/net/gajim/Portfile
> ___________________________________________________________________
> Name: svn:keywords
>    + Id
> Name: svn:eol-style
>    + native
>
> Added: trunk/dports/net/gajim/files/patch-scripts-gajim-remote.in.diff
> ===================================================================
> --- trunk/dports/net/gajim/files/patch-scripts-gajim- 
> remote.in.diff	                        (rev 0)
> +++ trunk/dports/net/gajim/files/patch-scripts-gajim-remote.in.diff	 
> 2008-08-18 08:05:13 UTC (rev 39320)
> @@ -0,0 +1,11 @@
> +--- scripts/gajim-remote.in.orig	2008-08-18 09:38:59.000000000 +0200
> ++++ scripts/gajim-remote.in	2008-08-18 09:38:05.000000000 +0200
> +@@ -29,7 +29,7 @@
> + fi
> +
> + datadir=@DATADIR@
> +-PYTHON_EXEC=@PYTHON@
> ++PYTHON_EXEC=/opt/local/bin/python2.5
> +
> + cd ${datadir}/gajim/src
> + export PYTHONPATH="$PYTHONPATH:@LIBDIR@/gajim"
>
> Added: trunk/dports/net/gajim/files/patch-scripts-gajim.in.diff
> ===================================================================
> --- trunk/dports/net/gajim/files/patch-scripts- 
> gajim.in.diff	                        (rev 0)
> +++ trunk/dports/net/gajim/files/patch-scripts-gajim.in.diff	 
> 2008-08-18 08:05:13 UTC (rev 39320)
> @@ -0,0 +1,11 @@
> +--- scripts/gajim.in.orig	2008-08-17 18:10:06.000000000 +0200
> ++++ scripts/gajim.in	2008-08-17 18:10:26.000000000 +0200
> +@@ -28,7 +28,7 @@
> + fi
> +
> + datadir=@DATADIR@
> +-PYTHON_EXEC=@PYTHON@
> ++PYTHON_EXEC=/opt/local/bin/python2.5
> +
> + cd ${datadir}/gajim/src
> + export PYTHONPATH="$PYTHONPATH:@LIBDIR@/gajim"
>
> Added: trunk/dports/net/gajim/files/patch-src-Makefile.in.diff
> ===================================================================
> --- trunk/dports/net/gajim/files/patch-src- 
> Makefile.in.diff	                        (rev 0)
> +++ trunk/dports/net/gajim/files/patch-src-Makefile.in.diff	 
> 2008-08-18 08:05:13 UTC (rev 39320)
> @@ -0,0 +1,11 @@
> +--- src/Makefile.in.orig	2008-08-18 08:57:14.000000000 +0200
> ++++ src/Makefile.in	2008-08-18 08:57:53.000000000 +0200
> +@@ -294,7 +294,7 @@
> + 	trayicon.c
> +
> + INCLUDES = \
> +-	$(PYTHON_INCLUDES)
> ++	-I/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
> include/python2.5/
> +
> + @BUILD_GTKSPELL_TRUE at gtkspelllib_LTLIBRARIES = gtkspell.la
> + @BUILD_GTKSPELL_TRUE at gtkspelllibdir = $(libdir)/gajim
> _______________________________________________
> macports-changes mailing list
> macports-changes at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes


From rene at macports.org  Mon Aug 18 01:40:22 2008
From: rene at macports.org (=?ISO-8859-1?Q?Ren=E9_K=FCttner?=)
Date: Mon, 18 Aug 2008 10:40:22 +0200
Subject: [39320] trunk/dports/net
In-Reply-To: <1384F4A0-79B9-4CA9-B62E-FCA364B1F244@macports.org>
References: <20080818080515.107231F6B81@beta.macosforge.org>
	<1384F4A0-79B9-4CA9-B62E-FCA364B1F244@macports.org>
Message-ID: <02C22D1C-B1C2-4465-8B7B-259883E2F5B4@macports.org>

Thank you, I'll fix that.

Am 18.08.2008 um 10:38 schrieb Ryan Schmidt:

> You can't hardcode /opt/local into the patchfiles like that.  
> MacPorts may be installed into a different prefix. You need to  
> handle this with a reinplace, not patchfiles.
>
> On Aug 18, 2008, at 03:05, rene at macports.org wrote:
>
>> Revision: 39320
>>          http://trac.macosforge.org/projects/macports/changeset/39320
>> Author:   rene at macports.org
>> Date:     2008-08-18 01:05:13 -0700 (Mon, 18 Aug 2008)
>> Log Message:
>> -----------
>> net/gajim: New port. (0.11.4) A full featured Jabber client.
>>
>> Added Paths:
>> -----------
>>    trunk/dports/net/gajim/
>>    trunk/dports/net/gajim/Portfile
>>    trunk/dports/net/gajim/files/
>>    trunk/dports/net/gajim/files/patch-scripts-gajim-remote.in.diff
>>    trunk/dports/net/gajim/files/patch-scripts-gajim.in.diff
>>    trunk/dports/net/gajim/files/patch-src-Makefile.in.diff
>>
>> Added: trunk/dports/net/gajim/Portfile
>> ===================================================================
>> --- trunk/dports/net/gajim/Portfile	                        (rev 0)
>> +++ trunk/dports/net/gajim/Portfile	2008-08-18 08:05:13 UTC (rev  
>> 39320)
>> @@ -0,0 +1,80 @@
>> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode:  
>> nil; c-basic-off    set: 4 -*-  
>> vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
>> +# $Id$
>> +
>> +PortSystem          1.0
>> +
>> +name                gajim
>> +version             0.11.4
>> +homepage            http://www.gajim.org/
>> +categories          net chat x11
>> +
>> +description         A full featured and easy to use Jabber client.
>> +long_description    The goal of Gajim is to provide a full  
>> featured and \
>> +                    easy to use Jabber client. Gajim works nicely  
>> with \
>> +                    GNOME, but does not require it to run.
>> +
>> +maintainers         rene
>> +
>> +platforms           darwin
>> +
>> +master_sites        http://www.gajim.org/downloads/
>> +distname            ${name}-${version}
>> +use_bzip2           yes
>> +checksums           md5 53eb80b280674678f6615eae4a552374 \
>> +                    sha1 66c3c2aba9cea8e0e48581e87e412b445040ac15 \
>> +                    rmd160 77ddba3f06c1b4dc80c0c3efe1951cbb0fac07e0
>> +
>> +depends_lib         port:gettext \
>> +                    port:gtk2 \
>> +                    port:py25-gtk \
>> +                    port:py25-gobject \
>> +                    port:py25-docutils \
>> +                    port:py25-socket-ssl \
>> +                    port:dbus-python25
>> +
>> +patchfiles          patch-scripts-gajim.in.diff \
>> +                    patch-scripts-gajim-remote.in.diff \
>> +                    patch-src-Makefile.in.diff
>> +
>> +configure.args      --disable-trayicon \
>> +                    --enable-idle \
>> +                    --disable-gtkspell \
>> +                    --enable-remote \
>> +                    --enable-nls
>> +
>> +variant gnome description {Add GNOME support} {
>> +    depends_lib-append      port:gnome-python-desktop
>> +}
>> +
>> +variant zeroconf description {Add zeroconf (Bonjour) support} {
>> +    depends_lib-append      port:dbus-glib \
>> +                            port:avahi
>> +}
>> +
>> +variant trayicon description {Add trayicon support} {
>> +    configure.args-delete   --disable-trayicon
>> +    configure.args-append   --enable-trayicon
>> +}
>> +
>> +variant noidle description {Disable idle support} {
>> +    configure.args-delete   --enable-idle
>> +    configure.args-append   --disable-idle
>> +}
>> +
>> +variant noremote description {Add remote support} {
>> +    configure.args-delete   --disable-remote
>> +    configure.args-append   --enable-remote
>> +    depends_lib-append      port:dbus
>> +}
>> +
>> +variant nonls description {Disable native language support} {
>> +    configure.args-delete   --enable-nls
>> +    configure.args-append   --disable-nls
>> +}
>> +
>> +variant gtkspell description {Add gtkspell support} {
>> +    configure.args-delete   --disable-gtkspell
>> +    configure.args-append   --enable-gtkspell
>> +    depends_lib-append      port:gtkspell2
>> +}
>> +
>>
>>
>> Property changes on: trunk/dports/net/gajim/Portfile
>> ___________________________________________________________________
>> Name: svn:keywords
>>   + Id
>> Name: svn:eol-style
>>   + native
>>
>> Added: trunk/dports/net/gajim/files/patch-scripts-gajim- 
>> remote.in.diff
>> ===================================================================
>> --- trunk/dports/net/gajim/files/patch-scripts-gajim- 
>> remote.in.diff	                        (rev 0)
>> +++ trunk/dports/net/gajim/files/patch-scripts-gajim-remote.in.diff	 
>> 2008-08-18 08:05:13 UTC (rev 39320)
>> @@ -0,0 +1,11 @@
>> +--- scripts/gajim-remote.in.orig	2008-08-18 09:38:59.000000000 +0200
>> ++++ scripts/gajim-remote.in	2008-08-18 09:38:05.000000000 +0200
>> +@@ -29,7 +29,7 @@
>> + fi
>> +
>> + datadir=@DATADIR@
>> +-PYTHON_EXEC=@PYTHON@
>> ++PYTHON_EXEC=/opt/local/bin/python2.5
>> +
>> + cd ${datadir}/gajim/src
>> + export PYTHONPATH="$PYTHONPATH:@LIBDIR@/gajim"
>>
>> Added: trunk/dports/net/gajim/files/patch-scripts-gajim.in.diff
>> ===================================================================
>> --- trunk/dports/net/gajim/files/patch-scripts- 
>> gajim.in.diff	                        (rev 0)
>> +++ trunk/dports/net/gajim/files/patch-scripts-gajim.in.diff	 
>> 2008-08-18 08:05:13 UTC (rev 39320)
>> @@ -0,0 +1,11 @@
>> +--- scripts/gajim.in.orig	2008-08-17 18:10:06.000000000 +0200
>> ++++ scripts/gajim.in	2008-08-17 18:10:26.000000000 +0200
>> +@@ -28,7 +28,7 @@
>> + fi
>> +
>> + datadir=@DATADIR@
>> +-PYTHON_EXEC=@PYTHON@
>> ++PYTHON_EXEC=/opt/local/bin/python2.5
>> +
>> + cd ${datadir}/gajim/src
>> + export PYTHONPATH="$PYTHONPATH:@LIBDIR@/gajim"
>>
>> Added: trunk/dports/net/gajim/files/patch-src-Makefile.in.diff
>> ===================================================================
>> --- trunk/dports/net/gajim/files/patch-src- 
>> Makefile.in.diff	                        (rev 0)
>> +++ trunk/dports/net/gajim/files/patch-src-Makefile.in.diff	 
>> 2008-08-18 08:05:13 UTC (rev 39320)
>> @@ -0,0 +1,11 @@
>> +--- src/Makefile.in.orig	2008-08-18 08:57:14.000000000 +0200
>> ++++ src/Makefile.in	2008-08-18 08:57:53.000000000 +0200
>> +@@ -294,7 +294,7 @@
>> + 	trayicon.c
>> +
>> + INCLUDES = \
>> +-	$(PYTHON_INCLUDES)
>> ++	-I/opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
>> include/python2.5/
>> +
>> + @BUILD_GTKSPELL_TRUE at gtkspelllib_LTLIBRARIES = gtkspell.la
>> + @BUILD_GTKSPELL_TRUE at gtkspelllibdir = $(libdir)/gajim
>> _______________________________________________
>> macports-changes mailing list
>> macports-changes at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes


From wsiegrist at apple.com  Mon Aug 18 10:59:50 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Mon, 18 Aug 2008 10:59:50 -0700
Subject: Trac Upgrade Tuesday 8/19 7pm PDT
Message-ID: <1120C602-40A2-483C-B484-1D84F3C7846A@apple.com>

Several of you have been asking about Trac 0.11.1, so I just wanted to  
let you know it will happen tomorrow evening. There's also a new look/ 
feel for Mac OS Forge coming along with it; hopefully most will see it  
as an improvement. Due to this, Trac will be down for about 30m  
starting tomorrow at 7pm. I'll announce in IRC before and after.

If you'd like to read about the new version of Trac, see:

http://trac.edgewall.org/browser/tags/trac-0.11.1/RELEASE


Thanks
-Bill


----
William Siegrist
Mac OS Forge
http://macosforge.org/







-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2421 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080818/43381666/attachment.bin 

From seanasy at gmail.com  Mon Aug 18 14:02:11 2008
From: seanasy at gmail.com (Sean Fulton)
Date: Mon, 18 Aug 2008 17:02:11 -0400
Subject: [MacPorts] #16342: Build gdal with xercesc support for GML files
In-Reply-To: <059.52afe077a80e00593bee253294ec4d7e@macports.org>
References: <059.52afe077a80e00593bee253294ec4d7e@macports.org>
Message-ID: <420d14190808181402h41d1fa85kd5ee9de799bed285@mail.gmail.com>

Thanks. That looks fine to me. I'm out of town right now and away from
my Mac. Can you / have you submitted a patch?

 Sean

On Mon, Aug 18, 2008 at 4:47 PM, MacPorts <noreply at macports.org> wrote:
> #16342: Build gdal with xercesc support for GML files
> -------------------------------------+--------------------------------------
>  Reporter:  mbarchfe at googlemail.com  |       Owner:  macports-tickets at lists.macosforge.org
>     Type:  enhancement              |      Status:  new
>  Priority:  Normal                   |   Milestone:
> Component:  ports                    |     Version:  1.6.0
>  Keywords:                           |
> -------------------------------------+--------------------------------------
>  If you call ogrinfo --formats it will list GML, but if you actually try to
>  access a GML file, you will be surprised with the following error message:
>
>  ERROR 1: Unable to create Xerces C++ based GML reader, Xerces support
>  not configured into GDAL/OGR.
>
>  With the following simple variant GML files could be read:
>
>  variant xerces {
>         depends_lib-append              port:xercesc
>         configure.args-append   --with-xerces=${prefix}
>  }
>
> --
> Ticket URL: <http://trac.macports.org/ticket/16342>
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS
>

From wsiegrist at apple.com  Tue Aug 19 16:06:47 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Tue, 19 Aug 2008 16:06:47 -0700
Subject: Trac Upgrade Tuesday 8/19 7pm PDT
In-Reply-To: <1120C602-40A2-483C-B484-1D84F3C7846A@apple.com>
References: <1120C602-40A2-483C-B484-1D84F3C7846A@apple.com>
Message-ID: <EC6C8BAE-07DB-4F38-B765-9837B3A0DB51@apple.com>

This work has been postponed. I'll try to reschedule it for next week.

-Bill



On Aug 18, 2008, at 10:59 AM, William Siegrist wrote:

> Several of you have been asking about Trac 0.11.1, so I just wanted  
> to let you know it will happen tomorrow evening. There's also a new  
> look/feel for Mac OS Forge coming along with it; hopefully most will  
> see it as an improvement. Due to this, Trac will be down for about  
> 30m starting tomorrow at 7pm. I'll announce in IRC before and after.
>
> If you'd like to read about the new version of Trac, see:
>
> http://trac.edgewall.org/browser/tags/trac-0.11.1/RELEASE
>
>
> Thanks
> -Bill
>
>
> ----
> William Siegrist
> Mac OS Forge
> http://macosforge.org/
>
>
>
>
>
>
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev




----
William Siegrist
Mac OS Forge
http://macosforge.org/







-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2421 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080819/11cabd90/attachment.bin 

From ryandesign at macports.org  Tue Aug 19 20:42:25 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 19 Aug 2008 22:42:25 -0500
Subject: [39440] trunk/dports/sysutils
In-Reply-To: <20080820004325.3EF5A1FFEA9@beta.macosforge.org>
References: <20080820004325.3EF5A1FFEA9@beta.macosforge.org>
Message-ID: <9C400AE7-E735-4367-8070-28FADFED62CE@macports.org>

On Aug 19, 2008, at 19:43, ricci at macports.org wrote:

> Revision: 39440
>           http://trac.macosforge.org/projects/macports/changeset/39440
> Author:   ricci at macports.org
> Date:     2008-08-19 17:43:24 -0700 (Tue, 19 Aug 2008)
> Log Message:
> -----------
> New port - nut (Network UPS Tools)


> +set                 majorVer 2
> +set                 minorVer 2
> +set                 majorMinorVer ${majorVer}.${minorVer}
> +set                 revVer 2
> +version             ${majorVer}.${minorVer}.${revVer}


> +master_sites        http://www.networkupstools.org/source/$ 
> {majorMinorVer}


In several other ports, we have a slightly different way of handling  
this that enables the version variable to retain a readable version  
in the Portfile; see attached patch.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: nut.diff
Type: application/octet-stream
Size: 994 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080819/cde1a723/attachment.obj 

From yann+macports at daysofwonder.com  Wed Aug 20 13:38:32 2008
From: yann+macports at daysofwonder.com (Yann Corno)
Date: Wed, 20 Aug 2008 22:38:32 +0200
Subject: FreeType crasher: how to recompile ?
Message-ID: <48AC80C8.3000904@daysofwonder.com>

Hello everyone:

I am suffering from a crasher recently introduced in FreeType (or so it
seems). After a wild goose chase from Apache to PHP to GD2 to FreeType,
it boils down to a crash because Apache2 uses fork() without a
corresponding exec() and, upon calling PHP/GD/FreeType, the Carbon call
in FreeType causes Apache2 to crash. This is what is explained here:

http://90kts.com/blog/2008/installing-gd-libraries-for-leopard-apache-php-525/#comment-126

The next comment in the above link explains that FreeType should be
recompiled with a couple of options off: with-quickdraw-carbon and
with-quickdraw-toolbox

My question is: how do I do this in MacPort?

I tried to change the portfile like this:

configure.args \
     --with-old-mac-fonts \
     --with-fsspec=no --with-fsref=no --with-quickdraw-toolbox=no
--with-quickdraw-carbon=no

But it does not seem to make any difference. Heck, I am not even sure
that these options carry through down to the compiler. Sorry, I am such
a MacPort newbee...

Any advise on what I should do? Should I also rebuild gd2 and php5 after
that?

Thanks in advance for your insights,

Yann

PS: I am using Mac OS X 10.5.4 on a PowerPC G4 PowerBook machine, and
updated to the latest MacPorts builds.



From 0x62_0x6c_0x62 at pobox.com  Wed Aug 20 14:14:33 2008
From: 0x62_0x6c_0x62 at pobox.com (Bryan Blackburn)
Date: Wed, 20 Aug 2008 15:14:33 -0600
Subject: FreeType crasher: how to recompile ?
In-Reply-To: <48AC80C8.3000904@daysofwonder.com>
References: <48AC80C8.3000904@daysofwonder.com>
Message-ID: <B44BAB3A-B4CD-4F50-A648-B2BFE34EE67A@pobox.com>

On Aug 20, 2008, at 2:38 PM, Yann Corno wrote:

> Hello everyone:
>
> I am suffering from a crasher recently introduced in FreeType (or so  
> it
> seems). After a wild goose chase from Apache to PHP to GD2 to  
> FreeType,
> it boils down to a crash because Apache2 uses fork() without a
> corresponding exec() and, upon calling PHP/GD/FreeType, the Carbon  
> call
> in FreeType causes Apache2 to crash. This is what is explained here:
>
> http://90kts.com/blog/2008/installing-gd-libraries-for-leopard-apache-php-525/#comment-126
>
> The next comment in the above link explains that FreeType should be
> recompiled with a couple of options off: with-quickdraw-carbon and
> with-quickdraw-toolbox
>
> My question is: how do I do this in MacPort?
>
> I tried to change the portfile like this:
>
> configure.args \
>     --with-old-mac-fonts \
>     --with-fsspec=no --with-fsref=no --with-quickdraw-toolbox=no
> --with-quickdraw-carbon=no
>

That should be working as you expect, but I believe you also need to  
remove --with-old-mac-fonts to fully get around the CoreFoundation  
issue.  There's also a ticket covering this issue:

<http://trac.macports.org/ticket/15909>

Bryan


> But it does not seem to make any difference. Heck, I am not even sure
> that these options carry through down to the compiler. Sorry, I am  
> such
> a MacPort newbee...
>
> Any advise on what I should do? Should I also rebuild gd2 and php5  
> after
> that?
>
> Thanks in advance for your insights,
>
> Yann
>
> PS: I am using Mac OS X 10.5.4 on a PowerPC G4 PowerBook machine, and
> updated to the latest MacPorts builds.


From wsiegrist at apple.com  Wed Aug 20 17:09:45 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Wed, 20 Aug 2008 17:09:45 -0700
Subject: Trac Upgrade Tuesday 8/19 7pm PDT
In-Reply-To: <EC6C8BAE-07DB-4F38-B765-9837B3A0DB51@apple.com>
References: <1120C602-40A2-483C-B484-1D84F3C7846A@apple.com>
	<EC6C8BAE-07DB-4F38-B765-9837B3A0DB51@apple.com>
Message-ID: <DC2C26C1-28D3-47D7-8059-16585013347A@apple.com>

The Trac upgrade has been rescheduled for _next_ Tuesday, August 26th,  
7pm PDT.

Thanks
-Bill

On Aug 19, 2008, at 4:06 PM, William Siegrist wrote:

> This work has been postponed. I'll try to reschedule it for next week.
>
> -Bill
>
>
>
> On Aug 18, 2008, at 10:59 AM, William Siegrist wrote:
>
>> Several of you have been asking about Trac 0.11.1, so I just wanted  
>> to let you know it will happen tomorrow evening. There's also a new  
>> look/feel for Mac OS Forge coming along with it; hopefully most  
>> will see it as an improvement. Due to this, Trac will be down for  
>> about 30m starting tomorrow at 7pm. I'll announce in IRC before and  
>> after.
>>
>> If you'd like to read about the new version of Trac, see:
>>
>> http://trac.edgewall.org/browser/tags/trac-0.11.1/RELEASE
>>
>>
>> Thanks
>> -Bill
>>
>>
>> ----
>> William Siegrist
>> Mac OS Forge
>> http://macosforge.org/
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>
>
>
>
> ----
> William Siegrist
> Mac OS Forge
> http://macosforge.org/
>
>
>
>
>
>
>




----
William Siegrist
Mac OS Forge
http://macosforge.org/







-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2421 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080820/fdc4f07f/attachment.bin 

From ryandesign at macports.org  Wed Aug 20 21:58:30 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 20 Aug 2008 23:58:30 -0500
Subject: FreeType crasher: how to recompile ?
In-Reply-To: <B44BAB3A-B4CD-4F50-A648-B2BFE34EE67A@pobox.com>
References: <48AC80C8.3000904@daysofwonder.com>
	<B44BAB3A-B4CD-4F50-A648-B2BFE34EE67A@pobox.com>
Message-ID: <9047558A-0D8A-448B-9AE4-FE9500798A54@macports.org>


On Aug 20, 2008, at 16:14, Bryan Blackburn wrote:

> On Aug 20, 2008, at 2:38 PM, Yann Corno wrote:
>
>> I am suffering from a crasher recently introduced in FreeType (or so
>> it seems).

As I understand it, Apple has, in Leopard, now forbidden a  
programming practice that used to work, and is in use in the  
combination of apache / php / freetype. So, nothing was recently  
introduced in freetype to cause this problem; rather, the existence  
of Leopard causes this problem.

>> After a wild goose chase from Apache to PHP to GD2 to
>> FreeType, it boils down to a crash because Apache2 uses fork()  
>> without a
>> corresponding exec() and, upon calling PHP/GD/FreeType, the Carbon
>> call in FreeType causes Apache2 to crash. This is what is  
>> explained here:
>>
>> http://90kts.com/blog/2008/installing-gd-libraries-for-leopard- 
>> apache-php-525/#comment-126
>>
>> The next comment in the above link explains that FreeType should be
>> recompiled with a couple of options off: with-quickdraw-carbon and
>> with-quickdraw-toolbox
>>
>> My question is: how do I do this in MacPort?
>>
>> I tried to change the portfile like this:
>>
>> configure.args \
>>     --with-old-mac-fonts \
>>     --with-fsspec=no --with-fsref=no --with-quickdraw-toolbox=no
>> --with-quickdraw-carbon=no
>
> That should be working as you expect,

I would have thought so.

> but I believe you also need to
> remove --with-old-mac-fonts to fully get around the CoreFoundation
> issue.

I was hoping not, since I see the problem when using /System/Library/ 
Fonts/Arial.ttf on Leopard, which is not an "old Mac font" in that it  
is not a resource-fork-based font (though /System/Library/Fonts/Arial  
was a resource-fork-based font on Tiger).

> There's also a ticket covering this issue:
>
> <http://trac.macports.org/ticket/15909>

Right. I was working on testing that. I can reproduce the problem on  
Leopard. And then I had some peculiar and presumably unrelated  
problems with my php and so my testing was interrupted.



From yann+macports at daysofwonder.com  Thu Aug 21 00:21:58 2008
From: yann+macports at daysofwonder.com (Yann Corno)
Date: Thu, 21 Aug 2008 09:21:58 +0200
Subject: FreeType crasher: how to recompile ?
Message-ID: <48AD1796.8070405@daysofwonder.com>

Dear MacPorts people:

Following up on this, I finally found the solution. Maybe I was not 
recompiling properly FreeType, or maybe the little additional changes I 
made in the configure.args options made it work. Anyway, it works, so I 
am not going to touch it again ;-)

Here is the procedure:

* Uninstall Freetype:

sudo port uninstall -f freetype     # The -f option will force the 
un-install despite other packages dependencies


* Edit the portfile:

sudo port edit freetype
# In the editor, change the configure.args option like this:
configure.args \
     --with-old-mac-fonts=no \
     --with-quickdraw-toolbox=no --with-quickdraw-carbon=no


* Save the portfile, then re-install Freetype:

sudo port install freetype


If you have any comments, I'll be happy to hear them :-)

Thanks for your attention,

Yann


> Hello everyone:
> 
> I am suffering from a crasher recently introduced in FreeType (or so it
> seems). After a wild goose chase from Apache to PHP to GD2 to FreeType,
> it boils down to a crash because Apache2 uses fork() without a
> corresponding exec() and, upon calling PHP/GD/FreeType, the Carbon call
> in FreeType causes Apache2 to crash. This is what is explained here:
> 
> http://90kts.com/blog/2008/installing-gd-libraries-for-leopard-apache-php-525/#comment-126
> 
> The next comment in the above link explains that FreeType should be
> recompiled with a couple of options off: with-quickdraw-carbon and
> with-quickdraw-toolbox
> 
> My question is: how do I do this in MacPort?
> 
> I tried to change the portfile like this:
> 
> configure.args \
>     --with-old-mac-fonts \
>     --with-fsspec=no --with-fsref=no --with-quickdraw-toolbox=no
> --with-quickdraw-carbon=no
> 
> But it does not seem to make any difference. Heck, I am not even sure
> that these options carry through down to the compiler. Sorry, I am such
> a MacPort newbee...
> 
> Any advise on what I should do? Should I also rebuild gd2 and php5 after
> that?
> 
> Thanks in advance for your insights,
> 
> Yann
> 
> PS: I am using Mac OS X 10.5.4 on a PowerPC G4 PowerBook machine, and
> updated to the latest MacPorts builds.
> 
> 
> 

From ryandesign at macports.org  Thu Aug 21 00:54:16 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 21 Aug 2008 02:54:16 -0500
Subject: FreeType crasher: how to recompile ?
In-Reply-To: <48AD1796.8070405@daysofwonder.com>
References: <48AD1796.8070405@daysofwonder.com>
Message-ID: <BAFED45F-615F-44D4-93A5-E3394C042305@macports.org>

Did you find that disabling old Mac font support was really necessary  
to resolve this issue? I was hoping old Mac font support could be  
retained.


On Aug 21, 2008, at 02:21, Yann Corno wrote:

> Dear MacPorts people:
>
> Following up on this, I finally found the solution. Maybe I was not
> recompiling properly FreeType, or maybe the little additional  
> changes I
> made in the configure.args options made it work. Anyway, it works,  
> so I
> am not going to touch it again ;-)
>
> Here is the procedure:
>
> * Uninstall Freetype:
>
> sudo port uninstall -f freetype     # The -f option will force the
> un-install despite other packages dependencies
>
>
> * Edit the portfile:
>
> sudo port edit freetype
> # In the editor, change the configure.args option like this:
> configure.args \
>      --with-old-mac-fonts=no \
>      --with-quickdraw-toolbox=no --with-quickdraw-carbon=no
>
>
> * Save the portfile, then re-install Freetype:
>
> sudo port install freetype
>
>
> If you have any comments, I'll be happy to hear them :-)
>
> Thanks for your attention,
>
> Yann
>
>
>> Hello everyone:
>>
>> I am suffering from a crasher recently introduced in FreeType (or  
>> so it
>> seems). After a wild goose chase from Apache to PHP to GD2 to  
>> FreeType,
>> it boils down to a crash because Apache2 uses fork() without a
>> corresponding exec() and, upon calling PHP/GD/FreeType, the Carbon  
>> call
>> in FreeType causes Apache2 to crash. This is what is explained here:
>>
>> http://90kts.com/blog/2008/installing-gd-libraries-for-leopard- 
>> apache-php-525/#comment-126
>>
>> The next comment in the above link explains that FreeType should be
>> recompiled with a couple of options off: with-quickdraw-carbon and
>> with-quickdraw-toolbox
>>
>> My question is: how do I do this in MacPort?
>>
>> I tried to change the portfile like this:
>>
>> configure.args \
>>     --with-old-mac-fonts \
>>     --with-fsspec=no --with-fsref=no --with-quickdraw-toolbox=no
>> --with-quickdraw-carbon=no
>>
>> But it does not seem to make any difference. Heck, I am not even sure
>> that these options carry through down to the compiler. Sorry, I am  
>> such
>> a MacPort newbee...
>>
>> Any advise on what I should do? Should I also rebuild gd2 and php5  
>> after
>> that?
>>
>> Thanks in advance for your insights,
>>
>> Yann
>>
>> PS: I am using Mac OS X 10.5.4 on a PowerPC G4 PowerBook machine, and
>> updated to the latest MacPorts builds.



From yann+macports at daysofwonder.com  Thu Aug 21 01:24:18 2008
From: yann+macports at daysofwonder.com (Yann Corno)
Date: Thu, 21 Aug 2008 10:24:18 +0200
Subject: FreeType crasher: how to recompile ?
In-Reply-To: <BAFED45F-615F-44D4-93A5-E3394C042305@macports.org>
References: <48AD1796.8070405@daysofwonder.com>
	<BAFED45F-615F-44D4-93A5-E3394C042305@macports.org>
Message-ID: <48AD2632.8080001@daysofwonder.com>

I confirm that I need to disable old Mac font support 
(--with-old-mac-fonts=no). I just tried with the option back "on", and 
it fails again.

Sorry for the bad news,

Yann

Ryan Schmidt a ?crit :
> Did you find that disabling old Mac font support was really necessary to 
> resolve this issue? I was hoping old Mac font support could be retained.
> 
> 
> On Aug 21, 2008, at 02:21, Yann Corno wrote:
> 
>> Dear MacPorts people:
>>
>> Following up on this, I finally found the solution. Maybe I was not
>> recompiling properly FreeType, or maybe the little additional changes I
>> made in the configure.args options made it work. Anyway, it works, so I
>> am not going to touch it again ;-)
>>
>> Here is the procedure:
>>
>> * Uninstall Freetype:
>>
>> sudo port uninstall -f freetype     # The -f option will force the
>> un-install despite other packages dependencies
>>
>>
>> * Edit the portfile:
>>
>> sudo port edit freetype
>> # In the editor, change the configure.args option like this:
>> configure.args \
>>      --with-old-mac-fonts=no \
>>      --with-quickdraw-toolbox=no --with-quickdraw-carbon=no
>>
>>
>> * Save the portfile, then re-install Freetype:
>>
>> sudo port install freetype
>>
>>
>> If you have any comments, I'll be happy to hear them :-)
>>
>> Thanks for your attention,
>>
>> Yann
>>
>>

From ryandesign at macports.org  Thu Aug 21 10:48:18 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 21 Aug 2008 12:48:18 -0500
Subject: [39458] trunk/doc-new/guide/xml/installing.xml
In-Reply-To: <fc.004c4c581017b0b7004c4c581017b0b7.1017dd1f@biola.edu>
References: <fc.004c4c581017b0b7004c4c581017b0b7.1017dd1f@biola.edu>
Message-ID: <03C59C87-8A0E-4508-9063-F763DA645A09@macports.org>

On Aug 21, 2008, at 12:04, markd at macports.org wrote:

>> Date: Wed, 20 Aug 2008 12:56:20 -0700 (PDT)
>> From: ryandesign at macports.org
>> Subject: [39458] trunk/doc-new/guide/xml/installing.xml
>> To: macports-changes at lists.macosforge.org
>> Message-ID: <20080820195620.695922023D5 at beta.macosforge.org>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Revision: 39458
>>          http://trac.macosforge.org/projects/macports/changeset/39458
>> Author:   ryandesign at macports.org
>> Date:     2008-08-20 12:56:20 -0700 (Wed, 20 Aug 2008)
>> Log Message:
>> -----------
>> installing.xml: list the latest versions of Xcode
>>
>> Modified Paths:
>> --------------
>>    trunk/doc-new/guide/xml/installing.xml
>>
>> Modified: trunk/doc-new/guide/xml/installing.xml
>> ===================================================================
>> --- trunk/doc-new/guide/xml/installing.xml      2008-08-20  
>> 19:54:19 UTC
>> (rev 39457)
>> +++ trunk/doc-new/guide/xml/installing.xml      2008-08-20  
>> 19:56:20 UTC
>> (rev 39458)
>> @@ -110,7 +110,10 @@
>>         url="http://developer.apple.com/tools/xcode/">Xcode
>> Tools</ulink> from
>>         Apple's developer site?do not install it from a Mac OS X  
>> install
>> disk
>>         unless you've checked for the latest version on Apple's site;
>> older
>> -        versions of Xcode Tools often cause port install  
>> failures.</para>
>> +        versions of Xcode Tools often cause port install  
>> failures. The
>> latest
>> +        versions at the time of this writing are Xcode 3.1 for  
>> Mac OS X
>> 10.5
>> +        Leopard, Xcode 2.5 for Mac OS X 10.4 Tiger, and Xcode 1.5  
>> for
>> Mac OS X
>> +        10.3 Panther.</para>
>>       </listitem>
>
> Hi Ryan,
>
> Personally, I'd prefer directing users to the place where the  
> latest Xcode
> version is listed for the current OS (10.5) since it is a moving  
> target.
> Otherwise we fix the guide in time more than absolutely necessary and
> commit ourselves to updating the guide for Apple updates anywhere such
> references are made.   Also, saying "at the time of writing" seems  
> not to
> help since there isn't a way to know what time that is for that  
> particular
> text snippet, so it almost invites putting the date in parenthesis.
>
> I see that Apple's developer site now has a button named "Download  
> Latest
> Xcode"    http://developer.apple.com/tools/xcode/
>
> So I favor something like I pasted below.  I can't even find Xcode  
> 1.5 on
> Apple's site (though it must be there somewhere), and since we don't
> officially support 10.3 anymore I don't think anything needs to be  
> said on
> that.
>
> ---------------------
> Download and install the latest version of Xcode Tools by clicking the
> button "Download Latest Xcode" here:
> (http://developer.apple.com/tools/xcode/).  Do not install Xcode Tools
> from a Mac OS X install DVD unless you verify that you are  
> installing the
> latest version as listed on Apple's developer site; older versions  
> often
> cause port install failures.
>
> If you are installing MacPorts on Mac OS X 10.4, download and install
> Xcode 2.5
> (http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/ 
> getSoftware?bundleID=19907)
> ---------------------
>
> How does that seem?

I made the change specifically in response to a user who was confused  
when Xcode 2 did not work with Leopard, because he couldn't find a  
newer version on Apple's site:

http://lists.macosforge.org/pipermail/macports-users/2008-August/ 
011312.html

He went to ADC: Downloads: Mac OS X. The latest version I find there  
is 2.2.1.

Now, you and I know to go to ADC: Downloads: Developer Tools instead,  
which is where all versions of the Developer Tools (except Xcode 2.0)  
are located, going back to the December 2002 Developer Tools for  
Jaguar before it was even called Xcode. But if a user doesn't know  
that Xcode 2.2.1 isn't the latest, they won't go looking for a newer  
one.

I don't like the "Download Latest Xcode" button because it only gives  
you the latest Xcode for Leopard; it doesn't give you the latest  
Xcode for Tiger or Panther. I do want to continue supporting Panther  
as much as possible. I know we have at least one active Panther user  
on the list. I see no reason to cut off support for Panther at this  
time.

I agree "as of this writing" isn't good without a date, and that I  
shouldn't have created the situation where we have to update the  
Guide with "latest" information about Xcode releases, even if they  
are infrequent. Instead, how about we list a minimum Xcode version?  
The minimum supported Xcode version for MacPorts is 3.0 on Leopard,  
2.4 on Tiger and 1.5 on Panther, as seen in the MacPorts configure  
script:


case "$XCODE_VERSION" in
   1.[[0-1]]*|2.[[0-1]]*)
     AC_WARN(This version of Xcode Tools is not supported)
     AC_WARN(Please upgrade at http://connect.apple.com/)
     ;;
   1.[[2-4]]*|2.[[2-3]]*)
     AC_WARN(This version of Xcode Tools is out of date)
     AC_WARN(Please consider upgrading as some ports fail compiling)
     ;;
   1.5*|2.4*|3.*)
     dnl Supported version
     ;;
   *)
     ;;
esac


http://trac.macports.org/changeset/30338

http://trac.macports.org/changeset/30477


How about this text?


         <para>Install the latest version of Xcode Tools. The minimum  
versions
         which are supported for use with MacPorts are Xcode 3.0 on  
Mac OS X
         10.5 Leopard, Xcode 2.4 on Mac OS X 10.4 Tiger, and Xcode  
1.5 on
         Mac OS X 10.3 Panther. If your Mac OS X install disc has an  
earlier
         version of Xcode Tools, don't use it?older versions of Xcode  
Tools
         often cause port install failures. Instead, download the  
latest version
         from <ulink url="http://connect.apple.com/">Apple Developer
         Connection</ulink> &gt; Downloads &gt; Developer Tools.</para>




From ryandesign at macports.org  Thu Aug 21 11:16:29 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 21 Aug 2008 13:16:29 -0500
Subject: [39476] trunk/dports/net/wireshark/Portfile
In-Reply-To: <20080821175230.C654620623D@beta.macosforge.org>
References: <20080821175230.C654620623D@beta.macosforge.org>
Message-ID: <483EF4D7-E547-4EAC-BF94-D3891585F9BA@macports.org>

On Aug 21, 2008, at 12:52, ricci at macports.org wrote:

> Revision: 39476
>           http://trac.macosforge.org/projects/macports/changeset/39476
> Author:   ricci at macports.org
> Date:     2008-08-21 10:52:30 -0700 (Thu, 21 Aug 2008)
> Log Message:
> -----------
> Add support for RTP via portaudio.
> Resolves ticket #16361 (different solution used than what is in the  
> patch on the ticket)

Did you mean to undo r39474, r39475 and r39476?


> Modified Paths:
> --------------
>     trunk/dports/net/wireshark/Portfile
>
> Modified: trunk/dports/net/wireshark/Portfile
> ===================================================================
> --- trunk/dports/net/wireshark/Portfile	2008-08-21 17:43:30 UTC  
> (rev 39475)
> +++ trunk/dports/net/wireshark/Portfile	2008-08-21 17:52:30 UTC  
> (rev 39476)
> @@ -1,7 +1,6 @@
>  # $Id$
>
>  PortSystem 1.0
> -
>  name		wireshark
>  version		1.0.2
>  revision	0
> @@ -20,8 +19,8 @@
>  		http://www.wireshark.org/download/src/all-versions/
>
>  checksums	md5 77114890256222605a699d7123d86a7d \
> -		sha1 6d5736096efde3507a900942bfb21c492a42a057 \
> -		rmd160 bd42952c87c412b4395485cbaaf8698d26e03137
> +			sha1 6d5736096efde3507a900942bfb21c492a42a057 \
> +			rmd160 bd42952c87c412b4395485cbaaf8698d26e03137
>
>  use_bzip2	yes
>
> @@ -29,8 +28,7 @@
>  		port:gtk2 \
>  		port:openssl \
>  		port:libpcap \
> -		port:zlib \
> -		port:portaudio
> +		port:zlib
>
>  configure.args	--enable-gtk2 \
>  		--with-net-snmp=no --with-ucd-snmp=no \
> @@ -67,45 +65,50 @@
>  	configure.env-append	MACOSX_DEPLOYMENT_TARGET=10.5
>  }
>
> -variant adns description {Use Asynchronous DNS} {
> +variant adns {
>  	configure.args-append	--with-adns=${prefix}
>  	configure.args-delete	--without-adns
>  	depends_lib-append	port:adns
>  }
>
> -variant gnutls description {Use GNUTLS} {
> +variant gnutls {
>  	configure.args-append	--with-libgnutls-prefix=${prefix}
>  	depends_lib-append	port:gnutls
>  }
>
> -variant libgcrypt description {Use gcrypt} {
> +variant libgcrypt {
>  	configure.args-append	--with-libgcrypt-prefix=${prefix}
>  	depends_lib-append	port:libgcrypt
>  }
>
> -variant ipv6 description {Enable IPv6 Support} {
> +variant ipv6 {
>  	configure.args-append	--enable-ipv6
>  	configure.args-delete	--disable-ipv6
>  }
>
> -variant net_snmp description {Use Net-SNMP} {
> +variant net_snmp {
>  	configure.args-append	--with-net-snmp=${prefix}/bin/net-snmp-config
>  	configure.args-delete	--with-net-snmp=no
>  	depends_lib-append	port:net-snmp
>  }
>
> -variant pcre description {Use PCRE} {
> +variant pcre {
>  	configure.args-append	--with-pcre=${prefix}
>  	configure.args-delete	--without-pcre
>  	depends_lib-append	lib:libpcre:pcre
>  }
>
> -variant no_ssl description {Disable SSL Support} {
> +variant rtp description {add rtp support with portaudio} {
> +	configure.args-append   --with-portaudio=${prefix}
> +	depends_lib-append      port:portaudio
> +}
> +
> +variant no_ssl {
>  	configure.args-append --without-ssl
>  	depends_lib-delete	port:openssl
>  }
>
> -variant no_x11	description {Disable X11 Support} {
> +variant no_x11	{
>  	depends_lib-delete	port:gtk2
>  	configure.args-delete	--disable-gtk2
>  	configure.args-append	--disable-wireshark



From opendarwin.org at darkart.com  Thu Aug 21 12:19:33 2008
From: opendarwin.org at darkart.com (Eric Hall)
Date: Thu, 21 Aug 2008 19:19:33 +0000
Subject: [39476] trunk/dports/net/wireshark/Portfile
In-Reply-To: <483EF4D7-E547-4EAC-BF94-D3891585F9BA@macports.org>
References: <20080821175230.C654620623D@beta.macosforge.org>
	<483EF4D7-E547-4EAC-BF94-D3891585F9BA@macports.org>
Message-ID: <20080821191933.GA56231@darkart.com>

On Thu, Aug 21, 2008 at 01:16:29PM -0500, Ryan Schmidt wrote:
> On Aug 21, 2008, at 12:52, ricci at macports.org wrote:
> 
> >Revision: 39476
> >          http://trac.macosforge.org/projects/macports/changeset/39476
> >Author:   ricci at macports.org
> >Date:     2008-08-21 10:52:30 -0700 (Thu, 21 Aug 2008)
> >Log Message:
> >-----------
> >Add support for RTP via portaudio.
> >Resolves ticket #16361 (different solution used than what is in the  
> >patch on the ticket)
> 
> Did you mean to undo r39474, r39475 and r39476?
> 
> 

	Yes, r39476 undoes the changes in r39474 ("better" solution
for the request in ticket #16361) and in r39475 (non-maintainer
changes, made while maintainer was testing the change done in
r39476).  There's a note in ticket #16361 about it.



		-eric


From ryandesign at macports.org  Thu Aug 21 14:20:31 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 21 Aug 2008 16:20:31 -0500
Subject: [MacPorts] Notification: LeopardProblems modified
In-Reply-To: <079.f9d1308ecb353849c1d5b9f805097064@macports.org>
References: <070.afa7732be8d2c59631bbf09f611c626a@macports.org>
	<079.f9d1308ecb353849c1d5b9f805097064@macports.org>
Message-ID: <99093C31-0E0E-4383-A578-5544AC5179E0@macports.org>

I removed the changes you made to the LeopardProblems page on the  
MacPorts Wiki.

Please file tickets for bugs you encounter, or discuss them on the  
macports-users mailing list, rather than edit our FAQ documents. Thanks.


On Aug 21, 2008, at 16:01, MacPorts wrote:

> Changed page "LeopardProblems" by edwastrodowski at yahoo.com from  
> 67.155.224.242*
> Page URL: <http://trac.macports.org/wiki/LeopardProblems>
> Diff URL: <http://trac.macports.org/wiki/LeopardProblems? 
> action=diff&version=11>
> Revision 11
>
> -------8<------8<------8<------8<------8<------8<------8<------8<----- 
> ---
> Index: LeopardProblems
> ====================================================================== 
> ===
> --- LeopardProblems (version: 10)
> +++ LeopardProblems (version: 11)
> @@ -8,6 +8,31 @@
>  Here is [http://lists.macosforge.org/pipermail/macports-users/2008- 
> April/009991.html an analysis of the problem] by Bryan Blackburn.
>
>  This should be fixed on trunk (r36719, r36722, r39016, r39017) but  
> the fix isn't part of MacPorts 1.6.0. It will be in the next  
> version of MacPorts.
> +
> +(I have a similar problem doing sudo port install seamonkey on  
> 10.5.4 on an
> +iBook(ppc).  So I edited the above mentioned files as indicated  
> and did
> +cd  /opt/local/var/macports/sources/rsync.macports.org/release/base
> +sudo ./configure
> +sudo make all
> +sudo make install
> +and it didn't help..
> +
> +to wit:
> +--->  Building seamonkey with target all
> +Error: Target org.macports.build returned: shell command " cd "/ 
> opt/local/var/macports/build/ 
> _opt_local_var_macports_sources_rsync.macports.org_release_ports_www_s 
> eamonkey/work/mozilla" && make all " returned error 2
> +Command output: o host_include. -c  -DINCLUDEDIR=\"/usr/include\" - 
> DOBJSUFFIX=\".\"   -I/include/mkdepend -I/include  -I/sdk/include  / 
> opt/local/var/macports/build/ 
> _opt_local_var_macports_sources_rsync.macports.org_release_ports_www_s 
> eamonkey/work/mozilla/config/mkdepend/include.c
> +make[3]: o: Command not found
> +make[3]: [host_include.] Error 127 (ignored)
> +.... etc ending in..
> +make[2]: *** [export] Error 127
> +make[1]: *** [export] Error 2
> +make: *** [all] Error 2
> +
> +Error: Status 1 encountered during processing.
> +
> +
> +I notice that there is a [3] after the make,  at the time of the  
> first error, so
> +it seems to be an environment variable setting problem of some kind)
>
>  == `ld: cycle in dylib re-exports with /usr/X11/lib/libGL.dylib` ==
>  This is the result of a misfeature in Leopard's linker. See  
> Apple's Technical Q&A on the subject [http://developer.apple.com/qa/ 
> qa2007/qa1567.html here]. It can generally be fixed by adding the  
> following to the portfile inside a `platform darwin 9` block:
>
> -------8<------8<------8<------8<------8<------8<------8<------8<----- 
> ---
>
>
> * The IP shown here might not mean anything if the user is behind a  
> proxy.
>
> --
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS
>
> This is an automated message. Someone at http://www.macports.org/
> added your email address to be notified of changes on MacPorts.
> If it was not you, please report to http://www.macports.org/.
> _______________________________________________
> macports-changes mailing list
> macports-changes at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes


From markd at macports.org  Thu Aug 21 19:00:51 2008
From: markd at macports.org (markd at macports.org)
Date: Thu, 21 Aug 2008 19:00:51 -0700
Subject: [39458] trunk/doc-new/guide/xml/installing.xml
Message-ID: <fc.004c4c581017f93d004c4c581017f93d.1018c8ff@biola.edu>


>> Hi Ryan,
>>
>> Personally, I'd prefer directing users to the place where the
>> latest Xcode
>> version is listed for the current OS (10.5) since it is a moving
>> target.
>> Otherwise we fix the guide in time more than absolutely necessary and
>> commit ourselves to updating the guide for Apple updates anywhere such
>> references are made.   Also, saying "at the time of writing" seems
>> not to
>> help since there isn't a way to know what time that is for that
>> particular
>> text snippet, so it almost invites putting the date in parenthesis.
>>
>> I see that Apple's developer site now has a button named "Download
>> Latest
>> Xcode"    [ http://developer.apple.com/tools/xcode/
>]http://developer.apple.com/tools/xcode/
>>
>> So I favor something like I pasted below.  I can't even find Xcode
>> 1.5 on
>> Apple's site (though it must be there somewhere), and since we don't
>> officially support 10.3 anymore I don't think anything needs to be
>> said on
>> that.
>>
>> ---------------------
>> Download and install the latest version of Xcode Tools by clicking the
>> button "Download Latest Xcode" here:
>> ([ http://developer.apple.com/tools/xcode/)
>]http://developer.apple.com/tools/xcode/).  Do not install Xcode Tools
>> from a Mac OS X install DVD unless you verify that you are
>> installing the
>> latest version as listed on Apple's developer site; older versions
>> often
>> cause port install failures.
>>
>> If you are installing MacPorts on Mac OS X 10.4, download and install
>> Xcode 2.5
>> ([ http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/
>]http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/
>> getSoftware?bundleID=19907)
>> ---------------------
>>
>> How does that seem?
>
>I made the change specifically in response to a user who was confused
>when Xcode 2 did not work with Leopard, because he couldn't find a
>newer version on Apple's site:
>
>[ http://lists.macosforge.org/pipermail/macports-users/2008-August/
>]http://lists.macosforge.org/pipermail/macports-users/2008-August/
>011312.html
>
>He went to ADC: Downloads: Mac OS X. The latest version I find there
>is 2.2.1.

But he wasn't led astray by the Guide.  The Guide can and needs to be
improved, but doesn't necessarily help to modify guide text to try to
solve a specific problem that arose because a user ignored that very Guide
text, especially when the text that was in front of the user's face
(Apple's) before they clicked download were ignored.  Here is Apple's text
at that link.

----------
Xcode Tools 2.2.1:
Xcode 2.2.1 is an update for the Mac OS X v10.4 Xcode Tools suite.
Please see the Read Me document for more details and installation
instructions.
-----------

What needs to be fixed is Apple's ADC site, but nowhere I know of in the
Guide do we point users there.
>
>Now, you and I know to go to ADC: Downloads: Developer Tools instead,
>which is where all versions of the Developer Tools (except Xcode 2.0)
>are located, going back to the December 2002 Developer Tools for
>Jaguar before it was even called Xcode. But if a user doesn't know
>that Xcode 2.2.1 isn't the latest, they won't go looking for a newer
>one.
>
>I don't like the "Download Latest Xcode" button because it only gives
>you the latest Xcode for Leopard; it doesn't give you the latest
>Xcode for Tiger or Panther.

Giving the link to the "latest Xcode" for 10.5 was only one part of my
suggestion:

------------------
Download and install the latest version of Xcode Tools by clicking the
button "Download Latest Xcode" here:
(http://developer.apple.com/tools/xcode/).  Do not install Xcode Tools
from a Mac OS X install DVD unless you verify that you are installing the
latest version as listed on Apple's developer site; older versions often
cause port install failures.

If you are installing MacPorts on Mac OS X 10.4, download and install
Xcode 2.5
(http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=19907)
-------------------

The suggested text does tell you where to find Xcode 2.5 for 10.4, which
the current instructions do not, and finding it isn't as easy as it seems.
 Telling someone what they need and showing them where it are different
things.  Do to the magic of hyperlinking, we can do both at once and I
think this is a slight improvement.

>I do want to continue supporting Panther
>as much as possible. I know we have at least one active Panther user
>on the list. I see no reason to cut off support for Panther at this
>time.

Nobody is "cutting off" anything.  The support is what it is.  It is a
question of what is recommended.  I would not like to give the impression
that we provide better support that we actually do, and support for 10.3
is pretty darn weak.   We all know that we aren't prepared to do much to
actively support 10.3, so how long will it be before in response to a MP
developer's suggestion that (at the very least) it is wise to avoid 10.3
if possible that we hear: "But on page 1 at the top of the Guide it states
requirements for 10.3 (implying it is supported), and now you're telling
me it isn't supported?"  And we do say that, and I think we've had this
discussion many times before.

But look, I know I'm acting as a self-appointed documentation Nazi, and
probably  coming off as too argumentative, but the truth is I think there
are unstated assumptions at work in discussions about the Guide.  I think
failure to observe a certain rules ruins a document over time, and that
disagreement on those implicit assumptions is the source of most of the
disagreements on MP docs.  I have several in mind:

1) One I'm always pushing is basically the 80/20 rule (or 95/5 or
insert_your_own_numbers here).  We have a mailing list, and it will always
be used and needed, and a wiki.  Some questions are best answered by the
list, and trying to answer certain questions that fall in the 20% in the
Guide will destroy it over time.  The Guide is an attempt to document
certain things, not everything.  A document can't be all thing to all
people.

2) No duplication of text unless absolutely necessary.  This is a
volunteer project and we must minimize the effort required for
documentation, or it will seem futile to have good documents in a
reasonable length of a volunteer's time.  Soon, in a future release, the
man pages will be sourced oet of the Guide and this is a big step in
having accurate and maintainable documents.

3) Minimalism is good, because people only have so much time to read. 
Everything that can be said shouldn't be.  All text needs to support the
main purpose of the document.

I think probably we should hash out this stuff as a community, and I'm
always willing to submit this sort of thing to a vote.  I think a certain
ruthless adherence to these principals will get us a better Guide in the
end since comprehensive documentation is difficult and none of us get paid
for this.  I can look at almost any part of the Guide and think "That
could be a lot better", but I think when trying to do so I think there
should be overall consideration of the document design principles.  BTW, I
do intend to start in on the unfinished sections of the Guide very soon,
and also address the tickets on it.  Hopefully in a matter of weeks.
>
>I agree "as of this writing" isn't good without a date, and that I
>shouldn't have created the situation where we have to update the
>Guide with "latest" information about Xcode releases, even if they
>are infrequent. Instead, how about we list a minimum Xcode version?
>The minimum supported Xcode version for MacPorts is 3.0 on Leopard,
>2.4 on Tiger and 1.5 on Panther, as seen in the MacPorts configure
>script:
>
>
>case "$XCODE_VERSION" in
>   1.[[0-1]]*|2.[[0-1]]*)
>     AC_WARN(This version of Xcode Tools is not supported)
>     AC_WARN(Please upgrade at [ http://connect.apple.com/
>]http://connect.apple.com/)
>     ;;
>   1.[[2-4]]*|2.[[2-3]]*)
>     AC_WARN(This version of Xcode Tools is out of date)
>     AC_WARN(Please consider upgrading as some ports fail compiling)
>     ;;
>   1.5*|2.4*|3.*)
>     dnl Supported version
>     ;;
>   *)
>     ;;
>esac 

I prefer to let the scripts do their job and warn the user appropriately
without duplicating the script messages in the documentation.  Principal
#2.  :)

Please don't take me as being rude or argumentative.  I just have a vision
for the docs I'd like to argue for and to put forth some working
assumptions that I've always used for the Guide.  I think discussing these
issues as a community is a good thing.

Cheers,

Mark


From ryandesign at macports.org  Thu Aug 21 19:57:28 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 21 Aug 2008 21:57:28 -0500
Subject: [39458] trunk/doc-new/guide/xml/installing.xml
In-Reply-To: <fc.004c4c581017f93d004c4c581017f93d.1018c8ff@biola.edu>
References: <fc.004c4c581017f93d004c4c581017f93d.1018c8ff@biola.edu>
Message-ID: <A1064517-F03F-40D6-A395-6224B4BFEB4D@macports.org>


On Aug 21, 2008, at 21:00, markd at macports.org wrote:

>>> Personally, I'd prefer directing users to the place where the
>>> latest Xcode
>>> version is listed for the current OS (10.5) since it is a moving
>>> target.
>>> Otherwise we fix the guide in time more than absolutely necessary  
>>> and
>>> commit ourselves to updating the guide for Apple updates anywhere  
>>> such
>>> references are made.   Also, saying "at the time of writing" seems
>>> not to
>>> help since there isn't a way to know what time that is for that
>>> particular
>>> text snippet, so it almost invites putting the date in parenthesis.
>>>
>>> I see that Apple's developer site now has a button named "Download
>>> Latest
>>> Xcode"    [ http://developer.apple.com/tools/xcode/
>> ]http://developer.apple.com/tools/xcode/
>>>
>>> So I favor something like I pasted below.  I can't even find Xcode
>>> 1.5 on
>>> Apple's site (though it must be there somewhere), and since we don't
>>> officially support 10.3 anymore I don't think anything needs to be
>>> said on
>>> that.
>>>
>>> ---------------------
>>> Download and install the latest version of Xcode Tools by  
>>> clicking the
>>> button "Download Latest Xcode" here:
>>> ([ http://developer.apple.com/tools/xcode/)
>> ]http://developer.apple.com/tools/xcode/).  Do not install Xcode  
>> Tools
>>> from a Mac OS X install DVD unless you verify that you are
>>> installing the
>>> latest version as listed on Apple's developer site; older versions
>>> often
>>> cause port install failures.
>>>
>>> If you are installing MacPorts on Mac OS X 10.4, download and  
>>> install
>>> Xcode 2.5
>>> ([ http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/
>> ]http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/
>>> getSoftware?bundleID=19907)
>>> ---------------------
>>>
>>> How does that seem?
>>
>> I made the change specifically in response to a user who was confused
>> when Xcode 2 did not work with Leopard, because he couldn't find a
>> newer version on Apple's site:
>>
>> [ http://lists.macosforge.org/pipermail/macports-users/2008-August/
>> ]http://lists.macosforge.org/pipermail/macports-users/2008-August/
>> 011312.html
>>
>> He went to ADC: Downloads: Mac OS X. The latest version I find there
>> is 2.2.1.
>
> But he wasn't led astray by the Guide.  The Guide can and needs to be
> improved, but doesn't necessarily help to modify guide text to try to
> solve a specific problem that arose because a user ignored that  
> very Guide
> text, especially when the text that was in front of the user's face
> (Apple's) before they clicked download were ignored.  Here is  
> Apple's text
> at that link.
>
> ----------
> Xcode Tools 2.2.1:
> Xcode 2.2.1 is an update for the Mac OS X v10.4 Xcode Tools suite.
> Please see the Read Me document for more details and installation
> instructions.
> -----------
>
> What needs to be fixed is Apple's ADC site, but nowhere I know of  
> in the
> Guide do we point users there.
>>
>> Now, you and I know to go to ADC: Downloads: Developer Tools instead,
>> which is where all versions of the Developer Tools (except Xcode 2.0)
>> are located, going back to the December 2002 Developer Tools for
>> Jaguar before it was even called Xcode. But if a user doesn't know
>> that Xcode 2.2.1 isn't the latest, they won't go looking for a newer
>> one.
>>
>> I don't like the "Download Latest Xcode" button because it only gives
>> you the latest Xcode for Leopard; it doesn't give you the latest
>> Xcode for Tiger or Panther.
>
> Giving the link to the "latest Xcode" for 10.5 was only one part of my
> suggestion:
>
> ------------------
> Download and install the latest version of Xcode Tools by clicking the
> button "Download Latest Xcode" here:
> (http://developer.apple.com/tools/xcode/).  Do not install Xcode Tools
> from a Mac OS X install DVD unless you verify that you are  
> installing the
> latest version as listed on Apple's developer site; older versions  
> often
> cause port install failures.
>
> If you are installing MacPorts on Mac OS X 10.4, download and install
> Xcode 2.5
> (http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/ 
> getSoftware?bundleID=19907)
> -------------------
>
> The suggested text does tell you where to find Xcode 2.5 for 10.4,  
> which
> the current instructions do not, and finding it isn't as easy as it  
> seems.
>  Telling someone what they need and showing them where it are  
> different
> things.  Do to the magic of hyperlinking, we can do both at once and I
> think this is a slight improvement.
>
>> I do want to continue supporting Panther
>> as much as possible. I know we have at least one active Panther user
>> on the list. I see no reason to cut off support for Panther at this
>> time.
>
> Nobody is "cutting off" anything.  The support is what it is.  It is a
> question of what is recommended.  I would not like to give the  
> impression
> that we provide better support that we actually do, and support for  
> 10.3
> is pretty darn weak.   We all know that we aren't prepared to do  
> much to
> actively support 10.3

I think most of my ports work on Panther. If they don't, I'll gladly  
take bug reports.

> so how long will it be before in response to a MP
> developer's suggestion that (at the very least) it is wise to avoid  
> 10.3
> if possible that we hear: "But on page 1 at the top of the Guide it  
> states
> requirements for 10.3 (implying it is supported), and now you're  
> telling
> me it isn't supported?"  And we do say that, and I think we've had  
> this
> discussion many times before.

Then we should state on page 1 that support for Panther and non-Mac  
OSes is not guaranteed. It is official MacPorts policy that only the  
latest two Mac OS X releases are supported [1] so we should state  
this in the Guide.

[1] http://lists.macosforge.org/pipermail/macports-dev/2008-June/ 
005393.html


Note: The Guide already contains examples of "darwin 7" platform  
statements, which could also be construed to mean that Panther is  
supported.


I do think it is a good idea to list the requirements of MacPorts in  
the Guide, and certain versions of Xcode are required. This came up  
before, and it was decided that we would gladly trade user time for  
developer time -- better to have the user spend time downloading a  
new Xcode than to have a developer spend time to figure out that a  
user's problem was caused by an old Xcode. We are not in control of  
Apple's web sites, but we are in control of the Guide, hence it is  
useful to list there the minimum versions of Xcode that should be used.


I don't like your link to download Xcode 2.5 directly for the same  
reason you didn't like me stating that Xcode 2.5 is the latest  
version for Tiger -- what if it changes? I think it's better to teach  
the user to fish: show them where Xcode releases are posted and let  
them find the latest version.


> But look, I know I'm acting as a self-appointed documentation Nazi,  
> and
> probably  coming off as too argumentative,

No worries -- I'm glad someone feels responsible for guiding the Guide!


> but the truth is I think there
> are unstated assumptions at work in discussions about the Guide.  I  
> think
> failure to observe a certain rules ruins a document over time, and  
> that
> disagreement on those implicit assumptions is the source of most of  
> the
> disagreements on MP docs.  I have several in mind:
>
> 1) One I'm always pushing is basically the 80/20 rule (or 95/5 or
> insert_your_own_numbers here).  We have a mailing list, and it will  
> always
> be used and needed, and a wiki.  Some questions are best answered  
> by the
> list, and trying to answer certain questions that fall in the 20%  
> in the
> Guide will destroy it over time.  The Guide is an attempt to document
> certain things, not everything.  A document can't be all thing to all
> people.

I believe the Guide should document everything you need to know about  
using MacPorts. I would not include information about how to use any  
specific port, and I wouldn't include ProblemHotlist-type stuff which  
is really just descriptions of bugs which will be fixed.


> 2) No duplication of text unless absolutely necessary.  This is a
> volunteer project and we must minimize the effort required for
> documentation, or it will seem futile to have good documents in a
> reasonable length of a volunteer's time.  Soon, in a future  
> release, the
> man pages will be sourced oet of the Guide and this is a big step in
> having accurate and maintainable documents.

Before manpages can be sourced out of the Guide, the information  
currently in the manpages needs to be put into the Guide... :)

Also, I pointed out recently how much duplication of text we already  
have, which is captured here:

http://www.macports.org/docs.php


> 3) Minimalism is good, because people only have so much time to read.
> Everything that can be said shouldn't be.  All text needs to  
> support the
> main purpose of the document.

That's true.


> I think probably we should hash out this stuff as a community, and I'm
> always willing to submit this sort of thing to a vote.  I think a  
> certain
> ruthless adherence to these principals will get us a better Guide  
> in the
> end since comprehensive documentation is difficult and none of us  
> get paid
> for this.  I can look at almost any part of the Guide and think "That
> could be a lot better", but I think when trying to do so I think there
> should be overall consideration of the document design principles.   
> BTW, I
> do intend to start in on the unfinished sections of the Guide very  
> soon,
> and also address the tickets on it.  Hopefully in a matter of weeks.

Are the document design principles documented somewhere? :)


>> I agree "as of this writing" isn't good without a date, and that I
>> shouldn't have created the situation where we have to update the
>> Guide with "latest" information about Xcode releases, even if they
>> are infrequent. Instead, how about we list a minimum Xcode version?
>> The minimum supported Xcode version for MacPorts is 3.0 on Leopard,
>> 2.4 on Tiger and 1.5 on Panther, as seen in the MacPorts configure
>> script:
>>
>>
>> case "$XCODE_VERSION" in
>>   1.[[0-1]]*|2.[[0-1]]*)
>>     AC_WARN(This version of Xcode Tools is not supported)
>>     AC_WARN(Please upgrade at [ http://connect.apple.com/
>> ]http://connect.apple.com/)
>>     ;;
>>   1.[[2-4]]*|2.[[2-3]]*)
>>     AC_WARN(This version of Xcode Tools is out of date)
>>     AC_WARN(Please consider upgrading as some ports fail compiling)
>>     ;;
>>   1.5*|2.4*|3.*)
>>     dnl Supported version
>>     ;;
>>   *)
>>     ;;
>> esac
>
> I prefer to let the scripts do their job and warn the user  
> appropriately
> without duplicating the script messages in the documentation.   
> Principal
> #2.  :)

The problem is that the script in which this is implemented is the  
configure script, which is not a script a user will encounter if  
installing MacPorts the usual way, from a dmg. Getting MacPorts to  
check the Xcode version during normal use is an as yet outstanding  
ticket.

http://trac.macports.org/ticket/12794



> Please don't take me as being rude or argumentative.  I just have a  
> vision
> for the docs I'd like to argue for and to put forth some working
> assumptions that I've always used for the Guide.  I think  
> discussing these
> issues as a community is a good thing.

Agreed!


From afb at macports.org  Thu Aug 21 23:45:01 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Fri, 22 Aug 2008 08:45:01 +0200
Subject: [39458] trunk/doc-new/guide/xml/installing.xml
In-Reply-To: <A1064517-F03F-40D6-A395-6224B4BFEB4D@macports.org>
References: <fc.004c4c581017f93d004c4c581017f93d.1018c8ff@biola.edu>
	<A1064517-F03F-40D6-A395-6224B4BFEB4D@macports.org>
Message-ID: <8748D09B-C8AF-4EB5-9CFD-06F57FA56D59@macports.org>

Ryan Schmidt wrote:

>>> I agree "as of this writing" isn't good without a date, and that I
>>> shouldn't have created the situation where we have to update the
>>> Guide with "latest" information about Xcode releases, even if they
>>> are infrequent. Instead, how about we list a minimum Xcode version?
>>> The minimum supported Xcode version for MacPorts is 3.0 on Leopard,
>>> 2.4 on Tiger and 1.5 on Panther, as seen in the MacPorts configure
>>> script:
...
>> I prefer to let the scripts do their job and warn the user
>> appropriately
>> without duplicating the script messages in the documentation.
>> Principal
>> #2.  :)
>
> The problem is that the script in which this is implemented is the
> configure script, which is not a script a user will encounter if
> installing MacPorts the usual way, from a dmg. Getting MacPorts to
> check the Xcode version during normal use is an as yet outstanding
> ticket.
>
> http://trac.macports.org/ticket/12794

I suggested to use "selfupdate" to run the same version check
on Mac OS X and Xcode as configure does ? (and check the oil)
Doing it on every port operation would make it even slower
than what it is today, which doesn't sound very exciting...

This is part of a bigger problem that most of the messages
in MacPorts cater to developers only, and this along with
the need to install Developer Tools and build from source
instead of installing binaries makes the "threshold" higher.

--anders


From adambyrtek at gmail.com  Fri Aug 22 01:21:33 2008
From: adambyrtek at gmail.com (Adam Byrtek)
Date: Fri, 22 Aug 2008 10:21:33 +0200
Subject: [PATCH] Inheritance of macports.conf configuration files
Message-ID: <670d23ff0808220121g1ebe7680of841f988dfc5fc28@mail.gmail.com>

I've made a tweak in handling of macports.conf configuration file, now
the global file defines defaults and user configuration can just
override parts of it. More information can be found in this thread on
macports-users:
http://lists.macosforge.org/pipermail/macports-users/2008-August/011273.html

The actual patch is available here:
http://trac.macports.org/ticket/16329

A similar problem had been raised on this list a year ago, bus as far
as I know didn't result in a patch:
http://lists.macosforge.org/pipermail/macports-dev/2007-April/001373.html

I'm looking forward for reviewing and applying the patch if you find it valid.

Best regards,
Adam Byrtek

From ryandesign at macports.org  Fri Aug 22 01:38:40 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 22 Aug 2008 03:38:40 -0500
Subject: [39495] trunk/dports/office/taskjuggler/Portfile
In-Reply-To: <20080822081801.32F29208C46@beta.macosforge.org>
References: <20080822081801.32F29208C46@beta.macosforge.org>
Message-ID: <2CA16221-95AC-4D4A-A5E1-1F8D70FDAA5D@macports.org>

On Aug 22, 2008, at 03:18, rene at macports.org wrote:

> Revision: 39495
>           http://trac.macosforge.org/projects/macports/changeset/39495
> Author:   rene at macports.org
> Date:     2008-08-22 01:18:00 -0700 (Fri, 22 Aug 2008)
> Log Message:
> -----------
> office/taskjuggler: Modify variant descriptions to match  
> prescriptions.

[snip]

> -variant arts description {compile with arts support} {
> +variant arts description {Disable arts support} {

Surely it *enables* arts support?

From ryandesign at macports.org  Mon Aug 25 09:40:56 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 25 Aug 2008 11:40:56 -0500
Subject: [39526] trunk/dports/net/gajim-devel/Portfile
In-Reply-To: <20080823004650.ADF3320C878@beta.macosforge.org>
References: <20080823004650.ADF3320C878@beta.macosforge.org>
Message-ID: <2436301A-1E49-448E-BBEA-1EF07B0584DC@macports.org>

On Aug 22, 2008, at 19:46, rene at macports.org wrote:

> Revision: 39526
>           http://trac.macosforge.org/projects/macports/changeset/39526
> Author:   rene at macports.org
> Date:     2008-08-22 17:46:50 -0700 (Fri, 22 Aug 2008)
> Log Message:
> -----------
> net/gajim-devel: Fix typo.
>
> Modified Paths:
> --------------
>     trunk/dports/net/gajim-devel/Portfile
>
> Modified: trunk/dports/net/gajim-devel/Portfile
> ===================================================================
> --- trunk/dports/net/gajim-devel/Portfile	2008-08-23 00:39:00 UTC  
> (rev 39525)
> +++ trunk/dports/net/gajim-devel/Portfile	2008-08-23 00:46:50 UTC  
> (rev 39526)
> @@ -75,10 +75,10 @@
>      xinstall -d ${destroot}/Applications/MacPorts
>      file rename ${worksrcpath}/dist/Gajim.app \
>          ${destroot}/Applications/MacPorts/
> -    ui_msg  
> "*********************************************************"
> -    ui_msg "***  Gajim has been installed to /Application/MacPort   
> **"
> -    ui_msg "***     Double click Gajim.app to start using it.       
> **"
> -    ui_msg  
> "*********************************************************"
> +    ui_msg "********************************************************"
> +    ui_msg "*** Gajim has been installed to /Application/MacPorts **"
> +    ui_msg "***     Double click Gajim.app to start using it.     **"
> +    ui_msg "********************************************************"

You fixed one typo (MacPort => MacPorts) but left another  
(Application => Applications). However the best way to fix this is to  
add support for the ${applications_dir} variable at this time, which  
MacPorts 1.7.0 users will be able to configure in their  
macports.conf. Patch attached.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gajim-devel.diff
Type: application/octet-stream
Size: 1071 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080825/2fa01fcf/attachment.obj 

From ryandesign at macports.org  Mon Aug 25 09:59:11 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 25 Aug 2008 11:59:11 -0500
Subject: [39535] tags/release_1_6_0/base/src/port1.0/portconfigure.tcl
In-Reply-To: <20080823084854.BC44520DA1E@beta.macosforge.org>
References: <20080823084854.BC44520DA1E@beta.macosforge.org>
Message-ID: <18A15F38-21DE-4326-97BF-55B6CB5FE0F9@macports.org>

On Aug 23, 2008, at 03:48, raimue at macports.org wrote:

> Revision: 39535
>           http://trac.macosforge.org/projects/macports/changeset/39535
> Author:   raimue at macports.org
> Date:     2008-08-23 01:48:52 -0700 (Sat, 23 Aug 2008)
> Log Message:
> -----------
> port1.0/portconfigure.tcl:
> Return an error if an invalid value was given to configure.compiler
>
> Modified Paths:
> --------------
>     tags/release_1_6_0/base/src/port1.0/portconfigure.tcl
>
> Modified: tags/release_1_6_0/base/src/port1.0/portconfigure.tcl
> ===================================================================
> --- tags/release_1_6_0/base/src/port1.0/portconfigure.tcl	 
> 2008-08-23 08:15:08 UTC (rev 39534)
> +++ tags/release_1_6_0/base/src/port1.0/portconfigure.tcl	 
> 2008-08-23 08:48:52 UTC (rev 39535)
> @@ -246,7 +246,7 @@
>                  f77 ${prefix}/bin/gfortran-mp-4.3 \
>                  f90 ${prefix}/bin/gfortran-mp-4.3 }
>          default {
> -            ui_debug "No compiler collection selected explicitly" }
> +            return -code error "Invalid value for  
> configure.compiler" }
>      }

You made this change to the 1.6.0 release tag. Did you mean to make  
it in trunk instead?


From raimue at macports.org  Mon Aug 25 10:19:01 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Mon, 25 Aug 2008 19:19:01 +0200
Subject: [39535] tags/release_1_6_0/base/src/port1.0/portconfigure.tcl
In-Reply-To: <18A15F38-21DE-4326-97BF-55B6CB5FE0F9@macports.org>
References: <20080823084854.BC44520DA1E@beta.macosforge.org>
	<18A15F38-21DE-4326-97BF-55B6CB5FE0F9@macports.org>
Message-ID: <48B2E985.1010806@macports.org>

Ryan Schmidt wrote:
> On Aug 23, 2008, at 03:48, raimue at macports.org wrote:
> 
>> Revision: 39535
>>           http://trac.macosforge.org/projects/macports/changeset/39535
>> Author:   raimue at macports.org
>> Date:     2008-08-23 01:48:52 -0700 (Sat, 23 Aug 2008)
>> Log Message:
>> -----------
>> port1.0/portconfigure.tcl:
>> Return an error if an invalid value was given to configure.compiler
>>
>> Modified Paths:
>> --------------
>>     tags/release_1_6_0/base/src/port1.0/portconfigure.tcl
>>
>> Modified: tags/release_1_6_0/base/src/port1.0/portconfigure.tcl
>> ===================================================================
>> --- tags/release_1_6_0/base/src/port1.0/portconfigure.tcl	 
>> 2008-08-23 08:15:08 UTC (rev 39534)
>> +++ tags/release_1_6_0/base/src/port1.0/portconfigure.tcl	 
>> 2008-08-23 08:48:52 UTC (rev 39535)
>> @@ -246,7 +246,7 @@
>>                  f77 ${prefix}/bin/gfortran-mp-4.3 \
>>                  f90 ${prefix}/bin/gfortran-mp-4.3 }
>>          default {
>> -            ui_debug "No compiler collection selected explicitly" }
>> +            return -code error "Invalid value for  
>> configure.compiler" }
>>      }
> 
> You made this change to the 1.6.0 release tag. Did you mean to make  
> it in trunk instead?

Sorry, of course I wanted to do that in trunk! Seems like I was in the
wrong working copy.

Reverted in r39572, re-made the change to trunk in r39573.

Rainer

From markd at macports.org  Mon Aug 25 19:08:39 2008
From: markd at macports.org (markd at macports.org)
Date: Mon, 25 Aug 2008 19:08:39 -0700
Subject: Guide - was ... trunk/doc-new/guide/xml/installing.xml
Message-ID: <fc.004c4c581019e1f1004c4c581019e1f1.101f40a2@biola.edu>

>I think most of my ports work on Panther. If they don't, I'll gladly
>take bug reports.
>
>> so how long will it be before in response to a MP
>> developer's suggestion that (at the very least) it is wise to avoid
>> 10.3
>> if possible that we hear: "But on page 1 at the top of the Guide it
>> states
>> requirements for 10.3 (implying it is supported), and now you're
>> telling
>> me it isn't supported?"  And we do say that, and I think we've had
>> this
>> discussion many times before.
>
>Then we should state on page 1 that support for Panther and non-Mac
>OSes is not guaranteed. It is official MacPorts policy that only the
>latest two Mac OS X releases are supported [1] so we should state
>this in the Guide.

For OS X that is not a problem, but what should we say for other
platforms?  If we can agree on something it would be nice to state it.
>
>[1] http://lists.macosforge.org/pipermail/macports-dev/2008-June/
>005393.html
>
>
>Note: The Guide already contains examples of "darwin 7" platform
>statements, which could also be construed to mean that Panther is
>supported.

That seems a stretch.  I think removing all reference info to 10.3 (and
then I suppose the Portfile keywords too?) would amount to "cutting off"
support, which seems draconian.
>
>
>I do think it is a good idea to list the requirements of MacPorts in
>the Guide, and certain versions of Xcode are required. This came up
>before, and it was decided that we would gladly trade user time for
>developer time -- better to have the user spend time downloading a
>new Xcode than to have a developer spend time to figure out that a
>user's problem was caused by an old Xcode.

Agreed.  But you're claiming you've solved the problem by listing version
numbers in the Guide and I say you haven't, and there are other problems
raised by this method as well .....

>We are not in control of
>Apple's web sites, but we are in control of the Guide, hence it is
>useful to list there the minimum versions of Xcode that should be used.

....  for example here.  I don't want to give users a reason not to go to
Apple's download sites, because there can be important information there. 
For example, by going to Apple's site as part of this thread I learned
important details about what is in Xcode 3.1 that I didn't know, and that
Apple supports installing Xcode 2.5 on 10.5.  I don't want people looking
at potentially dated information in the Guide (there is no way to avoid
this when updates occur) and Googling for the outdated version listed in
the guide.
>
>I don't like your link to download Xcode 2.5 directly for the same
>reason you didn't like me stating that Xcode 2.5 is the latest
>version for Tiger -- what if it changes? I think it's better to teach
>the user to fish: show them where Xcode releases are posted and let
>them find the latest version.
>
I don't like it that well either but I thought that was a concession to
you, and frankly I'm lost now because I think you've taken my view now not
to list version numbers unless absolutely necessary.  I thought it a
reasonable concession since I'm more concerned that the current OS Xcode
version not be listed since that version will change soon and frequently,
than with a previous OS (Xcode version) that won't, and might not at all.
>
>> But look, I know I'm acting as a self-appointed documentation Nazi,
>> and
>> probably  coming off as too argumentative,
>
>No worries -- I'm glad someone feels responsible for guiding the Guide!
>
>
>> but the truth is I think there
>> are unstated assumptions at work in discussions about the Guide.  I
>> think
>> failure to observe a certain rules ruins a document over time, and
>> that
>> disagreement on those implicit assumptions is the source of most of
>> the
>> disagreements on MP docs.  I have several in mind:
>>
>> 1) One I'm always pushing is basically the 80/20 rule (or 95/5 or
>> insert_your_own_numbers here).  We have a mailing list, and it will
>> always
>> be used and needed, and a wiki.  Some questions are best answered
>> by the
>> list, and trying to answer certain questions that fall in the 20%
>> in the
>> Guide will destroy it over time.  The Guide is an attempt to document
>> certain things, not everything.  A document can't be all thing to all
>> people.
>
>I believe the Guide should document everything you need to know about
>using MacPorts. I would not include information about how to use any
>specific port, and I wouldn't include ProblemHotlist-type stuff which
>is really just descriptions of bugs which will be fixed.
>
And if wishes were horses, beggars would ride.  "Document everything you
need to know" is an impossible goal.  If this were really true, we'd shut
down the mailing list.  It is a meaningless statement in practical terms. 
"Make the Guide as good as we can make it" is better, and may not include
certain things you might want to know if the Guide is not the best medium
to deliver those things.
>
>> 2) No duplication of text unless absolutely necessary.  This is a
>> volunteer project and we must minimize the effort required for
>> documentation, or it will seem futile to have good documents in a
>> reasonable length of a volunteer's time.  Soon, in a future
>> release, the
>> man pages will be sourced oet of the Guide and this is a big step in
>> having accurate and maintainable documents.
>
>Before manpages can be sourced out of the Guide, the information
>currently in the manpages needs to be put into the Guide... :)

The reference section of the guide contains the manpage sources. 
http://guide.macports.org/#reference

Important parts are still missing, but completion is not far as far off as
you think.  The reason it  takes so long is that I am re-writing it, and
I'm trying to make it accurate as I go.  If you think the current manpages
are accurate, compare the Guide section on startupitems with the manpages
on that topic.
>
>Also, I pointed out recently how much duplication of text we already
>have, which is captured here:
>
>http://www.macports.org/docs.php

Yes, I know that.  This needs to be fixed, not perpetuated as a model.
>
>
>> 3) Minimalism is good, because people only have so much time to read.
>> Everything that can be said shouldn't be.  All text needs to
>> support the
>> main purpose of the document.
>
>That's true.
>
>
>> I think probably we should hash out this stuff as a community, and I'm
>> always willing to submit this sort of thing to a vote.  I think a
>> certain
>> ruthless adherence to these principals will get us a better Guide
>> in the
>> end since comprehensive documentation is difficult and none of us
>> get paid
>> for this.  I can look at almost any part of the Guide and think "That
>> could be a lot better", but I think when trying to do so I think there
>> should be overall consideration of the document design principles.
>> BTW, I
>> do intend to start in on the unfinished sections of the Guide very
>> soon,
>> and also address the tickets on it.  Hopefully in a matter of weeks.
>
>Are the document design principles documented somewhere? :)
>
No, but I thought the last email could be a starting point so I'm saving
that info as a start at least.
>
>>> I agree "as of this writing" isn't good without a date, and that I
>>> shouldn't have created the situation where we have to update the
>>> Guide with "latest" information about Xcode releases, even if they
>>> are infrequent. Instead, how about we list a minimum Xcode version?
>>> The minimum supported Xcode version for MacPorts is 3.0 on Leopard,
>>> 2.4 on Tiger and 1.5 on Panther, as seen in the MacPorts configure
>>> script:
>>>
>>>
>>> case "$XCODE_VERSION" in
>>>   1.[[0-1]]*|2.[[0-1]]*)
>>>     AC_WARN(This version of Xcode Tools is not supported)
>>>     AC_WARN(Please upgrade at [ http://connect.apple.com/
>>> ]http://connect.apple.com/)
>>>     ;;
>>>   1.[[2-4]]*|2.[[2-3]]*)
>>>     AC_WARN(This version of Xcode Tools is out of date)
>>>     AC_WARN(Please consider upgrading as some ports fail compiling)
>>>     ;;
>>>   1.5*|2.4*|3.*)
>>>     dnl Supported version
>>>     ;;
>>>   *)
>>>     ;;
>>> esac
>>
>> I prefer to let the scripts do their job and warn the user
>> appropriately
>> without duplicating the script messages in the documentation.
>> Principal
>> #2.  :)
>
>The problem is that the script in which this is implemented is the
>configure script, which is not a script a user will encounter if
>installing MacPorts the usual way, from a dmg. Getting MacPorts to
>check the Xcode version during normal use is an as yet outstanding
>ticket.
>
>http://trac.macports.org/ticket/12794
>
I see.  Well maybe there should be a principle #4, that transitory
information in the guide should be limited, and if a bug or incomplete
feature that would solve user issues isn't a top priority for the base
developers, then maybe it isn't for the doc team either and the mailing
list may need to suffice.  ;-)
>
>
Mark


From wsiegrist at apple.com  Wed Aug 27 11:28:35 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Wed, 27 Aug 2008 11:28:35 -0700
Subject: Block pre-Subversion 1.5 clients
In-Reply-To: <488E6A9D.9070706@macports.org>
References: <0E3E31AF-061E-4F7D-AFE6-30FB7F1C1842@macports.org>
	<792B6BD0-2A78-4208-8E9C-AE3C34A661CC@apple.com>
	<D69295BF-362E-48EF-B289-49B71ECAADA9@macports.org>
	<81B71504-FFAB-40E7-B975-16A74338FACB@apple.com>
	<AB3A6274-52DC-4B97-B1F2-A695CA3B56F1@macports.org>
	<488E6A9D.9070706@macports.org>
Message-ID: <F968A275-3916-4F0E-BF47-A02E5171DEAE@apple.com>

On Jul 28, 2008, at 5:55 PM, Rainer M?ller wrote:

> Ryan Schmidt wrote:
>>> If v1.5 will help a lot of people, they should speak up so I can   
>>> gauge the priority of the upgrade.
>> I think we should start using Subversion 1.5's merge tracking   
>> (instead of svnmerge.py) on the 1.7 branch, when that's created.
>
> Can we switch to the new merge tracking in the 1.7 branch and still  
> use svnmerge.py on the older branches or would we need to convert  
> this information?
>

By the way, the server is now running Subversion 1.5, so you can start  
using the new merge tracking whenever you'd like.

-Bill




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2421 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080827/dd6a65c4/attachment.bin 

From florian.ebeling at gmail.com  Wed Aug 27 11:55:11 2008
From: florian.ebeling at gmail.com (Caspar Florian Ebeling)
Date: Wed, 27 Aug 2008 20:55:11 +0200
Subject: Fwd: openvpn2: "Cannot allocate TUN/TAP dev dynamically"
In-Reply-To: <48B4FCCB.9030907@macports.org>
References: <5cbbe4ae0808261416u3f46c8adka7d4f8bae199c551@mail.gmail.com>
	<48B4FCCB.9030907@macports.org>
Message-ID: <5cbbe4ae0808271155n1def0a6fs63bf7301014de235@mail.gmail.com>

---------- Forwarded message ----------
From: Pierre Queinnec <pmq at macports.org>
Date: Wed, Aug 27, 2008 at 9:05 AM
Subject: Re: openvpn2: "Cannot allocate TUN/TAP dev dynamically"
To: MacPorts Users <macports-users at lists.macosforge.org>

Caspar Florian Ebeling wrote:
> Is anyone using openvpn2 sucessfully? After all that I was able
> to google up, there is an additional driver necessary for /dev/tun
> or tap, which is said to be included in Tunnelblick, a Cocoa UI
> over openvpn.
The tun/tap modules are available at: http://tuntaposx.sourceforge.net

This might be an interesting candidate for a new port. I feel a bit
out of my depth here, though, installing kexts and all. Also the Makefile
has to convinced about a few things like PREFIX. Anyone?

If we have it, it should probably be integrated with openvpn/openvpn2
to make that usable as a client. (Or is it needed for server side as well?)

Florian





-- 
Florian Ebeling
florian.ebeling at gmail.com

From erickt at macports.org  Wed Aug 27 22:16:35 2008
From: erickt at macports.org (Erick Tryzelaar)
Date: Wed, 27 Aug 2008 22:16:35 -0700
Subject: how do I specify a specific framework version on OS X?
Message-ID: <1ef034530808272216g6ef1ce59ke0b68ef191b67778@mail.gmail.com>

I'm trying to get py25-sip to link properly on my leopard machine.
Since leopard comes with 2.5.1, I run into version conflicts trying to
use macports python 2.5.2. Since I can't rely on python_select
python25 being set, I need to figure out how to do this without it
being set. As a consequence of this, the current version symlinks in
${prefix}/Library/Frameworks/Python.framework are not set up. So, when
I specify:

-F {prefix}/Library/Frameworks -framework Python

It's just using apple's version of python. Is there any way around
this? I've tried using "-current_version 2.5 -compatibility_version
2.5.2" but sip builds a bundle and they apparently don't support
setting the version using this technique. Anyone know of a better way
to do this?

From usx303 at googlemail.com  Thu Aug 28 01:36:59 2008
From: usx303 at googlemail.com (Uwe Schwartz)
Date: Thu, 28 Aug 2008 10:36:59 +0200
Subject: openvpn2: "Cannot allocate TUN/TAP dev dynamically"
In-Reply-To: <5cbbe4ae0808271155n1def0a6fs63bf7301014de235@mail.gmail.com>
References: <5cbbe4ae0808261416u3f46c8adka7d4f8bae199c551@mail.gmail.com>
	<48B4FCCB.9030907@macports.org>
	<5cbbe4ae0808271155n1def0a6fs63bf7301014de235@mail.gmail.com>
Message-ID: <fdb095270808280136h3cebdf0ey40ca348f58d087e7@mail.gmail.com>

Hi,

I would also like to see TUN/TAP drivers in MacPorts.
After a quick look on the Makefile in the git repository the Portfile should
contain:

use_configure    no
(because there is no configure)

I'm not sure where to put the kext files. If we put it in the usual
/Library/Extensions folder we need:

destroot.args    BASE=${destroot}
(the Makefile uses BASE instead of DESTDIR)

This would cause a mtree violation. Thus we need:
destroot.violate_mtree    yes

The next issues are the StartupItems. The Makefile provides an own way to
create the items, but we could also use MacPorts StartupItems.

At the end I would suggest to not include the drivers in openvpn port,
because there are also other tools which use TUN/TAP.

Regards,

Uwe





On Wed, Aug 27, 2008 at 8:55 PM, Caspar Florian Ebeling <
florian.ebeling at gmail.com> wrote:

> ---------- Forwarded message ----------
> From: Pierre Queinnec <pmq at macports.org>
> Date: Wed, Aug 27, 2008 at 9:05 AM
> Subject: Re: openvpn2: "Cannot allocate TUN/TAP dev dynamically"
> To: MacPorts Users <macports-users at lists.macosforge.org>
>
> Caspar Florian Ebeling wrote:
> > Is anyone using openvpn2 sucessfully? After all that I was able
> > to google up, there is an additional driver necessary for /dev/tun
> > or tap, which is said to be included in Tunnelblick, a Cocoa UI
> > over openvpn.
> The tun/tap modules are available at: http://tuntaposx.sourceforge.net
>
> This might be an interesting candidate for a new port. I feel a bit
> out of my depth here, though, installing kexts and all. Also the Makefile
> has to convinced about a few things like PREFIX. Anyone?
>
> If we have it, it should probably be integrated with openvpn/openvpn2
> to make that usable as a client. (Or is it needed for server side as well?)
>
> Florian
>
>
>
>
>
> --
> Florian Ebeling
> florian.ebeling at gmail.com
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080828/afc75fea/attachment.html 

From florian.ebeling at gmail.com  Thu Aug 28 04:51:49 2008
From: florian.ebeling at gmail.com (Caspar Florian Ebeling)
Date: Thu, 28 Aug 2008 13:51:49 +0200
Subject: openvpn2: "Cannot allocate TUN/TAP dev dynamically"
In-Reply-To: <fdb095270808280136h3cebdf0ey40ca348f58d087e7@mail.gmail.com>
References: <5cbbe4ae0808261416u3f46c8adka7d4f8bae199c551@mail.gmail.com>
	<48B4FCCB.9030907@macports.org>
	<5cbbe4ae0808271155n1def0a6fs63bf7301014de235@mail.gmail.com>
	<fdb095270808280136h3cebdf0ey40ca348f58d087e7@mail.gmail.com>
Message-ID: <5cbbe4ae0808280451n30d5c233rb82cc53b4d9f10bd@mail.gmail.com>

> I would also like to see TUN/TAP drivers in MacPorts.
> After a quick look on the Makefile in the git repository the Portfile should
> contain:
>
> use_configure    no
> (because there is no configure)
>
> I'm not sure where to put the kext files. If we put it in the usual
> /Library/Extensions folder we need:
>
> destroot.args    BASE=${destroot}
> (the Makefile uses BASE instead of DESTDIR)

I would think ${destroot}${prefix} might be even better,
so that things end up in /opt/local/Library/Extensions.
I tried it and loading/unloading seems to work nicely.
So the location doesn't seem to matter if you load kexts
explicitly.

> This would cause a mtree violation. Thus we need:
> destroot.violate_mtree    yes
>
> The next issues are the StartupItems. The Makefile provides an own way to
> create the items, but we could also use MacPorts StartupItems.

The problem with MacPorts StartupItems is that they look very
server-centric to me, and we only need to trigger load and unload
of the Kext. But that with su privileges. There is no pid to watch
e.g.

So one way of dealing with this would be to provide an oldfashioned
script. But where to put that. I would be tempted to put it into
/opt/local/init.d/,
but there is nothing yet.

Otherwise my Portfile is working. Maybe we just leave that part out for
now and add a README.MacPorts, which explains:

kextload KEXT_PATH # to load and get /dev/tap*
kextunload KEXT_PATH # to unload and remove /dev/tap*

> At the end I would suggest to not include the drivers in openvpn port,
> because there are also other tools which use TUN/TAP.

no, I agree, but there might be a dependency. Maybe only via a
variant, but I think plain/full dependency would be arguable as well.



-- 
Florian Ebeling
florian.ebeling at gmail.com

From usx303 at googlemail.com  Thu Aug 28 08:14:57 2008
From: usx303 at googlemail.com (Uwe Schwartz)
Date: Thu, 28 Aug 2008 17:14:57 +0200
Subject: openvpn2: "Cannot allocate TUN/TAP dev dynamically"
In-Reply-To: <5cbbe4ae0808280451n30d5c233rb82cc53b4d9f10bd@mail.gmail.com>
References: <5cbbe4ae0808261416u3f46c8adka7d4f8bae199c551@mail.gmail.com>
	<48B4FCCB.9030907@macports.org>
	<5cbbe4ae0808271155n1def0a6fs63bf7301014de235@mail.gmail.com>
	<fdb095270808280136h3cebdf0ey40ca348f58d087e7@mail.gmail.com>
	<5cbbe4ae0808280451n30d5c233rb82cc53b4d9f10bd@mail.gmail.com>
Message-ID: <fdb095270808280814g6c73ef57id3b8b9fbc63784cc@mail.gmail.com>

On Thu, Aug 28, 2008 at 1:51 PM, Caspar Florian Ebeling <
florian.ebeling at gmail.com> wrote:

> > I would also like to see TUN/TAP drivers in MacPorts.
> > After a quick look on the Makefile in the git repository the Portfile
> should
> > contain:
> >
> > use_configure    no
> > (because there is no configure)
> >
> > I'm not sure where to put the kext files. If we put it in the usual
> > /Library/Extensions folder we need:
> >
> > destroot.args    BASE=${destroot}
> > (the Makefile uses BASE instead of DESTDIR)
>
> I would think ${destroot}${prefix} might be even better,
> so that things end up in /opt/local/Library/Extensions.
> I tried it and loading/unloading seems to work nicely.
> So the location doesn't seem to matter if you load kexts
> explicitly.
>
> > This would cause a mtree violation. Thus we need:
> > destroot.violate_mtree    yes
> >
> > The next issues are the StartupItems. The Makefile provides an own way to
> > create the items, but we could also use MacPorts StartupItems.
>
> The problem with MacPorts StartupItems is that they look very
> server-centric to me, and we only need to trigger load and unload
> of the Kext. But that with su privileges. There is no pid to watch
> e.g.
>
> So one way of dealing with this would be to provide an oldfashioned
> script. But where to put that. I would be tempted to put it into
> /opt/local/init.d/,
> but there is nothing yet.


Well, I'm not an experienced Ports developer, so I don't know what's the
rigth way. But I don't like the idea to create a new method to start things.
A Script StartupItem would do the same. (5.7.3 in the guide). The
StartupItems from the original package provide already some scripts and the
PID issue could be solved by setting "startupitem.pidfile" to "none"


> Otherwise my Portfile is working. Maybe we just leave that part out for
> now and add a README.MacPorts, which explains:
>
> kextload KEXT_PATH # to load and get /dev/tap*
> kextunload KEXT_PATH # to unload and remove /dev/tap*
>
> > At the end I would suggest to not include the drivers in openvpn port,
> > because there are also other tools which use TUN/TAP.
>
> no, I agree, but there might be a dependency. Maybe only via a
> variant, but I think plain/full dependency would be arguable as well


Another problem could be a conflict with an already installed Kext (maybe
the legacy TUN/TAP driver or Tunnelblick).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080828/715c8d7f/attachment.html 

From florian.ebeling at gmail.com  Thu Aug 28 08:58:05 2008
From: florian.ebeling at gmail.com (Caspar Florian Ebeling)
Date: Thu, 28 Aug 2008 17:58:05 +0200
Subject: openvpn2: "Cannot allocate TUN/TAP dev dynamically"
In-Reply-To: <fdb095270808280814g6c73ef57id3b8b9fbc63784cc@mail.gmail.com>
References: <5cbbe4ae0808261416u3f46c8adka7d4f8bae199c551@mail.gmail.com>
	<48B4FCCB.9030907@macports.org>
	<5cbbe4ae0808271155n1def0a6fs63bf7301014de235@mail.gmail.com>
	<fdb095270808280136h3cebdf0ey40ca348f58d087e7@mail.gmail.com>
	<5cbbe4ae0808280451n30d5c233rb82cc53b4d9f10bd@mail.gmail.com>
	<fdb095270808280814g6c73ef57id3b8b9fbc63784cc@mail.gmail.com>
Message-ID: <5cbbe4ae0808280858u65549aaanfffc25b6eb122ccf@mail.gmail.com>

>> So one way of dealing with this would be to provide an oldfashioned
>> script. But where to put that. I would be tempted to put it into
>> /opt/local/init.d/,
>> but there is nothing yet.
>
> Well, I'm not an experienced Ports developer, so I don't know what's the
> rigth way. But I don't like the idea to create a new method to start things.
> A Script StartupItem would do the same. (5.7.3 in the guide). The
> StartupItems from the original package provide already some scripts and the
> PID issue could be solved by setting "startupitem.pidfile" to "none"

yeah you could probably hack it, but the guide is quite clear here:

  A StartupItem is a MacPorts facility to run "daemons,"
  a Unix term for programs that run   continuously in the
  background, rather than under the direct control of a user;"

I would not like to duplicate code either, obviously, but also not
violate things. It is true though, IIRC, that StartupItems are meant
to do more than managing daemons. But I don't know if MP startupitem
facilities have stricter assumptions. And this above sounds much
like it. Or the guide author was actually a bit too restrictive
in his description and nothing is wrong with your approach.
I don't know.

The only other port that mentions "kext" is macfuse,
according to rgrep. And that contains a Framework, and
I would imagine that places the kext into a well-known
place and takes care of everything. And least it has
no special means to start it.

> Another problem could be a conflict with an already installed Kext (maybe
> the legacy TUN/TAP driver or Tunnelblick).

MacPorts does not overwrite files but rather fails before doing so.
And then you just have to know how you manually configured your
system.

What is the "legacy TUN/TAP" btw?

Florian



-- 
Florian Ebeling
florian.ebeling at gmail.com

From landonf at macports.org  Thu Aug 28 18:44:07 2008
From: landonf at macports.org (Landon Fuller)
Date: Thu, 28 Aug 2008 18:44:07 -0700
Subject: openvpn2: "Cannot allocate TUN/TAP dev dynamically"
In-Reply-To: <5cbbe4ae0808280858u65549aaanfffc25b6eb122ccf@mail.gmail.com>
References: <5cbbe4ae0808261416u3f46c8adka7d4f8bae199c551@mail.gmail.com>
	<48B4FCCB.9030907@macports.org>
	<5cbbe4ae0808271155n1def0a6fs63bf7301014de235@mail.gmail.com>
	<fdb095270808280136h3cebdf0ey40ca348f58d087e7@mail.gmail.com>
	<5cbbe4ae0808280451n30d5c233rb82cc53b4d9f10bd@mail.gmail.com>
	<fdb095270808280814g6c73ef57id3b8b9fbc63784cc@mail.gmail.com>
	<5cbbe4ae0808280858u65549aaanfffc25b6eb122ccf@mail.gmail.com>
Message-ID: <DF397B6F-37D4-4C5A-97D1-F88467CDD6EE@macports.org>


On Aug 28, 2008, at 8:58 AM, Caspar Florian Ebeling wrote:

>>
>> Another problem could be a conflict with an already installed Kext  
>> (maybe
>> the legacy TUN/TAP driver or Tunnelblick).
>
> MacPorts does not overwrite files but rather fails before doing so.
> And then you just have to know how you manually configured your
> system.

MacPorts shouldn't be installing files into a directory it doesn't  
control, however -- that was the thinking behind /Applications/MacPorts/

-landonf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080828/4080cc0a/attachment.bin 

From landonf at macports.org  Thu Aug 28 18:44:43 2008
From: landonf at macports.org (Landon Fuller)
Date: Thu, 28 Aug 2008 18:44:43 -0700
Subject: openvpn2: "Cannot allocate TUN/TAP dev dynamically"
In-Reply-To: <fdb095270808280136h3cebdf0ey40ca348f58d087e7@mail.gmail.com>
References: <5cbbe4ae0808261416u3f46c8adka7d4f8bae199c551@mail.gmail.com>
	<48B4FCCB.9030907@macports.org>
	<5cbbe4ae0808271155n1def0a6fs63bf7301014de235@mail.gmail.com>
	<fdb095270808280136h3cebdf0ey40ca348f58d087e7@mail.gmail.com>
Message-ID: <BCF7385C-8916-448A-B1C7-82FD83E6A2FD@macports.org>


On Aug 28, 2008, at 1:36 AM, Uwe Schwartz wrote:

> At the end I would suggest to not include the drivers in openvpn  
> port, because there are also other tools which use TUN/TAP.

+1
I use openvpn2 but have externally installed tun/tap drivers, and the  
kexts would conflict.

-landonf


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080828/94c2e916/attachment.bin 

From usx303 at googlemail.com  Fri Aug 29 01:12:12 2008
From: usx303 at googlemail.com (Uwe Schwartz)
Date: Fri, 29 Aug 2008 10:12:12 +0200
Subject: openvpn2: "Cannot allocate TUN/TAP dev dynamically"
In-Reply-To: <5cbbe4ae0808280858u65549aaanfffc25b6eb122ccf@mail.gmail.com>
References: <5cbbe4ae0808261416u3f46c8adka7d4f8bae199c551@mail.gmail.com>
	<48B4FCCB.9030907@macports.org>
	<5cbbe4ae0808271155n1def0a6fs63bf7301014de235@mail.gmail.com>
	<fdb095270808280136h3cebdf0ey40ca348f58d087e7@mail.gmail.com>
	<5cbbe4ae0808280451n30d5c233rb82cc53b4d9f10bd@mail.gmail.com>
	<fdb095270808280814g6c73ef57id3b8b9fbc63784cc@mail.gmail.com>
	<5cbbe4ae0808280858u65549aaanfffc25b6eb122ccf@mail.gmail.com>
Message-ID: <fdb095270808290112y5a6b9b6fh81df047b3b043d1a@mail.gmail.com>

> The only other port that mentions "kext" is macfuse,
> according to rgrep. And that contains a Framework, and
> I would imagine that places the kext into a well-known
> place and takes care of everything. And least it has
> no special means to start it.
>

Macfuse is a good hint. It seems the Port takes a completely different
approach. So I set eridius at macports.org (the maintainer of macfuse) to CC.

@eridius: What's best practics on handling Kexts?


> > Another problem could be a conflict with an already installed Kext (maybe
> > the legacy TUN/TAP driver or Tunnelblick).
>
> MacPorts does not overwrite files but rather fails before doing so.
> And then you just have to know how you manually configured your
> system.
>
> What is the "legacy TUN/TAP" btw?


With legacy I just mean the prebuild/compiled package from tuntaposx (which
e.g. come with Tunnelblick or maybe some other VPN solution). And with
conflict I mean the error on loading the extension when there is already the
"legacy" Kext loaded. Indeed this is not a big problem but slightly unclean.
The outcome of this is an issue with the dependencies of openvpn2.

At the moment I'm pinched of time and during work hours I'm on a Win
machine, so I can't help a lot.
Maybe you just create a Port Submission and upload your Portfile. I will
test it during the next days.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080829/2927477f/attachment.html 

From eridius at macports.org  Fri Aug 29 03:02:17 2008
From: eridius at macports.org (Kevin Ballard)
Date: Fri, 29 Aug 2008 03:02:17 -0700
Subject: openvpn2: "Cannot allocate TUN/TAP dev dynamically"
In-Reply-To: <fdb095270808290112y5a6b9b6fh81df047b3b043d1a@mail.gmail.com>
References: <5cbbe4ae0808261416u3f46c8adka7d4f8bae199c551@mail.gmail.com>
	<48B4FCCB.9030907@macports.org>
	<5cbbe4ae0808271155n1def0a6fs63bf7301014de235@mail.gmail.com>
	<fdb095270808280136h3cebdf0ey40ca348f58d087e7@mail.gmail.com>
	<5cbbe4ae0808280451n30d5c233rb82cc53b4d9f10bd@mail.gmail.com>
	<fdb095270808280814g6c73ef57id3b8b9fbc63784cc@mail.gmail.com>
	<5cbbe4ae0808280858u65549aaanfffc25b6eb122ccf@mail.gmail.com>
	<fdb095270808290112y5a6b9b6fh81df047b3b043d1a@mail.gmail.com>
Message-ID: <01AC016D-BCB5-4FE9-AFAB-EA49F7625043@macports.org>

If the kext is meant to be loaded by the system at startup, it has to  
go in the System-provided folder. The macfuse port just follows the  
lead of the official MacFuse project and puts it where the official  
MacFuse project designates - this works, because MacFuse apps  
explicitly load the kext when they need it.

-Kevin Ballard

On Aug 29, 2008, at 1:12 AM, Uwe Schwartz wrote:

>
> The only other port that mentions "kext" is macfuse,
> according to rgrep. And that contains a Framework, and
> I would imagine that places the kext into a well-known
> place and takes care of everything. And least it has
> no special means to start it.
>
> Macfuse is a good hint. It seems the Port takes a completely  
> different approach. So I set eridius at macports.org (the maintainer of  
> macfuse) to CC.
>
> @eridius: What's best practics on handling Kexts?
>
>
> > Another problem could be a conflict with an already installed Kext  
> (maybe
> > the legacy TUN/TAP driver or Tunnelblick).
>
> MacPorts does not overwrite files but rather fails before doing so.
> And then you just have to know how you manually configured your
> system.
>
> What is the "legacy TUN/TAP" btw?
>
> With legacy I just mean the prebuild/compiled package from tuntaposx  
> (which e.g. come with Tunnelblick or maybe some other VPN solution).  
> And with conflict I mean the error on loading the extension when  
> there is already the "legacy" Kext loaded. Indeed this is not a big  
> problem but slightly unclean. The outcome of this is an issue with  
> the dependencies of openvpn2.
>
> At the moment I'm pinched of time and during work hours I'm on a Win  
> machine, so I can't help a lot.
> Maybe you just create a Port Submission and upload your Portfile. I  
> will test it during the next days.

-- 
Kevin Ballard
http://kevin.sb.org
eridius at macports.org
http://www.tildesoft.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080829/f76a3b01/attachment-0001.html 

From dluke at geeklair.net  Fri Aug 29 07:18:57 2008
From: dluke at geeklair.net (Daniel J. Luke)
Date: Fri, 29 Aug 2008 10:18:57 -0400
Subject: openvpn2: "Cannot allocate TUN/TAP dev dynamically"
In-Reply-To: <01AC016D-BCB5-4FE9-AFAB-EA49F7625043@macports.org>
References: <5cbbe4ae0808261416u3f46c8adka7d4f8bae199c551@mail.gmail.com>
	<48B4FCCB.9030907@macports.org>
	<5cbbe4ae0808271155n1def0a6fs63bf7301014de235@mail.gmail.com>
	<fdb095270808280136h3cebdf0ey40ca348f58d087e7@mail.gmail.com>
	<5cbbe4ae0808280451n30d5c233rb82cc53b4d9f10bd@mail.gmail.com>
	<fdb095270808280814g6c73ef57id3b8b9fbc63784cc@mail.gmail.com>
	<5cbbe4ae0808280858u65549aaanfffc25b6eb122ccf@mail.gmail.com>
	<fdb095270808290112y5a6b9b6fh81df047b3b043d1a@mail.gmail.com>
	<01AC016D-BCB5-4FE9-AFAB-EA49F7625043@macports.org>
Message-ID: <24258160-9914-43C4-B783-352D9159B8FE@geeklair.net>

On Aug 29, 2008, at 6:02 AM, Kevin Ballard wrote:
> If the kext is meant to be loaded by the system at startup,

by IOKit matching...

> it has to go in the System-provided folder.

or a startup script/launchd plist can run kextload on it wherever it  
is located

> The macfuse port just follows the lead of the official MacFuse  
> project and puts it where the official MacFuse project designates -  
> this works, because MacFuse apps explicitly load the kext when they  
> need it.


--
Daniel J. Luke
+========================================================+
| *---------------- dluke at 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: 194 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080829/f46a7cc0/attachment.bin 

From florian.ebeling at gmail.com  Fri Aug 29 08:48:16 2008
From: florian.ebeling at gmail.com (Caspar Florian Ebeling)
Date: Fri, 29 Aug 2008 17:48:16 +0200
Subject: openvpn2: "Cannot allocate TUN/TAP dev dynamically"
In-Reply-To: <24258160-9914-43C4-B783-352D9159B8FE@geeklair.net>
References: <5cbbe4ae0808261416u3f46c8adka7d4f8bae199c551@mail.gmail.com>
	<48B4FCCB.9030907@macports.org>
	<5cbbe4ae0808271155n1def0a6fs63bf7301014de235@mail.gmail.com>
	<fdb095270808280136h3cebdf0ey40ca348f58d087e7@mail.gmail.com>
	<5cbbe4ae0808280451n30d5c233rb82cc53b4d9f10bd@mail.gmail.com>
	<fdb095270808280814g6c73ef57id3b8b9fbc63784cc@mail.gmail.com>
	<5cbbe4ae0808280858u65549aaanfffc25b6eb122ccf@mail.gmail.com>
	<fdb095270808290112y5a6b9b6fh81df047b3b043d1a@mail.gmail.com>
	<01AC016D-BCB5-4FE9-AFAB-EA49F7625043@macports.org>
	<24258160-9914-43C4-B783-352D9159B8FE@geeklair.net>
Message-ID: <5cbbe4ae0808290848h637eceedkb27adf74ad461052@mail.gmail.com>

On Fri, Aug 29, 2008 at 4:18 PM, Daniel J. Luke <dluke at geeklair.net> wrote:
> On Aug 29, 2008, at 6:02 AM, Kevin Ballard wrote:
>>
>> If the kext is meant to be loaded by the system at startup,
>
> by IOKit matching...
>
>> it has to go in the System-provided folder.
>
> or a startup script/launchd plist can run kextload on it wherever it is
> located

That's exactly what I use now.

The package wants to put the kexts into /Library/Extensions, which is
/opt/local/Library/Extensions for us. That violates the mtree. Would
/opt/local/lib/{tap|tun}.kext be an good place to keep them instead?

Florian


-- 
Florian Ebeling
florian.ebeling at gmail.com

From dluke at geeklair.net  Fri Aug 29 12:18:44 2008
From: dluke at geeklair.net (Daniel J. Luke)
Date: Fri, 29 Aug 2008 15:18:44 -0400
Subject: openvpn2: "Cannot allocate TUN/TAP dev dynamically"
In-Reply-To: <5cbbe4ae0808290848h637eceedkb27adf74ad461052@mail.gmail.com>
References: <5cbbe4ae0808261416u3f46c8adka7d4f8bae199c551@mail.gmail.com>
	<48B4FCCB.9030907@macports.org>
	<5cbbe4ae0808271155n1def0a6fs63bf7301014de235@mail.gmail.com>
	<fdb095270808280136h3cebdf0ey40ca348f58d087e7@mail.gmail.com>
	<5cbbe4ae0808280451n30d5c233rb82cc53b4d9f10bd@mail.gmail.com>
	<fdb095270808280814g6c73ef57id3b8b9fbc63784cc@mail.gmail.com>
	<5cbbe4ae0808280858u65549aaanfffc25b6eb122ccf@mail.gmail.com>
	<fdb095270808290112y5a6b9b6fh81df047b3b043d1a@mail.gmail.com>
	<01AC016D-BCB5-4FE9-AFAB-EA49F7625043@macports.org>
	<24258160-9914-43C4-B783-352D9159B8FE@geeklair.net>
	<5cbbe4ae0808290848h637eceedkb27adf74ad461052@mail.gmail.com>
Message-ID: <1084D395-26B4-45D0-B326-A65A1B4671E6@geeklair.net>

On Aug 29, 2008, at 11:48 AM, Caspar Florian Ebeling wrote:
> On Fri, Aug 29, 2008 at 4:18 PM, Daniel J. Luke <dluke at geeklair.net>  
> wrote:
>> On Aug 29, 2008, at 6:02 AM, Kevin Ballard wrote:
>>>
>>> If the kext is meant to be loaded by the system at startup,
>>
>> by IOKit matching...
>>
>>> it has to go in the System-provided folder.
>>
>> or a startup script/launchd plist can run kextload on it wherever  
>> it is
>> located
>
> That's exactly what I use now.
>
> The package wants to put the kexts into /Library/Extensions, which is
> /opt/local/Library/Extensions for us. That violates the mtree.

That seems fine to me, but others might have different ideas.

> Would
> /opt/local/lib/{tap|tun}.kext be an good place to keep them instead?

--
Daniel J. Luke
+========================================================+
| *---------------- dluke at 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: 194 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080829/d7c2f9f9/attachment.bin 

From eridius at macports.org  Fri Aug 29 12:48:33 2008
From: eridius at macports.org (Kevin Ballard)
Date: Fri, 29 Aug 2008 12:48:33 -0700
Subject: openvpn2: "Cannot allocate TUN/TAP dev dynamically"
In-Reply-To: <5cbbe4ae0808290848h637eceedkb27adf74ad461052@mail.gmail.com>
References: <5cbbe4ae0808261416u3f46c8adka7d4f8bae199c551@mail.gmail.com>
	<48B4FCCB.9030907@macports.org>
	<5cbbe4ae0808271155n1def0a6fs63bf7301014de235@mail.gmail.com>
	<fdb095270808280136h3cebdf0ey40ca348f58d087e7@mail.gmail.com>
	<5cbbe4ae0808280451n30d5c233rb82cc53b4d9f10bd@mail.gmail.com>
	<fdb095270808280814g6c73ef57id3b8b9fbc63784cc@mail.gmail.com>
	<5cbbe4ae0808280858u65549aaanfffc25b6eb122ccf@mail.gmail.com>
	<fdb095270808290112y5a6b9b6fh81df047b3b043d1a@mail.gmail.com>
	<01AC016D-BCB5-4FE9-AFAB-EA49F7625043@macports.org>
	<24258160-9914-43C4-B783-352D9159B8FE@geeklair.net>
	<5cbbe4ae0808290848h637eceedkb27adf74ad461052@mail.gmail.com>
Message-ID: <A2B12EEE-7964-45A7-B48F-326901B30075@macports.org>

On Aug 29, 2008, at 8:48 AM, Caspar Florian Ebeling wrote:

> On Fri, Aug 29, 2008 at 4:18 PM, Daniel J. Luke <dluke at geeklair.net>  
> wrote:
>> On Aug 29, 2008, at 6:02 AM, Kevin Ballard wrote:
>>>
>>> If the kext is meant to be loaded by the system at startup,
>>
>> by IOKit matching...
>>
>>> it has to go in the System-provided folder.
>>
>> or a startup script/launchd plist can run kextload on it wherever  
>> it is
>> located
>
> That's exactly what I use now.
>
> The package wants to put the kexts into /Library/Extensions, which is
> /opt/local/Library/Extensions for us. That violates the mtree. Would
> /opt/local/lib/{tap|tun}.kext be an good place to keep them instead?

/opt/local/Library/Extensions seems fine to me. /opt/local/Library is  
already used by at least one other port (python24 uses /opt/local/ 
Library/Frameworks/Python.framework).

-Kevin

-- 
Kevin Ballard
http://kevin.sb.org
eridius at macports.org
http://www.tildesoft.com



From krischik at users.sourceforge.net  Fri Aug 29 22:38:10 2008
From: krischik at users.sourceforge.net (Martin Krischik)
Date: Sat, 30 Aug 2008 07:38:10 +0200
Subject: ffitarget.h": file already exists
Message-ID: <42D4BE33-1EC5-46FD-91F6-24F8D2873133@users.sourceforge.net>

Hello,

I am currently trying to add Ada support to the gcc34 package.  
Currently there is none since Ada is self hosted (the Ada compiler is  
written in Ada) and therefore you need an Ada compiler to compile Ada.

Personally I consider self hosting a good thing even when it makes a  
little more work initially.

Anyway I run into a little problem for which I have no explanation:

-----------------------------
--->  Staging gcc43 into destroot
Error: Target org.macports.destroot returned: error copying "/opt/ 
local/var/macports/build/_Developer_work_gnuada_OSX_ports_lang_gcc43/ 
work/destroot/opt/local/lib/gcc43/gcc/i386-apple-darwin9.4.0/4.3.1/ 
include/ffitarget.h" to "/opt/local/var/macports/build/ 
_Developer_work_gnuada_OSX_ports_lang_gcc43/work/destroot/opt/local/ 
include/gcc43/ffitarget.h": file already exists
Error: Status 1 encountered during processing.
-----------------------------

I deleted "/opt/local/var/macports/build/ 
_Developer_work_gnuada_OSX_ports_lang_gcc43" before starting to  
compile and still I get this error.

Any ideas where to look for the problem?

I have attached the Portfile - if you want to try it out you will get  
the needed boot strap compiler from http://www.macada.org.

I can provide more debug information it that helps.

With Regards


Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Portfile
Type: application/octet-stream
Size: 5772 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080830/6afba564/attachment.obj 
-------------- next part --------------

-------------- 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/20080830/6afba564/attachment.bin 

From msavory1 at nzbox.com  Fri Aug 29 23:39:47 2008
From: msavory1 at nzbox.com (Mike Savory)
Date: Fri, 29 Aug 2008 23:39:47 -0700
Subject: Fwd: Building 
References: <EBE7ECD4-3FC9-4046-AF02-CC1FBAA9E04B@nzbox.com>
Message-ID: <0120A783-34A7-4C9F-929F-B6D1E11ECC34@nzbox.com>

Sent this to Chris, the port maintainer

Should I open a ticket??

Mike


Begin forwarded message:

> From: Mike Savory <msavory at nzbox.com>
> Date: August 21, 2008 9:39:54 PM PDT
> To: chris.owen at consault.com
> Subject: Building
>
> Hi Chris
>
> Im trying to get a local portfile to work for py-libdnet and  
> python2.5 (to get scapy 2 running (requires Python 2.5)
>
> Have you looked at making a portfile for py25
>
>
>
> I tried both just changing yours to have
>
> set python.bin	${prefix}/bin/python2.5
>
> and to do add in the
>
> PortGroup               python25 1.0
>
> (which I don't really understand)
>
> I have had success with the py-pylibpcap library building OK I  
> think...
>
> This is my current try with your Portfile
>
> # $Id: Portfile 20751 2006-11-25 22:10:13Z markd at macports.org $
> PortSystem              1.0
> #PortGroup               python25 1.0
>
> set python.bin	${prefix}/bin/python2.5
>
> name                    py25-libdnet
> version                 1.11
> categories              python net
> maintainers             chris.owen at consault.com
> description             A python module for the libdnet low-level  
> networking library.
> long_description        \
>       Libdnet provides a simplified, portable interface to several  
> low-level \
>       networking routines, including: network address manipulation,  
> kernel \
>       arp(4) cache and route(4) table lookup and manipulation,  
> network \
>       firewalling (IP filter, ipfw, ipchains, pf, ...), network  
> interface \
>       lookup and manipulation, raw IP packet and Ethernet frame  
> transmission.
> homepage                http://libdnet.sourceforge.net/
>
>
> master_sites            sourceforge:libdnet
> distname                libdnet-${version}
>
> depends_lib	      port:libdnet
>
> checksums		md5 04c394ed8e1e7fc455456e79e908916d \
> 			sha1 e2ae8c7f0ca95655ae9f77fd4a0e2235dc4716bf \
> 			rmd160 9a940cdd96af4b513a048f3a389e3f7eb0bb7011
>
>
> pre-destroot {
> 	worksrcdir	${worksrcdir}/python
> }
> destroot.cmd		${python.bin} setup.py
> destroot.destdir	--prefix=${prefix} --root=${destroot}
>
>
> $ sudo port install py25-libdnet
> Portfile changed since last build; discarding previous state.
> --->  Fetching py25-libdnet
> --->  Attempting to fetch libdnet-1.11.tar.gz from http://downloads.sourceforge.net/libdnet
> --->  Verifying checksum(s) for py25-libdnet
> --->  Extracting py25-libdnet
> --->  Configuring py25-libdnet
> --->  Building py25-libdnet with target all
> --->  Staging py25-libdnet into destroot
> Error: Target org.macports.destroot returned: shell command " cd "/ 
> opt/local/var/macports/build/_Users_mikesavory_mp_python_py25- 
> libdnet/work/libdnet-1.11/python" && /opt/local/bin/python2.5  
> setup.py install --prefix=/opt/local --root=/opt/local/var/macports/ 
> build/_Users_mikesavory_mp_python_py25-libdnet/work/destroot "  
> returned error 1
> Command output: running install
> running build
> running build_ext
> building 'dnet' extension
> creating build
> creating build/temp.macosx-10.3-i386-2.5
> -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I../include -I/ 
> opt/local/Library/Frameworks/Python.framework/Versions/2.5/include/ 
> python2.5 -c ./dnet.c -o build/temp.macosx-10.3-i386-2.5/./dnet.o
> unable to execute -DNDEBUG: No such file or directory
> error: command '-DNDEBUG' failed with exit status 1
>
> Error: Status 1 encountered during processing.
>
>
>
>
> Regards
>
> Mike


From jmr at macports.org  Sat Aug 30 02:22:17 2008
From: jmr at macports.org (Joshua Root)
Date: Sat, 30 Aug 2008 19:22:17 +1000
Subject: Fwd: Building
In-Reply-To: <0120A783-34A7-4C9F-929F-B6D1E11ECC34@nzbox.com>
References: <EBE7ECD4-3FC9-4046-AF02-CC1FBAA9E04B@nzbox.com>
	<0120A783-34A7-4C9F-929F-B6D1E11ECC34@nzbox.com>
Message-ID: <48B91149.7040000@macports.org>

Mike Savory wrote:
>> I tried both just changing yours to have
>>
>> set python.bin	${prefix}/bin/python2.5
>>
>> and to do add in the
>>
>> PortGroup               python25 1.0
>>
>> (which I don't really understand)

PortGroup is like an include statement. It pulls in the code from one of
the files in /opt/local/share/macports/resources/port1.0/group/.

- Josh

From florian.ebeling at gmail.com  Sat Aug 30 04:14:40 2008
From: florian.ebeling at gmail.com (Caspar Florian Ebeling)
Date: Sat, 30 Aug 2008 13:14:40 +0200
Subject: openvpn2: "Cannot allocate TUN/TAP dev dynamically"
In-Reply-To: <A2B12EEE-7964-45A7-B48F-326901B30075@macports.org>
References: <5cbbe4ae0808261416u3f46c8adka7d4f8bae199c551@mail.gmail.com>
	<fdb095270808280136h3cebdf0ey40ca348f58d087e7@mail.gmail.com>
	<5cbbe4ae0808280451n30d5c233rb82cc53b4d9f10bd@mail.gmail.com>
	<fdb095270808280814g6c73ef57id3b8b9fbc63784cc@mail.gmail.com>
	<5cbbe4ae0808280858u65549aaanfffc25b6eb122ccf@mail.gmail.com>
	<fdb095270808290112y5a6b9b6fh81df047b3b043d1a@mail.gmail.com>
	<01AC016D-BCB5-4FE9-AFAB-EA49F7625043@macports.org>
	<24258160-9914-43C4-B783-352D9159B8FE@geeklair.net>
	<5cbbe4ae0808290848h637eceedkb27adf74ad461052@mail.gmail.com>
	<A2B12EEE-7964-45A7-B48F-326901B30075@macports.org>
Message-ID: <5cbbe4ae0808300414i7ff3298y4919b8faebcfcd1b@mail.gmail.com>

>> The package wants to put the kexts into /Library/Extensions, which is
>> /opt/local/Library/Extensions for us. That violates the mtree. Would
>> /opt/local/lib/{tap|tun}.kext be an good place to keep them instead?
>
> /opt/local/Library/Extensions seems fine to me. /opt/local/Library is
> already used by at least one other port (python24 uses
> /opt/local/Library/Frameworks/Python.framework).

Ok, then I just leave it there. And I think it's quite reasonable as
well to put objects which are clearly Mac-only and not Unix in general
into Mac locations. Should that be mentioned in the guide as a possibility?

Florian


-- 
Florian Ebeling
florian.ebeling at gmail.com

From ryandesign at macports.org  Sat Aug 30 12:58:59 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 30 Aug 2008 14:58:59 -0500
Subject: Building 
In-Reply-To: <0120A783-34A7-4C9F-929F-B6D1E11ECC34@nzbox.com>
References: <EBE7ECD4-3FC9-4046-AF02-CC1FBAA9E04B@nzbox.com>
	<0120A783-34A7-4C9F-929F-B6D1E11ECC34@nzbox.com>
Message-ID: <A9746462-20E6-4D15-9DE9-A405D54BDE4B@macports.org>

Since this question is about Portfile development, not using  
MacPorts, I'll continue this thread only on macports-dev.


On Aug 21, 2008, at 9:39:54 PM, Mike Savory wrote:

> Im trying to get a local portfile to work for py-libdnet and
> python2.5 (to get scapy 2 running (requires Python 2.5)
>
> Have you looked at making a portfile for py25
>
>
>
> I tried both just changing yours to have
>
> set python.bin	${prefix}/bin/python2.5

I wouldn't have thought this line would be necessary, since the  
python25 PortGroup takes care of this.


> and to do add in the
>
> PortGroup               python25 1.0
>
> (which I don't really understand)

To understand the python25 PortGroup, you can read the Guide:

http://guide.macports.org/#reference.portgroup.python

And the source code:

http://trac.macports.org/browser/trunk/base/src/port1.0/resources/ 
group/python25-1.0.tcl



From ryandesign at macports.org  Sat Aug 30 13:55:10 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 30 Aug 2008 15:55:10 -0500
Subject: openvpn2: "Cannot allocate TUN/TAP dev dynamically"
In-Reply-To: <5cbbe4ae0808300414i7ff3298y4919b8faebcfcd1b@mail.gmail.com>
References: <5cbbe4ae0808261416u3f46c8adka7d4f8bae199c551@mail.gmail.com>
	<fdb095270808280136h3cebdf0ey40ca348f58d087e7@mail.gmail.com>
	<5cbbe4ae0808280451n30d5c233rb82cc53b4d9f10bd@mail.gmail.com>
	<fdb095270808280814g6c73ef57id3b8b9fbc63784cc@mail.gmail.com>
	<5cbbe4ae0808280858u65549aaanfffc25b6eb122ccf@mail.gmail.com>
	<fdb095270808290112y5a6b9b6fh81df047b3b043d1a@mail.gmail.com>
	<01AC016D-BCB5-4FE9-AFAB-EA49F7625043@macports.org>
	<24258160-9914-43C4-B783-352D9159B8FE@geeklair.net>
	<5cbbe4ae0808290848h637eceedkb27adf74ad461052@mail.gmail.com>
	<A2B12EEE-7964-45A7-B48F-326901B30075@macports.org>
	<5cbbe4ae0808300414i7ff3298y4919b8faebcfcd1b@mail.gmail.com>
Message-ID: <00B53CDE-9C02-41D2-BBA3-ECEA8D2038C5@macports.org>


On Aug 30, 2008, at 6:14 AM, Caspar Florian Ebeling wrote:

>>> The package wants to put the kexts into /Library/Extensions,  
>>> which is
>>> /opt/local/Library/Extensions for us. That violates the mtree. Would
>>> /opt/local/lib/{tap|tun}.kext be an good place to keep them instead?
>>
>> /opt/local/Library/Extensions seems fine to me. /opt/local/Library is
>> already used by at least one other port (python24 uses
>> /opt/local/Library/Frameworks/Python.framework).
>
> Ok, then I just leave it there. And I think it's quite reasonable as
> well to put objects which are clearly Mac-only and not Unix in general
> into Mac locations.

That seems reasonable.

> Should that be mentioned in the guide as a possibility?

It seems obvious to me, such that no mention in the Guide should be  
necessary.

Note that python24 does not (or at least will not, as of MacPorts  
1.7.0) use /opt/local/Library/Frameworks/Python.framework, or even $ 
{prefix}/Library/Frameworks/Python.framework, which is what you  
probably meant. In MacPorts 1.7.0 we have a new variable $ 
{frameworks_dir}, so it will go in ${frameworks_dir}/ 
Python.framework. This brings up the question of whether we should  
have a ${library_dir} variable, and base ${frameworks_dir} on that,  
so that others can use ${library_dir} for less-usual purposes, like  
kernel extensions.



From florian.ebeling at gmail.com  Sat Aug 30 15:35:56 2008
From: florian.ebeling at gmail.com (Caspar Florian Ebeling)
Date: Sun, 31 Aug 2008 00:35:56 +0200
Subject: openvpn2: "Cannot allocate TUN/TAP dev dynamically"
In-Reply-To: <00B53CDE-9C02-41D2-BBA3-ECEA8D2038C5@macports.org>
References: <5cbbe4ae0808261416u3f46c8adka7d4f8bae199c551@mail.gmail.com>
	<fdb095270808280814g6c73ef57id3b8b9fbc63784cc@mail.gmail.com>
	<5cbbe4ae0808280858u65549aaanfffc25b6eb122ccf@mail.gmail.com>
	<fdb095270808290112y5a6b9b6fh81df047b3b043d1a@mail.gmail.com>
	<01AC016D-BCB5-4FE9-AFAB-EA49F7625043@macports.org>
	<24258160-9914-43C4-B783-352D9159B8FE@geeklair.net>
	<5cbbe4ae0808290848h637eceedkb27adf74ad461052@mail.gmail.com>
	<A2B12EEE-7964-45A7-B48F-326901B30075@macports.org>
	<5cbbe4ae0808300414i7ff3298y4919b8faebcfcd1b@mail.gmail.com>
	<00B53CDE-9C02-41D2-BBA3-ECEA8D2038C5@macports.org>
Message-ID: <5cbbe4ae0808301535s64cc9225x279a13163eb0801c@mail.gmail.com>

> Note that python24 does not (or at least will not, as of MacPorts 1.7.0) use
> /opt/local/Library/Frameworks/Python.framework, or even
> ${prefix}/Library/Frameworks/Python.framework, which is what you probably
> meant. In MacPorts 1.7.0 we have a new variable ${frameworks_dir}, so it
> will go in ${frameworks_dir}/Python.framework. This brings up the question
> of whether we should have a ${library_dir} variable, and base
> ${frameworks_dir} on that, so that others can use ${library_dir} for
> less-usual purposes, like kernel extensions.

Yes, sounds like a good idea to me.



-- 
Florian Ebeling
florian.ebeling at gmail.com