From blair at orcaware.com  Tue Jul  1 07:29:16 2008
From: blair at orcaware.com (Blair Zajac)
Date: Tue, 1 Jul 2008 07:29:16 -0700
Subject: [Pythonmac-SIG] 64-bit Python?
In-Reply-To: <D1BA44D3-0052-48BA-BE78-9607DF24BBC4@nrao.edu>
References: <302611.62100.qm@web52111.mail.re2.yahoo.com>
	<CFB80CA1-9687-43E1-97ED-8DB26FC4C025@boulder.nist.gov>
	<D1BA44D3-0052-48BA-BE78-9607DF24BBC4@nrao.edu>
Message-ID: <013D636B-AE5E-4AF7-AC00-52E74A7B863E@orcaware.com>


On May 29, 2008, at 3:13 PM, Boyd Waters wrote:

>
> On May 29, 2008, at 2:53 PM, Frank Schima wrote:
>
>> I have the latest Mac Pro with 10.5.3. I ran the sys.maxint test  
>> and got the 32-bit result. I tried both the Apple python and the  
>> MacPorts python 2.5.2.
>
>
> The MacPorts 2.5.2 doesn't have my 64-bit hacks in it. I'm not sure  
> what the consequences of 64-bit Python will be with respect to other  
> Python packages, so I haven't committed the changes. And I ran into  
> a problem compiling this on Tiger with GNU (non-Apple-patched) GCC  
> 4.2.1.
>
> But it's really 64-bit Python here, I think:
>
> $ /usr/bin/python -c 'import sys; print sys.maxint'
> 2147483647
>
> $ /opt/casa/core2-apple-darwin9/3rd-party/bin/python -c 'import sys;  
> print sys.maxint'
> 9223372036854775807
>
>
> Here's the MacPorts port:
>
> <python25.tbz>
>
>
>
> You might unpack this thing into your MacPorts tree like this:
>
> tar xjvf ~/Downloads/python25.tbz -C $(port dir python25)/..
>
> and then do a port update python25
>
> ... but I haven't tested that path.
>
> I can post a binary on a web site if anyone is interested in testing  
> this; it's a quad-architecture Framework build.
>
> Be careful out there...

How would a quad-architecture build work with other C/C++ modules?

Having a 64-bit itself would be nice, but that would require all  
Python modules also be compiled in 64-bit, such as Qt, Subversion,  
anything that is a C/C++ package on its own that has a Python module.   
So I think the ramifications of going to a pure 64-bit Python would be  
large and would have to be decided by MacPorts group as a whole if we  
want to move in that direction.

Regards,
Blair

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



From bwaters at nrao.edu  Tue Jul  1 19:17:08 2008
From: bwaters at nrao.edu (Boyd Waters)
Date: Tue, 1 Jul 2008 20:17:08 -0600
Subject: [Pythonmac-SIG] 64-bit Python?
In-Reply-To: <013D636B-AE5E-4AF7-AC00-52E74A7B863E@orcaware.com>
References: <302611.62100.qm@web52111.mail.re2.yahoo.com>
	<CFB80CA1-9687-43E1-97ED-8DB26FC4C025@boulder.nist.gov>
	<D1BA44D3-0052-48BA-BE78-9607DF24BBC4@nrao.edu>
	<013D636B-AE5E-4AF7-AC00-52E74A7B863E@orcaware.com>
Message-ID: <970BFEE1-53DE-4B39-80AB-6971D3F1EDD6@nrao.edu>


On Jul 1, 2008, at 8:29 AM, Blair Zajac wrote:

> How would a quad-architecture build work with other C/C++ modules?

I haven't tested other modules yet; I'm still building quad- 
architecture GCC 4.2.4 with AT&T and Apple patches. Got that MacPorted  
yesterday after two weeks' work... now we have a gfortran that plays  
nice with Apple-patched GCC, I think.

> Having a 64-bit itself would be nice, but that would require all  
> Python modules also be compiled in 64-bit, such as Qt, Subversion,  
> anything that is a C/C++ package on its own that has a Python  
> module.  So I think the ramifications of going to a pure 64-bit  
> Python would be large and would have to be decided by MacPorts group  
> as a whole if we want to move in that direction.

Yes, I am hoping to build up our local NRAO/CASA package toolchain  
quad-architecture. I don't know how far I can get. I already have an  
Intel 32/64-bit Qt; that's TrollTech's Cocoa version (expected to  
release as Qt 4.5). I would need to build all of SciPy quad-arch to  
make this fly...

   - boyd


Boyd Waters
Scientific Programmer
National Radio Astronomy Observatory
Socorro, New Mexico


From ryandesign at macports.org  Wed Jul  2 00:57:50 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 2 Jul 2008 02:57:50 -0500
Subject: [37988] trunk/dports/net/obby/Portfile
In-Reply-To: <20080702062802.89E6B101310@beta.macosforge.org>
References: <20080702062802.89E6B101310@beta.macosforge.org>
Message-ID: <5BD9B2DE-A099-4FBA-BB3D-6277C9397AA6@macports.org>

You should increment the port revision so everyone who already had  
the port installed also gets this change. I did this in r37990.

On Jul 2, 2008, at 01:28, pkern at macports.org wrote:

> Revision: 37988
>           http://trac.macosforge.org/projects/macports/changeset/37988
> Author:   pkern at macports.org
> Date:     2008-07-01 23:28:01 -0700 (Tue, 01 Jul 2008)
> Log Message:
> -----------
> net/obby: change howl dep to avahi (#15808)
>
> Modified Paths:
> --------------
>     trunk/dports/net/obby/Portfile
>
> Modified: trunk/dports/net/obby/Portfile
> ===================================================================
> --- trunk/dports/net/obby/Portfile	2008-07-02 05:59:11 UTC (rev 37987)
> +++ trunk/dports/net/obby/Portfile	2008-07-02 06:28:01 UTC (rev 37988)
> @@ -21,7 +21,7 @@
>
>  depends_build	port:pkgconfig
>  depends_lib	port:libsigcxx2 \
> -		port:howl \
> +		port:avahi \
>  		lib:libnet6-1.3.0:net6
>
>  configure.args	--with-zeroconf --enable-ipv6



From dluke at geeklair.net  Wed Jul  2 08:59:59 2008
From: dluke at geeklair.net (Daniel J. Luke)
Date: Wed, 2 Jul 2008 11:59:59 -0400
Subject: port upgrade when port is not installed
In-Reply-To: <7F65C8FB-5A8C-4C93-8BF1-92DCA36B03BB@macports.org>
References: <7F65C8FB-5A8C-4C93-8BF1-92DCA36B03BB@macports.org>
Message-ID: <E3C12D69-9F80-4217-8C7D-5B311EC9A3F5@geeklair.net>

On Jun 30, 2008, at 2:27 AM, Ryan Schmidt wrote:
> It built and installed wget, then built it again, then tried to
> uninstall the old version which was never installed in the first
> place. If port upgrade is going to break if a port is not already
> installed, it should fail right at the very beginning with a clear
> message telling the user to use port install. Alternately, port
> upgrade could become a synonym for port install if the port is not
> already installed.

I think this only happened because of the -u

(ie. if you did port -nf upgrade wget && port -f uninstall inactive  
things would work the way you expect).

It's been a while since I looked at the upgrade code, though, so  
things could have changed.

... but you're right, it's unexpected behavior and probably should be  
fixed.

--
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/20080702/a5d9d449/attachment.bin 

From wsiegrist at apple.com  Wed Jul  2 15:01:47 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Wed, 02 Jul 2008 15:01:47 -0700
Subject: Trac issue tracker is slow
In-Reply-To: <486733C2.1050104@macports.org>
References: <F6220EA4-F4FD-4517-AC75-29C097ADF18C@macports.org>
	<68129AAA-E87C-4341-8E07-DDEC09FB9575@apple.com>
	<90977C1C-DEF5-401F-B147-EB90F49BC1C7@macports.org>
	<A793B5BE-F07C-468F-8776-C5973BC0D49C@apple.com>
	<486733C2.1050104@macports.org>
Message-ID: <CA92A0EF-C2ED-4400-9F19-DF6BD4D79CC3@apple.com>


On Jun 29, 2008, at 12:03 AM, Joshua Root wrote:

> William Siegrist wrote:
>> On Jun 20, 2008, at 11:45 PM, Ryan Schmidt wrote:
>>> On Jun 20, 2008, at 11:21 PM, William Siegrist wrote:
>>>> So let me know if this change is worth the performance.  If some  
>>>> devs want to see the difference, you can ping me in IRC so I can  
>>>> switch the option, let you load a few of these pages, and then  
>>>> switch back. Its quite noticeable.
>>>
>>> Absent a way to build the menu ourselves, my vote would be to  
>>> switch to a text box. I usually copy/paste the maintainer's email  
>>> address from the "port info" output anyway, since we never got the  
>>> full list of maintainers in the drop down box.
>
> I'd be in favour of switching to a text box too, especially if it  
> could be made to automatically append @macports.org to bare  
> usernames (maybe even validate the result). In fact, why not do this  
> for cc as well? It would also be nice to be able to assign tickets  
> to non-committer accounts.
>


I like the idea of expanding bare names with @macports for both  
fields. Maybe even use the autocomplete idea with this. It doesnt seem  
too hard to do as a plugin, but I'm in the process of upgrading to  
Trac v0.11. So I could write the plugin for v0.11 and deploy it when  
I'm ready to deploy v0.11, but that will still be a few weeks away.

Does anyone want to step forward and declare a naive text field the  
way to go in the short term and the smarter text field a nice upgrade  
in a few weeks?

-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/20080702/6d851493/attachment.bin 

From ryandesign at macports.org  Wed Jul  2 15:08:46 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 2 Jul 2008 17:08:46 -0500
Subject: Trac issue tracker is slow
In-Reply-To: <CA92A0EF-C2ED-4400-9F19-DF6BD4D79CC3@apple.com>
References: <F6220EA4-F4FD-4517-AC75-29C097ADF18C@macports.org>
	<68129AAA-E87C-4341-8E07-DDEC09FB9575@apple.com>
	<90977C1C-DEF5-401F-B147-EB90F49BC1C7@macports.org>
	<A793B5BE-F07C-468F-8776-C5973BC0D49C@apple.com>
	<486733C2.1050104@macports.org>
	<CA92A0EF-C2ED-4400-9F19-DF6BD4D79CC3@apple.com>
Message-ID: <188CFA2D-C25B-400C-A344-23542BCE26A3@macports.org>


On Jul 2, 2008, at 17:01, William Siegrist wrote:
> On Jun 29, 2008, at 12:03 AM, Joshua Root wrote:
>> William Siegrist wrote:
>>> On Jun 20, 2008, at 11:45 PM, Ryan Schmidt wrote:
>>>> On Jun 20, 2008, at 11:21 PM, William Siegrist wrote:
>>>>> So let me know if this change is worth the performance.  If  
>>>>> some devs want to see the difference, you can ping me in IRC so  
>>>>> I can switch the option, let you load a few of these pages, and  
>>>>> then switch back. Its quite noticeable.
>>>>
>>>> Absent a way to build the menu ourselves, my vote would be to  
>>>> switch to a text box. I usually copy/paste the maintainer's  
>>>> email address from the "port info" output anyway, since we never  
>>>> got the full list of maintainers in the drop down box.
>>
>> I'd be in favour of switching to a text box too, especially if it  
>> could be made to automatically append @macports.org to bare  
>> usernames (maybe even validate the result). In fact, why not do  
>> this for cc as well? It would also be nice to be able to assign  
>> tickets to non-committer accounts.
>
> I like the idea of expanding bare names with @macports for both  
> fields. Maybe even use the autocomplete idea with this. It doesnt  
> seem too hard to do as a plugin, but I'm in the process of  
> upgrading to Trac v0.11. So I could write the plugin for v0.11 and  
> deploy it when I'm ready to deploy v0.11, but that will still be a  
> few weeks away.

I think that would be super.


> Does anyone want to step forward and declare a naive text field the  
> way to go in the short term and the smarter text field a nice  
> upgrade in a few weeks?

I say go for it!



From wsiegrist at apple.com  Wed Jul  2 15:11:49 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Wed, 02 Jul 2008 15:11:49 -0700
Subject: Trac issue tracker is slow
In-Reply-To: <188CFA2D-C25B-400C-A344-23542BCE26A3@macports.org>
References: <F6220EA4-F4FD-4517-AC75-29C097ADF18C@macports.org>
	<68129AAA-E87C-4341-8E07-DDEC09FB9575@apple.com>
	<90977C1C-DEF5-401F-B147-EB90F49BC1C7@macports.org>
	<A793B5BE-F07C-468F-8776-C5973BC0D49C@apple.com>
	<486733C2.1050104@macports.org>
	<CA92A0EF-C2ED-4400-9F19-DF6BD4D79CC3@apple.com>
	<188CFA2D-C25B-400C-A344-23542BCE26A3@macports.org>
Message-ID: <EC6308AD-AF68-4320-A0CA-101BBD321E2B@apple.com>


On Jul 2, 2008, at 3:08 PM, Ryan Schmidt wrote:

>
> On Jul 2, 2008, at 17:01, William Siegrist wrote:
>> On Jun 29, 2008, at 12:03 AM, Joshua Root wrote:
>>> William Siegrist wrote:
>>>> On Jun 20, 2008, at 11:45 PM, Ryan Schmidt wrote:
>>>>> On Jun 20, 2008, at 11:21 PM, William Siegrist wrote:
>>>>>> So let me know if this change is worth the performance.  If  
>>>>>> some devs want to see the difference, you can ping me in IRC so  
>>>>>> I can switch the option, let you load a few of these pages, and  
>>>>>> then switch back. Its quite noticeable.
>>>>>
>>>>> Absent a way to build the menu ourselves, my vote would be to  
>>>>> switch to a text box. I usually copy/paste the maintainer's  
>>>>> email address from the "port info" output anyway, since we never  
>>>>> got the full list of maintainers in the drop down box.
>>>
>>> I'd be in favour of switching to a text box too, especially if it  
>>> could be made to automatically append @macports.org to bare  
>>> usernames (maybe even validate the result). In fact, why not do  
>>> this for cc as well? It would also be nice to be able to assign  
>>> tickets to non-committer accounts.
>>
>> I like the idea of expanding bare names with @macports for both  
>> fields. Maybe even use the autocomplete idea with this. It doesnt  
>> seem too hard to do as a plugin, but I'm in the process of  
>> upgrading to Trac v0.11. So I could write the plugin for v0.11 and  
>> deploy it when I'm ready to deploy v0.11, but that will still be a  
>> few weeks away.
>
> I think that would be super.
>
>
>> Does anyone want to step forward and declare a naive text field the  
>> way to go in the short term and the smarter text field a nice  
>> upgrade in a few weeks?
>
> I say go for it!
>
>

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/20080702/7f005964/attachment.bin 

From ryandesign at macports.org  Wed Jul  2 15:32:25 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 2 Jul 2008 17:32:25 -0500
Subject: Trac issue tracker is slow
In-Reply-To: <EC6308AD-AF68-4320-A0CA-101BBD321E2B@apple.com>
References: <F6220EA4-F4FD-4517-AC75-29C097ADF18C@macports.org>
	<68129AAA-E87C-4341-8E07-DDEC09FB9575@apple.com>
	<90977C1C-DEF5-401F-B147-EB90F49BC1C7@macports.org>
	<A793B5BE-F07C-468F-8776-C5973BC0D49C@apple.com>
	<486733C2.1050104@macports.org>
	<CA92A0EF-C2ED-4400-9F19-DF6BD4D79CC3@apple.com>
	<188CFA2D-C25B-400C-A344-23542BCE26A3@macports.org>
	<EC6308AD-AF68-4320-A0CA-101BBD321E2B@apple.com>
Message-ID: <B0B4E3F9-F682-4887-8AB3-2AD600FABC44@macports.org>

On Jul 2, 2008, at 17:11, William Siegrist wrote:
> On Jul 2, 2008, at 3:08 PM, Ryan Schmidt wrote:
>> On Jul 2, 2008, at 17:01, William Siegrist wrote:
>>> On Jun 29, 2008, at 12:03 AM, Joshua Root wrote:
>>>> William Siegrist wrote:
>>>>> On Jun 20, 2008, at 11:45 PM, Ryan Schmidt wrote:
>>>>>> On Jun 20, 2008, at 11:21 PM, William Siegrist wrote:
>>>>>>> So let me know if this change is worth the performance.  If  
>>>>>>> some devs want to see the difference, you can ping me in IRC  
>>>>>>> so I can switch the option, let you load a few of these  
>>>>>>> pages, and then switch back. Its quite noticeable.
>>>>>>
>>>>>> Absent a way to build the menu ourselves, my vote would be to  
>>>>>> switch to a text box. I usually copy/paste the maintainer's  
>>>>>> email address from the "port info" output anyway, since we  
>>>>>> never got the full list of maintainers in the drop down box.
>>>>
>>>> I'd be in favour of switching to a text box too, especially if  
>>>> it could be made to automatically append @macports.org to bare  
>>>> usernames (maybe even validate the result). In fact, why not do  
>>>> this for cc as well? It would also be nice to be able to assign  
>>>> tickets to non-committer accounts.
>>>
>>> I like the idea of expanding bare names with @macports for both  
>>> fields. Maybe even use the autocomplete idea with this. It doesnt  
>>> seem too hard to do as a plugin, but I'm in the process of  
>>> upgrading to Trac v0.11. So I could write the plugin for v0.11  
>>> and deploy it when I'm ready to deploy v0.11, but that will still  
>>> be a few weeks away.
>>
>> I think that would be super.
>>
>>> Does anyone want to step forward and declare a naive text field  
>>> the way to go in the short term and the smarter text field a nice  
>>> upgrade in a few weeks?
>>
>> I say go for it!
>
> Done.

I would have to say
that is a lot faster!
Thanks.


From raimue at macports.org  Wed Jul  2 17:47:54 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 03 Jul 2008 02:47:54 +0200
Subject: Contrib area (was: Re: MacPorts AutoBuild)
In-Reply-To: <BE635494-5F5D-4FE3-91BD-0764C5A1BB2A@macports.org>
References: <86A557C5-0074-49D2-802C-A45062768220@macports.org>
	<BE635494-5F5D-4FE3-91BD-0764C5A1BB2A@macports.org>
Message-ID: <486C21BA.4050400@macports.org>

Ryan Schmidt wrote:
> The page says MPAB is to be downloaded from the attachment on that  
> wiki page. Why not put it in the repository somewhere, like in /users/ 
> blb?

Maybe we should create a 'contrib area' in our repository? That would be 
another directory like /trunk/contrib or /trunk/tools for stuff like this.

I consider /users to be the private room of developers and I don't want 
to tread on someones toes by committing there (of course it's a path 
like any other, but still there is some psychological barrier...).

We currently have some stuff lying around which is not necessarily bound 
to only one user and could therefore be on a more prominent place. Also, 
this might attract more developers to work on it.

I suggest to move the following things from other places
into a 'contrib area':

   * MPWA (from /users/jberry/mpwa/)
   * MPAB (from the wiki)
   * select (used for {gcc,python}_select, from /users/mww/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.

Of course I understand if someone wants total control over his project 
(and rather wants to see patches than commits from others), this could 
remain in the /users space.

Comments?

Rainer

From wsiegrist at apple.com  Thu Jul  3 12:52:33 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Thu, 03 Jul 2008 12:52:33 -0700
Subject: [38028] trunk/dports/PortIndex
In-Reply-To: <20080703194544.0D264108C60@beta.macosforge.org>
References: <20080703194544.0D264108C60@beta.macosforge.org>
Message-ID: <744A53FA-3E13-4208-915C-CE6C6C144F9F@apple.com>

Daniel,

Would you like Mac OS Forge to start running this job? I believe it  
was the plan to eventually move it, so I am making the offer.

-Bill



On Jul 3, 2008, at 12:45 PM, dluke at macports.org wrote:

> Revision38028Authordluke at macports.orgDate2008-07-03 12:45:43 -0700  
> (Thu, 03 Jul 2008)Log Message
> Total number of ports parsed:	4861
> Ports successfully parsed:	4861	
> Ports failed:			0
> Modified Paths
> 	? trunk/dports/PortIndex
> Diff
> Modified: trunk/dports/PortIndex (38027 => 38028)
>
-------------- 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/20080703/96f1812d/attachment.bin 

From kimuraw at macports.org  Thu Jul  3 14:36:16 2008
From: kimuraw at macports.org (kimura wataru)
Date: Fri, 4 Jul 2008 06:36:16 +0900
Subject: lang/ruby: ignore minor system version for archdir, like Apple's Ruby
Message-ID: <20080704063616180029.5b40ba6c@macports.org>

Hi, I'm a maintainer of lang/ruby.

I'm planning to change the Portfile of lang/ruby to ignore minor 
system version for "archdir", like Apple's Ruby.

Ruby uses "archdir" to define install destination of extension
modules, such as "RMagick.bundle". I think it is not convenient 
to need to re-install ruby libraries (port:rb-*) which includes 
extension module(s) for minor upgrade of MacOS X.

Please tell me your thoughts and issues about this change.

before:
 10.4.11-> i686-darwin8.11.0
 10.5.1 -> i686-darwin9.1.0
 10.5.3 -> i686-darwin9.3.0

after:
 10.4.11-> i686-darwin8.0
 10.5.1 -> i686-darwin9.0
 10.5.3 -> i686-darwin9.0


I tested with the following change and got a good result.

Index: lang/ruby/Portfile
===================================================================
--- lang/ruby/Portfile	(revision 37739)
+++ lang/ruby/Portfile	(working copy)
@@ -4,7 +4,7 @@
 
 name			ruby
 version			1.8.7-p22
-revision		2
+revision		3
 
 categories		lang ruby
 maintainers		kimuraw
@@ -49,6 +49,8 @@
 				--enable-pthread \
 				--without-tk \
 				--with-vendordir=${prefix}/lib/ruby/vendor_ruby
+# ignore minor version for archdir, like i686-darwin9.0
+configure.env	UNAME_RELEASE=${os.major}.0
 
 destroot.target	install install-doc
 post-destroot {


-- 
kimura wataru

From raimue at macports.org  Thu Jul  3 15:08:43 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Fri, 04 Jul 2008 00:08:43 +0200
Subject: lang/ruby: ignore minor system version for archdir, like Apple's
	Ruby
In-Reply-To: <20080704063616180029.5b40ba6c@macports.org>
References: <20080704063616180029.5b40ba6c@macports.org>
Message-ID: <486D4DEB.8080401@macports.org>

kimura wataru wrote:
> Hi, I'm a maintainer of lang/ruby.

Hi Kimuraw!
Welcome aboard :-)

> I'm planning to change the Portfile of lang/ruby to ignore minor 
> system version for "archdir", like Apple's Ruby.
> 
> Ruby uses "archdir" to define install destination of extension
> modules, such as "RMagick.bundle". I think it is not convenient 
> to need to re-install ruby libraries (port:rb-*) which includes 
> extension module(s) for minor upgrade of MacOS X.

I agree. An upgrade of Mac OS X should not force to rebuild anything if 
it can be avoided and is not necessary. And as Apple does this as well I 
assume it should be safe.

Rainer

From raimue at macports.org  Thu Jul  3 19:52:54 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Fri, 04 Jul 2008 04:52:54 +0200
Subject: Wiki change notifications
Message-ID: <486D9086.4080002@macports.org>

Hi Bill,

There haven't been any wiki change notification mails to 
macports-changes recently. I assume they got lost as you switched 
servers. Could you please re-enable them?

Thanks in advance,
Rainer

From jkh at apple.com  Thu Jul  3 21:45:20 2008
From: jkh at apple.com (Jordan K. Hubbard)
Date: Thu, 3 Jul 2008 21:45:20 -0700
Subject: MacPorts AutoBuild
In-Reply-To: <2AFAA476-7995-4C5B-8F76-D71EA42C256F@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>
Message-ID: <5BA0686A-EB83-4D30-AF09-F2F8A2B0FC6A@apple.com>


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.

- Jordan

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

From wsiegrist at apple.com  Thu Jul  3 23:06:27 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Thu, 03 Jul 2008 23:06:27 -0700
Subject: Wiki change notifications
In-Reply-To: <486D9086.4080002@macports.org>
References: <486D9086.4080002@macports.org>
Message-ID: <CA6F342B-71F9-4B3B-B79C-7245791AC33A@apple.com>

They were enabled earlier today.

-Bill


On Jul 3, 2008, at 7:52 PM, Rainer M?ller wrote:

> Hi Bill,
>
> There haven't been any wiki change notification mails to macports- 
> changes recently. I assume they got lost as you switched servers.  
> Could you please re-enable them?
>
> Thanks in advance,
> Rainer




----
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/20080703/bb179be0/attachment.bin 

From ram at macports.org  Thu Jul  3 23:25:59 2008
From: ram at macports.org (Adam Mercer)
Date: Fri, 4 Jul 2008 01:25:59 -0500
Subject: checking for swig variants in a pre-fetch hook
Message-ID: <799406d60807032325r7e164afam98ddedafa0cc8e9a@mail.gmail.com>

Hi

The recent changes to the swig port have broken the scipy build on
Tiger, essentially the problem is that scipy requires the python
variant of swig to be installed. Therefore to try and fix this I want
to check for existence of the python variant using something like the
following pre-fetch hook:

pre-fetch {
  if {![file exists ${prefix}/share/swig/1.3.36/python/python.swg]} {
    ui_error "The python variant of swig is not installed. Please run"
    ui_error "the following commands:"
    ui_error "$ sudo port uninstall swig"
    ui_error "$ sudo port install swig +python"
    error "python variant of swig required"
  }
}

The problem is that this is dependent on the swig version and will
need to be updated for every new swig release. I tried using a
wildcard for the version but this doesn't work. Is there any way that
I can check for this version dependent path in a version independent
way?

Cheers

Adam

From jmr at macports.org  Thu Jul  3 23:38:36 2008
From: jmr at macports.org (Joshua Root)
Date: Fri, 04 Jul 2008 16:38:36 +1000
Subject: checking for swig variants in a pre-fetch hook
In-Reply-To: <799406d60807032325r7e164afam98ddedafa0cc8e9a@mail.gmail.com>
References: <799406d60807032325r7e164afam98ddedafa0cc8e9a@mail.gmail.com>
Message-ID: <486DC56C.7020300@macports.org>

Adam Mercer wrote:
> Hi
> 
> The recent changes to the swig port have broken the scipy build on
> Tiger, essentially the problem is that scipy requires the python
> variant of swig to be installed. Therefore to try and fix this I want
> to check for existence of the python variant using something like the
> following pre-fetch hook:
> 
> pre-fetch {
>   if {![file exists ${prefix}/share/swig/1.3.36/python/python.swg]} {
>     ui_error "The python variant of swig is not installed. Please run"
>     ui_error "the following commands:"
>     ui_error "$ sudo port uninstall swig"
>     ui_error "$ sudo port install swig +python"
>     error "python variant of swig required"
>   }
> }
> 
> The problem is that this is dependent on the swig version and will
> need to be updated for every new swig release. I tried using a
> wildcard for the version but this doesn't work. Is there any way that
> I can check for this version dependent path in a version independent
> way?

Changing the if line to this should do it:

if {![llen [glob ${prefix}/share/swig/*/python/python.swg]]} {

- Josh

From florian.ebeling at gmail.com  Fri Jul  4 01:27:16 2008
From: florian.ebeling at gmail.com (Caspar Florian Ebeling)
Date: Fri, 4 Jul 2008 10:27:16 +0200
Subject: lang/ruby: ignore minor system version for archdir,
	like Apple's Ruby
In-Reply-To: <20080704063616180029.5b40ba6c@macports.org>
References: <20080704063616180029.5b40ba6c@macports.org>
Message-ID: <5cbbe4ae0807040127v2ce1e9e4w2196d23eaf241dfc@mail.gmail.com>

Hi Kimuraw,

welcome from my side as well!

> I'm planning to change the Portfile of lang/ruby to ignore minor
> system version for "archdir", like Apple's Ruby.
>
> Ruby uses "archdir" to define install destination of extension
> modules, such as "RMagick.bundle". I think it is not convenient
> to need to re-install ruby libraries (port:rb-*) which includes
> extension module(s) for minor upgrade of MacOS X.
>
> Please tell me your thoughts and issues about this change.

Sounds like a good idea to me.

> before:
>  10.4.11-> i686-darwin8.11.0
>  10.5.1 -> i686-darwin9.1.0
>  10.5.3 -> i686-darwin9.3.0
>
> after:
>  10.4.11-> i686-darwin8.0
>  10.5.1 -> i686-darwin9.0
>  10.5.3 -> i686-darwin9.0

Actually, one thing, what does the .0 stand for?
Wouldn't it be less confusing just to cut everything
off after the major version? Because the real Darwin
version is something else; there the teeny of OS X
becomes the minor of Darwin, like here 10.4.11 = 8.11,
10.5.4 = 9.4, etc. But this below would result in the same
behaviour and be true to Darwin numbers:

10.4.11-> i686-darwin8
10.5.1 -> i686-darwin9
10.5.3 -> i686-darwin9

Florian



-- 
Florian Ebeling
florian.ebeling at gmail.com

From jmr at macports.org  Fri Jul  4 08:23:40 2008
From: jmr at macports.org (Joshua Root)
Date: Sat, 05 Jul 2008 01:23:40 +1000
Subject: checking for swig variants in a pre-fetch hook
In-Reply-To: <799406d60807040817j544ee8f4o97968dbdac873525@mail.gmail.com>
References: <799406d60807032325r7e164afam98ddedafa0cc8e9a@mail.gmail.com>	
	<486DC56C.7020300@macports.org>
	<799406d60807040817j544ee8f4o97968dbdac873525@mail.gmail.com>
Message-ID: <486E407C.7000706@macports.org>

Adam Mercer wrote:
> On Fri, Jul 4, 2008 at 1:38 AM, Joshua Root <jmr at macports.org> wrote:
> 
>> Changing the if line to this should do it:
>>
>> if {![llen [glob ${prefix}/share/swig/*/python/python.swg]]} {
> 
> Using the above line only half works if a file doesn't satisfy the
> above pattern port errors out straight away, the different ui_error
> messages aren't displayed. I have the following in a pre-fetch hook:
> 
> pre-fetch {
>   if {![llen [glob ${prefix}/share/swig/*/python/python.swg]]} {
>     ui_error "The python variant of swig is not installed. Please run"
>     ui_error "the following commands:"
>     ui_error "$ sudo port uninstall swig"
>     ui_error "$ sudo port install swig +python"
>     error "python variant of swig required"
>   }
> }
> 
> then the only thing displayed on error is:
> 
> --->  Fetching py25-scipy
> Error: Target org.macports.fetch returned: no files matched glob
> pattern "/opt/local/share/swig/*/python/python.swg"
> Error: Status 1 encountered during processing.
> 
> How can I get the messages to display?

Ah, sorry, I forgot that glob errors if nothing matches. Add -nocomplain:

if {![llen [glob -nocomplain ${prefix}/share/swig/*/python/python.swg]]}

- Josh

From ram at macports.org  Fri Jul  4 08:36:48 2008
From: ram at macports.org (Adam Mercer)
Date: Fri, 4 Jul 2008 10:36:48 -0500
Subject: checking for swig variants in a pre-fetch hook
In-Reply-To: <486E407C.7000706@macports.org>
References: <799406d60807032325r7e164afam98ddedafa0cc8e9a@mail.gmail.com>
	<486DC56C.7020300@macports.org>
	<799406d60807040817j544ee8f4o97968dbdac873525@mail.gmail.com>
	<486E407C.7000706@macports.org>
Message-ID: <799406d60807040836x695ff0fajfed515fba9ecaeae@mail.gmail.com>

On Fri, Jul 4, 2008 at 10:23 AM, Joshua Root <jmr at macports.org> wrote:

Josh

> Ah, sorry, I forgot that glob errors if nothing matches. Add -nocomplain:
>
> if {![llen [glob -nocomplain ${prefix}/share/swig/*/python/python.swg]]}

Still not working quite right, the error is now:

--->  Fetching py25-scipy
Error: Target org.macports.fetch returned: invalid command name "llen"
Error: Status 1 encountered during processing.

removing the -nocomplain flag results in the previous error.

Cheers

Adam

From raimue at macports.org  Fri Jul  4 08:50:04 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Fri, 04 Jul 2008 17:50:04 +0200
Subject: checking for swig variants in a pre-fetch hook
In-Reply-To: <799406d60807040836x695ff0fajfed515fba9ecaeae@mail.gmail.com>
References: <799406d60807032325r7e164afam98ddedafa0cc8e9a@mail.gmail.com>	<486DC56C.7020300@macports.org>	<799406d60807040817j544ee8f4o97968dbdac873525@mail.gmail.com>	<486E407C.7000706@macports.org>
	<799406d60807040836x695ff0fajfed515fba9ecaeae@mail.gmail.com>
Message-ID: <486E46AC.6010605@macports.org>

Adam Mercer wrote:
> --->  Fetching py25-scipy
> Error: Target org.macports.fetch returned: invalid command name "llen"
> Error: Status 1 encountered during processing.

It should be [llength ...]

Rainer

From jmr at macports.org  Fri Jul  4 09:01:45 2008
From: jmr at macports.org (Joshua Root)
Date: Sat, 05 Jul 2008 02:01:45 +1000
Subject: checking for swig variants in a pre-fetch hook
In-Reply-To: <799406d60807040836x695ff0fajfed515fba9ecaeae@mail.gmail.com>
References: <799406d60807032325r7e164afam98ddedafa0cc8e9a@mail.gmail.com>	
	<486DC56C.7020300@macports.org>	
	<799406d60807040817j544ee8f4o97968dbdac873525@mail.gmail.com>	
	<486E407C.7000706@macports.org>
	<799406d60807040836x695ff0fajfed515fba9ecaeae@mail.gmail.com>
Message-ID: <486E4969.7050104@macports.org>

Adam Mercer wrote:
> On Fri, Jul 4, 2008 at 10:23 AM, Joshua Root <jmr at macports.org> wrote:
> 
> Josh
> 
>> Ah, sorry, I forgot that glob errors if nothing matches. Add -nocomplain:
>>
>> if {![llen [glob -nocomplain ${prefix}/share/swig/*/python/python.swg]]}
> 
> Still not working quite right, the error is now:
> 
> --->  Fetching py25-scipy
> Error: Target org.macports.fetch returned: invalid command name "llen"
> Error: Status 1 encountered during processing.
> 
> removing the -nocomplain flag results in the previous error.

Oh right, Tcl doesn't let you do that with the ! operator. Either 
compare the length to 0 like so:

if {[llen [glob -nocomplain ${prefix}/share/swig/*/python/python.swg]] 
== 0} {

or remove the -nocomplain and just catch the error:

if {[catch {glob ${prefix}/share/swig/*/python/python.swg}]} {

- Josh

From ram at macports.org  Fri Jul  4 09:08:07 2008
From: ram at macports.org (Adam Mercer)
Date: Fri, 4 Jul 2008 11:08:07 -0500
Subject: checking for swig variants in a pre-fetch hook
In-Reply-To: <486E46AC.6010605@macports.org>
References: <799406d60807032325r7e164afam98ddedafa0cc8e9a@mail.gmail.com>
	<486DC56C.7020300@macports.org>
	<799406d60807040817j544ee8f4o97968dbdac873525@mail.gmail.com>
	<486E407C.7000706@macports.org>
	<799406d60807040836x695ff0fajfed515fba9ecaeae@mail.gmail.com>
	<486E46AC.6010605@macports.org>
Message-ID: <799406d60807040908v205d9eecs4d139f87e4dc188e@mail.gmail.com>

On Fri, Jul 4, 2008 at 10:50 AM, Rainer M?ller <raimue at macports.org> wrote:

> It should be [llength ...]

Thanks Rainer, that does the job.

Cheers

Adam

From landonf at macports.org  Fri Jul  4 10:08:21 2008
From: landonf at macports.org (Landon Fuller)
Date: Fri, 4 Jul 2008 10:08:21 -0700
Subject: checking for swig variants in a pre-fetch hook
In-Reply-To: <799406d60807032325r7e164afam98ddedafa0cc8e9a@mail.gmail.com>
References: <799406d60807032325r7e164afam98ddedafa0cc8e9a@mail.gmail.com>
Message-ID: <0CC1673C-ECA7-426B-AF87-C70AFC1A93A2@macports.org>


On Jul 3, 2008, at 11:25 PM, Adam Mercer wrote:

> The recent changes to the swig port have broken the scipy build on
> Tiger, essentially the problem is that scipy requires the python
> variant of swig to be installed.


Swig's variants:
	swig 1.3.36, devel/swig (Variants: universal, doc, python, perl, gcj,  
guile, mzscheme, ruby, php4, ocaml, pike, lua, chicken, allegro,  
clisp, r)

Why not enable some of these by default? Having none of them enabled  
makes swig useless, seems like defaulting to:
	- python
	- perl
	- ruby
	- php4

Would be a good start.

-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/20080704/35a991b2/attachment.bin 

From ryandesign at macports.org  Fri Jul  4 11:22:53 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 4 Jul 2008 13:22:53 -0500
Subject: checking for swig variants in a pre-fetch hook
In-Reply-To: <0CC1673C-ECA7-426B-AF87-C70AFC1A93A2@macports.org>
References: <799406d60807032325r7e164afam98ddedafa0cc8e9a@mail.gmail.com>
	<0CC1673C-ECA7-426B-AF87-C70AFC1A93A2@macports.org>
Message-ID: <7C4010BC-5101-43C7-A1AE-BB1E41D1AC07@macports.org>

On Jul 4, 2008, at 12:08, Landon Fuller wrote:

> On Jul 3, 2008, at 11:25 PM, Adam Mercer wrote:
>
>> The recent changes to the swig port have broken the scipy build on
>> Tiger, essentially the problem is that scipy requires the python
>> variant of swig to be installed.
>
> Swig's variants:
> 	swig 1.3.36, devel/swig (Variants: universal, doc, python, perl,  
> gcj, guile, mzscheme, ruby, php4, ocaml, pike, lua, chicken,  
> allegro, clisp, r)
>
> Why not enable some of these by default? Having none of them  
> enabled makes swig useless, seems like defaulting to:
> 	- python
> 	- perl
> 	- ruby
> 	- php4
>
> Would be a good start.

Why is there a php4 variant but not a php5 variant?

Enabling php4 by default would cause all swig users to have to  
install php4. php4 is pretty much obsolete. The last normal release  
of php4 was made 2008-01-03 and after 2008-08-08 there will be no  
more releases of php4 at all. php5 is the current version. php5 and  
php4 cannot be installed at the same time (with the way the ports are  
set up currently).



From ryandesign at macports.org  Fri Jul  4 12:28:05 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 4 Jul 2008 14:28:05 -0500
Subject: [38055] trunk/dports/lang/swi-prolog/Portfile
In-Reply-To: <20080704182047.5EB1010BE83@beta.macosforge.org>
References: <20080704182047.5EB1010BE83@beta.macosforge.org>
Message-ID: <CEEA9D57-DCA3-4ACA-9FE4-3E73B08BDC3A@macports.org>

On Jul 4, 2008, at 13:20, gwright at macports.org wrote:

> Revision: 38055
>           http://trac.macosforge.org/projects/macports/changeset/38055
> Author:   gwright at macports.org
> Date:     2008-07-04 11:20:46 -0700 (Fri, 04 Jul 2008)
> Log Message:
> -----------
> Version bump to 5.6.57.
>
> Modified Paths:
> --------------
>     trunk/dports/lang/swi-prolog/Portfile
>
> Modified: trunk/dports/lang/swi-prolog/Portfile
> ===================================================================
> --- trunk/dports/lang/swi-prolog/Portfile	2008-07-04 18:17:29 UTC  
> (rev 38054)
> +++ trunk/dports/lang/swi-prolog/Portfile	2008-07-04 18:20:46 UTC  
> (rev 38055)
> @@ -3,7 +3,7 @@
>  PortSystem	1.0
>
>  name		swi-prolog
> -version		5.6.55
> +version		5.6.57
>  epoch		20051223
>
>  categories	lang
> @@ -25,19 +25,21 @@
>  homepage	http://www.swi-prolog.org/
>  master_sites	http://gollem.science.uva.nl/cgi-bin/nph-download/SWI- 
> Prolog/
>
> -checksums	md5     5710bc10a72a285a4cdf55924b6987e0
> +checksums	md5     c41709e50dbcd784f26273a1686af9e8 \
> +		sha1    30c1e45dbe1d8d963599059394a8fa3228c8fbca \
> +		rmd160  3c5a699b4528cb1272c6ba77acceb17bf5ba8703
>
>  depends_build   \
>  	port:gawk	\
>  	port:junit
>
>  depends_lib		\
> -	port:readline				\
> +	port:readline			\
>  	lib:libncursesw:ncurses		\
> -	lib:libjpeg:jpeg			\
> +	lib:libjpeg:jpeg		\
>  	lib:libmcrypt:libmcrypt		\
>  	lib:libX11.6:XFree86		\
> -	lib:libgmp:gmp				\
> +	lib:libgmp:gmp			\
>  	lib:libzlib:zlib

There isn't a "libzlib" (it's called "libz"). But you should use  
port:-style dependencies anyway, not lib:-style (except for  
lib:libX11.6:XFree86 which should stay as it is so that it can use  
Apple's X11 instead of XFree86). For the other dependencies, we  
always want the MacPorts versions used, never another version the  
user might have installed.

>  platform darwin 6 {
> @@ -51,19 +53,19 @@
>  distname	pl-${version}
>
>  configure.env	\
> -	LIBRARY_PATH=/usr/lib:/usr/X11R6/lib:${prefix}/lib 		\
> +	LIBRARY_PATH=/usr/lib:/usr/X11R6/lib:${prefix}/lib 	\
>  	CPATH=/usr/include:/usr/X11R6/include:${prefix}/include	\

Should use ${x11prefix} instead of hardcoding /usr/X11R6.

I'm not clear on why LIBRARY_PATH and CPATH are needed here. /usr/lib  
and /usr/include are surely already there by default. And MacPorts  
already puts -L${prefix}/lib into LDFLAGS and -I${prefix}/include  
into CPPFLAGS which should serve the same purpose. Maybe all you need  
to do is add -L${x11prefix}/lib to LDFLAGS and -I${x11prefix}/include  
to CPPFLAGS (using configure.ldflags-append and configure.cppflags- 
append). I have not tested this however.

>  	JUNIT=${prefix}/share/java/junit.jar
>
>  configure.ldflags

Ah, I see, you're deleting the LDFLAGS here. If you found that to be  
necessary, then very well.

>  configure.args	\
> -	--prefix=${prefix}				\
> +	--prefix=${prefix}		\

Do not need to have --prefix=${prefix} in the configure.args because  
it is already in the configure.pre_args by default. This applies to  
swi-prolog-lite too.

>  	--mandir=${prefix}/share/man	\
>  	--with-world
>
>  build.env	\
> -	LIBRARY_PATH=/usr/lib:/usr/X11R6/lib:${prefix}/lib		\
> +	LIBRARY_PATH=/usr/lib:/usr/X11R6/lib:${prefix}/lib	\
>  	CPATH=/usr/include:/usr/X11R6/include:${prefix}/include	\

Same comment as for configure.env above. You may want to just set  
build.env to configure.env to save yourself from having to duplicate  
this information.


From jkh at apple.com  Fri Jul  4 13:04:08 2008
From: jkh at apple.com (Jordan K. Hubbard)
Date: Fri, 4 Jul 2008 13:04:08 -0700
Subject: checking for swig variants in a pre-fetch hook
In-Reply-To: <486E4969.7050104@macports.org>
References: <799406d60807032325r7e164afam98ddedafa0cc8e9a@mail.gmail.com>
	<486DC56C.7020300@macports.org>
	<799406d60807040817j544ee8f4o97968dbdac873525@mail.gmail.com>
	<486E407C.7000706@macports.org>
	<799406d60807040836x695ff0fajfed515fba9ecaeae@mail.gmail.com>
	<486E4969.7050104@macports.org>
Message-ID: <779813A4-ED66-4175-A2F8-D445F3C95263@apple.com>


On Jul 4, 2008, at 9:01 AM, Joshua Root wrote:

>>> if {![llen [glob -nocomplain ${prefix}/share/swig/*/python/ 
>>> python.swg]]}
>>
>> Still not working quite right, the error is now:
>>
>> --->  Fetching py25-scipy
>> Error: Target org.macports.fetch returned: invalid command name  
>> "llen"
>> Error: Status 1 encountered during processing.
>>
>> removing the -nocomplain flag results in the previous error.
>
> Oh right, Tcl doesn't let you do that with the ! operator. Either
> compare the length to 0 like so:

Hmmm?

% if {![llen {}]} {puts "empty"} else {puts "not empty"}
empty
% if {![llen {one two}]} {puts "empty"} else {puts "not empty"}
not empty

I'm not sure why Adam sees that particular error (I don't know the  
containing expression) but you're also right in saying that catching  
the glob is probably the most straight-forward approach.  I just don't  
like to see Tcl's operators unfairly maligned like this. :-)

- Jordan


From jkh at apple.com  Fri Jul  4 13:07:14 2008
From: jkh at apple.com (Jordan K. Hubbard)
Date: Fri, 4 Jul 2008 13:07:14 -0700
Subject: checking for swig variants in a pre-fetch hook
In-Reply-To: <779813A4-ED66-4175-A2F8-D445F3C95263@apple.com>
References: <799406d60807032325r7e164afam98ddedafa0cc8e9a@mail.gmail.com>
	<486DC56C.7020300@macports.org>
	<799406d60807040817j544ee8f4o97968dbdac873525@mail.gmail.com>
	<486E407C.7000706@macports.org>
	<799406d60807040836x695ff0fajfed515fba9ecaeae@mail.gmail.com>
	<486E4969.7050104@macports.org>
	<779813A4-ED66-4175-A2F8-D445F3C95263@apple.com>
Message-ID: <EF871123-710C-4576-AD50-247F764D9265@apple.com>

Doh, I hate it when tcl "helps" by automatically intuiting command  
names at the shell!   Rainer is, of course, correct:  The correct  
command name is llength, not llen, hence the problem.  My face is red...

- Jordan

On Jul 4, 2008, at 1:04 PM, Jordan K. Hubbard wrote:

>
> On Jul 4, 2008, at 9:01 AM, Joshua Root wrote:
>
>>>> if {![llen [glob -nocomplain ${prefix}/share/swig/*/python/ 
>>>> python.swg]]}
>>>
>>> Still not working quite right, the error is now:
>>>
>>> --->  Fetching py25-scipy
>>> Error: Target org.macports.fetch returned: invalid command name  
>>> "llen"
>>> Error: Status 1 encountered during processing.
>>>
>>> removing the -nocomplain flag results in the previous error.
>>
>> Oh right, Tcl doesn't let you do that with the ! operator. Either
>> compare the length to 0 like so:
>
> Hmmm?
>
> % if {![llen {}]} {puts "empty"} else {puts "not empty"}
> empty
> % if {![llen {one two}]} {puts "empty"} else {puts "not empty"}
> not empty
>
> I'm not sure why Adam sees that particular error (I don't know the  
> containing expression) but you're also right in saying that catching  
> the glob is probably the most straight-forward approach.  I just  
> don't like to see Tcl's operators unfairly maligned like this. :-)
>
> - Jordan
>


From jmr at macports.org  Fri Jul  4 13:57:46 2008
From: jmr at macports.org (Joshua Root)
Date: Sat, 05 Jul 2008 06:57:46 +1000
Subject: checking for swig variants in a pre-fetch hook
In-Reply-To: <EF871123-710C-4576-AD50-247F764D9265@apple.com>
References: <799406d60807032325r7e164afam98ddedafa0cc8e9a@mail.gmail.com>
	<486DC56C.7020300@macports.org>
	<799406d60807040817j544ee8f4o97968dbdac873525@mail.gmail.com>
	<486E407C.7000706@macports.org>
	<799406d60807040836x695ff0fajfed515fba9ecaeae@mail.gmail.com>
	<486E4969.7050104@macports.org>
	<779813A4-ED66-4175-A2F8-D445F3C95263@apple.com>
	<EF871123-710C-4576-AD50-247F764D9265@apple.com>
Message-ID: <486E8ECA.8010500@macports.org>

Jordan K. Hubbard wrote:
> Doh, I hate it when tcl "helps" by automatically intuiting command names 
> at the shell!   Rainer is, of course, correct:  The correct command name 
> is llength, not llen, hence the problem.  My face is red...

Indeed, it fooled me as well.

- Josh

From ryandesign at macports.org  Fri Jul  4 19:30:17 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 4 Jul 2008 21:30:17 -0500
Subject: [38038] trunk/base/src/port1.0/portextract.tcl
In-Reply-To: <20080704043057.1005E10A2D7@beta.macosforge.org>
References: <20080704043057.1005E10A2D7@beta.macosforge.org>
Message-ID: <76E88124-6F0F-4CFA-B7C9-AC58171DB219@macports.org>

On Jul 3, 2008, at 23:30, raimue at macports.org wrote:

> Revision: 38038
>           http://trac.macosforge.org/projects/macports/changeset/38038
> Author:   raimue at macports.org
> Date:     2008-07-03 21:30:56 -0700 (Thu, 03 Jul 2008)
> Log Message:
> -----------
> port1.0/portextract.tcl:
> If the $distfile exists in $filespath, use it from there as it was  
> not fetched
> to the distpath in this case.

Why would the distfile be in the filespath?


> Modified Paths:
> --------------
>     trunk/base/src/port1.0/portextract.tcl
>
> Modified: trunk/base/src/port1.0/portextract.tcl
> ===================================================================
> --- trunk/base/src/port1.0/portextract.tcl	2008-07-04 02:58:10 UTC  
> (rev 38037)
> +++ trunk/base/src/port1.0/portextract.tcl	2008-07-04 04:30:56 UTC  
> (rev 38038)
> @@ -92,7 +92,7 @@
>  }
>
>  proc extract_main {args} {
> -    global UI_PREFIX
> +    global UI_PREFIX filespath
>
>      if {![exists distfiles] && ![exists extract.only]} {
>  	# nothing to do
> @@ -101,7 +101,11 @@
>
>      foreach distfile [option extract.only] {
>  	ui_info "$UI_PREFIX [format [msgcat::mc "Extracting %s"] $distfile]"
> -	option extract.args "[option distpath]/$distfile"
> +	if {[file exists $filespath/$distfile]} {
> +		option extract.args "$filespath/$distfile"
> +	} else {
> +		option extract.args "[option distpath]/$distfile"
> +	}
>  	if {[catch {command_exec extract} result]} {
>  	    return -code error "$result"
>  	}



From raimue at macports.org  Fri Jul  4 19:37:07 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 05 Jul 2008 04:37:07 +0200
Subject: [38038] trunk/base/src/port1.0/portextract.tcl
In-Reply-To: <76E88124-6F0F-4CFA-B7C9-AC58171DB219@macports.org>
References: <20080704043057.1005E10A2D7@beta.macosforge.org>
	<76E88124-6F0F-4CFA-B7C9-AC58171DB219@macports.org>
Message-ID: <486EDE53.4090404@macports.org>

Ryan Schmidt wrote:
> On Jul 3, 2008, at 23:30, raimue at macports.org wrote:
> 
>> Revision: 38038
>>           http://trac.macosforge.org/projects/macports/changeset/38038
>> Author:   raimue at macports.org
>> Date:     2008-07-03 21:30:56 -0700 (Thu, 03 Jul 2008)
>> Log Message:
>> -----------
>> port1.0/portextract.tcl:
>> If the $distfile exists in $filespath, use it from there as it was  
>> not fetched
>> to the distpath in this case.
> 
> Why would the distfile be in the filespath?

'port fetch' checks first if the distfile exists in $filespath and does 
not fetch it to $distpath if it exists there. So 'port fetch' was able 
to work with a distfile in $filespath, but 'port extract' was not.

I did this change for consistency. We could also remove the check for 
the distfile in $filespath in portfetch, but I think that would apply to 
patchfiles as well which are often in $filespath.

Rainer

From kimuraw at macports.org  Fri Jul  4 23:20:38 2008
From: kimuraw at macports.org (kimura wataru)
Date: Sat, 5 Jul 2008 15:20:38 +0900
Subject: lang/ruby: ignore minor system version for archdir, like
	Apple's Ruby
In-Reply-To: <5cbbe4ae0807040127v2ce1e9e4w2196d23eaf241dfc@mail.gmail.com>
References: <20080704063616180029.5b40ba6c@macports.org>
	<5cbbe4ae0807040127v2ce1e9e4w2196d23eaf241dfc@mail.gmail.com>
Message-ID: <20080705152038493272.c09fa640@macports.org>

Hi Florian,

On Fri, 4 Jul 2008 10:27:16 +0200, Caspar Florian Ebeling wrote:
> Actually, one thing, what does the .0 stand for?
> Wouldn't it be less confusing just to cut everything
> off after the major version? Because the real Darwin
> version is something else; there the teeny of OS X
> becomes the minor of Darwin, like here 10.4.11 = 8.11,
> 10.5.4 = 9.4, etc. But this below would result in the same
> behaviour and be true to Darwin numbers:
> 
> 10.4.11-> i686-darwin8
> 10.5.1 -> i686-darwin9
> 10.5.3 -> i686-darwin9
> 
> Florian
> 

I agree. I comitted this change with your suggestion as r38064.
http://trac.macports.org/changeset/38064

Thanks!

-- 
kimura wataru

From dgou at mac.com  Sat Jul  5 11:14:30 2008
From: dgou at mac.com (Douglas Philips)
Date: Sat, 05 Jul 2008 14:14:30 -0400
Subject: py25-gtk dependency oddity?
Message-ID: <534FD25B-4CF6-42D4-9198-75FE39CEA765@mac.com>

I'm running Leopard (10.5.3) on a 2.4Ghz dual core.
When I went to install py25-gtk, I got this message:
Error: Some libs are missing from your X11 installation. Please run  
this command:
Error: sudo ln -s libXrandr.2.dylib /usr/X11/lib/libXrandr.2.0.0.dylib
Error: Target org.macports.fetch returned: missing /usr/X11/lib/ 
libXrandr.2.0.0.dylib
When I looked in /usr/X11/lib/ I found a libXrandr.2.1.0.dylib  
symlinked to the libXrandr.2.dylib and am wondering if the version  
check py25-gtk is doing is out of date?
I went ahead and made the symbolic link it asked for and it is in the  
middle of a build now.
Just wanted to ask if this was expected/desired behaviour, or if the  
port is slightly out of date? (nomaintainer at macports.org and  
all... :) ).

Thanks,
	--Doug


From 0x62_0x6c_0x62 at pobox.com  Sat Jul  5 14:37:21 2008
From: 0x62_0x6c_0x62 at pobox.com (Bryan Blackburn)
Date: Sat, 5 Jul 2008 15:37:21 -0600
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: <EABBC23C-E9B2-4768-9E4E-8517EC7FCE5E@pobox.com>

On Jul 3, 2008, at 10:45 PM, 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.
>

At the moment, no, just the tarball on the wiki.

Bryan


> - Jordan
>


From ryandesign at macports.org  Sat Jul  5 14:45:33 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 5 Jul 2008 16:45:33 -0500
Subject: [38067] trunk/dports/lang
In-Reply-To: <20080705132402.03E0C10DBFF@beta.macosforge.org>
References: <20080705132402.03E0C10DBFF@beta.macosforge.org>
Message-ID: <0673C620-EFCE-47C3-9EC2-212CEEEA2940@macports.org>

On Jul 5, 2008, at 08:24, raimue at macports.org wrote:

> Revision: 38067
>           http://trac.macosforge.org/projects/macports/changeset/38067
> Author:   raimue at macports.org
> Date:     2008-07-05 06:24:00 -0700 (Sat, 05 Jul 2008)
> Log Message:
> -----------
> lang/perl5.8, lang/perl5.10:
> Add a perl binary with major version, bin/perl5.8 and bin/perl5.10
>
> Modified Paths:
> --------------
>     trunk/dports/lang/perl5.10/Portfile
>     trunk/dports/lang/perl5.8/Portfile


> +    ln -s ${prefix}/bin/perl${version} ${destroot}${prefix}/bin/$name

Wouldn't a relative link have sufficed or is an absolute reference  
necessary? Just curious.

ln -s perl${version} ${destroot}${prefix}/bin/$name



From randall.h.wood at alexandriasoftware.com  Sun Jul  6 01:50:12 2008
From: randall.h.wood at alexandriasoftware.com (Randall Wood)
Date: Sun, 6 Jul 2008 04:50:12 -0400
Subject: gtk28
Message-ID: <c24012060807060150j52dc7bb9vdcf42a323c4e9ab6@mail.gmail.com>

Is there any objection to removing this port entirely? There are no
dependencies on it. There is an open bug on it, but it does not seem
worth fixing.

-- 
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 randall.h.wood at alexandriasoftware.com  Sun Jul  6 02:15:23 2008
From: randall.h.wood at alexandriasoftware.com (Randall Wood)
Date: Sun, 6 Jul 2008 05:15:23 -0400
Subject: Good news
Message-ID: <c24012060807060215x20b1b9a0q1bf060f7ad2ecfe4@mail.gmail.com>

A quote from the Mozilla Developers[1]:

"There are two package management systems that are compatible with the
Mozilla build system, Fink and MacPorts (formerly DarwinPorts). Note
that package installation may be a time-consuming but automated
process using either tool.

MacPorts, formerly DarwinPorts. You may download the MacPorts
installer corresponding to your operating system release. MacPorts
installs in /opt/local by default. After running the MacPorts
installer, the changes that it makes to the shell environment will be
available in any new Terminal window.

fink (not recommended)."

[1]: http://developer.mozilla.org/en/docs/Mac_OS_X_Build_Prerequisites

-- 
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 raimue at macports.org  Sun Jul  6 05:06:56 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sun, 06 Jul 2008 14:06:56 +0200
Subject: [38067] trunk/dports/lang
In-Reply-To: <0673C620-EFCE-47C3-9EC2-212CEEEA2940@macports.org>
References: <20080705132402.03E0C10DBFF@beta.macosforge.org>
	<0673C620-EFCE-47C3-9EC2-212CEEEA2940@macports.org>
Message-ID: <4870B560.6040907@macports.org>

Ryan Schmidt wrote:
>> +    ln -s ${prefix}/bin/perl${version} ${destroot}${prefix}/bin/$name
> 
> Wouldn't a relative link have sufficed or is an absolute reference  
> necessary? Just curious.
> 
> ln -s perl${version} ${destroot}${prefix}/bin/$name

Right, that should have been sufficient as well. But should I change it 
now and increment the revision one more time?

There are also other ports using absolute paths for symlinks and I don't 
think it is wrong to do so. The ${prefix} is not intended to be 
relocatable. Do you see any problem with absolute symlink paths?

For example from my MacPorts installation:
$ find /opt/local/bin -type l |wc -l
      200
$ find /opt/local/bin -type l |xargs readlink |grep ^/opt/local |wc -l
       60

Rainer

From jwa at macports.org  Sun Jul  6 05:32:18 2008
From: jwa at macports.org (Jyrki Wahlstedt)
Date: Sun, 6 Jul 2008 15:32:18 +0300
Subject: checking for swig variants in a pre-fetch hook
In-Reply-To: <7C4010BC-5101-43C7-A1AE-BB1E41D1AC07@macports.org>
References: <799406d60807032325r7e164afam98ddedafa0cc8e9a@mail.gmail.com>
	<0CC1673C-ECA7-426B-AF87-C70AFC1A93A2@macports.org>
	<7C4010BC-5101-43C7-A1AE-BB1E41D1AC07@macports.org>
Message-ID: <84E75B62-844D-43B8-9AF0-9813C08DA71C@macports.org>


On 4.7.2008, at 21.22, Ryan Schmidt wrote:

> On Jul 4, 2008, at 12:08, Landon Fuller wrote:
>
>> On Jul 3, 2008, at 11:25 PM, Adam Mercer wrote:
>>
>>> The recent changes to the swig port have broken the scipy build on
>>> Tiger, essentially the problem is that scipy requires the python
>>> variant of swig to be installed.
>>
>> Swig's variants:
>> 	swig 1.3.36, devel/swig (Variants: universal, doc, python, perl,  
>> gcj, guile, mzscheme, ruby, php4, ocaml, pike, lua, chicken,  
>> allegro, clisp, r)
>>
>> Why not enable some of these by default? Having none of them  
>> enabled makes swig useless, seems like defaulting to:
>> 	- python
>> 	- perl
>> 	- ruby
>> 	- php4
>>
>> Would be a good start.
>
> Why is there a php4 variant but not a php5 variant?
>
> Enabling php4 by default would cause all swig users to have to  
> install php4. php4 is pretty much obsolete. The last normal release  
> of php4 was made 2008-01-03 and after 2008-08-08 there will be no  
> more releases of php4 at all. php5 is the current version. php5 and  
> php4 cannot be installed at the same time (with the way the ports  
> are set up currently).
>
>
Hi,
this is definitely something that has to be taken care of. I'll look  
into it asap.

!
! Jyrki Wahlstedt
!	http://www.wahlstedt.fi/jyrki/
!
! Our life is no dream; but it ought to become one and perhaps will.
! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0  A780  
6366 EFD9 139C C386




From frstan at bellsouth.net  Sun Jul  6 07:29:37 2008
From: frstan at bellsouth.net (William Davis)
Date: Sun, 6 Jul 2008 10:29:37 -0400
Subject: Good news
In-Reply-To: <c24012060807060215x20b1b9a0q1bf060f7ad2ecfe4@mail.gmail.com>
References: <c24012060807060215x20b1b9a0q1bf060f7ad2ecfe4@mail.gmail.com>
Message-ID: <845F1884-35EE-4AD9-AE95-92DE643998BE@bellsouth.net>

Randall, given that ringing endorsement, don't you think we ought to  
FIX the INSTALL error?
We may get a lot of new people trying MacPorts out who are not on this  
list.......
Wm Davis
On Jul 6, 2008, at 5:15 AM, Randall Wood wrote:

> A quote from the Mozilla Developers[1]:
>
> "There are two package management systems that are compatible with the
> Mozilla build system, Fink and MacPorts (formerly DarwinPorts). Note
> that package installation may be a time-consuming but automated
> process using either tool.
>
> MacPorts, formerly DarwinPorts. You may download the MacPorts
> installer corresponding to your operating system release. MacPorts
> installs in /opt/local by default. After running the MacPorts
> installer, the changes that it makes to the shell environment will be
> available in any new Terminal window.
>
> fink (not recommended)."
>
> [1]: http://developer.mozilla.org/en/docs/Mac_OS_X_Build_Prerequisites
>
> -- 
> 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 Davis
frstanATbellsouthDOTnet
Mac OS X.5.4 Darwin 9.4.0
Xquartz 2.2.3 - (xorg-server 1.3.0-apple21)
Mac Mini Intel Duo @ 1.86 GHz

Mundus vult decepi, ego non


From randall.h.wood at alexandriasoftware.com  Sun Jul  6 09:34:00 2008
From: randall.h.wood at alexandriasoftware.com (Randall Wood)
Date: Sun, 6 Jul 2008 12:34:00 -0400
Subject: Good news
In-Reply-To: <845F1884-35EE-4AD9-AE95-92DE643998BE@bellsouth.net>
References: <c24012060807060215x20b1b9a0q1bf060f7ad2ecfe4@mail.gmail.com>
	<845F1884-35EE-4AD9-AE95-92DE643998BE@bellsouth.net>
Message-ID: <c24012060807060934q50994537s97ccad9d9fc32c1a@mail.gmail.com>

On Sun, Jul 6, 2008 at 10:29 AM, William Davis <frstan at bellsouth.net> wrote:
> Randall, given that ringing endorsement, don't you think we ought to FIX the
> INSTALL error?

YES. Although that same page documents the install error...

> We may get a lot of new people trying MacPorts out who are not on this
> list.......
> Wm Davis
> On Jul 6, 2008, at 5:15 AM, Randall Wood wrote:
>
>> A quote from the Mozilla Developers[1]:
>>
>> "There are two package management systems that are compatible with the
>> Mozilla build system, Fink and MacPorts (formerly DarwinPorts). Note
>> that package installation may be a time-consuming but automated
>> process using either tool.
>>
>> MacPorts, formerly DarwinPorts. You may download the MacPorts
>> installer corresponding to your operating system release. MacPorts
>> installs in /opt/local by default. After running the MacPorts
>> installer, the changes that it makes to the shell environment will be
>> available in any new Terminal window.
>>
>> fink (not recommended)."
>>
>> [1]: http://developer.mozilla.org/en/docs/Mac_OS_X_Build_Prerequisites
>>
>> --
>> 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 Davis
> frstanATbellsouthDOTnet
> Mac OS X.5.4 Darwin 9.4.0
> Xquartz 2.2.3 - (xorg-server 1.3.0-apple21)
> Mac Mini Intel Duo @ 1.86 GHz
>
> Mundus vult decepi, ego non
>
>



-- 
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  Sun Jul  6 12:52:39 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 6 Jul 2008 14:52:39 -0500
Subject: [38067] trunk/dports/lang
In-Reply-To: <4870B560.6040907@macports.org>
References: <20080705132402.03E0C10DBFF@beta.macosforge.org>
	<0673C620-EFCE-47C3-9EC2-212CEEEA2940@macports.org>
	<4870B560.6040907@macports.org>
Message-ID: <92FEBABB-F27B-4FAB-B1E3-3C7923A55994@macports.org>

On Jul 6, 2008, at 07:06, Rainer M?ller wrote:

> Ryan Schmidt wrote:
>>> +    ln -s ${prefix}/bin/perl${version} ${destroot}${prefix}/bin/ 
>>> $name
>>
>> Wouldn't a relative link have sufficed or is an absolute reference
>> necessary? Just curious.
>>
>> ln -s perl${version} ${destroot}${prefix}/bin/$name
>
> Right, that should have been sufficient as well. But should I  
> change it
> now and increment the revision one more time?
>
> There are also other ports using absolute paths for symlinks and I  
> don't
> think it is wrong to do so. The ${prefix} is not intended to be
> relocatable. Do you see any problem with absolute symlink paths?
>
> For example from my MacPorts installation:
> $ find /opt/local/bin -type l |wc -l
>       200
> $ find /opt/local/bin -type l |xargs readlink |grep ^/opt/local |wc -l
>        60


In /usr/bin Apple provides some symlinks to other items in /usr/bin,  
and on Tiger, 31 of these are relative while 5 are absolute.

$ find /usr/bin -type l |xargs readlink |grep -v / |wc -l
       31
$ find /usr/bin -type l |xargs readlink |grep ^/usr/bin |wc -l
        5

It seems to me that relative symlinks would be better... For testing  
I installed Leopard on a separate partition, and from Leopard, I  
wanted to update my MacPorts working copy, but I had already updated  
it to Subversion 1.5 format and Leopard only comes with Subversion  
1.4.x. I was able to use the Subversion I had installed in Tiger's  
MacPorts installation like this:

DYLD_LIBRARY_PATH=/Volumes/tiger/mp/lib:/Volumes/tiger/mp/lib/db46 / 
Volumes/tiger/mp/bin/svn up

If svn had been an absolute symlink to /mp/bin/something then this  
would not have worked, but a relative symlink would have worked.  
Somewhat hypothetical situation, I know, but if I had been trying to  
run my Tiger's perl from Leopard I might have run into the problem.


On the other hand, I have one bug report saying that relative  
symlinks are bad, though I did not understand why and the reporter  
did not clarify:

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



From ryandesign at macports.org  Sun Jul  6 17:15:20 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 6 Jul 2008 19:15:20 -0500
Subject: [38109] trunk/base
In-Reply-To: <20080706202749.750C0112476@beta.macosforge.org>
References: <20080706202749.750C0112476@beta.macosforge.org>
Message-ID: <1C9F86B4-0CEC-4A36-8C07-289B5D74BA2A@macports.org>

On Jul 6, 2008, at 15:27, raimue at macports.org wrote:

> Revision: 38109
>           http://trac.macosforge.org/projects/macports/changeset/38109
> Author:   raimue at macports.org
> Date:     2008-07-06 13:27:48 -0700 (Sun, 06 Jul 2008)
> Log Message:
> -----------
> base:
> Add a new setupenv.sh script which can be used to setup the  
> environment for
> MacPorts. It will be installed to ${prefix}/share/macports/ 
> setupenv.sh and can
> be sourced from your profile.


Great! You read my mind.

Now does this work for tcsh too or just for bash?


From raimue at macports.org  Sun Jul  6 17:39:29 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Mon, 07 Jul 2008 02:39:29 +0200
Subject: [38109] trunk/base
In-Reply-To: <1C9F86B4-0CEC-4A36-8C07-289B5D74BA2A@macports.org>
References: <20080706202749.750C0112476@beta.macosforge.org>
	<1C9F86B4-0CEC-4A36-8C07-289B5D74BA2A@macports.org>
Message-ID: <487165C1.3070008@macports.org>

Ryan Schmidt wrote:
> Now does this work for tcsh too or just for bash?

This is for bash only. I assume the majority of users have bash as 
default shell.

I don't think we can write a script which will work with all shells out 
there, so additional versions for tcsh/zsh/ksh/... are welcomed.

I renamed the file to setupenv.bash in r38114 to reflect this.

Rainer

From ryandesign at macports.org  Sun Jul  6 19:23:16 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 6 Jul 2008 21:23:16 -0500
Subject: [38109] trunk/base
In-Reply-To: <487165C1.3070008@macports.org>
References: <20080706202749.750C0112476@beta.macosforge.org>
	<1C9F86B4-0CEC-4A36-8C07-289B5D74BA2A@macports.org>
	<487165C1.3070008@macports.org>
Message-ID: <1B079DDD-828F-4CF7-85F1-7119A6B89172@macports.org>


On Jul 6, 2008, at 19:39, Rainer M?ller wrote:

> Ryan Schmidt wrote:
>> Now does this work for tcsh too or just for bash?
>
> This is for bash only. I assume the majority of users have bash as
> default shell.

Probably, but users who upgraded from Mac OS X 10.1.x or earlier  
could still have tcsh as their default shell, and we should support  
that.

> I don't think we can write a script which will work with all shells  
> out
> there, so additional versions for tcsh/zsh/ksh/... are welcomed.
>
> I renamed the file to setupenv.bash in r38114 to reflect this.


From ryandesign at macports.org  Sun Jul  6 23:53:35 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 7 Jul 2008 01:53:35 -0500
Subject: [38038] trunk/base/src/port1.0/portextract.tcl
In-Reply-To: <486EDE53.4090404@macports.org>
References: <20080704043057.1005E10A2D7@beta.macosforge.org>
	<76E88124-6F0F-4CFA-B7C9-AC58171DB219@macports.org>
	<486EDE53.4090404@macports.org>
Message-ID: <F8048992-E80A-4689-B8E8-97E277851229@macports.org>


On Jul 4, 2008, at 21:37, Rainer M?ller wrote:

> Ryan Schmidt wrote:
>
>> On Jul 3, 2008, at 23:30, raimue at macports.org wrote:
>>
>>> Revision: 38038
>>>           http://trac.macosforge.org/projects/macports/changeset/ 
>>> 38038
>>> Author:   raimue at macports.org
>>> Date:     2008-07-03 21:30:56 -0700 (Thu, 03 Jul 2008)
>>> Log Message:
>>> -----------
>>> port1.0/portextract.tcl:
>>> If the $distfile exists in $filespath, use it from there as it was
>>> not fetched
>>> to the distpath in this case.
>>
>> Why would the distfile be in the filespath?
>
> 'port fetch' checks first if the distfile exists in $filespath and  
> does
> not fetch it to $distpath if it exists there. So 'port fetch' was able
> to work with a distfile in $filespath, but 'port extract' was not.
>
> I did this change for consistency. We could also remove the check for
> the distfile in $filespath in portfetch, but I think that would  
> apply to
> patchfiles as well which are often in $filespath.

Ah, now I understand. Makes sense.


From randall.h.wood at alexandriasoftware.com  Mon Jul  7 01:32:21 2008
From: randall.h.wood at alexandriasoftware.com (Randall Wood)
Date: Mon, 7 Jul 2008 04:32:21 -0400
Subject: [38109] trunk/base
In-Reply-To: <1B079DDD-828F-4CF7-85F1-7119A6B89172@macports.org>
References: <20080706202749.750C0112476@beta.macosforge.org>
	<1C9F86B4-0CEC-4A36-8C07-289B5D74BA2A@macports.org>
	<487165C1.3070008@macports.org>
	<1B079DDD-828F-4CF7-85F1-7119A6B89172@macports.org>
Message-ID: <c24012060807070132j2a72836au75e80e97197edbec@mail.gmail.com>

On Sun, Jul 6, 2008 at 10:23 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On Jul 6, 2008, at 19:39, Rainer M?ller wrote:
>
>> Ryan Schmidt wrote:
>>> Now does this work for tcsh too or just for bash?
>>
>> This is for bash only. I assume the majority of users have bash as
>> default shell.
>
> Probably, but users who upgraded from Mac OS X 10.1.x or earlier
> could still have tcsh as their default shell, and we should support
> that.
>
>> I don't think we can write a script which will work with all shells
>> out
>> there, so additional versions for tcsh/zsh/ksh/... are welcomed.
>>
>> I renamed the file to setupenv.bash in r38114 to reflect this.
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>

Is there any mechanism for ports to manipulate the environment?

-- 
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  Mon Jul  7 02:00:52 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 7 Jul 2008 04:00:52 -0500
Subject: [38109] trunk/base
In-Reply-To: <c24012060807070132j2a72836au75e80e97197edbec@mail.gmail.com>
References: <20080706202749.750C0112476@beta.macosforge.org>
	<1C9F86B4-0CEC-4A36-8C07-289B5D74BA2A@macports.org>
	<487165C1.3070008@macports.org>
	<1B079DDD-828F-4CF7-85F1-7119A6B89172@macports.org>
	<c24012060807070132j2a72836au75e80e97197edbec@mail.gmail.com>
Message-ID: <B81A660F-1D0E-4614-8241-11DFF9F654BD@macports.org>


On Jul 7, 2008, at 03:32, Randall Wood wrote:

> On Sun, Jul 6, 2008 at 10:23 PM, Ryan Schmidt wrote:
>
>> On Jul 6, 2008, at 19:39, Rainer M?ller wrote:
>>
>>> Ryan Schmidt wrote:
>>>
>>>> Now does this work for tcsh too or just for bash?
>>>
>>> This is for bash only. I assume the majority of users have bash as
>>> default shell.
>>
>> Probably, but users who upgraded from Mac OS X 10.1.x or earlier
>> could still have tcsh as their default shell, and we should support
>> that.
>>
>>> I don't think we can write a script which will work with all shells
>>> out
>>> there, so additional versions for tcsh/zsh/ksh/... are welcomed.
>>>
>>> I renamed the file to setupenv.bash in r38114 to reflect this.
>
> Is there any mechanism for ports to manipulate the environment?


Do you mean to change the user's shell for them? It should be  
possible with NetInfo. But I don't think MacPorts should be the one  
to tell the user what shell to use.

Or did you mean something else?


From randall.h.wood at alexandriasoftware.com  Mon Jul  7 03:18:07 2008
From: randall.h.wood at alexandriasoftware.com (Randall Wood)
Date: Mon, 7 Jul 2008 06:18:07 -0400
Subject: [38109] trunk/base
In-Reply-To: <B81A660F-1D0E-4614-8241-11DFF9F654BD@macports.org>
References: <20080706202749.750C0112476@beta.macosforge.org>
	<1C9F86B4-0CEC-4A36-8C07-289B5D74BA2A@macports.org>
	<487165C1.3070008@macports.org>
	<1B079DDD-828F-4CF7-85F1-7119A6B89172@macports.org>
	<c24012060807070132j2a72836au75e80e97197edbec@mail.gmail.com>
	<B81A660F-1D0E-4614-8241-11DFF9F654BD@macports.org>
Message-ID: <c24012060807070318s44b754e8v8188fb416fb258f5@mail.gmail.com>

On Mon, Jul 7, 2008 at 5:00 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On Jul 7, 2008, at 03:32, Randall Wood wrote:
>
>> On Sun, Jul 6, 2008 at 10:23 PM, Ryan Schmidt wrote:
>>
>>> On Jul 6, 2008, at 19:39, Rainer M?ller wrote:
>>>
>>>> Ryan Schmidt wrote:
>>>>
>>>>> Now does this work for tcsh too or just for bash?
>>>>
>>>> This is for bash only. I assume the majority of users have bash as
>>>> default shell.
>>>
>>> Probably, but users who upgraded from Mac OS X 10.1.x or earlier
>>> could still have tcsh as their default shell, and we should support
>>> that.
>>>
>>>> I don't think we can write a script which will work with all shells
>>>> out
>>>> there, so additional versions for tcsh/zsh/ksh/... are welcomed.
>>>>
>>>> I renamed the file to setupenv.bash in r38114 to reflect this.
>>
>> Is there any mechanism for ports to manipulate the environment?
>
>
> Do you mean to change the user's shell for them? It should be possible with
> NetInfo. But I don't think MacPorts should be the one to tell the user what
> shell to use.
>
> Or did you mean something else?
>
>
I meant something like what fink does. See
http://trac.macports.org/wiki/SummerOfCode task 10


-- 
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 landonf at macports.org  Mon Jul  7 09:02:40 2008
From: landonf at macports.org (Landon Fuller)
Date: Mon, 7 Jul 2008 09:02:40 -0700
Subject: [38109] trunk/base
In-Reply-To: <c24012060807070318s44b754e8v8188fb416fb258f5@mail.gmail.com>
References: <20080706202749.750C0112476@beta.macosforge.org>
	<1C9F86B4-0CEC-4A36-8C07-289B5D74BA2A@macports.org>
	<487165C1.3070008@macports.org>
	<1B079DDD-828F-4CF7-85F1-7119A6B89172@macports.org>
	<c24012060807070132j2a72836au75e80e97197edbec@mail.gmail.com>
	<B81A660F-1D0E-4614-8241-11DFF9F654BD@macports.org>
	<c24012060807070318s44b754e8v8188fb416fb258f5@mail.gmail.com>
Message-ID: <2B25A175-26AC-41A8-9F83-04B796106814@macports.org>


On Jul 7, 2008, at 3:18 AM, Randall Wood wrote:

> On Mon, Jul 7, 2008 at 5:00 AM, Ryan Schmidt  
> <ryandesign at macports.org> wrote:
>>
>>
>> Do you mean to change the user's shell for them? It should be  
>> possible with
>> NetInfo. But I don't think MacPorts should be the one to tell the  
>> user what
>> shell to use.
>>
>> Or did you mean something else?
>>
>>
> I meant something like what fink does. See
> http://trac.macports.org/wiki/SummerOfCode task 10

I'm not sure I'd want ports to assume the ability to modify my shell  
environment.
The shell environment something I'm pretty specific about, and I  
wouldn't want anything assuming that it could modify it.

-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/20080707/b6141eef/attachment.bin 

From randall.h.wood at alexandriasoftware.com  Mon Jul  7 09:41:51 2008
From: randall.h.wood at alexandriasoftware.com (Randall Wood)
Date: Mon, 7 Jul 2008 12:41:51 -0400
Subject: [38109] trunk/base
In-Reply-To: <2B25A175-26AC-41A8-9F83-04B796106814@macports.org>
References: <20080706202749.750C0112476@beta.macosforge.org>
	<1C9F86B4-0CEC-4A36-8C07-289B5D74BA2A@macports.org>
	<487165C1.3070008@macports.org>
	<1B079DDD-828F-4CF7-85F1-7119A6B89172@macports.org>
	<c24012060807070132j2a72836au75e80e97197edbec@mail.gmail.com>
	<B81A660F-1D0E-4614-8241-11DFF9F654BD@macports.org>
	<c24012060807070318s44b754e8v8188fb416fb258f5@mail.gmail.com>
	<2B25A175-26AC-41A8-9F83-04B796106814@macports.org>
Message-ID: <c24012060807070941q536a94f9m13ccf724bbc40e50@mail.gmail.com>

On Mon, Jul 7, 2008 at 12:02 PM, Landon Fuller <landonf at macports.org> wrote:
>
> On Jul 7, 2008, at 3:18 AM, Randall Wood wrote:
>
>> On Mon, Jul 7, 2008 at 5:00 AM, Ryan Schmidt <ryandesign at macports.org>
>> wrote:
>>>
>>>
>>> Do you mean to change the user's shell for them? It should be possible
>>> with
>>> NetInfo. But I don't think MacPorts should be the one to tell the user
>>> what
>>> shell to use.
>>>
>>> Or did you mean something else?
>>>
>>>
>> I meant something like what fink does. See
>> http://trac.macports.org/wiki/SummerOfCode task 10
>
> I'm not sure I'd want ports to assume the ability to modify my shell
> environment.
> The shell environment something I'm pretty specific about, and I wouldn't
> want anything assuming that it could modify it.
>
> -landonf
>

In your case, you probably don't want to source a macports script for
your environment anyway, right?

But if you are going to source some script we provide, why not let
ports set certain expected environment variables that make
correct-in-most-cases-but-not-ours assumptions that can be overridden
by setting the environment. Its better than patching the upstream code
if the code respects env. variables, and carries defaults that make
sense in almost every other UNIX out in the wild. (Specifically, I am
thinking of the environment variables that unless set or patched,
cause GNOME/KDE/other-Freedesktop-spec-implementations to look for
configuration data in /usr or /usr/local instead of /opt/local)

An ideal mechanism would be something like having a port include a
statement like:

shell.env name value

and having the install/uninstall phases generate/remove a file (1 for
each supported shell environment) containing the shell-specific syntax
for including that variable in the shell

-- 
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 randall.h.wood at alexandriasoftware.com  Mon Jul  7 09:44:22 2008
From: randall.h.wood at alexandriasoftware.com (Randall Wood)
Date: Mon, 7 Jul 2008 12:44:22 -0400
Subject: [38109] trunk/base
In-Reply-To: <20080706202749.750C0112476@beta.macosforge.org>
References: <20080706202749.750C0112476@beta.macosforge.org>
Message-ID: <c24012060807070944t316eceadwcfe987c6325a5d5f@mail.gmail.com>

In Leopard, do we really want to set the display? Won't that screw
with the new Apple mechanism for handling X display requests?

On Sun, Jul 6, 2008 at 4:27 PM,  <raimue at macports.org> wrote:
> Revision 38109 Author raimue at macports.org Date 2008-07-06 13:27:48 -0700
> (Sun, 06 Jul 2008)
>
> Log Message
>
> base:
> Add a new setupenv.sh script which can be used to setup the environment for
> MacPorts. It will be installed to ${prefix}/share/macports/setupenv.sh and
> can
> be sourced from your profile.
>
> Modified Paths
>
> trunk/base/Makefile.in
> trunk/base/configure
> trunk/base/configure.ac
>
> Added Paths
>
> trunk/base/setupenv.sh.in
>
> Property Changed
>
> trunk/base/
>
> Diff
>
> Property changes: trunk/base
>
> Name: svn:ignore
>    - autom4te.cache
> config.log
> config.status
> Makefile
> Doxyfile
> tcldox
>    + autom4te.cache
> config.log
> config.status
> Makefile
> Doxyfile
> tcldox
> setupenv.sh
>
> Modified: trunk/base/Makefile.in (38108 => 38109)
>
> --- trunk/base/Makefile.in	2008-07-06 19:45:41 UTC (rev 38108)
> +++ trunk/base/Makefile.in	2008-07-06 20:27:48 UTC (rev 38109)
> @@ -32,6 +32,7 @@
>  include Mk/macports.upgrade.mk
>
>  install:: upgrade
> +	$(INSTALL) -o ${DSTUSR} -g ${DSTGRP} -m 444 setupenv.sh
> ${datadir}/macports/
>  	[ ! -f ${sysconfdir}/macports/mp_version ] || rm -vf
> ${sysconfdir}/macports/mp_version
>
>  include Mk/macports.subdir.mk
>
> Modified: trunk/base/configure (38108 => 38109)
>
> --- trunk/base/configure	2008-07-06 19:45:41 UTC (rev 38108)
> +++ trunk/base/configure	2008-07-06 20:27:48 UTC (rev 38109)
> @@ -12377,7 +12377,7 @@
>
>
>  # Output
> -ac_config_files="$ac_config_files Doxyfile Makefile Mk/macports.autoconf.mk
> doc/prefix.mtree doc/macosx.mtree doc/macports.conf portmgr/freebsd/Makefile
> portmgr/fedora/macports.spec src/Makefile
> src/macports1.0/macports_autoconf.tcl src/tclobjc1.0/Makefile
> src/pathconf/Makefile src/pathconf/paths src/pathconf/manpaths
> src/port1.0/port_autoconf.tcl src/registry1.0/registry_autoconf.tcl
> src/programs/Makefile src/macports1.0/macports_fastload.tcl"
> +ac_config_files="$ac_config_files Doxyfile Makefile Mk/macports.autoconf.mk
> doc/prefix.mtree doc/macosx.mtree doc/macports.conf portmgr/freebsd/Makefile
> portmgr/fedora/macports.spec src/Makefile
> src/macports1.0/macports_autoconf.tcl src/tclobjc1.0/Makefile
> src/pathconf/Makefile src/pathconf/paths src/pathconf/manpaths
> src/port1.0/port_autoconf.tcl src/registry1.0/registry_autoconf.tcl
> src/programs/Makefile src/macports1.0/macports_fastload.tcl setupenv.sh"
>
>
>  cat >confcache <<\_ACEOF
> @@ -12953,6 +12953,7 @@
>      "src/registry1.0/registry_autoconf.tcl") CONFIG_FILES="$CONFIG_FILES
> src/registry1.0/registry_autoconf.tcl" ;;
>      "src/programs/Makefile") CONFIG_FILES="$CONFIG_FILES
> src/programs/Makefile" ;;
>      "src/macports1.0/macports_fastload.tcl") CONFIG_FILES="$CONFIG_FILES
> src/macports1.0/macports_fastload.tcl" ;;
> +    "setupenv.sh") CONFIG_FILES="$CONFIG_FILES setupenv.sh" ;;
>
>    *) { { echo "$as_me:$LINENO: error: invalid argument: $ac_config_target"
>>&5
>  echo "$as_me: error: invalid argument: $ac_config_target" >&2;}
>
> Modified: trunk/base/configure.ac (38108 => 38109)
>
> --- trunk/base/configure.ac	2008-07-06 19:45:41 UTC (rev 38108)
> +++ trunk/base/configure.ac	2008-07-06 20:27:48 UTC (rev 38109)
> @@ -412,6 +412,7 @@
>  	src/registry1.0/registry_autoconf.tcl
>  	src/programs/Makefile
>  	src/macports1.0/macports_fastload.tcl
> +	setupenv.sh
>  ])
>
>  AC_OUTPUT
>
> Added: trunk/base/setupenv.sh.in (0 => 38109)
>
> --- trunk/base/setupenv.sh.in	                        (rev 0)
> +++ trunk/base/setupenv.sh.in	2008-07-06 20:27:48 UTC (rev 38109)
> @@ -0,0 +1,87 @@
> +# -*- coding: utf-8; mode: shell-script-mode; tab-width: 4;
> indent-tabs-mode: nil; c-basic-offset: 4 -*-
> vim:fenc=utf-8:filetype=sh:et:sw=4:ts=4:sts=4
> +#
> +# Copyright (c) 2008 Rainer Mueller <raimue at macports.org>, The MacPorts
> Project.
> +# All rights reserved.
> +#
> +# Redistribution and use in source and binary forms, with or without
> +# modification, are permitted provided that the following conditions
> +# are met:
> +# 1. Redistributions of source code must retain the above copyright
> +#    notice, this list of conditions and the following disclaimer.
> +# 2. Redistributions in binary form must reproduce the above copyright
> +#    notice, this list of conditions and the following disclaimer in the
> +#    documentation and/or other materials provided with the distribution.
> +# 3. Neither the name of Apple, Inc., The MacPorts Project nor the
> +#    names of its contributors may be used to endorse or promote products
> +#    derived from this software without specific prior written permission.
> +#
> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
> IS" AND
> +# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> LIABLE
> +# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> CONSEQUENTIAL
> +# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> +# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> +# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
> STRICT
> +# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> +# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> +# SUCH DAMAGE.
> +#
> +# $Id$
> +
> +function export_path() {
> +    local binpath="@prefix_expanded@/bin"
> +    local sbinpath="@prefix_expanded@/sbin"
> +
> +    local IFS=":"
> +    for p in $PATH; do
> +        if [ "$p" == "$binpath" ]; then
> +            binpath=""
> +        elif [ "$p" == "$sbinpath" ]; then
> +            sbinpath=""
> +        fi
> +    done
> +
> +    if [ -n "$binpath" ]; then
> +        binpath+=":"
> +    fi
> +
> +    if [ -n "$sbinpath" ]; then
> +        sbinpath+=":"
> +    fi
> +
> +    export PATH="${binpath}${sbinpath}${PATH}"
> +}
> +
> +function export_manpath() {
> +    mpath="@prefix_expanded@/share/man"
> +
> +    local IFS=":"
> +    for p in $MANPATH; do
> +        if [ "$p" == "$mpath" ]; then
> +            mpath=""
> +        fi
> +    done
> +
> +    if [ -n "$mpath" ]; then
> +        mpath+=":"
> +    fi
> +
> +    export MANPATH="${mpath}${MANPATH}"
> +}
> +
> +function export_display() {
> +    if [ -z $DISPLAY ]; then
> +        export DISPLAY=":0.0"
> +    fi
> +}
> +
> +export_path
> +export_manpath
> +export_display
> +
> +# Remove defined functions to prevent them from cluttering the shell,
> +# but they are needed to restrict variables to the local scope
> +unset export_path
> +unset export_manpath
> +unset export_display
>
> _______________________________________________
> 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 landonf at macports.org  Mon Jul  7 09:49:30 2008
From: landonf at macports.org (Landon Fuller)
Date: Mon, 7 Jul 2008 09:49:30 -0700
Subject: [38109] trunk/base
In-Reply-To: <c24012060807070941q536a94f9m13ccf724bbc40e50@mail.gmail.com>
References: <20080706202749.750C0112476@beta.macosforge.org>
	<1C9F86B4-0CEC-4A36-8C07-289B5D74BA2A@macports.org>
	<487165C1.3070008@macports.org>
	<1B079DDD-828F-4CF7-85F1-7119A6B89172@macports.org>
	<c24012060807070132j2a72836au75e80e97197edbec@mail.gmail.com>
	<B81A660F-1D0E-4614-8241-11DFF9F654BD@macports.org>
	<c24012060807070318s44b754e8v8188fb416fb258f5@mail.gmail.com>
	<2B25A175-26AC-41A8-9F83-04B796106814@macports.org>
	<c24012060807070941q536a94f9m13ccf724bbc40e50@mail.gmail.com>
Message-ID: <FED8E182-E1C2-4600-A076-0FA5BBEE932D@macports.org>


On Jul 7, 2008, at 9:41 AM, Randall Wood wrote:

> On Mon, Jul 7, 2008 at 12:02 PM, Landon Fuller  
> <landonf at macports.org> wrote:
>>
>> On Jul 7, 2008, at 3:18 AM, Randall Wood wrote:
>>
>>> On Mon, Jul 7, 2008 at 5:00 AM, Ryan Schmidt <ryandesign at macports.org 
>>> >
>>> wrote:
>>>>
>>>>
>>>> Do you mean to change the user's shell for them? It should be  
>>>> possible
>>>> with
>>>> NetInfo. But I don't think MacPorts should be the one to tell the  
>>>> user
>>>> what
>>>> shell to use.
>>>>
>>>> Or did you mean something else?
>>>>
>>>>
>>> I meant something like what fink does. See
>>> http://trac.macports.org/wiki/SummerOfCode task 10
>>
>> I'm not sure I'd want ports to assume the ability to modify my shell
>> environment.
>> The shell environment something I'm pretty specific about, and I  
>> wouldn't
>> want anything assuming that it could modify it.
>>
>> -landonf
>>
>
> In your case, you probably don't want to source a macports script for
> your environment anyway, right?
>
> But if you are going to source some script we provide, why not let
> ports set certain expected environment variables that make
> correct-in-most-cases-but-not-ours assumptions that can be overridden
> by setting the environment. Its better than patching the upstream code
> if the code respects env. variables, and carries defaults that make
> sense in almost every other UNIX out in the wild. (Specifically, I am
> thinking of the environment variables that unless set or patched,
> cause GNOME/KDE/other-Freedesktop-spec-implementations to look for
> configuration data in /usr or /usr/local instead of /opt/local)
>
> An ideal mechanism would be something like having a port include a
> statement like:
>
> shell.env name value
>
> and having the install/uninstall phases generate/remove a file (1 for
> each supported shell environment) containing the shell-specific syntax
> for including that variable in the shell

Ports would assume those environmental variables are set (and can be  
set), rather than patching the software and having it Just Work no  
matter what environment they're run from (including non-shell  
environments).

I'd say patching is a lot less complicated, and far more polite, than  
trying to control the program's external environment.

-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/20080707/22538f67/attachment.bin 

From raimue at macports.org  Mon Jul  7 10:34:36 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Mon, 07 Jul 2008 19:34:36 +0200
Subject: [38109] trunk/base
In-Reply-To: <c24012060807070944t316eceadwcfe987c6325a5d5f@mail.gmail.com>
References: <20080706202749.750C0112476@beta.macosforge.org>
	<c24012060807070944t316eceadwcfe987c6325a5d5f@mail.gmail.com>
Message-ID: <487253AC.7030502@macports.org>

Randall Wood wrote:
> In Leopard, do we really want to set the display? Won't that screw
> with the new Apple mechanism for handling X display requests?

This script only exports DISPLAY if it is not set yet. On Leopard 
DISPLAY is already exported from the LaunchAgent in launchd, so the 
mechanism still works as the script does not touch it.

Rainer

From ryandesign at macports.org  Mon Jul  7 10:50:33 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 7 Jul 2008 12:50:33 -0500
Subject: [38109] trunk/base
In-Reply-To: <c24012060807070941q536a94f9m13ccf724bbc40e50@mail.gmail.com>
References: <20080706202749.750C0112476@beta.macosforge.org>
	<1C9F86B4-0CEC-4A36-8C07-289B5D74BA2A@macports.org>
	<487165C1.3070008@macports.org>
	<1B079DDD-828F-4CF7-85F1-7119A6B89172@macports.org>
	<c24012060807070132j2a72836au75e80e97197edbec@mail.gmail.com>
	<B81A660F-1D0E-4614-8241-11DFF9F654BD@macports.org>
	<c24012060807070318s44b754e8v8188fb416fb258f5@mail.gmail.com>
	<2B25A175-26AC-41A8-9F83-04B796106814@macports.org>
	<c24012060807070941q536a94f9m13ccf724bbc40e50@mail.gmail.com>
Message-ID: <92CD9C2C-A175-44CB-A8A4-9572F8D28126@macports.org>


On Jul 7, 2008, at 11:41, Randall Wood wrote:

> But if you are going to source some script we provide, why not let
> ports set certain expected environment variables that make
> correct-in-most-cases-but-not-ours assumptions that can be overridden
> by setting the environment. Its better than patching the upstream code
> if the code respects env. variables, and carries defaults that make
> sense in almost every other UNIX out in the wild. (Specifically, I am
> thinking of the environment variables that unless set or patched,
> cause GNOME/KDE/other-Freedesktop-spec-implementations to look for
> configuration data in /usr or /usr/local instead of /opt/local)
>
> An ideal mechanism would be something like having a port include a
> statement like:
>
> shell.env name value
>
> and having the install/uninstall phases generate/remove a file (1 for
> each supported shell environment) containing the shell-specific syntax
> for including that variable in the shell

Hmm. Well this might be useful for something else.... what about the  
case where ports want to add something to the PATH? For example  
mysql5 might like to add ${prefix}/lib/mysql5/bin to the PATH.  
apache2 might like to add ${prefix}/apache2/bin.


From raimue at macports.org  Mon Jul  7 11:53:13 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Mon, 07 Jul 2008 20:53:13 +0200
Subject: [38109] trunk/base
In-Reply-To: <c24012060807070941q536a94f9m13ccf724bbc40e50@mail.gmail.com>
References: <20080706202749.750C0112476@beta.macosforge.org>	<1C9F86B4-0CEC-4A36-8C07-289B5D74BA2A@macports.org>	<487165C1.3070008@macports.org>	<1B079DDD-828F-4CF7-85F1-7119A6B89172@macports.org>	<c24012060807070132j2a72836au75e80e97197edbec@mail.gmail.com>	<B81A660F-1D0E-4614-8241-11DFF9F654BD@macports.org>	<c24012060807070318s44b754e8v8188fb416fb258f5@mail.gmail.com>	<2B25A175-26AC-41A8-9F83-04B796106814@macports.org>
	<c24012060807070941q536a94f9m13ccf724bbc40e50@mail.gmail.com>
Message-ID: <48726619.1030802@macports.org>

Randall Wood wrote:
> But if you are going to source some script we provide, why not let
> ports set certain expected environment variables that make
> correct-in-most-cases-but-not-ours assumptions that can be overridden
> by setting the environment. Its better than patching the upstream code
> if the code respects env. variables, and carries defaults that make
> sense in almost every other UNIX out in the wild. (Specifically, I am
> thinking of the environment variables that unless set or patched,
> cause GNOME/KDE/other-Freedesktop-spec-implementations to look for
> configuration data in /usr or /usr/local instead of /opt/local)

Software installed by MacPorts always looks in /opt/local. Exporting 
some variables could cause software from /usr/bin to look in /opt/local, 
too. This might be unexpected and not so easy to track down for users 
when they are not aware of these variables.

> An ideal mechanism would be something like having a port include a
> statement like:
> 
> shell.env name value

Can you provide example ports we currently have in the tree which would 
benefit from such a mechanism?

> and having the install/uninstall phases generate/remove a file (1 for
> each supported shell environment) containing the shell-specific syntax
> for including that variable in the shell

uninstall/deactivate hooks were planned for registry2.0, but there is no 
ongoing development on this. I sent a status request to Chris some time 
ago...

Rainer



From wsiegrist at apple.com  Mon Jul  7 13:15:10 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Mon, 07 Jul 2008 13:15:10 -0700
Subject: [38028] trunk/dports/PortIndex
In-Reply-To: <47C1B925-22E4-49B1-8753-4DE70D75D1A7@geeklair.net>
References: <20080703194544.0D264108C60@beta.macosforge.org>
	<744A53FA-3E13-4208-915C-CE6C6C144F9F@apple.com>
	<47C1B925-22E4-49B1-8753-4DE70D75D1A7@geeklair.net>
Message-ID: <6406E4B0-F272-4D48-ADB7-EDEFA3BB9143@apple.com>


On Jul 3, 2008, at 5:49 PM, Daniel J. Luke wrote:

> Yeah, whenever you're ready to start running it I can turn it off on  
> my box.
>
> On Jul 3, 2008, at 3:52 PM, William Siegrist wrote:
>> Would you like Mac OS Forge to start running this job? I believe it  
>> was the plan to eventually move it, so I am making the offer.
>>>


(Sorry for the initial top-post)...

 From reading the script, it makes yet-another-checkout/update of the  
source instead of coexisting with PortIndex2MySQL and mprsyncup? It  
also reinstalls MP v1.6 every time? I run MP from trunk on the  
servers, and carefully jump to new versions, so I'd like to avoid  
reverting to 1.6 and/or getting a new MP install every day  
automatically.

I can probably unify the various scripts to all update to the same  
place so I dont have so many copies of MP source  laying around, but I  
was curious if the index *must* be done from a machine running the  
latest release instead of a reasonably-up-to-date trunk install?

-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/20080707/53efde25/attachment.bin 

From dluke at geeklair.net  Mon Jul  7 13:20:04 2008
From: dluke at geeklair.net (Daniel J. Luke)
Date: Mon, 7 Jul 2008 16:20:04 -0400
Subject: [38028] trunk/dports/PortIndex
In-Reply-To: <6406E4B0-F272-4D48-ADB7-EDEFA3BB9143@apple.com>
References: <20080703194544.0D264108C60@beta.macosforge.org>
	<744A53FA-3E13-4208-915C-CE6C6C144F9F@apple.com>
	<47C1B925-22E4-49B1-8753-4DE70D75D1A7@geeklair.net>
	<6406E4B0-F272-4D48-ADB7-EDEFA3BB9143@apple.com>
Message-ID: <2E702AC0-4C93-4B13-BF9D-6415F89852D4@geeklair.net>

On Jul 7, 2008, at 4:15 PM, William Siegrist wrote:
> From reading the script, it makes yet-another-checkout/update of the  
> source instead of coexisting with PortIndex2MySQL and mprsyncup?

yep.

> It also reinstalls MP v1.6 every time?

Well, it reinstalls the current release every time (I never bothered  
to make the script smarter to only install if the release changed).

> I run MP from trunk on the servers, and carefully jump to new  
> versions, so I'd like to avoid reverting to 1.6 and/or getting a new  
> MP install every day automatically.

Its install is not system-wide, if that helps any. On my box, it all  
lives in its own user's $HOME

> I can probably unify the various scripts to all update to the same  
> place so I dont have so many copies of MP source  laying around, but  
> I was curious if the index *must* be done from a machine running the  
> latest release instead of a reasonably-up-to-date trunk install?


Yes. The PortIndex should only contain ports which can be parsed by  
the current MacPorts release, so the portindex that generates it needs  
to be from the current release. A newer version, which supports newer  
keywords would add ports to the index that users running the latest  
release version wouldn't be able to install.

--
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/20080707/33962803/attachment.bin 

From ryandesign at macports.org  Mon Jul  7 13:58:00 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 7 Jul 2008 15:58:00 -0500
Subject: [MacPorts] #15891: Undefined symbols:
	_xmlTextReaderSchemaValidate _xmlTextReaderSchemaValidate
In-Reply-To: <798115C6-6723-498E-83D7-76B120A9B6DC@fairfaxconsultancy.com>
References: <065.b8357163a43b0eb4acdbc4b1a5c56fa4@macports.org>
	<074.646e5af58f526733340bf2ef89437c58@macports.org>
	<798115C6-6723-498E-83D7-76B120A9B6DC@fairfaxconsultancy.com>
Message-ID: <0585EF6E-B6B4-4DF6-9331-1587E15571B0@macports.org>


On Jul 7, 2008, at 15:32, Martin wrote:

> Sorry to have made it more confusing.
>
> I did not have MacPorts installed until 2 days ago.
>
> I am using MAMP, simply because it is easy. ImageMagick was a  
> standalone installation (so, not the MacPorts version).
> ImageMagick required the DYLD_LIBRARY_PATH to be extended.
>
> I also added MAMP's lib dir to the DYLD_LIBRARY_PATH.
>
> After installing MacPorts I ran into library conflicts with MAMP  
> and initially prepended /opt/local/lib to DYLD_LIBRARY_PATH
>
> That seemed to work for installation but not for runtime.
>
> I am now running without the DYLD_LIBRARY_PATH changed for MAMP and  
> MacPorts and it all works.
>
> I guess the moral of the story is to keep the .profile as clean as  
> possible.
>
> And I will probably move from MAMP to MacPorts too.
>
> But it all works at the moment so I am reluctant to switch them.
> Then again, the reason to start using MacPorts is the ability to  
> use variants and to keep up to date with versions.

The moral of the story is not to use DYLD_LIBRARY_PATH. :) Any  
software that requires you to use that variable is pretty much broken.


From florian.ebeling at gmail.com  Mon Jul  7 14:37:36 2008
From: florian.ebeling at gmail.com (Caspar Florian Ebeling)
Date: Mon, 7 Jul 2008 23:37:36 +0200
Subject: [MacPorts] #15891: Undefined symbols:
	_xmlTextReaderSchemaValidate _xmlTextReaderSchemaValidate
In-Reply-To: <0585EF6E-B6B4-4DF6-9331-1587E15571B0@macports.org>
References: <065.b8357163a43b0eb4acdbc4b1a5c56fa4@macports.org>
	<074.646e5af58f526733340bf2ef89437c58@macports.org>
	<798115C6-6723-498E-83D7-76B120A9B6DC@fairfaxconsultancy.com>
	<0585EF6E-B6B4-4DF6-9331-1587E15571B0@macports.org>
Message-ID: <5cbbe4ae0807071437yde18bf2p41aaea4ff87f0109@mail.gmail.com>

>> I am now running without the DYLD_LIBRARY_PATH changed for MAMP and
>> MacPorts and it all works.
>>
>> I guess the moral of the story is to keep the .profile as clean as
>> possible.
>>
>> And I will probably move from MAMP to MacPorts too.
>>
>> But it all works at the moment so I am reluctant to switch them.
>> Then again, the reason to start using MacPorts is the ability to
>> use variants and to keep up to date with versions.
>
> The moral of the story is not to use DYLD_LIBRARY_PATH. :) Any
> software that requires you to use that variable is pretty much broken.

but isn't quite necessary for running test and using binaries
e.g. for building generated docs while still only staged and not fully
installed?

Florian



-- 
Florian Ebeling
florian.ebeling at gmail.com

From ryandesign at macports.org  Mon Jul  7 15:38:06 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 7 Jul 2008 17:38:06 -0500
Subject: [MacPorts] #15891: Undefined symbols:
	_xmlTextReaderSchemaValidate _xmlTextReaderSchemaValidate
In-Reply-To: <5cbbe4ae0807071437yde18bf2p41aaea4ff87f0109@mail.gmail.com>
References: <065.b8357163a43b0eb4acdbc4b1a5c56fa4@macports.org>
	<074.646e5af58f526733340bf2ef89437c58@macports.org>
	<798115C6-6723-498E-83D7-76B120A9B6DC@fairfaxconsultancy.com>
	<0585EF6E-B6B4-4DF6-9331-1587E15571B0@macports.org>
	<5cbbe4ae0807071437yde18bf2p41aaea4ff87f0109@mail.gmail.com>
Message-ID: <CE83A834-A32C-425D-9D81-E8337CFB55C3@macports.org>


On Jul 7, 2008, at 16:37, Caspar Florian Ebeling wrote:

>>> I am now running without the DYLD_LIBRARY_PATH changed for MAMP and
>>> MacPorts and it all works.
>>>
>>> I guess the moral of the story is to keep the .profile as clean as
>>> possible.
>>>
>>> And I will probably move from MAMP to MacPorts too.
>>>
>>> But it all works at the moment so I am reluctant to switch them.
>>> Then again, the reason to start using MacPorts is the ability to
>>> use variants and to keep up to date with versions.
>>
>> The moral of the story is not to use DYLD_LIBRARY_PATH. :) Any
>> software that requires you to use that variable is pretty much  
>> broken.
>
> but isn't quite necessary for running test and using binaries
> e.g. for building generated docs while still only staged and not fully
> installed?

Sure. Many ports set DYLD_LIBRARY_PATH just for the testing phase.  
It's fine if a port sets it where necessary during the build. That's  
a temporary setting that doesn't live past that phase. But it's not  
fine for a user to set DYLD_LIBRARY_PATH e.g. in his .profile.  
MacPorts won't look in the .profile while building, but the product  
that MacPorts then built and linked with MacPorts parts might start  
using other parts as directed by DYLD_LIBRARY_PATH, and that's not  
what we want.



From wsiegrist at apple.com  Mon Jul  7 17:01:36 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Mon, 07 Jul 2008 17:01:36 -0700
Subject: [38028] trunk/dports/PortIndex
In-Reply-To: <2E702AC0-4C93-4B13-BF9D-6415F89852D4@geeklair.net>
References: <20080703194544.0D264108C60@beta.macosforge.org>
	<744A53FA-3E13-4208-915C-CE6C6C144F9F@apple.com>
	<47C1B925-22E4-49B1-8753-4DE70D75D1A7@geeklair.net>
	<6406E4B0-F272-4D48-ADB7-EDEFA3BB9143@apple.com>
	<2E702AC0-4C93-4B13-BF9D-6415F89852D4@geeklair.net>
Message-ID: <1DF389DC-193A-4F94-8E9C-951A0255C546@apple.com>


On Jul 7, 2008, at 1:20 PM, Daniel J. Luke wrote:

> On Jul 7, 2008, at 4:15 PM, William Siegrist wrote:
>> From reading the script, it makes yet-another-checkout/update of  
>> the source instead of coexisting with PortIndex2MySQL and mprsyncup?
>
> yep.
>
>> It also reinstalls MP v1.6 every time?
>
> Well, it reinstalls the current release every time (I never bothered  
> to make the script smarter to only install if the release changed).
>
>> I run MP from trunk on the servers, and carefully jump to new  
>> versions, so I'd like to avoid reverting to 1.6 and/or getting a  
>> new MP install every day automatically.
>
> Its install is not system-wide, if that helps any. On my box, it all  
> lives in its own user's $HOME
>
>> I can probably unify the various scripts to all update to the same  
>> place so I dont have so many copies of MP source  laying around,  
>> but I was curious if the index *must* be done from a machine  
>> running the latest release instead of a reasonably-up-to-date trunk  
>> install?
>
>
> Yes. The PortIndex should only contain ports which can be parsed by  
> the current MacPorts release, so the portindex that generates it  
> needs to be from the current release. A newer version, which  
> supports newer keywords would add ports to the index that users  
> running the latest release version wouldn't be able to install.




Ok. I've setup a job to run at 00:45 and 12:45.  You can disable it on  
your machine.

-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/20080707/0e0b7118/attachment-0001.bin 

From ryandesign at macports.org  Mon Jul  7 18:22:59 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 7 Jul 2008 20:22:59 -0500
Subject: distfiles.macports.org slow
Message-ID: <BF8F999D-D52F-40CA-B130-F8C75E3771D6@macports.org>

MacPorts trunk seems to like picking distfiles.macports.org to  
download distfiles because its pings return fast, but actually  
downloading files from it is slow, like less than 10KB/sec. Anyone  
else seeing this?



From wsiegrist at apple.com  Mon Jul  7 19:34:06 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Mon, 07 Jul 2008 19:34:06 -0700
Subject: distfiles.macports.org slow
In-Reply-To: <BF8F999D-D52F-40CA-B130-F8C75E3771D6@macports.org>
References: <BF8F999D-D52F-40CA-B130-F8C75E3771D6@macports.org>
Message-ID: <AB09EA8F-1AE7-4891-AFCB-0B680A3C7E2B@apple.com>

On Jul 7, 2008, at 6:22 PM, Ryan Schmidt wrote:

> MacPorts trunk seems to like picking distfiles.macports.org to
> download distfiles because its pings return fast, but actually
> downloading files from it is slow, like less than 10KB/sec. Anyone
> else seeing this?



I just did a quick test and I get much better results. Obviously, to  
my office is 5-10 MB/s which is expected since the servers are very  
close to me. But even downloading to my personal machine at home over  
a cable modem averaged around 1 MB/s.  There's probably a point when  
you're too far away for pings to accurately model the bandwidth  
between, but I think you should be getting something better than 10KB/ 
s anyway.


-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/20080707/b0798100/attachment.bin 

From dluke at geeklair.net  Mon Jul  7 20:05:14 2008
From: dluke at geeklair.net (Daniel J. Luke)
Date: Mon, 7 Jul 2008 23:05:14 -0400
Subject: [38028] trunk/dports/PortIndex
In-Reply-To: <1DF389DC-193A-4F94-8E9C-951A0255C546@apple.com>
References: <20080703194544.0D264108C60@beta.macosforge.org>
	<744A53FA-3E13-4208-915C-CE6C6C144F9F@apple.com>
	<47C1B925-22E4-49B1-8753-4DE70D75D1A7@geeklair.net>
	<6406E4B0-F272-4D48-ADB7-EDEFA3BB9143@apple.com>
	<2E702AC0-4C93-4B13-BF9D-6415F89852D4@geeklair.net>
	<1DF389DC-193A-4F94-8E9C-951A0255C546@apple.com>
Message-ID: <7657BD9A-933C-46B4-89B5-DF06DF8B2958@geeklair.net>

On Jul 7, 2008, at 8:01 PM, William Siegrist wrote:
> Ok. I've setup a job to run at 00:45 and 12:45.  You can disable it  
> on your machine.


done!
--
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/20080707/52b3146b/attachment.bin 

From dluke at geeklair.net  Mon Jul  7 21:16:52 2008
From: dluke at geeklair.net (Daniel J. Luke)
Date: Tue, 8 Jul 2008 00:16:52 -0400
Subject: distfiles.macports.org slow
In-Reply-To: <AB09EA8F-1AE7-4891-AFCB-0B680A3C7E2B@apple.com>
References: <BF8F999D-D52F-40CA-B130-F8C75E3771D6@macports.org>
	<AB09EA8F-1AE7-4891-AFCB-0B680A3C7E2B@apple.com>
Message-ID: <37ACFC14-3ABE-43CA-9D76-96FF35DDA22F@geeklair.net>

On Jul 7, 2008, at 10:34 PM, William Siegrist wrote:
> On Jul 7, 2008, at 6:22 PM, Ryan Schmidt wrote:
>> MacPorts trunk seems to like picking distfiles.macports.org to
>> download distfiles because its pings return fast, but actually
>> downloading files from it is slow, like less than 10KB/sec. Anyone
>> else seeing this?
>
> I just did a quick test and I get much better results. Obviously, to  
> my office is 5-10 MB/s which is expected since the servers are very  
> close to me. But even downloading to my personal machine at home  
> over a cable modem averaged around 1 MB/s.  There's probably a point  
> when you're too far away for pings to accurately model the bandwidth  
> between, but I think you should be getting something better than  
> 10KB/s anyway.


Maybe there's some ICMP filtering that's breaking PMTU discovery  
(which could be interfering with TCP window scaling):

[xeon:~] dluke% ping -s 1600 gandalf.geeklair.net
PING geeklair.net (129.250.34.2): 1600 data bytes
1608 bytes from 129.250.34.2: icmp_seq=0 ttl=51 time=90.470 ms
1608 bytes from 129.250.34.2: icmp_seq=1 ttl=51 time=74.231 ms
^C
--- gandalfgeeklair.net ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 74.231/82.350/90.470/8.119 ms

[xeon:~] dluke% ping -s 1600 distfiles.macports.org
PING alpha.macosforge.org (17.254.17.246): 1600 data bytes
^C
--- alpha.macosforge.org ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss

--
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/20080708/583a57fb/attachment.bin 

From wsiegrist at apple.com  Mon Jul  7 21:32:26 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Mon, 07 Jul 2008 21:32:26 -0700
Subject: distfiles.macports.org slow
In-Reply-To: <37ACFC14-3ABE-43CA-9D76-96FF35DDA22F@geeklair.net>
References: <BF8F999D-D52F-40CA-B130-F8C75E3771D6@macports.org>
	<AB09EA8F-1AE7-4891-AFCB-0B680A3C7E2B@apple.com>
	<37ACFC14-3ABE-43CA-9D76-96FF35DDA22F@geeklair.net>
Message-ID: <B809B7ED-28CE-4A00-99F5-1256BD2C4D82@apple.com>


On Jul 7, 2008, at 9:16 PM, Daniel J. Luke wrote:

> On Jul 7, 2008, at 10:34 PM, William Siegrist wrote:
>> On Jul 7, 2008, at 6:22 PM, Ryan Schmidt wrote:
>>> MacPorts trunk seems to like picking distfiles.macports.org to
>>> download distfiles because its pings return fast, but actually
>>> downloading files from it is slow, like less than 10KB/sec. Anyone
>>> else seeing this?
>>
>> I just did a quick test and I get much better results. Obviously,  
>> to my office is 5-10 MB/s which is expected since the servers are  
>> very close to me. But even downloading to my personal machine at  
>> home over a cable modem averaged around 1 MB/s.  There's probably a  
>> point when you're too far away for pings to accurately model the  
>> bandwidth between, but I think you should be getting something  
>> better than 10KB/s anyway.
>
>
> Maybe there's some ICMP filtering that's breaking PMTU discovery  
> (which could be interfering with TCP window scaling):
>
> [xeon:~] dluke% ping -s 1600 gandalf.geeklair.net
> PING geeklair.net (129.250.34.2): 1600 data bytes
> 1608 bytes from 129.250.34.2: icmp_seq=0 ttl=51 time=90.470 ms
> 1608 bytes from 129.250.34.2: icmp_seq=1 ttl=51 time=74.231 ms
> ^C
> --- gandalfgeeklair.net ping statistics ---
> 2 packets transmitted, 2 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 74.231/82.350/90.470/8.119 ms
>
> [xeon:~] dluke% ping -s 1600 distfiles.macports.org
> PING alpha.macosforge.org (17.254.17.246): 1600 data bytes
> ^C
> --- alpha.macosforge.org ping statistics ---
> 6 packets transmitted, 0 packets received, 100% packet loss
>


I enabled all ICMP types. Does that help?

-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/20080707/9a3e8cc1/attachment.bin 

From ryandesign at macports.org  Mon Jul  7 21:38:02 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 7 Jul 2008 23:38:02 -0500
Subject: distfiles.macports.org slow
In-Reply-To: <AB09EA8F-1AE7-4891-AFCB-0B680A3C7E2B@apple.com>
References: <BF8F999D-D52F-40CA-B130-F8C75E3771D6@macports.org>
	<AB09EA8F-1AE7-4891-AFCB-0B680A3C7E2B@apple.com>
Message-ID: <F9EE794A-6672-4BC0-B35B-51804A392FDF@macports.org>

On Jul 7, 2008, at 21:34, William Siegrist wrote:

> On Jul 7, 2008, at 6:22 PM, Ryan Schmidt wrote:
>
>> MacPorts trunk seems to like picking distfiles.macports.org to
>> download distfiles because its pings return fast, but actually
>> downloading files from it is slow, like less than 10KB/sec. Anyone
>> else seeing this?
>
> I just did a quick test and I get much better results. Obviously,  
> to my office is 5-10 MB/s which is expected since the servers are  
> very close to me. But even downloading to my personal machine at  
> home over a cable modem averaged around 1 MB/s.  There's probably a  
> point when you're too far away for pings to accurately model the  
> bandwidth between, but I think you should be getting something  
> better than 10KB/s anyway.

I was downloading the gcc41 distfiles. The first file took forever,  
transferring at about 5KB/sec. The next file transferred (or at  
least, began transferring) at 130KB/sec or so. I think it's ok most  
of the time, but sometimes it's very slow. I don't think it's my  
network.


From dluke at geeklair.net  Tue Jul  8 03:33:57 2008
From: dluke at geeklair.net (Daniel J. Luke)
Date: Tue, 8 Jul 2008 06:33:57 -0400
Subject: distfiles.macports.org slow
In-Reply-To: <B809B7ED-28CE-4A00-99F5-1256BD2C4D82@apple.com>
References: <BF8F999D-D52F-40CA-B130-F8C75E3771D6@macports.org>
	<AB09EA8F-1AE7-4891-AFCB-0B680A3C7E2B@apple.com>
	<37ACFC14-3ABE-43CA-9D76-96FF35DDA22F@geeklair.net>
	<B809B7ED-28CE-4A00-99F5-1256BD2C4D82@apple.com>
Message-ID: <28EDF86A-25A9-4D41-AB32-1BC1CFE444D9@geeklair.net>

On Jul 8, 2008, at 12:32 AM, William Siegrist wrote:
> I enabled all ICMP types. Does that help?


I get good speeds from my well connected host and fairly good speeds  
from my cable modem, so I haven't seen the slow speed problem at all.

I'm still seeing the same kind of behavior (so if it's the problem,  
it's probably somewhere in the network and not on the macosforge host):

[gandalf:~] dluke% sudo tcptraceroute distfiles.macports.org 80 1500
Selected device en0, address 129.250.34.2, port 53913 for outgoing  
packets
Tracing the path to distfiles.macports.org (17.254.17.246) on TCP port  
80 (http), 30 hops max, 1500 byte packets
  1  fa-3-15.r02.dllstx09.us.bb.gin.ntt.net (129.250.34.1)  0.801 ms   
0.693 ms  0.501 ms
  2  ae-2.r21.dllstx09.us.bb.gin.ntt.net (129.250.2.173)  0.861 ms   
0.905 ms  0.919 ms
  3  p64-4-0-0.r21.snjsca04.us.bb.gin.ntt.net (129.250.3.152)  45.933  
ms  45.991 ms  46.173 ms
  4  po-4.r03.snjsca04.us.bb.gin.ntt.net (129.250.4.78)  45.862 ms   
45.714 ms *
  5  xe-0.internap.snjsca04.us.bb.gin.ntt.net (129.250.12.82)  46.526  
ms  46.411 ms  46.460 ms
  6  border1.pc1-0-bbnet1.sje.pnap.net (66.151.144.4)  47.157 ms   
47.645 ms  46.810 ms
  7  * * *
  8  * * *
  9  * * *
10  alpha.macosforge.org (17.254.17.246) [open]  48.036 ms * 48.001 ms
[gandalf:~] dluke% sudo tcptraceroute distfiles.macports.org 80 1501
Selected device en0, address 129.250.34.2, port 53930 for outgoing  
packets
Tracing the path to distfiles.macports.org (17.254.17.246) on TCP port  
80 (http), 30 hops max, 1501 byte packets
  1  fa-3-15.r02.dllstx09.us.bb.gin.ntt.net (129.250.34.1)  0.874 ms   
0.776 ms  0.584 ms
  2  ae-2.r21.dllstx09.us.bb.gin.ntt.net (129.250.2.173)  0.948 ms   
0.981 ms  0.945 ms
  3  p64-4-0-0.r21.snjsca04.us.bb.gin.ntt.net (129.250.3.152)  45.912  
ms  46.012 ms  46.002 ms
  4  po-4.r03.snjsca04.us.bb.gin.ntt.net (129.250.4.78)  45.911 ms   
52.189 ms  45.916 ms
  5  xe-0.internap.snjsca04.us.bb.gin.ntt.net (129.250.12.82)  46.586  
ms  46.426 ms  46.466 ms
  6  border1.pc1-0-bbnet1.sje.pnap.net (66.151.144.4)  47.072 ms   
46.721 ms  46.788 ms
  7  * * *
  8  * * *
  9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
^C

--
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/20080708/20b7a75b/attachment.bin 

From mcalhoun at macports.org  Tue Jul  8 07:30:06 2008
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Tue, 8 Jul 2008 08:30:06 -0600
Subject: Meaning of "Not a directory"
Message-ID: <E71BEF4E-22D6-41C5-9859-BD193D9CE738@macports.org>

I am experimenting with a local version of graphviz.
During the activation phase, I get the error:
Error: Target org.macports.activate returned: Not a directory

Does anyone know the meaning of this error?

The previous message is
DEBUG: Adding link to file_map: /opt/local/Library/Frameworks/ 
Python.framework/Versions/2.5/lib/python2.5/site-packages/gv.py for:  
graphviz

The file gv.py is the problem.
I have arranged it so that gv.py is the only python file to be  
installed.
When I prevent  it from being installed, there is no problem
Strangely enough, the file gv.py does in fact get installed (and then  
the activation phase dies).

The directory  /opt/local/Library/Frameworks/Python.framework/Versions/ 
2.5/lib/python2.5 is not a directory.
It is a link to /opt/local/lib/python2.5.

Any help would be appreciated.

-Marcus

From ryandesign at macports.org  Tue Jul  8 12:47:41 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 8 Jul 2008 14:47:41 -0500
Subject: [38140] trunk/dports/science/grads/Portfile
In-Reply-To: <20080708142654.7CA2D11B4A3@beta.macosforge.org>
References: <20080708142654.7CA2D11B4A3@beta.macosforge.org>
Message-ID: <8A005162-8613-43F0-BFF9-995A2319819C@macports.org>

On Jul 8, 2008, at 09:26, takeshi at macports.org wrote:

> Revision: 38140
>           http://trac.macosforge.org/projects/macports/changeset/38140
> Author:   takeshi at macports.org
> Date:     2008-07-08 07:26:53 -0700 (Tue, 08 Jul 2008)
> Log Message:
> -----------
> grads: removed --prefix=

For future reference, there's no reason to increment the port's  
revision for this kind of change, because the change doesn't cause  
any different files to be installed by the port. All you're doing is  
removing a duplicated option which MacPorts already added, so nothing  
has functionally changed for the user.

> --- trunk/dports/science/grads/Portfile	2008-07-08 13:21:15 UTC  
> (rev 38139)
> +++ trunk/dports/science/grads/Portfile	2008-07-08 14:26:53 UTC  
> (rev 38140)
> @@ -1,3 +1,4 @@
> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode:  
> nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
>  # $Id$
>
>  PortSystem 1.0
> @@ -4,7 +5,7 @@
>
>  name               grads
>  version            1.9b4
> -revision           3
> +revision           4
>  platforms          darwin
>  maintainers        takeshi at macports.org
>  categories         science
> @@ -33,14 +34,12 @@
>                     patch-wgrib.c.diff   patch-bufrscan.c.diff \
>                     patch-gacfg.c.diff   patch-gxhpng.c.diff
>
> -
>  post-patch {
>      reinplace "s|/usr/local|${prefix}|" ${worksrcpath}/src/gx.h
>  }
>
> -#configure.env LIBS="-lwmf" SUPPLIBS=${prefix}
>  configure.env SUPPLIBS=${prefix}
> -configure.args     --prefix=${prefix} --with-readline --with-lats \
> +configure.args     --with-readline --with-lats \
>                     --with-nc --with-dods --with-hdf --with-x      \
>                     --without-printim --without-gui



From ryandesign at macports.org  Tue Jul  8 12:50:42 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 8 Jul 2008 14:50:42 -0500
Subject: [38141] trunk/dports/net/kismet/Portfile
In-Reply-To: <20080708172019.35DB511BCC3@beta.macosforge.org>
References: <20080708172019.35DB511BCC3@beta.macosforge.org>
Message-ID: <8D3C3654-92B4-4A23-99AB-5B2F9200DE59@macports.org>

On Jul 8, 2008, at 12:20, macsforever2000 at macports.org wrote:

> Revision: 38141
>           http://trac.macosforge.org/projects/macports/changeset/38141
> Author:   macsforever2000 at macports.org
> Date:     2008-07-08 10:20:17 -0700 (Tue, 08 Jul 2008)
> Log Message:
> -----------
> Updated to 2008-05-R1 by sava.chankov at gmail.com
>
> Modified Paths:
> --------------
>     trunk/dports/net/kismet/Portfile
>
> Modified: trunk/dports/net/kismet/Portfile
> ===================================================================
> --- trunk/dports/net/kismet/Portfile	2008-07-08 14:26:53 UTC (rev  
> 38140)
> +++ trunk/dports/net/kismet/Portfile	2008-07-08 17:20:17 UTC (rev  
> 38141)
> @@ -3,7 +3,7 @@
>  PortSystem              1.0
>
>  name                    kismet
> -version                 2007-10-R1
> +version                 2008-05-R1
>  description             Wireless network detector and sniffer
>  long_description        Kismet is an 802.11 layer2 wireless  
> network detector, sniffer, and \
>                          intrusion detection system.  Kismet will  
> work with any wireless card which \
> @@ -21,7 +21,7 @@
>  homepage                http://www.kismetwireless.net/
>  master_sites            ${homepage}code
>
> -checksums               md5 2100c667e69db0cde35fa2d06c8516e2
> +checksums               md5 6ee365d36354b4dee4945e67f8149294

Ok.

> +variant svn_trunk description {Build from current development  
> trunk. Try this on Mac OS X 10.5 if released version doesn't work'} {
> +  version   svn_trunk
> +  fetch {
> +    system "cd  ${workpath}/../../../distfiles && svn co http:// 
> svn.kismetwireless.net/code/trunk kismet"
> +    system "true"
> +  }
> +
> +  checksum {
> +    system "true"
> +  }
> +
> +  extract {
> +    system "cp -r ${workpath}/../../../distfiles/${name} $ 
> {worksrcpath}"
> +  }
> +}

This is not ok. Please remove this part of the portfile again. If you  
want to offer a development version of kismet as an alternative,  
create a new port kismet-devel by copying and then modifying the  
kismet port. See these ports for examples:

pure-devel
glib2-devel
graphviz-devel
mysql5-devel
php5-devel

Keep the kismet and kismet-devel ports as similar as possible.


From ryandesign at macports.org  Tue Jul  8 12:54:56 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 8 Jul 2008 14:54:56 -0500
Subject: Meaning of "Not a directory"
In-Reply-To: <E71BEF4E-22D6-41C5-9859-BD193D9CE738@macports.org>
References: <E71BEF4E-22D6-41C5-9859-BD193D9CE738@macports.org>
Message-ID: <B811B67E-6D92-4A6B-AA20-A09DFFEAA8A1@macports.org>

On Jul 8, 2008, at 09:30, Marcus Calhoun-Lopez wrote:

> I am experimenting with a local version of graphviz.
> During the activation phase, I get the error:
> Error: Target org.macports.activate returned: Not a directory
>
> Does anyone know the meaning of this error?
>
> The previous message is
> DEBUG: Adding link to file_map: /opt/local/Library/Frameworks/
> Python.framework/Versions/2.5/lib/python2.5/site-packages/gv.py for:
> graphviz
>
> The file gv.py is the problem.
> I have arranged it so that gv.py is the only python file to be
> installed.
> When I prevent  it from being installed, there is no problem
> Strangely enough, the file gv.py does in fact get installed (and then
> the activation phase dies).
>
> The directory  /opt/local/Library/Frameworks/Python.framework/ 
> Versions/
> 2.5/lib/python2.5 is not a directory.
> It is a link to /opt/local/lib/python2.5.

I am the maintainer of the graphviz port but I do not use the  
language bindings or Python in general so if something isn't working  
right I'll need your help.

How are you installing graphviz? With the +python variant? I see that  
this variant is coded to use the python24 port.

What do you mean "a local version of graphviz"? Do you mean outside  
of MacPorts? If so, is there something broken in the graphviz port  
that I need to fix?


From mcalhoun at macports.org  Tue Jul  8 13:14:36 2008
From: mcalhoun at macports.org (Marcus)
Date: Tue, 8 Jul 2008 20:14:36 +0000 (UTC)
Subject: Meaning of 
References: <E71BEF4E-22D6-41C5-9859-BD193D9CE738@macports.org>
	<B811B67E-6D92-4A6B-AA20-A09DFFEAA8A1@macports.org>
Message-ID: <loom.20080708T200326-959@post.gmane.org>

Ryan Schmidt <ryandesign at ...> writes:

> 
> On Jul 8, 2008, at 09:30, Marcus Calhoun-Lopez wrote:
> 
> > I am experimenting with a local version of graphviz.
> > During the activation phase, I get the error:
> > Error: Target org.macports.activate returned: Not a directory
> >
> > Does anyone know the meaning of this error?
> >
> > The previous message is
> > DEBUG: Adding link to file_map: /opt/local/Library/Frameworks/
> > Python.framework/Versions/2.5/lib/python2.5/site-packages/gv.py for:
> > graphviz
> >
> > The file gv.py is the problem.
> > I have arranged it so that gv.py is the only python file to be
> > installed.
> > When I prevent  it from being installed, there is no problem
> > Strangely enough, the file gv.py does in fact get installed (and then
> > the activation phase dies).
> >
> > The directory  /opt/local/Library/Frameworks/Python.framework/ 
> > Versions/
> > 2.5/lib/python2.5 is not a directory.
> > It is a link to /opt/local/lib/python2.5.
> 
> I am the maintainer of the graphviz port but I do not use the  
> language bindings or Python in general so if something isn't working  
> right I'll need your help.
> 
> How are you installing graphviz? With the +python variant? I see that  
> this variant is coded to use the python24 port.
> 
> What do you mean "a local version of graphviz"? Do you mean outside  
> of MacPorts? If so, is there something broken in the graphviz port  
> that I need to fix?
> 
> 

The current version of graphviz uses Python 2.4.
I am trying to create a variant which uses Python 2.5
since it is the most recent.

I have a local portfile repository for just these cases,
which is what I meant by "a local version of graphviz."
I did not submit a bug report because the problem seems
to be causes by my own modifications.

The error I get is a mystery to me, and I was hoping
someone on the list could tell me what it means.


Thanks,
Marcus










From wsiegrist at apple.com  Tue Jul  8 13:30:46 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Tue, 08 Jul 2008 13:30:46 -0700
Subject: Email Extensions
Message-ID: <C6863897-2FAA-4FA3-91EE-79E50AD96E5C@apple.com>

Your @macports.org email addresses will now accept email extensions in  
the form of:

user+ext at macports.org

-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/20080708/9829ae5d/attachment.bin 

From ryandesign at macports.org  Tue Jul  8 13:38:19 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 8 Jul 2008 15:38:19 -0500
Subject: [38144] branches/gsoc08-privileges/base/src/port1.0
In-Reply-To: <20080708203535.5910411C434@beta.macosforge.org>
References: <20080708203535.5910411C434@beta.macosforge.org>
Message-ID: <D2C9B121-C170-4DF6-A2E6-4178F868A233@macports.org>


On Jul 8, 2008, at 15:35, pmagrath at macports.org wrote:

> Revision: 38144
>           http://trac.macosforge.org/projects/macports/changeset/38144
> Author:   pmagrath at macports.org
> Date:     2008-07-08 13:35:34 -0700 (Tue, 08 Jul 2008)
> Log Message:
> -----------
> Added a new procedure for recursive chowning of directories.  
> Inserted calls to this procedure where necessary.


> +##
> +# Recusively chown the given file or directory to the specified user.
> +#
> +# @param path the file/directory to be chowned
> +# @param user the user to chown file to
> +proc chown {path user} {
> +	file attributes $path -owner [name_to_uid "$user"]
> +	
> +    if {[file isdirectory $path]} {
> +		foreach g [glob [file join $path *]] {
> +			chown $g $user
> +		}
> +    }
> +}

We already have fs-traverse... couldn't that be used? See example in  
the CronniX port's post-destroot.

From ryandesign at macports.org  Tue Jul  8 14:27:31 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 8 Jul 2008 16:27:31 -0500
Subject: distfiles.macports.org slow
In-Reply-To: <F9EE794A-6672-4BC0-B35B-51804A392FDF@macports.org>
References: <BF8F999D-D52F-40CA-B130-F8C75E3771D6@macports.org>
	<AB09EA8F-1AE7-4891-AFCB-0B680A3C7E2B@apple.com>
	<F9EE794A-6672-4BC0-B35B-51804A392FDF@macports.org>
Message-ID: <10D6E5DC-984F-43EE-B057-E305DE0F6160@macports.org>

On Jul 7, 2008, at 23:38, Ryan Schmidt wrote:

> On Jul 7, 2008, at 21:34, William Siegrist wrote:
>
>> On Jul 7, 2008, at 6:22 PM, Ryan Schmidt wrote:
>>
>>> MacPorts trunk seems to like picking distfiles.macports.org to
>>> download distfiles because its pings return fast, but actually
>>> downloading files from it is slow, like less than 10KB/sec. Anyone
>>> else seeing this?
>>
>> I just did a quick test and I get much better results. Obviously,
>> to my office is 5-10 MB/s which is expected since the servers are
>> very close to me. But even downloading to my personal machine at
>> home over a cable modem averaged around 1 MB/s.  There's probably a
>> point when you're too far away for pings to accurately model the
>> bandwidth between, but I think you should be getting something
>> better than 10KB/s anyway.
>
> I was downloading the gcc41 distfiles. The first file took forever,
> transferring at about 5KB/sec. The next file transferred (or at
> least, began transferring) at 130KB/sec or so. I think it's ok most
> of the time, but sometimes it's very slow. I don't think it's my
> network.

Right now:

--->  Fetching ruby
--->  Attempting to fetch ruby-1.8.7-p22.tar.bz2 from http:// 
distfiles.macports.org/ruby

It's fetching at about 4KB/sec. My wireless signal strength is at  
maximum and it's the same if I put my MacBook Pro very near the  
access point. I'm on a Time Warner cable modem in San Antonio, TX.  
While this distfile is loading, I can view web pages from  
www.apple.com transferring at 200KB/sec so the problem is not at my end.


From ryandesign at macports.org  Tue Jul  8 14:46:43 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 8 Jul 2008 16:46:43 -0500
Subject: Ticket resolved status
Message-ID: <8CA5F293-8308-4756-AA70-3ED17CFEAAA7@macports.org>

When closing a ticket in Trac, I can select from the following  
resolutions:

fixed
invalid
wontfix
duplicate
worksforme

More often than I would like, I find myself unsure which to select.

The Guide does not give any guidance on these ticket resolution values.

If I had to define these I guess I would say:

fixed - there was a problem in MacPorts and it was fixed in MacPorts
invalid - not a MacPorts issue?
wontfix - there is a problem in MacPorts and it will not be fixed in  
MacPorts
duplicate - another ticket describes this problem
worksforme - unable to reproduce the issue, user did not provide  
sufficient information

Is it possible to change these values in Trac? Add new resolutions?  
Remove ones we don't like? The TracTickets wiki page also lists these  
values, so I wonder if it's hard-coded?

I find myself wanting a resolution like "no change required". Or is  
that what "invalid" is for?

Take this ticket:

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

It was a user error caused by a mis-configured macports.conf.

Maybe "user error" is the resolution I want?

How would you resolve this ticket? "fixed" because the user fixed the  
problem? "invalid" because it's not a MacPorts problem? "wontfix"  
because we won't change anything in MacPorts to fix it? "worksforme"  
because it works for me (when I don't mis-configure my  
macports.conf)? Do you see my problem? :-)


From wsiegrist at apple.com  Tue Jul  8 14:54:48 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Tue, 08 Jul 2008 14:54:48 -0700
Subject: distfiles.macports.org slow
In-Reply-To: <10D6E5DC-984F-43EE-B057-E305DE0F6160@macports.org>
References: <BF8F999D-D52F-40CA-B130-F8C75E3771D6@macports.org>
	<AB09EA8F-1AE7-4891-AFCB-0B680A3C7E2B@apple.com>
	<F9EE794A-6672-4BC0-B35B-51804A392FDF@macports.org>
	<10D6E5DC-984F-43EE-B057-E305DE0F6160@macports.org>
Message-ID: <A17E75AD-91E3-49AC-AECC-24702C99473A@apple.com>


On Jul 8, 2008, at 2:27 PM, Ryan Schmidt wrote:

> On Jul 7, 2008, at 23:38, Ryan Schmidt wrote:
>
>> On Jul 7, 2008, at 21:34, William Siegrist wrote:
>>
>>> On Jul 7, 2008, at 6:22 PM, Ryan Schmidt wrote:
>>>
>>>> MacPorts trunk seems to like picking distfiles.macports.org to
>>>> download distfiles because its pings return fast, but actually
>>>> downloading files from it is slow, like less than 10KB/sec. Anyone
>>>> else seeing this?
>>>
>>> I just did a quick test and I get much better results. Obviously,
>>> to my office is 5-10 MB/s which is expected since the servers are
>>> very close to me. But even downloading to my personal machine at
>>> home over a cable modem averaged around 1 MB/s.  There's probably a
>>> point when you're too far away for pings to accurately model the
>>> bandwidth between, but I think you should be getting something
>>> better than 10KB/s anyway.
>>
>> I was downloading the gcc41 distfiles. The first file took forever,
>> transferring at about 5KB/sec. The next file transferred (or at
>> least, began transferring) at 130KB/sec or so. I think it's ok most
>> of the time, but sometimes it's very slow. I don't think it's my
>> network.
>
> Right now:
>
> --->  Fetching ruby
> --->  Attempting to fetch ruby-1.8.7-p22.tar.bz2 from http://distfiles.macports.org/ruby
>
> It's fetching at about 4KB/sec. My wireless signal strength is at  
> maximum and it's the same if I put my MacBook Pro very near the  
> access point. I'm on a Time Warner cable modem in San Antonio, TX.  
> While this distfile is loading, I can view web pages from www.apple.com 
>  transferring at 200KB/sec so the problem is not at my end.
>


Any chance you can tcpdump/wireshark a download to see if anything  
obvious is happening? Also, www.apple.com is hosted in a different  
location than macosforge.org. So a better comparison would be traffic  
from one of our servers. An XQuartz or WebKit nightly dmg would be a  
good target.

http://xquartz.macosforge.org/downloads/X11-2.2.3.pkg

http://builds.nightly.webkit.org/files/trunk/mac/WebKit-SVN-r35039.dmg

If you want some realtime troubleshooting, ping me on IRC.

-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/20080708/7642ce8c/attachment.bin 

From randall.h.wood at alexandriasoftware.com  Tue Jul  8 15:27:53 2008
From: randall.h.wood at alexandriasoftware.com (Randall Wood)
Date: Tue, 8 Jul 2008 18:27:53 -0400
Subject: Ticket resolved status
In-Reply-To: <8CA5F293-8308-4756-AA70-3ED17CFEAAA7@macports.org>
References: <8CA5F293-8308-4756-AA70-3ED17CFEAAA7@macports.org>
Message-ID: <c24012060807081527o27d7f381hf8be16a1d0ded156@mail.gmail.com>

On Tue, Jul 8, 2008 at 5:46 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> When closing a ticket in Trac, I can select from the following
> resolutions:
>
> fixed
> invalid
> wontfix
> duplicate
> worksforme
>
> More often than I would like, I find myself unsure which to select.
>
> The Guide does not give any guidance on these ticket resolution values.
>
> If I had to define these I guess I would say:
>
> fixed - there was a problem in MacPorts and it was fixed in MacPorts
> invalid - not a MacPorts issue?
> wontfix - there is a problem in MacPorts and it will not be fixed in
> MacPorts
> duplicate - another ticket describes this problem
> worksforme - unable to reproduce the issue, user did not provide
> sufficient information
>
> Is it possible to change these values in Trac? Add new resolutions?
> Remove ones we don't like? The TracTickets wiki page also lists these
> values, so I wonder if it's hard-coded?
>
> I find myself wanting a resolution like "no change required". Or is
> that what "invalid" is for?
>
> Take this ticket:
>
> http://trac.macports.org/ticket/15914
>
> It was a user error caused by a mis-configured macports.conf.
>
> Maybe "user error" is the resolution I want?
>
> How would you resolve this ticket? "fixed" because the user fixed the
> problem? "invalid" because it's not a MacPorts problem? "wontfix"
> because we won't change anything in MacPorts to fix it? "worksforme"
> because it works for me (when I don't mis-configure my
> macports.conf)? Do you see my problem? :-)
>

In my experience, user errors are almost always "invalid".



-- 
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 florian.ebeling at gmail.com  Tue Jul  8 15:43:05 2008
From: florian.ebeling at gmail.com (Caspar Florian Ebeling)
Date: Wed, 9 Jul 2008 00:43:05 +0200
Subject: Ruby ports and 1.9
Message-ID: <5cbbe4ae0807081543w3ebdb435s771b7b0e06ec11a6@mail.gmail.com>

Hi,

Yesterday, I have put a patch for ruby group into the trac, which changes
the ruby.setup command so that it accepts an additional parameter.
With it applied
ports for ruby19 can be installed using the port group. These would get
a prefix of rb19 instead of rb, following the python example. Find it here:

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

Rainer raised the concern, that these version-specific ports are a bit of
a duplication, and that the experience with python was not really spotless.
See his comment in the ticket. I see this problem as well.

I have other issues myself. It is not entirely convincing to install
ruby libraries
via a generic package manager like mp, given that ruby has it's own in the
form of Rubygems, which even comes builtin with 1.9.

Unfortunately, authors are not consistent in how they package their ruby
libraries, so not every library is available as a gem, but rather
bring a setup.rb
or an install.rb, which are older but still quite popular alternatives
to rubygems.

So if we would adopt the policy not to offer any ruby ports, then people would
still need to do the good old google+wget+tar xjf+sudo footwork, which
to make a
thing of the past is mp's mission, kind of.

The question is now, do we want to offer ruby ports for 1.9? I think
yes, even if
this is usually the second best option after plain gems. Maybe there can be
a policy that a ruby port should only be added, when it is not
available from the
standard rubygems indexes for installation. Or when a non-gem lib depends on
it and we offer it through a port. When there is a good reason, in general.
One could argue that with 1.9 only gems should be used any longer, and
adoption of gems will be higher since it is shipped directly, but still this
will not help in exceptional cases. And there mp should probably be
able to help.

And if we want 1.9 ports, then we also need support for them in the
port group, I think. So in my opinion this patch should go in, or
maybe something
better than I can produce, for that matter.

Please review the patch as well, in case, I haven't done awfully much of tcl in
my live :) And I'm looking forward to hear what you think on this.

Florian


-- 
Florian Ebeling
florian.ebeling at gmail.com

From ryandesign at macports.org  Tue Jul  8 15:53:21 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 8 Jul 2008 17:53:21 -0500
Subject: [38147] branches/gsoc08-privileges/base/src/port1.0/portutil.tcl
In-Reply-To: <20080708210125.CE5C411C609@beta.macosforge.org>
References: <20080708210125.CE5C411C609@beta.macosforge.org>
Message-ID: <14F30124-61FA-4272-9B9E-37DD6505ED57@macports.org>

Is this chown procedure intended to be used by ports?

If so, maybe there should be chgrp and chmod procedures as well.


On Jul 8, 2008, at 16:01, pmagrath at macports.org wrote:

> Revision: 38147
>           http://trac.macosforge.org/projects/macports/changeset/38147
> Author:   pmagrath at macports.org
> Date:     2008-07-08 14:01:25 -0700 (Tue, 08 Jul 2008)
> Log Message:
> -----------
> Re-wrote chown proc to use fs-traverse (suggested by Eridius. Thanks!)
>
> Modified Paths:
> --------------
>     branches/gsoc08-privileges/base/src/port1.0/portutil.tcl
>
> Modified: branches/gsoc08-privileges/base/src/port1.0/portutil.tcl
> ===================================================================
> --- branches/gsoc08-privileges/base/src/port1.0/portutil.tcl	 
> 2008-07-08 20:44:32 UTC (rev 38146)
> +++ branches/gsoc08-privileges/base/src/port1.0/portutil.tcl	 
> 2008-07-08 21:01:25 UTC (rev 38147)
> @@ -2273,9 +2273,10 @@
>  	file attributes $path -owner [name_to_uid "$user"]
>  	
>      if {[file isdirectory $path]} {
> -		foreach g [glob [file join $path *]] {
> -			chown $g $user
> +		fs-traverse myfile ${path} {
> +			file attributes $myfile -owner [name_to_uid "$user"]
>  		}
>      }
> +
>  }


From wsiegrist at apple.com  Tue Jul  8 16:29:27 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Tue, 08 Jul 2008 16:29:27 -0700
Subject: Ticket resolved status
In-Reply-To: <8CA5F293-8308-4756-AA70-3ED17CFEAAA7@macports.org>
References: <8CA5F293-8308-4756-AA70-3ED17CFEAAA7@macports.org>
Message-ID: <92E8197D-E76C-45C0-AE33-B9A7A3B1FD30@apple.com>


On Jul 8, 2008, at 2:46 PM, Ryan Schmidt wrote:
>
> Is it possible to change these values in Trac? Add new resolutions?
> Remove ones we don't like? The TracTickets wiki page also lists these
> values, so I wonder if it's hard-coded?


The values are hardcoded even in 0.11.  I can add a custom field  
plugin to allow for some flexibility, like "invalid" plus a field that  
says "user error".  Once the rest of your points are discussed down to  
a final request I can whip up the plugin if needed.

-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/20080708/e9d98d97/attachment-0001.bin 

From opendarwin.org at darkart.com  Tue Jul  8 16:34:12 2008
From: opendarwin.org at darkart.com (Eric Hall)
Date: Tue, 8 Jul 2008 23:34:12 +0000
Subject: Ticket resolved status
In-Reply-To: <c24012060807081527o27d7f381hf8be16a1d0ded156@mail.gmail.com>
References: <8CA5F293-8308-4756-AA70-3ED17CFEAAA7@macports.org>
	<c24012060807081527o27d7f381hf8be16a1d0ded156@mail.gmail.com>
Message-ID: <20080708233412.GF973@darkart.com>

On Tue, Jul 08, 2008 at 06:27:53PM -0400, Randall Wood wrote:
> On Tue, Jul 8, 2008 at 5:46 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> > When closing a ticket in Trac, I can select from the following
> > resolutions:
> >
> > fixed
> > invalid
> > wontfix
> > duplicate
> > worksforme
> >
> > More often than I would like, I find myself unsure which to select.

[snip]

> > Take this ticket:
> >
> > http://trac.macports.org/ticket/15914
> >
> > It was a user error caused by a mis-configured macports.conf.
> >
> > Maybe "user error" is the resolution I want?
> >
> > How would you resolve this ticket? "fixed" because the user fixed the
> > problem? "invalid" because it's not a MacPorts problem? "wontfix"
> > because we won't change anything in MacPorts to fix it? "worksforme"
> > because it works for me (when I don't mis-configure my
> > macports.conf)? Do you see my problem? :-)
> >
> 
> In my experience, user errors are almost always "invalid".

	I agree, invalid (its not a problem w/ macports, unless
the docs/guidance we have for users is at fault).


		-eric


From raimue at macports.org  Tue Jul  8 17:06:56 2008
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Wed, 09 Jul 2008 02:06:56 +0200
Subject: [38144] branches/gsoc08-privileges/base/src/port1.0
In-Reply-To: <20080708203535.5910411C434@beta.macosforge.org>
References: <20080708203535.5910411C434@beta.macosforge.org>
Message-ID: <48740120.5030700@macports.org>

pmagrath at macports.org wrote:
> Revision: 38144
>           http://trac.macosforge.org/projects/macports/changeset/38144
> Author:   pmagrath at macports.org
> Date:     2008-07-08 13:35:34 -0700 (Tue, 08 Jul 2008)
> Log Message:
> -----------
> Added a new procedure for recursive chowning of directories. Inserted calls to this procedure where necessary.
> 
> Modified Paths:
> --------------
>     branches/gsoc08-privileges/base/src/port1.0/portextract.tcl
>     branches/gsoc08-privileges/base/src/port1.0/portutil.tcl
> 
> Modified: branches/gsoc08-privileges/base/src/port1.0/portextract.tcl
> ===================================================================
> --- branches/gsoc08-privileges/base/src/port1.0/portextract.tcl	2008-07-08 19:52:43 UTC (rev 38143)
> +++ branches/gsoc08-privileges/base/src/port1.0/portextract.tcl	2008-07-08 20:35:34 UTC (rev 38144)
> @@ -93,7 +93,6 @@
>  
>  proc extract_main {args} {
>      global UI_PREFIX euid egid worksrcpath macportsuser
> -    global filespath
>      
>      if {![exists distfiles] && ![exists extract.only]} {
>  	# nothing to do
> @@ -102,11 +101,7 @@
>  
>      foreach distfile [option extract.only] {
>  	ui_info "$UI_PREFIX [format [msgcat::mc "Extracting %s"] $distfile]"
> -	if {[file exists $filespath/$distfile]} {
> -		option extract.args "$filespath/$distfile"
> -	} else {
> -		option extract.args "[option distpath]/$distfile"
> -	}
> +	option extract.args "[option distpath]/$distfile"

You reverted a change here which was merged in from trunk (r38038).
Be careful, we are going to merge your work back to trunk at the end of 
the summer and it should not overwrite other changes made in between.

Rainer

From raimue at macports.org  Tue Jul  8 17:21:25 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Wed, 09 Jul 2008 02:21:25 +0200
Subject: Ticket resolved status
In-Reply-To: <8CA5F293-8308-4756-AA70-3ED17CFEAAA7@macports.org>
References: <8CA5F293-8308-4756-AA70-3ED17CFEAAA7@macports.org>
Message-ID: <48740485.9010404@macports.org>

Ryan Schmidt wrote:
> If I had to define these I guess I would say:
> 
> fixed - there was a problem in MacPorts and it was fixed in MacPorts

Or: there was a problem somewhere and this fix is available through MacPorts

Some problems are directed to upstream and fixed there, and then an 
updated Portfile provides the fix.

> invalid - not a MacPorts issue?
> wontfix - there is a problem in MacPorts and it will not be fixed in  
> MacPorts
> duplicate - another ticket describes this problem
> worksforme - unable to reproduce the issue, user did not provide  
> sufficient information

You definitions sound good. Is there an appropriate place in the guide 
to add them?

> [...]
> How would you resolve this ticket? "fixed" because the user fixed the  
> problem? "invalid" because it's not a MacPorts problem? "wontfix"  
> because we won't change anything in MacPorts to fix it? "worksforme"  
> because it works for me (when I don't mis-configure my  
> macports.conf)? Do you see my problem? :-)
I would say user error is 'invalid'. It was an invalid claim that there 
is a bug.

Rainer

From raimue at macports.org  Tue Jul  8 17:29:32 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Wed, 09 Jul 2008 02:29:32 +0200
Subject: Ruby ports and 1.9
In-Reply-To: <5cbbe4ae0807081543w3ebdb435s771b7b0e06ec11a6@mail.gmail.com>
References: <5cbbe4ae0807081543w3ebdb435s771b7b0e06ec11a6@mail.gmail.com>
Message-ID: <4874066C.3000505@macports.org>

Caspar Florian Ebeling wrote:
> I have other issues myself. It is not entirely convincing to install
> ruby libraries
> via a generic package manager like mp, given that ruby has it's own in the
> form of Rubygems, which even comes builtin with 1.9.

The same thing applies to Perl. There is CPAN which distributes nearly 
every Perl module available. But the problem is that you can't declare a 
dependency on a specific module without a port.

Also, in my opinion it's easier for users to use only one package 
manager (like MacPorts) to install software. Using cpan, gem and others 
additionally might not be that easy. Especially this comes true when 
using a GUI.

Rainer

From florian.ebeling at gmail.com  Tue Jul  8 23:24:43 2008
From: florian.ebeling at gmail.com (Caspar Florian Ebeling)
Date: Wed, 9 Jul 2008 08:24:43 +0200
Subject: Ticket resolved status
In-Reply-To: <8CA5F293-8308-4756-AA70-3ED17CFEAAA7@macports.org>
References: <8CA5F293-8308-4756-AA70-3ED17CFEAAA7@macports.org>
Message-ID: <5cbbe4ae0807082324r25b7ad44ye3f5221245d9a72a@mail.gmail.com>

On Tue, Jul 8, 2008 at 11:46 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> When closing a ticket in Trac, I can select from the following
> resolutions:
>
> fixed
> invalid
> wontfix
> duplicate
> worksforme
>
> More often than I would like, I find myself unsure which to select.
>
> The Guide does not give any guidance on these ticket resolution values.
>
> If I had to define these I guess I would say:
>
> fixed - there was a problem in MacPorts and it was fixed in MacPorts
> invalid - not a MacPorts issue?
> wontfix - there is a problem in MacPorts and it will not be fixed in
> MacPorts
> duplicate - another ticket describes this problem
> worksforme - unable to reproduce the issue, user did not provide
> sufficient information
>
> Is it possible to change these values in Trac? Add new resolutions?
> Remove ones we don't like? The TracTickets wiki page also lists these
> values, so I wonder if it's hard-coded?
>
> I find myself wanting a resolution like "no change required". Or is
> that what "invalid" is for?

These are largely inherited from things like bugzilla, and I would
hesitate to change them, because their are also somewhat conventions,
weird as their sound.

"No change required" is implicit in wontfix, invalid and worksforme.
Wontfix means, something like "It's not a bug it'a a feature", or
"it's not worth the trouble in this version"; invalid
is "I can see what the user did wrong and it was not our software",
so the assertion that there is a problem with software is invalid.
And worksforme is a somewhat weaker form of invalid, a second class
invalid. You cannot rule out that there might be a problem on
some esoteric platform, but a reasonable check did not show
any problem in a situation as the user describes it.

There might be better, and more authoritive descriptions in the bugzilla
documentation. These are my rule-of-thumb heuristics. The tags
are not entirely unambiguous, but that only reflects the character
of many bugs in that respect, doesn't it ;)

>
> Take this ticket:
>
> http://trac.macports.org/ticket/15914
>
> It was a user error caused by a mis-configured macports.conf.
>
> Maybe "user error" is the resolution I want?
>
> How would you resolve this ticket? "fixed" because the user fixed the
> problem? "invalid" because it's not a MacPorts problem? "wontfix"
> because we won't change anything in MacPorts to fix it? "worksforme"
> because it works for me (when I don't mis-configure my
> macports.conf)? Do you see my problem? :-)

It's clearly invalid, in my view. Would be worksforme if you didn't
know the cause, but you yourself were able to install as suggested,
and wontfix if it was a problem only under Mac OS X Cheetah/Puma.

Florian




-- 
Florian Ebeling
florian.ebeling at gmail.com

From pmagrath at macports.org  Wed Jul  9 01:16:11 2008
From: pmagrath at macports.org (Paul Magrath)
Date: Wed, 9 Jul 2008 09:16:11 +0100
Subject: [38144] branches/gsoc08-privileges/base/src/port1.0
In-Reply-To: <D2C9B121-C170-4DF6-A2E6-4178F868A233@macports.org>
References: <20080708203535.5910411C434@beta.macosforge.org>
	<D2C9B121-C170-4DF6-A2E6-4178F868A233@macports.org>
Message-ID: <8FC5DA4A-E146-486A-995C-B7A568DD927F@macports.org>

Yep. Eridius pointed that out to me about a second after I committed  
so I committed a new version using fs-traverse about 15 mins later.

On 8 Jul 2008, at 21:38, Ryan Schmidt wrote:
>
> We already have fs-traverse... couldn't that be used? See example in  
> the CronniX port's post-destroot.


From pmagrath at macports.org  Wed Jul  9 01:14:37 2008
From: pmagrath at macports.org (Paul Magrath)
Date: Wed, 9 Jul 2008 09:14:37 +0100
Subject: [38147] branches/gsoc08-privileges/base/src/port1.0/portutil.tcl
In-Reply-To: <14F30124-61FA-4272-9B9E-37DD6505ED57@macports.org>
References: <20080708210125.CE5C411C609@beta.macosforge.org>
	<14F30124-61FA-4272-9B9E-37DD6505ED57@macports.org>
Message-ID: <DB55CB7E-A58A-429F-A89F-1668C434C732@macports.org>

Not primarily no. Is there somewhere more appropriate for private  
functions in portutil?

On 8 Jul 2008, at 23:53, Ryan Schmidt wrote:

> Is this chown procedure intended to be used by ports?
>
> If so, maybe there should be chgrp and chmod procedures as well.
>
>
> On Jul 8, 2008, at 16:01, pmagrath at macports.org wrote:
>
>> Revision: 38147
>>          http://trac.macosforge.org/projects/macports/changeset/38147
>> Author:   pmagrath at macports.org
>> Date:     2008-07-08 14:01:25 -0700 (Tue, 08 Jul 2008)
>> Log Message:
>> -----------
>> Re-wrote chown proc to use fs-traverse (suggested by Eridius.  
>> Thanks!)
>>
>> Modified Paths:
>> --------------
>>    branches/gsoc08-privileges/base/src/port1.0/portutil.tcl
>>
>> Modified: branches/gsoc08-privileges/base/src/port1.0/portutil.tcl
>> ===================================================================
>> --- branches/gsoc08-privileges/base/src/port1.0/portutil.tcl	 
>> 2008-07-08 20:44:32 UTC (rev 38146)
>> +++ branches/gsoc08-privileges/base/src/port1.0/portutil.tcl	 
>> 2008-07-08 21:01:25 UTC (rev 38147)
>> @@ -2273,9 +2273,10 @@
>> 	file attributes $path -owner [name_to_uid "$user"]
>> 	
>>     if {[file isdirectory $path]} {
>> -		foreach g [glob [file join $path *]] {
>> -			chown $g $user
>> +		fs-traverse myfile ${path} {
>> +			file attributes $myfile -owner [name_to_uid "$user"]
>> 		}
>>     }
>> +
>> }
>


From ryandesign at macports.org  Wed Jul  9 23:15:34 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 10 Jul 2008 01:15:34 -0500
Subject: distfiles.macports.org updates
Message-ID: <560898AD-4617-4E99-836D-BC8676B2C12E@macports.org>

How often does distfiles.macports.org get new files? Is it a periodic  
process like portindex, or does it run after every commit like the  
port lint check?

If periodic, does it generate output about what it's doing, like  
which new files have been downloaded or which files failed to  
download, and if so, could that be emailed to the changes list? Would  
anyone find that useful?


From wsiegrist at apple.com  Thu Jul 10 12:31:36 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Thu, 10 Jul 2008 12:31:36 -0700
Subject: distfiles.macports.org updates
In-Reply-To: <560898AD-4617-4E99-836D-BC8676B2C12E@macports.org>
References: <560898AD-4617-4E99-836D-BC8676B2C12E@macports.org>
Message-ID: <B1176804-CFE8-40C9-B545-0E93DEAF8CC2@apple.com>

On Jul 9, 2008, at 11:15 PM, Ryan Schmidt wrote:

> How often does distfiles.macports.org get new files? Is it a periodic
> process like portindex, or does it run after every commit like the
> port lint check?
>

Every morning it runs through every port and performs "port mirror".   
So regardless of commits or changes to the port, it will try to mirror  
whats currently listed in the portfile. This allows for failed  
transfers to be retried. It records a timestamp when it finishes each  
day:

http://distfiles.macports.org/TIMESTAMP


> If periodic, does it generate output about what it's doing, like
> which new files have been downloaded or which files failed to
> download, and if so, could that be emailed to the changes list? Would
> anyone find that useful?


I use the -d flag for mirror and record the output for debugging, but  
its a lot of spam. But if you really want it, I can maybe clean it up  
a little or make a summary report.

-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/20080710/e73ea1f9/attachment.bin 

From ryandesign at macports.org  Fri Jul 11 01:29:04 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 11 Jul 2008 03:29:04 -0500
Subject: Leopard makes ppc7400 binaries
Message-ID: <8B641C65-544C-4D42-8927-09A688C91E14@macports.org>

When I compile on Leopard on a PowerPC Mac, "lipo" shows that  
executables and dynamic libraries are getting created with the  
architecture "ppc7400" instead of "ppc" as on Tiger and earlier.  
Static libraries still are "ppc".

Even in universal binaries, when I specifically request "i386" and  
"ppc", I get a binary with "i386" and "ppc7400".

This seems to mean that these binaries require a G4 or better, and  
won't work on a G3. Leopard of course also requires a G4.

Here's a post I found:

http://www.jaharmi.com/2007/10/28/compiled_for_ppc7400

I guess I don't have a question, I was just surprised so I wanted to  
share.


From ryandesign at macports.org  Fri Jul 11 01:54:28 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 11 Jul 2008 03:54:28 -0500
Subject: molden and distfiles mirror
Message-ID: <8F8449AF-749F-4504-B9DB-6CD491DF29C1@macports.org>

The molden port says:

> # I (Jochen K?pper) got explicit permission to distribute molden as a
> # MacPorts port, given that the source-code is always downloaded from
> # the authors webpage and we add a banner asking users to register at
> # the following web-page: http://www.cmbi.ru.nl/molden/form.html


What are the implications now that MacPorts mirrors distfiles at  
distfiles.macports.org?


From wsiegrist at apple.com  Fri Jul 11 07:11:54 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Fri, 11 Jul 2008 07:11:54 -0700
Subject: molden and distfiles mirror
In-Reply-To: <8F8449AF-749F-4504-B9DB-6CD491DF29C1@macports.org>
References: <8F8449AF-749F-4504-B9DB-6CD491DF29C1@macports.org>
Message-ID: <08FFD295-B0A2-42E0-8C60-F760F26F7AD7@apple.com>

On Jul 11, 2008, at 1:54 AM, Ryan Schmidt wrote:

> The molden port says:
>
>> # I (Jochen K?pper) got explicit permission to distribute molden as a
>> # MacPorts port, given that the source-code is always downloaded from
>> # the authors webpage and we add a banner asking users to register at
>> # the following web-page: http://www.cmbi.ru.nl/molden/form.html
>
>
> What are the implications now that MacPorts mirrors distfiles at
> distfiles.macports.org?
>

Restrictions like this need to be mailed to me so I can remove the  
port from the mirror process. I'll take care of this today. If someone  
wants to ask the dev about mirroring it, I can always re-add later but  
sounds like they wont want that.

-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/20080711/f1e14e5d/attachment.bin 

From captsolo at gmail.com  Fri Jul 11 07:42:12 2008
From: captsolo at gmail.com (Uldis Bojars)
Date: Fri, 11 Jul 2008 15:42:12 +0100
Subject: Meaning of "Not a directory"
Message-ID: <64c81f720807110742q4d6edf85o93856bddd6dc127b@mail.gmail.com>

> Marcus Calhoun-Lopez wrote:
> > > I am experimenting with a local version of graphviz.
> > > During the activation phase, I get the error:
> > > Error: Target org.macports.activate returned: Not a directory
> > >
> > > Does anyone know the meaning of this error?
> [...]
>
> The current version of graphviz uses Python 2.4.
> I am trying to create a variant which uses Python 2.5
> since it is the most recent.

The same error message has appeared for me in a number of other ports.
Two such cases:
 - py25-pyqt4 (reported in
http://lists.macosforge.org/pipermail/macports-users/2008-July/010888.html,
no replies);
 - redland-bindings +python (after bringing it up to 1.0.8.1 since
previous versions of this port have problems earlier in the
installation process, not getting to the activation phase)

If this error appears in multiple packages (not for everyone, perhaps)
it would be good to have a FAQ entry on how to fix it.

Has someone else seen these messages? Would be good to find out under
what conditions these problems appear. So far it looks like they
appear in packages created using SWIG when Python bindings are used.

Marcus: did the same problem with Graphviz appear if you compile it
with Python 2.4?

Uldis

From dluke at geeklair.net  Fri Jul 11 08:40:17 2008
From: dluke at geeklair.net (Daniel J. Luke)
Date: Fri, 11 Jul 2008 11:40:17 -0400
Subject: molden and distfiles mirror
In-Reply-To: <08FFD295-B0A2-42E0-8C60-F760F26F7AD7@apple.com>
References: <8F8449AF-749F-4504-B9DB-6CD491DF29C1@macports.org>
	<08FFD295-B0A2-42E0-8C60-F760F26F7AD7@apple.com>
Message-ID: <5CE4E17E-522F-4006-8AB1-5BD1C42DA527@geeklair.net>

On Jul 11, 2008, at 10:11 AM, William Siegrist wrote:
> On Jul 11, 2008, at 1:54 AM, Ryan Schmidt wrote:
>> The molden port says:
>>> # I (Jochen K?pper) got explicit permission to distribute molden  
>>> as a
>>> # MacPorts port, given that the source-code is always downloaded  
>>> from
>>> # the authors webpage and we add a banner asking users to register  
>>> at
>>> # the following web-page: http://www.cmbi.ru.nl/molden/form.html
>>
>> What are the implications now that MacPorts mirrors distfiles at
>> distfiles.macports.org?
>
> Restrictions like this need to be mailed to me so I can remove the  
> port from the mirror process. I'll take care of this today. If  
> someone wants to ask the dev about mirroring it, I can always re-add  
> later but sounds like they wont want that.


It looks like we can mirror it if we want to:

http://www.cmbi.ru.nl/molden/CopyRight.html

Although it's probably a good idea to respect the author's preference  
if we can.

--
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/20080711/f55a33f5/attachment.bin 

From reiffert at macports.org  Fri Jul 11 10:20:19 2008
From: reiffert at macports.org (Thomas Reifferscheid)
Date: Fri, 11 Jul 2008 19:20:19 +0200
Subject: [MacPorts] #15955: Finch no longer connects to ICQ
In-Reply-To: <062.7aaae56e2246347eeb1b65d2a80a07af@macports.org>
References: <053.2eca42d5760cf2ad72a1fa3733ca5f91@macports.org>
	<062.7aaae56e2246347eeb1b65d2a80a07af@macports.org>
Message-ID: <48779653.1020101@macports.org>

Dear Simon,

feel free to take the port and change everything the way you want.

Kind regards
Thomas

MacPorts wrote:
> #15955: Finch no longer connects to ICQ
> --------------------------------+-------------------------------------------
>   Reporter:  xoagray at gmail.com  |       Owner:  rsync at reifferscheid.org
>       Type:  defect             |      Status:  new                    
>   Priority:  Normal             |   Milestone:  Port Bugs              
>  Component:  ports              |     Version:  1.6.0                  
> Resolution:                     |    Keywords:  Finch ICQ              
> --------------------------------+-------------------------------------------
> Changes (by simon at macports.org):
>
>  * cc: simon at macports.org (added)
>
> Comment:
>
>  Here is a patch to update to 2.4.3 which works fine for me.
>
>  Simon
>
>   


From simon at ruderich.com  Fri Jul 11 13:55:05 2008
From: simon at ruderich.com (Simon Ruderich)
Date: Fri, 11 Jul 2008 22:55:05 +0200
Subject: [MacPorts] #15955: Finch no longer connects to ICQ
In-Reply-To: <48779653.1020101@macports.org>
References: <053.2eca42d5760cf2ad72a1fa3733ca5f91@macports.org>
	<062.7aaae56e2246347eeb1b65d2a80a07af@macports.org>
	<48779653.1020101@macports.org>
Message-ID: <20080711205505.GA29568@ruderich.com>

On Fri, Jul 11, 2008 at 07:20:19PM +0200, Thomas Reifferscheid wrote:
> Dear Simon,
>
> feel free to take the port and change everything the way you want.
>
> Kind regards
> Thomas

Hi Thomas,

thanks, I just updated finch to the latest version [1]. Can I also update the
pidgin port? [2]

Thanks,
Simon

[1]: http://trac.macports.org/changeset/38190
[2]: http://trac.macports.org/ticket/15959
-- 
+ privacy is necessary
+ using http://gnupg.org
+ public key id: 0x6115F804EFB33229
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080711/72596cd8/attachment.bin 

From mcalhoun at macports.org  Fri Jul 11 15:07:28 2008
From: mcalhoun at macports.org (Marcus)
Date: Fri, 11 Jul 2008 22:07:28 +0000 (UTC)
Subject: Meaning of 
References: <64c81f720807110742q4d6edf85o93856bddd6dc127b@mail.gmail.com>
Message-ID: <loom.20080711T215556-334@post.gmane.org>

Uldis Bojars <captsolo at ...> writes:

> 
> > Marcus Calhoun-Lopez wrote:
> > > > I am experimenting with a local version of graphviz.
> > > > During the activation phase, I get the error:
> > > > Error: Target org.macports.activate returned: Not a directory
> > > >
> > > > Does anyone know the meaning of this error?
> > [...]
> 
> If this error appears in multiple packages (not for everyone, perhaps)
> it would be good to have a FAQ entry on how to fix it.
> [...]
> 
> Marcus: did the same problem with Graphviz appear if you compile it
> with Python 2.4?

Yes, the error is reproducible with using the variant "graphviz +python,"
which uses Python 2.4.

-Marcus








From ryandesign at macports.org  Fri Jul 11 15:58:10 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 11 Jul 2008 17:58:10 -0500
Subject: [38191] trunk/dports/www/ikiwiki/Portfile
In-Reply-To: <20080711224347.8CA1212E75A@beta.macosforge.org>
References: <20080711224347.8CA1212E75A@beta.macosforge.org>
Message-ID: <E7678A7E-6B83-4C68-8DB9-4BD910A502C1@macports.org>

Hi Thomas!

On Jul 11, 2008, at 17:43, tommyd at macports.org wrote:

> Revision: 38191
>           http://trac.macosforge.org/projects/macports/changeset/38191
> Author:   tommyd at macports.org
> Date:     2008-07-11 15:43:47 -0700 (Fri, 11 Jul 2008)
> Log Message:
> -----------
> www/ikiwiki: take maintenance of ikiwiki port, upgrade to
> 2.51, closes #15801
>
> Modified Paths:
> --------------
>     trunk/dports/www/ikiwiki/Portfile
>
> Modified: trunk/dports/www/ikiwiki/Portfile
> ===================================================================
> --- trunk/dports/www/ikiwiki/Portfile	2008-07-11 20:51:54 UTC (rev  
> 38190)
> +++ trunk/dports/www/ikiwiki/Portfile	2008-07-11 22:43:47 UTC (rev  
> 38191)
> @@ -3,38 +3,68 @@
>  PortSystem 1.0
>  PortGroup perl5 1.0
>
> -perl5.setup             ikiwiki 1.47
> +perl5.setup             ikiwiki 2.51
>  name                    ikiwiki
> -categories		www perl
> +version                 2.51

I don't think you need to add the version field for perl5-portgroup  
ports. I think it handles that automatically.

> +categories              www perl
>  description             A wiki compiler.
> -long_description        ${description}
> -homepage                http://ikiwiki.kitenet.net/
> -maintainers             paul.totterman at gmail.com
> +long_description        Ikiwiki is a wiki compiler. It converts  
> wiki pages \
> +                        into HTML pages suitable for publishing on  
> a website. \
> +                        Ikiwiki stores pages and history in a  
> revision control \
> +                        system such as Subversion or Git. There  
> are many other \
> +                        features, including support for blogging,  
> as well as a \
> +                        large array of plugins.
> +homepage                http://ikiwiki.info/
> +maintainers             tommyd at macports.org

To reduce spam, you might want to use the short form (just write  
"tommyd" instead of your full email address).

>  platforms               darwin
>  master_sites            http://ftp.debian.org/debian/pool/main/i/ 
> ikiwiki/
>  distname                ${name}_${version}
>  worksrcdir              ${name}
> -checksums		md5 2463a50af5b5587bc2444e89c2edcb46 \
> -			sha1 f4d6ecc2d16b96da57812e1dcb332bf8cacc2e2d \
> -			rmd160 fe5563ef36cd27fe258ac654bd1496e932b1c77f
>
> +checksums               md5 4423258ab049d5441225027704fd2d1a \
> +                        sha1  
> c8c30cb78dea19ee60385bb81f73d2ff9a42f72b \
> +                        rmd160  
> b023427675268c731e5d54eefc90d937e4d41a3d
> +
>  depends_build           port:perl5.8 port:coreutils
> -depends_lib-append      port:p5-text-markdown port:p5-html-template \
> -                        port:p5-html-scrubber port:p5-uri port:p5- 
> perlmagick \
> -			port:p5-cgi-formbuilder port:p5-timedate port:p5-mail-sendmail \
> -			port:p5-time-duration port:p5-xml-sax-expat
>
> +# needed modules (see Bundles/IkiWiki.pm)
> +depends_lib-append      port:p5-cgi \
> +                        port:p5-cgi-formbuilder \
> +                        port:p5-cgi-session \
> +                        port:p5-data-dumper \
> +                        port:p5-html-parser \
> +                        port:p5-html-scrubber \
> +                        port:p5-html-parser \
> +                        port:p5-mail-sendmail \
> +                        port:p5-text-markdown \
> +                        port:p5-uri \
> +                        port:p5-timedate \
> +                        port:p5-xml-simple
> +
> +# a couple of optional extra modules bundled from MacPorts used by  
> plugins
> +# (for a complete list see Bundles/IkiWiki/Extras.pm)
> +depends_lib-append      port:p5-crypt-ssleay \
> +                        port:p5-digest-sha1 \
> +                        port:p5-file-mimeinfo \
> +                        port:p5-locale-gettext \
> +                        port:p5-text-csv \
> +                        port:p5-text-wikiformat \
> +                        port:p5-xml-feed
> +
>  destroot.target         CP=gcp install
>  configure.args          INSTALLDIRS=vendor PREFIX=${prefix}
>
>  post-patch {
> -	reinplace "s|/usr/bin/perl|${prefix}/bin/perl|g" \
> -		${worksrcpath}/ikiwiki.in \
> -		${worksrcpath}/IkiWiki.pm \
> -		${worksrcpath}/Makefile.PL \
> -		${worksrcpath}/ikiwiki-mass-rebuild \
> -		${worksrcpath}/ikiwiki-w3m.cgi \
> -		${worksrcpath}/ikiwiki.in \
> -		${worksrcpath}/mdwn2man \
> -		${worksrcpath}/pm_filter
> +    reinplace "s|/usr/bin/perl|${prefix}/bin/perl|g" \
> +        ${worksrcpath}/ikiwiki.in \
> +        ${worksrcpath}/IkiWiki.pm \
> +        ${worksrcpath}/Makefile.PL \
> +        ${worksrcpath}/ikiwiki-mass-rebuild \
> +        ${worksrcpath}/ikiwiki-transition \
> +        ${worksrcpath}/ikiwiki-update-wikilist \
> +        ${worksrcpath}/ikiwiki-w3m.cgi \
> +        ${worksrcpath}/ikiwiki.in \
> +        ${worksrcpath}/docwiki.setup \
> +        ${worksrcpath}/mdwn2man \
> +        ${worksrcpath}/pm_filter
>  }


It would be nice if in the future you could make purely whitespace  
changes in a separate commit from functional changes.




From ryandesign at macports.org  Fri Jul 11 16:04:34 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 11 Jul 2008 18:04:34 -0500
Subject: molden and distfiles mirror
In-Reply-To: <08FFD295-B0A2-42E0-8C60-F760F26F7AD7@apple.com>
References: <8F8449AF-749F-4504-B9DB-6CD491DF29C1@macports.org>
	<08FFD295-B0A2-42E0-8C60-F760F26F7AD7@apple.com>
Message-ID: <38D309B3-A9FE-4347-949A-D0344FD732FD@macports.org>


On Jul 11, 2008, at 09:11, William Siegrist wrote:

> On Jul 11, 2008, at 1:54 AM, Ryan Schmidt wrote:
>
>> The molden port says:
>>
>>> # I (Jochen K?pper) got explicit permission to distribute molden  
>>> as a
>>> # MacPorts port, given that the source-code is always downloaded  
>>> from
>>> # the authors webpage and we add a banner asking users to  
>>> register at
>>> # the following web-page: http://www.cmbi.ru.nl/molden/form.html
>>
>> What are the implications now that MacPorts mirrors distfiles at
>> distfiles.macports.org?
>
> Restrictions like this need to be mailed to me so I can remove the  
> port from the mirror process. I'll take care of this today. If  
> someone wants to ask the dev about mirroring it, I can always re- 
> add later but sounds like they wont want that.

We need to add a keyword to the portfile syntax for this.
What should it be?
"fetch.mirror", default "yes", can be set to "no" by portfile authors?
Or should it not be linked with the fetch phase?
"mirror_distfile" default "yes"?
"allow_distfile_mirror"
"allow_mirroring"



From ryandesign at macports.org  Fri Jul 11 16:06:19 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 11 Jul 2008 18:06:19 -0500
Subject: Meaning of 
In-Reply-To: <loom.20080711T215556-334@post.gmane.org>
References: <64c81f720807110742q4d6edf85o93856bddd6dc127b@mail.gmail.com>
	<loom.20080711T215556-334@post.gmane.org>
Message-ID: <7B7FB0F7-AFAA-44B6-8C71-4F8DD4E5BCC5@macports.org>


On Jul 11, 2008, at 17:07, Marcus wrote:

> Uldis Bojars <captsolo at ...> writes:
>
>>
>>> Marcus Calhoun-Lopez wrote:
>>>>> I am experimenting with a local version of graphviz.
>>>>> During the activation phase, I get the error:
>>>>> Error: Target org.macports.activate returned: Not a directory
>>>>>
>>>>> Does anyone know the meaning of this error?
>>> [...]
>>
>> If this error appears in multiple packages (not for everyone,  
>> perhaps)
>> it would be good to have a FAQ entry on how to fix it.
>> [...]
>>
>> Marcus: did the same problem with Graphviz appear if you compile it
>> with Python 2.4?
>
> Yes, the error is reproducible with using the variant "graphviz  
> +python,"
> which uses Python 2.4.

I did experience the problem too trying to update graphviz to use  
python25 and php5 instead of python24 and php4. It makes no sense to  
keep graphviz depending on python24 and php4 because it also depends  
on swig which itself now depends on python25 and php5.

I do not know what is going on with the "Not a directory" error. I  
need someone who knows something about Python to look into it.



From wsiegrist at apple.com  Fri Jul 11 16:07:13 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Fri, 11 Jul 2008 16:07:13 -0700
Subject: molden and distfiles mirror
In-Reply-To: <8F8449AF-749F-4504-B9DB-6CD491DF29C1@macports.org>
References: <8F8449AF-749F-4504-B9DB-6CD491DF29C1@macports.org>
Message-ID: <CA68698E-07E1-4FBB-A30F-0BE82B5183C8@apple.com>

On Jul 11, 2008, at 1:54 AM, Ryan Schmidt wrote:

> The molden port says:
>
>> # I (Jochen K?pper) got explicit permission to distribute molden as a
>> # MacPorts port, given that the source-code is always downloaded from
>> # the authors webpage and we add a banner asking users to register at
>> # the following web-page: http://www.cmbi.ru.nl/molden/form.html
>
>
> What are the implications now that MacPorts mirrors distfiles at
> distfiles.macports.org?
>

The molden distfiles have been removed and an exception has been added  
to the daily mirror job.

-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/20080711/8857de50/attachment.bin 

From captsolo at gmail.com  Fri Jul 11 16:35:30 2008
From: captsolo at gmail.com (Uldis Bojars)
Date: Sat, 12 Jul 2008 00:35:30 +0100
Subject: Meaning of
In-Reply-To: <7B7FB0F7-AFAA-44B6-8C71-4F8DD4E5BCC5@macports.org>
References: <64c81f720807110742q4d6edf85o93856bddd6dc127b@mail.gmail.com>
	<loom.20080711T215556-334@post.gmane.org>
	<7B7FB0F7-AFAA-44B6-8C71-4F8DD4E5BCC5@macports.org>
Message-ID: <64c81f720807111635h799df04fl732bed90ddbe8738@mail.gmail.com>

On Sat, Jul 12, 2008 at 12:06 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
>>> Marcus: did the same problem with Graphviz appear if you compile it
>>> with Python 2.4?
>>
>> Yes, the error is reproducible with using the variant "graphviz
>> +python,"
>> which uses Python 2.4.
>
> I did experience the problem too trying to update graphviz to use
> python25 and php5 instead of python24 and php4. It makes no sense to
> keep graphviz depending on python24 and php4 because it also depends
> on swig which itself now depends on python25 and php5.
>
> I do not know what is going on with the "Not a directory" error. I
> need someone who knows something about Python to look into it.

It also needs someone with good knowledge of MacPorts which you may have.

The error does not happen in Python code (though it may be triggered
by something from earlier on in the compilation process) unless there
is Python code being executed during port activation. Marcus wrote
that the error also appears for him if compiling with Python 2.4 which
means the problem is not specific to Python 2.5 either.

Let's assume for a moment that "Not a directory" errors from different
ports (with Python bindings generated by SWIG) are caused by the same
problem. If so, we can use a fragment of a detailed error log from
http://lists.macosforge.org/pipermail/macports-users/2008-July/010888.html
(below). I can not say more w/o detailed knowledge of port activation
process, but it looks like the error happens at the very end when
files are being added to the file_map.

Perhaps the problem is related to the directory layout of how Python
(python24, python25) is installed by MacPorts?

Uldis

----
...
DEBUG: activating file: /opt/local/share/sip/PyQt4/phonon/videoplayer.sip
DEBUG: activating file: /opt/local/share/sip/PyQt4/phonon/videowidget.sip
DEBUG: activating file: /opt/local/share/sip/PyQt4/phonon/volumeslider.sip
DEBUG: Adding file to file_map:
/opt/local/Library/Frameworks/Python.framework/Versions/2.5/bin/pylupdate4
for: py25-pyqt4
DEBUG: Adding file to file_map:
/opt/local/Library/Frameworks/Python.framework/Versions/2.5/bin/pyrcc4
for: py25-pyqt4
DEBUG: Adding file to file_map:
/opt/local/Library/Frameworks/Python.framework/Versions/2.5/bin/pyuic4
for: py25-pyqt4
DEBUG: Adding file to file_map:
/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/PyQt4/__init__.py
for: py25-pyqt4
Error: Target org.macports.activate returned: Not a directory
Warning: the following items did not execute (for py25-pyqt4):
org.macports.activate
Error: Status 1 encountered during processing.
----

From loshea at gmail.com  Fri Jul 11 19:43:06 2008
From: loshea at gmail.com (Luis O'Shea)
Date: Fri, 11 Jul 2008 22:43:06 -0400
Subject: Port update needs commit
Message-ID: <a87d8aa50807111943m3aeb1978r28185ea7a737aff4@mail.gmail.com>

I have upgraded the asymptote port, see

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

Could someone commit it?

Thanks,

Luis

From simon at ruderich.com  Sat Jul 12 02:31:25 2008
From: simon at ruderich.com (Simon Ruderich)
Date: Sat, 12 Jul 2008 11:31:25 +0200
Subject: Port update needs commit
In-Reply-To: <a87d8aa50807111943m3aeb1978r28185ea7a737aff4@mail.gmail.com>
References: <a87d8aa50807111943m3aeb1978r28185ea7a737aff4@mail.gmail.com>
Message-ID: <20080712093124.GA5194@ruderich.com>

On Fri, Jul 11, 2008 at 10:43:06PM -0400, Luis O'Shea wrote:
> I have upgraded the asymptote port, see
> 
> http://trac.macports.org/ticket/15936
> 
> Could someone commit it?
> 
> Thanks,
> 
> Luis

Committed in r38199.

Thanks for your help,
Simon
-- 
+ privacy is necessary
+ using http://gnupg.org
+ public key id: 0x6115F804EFB33229
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080712/f9696983/attachment.bin 

From raimue at macports.org  Sat Jul 12 10:29:51 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 12 Jul 2008 19:29:51 +0200
Subject: molden and distfiles mirror
In-Reply-To: <38D309B3-A9FE-4347-949A-D0344FD732FD@macports.org>
References: <8F8449AF-749F-4504-B9DB-6CD491DF29C1@macports.org>	<08FFD295-B0A2-42E0-8C60-F760F26F7AD7@apple.com>
	<38D309B3-A9FE-4347-949A-D0344FD732FD@macports.org>
Message-ID: <4878EA0F.5000705@macports.org>

Ryan Schmidt wrote:
> We need to add a keyword to the portfile syntax for this.
> What should it be?
> "fetch.mirror", default "yes", can be set to "no" by portfile authors?
> Or should it not be linked with the fetch phase?
> "mirror_distfile" default "yes"?
> "allow_distfile_mirror"
> "allow_mirroring"

There was the idea to add general license information into Portfiles 
before. As this is part of the license it would make sense to bundle 
fetch restrictions with it. But on the other hand this does not happen 
that often and licenses preventing mirroring are mostly custom for only 
one project, so we would not gain much from it.

I like "fetch.mirror" best. In my opinion it is kind of linked with the 
fetch phase. 'port mirror' is also using other variables and code from 
fetch anyway.

Rainer


From raimue at macports.org  Sat Jul 12 11:40:56 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 12 Jul 2008 20:40:56 +0200
Subject: Meaning of "Not a directory"
In-Reply-To: <E71BEF4E-22D6-41C5-9859-BD193D9CE738@macports.org>
References: <E71BEF4E-22D6-41C5-9859-BD193D9CE738@macports.org>
Message-ID: <4878FAB8.1010309@macports.org>

Marcus Calhoun-Lopez wrote:
> I am experimenting with a local version of graphviz.
> During the activation phase, I get the error:
> Error: Target org.macports.activate returned: Not a directory
> 
> Does anyone know the meaning of this error?

This happens when 'port activate' finds something unexpected. For
example, assume /opt/local/foo is a symlink to another directory. Now
port tries to activate the file /opt/local/foo/bar, but it can't do that
because /opt/local/foo is not a directory.

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.

Rainer

From florian.ebeling at gmail.com  Sat Jul 12 12:04:08 2008
From: florian.ebeling at gmail.com (Caspar Florian Ebeling)
Date: Sat, 12 Jul 2008 21:04:08 +0200
Subject: Ruby ports and 1.9
In-Reply-To: <4878A918.2010506@shopwatch.org>
References: <5cbbe4ae0807081543w3ebdb435s771b7b0e06ec11a6@mail.gmail.com>
	<4874066C.3000505@macports.org> <4878A918.2010506@shopwatch.org>
Message-ID: <5cbbe4ae0807121204w2486cec0g5ba26dfcba1519df@mail.gmail.com>

>>> I have other issues myself. It is not entirely convincing to install
>>> ruby libraries
>>> via a generic package manager like mp, given that ruby has it's own in
>>> the
>>> form of Rubygems, which even comes builtin with 1.9.
>>
>> The same thing applies to Perl. There is CPAN which distributes nearly
>> every Perl module available. But the problem is that you can't declare a
>> dependency on a specific module without a port.
>
> The problem goes both ways, though; you can't install a gem with
> dependencies unless you also install that gem!

if you have a port which has install type gem, then mp is only a frontend
above gem and uses it, putting it's own dependencies mechanism
in place instead. So if you install gems via mp and then add a gem
directly, gem will see this and use it as a dependency. So what you
say is not quite correct, I think.

>
> I realize that this is true for CPAN as well; however, RubyGems is more
> "socially integrated" into the Ruby world, even if it wasn't an official
> part of Ruby until 1.9.  I'd venture that the vast majority of Ruby users
> install RubyGems directly after installing Ruby.

Agreed, everybody will have it. But it never worked that great for me for
things slightly off the beaten rails track. And there have always been
voices critizising rubygems, favoring setup.rb and install.rb.

>
> Except for Rails plugins (which couldn't be gems themselves until recently,
> but which still required RubyGems to be installed), I haven't seen anything
> distributed as other than a gem in the past few years.

This is not my experience. I think it is true for the vast majority of
things in the
rails ecosystem, but older libraries are rarely gems. One example I
ecountered lately is ruby-mmap. This one esoteric, but there are plenty of
other examples I guess.

>
> To me, in the Ruby world, the right way to install a gem is to use "gem
> install".  That whole infrastructure shouldn't be duplicated in the MacPorts
> world, any more than you'd create a port for each Firefox extension.

Admitted. Only mp does not duplicate rubygems, but rather layers over
it, installing packages as gems if the port maintainer wants. It does
duplicate the
indexes of rubygems, which are a weak point of it anyway (slowness!).
I don't know how
much this has been improved with 1.2.0 now. But I just tried to install mysql
with gem1.9 and it still fetchs mysql2.7, even though 2.8pre-something is the
one which is compatible with ruby1.9.

This could be smoothed over by mp, and all we have to do is to decide not to
drop support for ruby ports with ruby1.9. To provide for that is what my
patch is for.

> So to me, the question is: Are there actually ports that depend on gems, but
> aren't gems themselves?  If so, how hard would it be to create a fake
> "gem-dependency" port, which will get auto-installed as a dependency by
> those ports, and which will in turn "succeed" by verifying that the given
> gem is installed?

I think a port would be nice for any ruby library or program which does not
come as a gem, or for which the author is not much bothered to keep
the gem index current.

>> Also, in my opinion it's easier for users to use only one package manager
>> (like MacPorts) to install software. Using cpan, gem and others additionally
>> might not be that easy. Especially this comes true when using a GUI.
>
> If you're using Ruby, you're at the command line at some point to run your
> code

I don't think this is necessarily true. Especially now that there is quite some
thinking about improving gui toolkits in the ruby community. And once they
get more mainstream some nice broad-audience tool might come out of it.

Actually I think we should not drop support for ruby1.9 ports (that's
why I wrote the
patch after all).



Florian




-- 
Florian Ebeling
florian.ebeling at gmail.com

From kimuraw at macports.org  Sun Jul 13 04:00:59 2008
From: kimuraw at macports.org (kimura wataru)
Date: Sun, 13 Jul 2008 20:00:59 +0900
Subject: Ruby ports and 1.9
In-Reply-To: <5cbbe4ae0807081543w3ebdb435s771b7b0e06ec11a6@mail.gmail.com>
References: <5cbbe4ae0807081543w3ebdb435s771b7b0e06ec11a6@mail.gmail.com>
Message-ID: <20080713200059983128.8fc063c3@macports.org>

Hi Florian,

It's a very interesting plan!
But I think that is better to separate rb-* and rb19-* for some reasons.

* Ruby 1.9 is not stable version. I think 1.8 is still needed
  for daily work on 1.9 installed environment.
* So, it is important we can install, upgrade, uninstall rb-* and rb19-*
  separately.

I have an inspiration from your email and ticket.
This feature makes easy to write rb19-* portfiles.

like this,

  % port cat rb19-rails
  PortSystem 1.0
  PortGroup  ruby 1.0
  ruby.import rb-rails 1.9
  %

The proc ruby.import reads rb-rails Portfile (for 1.8)
and process portfile with Florian's extension for 1.9 (#15912)
and modify some attributes of the original portfile dynamically.

[rewrite]
  name: rb-rails -> rb19-rails
  depends_lib: ruby, rb-rubygems, rb-rake, ...
            -> ruby19, rb19-rubygems, rb19-rake, ...
               
[append]
  configure.args-append --program-suffix=1.9

We can generate almost of rb19-* portfiles with a short script,
if this approach is available.

On Wed, 9 Jul 2008 00:43:05 +0200, Caspar Florian Ebeling wrote:
> Hi,
> 
> Yesterday, I have put a patch for ruby group into the trac, which changes
> the ruby.setup command so that it accepts an additional parameter.
> With it applied
> ports for ruby19 can be installed using the port group. These would get
> a prefix of rb19 instead of rb, following the python example. Find it here:
> 
> http://trac.macports.org/ticket/15912
> 
> Rainer raised the concern, that these version-specific ports are a bit of
> a duplication, and that the experience with python was not really spotless.
> See his comment in the ticket. I see this problem as well.
> 
> I have other issues myself. It is not entirely convincing to install
> ruby libraries
> via a generic package manager like mp, given that ruby has it's own in the
> form of Rubygems, which even comes builtin with 1.9.
> 
-- 
kimura wataru

From frstan at bellsouth.net  Sun Jul 13 09:23:49 2008
From: frstan at bellsouth.net (William Davis)
Date: Sun, 13 Jul 2008 12:23:49 -0400
Subject: New XCode version
Message-ID: <E74D3423-D878-4FF3-98A6-0DAACD4656FA@bellsouth.net>

FYI: a new version of XCode dated 11 July 08 is available on ADC.   
Interestingly, it includes gcc 4.2 as well as 4.0.


William Davis
frstanATbellsouthDOTnet
Mac OS X.5.4 Darwin 9.4.0
Xquartz 2.2.3 - (xorg-server 1.3.0-apple21)
Mac Mini Intel Duo @ 1.86 GHz

Mundus vult decepi, ego non


From captsolo at gmail.com  Sun Jul 13 12:24:43 2008
From: captsolo at gmail.com (Uldis Bojars)
Date: Sun, 13 Jul 2008 20:24:43 +0100
Subject: updates for redland-bindings
Message-ID: <64c81f720807131224i3e24345fie758d22c1eb68565@mail.gmail.com>

Hi,

Could the admins please "bump" this port up to the most recent
software version ( http://trac.macports.org/ticket/15921 ) and add
"openmaintainer" or "nomaintainer" to the port (if appropriate)?

The reason for asking this is because it looks like redland-bindings
is currently not being maintained - there are 3 and 6 months old
tickets [1,2] on redland-bindings port which have had no response from
the maintainer.

[1] http://trac.macports.org/ticket/13838
[2] http://trac.macports.org/ticket/14956

The old tickets themselves do not need more attention though because
version 1.0.8.1 addresses the bug described in [1]. And [2] is an
earlier request for version update.

P.S. This port also has an activation bug in +python version (similar
as some other SWIG-generated Python bindings) discussed on this list
under the topic: Meaning of "Not a directory".

CC: maintainer of redland-bindings

Thanks,
Uldis

From florian.ebeling at gmail.com  Sun Jul 13 12:57:12 2008
From: florian.ebeling at gmail.com (Caspar Florian Ebeling)
Date: Sun, 13 Jul 2008 21:57:12 +0200
Subject: Ruby ports and 1.9
In-Reply-To: <20080713200059983128.8fc063c3@macports.org>
References: <5cbbe4ae0807081543w3ebdb435s771b7b0e06ec11a6@mail.gmail.com>
	<20080713200059983128.8fc063c3@macports.org>
Message-ID: <5cbbe4ae0807131257v12b4ee2fr33e4f069ea03e412@mail.gmail.com>

> It's a very interesting plan!
> But I think that is better to separate rb-* and rb19-* for some reasons.
>
> * Ruby 1.9 is not stable version. I think 1.8 is still needed
>  for daily work on 1.9 installed environment.
> * So, it is important we can install, upgrade, uninstall rb-* and rb19-*
>  separately.

Absolutely, that's exactly what I think, and actually my patch
does that alreday.

> I have an inspiration from your email and ticket.
> This feature makes easy to write rb19-* portfiles.
>
> like this,
>
>  % port cat rb19-rails
>  PortSystem 1.0
>  PortGroup  ruby 1.0
>  ruby.import rb-rails 1.9
>  %
>
> The proc ruby.import reads rb-rails Portfile (for 1.8)
> and process portfile with Florian's extension for 1.9 (#15912)
> and modify some attributes of the original portfile dynamically.

yeah, that would be a cool feature indeed. Although, it would
be rather quite a different thing when put in code. But the aim
to minimize duplication whereever possible is worth quite
some effort.

Otoh, ruby.setup ports are usually quite brief already. Don't
know what is best, maybe we can implement ruby.import
as well and see which share of existing can be properly
expressed as derived ports for 1.9 version.

> [rewrite]
>  name: rb-rails -> rb19-rails
>  depends_lib: ruby, rb-rubygems, rb-rake, ...
>            -> ruby19, rb19-rubygems, rb19-rake, ...
>
> [append]
>  configure.args-append --program-suffix=1.9

Maybe that's all what is needed to to. Port authors
tend to do curious things though, as I have learnt lately.
Some experimentation would be in order I guess.

For the patch in question, do you think we should
integrate it into trunk as is as well, or rather work
more into the direction of a "derived-but-new-version"
kind of feature like you suggest. It appears to me
that we still need a plain support as well, since there
is not necessarily an 1.8 version of a port.

Florian

-- 
Florian Ebeling
florian.ebeling at gmail.com

From armahg at gmail.com  Sun Jul 13 15:02:31 2008
From: armahg at gmail.com (George Armah)
Date: Sun, 13 Jul 2008 18:02:31 -0400
Subject: MacPorts.Framework MidTerm Evaluation Release for Feedback
Message-ID: <487A7B77.4050109@gmail.com>

Hello all,
Google Summer of Code mid term evaluations are due on July 14th. So it 
doesn't seem
like I have / was / had been working in the dark all summer I thought it 
would be fitting
to release an MidTerm Evaluation version of the current Framework along 
with its
attendant Documentation.

Please note that the current Framework HAS NOT BEEN THOROUGHLY TESTED.
I am looking for any and all kinds of feedback e.g. basic functionality 
that might be lacking,
design changes. Also, you can look at the code in my
svn repo 
(http://svn/macosforge.org/repository/macports/branches/gsoc08-framework/MacPorts_Framework)
if you are interested in implementation details. Please let me know of 
any glaring mistakes.

Functionality for Notifications, Authorizations and a thorough Testing 
Bundle are the main things that are yet to
be added to the Framework. I have been keeping "track" of my work here
http://trac.macports.org/wiki/MPFramworkGSocWk for those who are interested.

There is
a .dmg 
(http://svn.macosforge.org/repository/macports/users/armahg/MacPorts_Framework/MPFMidtermRelease.dmg)
and a .zip 
(http://svn.macosforge.org/repository/macports/users/armahg/MacPorts_Framework/MPFMidtermRelease.zip)
available for download.

You can send feedback to armahg at macports.org or simply reply to this thread.

Thanks in advance,

George.





From florian.ebeling at gmail.com  Sun Jul 13 15:30:26 2008
From: florian.ebeling at gmail.com (Caspar Florian Ebeling)
Date: Mon, 14 Jul 2008 00:30:26 +0200
Subject: [34218] trunk/dports/lang
In-Reply-To: <2CB32F21-AFB9-4DC8-A65B-6206E3E2D14A@macports.org>
References: <20080218091344.7F0AE12AF382@beta.macosforge.org>
	<2CB32F21-AFB9-4DC8-A65B-6206E3E2D14A@macports.org>
Message-ID: <5cbbe4ae0807131530w6e074e18m39146dd6c30a9e0@mail.gmail.com>

On Mon, Feb 18, 2008 at 11:48 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Feb 18, 2008, at 03:13, erickt at macports.org wrote:
>> +post-destroot {
>> +  cd ${destroot}${prefix}
>
> Please don't use the "cd" command. It does not exist in MacPorts
> trunk and will not exist in MacPorts 1.7.0 and later.

What is the whole story to this change? Does "cd" work in 1.6 but
not in trunk? Why was it necessary and is no longer? Is this documented
somewhere maybe? Just curious because I ran into build problems
with this in a very recently changed port, so some configurations
apparently do accept it, while trunk does not.

Florian


-- 
Florian Ebeling
florian.ebeling at gmail.com

From bwaters at nrao.edu  Sun Jul 13 16:02:58 2008
From: bwaters at nrao.edu (Boyd Waters)
Date: Sun, 13 Jul 2008 17:02:58 -0600
Subject: New XCode version
In-Reply-To: <E74D3423-D878-4FF3-98A6-0DAACD4656FA@bellsouth.net>
References: <E74D3423-D878-4FF3-98A6-0DAACD4656FA@bellsouth.net>
Message-ID: <256D8E24-0756-4600-94A7-4238B60E41F0@nrao.edu>

On Jul 13, 2008, at 10:23 AM, William Davis wrote:

> FYI: a new version of XCode dated 11 July 08 is available on ADC.
> Interestingly, it includes gcc 4.2 as well as 4.0.


Interesting; it's probably the iPhone SDK version that shipped last  
Friday.

Apple has been great about posting the GCC 4.0 patches associated with  
the various iPhone SDK releases, but they haven't released the patches  
for GCC 42 (last gcc-4.2 patch was 5553).

See
http://www.opensource.apple.com/darwinsource/tarballs/other/
http://r.research.att.com

I expect that they will eventually release newer patches, I could  
really use them!

I am *almost* done with a full quad-architecture (ppc,intel,32-bit,64- 
bit) GCC 4.2 that incorporates changes from AT&T so that gfortran can  
be built as well as Objective-C. But it requires testing.

Here's what I've got so far... so close...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Portfile
Type: application/octet-stream
Size: 6605 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080713/93d7a294/attachment-0002.obj 
-------------- next part --------------



-------------- next part --------------
A non-text attachment was scrubbed...
Name: make-universal-gcc.sh
Type: application/octet-stream
Size: 3743 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080713/93d7a294/attachment-0003.obj 
-------------- next part --------------




I'd really like newer patches from Apple, because Apple builds before  
5555 have an inline-assembly bug (rdar://5705060)


- boyd

Boyd Waters
Scientific Programmer
National Radio Astronomy Observatory
https://wikio.nrao.edu/bin/view/Software/ObtainingCasaMacIntel


From ryandesign at macports.org  Sun Jul 13 16:53:17 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 13 Jul 2008 18:53:17 -0500
Subject: New XCode version
In-Reply-To: <E74D3423-D878-4FF3-98A6-0DAACD4656FA@bellsouth.net>
References: <E74D3423-D878-4FF3-98A6-0DAACD4656FA@bellsouth.net>
Message-ID: <E33EC0E2-301C-4EB8-826A-0C3322CE027E@macports.org>


On Jul 13, 2008, at 11:23, William Davis wrote:

> FYI: a new version of XCode dated 11 July 08 is available on ADC.
> Interestingly, it includes gcc 4.2 as well as 4.0.

Yes, Xcode 3.1 has been released.

Also, the first non-beta version of the iPhone SDK has been released.  
It includes the full Xcode 3.1, so if you want the iPhone SDK, get  
just the iPhone SDK download; you do not need to separately install  
Xcode 3.1.



From ryandesign at macports.org  Sun Jul 13 17:09:23 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 13 Jul 2008 19:09:23 -0500
Subject: [34218] trunk/dports/lang
In-Reply-To: <5cbbe4ae0807131530w6e074e18m39146dd6c30a9e0@mail.gmail.com>
References: <20080218091344.7F0AE12AF382@beta.macosforge.org>
	<2CB32F21-AFB9-4DC8-A65B-6206E3E2D14A@macports.org>
	<5cbbe4ae0807131530w6e074e18m39146dd6c30a9e0@mail.gmail.com>
Message-ID: <24AAFA06-87A3-4247-8574-EE2C3C8BC8E9@macports.org>


On Jul 13, 2008, at 17:30, Caspar Florian Ebeling wrote:

> On Mon, Feb 18, 2008 at 11:48 AM, Ryan Schmidt wrote:
>
>> On Feb 18, 2008, at 03:13, erickt at macports.org wrote:
>>
>>> +post-destroot {
>>> +  cd ${destroot}${prefix}
>>
>> Please don't use the "cd" command. It does not exist in MacPorts
>> trunk and will not exist in MacPorts 1.7.0 and later.
>
> What is the whole story to this change? Does "cd" work in 1.6 but
> not in trunk? Why was it necessary and is no longer? Is this  
> documented
> somewhere maybe? Just curious because I ran into build problems
> with this in a very recently changed port, so some configurations
> apparently do accept it, while trunk does not.


The "cd" command changes the working directory for the tcl  
interpreter, and this change lives on until the tcl interpreter  
stops. This means that if you "cd" somewhere in, say, the configure  
phase, then the interpreter will still be in that directory in the  
build and destroot and activate phases. If a portfile relies on this,  
it can be confusing to people trying to understand how a portfile  
works. There may also be other reasons that I have forgotten at this  
time.

I think it was never intended for ports to use the "cd" command, but  
many port did, and its use went undetected (or those who noticed its  
use didn't think anything of it) until after the release of MacPorts  
1.5.0. The "cd" command was going to be removed in MacPorts 1.6.0 but  
there were still so many ports using it that "cd" was retained in  
1.6.0. But it is absent in trunk (which will be 1.7.0 one day). The  
use of the "cd" command should be removed from all ports.


See:

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


From mark at dxradio.demon.co.uk  Sun Jul 13 17:37:19 2008
From: mark at dxradio.demon.co.uk (Mark Hattam)
Date: Mon, 14 Jul 2008 01:37:19 +0100
Subject: New XCode version
In-Reply-To: <256D8E24-0756-4600-94A7-4238B60E41F0@nrao.edu>
References: <E74D3423-D878-4FF3-98A6-0DAACD4656FA@bellsouth.net>
	<256D8E24-0756-4600-94A7-4238B60E41F0@nrao.edu>
Message-ID: <p06240801c4a04fd77257@[192.168.0.2]>

>On Jul 13, 2008, at 10:23 AM, William Davis wrote:
>
>>FYI: a new version of XCode dated 11 July 08 is available on ADC.
>>Interestingly, it includes gcc 4.2 as well as 4.0.


But it will only install on 10.5.x ... 10.4.x and earlier need not 
apply (and save the 1 GB download time)


Mark

From bwaters at nrao.edu  Sun Jul 13 22:47:27 2008
From: bwaters at nrao.edu (Boyd Waters)
Date: Sun, 13 Jul 2008 23:47:27 -0600
Subject: gcc 4.2 on 10.4 tiger: ld: unknown flag: -compatibility_version
In-Reply-To: <487ABD8C.4030801@pogma.com>
References: <20080713140849.98280@gmx.net>	<C4E52EAB-3142-4DB8-9DBA-69736F6F56D2@apple.com>	<ADCFB561-D989-4093-B176-CB0B318CC19E@nrao.edu>
	<20080713233447.307110@gmx.net> <487AA952.9040606@pogma.com>
	<20080714015536.307090@gmx.net> <487ABD8C.4030801@pogma.com>
Message-ID: <723866BC-F797-4F6B-9D5F-D69F0AD87AD1@nrao.edu>


On Jul 13, 2008, at 8:44 PM, Peter O'Gorman wrote:

> Easiest solutions are to update the libtool version in the package  
> that
> you are attempting to build (autoreconf -fi) or simple sed out ${wl}
> before the -compatibility_version etc in ltmain.sh
>
> This is what I committed when the gcc build problem was reported:
>
> http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commitdiff;h=eee885d7c58eea2b9fef52798ef2a1e7adb9be4f
>
> Using sed to remove the '${wl}' from verstring in ltmain.sh before
> configure should work fine:
> sed -e '/verstring=/s/\${wl}//g' < ltmain.sh > ltmain.fixed; mv
> ltmain.fixed ltmain.sh


Peter:

This explanation helps me a *lot*, thanks!

In our collection of ~50 MacPorts, I've had to twiddle libtool in a  
number of them. I just applied a patch to the libtool script that  
comes with the package, essentially what your sed example does.  Now I  
know why.



From florian.ebeling at gmail.com  Mon Jul 14 00:08:28 2008
From: florian.ebeling at gmail.com (Caspar Florian Ebeling)
Date: Mon, 14 Jul 2008 09:08:28 +0200
Subject: [34218] trunk/dports/lang
In-Reply-To: <24AAFA06-87A3-4247-8574-EE2C3C8BC8E9@macports.org>
References: <20080218091344.7F0AE12AF382@beta.macosforge.org>
	<2CB32F21-AFB9-4DC8-A65B-6206E3E2D14A@macports.org>
	<5cbbe4ae0807131530w6e074e18m39146dd6c30a9e0@mail.gmail.com>
	<24AAFA06-87A3-4247-8574-EE2C3C8BC8E9@macports.org>
Message-ID: <5cbbe4ae0807140008h39ebd587ua93e98de6dfe5bd0@mail.gmail.com>

>>> Please don't use the "cd" command. It does not exist in MacPorts
>>> trunk and will not exist in MacPorts 1.7.0 and later.
>>
>> What is the whole story to this change? Does "cd" work in 1.6 but
>> not in trunk? Why was it necessary and is no longer? Is this documented
>> somewhere maybe? Just curious because I ran into build problems
>> with this in a very recently changed port, so some configurations
>> apparently do accept it, while trunk does not.
>
>
> The "cd" command changes the working directory for the tcl interpreter, and
> this change lives on until the tcl interpreter stops. This means that if you
> "cd" somewhere in, say, the configure phase, then the interpreter will still
> be in that directory in the build and destroot and activate phases. If a
> portfile relies on this, it can be confusing to people trying to understand
> how a portfile works. There may also be other reasons that I have forgotten
> at this time.

Yes, I share such concerns about runaway side-effects.

> I think it was never intended for ports to use the "cd" command, but many
> port did, and its use went undetected (or those who noticed its use didn't
> think anything of it) until after the release of MacPorts 1.5.0. The "cd"
> command was going to be removed in MacPorts 1.6.0 but there were still so
> many ports using it that "cd" was retained in 1.6.0. But it is absent in
> trunk (which will be 1.7.0 one day). The use of the "cd" command should be
> removed from all ports.

Ok. Maybe a deprecation period would have smoothed things over a bit
more garcefully, but just turning it off makes for a quicker migration ;)
We will see when 1.7 comes out. (Which hopefully it does some day!)

I'll add a few words to RunningTrunk in the wiki, though. Thanks for
the explanation.

Florian


-- 
Florian Ebeling
florian.ebeling at gmail.com

From raimue at macports.org  Mon Jul 14 07:18:00 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Mon, 14 Jul 2008 16:18:00 +0200
Subject: [34218] trunk/dports/lang
In-Reply-To: <5cbbe4ae0807140008h39ebd587ua93e98de6dfe5bd0@mail.gmail.com>
References: <20080218091344.7F0AE12AF382@beta.macosforge.org>	<2CB32F21-AFB9-4DC8-A65B-6206E3E2D14A@macports.org>	<5cbbe4ae0807131530w6e074e18m39146dd6c30a9e0@mail.gmail.com>	<24AAFA06-87A3-4247-8574-EE2C3C8BC8E9@macports.org>
	<5cbbe4ae0807140008h39ebd587ua93e98de6dfe5bd0@mail.gmail.com>
Message-ID: <487B6018.8000308@macports.org>

Caspar Florian Ebeling wrote:
> Ok. Maybe a deprecation period would have smoothed things over a bit
> more garcefully, but just turning it off makes for a quicker migration ;)
> We will see when 1.7 comes out. (Which hopefully it does some day!)

Actually there was a deprecation period. MacPorts 1.6 spits out a 
warning when 'cd' is used in Portfiles. In 1.7 it will be removed 
completely. In my opinion this is sufficient.

Rainer

From raimue at macports.org  Mon Jul 14 08:35:47 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Mon, 14 Jul 2008 17:35:47 +0200
Subject: Meaning of "Not a directory"
In-Reply-To: <4878FAB8.1010309@macports.org>
References: <E71BEF4E-22D6-41C5-9859-BD193D9CE738@macports.org>
	<4878FAB8.1010309@macports.org>
Message-ID: <487B7253.5070308@macports.org>

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.

If nothing else works, I would have to change the default path of the 
site-packages to be inside the framework and add the symlink at 
${prefix}/lib/python25. But that means, everyone would be forced to 
reinstall any port using python25. And the same change would be needed 
for python24 and python30 as it could appear there, too.

My plan with the symlink in the direction framework -> lib was to avoid 
unnecessary reinstalls.

Rainer

From febeling at macports.org  Mon Jul 14 13:51:58 2008
From: febeling at macports.org (Caspar Florian Ebeling)
Date: Mon, 14 Jul 2008 22:51:58 +0200
Subject: rb-criteria
Message-ID: <5cbbe4ae0807141351i588c709dj8e60df8367d48a35@mail.gmail.com>

While looking a bit closer at all the broken ruby ports which
my regression testing turned up, I encountered some real
cruft. Some of the libraries are really quite abandoned,
like Criteria. This particular one has no active web site any longer,
and can only be found on mirror servers. The unit tests don't
pass anylonger, with errors indicating that the lib does
not work with current day rubys at all, like different return
types. I dont want to assume maintainership of this whole
libary now. Is this maybe the right moment to remove a
port?

Florian






-- 
Florian Ebeling
florian.ebeling at gmail.com

From ryandesign at macports.org  Mon Jul 14 14:35:28 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 14 Jul 2008 16:35:28 -0500
Subject: [34218] trunk/dports/lang
In-Reply-To: <487B6018.8000308@macports.org>
References: <20080218091344.7F0AE12AF382@beta.macosforge.org>	<2CB32F21-AFB9-4DC8-A65B-6206E3E2D14A@macports.org>	<5cbbe4ae0807131530w6e074e18m39146dd6c30a9e0@mail.gmail.com>	<24AAFA06-87A3-4247-8574-EE2C3C8BC8E9@macports.org>
	<5cbbe4ae0807140008h39ebd587ua93e98de6dfe5bd0@mail.gmail.com>
	<487B6018.8000308@macports.org>
Message-ID: <E06E730F-7E6C-4259-9988-BD18B06F2CEC@macports.org>


On Jul 14, 2008, at 09:18, Rainer M?ller wrote:

> Caspar Florian Ebeling wrote:
>
>> Ok. Maybe a deprecation period would have smoothed things over a bit
>> more garcefully, but just turning it off makes for a quicker  
>> migration ;)
>> We will see when 1.7 comes out. (Which hopefully it does some day!)
>
> Actually there was a deprecation period. MacPorts 1.6 spits out a  
> warning when 'cd' is used in Portfiles.

Would be great if it did print a message when "cd" is used, but I  
don't think it does.

> In 1.7 it will be removed completely. In my opinion this is  
> sufficient.


From mcalhoun at macports.org  Mon Jul 14 14:48:36 2008
From: mcalhoun at macports.org (Marcus)
Date: Mon, 14 Jul 2008 21:48:36 +0000 (UTC)
Subject: Meaning of 
References: <E71BEF4E-22D6-41C5-9859-BD193D9CE738@macports.org>
	<4878FAB8.1010309@macports.org> <487B7253.5070308@macports.org>
Message-ID: <loom.20080714T211735-685@post.gmane.org>

Rainer M?ller <raimue at ...> writes:

> 
> 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.
> 
> If nothing else works, I would have to change the default path of the 
> site-packages to be inside the framework and add the symlink at 
> ${prefix}/lib/python25. But that means, everyone would be forced to 
> reinstall any port using python25. And the same change would be needed 
> for python24 and python30 as it could appear there, too.
> 
> My plan with the symlink in the direction framework -> lib was to avoid 
> unnecessary reinstalls.
> 
> Rainer
> 

I believe that in both cases, the problem lies in sys.prefix, which is
${prefix}/Library/Frameworks/Python.framework/Versions/2.5

Just out of curiosity, why is ${prefix}/lib/python25 even necessary?

The package swig picks up the framework directory via the statement
in the configure script:
PYPREFIX=`($PYTHON -c "import sys; print sys.prefix") 2>/dev/null`

The package graphviz picks up the framework directory via the script
config/config_python.py
An equivalent statement is
/opt/local/bin/python2.5 -c
"import sys; from distutils import sysconfig;
print sysconfig.get_python_lib(1,0)"

sysconfig.get_python_lib in turn
(defined in ${prefix}/lib/python2.5/distutils/sysconfig.py)
uses the value of sys.prefix.

-Marcus







From captsolo at gmail.com  Mon Jul 14 15:40:38 2008
From: captsolo at gmail.com (Uldis Bojars)
Date: Mon, 14 Jul 2008 23:40:38 +0100
Subject: Meaning of
In-Reply-To: <loom.20080714T211735-685@post.gmane.org>
References: <E71BEF4E-22D6-41C5-9859-BD193D9CE738@macports.org>
	<4878FAB8.1010309@macports.org> <487B7253.5070308@macports.org>
	<loom.20080714T211735-685@post.gmane.org>
Message-ID: <64c81f720807141540m71796b6em9c5381252b6205a7@mail.gmail.com>

On Mon, Jul 14, 2008 at 10:48 PM, Marcus <mcalhoun at ...> wrote:
>> My plan with the symlink in the direction framework -> lib was to avoid
>> unnecessary reinstalls.
>
> I believe that in both cases, the problem lies in sys.prefix, which is
> ${prefix}/Library/Frameworks/Python.framework/Versions/2.5
>
> Just out of curiosity, why is ${prefix}/lib/python25 even necessary?
>
> The package swig picks up the framework directory via the statement
> in the configure script:
> PYPREFIX=`($PYTHON -c "import sys; print sys.prefix") 2>/dev/null`

Same with ./configure in Redland bindings which picks Python directories from:

  python_prefix=`$PYTHON -c 'import sys; print sys.prefix' 2>/dev/null`
  python_exec_prefix=`$PYTHON -c "import sys; print sys.exec_prefix"`

Uldis

From raimue at macports.org  Mon Jul 14 15:42:31 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Tue, 15 Jul 2008 00:42:31 +0200
Subject: [34218] trunk/dports/lang
In-Reply-To: <E06E730F-7E6C-4259-9988-BD18B06F2CEC@macports.org>
References: <20080218091344.7F0AE12AF382@beta.macosforge.org>	<2CB32F21-AFB9-4DC8-A65B-6206E3E2D14A@macports.org>	<5cbbe4ae0807131530w6e074e18m39146dd6c30a9e0@mail.gmail.com>	<24AAFA06-87A3-4247-8574-EE2C3C8BC8E9@macports.org>
	<5cbbe4ae0807140008h39ebd587ua93e98de6dfe5bd0@mail.gmail.com>
	<487B6018.8000308@macports.org>
	<E06E730F-7E6C-4259-9988-BD18B06F2CEC@macports.org>
Message-ID: <487BD657.3060509@macports.org>

Ryan Schmidt wrote:
> Would be great if it did print a message when "cd" is used, but I  
> don't think it does.

Damn, I was mistaken. So I stand corrected and it seems like I have only 
dreamed about this warning :-/
Sorry, I thought there had been a deprecation warning in 1.6.0, but 
actually the code for the rename of 'cd' to '_cd' is only commented out.

Rainer

From ryandesign at macports.org  Mon Jul 14 17:50:37 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 14 Jul 2008 19:50:37 -0500
Subject: rb-criteria
In-Reply-To: <5cbbe4ae0807141351i588c709dj8e60df8367d48a35@mail.gmail.com>
References: <5cbbe4ae0807141351i588c709dj8e60df8367d48a35@mail.gmail.com>
Message-ID: <6AE584BA-E64F-4570-B6F5-626A6BAA6702@macports.org>

On Jul 14, 2008, at 15:51, Caspar Florian Ebeling wrote:

> While looking a bit closer at all the broken ruby ports which
> my regression testing turned up, I encountered some real
> cruft. Some of the libraries are really quite abandoned,
> like Criteria. This particular one has no active web site any longer,
> and can only be found on mirror servers. The unit tests don't
> pass anylonger, with errors indicating that the lib does
> not work with current day rubys at all, like different return
> types. I dont want to assume maintainership of this whole
> libary now. Is this maybe the right moment to remove a
> port?

Sounds like it.
If you haven't yet, you might try to locate the author of the  
software to see if a newer version is available that would fix these  
problems.
If not, delete the port (assuming there are no ports that depend on  
it, and I can't find any)



From ryandesign at macports.org  Tue Jul 15 03:35:02 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 15 Jul 2008 05:35:02 -0500
Subject: "MACOSX_DEPLOYMENT_TARGET"
Message-ID: <7A08C1A2-34D7-492C-984F-BD024E0F67E7@macports.org>

With debug output on, I see this fly by during the configure phase:


DEBUG: Environment: CFLAGS='-O2' CPPFLAGS='-I/mp/include' CXXFLAGS='- 
O2' CPP='/usr/bin/cpp-4.0' CXX='/usr/bin/g++-4.0' F90FLAGS='-O2'  
LDFLAGS='-L/mp/lib' FCFLAGS='-O2' OBJC='/usr/bin/gcc-4.0' INSTALL='/ 
usr/bin/install -c' OBJCFLAGS='-O2' FFLAGS='-O2'  
"MACOSX_DEPLOYMENT_TARGET"='10.5' CC='/usr/bin/gcc-4.0'


Why is "MACOSX_DEPLOYMENT_TARGET" in quotes an the other environment  
variable names aren't?



From jmr at macports.org  Tue Jul 15 03:50:56 2008
From: jmr at macports.org (Joshua Root)
Date: Tue, 15 Jul 2008 20:50:56 +1000
Subject: "MACOSX_DEPLOYMENT_TARGET"
In-Reply-To: <7A08C1A2-34D7-492C-984F-BD024E0F67E7@macports.org>
References: <7A08C1A2-34D7-492C-984F-BD024E0F67E7@macports.org>
Message-ID: <487C8110.3050406@macports.org>

Ryan Schmidt wrote:
> With debug output on, I see this fly by during the configure phase:
> 
> 
> DEBUG: Environment: CFLAGS='-O2' CPPFLAGS='-I/mp/include' CXXFLAGS='- 
> O2' CPP='/usr/bin/cpp-4.0' CXX='/usr/bin/g++-4.0' F90FLAGS='-O2'  
> LDFLAGS='-L/mp/lib' FCFLAGS='-O2' OBJC='/usr/bin/gcc-4.0' INSTALL='/ 
> usr/bin/install -c' OBJCFLAGS='-O2' FFLAGS='-O2'  
> "MACOSX_DEPLOYMENT_TARGET"='10.5' CC='/usr/bin/gcc-4.0'
> 
> 
> Why is "MACOSX_DEPLOYMENT_TARGET" in quotes an the other environment  
> variable names aren't?

Because macosx_deployment_target is an option separate from 
${phase}.env, and its corresponding env variable gets set separately in 
the command_exec proc in portutil.tcl, and quotes are used there.

- Josh

From ryandesign at macports.org  Tue Jul 15 04:15:47 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 15 Jul 2008 06:15:47 -0500
Subject: "MACOSX_DEPLOYMENT_TARGET"
In-Reply-To: <487C8110.3050406@macports.org>
References: <7A08C1A2-34D7-492C-984F-BD024E0F67E7@macports.org>
	<487C8110.3050406@macports.org>
Message-ID: <A3BE728E-912C-494C-9CFE-50D57966E615@macports.org>

On Jul 15, 2008, at 05:50, Joshua Root wrote:

> Ryan Schmidt wrote:
>
>> With debug output on, I see this fly by during the configure phase:
>>
>>
>> DEBUG: Environment: CFLAGS='-O2' CPPFLAGS='-I/mp/include' CXXFLAGS='-
>> O2' CPP='/usr/bin/cpp-4.0' CXX='/usr/bin/g++-4.0' F90FLAGS='-O2'
>> LDFLAGS='-L/mp/lib' FCFLAGS='-O2' OBJC='/usr/bin/gcc-4.0' INSTALL='/
>> usr/bin/install -c' OBJCFLAGS='-O2' FFLAGS='-O2'
>> "MACOSX_DEPLOYMENT_TARGET"='10.5' CC='/usr/bin/gcc-4.0'
>>
>>
>> Why is "MACOSX_DEPLOYMENT_TARGET" in quotes an the other environment
>> variable names aren't?
>
> Because macosx_deployment_target is an option separate from
> ${phase}.env, and its corresponding env variable gets set  
> separately in
> the command_exec proc in portutil.tcl, and quotes are used there.

Can the quotes be removed so that it is consistent with the other  
environment variables and doesn't look weird? Or are the quotes needed?


From jmr at macports.org  Tue Jul 15 05:18:37 2008
From: jmr at macports.org (Joshua Root)
Date: Tue, 15 Jul 2008 22:18:37 +1000
Subject: "MACOSX_DEPLOYMENT_TARGET"
In-Reply-To: <A3BE728E-912C-494C-9CFE-50D57966E615@macports.org>
References: <7A08C1A2-34D7-492C-984F-BD024E0F67E7@macports.org>
	<487C8110.3050406@macports.org>
	<A3BE728E-912C-494C-9CFE-50D57966E615@macports.org>
Message-ID: <487C959D.4080500@macports.org>

Ryan Schmidt wrote:
> On Jul 15, 2008, at 05:50, Joshua Root wrote:
> 
>> Ryan Schmidt wrote:
>>
>>> With debug output on, I see this fly by during the configure phase:
>>>
>>>
>>> DEBUG: Environment: CFLAGS='-O2' CPPFLAGS='-I/mp/include' CXXFLAGS='-
>>> O2' CPP='/usr/bin/cpp-4.0' CXX='/usr/bin/g++-4.0' F90FLAGS='-O2'
>>> LDFLAGS='-L/mp/lib' FCFLAGS='-O2' OBJC='/usr/bin/gcc-4.0' INSTALL='/
>>> usr/bin/install -c' OBJCFLAGS='-O2' FFLAGS='-O2'
>>> "MACOSX_DEPLOYMENT_TARGET"='10.5' CC='/usr/bin/gcc-4.0'
>>>
>>>
>>> Why is "MACOSX_DEPLOYMENT_TARGET" in quotes an the other environment
>>> variable names aren't?
>>
>> Because macosx_deployment_target is an option separate from
>> ${phase}.env, and its corresponding env variable gets set separately in
>> the command_exec proc in portutil.tcl, and quotes are used there.
> 
> Can the quotes be removed so that it is consistent with the other 
> environment variables and doesn't look weird? Or are the quotes needed?

Can't see any reason they'd be needed. I'll remove them.

- Josh

From vincent at AI.SRI.COM  Tue Jul 15 09:03:43 2008
From: vincent at AI.SRI.COM (Regis Vincent)
Date: Tue, 15 Jul 2008 09:03:43 -0700
Subject: [MacPorts] #15932: Update for playerstage-player version 2.1.1
In-Reply-To: <063.d48229c15bc07352a308fb45342e6356@macports.org>
References: <054.d137560571849c54a0087fd38060e931@macports.org>
	<063.d48229c15bc07352a308fb45342e6356@macports.org>
Message-ID: <F89D9640-E3CD-4112-81C7-9BE5823DF951@AI.SRI.COM>

I just did a test on fresh install of 10.5.4 and it works flawlessly  
with Xcode 3.0 (not Xcode 3.1).

How can I disable the universal build and force it to 386 ?




On Jul 15, 2008, at 2:07 AM, MacPorts wrote:

> #15932: Update for playerstage-player version 2.1.1
> --------------------------------- 
> +------------------------------------------
>  Reporter:  vincent at ai.sri.com  |       Owner:  macports-tickets at lists.macosforge.org
>      Type:  enhancement         |      Status:  new
>  Priority:  Normal              |   Milestone:  Port Updates
> Component:  ports               |     Version:  1.6.0
> Resolution:                      |    Keywords:
> --------------------------------- 
> +------------------------------------------
> Changes (by ryandesign at macports.org):
>
> * cc: ryandesign at macports.org (added)
>
> Comment:
>
> How are you able to install this port? I cannot. playerstage-player  
> seems
> to build itself universal without me having selected the universal
> variant; playerstage-player depends on gtk2; gtk2 depends on pango;  
> pango
> depends on cairo; and [ticket:15451 cairo cannot be built  
> universal]. I am
> on Mac OS X 10.5.4 with Xcode 3.1 on a MacBook Pro.
>
> I also have a problem with the library dependencies on automake,  
> autoconf
> and pkgconfig. These should be build dependencies, not library
> dependencies.
>
> -- 
> Ticket URL: <http://trac.macports.org/ticket/15932#comment:1>
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS

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

From vincent at AI.SRI.COM  Tue Jul 15 09:09:43 2008
From: vincent at AI.SRI.COM (Regis Vincent)
Date: Tue, 15 Jul 2008 09:09:43 -0700
Subject: [MacPorts] #15933: Update for playerstage-stage version 2.1.0
In-Reply-To: <063.642aa81051a38848647e318cc2587265@macports.org>
References: <054.ef4ce186b048761763a7cd4bdd298f14@macports.org>
	<063.642aa81051a38848647e318cc2587265@macports.org>
Message-ID: <B4269F79-626B-4E96-BDED-16085465248C@AI.SRI.COM>

Can you point me to a doc on how to use the universal vs. 386 variant.
I did not know it was added automatically. I will remove the variants.


On Jul 15, 2008, at 2:14 AM, MacPorts wrote:

> #15933: Update for playerstage-stage version 2.1.0
> --------------------------------- 
> +------------------------------------------
>  Reporter:  vincent at ai.sri.com  |       Owner:  macports-tickets at lists.macosforge.org
>      Type:  enhancement         |      Status:  new
>  Priority:  Normal              |   Milestone:  Port Updates
> Component:  ports               |     Version:  1.6.0
> Resolution:                      |    Keywords:
> --------------------------------- 
> +------------------------------------------
> Changes (by ryandesign at macports.org):
>
> * cc: ryandesign at macports.org (added)
>
> Comment:
>
> Why have you added an empty i386 variant?
>
> Why have you added a universal variant which looks very much like the
> default universal variant that MacPorts automatically adds to all  
> ports
> except that yours hardcodes parameters like the sdkroot and the list  
> of
> architectures which MacPorts allows users to configure, and by  
> hardcoding
> the sdkroot to the 10.5 sdk, you make this port unable to be installed
> universal on earlier versions of Mac OS X?
>
> Still curious how this port can be installed, given
> [comment:ticket:15932:1 this].
>
> -- 
> Ticket URL: <http://trac.macports.org/ticket/15933#comment:1>
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS

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

From vincent at AI.SRI.COM  Tue Jul 15 09:05:25 2008
From: vincent at AI.SRI.COM (Regis Vincent)
Date: Tue, 15 Jul 2008 09:05:25 -0700
Subject: [MacPorts] #13216: Add python support to playerstage-player
In-Reply-To: <069.f81827abdef8494bb6bd058287c351e2@macports.org>
References: <060.72d84dbdf86ef7d6441552a5127772ed@macports.org>
	<069.f81827abdef8494bb6bd058287c351e2@macports.org>
Message-ID: <8D2D0EEC-7AA8-47A2-895B-C5C5163F6B7F@AI.SRI.COM>

I understand, my bad, you want to disable python on the default and  
only enable it with the variant. Ok I can fix that.

R.
On Jul 15, 2008, at 2:16 AM, MacPorts wrote:

> #13216: Add python support to playerstage-player
> --------------------------------------- 
> +------------------------------------
>  Reporter:  apoikos at csl.mech.ntua.gr  |       Owner:  macports-tickets at lists.macosforge.org
>      Type:  enhancement               |      Status:  new
>  Priority:  Normal                    |   Milestone:  Port  
> Enhancements
> Component:  ports                     |     Version:  1.5.0
> Resolution:                            |    Keywords:  playerstage,  
> player, python, swig
> --------------------------------------- 
> +------------------------------------
> Comment (by ryandesign at macports.org):
>
> The python variant in #15932 does not satisfy the request expressed by
> Anthony [comment:1 above]. No attempt has been made to disable python
> support by default, and to only enable it if the python variant is
> selected.
>
> -- 
> Ticket URL: <http://trac.macports.org/ticket/13216#comment:3>
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS

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

From vincent at AI.SRI.COM  Tue Jul 15 09:13:57 2008
From: vincent at AI.SRI.COM (Regis Vincent)
Date: Tue, 15 Jul 2008 09:13:57 -0700
Subject: [MacPorts] #13216: Add python support to playerstage-player
In-Reply-To: <069.f81827abdef8494bb6bd058287c351e2@macports.org>
References: <060.72d84dbdf86ef7d6441552a5127772ed@macports.org>
	<069.f81827abdef8494bb6bd058287c351e2@macports.org>
Message-ID: <5BE206EC-EE61-4AD6-A4A6-B6B82E2541F4@AI.SRI.COM>

I have a question about this behavior
autoconf detects if python is present and adds the it to the build of  
player.

If python is present, on the machine, what should be the behavior,  
build it with python even if the variant is not selected  OR
not build the python extension despite the fact that python is present  
on the machine ?

I don't care one way or the other but both are valid expectations.

r.

On Jul 15, 2008, at 2:16 AM, MacPorts wrote:

> #13216: Add python support to playerstage-player
> --------------------------------------- 
> +------------------------------------
>  Reporter:  apoikos at csl.mech.ntua.gr  |       Owner:  macports-tickets at lists.macosforge.org
>      Type:  enhancement               |      Status:  new
>  Priority:  Normal                    |   Milestone:  Port  
> Enhancements
> Component:  ports                     |     Version:  1.5.0
> Resolution:                            |    Keywords:  playerstage,  
> player, python, swig
> --------------------------------------- 
> +------------------------------------
> Comment (by ryandesign at macports.org):
>
> The python variant in #15932 does not satisfy the request expressed by
> Anthony [comment:1 above]. No attempt has been made to disable python
> support by default, and to only enable it if the python variant is
> selected.
>
> -- 
> Ticket URL: <http://trac.macports.org/ticket/13216#comment:3>
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS

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

From ryandesign at macports.org  Tue Jul 15 14:51:55 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 15 Jul 2008 16:51:55 -0500
Subject: [MacPorts] #15932: Update for playerstage-player version 2.1.1
In-Reply-To: <F89D9640-E3CD-4112-81C7-9BE5823DF951@AI.SRI.COM>
References: <054.d137560571849c54a0087fd38060e931@macports.org>
	<063.d48229c15bc07352a308fb45342e6356@macports.org>
	<F89D9640-E3CD-4112-81C7-9BE5823DF951@AI.SRI.COM>
Message-ID: <A0E9CA91-B0C4-4BD5-B0F7-AA8AAD734467@macports.org>


On Jul 15, 2008, at 11:03, Regis Vincent wrote:

> I just did a test on fresh install of 10.5.4 and it works  
> flawlessly with Xcode 3.0 (not Xcode 3.1).

Does it build universal on your system too? Do you have the  
dependencies of this port installed as universal on your system too?


> How can I disable the universal build and force it to 386 ?

You would have to look through the source code and see if you can  
figure that out. Or you could talk to the developers of the software.


> On Jul 15, 2008, at 2:07 AM, MacPorts wrote:
>
>> #15932: Update for playerstage-player version 2.1.1
>> --------------------------------- 
>> +------------------------------------------
>>  Reporter:  vincent at ai.sri.com  |       Owner:  macports- 
>> tickets at lists.macosforge.org
>>      Type:  enhancement         |      Status:  new
>>  Priority:  Normal              |   Milestone:  Port Updates
>> Component:  ports               |     Version:  1.6.0
>> Resolution:                      |    Keywords:
>> --------------------------------- 
>> +------------------------------------------
>> Changes (by ryandesign at macports.org):
>>
>> * cc: ryandesign at macports.org (added)
>>
>> Comment:
>>
>> How are you able to install this port? I cannot. playerstage- 
>> player seems
>> to build itself universal without me having selected the universal
>> variant; playerstage-player depends on gtk2; gtk2 depends on  
>> pango; pango
>> depends on cairo; and [ticket:15451 cairo cannot be built  
>> universal]. I am
>> on Mac OS X 10.5.4 with Xcode 3.1 on a MacBook Pro.
>>
>> I also have a problem with the library dependencies on automake,  
>> autoconf
>> and pkgconfig. These should be build dependencies, not library
>> dependencies.
>>
>> -- 
>> Ticket URL: <http://trac.macports.org/ticket/15932#comment:1>
>> MacPorts <http://www.macports.org/>
>> Ports system for Mac OS

From ryandesign at macports.org  Tue Jul 15 14:54:43 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 15 Jul 2008 16:54:43 -0500
Subject: [MacPorts] #15933: Update for playerstage-stage version 2.1.0
In-Reply-To: <B4269F79-626B-4E96-BDED-16085465248C@AI.SRI.COM>
References: <054.ef4ce186b048761763a7cd4bdd298f14@macports.org>
	<063.642aa81051a38848647e318cc2587265@macports.org>
	<B4269F79-626B-4E96-BDED-16085465248C@AI.SRI.COM>
Message-ID: <47DD1F4F-EC99-4483-ABCA-EA895CCF8D41@macports.org>


On Jul 15, 2008, at 11:09, Regis Vincent wrote:

> Can you point me to a doc on how to use the universal vs. 386 variant.
> I did not know it was added automatically. I will remove the variants.

i386 is a platform selector, not a variant. If you want portfile code  
to be executed when building on i386 but not when building on  
PowerPC, you would write:

platform i386 {
	whatever
}

For information about universal, see:

http://trac.macports.org/wiki/FAQ#IsMacPortsUniversal

And:

http://guide.macports.org/#reference.phases.configure.universal



From febeling at macports.org  Tue Jul 15 16:07:41 2008
From: febeling at macports.org (Caspar Florian Ebeling)
Date: Wed, 16 Jul 2008 01:07:41 +0200
Subject: erlang category
Message-ID: <5cbbe4ae0807151607l2a6e4100oe98c8be8d023142f@mail.gmail.com>

Hi,

I want to add the erlang web server yaws as a port and I wonder if it makes
sense to create a new priamary category "erlang" for this. In fact I think so
because I see an increase in interest in this platform in general. The
New Committers Guide in the wiki says such a thing needs approval.
Should I add it?

Florian

-- 
Florian Ebeling
florian.ebeling at gmail.com

From ryandesign at macports.org  Tue Jul 15 16:20:59 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 15 Jul 2008 18:20:59 -0500
Subject: [MacPorts] #13216: Add python support to playerstage-player
In-Reply-To: <5BE206EC-EE61-4AD6-A4A6-B6B82E2541F4@AI.SRI.COM>
References: <060.72d84dbdf86ef7d6441552a5127772ed@macports.org>
	<069.f81827abdef8494bb6bd058287c351e2@macports.org>
	<5BE206EC-EE61-4AD6-A4A6-B6B82E2541F4@AI.SRI.COM>
Message-ID: <DFF224FA-2B73-474A-8F86-F9E0C2397D3C@macports.org>


On Jul 15, 2008, at 11:13, Regis Vincent wrote:

> I have a question about this behavior
> autoconf detects if python is present and adds the it to the build  
> of player.
>
> If python is present, on the machine, what should be the behavior,  
> build it with python even if the variant is not selected

No.

> OR
> not build the python extension despite the fact that python is  
> present on the machine ?

Yes.

> I don't care one way or the other but both are valid expectations.

In MacPorts the expectation is that two users who request to install  
a port with the same set of variants will get exactly the same  
software [1] regardless of any differences in the list of installed  
ports on their machines. If the port has not declared a dependency on  
python, it must not use python, even if python is installed. Same  
goes for all other undeclared dependencies [2]. Software should come  
with configure switches you can use to disable python support in the  
default situation, which you can include with configure.args, and  
which you can remove in the python variant with configure.args- 
delete. Or you could choose to make python support always-on and  
dispense with the need for configure arguments and variants.

Other than Xcode, ports usually shouldn't make use of software  
provided by Apple with Mac OS X; MacPorts versions of that software  
should be preferred. The FAQ [3] explains why.


[1] With the exception of differences in major Mac OS X versions and  
processor architecture.

[2] With the exception of Xcode, which is a basic necessity for using  
MacPorts and on which ports needn't declare a dependency.

[3] http://trac.macports.org/wiki/FAQ#WhyisMacPortsusingitsownlibraries



From 0x62_0x6c_0x62 at pobox.com  Tue Jul 15 16:44:08 2008
From: 0x62_0x6c_0x62 at pobox.com (Bryan Blackburn)
Date: Tue, 15 Jul 2008 17:44:08 -0600
Subject: erlang category
In-Reply-To: <5cbbe4ae0807151607l2a6e4100oe98c8be8d023142f@mail.gmail.com>
References: <5cbbe4ae0807151607l2a6e4100oe98c8be8d023142f@mail.gmail.com>
Message-ID: <65DB9511-D92F-4102-9644-9409A1415750@pobox.com>

On Jul 15, 2008, at 5:07 PM, Caspar Florian Ebeling wrote:

> Hi,
>
> I want to add the erlang web server yaws as a port and I wonder if  
> it makes
> sense to create a new priamary category "erlang" for this. In fact I  
> think so
> because I see an increase in interest in this platform in general. The
> New Committers Guide in the wiki says such a thing needs approval.
> Should I add it?
>

An erlang category would definitely make sense if there's enough  
software based on it.  Though about yaws:

$ port search yaws
yaws @1.76 (www)
     Webserver for dynamic content written in Erlang

Bryan


> Florian
>
> -- 
> Florian Ebeling
> florian.ebeling at gmail.com

From ram at macports.org  Tue Jul 15 18:36:01 2008
From: ram at macports.org (Adam Mercer)
Date: Tue, 15 Jul 2008 20:36:01 -0500
Subject: base from trunk fails to install with "install:
	/opt/local/share/macports/: No such file or directory"
Message-ID: <799406d60807151836u4f8bcb56x7a912482193283c0@mail.gmail.com>

Hi

Just tried to install base from the trunk and install fails with the
following error:

/usr/bin/install -c -o root -g admin -m 444 setupenv.bash
/opt/local/share/macports/
install: /opt/local/share/macports/: No such file or directory

manually creating this directory and the installation proceeds without error.

Cheers

Adam

From febeling at macports.org  Tue Jul 15 23:23:34 2008
From: febeling at macports.org (Caspar Florian Ebeling)
Date: Wed, 16 Jul 2008 08:23:34 +0200
Subject: erlang category
In-Reply-To: <65DB9511-D92F-4102-9644-9409A1415750@pobox.com>
References: <5cbbe4ae0807151607l2a6e4100oe98c8be8d023142f@mail.gmail.com>
	<65DB9511-D92F-4102-9644-9409A1415750@pobox.com>
Message-ID: <5cbbe4ae0807152323j2d473075v5525f0df38c78c67@mail.gmail.com>

> software based on it.  Though about yaws:
>
> $ port search yaws
> yaws @1.76 (www)
>     Webserver for dynamic content written in Erlang

Hm. I don't know what i have been looking at yesterday.
Thanks for catching that.

-- 
Florian Ebeling
florian.ebeling at gmail.com

From ryandesign at macports.org  Tue Jul 15 23:43:45 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 16 Jul 2008 01:43:45 -0500
Subject: To whom should error messages be written?
Message-ID: <220DC6E3-FFB7-433F-A9C9-5C4C5E106C34@macports.org>

There are a number of error messages that MacPorts might print during  
the normal course of events. Checksum errors, fetch failures, port  
misbehaviors. Who should be the audience for these error messages --  
the end user or the portfile developer? I would argue the former but  
we currently have some messages that target the latter.

Take, for example, destroot violations. If a port violates the mtree  
and does not indicate that it wants to do this via  
"destroot.violate_mtree yes", MacPorts prints:

	Warning: violation by <path>
	Warning: <port> violates the layout of the ports-filesystems!
	Warning: Please fix or indicate this misbehavior (if it is  
intended), it will be an error in future releases!

This message is clearly written to the portfile developer.

If the port does indicate that it will install files outside of the  
mtree, MacPorts says:

	Warning: <port> requests to install files outside the common  
directory structure!

This message is presumably written to the end user so that they know  
files have been installed in a nonstandard location, though MacPorts  
does not tell the user where. I recall at least one bug report from a  
user who did not realize that this message did not constitute a bug  
but correct normal behavior. I guess the word "Warning" and the  
exclamation point make it sound like a bug that needs to be reported.

The patch in #15514 [1] adds a new message the end user could see:

	Warning: reinplace <regexp> didn't change anything in <file>

This information is meant for the portfile developer. The developer  
should either fix the regexp (so that it replaces what it was  
designed to replace), or remove it (because the file no longer needs  
that replacement), or indicate via a new flag to the reinplace  
command that it's ok that no replacement occurred (for example see  
the mysql5 port which does a reinplace across a glob of files, not  
all of which contain the string to be replaced). The end user doesn't  
need to know all this, of course; the end user just needs to be told  
to file a ticket.



I think we should write error messages to the end user, not the  
portfile developer. I think we should also have a new page in the  
wiki called ErrorMessages, where we can list the error messages that  
MacPorts might print along with explanations of what the portfile  
author should do about them. We would describe mtree violations and  
ineffectual reinplaces and checksum failures (the checksum failure  
discussion would move to this new page from the FAQ).

Or we could put all these in the FAQ page, maybe in a new section for  
error messages.


[1] http://trac.macports.org/ticket/15514


From simon at ruderich.com  Wed Jul 16 06:13:59 2008
From: simon at ruderich.com (Simon Ruderich)
Date: Wed, 16 Jul 2008 15:13:59 +0200
Subject: Chunked guide
Message-ID: <20080716131359.GA29468@ruderich.com>

Hi,

I just committed a new target "guide-chunked" to the doc-new Makefile which
generates a chunked version of the guide [1].

I used a Tcl script to add the table of contents to each page. Please have a
look at [2] and tell me what you think.

If you like it we can activate the guide-chunked target on the documentation
server and make it available to everybody.

Thanks,
Simon

PS: Looks like the guide doesn't get updated anymore. I made some changes
yesterday and they are still not available at guide.macports.org.

[1]: http://trac.macports.org/changeset/38342
[2]: http://ruderich.com/macports/chunked/
-- 
+ privacy is necessary
+ using http://gnupg.org
+ public key id: 0x6115F804EFB33229
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080716/aac6ab72/attachment.bin 

From wsiegrist at apple.com  Wed Jul 16 07:43:33 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Wed, 16 Jul 2008 07:43:33 -0700
Subject: Chunked guide
In-Reply-To: <20080716131359.GA29468@ruderich.com>
References: <20080716131359.GA29468@ruderich.com>
Message-ID: <CC4215CF-7C17-4F76-A1DB-F5F12B1B7469@apple.com>


On Jul 16, 2008, at 6:13 AM, Simon Ruderich wrote:

> PS: Looks like the guide doesn't get updated anymore. I made some  
> changes
> yesterday and they are still not available at guide.macports.org.
>

Fixed.

-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/20080716/e8547226/attachment.bin 

From raimue at macports.org  Wed Jul 16 08:01:45 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Wed, 16 Jul 2008 17:01:45 +0200
Subject: base from trunk fails to install with
	"install:	/opt/local/share/macports/: No such file or directory"
In-Reply-To: <799406d60807151836u4f8bcb56x7a912482193283c0@mail.gmail.com>
References: <799406d60807151836u4f8bcb56x7a912482193283c0@mail.gmail.com>
Message-ID: <487E0D59.8070900@macports.org>

Adam Mercer wrote:
> Just tried to install base from the trunk and install fails with the
> following error:
> 
> /usr/bin/install -c -o root -g admin -m 444 setupenv.bash
> /opt/local/share/macports/
> install: /opt/local/share/macports/: No such file or directory
> 
> manually creating this directory and the installation proceeds without error.

Thanks for the report. I just never tested this addition with a fresh 
install.

Fixed in r38344.

Rainer

From captsolo at gmail.com  Wed Jul 16 08:42:48 2008
From: captsolo at gmail.com (Uldis Bojars)
Date: Wed, 16 Jul 2008 16:42:48 +0100
Subject: Meaning of "Not a directory"
In-Reply-To: <487B7253.5070308@macports.org>
References: <E71BEF4E-22D6-41C5-9859-BD193D9CE738@macports.org>
	<4878FAB8.1010309@macports.org> <487B7253.5070308@macports.org>
Message-ID: <64c81f720807160842i5cde4b5am444d8cbc6bbe4c5f@mail.gmail.com>

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.

Does anyone know how to fix this or where ./configure or the linker
picks up the path to Leopard's built-in Python?

I can not find where the wrong path comes from either. The path
returned by the Python snippet in the ./configure points to the
correct Python location (/opt/local/...) and yet the library gets
linked against the system Python. Here is the path returned by Python:

>>> print sys.prefix
/opt/local/Library/Frameworks/Python.framework/Versions/2.5

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?

Uldis

From jkh at apple.com  Wed Jul 16 10:35:13 2008
From: jkh at apple.com (Jordan K. Hubbard)
Date: Wed, 16 Jul 2008 10:35:13 -0700
Subject: To whom should error messages be written?
In-Reply-To: <220DC6E3-FFB7-433F-A9C9-5C4C5E106C34@macports.org>
References: <220DC6E3-FFB7-433F-A9C9-5C4C5E106C34@macports.org>
Message-ID: <55E5CD93-EDCA-4616-8AFF-39279CEB3FC0@apple.com>


On Jul 15, 2008, at 11:43 PM, Ryan Schmidt wrote:

> I think we should write error messages to the end user, not the
> portfile developer. I think we should also have a new page in the
> wiki called ErrorMessages, where we can list the error messages that
> MacPorts might print along with explanations of what the portfile
> author should do about them. We would describe mtree violations and
> ineffectual reinplaces and checksum failures (the checksum failure
> discussion would move to this new page from the FAQ).

I think you've highlighted an important point ("what audience are  
these messages for?") but I don't necessarily see this as an either/or  
scenario.  Both types of messages are important, depending on the  
context, we've just done a poor job of segregating them and allowing  
the user or developer to select which types they want.  I think  
there's enough goop being generated at this point that it would be a  
fine (and comparatively easy) project to add some classification  
attributes to each messages and then enhance the port command to allow  
messages to be emitted by classification (with, of course, some good  
defaults for naive users).  This is the ASL approach, and while it's  
taken awhile for ASL to gain traction in MacOSX, people are already  
using it to do some rather sophisticated log generation and  
scraping.   I understand that these are not log messages, but they're  
close enough in spirit and form that we should take a page from ASL's  
book when it comes to attributes and uniform structure of each  
message.  This would be particularly helpful for debugging messages,  
where we've currently dumped so much stuff into one big "debug bucket"  
that it becomes increasingly more difficult to read the output of port  
-d.

- Jordan


From usx303 at googlemail.com  Wed Jul 16 12:26:42 2008
From: usx303 at googlemail.com (Uwe Schwartz)
Date: Wed, 16 Jul 2008 21:26:42 +0200
Subject: Whitespaces in Portfile
Message-ID: <487E4B72.8060506@googlemail.com>

Hi,

are there any conventions about tabs and whitespaces in Portfile?
I couldn't find any hints in the wiki or in the guide.

Regards,

Uwe

From raimue at macports.org  Wed Jul 16 13:38:12 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Wed, 16 Jul 2008 22:38:12 +0200
Subject: Whitespaces in Portfile
In-Reply-To: <487E4B72.8060506@googlemail.com>
References: <487E4B72.8060506@googlemail.com>
Message-ID: <487E5C34.5040801@macports.org>

Uwe Schwartz wrote:
> are there any conventions about tabs and whitespaces in Portfile?
> I couldn't find any hints in the wiki or in the guide.

http://guide.macports.org/#development.practices.portstyle

Additionally, watch out for trailing whitespace - especially when the 
line should end with a backslash. Use 'port lint', it prints a warning 
for this.

Rainer

From usx303 at googlemail.com  Wed Jul 16 14:08:01 2008
From: usx303 at googlemail.com (Uwe Schwartz)
Date: Wed, 16 Jul 2008 23:08:01 +0200
Subject: Whitespaces in Portfile
In-Reply-To: <487E5C34.5040801@macports.org>
References: <487E4B72.8060506@googlemail.com> <487E5C34.5040801@macports.org>
Message-ID: <487E6331.9080804@googlemail.com>

'port lint' is much more convenient than 'portindex'

Thanks.

Uwe

Rainer M?ller schrieb:
> Uwe Schwartz wrote:
>> are there any conventions about tabs and whitespaces in Portfile?
>> I couldn't find any hints in the wiki or in the guide.
> 
> http://guide.macports.org/#development.practices.portstyle
> 
> Additionally, watch out for trailing whitespace - especially when the 
> line should end with a backslash. Use 'port lint', it prints a warning 
> for this.
> 
> Rainer


From ryandesign at macports.org  Wed Jul 16 14:40:28 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 16 Jul 2008 16:40:28 -0500
Subject: Whitespaces in Portfile
In-Reply-To: <487E6331.9080804@googlemail.com>
References: <487E4B72.8060506@googlemail.com> <487E5C34.5040801@macports.org>
	<487E6331.9080804@googlemail.com>
Message-ID: <5A423860-8F1E-48C0-B89C-7D4727D7CE5A@macports.org>

On Jul 16, 2008, at 16:08, Uwe Schwartz wrote:

> Rainer M?ller schrieb:
>
>> Uwe Schwartz wrote:
>>
>>> are there any conventions about tabs and whitespaces in Portfile?
>>> I couldn't find any hints in the wiki or in the guide.
>>
>> http://guide.macports.org/#development.practices.portstyle
>>
>> Additionally, watch out for trailing whitespace - especially when the
>> line should end with a backslash. Use 'port lint', it prints a  
>> warning
>> for this.
>
> 'port lint' is much more convenient than 'portindex'

Some whitespace warnings that port lint currently prints will be  
removed or will only appear when using a switch:

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

port lint does not currently warn if you use tabs in your portfile,  
though spaces are preferred instead of tabs.


From ryandesign at macports.org  Thu Jul 17 01:25:46 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 17 Jul 2008 03:25:46 -0500
Subject: [38358] branches/gsoc08-logging
In-Reply-To: <20080717064715.23E4C156BEC@beta.macosforge.org>
References: <20080717064715.23E4C156BEC@beta.macosforge.org>
Message-ID: <2586C1B3-2C47-405C-A49D-1066E2792BB6@macports.org>


On Jul 17, 2008, at 01:47, dpemmons at macports.org wrote:

> server now dumps submitted lot file to mysql database. also created  
> userAdmin.pl tool for server users.

You should fix the typo in your log message. :) Use this:

svn propedit --revprop -r 38358 svn:log \
http://svn.macosforge.org/repository/macports



From ryandesign at macports.org  Thu Jul 17 01:28:58 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 17 Jul 2008 03:28:58 -0500
Subject: To whom should error messages be written?
In-Reply-To: <55E5CD93-EDCA-4616-8AFF-39279CEB3FC0@apple.com>
References: <220DC6E3-FFB7-433F-A9C9-5C4C5E106C34@macports.org>
	<55E5CD93-EDCA-4616-8AFF-39279CEB3FC0@apple.com>
Message-ID: <8B2CC32C-AE0E-4AD4-90DC-BE63761D739C@macports.org>

On Jul 16, 2008, at 12:35, Jordan K. Hubbard wrote:

> On Jul 15, 2008, at 11:43 PM, Ryan Schmidt wrote:
>
>> I think we should write error messages to the end user, not the
>> portfile developer. I think we should also have a new page in the
>> wiki called ErrorMessages, where we can list the error messages that
>> MacPorts might print along with explanations of what the portfile
>> author should do about them. We would describe mtree violations and
>> ineffectual reinplaces and checksum failures (the checksum failure
>> discussion would move to this new page from the FAQ).
>
> I think you've highlighted an important point ("what audience are
> these messages for?") but I don't necessarily see this as an either/or
> scenario.  Both types of messages are important, depending on the
> context, we've just done a poor job of segregating them and allowing
> the user or developer to select which types they want.  I think
> there's enough goop being generated at this point that it would be a
> fine (and comparatively easy) project to add some classification
> attributes to each messages and then enhance the port command to allow
> messages to be emitted by classification (with, of course, some good
> defaults for naive users).

Or we could print no messages that attempt to explain the error  
situation, other than a URL to the FAQ entry for that error message.  
Don't advise "fix the portfile" or "file a ticket" but link to the  
explanation of what the problem is. The FAQ entry can have two  
sections for each entry: one for end users, one for port developers.

> This is the ASL approach, and while it's
> taken awhile for ASL to gain traction in MacOSX, people are already
> using it to do some rather sophisticated log generation and
> scraping.   I understand that these are not log messages, but they're
> close enough in spirit and form that we should take a page from ASL's
> book when it comes to attributes and uniform structure of each
> message.

What is ASL?

> This would be particularly helpful for debugging messages,
> where we've currently dumped so much stuff into one big "debug bucket"
> that it becomes increasingly more difficult to read the output of port
> -d.

I agree our debug bucket is overflowing.


From randall.h.wood at alexandriasoftware.com  Thu Jul 17 02:05:46 2008
From: randall.h.wood at alexandriasoftware.com (Randall Wood)
Date: Thu, 17 Jul 2008 05:05:46 -0400
Subject: Chunked guide
In-Reply-To: <20080716131359.GA29468@ruderich.com>
References: <20080716131359.GA29468@ruderich.com>
Message-ID: <c24012060807170205j1c825e1aj6663d29505bd91ef@mail.gmail.com>

On Wed, Jul 16, 2008 at 9:13 AM, Simon Ruderich <simon at ruderich.com> wrote:
> Hi,
>
> I just committed a new target "guide-chunked" to the doc-new Makefile which
> generates a chunked version of the guide [1].
>
> I used a Tcl script to add the table of contents to each page. Please have a
> look at [2] and tell me what you think.
>
> If you like it we can activate the guide-chunked target on the documentation
> server and make it available to everybody.

I like it. Is it possible to chunk the guide at x.y sections instead
of chapters?

Some notes:

Indexers such a google do not seem to respect links to individual
headers, but instead always return the user to the top of the page, so
the smaller the chunk, the better the user experience when coming from
a search.

Even though it did not need them, the scroll bars were kept in the
navigation bar. Empty scroll bars don't look good in Safari IMHO.

Can each page get a further table of contents of its headers down to
the x.y.z level?

> Thanks,
> Simon
>
> PS: Looks like the guide doesn't get updated anymore. I made some changes
> yesterday and they are still not available at guide.macports.org.
>
> [1]: http://trac.macports.org/changeset/38342
> [2]: http://ruderich.com/macports/chunked/
> --
> + privacy is necessary
> + using http://gnupg.org
> + public key id: 0x6115F804EFB33229
>
> _______________________________________________
> 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 smilerliu at gmail.com  Thu Jul 17 10:04:43 2008
From: smilerliu at gmail.com (Xin Liu)
Date: Thu, 17 Jul 2008 10:04:43 -0700
Subject: [MacPorts] #16002: macfuse not building on 10.4.11
In-Reply-To: <064.97f89ffe812c1fa50db9d2816e3cfe2f@macports.org>
References: <055.71e3f49e523cbb0b811c6c9f28c9373a@macports.org>
	<064.97f89ffe812c1fa50db9d2816e3cfe2f@macports.org>
Message-ID: <ea11805f0807171004q2320c7f7vea9873a82c5d39f4@mail.gmail.com>

Please, check the error message carefully. There are two errors:

1. A shell command returned non-zero. I don't know the reason for this.
2. The SDK is not found in /MacOSX10.4u.sdk, which should not be the
path to the SDK. The reason for this is that a variable
$(DEVELOPER_SDK_DIR) is not set in the Xcode project file.

On Thu, Jul 17, 2008 at 2:41 AM, MacPorts <noreply at macports.org> wrote:
> #16002: macfuse not building on 10.4.11
> ----------------------------------+-----------------------------------------
>  Reporter:  smilerliu at gmail.com  |       Owner:  eridius at macports.org
>      Type:  defect               |      Status:  new
>  Priority:  Normal               |   Milestone:  Port Bugs
>  Component:  ports                |     Version:  1.6.0
> Resolution:                       |    Keywords:  macfuse build error
> ----------------------------------+-----------------------------------------
> Comment (by jmr at macports.org):
>
>  Install the 10.4u SDK. It's part of the default XCode install.

From jkh at apple.com  Thu Jul 17 10:54:25 2008
From: jkh at apple.com (Jordan K. Hubbard)
Date: Thu, 17 Jul 2008 10:54:25 -0700
Subject: To whom should error messages be written?
In-Reply-To: <8B2CC32C-AE0E-4AD4-90DC-BE63761D739C@macports.org>
References: <220DC6E3-FFB7-433F-A9C9-5C4C5E106C34@macports.org>
	<55E5CD93-EDCA-4616-8AFF-39279CEB3FC0@apple.com>
	<8B2CC32C-AE0E-4AD4-90DC-BE63761D739C@macports.org>
Message-ID: <970F78E5-6A8C-41B9-B009-E854F7936B45@apple.com>


On Jul 17, 2008, at 1:28 AM, Ryan Schmidt wrote:

> What is ASL?

man 3 asl

It's been around since Tiger.  I can see we still have some marketing  
to do. :-)

- Jordan


From ryandesign at macports.org  Thu Jul 17 14:35:02 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 17 Jul 2008 16:35:02 -0500
Subject: Adding distfiles to the repository (was: Re: iso-codes 3.1 cannot
	download)
In-Reply-To: <487FB718.9000109@orcaware.com>
References: <487F79F8.8060300@orcaware.com>
	<25CDFE40-DB83-4750-B90E-3735B32A6E3D@macports.org>
	<487FB718.9000109@orcaware.com>
Message-ID: <14567128-9862-47FD-93CA-A3B1AA934258@macports.org>

List,

I'm bringing this discussion to the list from private mail between me  
and Blair Zajac:

On Jul 17, 2008, at 16:18, Blair Zajac wrote:

> Ryan Schmidt wrote:
>
>> On Jul 17, 2008, at 11:57, Blair Zajac wrote:
>>
>>> Hi Ryan,
>>>
>>> Do you have a copy of the iso-codes-3.1.tar.gz we can put up in  
>>> the svn repos? Right now the ftp://pkg-isocodes.alioth.debian.org/ 
>>> pub/pkg-isocodes/ URL isn't loading at all and at some sites,  
>>> such as my port, we cannot use ftp:// URLs and only http:// URLs,  
>>> so having this in our repos would make it work there.
>>>
>>> Thanks,
>>> Blair
>>
>> I'll fix this. See #15981.
>
> I put the tarball into our svn dist location, so it can be  
> downloaded using http.  I don't know if the r38372 is needed, as it  
> worked for me without this change.

I think we should not add distfiles to the Subversion repository  
anymore. They take up lots of room. I could make thousands of  
portfile edits in the amount of disk space used by a single distfile.  
I would rather use 1K in the repository to add a new distfiles mirror  
to the portfile than use 5MB to store a copy of the distfile. There  
is "no way" to remove data from the repository "ever" [1] so it has  
always seemed like the wrong place to put distfiles. And thankfully  
we now have a much better solution in the distfiles mirror. I think  
the only reason to add a distfile to the repository is if the  
distfiles mirror is unable to mirror it for some technical reason,  
and that should be rare.

I don't know if the Guide mentions putting distfiles into the  
repository, but if it does, it should be changed to talk about the  
distfiles mirror.


From wsiegrist at apple.com  Thu Jul 17 14:50:50 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Thu, 17 Jul 2008 14:50:50 -0700
Subject: Adding distfiles to the repository (was: Re: iso-codes 3.1 cannot
	download)
In-Reply-To: <14567128-9862-47FD-93CA-A3B1AA934258@macports.org>
References: <487F79F8.8060300@orcaware.com>
	<25CDFE40-DB83-4750-B90E-3735B32A6E3D@macports.org>
	<487FB718.9000109@orcaware.com>
	<14567128-9862-47FD-93CA-A3B1AA934258@macports.org>
Message-ID: <882898A8-F1EC-41A7-9B7F-0BC0E1F1A482@apple.com>

On Jul 17, 2008, at 2:35 PM, Ryan Schmidt wrote:

> List,
>
> I'm bringing this discussion to the list from private mail between me
> and Blair Zajac:
>
> On Jul 17, 2008, at 16:18, Blair Zajac wrote:
>
>> Ryan Schmidt wrote:
>>
>>> On Jul 17, 2008, at 11:57, Blair Zajac wrote:
>>>
>>>> Hi Ryan,
>>>>
>>>> Do you have a copy of the iso-codes-3.1.tar.gz we can put up in
>>>> the svn repos? Right now the ftp://pkg-isocodes.alioth.debian.org/
>>>> pub/pkg-isocodes/ URL isn't loading at all and at some sites,
>>>> such as my port, we cannot use ftp:// URLs and only http:// URLs,
>>>> so having this in our repos would make it work there.
>>>>
>>>> Thanks,
>>>> Blair
>>>
>>> I'll fix this. See #15981.
>>
>> I put the tarball into our svn dist location, so it can be
>> downloaded using http.  I don't know if the r38372 is needed, as it
>> worked for me without this change.
>
> I think we should not add distfiles to the Subversion repository
> anymore. They take up lots of room. I could make thousands of
> portfile edits in the amount of disk space used by a single distfile.
> I would rather use 1K in the repository to add a new distfiles mirror
> to the portfile than use 5MB to store a copy of the distfile. There
> is "no way" to remove data from the repository "ever" [1] so it has
> always seemed like the wrong place to put distfiles. And thankfully
> we now have a much better solution in the distfiles mirror. I think
> the only reason to add a distfile to the repository is if the
> distfiles mirror is unable to mirror it for some technical reason,
> and that should be rare.
>
> I don't know if the Guide mentions putting distfiles into the
> repository, but if it does, it should be changed to talk about the
> distfiles mirror.
>


The distfile mirror actually got the iso-codes 3.1 tarball only an  
hour ago due to a sync issue (it still saw v2.0). I noticed Blair had  
to commit the tarball which is what prompted me to check the mirror  
status.

But in general, I agree people should rely on that server instead of  
committing distfiles. I believe the plan is for MPWA to provide an  
upload mechanism to manually add files.

If someone has trouble getting a distfile, and the mirror also doesnt  
have it, they can submit a ticket to server/hosting and I'll try to  
get it cleaned up. Note that the servers cannot retrieve files via FTP  
either, so ports with only FTP will always be a problem, but I can  
manually add the file so there should be no permanently missing  
distfiles.  Also, please allow at least 24hr after a portfile is  
updated before complaining though, as the mirror is only updated daily.

-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/20080717/f891d6d3/attachment.bin 

From raimue at macports.org  Thu Jul 17 14:52:00 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 17 Jul 2008 23:52:00 +0200
Subject: Adding distfiles to the repository
In-Reply-To: <14567128-9862-47FD-93CA-A3B1AA934258@macports.org>
References: <487F79F8.8060300@orcaware.com>	<25CDFE40-DB83-4750-B90E-3735B32A6E3D@macports.org>	<487FB718.9000109@orcaware.com>
	<14567128-9862-47FD-93CA-A3B1AA934258@macports.org>
Message-ID: <487FBF00.5000709@macports.org>

Ryan Schmidt wrote:
> I think we should not add distfiles to the Subversion repository  
> anymore. They take up lots of room. I could make thousands of  
> portfile edits in the amount of disk space used by a single distfile.  
> I would rather use 1K in the repository to add a new distfiles mirror  
> to the portfile than use 5MB to store a copy of the distfile. There  
> is "no way" to remove data from the repository "ever" [1] so it has  
> always seemed like the wrong place to put distfiles. And thankfully  
> we now have a much better solution in the distfiles mirror. I think  
> the only reason to add a distfile to the repository is if the  
> distfiles mirror is unable to mirror it for some technical reason,  
> and that should be rare.

I agree with you. Subversion repositories are not a good place to 
archive non-changing binary data.

But there is currently no way to add a file to the distfiles mirror if 
all of the original master_sites are not available any more. This was 
the case for iso-codes.

To add the file to the distfiles mirror, it has to be online somewhere, 
so 'port mirror' can pick it up. The subversion repository is the 
easiest way to add a local copy, as it is automatically in master_sites 
as fallback.

Rainer

From blair at orcaware.com  Thu Jul 17 15:00:00 2008
From: blair at orcaware.com (Blair Zajac)
Date: Thu, 17 Jul 2008 15:00:00 -0700
Subject: Adding distfiles to the repository
In-Reply-To: <487FBF00.5000709@macports.org>
References: <487F79F8.8060300@orcaware.com>	<25CDFE40-DB83-4750-B90E-3735B32A6E3D@macports.org>	<487FB718.9000109@orcaware.com>
	<14567128-9862-47FD-93CA-A3B1AA934258@macports.org>
	<487FBF00.5000709@macports.org>
Message-ID: <487FC0E0.7020300@orcaware.com>

Rainer M?ller wrote:
> Ryan Schmidt wrote:
>> I think we should not add distfiles to the Subversion repository  
>> anymore. They take up lots of room. I could make thousands of  
>> portfile edits in the amount of disk space used by a single distfile.  
>> I would rather use 1K in the repository to add a new distfiles mirror  
>> to the portfile than use 5MB to store a copy of the distfile. There  
>> is "no way" to remove data from the repository "ever" [1] so it has  
>> always seemed like the wrong place to put distfiles. And thankfully  
>> we now have a much better solution in the distfiles mirror. I think  
>> the only reason to add a distfile to the repository is if the  
>> distfiles mirror is unable to mirror it for some technical reason,  
>> and that should be rare.
> 
> I agree with you. Subversion repositories are not a good place to 
> archive non-changing binary data.

Well, they are a good place to store non-changing binary data, it's just if you 
don't need that data any more, say after a new version of the port comes out, 
then you can't remove it and it consumes space forever.

We could set up a new svn repository for distfiles, separate from the one for 
Portfile's, and that repository could be exported and reimported into a fresh 
repository every so often when it got too big.

Blair


From blair at orcaware.com  Thu Jul 17 15:01:09 2008
From: blair at orcaware.com (Blair Zajac)
Date: Thu, 17 Jul 2008 15:01:09 -0700
Subject: Adding distfiles to the repository
In-Reply-To: <882898A8-F1EC-41A7-9B7F-0BC0E1F1A482@apple.com>
References: <487F79F8.8060300@orcaware.com>
	<25CDFE40-DB83-4750-B90E-3735B32A6E3D@macports.org>
	<487FB718.9000109@orcaware.com>
	<14567128-9862-47FD-93CA-A3B1AA934258@macports.org>
	<882898A8-F1EC-41A7-9B7F-0BC0E1F1A482@apple.com>
Message-ID: <487FC125.5060507@orcaware.com>

William Siegrist wrote:
> On Jul 17, 2008, at 2:35 PM, Ryan Schmidt wrote:
> 
>> List,
>>
>> I'm bringing this discussion to the list from private mail between me
>> and Blair Zajac:
>>
>> On Jul 17, 2008, at 16:18, Blair Zajac wrote:
>>
>>> Ryan Schmidt wrote:
>>>
>>>> On Jul 17, 2008, at 11:57, Blair Zajac wrote:
>>>>
>>>>> Hi Ryan,
>>>>>
>>>>> Do you have a copy of the iso-codes-3.1.tar.gz we can put up in
>>>>> the svn repos? Right now the ftp://pkg-isocodes.alioth.debian.org/
>>>>> pub/pkg-isocodes/ URL isn't loading at all and at some sites,
>>>>> such as my port, we cannot use ftp:// URLs and only http:// URLs,
>>>>> so having this in our repos would make it work there.
>>>>>
>>>>> Thanks,
>>>>> Blair
>>>>
>>>> I'll fix this. See #15981.
>>>
>>> I put the tarball into our svn dist location, so it can be
>>> downloaded using http.  I don't know if the r38372 is needed, as it
>>> worked for me without this change.
>>
>> I think we should not add distfiles to the Subversion repository
>> anymore. They take up lots of room. I could make thousands of
>> portfile edits in the amount of disk space used by a single distfile.
>> I would rather use 1K in the repository to add a new distfiles mirror
>> to the portfile than use 5MB to store a copy of the distfile. There
>> is "no way" to remove data from the repository "ever" [1] so it has
>> always seemed like the wrong place to put distfiles. And thankfully
>> we now have a much better solution in the distfiles mirror. I think
>> the only reason to add a distfile to the repository is if the
>> distfiles mirror is unable to mirror it for some technical reason,
>> and that should be rare.
>>
>> I don't know if the Guide mentions putting distfiles into the
>> repository, but if it does, it should be changed to talk about the
>> distfiles mirror.
>>
> 
> 
> The distfile mirror actually got the iso-codes 3.1 tarball only an hour 
> ago due to a sync issue (it still saw v2.0). I noticed Blair had to 
> commit the tarball which is what prompted me to check the mirror status.
> 
> But in general, I agree people should rely on that server instead of 
> committing distfiles. I believe the plan is for MPWA to provide an 
> upload mechanism to manually add files.
> 
> If someone has trouble getting a distfile, and the mirror also doesnt 
> have it, they can submit a ticket to server/hosting and I'll try to get 
> it cleaned up. Note that the servers cannot retrieve files via FTP 
> either, so ports with only FTP will always be a problem, but I can 
> manually add the file so there should be no permanently missing 
> distfiles.  Also, please allow at least 24hr after a portfile is updated 
> before complaining though, as the mirror is only updated daily.

Thanks for this info.  Can we up the cron from 24 to something on a shorter basis?

Blair


From ryandesign at macports.org  Thu Jul 17 15:09:21 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 17 Jul 2008 17:09:21 -0500
Subject: Adding distfiles to the repository
In-Reply-To: <487FC125.5060507@orcaware.com>
References: <487F79F8.8060300@orcaware.com>
	<25CDFE40-DB83-4750-B90E-3735B32A6E3D@macports.org>
	<487FB718.9000109@orcaware.com>
	<14567128-9862-47FD-93CA-A3B1AA934258@macports.org>
	<882898A8-F1EC-41A7-9B7F-0BC0E1F1A482@apple.com>
	<487FC125.5060507@orcaware.com>
Message-ID: <2CF75407-3A06-44B1-A943-8B1BDAD6FE2A@macports.org>


On Jul 17, 2008, at 17:01, Blair Zajac wrote:

> William Siegrist wrote:
>>
>
>> please allow at least 24hr after a portfile is updated
>> before complaining though, as the mirror is only updated daily.
>
> Thanks for this info.  Can we up the cron from 24 to something on a  
> shorter basis?

This may be relevant for the php5-devel port as well. It's currently  
tracking php 5.2 release candidates but I now have a request from a  
user who wants to try a feature only available in php 5.3. The php  
team provides snapshot tarballs of php 5.3, but they're generated  
every two hours, and disappear after ten hours. So I would have to  
make sure to time my commit such that it's less than ten hours until  
the portmirror process runs on the distfiles mirror machine. Which I  
could do. But it would be convenient if I wouldn't have to remember  
to do that. Who knows what time of day I might feel like working on  
my ports.


From wsiegrist at apple.com  Thu Jul 17 15:57:30 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Thu, 17 Jul 2008 15:57:30 -0700
Subject: Adding distfiles to the repository
In-Reply-To: <487FC0E0.7020300@orcaware.com>
References: <487F79F8.8060300@orcaware.com>
	<25CDFE40-DB83-4750-B90E-3735B32A6E3D@macports.org>
	<487FB718.9000109@orcaware.com>
	<14567128-9862-47FD-93CA-A3B1AA934258@macports.org>
	<487FBF00.5000709@macports.org> <487FC0E0.7020300@orcaware.com>
Message-ID: <551C479F-B400-42C2-99DC-7A1916ABA7D6@apple.com>


On Jul 17, 2008, at 3:00 PM, Blair Zajac wrote:

> Rainer M?ller wrote:
>> Ryan Schmidt wrote:
>>> I think we should not add distfiles to the Subversion repository
>>> anymore. They take up lots of room. I could make thousands of
>>> portfile edits in the amount of disk space used by a single  
>>> distfile.
>>> I would rather use 1K in the repository to add a new distfiles  
>>> mirror
>>> to the portfile than use 5MB to store a copy of the distfile. There
>>> is "no way" to remove data from the repository "ever" [1] so it has
>>> always seemed like the wrong place to put distfiles. And thankfully
>>> we now have a much better solution in the distfiles mirror. I think
>>> the only reason to add a distfile to the repository is if the
>>> distfiles mirror is unable to mirror it for some technical reason,
>>> and that should be rare.
>>
>> I agree with you. Subversion repositories are not a good place to
>> archive non-changing binary data.
>
> Well, they are a good place to store non-changing binary data, it's  
> just if you
> don't need that data any more, say after a new version of the port  
> comes out,
> then you can't remove it and it consumes space forever.
>
> We could set up a new svn repository for distfiles, separate from  
> the one for
> Portfile's, and that repository could be exported and reimported  
> into a fresh
> repository every so often when it got too big.
>

The wasted space is all server-side right? So its not that big of a  
deal in the short term. MPWA should fix it for the long term.





-------------- 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/20080717/ffecee3d/attachment.bin 

From blair at orcaware.com  Thu Jul 17 16:00:14 2008
From: blair at orcaware.com (Blair Zajac)
Date: Thu, 17 Jul 2008 16:00:14 -0700
Subject: Adding distfiles to the repository
In-Reply-To: <551C479F-B400-42C2-99DC-7A1916ABA7D6@apple.com>
References: <487F79F8.8060300@orcaware.com>
	<25CDFE40-DB83-4750-B90E-3735B32A6E3D@macports.org>
	<487FB718.9000109@orcaware.com>
	<14567128-9862-47FD-93CA-A3B1AA934258@macports.org>
	<487FBF00.5000709@macports.org> <487FC0E0.7020300@orcaware.com>
	<551C479F-B400-42C2-99DC-7A1916ABA7D6@apple.com>
Message-ID: <487FCEFE.7060601@orcaware.com>

William Siegrist wrote:
> 
> On Jul 17, 2008, at 3:00 PM, Blair Zajac wrote:
> 
>> Rainer M?ller wrote:
>>> Ryan Schmidt wrote:
>>>> I think we should not add distfiles to the Subversion repository
>>>> anymore. They take up lots of room. I could make thousands of
>>>> portfile edits in the amount of disk space used by a single distfile.
>>>> I would rather use 1K in the repository to add a new distfiles mirror
>>>> to the portfile than use 5MB to store a copy of the distfile. There
>>>> is "no way" to remove data from the repository "ever" [1] so it has
>>>> always seemed like the wrong place to put distfiles. And thankfully
>>>> we now have a much better solution in the distfiles mirror. I think
>>>> the only reason to add a distfile to the repository is if the
>>>> distfiles mirror is unable to mirror it for some technical reason,
>>>> and that should be rare.
>>>
>>> I agree with you. Subversion repositories are not a good place to
>>> archive non-changing binary data.
>>
>> Well, they are a good place to store non-changing binary data, it's 
>> just if you
>> don't need that data any more, say after a new version of the port 
>> comes out,
>> then you can't remove it and it consumes space forever.
>>
>> We could set up a new svn repository for distfiles, separate from the 
>> one for
>> Portfile's, and that repository could be exported and reimported into 
>> a fresh
>> repository every so often when it got too big.
>>
> 
> The wasted space is all server-side right? So its not that big of a deal 
> in the short term. MPWA should fix it for the long term.

Right.  The problem is in the main repository, unless we dump and filter that 
svn repository, the dist files will never go away.  If we move the distfiles 
into a separate repository and then Portfile one should see very little growth.

Blair


From wsiegrist at apple.com  Thu Jul 17 16:03:04 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Thu, 17 Jul 2008 16:03:04 -0700
Subject: Adding distfiles to the repository
In-Reply-To: <2CF75407-3A06-44B1-A943-8B1BDAD6FE2A@macports.org>
References: <487F79F8.8060300@orcaware.com>
	<25CDFE40-DB83-4750-B90E-3735B32A6E3D@macports.org>
	<487FB718.9000109@orcaware.com>
	<14567128-9862-47FD-93CA-A3B1AA934258@macports.org>
	<882898A8-F1EC-41A7-9B7F-0BC0E1F1A482@apple.com>
	<487FC125.5060507@orcaware.com>
	<2CF75407-3A06-44B1-A943-8B1BDAD6FE2A@macports.org>
Message-ID: <9C706806-4C8A-4DF8-BADC-85CF8DCBA634@apple.com>


On Jul 17, 2008, at 3:09 PM, Ryan Schmidt wrote:

>
> On Jul 17, 2008, at 17:01, Blair Zajac wrote:
>
>> William Siegrist wrote:
>>>
>>
>>> please allow at least 24hr after a portfile is updated
>>> before complaining though, as the mirror is only updated daily.
>>
>> Thanks for this info.  Can we up the cron from 24 to something on a  
>> shorter basis?
>
> This may be relevant for the php5-devel port as well. It's currently  
> tracking php 5.2 release candidates but I now have a request from a  
> user who wants to try a feature only available in php 5.3. The php  
> team provides snapshot tarballs of php 5.3, but they're generated  
> every two hours, and disappear after ten hours. So I would have to  
> make sure to time my commit such that it's less than ten hours until  
> the portmirror process runs on the distfiles mirror machine. Which I  
> could do. But it would be convenient if I wouldn't have to remember  
> to do that. Who knows what time of day I might feel like working on  
> my ports.
>


The current process takes 6-8 hours to run and eats a decent amount of  
cpu cycles because it tries to mirror every variant of every port, so  
doing it more often wont work well on the server. Like I've said  
before, this allows for daily re-trying if the mirroring fails the  
first day.  What I could do is add a mirror attempt during post-commit  
as well. So every port gets mirrored upon commit and then once a day  
after that. When you commit, if your distfile is unavailable, it'll  
get retried the next morning during the daily job.  I think this is  
reasonable and covers everyone's needs.

-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/20080717/5822c50c/attachment.bin 

From blair at orcaware.com  Thu Jul 17 16:08:24 2008
From: blair at orcaware.com (Blair Zajac)
Date: Thu, 17 Jul 2008 16:08:24 -0700
Subject: Adding distfiles to the repository
In-Reply-To: <9C706806-4C8A-4DF8-BADC-85CF8DCBA634@apple.com>
References: <487F79F8.8060300@orcaware.com>
	<25CDFE40-DB83-4750-B90E-3735B32A6E3D@macports.org>
	<487FB718.9000109@orcaware.com>
	<14567128-9862-47FD-93CA-A3B1AA934258@macports.org>
	<882898A8-F1EC-41A7-9B7F-0BC0E1F1A482@apple.com>
	<487FC125.5060507@orcaware.com>
	<2CF75407-3A06-44B1-A943-8B1BDAD6FE2A@macports.org>
	<9C706806-4C8A-4DF8-BADC-85CF8DCBA634@apple.com>
Message-ID: <487FD0E8.5090308@orcaware.com>

William Siegrist wrote:
> 
> On Jul 17, 2008, at 3:09 PM, Ryan Schmidt wrote:
> 
>>
>> On Jul 17, 2008, at 17:01, Blair Zajac wrote:
>>
>>> William Siegrist wrote:
>>>>
>>>
>>>> please allow at least 24hr after a portfile is updated
>>>> before complaining though, as the mirror is only updated daily.
>>>
>>> Thanks for this info.  Can we up the cron from 24 to something on a 
>>> shorter basis?
>>
>> This may be relevant for the php5-devel port as well. It's currently 
>> tracking php 5.2 release candidates but I now have a request from a 
>> user who wants to try a feature only available in php 5.3. The php 
>> team provides snapshot tarballs of php 5.3, but they're generated 
>> every two hours, and disappear after ten hours. So I would have to 
>> make sure to time my commit such that it's less than ten hours until 
>> the portmirror process runs on the distfiles mirror machine. Which I 
>> could do. But it would be convenient if I wouldn't have to remember to 
>> do that. Who knows what time of day I might feel like working on my 
>> ports.
>>
> 
> 
> The current process takes 6-8 hours to run and eats a decent amount of 
> cpu cycles because it tries to mirror every variant of every port, so 
> doing it more often wont work well on the server. Like I've said before, 
> this allows for daily re-trying if the mirroring fails the first day.  
> What I could do is add a mirror attempt during post-commit as well. So 
> every port gets mirrored upon commit and then once a day after that. 
> When you commit, if your distfile is unavailable, it'll get retried the 
> next morning during the daily job.  I think this is reasonable and 
> covers everyone's needs.

That sounds good.

<joking>
Now we can just spam commits to get it to retry :)
</joking>

Blair


From blair at orcaware.com  Thu Jul 17 17:52:16 2008
From: blair at orcaware.com (Blair Zajac)
Date: Thu, 17 Jul 2008 17:52:16 -0700
Subject: How to fetch this URL
Message-ID: <487FE940.5000004@orcaware.com>

I can't get this URL to download through MacPorts even using the 
fetch.ignore_sslcert setting.

https://jna.dev.java.net/source/browse/*checkout*/jna/tags/3.0.4/jnalib/dist/jna.jar

Any ideas?  Could those * be causing trouble?

Regards,
Blair

From ryandesign at macports.org  Thu Jul 17 21:07:16 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 17 Jul 2008 23:07:16 -0500
Subject: How to fetch this URL
In-Reply-To: <487FE940.5000004@orcaware.com>
References: <487FE940.5000004@orcaware.com>
Message-ID: <F74A17B8-E3BF-41BA-849F-5F48AEFDC69D@macports.org>


On Jul 17, 2008, at 19:52, Blair Zajac wrote:

> I can't get this URL to download through MacPorts even using the
> fetch.ignore_sslcert setting.
>
> https://jna.dev.java.net/source/browse/*checkout*/jna/tags/3.0.4/ 
> jnalib/dist/jna.jar
>
> Any ideas?  Could those * be causing trouble?

"*" should be ok.

Without fetch.ignore_sslcert yes I get:


--->  Attempting to fetch jna.jar from https://jna.dev.java.net/ 
source/browse/*checkout*/jna/tags/3.0.4/jnalib/dist/

DEBUG: Fetching failed:: problem with the SSL CA cert (path? access  
rights?)


But with fetch.ignore_sslcert yes it seems to fetch ok:


--->  Attempting to fetch jna.jar from https://jna.dev.java.net/ 
source/browse/*checkout*/jna/tags/3.0.4/jnalib/dist/
   % Total    % Received % Xferd  Average Speed   Time    Time      
Time  Current
                                  Dload  Upload   Total   Spent     
Left  Speed
100  606k    0  606k    0     0   101k      0 --:--:--  0:00:05  
--:--:--  169k


Here's my test portfile:


PortSystem 1.0

name test
version 1.0

distname jna.jar
extract.suffix
extract {}
fetch.ignore_sslcert yes

master_sites https://jna.dev.java.net/source/browse/*checkout*/jna/ 
tags/3.0.4/jnalib/dist/



From wsiegrist at apple.com  Thu Jul 17 22:11:14 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Thu, 17 Jul 2008 22:11:14 -0700
Subject: [38374] trunk/dports/java
In-Reply-To: <20080718024221.7DF9915C4BB@beta.macosforge.org>
References: <20080718024221.7DF9915C4BB@beta.macosforge.org>
Message-ID: <25A40CDB-D8C8-4BDC-AB69-1148D1B1A8FE@apple.com>

This port fetches for me, but mirror fails.  Can you see if mirror  
works for you?

-Bill


On Jul 17, 2008, at 7:42 PM, blair at macports.org wrote:

> Revision38374Authorblair at macports.orgDate2008-07-17 19:42:21 -0700  
> (Thu, 17 Jul 2008)Log Message
> New port for Java Native Access 3.0.4.
> Added Paths
> 	? trunk/dports/java/jna/
> 	? trunk/dports/java/jna/Portfile
> Diff
> Added: trunk/dports/java/jna/Portfile (0 => 38374)
> --- trunk/dports/java/jna/Portfile	                        (rev 0)
> +++ trunk/dports/java/jna/Portfile	2008-07-18 02:42:21 UTC (rev 38374)
> @@ -0,0 +1,53 @@
> +# $Id$
> +
> +PortSystem 1.0
> +
> +name			jna
> +version			3.0.4
> +categories		java
> +platforms		darwin
> +maintainers		blair
> +description		Access to native shared libraries with pure Java code
> +
> +long_description	Java Native Access provides Java programs easy \
> +			access to native shared libraries (DLLs on Windows) \
> +			without writing anything but Java code - no JNI or \
> +			native code is required.  This functionality is \
> +			comparable to Windows' Platform/Invoke and Python's \
> +			ctypes.  Access is dynamic at runtime without code \
> +			generation.  JNA's design aims to provide native \
> +			access in a natural way with a minimum of effort.  \
> +			No boilerplate or generated code is required.  While \
> +			some attention is paid to performance, correctness \
> +			and ease of use take priority.
> +
> +homepage		https://jna.dev.java.net/
> +
> +master_sites		'https://${name}.dev.java.net/source/browse/ 
> *checkout*/${name}/tags/${version}/jnalib/dist/'
> +distfiles		${name}.jar
> +fetch.ignore_sslcert	yes
> +extract.only
> +
> +checksums		md5 7b6754e18e6145b7289c343a34c417e7 \
> +			sha1 2f348d9c132272434c910e15c25b6d1a06c7fd52 \
> +			rmd160 d1e264201808a2f9b16af49b1d319683135fe41c
> +
> +depends_lib		bin:java:kaffe
> +
> +use_configure		no
> +
> +fetch {
> +	system "curl -v -k 'https://${name}.dev.java.net/source/browse/ 
> *checkout*/${name}/tags/${version}/jnalib/dist/jna.jar' -o $ 
> {distpath}/${name}.jar.TMP"
> +	file delete -force ${distpath}/${name}.jar
> +	file rename ${distpath}/${name}.jar.TMP ${distpath}/${name}.jar
> +}
> +
> +build { }
> +
> +destroot {
> +	set javadir ${destroot}${prefix}/share/java
> +
> +	xinstall -d -m 755 ${javadir}
> +
> +	file copy ${distpath}/${name}.jar ${javadir}/
> +}
> Property changes on: trunk/dports/java/jna/Portfile
> ___________________________________________________________________
> Name: svn:keywords
>    + Id
> Name: svn:eol-style
>    + native
> _______________________________________________
> macports-changes mailing list
> macports-changes at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/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/20080717/38ef9fbe/attachment.bin 

From blair at orcaware.com  Thu Jul 17 22:42:10 2008
From: blair at orcaware.com (Blair Zajac)
Date: Thu, 17 Jul 2008 22:42:10 -0700
Subject: [38374] trunk/dports/java
In-Reply-To: <25A40CDB-D8C8-4BDC-AB69-1148D1B1A8FE@apple.com>
References: <20080718024221.7DF9915C4BB@beta.macosforge.org>
	<25A40CDB-D8C8-4BDC-AB69-1148D1B1A8FE@apple.com>
Message-ID: <48802D32.207@orcaware.com>

I was unable to get this port to fetch using the normal master_sites I have in 
their so I needed to use the custom fetch command.

Can you try fetching it commenting out my custom fetch { }?

Regards,
Blair

William Siegrist wrote:
> This port fetches for me, but mirror fails.  Can you see if mirror works 
> for you?
> 
> -Bill
> 
> 
> On Jul 17, 2008, at 7:42 PM, blair at macports.org wrote:
> 
>> Revision38374Authorblair at macports.orgDate2008-07-17 19:42:21 -0700 
>> (Thu, 17 Jul 2008)Log Message
>> New port for Java Native Access 3.0.4.
>> Added Paths
>>     ? trunk/dports/java/jna/
>>     ? trunk/dports/java/jna/Portfile
>> Diff
>> Added: trunk/dports/java/jna/Portfile (0 => 38374)
>> --- trunk/dports/java/jna/Portfile                            (rev 0)
>> +++ trunk/dports/java/jna/Portfile    2008-07-18 02:42:21 UTC (rev 38374)
>> @@ -0,0 +1,53 @@
>> +# $Id$
>> +
>> +PortSystem 1.0
>> +
>> +name            jna
>> +version            3.0.4
>> +categories        java
>> +platforms        darwin
>> +maintainers        blair
>> +description        Access to native shared libraries with pure Java code
>> +
>> +long_description    Java Native Access provides Java programs easy \
>> +            access to native shared libraries (DLLs on Windows) \
>> +            without writing anything but Java code - no JNI or \
>> +            native code is required.  This functionality is \
>> +            comparable to Windows' Platform/Invoke and Python's \
>> +            ctypes.  Access is dynamic at runtime without code \
>> +            generation.  JNA's design aims to provide native \
>> +            access in a natural way with a minimum of effort.  \
>> +            No boilerplate or generated code is required.  While \
>> +            some attention is paid to performance, correctness \
>> +            and ease of use take priority.
>> +
>> +homepage        https://jna.dev.java.net/
>> +
>> +master_sites        
>> 'https://${name}.dev.java.net/source/browse/*checkout*/${name}/tags/${version}/jnalib/dist/' 
>>
>> +distfiles        ${name}.jar
>> +fetch.ignore_sslcert    yes
>> +extract.only
>> +
>> +checksums        md5 7b6754e18e6145b7289c343a34c417e7 \
>> +            sha1 2f348d9c132272434c910e15c25b6d1a06c7fd52 \
>> +            rmd160 d1e264201808a2f9b16af49b1d319683135fe41c
>> +
>> +depends_lib        bin:java:kaffe
>> +
>> +use_configure        no
>> +
>> +fetch {
>> +    system "curl -v -k 
>> 'https://${name}.dev.java.net/source/browse/*checkout*/${name}/tags/${version}/jnalib/dist/jna.jar' 
>> -o ${distpath}/${name}.jar.TMP"
>> +    file delete -force ${distpath}/${name}.jar
>> +    file rename ${distpath}/${name}.jar.TMP ${distpath}/${name}.jar
>> +}
>> +
>> +build { }
>> +
>> +destroot {
>> +    set javadir ${destroot}${prefix}/share/java
>> +
>> +    xinstall -d -m 755 ${javadir}
>> +
>> +    file copy ${distpath}/${name}.jar ${javadir}/
>> +}
>> Property changes on: trunk/dports/java/jna/Portfile
>> ___________________________________________________________________
>> Name: svn:keywords
>>    + Id
>> Name: svn:eol-style
>>    + native

From wsiegrist at apple.com  Thu Jul 17 23:37:13 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Thu, 17 Jul 2008 23:37:13 -0700
Subject: [38374] trunk/dports/java
In-Reply-To: <48802D32.207@orcaware.com>
References: <20080718024221.7DF9915C4BB@beta.macosforge.org>
	<25A40CDB-D8C8-4BDC-AB69-1148D1B1A8FE@apple.com>
	<48802D32.207@orcaware.com>
Message-ID: <2D82732B-D068-4D15-BFB1-7E255240DC04@apple.com>

It doesnt fetch using the built in fetch, so your custom fetch is  
needed. If I copy that fetch block to make a mirror block it mostly  
works, though the file ends up in $prefix/var/macports/distfiles/  
instead of down in .../java/jna/ like your fetch. So $distpast gets  
defined differently between fetch and mirror?

-Bill

On Jul 17, 2008, at 10:42 PM, Blair Zajac wrote:

> I was unable to get this port to fetch using the normal master_sites  
> I have in their so I needed to use the custom fetch command.
>
> Can you try fetching it commenting out my custom fetch { }?
>
> Regards,
> Blair
>
> William Siegrist wrote:
>> This port fetches for me, but mirror fails.  Can you see if mirror  
>> works for you?
>> -Bill
>> On Jul 17, 2008, at 7:42 PM, blair at macports.org wrote:
>>> Revision38374Authorblair at macports.orgDate2008-07-17 19:42:21 -0700  
>>> (Thu, 17 Jul 2008)Log Message
>>> New port for Java Native Access 3.0.4.
>>> Added Paths
>>>    ? trunk/dports/java/jna/
>>>    ? trunk/dports/java/jna/Portfile
>>> Diff
>>> Added: trunk/dports/java/jna/Portfile (0 => 38374)
>>> --- trunk/dports/java/jna/Portfile                            (rev  
>>> 0)
>>> +++ trunk/dports/java/jna/Portfile    2008-07-18 02:42:21 UTC (rev  
>>> 38374)
>>> @@ -0,0 +1,53 @@
>>> +# $Id$
>>> +
>>> +PortSystem 1.0
>>> +
>>> +name            jna
>>> +version            3.0.4
>>> +categories        java
>>> +platforms        darwin
>>> +maintainers        blair
>>> +description        Access to native shared libraries with pure  
>>> Java code
>>> +
>>> +long_description    Java Native Access provides Java programs  
>>> easy \
>>> +            access to native shared libraries (DLLs on Windows) \
>>> +            without writing anything but Java code - no JNI or \
>>> +            native code is required.  This functionality is \
>>> +            comparable to Windows' Platform/Invoke and Python's \
>>> +            ctypes.  Access is dynamic at runtime without code \
>>> +            generation.  JNA's design aims to provide native \
>>> +            access in a natural way with a minimum of effort.  \
>>> +            No boilerplate or generated code is required.  While \
>>> +            some attention is paid to performance, correctness \
>>> +            and ease of use take priority.
>>> +
>>> +homepage        https://jna.dev.java.net/
>>> +
>>> +master_sites        'https://${name}.dev.java.net/source/browse/ 
>>> *checkout*/${name}/tags/${version}/jnalib/dist/'
>>> +distfiles        ${name}.jar
>>> +fetch.ignore_sslcert    yes
>>> +extract.only
>>> +
>>> +checksums        md5 7b6754e18e6145b7289c343a34c417e7 \
>>> +            sha1 2f348d9c132272434c910e15c25b6d1a06c7fd52 \
>>> +            rmd160 d1e264201808a2f9b16af49b1d319683135fe41c
>>> +
>>> +depends_lib        bin:java:kaffe
>>> +
>>> +use_configure        no
>>> +
>>> +fetch {
>>> +    system "curl -v -k 'https://${name}.dev.java.net/source/ 
>>> browse/*checkout*/${name}/tags/${version}/jnalib/dist/jna.jar' -o $ 
>>> {distpath}/${name}.jar.TMP"
>>> +    file delete -force ${distpath}/${name}.jar
>>> +    file rename ${distpath}/${name}.jar.TMP ${distpath}/${name}.jar
>>> +}
>>> +
>>> +build { }
>>> +
>>> +destroot {
>>> +    set javadir ${destroot}${prefix}/share/java
>>> +
>>> +    xinstall -d -m 755 ${javadir}
>>> +
>>> +    file copy ${distpath}/${name}.jar ${javadir}/
>>> +}
>>> Property changes on: trunk/dports/java/jna/Portfile
>>> ___________________________________________________________________
>>> Name: svn:keywords
>>>   + Id
>>> Name: svn:eol-style
>>>   + native




----
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/20080717/23befca0/attachment.bin 

From ryandesign at macports.org  Fri Jul 18 00:36:54 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 18 Jul 2008 02:36:54 -0500
Subject: [38374] trunk/dports/java
In-Reply-To: <2D82732B-D068-4D15-BFB1-7E255240DC04@apple.com>
References: <20080718024221.7DF9915C4BB@beta.macosforge.org>
	<25A40CDB-D8C8-4BDC-AB69-1148D1B1A8FE@apple.com>
	<48802D32.207@orcaware.com>
	<2D82732B-D068-4D15-BFB1-7E255240DC04@apple.com>
Message-ID: <58DADF7A-3A3A-4159-850F-414193D5E060@macports.org>

It does fetch for me using the built-in fetch, see attached patch.


On Jul 18, 2008, at 01:37, William Siegrist wrote:

> It doesnt fetch using the built in fetch, so your custom fetch is  
> needed. If I copy that fetch block to make a mirror block it mostly  
> works, though the file ends up in $prefix/var/macports/distfiles/  
> instead of down in .../java/jna/ like your fetch. So $distpast gets  
> defined differently between fetch and mirror?
>
> -Bill
>
> On Jul 17, 2008, at 10:42 PM, Blair Zajac wrote:
>
>> I was unable to get this port to fetch using the normal  
>> master_sites I have in their so I needed to use the custom fetch  
>> command.
>>
>> Can you try fetching it commenting out my custom fetch { }?
>>
>> Regards,
>> Blair
>>
>> William Siegrist wrote:
>>> This port fetches for me, but mirror fails.  Can you see if  
>>> mirror works for you?
>>> -Bill
>>> On Jul 17, 2008, at 7:42 PM, blair at macports.org wrote:
>>>> Revision38374Authorblair at macports.orgDate2008-07-17 19:42:21  
>>>> -0700 (Thu, 17 Jul 2008)Log Message
>>>> New port for Java Native Access 3.0.4.
>>>> Added Paths
>>>>    ? trunk/dports/java/jna/
>>>>    ? trunk/dports/java/jna/Portfile
>>>> Diff
>>>> Added: trunk/dports/java/jna/Portfile (0 => 38374)
>>>> --- trunk/dports/java/jna/Portfile                             
>>>> (rev 0)
>>>> +++ trunk/dports/java/jna/Portfile    2008-07-18 02:42:21 UTC  
>>>> (rev 38374)
>>>> @@ -0,0 +1,53 @@
>>>> +# $Id$
>>>> +
>>>> +PortSystem 1.0
>>>> +
>>>> +name            jna
>>>> +version            3.0.4
>>>> +categories        java
>>>> +platforms        darwin
>>>> +maintainers        blair
>>>> +description        Access to native shared libraries with pure  
>>>> Java code
>>>> +
>>>> +long_description    Java Native Access provides Java programs  
>>>> easy \
>>>> +            access to native shared libraries (DLLs on Windows) \
>>>> +            without writing anything but Java code - no JNI or \
>>>> +            native code is required.  This functionality is \
>>>> +            comparable to Windows' Platform/Invoke and Python's \
>>>> +            ctypes.  Access is dynamic at runtime without code \
>>>> +            generation.  JNA's design aims to provide native \
>>>> +            access in a natural way with a minimum of effort.  \
>>>> +            No boilerplate or generated code is required.  While \
>>>> +            some attention is paid to performance, correctness \
>>>> +            and ease of use take priority.
>>>> +
>>>> +homepage        https://jna.dev.java.net/
>>>> +
>>>> +master_sites        'https://${name}.dev.java.net/source/browse/ 
>>>> *checkout*/${name}/tags/${version}/jnalib/dist/'
>>>> +distfiles        ${name}.jar
>>>> +fetch.ignore_sslcert    yes
>>>> +extract.only
>>>> +
>>>> +checksums        md5 7b6754e18e6145b7289c343a34c417e7 \
>>>> +            sha1 2f348d9c132272434c910e15c25b6d1a06c7fd52 \
>>>> +            rmd160 d1e264201808a2f9b16af49b1d319683135fe41c
>>>> +
>>>> +depends_lib        bin:java:kaffe
>>>> +
>>>> +use_configure        no
>>>> +
>>>> +fetch {
>>>> +    system "curl -v -k 'https://${name}.dev.java.net/source/ 
>>>> browse/*checkout*/${name}/tags/${version}/jnalib/dist/jna.jar' - 
>>>> o ${distpath}/${name}.jar.TMP"
>>>> +    file delete -force ${distpath}/${name}.jar
>>>> +    file rename ${distpath}/${name}.jar.TMP ${distpath}/$ 
>>>> {name}.jar
>>>> +}
>>>> +
>>>> +build { }
>>>> +
>>>> +destroot {
>>>> +    set javadir ${destroot}${prefix}/share/java
>>>> +
>>>> +    xinstall -d -m 755 ${javadir}
>>>> +
>>>> +    file copy ${distpath}/${name}.jar ${javadir}/
>>>> +}
>>>> Property changes on: trunk/dports/java/jna/Portfile
>>>> ___________________________________________________________________
>>>> Name: svn:keywords
>>>>   + Id
>>>> Name: svn:eol-style
>>>>   + native


-------------- next part --------------
A non-text attachment was scrubbed...
Name: jna.diff
Type: application/octet-stream
Size: 806 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080718/00062060/attachment-0001.obj 
-------------- next part --------------


From ryandesign at macports.org  Fri Jul 18 03:02:20 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 18 Jul 2008 05:02:20 -0500
Subject: build.dir not based on configure.dir
Message-ID: <5259ACC0-CF1E-4987-9BBA-E281FAF2DA7A@macports.org>

from portconfigure.tcl:

default configure.dir       {${worksrcpath}}


from portbuild.tcl:

default build.dir {${workpath}/${worksrcdir}}


from portdestroot.tcl:

default destroot.dir {${build.dir}}



So destroot.dir is based on build.dir but build.dir isn't based on  
configure.dir. Why not? It means that if a port wants to override the  
configure/build/destroot directory it has to set both the  
configure.dir and the build.dir. Wouldn't it be nice if it could just  
set the configure.dir and the others would inherit the new value?


From ryandesign at macports.org  Fri Jul 18 03:07:14 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 18 Jul 2008 05:07:14 -0500
Subject: [38384] trunk/dports/lang
In-Reply-To: <20080718092331.A7B8115D1D1@beta.macosforge.org>
References: <20080718092331.A7B8115D1D1@beta.macosforge.org>
Message-ID: <75AB6EE3-4F75-498A-A613-0C20289EF243@macports.org>


On Jul 18, 2008, at 04:23, pguyot at kallisys.net wrote:

> Revision: 38384
>           http://trac.macosforge.org/projects/macports/changeset/38384
> Author:   pguyot at kallisys.net
> Date:     2008-07-18 02:23:30 -0700 (Fri, 18 Jul 2008)
> Log Message:
> -----------
> new port: lang/llvm-devel, a recent checkout of llvm with clang/ 
> checker as a variant
>
> Added Paths:
> -----------
>     trunk/dports/lang/llvm-devel/
>     trunk/dports/lang/llvm-devel/Portfile
>     trunk/dports/lang/llvm-devel/files/
>     trunk/dports/lang/llvm-devel/files/patch-tools-Makefile.diff

It would be nice if you would use "svn cp" to copy this Portfile from  
the llvm Portfile and then make changes, rather than calling it into  
existence as a new file here. That way "svn log" and "svn blame"  
would be useful. Could you please re-create the port this way? Thanks.


From ryandesign at macports.org  Fri Jul 18 03:36:30 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 18 Jul 2008 05:36:30 -0500
Subject: [38384] trunk/dports/lang
In-Reply-To: <75AB6EE3-4F75-498A-A613-0C20289EF243@macports.org>
References: <20080718092331.A7B8115D1D1@beta.macosforge.org>
	<75AB6EE3-4F75-498A-A613-0C20289EF243@macports.org>
Message-ID: <01224C56-0887-40A6-9E6E-97E12C900793@macports.org>

On Jul 18, 2008, at 05:07, Ryan Schmidt wrote:

> On Jul 18, 2008, at 04:23, pguyot at kallisys.net wrote:
>
>> Revision: 38384
>>           http://trac.macosforge.org/projects/macports/changeset/ 
>> 38384
>> Author:   pguyot at kallisys.net
>> Date:     2008-07-18 02:23:30 -0700 (Fri, 18 Jul 2008)
>> Log Message:
>> -----------
>> new port: lang/llvm-devel, a recent checkout of llvm with clang/
>> checker as a variant
>>
>> Added Paths:
>> -----------
>>     trunk/dports/lang/llvm-devel/
>>     trunk/dports/lang/llvm-devel/Portfile
>>     trunk/dports/lang/llvm-devel/files/
>>     trunk/dports/lang/llvm-devel/files/patch-tools-Makefile.diff
>
> It would be nice if you would use "svn cp" to copy this Portfile from
> the llvm Portfile and then make changes, rather than calling it into
> existence as a new file here. That way "svn log" and "svn blame"
> would be useful. Could you please re-create the port this way? Thanks.

Then you can also pick up the fixes I just made to the llvm port.


From dluke at geeklair.net  Fri Jul 18 06:02:23 2008
From: dluke at geeklair.net (Daniel J. Luke)
Date: Fri, 18 Jul 2008 09:02:23 -0400
Subject: build.dir not based on configure.dir
In-Reply-To: <5259ACC0-CF1E-4987-9BBA-E281FAF2DA7A@macports.org>
References: <5259ACC0-CF1E-4987-9BBA-E281FAF2DA7A@macports.org>
Message-ID: <E5BBC982-9B93-4ECF-917A-992C6071ACA8@geeklair.net>

On Jul 18, 2008, at 6:02 AM, Ryan Schmidt wrote:
> So destroot.dir is based on build.dir but build.dir isn't based on
> configure.dir. Why not? It means that if a port wants to override the
> configure/build/destroot directory it has to set both the
> configure.dir and the build.dir. Wouldn't it be nice if it could just
> set the configure.dir and the others would inherit the new value?


I think this was set this way because there are project where the  
configure script is buried somewhere while you still need to run  
'make' from the top level directory.

I'm not sure how common that is, however, so it might make sense to  
swap the default to your suggestion (we'd have to go through and make  
sure we don't break anything that depends on the old behavior, though).

--
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/20080718/b29fea11/attachment.bin 

From blair at orcaware.com  Fri Jul 18 09:36:59 2008
From: blair at orcaware.com (Blair Zajac)
Date: Fri, 18 Jul 2008 09:36:59 -0700
Subject: [38374] trunk/dports/java
In-Reply-To: <58DADF7A-3A3A-4159-850F-414193D5E060@macports.org>
References: <20080718024221.7DF9915C4BB@beta.macosforge.org>
	<25A40CDB-D8C8-4BDC-AB69-1148D1B1A8FE@apple.com>
	<48802D32.207@orcaware.com>
	<2D82732B-D068-4D15-BFB1-7E255240DC04@apple.com>
	<58DADF7A-3A3A-4159-850F-414193D5E060@macports.org>
Message-ID: <4880C6AB.2060004@orcaware.com>

I applied that patch and it doesn't work for me.

$ port -d -v fetch jna
DEBUG: Found port in 
file:///Users/blair/my-macports/var/macports/sources/rsync.macports.org/release/ports/java/jna
DEBUG: Changing to port directory: 
/Users/blair/my-macports/var/macports/sources/rsync.macports.org/release/ports/java/jna
DEBUG: Requested variant darwin is not provided by port jna.
DEBUG: Requested variant i386 is not provided by port jna.
DEBUG: Requested variant macosx is not provided by port jna.
Portfile changed since last build; discarding previous state.
DEBUG: Executing org.macports.main (jna)
--->  Fetching jna
DEBUG: Executing org.macports.fetch (jna)
--->  jna.jar doesn't seem to exist in 
/Users/blair/my-macports/var/macports/distfiles/jna
--->  Attempting to fetch jna.jar from 
https://jna.dev.java.net/source/browse/*checkout*/jna/tags/3.0.4/jnalib/dist/

DEBUG: Fetching failed:: couldn't connect to server
--->  Attempting to fetch jna.jar from 
http://svn.macports.org/repository/macports/distfiles/jna

Blair

Ryan Schmidt wrote:
> It does fetch for me using the built-in fetch, see attached patch.
> 
> 
> On Jul 18, 2008, at 01:37, William Siegrist wrote:
> 
>> It doesnt fetch using the built in fetch, so your custom fetch is 
>> needed. If I copy that fetch block to make a mirror block it mostly 
>> works, though the file ends up in $prefix/var/macports/distfiles/ 
>> instead of down in .../java/jna/ like your fetch. So $distpast gets 
>> defined differently between fetch and mirror?
>>
>> -Bill

From wsiegrist at apple.com  Fri Jul 18 10:35:05 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Fri, 18 Jul 2008 10:35:05 -0700
Subject: [MacPorts] #15908: Ticket queries are not useful
In-Reply-To: <87prpbozvz.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <054.cd95a8ecf60b4f509e56eec4ea30ea4b@macports.org>
	<063.c141434de706c81c2b87ca304ba46456@macports.org>
	<87prpbozvz.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <DC900F2A-73BD-4AD7-891D-B9FCE2A798AB@apple.com>

On Jul 18, 2008, at 10:39 AM, Stephen J. Turnbull wrote:

> MacPorts writes:
>> #15908: Ticket queries are not useful
>> --------------------------------- 
>> +------------------------------------------
>>  Reporter:  stephen at xemacs.org  |       Owner:  wsiegrist at apple.com
>>      Type:  defect              |      Status:  new
>>  Priority:  Normal              |   Milestone:  Website &  
>> Documentation
>> Component:  server/hosting      |     Version:
>> Resolution:                      |    Keywords:  query, results order
>> --------------------------------- 
>> +------------------------------------------
>> Comment (by wsiegrist at apple.com):
>>
>> I also do not understand. Can you give me a URL for which page you  
>> think
>> needs to be sorted, and tell me the heading of the column you want  
>> it to
>> sort by?
>
> On looking again, nothing seems to need to be done, after all.
>
> The problem that I face is that there didn't seem to be a good way to
> look for bug reports on a specific port.  Eg, search for "sbcl build"
> which is currently broken returned hundreds of results, of the first
> 100 of which only 3 were relevant.
>
> But now when I try it I get only 19 results, with the same 3
> included.  I don't understand what's changed, but I can't reproduce
> the previous output.
>
> Unfortunately a lot of people submit their entire list of installed
> ports, so about half of those contain "sbcl" only by accident.

You should keep an eye on <http://trac.macports.org/ticket/15210> then  
which will allow you to use the Custom Query page to search for  
tickets about a specific port. This wont solve the problem of users  
not knowing which port is actually broken when its a dependency that  
fails, but its better than what we currently have.


-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/20080718/c59c3d32/attachment.bin 

From blair at orcaware.com  Fri Jul 18 10:43:52 2008
From: blair at orcaware.com (Blair Zajac)
Date: Fri, 18 Jul 2008 10:43:52 -0700
Subject: [38374] trunk/dports/java
In-Reply-To: <4880C6AB.2060004@orcaware.com>
References: <20080718024221.7DF9915C4BB@beta.macosforge.org>
	<25A40CDB-D8C8-4BDC-AB69-1148D1B1A8FE@apple.com>
	<48802D32.207@orcaware.com>
	<2D82732B-D068-4D15-BFB1-7E255240DC04@apple.com>
	<58DADF7A-3A3A-4159-850F-414193D5E060@macports.org>
	<4880C6AB.2060004@orcaware.com>
Message-ID: <4880D658.9030607@orcaware.com>

Nevermind, I didn't have the HTTPS_PROXY environmental variable set, I had 
https_proxy set which curl doesn't use.

I applied the patch in r38404.

Blair

Blair Zajac wrote:
> I applied that patch and it doesn't work for me.
> 
> $ port -d -v fetch jna
> DEBUG: Found port in 
> file:///Users/blair/my-macports/var/macports/sources/rsync.macports.org/release/ports/java/jna 
> 
> DEBUG: Changing to port directory: 
> /Users/blair/my-macports/var/macports/sources/rsync.macports.org/release/ports/java/jna 
> 
> DEBUG: Requested variant darwin is not provided by port jna.
> DEBUG: Requested variant i386 is not provided by port jna.
> DEBUG: Requested variant macosx is not provided by port jna.
> Portfile changed since last build; discarding previous state.
> DEBUG: Executing org.macports.main (jna)
> --->  Fetching jna
> DEBUG: Executing org.macports.fetch (jna)
> --->  jna.jar doesn't seem to exist in 
> /Users/blair/my-macports/var/macports/distfiles/jna
> --->  Attempting to fetch jna.jar from 
> https://jna.dev.java.net/source/browse/*checkout*/jna/tags/3.0.4/jnalib/dist/ 
> 
> 
> DEBUG: Fetching failed:: couldn't connect to server
> --->  Attempting to fetch jna.jar from 
> http://svn.macports.org/repository/macports/distfiles/jna
> 
> Blair
> 
> Ryan Schmidt wrote:
>> It does fetch for me using the built-in fetch, see attached patch.
>>
>>
>> On Jul 18, 2008, at 01:37, William Siegrist wrote:
>>
>>> It doesnt fetch using the built in fetch, so your custom fetch is 
>>> needed. If I copy that fetch block to make a mirror block it mostly 
>>> works, though the file ends up in $prefix/var/macports/distfiles/ 
>>> instead of down in .../java/jna/ like your fetch. So $distpast gets 
>>> defined differently between fetch and mirror?
>>>
>>> -Bill

From wsiegrist at apple.com  Fri Jul 18 10:45:26 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Fri, 18 Jul 2008 10:45:26 -0700
Subject: Adding distfiles to the repository
In-Reply-To: <487FD0E8.5090308@orcaware.com>
References: <487F79F8.8060300@orcaware.com>
	<25CDFE40-DB83-4750-B90E-3735B32A6E3D@macports.org>
	<487FB718.9000109@orcaware.com>
	<14567128-9862-47FD-93CA-A3B1AA934258@macports.org>
	<882898A8-F1EC-41A7-9B7F-0BC0E1F1A482@apple.com>
	<487FC125.5060507@orcaware.com>
	<2CF75407-3A06-44B1-A943-8B1BDAD6FE2A@macports.org>
	<9C706806-4C8A-4DF8-BADC-85CF8DCBA634@apple.com>
	<487FD0E8.5090308@orcaware.com>
Message-ID: <0FD9803A-2D93-4B09-94C0-70F4DCBF6747@apple.com>

On Jul 17, 2008, at 4:08 PM, Blair Zajac wrote:

> William Siegrist wrote:
>> On Jul 17, 2008, at 3:09 PM, Ryan Schmidt wrote:
>>>
>>> On Jul 17, 2008, at 17:01, Blair Zajac wrote:
>>>
>>>> William Siegrist wrote:
>>>>>
>>>>
>>>>> please allow at least 24hr after a portfile is updated
>>>>> before complaining though, as the mirror is only updated daily.
>>>>
>>>> Thanks for this info.  Can we up the cron from 24 to something on  
>>>> a shorter basis?
>>>
>>> This may be relevant for the php5-devel port as well. It's  
>>> currently tracking php 5.2 release candidates but I now have a  
>>> request from a user who wants to try a feature only available in  
>>> php 5.3. The php team provides snapshot tarballs of php 5.3, but  
>>> they're generated every two hours, and disappear after ten hours.  
>>> So I would have to make sure to time my commit such that it's less  
>>> than ten hours until the portmirror process runs on the distfiles  
>>> mirror machine. Which I could do. But it would be convenient if I  
>>> wouldn't have to remember to do that. Who knows what time of day I  
>>> might feel like working on my ports.
>>>
>> The current process takes 6-8 hours to run and eats a decent amount  
>> of cpu cycles because it tries to mirror every variant of every  
>> port, so doing it more often wont work well on the server. Like  
>> I've said before, this allows for daily re-trying if the mirroring  
>> fails the first day.  What I could do is add a mirror attempt  
>> during post-commit as well. So every port gets mirrored upon commit  
>> and then once a day after that. When you commit, if your distfile  
>> is unavailable, it'll get retried the next morning during the daily  
>> job.  I think this is reasonable and covers everyone's needs.
>
> That sounds good.
>

I have a slightly-tested job in place for post-commit mirroring. It  
will send email to maintainers if mirroring fails, much like how lint  
nags you.

As for retriggering with extra commits, it actually doesnt try to  
detect a distfile change. So if you commit lint or whitespace changes,  
it'll try mirroring again.  But dont rely on or abuse that side  
effect, just ping me in IRC or email me if you have mirroring issues.

-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/20080718/b848f220/attachment.bin 

From 0x62_0x6c_0x62 at pobox.com  Fri Jul 18 13:58:24 2008
From: 0x62_0x6c_0x62 at pobox.com (Bryan Blackburn)
Date: Fri, 18 Jul 2008 14:58:24 -0600
Subject: [MacPorts] #15908: Ticket queries are not useful
In-Reply-To: <DC900F2A-73BD-4AD7-891D-B9FCE2A798AB@apple.com>
References: <054.cd95a8ecf60b4f509e56eec4ea30ea4b@macports.org>
	<063.c141434de706c81c2b87ca304ba46456@macports.org>
	<87prpbozvz.fsf@uwakimon.sk.tsukuba.ac.jp>
	<DC900F2A-73BD-4AD7-891D-B9FCE2A798AB@apple.com>
Message-ID: <97CE7AF8-9740-4EB3-B69C-F23B612DF9CD@pobox.com>

On Jul 18, 2008, at 11:35 AM, William Siegrist wrote:

...
>
> You should keep an eye on <http://trac.macports.org/ticket/15210>  
> then which will allow you to use the Custom Query page to search for  
> tickets about a specific port. This wont solve the problem of users  
> not knowing which port is actually broken when its a dependency that  
> fails, but its better than what we currently have.
>

I always just go to the custom query page [1], add a summary filter,  
and put the port name there; as long as people follow the proper trac  
ticketing guidelines [2] this works quite nicely.  E.g., only three  
hits for open sbcl tickets (#14036, #14241, and #15157).

I've found using the base search portion of trac, though, does result  
in lots of excess, since it defaults to search tickets (all parts of  
them, open and closed), changesets, and the wiki...

Bryan

[1] - <http://trac.macports.org/query>
[2] - <http://guide.macports.org/#project.tickets>


>
> -Bill
>
>

From ryandesign at macports.org  Fri Jul 18 17:13:51 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 18 Jul 2008 19:13:51 -0500
Subject: [MacPorts] #15908: Ticket queries are not useful
In-Reply-To: <97CE7AF8-9740-4EB3-B69C-F23B612DF9CD@pobox.com>
References: <054.cd95a8ecf60b4f509e56eec4ea30ea4b@macports.org>
	<063.c141434de706c81c2b87ca304ba46456@macports.org>
	<87prpbozvz.fsf@uwakimon.sk.tsukuba.ac.jp>
	<DC900F2A-73BD-4AD7-891D-B9FCE2A798AB@apple.com>
	<97CE7AF8-9740-4EB3-B69C-F23B612DF9CD@pobox.com>
Message-ID: <D5B58B71-AAFA-41E3-8744-E110A177FE02@macports.org>


On Jul 18, 2008, at 15:58, Bryan Blackburn wrote:

> On Jul 18, 2008, at 11:35 AM, William Siegrist wrote:
>
>> You should keep an eye on <http://trac.macports.org/ticket/15210>
>> then which will allow you to use the Custom Query page to search for
>> tickets about a specific port. This wont solve the problem of users
>> not knowing which port is actually broken when its a dependency that
>> fails, but its better than what we currently have.
>
> I always just go to the custom query page [1], add a summary filter,
> and put the port name there; as long as people follow the proper trac
> ticketing guidelines [2] this works quite nicely.  E.g., only three
> hits for open sbcl tickets (#14036, #14241, and #15157).

I do this too.

> I've found using the base search portion of trac, though, does result
> in lots of excess, since it defaults to search tickets (all parts of
> them, open and closed), changesets, and the wiki...

I used the default search box in Trac a couple times when we first  
switched to Trac, then never again, because it never gave me the  
results I needed.

Would like a search box added which does just a summary search on  
tickets. Not sure where it should be placed but it's almost the only  
search I do. Add a drop-down menu for whether you want to search for  
new or open or closed tickets and you've taken care of a majority of  
users' search needs I think. Like in the attached ticket_search.php.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ticket_search.php
Type: text/php
Size: 808 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080718/b52c1f81/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: search_redirect.php
Type: text/php
Size: 580 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080718/b52c1f81/attachment-0003.bin 

From wsiegrist at apple.com  Fri Jul 18 19:00:09 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Fri, 18 Jul 2008 19:00:09 -0700
Subject: Distfile Mirror Mirroring
Message-ID: <C1311826-F29C-49E0-B55E-C717526403FE@apple.com>

If anyone wants to provide more distfile mirrors for MP, or just  
collect all of the distfiles, you can rsync from the main mirror at <rsync://rsync.macports.org/mpdistfiles/ 
 >. You could of course just do a "port mirror" for every port &  
variant like we do, but I thought I would point out this rsync module  
in case it helps. The size grows over time since we dont delete  
anything, but its currently around 15GB.


-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/20080718/689ac5aa/attachment.bin 

From wsiegrist at apple.com  Fri Jul 18 19:38:12 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Fri, 18 Jul 2008 19:38:12 -0700
Subject: [MacPorts] #15908: Ticket queries are not useful
In-Reply-To: <D5B58B71-AAFA-41E3-8744-E110A177FE02@macports.org>
References: <054.cd95a8ecf60b4f509e56eec4ea30ea4b@macports.org>
	<063.c141434de706c81c2b87ca304ba46456@macports.org>
	<87prpbozvz.fsf@uwakimon.sk.tsukuba.ac.jp>
	<DC900F2A-73BD-4AD7-891D-B9FCE2A798AB@apple.com>
	<97CE7AF8-9740-4EB3-B69C-F23B612DF9CD@pobox.com>
	<D5B58B71-AAFA-41E3-8744-E110A177FE02@macports.org>
Message-ID: <1921E89A-91A6-4BE0-8248-5704E0D808D6@apple.com>


On Jul 18, 2008, at 5:13 PM, Ryan Schmidt wrote:

>
> On Jul 18, 2008, at 15:58, Bryan Blackburn wrote:
>
>> On Jul 18, 2008, at 11:35 AM, William Siegrist wrote:
>>
>>> You should keep an eye on <http://trac.macports.org/ticket/15210>
>>> then which will allow you to use the Custom Query page to search for
>>> tickets about a specific port. This wont solve the problem of users
>>> not knowing which port is actually broken when its a dependency that
>>> fails, but its better than what we currently have.
>>
>> I always just go to the custom query page [1], add a summary filter,
>> and put the port name there; as long as people follow the proper trac
>> ticketing guidelines [2] this works quite nicely.  E.g., only three
>> hits for open sbcl tickets (#14036, #14241, and #15157).
>
> I do this too.
>
>> I've found using the base search portion of trac, though, does result
>> in lots of excess, since it defaults to search tickets (all parts of
>> them, open and closed), changesets, and the wiki...
>
> I used the default search box in Trac a couple times when we first  
> switched to Trac, then never again, because it never gave me the  
> results I needed.
>
> Would like a search box added which does just a summary search on  
> tickets. Not sure where it should be placed but it's almost the only  
> search I do. Add a drop-down menu for whether you want to search for  
> new or open or closed tickets and you've taken care of a majority of  
> users' search needs I think. Like in the attached ticket_search.php.
>
>
> < 
> ticket_search 
> .php 
> ><search_redirect.php>_____________________________________________

I can add this to Trac along with some other plugins I have planned  
for MP...

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

-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/20080718/6d1d26a5/attachment.bin 

From ryandesign at macports.org  Sat Jul 19 16:03:24 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 19 Jul 2008 18:03:24 -0500
Subject: [38420] branches/gsoc08-mpwa
In-Reply-To: <20080719120833.3FE06163691@beta.macosforge.org>
References: <20080719120833.3FE06163691@beta.macosforge.org>
Message-ID: <058E6059-FF00-4E84-BF77-3EC6B4D2C670@macports.org>

On Jul 19, 2008, at 07:08, digx at macports.org wrote:

> Revision: 38420
>           http://trac.macosforge.org/projects/macports/changeset/38420
> Author:   digx at macports.org
> Date:     2008-07-19 05:08:25 -0700 (Sat, 19 Jul 2008)
> Log Message:
> -----------
> Updates, yo


What did you update and why? Please expand on your commit message by  
typing:


svn propedit --revprop -r 38420 svn:log \
http://svn.macosforge.org/repository/macports



From ryandesign at macports.org  Sat Jul 19 16:03:59 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 19 Jul 2008 18:03:59 -0500
Subject: [38422] trunk/dports/sysutils
In-Reply-To: <20080719201408.61A4316455B@beta.macosforge.org>
References: <20080719201408.61A4316455B@beta.macosforge.org>
Message-ID: <7EB6C36E-333E-4B21-A797-3A79D4CD399D@macports.org>

On Jul 19, 2008, at 15:14, ricci at macports.org wrote:

> Revision: 38422
>           http://trac.macosforge.org/projects/macports/changeset/38422
> Author:   ricci at macports.org
> Date:     2008-07-19 13:14:07 -0700 (Sat, 19 Jul 2008)
> Log Message:
> -----------
> New port dc3dd, an enhanced version of GNU dd

[snip]

> +configure.args      --prefix=${prefix} --mandir=${prefix}/share/man

You do not need "--prefix=${prefix}" in configure.args; MacPorts  
already puts this into configure.pre_args.



From captsolo at gmail.com  Sat Jul 19 17:51:49 2008
From: captsolo at gmail.com (Uldis Bojars)
Date: Sun, 20 Jul 2008 01:51:49 +0100
Subject: updates for redland-bindings
In-Reply-To: <64c81f720807131224i3e24345fie758d22c1eb68565@mail.gmail.com>
References: <64c81f720807131224i3e24345fie758d22c1eb68565@mail.gmail.com>
Message-ID: <64c81f720807191751g759d8279rdf8bbca5714f4743@mail.gmail.com>

Kindly asking if someone here could update redland-bindings port per
ticket http://trac.macports.org/ticket/15921.

My apologies for a repeated message, but the guide says this is the
place to ask about these things:

> If the maintainer does not respond within 72 hours, you or another committer
> may review the patches and update the port. If you are not a committer,
> you may email <macports-dev at lists.macosforge.org> and request
> the updates be committed.

Uldis

On Sun, Jul 13, 2008 at 8:24 PM, Uldis Bojars <captsolo at gmail.com> wrote:
> Hi,
>
> Could the admins please "bump" this port up to the most recent
> software version ( http://trac.macports.org/ticket/15921 ) and add
> "openmaintainer" or "nomaintainer" to the port (if appropriate)?
>
> The reason for asking this is because it looks like redland-bindings
> is currently not being maintained - there are 3 and 6 months old
> tickets [1,2] on redland-bindings port which have had no response from
> the maintainer.
>
> [1] http://trac.macports.org/ticket/13838
> [2] http://trac.macports.org/ticket/14956
>
> The old tickets themselves do not need more attention though because
> version 1.0.8.1 addresses the bug described in [1]. And [2] is an
> earlier request for version update.
>
> P.S. This port also has an activation bug in +python version (similar
> as some other SWIG-generated Python bindings) discussed on this list
> under the topic: Meaning of "Not a directory".
>
> CC: maintainer of redland-bindings
>
> Thanks,
> Uldis
>

From ryandesign at macports.org  Sat Jul 19 23:23:28 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 20 Jul 2008 01:23:28 -0500
Subject: [38358] branches/gsoc08-logging
In-Reply-To: <2586C1B3-2C47-405C-A49D-1066E2792BB6@macports.org>
References: <20080717064715.23E4C156BEC@beta.macosforge.org>
	<2586C1B3-2C47-405C-A49D-1066E2792BB6@macports.org>
Message-ID: <7661D3E7-6694-47E1-99C6-755A909DC1CD@macports.org>

On Jul 17, 2008, at 03:25, Ryan Schmidt wrote:

> On Jul 17, 2008, at 01:47, dpemmons at macports.org wrote:
>
>> server now dumps submitted lot file to mysql database. also created
>> userAdmin.pl tool for server users.
>
> You should fix the typo in your log message. :) Use this:
>
> svn propedit --revprop -r 38358 svn:log \
> http://svn.macosforge.org/repository/macports

I fixed the log message for you this time.

http://lists.macosforge.org/pipermail/macports-changes/2008-July/ 
019277.html

In the future please fix log messages yourself. Thanks.



From markd at macports.org  Sun Jul 20 07:34:46 2008
From: markd at macports.org (markd at macports.org)
Date: Sun, 20 Jul 2008 07:34:46 -0700
Subject: Chunked guide
Message-ID: <fc.004c4c580fdd69db004c4c580fdd69db.fdd6b59@biola.edu>

>Hi,
>
>I just committed a new target "guide-chunked" to the doc-new Makefile
>which
>generates a chunked version of the guide [1].
>
>I used a Tcl script to add the table of contents to each page. Please
>have a
>look at [2] and tell me what you think.
>
>If you like it we can activate the guide-chunked target on the
>documentation
>server and make it available to everybody.
>
>Thanks,
>Simon

Thanks for your work on this!  That is some nice scripting work.  I think
we should make the chunked guide available now that you've got the TOC
handled.  I think the real question now is whether to keep a "single html"
version around.  The only "problem" with the chunked version is you can't
do a browser search of the whole document, but I'm not sure how many
people want that.  I can live without it.  I'd like to hear comments from
others.

If a consensus is that keepind a "single html" version around is
desirable, I wouldn't want to make people select between two versions
before viewing, but provide a link to a "single html" version as an option
so the chunked version is the default viewing methood.

Mark


From markd at macports.org  Sun Jul 20 07:47:39 2008
From: markd at macports.org (markd at macports.org)
Date: Sun, 20 Jul 2008 07:47:39 -0700
Subject: To whom should error messages be written?
Message-ID: <fc.004c4c580fd7a905004c4c580fd7a905.fdd6c60@biola.edu>

>There are a number of error messages that MacPorts might print during
>the normal course of events. Checksum errors, fetch failures, port
>misbehaviors. Who should be the audience for these error messages --
>the end user or the portfile developer? I would argue the former but
>we currently have some messages that target the latter.

I agree they should be written to the end user.  Perhaps if more technical
stuff in a message, if any, could be included after a "DEBUG Info:" label?
 Not sure if this is a good idea; I'm just thinking out loud.
>
>Take, for example, destroot violations. If a port violates the mtree
>and does not indicate that it wants to do this via
>"destroot.violate_mtree yes", MacPorts prints:
>
>        Warning: violation by <path>
>        Warning: <port> violates the layout of the ports-filesystems!
>        Warning: Please fix or indicate this misbehavior (if it is
>intended), it will be an error in future releases!
>
>This message is clearly written to the portfile developer.
>
>If the port does indicate that it will install files outside of the
>mtree, MacPorts says:
>
>        Warning: <port> requests to install files outside the common
>directory structure!
>
>This message is presumably written to the end user so that they know
>files have been installed in a nonstandard location, though MacPorts
>does not tell the user where. I recall at least one bug report from a
>user who did not realize that this message did not constitute a bug
>but correct normal behavior. I guess the word "Warning" and the
>exclamation point make it sound like a bug that needs to be reported.
>
>The patch in #15514 [1] adds a new message the end user could see:
>
>        Warning: reinplace <regexp> didn't change anything in <file>
>
>This information is meant for the portfile developer. The developer
>should either fix the regexp (so that it replaces what it was
>designed to replace), or remove it (because the file no longer needs
>that replacement), or indicate via a new flag to the reinplace
>command that it's ok that no replacement occurred (for example see
>the mysql5 port which does a reinplace across a glob of files, not
>all of which contain the string to be replaced). The end user doesn't
>need to know all this, of course; the end user just needs to be told
>to file a ticket.

That new reinplace error message only shows up in debug output, correct? 
I wouldn't think a bug report is necessarily required for this error.  I
think of it more as informational.
>

Also, I favor changing the "target" terminology in error messages for the
same reason; I think that is ambiguos and a type of "developer-speak".  I
dropped that in favor of "phase" or "installation phase" in the new guide.
 I haven't submitted a patch to change the error message(s) yet so the
user doesn't need to figure out what a target is, but I will.

http://lists.macosforge.org/pipermail/macports-dev/2007-September/002872.html

>
>I think we should write error messages to the end user, not the
>portfile developer. I think we should also have a new page in the
>wiki called ErrorMessages, where we can list the error messages that
>MacPorts might print along with explanations of what the portfile
>author should do about them. We would describe mtree violations and
>ineffectual reinplaces and checksum failures (the checksum failure
>discussion would move to this new page from the FAQ).
>
>Or we could put all these in the FAQ page, maybe in a new section for
>error messages.

I think this might not be sustainable and might lead to always out-of-date
docs.  I wouldn't be in favor of this unless the error messages were
sourced out of the code itself, rather than written independently.

Mark


From jon.hermansen at gmail.com  Sun Jul 20 08:27:45 2008
From: jon.hermansen at gmail.com (Jon Hermansen)
Date: Sun, 20 Jul 2008 11:27:45 -0400
Subject: Chunked guide
In-Reply-To: <fc.004c4c580fdd69db004c4c580fdd69db.fdd6b59@biola.edu>
References: <fc.004c4c580fdd69db004c4c580fdd69db.fdd6b59@biola.edu>
Message-ID: <21b72fa30807200827n260e78f6we74c01355fb6d05a@mail.gmail.com>

I found that having the guide all on one page was VERY handy, I was skipping
all around it when I wrote my first port. Since package management isn't too
scary to me, and building from source isn't either, I essentially knew how
to build the package I was trying to write, but I didn't know how to
implement it in a Portfile. Getting help in IRC and cross-referencing
people's suggestions with information from the guide made things really
easy.

Anyways, just my two cents.

On Sun, Jul 20, 2008 at 10:34 AM, <markd at macports.org> wrote:

> >Hi,
> >
> >I just committed a new target "guide-chunked" to the doc-new Makefile
> >which
> >generates a chunked version of the guide [1].
> >
> >I used a Tcl script to add the table of contents to each page. Please
> >have a
> >look at [2] and tell me what you think.
> >
> >If you like it we can activate the guide-chunked target on the
> >documentation
> >server and make it available to everybody.
> >
> >Thanks,
> >Simon
>
> Thanks for your work on this!  That is some nice scripting work.  I think
> we should make the chunked guide available now that you've got the TOC
> handled.  I think the real question now is whether to keep a "single html"
> version around.  The only "problem" with the chunked version is you can't
> do a browser search of the whole document, but I'm not sure how many
> people want that.  I can live without it.  I'd like to hear comments from
> others.
>
> If a consensus is that keepind a "single html" version around is
> desirable, I wouldn't want to make people select between two versions
> before viewing, but provide a link to a "single html" version as an option
> so the chunked version is the default viewing methood.
>
> Mark
>
> _______________________________________________
> 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/20080720/d58bc072/attachment.html 

From raimue at macports.org  Sun Jul 20 09:15:35 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sun, 20 Jul 2008 18:15:35 +0200
Subject: Chunked guide
In-Reply-To: <c24012060807170205j1c825e1aj6663d29505bd91ef@mail.gmail.com>
References: <20080716131359.GA29468@ruderich.com>
	<c24012060807170205j1c825e1aj6663d29505bd91ef@mail.gmail.com>
Message-ID: <488364A7.6080906@macports.org>

Randall Wood wrote:
> I like it. Is it possible to chunk the guide at x.y sections instead
> of chapters?

Yes, just set chunk.section.depth to something greater than 0.

I splitted the string params from the Makefile to new .xsl files in 
guide/resources, the settings can be tweaked there.

Mark, Simon:
If you don't like this change, feel free to revert my commit in r38441. 
But I find it better to edit a configuration file than editing the 
Makefile just to change some settings.

> Some notes:
> 
> Indexers such a google do not seem to respect links to individual
> headers, but instead always return the user to the top of the page, so
> the smaller the chunk, the better the user experience when coming from
> a search.

I also added use.id.as.filename which names the pages by their id 
instead of numbers.

> Even though it did not need them, the scroll bars were kept in the
> navigation bar. Empty scroll bars don't look good in Safari IMHO.

Maybe something in the CSS, haven't looked deeper on this.

> Can each page get a further table of contents of its headers down to
> the x.y.z level?

I think this one would require additional XSLT code. But if someone is 
able to do it, it can easily be added to chunk.xsl now. Personally my 
XSLT experience is very limited.

Rainer

From opendarwin.org at darkart.com  Sun Jul 20 10:55:36 2008
From: opendarwin.org at darkart.com (Eric Hall)
Date: Sun, 20 Jul 2008 17:55:36 +0000
Subject: [38422] trunk/dports/sysutils
In-Reply-To: <7EB6C36E-333E-4B21-A797-3A79D4CD399D@macports.org>
References: <20080719201408.61A4316455B@beta.macosforge.org>
	<7EB6C36E-333E-4B21-A797-3A79D4CD399D@macports.org>
Message-ID: <20080720175536.GQ1162@darkart.com>

On Sat, Jul 19, 2008 at 06:03:59PM -0500, Ryan Schmidt wrote:
> On Jul 19, 2008, at 15:14, ricci at macports.org wrote:
> 
> >Revision: 38422
> >          http://trac.macosforge.org/projects/macports/changeset/38422
> >Author:   ricci at macports.org
> >Date:     2008-07-19 13:14:07 -0700 (Sat, 19 Jul 2008)
> >Log Message:
> >-----------
> >New port dc3dd, an enhanced version of GNU dd
> 
> [snip]
> 
> >+configure.args      --prefix=${prefix} --mandir=${prefix}/share/man
> 
> You do not need "--prefix=${prefix}" in configure.args; MacPorts  
> already puts this into configure.pre_args.
> 
> 

	Indeed, not sure why that was in the Portfile I copied from,
I suspect that's been dragged forward from a *long* time back.
	Cleaned up in r38427.


		-eric



From andrea.damore at macports.org  Sun Jul 20 11:18:03 2008
From: andrea.damore at macports.org (Andrea D'Amore)
Date: Sun, 20 Jul 2008 20:18:03 +0200
Subject: Problem buildings octave related packages 
Message-ID: <8C9D6D30-B339-45C7-A396-48585E64299C@macports.org>

Hello,
I've been very little active lately, still I have this two bugs  
assigned about problem with octave-ann and octave-image that I'm not  
able to manage, actually I'm not that confident with compiling stuffs  
to help much about it, so if anyone has some spare time and willing to  
help check tickets no. 15428 and 15716.


Thanks.


Andrea

From armahg at gmail.com  Sun Jul 20 15:38:25 2008
From: armahg at gmail.com (George Armah)
Date: Sun, 20 Jul 2008 18:38:25 -0400
Subject: NonTcl Portfiles
Message-ID: <c8747a350807201538y6de9b437w9e99d9e8f65a2cca@mail.gmail.com>

(First two attempts at sending this email failed. Hope this one works)

Hello,

I was reading through the Portfile Development section of MacPorts Guide
and an idea occurred to me.
It has been mentioned before that having Tcl as MacPorts' base language
does shy away some potential developers and port contributers / maintainers.

The Basic Portfile example (or some variant of it) looks like something
that could easily be typed in a plain old text file. Would it be possible to
create a Tcl
tool that parses Portfiles that are in for example .txt file formats? The
exact format of the text in
the file would probably be different from the current Tcl portfiles (and
hopefully simpler as a
result).
That way potential port maintainers who don't know any Tcl won't shy
away from contributing and maintaining ports.

I myself don't know too much Tcl (but am willing to learn) and currently
have my hands full with GSoC. I'll however be willing to work on such a
project after
summer is over if I have some help getting started.


Let me know if this idea sounds feasible or if there is already such a
tool out there which I didn't know about,

Thanks,

George.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080720/164daed0/attachment-0001.html 

From jkh at apple.com  Sun Jul 20 16:00:41 2008
From: jkh at apple.com (Jordan K. Hubbard)
Date: Sun, 20 Jul 2008 16:00:41 -0700
Subject: NonTcl Portfiles
In-Reply-To: <c8747a350807201538y6de9b437w9e99d9e8f65a2cca@mail.gmail.com>
References: <c8747a350807201538y6de9b437w9e99d9e8f65a2cca@mail.gmail.com>
Message-ID: <749D0E7D-1D99-4E5C-8ECB-7C231ED0BC5B@apple.com>

Now you're just talking crazy talk, George! :-)

Seriously, we we have looked at this a few times in the past (in  
response to the "everyone hates Tcl" as well as other concerns) and  
debate generally seems to polarize around two positions:

A)  Tcl, with its simplistic and context-sensitive syntax, is already  
far more of a textual format than a structured language.  Just make  
the various verbs and nouns in the macports infrastructure a bit more  
descriptive, clean things up here and there, done:  A description  
format that's 90% "option value" and 10% high level functions that  
could read more like english if that was really the goal (Note:  I  
just made those numbers up - it could be substantially more options  
and less functions with certain design decisions).  No need to create  
yet another "user friendly" description format.

B) Tcl is totally NOT machine readable by anything but a Tcl  
interpreter, something which makes data harvesting and/or mass-changes  
across the ports collection really really painful.  It is time for  
Portfiles to be written in XML with a proper DTD!  We can use  
translators to get to and from a human readable format when and if  
editing is actually required, so don't be such a bunch of sissies,  
running away every time the letters X, M and L are mentioned together!

Since no battle like that can ever truly have a clear winner (they're  
both "right" for some value of "right"), we generally decide in the  
end to just leave things alone, which is probably the right decision  
for this iteration of MacPorts.   If we ever do see such a sweeping  
change of the collection, I think it will be because someone decides,  
one day, to write MacPorts "3.0 or later" completely from scratch.    
New Portfile syntax, new infrastructure to go with it, and probably  
some monster Perl script (in Perl6, of course) which manages to  
convert some significant percentage of the old ports into the new  
format.

- Jordan


On Jul 20, 2008, at 3:38 PM, George Armah wrote:

> (First two attempts at sending this email failed. Hope this one works)
>
> Hello,
>
> I was reading through the Portfile Development section of MacPorts  
> Guide
> and an idea occurred to me.
> It has been mentioned before that having Tcl as MacPorts' base  
> language
> does shy away some potential developers and port contributers /  
> maintainers.
>
> The Basic Portfile example (or some variant of it) looks like  
> something
> that could easily be typed in a plain old text file. Would it be  
> possible to create a Tcl
> tool that parses Portfiles that are in for example .txt file  
> formats? The exact format of the text in
> the file would probably be different from the current Tcl portfiles  
> (and hopefully simpler as a
> result).
> That way potential port maintainers who don't know any Tcl won't shy
> away from contributing and maintaining ports.
>
> I myself don't know too much Tcl (but am willing to learn) and  
> currently
> have my hands full with GSoC. I'll however be willing to work on  
> such a project after
> summer is over if I have some help getting started.
>
>
> Let me know if this idea sounds feasible or if there is already such a
> tool out there which I didn't know about,
>
> Thanks,
>
> George.
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


From ryandesign at macports.org  Sun Jul 20 19:10:58 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 20 Jul 2008 21:10:58 -0500
Subject: NonTcl Portfiles
In-Reply-To: <c8747a350807201538y6de9b437w9e99d9e8f65a2cca@mail.gmail.com>
References: <c8747a350807201538y6de9b437w9e99d9e8f65a2cca@mail.gmail.com>
Message-ID: <F5817A1F-6D0E-4590-B53F-D3096C7F9096@macports.org>

On Jul 20, 2008, at 17:38, George Armah wrote:

> I was reading through the Portfile Development section of MacPorts  
> Guide
> and an idea occurred to me.
> It has been mentioned before that having Tcl as MacPorts' base  
> language
> does shy away some potential developers and port contributers /  
> maintainers.
>
> The Basic Portfile example (or some variant of it) looks like  
> something
> that could easily be typed in a plain old text file. Would it be  
> possible to create a Tcl
> tool that parses Portfiles that are in for example .txt file  
> formats? The exact format of the text in
> the file would probably be different from the current Tcl portfiles  
> (and hopefully simpler as a
> result).
> That way potential port maintainers who don't know any Tcl won't shy
> away from contributing and maintaining ports.
>
> I myself don't know too much Tcl (but am willing to learn) and  
> currently
> have my hands full with GSoC. I'll however be willing to work on  
> such a project after
> summer is over if I have some help getting started.

I don't think we're going to change this anytime soon, like jkh said.

Instead, the Guide exists to teach you all you need to know to write  
Portfiles. If the Guide is inadequate in that regard, then it's the  
Guide that should be improved, rather than rewriting virtually all of  
MacPorts.



From armahg at gmail.com  Mon Jul 21 05:26:22 2008
From: armahg at gmail.com (George Armah)
Date: Mon, 21 Jul 2008 08:26:22 -0400
Subject: NonTcl Portfiles
In-Reply-To: <749D0E7D-1D99-4E5C-8ECB-7C231ED0BC5B@apple.com>
References: <c8747a350807201538y6de9b437w9e99d9e8f65a2cca@mail.gmail.com>
	<749D0E7D-1D99-4E5C-8ECB-7C231ED0BC5B@apple.com>
Message-ID: <c8747a350807210526o7d1d80b2k1c67f291990b2f20@mail.gmail.com>

On Sun, Jul 20, 2008 at 7:00 PM, Jordan K. Hubbard <jkh at apple.com> wrote:

> Now you're just talking crazy talk, George! :-)
>
> Seriously, we we have looked at this a few times in the past (in response
> to the "everyone hates Tcl" as well as other concerns) and debate generally
> seems to polarize around two positions:
>
> A)  Tcl, with its simplistic and context-sensitive syntax, is already far
> more of a textual format than a structured language.  Just make the various
> verbs and nouns in the macports infrastructure a bit more descriptive, clean
> things up here and there, done:  A description format that's 90% "option
> value" and 10% high level functions that could read more like english if
> that was really the goal (Note:  I just made those numbers up - it could be
> substantially more options and less functions with certain design
> decisions).  No need to create yet another "user friendly" description
> format.


I did notice that whilst reading the guide. The portfile itself IS very self
descriptive. In fact i'm a sure some of the Tcl apprehension stems more
from the fact that newcomers will be encountering the language for the first
time, rather than from any actual "difficulty" in the portifile creation.



>
>
> B) Tcl is totally NOT machine readable by anything but a Tcl interpreter,
> something which makes data harvesting and/or mass-changes across the ports
> collection really really painful.  It is time for Portfiles to be written in
> XML with a proper DTD!  We can use translators to get to and from a human
> readable format when and if editing is actually required, so don't be such a
> bunch of sissies, running away every time the letters X, M and L are
> mentioned together!
>
> Since no battle like that can ever truly have a clear winner (they're both
> "right" for some value of "right"), we generally decide in the end to just
> leave things alone, which is probably the right decision for this iteration
> of MacPorts.   If we ever do see such a sweeping change of the collection, I
> think it will be because someone decides, one day, to write MacPorts "3.0 or
> later" completely from scratch.   New Portfile syntax, new infrastructure to
> go with it, and probably some monster Perl script (in Perl6, of course)
> which manages to convert some significant percentage of the old ports into
> the new format.



So basically it would be a hefty change requiring lots of time and
resources. I get that. The driving factor behind my suggestion however was
getting more people to contribute to the project. From your comments,
allowing more than one file format  does not seem like a good
idea.

I just started reading more on MacPorts Web Application. Its goals are
exactly what I had in mind when made this suggestion :).
I guess this thread can end  and hopefully we'll have  something up and
running after SoC.

Thanks for enlightening me on the Tcl argument though,



>
>
> - Jordan
>
>
>
> On Jul 20, 2008, at 3:38 PM, George Armah wrote:
>
>  (First two attempts at sending this email failed. Hope this one works)
>>
>> Hello,
>>
>> I was reading through the Portfile Development section of MacPorts Guide
>> and an idea occurred to me.
>> It has been mentioned before that having Tcl as MacPorts' base language
>> does shy away some potential developers and port contributers /
>> maintainers.
>>
>> The Basic Portfile example (or some variant of it) looks like something
>> that could easily be typed in a plain old text file. Would it be possible
>> to create a Tcl
>> tool that parses Portfiles that are in for example .txt file formats? The
>> exact format of the text in
>> the file would probably be different from the current Tcl portfiles (and
>> hopefully simpler as a
>> result).
>> That way potential port maintainers who don't know any Tcl won't shy
>> away from contributing and maintaining ports.
>>
>> I myself don't know too much Tcl (but am willing to learn) and currently
>> have my hands full with GSoC. I'll however be willing to work on such a
>> project after
>> summer is over if I have some help getting started.
>>
>>
>> Let me know if this idea sounds feasible or if there is already such a
>> tool out there which I didn't know about,
>>
>> Thanks,
>>
>> George.
>>
>> _______________________________________________
>> 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/20080721/afb65923/attachment.html 

From armahg at gmail.com  Sun Jul 20 05:37:35 2008
From: armahg at gmail.com (George Armah)
Date: Sun, 20 Jul 2008 08:37:35 -0400
Subject: Non-Tcl Portfiles
Message-ID: <4883318F.2070507@gmail.com>

Hello,

I was reading through the Portfile Development section of MacPorts Guide 
and an idea occurred to me.
It has been mentioned before that having Tcl as MacPorts' base language 
does shy away some
potential developers and port contributers / maintainers.

The Basic Portfile example (or some variant of it) looks like something 
that could easily be
typed in a plain old text file. Would it be possible to create a Tcl 
tool that parses Portfiles that
are in for example .txt file formats? The exact format of the text in 
the file would probably be
different from the current Tcl portfiles (and hopefully simpler as a 
result).
That way potential port maintainers who don't know any Tcl won't shy 
away from contributing and maintaining ports.

I myself don't know too much Tcl (but am willing to learn) and currently 
have my hands
full with GSoC. I'll however be willing to work on such a project after 
summer is over
if I have some help getting started.


Let me know if this idea sounds feasible or if there is already such a 
tool out there
which I didn't know about,

Thanks,

George.


From armahg at gmail.com  Sun Jul 20 16:27:24 2008
From: armahg at gmail.com (George Armah)
Date: Sun, 20 Jul 2008 19:27:24 -0400
Subject: NonTcl Portfiles
In-Reply-To: <749D0E7D-1D99-4E5C-8ECB-7C231ED0BC5B@apple.com>
References: <c8747a350807201538y6de9b437w9e99d9e8f65a2cca@mail.gmail.com>
	<749D0E7D-1D99-4E5C-8ECB-7C231ED0BC5B@apple.com>
Message-ID: <4883C9DC.7090207@gmail.com>

Jordan K. Hubbard wrote:
> Now you're just talking crazy talk, George! :-)
>
> Seriously, we we have looked at this a few times in the past (in 
> response to the "everyone hates Tcl" as well as other concerns) and 
> debate generally seems to polarize around two positions:
>
> A)  Tcl, with its simplistic and context-sensitive syntax, is already 
> far more of a textual format than a structured language.  Just make 
> the various verbs and nouns in the macports infrastructure a bit more 
> descriptive, clean things up here and there, done:  A description 
> format that's 90% "option value" and 10% high level functions that 
> could read more like english if that was really the goal (Note:  I 
> just made those numbers up - it could be substantially more options 
> and less functions with certain design decisions).  No need to create 
> yet another "user friendly" description format.
I did notice that whilst reading the guide. The portfile itself IS very 
self descriptive. In fact i'm a sure some of the Tcl apprehension stems more
from the fact that newcomers will be encountering the language for the 
first time, rather than from any actual "difficulty" in the portifile 
creation.


>
> B) Tcl is totally NOT machine readable by anything but a Tcl 
> interpreter, something which makes data harvesting and/or mass-changes 
> across the ports collection really really painful.  It is time for 
> Portfiles to be written in XML with a proper DTD!  We can use 
> translators to get to and from a human readable format when and if 
> editing is actually required, so don't be such a bunch of sissies, 
> running away every time the letters X, M and L are mentioned together!
> Since no battle like that can ever truly have a clear winner (they're 
> both "right" for some value of "right"), we generally decide in the 
> end to just leave things alone, which is probably the right decision 
> for this iteration of MacPorts.   If we ever do see such a sweeping 
> change of the collection, I think it will be because someone decides, 
> one day, to write MacPorts "3.0 or later" completely from scratch.   
> New Portfile syntax, new infrastructure to go with it, and probably 
> some monster Perl script (in Perl6, of course) which manages to 
> convert some significant percentage of the old ports into the new format.

So basically it would be a hefty change requiring lots of time and 
resources. I get that. The driving factor behind my suggestion however was
getting more people to contribute to the project. From your comments, 
allowing more than one file format  does not seem like a good
idea.

I just started reading more on MacPorts Web Application. Its goals are 
exactly what I had in mind when made this suggestion :).
I guess this thread can end  and hopefully we'll have  something up and 
running after SoC.

Thanks for enlightening me on the Tcl argument though,

George.

>
>
> - Jordan
>
>
> On Jul 20, 2008, at 3:38 PM, George Armah wrote:
>
>> (First two attempts at sending this email failed. Hope this one works)
>>
>> Hello,
>>
>> I was reading through the Portfile Development section of MacPorts Guide
>> and an idea occurred to me.
>> It has been mentioned before that having Tcl as MacPorts' base language
>> does shy away some potential developers and port contributers / 
>> maintainers.
>>
>> The Basic Portfile example (or some variant of it) looks like something
>> that could easily be typed in a plain old text file. Would it be 
>> possible to create a Tcl
>> tool that parses Portfiles that are in for example .txt file formats? 
>> The exact format of the text in
>> the file would probably be different from the current Tcl portfiles 
>> (and hopefully simpler as a
>> result).
>> That way potential port maintainers who don't know any Tcl won't shy
>> away from contributing and maintaining ports.
>>
>> I myself don't know too much Tcl (but am willing to learn) and currently
>> have my hands full with GSoC. I'll however be willing to work on such 
>> a project after
>> summer is over if I have some help getting started.
>>
>>
>> Let me know if this idea sounds feasible or if there is already such a
>> tool out there which I didn't know about,
>>
>> Thanks,
>>
>> George.
>>
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>
>


From armahg at gmail.com  Sun Jul 20 09:19:18 2008
From: armahg at gmail.com (George Armah)
Date: Sun, 20 Jul 2008 12:19:18 -0400
Subject: NonTcl Portfiles
Message-ID: <48836586.1030304@gmail.com>

(First attempt to send this email failed. Hope this one works)

Hello,

I was reading through the Portfile Development section of MacPorts Guide
and an idea occurred to me.
It has been mentioned before that having Tcl as MacPorts' base language
does shy away some
potential developers and port contributers / maintainers.

The Basic Portfile example (or some variant of it) looks like something
that could easily be
typed in a plain old text file. Would it be possible to create a Tcl
tool that parses Portfiles that
are in for example .txt file formats? The exact format of the text in
the file would probably be
different from the current Tcl portfiles (and hopefully simpler as a
result).
That way potential port maintainers who don't know any Tcl won't shy
away from contributing and maintaining ports.

I myself don't know too much Tcl (but am willing to learn) and currently
have my hands
full with GSoC. I'll however be willing to work on such a project after
summer is over
if I have some help getting started.


Let me know if this idea sounds feasible or if there is already such a
tool out there
which I didn't know about,

Thanks,

George.



From wsiegrist at apple.com  Mon Jul 21 12:56:45 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Mon, 21 Jul 2008 12:56:45 -0700
Subject: Adding distfiles to the repository
In-Reply-To: <0FD9803A-2D93-4B09-94C0-70F4DCBF6747@apple.com>
References: <487F79F8.8060300@orcaware.com>
	<25CDFE40-DB83-4750-B90E-3735B32A6E3D@macports.org>
	<487FB718.9000109@orcaware.com>
	<14567128-9862-47FD-93CA-A3B1AA934258@macports.org>
	<882898A8-F1EC-41A7-9B7F-0BC0E1F1A482@apple.com>
	<487FC125.5060507@orcaware.com>
	<2CF75407-3A06-44B1-A943-8B1BDAD6FE2A@macports.org>
	<9C706806-4C8A-4DF8-BADC-85CF8DCBA634@apple.com>
	<487FD0E8.5090308@orcaware.com>
	<0FD9803A-2D93-4B09-94C0-70F4DCBF6747@apple.com>
Message-ID: <0F92D27C-143A-40E0-9B2F-E3ACA88DA041@apple.com>


On Jul 18, 2008, at 10:45 AM, William Siegrist wrote:

> On Jul 17, 2008, at 4:08 PM, Blair Zajac wrote:
>
>> William Siegrist wrote:
>>> On Jul 17, 2008, at 3:09 PM, Ryan Schmidt wrote:
>>>>
>>>> On Jul 17, 2008, at 17:01, Blair Zajac wrote:
>>>>
>>>>> William Siegrist wrote:
>>>>>>
>>>>>
>>>>>> please allow at least 24hr after a portfile is updated
>>>>>> before complaining though, as the mirror is only updated daily.
>>>>>
>>>>> Thanks for this info.  Can we up the cron from 24 to something  
>>>>> on a shorter basis?
>>>>
>>>> This may be relevant for the php5-devel port as well. It's  
>>>> currently tracking php 5.2 release candidates but I now have a  
>>>> request from a user who wants to try a feature only available in  
>>>> php 5.3. The php team provides snapshot tarballs of php 5.3, but  
>>>> they're generated every two hours, and disappear after ten hours.  
>>>> So I would have to make sure to time my commit such that it's  
>>>> less than ten hours until the portmirror process runs on the  
>>>> distfiles mirror machine. Which I could do. But it would be  
>>>> convenient if I wouldn't have to remember to do that. Who knows  
>>>> what time of day I might feel like working on my ports.
>>>>
>>> The current process takes 6-8 hours to run and eats a decent  
>>> amount of cpu cycles because it tries to mirror every variant of  
>>> every port, so doing it more often wont work well on the server.  
>>> Like I've said before, this allows for daily re-trying if the  
>>> mirroring fails the first day.  What I could do is add a mirror  
>>> attempt during post-commit as well. So every port gets mirrored  
>>> upon commit and then once a day after that. When you commit, if  
>>> your distfile is unavailable, it'll get retried the next morning  
>>> during the daily job.  I think this is reasonable and covers  
>>> everyone's needs.
>>
>> That sounds good.
>>
>
> I have a slightly-tested job in place for post-commit mirroring. It  
> will send email to maintainers if mirroring fails, much like how  
> lint nags you.


The post-commit mirroring seems to be working and no one has  
complained about emails nagging them with errors.

Ryan, let me know if you still have trouble with php5-devel.

-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/20080721/ed01ca82/attachment.bin 

From macsforever2000 at macports.org  Mon Jul 21 16:25:24 2008
From: macsforever2000 at macports.org (Frank Schima)
Date: Mon, 21 Jul 2008 17:25:24 -0600
Subject: py25-gtk dependency oddity?
In-Reply-To: <534FD25B-4CF6-42D4-9198-75FE39CEA765@mac.com>
References: <534FD25B-4CF6-42D4-9198-75FE39CEA765@mac.com>
Message-ID: <DD6766C8-EA88-40FD-A8C2-9D8C464C4A44@macports.org>

Hi Doug,


On Jul 5, 2008, at 12:14 PM, Douglas Philips wrote:

> I'm running Leopard (10.5.3) on a 2.4Ghz dual core.
> When I went to install py25-gtk, I got this message:
> Error: Some libs are missing from your X11 installation. Please run
> this command:
> Error: sudo ln -s libXrandr.2.dylib /usr/X11/lib/libXrandr.2.0.0.dylib
> Error: Target org.macports.fetch returned: missing /usr/X11/lib/
> libXrandr.2.0.0.dylib
> When I looked in /usr/X11/lib/ I found a libXrandr.2.1.0.dylib
> symlinked to the libXrandr.2.dylib and am wondering if the version
> check py25-gtk is doing is out of date?
> I went ahead and made the symbolic link it asked for and it is in the
> middle of a build now.
> Just wanted to ask if this was expected/desired behaviour, or if the
> port is slightly out of date? (nomaintainer at macports.org and
> all... :) ).

I didn't see that issue and I have it installed too (Mac Pro with  
10.5.4). This sounds like an issue with your X11 install. I run the  
latest version of XQuartz:
<http://xquartz.macosforge.org/trac/wiki>.

I recommend installing this over (or in place of) Apple's version from  
Leopard.

The py25-gtk port is up to date.


Cheers!
Frank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080721/c25fab97/attachment.html 

From erickt at macports.org  Mon Jul 21 18:27:17 2008
From: erickt at macports.org (Erick Tryzelaar)
Date: Mon, 21 Jul 2008 18:27:17 -0700
Subject: removing parallel building for "make install"?
Message-ID: <1ef034530807211827x6709196an6f5970ce97a2d1ff@mail.gmail.com>

I've run into a couple packages, llvm and qt4-mac, that can build
parallelized, but can't install like that. Is there any way to turn
off the parallel build when destrooting?

From jmr at macports.org  Mon Jul 21 18:32:32 2008
From: jmr at macports.org (Joshua Root)
Date: Tue, 22 Jul 2008 11:32:32 +1000
Subject: removing parallel building for "make install"?
In-Reply-To: <1ef034530807211827x6709196an6f5970ce97a2d1ff@mail.gmail.com>
References: <1ef034530807211827x6709196an6f5970ce97a2d1ff@mail.gmail.com>
Message-ID: <488538B0.9090700@macports.org>

Erick Tryzelaar wrote:
> I've run into a couple packages, llvm and qt4-mac, that can build
> parallelized, but can't install like that. Is there any way to turn
> off the parallel build when destrooting?

That's the way it's done in trunk, but in 1.6.0 I think you're out of 
luck. Some ports manage to work around the problem by creating certain 
directories in pre-destroot.

- Josh

From ryandesign at macports.org  Mon Jul 21 20:33:37 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 21 Jul 2008 22:33:37 -0500
Subject: Adding distfiles to the repository
In-Reply-To: <0F92D27C-143A-40E0-9B2F-E3ACA88DA041@apple.com>
References: <487F79F8.8060300@orcaware.com>
	<25CDFE40-DB83-4750-B90E-3735B32A6E3D@macports.org>
	<487FB718.9000109@orcaware.com>
	<14567128-9862-47FD-93CA-A3B1AA934258@macports.org>
	<882898A8-F1EC-41A7-9B7F-0BC0E1F1A482@apple.com>
	<487FC125.5060507@orcaware.com>
	<2CF75407-3A06-44B1-A943-8B1BDAD6FE2A@macports.org>
	<9C706806-4C8A-4DF8-BADC-85CF8DCBA634@apple.com>
	<487FD0E8.5090308@orcaware.com>
	<0FD9803A-2D93-4B09-94C0-70F4DCBF6747@apple.com>
	<0F92D27C-143A-40E0-9B2F-E3ACA88DA041@apple.com>
Message-ID: <1A7AD9FC-612B-46EA-8998-64A26C6DD1A3@macports.org>

On Jul 21, 2008, at 14:56, William Siegrist wrote:

> On Jul 18, 2008, at 10:45 AM, William Siegrist wrote:
>
>> On Jul 17, 2008, at 4:08 PM, Blair Zajac wrote:
>>
>>> William Siegrist wrote:
>>>
>>>> On Jul 17, 2008, at 3:09 PM, Ryan Schmidt wrote:
>>>>
>>>>> On Jul 17, 2008, at 17:01, Blair Zajac wrote:
>>>>>
>>>>>> William Siegrist wrote:
>>>>>>
>>>>>>> please allow at least 24hr after a portfile is updated
>>>>>>> before complaining though, as the mirror is only updated daily.
>>>>>>
>>>>>> Thanks for this info.  Can we up the cron from 24 to something  
>>>>>> on a shorter basis?
>>>>>
>>>>> This may be relevant for the php5-devel port as well. It's  
>>>>> currently tracking php 5.2 release candidates but I now have a  
>>>>> request from a user who wants to try a feature only available  
>>>>> in php 5.3. The php team provides snapshot tarballs of php 5.3,  
>>>>> but they're generated every two hours, and disappear after ten  
>>>>> hours. So I would have to make sure to time my commit such that  
>>>>> it's less than ten hours until the portmirror process runs on  
>>>>> the distfiles mirror machine. Which I could do. But it would be  
>>>>> convenient if I wouldn't have to remember to do that. Who knows  
>>>>> what time of day I might feel like working on my ports.
>>>>
>>>> The current process takes 6-8 hours to run and eats a decent  
>>>> amount of cpu cycles because it tries to mirror every variant of  
>>>> every port, so doing it more often wont work well on the server.  
>>>> Like I've said before, this allows for daily re-trying if the  
>>>> mirroring fails the first day.  What I could do is add a mirror  
>>>> attempt during post-commit as well. So every port gets mirrored  
>>>> upon commit and then once a day after that. When you commit, if  
>>>> your distfile is unavailable, it'll get retried the next morning  
>>>> during the daily job.  I think this is reasonable and covers  
>>>> everyone's needs.
>>>
>>> That sounds good.
>>
>> I have a slightly-tested job in place for post-commit mirroring.  
>> It will send email to maintainers if mirroring fails, much like  
>> how lint nags you.
>
> The post-commit mirroring seems to be working and no one has  
> complained about emails nagging them with errors.
>
> Ryan, let me know if you still have trouble with php5-devel.

I noticed the distfiles being mirrored very quickly when updating the  
wine and glib2 ports so I expect php5 will be fine too.


From ryandesign at macports.org  Tue Jul 22 00:19:25 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 22 Jul 2008 02:19:25 -0500
Subject: Chunked guide
In-Reply-To: <fc.004c4c580fdd69db004c4c580fdd69db.fdd6b59@biola.edu>
References: <fc.004c4c580fdd69db004c4c580fdd69db.fdd6b59@biola.edu>
Message-ID: <0F0AD412-083B-41AE-8EF5-F2889A691DB3@macports.org>


On Jul 20, 2008, at 09:34, markd at macports.org wrote:

> The only "problem" with the chunked version is you can't
> do a browser search of the whole document, but I'm not sure how many
> people want that.

I was initially going to suggest making a chunked guide because it's  
what I'm used to from other projects like php and mysql. But since  
then I've found it convenient to have it all on one page. I do use  
the browser search feature to quickly determine whether or not the  
guide mentions a particular topic at all before filing an enhancement  
request.

I can learn to live with a Google search instead. If we make the  
chunked guide the default, we should provide a Google search box  
which searches just guide.macports.org.


From ryandesign at macports.org  Tue Jul 22 00:35:59 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 22 Jul 2008 02:35:59 -0500
Subject: To whom should error messages be written?
In-Reply-To: <fc.004c4c580fd7a905004c4c580fd7a905.fdd6c60@biola.edu>
References: <fc.004c4c580fd7a905004c4c580fd7a905.fdd6c60@biola.edu>
Message-ID: <2F9448ED-0C00-41B7-9993-9B37945BC93E@macports.org>

On Jul 20, 2008, at 09:47, markd at macports.org wrote:

>> There are a number of error messages that MacPorts might print during
>> the normal course of events. Checksum errors, fetch failures, port
>> misbehaviors. Who should be the audience for these error messages --
>> the end user or the portfile developer? I would argue the former but
>> we currently have some messages that target the latter.
>
> I agree they should be written to the end user.  Perhaps if more  
> technical
> stuff in a message, if any, could be included after a "DEBUG Info:"  
> label?
>  Not sure if this is a good idea; I'm just thinking out loud.

Currently, debug output is prefixed with the DEBUG: label but only in  
debug mode. I think it would be confusing to now introduce new  
information which comes with a DEBUG: prefix which is not controlled  
by debug mode.


>> Take, for example, destroot violations. If a port violates the mtree
>> and does not indicate that it wants to do this via
>> "destroot.violate_mtree yes", MacPorts prints:
>>
>>        Warning: violation by <path>
>>        Warning: <port> violates the layout of the ports-filesystems!
>>        Warning: Please fix or indicate this misbehavior (if it is
>> intended), it will be an error in future releases!
>>
>> This message is clearly written to the portfile developer.
>>
>> If the port does indicate that it will install files outside of the
>> mtree, MacPorts says:
>>
>>        Warning: <port> requests to install files outside the common
>> directory structure!
>>
>> This message is presumably written to the end user so that they know
>> files have been installed in a nonstandard location, though MacPorts
>> does not tell the user where. I recall at least one bug report from a
>> user who did not realize that this message did not constitute a bug
>> but correct normal behavior. I guess the word "Warning" and the
>> exclamation point make it sound like a bug that needs to be reported.
>>
>> The patch in #15514 [1] adds a new message the end user could see:
>>
>>        Warning: reinplace <regexp> didn't change anything in <file>
>>
>> This information is meant for the portfile developer. The developer
>> should either fix the regexp (so that it replaces what it was
>> designed to replace), or remove it (because the file no longer needs
>> that replacement), or indicate via a new flag to the reinplace
>> command that it's ok that no replacement occurred (for example see
>> the mysql5 port which does a reinplace across a glob of files, not
>> all of which contain the string to be replaced). The end user doesn't
>> need to know all this, of course; the end user just needs to be told
>> to file a ticket.
>
> That new reinplace error message only shows up in debug output,  
> correct?

No, it occurs in normal output, just like the mtree warning.

The portfile developer can add a flag to the reinplace invocation to  
suppress the message, if indeed it is intentional that the reinplace  
not modify anything. This should be very rare.

I added a note to the ticket about possibly printing the warning in  
debug mode only in the case that the developer requested reinplace to  
be silent, just so there's some record of the situation.

> I wouldn't think a bug report is necessarily required for this  
> error.  I
> think of it more as informational.

It is my intention that any occurrence of this message in normal (non- 
debug) output is an error that needs to be fixed in the port in some  
way or another. Either the reinplace needs to be fixed so the file  
gets changed, or the reinplace needs to be removed if it is no longer  
needed, or a flag needs to be added to the reinplace invocation to  
indicate that it is ok that nothing got replaced.


> Also, I favor changing the "target" terminology in error messages  
> for the
> same reason; I think that is ambiguos and a type of "developer- 
> speak".  I
> dropped that in favor of "phase" or "installation phase" in the new  
> guide.
>  I haven't submitted a patch to change the error message(s) yet so the
> user doesn't need to figure out what a target is, but I will.
>
> http://lists.macosforge.org/pipermail/macports-dev/2007-September/ 
> 002872.html

I agree "phase" is clearer than "target". Especially since portfile  
syntax also includes the notion of a "target" (in the likes of  
build.target) which is an unrelated concept.


>> I think we should write error messages to the end user, not the
>> portfile developer. I think we should also have a new page in the
>> wiki called ErrorMessages, where we can list the error messages that
>> MacPorts might print along with explanations of what the portfile
>> author should do about them. We would describe mtree violations and
>> ineffectual reinplaces and checksum failures (the checksum failure
>> discussion would move to this new page from the FAQ).
>>
>> Or we could put all these in the FAQ page, maybe in a new section for
>> error messages.
>
> I think this might not be sustainable and might lead to always out- 
> of-date
> docs.  I wouldn't be in favor of this unless the error messages were
> sourced out of the code itself, rather than written independently.

Can you suggest an alternative?

There is a vast amount of information, for example, that we want to  
impart to people who encounter a checksum error. The port command  
does not provide any of it. Instead the user must read the FAQ to  
figure out which of several reasons for the checksum error exist and  
how to resolve it. And we have some information which is for MacPorts  
users and other information which is for port maintainers.

Not all errors need that much explanation, but I'm sure at least a  
paragraph could be written about each. Would you rather the port  
command print all of that out? And what if the instructions are  
inaccurate or unclear? Then we need to do a whole new MacPorts  
release just to fix it. And we know how infrequent MacPorts releases  
have been lately.

I would much prefer that MacPorts itself print very little  
information to the user: only a brief statement about what happened,  
and a link to the FAQ entry about that error. Since this link would  
point to a wiki page, inaccuracies could be very quickly corrected by  
anyone.


Just like we're talking about having a chunked guide now instead of  
the entire guide all on one page, maybe we should have one error  
message per page too instead of all on one. We could have a wiki  
template for error messages, like we have a wiki template for how-to's.


From randall.h.wood at alexandriasoftware.com  Tue Jul 22 01:42:09 2008
From: randall.h.wood at alexandriasoftware.com (Randall Wood)
Date: Tue, 22 Jul 2008 04:42:09 -0400
Subject: Chunked guide
In-Reply-To: <0F0AD412-083B-41AE-8EF5-F2889A691DB3@macports.org>
References: <fc.004c4c580fdd69db004c4c580fdd69db.fdd6b59@biola.edu>
	<0F0AD412-083B-41AE-8EF5-F2889A691DB3@macports.org>
Message-ID: <c24012060807220142t680b1db8sacfda2d226c833a4@mail.gmail.com>

On Tue, Jul 22, 2008 at 3:19 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On Jul 20, 2008, at 09:34, markd at macports.org wrote:
>
>> The only "problem" with the chunked version is you can't
>> do a browser search of the whole document, but I'm not sure how many
>> people want that.
>
> I was initially going to suggest making a chunked guide because it's
> what I'm used to from other projects like php and mysql. But since
> then I've found it convenient to have it all on one page. I do use
> the browser search feature to quickly determine whether or not the
> guide mentions a particular topic at all before filing an enhancement
> request.
>
> I can learn to live with a Google search instead. If we make the
> chunked guide the default, we should provide a Google search box
> which searches just guide.macports.org.

Why not place this across all MacPorts sites?
http://www.google.com/coop/cse?cx=011837386708472035020:5lqtx6zp3qw

> _______________________________________________
> 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 ryandesign at macports.org  Tue Jul 22 02:11:57 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 22 Jul 2008 04:11:57 -0500
Subject: Chunked guide
In-Reply-To: <c24012060807220142t680b1db8sacfda2d226c833a4@mail.gmail.com>
References: <fc.004c4c580fdd69db004c4c580fdd69db.fdd6b59@biola.edu>
	<0F0AD412-083B-41AE-8EF5-F2889A691DB3@macports.org>
	<c24012060807220142t680b1db8sacfda2d226c833a4@mail.gmail.com>
Message-ID: <7536594D-9222-424A-82F2-DDDD092C49CF@macports.org>


On Jul 22, 2008, at 03:42, Randall Wood wrote:

> On Tue, Jul 22, 2008 at 3:19 AM, Ryan Schmidt wrote:
>
>> On Jul 20, 2008, at 09:34, markd at macports.org wrote:
>>
>>> The only "problem" with the chunked version is you can't
>>> do a browser search of the whole document, but I'm not sure how many
>>> people want that.
>>
>> I was initially going to suggest making a chunked guide because it's
>> what I'm used to from other projects like php and mysql. But since
>> then I've found it convenient to have it all on one page. I do use
>> the browser search feature to quickly determine whether or not the
>> guide mentions a particular topic at all before filing an enhancement
>> request.
>>
>> I can learn to live with a Google search instead. If we make the
>> chunked guide the default, we should provide a Google search box
>> which searches just guide.macports.org.
>
> Why not place this across all MacPorts sites?
> http://www.google.com/coop/cse?cx=011837386708472035020:5lqtx6zp3qw

Searching across more than just guide.macports.org does not answer  
the question "Is this in the Guide?" It doesn't even answer the  
question "How do I use this?" For example, I might want search the  
Guide for "build.dir" to see what the default is. But using your  
search, I get a bunch of tickets where build.dir is mentioned, which  
is not what I wanted. If we remove the single-page Guide, or make the  
chunked Guide the preferred Guide, then we need to provide a way to  
search it, and only it.


From randall.h.wood at alexandriasoftware.com  Tue Jul 22 02:38:10 2008
From: randall.h.wood at alexandriasoftware.com (Randall Wood)
Date: Tue, 22 Jul 2008 05:38:10 -0400
Subject: Chunked guide
In-Reply-To: <7536594D-9222-424A-82F2-DDDD092C49CF@macports.org>
References: <fc.004c4c580fdd69db004c4c580fdd69db.fdd6b59@biola.edu>
	<0F0AD412-083B-41AE-8EF5-F2889A691DB3@macports.org>
	<c24012060807220142t680b1db8sacfda2d226c833a4@mail.gmail.com>
	<7536594D-9222-424A-82F2-DDDD092C49CF@macports.org>
Message-ID: <c24012060807220238l7d566a36j72803f9f0928bd4f@mail.gmail.com>

On Tue, Jul 22, 2008 at 5:11 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On Jul 22, 2008, at 03:42, Randall Wood wrote:
>
>> On Tue, Jul 22, 2008 at 3:19 AM, Ryan Schmidt wrote:
>>
>>> On Jul 20, 2008, at 09:34, markd at macports.org wrote:
>>>
>>>> The only "problem" with the chunked version is you can't
>>>> do a browser search of the whole document, but I'm not sure how many
>>>> people want that.
>>>
>>> I was initially going to suggest making a chunked guide because it's
>>> what I'm used to from other projects like php and mysql. But since
>>> then I've found it convenient to have it all on one page. I do use
>>> the browser search feature to quickly determine whether or not the
>>> guide mentions a particular topic at all before filing an enhancement
>>> request.
>>>
>>> I can learn to live with a Google search instead. If we make the
>>> chunked guide the default, we should provide a Google search box
>>> which searches just guide.macports.org.
>>
>> Why not place this across all MacPorts sites?
>> http://www.google.com/coop/cse?cx=011837386708472035020:5lqtx6zp3qw
>
> Searching across more than just guide.macports.org does not answer the
> question "Is this in the Guide?" It doesn't even answer the question "How do
> I use this?" For example, I might want search the Guide for "build.dir" to
> see what the default is. But using your search, I get a bunch of tickets
> where build.dir is mentioned, which is not what I wanted. If we remove the
> single-page Guide, or make the chunked Guide the preferred Guide, then we
> need to provide a way to search it, and only it.
>
>
Are the topical searches within results not showing the guide? (Now  I
just need to figure out how to get a topical search to be the default
one...)



-- 
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 markd at macports.org  Wed Jul 23 13:35:53 2008
From: markd at macports.org (markd at macports.org)
Date: Wed, 23 Jul 2008 13:35:53 -0700
Subject: To whom should error messages be written?
Message-ID: <fc.004c4c580fe09d40004c4c580fe09d40.fe31edf@biola.edu>

>>> I think we should write error messages to the end user, not the
>>> portfile developer. I think we should also have a new page in the
>>> wiki called ErrorMessages, where we can list the error messages that
>>> MacPorts might print along with explanations of what the portfile
>>> author should do about them. We would describe mtree violations and
>>> ineffectual reinplaces and checksum failures (the checksum failure
>>> discussion would move to this new page from the FAQ).
>>>
>>> Or we could put all these in the FAQ page, maybe in a new section for
>>> error messages.
>>
>> I think this might not be sustainable and might lead to always out-
>> of-date
>> docs.  I wouldn't be in favor of this unless the error messages were
>> sourced out of the code itself, rather than written independently.
>
>Can you suggest an alternative?
>
>There is a vast amount of information, for example, that we want to
>impart to people who encounter a checksum error. The port command
>does not provide any of it. Instead the user must read the FAQ to
>figure out which of several reasons for the checksum error exist and
>how to resolve it. And we have some information which is for MacPorts
>users and other information which is for port maintainers.
>
>Not all errors need that much explanation, but I'm sure at least a
>paragraph could be written about each. Would you rather the port
>command print all of that out? And what if the instructions are
>inaccurate or unclear? Then we need to do a whole new MacPorts
>release just to fix it. And we know how infrequent MacPorts releases
>have been lately.
>
>I would much prefer that MacPorts itself print very little
>information to the user: only a brief statement about what happened,
>and a link to the FAQ entry about that error. Since this link would
>point to a wiki page, inaccuracies could be very quickly corrected by
>anyone.
>
>
>Just like we're talking about having a chunked guide now instead of
>the entire guide all on one page, maybe we should have one error
>message per page too instead of all on one. We could have a wiki
>template for error messages, like we have a wiki template for how-to's.

This might all be fine.  At the time I read it I was envisioning a lot of
duplication; large companies sometimes have extensive error message lists
in formal documentation.  I've thought of links to online docs in error
messages too.

I do favor error messages communicating as much information as possible in
a terse fashion though.  If they are innaccuarate or unclear I suspect it
will cause problems even for the developers at some point.  So I think any
new error message approaches to enhancing the user experience are fine,
but I'm just saying we should be careful about trying to solve current
problems that originate from error message innaccuracy or release
frequency that way.

Mark


From ryandesign at macports.org  Wed Jul 23 17:45:55 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 23 Jul 2008 19:45:55 -0500
Subject: Chunked guide
In-Reply-To: <c24012060807220238l7d566a36j72803f9f0928bd4f@mail.gmail.com>
References: <fc.004c4c580fdd69db004c4c580fdd69db.fdd6b59@biola.edu>
	<0F0AD412-083B-41AE-8EF5-F2889A691DB3@macports.org>
	<c24012060807220142t680b1db8sacfda2d226c833a4@mail.gmail.com>
	<7536594D-9222-424A-82F2-DDDD092C49CF@macports.org>
	<c24012060807220238l7d566a36j72803f9f0928bd4f@mail.gmail.com>
Message-ID: <885132C4-CFC3-43D6-B2CA-A2EA543255E9@macports.org>

On Jul 22, 2008, at 04:38, Randall Wood wrote:

> On Tue, Jul 22, 2008 at 5:11 AM, Ryan Schmidt wrote:
>
>> On Jul 22, 2008, at 03:42, Randall Wood wrote:
>>
>>> On Tue, Jul 22, 2008 at 3:19 AM, Ryan Schmidt wrote:
>>>
>>>> On Jul 20, 2008, at 09:34, markd at macports.org wrote:
>>>>
>>>>> The only "problem" with the chunked version is you can't
>>>>> do a browser search of the whole document, but I'm not sure how  
>>>>> many
>>>>> people want that.
>>>>
>>>> I was initially going to suggest making a chunked guide because  
>>>> it's
>>>> what I'm used to from other projects like php and mysql. But since
>>>> then I've found it convenient to have it all on one page. I do use
>>>> the browser search feature to quickly determine whether or not the
>>>> guide mentions a particular topic at all before filing an  
>>>> enhancement
>>>> request.
>>>>
>>>> I can learn to live with a Google search instead. If we make the
>>>> chunked guide the default, we should provide a Google search box
>>>> which searches just guide.macports.org.
>>>
>>> Why not place this across all MacPorts sites?
>>> http://www.google.com/coop/cse?cx=011837386708472035020:5lqtx6zp3qw
>>
>> Searching across more than just guide.macports.org does not answer  
>> the
>> question "Is this in the Guide?" It doesn't even answer the  
>> question "How do
>> I use this?" For example, I might want search the Guide for  
>> "build.dir" to
>> see what the default is. But using your search, I get a bunch of  
>> tickets
>> where build.dir is mentioned, which is not what I wanted. If we  
>> remove the
>> single-page Guide, or make the chunked Guide the preferred Guide,  
>> then we
>> need to provide a way to search it, and only it.
>
> Are the topical searches within results not showing the guide? (Now  I
> just need to figure out how to get a topical search to be the default
> one...)

You mean the part after I do my search where it says:

Refine results for foo: Guide Tickets Changesets Ports Wiki

Honestly I hadn't seen that until now. It works fine when I click  
"Guide".

Still I'd rather not search over everything, then have to refine my  
search. I want the right search from the beginning. I guess I can  
type "more:guide" into the search box. It would be easier if there  
were a drop-down menu where I could select how I want to refine the  
search right at the beginning.


From randall.h.wood at alexandriasoftware.com  Thu Jul 24 02:44:38 2008
From: randall.h.wood at alexandriasoftware.com (Randall Wood)
Date: Thu, 24 Jul 2008 05:44:38 -0400
Subject: Chunked guide
In-Reply-To: <885132C4-CFC3-43D6-B2CA-A2EA543255E9@macports.org>
References: <fc.004c4c580fdd69db004c4c580fdd69db.fdd6b59@biola.edu>
	<0F0AD412-083B-41AE-8EF5-F2889A691DB3@macports.org>
	<c24012060807220142t680b1db8sacfda2d226c833a4@mail.gmail.com>
	<7536594D-9222-424A-82F2-DDDD092C49CF@macports.org>
	<c24012060807220238l7d566a36j72803f9f0928bd4f@mail.gmail.com>
	<885132C4-CFC3-43D6-B2CA-A2EA543255E9@macports.org>
Message-ID: <c24012060807240244j3f1e5777hecea5dbef2789c44@mail.gmail.com>

On Wed, Jul 23, 2008 at 8:45 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Jul 22, 2008, at 04:38, Randall Wood wrote:
>
>> On Tue, Jul 22, 2008 at 5:11 AM, Ryan Schmidt wrote:
>>
>>> On Jul 22, 2008, at 03:42, Randall Wood wrote:
>>>
>>>> On Tue, Jul 22, 2008 at 3:19 AM, Ryan Schmidt wrote:
>>>>
>>>>> On Jul 20, 2008, at 09:34, markd at macports.org wrote:
>>>>>
>>>>>> The only "problem" with the chunked version is you can't
>>>>>> do a browser search of the whole document, but I'm not sure how many
>>>>>> people want that.
>>>>>
>>>>> I was initially going to suggest making a chunked guide because it's
>>>>> what I'm used to from other projects like php and mysql. But since
>>>>> then I've found it convenient to have it all on one page. I do use
>>>>> the browser search feature to quickly determine whether or not the
>>>>> guide mentions a particular topic at all before filing an enhancement
>>>>> request.
>>>>>
>>>>> I can learn to live with a Google search instead. If we make the
>>>>> chunked guide the default, we should provide a Google search box
>>>>> which searches just guide.macports.org.
>>>>
>>>> Why not place this across all MacPorts sites?
>>>> http://www.google.com/coop/cse?cx=011837386708472035020:5lqtx6zp3qw
>>>
>>> Searching across more than just guide.macports.org does not answer the
>>> question "Is this in the Guide?" It doesn't even answer the question "How
>>> do
>>> I use this?" For example, I might want search the Guide for "build.dir"
>>> to
>>> see what the default is. But using your search, I get a bunch of tickets
>>> where build.dir is mentioned, which is not what I wanted. If we remove
>>> the
>>> single-page Guide, or make the chunked Guide the preferred Guide, then we
>>> need to provide a way to search it, and only it.
>>
>> Are the topical searches within results not showing the guide? (Now  I
>> just need to figure out how to get a topical search to be the default
>> one...)
>
> You mean the part after I do my search where it says:
>
> Refine results for foo: Guide Tickets Changesets Ports Wiki
>
> Honestly I hadn't seen that until now. It works fine when I click "Guide".
>
> Still I'd rather not search over everything, then have to refine my search.
> I want the right search from the beginning. I guess I can type "more:guide"
> into the search box. It would be easier if there were a drop-down menu where
> I could select how I want to refine the search right at the beginning.

The Google Search API (javascript) makes this possible. So, is the use
of JavaScript to draw the search form acceptable or not in this case?

-- 
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 db.evans at gmail.com  Thu Jul 24 10:12:28 2008
From: db.evans at gmail.com (David Evans)
Date: Thu, 24 Jul 2008 10:12:28 -0700
Subject: Committer help requested
Message-ID: <4888B7FC.4050806@gmail.com>

Would appreciate comitter help with the following tickets:

http://trac.macports.org/ticket/16046
http://trac.macports.org/ticket/16047
http://trac.macports.org/ticket/16048
http://trac.macports.org/ticket/16049
http://trac.macports.org/ticket/16051

Thanks

From wsiegrist at apple.com  Thu Jul 24 10:03:53 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Thu, 24 Jul 2008 10:03:53 -0700
Subject: [38526] trunk/dports/net/openssh
In-Reply-To: <20080724043305.114AA17CE27@beta.macosforge.org>
References: <20080724043305.114AA17CE27@beta.macosforge.org>
Message-ID: <AA37B805-5B26-470F-93AE-ACDCCD07C4CE@apple.com>

I've backed out the new patches to openssh since most of the fixes do  
not work. I'll try to get some updated patches next week to hopefully  
actually fix keychain, kerberos, and PAM.

Sorry for the churn.

-Bill



On Jul 23, 2008, at 9:33 PM, wsiegrist at apple.com wrote:

> Revision38526Authorwsiegrist at apple.comDate2008-07-23 21:33:03 -0700  
> (Wed, 23 Jul 2008)Log Message
> Adding patches from Apple for various fixes. Primarily this commit  
> fixes keychain integration.
> Modified Paths
> 	? trunk/dports/net/openssh/Portfile
> Added Paths
> 	? trunk/dports/net/openssh/files/ 
> AJ-5229538+5383306+5446006+5567447+5806868_keychain.patch
> 	? trunk/dports/net/openssh/files/AJ-5491854- 
> fix_unsafe_usage_of_getpwuid.patch
> 	? trunk/dports/net/openssh/files/DVG-3977221_manpage_tweaks.patch
> 	? trunk/dports/net/openssh/files/DVG-4122722+5277818_new_EA.patch
> 	? trunk/dports/net/openssh/files/ 
> DVG-4135812_add_SACLSupport_to_sshd_conf_manpage.patch
> 	? trunk/dports/net/openssh/files/ 
> DVG-4157448+4920695_corrected_UsePAM_comment.patch
> 	? trunk/dports/net/openssh/files/ 
> DVG-4212542_auth_error_logging_fix.patch
> 	? trunk/dports/net/openssh/files/DVG-4648874_preserve_EA_mtime.patch
> 	? trunk/dports/net/openssh/files/DVG-4694589_16_group_limit_fix.patch
> 	? trunk/dports/net/openssh/files/DVG-4748610+4897588_ssh- 
> agent_via_launchd.patch
> 	? trunk/dports/net/openssh/files/DVG-4853931_enable_GSSAPI.patch
> 	? trunk/dports/net/openssh/files/DVG-4853931_enable_GSSAPI_for_pre- 
> Leopard---BuildPhase.patch
> 	? trunk/dports/net/openssh/files/ 
> DVG-4920695_remove_nullok_comment_for_pre-Leopard---BuildPhase.patch
> 	? trunk/dports/net/openssh/files/ 
> DVG-5142987_launchd_DISPLAY_for_X11.patch
> 	? trunk/dports/net/openssh/files/DVG-5258734_pty_permission_fix.patch
> 	? trunk/dports/net/openssh/files/DVG-5462402_enable_SSH1_for_pre- 
> Leopard---BuildPhase.patch
> 	? trunk/dports/net/openssh/files/ 
> DVG-5755519_use_GSS_C_NO_NAME_with_gss_acquire_cred.patch
> 	? trunk/dports/net/openssh/files/lastlog.patch
> 	? trunk/dports/net/openssh/files/openssh-5.0p1-gsskex-20080404.patch
> 	? trunk/dports/net/openssh/files/pam.patch
> 	? trunk/dports/net/openssh/files/sacl.patch
> Diff
> Modified: trunk/dports/net/openssh/Portfile (38525 => 38526)
> --- trunk/dports/net/openssh/Portfile	2008-07-24 03:33:34 UTC (rev  
> 38525)
> +++ trunk/dports/net/openssh/Portfile	2008-07-24 04:33:03 UTC (rev  
> 38526)
> @@ -4,6 +4,7 @@
>
>  name            openssh
>  version         5.0p1
> +revision	1
>  categories      net
>  maintainers     wms
>  description     OpenSSH secure login server
> @@ -20,9 +21,9 @@
>  homepage        http://www.openssh.com/
>  platforms       darwin
>  checksums       ${distfiles} \
> -		md5 1f1dfaa775f33dd3328169de9bdc292a \
> -		sha1 121cea3a730c0b0353334b6f46f438de30ab4928 \
> -		rmd160 b813234014e339fe2d9d10a5adad9f8e065918fc
> +                md5     1f1dfaa775f33dd3328169de9bdc292a \
> +                sha1    121cea3a730c0b0353334b6f46f438de30ab4928 \
> +                rmd160  b813234014e339fe2d9d10a5adad9f8e065918fc
>
>  master_sites    openbsd:OpenSSH/portable \
>  	http://mirror.mcs.anl.gov/openssh/portable/ \
> @@ -34,6 +35,24 @@
>  	ftp://openbsd.secsup.org/pub/openbsd/OpenSSH/portable/
>  depends_lib     port:openssl port:zlib
>
> +patchfiles	pam.patch \
> +		sacl.patch \
> +		DVG-4122722+5277818_new_EA.patch \
> +		DVG-3977221_manpage_tweaks.patch \
> +		DVG-4212542_auth_error_logging_fix.patch \
> +		DVG-4157448+4920695_corrected_UsePAM_comment.patch \
> +		lastlog.patch \
> +		openssh-5.0p1-gsskex-20080404.patch \
> +		DVG-4853931_enable_GSSAPI.patch \
> +		DVG-4648874_preserve_EA_mtime.patch \
> +		DVG-4748610+4897588_ssh-agent_via_launchd.patch \
> +		DVG-4694589_16_group_limit_fix.patch \
> +		DVG-5142987_launchd_DISPLAY_for_X11.patch \
> +		DVG-5258734_pty_permission_fix.patch \
> +		AJ-5491854-fix_unsafe_usage_of_getpwuid.patch \
> +		DVG-4135812_add_SACLSupport_to_sshd_conf_manpage.patch \
> +		DVG-5755519_use_GSS_C_NO_NAME_with_gss_acquire_cred.patch
> +
>  # Specified -fno-builtin because GCC 3.3 has log() as a builtin
>  # (from math.h) while OpenSSH has its own log() function
>  # -- from fink.
> @@ -43,8 +62,9 @@
>    --with-pid-dir=${prefix}/var/run --with-tcp-wrappers \
>    --with-pam --disable-suid-ssh --with-random=/dev/urandom \
>    --mandir=${prefix}/share/man --with-zlib=${prefix} \
> -  --with-kerberos5=/usr
> +  --with-kerberos5
>
> +
>  destroot.target install-nokeys
>
>  post-destroot {
> @@ -81,13 +101,18 @@
>    }
>  }
>
> +set keychain_patch  
> AJ-5229538+5383306+5446006+5567447+5806868_keychain.patch
> +
>  platform darwin 9 {
> -  patch_sites-append   http://www.opensource.apple.com/darwinsource/10.5/OpenSSH-87/patches/
> -  patchfiles-append    DVG-5142987_launchd_DISPLAY_for_X11.patch
> -  checksums-append     DVG-5142987_launchd_DISPLAY_for_X11.patch \
> -                       md5 e188ebbba95c4cde61e0e1b2edc9f992 \
> -                       sha1  
> 62735c5bfbbe1fa41433993435ded7767cc5f1f9 \
> -                       rmd160  
> eb5262f554583f4925f6f91f6a6d0034c70098ad
> +  pre-patch {
> +	reinplace "s|/usr/bin/|${prefix}/bin/|g" "${filespath}/$ 
> {keychain_patch}"
> +  }
> +  patchfiles-append	        ${keychain_patch}
> +  configure.args-append         --with-keychain=apple
> +  configure.cflags-append	-fPIE -Wl,-pie -D_FORTIFY_SOURCE=2
> +  configure.ldflags-append	-L. -Lopenbsd-compat -Wl,-pie
> +  configure.cppflags-append	-D__APPLE_SACL__ -D_UTMPX_COMPAT - 
> D__APPLE_UTMPX__ -DUSE_CCAPI \
> +                                -D__APPLE_LAUNCHD__ - 
> D__APPLE_PRIVPTY__ -D__BROKEN_GLOB__ -Dcannot_audit
>  }
>
>  startupitem.create  yes
> Added: trunk/dports/net/openssh/files/ 
> AJ-5229538+5383306+5446006+5567447+5806868_keychain.patch (0 => 38526)
> --- trunk/dports/net/openssh/files/ 
> AJ 
> -5229538 
> + 
> 5383306 
> +5446006+5567447+5806868_keychain.patch	                        (rev  
> 0)
> +++ trunk/dports/net/openssh/files/ 
> AJ-5229538+5383306+5446006+5567447+5806868_keychain.patch	2008-07-24  
> 04:33:03 UTC (rev 38526)
> @@ -0,0 +1,1457 @@
> +diff -uNr ../openssh-5.0p1.orig/Makefile.in ./Makefile.in
> +--- ../openssh-5.0p1.orig/Makefile.in	2008-03-12 18:41:31.000000000  
> -0700
> ++++ ./Makefile.in	2008-04-15 18:32:47.000000000 -0700
> +@@ -56,6 +56,7 @@
> + XAUTH_PATH=@XAUTH_PATH@
> + LDFLAGS=-L. -Lopenbsd-compat/ @LDFLAGS@
> + EXEEXT=@EXEEXT@
> ++KEYCHAIN_LDFLAGS=@KEYCHAIN_LDFLAGS@
> +
> + INSTALL_SSH_PRNG_CMDS=@INSTALL_SSH_PRNG_CMDS@
> + INSTALL_SSH_RAND_HELPER=@INSTALL_SSH_RAND_HELPER@
> +@@ -88,6 +89,8 @@
> + 	loginrec.o auth-pam.o auth-shadow.o auth-sia.o md5crypt.o \
> + 	audit.o audit-bsm.o platform.o sftp-server.o sftp-common.o
> +
> ++KEYCHAINOBJS=keychain.o
> ++
> + MANPAGES	= scp.1.out ssh-add.1.out ssh-agent.1.out ssh-keygen. 
> 1.out ssh-keyscan.1.out ssh.1.out sshd.8.out sftp-server.8.out sftp. 
> 1.out ssh-rand-helper.8.out ssh-keysign.8.out sshd_config.5.out  
> ssh_config.5.out
> + MANPAGES_IN	= scp.1 ssh-add.1 ssh-agent.1 ssh-keygen.1 ssh-keyscan. 
> 1 ssh.1 sshd.8 sftp-server.8 sftp.1 ssh-rand-helper.8 ssh-keysign.8  
> sshd_config.5 ssh_config.5
> + MANTYPE		= @MANTYPE@
> +@@ -119,6 +122,7 @@
> + $(LIBSSH_OBJS): Makefile.in config.h
> + $(SSHOBJS): Makefile.in config.h
> + $(SSHDOBJS): Makefile.in config.h
> ++$(KEYCHAINOBJS): Makefile.in config.h
> +
> + .c.o:
> + 	$(CC) $(CFLAGS) $(CPPFLAGS) -c $<
> +@@ -132,8 +136,8 @@
> + 	$(AR) rv $@ $(LIBSSH_OBJS)
> + 	$(RANLIB) $@
> +
> +-ssh$(EXEEXT): $(LIBCOMPAT) libssh.a $(SSHOBJS)
> +-	$(LD) -o $@ $(SSHOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
> ++ssh$(EXEEXT): $(LIBCOMPAT) libssh.a $(SSHOBJS) $(KEYCHAINOBJS)
> ++	$(LD) -o $@ $(SSHOBJS) $(KEYCHAINOBJS) $(LDFLAGS) $ 
> (KEYCHAIN_LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
> +
> + sshd$(EXEEXT): libssh.a	$(LIBCOMPAT) $(SSHDOBJS)
> + 	$(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $ 
> (SSHDLIBS) $(LIBS)
> +@@ -141,11 +145,11 @@
> + scp$(EXEEXT): $(LIBCOMPAT) libssh.a scp.o progressmeter.o
> + 	$(LD) -o $@ scp.o progressmeter.o bufaux.o $(LDFLAGS) -lssh - 
> lopenbsd-compat $(LIBS)
> +
> +-ssh-add$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-add.o
> +-	$(LD) -o $@ ssh-add.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
> ++ssh-add$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-add.o $(KEYCHAINOBJS)
> ++	$(LD) -o $@ ssh-add.o $(KEYCHAINOBJS) $(LDFLAGS) $ 
> (KEYCHAIN_LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
> +
> +-ssh-agent$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-agent.o
> +-	$(LD) -o $@ ssh-agent.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
> ++ssh-agent$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-agent.o $ 
> (KEYCHAINOBJS)
> ++	$(LD) -o $@ ssh-agent.o $(KEYCHAINOBJS) $(LDFLAGS) $ 
> (KEYCHAIN_LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
> +
> + ssh-keygen$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keygen.o
> + 	$(LD) -o $@ ssh-keygen.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
> +diff -uNr ../openssh-5.0p1.orig/authfd.c ./authfd.c
> +--- ../openssh-5.0p1.orig/authfd.c	2006-08-31 22:38:36.000000000  
> -0700
> ++++ ./authfd.c	2008-04-15 18:32:47.000000000 -0700
> +@@ -652,6 +652,29 @@
> + 	return decode_reply(type);
> + }
> +
> ++/*
> ++ * Adds identities using passphrases stored in the keychain.  This  
> call is not
> ++ * meant to be used by normal applications.
> ++ */
> ++
> ++int
> ++ssh_add_from_keychain(AuthenticationConnection *auth)
> ++{
> ++	Buffer msg;
> ++	int type;
> ++
> ++	buffer_init(&msg);
> ++	buffer_put_char(&msg, SSH_AGENTC_ADD_FROM_KEYCHAIN);
> ++
> ++	if (ssh_request_reply(auth, &msg, &msg) == 0) {
> ++		buffer_free(&msg);
> ++		return 0;
> ++	}
> ++	type = buffer_get_char(&msg);
> ++	buffer_free(&msg);
> ++	return decode_reply(type);
> ++}
> ++
> + int
> + decode_reply(int type)
> + {
> +diff -uNr ../openssh-5.0p1.orig/authfd.h ./authfd.h
> +--- ../openssh-5.0p1.orig/authfd.h	2006-08-04 19:39:39.000000000  
> -0700
> ++++ ./authfd.h	2008-04-15 18:32:47.000000000 -0700
> +@@ -49,6 +49,9 @@
> + #define SSH2_AGENTC_ADD_ID_CONSTRAINED		25
> + #define SSH_AGENTC_ADD_SMARTCARD_KEY_CONSTRAINED 26
> +
> ++/* keychain */
> ++#define SSH_AGENTC_ADD_FROM_KEYCHAIN		27
> ++
> + #define	SSH_AGENT_CONSTRAIN_LIFETIME		1
> + #define	SSH_AGENT_CONSTRAIN_CONFIRM		2
> +
> +diff -uNr ../openssh-5.0p1.orig/configure ./configure
> +--- ../openssh-5.0p1.orig/configure	2008-04-03 03:01:50.000000000  
> -0700
> ++++ ./configure	2008-04-15 18:32:47.000000000 -0700
> +@@ -723,6 +723,7 @@
> + mansubdir
> + user_path
> + piddir
> ++KEYCHAIN_LDFLAGS
> + LIBOBJS
> + LTLIBOBJS'
> + ac_subst_files=''
> +@@ -1364,6 +1365,7 @@
> +   --with-bsd-auth         Enable BSD auth support
> +   --with-pid-dir=PATH     Specify location of ssh.pid file
> +   --with-lastlog=FILE|DIR specify lastlog location common locations
> ++  --with-keychain=apple   Use Mac OS X Keychain
> +
> + Some influential environment variables:
> +   CC          C compiler command
> +@@ -7133,6 +7135,7 @@
> + #define DISABLE_FD_PASSING 1
> + _ACEOF
> +
> ++	KEYCHAIN="apple"
> + 	;;
> + *-*-dgux*)
> + 	cat >>confdefs.h <<\_ACEOF
> +@@ -28605,6 +28608,181 @@
> + echo "$as_me: WARNING: Please check and edit blibpath in LDFLAGS  
> in Makefile" >&2;}
> + fi
> +
> ++# Check whether --with-keychain was given.
> ++if test "${with_keychain+set}" = set; then
> ++  withval=$with_keychain;
> ++		case "$withval" in
> ++		apple|no)
> ++			KEYCHAIN=$withval
> ++			;;
> ++		*)
> ++			{ { echo "$as_me:$LINENO: error: invalid keychain type:  
> $withval" >&5
> ++echo "$as_me: error: invalid keychain type: $withval" >&2;}
> ++   { (exit 1); exit 1; }; }
> ++			;;
> ++		esac
> ++
> ++
> ++fi
> ++
> ++if test ! -z "$KEYCHAIN" -a "$KEYCHAIN" != "no"; then
> ++	case "$KEYCHAIN" in
> ++	apple)
> ++
> ++for ac_header in Security/Security.h
> ++do
> ++as_ac_Header=`echo "ac_cv_header_$ac_header" | $as_tr_sh`
> ++if { as_var=$as_ac_Header; eval "test \"\${$as_var+set}\" =  
> set"; }; then
> ++  { echo "$as_me:$LINENO: checking for $ac_header" >&5
> ++echo $ECHO_N "checking for $ac_header... $ECHO_C" >&6; }
> ++if { as_var=$as_ac_Header; eval "test \"\${$as_var+set}\" =  
> set"; }; then
> ++  echo $ECHO_N "(cached) $ECHO_C" >&6
> ++fi
> ++ac_res=`eval echo '${'$as_ac_Header'}'`
> ++	       { echo "$as_me:$LINENO: result: $ac_res" >&5
> ++echo "${ECHO_T}$ac_res" >&6; }
> ++else
> ++  # Is the header compilable?
> ++{ echo "$as_me:$LINENO: checking $ac_header usability" >&5
> ++echo $ECHO_N "checking $ac_header usability... $ECHO_C" >&6; }
> ++cat >conftest.$ac_ext <<_ACEOF
> ++/* confdefs.h.  */
> ++_ACEOF
> ++cat confdefs.h >>conftest.$ac_ext
> ++cat >>conftest.$ac_ext <<_ACEOF
> ++/* end confdefs.h.  */
> ++$ac_includes_default
> ++#include <$ac_header>
> ++_ACEOF
> ++rm -f conftest.$ac_objext
> ++if { (ac_try="$ac_compile"
> ++case "(($ac_try" in
> ++  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
> ++  *) ac_try_echo=$ac_try;;
> ++esac
> ++eval "echo \"\$as_me:$LINENO: $ac_try_echo\"") >&5
> ++  (eval "$ac_compile") 2>conftest.er1
> ++  ac_status=$?
> ++  grep -v '^ *+' conftest.er1 >conftest.err
> ++  rm -f conftest.er1
> ++  cat conftest.err >&5
> ++  echo "$as_me:$LINENO: \$? = $ac_status" >&5
> ++  (exit $ac_status); } && {
> ++	 test -z "$ac_c_werror_flag" ||
> ++	 test ! -s conftest.err
> ++       } && test -s conftest.$ac_objext; then
> ++  ac_header_compiler=yes
> ++else
> ++  echo "$as_me: failed program was:" >&5
> ++sed 's/^/| /' conftest.$ac_ext >&5
> ++
> ++	ac_header_compiler=no
> ++fi
> ++
> ++rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
> ++{ echo "$as_me:$LINENO: result: $ac_header_compiler" >&5
> ++echo "${ECHO_T}$ac_header_compiler" >&6; }
> ++
> ++# Is the header present?
> ++{ echo "$as_me:$LINENO: checking $ac_header presence" >&5
> ++echo $ECHO_N "checking $ac_header presence... $ECHO_C" >&6; }
> ++cat >conftest.$ac_ext <<_ACEOF
> ++/* confdefs.h.  */
> ++_ACEOF
> ++cat confdefs.h >>conftest.$ac_ext
> ++cat >>conftest.$ac_ext <<_ACEOF
> ++/* end confdefs.h.  */
> ++#include <$ac_header>
> ++_ACEOF
> ++if { (ac_try="$ac_cpp conftest.$ac_ext"
> ++case "(($ac_try" in
> ++  *\"* | *\`* | *\\*) ac_try_echo=\$ac_try;;
> ++  *) ac_try_echo=$ac_try;;
> ++esac
> ++eval "echo \"\$as_me:$LINENO: $ac_try_echo\"") >&5
> ++  (eval "$ac_cpp conftest.$ac_ext") 2>conftest.er1
> ++  ac_status=$?
> ++  grep -v '^ *+' conftest.er1 >conftest.err
> ++  rm -f conftest.er1
> ++  cat conftest.err >&5
> ++  echo "$as_me:$LINENO: \$? = $ac_status" >&5
> ++  (exit $ac_status); } >/dev/null && {
> ++	 test -z "$ac_c_preproc_warn_flag$ac_c_werror_flag" ||
> ++	 test ! -s conftest.err
> ++       }; then
> ++  ac_header_preproc=yes
> ++else
> ++  echo "$as_me: failed program was:" >&5
> ++sed 's/^/| /' conftest.$ac_ext >&5
> ++
> ++  ac_header_preproc=no
> ++fi
> ++
> ++rm -f conftest.err conftest.$ac_ext
> ++{ echo "$as_me:$LINENO: result: $ac_header_preproc" >&5
> ++echo "${ECHO_T}$ac_header_preproc" >&6; }
> ++
> ++# So?  What about this header?
> ++case $ac_header_compiler:$ac_header_preproc: 
> $ac_c_preproc_warn_flag in
> ++  yes:no: )
> ++    { echo "$as_me:$LINENO: WARNING: $ac_header: accepted by the  
> compiler, rejected by the preprocessor!" >&5
> ++echo "$as_me: WARNING: $ac_header: accepted by the compiler,  
> rejected by the preprocessor!" >&2;}
> ++    { echo "$as_me:$LINENO: WARNING: $ac_header: proceeding with  
> the compiler's result" >&5
> ++echo "$as_me: WARNING: $ac_header: proceeding with the compiler's  
> result" >&2;}
> ++    ac_header_preproc=yes
> ++    ;;
> ++  no:yes:* )
> ++    { echo "$as_me:$LINENO: WARNING: $ac_header: present but  
> cannot be compiled" >&5
> ++echo "$as_me: WARNING: $ac_header: present but cannot be compiled"  
> >&2;}
> ++    { echo "$as_me:$LINENO: WARNING: $ac_header:     check for  
> missing prerequisite headers?" >&5
> ++echo "$as_me: WARNING: $ac_header:     check for missing  
> prerequisite headers?" >&2;}
> ++    { echo "$as_me:$LINENO: WARNING: $ac_header: see the Autoconf  
> documentation" >&5
> ++echo "$as_me: WARNING: $ac_header: see the Autoconf documentation"  
> >&2;}
> ++    { echo "$as_me:$LINENO: WARNING: $ac_header:     section  
> \"Present But Cannot Be Compiled\"" >&5
> ++echo "$as_me: WARNING: $ac_header:     section \"Present But  
> Cannot Be Compiled\"" >&2;}
> ++    { echo "$as_me:$LINENO: WARNING: $ac_header: proceeding with  
> the preprocessor's result" >&5
> ++echo "$as_me: WARNING: $ac_header: proceeding with the  
> preprocessor's result" >&2;}
> ++    { echo "$as_me:$LINENO: WARNING: $ac_header: in the future,  
> the compiler will take precedence" >&5
> ++echo "$as_me: WARNING: $ac_header: in the future, the compiler  
> will take precedence" >&2;}
> ++    ( cat <<\_ASBOX
> ++## ------------------------------------------- ##
> ++## Report this to openssh-unix-dev at mindrot.org ##
> ++## ------------------------------------------- ##
> ++_ASBOX
> ++     ) | sed "s/^/$as_me: WARNING:     /" >&2
> ++    ;;
> ++esac
> ++{ echo "$as_me:$LINENO: checking for $ac_header" >&5
> ++echo $ECHO_N "checking for $ac_header... $ECHO_C" >&6; }
> ++if { as_var=$as_ac_Header; eval "test \"\${$as_var+set}\" =  
> set"; }; then
> ++  echo $ECHO_N "(cached) $ECHO_C" >&6
> ++else
> ++  eval "$as_ac_Header=\$ac_header_preproc"
> ++fi
> ++ac_res=`eval echo '${'$as_ac_Header'}'`
> ++	       { echo "$as_me:$LINENO: result: $ac_res" >&5
> ++echo "${ECHO_T}$ac_res" >&6; }
> ++
> ++fi
> ++if test `eval echo '${'$as_ac_Header'}'` = yes; then
> ++  cat >>confdefs.h <<_ACEOF
> ++#define `echo "HAVE_$ac_header" | $as_tr_cpp` 1
> ++_ACEOF
> ++
> ++				CPPFLAGS="$CPPFLAGS -D__APPLE_KEYCHAIN__"
> ++				KEYCHAIN_LDFLAGS="-framework Security -framework CoreFoundation"
> ++
> ++
> ++else
> ++  { echo "$as_me:$LINENO: WARNING: Security framework not found.  
> Disabling Mac OS X Keychain support." >&5
> ++echo "$as_me: WARNING: Security framework not found. Disabling Mac  
> OS X Keychain support." >&2;}
> ++fi
> ++
> ++done
> ++
> ++		;;
> ++	esac
> ++fi
> + CFLAGS="$CFLAGS $werror_flags"
> +
> +
> +@@ -29230,7 +29408,6 @@
> + _ACEOF
> +
> +
> +-
> + ac_delim='%!_!# '
> + for ac_last_try in false false false false false :; do
> +   cat >conf$$subs.sed <<_ACEOF
> +@@ -29382,11 +29559,12 @@
> + mansubdir!$mansubdir$ac_delim
> + user_path!$user_path$ac_delim
> + piddir!$piddir$ac_delim
> ++KEYCHAIN_LDFLAGS!$KEYCHAIN_LDFLAGS$ac_delim
> + LIBOBJS!$LIBOBJS$ac_delim
> + LTLIBOBJS!$LTLIBOBJS$ac_delim
> + _ACEOF
> +
> +-  if test `sed -n "s/.*$ac_delim\$/X/p" conf$$subs.sed | grep -c  
> X` = 12; then
> ++  if test `sed -n "s/.*$ac_delim\$/X/p" conf$$subs.sed | grep -c  
> X` = 13; then
> +     break
> +   elif $ac_last_try; then
> +     { { echo "$as_me:$LINENO: error: could not make  
> $CONFIG_STATUS" >&5
> +diff -uNr ../openssh-5.0p1.orig/configure.ac ./configure.ac
> +--- ../openssh-5.0p1.orig/configure.ac	2008-03-26  
> 18:33:07.000000000 -0700
> ++++ ./configure.ac	2008-04-15 18:32:47.000000000 -0700
> +@@ -594,6 +594,7 @@
> + 	    AC_DEFINE(SSH_TUN_NO_L2, 1, [No layer 2 tunnel support]))
> + 	AC_DEFINE(SSH_TUN_PREPEND_AF, 1,
> + 	    [Prepend the address family to IP tunnel traffic])
> ++	KEYCHAIN="apple"
> + 	;;
> + *-*-freebsd*)
> + 	check_for_libcrypt_later=1
> +@@ -4035,6 +4036,33 @@
> + 	AC_MSG_WARN([Please check and edit blibpath in LDFLAGS in  
> Makefile])
> + fi
> +
> ++dnl Keychain support
> ++AC_ARG_WITH(keychain,
> ++	[  --with-keychain=apple   Use Mac OS X Keychain],
> ++	[
> ++		case "$withval" in
> ++		apple|no)
> ++			KEYCHAIN=$withval
> ++			;;
> ++		*)
> ++			AC_MSG_ERROR(invalid keychain type: $withval)
> ++			;;
> ++		esac
> ++	]
> ++)
> ++if test ! -z "$KEYCHAIN" -a "$KEYCHAIN" != "no"; then
> ++	case "$KEYCHAIN" in
> ++	apple)
> ++		AC_CHECK_HEADERS(Security/Security.h, [
> ++				CPPFLAGS="$CPPFLAGS -D__APPLE_KEYCHAIN__"
> ++				KEYCHAIN_LDFLAGS="-framework Security -framework CoreFoundation"
> ++				AC_SUBST(KEYCHAIN_LDFLAGS)
> ++				],
> ++				AC_MSG_WARN([Security framework not found. Disabling Mac OS X  
> Keychain support.]))
> ++		;;
> ++	esac
> ++fi
> ++
> + dnl Adding -Werror to CFLAGS early prevents configure tests from  
> running.
> + dnl Add now.
> + CFLAGS="$CFLAGS $werror_flags"
> +diff -uNr ../openssh-5.0p1.orig/keychain.c ./keychain.c
> +--- ../openssh-5.0p1.orig/keychain.c	1969-12-31 16:00:00.000000000  
> -0800
> ++++ ./keychain.c	2008-04-15 18:32:47.000000000 -0700
> +@@ -0,0 +1,675 @@
> ++/*
> ++ * Copyright (c) 2007 Apple Inc. All rights reserved.
> ++ *
> ++ * @APPLE_BSD_LICENSE_HEADER_START@
> ++ *
> ++ * Redistribution and use in source and binary forms, with or  
> without
> ++ * modification, are permitted provided that the following  
> conditions
> ++ * are met:
> ++ *
> ++ * 1.  Redistributions of source code must retain the above  
> copyright
> ++ *     notice, this list of conditions and the following disclaimer.
> ++ * 2.  Redistributions in binary form must reproduce the above  
> copyright
> ++ *     notice, this list of conditions and the following  
> disclaimer in the
> ++ *     documentation and/or other materials provided with the  
> distribution.
> ++ * 3.  Neither the name of Apple Inc. ("Apple") nor the names of its
> ++ *     contributors may be used to endorse or promote products  
> derived from
> ++ *     this software without specific prior written permission.
> ++ *
> ++ * THIS SOFTWARE IS PROVIDED BY APPLE AND ITS CONTRIBUTORS "AS IS"  
> AND ANY
> ++ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,  
> THE IMPLIED
> ++ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR  
> PURPOSE ARE
> ++ * DISCLAIMED. IN NO EVENT SHALL APPLE OR ITS CONTRIBUTORS BE  
> LIABLE FOR ANY
> ++ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR  
> CONSEQUENTIAL DAMAGES
> ++ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS  
> OR SERVICES;
> ++ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)  
> HOWEVER CAUSED AND
> ++ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT  
> LIABILITY, OR TORT
> ++ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF  
> THE USE OF
> ++ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> ++ *
> ++ * @APPLE_BSD_LICENSE_HEADER_END@
> ++ */
> ++
> ++#include "includes.h"
> ++
> ++#include <stdio.h>
> ++#include <string.h>
> ++
> ++#include "xmalloc.h"
> ++#include "key.h"
> ++#include "authfd.h"
> ++
> ++#if defined(__APPLE_KEYCHAIN__)
> ++
> ++#include <CoreFoundation/CoreFoundation.h>
> ++#include <Security/Security.h>
> ++#include <Security/SecPassword.h>
> ++
> ++#endif
> ++
> ++/*
> ++ * Platform-specific helper functions.
> ++ */
> ++
> ++#if defined(__APPLE_KEYCHAIN__)
> ++
> ++static int get_boolean_preference(const char *key, int  
> default_value,
> ++    int foreground)
> ++{
> ++	int value = default_value;
> ++	CFStringRef keyRef = NULL;
> ++	CFPropertyListRef valueRef = NULL;
> ++
> ++	keyRef = CFStringCreateWithCString(NULL, key,  
> kCFStringEncodingUTF8);
> ++	if (keyRef != NULL)
> ++		valueRef = CFPreferencesCopyAppValue(keyRef,
> ++		    CFSTR("org.openbsd.openssh"));
> ++	if (valueRef != NULL)
> ++		if (CFGetTypeID(valueRef) == CFBooleanGetTypeID())
> ++			value = CFBooleanGetValue(valueRef);
> ++		else if (foreground)
> ++			fprintf(stderr, "Ignoring nonboolean %s preference.\n", key);
> ++
> ++	if (keyRef)
> ++		CFRelease(keyRef);
> ++	if (valueRef)
> ++		CFRelease(valueRef);
> ++
> ++	return value;
> ++}
> ++
> ++#endif
> ++
> ++/*
> ++ * Store the passphrase for a given identity in the keychain.
> ++ */
> ++void
> ++store_in_keychain(const char *filename, const char *passphrase)
> ++{
> ++
> ++#if defined(__APPLE_KEYCHAIN__)
> ++
> ++	/*
> ++	 * store_in_keychain
> ++	 * Mac OS X implementation
> ++	 */
> ++
> ++	CFStringRef cfstr_relative_filename = NULL;
> ++	CFURLRef cfurl_relative_filename = NULL, cfurl_filename = NULL;
> ++	CFStringRef cfstr_filename = NULL;
> ++	CFDataRef cfdata_filename = NULL;
> ++	CFIndex filename_len;
> ++	UInt8 *label = NULL;
> ++	UInt8 *utf8_filename;
> ++	OSStatus rv;
> ++	SecKeychainItemRef itemRef = NULL;
> ++	SecTrustedApplicationRef apps[] = {NULL, NULL, NULL};
> ++	CFArrayRef trustedlist = NULL;
> ++	SecAccessRef initialAccess = NULL;
> ++
> ++	/* Bail out if KeychainIntegration preference is -bool NO */
> ++	if (get_boolean_preference("KeychainIntegration", 1, 1) == 0) {
> ++		fprintf(stderr, "Keychain integration is disabled.\n");
> ++		goto err;
> ++	}
> ++
> ++	/* Interpret filename with the correct encoding. */
> ++	if ((cfstr_relative_filename =
> ++	    CFStringCreateWithFileSystemRepresentation(NULL, filename))  
> == NULL)
> ++	    {
> ++		fprintf(stderr, "CFStringCreateWithFileSystemRepresentation  
> failed\n");
> ++		goto err;
> ++	}
> ++	if ((cfurl_relative_filename = CFURLCreateWithFileSystemPath(NULL,
> ++	    cfstr_relative_filename, kCFURLPOSIXPathStyle, false)) ==  
> NULL) {
> ++		fprintf(stderr, "CFURLCreateWithFileSystemPath failed\n");
> ++		goto err;
> ++	}
> ++	if ((cfurl_filename =  
> CFURLCopyAbsoluteURL(cfurl_relative_filename)) ==
> ++	    NULL) {
> ++		fprintf(stderr, "CFURLCopyAbsoluteURL failed\n");
> ++		goto err;
> ++	}
> ++	if ((cfstr_filename = CFURLCopyFileSystemPath(cfurl_filename,
> ++	    kCFURLPOSIXPathStyle)) == NULL) {
> ++		fprintf(stderr, "CFURLCopyFileSystemPath failed\n");
> ++		goto err;
> ++	}
> ++	if ((cfdata_filename = CFStringCreateExternalRepresentation(NULL,
> ++	    cfstr_filename, kCFStringEncodingUTF8, 0)) == NULL) {
> ++		fprintf(stderr, "CFStringCreateExternalRepresentation failed\n");
> ++		goto err;
> ++	}
> ++	filename_len = CFDataGetLength(cfdata_filename);
> ++	if ((label = xmalloc(filename_len + 5)) == NULL) {
> ++		fprintf(stderr, "xmalloc failed\n");
> ++		goto err;
> ++	}
> ++	memcpy(label, "SSH: ", 5);
> ++	utf8_filename = label + 5;
> ++	CFDataGetBytes(cfdata_filename, CFRangeMake(0, filename_len),
> ++	    utf8_filename);
> ++
> ++	/* Check if we already have this passphrase. */
> ++	rv = SecKeychainFindGenericPassword(NULL, 3, "SSH", filename_len,
> ++	    (char *)utf8_filename, NULL, NULL, &itemRef);
> ++	if (rv == errSecItemNotFound) {
> ++		/* Add a new keychain item. */
> ++		SecKeychainAttribute attrs[] = {
> ++			{kSecLabelItemAttr, filename_len + 5, label},
> ++			{kSecServiceItemAttr, 3, "SSH"},
> ++			{kSecAccountItemAttr, filename_len, utf8_filename}
> ++		};
> ++		SecKeychainAttributeList attrList =
> ++		    {sizeof(attrs) / sizeof(attrs[0]), attrs};
> ++		if (SecTrustedApplicationCreateFromPath("/opt/local/bin/ssh- 
> agent",
> ++		    &apps[0]) != noErr ||
> ++		    SecTrustedApplicationCreateFromPath("/opt/local/bin/ssh-add",
> ++		    &apps[1]) != noErr ||
> ++		    SecTrustedApplicationCreateFromPath("/opt/local/bin/ssh",
> ++		    &apps[2]) != noErr) {
> ++			fprintf(stderr, "SecTrustedApplicationCreateFromPath failed\n");
> ++			goto err;
> ++		}
> ++		if ((trustedlist = CFArrayCreate(NULL, (const void **)apps,
> ++		    sizeof(apps) / sizeof(apps[0]), &kCFTypeArrayCallBacks)) ==
> ++		    NULL) {
> ++			fprintf(stderr, "CFArrayCreate failed\n");
> ++			goto err;
> ++		}
> ++		if (SecAccessCreate(cfstr_filename, trustedlist,
> ++		    &initialAccess) != noErr) {
> ++			fprintf(stderr, "SecAccessCreate failed\n");
> ++			goto err;
> ++		}
> ++		if (SecKeychainItemCreateFromContent(
> ++		    kSecGenericPasswordItemClass, &attrList, strlen(passphrase),
> ++		    passphrase, NULL, initialAccess, NULL) == noErr)
> ++			fprintf(stderr, "Passphrase stored in keychain: %s\n", filename);
> ++		else
> ++			fprintf(stderr, "Could not create keychain item\n");
> ++	} else if (rv == noErr) {
> ++		/* Update an existing keychain item. */
> ++		if (SecKeychainItemModifyAttributesAndData(itemRef, NULL,
> ++		    strlen(passphrase), passphrase) == noErr)
> ++			fprintf(stderr, "Passphrase updated in keychain: %s\n",  
> filename);
> ++		else
> ++			fprintf(stderr, "Could not modify keychain item\n");
> ++	} else
> ++		fprintf(stderr, "Could not access keychain\n");
> ++
> ++err:	/* Clean up. */
> ++	if (cfstr_relative_filename)
> ++		CFRelease(cfstr_relative_filename);
> ++	if (cfurl_relative_filename)
> ++		CFRelease(cfurl_relative_filename);
> ++	if (cfurl_filename)
> ++		CFRelease(cfurl_filename);
> ++	if (cfstr_filename)
> ++		CFRelease(cfstr_filename);
> ++	if (cfdata_filename)
> ++		CFRelease(cfdata_filename);
> ++	if (label)
> ++		xfree(label);
> ++	if (itemRef)
> ++		CFRelease(itemRef);
> ++	if (apps[0])
> ++		CFRelease(apps[0]);
> ++	if (apps[1])
> ++		CFRelease(apps[1]);
> ++	if (apps[2])
> ++		CFRelease(apps[2]);
> ++	if (trustedlist)
> ++		CFRelease(trustedlist);
> ++	if (initialAccess)
> ++		CFRelease(initialAccess);
> ++
> ++#else
> ++
> ++	/*
> ++	 * store_in_keychain
> ++	 * no keychain implementation
> ++	 */
> ++
> ++	fprintf(stderr, "Keychain is not available on this system\n");
> ++
> ++#endif
> ++
> ++}
> ++
> ++/*
> ++ * Remove the passphrase for a given identity from the keychain.
> ++ */
> ++void
> ++remove_from_keychain(const char *filename)
> ++{
> ++
> ++#if defined(__APPLE_KEYCHAIN__)
> ++
> ++	/*
> ++	 * remove_from_keychain
> ++	 * Mac OS X implementation
> ++	 */
> ++
> ++	CFStringRef cfstr_relative_filename = NULL;
> ++	CFURLRef cfurl_relative_filename = NULL, cfurl_filename = NULL;
> ++	CFStringRef cfstr_filename = NULL;
> ++	CFDataRef cfdata_filename = NULL;
> ++	CFIndex filename_len;
> ++	const UInt8 *utf8_filename;
> ++	OSStatus rv;
> ++	SecKeychainItemRef itemRef = NULL;
> ++
> ++	/* Bail out if KeychainIntegration preference is -bool NO */
> ++	if (get_boolean_preference("KeychainIntegration", 1, 1) == 0) {
> ++		fprintf(stderr, "Keychain integration is disabled.\n");
> ++		goto err;
> ++	}
> ++
> ++	/* Interpret filename with the correct encoding. */
> ++	if ((cfstr_relative_filename =
> ++	    CFStringCreateWithFileSystemRepresentation(NULL, filename))  
> == NULL)
> ++	    {
> ++		fprintf(stderr, "CFStringCreateWithFileSystemRepresentation  
> failed\n");
> ++		goto err;
> ++	}
> ++	if ((cfurl_relative_filename = CFURLCreateWithFileSystemPath(NULL,
> ++	    cfstr_relative_filename, kCFURLPOSIXPathStyle, false)) ==  
> NULL) {
> ++		fprintf(stderr, "CFURLCreateWithFileSystemPath failed\n");
> ++		goto err;
> ++	}
> ++	if ((cfurl_filename =  
> CFURLCopyAbsoluteURL(cfurl_relative_filename)) ==
> ++	    NULL) {
> ++		fprintf(stderr, "CFURLCopyAbsoluteURL failed\n");
> ++		goto err;
> ++	}
> ++	if ((cfstr_filename = CFURLCopyFileSystemPath(cfurl_filename,
> ++	    kCFURLPOSIXPathStyle)) == NULL) {
> ++		fprintf(stderr, "CFURLCopyFileSystemPath failed\n");
> ++		goto err;
> ++	}
> ++	if ((cfdata_filename = CFStringCreateExternalRepresentation(NULL,
> ++	    cfstr_filename, kCFStringEncodingUTF8, 0)) == NULL) {
> ++		fprintf(stderr, "CFStringCreateExternalRepresentation failed\n");
> ++		goto err;
> ++	}
> ++	filename_len = CFDataGetLength(cfdata_filename);
> ++	utf8_filename = CFDataGetBytePtr(cfdata_filename);
> ++
> ++	/* Check if we already have this passphrase. */
> ++	rv = SecKeychainFindGenericPassword(NULL, 3, "SSH", filename_len,
> ++	    (const char *)utf8_filename, NULL, NULL, &itemRef);
> ++	if (rv == noErr) {
> ++		/* Remove the passphrase from the keychain. */
> ++		if (SecKeychainItemDelete(itemRef) == noErr)
> ++			fprintf(stderr, "Passphrase removed from keychain: %s\n",  
> filename);
> ++		else
> ++			fprintf(stderr, "Could not remove keychain item\n");
> ++	} else if (rv != errSecItemNotFound)
> ++		fprintf(stderr, "Could not access keychain\n");
> ++
> ++err:	/* Clean up. */
> ++	if (cfstr_relative_filename)
> ++		CFRelease(cfstr_relative_filename);
> ++	if (cfurl_relative_filename)
> ++		CFRelease(cfurl_relative_filename);
> ++	if (cfurl_filename)
> ++		CFRelease(cfurl_filename);
> ++	if (cfstr_filename)
> ++		CFRelease(cfstr_filename);
> ++	if (cfdata_filename)
> ++		CFRelease(cfdata_filename);
> ++	if (itemRef)
> ++		CFRelease(itemRef);
> ++
> ++#else
> ++
> ++	/*
> ++	 * remove_from_keychain
> ++	 * no keychain implementation
> ++	 */
> ++
> ++	fprintf(stderr, "Keychain is not available on this system\n");
> ++
> ++#endif
> ++
> ++}
> ++
> ++/*
> ++ * Add identities to ssh-agent using passphrases stored in the  
> keychain.
> ++ * Returns zero on success and nonzero on failure.
> ++ * add_identity is a callback into ssh-agent.  It takes a filename  
> and a
> ++ * passphrase, and attempts to add the identity to the agent.  It  
> returns
> ++ * zero on success and nonzero on failure.
> ++ */
> ++int
> ++add_identities_using_keychain(int (*add_identity)(const char *,  
> const char *))
> ++{
> ++
> ++#if defined(__APPLE_KEYCHAIN__)
> ++
> ++	/*
> ++	 * add_identities_using_keychain
> ++	 * Mac OS X implementation
> ++	 */
> ++
> ++	OSStatus rv;
> ++	SecKeychainSearchRef searchRef;
> ++	SecKeychainItemRef itemRef;
> ++	UInt32 length;
> ++	void *data;
> ++	CFIndex maxsize;
> ++
> ++	/* Bail out if KeychainIntegration preference is -bool NO */
> ++	if (get_boolean_preference("KeychainIntegration", 1, 0) == 0)
> ++		return 0;
> ++
> ++	/* Search for SSH passphrases in the keychain */
> ++	SecKeychainAttribute attrs[] = {
> ++		{kSecServiceItemAttr, 3, "SSH"}
> ++	};
> ++	SecKeychainAttributeList attrList =
> ++	    {sizeof(attrs) / sizeof(attrs[0]), attrs};
> ++	if ((rv = SecKeychainSearchCreateFromAttributes(NULL,
> ++	    kSecGenericPasswordItemClass, &attrList, &searchRef)) != noErr)
> ++		return 0;
> ++
> ++	/* Iterate through the search results. */
> ++	while ((rv = SecKeychainSearchCopyNext(searchRef, &itemRef)) ==  
> noErr) {
> ++		UInt32 tag = kSecAccountItemAttr;
> ++		UInt32 format = kSecFormatUnknown;
> ++		SecKeychainAttributeInfo info = {1, &tag, &format};
> ++		SecKeychainAttributeList *itemAttrList = NULL;
> ++		CFStringRef cfstr_filename = NULL;
> ++		char *filename = NULL;
> ++		char *passphrase = NULL;
> ++
> ++		/* Retrieve filename and passphrase. */
> ++		if ((rv = SecKeychainItemCopyAttributesAndData(itemRef, &info,
> ++		    NULL, &itemAttrList, &length, &data)) != noErr)
> ++			goto err;
> ++		if (itemAttrList->count != 1)
> ++			goto err;
> ++		cfstr_filename = CFStringCreateWithBytes(NULL,
> ++		    itemAttrList->attr->data, itemAttrList->attr->length,
> ++		    kCFStringEncodingUTF8, true);
> ++		maxsize = CFStringGetMaximumSizeOfFileSystemRepresentation(
> ++		    cfstr_filename);
> ++		if ((filename = xmalloc(maxsize)) == NULL)
> ++			goto err;
> ++		if (CFStringGetFileSystemRepresentation(cfstr_filename,
> ++		    filename, maxsize) == false)
> ++			goto err;
> ++		if ((passphrase = xmalloc(length + 1)) == NULL)
> ++			goto err;
> ++		memcpy(passphrase, data, length);
> ++		passphrase[length] = '\0';
> ++
> ++		/* Add the identity. */
> ++		add_identity(filename, passphrase);
> ++
> ++err:		/* Clean up. */
> ++		if (itemRef)
> ++			CFRelease(itemRef);
> ++		if (cfstr_filename)
> ++			CFRelease(cfstr_filename);
> ++		if (filename)
> ++			xfree(filename);
> ++		if (passphrase)
> ++			xfree(passphrase);
> ++		if (itemAttrList)
> ++			SecKeychainItemFreeAttributesAndData(itemAttrList,
> ++			    data);
> ++	}
> ++
> ++	CFRelease(searchRef);
> ++
> ++	return 0;
> ++
> ++#else
> ++
> ++	/*
> ++	 * add_identities_using_keychain
> ++	 * no implementation
> ++	 */
> ++
> ++	return 1;
> ++
> ++#endif
> ++
> ++}
> ++
> ++/*
> ++ * Prompt the user for a key's passphrase.  The user will be  
> offered the option
> ++ * of storing the passphrase in their keychain.  Returns the  
> passphrase
> ++ * (which the caller is responsible for xfreeing), or NULL if this  
> function
> ++ * fails or is not implemented.  If this function is not  
> implemented, ssh will
> ++ * fall back on the standard read_passphrase function, and the  
> user will need
> ++ * to use ssh-add -K to add their keys to the keychain.
> ++ */
> ++char *
> ++keychain_read_passphrase(const char *filename)
> ++{
> ++
> ++#if defined(__APPLE_KEYCHAIN__)
> ++
> ++	/*
> ++	 * keychain_read_passphrase
> ++	 * Mac OS X implementation
> ++	 */
> ++
> ++	CFStringRef cfstr_relative_filename = NULL;
> ++	CFURLRef cfurl_relative_filename = NULL, cfurl_filename = NULL;
> ++	CFStringRef cfstr_filename = NULL;
> ++	CFDataRef cfdata_filename = NULL;
> ++	CFIndex filename_len;
> ++	UInt8 *label = NULL;
> ++	UInt8 *utf8_filename;
> ++	SecPasswordRef passRef = NULL;
> ++	SecTrustedApplicationRef apps[] = {NULL, NULL, NULL};
> ++	CFArrayRef trustedlist = NULL;
> ++	SecAccessRef initialAccess = NULL;
> ++	CFURLRef path = NULL;
> ++	CFStringRef pathFinal = NULL;
> ++	CFURLRef bundle_url = NULL;
> ++	CFBundleRef bundle = NULL;
> ++	CFStringRef promptTemplate = NULL, prompt = NULL;
> ++	UInt32 length;
> ++	const void *data;
> ++	AuthenticationConnection *ac = NULL;
> ++	char *result = NULL;
> ++
> ++	/* Bail out if KeychainIntegration preference is -bool NO */
> ++	if (get_boolean_preference("KeychainIntegration", 1, 1) == 0)
> ++		goto err;
> ++
> ++	/* Bail out if the user set AskPassGUI preference to -bool NO */
> ++	if (get_boolean_preference("AskPassGUI", 1, 1) == 0)
> ++		goto err;
> ++
> ++	/* Bail out if we can't communicate with ssh-agent */
> ++	if ((ac = ssh_get_authentication_connection()) == NULL)
> ++		goto err;
> ++
> ++	/* Interpret filename with the correct encoding. */
> ++	if ((cfstr_relative_filename =
> ++	    CFStringCreateWithFileSystemRepresentation(NULL, filename))  
> == NULL)
> ++	    {
> ++		fprintf(stderr, "CFStringCreateWithFileSystemRepresentation  
> failed\n");
> ++		goto err;
> ++	}
> ++	if ((cfurl_relative_filename = CFURLCreateWithFileSystemPath(NULL,
> ++	    cfstr_relative_filename, kCFURLPOSIXPathStyle, false)) ==  
> NULL) {
> ++		fprintf(stderr, "CFURLCreateWithFileSystemPath failed\n");
> ++		goto err;
> ++	}
> ++	if ((cfurl_filename =  
> CFURLCopyAbsoluteURL(cfurl_relative_filename)) ==
> ++	    NULL) {
> ++		fprintf(stderr, "CFURLCopyAbsoluteURL failed\n");
> ++		goto err;
> ++	}
> ++	if ((cfstr_filename = CFURLCopyFileSystemPath(cfurl_filename,
> ++	    kCFURLPOSIXPathStyle)) == NULL) {
> ++		fprintf(stderr, "CFURLCopyFileSystemPath failed\n");
> ++		goto err;
> ++	}
> ++	if ((cfdata_filename = CFStringCreateExternalRepresentation(NULL,
> ++	    cfstr_filename, kCFStringEncodingUTF8, 0)) == NULL) {
> ++		fprintf(stderr, "CFStringCreateExternalRepresentation failed\n");
> ++		goto err;
> ++	}
> ++	filename_len = CFDataGetLength(cfdata_filename);
> ++	if ((label = xmalloc(filename_len + 5)) == NULL) {
> ++		fprintf(stderr, "xmalloc failed\n");
> ++		goto err;
> ++	}
> ++	memcpy(label, "SSH: ", 5);
> ++	utf8_filename = label + 5;
> ++	CFDataGetBytes(cfdata_filename, CFRangeMake(0, filename_len),
> ++	    utf8_filename);
> ++
> ++	/* Build a SecPasswordRef. */
> ++	SecKeychainAttribute searchAttrs[] = {
> ++		{kSecServiceItemAttr, 3, "SSH"},
> ++		{kSecAccountItemAttr, filename_len, utf8_filename}
> ++	};
> ++	SecKeychainAttributeList searchAttrList =
> ++	    {sizeof(searchAttrs) / sizeof(searchAttrs[0]), searchAttrs};
> ++	SecKeychainAttribute attrs[] = {
> ++		{kSecLabelItemAttr, filename_len + 5, label},
> ++		{kSecServiceItemAttr, 3, "SSH"},
> ++		{kSecAccountItemAttr, filename_len, utf8_filename}
> ++	};
> ++	SecKeychainAttributeList attrList =
> ++	    {sizeof(attrs) / sizeof(attrs[0]), attrs};
> ++	if (SecGenericPasswordCreate(&searchAttrList, &attrList,  
> &passRef) !=
> ++	    noErr) {
> ++		fprintf(stderr, "SecGenericPasswordCreate failed\n");
> ++		goto err;
> ++	}
> ++	if (SecTrustedApplicationCreateFromPath("/opt/local/bin/ssh- 
> agent", &apps[0])
> ++	    != noErr ||
> ++	    SecTrustedApplicationCreateFromPath("/opt/local/bin/ssh-add",  
> &apps[1])
> ++	    != noErr ||
> ++	    SecTrustedApplicationCreateFromPath("/opt/local/bin/ssh",  
> &apps[2])
> ++	    != noErr) {
> ++		fprintf(stderr, "SecTrustedApplicationCreateFromPath failed\n");
> ++		goto err;
> ++	}
> ++	if ((trustedlist = CFArrayCreate(NULL, (const void **)apps,
> ++	    sizeof(apps) / sizeof(apps[0]), &kCFTypeArrayCallBacks)) ==  
> NULL) {
> ++		fprintf(stderr, "CFArrayCreate failed\n");
> ++		goto err;
> ++	}
> ++	if (SecAccessCreate(cfstr_filename, trustedlist, &initialAccess)
> ++	    != noErr) {
> ++		fprintf(stderr, "SecAccessCreate failed\n");
> ++		goto err;
> ++	}
> ++	if (SecPasswordSetInitialAccess(passRef, initialAccess) != noErr) {
> ++		fprintf(stderr, "SecPasswordSetInitialAccess failed\n");
> ++		goto err;
> ++	}
> ++
> ++	/* Request the passphrase from the user. */
> ++	if ((path = CFURLCreateFromFileSystemRepresentation(NULL,
> ++	    (UInt8 *)filename, strlen(filename), false)) == NULL) {
> ++		fprintf(stderr, "CFURLCreateFromFileSystemRepresentation failed 
> \n");
> ++		goto err;
> ++	}
> ++	if ((pathFinal = CFURLCopyLastPathComponent(path)) == NULL) {
> ++		fprintf(stderr, "CFURLCopyLastPathComponent failed\n");
> ++		goto err;
> ++	}
> ++	if (!((bundle_url = CFURLCreateWithFileSystemPath(NULL,
> ++	    CFSTR("/System/Library/CoreServices/"), kCFURLPOSIXPathStyle,  
> true))
> ++	    != NULL && (bundle = CFBundleCreate(NULL, bundle_url)) !=  
> NULL &&
> ++	    (promptTemplate = CFCopyLocalizedStringFromTableInBundle(
> ++	    CFSTR("Enter your password for the SSH key \"%@\"."),
> ++	    CFSTR("OpenSSH"), bundle, "Text of the dialog asking the user  
> for"
> ++	    "their passphrase.  The %@ will be replaced with the filename  
> of a"
> ++	    "specific key.")) != NULL) &&
> ++	    (promptTemplate = CFStringCreateCopy(NULL,
> ++	    CFSTR("Enter your password for the SSH key \"%@\"."))) ==  
> NULL) {
> ++		fprintf(stderr, "CFStringCreateCopy failed\n");
> ++		goto err;
> ++	}
> ++	if ((prompt = CFStringCreateWithFormat(NULL, NULL, promptTemplate,
> ++	    pathFinal)) == NULL) {
> ++		fprintf(stderr, "CFStringCreateWithFormat failed\n");
> ++		goto err;
> ++	}
> ++	switch (SecPasswordAction(passRef, prompt,
> ++	    kSecPasswordGet|kSecPasswordFail, &length, &data)) {
> ++	case noErr:
> ++		result = xmalloc(length + 1);
> ++		memcpy(result, data, length);
> ++		result[length] = '\0';
> ++
> ++		/* Save password in keychain if requested. */
> ++		if (SecPasswordAction(passRef, CFSTR(""), kSecPasswordSet,
> ++		    &length, &data) == noErr)
> ++			ssh_add_from_keychain(ac);
> ++		break;
> ++	case errAuthorizationCanceled:
> ++		result = xmalloc(1);
> ++		*result = '\0';
> ++		break;
> ++	default:
> ++		goto err;
> ++	}
> ++
> ++err:	/* Clean up. */
> ++	if (cfstr_relative_filename)
> ++		CFRelease(cfstr_relative_filename);
> ++	if (cfurl_relative_filename)
> ++		CFRelease(cfurl_relative_filename);
> ++	if (cfurl_filename)
> ++		CFRelease(cfurl_filename);
> ++	if (cfstr_filename)
> ++		CFRelease(cfstr_filename);
> ++	if (cfdata_filename)
> ++		CFRelease(cfdata_filename);
> ++	if (label)
> ++		xfree(label);
> ++	if (passRef)
> ++		CFRelease(passRef);
> ++	if (apps[0])
> ++		CFRelease(apps[0]);
> ++	if (apps[1])
> ++		CFRelease(apps[1]);
> ++	if (apps[2])
> ++		CFRelease(apps[2]);
> ++	if (trustedlist)
> ++		CFRelease(trustedlist);
> ++	if (initialAccess)
> ++		CFRelease(initialAccess);
> ++	if (path)
> ++		CFRelease(path);
> ++	if (pathFinal)
> ++		CFRelease(pathFinal);
> ++	if (bundle_url)
> ++		CFRelease(bundle_url);
> ++	if (bundle)
> ++		CFRelease(bundle);
> ++	if (promptTemplate)
> ++		CFRelease(promptTemplate);
> ++	if (prompt)
> ++		CFRelease(prompt);
> ++	if (ac)
> ++		ssh_close_authentication_connection(ac);
> ++
> ++	return result;
> ++
> ++#else
> ++
> ++	/*
> ++	 * keychain_read_passphrase
> ++	 * no implementation
> ++	 */
> ++
> ++	return NULL;
> ++
> ++#endif
> ++
> ++}
> +diff -uNr ../openssh-5.0p1.orig/keychain.h ./keychain.h
> +--- ../openssh-5.0p1.orig/keychain.h	1969-12-31 16:00:00.000000000  
> -0800
> ++++ ./keychain.h	2008-04-15 18:32:47.000000000 -0700
> +@@ -0,0 +1,45 @@
> ++/*
> ++ * Copyright (c) 2007 Apple Inc. All rights reserved.
> ++ *
> ++ * @APPLE_BSD_LICENSE_HEADER_START@
> ++ *
> ++ * Redistribution and use in source and binary forms, with or  
> without
> ++ * modification, are permitted provided that the following  
> conditions
> ++ * are met:
> ++ *
> ++ * 1.  Redistributions of source code must retain the above  
> copyright
> ++ *     notice, this list of conditions and the following disclaimer.
> ++ * 2.  Redistributions in binary form must reproduce the above  
> copyright
> ++ *     notice, this list of conditions and the following  
> disclaimer in the
> ++ *     documentation and/or other materials provided with the  
> distribution.
> ++ * 3.  Neither the name of Apple Inc. ("Apple") nor the names of its
> ++ *     contributors may be used to endorse or promote products  
> derived from
> ++ *     this software without specific prior written permission.
> ++ *
> ++ * THIS SOFTWARE IS PROVIDED BY APPLE AND ITS CONTRIBUTORS "AS IS"  
> AND ANY
> ++ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,  
> THE IMPLIED
> ++ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR  
> PURPOSE ARE
> ++ * DISCLAIMED. IN NO EVENT SHALL APPLE OR ITS CONTRIBUTORS BE  
> LIABLE FOR ANY
> ++ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR  
> CONSEQUENTIAL DAMAGES
> ++ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS  
> OR SERVICES;
> ++ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)  
> HOWEVER CAUSED AND
> ++ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT  
> LIABILITY, OR TORT
> ++ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF  
> THE USE OF
> ++ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> ++ *
> ++ * @APPLE_BSD_LICENSE_HEADER_END@
> ++ */
> ++
> ++/*
> ++ * KEYCHAIN indicates that keychain functionality is present.
> ++ * KEYCHAIN_* indicates the implementation to use, and implies  
> KEYCHAIN.
> ++ */
> ++#if defined(__APPLE_KEYCHAIN__)
> ++#define KEYCHAIN
> ++#endif
> ++
> ++void	 store_in_keychain(const char *filename, const char  
> *passphrase);
> ++void	 remove_from_keychain(const char *filename);
> ++int	 add_identities_using_keychain(
> ++	     int (*add_identity)(const char *, const char *));
> ++char	*keychain_read_passphrase(const char *filename);
> +diff -uNr ../openssh-5.0p1.orig/ssh-add.0 ./ssh-add.0
> +--- ../openssh-5.0p1.orig/ssh-add.0	2008-04-03 03:01:50.000000000  
> -0700
> ++++ ./ssh-add.0	2008-04-15 18:35:24.000000000 -0700
> +@@ -1,10 +1,10 @@
> + SSH-ADD(1)                 OpenBSD Reference  
> Manual                 SSH-ADD(1)
> +
> + NAME
> +-     ssh-add - adds RSA or DSA identities to the authentication  
> agent
> ++     ssh-add -- adds RSA or DSA identities to the authentication  
> agent
> +
> + SYNOPSIS
> +-     ssh-add [-cDdLlXx] [-t life] [file ...]
> ++     ssh-add [-cDdLlXxKk] [-t life] [file ...]
> +      ssh-add -s reader
> +      ssh-add -e reader
> +
> +@@ -58,6 +58,13 @@
> +
> +      -x      Lock the agent with a password.
> +
> ++     -K      When adding identities, each passphrase will also be  
> stored in
> ++             your keychain.  When removing identities with -d,  
> each passphrase
> ++             will be removed from your keychain.
> ++
> ++     -k      Add identities to the agent using any passphrases  
> stored in your
> ++             keychain.
> ++
> + ENVIRONMENT
> +      DISPLAY and SSH_ASKPASS
> +              If ssh-add needs a passphrase, it will read the  
> passphrase from
> +diff -uNr ../openssh-5.0p1.orig/ssh-add.1 ./ssh-add.1
> +--- ../openssh-5.0p1.orig/ssh-add.1	2007-06-12 07:00:27.000000000  
> -0700
> ++++ ./ssh-add.1	2008-04-15 18:32:47.000000000 -0700
> +@@ -45,7 +45,7 @@
> + .Nd adds RSA or DSA identities to the authentication agent
> + .Sh SYNOPSIS
> + .Nm ssh-add
> +-.Op Fl cDdLlXx
> ++.Op Fl cDdLlXxKk
> + .Op Fl t Ar life
> + .Op Ar
> + .Nm ssh-add
> +@@ -121,6 +121,12 @@
> + Unlock the agent.
> + .It Fl x
> + Lock the agent with a password.
> ++.It Fl K
> ++When adding identities, each passphrase will also be stored in your
> ++keychain.  When removing identities with -d, each passphrase will be
> ++removed from your keychain.
> ++.It Fl k
> ++Add identities to the agent using any passphrases stored in your  
> keychain.
> + .El
> + .Sh ENVIRONMENT
> + .Bl -tag -width Ds
> +diff -uNr ../openssh-5.0p1.orig/ssh-add.c ./ssh-add.c
> +--- ../openssh-5.0p1.orig/ssh-add.c	2008-02-28 00:13:52.000000000  
> -0800
> ++++ ./ssh-add.c	2008-04-15 18:32:47.000000000 -0700
> +@@ -62,6 +62,7 @@
> + #include "authfile.h"
> + #include "pathnames.h"
> + #include "misc.h"
> ++#include "keychain.h"
> +
> + /* argv0 */
> + extern char *__progname;
> +@@ -93,12 +94,24 @@
> + }
> +
> + static int
> +-delete_file(AuthenticationConnection *ac, const char *filename)
> ++add_from_keychain(AuthenticationConnection *ac)
> ++{
> ++	if (ssh_add_from_keychain(ac) == 0)
> ++		return -1;
> ++
> ++	fprintf(stderr, "Added keychain identities.\n");
> ++	return 0;
> ++}
> ++
> ++static int
> ++delete_file(AuthenticationConnection *ac, int keychain, const char  
> *filename)
> + {
> + 	Key *public;
> + 	char *comment = NULL;
> + 	int ret = -1;
> +
> ++	if (keychain)
> ++		remove_from_keychain(filename);
> + 	public = key_load_public(filename, &comment);
> + 	if (public == NULL) {
> + 		printf("Bad key file %s\n", filename);
> +@@ -136,7 +149,7 @@
> + }
> +
> + static int
> +-add_file(AuthenticationConnection *ac, const char *filename)
> ++add_file(AuthenticationConnection *ac, int keychain, const char  
> *filename)
> + {
> + 	Key *private;
> + 	char *comment = NULL;
> +@@ -159,11 +172,16 @@
> +
> + 	/* At first, try empty passphrase */
> + 	private = key_load_private(filename, "", &comment);
> ++	if (keychain && private != NULL)
> ++		store_in_keychain(filename, "");
> + 	if (comment == NULL)
> + 		comment = xstrdup(filename);
> + 	/* try last */
> +-	if (private == NULL && pass != NULL)
> ++	if (private == NULL && pass != NULL) {
> + 		private = key_load_private(filename, pass, NULL);
> ++		if (keychain && private != NULL)
> ++			store_in_keychain(filename, pass);
> ++	}
> + 	if (private == NULL) {
> + 		/* clear passphrase since it did not work */
> + 		clear_pass();
> +@@ -177,8 +195,11 @@
> + 				return -1;
> + 			}
> + 			private = key_load_private(filename, pass, &comment);
> +-			if (private != NULL)
> ++			if (private != NULL) {
> ++				if (keychain)
> ++					store_in_keychain(filename, pass);
> + 				break;
> ++			}
> + 			clear_pass();
> + 			snprintf(msg, sizeof msg,
> + 			    "Bad passphrase, try again for %.200s: ", comment);
> +@@ -295,13 +316,13 @@
> + }
> +
> + static int
> +-do_file(AuthenticationConnection *ac, int deleting, char *file)
> ++do_file(AuthenticationConnection *ac, int deleting, int keychain,  
> char *file)
> + {
> + 	if (deleting) {
> +-		if (delete_file(ac, file) == -1)
> ++		if (delete_file(ac, keychain, file) == -1)
> + 			return -1;
> + 	} else {
> +-		if (add_file(ac, file) == -1)
> ++		if (add_file(ac, keychain, file) == -1)
> + 			return -1;
> + 	}
> + 	return 0;
> +@@ -324,6 +345,11 @@
> + 	fprintf(stderr, "  -s reader   Add key in smartcard reader.\n");
> + 	fprintf(stderr, "  -e reader   Remove key in smartcard reader.\n");
> + #endif
> ++#ifdef KEYCHAIN
> ++	fprintf(stderr, "  -k          Add all identities stored in your  
> keychain.\n");
> ++	fprintf(stderr, "  -K          Store passphrases in your keychain. 
> \n");
> ++	fprintf(stderr, "              With -d, remove passphrases from  
> your keychain.\n");
> ++#endif
> + }
> +
> + int
> +@@ -334,6 +360,7 @@
> + 	AuthenticationConnection *ac = NULL;
> + 	char *sc_reader_id = NULL;
> + 	int i, ch, deleting = 0, ret = 0;
> ++	int keychain = 0;
> +
> + 	/* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */
> + 	sanitise_stdfd();
> +@@ -351,7 +378,7 @@
> + 		    "Could not open a connection to your authentication agent. 
> \n");
> + 		exit(2);
> + 	}
> +-	while ((ch = getopt(argc, argv, "lLcdDxXe:s:t:")) != -1) {
> ++	while ((ch = getopt(argc, argv, "lLcdDxXe:s:kKt:")) != -1) {
> + 		switch (ch) {
> + 		case 'l':
> + 		case 'L':
> +@@ -373,6 +400,13 @@
> + 			if (delete_all(ac) == -1)
> + 				ret = 1;
> + 			goto done;
> ++		case 'k':
> ++			if (add_from_keychain(ac) == -1)
> ++				ret = 1;
> ++			goto done;
> ++		case 'K':
> ++			keychain = 1;
> ++			break;
> + 		case 's':
> + 			sc_reader_id = optarg;
> + 			break;
> +@@ -418,7 +452,7 @@
> + 			    default_files[i]);
> + 			if (stat(buf, &st) < 0)
> + 				continue;
> +-			if (do_file(ac, deleting, buf) == -1)
> ++			if (do_file(ac, deleting, keychain, buf) == -1)
> + 				ret = 1;
> + 			else
> + 				count++;
> +@@ -427,7 +461,7 @@
> + 			ret = 1;
> + 	} else {
> + 		for (i = 0; i < argc; i++) {
> +-			if (do_file(ac, deleting, argv[i]) == -1)
> ++			if (do_file(ac, deleting, keychain, argv[i]) == -1)
> + 				ret = 1;
> + 		}
> + 	}
> +diff -uNr ../openssh-5.0p1.orig/ssh-agent.c ./ssh-agent.c
> +--- ../openssh-5.0p1.orig/ssh-agent.c	2008-02-28 00:13:52.000000000  
> -0800
> ++++ ./ssh-agent.c	2008-04-15 18:32:47.000000000 -0700
> +@@ -72,9 +72,11 @@
> + #include "buffer.h"
> + #include "key.h"
> + #include "authfd.h"
> ++#include "authfile.h"
> + #include "compat.h"
> + #include "log.h"
> + #include "misc.h"
> ++#include "keychain.h"
> +
> + #ifdef SMARTCARD
> + #include "scard.h"
> +@@ -703,6 +705,61 @@
> + }
> + #endif /* SMARTCARD */
> +
> ++static int
> ++add_identity_callback(const char *filename, const char *passphrase)
> ++{
> ++	Key *k;
> ++	int version;
> ++	Idtab *tab;
> ++
> ++	if ((k = key_load_private(filename, passphrase, NULL)) == NULL)
> ++		return 1;
> ++	switch (k->type) {
> ++	case KEY_RSA:
> ++	case KEY_RSA1:
> ++		if (RSA_blinding_on(k->rsa, NULL) != 1) {
> ++			key_free(k);
> ++			return 1;
> ++		}
> ++		break;
> ++	}
> ++	version = k->type == KEY_RSA1 ? 1 : 2;
> ++	tab = idtab_lookup(version);
> ++	if (lookup_identity(k, version) == NULL) {
> ++		Identity *id = xmalloc(sizeof(Identity));
> ++		id->key = k;
> ++		id->comment = xstrdup(filename);
> ++		if (id->comment == NULL) {
> ++			key_free(k);
> ++			return 1;
> ++		}
> ++		id->death = 0;
> ++		id->confirm = 0;
> ++		TAILQ_INSERT_TAIL(&tab->idlist, id, next);
> ++		tab->nentries++;
> ++	} else {
> ++		key_free(k);
> ++		return 1;
> ++	}
> ++
> ++	return 0;
> ++}
> ++
> ++static void
> ++process_add_from_keychain(SocketEntry *e)
> ++{
> ++	int result;
> ++
> ++	result = add_identities_using_keychain(&add_identity_callback);
> ++
> ++	/* e will be NULL when ssh-agent adds keys on its own at startup */
> ++	if (e) {
> ++		buffer_put_int(&e->output, 1);
> ++		buffer_put_char(&e->output,
> ++		    result ? SSH_AGENT_FAILURE : SSH_AGENT_SUCCESS);
> ++	}
> ++}
> ++
> + /* dispatch incoming messages */
> +
> + static void
> +@@ -795,6 +852,9 @@
> + 		process_remove_smartcard_key(e);
> + 		break;
> + #endif /* SMARTCARD */
> ++	case SSH_AGENTC_ADD_FROM_KEYCHAIN:
> ++		process_add_from_keychain(e);
> ++		break;
> + 	default:
> + 		/* Unknown message.  Respond with failure. */
> + 		error("Unknown message %d", type);
> +@@ -1258,6 +1318,10 @@
> + 	signal(SIGTERM, cleanup_handler);
> + 	nalloc = 0;
> +
> ++#ifdef KEYCHAIN
> ++	process_add_from_keychain(NULL);
> ++#endif
> ++
> + 	while (1) {
> + 		prepare_select(&readsetp, &writesetp, &max_fd, &nalloc, &tvp);
> + 		result = select(max_fd + 1, readsetp, writesetp, NULL, tvp);
> +diff -uNr ../openssh-5.0p1.orig/sshconnect1.c ./sshconnect1.c
> +--- ../openssh-5.0p1.orig/sshconnect1.c	2006-11-07  
> 04:14:42.000000000 -0800
> ++++ ./sshconnect1.c	2008-04-15 18:32:47.000000000 -0700
> +@@ -47,6 +47,7 @@
> + #include "canohost.h"
> + #include "hostfile.h"
> + #include "auth.h"
> ++#include "keychain.h"
> +
> + /* Session id for the current session. */
> + u_char session_id[16];
> +@@ -260,7 +261,9 @@
> + 		snprintf(buf, sizeof(buf),
> + 		    "Enter passphrase for RSA key '%.100s': ", comment);
> + 		for (i = 0; i < options.number_of_password_prompts; i++) {
> +-			passphrase = read_passphrase(buf, 0);
> ++			passphrase = keychain_read_passphrase(comment);
> ++			if (passphrase == NULL)
> ++				passphrase = read_passphrase(buf, 0);
> + 			if (strcmp(passphrase, "") != 0) {
> + 				private = key_load_private_type(KEY_RSA1,
> + 				    authfile, passphrase, NULL, NULL);
> +diff -uNr ../openssh-5.0p1.orig/sshconnect2.c ./sshconnect2.c
> +--- ../openssh-5.0p1.orig/sshconnect2.c	2008-02-10  
> 03:25:53.000000000 -0800
> ++++ ./sshconnect2.c	2008-04-15 18:32:47.000000000 -0700
> +@@ -64,6 +64,7 @@
> + #include "msg.h"
> + #include "pathnames.h"
> + #include "uidswap.h"
> ++#include "keychain.h"
> +
> + #ifdef GSSAPI
> + #include "ssh-gss.h"
> +@@ -990,7 +991,9 @@
> + 		snprintf(prompt, sizeof prompt,
> + 		    "Enter passphrase for key '%.100s': ", filename);
> + 		for (i = 0; i < options.number_of_password_prompts; i++) {
> +-			passphrase = read_passphrase(prompt, 0);
> ++			passphrase = keychain_read_passphrase(filename);
> ++			if (passphrase == NULL)
> ++				passphrase = read_passphrase(prompt, 0);
> + 			if (strcmp(passphrase, "") != 0) {
> + 				private = key_load_private_type(KEY_UNSPEC,
> + 				    filename, passphrase, NULL, NULL);
> Added: trunk/dports/net/openssh/files/AJ-5491854- 
> fix_unsafe_usage_of_getpwuid.patch (0 => 38526)
> --- trunk/dports/net/openssh/files/AJ-5491854- 
> fix_unsafe_usage_of_getpwuid.patch	                        (rev 0)
> +++ trunk/dports/net/openssh/files/AJ-5491854- 
> fix_unsafe_usage_of_getpwuid.patch	2008-07-24 04:33:03 UTC (rev 38526)
> @@ -0,0 +1,32 @@
> +diff -ru ../openssh-4.5p1.old/ssh-add.c ./ssh-add.c
> +--- ../openssh-4.5p1.old/ssh-add.c	2006-08-31 22:38:37.000000000  
> -0700
> ++++ ./ssh-add.c	2007-09-21 13:11:56.000000000 -0700
> +@@ -402,6 +402,7 @@
> + 	if (argc == 0) {
> + 		char buf[MAXPATHLEN];
> + 		struct passwd *pw;
> ++		char *pw_dir;
> + 		struct stat st;
> + 		int count = 0;
> +
> +@@ -412,8 +413,10 @@
> + 			goto done;
> + 		}
> +
> ++		pw_dir = xstrdup(pw->pw_dir);
> ++
> + 		for (i = 0; default_files[i]; i++) {
> +-			snprintf(buf, sizeof(buf), "%s/%s", pw->pw_dir,
> ++			snprintf(buf, sizeof(buf), "%s/%s", pw_dir,
> + 			    default_files[i]);
> + 			if (stat(buf, &st) < 0)
> + 				continue;
> +@@ -424,6 +427,8 @@
> + 		}
> + 		if (count == 0)
> + 			ret = 1;
> ++
> ++		xfree(pw_dir);
> + 	} else {
> + 		for (i = 0; i < argc; i++) {
> + 			if (do_file(ac, deleting, argv[i]) == -1)
> Added: trunk/dports/net/openssh/files/ 
> DVG-3977221_manpage_tweaks.patch (0 => 38526)
> --- trunk/dports/net/openssh/files/ 
> DVG-3977221_manpage_tweaks.patch	                        (rev 0)
> +++ trunk/dports/net/openssh/files/DVG-3977221_manpage_tweaks.patch	 
> 2008-07-24 04:33:03 UTC (rev 38526)
> @@ -0,0 +1,54 @@
> +diff -uNr ../openssh-4.7p1.orig/sshd.0 ./sshd.0
> +--- ../openssh-4.7p1.orig/sshd.0	2007-09-03 23:50:10.000000000 -0700
> ++++ ./sshd.0	2007-09-05 20:44:16.000000000 -0700
> +@@ -527,8 +527,8 @@
> +
> + SEE ALSO
> +      scp(1), sftp(1), ssh(1), ssh-add(1), ssh-agent(1), ssh- 
> keygen(1),
> +-     ssh-keyscan(1), chroot(2), hosts_access(5), login.conf(5),  
> moduli(5),
> +-     sshd_config(5), inetd(8), sftp-server(8)
> ++     ssh-keyscan(1), chroot(2), hosts_access(5), sshd_config(5)
> ++     sftp-server(8)
> +
> + AUTHORS
> +      OpenSSH is a derivative of the original and free ssh 1.2.12  
> release by
> +diff -uNr ../openssh-4.7p1.orig/sshd.8 ./sshd.8
> +--- ../openssh-4.7p1.orig/sshd.8	2007-08-16 16:42:33.000000000 -0700
> ++++ ./sshd.8	2007-09-05 20:43:10.000000000 -0700
> +@@ -833,10 +833,7 @@
> + .Xr ssh-keyscan 1 ,
> + .Xr chroot 2 ,
> + .Xr hosts_access 5 ,
> +-.Xr login.conf 5 ,
> +-.Xr moduli 5 ,
> + .Xr sshd_config 5 ,
> +-.Xr inetd 8 ,
> + .Xr sftp-server 8
> + .Sh AUTHORS
> + OpenSSH is a derivative of the original and free
> +diff -uNr ../openssh-4.7p1.orig/sshd_config.0 ./sshd_config.0
> +--- ../openssh-4.7p1.orig/sshd_config.0	2007-09-03  
> 23:50:11.000000000 -0700
> ++++ ./sshd_config.0	2007-09-05 20:44:58.000000000 -0700
> +@@ -84,8 +84,7 @@
> +
> +      ChallengeResponseAuthentication
> +              Specifies whether challenge-response authentication  
> is allowed.
> +-             All authentication styles from login.conf(5) are  
> supported.  The
> +-             default is ``yes''.
> ++             The default is ``yes''.
> +
> +      Ciphers
> +              Specifies the ciphers allowed for protocol version  
> 2.  Multiple
> +diff -uNr ../openssh-4.7p1.orig/sshd_config.5 ./sshd_config.5
> +--- ../openssh-4.7p1.orig/sshd_config.5	2007-06-10  
> 21:07:13.000000000 -0700
> ++++ ./sshd_config.5	2007-09-05 20:45:25.000000000 -0700
> +@@ -167,9 +167,6 @@
> + By default, no banner is displayed.
> + .It Cm ChallengeResponseAuthentication
> + Specifies whether challenge-response authentication is allowed.
> +-All authentication styles from
> +-.Xr login.conf 5
> +-are supported.
> + The default is
> + .Dq yes .
> + .It Cm Ciphers
> Added: trunk/dports/net/openssh/files/ 
> DVG-4122722+5277818_new_EA.patch (0 => 38526)
> --- trunk/dports/net/openssh/files/ 
> DVG-4122722+5277818_new_EA.patch	                        (rev 0)
> +++ trunk/dports/net/openssh/files/DVG-4122722+5277818_new_EA.patch	 
> 2008-07-24 04:33:03 UTC (rev 38526)
> @@ -0,0 +1,537 @@
> +diff -ruN ../openssh-4.7p1/config.h.in ./config.h.in
> +--- ../openssh-4.7p1/config.h.in	2007-09-03 23:50:04.000000000 -0700
> ++++ ./config.h.in	2007-10-01 20:02:51.000000000 -0700
> +@@ -56,6 +56,18 @@
> + /* Define if your snprintf is busted */
> + #undef BROKEN_SNPRINTF
> +
> ++/* platform uses an in-memory credentials cache */
> ++#undef USE_CCAPI
> ++
> ++/* platform has a Security Authorization Session API */
> ++#undef USE_SECURITY_SESSION_API
> ++
> ++/* Define to 1 if you have the `copyfile' function. */
> ++#undef HAVE_COPYFILE
> ++
> ++/* Define to 1 if you have the <copyfile.h> header file. */
> ++#undef HAVE_COPYFILE_H
> ++
> + /* updwtmpx is broken (if present) */
> + #undef BROKEN_UPDWTMPX
> +
> +diff -ruN ../openssh-4.7p1/configure ./configure
> +--- ../openssh-4.7p1/configure	2007-09-03 23:50:09.000000000 -0700
> ++++ ./configure	2007-10-01 20:02:51.000000000 -0700
> +@@ -28390,6 +28390,259 @@
> + CFLAGS="$CFLAGS $werror_flags"
> +
> +
> ++for ac_func in copyfile
> ++do
> ++as_ac_var=`echo "ac_cv_func_$ac_func" | $as_tr_sh`
> ++echo "$as_me:$LINENO: checking for $ac_func" >&5
> ++echo $ECHO_N "checking for $ac_func... $ECHO_C" >&6
> ++if eval "test \"\${$as_ac_var+set}\" = set"; then
> ++  echo $ECHO_N "(cached) $ECHO_C" >&6
> ++else
> ++  cat >conftest.$ac_ext <<_ACEOF
> ++/* confdefs.h.  */
> ++_ACEOF
> ++cat confdefs.h >>conftest.$ac_ext
> ++cat >>conftest.$ac_ext <<_ACEOF
> ++/* end confdefs.h.  */
> ++/* Define $ac_func to an innocuous variant, in case <limits.h>  
> declares $ac_func.
> ++   For example, HP-UX 11i <limits.h> declares gettimeofday.  */
> ++#define $ac_func innocuous_$ac_func
> ++
> ++/* System header to define __stub macros and hopefully few  
> prototypes,
> ++    which can conflict with char $ac_func (); below.
> ++    Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
> ++    <limits.h> exists even on freestanding compilers.  */
> ++
> ++#ifdef __STDC__
> ++# include <limits.h>
> ++#else
> ++# include <assert.h>
> ++#endif
> ++
> ++#undef $ac_func
> ++
> ++/* Override any gcc2 internal prototype to avoid an error.  */
> ++#ifdef __cplusplus
> ++extern "C"
> ++{
> ++#endif
> ++/* We use char because int might match the return type of a gcc2
> ++   builtin and then its argument prototype would still apply.  */
> ++char $ac_func ();
> ++/* The GNU C library defines this for functions which it implements
> ++    to always fail with ENOSYS.  Some functions are actually named
> ++    something starting with __ and the normal name is an alias.  */
> ++#if defined (__stub_$ac_func) || defined (__stub___$ac_func)
> ++choke me
> ++#else
> ++char (*f) () = $ac_func;
> ++#endif
> ++#ifdef __cplusplus
> ++}
> ++#endif
> ++
> ++int
> ++main ()
> ++{
> ++return f != $ac_func;
> ++  ;
> ++  return 0;
> ++}
> ++_ACEOF
> ++rm -f conftest.$ac_objext conftest$ac_exeext
> ++if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
> ++  (eval $ac_link) 2>conftest.er1
> ++  ac_status=$?
> ++  grep -v '^ *+' conftest.er1 >conftest.err
> ++  rm -f conftest.er1
> ++  cat conftest.err >&5
> ++  echo "$as_me:$LINENO: \$? = $ac_status" >&5
> ++  (exit $ac_status); } &&
> ++	 { ac_try='test -z "$ac_c_werror_flag"
> ++			 || test ! -s conftest.err'
> ++  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
> ++  (eval $ac_try) 2>&5
> ++  ac_status=$?
> ++  echo "$as_me:$LINENO: \$? = $ac_status" >&5
> ++  (exit $ac_status); }; } &&
> ++	 { ac_try='test -s conftest$ac_exeext'
> ++  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
> ++  (eval $ac_try) 2>&5
> ++  ac_status=$?
> ++  echo "$as_me:$LINENO: \$? = $ac_status" >&5
> ++  (exit $ac_status); }; }; then
> ++  eval "$as_ac_var=yes"
> ++else
> ++  echo "$as_me: failed program was:" >&5
> ++sed 's/^/| /' conftest.$ac_ext >&5
> ++
> ++eval "$as_ac_var=no"
> ++fi
> ++rm -f conftest.err conftest.$ac_objext \
> ++      conftest$ac_exeext conftest.$ac_ext
> ++fi
> ++echo "$as_me:$LINENO: result: `eval echo '${'$as_ac_var'}'`" >&5
> ++echo "${ECHO_T}`eval echo '${'$as_ac_var'}'`" >&6
> ++if test `eval echo '${'$as_ac_var'}'` = yes; then
> ++  cat >>confdefs.h <<_ACEOF
> ++#define `echo "HAVE_$ac_func" | $as_tr_cpp` 1
> ++_ACEOF
> ++
> ++fi
> ++done
> ++
> ++
> ++for ac_header in copyfile.h
> ++do
> ++as_ac_Header=`echo "ac_cv_header_$ac_header" | $as_tr_sh`
> ++if eval "test \"\${$as_ac_Header+set}\" = set"; then
> ++  echo "$as_me:$LINENO: checking for $ac_header" >&5
> ++echo $ECHO_N "checking for $ac_header... $ECHO_C" >&6
> ++if eval "test \"\${$as_ac_Header+set}\" = set"; then
> ++  echo $ECHO_N "(cached) $ECHO_C" >&6
> ++fi
> ++echo "$as_me:$LINENO: result: `eval echo '${'$as_ac_Header'}'`" >&5
> ++echo "${ECHO_T}`eval echo '${'$as_ac_Header'}'`" >&6
> ++else
> ++  # Is the header compilable?
> ++echo "$as_me:$LINENO: checking $ac_header usability" >&5
> ++echo $ECHO_N "checking $ac_header usability... $ECHO_C" >&6
> ++cat >conftest.$ac_ext <<_ACEOF
> ++/* confdefs.h.  */
> ++_ACEOF
> ++cat confdefs.h >>conftest.$ac_ext
> ++cat >>conftest.$ac_ext <<_ACEOF
> ++/* end confdefs.h.  */
> ++$ac_includes_default
> ++#include <$ac_header>
> ++_ACEOF
> ++rm -f conftest.$ac_objext
> ++if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
> ++  (eval $ac_compile) 2>conftest.er1
> ++  ac_status=$?
> ++  grep -v '^ *+' conftest.er1 >conftest.err
> ++  rm -f conftest.er1
> ++  cat conftest.err >&5
> ++  echo "$as_me:$LINENO: \$? = $ac_status" >&5
> ++  (exit $ac_status); } &&
> ++	 { ac_try='test -z "$ac_c_werror_flag"
> ++			 || test ! -s conftest.err'
> ++  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
> ++  (eval $ac_try) 2>&5
> ++  ac_status=$?
> ++  echo "$as_me:$LINENO: \$? = $ac_status" >&5
> ++  (exit $ac_status); }; } &&
> ++	 { ac_try='test -s conftest.$ac_objext'
> ++  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
> ++  (eval $ac_try) 2>&5
> ++  ac_status=$?
> ++  echo "$as_me:$LINENO: \$? = $ac_status" >&5
> ++  (exit $ac_status); }; }; then
> ++  ac_header_compiler=yes
> ++else
> ++  echo "$as_me: failed program was:" >&5
> ++sed 's/^/| /' conftest.$ac_ext >&5
> ++
> ++ac_header_compiler=no
> ++fi
> ++rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
> ++echo "$as_me:$LINENO: result: $ac_header_compiler" >&5
> ++echo "${ECHO_T}$ac_header_compiler" >&6
> ++
> ++# Is the header present?
> ++echo "$as_me:$LINENO: checking $ac_header presence" >&5
> ++echo $ECHO_N "checking $ac_header presence... $ECHO_C" >&6
> ++cat >conftest.$ac_ext <<_ACEOF
> ++/* confdefs.h.  */
> ++_ACEOF
> ++cat confdefs.h >>conftest.$ac_ext
> ++cat >>conftest.$ac_ext <<_ACEOF
> ++/* end confdefs.h.  */
> ++#include <$ac_header>
> ++_ACEOF
> ++if { (eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\"") >&5
> ++  (eval $ac_cpp conftest.$ac_ext) 2>conftest.er1
> ++  ac_status=$?
> ++  grep -v '^ *+' conftest.er1 >conftest.err
> ++  rm -f conftest.er1
> ++  cat conftest.err >&5
> ++  echo "$as_me:$LINENO: \$? = $ac_status" >&5
> ++  (exit $ac_status); } >/dev/null; then
> ++  if test -s conftest.err; then
> ++    ac_cpp_err=$ac_c_preproc_warn_flag
> ++    ac_cpp_err=$ac_cpp_err$ac_c_werror_flag
> ++  else
> ++    ac_cpp_err=
> ++  fi
> ++else
> ++  ac_cpp_err=yes
> ++fi
> ++if test -z "$ac_cpp_err"; then
> ++  ac_header_preproc=yes
> ++else
> ++  echo "$as_me: failed program was:" >&5
> ++sed 's/^/| /' conftest.$ac_ext >&5
> ++
> ++  ac_header_preproc=no
> ++fi
> ++rm -f conftest.err conftest.$ac_ext
> ++echo "$as_me:$LINENO: result: $ac_header_preproc" >&5
> ++echo "${ECHO_T}$ac_header_preproc" >&6
> ++
> ++# So?  What about this header?
> ++case $ac_header_compiler:$ac_header_preproc: 
> $ac_c_preproc_warn_flag in
> ++  yes:no: )
> ++    { echo "$as_me:$LINENO: WARNING: $ac_header: accepted by the  
> compiler, rejected by the preprocessor!" >&5
> ++echo "$as_me: WARNING: $ac_header: accepted by the compiler,  
> rejected by the preprocessor!" >&2;}
> ++    { echo "$as_me:$LINENO: WARNING: $ac_header: proceeding with  
> the compiler's result" >&5
> ++echo "$as_me: WARNING: $ac_header: proceeding with the compiler's  
> result" >&2;}
> ++    ac_header_preproc=yes
> ++    ;;
> ++  no:yes:* )
> ++    { echo "$as_me:$LINENO: WARNING: $ac_header: present but  
> cannot be compiled" >&5
> ++echo "$as_me: WARNING: $ac_header: present but cannot be compiled"  
> >&2;}
> ++    { echo "$as_me:$LINENO: WARNING: $ac_header:     check for  
> missing prerequisite headers?" >&5
> ++echo "$as_me: WARNING: $ac_header:     check for missing  
> prerequisite headers?" >&2;}
> ++    { echo "$as_me:$LINENO: WARNING: $ac_header: see the Autoconf  
> documentation" >&5
> ++echo "$as_me: WARNING: $ac_header: see the Autoconf documentation"  
> >&2;}
> ++    { echo "$as_me:$LINENO: WARNING: $ac_header:     section  
> \"Present But Cannot Be Compiled\"" >&5
> ++echo "$as_me: WARNING: $ac_header:     section \"Present But  
> Cannot Be Compiled\"" >&2;}
> ++    { echo "$as_me:$LINENO: WARNING: $ac_header: proceeding with  
> the preprocessor's result" >&5
> ++echo "$as_me: WARNING: $ac_header: proceeding with the  
> preprocessor's result" >&2;}
> ++    { echo "$as_me:$LINENO: WARNING: $ac_header: in the future,  
> the compiler will take precedence" >&5
> ++echo "$as_me: WARNING: $ac_header: in the future, the compiler  
> will take precedence" >&2;}
> ++    (
> ++      cat <<\_ASBOX
> ++## ------------------------------------------- ##
> ++## Report this to openssh-unix-dev at mindrot.org ##
> ++## ------------------------------------------- ##
> ++_ASBOX
> ++    ) |
> ++      sed "s/^/$as_me: WARNING:     /" >&2
> ++    ;;
> ++esac
> ++echo "$as_me:$LINENO: checking for $ac_header" >&5
> ++echo $ECHO_N "checking for $ac_header... $ECHO_C" >&6
> ++if eval "test \"\${$as_ac_Header+set}\" = set"; then
> ++  echo $ECHO_N "(cached) $ECHO_C" >&6
> ++else
> ++  eval "$as_ac_Header=\$ac_header_preproc"
> ++fi
> ++echo "$as_me:$LINENO: result: `eval echo '${'$as_ac_Header'}'`" >&5
> ++echo "${ECHO_T}`eval echo '${'$as_ac_Header'}'`" >&6
> ++
> ++fi
> ++if test `eval echo '${'$as_ac_Header'}'` = yes; then
> ++  cat >>confdefs.h <<_ACEOF
> ++#define `echo "HAVE_$ac_header" | $as_tr_cpp` 1
> ++_ACEOF
> ++
> ++fi
> ++
> ++done
> ++
> ++
> ++
> + ac_config_files="$ac_config_files Makefile buildpkg.sh  
> opensshd.init openssh.xml openbsd-compat/Makefile openbsd-compat/ 
> regress/Makefile scard/Makefile ssh_prng_cmds survey.sh"
> +
> + cat >confcache <<\_ACEOF
> +diff -ruN ../openssh-4.7p1/configure.ac ./configure.ac
> +--- ../openssh-4.7p1/configure.ac	2007-08-09 21:36:12.000000000 -0700
> ++++ ./configure.ac	2007-10-01 20:02:51.000000000 -0700
> +@@ -3982,6 +3982,9 @@
> + dnl Add now.
> + CFLAGS="$CFLAGS $werror_flags"
> +
> ++AC_CHECK_FUNCS(copyfile)
> ++AC_CHECK_HEADERS(copyfile.h)
> ++
> + AC_EXEEXT
> + AC_CONFIG_FILES([Makefile buildpkg.sh opensshd.init openssh.xml \
> + 	openbsd-compat/Makefile openbsd-compat/regress/Makefile \
> +diff -ruN ../openssh-4.7p1/scp.1 ./scp.1
> +--- ../openssh-4.7p1/scp.1	2007-08-07 21:29:58.000000000 -0700
> ++++ ./scp.1	2007-10-01 20:02:51.000000000 -0700
> +@@ -20,7 +20,7 @@
> + .Sh SYNOPSIS
> + .Nm scp
> + .Bk -words
> +-.Op Fl 1246BCpqrv
> ++.Op Fl 1246BCEpqrv
> + .Op Fl c Ar cipher
> + .Op Fl F Ar ssh_config
> + .Op Fl i Ar identity_file
> +@@ -87,6 +87,8 @@
> + flag to
> + .Xr ssh 1
> + to enable compression.
> ++.It Fl E
> ++Preserves extended attributes, resource forks, and ACLs.  Requires  
> both ends to be running Mac OS X 10.4 or later.
> + .It Fl c Ar cipher
> + Selects the cipher to use for encrypting the data transfer.
> + This option is directly passed to
> +diff -ruN ../openssh-4.7p1/scp.c ./scp.c
> +--- ../openssh-4.7p1/scp.c	2007-08-07 21:29:58.000000000 -0700
> ++++ ./scp.c	2007-10-01 20:29:54.000000000 -0700
> +@@ -107,6 +107,11 @@
> + #include "misc.h"
> + #include "progressmeter.h"
> +
> ++#ifdef HAVE_COPYFILE_H
> ++#include <libgen.h>
> ++#include <copyfile.h>
> ++#endif
> ++
> + extern char *__progname;
> +
> + int do_cmd(char *host, char *remuser, char *cmd, int *fdin, int  
> *fdout);
> +@@ -134,6 +139,12 @@
> + /* This is used to store the pid of ssh_program */
> + pid_t do_cmd_pid = -1;
> +
> ++#ifdef HAVE_COPYFILE
> ++int copy_xattr = 0;
> ++int md_flag = 0;
> ++#endif
> ++
> ++
> + static void
> + killchild(int signo)
> + {
> +@@ -313,7 +324,11 @@
> + 	addargs(&args, "-oClearAllForwardings yes");
> +
> + 	fflag = tflag = 0;
> ++#if HAVE_COPYFILE
> ++	while ((ch = getopt(argc, argv, "dfl:prtvBCEc:i:P:q1246S:o:F:")) ! 
> = -1)
> ++#else
> + 	while ((ch = getopt(argc, argv, "dfl:prtvBCc:i:P:q1246S:o:F:")) ! 
> = -1)
> ++#endif
> + 		switch (ch) {
> + 		/* User-visible flags. */
> + 		case '1':
> +@@ -359,6 +374,11 @@
> + 			showprogress = 0;
> + 			break;
> +
> ++#ifdef HAVE_COPYFILE
> ++		case 'E':
> ++			copy_xattr = 1;
> ++			break;
> ++#endif
> + 		/* Server options. */
> + 		case 'd':
> + 			targetshouldbedirectory = 1;
> +@@ -408,7 +428,12 @@
> + 	remin = remout = -1;
> + 	do_cmd_pid = -1;
> + 	/* Command to be executed on remote system using "ssh". */
> ++#if HAVE_COPYFILE
> ++	(void) snprintf(cmd, sizeof cmd, "scp%s%s%s%s%s",
> ++	    copy_xattr ? " -E" : "",
> ++#else
> + 	(void) snprintf(cmd, sizeof cmd, "scp%s%s%s%s",
> ++#endif
> + 	    verbose_mode ? " -v" : "",
> + 	    iamrecursive ? " -r" : "", pflag ? " -p" : "",
> + 	    targetshouldbedirectory ? " -d" : "");
> +@@ -587,6 +612,10 @@
> + 	int fd = -1, haderr, indx;
> + 	char *last, *name, buf[2048], encname[MAXPATHLEN];
> + 	int len;
> ++#if HAVE_COPYFILE
> ++	char md_name[MAXPATHLEN];
> ++	char *md_tmp;
> ++#endif
> +
> + 	for (indx = 0; indx < argc; ++indx) {
> + 		name = argv[indx];
> +@@ -594,12 +623,26 @@
> + 		len = strlen(name);
> + 		while (len > 1 && name[len-1] == '/')
> + 			name[--len] = '\0';
> ++#if HAVE_COPYFILE
> ++md_next:
> ++		statbytes = 0;
> ++		if (md_flag) {
> ++		    fd = open(md_tmp, O_RDONLY, 0);
> ++		    unlink(md_tmp);
> ++		    free(md_tmp);
> ++		    if (fd < 0)
> ++			goto syserr;
> ++		} else {
> ++#endif
> + 		if ((fd = open(name, O_RDONLY|O_NONBLOCK, 0)) < 0)
> + 			goto syserr;
> + 		if (strchr(name, '\n') != NULL) {
> + 			strnvis(encname, name, sizeof(encname), VIS_NL);
> + 			name = encname;
> + 		}
> ++#if HAVE_COPYFILE
> ++		}
> ++#endif
> + 		if (fstat(fd, &stb) < 0) {
> + syserr:			run_err("%s: %s", name, strerror(errno));
> + 			goto next;
> +@@ -688,6 +731,36 @@
> + 		else
> + 			run_err("%s: %s", name, strerror(haderr));
> + 		(void) response();
> ++#ifdef HAVE_COPYFILE
> ++		if (copy_xattr && md_flag == 0)
> ++		{
> ++		    if (!copyfile(name, NULL, 0,
> ++			    COPYFILE_ACL | COPYFILE_XATTR | COPYFILE_CHECK))
> ++			continue;
> ++
> ++		    /*
> ++		     * this file will hold the actual metadata
> ++		     * to be transferred
> ++		     */
> ++		    md_tmp = strdup("/tmp/scp.md.XXXXXX");
> ++		    md_tmp = mktemp(md_tmp);
> ++
> ++		    if(copyfile(name, md_tmp, 0,
> ++				COPYFILE_ACL | COPYFILE_XATTR | COPYFILE_PACK) == 0)
> ++		    {
> ++			/*
> ++			 * this is the fake name to display
> ++			 */
> ++			snprintf(md_name, sizeof md_name, "%s/._%s", dirname(name),  
> basename(name));
> ++			name = md_name;
> ++			md_flag = 1;
> ++			if (verbose_mode)
> ++			    fprintf(stderr, "copyfile(%s, %s, PACK)\n", name, md_tmp);
> ++			goto md_next;
> ++		    }
> ++		} else
> ++		    md_flag = 0;
> ++#endif
> + 	}
> + }
> +
> +@@ -836,6 +909,10 @@
> + 	if (stat(targ, &stb) == 0 && S_ISDIR(stb.st_mode))
> + 		targisdir = 1;
> + 	for (first = 1;; first = 0) {
> ++#if HAVE_COPYFILE
> ++		char md_src[MAXPATHLEN];
> ++		char md_dst[MAXPATHLEN];
> ++#endif
> + 		cp = buf;
> + 		if (atomicio(read, remin, cp, 1) != 1)
> + 			return;
> +@@ -969,6 +1046,32 @@
> + 		}
> + 		omode = mode;
> + 		mode |= S_IWRITE;
> ++
> ++#if HAVE_COPYFILE
> ++		if (copy_xattr && !strncmp(basename(curfile), "._", 2))
> ++		{
> ++			int mdfd;
> ++			if (targisdir)
> ++			{
> ++			    snprintf(md_src, sizeof md_src, "%s.XXXXXX", np);
> ++			    snprintf(md_dst, sizeof md_dst, "%s/%s",
> ++				    dirname(np), basename(np) + 2);
> ++			    if((mdfd = mkstemp(md_src)) < 0)
> ++				continue;
> ++			}
> ++			else
> ++			{
> ++			    snprintf(md_src, sizeof md_src, "%s/._%s.XXXXXX",
> ++				    dirname(np), basename(np));
> ++			    snprintf(md_dst, sizeof md_dst, "%s", np);
> ++			    if((mdfd = mkstemp(md_src)) < 0)
> ++				continue;
> ++			}
> ++			if (mdfd >= 0)
> ++				close(mdfd);
> ++			np = md_src;
> ++		}
> ++#endif
> + 		if ((ofd = open(np, O_WRONLY|O_CREAT, mode)) < 0) {
> + bad:			run_err("%s: %s", np, strerror(errno));
> + 			continue;
> +@@ -1057,6 +1160,21 @@
> + 			wrerrno = errno;
> + 		}
> + 		(void) response();
> ++#ifdef HAVE_COPYFILE
> ++		if (copy_xattr && strncmp(basename(np), "._", 2) == 0)
> ++		{
> ++			if (verbose_mode)
> ++			    fprintf(stderr, "copyfile(%s, %s, UNPACK)\n", md_src,  
> md_dst);
> ++			if(!copyfile(md_src, md_dst, 0,
> ++			    COPYFILE_ACL | COPYFILE_XATTR | COPYFILE_UNPACK) < 0)
> ++			{
> ++			    snprintf(md_dst, sizeof md_dst, "%s/._%s",
> ++				    dirname(md_dst), basename(md_dst));
> ++			    rename(md_src, md_dst);
> ++			} else
> ++			    unlink(md_src);
> ++		} else
> ++#endif
> + 		if (setimes && wrerr == NO) {
> + 			setimes = 0;
> + 			if (utimes(np, tv) < 0) {
> +@@ -1118,7 +1236,11 @@
> + usage(void)
> + {
> + 	(void) fprintf(stderr,
> ++#if HAVE_COPYFILE
> ++	    "usage: scp [-1246BCEpqrv] [-c cipher] [-F ssh_config] [-i  
> identity_file]\n"
> ++#else
> + 	    "usage: scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i  
> identity_file]\n"
> ++#endif
> + 	    "           [-l limit] [-o ssh_option] [-P port] [-S program] 
> \n"
> + 	    "           [[user@]host1:]file1 ... [[user@]host2:]file2\n");
> + 	exit(1);
> Added: trunk/dports/net/openssh/files/ 
> DVG-4135812_add_SACLSupport_to_sshd_conf_manpage.patch (0 => 38526)
> --- trunk/dports/net/openssh/files/ 
> DVG 
> -4135812_add_SACLSupport_to_sshd_conf_manpage 
> .patch	                        (rev 0)
> +++ trunk/dports/net/openssh/files/ 
> DVG-4135812_add_SACLSupport_to_sshd_conf_manpage.patch	2008-07-24  
> 04:33:03 UTC (rev 38526)
> @@ -0,0 +1,25 @@
> +diff -uNr ../openssh-4.7p1.orig/sshd_config.0 ./sshd_config.0
> +--- ../openssh-4.7p1.orig/sshd_config.0	2007-09-03  
> 23:50:11.000000000 -0700
> ++++ ./sshd_config.0	2008-01-31 17:32:40.000000000 -0800
> +@@ -414,6 +414,9 @@
> +              fault is ``yes''.  This option applies to protocol  
> version 1 on-
> +              ly.
> +
> ++     SACLSupport
> ++             Enables use of Service ACLs on Mac OS X.
> ++
> +      ServerKeyBits
> +              Defines the number of bits in the ephemeral protocol  
> version 1
> +              server key.  The minimum value is 512, and the  
> default is 768.
> +diff -uNr ../openssh-4.7p1.orig/sshd_config.5 ./sshd_config.5
> +--- ../openssh-4.7p1.orig/sshd_config.5	2007-06-10  
> 21:07:13.000000000 -0700
> ++++ ./sshd_config.5	2008-01-31 17:33:17.000000000 -0800
> +@@ -722,6 +722,8 @@
> + The default is
> + .Dq yes .
> + This option applies to protocol version 1 only.
> ++.It Cm SACLSupport
> ++Enables use of Service ACLs on Mac OS X.
> + .It Cm ServerKeyBits
> + Defines the number of bits in the ephemeral protocol version 1  
> server key.
> + The minimum value is 512, and the default is 768.
> Added: trunk/dports/net/openssh/files/ 
> DVG-4157448+4920695_corrected_UsePAM_comment.patch (0 => 38526)
> --- trunk/dports/net/openssh/files/ 
> DVG 
> -4157448 
> +4920695_corrected_UsePAM_comment.patch	                        (rev  
> 0)
> +++ trunk/dports/net/openssh/files/ 
> DVG-4157448+4920695_corrected_UsePAM_comment.patch	2008-07-24  
> 04:33:03 UTC (rev 38526)
> @@ -0,0 +1,25 @@
> +diff -uNr ../openssh-4.5p1.orig/sshd_config ./sshd_config
> +--- ../openssh-4.5p1.orig/sshd_config	2006-07-23 21:06:47.000000000  
> -0700
> ++++ ./sshd_config	2007-01-11 17:05:47.000000000 -0800
> +@@ -52,7 +52,8 @@
> + # Don't read the user's ~/.rhosts and ~/.shosts files
> + #IgnoreRhosts yes
> +
> +-# To disable tunneled clear text passwords, change to no here!
> ++# To disable tunneled clear text passwords, change to no here! Also,
> ++# remember to set the UsePAM setting to 'no'.
> + #PasswordAuthentication yes
> + #PermitEmptyPasswords no
> +
> +@@ -78,7 +79,10 @@
> + # If you just want the PAM account and session checks to run without
> + # PAM authentication, then enable this but set  
> PasswordAuthentication
> + # and ChallengeResponseAuthentication to 'no'.
> +-#UsePAM no
> ++# Also, PAM will deny null passwords by default.  If you need to  
> allow
> ++# null passwords, add the "	nullok" option to the end of the
> ++# securityserver.so line in /etc/pam.d/sshd.
> ++#UsePAM yes
> +
> + #AllowTcpForwarding yes
> + #GatewayPorts no
> Added: trunk/dports/net/openssh/files/ 
> DVG-4212542_auth_error_logging_fix.patch (0 => 38526)
> --- trunk/dports/net/openssh/files/ 
> DVG-4212542_auth_error_logging_fix.patch	                         
> (rev 0)
> +++ trunk/dports/net/openssh/files/ 
> DVG-4212542_auth_error_logging_fix.patch	2008-07-24 04:33:03 UTC  
> (rev 38526)
> @@ -0,0 +1,12 @@
> +diff -uNr ../openssh-4.3p2.orig/sshd_config ./sshd_config
> +--- ../openssh-4.3p2.orig/sshd_config	2005-12-13 00:29:03.000000000  
> -0800
> ++++ ./sshd_config	2006-10-18 16:47:04.000000000 -0700
> +@@ -28,7 +28,7 @@
> +
> + # Logging
> + # obsoletes QuietMode and FascistLogging
> +-#SyslogFacility AUTH
> ++SyslogFacility AUTHPRIV
> + #LogLevel INFO
> +
> + # Authentication:
> Added: trunk/dports/net/openssh/files/ 
> DVG-4648874_preserve_EA_mtime.patch (0 => 38526)
> --- trunk/dports/net/openssh/files/ 
> DVG-4648874_preserve_EA_mtime.patch	                        (rev 0)
> +++ trunk/dports/net/openssh/files/ 
> DVG-4648874_preserve_EA_mtime.patch	2008-07-24 04:33:03 UTC (rev  
> 38526)
> @@ -0,0 +1,18 @@
> +diff -uNr ../openssh-4.5p1.orig/scp.c ./scp.c
> +--- ../openssh-4.5p1.orig/scp.c	2006-12-12 13:08:35.000000000 -0800
> ++++ ./scp.c	2006-12-12 15:53:57.000000000 -0800
> +@@ -1163,6 +1163,14 @@
> + 			    rename(md_src, md_dst);
> + 			} else
> + 			    unlink(md_src);
> ++			if (setimes && wrerr == NO) {
> ++				setimes = 0;
> ++				if (utimes(md_dst, tv) < 0) {
> ++					run_err("%s: set times: %s",
> ++					np, strerror(errno));
> ++					wrerr = DISPLAYED;
> ++				}
> ++			}
> + 		} else
> + #endif
> + 		if (setimes && wrerr == NO) {
> Added: trunk/dports/net/openssh/files/ 
> DVG-4694589_16_group_limit_fix.patch (0 => 38526)
> --- trunk/dports/net/openssh/files/ 
> DVG-4694589_16_group_limit_fix.patch	                        (rev 0)
> +++ trunk/dports/net/openssh/files/ 
> DVG-4694589_16_group_limit_fix.patch	2008-07-24 04:33:03 UTC (rev  
> 38526)
> @@ -0,0 +1,13 @@
> +diff -uNr ../openssh-4.5p1.orig/uidswap.c ./uidswap.c
> +--- ../openssh-4.5p1.orig/uidswap.c	2006-08-04 19:39:41.000000000  
> -0700
> ++++ ./uidswap.c	2007-01-12 19:26:22.000000000 -0800
> +@@ -233,6 +239,9 @@
> + 		fatal("setgid %u: %.100s", (u_int)pw->pw_gid, strerror(errno));
> + #endif
> +
> ++	if (initgroups(pw->pw_name, pw->pw_gid) < 0)
> ++		fatal("setgid %.100s %u: %.100s", pw->pw_name, (u_int)pw- 
> >pw_gid, strerror(errno));
> ++
> + #if defined(HAVE_SETRESUID) && !defined(BROKEN_SETRESUID)
> + 	if (setresuid(pw->pw_uid, pw->pw_uid, pw->pw_uid) < 0)
> + 		fatal("setresuid %u: %.100s", (u_int)pw->pw_uid, strerror(errno));
> Added: trunk/dports/net/openssh/files/DVG-4748610+4897588_ssh- 
> agent_via_launchd.patch (0 => 38526)
> --- trunk/dports/net/openssh/files/DVG-4748610+4897588_ssh- 
> agent_via_launchd.patch	                        (rev 0)
> +++ trunk/dports/net/openssh/files/DVG-4748610+4897588_ssh- 
> agent_via_launchd.patch	2008-07-24 04:33:03 UTC (rev 38526)
> @@ -0,0 +1,146 @@
> +diff -ru ../openssh-4.7p1.old/ssh-agent.c ./ssh-agent.c
> +--- ../openssh-4.7p1.old/ssh-agent.c	2007-03-21 02:45:07.000000000  
> -0700
> ++++ ./ssh-agent.c	2007-10-01 01:01:39.000000000 -0700
> +@@ -64,6 +64,9 @@
> + #include <time.h>
> + #include <string.h>
> + #include <unistd.h>
> ++#ifdef __APPLE_LAUNCHD__
> ++#include <launch.h>
> ++#endif
> +
> + #include "xmalloc.h"
> + #include "ssh.h"
> +@@ -1031,7 +1034,11 @@
> + int
> + main(int ac, char **av)
> + {
> ++#ifdef __APPLE_LAUNCHD__
> ++	int c_flag = 0, d_flag = 0, k_flag = 0, s_flag = 0, l_flag = 0;
> ++#else
> + 	int c_flag = 0, d_flag = 0, k_flag = 0, s_flag = 0;
> ++#endif
> + 	int sock, fd, ch, result, saved_errno;
> + 	u_int nalloc;
> + 	char *shell, *format, *pidstr, *agentsocket = NULL;
> +@@ -1065,7 +1072,11 @@
> + 	init_rng();
> + 	seed_rng();
> +
> ++#ifdef __APPLE_LAUNCHD__
> ++	while ((ch = getopt(ac, av, "cdklsa:t:")) != -1) {
> ++#else
> + 	while ((ch = getopt(ac, av, "cdksa:t:")) != -1) {
> ++#endif
> + 		switch (ch) {
> + 		case 'c':
> + 			if (s_flag)
> +@@ -1075,6 +1086,11 @@
> + 		case 'k':
> + 			k_flag++;
> + 			break;
> ++#ifdef __APPLE_LAUNCHD__
> ++		case 'l':
> ++			l_flag++;
> ++			break;
> ++#endif
> + 		case 's':
> + 			if (c_flag)
> + 				usage();
> +@@ -1101,7 +1117,11 @@
> + 	ac -= optind;
> + 	av += optind;
> +
> ++#ifdef __APPPLE_LAUNCHD__
> ++	if (ac > 0 && (c_flag || k_flag || s_flag || d_flag || l_flag))
> ++#else
> + 	if (ac > 0 && (c_flag || k_flag || s_flag || d_flag))
> ++#endif
> + 		usage();
> +
> + 	if (ac == 0 && !c_flag && !s_flag) {
> +@@ -1157,6 +1177,53 @@
> + 	 * Create socket early so it will exist before command gets run  
> from
> + 	 * the parent.
> + 	 */
> ++#ifdef __APPLE_LAUNCHD__
> ++	if (l_flag) {
> ++		launch_data_t resp, msg, tmp;
> ++		size_t listeners_i;
> ++
> ++		msg = launch_data_new_string(LAUNCH_KEY_CHECKIN);
> ++
> ++		resp = launch_msg(msg);
> ++
> ++		if (NULL == resp) {
> ++			perror("launch_msg");
> ++			exit(1);
> ++		}
> ++		launch_data_free(msg);
> ++		switch (launch_data_get_type(resp)) {
> ++		case LAUNCH_DATA_ERRNO:
> ++			errno = launch_data_get_errno(resp);
> ++			perror("launch_msg response");
> ++			exit(1);
> ++		case LAUNCH_DATA_DICTIONARY:
> ++			break;
> ++		default:
> ++			fprintf(stderr, "launch_msg unknown response");
> ++			exit(1);
> ++		}
> ++		tmp = launch_data_dict_lookup(resp, LAUNCH_JOBKEY_SOCKETS);
> ++
> ++		if (NULL == tmp) {
> ++			fprintf(stderr, "no sockets\n");
> ++			exit(1);
> ++		}
> ++
> ++		tmp = launch_data_dict_lookup(tmp, "Listeners");
> ++
> ++		if (NULL == tmp) {
> ++			fprintf(stderr, "no known listeners\n");
> ++			exit(1);
> ++		}
> ++
> ++		for (listeners_i = 0; listeners_i <  
> launch_data_array_get_count(tmp); listeners_i++) {
> ++			launch_data_t obj_at_ind = launch_data_array_get_index(tmp,  
> listeners_i);
> ++			new_socket(AUTH_SOCKET, launch_data_get_fd(obj_at_ind));
> ++		}
> ++
> ++		launch_data_free(resp);
> ++	} else {
> ++#endif
> + 	sock = socket(AF_UNIX, SOCK_STREAM, 0);
> + 	if (sock < 0) {
> + 		perror("socket");
> +@@ -1178,6 +1245,9 @@
> + 		perror("listen");
> + 		cleanup_exit(1);
> + 	}
> ++#ifdef __APPLE_LAUNCHD__
> ++	}
> ++#endif
> +
> + 	/*
> + 	 * Fork, and have the parent execute the command, if any, or  
> present
> +@@ -1191,6 +1261,12 @@
> + 		printf("echo Agent pid %ld;\n", (long)parent_pid);
> + 		goto skip;
> + 	}
> ++
> ++#ifdef __APPLE_LAUNCHD__
> ++	if (l_flag)
> ++	goto skip2;
> ++#endif
> ++
> + 	pid = fork();
> + 	if (pid == -1) {
> + 		perror("fork");
> +@@ -1246,6 +1322,7 @@
> +
> + skip:
> + 	new_socket(AUTH_SOCKET, sock);
> ++skip2:
> + 	if (ac > 0)
> + 		parent_alive_interval = 10;
> + 	idtab_init();
> Added: trunk/dports/net/openssh/files/ 
> DVG-4853931_enable_GSSAPI.patch (0 => 38526)
> --- trunk/dports/net/openssh/files/ 
> DVG-4853931_enable_GSSAPI.patch	                        (rev 0)
> +++ trunk/dports/net/openssh/files/DVG-4853931_enable_GSSAPI.patch	 
> 2008-07-24 04:33:03 UTC (rev 38526)
> @@ -0,0 +1,42 @@
> +diff -uNr ../openssh-4.5p1.orig/readconf.c ./readconf.c
> +--- ../openssh-4.5p1.orig/readconf.c	2006-12-05 21:05:28.000000000  
> -0800
> ++++ ./readconf.c	2006-12-05 21:10:59.000000000 -0800
> +@@ -1113,10 +1113,17 @@
> + 		options->pubkey_authentication = 1;
> + 	if (options->challenge_response_authentication == -1)
> + 		options->challenge_response_authentication = 1;
> ++#ifdef __APPLE_GSSAPI_ENABLE__
> ++	if (options->gss_authentication == -1)
> ++		options->gss_authentication = 1;
> ++	if (options->gss_keyex == -1)
> ++		options->gss_keyex = 1;
> ++#else
> + 	if (options->gss_authentication == -1)
> + 		options->gss_authentication = 0;
> + 	if (options->gss_keyex == -1)
> + 		options->gss_keyex = 0;
> ++#endif
> + 	if (options->gss_deleg_creds == -1)
> + 		options->gss_deleg_creds = 0;
> + 	if (options->gss_trust_dns == -1)
> +diff -uNr ../openssh-4.5p1.orig/servconf.c ./servconf.c
> +--- ../openssh-4.5p1.orig/servconf.c	2006-12-05 21:05:28.000000000  
> -0800
> ++++ ./servconf.c	2006-12-05 21:08:44.000000000 -0800
> +@@ -204,10 +204,17 @@
> + 		options->kerberos_ticket_cleanup = 1;
> + 	if (options->kerberos_get_afs_token == -1)
> + 		options->kerberos_get_afs_token = 0;
> ++#ifdef __APPLE_GSSAPI_ENABLE__
> ++	if (options->gss_authentication == -1)
> ++		options->gss_authentication = 1;
> ++	if (options->gss_keyex == -1)
> ++		options->gss_keyex = 1;
> ++#else
> + 	if (options->gss_authentication == -1)
> + 		options->gss_authentication = 0;
> + 	if (options->gss_keyex == -1)
> + 		options->gss_keyex = 0;
> ++#endif
> + 	if (options->gss_cleanup_creds == -1)
> + 		options->gss_cleanup_creds = 1;
> + 	if (options->gss_strict_acceptor == -1)
> Added: trunk/dports/net/openssh/files/ 
> DVG-4853931_enable_GSSAPI_for_pre-Leopard---BuildPhase.patch (0 =>  
> 38526)
> --- trunk/dports/net/openssh/files/DVG-4853931_enable_GSSAPI_for_pre- 
> Leopard---BuildPhase.patch	                        (rev 0)
> +++ trunk/dports/net/openssh/files/DVG-4853931_enable_GSSAPI_for_pre- 
> Leopard---BuildPhase.patch	2008-07-24 04:33:03 UTC (rev 38526)
> @@ -0,0 +1,69 @@
> +diff -ur ../OpenSSH-5729681~obj.orig/ssh_config.5.out ./ssh_config. 
> 5.out
> +--- ../OpenSSH-5729681~obj.orig/ssh_config.5.out	2008-02-07  
> 13:25:33.000000000 -0800
> ++++ ./ssh_config.5.out	2008-02-07 13:31:16.000000000 -0800
> +@@ -475,13 +475,13 @@
> + .It Cm GSSAPIAuthentication
> + Specifies whether user authentication based on GSSAPI is allowed.
> + The default is
> +-.Dq no .
> ++.Dq yes .
> + Note that this option applies to protocol version 2 only.
> + .It Cm GSSAPIKeyExchange
> + Specifies whether key exchange based on GSSAPI may be used. When  
> using
> + GSSAPI key exchange the server need not have a host key.
> + The default is
> +-.Dq no .
> ++.Dq yes .
> + Note that this option applies to protocol version 2 only.
> + .It Cm GSSAPIDelegateCredentials
> + Forward (delegate) credentials to the server.
> +diff -ur ../OpenSSH-5729681~obj.orig/ssh_config.out ./ssh_config.out
> +--- ../OpenSSH-5729681~obj.orig/ssh_config.out	2008-02-07  
> 13:25:32.000000000 -0800
> ++++ ./ssh_config.out	2008-02-07 13:29:57.000000000 -0800
> +@@ -24,9 +24,9 @@
> + #   RSAAuthentication yes
> + #   PasswordAuthentication yes
> + #   HostbasedAuthentication no
> +-#   GSSAPIAuthentication no
> ++#   GSSAPIAuthentication yes
> + #   GSSAPIDelegateCredentials no
> +-#   GSSAPIKeyExchange no
> ++#   GSSAPIKeyExchange yes
> + #   GSSAPITrustDNS no
> + #   BatchMode no
> + #   CheckHostIP yes
> +diff -ur ../OpenSSH-5729681~obj.orig/sshd_config.5.out ./ 
> sshd_config.5.out
> +--- ../OpenSSH-5729681~obj.orig/sshd_config.5.out	2008-02-07  
> 13:25:33.000000000 -0800
> ++++ ./sshd_config.5.out	2008-02-07 13:31:43.000000000 -0800
> +@@ -313,13 +313,13 @@
> + .It Cm GSSAPIAuthentication
> + Specifies whether user authentication based on GSSAPI is allowed.
> + The default is
> +-.Dq no .
> ++.Dq yes .
> + Note that this option applies to protocol version 2 only.
> + .It Cm GSSAPIKeyExchange
> + Specifies whether key exchange based on GSSAPI is allowed. GSSAPI  
> key exchange
> + doesn't rely on ssh keys to verify host identity.
> + The default is
> +-.Dq no .
> ++.Dq yes .
> + Note that this option applies to protocol version 2 only.
> + .It Cm GSSAPICleanupCredentials
> + Specifies whether to automatically destroy the user's credentials  
> cache
> +diff -ur ../OpenSSH-5729681~obj.orig/sshd_config.out ./ 
> sshd_config.out
> +--- ../OpenSSH-5729681~obj.orig/sshd_config.out	2008-02-07  
> 13:26:28.000000000 -0800
> ++++ ./sshd_config.out	2008-02-07 13:30:22.000000000 -0800
> +@@ -70,10 +70,10 @@
> + #KerberosGetAFSToken no
> +
> + # GSSAPI options
> +-#GSSAPIAuthentication no
> ++#GSSAPIAuthentication yes
> + #GSSAPICleanupCredentials yes
> + #GSSAPIStrictAcceptorCheck yes
> +-#GSSAPIKeyExchange no
> ++#GSSAPIKeyExchange yes
> +
> + # Set this to 'yes' to enable PAM authentication, account  
> processing,
> + # and session processing. If this is enabled, PAM authentication  
> will
> Added: trunk/dports/net/openssh/files/ 
> DVG-4920695_remove_nullok_comment_for_pre-Leopard---BuildPhase.patch  
> (0 => 38526)
> --- trunk/dports/net/openssh/files/ 
> DVG-4920695_remove_nullok_comment_for_pre-Leopard--- 
> BuildPhase.patch	                        (rev 0)
> +++ trunk/dports/net/openssh/files/ 
> DVG-4920695_remove_nullok_comment_for_pre-Leopard---BuildPhase.patch	 
> 2008-07-24 04:33:03 UTC (rev 38526)
> @@ -0,0 +1,13 @@
> +diff -uNr ../openssh-4.7p1.orig/sshd_config ./sshd_config
> +--- ../openssh-4.7p1.orig/sshd_config.out	2008-02-06  
> 10:27:36.000000000 -0800
> ++++ ./sshd_config.out	2008-02-06 10:26:39.000000000 -0800
> +@@ -83,9 +83,6 @@
> + # If you just want the PAM account and session checks to run without
> + # PAM authentication, then enable this but set  
> PasswordAuthentication
> + # and ChallengeResponseAuthentication to 'no'.
> +-# Also, PAM will deny null passwords by default.  If you need to  
> allow
> +-# null passwords, add the "	nullok" option to the end of the
> +-# securityserver.so line in /etc/pam.d/sshd.
> + #UsePAM yes
> +
> + #AllowTcpForwarding yes
> Added: trunk/dports/net/openssh/files/ 
> DVG-5142987_launchd_DISPLAY_for_X11.patch (0 => 38526)
> --- trunk/dports/net/openssh/files/ 
> DVG-5142987_launchd_DISPLAY_for_X11.patch	                         
> (rev 0)
> +++ trunk/dports/net/openssh/files/ 
> DVG-5142987_launchd_DISPLAY_for_X11.patch	2008-07-24 04:33:03 UTC  
> (rev 38526)
> @@ -0,0 +1,55 @@
> +diff -uNr ../openssh-4.5p1.orig/channels.c ./channels.c
> +--- ../openssh-4.5p1.orig/channels.c	2006-08-29 18:07:40.000000000  
> -0700
> ++++ ./channels.c	2007-04-19 18:59:28.000000000 -0700
> +@@ -2954,7 +2954,7 @@
> + }
> +
> + static int
> +-connect_local_xsocket(u_int dnr)
> ++connect_local_xsocket_path(const char *pathname)
> + {
> + 	int sock;
> + 	struct sockaddr_un addr;
> +@@ -2964,7 +2964,7 @@
> + 		error("socket: %.100s", strerror(errno));
> + 	memset(&addr, 0, sizeof(addr));
> + 	addr.sun_family = AF_UNIX;
> +-	snprintf(addr.sun_path, sizeof addr.sun_path, _PATH_UNIX_X, dnr);
> ++	strlcpy(addr.sun_path, pathname, sizeof addr.sun_path);
> + 	if (connect(sock, (struct sockaddr *)&addr, sizeof(addr)) == 0)
> + 		return sock;
> + 	close(sock);
> +@@ -2972,6 +2972,14 @@
> + 	return -1;
> + }
> +
> ++static int
> ++connect_local_xsocket(u_int dnr)
> ++{
> ++	char buf[1024];
> ++	snprintf(buf, sizeof buf, _PATH_UNIX_X, dnr);
> ++	return connect_local_xsocket_path(buf);
> ++}
> ++
> + int
> + x11_connect_display(void)
> + {
> +@@ -2994,9 +3002,18 @@
> + 	 */
> +
> + 	/*
> ++	 * Check if the display is from launchd, then...
> + 	 * Check if it is a unix domain socket.  Unix domain displays are  
> in
> + 	 * one of the following formats: unix:d[.s], :d[.s], ::d[.s]
> + 	 */
> ++	if (strncmp(display, "/tmp/launch", 11) == 0) {
> ++		sock = connect_local_xsocket_path(display);
> ++		if (sock < 0)
> ++			return -1;
> ++
> ++		/* OK, we now have a connection to the display. */
> ++		return sock;
> ++	}
> + 	if (strncmp(display, "unix:", 5) == 0 ||
> + 	    display[0] == ':') {
> + 		/* Connect to the unix domain socket. */
> Added: trunk/dports/net/openssh/files/ 
> DVG-5258734_pty_permission_fix.patch (0 => 38526)
> --- trunk/dports/net/openssh/files/ 
> DVG-5258734_pty_permission_fix.patch	                        (rev 0)
> +++ trunk/dports/net/openssh/files/ 
> DVG-5258734_pty_permission_fix.patch	2008-07-24 04:33:03 UTC (rev  
> 38526)
> @@ -0,0 +1,26 @@
> +diff -uNr ../openssh-4.5p1.orig/session.c ./session.c
> +--- ../openssh-4.5p1.orig/session.c	2006-10-23 10:01:56.000000000  
> -0700
> ++++ ./session.c	2007-06-15 11:23:17.000000000 -0700
> +@@ -1846,8 +1846,10 @@
> + 		n_bytes = packet_remaining();
> + 	tty_parse_modes(s->ttyfd, &n_bytes);
> +
> ++#ifndef __APPLE_PRIVPTY__
> + 	if (!use_privsep)
> + 		pty_setowner(s->pw, s->tty);
> ++#endif
> +
> + 	/* Set window size from the packet. */
> + 	pty_change_window_size(s->ptyfd, s->row, s->col, s->xpixel, s- 
> >ypixel);
> +@@ -2085,9 +2087,11 @@
> + 	if (s->pid != 0)
> + 		record_logout(s->pid, s->tty, s->pw->pw_name);
> +
> ++#ifndef __APPLE_PRIVPTY__
> + 	/* Release the pseudo-tty. */
> + 	if (getuid() == 0)
> + 		pty_release(s->tty);
> ++#endif
> +
> + 	/*
> + 	 * Close the server side of the socket pairs.  We must do this  
> after
> Added: trunk/dports/net/openssh/files/ 
> DVG-5462402_enable_SSH1_for_pre-Leopard---BuildPhase.patch (0 =>  
> 38526)
> --- trunk/dports/net/openssh/files/DVG-5462402_enable_SSH1_for_pre- 
> Leopard---BuildPhase.patch	                        (rev 0)
> +++ trunk/dports/net/openssh/files/DVG-5462402_enable_SSH1_for_pre- 
> Leopard---BuildPhase.patch	2008-07-24 04:33:03 UTC (rev 38526)
> @@ -0,0 +1,19 @@
> +--- ../openssh-4.7p1/sshd_config.out	2007-03-21 02:42:25.000000000  
> -0700
> ++++ ./sshd_config.out	2006-07-23 21:06:47.000000000 -0700
> +@@ -11,15 +11,11 @@
> + # default value.
> +
> + #Port 22
> ++#Protocol 2,1
> + #AddressFamily any
> + #ListenAddress 0.0.0.0
> + #ListenAddress ::
> +
> +-# Disable legacy (protocol version 1) support in the server for new
> +-# installations. In future the default will change to require  
> explicit
> +-# activation of protocol 1
> +-Protocol 2
> +-
> + # HostKey for protocol version 1
> + #HostKey /etc/ssh/ssh_host_key
> + # HostKeys for protocol version 2
> Added: trunk/dports/net/openssh/files/ 
> DVG-5755519_use_GSS_C_NO_NAME_with_gss_acquire_cred.patch (0 => 38526)
> --- trunk/dports/net/openssh/files/ 
> DVG 
> -5755519_use_GSS_C_NO_NAME_with_gss_acquire_cred 
> .patch	                        (rev 0)
> +++ trunk/dports/net/openssh/files/ 
> DVG-5755519_use_GSS_C_NO_NAME_with_gss_acquire_cred.patch	2008-07-24  
> 04:33:03 UTC (rev 38526)
> @@ -0,0 +1,12 @@
> +diff -uNr ../openssh-5.0p1.orig/gss-serv.c ./gss-serv.c
> +--- ../openssh-5.0p1.orig/gss-serv.c	2008-04-15 17:48:41.000000000  
> -0700
> ++++ ./gss-serv.c	2008-04-15 17:49:27.000000000 -0700
> +@@ -99,7 +99,7 @@
> + 		}
> +
> + 		if ((ctx->major = gss_acquire_cred(&ctx->minor,
> +-		    ctx->name, 0, oidset, GSS_C_ACCEPT, &ctx->creds,
> ++		    GSS_C_NO_NAME, 0, oidset, GSS_C_ACCEPT, &ctx->creds,
> + 		    NULL, NULL)))
> + 			ssh_gssapi_error(ctx);
> +
> Added: trunk/dports/net/openssh/files/lastlog.patch (0 => 38526)
> --- trunk/dports/net/openssh/files/ 
> lastlog.patch	                        (rev 0)
> +++ trunk/dports/net/openssh/files/lastlog.patch	2008-07-24 04:33:03  
> UTC (rev 38526)
> @@ -0,0 +1,50 @@
> +diff -uNr ../openssh-5.0p1.orig/loginrec.c ./loginrec.c
> +--- ../openssh-5.0p1.orig/loginrec.c	2007-04-28 19:10:58.000000000  
> -0700
> ++++ ./loginrec.c	2008-04-17 12:43:18.000000000 -0700
> +@@ -1456,6 +1456,38 @@
> +  **/
> +
> + #ifdef USE_LASTLOG
> ++#ifdef __APPLE_UTMPX__
> ++int
> ++lastlog_write_entry(struct logininfo *li)
> ++{
> ++	switch(li->type) {
> ++	case LTYPE_LOGIN:
> ++		return 1; /* lastlog written by pututxline */
> ++	default:
> ++		logit("lastlog_write_entry: Invalid type field");
> ++		return 0;
> ++	}
> ++}
> ++
> ++int
> ++lastlog_get_entry(struct logininfo *li)
> ++{
> ++	struct lastlogx l, *ll;
> ++
> ++	if ((ll = getlastlogxbyname(li->username, &l)) == NULL) {
> ++		memset(&l, '\0', sizeof(l));
> ++		ll = &l;
> ++	}
> ++	line_fullname(li->line, ll->ll_line, sizeof(li->line));
> ++	strlcpy(li->hostname, ll->ll_host,
> ++		MIN_SIZEOF(li->hostname, ll->ll_host));
> ++	li->tv_sec = ll->ll_tv.tv_sec;
> ++	li->tv_usec = ll->ll_tv.tv_usec;
> ++	return (1);
> ++}
> ++
> ++#else /* !__APPLE_UTMPX__ */
> ++
> + #define LL_FILE 1
> + #define LL_DIR 2
> + #define LL_OTHER 3
> +@@ -1613,6 +1645,7 @@
> + 	/* NOTREACHED */
> + 	return (0);
> + }
> ++#endif /* __APPLE_UTMPX__ */
> + #endif /* USE_LASTLOG */
> +
> + #ifdef USE_BTMP
> Added: trunk/dports/net/openssh/files/openssh-5.0p1- 
> gsskex-20080404.patch (0 => 38526)
> --- trunk/dports/net/openssh/files/openssh-5.0p1- 
> gsskex-20080404.patch	                        (rev 0)
> +++ trunk/dports/net/openssh/files/openssh-5.0p1- 
> gsskex-20080404.patch	2008-07-24 04:33:03 UTC (rev 38526)
> @@ -0,0 +1,2295 @@
> +? gss-genr.c.pre14
> +? kex.c.pre14
> +? kex.h.pre14
> +? kexgssc.c.pre14
> +? kexgsss.c.pre14
> +? monitor.c.pre14
> +? new.patch
> +? ssh-gss.h.pre14
> +? sshconnect2.c.pre14
> +? sshd.c.pre14
> +Index: ChangeLog.gssapi
> +===================================================================
> +RCS file: ChangeLog.gssapi
> +diff -N ChangeLog.gssapi
> +--- /dev/null	1 Jan 1970 00:00:00 -0000
> ++++ ChangeLog.gssapi	4 Apr 2008 12:52:27 -0000
> +@@ -0,0 +1,75 @@
> ++20080404
> ++  - [ gss-serv.c ]
> ++    Add code to actually implement GSSAPIStrictAcceptCheck, which  
> had somehow
> ++    been omitted from a previous version of this patch. Reported  
> by Borislav
> ++    Stoichkov
> ++
> ++20070317
> ++  - [ gss-serv-krb5.c ]
> ++    Remove C99ism, where new_ccname was being declared in the  
> middle of a
> ++    function
> ++
> ++20061220
> ++  - [ servconf.c ]
> ++    Make default for GSSAPIStrictAcceptorCheck be Yes, to match  
> previous, and
> ++    documented, behaviour. Reported by Dan Watson.
> ++
> ++20060910
> ++  - [ gss-genr.c kexgssc.c kexgsss.c kex.h monitor.c sshconnect2.c  
> sshd.c
> ++      ssh-gss.h ]
> ++    add support for gss-group14-sha1 key exchange mechanisms
> ++  - [ gss-serv.c servconf.c servconf.h sshd_config sshd_config.5 ]
> ++    Add GSSAPIStrictAcceptorCheck option to allow the disabling of
> ++    acceptor principal checking on multi-homed machines.
> ++    <Bugzilla #928>
> ++  - [ sshd_config ssh_config ]
> ++    Add settings for GSSAPIKeyExchange and GSSAPITrustDNS to the  
> sample
> ++    configuration files
> ++  - [ kexgss.c kegsss.c sshconnect2.c sshd.c ]
> ++    Code cleanup. Replace strlen/xmalloc/snprintf sequences with  
> xasprintf()
> ++    Limit length of error messages displayed by client
> ++
> ++20060909
> ++  - [ gss-genr.c gss-serv.c ]
> ++    move ssh_gssapi_acquire_cred() and ssh_gssapi_server_ctx to be  
> server
> ++    only, where they belong
> ++    <Bugzilla #1225>
> ++
> ++20060829
> ++  - [ gss-serv-krb5.c ]
> ++    Fix CCAPI credentials cache name when creating KRB5CCNAME  
> environment
> ++    variable
> ++
> ++20060828
> ++  - [ gss-genr.c ]
> ++    Avoid Heimdal context freeing problem
> ++    <Fixed upstream 20060829>
> ++
> ++20060818
> ++  - [ gss-genr.c ssh-gss.h sshconnect2.c ]
> ++    Make sure that SPENGO is disabled
> ++    <Bugzilla #1218 - Fixed upstream 20060818>
> ++
> ++20060421
> ++  - [ gssgenr.c, sshconnect2.c ]
> ++    a few type changes (signed versus unsigned, int versus size_t)  
> to
> ++    fix compiler errors/warnings
> ++    (from jbasney AT ncsa.uiuc.edu)
> ++  - [ kexgssc.c, sshconnect2.c ]
> ++    fix uninitialized variable warnings
> ++    (from jbasney AT ncsa.uiuc.edu)
> ++  - [ gssgenr.c ]
> ++    pass oid to gss_display_status (helpful when using GSSAPI  
> mechglue)
> ++    (from jbasney AT ncsa.uiuc.edu)
> ++    <Bugzilla #1220 >
> ++  - [ gss-serv-krb5.c ]
> ++    #ifdef HAVE_GSSAPI_KRB5 should be #ifdef HAVE_GSSAPI_KRB5_H
> ++    (from jbasney AT ncsa.uiuc.edu)
> ++    <Fixed upstream 20060304>
> ++  - [ readconf.c, readconf.h, ssh_config.5, sshconnect2.c
> ++    add client-side GssapiKeyExchange option
> ++    (from jbasney AT ncsa.uiuc.edu)
> ++  - [ sshconnect2.c ]
> ++    add support for GssapiTrustDns option for gssapi-with-mic
> ++    (from jbasney AT ncsa.uiuc.edu)
> ++    <gssapi-with-mic support is Bugzilla #1008>
> +Index: Makefile.in
> +===================================================================
> +RCS file: /cvs/openssh/Makefile.in,v
> +retrieving revision 1.289
> +diff -u -r1.289 Makefile.in
> +--- Makefile.in	13 Mar 2008 01:41:31 -0000	1.289
> ++++ Makefile.in	4 Apr 2008 12:52:27 -0000
> +@@ -71,7 +71,7 @@
> + 	atomicio.o key.o dispatch.o kex.o mac.o uidswap.o uuencode.o  
> misc.o \
> + 	monitor_fdpass.o rijndael.o ssh-dss.o ssh-rsa.o dh.o kexdh.o \
> + 	kexgex.o kexdhc.o kexgexc.o scard.o msg.o progressmeter.o dns.o \
> +-	entropy.o scard-opensc.o gss-genr.o umac.o
> ++	entropy.o scard-opensc.o gss-genr.o umac.o kexgssc.o
> +
> + SSHOBJS= ssh.o readconf.o clientloop.o sshtty.o \
> + 	sshconnect.o sshconnect1.o sshconnect2.o
> +@@ -84,7 +84,7 @@
> + 	auth2-none.o auth2-passwd.o auth2-pubkey.o \
> + 	monitor_mm.o monitor.o monitor_wrap.o kexdhs.o kexgexs.o \
> + 	auth-krb5.o \
> +-	auth2-gss.o gss-serv.o gss-serv-krb5.o \
> ++	auth2-gss.o gss-serv.o gss-serv-krb5.o kexgsss.o\
> + 	loginrec.o auth-pam.o auth-shadow.o auth-sia.o md5crypt.o \
> + 	audit.o audit-bsm.o platform.o sftp-server.o sftp-common.o
> +
> +Index: auth-krb5.c
> +===================================================================
> +RCS file: /cvs/openssh/auth-krb5.c,v
> +retrieving revision 1.35
> +diff -u -r1.35 auth-krb5.c
> +--- auth-krb5.c	5 Aug 2006 02:39:39 -0000	1.35
> ++++ auth-krb5.c	4 Apr 2008 12:52:28 -0000
> +@@ -166,8 +166,13 @@
> +
> + 	len = strlen(authctxt->krb5_ticket_file) + 6;
> + 	authctxt->krb5_ccname = xmalloc(len);
> ++#ifdef USE_CCAPI
> ++	snprintf(authctxt->krb5_ccname, len, "API:%s",
> ++	    authctxt->krb5_ticket_file);
> ++#else
> + 	snprintf(authctxt->krb5_ccname, len, "FILE:%s",
> + 	    authctxt->krb5_ticket_file);
> ++#endif
> +
> + #ifdef USE_PAM
> + 	if (options.use_pam)
> +@@ -219,15 +224,22 @@
> + #ifndef HEIMDAL
> + krb5_error_code
> + ssh_krb5_cc_gen(krb5_context ctx, krb5_ccache *ccache) {
> +-	int tmpfd, ret;
> ++	int ret;
> + 	char ccname[40];
> + 	mode_t old_umask;
> ++#ifdef USE_CCAPI
> ++	char cctemplate[] = "API:krb5cc_%d";
> ++#else
> ++	char cctemplate[] = "FILE:/tmp/krb5cc_%d_XXXXXXXXXX";
> ++	int tmpfd;
> ++#endif
> +
> + 	ret = snprintf(ccname, sizeof(ccname),
> +-	    "FILE:/tmp/krb5cc_%d_XXXXXXXXXX", geteuid());
> ++	    cctemplate, geteuid());
> + 	if (ret < 0 || (size_t)ret >= sizeof(ccname))
> + 		return ENOMEM;
> +
> ++#ifndef USE_CCAPI
> + 	old_umask = umask(0177);
> + 	tmpfd = mkstemp(ccname + strlen("FILE:"));
> + 	umask(old_umask);
> +@@ -242,6 +254,7 @@
> + 		return errno;
> + 	}
> + 	close(tmpfd);
> ++#endif
> +
> + 	return (krb5_cc_resolve(ctx, ccname, ccache));
> + }
> +Index: auth.h
> +===================================================================
> +RCS file: /cvs/openssh/auth.h,v
> +retrieving revision 1.78
> +diff -u -r1.78 auth.h
> +--- auth.h	26 Oct 2007 04:25:13 -0000	1.78
> ++++ auth.h	4 Apr 2008 12:52:28 -0000
> +@@ -53,6 +53,7 @@
> + 	int		 valid;		/* user exists and is allowed to login */
> + 	int		 attempt;
> + 	int		 failures;
> ++	int		 server_caused_failure;
> + 	int		 force_pwchange;
> + 	char		*user;		/* username sent by the client */
> + 	char		*service;
> +Index: auth2-gss.c
> +===================================================================
> +RCS file: /cvs/openssh/auth2-gss.c,v
> +retrieving revision 1.19
> +diff -u -r1.19 auth2-gss.c
> +--- auth2-gss.c	2 Dec 2007 11:59:45 -0000	1.19
> ++++ auth2-gss.c	4 Apr 2008 12:52:28 -0000
> +@@ -52,6 +52,39 @@
> + static void input_gssapi_exchange_complete(int type, u_int32_t  
> plen, void *ctxt);
> + static void input_gssapi_errtok(int, u_int32_t, void *);
> +
> ++/*
> ++ * The 'gssapi_keyex' userauth mechanism.
> ++ */
> ++static int
> ++userauth_gsskeyex(Authctxt *authctxt)
> ++{
> ++	int authenticated = 0;
> ++	Buffer b;
> ++	gss_buffer_desc mic, gssbuf;
> ++	u_int len;
> ++
> ++	mic.value = packet_get_string(&len);
> ++	mic.length = len;
> ++
> ++	packet_check_eom();
> ++
> ++	ssh_gssapi_buildmic(&b, authctxt->user, authctxt->service,
> ++	    "gssapi-keyex");
> ++
> ++	gssbuf.value = buffer_ptr(&b);
> ++	gssbuf.length = buffer_len(&b);
> ++
> ++	/* gss_kex_context is NULL with privsep, so we can't check it  
> here */
> ++	if (!GSS_ERROR(PRIVSEP(ssh_gssapi_checkmic(gss_kex_context,
> ++	    &gssbuf, &mic))))
> ++		authenticated = PRIVSEP(ssh_gssapi_userok(authctxt->user));
> ++	
> ++	buffer_free(&b);
> ++	xfree(mic.value);
> ++
> ++	return (authenticated);
> ++}
> ++
> + /*
> +  * We only support those mechanisms that we know about (ie ones  
> that we know
> +  * how to check local user kuserok and the like)
> +@@ -102,6 +135,7 @@
> +
> + 	if (!present) {
> + 		xfree(doid);
> ++		authctxt->server_caused_failure = 1;
> + 		return (0);
> + 	}
> +
> +@@ -109,6 +143,7 @@
> + 		if (ctxt != NULL)
> + 			ssh_gssapi_delete_ctx(&ctxt);
> + 		xfree(doid);
> ++		authctxt->server_caused_failure = 1;
> + 		return (0);
> + 	}
> +
> +@@ -291,6 +326,12 @@
> + 	dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, NULL);
> + 	userauth_finish(authctxt, authenticated, "gssapi-with-mic");
> + }
> ++
> ++Authmethod method_gsskeyex = {
> ++	"gssapi-keyex",
> ++	userauth_gsskeyex,
> ++	&options.gss_authentication
> ++};
> +
> + Authmethod method_gssapi = {
> + 	"gssapi-with-mic",
> +Index: auth2.c
> +===================================================================
> +RCS file: /cvs/openssh/auth2.c,v
> +retrieving revision 1.145
> +diff -u -r1.145 auth2.c
> +--- auth2.c	26 Oct 2007 04:26:16 -0000	1.145
> ++++ auth2.c	4 Apr 2008 12:52:28 -0000
> +@@ -64,6 +64,7 @@
> + extern Authmethod method_kbdint;
> + extern Authmethod method_hostbased;
> + #ifdef GSSAPI
> ++extern Authmethod method_gsskeyex;
> + extern Authmethod method_gssapi;
> + #endif
> +
> +@@ -71,6 +72,7 @@
> + 	&method_none,
> + 	&method_pubkey,
> + #ifdef GSSAPI
> ++	&method_gsskeyex,
> + 	&method_gssapi,
> + #endif
> + 	&method_passwd,
> +@@ -194,6 +196,7 @@
> + #endif
> +
> + 	authctxt->postponed = 0;
> ++	authctxt->server_caused_failure = 0;
> +
> + 	/* try to authenticate user */
> + 	m = authmethod_lookup(method);
> +@@ -264,7 +267,9 @@
> + 		/* now we can break out */
> + 		authctxt->success = 1;
> + 	} else {
> +-		if (authctxt->failures++ > options.max_authtries) {
> ++		/* Dont count server configuration issues against the client */
> ++		if (!authctxt->server_caused_failure &&
> ++		    authctxt->failures++ > options.max_authtries) {
> + #ifdef SSH_AUDIT_EVENTS
> + 			PRIVSEP(audit_event(SSH_LOGIN_EXCEED_MAXTRIES));
> + #endif
> +Index: configure.ac
> +===================================================================
> +RCS file: /cvs/openssh/configure.ac,v
> +retrieving revision 1.397
> +diff -u -r1.397 configure.ac
> +--- configure.ac	27 Mar 2008 01:33:07 -0000	1.397
> ++++ configure.ac	4 Apr 2008 12:52:29 -0000
> +@@ -459,6 +459,30 @@
> + 	    [Use tunnel device compatibility to OpenBSD])
> + 	AC_DEFINE(SSH_TUN_PREPEND_AF, 1,
> + 	    [Prepend the address family to IP tunnel traffic])
> ++	AC_MSG_CHECKING(if we have the Security Authorization Session API)
> ++	AC_TRY_COMPILE([#include <Security/AuthSession.h>],
> ++		[SessionCreate(0, 0);],
> ++		[ac_cv_use_security_session_api="yes"
> ++		 AC_DEFINE(USE_SECURITY_SESSION_API, 1,
> ++			[platform has the Security Authorization Session API])
> ++		 LIBS="$LIBS -framework Security"
> ++		 AC_MSG_RESULT(yes)],
> ++		[ac_cv_use_security_session_api="no"
> ++		 AC_MSG_RESULT(no)])
> ++	AC_MSG_CHECKING(if we have an in-memory credentials cache)
> ++	AC_TRY_COMPILE(
> ++		[#include <Kerberos/Kerberos.h>],
> ++		[cc_context_t c;
> ++		 (void) cc_initialize (&c, 0, NULL, NULL);],
> ++		[AC_DEFINE(USE_CCAPI, 1,
> ++			[platform uses an in-memory credentials cache])
> ++		 LIBS="$LIBS -framework Security"
> ++		 AC_MSG_RESULT(yes)
> ++		 if test "x$ac_cv_use_security_session_api" = "xno"; then
> ++			AC_MSG_ERROR(*** Need a security framework to use the  
> credentials cache API ***)
> ++		fi],
> ++		[AC_MSG_RESULT(no)]
> ++	)
> + 	m4_pattern_allow(AU_IPv)
> + 	AC_CHECK_DECL(AU_IPv4, [],
> + 	    AC_DEFINE(AU_IPv4, 0, [System only supports IPv4 audit  
> records])
> +Index: gss-genr.c
> +===================================================================
> +RCS file: /cvs/openssh/gss-genr.c,v
> +retrieving revision 1.21
> +diff -u -r1.21 gss-genr.c
> +--- gss-genr.c	12 Jun 2007 13:44:36 -0000	1.21
> ++++ gss-genr.c	4 Apr 2008 12:52:29 -0000
> +@@ -39,12 +39,160 @@
> + #include "buffer.h"
> + #include "log.h"
> + #include "ssh2.h"
> ++#include "cipher.h"
> ++#include "key.h"
> ++#include "kex.h"
> ++#include <openssl/evp.h>
> +
> + #include "ssh-gss.h"
> +
> + extern u_char *session_id2;
> + extern u_int session_id2_len;
> +
> ++typedef struct {
> ++	char *encoded;
> ++	gss_OID oid;
> ++} ssh_gss_kex_mapping;
> ++
> ++/*
> ++ * XXX - It would be nice to find a more elegant way of handling the
> ++ * XXX   passing of the key exchange context to the userauth  
> routines
> ++ */
> ++
> ++Gssctxt *gss_kex_context = NULL;
> ++
> ++static ssh_gss_kex_mapping *gss_enc2oid = NULL;
> ++
> ++int
> ++ssh_gssapi_oid_table_ok() {
> ++	return (gss_enc2oid != NULL);
> ++}
> ++
> ++/*
> ++ * Return a list of the gss-group1-sha1 mechanisms supported by  
> this program
> ++ *
> ++ * We test mechanisms to ensure that we can use them, to avoid  
> starting
> ++ * a key exchange with a bad mechanism
> ++ */
> ++
> ++char *
> ++ssh_gssapi_client_mechanisms(const char *host) {
> ++	gss_OID_set gss_supported;
> ++	OM_uint32 min_status;
> ++
> ++	gss_indicate_mechs(&min_status, &gss_supported);
> ++
> ++	return(ssh_gssapi_kex_mechs(gss_supported,  
> ssh_gssapi_check_mechanism,
> ++	    host));
> ++}
> ++
> ++char *
> ++ssh_gssapi_kex_mechs(gss_OID_set gss_supported,  
> ssh_gssapi_check_fn *check,
> ++    const char *data) {
> ++	Buffer buf;
> ++	size_t i;
> ++	int oidpos, enclen;
> ++	char *mechs, *encoded;
> ++	u_char digest[EVP_MAX_MD_SIZE];
> ++	char deroid[2];
> ++	const EVP_MD *evp_md = EVP_md5();
> ++	EVP_MD_CTX md;
> ++
> ++	if (gss_enc2oid != NULL) {
> ++		for (i = 0; gss_enc2oid[i].encoded != NULL; i++)
> ++			xfree(gss_enc2oid[i].encoded);
> ++		xfree(gss_enc2oid);
> ++	}
> ++
> ++	gss_enc2oid = xmalloc(sizeof(ssh_gss_kex_mapping) *
> ++	    (gss_supported->count + 1));
> ++
> ++	buffer_init(&buf);
> ++
> ++	oidpos = 0;
> ++	for (i = 0; i < gss_supported->count; i++) {
> ++		if (gss_supported->elements[i].length < 128 &&
> ++		    (*check)(NULL, &(gss_supported->elements[i]), data)) {
> ++
> ++			deroid[0] = SSH_GSS_OIDTYPE;
> ++			deroid[1] = gss_supported->elements[i].length;
> ++
> ++			EVP_DigestInit(&md, evp_md);
> ++			EVP_DigestUpdate(&md, deroid, 2);
> ++			EVP_DigestUpdate(&md,
> ++			    gss_supported->elements[i].elements,
> ++			    gss_supported->elements[i].length);
> ++			EVP_DigestFinal(&md, digest, NULL);
> ++
> ++			encoded = xmalloc(EVP_MD_size(evp_md) * 2);
> ++			enclen = __b64_ntop(digest, EVP_MD_size(evp_md),
> ++			    encoded, EVP_MD_size(evp_md) * 2);
> ++
> ++			if (oidpos != 0)
> ++				buffer_put_char(&buf, ',');
> ++
> ++			buffer_append(&buf, KEX_GSS_GEX_SHA1_ID,
> ++			    sizeof(KEX_GSS_GEX_SHA1_ID) - 1);
> ++			buffer_append(&buf, encoded, enclen);
> ++			buffer_put_char(&buf, ',');
> ++			buffer_append(&buf, KEX_GSS_GRP1_SHA1_ID,
> ++			    sizeof(KEX_GSS_GRP1_SHA1_ID) - 1);
> ++			buffer_append(&buf, encoded, enclen);
> ++			buffer_put_char(&buf, ',');
> ++			buffer_append(&buf, KEX_GSS_GRP14_SHA1_ID,
> ++			    sizeof(KEX_GSS_GRP14_SHA1_ID) - 1);
> ++			buffer_append(&buf, encoded, enclen);
> ++
> ++			gss_enc2oid[oidpos].oid = &(gss_supported->elements[i]);
> ++			gss_enc2oid[oidpos].encoded = encoded;
> ++			oidpos++;
> ++		}
> ++	}
> ++	gss_enc2oid[oidpos].oid = NULL;
> ++	gss_enc2oid[oidpos].encoded = NULL;
> ++
> ++	buffer_put_char(&buf, '\0');
> ++
> ++	mechs = xmalloc(buffer_len(&buf));
> ++	buffer_get(&buf, mechs, buffer_len(&buf));
> ++	buffer_free(&buf);
> ++
> ++	if (strlen(mechs) == 0) {
> ++		xfree(mechs);
> ++		mechs = NULL;
> ++	}
> ++	
> ++	return (mechs);
> ++}
> ++
> ++gss_OID
> ++ssh_gssapi_id_kex(Gssctxt *ctx, char *name, int kex_type) {
> ++	int i = 0;
> ++	
> ++	switch (kex_type) {
> ++	case KEX_GSS_GRP1_SHA1:
> ++		name += sizeof(KEX_GSS_GRP1_SHA1_ID) - 1;
> ++		break;
> ++	case KEX_GSS_GRP14_SHA1:
> ++		name += sizeof(KEX_GSS_GRP14_SHA1_ID) - 1;
> ++		break;
> ++	case KEX_GSS_GEX_SHA1:
> ++		name += sizeof(KEX_GSS_GEX_SHA1_ID) - 1;
> ++		break;
> ++	default:
> ++		return GSS_C_NO_OID;
> ++	}
> ++
> ++	while (gss_enc2oid[i].encoded != NULL &&
> ++	    strcmp(name, gss_enc2oid[i].encoded) != 0)
> ++		i++;
> ++
> ++	if (gss_enc2oid[i].oid != NULL && ctx != NULL)
> ++		ssh_gssapi_set_oid(ctx, gss_enc2oid[i].oid);
> ++
> ++	return gss_enc2oid[i].oid;
> ++}
> ++
> + /* Check that the OID in a data stream matches that in the context  
> */
> + int
> + ssh_gssapi_check_oid(Gssctxt *ctx, void *data, size_t len)
> +@@ -229,6 +377,9 @@
> + OM_uint32
> + ssh_gssapi_sign(Gssctxt *ctx, gss_buffer_t buffer, gss_buffer_t  
> hash)
> + {
> ++	if (ctx == NULL)
> ++		return -1;
> ++
> + 	if ((ctx->major = gss_get_mic(&ctx->minor, ctx->context,
> + 	    GSS_C_QOP_DEFAULT, buffer, hash)))
> + 		ssh_gssapi_error(ctx);
> +@@ -236,6 +387,19 @@
> + 	return (ctx->major);
> + }
> +
> ++/* Priviledged when used by server */
> ++OM_uint32
> ++ssh_gssapi_checkmic(Gssctxt *ctx, gss_buffer_t gssbuf,  
> gss_buffer_t gssmic)
> ++{
> ++	if (ctx == NULL)
> ++		return -1;
> ++
> ++	ctx->major = gss_verify_mic(&ctx->minor, ctx->context,
> ++	    gssbuf, gssmic, NULL);
> ++
> ++	return (ctx->major);
> ++}
> ++
> + void
> + ssh_gssapi_buildmic(Buffer *b, const char *user, const char  
> *service,
> +     const char *context)
> +@@ -254,6 +418,10 @@
> + 	gss_buffer_desc token = GSS_C_EMPTY_BUFFER;
> + 	OM_uint32 major, minor;
> + 	gss_OID_desc spnego_oid = {6, (void *)"\x2B\x06\x01\x05\x05\x02"};
> ++	Gssctxt *intctx = NULL;
> ++
> ++	if (ctx == NULL)
> ++		ctx = &intctx;
> +
> + 	/* RFC 4462 says we MUST NOT do SPNEGO */
> + 	if (oid->length == spnego_oid.length &&
> +@@ -272,7 +440,7 @@
> + 			    GSS_C_NO_BUFFER);
> + 	}
> +
> +-	if (GSS_ERROR(major))
> ++	if (GSS_ERROR(major) || intctx != NULL)
> + 		ssh_gssapi_delete_ctx(ctx);
> +
> + 	return (!GSS_ERROR(major));
> +Index: gss-serv-krb5.c
> +===================================================================
> +RCS file: /cvs/openssh/gss-serv-krb5.c,v
> +retrieving revision 1.17
> +diff -u -r1.17 gss-serv-krb5.c
> +--- gss-serv-krb5.c	1 Sep 2006 05:38:36 -0000	1.17
> ++++ gss-serv-krb5.c	4 Apr 2008 12:52:29 -0000
> +@@ -120,6 +120,7 @@
> + 	krb5_principal princ;
> + 	OM_uint32 maj_status, min_status;
> + 	int len;
> ++	const char *new_ccname;
> +
> + 	if (client->creds == NULL) {
> + 		debug("No credentials stored");
> +@@ -168,11 +169,16 @@
> + 		return;
> + 	}
> +
> +-	client->store.filename = xstrdup(krb5_cc_get_name(krb_context,  
> ccache));
> ++	new_ccname = krb5_cc_get_name(krb_context, ccache);
> ++
> + 	client->store.envvar = "KRB5CCNAME";
> +-	len = strlen(client->store.filename) + 6;
> +-	client->store.envval = xmalloc(len);
> +-	snprintf(client->store.envval, len, "FILE:%s", client- 
> >store.filename);
> ++#ifdef USE_CCAPI
> ++	xasprintf(&client->store.envval, "API:%s", new_ccname);
> ++	client->store.filename = NULL;
> ++#else
> ++	xasprintf(&client->store.envval, "FILE:%s", new_ccname);
> ++	client->store.filename = xstrdup(new_ccname);
> ++#endif
> +
> + #ifdef USE_PAM
> + 	if (options.use_pam)
> +Index: gss-serv.c
> +===================================================================
> +RCS file: /cvs/openssh/gss-serv.c,v
> +retrieving revision 1.23
> +diff -u -r1.23 gss-serv.c
> +--- gss-serv.c	12 Jun 2007 13:40:39 -0000	1.23
> ++++ gss-serv.c	4 Apr 2008 12:52:29 -0000
> +@@ -1,7 +1,7 @@
> + /* $OpenBSD: gss-serv.c,v 1.21 2007/06/12 08:20:00 djm Exp $ */
> +
> + /*
> +- * Copyright (c) 2001-2003 Simon Wilkinson. All rights reserved.
> ++ * Copyright (c) 2001-2008 Simon Wilkinson. All rights reserved.
> +  *
> +  * Redistribution and use in source and binary forms, with or  
> without
> +  * modification, are permitted provided that the following  
> conditions
> +@@ -44,8 +44,12 @@
> + #include "channels.h"
> + #include "session.h"
> + #include "misc.h"
> ++#include "servconf.h"
> +
> + #include "ssh-gss.h"
> ++#include "monitor_wrap.h"
> ++
> ++extern ServerOptions options;
> +
> + static ssh_gssapi_client gssapi_client =
> +     { GSS_C_EMPTY_BUFFER, GSS_C_EMPTY_BUFFER,
> +@@ -80,25 +84,32 @@
> + 	char lname[MAXHOSTNAMELEN];
> + 	gss_OID_set oidset;
> +
> +-	gss_create_empty_oid_set(&status, &oidset);
> +-	gss_add_oid_set_member(&status, ctx->oid, &oidset);
> ++	if (options.gss_strict_acceptor) {
> ++		gss_create_empty_oid_set(&status, &oidset);
> ++		gss_add_oid_set_member(&status, ctx->oid, &oidset);
> ++
> ++		if (gethostname(lname, MAXHOSTNAMELEN)) {
> ++			gss_release_oid_set(&status, &oidset);
> ++			return (-1);
> ++		}
> +
> +-	if (gethostname(lname, MAXHOSTNAMELEN)) {
> +-		gss_release_oid_set(&status, &oidset);
> +-		return (-1);
> +-	}
> ++		if (GSS_ERROR(ssh_gssapi_import_name(ctx, lname))) {
> ++			gss_release_oid_set(&status, &oidset);
> ++			return (ctx->major);
> ++		}
> ++
> ++		if ((ctx->major = gss_acquire_cred(&ctx->minor,
> ++		    ctx->name, 0, oidset, GSS_C_ACCEPT, &ctx->creds,
> ++		    NULL, NULL)))
> ++			ssh_gssapi_error(ctx);
> +
> +-	if (GSS_ERROR(ssh_gssapi_import_name(ctx, lname))) {
> + 		gss_release_oid_set(&status, &oidset);
> + 		return (ctx->major);
> ++	} else {
> ++		ctx->name = GSS_C_NO_NAME;
> ++		ctx->creds = GSS_C_NO_CREDENTIAL;
> + 	}
> +-
> +-	if ((ctx->major = gss_acquire_cred(&ctx->minor,
> +-	    ctx->name, 0, oidset, GSS_C_ACCEPT, &ctx->creds, NULL, NULL)))
> +-		ssh_gssapi_error(ctx);
> +-
> +-	gss_release_oid_set(&status, &oidset);
> +-	return (ctx->major);
> ++	return GSS_S_COMPLETE;
> + }
> +
> + /* Privileged */
> +@@ -113,6 +124,28 @@
> + }
> +
> + /* Unprivileged */
> ++char *
> ++ssh_gssapi_server_mechanisms() {
> ++	gss_OID_set	supported;
> ++
> ++	ssh_gssapi_supported_oids(&supported);
> ++	return (ssh_gssapi_kex_mechs(supported,  
> &ssh_gssapi_server_check_mech,
> ++	    NULL));
> ++}
> ++
> ++/* Unprivileged */
> ++int
> ++ssh_gssapi_server_check_mech(Gssctxt **dum, gss_OID oid, const  
> char *data) {
> ++	Gssctxt *ctx = NULL;
> ++	int res;
> ++
> ++	res = !GSS_ERROR(PRIVSEP(ssh_gssapi_server_ctx(&ctx, oid)));
> ++	ssh_gssapi_delete_ctx(&ctx);
> ++
> ++	return (res);
> ++}
> ++
> ++/* Unprivileged */
> + void
> + ssh_gssapi_supported_oids(gss_OID_set *oidset)
> + {
> +@@ -349,16 +382,6 @@
> + 	else
> + 		debug("ssh_gssapi_userok: Unknown GSSAPI mechanism");
> + 	return (0);
> +-}
> +-
> +-/* Privileged */
> +-OM_uint32
> +-ssh_gssapi_checkmic(Gssctxt *ctx, gss_buffer_t gssbuf,  
> gss_buffer_t gssmic)
> +-{
> +-	ctx->major = gss_verify_mic(&ctx->minor, ctx->context,
> +-	    gssbuf, gssmic, NULL);
> +-
> +-	return (ctx->major);
> + }
> +
> + #endif
> +Index: kex.c
> +===================================================================
> +RCS file: /cvs/openssh/kex.c,v
> +retrieving revision 1.86
> +diff -u -r1.86 kex.c
> +--- kex.c	5 Jun 2007 08:30:18 -0000	1.86
> ++++ kex.c	4 Apr 2008 12:52:29 -0000
> +@@ -49,6 +49,10 @@
> + #include "dispatch.h"
> + #include "monitor.h"
> +
> ++#ifdef GSSAPI
> ++#include "ssh-gss.h"
> ++#endif
> ++
> + #define KEX_COOKIE_LEN	16
> +
> + #if OPENSSL_VERSION_NUMBER >= 0x00907000L
> +@@ -326,6 +330,20 @@
> + 	} else if (strcmp(k->name, KEX_DHGEX_SHA256) == 0) {
> + 		k->kex_type = KEX_DH_GEX_SHA256;
> + 		k->evp_md = evp_ssh_sha256();
> ++#endif
> ++#ifdef GSSAPI
> ++	} else if (strncmp(k->name, KEX_GSS_GEX_SHA1_ID,
> ++	    sizeof(KEX_GSS_GEX_SHA1_ID) - 1) == 0) {
> ++		k->kex_type = KEX_GSS_GEX_SHA1;
> ++		k->evp_md = EVP_sha1();
> ++	} else if (strncmp(k->name, KEX_GSS_GRP1_SHA1_ID,
> ++	    sizeof(KEX_GSS_GRP1_SHA1_ID) - 1) == 0) {
> ++		k->kex_type = KEX_GSS_GRP1_SHA1;
> ++		k->evp_md = EVP_sha1();
> ++	} else if (strncmp(k->name, KEX_GSS_GRP14_SHA1_ID,
> ++	    sizeof(KEX_GSS_GRP14_SHA1_ID) - 1) == 0) {
> ++		k->kex_type = KEX_GSS_GRP14_SHA1;
> ++		k->evp_md = EVP_sha1();
> + #endif
> + 	} else
> + 		fatal("bad kex alg %s", k->name);
> +Index: kex.h
> +===================================================================
> +RCS file: /cvs/openssh/kex.h,v
> +retrieving revision 1.49
> +diff -u -r1.49 kex.h
> +--- kex.h	11 Jun 2007 04:01:42 -0000	1.49
> ++++ kex.h	4 Apr 2008 12:52:29 -0000
> +@@ -64,6 +64,9 @@
> + 	KEX_DH_GRP14_SHA1,
> + 	KEX_DH_GEX_SHA1,
> + 	KEX_DH_GEX_SHA256,
> ++	KEX_GSS_GRP1_SHA1,
> ++	KEX_GSS_GRP14_SHA1,
> ++	KEX_GSS_GEX_SHA1,
> + 	KEX_MAX
> + };
> +
> +@@ -119,6 +122,11 @@
> + 	sig_atomic_t done;
> + 	int	flags;
> + 	const EVP_MD *evp_md;
> ++#ifdef GSSAPI
> ++	int	gss_deleg_creds;
> ++	int	gss_trust_dns;
> ++	char    *gss_host;
> ++#endif
> + 	char	*client_version_string;
> + 	char	*server_version_string;
> + 	int	(*verify_host_key)(Key *);
> +@@ -140,6 +148,11 @@
> + void	 kexdh_server(Kex *);
> + void	 kexgex_client(Kex *);
> + void	 kexgex_server(Kex *);
> ++
> ++#ifdef GSSAPI
> ++void	kexgss_client(Kex *);
> ++void	kexgss_server(Kex *);
> ++#endif
> +
> + void
> + kex_dh_hash(char *, char *, char *, int, char *, int, u_char *, int,
> +Index: kexgssc.c
> +===================================================================
> +RCS file: kexgssc.c
> +diff -N kexgssc.c
> +--- /dev/null	1 Jan 1970 00:00:00 -0000
> ++++ kexgssc.c	4 Apr 2008 12:52:29 -0000
> +@@ -0,0 +1,319 @@
> ++/*
> ++ * Copyright (c) 2001-2006 Simon Wilkinson. All rights reserved.
> ++ *
> ++ * Redistribution and use in source and binary forms, with or  
> without
> ++ * modification, are permitted provided that the following  
> conditions
> ++ * are met:
> ++ * 1. Redistributions of source code must retain the above copyright
> ++ *    notice, this list of conditions and the following disclaimer.
> ++ * 2. Redistributions in binary form must reproduce the above  
> copyright
> ++ *    notice, this list of conditions and the following disclaimer  
> in the
> ++ *    documentation and/or other materials provided with the  
> distribution.
> ++ *
> ++ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR `AS IS'' AND ANY  
> EXPRESS OR
> ++ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED  
> WARRANTIES
> ++ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE  
> DISCLAIMED.
> ++ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
> ++ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES  
> (INCLUDING, BUT
> ++ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;  
> LOSS OF USE,
> ++ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND  
> ON ANY
> ++ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR  
> TORT
> ++ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF  
> THE USE OF
> ++ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> ++ */
> ++
> ++#include "includes.h"
> ++
> ++#ifdef GSSAPI
> ++
> ++#include "includes.h"
> ++
> ++#include <openssl/crypto.h>
> ++#include <openssl/bn.h>
> ++
> ++#include <string.h>
> ++
> ++#include "xmalloc.h"
> ++#include "buffer.h"
> ++#include "ssh2.h"
> ++#include "key.h"
> ++#include "cipher.h"
> ++#include "kex.h"
> ++#include "log.h"
> ++#include "packet.h"
> ++#include "dh.h"
> ++
> ++#include "ssh-gss.h"
> ++
> ++void
> ++kexgss_client(Kex *kex) {
> ++	gss_buffer_desc send_tok = GSS_C_EMPTY_BUFFER;
> ++	gss_buffer_desc recv_tok, gssbuf, msg_tok, *token_ptr;
> ++	Gssctxt *ctxt;
> ++	OM_uint32 maj_status, min_status, ret_flags;
> ++	u_int klen, kout, slen = 0, hashlen, strlen;
> ++	DH *dh;
> ++	BIGNUM *dh_server_pub = NULL;
> ++	BIGNUM *shared_secret = NULL;
> ++	BIGNUM *p = NULL;
> ++	BIGNUM *g = NULL;	
> ++	u_char *kbuf, *hash;
> ++	u_char *serverhostkey = NULL;
> ++	char *msg;
> ++	char *lang;
> ++	int type = 0;
> ++	int first = 1;
> ++	int nbits = 0, min = DH_GRP_MIN, max = DH_GRP_MAX;
> ++
> ++	/* Initialise our GSSAPI world */	
> ++	ssh_gssapi_build_ctx(&ctxt);
> ++	if (ssh_gssapi_id_kex(ctxt, kex->name, kex->kex_type)
> ++	    == GSS_C_NO_OID)
> ++		fatal("Couldn't identify host exchange");
> ++
> ++	if (ssh_gssapi_import_name(ctxt, kex->gss_host))
> ++		fatal("Couldn't import hostname");
> ++	
> ++	switch (kex->kex_type) {
> ++	case KEX_GSS_GRP1_SHA1:
> ++		dh = dh_new_group1();
> ++		break;
> ++	case KEX_GSS_GRP14_SHA1:
> ++		dh = dh_new_group14();
> ++		break;
> ++	case KEX_GSS_GEX_SHA1:
> ++		debug("Doing group exchange\n");
> ++		nbits = dh_estimate(kex->we_need * 8);
> ++		packet_start(SSH2_MSG_KEXGSS_GROUPREQ);
> ++		packet_put_int(min);
> ++		packet_put_int(nbits);
> ++		packet_put_int(max);
> ++
> ++		packet_send();
> ++
> ++		packet_read_expect(SSH2_MSG_KEXGSS_GROUP);
> ++
> ++		if ((p = BN_new()) == NULL)
> ++			fatal("BN_new() failed");
> ++		packet_get_bignum2(p);
> ++		if ((g = BN_new()) == NULL)
> ++			fatal("BN_new() failed");
> ++		packet_get_bignum2(g);
> ++		packet_check_eom();
> ++
> ++		if (BN_num_bits(p) < min || BN_num_bits(p) > max)
> ++			fatal("GSSGRP_GEX group out of range: %d !< %d !< %d",
> ++			    min, BN_num_bits(p), max);
> ++
> ++		dh = dh_new_group(g, p);
> ++		break;
> ++	default:
> ++		fatal("%s: Unexpected KEX type %d", __func__, kex->kex_type);
> ++	}
> ++	
> ++	/* Step 1 - e is dh->pub_key */
> ++	dh_gen_key(dh, kex->we_need * 8);
> ++
> ++	/* This is f, we initialise it now to make life easier */
> ++	dh_server_pub = BN_new();
> ++	if (dh_server_pub == NULL)
> ++		fatal("dh_server_pub == NULL");
> ++
> ++	token_ptr = GSS_C_NO_BUFFER;
> ++			
> ++	do {
> ++		debug("Calling gss_init_sec_context");
> ++		
> ++		maj_status = ssh_gssapi_init_ctx(ctxt,
> ++		    kex->gss_deleg_creds, token_ptr, &send_tok,
> ++		    &ret_flags);
> ++
> ++		if (GSS_ERROR(maj_status)) {
> ++			if (send_tok.length != 0) {
> ++				packet_start(SSH2_MSG_KEXGSS_CONTINUE);
> ++				packet_put_string(send_tok.value,
> ++				    send_tok.length);
> ++			}
> ++			fatal("gss_init_context failed");
> ++		}
> ++
> ++		/* If we've got an old receive buffer get rid of it */
> ++		if (token_ptr != GSS_C_NO_BUFFER)
> ++			xfree(recv_tok.value);
> ++
> ++		if (maj_status == GSS_S_COMPLETE) {
> ++			/* If mutual state flag is not true, kex fails */
> ++			if (!(ret_flags & GSS_C_MUTUAL_FLAG))
> ++				fatal("Mutual authentication failed");
> ++
> ++			/* If integ avail flag is not true kex fails */
> ++			if (!(ret_flags & GSS_C_INTEG_FLAG))
> ++				fatal("Integrity check failed");
> ++		}
> ++
> ++		/*
> ++		 * If we have data to send, then the last message that we
> ++		 * received cannot have been a 'complete'.
> ++		 */
> ++		if (send_tok.length != 0) {
> ++			if (first) {
> ++				packet_start(SSH2_MSG_KEXGSS_INIT);
> ++				packet_put_string(send_tok.value,
> ++				    send_tok.length);
> ++				packet_put_bignum2(dh->pub_key);
> ++				first = 0;
> ++			} else {
> ++				packet_start(SSH2_MSG_KEXGSS_CONTINUE);
> ++				packet_put_string(send_tok.value,
> ++				    send_tok.length);
> ++			}
> ++			packet_send();
> ++			gss_release_buffer(&min_status, &send_tok);
> ++
> ++			/* If we've sent them data, they should reply */
> ++			do {	
> ++				type = packet_read();
> ++				if (type == SSH2_MSG_KEXGSS_HOSTKEY) {
> ++					debug("Received KEXGSS_HOSTKEY");
> ++					if (serverhostkey)
> ++						fatal("Server host key received more than once");
> ++					serverhostkey =
> ++					    packet_get_string(&slen);
> ++				}
> ++			} while (type == SSH2_MSG_KEXGSS_HOSTKEY);
> ++
> ++			switch (type) {
> ++			case SSH2_MSG_KEXGSS_CONTINUE:
> ++				debug("Received GSSAPI_CONTINUE");
> ++				if (maj_status == GSS_S_COMPLETE)
> ++					fatal("GSSAPI Continue received from server when complete");
> ++				recv_tok.value = packet_get_string(&strlen);
> ++				recv_tok.length = strlen;
> ++				break;
> ++			case SSH2_MSG_KEXGSS_COMPLETE:
> ++				debug("Received GSSAPI_COMPLETE");
> ++				packet_get_bignum2(dh_server_pub);
> ++				msg_tok.value =  packet_get_string(&strlen);
> ++				msg_tok.length = strlen;
> ++
> ++				/* Is there a token included? */
> ++				if (packet_get_char()) {
> ++					recv_tok.value=
> ++					    packet_get_string(&strlen);
> ++					recv_tok.length = strlen;
> ++					/* If we're already complete - protocol error */
> ++					if (maj_status == GSS_S_COMPLETE)
> ++						packet_disconnect("Protocol error: received token when  
> complete");
> ++					} else {
> ++						/* No token included */
> ++						if (maj_status != GSS_S_COMPLETE)
> ++							packet_disconnect("Protocol error: did not receive final  
> token");
> ++				}
> ++				break;
> ++			case SSH2_MSG_KEXGSS_ERROR:
> ++				debug("Received Error");
> ++				maj_status = packet_get_int();
> ++				min_status = packet_get_int();
> ++				msg = packet_get_string(NULL);
> ++				lang = packet_get_string(NULL);
> ++				fatal("GSSAPI Error: \n%.400s",msg);
> ++			default:
> ++				packet_disconnect("Protocol error: didn't expect packet type  
> %d",
> ++		    		type);
> ++			}
> ++			token_ptr = &recv_tok;
> ++		} else {
> ++			/* No data, and not complete */
> ++			if (maj_status != GSS_S_COMPLETE)
> ++				fatal("Not complete, and no token output");
> ++		}
> ++	} while (maj_status & GSS_S_CONTINUE_NEEDED);
> ++
> ++	/*
> ++	 * We _must_ have received a COMPLETE message in reply from the
> ++	 * server, which will have set dh_server_pub and msg_tok
> ++	 */
> ++
> ++	if (type != SSH2_MSG_KEXGSS_COMPLETE)
> ++		fatal("Didn't receive a SSH2_MSG_KEXGSS_COMPLETE when I expected  
> it");
> ++
> ++	/* Check f in range [1, p-1] */
> ++	if (!dh_pub_is_valid(dh, dh_server_pub))
> ++		packet_disconnect("bad server public DH value");
> ++
> ++	/* compute K=f^x mod p */
> ++	klen = DH_size(dh);
> ++	kbuf = xmalloc(klen);
> ++	kout = DH_compute_key(kbuf, dh_server_pub, dh);
> ++
> ++	shared_secret = BN_new();
> ++	BN_bin2bn(kbuf,kout, shared_secret);
> ++	memset(kbuf, 0, klen);
> ++	xfree(kbuf);
> ++
> ++	switch (kex->kex_type) {
> ++	case KEX_GSS_GRP1_SHA1:
> ++	case KEX_GSS_GRP14_SHA1:
> ++		kex_dh_hash( kex->client_version_string,
> ++		    kex->server_version_string,
> ++		    buffer_ptr(&kex->my), buffer_len(&kex->my),
> ++		    buffer_ptr(&kex->peer), buffer_len(&kex->peer),
> ++		    serverhostkey, slen, /* server host key */
> ++		    dh->pub_key,	/* e */
> ++		    dh_server_pub,	/* f */
> ++		    shared_secret,	/* K */
> ++		    &hash, &hashlen
> ++		);
> ++		break;
> ++	case KEX_GSS_GEX_SHA1:
> ++		kexgex_hash(
> ++		    kex->evp_md,
> ++		    kex->client_version_string,
> ++		    kex->server_version_string,
> ++		    buffer_ptr(&kex->my), buffer_len(&kex->my),
> ++		    buffer_ptr(&kex->peer), buffer_len(&kex->peer),
> ++		    serverhostkey, slen,
> ++ 		    min, nbits, max,
> ++		    dh->p, dh->g,
> ++		    dh->pub_key,
> ++		    dh_server_pub,
> ++		    shared_secret,
> ++		    &hash, &hashlen
> ++		);
> ++		break;
> ++	default:
> ++		fatal("%s: Unexpected KEX type %d", __func__, kex->kex_type);
> ++	}
> ++
> ++	gssbuf.value = hash;
> ++	gssbuf.length = hashlen;
> ++
> ++	/* Verify that the hash matches the MIC we just got. */
> ++	if (GSS_ERROR(ssh_gssapi_checkmic(ctxt, &gssbuf, &msg_tok)))
> ++		packet_disconnect("Hash's MIC didn't verify");
> ++
> ++	xfree(msg_tok.value);
> ++
> ++	DH_free(dh);
> ++	if (serverhostkey)
> ++		xfree(serverhostkey);
> ++	BN_clear_free(dh_server_pub);
> ++
> ++	/* save session id */
> ++	if (kex->session_id == NULL) {
> ++		kex->session_id_len = hashlen;
> ++		kex->session_id = xmalloc(kex->session_id_len);
> ++		memcpy(kex->session_id, hash, kex->session_id_len);
> ++	}
> ++
> ++	if (gss_kex_context == NULL)
> ++		gss_kex_context = ctxt;
> ++	else
> ++		ssh_gssapi_delete_ctx(&ctxt);
> ++
> ++	kex_derive_keys(kex, hash, hashlen, shared_secret);
> ++	BN_clear_free(shared_secret);
> ++	kex_finish(kex);
> ++}
> ++
> ++#endif /* GSSAPI */
> +Index: kexgsss.c
> +===================================================================
> +RCS file: kexgsss.c
> +diff -N kexgsss.c
> +--- /dev/null	1 Jan 1970 00:00:00 -0000
> ++++ kexgsss.c	4 Apr 2008 12:52:29 -0000
> +@@ -0,0 +1,271 @@
> ++/*
> ++ * Copyright (c) 2001-2006 Simon Wilkinson. All rights reserved.
> ++ *
> ++ * Redistribution and use in source and binary forms, with or  
> without
> ++ * modification, are permitted provided that the following  
> conditions
> ++ * are met:
> ++ * 1. Redistributions of source code must retain the above copyright
> ++ *    notice, this list of conditions and the following disclaimer.
> ++ * 2. Redistributions in binary form must reproduce the above  
> copyright
> ++ *    notice, this list of conditions and the following disclaimer  
> in the
> ++ *    documentation and/or other materials provided with the  
> distribution.
> ++ *
> ++ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR `AS IS'' AND ANY  
> EXPRESS OR
> ++ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED  
> WARRANTIES
> ++ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE  
> DISCLAIMED.
> ++ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
> ++ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES  
> (INCLUDING, BUT
> ++ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;  
> LOSS OF USE,
> ++ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND  
> ON ANY
> ++ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR  
> TORT
> ++ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF  
> THE USE OF
> ++ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> ++ */
> ++
> ++#include "includes.h"
> ++
> ++#ifdef GSSAPI
> ++
> ++#include <string.h>
> ++
> ++#include <openssl/crypto.h>
> ++#include <openssl/bn.h>
> ++
> ++#include "xmalloc.h"
> ++#include "buffer.h"
> ++#include "ssh2.h"
> ++#include "key.h"
> ++#include "cipher.h"
> ++#include "kex.h"
> ++#include "log.h"
> ++#include "packet.h"
> ++#include "dh.h"
> ++#include "ssh-gss.h"
> ++#include "monitor_wrap.h"
> ++
> ++void
> ++kexgss_server(Kex *kex)
> ++{
> ++	OM_uint32 maj_status, min_status;
> ++	
> ++	/*
> ++	 * Some GSSAPI implementations use the input value of ret_flags (an
> ++ 	 * output variable) as a means of triggering mechanism specific
> ++ 	 * features. Initializing it to zero avoids inadvertently
> ++ 	 * activating this non-standard behaviour.
> ++	 */
> ++
> ++	OM_uint32 ret_flags = 0;
> ++	gss_buffer_desc gssbuf, recv_tok, msg_tok;
> ++	gss_buffer_desc send_tok = GSS_C_EMPTY_BUFFER;
> ++	Gssctxt *ctxt = NULL;
> ++	u_int slen, klen, kout, hashlen;
> ++	u_char *kbuf, *hash;
> ++	DH *dh;
> ++	int min = -1, max = -1, nbits = -1;
> ++	BIGNUM *shared_secret = NULL;
> ++	BIGNUM *dh_client_pub = NULL;
> ++	int type = 0;
> ++	gss_OID oid;
> ++
> ++	/* Initialise GSSAPI */
> ++
> ++	/* If we're rekeying, privsep means that some of the private  
> structures
> ++	 * in the GSSAPI code are no longer available. This kludges them  
> back
> ++	 * into life
> ++	 */
> ++	if (!ssh_gssapi_oid_table_ok())
> ++		ssh_gssapi_server_mechanisms();
> ++
> ++	debug2("%s: Identifying %s", __func__, kex->name);
> ++	oid = ssh_gssapi_id_kex(NULL, kex->name, kex->kex_type);
> ++	if (oid == GSS_C_NO_OID)
> ++	   fatal("Unknown gssapi mechanism");
> ++
> ++	debug2("%s: Acquiring credentials", __func__);
> ++
> ++	if (GSS_ERROR(PRIVSEP(ssh_gssapi_server_ctx(&ctxt, oid))))
> ++		fatal("Unable to acquire credentials for the server");
> ++
> ++	switch (kex->kex_type) {
> ++	case KEX_GSS_GRP1_SHA1:
> ++		dh = dh_new_group1();
> ++		break;
> ++	case KEX_GSS_GRP14_SHA1:
> ++		dh = dh_new_group14();
> ++		break;
> ++	case KEX_GSS_GEX_SHA1:
> ++		debug("Doing group exchange");
> ++		packet_read_expect(SSH2_MSG_KEXGSS_GROUPREQ);
> ++		min = packet_get_int();
> ++		nbits = packet_get_int();
> ++		max = packet_get_int();
> ++		min = MAX(DH_GRP_MIN, min);
> ++		max = MIN(DH_GRP_MAX, max);
> ++		packet_check_eom();
> ++		if (max < min || nbits < min || max < nbits)
> ++			fatal("GSS_GEX, bad parameters: %d !< %d !< %d",
> ++			    min, nbits, max);
> ++		dh = PRIVSEP(choose_dh(min, nbits, max));
> ++		if (dh == NULL)
> ++			packet_disconnect("Protocol error: no matching group found");
> ++
> ++		packet_start(SSH2_MSG_KEXGSS_GROUP);
> ++		packet_put_bignum2(dh->p);
> ++		packet_put_bignum2(dh->g);
> ++		packet_send();
> ++
> ++		packet_write_wait();
> ++		break;
> ++	default:
> ++		fatal("%s: Unexpected KEX type %d", __func__, kex->kex_type);
> ++	}
> ++
> ++	dh_gen_key(dh, kex->we_need * 8);
> ++
> ++	do {
> ++		debug("Wait SSH2_MSG_GSSAPI_INIT");
> ++		type = packet_read();
> ++		switch(type) {
> ++		case SSH2_MSG_KEXGSS_INIT:
> ++			if (dh_client_pub != NULL)
> ++				fatal("Received KEXGSS_INIT after initialising");
> ++			recv_tok.value = packet_get_string(&slen);
> ++			recv_tok.length = slen;
> ++
> ++			if ((dh_client_pub = BN_new()) == NULL)
> ++				fatal("dh_client_pub == NULL");
> ++
> ++			packet_get_bignum2(dh_client_pub);
> ++
> ++			/* Send SSH_MSG_KEXGSS_HOSTKEY here, if we want */
> ++			break;
> ++		case SSH2_MSG_KEXGSS_CONTINUE:
> ++			recv_tok.value = packet_get_string(&slen);
> ++			recv_tok.length = slen;
> ++			break;
> ++		default:
> ++			packet_disconnect(
> ++			    "Protocol error: didn't expect packet type %d",
> ++			    type);
> ++		}
> ++
> ++		maj_status = PRIVSEP(ssh_gssapi_accept_ctx(ctxt, &recv_tok,
> ++		    &send_tok, &ret_flags));
> ++
> ++		xfree(recv_tok.value);
> ++
> ++		if (maj_status != GSS_S_COMPLETE && send_tok.length == 0)
> ++			fatal("Zero length token output when incomplete");
> ++
> ++		if (dh_client_pub == NULL)
> ++			fatal("No client public key");
> ++		
> ++		if (maj_status & GSS_S_CONTINUE_NEEDED) {
> ++			debug("Sending GSSAPI_CONTINUE");
> ++			packet_start(SSH2_MSG_KEXGSS_CONTINUE);
> ++			packet_put_string(send_tok.value, send_tok.length);
> ++			packet_send();
> ++			gss_release_buffer(&min_status, &send_tok);
> ++		}
> ++	} while (maj_status & GSS_S_CONTINUE_NEEDED);
> ++
> ++	if (GSS_ERROR(maj_status)) {
> ++		if (send_tok.length > 0) {
> ++			packet_start(SSH2_MSG_KEXGSS_CONTINUE);
> ++			packet_put_string(send_tok.value, send_tok.length);
> ++			packet_send();
> ++		}
> ++		fatal("accept_ctx died");
> ++	}
> ++
> ++	if (!(ret_flags & GSS_C_MUTUAL_FLAG))
> ++		fatal("Mutual Authentication flag wasn't set");
> ++
> ++	if (!(ret_flags & GSS_C_INTEG_FLAG))
> ++		fatal("Integrity flag wasn't set");
> ++	
> ++	if (!dh_pub_is_valid(dh, dh_client_pub))
> ++		packet_disconnect("bad client public DH value");
> ++
> ++	klen = DH_size(dh);
> ++	kbuf = xmalloc(klen);
> ++	kout = DH_compute_key(kbuf, dh_client_pub, dh);
> ++
> ++	shared_secret = BN_new();
> ++	BN_bin2bn(kbuf, kout, shared_secret);
> ++	memset(kbuf, 0, klen);
> ++	xfree(kbuf);
> ++
> ++	switch (kex->kex_type) {
> ++	case KEX_GSS_GRP1_SHA1:
> ++	case KEX_GSS_GRP14_SHA1:
> ++		kex_dh_hash(
> ++		    kex->client_version_string, kex->server_version_string,
> ++		    buffer_ptr(&kex->peer), buffer_len(&kex->peer),
> ++		    buffer_ptr(&kex->my), buffer_len(&kex->my),
> ++		    NULL, 0, /* Change this if we start sending host keys */
> ++		    dh_client_pub, dh->pub_key, shared_secret,
> ++		    &hash, &hashlen
> ++		);
> ++		break;
> ++	case KEX_GSS_GEX_SHA1:
> ++		kexgex_hash(
> ++		    kex->evp_md,
> ++		    kex->client_version_string, kex->server_version_string,
> ++		    buffer_ptr(&kex->peer), buffer_len(&kex->peer),
> ++		    buffer_ptr(&kex->my), buffer_len(&kex->my),
> ++		    NULL, 0,
> ++		    min, nbits, max,
> ++		    dh->p, dh->g,
> ++		    dh_client_pub,
> ++		    dh->pub_key,
> ++		    shared_secret,
> ++		    &hash, &hashlen
> ++		);
> ++		break;
> ++	default:
> ++		fatal("%s: Unexpected KEX type %d", __func__, kex->kex_type);
> ++	}
> ++
> ++	BN_free(dh_client_pub);
> ++
> ++	if (kex->session_id == NULL) {
> ++		kex->session_id_len = hashlen;
> ++		kex->session_id = xmalloc(kex->session_id_len);
> ++		memcpy(kex->session_id, hash, kex->session_id_len);
> ++	}
> ++
> ++	gssbuf.value = hash;
> ++	gssbuf.length = hashlen;
> ++
> ++	if (GSS_ERROR(PRIVSEP(ssh_gssapi_sign(ctxt,&gssbuf,&msg_tok))))
> ++		fatal("Couldn't get MIC");
> ++
> ++	packet_start(SSH2_MSG_KEXGSS_COMPLETE);
> ++	packet_put_bignum2(dh->pub_key);
> ++	packet_put_string(msg_tok.value,msg_tok.length);
> ++
> ++	if (send_tok.length != 0) {
> ++		packet_put_char(1); /* true */
> ++		packet_put_string(send_tok.value, send_tok.length);
> ++	} else {
> ++		packet_put_char(0); /* false */
> ++	}
> ++	packet_send();
> ++
> ++	gss_release_buffer(&min_status, &send_tok);
> ++	gss_release_buffer(&min_status, &msg_tok);
> ++
> ++	if (gss_kex_context == NULL)
> ++		gss_kex_context = ctxt;
> ++	else
> ++		ssh_gssapi_delete_ctx(&ctxt);
> ++
> ++	DH_free(dh);
> ++
> ++	kex_derive_keys(kex, hash, hashlen, shared_secret);
> ++	BN_clear_free(shared_secret);
> ++	kex_finish(kex);
> ++}
> ++#endif /* GSSAPI */
> +Index: key.c
> +===================================================================
> +RCS file: /cvs/openssh/key.c,v
> +retrieving revision 1.72
> +diff -u -r1.72 key.c
> +--- key.c	28 Feb 2008 08:22:04 -0000	1.72
> ++++ key.c	4 Apr 2008 12:52:29 -0000
> +@@ -649,6 +649,8 @@
> + 		return KEY_RSA;
> + 	} else if (strcmp(name, "ssh-dss") == 0) {
> + 		return KEY_DSA;
> ++	} else if (strcmp(name, "null") == 0) {
> ++		return KEY_NULL;
> + 	}
> + 	debug2("key_type_from_name: unknown key type '%s'", name);
> + 	return KEY_UNSPEC;
> +Index: key.h
> +===================================================================
> +RCS file: /cvs/openssh/key.h,v
> +retrieving revision 1.28
> +diff -u -r1.28 key.h
> +--- key.h	5 Aug 2006 02:39:40 -0000	1.28
> ++++ key.h	4 Apr 2008 12:52:29 -0000
> +@@ -34,6 +34,7 @@
> + 	KEY_RSA1,
> + 	KEY_RSA,
> + 	KEY_DSA,
> ++	KEY_NULL,
> + 	KEY_UNSPEC
> + };
> + enum fp_type {
> +Index: monitor.c
> +===================================================================
> +RCS file: /cvs/openssh/monitor.c,v
> +retrieving revision 1.127
> +diff -u -r1.127 monitor.c
> +--- monitor.c	11 Mar 2008 11:58:25 -0000	1.127
> ++++ monitor.c	4 Apr 2008 12:52:29 -0000
> +@@ -163,6 +163,7 @@
> + int mm_answer_gss_accept_ctx(int, Buffer *);
> + int mm_answer_gss_userok(int, Buffer *);
> + int mm_answer_gss_checkmic(int, Buffer *);
> ++int mm_answer_gss_sign(int, Buffer *);
> + #endif
> +
> + #ifdef SSH_AUDIT_EVENTS
> +@@ -232,11 +233,17 @@
> +     {MONITOR_REQ_GSSSTEP, MON_ISAUTH, mm_answer_gss_accept_ctx},
> +     {MONITOR_REQ_GSSUSEROK, MON_AUTH, mm_answer_gss_userok},
> +     {MONITOR_REQ_GSSCHECKMIC, MON_ISAUTH, mm_answer_gss_checkmic},
> ++    {MONITOR_REQ_GSSSIGN, MON_ONCE, mm_answer_gss_sign},
> + #endif
> +     {0, 0, NULL}
> + };
> +
> + struct mon_table mon_dispatch_postauth20[] = {
> ++#ifdef GSSAPI
> ++    {MONITOR_REQ_GSSSETUP, 0, mm_answer_gss_setup_ctx},
> ++    {MONITOR_REQ_GSSSTEP, 0, mm_answer_gss_accept_ctx},
> ++    {MONITOR_REQ_GSSSIGN, 0, mm_answer_gss_sign},
> ++#endif
> +     {MONITOR_REQ_MODULI, 0, mm_answer_moduli},
> +     {MONITOR_REQ_SIGN, 0, mm_answer_sign},
> +     {MONITOR_REQ_PTY, 0, mm_answer_pty},
> +@@ -341,6 +348,10 @@
> + 		/* Permit requests for moduli and signatures */
> + 		monitor_permit(mon_dispatch, MONITOR_REQ_MODULI, 1);
> + 		monitor_permit(mon_dispatch, MONITOR_REQ_SIGN, 1);
> ++#ifdef GSSAPI
> ++		/* and for the GSSAPI key exchange */
> ++		monitor_permit(mon_dispatch, MONITOR_REQ_GSSSETUP, 1);
> ++#endif
> + 	} else {
> + 		mon_dispatch = mon_dispatch_proto15;
> +
> +@@ -418,6 +429,10 @@
> + 		monitor_permit(mon_dispatch, MONITOR_REQ_MODULI, 1);
> + 		monitor_permit(mon_dispatch, MONITOR_REQ_SIGN, 1);
> + 		monitor_permit(mon_dispatch, MONITOR_REQ_TERM, 1);
> ++#ifdef GSSAPI
> ++		/* and for the GSSAPI key exchange */
> ++		monitor_permit(mon_dispatch, MONITOR_REQ_GSSSETUP, 1);
> ++#endif		
> + 	} else {
> + 		mon_dispatch = mon_dispatch_postauth15;
> + 		monitor_permit(mon_dispatch, MONITOR_REQ_TERM, 1);
> +@@ -1670,6 +1685,11 @@
> + 	kex->kex[KEX_DH_GRP14_SHA1] = kexdh_server;
> + 	kex->kex[KEX_DH_GEX_SHA1] = kexgex_server;
> + 	kex->kex[KEX_DH_GEX_SHA256] = kexgex_server;
> ++#ifdef GSSAPI
> ++	kex->kex[KEX_GSS_GRP1_SHA1] = kexgss_server;
> ++	kex->kex[KEX_GSS_GRP14_SHA1] = kexgss_server;
> ++	kex->kex[KEX_GSS_GEX_SHA1] = kexgss_server;
> ++#endif
> + 	kex->server = 1;
> + 	kex->hostkey_type = buffer_get_int(m);
> + 	kex->kex_type = buffer_get_int(m);
> +@@ -1911,6 +1931,7 @@
> + 		monitor_permit(mon_dispatch, MONITOR_REQ_GSSSTEP, 0);
> + 		monitor_permit(mon_dispatch, MONITOR_REQ_GSSUSEROK, 1);
> + 		monitor_permit(mon_dispatch, MONITOR_REQ_GSSCHECKMIC, 1);
> ++		monitor_permit(mon_dispatch, MONITOR_REQ_GSSSIGN, 1);
> + 	}
> + 	return (0);
> + }
> +@@ -1961,4 +1982,42 @@
> + 	/* Monitor loop will terminate if authenticated */
> + 	return (authenticated);
> + }
> ++
> ++int
> ++mm_answer_gss_sign(int socket, Buffer *m)
> ++{
> ++	gss_buffer_desc data;
> ++	gss_buffer_desc hash = GSS_C_EMPTY_BUFFER;
> ++	OM_uint32 major, minor;
> ++	u_int len;
> ++
> ++	data.value = buffer_get_string(m, &len);
> ++	data.length = len;
> ++	if (data.length != 20)
> ++		fatal("%s: data length incorrect: %d", __func__, data.length);
> ++
> ++	/* Save the session ID on the first time around */
> ++	if (session_id2_len == 0) {
> ++		session_id2_len = data.length;
> ++		session_id2 = xmalloc(session_id2_len);
> ++		memcpy(session_id2, data.value, session_id2_len);
> ++	}
> ++	major = ssh_gssapi_sign(gsscontext, &data, &hash);
> ++
> ++	xfree(data.value);
> ++
> ++	buffer_clear(m);
> ++	buffer_put_int(m, major);
> ++	buffer_put_string(m, hash.value, hash.length);
> ++
> ++	mm_request_send(socket, MONITOR_ANS_GSSSIGN, m);
> ++
> ++	gss_release_buffer(&minor, &hash);
> ++
> ++	/* Turn on getpwnam permissions */
> ++	monitor_permit(mon_dispatch, MONITOR_REQ_PWNAM, 1);
> ++
> ++	return (0);
> ++}
> ++
> + #endif /* GSSAPI */
> +Index: monitor.h
> +===================================================================
> +RCS file: /cvs/openssh/monitor.h,v
> +retrieving revision 1.21
> +diff -u -r1.21 monitor.h
> +--- monitor.h	26 Mar 2006 03:30:02 -0000	1.21
> ++++ monitor.h	4 Apr 2008 12:52:29 -0000
> +@@ -53,6 +53,7 @@
> + 	MONITOR_REQ_GSSSTEP, MONITOR_ANS_GSSSTEP,
> + 	MONITOR_REQ_GSSUSEROK, MONITOR_ANS_GSSUSEROK,
> + 	MONITOR_REQ_GSSCHECKMIC, MONITOR_ANS_GSSCHECKMIC,
> ++	MONITOR_REQ_GSSSIGN, MONITOR_ANS_GSSSIGN,
> + 	MONITOR_REQ_PAM_START,
> + 	MONITOR_REQ_PAM_ACCOUNT, MONITOR_ANS_PAM_ACCOUNT,
> + 	MONITOR_REQ_PAM_INIT_CTX, MONITOR_ANS_PAM_INIT_CTX,
> +Index: monitor_wrap.c
> +===================================================================
> +RCS file: /cvs/openssh/monitor_wrap.c,v
> +retrieving revision 1.76
> +diff -u -r1.76 monitor_wrap.c
> +--- monitor_wrap.c	2 Dec 2007 12:02:15 -0000	1.76
> ++++ monitor_wrap.c	4 Apr 2008 12:52:29 -0000
> +@@ -1238,4 +1238,27 @@
> + 	debug3("%s: user %sauthenticated",__func__, authenticated ? "" :  
> "not ");
> + 	return (authenticated);
> + }
> ++
> ++OM_uint32
> ++mm_ssh_gssapi_sign(Gssctxt *ctx, gss_buffer_desc *data,  
> gss_buffer_desc *hash)
> ++{
> ++	Buffer m;
> ++	OM_uint32 major;
> ++	u_int len;
> ++
> ++	buffer_init(&m);
> ++	buffer_put_string(&m, data->value, data->length);
> ++
> ++	mm_request_send(pmonitor->m_recvfd, MONITOR_REQ_GSSSIGN, &m);
> ++	mm_request_receive_expect(pmonitor->m_recvfd,  
> MONITOR_ANS_GSSSIGN, &m);
> ++
> ++	major = buffer_get_int(&m);
> ++	hash->value = buffer_get_string(&m, &len);
> ++	hash->length = len;
> ++
> ++	buffer_free(&m);
> ++
> ++	return(major);
> ++}
> ++
> + #endif /* GSSAPI */
> +Index: monitor_wrap.h
> +===================================================================
> +RCS file: /cvs/openssh/monitor_wrap.h,v
> +retrieving revision 1.27
> +diff -u -r1.27 monitor_wrap.h
> +--- monitor_wrap.h	5 Aug 2006 02:39:40 -0000	1.27
> ++++ monitor_wrap.h	4 Apr 2008 12:52:29 -0000
> +@@ -59,6 +59,7 @@
> +    gss_buffer_desc *, gss_buffer_desc *, OM_uint32 *);
> + int mm_ssh_gssapi_userok(char *user);
> + OM_uint32 mm_ssh_gssapi_checkmic(Gssctxt *, gss_buffer_t,  
> gss_buffer_t);
> ++OM_uint32 mm_ssh_gssapi_sign(Gssctxt *, gss_buffer_t, gss_buffer_t);
> + #endif
> +
> + #ifdef USE_PAM
> +Index: readconf.c
> +===================================================================
> +RCS file: /cvs/openssh/readconf.c,v
> +retrieving revision 1.142
> +diff -u -r1.142 readconf.c
> +--- readconf.c	10 Feb 2008 11:25:52 -0000	1.142
> ++++ readconf.c	4 Apr 2008 12:52:29 -0000
> +@@ -127,6 +127,8 @@
> + 	oClearAllForwardings, oNoHostAuthenticationForLocalhost,
> + 	oEnableSSHKeysign, oRekeyLimit, oVerifyHostKeyDNS, oConnectTimeout,
> + 	oAddressFamily, oGssAuthentication, oGssDelegateCreds,
> ++	oGssKeyEx,
> ++	oGssTrustDns,
> + 	oServerAliveInterval, oServerAliveCountMax, oIdentitiesOnly,
> + 	oSendEnv, oControlPath, oControlMaster, oHashKnownHosts,
> + 	oTunnel, oTunnelDevice, oLocalCommand, oPermitLocalCommand,
> +@@ -163,10 +165,14 @@
> + 	{ "afstokenpassing", oUnsupported },
> + #if defined(GSSAPI)
> + 	{ "gssapiauthentication", oGssAuthentication },
> ++	{ "gssapikeyexchange", oGssKeyEx },
> + 	{ "gssapidelegatecredentials", oGssDelegateCreds },
> ++	{ "gssapitrustdns", oGssTrustDns },
> + #else
> + 	{ "gssapiauthentication", oUnsupported },
> ++	{ "gssapikeyexchange", oUnsupported },
> + 	{ "gssapidelegatecredentials", oUnsupported },
> ++	{ "gssapitrustdns", oUnsupported },
> + #endif
> + 	{ "fallbacktorsh", oDeprecated },
> + 	{ "usersh", oDeprecated },
> +@@ -442,10 +448,18 @@
> + 		intptr = &options->gss_authentication;
> + 		goto parse_flag;
> +
> ++	case oGssKeyEx:
> ++	    	intptr = &options->gss_keyex;
> ++		goto parse_flag;
> ++
> + 	case oGssDelegateCreds:
> + 		intptr = &options->gss_deleg_creds;
> + 		goto parse_flag;
> +
> ++	case oGssTrustDns:
> ++		intptr = &options->gss_trust_dns;
> ++		goto parse_flag;
> ++
> + 	case oBatchMode:
> + 		intptr = &options->batch_mode;
> + 		goto parse_flag;
> +@@ -1010,7 +1024,9 @@
> + 	options->pubkey_authentication = -1;
> + 	options->challenge_response_authentication = -1;
> + 	options->gss_authentication = -1;
> ++	options->gss_keyex = -1;
> + 	options->gss_deleg_creds = -1;
> ++	options->gss_trust_dns = -1;
> + 	options->password_authentication = -1;
> + 	options->kbd_interactive_authentication = -1;
> + 	options->kbd_interactive_devices = NULL;
> +@@ -1099,8 +1115,12 @@
> + 		options->challenge_response_authentication = 1;
> + 	if (options->gss_authentication == -1)
> + 		options->gss_authentication = 0;
> ++	if (options->gss_keyex == -1)
> ++		options->gss_keyex = 0;
> + 	if (options->gss_deleg_creds == -1)
> + 		options->gss_deleg_creds = 0;
> ++	if (options->gss_trust_dns == -1)
> ++		options->gss_trust_dns = 0;
> + 	if (options->password_authentication == -1)
> + 		options->password_authentication = 1;
> + 	if (options->kbd_interactive_authentication == -1)
> +Index: readconf.h
> +===================================================================
> +RCS file: /cvs/openssh/readconf.h,v
> +retrieving revision 1.64
> +diff -u -r1.64 readconf.h
> +--- readconf.h	10 Feb 2008 11:25:52 -0000	1.64
> ++++ readconf.h	4 Apr 2008 12:52:29 -0000
> +@@ -44,7 +44,9 @@
> + 	int     challenge_response_authentication;
> + 					/* Try S/Key or TIS, authentication. */
> + 	int     gss_authentication;	/* Try GSS authentication */
> ++	int	gss_keyex;              /* Try GSS key exchange */
> + 	int     gss_deleg_creds;	/* Delegate GSS credentials */
> ++	int	gss_trust_dns;		/* Trust DNS for GSS canonicalization */
> + 	int     password_authentication;	/* Try password
> + 						 * authentication. */
> + 	int     kbd_interactive_authentication; /* Try keyboard- 
> interactive auth. */
> +Index: servconf.c
> +===================================================================
> +RCS file: /cvs/openssh/servconf.c,v
> +retrieving revision 1.168
> +diff -u -r1.168 servconf.c
> +--- servconf.c	10 Feb 2008 11:48:55 -0000	1.168
> ++++ servconf.c	4 Apr 2008 12:52:30 -0000
> +@@ -90,7 +90,9 @@
> + 	options->kerberos_ticket_cleanup = -1;
> + 	options->kerberos_get_afs_token = -1;
> + 	options->gss_authentication=-1;
> ++	options->gss_keyex = -1;
> + 	options->gss_cleanup_creds = -1;
> ++	options->gss_strict_acceptor = -1;
> + 	options->password_authentication = -1;
> + 	options->kbd_interactive_authentication = -1;
> + 	options->challenge_response_authentication = -1;
> +@@ -205,8 +207,12 @@
> + 		options->kerberos_get_afs_token = 0;
> + 	if (options->gss_authentication == -1)
> + 		options->gss_authentication = 0;
> ++	if (options->gss_keyex == -1)
> ++		options->gss_keyex = 0;
> + 	if (options->gss_cleanup_creds == -1)
> + 		options->gss_cleanup_creds = 1;
> ++	if (options->gss_strict_acceptor == -1)
> ++		options->gss_strict_acceptor = 1;
> + 	if (options->password_authentication == -1)
> + 		options->password_authentication = 1;
> + 	if (options->kbd_interactive_authentication == -1)
> +@@ -291,7 +297,9 @@
> + 	sBanner, sUseDNS, sHostbasedAuthentication,
> + 	sHostbasedUsesNameFromPacketOnly, sClientAliveInterval,
> + 	sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2,
> +-	sGssAuthentication, sGssCleanupCreds, sAcceptEnv, sPermitTunnel,
> ++	sGssAuthentication, sGssCleanupCreds, sGssStrictAcceptor,
> ++	sGssKeyEx,
> ++	sAcceptEnv, sPermitTunnel,
> + 	sMatch, sPermitOpen, sForceCommand, sChrootDirectory,
> + 	sUsePrivilegeSeparation,
> + 	sDeprecated, sUnsupported
> +@@ -352,9 +360,13 @@
> + #ifdef GSSAPI
> + 	{ "gssapiauthentication", sGssAuthentication, SSHCFG_ALL },
> + 	{ "gssapicleanupcredentials", sGssCleanupCreds, SSHCFG_GLOBAL },
> ++	{ "gssapistrictacceptorcheck", sGssStrictAcceptor, SSHCFG_GLOBAL },
> ++	{ "gssapikeyexchange", sGssKeyEx, SSHCFG_GLOBAL },
> + #else
> + 	{ "gssapiauthentication", sUnsupported, SSHCFG_ALL },
> + 	{ "gssapicleanupcredentials", sUnsupported, SSHCFG_GLOBAL },
> ++	{ "gssapistrictacceptorcheck", sUnsupported, SSHCFG_GLOBAL },
> ++	{ "gssapikeyexchange", sUnsupported, SSHCFG_GLOBAL },
> + #endif
> + 	{ "passwordauthentication", sPasswordAuthentication, SSHCFG_ALL },
> + 	{ "kbdinteractiveauthentication", sKbdInteractiveAuthentication,  
> SSHCFG_ALL },
> +@@ -875,8 +887,16 @@
> + 		intptr = &options->gss_authentication;
> + 		goto parse_flag;
> +
> ++	case sGssKeyEx:
> ++		intptr = &options->gss_keyex;
> ++		goto parse_flag;
> ++
> + 	case sGssCleanupCreds:
> + 		intptr = &options->gss_cleanup_creds;
> ++		goto parse_flag;
> ++
> ++	case sGssStrictAcceptor:
> ++		intptr = &options->gss_strict_acceptor;
> + 		goto parse_flag;
> +
> + 	case sPasswordAuthentication:
> +Index: servconf.h
> +===================================================================
> +RCS file: /cvs/openssh/servconf.h,v
> +retrieving revision 1.74
> +diff -u -r1.74 servconf.h
> +--- servconf.h	7 Mar 2008 07:31:24 -0000	1.74
> ++++ servconf.h	4 Apr 2008 12:52:30 -0000
> +@@ -90,7 +90,9 @@
> + 	int     kerberos_get_afs_token;		/* If true, try to get AFS token  
> if
> + 						 * authenticated with Kerberos. */
> + 	int     gss_authentication;	/* If true, permit GSSAPI  
> authentication */
> ++	int 	gss_keyex;		/* If true, permit GSSAPI key exchange */
> + 	int     gss_cleanup_creds;	/* If true, destroy cred cache on  
> logout */
> ++	int 	gss_strict_acceptor;	/* If true, restrict the GSSAPI  
> acceptor name */
> + 	int     password_authentication;	/* If true, permit password
> + 						 * authentication. */
> + 	int     kbd_interactive_authentication;	/* If true, permit */
> +Index: ssh-gss.h
> +===================================================================
> +RCS file: /cvs/openssh/ssh-gss.h,v
> +retrieving revision 1.12
> +diff -u -r1.12 ssh-gss.h
> +--- ssh-gss.h	12 Jun 2007 13:40:39 -0000	1.12
> ++++ ssh-gss.h	4 Apr 2008 12:52:30 -0000
> +@@ -60,6 +60,17 @@
> +
> + #define SSH_GSS_OIDTYPE 0x06
> +
> ++#define SSH2_MSG_KEXGSS_INIT                            30
> ++#define SSH2_MSG_KEXGSS_CONTINUE                        31
> ++#define SSH2_MSG_KEXGSS_COMPLETE                        32
> ++#define SSH2_MSG_KEXGSS_HOSTKEY                         33
> ++#define SSH2_MSG_KEXGSS_ERROR                           34
> ++#define SSH2_MSG_KEXGSS_GROUPREQ			40
> ++#define SSH2_MSG_KEXGSS_GROUP				41
> ++#define KEX_GSS_GRP1_SHA1_ID				"gss-group1-sha1-"
> ++#define KEX_GSS_GRP14_SHA1_ID				"gss-group14-sha1-"
> ++#define KEX_GSS_GEX_SHA1_ID				"gss-gex-sha1-"
> ++
> + typedef struct {
> + 	char *filename;
> + 	char *envvar;
> +@@ -97,6 +108,7 @@
> + } Gssctxt;
> +
> + extern ssh_gssapi_mech *supported_mechs[];
> ++extern Gssctxt *gss_kex_context;
> +
> + int  ssh_gssapi_check_oid(Gssctxt *, void *, size_t);
> + void ssh_gssapi_set_oid_data(Gssctxt *, void *, size_t);
> +@@ -119,6 +131,11 @@
> + int ssh_gssapi_check_mechanism(Gssctxt **, gss_OID, const char *);
> +
> + /* In the server */
> ++typedef int ssh_gssapi_check_fn(Gssctxt **, gss_OID, const char *);
> ++char *ssh_gssapi_client_mechanisms(const char *host);
> ++char *ssh_gssapi_kex_mechs(gss_OID_set, ssh_gssapi_check_fn *,  
> const char *);
> ++gss_OID ssh_gssapi_id_kex(Gssctxt *, char *, int);
> ++int ssh_gssapi_server_check_mech(Gssctxt **,gss_OID, const char *);
> + OM_uint32 ssh_gssapi_server_ctx(Gssctxt **, gss_OID);
> + int ssh_gssapi_userok(char *name);
> + OM_uint32 ssh_gssapi_checkmic(Gssctxt *, gss_buffer_t,  
> gss_buffer_t);
> +@@ -126,6 +143,8 @@
> + void ssh_gssapi_cleanup_creds(void);
> + void ssh_gssapi_storecreds(void);
> +
> ++char *ssh_gssapi_server_mechanisms(void);
> ++int ssh_gssapi_oid_table_ok();
> + #endif /* GSSAPI */
> +
> + #endif /* _SSH_GSS_H */
> +Index: ssh_config
> +===================================================================
> +RCS file: /cvs/openssh/ssh_config,v
> +retrieving revision 1.25
> +diff -u -r1.25 ssh_config
> +--- ssh_config	11 Jun 2007 04:04:42 -0000	1.25
> ++++ ssh_config	4 Apr 2008 12:52:30 -0000
> +@@ -26,6 +26,8 @@
> + #   HostbasedAuthentication no
> + #   GSSAPIAuthentication no
> + #   GSSAPIDelegateCredentials no
> ++#   GSSAPIKeyExchange no
> ++#   GSSAPITrustDNS no
> + #   BatchMode no
> + #   CheckHostIP yes
> + #   AddressFamily any
> +Index: ssh_config.5
> +===================================================================
> +RCS file: /cvs/openssh/ssh_config.5,v
> +retrieving revision 1.105
> +diff -u -r1.105 ssh_config.5
> +--- ssh_config.5	2 Dec 2007 12:09:30 -0000	1.105
> ++++ ssh_config.5	4 Apr 2008 12:52:30 -0000
> +@@ -477,11 +477,28 @@
> + The default is
> + .Dq no .
> + Note that this option applies to protocol version 2 only.
> ++.It Cm GSSAPIKeyExchange
> ++Specifies whether key exchange based on GSSAPI may be used. When  
> using
> ++GSSAPI key exchange the server need not have a host key.
> ++The default is
> ++.Dq no .
> ++Note that this option applies to protocol version 2 only.
> + .It Cm GSSAPIDelegateCredentials
> + Forward (delegate) credentials to the server.
> + The default is
> + .Dq no .
> + Note that this option applies to protocol version 2 only.
> ++.It Cm GSSAPITrustDns
> ++Set to
> ++.Dq yes
> ++to indicate that the DNS is trusted to securely canonicalize
> ++the name of the host being connected to. If
> ++.Dq no ,
> ++the hostname entered on the
> ++command line will be passed untouched to the GSSAPI library.
> ++The default is
> ++.Dq no .
> ++This option only applies to protocol version 2 connections using  
> GSSAPI.
> + .It Cm HashKnownHosts
> + Indicates that
> + .Xr ssh 1
> +Index: sshconnect2.c
> +===================================================================
> +RCS file: /cvs/openssh/sshconnect2.c,v
> +retrieving revision 1.156
> +diff -u -r1.156 sshconnect2.c
> +--- sshconnect2.c	10 Feb 2008 11:25:53 -0000	1.156
> ++++ sshconnect2.c	4 Apr 2008 12:52:30 -0000
> +@@ -99,9 +99,34 @@
> + {
> + 	Kex *kex;
> +
> ++#ifdef GSSAPI
> ++	char *orig = NULL, *gss = NULL;
> ++	char *gss_host = NULL;
> ++#endif
> ++
> + 	xxx_host = host;
> + 	xxx_hostaddr = hostaddr;
> +
> ++#ifdef GSSAPI
> ++	if (options.gss_keyex) {
> ++		/* Add the GSSAPI mechanisms currently supported on this
> ++		 * client to the key exchange algorithm proposal */
> ++		orig = myproposal[PROPOSAL_KEX_ALGS];
> ++
> ++		if (options.gss_trust_dns)
> ++			gss_host = (char *)get_canonical_hostname(1);
> ++		else
> ++			gss_host = host;
> ++
> ++		gss = ssh_gssapi_client_mechanisms(gss_host);
> ++		if (gss) {
> ++			debug("Offering GSSAPI proposal: %s", gss);
> ++			xasprintf(&myproposal[PROPOSAL_KEX_ALGS],
> ++			    "%s,%s", gss, orig);
> ++		}
> ++	}
> ++#endif
> ++
> + 	if (options.ciphers == (char *)-1) {
> + 		logit("No valid ciphers for protocol version 2 given, using  
> defaults.");
> + 		options.ciphers = NULL;
> +@@ -129,6 +154,16 @@
> + 		myproposal[PROPOSAL_SERVER_HOST_KEY_ALGS] =
> + 		    options.hostkeyalgorithms;
> +
> ++#ifdef GSSAPI
> ++	/* If we've got GSSAPI algorithms, then we also support the
> ++	 * 'null' hostkey, as a last resort */
> ++	if (options.gss_keyex && gss) {
> ++		orig = myproposal[PROPOSAL_SERVER_HOST_KEY_ALGS];
> ++		xasprintf(&myproposal[PROPOSAL_SERVER_HOST_KEY_ALGS],
> ++		    "%s,null", orig);
> ++	}
> ++#endif
> ++
> + 	if (options.rekey_limit)
> + 		packet_set_rekey_limit((u_int32_t)options.rekey_limit);
> +
> +@@ -138,10 +173,21 @@
> + 	kex->kex[KEX_DH_GRP14_SHA1] = kexdh_client;
> + 	kex->kex[KEX_DH_GEX_SHA1] = kexgex_client;
> + 	kex->kex[KEX_DH_GEX_SHA256] = kexgex_client;
> ++#ifdef GSSAPI
> ++	kex->kex[KEX_GSS_GRP1_SHA1] = kexgss_client;
> ++	kex->kex[KEX_GSS_GRP14_SHA1] = kexgss_client;
> ++	kex->kex[KEX_GSS_GEX_SHA1] = kexgss_client;
> ++#endif
> + 	kex->client_version_string=client_version_string;
> + 	kex->server_version_string=server_version_string;
> + 	kex->verify_host_key=&verify_host_key_callback;
> +
> ++#ifdef GSSAPI
> ++	kex->gss_deleg_creds = options.gss_deleg_creds;
> ++	kex->gss_trust_dns = options.gss_trust_dns;
> ++	kex->gss_host = gss_host;
> ++#endif
> ++
> + 	xxx_kex = kex;
> +
> + 	dispatch_run(DISPATCH_BLOCK, &kex->done, kex);
> +@@ -224,6 +270,7 @@
> + void	input_gssapi_hash(int type, u_int32_t, void *);
> + void	input_gssapi_error(int, u_int32_t, void *);
> + void	input_gssapi_errtok(int, u_int32_t, void *);
> ++int	userauth_gsskeyex(Authctxt *authctxt);
> + #endif
> +
> + void	userauth(Authctxt *, char *);
> +@@ -239,6 +286,10 @@
> +
> + Authmethod authmethods[] = {
> + #ifdef GSSAPI
> ++	{"gssapi-keyex",
> ++		userauth_gsskeyex,
> ++		&options.gss_authentication,
> ++		NULL},
> + 	{"gssapi-with-mic",
> + 		userauth_gssapi,
> + 		&options.gss_authentication,
> +@@ -501,6 +552,12 @@
> + 	static u_int mech = 0;
> + 	OM_uint32 min;
> + 	int ok = 0;
> ++	char *gss_host = NULL;
> ++
> ++	if (options.gss_trust_dns)
> ++		gss_host = (char *)get_canonical_hostname(1);
> ++	else
> ++		gss_host = (char *)authctxt->host;
> +
> + 	/* Try one GSSAPI method at a time, rather than sending them all at
> + 	 * once. */
> +@@ -513,7 +570,7 @@
> + 		/* My DER encoding requires length<128 */
> + 		if (gss_supported->elements[mech].length < 128 &&
> + 		    ssh_gssapi_check_mechanism(&gssctxt,
> +-		    &gss_supported->elements[mech], authctxt->host)) {
> ++		    &gss_supported->elements[mech], gss_host)) {
> + 			ok = 1; /* Mechanism works */
> + 		} else {
> + 			mech++;
> +@@ -609,8 +666,8 @@
> + {
> + 	Authctxt *authctxt = ctxt;
> + 	Gssctxt *gssctxt;
> +-	int oidlen;
> +-	char *oidv;
> ++	u_int oidlen;
> ++	u_char *oidv;
> +
> + 	if (authctxt == NULL)
> + 		fatal("input_gssapi_response: no authentication context");
> +@@ -717,6 +774,48 @@
> + 	xfree(msg);
> + 	xfree(lang);
> + }
> ++
> ++int
> ++userauth_gsskeyex(Authctxt *authctxt)
> ++{
> ++	Buffer b;
> ++	gss_buffer_desc gssbuf;
> ++	gss_buffer_desc mic = GSS_C_EMPTY_BUFFER;
> ++	OM_uint32 ms;
> ++
> ++	static int attempt = 0;
> ++	if (attempt++ >= 1)
> ++		return (0);
> ++
> ++	if (gss_kex_context == NULL) {
> ++		debug("No valid Key exchange context");
> ++		return (0);
> ++	}
> ++
> ++	ssh_gssapi_buildmic(&b, authctxt->server_user, authctxt->service,
> ++	    "gssapi-keyex");
> ++
> ++	gssbuf.value = buffer_ptr(&b);
> ++	gssbuf.length = buffer_len(&b);
> ++
> ++	if (GSS_ERROR(ssh_gssapi_sign(gss_kex_context, &gssbuf, &mic))) {
> ++		buffer_free(&b);
> ++		return (0);
> ++	}
> ++
> ++	packet_start(SSH2_MSG_USERAUTH_REQUEST);
> ++	packet_put_cstring(authctxt->server_user);
> ++	packet_put_cstring(authctxt->service);
> ++	packet_put_cstring(authctxt->method->name);
> ++	packet_put_string(mic.value, mic.length);
> ++	packet_send();
> ++
> ++	buffer_free(&b);
> ++	gss_release_buffer(&ms, &mic);
> ++
> ++	return (1);
> ++}
> ++
> + #endif /* GSSAPI */
> +
> + int
> +Index: sshd.c
> +===================================================================
> +RCS file: /cvs/openssh/sshd.c,v
> +retrieving revision 1.372
> +diff -u -r1.372 sshd.c
> +--- sshd.c	11 Mar 2008 11:58:25 -0000	1.372
> ++++ sshd.c	4 Apr 2008 12:52:30 -0000
> +@@ -119,6 +119,10 @@
> + #include "monitor_fdpass.h"
> + #include "version.h"
> +
> ++#ifdef USE_SECURITY_SESSION_API
> ++#include <Security/AuthSession.h>
> ++#endif
> ++
> + #ifdef LIBWRAP
> + #include <tcpd.h>
> + #include <syslog.h>
> +@@ -1501,10 +1505,13 @@
> + 		logit("Disabling protocol version 1. Could not load host key");
> + 		options.protocol &= ~SSH_PROTO_1;
> + 	}
> ++#ifndef GSSAPI
> ++	/* The GSSAPI key exchange can run without a host key */
> + 	if ((options.protocol & SSH_PROTO_2) && ! 
> sensitive_data.have_ssh2_key) {
> + 		logit("Disabling protocol version 2. Could not load host key");
> + 		options.protocol &= ~SSH_PROTO_2;
> + 	}
> ++#endif
> + 	if (!(options.protocol & (SSH_PROTO_1|SSH_PROTO_2))) {
> + 		logit("sshd: no hostkeys available -- exiting.");
> + 		exit(1);
> +@@ -1777,6 +1784,60 @@
> + 	/* Log the connection. */
> + 	verbose("Connection from %.500s port %d", remote_ip, remote_port);
> +
> ++#ifdef USE_SECURITY_SESSION_API
> ++	/*
> ++	 * Create a new security session for use by the new user login if
> ++	 * the current session is the root session or we are not launched
> ++	 * by inetd (eg: debugging mode or server mode).  We do not
> ++	 * necessarily need to create a session if we are launched from
> ++	 * inetd because Panther xinetd will create a session for us.
> ++	 *
> ++	 * The only case where this logic will fail is if there is an
> ++	 * inetd running in a non-root session which is not creating
> ++	 * new sessions for us.  Then all the users will end up in the
> ++	 * same session (bad).
> ++	 *
> ++	 * When the client exits, the session will be destroyed for us
> ++	 * automatically.
> ++	 *
> ++	 * We must create the session before any credentials are stored
> ++	 * (including AFS pags, which happens a few lines below).
> ++	 */
> ++	{
> ++		OSStatus err = 0;
> ++		SecuritySessionId sid = 0;
> ++		SessionAttributeBits sattrs = 0;
> ++
> ++		err = SessionGetInfo(callerSecuritySession, &sid, &sattrs);
> ++		if (err)
> ++			error("SessionGetInfo() failed with error %.8X",
> ++			    (unsigned) err);
> ++		else
> ++			debug("Current Session ID is %.8X / Session Attributes are %.8X",
> ++			    (unsigned) sid, (unsigned) sattrs);
> ++
> ++		if (inetd_flag && !(sattrs & sessionIsRoot))
> ++			debug("Running in inetd mode in a non-root session... "
> ++			    "assuming inetd created the session for us.");
> ++		else {
> ++			debug("Creating new security session...");
> ++			err = SessionCreate(0, sessionHasTTY | sessionIsRemote);
> ++			if (err)
> ++				error("SessionCreate() failed with error %.8X",
> ++				    (unsigned) err);
> ++
> ++			err = SessionGetInfo(callerSecuritySession, &sid,
> ++			    &sattrs);
> ++			if (err)
> ++				error("SessionGetInfo() failed with error %.8X",
> ++				    (unsigned) err);
> ++			else
> ++				debug("New Session ID is %.8X / Session Attributes are %.8X",
> ++				    (unsigned) sid, (unsigned) sattrs);
> ++		}
> ++	}
> ++#endif
> ++
> + 	/*
> + 	 * We don't want to listen forever unless the other side
> + 	 * successfully authenticates itself.  So we set up an alarm  
> which is
> +@@ -2153,12 +2214,59 @@
> +
> + 	myproposal[PROPOSAL_SERVER_HOST_KEY_ALGS] = list_hostkey_types();
> +
> ++#ifdef GSSAPI
> ++	{
> ++	char *orig;
> ++	char *gss = NULL;
> ++	char *newstr = NULL;
> ++	orig = myproposal[PROPOSAL_KEX_ALGS];
> ++
> ++	/*
> ++	 * If we don't have a host key, then there's no point advertising
> ++	 * the other key exchange algorithms
> ++	 */
> ++
> ++	if (strlen(myproposal[PROPOSAL_SERVER_HOST_KEY_ALGS]) == 0)
> ++		orig = NULL;
> ++
> ++	if (options.gss_keyex)
> ++		gss = ssh_gssapi_server_mechanisms();
> ++	else
> ++		gss = NULL;
> ++
> ++	if (gss && orig)
> ++		xasprintf(&newstr, "%s,%s", gss, orig);
> ++	else if (gss)
> ++		newstr = gss;
> ++	else if (orig)
> ++		newstr = orig;
> ++
> ++	/*
> ++	 * If we've got GSSAPI mechanisms, then we've got the 'null' host
> ++	 * key alg, but we can't tell people about it unless its the only
> ++  	 * host key algorithm we support
> ++	 */
> ++	if (gss && (strlen(myproposal[PROPOSAL_SERVER_HOST_KEY_ALGS])) ==  
> 0)
> ++		myproposal[PROPOSAL_SERVER_HOST_KEY_ALGS] = "null";
> ++
> ++	if (newstr)
> ++		myproposal[PROPOSAL_KEX_ALGS] = newstr;
> ++	else
> ++		fatal("No supported key exchange algorithms");
> ++	}
> ++#endif
> ++
> + 	/* start key exchange */
> + 	kex = kex_setup(myproposal);
> + 	kex->kex[KEX_DH_GRP1_SHA1] = kexdh_server;
> + 	kex->kex[KEX_DH_GRP14_SHA1] = kexdh_server;
> + 	kex->kex[KEX_DH_GEX_SHA1] = kexgex_server;
> + 	kex->kex[KEX_DH_GEX_SHA256] = kexgex_server;
> ++#ifdef GSSAPI
> ++	kex->kex[KEX_GSS_GRP1_SHA1] = kexgss_server;
> ++	kex->kex[KEX_GSS_GRP14_SHA1] = kexgss_server;
> ++	kex->kex[KEX_GSS_GEX_SHA1] = kexgss_server;
> ++#endif
> + 	kex->server = 1;
> + 	kex->client_version_string=client_version_string;
> + 	kex->server_version_string=server_version_string;
> +Index: sshd_config
> +===================================================================
> +RCS file: /cvs/openssh/sshd_config,v
> +retrieving revision 1.79
> +diff -u -r1.79 sshd_config
> +--- sshd_config	10 Feb 2008 11:40:12 -0000	1.79
> ++++ sshd_config	4 Apr 2008 12:52:30 -0000
> +@@ -72,6 +72,8 @@
> + # GSSAPI options
> + #GSSAPIAuthentication no
> + #GSSAPICleanupCredentials yes
> ++#GSSAPIStrictAcceptorCheck yes
> ++#GSSAPIKeyExchange no
> +
> + # Set this to 'yes' to enable PAM authentication, account  
> processing,
> + # and session processing. If this is enabled, PAM authentication  
> will
> +Index: sshd_config.5
> +===================================================================
> +RCS file: /cvs/openssh/sshd_config.5,v
> +retrieving revision 1.90
> +diff -u -r1.90 sshd_config.5
> +--- sshd_config.5	27 Mar 2008 00:02:02 -0000	1.90
> ++++ sshd_config.5	4 Apr 2008 12:52:30 -0000
> +@@ -365,12 +365,35 @@
> + The default is
> + .Dq no .
> + Note that this option applies to protocol version 2 only.
> ++.It Cm GSSAPIKeyExchange
> ++Specifies whether key exchange based on GSSAPI is allowed. GSSAPI  
> key exchange
> ++doesn't rely on ssh keys to verify host identity.
> ++The default is
> ++.Dq no .
> ++Note that this option applies to protocol version 2 only.
> + .It Cm GSSAPICleanupCredentials
> + Specifies whether to automatically destroy the user's credentials  
> cache
> + on logout.
> + The default is
> + .Dq yes .
> + Note that this option applies to protocol version 2 only.
> ++.It Cm GSSAPIStrictAcceptorCheck
> ++Determines whether to be strict about the identity of the GSSAPI  
> acceptor
> ++a client authenticates against. If
> ++.Dq yes
> ++then the client must authenticate against the
> ++.Pa host
> ++service on the current hostname. If
> ++.Dq no
> ++then the client may authenticate against any service key stored in  
> the
> ++machine's default store. This facility is provided to assist with  
> operation
> ++on multi homed machines.
> ++The default is
> ++.Dq yes .
> ++Note that this option applies only to protocol version 2 GSSAPI  
> connections,
> ++and setting it to
> ++.Dq no
> ++may only work with recent Kerberos GSSAPI libraries.
> + .It Cm HostbasedAuthentication
> + Specifies whether rhosts or /etc/hosts.equiv authentication together
> + with successful public key client host authentication is allowed
> Added: trunk/dports/net/openssh/files/pam.patch (0 => 38526)
> --- trunk/dports/net/openssh/files/pam.patch	                         
> (rev 0)
> +++ trunk/dports/net/openssh/files/pam.patch	2008-07-24 04:33:03 UTC  
> (rev 38526)
> @@ -0,0 +1,12 @@
> +diff -Naur ../openssh-4.4p1.orig/servconf.c ./servconf.c
> +--- ../openssh-4.4p1.orig/servconf.c	2006-08-18 07:23:15.000000000  
> -0700
> ++++ ./servconf.c	2006-10-19 17:12:43.000000000 -0700
> +@@ -129,7 +129,7 @@
> + {
> + 	/* Portable-specific options */
> + 	if (options->use_pam == -1)
> +-		options->use_pam = 0;
> ++		options->use_pam = 1;
> +
> + 	/* Standard Options */
> + 	if (options->protocol == SSH_PROTO_UNKNOWN)
> Added: trunk/dports/net/openssh/files/sacl.patch (0 => 38526)
> --- trunk/dports/net/openssh/files/ 
> sacl.patch	                        (rev 0)
> +++ trunk/dports/net/openssh/files/sacl.patch	2008-07-24 04:33:03  
> UTC (rev 38526)
> @@ -0,0 +1,124 @@
> +diff -Naur ../openssh-4.4p1.orig/auth.c ./auth.c
> +--- ../openssh-4.4p1.orig/auth.c	2006-09-06 17:36:43.000000000 -0700
> ++++ ./auth.c	2006-10-19 17:22:43.000000000 -0700
> +@@ -45,6 +45,11 @@
> + #ifdef HAVE_LIBGEN_H
> + #include <libgen.h>
> + #endif
> ++
> ++#ifdef __APPLE_SACL__
> ++#include <membershipPriv.h>
> ++#endif
> ++
> + #include <stdarg.h>
> + #include <stdio.h>
> + #include <string.h>
> +@@ -233,6 +238,46 @@
> + 			}
> + 		ga_free();
> + 	}
> ++	
> ++	if( options.sacl_support )
> ++	{
> ++#ifdef __APPLE_SACL__
> ++		/*
> ++	 	* Here we check with memberd if the Service ACLs allow this  
> user to
> ++	 	* use the ssh service.
> ++	 	*/
> ++
> ++		debug("Checking with Service ACLs for ssh login restrictions");
> ++
> ++		uuid_t user_uuid;
> ++		int isMember = 0;
> ++		int mbrErr = 0;
> ++	
> ++		// get the uuid
> ++		if ( mbr_user_name_to_uuid(pw->pw_name, user_uuid) )
> ++		{
> ++			debug("call to mbr_user_name_to_uuid with <%s> failed to  
> retrieve user_uuid", pw->pw_name);
> ++			return 0;
> ++		}	
> ++		debug("call to mbr_user_name_to_uuid with <%s> suceeded to  
> retrieve user_uuid", pw->pw_name);
> ++	
> ++		// check the sacl
> ++		if((mbrErr = mbr_check_service_membership(user_uuid, "ssh",  
> &isMember)))
> ++		{
> ++			debug("Called mbr_check_service_membership with isMember <%d>  
> with status <%d>", isMember, mbrErr);
> ++			if(mbrErr == ENOENT)	// no ACL exists
> ++			{
> ++				return 1;	
> ++			} else {
> ++				return 0;
> ++			}
> ++		}
> ++		debug("Call to mbr_check_service_membership failed with status < 
> %d>", mbrErr);
> ++		return isMember;
> ++#endif /* __APPLE_SACL__ */
> ++	}
> ++
> ++
> +
> + #ifdef CUSTOM_SYS_AUTH_ALLOWED_USER
> + 	if (!sys_auth_allowed_user(pw, &loginmsg))
> +diff -Naur ../openssh-4.4p1.orig/servconf.c ./servconf.c
> +--- ../openssh-4.4p1.orig/servconf.c	2006-08-18 07:23:15.000000000  
> -0700
> ++++ ./servconf.c	2006-10-19 17:24:47.000000000 -0700
> +@@ -97,6 +97,7 @@
> + 	options->permit_empty_passwd = -1;
> + 	options->permit_user_env = -1;
> + 	options->use_login = -1;
> ++	options->sacl_support = -1;
> + 	options->compression = -1;
> + 	options->allow_tcp_forwarding = -1;
> + 	options->num_allow_users = 0;
> +@@ -293,6 +294,7 @@
> + 	sGssAuthentication, sGssCleanupCreds, sAcceptEnv, sPermitTunnel,
> + 	sMatch, sPermitOpen, sForceCommand,
> + 	sUsePrivilegeSeparation,
> ++	sSACLSupport,
> + 	sDeprecated, sUnsupported
> + } ServerOpCodes;
> +
> +@@ -398,6 +400,7 @@
> + 	{ "authorizedkeysfile", sAuthorizedKeysFile, SSHCFG_GLOBAL },
> + 	{ "authorizedkeysfile2", sAuthorizedKeysFile2, SSHCFG_GLOBAL },
> + 	{ "useprivilegeseparation", sUsePrivilegeSeparation,  
> SSHCFG_GLOBAL },
> ++	{ "saclsupport", sSACLSupport },
> + 	{ "acceptenv", sAcceptEnv, SSHCFG_GLOBAL },
> + 	{ "permittunnel", sPermitTunnel, SSHCFG_GLOBAL },
> +  	{ "match", sMatch, SSHCFG_ALL },
> +@@ -912,6 +915,10 @@
> + 		charptr = &options->xauth_location;
> + 		goto parse_filename;
> +
> ++	case sSACLSupport:
> ++		intptr = &options->sacl_support;
> ++		goto parse_flag;
> ++
> + 	case sStrictModes:
> + 		intptr = &options->strict_modes;
> + 		goto parse_flag;
> +diff -Naur ../openssh-4.4p1.orig/servconf.h ./servconf.h
> +--- ../openssh-4.4p1.orig/servconf.h	2006-08-18 07:23:15.000000000  
> -0700
> ++++ ./servconf.h	2006-10-19 17:25:18.000000000 -0700
> +@@ -137,6 +137,7 @@
> + 	char   *adm_forced_command;
> +
> + 	int	use_pam;		/* Enable auth via PAM */
> ++	int	sacl_support;		/* Enable use of SACLs */
> +
> + 	int	permit_tun;
> +
> +diff -Naur ../openssh-4.4p1.orig/sshd_config ./sshd_config
> +--- ../openssh-4.4p1.orig/sshd_config	2006-07-23 21:06:47.000000000  
> -0700
> ++++ ./sshd_config	2006-10-19 17:26:01.000000000 -0700
> +@@ -56,6 +56,9 @@
> + #PasswordAuthentication yes
> + #PermitEmptyPasswords no
> +
> ++# SACL options
> ++#SACLSupport yes
> ++
> + # Change to no to disable s/key passwords
> + #ChallengeResponseAuthentication yes
> +
> _______________________________________________
> macports-changes mailing list
> macports-changes at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/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/20080724/a5fe278a/attachment-0001.bin 

From ryandesign at macports.org  Thu Jul 24 14:32:46 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 24 Jul 2008 16:32:46 -0500
Subject: [38533] trunk/dports/devel/caml-ounit/Portfile
In-Reply-To: <20080724210736.CF3F317F724@beta.macosforge.org>
References: <20080724210736.CF3F317F724@beta.macosforge.org>
Message-ID: <FC039F23-2D21-44C9-B758-90197560B6D7@macports.org>


On Jul 24, 2008, at 16:07, landonf at macports.org wrote:

> Revision: 38533
>           http://trac.macosforge.org/projects/macports/changeset/38533
> Author:   landonf at macports.org
> Date:     2008-07-24 14:07:36 -0700 (Thu, 24 Jul 2008)
> Log Message:
> -----------
> Avoid calling ocamlfind before it has been installed.

> -set ocaml_site_path [exec ocamlfind printconf destdir]
> +pre-extract {
> +    global ocaml_site_path
> +    set ocaml_site_path [exec ocamlfind printconf destdir]
> +}

That works if you install all in one go:


$ port install caml-unit
--->  Fetching caml-ounit
--->  Verifying checksum(s) for caml-ounit
--->  Extracting caml-ounit
--->  Configuring caml-ounit
--->  Building caml-ounit
--->  Staging caml-ounit into destroot
--->  Installing caml-ounit @1.0.2_0
--->  Activating caml-ounit @1.0.2_0
--->  Cleaning caml-ounit
$


But not if you break it up into two steps:


$ port extract caml-unit
--->  Fetching caml-ounit
--->  Verifying checksum(s) for caml-ounit
--->  Extracting caml-ounit
$ port install caml-unit
Error: Target org.macports.patch returned: can't read  
"ocaml_site_path": no such variable
Error: Status 1 encountered during processing.
$


I think you need to set the ocaml_site_path variable within each  
phase that uses it.



From landonf at macports.org  Thu Jul 24 15:22:07 2008
From: landonf at macports.org (Landon Fuller)
Date: Thu, 24 Jul 2008 15:22:07 -0700
Subject: caml vs. ocaml
Message-ID: <E0BB0A71-8E8F-493B-A63F-CB86C151685E@macports.org>

A number of ports are named "caml-", but are actually OCaml ports.  
They seem to only be used as dependencies for Unison (which is written  
in OCaml).

Objections to changing their name to ocaml? This will probably cause a  
headache for anyone who currently has Unison installed.
Other suggestions?

-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/20080724/adca9986/attachment.bin 

From ryandesign at macports.org  Thu Jul 24 19:43:26 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 24 Jul 2008 21:43:26 -0500
Subject: Chunked guide
In-Reply-To: <c24012060807240244j3f1e5777hecea5dbef2789c44@mail.gmail.com>
References: <fc.004c4c580fdd69db004c4c580fdd69db.fdd6b59@biola.edu>
	<0F0AD412-083B-41AE-8EF5-F2889A691DB3@macports.org>
	<c24012060807220142t680b1db8sacfda2d226c833a4@mail.gmail.com>
	<7536594D-9222-424A-82F2-DDDD092C49CF@macports.org>
	<c24012060807220238l7d566a36j72803f9f0928bd4f@mail.gmail.com>
	<885132C4-CFC3-43D6-B2CA-A2EA543255E9@macports.org>
	<c24012060807240244j3f1e5777hecea5dbef2789c44@mail.gmail.com>
Message-ID: <7216033A-45DD-43C4-9B53-03F6C5D1E6E9@macports.org>


On Jul 24, 2008, at 04:44, Randall Wood wrote:

>>> Are the topical searches within results not showing the guide?  
>>> (Now  I
>>> just need to figure out how to get a topical search to be the  
>>> default
>>> one...)
>>
>> You mean the part after I do my search where it says:
>>
>> Refine results for foo: Guide Tickets Changesets Ports Wiki
>>
>> Honestly I hadn't seen that until now. It works fine when I click  
>> "Guide".
>>
>> Still I'd rather not search over everything, then have to refine  
>> my search.
>> I want the right search from the beginning. I guess I can type  
>> "more:guide"
>> into the search box. It would be easier if there were a drop-down  
>> menu where
>> I could select how I want to refine the search right at the  
>> beginning.
>
> The Google Search API (javascript) makes this possible. So, is the use
> of JavaScript to draw the search form acceptable or not in this case?

I'm not familiar with the Google Search API but I would say it would  
be a good idea to use a regular text box for the search box, and then  
add a drop-down menu of refinements via JavaScript if necessary. That  
way those with JavaScript off still get a basic search box that works.


From ryandesign at macports.org  Thu Jul 24 23:23:21 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 25 Jul 2008 01:23:21 -0500
Subject: Committer help requested
In-Reply-To: <4888B7FC.4050806@gmail.com>
References: <4888B7FC.4050806@gmail.com>
Message-ID: <DF41589A-EAC1-4F51-A9FA-3683BDE29BB8@macports.org>


On Jul 24, 2008, at 12:12, David Evans wrote:

> Would appreciate comitter help with the following tickets:
>
> http://trac.macports.org/ticket/16046
> http://trac.macports.org/ticket/16047
> http://trac.macports.org/ticket/16048
> http://trac.macports.org/ticket/16049
> http://trac.macports.org/ticket/16051

I'm taking care of these.


From ryandesign at macports.org  Fri Jul 25 08:42:22 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 25 Jul 2008 10:42:22 -0500
Subject: [38599] trunk/dports/math/fftw-3/Portfile
In-Reply-To: <20080725125114.C4BD61840B7@beta.macosforge.org>
References: <20080725125114.C4BD61840B7@beta.macosforge.org>
Message-ID: <386D768F-B594-4580-A321-2D6DB37E4E8F@macports.org>

On Jul 25, 2008, at 07:51, takeshi at macports.org wrote:

> Revision: 38599
>           http://trac.macosforge.org/projects/macports/changeset/38599
> Author:   takeshi at macports.org
> Date:     2008-07-25 05:51:14 -0700 (Fri, 25 Jul 2008)
> Log Message:
> -----------
> fftw-3: use_parallel_build yes

Thanks, but for future reference, you don't need to increase the port  
revision for changes like this, because there is no change to the  
files the port ends up installing on the user's hard drive. You only  
need to increase the revision if you want all users who already have  
the port installed to be forced to reinstall it.


> Modified Paths:
> --------------
>     trunk/dports/math/fftw-3/Portfile
>
> Modified: trunk/dports/math/fftw-3/Portfile
> ===================================================================
> --- trunk/dports/math/fftw-3/Portfile	2008-07-25 12:50:01 UTC (rev  
> 38598)
> +++ trunk/dports/math/fftw-3/Portfile	2008-07-25 12:51:14 UTC (rev  
> 38599)
> @@ -1,3 +1,4 @@
> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode:  
> nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
>  # $Id$
>
>  PortSystem      1.0
> @@ -4,7 +5,7 @@
>
>  name            fftw-3
>  version         3.1.2
> -revision        5
> +revision        6
>  categories      math
>  platforms       darwin
>  maintainers     takeshi at macports.org
> @@ -35,10 +36,9 @@
>  	improvements relative to 2.x, but is not backwardly \
>  	compatible.
>
> -checksums \
> -	md5 08f2e21c9fd02f4be2bd53a62592afa4 \
> -	sha1 3e4c64009ffb48123a0f30f46c1d89da7810dc67 \
> -	rmd160 13069b3582eeaa1fba1614cdca2dfbc2e45ab585
> +checksums md5 08f2e21c9fd02f4be2bd53a62592afa4 \
> +	        sha1 3e4c64009ffb48123a0f30f46c1d89da7810dc67 \
> +	        rmd160 13069b3582eeaa1fba1614cdca2dfbc2e45ab585
>
>  configure.args \
>  	--enable-threads \
> @@ -52,6 +52,7 @@
>  test.target  check
>
>  universal_variant no
> +use_parallel_build yes
>
>  variant gcc42 description {create Fortran wrappers using gcc42}  
> conflicts gcc43 g95 {
>  	depends_lib-append    port:gcc42


From db.evans at gmail.com  Fri Jul 25 09:01:41 2008
From: db.evans at gmail.com (David Evans)
Date: Fri, 25 Jul 2008 09:01:41 -0700
Subject: [MacPorts] #16048: lv2core:  new port
In-Reply-To: <063.7f53508ab6c00f9d2bcb3fa8ac66747c@macports.org>
References: <054.3b8adbf8e11dda4570728937aef62fdf@macports.org>
	<063.7f53508ab6c00f9d2bcb3fa8ac66747c@macports.org>
Message-ID: <4889F8E5.2000608@gmail.com>

MacPorts wrote:
> #16048: lv2core:  new port
> ---------------------------------+------------------------------------------
>   Reporter:  db.evans at gmail.com  |       Owner:  ryandesign at macports.org
>       Type:  enhancement         |      Status:  assigned               
>   Priority:  Normal              |   Milestone:  Port Submissions       
>  Component:  ports               |     Version:  1.6.0                  
> Resolution:                      |    Keywords:                         
> ---------------------------------+------------------------------------------
> Changes (by ryandesign at macports.org):
> 
>   * owner:  macports-tickets at lists.macosforge.org =>
>             ryandesign at macports.org
>   * status:  new => assigned
> 
> Comment:
> 
>  I added the port in r38544. Thanks!
> 
>  Question: why is gawk listed as a dependency? It installs for me without
>  complaint even when gawk is absent. That's on 10.4.11 Intel.
> 
>  Also: this port doesn't install any binaries or libraries, right? Given
>  that, can I add "`universal_variant no`" to the portfile?
> 

I added gawk because the configure script explicitly checks for it and 
it was my understanding that the MacPorts policy was to use ports in 
preference to Apple installed software.  However, if you see no need for
it, I have no problem removing it.

And yes, the port only installs necessary include pkgconfig files that 
are required by other software (such as the slv2 port) to implement the
lv2 plugin standard.  So, as you say, the concept of a universal_variant
is not meaningful here.

Thanks for your help and suggestions with these ports

Dave

From db.evans at gmail.com  Fri Jul 25 09:27:56 2008
From: db.evans at gmail.com (David Evans)
Date: Fri, 25 Jul 2008 09:27:56 -0700
Subject: [MacPorts] #16051: ardour2: new port
In-Reply-To: <063.c160fee0af162d1c0ffb7324afa7b969@macports.org>
References: <054.28746b42c34c31b6890bfda73ebdf476@macports.org>
	<063.c160fee0af162d1c0ffb7324afa7b969@macports.org>
Message-ID: <4889FF0C.6010100@gmail.com>

MacPorts wrote:
> #16051: ardour2: new port
> ---------------------------------+------------------------------------------
>   Reporter:  db.evans at gmail.com  |       Owner:  ryandesign at macports.org
>       Type:  enhancement         |      Status:  closed                 
>   Priority:  Normal              |   Milestone:  Port Submissions       
>  Component:  ports               |     Version:  1.6.0                  
> Resolution:  fixed               |    Keywords:  ardour                 
> ---------------------------------+------------------------------------------
> Changes (by ryandesign at macports.org):
> 
>   * status:  assigned => closed
>   * resolution:  => fixed
> 
> Comment:
> 
>  Rather than clearing the build phase, the correct way seems to be to set
>  `build.cmd` to "`scons`", clear the `build.target`, and set the
>  `build.args` as desired. MacPorts takes care of setting `destroot.cmd` to
>  the same thing as `build.cmd`, setting `destroot.target` to "`install`"
>  and setting `destroot.destdir` to "`DESTDIR=${destroot}`".
> 
>  {{{
>  build.cmd               scons
>  build.target
>  build.args              PREFIX=${prefix} VST=0 AUBIO=1 FREESOUND=1 LV2=1
>  }}}
> 
>  This change also means that parallel building will work now, since I
>  enabled parallel building for scons-based ports in MacPorts base in
>  r38556. This helps a lot since ardour takes a long time to compile. So I
>  added "`use_parallel_build yes`" to the portfile, and reindented the
>  column to 24 characters so things line up again.
> 
>  The one remaining oddity is that it looks like the gettext message
>  catalogs get built only during the destroot phase. Not sure why. But I'm
>  not too concerned since it takes very little time to build the message
>  catalogs, compared with how much time it takes to build the rest of
>  ardour.
> 
>  So the port is now added in r38560. Thanks for the contribution! And I
>  hope you'll forgive my interfering in your port here.
> 

Again, thanks for your help with this.  My original approach was based 
on my understanding that I needed to declare DESTDIR during the scons 
build phase and scons refused to proceed at build time because 
${destroot} did not yet exist.  Hence deferred everything to destroot.
So thanks for your suggestions.  They clear up some points that are
not so clear from the guide documentation.

I wonder if you have actually tried using the port.  It works for me at
a minimal level if you configure things properly but the audio output
breaks up a lot.  According to the mac osx developers on chat the 
problem is with the current released version of jack (0.109.2).  They
recommended the svn version which advertises itself as 0.111.0 but its
still got some instabilities.  Looks like the correct solution is to use
jackdmp (C++ implementation of the jack api that supports multiple 
processors) but ardour2 compiled against jack will not work with it.  So
ardour2 needs to be compiled against whichever version of jack your 
using for jackd/jackdmp since that package provides both the server and
matching client library.  Am working on this now and so am thinking of
of adding variants to ardour2 to allow the user to select which jack 
port to build against.  Of course, jack and jackdmp would conflict with
each other in terms of the installed binaries so only one can be active 
at a given time.  Any suggestions?

At any rate, I'm grateful for your suggestions and improvements as well
your help in getting these ports committed.

Dave

From usx303 at googlemail.com  Fri Jul 25 11:52:34 2008
From: usx303 at googlemail.com (Uwe Schwartz)
Date: Fri, 25 Jul 2008 20:52:34 +0200
Subject: Name for StartupItem Variant
Message-ID: <488A20F2.9000807@googlemail.com>

Hi,

I would like to add a variant to a port which should create a StartupItem.
In the MacPort Guide the example uses "server" as name for the variant.
Is this common practice? Or are there any other suggestions?

Uwe

From landonf at macports.org  Fri Jul 25 12:35:58 2008
From: landonf at macports.org (Landon Fuller)
Date: Fri, 25 Jul 2008 12:35:58 -0700
Subject: Name for StartupItem Variant
In-Reply-To: <488A20F2.9000807@googlemail.com>
References: <488A20F2.9000807@googlemail.com>
Message-ID: <271FC904-FF49-447B-871C-E7D9187D1CDC@macports.org>


On Jul 25, 2008, at 11:52 AM, Uwe Schwartz wrote:

> Hi,
>
> I would like to add a variant to a port which should create a  
> StartupItem.
> In the MacPort Guide the example uses "server" as name for the  
> variant.
> Is this common practice? Or are there any other suggestions?

I would suggest either *always* installing the startup item (but  
disabled by default), or creating a new port, <base port>-server, that  
depends on the base port and declares only a startup item.

The postgresql ports all provide "-server" ports -- you don't have to  
rebuild the whole port just to add a startup item.

In contrast, I can't tell you the number of times I had employees  
accidentally build MySQL without the +server variant on their  
workstation, and then have to rebuild it all again just for the  
startup item.

-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/20080725/75c9ce47/attachment.bin 

From ryandesign at macports.org  Fri Jul 25 12:54:32 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 25 Jul 2008 14:54:32 -0500
Subject: Name for StartupItem Variant
In-Reply-To: <271FC904-FF49-447B-871C-E7D9187D1CDC@macports.org>
References: <488A20F2.9000807@googlemail.com>
	<271FC904-FF49-447B-871C-E7D9187D1CDC@macports.org>
Message-ID: <54DC76EB-28FD-44B2-AF0C-6347E5439AAE@macports.org>


On Jul 25, 2008, at 14:35, Landon Fuller wrote:

> On Jul 25, 2008, at 11:52 AM, Uwe Schwartz wrote:
>
>> I would like to add a variant to a port which should create a  
>> StartupItem.
>> In the MacPort Guide the example uses "server" as name for the  
>> variant.
>> Is this common practice? Or are there any other suggestions?
>
> I would suggest either *always* installing the startup item (but  
> disabled by default), or creating a new port, <base port>-server,  
> that depends on the base port and declares only a startup item.
>
> The postgresql ports all provide "-server" ports -- you don't have  
> to rebuild the whole port just to add a startup item.
>
> In contrast, I can't tell you the number of times I had employees  
> accidentally build MySQL without the +server variant on their  
> workstation, and then have to rebuild it all again just for the  
> startup item.


Mhm. The mysql5 port should be changed. Here's the ticket:

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

There's also mysql5-devel. Should there be a separate mysql5-devel- 
server port? Or mysql5-server-devel? Or would the mysql5-server port  
be written to use either mysql5 or mysql5-devel? I'm thinking this  
last option is best if it's possible.


From ryandesign at macports.org  Fri Jul 25 13:09:48 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 25 Jul 2008 15:09:48 -0500
Subject: [MacPorts] #16048: lv2core:  new port
In-Reply-To: <4889F8E5.2000608@gmail.com>
References: <054.3b8adbf8e11dda4570728937aef62fdf@macports.org>
	<063.7f53508ab6c00f9d2bcb3fa8ac66747c@macports.org>
	<4889F8E5.2000608@gmail.com>
Message-ID: <0EE670B9-A935-473F-8768-4AFC38FD8B30@macports.org>


On Jul 25, 2008, at 11:01, David Evans wrote:

> MacPorts wrote:
>
>> #16048: lv2core:  new port
>> --------------------------------- 
>> +------------------------------------------
>>   Reporter:  db.evans at gmail.com  |       Owner:   
>> ryandesign at macports.org
>>       Type:  enhancement         |      Status:   
>> assigned                 Priority:  Normal              |    
>> Milestone:  Port Submissions        Component:   
>> ports               |     Version:  1.6.0                   
>> Resolution:                      |     
>> Keywords:                         --------------------------------- 
>> +------------------------------------------
>> Changes (by ryandesign at macports.org):
>>   * owner:  macports-tickets at lists.macosforge.org =>
>>             ryandesign at macports.org
>>   * status:  new => assigned
>> Comment:
>>  I added the port in r38544. Thanks!
>>  Question: why is gawk listed as a dependency? It installs for me  
>> without
>>  complaint even when gawk is absent. That's on 10.4.11 Intel.
>>  Also: this port doesn't install any binaries or libraries, right?  
>> Given
>>  that, can I add "`universal_variant no`" to the portfile?
>
> I added gawk because the configure script explicitly checks for it  
> and it was my understanding that the MacPorts policy was to use  
> ports in preference to Apple installed software.  However, if you  
> see no need for it, I have no problem removing it.

You're right that we do want to use MacPorts software instead of  
system software...

But I think configure will always check for gawk and other itty bitty  
utilities like that, even if the software doesn't need it. This would  
mean we would need to add gawk as a dependency to every port that  
uses autoconf. Even gawk's configure script checks for gawk!

So for dependencies like awk and sed and grep I think it is ok to use  
the versions of these utilities included with Mac OS X, if they work  
for the given port. Maybe the distinction that should be made in the  
Guide is that build-time dependencies can be supplied by Mac OS X if  
they work, while runtime and library dependencies should be supplied  
by MacPorts (excepting X11, Kerberos, ...)? Does that make sense to  
everyone?


> And yes, the port only installs necessary include pkgconfig files  
> that are required by other software (such as the slv2 port) to  
> implement the
> lv2 plugin standard.  So, as you say, the concept of a  
> universal_variant is not meaningful here.

Ok, thanks, I removed the universal variant.

-Ryan


From ryandesign at macports.org  Fri Jul 25 13:14:22 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 25 Jul 2008 15:14:22 -0500
Subject: [MacPorts] #16051: ardour2: new port
In-Reply-To: <4889FF0C.6010100@gmail.com>
References: <054.28746b42c34c31b6890bfda73ebdf476@macports.org>
	<063.c160fee0af162d1c0ffb7324afa7b969@macports.org>
	<4889FF0C.6010100@gmail.com>
Message-ID: <81B90218-B787-4019-BD4A-B27FAA087163@macports.org>


On Jul 25, 2008, at 11:27, David Evans wrote:

> MacPorts wrote:
>> #16051: ardour2: new port
>> --------------------------------- 
>> +------------------------------------------
>>   Reporter:  db.evans at gmail.com  |       Owner:   
>> ryandesign at macports.org
>>       Type:  enhancement         |      Status:   
>> closed                   Priority:  Normal              |    
>> Milestone:  Port Submissions        Component:   
>> ports               |     Version:  1.6.0                   
>> Resolution:  fixed               |    Keywords:   
>> ardour                 --------------------------------- 
>> +------------------------------------------
>> Changes (by ryandesign at macports.org):
>>   * status:  assigned => closed
>>   * resolution:  => fixed
>> Comment:
>>  Rather than clearing the build phase, the correct way seems to be  
>> to set
>>  `build.cmd` to "`scons`", clear the `build.target`, and set the
>>  `build.args` as desired. MacPorts takes care of setting  
>> `destroot.cmd` to
>>  the same thing as `build.cmd`, setting `destroot.target` to  
>> "`install`"
>>  and setting `destroot.destdir` to "`DESTDIR=${destroot}`".
>>  {{{
>>  build.cmd               scons
>>  build.target
>>  build.args              PREFIX=${prefix} VST=0 AUBIO=1  
>> FREESOUND=1 LV2=1
>>  }}}
>>  This change also means that parallel building will work now, since I
>>  enabled parallel building for scons-based ports in MacPorts base in
>>  r38556. This helps a lot since ardour takes a long time to  
>> compile. So I
>>  added "`use_parallel_build yes`" to the portfile, and reindented the
>>  column to 24 characters so things line up again.
>>  The one remaining oddity is that it looks like the gettext message
>>  catalogs get built only during the destroot phase. Not sure why.  
>> But I'm
>>  not too concerned since it takes very little time to build the  
>> message
>>  catalogs, compared with how much time it takes to build the rest of
>>  ardour.
>>  So the port is now added in r38560. Thanks for the contribution!  
>> And I
>>  hope you'll forgive my interfering in your port here.
>
> Again, thanks for your help with this.  My original approach was  
> based on my understanding that I needed to declare DESTDIR during  
> the scons build phase and scons refused to proceed at build time  
> because ${destroot} did not yet exist.

I noticed that too. I haven't used scons before so I was muddling  
through it.

> Hence deferred everything to destroot.
> So thanks for your suggestions.  They clear up some points that are
> not so clear from the guide documentation.
>
> I wonder if you have actually tried using the port.

Only to the point of opening it and getting its fatal error message  
about there not being a suitable audio device, about which I'm  
advised to complain to Apple or adjust my Jack settings.

> It works for me at
> a minimal level if you configure things properly but the audio output
> breaks up a lot.  According to the mac osx developers on chat the  
> problem is with the current released version of jack (0.109.2).  They
> recommended the svn version which advertises itself as 0.111.0 but its
> still got some instabilities.

We could add a jack-devel port for that version if desired.

> Looks like the correct solution is to use
> jackdmp (C++ implementation of the jack api that supports multiple  
> processors) but ardour2 compiled against jack will not work with  
> it.  So
> ardour2 needs to be compiled against whichever version of jack your  
> using for jackd/jackdmp since that package provides both the server  
> and
> matching client library.  Am working on this now and so am thinking of
> of adding variants to ardour2 to allow the user to select which  
> jack port to build against.  Of course, jack and jackdmp would  
> conflict with
> each other in terms of the installed binaries so only one can be  
> active at a given time.  Any suggestions?

Variants for this in the ardour2 port sound reasonable.

> At any rate, I'm grateful for your suggestions and improvements as  
> well
> your help in getting these ports committed.



From ram at macports.org  Sat Jul 26 20:23:24 2008
From: ram at macports.org (Adam Mercer)
Date: Sat, 26 Jul 2008 22:23:24 -0500
Subject: python binary symlinks in Framework build
Message-ID: <799406d60807262023m48c427fj209c7d58aeffcc03@mail.gmail.com>

Hi

In investigating a NumPy build problem I think I have found an issue
related to the python Framework builds. NumPy, and many other python
modules, use the python code os.path.basename(sys.executable) to
return the path to the current running executable for setting which
interpreter to use. This is $prefix/bin/python2.5, but as this is a
symlink to the Python binary within the framework directory
sys.executable is returning
/opt/local/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python
which will be shortened to simply Python after the basename call.

As $prefix/bin/Python is a symlink created by python_select this is
clearly going to cause problems if the default python interpreter is
changed with python_select.

Can anyone see a solution to this without having to heavily patch the
NumPy source?

Cheers

Adam

From 0x62_0x6c_0x62 at pobox.com  Sat Jul 26 20:48:49 2008
From: 0x62_0x6c_0x62 at pobox.com (Bryan Blackburn)
Date: Sat, 26 Jul 2008 21:48:49 -0600
Subject: python binary symlinks in Framework build
In-Reply-To: <799406d60807262023m48c427fj209c7d58aeffcc03@mail.gmail.com>
References: <799406d60807262023m48c427fj209c7d58aeffcc03@mail.gmail.com>
Message-ID: <10F3FC7E-1814-4421-8E89-B5592052C28E@pobox.com>

On Jul 26, 2008, at 9:23 PM, Adam Mercer wrote:

> Hi
>
> In investigating a NumPy build problem I think I have found an issue
> related to the python Framework builds. NumPy, and many other python
> modules, use the python code os.path.basename(sys.executable) to
> return the path to the current running executable for setting which
> interpreter to use. This is $prefix/bin/python2.5, but as this is a
> symlink to the Python binary within the framework directory
> sys.executable is returning
> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/ 
> Resources/Python.app/Contents/MacOS/Python
> which will be shortened to simply Python after the basename call.
>

Actually, ${prefix}/bin/python2.5 isn't a symlink, but that obviously  
doesn't change what sys.executable returns.

Note, however, that this is how Apple's python works too:

$ /usr/bin/python
Python 2.5.1 (r251:54863, Apr 15 2008, 22:57:26)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import sys
 >>> print sys.executable
/System/Library/Frameworks/Python.framework/Versions/2.5/Resources/ 
Python.app/Contents/MacOS/Python

So it seems like the same basename trick would return Python here,  
which works on a case-insensitive FS but I'm guessing would fail on  
sensitive ones?

> As $prefix/bin/Python is a symlink created by python_select this is
> clearly going to cause problems if the default python interpreter is
> changed with python_select.
>

I think python_select is pretty much required at this point, as  
otherwise linking against the framework doesn't work properly without  
python_select'ing python25.

> Can anyone see a solution to this without having to heavily patch the
> NumPy source?
>

Is this about ticket 15865?  Maybe the shebang line can be changed  
with a reinplace?

Bryan


> Cheers
>
> Adam

From ram at macports.org  Sat Jul 26 23:37:56 2008
From: ram at macports.org (Adam Mercer)
Date: Sun, 27 Jul 2008 01:37:56 -0500
Subject: python binary symlinks in Framework build
In-Reply-To: <10F3FC7E-1814-4421-8E89-B5592052C28E@pobox.com>
References: <799406d60807262023m48c427fj209c7d58aeffcc03@mail.gmail.com>
	<10F3FC7E-1814-4421-8E89-B5592052C28E@pobox.com>
Message-ID: <799406d60807262337g3eeeb935q6a89758f15faef87@mail.gmail.com>

On Sat, Jul 26, 2008 at 10:48 PM, Bryan Blackburn
<0x62_0x6c_0x62 at pobox.com> wrote:

> Actually, ${prefix}/bin/python2.5 isn't a symlink, but that obviously
> doesn't change what sys.executable returns.

Thats a good point, so shy does sys.executable return the Framework binary?

> Note, however, that this is how Apple's python works too:
>
> $ /usr/bin/python
> Python 2.5.1 (r251:54863, Apr 15 2008, 22:57:26)
> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import sys
>  >>> print sys.executable
> /System/Library/Frameworks/Python.framework/Versions/2.5/Resources/
> Python.app/Contents/MacOS/Python
>
> So it seems like the same basename trick would return Python here,
> which works on a case-insensitive FS but I'm guessing would fail on
> sensitive ones?

True, but just because that is the way the Apple does it does not mean
it is the correct way.

>> As $prefix/bin/Python is a symlink created by python_select this is
>> clearly going to cause problems if the default python interpreter is
>> changed with python_select.
>
> I think python_select is pretty much required at this point, as
> otherwise linking against the framework doesn't work properly without
> python_select'ing python25.

In that case we need to think about how the current ports system
handles python ports, as if it is required that people run
python_select before the different python ports will work then that
will only lead to problems!

>> Can anyone see a solution to this without having to heavily patch the
>> NumPy source?
>
> Is this about ticket 15865?  Maybe the shebang line can be changed
> with a reinplace?

It is, and that would indeed solve the problem but I would prefer this
problem be solved in python25 and not in the individual python ports.

Cheers

Adam

From 0x62_0x6c_0x62 at pobox.com  Sun Jul 27 01:54:14 2008
From: 0x62_0x6c_0x62 at pobox.com (Bryan Blackburn)
Date: Sun, 27 Jul 2008 02:54:14 -0600
Subject: python binary symlinks in Framework build
In-Reply-To: <799406d60807262337g3eeeb935q6a89758f15faef87@mail.gmail.com>
References: <799406d60807262023m48c427fj209c7d58aeffcc03@mail.gmail.com>
	<10F3FC7E-1814-4421-8E89-B5592052C28E@pobox.com>
	<799406d60807262337g3eeeb935q6a89758f15faef87@mail.gmail.com>
Message-ID: <66ECC678-51DD-4312-B202-8E3A364827CF@pobox.com>

On Jul 27, 2008, at 12:37 AM, Adam Mercer wrote:

> On Sat, Jul 26, 2008 at 10:48 PM, Bryan Blackburn
> <0x62_0x6c_0x62 at pobox.com> wrote:
>
>> Actually, ${prefix}/bin/python2.5 isn't a symlink, but that obviously
>> doesn't change what sys.executable returns.
>
> Thats a good point, so shy does sys.executable return the Framework  
> binary?
>

Good question, calculate_path() does most of the work, but there's  
quite a bit to it:

<http://svn.python.org/view/python/tags/r252/Modules/getpath.c?rev=60915&view=auto 
 >

>> Note, however, that this is how Apple's python works too:
>>
>> $ /usr/bin/python
>> Python 2.5.1 (r251:54863, Apr 15 2008, 22:57:26)
>> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
>> Type "help", "copyright", "credits" or "license" for more  
>> information.
>>>>> import sys
>>>>> print sys.executable
>> /System/Library/Frameworks/Python.framework/Versions/2.5/Resources/
>> Python.app/Contents/MacOS/Python
>>
>> So it seems like the same basename trick would return Python here,
>> which works on a case-insensitive FS but I'm guessing would fail on
>> sensitive ones?
>
> True, but just because that is the way the Apple does it does not mean
> it is the correct way.
>

I mention this because anyone installing, say, numpy with the Apple- 
provided version must be doing something about this as well.  Not to  
mention we can't exactly look to other OS's to see how they do  
framework installs...

>>> As $prefix/bin/Python is a symlink created by python_select this is
>>> clearly going to cause problems if the default python interpreter is
>>> changed with python_select.
>>
>> I think python_select is pretty much required at this point, as
>> otherwise linking against the framework doesn't work properly without
>> python_select'ing python25.
>
> In that case we need to think about how the current ports system
> handles python ports, as if it is required that people run
> python_select before the different python ports will work then that
> will only lead to problems!
>

Note the post activate section of python25 already basically suggests  
this:

post-activate {
     ui_msg "\nTo fully complete your installation and make python  
$branch the default, please run
\n\tsudo port install python_select \
\n\tsudo python_select $name\n"
}

>>> Can anyone see a solution to this without having to heavily patch  
>>> the
>>> NumPy source?
>>
>> Is this about ticket 15865?  Maybe the shebang line can be changed
>> with a reinplace?
>
> It is, and that would indeed solve the problem but I would prefer this
> problem be solved in python25 and not in the individual python ports.
>

Of course replacing the shebang line would truly tie it to the proper  
python if you used ${prefix}/bin/python2.5, which protects against  
both the issue with env if ${prefix}/bin is after /usr/bin in PATH, as  
well as when multiple python versions are installed with MacPorts.  If  
someone has python25 and python26, but does a python_select on 2.6,  
all py25- ports using env will now most likely break...

Probably the best place for this is perhaps an addition to the python  
group code to specify scripts to be installed, and have that rewrite  
shebang lines as appropriate maybe?

Bryan


> Cheers
>
> Adam

From lists-macports at shopwatch.org  Sun Jul 27 09:46:21 2008
From: lists-macports at shopwatch.org (Jay Levitt)
Date: Sun, 27 Jul 2008 12:46:21 -0400
Subject: postgresql83, binaries, and paths?
Message-ID: <488CA65D.3090901@shopwatch.org>

I'm setting up a new Mac for Ruby development, and I tried installing the 
postgresql83 and postgresql83-server ports.  But I couldn't install Ruby's 
postgresql gem.  A little digging turned this up:

1. The postgres ports install the pg_config binary (among others) into 
/opt/local/lib/postgresql83/bin/pg_config.  However, they don't add that 
directory to PATH.  Should they?  What's the convention for ports and paths? 
   Given the nice clean paths.d support in Leopard, I'd think they should 
use it.

2. Why is that ending up in lib, anyway?  A clean build from the 8.3.3 
source puts those files in /usr/local/pgsql/bin, which makes a little more 
sense... I think...

3. The port makes a half-hearted attempt to get psql into your path: it 
creates a link from /opt/local/bin/psql83 to 
/opt/local/lib/postgresql83/bin/psql.  That seems odd too. If the philosophy 
is to make it "just work", nobody's going to be typing "psql83"; they'll be 
looking for "psql".  But if the philosophy is that users should be able to 
do side-by-side installs and roll their own "psql-select", then why create 
the link at all?

What do folks think?

Jay Levitt

From ryandesign at macports.org  Sun Jul 27 10:59:47 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 27 Jul 2008 12:59:47 -0500
Subject: postgresql83, binaries, and paths?
In-Reply-To: <488CA65D.3090901@shopwatch.org>
References: <488CA65D.3090901@shopwatch.org>
Message-ID: <5C591549-20C4-46A9-A974-F9B041978064@macports.org>

On Jul 27, 2008, at 11:46, Jay Levitt wrote:

> I'm setting up a new Mac for Ruby development, and I tried  
> installing the
> postgresql83 and postgresql83-server ports.  But I couldn't install  
> Ruby's
> postgresql gem.  A little digging turned this up:
>
> 1. The postgres ports install the pg_config binary (among others) into
> /opt/local/lib/postgresql83/bin/pg_config.  However, they don't add  
> that
> directory to PATH.  Should they?  What's the convention for ports  
> and paths?

Ports can't add anything to the PATH. There is no mechanism for this  
in MacPorts (no portfile syntax to allow this).

>    Given the nice clean paths.d support in Leopard, I'd think they  
> should
> use it.

Not all users have Leopard (or even Mac OS X). Also, we decided  
against using paths.d for MacPorts base even on Leopard because it  
adds paths at the end of PATH instead of at the beginning like we want.

> 2. Why is that ending up in lib, anyway?  A clean build from the 8.3.3
> source puts those files in /usr/local/pgsql/bin, which makes a  
> little more
> sense... I think...

There are multiple versions of postgresql available in MacPorts which  
can be installed simultaneously, so they can't all install to the  
same place.

> 3. The port makes a half-hearted attempt to get psql into your  
> path: it
> creates a link from /opt/local/bin/psql83 to
> /opt/local/lib/postgresql83/bin/psql.  That seems odd too. If the  
> philosophy
> is to make it "just work", nobody's going to be typing "psql83";  
> they'll be
> looking for "psql".  But if the philosophy is that users should be  
> able to
> do side-by-side installs and roll their own "psql-select", then why  
> create
> the link at all?

I believe the intention is that users should be able to  
simultaneously install multiple versions of postgresql. As to rolling  
your own psql-select, we already have gcc_select and python_select  
ports; a postgresql_select port could be added if that would be useful.


From lists-macports at shopwatch.org  Sun Jul 27 14:20:05 2008
From: lists-macports at shopwatch.org (Jay Levitt)
Date: Sun, 27 Jul 2008 17:20:05 -0400
Subject: postgresql83, binaries, and paths?
In-Reply-To: <5C591549-20C4-46A9-A974-F9B041978064@macports.org>
References: <488CA65D.3090901@shopwatch.org>
	<5C591549-20C4-46A9-A974-F9B041978064@macports.org>
Message-ID: <488CE685.7090709@shopwatch.org>

Ryan Schmidt wrote:
> On Jul 27, 2008, at 11:46, Jay Levitt wrote:
> 
>> I'm setting up a new Mac for Ruby development, and I tried installing the
>> postgresql83 and postgresql83-server ports.  But I couldn't install 
>> Ruby's
>> postgresql gem.  A little digging turned this up:
>>
>> 1. The postgres ports install the pg_config binary (among others) into
>> /opt/local/lib/postgresql83/bin/pg_config.  However, they don't add that
>> directory to PATH.  Should they?  What's the convention for ports and 
>> paths?
> 
> Ports can't add anything to the PATH. There is no mechanism for this in 
> MacPorts (no portfile syntax to allow this).
> 
>>    Given the nice clean paths.d support in Leopard, I'd think they should
>> use it.
> 
> Not all users have Leopard (or even Mac OS X). Also, we decided against 
> using paths.d for MacPorts base even on Leopard because it adds paths at 
> the end of PATH instead of at the beginning like we want.

All true.  But, that said: If the alternative is no PATH support at all, and 
if a port can create a file in /etc/paths.d (and I assume it can), isn't 
that the lesser of two evils?

>> 2. Why is that ending up in lib, anyway?  A clean build from the 8.3.3
>> source puts those files in /usr/local/pgsql/bin, which makes a little 
>> more
>> sense... I think...
> 
> There are multiple versions of postgresql available in MacPorts which 
> can be installed simultaneously, so they can't all install to the same 
> place.

Sorry, I meant that .../bin makes more sense than .../lib/.../bin.  i.e. I'd 
expect to see those binaries in /opt/local/postgresql83/bin... is there an 
advantage to /opt/local/lib/postgresql83?

>> 3. The port makes a half-hearted attempt to get psql into your path: it
>> creates a link from /opt/local/bin/psql83 to
>> /opt/local/lib/postgresql83/bin/psql.  That seems odd too. If the 
>> philosophy
>> is to make it "just work", nobody's going to be typing "psql83"; 
>> they'll be
>> looking for "psql".  But if the philosophy is that users should be 
>> able to
>> do side-by-side installs and roll their own "psql-select", then why 
>> create
>> the link at all?
> 
> I believe the intention is that users should be able to simultaneously 
> install multiple versions of postgresql. As to rolling your own 
> psql-select, we already have gcc_select and python_select ports; a 
> postgresql_select port could be added if that would be useful.

A reasonable intention.  But then why bother linking psql (and only psql), 
and under a name where nobody's looking for it?

I realize the answer to all these questions may be "because that's the way 
someone wrote it once"; in that case, pretend I'm asking "would a patch to 
change that be welcomed/a good idea/grudgingly accepted/treated as a 
maternal-lineage insult?"

From ryandesign at macports.org  Sun Jul 27 15:09:58 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 27 Jul 2008 17:09:58 -0500
Subject: [MacPorts] Notification: howto/SetupTracAjpWsgi added
In-Reply-To: <077.755cde492a300ae15fb622b1f48e5395@macports.org>
References: <077.755cde492a300ae15fb622b1f48e5395@macports.org>
Message-ID: <DD1F5751-91DF-48B6-9EE3-9D685A70D97C@macports.org>

Why is Leopard required?


On Jul 27, 2008, at 16:03, MacPorts wrote:

> Added page "howto/SetupTracAjpWsgi" by blb at macports.org from  
> 75.163.189.154*
> Page URL: <http://trac.macports.org/wiki/howto/SetupTracAjpWsgi>
> Comment: New HOWTO on running Trac with ajp-wsgi
> Content:
>
> [wiki:howto <- Back to the HOWTO section]
>
> = How to use Trac with ajp-wsgi and Apache =
>
>  * Audience: Those who want to use Trac within a separate process  
> from apache
>  * Requires: MacPorts >=1.6, Mac OS X 10.5
>
> == Introduction ==
>
> There are several ways to run Trac with Apache: [http:// 
> trac.edgewall.org/wiki/TracModWSGI mod_wsgi], [http:// 
> trac.edgewall.org/wiki/TracModPython mod_python], and [http:// 
> www.saddi.com/software/ajp-wsgi/ ajp-wsgi] (and probably  
> others...).  This discusses how to get it working with ajp-wsgi,  
> which runs as a single separate process from Apache's httpd.  ajp- 
> wsgi uses the [http://tomcat.apache.org/connectors-doc/ajp/ 
> ajpv13a.html Apache JServ Protocol] to communicate with Apache,  
> hence needs some configuration done in httpd.conf.
>
> == Installation ==
>
> Install the necessary ports with:
> {{{
> sudo port install apache2
> sudo port install trac
> sudo port install ajp-wsgi +python25
> }}}
> The {{{+python25}}} variant was selected for ajp-wsgi to use the  
> current Python version, and Trac prefers 2.5 as well so this keeps  
> them using the same version.  By default, ajp-wsgi would otherwise  
> depend on python24.
>
> == Configuration ==
>
> === Configuring ajp-wsgi ===
>
> First, ajp-wsgi needs to be setup to run with a launchd item.   
> Create a new launchd plist in {{{/Library/LaunchDaemons}}} called  
> {{{com.example.ajp-wsgi.plist}}} (change com.example to suit your  
> network) with {{{sudo vi /Library/LaunchDaemons/com.example.ajp- 
> wsgi.plist}}} (or a different editor you can run as root).  Place  
> the following into this new file
> {{{
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http:// 
> www.apple.com/DTDs/PropertyList-1.0.dtd">
> <plist version="1.0">
> <dict>
> 	<key>EnvironmentVariables</key>
> 	<dict>
> 		<key>PYTHONHOME</key>
> 		<string>/opt/local</string>
> 		<key>PYTHON_EGG_CACHE</key>
> 		<string>/usr/local/trac/.python-egg-cache</string>
> 		<key>TRAC_ENV_PARENT_DIR</key>
> 		<string>/usr/local/trac</string>
> 	</dict>
> 	<key>GroupName</key>
> 	<string>_www</string>
> 	<key>KeepAlive</key>
> 	<true/>
> 	<key>Label</key>
> 	<string>com.example.ajp-wsgi</string>
> 	<key>ProgramArguments</key>
> 	<array>
> 		<string>/opt/local/bin/ajp-wsgi</string>
> 		<string>-p</string>
> 		<string>8990</string>
> 		<string>trac.web.main</string>
> 		<string>dispatch_request</string>
> 		<string>/projects</string>
> 	</array>
> 	<key>UserName</key>
> 	<string>_www</string>
> 	<key>WorkingDirectory</key>
> 	<string>/usr/local/trac</string>
> </dict>
> </plist>
> }}}
> Be sure to replace {{{/usr/local/trac}}} with the location of your  
> actual Trac project location.  This example uses  
> {{{TRAC_ENV_PARENT_DIR}}} which allows for multiple Trac projects  
> to be located as subdirectories under that path.
>
> Also note the {{{/projects}}} part being passed to ajp-wsgi, which  
> tells it that all the Trac projects will be accessed with a URL  
> whose path starts with {{{/projects}}}.
>
> === Configuring Apache2 ===
> Edit {{{/opt/local/apache2/conf/httpd.conf}}} in a text editor, and  
> in the section pertinent to your server and how you want Trac  
> accessed, add
> {{{
>    ProxyPass /projects/ ajp://localhost:8990/projects
>    <Proxy */projects/*>
>       Order Allow,Deny
>       Allow from all
>    </Proxy>
> }}}
> This tells Apache that requests to {{{/projects/*}}} to be proxied  
> over to localhost's port 8990 (which is where ajp-wsgi is  
> listening, as specified above).  This excerpt can be placed in the  
> main portion of {{{httpd.conf}}} or in a <VirtualHost> section,  
> depending on your needs.
>
> === Configuring Trac ===
> Setup Trac as specified in [http://trac.edgewall.org/wiki/ 
> TracInstall#CreatingaProjectEnvironment Creating a Project  
> Environment].  Since this example uses the multiple-projects-in-a- 
> directory, be sure to use a subdirectory as the project  
> environment; for example, with the {{{/usr/local/trac}}} location  
> used above:
> {{{
> trac-admin /usr/local/trac/myproject initenv
> }}}
> Make sure everything in {{{/usr/local/trac}}} is owned by the user  
> _www as that's how ajp-wsgi is running, which will need write  
> access so Trac can update files.
>
> == Testing ==
>
> Try loading {{{http://www.example.com/projects/myproject}}}  
> (replacing the domain and myproject as appropriate) and you should  
> see the Trac page.
>
> [wiki:howto <- Back to the HOWTO section]
>
>
> * The IP shown here might not mean anything if the user is behind a  
> proxy.


From 0x62_0x6c_0x62 at pobox.com  Sun Jul 27 16:07:20 2008
From: 0x62_0x6c_0x62 at pobox.com (Bryan Blackburn)
Date: Sun, 27 Jul 2008 17:07:20 -0600
Subject: [MacPorts] Notification: howto/SetupTracAjpWsgi added
In-Reply-To: <DD1F5751-91DF-48B6-9EE3-9D685A70D97C@macports.org>
References: <077.755cde492a300ae15fb622b1f48e5395@macports.org>
	<DD1F5751-91DF-48B6-9EE3-9D685A70D97C@macports.org>
Message-ID: <3D211F83-95B2-45FD-9F8F-7DCF76B274F7@pobox.com>

On Jul 27, 2008, at 4:09 PM, Ryan Schmidt wrote:

> Why is Leopard required?
>

Partly, the _www user and group would need to be just www, and mostly  
because that's where I'm currently running it.  While I was running  
ajp-wsgi on 10.4 basically like this, I don't recall what changes, if  
any, had to be made to work on 10.5 (beyond _www/www of course).

If someone makes it work this way on 10.4, then the howto can be  
updated to be 10.4+ instead.  I just didn't want to claim that without  
being sure...

Bryan


>
> On Jul 27, 2008, at 16:03, MacPorts wrote:
>
>> Added page "howto/SetupTracAjpWsgi" by blb at macports.org from
>>
...

From ryandesign at macports.org  Sun Jul 27 22:44:34 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 28 Jul 2008 00:44:34 -0500
Subject: [38660] trunk/dports/sysutils/bacula/Portfile
In-Reply-To: <20080728005325.BA1E6190C98@beta.macosforge.org>
References: <20080728005325.BA1E6190C98@beta.macosforge.org>
Message-ID: <AF1C5C35-D03E-4778-AE35-1238ACB1EEF1@macports.org>

On Jul 27, 2008, at 19:53, macsforever2000 at macports.org wrote:

> Revision: 38660
>           http://trac.macosforge.org/projects/macports/changeset/38660
> Author:   macsforever2000 at macports.org
> Date:     2008-07-27 17:53:24 -0700 (Sun, 27 Jul 2008)
> Log Message:
> -----------
> Updated to version 2.4.1. Fixed so that it compiles filed and  
> others now. Fixed datarootdir. Added macsforever2000 as maintainer.  
> Added variants for client_only, mysql4, mysql5, postgresql83,  
> sqlite2, sqlite3. Thanks to blb for help with compile issues.
>
> Modified Paths:
> --------------
>     trunk/dports/sysutils/bacula/Portfile


> +variant client_only conflicts mysql4 mysql5 postgresql83 sqlite2  
> sqlite3 description "Install bacula client (bacula-fd) only" {
> +    configure.args-append --enable-client-only
> +}
> +
> +variant mysql4 conflicts client-only mysql5 postgresql83 sqlite2  
> sqlite3 description "Install bacula client and server with mysql 4  
> backend" {

You should replace occurrences of "client-only" in the "conflicts"  
section with "client_only" to match the variant name.

> +  depends_lib-append    port:mysql4
> +  configure.args-append --with-mysql=${prefix}
> +  configure.args-delete --without-mysql
> +}
> +
> +variant mysql5 conflicts client-only mysql4 postgresql83 sqlite2  
> sqlite3 description "Install bacula client and server with mysql 5  
> backend" {
> +  depends_lib-append    port:mysql5
> +  configure.args-append --with-mysql=${prefix}
> +  configure.args-delete --without-mysql
> +}
> +
> +variant postgresql83 conflicts mysql4 mysql5 sqlite2 sqlite3  
> client-only description "Install bacula client and server with  
> postgresql 8.3 backend" {
> +  depends_lib-append    port:postgresql83
> +  configure.args-append --with-postgresql=${prefix}
> +  configure.args-delete --without-postgresql
> +}
> +
> +variant sqlite2 conflicts client-only sqlite3 mysql4 mysql5  
> postgresql83 description "Install bacula client and server with  
> sqlite 2 backend" {
> +  depends_lib-append    port:sqlite2
> +  configure.args-append --with-sqlite=${prefix}
> +  configure.args-delete --without-sqlite
> +}
> +
> +variant sqlite3 conflicts client-only sqlite2 mysql4 mysql5  
> postgresql83 description "Install bacula client and server with  
> sqlite 3 backend" {
> +  depends_lib-append    port:sqlite3
> +  configure.args-append --with-sqlite3=${prefix}
> +  configure.args-delete --without-sqlite3
> +}
> +
> +default_variants        +client_only

You should only make client_only the default variant if the user has  
not already selected a conflicting variant. So do:

if {![variant_isset mysql4] && ![variant_isset mysql5] && ! 
[variant_isset postgresql83] && ![variant_isset sqlite2] && ! 
[variant_isset sqlite3]} {
	default_variants +client_only
}

See e.g. the pdftk and minivmac ports.


From macsforever2000 at macports.org  Mon Jul 28 07:53:03 2008
From: macsforever2000 at macports.org (Frank Schima)
Date: Mon, 28 Jul 2008 08:53:03 -0600
Subject: [38660] trunk/dports/sysutils/bacula/Portfile
In-Reply-To: <AF1C5C35-D03E-4778-AE35-1238ACB1EEF1@macports.org>
References: <20080728005325.BA1E6190C98@beta.macosforge.org>
	<AF1C5C35-D03E-4778-AE35-1238ACB1EEF1@macports.org>
Message-ID: <E4F7B6DD-C09A-45C9-93D3-F5FD3772A48A@macports.org>

Hi Ryan,


On Jul 27, 2008, at 11:44 PM, Ryan Schmidt wrote:

> On Jul 27, 2008, at 19:53, macsforever2000 at macports.org wrote:
>
>> Revision: 38660
>>          http://trac.macosforge.org/projects/macports/changeset/38660
>> Author:   macsforever2000 at macports.org
>> Date:     2008-07-27 17:53:24 -0700 (Sun, 27 Jul 2008)
>> Log Message:
>> -----------
>> Updated to version 2.4.1. Fixed so that it compiles filed and  
>> others now. Fixed datarootdir. Added macsforever2000 as maintainer.  
>> Added variants for client_only, mysql4, mysql5, postgresql83,  
>> sqlite2, sqlite3. Thanks to blb for help with compile issues.
>>
>> Modified Paths:
>> --------------
>>    trunk/dports/sysutils/bacula/Portfile
>
>
>> +variant client_only conflicts mysql4 mysql5 postgresql83 sqlite2  
>> sqlite3 description "Install bacula client (bacula-fd) only" {
>> +    configure.args-append --enable-client-only
>> +}
>> +
>> +variant mysql4 conflicts client-only mysql5 postgresql83 sqlite2  
>> sqlite3 description "Install bacula client and server with mysql 4  
>> backend" {
>
> You should replace occurrences of "client-only" in the "conflicts"  
> section with "client_only" to match the variant name.

Good catch.

>> +  depends_lib-append    port:mysql4
>> +  configure.args-append --with-mysql=${prefix}
>> +  configure.args-delete --without-mysql
>> +}
>> +
>> +variant mysql5 conflicts client-only mysql4 postgresql83 sqlite2  
>> sqlite3 description "Install bacula client and server with mysql 5  
>> backend" {
>> +  depends_lib-append    port:mysql5
>> +  configure.args-append --with-mysql=${prefix}
>> +  configure.args-delete --without-mysql
>> +}
>> +
>> +variant postgresql83 conflicts mysql4 mysql5 sqlite2 sqlite3  
>> client-only description "Install bacula client and server with  
>> postgresql 8.3 backend" {
>> +  depends_lib-append    port:postgresql83
>> +  configure.args-append --with-postgresql=${prefix}
>> +  configure.args-delete --without-postgresql
>> +}
>> +
>> +variant sqlite2 conflicts client-only sqlite3 mysql4 mysql5  
>> postgresql83 description "Install bacula client and server with  
>> sqlite 2 backend" {
>> +  depends_lib-append    port:sqlite2
>> +  configure.args-append --with-sqlite=${prefix}
>> +  configure.args-delete --without-sqlite
>> +}
>> +
>> +variant sqlite3 conflicts client-only sqlite2 mysql4 mysql5  
>> postgresql83 description "Install bacula client and server with  
>> sqlite 3 backend" {
>> +  depends_lib-append    port:sqlite3
>> +  configure.args-append --with-sqlite3=${prefix}
>> +  configure.args-delete --without-sqlite3
>> +}
>> +
>> +default_variants        +client_only
>
> You should only make client_only the default variant if the user has  
> not already selected a conflicting variant. So do:
>
> if {![variant_isset mysql4] && ![variant_isset mysql5] && ! 
> [variant_isset postgresql83] && ![variant_isset sqlite2] && ! 
> [variant_isset sqlite3]} {
> 	default_variants +client_only
> }
>
> See e.g. the pdftk and minivmac ports.

I was wondering how to do that.

Changes committed in r38669. Thanks for the help!


Cheers!
Frank




From dluke at geeklair.net  Mon Jul 28 08:00:21 2008
From: dluke at geeklair.net (Daniel J. Luke)
Date: Mon, 28 Jul 2008 11:00:21 -0400
Subject: postgresql83, binaries, and paths?
In-Reply-To: <488CE685.7090709@shopwatch.org>
References: <488CA65D.3090901@shopwatch.org>
	<5C591549-20C4-46A9-A974-F9B041978064@macports.org>
	<488CE685.7090709@shopwatch.org>
Message-ID: <D3D171F4-8865-41CB-A35D-564FFEEDD61B@geeklair.net>

On Jul 27, 2008, at 5:20 PM, Jay Levitt wrote:
> A reasonable intention.  But then why bother linking psql (and only  
> psql),
> and under a name where nobody's looking for it?

Because 'normal' (non-macports) installs of postgres usually install  
into their own directory, so people using postgres often add the  
postgres specific bin/ directory to their path.

Using the macports postgres83 would be similar, and having the link  
there means you can just type 'psql' after munging your path.

> I realize the answer to all these questions may be "because that's  
> the way
> someone wrote it once"; in that case, pretend I'm asking "would a  
> patch to
> change that be welcomed/a good idea/grudgingly accepted/treated as a
> maternal-lineage insult?"

It's usually up to the maintainer to determine if a patch is a good  
idea or not (or how any ideas it has can be incorporated into the port).

[My personal opinion is that adding to the end of $PATH is a better  
idea, that we should use paths.d, and that we should deal with any  
problems this causes where a package picks up a system tool where we  
would rather have it pick up a macports tool - but obviously other  
people have different opinions :) ]

--
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/20080728/40c77379/attachment.bin 

From florian.ebeling at gmail.com  Mon Jul 28 15:02:33 2008
From: florian.ebeling at gmail.com (Caspar Florian Ebeling)
Date: Tue, 29 Jul 2008 00:02:33 +0200
Subject: [38646] trunk/doc-new/guide
In-Reply-To: <20080727043732.51C5F18C264@beta.macosforge.org>
References: <20080727043732.51C5F18C264@beta.macosforge.org>
Message-ID: <5cbbe4ae0807281502p2972b3d8i6e6416e4bdfd0db9@mail.gmail.com>

This change broke the build. Fixed it in r38687.

On Sun, Jul 27, 2008 at 6:37 AM,  <ryandesign at macports.org> wrote:
> Revision 38646 Author ryandesign at macports.org Date 2008-07-26 21:37:31 -0700
> (Sat, 26 Jul 2008)
>
> Log Message
>
> Our Trac now shows a text box instead of a menu of ticket assignees; update
> instructions and screenshot to match
>
> Modified Paths
>
> trunk/doc-new/guide/resources/images/trac-default.png
> trunk/doc-new/guide/xml/project.xml
>
> Diff
>
> Modified: trunk/doc-new/guide/resources/images/trac-default.png
>
> (Binary files differ)
>
> Modified: trunk/doc-new/guide/xml/project.xml (38645 => 38646)
>
> --- trunk/doc-new/guide/xml/project.xml	2008-07-27 03:08:48 UTC (rev 38645)
> +++ trunk/doc-new/guide/xml/project.xml	2008-07-27 04:37:31 UTC (rev 38646)
> @@ -169,12 +169,9 @@
>          <listitem>
>            <para><guilabel>Cc:</guilabel> Anyone else besides the ticket
>            reporter and assignee who would like to be kept involved in the
> -          development of the ticket, and/or the port maintainer in case
> -          his/her address does not appear in the <guimenu>Assign
> To</guimenu>
> -          drop down menu. Multiple emails should be separated with a comma
> +          development of the ticket. Multiple email addresses should be
> +          separated with a comma and a space
>            (i.e. <literal>you at example.org,
> maintainer at macports.org</literal>).
> -          To get the maintainer email address use <command>port info
> -          &lt;portname&gt;</command>.</para>
>          </listitem>
>
>          <listitem>
> @@ -237,18 +234,23 @@
>          </listitem>
>
>          <listitem>
> -          <para><guilabel>Assign To:</guilabel> For tickets on ports,
> select
> -          the port maintainer's email address (use <command>port info
> -          &lt;portname&gt;</command>). If the maintainer's email address is
> -          <email>nomaintainer at macports.org</email>, select
> -          <email>macports-tickets at lists.macosforge.org</email>.</para>
> +          <para><guilabel>Assign To:</guilabel> For tickets on ports, enter
> +          the email address of the port's maintainer (use <command>port
> info
> +          &lt;portname&gt;</command> to find this). If multiple maintainers
> +          are listed, enter the first maintainer's email address here and
> +          enter the remainining maintainers' email addresses in the
> +          <guimenu>Cc</guimenu> field. Exclude the email address
> +          <email>openmaintainer at macports.org</email> if it appears.
> +          If the maintainer's email address is
> +          <email>nomaintainer at macports.org</email>, leave the field
> +          blank.</para>
>          </listitem>
>
>          <listitem>
> -          <para><guilabel>Attachments:</guilabel> Files may be attached to
> a
> -          ticket when it is being created if the checkbox that reads
> &ldquo;I
> -          have files to attach to this ticket&rdquo; is selected, or after
> it
> -          has been submitted by using the file attachment button.</para>
> +          <para><guilabel>I have files to attach to this ticket:</guilabel>
> +          Use this checkbox to attach files to the ticket immediately after
> +          you create it. Or you can attach files later using the
> +          <guilabel>Attach File</guilabel> button.</para>
>          </listitem>
>        </itemizedlist>
>      </section>
>
> _______________________________________________
> macports-changes mailing list
> macports-changes at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes
>
>



-- 
Florian Ebeling
florian.ebeling at gmail.com

From ryandesign at macports.org  Mon Jul 28 16:10:00 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 28 Jul 2008 18:10:00 -0500
Subject: [38646] trunk/doc-new/guide
In-Reply-To: <5cbbe4ae0807281502p2972b3d8i6e6416e4bdfd0db9@mail.gmail.com>
References: <20080727043732.51C5F18C264@beta.macosforge.org>
	<5cbbe4ae0807281502p2972b3d8i6e6416e4bdfd0db9@mail.gmail.com>
Message-ID: <33E7A61A-756D-45C3-8F81-A44B9C0B649B@macports.org>

Thanks for catching that. Is there some script I'm meant to run  
before committing changes to the documentation, to make sure I'm not  
breaking something?


On Jul 28, 2008, at 17:02, Caspar Florian Ebeling wrote:

> This change broke the build. Fixed it in r38687.
>
> On Sun, Jul 27, 2008 at 6:37 AM,  wrote:
>
>> Revision 38646 Author ryandesign at macports.org Date 2008-07-26  
>> 21:37:31 -0700
>> (Sat, 26 Jul 2008)
>>
>> Log Message
>>
>> Our Trac now shows a text box instead of a menu of ticket  
>> assignees; update
>> instructions and screenshot to match
>>
>> Modified Paths
>>
>> trunk/doc-new/guide/resources/images/trac-default.png
>> trunk/doc-new/guide/xml/project.xml
>>
>> Diff
>>
>> Modified: trunk/doc-new/guide/resources/images/trac-default.png
>>
>> (Binary files differ)
>>
>> Modified: trunk/doc-new/guide/xml/project.xml (38645 => 38646)
>>
>> --- trunk/doc-new/guide/xml/project.xml	2008-07-27 03:08:48 UTC  
>> (rev 38645)
>> +++ trunk/doc-new/guide/xml/project.xml	2008-07-27 04:37:31 UTC  
>> (rev 38646)
>> @@ -169,12 +169,9 @@
>>          <listitem>
>>            <para><guilabel>Cc:</guilabel> Anyone else besides the  
>> ticket
>>            reporter and assignee who would like to be kept  
>> involved in the
>> -          development of the ticket, and/or the port maintainer  
>> in case
>> -          his/her address does not appear in the <guimenu>Assign
>> To</guimenu>
>> -          drop down menu. Multiple emails should be separated  
>> with a comma
>> +          development of the ticket. Multiple email addresses  
>> should be
>> +          separated with a comma and a space
>>            (i.e. <literal>you at example.org,
>> maintainer at macports.org</literal>).
>> -          To get the maintainer email address use <command>port info
>> -          &lt;portname&gt;</command>.</para>
>>          </listitem>
>>
>>          <listitem>

From markd at macports.org  Mon Jul 28 16:14:05 2008
From: markd at macports.org (markd at macports.org)
Date: Mon, 28 Jul 2008 16:14:05 -0700
Subject: chunked guide / docs.macports.org?
Message-ID: <fc.004c4c580fec2eb4004c4c580fec2eb4.fec3506@biola.edu>

Simon has got the details of the chunked guide worked out, and I am of the
opinion that it is better that guide.macports.org display the chunked
guide with an obvious link somewhere to the single-page version, as
opposed to the guide.macports.org pulling up a page that asks 'single-page
or multi-page?'  I prefer to provide the chunked guide as a sane default. 
Do you agree or disagree with this?

Also, I am thinking that maybe we need a docs.macports.org url to track
all our documents.  I know Jordan mentioned we should link the HOWTOs in
the Guide, but I think it might be better to link a more general docs page
there and perhaps elsewhere.  Opinions?

Mark


From febeling at macports.org  Mon Jul 28 16:16:40 2008
From: febeling at macports.org (Caspar Florian Ebeling)
Date: Tue, 29 Jul 2008 01:16:40 +0200
Subject: [38646] trunk/doc-new/guide
In-Reply-To: <33E7A61A-756D-45C3-8F81-A44B9C0B649B@macports.org>
References: <20080727043732.51C5F18C264@beta.macosforge.org>
	<5cbbe4ae0807281502p2972b3d8i6e6416e4bdfd0db9@mail.gmail.com>
	<33E7A61A-756D-45C3-8F81-A44B9C0B649B@macports.org>
Message-ID: <5cbbe4ae0807281616h2051fac3h69ed43fc4090aa68@mail.gmail.com>

> Thanks for catching that. Is there some script I'm meant to run before
> committing changes to the documentation, to make sure I'm not breaking
> something?

Just do a "make guide" or "make guide-chunked" in doc-new/. If it runs
without errors it should be ok, but you can visually check in the sub-dir
guide/html.

You will need to install 3 or so ports for docbook processing, just
read the README there.

Florian



-- 
Florian Ebeling
florian.ebeling at gmail.com

From ryandesign at macports.org  Mon Jul 28 16:25:57 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 28 Jul 2008 18:25:57 -0500
Subject: Block pre-Subversion 1.5 clients
Message-ID: <0E3E31AF-061E-4F7D-AFE6-30FB7F1C1842@macports.org>

Should we block access to pre-Subversion 1.5 clients to commit to the  
repository, so that we can use the new Subversion 1.5 merge tracking?

http://svnbook.red-bean.com/nightly/en/ 
svn.branchmerge.advanced.html#svn.branchmerge.advanced.pre1.5clients


From wsiegrist at apple.com  Mon Jul 28 16:34:48 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Mon, 28 Jul 2008 16:34:48 -0700
Subject: Block pre-Subversion 1.5 clients
In-Reply-To: <0E3E31AF-061E-4F7D-AFE6-30FB7F1C1842@macports.org>
References: <0E3E31AF-061E-4F7D-AFE6-30FB7F1C1842@macports.org>
Message-ID: <792B6BD0-2A78-4208-8E9C-AE3C34A661CC@apple.com>

On Jul 28, 2008, at 4:25 PM, Ryan Schmidt wrote:

> Should we block access to pre-Subversion 1.5 clients to commit to the
> repository, so that we can use the new Subversion 1.5 merge tracking?
>
> http://svnbook.red-bean.com/nightly/en/
> svn.branchmerge.advanced.html#svn.branchmerge.advanced.pre1.5clients
>

The server is still running v1.4. I do not have any plans to upgrade  
anytime soon.

-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/20080728/40a47716/attachment-0001.bin 

From ryandesign at macports.org  Mon Jul 28 16:48:17 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 28 Jul 2008 18:48:17 -0500
Subject: [38669] trunk/dports/sysutils/bacula/Portfile
In-Reply-To: <20080728144824.135811921F0@beta.macosforge.org>
References: <20080728144824.135811921F0@beta.macosforge.org>
Message-ID: <7122ABE7-A060-4824-8397-B71AF54BD82D@macports.org>


On Jul 28, 2008, at 09:48, macsforever2000 at macports.org wrote:

> Revision: 38669
>           http://trac.macosforge.org/projects/macports/changeset/38669
> Author:   macsforever2000 at macports.org
> Date:     2008-07-28 07:48:23 -0700 (Mon, 28 Jul 2008)
> Log Message:
> -----------
> Fixed client_only variant name in conflict. client_only now is the  
> default variant if no other variant is selected. Thanks to  
> ryandesign for spotting these issues.
>
> Modified Paths:
> --------------
>     trunk/dports/sysutils/bacula/Portfile
>
> Modified: trunk/dports/sysutils/bacula/Portfile
> ===================================================================
> --- trunk/dports/sysutils/bacula/Portfile	2008-07-28 14:36:44 UTC  
> (rev 38668)
> +++ trunk/dports/sysutils/bacula/Portfile	2008-07-28 14:48:23 UTC  
> (rev 38669)
> @@ -58,37 +58,39 @@
>  "\[ -r \${PID} \] && /bin/kill \$(cat \${PID})"
>
>  variant client_only conflicts mysql4 mysql5 postgresql83 sqlite2  
> sqlite3 description "Install bacula client (bacula-fd) only" {
> -    configure.args-append --enable-client-only
> +  configure.args-append --enable-client_only

No, no -- the configure argument still needs a dash, not an  
underscore. :-)



From ryandesign at macports.org  Mon Jul 28 16:52:38 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 28 Jul 2008 18:52:38 -0500
Subject: Block pre-Subversion 1.5 clients
In-Reply-To: <792B6BD0-2A78-4208-8E9C-AE3C34A661CC@apple.com>
References: <0E3E31AF-061E-4F7D-AFE6-30FB7F1C1842@macports.org>
	<792B6BD0-2A78-4208-8E9C-AE3C34A661CC@apple.com>
Message-ID: <D69295BF-362E-48EF-B289-49B71ECAADA9@macports.org>


On Jul 28, 2008, at 18:34, William Siegrist wrote:

> On Jul 28, 2008, at 4:25 PM, Ryan Schmidt wrote:
>
>> Should we block access to pre-Subversion 1.5 clients to commit to the
>> repository, so that we can use the new Subversion 1.5 merge tracking?
>>
>> http://svnbook.red-bean.com/nightly/en/
>> svn.branchmerge.advanced.html#svn.branchmerge.advanced.pre1.5clients
>>
>
> The server is still running v1.4. I do not have any plans to  
> upgrade anytime soon.

Gotcha. That explains why I didn't see svn:mergeinfo properties added  
though I am using 1.5. Well, we'll keep it in mind for when the  
server is updated to 1.5 and beyond.


From macsforever2000 at macports.org  Mon Jul 28 16:59:51 2008
From: macsforever2000 at macports.org (Frank Schima)
Date: Mon, 28 Jul 2008 17:59:51 -0600
Subject: [38669] trunk/dports/sysutils/bacula/Portfile
In-Reply-To: <7122ABE7-A060-4824-8397-B71AF54BD82D@macports.org>
References: <20080728144824.135811921F0@beta.macosforge.org>
	<7122ABE7-A060-4824-8397-B71AF54BD82D@macports.org>
Message-ID: <567BD3ED-EA62-439A-878F-7144C3A6C161@macports.org>


On Jul 28, 2008, at 5:48 PM, Ryan Schmidt wrote:

>
> On Jul 28, 2008, at 09:48, macsforever2000 at macports.org wrote:
>
>> variant client_only conflicts mysql4 mysql5 postgresql83 sqlite2  
>> sqlite3 description "Install bacula client (bacula-fd) only" {
>> -    configure.args-append --enable-client-only
>> +  configure.args-append --enable-client_only
>
> No, no -- the configure argument still needs a dash, not an  
> underscore. :-)

You are quite correct. Fixed (and tested this time) in r38688. Thanks  
again!


Cheers!
Frank


From wsiegrist at apple.com  Mon Jul 28 17:00:45 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Mon, 28 Jul 2008 17:00:45 -0700
Subject: Block pre-Subversion 1.5 clients
In-Reply-To: <D69295BF-362E-48EF-B289-49B71ECAADA9@macports.org>
References: <0E3E31AF-061E-4F7D-AFE6-30FB7F1C1842@macports.org>
	<792B6BD0-2A78-4208-8E9C-AE3C34A661CC@apple.com>
	<D69295BF-362E-48EF-B289-49B71ECAADA9@macports.org>
Message-ID: <81B71504-FFAB-40E7-B975-16A74338FACB@apple.com>


On Jul 28, 2008, at 4:52 PM, Ryan Schmidt wrote:

>
> On Jul 28, 2008, at 18:34, William Siegrist wrote:
>
>> On Jul 28, 2008, at 4:25 PM, Ryan Schmidt wrote:
>>
>>> Should we block access to pre-Subversion 1.5 clients to commit to  
>>> the
>>> repository, so that we can use the new Subversion 1.5 merge  
>>> tracking?
>>>
>>> http://svnbook.red-bean.com/nightly/en/
>>> svn.branchmerge.advanced.html#svn.branchmerge.advanced.pre1.5clients
>>>
>>
>> The server is still running v1.4. I do not have any plans to  
>> upgrade anytime soon.
>
> Gotcha. That explains why I didn't see svn:mergeinfo properties  
> added though I am using 1.5. Well, we'll keep it in mind for when  
> the server is updated to 1.5 and beyond.
>

If v1.5 will help a lot of people, they should speak up so I can gauge  
the priority of the upgrade.

-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/20080728/f0d74358/attachment.bin 

From ryandesign at macports.org  Mon Jul 28 17:01:13 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 28 Jul 2008 19:01:13 -0500
Subject: chunked guide / docs.macports.org?
In-Reply-To: <fc.004c4c580fec2eb4004c4c580fec2eb4.fec3506@biola.edu>
References: <fc.004c4c580fec2eb4004c4c580fec2eb4.fec3506@biola.edu>
Message-ID: <B08E8F02-DECF-494E-AECA-E35FC1CC8C96@macports.org>

On Jul 28, 2008, at 18:14, markd at macports.org wrote:

> Simon has got the details of the chunked guide worked out, and I am  
> of the
> opinion that it is better that guide.macports.org display the chunked
> guide with an obvious link somewhere to the single-page version, as
> opposed to the guide.macports.org pulling up a page that asks  
> 'single-page
> or multi-page?'  I prefer to provide the chunked guide as a sane  
> default.
> Do you agree or disagree with this?
>
> Also, I am thinking that maybe we need a docs.macports.org url to  
> track
> all our documents.  I know Jordan mentioned we should link the  
> HOWTOs in
> the Guide, but I think it might be better to link a more general  
> docs page
> there and perhaps elsewhere.  Opinions?

I would prefer that we gravitate towards less hostnames, not more.

Our documentation is currently in the Guide (guide.macports.org) and  
in the wiki (trac.macports.org/wiki). Do we really need another page  
that provides just those two links?

Maybe it would make sense to have a wiki page which provides links to  
all documentation.


From ryandesign at macports.org  Mon Jul 28 17:03:34 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 28 Jul 2008 19:03:34 -0500
Subject: Block pre-Subversion 1.5 clients
In-Reply-To: <81B71504-FFAB-40E7-B975-16A74338FACB@apple.com>
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>
Message-ID: <AB3A6274-52DC-4B97-B1F2-A695CA3B56F1@macports.org>

On Jul 28, 2008, at 19:00, William Siegrist wrote:

> On Jul 28, 2008, at 4:52 PM, Ryan Schmidt wrote:
>
>> On Jul 28, 2008, at 18:34, William Siegrist wrote:
>>
>>> On Jul 28, 2008, at 4:25 PM, Ryan Schmidt wrote:
>>>
>>>> Should we block access to pre-Subversion 1.5 clients to commit  
>>>> to the
>>>> repository, so that we can use the new Subversion 1.5 merge  
>>>> tracking?
>>>>
>>>> http://svnbook.red-bean.com/nightly/en/
>>>> svn.branchmerge.advanced.html#svn.branchmerge.advanced.pre1.5client 
>>>> s
>>>
>>> The server is still running v1.4. I do not have any plans to  
>>> upgrade anytime soon.
>>
>> Gotcha. That explains why I didn't see svn:mergeinfo properties  
>> added though I am using 1.5. Well, we'll keep it in mind for when  
>> the server is updated to 1.5 and beyond.
>
> 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.


From wsiegrist at apple.com  Mon Jul 28 17:36:18 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Mon, 28 Jul 2008 17:36:18 -0700
Subject: chunked guide / docs.macports.org?
In-Reply-To: <B08E8F02-DECF-494E-AECA-E35FC1CC8C96@macports.org>
References: <fc.004c4c580fec2eb4004c4c580fec2eb4.fec3506@biola.edu>
	<B08E8F02-DECF-494E-AECA-E35FC1CC8C96@macports.org>
Message-ID: <3C5CB9A9-5A8F-47FF-A46E-7D6EF09263B9@apple.com>


On Jul 28, 2008, at 5:01 PM, Ryan Schmidt wrote:

> On Jul 28, 2008, at 18:14, markd at macports.org wrote:
>
>> Simon has got the details of the chunked guide worked out, and I am
>> of the
>> opinion that it is better that guide.macports.org display the chunked
>> guide with an obvious link somewhere to the single-page version, as
>> opposed to the guide.macports.org pulling up a page that asks
>> 'single-page
>> or multi-page?'  I prefer to provide the chunked guide as a sane
>> default.
>> Do you agree or disagree with this?
>>
>> Also, I am thinking that maybe we need a docs.macports.org url to
>> track
>> all our documents.  I know Jordan mentioned we should link the
>> HOWTOs in
>> the Guide, but I think it might be better to link a more general
>> docs page
>> there and perhaps elsewhere.  Opinions?
>
> I would prefer that we gravitate towards less hostnames, not more.
>
> Our documentation is currently in the Guide (guide.macports.org) and
> in the wiki (trac.macports.org/wiki). Do we really need another page
> that provides just those two links?
>
> Maybe it would make sense to have a wiki page which provides links to
> all documentation.



I agree with Ryan. Why not try to standardize on something like <http://macports.org/docs/ 
 >  for everything? That page could contain links into the Trac wiki,  
guide, FAQ, whatever. The main page at macports.org would have a  
single "Documentation" link to that page. We could even move the  
guide(s) into <http://macports.org/docs/guide/>.

-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/20080728/26fd74ce/attachment-0001.bin 

From markd at macports.org  Mon Jul 28 17:51:44 2008
From: markd at macports.org (markd at macports.org)
Date: Mon, 28 Jul 2008 17:51:44 -0700
Subject: chunked guide / docs.macports.org?
Message-ID: <fc.004c4c580fec4d1b004c4c580fec4d1b.fec5054@biola.edu>

>>> Simon has got the details of the chunked guide worked out, and I am
>>> of the
>>> opinion that it is better that guide.macports.org display the chunked
>>> guide with an obvious link somewhere to the single-page version, as
>>> opposed to the guide.macports.org pulling up a page that asks
>>> 'single-page
>>> or multi-page?'  I prefer to provide the chunked guide as a sane
>>> default.
>>> Do you agree or disagree with this?
>>>
>>> Also, I am thinking that maybe we need a docs.macports.org url to
>>> track
>>> all our documents.  I know Jordan mentioned we should link the
>>> HOWTOs in
>>> the Guide, but I think it might be better to link a more general
>>> docs page
>>> there and perhaps elsewhere.  Opinions?
>>
>> I would prefer that we gravitate towards less hostnames, not more.
>>
>> Our documentation is currently in the Guide (guide.macports.org) and
>> in the wiki (trac.macports.org/wiki). Do we really need another page
>> that provides just those two links?
>>
>> Maybe it would make sense to have a wiki page which provides links to
>> all documentation.
>
>
>
>I agree with Ryan. Why not try to standardize on something like
><http://macports.org/docs/ 
> >  for everything? That page could contain links into the Trac wiki,  
>guide, FAQ, whatever. The main page at macports.org would have a  
>single "Documentation" link to that page. We could even move the  
>guide(s) into <http://macports.org/docs/guide/>.

I agree.  I did not mean to say I thought we needed both
guide.macports.org and docs.macports.org.  I had two separate questions. 
But anyway, should we then ditch http://guide.macports.org for
http://macports.org/docs/?  It seems like a pretty good idea to me and
that is what I was getting at.  http://guide.macports.org seems
problematic to me now as too specific, and it tends to make people equate
the Guide with "MacPorts documentation", whereas I think of it as one in a
set.

Mark


From raimue at macports.org  Mon Jul 28 17:55:57 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Tue, 29 Jul 2008 02:55:57 +0200
Subject: Block pre-Subversion 1.5 clients
In-Reply-To: <AB3A6274-52DC-4B97-B1F2-A695CA3B56F1@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>
Message-ID: <488E6A9D.9070706@macports.org>

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?

Rainer

From raimue at macports.org  Mon Jul 28 17:59:17 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Tue, 29 Jul 2008 02:59:17 +0200
Subject: [38646] trunk/doc-new/guide
In-Reply-To: <5cbbe4ae0807281616h2051fac3h69ed43fc4090aa68@mail.gmail.com>
References: <20080727043732.51C5F18C264@beta.macosforge.org>	<5cbbe4ae0807281502p2972b3d8i6e6416e4bdfd0db9@mail.gmail.com>	<33E7A61A-756D-45C3-8F81-A44B9C0B649B@macports.org>
	<5cbbe4ae0807281616h2051fac3h69ed43fc4090aa68@mail.gmail.com>
Message-ID: <488E6B65.2050907@macports.org>

Caspar Florian Ebeling wrote:
>> Thanks for catching that. Is there some script I'm meant to run before
>> committing changes to the documentation, to make sure I'm not breaking
>> something?
> 
> Just do a "make guide" or "make guide-chunked" in doc-new/. If it runs
> without errors it should be ok, but you can visually check in the sub-dir
> guide/html.

Building the guide with docbook takes very long in my opinion. There is 
also a quicker 'make validate' which just checks for syntax errors 
before building.

Rainer

From wsiegrist at apple.com  Mon Jul 28 19:25:40 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Mon, 28 Jul 2008 19:25:40 -0700
Subject: chunked guide / docs.macports.org?
In-Reply-To: <fc.004c4c580fec4d1b004c4c580fec4d1b.fec5054@biola.edu>
References: <fc.004c4c580fec4d1b004c4c580fec4d1b.fec5054@biola.edu>
Message-ID: <BC49FEB4-4045-4ADB-A6D3-750AB169DA48@apple.com>


On Jul 28, 2008, at 5:51 PM, markd at macports.org wrote:

>>>> Simon has got the details of the chunked guide worked out, and I am
>>>> of the
>>>> opinion that it is better that guide.macports.org display the  
>>>> chunked
>>>> guide with an obvious link somewhere to the single-page version, as
>>>> opposed to the guide.macports.org pulling up a page that asks
>>>> 'single-page
>>>> or multi-page?'  I prefer to provide the chunked guide as a sane
>>>> default.
>>>> Do you agree or disagree with this?
>>>>
>>>> Also, I am thinking that maybe we need a docs.macports.org url to
>>>> track
>>>> all our documents.  I know Jordan mentioned we should link the
>>>> HOWTOs in
>>>> the Guide, but I think it might be better to link a more general
>>>> docs page
>>>> there and perhaps elsewhere.  Opinions?
>>>
>>> I would prefer that we gravitate towards less hostnames, not more.
>>>
>>> Our documentation is currently in the Guide (guide.macports.org) and
>>> in the wiki (trac.macports.org/wiki). Do we really need another page
>>> that provides just those two links?
>>>
>>> Maybe it would make sense to have a wiki page which provides links  
>>> to
>>> all documentation.
>>
>>
>>
>> I agree with Ryan. Why not try to standardize on something like
>> <http://macports.org/docs/
>>> for everything? That page could contain links into the Trac wiki,
>> guide, FAQ, whatever. The main page at macports.org would have a
>> single "Documentation" link to that page. We could even move the
>> guide(s) into <http://macports.org/docs/guide/>.
>
> I agree.  I did not mean to say I thought we needed both
> guide.macports.org and docs.macports.org.  I had two separate  
> questions.
> But anyway, should we then ditch http://guide.macports.org for
> http://macports.org/docs/?  It seems like a pretty good idea to me and
> that is what I was getting at.  http://guide.macports.org seems
> problematic to me now as too specific, and it tends to make people  
> equate
> the Guide with "MacPorts documentation", whereas I think of it as  
> one in a
> set.
>

My idea was for /docs/ to be static HTML/PHP  in the repo which  
renders to something like:


Documentation:
	* Installation
	* HOWTOs
	* Guide:
		* Chunked HTML
		* Single HTML
		* a future PDF version maybe?
	* FAQ
	* Bug Reporting Guidelines
	* Becoming a Member??


So this /docs/ page would replace several left navigation links on  
macports.org. The existing Documentation link would point to /docs/  
and the above list.

-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/20080728/72cf08af/attachment.bin 

From ryandesign at macports.org  Mon Jul 28 22:55:39 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 29 Jul 2008 00:55:39 -0500
Subject: [38698] trunk/dports/x11/qtoctave-mac/Portfile
In-Reply-To: <20080729053303.8EC42197CC3@beta.macosforge.org>
References: <20080729053303.8EC42197CC3@beta.macosforge.org>
Message-ID: <17B097E2-C14F-4518-8CC7-D4605328E0E4@macports.org>

On Jul 29, 2008, at 00:33, andrea.damore at macports.org wrote:

> Revision: 38698
>           http://trac.macosforge.org/projects/macports/changeset/38698
> Author:   andrea.damore at macports.org
> Date:     2008-07-28 22:33:02 -0700 (Mon, 28 Jul 2008)
> Log Message:
> -----------
> Fixed distname for qtoctave-mac.

For future reference, you do not need to increase the revision (and  
thereby force all users who already installed 0.7.4_0 to now build  
0.7.4_1) because this change does not affect what files the port ends  
up installing on the user's hard drive.


> Modified Paths:
> --------------
>     trunk/dports/x11/qtoctave-mac/Portfile
>
> Modified: trunk/dports/x11/qtoctave-mac/Portfile
> ===================================================================
> --- trunk/dports/x11/qtoctave-mac/Portfile	2008-07-29 02:00:31 UTC  
> (rev 38697)
> +++ trunk/dports/x11/qtoctave-mac/Portfile	2008-07-29 05:33:02 UTC  
> (rev 38698)
> @@ -4,6 +4,7 @@
>
>  name                    qtoctave-mac
>  version                 0.7.4
> +revision		1
>  categories              x11 math
>  platforms               darwin
>  maintainers             andrea.damore openmaintainer
> @@ -14,7 +15,8 @@
>  						tries, using menus and forms, make easy Octave.
>
>  homepage		http://qtoctave.wordpress.com
> -master_sites	http://forja.rediris.es/frs/download.php/744/
> +distname		qtoctave-${version}
> +master_sites		http://forja.rediris.es/frs/download.php/744/
>
>  depends_lib		port:octave \
>  				port:qt4-mac



From febeling at macports.org  Tue Jul 29 00:07:50 2008
From: febeling at macports.org (Caspar Florian Ebeling)
Date: Tue, 29 Jul 2008 09:07:50 +0200
Subject: [38646] trunk/doc-new/guide
In-Reply-To: <488E6B65.2050907@macports.org>
References: <20080727043732.51C5F18C264@beta.macosforge.org>
	<5cbbe4ae0807281502p2972b3d8i6e6416e4bdfd0db9@mail.gmail.com>
	<33E7A61A-756D-45C3-8F81-A44B9C0B649B@macports.org>
	<5cbbe4ae0807281616h2051fac3h69ed43fc4090aa68@mail.gmail.com>
	<488E6B65.2050907@macports.org>
Message-ID: <5cbbe4ae0807290007j2fda48e8u70f9846140b95466@mail.gmail.com>

>>> Thanks for catching that. Is there some script I'm meant to run before
>>> committing changes to the documentation, to make sure I'm not breaking
>>> something?
>>
>> Just do a "make guide" or "make guide-chunked" in doc-new/. If it runs
>> without errors it should be ok, but you can visually check in the sub-dir
>> guide/html.
>
> Building the guide with docbook takes very long in my opinion. There is also
> a quicker 'make validate' which just checks for syntax errors before
> building.

make guide takes 6.5 seconds on my machine, which is quick enough for me,
but the make validate takes only 2, so for just verifying while editing this is
even better, of course.

Florian

-- 
Florian Ebeling
florian.ebeling at gmail.com

From 0x62_0x6c_0x62 at pobox.com  Tue Jul 29 00:33:51 2008
From: 0x62_0x6c_0x62 at pobox.com (Bryan Blackburn)
Date: Tue, 29 Jul 2008 01:33:51 -0600
Subject: [38646] trunk/doc-new/guide
In-Reply-To: <5cbbe4ae0807290007j2fda48e8u70f9846140b95466@mail.gmail.com>
References: <20080727043732.51C5F18C264@beta.macosforge.org>
	<5cbbe4ae0807281502p2972b3d8i6e6416e4bdfd0db9@mail.gmail.com>
	<33E7A61A-756D-45C3-8F81-A44B9C0B649B@macports.org>
	<5cbbe4ae0807281616h2051fac3h69ed43fc4090aa68@mail.gmail.com>
	<488E6B65.2050907@macports.org>
	<5cbbe4ae0807290007j2fda48e8u70f9846140b95466@mail.gmail.com>
Message-ID: <6B417F57-BD67-4BB5-B7E8-791793A38B33@pobox.com>

On Jul 29, 2008, at 1:07 AM, Caspar Florian Ebeling wrote:

>>>> Thanks for catching that. Is there some script I'm meant to run  
>>>> before
>>>> committing changes to the documentation, to make sure I'm not  
>>>> breaking
>>>> something?
>>>
>>> Just do a "make guide" or "make guide-chunked" in doc-new/. If it  
>>> runs
>>> without errors it should be ok, but you can visually check in the  
>>> sub-dir
>>> guide/html.
>>
>> Building the guide with docbook takes very long in my opinion.  
>> There is also
>> a quicker 'make validate' which just checks for syntax errors before
>> building.
>
> make guide takes 6.5 seconds on my machine, which is quick enough  
> for me,
> but the make validate takes only 2, so for just verifying while  
> editing this is
> even better, of course.
>

If it takes significantly longer than this for anyone, check to see if  
you have XML_CATALOG_FILES set in your environment.  I did, and it  
kept downloading stuff, so I killed it after 8.5 minutes...once I  
unset it, it took about as long as it did for Florian.

Bryan


> Florian
>
> -- 
> Florian Ebeling
> florian.ebeling at gmail.com

From florian.ebeling at gmail.com  Tue Jul 29 01:13:23 2008
From: florian.ebeling at gmail.com (Caspar Florian Ebeling)
Date: Tue, 29 Jul 2008 10:13:23 +0200
Subject: [38646] trunk/doc-new/guide
In-Reply-To: <6B417F57-BD67-4BB5-B7E8-791793A38B33@pobox.com>
References: <20080727043732.51C5F18C264@beta.macosforge.org>
	<5cbbe4ae0807281502p2972b3d8i6e6416e4bdfd0db9@mail.gmail.com>
	<33E7A61A-756D-45C3-8F81-A44B9C0B649B@macports.org>
	<5cbbe4ae0807281616h2051fac3h69ed43fc4090aa68@mail.gmail.com>
	<488E6B65.2050907@macports.org>
	<5cbbe4ae0807290007j2fda48e8u70f9846140b95466@mail.gmail.com>
	<6B417F57-BD67-4BB5-B7E8-791793A38B33@pobox.com>
Message-ID: <5cbbe4ae0807290113u60462b1ek67587e0f47bcc5ff@mail.gmail.com>

>> make guide takes 6.5 seconds on my machine, which is quick enough
>> for me,
>> but the make validate takes only 2, so for just verifying while
>> editing this is
>> even better, of course.
>>
>
> If it takes significantly longer than this for anyone, check to see if
> you have XML_CATALOG_FILES set in your environment.  I did, and it
> kept downloading stuff, so I killed it after 8.5 minutes...once I
> unset it, it took about as long as it did for Florian.

But do I loose something without this variable or can it
be considered a trick to speed up things when working
on the guide? I browsed it locally afterwards and it seemed
all fine.

Florian


-- 
Florian Ebeling
florian.ebeling at gmail.com

From 0x62_0x6c_0x62 at pobox.com  Tue Jul 29 01:25:03 2008
From: 0x62_0x6c_0x62 at pobox.com (Bryan Blackburn)
Date: Tue, 29 Jul 2008 02:25:03 -0600
Subject: [38646] trunk/doc-new/guide
In-Reply-To: <5cbbe4ae0807290113u60462b1ek67587e0f47bcc5ff@mail.gmail.com>
References: <20080727043732.51C5F18C264@beta.macosforge.org>
	<5cbbe4ae0807281502p2972b3d8i6e6416e4bdfd0db9@mail.gmail.com>
	<33E7A61A-756D-45C3-8F81-A44B9C0B649B@macports.org>
	<5cbbe4ae0807281616h2051fac3h69ed43fc4090aa68@mail.gmail.com>
	<488E6B65.2050907@macports.org>
	<5cbbe4ae0807290007j2fda48e8u70f9846140b95466@mail.gmail.com>
	<6B417F57-BD67-4BB5-B7E8-791793A38B33@pobox.com>
	<5cbbe4ae0807290113u60462b1ek67587e0f47bcc5ff@mail.gmail.com>
Message-ID: <64A4C706-1750-46F9-9886-0BCA936FFDD4@pobox.com>

On Jul 29, 2008, at 2:13 AM, Caspar Florian Ebeling wrote:

>>> make guide takes 6.5 seconds on my machine, which is quick enough
>>> for me,
>>> but the make validate takes only 2, so for just verifying while
>>> editing this is
>>> even better, of course.
>>>
>>
>> If it takes significantly longer than this for anyone, check to see  
>> if
>> you have XML_CATALOG_FILES set in your environment.  I did, and it
>> kept downloading stuff, so I killed it after 8.5 minutes...once I
>> unset it, it took about as long as it did for Florian.
>
> But do I loose something without this variable or can it
> be considered a trick to speed up things when working
> on the guide? I browsed it locally afterwards and it seemed
> all fine.
>

I think it depends on where it points.  If it's not set and you're  
using xsltproc from MacPorts, it should default to /opt/local/etc/xml/ 
catalog which then points to all the XSL and XML stuff for docbook.   
Assuming you have the docbook-xsl and docbook-xml ports installed, you  
should have everything you need (as you've see looking at the output).

In my case it was pointed to a nonexistent catalog file (I think I was  
messing with it years ago and just left it in .bash_profile) so I  
believe it was redownloading all those docbook files again, hence the  
slowness...

Bryan


> Florian
>
>
> -- 
> Florian Ebeling
> florian.ebeling at gmail.com

From raimue at macports.org  Tue Jul 29 07:50:31 2008
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Tue, 29 Jul 2008 16:50:31 +0200
Subject: [38646] trunk/doc-new/guide
In-Reply-To: <5cbbe4ae0807290007j2fda48e8u70f9846140b95466@mail.gmail.com>
References: <20080727043732.51C5F18C264@beta.macosforge.org>	
	<5cbbe4ae0807281502p2972b3d8i6e6416e4bdfd0db9@mail.gmail.com>	
	<33E7A61A-756D-45C3-8F81-A44B9C0B649B@macports.org>	
	<5cbbe4ae0807281616h2051fac3h69ed43fc4090aa68@mail.gmail.com>	
	<488E6B65.2050907@macports.org>
	<5cbbe4ae0807290007j2fda48e8u70f9846140b95466@mail.gmail.com>
Message-ID: <488F2E37.2070507@macports.org>

Caspar Florian Ebeling wrote:
>> Building the guide with docbook takes very long in my opinion. There is also
>> a quicker 'make validate' which just checks for syntax errors before
>> building.
> 
> make guide takes 6.5 seconds on my machine, which is quick enough for me,
> but the make validate takes only 2, so for just verifying while editing this is
> even better, of course.

Oh, really *that* fast? Maybe something with my setup is wrong...

$ make clean
...

$ time make guide
...
real    11m58.320s
user    0m7.515s
sys     0m1.018s

This is what I consider long. Although I have no idea why we have that 
big differences. Even for rebuilding without changes and without 
cleaning it takes that long. I am on a MacBook (Core 2 Duo @ 2.0 GHz).

I have the following relevant ports installed:

$ port installed docbook* libxslt
The following ports are currently installed:
   docbook-dsssl @1.79_0 (active)
   docbook-xml @4.5_1 (active)
   docbook-xml-4.1.2 @4.1.2_1 (active)
   docbook-xml-4.2 @4.2_0 (active)
   docbook-xml-4.3 @4.3_0 (active)
   docbook-xml-4.4 @4.4_0 (active)
   docbook-xml-4.5 @4.5_0 (active)
   docbook-xsl @1.73.2_0 (active)
   libxslt @1.1.23_0 (active)

Probably I should only keep one of the various docbook versions?

I don't have XML_CATALOG_FILES in my environment as Bryan suggested in 
another mail.

Rainer

From dluke at geeklair.net  Tue Jul 29 08:10:06 2008
From: dluke at geeklair.net (Daniel J. Luke)
Date: Tue, 29 Jul 2008 11:10:06 -0400
Subject: [38646] trunk/doc-new/guide
In-Reply-To: <488F2E37.2070507@macports.org>
References: <20080727043732.51C5F18C264@beta.macosforge.org>	
	<5cbbe4ae0807281502p2972b3d8i6e6416e4bdfd0db9@mail.gmail.com>	
	<33E7A61A-756D-45C3-8F81-A44B9C0B649B@macports.org>	
	<5cbbe4ae0807281616h2051fac3h69ed43fc4090aa68@mail.gmail.com>	
	<488E6B65.2050907@macports.org>
	<5cbbe4ae0807290007j2fda48e8u70f9846140b95466@mail.gmail.com>
	<488F2E37.2070507@macports.org>
Message-ID: <6D5D339D-C8B5-4635-92E9-8FBBD50A846B@geeklair.net>

On Jul 29, 2008, at 10:50 AM, Rainer M?ller wrote:
> Probably I should only keep one of the various docbook versions?
>
> I don't have XML_CATALOG_FILES in my environment as Bryan suggested in
> another mail.


When I set up the guide regen on my box, I had to set up an XML  
catalog stuff in order to get it to use the local files instead of  
trying to download them (which is what seemed to take the most time).

I don't recall exactly what I did (and didn't keep notes), though.

--
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/20080729/027f3f32/attachment.bin 

From febeling at macports.org  Tue Jul 29 09:57:29 2008
From: febeling at macports.org (Caspar Florian Ebeling)
Date: Tue, 29 Jul 2008 18:57:29 +0200
Subject: [38646] trunk/doc-new/guide
In-Reply-To: <488F2E37.2070507@macports.org>
References: <20080727043732.51C5F18C264@beta.macosforge.org>
	<5cbbe4ae0807281502p2972b3d8i6e6416e4bdfd0db9@mail.gmail.com>
	<33E7A61A-756D-45C3-8F81-A44B9C0B649B@macports.org>
	<5cbbe4ae0807281616h2051fac3h69ed43fc4090aa68@mail.gmail.com>
	<488E6B65.2050907@macports.org>
	<5cbbe4ae0807290007j2fda48e8u70f9846140b95466@mail.gmail.com>
	<488F2E37.2070507@macports.org>
Message-ID: <5cbbe4ae0807290957s7c37dd41xd61fe0cff3fe1a4@mail.gmail.com>

>>> Building the guide with docbook takes very long in my opinion. There is
>>> also
>>> a quicker 'make validate' which just checks for syntax errors before
>>> building.
>>
>> make guide takes 6.5 seconds on my machine, which is quick enough for me,
>> but the make validate takes only 2, so for just verifying while editing
>> this is
>> even better, of course.
>
> Oh, really *that* fast? Maybe something with my setup is wrong...
>
> $ make clean
> ...
>
> $ time make guide
> ...
> real    11m58.320s
> user    0m7.515s
> sys     0m1.018s

flomac:doc-new febeling$ make clean
flomac:doc-new febeling$ time make guide

real	0m6.436s
user	0m6.095s
sys	0m0.305s


> This is what I consider long. Although I have no idea why we have that big
> differences. Even for rebuilding without changes and without cleaning it
> takes that long. I am on a MacBook (Core 2 Duo @ 2.0 GHz).

So am I. That's when I whish I had strace on macs as well...

> I have the following relevant ports installed:
>
> $ port installed docbook* libxslt
> The following ports are currently installed:
>  docbook-dsssl @1.79_0 (active)
>  docbook-xml @4.5_1 (active)
>  docbook-xml-4.1.2 @4.1.2_1 (active)
>  docbook-xml-4.2 @4.2_0 (active)
>  docbook-xml-4.3 @4.3_0 (active)
>  docbook-xml-4.4 @4.4_0 (active)
>  docbook-xml-4.5 @4.5_0 (active)
>  docbook-xsl @1.73.2_0 (active)
>  libxslt @1.1.23_0 (active)

flomac:doc-new febeling$ port installed docbook* libxslt
The following ports are currently installed:
  docbook-xml @4.5_1 (active)
  docbook-xml-4.1.2 @4.1.2_1 (active)
  docbook-xml-4.2 @4.2_0 (active)
  docbook-xml-4.3 @4.3_0 (active)
  docbook-xml-4.4 @4.4_0 (active)
  docbook-xml-4.5 @4.5_0 (active)
  docbook-xsl @1.72.0_0 (active)
  libxslt @1.1.22_0 (active)

Looks pretty similar... I bit less current on my side, but nothing
earth-shaking.

> Probably I should only keep one of the various docbook versions?
>
> I don't have XML_CATALOG_FILES in my environment as Bryan suggested in
> another mail.

Nor do I. And I didn't do any further magic or configuration. No idea, tbh.

Might be an outdated configuration on your machine, because I installed
and never upgraded it, so the configuration is as current as the version
numbers indeicate, I think April or so.

Florian

-- 
Florian Ebeling
florian.ebeling at gmail.com

From jmr at macports.org  Tue Jul 29 10:09:37 2008
From: jmr at macports.org (Joshua Root)
Date: Wed, 30 Jul 2008 03:09:37 +1000
Subject: [38646] trunk/doc-new/guide
In-Reply-To: <5cbbe4ae0807290957s7c37dd41xd61fe0cff3fe1a4@mail.gmail.com>
References: <20080727043732.51C5F18C264@beta.macosforge.org>	<5cbbe4ae0807281502p2972b3d8i6e6416e4bdfd0db9@mail.gmail.com>	<33E7A61A-756D-45C3-8F81-A44B9C0B649B@macports.org>	<5cbbe4ae0807281616h2051fac3h69ed43fc4090aa68@mail.gmail.com>	<488E6B65.2050907@macports.org>	<5cbbe4ae0807290007j2fda48e8u70f9846140b95466@mail.gmail.com>	<488F2E37.2070507@macports.org>
	<5cbbe4ae0807290957s7c37dd41xd61fe0cff3fe1a4@mail.gmail.com>
Message-ID: <488F4ED1.2020003@macports.org>

Caspar Florian Ebeling wrote:
> So am I. That's when I whish I had strace on macs as well...

Are you aware of dtruss (10.5) and ktrace (earlier)?

- Josh

From febeling at macports.org  Tue Jul 29 10:15:57 2008
From: febeling at macports.org (Caspar Florian Ebeling)
Date: Tue, 29 Jul 2008 19:15:57 +0200
Subject: [38646] trunk/doc-new/guide
In-Reply-To: <488F4ED1.2020003@macports.org>
References: <20080727043732.51C5F18C264@beta.macosforge.org>
	<5cbbe4ae0807281502p2972b3d8i6e6416e4bdfd0db9@mail.gmail.com>
	<33E7A61A-756D-45C3-8F81-A44B9C0B649B@macports.org>
	<5cbbe4ae0807281616h2051fac3h69ed43fc4090aa68@mail.gmail.com>
	<488E6B65.2050907@macports.org>
	<5cbbe4ae0807290007j2fda48e8u70f9846140b95466@mail.gmail.com>
	<488F2E37.2070507@macports.org>
	<5cbbe4ae0807290957s7c37dd41xd61fe0cff3fe1a4@mail.gmail.com>
	<488F4ED1.2020003@macports.org>
Message-ID: <5cbbe4ae0807291015y67ba23ceoa4560c2e74d4263f@mail.gmail.com>

On Tue, Jul 29, 2008 at 7:09 PM, Joshua Root <jmr at macports.org> wrote:
> Caspar Florian Ebeling wrote:
>>
>> So am I. That's when I whish I had strace on macs as well...
>
> Are you aware of dtruss (10.5) and ktrace (earlier)?

yeah, only for dtrace I need to learn some D language, apparently, and
for ktrace
I can't see the output in as it happens, but only with a certain viewer...
I never found either of them as intuitive. Correct my if I'm too ignorant
and miss something.

Florian



-- 
Florian Ebeling
florian.ebeling at gmail.com

From febeling at macports.org  Tue Jul 29 10:19:14 2008
From: febeling at macports.org (Caspar Florian Ebeling)
Date: Tue, 29 Jul 2008 19:19:14 +0200
Subject: [38646] trunk/doc-new/guide
In-Reply-To: <5cbbe4ae0807291015y67ba23ceoa4560c2e74d4263f@mail.gmail.com>
References: <20080727043732.51C5F18C264@beta.macosforge.org>
	<5cbbe4ae0807281502p2972b3d8i6e6416e4bdfd0db9@mail.gmail.com>
	<33E7A61A-756D-45C3-8F81-A44B9C0B649B@macports.org>
	<5cbbe4ae0807281616h2051fac3h69ed43fc4090aa68@mail.gmail.com>
	<488E6B65.2050907@macports.org>
	<5cbbe4ae0807290007j2fda48e8u70f9846140b95466@mail.gmail.com>
	<488F2E37.2070507@macports.org>
	<5cbbe4ae0807290957s7c37dd41xd61fe0cff3fe1a4@mail.gmail.com>
	<488F4ED1.2020003@macports.org>
	<5cbbe4ae0807291015y67ba23ceoa4560c2e74d4263f@mail.gmail.com>
Message-ID: <5cbbe4ae0807291019o5ad264ebta1ea5f00c24e37fa@mail.gmail.com>

On Tue, Jul 29, 2008 at 7:15 PM, Caspar Florian Ebeling
<febeling at macports.org> wrote:
> On Tue, Jul 29, 2008 at 7:09 PM, Joshua Root <jmr at macports.org> wrote:
>> Caspar Florian Ebeling wrote:
>>>
>>> So am I. That's when I whish I had strace on macs as well...
>>
>> Are you aware of dtruss (10.5) and ktrace (earlier)?
>
> yeah, only for dtrace I need to learn some D language, apparently, and
> for ktrace
> I can't see the output in as it happens, but only with a certain viewer...
> I never found either of them as intuitive. Correct my if I'm too ignorant
> and miss something.

Hang on, I thought that was a typo, but you really meant dtruss, not -trace.
That looks pretty cool, thanks for the pointer!


-- 
Florian Ebeling
florian.ebeling at gmail.com

From raimue at macports.org  Tue Jul 29 11:04:56 2008
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Tue, 29 Jul 2008 20:04:56 +0200
Subject: [38646] trunk/doc-new/guide
In-Reply-To: <5cbbe4ae0807290957s7c37dd41xd61fe0cff3fe1a4@mail.gmail.com>
References: <20080727043732.51C5F18C264@beta.macosforge.org>	
	<5cbbe4ae0807281502p2972b3d8i6e6416e4bdfd0db9@mail.gmail.com>	
	<33E7A61A-756D-45C3-8F81-A44B9C0B649B@macports.org>	
	<5cbbe4ae0807281616h2051fac3h69ed43fc4090aa68@mail.gmail.com>	
	<488E6B65.2050907@macports.org>	
	<5cbbe4ae0807290007j2fda48e8u70f9846140b95466@mail.gmail.com>	
	<488F2E37.2070507@macports.org>
	<5cbbe4ae0807290957s7c37dd41xd61fe0cff3fe1a4@mail.gmail.com>
Message-ID: <488F5BC8.4020909@macports.org>

Caspar Florian Ebeling wrote:
>> I don't have XML_CATALOG_FILES in my environment as Bryan suggested in
>> another mail.
> 
> Nor do I. And I didn't do any further magic or configuration. No idea, tbh.
> 
> Might be an outdated configuration on your machine, because I installed
> and never upgraded it, so the configuration is as current as the version
> numbers indeicate, I think April or so.

So I uninstalled docbook-xml, docbook-xsl and libxslt. I made sure that 
there are no files left in /opt/local/share/xml/docbook or 
/opt/local/share/xsl.

Then I reinstalled docbook-xml, docbook-xsl and libxslt. And it still 
needs more than 11 minutes to compile the guide.

I will try to build it completely new in a different prefix and diff the 
  files afterwards to find the issue.

Rainer

From febeling at macports.org  Tue Jul 29 11:10:42 2008
From: febeling at macports.org (Caspar Florian Ebeling)
Date: Tue, 29 Jul 2008 20:10:42 +0200
Subject: [38646] trunk/doc-new/guide
In-Reply-To: <488F5BC8.4020909@macports.org>
References: <20080727043732.51C5F18C264@beta.macosforge.org>
	<5cbbe4ae0807281502p2972b3d8i6e6416e4bdfd0db9@mail.gmail.com>
	<33E7A61A-756D-45C3-8F81-A44B9C0B649B@macports.org>
	<5cbbe4ae0807281616h2051fac3h69ed43fc4090aa68@mail.gmail.com>
	<488E6B65.2050907@macports.org>
	<5cbbe4ae0807290007j2fda48e8u70f9846140b95466@mail.gmail.com>
	<488F2E37.2070507@macports.org>
	<5cbbe4ae0807290957s7c37dd41xd61fe0cff3fe1a4@mail.gmail.com>
	<488F5BC8.4020909@macports.org>
Message-ID: <5cbbe4ae0807291110t6101c8d6y7f11a843a3f4c6d9@mail.gmail.com>

> So I uninstalled docbook-xml, docbook-xsl and libxslt. I made sure that
> there are no files left in /opt/local/share/xml/docbook or
> /opt/local/share/xsl.
>
> Then I reinstalled docbook-xml, docbook-xsl and libxslt. And it still needs
> more than 11 minutes to compile the guide.
>
> I will try to build it completely new in a different prefix and diff the
>  files afterwards to find the issue.

There was one file I found interesting with regard to possible
download delays:

The file /opt/local/share/xsl/docbook-xsl/catalog.xml contains this:

<?xml version="1.0" encoding="utf-8"?>
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
<!-- XML Catalog file for DocBook XSL Stylesheets v1.72.0 -->
   <rewriteURI uriStartString="http://docbook.sourceforge.net/release/xsl/current/"
rewritePrefix="./"/>
   <rewriteSystem
systemIdStartString="http://docbook.sourceforge.net/release/xsl/current/"
rewritePrefix="./"/>
   <rewriteURI uriStartString="http://docbook.sourceforge.net/release/xsl/1.72.0/"
rewritePrefix="./"/>
   <rewriteSystem
systemIdStartString="http://docbook.sourceforge.net/release/xsl/1.72.0/"
rewritePrefix="./"/>
</catalog>

...and that looks like something to convince the xml machinery to
not fetch remotely but use local copies. That's the only catalog entry I
can see here that has any remote references in it.

Florian



-- 
Florian Ebeling
florian.ebeling at gmail.com

From raimue at macports.org  Tue Jul 29 11:32:23 2008
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Tue, 29 Jul 2008 20:32:23 +0200
Subject: [38646] trunk/doc-new/guide
In-Reply-To: <488F5BC8.4020909@macports.org>
References: <20080727043732.51C5F18C264@beta.macosforge.org>	
	<5cbbe4ae0807281502p2972b3d8i6e6416e4bdfd0db9@mail.gmail.com>	
	<33E7A61A-756D-45C3-8F81-A44B9C0B649B@macports.org>	
	<5cbbe4ae0807281616h2051fac3h69ed43fc4090aa68@mail.gmail.com>	
	<488E6B65.2050907@macports.org>	
	<5cbbe4ae0807290007j2fda48e8u70f9846140b95466@mail.gmail.com>	
	<488F2E37.2070507@macports.org>
	<5cbbe4ae0807290957s7c37dd41xd61fe0cff3fe1a4@mail.gmail.com>
	<488F5BC8.4020909@macports.org>
Message-ID: <488F6237.4010406@macports.org>

Rainer M?ller wrote:
> I will try to build it completely new in a different prefix and diff the 
>   files afterwards to find the issue.

Seems like I finally found the issue.
It was something in /opt/local/etc/xml/catalog. I am attaching a diff of 
the old and the new version in case someone else has similar problems. I 
have no idea there these entries disturbing the build came from. As this 
file is not part of any port it was never upgraded.

With the new one, the guide finally compiles in less than 10 seconds. 
Thanks for your help!

Rainer
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: catalog.xml.diff
Url: http://lists.macosforge.org/pipermail/macports-dev/attachments/20080729/486bbc91/attachment.ksh 

From febeling at macports.org  Tue Jul 29 11:39:29 2008
From: febeling at macports.org (Caspar Florian Ebeling)
Date: Tue, 29 Jul 2008 20:39:29 +0200
Subject: [38646] trunk/doc-new/guide
In-Reply-To: <488F6237.4010406@macports.org>
References: <20080727043732.51C5F18C264@beta.macosforge.org>
	<5cbbe4ae0807281502p2972b3d8i6e6416e4bdfd0db9@mail.gmail.com>
	<33E7A61A-756D-45C3-8F81-A44B9C0B649B@macports.org>
	<5cbbe4ae0807281616h2051fac3h69ed43fc4090aa68@mail.gmail.com>
	<488E6B65.2050907@macports.org>
	<5cbbe4ae0807290007j2fda48e8u70f9846140b95466@mail.gmail.com>
	<488F2E37.2070507@macports.org>
	<5cbbe4ae0807290957s7c37dd41xd61fe0cff3fe1a4@mail.gmail.com>
	<488F5BC8.4020909@macports.org> <488F6237.4010406@macports.org>
Message-ID: <5cbbe4ae0807291139w40725a77s4795556061dc2d1@mail.gmail.com>

On Tue, Jul 29, 2008 at 8:32 PM, Rainer M?ller <raimue at macports.org> wrote:
> Rainer M?ller wrote:
>>
>> I will try to build it completely new in a different prefix and diff the
>>  files afterwards to find the issue.
>
> Seems like I finally found the issue.
> It was something in /opt/local/etc/xml/catalog. I am attaching a diff of the
> old and the new version in case someone else has similar problems. I have no
> idea there these entries disturbing the build came from. As this file is not
> part of any port it was never upgraded.

I think that is ok, there seems to be a nifty thing called xmlcatmgr, which left
a couple a comments in my catalog.

Have a look at this commit, it sounds related:

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

Florian

> With the new one, the guide finally compiles in less than 10 seconds. Thanks
> for your help!
welcome :)



-- 
Florian Ebeling
florian.ebeling at gmail.com

From febeling at macports.org  Tue Jul 29 12:10:06 2008
From: febeling at macports.org (Caspar Florian Ebeling)
Date: Tue, 29 Jul 2008 21:10:06 +0200
Subject: Distfiles
Message-ID: <5cbbe4ae0807291210i6457eb1ar16204596b35fd7c6@mail.gmail.com>

I know there was a discussion about distfiles in svn lately, but I missed
the central point. What is the right place to put them now, in cases where
there is no suitable download location? Should they still live in svn/distfiles
or elsewhere?

Florian

-- 
Florian Ebeling
florian.ebeling at gmail.com

From 0x62_0x6c_0x62 at pobox.com  Tue Jul 29 12:58:48 2008
From: 0x62_0x6c_0x62 at pobox.com (Bryan Blackburn)
Date: Tue, 29 Jul 2008 13:58:48 -0600
Subject: [38646] trunk/doc-new/guide
In-Reply-To: <488F6237.4010406@macports.org>
References: <20080727043732.51C5F18C264@beta.macosforge.org>	
	<5cbbe4ae0807281502p2972b3d8i6e6416e4bdfd0db9@mail.gmail.com>	
	<33E7A61A-756D-45C3-8F81-A44B9C0B649B@macports.org>	
	<5cbbe4ae0807281616h2051fac3h69ed43fc4090aa68@mail.gmail.com>	
	<488E6B65.2050907@macports.org>	
	<5cbbe4ae0807290007j2fda48e8u70f9846140b95466@mail.gmail.com>	
	<488F2E37.2070507@macports.org>
	<5cbbe4ae0807290957s7c37dd41xd61fe0cff3fe1a4@mail.gmail.com>
	<488F5BC8.4020909@macports.org> <488F6237.4010406@macports.org>
Message-ID: <C44B4A64-8177-4919-B4A8-6B90D0C4B082@pobox.com>

On Jul 29, 2008, at 12:32 PM, Rainer M?ller wrote:

> Rainer M?ller wrote:
>> I will try to build it completely new in a different prefix and  
>> diff the   files afterwards to find the issue.
>
> Seems like I finally found the issue.
> It was something in /opt/local/etc/xml/catalog. I am attaching a  
> diff of the old and the new version in case someone else has similar  
> problems. I have no idea there these entries disturbing the build  
> came from. As this file is not part of any port it was never upgraded.
>
> With the new one, the guide finally compiles in less than 10  
> seconds. Thanks for your help!
>
> Rainer
> --- catalog.xml.old	2008-07-29 20:23:32.000000000 +0200
> +++ /opt/local/etc/xml/catalog	2008-07-29 20:25:52.000000000 +0200
> @@ -1,15 +1,13 @@
> <?xml version="1.0"?>
> -<!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML  
> Catalog V1.0//EN" "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd 
> ">
> +<!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML  
> Catalog V1.0//EN"
> +    "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd 
> ">
> +
> +<!-- Created by XML Catalog Manager 2.2 -->
> <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
> -  <delegatePublic publicIdStartString="-//OASIS//ENTITIES DocBook  
> XML" catalog="file:///opt/local/etc/xml/docbook"/>

I wonder if it's these delegate bits, which point to /opt/local/etc/ 
xml/docbook which I don't have here?  Maybe if you also didn't have  
them, it then went over the network?  I noticed, watching netstat,  
talking to oasis-open.org wasn't exactly the fastest network connection.

Bryan


From wsiegrist at apple.com  Tue Jul 29 13:19:41 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Tue, 29 Jul 2008 13:19:41 -0700
Subject: Distfiles
In-Reply-To: <5cbbe4ae0807291210i6457eb1ar16204596b35fd7c6@mail.gmail.com>
References: <5cbbe4ae0807291210i6457eb1ar16204596b35fd7c6@mail.gmail.com>
Message-ID: <D209981A-686C-4A8D-B03A-06DB2995ABB4@apple.com>

On Jul 29, 2008, at 12:10 PM, Caspar Florian Ebeling wrote:

> I know there was a discussion about distfiles in svn lately, but I  
> missed
> the central point. What is the right place to put them now, in cases  
> where
> there is no suitable download location? Should they still live in  
> svn/distfiles
> or elsewhere?
>

In the future, MPWA will have an upload mechanism. For now, you could  
email me a URL and portname and I'll put it on the mirror.

If I get a chance to make an upload mechanism before MPWA, then I'll  
announce it here.

-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/20080729/94d72217/attachment.bin 

From ryandesign at macports.org  Tue Jul 29 18:08:12 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 29 Jul 2008 20:08:12 -0500
Subject: [38707] trunk/dports/databases
In-Reply-To: <20080729095247.816DC198A34@beta.macosforge.org>
References: <20080729095247.816DC198A34@beta.macosforge.org>
Message-ID: <545B7553-20FA-430B-8D19-B1D35D144822@macports.org>


On Jul 29, 2008, at 04:52, mr_bond at macports.org wrote:

> Revision: 38707
>           http://trac.macosforge.org/projects/macports/changeset/38707
> Author:   mr_bond at macports.org
> Date:     2008-07-29 02:52:47 -0700 (Tue, 29 Jul 2008)
> Log Message:
> -----------
> pgbouncer: New port submission, pgbouncer 1.1.2. Closes #16044
>
> Added Paths:
> -----------
>     trunk/dports/databases/pgbouncer/
>     trunk/dports/databases/pgbouncer/Portfile
>
> Added: trunk/dports/databases/pgbouncer/Portfile
> ===================================================================
> --- trunk/dports/databases/pgbouncer/ 
> Portfile	                        (rev 0)
> +++ trunk/dports/databases/pgbouncer/Portfile	2008-07-29 09:52:47  
> UTC (rev 38707)
> @@ -0,0 +1,35 @@
> +# $Id$
> +
> +PortSystem 1.0
> +
> +name			pgbouncer
> +version			1.1.2
> +categories		databases
> +platforms		darwin
> +maintainers		mac.com:giorgio_v
> +description		Lightweight connection pooler for PostgreSQL
> +long_description	pgbouncer is a PostgreSQL connection pooler. \
> +			Any target application can be connected to \
> +			pgbouncer as if it were a PostgreSQL server, \
> +			and pgbouncer will manage to connect to the \
> +			server, or to reuse one of its existing	connections.
> +
> +homepage		http://pgbouncer.projects.postgresql.org/
> +master_sites		http://pgfoundry.org/frs/download.php/1532/
> +checksums		md5 47bde1402f1a99dfc69f2f610fc1a36c \
> +			sha1 2b3c9a3c6ea620d2e35d4c857592e54afb5c727c \
> +			rmd160 7f2b4364c575109d3a59a909494029f80b542b2c
> +
> +configure.env		PATH=$env(PATH):${prefix}/lib/postgresql83/bin
> +
> +depends_build		port:postgresql83
> +depends_lib             port:libevent
> +
> +livecheck.check	regex
> +livecheck.url	http://pgfoundry.org/frs/?group_id=1000258
> +livecheck.regex	pgbouncer-(\[0-9\\.\]+)\\.tar\\.gz
> +
> +variant postgresql82 description {uses postgresql82 installation} {
> +	depends_build		port:postgresql82
> +	configure.env		PATH=$env(PATH):${prefix}/lib/postgresql82/bin
> +}

If a user selects the postgresql82 variant, pgbouncer will depend on  
both postgresql82 and postgresql83 which is probably not what you want.

When you have two possibilities which would be represented as radio  
buttons in a GUI as opposed to checkboxes (as is the case here -- the  
choice between postgresql82 and postgresql83) you should have two  
variants, marked as conflicting with one another, with one being the  
default. This makes it clearer to the user what her choices are.

Attached is a diff.

I'm also surprised postgresql* is listed as a build dependency. It's  
not needed at runtime? If it is, you should make it a run dependency,  
not a build dependency.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgbouncer.diff
Type: application/octet-stream
Size: 956 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080729/629cb055/attachment-0001.obj 

From ryandesign at macports.org  Tue Jul 29 18:12:38 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 29 Jul 2008 20:12:38 -0500
Subject: [38707] trunk/dports/databases
In-Reply-To: <545B7553-20FA-430B-8D19-B1D35D144822@macports.org>
References: <20080729095247.816DC198A34@beta.macosforge.org>
	<545B7553-20FA-430B-8D19-B1D35D144822@macports.org>
Message-ID: <DB810789-E708-4EB2-8C9E-9A974379BA15@macports.org>

On Jul 29, 2008, at 20:08, Ryan Schmidt wrote:

> On Jul 29, 2008, at 04:52, mr_bond at macports.org wrote:
>
>> Revision: 38707
>>           http://trac.macosforge.org/projects/macports/changeset/ 
>> 38707
>> Author:   mr_bond at macports.org
>> Date:     2008-07-29 02:52:47 -0700 (Tue, 29 Jul 2008)
>> Log Message:
>> -----------
>> pgbouncer: New port submission, pgbouncer 1.1.2. Closes #16044
>>
>> Added Paths:
>> -----------
>>     trunk/dports/databases/pgbouncer/
>>     trunk/dports/databases/pgbouncer/Portfile
>>
>> Added: trunk/dports/databases/pgbouncer/Portfile
>> ===================================================================
>> --- trunk/dports/databases/pgbouncer/ 
>> Portfile	                        (rev 0)
>> +++ trunk/dports/databases/pgbouncer/Portfile	2008-07-29 09:52:47  
>> UTC (rev 38707)
>> @@ -0,0 +1,35 @@
>> +# $Id$
>> +
>> +PortSystem 1.0
>> +
>> +name			pgbouncer
>> +version			1.1.2
>> +categories		databases
>> +platforms		darwin
>> +maintainers		mac.com:giorgio_v
>> +description		Lightweight connection pooler for PostgreSQL
>> +long_description	pgbouncer is a PostgreSQL connection pooler. \
>> +			Any target application can be connected to \
>> +			pgbouncer as if it were a PostgreSQL server, \
>> +			and pgbouncer will manage to connect to the \
>> +			server, or to reuse one of its existing	connections.
>> +
>> +homepage		http://pgbouncer.projects.postgresql.org/
>> +master_sites		http://pgfoundry.org/frs/download.php/1532/
>> +checksums		md5 47bde1402f1a99dfc69f2f610fc1a36c \
>> +			sha1 2b3c9a3c6ea620d2e35d4c857592e54afb5c727c \
>> +			rmd160 7f2b4364c575109d3a59a909494029f80b542b2c
>> +
>> +configure.env		PATH=$env(PATH):${prefix}/lib/postgresql83/bin
>> +
>> +depends_build		port:postgresql83
>> +depends_lib             port:libevent
>> +
>> +livecheck.check	regex
>> +livecheck.url	http://pgfoundry.org/frs/?group_id=1000258
>> +livecheck.regex	pgbouncer-(\[0-9\\.\]+)\\.tar\\.gz
>> +
>> +variant postgresql82 description {uses postgresql82 installation} {
>> +	depends_build		port:postgresql82
>> +	configure.env		PATH=$env(PATH):${prefix}/lib/postgresql82/bin
>> +}
>
> If a user selects the postgresql82 variant, pgbouncer will depend  
> on both postgresql82 and postgresql83 which is probably not what  
> you want.

Sorry, I realize I was mistaken on this point. The rest of my  
feedback stands however.

> When you have two possibilities which would be represented as radio  
> buttons in a GUI as opposed to checkboxes (as is the case here --  
> the choice between postgresql82 and postgresql83) you should have  
> two variants, marked as conflicting with one another, with one  
> being the default. This makes it clearer to the user what her  
> choices are.
>
> Attached is a diff.
>
> I'm also surprised postgresql* is listed as a build dependency.  
> It's not needed at runtime? If it is, you should make it a run  
> dependency, not a build dependency.


From ryandesign at macports.org  Tue Jul 29 18:17:39 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 29 Jul 2008 20:17:39 -0500
Subject: [38737] trunk/dports/devel
In-Reply-To: <20080729232458.8C7D619B635@beta.macosforge.org>
References: <20080729232458.8C7D619B635@beta.macosforge.org>
Message-ID: <3DF1B792-D179-4C24-9732-023C1A805F6B@macports.org>

On Jul 29, 2008, at 18:24, landonf at macports.org wrote:

> Revision: 38737
>           http://trac.macosforge.org/projects/macports/changeset/38737
> Author:   landonf at macports.org
> Date:     2008-07-29 16:24:57 -0700 (Tue, 29 Jul 2008)
> Log Message:
> -----------
> Add OCamlnet library
>
> Added Paths:
> -----------
>     trunk/dports/devel/caml-ocamlnet/
>     trunk/dports/devel/caml-ocamlnet/Portfile
>
> Added: trunk/dports/devel/caml-ocamlnet/Portfile
> ===================================================================
> --- trunk/dports/devel/caml-ocamlnet/ 
> Portfile	                        (rev 0)
> +++ trunk/dports/devel/caml-ocamlnet/Portfile	2008-07-29 23:24:57  
> UTC (rev 38737)
> @@ -0,0 +1,50 @@
> +# $Id: $
> +
> +PortSystem          1.0
> +
> +name                caml-ocamlnet
> +version             2.2.9
> +categories          devel ml
> +maintainers         landonf openmaintainer
> +description         Internet protocols and helper data structures  
> for OCaml.
> +long_description    Internet protocols (http, cgi, email etc.) and  
> helper \
> +                    data structures (mail messages, character  
> sets, etc.) \
> +                    Ocamlnet implements a number of Internet  
> protocols (http \
> +                    client & server, cgi and cgi variants, SunRPC,  
> FTP, POP, \
> +                    SMTP) and is a strong base for web and Internet \
> +                    programming.
> +
> +homepage            http://projects.camlcity.org/projects/ 
> ocamlnet.html
> +platforms           darwin
> +master_sites        http://download.camlcity.org/download/
> +
> +distname            ocamlnet-${version}
> +
> +checksums           md5 3655e3be3bb2806e0a1f48bb7ce16fb3 \
> +                    sha1 ca073c60f86fede60d4c479e5589127010482804 \
> +                    rmd160 1299e1316e0547171089b0caaa9deb13c4c67c31
> +
> +
> +depends_lib         port:ocaml \
> +                    port:caml-findlib \
> +                    port:caml-pcre
> +
> +post-patch {
> +    set ocaml_site_path [exec ocamlfind printconf destdir]
> +    reinplace       "s|\$(OCAMLFIND) install|\$(OCAMLFIND) install  
> -destdir ${destroot}/${ocaml_site_path}|g" \
> +                    ${worksrcpath}/Makefile
> +}
> +
> +configure {
> +    system "cd ${worksrcpath} && ./configure"
> +}

Out of curiosity, why not use the default configure phase?


> +build.target        all opt
> +
> +pre-destroot {
> +    set ocaml_site_path [exec ocamlfind printconf destdir]
> +    file mkdir ${destroot}/${ocaml_site_path}
> +}
> +
> +destroot.env        DESTDIR="${destroot}" \
> +                    OCAMLFIND_DESTDIR="${destroot}/[exec ${prefix}/ 
> bin/ocamlfind printconf destdir]"

This last line is probably responsible for:

caml-ocamlnet $ port info
Can't map the URL 'file://.' to a port description file ("couldn't  
execute "/mp/bin/ocamlfind": no such file or directory").
Please verify that the directory and portfile syntax are correct.
To use the current port, you must be in a port's directory.
(you might also see this message if a pseudo-port such as
outdated or installed expands to no ports).

May want to put the setting of destroot.env into the pre-destroot block.



From ryandesign at macports.org  Tue Jul 29 20:05:14 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 29 Jul 2008 22:05:14 -0500
Subject: [38743] trunk/dports/devel/caml-ocamlnet/Portfile
In-Reply-To: <20080730013948.DB69A19BE88@beta.macosforge.org>
References: <20080730013948.DB69A19BE88@beta.macosforge.org>
Message-ID: <E4E82C78-509A-4FF7-A88E-58CA6ED4E040@macports.org>

On Jul 29, 2008, at 20:39, landonf at macports.org wrote:

> Revision: 38743
>           http://trac.macosforge.org/projects/macports/changeset/38743
> Author:   landonf at macports.org
> Date:     2008-07-29 18:39:48 -0700 (Tue, 29 Jul 2008)
> Log Message:
> -----------
> Fix breakage at index time. ocamlfind, you're killing me.
>
> Modified Paths:
> --------------
>     trunk/dports/devel/caml-ocamlnet/Portfile
>
> Modified: trunk/dports/devel/caml-ocamlnet/Portfile
> ===================================================================
> --- trunk/dports/devel/caml-ocamlnet/Portfile	2008-07-30 01:03:31  
> UTC (rev 38742)
> +++ trunk/dports/devel/caml-ocamlnet/Portfile	2008-07-30 01:39:48  
> UTC (rev 38743)
> @@ -44,7 +44,9 @@
>  pre-destroot {
>      set ocaml_site_path [exec ocamlfind printconf destdir]
>      file mkdir ${destroot}/${ocaml_site_path}/stublibs
> +
>  }
>
> -destroot.env        DESTDIR="${destroot}" \
> -                    OCAMLFIND_DESTDIR="${destroot}/[exec ${prefix}/ 
> bin/ocamlfind printconf destdir]"
> +pre-destroot {
> +    destroot.args DESTDIR="${destroot}" OCAMLFIND_DESTDIR="$ 
> {destroot}/[exec ${prefix}/bin/ocamlfind printconf destdir]"
> +}

How about the attached diff? Should be ok?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: caml-ocamlnet.diff
Type: application/octet-stream
Size: 531 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080729/3b0f5c1a/attachment.obj 

From jlmuir at anl.gov  Wed Jul 30 07:32:16 2008
From: jlmuir at anl.gov (J. Lewis Muir)
Date: Wed, 30 Jul 2008 10:32:16 -0400
Subject: Conflict with /Applications/MacPorts when multiple MacPorts instances
	installed
Message-ID: <48907B70.4050409@anl.gov>

Activating python25 in a second MacPorts instance fails for me when my
first instance already contains an activated python25.

According to

  http://guide.macports.org/#installing.macports.source.multiple

I can install more than one MacPorts instance on the same host.
However, when I do this and then install bzr which installs python25 in
a second instance, I eventually get the following error output:

--------------------
--->  Fetching python25
--->  Attempting to fetch Python-2.5.2.tgz from http://www.python.org//f
tp/python/2.5.2/
--->  Verifying checksum(s) for python25
--->  Extracting python25
--->  Applying patches to python25
--->  Configuring python25
--->  Building python25 with target all libpython2.5.dylib
--->  Staging python25 into destroot
--->  Installing python25 2.5.2_5+darwin_9
--->  Activating python25 2.5.2_5+darwin_9
Error: Target org.macports.activate returned: Image error: /Applications
/MacPorts/MacPython 2.5/Build Applet.app/Contents/Info.plist already exi
sts and does not belong to a registered port.  Unable to activate port p
ython25.
Error: The following dependencies failed to build: py25-bz2 python25 py2
5-crypto py25-curl curl pkgconfig zlib py25-docutils py25-hashlib openss
l py25-paramiko py25-socket-ssl py25-zlib
Error: Status 1 encountered during processing.
--------------------

Is there a way around this?  Perhaps another configure option, similar
to the --with-tclpackage option, such as --with-apppackage is needed?  I
could then configure my development MacPorts install with something like

  ./configure
    --prefix=/opt-dev
    --with-tclpackage=/Library/Tcl/macports-dev
    --with-apppackage=/Applications/MacPortsDev

Of course, I can work around this by moving /Applications/MacPorts out
of the way while I work with my development instance, but it would be
nice if I didn't have to do that.

Or maybe I'm not understanding something correctly.

Thanks,

Lewis

From jmr at macports.org  Wed Jul 30 07:36:29 2008
From: jmr at macports.org (Joshua Root)
Date: Thu, 31 Jul 2008 00:36:29 +1000
Subject: Conflict with /Applications/MacPorts when multiple MacPorts
	instances installed
In-Reply-To: <48907B70.4050409@anl.gov>
References: <48907B70.4050409@anl.gov>
Message-ID: <48907C6D.4000802@macports.org>

J. Lewis Muir wrote:
> Activating python25 in a second MacPorts instance fails for me when my
> first instance already contains an activated python25.
> 
> According to
> 
>   http://guide.macports.org/#installing.macports.source.multiple
> 
> I can install more than one MacPorts instance on the same host.
> However, when I do this and then install bzr which installs python25 in
> a second instance, I eventually get the following error output:
<snip>
> 
> Is there a way around this?  Perhaps another configure option, similar
> to the --with-tclpackage option, such as --with-apppackage is needed?  I
> could then configure my development MacPorts install with something like

The configure option you want is --with-applications-dir. A full list is 
available from './configure --help'.

- Josh

From jlmuir at anl.gov  Wed Jul 30 07:48:25 2008
From: jlmuir at anl.gov (J. Lewis Muir)
Date: Wed, 30 Jul 2008 10:48:25 -0400
Subject: Conflict with /Applications/MacPorts when multiple MacPorts
	instances installed
In-Reply-To: <48907C6D.4000802@macports.org>
References: <48907B70.4050409@anl.gov> <48907C6D.4000802@macports.org>
Message-ID: <48907F39.50200@anl.gov>

On 7/30/08 10:36 AM, Joshua Root wrote:
> J. Lewis Muir wrote:
>> Activating python25 in a second MacPorts instance fails for me when my
>> first instance already contains an activated python25.
>>
>> According to
>>
>>   http://guide.macports.org/#installing.macports.source.multiple
>>
>> I can install more than one MacPorts instance on the same host.
>> However, when I do this and then install bzr which installs python25 in
>> a second instance, I eventually get the following error output:
> <snip>
>>
>> Is there a way around this?  Perhaps another configure option, similar
>> to the --with-tclpackage option, such as --with-apppackage is needed?  I
>> could then configure my development MacPorts install with something like
> 
> The configure option you want is --with-applications-dir. A full list is
> available from './configure --help'.

Hmm...I did that before posting and didn't see the option.  I checked
again to make sure and it's not listed.  I'm using MacPorts 1.6.0.
Maybe it's in the latest MacPorts development branch?

Thanks,

Lewis

From jmr at macports.org  Wed Jul 30 07:56:52 2008
From: jmr at macports.org (Joshua Root)
Date: Thu, 31 Jul 2008 00:56:52 +1000
Subject: Conflict with /Applications/MacPorts when multiple
	MacPorts	instances installed
In-Reply-To: <48907F39.50200@anl.gov>
References: <48907B70.4050409@anl.gov> <48907C6D.4000802@macports.org>
	<48907F39.50200@anl.gov>
Message-ID: <48908134.7030605@macports.org>

J. Lewis Muir wrote:
> On 7/30/08 10:36 AM, Joshua Root wrote:
>> J. Lewis Muir wrote:
>>> Activating python25 in a second MacPorts instance fails for me when my
>>> first instance already contains an activated python25.
>>>
>>> According to
>>>
>>>   http://guide.macports.org/#installing.macports.source.multiple
>>>
>>> I can install more than one MacPorts instance on the same host.
>>> However, when I do this and then install bzr which installs python25 in
>>> a second instance, I eventually get the following error output:
>> <snip>
>>> Is there a way around this?  Perhaps another configure option, similar
>>> to the --with-tclpackage option, such as --with-apppackage is needed?  I
>>> could then configure my development MacPorts install with something like
>> The configure option you want is --with-applications-dir. A full list is
>> available from './configure --help'.
> 
> Hmm...I did that before posting and didn't see the option.  I checked
> again to make sure and it's not listed.  I'm using MacPorts 1.6.0.
> Maybe it's in the latest MacPorts development branch?

Ah, sorry, you're right. That option is only present in svn trunk, not 
1.6.0.

- Josh

From afb at macports.org  Wed Jul 30 08:07:05 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Wed, 30 Jul 2008 17:07:05 +0200
Subject: Conflict with /Applications/MacPorts when multiple
	MacPorts	instances installed
In-Reply-To: <48908134.7030605@macports.org>
References: <48907B70.4050409@anl.gov> <48907C6D.4000802@macports.org>
	<48907F39.50200@anl.gov> <48908134.7030605@macports.org>
Message-ID: <8DA288B4-05C9-4661-8EA6-F0AF14CF5C17@macports.org>

Joshua Root wrote:

>>>> Is there a way around this?  Perhaps another configure option,  
>>>> similar
>>>> to the --with-tclpackage option, such as --with-apppackage is  
>>>> needed?  I
>>>> could then configure my development MacPorts install with  
>>>> something like
>>> The configure option you want is --with-applications-dir. A full  
>>> list is
>>> available from './configure --help'.
>>
>> Hmm...I did that before posting and didn't see the option.  I checked
>> again to make sure and it's not listed.  I'm using MacPorts 1.6.0.
>> Maybe it's in the latest MacPorts development branch?
>
> Ah, sorry, you're right. That option is only present in svn trunk, not
> 1.6.0.

MacPorts installs ports in *four* different places: (default values)

- prefix (/opt/local)
- x11prefix (/usr/X11R6)
- applications-dir (/Applications/MacPorts)
- frameworks-dir (/Library/Frameworks)

Some of these were hardcoded in the previous releases, such as 1.6.0.

MacPorts "base" installs itself into:
- prefix (/opt/local)
- tclpackage (/Library/Tcl)
It's also possible to change ports-dir.

--anders


From markd at macports.org  Wed Jul 30 09:23:31 2008
From: markd at macports.org (markd at macports.org)
Date: Wed, 30 Jul 2008 09:23:31 -0700
Subject: chunked guide - macports.org/docs/ 
Message-ID: <fc.004c4c580fefcbfe004c4c580fefcbfe.fefd4d4@biola.edu>

>My idea was for /docs/ to be static HTML/PHP  in the repo which  
>renders to something like:
>
>
>Documentation:
>	* Installation
>	* HOWTOs
>	* Guide:
>		* Chunked HTML
>		* Single HTML
>		* a future PDF version maybe?
>	* FAQ
>	* Bug Reporting Guidelines
>	* Becoming a Member??
>
>
>So this /docs/ page would replace several left navigation links on  
>macports.org. The existing Documentation link would point to /docs/  
>and the above list.
>
>-Bill


I like this idea.  One benefit would be that it would allow us to unify
the install information (guide & website are different), which needs to be
done anyway.

Mark


From landonf at macports.org  Wed Jul 30 09:58:47 2008
From: landonf at macports.org (Landon Fuller)
Date: Wed, 30 Jul 2008 09:58:47 -0700
Subject: Conflict with /Applications/MacPorts when multiple
	MacPorts	instances installed
In-Reply-To: <8DA288B4-05C9-4661-8EA6-F0AF14CF5C17@macports.org>
References: <48907B70.4050409@anl.gov> <48907C6D.4000802@macports.org>
	<48907F39.50200@anl.gov> <48908134.7030605@macports.org>
	<8DA288B4-05C9-4661-8EA6-F0AF14CF5C17@macports.org>
Message-ID: <72372C98-B591-4AF6-9181-21D858629CFF@macports.org>


On Jul 30, 2008, at 8:07 AM, Anders F Bj?rklund wrote:

> - frameworks-dir (/Library/Frameworks)

Shouldn't this be ${prefix}/Library/Frameworks? It can still be  
referenced with the -F compiler/linker flag
-------------- 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/20080730/19a6fba4/attachment.bin 

From afb at macports.org  Wed Jul 30 15:18:00 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Thu, 31 Jul 2008 00:18:00 +0200
Subject: Conflict with /Applications/MacPorts when multiple
	MacPorts	instances installed
In-Reply-To: <72372C98-B591-4AF6-9181-21D858629CFF@macports.org>
References: <48907B70.4050409@anl.gov> <48907C6D.4000802@macports.org>
	<48907F39.50200@anl.gov> <48908134.7030605@macports.org>
	<8DA288B4-05C9-4661-8EA6-F0AF14CF5C17@macports.org>
	<72372C98-B591-4AF6-9181-21D858629CFF@macports.org>
Message-ID: <E3010F3D-FABE-4A76-BD3B-7100D33606B5@macports.org>

Landon Fuller wrote:

>> - frameworks-dir (/Library/Frameworks)
>
> Shouldn't this be ${prefix}/Library/Frameworks? It can still be  
> referenced with the -F compiler/linker flag

I would have preferred ${prefix}/Applications and ${prefix}/Library/ 
Frameworks.
That way it is just one location to keep track of, instead of three  
(or more)...
(Fink uses ${prefix} for Applications and Frameworks, if that is of  
any relevance)
But it varies a bit between ports, Python uses ${prefix} while SDL  
uses /Library.

--anders


From randall.h.wood at alexandriasoftware.com  Wed Jul 30 16:38:22 2008
From: randall.h.wood at alexandriasoftware.com (Randall Wood)
Date: Wed, 30 Jul 2008 19:38:22 -0400
Subject: Conflict with /Applications/MacPorts when multiple MacPorts
	instances installed
In-Reply-To: <E3010F3D-FABE-4A76-BD3B-7100D33606B5@macports.org>
References: <48907B70.4050409@anl.gov> <48907C6D.4000802@macports.org>
	<48907F39.50200@anl.gov> <48908134.7030605@macports.org>
	<8DA288B4-05C9-4661-8EA6-F0AF14CF5C17@macports.org>
	<72372C98-B591-4AF6-9181-21D858629CFF@macports.org>
	<E3010F3D-FABE-4A76-BD3B-7100D33606B5@macports.org>
Message-ID: <c24012060807301638k2d924bf4i1eaf912afa7d191@mail.gmail.com>

/Applications is a magic location in Mac OS X. Unless your app is in
/Applications, ~/Applications, or /Network/*/Applications (I'm not
sure how the /Network domain works), certain standard Cocoa features
(like placing items in the Services menu) will be turned off in the
app. Since MacPorts sticks its apps in /Applications/MacPorts, its
apps get the standard features (Fink apps don't).

On Wed, Jul 30, 2008 at 6:18 PM, Anders F Bj?rklund <afb at macports.org> wrote:
> Landon Fuller wrote:
>
>>> - frameworks-dir (/Library/Frameworks)
>>
>> Shouldn't this be ${prefix}/Library/Frameworks? It can still be
>> referenced with the -F compiler/linker flag
>
> I would have preferred ${prefix}/Applications and ${prefix}/Library/
> Frameworks.
> That way it is just one location to keep track of, instead of three
> (or more)...
> (Fink uses ${prefix} for Applications and Frameworks, if that is of
> any relevance)
> But it varies a bit between ports, Python uses ${prefix} while SDL
> uses /Library.
>
> --anders
>
> _______________________________________________
> 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 raimue at macports.org  Wed Jul 30 16:44:59 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 31 Jul 2008 01:44:59 +0200
Subject: Conflict with /Applications/MacPorts when multiple
	MacPorts	instances installed
In-Reply-To: <48907C6D.4000802@macports.org>
References: <48907B70.4050409@anl.gov> <48907C6D.4000802@macports.org>
Message-ID: <4890FCFB.3090709@macports.org>

Joshua Root wrote:
> The configure option you want is --with-applications-dir. A full list is 
> available from './configure --help'.

As this option is only available in trunk, all current ports have 
"/Applications/MacPorts" and the framework path hardcoded. As of the 
next release ${applications_dir} and ${frameworks_dir} can be used in 
Portfiles instead. Until then, there is no easy solution to keep 
multiple MacPorts installations.

Rainer

From ryandesign at macports.org  Wed Jul 30 20:20:12 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 30 Jul 2008 22:20:12 -0500
Subject: [38761] trunk/dports/devel/darcs
In-Reply-To: <20080730175039.05E2C19F4D7@beta.macosforge.org>
References: <20080730175039.05E2C19F4D7@beta.macosforge.org>
Message-ID: <85EAD4E2-8B4E-4AD4-93F6-0F7922D9D656@macports.org>

On Jul 30, 2008, at 12:50, gwright at macports.org wrote:

> Revision: 38761
>           http://trac.macosforge.org/projects/macports/changeset/38761
> Author:   gwright at macports.org
> Date:     2008-07-30 10:50:38 -0700 (Wed, 30 Jul 2008)
> Log Message:
> -----------
> Add profiling variant (mostly of interest to those working to
> improve darcs internals).

FYI, when you add a variant, you don't need to increase the port  
revision, since nothing will change for those users who already had  
the port installed.


> Modified Paths:
> --------------
>     trunk/dports/devel/darcs/Portfile
>
> Added Paths:
> -----------
>     trunk/dports/devel/darcs/files/
>     trunk/dports/devel/darcs/files/patch-GNUmakefile.diff
>
> Modified: trunk/dports/devel/darcs/Portfile
> ===================================================================
> --- trunk/dports/devel/darcs/Portfile	2008-07-30 16:29:11 UTC (rev  
> 38760)
> +++ trunk/dports/devel/darcs/Portfile	2008-07-30 17:50:38 UTC (rev  
> 38761)
> @@ -4,6 +4,7 @@
>
>  name            darcs
>  version         2.0.2
> +revision	1
>  categories      devel
>  maintainers     gwright at macports.org
>  description     David's Advanced Revision Control System
> @@ -37,3 +38,8 @@
>  		configure.args-append	--with-docs
>  }
>
> +variant profiling description {Build darcs with runtime profiling  
> enabled} {
> +		configure.args-append	--enable-profile
> +		patchfiles-append	patch-GNUmakefile.diff
> +}



From ryandesign at macports.org  Wed Jul 30 20:40:37 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 30 Jul 2008 22:40:37 -0500
Subject: Conflict with /Applications/MacPorts when multiple
	MacPorts	instances installed
In-Reply-To: <4890FCFB.3090709@macports.org>
References: <48907B70.4050409@anl.gov> <48907C6D.4000802@macports.org>
	<4890FCFB.3090709@macports.org>
Message-ID: <05D25329-AA61-47D0-A567-9E06F51288B8@macports.org>


On Jul 30, 2008, at 18:44, Rainer M?ller wrote:

> Joshua Root wrote:
>
>> The configure option you want is --with-applications-dir. A full  
>> list is
>> available from './configure --help'.
>
> As this option is only available in trunk, all current ports have
> "/Applications/MacPorts" and the framework path hardcoded. As of the
> next release ${applications_dir} and ${frameworks_dir} can be used in
> Portfiles instead. Until then, there is no easy solution to keep
> multiple MacPorts installations.

Ports that currently hardcode /Applications/MacPorts can already be  
updated to support the ${applications_dir} variable by adding this  
snippet to the port before using the ${applications_dir} variable:

# Can be removed once MacPorts 1.7.0 is released
if {![info exists applications_dir]} {
     set applications_dir /Applications/MacPorts
}

See the lisaem port for an example.


From blair at orcaware.com  Wed Jul 30 21:26:03 2008
From: blair at orcaware.com (Blair Zajac)
Date: Wed, 30 Jul 2008 21:26:03 -0700
Subject: [38761] trunk/dports/devel/darcs
In-Reply-To: <85EAD4E2-8B4E-4AD4-93F6-0F7922D9D656@macports.org>
References: <20080730175039.05E2C19F4D7@beta.macosforge.org>
	<85EAD4E2-8B4E-4AD4-93F6-0F7922D9D656@macports.org>
Message-ID: <48913EDB.3030200@orcaware.com>

Ryan Schmidt wrote:
> On Jul 30, 2008, at 12:50, gwright at macports.org wrote:
> 
>> Revision: 38761
>>           http://trac.macosforge.org/projects/macports/changeset/38761
>> Author:   gwright at macports.org
>> Date:     2008-07-30 10:50:38 -0700 (Wed, 30 Jul 2008)
>> Log Message:
>> -----------
>> Add profiling variant (mostly of interest to those working to
>> improve darcs internals).
> 
> FYI, when you add a variant, you don't need to increase the port  
> revision, since nothing will change for those users who already had  
> the port installed.

But on the other hand, if you weren't aware of this variant, there would be no 
way to tell.  With a bump in revision, you can check for new variants.

Blair

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

From ryandesign at macports.org  Wed Jul 30 21:57:41 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 30 Jul 2008 23:57:41 -0500
Subject: [38761] trunk/dports/devel/darcs
In-Reply-To: <48913EDB.3030200@orcaware.com>
References: <20080730175039.05E2C19F4D7@beta.macosforge.org>
	<85EAD4E2-8B4E-4AD4-93F6-0F7922D9D656@macports.org>
	<48913EDB.3030200@orcaware.com>
Message-ID: <47FE942E-B02F-44E5-BED2-5E16E881E26F@macports.org>

On Jul 30, 2008, at 23:26, Blair Zajac wrote:

> Ryan Schmidt wrote:
>
>> On Jul 30, 2008, at 12:50, gwright at macports.org wrote:
>>
>>> Revision: 38761
>>>           http://trac.macosforge.org/projects/macports/changeset/ 
>>> 38761
>>> Author:   gwright at macports.org
>>> Date:     2008-07-30 10:50:38 -0700 (Wed, 30 Jul 2008)
>>> Log Message:
>>> -----------
>>> Add profiling variant (mostly of interest to those working to
>>> improve darcs internals).
>>
>> FYI, when you add a variant, you don't need to increase the port
>> revision, since nothing will change for those users who already had
>> the port installed.
>
> But on the other hand, if you weren't aware of this variant, there  
> would be no
> way to tell.  With a bump in revision, you can check for new variants.

I don't like increasing the revision as a means for informing users  
that a new variant is available. Increasing the revision causes the  
port to show up in "port outdated" and on the mailing list and  
hopefully in the Guide, users are encouraged to update their ports.  
For some larger ports and/or slower computers this can take a long  
time. Let's not waste users' time by needlessly increasing port  
revisions when nothing about the files that get installed has changed.

I think it's a fine idea to have a way to inform users that new  
variants are available for ports they have installed. But let's make  
a new way for users to be informed of that. Let's not overload the  
port revision.


From ryandesign at macports.org  Wed Jul 30 23:34:20 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 31 Jul 2008 01:34:20 -0500
Subject: [38384] trunk/dports/lang
In-Reply-To: <01224C56-0887-40A6-9E6E-97E12C900793@macports.org>
References: <20080718092331.A7B8115D1D1@beta.macosforge.org>
	<75AB6EE3-4F75-498A-A613-0C20289EF243@macports.org>
	<01224C56-0887-40A6-9E6E-97E12C900793@macports.org>
Message-ID: <45A2400A-8850-4CA6-A5B3-4A4BC69D08BB@macports.org>

On Jul 18, 2008, at 05:36, Ryan Schmidt wrote:

> On Jul 18, 2008, at 05:07, Ryan Schmidt wrote:
>
>> On Jul 18, 2008, at 04:23, pguyot at kallisys.net wrote:
>>
>>> Revision: 38384
>>>           http://trac.macosforge.org/projects/macports/changeset/
>>> 38384
>>> Author:   pguyot at kallisys.net
>>> Date:     2008-07-18 02:23:30 -0700 (Fri, 18 Jul 2008)
>>> Log Message:
>>> -----------
>>> new port: lang/llvm-devel, a recent checkout of llvm with clang/
>>> checker as a variant
>>>
>>> Added Paths:
>>> -----------
>>>     trunk/dports/lang/llvm-devel/
>>>     trunk/dports/lang/llvm-devel/Portfile
>>>     trunk/dports/lang/llvm-devel/files/
>>>     trunk/dports/lang/llvm-devel/files/patch-tools-Makefile.diff
>>
>> It would be nice if you would use "svn cp" to copy this Portfile from
>> the llvm Portfile and then make changes, rather than calling it into
>> existence as a new file here. That way "svn log" and "svn blame"
>> would be useful. Could you please re-create the port this way?  
>> Thanks.
>
> Then you can also pick up the fixes I just made to the llvm port.

I recreated the port in r38775.


From ryandesign at macports.org  Thu Jul 31 00:03:58 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 31 Jul 2008 02:03:58 -0500
Subject: [38678] d-mode.el
In-Reply-To: <20080728171043.13289192B57@beta.macosforge.org>
References: <20080728171043.13289192B57@beta.macosforge.org>
Message-ID: <55AE6DD0-B3FC-454F-970F-33BE6CEE28DF@macports.org>


On Jul 28, 2008, at 12:10, jmr at macports.org wrote:

> Revision: 38678
>           http://trac.macosforge.org/projects/macports/changeset/38678
> Author:   jmr at macports.org
> Date:     2008-07-28 10:10:42 -0700 (Mon, 28 Jul 2008)
> Log Message:
> -----------
> New port: d-mode.el (#15792)

I suggest:

  * removing the backslash at the end of the long description
  * using "extract.mkdir yes" instead of "file mkdir ${worksrcpath}"  
in the extract phase
  * using "copy" instead of "file copy"
  * using "${distpath}" instead of "${prefix}/var/macports/distfiles/$ 
{name}"


-------------- next part --------------
A non-text attachment was scrubbed...
Name: d-mode.el.diff
Type: application/octet-stream
Size: 891 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20080731/8ec6b4e9/attachment.obj 

From ryandesign at macports.org  Thu Jul 31 00:08:38 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 31 Jul 2008 02:08:38 -0500
Subject: [38683] trunk/base/src/port1.0/resources/group
In-Reply-To: <20080728212133.ABAEA1966AF@beta.macosforge.org>
References: <20080728212133.ABAEA1966AF@beta.macosforge.org>
Message-ID: <8F1D2CC9-F8E3-4E4E-999A-4C9D23921DAA@macports.org>


On Jul 28, 2008, at 16:21, febeling at macports.org wrote:

> Added: trunk/base/src/port1.0/resources/group/tests/ruby-1.0.tcl
> ===================================================================
> --- trunk/base/src/port1.0/resources/group/tests/ 
> ruby-1.0.tcl	                        (rev 0)
> +++ trunk/base/src/port1.0/resources/group/tests/ruby-1.0.tcl	 
> 2008-07-28 21:21:33 UTC (rev 38683)
> @@ -0,0 +1,148 @@
> +#!/bin/sh
> +# start as tcl \
> +exec tclsh "$0" "$@"
> +
> +set prefix                    /opt/local

Is it necessary to hardcode /opt/local here or could the actual  
MacPorts prefix be somehow determined?

Also, although you define the ${prefix} variable here, you use /opt/ 
local four subsequent times in the script. Shouldn't ${prefix} be  
used in those cases too?


From afb at macports.org  Thu Jul 31 00:10:19 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Thu, 31 Jul 2008 09:10:19 +0200
Subject: Conflict with /Applications/MacPorts when multiple MacPorts
	instances installed
In-Reply-To: <c24012060807301638k2d924bf4i1eaf912afa7d191@mail.gmail.com>
References: <48907B70.4050409@anl.gov> <48907C6D.4000802@macports.org>
	<48907F39.50200@anl.gov> <48908134.7030605@macports.org>
	<8DA288B4-05C9-4661-8EA6-F0AF14CF5C17@macports.org>
	<72372C98-B591-4AF6-9181-21D858629CFF@macports.org>
	<E3010F3D-FABE-4A76-BD3B-7100D33606B5@macports.org>
	<c24012060807301638k2d924bf4i1eaf912afa7d191@mail.gmail.com>
Message-ID: <31B821D7-8245-4BC4-B500-26FD7E9AF400@macports.org>

Randall Wood wrote:

> /Applications is a magic location in Mac OS X. Unless your app is in
> /Applications, ~/Applications, or /Network/*/Applications (I'm not
> sure how the /Network domain works), certain standard Cocoa features
> (like placing items in the Services menu) will be turned off in the
> app. Since MacPorts sticks its apps in /Applications/MacPorts, its
> apps get the standard features (Fink apps don't).

Right, so we get the three settings. Four, if you count "tclpackage".
/Library/Tcl being another magic location of Mac OS X, Ticket #12943
Note that the defaults change to ~, if not installing as root user.
(i.e. ~/Applications/MacPorts, ~/Library/Frameworks, ~/Library/Tcl)

But moving frameworks to inside prefix would be a good thing anyway,
even if not able to move the other two locations due to restrictions.

--anders


From ryandesign at macports.org  Thu Jul 31 00:17:07 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 31 Jul 2008 02:17:07 -0500
Subject: [38686] trunk/dports/python
In-Reply-To: <20080728215758.36F901968A6@beta.macosforge.org>
References: <20080728215758.36F901968A6@beta.macosforge.org>
Message-ID: <56557EC8-AB91-4507-B933-E8E4B57BB931@macports.org>

On Jul 28, 2008, at 16:57, stechert at macports.org wrote:

> Revision: 38686
>           http://trac.macosforge.org/projects/macports/changeset/38686
> Author:   stechert at macports.org
> Date:     2008-07-28 14:57:57 -0700 (Mon, 28 Jul 2008)
> Log Message:
> -----------
> Creating new py25 port for mssql 0.8.0

When creating ports derived from other ports, please use "svn copy"  
to create the copy, rather than using a normal OS copy or creating  
the files from scratch. For example in this case, py25-mssql is  
clearly based on py-mssql but because you did not use "svn copy" the  
history is disconnected and the commands "svn log" and "svn blame" on  
py25-mssql are not useful. Instead you should have changed to the  
dports/python directory and used "svn copy py-mssql py25-mssql", then  
made your edits to py25-mssql, then committed. I have deleted the  
port in r38777 and recreated it in r38778 to accomplish this.



From ryandesign at macports.org  Thu Jul 31 00:46:41 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 31 Jul 2008 02:46:41 -0500
Subject: chunked guide - macports.org/docs/ 
In-Reply-To: <fc.004c4c580fefcbfe004c4c580fefcbfe.fefd4d4@biola.edu>
References: <fc.004c4c580fefcbfe004c4c580fefcbfe.fefd4d4@biola.edu>
Message-ID: <DF93F02A-F7C5-4968-A4CB-9BF54CD6D231@macports.org>

On Jul 30, 2008, at 11:23, markd at macports.org wrote:

>> My idea was for /docs/ to be static HTML/PHP  in the repo which
>> renders to something like:
>>
>>
>> Documentation:
>> 	* Installation

We currently have a standalone page:

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

and a Guide chapter:

	http://guide.macports.org/#installing

and a Wiki page:

	http://trac.macports.org/wiki/InstallingMacPorts

Though some users may want to install trunk, for which we a separate  
how-to:

	http://trac.macports.org/wiki/howto/RunningTrunk

And also:

	http://trac.macports.org/wiki/GetMacPortsSource


>> 	* HOWTOs

The list of how-to's is in the Wiki:

	http://trac.macports.org/wiki/howto


>> 	* Guide:
>> 		* Chunked HTML
>> 		* Single HTML
>> 		* a future PDF version maybe?

Yes, that would be good. Much like the Subversion project offers many  
formats of its book; see:

	http://svnbook.org/


>> 	* FAQ

Frequently-asked questions are in the Wiki:

	http://trac.macports.org/wiki/FAQ

Though we also have the ProblemHotlist:

	http://trac.macports.org/wiki/ProblemHotlist

And LeopardProblems:

	http://trac.macports.org/wiki/LeopardProblems

All of these should probably be regrouped as just "FAQs".

And I mentioned in an earlier thread that I think it would be a good  
idea if we would have a Wiki page to describe several of the error  
messages that a user might be expected to encounter in the course of  
using MacPorts. So an "Error Messages" menu item on the docs page  
would be good.


>> 	* Bug Reporting Guidelines

We have bug reporting guidelines in the Guide:

	http://guide.macports.org/#project

And also in the Wiki:

	http://trac.macports.org/wiki/TracTicketing


>> 	* Becoming a Member??

Good idea. We currently have these documents on that topic:

	http://guide.macports.org/#project.membership

	http://trac.macports.org/wiki/NewCommittersGuide

	http://trac.macports.org/wiki/CommittersTipsAndTricks



I would also want a "how to use MacPorts" document. These documents  
describe that, though probably not completely:

	http://guide.macports.org/#using

	http://trac.macports.org/wiki/UsingMacPortsQuickStart


>> So this /docs/ page would replace several left navigation links on
>> macports.org. The existing Documentation link would point to /docs/
>> and the above list.
>
> I like this idea.  One benefit would be that it would allow us to  
> unify
> the install information (guide & website are different), which  
> needs to be
> done anyway.


I would recommend that before we create a documentation index page,  
we consolidate our documentation and not have three or four distinct  
URLs describing the same basic things. A lot of the Guide was taken  
from Wiki pages, so the Wiki pages that the Guide obsoletes should be  
cleared of their contents and replaced with a link to the appropriate  
Guide section (after ensuring that all content from the Wiki pages  
has made it into the corresponding Guide sections).


So www.macports.org/docs would list the available documentation. And  
the Guide would be where? Still at guide.macports.org? Or would it  
move to www.macports.org/guide? or www.macports.org/docs/guide? An  
advantage I think of keeping the Guide on its own hostname is that  
you can limit a Google search to just that hostname, so you get just  
Guide results. If we move the Guide to www.macports.org/whatever, can  
we still make a Google search that just searches the Guide?

The wiki would stay at trac.macports.org/wiki? Or would you want it  
to move to www.macports.org/wiki? or www.macports.org/docs/wiki? I'm  
not sure if we can or should move the wiki URL independent of the  
rest of the Trac URLs.



From jmr at macports.org  Thu Jul 31 00:55:28 2008
From: jmr at macports.org (Joshua Root)
Date: Thu, 31 Jul 2008 17:55:28 +1000
Subject: [38678] d-mode.el
In-Reply-To: <55AE6DD0-B3FC-454F-970F-33BE6CEE28DF@macports.org>
References: <20080728171043.13289192B57@beta.macosforge.org>
	<55AE6DD0-B3FC-454F-970F-33BE6CEE28DF@macports.org>
Message-ID: <48916FF0.2090003@macports.org>

Ryan Schmidt wrote:
> 
> On Jul 28, 2008, at 12:10, jmr at macports.org wrote:
> 
>> Revision: 38678
>>           http://trac.macosforge.org/projects/macports/changeset/38678
>> Author:   jmr at macports.org
>> Date:     2008-07-28 10:10:42 -0700 (Mon, 28 Jul 2008)
>> Log Message:
>> -----------
>> New port: d-mode.el (#15792)
> 
> I suggest:
> 
>  * removing the backslash at the end of the long description
>  * using "extract.mkdir yes" instead of "file mkdir ${worksrcpath}" in 
> the extract phase
>  * using "copy" instead of "file copy"
>  * using "${distpath}" instead of 
> "${prefix}/var/macports/distfiles/${name}"

Done. Thanks for spotting those.

- Josh

From florian.ebeling at gmail.com  Thu Jul 31 02:37:20 2008
From: florian.ebeling at gmail.com (Caspar Florian Ebeling)
Date: Thu, 31 Jul 2008 11:37:20 +0200
Subject: [38761] trunk/dports/devel/darcs
In-Reply-To: <48913EDB.3030200@orcaware.com>
References: <20080730175039.05E2C19F4D7@beta.macosforge.org>
	<85EAD4E2-8B4E-4AD4-93F6-0F7922D9D656@macports.org>
	<48913EDB.3030200@orcaware.com>
Message-ID: <5cbbe4ae0807310237m69a76b3bj297b6c4a5b73c335@mail.gmail.com>

On Thu, Jul 31, 2008 at 6:26 AM, Blair Zajac <blair at orcaware.com> wrote:
> Ryan Schmidt wrote:
>> On Jul 30, 2008, at 12:50, gwright at macports.org wrote:
>>
>>> Revision: 38761
>>>           http://trac.macosforge.org/projects/macports/changeset/38761
>>> Author:   gwright at macports.org
>>> Date:     2008-07-30 10:50:38 -0700 (Wed, 30 Jul 2008)
>>> Log Message:
>>> -----------
>>> Add profiling variant (mostly of interest to those working to
>>> improve darcs internals).
>>
>> FYI, when you add a variant, you don't need to increase the port
>> revision, since nothing will change for those users who already had
>> the port installed.
>
> But on the other hand, if you weren't aware of this variant, there would be no
> way to tell.  With a bump in revision, you can check for new variants.

I think you're mistaken. You do get the latest variants from the
current portfile,
independently of the revision installed.

Florian

-- 
Florian Ebeling
florian.ebeling at gmail.com

From febeling at macports.org  Thu Jul 31 02:52:13 2008
From: febeling at macports.org (Caspar Florian Ebeling)
Date: Thu, 31 Jul 2008 11:52:13 +0200
Subject: [38683] trunk/base/src/port1.0/resources/group
In-Reply-To: <8F1D2CC9-F8E3-4E4E-999A-4C9D23921DAA@macports.org>
References: <20080728212133.ABAEA1966AF@beta.macosforge.org>
	<8F1D2CC9-F8E3-4E4E-999A-4C9D23921DAA@macports.org>
Message-ID: <5cbbe4ae0807310252y57027794u56bc7eaaa1f784d2@mail.gmail.com>

On Thu, Jul 31, 2008 at 9:08 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Jul 28, 2008, at 16:21, febeling at macports.org wrote:
>> Added: trunk/base/src/port1.0/resources/group/tests/ruby-1.0.tcl
>> ===================================================================
>> --- trunk/base/src/port1.0/resources/group/tests/ruby-1.0.tcl
>>                (rev 0)
>> +++ trunk/base/src/port1.0/resources/group/tests/ruby-1.0.tcl   2008-07-28
>> 21:21:33 UTC (rev 38683)
>> @@ -0,0 +1,148 @@
>> +#!/bin/sh
>> +# start as tcl \
>> +exec tclsh "$0" "$@"
>> +
>> +set prefix                    /opt/local
>
> Is it necessary to hardcode /opt/local here or could the actual MacPorts
> prefix be somehow determined?
>
> Also, although you define the ${prefix} variable here, you use /opt/local
> four subsequent times in the script. Shouldn't ${prefix} be used in those
> cases too?

Yeah, I will change it to something like dirname(which port).
Or maybe I mock away the whole ruby port dependence of the
test. That would be a still nicer option, but also complicates the
test further. I think about it.

Florian




-- 
Florian Ebeling
florian.ebeling at gmail.com

From raimue at macports.org  Thu Jul 31 03:12:20 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 31 Jul 2008 12:12:20 +0200
Subject: Conflict with /Applications/MacPorts when multiple
	MacPorts	instances installed
In-Reply-To: <05D25329-AA61-47D0-A567-9E06F51288B8@macports.org>
References: <48907B70.4050409@anl.gov> <48907C6D.4000802@macports.org>
	<4890FCFB.3090709@macports.org>
	<05D25329-AA61-47D0-A567-9E06F51288B8@macports.org>
Message-ID: <48919004.2080506@macports.org>

Ryan Schmidt wrote:
> Ports that currently hardcode /Applications/MacPorts can already be  
> updated to support the ${applications_dir} variable by adding this  
> snippet to the port before using the ${applications_dir} variable:
> 
> # Can be removed once MacPorts 1.7.0 is released
> if {![info exists applications_dir]} {
>      set applications_dir /Applications/MacPorts
> }
> 
> See the lisaem port for an example.

Thanks, this is a very good idea. I will change my ports in the same way.

Rainer

From ryandesign at macports.org  Thu Jul 31 03:19:02 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 31 Jul 2008 05:19:02 -0500
Subject: [38761] trunk/dports/devel/darcs
In-Reply-To: <5cbbe4ae0807310237m69a76b3bj297b6c4a5b73c335@mail.gmail.com>
References: <20080730175039.05E2C19F4D7@beta.macosforge.org>
	<85EAD4E2-8B4E-4AD4-93F6-0F7922D9D656@macports.org>
	<48913EDB.3030200@orcaware.com>
	<5cbbe4ae0807310237m69a76b3bj297b6c4a5b73c335@mail.gmail.com>
Message-ID: <35B4F59A-1C73-4DAF-9A3A-983E82424528@macports.org>

On Jul 31, 2008, at 04:37, Caspar Florian Ebeling wrote:

> On Thu, Jul 31, 2008 at 6:26 AM, Blair Zajac wrote:
>
>> Ryan Schmidt wrote:
>>>
>>
>>> FYI, when you add a variant, you don't need to increase the port
>>> revision, since nothing will change for those users who already had
>>> the port installed.
>>
>> But on the other hand, if you weren't aware of this variant, there  
>> would be no
>> way to tell.  With a bump in revision, you can check for new  
>> variants.
>
> I think you're mistaken. You do get the latest variants from the
> current portfile, independently of the revision installed.

Yes, if you type "port variants foo" you will learn about all of port  
foo's variants, even if you had installed the port previous to those  
variants existing (assuming your ports and portindex are up to date).  
However, if you installed the port earlier, how would you know that  
you should run "port variants foo" now? How would you know that a new  
variant you might care about had become available? Blair is saying  
that the fact that a port shows up in the output of "port outdated"  
should be a signal to the user to run "port variants" on that port to  
see if any new variants are available. I say that "port outdated" is  
only for informing you of ports that are outdated on your system, and  
in my other message I suggested that we could build a new mechanism  
by which users could be informed of new variants.

On further reflection, I'm not sure that's necessary. Because if a  
user needs a variant that is not available at the time, the user  
should file a ticket requesting that variant, or Cc themselves on an  
existing ticket requesting that variant. When the variant is added to  
the port, the ticket will be updated and closed, which will send an  
email to the user, thus notifying them of the availability of the  
variant.

The same applies to ports. If a user goes looking for a port and  
discovers there is no such port, but it later becomes available, the  
user won't be informed of that either, unless they go looking for it  
again, or they are Cc'd on the ticket via which the port was added.

The moral of the story is that users should Cc themselves on tickets  
whose resolutions they're interested in, and file tickets for  
unresolved issues which don't yet have tickets.


From florian.ebeling at gmail.com  Thu Jul 31 04:31:35 2008
From: florian.ebeling at gmail.com (Caspar Florian Ebeling)
Date: Thu, 31 Jul 2008 13:31:35 +0200
Subject: [38761] trunk/dports/devel/darcs
In-Reply-To: <35B4F59A-1C73-4DAF-9A3A-983E82424528@macports.org>
References: <20080730175039.05E2C19F4D7@beta.macosforge.org>
	<85EAD4E2-8B4E-4AD4-93F6-0F7922D9D656@macports.org>
	<48913EDB.3030200@orcaware.com>
	<5cbbe4ae0807310237m69a76b3bj297b6c4a5b73c335@mail.gmail.com>
	<35B4F59A-1C73-4DAF-9A3A-983E82424528@macports.org>
Message-ID: <5cbbe4ae0807310431hfed9b6bo543c45c0fb26f113@mail.gmail.com>

> On further reflection, I'm not sure that's necessary. Because if a user
> needs a variant that is not available at the time, the user should file a
> ticket requesting that variant, or Cc themselves on an existing ticket
> requesting that variant. When the variant is added to the port, the ticket
> will be updated and closed, which will send an email to the user, thus
> notifying them of the availability of the variant.
>
> The same applies to ports. If a user goes looking for a port and discovers
> there is no such port, but it later becomes available, the user won't be
> informed of that either, unless they go looking for it again, or they are
> Cc'd on the ticket via which the port was added.
+1


-- 
Florian Ebeling
florian.ebeling at gmail.com

From blair at orcaware.com  Thu Jul 31 06:53:22 2008
From: blair at orcaware.com (Blair Zajac)
Date: Thu, 31 Jul 2008 06:53:22 -0700
Subject: [38686] trunk/dports/python
In-Reply-To: <56557EC8-AB91-4507-B933-E8E4B57BB931@macports.org>
References: <20080728215758.36F901968A6@beta.macosforge.org>
	<56557EC8-AB91-4507-B933-E8E4B57BB931@macports.org>
Message-ID: <2E3DD8DC-5009-4A8C-A24A-CDA74380A084@orcaware.com>


On Jul 31, 2008, at 12:17 AM, Ryan Schmidt wrote:

> On Jul 28, 2008, at 16:57, stechert at macports.org wrote:
>
>> Revision: 38686
>>          http://trac.macosforge.org/projects/macports/changeset/38686
>> Author:   stechert at macports.org
>> Date:     2008-07-28 14:57:57 -0700 (Mon, 28 Jul 2008)
>> Log Message:
>> -----------
>> Creating new py25 port for mssql 0.8.0
>
> When creating ports derived from other ports, please use "svn copy"
> to create the copy, rather than using a normal OS copy or creating
> the files from scratch. For example in this case, py25-mssql is
> clearly based on py-mssql but because you did not use "svn copy" the
> history is disconnected and the commands "svn log" and "svn blame" on
> py25-mssql are not useful. Instead you should have changed to the
> dports/python directory and used "svn copy py-mssql py25-mssql", then
> made your edits to py25-mssql, then committed. I have deleted the
> port in r38777 and recreated it in r38778 to accomplish this.

Not only that, but the commit from the copy would show the diffs it  
took to migrate the port from 2.4 to 2.5, making it easier to review.

Regards,
Blair

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



From wsiegrist at apple.com  Thu Jul 31 13:30:37 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Thu, 31 Jul 2008 13:30:37 -0700
Subject: chunked guide - macports.org/docs/
In-Reply-To: <DF93F02A-F7C5-4968-A4CB-9BF54CD6D231@macports.org>
References: <fc.004c4c580fefcbfe004c4c580fefcbfe.fefd4d4@biola.edu>
	<DF93F02A-F7C5-4968-A4CB-9BF54CD6D231@macports.org>
Message-ID: <3F8291C1-A36D-473B-985A-94B6AB0F8ACE@apple.com>


On Jul 31, 2008, at 12:46 AM, Ryan Schmidt wrote:

> On Jul 30, 2008, at 11:23, markd at macports.org wrote:
>
>>> My idea was for /docs/ to be static HTML/PHP  in the repo which
>>> renders to something like:
>>>
>>>
>>> Documentation:
>>> 	* Installation
>
>
>
>>> So this /docs/ page would replace several left navigation links on
>>> macports.org. The existing Documentation link would point to /docs/
>>> and the above list.
>>
>> I like this idea.  One benefit would be that it would allow us to  
>> unify
>> the install information (guide & website are different), which  
>> needs to be
>> done anyway.
>
>
> I would recommend that before we create a documentation index page,  
> we consolidate our documentation and not have three or four distinct  
> URLs describing the same basic things. A lot of the Guide was taken  
> from Wiki pages, so the Wiki pages that the Guide obsoletes should  
> be cleared of their contents and replaced with a link to the  
> appropriate Guide section (after ensuring that all content from the  
> Wiki pages has made it into the corresponding Guide sections).
>
>

I added <http://macports.org/docs.php> which just lists all of the  
URLs Ryan listed. That page isnt linked to from anywhere, so for now  
we can use it to track all of the docs we have as we try to shorten  
the list.

> So www.macports.org/docs would list the available documentation. And  
> the Guide would be where? Still at guide.macports.org? Or would it  
> move to www.macports.org/guide? or www.macports.org/docs/guide? An  
> advantage I think of keeping the Guide on its own hostname is that  
> you can limit a Google search to just that hostname, so you get just  
> Guide results. If we move the Guide to www.macports.org/whatever,  
> can we still make a Google search that just searches the Guide?
>

In keeping with current convention, its "/docs.php".  We can keep  
guide.macports.org, but use "/single" and "/chunked"? I can add a  
redirect so it defaults to one or the other when visiting just http://guide.macports.org/ 
. I guess the consensus so far is to default to chunked?

> The wiki would stay at trac.macports.org/wiki? Or would you want it  
> to move to www.macports.org/wiki? or www.macports.org/docs/wiki? I'm  
> not sure if we can or should move the wiki URL independent of the  
> rest of the Trac URLs.
>

Its possible to serve out the Trac wiki from www.macports.org, but  
probably not worth the effort. I think trac.macports.org should stay.  
Other projects do this, but usually have a generic name like  
"code.macports.org" so its not branded with the app you happen to be  
using. What would be nice is if the two sites shared styles so they  
look similar, I just dont have a lot of time right now to do that.  
Maybe after Trac 0.11 since I have to redo all the templates anyway.


-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/20080731/8a5e3478/attachment.bin 

From ryandesign at macports.org  Thu Jul 31 18:14:20 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 31 Jul 2008 20:14:20 -0500
Subject: buildmakejobs 0 by default to allow parallel builds
Message-ID: <8584E065-818F-426C-ACC8-184976B59227@macports.org>

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.

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.


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.



Comments?


From ramercer at gmail.com  Thu Jul 31 21:05:29 2008
From: ramercer at gmail.com (Adam Mercer)
Date: Thu, 31 Jul 2008 23:05:29 -0500
Subject: [38815] trunk/dports/science/geos
In-Reply-To: <20080801000737.9FB861A78A3@beta.macosforge.org>
References: <20080801000737.9FB861A78A3@beta.macosforge.org>
Message-ID: <799406d60807312105i52455880o16e0c088264b8504@mail.gmail.com>

On Thu, Jul 31, 2008 at 7:07 PM,  <landonf at macports.org> wrote:

> 3.0 's C-API is both API and binary compatible with the 2.x release, and I
> tested building / running PostGIS.

No it is not, py25-matplotlib-basemap is now broken, it does not build
against 3.0.x!

From ramercer at gmail.com  Thu Jul 31 21:21:21 2008
From: ramercer at gmail.com (Adam Mercer)
Date: Thu, 31 Jul 2008 23:21:21 -0500
Subject: [38815] trunk/dports/science/geos
In-Reply-To: <799406d60807312105i52455880o16e0c088264b8504@mail.gmail.com>
References: <20080801000737.9FB861A78A3@beta.macosforge.org>
	<799406d60807312105i52455880o16e0c088264b8504@mail.gmail.com>
Message-ID: <799406d60807312121u6ab1b1f3hf3371af3817f03c@mail.gmail.com>

On Thu, Jul 31, 2008 at 11:05 PM, Adam Mercer <ramercer at gmail.com> wrote:
> On Thu, Jul 31, 2008 at 7:07 PM,  <landonf at macports.org> wrote:
>
>> 3.0 's C-API is both API and binary compatible with the 2.x release, and I
>> tested building / running PostGIS.
>
> No it is not, py25-matplotlib-basemap is now broken, it does not build
> against 3.0.x!

reverted in r38822

Cheers

Adam

From landonf at macports.org  Thu Jul 31 21:23:24 2008
From: landonf at macports.org (Landon Fuller)
Date: Thu, 31 Jul 2008 21:23:24 -0700
Subject: [38815] trunk/dports/science/geos
In-Reply-To: <799406d60807312105i52455880o16e0c088264b8504@mail.gmail.com>
References: <20080801000737.9FB861A78A3@beta.macosforge.org>
	<799406d60807312105i52455880o16e0c088264b8504@mail.gmail.com>
Message-ID: <481FCC3C-060A-460D-9907-14CA8E24926B@macports.org>


On Jul 31, 2008, at 9:05 PM, Adam Mercer wrote:

> On Thu, Jul 31, 2008 at 7:07 PM,  <landonf at macports.org> wrote:
>
>> 3.0 's C-API is both API and binary compatible with the 2.x  
>> release, and I
>> tested building / running PostGIS.
>
> No it is not, py25-matplotlib-basemap is now broken, it does not build
> against 3.0.x!


I went off the developer's statements on compatibility, but,  
unfortunately:
	http://www.mail-archive.com/matplotlib-users at lists.sourceforge.net/msg05301.html

So it sounds like we either need to fix the issues, or keep around  
GEOS 2.x *and* GEOS 3.x, and that's going to be a bloody mess.

I see you rolled back the port. It looks like ticket #13699 has been  
sitting since March -- can I just create a GEOS 2.x port and py25- 
matplotlib-basemap can depend on that?

I'd like to move the state of the world forward.

-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/20080731/e3b004b2/attachment.bin 

From ramercer at gmail.com  Thu Jul 31 21:38:03 2008
From: ramercer at gmail.com (Adam Mercer)
Date: Thu, 31 Jul 2008 23:38:03 -0500
Subject: [38815] trunk/dports/science/geos
In-Reply-To: <481FCC3C-060A-460D-9907-14CA8E24926B@macports.org>
References: <20080801000737.9FB861A78A3@beta.macosforge.org>
	<799406d60807312105i52455880o16e0c088264b8504@mail.gmail.com>
	<481FCC3C-060A-460D-9907-14CA8E24926B@macports.org>
Message-ID: <799406d60807312138j4b2ba462k5df088e47f00475f@mail.gmail.com>

On Thu, Jul 31, 2008 at 11:23 PM, Landon Fuller <landonf at macports.org> wrote:
>
> On Jul 31, 2008, at 9:05 PM, Adam Mercer wrote:
>
>> On Thu, Jul 31, 2008 at 7:07 PM,  <landonf at macports.org> wrote:
>>
>>> 3.0 's C-API is both API and binary compatible with the 2.x release, and
>>> I
>>> tested building / running PostGIS.
>>
>> No it is not, py25-matplotlib-basemap is now broken, it does not build
>> against 3.0.x!
>
>
> I went off the developer's statements on compatibility, but, unfortunately:
>
>  http://www.mail-archive.com/matplotlib-users at lists.sourceforge.net/msg05301.html
>
> So it sounds like we either need to fix the issues, or keep around GEOS 2.x
> *and* GEOS 3.x, and that's going to be a bloody mess.
>
> I see you rolled back the port. It looks like ticket #13699 has been sitting
> since March -- can I just create a GEOS 2.x port and py25-matplotlib-basemap
> can depend on that?

I've been trying since March to get basemap working with 3.0.x, it can
build but doesn't work properly. The basemap developer has also been
trying and can't get anywhere. So at the moment, the only solution is
to have a separate geos3 port. As you want to add ports that require
geos3 we'll have to go that way.

Cheers

Adam

>
> I'd like to move the state of the world forward.
>
> -landonf
>

From landonf at macports.org  Thu Jul 31 23:12:43 2008
From: landonf at macports.org (Landon Fuller)
Date: Thu, 31 Jul 2008 23:12:43 -0700
Subject: [38815] trunk/dports/science/geos
In-Reply-To: <799406d60807312138j4b2ba462k5df088e47f00475f@mail.gmail.com>
References: <20080801000737.9FB861A78A3@beta.macosforge.org>
	<799406d60807312105i52455880o16e0c088264b8504@mail.gmail.com>
	<481FCC3C-060A-460D-9907-14CA8E24926B@macports.org>
	<799406d60807312138j4b2ba462k5df088e47f00475f@mail.gmail.com>
Message-ID: <A4482401-64AD-4525-8414-43DC4490BCE4@macports.org>


On Jul 31, 2008, at 9:38 PM, Adam Mercer wrote:

> On Thu, Jul 31, 2008 at 11:23 PM, Landon Fuller  
> <landonf at macports.org> wrote:
>>
>> On Jul 31, 2008, at 9:05 PM, Adam Mercer wrote:
>>
>>> On Thu, Jul 31, 2008 at 7:07 PM,  <landonf at macports.org> wrote:
>>>
>>>> 3.0 's C-API is both API and binary compatible with the 2.x  
>>>> release, and
>>>> I
>>>> tested building / running PostGIS.
>>>
>>> No it is not, py25-matplotlib-basemap is now broken, it does not  
>>> build
>>> against 3.0.x!
>>
>>
>> I went off the developer's statements on compatibility, but,  
>> unfortunately:
>>
>> http://www.mail-archive.com/matplotlib-users at lists.sourceforge.net/msg05301.html
>>
>> So it sounds like we either need to fix the issues, or keep around  
>> GEOS 2.x
>> *and* GEOS 3.x, and that's going to be a bloody mess.
>>
>> I see you rolled back the port. It looks like ticket #13699 has  
>> been sitting
>> since March -- can I just create a GEOS 2.x port and py25- 
>> matplotlib-basemap
>> can depend on that?
>
> I've been trying since March to get basemap working with 3.0.x, it can
> build but doesn't work properly. The basemap developer has also been
> trying and can't get anywhere. So at the moment, the only solution is
> to have a separate geos3 port. As you want to add ports that require
> geos3 we'll have to go that way.

OK, I implemented the fixes for issue #13699:
	geos2 committed in r38824.
	py25-matplotlib-basemap updated in r38825.
	py-matplotlib-basemap updated in r38826.
	geos updated to 3.0.0 in r38827.
	matplotlib-basemap port revisions bumped in r38828 to ensure that the  
ports are linked to geos2.

I verified that the basemap ports were correctly linked, and ran  
example/test.py to sanity-check the output. I've got time to spend on  
this, so please let me know if anything is incorrect and I'll get it  
working.

-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/20080731/a19622b7/attachment-0001.bin 

From jmr at macports.org  Thu Jul 31 23:56:48 2008
From: jmr at macports.org (Joshua Root)
Date: Fri, 01 Aug 2008 16:56:48 +1000
Subject: [38815] trunk/dports/science/geos
In-Reply-To: <A4482401-64AD-4525-8414-43DC4490BCE4@macports.org>
References: <20080801000737.9FB861A78A3@beta.macosforge.org>	<799406d60807312105i52455880o16e0c088264b8504@mail.gmail.com>	<481FCC3C-060A-460D-9907-14CA8E24926B@macports.org>	<799406d60807312138j4b2ba462k5df088e47f00475f@mail.gmail.com>
	<A4482401-64AD-4525-8414-43DC4490BCE4@macports.org>
Message-ID: <4892B3B0.4090809@macports.org>

Landon Fuller wrote:
> OK, I implemented the fixes for issue #13699:
>     geos2 committed in r38824.
>     py25-matplotlib-basemap updated in r38825.
>     py-matplotlib-basemap updated in r38826.
>     geos updated to 3.0.0 in r38827.
>     matplotlib-basemap port revisions bumped in r38828 to ensure that 
> the ports are linked to geos2.

This won't work as expected on upgrade because of a base bug: 
<http://trac.macports.org/ticket/13054>

- Josh