From jeremyhu at macports.org  Wed Apr  1 00:15:35 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Wed, 1 Apr 2009 00:15:35 -0700
Subject: CA Certificates
Message-ID: <51023410-34C7-42DC-AF98-CDE2B754C977@macports.org>

Am I just not seeing a port that installs CA root certs?  I thought it  
might be a variant in openssl, but it's not there either... Am I  
missing something?



From blair at orcaware.com  Wed Apr  1 00:27:21 2009
From: blair at orcaware.com (Blair Zajac)
Date: Wed, 1 Apr 2009 00:27:21 -0700
Subject: CA Certificates
In-Reply-To: <51023410-34C7-42DC-AF98-CDE2B754C977@macports.org>
References: <51023410-34C7-42DC-AF98-CDE2B754C977@macports.org>
Message-ID: <151AEFAA-0B68-4FF8-9443-BA766040951B@orcaware.com>


On Apr 1, 2009, at 12:15 AM, Jeremy Huddleston wrote:

> Am I just not seeing a port that installs CA root certs?  I thought  
> it might be a variant in openssl, but it's not there either... Am I  
> missing something?


Maybe curl-ca-bundle?

Blair

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



From blb at macports.org  Wed Apr  1 00:27:18 2009
From: blb at macports.org (Bryan Blackburn)
Date: Wed, 1 Apr 2009 01:27:18 -0600
Subject: CA Certificates
In-Reply-To: <51023410-34C7-42DC-AF98-CDE2B754C977@macports.org>
References: <51023410-34C7-42DC-AF98-CDE2B754C977@macports.org>
Message-ID: <20090401072718.GA730@ninagal.withay.com>

On Wed, Apr 01, 2009 at 12:15:35AM -0700, Jeremy Huddleston said:
> Am I just not seeing a port that installs CA root certs?  I thought it  
> might be a variant in openssl, but it's not there either... Am I missing 
> something?

curl uses the curl-ca-bundle port, other than that if there are any root
certs they are probably just a part of some bigger port.

Bryan


From mcalhoun at macports.org  Wed Apr  1 14:28:23 2009
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Wed, 1 Apr 2009 21:28:23 +0000 (UTC)
Subject: Redundant p5- libraries
Message-ID: <loom.20090401T211959-685@post.gmane.org>

Now that the very useful change of reversing @INC has been made r48955,
will there be a rule of thumb for p5 dependencies already provided by perl5?

Option 1: Only have the dependency if the newer version is needed.
Option 2: If the package is needed, included it as a dependency even if the
                        base package is sufficient.
Option 3: No rule of thumb on this matter.

I would personally be in favor of Option 1 since it would lead to fewer surprises
for users.
As much as possible, the packages requested by the user is the one provided
by the base perl5.

-Marcus


From opendarwin.org at darkart.com  Wed Apr  1 14:39:29 2009
From: opendarwin.org at darkart.com (Eric Hall)
Date: Wed, 1 Apr 2009 21:39:29 +0000
Subject: Redundant p5- libraries
In-Reply-To: <loom.20090401T211959-685@post.gmane.org>
References: <loom.20090401T211959-685@post.gmane.org>
Message-ID: <20090401213929.GJ10906@darkart.com>

On Wed, Apr 01, 2009 at 09:28:23PM +0000, Marcus Calhoun-Lopez wrote:
> Now that the very useful change of reversing @INC has been made r48955,
> will there be a rule of thumb for p5 dependencies already provided by perl5?
> 
> Option 1: Only have the dependency if the newer version is needed.
> Option 2: If the package is needed, included it as a dependency even if the
>                         base package is sufficient.
> Option 3: No rule of thumb on this matter.
> 
> I would personally be in favor of Option 1 since it would lead to fewer surprises
> for users.
> As much as possible, the packages requested by the user is the one provided
> by the base perl5.

	I also like Option 1, keeps things (generally) simpler.  


		-eric



From raimue at macports.org  Wed Apr  1 14:44:49 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Wed, 01 Apr 2009 23:44:49 +0200
Subject: [MacPorts] #19110: gdb: Malformed receipt
In-Reply-To: <064.b7367ec4854610ff0c5e9bb739c97a9e@macports.org>
References: <055.3adae7648082ed20f397331ad26fe599@macports.org>
	<064.b7367ec4854610ff0c5e9bb739c97a9e@macports.org>
Message-ID: <49D3E051.4000500@macports.org>

As this is a totally different issue now from what was initially in the
ticket, I am going to move the discussion to the list.

On 2009-04-01 23:32, MacPorts wrote:
> #19110: gdb: Malformed receipt
> -----------------------------------+----------------------------------------
>  Reporter:  dweber@?               |       Owner:  dweber@?           
>      Type:  defect                 |      Status:  assigned           
>  Priority:  Normal                 |   Milestone:  Port Bugs          
> Component:  ports                  |     Version:  1.7.0              
>  Keywords:  gdb ports-filesystems  |        Port:  gdb                
> -----------------------------------+----------------------------------------
> 
> Comment(by dweber@?):
> 
>  I removed all the \n and \t characters from the long_description.  The
>  port still fails to install, ie:
>  {{{
>  --->  Fetching gdb
>  --->  Attempting to fetch gdb-6.8.tar.bz2 from
>  http://mirrors.kernel.org/gnu/gdb
>  --->  Verifying checksum(s) for gdb
>  --->  Extracting gdb
>  --->  Configuring gdb
>  --->  Building gdb
>  --->  Staging gdb into destroot
>  Warning: violation by /opt/local/info
>  Warning: gdb 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!

Tell the port not to use ${prefix}/info, but ${prefix}/share/info.
Usually with a configure flag --infodir=${prefix}/share/info.

>  --->  Installing gdb @6.8_0
>  --->  Activating gdb @6.8_0
>  Error: Target org.macports.activate returned: Image error:
>  /opt/local/lib/libiberty.a is being used by the active binutils port.
>  Please deactivate this port first, or use 'port -f activate gdb' to force
>  the activation.
>  Error: Status 1 encountered during processing.

The error message is pretty clear what happens. Both binutils and gdb
want to install the same file.

Also, you would probably have to re-create some of the patches available
from Apple at [1] for this gdb version to get it fully functional.

Rainer

[1] http://www.opensource.apple.com/darwinsource/10.5.6/gdb-768/
(requires Apple ID)

From anand at buddhdev.name  Wed Apr  1 15:28:31 2009
From: anand at buddhdev.name (Anand Buddhdev)
Date: Thu, 2 Apr 2009 00:28:31 +0200
Subject: Including spaces in adduser command
Message-ID: <557f33430904011528n2da7992fpea2d107939ffced@mail.gmail.com>

I'm busy testing a Portfile in which I have to use the adduser command
to add a user account to the system. My recipe looks like this:

post-destroot {
  addgroup nsd
  adduser nsd gid=nsd shell=/sbin/nologin home=${prefix}/var/db/nsd
realname=NSD User
}

However, when the account is created on the system, its real name is
set to just "NSD". So I tried putting quotes around "NSD User", but
then the real name is set to "NSD. That's right, a single quote,
followed by the words NSD. I also tried it with a backslash before the
space, NSD\ User, but then I get the backspace in the real name.

How can I get adduser to create the account with the string "NSD User"
as the real name? Am I missing something obvious? I'm using Macports
1.710.

Regards,

Anand

From febeling at macports.org  Wed Apr  1 15:31:11 2009
From: febeling at macports.org (C. Florian Ebeling)
Date: Thu, 2 Apr 2009 00:31:11 +0200
Subject: Redundant p5- libraries
In-Reply-To: <20090401213929.GJ10906@darkart.com>
References: <loom.20090401T211959-685@post.gmane.org>
	<20090401213929.GJ10906@darkart.com>
Message-ID: <5cbbe4ae0904011531w340e0c8dm3531b24dcb767aa3@mail.gmail.com>

On Wed, Apr 1, 2009 at 11:39 PM, Eric Hall <opendarwin.org at darkart.com> wrote:
> On Wed, Apr 01, 2009 at 09:28:23PM +0000, Marcus Calhoun-Lopez wrote:
>> Now that the very useful change of reversing @INC has been made r48955,
>> will there be a rule of thumb for p5 dependencies already provided by perl5?
>>
>> Option 1: Only have the dependency if the newer version is needed.
>> Option 2: If the package is needed, included it as a dependency even if the
>> ? ? ? ? ? ? ? ? ? ? ? ? base package is sufficient.
>> Option 3: No rule of thumb on this matter.

Option 1. It's a no-brainer. Any avoidable dependency has to be avoided.

But this change is no small thing. It has been lingering as long as I
use macports. Thanks to everyone who helped sort this out! This makes
macports much better, because everything needs Perl.


>>
>> I would personally be in favor of Option 1 since it would lead to fewer surprises
>> for users.
>> As much as possible, the packages requested by the user is the one provided
>> by the base perl5.
>
> ? ? ? ?I also like Option 1, keeps things (generally) simpler.
>
>
> ? ? ? ? ? ? ? ?-eric
>
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>



-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com

From jeremy at lavergne.gotdns.org  Wed Apr  1 15:35:59 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Wed, 1 Apr 2009 18:35:59 -0400
Subject: Including spaces in adduser command
In-Reply-To: <557f33430904011528n2da7992fpea2d107939ffced@mail.gmail.com>
References: <557f33430904011528n2da7992fpea2d107939ffced@mail.gmail.com>
Message-ID: <F4892770-8B63-4C6F-8181-CE425FEA86FB@lavergne.gotdns.org>

> I'm busy testing a Portfile in which I have to use the adduser command
> to add a user account to the system. My recipe looks like this:
>
> post-destroot {
>  addgroup nsd
>  adduser nsd gid=nsd shell=/sbin/nologin home=${prefix}/var/db/nsd
> realname=NSD User
> }
>
> However, when the account is created on the system, its real name is
> set to just "NSD". So I tried putting quotes around "NSD User", but
> then the real name is set to "NSD. That's right, a single quote,
> followed by the words NSD. I also tried it with a backslash before the
> space, NSD\ User, but then I get the backspace in the real name.
>
> How can I get adduser to create the account with the string "NSD User"
> as the real name? Am I missing something obvious? I'm using Macports
> 1.710.

If it works like I suspect, you might try using {NSD User}.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2435 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090401/21f21300/attachment.bin>

From raimue at macports.org  Wed Apr  1 15:43:27 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 02 Apr 2009 00:43:27 +0200
Subject: Including spaces in adduser command
In-Reply-To: <F4892770-8B63-4C6F-8181-CE425FEA86FB@lavergne.gotdns.org>
References: <557f33430904011528n2da7992fpea2d107939ffced@mail.gmail.com>
	<F4892770-8B63-4C6F-8181-CE425FEA86FB@lavergne.gotdns.org>
Message-ID: <49D3EE0F.6090909@macports.org>

On 2009-04-02 00:35, Jeremy Lavergne wrote:
>> How can I get adduser to create the account with the string "NSD User"
>> as the real name? Am I missing something obvious? I'm using Macports
>> 1.710.
> 
> If it works like I suspect, you might try using {NSD User}.

Close :-)

You should use:
  adduser ... {realname=NSD User}

Rainer

From anand at buddhdev.name  Wed Apr  1 16:14:15 2009
From: anand at buddhdev.name (Anand Buddhdev)
Date: Thu, 2 Apr 2009 01:14:15 +0200
Subject: Including spaces in adduser command
In-Reply-To: <49D3EE0F.6090909@macports.org>
References: <557f33430904011528n2da7992fpea2d107939ffced@mail.gmail.com>
	<F4892770-8B63-4C6F-8181-CE425FEA86FB@lavergne.gotdns.org>
	<49D3EE0F.6090909@macports.org>
Message-ID: <557f33430904011614o7dafac7cj1de0e097170fb29a@mail.gmail.com>

2009/4/2 Rainer M?ller <raimue at macports.org>:

Hi Jeremy, Rainer,

> On 2009-04-02 00:35, Jeremy Lavergne wrote:
>>> How can I get adduser to create the account with the string "NSD User"
>>> as the real name? Am I missing something obvious? I'm using Macports
>>> 1.710.
>>
>> If it works like I suspect, you might try using {NSD User}.

This didn't work. I got "{NSD" as the RealName.

> Close :-)
>
> You should use:
> ?adduser ... {realname=NSD User}

This kind of works. It results in:

$ sudo dscl . -read /Users/nsd
AppleMetaNodeLocation: /Local/Default
GeneratedUID: 4A501FD1-7BFC-4589-A81A-AB999CBB7B12
NFSHomeDirectory: /opt/local/var/db/nsd
Password: *
PrimaryGroupID: 500
RealName:
 NSD\ User
RecordName: nsd
RecordType: dsRecTypeStandard:Users
UniqueID: 500
UserShell: /sbin/nologin

There's a backslash in the RealName field. It does no harm, but it's
not what I intended, so it smells like a bug to me. Where do I report
this bug ?

From raimue at macports.org  Wed Apr  1 16:43:45 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 02 Apr 2009 01:43:45 +0200
Subject: Including spaces in adduser command
In-Reply-To: <557f33430904011614o7dafac7cj1de0e097170fb29a@mail.gmail.com>
References: <557f33430904011528n2da7992fpea2d107939ffced@mail.gmail.com>	
	<F4892770-8B63-4C6F-8181-CE425FEA86FB@lavergne.gotdns.org>	
	<49D3EE0F.6090909@macports.org>
	<557f33430904011614o7dafac7cj1de0e097170fb29a@mail.gmail.com>
Message-ID: <49D3FC31.6000301@macports.org>

On 2009-04-02 01:14, Anand Buddhdev wrote:
> There's a backslash in the RealName field. It does no harm, but it's
> not what I intended, so it smells like a bug to me. Where do I report
> this bug ?

You already did :-)

Spaces were explicitly converted, seems to be an old leftover as for as
I see in the history.

Fixed in r49013 [1] and merged back to release_1_7 in r49014 [2].

Rainer

[1] http://trac.macports.org/changeset/49013
[2] http://trac.macports.org/changeset/49014

From ryandesign at macports.org  Wed Apr  1 18:02:04 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 1 Apr 2009 20:02:04 -0500
Subject: Openssl: built-in or ports?
In-Reply-To: <00183FE5-D221-4D64-8A62-3C0FE832B109@macports.org>
References: <557f33430903310658l34de2dc1l27af2d4d70dccf4b@mail.gmail.com>
	<2DBE9E31-07B5-44BE-B8E8-EB29F3D98387@lavergne.gotdns.org>
	<00183FE5-D221-4D64-8A62-3C0FE832B109@macports.org>
Message-ID: <FD99E2C5-12FB-4430-8B41-46E18AB9747C@macports.org>

On Mar 31, 2009, at 09:09, Anders F Bj?rklund wrote:

> Using the MacPorts version of OpenSSL has a licensing problem with
> GPL ports, though... When distributing package binaries, that is.

Oh. Good. Grief.

So when we get going on binaries, we're going to have to provide  
portfile syntax to indicate whether we may distribute binaries of the  
built thing?

Sheesh.


> Like http://www.finkproject.org/doc/packaging/policy.php? 
> phpLang=en#openssl

That says use of OpenSSL with GPL-licensed software is questionable.  
It says Fink won't distribute such binaries, and implies users  
building from source are no better off, legally. To me, this says  
that if there is a problem for MacPorts to distribute binaries  
including OpenSSL support, then the problem exists for all users of  
MacPorts using these ports, regardless of whether it was provided as  
a binary or compiled by the user.


> http://www.openssl.org/support/faq.html#LEGAL2 (using system  
> openssl is ok)


That doesn't seem to prohibit the use of OpenSSL for us. It says  
nothing about binaries. It says "the GPL does not place restrictions  
on using libraries that are part of the normal operating system  
distribution". OpenSSL is part of the normal Mac OS X distribution.  
It says "Some GPL software copyright holders claim that you infringe  
on their rights if you use OpenSSL with their software on operating  
systems that don't normally include OpenSSL." Mac OS X does normally  
include OpenSSL, so I don't see any problem here. But, I'm not a lawyer.


The situation might be different for people who use MacPorts on other  
operating systems that don't come with OpenSSL. Not sure what that OS  
would be. But  I have no plans to provide binaries for anything other  
than Mac OS X.


From ryandesign at macports.org  Wed Apr  1 18:04:45 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 1 Apr 2009 20:04:45 -0500
Subject: CA Certificates
In-Reply-To: <20090401072718.GA730@ninagal.withay.com>
References: <51023410-34C7-42DC-AF98-CDE2B754C977@macports.org>
	<20090401072718.GA730@ninagal.withay.com>
Message-ID: <05868815-CDD0-4419-989A-A1454D81E37B@macports.org>


On Apr 1, 2009, at 02:27, Bryan Blackburn wrote:

> On Wed, Apr 01, 2009 at 12:15:35AM -0700, Jeremy Huddleston said:
>
>> Am I just not seeing a port that installs CA root certs?  I  
>> thought it
>> might be a variant in openssl, but it's not there either... Am I  
>> missing
>> something?
>
> curl uses the curl-ca-bundle port, other than that if there are any  
> root
> certs they are probably just a part of some bigger port.


That's what I'd guess. The curl software used to bundle the CA certs,  
until they recently decided not to do so anymore, necessitating the  
creation of the curl-ca-bundle port. So, check with whatever software  
you're wanting to use that needs CA certs.




From ryandesign at macports.org  Wed Apr  1 18:05:57 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 1 Apr 2009 20:05:57 -0500
Subject: Cleaning up during uninstall and submitting Portfile
In-Reply-To: <557f33430903310900s621c2476g3d23b7b6d85b60c8@mail.gmail.com>
References: <557f33430903310900s621c2476g3d23b7b6d85b60c8@mail.gmail.com>
Message-ID: <DAAE2CE8-EFBE-4BCC-8BAF-6CC0E1007501@macports.org>

On Mar 31, 2009, at 11:00, Anand Buddhdev wrote:

> Thanks for your help with advice on which openssl to use. So I've
> created a Portfile for NSD 3.2.1, placed it in a local ports
> repository, and used it to install the package on my system. The
> package builds, installs and runs just fine.
>
> So when I uninstalled the package, all the installed files were
> removed. However, the install process created 2 directories in the
> pre-destroot phase using "xinstall". These 2 directories are not
> removed during the uninstall phase. Is there any kind of
> post-uninstall hook to do this kind of cleanup? It would also be
> useful to remove users and groups created during package installation.

You need to create the directories inside the destroot so they're  
registered to the port.

Instead of:

xinstall -d ${prefix}/somewhere

do:

xinstall -d ${destroot}${prefix}/somewhere

MacPorts will remove empty directories automatically after destroot.  
If you want them kept, add them to destroot.keepdirs.


> Finally, I'm happy with my Portfile, so I'd like to submit it into
> Macports. How do I do that? Do I need an account on a server
> somewhere?

File a ticket in the issue tracker and attach your portfile.



From jkh at apple.com  Wed Apr  1 18:53:55 2009
From: jkh at apple.com (Jordan K. Hubbard)
Date: Wed, 1 Apr 2009 18:53:55 -0700
Subject: Openssl: built-in or ports?
In-Reply-To: <FD99E2C5-12FB-4430-8B41-46E18AB9747C@macports.org>
References: <557f33430903310658l34de2dc1l27af2d4d70dccf4b@mail.gmail.com>
	<2DBE9E31-07B5-44BE-B8E8-EB29F3D98387@lavergne.gotdns.org>
	<00183FE5-D221-4D64-8A62-3C0FE832B109@macports.org>
	<FD99E2C5-12FB-4430-8B41-46E18AB9747C@macports.org>
Message-ID: <3B3F3D95-CF5D-4B2E-ACF0-BB6A1D8E156B@apple.com>


On Apr 1, 2009, at 6:02 PM, Ryan Schmidt wrote:

> So when we get going on binaries, we're going to have to provide  
> portfile syntax to indicate whether we may distribute binaries of  
> the built thing?

FreeBSD has been doing this for over a decade.   There is quite a bit  
of useful legal/security metadata about ports that MacPorts hasn't  
gotten big enough to worry about yet, in fact, but that won't hold  
true forever.  Binary packages are just the tip of the iceberg.

- Jordan


From raimue at macports.org  Wed Apr  1 19:02:00 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 02 Apr 2009 04:02:00 +0200
Subject: Openssl: built-in or ports?
In-Reply-To: <FD99E2C5-12FB-4430-8B41-46E18AB9747C@macports.org>
References: <557f33430903310658l34de2dc1l27af2d4d70dccf4b@mail.gmail.com>	<2DBE9E31-07B5-44BE-B8E8-EB29F3D98387@lavergne.gotdns.org>	<00183FE5-D221-4D64-8A62-3C0FE832B109@macports.org>
	<FD99E2C5-12FB-4430-8B41-46E18AB9747C@macports.org>
Message-ID: <49D41C98.20404@macports.org>

On 2009-04-02 03:02, Ryan Schmidt wrote:
> On Mar 31, 2009, at 09:09, Anders F Bj?rklund wrote:
> 
>> Using the MacPorts version of OpenSSL has a licensing problem with
>> GPL ports, though... When distributing package binaries, that is.
> 
> Oh. Good. Grief.
> 
> So when we get going on binaries, we're going to have to provide  
> portfile syntax to indicate whether we may distribute binaries of the  
> built thing?

Having license information would be nice anyway in my opinion,
regardless if it will be used for building binaries.

It sounds easy to just add a new license field to the Portfile syntax.
But the hard part will be to fill it with actual values.

Maybe we could script something which asks freshmeat/sourceforge/ohloh
for license information or scan for LICENSE in the work dir. But of
course it would still require manual acknowledgment, I would not
entirely rely on a script here.

>> Like http://www.finkproject.org/doc/packaging/policy.php? 
>> phpLang=en#openssl
> 
> That says use of OpenSSL with GPL-licensed software is questionable.  
> It says Fink won't distribute such binaries, and implies users  
> building from source are no better off, legally. To me, this says  
> that if there is a problem for MacPorts to distribute binaries  
> including OpenSSL support, then the problem exists for all users of  
> MacPorts using these ports, regardless of whether it was provided as  
> a binary or compiled by the user.

In my opinion this is not a problem as long as you build from source.
GPL only covers "terms and conditions for copying, distribution and
modification".

>> http://www.openssl.org/support/faq.html#LEGAL2 (using system  
>> openssl is ok)
> 
> 
> That doesn't seem to prohibit the use of OpenSSL for us. It says  
> nothing about binaries. It says "the GPL does not place restrictions  
> on using libraries that are part of the normal operating system  
> distribution". OpenSSL is part of the normal Mac OS X distribution.

Hmmmm, but it is not the OpenSSL installation of the system we use. So
those are actually not part of the OS distribution.

> It says "Some GPL software copyright holders claim that you infringe  
> on their rights if you use OpenSSL with their software on operating  
> systems that don't normally include OpenSSL." Mac OS X does normally  
> include OpenSSL, so I don't see any problem here. But, I'm not a lawyer.

I never met any programmer claiming to be a lawyer :-D
But you might have a valid point here...

Rainer

From jmr at macports.org  Wed Apr  1 19:20:25 2009
From: jmr at macports.org (Joshua Root)
Date: Thu, 02 Apr 2009 13:20:25 +1100
Subject: Openssl: built-in or ports?
In-Reply-To: <FD99E2C5-12FB-4430-8B41-46E18AB9747C@macports.org>
References: <557f33430903310658l34de2dc1l27af2d4d70dccf4b@mail.gmail.com>	<2DBE9E31-07B5-44BE-B8E8-EB29F3D98387@lavergne.gotdns.org>	<00183FE5-D221-4D64-8A62-3C0FE832B109@macports.org>
	<FD99E2C5-12FB-4430-8B41-46E18AB9747C@macports.org>
Message-ID: <49D420E9.2030206@macports.org>

Ryan Schmidt wrote:
> On Mar 31, 2009, at 09:09, Anders F Bj?rklund wrote:
> 
>> Using the MacPorts version of OpenSSL has a licensing problem with
>> GPL ports, though... When distributing package binaries, that is.
> 
> Oh. Good. Grief.
> 
> So when we get going on binaries, we're going to have to provide
> portfile syntax to indicate whether we may distribute binaries of the
> built thing?
> 
> Sheesh.

Absolutely. And you wonder why we don't have binaries yet? ;-)

This is being tracked in <http://trac.macports.org/ticket/7493>.

>> Like
>> http://www.finkproject.org/doc/packaging/policy.php?phpLang=en#openssl
> 
> That says use of OpenSSL with GPL-licensed software is questionable. It
> says Fink won't distribute such binaries, and implies users building
> from source are no better off, legally. To me, this says that if there
> is a problem for MacPorts to distribute binaries including OpenSSL
> support, then the problem exists for all users of MacPorts using these
> ports, regardless of whether it was provided as a binary or compiled by
> the user.

Not at all. The licenses are copyright licenses, and hence can only
specify conditions for distribution. You don't need a license to build
or run software. You can build any license-incompatible mess you like,
you just won't be able to distribute it to anyone else.

>> http://www.openssl.org/support/faq.html#LEGAL2 (using system openssl
>> is ok)
> 
> 
> That doesn't seem to prohibit the use of OpenSSL for us. It says nothing
> about binaries. It says "the GPL does not place restrictions on using
> libraries that are part of the normal operating system distribution".
> OpenSSL is part of the normal Mac OS X distribution. It says "Some GPL
> software copyright holders claim that you infringe on their rights if
> you use OpenSSL with their software on operating systems that don't
> normally include OpenSSL." Mac OS X does normally include OpenSSL, so I
> don't see any problem here. But, I'm not a lawyer.
> 
> 
> The situation might be different for people who use MacPorts on other
> operating systems that don't come with OpenSSL. Not sure what that OS
> would be. But  I have no plans to provide binaries for anything other
> than Mac OS X.

The actual wording in GPLv2 is "However, as a special exception, the
source code distributed need not include anything that is normally
distributed (in either source or binary form) with the major components
(compiler, kernel, and so on) of the operating system on which the
executable runs, unless that component itself accompanies the executable."

Even that paragraph seems open to different interpretations. (Does
downloading an openssl binary as a dependency count as "accompanying the
executable"?) And then there's the question of whether that exception
also gets you out of the "no further restrictions" clause, since the
program presumably includes code from the openssl headers, which is
covered by the openssl license which has the extra requirement of an
acknowledgement.

In short, you do probably have to be a lawyer to have a hope of knowing.
(And the verdict would probably vary by jurisdiction and judicial
interpretation, sigh...)

- Josh

From blb at macports.org  Wed Apr  1 22:39:02 2009
From: blb at macports.org (Bryan Blackburn)
Date: Wed, 1 Apr 2009 23:39:02 -0600
Subject: Including spaces in adduser command
In-Reply-To: <49D3FC31.6000301@macports.org>
References: <557f33430904011528n2da7992fpea2d107939ffced@mail.gmail.com>
	<F4892770-8B63-4C6F-8181-CE425FEA86FB@lavergne.gotdns.org>
	<49D3EE0F.6090909@macports.org>
	<557f33430904011614o7dafac7cj1de0e097170fb29a@mail.gmail.com>
	<49D3FC31.6000301@macports.org>
Message-ID: <20090402053902.GC505@ninagal.withay.com>

On Thu, Apr 02, 2009 at 01:43:45AM +0200, Rainer M?ller said:
> On 2009-04-02 01:14, Anand Buddhdev wrote:
> > There's a backslash in the RealName field. It does no harm, but it's
> > not what I intended, so it smells like a bug to me. Where do I report
> > this bug ?
> 
> You already did :-)
> 
> Spaces were explicitly converted, seems to be an old leftover as for as
> I see in the history.
> 
> Fixed in r49013 [1] and merged back to release_1_7 in r49014 [2].

Does that mean we'll be having a 1.7.2 at some point?

Bryan


> 
> Rainer
> 
> [1] http://trac.macports.org/changeset/49013
> [2] http://trac.macports.org/changeset/49014

From ryandesign at macports.org  Wed Apr  1 23:28:50 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 2 Apr 2009 01:28:50 -0500
Subject: Question regarding Xcode version check
In-Reply-To: <ED905CBD-6C77-446D-B058-081D0470B42D@macports.org>
References: <ED905CBD-6C77-446D-B058-081D0470B42D@macports.org>
Message-ID: <4C59AACF-5BB6-498C-9F27-50A84A19FA42@macports.org>

On Apr 1, 2009, at 20:17, Juan Manuel Palacios wrote:

> 	Hey Ryan! Believe it or not, I'm still alive ;-)
>
> 	Today I was putting together a MAMP installation on a Mac at work,  
> with our beautiful MacPorts of course, and stumbled on a rather  
> annoying glitch, or what at least looks like one. The tiff port has  
> the standard check for the minimum Xcode version on Leopard, 3.1.2,  
> as introduced by you in r48210; but said check happens at pre- 
> extract time, which means port has already wasted time downloading  
> the distfile if the target Mac has Xcode < 3.1.2, which was my case  
> this time round. Is it possible to move the check up to pre-fetch?
>
> 	I'm not gonna commit that change just now, one 'cause the port is  
> not openmaintainer and, two, 'cause I don't know if pre-fetch was  
> explicitly avoided for a reason.
>
> 	Let me know, thanks! Regards,...

Hi Juan!

This was a deliberate decision, and I'm copying macports-dev on this  
answer since I never explained the rationale before, so let me do so  
now.

Some of my ports do checks and issue fatal error messages in the pre- 
fetch phase. I reserve this for ports which can never be installed on  
the given system at all. For example, if you try to install wine on a  
PowerPC Mac, or oracle-instantclient on an Intel Mac with Tiger or  
earlier. It can't be done. There is no way those ports will ever work  
on those systems, so there's no point allowing the user to download  
the distfile.

For other ports, like tiff, as you found, and any others where I've  
added the Xcode version check, and other ports like pango and cairo  
and pure which check the version of other installed ports, the check  
is in pre-extract, specifically so that the user can still fetch and  
verify the distfile. Most likely, the user wants to install the  
software, so after encountering the message that they need to upgrade  
their Xcode, they will seek out and download the new Xcode, and then  
be able to install the software. I did not want to put the check in  
the pre-fetch phase because that would prevent the user from doing  
something like "port fetch outdated" or "port fetch some long list of  
ports" which the user may want to do if they have a slow network  
connection and/or want to download these files unattended. The user  
might be annoyed to have left the machine alone for hours while they  
expect it to be downloading many ports, only to find when they come  
back that it has exited with an error after failing to download only  
a few files. Sure, the user won't be able to install this specific  
port without downloading the newer Xcode, but they can still install  
the others they fetched.

Anyway, not sure if these hypothetical uses actually occur, but that  
was why I decided to do it this way.



From afb at macports.org  Wed Apr  1 23:32:11 2009
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Thu, 2 Apr 2009 08:32:11 +0200
Subject: Openssl: built-in or ports?
In-Reply-To: <FD99E2C5-12FB-4430-8B41-46E18AB9747C@macports.org>
References: <557f33430903310658l34de2dc1l27af2d4d70dccf4b@mail.gmail.com>
	<2DBE9E31-07B5-44BE-B8E8-EB29F3D98387@lavergne.gotdns.org>
	<00183FE5-D221-4D64-8A62-3C0FE832B109@macports.org>
	<FD99E2C5-12FB-4430-8B41-46E18AB9747C@macports.org>
Message-ID: <39FBAEBB-69FB-40A6-BABF-92753E34C018@macports.org>

Ryan Schmidt wrote:

>> Using the MacPorts version of OpenSSL has a licensing problem with
>> GPL ports, though... When distributing package binaries, that is.
>
> Oh. Good. Grief.
>
> So when we get going on binaries, we're going to have to provide  
> portfile syntax to indicate whether we may distribute binaries of  
> the built thing?
>
> Sheesh.

It might even need two flags, one for the distfiles and one for the  
binaries...

Then again, the default should probably be "yes we can" and the  
others override.

> [...]
> It says "the GPL does not place restrictions on using libraries  
> that are part of the normal operating system distribution". OpenSSL  
> is part of the normal Mac OS X distribution. It says "Some GPL  
> software copyright holders claim that you infringe on their rights  
> if you use OpenSSL with their software on operating systems that  
> don't normally include OpenSSL." Mac OS X does normally include  
> OpenSSL, so I don't see any problem here. But, I'm not a lawyer.
>
>
> The situation might be different for people who use MacPorts on  
> other operating systems that don't come with OpenSSL. Not sure what  
> that OS would be. But  I have no plans to provide binaries for  
> anything other than Mac OS X.

I do think that part applies when you actually link with the system  
version...

The annoying part is when the system openssl lack new features, such  
as SHA256.

--anders


From ryandesign at macports.org  Thu Apr  2 00:12:16 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 2 Apr 2009 02:12:16 -0500
Subject: [48220] trunk/dports/x11
In-Reply-To: <20090317025323.8D4D5122F2C6@beta.macosforge.org>
References: <20090317025323.8D4D5122F2C6@beta.macosforge.org>
Message-ID: <22D20BB2-F8E0-44C0-A923-8D7E8571FA88@macports.org>

On Mar 16, 2009, at 21:53, jeremyhu at macports.org wrote:

> Revision: 48220
>           http://trac.macports.org/changeset/48220
> Author:   jeremyhu at macports.org
> Date:     2009-03-16 19:53:23 -0700 (Mon, 16 Mar 2009)
> Log Message:
> -----------
> quartz-wm: New port
>
> Added Paths:
> -----------
>     trunk/dports/x11/quartz-wm/
>     trunk/dports/x11/quartz-wm/Portfile
>
> Added: trunk/dports/x11/quartz-wm/Portfile
> ===================================================================
> --- trunk/dports/x11/quartz-wm/Portfile	                         
> (rev 0)
> +++ trunk/dports/x11/quartz-wm/Portfile	2009-03-17 02:53:23 UTC  
> (rev 48220)
> @@ -0,0 +1,48 @@
> +# $Id: Portfile 46927 2009-02-17 23:02:35Z jeremyhu at macports.org $
> +
> +PortSystem 1.0
> +
> +name		quartz-wm
> +version		1.0.1
> +categories	x11
> +maintainers	jeremyhu openmaintainer
> +description     Apple's Window Manager for X11
> +homepage	http://xquartz.macosforge.org
> +platforms	macosx
> +long_description quartz-wm is Apple's closed source window-manager.
> +master_sites	${homepage}/downloads
> +
> +distfiles	quartz-wm-${version}-Tiger.bz2 quartz-wm-${version}- 
> Leopard.bz2

You should modify this to only download the Tiger or Leopard  
distfile, depending on whether the user is running Tiger or Leopard.  
No point making everyone download both files.

> +checksums           quartz-wm-1.0.1-Tiger.bz2 \
> +                    md5     2d1569514b280a36e54711f9f555f069 \
> +                    sha1     
> b5001813509089328e524ac6ce4470187b5e76c3 \
> +                    rmd160   
> 8e4652cd372d112f6f77126b68b35275dbae4c7a \
> +                    quartz-wm-1.0.1-Leopard.bz2 \
> +                    md5     91936d4f209bd68d8bddf7e761d62fcc \
> +                    sha1     
> b7ee7b307dc211af0a799030a809d5390e0a3331 \
> +                    rmd160  46c459115631460f8885a681d5248d693d4c774a
> +
> +use_bzip2	yes
> +
> +depends_lib     port:xorg-libXinerama \
> +                port:xorg-libAppleWM
> +
> +use_configure no
> +extract         {
> +	system "mkdir -p ${worksrcpath}"

You could use

xinstall -d ${worksrcpath}

or I believe

extract.mkdir yes


> +	file copy ${distpath}/quartz-wm-${version}-Tiger.bz2 ${worksrcpath}
> +	file copy ${distpath}/quartz-wm-${version}-Leopard.bz2 $ 
> {worksrcpath}
> +	system "cd ${worksrcpath} && bunzip2 quartz-wm-${version}- 
> Tiger.bz2 && bunzip2 quartz-wm-${version}-Leopard.bz2"
> +}
> +
> +build           { }
> +
> +destroot        {
> +	xinstall -d -m 755 ${destroot}${prefix}/bin
> +	if {[rpm-vercomp ${os.version} 9] < 0} {
> +		xinstall -m 755 ${worksrcpath}/quartz-wm-${version}-Tiger $ 
> {destroot}${prefix}/bin/quartz-wm
> +	} else {
> +		xinstall -m 755 ${worksrcpath}/quartz-wm-${version}-Leopard $ 
> {destroot}${prefix}/bin/quartz-wm
> +	}
> +}

Will the "Tiger" version work on Panther?
Will the "Leopard" version work on Snow Leopard?
If so, then the naming is confusing...
If not, then "platform darwin 8" and "platform darwin 9" blocks would  
be more appropriate, and you may want to add a pre-fetch block  
bailing out if the OS version won't work.


From ryandesign at macports.org  Thu Apr  2 00:13:59 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 2 Apr 2009 02:13:59 -0500
Subject: [49020] trunk/dports/devel/gdb/Portfile
In-Reply-To: <20090402005641.8D56913DCF96@beta.macosforge.org>
References: <20090402005641.8D56913DCF96@beta.macosforge.org>
Message-ID: <F3779C2B-894D-4C4E-A9AA-2778F01DA510@macports.org>


On Apr 1, 2009, at 19:56, dweber at macports.org wrote:

> Revision: 49020
>           http://trac.macports.org/changeset/49020
> Author:   dweber at macports.org
> Date:     2009-04-01 17:56:40 -0700 (Wed, 01 Apr 2009)
> Log Message:
> -----------
> -m "tweaks to the configure installation paths"

And you added a dependency on expat, and you added --enable-objc-gc  
to configure.args, so probably you need to bump the revision so  
everyone gets these changes (I assume this changes at least some  
files the port installs).


> Modified Paths:
> --------------
>     trunk/dports/devel/gdb/Portfile
>
> Modified: trunk/dports/devel/gdb/Portfile
> ===================================================================
> --- trunk/dports/devel/gdb/Portfile	2009-04-02 00:53:41 UTC (rev  
> 49019)
> +++ trunk/dports/devel/gdb/Portfile	2009-04-02 00:56:40 UTC (rev  
> 49020)
> @@ -11,18 +11,18 @@
>  description     GDB: The GNU Project Debugger
>
>  long_description \
> -GDB, the GNU Project debugger, allows you to see what is going on  
> `inside'\
> -another program while it executes -- or what another program was  
> doing at the\
> -moment it crashed.  GDB can do four main kinds of things (plus  
> other things\
> -in support of these) to help you catch bugs in the act:\
> -    * Start your program, specifying anything that might affect  
> its behavior.\
> -    * Make your program stop on specified conditions.\
> -    * Examine what has happened, when your program has stopped.\
> -    * Change things in your program, so you can experiment with  
> correcting\
> -     the effects of one bug and go on to learn about another.\
> -The program being debugged can be written in Ada, C, C++,  
> Objective-C,\
> -Pascal (and many other languages). Those programs might be  
> executing on\
> -the same machine as GDB (native) or on another machine (remote). GDB\
> +GDB, the GNU Project debugger, allows you to see what is going on  
> 'inside' \
> +another program while it executes -- or what another program was  
> doing at the \
> +moment it crashed.  GDB can do four main kinds of things (plus  
> other things \
> +in support of these) to help you catch bugs in the act: \
> +    a) start your program, specifying anything that might affect  
> its behavior, \
> +    b) make your program stop on specified conditions, \
> +    c) examine what has happened, when your program has stopped, \
> +    d) change things in your program, so you can experiment with  
> correcting \
> +       the effects of one bug and go on to learn about another. \
> +The program being debugged can be written in Ada, C, C++,  
> Objective-C, \
> +Pascal (and many other languages). Those programs might be  
> executing on \
> +the same machine as GDB (native) or on another machine (remote).  
> GDB \
>  can run on most popular UNIX and Microsoft Windows variants.
>
>  homepage        http://www.gnu.org/software/gdb/
> @@ -39,3 +39,13 @@
>                  sha1 ba1394d59dd84a1dd3a83322bd82c799596f0bcf \
>                  rmd160 23fc9442290b6383ce8f943ef1eb117fa06e79fb
>
> +depends_build   \
> +                port:expat
> +                #port:gcc42
> +
> +configure.args-append \
> +    --infodir=${prefix}/share/info \
> +    --mandir=${prefix}/share/man \
> +    --with-docdir=${prefix}/share/doc \
> +    --enable-objc-gc



From ryandesign at macports.org  Thu Apr  2 01:34:45 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 2 Apr 2009 03:34:45 -0500
Subject: [48945] trunk/dports/lang/spidermonkey/Portfile
In-Reply-To: <20090331170601.2F649135D4C9@beta.macosforge.org>
References: <20090331170601.2F649135D4C9@beta.macosforge.org>
Message-ID: <AACCB349-035B-463C-80E0-4E4BE8F3E95D@macports.org>


On Mar 31, 2009, at 12:06, macsforever2000 at macports.org wrote:

> Revision: 48945
>           http://trac.macports.org/changeset/48945
> Author:   macsforever2000 at macports.org
> Date:     2009-03-31 10:06:00 -0700 (Tue, 31 Mar 2009)
> Log Message:
> -----------
> Added UTF-8 support. (#18895)
>
> Modified Paths:
> --------------
>     trunk/dports/lang/spidermonkey/Portfile
>
> Modified: trunk/dports/lang/spidermonkey/Portfile
> ===================================================================
> --- trunk/dports/lang/spidermonkey/Portfile	2009-03-31 17:03:48 UTC  
> (rev 48944)
> +++ trunk/dports/lang/spidermonkey/Portfile	2009-03-31 17:06:00 UTC  
> (rev 48945)
> @@ -5,8 +5,7 @@
>
>  name                spidermonkey
>  version             1.7.0
> -revision            1
> -epoch               1
> +revision            2
>  categories          lang
>  platforms           darwin
>  maintainers         akitada openmaintainer

Once epoch has been added to a port, you can never remove it or  
decrease it. I added it back in in r49041.



From ryandesign at macports.org  Thu Apr  2 02:25:27 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 2 Apr 2009 04:25:27 -0500
Subject: Including spaces in adduser command
In-Reply-To: <20090402053902.GC505@ninagal.withay.com>
References: <557f33430904011528n2da7992fpea2d107939ffced@mail.gmail.com>
	<F4892770-8B63-4C6F-8181-CE425FEA86FB@lavergne.gotdns.org>
	<49D3EE0F.6090909@macports.org>
	<557f33430904011614o7dafac7cj1de0e097170fb29a@mail.gmail.com>
	<49D3FC31.6000301@macports.org>
	<20090402053902.GC505@ninagal.withay.com>
Message-ID: <5B4A38BD-E8E8-4881-AB24-198A14FF41A1@macports.org>


On Apr 2, 2009, at 00:39, Bryan Blackburn wrote:

> On Thu, Apr 02, 2009 at 01:43:45AM +0200, Rainer M?ller said:
>
>> Fixed in r49013 [1] and merged back to release_1_7 in r49014 [2].
>
> Does that mean we'll be having a 1.7.2 at some point?

By all means! :) Maybe not just yet, since we just had 1.7.1.


From ryandesign at macports.org  Thu Apr  2 02:26:26 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 2 Apr 2009 04:26:26 -0500
Subject: [49005] trunk/dports/PortIndex.quick
In-Reply-To: <20090401193602.7292B13C9400@beta.macosforge.org>
References: <20090401193602.7292B13C9400@beta.macosforge.org>
Message-ID: <69F44E5C-9ECF-43CC-912C-A5B31BF54E9B@macports.org>


On Apr 1, 2009, at 14:36, wsiegrist at apple.com wrote:

> Revision: 49005
>           http://trac.macports.org/changeset/49005
> Author:   wsiegrist at apple.com
> Date:     2009-04-01 12:36:01 -0700 (Wed, 01 Apr 2009)
> Log Message:
> -----------
> Mark the PortIndex.quick as binary to avoid the large diffs

What *is* PortIndex.quick?



From anand at buddhdev.name  Thu Apr  2 02:51:20 2009
From: anand at buddhdev.name (Anand Buddhdev)
Date: Thu, 2 Apr 2009 11:51:20 +0200
Subject: Cleaning up during uninstall and submitting Portfile
In-Reply-To: <DAAE2CE8-EFBE-4BCC-8BAF-6CC0E1007501@macports.org>
References: <557f33430903310900s621c2476g3d23b7b6d85b60c8@mail.gmail.com>
	<DAAE2CE8-EFBE-4BCC-8BAF-6CC0E1007501@macports.org>
Message-ID: <557f33430904020251k559ee9a9wa2d24a7aec6f08cc@mail.gmail.com>

2009/4/2 Ryan Schmidt <ryandesign at macports.org>

Hi Ryan,

 Thanks for your help with advice on which openssl to use. So I've
>> created a Portfile for NSD 3.2.1, placed it in a local ports
>> repository, and used it to install the package on my system. The
>> package builds, installs and runs just fine.
>>
>> So when I uninstalled the package, all the installed files were
>> removed. However, the install process created 2 directories in the
>> pre-destroot phase using "xinstall". These 2 directories are not
>> removed during the uninstall phase. Is there any kind of
>> post-uninstall hook to do this kind of cleanup? It would also be
>> useful to remove users and groups created during package installation.
>>
>
> You need to create the directories inside the destroot so they're
> registered to the port.
>
> Instead of:
>
> xinstall -d ${prefix}/somewhere
>
> do:
>
> xinstall -d ${destroot}${prefix}/somewhere


Actually, this is what I'm already doing. However, at run-time, the package
creates files in these directories, so Macports doesn't remove them. That's
why I was asking about something like a post-uninstall hook, which can
remove these (possibly) nonempty directories, and remove the user account
created during package installation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090402/32990328/attachment-0001.html>

From ryandesign at macports.org  Thu Apr  2 03:11:14 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 2 Apr 2009 05:11:14 -0500
Subject: Cleaning up during uninstall and submitting Portfile
In-Reply-To: <557f33430904020251k559ee9a9wa2d24a7aec6f08cc@mail.gmail.com>
References: <557f33430903310900s621c2476g3d23b7b6d85b60c8@mail.gmail.com>
	<DAAE2CE8-EFBE-4BCC-8BAF-6CC0E1007501@macports.org>
	<557f33430904020251k559ee9a9wa2d24a7aec6f08cc@mail.gmail.com>
Message-ID: <70B865FD-78AF-425E-831A-C2759413B7E7@macports.org>

On Apr 2, 2009, at 04:51, Anand Buddhdev wrote:

>> You need to create the directories inside the destroot so they're  
>> registered to the port.
>>
>> Instead of:
>>
>> xinstall -d ${prefix}/somewhere
>>
>> do:
>>
>> xinstall -d ${destroot}${prefix}/somewhere
>
>
> Actually, this is what I'm already doing. However, at run-time, the  
> package creates files in these directories, so Macports doesn't  
> remove them. That's why I was asking about something like a post- 
> uninstall hook, which can remove these (possibly) nonempty  
> directories, and remove the user account created during package  
> installation.

Oh yes, understood. But sorry, no, there is no post-uninstall hook.  
There are several ports where this would be useful, but nobody has  
written it yet.



From ryandesign at macports.org  Thu Apr  2 03:54:47 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 2 Apr 2009 05:54:47 -0500
Subject: Openssl: built-in or ports?
In-Reply-To: <39FBAEBB-69FB-40A6-BABF-92753E34C018@macports.org>
References: <557f33430903310658l34de2dc1l27af2d4d70dccf4b@mail.gmail.com>
	<2DBE9E31-07B5-44BE-B8E8-EB29F3D98387@lavergne.gotdns.org>
	<00183FE5-D221-4D64-8A62-3C0FE832B109@macports.org>
	<FD99E2C5-12FB-4430-8B41-46E18AB9747C@macports.org>
	<39FBAEBB-69FB-40A6-BABF-92753E34C018@macports.org>
Message-ID: <EBABEE94-7780-4CB3-A06F-86D8413FCD6C@macports.org>

On Apr 2, 2009, at 01:32, Anders F Bj?rklund wrote:

>> So when we get going on binaries, we're going to have to provide  
>> portfile syntax to indicate whether we may distribute binaries of  
>> the built thing?
>>
>> Sheesh.
>
> It might even need two flags, one for the distfiles and one for the  
> binaries...

Absolutely. We already need a flag for whether distfiles may be  
distributed. William is currently maintaining that list manually in  
his mirror script, which isn't optimal. Anyone have a suggestion for  
what such a flag could be called?


From ryandesign at macports.org  Thu Apr  2 03:56:52 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 2 Apr 2009 05:56:52 -0500
Subject: Openssl: built-in or ports?
In-Reply-To: <49D41C98.20404@macports.org>
References: <557f33430903310658l34de2dc1l27af2d4d70dccf4b@mail.gmail.com>	<2DBE9E31-07B5-44BE-B8E8-EB29F3D98387@lavergne.gotdns.org>	<00183FE5-D221-4D64-8A62-3C0FE832B109@macports.org>
	<FD99E2C5-12FB-4430-8B41-46E18AB9747C@macports.org>
	<49D41C98.20404@macports.org>
Message-ID: <B996D2E1-A468-469D-BC96-A50487FB8E61@macports.org>


On Apr 1, 2009, at 21:02, Rainer M?ller wrote:

> Having license information would be nice anyway in my opinion,
> regardless if it will be used for building binaries.
>
> It sounds easy to just add a new license field to the Portfile syntax.
> But the hard part will be to fill it with actual values.
>
> Maybe we could script something which asks freshmeat/sourceforge/ohloh
> for license information or scan for LICENSE in the work dir. But of
> course it would still require manual acknowledgment, I would not
> entirely rely on a script here.

I might just make it as simple as having "port lint" complain if the  
port doesn't specify the license. It's not too hard for a port  
maintainer to figure out and indicate what the license is, once  
they're made aware that they should do so.


From jeremy at lavergne.gotdns.org  Thu Apr  2 05:11:08 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Thu, 2 Apr 2009 08:11:08 -0400
Subject: Including spaces in adduser command
In-Reply-To: <5B4A38BD-E8E8-4881-AB24-198A14FF41A1@macports.org>
References: <557f33430904011528n2da7992fpea2d107939ffced@mail.gmail.com>
	<F4892770-8B63-4C6F-8181-CE425FEA86FB@lavergne.gotdns.org>
	<49D3EE0F.6090909@macports.org>
	<557f33430904011614o7dafac7cj1de0e097170fb29a@mail.gmail.com>
	<49D3FC31.6000301@macports.org>
	<20090402053902.GC505@ninagal.withay.com>
	<5B4A38BD-E8E8-4881-AB24-198A14FF41A1@macports.org>
Message-ID: <E412EF52-BFA2-4766-9DCF-E5A39A49FCA5@lavergne.gotdns.org>

I should think that shouldn't stop us from releasing important updates.

On Apr 2, 2009, at 5:25 AM, Ryan Schmidt wrote:

> By all means! :) Maybe not just yet, since we just had 1.7.1.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2435 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090402/667e87fa/attachment.bin>

From raimue at macports.org  Thu Apr  2 06:19:43 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 02 Apr 2009 15:19:43 +0200
Subject: Including spaces in adduser command
In-Reply-To: <20090402053902.GC505@ninagal.withay.com>
References: <557f33430904011528n2da7992fpea2d107939ffced@mail.gmail.com>	<F4892770-8B63-4C6F-8181-CE425FEA86FB@lavergne.gotdns.org>	<49D3EE0F.6090909@macports.org>	<557f33430904011614o7dafac7cj1de0e097170fb29a@mail.gmail.com>	<49D3FC31.6000301@macports.org>
	<20090402053902.GC505@ninagal.withay.com>
Message-ID: <49D4BB6F.8010700@macports.org>

On 2009-04-02 07:39, Bryan Blackburn wrote:
> On Thu, Apr 02, 2009 at 01:43:45AM +0200, Rainer M?ller said:
>> Fixed in r49013 [1] and merged back to release_1_7 in r49014 [2].
> 
> Does that mean we'll be having a 1.7.2 at some point?

Currently trunk is not yet in a state where we can estimate a time of
release. So I merged it back to release_1_7 just in case we have more
changes of this sort to do a 1.7.2 release. Otherwise it would have been
forgotten and nobody will scan all the commit log again to find this.

Rainer

From wsiegrist at apple.com  Thu Apr  2 06:36:04 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Thu, 02 Apr 2009 06:36:04 -0700
Subject: [49005] trunk/dports/PortIndex.quick
In-Reply-To: <69F44E5C-9ECF-43CC-912C-A5B31BF54E9B@macports.org>
References: <20090401193602.7292B13C9400@beta.macosforge.org>
	<69F44E5C-9ECF-43CC-912C-A5B31BF54E9B@macports.org>
Message-ID: <FC70F465-4B69-48E1-AB9A-9BF23BA246AE@apple.com>

On Apr 2, 2009, at 2:26 AM, Ryan Schmidt wrote:

>
> On Apr 1, 2009, at 14:36, wsiegrist at apple.com wrote:
>
>> Revision: 49005
>>          http://trac.macports.org/changeset/49005
>> Author:   wsiegrist at apple.com
>> Date:     2009-04-01 12:36:01 -0700 (Wed, 01 Apr 2009)
>> Log Message:
>> -----------
>> Mark the PortIndex.quick as binary to avoid the large diffs
>
> What *is* PortIndex.quick?
>

Its the new index file in 1.8 that stores offsets to each port in  
PortIndex. We now generate it server-side along with PortIndex. The  
change emails were very large since every line in PortIndex.quick  
changes frequently.

-Bill

From david.osguthorpe at gmail.com  Thu Apr  2 07:34:51 2009
From: david.osguthorpe at gmail.com (David Osguthorpe)
Date: Thu, 2 Apr 2009 08:34:51 -0600
Subject: Cleaning up during uninstall and submitting Portfile
In-Reply-To: <70B865FD-78AF-425E-831A-C2759413B7E7@macports.org>
References: <557f33430903310900s621c2476g3d23b7b6d85b60c8@mail.gmail.com>
	<DAAE2CE8-EFBE-4BCC-8BAF-6CC0E1007501@macports.org>
	<557f33430904020251k559ee9a9wa2d24a7aec6f08cc@mail.gmail.com>
	<70B865FD-78AF-425E-831A-C2759413B7E7@macports.org>
Message-ID: <20090402143451.GA2645@mactelhm.local>

On Thu, Apr 02, 2009 at 04:11:14AM -0600, Ryan Schmidt wrote:
> On Apr 2, 2009, at 04:51, Anand Buddhdev wrote:
> 
> Oh yes, understood. But sorry, no, there is no post-uninstall hook.  
> There are several ports where this would be useful, but nobody has  
> written it yet.
> 

what about the pkg_uninstall hook - this has existed for a long while
- although I see in registry2.0 somebody has commented this section

# pkg_uninstall isn't used anywhere as far as I can tell and I intend to add

of course it isnt used anywhere - you need to define a pkg_uninstall procedure
in the Portfile

the other fixup needed is an encoding of the procedure as defined in the Portfile
before it can be stored in the registry file so that it works after reading from the registry
- I needed a fixup to the proc_disasm procedure to map \n to \\n in the procedure body
to get this to work

append p [string map { \n \\n } [info body $pname] ]

with this I have had pkg_uninstall working for a few years - unfortunately the name change
from darwinports to macports made life difficult for me (running on Panther at the time
and only recently upgrading to Tiger because of features I needed that only worked
in Panther) and hence had no desire to upgrade that system
- only now with a new machine did I install the new macports

David


From raimue at macports.org  Thu Apr  2 07:40:15 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Thu, 02 Apr 2009 16:40:15 +0200
Subject: [49051] trunk/dports/devel/openssl/Portfile
In-Reply-To: <20090402103219.992D213E652C@beta.macosforge.org>
References: <20090402103219.992D213E652C@beta.macosforge.org>
Message-ID: <49D4CE4F.3020008@macports.org>

On 2009-04-02 12:32, mww at macports.org wrote:
> Revision: 49051
>           http://trac.macports.org/changeset/49051
> Author:   mww at macports.org
> Date:     2009-04-02 03:32:18 -0700 (Thu, 02 Apr 2009)
> Log Message:
> -----------
> version 1.0.0-beta1

Is it really wise to upgrade to a beta? Shouldn't MacPorts provide the
latest stable release instead? This is especially important for security
related ports like OpenSSL.

Rainer

From macsforever2000 at macports.org  Thu Apr  2 08:35:44 2009
From: macsforever2000 at macports.org (Frank Schima)
Date: Thu, 2 Apr 2009 09:35:44 -0600
Subject: [48945] trunk/dports/lang/spidermonkey/Portfile
In-Reply-To: <AACCB349-035B-463C-80E0-4E4BE8F3E95D@macports.org>
References: <20090331170601.2F649135D4C9@beta.macosforge.org>
	<AACCB349-035B-463C-80E0-4E4BE8F3E95D@macports.org>
Message-ID: <C4501710-A0F0-46DB-9822-2BEBDEC9656C@macports.org>


On Apr 2, 2009, at 2:34 AM, Ryan Schmidt wrote:

>
> On Mar 31, 2009, at 12:06, macsforever2000 at macports.org wrote:
>
>> Revision: 48945
>>          http://trac.macports.org/changeset/48945
>> Author:   macsforever2000 at macports.org
>> Date:     2009-03-31 10:06:00 -0700 (Tue, 31 Mar 2009)
>> Log Message:
>> -----------
>> Added UTF-8 support. (#18895)
>>
>> Modified Paths:
>> --------------
>>    trunk/dports/lang/spidermonkey/Portfile
>>
>> Modified: trunk/dports/lang/spidermonkey/Portfile
>> ===================================================================
>> --- trunk/dports/lang/spidermonkey/Portfile	2009-03-31 17:03:48 UTC
>> (rev 48944)
>> +++ trunk/dports/lang/spidermonkey/Portfile	2009-03-31 17:06:00 UTC
>> (rev 48945)
>> @@ -5,8 +5,7 @@
>>
>> name                spidermonkey
>> version             1.7.0
>> -revision            1
>> -epoch               1
>> +revision            2
>> categories          lang
>> platforms           darwin
>> maintainers         akitada openmaintainer
>
> Once epoch has been added to a port, you can never remove it or
> decrease it. I added it back in in r49041.

I didn't know that. Thanks for letting me know and for fixing it!


Cheers!
Frank


From raimue at macports.org  Thu Apr  2 08:51:52 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 02 Apr 2009 17:51:52 +0200
Subject: [49051] trunk/dports/devel/openssl/Portfile
In-Reply-To: <49D4CE4F.3020008@macports.org>
References: <20090402103219.992D213E652C@beta.macosforge.org>
	<49D4CE4F.3020008@macports.org>
Message-ID: <49D4DF18.3060006@macports.org>

On 2009-04-02 16:40, Rainer M?ller wrote:
> On 2009-04-02 12:32, mww at macports.org wrote:
>> Revision: 49051
>>           http://trac.macports.org/changeset/49051
>> Author:   mww at macports.org
>> Date:     2009-04-02 03:32:18 -0700 (Thu, 02 Apr 2009)
>> Log Message:
>> -----------
>> version 1.0.0-beta1
> 
> Is it really wise to upgrade to a beta? Shouldn't MacPorts provide the
> latest stable release instead? This is especially important for security
> related ports like OpenSSL.

As this also caused major problems with other ports not working anymore,
I reverted the change in r49057 [1], epoch increased.

See #19122 [2]

Rainer

[1] http://trac.macports.org/changeset/49057
[2] http://trac.macports.org/ticket/19122

From raimue at macports.org  Thu Apr  2 08:55:22 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 02 Apr 2009 17:55:22 +0200
Subject: Cleaning up during uninstall and submitting Portfile
In-Reply-To: <20090402143451.GA2645@mactelhm.local>
References: <557f33430903310900s621c2476g3d23b7b6d85b60c8@mail.gmail.com>	<DAAE2CE8-EFBE-4BCC-8BAF-6CC0E1007501@macports.org>	<557f33430904020251k559ee9a9wa2d24a7aec6f08cc@mail.gmail.com>	<70B865FD-78AF-425E-831A-C2759413B7E7@macports.org>
	<20090402143451.GA2645@mactelhm.local>
Message-ID: <49D4DFEA.4010509@macports.org>

On 2009-04-02 16:34, David Osguthorpe wrote:
> On Thu, Apr 02, 2009 at 04:11:14AM -0600, Ryan Schmidt wrote:
>> On Apr 2, 2009, at 04:51, Anand Buddhdev wrote:
>>
>> Oh yes, understood. But sorry, no, there is no post-uninstall hook.  
>> There are several ports where this would be useful, but nobody has  
>> written it yet.
>>
> 
> what about the pkg_uninstall hook - this has existed for a long while
> - although I see in registry2.0 somebody has commented this section

registry2.0 is not used at the moment, as the original author
Chris Pickel (sfiera@) got MIA and we don't know much about the current
state. So we will have to figure out how much is working already before
it can be included as default.

> # pkg_uninstall isn't used anywhere as far as I can tell and I intend to add
> 
> of course it isnt used anywhere - you need to define a pkg_uninstall procedure
> in the Portfile
> 
> the other fixup needed is an encoding of the procedure as defined in the Portfile
> before it can be stored in the registry file so that it works after reading from the registry
> - I needed a fixup to the proc_disasm procedure to map \n to \\n in the procedure body
> to get this to work
> 
> append p [string map { \n \\n } [info body $pname] ]
> 
> with this I have had pkg_uninstall working for a few years - unfortunately the name change
> from darwinports to macports made life difficult for me (running on Panther at the time
> and only recently upgrading to Tiger because of features I needed that only worked
> in Panther) and hence had no desire to upgrade that system
> - only now with a new machine did I install the new macports

Would you still care to send a patch? :-)

Rainer

From raimue at macports.org  Thu Apr  2 09:55:45 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 02 Apr 2009 18:55:45 +0200
Subject: Openssl: built-in or ports?
In-Reply-To: <EBABEE94-7780-4CB3-A06F-86D8413FCD6C@macports.org>
References: <557f33430903310658l34de2dc1l27af2d4d70dccf4b@mail.gmail.com>	<2DBE9E31-07B5-44BE-B8E8-EB29F3D98387@lavergne.gotdns.org>	<00183FE5-D221-4D64-8A62-3C0FE832B109@macports.org>	<FD99E2C5-12FB-4430-8B41-46E18AB9747C@macports.org>	<39FBAEBB-69FB-40A6-BABF-92753E34C018@macports.org>
	<EBABEE94-7780-4CB3-A06F-86D8413FCD6C@macports.org>
Message-ID: <49D4EE11.5030601@macports.org>

On 2009-04-02 12:54, Ryan Schmidt wrote:
> Absolutely. We already need a flag for whether distfiles may be  
> distributed. William is currently maintaining that list manually in  
> his mirror script, which isn't optimal. Anyone have a suggestion for  
> what such a flag could be called?

Either we make two flags, so this would be for mirroring:
  mirror.restricted yes

Or we integrate this into a 'licenses' option:
  licenses BSD
  licenses GPL
  licenses Restricted BSD
  licenses Restricted NoMirror

So multiple licenses can be named if parts are under different licenses,
with "Restricted" just naming something proprietary and "NoMirror"
indicating we are not allowed to mirror distfiles.

Rainer

From devans at macports.org  Thu Apr  2 10:17:11 2009
From: devans at macports.org (David Evans)
Date: Thu, 02 Apr 2009 10:17:11 -0700
Subject: Openssl: built-in or ports?
In-Reply-To: <49D4EE11.5030601@macports.org>
References: <557f33430903310658l34de2dc1l27af2d4d70dccf4b@mail.gmail.com>	<2DBE9E31-07B5-44BE-B8E8-EB29F3D98387@lavergne.gotdns.org>	<00183FE5-D221-4D64-8A62-3C0FE832B109@macports.org>	<FD99E2C5-12FB-4430-8B41-46E18AB9747C@macports.org>	<39FBAEBB-69FB-40A6-BABF-92753E34C018@macports.org>	<EBABEE94-7780-4CB3-A06F-86D8413FCD6C@macports.org>
	<49D4EE11.5030601@macports.org>
Message-ID: <49D4F317.6070303@macports.org>

Rainer M?ller wrote:
> On 2009-04-02 12:54, Ryan Schmidt wrote:
>   
>> Absolutely. We already need a flag for whether distfiles may be  
>> distributed. William is currently maintaining that list manually in  
>> his mirror script, which isn't optimal. Anyone have a suggestion for  
>> what such a flag could be called?
>>     
>
> Either we make two flags, so this would be for mirroring:
>   mirror.restricted yes
>
> Or we integrate this into a 'licenses' option:
>   licenses BSD
>   licenses GPL
>   licenses Restricted BSD
>   licenses Restricted NoMirror
>
> So multiple licenses can be named if parts are under different licenses,
> with "Restricted" just naming something proprietary and "NoMirror"
> indicating we are not allowed to mirror distfiles.
>
> Rainer
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>
>   
For some ports, licensing is dependent on variant selected.  For 
instance, ffmpeg
is GPL by default but is LGPL if the +no_gpl variant is specified 
causing GPL modules to be disabled.

This would work in these cases if it is acceptable to declare licenses 
in a variant definition clause.

From raimue at macports.org  Thu Apr  2 10:26:54 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 02 Apr 2009 19:26:54 +0200
Subject: Openssl: built-in or ports?
In-Reply-To: <49D4F317.6070303@macports.org>
References: <557f33430903310658l34de2dc1l27af2d4d70dccf4b@mail.gmail.com>	<2DBE9E31-07B5-44BE-B8E8-EB29F3D98387@lavergne.gotdns.org>	<00183FE5-D221-4D64-8A62-3C0FE832B109@macports.org>	<FD99E2C5-12FB-4430-8B41-46E18AB9747C@macports.org>	<39FBAEBB-69FB-40A6-BABF-92753E34C018@macports.org>	<EBABEE94-7780-4CB3-A06F-86D8413FCD6C@macports.org>
	<49D4EE11.5030601@macports.org> <49D4F317.6070303@macports.org>
Message-ID: <49D4F55E.6060408@macports.org>

On 2009-04-02 19:17, David Evans wrote:
> For some ports, licensing is dependent on variant selected.  For 
> instance, ffmpeg
> is GPL by default but is LGPL if the +no_gpl variant is specified 
> causing GPL modules to be disabled.

Good catch.

> This would work in these cases if it is acceptable to declare licenses 
> in a variant definition clause.

Should be no problem to use licenses-delete and licenses-append in
variants. But my proposed NoMirror or mirror.restricted would always be
for all distfiles, as I don't think we need to make it more specific.

Rainer

From david.osguthorpe at gmail.com  Thu Apr  2 11:00:42 2009
From: david.osguthorpe at gmail.com (David Osguthorpe)
Date: Thu, 2 Apr 2009 12:00:42 -0600
Subject: Cleaning up during uninstall and submitting Portfile
In-Reply-To: <49D4DFEA.4010509@macports.org>
References: <557f33430903310900s621c2476g3d23b7b6d85b60c8@mail.gmail.com>
	<DAAE2CE8-EFBE-4BCC-8BAF-6CC0E1007501@macports.org>
	<557f33430904020251k559ee9a9wa2d24a7aec6f08cc@mail.gmail.com>
	<70B865FD-78AF-425E-831A-C2759413B7E7@macports.org>
	<20090402143451.GA2645@mactelhm.local>
	<49D4DFEA.4010509@macports.org>
Message-ID: <20090402180042.GA3284@mactelhm.local>

On Thu, Apr 02, 2009 at 09:55:22AM -0600, Rainer M?ller wrote:
> > 
> > with this I have had pkg_uninstall working for a few years - unfortunately the name change
> > from darwinports to macports made life difficult for me (running on Panther at the time
> > and only recently upgrading to Tiger because of features I needed that only worked
> > in Panther) and hence had no desire to upgrade that system
> > - only now with a new machine did I install the new macports
> 
> Would you still care to send a patch? :-)
> 

I will attempt to create a patch for the current Macports - if I remember right this
turned out to be a 1 line patch in the proc_disasm
- hopefully I can check if its working reasonably quickly

(I actually had a few patches I was going to submit at that time for the last 1.4..
version but because of not upgrading to macports I wasnt able to update them for the
newer versions - my new machine is also a ppc to intel switch)

David

From afb at macports.org  Thu Apr  2 12:48:14 2009
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Thu, 2 Apr 2009 21:48:14 +0200
Subject: Openssl: built-in or ports?
In-Reply-To: <49D4EE11.5030601@macports.org>
References: <557f33430903310658l34de2dc1l27af2d4d70dccf4b@mail.gmail.com>	<2DBE9E31-07B5-44BE-B8E8-EB29F3D98387@lavergne.gotdns.org>	<00183FE5-D221-4D64-8A62-3C0FE832B109@macports.org>	<FD99E2C5-12FB-4430-8B41-46E18AB9747C@macports.org>	<39FBAEBB-69FB-40A6-BABF-92753E34C018@macports.org>
	<EBABEE94-7780-4CB3-A06F-86D8413FCD6C@macports.org>
	<49D4EE11.5030601@macports.org>
Message-ID: <5C0302EF-C1BC-42F6-9E63-9EEDCC5B8B6D@macports.org>

> Either we make two flags, so this would be for mirroring:
>   mirror.restricted yes
>
> Or we integrate this into a 'licenses' option:
>   licenses BSD
>   licenses GPL
>   licenses Restricted BSD
>   licenses Restricted NoMirror
>
> So multiple licenses can be named if parts are under different  
> licenses,
> with "Restricted" just naming something proprietary and "NoMirror"
> indicating we are not allowed to mirror distfiles.

I'd make two flags, instead of having "special" licenses...

--anders


From blb at macports.org  Thu Apr  2 13:21:13 2009
From: blb at macports.org (Bryan Blackburn)
Date: Thu, 2 Apr 2009 14:21:13 -0600
Subject: [49005] trunk/dports/PortIndex.quick
In-Reply-To: <FC70F465-4B69-48E1-AB9A-9BF23BA246AE@apple.com>
References: <20090401193602.7292B13C9400@beta.macosforge.org>
	<69F44E5C-9ECF-43CC-912C-A5B31BF54E9B@macports.org>
	<FC70F465-4B69-48E1-AB9A-9BF23BA246AE@apple.com>
Message-ID: <20090402202113.GC701@ninagal.withay.com>

On Thu, Apr 02, 2009 at 06:36:04AM -0700, William Siegrist said:
> On Apr 2, 2009, at 2:26 AM, Ryan Schmidt wrote:
>
>>
>> On Apr 1, 2009, at 14:36, wsiegrist at apple.com wrote:
>>
>>> Revision: 49005
>>>          http://trac.macports.org/changeset/49005
>>> Author:   wsiegrist at apple.com
>>> Date:     2009-04-01 12:36:01 -0700 (Wed, 01 Apr 2009)
>>> Log Message:
>>> -----------
>>> Mark the PortIndex.quick as binary to avoid the large diffs
>>
>> What *is* PortIndex.quick?
>>
>
> Its the new index file in 1.8 that stores offsets to each port in  
> PortIndex. We now generate it server-side along with PortIndex. The  
> change emails were very large since every line in PortIndex.quick changes 
> frequently.

And the purpose of this file is to drastically help speed up dependency
calculations; see

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

Bryan


>
> -Bill

From raimue at macports.org  Thu Apr  2 13:59:48 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 02 Apr 2009 22:59:48 +0200
Subject: Openssl: built-in or ports?
In-Reply-To: <B996D2E1-A468-469D-BC96-A50487FB8E61@macports.org>
References: <557f33430903310658l34de2dc1l27af2d4d70dccf4b@mail.gmail.com>	<2DBE9E31-07B5-44BE-B8E8-EB29F3D98387@lavergne.gotdns.org>	<00183FE5-D221-4D64-8A62-3C0FE832B109@macports.org>
	<FD99E2C5-12FB-4430-8B41-46E18AB9747C@macports.org>
	<49D41C98.20404@macports.org>
	<B996D2E1-A468-469D-BC96-A50487FB8E61@macports.org>
Message-ID: <49D52744.1080305@macports.org>

On 2009-04-02 12:56, Ryan Schmidt wrote:
> I might just make it as simple as having "port lint" complain if the  
> port doesn't specify the license. It's not too hard for a port  
> maintainer to figure out and indicate what the license is, once  
> they're made aware that they should do so.

Of course that will work for ports with an active maintainer. But around
41% of the ports do not have a maintainer listed. The number of ports
with a listed maintainer being inactive is unknown, so I suspect it to
be more ports actually being unmaintained.

$ port echo all |wc -l
    5695
$ port echo maintainer:nomaintainer |wc -l
    2349

As an example, many ports are missing the platforms variable. This is
not really important as it is not used currently, but port lint already
warns to add it. Still there are a lot of ports without a platforms
statement and I assume most of them do also not have a maintainer.

Rainer

From wsiegrist at apple.com  Thu Apr  2 14:01:07 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Thu, 02 Apr 2009 14:01:07 -0700
Subject: [MacPorts] BadContent added
In-Reply-To: <20090402205709.7E40328082@relay11.apple.com>
References: <20090402205709.7E40328082@relay11.apple.com>
Message-ID: <08A5B541-3881-40F1-8687-27F34A614CA8@apple.com>

This is to support a spam filter, please do not actually go to that URL.

Thanks
-Bill

On Apr 2, 2009, at 1:57 PM, MacPorts wrote:

>
> Added page "BadContent" by wsiegrist at apple.com from 17.202.44.123*
> Page URL: <http://trac.macports.org/wiki/BadContent>
> Content:
> -------8
> <------8<------8<------8<------8<------8<------8<------8<--------
> {{{
> www.sneakeralley.com
> }}}
>
> -------8
> <------8<------8<------8<------8<------8<------8<------8<--------
>
> * The IP shown here might not mean anything if the user or the  
> server is
> behind a proxy.
>
> --
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS
>
> This is an automated message. Someone at http://www.macports.org/  
> added your email
> address to be notified of changes on BadContent. If it was not you,  
> please
> report to .
>


From brad at pixilla.com  Thu Apr  2 15:23:49 2009
From: brad at pixilla.com (Bradley Giesbrecht)
Date: Thu, 2 Apr 2009 15:23:49 -0700
Subject: postfix +tls upgrade broken
Message-ID: <FA6D7086-54C4-4ED7-8173-AAC2E2DA62DD@pixilla.com>

Performing "port selfupdate" followed by "port upgrade outdated" and  
my postfix +tls was broken by not finding "/opt/local/lib/libssl. 
0.9.8.dylib".

Adding a symlink provided a quick fix. I'd like to see postfix  
building with this simlink "/opt/local/lib/libssl.dylib" instead.
libcrypto has the same issue here.

lrwxr-xr-x  1 root  admin      12 Apr  2 14:55 /opt/local/lib/libssl. 
0.9.8.dylib -> libssl.dylib
-r-xr-xr-x  2 root  admin  346816 Apr  2 14:44 /opt/local/lib/libssl. 
1.0.0.dylib
-rw-r--r--  2 root  admin  543408 Apr  2 14:44 /opt/local/lib/libssl.a
lrwxr-xr-x  1 root  admin      18 Apr  2 14:44 /opt/local/lib/ 
libssl.dylib -> libssl.1.0.0.dylib


//Brad

From max at inmachina.com  Thu Apr  2 15:36:03 2009
From: max at inmachina.com (Maximilian Nickel)
Date: Fri, 3 Apr 2009 00:36:03 +0200
Subject: postfix +tls upgrade broken
In-Reply-To: <FA6D7086-54C4-4ED7-8173-AAC2E2DA62DD@pixilla.com>
References: <FA6D7086-54C4-4ED7-8173-AAC2E2DA62DD@pixilla.com>
Message-ID: <7bad5d350904021536h4d97e398n8844e58955b9941@mail.gmail.com>

Hi Brad,
it seems like you have been affected by the openssl-1.0.0-beta1 update. This
update has been reverted since it broke some ports. A 'port sync' and
subsequent update of openssl should fix the issue

/max

On Fri, Apr 3, 2009 at 12:23 AM, Bradley Giesbrecht <brad at pixilla.com>wrote:

> Performing "port selfupdate" followed by "port upgrade outdated" and my
> postfix +tls was broken by not finding "/opt/local/lib/libssl.0.9.8.dylib".
>
> Adding a symlink provided a quick fix. I'd like to see postfix building
> with this simlink "/opt/local/lib/libssl.dylib" instead.
> libcrypto has the same issue here.
>
> lrwxr-xr-x  1 root  admin      12 Apr  2 14:55
> /opt/local/lib/libssl.0.9.8.dylib -> libssl.dylib
> -r-xr-xr-x  2 root  admin  346816 Apr  2 14:44
> /opt/local/lib/libssl.1.0.0.dylib
> -rw-r--r--  2 root  admin  543408 Apr  2 14:44 /opt/local/lib/libssl.a
> lrwxr-xr-x  1 root  admin      18 Apr  2 14:44 /opt/local/lib/libssl.dylib
> -> libssl.1.0.0.dylib
>
>
> //Brad
> _______________________________________________
> 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/20090403/1aed82b8/attachment.html>

From raimue at macports.org  Thu Apr  2 16:01:02 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Fri, 03 Apr 2009 01:01:02 +0200
Subject: postfix +tls upgrade broken
In-Reply-To: <FA6D7086-54C4-4ED7-8173-AAC2E2DA62DD@pixilla.com>
References: <FA6D7086-54C4-4ED7-8173-AAC2E2DA62DD@pixilla.com>
Message-ID: <49D543AE.4040601@macports.org>

On 2009-04-03 00:23, Bradley Giesbrecht wrote:
> Performing "port selfupdate" followed by "port upgrade outdated" and  
> my postfix +tls was broken by not finding "/opt/local/lib/libssl. 
> 0.9.8.dylib".
> 
> Adding a symlink provided a quick fix. I'd like to see postfix  
> building with this simlink "/opt/local/lib/libssl.dylib" instead.
> libcrypto has the same issue here.
> 
> lrwxr-xr-x  1 root  admin      12 Apr  2 14:55 /opt/local/lib/libssl. 
> 0.9.8.dylib -> libssl.dylib
> -r-xr-xr-x  2 root  admin  346816 Apr  2 14:44 /opt/local/lib/libssl. 
> 1.0.0.dylib
> -rw-r--r--  2 root  admin  543408 Apr  2 14:44 /opt/local/lib/libssl.a
> lrwxr-xr-x  1 root  admin      18 Apr  2 14:44 /opt/local/lib/ 
> libssl.dylib -> libssl.1.0.0.dylib

Sync again and then upgrade openssl. The openssl @1.0.0-beta1 port
upgrade has been reverted.

But in general, this is how the final update to openssl @1.0.0 will go.
Every dependent need to be rebuild as usually for every upgrade. Just
that in this case it will affect many ports and will probably cause much
confusion at first.

I don't think there is a better solution currently than advising to run
'sudo port -R upgrade openssl' when it is released, even if it will
probably trigger a lot of unnecessary rebuilds.

Rainer

From mark at dxradio.demon.co.uk  Thu Apr  2 16:53:48 2009
From: mark at dxradio.demon.co.uk (Mark Hattam)
Date: Fri, 3 Apr 2009 00:53:48 +0100
Subject: [49051] trunk/dports/devel/openssl/Portfile
In-Reply-To: <49D4DF18.3060006@macports.org>
References: <20090402103219.992D213E652C@beta.macosforge.org>
	<49D4CE4F.3020008@macports.org> <49D4DF18.3060006@macports.org>
Message-ID: <837B3C95-9950-41D2-BE3F-B6C42C88A8DC@dxradio.demon.co.uk>


On 2 Apr 2009, at 16:51, Rainer M?ller wrote:

> On 2009-04-02 16:40, Rainer M?ller wrote:
>> On 2009-04-02 12:32, mww at macports.org wrote:
>>> Revision: 49051
>>>          http://trac.macports.org/changeset/49051
>>> Author:   mww at macports.org
>>> Date:     2009-04-02 03:32:18 -0700 (Thu, 02 Apr 2009)
>>> Log Message:
>>> -----------
>>> version 1.0.0-beta1
>>
>> Is it really wise to upgrade to a beta? Shouldn't MacPorts provide  
>> the
>> latest stable release instead? This is especially important for  
>> security
>> related ports like OpenSSL.
>
> As this also caused major problems with other ports not working  
> anymore,
> I reverted the change in r49057 [1], epoch increased.
>
> See #19122 [2]
>
> Rainer
>
> [1] http://trac.macports.org/changeset/49057
> [2] http://trac.macports.org/ticket/19122
> _______________________________________________


Is this the cause of openssl updating itself tonight with the same  
version?

iMac:~ mark$ sudo port outdated
openssl                        0.9.8k_0 < 0.9.8k_0
sqlite3                        3.6.11_0 < 3.6.12_0

iMac:~ mark$ sudo port upgrade outdated
--->  Fetching openssl
--->  Verifying checksum(s) for openssl
--->  Extracting openssl
--->  Applying patches to openssl
--->  Configuring openssl
--->  Building openssl
--->  Staging openssl into destroot
--->  Deactivating openssl @0.9.8k_0
--->  Unable to uninstall openssl 0.9.8k_0, the following ports depend  
on it:
--->  	neon
--->  	serf
--->  	apache2
--->  	dovecot
--->  	cyrus-sasl2
--->  	wget
--->  	php5
--->  	mysql5
Warning: Uninstall forced.  Proceeding despite dependencies.
--->  Uninstalling openssl @0.9.8k_0
--->  Installing openssl @0.9.8k_0
--->  Activating openssl @0.9.8k_0
--->  Cleaning openssl
--->  Fetching sqlite3
--->  Attempting to fetch sqlite-3.6.12.tar.gz from http://arn.se.distfiles.macports.org/sqlite3/3.6.12
--->  Attempting to fetch sqlite-3.6.12.tar.gz from http://trd.no.distfiles.macports.org/sqlite3/3.6.12
--->  Attempting to fetch sqlite-3.6.12.tar.gz from http://www.sqlite.org/
--->  Verifying checksum(s) for sqlite3
--->  Extracting sqlite3
--->  Configuring sqlite3
--->  Building sqlite3
--->  Staging sqlite3 into destroot
--->  Deactivating sqlite3 @3.6.11_0
--->  Installing sqlite3 @3.6.12_0
--->  Activating sqlite3 @3.6.12_0
--->  Cleaning sqlite3

iMac:~ mark$ sudo port uninstall inactive
--->  Uninstalling sqlite3 @3.6.11_0

iMac:~ mark$ sudo port outdated
No installed ports are outdated.


From ryandesign at macports.org  Thu Apr  2 17:25:08 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 2 Apr 2009 19:25:08 -0500
Subject: [48945] trunk/dports/lang/spidermonkey/Portfile
In-Reply-To: <C4501710-A0F0-46DB-9822-2BEBDEC9656C@macports.org>
References: <20090331170601.2F649135D4C9@beta.macosforge.org>
	<AACCB349-035B-463C-80E0-4E4BE8F3E95D@macports.org>
	<C4501710-A0F0-46DB-9822-2BEBDEC9656C@macports.org>
Message-ID: <B6F9DFCE-F7F9-44E2-B02D-7E6E09E55A1E@macports.org>

On Apr 2, 2009, at 10:35, Frank Schima wrote:

> On Apr 2, 2009, at 2:34 AM, Ryan Schmidt wrote:
>
>> Once epoch has been added to a port, you can never remove it or
>> decrease it. I added it back in in r49041.
>
> I didn't know that. Thanks for letting me know and for fixing it!

The order of precedence is:

epoch (default 0)
version
revision (default 0)

So if you have a port at version 1.0, the number MacPorts uses for  
comparison is really something like 0_1.0_0.

In the case of the spidermonkey port:

>>> @@ -5,8 +5,7 @@
>>>
>>> name                spidermonkey
>>> version             1.7.0
>>> -revision            1
>>> -epoch               1
>>> +revision            2
>>> categories          lang
>>> platforms           darwin
>>> maintainers         akitada openmaintainer

the number was 1_1.7.0_1, and you changed it to 0_1.7.0_2. Since the  
first 0 in your new number is less than the 1 at the start of the old  
number, "port outdated" would not think the port was outdated.


From ryandesign at macports.org  Thu Apr  2 17:29:17 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 2 Apr 2009 19:29:17 -0500
Subject: Including spaces in adduser command
In-Reply-To: <E412EF52-BFA2-4766-9DCF-E5A39A49FCA5@lavergne.gotdns.org>
References: <557f33430904011528n2da7992fpea2d107939ffced@mail.gmail.com>
	<F4892770-8B63-4C6F-8181-CE425FEA86FB@lavergne.gotdns.org>
	<49D3EE0F.6090909@macports.org>
	<557f33430904011614o7dafac7cj1de0e097170fb29a@mail.gmail.com>
	<49D3FC31.6000301@macports.org>
	<20090402053902.GC505@ninagal.withay.com>
	<5B4A38BD-E8E8-4881-AB24-198A14FF41A1@macports.org>
	<E412EF52-BFA2-4766-9DCF-E5A39A49FCA5@lavergne.gotdns.org>
Message-ID: <5476388F-A7C4-4F2F-A9F2-C17C5E4ED0E3@macports.org>

On Apr 2, 2009, at 07:11, Jeremy Lavergne wrote:

> On Apr 2, 2009, at 5:25 AM, Ryan Schmidt wrote:
>
>> By all means! :) Maybe not just yet, since we just had 1.7.1.
>
> I should think that shouldn't stop us from releasing important  
> updates.

I suppose not.

There were a few changes I wanted to merge back to the 1.7 branch in  
time for 1.7.1, and then suddenly 1.7.1 had been released. So I'd  
like to go back and merge those for 1.7.2.

This bug we're talking about here, with spaces in adduser, has  
existed forever, though, right? It's not a regression introduced by  
1.7.1? So it doesn't seem to me like there is that much urgency to  
fix it immediately.


From ryandesign at macports.org  Thu Apr  2 17:31:29 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 2 Apr 2009 19:31:29 -0500
Subject: Fwd: Cleaning up during uninstall and submitting Portfile
References: <557f33430904020457o33e9ee41x80933dda3a75492a@mail.gmail.com>
Message-ID: <9A3C62C4-1098-4D9D-AE7D-93628F8AC05D@macports.org>

Forwarding to list. Please use Reply All so your reply goes to the  
list too, not just to me.


Anand wrote:

> Ryan wrote:
>
>> Anand wrote:
>>
>>> Actually, this is what I'm already doing. However, at run-time,  
>>> the package creates files in these directories, so Macports  
>>> doesn't remove them. That's why I was asking about something like  
>>> a post-uninstall hook, which can remove these (possibly) nonempty  
>>> directories, and remove the user account created during package  
>>> installation.
>>
>> Oh yes, understood. But sorry, no, there is no post-uninstall  
>> hook. There are several ports where this would be useful, but  
>> nobody has written it yet.
>
>
> Okay, thanks for letting me know. I'll live without the post- 
> install hook for now. Many other ports behave this way too, so it's  
> not a big problem.


From ryandesign at macports.org  Thu Apr  2 17:32:37 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 2 Apr 2009 19:32:37 -0500
Subject: Fwd: Including spaces in adduser command
References: <557f33430904020500mf1058fds1d088d11ab7ae189@mail.gmail.com>
Message-ID: <89DD257B-0C00-4477-A571-CA6D40CA8BDD@macports.org>

Forwarding to list. Please use Reply All so your reply goes to the  
list too, not just to me.


Anand wrote:

> 2009/4/2 Ryan Schmidt wrote:
>
>> On Apr 2, 2009, at 00:39, Bryan Blackburn wrote:
>>
>>> On Thu, Apr 02, 2009 at 01:43:45AM +0200, Rainer M?ller said:
>>>
>>>> Fixed in r49013 [1] and merged back to release_1_7 in r49014 [2].
>>>
>>> Does that mean we'll be having a 1.7.2 at some point?
>>
>> By all means! :) Maybe not just yet, since we just had 1.7.1.
>
> Shame :(
>
> In any case, I will submit my Portfile now, because it is complete  
> and correct, and the extra backslash in the user's real name is not  
> a big problem, and it will go away with 1.7.2 is released.
>
> Thanks for all your help gentlemen.


From raimue at macports.org  Thu Apr  2 17:43:10 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Fri, 03 Apr 2009 02:43:10 +0200
Subject: [49051] trunk/dports/devel/openssl/Portfile
In-Reply-To: <837B3C95-9950-41D2-BE3F-B6C42C88A8DC@dxradio.demon.co.uk>
References: <20090402103219.992D213E652C@beta.macosforge.org>
	<49D4CE4F.3020008@macports.org> <49D4DF18.3060006@macports.org>
	<837B3C95-9950-41D2-BE3F-B6C42C88A8DC@dxradio.demon.co.uk>
Message-ID: <49D55B9E.8000603@macports.org>

On 2009-04-03 01:53, Mark Hattam wrote:
> Is this the cause of openssl updating itself tonight with the same  
> version?
> 
> iMac:~ mark$ sudo port outdated
> openssl                        0.9.8k_0 < 0.9.8k_0
> sqlite3                        3.6.11_0 < 3.6.12_0

Yes, doing a downgrade means we have to override the version check by
increasing the epoch in the Portfile. Which means the reverted Portfile
is now always considered newer than the old version you had, even if it
is actually the same.

Rainer

From ryandesign at macports.org  Thu Apr  2 19:14:37 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 2 Apr 2009 21:14:37 -0500
Subject: -isystem${prefix}/include instead of -I${prefix}/include
Message-ID: <2F1491A4-0AB4-4687-85E0-4AA02C1BA5FA@macports.org>

Many ports now replace the -I${prefix}/include that MacPorts  
automatically puts into the CPPFLAGS with -isystem${prefix}/include  
to work around issues. (freetype ghostscript jpeg pdflib qt4-kde qt4- 
mac-devel qt4-mac qt4-x11 texlive_base)

Should we make this change in MacPorts base?

When I brought this situation to the attention of the developer of  
freetype, he said that what we are doing with -I is "completely non- 
standard", and that using -isystem would be "exactly the right thing."

http://lists.gnu.org/archive/html/freetype/2009-04/msg00005.html


What about LDFLAGS? We currently do -L${prefix}/lib. Is this also non- 
standard and problematic? (Could it be the cause of #18937?) Should  
we do something else? I thought someone mentioned something about  
this but I can't find it now and can't figure out how to search for  
it in the archives.


I've always wondered how C_INCLUDE_PATH and LIBRARY_PATH compared to  
what we do, but if we find a solution in -isystem and whatever its  
library analog is, then I don't care.


From ryandesign at macports.org  Thu Apr  2 19:40:21 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 2 Apr 2009 21:40:21 -0500
Subject: Openssl: built-in or ports?
In-Reply-To: <49D4F55E.6060408@macports.org>
References: <557f33430903310658l34de2dc1l27af2d4d70dccf4b@mail.gmail.com>	<2DBE9E31-07B5-44BE-B8E8-EB29F3D98387@lavergne.gotdns.org>	<00183FE5-D221-4D64-8A62-3C0FE832B109@macports.org>	<FD99E2C5-12FB-4430-8B41-46E18AB9747C@macports.org>	<39FBAEBB-69FB-40A6-BABF-92753E34C018@macports.org>	<EBABEE94-7780-4CB3-A06F-86D8413FCD6C@macports.org>
	<49D4EE11.5030601@macports.org> <49D4F317.6070303@macports.org>
	<49D4F55E.6060408@macports.org>
Message-ID: <2B2EB118-8437-40AA-8A3A-DEFBFA34ADB6@macports.org>


On Apr 2, 2009, at 12:26, Rainer M?ller wrote:

> On 2009-04-02 19:17, David Evans wrote:
>> For some ports, licensing is dependent on variant selected.  For
>> instance, ffmpeg
>> is GPL by default but is LGPL if the +no_gpl variant is specified
>> causing GPL modules to be disabled.
>
> Good catch.
>
>> This would work in these cases if it is acceptable to declare  
>> licenses
>> in a variant definition clause.
>
> Should be no problem to use licenses-delete and licenses-append in
> variants. But my proposed NoMirror or mirror.restricted would  
> always be
> for all distfiles, as I don't think we need to make it more specific.

Here's an idea: we could make a variable mirror.only, being similar  
to the existing variable extract.only. If not all files may be  
mirrored, you can list the ones that may be mirrored in mirror.only,  
or set mirror.only to empty if none may be mirrored.

That doesn't address binary files, since I don't know what filenames  
our binaries would have. And I think a simple yes/no flag would be  
more appropriate for whether binaries may be distributed, since it  
could vary by variant, so it would be most simple to be able to set  
that flag in the particular variant. e.g. for freetype:

variant bytecode description {Build bytecode interpreter into the  
TrueType driver} {
	create_binaries no
	...
}

I don't like "mirror.restricted yes" to restrict mirroring; I'd  
rather make it a positive statement, like "mirror.allowed no" or  
"distfiles.mirror no". "mirror.restricted yes" feels like having a  
checkbox that says "[X] Don't mirror" (read: "Yes, don't mirror");  
checkboxes (or other Booleans) with negative wording are confusing.  
Simper: "[ ] Mirror"


From raimue at macports.org  Thu Apr  2 21:55:17 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Fri, 03 Apr 2009 06:55:17 +0200
Subject: Openssl: built-in or ports?
In-Reply-To: <2B2EB118-8437-40AA-8A3A-DEFBFA34ADB6@macports.org>
References: <557f33430903310658l34de2dc1l27af2d4d70dccf4b@mail.gmail.com>	<2DBE9E31-07B5-44BE-B8E8-EB29F3D98387@lavergne.gotdns.org>	<00183FE5-D221-4D64-8A62-3C0FE832B109@macports.org>	<FD99E2C5-12FB-4430-8B41-46E18AB9747C@macports.org>	<39FBAEBB-69FB-40A6-BABF-92753E34C018@macports.org>	<EBABEE94-7780-4CB3-A06F-86D8413FCD6C@macports.org>
	<49D4EE11.5030601@macports.org> <49D4F317.6070303@macports.org>
	<49D4F55E.6060408@macports.org>
	<2B2EB118-8437-40AA-8A3A-DEFBFA34ADB6@macports.org>
Message-ID: <49D596B5.3020607@macports.org>

On 2009-04-03 04:40, Ryan Schmidt wrote:
> Here's an idea: we could make a variable mirror.only, being similar  
> to the existing variable extract.only. If not all files may be  
> mirrored, you can list the ones that may be mirrored in mirror.only,  
> or set mirror.only to empty if none may be mirrored.

Okay, this allows to set mirroring per distfile. But using
  mirror.only
to prevent mirroring looks quite strange to me.

> That doesn't address binary files, since I don't know what filenames  
> our binaries would have. And I think a simple yes/no flag would be  
> more appropriate for whether binaries may be distributed, since it  
> could vary by variant, so it would be most simple to be able to set  
> that flag in the particular variant. e.g. for freetype:

Binary files are out of scope here for mirroring as they do not exist at
the time of writing the Portfile. And a binary file is not a distfile.

> variant bytecode description {Build bytecode interpreter into the  
> TrueType driver} {
> 	create_binaries no
> 	...
> }

What about
  package.create no
The code for creating binary packages lives in package1.0. This could
both be set from the main Portfile or from variants. Default being yes.
Maybe there will be other options necessary for binaries we don't know
yet, so having a package.* namespace sounds like a good idea to me.

> I don't like "mirror.restricted yes" to restrict mirroring; I'd  
> rather make it a positive statement, like "mirror.allowed no" or  
> "distfiles.mirror no". "mirror.restricted yes" feels like having a  
> checkbox that says "[X] Don't mirror" (read: "Yes, don't mirror");  
> checkboxes (or other Booleans) with negative wording are confusing.  
> Simper: "[ ] Mirror"

Okay, I concur with that :-)

Rainer

From dluke at geeklair.net  Fri Apr  3 06:07:18 2009
From: dluke at geeklair.net (Daniel J. Luke)
Date: Fri, 3 Apr 2009 09:07:18 -0400
Subject: postfix +tls upgrade broken
In-Reply-To: <49D543AE.4040601@macports.org>
References: <FA6D7086-54C4-4ED7-8173-AAC2E2DA62DD@pixilla.com>
	<49D543AE.4040601@macports.org>
Message-ID: <1D916FE9-5FA1-4321-A51B-946A0CDB8A39@geeklair.net>

On Apr 2, 2009, at 7:01 PM, Rainer M?ller wrote:
> But in general, this is how the final update to openssl @1.0.0 will  
> go.
> Every dependent need to be rebuild as usually for every upgrade. Just
> that in this case it will affect many ports and will probably cause  
> much
> confusion at first.
>
> I don't think there is a better solution currently than advising to  
> run
> 'sudo port -R upgrade openssl' when it is released, even if it will
> probably trigger a lot of unnecessary rebuilds.


In the past, we have rev-bumped every port that we thought would need  
a rebuild when we've done something like this...

--
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/20090403/9d70ebb9/attachment.bin>

From jmpp at macports.org  Fri Apr  3 08:43:38 2009
From: jmpp at macports.org (Juan Manuel Palacios)
Date: Fri, 3 Apr 2009 11:13:38 -0430
Subject: Question regarding Xcode version check
In-Reply-To: <4C59AACF-5BB6-498C-9F27-50A84A19FA42@macports.org>
References: <ED905CBD-6C77-446D-B058-081D0470B42D@macports.org>
	<4C59AACF-5BB6-498C-9F27-50A84A19FA42@macports.org>
Message-ID: <ED934BD3-0797-4C4B-90BE-1D8D90EF178F@macports.org>


On Apr 2, 2009, at 1:58 AM, Ryan Schmidt wrote:

> On Apr 1, 2009, at 20:17, Juan Manuel Palacios wrote:
>
>> 	Hey Ryan! Believe it or not, I'm still alive ;-)
>>
>> 	Today I was putting together a MAMP installation on a Mac at work,  
>> with our beautiful MacPorts of course, and stumbled on a rather  
>> annoying glitch, or what at least looks like one. The tiff port has  
>> the standard check for the minimum Xcode version on Leopard, 3.1.2,  
>> as introduced by you in r48210; but said check happens at pre- 
>> extract time, which means port has already wasted time downloading  
>> the distfile if the target Mac has Xcode < 3.1.2, which was my case  
>> this time round. Is it possible to move the check up to pre-fetch?
>>
>> 	I'm not gonna commit that change just now, one 'cause the port is  
>> not openmaintainer and, two, 'cause I don't know if pre-fetch was  
>> explicitly avoided for a reason.
>>
>> 	Let me know, thanks! Regards,...
>
> Hi Juan!
>
> This was a deliberate decision, and I'm copying macports-dev on this  
> answer since I never explained the rationale before, so let me do so  
> now.
>
> Some of my ports do checks and issue fatal error messages in the pre- 
> fetch phase. I reserve this for ports which can never be installed  
> on the given system at all. For example, if you try to install wine  
> on a PowerPC Mac, or oracle-instantclient on an Intel Mac with Tiger  
> or earlier. It can't be done. There is no way those ports will ever  
> work on those systems, so there's no point allowing the user to  
> download the distfile.
>
> For other ports, like tiff, as you found, and any others where I've  
> added the Xcode version check, and other ports like pango and cairo  
> and pure which check the version of other installed ports, the check  
> is in pre-extract, specifically so that the user can still fetch and  
> verify the distfile. Most likely, the user wants to install the  
> software, so after encountering the message that they need to  
> upgrade their Xcode, they will seek out and download the new Xcode,  
> and then be able to install the software. I did not want to put the  
> check in the pre-fetch phase because that would prevent the user  
> from doing something like "port fetch outdated" or "port fetch some  
> long list of ports" which the user may want to do if they have a  
> slow network connection and/or want to download these files  
> unattended. The user might be annoyed to have left the machine alone  
> for hours while they expect it to be downloading many ports, only to  
> find when they come back that it has exited with an error after  
> failing to download only a few files. Sure, the user won't be able  
> to install this specific port without downloading the newer Xcode,  
> but they can still install the others they fetched.
>
> Anyway, not sure if these hypothetical uses actually occur, but that  
> was why I decided to do it this way.
>


	Yeah, seems like a legit reasoning to me, and indeed I updated Xcode  
and went on to install the already downloaded tiff port, so in this  
case your theory did hold true ;-) All in all, pre-fetch is for sort- 
of irrecoverable errors and pre-extract for sort-of soft errors, which  
I agree is a good compromise.

	Thanks for the explanation! (which should probably go in a portfile  
writing tips document ;-) Regards,...


-jmpp


From jeremyhu at macports.org  Fri Apr  3 17:03:51 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Fri, 3 Apr 2009 17:03:51 -0700
Subject: [48220] trunk/dports/x11
In-Reply-To: <22D20BB2-F8E0-44C0-A923-8D7E8571FA88@macports.org>
References: <20090317025323.8D4D5122F2C6@beta.macosforge.org>
	<22D20BB2-F8E0-44C0-A923-8D7E8571FA88@macports.org>
Message-ID: <EF540C4A-1E12-4874-B615-CF7F5E839A22@macports.org>


On Apr 2, 2009, at 00:12, Ryan Schmidt wrote:

> On Mar 16, 2009, at 21:53, jeremyhu at macports.org wrote:
>
>> Revision: 48220
>>          http://trac.macports.org/changeset/48220
>> Author:   jeremyhu at macports.org
>> Date:     2009-03-16 19:53:23 -0700 (Mon, 16 Mar 2009)
>> Log Message:
>> -----------
>> quartz-wm: New port
>>
>> Added Paths:
>> -----------
>>    trunk/dports/x11/quartz-wm/
>>    trunk/dports/x11/quartz-wm/Portfile
>>
>> Added: trunk/dports/x11/quartz-wm/Portfile
>> ===================================================================
>> --- trunk/dports/x11/quartz-wm/Portfile	                         
>> (rev 0)
>> +++ trunk/dports/x11/quartz-wm/Portfile	2009-03-17 02:53:23 UTC  
>> (rev 48220)
>> @@ -0,0 +1,48 @@
>> +# $Id: Portfile 46927 2009-02-17 23:02:35Z jeremyhu at macports.org $
>> +
>> +PortSystem 1.0
>> +
>> +name		quartz-wm
>> +version		1.0.1
>> +categories	x11
>> +maintainers	jeremyhu openmaintainer
>> +description     Apple's Window Manager for X11
>> +homepage	http://xquartz.macosforge.org
>> +platforms	macosx
>> +long_description quartz-wm is Apple's closed source window-manager.
>> +master_sites	${homepage}/downloads
>> +
>> +distfiles	quartz-wm-${version}-Tiger.bz2 quartz-wm-${version}- 
>> Leopard.bz2
>
> You should modify this to only download the Tiger or Leopard  
> distfile, depending on whether the user is running Tiger or Leopard.  
> No point making everyone download both files.

Ok, I'll try that when I update it next.

>> +use_configure no
>> +extract         {
>> +	system "mkdir -p ${worksrcpath}"
>
> You could use
>
> xinstall -d ${worksrcpath}
>
> or I believe
>
> extract.mkdir yes

Ok, thanks for the heads up.

> Will the "Tiger" version work on Panther?

I'm not sure.   I built it against the 10.4u SDK... but it may or may  
not.  I never had a panther machine, so I don't even know what the X11  
on it looked like.

> Will the "Leopard" version work on Snow Leopard?

Yes.

> If so, then the naming is confusing...

Sorry.  I'm hoping to get around to pseudo-opensourcing quartz-wm  
(basically the nvidia driver model... some object files to hide  
internal bits but giving source for as much as possible)... so when  
that finally happens, this should be less of an issue.  Sorry.

> If not, then "platform darwin 8" and "platform darwin 9" blocks  
> would be more appropriate, and you may want to add a pre-fetch block  
> bailing out if the OS version won't work.

Honestly, I figured I'd put it out there and see if someone tells me  
that Panther fails.


From jeremyhu at macports.org  Fri Apr  3 21:07:22 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Fri, 3 Apr 2009 21:07:22 -0700
Subject: [49087] trunk/base/src/port1.0
In-Reply-To: <20090403113433.0476913FD9F0@beta.macosforge.org>
References: <20090403113433.0476913FD9F0@beta.macosforge.org>
Message-ID: <EFCDAACC-B8E8-460A-9FC9-22EBD88F2C26@macports.org>

With latest base:

Error: Unable to open port: Error evaluating variants
--->  Computing dependencies for xorg-server.Error: Error executing  
universal: invalid command name "configure_get_universal_system_name"
Error: Unable to upgrade port: Error evaluating variants

Looks like r49087 is incomplete

On Apr 3, 2009, at 04:34, raimue at macports.org wrote:

> Revision: 49087
>          http://trac.macports.org/changeset/49087
> Author:   raimue at macports.org
> Date:     2009-04-03 04:34:32 -0700 (Fri, 03 Apr 2009)
> Log Message:
> -----------
> port1.0:
> Create namespaces for the packages in port1.0, stop polluting the  
> global
> namespace with many local helper functions.
>
> Modified Paths:
> --------------
>    trunk/base/src/port1.0/portactivate.tcl
>    trunk/base/src/port1.0/portbuild.tcl
>    trunk/base/src/port1.0/portchecksum.tcl
>    trunk/base/src/port1.0/portclean.tcl
>    trunk/base/src/port1.0/portconfigure.tcl
>    trunk/base/src/port1.0/portdepends.tcl
>    trunk/base/src/port1.0/portdestroot.tcl
>    trunk/base/src/port1.0/portdistcheck.tcl
>    trunk/base/src/port1.0/portdistfiles.tcl
>    trunk/base/src/port1.0/portextract.tcl
>    trunk/base/src/port1.0/portfetch.tcl
>    trunk/base/src/port1.0/portinstall.tcl
>    trunk/base/src/port1.0/portlint.tcl
>    trunk/base/src/port1.0/portlivecheck.tcl
>    trunk/base/src/port1.0/portload.tcl
>    trunk/base/src/port1.0/portmain.tcl
>    trunk/base/src/port1.0/portmirror.tcl
>    trunk/base/src/port1.0/portpatch.tcl
>    trunk/base/src/port1.0/portstartupitem.tcl
>    trunk/base/src/port1.0/portsubmit.tcl
>    trunk/base/src/port1.0/porttest.tcl
>    trunk/base/src/port1.0/porttrace.tcl
>    trunk/base/src/port1.0/portunload.tcl
>    trunk/base/src/port1.0/portutil.tcl



From jmr at macports.org  Fri Apr  3 21:16:04 2009
From: jmr at macports.org (Joshua Root)
Date: Sat, 04 Apr 2009 15:16:04 +1100
Subject: [49087] trunk/base/src/port1.0
In-Reply-To: <EFCDAACC-B8E8-460A-9FC9-22EBD88F2C26@macports.org>
References: <20090403113433.0476913FD9F0@beta.macosforge.org>
	<EFCDAACC-B8E8-460A-9FC9-22EBD88F2C26@macports.org>
Message-ID: <49D6DF04.8050807@macports.org>

Jeremy Huddleston wrote:
> With latest base:
> 
> Error: Unable to open port: Error evaluating variants
> --->  Computing dependencies for xorg-server.Error: Error executing
> universal: invalid command name "configure_get_universal_system_name"
> Error: Unable to upgrade port: Error evaluating variants
> 
> Looks like r49087 is incomplete

Rainer forgot to test with +universal. Rest assured I let him know all
about it earlier today. :-)

This change actually exposed a circular dependency of sorts between
portconfigure and portutil. He said he'd look at it some more in the
morning.

- Josh

From raimue at macports.org  Sat Apr  4 00:20:38 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 04 Apr 2009 09:20:38 +0200
Subject: postfix +tls upgrade broken
In-Reply-To: <1D916FE9-5FA1-4321-A51B-946A0CDB8A39@geeklair.net>
References: <FA6D7086-54C4-4ED7-8173-AAC2E2DA62DD@pixilla.com>
	<49D543AE.4040601@macports.org>
	<1D916FE9-5FA1-4321-A51B-946A0CDB8A39@geeklair.net>
Message-ID: <49D70A46.9040909@macports.org>

On 2009-04-03 15:07, Daniel J. Luke wrote:
> On Apr 2, 2009, at 7:01 PM, Rainer M?ller wrote:
>> But in general, this is how the final update to openssl @1.0.0 will  
>> go.
>> Every dependent need to be rebuild as usually for every upgrade. Just
>> that in this case it will affect many ports and will probably cause  
>> much
>> confusion at first.
>>
>> I don't think there is a better solution currently than advising to  
>> run
>> 'sudo port -R upgrade openssl' when it is released, even if it will
>> probably trigger a lot of unnecessary rebuilds.
> 
> In the past, we have rev-bumped every port that we thought would need  
> a rebuild when we've done something like this...

For the readline @5.2 -> @6.0 upgrade I added additional symlinks to the
old libreadline.5.x.dylib paths. I tested it before with the ports
installed on my machine and as it worked for all of them I decided to go
that way. Might just have been coincidence that the versions were still
compatible... Maybe not the best solution, but it saved a lot of hassle.

Rainer

From raimue at macports.org  Sat Apr  4 12:01:56 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 04 Apr 2009 21:01:56 +0200
Subject: [49087] trunk/base/src/port1.0
In-Reply-To: <49D6DF04.8050807@macports.org>
References: <20090403113433.0476913FD9F0@beta.macosforge.org>
	<EFCDAACC-B8E8-460A-9FC9-22EBD88F2C26@macports.org>
	<49D6DF04.8050807@macports.org>
Message-ID: <49D7AEA4.6010804@macports.org>

On 2009-04-04 06:16, Joshua Root wrote:
> Jeremy Huddleston wrote:
>> With latest base:
>>
>> Error: Unable to open port: Error evaluating variants
>> --->  Computing dependencies for xorg-server.Error: Error executing
>> universal: invalid command name "configure_get_universal_system_name"
>> Error: Unable to upgrade port: Error evaluating variants
>>
>> Looks like r49087 is incomplete
> 
> Rainer forgot to test with +universal. Rest assured I let him know all
> about it earlier today. :-)

Oh yeah, I finally found it!

Unfortunately I did not test with +universal and did not realize the
muniversal port group is calling the procs
configure_get_universal_system_name and configure_main - which now moved
to the namespace so they are no longer accessible.

I committed a quick hack to make it work again in r49157.

> This change actually exposed a circular dependency of sorts between
> portconfigure and portutil. He said he'd look at it some more in the
> morning.

That's what I thought at first, as I assumed it was triggered by our
default universal variant which is defined in portutil. Scratch that ;-)

Rainer

From mcalhoun at macports.org  Sat Apr  4 12:56:03 2009
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Sat, 4 Apr 2009 19:56:03 +0000 (UTC)
Subject: [49158]
	=?utf-8?b?dHJ1bmsvZHBvcnRzL19yZXNvdXJjZXMvcG9ydDEuMC9ncm91cC9tdW5pdmVyc2FsLTEuMC50Y2w=?=
Message-ID: <loom.20090404T194101-520@post.gmane.org>


On Apr 4, 2009, at 3:31 PM, toby at macports.org wrote:
> Message
> More fixes to handle recent base change.
> Also, remove insanity from muniversal_get_arch_flag
> Modified Paths
> 	? trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl
>
...
>
>  proc muniversal_get_arch_flag {arch} {
>  -    global os.arch
>  -    # Prefer -m to -arch
> -    set archf "-arch ${arch}"
> -    if { ${os.arch}=="i386" && ${arch}=="i386" } {
> -        set archf -m32
> -    } elseif { ${os.arch}=="i386" && ${arch}=="x86_64" } {
> -        set archf -m64
> -    } elseif { ${os.arch}=="powerpc" && ${arch}=="ppc" } {
> -        set archf -m32
> -    } elseif { ${os.arch}=="powerpc" && ${arch}=="ppc64" } {
> -        set archf -m64
> -    }
> -    return ${archf}
>+    return "-arch ${arch}"
> }
 
Could you please explain why this change was made?
Why was the old way "insanity?"

The old way helped with endian issues.
See http://thread.gmane.org/gmane.os.apple.macports.devel/6859/focus=6862

It also made fortran use possible.
gfortran seems to work with -m64 but does not recognize -arch x86_64.

It also precludes the use of gcc-mp-* for building 32/64-bit universals.

-Marcus




From ryandesign at macports.org  Sun Apr  5 01:46:26 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 5 Apr 2009 03:46:26 -0500
Subject: postfix +tls upgrade broken
In-Reply-To: <49D70A46.9040909@macports.org>
References: <FA6D7086-54C4-4ED7-8173-AAC2E2DA62DD@pixilla.com>
	<49D543AE.4040601@macports.org>
	<1D916FE9-5FA1-4321-A51B-946A0CDB8A39@geeklair.net>
	<49D70A46.9040909@macports.org>
Message-ID: <9B7ECB22-3007-4D81-8A55-931050D1E7BF@macports.org>


On Apr 4, 2009, at 02:20, Rainer M?ller wrote:

> On 2009-04-03 15:07, Daniel J. Luke wrote:
>> On Apr 2, 2009, at 7:01 PM, Rainer M?ller wrote:
>>> But in general, this is how the final update to openssl @1.0.0 will
>>> go.
>>> Every dependent need to be rebuild as usually for every upgrade.  
>>> Just
>>> that in this case it will affect many ports and will probably cause
>>> much
>>> confusion at first.
>>>
>>> I don't think there is a better solution currently than advising to
>>> run
>>> 'sudo port -R upgrade openssl' when it is released, even if it will
>>> probably trigger a lot of unnecessary rebuilds.
>>
>> In the past, we have rev-bumped every port that we thought would need
>> a rebuild when we've done something like this...

Or written it up as a hot problem, e.g.:

http://trac.macports.org/wiki/ 
ProblemHotlist#Aportfailedtobuildupgradeorrunwithamessagereferringtolibi 
ntl.3.dylib


> For the readline @5.2 -> @6.0 upgrade I added additional symlinks  
> to the
> old libreadline.5.x.dylib paths. I tested it before with the ports
> installed on my machine and as it worked for all of them I decided  
> to go
> that way. Might just have been coincidence that the versions were  
> still
> compatible... Maybe not the best solution, but it saved a lot of  
> hassle.

I've been wary of that, in fact. The only reason I know of for  
upstream to use a new library version number is if it's not binary  
compatible with the old version, so I would think creating such a  
symlink would cause problems. Maybe in the case of readline there was  
something special, but I wouldn't expect that to work generally.


From blair at orcaware.com  Sun Apr  5 02:04:45 2009
From: blair at orcaware.com (Blair Zajac)
Date: Sun, 05 Apr 2009 02:04:45 -0700
Subject: postfix +tls upgrade broken
In-Reply-To: <9B7ECB22-3007-4D81-8A55-931050D1E7BF@macports.org>
References: <FA6D7086-54C4-4ED7-8173-AAC2E2DA62DD@pixilla.com>	<49D543AE.4040601@macports.org>	<1D916FE9-5FA1-4321-A51B-946A0CDB8A39@geeklair.net>	<49D70A46.9040909@macports.org>
	<9B7ECB22-3007-4D81-8A55-931050D1E7BF@macports.org>
Message-ID: <49D8742D.5060607@orcaware.com>

Ryan Schmidt wrote:
> 
> On Apr 4, 2009, at 02:20, Rainer M?ller wrote:
> 
>> On 2009-04-03 15:07, Daniel J. Luke wrote:
>>> On Apr 2, 2009, at 7:01 PM, Rainer M?ller wrote:
>>>> But in general, this is how the final update to openssl @1.0.0 will
>>>> go.
>>>> Every dependent need to be rebuild as usually for every upgrade. Just
>>>> that in this case it will affect many ports and will probably cause
>>>> much
>>>> confusion at first.
>>>>
>>>> I don't think there is a better solution currently than advising to
>>>> run
>>>> 'sudo port -R upgrade openssl' when it is released, even if it will
>>>> probably trigger a lot of unnecessary rebuilds.
>>>
>>> In the past, we have rev-bumped every port that we thought would need
>>> a rebuild when we've done something like this...
> 
> Or written it up as a hot problem, e.g.:
> 
> http://trac.macports.org/wiki/ProblemHotlist#Aportfailedtobuildupgradeorrunwithamessagereferringtolibintl.3.dylib 
> 
> 
> 
>> For the readline @5.2 -> @6.0 upgrade I added additional symlinks to the
>> old libreadline.5.x.dylib paths. I tested it before with the ports
>> installed on my machine and as it worked for all of them I decided to go
>> that way. Might just have been coincidence that the versions were still
>> compatible... Maybe not the best solution, but it saved a lot of hassle.
> 
> I've been wary of that, in fact. The only reason I know of for upstream 
> to use a new library version number is if it's not binary compatible 
> with the old version, so I would think creating such a symlink would 
> cause problems. Maybe in the case of readline there was something 
> special, but I wouldn't expect that to work generally.

Agreed.  It was lucky it worked, no telling which functions changed the ABI. 
See this for more information on library versioning:

http://apr.apache.org/versioning.html

Regards,
Blair

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

From david.osguthorpe at gmail.com  Sun Apr  5 10:01:04 2009
From: david.osguthorpe at gmail.com (David Osguthorpe)
Date: Sun, 5 Apr 2009 11:01:04 -0600
Subject: Cleaning up during uninstall and submitting Portfile
In-Reply-To: <49D4DFEA.4010509@macports.org>
References: <557f33430903310900s621c2476g3d23b7b6d85b60c8@mail.gmail.com>
	<DAAE2CE8-EFBE-4BCC-8BAF-6CC0E1007501@macports.org>
	<557f33430904020251k559ee9a9wa2d24a7aec6f08cc@mail.gmail.com>
	<70B865FD-78AF-425E-831A-C2759413B7E7@macports.org>
	<20090402143451.GA2645@mactelhm.local>
	<49D4DFEA.4010509@macports.org>
Message-ID: <20090405170104.GA1325@mactelhm.local>

> 
> Would you still care to send a patch? :-)
> 

patch sent as ticket 19176

note I kept as close as possible to the existing code and its variable names


David

From blair at orcaware.com  Sun Apr  5 12:17:03 2009
From: blair at orcaware.com (Blair Zajac)
Date: Sun, 05 Apr 2009 12:17:03 -0700
Subject: Moving X11 install into their own subdirectory
In-Reply-To: <A40ACA37-224E-4D09-A0A1-1CDEDBA0E3A5@macports.org>
References: <49BAFC2E.7040709@orcaware.com>
	<7DA5E02A-6F6F-4C8E-A733-A481C7FA0D91@macports.org>
	<49BC1E7D.6020900@orcaware.com>
	<2903A083-81ED-4B7F-9FC0-41077738128B@macports.org>
	<49BC78D0.2020808@orcaware.com>
	<5E04B33A-C349-41B6-AD76-D7B12FF5A5AE@macports.org>
	<49BFDFF5.50604@orcaware.com> <49BFECE6.5000106@orcaware.com>
	<8FCF4F42-CDA5-4AEC-8A5D-0A0E9B8142E8@macports.org>
	<A40ACA37-224E-4D09-A0A1-1CDEDBA0E3A5@macports.org>
Message-ID: <49D903AF.4030508@orcaware.com>

Ryan Schmidt wrote:
> On Mar 17, 2009, at 15:26, Jeremy Huddleston wrote:
> 
>> Why not just go one step further and actually rename the dylibs 
>> libZeroCIce.33.dylib and libZeroCIce.3.3.0.dylib?  That seems safer, 
>> easier, and less confusing.
> 
> +1. Seems that way to me too.
> 

I've updated the ice-cpp, ice-python and ice-python25 ports to create and use 
libZeroCIce.*, so the name conflict is now resolved.

Regards,
Blair

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

From allencmcbride at gmail.com  Sun Apr  5 12:24:29 2009
From: allencmcbride at gmail.com (Allen McBride)
Date: Sun, 5 Apr 2009 15:24:29 -0400
Subject: runtime vs build dependencies in making metapackages?
Message-ID: <D6B43D09-6C8B-4C30-826A-316347C02A1F@gmail.com>

In trying to make an mdmg for GNU Solfege, I first installed a clean  
copy of MacPorts, then used "port -f destroot solfege", which I now  
know was wrong.  But I counted 86 dependencies installed.  Then I did  
"port mdmg solfege", and counted 51 dependencies that MP tried (and  
failed, of course) to make packages of.

Now I know, or think I know, that the correct way to do this is to do  
"port -f destroot" for each dependency, and then "port mdmg solfege".   
But on which list do I use "port -f destroot", the 86 member list or  
the 51?  Is it that, in making a metapackage, I only need to worry  
about runtime dependencies, because build dependencies will already be  
included in the solfege binary?  And apparently I've got 51 runtime  
dependencies, and the rest are build deps?  That would all make sense  
to me, but I'm just speculating.

Thanks!
--Allen


From captsolo at gmail.com  Sun Apr  5 16:37:12 2009
From: captsolo at gmail.com (Uldis Bojars)
Date: Mon, 6 Apr 2009 00:37:12 +0100
Subject: Update to moin port
Message-ID: <64c81f720904051637o7f497cfdnbd49c715b80a6cc2@mail.gmail.com>

Could someone on the list update the moin port re. this ticket:
https://trac.macports.org/ticket/19099

The guide suggests it is ok to ask this if there has been no
maintainer action or reply for 3+ days.

Best,
Uldis

From blair at orcaware.com  Sun Apr  5 21:24:23 2009
From: blair at orcaware.com (Blair Zajac)
Date: Sun, 05 Apr 2009 21:24:23 -0700
Subject: Updating hg-forest
Message-ID: <49D983F7.5010107@orcaware.com>

Should we upate hg-forest to what looks like the latest release at:

http://www.bitbucket.org/pmezard/hgforest-crew/overview/

This page says it's where to find versions for 1.0+

http://www.selenic.com/mercurial/wiki/index.cgi/ForestExtension

And this blog says says to use it

http://infernus.org/2009/02/building-java-7-on-mac-os-x/

Regards,
Blair

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

From blb at macports.org  Mon Apr  6 00:04:20 2009
From: blb at macports.org (Bryan Blackburn)
Date: Mon, 6 Apr 2009 01:04:20 -0600
Subject: Updating hg-forest
In-Reply-To: <49D983F7.5010107@orcaware.com>
References: <49D983F7.5010107@orcaware.com>
Message-ID: <20090406070420.GI16255@ninagal.withay.com>

On Sun, Apr 05, 2009 at 09:24:23PM -0700, Blair Zajac said:
> Should we upate hg-forest to what looks like the latest release at:
>
> http://www.bitbucket.org/pmezard/hgforest-crew/overview/
>
> This page says it's where to find versions for 1.0+
>
> http://www.selenic.com/mercurial/wiki/index.cgi/ForestExtension
>
> And this blog says says to use it
>
> http://infernus.org/2009/02/building-java-7-on-mac-os-x/

The port is actually using the one from bitbucket (but it simply sits in
files/ for simplicity).  However it does appear to be a few months out of
date, so updated in r49248; thanks for the reminder.

Bryan


>
> Regards,
> 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  Mon Apr  6 00:57:52 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 6 Apr 2009 02:57:52 -0500
Subject: [49117] trunk/dports/print/freetype/Portfile
In-Reply-To: <20090404052330.3A5CD14087AD@beta.macosforge.org>
References: <20090404052330.3A5CD14087AD@beta.macosforge.org>
Message-ID: <84CBB5AE-FAD8-4D4A-94D5-F7F924D462DC@macports.org>

On Apr 4, 2009, at 00:23, mcalhoun at macports.org wrote:

> Revision: 49117
>           http://trac.macports.org/changeset/49117
> Author:   mcalhoun at macports.org
> Date:     2009-04-03 22:23:29 -0700 (Fri, 03 Apr 2009)
> Log Message:
> -----------
> freetype: Use muniversal PortGroup for universal builds
> so that header file ftconfig.h has correct values.
> Fixes #19101 (maintainer timeout).

Sorry I didn't have time to evaluate your proposal before. Thanks for  
taking care of it.

[snip]

> +if { ${os.arch}=="i386" } {
> +    if { ${os.major}>=10 } {
> +        set merger_configure_env(ppc) CC_BUILD=${configure.cc}
> +    }
> +    set merger_configure_env(ppc64)   CC_BUILD=${configure.cc}
> +} else {
> +    set merger_configure_env(i386)    CC_BUILD=${configure.cc}
> +    set merger_configure_env(x86_64)  CC_BUILD=${configure.cc}
> +}


I don't understand what these lines are for. Could you explain? Why  
is this environment variable only required on these specific OS/arch  
combinations, and/or why are they detrimental on the other OS/arch  
combinations?



From mcalhoun at macports.org  Mon Apr  6 01:23:52 2009
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Mon, 6 Apr 2009 08:23:52 +0000 (UTC)
Subject: [49117] trunk/dports/print/freetype/Portfile
References: <20090404052330.3A5CD14087AD@beta.macosforge.org>
	<84CBB5AE-FAD8-4D4A-94D5-F7F924D462DC@macports.org>
Message-ID: <loom.20090406T080248-880@post.gmane.org>

Ryan Schmidt <ryandesign at ...> writes:

> > +if { ${os.arch}=="i386" } {
> > +    if { ${os.major}>=10 } {
> > +        set merger_configure_env(ppc) CC_BUILD=${configure.cc}
> > +    }
> > +    set merger_configure_env(ppc64)   CC_BUILD=${configure.cc}
> > +} else {
> > +    set merger_configure_env(i386)    CC_BUILD=${configure.cc}
> > +    set merger_configure_env(x86_64)  CC_BUILD=${configure.cc}
> > +}
> 
> I don't understand what these lines are for. Could you explain? Why  
> is this environment variable only required on these specific OS/arch  
> combinations, and/or why are they detrimental on the other OS/arch  
> combinations?
> 

CC_BUILD is only needed when cross-compiling.
For what purpose, I can not say, but it seems to need a compiler
which builds binaries to run on the build architecture.

When not cross-compiling, the configure script happily sets CC_BUILD to CC.

I do not know if setting CC_BUILD is detrimental to regular builds, but my policy
has been to make the smallest possible change to the build process
to get universal to work (especially the ports of others).
This minimizes the chances of breaking the regular build.

-Marcus




From ryandesign at macports.org  Mon Apr  6 04:44:12 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 6 Apr 2009 06:44:12 -0500
Subject: runtime vs build dependencies in making metapackages?
In-Reply-To: <D6B43D09-6C8B-4C30-826A-316347C02A1F@gmail.com>
References: <D6B43D09-6C8B-4C30-826A-316347C02A1F@gmail.com>
Message-ID: <399DC5DD-A058-4647-BF00-4CF25071AD07@macports.org>


On Apr 5, 2009, at 14:24, Allen McBride wrote:

> In trying to make an mdmg for GNU Solfege, I first installed a  
> clean copy of MacPorts, then used "port -f destroot solfege", which  
> I now know was wrong.  But I counted 86 dependencies installed.   
> Then I did "port mdmg solfege", and counted 51 dependencies that MP  
> tried (and failed, of course) to make packages of.
>
> Now I know, or think I know, that the correct way to do this is to  
> do "port -f destroot" for each dependency, and then "port mdmg  
> solfege".  But on which list do I use "port -f destroot", the 86  
> member list or the 51?  Is it that, in making a metapackage, I only  
> need to worry about runtime dependencies, because build  
> dependencies will already be included in the solfege binary?  And  
> apparently I've got 51 runtime dependencies, and the rest are build  
> deps?  That would all make sense to me, but I'm just speculating.

I haven't used "port mdmg" myself so I can't advise you specifically  
for that.

I can explain that a port's build dependencies are only needed to  
build the software, not to run it. Therefore, there's no reason to  
include build dependencies into the binary mdmg package.



From afb at macports.org  Mon Apr  6 05:21:53 2009
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Mon, 6 Apr 2009 14:21:53 +0200
Subject: runtime vs build dependencies in making metapackages?
In-Reply-To: <399DC5DD-A058-4647-BF00-4CF25071AD07@macports.org>
References: <D6B43D09-6C8B-4C30-826A-316347C02A1F@gmail.com>
	<399DC5DD-A058-4647-BF00-4CF25071AD07@macports.org>
Message-ID: <DEAFF40B-878C-4A53-AC03-4EA0946B19A5@macports.org>

  Ryan Schmidt:

>> Now I know, or think I know, that the correct way to do this is to  
>> do "port -f destroot" for each dependency, and then "port mdmg  
>> solfege".  But on which list do I use "port -f destroot", the 86  
>> member list or the 51?  Is it that, in making a metapackage, I  
>> only need to worry about runtime dependencies, because build  
>> dependencies will already be included in the solfege binary?  And  
>> apparently I've got 51 runtime dependencies, and the rest are  
>> build deps?  That would all make sense to me, but I'm just  
>> speculating.
>
> I haven't used "port mdmg" myself so I can't advise you  
> specifically for that.
>
> I can explain that a port's build dependencies are only needed to  
> build the software, not to run it. Therefore, there's no reason to  
> include build dependencies into the binary mdmg package.

And of course one shouldn't _need_ to do port -f destroot in the  
first place either, it's just a workaround to the portautoclean  
default and Ticket #10881...

The trick is to disable "autoclean" before it empties all of the  
ports destroot, otherwise you need to rebuild everything unless you  
also enabled "archivemode".


# Set whether to automatically execute "clean" after "install" of ports
portautoclean           no

# Create and use binary archive packages for installation/ 
reinstallation ease
portarchivemode         yes

--anders


From allencmcbride at gmail.com  Mon Apr  6 08:31:56 2009
From: allencmcbride at gmail.com (Allen McBride)
Date: Mon, 6 Apr 2009 11:31:56 -0400
Subject: runtime vs build dependencies in making metapackages?
In-Reply-To: <DEAFF40B-878C-4A53-AC03-4EA0946B19A5@macports.org>
References: <D6B43D09-6C8B-4C30-826A-316347C02A1F@gmail.com>
	<399DC5DD-A058-4647-BF00-4CF25071AD07@macports.org>
	<DEAFF40B-878C-4A53-AC03-4EA0946B19A5@macports.org>
Message-ID: <79F53A9C-FC3F-4900-B320-4E4584C4F4DA@gmail.com>

Thanks!  So what I need to do is:

1) uninstall all the ports I installed with the default settings  
(portautoclean yes and portarchivemode no)
2) set "portautoclean no" in ${prefix}/etc/macports/macports.conf
3) also set "portarchivemode yes" in the the same file
4) run "port mdmg solfege" (no need to do port -f destroot anymore  
because of the last two steps)

Do I have that right? Or is step #3 redundant to step #2?

--Allen


On Apr 6, 2009, at 8:21 AM, Anders F Bj?rklund wrote:

> Ryan Schmidt:
>
>>> Now I know, or think I know, that the correct way to do this is to  
>>> do "port -f destroot" for each dependency, and then "port mdmg  
>>> solfege".  But on which list do I use "port -f destroot", the 86  
>>> member list or the 51?  Is it that, in making a metapackage, I  
>>> only need to worry about runtime dependencies, because build  
>>> dependencies will already be included in the solfege binary?  And  
>>> apparently I've got 51 runtime dependencies, and the rest are  
>>> build deps?  That would all make sense to me, but I'm just  
>>> speculating.
>>
>> I haven't used "port mdmg" myself so I can't advise you  
>> specifically for that.
>>
>> I can explain that a port's build dependencies are only needed to  
>> build the software, not to run it. Therefore, there's no reason to  
>> include build dependencies into the binary mdmg package.
>
> And of course one shouldn't _need_ to do port -f destroot in the  
> first place either, it's just a workaround to the portautoclean  
> default and Ticket #10881...
>
> The trick is to disable "autoclean" before it empties all of the  
> ports destroot, otherwise you need to rebuild everything unless you  
> also enabled "archivemode".
>
>
> # Set whether to automatically execute "clean" after "install" of  
> ports
> portautoclean           no
>
> # Create and use binary archive packages for installation/ 
> reinstallation ease
> portarchivemode         yes
>
> --anders
>


From blair at orcaware.com  Mon Apr  6 18:26:38 2009
From: blair at orcaware.com (Blair Zajac)
Date: Mon, 06 Apr 2009 18:26:38 -0700
Subject: Updating hg-forest
In-Reply-To: <20090406070420.GI16255@ninagal.withay.com>
References: <49D983F7.5010107@orcaware.com>
	<20090406070420.GI16255@ninagal.withay.com>
Message-ID: <49DAABCE.2070305@orcaware.com>

Bryan Blackburn wrote:
> On Sun, Apr 05, 2009 at 09:24:23PM -0700, Blair Zajac said:
>> Should we upate hg-forest to what looks like the latest release at:
>>
>> http://www.bitbucket.org/pmezard/hgforest-crew/overview/
>>
>> This page says it's where to find versions for 1.0+
>>
>> http://www.selenic.com/mercurial/wiki/index.cgi/ForestExtension
>>
>> And this blog says says to use it
>>
>> http://infernus.org/2009/02/building-java-7-on-mac-os-x/
> 
> The port is actually using the one from bitbucket (but it simply sits in
> files/ for simplicity).  However it does appear to be a few months out of
> date, so updated in r49248; thanks for the reminder.

Sweet, thanks.

Blair

From loshea at gmail.com  Mon Apr  6 18:36:50 2009
From: loshea at gmail.com (Luis O'Shea)
Date: Mon, 6 Apr 2009 21:36:50 -0400
Subject: Port update needs commit
Message-ID: <0AB0E01A-C13F-4759-8BBB-5407406AA84F@gmail.com>

The asymptote port has an update that needs committing.  See https:// 
trac.macports.org/ticket/19104

Thanks,

Luis

From ryandesign at macports.org  Tue Apr  7 04:11:42 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 7 Apr 2009 06:11:42 -0500
Subject: [49311] trunk/dports/lang
In-Reply-To: <20090407110650.B6826144A1A3@beta.macosforge.org>
References: <20090407110650.B6826144A1A3@beta.macosforge.org>
Message-ID: <9730EFC1-C1CC-4419-8759-AEDF4FD27FF6@macports.org>

On Apr 7, 2009, at 06:06, gwright at macports.org wrote:

> Revision: 49311
>           http://trac.macports.org/changeset/49311
> Author:   gwright at macports.org
> Date:     2009-04-07 04:06:49 -0700 (Tue, 07 Apr 2009)
> Log Message:
> -----------
> New port: Clozure Common Lisp, version 1.3-RC1.
> This replaces OpenMCL, which was renamed to avoid confusion
> with a similarly named commercial product.  The 1.3 release
> supports x86 and x86_64 architectures, as well as ppc
> and ppc64.

[snip]

> +platform darwin i386 {
> +	svn.url	http://svn.clozure.com/publicsvn/openmcl/release/$ 
> {shortversion}/darwinx86/ccl
> +	global bootimg
> +	set bootimg dx86cl
> +
> +	global ccl_script
> +	set ccl_script ccl
> +}
> +
> +platform darwin x86_64 {
> +	svn.url	http://svn.clozure.com/publicsvn/openmcl/release/$ 
> {shortversion}/darwinx86/ccl
> +	global bootimg
> +	set bootimg dx86cl64
> +
> +	global ccl_script
> +	set ccl_script ccl64
> +}
> +
> +platform darwin ppc {
> +	svn.url	http://svn.clozure.com/publicsvn/openmcl/release/$ 
> {shortversion}/darwinpcc/ccl
> +	global bootimg
> +	set bootimg dppccl
> +
> +	global ccl_script
> +	set ccl_script ccl
> +}
> +
> +platform darwin ppc64 {
> +	svn.url	http://svn.clozure.com/publicsvn/openmcl/release/$ 
> {shortversion}/darwinppc/ccl
> +	global bootimg
> +	set bootimg dppccl64
> +
> +	global ccl_script
> +	set ccl_script ccl64
> +}


[snip]

MacPorts doesn't have any x86_64, ppc, or ppc64 platform selectors;  
it only has i386 and powerpc. MacPorts only builds 32-bit software,  
unless the user modifies macports.conf and requests 64-bit  
architectures in universal_archs and builds the port universal.



From jmr at macports.org  Tue Apr  7 05:09:08 2009
From: jmr at macports.org (Joshua Root)
Date: Tue, 07 Apr 2009 22:09:08 +1000
Subject: [49311] trunk/dports/lang
In-Reply-To: <9730EFC1-C1CC-4419-8759-AEDF4FD27FF6@macports.org>
References: <20090407110650.B6826144A1A3@beta.macosforge.org>
	<9730EFC1-C1CC-4419-8759-AEDF4FD27FF6@macports.org>
Message-ID: <49DB4264.2040009@macports.org>

Ryan Schmidt wrote:
> MacPorts doesn't have any x86_64, ppc, or ppc64 platform selectors; it
> only has i386 and powerpc. MacPorts only builds 32-bit software, unless
> the user modifies macports.conf and requests 64-bit architectures in
> universal_archs and builds the port universal.

OTOH, that should probably change...

- Josh

From raimue at macports.org  Tue Apr  7 07:06:35 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Tue, 07 Apr 2009 16:06:35 +0200
Subject: [49158] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl
In-Reply-To: <loom.20090404T194101-520@post.gmane.org>
References: <loom.20090404T194101-520@post.gmane.org>
Message-ID: <49DB5DEB.7020701@macports.org>

On 2009-04-04 21:56, Marcus Calhoun-Lopez wrote:
> On Apr 4, 2009, at 3:31 PM, toby at macports.org wrote:
>> Message
>> More fixes to handle recent base change.
>> Also, remove insanity from muniversal_get_arch_flag
>> Modified Paths
>> 	? trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl
>>
> ...
>>  proc muniversal_get_arch_flag {arch} {
>>  -    global os.arch
>>  -    # Prefer -m to -arch
>> -    set archf "-arch ${arch}"
>> -    if { ${os.arch}=="i386" && ${arch}=="i386" } {
>> -        set archf -m32
>> -    } elseif { ${os.arch}=="i386" && ${arch}=="x86_64" } {
>> -        set archf -m64
>> -    } elseif { ${os.arch}=="powerpc" && ${arch}=="ppc" } {
>> -        set archf -m32
>> -    } elseif { ${os.arch}=="powerpc" && ${arch}=="ppc64" } {
>> -        set archf -m64
>> -    }
>> -    return ${archf}
>> +    return "-arch ${arch}"
>> }
>  
> Could you please explain why this change was made?
> Why was the old way "insanity?"
> 
> The old way helped with endian issues.
> See http://thread.gmane.org/gmane.os.apple.macports.devel/6859/focus=6862
> 
> It also made fortran use possible.
> gfortran seems to work with -m64 but does not recognize -arch x86_64.
> 
> It also precludes the use of gcc-mp-* for building 32/64-bit universals.

Although -arch seems to be easier, you have a valid point.

By the way, what is the current status of muniversal? I see you are
converting more and more ports to use it. Is it ready yet to be
integrated into base?

Rainer

From jeremy at lavergne.gotdns.org  Tue Apr  7 07:59:57 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Tue, 7 Apr 2009 10:59:57 -0400
Subject: yacc/bison
Message-ID: <AAEDB847-EF6D-4177-B257-8613D71BBAEE@lavergne.gotdns.org>

I have a port that is using yacc.  Like g++/gcc, it can use the system  
ones without a problem.  Should this not be marked as a dependency then?

If not, what ports provide bin/yacc besides bison +yacc?  It is my  
understanding we can't dictate variants yet, so I'd like a better  
solution than printing a ui_msg.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2435 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090407/aa6acc9c/attachment.bin>

From dweber at macports.org  Tue Apr  7 12:57:02 2009
From: dweber at macports.org (Darren Weber)
Date: Tue, 7 Apr 2009 12:57:02 -0700
Subject: python path configuration
Message-ID: <b808b3510904071257n7429fdddp8d8da0df8ab36fe2@mail.gmail.com>

I am doing some manual testing of the build and install for VTK 5.4, which
has python wrapping.  In the course of this testing, I've stumbled across an
installation issue with python 2.6.  I can't proceed without knowing more
about this should be handled within macports.  Any advice and pointers to
more information would be really handy!

FYI
http://peak.telecommunity.com/DevCenter/EasyInstall#custom-installation-locations

I was pointed to this link during a manual installation of VTK 5.4 (with
python wrapping), ie:

-- Installing: /opt/local/bin/vtkpython
running cd "/Users/dweber/src/kitware/VTK_build/Wrapping/Python" &&
/opt/local/bin/python2.6 setup.py install --prefix="/opt/local"  2>&1
running install
Checking .pth file support in /opt/local/lib/python2.6/site-packages/
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python
-E -c pass
TEST FAILED: /opt/local/lib/python2.6/site-packages/ does NOT support .pth
files
error: bad install directory or PYTHONPATH

You are attempting to install a package to a directory that is not
on PYTHONPATH and which Python does not read ".pth" files from.  The
installation directory you specified (via --install-dir, --prefix, or
the distutils default setting) was:

    /opt/local/lib/python2.6/site-packages/

and your PYTHONPATH environment variable currently contains:

    ''

Here are some of your options for correcting the problem:

* You can choose a different installation directory, i.e., one that is
  on PYTHONPATH or supports .pth files

* You can add the installation directory to the PYTHONPATH environment
  variable.  (It must then also be on PYTHONPATH whenever you run
  Python and want to use the package(s) you are installing.)

* You can set up the installation directory to support ".pth" files by
  using one of the approaches described here:


http://peak.telecommunity.com/EasyInstall.html#custom-installation-locations

Please make the appropriate changes for your system and try again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090407/2b0ed302/attachment.html>

From dweber at macports.org  Tue Apr  7 13:35:54 2009
From: dweber at macports.org (Darren Weber)
Date: Tue, 7 Apr 2009 13:35:54 -0700
Subject: WWDC meeting?
Message-ID: <b808b3510904071335n30420110y1f09bc8052dd3d58@mail.gmail.com>

I'm fairly new to macports development (only joined last year).  I'm
wondering if there are any 'in-person' meetings?

I've been asked by my employer to attend the Apple WWDC, and I wonder if
other macport developers are also attending?  Perhaps it would be an
opportunity to meet over lunch, dinner, drinks to discuss macports?

Best, Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090407/89868f40/attachment.html>

From blb at macports.org  Tue Apr  7 13:38:35 2009
From: blb at macports.org (Bryan Blackburn)
Date: Tue, 7 Apr 2009 14:38:35 -0600
Subject: python path configuration
In-Reply-To: <b808b3510904071257n7429fdddp8d8da0df8ab36fe2@mail.gmail.com>
References: <b808b3510904071257n7429fdddp8d8da0df8ab36fe2@mail.gmail.com>
Message-ID: <20090407203835.GC2737@ninagal.withay.com>

On Tue, Apr 07, 2009 at 12:57:02PM -0700, Darren Weber said:
> I am doing some manual testing of the build and install for VTK 5.4, which
> has python wrapping.  In the course of this testing, I've stumbled across an
> installation issue with python 2.6.  I can't proceed without knowing more
> about this should be handled within macports.  Any advice and pointers to
> more information would be really handy!

Try setting PYTHONPATH to python.prefix (which is defined in the python
groups), ${frameworks_dir}/Python.framework/Versions/${python.branch} (where
python.branch would be 2.6 in this case).  So something like

configure.env PYTHONPATH="${frameworks_dir}/Python.framework/Versions/2.6"

Since there is no ${prefix}/lib/python2.6 and hence no site-packages under
that, if you can't specify the python prefix separately, using PYTHONPATH
seems like it may work.  And in case anyone asks, using a symlink in
${prefix}/lib for python2.6 won't work or we'll run into the python25 issue
of 'not a directory'.

Bryan

[...]


From toby at macports.org  Tue Apr  7 14:06:16 2009
From: toby at macports.org (Toby Peterson)
Date: Tue, 7 Apr 2009 14:06:16 -0700
Subject: WWDC meeting?
In-Reply-To: <b808b3510904071335n30420110y1f09bc8052dd3d58@mail.gmail.com>
References: <b808b3510904071335n30420110y1f09bc8052dd3d58@mail.gmail.com>
Message-ID: <74c219d30904071406i63cc5d44m57ef75a4721ef2ab@mail.gmail.com>

On Tue, Apr 7, 2009 at 13:35, Darren Weber <dweber at macports.org> wrote:
> I'm fairly new to macports development (only joined last year).? I'm
> wondering if there are any 'in-person' meetings?
>
> I've been asked by my employer to attend the Apple WWDC, and I wonder if
> other macport developers are also attending?? Perhaps it would be an
> opportunity to meet over lunch, dinner, drinks to discuss macports?

I will be there.

- Toby

From wsiegrist at apple.com  Tue Apr  7 14:18:34 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Tue, 07 Apr 2009 14:18:34 -0700
Subject: WWDC meeting?
In-Reply-To: <b808b3510904071335n30420110y1f09bc8052dd3d58@mail.gmail.com>
References: <b808b3510904071335n30420110y1f09bc8052dd3d58@mail.gmail.com>
Message-ID: <660DFB5A-47C5-4661-9F69-90173CD7E957@apple.com>

On Apr 7, 2009, at 1:35 PM, Darren Weber wrote:

>
> I'm fairly new to macports development (only joined last year).  I'm  
> wondering if there are any 'in-person' meetings?
>
> I've been asked by my employer to attend the Apple WWDC, and I  
> wonder if other macport developers are also attending?  Perhaps it  
> would be an opportunity to meet over lunch, dinner, drinks to  
> discuss macports?
>


I'll be staffing the sysadmin labs most likely and hanging out the  
rest of those days.

-Bill

From mcalhoun at macports.org  Tue Apr  7 16:14:28 2009
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Tue, 7 Apr 2009 23:14:28 +0000 (UTC)
Subject: [49158]
	=?utf-8?b?dHJ1bmsvZHBvcnRzL19yZXNvdXJjZXMvcG9ydDEuMC9ncm91cC9tdW5pdmVyc2FsLTEuMC50Y2w=?=
References: <loom.20090404T194101-520@post.gmane.org>
	<49DB5DEB.7020701@macports.org>
Message-ID: <loom.20090407T193956-989@post.gmane.org>

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

> By the way, what is the current status of muniversal? I see you are
> converting more and more ports to use it. Is it ready yet to be
> integrated into base?

I have already attempted to create some patches to be incorporated
into the base.
One stumbling block is my unfamiliarity with the base code, so the
patches are not very good yet.

I would say that the strategy (separate compilations for each architecture)
has been doing well.
It has uncovered some bugs which would have been difficult to track down
otherwise.
As you might expect, they often have to do with size of data types.

I will keep trying.

-Marcus





From raimue at macports.org  Tue Apr  7 16:49:06 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Wed, 08 Apr 2009 01:49:06 +0200
Subject: [MacPorts] #19232: RFE: Have gdbm use the muniversal PortGroup
In-Reply-To: <057.15906d118c5e4616d899e27efbfdfe3a@macports.org>
References: <057.15906d118c5e4616d899e27efbfdfe3a@macports.org>
Message-ID: <49DBE672.4090002@macports.org>

On 2009-04-07 21:36, MacPorts wrote:
> #19232: RFE: Have gdbm use the muniversal PortGroup
> -----------------------------------+----------------------------------------
>  Reporter:  mcalhoun@?             |       Owner:  digdog@?           
>      Type:  enhancement            |      Status:  new                
>  Priority:  Normal                 |   Milestone:  Port Enhancements  
> Component:  ports                  |     Version:  1.7.1              
>  Keywords:  universal              |        Port:  gdbm               
> -----------------------------------+----------------------------------------
>  Attached is a proposed change to gdbm to use the muniversal
>  PortGroup.[[BR]]
>  There is no apparent error with the old way, but muniversal is a safer
>  option.

In my opinion there is no point in using muniversal if the existing
default variant already works. What would be the benefit of using that?
It just clutters the Portfile and makes it less readable.

Rainer


From raimue at macports.org  Tue Apr  7 16:51:40 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Wed, 08 Apr 2009 01:51:40 +0200
Subject: [MacPorts] #18685: `autocd' `checkjobs' `globstar' `>>&' variants
	for bash-4
In-Reply-To: <BFCF3A49-112C-4CD3-9348-9FF8A720C3A9@googlemail.com>
References: <060.eba95210b08551dbcda9a2e42c979a4e@macports.org>
	<069.80625a162cbd2469ccef1c13281df570@macports.org>
	<BFCF3A49-112C-4CD3-9348-9FF8A720C3A9@googlemail.com>
Message-ID: <49DBE70C.1090000@macports.org>

On 2009-04-07 23:47, Charles Darwin wrote:
> On 7-Apr-09, at 1:01 PM, MacPorts wrote:
> 
>> do you want to add a `${prefix}/etc/bashrc` which enabled these
>> features?
> 
> That wasn't my intention but it would be nice to have that. Also I  
> think a revised man page or some documention of how compile options  
> are used by `port' would be helpful. Please let me if there already  
> exist such a reading already available that I am not aware of.

I don't understand your question. The features you mentioned are
standard features of bash 4.0 and are always available without any
additional configure flags. So I don't know what kind of documentation
you are looking for.

Rainer

From dweber at macports.org  Tue Apr  7 16:59:36 2009
From: dweber at macports.org (Darren Weber)
Date: Tue, 7 Apr 2009 16:59:36 -0700
Subject: WWDC meeting?
In-Reply-To: <660DFB5A-47C5-4661-9F69-90173CD7E957@apple.com>
References: <b808b3510904071335n30420110y1f09bc8052dd3d58@mail.gmail.com>
	<660DFB5A-47C5-4661-9F69-90173CD7E957@apple.com>
Message-ID: <b808b3510904071659m151dd76o2fc53df741288993@mail.gmail.com>

Suggestions on a time and venue to hang out?


On Tue, Apr 7, 2009 at 2:18 PM, William Siegrist <wsiegrist at apple.com>wrote:

> On Apr 7, 2009, at 1:35 PM, Darren Weber wrote:
>
>
>> I'm fairly new to macports development (only joined last year).  I'm
>> wondering if there are any 'in-person' meetings?
>>
>> I've been asked by my employer to attend the Apple WWDC, and I wonder if
>> other macport developers are also attending?  Perhaps it would be an
>> opportunity to meet over lunch, dinner, drinks to discuss macports?
>>
>>
>
> I'll be staffing the sysadmin labs most likely and hanging out the rest of
> those days.
>
> -Bill
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090407/bfd7b7be/attachment.html>

From mcalhoun at macports.org  Tue Apr  7 17:04:52 2009
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Wed, 8 Apr 2009 00:04:52 +0000 (UTC)
Subject: [MacPorts] #19232: RFE: Have gdbm use the muniversal PortGroup
References: <057.15906d118c5e4616d899e27efbfdfe3a@macports.org>
	<49DBE672.4090002@macports.org>
Message-ID: <loom.20090408T000414-307@post.gmane.org>

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

> In my opinion there is no point in using muniversal if the existing
> default variant already works. What would be the benefit of using that?
> It just clutters the Portfile and makes it less readable.

The default universal variant works for gdbm as far as I can tell,
but the muniversal PortGroup is much better at catching problems
than I am.

mpfr, for example, builds differently with muniversal than the default
because of a variable HAVE_LDOUBLE_IEEE_EXT_LITTLE.
This would have been extremely difficult to have found without separate builds.

The strategy employed by muniversal (separate builds for each architectures)
takes much of the tedium out of finding problems in universal builds.

-Marcus




From blb at macports.org  Tue Apr  7 17:37:11 2009
From: blb at macports.org (Bryan Blackburn)
Date: Tue, 7 Apr 2009 18:37:11 -0600
Subject: [49330] trunk/dports/databases
In-Reply-To: <20090407181834.2C67E146269C@beta.macosforge.org>
References: <20090407181834.2C67E146269C@beta.macosforge.org>
Message-ID: <20090408003711.GI2737@ninagal.withay.com>

On Tue, Apr 07, 2009 at 11:18:21AM -0700, raimue at macports.org said:
> Revision: 49330
>           http://trac.macports.org/changeset/49330
> Author:   raimue at macports.org
> Date:     2009-04-07 11:18:04 -0700 (Tue, 07 Apr 2009)
> Log Message:
> -----------
> databases/postgresql-devel, databases/postgresql-server-devel:
> New ports, tracking upcoming postgresql releases. Closes #18855
[...]
> +
> +name			postgresql-devel
> +version			devel

The version is 'devel'?  Does that mean each time it needs to be updated,
the revision will be increased, so it is devel_0, devel_1, etc?  Otherwise
this should probably use something which increments and is logical, like the
date being used in cvs.date, eg

version   20090313

Then increasing the version will make much more sense.

Bryan

[...]


From raimue at macports.org  Tue Apr  7 18:02:29 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Wed, 08 Apr 2009 03:02:29 +0200
Subject: [49330] trunk/dports/databases
In-Reply-To: <20090408003711.GI2737@ninagal.withay.com>
References: <20090407181834.2C67E146269C@beta.macosforge.org>
	<20090408003711.GI2737@ninagal.withay.com>
Message-ID: <49DBF7A5.3020600@macports.org>

On 2009-04-08 02:37, Bryan Blackburn wrote:
> The version is 'devel'?  Does that mean each time it needs to be updated,
> the revision will be increased, so it is devel_0, devel_1, etc?  Otherwise
> this should probably use something which increments and is logical, like the
> date being used in cvs.date, eg
> 
> version   20090313
> 
> Then increasing the version will make much more sense.

You are absolutely right. Sorry, I missed the version when committing
the Portfiles.

Does cvs accept ISO dates in YYYY-MM-DD format? If so, this would work:

  version 20090313
  cvs.date "[string range $version 0 3]-[string range $version 4
5]-[string range $version 6 7]"

Rainer

From ryandesign at macports.org  Tue Apr  7 21:45:01 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 7 Apr 2009 23:45:01 -0500
Subject: yacc/bison
In-Reply-To: <AAEDB847-EF6D-4177-B257-8613D71BBAEE@lavergne.gotdns.org>
References: <AAEDB847-EF6D-4177-B257-8613D71BBAEE@lavergne.gotdns.org>
Message-ID: <DC168FB6-C464-4454-BAD9-DDD94453FD04@macports.org>


On Apr 7, 2009, at 09:59, Jeremy Lavergne wrote:

> I have a port that is using yacc.  Like g++/gcc, it can use the  
> system ones without a problem.  Should this not be marked as a  
> dependency then?

I suggest declaring a dependency on the bison port. I do this in my  
pure/pure-devel ports which need bison. This way, you won't be  
confused later when differences arise between the system bison and  
the MacPorts bison; you can be assured all users are using the  
MacPorts bison.

> If not, what ports provide bin/yacc besides bison +yacc?  It is my  
> understanding we can't dictate variants yet, so I'd like a better  
> solution than printing a ui_msg.

True. But:

The +yacc variant doesn't make bison take longer to build [1]. It  
doesn't add any dependencies. All it does is install a static library  
liby.a and install a wrapper script "yacc" which calls "bison -y".

The +yacc variant was added to the bison port in r10216 when it was  
updated to version 2.0. No explanation why it was a variant instead  
of always on.

This sounds like a great example of where we should remove the  
variant and have bison always include yacc support.



[1]

$ time port install bison +yacc
--->  Fetching bison
--->  Verifying checksum(s) for bison
--->  Extracting bison
--->  Configuring bison
--->  Building bison
--->  Staging bison into destroot
--->  Installing bison @2.4.1_0+yacc
--->  Activating bison @2.4.1_0+yacc
--->  Cleaning bison

real    0m46.056s
user    0m24.097s
sys     0m16.667s
$ port deactivate bison
--->  Deactivating bison
$ time port install bison
--->  Fetching bison
--->  Verifying checksum(s) for bison
--->  Extracting bison
--->  Configuring bison
--->  Building bison
--->  Staging bison into destroot
--->  Installing bison @2.4.1_0
--->  Activating bison @2.4.1_0
--->  Cleaning bison

real    0m44.871s
user    0m24.013s
sys     0m16.512s
$



From mww at macports.org  Wed Apr  8 00:33:16 2009
From: mww at macports.org (Markus Weissmann)
Date: Wed, 8 Apr 2009 09:33:16 +0200
Subject: yacc/bison
In-Reply-To: <DC168FB6-C464-4454-BAD9-DDD94453FD04@macports.org>
References: <AAEDB847-EF6D-4177-B257-8613D71BBAEE@lavergne.gotdns.org>
	<DC168FB6-C464-4454-BAD9-DDD94453FD04@macports.org>
Message-ID: <0D204260-7DA4-4C24-8B85-2AB0BA63664F@macports.org>

On 8 Apr 2009, at 06:45, Ryan Schmidt wrote:

> On Apr 7, 2009, at 09:59, Jeremy Lavergne wrote:
>
>> I have a port that is using yacc.  Like g++/gcc, it can use the  
>> system ones without a problem.  Should this not be marked as a  
>> dependency then?
>
> I suggest declaring a dependency on the bison port. I do this in my  
> pure/pure-devel ports which need bison. This way, you won't be  
> confused later when differences arise between the system bison and  
> the MacPorts bison; you can be assured all users are using the  
> MacPorts bison.
>
>> If not, what ports provide bin/yacc besides bison +yacc?  It is my  
>> understanding we can't dictate variants yet, so I'd like a better  
>> solution than printing a ui_msg.
>
> True. But:
>
> The +yacc variant doesn't make bison take longer to build [1]. It  
> doesn't add any dependencies. All it does is install a static  
> library liby.a and install a wrapper script "yacc" which calls  
> "bison -y".
>

How about setting YACC='bison -y' ? Or does the port require the  
library as well?


> The +yacc variant was added to the bison port in r10216 when it was  
> updated to version 2.0. No explanation why it was a variant instead  
> of always on.
>

If in doubt, I try to mimic the FreeBSD ports -- thats tried and  
tested already for the "closest relative" OS. I recall there were some  
ports that failed due to expecting "bison1" behind 'yacc'..


> This sounds like a great example of where we should remove the  
> variant and have bison always include yacc support.
>

Thinking about enabling 'yacc' by default, there are (at least) 3  
candidates to claim the 'yacc' executable: bison1, bison (version 2),  
byaccj and bisoncpp [1];

Another solution would be to install the yacc/bison2 executable as  
'yacc2' or as 'yacc' in $prefix/lib/bison/bin -- thought?


Regards,

-Markus


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

--
Markus W. Weissmann, M. Sc.
http://www.mweissmann.de/


From ryandesign at macports.org  Wed Apr  8 01:37:40 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 8 Apr 2009 03:37:40 -0500
Subject: yacc/bison
In-Reply-To: <0D204260-7DA4-4C24-8B85-2AB0BA63664F@macports.org>
References: <AAEDB847-EF6D-4177-B257-8613D71BBAEE@lavergne.gotdns.org>
	<DC168FB6-C464-4454-BAD9-DDD94453FD04@macports.org>
	<0D204260-7DA4-4C24-8B85-2AB0BA63664F@macports.org>
Message-ID: <C9A04E5D-4EB8-4688-A0CD-0BB5FF84A9B5@macports.org>


On Apr 8, 2009, at 02:33, Markus Weissmann wrote:

> On 8 Apr 2009, at 06:45, Ryan Schmidt wrote:
>
>> The +yacc variant was added to the bison port in r10216 when it  
>> was updated to version 2.0. No explanation why it was a variant  
>> instead of always on.
>
> If in doubt, I try to mimic the FreeBSD ports -- thats tried and  
> tested already for the "closest relative" OS. I recall there were  
> some ports that failed due to expecting "bison1" behind 'yacc'..

Ah, ok.


>> This sounds like a great example of where we should remove the  
>> variant and have bison always include yacc support.
>
> Thinking about enabling 'yacc' by default, there are (at least) 3  
> candidates to claim the 'yacc' executable: bison1, bison (version  
> 2), byaccj and bisoncpp [1];

Ok, didn't know those existed.

Perhaps bison's yacc could be its own port? Then one could declare a  
dependency on "path:bin/yacc:bison-yacc".


> Another solution would be to install the yacc/bison2 executable as  
> 'yacc2' or as 'yacc' in $prefix/lib/bison/bin -- thought?

If you go this route, ${prefix}/libexec/bison/ would be a better  
place than ${prefix}/lib/bison/bin/, based on my understanding of  
portheir(7), as used e.g. in the wine port.



From ryandesign at macports.org  Wed Apr  8 01:59:17 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 8 Apr 2009 03:59:17 -0500
Subject: [49342] trunk/dports/graphics/cairomm/Portfile
In-Reply-To: <20090408025451.5B25C1476275@beta.macosforge.org>
References: <20090408025451.5B25C1476275@beta.macosforge.org>
Message-ID: <D19817DE-7A87-4EA1-8556-A131DD569122@macports.org>


On Apr 7, 2009, at 21:54, devans at macports.org wrote:

> Revision: 49342
>           http://trac.macports.org/changeset/49342
> Author:   devans at macports.org
> Date:     2009-04-07 19:54:50 -0700 (Tue, 07 Apr 2009)
> Log Message:
> -----------
> cairomm: increment revision to force build against latest cairo  
> (quartz and x11 now mutually exclusive).

quartz and x11 are not meant to be mutually exclusive in the cairo  
port. Are they? It was not my intention. I only meant to disable  
quartz by default.


From devans at macports.org  Wed Apr  8 08:54:30 2009
From: devans at macports.org (David Evans)
Date: Wed, 08 Apr 2009 08:54:30 -0700
Subject: [49342] trunk/dports/graphics/cairomm/Portfile
In-Reply-To: <D19817DE-7A87-4EA1-8556-A131DD569122@macports.org>
References: <20090408025451.5B25C1476275@beta.macosforge.org>
	<D19817DE-7A87-4EA1-8556-A131DD569122@macports.org>
Message-ID: <49DCC8B6.5040901@macports.org>

Ryan Schmidt wrote:
>
> On Apr 7, 2009, at 21:54, devans at macports.org wrote:
>
>> Revision: 49342
>>           http://trac.macports.org/changeset/49342
>> Author:   devans at macports.org
>> Date:     2009-04-07 19:54:50 -0700 (Tue, 07 Apr 2009)
>> Log Message:
>> -----------
>> cairomm: increment revision to force build against latest cairo 
>> (quartz and x11 now mutually exclusive).
>
> quartz and x11 are not meant to be mutually exclusive in the cairo 
> port. Are they? It was not my intention. I only meant to disable 
> quartz by default.
>
Yes, you're right.  But doing so required rebuilding cairomm because it
links to anything it can find available in libcairo.  Applications that
use cairomm (inkscape, inkscape-devel) were failing on build because
cairomm couldn't find the quartz backend functions that were available
when it was last built even though they are not used by its dependents.

As you say, all the cairo backends (more than just quartz and x11) are
independent of each other and are accessed independently by
their own APIs so they can co-exist and often do.

Dave


From raimue at macports.org  Wed Apr  8 09:03:44 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Wed, 08 Apr 2009 18:03:44 +0200
Subject: Ports linking against the wrong Python.framework (was: Re: [MacPorts]
	#19223: subversion 1.6.0 stubbornly linking against	python25-apple?)
In-Reply-To: <071.41da13f929b715af04a8bb4857c8e12c@macports.org>
References: <062.13f6e0b9941679b695339c1187888885@macports.org>
	<071.41da13f929b715af04a8bb4857c8e12c@macports.org>
Message-ID: <49DCCAE0.8020409@macports.org>

Writing to macports-dev to get more public discussion and more people
noticing this problem.

MacPorts wrote:
> #19223: subversion 1.6.0 stubbornly linking against python25-apple?
> ------------------------------------------+---------------------------------
>   Reporter:  macports.org@?               |       Owner:  dluke@?           
>       Type:  defect                       |      Status:  reopened          
>   Priority:  Normal                       |   Milestone:  Port Bugs         
>  Component:  ports                        |     Version:  1.7.1             
> Resolution:                               |    Keywords:                    
>       Port:  subversion-python25bindings  |  
> ------------------------------------------+---------------------------------
> 
> Comment(by dluke@?):
> 
>  So, the libtool link lines in both build logs have:
>  -F/opt/local/Library/Frameworks -framework Python, which should cause the
>  correct Python framework to be chosen, so at this point I'm unsure why
>  it's not working correctly.

And exactly this is wrong. As soon as another framework version (e.g.
2.6 or 3.0) is selected by python_select, it will link against the wrong
python version, but still use the python 2.5 headers. This can lead to
build failures or other problems. After all it is not version which the
maintainer intended, which will result in "Python version mismatch"
later. If none is selected at all, it will even fall back to the system
for linking.

The problem is that frameworks allow to contain multiple versions, but
the compiler does not have any option to choose a specific version. In
my opinion this is a bug. But given this fact, all ports wanting to link
against python need to be patched not to use -framework. This has
already been done for example for mod_wsgi and mod_python25 by
commenting out the framework relevant parts in the configure script.

These multiple versions in one framework cause us more troubles than
benefit. The flags like "-F${prefix}/Library/Frameworks -framework
Python" are generated by build scripts in ports detecting a python
framework. They are not given by the global python configuration, which
only specifies the framework dir and framework name.

We need to get ports not to use these flags. Either we trick ports not
to link using -framework by patching each of them or by modifying the
global python configuration not to report itself as a framework. But
then what would be a reason to keep it as a framework as it causes us so
much troubles?

As far as I know the only advantage of the frameworks is currently to
have working pythonw and IDLE. Is there really no way to get this
without a framework build or did just nobody try yet?

Yes, I know I have been the one who committed the original python
framework transition for python25. :-) It sounded like a good idea back
then and I never thought it would cause such problems for us.

Rainer

From devans at macports.org  Wed Apr  8 09:08:32 2009
From: devans at macports.org (David Evans)
Date: Wed, 08 Apr 2009 09:08:32 -0700
Subject: ruby, macports trunk and setgid
Message-ID: <49DCCC00.4090700@macports.org>

Ruby fails to build using the usual

sudo port install/upgrade ruby

when using MacPorts trunk (but not 1.7.1) because port runs setgid and 
miniruby that is built and used in the build
sees that as a security problem and will not run as requested.

Is this a problem or is there a way to get around this? Are there other 
ports that don't like running setgid?

See https://trac.macports.org/ticket/19131

From raimue at macports.org  Wed Apr  8 09:14:04 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Wed, 08 Apr 2009 18:14:04 +0200
Subject: Comparison to other package managers for new users (was: Re:
	Deprecating port list)
In-Reply-To: <F8DEA48C-CB47-4004-8EFD-A27F93164697@macports.org>
References: <49B916AD.7020203@macports.org>	<FC394E23-EF97-45FD-AB33-9E7EB885CFF4@lavergne.gotdns.org>	<49B922C2.8090509@macports.org>	<BC33A79B-7530-4868-98C2-DCC2C14E633B@lavergne.gotdns.org>	<49B93A6E.7060304@macports.org>	<C3DA10D8-1910-41F0-B475-E8AB3624949C@lavergne.gotdns.org>
	<F8DEA48C-CB47-4004-8EFD-A27F93164697@macports.org>
Message-ID: <49DCCD4C.5060506@macports.org>

Olivier Le Floch wrote:
> On 12 mars 09, at 18:41, Jeremy Lavergne wrote:
> 
>>> If you are concerned that new users who are already familiar with
>>> different packagement systems have a hard time to get used to  
>>> 'port', we
>>> could create a wiki section which lists equivalent commands for other
>>> systems.
>> I like this idea.
> 
> I like it too ! I can help out with the Debian/Apt/DPKG section.

Not that this idea gets lost, let's just start a wiki page. Yet I can't
decide for a good name, MacPortsComparedToOtherPackageManagers sounds a
bit clumsy.

Rainer

From dluke at geeklair.net  Wed Apr  8 09:51:17 2009
From: dluke at geeklair.net (Daniel J. Luke)
Date: Wed, 8 Apr 2009 12:51:17 -0400
Subject: Ports linking against the wrong Python.framework (was: Re:
	[MacPorts] #19223: subversion 1.6.0 stubbornly linking
	against	python25-apple?)
In-Reply-To: <49DCCAE0.8020409@macports.org>
References: <062.13f6e0b9941679b695339c1187888885@macports.org>
	<071.41da13f929b715af04a8bb4857c8e12c@macports.org>
	<49DCCAE0.8020409@macports.org>
Message-ID: <C5CB11B1-D22A-4BA6-8932-698487149A90@geeklair.net>

On Apr 8, 2009, at 12:03 PM, Rainer M?ller wrote:
> The problem is that frameworks allow to contain multiple versions, but
> the compiler does not have any option to choose a specific version. In
> my opinion this is a bug. But given this fact, all ports wanting to  
> link
> against python need to be patched not to use -framework. This has
> already been done for example for mod_wsgi and mod_python25 by
> commenting out the framework relevant parts in the configure script.

Ok, I can do that for the subversion-python25bindings port too, then,  
I guess.

> We need to get ports not to use these flags. Either we trick ports not
> to link using -framework by patching each of them or by modifying the
> global python configuration not to report itself as a framework. But
> then what would be a reason to keep it as a framework as it causes  
> us so
> much troubles?
>
> As far as I know the only advantage of the frameworks is currently to
> have working pythonw and IDLE. Is there really no way to get this
> without a framework build or did just nobody try yet?

I would also prefer the non-framework install. (I don't know how  
difficult it would be to get pythonw and IDLE to work, 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/20090408/2800dc46/attachment.bin>

From blair at orcaware.com  Wed Apr  8 09:56:59 2009
From: blair at orcaware.com (Blair Zajac)
Date: Wed, 08 Apr 2009 09:56:59 -0700
Subject: Ports linking against the wrong Python.framework
In-Reply-To: <49DCCAE0.8020409@macports.org>
References: <062.13f6e0b9941679b695339c1187888885@macports.org>	<071.41da13f929b715af04a8bb4857c8e12c@macports.org>
	<49DCCAE0.8020409@macports.org>
Message-ID: <49DCD75B.6060709@orcaware.com>

Rainer M?ller wrote:
> Writing to macports-dev to get more public discussion and more people
> noticing this problem.
> 

> Yes, I know I have been the one who committed the original python
> framework transition for python25. :-) It sounded like a good idea back
> then and I never thought it would cause such problems for us.

I think we should just have different framework directories for each version of 
Python.

So instead of

${prefix}/Library/Frameworks

have

${prefix}/Library/Python2.6-Framework

or something and that version is always 2.6.  So we avoid this issue.

Regards,
Blair

From blb at macports.org  Wed Apr  8 13:15:47 2009
From: blb at macports.org (Bryan Blackburn)
Date: Wed, 8 Apr 2009 14:15:47 -0600
Subject: Ports linking against the wrong Python.framework (was: Re:
	[MacPorts] #19223: subversion 1.6.0 stubbornly linking against
	python25-apple?)
In-Reply-To: <49DCCAE0.8020409@macports.org>
References: <062.13f6e0b9941679b695339c1187888885@macports.org>
	<071.41da13f929b715af04a8bb4857c8e12c@macports.org>
	<49DCCAE0.8020409@macports.org>
Message-ID: <20090408201547.GC94765@ninagal.withay.com>

On Wed, Apr 08, 2009 at 06:03:44PM +0200, Rainer M?ller said:
[...]
> We need to get ports not to use these flags. Either we trick ports not
> to link using -framework by patching each of them or by modifying the
> global python configuration not to report itself as a framework. But
> then what would be a reason to keep it as a framework as it causes us so
> much troubles?
> 
> As far as I know the only advantage of the frameworks is currently to
> have working pythonw and IDLE. Is there really no way to get this
> without a framework build or did just nobody try yet?

The last time I tried, you had to build it as a framework if you wanted
pythonw on the Mac.  Though I haven't tried it in a few python versions
(that was either 2.3 or 2.4 when I last tried).

With enough patches to python it could probably be done if that still isn't
supported, but moving back to a more *nix-like install would probably cause
yet more pain.  So in this case we should probably make sure it'd be worth
it first...

Bryan


> 
> Yes, I know I have been the one who committed the original python
> framework transition for python25. :-) It sounded like a good idea back
> then and I never thought it would cause such problems for us.
> 
> Rainer

From florian.ebeling at gmail.com  Wed Apr  8 13:23:04 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Wed, 8 Apr 2009 22:23:04 +0200
Subject: Comparison to other package managers for new users (was: Re: 
	Deprecating port list)
In-Reply-To: <49DCCD4C.5060506@macports.org>
References: <49B916AD.7020203@macports.org>
	<FC394E23-EF97-45FD-AB33-9E7EB885CFF4@lavergne.gotdns.org>
	<49B922C2.8090509@macports.org>
	<BC33A79B-7530-4868-98C2-DCC2C14E633B@lavergne.gotdns.org>
	<49B93A6E.7060304@macports.org>
	<C3DA10D8-1910-41F0-B475-E8AB3624949C@lavergne.gotdns.org>
	<F8DEA48C-CB47-4004-8EFD-A27F93164697@macports.org>
	<49DCCD4C.5060506@macports.org>
Message-ID: <5cbbe4ae0904081323n21e8ae57r709d0333647fb7df@mail.gmail.com>

On Wed, Apr 8, 2009 at 6:14 PM, Rainer M?ller <raimue at macports.org> wrote:
> Olivier Le Floch wrote:
>> On 12 mars 09, at 18:41, Jeremy Lavergne wrote:
>>
>>>> If you are concerned that new users who are already familiar with
>>>> different packagement systems have a hard time to get used to
>>>> 'port', we
>>>> could create a wiki section which lists equivalent commands for other
>>>> systems.
>>> I like this idea.
>>
>> I like it too ! I can help out with the Debian/Apt/DPKG section.
>
> Not that this idea gets lost, let's just start a wiki page. Yet I can't
> decide for a good name, MacPortsComparedToOtherPackageManagers sounds a
> bit clumsy.

Its a bit of an introduction for already quite knowledgable users, isn't it?
Maybe PowerUsersGettingStarted, or PowerUsersIntro would make sense...
The focus should be usage, and not comparision anyway, shouldn't it?

Florian


-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com

From blair at orcaware.com  Wed Apr  8 13:29:24 2009
From: blair at orcaware.com (Blair Zajac)
Date: Wed, 08 Apr 2009 13:29:24 -0700
Subject: Ports linking against the wrong Python.framework
In-Reply-To: <49DCCAE0.8020409@macports.org>
References: <062.13f6e0b9941679b695339c1187888885@macports.org>	<071.41da13f929b715af04a8bb4857c8e12c@macports.org>
	<49DCCAE0.8020409@macports.org>
Message-ID: <49DD0924.6000205@orcaware.com>

Rainer M?ller wrote:
> Writing to macports-dev to get more public discussion and more people
> noticing this problem.
> 
> MacPorts wrote:
>> #19223: subversion 1.6.0 stubbornly linking against python25-apple?
>> ------------------------------------------+---------------------------------
>>   Reporter:  macports.org@?               |       Owner:  dluke@?           
>>       Type:  defect                       |      Status:  reopened          
>>   Priority:  Normal                       |   Milestone:  Port Bugs         
>>  Component:  ports                        |     Version:  1.7.1             
>> Resolution:                               |    Keywords:                    
>>       Port:  subversion-python25bindings  |  
>> ------------------------------------------+---------------------------------
>>
>> Comment(by dluke@?):
>>
>>  So, the libtool link lines in both build logs have:
>>  -F/opt/local/Library/Frameworks -framework Python, which should cause the
>>  correct Python framework to be chosen, so at this point I'm unsure why
>>  it's not working correctly.
> 
> As far as I know the only advantage of the frameworks is currently to
> have working pythonw and IDLE. Is there really no way to get this
> without a framework build or did just nobody try yet?

The Ice Python bindings requires a framework build.  Sony Pictures Imageworks 
whole middle-tier infrastructure is based on Ice with Python clients.

Blair

From blair at orcaware.com  Wed Apr  8 13:31:37 2009
From: blair at orcaware.com (Blair Zajac)
Date: Wed, 08 Apr 2009 13:31:37 -0700
Subject: Ports linking against the wrong Python.framework
In-Reply-To: <20090408201547.GC94765@ninagal.withay.com>
References: <062.13f6e0b9941679b695339c1187888885@macports.org>	<071.41da13f929b715af04a8bb4857c8e12c@macports.org>	<49DCCAE0.8020409@macports.org>
	<20090408201547.GC94765@ninagal.withay.com>
Message-ID: <49DD09A9.1090004@orcaware.com>

Bryan Blackburn wrote:
> On Wed, Apr 08, 2009 at 06:03:44PM +0200, Rainer M?ller said:
> [...]
>> We need to get ports not to use these flags. Either we trick ports not
>> to link using -framework by patching each of them or by modifying the
>> global python configuration not to report itself as a framework. But
>> then what would be a reason to keep it as a framework as it causes us so
>> much troubles?
>>
>> As far as I know the only advantage of the frameworks is currently to
>> have working pythonw and IDLE. Is there really no way to get this
>> without a framework build or did just nobody try yet?
> 
> The last time I tried, you had to build it as a framework if you wanted
> pythonw on the Mac.  Though I haven't tried it in a few python versions
> (that was either 2.3 or 2.4 when I last tried).
> 
> With enough patches to python it could probably be done if that still isn't
> supported, but moving back to a more *nix-like install would probably cause
> yet more pain.  So in this case we should probably make sure it'd be worth
> it first...

I'm definitely against moving back to a Unix install.  As I said in a previous 
post, I think we should move each Python Framework into a different prefix 
directory so we don't have conflicts between versions or have to deal with 
python_select before compiling a binding.

Blair

From blair at orcaware.com  Wed Apr  8 13:34:13 2009
From: blair at orcaware.com (Blair Zajac)
Date: Wed, 08 Apr 2009 13:34:13 -0700
Subject: Ports linking against the wrong Python.framework
In-Reply-To: <49DD0924.6000205@orcaware.com>
References: <062.13f6e0b9941679b695339c1187888885@macports.org>	<071.41da13f929b715af04a8bb4857c8e12c@macports.org>	<49DCCAE0.8020409@macports.org>
	<49DD0924.6000205@orcaware.com>
Message-ID: <49DD0A45.3080500@orcaware.com>

Blair Zajac wrote:
> Rainer M?ller wrote:
>> Writing to macports-dev to get more public discussion and more people
>> noticing this problem.
>>
>> MacPorts wrote:
>>> #19223: subversion 1.6.0 stubbornly linking against python25-apple?
>>> ------------------------------------------+--------------------------------- 
>>>
>>>   Reporter:  macports.org@?               |       Owner:  
>>> dluke@?                 Type:  defect                       |      
>>> Status:  reopened            Priority:  Normal                       
>>> |   Milestone:  Port Bugs          Component:  
>>> ports                        |     Version:  1.7.1             
>>> Resolution:                               |    
>>> Keywords:                          Port:  
>>> subversion-python25bindings  |  
>>> ------------------------------------------+--------------------------------- 
>>>
>>>
>>> Comment(by dluke@?):
>>>
>>>  So, the libtool link lines in both build logs have:
>>>  -F/opt/local/Library/Frameworks -framework Python, which should 
>>> cause the
>>>  correct Python framework to be chosen, so at this point I'm unsure why
>>>  it's not working correctly.
>>
>> As far as I know the only advantage of the frameworks is currently to
>> have working pythonw and IDLE. Is there really no way to get this
>> without a framework build or did just nobody try yet?
> 
> The Ice Python bindings requires a framework build.  Sony Pictures 
> Imageworks whole middle-tier infrastructure is based on Ice with Python 
> clients.

Oh, and doesn't PyQt require a framework install?  We depend heavily on that too.

Blair


From raimue at macports.org  Wed Apr  8 18:44:07 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Thu, 09 Apr 2009 03:44:07 +0200
Subject: [49158] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl
In-Reply-To: <loom.20090407T193956-989@post.gmane.org>
References: <loom.20090404T194101-520@post.gmane.org>	<49DB5DEB.7020701@macports.org>
	<loom.20090407T193956-989@post.gmane.org>
Message-ID: <49DD52E7.5080507@macports.org>

Marcus Calhoun-Lopez wrote:
> Rainer M?ller <raimue at ...> writes:
> 
>> By the way, what is the current status of muniversal? I see you are
>> converting more and more ports to use it. Is it ready yet to be
>> integrated into base?
> 
> I have already attempted to create some patches to be incorporated
> into the base.
> One stumbling block is my unfamiliarity with the base code, so the
> patches are not very good yet.

No problem if you are not in the know of base code. That is most
probably the same for a lot of people ;-) And I don't claim to know
everything in base myself either. I only learned over time how internals
work.

Also, for myself I just never looked at the code in muniversal. But
basically it is running extract/patch/configure/build for each
architecture in a different work directory, right?

I would introduce a new merge target in port1.0 which does the actual
merging. Targets can declare dependency on other targets, which is
basically how it all links together. So this merge target just needs to
depend on multiple appropriate extract/patch/configure/build targets.
But running targets multiple times is currently not done anywhere else
in the base code. So we need something to distinguish between them and
figure out a way how to pass them special options, e.g. the architecture
and working directory.

Rainer

From ryandesign at macports.org  Wed Apr  8 20:02:14 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 8 Apr 2009 22:02:14 -0500
Subject: [49158] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl
In-Reply-To: <49DD52E7.5080507@macports.org>
References: <loom.20090404T194101-520@post.gmane.org>	<49DB5DEB.7020701@macports.org>
	<loom.20090407T193956-989@post.gmane.org>
	<49DD52E7.5080507@macports.org>
Message-ID: <C78CEB2C-A1DB-4862-AC3E-6BB4C86C6D2D@macports.org>

On Apr 8, 2009, at 20:44, Rainer M?ller wrote:

> Also, for myself I just never looked at the code in muniversal. But
> basically it is running extract/patch/configure/build for each
> architecture in a different work directory, right?
>
> I would introduce a new merge target in port1.0 which does the actual
> merging. Targets can declare dependency on other targets, which is
> basically how it all links together. So this merge target just  
> needs to
> depend on multiple appropriate extract/patch/configure/build targets.
> But running targets multiple times is currently not done anywhere else
> in the base code. So we need something to distinguish between them and
> figure out a way how to pass them special options, e.g. the  
> architecture
> and working directory.

I still think rather than devote a lot of energy to this mechanism,  
we should instead focus on building binaries, and let the server  
merge them together -- or even let the user download both the powerpc  
and intel binaries and have the user's macports merge them. Either  
way, we wouldn't have to worry about figuring out how to let the  
phases run multiple times, because the server would just run "port  
install" multiple times instead.




From ryandesign at macports.org  Wed Apr  8 20:03:53 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 8 Apr 2009 22:03:53 -0500
Subject: Comparison to other package managers for new users (was: Re:
	Deprecating port list)
In-Reply-To: <5cbbe4ae0904081323n21e8ae57r709d0333647fb7df@mail.gmail.com>
References: <49B916AD.7020203@macports.org>
	<FC394E23-EF97-45FD-AB33-9E7EB885CFF4@lavergne.gotdns.org>
	<49B922C2.8090509@macports.org>
	<BC33A79B-7530-4868-98C2-DCC2C14E633B@lavergne.gotdns.org>
	<49B93A6E.7060304@macports.org>
	<C3DA10D8-1910-41F0-B475-E8AB3624949C@lavergne.gotdns.org>
	<F8DEA48C-CB47-4004-8EFD-A27F93164697@macports.org>
	<49DCCD4C.5060506@macports.org>
	<5cbbe4ae0904081323n21e8ae57r709d0333647fb7df@mail.gmail.com>
Message-ID: <535C61E5-BB1A-4A11-92D0-7AB0F920178D@macports.org>


On Apr 8, 2009, at 15:23, C. Florian Ebeling wrote:

> On Wed, Apr 8, 2009 at 6:14 PM, Rainer M?ller wrote:
>> Olivier Le Floch wrote:
>>> On 12 mars 09, at 18:41, Jeremy Lavergne wrote:
>>>
>>>>> If you are concerned that new users who are already familiar with
>>>>> different packagement systems have a hard time to get used to
>>>>> 'port', we
>>>>> could create a wiki section which lists equivalent commands for  
>>>>> other
>>>>> systems.
>>>> I like this idea.
>>>
>>> I like it too ! I can help out with the Debian/Apt/DPKG section.
>>
>> Not that this idea gets lost, let's just start a wiki page. Yet I  
>> can't
>> decide for a good name, MacPortsComparedToOtherPackageManagers  
>> sounds a
>> bit clumsy.
>
> Its a bit of an introduction for already quite knowledgable users,  
> isn't it?
> Maybe PowerUsersGettingStarted, or PowerUsersIntro would make sense...
> The focus should be usage, and not comparision anyway, shouldn't it?

The Guide explains usage. If the goal is to create a document that  
helps you migrate your knowledge from another package manager to  
MacPorts, then maybe MigratingToMacPorts, MacPortsMigration, or just  
Migrating would be a good page name.



From mcalhoun at macports.org  Wed Apr  8 21:09:25 2009
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Thu, 9 Apr 2009 04:09:25 +0000 (UTC)
Subject: [49158]
	=?utf-8?b?dHJ1bmsvZHBvcnRzL19yZXNvdXJjZXMvcG9ydDEuMC9ncm91cC9tdW5pdmVyc2FsLTEuMC50Y2w=?=
References: <loom.20090404T194101-520@post.gmane.org>	<49DB5DEB.7020701@macports.org>
	<loom.20090407T193956-989@post.gmane.org>
	<49DD52E7.5080507@macports.org>
	<C78CEB2C-A1DB-4862-AC3E-6BB4C86C6D2D@macports.org>
Message-ID: <loom.20090409T033610-916@post.gmane.org>

Ryan Schmidt <ryandesign at ...> writes:

> 
> I still think rather than devote a lot of energy to this mechanism,  
> we should instead focus on building binaries, and let the server  
> merge them together -- or even let the user download both the powerpc  
> and intel binaries and have the user's macports merge them. Either  
> way, we wouldn't have to worry about figuring out how to let the  
> phases run multiple times, because the server would just run "port  
> install" multiple times instead.
> 

I think binaries would be great idea.
There would not be much reason for intel/ppc universals
anymore because the user could simply download the correct architecture.

My particular interest is 32/64-bit universals.
Simply letting the user or server merge the 32 and 64 bit versions would
be a bit of a problem.
Some ports require tweaking for the merge to work.
Big and complicated ports like qt4-mac and python2.6 probably would not
merge easily.
Fortunately both packages support universal builds.

We could have separate prefix values for 32 and 64 bit libraries and
forget universals.
Once built, however, universal libraries are very convenient.
Plus, I like the idea that all I need to do is build my a.out program
once and run:
time arch -arch i386 ./a.out
time arch -arch x86_64 ./a.out
to compare 32-bit and 64-bit execution.

If we want to support 32/64-bit universals, it seems to me that
incorporating muniversal into the base is a good way to accomplish it.

-Marcus











From florian.ebeling at gmail.com  Thu Apr  9 00:58:58 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Thu, 9 Apr 2009 09:58:58 +0200
Subject: Comparison to other package managers for new users (was: Re: 
	Deprecating port list)
In-Reply-To: <535C61E5-BB1A-4A11-92D0-7AB0F920178D@macports.org>
References: <49B916AD.7020203@macports.org>
	<FC394E23-EF97-45FD-AB33-9E7EB885CFF4@lavergne.gotdns.org>
	<49B922C2.8090509@macports.org>
	<BC33A79B-7530-4868-98C2-DCC2C14E633B@lavergne.gotdns.org>
	<49B93A6E.7060304@macports.org>
	<C3DA10D8-1910-41F0-B475-E8AB3624949C@lavergne.gotdns.org>
	<F8DEA48C-CB47-4004-8EFD-A27F93164697@macports.org>
	<49DCCD4C.5060506@macports.org>
	<5cbbe4ae0904081323n21e8ae57r709d0333647fb7df@mail.gmail.com>
	<535C61E5-BB1A-4A11-92D0-7AB0F920178D@macports.org>
Message-ID: <5cbbe4ae0904090058t427196adk8915eefb10a89fae@mail.gmail.com>

On Thu, Apr 9, 2009 at 5:03 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On Apr 8, 2009, at 15:23, C. Florian Ebeling wrote:
>
>> On Wed, Apr 8, 2009 at 6:14 PM, Rainer M?ller wrote:
>>>
>>> Olivier Le Floch wrote:
>>>>
>>>> On 12 mars 09, at 18:41, Jeremy Lavergne wrote:
>>>>
>>>>>> If you are concerned that new users who are already familiar with
>>>>>> different packagement systems have a hard time to get used to
>>>>>> 'port', we
>>>>>> could create a wiki section which lists equivalent commands for other
>>>>>> systems.
>>>>>
>>>>> I like this idea.
>>>>
>>>> I like it too ! I can help out with the Debian/Apt/DPKG section.
>>>
>>> Not that this idea gets lost, let's just start a wiki page. Yet I can't
>>> decide for a good name, MacPortsComparedToOtherPackageManagers sounds a
>>> bit clumsy.
>>
>> Its a bit of an introduction for already quite knowledgable users, isn't
>> it?
>> Maybe PowerUsersGettingStarted, or PowerUsersIntro would make sense...
>> The focus should be usage, and not comparision anyway, shouldn't it?
>
> The Guide explains usage. If the goal is to create a document that helps you
> migrate your knowledge from another package manager to MacPorts, then maybe
> MigratingToMacPorts, MacPortsMigration, or just Migrating would be a good
> page name.

That implies the reader stops working with Linux, which is not the
most likely case. And the whole idea of this document seem to
be a special-audience text, at the expense of having a single
documentation like the guide. Remember this is documentation,
so redundancy for the sake of understandability is acceptable.

I agree that my name suggestions where quite lame, though. Please
don't use them. :)

-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com

From ryandesign at macports.org  Thu Apr  9 03:35:29 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 9 Apr 2009 05:35:29 -0500
Subject: Binaries and alternate prefix
Message-ID: <88054BE3-2148-4C5D-9898-674D2610C944@macports.org>

If we build and distribute binaries of ports.... is there a way we  
can still allow the user to choose their prefix?

The prefix can be hardcoded in so many places in built ports. For  
compiled libraries and binaries, we could use install_name_tool on  
the client side to fix up all the paths. We could either build with - 
headerpad_max_install_names or with a very long prefix, so that there  
is enough space in the binary to accommodate the user's prefix. If we  
used a long and particularly unique prefix at build time, then this  
would also make it possible for the client to do a search/replace of  
that string with the user's prefix in the port's text files.

Perhaps I'm getting ahead of things. We could begin with binaries  
only available for the default /opt/local path, and think about how  
to support other prefixes later.



From alakazam at macports.org  Thu Apr  9 03:40:47 2009
From: alakazam at macports.org (Olivier Le Floch)
Date: Thu, 9 Apr 2009 12:40:47 +0200
Subject: Comparison to other package managers for new users (was: Re:
	Deprecating port list)
In-Reply-To: <5cbbe4ae0904090058t427196adk8915eefb10a89fae@mail.gmail.com>
References: <49B916AD.7020203@macports.org>
	<FC394E23-EF97-45FD-AB33-9E7EB885CFF4@lavergne.gotdns.org>
	<49B922C2.8090509@macports.org>
	<BC33A79B-7530-4868-98C2-DCC2C14E633B@lavergne.gotdns.org>
	<49B93A6E.7060304@macports.org>
	<C3DA10D8-1910-41F0-B475-E8AB3624949C@lavergne.gotdns.org>
	<F8DEA48C-CB47-4004-8EFD-A27F93164697@macports.org>
	<49DCCD4C.5060506@macports.org>
	<5cbbe4ae0904081323n21e8ae57r709d0333647fb7df@mail.gmail.com>
	<535C61E5-BB1A-4A11-92D0-7AB0F920178D@macports.org>
	<5cbbe4ae0904090058t427196adk8915eefb10a89fae@mail.gmail.com>
Message-ID: <05DCCAB0-1FF7-445A-9F38-90EE129BFB89@macports.org>

>> The Guide explains usage. If the goal is to create a document that  
>> helps you
>> migrate your knowledge from another package manager to MacPorts,  
>> then maybe
>> MigratingToMacPorts, MacPortsMigration, or just Migrating would be  
>> a good
>> page name.
>
> That implies the reader stops working with Linux, which is not the
> most likely case. And the whole idea of this document seem to
> be a special-audience text, at the expense of having a single
> documentation like the guide. Remember this is documentation,
> so redundancy for the sake of understandability is acceptable.
>
> I agree that my name suggestions where quite lame, though. Please
> don't use them. :)

How about MacportsForLinuxUsers ? (since I guess most of the other  
package managers are on linux)

From ryandesign at macports.org  Thu Apr  9 03:47:16 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 9 Apr 2009 05:47:16 -0500
Subject: Comparison to other package managers for new users (was: Re:
	Deprecating port list)
In-Reply-To: <05DCCAB0-1FF7-445A-9F38-90EE129BFB89@macports.org>
References: <49B916AD.7020203@macports.org>
	<FC394E23-EF97-45FD-AB33-9E7EB885CFF4@lavergne.gotdns.org>
	<49B922C2.8090509@macports.org>
	<BC33A79B-7530-4868-98C2-DCC2C14E633B@lavergne.gotdns.org>
	<49B93A6E.7060304@macports.org>
	<C3DA10D8-1910-41F0-B475-E8AB3624949C@lavergne.gotdns.org>
	<F8DEA48C-CB47-4004-8EFD-A27F93164697@macports.org>
	<49DCCD4C.5060506@macports.org>
	<5cbbe4ae0904081323n21e8ae57r709d0333647fb7df@mail.gmail.com>
	<535C61E5-BB1A-4A11-92D0-7AB0F920178D@macports.org>
	<5cbbe4ae0904090058t427196adk8915eefb10a89fae@mail.gmail.com>
	<05DCCAB0-1FF7-445A-9F38-90EE129BFB89@macports.org>
Message-ID: <5AD6B2DA-1293-4AD9-AD04-8156535AAD79@macports.org>


On Apr 9, 2009, at 05:40, Olivier Le Floch wrote:

>>> The Guide explains usage. If the goal is to create a document  
>>> that helps you
>>> migrate your knowledge from another package manager to MacPorts,  
>>> then maybe
>>> MigratingToMacPorts, MacPortsMigration, or just Migrating would  
>>> be a good
>>> page name.
>>
>> That implies the reader stops working with Linux, which is not the
>> most likely case. And the whole idea of this document seem to
>> be a special-audience text, at the expense of having a single
>> documentation like the guide. Remember this is documentation,
>> so redundancy for the sake of understandability is acceptable.
>>
>> I agree that my name suggestions where quite lame, though. Please
>> don't use them. :)
>
> How about MacportsForLinuxUsers ? (since I guess most of the other  
> package managers are on linux)

Or, in case they aren't, how about "MacPortsForSwitchers", to use  
some Apple terminology?



From alakazam at macports.org  Thu Apr  9 03:53:18 2009
From: alakazam at macports.org (Olivier Le Floch)
Date: Thu, 9 Apr 2009 12:53:18 +0200
Subject: Comparison to other package managers for new users (was: Re:
	Deprecating port list)
In-Reply-To: <5AD6B2DA-1293-4AD9-AD04-8156535AAD79@macports.org>
References: <49B916AD.7020203@macports.org>
	<FC394E23-EF97-45FD-AB33-9E7EB885CFF4@lavergne.gotdns.org>
	<49B922C2.8090509@macports.org>
	<BC33A79B-7530-4868-98C2-DCC2C14E633B@lavergne.gotdns.org>
	<49B93A6E.7060304@macports.org>
	<C3DA10D8-1910-41F0-B475-E8AB3624949C@lavergne.gotdns.org>
	<F8DEA48C-CB47-4004-8EFD-A27F93164697@macports.org>
	<49DCCD4C.5060506@macports.org>
	<5cbbe4ae0904081323n21e8ae57r709d0333647fb7df@mail.gmail.com>
	<535C61E5-BB1A-4A11-92D0-7AB0F920178D@macports.org>
	<5cbbe4ae0904090058t427196adk8915eefb10a89fae@mail.gmail.com>
	<05DCCAB0-1FF7-445A-9F38-90EE129BFB89@macports.org>
	<5AD6B2DA-1293-4AD9-AD04-8156535AAD79@macports.org>
Message-ID: <2A00E374-2F64-4AAF-AB0B-CAB1765F614F@macports.org>


On 9 avr. 09, at 12:47, Ryan Schmidt wrote:

> On Apr 9, 2009, at 05:40, Olivier Le Floch wrote:
>
>> How about MacportsForLinuxUsers ? (since I guess most of the other  
>> package managers are on linux)
>
> Or, in case they aren't, how about "MacPortsForSwitchers", to use  
> some Apple terminology?

I like that a lot ;)


From jmr at macports.org  Thu Apr  9 04:20:22 2009
From: jmr at macports.org (Joshua Root)
Date: Thu, 09 Apr 2009 21:20:22 +1000
Subject: Binaries and alternate prefix
In-Reply-To: <88054BE3-2148-4C5D-9898-674D2610C944@macports.org>
References: <88054BE3-2148-4C5D-9898-674D2610C944@macports.org>
Message-ID: <49DDD9F6.4060404@macports.org>

Ryan Schmidt wrote:
> If we build and distribute binaries of ports.... is there a way we can
> still allow the user to choose their prefix?

Not without doing something akin to taint analysis to track everywhere
the prefix is included in the installed files, in the general case.
Which is close enough to "no" for me.

- Josh

From raimue at macports.org  Thu Apr  9 04:24:16 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 09 Apr 2009 13:24:16 +0200
Subject: [49158] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl
In-Reply-To: <C78CEB2C-A1DB-4862-AC3E-6BB4C86C6D2D@macports.org>
References: <loom.20090404T194101-520@post.gmane.org>	<49DB5DEB.7020701@macports.org>
	<loom.20090407T193956-989@post.gmane.org>
	<49DD52E7.5080507@macports.org>
	<C78CEB2C-A1DB-4862-AC3E-6BB4C86C6D2D@macports.org>
Message-ID: <49DDDAE0.4090606@macports.org>

Ryan Schmidt wrote:
> I still think rather than devote a lot of energy to this mechanism,  
> we should instead focus on building binaries, and let the server  
> merge them together -- or even let the user download both the powerpc  
> and intel binaries and have the user's macports merge them. Either  
> way, we wouldn't have to worry about figuring out how to let the  
> phases run multiple times, because the server would just run "port  
> install" multiple times instead.

This sounds quite complicated. How would that work with the current
image mode? Do merge on activate and split on deactivate?

Are you planning to let the user install additional architectures time
by time? Which would mean we need to track dependencies per
architecture. Also we would need to ensure that no two different
versions are merged together.

Rainer

From raimue at macports.org  Thu Apr  9 04:36:40 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 09 Apr 2009 13:36:40 +0200
Subject: [49158] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl
In-Reply-To: <loom.20090409T033610-916@post.gmane.org>
References: <loom.20090404T194101-520@post.gmane.org>	<49DB5DEB.7020701@macports.org>	<loom.20090407T193956-989@post.gmane.org>	<49DD52E7.5080507@macports.org>	<C78CEB2C-A1DB-4862-AC3E-6BB4C86C6D2D@macports.org>
	<loom.20090409T033610-916@post.gmane.org>
Message-ID: <49DDDDC8.5050604@macports.org>

Marcus Calhoun-Lopez wrote:
> I think binaries would be great idea.
> There would not be much reason for intel/ppc universals
> anymore because the user could simply download the correct architecture.

MacPorts just didn't manage to deliver reliable PowerPC/Intel universal
building in time. I would say most people already don't need this anymore.

> [...]
> We could have separate prefix values for 32 and 64 bit libraries and
> forget universals.

So just use multiple MacPorts installations and be done. This is already
possible. :-)

Rainer

From ryandesign at macports.org  Thu Apr  9 05:13:45 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 9 Apr 2009 07:13:45 -0500
Subject: [49158] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl
In-Reply-To: <49DDDAE0.4090606@macports.org>
References: <loom.20090404T194101-520@post.gmane.org>	<49DB5DEB.7020701@macports.org>
	<loom.20090407T193956-989@post.gmane.org>
	<49DD52E7.5080507@macports.org>
	<C78CEB2C-A1DB-4862-AC3E-6BB4C86C6D2D@macports.org>
	<49DDDAE0.4090606@macports.org>
Message-ID: <0E8CCF9A-40B3-463B-89D5-3BE691727F54@macports.org>


On Apr 9, 2009, at 06:24, Rainer M?ller wrote:

> Ryan Schmidt wrote:
>
>> I still think rather than devote a lot of energy to this mechanism,
>> we should instead focus on building binaries, and let the server
>> merge them together -- or even let the user download both the powerpc
>> and intel binaries and have the user's macports merge them. Either
>> way, we wouldn't have to worry about figuring out how to let the
>> phases run multiple times, because the server would just run "port
>> install" multiple times instead.
>
> This sounds quite complicated. How would that work with the current
> image mode? Do merge on activate and split on deactivate?
>
> Are you planning to let the user install additional architectures time
> by time? Which would mean we need to track dependencies per
> architecture. Also we would need to ensure that no two different
> versions are merged together.

My original suggestion:

Two build servers per major OS:

Xserve G5: builds a port for ppc and again for ppc64
Xserve Xeon: builds a port for i386 and again for x86_64

Both build servers send both build products to a binaries server,  
which combines all four builds into a universal build, possibly using  
special instructions in the portfile for how to merge some files if  
automated lipo or diff, as in muniversal, won't work.

Someone pointed out that to allow the user to select any combination  
of variants, as we currently allow in macports.conf, the binaries  
server would have to create many different combinations of these  
(e.g. ppc+i386, i386+x86_64, ppc+ppc64+i386+x86_64, etc.). So that  
would take a lot of time to create and space to store. Some of the  
combinations might even be silly (e.g. ppc64+i386?).

On the other hand, my motivation for the above was so that a user who  
wants, say, all 4 archs only has to download a single package instead  
of 4 packages, which probably contain some amount of redundant  
information. That amount would vary widely by port. Some ports might  
have no shared files, or just a readme; others might have megs of  
documentation or even, in the case of some games, hundreds of megs of  
assets.

We could consider the idea of splitting ports with lots of shared  
arch-agnostic data into a separate port, which would be marked as  
arch-agnostic via a new syntax. This would cause some headaches for  
each port to switch to this layout.


From ryandesign at macports.org  Thu Apr  9 06:00:56 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 9 Apr 2009 08:00:56 -0500
Subject: [49158] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl
In-Reply-To: <49DDDDC8.5050604@macports.org>
References: <loom.20090404T194101-520@post.gmane.org>	<49DB5DEB.7020701@macports.org>	<loom.20090407T193956-989@post.gmane.org>	<49DD52E7.5080507@macports.org>	<C78CEB2C-A1DB-4862-AC3E-6BB4C86C6D2D@macports.org>
	<loom.20090409T033610-916@post.gmane.org>
	<49DDDDC8.5050604@macports.org>
Message-ID: <0C24A516-FEF2-469E-B26A-97EA80F01E75@macports.org>

On Apr 9, 2009, at 06:36, Rainer M?ller wrote:

> MacPorts just didn't manage to deliver reliable PowerPC/Intel  
> universal
> building in time. I would say most people already don't need this  
> anymore.

Perhaps there was never a great need for ppc/i386 universal binaries  
in MacPorts. The advantage to the user of universal binaries is  
having only a single version to download -- not having to think about  
what version to download. With MacPorts, we already have only one  
version to download (the source) and it is built correctly for the  
user's computer.


If we start providing binaries, we can certainly start with Intel  
Leopard binaries only. This would cover the majority of users. But I  
think there is still value in offering PowerPC Leopard and Tiger  
binaries. PowerPC users may not be as plentiful, but they are in  
greater need of binaries, as their computers are much slower and take  
much longer to build software.



From max at inmachina.com  Thu Apr  9 16:17:14 2009
From: max at inmachina.com (Maximilian Nickel)
Date: Fri, 10 Apr 2009 01:17:14 +0200
Subject: livecheck-helper.sh
Message-ID: <7bad5d350904091617m1d29796cl2ce910e61699b536@mail.gmail.com>

Hi,
i wrote a small script that livechecks all ports for a given maintainer and
prints or mails the output. It only sends a mail if there are updates, so
you can run it as a cronjob without getting useless mails everyday. You can
also add additional ports you want to check or include all open/nomaintainer
ports.
'livecheck-helper.sh -help' should explain all available options.

It's a simple script but i thought i share it as it might be useful for
somebody else. You can get it here:
http://drop.io/2manyvariables/asset/livecheck-helper-sh

Cheers
/max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090410/a68e82d6/attachment.html>

From ryandesign at macports.org  Fri Apr 10 06:01:13 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 10 Apr 2009 08:01:13 -0500
Subject: [49345] branches/new-help-system/base/doc
In-Reply-To: <20090408035845.372D1147819C@beta.macosforge.org>
References: <20090408035845.372D1147819C@beta.macosforge.org>
Message-ID: <F6D39D8B-DAFC-471F-8A22-80F909FFC873@macports.org>


On Apr 7, 2009, at 22:58, raimue at macports.org wrote:

> Revision: 49345
>           http://trac.macports.org/changeset/49345
> Author:   raimue at macports.org
> Date:     2009-04-07 20:58:44 -0700 (Tue, 07 Apr 2009)
> Log Message:
> -----------
> doc:
> Converted port.1 to asciidoc syntax in port.1.txt. Has some rough  
> edges, but
> contains everything from the old man page.

I thought we had an existing effort to produce port.1 out of the  
Guide sources. Has that been abandoned now?



From ryandesign at macports.org  Fri Apr 10 07:43:07 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 10 Apr 2009 09:43:07 -0500
Subject: livecheck-helper.sh
In-Reply-To: <7bad5d350904091617m1d29796cl2ce910e61699b536@mail.gmail.com>
References: <7bad5d350904091617m1d29796cl2ce910e61699b536@mail.gmail.com>
Message-ID: <E5DFA073-7D71-470F-BC20-0184F8C63A35@macports.org>


On Apr 9, 2009, at 18:17, Maximilian Nickel wrote:

> i wrote a small script that livechecks all ports for a given  
> maintainer and prints or mails the output. It only sends a mail if  
> there are updates, so you can run it as a cronjob without getting  
> useless mails everyday. You can also add additional ports you want  
> to check or include all open/nomaintainer ports.
> 'livecheck-helper.sh -help' should explain all available options.
>
> It's a simple script but i thought i share it as it might be useful  
> for somebody else. You can get it here:
> http://drop.io/2manyvariables/asset/livecheck-helper-sh

Small typo: "Specifiy" should be "Specify"

I personally use "port livecheck maintainer:ryandesign" to check my  
ports.



From alakazam at macports.org  Fri Apr 10 08:15:31 2009
From: alakazam at macports.org (Olivier Le Floch)
Date: Fri, 10 Apr 2009 17:15:31 +0200
Subject: livecheck-helper.sh
In-Reply-To: <E5DFA073-7D71-470F-BC20-0184F8C63A35@macports.org>
References: <7bad5d350904091617m1d29796cl2ce910e61699b536@mail.gmail.com>
	<E5DFA073-7D71-470F-BC20-0184F8C63A35@macports.org>
Message-ID: <C972F2D1-22D1-4737-B30E-024E5A5B34F2@macports.org>

On 10 avr. 09, at 16:43, Ryan Schmidt wrote:

> I personally use "port livecheck maintainer:ryandesign" to check my  
> ports.

By the way : is there a command to list ports that do not have a  
livecheck ? (a flag for livecheck, for instance)

From raimue at macports.org  Fri Apr 10 13:42:33 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Fri, 10 Apr 2009 22:42:33 +0200
Subject: NewHelpSystem & man pages
In-Reply-To: <fc.004c4c5811efa0e7004c4c5811efa0e7.11f3c16d@biola.edu>
References: <fc.004c4c5811efa0e7004c4c5811efa0e7.11f3c16d@biola.edu>
Message-ID: <49DFAF39.2070304@macports.org>

For everyone who did not notice yet what this is about, I documented my
plans about a new help system based on AsciiDoc at
<http://trac.macports.org/wiki/NewHelpSystem>.

markd at macports.org wrote:
> I just want to restate that there is a current project underway to source
> new man pages out of the guide that has been tested, though the content of
> the port man page has not been composed yet.  I also said my intent is to
> finish the sections of the guide that contain the new man page content
> this summer.
> 
> It seems to me you intend to supercede the new man page sources being
> constructed in doc-new/man/xml/*.  Is that correct?  If so we need to have
> some community consensus on that since it seems to me that would mean our
> projects cannot happen at the same time, and also that my effort with
> simon@ to source the man pages out of the guide and yours to source parts
> of the guide from the man pages would each require a differently
> structured guide.

I know that your long term goal was to integrate man pages and guide
together. But I didn't know yet that work already started on this. Now I
am looking at the man pages in XML format in doc-new/man/xml/* which are
untouched for over a year now and thus outdated as we continued to work
on them in base/doc/. Sorry that I was not aware of these existing man
pages there, but for me this project looks stalled for too long.

The old plain roff format for man pages was just too cryptic and
uncommon, so we are in the need for a new format. My intent with
choosing AsciiDoc as the source for the new man pages is trying to
satisfy both the need for a simple format and still being able to
integrate it into the guide. Simple formats for documentation have been
requested by Florian Ebeling some time ago [1] and I still second that
request.

Let's just compare a little bit of the XML and AsciiDoc format.

XML:

    <refsection>
      <title>GLOBAL OPTIONS</title>

      <variablelist>
        <varlistentry>
          <term><option>-q</option></term>

          <listitem>
            <para>quiet mode (suppress messages)</para>
          </listitem>
        </varlistentry>

        <varlistentry>
          <term><option>-v</option></term>

          <listitem>
            <para>verbose mode (generate verbose messages)</para>
          </listitem>
        </varlistentry>


AsciiDoc:

    GLOBAL OPTIONS
    --------------

    -v::
        Verbose mode, generates verbose messages

    -d::
        Debug mode, generate debugging messages, implies -v


And now please tell me honestly, which of these two do you find more
intuitive and readable?

For me it is totally the AsciiDoc format which I prefer to write and
edit. XML is just too cumbersome. You may disagree with me, but this is
my point of view. In my opinion it is still the format which stops
people from contributing to the guide.

You can see more at port.1.txt [2], where I already converted the
current port(1) man page to AsciiDoc syntax.

AsciiDoc internally also uses Docbook XML and allows that as output
format, so it will be no problem to integrate these man pages into the
guide. If you want to view that, just checkout the new branch and run
`make xml in` the base/doc directory.

Rainer

[1]
http://lists.macosforge.org/pipermail/macports-dev/2009-January/006953.html
[2]
http://trac.macports.org/browser/branches/new-help-system/base/doc/port.1.txt

PS: Sorry Mark, you may receive this mail twice now, but the list
address in your original mail was wrong, which I only noticed as my
reply bounced.

From raimue at macports.org  Fri Apr 10 13:44:08 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Fri, 10 Apr 2009 22:44:08 +0200
Subject: [49345] branches/new-help-system/base/doc
In-Reply-To: <F6D39D8B-DAFC-471F-8A22-80F909FFC873@macports.org>
References: <20090408035845.372D1147819C@beta.macosforge.org>
	<F6D39D8B-DAFC-471F-8A22-80F909FFC873@macports.org>
Message-ID: <49DFAF98.2030602@macports.org>

Ryan Schmidt wrote:
> On Apr 7, 2009, at 22:58, raimue at macports.org wrote:
> 
>> Revision: 49345
>>           http://trac.macports.org/changeset/49345
>> Author:   raimue at macports.org
>> Date:     2009-04-07 20:58:44 -0700 (Tue, 07 Apr 2009)
>> Log Message:
>> -----------
>> doc:
>> Converted port.1 to asciidoc syntax in port.1.txt. Has some rough  
>> edges, but
>> contains everything from the old man page.
> 
> I thought we had an existing effort to produce port.1 out of the  
> Guide sources. Has that been abandoned now?

Over a year without changes to the XML man pages in doc-new/man/xml or
any progress reports is what I would call abandoned, yes.

Rainer


From jeremy at lavergne.gotdns.org  Fri Apr 10 13:45:16 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Fri, 10 Apr 2009 16:45:16 -0400
Subject: NewHelpSystem & man pages
In-Reply-To: <49DFAF39.2070304@macports.org>
References: <fc.004c4c5811efa0e7004c4c5811efa0e7.11f3c16d@biola.edu>
	<49DFAF39.2070304@macports.org>
Message-ID: <892343C6-7DF4-45BC-B311-DA32206F5A75@lavergne.gotdns.org>

> I know that your long term goal was to integrate man pages and guide  
> together. But I didn't know yet that work already started on this.  
> Now I am looking at the man pages in XML format in doc-new/man/xml/*  
> which are untouched for over a year now and thus outdated as we  
> continued to work on them in base/doc/. Sorry that I was not aware  
> of these existing man pages there, but for me this project looks  
> stalled for too long.
>
> ?
>
> And now please tell me honestly, which of these two do you find more
> intuitive and readable?

You might also check out pxsl (port:pxsl-tools).  It might happen to  
be useful for this operation.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2435 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090410/6b265cac/attachment.bin>

From ryandesign at macports.org  Fri Apr 10 15:53:29 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 10 Apr 2009 17:53:29 -0500
Subject: [49479] trunk/dports/games/larn/Portfile
In-Reply-To: <20090410220640.5593B14FBF7B@beta.macosforge.org>
References: <20090410220640.5593B14FBF7B@beta.macosforge.org>
Message-ID: <6CD06E45-3F00-4FA7-8DB6-C026DEC17E06@macports.org>

On Apr 10, 2009, at 17:06, aschenke at macports.org wrote:

> Revision: 49479
>           http://trac.macports.org/changeset/49479
> Author:   aschenke at macports.org
> Date:     2009-04-10 15:06:39 -0700 (Fri, 10 Apr 2009)
> Log Message:
> -----------
> added proper score & logging support for multiuser environment
>
> Modified Paths:
> --------------
>     trunk/dports/games/larn/Portfile
>
> Modified: trunk/dports/games/larn/Portfile
> ===================================================================
> --- trunk/dports/games/larn/Portfile	2009-04-10 19:52:47 UTC (rev  
> 49478)
> +++ trunk/dports/games/larn/Portfile	2009-04-10 22:06:39 UTC (rev  
> 49479)
> @@ -37,7 +37,9 @@
>                          depends_lib-delete port:libcompat
>                      }
>
> -configure           {
> +configure           {
> +						addgroup games
> +
>                          reinplace "s|MAN|MAN6|" ${worksrcpath}/ 
> Makefile
>                          reinplace "s|/usr/share/games|${prefix}/ 
> share|g" ${worksrcpath}/pathnames.h
>                          reinplace "s|/var/games|${prefix}/var/ 
> games|g" ${worksrcpath}/pathnames.h
> @@ -45,11 +47,11 @@
>
>  destroot            {
>                          xinstall -m 755 -d ${destroot}${prefix}/ 
> share/larn
> -                        xinstall -m 755 -c ${worksrcpath}/larn $ 
> {destroot}${prefix}/bin
> +                        xinstall -m 2755 -g games -c $ 
> {worksrcpath}/larn ${destroot}${prefix}/bin
>                          xinstall -m 644 -c ${worksrcpath}/larn. 
> 6.gz ${destroot}${prefix}/share/man/man6
>                          xinstall -m 644 -c ${worksrcpath}/datfiles/ 
> larn.help ${destroot}${prefix}/share/larn
>                          xinstall -m 644 -c ${worksrcpath}/datfiles/ 
> larnmaze ${destroot}${prefix}/share/larn
>                          xinstall -m 775 -d ${destroot}${prefix}/ 
> var/games/larn
> -                        xinstall -m 660 -c /dev/null ${destroot}$ 
> {prefix}/var/games/larn/lscore12.0
> -                        xinstall -m 660 -c /dev/null ${destroot}$ 
> {prefix}/var/games/larn/llog12.0
> +                        xinstall -m 660 -g games -c /dev/null $ 
> {destroot}${prefix}/var/games/larn/lscore12.0
> +                        xinstall -m 660 -g games -c /dev/null $ 
> {destroot}${prefix}/var/games/larn/llog12.0
>                      }

You probably do not want score and logging files registered to the  
port, because they will be overwritten when the port is upgraded.  
High score and logging files should probably be persistent across  
port upgrades.




From ryandesign at macports.org  Fri Apr 10 15:58:30 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 10 Apr 2009 17:58:30 -0500
Subject: livecheck-helper.sh
In-Reply-To: <C972F2D1-22D1-4737-B30E-024E5A5B34F2@macports.org>
References: <7bad5d350904091617m1d29796cl2ce910e61699b536@mail.gmail.com>
	<E5DFA073-7D71-470F-BC20-0184F8C63A35@macports.org>
	<C972F2D1-22D1-4737-B30E-024E5A5B34F2@macports.org>
Message-ID: <F0EC38C2-DEBE-4696-B28B-96DCE5B3B1AA@macports.org>

On Apr 10, 2009, at 10:15, Olivier Le Floch wrote:

> By the way : is there a command to list ports that do not have a  
> livecheck ? (a flag for livecheck, for instance)

I don't know one. I would probably whip something up with grep.

All ports do inherit a default livecheck setup, but it often doesn't  
work and needs customization or to be overridden completely.



From ryandesign at macports.org  Fri Apr 10 23:22:38 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 11 Apr 2009 01:22:38 -0500
Subject: [49492] trunk/dports/editors/MacVim
In-Reply-To: <20090411014144.6CFBA1504FAA@beta.macosforge.org>
References: <20090411014144.6CFBA1504FAA@beta.macosforge.org>
Message-ID: <F3E9BC69-D103-4E80-B668-4F4C669F0DE6@macports.org>


On Apr 10, 2009, at 20:41, raimue at macports.org wrote:

> -variant python description {Enable Python scripting} {
> -    configure.args-append   --enable-pythoninterp
> +variant python requires python25 description {Compatibility  
> variant, requires +python25} {}
> +variant python25 description {Enable Python scripting} {
> +    configure.args-append   --enable-pythoninterp --with-python=$ 
> {prefix}/bin/python2.5
> +    patchfiles-append       patch-python.diff
>      depends_lib-append      port:python25
>  }
> +variant python26 description {Enable Python scripting} {
> +    configure.args-append   --enable-pythoninterp --with-python=$ 
> {prefix}/bin/python2.6
> +    patchfiles-append       patch-python.diff
> +    depends_lib-append      port:python26
> +}

python25 and python26 should conflict with one another, yes?


From ryandesign at macports.org  Fri Apr 10 23:26:30 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 11 Apr 2009 01:26:30 -0500
Subject: [49481] trunk/dports/editors
In-Reply-To: <20090410231136.8FC8814FE79B@beta.macosforge.org>
References: <20090410231136.8FC8814FE79B@beta.macosforge.org>
Message-ID: <4777A16B-C58D-4F7D-9636-E32A1C77506F@macports.org>


On Apr 10, 2009, at 18:11, raimue at macports.org wrote:

> +pre-configure {
> +    system "cd ${worksrcpath}/src && make autoconf"
> +}

This could be


use_autoconf yes
autoconf.dir ${worksrcpath}/src


right?


From raimue at macports.org  Sat Apr 11 02:28:48 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 11 Apr 2009 11:28:48 +0200
Subject: [49481] trunk/dports/editors
In-Reply-To: <4777A16B-C58D-4F7D-9636-E32A1C77506F@macports.org>
References: <20090410231136.8FC8814FE79B@beta.macosforge.org>
	<4777A16B-C58D-4F7D-9636-E32A1C77506F@macports.org>
Message-ID: <49E062D0.5030701@macports.org>

Ryan Schmidt wrote:
> On Apr 10, 2009, at 18:11, raimue at macports.org wrote:
> 
>> +pre-configure {
>> +    system "cd ${worksrcpath}/src && make autoconf"
>> +}
> 
> This could be
> 
> 
> use_autoconf yes
> autoconf.dir ${worksrcpath}/src

The vim autoconf setup is a bit special. They have src/configure.in but
keep the generated file at src/auto/configure. The Makefile provides an
autoconf target and warns against running autoconf manually, so that's
why I did it this way.

Rainer

From raimue at macports.org  Sat Apr 11 02:31:56 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 11 Apr 2009 11:31:56 +0200
Subject: [49492] trunk/dports/editors/MacVim
In-Reply-To: <F3E9BC69-D103-4E80-B668-4F4C669F0DE6@macports.org>
References: <20090411014144.6CFBA1504FAA@beta.macosforge.org>
	<F3E9BC69-D103-4E80-B668-4F4C669F0DE6@macports.org>
Message-ID: <49E0638C.4010603@macports.org>

Ryan Schmidt wrote:
> On Apr 10, 2009, at 20:41, raimue at macports.org wrote:
> 
>> -variant python description {Enable Python scripting} {
>> -    configure.args-append   --enable-pythoninterp
>> +variant python requires python25 description {Compatibility  
>> variant, requires +python25} {}
>> +variant python25 description {Enable Python scripting} {
>> +    configure.args-append   --enable-pythoninterp --with-python=$ 
>> {prefix}/bin/python2.5
>> +    patchfiles-append       patch-python.diff
>>      depends_lib-append      port:python25
>>  }
>> +variant python26 description {Enable Python scripting} {
>> +    configure.args-append   --enable-pythoninterp --with-python=$ 
>> {prefix}/bin/python2.6
>> +    patchfiles-append       patch-python.diff
>> +    depends_lib-append      port:python26
>> +}
> 
> python25 and python26 should conflict with one another, yes?

Absolutely right. Thanks for the hint :-)
Marked them as conflicting in r49504.

Rainer


From florian.ebeling at gmail.com  Sat Apr 11 06:36:19 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Sat, 11 Apr 2009 15:36:19 +0200
Subject: NewHelpSystem & man pages
In-Reply-To: <49DFAF39.2070304@macports.org>
References: <fc.004c4c5811efa0e7004c4c5811efa0e7.11f3c16d@biola.edu>
	<49DFAF39.2070304@macports.org>
Message-ID: <5cbbe4ae0904110636p5c20e86dg84c811c5b7b9e55b@mail.gmail.com>

On Fri, Apr 10, 2009 at 10:42 PM, Rainer M?ller <raimue at macports.org> wrote:
> For everyone who did not notice yet what this is about, I documented my
> plans about a new help system based on AsciiDoc at
> <http://trac.macports.org/wiki/NewHelpSystem>.

Really good to see an initiative to shape in the doc area! The current
state of affairs was not really satisfying. Mark has probably good
reasons why he couldn't bring in more time, but we shouldn't stay in
write-lock mode for too long on that.

Do I get it correct that the guide will be maintained separately for
now, after the new help system plan?

In which ways can people help the effort? (Maybe that would be a good
additional note on the wiki page to point out.)

Cheers,
Florian

-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com

From febeling at macports.org  Sat Apr 11 07:12:36 2009
From: febeling at macports.org (C. Florian Ebeling)
Date: Sat, 11 Apr 2009 16:12:36 +0200
Subject: Section pages with policies for Ruby, Python, Perl? (and others?)
Message-ID: <5cbbe4ae0904110712u6b373d87x42b53f96fbec1d5f@mail.gmail.com>

I yesterday threw together a RubySection page in the wiki. Now I
wanted to hear thoughts if we should add one for every group of ports
where we have some implicit policy of how to add ports and if you like
the idea at all.

I think of them to state how ports are handled in a certain
special-interest section: wether to add them at all or rather use
package managers (like gem, eggs, pear, cpan) and point users there,
who the interested maintainers for a certain section are, and other
topics which would fit here.

Another question that tends to come up regularly is the one after
dealing with new releases, and how different versions are kept
available (executable suffices, or *_select symlink configuration).
Another question might be the one after implementions (at least for
Ruby case). All these things are not really well suited for main
documentation and are quite well kept in wiki. That way they can
evolve more easily as well. Parts might also end up being taken into
core docs if they establish enough.

I would see at least PythonSection, and PerlSection, but there are
probably many others which might make sense. Do I overlook some other
place where such information is kept? What do you think?

Florian

-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com

From alakazam at macports.org  Sat Apr 11 07:42:08 2009
From: alakazam at macports.org (Olivier Le Floch)
Date: Sat, 11 Apr 2009 16:42:08 +0200
Subject: [49481] trunk/dports/editors
In-Reply-To: <49E062D0.5030701@macports.org>
References: <20090410231136.8FC8814FE79B@beta.macosforge.org>
	<4777A16B-C58D-4F7D-9636-E32A1C77506F@macports.org>
	<49E062D0.5030701@macports.org>
Message-ID: <2B6C6091-C58A-4130-B1B8-DAFDA1612337@macports.org>

On 11 avr. 09, at 11:28, Rainer M?ller wrote:

> Ryan Schmidt wrote:
>> On Apr 10, 2009, at 18:11, raimue at macports.org wrote:
>>
>>> +pre-configure {
>>> +    system "cd ${worksrcpath}/src && make autoconf"
>>> +}
>>
>> This could be
>>
>>
>> use_autoconf yes
>> autoconf.dir ${worksrcpath}/src
>
> The vim autoconf setup is a bit special. They have src/configure.in  
> but
> keep the generated file at src/auto/configure. The Makefile provides  
> an
> autoconf target and warns against running autoconf manually, so that's
> why I did it this way.

I think we should document sections in portfiles where we voluntarily  
do not follow conventions.

From arthurk at macports.org  Sat Apr 11 10:46:04 2009
From: arthurk at macports.org (Arthur Koziel)
Date: Sat, 11 Apr 2009 19:46:04 +0200
Subject: "Lite" vs. "Full" Python Ports
Message-ID: <F4917587-3230-4ED6-98BB-83F7EB14DAB7@macports.org>

Hello,

I'm writing this because of ticket #12369 [http://trac.macports.org/ticket/12369 
], which is 21 months old and still hasn't been resolved. The general  
problem is whether the python25 port should include core modules  
(hashlib, sqlite3, ...) or not.

The current python25 port doesn't install the core modules. It expects  
the user to install the ones he need. This leads to some confusion, as  
new users generally assume that "core modules" like hashlib should  
always be available (and a lot python script do rely on them).

On the other hand, if the python25 port would enable all modules a lot  
of dependencies would get pulled in (9 in total; see the third comment  
in the ticket for a list). Not everyone wants to have these ports  
installed. Some people just want to have a minimal python interpreter.

Additionally, there seems to be a inconsistency with all python ports  
regarding this issue. The python24 port doesn't install core modules  
(same as python25) but python26 installs them. It would be great if we  
could have a consistent approach to this.

Arthur.


From raimue at macports.org  Sat Apr 11 11:23:20 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 11 Apr 2009 20:23:20 +0200
Subject: "Lite" vs. "Full" Python Ports
In-Reply-To: <F4917587-3230-4ED6-98BB-83F7EB14DAB7@macports.org>
References: <F4917587-3230-4ED6-98BB-83F7EB14DAB7@macports.org>
Message-ID: <49E0E018.2060504@macports.org>

Arthur Koziel wrote:
> The current python25 port doesn't install the core modules. It expects  
> the user to install the ones he need. This leads to some confusion, as  
> new users generally assume that "core modules" like hashlib should  
> always be available (and a lot python script do rely on them).
> 
> On the other hand, if the python25 port would enable all modules a lot  
> of dependencies would get pulled in (9 in total; see the third comment  
> in the ticket for a list). Not everyone wants to have these ports  
> installed. Some people just want to have a minimal python interpreter.

9 direct dependencies, which of course have other dependencies again.

Here is a diff of 'port-rdeps -r python25' for both versions:

--- python25-no-modules.txt
+++ python25-modules.txt
@@ -1,7 +1,36 @@
 Dependencies of python25:
   gettext
     libiconv
       gperf
     ncurses
       ncursesw
     expat
+  zlib
+  openssl
+  tk
+    tcl
+    Xft2
+      xrender
+        xorg-libX11
+          xorg-libXdmcp
+            pkgconfig
+            xorg-xproto
+          xorg-libXau
+          xorg-bigreqsproto
+          xorg-xcmiscproto
+          xorg-xtrans
+          xorg-xextproto
+          xorg-xf86bigfontproto
+          xorg-inputproto
+          xorg-kbproto
+        xorg-renderproto
+      freetype
+      fontconfig
+    xorg-libXScrnSaver
+      xorg-libXext
+      xorg-scrnsaverproto
+  sqlite3
+    readline
+  db46
+  bzip2
+  gdbm

> Additionally, there seems to be a inconsistency with all python ports  
> regarding this issue. The python24 port doesn't install core modules  
> (same as python25) but python26 installs them. It would be great if we  
> could have a consistent approach to this.

Consistency +1

In my opinion, most users won't need tkinter and thus do not need to
install tk. As you can see from above, this is what pulls the most
dependencies in. So what about removing only tk from the default python
builds to maintain less dependencies, but offer more features by default?

But you could also say that would be inconsistent again :-)

Rainer

From raimue at macports.org  Sat Apr 11 13:11:21 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Sat, 11 Apr 2009 22:11:21 +0200
Subject: "Lite" vs. "Full" Python Ports
In-Reply-To: <3a73f7f00904111251p48969733jf0c76bd9d4b792d@mail.gmail.com>
References: <F4917587-3230-4ED6-98BB-83F7EB14DAB7@macports.org>	
	<49E0E018.2060504@macports.org>
	<3a73f7f00904111251p48969733jf0c76bd9d4b792d@mail.gmail.com>
Message-ID: <49E0F969.5070002@macports.org>

Julio Biason wrote:
> On Sun, Apr 12, 2009 at 4:23 AM, Rainer M?ller <raimue at macports.org> wrote:
>> In my opinion, most users won't need tkinter and thus do not need to
>> install tk. As you can see from above, this is what pulls the most
>> dependencies in. So what about removing only tk from the default python
>> builds to maintain less dependencies, but offer more features by default?
> 
> As a Python user of MacPorts, I'd prefer that those were variants.
> 
> sudo port install python26 +ssl +tk +...

Which would mean you would have to rebuild the whole python port
unnecessarily just to add another module.
Also, with reference to #126 [1] it would be impossible for other ports
to depend on certain features of python.

Rainer

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

PS: http://trac.macports.org/wiki/MailingLists#intro.reply

From julio.biason at gmail.com  Sat Apr 11 13:15:49 2009
From: julio.biason at gmail.com (Julio Biason)
Date: Sun, 12 Apr 2009 06:15:49 +1000
Subject: "Lite" vs. "Full" Python Ports
In-Reply-To: <49E0F969.5070002@macports.org>
References: <F4917587-3230-4ED6-98BB-83F7EB14DAB7@macports.org>
	<49E0E018.2060504@macports.org>
	<3a73f7f00904111251p48969733jf0c76bd9d4b792d@mail.gmail.com>
	<49E0F969.5070002@macports.org>
Message-ID: <3a73f7f00904111315i218ab8a3qb317951f31f19504@mail.gmail.com>

On Sun, Apr 12, 2009 at 6:11 AM, Rainer M?ller <raimue at macports.org> wrote:
>> As a Python user of MacPorts, I'd prefer that those were variants.
>>
>> sudo port install python26 +ssl +tk +...
>
> Which would mean you would have to rebuild the whole python port
> unnecessarily just to add another module.

I know. It just sounds a better way to get things into Python than
trying to find some py25-module in the plethora of py25-modules that
exist in MacPorts right now.

But, then again, it's just my opinion.

-- 
Julio Biason <julio.biason at gmail.com>
Twitter: http://twitter.com/juliobiason

From ryandesign at macports.org  Sat Apr 11 13:21:26 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 11 Apr 2009 15:21:26 -0500
Subject: [49481] trunk/dports/editors
In-Reply-To: <49E062D0.5030701@macports.org>
References: <20090410231136.8FC8814FE79B@beta.macosforge.org>
	<4777A16B-C58D-4F7D-9636-E32A1C77506F@macports.org>
	<49E062D0.5030701@macports.org>
Message-ID: <039363DD-B52E-4C27-B1F6-168C46447EB9@macports.org>

On Apr 11, 2009, at 04:28, Rainer M?ller wrote:

> Ryan Schmidt wrote:
>
>> On Apr 10, 2009, at 18:11, raimue at macports.org wrote:
>>
>>> +pre-configure {
>>> +    system "cd ${worksrcpath}/src && make autoconf"
>>> +}
>>
>> This could be
>>
>>
>> use_autoconf yes
>> autoconf.dir ${worksrcpath}/src
>
> The vim autoconf setup is a bit special. They have src/configure.in  
> but
> keep the generated file at src/auto/configure. The Makefile  
> provides an
> autoconf target and warns against running autoconf manually, so that's
> why I did it this way.

Oh hey. There's a "make" before that "autoconf". Never mind. :)


From ryandesign at macports.org  Sat Apr 11 17:45:03 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 11 Apr 2009 19:45:03 -0500
Subject: "Lite" vs. "Full" Python Ports
In-Reply-To: <3a73f7f00904111315i218ab8a3qb317951f31f19504@mail.gmail.com>
References: <F4917587-3230-4ED6-98BB-83F7EB14DAB7@macports.org>
	<49E0E018.2060504@macports.org>
	<3a73f7f00904111251p48969733jf0c76bd9d4b792d@mail.gmail.com>
	<49E0F969.5070002@macports.org>
	<3a73f7f00904111315i218ab8a3qb317951f31f19504@mail.gmail.com>
Message-ID: <8FD8B36E-9BA2-4774-8AF6-E9B096DEEAF2@macports.org>


On Apr 11, 2009, at 15:15, Julio Biason wrote:

> On Sun, Apr 12, 2009 at 6:11 AM, Rainer M?ller wrote:
>>> As a Python user of MacPorts, I'd prefer that those were variants.
>>>
>>> sudo port install python26 +ssl +tk +...
>>
>> Which would mean you would have to rebuild the whole python port
>> unnecessarily just to add another module.
>
> I know. It just sounds a better way to get things into Python than
> trying to find some py25-module in the plethora of py25-modules that
> exist in MacPorts right now.
>
> But, then again, it's just my opinion.

They modules aren't that hard to find, are they?

$ port echo py25*ssl*
py25-openssl
py25-socket-ssl
$ port echo py25*tk*
py25-gtk
py25-gtkglext
py25-nltk
py25-pygtksourceview
py25-tkinter
$

I agree with Rainer, this is not what variants should be used for.


From ryandesign at macports.org  Sat Apr 11 17:48:34 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 11 Apr 2009 19:48:34 -0500
Subject: Section pages with policies for Ruby, Python, Perl? (and others?)
In-Reply-To: <5cbbe4ae0904110712u6b373d87x42b53f96fbec1d5f@mail.gmail.com>
References: <5cbbe4ae0904110712u6b373d87x42b53f96fbec1d5f@mail.gmail.com>
Message-ID: <3A1DDAC1-8AEA-4B7E-A472-540DF1B4BB39@macports.org>

On Apr 11, 2009, at 09:12, C. Florian Ebeling wrote:

> I yesterday threw together a RubySection page in the wiki. Now I
> wanted to hear thoughts if we should add one for every group of ports
> where we have some implicit policy of how to add ports and if you like
> the idea at all.
>
> I think of them to state how ports are handled in a certain
> special-interest section: wether to add them at all or rather use
> package managers (like gem, eggs, pear, cpan) and point users there,
> who the interested maintainers for a certain section are, and other
> topics which would fit here.

Whether to add ports at all: I think the answer for all ports if you  
want to be able to declare something as a dependency of another port,  
then you need it to be a port.

Who the maintainers are: I think that's adequately covered by the  
maintainers field in each Portfile.


From ryandesign at macports.org  Sat Apr 11 17:50:19 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 11 Apr 2009 19:50:19 -0500
Subject: NewHelpSystem & man pages
In-Reply-To: <5cbbe4ae0904110636p5c20e86dg84c811c5b7b9e55b@mail.gmail.com>
References: <fc.004c4c5811efa0e7004c4c5811efa0e7.11f3c16d@biola.edu>
	<49DFAF39.2070304@macports.org>
	<5cbbe4ae0904110636p5c20e86dg84c811c5b7b9e55b@mail.gmail.com>
Message-ID: <79F3A6DE-BA51-41A2-AAFA-F57D48E25C37@macports.org>


On Apr 11, 2009, at 08:36, C. Florian Ebeling wrote:

> On Fri, Apr 10, 2009 at 10:42 PM, Rainer M?ller wrote:
>
>> For everyone who did not notice yet what this is about, I  
>> documented my
>> plans about a new help system based on AsciiDoc at
>> <http://trac.macports.org/wiki/NewHelpSystem>.
>
> Really good to see an initiative to shape in the doc area! The current
> state of affairs was not really satisfying. Mark has probably good
> reasons why he couldn't bring in more time, but we shouldn't stay in
> write-lock mode for too long on that.
>
> Do I get it correct that the guide will be maintained separately for
> now, after the new help system plan?

I didn't get the impression that Rainer's plan in any way affected  
the current Guide, only the manpages.

If Rainer's effort with new manpages using asciidoc is successful, we  
could of course discuss the idea of migrating the Guide over to that  
format as well.



From ryandesign at macports.org  Sat Apr 11 19:44:21 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 11 Apr 2009 21:44:21 -0500
Subject: [49500] trunk/dports/games/rogue/Portfile
In-Reply-To: <20090411033014.C679A1508D33@beta.macosforge.org>
References: <20090411033014.C679A1508D33@beta.macosforge.org>
Message-ID: <A096776D-157B-4F55-8BFD-7424EE1BF2C7@macports.org>




On Apr 10, 2009, at 22:21, aschenke at macports.org wrote:

> Revision: 49499
>           http://trac.macports.org/changeset/49499
> Author:   aschenke at macports.org
> Date:     2009-04-10 20:21:27 -0700 (Fri, 10 Apr 2009)
> Log Message:
> -----------
> don't track score & log files with port manager (let larn create them)

On Apr 10, 2009, at 22:30, aschenke at macports.org wrote:

> Revision: 49500
>           http://trac.macports.org/changeset/49500
> Author:   aschenke at macports.org
> Date:     2009-04-10 20:30:13 -0700 (Fri, 10 Apr 2009)
> Log Message:
> -----------
> remove score file from port manager tracking (let rogue create it)


On Apr 10, 2009, at 22:35, aschenke at macports.org wrote:
> Revision: 49502
>           http://trac.macports.org/changeset/49502
> Author:   aschenke at macports.org
> Date:     2009-04-10 20:35:58 -0700 (Fri, 10 Apr 2009)
> Log Message:
> -----------
> removed score file from port manager tracking (note: moria requires  
> a score file -- even a blank one -- to be present or it will not  
> run; hence the post-activate code)


Since these revisions change what files get installed by the port,  
you should increase the revision of each port.



From raimue at macports.org  Sun Apr 12 01:49:14 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Sun, 12 Apr 2009 10:49:14 +0200
Subject: NewHelpSystem & man pages
In-Reply-To: <5cbbe4ae0904110636p5c20e86dg84c811c5b7b9e55b@mail.gmail.com>
References: <fc.004c4c5811efa0e7004c4c5811efa0e7.11f3c16d@biola.edu>	
	<49DFAF39.2070304@macports.org>
	<5cbbe4ae0904110636p5c20e86dg84c811c5b7b9e55b@mail.gmail.com>
Message-ID: <49E1AB0A.6020102@macports.org>

C. Florian Ebeling wrote:
> On Fri, Apr 10, 2009 at 10:42 PM, Rainer M?ller <raimue at macports.org> wrote:
>> For everyone who did not notice yet what this is about, I documented my
>> plans about a new help system based on AsciiDoc at
>> <http://trac.macports.org/wiki/NewHelpSystem>.
> 
> Really good to see an initiative to shape in the doc area! The current
> state of affairs was not really satisfying. Mark has probably good
> reasons why he couldn't bring in more time, but we shouldn't stay in
> write-lock mode for too long on that.
> 
> Do I get it correct that the guide will be maintained separately for
> now, after the new help system plan?

My plan is to present help right when you need it - while running port
commands. So if you are unsure what a port command does exactly, you
simply run 'port help <command>' and get a description with additional
usage examples.

One option would have been to just print help texts to stdout, but this
is not really satisfying. For long texts, you would have to scroll up
again in the terminal or use a pipe with less. This is not very comfortable.

I am not about to comment on git version control itself, but I really
like the way the git command line utility offers help by opening man
pages from 'git help'. This is both unintrusive (does not clutter your
scrollback buffer) and is easily accessible (no need to search the web
or long text documents for the right section describing this command).

While these man pages target documentation of the individual port
commands, The Guide is a different resource for help. It is available
online as comprehensive documentation of the port system. I turn there
to understand how the port system or Portfile development works and
to find out which policies are in place.

> In which ways can people help the effort? (Maybe that would be a good
> additional note on the wiki page to point out.)

I added the list of man pages I have thought of currently to the wiki
page. I already converted port.1.txt now to AsciiDoc syntax and did some
small revise.

Also I have written port-install.1.txt, which can already be used as
example for other man pages. So to help with the new man pages, just
pick any from the list (maybe even mark it as taken to avoid conflicts?)
and write something up and commit it to the branch or submit it per Trac
and assign it to me. Of course you can also extend existing man pages to
add additional aspects.

As reference you can use the two man pages I have finished so far and
git man pages [1] as examples. If you want to help but have problems
with the AsciiDoc syntax, just submit what you can come up with so far.
Fine adjustment can still take place. AsciiDoc is also new to me, so I
can't recommend any best practices yet.

The new-help-system branch is not limited to me, of course anybody is
invited to help! :-)

Rainer

[1] http://git.kernel.org/?p=git/git.git;a=tree;f=Documentation

From febeling at macports.org  Sun Apr 12 04:36:55 2009
From: febeling at macports.org (C. Florian Ebeling)
Date: Sun, 12 Apr 2009 13:36:55 +0200
Subject: Section pages with policies for Ruby, Python, Perl? (and others?)
In-Reply-To: <3A1DDAC1-8AEA-4B7E-A472-540DF1B4BB39@macports.org>
References: <5cbbe4ae0904110712u6b373d87x42b53f96fbec1d5f@mail.gmail.com>
	<3A1DDAC1-8AEA-4B7E-A472-540DF1B4BB39@macports.org>
Message-ID: <5cbbe4ae0904120436v78a8658nb0062c7e931bdb1f@mail.gmail.com>

On Sun, Apr 12, 2009 at 2:48 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Apr 11, 2009, at 09:12, C. Florian Ebeling wrote:
>
>> I yesterday threw together a RubySection page in the wiki. Now I
>> wanted to hear thoughts if we should add one for every group of ports
>> where we have some implicit policy of how to add ports and if you like
>> the idea at all.
>>
>> I think of them to state how ports are handled in a certain
>> special-interest section: wether to add them at all or rather use
>> package managers (like gem, eggs, pear, cpan) and point users there,
>> who the interested maintainers for a certain section are, and other
>> topics which would fit here.
>
> Whether to add ports at all: I think the answer for all ports if you want to
> be able to declare something as a dependency of another port, then you need
> it to be a port.

Yes, in that case you have no option. But if you add only those
justified by such dependencies, the selection of ruby ports (to stick with
that example) would look pretty fractioned and weird to a ruby programmer
having an casual look at what MacPorts had to offer to him. So it would
not hurt to have a place which explains the reasoning behind ruby packaging
in general in MacPorts.

>
> Who the maintainers are: I think that's adequately covered by the
> maintainers field in each Portfile.

You can say that he should just run the obvious command

  port info --maintainers category:ruby | grep maintainers | awk
'{print $2}' | sort | uniq -c

and immediately see who is who. ;)

But I thought of this list of maintainers rather like the list of people who
have an opinion and interest in the section. So someone might even
have a small number of ports under the section but is not really
interested in ruby in general beyond that. And then he or she should not
or certainly has no obligation to appear there. Think of it like a special
interest group. If think a suggestion to that effect even was once made
on macports-dev@ and might have influenced me in adding that as well.

I give you another example how this might be helpful. I don't regularly use
python but just recently came across the need because of another app
that depends on it. So I looked at the collection and at the python web site.
2.6 and 3 are current. Looking at the existing library ports I realized that
the ones I need are not there as ports for these. Question now is: should I drop
back to 2.5 and base the app portfile on that or rather add portfiles or
should I abstain from adding the app as port, because we avoid python
library ports and therefore anything that depends on them as well? The
last option is probably not really satisfying, but if installing libs is a real
mess as well, than what to do? And so on. It would help to have a section
page for python which states then that new ports should depend on version
2.x if in doubt and only add lib ports following example port y.



-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com

From florian.ebeling at gmail.com  Sun Apr 12 05:38:51 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Sun, 12 Apr 2009 14:38:51 +0200
Subject: "Lite" vs. "Full" Python Ports
In-Reply-To: <8FD8B36E-9BA2-4774-8AF6-E9B096DEEAF2@macports.org>
References: <F4917587-3230-4ED6-98BB-83F7EB14DAB7@macports.org>
	<49E0E018.2060504@macports.org>
	<3a73f7f00904111251p48969733jf0c76bd9d4b792d@mail.gmail.com>
	<49E0F969.5070002@macports.org>
	<3a73f7f00904111315i218ab8a3qb317951f31f19504@mail.gmail.com>
	<8FD8B36E-9BA2-4774-8AF6-E9B096DEEAF2@macports.org>
Message-ID: <5cbbe4ae0904120538mc7413fbo1c4e231adae5e91@mail.gmail.com>

On Sun, Apr 12, 2009 at 2:45 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On Apr 11, 2009, at 15:15, Julio Biason wrote:
>
>> On Sun, Apr 12, 2009 at 6:11 AM, Rainer M?ller wrote:
>>>>
>>>> As a Python user of MacPorts, I'd prefer that those were variants.
>>>>
>>>> sudo port install python26 +ssl +tk +...
>>>
>>> Which would mean you would have to rebuild the whole python port
>>> unnecessarily just to add another module.
>>
>> I know. It just sounds a better way to get things into Python than
>> trying to find some py25-module in the plethora of py25-modules that
>> exist in MacPorts right now.
>>
>> But, then again, it's just my opinion.
>
> They modules aren't that hard to find, are they?
>
> $ port echo py25*ssl*
> py25-openssl
> py25-socket-ssl
> $ port echo py25*tk*
> py25-gtk
> py25-gtkglext
> py25-nltk
> py25-pygtksourceview
> py25-tkinter

This thread is no bad place to put another plug for my section
pages suggestion. Mentioning the ports which contain the
core modules in different python versions sounds like something
most people would otherwise have trouble finding out.


-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com

From blb at macports.org  Sun Apr 12 14:17:12 2009
From: blb at macports.org (Bryan Blackburn)
Date: Sun, 12 Apr 2009 15:17:12 -0600
Subject: "Lite" vs. "Full" Python Ports
In-Reply-To: <F4917587-3230-4ED6-98BB-83F7EB14DAB7@macports.org>
References: <F4917587-3230-4ED6-98BB-83F7EB14DAB7@macports.org>
Message-ID: <20090412211712.GF15239@ninagal.withay.com>

On Sat, Apr 11, 2009 at 07:46:04PM +0200, Arthur Koziel said:
> Hello,
>
> I'm writing this because of ticket #12369 
> [http://trac.macports.org/ticket/12369], which is 21 months old and still 
> hasn't been resolved. The general problem is whether the python25 port 
> should include core modules (hashlib, sqlite3, ...) or not.

Newer python versions are going with the install-them-all method; see

<http://trac.macports.org/wiki/FAQ#pydeps>

>
> The current python25 port doesn't install the core modules. It expects  
> the user to install the ones he need. This leads to some confusion, as  
> new users generally assume that "core modules" like hashlib should always 
> be available (and a lot python script do rely on them).
>
> On the other hand, if the python25 port would enable all modules a lot of 
> dependencies would get pulled in (9 in total; see the third comment in the 
> ticket for a list). Not everyone wants to have these ports installed. Some 
> people just want to have a minimal python interpreter.

Do note that 'minimal python interpreter' has vague definitions at best;
many expect 'python' to be just that, which includes everything from sqlite3
support to IDLE.app working (which needs tkinter).

Picking between confusing & incomplete installs verses one that brings in a
few megs of other dependencies but works completely and consistency, the
choice should hopefully be clear...

>
> Additionally, there seems to be a inconsistency with all python ports  
> regarding this issue. The python24 port doesn't install core modules  
> (same as python25) but python26 installs them. It would be great if we  
> could have a consistent approach to this.

It would be nice to move 2.4 and 2.5 (or at least 2.5) to the same model as
2.6+, but that is quite a bit of work; not to update the python25 port but
to remove all the dependencies which have built up using those modules that
would no longer be needed.

I've started bringing modules into py26-* from the py- and py25- side, so
maybe we can start moving everything possible over to 2.6 and not worry too
much about the older versions.

Bryan


>
> Arthur.

From ryandesign at macports.org  Mon Apr 13 01:00:55 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 13 Apr 2009 03:00:55 -0500
Subject: [49606] trunk/base/src/port1.0/portactivate.tcl
In-Reply-To: <20090413074025.2D7841566F53@beta.macosforge.org>
References: <20090413074025.2D7841566F53@beta.macosforge.org>
Message-ID: <B8096B93-7853-4D2F-ABA6-694923CE8869@macports.org>


On Apr 13, 2009, at 02:40, perry at macports.org wrote:

> Revision: 49606
>           http://trac.macports.org/changeset/49606
> Author:   perry at macports.org
> Date:     2009-04-13 00:40:18 -0700 (Mon, 13 Apr 2009)
> Log Message:
> -----------
> port1.0/portactivate.tcl - Wrap notes output to the terminal's width.

We already have the wrapline procedure to do this (added in r34354).  
Could this be used here as well, instead of having another separate  
line wrapping implementation?


> Modified Paths:
> --------------
>     trunk/base/src/port1.0/portactivate.tcl
>
> Modified: trunk/base/src/port1.0/portactivate.tcl
> ===================================================================
> --- trunk/base/src/port1.0/portactivate.tcl	2009-04-13 05:55:44 UTC  
> (rev 49605)
> +++ trunk/base/src/port1.0/portactivate.tcl	2009-04-13 07:40:18 UTC  
> (rev 49606)
> @@ -52,12 +52,39 @@
>  set_ui_prefix
>
>  proc portactivate::activate_main {args} {
> -	global portname portversion portrevision portvariants  
> user_options portnotes
> +	global env portname portversion portrevision portvariants  
> user_options portnotes
>  	registry_activate $portname ${portversion}_${portrevision}$ 
> {portvariants} [array get user_options]
>
>      # Display notes at the end of the activation phase.
>      if {[info exists portnotes] && $portnotes ne {}} {
> -        ui_msg \n$portnotes\n
> +        # If env(COLUMNS) exists, limit each line's width to this  
> width.
> +        if {[info exists env(COLUMNS)]} {
> +            set maxlen $env(COLUMNS)
> +
> +            ui_msg ""
> +            foreach line [split $portnotes "\n"] {
> +                set joiner ""
> +                set lines ""
> +                set newline ""
> +
> +                foreach word [split $line " "] {
> +                    if {[string length $newline] + [string length  
> $word] >= $maxlen} {
> +                        lappend lines $newline
> +                        set newline ""
> +                        set joiner ""
> +                    }
> +                    append newline $joiner $word
> +                    set joiner " "
> +                }
> +                if {$newline ne {}} {
> +                    lappend lines $newline
> +                }
> +                ui_msg [join $lines "\n"]
> +            }
> +            ui_msg ""
> +        } else {
> +            ui_msg \n$portnotes\n
> +        }
>      }
>
>      return 0



From perry at macports.org  Mon Apr 13 01:07:56 2009
From: perry at macports.org (Perry Lee)
Date: Mon, 13 Apr 2009 01:07:56 -0700
Subject: [49606] trunk/base/src/port1.0/portactivate.tcl
In-Reply-To: <B8096B93-7853-4D2F-ABA6-694923CE8869@macports.org>
References: <20090413074025.2D7841566F53@beta.macosforge.org>
	<B8096B93-7853-4D2F-ABA6-694923CE8869@macports.org>
Message-ID: <61972D4A-E99A-4C19-ADEB-294B586B432E@macports.org>

On Apr 13, 2009, at 1:00 AM, Ryan Schmidt wrote:
>> Revision: 49606
>>          http://trac.macports.org/changeset/49606
>> Author:   perry at macports.org
>> Date:     2009-04-13 00:40:18 -0700 (Mon, 13 Apr 2009)
>> Log Message:
>> -----------
>> port1.0/portactivate.tcl - Wrap notes output to the terminal's width.
>
> We already have the wrapline procedure to do this (added in r34354).  
> Could this be used here as well, instead of having another separate  
> line wrapping implementation?

I mentioned that in the ticket http://trac.macports.org/ticket/421#comment 
:17.

I'm not sure if there's a way to share the proc since it's in  
port.tcl, but I thought it'd be better to commit it now so at least  
the output looks more uniform than what I had before.

From febeling at macports.org  Mon Apr 13 05:47:11 2009
From: febeling at macports.org (C. Florian Ebeling)
Date: Mon, 13 Apr 2009 14:47:11 +0200
Subject: ruby_select plan, rubygem: dependency operator
Message-ID: <5cbbe4ae0904130547h75e46fa1x3d364588fd2ba31e@mail.gmail.com>

In the last couple days Brett Eisenberg, Wataru Kimura and I have been
discussing
a few changes to the Ruby ports on private mail, and I wanted to put
this publicly onto
the list for dicussion. Nothing earthshaking, but sure worth discussion.

It started with Brett's suggestion to have ruby 1.9 as default ruby,
without suffix.
That is possible already by setting the nosuffix variant. It would
been more convenient
and more consistent across MacPorts to use the *_select approach, which python
and gcc have adopted. This is the solution we have agreed on now among us.

So the course of action will be:
1 rename ruby port to ruby18
2 create ruby_select port

I added the suggestion to maybe have another third step:
3 create port ruby again which is empty mostly, but pulls select_ruby
and symlinks
to default version (which ever that is then) This one is not agreed on yet
and still to be discussed.

Other ideas came up as well. It is not really very convincing to have rubygems
installed through mp, marked as installed, accidentially uninstalled
directly using
the gem command and break downstream apps that rely on these dependencies.
Kimura had the idea to introduce a new dependency type, rubygem: maybe,
which would largely work like path: or lib: dependencies. I like that
approach and will
write a ticket for this.

An open question is wether to include jruby and other implementations as well.
But that can come later as well.

What do you think of the plan? Any commentary, maybe educated by python
experiences?

Florian






-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com

From raimue at macports.org  Mon Apr 13 06:11:25 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Mon, 13 Apr 2009 15:11:25 +0200
Subject: "Lite" vs. "Full" Python Ports
In-Reply-To: <20090412211712.GF15239@ninagal.withay.com>
References: <F4917587-3230-4ED6-98BB-83F7EB14DAB7@macports.org>
	<20090412211712.GF15239@ninagal.withay.com>
Message-ID: <49E339FD.7020509@macports.org>

Bryan Blackburn wrote:
> It would be nice to move 2.4 and 2.5 (or at least 2.5) to the same model as
> 2.6+, but that is quite a bit of work; not to update the python25 port but
> to remove all the dependencies which have built up using those modules that
> would no longer be needed.

The dependencies are not the only problem. An upgrade would always
upgrade python25 before py25-* as this is the dependency chain, so there
is no easy transition.

> I've started bringing modules into py26-* from the py- and py25- side, so
> maybe we can start moving everything possible over to 2.6 and not worry too
> much about the older versions.

Getting rid of python24 would be the first start. Too many ports still
depend on it and so it is very likely to end up having three versions of
python being installed at the same time.

Rainer

From arthurk at macports.org  Mon Apr 13 08:15:36 2009
From: arthurk at macports.org (Arthur Koziel)
Date: Mon, 13 Apr 2009 17:15:36 +0200
Subject: "Lite" vs. "Full" Python Ports
In-Reply-To: <49E339FD.7020509@macports.org>
References: <F4917587-3230-4ED6-98BB-83F7EB14DAB7@macports.org>
	<20090412211712.GF15239@ninagal.withay.com>
	<49E339FD.7020509@macports.org>
Message-ID: <0DA9CCCB-25D5-4764-81A0-828FCBA8B157@macports.org>


On 13.04.2009, at 15:11, Rainer M?ller wrote:

> Bryan Blackburn wrote:
>> It would be nice to move 2.4 and 2.5 (or at least 2.5) to the same  
>> model as
>> 2.6+, but that is quite a bit of work; not to update the python25  
>> port but
>> to remove all the dependencies which have built up using those  
>> modules that
>> would no longer be needed.
>
> The dependencies are not the only problem. An upgrade would always
> upgrade python25 before py25-* as this is the dependency chain, so  
> there
> is no easy transition.
>
>> I've started bringing modules into py26-* from the py- and py25-  
>> side, so
>> maybe we can start moving everything possible over to 2.6 and not  
>> worry too
>> much about the older versions.
>
> Getting rid of python24 would be the first start. Too many ports still
> depend on it and so it is very likely to end up having three  
> versions of
> python being installed at the same time.
>

Here's how I thought of it (using hashlib as an example):

Once the python25 port is updated, the hashlib module will be located  
one level
above the "site-packages" directory. So, all "import hashlib"  
statements would
result in importing the hashlib module installed by python25, not the  
one installed
by py25-hashlib.

There would still be ports depending on py25-hashlib but they would  
work fine.
We could remove the dependency on py25-hashlib from other ports one by  
one
and then finally remove py25-hashlib.

Is this correct, or do I miss something obvious here?

Arthur



From raimue at macports.org  Mon Apr 13 08:44:33 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Mon, 13 Apr 2009 17:44:33 +0200
Subject: "Lite" vs. "Full" Python Ports
In-Reply-To: <0DA9CCCB-25D5-4764-81A0-828FCBA8B157@macports.org>
References: <F4917587-3230-4ED6-98BB-83F7EB14DAB7@macports.org>	<20090412211712.GF15239@ninagal.withay.com>	<49E339FD.7020509@macports.org>
	<0DA9CCCB-25D5-4764-81A0-828FCBA8B157@macports.org>
Message-ID: <49E35DE1.3080002@macports.org>

Arthur Koziel wrote:
> Here's how I thought of it (using hashlib as an example):
> 
> Once the python25 port is updated, the hashlib module will be located  
> one level
> above the "site-packages" directory. So, all "import hashlib"  
> statements would
> result in importing the hashlib module installed by python25, not the  
> one installed
> by py25-hashlib.
> 
> There would still be ports depending on py25-hashlib but they would  
> work fine.
> We could remove the dependency on py25-hashlib from other ports one by  
> one
> and then finally remove py25-hashlib.
> 
> Is this correct, or do I miss something obvious here?

I didn't know the integrated module would be installed into another
directory. If python25 and py25-* would not conflict on any files, this
will work.

Rainer

From markd at macports.org  Mon Apr 13 01:34:29 2009
From: markd at macports.org (markd at macports.org)
Date: Mon, 13 Apr 2009 01:34:29 -0700
Subject: NewHelpSystem & man pages
Message-ID: <fc.004c4c5811f738aa004c4c5811f738aa.11f83b6d@biola.edu>

I sent this to the wrong list address by mistake, so I'm sending it again.

>I know that your long term goal was to integrate man pages and guide
>together. But I didn't know yet that work already started on this. Now I
>am looking at the man pages in XML format in doc-new/man/xml/* which are
>untouched for over a year now and thus outdated as we continued to work
>on them in base/doc/. For me this project looks stalled for too long.

Hi Rainer,

If you can produce better docs than what I've done it doesn't matter what
has already been done.  I would naturally want to use the simplest method
that can produce acceptable output.  If you can't with the method you have
proposed, then it doesn't matter if it has been stalled too long or not as
long as it continues before a better plan arrives.

I only raised the issue that I have already started on man pages only to
say that no one should modify the guide for a new purpose without
consulting the community.  That would be disturbing an ongoing project
that I am working on now, no matter what are one's personal judgements on
what counts as stalled.  It also wouldn't be necessary since if you need
to demonstrate issues related to your project having to do with the guide,
you could always make a copy in your branch.
>
>If Rainer's effort with new manpages using asciidoc is successful, we 
>could of course discuss the idea of migrating the Guide over to that 
>format as well.

The problem from my perspective is that as far as I've been able to tell,
what would count as success seems to have surprisingly little to do with
structure or style (control over which docbook and CSS give to the current
guide), and it appears from the last few messages that a commitment to
using a single source has been dropped or probably soon will be too. 
Aside from the absolute necessity in my opinion to use a single source
(eliminate duplicated effort), the main problem I see, as I've already
said before, is that without a defined structure and style the docs will
not be very consistent and will have no resistance to entropy in any case.

>My intent with
>choosing AsciiDoc as the source for the new man pages is trying to
>satisfy both the need for a simple format and still being able to
>integrate it into the guide. Simple formats for documentation have been
>requested by Florian Ebeling some time ago [1] and I still second that
>request.
>
>Let's just compare a little bit of the XML and AsciiDoc format.

We all know asciidoc is simpler; the question is whether or not the
criteria for success can be met.  I looked at alternatives to XML before I
started the guide (because I want the simplest solution that meets the
goals too) and rejected them as not meeting my criteria for success. 
You've defined the success as the ability to edit bits easily and that is
an easy target to hit, but has nothing to say about product quality and I
think most users have greater expectations for docs than that.  I think
having something like NewHelpSystem is fine, but adding features doesn't
mean ignoring previous design goals or dictating changes unrelated to such
features.

I haven't even seen where you have warned anyone or commented on the
completely generic look of asciidos generated html and the lack of control
for adding future format additions and changes.  Are we ok with a guide
that looks like Git man pages?  I'm not.  Is the communty satisfied with
that?  Or has that been discussed somewhere and I've missed it?  That
would be the first question I would ask, even though the other questions
I've raised would still hold.  If everybody is satisfied with poorly
formatted and structured docs, then I really need to know that.  Because I
am not interested in producing documents that ugly (poorly formatted) or
unsustainable (poorly structured) or the massively error-prone process of
reconciling text manually between guide and man (no single doc source). 
In the case of the former two, it isn't worthy of a product that runs on a
Mac, and in the case of the latter I just have better things to do, and
I'd hope we all do.

I mean no rudeness whatever, I'm just trying to get my point across.  And
I've said it all before and you are quite unimpressed.  That is why I
suppose that we should continue on parallel courses and let the community
decide which is better overall.  This is assuming that the community does
want docs that aspire to have a good design; if not then it is time for me
to retire.  :)

Mark


From blb at macports.org  Mon Apr 13 13:11:25 2009
From: blb at macports.org (Bryan Blackburn)
Date: Mon, 13 Apr 2009 14:11:25 -0600
Subject: ruby_select plan, rubygem: dependency operator
In-Reply-To: <5cbbe4ae0904130547h75e46fa1x3d364588fd2ba31e@mail.gmail.com>
References: <5cbbe4ae0904130547h75e46fa1x3d364588fd2ba31e@mail.gmail.com>
Message-ID: <20090413201125.GC651@ninagal.withay.com>

On Mon, Apr 13, 2009 at 02:47:11PM +0200, C. Florian Ebeling said:
> In the last couple days Brett Eisenberg, Wataru Kimura and I have been
> discussing
> a few changes to the Ruby ports on private mail, and I wanted to put
> this publicly onto
> the list for dicussion. Nothing earthshaking, but sure worth discussion.
> 
> It started with Brett's suggestion to have ruby 1.9 as default ruby,
> without suffix.
> That is possible already by setting the nosuffix variant. It would
> been more convenient
> and more consistent across MacPorts to use the *_select approach, which python
> and gcc have adopted. This is the solution we have agreed on now among us.
> 
> So the course of action will be:
> 1 rename ruby port to ruby18
> 2 create ruby_select port
> 
> I added the suggestion to maybe have another third step:
> 3 create port ruby again which is empty mostly, but pulls select_ruby
> and symlinks
> to default version (which ever that is then) This one is not agreed on yet
> and still to be discussed.

You'll definitely need some sort of upgrade path for anyone with ruby
currently installed; otherwise, if you try to install something which
depends on the new ruby18, that will then fail during activation since it
will conflict with files from ruby.

Also note that upgrading depedencies when installing a new port doesn't
happen automatically, so for those who may not upgrade regularly, this will
still be an issue.

Does this mean there will start to be rb19- ports as well, to have them
depend on ruby19?  Since ruby modules install into version-specific
locations (using rb-bdb's ${prefix}/lib/ruby/vendor_ruby/1.8 path as an
example), it seems like some form of consistency will be needed.  Otherwise
someone installs rb-bdb with ruby18 selected, then later switches to ruby19
and now rb-bdb doesn't work, right?

Bryan


> 
> Other ideas came up as well. It is not really very convincing to have rubygems
> installed through mp, marked as installed, accidentially uninstalled
> directly using
> the gem command and break downstream apps that rely on these dependencies.
> Kimura had the idea to introduce a new dependency type, rubygem: maybe,
> which would largely work like path: or lib: dependencies. I like that
> approach and will
> write a ticket for this.
> 
> An open question is wether to include jruby and other implementations as well.
> But that can come later as well.
> 
> What do you think of the plan? Any commentary, maybe educated by python
> experiences?
> 
> Florian
> 
> 
> -- 
> Florian Ebeling
> Twitter: febeling
> florian.ebeling at gmail.com

From florian.ebeling at gmail.com  Mon Apr 13 13:21:08 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Mon, 13 Apr 2009 22:21:08 +0200
Subject: ruby_select plan, rubygem: dependency operator
In-Reply-To: <20090413201125.GC651@ninagal.withay.com>
References: <5cbbe4ae0904130547h75e46fa1x3d364588fd2ba31e@mail.gmail.com>
	<20090413201125.GC651@ninagal.withay.com>
Message-ID: <5cbbe4ae0904131321t5f0afb6epad18420ba783fec8@mail.gmail.com>

>> So the course of action will be:
>> 1 rename ruby port to ruby18
>> 2 create ruby_select port
>>
>> I added the suggestion to maybe have another third step:
>> 3 create port ruby again which is empty mostly, but pulls select_ruby
>> and symlinks
>> to default version (which ever that is then) This one is not agreed on yet
>> and still to be discussed.
>
> You'll definitely need some sort of upgrade path for anyone with ruby
> currently installed; otherwise, if you try to install something which
> depends on the new ruby18, that will then fail during activation since it
> will conflict with files from ruby.
>
> Also note that upgrading depedencies when installing a new port doesn't
> happen automatically, so for those who may not upgrade regularly, this will
> still be an issue.

Yes, that's true. Didn't think of it. Are you aware of a
similar migration that was handled well and that can
be use as an example to follow?

>
> Does this mean there will start to be rb19- ports as well, to have them
> depend on ruby19? ?Since ruby modules install into version-specific
> locations (using rb-bdb's ${prefix}/lib/ruby/vendor_ruby/1.8 path as an
> example), it seems like some form of consistency will be needed. ?Otherwise
> someone installs rb-bdb with ruby18 selected, then later switches to ruby19
> and now rb-bdb doesn't work, right?

Yes, that's the behaviour of the ruby group code
already. It uses rb19 as prefix for ruby19 ports.

Florian

-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com

From blb at macports.org  Mon Apr 13 14:19:03 2009
From: blb at macports.org (Bryan Blackburn)
Date: Mon, 13 Apr 2009 15:19:03 -0600
Subject: "Lite" vs. "Full" Python Ports
In-Reply-To: <49E35DE1.3080002@macports.org>
References: <F4917587-3230-4ED6-98BB-83F7EB14DAB7@macports.org>
	<20090412211712.GF15239@ninagal.withay.com>
	<49E339FD.7020509@macports.org>
	<0DA9CCCB-25D5-4764-81A0-828FCBA8B157@macports.org>
	<49E35DE1.3080002@macports.org>
Message-ID: <20090413211903.GD651@ninagal.withay.com>

On Mon, Apr 13, 2009 at 05:44:33PM +0200, Rainer M?ller said:
> Arthur Koziel wrote:
> > Here's how I thought of it (using hashlib as an example):
> > 
> > Once the python25 port is updated, the hashlib module will be located  
> > one level
> > above the "site-packages" directory. So, all "import hashlib"  
> > statements would
> > result in importing the hashlib module installed by python25, not the  
> > one installed
> > by py25-hashlib.
> > 
> > There would still be ports depending on py25-hashlib but they would  
> > work fine.
> > We could remove the dependency on py25-hashlib from other ports one by  
> > one
> > and then finally remove py25-hashlib.
> > 
> > Is this correct, or do I miss something obvious here?
> 
> I didn't know the integrated module would be installed into another
> directory. If python25 and py25-* would not conflict on any files, this
> will work.

Right, the way the py25-* version installs it is different than if you
install it directly with python25, that's actually part of the problem with
splitting them out, as mentioned with the -S stuff on #12369:

${prefix}/lib/python2.5/site-packages/_hashlib.so
vs
${prefix}/lib/python2.5/lib-dynload/_hashlib.so

There will probably be confusion however, so a FAQ entry might be nice.

Bryan


> 
> Rainer

From blb at macports.org  Mon Apr 13 14:25:55 2009
From: blb at macports.org (Bryan Blackburn)
Date: Mon, 13 Apr 2009 15:25:55 -0600
Subject: ruby_select plan, rubygem: dependency operator
In-Reply-To: <5cbbe4ae0904131321t5f0afb6epad18420ba783fec8@mail.gmail.com>
References: <5cbbe4ae0904130547h75e46fa1x3d364588fd2ba31e@mail.gmail.com>
	<20090413201125.GC651@ninagal.withay.com>
	<5cbbe4ae0904131321t5f0afb6epad18420ba783fec8@mail.gmail.com>
Message-ID: <20090413212555.GE651@ninagal.withay.com>

On Mon, Apr 13, 2009 at 10:21:08PM +0200, C. Florian Ebeling said:
> >> So the course of action will be:
> >> 1 rename ruby port to ruby18
> >> 2 create ruby_select port
> >>
> >> I added the suggestion to maybe have another third step:
> >> 3 create port ruby again which is empty mostly, but pulls select_ruby
> >> and symlinks
> >> to default version (which ever that is then) This one is not agreed on yet
> >> and still to be discussed.
> >
> > You'll definitely need some sort of upgrade path for anyone with ruby
> > currently installed; otherwise, if you try to install something which
> > depends on the new ruby18, that will then fail during activation since it
> > will conflict with files from ruby.
> >
> > Also note that upgrading depedencies when installing a new port doesn't
> > happen automatically, so for those who may not upgrade regularly, this will
> > still be an issue.
> 
> Yes, that's true. Didn't think of it. Are you aware of a
> similar migration that was handled well and that can
> be use as an example to follow?

Unfortunately no, I think part of the problem is this need hasn't come up
enough for there to be good support to handle it in base.  If there were we
could probably also more easily fix the 'not a directory' issue with
python25 without causing pain.

Unless there's better support in base for such things, the best option may
be to try and document it with the right ports (via ui_msg) and mailing
lists/FAQ/etc that certain things are needed for the newer stuff to work
right...

> 
> >
> > Does this mean there will start to be rb19- ports as well, to have them
> > depend on ruby19? ?Since ruby modules install into version-specific
> > locations (using rb-bdb's ${prefix}/lib/ruby/vendor_ruby/1.8 path as an
> > example), it seems like some form of consistency will be needed. ?Otherwise
> > someone installs rb-bdb with ruby18 selected, then later switches to ruby19
> > and now rb-bdb doesn't work, right?
> 
> Yes, that's the behaviour of the ruby group code
> already. It uses rb19 as prefix for ruby19 ports.

Ah, okay, I didn't see any rb19- ports but didn't look at the group code.
Is there a possibility that they could eventually be merged once #126 is
done, similar to how we'd like the python modules to work, as mentioned in
#16723?

Bryan


> 
> Florian
> 
> -- 
> Florian Ebeling
> Twitter: febeling
> florian.ebeling at gmail.com

From jeremyhu at macports.org  Mon Apr 13 17:51:27 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Mon, 13 Apr 2009 17:51:27 -0700
Subject: [46431] trunk/dports/x11/qt4-x11
In-Reply-To: <20090204221525.E5040E708D3@beta.macosforge.org>
References: <20090204221525.E5040E708D3@beta.macosforge.org>
Message-ID: <7DB03BC6-27DE-471B-A0BF-EFDF57FF77B2@macports.org>

So where is qt4_select?  I see it mentioned in qt4-{x11,mac,kde}, and  
I see the files in ${prefix}/opt/local/etc/select/qt4, but I don't see  
any documentation about how to use them... either as a user or in a  
Portfile to ensure a particular flavor.

On Feb 4, 2009, at 14:15, mcalhoun at macports.org wrote:

> Revision: 46431
>          http://trac.macports.org/changeset/46431
> Author:   mcalhoun at macports.org
> Date:     2009-02-04 14:15:24 -0800 (Wed, 04 Feb 2009)
> Log Message:
> -----------
> qt4-x11: Fix linking of dbus and openssl libraries.
> Remove fix for Leopard OpenGL since it has been fixed in XCode for a  
> while.
> Install necessary files for qt4_select.
>
> Modified Paths:
> --------------
>    trunk/dports/x11/qt4-x11/Portfile
>
> Added Paths:
> -----------
>    trunk/dports/x11/qt4-x11/files/qt4-x11
>
> Modified: trunk/dports/x11/qt4-x11/Portfile
> ===================================================================
> --- trunk/dports/x11/qt4-x11/Portfile	2009-02-04 22:11:31 UTC (rev  
> 46430)
> +++ trunk/dports/x11/qt4-x11/Portfile	2009-02-04 22:15:24 UTC (rev  
> 46431)
> @@ -5,7 +5,7 @@
>
> name                qt4-x11
> version             4.4.3
> -revision            1
> +revision            2
> categories	        x11
> maintainers         mcalhoun
> homepage            http://www.trolltech.com/
> @@ -66,7 +66,12 @@
>
> # -I${prefix}/include should be set in ${configure.args}, but
> #    we instead patch -isystem ${prefix}/include into the configure
> -#    script to avoid conflicts with other ports (e.g. PCRE).
> +#    script to avoid conflicts with other ports (e.g. iconv).
> +# See http://trac.macports.org/ticket/16862
> +#
> +# -dbus-linked prevends qt4 from trying to dynamically load  
> libdbus-1,
> +#     which it is not able to find in ${prefix}
> +# -openssl-linked ensures that the MacPorts openssl is used
> configure.args                                                 \
>     -v                                                         \
>     -confirm-license                                           \
> @@ -75,6 +80,8 @@
>     -examplesdir     ${prefix}/share/${name}/examples          \
>     -demosdir        ${prefix}/share/${name}/demos             \
>     -system-sqlite                                             \
> +    -openssl-linked                                            \
> +    -dbus-linked                                               \
>     -I${prefix}/include/mysql5/mysql                           \
>     -I${prefix}/include/postgresql83                           \
>     -L${prefix}/lib                                            \
> @@ -103,17 +110,6 @@
>     depends_build-append    port:cups-headers
> }
>
> -platform darwin 9 {
> -    post-patch {
> -        # See http://trac.macports.org/wiki/LeopardProblems
> -        set dylibFile \
> -            /System/Library/Frameworks/OpenGL.framework/Versions/A/ 
> Libraries/libGL.dylib
> -        reinplace -E \
> -            "s|^(QMAKE_LFLAGS\[ \t\]*=\[ \t\]*)|\\1 -Wl,-dylib_file, 
> ${dylibFile}:${dylibFile}|g" \
> -            ${worksrcpath}/mkspecs/darwin-g++/qmake.conf
> -    }
> -}
> -
> post-patch {
>     reinplace -E "s|^I_FLAGS=\$|I_FLAGS=-isystem${prefix}/include|" \
>         ${worksrcpath}/configure
> @@ -254,6 +250,8 @@
>     foreach bin [glob ${destroot}${prefix}/bin/*] {
>         file rename ${bin} ${bin}-x11
>     }
> +    # qtconfig is not installed by qt4-mac
> +    file rename ${destroot}${prefix}/bin/qtconfig-x11 ${destroot}$ 
> {prefix}/bin/qtconfig
>
>     # Fix the .pc and .prl files by removing ${destroot}
>     foreach fixfile [glob -nocomplain -directory ${destroot} $ 
> {qt_dir}/lib/pkgconfig/*.pc ${qt_dir}/lib/*.prl ${prefix}/share/$ 
> {name}/demos/shared/*.prl] {
> @@ -262,10 +260,9 @@
>             ${fixfile}
>     }
>
> -    # move pkgconfig dir to another directory to avoid conflict  
> with qt4-mac
> -    # pkg-config should still find it, but qt4-mac will take  
> precedence
> -    xinstall -m 755 -d ${destroot}${prefix}/share/
> -    move ${destroot}${qt_dir}/lib/pkgconfig ${destroot}${prefix}/ 
> share/
> +    # install select file for qt4_select
> +    xinstall -m 755 -d ${destroot}${prefix}/etc/select/qt4
> +    xinstall -m 644 ${filespath}/${name} ${destroot}${prefix}/etc/ 
> select/qt4/
> }
>
> variant webkit description {Use WebKit as html rendering engine in  
> Assistant} {
>
> Added: trunk/dports/x11/qt4-x11/files/qt4-x11
> ===================================================================
> --- trunk/dports/x11/qt4-x11/files/qt4-x11	                         
> (rev 0)
> +++ trunk/dports/x11/qt4-x11/files/qt4-x11	2009-02-04 22:15:24 UTC  
> (rev 46431)
> @@ -0,0 +1,42 @@
> +libexec/qt4-x11/bin/assistant
> +libexec/qt4-x11/bin/assistant_adp
> +libexec/qt4-x11/bin/designer
> +libexec/qt4-x11/bin/linguist
> +libexec/qt4-x11/bin/lrelease
> +libexec/qt4-x11/bin/lupdate
> +libexec/qt4-x11/bin/moc
> +libexec/qt4-x11/bin/pixeltool
> +libexec/qt4-x11/bin/qcollectiongenerator
> +libexec/qt4-x11/bin/qdbus
> +libexec/qt4-x11/bin/qdbuscpp2xml
> +libexec/qt4-x11/bin/qdbusviewer
> +libexec/qt4-x11/bin/qdbusxml2cpp
> +libexec/qt4-x11/bin/qhelpconverter
> +libexec/qt4-x11/bin/qhelpgenerator
> +libexec/qt4-x11/bin/qmake
> +libexec/qt4-x11/bin/qt3to4
> +libexec/qt4-x11/bin/qtdemo
> +libexec/qt4-x11/bin/rcc
> +libexec/qt4-x11/bin/uic
> +libexec/qt4-x11/bin/uic3
> +libexec/qt4-x11/bin/xmlpatterns
> +libexec/qt4-x11/lib/pkgconfig/Qt3Support.pc
> +libexec/qt4-x11/lib/pkgconfig/QtAssistant.pc
> +libexec/qt4-x11/lib/pkgconfig/QtCLucene.pc
> +libexec/qt4-x11/lib/pkgconfig/QtCore.pc
> +libexec/qt4-x11/lib/pkgconfig/QtDBus.pc
> +libexec/qt4-x11/lib/pkgconfig/QtDesigner.pc
> +libexec/qt4-x11/lib/pkgconfig/QtDesignerComponents.pc
> +libexec/qt4-x11/lib/pkgconfig/QtGui.pc
> +libexec/qt4-x11/lib/pkgconfig/QtHelp.pc
> +libexec/qt4-x11/lib/pkgconfig/QtNetwork.pc
> +libexec/qt4-x11/lib/pkgconfig/QtOpenGL.pc
> +libexec/qt4-x11/lib/pkgconfig/QtScript.pc
> +libexec/qt4-x11/lib/pkgconfig/QtSql.pc
> +libexec/qt4-x11/lib/pkgconfig/QtSvg.pc
> +libexec/qt4-x11/lib/pkgconfig/QtTest.pc
> +libexec/qt4-x11/lib/pkgconfig/QtUiTools.pc
> +libexec/qt4-x11/lib/pkgconfig/QtWebKit.pc
> +libexec/qt4-x11/lib/pkgconfig/QtXml.pc
> +libexec/qt4-x11/lib/pkgconfig/QtXmlPatterns.pc
> +libexec/qt4-x11/lib/pkgconfig/phonon.pc
> _______________________________________________
> macports-changes mailing list
> macports-changes at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes


From arthurk at macports.org  Tue Apr 14 02:10:32 2009
From: arthurk at macports.org (Arthur Koziel)
Date: Tue, 14 Apr 2009 11:10:32 +0200
Subject: "Lite" vs. "Full" Python Ports
In-Reply-To: <20090413211903.GD651@ninagal.withay.com>
References: <F4917587-3230-4ED6-98BB-83F7EB14DAB7@macports.org>
	<20090412211712.GF15239@ninagal.withay.com>
	<49E339FD.7020509@macports.org>
	<0DA9CCCB-25D5-4764-81A0-828FCBA8B157@macports.org>
	<49E35DE1.3080002@macports.org>
	<20090413211903.GD651@ninagal.withay.com>
Message-ID: <69527FED-FA3B-47A1-9E5E-F745764F3B8D@macports.org>


On 13.04.2009, at 23:19, Bryan Blackburn wrote:
>
> Right, the way the py25-* version installs it is different than if you
> install it directly with python25, that's actually part of the  
> problem with
> splitting them out, as mentioned with the -S stuff on #12369:
>
> ${prefix}/lib/python2.5/site-packages/_hashlib.so
> vs
> ${prefix}/lib/python2.5/lib-dynload/_hashlib.so
>
> There will probably be confusion however, so a FAQ entry might be  
> nice.
>

That is, if you split the Python 2.5 port in "python2.5" and  
"python2.5-minimal". I thought we would just enable the core modules  
in python25, not split the port. See the "python25-reenable-libs.diff"  
patch on #12369.

> Bryan

Arthur


From kimuraw at macports.org  Tue Apr 14 05:31:53 2009
From: kimuraw at macports.org (kimura wataru)
Date: Tue, 14 Apr 2009 21:31:53 +0900
Subject: trunk "dropPrivileges" question(Re: ruby, macports trunk and setgid)
In-Reply-To: <49DCCC00.4090700@macports.org>
References: <49DCCC00.4090700@macports.org>
Message-ID: <20090414213153565474.8627c3ed@macports.org>

Hi,

I reproduced the problem #19131 on ppc 10.4.11 with trunk r49611.
but succeeded build on ppc 10.5.3 and i386 10.5.6.
ruby port runs ruby(+miniruby) in build process, then ruby do not 
allow some options (-I, -r, -e,..) under uid <> euid or gid <> egid
for security reasons.

I tested `sudo port build ruby' on the follwing environments and
watched the values of uid, euid, gid and egid from running ruby/miniruby.

             uid   euid      gid   egid
  -------------------------------------
  ppc 10.4     0      0        0     -1 
  ppc 10.5     0      0        0      0  
  i38610.5     0      0        0      0

all of port system says:
  DEBUG: changing euid/egid - current euid: 0 - current egid: -1 
  DEBUG: egid changed to: -1 
  DEBUG: euid changed to: 0 

which value of egid, getegid() returns, is the right value, -1 or 0?

On Wed, 08 Apr 2009 09:08:32 -0700, David Evans wrote:
> Ruby fails to build using the usual
> 
> sudo port install/upgrade ruby
> 
> when using MacPorts trunk (but not 1.7.1) because port runs setgid 
> and miniruby that is built and used in the build
> sees that as a security problem and will not run as requested.
> 
> Is this a problem or is there a way to get around this? Are there 
> other ports that don't like running setgid?
> 
> See https://trac.macports.org/ticket/19131
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

From rasmus at macports.org  Tue Apr 14 08:23:40 2009
From: rasmus at macports.org (Rasmus Andersson)
Date: Tue, 14 Apr 2009 17:23:40 +0200
Subject: [python] py25-elixir broken
Message-ID: <a9444a980904140823q1b5980c5o2856dfaea376e15f@mail.gmail.com>

just did sync + upgrade py25-elixir and it looks like someone upgraded
py25-sqlalchemy without upgrading/checking dependencies and/or someone
upgraded py25-elixir and did not test it.

Below is my transcript. Note that openssl could not be installed but
was forced to anyway. But I guess that is not the core problem, right?

$ sudo port sync
$ sudo port upgrade py25-elixir
Password:
Portfile changed since last build; discarding previous state.
--->  Fetching python25
--->  Verifying checksum(s) for python25
--->  Extracting python25
--->  Applying patches to python25
--->  Configuring python25
--->  Building python25
--->  Staging python25 into destroot
--->  Deactivating python25 @2.5.4_0+darwin_9+macosx
--->  Installing python25 @2.5.4_2+darwin_9+macosx
--->  Activating python25 @2.5.4_2+darwin_9+macosx

To fully complete your installation and make python 2.5 the default, please run

	sudo port install python_select
	sudo python_select python25

--->  Cleaning python25
--->  Fetching openssl
--->  Verifying checksum(s) for openssl
--->  Extracting openssl
--->  Applying patches to openssl
--->  Configuring openssl
--->  Building openssl
--->  Staging openssl into destroot
--->  Unable to uninstall openssl 0.9.8k_0, the following ports depend on it:
--->  	wget
--->  	lighttpd
--->  	py25-hashlib
--->  	curl
--->  	nginx
--->  	git-core
--->  	python26
--->  	py25-socket-ssl
--->  	httperf
Warning: Uninstall forced.  Proceeding despite dependencies.
--->  Deactivating openssl @0.9.8k_0
--->  Uninstalling openssl @0.9.8k_0
--->  Installing openssl @0.9.8k_0
--->  Activating openssl @0.9.8k_0
--->  Cleaning openssl
--->  Fetching py25-sqlalchemy
--->  Attempting to fetch SQLAlchemy-0.5.2.tar.gz from
http://trd.no.distfiles.macports.org/python
--->  Verifying checksum(s) for py25-sqlalchemy
--->  Extracting py25-sqlalchemy
--->  Configuring py25-sqlalchemy
--->  Building py25-sqlalchemy
--->  Staging py25-sqlalchemy into destroot
--->  Deactivating py25-sqlalchemy @0.4.7p1_0
--->  Installing py25-sqlalchemy @0.5.2_0
--->  Activating py25-sqlalchemy @0.5.2_0
--->  Cleaning py25-sqlalchemy

$ python2.5 myprogram.py
...
    from elixir.events import *
  File "/opt/local/lib/python2.5/site-packages/elixir/__init__.py",
line 28, in <module>
    from elixir.entity import Entity, EntityMeta, EntityDescriptor, \
  File "/opt/local/lib/python2.5/site-packages/elixir/entity.py", line
14, in <module>
    from sqlalchemy.orm                import Query, MapperExtension,\
ImportError: cannot import name EXT_PASS

$ port version
Version: 1.700

$ uname -a
Darwin apple.spotify.net 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24
17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386

From rasmus at macports.org  Tue Apr 14 08:29:15 2009
From: rasmus at macports.org (Rasmus Andersson)
Date: Tue, 14 Apr 2009 17:29:15 +0200
Subject: [python] py25-elixir broken
In-Reply-To: <a9444a980904140823q1b5980c5o2856dfaea376e15f@mail.gmail.com>
References: <a9444a980904140823q1b5980c5o2856dfaea376e15f@mail.gmail.com>
Message-ID: <a9444a980904140829h30aff2ccx2b8cc243827f019d@mail.gmail.com>

I could temporarily fix this by deactivating py25-sqlalchemy @0.5.2_0
and activating the old py25-sqlalchemy @0.4.7p1_0

Obviously the py25-elixir port is outdated. Support for SQLAlchemy 0.5
first appeared in Elixir 0.6 ("Added support for SQLAlchemy 0.5" ?
http://elixir.ematia.de/trac/browser/elixir/tags/0.6.0/CHANGES). That
is; Elixir <0.6 only works with SQLAlchemy <0.5.

On Tue, Apr 14, 2009 at 17:23, Rasmus Andersson <rasmus at macports.org> wrote:
> just did sync + upgrade py25-elixir and it looks like someone upgraded
> py25-sqlalchemy without upgrading/checking dependencies and/or someone
> upgraded py25-elixir and did not test it.
>
> Below is my transcript. Note that openssl could not be installed but
> was forced to anyway. But I guess that is not the core problem, right?
>
> $ sudo port sync
> $ sudo port upgrade py25-elixir
> Password:
> Portfile changed since last build; discarding previous state.
> ---> ?Fetching python25
> ---> ?Verifying checksum(s) for python25
> ---> ?Extracting python25
> ---> ?Applying patches to python25
> ---> ?Configuring python25
> ---> ?Building python25
> ---> ?Staging python25 into destroot
> ---> ?Deactivating python25 @2.5.4_0+darwin_9+macosx
> ---> ?Installing python25 @2.5.4_2+darwin_9+macosx
> ---> ?Activating python25 @2.5.4_2+darwin_9+macosx
>
> To fully complete your installation and make python 2.5 the default, please run
>
> ? ? ? ?sudo port install python_select
> ? ? ? ?sudo python_select python25
>
> ---> ?Cleaning python25
> ---> ?Fetching openssl
> ---> ?Verifying checksum(s) for openssl
> ---> ?Extracting openssl
> ---> ?Applying patches to openssl
> ---> ?Configuring openssl
> ---> ?Building openssl
> ---> ?Staging openssl into destroot
> ---> ?Unable to uninstall openssl 0.9.8k_0, the following ports depend on it:
> ---> ? ?wget
> ---> ? ?lighttpd
> ---> ? ?py25-hashlib
> ---> ? ?curl
> ---> ? ?nginx
> ---> ? ?git-core
> ---> ? ?python26
> ---> ? ?py25-socket-ssl
> ---> ? ?httperf
> Warning: Uninstall forced. ?Proceeding despite dependencies.
> ---> ?Deactivating openssl @0.9.8k_0
> ---> ?Uninstalling openssl @0.9.8k_0
> ---> ?Installing openssl @0.9.8k_0
> ---> ?Activating openssl @0.9.8k_0
> ---> ?Cleaning openssl
> ---> ?Fetching py25-sqlalchemy
> ---> ?Attempting to fetch SQLAlchemy-0.5.2.tar.gz from
> http://trd.no.distfiles.macports.org/python
> ---> ?Verifying checksum(s) for py25-sqlalchemy
> ---> ?Extracting py25-sqlalchemy
> ---> ?Configuring py25-sqlalchemy
> ---> ?Building py25-sqlalchemy
> ---> ?Staging py25-sqlalchemy into destroot
> ---> ?Deactivating py25-sqlalchemy @0.4.7p1_0
> ---> ?Installing py25-sqlalchemy @0.5.2_0
> ---> ?Activating py25-sqlalchemy @0.5.2_0
> ---> ?Cleaning py25-sqlalchemy
>
> $ python2.5 myprogram.py
> ...
> ? ?from elixir.events import *
> ?File "/opt/local/lib/python2.5/site-packages/elixir/__init__.py",
> line 28, in <module>
> ? ?from elixir.entity import Entity, EntityMeta, EntityDescriptor, \
> ?File "/opt/local/lib/python2.5/site-packages/elixir/entity.py", line
> 14, in <module>
> ? ?from sqlalchemy.orm ? ? ? ? ? ? ? ?import Query, MapperExtension,\
> ImportError: cannot import name EXT_PASS
>
> $ port version
> Version: 1.700
>
> $ uname -a
> Darwin apple.spotify.net 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24
> 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386
>



-- 
Rasmus Andersson

From blb at macports.org  Tue Apr 14 13:00:26 2009
From: blb at macports.org (Bryan Blackburn)
Date: Tue, 14 Apr 2009 14:00:26 -0600
Subject: "Lite" vs. "Full" Python Ports
In-Reply-To: <69527FED-FA3B-47A1-9E5E-F745764F3B8D@macports.org>
References: <F4917587-3230-4ED6-98BB-83F7EB14DAB7@macports.org>
	<20090412211712.GF15239@ninagal.withay.com>
	<49E339FD.7020509@macports.org>
	<0DA9CCCB-25D5-4764-81A0-828FCBA8B157@macports.org>
	<49E35DE1.3080002@macports.org>
	<20090413211903.GD651@ninagal.withay.com>
	<69527FED-FA3B-47A1-9E5E-F745764F3B8D@macports.org>
Message-ID: <20090414200026.GC48922@ninagal.withay.com>

On Tue, Apr 14, 2009 at 11:10:32AM +0200, Arthur Koziel said:
>
> On 13.04.2009, at 23:19, Bryan Blackburn wrote:
>>
>> Right, the way the py25-* version installs it is different than if you
>> install it directly with python25, that's actually part of the problem 
>> with
>> splitting them out, as mentioned with the -S stuff on #12369:
>>
>> ${prefix}/lib/python2.5/site-packages/_hashlib.so
>> vs
>> ${prefix}/lib/python2.5/lib-dynload/_hashlib.so
>>
>> There will probably be confusion however, so a FAQ entry might be nice.
>>
>
> That is, if you split the Python 2.5 port in "python2.5" and  
> "python2.5-minimal". I thought we would just enable the core modules in 
> python25, not split the port. See the "python25-reenable-libs.diff" patch 
> on #12369.

Right, reintegrating those modules back into python25 would mean that things
like hashlib could be installed twice, at the two locations I mentioned,
because python25 will install into one location and py25-hashlib (which may
already be installed, since it is popular) will be at the other.

As long as the one in lib-dynload is always loaded first, it shouldn't be
too big a deal, but someone really should test it...

Bryan


>
>> Bryan
>
> Arthur

From jannis at leidel.info  Tue Apr 14 13:19:30 2009
From: jannis at leidel.info (Jannis Leidel)
Date: Tue, 14 Apr 2009 22:19:30 +0200
Subject: "Lite" vs. "Full" Python Ports
In-Reply-To: <20090414200026.GC48922@ninagal.withay.com>
References: <F4917587-3230-4ED6-98BB-83F7EB14DAB7@macports.org>
	<20090412211712.GF15239@ninagal.withay.com>
	<49E339FD.7020509@macports.org>
	<0DA9CCCB-25D5-4764-81A0-828FCBA8B157@macports.org>
	<49E35DE1.3080002@macports.org>
	<20090413211903.GD651@ninagal.withay.com>
	<69527FED-FA3B-47A1-9E5E-F745764F3B8D@macports.org>
	<20090414200026.GC48922@ninagal.withay.com>
Message-ID: <FA8A6947-4AF0-4E6A-B820-6C0D85A87067@leidel.info>


Am 14.04.2009 um 22:00 schrieb Bryan Blackburn:

> On Tue, Apr 14, 2009 at 11:10:32AM +0200, Arthur Koziel said:
>>
>> On 13.04.2009, at 23:19, Bryan Blackburn wrote:
>>>
>>> Right, the way the py25-* version installs it is different than if  
>>> you
>>> install it directly with python25, that's actually part of the  
>>> problem
>>> with
>>> splitting them out, as mentioned with the -S stuff on #12369:
>>>
>>> ${prefix}/lib/python2.5/site-packages/_hashlib.so
>>> vs
>>> ${prefix}/lib/python2.5/lib-dynload/_hashlib.so
>>>
>>> There will probably be confusion however, so a FAQ entry might be  
>>> nice.
>>>
>>
>> That is, if you split the Python 2.5 port in "python2.5" and
>> "python2.5-minimal". I thought we would just enable the core  
>> modules in
>> python25, not split the port. See the "python25-reenable-libs.diff"  
>> patch
>> on #12369.
>
> Right, reintegrating those modules back into python25 would mean  
> that things
> like hashlib could be installed twice, at the two locations I  
> mentioned,
> because python25 will install into one location and py25-hashlib  
> (which may
> already be installed, since it is popular) will be at the other.
>
> As long as the one in lib-dynload is always loaded first, it  
> shouldn't be
> too big a deal, but someone really should test it...

At the risk of not knowing how that could be tested thoroughly: I'm  
running python25 with the patch I attached to #12369 for several days  
now without a problem. That also fixed #18567 for me.

Jannis

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


From febeling at macports.org  Tue Apr 14 13:30:11 2009
From: febeling at macports.org (C. Florian Ebeling)
Date: Tue, 14 Apr 2009 22:30:11 +0200
Subject: ruby_select plan, rubygem: dependency operator
In-Reply-To: <20090413212555.GE651@ninagal.withay.com>
References: <5cbbe4ae0904130547h75e46fa1x3d364588fd2ba31e@mail.gmail.com>
	<20090413201125.GC651@ninagal.withay.com>
	<5cbbe4ae0904131321t5f0afb6epad18420ba783fec8@mail.gmail.com>
	<20090413212555.GE651@ninagal.withay.com>
Message-ID: <5cbbe4ae0904141330p7a242fe6qf49bc8bbb3619698@mail.gmail.com>

On Mon, Apr 13, 2009 at 11:25 PM, Bryan Blackburn <blb at macports.org> wrote:
> On Mon, Apr 13, 2009 at 10:21:08PM +0200, C. Florian Ebeling said:
>> >> So the course of action will be:
>> >> 1 rename ruby port to ruby18
>> >> 2 create ruby_select port
>> >>
>> >> I added the suggestion to maybe have another third step:
>> >> 3 create port ruby again which is empty mostly, but pulls select_ruby
>> >> and symlinks
>> >> to default version (which ever that is then) This one is not agreed on yet
>> >> and still to be discussed.
>> >
>> > You'll definitely need some sort of upgrade path for anyone with ruby
>> > currently installed; otherwise, if you try to install something which
>> > depends on the new ruby18, that will then fail during activation since it
>> > will conflict with files from ruby.
>> >
>> > Also note that upgrading depedencies when installing a new port doesn't
>> > happen automatically, so for those who may not upgrade regularly, this will
>> > still be an issue.
>>
>> Yes, that's true. Didn't think of it. Are you aware of a
>> similar migration that was handled well and that can
>> be use as an example to follow?
>
> Unfortunately no, I think part of the problem is this need hasn't come up
> enough for there to be good support to handle it in base. ?If there were we
> could probably also more easily fix the 'not a directory' issue with
> python25 without causing pain.
>
> Unless there's better support in base for such things, the best option may
> be to try and document it with the right ports (via ui_msg) and mailing
> lists/FAQ/etc that certain things are needed for the newer stuff to work
> right...

Hm, then it is really the question if this is worth the users' hassle, only
for the sake of an somewhat better naming. Python also has an largely
obsolete python (without version suffix) port, hasn't it?

>> > Does this mean there will start to be rb19- ports as well, to have them
>> > depend on ruby19? ?Since ruby modules install into version-specific
>> > locations (using rb-bdb's ${prefix}/lib/ruby/vendor_ruby/1.8 path as an
>> > example), it seems like some form of consistency will be needed. ?Otherwise
>> > someone installs rb-bdb with ruby18 selected, then later switches to ruby19
>> > and now rb-bdb doesn't work, right?
>>
>> Yes, that's the behaviour of the ruby group code
>> already. It uses rb19 as prefix for ruby19 ports.
>
> Ah, okay, I didn't see any rb19- ports but didn't look at the group code.
> Is there a possibility that they could eventually be merged once #126 is
> done, similar to how we'd like the python modules to work, as mentioned in
> #16723?

The group code is already the same for ruby (1.8) and ruby19. There are
no rb19 ports yet because most ruby developers prefer rubygems over
ports using the 'gem' package manager. This tool now comes with
the (1.9) ruby release. So this approach mostly obsoletes older install.rb
and setup.rb methods. And gems as ports have issues.

We have ports that are only a skin over rubygem installs, but that approach
is not ideal, because you can e.g. install the port and uninstall the gem, just
using the gem tool. And then it is registered as installed, where it
really isn't
present as a library. I and others therefore think that ports just brokering
gem installs should be avoided if possible.

The obvious problem with no ruby lib ports is, once you want to add a port that
depends on a gem library, you cannot declare it.

That's the reason for the suggestion to add a new dependency type "gem" or
"rubygem", which behaves much like "path" or "lib" dependencies. Not controlling
installation, but checking.

Florian

-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com

From raimue at macports.org  Tue Apr 14 13:52:46 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Tue, 14 Apr 2009 22:52:46 +0200
Subject: NewHelpSystem & man pages
In-Reply-To: <fc.004c4c5811f738aa004c4c5811f738aa.11f752fd@biola.edu>
References: <fc.004c4c5811f738aa004c4c5811f738aa.11f752fd@biola.edu>
Message-ID: <49E4F79E.9000307@macports.org>

markd at macports.org wrote:
> If you can produce better docs than what I've done it doesn't matter what
> has already been done.  I would naturally want to use the simplest method
> that can produce acceptable output.  If you can't with the method you have
> proposed, then it doesn't matter if it has been stalled too long or not as
> long as it continues before a better plan arrives.
> 
> I only raised the issue that I have already started on man pages only to
> say that no one should modify the guide for a new purpose without
> consulting the community.  That would be disturbing an ongoing project
> that I am working on now, no matter what are one's personal judgements on
> what counts as stalled.  It also wouldn't be necessary since if you need
> to demonstrate issues related to your project having to do with the guide,
> you could always make a copy in your branch.

As I already explained, I do not plan to replace the current guide with
the NewHelpSystem. My effort is to create "hands-on" help available by
using the 'port help' command. And I am also not doing this on trunk, I
created a new branch for it. If it does not work out as expected, then
we can still throw it away and start something else.

> The problem from my perspective is that as far as I've been able to tell,
> what would count as success seems to have surprisingly little to do with
> structure or style (control over which docbook and CSS give to the current
> guide), and it appears from the last few messages that a commitment to
> using a single source has been dropped or probably soon will be too. 

AsciiDoc still gives control over DocBook and CSS. It is still possible
to change the XSL stylesheet converting the DocBook to HTML and the CSS
is in a separate file. It is even possible to add your own DocBook
elements if that would be necessary.

> Aside from the absolute necessity in my opinion to use a single source
> (eliminate duplicated effort), the main problem I see, as I've already
> said before, is that without a defined structure and style the docs will
> not be very consistent and will have no resistance to entropy in any case.

I don't see how you would apply the style and structure of the Guide
being a website to man pages in Terminal. Having the man pages on the
website is a secondary goal and I had the idea only while writing the
NewHelpSystem page. The primary goal is to have a usable 'port help'
which currently is not helpful at all.

I made a call for contributions on macports-users before about writing
more helpful strings for the current implementation, but nobody seems to
be interested. So why should I not be allowed to do something about it
if nobody else cares? And as it is me doing the work, I am going to do
it in a way I like.

> [...]
> We all know asciidoc is simpler; the question is whether or not the
> criteria for success can be met.  I looked at alternatives to XML before I
> started the guide (because I want the simplest solution that meets the
> goals too) and rejected them as not meeting my criteria for success. 
> You've defined the success as the ability to edit bits easily and that is
> an easy target to hit, but has nothing to say about product quality and I
> think most users have greater expectations for docs than that.  I think
> having something like NewHelpSystem is fine, but adding features doesn't
> mean ignoring previous design goals or dictating changes unrelated to such
> features.
> 
> I haven't even seen where you have warned anyone or commented on the
> completely generic look of asciidos generated html and the lack of control
> for adding future format additions and changes.  Are we ok with a guide
> that looks like Git man pages?  I'm not.  Is the communty satisfied with
> that?  Or has that been discussed somewhere and I've missed it?  That
> would be the first question I would ask, even though the other questions
> I've raised would still hold.

I didn't warn anybody because your expectations are simply not true. As
AsciiDoc uses DocBook as intermediate format, we can apply the same
customizations as to any document directly written in DocBook. This
includes changing XSLT and CSS.

And as we see in the guide, we are already applying customizations by
hacks. This is a) a sed expression to insert links to the headline
anchors b) a Tcl script to insert the TOC into each page for the chunked
version. Probably it would also be possible to do this with XSLT, but
it's probably too complicated. So there is the point in "having control"?

It was me who lately digged through the XSLT to add attribute
customizations to the single-page and the chunked versions and I also
added links to switch between them.

And how should I ask the community before I have anything to show?
A HTML version of the man pages would not have to look exactly like the
ones on the Git homepage. We can still apply custom CSS or even custom
XSLT. Be aware that AsciiDoc does not only offer writing man pages but
various output formats. But at the moment, my focus are man pages for
the terminal.

> If everybody is satisfied with poorly
> formatted and structured docs, then I really need to know that.  Because I
> am not interested in producing documents that ugly (poorly formatted) or
> unsustainable (poorly structured) or the massively error-prone process of
> reconciling text manually between guide and man (no single doc source). 
> In the case of the former two, it isn't worthy of a product that runs on a
> Mac, and in the case of the latter I just have better things to do, and
> I'd hope we all do.

Sorry, but I don't take the arguments of poorly structure or bad
formatting as serious. As explained above, AsciiDoc offers everything
DocBook does.

My plan is not to offer the Guide as man pages. This is mainly new
content describing the various options of the port commands.

> I mean no rudeness whatever, I'm just trying to get my point across.  And
> I've said it all before and you are quite unimpressed.  That is why I
> suppose that we should continue on parallel courses and let the community
> decide which is better overall.  This is assuming that the community does
> want docs that aspire to have a good design; if not then it is time for me
> to retire.  :)

If I would have been unimpressed I might not have considered AsciiDoc
which offers compatibility and interaction with DocBook. There are other
ways to write man pages without writing plain roff, like latex2man,
pod2man or any of the various markdown parsers. I am aware of the
concerns you expressed, but maybe I just don't see that as the big issue
as you do or I see ways to accomplish the goals.

Please do not take this discussion too personal. I appreciate your work
and I am looking forward for further contributions by you. It is
probably my fault that I quietly added this wiki page describing my plan
without any announcement on the mailing list. But I was not going to
hold a speech promoting AsciiDoc without having tried if it would work
at all. I also didn't want to do this all in private and come up with a
finished solution in a few months. Rather I am doing everything in
public so others can chime in about it and I can get some feedback if
this concept of 'port help' would be accepted at all.

Rainer

From raimue at macports.org  Tue Apr 14 13:55:42 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Tue, 14 Apr 2009 22:55:42 +0200
Subject: [49606] trunk/base/src/port1.0/portactivate.tcl
In-Reply-To: <61972D4A-E99A-4C19-ADEB-294B586B432E@macports.org>
References: <20090413074025.2D7841566F53@beta.macosforge.org>	<B8096B93-7853-4D2F-ABA6-694923CE8869@macports.org>
	<61972D4A-E99A-4C19-ADEB-294B586B432E@macports.org>
Message-ID: <49E4F84E.9060708@macports.org>

Perry Lee wrote:
> On Apr 13, 2009, at 1:00 AM, Ryan Schmidt wrote:
>>> Revision: 49606
>>>          http://trac.macports.org/changeset/49606
>>> Author:   perry at macports.org
>>> Date:     2009-04-13 00:40:18 -0700 (Mon, 13 Apr 2009)
>>> Log Message:
>>> -----------
>>> port1.0/portactivate.tcl - Wrap notes output to the terminal's width.
>> We already have the wrapline procedure to do this (added in r34354).  
>> Could this be used here as well, instead of having another separate  
>> line wrapping implementation?
> 
> I mentioned that in the ticket http://trac.macports.org/ticket/421#comment 
> :17.
> 
> I'm not sure if there's a way to share the proc since it's in  
> port.tcl, but I thought it'd be better to commit it now so at least  
> the output looks more uniform than what I had before.

I am not sure if it is really the appropriate place in port1.0 to make
changes for the output device. For example, there could be COLUMNS in
the environment even if the actual client is a GUI where we don't know
how it handles ui_*.

macports1.0 let's you register different Tcl channels for each ui_*
command. Thinking of other clients, e.g. the MacPorts.framework it may
be more correct to wrap the ui_msgs in port/port.tcl.

But this would require to write our own Tcl channel for port/port.tcl
which I did not look into yet. Maybe it would be easier to have simple
callbacks instead of Tcl channels, but probably the person implementing
this as channels had something in mind which I do not see yet.

Rainer

From ryandesign at macports.org  Tue Apr 14 14:43:24 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 14 Apr 2009 16:43:24 -0500
Subject: [49648] trunk/dports/net/psi
In-Reply-To: <20090414151158.02E3115802E5@beta.macosforge.org>
References: <20090414151158.02E3115802E5@beta.macosforge.org>
Message-ID: <8793F756-F114-46DE-AF56-886E27468A3F@macports.org>


On Apr 14, 2009, at 10:11, rowue at macports.org wrote:

> Revision: 49648
>           http://trac.macports.org/changeset/49648
> Author:   rowue at macports.org
> Date:     2009-04-14 08:11:57 -0700 (Tue, 14 Apr 2009)
> Log Message:
> -----------
> Added ipv6 - see #19310

[snip]

> +variant ipv6 description {Add ipv6 support} {
> +
> +patchfiles-append      patch-src-src.pro.diff
> +}

Is there a reason why ipv6 should not be always enabled? There has  
been a push to remove ipv6 variants and include ipv6 support  
generally; see:

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


From ryandesign at macports.org  Tue Apr 14 14:48:54 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 14 Apr 2009 16:48:54 -0500
Subject: [49649] trunk/dports/graphics/vtk5/Portfile
In-Reply-To: <20090414154901.54AB315816E4@beta.macosforge.org>
References: <20090414154901.54AB315816E4@beta.macosforge.org>
Message-ID: <CC34CFC1-85DF-4FE3-B686-EE47BFCF70E0@macports.org>


On Apr 14, 2009, at 10:48, macsforever2000 at macports.org wrote:

> Revision: 49649
>           http://trac.macports.org/changeset/49649
> Author:   macsforever2000 at macports.org
> Date:     2009-04-14 08:48:51 -0700 (Tue, 14 Apr 2009)
> Log Message:
> -----------
> Fix for +tcltk +x11 +python variants. (#19111)

Looks like you also added a +carbon variant.

Using the +carbon variant will be painful, as the user will have to  
also specify "-tcltk -x11" every time they want to upgrade their  
"vtk5 +carbon", because those default variants would otherwise  
conflict. It may be useful to specify +x11 and +tcltk as default  
variants *only* if the user has not already requested the +carbon  
variant. See many ports for examples of how to handle this, e.g.  
minivmac.

[snip]

> -default_variants +x11 +python
> +default_variants +x11 +tcltk +python
>
> -variant x11 description {use X11} {
> +variant x11 conflicts carbon description {use X11} {
>      depends_build-append    port:xorg-libs
>      configure.args-delete   -DVTK_USE_COCOA:BOOL=ON
>      configure.args-append   \
> @@ -96,6 +99,26 @@
>          -DOPENGL_glu_LIBRARY:FILEPATH=${x11prefix}/lib/libGLU.dylib
>  }
>
> +variant tcltk conflicts carbon description {build with Tcl  
> wrappers and Tk support} {
> +    configure.args-delete \
> +        -DVTK_USE_TK:BOOL=OFF \
> +        -DVTK_WRAP_TCL:BOOL=OFF
> +    configure.args-append \
> +        -DVTK_USE_TK:BOOL=ON \
> +        -DVTK_WRAP_TCL:BOOL=ON \
> +        -DTCL_INCLUDE_PATH=${prefix}/include \
> +        -DTCL_LIBRARY=${prefix}/lib/libtcl.dylib
> +}
> +
> +variant carbon conflicts x11 tcltk description {Use Carbon.   
> Allows embedding VTK within qt4-mac (and py25-pyqt4 when used with  
> Python)} {
> +    configure.args-delete \
> +        -DVTK_USE_COCOA:BOOL=ON \
> +        -DVTK_USE_CARBON:BOOL=OFF
> +    configure.args-append \
> +        -DVTK_USE_COCOA:BOOL=OFF \
> +        -DVTK_USE_CARBON:BOOL=ON
> +}




From ryandesign at macports.org  Tue Apr 14 15:19:44 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 14 Apr 2009 17:19:44 -0500
Subject: NewHelpSystem & man pages
In-Reply-To: <49E4F79E.9000307@macports.org>
References: <fc.004c4c5811f738aa004c4c5811f738aa.11f752fd@biola.edu>
	<49E4F79E.9000307@macports.org>
Message-ID: <0619E040-BF3F-4E1D-93A7-58EDA171B45E@macports.org>


On Apr 14, 2009, at 15:52, Rainer M?ller wrote:

> I made a call for contributions on macports-users before about writing
> more helpful strings for the current implementation, but nobody  
> seems to
> be interested. So why should I not be allowed to do something about it
> if nobody else cares? And as it is me doing the work, I am going to do
> it in a way I like.

I admit I don't remember this prior message, but there are so many  
messages, it's easy to forget some. I do remember a prior discussion  
advocating a switch from the Guide's docbook to asciidoc, and though  
we haven't done so yet, my recollection of the outcome of that  
discussion was that asciidoc should allow the same output to be  
produced, while allowing the source documents to be more readable.  
Rainer, I'm glad you're trying it out, and I'll be interested to see  
what comes of your efforts. Though your primary focus is  
documentation for the command line, I agree with Mark on the  
necessity of having this documentation available on the web as well,  
e.g. as an appendix to the guide, so I hope we'll be able to see the  
HTML output of your documents at some point to see how they'll fit  
in. As you work with asciidoc, it would be great if you could let us  
know about things you've learned about asciidoc, both the good and  
the bad.


I had forgotten we even had "port help". It would be great to reduce  
the number of places where we have unique documentation (so it's  
easier to update, so it's more likely it will get updated). So making  
"port help" use manpages sounds like a fine idea to me.



From raimue at macports.org  Tue Apr 14 15:38:33 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Wed, 15 Apr 2009 00:38:33 +0200
Subject: Ports linking against the wrong Python.framework
In-Reply-To: <49DD0A45.3080500@orcaware.com>
References: <062.13f6e0b9941679b695339c1187888885@macports.org>	<071.41da13f929b715af04a8bb4857c8e12c@macports.org>	<49DCCAE0.8020409@macports.org>
	<49DD0924.6000205@orcaware.com> <49DD0A45.3080500@orcaware.com>
Message-ID: <49E51069.8080607@macports.org>

Blair Zajac wrote:
> Blair Zajac wrote:
>> Rainer M?ller wrote:
>>> As far as I know the only advantage of the frameworks is currently to
>>> have working pythonw and IDLE. Is there really no way to get this
>>> without a framework build or did just nobody try yet?
>> The Ice Python bindings requires a framework build.  Sony Pictures 
>> Imageworks whole middle-tier infrastructure is based on Ice with Python 
>> clients.

I looked through the configure scripts in ice-python26 and did not find
anything special regarding framework installations. Is that your own
experience or is it documented somewhere? I also cannot find any
information on the website.

> Oh, and doesn't PyQt require a framework install?  We depend heavily on that too.

I looked around and the only reference I found is this:
<http://diotavelli.net/PyQtWiki/Mac_OS_X_Installation_Notes>

We have seen this error a lot and it usually happens when linking
against the wrong python version, e.g. mixing headers and libraries.

Yet again its configure.py demonstrate how linking against python
should not be done:

  if sys.platform == "darwin":
      # We need to work out how to specify the right framework
      # version.
      link = "-framework Python"

At least it looks like they are aware that this has issues :-) And
somehow it still seems to link correct, so I am not investigating this
any further. Other than this conditional in the configuration I did not
see anything special requiring a python framework.

Note that I did not actually try to build these ports against a
non-framework python, just looking at their configure scripts.

Rainer

From blb at macports.org  Tue Apr 14 16:34:54 2009
From: blb at macports.org (Bryan Blackburn)
Date: Tue, 14 Apr 2009 17:34:54 -0600
Subject: "Lite" vs. "Full" Python Ports
In-Reply-To: <FA8A6947-4AF0-4E6A-B820-6C0D85A87067@leidel.info>
References: <F4917587-3230-4ED6-98BB-83F7EB14DAB7@macports.org>
	<20090412211712.GF15239@ninagal.withay.com>
	<49E339FD.7020509@macports.org>
	<0DA9CCCB-25D5-4764-81A0-828FCBA8B157@macports.org>
	<49E35DE1.3080002@macports.org>
	<20090413211903.GD651@ninagal.withay.com>
	<69527FED-FA3B-47A1-9E5E-F745764F3B8D@macports.org>
	<20090414200026.GC48922@ninagal.withay.com>
	<FA8A6947-4AF0-4E6A-B820-6C0D85A87067@leidel.info>
Message-ID: <20090414233454.GJ48922@ninagal.withay.com>

On Tue, Apr 14, 2009 at 10:19:30PM +0200, Jannis Leidel said:
> Am 14.04.2009 um 22:00 schrieb Bryan Blackburn:
[...]
>>
>> As long as the one in lib-dynload is always loaded first, it shouldn't 
>> be
>> too big a deal, but someone really should test it...
>
> At the risk of not knowing how that could be tested thoroughly: I'm  
> running python25 with the patch I attached to #12369 for several days now 
> without a problem. That also fixed #18567 for me.

Optimally, having an older version of one of the modules (eg, py25-hashlib
at 2.5.2) installed with python25 at 2.5.4 with hashlib builtin, would be a
meaningful test.  Then trying it with various bits that affect how modules
are loaded (eg, normal, with -S, others?) would answer it fully I think.

Bryan


>
> Jannis

From blb at macports.org  Tue Apr 14 16:41:54 2009
From: blb at macports.org (Bryan Blackburn)
Date: Tue, 14 Apr 2009 17:41:54 -0600
Subject: ruby_select plan, rubygem: dependency operator
In-Reply-To: <5cbbe4ae0904141330p7a242fe6qf49bc8bbb3619698@mail.gmail.com>
References: <5cbbe4ae0904130547h75e46fa1x3d364588fd2ba31e@mail.gmail.com>
	<20090413201125.GC651@ninagal.withay.com>
	<5cbbe4ae0904131321t5f0afb6epad18420ba783fec8@mail.gmail.com>
	<20090413212555.GE651@ninagal.withay.com>
	<5cbbe4ae0904141330p7a242fe6qf49bc8bbb3619698@mail.gmail.com>
Message-ID: <20090414234154.GK48922@ninagal.withay.com>

On Tue, Apr 14, 2009 at 10:30:11PM +0200, C. Florian Ebeling said:
> On Mon, Apr 13, 2009 at 11:25 PM, Bryan Blackburn <blb at macports.org> wrote:
[...]
> >
> > Unless there's better support in base for such things, the best option may
> > be to try and document it with the right ports (via ui_msg) and mailing
> > lists/FAQ/etc that certain things are needed for the newer stuff to work
> > right...
> 
> Hm, then it is really the question if this is worth the users' hassle, only
> for the sake of an somewhat better naming. Python also has an largely
> obsolete python (without version suffix) port, hasn't it?

The py-* modules are all python 2.4-based modules, but since 2.5 is the
currently-popular version and 2.6 starting to kick in, like you say it
isn't worth the effort to rename to py24-*.

[...]
> >
> > Ah, okay, I didn't see any rb19- ports but didn't look at the group code.
> > Is there a possibility that they could eventually be merged once #126 is
> > done, similar to how we'd like the python modules to work, as mentioned in
> > #16723?
> 
> The group code is already the same for ruby (1.8) and ruby19. There are
> no rb19 ports yet because most ruby developers prefer rubygems over
> ports using the 'gem' package manager. This tool now comes with
> the (1.9) ruby release. So this approach mostly obsoletes older install.rb
> and setup.rb methods. And gems as ports have issues.
> 
> We have ports that are only a skin over rubygem installs, but that approach
> is not ideal, because you can e.g. install the port and uninstall the gem, just
> using the gem tool. And then it is registered as installed, where it
> really isn't
> present as a library. I and others therefore think that ports just brokering
> gem installs should be avoided if possible.
> 
> The obvious problem with no ruby lib ports is, once you want to add a port that
> depends on a gem library, you cannot declare it.
> 
> That's the reason for the suggestion to add a new dependency type "gem" or
> "rubygem", which behaves much like "path" or "lib" dependencies. Not controlling
> installation, but checking.

What would be nice is some automatic wrapper for all the various extensions
to languages (ruby, perl, python, etc) where you just say "I need xyz from
CPAN/gem" and port can handle it, and hence use it for dependencies.  Of course,
base has no support for such hence the need to wrap such things in full-blown
ports, otherwise how do we know what is installed and and what version?  It
would still run the install through the proper tool, but also keep track of
what is installed so it can be managed (and easily upgraded, activated,
etc), but wouldn't need to be a complete port.  Instead it could be some
form of listing in a table someplace, for any extensions which are easily
installed.

Bryan


> 
> Florian
> 
> -- 
> Florian Ebeling
> Twitter: febeling
> florian.ebeling at gmail.com

From jeremyhu at macports.org  Tue Apr 14 16:49:23 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Tue, 14 Apr 2009 16:49:23 -0700
Subject: volatile variants (was Re: Gimp 2.6 & Pango 1.8 : no font rendering)
In-Reply-To: <56DC803E-264B-4C72-A20C-2EE06EA614E7@macports.org>
References: <2DB9230F-D235-4509-9937-03995EDBDF69@gmail.ca>
	<99292962-5578-4FFF-B50D-89F27885A27E@macports.org>
	<49E406CD.3070906@macports.org>
	<56DC803E-264B-4C72-A20C-2EE06EA614E7@macports.org>
Message-ID: <F2E5D1F5-AAC3-47F6-99F5-4D861E8752F4@macports.org>

I think it might be wise to create a list of such volatile variants  
(system_x11, universal, no_x11, etc) and mention them to users in the  
install guide, so they can make decisions about them before it's too  
late.

Also, this brings up a point that has been bothering me for a while.   
Why do we have so many variants for what should really be a single  
binary decision: +x11, +no_x11, +quartz, +no_quartz, +aqua

On Apr 14, 2009, at 16:16, Ryan Schmidt wrote:

>
> On Apr 13, 2009, at 22:45, David Evans wrote:
>
>> I suspect that a  number of the reports of GOffice and other apps  
>> not working correctly no_x11/quartz is due to the same problem of  
>> mixing X11
>> and no_x11 in the same instance of MacPorts -- not realistic to  
>> think that you can do this and have the right selection of ports/ 
>> variants
>> active at any given point in time.
>
> Probably true. The other point is that some users may not be  
> intending to mix and match, yet may not realize that by the time  
> they choose to use quartz and no_x11 they may already have ports  
> installed for which that choice should have been made. Hence, the  
> recommendation is that you must make the choice to use quartz and  
> no_x11 before you have installed any ports, and if you have  
> installed any ports, you should remove them, then set the default  
> variants, or else as David said, install a new MacPorts to a new  
> prefix where you set the default variants and then install your ports.
>
>
> _______________________________________________
> macports-users mailing list
> macports-users at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-users


From devans at macports.org  Tue Apr 14 17:07:48 2009
From: devans at macports.org (David Evans)
Date: Tue, 14 Apr 2009 17:07:48 -0700
Subject: volatile variants (was Re: Gimp 2.6 & Pango 1.8 : no font
	rendering)
In-Reply-To: <F2E5D1F5-AAC3-47F6-99F5-4D861E8752F4@macports.org>
References: <2DB9230F-D235-4509-9937-03995EDBDF69@gmail.ca>
	<99292962-5578-4FFF-B50D-89F27885A27E@macports.org>
	<49E406CD.3070906@macports.org>
	<56DC803E-264B-4C72-A20C-2EE06EA614E7@macports.org>
	<F2E5D1F5-AAC3-47F6-99F5-4D861E8752F4@macports.org>
Message-ID: <49E52554.2030006@macports.org>

Jeremy Huddleston wrote:
> I think it might be wise to create a list of such volatile variants 
> (system_x11, universal, no_x11, etc) and mention them to users in the 
> install guide, so they can make decisions about them before it's too 
> late.
maybe volatile is a bit harsh? ;-)
>
> Also, this brings up a point that has been bothering me for a while.  
> Why do we have so many variants for what should really be a single 
> binary decision: +x11, +no_x11, +quartz, +no_quartz, +aqua
>
Here's my thoughts on this

+x11:  by custom this is the default for a MacPorts instance and so it 
really is unnecessary 
+no_quartz:  again really the default  (is any port actually using this?)


+no_x11: disable x11 support and just that.  does not imply what you 
will use otherwise.  specifically does not mean +quartz
+quartz: use MacOSX native graphics rendering.  Calling this quartz is 
probably a bit out of date.

+aqua: indicates an application with a MacOSX native GUI (not x11, not 
gtk, etc)

I think +x11, +no_quartz, -x11 and the like should be deprecated.  
+quartz should be added to the list of global variants as +no_x11 has 
already.




From blair at orcaware.com  Tue Apr 14 17:11:41 2009
From: blair at orcaware.com (Blair Zajac)
Date: Tue, 14 Apr 2009 17:11:41 -0700
Subject: Ports linking against the wrong Python.framework
In-Reply-To: <49E51069.8080607@macports.org>
References: <062.13f6e0b9941679b695339c1187888885@macports.org>	<071.41da13f929b715af04a8bb4857c8e12c@macports.org>	<49DCCAE0.8020409@macports.org>
	<49DD0924.6000205@orcaware.com> <49DD0A45.3080500@orcaware.com>
	<49E51069.8080607@macports.org>
Message-ID: <49E5263D.9090607@orcaware.com>

Rainer M?ller wrote:
> Blair Zajac wrote:
>> Blair Zajac wrote:
>>> Rainer M?ller wrote:
>>>> As far as I know the only advantage of the frameworks is currently to
>>>> have working pythonw and IDLE. Is there really no way to get this
>>>> without a framework build or did just nobody try yet?
>>> The Ice Python bindings requires a framework build.  Sony Pictures 
>>> Imageworks whole middle-tier infrastructure is based on Ice with Python 
>>> clients.
> 
> I looked through the configure scripts in ice-python26 and did not find
> anything special regarding framework installations. Is that your own
> experience or is it documented somewhere? I also cannot find any
> information on the website.

This comment in py/config/Make.rules.Darwin.

#
# We require Python to be built as a Framework for the IcePy plug-in.
#

I recall building it once against a non-framework build and it failed.

Regards,
Blair

From jon.hermansen at gmail.com  Tue Apr 14 17:28:20 2009
From: jon.hermansen at gmail.com (Jon Hermansen)
Date: Tue, 14 Apr 2009 20:28:20 -0400
Subject: Binaries and alternate prefix
In-Reply-To: <21b72fa30904141727h2fdf39a8i2fe7ec22ceb1faa2@mail.gmail.com>
References: <88054BE3-2148-4C5D-9898-674D2610C944@macports.org>
	<21b72fa30904141727h2fdf39a8i2fe7ec22ceb1faa2@mail.gmail.com>
Message-ID: <21b72fa30904141728u4173648dud4a6867c4636332@mail.gmail.com>

Sorry Ryan... sent a response directly to you accidentally.

On Tue, Apr 14, 2009 at 8:27 PM, Jon Hermansen <jon.hermansen at gmail.com>wrote:

> I seriously support the idea of setting up a build system / distributing
> binary packages.
>
> Most modern Linux distributions (unless source-based) install files
> contained within packages to one path, and one path only. Why does it need
> to be more complicated? Make it a requirement that if you want to use binary
> packages, for now, your prefix must be /opt/local.
>
>
> On Thu, Apr 9, 2009 at 6:35 AM, Ryan Schmidt <ryandesign at macports.org>wrote:
>
>> If we build and distribute binaries of ports.... is there a way we can
>> still allow the user to choose their prefix?
>>
>> The prefix can be hardcoded in so many places in built ports. For compiled
>> libraries and binaries, we could use install_name_tool on the client side to
>> fix up all the paths. We could either build with
>> -headerpad_max_install_names or with a very long prefix, so that there is
>> enough space in the binary to accommodate the user's prefix. If we used a
>> long and particularly unique prefix at build time, then this would also make
>> it possible for the client to do a search/replace of that string with the
>> user's prefix in the port's text files.
>>
>> Perhaps I'm getting ahead of things. We could begin with binaries only
>> available for the default /opt/local path, and think about how to support
>> other prefixes later.
>>
>>
>> _______________________________________________
>> 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/20090414/272afc59/attachment.html>

From markd at macports.org  Tue Apr 14 20:32:37 2009
From: markd at macports.org (markd at macports.org)
Date: Tue, 14 Apr 2009 20:32:37 -0700
Subject: NewHelpSystem & man pages
Message-ID: <fc.004c4c5811fb49f9004c4c5811fb49f9.11fb8290@biola.edu>

Forgot to send this to the list ...

>AsciiDoc still gives control over DocBook and CSS. It is still possible
>to change the XSL stylesheet converting the DocBook to HTML and the CSS
>is in a separate file. It is even possible to add your own DocBook
>elements if that would be necessary.

Yes, but I'm just skeptical of this translation and basically assumed it
won't work very well.  That could be wrong, but it is the norm for
translation to fail without extensive manual tweaking.

>Having the man pages on the
>website is a secondary goal and I had the idea only while writing the
>NewHelpSystem page. The primary goal is to have a usable 'port help'
>which currently is not helpful at all.
 .....

... 
>My plan is not to offer the Guide as man pages. This is mainly new
>content describing the various options of the port commands.

Here is the problem.  This will mean duplicate information and
instructions in the man pages and in the guide.  I think this is
unsupportable.  That is why I stopped writing content to work out a
strategy to merge in man pages and manage the content as a whole. rather
than provide similar information in two places and why the guide was
delayed when I was on the task.  It is impossible to have accuracy without
a single source, and I am confident that no one here has the time or
inclination to reconcile two sets of similar text.  There are doc tickets
that say "need to merge web site install section with guide install
section" that illustrate how people react to multiple sources.

Bottom line is that the sources for the man pages need to be the bases for
the relevant guide sections (currently the reference section) on a given
topic.  The guide and the man pages need to be designed together, and that
is what was being done.  I know development stalled, but that was not for
lack of interest.

>And as we see in the guide, we are already applying customizations by
>hacks. This is a) a sed expression to insert links to the headline
>anchors b) a Tcl script to insert the TOC into each page for the chunked
>version. Probably it would also be possible to do this with XSLT, but
>it's probably too complicated. So there is the point in "having control"?

Yes I know is is hacky.  The fact is I don't know that using XML source is
the best way to do on the man pages.  It could be that asiidoc is a better
way in the end.  I am not committed to any technology per se, despite the
impression I may have given by defending DocBook.  If asciidoc can be made
to do the job I'm fine with that, I am just skeptical.  I would be
entirely open to using something else as long as the principles I think
that are necessary for good docs overall are maintained, and the principle
of treating the guide and man pages (and other docs) comprehensively
(accomplished mostly by using a single source) is one of them.  It might
well be that asciidoc has a place, but I'm not sure.

But look, even the GNU coding standards (sect 6.9) show that man pages are
secondary and the problems that can result from man page contributions:
http://www.gnu.org/prep/standards/standards.html and multiple sources.  I
know it may sound ungrateful to question work before is is done, and I
appreciate your willingness to put in time improving the usability of
MacPorts, but it isn't a crazy idea to hash some things out up front so
there won't be any bitterness later on.  I"m not opposed at all to
anyone's work, but how would you like it if I waited until you got
something working before I jump in with my concerns?  That would wasting
your time (assuming my arguments had merit and were persuasive to the
community) and be pretty rude.  So don't think my early objections are
trying to stop you from doing beta work or whatever.

>Please do not take this discussion too personal. I appreciate your work
>and I am looking forward for further contributions by you. It is
>probably my fault that I quietly added this wiki page describing my plan
>without any announcement on the mailing list. But I was not going to
>hold a speech promoting AsciiDoc without having tried if it would work
>at all. I also didn't want to do this all in private and come up with a
>finished solution in a few months. Rather I am doing everything in
>public so others can chime in about it and I can get some feedback if
>this concept of 'port help' would be accepted at all.

I don't think I am taking it personally.  I think the main difference here
is that I take a content writer's perspective, whereas I think you are
taking a developer's perspective.  I am all about content and experience
overall, and that structure and style only matters as far as it support
the goals of knowledge management (content) and usability (experience). 
If asciidoc does it better then I could easily support that.  I think I've
shown that my concerns are on principles, right or wrong.

I think your point of view is all about delivery, and not so much what
gets delivered if I may say so.  And I'm not sure you are aware that you
seem to be ignoring my rewritten man pages that contain extensive content
that is not in the current man pages.  I was confused by the wandering
among several topics related to asciidoc advocacy recently and I didn't
realize you might be doing that until just now.

It seems to me you are doing what is normally called "context sensitive
help", and I think that is another reason to consider the docs as a whole.
 Maybe there is a way that we could work together on this.  Is there a
decent way to have a particular 'port help foo' command spit out a section
of a man page?  Or it could be that each port command could be treated as
a separate topic thatt get included in a file of similar topics together
as man pages, which could then be included in the guide one way or
another.  If they are written with their inclusion with the guide in mind
that would be fine.   I just don't think it is good to write them based on
the needs of the delivery system, the outdated man pages, or anything
other than a comprehensive point of view on the docs as a whole.

Mark


From ryandesign at macports.org  Wed Apr 15 00:54:25 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 15 Apr 2009 02:54:25 -0500
Subject: Binaries and alternate prefix
In-Reply-To: <21b72fa30904141728u4173648dud4a6867c4636332@mail.gmail.com>
References: <88054BE3-2148-4C5D-9898-674D2610C944@macports.org>
	<21b72fa30904141727h2fdf39a8i2fe7ec22ceb1faa2@mail.gmail.com>
	<21b72fa30904141728u4173648dud4a6867c4636332@mail.gmail.com>
Message-ID: <E0F0C862-4BD5-441C-805D-29FCA8019BA4@macports.org>

On Tue, Apr 14, 2009 at 8:27 PM, Jon Hermansen wrote:

> I seriously support the idea of setting up a build system /  
> distributing binary packages.

I think everybody is in favor of the idea. There are just many parts  
that need to get done. And I'm still trying to work out in my head  
what some of the disadvantages of binaries would be, and how we could  
possible handle those.


> Most modern Linux distributions (unless source-based) install files  
> contained within packages to one path, and one path only. Why does  
> it need to be more complicated? Make it a requirement that if you  
> want to use binary packages, for now, your prefix must be /opt/local.

Many users either prefer to or have no choice but to install into a  
prefix which doesn't require root to write to. MacPorts supports  
being installed into a different prefix partly for this purpose. I  
would like to support that flexibility, and indeed the entire set of  
MacPorts installation options, for binaries as well.

Thanks for the information on how Linux handles it; I wasn't aware.  
That means if we don't support alternate prefixes, we'd at least be  
in good company.

I personally install MacPorts to a different prefix, 1) because I  
want something shorter than "/opt/local" (I use "/mp"), and 2)  
because some port authors do not realize (or forget) that MacPorts  
can be installed in other prefixes and erroneously hardcode "/opt/ 
local" into their ports or patches, and I want to encounter an error  
message in these cases so that I can notice and report and/or correct  
that problem.

As proposed above, I think with a combination of install_name_tool  
and textual search/replace it could be possible to distribute install- 
time-relocatable binaries. But, our first priorities should be the  
basics that are required to provide binaries. We can always revisit  
non-standard prefixes once we have all that working.



From ryandesign at macports.org  Wed Apr 15 00:56:59 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 15 Apr 2009 02:56:59 -0500
Subject: ruby_select plan, rubygem: dependency operator
In-Reply-To: <20090414234154.GK48922@ninagal.withay.com>
References: <5cbbe4ae0904130547h75e46fa1x3d364588fd2ba31e@mail.gmail.com>
	<20090413201125.GC651@ninagal.withay.com>
	<5cbbe4ae0904131321t5f0afb6epad18420ba783fec8@mail.gmail.com>
	<20090413212555.GE651@ninagal.withay.com>
	<5cbbe4ae0904141330p7a242fe6qf49bc8bbb3619698@mail.gmail.com>
	<20090414234154.GK48922@ninagal.withay.com>
Message-ID: <9196B4F9-6954-4506-8A3D-A8F10E1B332F@macports.org>


On Apr 14, 2009, at 18:41, Bryan Blackburn wrote:

> What would be nice is some automatic wrapper for all the various  
> extensions
> to languages (ruby, perl, python, etc) where you just say "I need  
> xyz from
> CPAN/gem" and port can handle it, and hence use it for  
> dependencies.  Of course,
> base has no support for such hence the need to wrap such things in  
> full-blown
> ports, otherwise how do we know what is installed and and what  
> version?  It
> would still run the install through the proper tool, but also keep  
> track of
> what is installed so it can be managed (and easily upgraded,  
> activated,
> etc), but wouldn't need to be a complete port.  Instead it could be  
> some
> form of listing in a table someplace, for any extensions which are  
> easily
> installed.

In lieu of this, a tool to mostly-automatically convert from those  
package managers to a MacPorts port is useful, c.f. cpan2port for  
converting CPAN perl modules to Portfiles.



From ryandesign at macports.org  Wed Apr 15 01:02:11 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 15 Apr 2009 03:02:11 -0500
Subject: ruby_select plan, rubygem: dependency operator
In-Reply-To: <5cbbe4ae0904141330p7a242fe6qf49bc8bbb3619698@mail.gmail.com>
References: <5cbbe4ae0904130547h75e46fa1x3d364588fd2ba31e@mail.gmail.com>
	<20090413201125.GC651@ninagal.withay.com>
	<5cbbe4ae0904131321t5f0afb6epad18420ba783fec8@mail.gmail.com>
	<20090413212555.GE651@ninagal.withay.com>
	<5cbbe4ae0904141330p7a242fe6qf49bc8bbb3619698@mail.gmail.com>
Message-ID: <2558C8DA-5F8C-4FAF-88F1-89D899A681FD@macports.org>


On Apr 14, 2009, at 15:30, C. Florian Ebeling wrote:

> That's the reason for the suggestion to add a new dependency type  
> "gem" or
> "rubygem", which behaves much like "path" or "lib" dependencies.  
> Not controlling
> installation, but checking.

I don't quite understand how this suggestion would work, and on  
principle I think I'm not in favor of adding a new dependency type  
which is specific to a particular type of software. All existing  
dependency types are generic and applicable to all types of software,  
which is IMHO as it should be. If you want to depend on a gem, there  
should be a port for that gem, and you declare a dependency on the  
port as you would for any other type of software. There could,  
though, be shortcuts that would make such portfiles smaller. I think  
that would fall under the umbrella of a portgroup, like the perl5  
portgroup for simplifying Perl CPAN modules or the upcoming pecl  
portgroup for PHP PECL modules.

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


From florian.ebeling at gmail.com  Wed Apr 15 01:03:37 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Wed, 15 Apr 2009 10:03:37 +0200
Subject: ruby_select plan, rubygem: dependency operator
In-Reply-To: <9196B4F9-6954-4506-8A3D-A8F10E1B332F@macports.org>
References: <5cbbe4ae0904130547h75e46fa1x3d364588fd2ba31e@mail.gmail.com>
	<20090413201125.GC651@ninagal.withay.com>
	<5cbbe4ae0904131321t5f0afb6epad18420ba783fec8@mail.gmail.com>
	<20090413212555.GE651@ninagal.withay.com>
	<5cbbe4ae0904141330p7a242fe6qf49bc8bbb3619698@mail.gmail.com>
	<20090414234154.GK48922@ninagal.withay.com>
	<9196B4F9-6954-4506-8A3D-A8F10E1B332F@macports.org>
Message-ID: <5cbbe4ae0904150103h668abbbeq51074c4314d29bb4@mail.gmail.com>

>> What would be nice is some automatic wrapper for all the various
>> extensions
>> to languages (ruby, perl, python, etc) where you just say "I need xyz from
>> CPAN/gem" and port can handle it, and hence use it for dependencies. ?Of
>> course,
>> base has no support for such hence the need to wrap such things in
>> full-blown
>> ports, otherwise how do we know what is installed and and what version?
>> ?It
>> would still run the install through the proper tool, but also keep track
>> of
>> what is installed so it can be managed (and easily upgraded, activated,
>> etc), but wouldn't need to be a complete port. ?Instead it could be some
>> form of listing in a table someplace, for any extensions which are easily
>> installed.
>
> In lieu of this, a tool to mostly-automatically convert from those package
> managers to a MacPorts port is useful, c.f. cpan2port for converting CPAN
> perl modules to Portfiles.

A ruby port also consists of only 3 or 4 lines of effective code, if you use
the ruby.setup call from the ruby group file. What worries me more is
the brittleness when you just can pull away dependencies using the
special package manager, gem in the ruby case.




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



-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com

From florian.ebeling at gmail.com  Wed Apr 15 01:04:55 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Wed, 15 Apr 2009 10:04:55 +0200
Subject: ruby_select plan, rubygem: dependency operator
In-Reply-To: <20090414234154.GK48922@ninagal.withay.com>
References: <5cbbe4ae0904130547h75e46fa1x3d364588fd2ba31e@mail.gmail.com>
	<20090413201125.GC651@ninagal.withay.com>
	<5cbbe4ae0904131321t5f0afb6epad18420ba783fec8@mail.gmail.com>
	<20090413212555.GE651@ninagal.withay.com>
	<5cbbe4ae0904141330p7a242fe6qf49bc8bbb3619698@mail.gmail.com>
	<20090414234154.GK48922@ninagal.withay.com>
Message-ID: <5cbbe4ae0904150104v12b95741sf9d7152da6b6fefd@mail.gmail.com>

On Wed, Apr 15, 2009 at 1:41 AM, Bryan Blackburn <blb at macports.org> wrote:
> On Tue, Apr 14, 2009 at 10:30:11PM +0200, C. Florian Ebeling said:
>> On Mon, Apr 13, 2009 at 11:25 PM, Bryan Blackburn <blb at macports.org> wrote:
> [...]
>> >
>> > Unless there's better support in base for such things, the best option may
>> > be to try and document it with the right ports (via ui_msg) and mailing
>> > lists/FAQ/etc that certain things are needed for the newer stuff to work
>> > right...
>>
>> Hm, then it is really the question if this is worth the users' hassle, only
>> for the sake of an somewhat better naming. Python also has an largely
>> obsolete python (without version suffix) port, hasn't it?
>
> The py-* modules are all python 2.4-based modules, but since 2.5 is the
> currently-popular version and 2.6 starting to kick in, like you say it
> isn't worth the effort to rename to py24-*.
>
> [...]
>> >
>> > Ah, okay, I didn't see any rb19- ports but didn't look at the group code.
>> > Is there a possibility that they could eventually be merged once #126 is
>> > done, similar to how we'd like the python modules to work, as mentioned in
>> > #16723?
>>
>> The group code is already the same for ruby (1.8) and ruby19. There are
>> no rb19 ports yet because most ruby developers prefer rubygems over
>> ports using the 'gem' package manager. This tool now comes with
>> the (1.9) ruby release. So this approach mostly obsoletes older install.rb
>> and setup.rb methods. And gems as ports have issues.
>>
>> We have ports that are only a skin over rubygem installs, but that approach
>> is not ideal, because you can e.g. install the port and uninstall the gem, just
>> using the gem tool. And then it is registered as installed, where it
>> really isn't
>> present as a library. I and others therefore think that ports just brokering
>> gem installs should be avoided if possible.
>>
>> The obvious problem with no ruby lib ports is, once you want to add a port that
>> depends on a gem library, you cannot declare it.
>>
>> That's the reason for the suggestion to add a new dependency type "gem" or
>> "rubygem", which behaves much like "path" or "lib" dependencies. Not controlling
>> installation, but checking.
>
> What would be nice is some automatic wrapper for all the various extensions
> to languages (ruby, perl, python, etc) where you just say "I need xyz from
> CPAN/gem" and port can handle it, and hence use it for dependencies. ?Of course,
> base has no support for such hence the need to wrap such things in full-blown
> ports, otherwise how do we know what is installed and and what version? ?It
> would still run the install through the proper tool, but also keep track of
> what is installed so it can be managed (and easily upgraded, activated,
> etc), but wouldn't need to be a complete port. ?Instead it could be some
> form of listing in a table someplace, for any extensions which are easily
> installed.

That was the idea, basically. :)




-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com

From ryandesign at macports.org  Wed Apr 15 02:19:17 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 15 Apr 2009 04:19:17 -0500
Subject: ruby_select plan, rubygem: dependency operator
In-Reply-To: <5cbbe4ae0904150103h668abbbeq51074c4314d29bb4@mail.gmail.com>
References: <5cbbe4ae0904130547h75e46fa1x3d364588fd2ba31e@mail.gmail.com>
	<20090413201125.GC651@ninagal.withay.com>
	<5cbbe4ae0904131321t5f0afb6epad18420ba783fec8@mail.gmail.com>
	<20090413212555.GE651@ninagal.withay.com>
	<5cbbe4ae0904141330p7a242fe6qf49bc8bbb3619698@mail.gmail.com>
	<20090414234154.GK48922@ninagal.withay.com>
	<9196B4F9-6954-4506-8A3D-A8F10E1B332F@macports.org>
	<5cbbe4ae0904150103h668abbbeq51074c4314d29bb4@mail.gmail.com>
Message-ID: <6831B1CF-7D09-4221-AF09-6302A148E82B@macports.org>


On Apr 15, 2009, at 03:03, C. Florian Ebeling wrote:

> A ruby port also consists of only 3 or 4 lines of effective code,  
> if you use
> the ruby.setup call from the ruby group file. What worries me more is
> the brittleness when you just can pull away dependencies using the
> special package manager, gem in the ruby case.

Yes, it would be good to fix it so that users cannot cause that problem.


From florian.ebeling at gmail.com  Wed Apr 15 02:35:44 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Wed, 15 Apr 2009 11:35:44 +0200
Subject: ruby_select plan, rubygem: dependency operator
In-Reply-To: <6831B1CF-7D09-4221-AF09-6302A148E82B@macports.org>
References: <5cbbe4ae0904130547h75e46fa1x3d364588fd2ba31e@mail.gmail.com>
	<20090413201125.GC651@ninagal.withay.com>
	<5cbbe4ae0904131321t5f0afb6epad18420ba783fec8@mail.gmail.com>
	<20090413212555.GE651@ninagal.withay.com>
	<5cbbe4ae0904141330p7a242fe6qf49bc8bbb3619698@mail.gmail.com>
	<20090414234154.GK48922@ninagal.withay.com>
	<9196B4F9-6954-4506-8A3D-A8F10E1B332F@macports.org>
	<5cbbe4ae0904150103h668abbbeq51074c4314d29bb4@mail.gmail.com>
	<6831B1CF-7D09-4221-AF09-6302A148E82B@macports.org>
Message-ID: <5cbbe4ae0904150235h20a605a3occ1a5e01fb22bd2d@mail.gmail.com>

On Wed, Apr 15, 2009 at 11:19 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On Apr 15, 2009, at 03:03, C. Florian Ebeling wrote:
>
>> A ruby port also consists of only 3 or 4 lines of effective code, if you
>> use
>> the ruby.setup call from the ruby group file. What worries me more is
>> the brittleness when you just can pull away dependencies using the
>> special package manager, gem in the ruby case.
>
> Yes, it would be good to fix it so that users cannot cause that problem.

I don't see what the correct behaviour is, when having a port that wraps
over a gem, for instance. When the gem is loadable as ruby library, then
it is visible to the gem manager, and can be removed as well. Even if
there was a way to make a gem visible but not manipulatable, that would
be very strange behaviour from a ruby/gem perspective.

So I suggest not trying to stay in control here, but rather act like for
other dependencies for which we don't exert control (path, lib).

Or do you have an idea how to really fix this problem?





-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com

From febeling at macports.org  Wed Apr 15 02:40:49 2009
From: febeling at macports.org (C. Florian Ebeling)
Date: Wed, 15 Apr 2009 11:40:49 +0200
Subject: ruby_select plan, rubygem: dependency operator
In-Reply-To: <2558C8DA-5F8C-4FAF-88F1-89D899A681FD@macports.org>
References: <5cbbe4ae0904130547h75e46fa1x3d364588fd2ba31e@mail.gmail.com>
	<20090413201125.GC651@ninagal.withay.com>
	<5cbbe4ae0904131321t5f0afb6epad18420ba783fec8@mail.gmail.com>
	<20090413212555.GE651@ninagal.withay.com>
	<5cbbe4ae0904141330p7a242fe6qf49bc8bbb3619698@mail.gmail.com>
	<2558C8DA-5F8C-4FAF-88F1-89D899A681FD@macports.org>
Message-ID: <5cbbe4ae0904150240w49c93444k453e8ee4db744d64@mail.gmail.com>

On Wed, Apr 15, 2009 at 10:02 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On Apr 14, 2009, at 15:30, C. Florian Ebeling wrote:
>
>> That's the reason for the suggestion to add a new dependency type "gem" or
>> "rubygem", which behaves much like "path" or "lib" dependencies. Not
>> controlling
>> installation, but checking.
>
> I don't quite understand how this suggestion would work, and on principle I
> think I'm not in favor of adding a new dependency type which is specific to
> a particular type of software. All existing dependency types are generic and
> applicable to all types of software, which is IMHO as it should be. If you
> want to depend on a gem, there should be a port for that gem, and you
> declare a dependency on the port as you would for any other type of
> software. There could, though, be shortcuts that would make such portfiles
> smaller. I think that would fall under the umbrella of a portgroup, like the
> perl5 portgroup for simplifying Perl CPAN modules or the upcoming pecl
> portgroup for PHP PECL modules.

That's what we have right now with ruby group and ruby.setup call.
The problem is that the gem can be uninstalled through gem, leaving
an inconsistent install state behind in the mp registry.

I think that can come up with other dynamic languages as well, when
they have similar special package managers.





-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com

From ryandesign at macports.org  Wed Apr 15 03:16:49 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 15 Apr 2009 05:16:49 -0500
Subject: ruby_select plan, rubygem: dependency operator
In-Reply-To: <5cbbe4ae0904150235h20a605a3occ1a5e01fb22bd2d@mail.gmail.com>
References: <5cbbe4ae0904130547h75e46fa1x3d364588fd2ba31e@mail.gmail.com>
	<20090413201125.GC651@ninagal.withay.com>
	<5cbbe4ae0904131321t5f0afb6epad18420ba783fec8@mail.gmail.com>
	<20090413212555.GE651@ninagal.withay.com>
	<5cbbe4ae0904141330p7a242fe6qf49bc8bbb3619698@mail.gmail.com>
	<20090414234154.GK48922@ninagal.withay.com>
	<9196B4F9-6954-4506-8A3D-A8F10E1B332F@macports.org>
	<5cbbe4ae0904150103h668abbbeq51074c4314d29bb4@mail.gmail.com>
	<6831B1CF-7D09-4221-AF09-6302A148E82B@macports.org>
	<5cbbe4ae0904150235h20a605a3occ1a5e01fb22bd2d@mail.gmail.com>
Message-ID: <1A8A9AC2-3C0E-4BF0-9E3D-2B6A804579AE@macports.org>


On Apr 15, 2009, at 04:35, C. Florian Ebeling wrote:

> On Wed, Apr 15, 2009 at 11:19 AM, Ryan Schmidt wrote:
>
>> On Apr 15, 2009, at 03:03, C. Florian Ebeling wrote:
>>
>>> A ruby port also consists of only 3 or 4 lines of effective code,  
>>> if you
>>> use the ruby.setup call from the ruby group file. What worries me
>>> more is the brittleness when you just can pull away dependencies
>>> using the special package manager, gem in the ruby case.
>>
>> Yes, it would be good to fix it so that users cannot cause that  
>> problem.
>
> I don't see what the correct behaviour is, when having a port that  
> wraps
> over a gem, for instance. When the gem is loadable as ruby library,  
> then
> it is visible to the gem manager, and can be removed as well. Even if
> there was a way to make a gem visible but not manipulatable, that  
> would
> be very strange behaviour from a ruby/gem perspective.
>
> So I suggest not trying to stay in control here, but rather act  
> like for
> other dependencies for which we don't exert control (path, lib).
>
> Or do you have an idea how to really fix this problem?

How does the perl5 portgroup handle it? Is it using CPAN to install  
the modules, and can they then be uninstalled or upgraded by the user  
by using the cpan command?

For the pecl portgroup I'm working on, which will be based on the  
existing php5-* module ports, we do not use the pear command to  
install, so the user will hopefully not be able to use pear to  
upgrade or uninstall either.

Maybe it is simply a user error to use gem or cpan to manipulate  
those packages, and users just need to be educated to use MacPorts  
for all software installations.



From ryandesign at macports.org  Wed Apr 15 03:38:14 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 15 Apr 2009 05:38:14 -0500
Subject: volatile variants (was Re: Gimp 2.6 & Pango 1.8 : no font
	rendering)
In-Reply-To: <F2E5D1F5-AAC3-47F6-99F5-4D861E8752F4@macports.org>
References: <2DB9230F-D235-4509-9937-03995EDBDF69@gmail.ca>
	<99292962-5578-4FFF-B50D-89F27885A27E@macports.org>
	<49E406CD.3070906@macports.org>
	<56DC803E-264B-4C72-A20C-2EE06EA614E7@macports.org>
	<F2E5D1F5-AAC3-47F6-99F5-4D861E8752F4@macports.org>
Message-ID: <BEFD969E-5660-40DD-BF11-A6B3801F30EB@macports.org>

On Apr 14, 2009, at 18:49, Jeremy Huddleston wrote:

> I think it might be wise to create a list of such volatile variants  
> (system_x11, universal, no_x11, etc) and mention them to users in  
> the install guide, so they can make decisions about them before  
> it's too late.

That might be a good idea. Could you file a documentation ticket for  
that? It would also be good to describe these variants in the Guide  
and provide guidance for their use.


> Also, this brings up a point that has been bothering me for a  
> while.  Why do we have so many variants for what should really be a  
> single binary decision: +x11, +no_x11, +quartz, +no_quartz, +aqua

As David said, it's not necessarily a binary decision. For some  
ports, X11 and Quartz interfaces conflict, but for others, they  
don't. For example cairo by default builds with X11 support but not  
Quartz support. If you want both, you use just +quartz. If you want  
Quartz but no X11 support, you use +quartz +no_x11. If you want some  
undefined build that contains support for no graphics output at all,  
you use just +no_x11. :) Hmm, maybe I need to make that impossible.

Our tradition in MacPorts has been to enable X11 support by default,  
hence usually there is no +x11 variant, but there might be a +no_x11  
variant. This was just a natural application of the general principle  
that *any* feature should be enabled by default, to provide the most  
full-featured build possible by default, and provide +no_whatever  
variants to disable them if necessary. Some ports decided X11 support  
should be off by default. Maybe they have good reasons for that.  
Maybe they don't and should be changed.

+quartz provides the ability to use Mac OS X native drawing either in  
addition to or instead of X11 rendering, depending on the port (which  
depends on the abilities of the ported software).

No port has a variant +no_quartz.

You're probably right that +aqua could be renamed to +quartz for  
consistency. Though they may not necessarily mean the same thing. I  
think the original intention may have been for +quartz to use Mac OS  
X graphics rendering routines and +aqua to install a Mac OS X  
application bundle. These may go hand in hand, or they may not.  
Existing ports also might not necessarily follow this convention.


From ryandesign at macports.org  Wed Apr 15 03:49:29 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 15 Apr 2009 05:49:29 -0500
Subject: [python] py25-elixir broken
In-Reply-To: <a9444a980904140829h30aff2ccx2b8cc243827f019d@mail.gmail.com>
References: <a9444a980904140823q1b5980c5o2856dfaea376e15f@mail.gmail.com>
	<a9444a980904140829h30aff2ccx2b8cc243827f019d@mail.gmail.com>
Message-ID: <17CBB4F2-59AA-4962-8126-2AA47597A2E3@macports.org>


On Apr 14, 2009, at 10:29, Rasmus Andersson wrote:

> I could temporarily fix this by deactivating py25-sqlalchemy @0.5.2_0
> and activating the old py25-sqlalchemy @0.4.7p1_0
>
> Obviously the py25-elixir port is outdated. Support for SQLAlchemy 0.5
> first appeared in Elixir 0.6 ("Added support for SQLAlchemy 0.5" ?
> http://elixir.ematia.de/trac/browser/elixir/tags/0.6.0/CHANGES). That
> is; Elixir <0.6 only works with SQLAlchemy <0.5.

Would you please file a (single) port update ticket for py25-elixir  
and py-elixir?


> On Tue, Apr 14, 2009 at 17:23, Rasmus Andersson wrote:
>
>> just did sync + upgrade py25-elixir and it looks like someone  
>> upgraded
>> py25-sqlalchemy without upgrading/checking dependencies and/or  
>> someone
>> upgraded py25-elixir and did not test it.
>>
>> Below is my transcript. Note that openssl could not be installed but
>> was forced to anyway. But I guess that is not the core problem,  
>> right?

There is no problem with openssl. It was upgraded normally. It might  
be nice if those irrelevant error messages were not printed...

>> $ sudo port upgrade py25-elixir
[snip]
>> --->  Staging openssl into destroot
>> --->  Unable to uninstall openssl 0.9.8k_0, the following ports  
>> depend on it:
>> --->    wget
>> --->    lighttpd
>> --->    py25-hashlib
>> --->    curl
>> --->    nginx
>> --->    git-core
>> --->    python26
>> --->    py25-socket-ssl
>> --->    httperf
>> Warning: Uninstall forced.  Proceeding despite dependencies.
>> --->  Deactivating openssl @0.9.8k_0
>> --->  Uninstalling openssl @0.9.8k_0
>> --->  Installing openssl @0.9.8k_0
>> --->  Activating openssl @0.9.8k_0
>> --->  Cleaning openssl

I'm actually not sure why you got those messages. For one thing, you  
didn't use the "-f" flag when upgrading, so the uninstall was not  
forced. Second, it should not need to be forced; it should work on  
its own, since you're not uninstalling it directly; you're  
uninstalling it only indirectly as a consequence of upgrading which  
will cause the new version to be installed immediately. Possibly this  
is a special case since the old and new version and revision are  
identical (0.9.8k_0) which occurred because the openssl's epoch was  
incremented after it port was upgraded to 1.0.0 and then downgraded  
back to 0.9.8k when 1.0.0 was found to cause problems. Or maybe it's  
something that was fixed in a later version of MacPorts.


>> $ port version
>> Version: 1.700

You should upgrade to MacPorts 1.7.1 by typing

sudo port selfupdate



From florian.ebeling at gmail.com  Wed Apr 15 05:07:35 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Wed, 15 Apr 2009 14:07:35 +0200
Subject: ruby_select plan, rubygem: dependency operator
In-Reply-To: <1A8A9AC2-3C0E-4BF0-9E3D-2B6A804579AE@macports.org>
References: <5cbbe4ae0904130547h75e46fa1x3d364588fd2ba31e@mail.gmail.com>
	<5cbbe4ae0904131321t5f0afb6epad18420ba783fec8@mail.gmail.com>
	<20090413212555.GE651@ninagal.withay.com>
	<5cbbe4ae0904141330p7a242fe6qf49bc8bbb3619698@mail.gmail.com>
	<20090414234154.GK48922@ninagal.withay.com>
	<9196B4F9-6954-4506-8A3D-A8F10E1B332F@macports.org>
	<5cbbe4ae0904150103h668abbbeq51074c4314d29bb4@mail.gmail.com>
	<6831B1CF-7D09-4221-AF09-6302A148E82B@macports.org>
	<5cbbe4ae0904150235h20a605a3occ1a5e01fb22bd2d@mail.gmail.com>
	<1A8A9AC2-3C0E-4BF0-9E3D-2B6A804579AE@macports.org>
Message-ID: <5cbbe4ae0904150507k54338d76w4215c80125a49589@mail.gmail.com>

On Wed, Apr 15, 2009 at 12:16 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On Apr 15, 2009, at 04:35, C. Florian Ebeling wrote:
>
>> On Wed, Apr 15, 2009 at 11:19 AM, Ryan Schmidt wrote:
>>
>>> On Apr 15, 2009, at 03:03, C. Florian Ebeling wrote:
>>>
>>>> A ruby port also consists of only 3 or 4 lines of effective code, if you
>>>> use the ruby.setup call from the ruby group file. What worries me
>>>> more is the brittleness when you just can pull away dependencies
>>>> using the special package manager, gem in the ruby case.
>>>
>>> Yes, it would be good to fix it so that users cannot cause that problem.
>>
>> I don't see what the correct behaviour is, when having a port that wraps
>> over a gem, for instance. When the gem is loadable as ruby library, then
>> it is visible to the gem manager, and can be removed as well. Even if
>> there was a way to make a gem visible but not manipulatable, that would
>> be very strange behaviour from a ruby/gem perspective.
>>
>> So I suggest not trying to stay in control here, but rather act like for
>> other dependencies for which we don't exert control (path, lib).
>>
>> Or do you have an idea how to really fix this problem?
>
> How does the perl5 portgroup handle it? Is it using CPAN to install the
> modules, and can they then be uninstalled or upgraded by the user by using
> the cpan command?
>
> For the pecl portgroup I'm working on, which will be based on the existing
> php5-* module ports, we do not use the pear command to install, so the user
> will hopefully not be able to use pear to upgrade or uninstall either.

That is an approach that is certainly not acceptable for the
ruby community. There is really virbrant exchange and reuse
of gems over platforms like GutHub these days, and gem
comes as part of the standard ruby release. All these ruby
people would just walk away from MacPorts if where to try
and shut down use of gem for them.

I don't know if there is a way to make gems install in a
different location from port, and still have it visible from
ruby loading point of view. But I am pretty sure that view
is identical with the one gem sees in general, by virtue
of being a plain ruby script. Because of we made ruby
scripts require to add to the load path to see gems from
mp that would defy the effort.

>
> Maybe it is simply a user error to use gem or cpan to manipulate those
> packages, and users just need to be educated to use MacPorts for all
> software installations.

I agree, at the moment it is. But I think we could do a better job there.
Maybe these rubygems dependencies could even be installed without
a portfile and right through the special installer. Or that is too ambitious
and port should just fail and explain the missing dependency and show
the command to bring them into place. I don't know.

But the current situation is not really ideal. I understand your reluctance
to introduce very high-level dependency operators/types, because normally
MacPorts shouldn't have such a notion as "rubygem." But what are
better alternatives. As said, I find the "This is a user error" view not
too compelling (still it would involve the least work - we have it ;)





-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com

From ryandesign at macports.org  Wed Apr 15 05:20:28 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 15 Apr 2009 07:20:28 -0500
Subject: ruby_select plan, rubygem: dependency operator
In-Reply-To: <5cbbe4ae0904150507k54338d76w4215c80125a49589@mail.gmail.com>
References: <5cbbe4ae0904130547h75e46fa1x3d364588fd2ba31e@mail.gmail.com>
	<5cbbe4ae0904131321t5f0afb6epad18420ba783fec8@mail.gmail.com>
	<20090413212555.GE651@ninagal.withay.com>
	<5cbbe4ae0904141330p7a242fe6qf49bc8bbb3619698@mail.gmail.com>
	<20090414234154.GK48922@ninagal.withay.com>
	<9196B4F9-6954-4506-8A3D-A8F10E1B332F@macports.org>
	<5cbbe4ae0904150103h668abbbeq51074c4314d29bb4@mail.gmail.com>
	<6831B1CF-7D09-4221-AF09-6302A148E82B@macports.org>
	<5cbbe4ae0904150235h20a605a3occ1a5e01fb22bd2d@mail.gmail.com>
	<1A8A9AC2-3C0E-4BF0-9E3D-2B6A804579AE@macports.org>
	<5cbbe4ae0904150507k54338d76w4215c80125a49589@mail.gmail.com>
Message-ID: <62254081-7D1B-4A25-865D-3791609802E2@macports.org>

On Apr 15, 2009, at 07:07, C. Florian Ebeling wrote:

> On Wed, Apr 15, 2009 at 12:16 PM, Ryan Schmidt wrote:
>
>> On Apr 15, 2009, at 04:35, C. Florian Ebeling wrote:
>>
>>> On Wed, Apr 15, 2009 at 11:19 AM, Ryan Schmidt wrote:
>>>
>>>> On Apr 15, 2009, at 03:03, C. Florian Ebeling wrote:
>>>>
>>>>> A ruby port also consists of only 3 or 4 lines of effective  
>>>>> code, if you
>>>>> use the ruby.setup call from the ruby group file. What worries me
>>>>> more is the brittleness when you just can pull away dependencies
>>>>> using the special package manager, gem in the ruby case.
>>>>
>>>> Yes, it would be good to fix it so that users cannot cause that  
>>>> problem.
>>>
>>> I don't see what the correct behaviour is, when having a port  
>>> that wraps
>>> over a gem, for instance. When the gem is loadable as ruby  
>>> library, then
>>> it is visible to the gem manager, and can be removed as well.  
>>> Even if
>>> there was a way to make a gem visible but not manipulatable, that  
>>> would
>>> be very strange behaviour from a ruby/gem perspective.
>>>
>>> So I suggest not trying to stay in control here, but rather act  
>>> like for
>>> other dependencies for which we don't exert control (path, lib).
>>>
>>> Or do you have an idea how to really fix this problem?
>>
>> How does the perl5 portgroup handle it? Is it using CPAN to  
>> install the
>> modules, and can they then be uninstalled or upgraded by the user  
>> by using
>> the cpan command?
>>
>> For the pecl portgroup I'm working on, which will be based on the  
>> existing
>> php5-* module ports, we do not use the pear command to install, so  
>> the user
>> will hopefully not be able to use pear to upgrade or uninstall  
>> either.
>
> That is an approach that is certainly not acceptable for the
> ruby community. There is really virbrant exchange and reuse
> of gems over platforms like GutHub these days, and gem
> comes as part of the standard ruby release. All these ruby
> people would just walk away from MacPorts if where to try
> and shut down use of gem for them.
>
> I don't know if there is a way to make gems install in a
> different location from port, and still have it visible from
> ruby loading point of view. But I am pretty sure that view
> is identical with the one gem sees in general, by virtue
> of being a plain ruby script. Because of we made ruby
> scripts require to add to the load path to see gems from
> mp that would defy the effort.
>
>>
>> Maybe it is simply a user error to use gem or cpan to manipulate  
>> those
>> packages, and users just need to be educated to use MacPorts for all
>> software installations.
>
> I agree, at the moment it is. But I think we could do a better job  
> there.
> Maybe these rubygems dependencies could even be installed without
> a portfile and right through the special installer. Or that is too  
> ambitious
> and port should just fail and explain the missing dependency and show
> the command to bring them into place. I don't know.
>
> But the current situation is not really ideal. I understand your  
> reluctance
> to introduce very high-level dependency operators/types, because  
> normally
> MacPorts shouldn't have such a notion as "rubygem." But what are
> better alternatives. As said, I find the "This is a user error"  
> view not
> too compelling (still it would involve the least work - we have it ;)

Find a way to install the gem in a MacPorts port that does not cause  
the gem to show up when a user runs "gem". Build this into the ruby  
portgroup. Maybe we need to have a patched version of gem that we  
use. Maybe we need to not use gem at all to install.


From macports-mgr at lists.macosforge.org  Wed Apr 15 13:15:08 2009
From: macports-mgr at lists.macosforge.org (macports-mgr at lists.macosforge.org)
Date: Wed, 15 Apr 2009 13:15:08 -0700 (PDT)
Subject: PortIndex2MySQL run failure on Wednesday 2009-04-15 at 13:15:00
Message-ID: <20090415201508.344262696CB6@gamma.macosforge.org>


Synchronizing local ports tree from file:///rsync/macports-san/release/ports/
Error: CHILDSTATUS 2126 1: ERROR 1062 (23000) at line 43127: Duplicate entry 'php5-yaz' for key 1

From devans at macports.org  Wed Apr 15 13:24:54 2009
From: devans at macports.org (David Evans)
Date: Wed, 15 Apr 2009 13:24:54 -0700
Subject: volatile variants (was Re: Gimp 2.6 & Pango 1.8 : no
	font	rendering)
In-Reply-To: <BEFD969E-5660-40DD-BF11-A6B3801F30EB@macports.org>
References: <2DB9230F-D235-4509-9937-03995EDBDF69@gmail.ca>	<99292962-5578-4FFF-B50D-89F27885A27E@macports.org>	<49E406CD.3070906@macports.org>	<56DC803E-264B-4C72-A20C-2EE06EA614E7@macports.org>	<F2E5D1F5-AAC3-47F6-99F5-4D861E8752F4@macports.org>
	<BEFD969E-5660-40DD-BF11-A6B3801F30EB@macports.org>
Message-ID: <49E64296.2080108@macports.org>

Ryan Schmidt wrote:
> If you want some undefined build that contains support for no graphics 
> output at all, you use just +no_x11. :) Hmm, maybe I need to make that 
> impossible.
Actually cairo with just +no_x11 still  has several backends available.  
For instance, you can render SVG, PDF, PNG, etc to a file.

In addition, I think the documentation should stress the pitfalls of - 
variants (like -x11) since they aren't handled well by MacPorts.  It would
work better if ports with default variants would just make the 
equivalent actions part of the default behavior of the port and provide 
+no_whatever variants to
remove a particular default behavior if desired.

From frstan at bellsouth.net  Wed Apr 15 15:20:51 2009
From: frstan at bellsouth.net (William Davis)
Date: Wed, 15 Apr 2009 18:20:51 -0400
Subject: port index failures
Message-ID: <25F23686-4327-46B8-AB11-7C0673AAF0CC@bellsouth.net>

fyi
Total number of ports parsed: 5746
Ports successfully parsed: 5745
Ports failed: 1


Failed to parse file php/php5-yaz/Portfile: couldn't execute "\$ 
{prefix}/bin/php-config": no such file or directory


William Davis
frstanATbellsouthDOTnet
Mac OS X.5.6 Darwin 9.5.0
XQuartz 2.3.3_rc5 (xorg-server 1.4.2-apple41)
Mac Mini Intel Duo @ 1.86 GHz

Mundus vult decepi, ego non


From ryandesign at macports.org  Wed Apr 15 17:58:48 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 15 Apr 2009 19:58:48 -0500
Subject: port index failures
In-Reply-To: <25F23686-4327-46B8-AB11-7C0673AAF0CC@bellsouth.net>
References: <25F23686-4327-46B8-AB11-7C0673AAF0CC@bellsouth.net>
Message-ID: <406E9750-14AC-418B-8639-F667CDDCBDD5@macports.org>

On Apr 15, 2009, at 17:20, William Davis wrote:

> fyi
> Total number of ports parsed: 5746
> Ports successfully parsed: 5745
> Ports failed: 1
>
>
> Failed to parse file php/php5-yaz/Portfile: couldn't execute "\$ 
> {prefix}/bin/php-config": no such file or directory
>

Yes, I'm subscribed to the changes list too. :) I should fix this error.


From raimue at macports.org  Wed Apr 15 21:54:47 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 16 Apr 2009 06:54:47 +0200
Subject: ruby_select plan, rubygem: dependency operator
In-Reply-To: <20090414234154.GK48922@ninagal.withay.com>
References: <5cbbe4ae0904130547h75e46fa1x3d364588fd2ba31e@mail.gmail.com>	<20090413201125.GC651@ninagal.withay.com>	<5cbbe4ae0904131321t5f0afb6epad18420ba783fec8@mail.gmail.com>	<20090413212555.GE651@ninagal.withay.com>	<5cbbe4ae0904141330p7a242fe6qf49bc8bbb3619698@mail.gmail.com>
	<20090414234154.GK48922@ninagal.withay.com>
Message-ID: <49E6BA17.7050205@macports.org>

Bryan Blackburn wrote:
> What would be nice is some automatic wrapper for all the various extensions
> to languages (ruby, perl, python, etc) where you just say "I need xyz from
> CPAN/gem" and port can handle it, and hence use it for dependencies.  Of course,
> base has no support for such hence the need to wrap such things in full-blown
> ports, otherwise how do we know what is installed and and what version?  It
> would still run the install through the proper tool, but also keep track of
> what is installed so it can be managed (and easily upgraded, activated,
> etc), but wouldn't need to be a complete port.  Instead it could be some
> form of listing in a table someplace, for any extensions which are easily
> installed.

Such cpan: or rubygem: dependencies would cause some problems. If there
is no port for a language module, I would have to use cpan or gem to
install it. This is probably acceptable for developers, but quite
complicated for users.

And in the ongoing effort to provide binaries, it would probably cause
problems to make binary archives of these dependencies as no Portfiles
exist.

So if we are going to do something like this, we do not only need it for
dependencies, but also a new way to refer to such a "port" from the
command line.

How would we specify additional build options or customizations to fit
better into MacPorts? Probably only using a port. So if this is going to
be implemented, it should still always check if a port of that name
exists and prefer that.

Rainer

From macports-mgr at lists.macosforge.org  Thu Apr 16 01:15:09 2009
From: macports-mgr at lists.macosforge.org (macports-mgr at lists.macosforge.org)
Date: Thu, 16 Apr 2009 01:15:09 -0700 (PDT)
Subject: PortIndex2MySQL run failure on Thursday 2009-04-16 at 01:15:00
Message-ID: <20090416081509.BF8F326A71D5@gamma.macosforge.org>


Synchronizing local ports tree from file:///rsync/macports-san/release/ports/
Error: CHILDSTATUS 35836 1: ERROR 1062 (23000) at line 43127: Duplicate entry 'php5-yaz' for key 1

From jannis at leidel.info  Thu Apr 16 04:34:43 2009
From: jannis at leidel.info (Jannis Leidel)
Date: Thu, 16 Apr 2009 13:34:43 +0200
Subject: "Lite" vs. "Full" Python Ports
In-Reply-To: <20090414233454.GJ48922@ninagal.withay.com>
References: <F4917587-3230-4ED6-98BB-83F7EB14DAB7@macports.org>
	<20090412211712.GF15239@ninagal.withay.com>
	<49E339FD.7020509@macports.org>
	<0DA9CCCB-25D5-4764-81A0-828FCBA8B157@macports.org>
	<49E35DE1.3080002@macports.org>
	<20090413211903.GD651@ninagal.withay.com>
	<69527FED-FA3B-47A1-9E5E-F745764F3B8D@macports.org>
	<20090414200026.GC48922@ninagal.withay.com>
	<FA8A6947-4AF0-4E6A-B820-6C0D85A87067@leidel.info>
	<20090414233454.GJ48922@ninagal.withay.com>
Message-ID: <116F2E90-5E15-43A1-A261-264390CB2D8A@leidel.info>


Am 15.04.2009 um 01:34 schrieb Bryan Blackburn:

> On Tue, Apr 14, 2009 at 10:19:30PM +0200, Jannis Leidel said:
>> Am 14.04.2009 um 22:00 schrieb Bryan Blackburn:
> [...]
>>> As long as the one in lib-dynload is always loaded first, it  
>>> shouldn't
>>> be
>>> too big a deal, but someone really should test it...
>>
>> At the risk of not knowing how that could be tested thoroughly: I'm
>> running python25 with the patch I attached to #12369 for several  
>> days now
>> without a problem. That also fixed #18567 for me.
>
> Optimally, having an older version of one of the modules (eg, py25- 
> hashlib
> at 2.5.2) installed with python25 at 2.5.4 with hashlib builtin,  
> would be a
> meaningful test.  Then trying it with various bits that affect how  
> modules
> are loaded (eg, normal, with -S, others?) would answer it fully I  
> think.

I haven't been able to downgrade the installed py25-hashlib to 2.5.2  
but did some tests with python25 with the builtin hashlib and py25-hashlib at 2.5.4_0 
  installed. I also tested with a virtualenv and a sandboxed  
virtualenv (--no-site-packages).

~ $ python
Python 2.5.4 (r254:67916, Apr 10 2009, 23:33:06)
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import hashlib
 >>> hashlib.__file__
'/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/hashlib.pyc'
 >>>
~ $ python -S
Python 2.5.4 (r254:67916, Apr 10 2009, 23:33:06)
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
 >>> import hashlib
 >>> hashlib.__file__
'/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/hashlib.pyc'
 >>>
~ $ python -c "import hashlib; print hashlib.__file__"
/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/hashlib.pyc
~ $
~ $ port installed | grep py25-virtualenv
   py25-virtualenv @1.3.2_0 (active)
~ $ which virtualenv
/opt/local/bin/virtualenv
~ $
~ $ virtualenv hashlib-test
New python executable in hashlib-test/bin/python
Installing setuptools............done.
~ $ source hashlib-test/bin/ac
activate          activate_this.py
~ $ source hashlib-test/bin/activate
(hashlib-test)~ $ which python
/Users/Jannis/hashlib-test/bin/python
(hashlib-test)~ $ python
Python 2.5.4 (r254:67916, Apr 10 2009, 23:33:06)
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import hashlib
 >>> hashlib.__file__
'/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/hashlib.pyc'
 >>>
(hashlib-test)~ $ python -c "import hashlib; print hashlib.__file__"
/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/hashlib.pyc
(hashlib-test)~ $ deactivate
~ $
~ $
~ $ virtualenv --no-site-packages hashlib-test2
New python executable in hashlib-test2/bin/python
Installing setuptools............done.
~ $ source hashlib-test2/bin/activate
(hashlib-test2)~ $ python
Python 2.5.4 (r254:67916, Apr 10 2009, 23:33:06)
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import hashlib
 >>> hashlib.__file__
'/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/hashlib.pyc'
 >>>

Jannis

From dweber at macports.org  Fri Apr 17 11:04:50 2009
From: dweber at macports.org (Darren Weber)
Date: Fri, 17 Apr 2009 11:04:50 -0700
Subject: how-to delete a registry entry?
In-Reply-To: <49E7E76E.5010507@macports.org>
References: <b808b3510904161603g718e0793o82500a2a28833b43@mail.gmail.com>
	<49E7E76E.5010507@macports.org>
Message-ID: <b808b3510904171104m2b58e33bk6f5bb9c2a67d0777@mail.gmail.com>

I made the stupid mistake of removing some registry (ie, receipt) files, so
now I get

[ me at XXX ~/ports ]$ port installed
Error: port installed failed: list must have an even number of elements
No ports are installed.

I ran a few port uninstall commands and then checked that the ports were not
installed, but

port installed | grep <portname>

continued to indicate that the ports were installed (see my other list post
on that topic).  I should like 'port installed' to indicate that a port is
no longer installed after running 'port uninstall <port>'.  So I started to
read up on how to remove the receipts using the API somehow, but I couldn't
do that and I did just removed the files.  Lesson learned, but now it needs
to be fixed - how can I regenerate the registry?

FYI:

[ me at XXX ~/ports ]$ port -d installed
DEBUG: list must have an even number of elements
    while executing
"array set receipt_$ref $receipt_contents"
    (procedure "receipt_flat::open_entry" line 84)
    invoked from within
"${macports::registry.format}::open_entry $name $version $revision
$variants"
    (procedure "open_entry" line 4)
    invoked from within
"open_entry $iname $iversion $irevision $ivariants"
    (procedure "registry::installed" line 13)
    invoked from within
"registry::installed"
Error: port installed failed: list must have an even number of elements
No ports are installed.






On Thu, Apr 16, 2009 at 7:20 PM, Rainer M?ller <raimue at macports.org> wrote:

> Darren Weber wrote:
> >
> > There is some documentation here on the macports API, including some
> > registry functions:
> > http://guide.macports.org/#internals.apis
> >
> > How is the API called?  It is a tcl API, so is it loaded into tclsh?
>
> This is only meant for internal use inside of MacPorts. What are you
> trying to do with the registry?
>
> Rainer
>
> PS: This topic may have been better suited for macports-dev.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090417/f88099bc/attachment.html>

From jmr at macports.org  Fri Apr 17 12:16:45 2009
From: jmr at macports.org (Joshua Root)
Date: Sat, 18 Apr 2009 05:16:45 +1000
Subject: how-to delete a registry entry?
In-Reply-To: <b808b3510904171104m2b58e33bk6f5bb9c2a67d0777@mail.gmail.com>
References: <b808b3510904161603g718e0793o82500a2a28833b43@mail.gmail.com>	<49E7E76E.5010507@macports.org>
	<b808b3510904171104m2b58e33bk6f5bb9c2a67d0777@mail.gmail.com>
Message-ID: <49E8D59D.7010202@macports.org>

Darren Weber wrote:
> 
> I made the stupid mistake of removing some registry (ie, receipt) files,
> so now I get
> 
> [ me at XXX ~/ports ]$ port installed
> Error: port installed failed: list must have an even number of elements
> No ports are installed.
> 
> I ran a few port uninstall commands and then checked that the ports were
> not installed, but
> 
> port installed | grep <portname>
> 
> continued to indicate that the ports were installed (see my other list
> post on that topic).

Did you also delete the receipt's enclosing directories?

- Josh

From dweber at macports.org  Fri Apr 17 14:13:49 2009
From: dweber at macports.org (Darren Weber)
Date: Fri, 17 Apr 2009 14:13:49 -0700
Subject: how-to delete a registry entry?
In-Reply-To: <49E8D59D.7010202@macports.org>
References: <b808b3510904161603g718e0793o82500a2a28833b43@mail.gmail.com>
	<49E7E76E.5010507@macports.org>
	<b808b3510904171104m2b58e33bk6f5bb9c2a67d0777@mail.gmail.com>
	<49E8D59D.7010202@macports.org>
Message-ID: <b808b3510904171413t204cf384nbd068cc62f9faf3b@mail.gmail.com>

Yes, I think the receipt directories were removed entirely.

I had something like this after doing all the uninstalls on these ports:

[ me at XXX ~/src/kitware/VTK_build ]$ port installed | grep vtk
  vtk @5.2.1_0+darwin_9+examples+tclSys+testing
  vtk5 @5.2.0_0+darwin_9+examples+shared+tclSys+testing
  vtk5 @5.2.0_0+darwin_9+examples+tclSys+testing
  vtk52 @5.2.1_0+darwin_9+examples+tclSys+testing
  vtk54 @5.4.0_0+darwin_9+examples+tclSys+testing

I don't recall the details on how I removed the receipts exactly.  I do have
two systems with very similar installs.  On the system with untouched
receipts, there are the following receipt directories:

[ me at XXX ~/src/kitware/VTK_build ]$ ls /opt/local/var/macports/receipts/vtk*
/opt/local/var/macports/receipts/vtk:
5.2.1_0+darwin_9+examples+tclSys+testing/

/opt/local/var/macports/receipts/vtk5:
5.2.0_0+darwin_9+examples+shared+tclSys+testing/
5.2.0_0+darwin_9+examples+tclSys+testing/

/opt/local/var/macports/receipts/vtk52:
5.2.1_0+darwin_9+examples+tclSys+testing/

/opt/local/var/macports/receipts/vtk54:
5.4.0_0+darwin_9+examples+tclSys+testing/


On the system where receipt files were removed, all those directories are
missing.  So it might have been

sudo rm -rf /opt/local/var/macports/receipts/vtk*





On Fri, Apr 17, 2009 at 12:16 PM, Joshua Root <jmr at macports.org> wrote:

> Darren Weber wrote:
> >
> > I made the stupid mistake of removing some registry (ie, receipt) files,
> > so now I get
> >
> > [ me at XXX ~/ports ]$ port installed
> > Error: port installed failed: list must have an even number of elements
> > No ports are installed.
> >
> > I ran a few port uninstall commands and then checked that the ports were
> > not installed, but
> >
> > port installed | grep <portname>
> >
> > continued to indicate that the ports were installed (see my other list
> > post on that topic).
>
> Did you also delete the receipt's enclosing directories?
>
> - Josh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090417/6ba21c59/attachment.html>

From raimue at macports.org  Fri Apr 17 17:24:06 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 18 Apr 2009 02:24:06 +0200
Subject: NewHelpSystem & man pages
In-Reply-To: <0619E040-BF3F-4E1D-93A7-58EDA171B45E@macports.org>
References: <fc.004c4c5811f738aa004c4c5811f738aa.11f752fd@biola.edu>
	<49E4F79E.9000307@macports.org>
	<0619E040-BF3F-4E1D-93A7-58EDA171B45E@macports.org>
Message-ID: <49E91DA6.7080105@macports.org>

Ryan Schmidt wrote:
> On Apr 14, 2009, at 15:52, Rainer M?ller wrote:
> 
>> I made a call for contributions on macports-users before about writing
>> more helpful strings for the current implementation, but nobody  
>> seems to
>> be interested. So why should I not be allowed to do something about it
>> if nobody else cares? And as it is me doing the work, I am going to do
>> it in a way I like.
> 
> I admit I don't remember this prior message, but there are so many  
> messages, it's easy to forget some.

Yes, this even was about a year ago. Easy to forget about that in this
large time frame :-)

But there is still a reminder ticket for it at
<http://trac.macports.org/ticket/15467>

Rainer

From frstan at bellsouth.net  Fri Apr 17 22:54:42 2009
From: frstan at bellsouth.net (William Davis)
Date: Sat, 18 Apr 2009 01:54:42 -0400
Subject: Ruby upgrade missing defs
Message-ID: <88B796A8-855F-4A55-9960-799B08818991@bellsouth.net>

there are some missing definitions in the Ruby upgrade 1.8.7-p160_0:
opps lost the copy/past


William Davis
frstanATbellsouthDOTnet
Mac OS X.5.6 Darwin 9.5.0
XQuartz 2.3.3_rc5 (xorg-server 1.4.2-apple41)
Mac Mini Intel Duo @ 1.86 GHz

Mundus vult decepi, ego non


From frstan at bellsouth.net  Fri Apr 17 23:23:57 2009
From: frstan at bellsouth.net (William Davis)
Date: Sat, 18 Apr 2009 02:23:57 -0400
Subject: darwinbuild error
Message-ID: <5451E513-3906-4023-8589-33340A618D89@bellsouth.net>

error in darwinbuild upgrade:

DEBUG: invalid command name "svn.revision"
     while executing
"svn.revision	${revision}"
     (file "Portfile" line 27)
     invoked from within
"source Portfile"
     invoked from within
"$workername eval source Portfile"
     (procedure "mportopen" line 46)
     invoked from within
"mportopen $porturl [array get options] [array get variations]"
Error: Unable to open port:


William Davis
frstanATbellsouthDOTnet
Mac OS X.5.6 Darwin 9.5.0
XQuartz 2.3.3_rc5 (xorg-server 1.4.2-apple41)
Mac Mini Intel Duo @ 1.86 GHz

Mundus vult decepi, ego non


From wsiegrist at apple.com  Fri Apr 17 23:45:10 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Fri, 17 Apr 2009 23:45:10 -0700
Subject: darwinbuild error
In-Reply-To: <5451E513-3906-4023-8589-33340A618D89@bellsouth.net>
References: <5451E513-3906-4023-8589-33340A618D89@bellsouth.net>
Message-ID: <7E68102C-0DFD-4530-ACB3-162638EC97D6@apple.com>

On Apr 17, 2009, at 11:23 PM, William Davis wrote:

> error in darwinbuild upgrade:
>
> DEBUG: invalid command name "svn.revision"
>    while executing
> "svn.revision	${revision}"
>    (file "Portfile" line 27)
>    invoked from within
> "source Portfile"
>    invoked from within
> "$workername eval source Portfile"
>    (procedure "mportopen" line 46)
>    invoked from within
> "mportopen $porturl [array get options] [array get variations]"
> Error: Unable to open port:
>
>

So 1.7.1 still uses svn.tag but our auto-linting server is running  
1.8? I'll revert the change to svn.revision and just ignore the lint  
reports for now.

-Bill



From wsiegrist at apple.com  Fri Apr 17 23:49:12 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Fri, 17 Apr 2009 23:49:12 -0700
Subject: darwinbuild error
In-Reply-To: <7E68102C-0DFD-4530-ACB3-162638EC97D6@apple.com>
References: <5451E513-3906-4023-8589-33340A618D89@bellsouth.net>
	<7E68102C-0DFD-4530-ACB3-162638EC97D6@apple.com>
Message-ID: <CD5F1801-57ED-414A-83EA-5E7C07F1ABFD@apple.com>

On Apr 17, 2009, at 11:45 PM, William Siegrist wrote:

> On Apr 17, 2009, at 11:23 PM, William Davis wrote:
>
>> error in darwinbuild upgrade:
>>
>> DEBUG: invalid command name "svn.revision"
>>   while executing
>> "svn.revision	${revision}"
>>   (file "Portfile" line 27)
>>   invoked from within
>> "source Portfile"
>>   invoked from within
>> "$workername eval source Portfile"
>>   (procedure "mportopen" line 46)
>>   invoked from within
>> "mportopen $porturl [array get options] [array get variations]"
>> Error: Unable to open port:
>>
>>
>
> So 1.7.1 still uses svn.tag but our auto-linting server is running  
> 1.8? I'll revert the change to svn.revision and just ignore the lint  
> reports for now.
>

And it seems like the server should be linting with the released  
version of MP instead of trunk. Could portmgr just confirm this and I  
will downgrade it?

Thanks
-Bill

From blb at macports.org  Sat Apr 18 01:21:57 2009
From: blb at macports.org (Bryan Blackburn)
Date: Sat, 18 Apr 2009 02:21:57 -0600
Subject: darwinbuild error
In-Reply-To: <CD5F1801-57ED-414A-83EA-5E7C07F1ABFD@apple.com>
References: <5451E513-3906-4023-8589-33340A618D89@bellsouth.net>
	<7E68102C-0DFD-4530-ACB3-162638EC97D6@apple.com>
	<CD5F1801-57ED-414A-83EA-5E7C07F1ABFD@apple.com>
Message-ID: <20090418082157.GK36642@ninagal.withay.com>

On Fri, Apr 17, 2009 at 11:49:12PM -0700, William Siegrist said:
> On Apr 17, 2009, at 11:45 PM, William Siegrist wrote:
[...]
>>
>> So 1.7.1 still uses svn.tag but our auto-linting server is running 1.8? 
>> I'll revert the change to svn.revision and just ignore the lint reports 
>> for now.
>>
>
> And it seems like the server should be linting with the released version 
> of MP instead of trunk. Could portmgr just confirm this and I will 
> downgrade it?

Using a release version of lint definitely makes more sense than a trunk
version, since I imagine many committers and most maintainers are running a
release as well.

However, switching to 1.7.1 would stop the server from updating the
PortIndex.quick file, right?  At least we resolved issues with the server
generating that when it was first turned on, but we'd need to make sure
those who are running trunk know how to deal with this file (from a
permissions point of view).

Bryan


>
> Thanks
> -Bill

From wsiegrist at apple.com  Sat Apr 18 05:44:34 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Sat, 18 Apr 2009 05:44:34 -0700
Subject: darwinbuild error
In-Reply-To: <20090418082157.GK36642@ninagal.withay.com>
References: <5451E513-3906-4023-8589-33340A618D89@bellsouth.net>
	<7E68102C-0DFD-4530-ACB3-162638EC97D6@apple.com>
	<CD5F1801-57ED-414A-83EA-5E7C07F1ABFD@apple.com>
	<20090418082157.GK36642@ninagal.withay.com>
Message-ID: <0FEF70B2-ACE6-4E1C-9E76-45D3A1C3CFD6@apple.com>

On Apr 18, 2009, at 1:21 AM, Bryan Blackburn wrote:

> On Fri, Apr 17, 2009 at 11:49:12PM -0700, William Siegrist said:
>> On Apr 17, 2009, at 11:45 PM, William Siegrist wrote:
> [...]
>>>
>>> So 1.7.1 still uses svn.tag but our auto-linting server is running  
>>> 1.8?
>>> I'll revert the change to svn.revision and just ignore the lint  
>>> reports
>>> for now.
>>>
>>
>> And it seems like the server should be linting with the released  
>> version
>> of MP instead of trunk. Could portmgr just confirm this and I will
>> downgrade it?
>
> Using a release version of lint definitely makes more sense than a  
> trunk
> version, since I imagine many committers and most maintainers are  
> running a
> release as well.
>
> However, switching to 1.7.1 would stop the server from updating the
> PortIndex.quick file, right?  At least we resolved issues with the  
> server
> generating that when it was first turned on, but we'd need to make  
> sure
> those who are running trunk know how to deal with this file (from a
> permissions point of view).
>

I was going to try downgrading just portlint.tcl. If that didnt work,  
I would make a separate 1.7.1 install just for the purposes of linting.

-Bill




From frstan at bellsouth.net  Sat Apr 18 07:24:07 2009
From: frstan at bellsouth.net (William Davis)
Date: Sat, 18 Apr 2009 10:24:07 -0400
Subject: darwinbuild error
In-Reply-To: <20090418082157.GK36642@ninagal.withay.com>
References: <5451E513-3906-4023-8589-33340A618D89@bellsouth.net>
	<7E68102C-0DFD-4530-ACB3-162638EC97D6@apple.com>
	<CD5F1801-57ED-414A-83EA-5E7C07F1ABFD@apple.com>
	<20090418082157.GK36642@ninagal.withay.com>
Message-ID: <A7C1CCE8-4D91-47FA-8571-48D6310D132C@bellsouth.net>


On Apr 18, 2009, at 4:21 AM, Bryan Blackburn wrote:

> On Fri, Apr 17, 2009 at 11:49:12PM -0700, William Siegrist said:
>> On Apr 17, 2009, at 11:45 PM, William Siegrist wrote:
> [...]
>>>
>>> So 1.7.1 still uses svn.tag but our auto-linting server is running  
>>> 1.8?
>>> I'll revert the change to svn.revision and just ignore the lint  
>>> reports
>>> for now.
>>>
>>
>> And it seems like the server should be linting with the released  
>> version
>> of MP instead of trunk. Could portmgr just confirm this and I will
>> downgrade it?
>
> Using a release version of lint definitely makes more sense than a  
> trunk
> version, since I imagine many committers and most maintainers are  
> running a
> release as well.
>
> However, switching to 1.7.1 would stop the server from updating the
> PortIndex.quick file, right?  At least we resolved issues with the  
> server
> generating that when it was first turned on, but we'd need to make  
> sure
> those who are running trunk know how to deal with this file (from a
> permissions point of view).
>
> Bryan
>
>
>>
>> Thanks
>> -Bill
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


thanks, it upgrades fine now.

William Davis
frstanATbellsouthDOTnet
Mac OS X.5.6 Darwin 9.5.0
XQuartz 2.3.3_rc5 (xorg-server 1.4.2-apple41)
Mac Mini Intel Duo @ 1.86 GHz

Mundus vult decepi, ego non


From max at inmachina.com  Sat Apr 18 12:07:49 2009
From: max at inmachina.com (Maximilian Nickel)
Date: Sat, 18 Apr 2009 21:07:49 +0200
Subject: ATLAS 64bit defect
Message-ID: <7bad5d350904181207x5041ebeasb07f5d5e52eb610a@mail.gmail.com>

Hi,
i filed a ticket a while ago that ATLAS in macports gets currently compiled
as 64bit. Unfortunatly the orginal maintainer doesnt seem to respond, so i'm
posting it to the mailing list.
The ticket is here:
http://trac.macports.org/ticket/19189

The part in the ATLAS documentation covering the flag is here (Section
3.6.1):
http://math-atlas.sourceforge.net/atlas_install/atlas_install.html#SECTION00046000000000000000

The port is also outdated and i could provide a Portfile for the new
version, i just decided to not include the version bump in the defect patch

Regards
/max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090418/0c776e97/attachment.html>

From blb at macports.org  Sat Apr 18 13:20:40 2009
From: blb at macports.org (Bryan Blackburn)
Date: Sat, 18 Apr 2009 14:20:40 -0600
Subject: darwinbuild error
In-Reply-To: <0FEF70B2-ACE6-4E1C-9E76-45D3A1C3CFD6@apple.com>
References: <5451E513-3906-4023-8589-33340A618D89@bellsouth.net>
	<7E68102C-0DFD-4530-ACB3-162638EC97D6@apple.com>
	<CD5F1801-57ED-414A-83EA-5E7C07F1ABFD@apple.com>
	<20090418082157.GK36642@ninagal.withay.com>
	<0FEF70B2-ACE6-4E1C-9E76-45D3A1C3CFD6@apple.com>
Message-ID: <20090418202040.GC38087@ninagal.withay.com>

On Sat, Apr 18, 2009 at 05:44:34AM -0700, William Siegrist said:
> On Apr 18, 2009, at 1:21 AM, Bryan Blackburn wrote:
>
>> On Fri, Apr 17, 2009 at 11:49:12PM -0700, William Siegrist said:
>>> On Apr 17, 2009, at 11:45 PM, William Siegrist wrote:
>> [...]
>>>>
>>>> So 1.7.1 still uses svn.tag but our auto-linting server is running  
>>>> 1.8?
>>>> I'll revert the change to svn.revision and just ignore the lint  
>>>> reports
>>>> for now.
>>>>
>>>
>>> And it seems like the server should be linting with the released  
>>> version
>>> of MP instead of trunk. Could portmgr just confirm this and I will
>>> downgrade it?
>>
>> Using a release version of lint definitely makes more sense than a  
>> trunk
>> version, since I imagine many committers and most maintainers are  
>> running a
>> release as well.
>>
>> However, switching to 1.7.1 would stop the server from updating the
>> PortIndex.quick file, right?  At least we resolved issues with the  
>> server
>> generating that when it was first turned on, but we'd need to make sure
>> those who are running trunk know how to deal with this file (from a
>> permissions point of view).
>>
>
> I was going to try downgrading just portlint.tcl. If that didnt work, I 
> would make a separate 1.7.1 install just for the purposes of linting.

If you don't mind the increase in work that means for you on the server,
then that should give us the best of both.  Though I have no idea how well
an older portlint.tcl will work with a newer everything-else.

Bryan


>
> -Bill

From frstan at bellsouth.net  Sat Apr 18 13:45:26 2009
From: frstan at bellsouth.net (William Davis)
Date: Sat, 18 Apr 2009 16:45:26 -0400
Subject: Ruby upgrade missing defs
In-Reply-To: <88B796A8-855F-4A55-9960-799B08818991@bellsouth.net>
References: <88B796A8-855F-4A55-9960-799B08818991@bellsouth.net>
Message-ID: <C8033B87-F853-4F53-BA52-C30F764933CA@bellsouth.net>

here they are. this is in the latest change:

No definition for bsock_do_not_rev_lookup
.
No definition for bsock_do_not_rev_lookup_set
.
No definition for bsock_s_for_fd
.
No definition for bsock_close_read
.
No definition for bsock_close_write
.
No definition for bsock_shutdown
...
No definition for bsock_getsockname
.
No definition for bsock_getpeername
.
No definition for bsock_send
.
No definition for bsock_recv
..
No definition for ip_addr
.
No definition for ip_peeraddr
.
No definition for ip_recvfrom
.
No definition for ip_s_getaddress
...
No definition for socks_init
.
No definition for socks_s_close
.
No definition for tcp_accept
..
No definition for tcp_sysaccept
.
No definition for tcp_svr_init
..
No definition for udp_init
.
No definition for udp_connect
.
No definition for udp_bind
.
No definition for udp_send
..
No definition for unix_init
.
No definition for unix_path
.
No definition for unix_addr
.
No definition for unix_peeraddr
.
No definition for unix_recvfrom
.
No definition for unix_send_io
.
No definition for unix_recv_io
.
No definition for unix_s_socketpair
.
No definition for unix_s_socketpair
.
No definition for unix_svr_init
.
No definition for unix_accept
..
No definition for unix_sysaccept
..
No definition for sock_initialize
..........
No definition for sock_s_socketpair
.
No definition for sock_s_socketpair
.
No definition for sock_gethostname
..
No definition for sock_s_gethostbyaddr
...
No definition for sock_s_getnameinfo
.
No definition for sock_s_pack_sockaddr_in
.
No definition for sock_s_pack_sockaddr_in
.
No definition for sock_s_unpack_sockaddr_in
.
No definition for sock_s_pack_sockaddr_un
.
No definition for sock_s_pack_sockaddr_un
.
No definition for sock_s_unpack_sockaddr_un

                          stringio.c:  
c...........................................................

On Apr 18, 2009, at 1:54 AM, William Davis wrote:

> there are some missing definitions in the Ruby upgrade 1.8.7-p160_0:
> opps lost the copy/past
>
>
> William Davis
> frstanATbellsouthDOTnet
> Mac OS X.5.6 Darwin 9.5.0
> XQuartz 2.3.3_rc5 (xorg-server 1.4.2-apple41)
> Mac Mini Intel Duo @ 1.86 GHz
>
> Mundus vult decepi, ego non
>
> _______________________________________________
> 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.6 Darwin 9.5.0
XQuartz 2.3.3_rc5 (xorg-server 1.4.2-apple41)
Mac Mini Intel Duo @ 1.86 GHz

Mundus vult decepi, ego non


From kimuraw at macports.org  Sat Apr 18 18:23:36 2009
From: kimuraw at macports.org (kimura wataru)
Date: Sun, 19 Apr 2009 10:23:36 +0900
Subject: Ruby upgrade missing defs
In-Reply-To: <C8033B87-F853-4F53-BA52-C30F764933CA@bellsouth.net>
References: <88B796A8-855F-4A55-9960-799B08818991@bellsouth.net>
	<C8033B87-F853-4F53-BA52-C30F764933CA@bellsouth.net>
Message-ID: <20090419102336960813.054be18e@macports.org>

Hi,

This message appears at destroot and means rdoc document
is not written in ext/socket/socket.c. The message does not
mean program errors, then we can ignore this.

I'll ask why documents are missing in ext/socket/socket.c
to the list ruby-dev.
 
Thanks,

On Sat, 18 Apr 2009 16:45:26 -0400, William Davis wrote:
> here they are. this is in the latest change:
> 
> No definition for bsock_do_not_rev_lookup
> .
> No definition for bsock_do_not_rev_lookup_set
> .
> No definition for bsock_s_for_fd


-- 
kimura wataru

From jmr at macports.org  Sat Apr 18 19:28:13 2009
From: jmr at macports.org (Joshua Root)
Date: Sun, 19 Apr 2009 12:28:13 +1000
Subject: [49835] trunk/dports/gnome/libgnomecanvas/Portfile
Message-ID: <49EA8C3D.3020307@macports.org>

> -depends_lib \
> -    path:lib/pkgconfig/glib-2.0.pc:glib2 \
> -    port:gtk2 \
> -    path:lib/pkgconfig/pango.pc:pango \
> -    port:gettext \
> -    port:libiconv \
> -	port:libart_lgpl \
> -	port:libglade2
> +depends_lib     port:gtk2 \
> +                port:gettext \
> +                port:libiconv \
> +                port:libart_lgpl \
> +                port:libglade2

You might as well remove all of the redundant dependencies while you're
at it, gettext and libiconv being the ones I noticed here.

- Josh

From ryandesign at macports.org  Sun Apr 19 01:48:16 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 19 Apr 2009 03:48:16 -0500
Subject: darwinbuild error
In-Reply-To: <20090418202040.GC38087@ninagal.withay.com>
References: <5451E513-3906-4023-8589-33340A618D89@bellsouth.net>
	<7E68102C-0DFD-4530-ACB3-162638EC97D6@apple.com>
	<CD5F1801-57ED-414A-83EA-5E7C07F1ABFD@apple.com>
	<20090418082157.GK36642@ninagal.withay.com>
	<0FEF70B2-ACE6-4E1C-9E76-45D3A1C3CFD6@apple.com>
	<20090418202040.GC38087@ninagal.withay.com>
Message-ID: <E7DD5240-4DC5-45F7-AFC5-B648231F6646@macports.org>

On Apr 18, 2009, at 15:20, Bryan Blackburn wrote:

> On Sat, Apr 18, 2009 at 05:44:34AM -0700, William Siegrist said:
>> On Apr 18, 2009, at 1:21 AM, Bryan Blackburn wrote:
>>
>>> On Fri, Apr 17, 2009 at 11:49:12PM -0700, William Siegrist said:
>>>> On Apr 17, 2009, at 11:45 PM, William Siegrist wrote:
>>> [...]
>>>>>
>>>>> So 1.7.1 still uses svn.tag but our auto-linting server is running
>>>>> 1.8?
>>>>> I'll revert the change to svn.revision and just ignore the lint
>>>>> reports for now.
>>>>
>>>> And it seems like the server should be linting with the released
>>>> version
>>>> of MP instead of trunk. Could portmgr just confirm this and I will
>>>> downgrade it?
>>>
>>> Using a release version of lint definitely makes more sense than a
>>> trunk
>>> version, since I imagine many committers and most maintainers are
>>> running a
>>> release as well.
>>>
>>> However, switching to 1.7.1 would stop the server from updating the
>>> PortIndex.quick file, right?  At least we resolved issues with the
>>> server
>>> generating that when it was first turned on, but we'd need to  
>>> make sure
>>> those who are running trunk know how to deal with this file (from a
>>> permissions point of view).
>>
>> I was going to try downgrading just portlint.tcl. If that didnt  
>> work, I
>> would make a separate 1.7.1 install just for the purposes of linting.
>
> If you don't mind the increase in work that means for you on the  
> server,
> then that should give us the best of both.  Though I have no idea  
> how well
> an older portlint.tcl will work with a newer everything-else.

I would still rather that port lint, even in today's 1.8.0 trunk, did  
not warn that svn.tag is deprecated, because it cannot be considered  
deprecated until after we have released a version of MacPorts  
containing its replacement, svn.revision. After 1.8.0 is released,  
then we can add the deprecation warning back to trunk.



From jmr at macports.org  Sun Apr 19 02:03:09 2009
From: jmr at macports.org (Joshua Root)
Date: Sun, 19 Apr 2009 19:03:09 +1000
Subject: darwinbuild error
In-Reply-To: <E7DD5240-4DC5-45F7-AFC5-B648231F6646@macports.org>
References: <5451E513-3906-4023-8589-33340A618D89@bellsouth.net>	<7E68102C-0DFD-4530-ACB3-162638EC97D6@apple.com>	<CD5F1801-57ED-414A-83EA-5E7C07F1ABFD@apple.com>	<20090418082157.GK36642@ninagal.withay.com>	<0FEF70B2-ACE6-4E1C-9E76-45D3A1C3CFD6@apple.com>	<20090418202040.GC38087@ninagal.withay.com>
	<E7DD5240-4DC5-45F7-AFC5-B648231F6646@macports.org>
Message-ID: <49EAE8CD.40204@macports.org>

Ryan Schmidt wrote:
> I would still rather that port lint, even in today's 1.8.0 trunk, did
> not warn that svn.tag is deprecated, because it cannot be considered
> deprecated until after we have released a version of MacPorts containing
> its replacement, svn.revision. After 1.8.0 is released, then we can add
> the deprecation warning back to trunk.

*After* 1.8.0 is released? Isn't the intention to deprecate svn.tag *in*
1.8.0?

- Josh

From wsiegrist at apple.com  Sun Apr 19 02:19:45 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Sun, 19 Apr 2009 02:19:45 -0700
Subject: darwinbuild error
In-Reply-To: <20090418202040.GC38087@ninagal.withay.com>
References: <5451E513-3906-4023-8589-33340A618D89@bellsouth.net>
	<7E68102C-0DFD-4530-ACB3-162638EC97D6@apple.com>
	<CD5F1801-57ED-414A-83EA-5E7C07F1ABFD@apple.com>
	<20090418082157.GK36642@ninagal.withay.com>
	<0FEF70B2-ACE6-4E1C-9E76-45D3A1C3CFD6@apple.com>
	<20090418202040.GC38087@ninagal.withay.com>
Message-ID: <E6E98BBD-A9E8-43B7-832A-5DBB8B094163@apple.com>

On Apr 18, 2009, at 1:20 PM, Bryan Blackburn wrote:

> On Sat, Apr 18, 2009 at 05:44:34AM -0700, William Siegrist said:
>> On Apr 18, 2009, at 1:21 AM, Bryan Blackburn wrote:
>>
>>> On Fri, Apr 17, 2009 at 11:49:12PM -0700, William Siegrist said:
>>>> On Apr 17, 2009, at 11:45 PM, William Siegrist wrote:
>>> [...]
>>>
>>
>> I was going to try downgrading just portlint.tcl. If that didnt  
>> work, I
>> would make a separate 1.7.1 install just for the purposes of linting.
>
> If you don't mind the increase in work that means for you on the  
> server,
> then that should give us the best of both.  Though I have no idea  
> how well
> an older portlint.tcl will work with a newer everything-else.
>
> Bryan


After further investigation, the message is due to portfetch setting  
an option_proc on svn.tag (portlint has nothing to do with this). I do  
not want to try downgrading portfetch, and I do not want to disable  
all deprecation warnings, and I do not want to have to manually  
maintain all the uses of deprecation throughout the code. So we're  
back to having a separate release-install on the servers.  There have  
been times when portmgr has asked for portlint.tcl to be rolled  
forward to pick up new rules, so perhaps lint rules should move to  
_resources? Otherwise, I can just upgrade portlint on the release  
install as needed.

Also, I noticed that using the "-q" option does not suppress ui_warns  
at least in this case of deprecation warnings. Not sure if thats  
intentional.

-Bill

From ryandesign at macports.org  Sun Apr 19 02:26:14 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 19 Apr 2009 04:26:14 -0500
Subject: darwinbuild error
In-Reply-To: <49EAE8CD.40204@macports.org>
References: <5451E513-3906-4023-8589-33340A618D89@bellsouth.net>	<7E68102C-0DFD-4530-ACB3-162638EC97D6@apple.com>	<CD5F1801-57ED-414A-83EA-5E7C07F1ABFD@apple.com>	<20090418082157.GK36642@ninagal.withay.com>	<0FEF70B2-ACE6-4E1C-9E76-45D3A1C3CFD6@apple.com>	<20090418202040.GC38087@ninagal.withay.com>
	<E7DD5240-4DC5-45F7-AFC5-B648231F6646@macports.org>
	<49EAE8CD.40204@macports.org>
Message-ID: <D7F516FB-9F8C-4EFA-9452-D91278A3D1B0@macports.org>

On Apr 19, 2009, at 04:03, Joshua Root wrote:

> Ryan Schmidt wrote:
>> I would still rather that port lint, even in today's 1.8.0 trunk, did
>> not warn that svn.tag is deprecated, because it cannot be considered
>> deprecated until after we have released a version of MacPorts  
>> containing
>> its replacement, svn.revision. After 1.8.0 is released, then we  
>> can add
>> the deprecation warning back to trunk.
>
> *After* 1.8.0 is released? Isn't the intention to deprecate svn.tag  
> *in*
> 1.8.0?

I don't care when maintainers start switching svn.tag to  
svn.revision, so long as it's not before 1.8.0 is released. People  
running lint in trunk, or in this case people receiving lint emails  
from the server that's running trunk, may erroneously believe they  
should already today make this change, which is detrimental to do  
until users have upgraded to 1.8.0.


From arthurk at macports.org  Sun Apr 19 06:05:21 2009
From: arthurk at macports.org (Arthur Koziel)
Date: Sun, 19 Apr 2009 15:05:21 +0200
Subject: "Lite" vs. "Full" Python Ports
In-Reply-To: <116F2E90-5E15-43A1-A261-264390CB2D8A@leidel.info>
References: <F4917587-3230-4ED6-98BB-83F7EB14DAB7@macports.org>
	<20090412211712.GF15239@ninagal.withay.com>
	<49E339FD.7020509@macports.org>
	<0DA9CCCB-25D5-4764-81A0-828FCBA8B157@macports.org>
	<49E35DE1.3080002@macports.org>
	<20090413211903.GD651@ninagal.withay.com>
	<69527FED-FA3B-47A1-9E5E-F745764F3B8D@macports.org>
	<20090414200026.GC48922@ninagal.withay.com>
	<FA8A6947-4AF0-4E6A-B820-6C0D85A87067@leidel.info>
	<20090414233454.GJ48922@ninagal.withay.com>
	<116F2E90-5E15-43A1-A261-264390CB2D8A@leidel.info>
Message-ID: <849726D2-C503-4EA0-BF86-F6066B554FD9@macports.org>

I've been running the patched python25 port for over a week now and  
can only confirm what Jannis said. There are no problems.
I tested the following ports:

	? py25-zlib
	? py25-hashlib
	? py25-bsddb
	? py25-sqlite3
	? py25-tkinter
	? py25-bz2
	? py25-gdbm
	? py25-readline
	? py25-curses

Every module works fine. Even installing the python25 port first and  
then, for example, py25-bsddb will not give the new files precedence:

$ port contents py25-bsddb
Port py25-bsddb contains:
   /opt/local/lib/python2.5/site-packages/_bsddb-2.5.4-py2.5.egg-info
   /opt/local/lib/python2.5/site-packages/_bsddb.so

 >>> import bsddb
 >>> bsddb.__file__
'/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/bsddb/__init__.pyc'

I've also looked through older port versions. None of them changes the  
"python.pkgd" setting. Thus those modules will always get installed  
into the site-packages directory and will not be imported.

Arthur

On 16.04.2009, at 13:34, Jannis Leidel wrote:
>> Optimally, having an older version of one of the modules (eg, py25- 
>> hashlib
>> at 2.5.2) installed with python25 at 2.5.4 with hashlib builtin,  
>> would be a
>> meaningful test.  Then trying it with various bits that affect how  
>> modules
>> are loaded (eg, normal, with -S, others?) would answer it fully I  
>> think.
>
> I haven't been able to downgrade the installed py25-hashlib to 2.5.2  
> but did some tests with python25 with the builtin hashlib and py25-hashlib at 2.5.4_0 
>  installed. I also tested with a virtualenv and a sandboxed  
> virtualenv (--no-site-packages).
>
> ~ $ python
> Python 2.5.4 (r254:67916, Apr 10 2009, 23:33:06)
> [GCC 4.0.1 (Apple Inc. build 5490)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import hashlib
> >>> hashlib.__file__
> '/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
> python2.5/hashlib.pyc'
> >>>
> ~ $ python -S
> Python 2.5.4 (r254:67916, Apr 10 2009, 23:33:06)
> [GCC 4.0.1 (Apple Inc. build 5490)] on darwin
> >>> import hashlib
> >>> hashlib.__file__
> '/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
> python2.5/hashlib.pyc'
> >>>
> ~ $ python -c "import hashlib; print hashlib.__file__"
> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
> python2.5/hashlib.pyc
> ~ $
> ~ $ port installed | grep py25-virtualenv
>  py25-virtualenv @1.3.2_0 (active)
> ~ $ which virtualenv
> /opt/local/bin/virtualenv
> ~ $
> ~ $ virtualenv hashlib-test
> New python executable in hashlib-test/bin/python
> Installing setuptools............done.
> ~ $ source hashlib-test/bin/ac
> activate          activate_this.py
> ~ $ source hashlib-test/bin/activate
> (hashlib-test)~ $ which python
> /Users/Jannis/hashlib-test/bin/python
> (hashlib-test)~ $ python
> Python 2.5.4 (r254:67916, Apr 10 2009, 23:33:06)
> [GCC 4.0.1 (Apple Inc. build 5490)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import hashlib
> >>> hashlib.__file__
> '/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
> python2.5/hashlib.pyc'
> >>>
> (hashlib-test)~ $ python -c "import hashlib; print hashlib.__file__"
> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
> python2.5/hashlib.pyc
> (hashlib-test)~ $ deactivate
> ~ $
> ~ $
> ~ $ virtualenv --no-site-packages hashlib-test2
> New python executable in hashlib-test2/bin/python
> Installing setuptools............done.
> ~ $ source hashlib-test2/bin/activate
> (hashlib-test2)~ $ python
> Python 2.5.4 (r254:67916, Apr 10 2009, 23:33:06)
> [GCC 4.0.1 (Apple Inc. build 5490)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import hashlib
> >>> hashlib.__file__
> '/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
> python2.5/hashlib.pyc'
> >>>
>
> Jannis
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


From simon at ruderich.org  Sun Apr 19 08:02:53 2009
From: simon at ruderich.org (Simon Ruderich)
Date: Sun, 19 Apr 2009 17:02:53 +0200
Subject: NewHelpSystem & man pages
In-Reply-To: <49DFAF39.2070304@macports.org>
References: <fc.004c4c5811efa0e7004c4c5811efa0e7.11f3c16d@biola.edu>
	<49DFAF39.2070304@macports.org>
Message-ID: <20090419150253.GA24363@ruderich.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Apr 10, 2009 at 10:42:33PM +0200, Rainer M?ller wrote:
> For everyone who did not notice yet what this is about, I documented my
> plans about a new help system based on AsciiDoc at
> <http://trac.macports.org/wiki/NewHelpSystem>.

Hi all,

First I want to apologize for being inactive in the last months.
I only have sporadic access to a Mac at the moment (I switched to
Linux with my main machine) so my activity was very low. But I
like the MacPorts project and will continue to update my ports
when I have time and access to my Mac. But as I will not be very
active feel free to take over my ports.

Regarding the guide. I think for now the guide should use DocBook
at least until it's finished. Then we can decide if we want to
switch. But the duplication pointed out by Mark is an important
factor. So I think we should make a quick decision if the man
pages should be written in DocBook or Asciidoc. And after the
decision all other documents should be merged and removed so we
only have one source and no duplication.

If we switch the man pages to Asciidoc then all man pages in
base/doc/ should only be generated through Asciidoc so we have a
single format.

The only problematic man page is portfile.7 as it is directly
wired into the guide. I would like to remove it (or generate it
through DocBook) and instead install the guide in
/opt/local/share/doc/port/ so the user can access it.

We should really remove all duplication and move documentation
either to base/doc or doc, but not in both places.

Thanks,
Simon
- -- 
+ privacy is necessary
+ using http://gnupg.org
+ public key id: 0x6115F804EFB33229
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknrPR0ACgkQYRX4BO+zMil8ygCgwWNB0Mumz4BPmKtGUe26kaBc
/b0AoKg1wx4iOkj80BuZ50V3nnVbX6EZ
=HTco
-----END PGP SIGNATURE-----

From raimue at macports.org  Sun Apr 19 13:44:49 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sun, 19 Apr 2009 22:44:49 +0200
Subject: [49835] trunk/dports/gnome/libgnomecanvas/Portfile
In-Reply-To: <49EA8C3D.3020307@macports.org>
References: <49EA8C3D.3020307@macports.org>
Message-ID: <49EB8D41.9090608@macports.org>

Joshua Root wrote:
> You might as well remove all of the redundant dependencies while you're
> at it, gettext and libiconv being the ones I noticed here.

But sometimes redundant dependencies can also be useful. If the port is
using gettext and libiconv itself, it is okay to add it to the list of
dependencies.

What if a new gtk2 release would remove gettext and libiconv from the
requirements? This port would still require it. And I don't think
anybody would scan all dependents before making such changes.

I thought about letting 'port lint' check for redundant dependencies,
but abandoned the idea to avoid such situations.

Rainer

From jmr at macports.org  Sun Apr 19 23:39:46 2009
From: jmr at macports.org (Joshua Root)
Date: Mon, 20 Apr 2009 16:39:46 +1000
Subject: [49835] trunk/dports/gnome/libgnomecanvas/Portfile
In-Reply-To: <49EB8D41.9090608@macports.org>
References: <49EA8C3D.3020307@macports.org> <49EB8D41.9090608@macports.org>
Message-ID: <49EC18B2.10307@macports.org>

Rainer M?ller wrote:
> Joshua Root wrote:
>> You might as well remove all of the redundant dependencies while you're
>> at it, gettext and libiconv being the ones I noticed here.
> 
> But sometimes redundant dependencies can also be useful. If the port is
> using gettext and libiconv itself, it is okay to add it to the list of
> dependencies.
> 
> What if a new gtk2 release would remove gettext and libiconv from the
> requirements? This port would still require it. And I don't think
> anybody would scan all dependents before making such changes.

Sure, but if you list everything the average gnome port links against,
the list is going to be VERY long. Using the same deps as garnome is
usually a reasonable policy.

- Josh

From raimue at macports.org  Mon Apr 20 15:07:34 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Tue, 21 Apr 2009 00:07:34 +0200
Subject: GSoC: Accepted students announced
Message-ID: <49ECF226.6090802@macports.org>

Hi,

in this years edition of Google Summer of Code, The MacPorts Project
will mentor the following 2 students:

  Juan Germ?n Casta?eda Echevarr?a:
     GUI frontend using MacPorts.framework

  Dmitry Gorbik:
     Logging system

Dmitry, Juan, welcome to our community!
I would appreciate if you two could reply with a few words about your
projects as introduction to the macports-dev list for those who are
interested.

More information about the proposals and the projects are available at
<http://socghop.appspot.com/org/home/google/gsoc2009/macports>.


In overall, we had less applicants than last year. It seems like we were
not able to attract many students to work for us. If you have ideas what
we could improve for a possible next year, let me know. For example, we
did not get any proposal for the MPWA task while we got quite a few last
year.

Also, we would have gotten another third slot from Google implementing a
'Scan for broken library dependencies'. But unfortunately, the student
also got accepted for an internship at another company and decided to go
there instead of doing GSoC. In lack of other high quality proposals we
had to give this slot back to the general pool and therefore gave a
student for another project a chance.

Looking forward to this summer's work and its results,
Rainer

From ryandesign at macports.org  Tue Apr 21 06:37:14 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 21 Apr 2009 08:37:14 -0500
Subject: can't read "configure.universal_ldflags": no such variable
Message-ID: <6F1859E6-412B-4195-B936-FBC6CA96F2A0@macports.org>

I am having trouble upgrading an increasing number of ports (for  
example whois, glib2, python25). I'm only seeing this problem on one  
machine, as far as I can tell, which is running Mac OS X 10.4.11  
Intel, Xcode 2.5, MacPorts 1.7.1. Any ideas? Is anyone else seeing this?


$ port -uxd upgrade whois
DEBUG: Found port in file:///Users/rschmidt/macports/dports/net/whois
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: whois 4.7.33_0 exists in the ports tree
DEBUG: whois 4.7.32_0+universal is installed
DEBUG: whois 4.7.32_0+universal is active
DEBUG: Found port in file:///Users/rschmidt/macports/dports/devel/ 
gettext
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: gettext 0.17_4 exists in the ports tree
DEBUG: gettext 0.17_4+universal is installed
DEBUG: gettext 0.17_4+universal is active
DEBUG: Found port in file:///Users/rschmidt/macports/dports/textproc/ 
libiconv
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: libiconv 1.12_2 exists in the ports tree
DEBUG: libiconv 1.12_2+universal is installed
DEBUG: libiconv 1.12_2+universal is active
DEBUG: Found port in file:///Users/rschmidt/macports/dports/devel/gperf
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: gperf 3.0.4_0 exists in the ports tree
DEBUG: gperf 3.0.4_0 is installed
DEBUG: gperf 3.0.4_0 is active
DEBUG: No need to upgrade! gperf 3.0.4_0 >= gperf 3.0.4_0
DEBUG: No need to upgrade! libiconv 1.12_2 >= libiconv 1.12_2
DEBUG: Found port in file:///Users/rschmidt/macports/dports/devel/ 
ncurses
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: ncurses 5.7_0 exists in the ports tree
DEBUG: ncurses 5.7_0+universal is installed
DEBUG: ncurses 5.7_0+universal is active
DEBUG: Found port in file:///Users/rschmidt/macports/dports/devel/ 
ncursesw
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: ncursesw 5.7_0 exists in the ports tree
DEBUG: ncursesw 5.7_0+universal is installed
DEBUG: ncursesw 5.7_0+universal is active
DEBUG: No need to upgrade! ncursesw 5.7_0 >= ncursesw 5.7_0
DEBUG: No need to upgrade! ncurses 5.7_0 >= ncurses 5.7_0
DEBUG: Found port in file:///Users/rschmidt/macports/dports/textproc/ 
expat
DEBUG: epoch: in tree: 0 installed: 0
DEBUG: expat 2.0.1_0 exists in the ports tree
DEBUG: expat 2.0.1_0+universal is installed
DEBUG: expat 2.0.1_0+universal is active
DEBUG: No need to upgrade! expat 2.0.1_0 >= expat 2.0.1_0
DEBUG: No need to upgrade! gettext 0.17_4 >= gettext 0.17_4
DEBUG: variants to install {} universal
DEBUG: available variants are : darwin universal
DEBUG: variant universal is present in whois 4.7.33_0
DEBUG: new portvariants: universal +
DEBUG: Changing to port directory: /Users/rschmidt/macports/dports/ 
net/whois
DEBUG: setting option os.universal_supported to yes
DEBUG: org.macports.load registered provides 'load', a pre-existing  
procedure. Target override will not be provided
DEBUG: org.macports.distfiles registered provides 'distfiles', a pre- 
existing procedure. Target override will not be provided
DEBUG: universal variant already exists, so not adding the default one
DEBUG: Requested variant i386 is not provided by port whois.
DEBUG: Requested variant macosx is not provided by port whois.
DEBUG: Executing variant darwin provides darwin
DEBUG: Executing variant universal provides universal
DEBUG: Found port in file:///Users/rschmidt/macports/dports/devel/ 
gettext
DEBUG: Changing to port directory: /Users/rschmidt/macports/dports/ 
devel/gettext
DEBUG: setting option os.universal_supported to yes
DEBUG: org.macports.load registered provides 'load', a pre-existing  
procedure. Target override will not be provided
DEBUG: org.macports.distfiles registered provides 'distfiles', a pre- 
existing procedure. Target override will not be provided
DEBUG: Using group file /Users/rschmidt/macports/dports/_resources/ 
port1.0/group/muniversal-1.0.tcl
DEBUG: universal variant already exists, so not adding the default one
DEBUG: Requested variant darwin is not provided by port gettext.
DEBUG: Requested variant i386 is not provided by port gettext.
DEBUG: Requested variant macosx is not provided by port gettext.
DEBUG: Executing variant universal provides universal
DEBUG: can't read "configure.universal_ldflags": no such variable
     while executing
"eval configure.ldflags-append   ${configure.universal_ldflags}"
     (procedure "variant-universal" line 18)
     invoked from within
"variant-universal"
     invoked from within
"catch "variant-${name}" result"
Error: Error executing universal: can't read  
"configure.universal_ldflags": no such variable
DEBUG: Error evaluating variants
     while executing
"error "Error evaluating variants""
     (procedure "mportopen" line 57)
     invoked from within
"mportopen $porturl $options $variations"
     (procedure "mportdepends" line 66)
     invoked from within
"mportdepends $mport $target"
     (procedure "mportexec" line 23)
     invoked from within
"mportexec $workername $upgrade_action"
Error: Unable to upgrade port: Error evaluating variants
$


From jmr at macports.org  Tue Apr 21 08:15:14 2009
From: jmr at macports.org (Joshua Root)
Date: Wed, 22 Apr 2009 01:15:14 +1000
Subject: can't read "configure.universal_ldflags": no such variable
In-Reply-To: <6F1859E6-412B-4195-B936-FBC6CA96F2A0@macports.org>
References: <6F1859E6-412B-4195-B936-FBC6CA96F2A0@macports.org>
Message-ID: <49EDE302.7040902@macports.org>

Ryan Schmidt wrote:
> I am having trouble upgrading an increasing number of ports (for example
> whois, glib2, python25). I'm only seeing this problem on one machine, as
> far as I can tell, which is running Mac OS X 10.4.11 Intel, Xcode 2.5,
> MacPorts 1.7.1. Any ideas? Is anyone else seeing this?
> 
> 
> $ port -uxd upgrade whois
...
> DEBUG: Using group file
> /Users/rschmidt/macports/dports/_resources/port1.0/group/muniversal-1.0.tcl

Your whois Portfile is obviously different to the one in the tree (which
doesn't use muniversal), so it's going to be difficult for anyone else
to debug.

- Josh

From ryandesign at macports.org  Tue Apr 21 08:17:19 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 21 Apr 2009 10:17:19 -0500
Subject: [49949] trunk/dports/gnome
In-Reply-To: <20090420193307.A7107160220B@beta.macosforge.org>
References: <20090420193307.A7107160220B@beta.macosforge.org>
Message-ID: <66E2683F-2474-43E1-81F0-1ECFF483F455@macports.org>

On Apr 20, 2009, at 14:33, nox at macports.org wrote:

> Revision: 49949
>           http://trac.macports.org/changeset/49949
> Author:   nox at macports.org
> Date:     2009-04-20 12:33:06 -0700 (Mon, 20 Apr 2009)
> Log Message:
> -----------
> dia-devel: New port.

This port looks very different from the dia port. It would be best to  
keep the dia and dia-devel ports as similar as possible.

The dia port has many fewer dependencies, perhaps because gtk2 brings  
in the rest already. Perhaps you could do it that way in dia-devel as  
well. Otherwise, I suggest you modify the pango, cairo and glib2  
dependencies to allow pango-devel, cairo-devel and glib2-devel to  
satisfy them.


> Added Paths:
> -----------
>     trunk/dports/gnome/dia-devel/
>     trunk/dports/gnome/dia-devel/Portfile
>
> Added: trunk/dports/gnome/dia-devel/Portfile
> ===================================================================
> --- trunk/dports/gnome/dia-devel/Portfile	                         
> (rev 0)
> +++ trunk/dports/gnome/dia-devel/Portfile	2009-04-20 19:33:06 UTC  
> (rev 49949)
> @@ -0,0 +1,55 @@
> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode:  
> nil; c-basic-offset: 4 -*-  
> vim:fenc=utf-8:filetype=tcl:et:sw=4:ts=4:sts=4
> +# $Id$
> +
> +PortSystem      1.0
> +
> +name            dia-devel
> +set my_name     dia
> +version         0.97-pre3
> +maintainers     nox openmaintainer
> +categories      gnome
> +platforms       darwin
> +description     A diagram program.
> +
> +long_description \
> +    Dia is designed to be much like the commercial Windows \
> +    program Visio. It can be used to draw many different kinds \
> +    of diagrams. It currently has special objects to help draw \
> +    entity relationship diagrams, UML diagrams, flowcharts, \
> +    network diagrams, and simple circuits. It is also possible \
> +    to add support for new shapes by writing simple XML files, \
> +    using a subset of SVG to draw the shape.
> +
> +homepage        http://live.gnome.org/Dia
> +master_sites    gnome:sources/${my_name}/[lindex [split ${version}  
> -] 0]/
> +distname        ${my_name}-${version}
> +use_bzip2       yes
> +
> +checksums       md5     2723bccfdca2c0af9b85074b11f101e0 \
> +                sha1    091301bdf43a0518ca492b8cb94a6829a1f1876b \
> +                rmd160  b6a18ee3821daef46025e700bb24822c5774e760
> +
> +depends_build \
> +    port:intltool
> +
> +depends_lib \
> +    port:cairo \
> +    port:freetype \
> +    port:libart_lgpl \
> +    port:libpng \
> +    port:libxml2 \
> +    port:libxslt \
> +    port:gettext \
> +    port:glib2 \
> +    port:gtk2 \
> +    port:pango \
> +    port:popt \
> +    port:zlib
> +
> +configure.args \
> +    --with-cairo \
> +    --with-xslt-prefix=${prefix}
> +
> +livecheck.check regex
> +livecheck.url   http://ftp.gnome.org/pub/gnome/sources/${my_name}/ 
> [lindex [split ${version} -] 0]/
> +livecheck.regex {LATEST-IS-(\d+(?:\.\d+)*(?:-pre\d)*)}



From davidstuartbruce at gmail.com  Tue Apr 21 08:21:23 2009
From: davidstuartbruce at gmail.com (David Bruce)
Date: Tue, 21 Apr 2009 10:21:23 -0500
Subject: Setting up multiple MacPorts copies on one machine
Message-ID: <9a3504f50904210821n2d733d0ta2199b8d6aba1156@mail.gmail.com>

Hi,

I maintain the tuxmath and tuxtype ports (and am also upstream
maintainer for both).

I initially got interested in MacPorts as a way of making binary dmg
files for our Mac users, even if they don't use MacPorts.  I can now
build universal (32-bit PPC/Intel, that is) mdmg files for the
programs, although they probably only work on Leopard.

Recently on this list it was recommended that for situations like
mine, I build the dmgs to install under something other than the
default /opt/local, so that they not conflict with MacPorts-installed
packages if the user happens to have MacPorts.  So, I followed the
manual and installed a second MacPorts copy on my iMac, this time
under "/opt/local/tux4kids".

My question is how people make this simple to manage.   Is there an
established way to set up aliases, paths, etc? I want to be sure that
if I type "sudo port", I run the default macports copy, and have a
function or alias (say "sudo tuxport") that gives me "port" from my
non-default installation.

Thanks for any advice,

David Bruce

From jmr at macports.org  Tue Apr 21 08:23:13 2009
From: jmr at macports.org (Joshua Root)
Date: Wed, 22 Apr 2009 01:23:13 +1000
Subject: can't read "configure.universal_ldflags": no such variable
In-Reply-To: <49EDE302.7040902@macports.org>
References: <6F1859E6-412B-4195-B936-FBC6CA96F2A0@macports.org>
	<49EDE302.7040902@macports.org>
Message-ID: <49EDE4E1.5030409@macports.org>

Joshua Root wrote:
> Ryan Schmidt wrote:
>> I am having trouble upgrading an increasing number of ports (for example
>> whois, glib2, python25). I'm only seeing this problem on one machine, as
>> far as I can tell, which is running Mac OS X 10.4.11 Intel, Xcode 2.5,
>> MacPorts 1.7.1. Any ideas? Is anyone else seeing this?
>>
>>
>> $ port -uxd upgrade whois
> ...
>> DEBUG: Using group file
>> /Users/rschmidt/macports/dports/_resources/port1.0/group/muniversal-1.0.tcl
> 
> Your whois Portfile is obviously different to the one in the tree (which
> doesn't use muniversal), so it's going to be difficult for anyone else
> to debug.

Urgh, sorry, I misread; it's actually gettext failing. Still, the error
seems to occur in muniversal, and the line number doesn't seem to match
up with the version in the tree.

I can't reproduce the failure on a ppc Tiger machine with Xcode 2.5.

- Josh

From juanger at ciencias.unam.mx  Tue Apr 21 09:09:06 2009
From: juanger at ciencias.unam.mx (=?ISO-8859-1?Q?Juan_Germ=E1n_Casta=F1eda_Echevarria?=)
Date: Tue, 21 Apr 2009 11:09:06 -0500
Subject: GSoC: Accepted students announced
In-Reply-To: <49ECF226.6090802@macports.org>
References: <49ECF226.6090802@macports.org>
Message-ID: <2bad8a110904210909w2184c6c8rc717d5751517a752@mail.gmail.com>

Hi everyone,
I'm Juan Germ?n Casta?eda Echevarr?a (juanger), one of the selected students
in this year's Google Summer of Code.

My project consists in the design and implementation of a Cocoa application
using the MacPorts framework developed by Randall Woods and George Armah. I
want to create a simple and good looking interface to attract users who
don't like to use the terminal and for users that want a more visual way of
using MacPorts.

There are some GUI applications out there, but they are not fully Cocoa
based and also some members of the community don't like their GUI design.
That is why community feedback will be very important in almost all the
stages of the development and I'll be very happy to hear you all.

A little about myself: I'm a Mexican Computer Science student who currently
is preparing his thesis. I love Ruby, Rails and Cocoa and I'm a teacher
assistant at the National Autonomous University of Mexico. Last year I
applied for the MPWA but I wasn't selected and this year I want to give my
best to help the MacPorts project.

I made a sample application for this proposal (
http://juanger.googlepages.com/Porton-app.zip) and I'll begin to work out my
ideas from now.

Greetings.

My blog: http://xocoruby.blogspot.com
My projects: http://github.com/juanger

2009/4/20 Rainer M?ller <raimue at macports.org>

> Hi,
>
> in this years edition of Google Summer of Code, The MacPorts Project
> will mentor the following 2 students:
>
>  Juan Germ?n Casta?eda Echevarr?a:
>     GUI frontend using MacPorts.framework
>
>  Dmitry Gorbik:
>     Logging system
>
> Dmitry, Juan, welcome to our community!
> I would appreciate if you two could reply with a few words about your
> projects as introduction to the macports-dev list for those who are
> interested.
>
> More information about the proposals and the projects are available at
> <http://socghop.appspot.com/org/home/google/gsoc2009/macports>.
>
>
> In overall, we had less applicants than last year. It seems like we were
> not able to attract many students to work for us. If you have ideas what
> we could improve for a possible next year, let me know. For example, we
> did not get any proposal for the MPWA task while we got quite a few last
> year.
>
> Also, we would have gotten another third slot from Google implementing a
> 'Scan for broken library dependencies'. But unfortunately, the student
> also got accepted for an internship at another company and decided to go
> there instead of doing GSoC. In lack of other high quality proposals we
> had to give this slot back to the general pool and therefore gave a
> student for another project a chance.
>
> Looking forward to this summer's work and its results,
> Rainer
>



-- 
Ash Mac durbatul?k, ash Mac gimbatul, ash Mac thrakatul?k agh burzum-ishi
krimpatul.
Juanger.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090421/f7bb4c7a/attachment.html>

From juanger at ciencias.unam.mx  Tue Apr 21 09:50:14 2009
From: juanger at ciencias.unam.mx (=?ISO-8859-1?Q?Juan_Germ=E1n_Casta=F1eda_Echevarria?=)
Date: Tue, 21 Apr 2009 11:50:14 -0500
Subject: GSoC: Accepted students announced
In-Reply-To: <C3956554-E75B-44BA-B670-8444F89AACA0@apple.com>
References: <49ECF226.6090802@macports.org>
	<2bad8a110904210909w2184c6c8rc717d5751517a752@mail.gmail.com>
	<C3956554-E75B-44BA-B670-8444F89AACA0@apple.com>
Message-ID: <2bad8a110904210950n2904b6d4w4cf879de45c4ba23@mail.gmail.com>

El 21 de abril de 2009 11:22, William Siegrist <wsiegrist at apple.com>escribi?:

> On Apr 21, 2009, at 9:09 AM, Juan Germ?n Casta?eda Echevarria wrote:
>
>
>> A little about myself: I'm a Mexican Computer Science student who
>> currently is preparing his thesis. I love Ruby, Rails and Cocoa and I'm a
>> teacher assistant at the National Autonomous University of Mexico. Last year
>> I applied for the MPWA but I wasn't selected and this year I want to give my
>> best to help the MacPorts project.
>>
>
>
> Since you mention both Ruby and Cocoa, you might want to look at the
> MacRuby project (especially HotCocoa). I'm not sure if its mature enough yet
> for this, but I think its worth at least keeping an eye on.
>
> http://www.macruby.org/
>
> -Bill


Virginia

The sample app is intel-Leopard, I can make it universal-Leopard in a blink,
but I used some new features that are only available in Leopard
(NSPredicateEditor, some NSString messages, etc). I'll try to make a Tiger
compatible version in the next days, sorry for that.

Bill
Yes, I've looked at it a lot of times, and I don't know if it is mature
enough, lambda functions and some other things aren't implemented yet. I
made two apps with RubyCocoa, which is more mature (but ruby 1.8 based
instead of 1.9 as MacRuby) and I tried to port one of them (the one called
Lucecita http://github.com/juanger/lucecita) to MacRuby but I haven't been
able to do that yet because of some lacking functionality. Also I am willing
to improve my Obj-C with Cocoa and this is a very good opportunity :).

-- 
Ash Mac durbatul?k, ash Mac gimbatul, ash Mac thrakatul?k agh burzum-ishi
krimpatul.
Juanger. http://xocoruby.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090421/33f9bf5f/attachment-0001.html>

From dmitry at gorbik.ru  Tue Apr 21 23:06:39 2009
From: dmitry at gorbik.ru (Dmitry Gorbik)
Date: Wed, 22 Apr 2009 10:06:39 +0400
Subject: GSoC: Accepted students announced
In-Reply-To: <49ECF226.6090802@macports.org>
References: <49ECF226.6090802@macports.org>
Message-ID: <BC01FC73-0733-4ECF-81D6-ADF4EEFE7E36@gorbik.ru>

21.04.2009, ? 2:07, Rainer M?ller ???????(?):

> Hi,
>
> in this years edition of Google Summer of Code, The MacPorts Project
> will mentor the following 2 students:
>
>  Juan Germ?n Casta?eda Echevarr?a:
>     GUI frontend using MacPorts.framework
>
>  Dmitry Gorbik:
>     Logging system
>
> Dmitry, Juan, welcome to our community!
> I would appreciate if you two could reply with a few words about your
> projects as introduction to the macports-dev list for those who are
> interested.
>
> More information about the proposals and the projects are available at
> <http://socghop.appspot.com/org/home/google/gsoc2009/macports>.
>
>
> In overall, we had less applicants than last year. It seems like we  
> were
> not able to attract many students to work for us. If you have ideas  
> what
> we could improve for a possible next year, let me know. For example,  
> we
> did not get any proposal for the MPWA task while we got quite a few  
> last
> year.
>
> Also, we would have gotten another third slot from Google  
> implementing a
> 'Scan for broken library dependencies'. But unfortunately, the student
> also got accepted for an internship at another company and decided  
> to go
> there instead of doing GSoC. In lack of other high quality proposals  
> we
> had to give this slot back to the general pool and therefore gave a
> student for another project a chance.
>
> Looking forward to this summer's work and its results,
> Rainer

Hello!

My name is Dmitry. I am a student of Moscow State University (Russia),  
department of computational mathematics and cybernetics. I have been  
using mac for one year, before i used freebsd for 9 years. So this  
project is very important for me and I am glad to participate this  
year for MacPorts.

Logging is very vital feauture. Tracking all changes will help port  
mantainers find and correct bugs. GUI will be working with logs as  
well, so I suppose I will cooperate with Juan after the work is done.

If you have any questions about me or my project please mail me.

Gorbik Dmitry . Enlightened . dmitry at gorbik.ru









-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090422/f3c386b8/attachment.html>

From raimue at macports.org  Wed Apr 22 00:11:58 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Wed, 22 Apr 2009 09:11:58 +0200
Subject: Setting up multiple MacPorts copies on one machine
In-Reply-To: <9a3504f50904210821n2d733d0ta2199b8d6aba1156@mail.gmail.com>
References: <9a3504f50904210821n2d733d0ta2199b8d6aba1156@mail.gmail.com>
Message-ID: <49EEC33E.8000905@macports.org>

David Bruce wrote:
> My question is how people make this simple to manage.   Is there an
> established way to set up aliases, paths, etc? I want to be sure that
> if I type "sudo port", I run the default macports copy, and have a
> function or alias (say "sudo tuxport") that gives me "port" from my
> non-default installation.

To be really sure, just use the full path to the port binary. Otherwise
a alias should do fine, but note that shell aliases will not work with
sudo. You would have to create a symlink.

Rainer

From blb at macports.org  Wed Apr 22 01:31:08 2009
From: blb at macports.org (Bryan Blackburn)
Date: Wed, 22 Apr 2009 02:31:08 -0600
Subject: Setting up multiple MacPorts copies on one machine
In-Reply-To: <49EEC33E.8000905@macports.org>
References: <9a3504f50904210821n2d733d0ta2199b8d6aba1156@mail.gmail.com>
	<49EEC33E.8000905@macports.org>
Message-ID: <20090422083108.GJ2187@ninagal.withay.com>

On Wed, Apr 22, 2009 at 09:11:58AM +0200, Rainer M?ller said:
> David Bruce wrote:
> > My question is how people make this simple to manage.   Is there an
> > established way to set up aliases, paths, etc? I want to be sure that
> > if I type "sudo port", I run the default macports copy, and have a
> > function or alias (say "sudo tuxport") that gives me "port" from my
> > non-default installation.
> 
> To be really sure, just use the full path to the port binary. Otherwise
> a alias should do fine, but note that shell aliases will not work with
> sudo. You would have to create a symlink.

What I do is use aliases for those installs which are owned by me, and
basically work like:


basepath="/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/X11/bin"
alias port-1.7="/usr/bin/env PATH=/Users/blb/MacPorts/mp-1.7/bin:${basepath} port"
alias port-test="/usr/bin/env PATH=/Users/blb/MacPorts/mp-test/bin:${basepath} port"
...
unset basepath


This way PATH does not even know about any other installs; note that by
default my PATH has the location of my primary install which is root-owned.

For those which are root-owned, I use a shell script wrapper around the
alias idea, and adding $*.

Using the actual software installed by port into these various alternate
locations is left as an exercise.

Bryan


> 
> Rainer

From kimuraw at macports.org  Wed Apr 22 06:00:51 2009
From: kimuraw at macports.org (kimura wataru)
Date: Wed, 22 Apr 2009 22:00:51 +0900
Subject: ruby_select experimental implementation
Message-ID: <20090422220051485505.e38ce4e0@macports.org>

Hi,

I write experimental ruby_select for ruby186 and ruby18.

  http://trac.macports.org/browser/users/kimuraw/ruby_select

== install destinations

* different name for ruby bundled commands and libraries 
* share library and document directory for additional libraries

this allows to activate both of ruby186 and ruby18.


 dir,file       1.8.6(ruby186)             1.8.7(ruby18) 
------------------------------------------------------------
bin/ruby        bin/ruby186                bin/ruby18 
bin/irb         bin/irb186                 bin/irb18 
  :
libdir          lib/ruby/1.8.6/            lib/ruby/1.8.7/ 
sitedir         lib/ruby/site_ruby/1.8/    (share) 
vendordir       lib/ruby/vendor_ruby/1.8/  (share) 
libruby.so      libruby186.dylib           libruby18.dylib 
ri sysdir       share/ri/1.8/system1.8.6/  share/ri/1.8/system1.8.7/ 
ri sitedir      share/ri/1.8/site/         (share) 
------------------------------------------------------------

macports' vendor-specific.rb and site-specific.rb are moved
to lidir from vendordir and sitedir to avoid conflicts.

== ruby_select

sysutils/ruby_select uses same tool as port:python_select or port:gcc_selct.

  % sudo ruby_select ruby18
  Selecting version "ruby18" for ruby
  % ls -l /opt/local/bin/ruby
  lrwxr-xr-x  1 root  admin  21 Apr 18 21:03 /opt/local/bin/ruby@ -> /opt/local/bin/ruby18
  % sudo ruby_select ruby186
  Selecting version "ruby186" for ruby
  % ls -l /opt/local/bin/ruby
  lrwxr-xr-x  1 root  admin  22 Apr 18 21:06 /opt/local/bin/ruby@ -> /opt/local/bin/ruby186

the following files are targets of ruby_select.
* bin/ ruby, erb, irb, rdoc, ri, testrb
* lib/ libruby.dylib, libruby-static.a

ruby_select make symlinks the above files at post-activate. 
then, install ruby_select means existence of ${prefix}/bin/ruby (without suffix).
I expect this port become a meta port port:ruby.

== linking libruby

ruby_select introduce libruby.dylib. this file is a symbolic link for 
libruby186.dylib or libruby18.dylib. and, vendor-specific.rb changes 
LIBRUBYARG and so on.

  % ruby -rrbconfig -e 'p Config::CONFIG["LIBRUBYARG"]'        
  "-lruby18"
  % ruby -rvendor-specific -rrbconfig -e 'p Config::CONFIG["LIBRUBYARG"]'
  "-lruby"

so, port:rb-* links libruby.dylib and extension modules (.bundle)
use ruby_select-ed libruby.

this implementation is not enough. please tell me your thoughts.

-- 
kimura wataru

From blair at orcaware.com  Wed Apr 22 08:24:30 2009
From: blair at orcaware.com (Blair Zajac)
Date: Wed, 22 Apr 2009 08:24:30 -0700
Subject: Setting up multiple MacPorts copies on one machine
In-Reply-To: <20090422083108.GJ2187@ninagal.withay.com>
References: <9a3504f50904210821n2d733d0ta2199b8d6aba1156@mail.gmail.com>
	<49EEC33E.8000905@macports.org>
	<20090422083108.GJ2187@ninagal.withay.com>
Message-ID: <A3A3D1FA-2CD9-4AE3-851A-82B8B5A2B4C6@orcaware.com>


On Apr 22, 2009, at 1:31 AM, Bryan Blackburn wrote:

> On Wed, Apr 22, 2009 at 09:11:58AM +0200, Rainer M?ller said:
>> David Bruce wrote:
>>> My question is how people make this simple to manage.   Is there an
>>> established way to set up aliases, paths, etc? I want to be sure  
>>> that
>>> if I type "sudo port", I run the default macports copy, and have a
>>> function or alias (say "sudo tuxport") that gives me "port" from my
>>> non-default installation.
>>
>> To be really sure, just use the full path to the port binary.  
>> Otherwise
>> a alias should do fine, but note that shell aliases will not work  
>> with
>> sudo. You would have to create a symlink.
>
> What I do is use aliases for those installs which are owned by me, and
> basically work like:
>
>
> basepath="/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/X11/bin"
> alias port-1.7="/usr/bin/env PATH=/Users/blb/MacPorts/mp-1.7/bin:$ 
> {basepath} port"
> alias port-test="/usr/bin/env PATH=/Users/blb/MacPorts/mp-test/bin:$ 
> {basepath} port"
> ...
> unset basepath
>
>
> This way PATH does not even know about any other installs; note that  
> by
> default my PATH has the location of my primary install which is root- 
> owned.
>
> For those which are root-owned, I use a shell script wrapper around  
> the
> alias idea, and adding $*.
>
> Using the actual software installed by port into these various  
> alternate
> locations is left as an exercise.

I have a file I keep in the MacPorts install I just source:

bash-3.2# cat /opt/local-development/source.sh
export PATH=/opt/local-development/bin:/usr/bin:/usr/bin/cyrus:/usr/ 
X11/bin:/usr/X11R6/bin:/bin:/usr/sbin:/sbin:/etc:/usr/local/bin

Blair

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



From alakazam at macports.org  Wed Apr 22 12:10:00 2009
From: alakazam at macports.org (Olivier Le Floch)
Date: Wed, 22 Apr 2009 21:10:00 +0200
Subject: Fwd: [spam probable] [50018] php5-eaccelerator Lint Report
References: <20090422143911.640EA2807E@relay11.apple.com>
Message-ID: <4E5CFE7F-0879-4DD3-BDF2-932DFACDB7B5@macports.org>

Is the server's port command's code up to date ?

I think r49688 should make port lint recognize the top level php  
category.

Begin forwarded message:

> From: noreply at macports.org
> Date: 22 avril 2009 16:39:11 HAEC
> To: alakazam at macports.org, alakazam at macports.org
> Subject: [spam probable] [50018] php5-eaccelerator Lint Report
>
> Portfile: php5-eaccelerator
>
>
> Error: Unknown category: php


From wsiegrist at apple.com  Wed Apr 22 13:02:24 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Wed, 22 Apr 2009 13:02:24 -0700
Subject: [spam probable] [50018] php5-eaccelerator Lint Report
In-Reply-To: <4E5CFE7F-0879-4DD3-BDF2-932DFACDB7B5@macports.org>
References: <20090422143911.640EA2807E@relay11.apple.com>
	<4E5CFE7F-0879-4DD3-BDF2-932DFACDB7B5@macports.org>
Message-ID: <88FD089C-05E7-4D34-8BC0-8E26B853772E@apple.com>

On Apr 22, 2009, at 12:10 PM, Olivier Le Floch wrote:

> Is the server's port command's code up to date ?
>
> I think r49688 should make port lint recognize the top level php  
> category.
>
> Begin forwarded message:
>
>> From: noreply at macports.org
>> Date: 22 avril 2009 16:39:11 HAEC
>> To: alakazam at macports.org, alakazam at macports.org
>> Subject: [spam probable] [50018] php5-eaccelerator Lint Report
>>
>> Portfile: php5-eaccelerator
>>
>>
>> Error: Unknown category: php
>
>


No, I do not upgrade the macports install on the server with every  
base commit. If portlint.tcl needs to be updated, someone needs to  
give me a heads up.

The servers are now running r50021.

-Bill




From raimue at macports.org  Wed Apr 22 14:13:33 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Wed, 22 Apr 2009 23:13:33 +0200
Subject: Fwd: [spam probable] [50018] php5-eaccelerator Lint Report
In-Reply-To: <4E5CFE7F-0879-4DD3-BDF2-932DFACDB7B5@macports.org>
References: <20090422143911.640EA2807E@relay11.apple.com>
	<4E5CFE7F-0879-4DD3-BDF2-932DFACDB7B5@macports.org>
Message-ID: <49EF887D.9070209@macports.org>

Olivier Le Floch wrote:
> Is the server's port command's code up to date ?
> 
> I think r49688 should make port lint recognize the top level php  
> category.
> 
> Begin forwarded message:
> 
>> From: noreply at macports.org
>> Date: 22 avril 2009 16:39:11 HAEC
>> To: alakazam at macports.org, alakazam at macports.org
>> Subject: [spam probable] [50018] php5-eaccelerator Lint Report
>>
>> Portfile: php5-eaccelerator
>>
>>
>> Error: Unknown category: php

To chime in here, why are we validating the secondary categories at all?

The primary category is the one listed first, which name has to match
the parent directory of the port directory. But for the secondary
categories there is no need to limit them to a specific set in my
opinion. I would rather say they are like those web 2.0 tags, which make
it easier to find ports and should be chosen freely.

Thoughts?

Rainer

From raimue at macports.org  Wed Apr 22 14:38:02 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Wed, 22 Apr 2009 23:38:02 +0200
Subject: Fwd: [spam probable] [50018] php5-eaccelerator Lint Report
In-Reply-To: <49EF887D.9070209@macports.org>
References: <20090422143911.640EA2807E@relay11.apple.com>	<4E5CFE7F-0879-4DD3-BDF2-932DFACDB7B5@macports.org>
	<49EF887D.9070209@macports.org>
Message-ID: <49EF8E3A.7020605@macports.org>

Rainer M?ller wrote:
> Olivier Le Floch wrote:
>> Is the server's port command's code up to date ?
>>
>> I think r49688 should make port lint recognize the top level php  
>> category.
>>
>> Begin forwarded message:
>>
>>> From: noreply at macports.org
>>> Date: 22 avril 2009 16:39:11 HAEC
>>> To: alakazam at macports.org, alakazam at macports.org
>>> Subject: [spam probable] [50018] php5-eaccelerator Lint Report
>>>
>>> Portfile: php5-eaccelerator
>>>
>>>
>>> Error: Unknown category: php
> 
> To chime in here, why are we validating the secondary categories at all?

Sorry, I was wrong here as this was an error about a primary category.

We are only validating primary categories, secondary categories can
already be chosen freely.

But we check the primary category against a hardcoded list of valid
categories and we also check the parent directory of the port directory.
To pass both tests, this list will always have to reflect the current
existing category directories in the repository. Therefore it is quite
useless.

Rainer

From raimue at macports.org  Wed Apr 22 15:02:30 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 23 Apr 2009 00:02:30 +0200
Subject: ruby_select experimental implementation
In-Reply-To: <20090422220051485505.e38ce4e0@macports.org>
References: <20090422220051485505.e38ce4e0@macports.org>
Message-ID: <49EF93F6.2090108@macports.org>

kimura wataru wrote:
> I write experimental ruby_select for ruby186 and ruby18.
> 
>   http://trac.macports.org/browser/users/kimuraw/ruby_select

Will ruby19 be moved to ruby? Or what will happen to the existing ruby
port at all?

I would like to avoid the situation we created with python, where we
have only the versioned ports. Currently if you install many ports
dependencies will pull in all of python24, python25 and python26.
Something like this should be avoided. And maybe there should also be a
"default" python version.

I am not against providing multiple versions and allow switching, but we
should avoid creating a dependency hell where multiple available
versions are pulled in unecessary as happened for python.

> == ruby_select
> 
> sysutils/ruby_select uses same tool as port:python_select or port:gcc_selct.
>[...]

The select files should be part of the corresponding ports and not be in
ruby_select as it is for python. This avoids selection of a
non-installed ruby version.

You can use the select port group at
_resources/port1.0/group/select-1.0.tcl to set this up easily.

> == linking libruby
> 
> ruby_select introduce libruby.dylib. this file is a symbolic link for 
> libruby186.dylib or libruby18.dylib. and, vendor-specific.rb changes 
> LIBRUBYARG and so on.
> 
>   % ruby -rrbconfig -e 'p Config::CONFIG["LIBRUBYARG"]'        
>   "-lruby18"
>   % ruby -rvendor-specific -rrbconfig -e 'p Config::CONFIG["LIBRUBYARG"]'
>   "-lruby"
> 
> so, port:rb-* links libruby.dylib and extension modules (.bundle)
> use ruby_select-ed libruby.

This sounds like you will not be able to install modules for a specific
ruby version while you can install multiple ruby versions at the same
time. Is this correct? If so, where is the sense in that?

Also, switching ruby around with ruby_select after installing some rb-*
ports could probably break these, right?

Rainer

From raimue at macports.org  Wed Apr 22 15:04:09 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Thu, 23 Apr 2009 00:04:09 +0200
Subject: NewHelpSystem & man pages
In-Reply-To: <20090419150253.GA24363@ruderich.org>
References: <fc.004c4c5811efa0e7004c4c5811efa0e7.11f3c16d@biola.edu>	<49DFAF39.2070304@macports.org>
	<20090419150253.GA24363@ruderich.org>
Message-ID: <49EF9459.5000702@macports.org>

Simon Ruderich wrote:
> The only problematic man page is portfile.7 as it is directly
> wired into the guide. I would like to remove it (or generate it
> through DocBook) and instead install the guide in
> /opt/local/share/doc/port/ so the user can access it.

Although we could install the guide locally, it would make updates only
possible with new version. If there is really need to distribute a local
version of the guide I would make it a port. But this would also mean we
would need some sort of releases for the guide. Currently, everything is
released immediately as commits happen and I don't

> We should really remove all duplication and move documentation
> either to base/doc or doc, but not in both places.

base/doc is what ships with base, doc (resp. doc-new) contains
additional documentation. If we would change this, building base would
also require doc. And moving the guide to base/doc would not be good
either, as it is developed independently (e.g. no need to branch it).

Rainer

From ryandesign at macports.org  Wed Apr 22 19:21:36 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 22 Apr 2009 21:21:36 -0500
Subject: ruby_select experimental implementation
In-Reply-To: <49EF93F6.2090108@macports.org>
References: <20090422220051485505.e38ce4e0@macports.org>
	<49EF93F6.2090108@macports.org>
Message-ID: <4EE5C845-8C40-4C9B-8463-886FA965E154@macports.org>


On Apr 22, 2009, at 17:02, Rainer M?ller wrote:

> kimura wataru wrote:
>
>> I write experimental ruby_select for ruby186 and ruby18.
>>
>>   http://trac.macports.org/browser/users/kimuraw/ruby_select
>
> Will ruby19 be moved to ruby? Or what will happen to the existing ruby
> port at all?
>
> I would like to avoid the situation we created with python, where we
> have only the versioned ports. Currently if you install many ports
> dependencies will pull in all of python24, python25 and python26.
> Something like this should be avoided. And maybe there should also  
> be a
> "default" python version.

I don't think I agree. There isn't a port sqlite; there's sqlite2 and  
sqlite3. We used to have a port mysql but it was decided to remove it  
to avoid confusion and allow the user to select among mysql3, mysql4  
and mysql5. There isn't a port php; there's php4 and php5.  There  
isn't a port postgresql; there's postgresql7, 80, 81, 82, 83. There  
isn't a port db; there's db3, 41, 42, 43, 44, 45, 46, 47. There isn't  
a port gcc; there's gcc33, 34, 40, 41, 42, 43, 44, 45.


> I am not against providing multiple versions and allow switching,  
> but we
> should avoid creating a dependency hell where multiple available
> versions are pulled in unecessary as happened for python.

The only thing that comes to my mind is to update the dependencies of  
ports, when they're found to be out of date. If you find a port  
depending on python24 or php4 or db41 or gcc40 etc. then try to  
update it to the latest version. Of course sometimes this can't be  
done. For example pdftk cannot currently be compiled with gcc 4.3 or  
later so it uses gcc42.



From ryandesign at macports.org  Wed Apr 22 20:09:22 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 22 Apr 2009 22:09:22 -0500
Subject: Rationale behind naming "dot d" (.d) directories
Message-ID: <99C8600D-A0CD-4193-9084-5C80DB5E4A23@macports.org>

Does anyone know the history behind the ".d" naming convention on  
some directories?

For example, /etc/rc.d or ${prefix}/etc/bash_completion.d. I seem to  
understand how these directories are used, but what does the ".d" mean?


From frstan at bellsouth.net  Wed Apr 22 20:29:51 2009
From: frstan at bellsouth.net (William Davis)
Date: Wed, 22 Apr 2009 23:29:51 -0400
Subject: Rationale behind naming "dot d" (.d) directories
In-Reply-To: <99C8600D-A0CD-4193-9084-5C80DB5E4A23@macports.org>
References: <99C8600D-A0CD-4193-9084-5C80DB5E4A23@macports.org>
Message-ID: <486185C5-A437-4D6D-8592-8F39A7B335BB@bellsouth.net>


On Apr 22, 2009, at 11:09 PM, Ryan Schmidt wrote:

> Does anyone know the history behind the ".d" naming convention on  
> some directories?
>
> For example, /etc/rc.d or ${prefix}/etc/bash_completion.d. I seem to  
> understand how these directories are used, but what does the ".d"  
> mean?


simplistic answer:  .d == directory
;)

William Davis
frstanATbellsouthDOTnet
Mac OS X.5.6 Darwin 9.5.0
XQuartz 2.3.3_rc5 (xorg-server 1.4.2-apple41)
Mac Mini Intel Duo @ 1.86 GHz

Mundus vult decepi, ego non


From ryandesign at macports.org  Wed Apr 22 21:12:37 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 22 Apr 2009 23:12:37 -0500
Subject: [spam probable] [50018] php5-eaccelerator Lint Report
In-Reply-To: <49EF8E3A.7020605@macports.org>
References: <20090422143911.640EA2807E@relay11.apple.com>	<4E5CFE7F-0879-4DD3-BDF2-932DFACDB7B5@macports.org>
	<49EF887D.9070209@macports.org> <49EF8E3A.7020605@macports.org>
Message-ID: <95FD71CD-DB42-4125-813B-DB0EF230BA42@macports.org>

On Apr 22, 2009, at 16:38, Rainer M?ller wrote:

> Rainer M?ller wrote:
>
>> Olivier Le Floch wrote:
>>
>>> Begin forwarded message:
>>>
>>>> Error: Unknown category: php
>>
>> To chime in here, why are we validating the secondary categories  
>> at all?
>
> Sorry, I was wrong here as this was an error about a primary category.
>
> We are only validating primary categories, secondary categories can
> already be chosen freely.

Right. In this revision, the port was moved to the newly-created php  
primary category.


> But we check the primary category against a hardcoded list of valid
> categories and we also check the parent directory of the port  
> directory.
> To pass both tests, this list will always have to reflect the current
> existing category directories in the repository. Therefore it is quite
> useless.

Which part is useless? The separately-maintained list of valid  
categories in portlint.tcl? I've thought that too...

Then again, you might be developing a port in a separate directory,  
say /Users/yourname/someport. In that case, port lint would complain  
that "yourname" is not the same as the primary category declared in  
the port, which is true, and you'd realize why lint is saying that  
and ignore it. If we removed the list of valid categories from  
portlint.tcl, then port lint wouldn't be able to detect if you had in  
fact made a typo in your primary category name as listed in the  
portfile. However, one could argue that this is a rare case and that  
we don't need to handle it. It would certainly simplify things to  
remove the list of categories from portlint.tcl, and leave it to just  
check that the category directory name matches the primary category  
declared in the portfile.



From jkh at apple.com  Wed Apr 22 21:20:04 2009
From: jkh at apple.com (Jordan K. Hubbard)
Date: Wed, 22 Apr 2009 21:20:04 -0700
Subject: Rationale behind naming "dot d" (.d) directories
In-Reply-To: <99C8600D-A0CD-4193-9084-5C80DB5E4A23@macports.org>
References: <99C8600D-A0CD-4193-9084-5C80DB5E4A23@macports.org>
Message-ID: <E8304689-7AEF-43C6-94B8-2E5C1D0F65A1@apple.com>

The history was pretty simple.  When we had a file called /etc/foo,  
which we later to split into a directory full of individual one-entry- 
per-file records rather than the previous "all records in a single  
file", we would rename /etc/foo to /etc/foo.d to denote the switch.   
Don't forget, /etc/rc used to be a single file...

- Jordan

On Apr 22, 2009, at 8:09 PM, Ryan Schmidt wrote:

> Does anyone know the history behind the ".d" naming convention on  
> some directories?
>
> For example, /etc/rc.d or ${prefix}/etc/bash_completion.d. I seem to  
> understand how these directories are used, but what does the ".d"  
> mean?
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


From stechert at gmail.com  Wed Apr 22 21:41:12 2009
From: stechert at gmail.com (Andre Stechert)
Date: Wed, 22 Apr 2009 21:41:12 -0700
Subject: Rationale behind naming "dot d" (.d) directories
In-Reply-To: <E8304689-7AEF-43C6-94B8-2E5C1D0F65A1@apple.com>
References: <99C8600D-A0CD-4193-9084-5C80DB5E4A23@macports.org> 
	<E8304689-7AEF-43C6-94B8-2E5C1D0F65A1@apple.com>
Message-ID: <12a697af0904222141k5f371ed8r5518015e33bb194c@mail.gmail.com>

http://www.mewburn.net/luke/talks/auug-2003/

On Wed, Apr 22, 2009 at 9:20 PM, Jordan K. Hubbard <jkh at apple.com> wrote:
> The history was pretty simple. ?When we had a file called /etc/foo, which we
> later to split into a directory full of individual one-entry-per-file
> records rather than the previous "all records in a single file", we would
> rename /etc/foo to /etc/foo.d to denote the switch. ?Don't forget, /etc/rc
> used to be a single file...
>
> - Jordan
>
> On Apr 22, 2009, at 8:09 PM, Ryan Schmidt wrote:
>
>> Does anyone know the history behind the ".d" naming convention on some
>> directories?
>>
>> For example, /etc/rc.d or ${prefix}/etc/bash_completion.d. I seem to
>> understand how these directories are used, but what does the ".d" mean?
>>
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>

From ryandesign at macports.org  Wed Apr 22 22:33:55 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 23 Apr 2009 00:33:55 -0500
Subject: Rationale behind naming "dot d" (.d) directories
In-Reply-To: <E8304689-7AEF-43C6-94B8-2E5C1D0F65A1@apple.com>
References: <99C8600D-A0CD-4193-9084-5C80DB5E4A23@macports.org>
	<E8304689-7AEF-43C6-94B8-2E5C1D0F65A1@apple.com>
Message-ID: <21201C2B-F0A1-4AD2-8A72-F0C0426E3BB7@macports.org>


On Apr 22, 2009, at 23:20, Jordan K. Hubbard wrote:

> On Apr 22, 2009, at 8:09 PM, Ryan Schmidt wrote:
>
>> Does anyone know the history behind the ".d" naming convention on  
>> some directories?
>>
>> For example, /etc/rc.d or ${prefix}/etc/bash_completion.d. I seem  
>> to understand how these directories are used, but what does the  
>> ".d" mean?
>
> The history was pretty simple.  When we had a file called /etc/foo,  
> which we later to split into a directory full of individual one- 
> entry-per-file records rather than the previous "all records in a  
> single file", we would rename /etc/foo to /etc/foo.d to denote the  
> switch.

Thanks for the explanation. That makes sense, as it avoids the  
problems of an object with a given name changing from a file to a  
directory from one release to the next.

The reason I ask is for a change I'm working on for the php5  
extension ports. Currently, ports like php5-memcache just print a  
message telling the user to add these lines to their php.ini:

extension_dir=/opt/local/lib/php/extensions/no-debug-non-zts-20060613
extension=memcache.so

But php can be configured to look for additional ini files in a  
certain directory. So I would like to modify the php5 port to do  
this, and then modify ports like php5-memcache to just install a file  
like e.g. memcache.ini which contains these lines. Then the extension  
will automatically be loaded and the user won't have to do it manually.

Currently, the php.ini is in /opt/local/etc. This is a little out in  
the open and I would like to move it into a directory of its own,  
probably named for the port, so, say, /opt/local/etc/php5. This would  
also be a step toward allowing php4 and php5 (and a hypothetical  
future php6) to be installed simultaneously which is desirable.

Now I need a directory in which php5 extension ports will install  
their small additional .ini files. I don't think it should be the  
same /opt/local/etc/php5 directory because php is set up to first  
look for its one true php.ini and then load all the additional ini  
files in a directory; this might cause php.ini to be parsed twice,  
which is at best wasteful and at worst could cause problems. Order  
may also be important so I would like to load php.ini first, then the  
other files. So for the directory name, should I use /opt/local/etc/ 
php5.d? /opt/local/etc/php5/php.d? Or forget about the whole .d thing  
and make it /opt/local/etc/php5/extra (which would be similar to /opt/ 
local/apache2/conf/extra)? Other suggestions?


> Don't forget, /etc/rc used to be a single file...

And indeed I wasn't looking: it *is* a single file, even on Leopard.



From ryandesign at macports.org  Wed Apr 22 22:43:22 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 23 Apr 2009 00:43:22 -0500
Subject: Rationale behind naming "dot d" (.d) directories
In-Reply-To: <12a697af0904222141k5f371ed8r5518015e33bb194c@mail.gmail.com>
References: <99C8600D-A0CD-4193-9084-5C80DB5E4A23@macports.org>
	<E8304689-7AEF-43C6-94B8-2E5C1D0F65A1@apple.com>
	<12a697af0904222141k5f371ed8r5518015e33bb194c@mail.gmail.com>
Message-ID: <5BF8A9D9-C563-4BD0-AD61-30C417D7BA76@macports.org>


On Apr 22, 2009, at 23:41, Andre Stechert wrote:

>> On Apr 22, 2009, at 8:09 PM, Ryan Schmidt wrote:
>>
>>> Does anyone know the history behind the ".d" naming convention on  
>>> some
>>> directories?
>>>

> http://www.mewburn.net/luke/talks/auug-2003/

Thanks. I've skimmed that twice, but I don't see a part where it  
explains why the directory has a ".d" suffix on its name. Is it there  
and I'm missing it?



From jkh at apple.com  Wed Apr 22 22:46:58 2009
From: jkh at apple.com (Jordan K. Hubbard)
Date: Wed, 22 Apr 2009 22:46:58 -0700
Subject: Rationale behind naming "dot d" (.d) directories
In-Reply-To: <21201C2B-F0A1-4AD2-8A72-F0C0426E3BB7@macports.org>
References: <99C8600D-A0CD-4193-9084-5C80DB5E4A23@macports.org>
	<E8304689-7AEF-43C6-94B8-2E5C1D0F65A1@apple.com>
	<21201C2B-F0A1-4AD2-8A72-F0C0426E3BB7@macports.org>
Message-ID: <2ECA938A-A2DE-4CF9-8186-C306D584789E@apple.com>


On Apr 22, 2009, at 10:33 PM, Ryan Schmidt wrote:

> The reason I ask is for a change I'm working on for the php5  
> extension ports. Currently, ports like php5-memcache just print a  
> message telling the user to add these lines to their php.ini:
>
> extension_dir=/opt/local/lib/php/extensions/no-debug-non-zts-20060613
> extension=memcache.so
>
> But php can be configured to look for additional ini files in a  
> certain directory. So I would like to modify the php5 port to do  
> this, and then modify ports like php5-memcache to just install a  
> file like e.g. memcache.ini which contains these lines. Then the  
> extension will automatically be loaded and the user won't have to do  
> it manually.

Sounds laudable, just as long as you also figure out how to undo this  
when the php port is removed.  Nothing worse than something which  
installs itself with side-effects yet fails to remove those side- 
effects when it's removed / upgraded away. :)

> Currently, the php.ini is in /opt/local/etc. This is a little out in  
> the open and I would like to move it into a directory of its own,  
> probably named for the port, so, say, /opt/local/etc/php5. This  
> would also be a step toward allowing php4 and php5 (and a  
> hypothetical future php6) to be installed simultaneously which is  
> desirable.

Sounds entirely reasonable.

> Now I need a directory in which php5 extension ports will install  
> their small additional .ini files. I don't think it should be the  
> same /opt/local/etc/php5 directory because php is set up to first  
> look for its one true php.ini and then load all the additional ini  
> files in a directory; this might cause php.ini to be parsed twice,  
> which is at best wasteful and at worst could cause problems.

How about having a "system" path of ${prefix}/etc/php5 and ${prefix}/ 
var/db/php5 for the additional bits?

>> Don't forget, /etc/rc used to be a single file...
>
> And indeed I wasn't looking: it *is* a single file, even on Leopard.

Sorry, brain-fart. I meant the /usr/local/etc/rc file - you're correct  
that /etc/rc remains still too historical to be replaced, though it  
certainly should be.

- Jordan


From ryandesign at macports.org  Wed Apr 22 23:25:31 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 23 Apr 2009 01:25:31 -0500
Subject: Rationale behind naming "dot d" (.d) directories
In-Reply-To: <2ECA938A-A2DE-4CF9-8186-C306D584789E@apple.com>
References: <99C8600D-A0CD-4193-9084-5C80DB5E4A23@macports.org>
	<E8304689-7AEF-43C6-94B8-2E5C1D0F65A1@apple.com>
	<21201C2B-F0A1-4AD2-8A72-F0C0426E3BB7@macports.org>
	<2ECA938A-A2DE-4CF9-8186-C306D584789E@apple.com>
Message-ID: <2D06CC7C-79D0-4C7B-99B2-E8FD772C1136@macports.org>

On Apr 23, 2009, at 00:46, Jordan K. Hubbard wrote:

> On Apr 22, 2009, at 10:33 PM, Ryan Schmidt wrote:
>
>> The reason I ask is for a change I'm working on for the php5  
>> extension ports. Currently, ports like php5-memcache just print a  
>> message telling the user to add these lines to their php.ini:
>>
>> extension_dir=/opt/local/lib/php/extensions/no-debug-non-zts-20060613
>> extension=memcache.so
>>
>> But php can be configured to look for additional ini files in a  
>> certain directory. So I would like to modify the php5 port to do  
>> this, and then modify ports like php5-memcache to just install a  
>> file like e.g. memcache.ini which contains these lines. Then the  
>> extension will automatically be loaded and the user won't have to  
>> do it manually.
>
> Sounds laudable, just as long as you also figure out how to undo  
> this when the php port is removed.  Nothing worse than something  
> which installs itself with side-effects yet fails to remove those  
> side-effects when it's removed / upgraded away. :)

There shouldn't be side-effects. All files will be registered to the  
corresponding ports, and will be uninstalled by MacPorts if the ports  
are uninstalled. So e.g. uninstalling php5-memcache would remove  
memcache.ini.


>> Currently, the php.ini is in /opt/local/etc. This is a little out  
>> in the open and I would like to move it into a directory of its  
>> own, probably named for the port, so, say, /opt/local/etc/php5.  
>> This would also be a step toward allowing php4 and php5 (and a  
>> hypothetical future php6) to be installed simultaneously which is  
>> desirable.
>
> Sounds entirely reasonable.
>
>> Now I need a directory in which php5 extension ports will install  
>> their small additional .ini files. I don't think it should be the  
>> same /opt/local/etc/php5 directory because php is set up to first  
>> look for its one true php.ini and then load all the additional ini  
>> files in a directory; this might cause php.ini to be parsed twice,  
>> which is at best wasteful and at worst could cause problems.
>
> How about having a "system" path of ${prefix}/etc/php5 and $ 
> {prefix}/var/db/php5 for the additional bits?

"man porthier" says ${prefix}/var/db is for "misc. automatically  
generated system-specific database files". These would only be small  
text files containing configuration information, so they're not  
databases, so I don't know if this would be the right place... though  
getting them out of ${prefix}/etc isn't entirely a bad idea, since I  
don't want users modifying them. Would a place under ${prefix}/share  
be something to consider? They are "architecture-independent  
files"... Then again, though the user shouldn't modify the .ini files  
we install, the user may want to add her own .ini files.



From jkh at apple.com  Wed Apr 22 23:38:12 2009
From: jkh at apple.com (Jordan K. Hubbard)
Date: Wed, 22 Apr 2009 23:38:12 -0700
Subject: Rationale behind naming "dot d" (.d) directories
In-Reply-To: <2D06CC7C-79D0-4C7B-99B2-E8FD772C1136@macports.org>
References: <99C8600D-A0CD-4193-9084-5C80DB5E4A23@macports.org>
	<E8304689-7AEF-43C6-94B8-2E5C1D0F65A1@apple.com>
	<21201C2B-F0A1-4AD2-8A72-F0C0426E3BB7@macports.org>
	<2ECA938A-A2DE-4CF9-8186-C306D584789E@apple.com>
	<2D06CC7C-79D0-4C7B-99B2-E8FD772C1136@macports.org>
Message-ID: <66550488-AAD8-4527-8707-4F8C4A04C0E9@apple.com>

I agree that ${prefix}/var/db is far from ideal, but at least it's  
documented as mutable in hier(7).  The same cannot be said for $ 
{prefix}/share, even though it might make more sense from a config  
file vs "database" point of view.  Think of "database" in the highly  
abstract sense, if it helps to reduce the ringing in your head. :-)

- Jordan

On Apr 22, 2009, at 11:25 PM, Ryan Schmidt wrote:

> "man porthier" says ${prefix}/var/db is for "misc. automatically  
> generated system-specific database files". These would only be small  
> text files containing configuration information, so they're not  
> databases, so I don't know if this would be the right place...  
> though getting them out of ${prefix}/etc isn't entirely a bad idea,  
> since I don't want users modifying them. Would a place under $ 
> {prefix}/share be something to consider? They are "architecture- 
> independent files"... Then again, though the user shouldn't modify  
> the .ini files we install, the user may want to add her own .ini  
> files.


From anand at buddhdev.name  Thu Apr 23 06:30:07 2009
From: anand at buddhdev.name (Anand Buddhdev)
Date: Thu, 23 Apr 2009 15:30:07 +0200
Subject: Outstanding ticket: NSD port update
Message-ID: <557f33430904230630p17283aa5uf2b1a666b8138b06@mail.gmail.com>

Hello developers,

I created this ticket several days ago, but after the initial response,
nothing seems to have been done with it. If it is okay, could someone please
merge it into the ports tree?

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

Regards,

Anand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090423/e46f1f58/attachment.html>

From jeremyhu at macports.org  Thu Apr 23 10:22:59 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Thu, 23 Apr 2009 10:22:59 -0700
Subject: [50047] trunk/dports/x11/rox-filer/Portfile
In-Reply-To: <20090423120538.0BD201638075@beta.macosforge.org>
References: <20090423120538.0BD201638075@beta.macosforge.org>
Message-ID: <F14D7788-47F3-415A-AFEF-244C7525E44B@macports.org>


On Apr 23, 2009, at 05:05, afb at macports.org wrote:

> Revision: 50047
>          http://trac.macports.org/changeset/50047
> Author:   afb at macports.org
> Date:     2009-04-23 05:05:35 -0700 (Thu, 23 Apr 2009)
> Log Message:
> -----------
> add explicit x11 dependencies (#19406)

gtk2 pulls these in already as long as they're using an x11 gtk2...  
and if they're using a native gtk2, they're equally screwed.



> Modified Paths:
> --------------
>    trunk/dports/x11/rox-filer/Portfile
>
> Modified: trunk/dports/x11/rox-filer/Portfile
> ===================================================================
> --- trunk/dports/x11/rox-filer/Portfile	2009-04-23 10:53:04 UTC (rev  
> 50046)
> +++ trunk/dports/x11/rox-filer/Portfile	2009-04-23 12:05:35 UTC (rev  
> 50047)
> @@ -20,7 +20,8 @@
>                 sha1 7eec68a106a2605b2733025e44d890961b52ea1e \
>                 rmd160 9f0aecde32fdd9ecc39efe80bd037b95850bb38c
>
> -depends_lib     port:shared-mime-info port:libxml2 port:glib2  
> port:gtk2
> +depends_lib     port:shared-mime-info port:libxml2 port:glib2  
> port:gtk2 \
> +                port:xorg-libX11 port:xorg-libsm
>
> use_configure		no
> universal_variant	no
> _______________________________________________
> macports-changes mailing list
> macports-changes at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes


From afb at macports.org  Thu Apr 23 10:47:27 2009
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Thu, 23 Apr 2009 19:47:27 +0200
Subject: [50047] trunk/dports/x11/rox-filer/Portfile
In-Reply-To: <F14D7788-47F3-415A-AFEF-244C7525E44B@macports.org>
References: <20090423120538.0BD201638075@beta.macosforge.org>
	<F14D7788-47F3-415A-AFEF-244C7525E44B@macports.org>
Message-ID: <82ADA340-8FBA-4CCC-84A3-CACEF53FE325@macports.org>

Jeremy Huddleston wrote:

>> add explicit x11 dependencies (#19406)
>
> gtk2 pulls these in already as long as they're using an x11 gtk2...  
> and if they're using a native gtk2, they're equally screwed.

User said he was "missing the X development libraries,
which aren't there as dependancies" (and they weren't)

Since rox-filer uses both X11 and GTK+, it was fair to
assume that it would list both as direct dependencies ?

So just having a gtk2 +quartz would not be enough, nope.
afaik, "ROX" even means "RISC OS on X" (i.e. as in X11)

--anders


From jeremyhu at macports.org  Thu Apr 23 14:22:35 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Thu, 23 Apr 2009 14:22:35 -0700
Subject: [50047] trunk/dports/x11/rox-filer/Portfile
In-Reply-To: <82ADA340-8FBA-4CCC-84A3-CACEF53FE325@macports.org>
References: <20090423120538.0BD201638075@beta.macosforge.org>
	<F14D7788-47F3-415A-AFEF-244C7525E44B@macports.org>
	<82ADA340-8FBA-4CCC-84A3-CACEF53FE325@macports.org>
Message-ID: <75606FA3-C184-4AB0-A150-584A311B8465@macports.org>


On Apr 23, 2009, at 10:47, Anders F Bj?rklund wrote:

> Jeremy Huddleston wrote:
>
>>> add explicit x11 dependencies (#19406)
>>
>> gtk2 pulls these in already as long as they're using an x11 gtk2...  
>> and if they're using a native gtk2, they're equally screwed.
>
> User said he was "missing the X development libraries,
> which aren't there as dependancies" (and they weren't)

Right, but my point is "why?"

He should have them since gtk2 depends on them.

> Since rox-filer uses both X11 and GTK+, it was fair to
> assume that it would list both as direct dependencies ?

Sure, do whatever you want, but I prefer not to be verbose when I can  
let other ports pull in the dependencies... but that's a style issue  
and not really the point here.

> So just having a gtk2 +quartz would not be enough, nope.
> afaik, "ROX" even means "RISC OS on X" (i.e. as in X11)

Right, which is my point.  If gtk2 didn't pull in the X11 libs, then  
that means that he's got a gtk2+quartz install... which means that ROX  
is not going to work for him because it needs gtk2 for x11.

So either the user had a +quartz gtk2 (in which case he can't use rox)  
or he has some other problem that adding the X11 dependencies to rox  
won't solve (because they're redundant).

It's also possible that he just hasn't done a 'sudo port -v upgrade'  
in a very long time and thus has an outdated gtk2 that uses the system  
X11 libs.



From afb at macports.org  Thu Apr 23 15:57:57 2009
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Fri, 24 Apr 2009 00:57:57 +0200
Subject: [50047] trunk/dports/x11/rox-filer/Portfile
In-Reply-To: <75606FA3-C184-4AB0-A150-584A311B8465@macports.org>
References: <20090423120538.0BD201638075@beta.macosforge.org>
	<F14D7788-47F3-415A-AFEF-244C7525E44B@macports.org>
	<82ADA340-8FBA-4CCC-84A3-CACEF53FE325@macports.org>
	<75606FA3-C184-4AB0-A150-584A311B8465@macports.org>
Message-ID: <B61440D8-2EC5-4940-8D8B-0165E6593052@macports.org>

Jeremy Huddleston wrote:

> Right, which is my point.  If gtk2 didn't pull in the X11 libs,  
> then that means that he's got a gtk2+quartz install... which means  
> that ROX is not going to work for him because it needs gtk2 for x11.


Suppose dependencies-with-variants would have allowed requiring "gtk2 
+x11" ?

> So either the user had a +quartz gtk2 (in which case he can't use  
> rox) or he has some other problem that adding the X11 dependencies  
> to rox won't solve (because they're redundant).

In order to use a non-system X11, the port needed the usual workaround:
configure.args-append --x-include=${prefix}/include --x-lib=${prefix}/ 
lib
Just wasn't obvious where to add them, when using Zero Install's -- 
compile.

And obviously they would be wrong, when using +system_x11 (another  
story)
But seems like it'll be able to pick up /usr/X11R6 anyway, due to it  
being
present in gtk2's pkg-config and it being the default. So should be  
good.

--anders


From jeremyhu at macports.org  Thu Apr 23 20:32:54 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Thu, 23 Apr 2009 20:32:54 -0700
Subject: [50047] trunk/dports/x11/rox-filer/Portfile
In-Reply-To: <B61440D8-2EC5-4940-8D8B-0165E6593052@macports.org>
References: <20090423120538.0BD201638075@beta.macosforge.org>
	<F14D7788-47F3-415A-AFEF-244C7525E44B@macports.org>
	<82ADA340-8FBA-4CCC-84A3-CACEF53FE325@macports.org>
	<75606FA3-C184-4AB0-A150-584A311B8465@macports.org>
	<B61440D8-2EC5-4940-8D8B-0165E6593052@macports.org>
Message-ID: <FAC6BC38-A9A7-4C3D-8399-43F2ED95EE67@macports.org>


On Apr 23, 2009, at 15:57, Anders F Bj?rklund wrote:

> Jeremy Huddleston wrote:
>
>> Right, which is my point.  If gtk2 didn't pull in the X11 libs,  
>> then that means that he's got a gtk2+quartz install... which means  
>> that ROX is not going to work for him because it needs gtk2 for x11.
>
> Suppose dependencies-with-variants would have allowed requiring  
> "gtk2+x11" ?

+x11 is the default.  You can do some ui_err magic if they don't have  
gtk2+x11.

>> So either the user had a +quartz gtk2 (in which case he can't use  
>> rox) or he has some other problem that adding the X11 dependencies  
>> to rox won't solve (because they're redundant).
>
> In order to use a non-system X11, the port needed the usual  
> workaround:
> configure.args-append --x-include=${prefix}/include --x-lib=$ 
> {prefix}/lib
> Just wasn't obvious where to add them, when using Zero Install's -- 
> compile.

It should "just work".

> And obviously they would be wrong, when using +system_x11 (another  
> story)

The solution I've been using is just tricking AC_X_PATH by ALWAYS  
using --x-include=${prefix}/include --x-lib=${prefix}/lib and  
appending -I${x11prefix}/include and -L${x11prefix}/lib to  
configure.cppflags and configure.ldflags if ${prefix}/lib/pkgconfig/ 
x11.pc isn't available (just grep for AC_X_PATH in the tree, and  
you'll see a port that is doing that).

> But seems like it'll be able to pick up /usr/X11R6 anyway, due to it  
> being
> present in gtk2's pkg-config and it being the default. So should be  
> good.

Right... /usr/X11R6 should NOT be in gtk2's pc unless they're using  
+system_x11

$ pkg-config --libs gtk+-x11-2.0
-L/opt/local/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 - 
lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpangoft2-1.0 -lpango-1.0 - 
lm -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl

$ pkg-config --cflags gtk+-x11-2.0
-I/opt/local/include/gtk-2.0 -I/opt/local/lib/gtk-2.0/include -I/opt/ 
local/include/atk-1.0 -I/opt/local/include/cairo -I/opt/local/include/ 
pango-1.0 -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/ 
include -I/opt/local/include/pixman-1 -I/opt/local/include/freetype2 - 
I/opt/local/include/libpng12



From blb at macports.org  Thu Apr 23 23:04:50 2009
From: blb at macports.org (Bryan Blackburn)
Date: Fri, 24 Apr 2009 00:04:50 -0600
Subject: Avoiding the issue with https and 'fetch.type svn'
Message-ID: <20090424060450.GR50911@ninagal.withay.com>

Ports which use 'fetch.type svn' and have an https URL (eg, tickets #17419,
#18429, and possibly #18583) will quite likely fail for people in the fetch
stage.  svn from the current subversion port (version 1.6.1) has the
--trust-server-cert option to avoid this, but /usr/bin/svn on 10.5 is too
old to have it.  Unless we are going to add subversion as a dependency for
all ports setting svn as the fetch type, this is a problem.

The maintainer of the flashdot port (Tobias Elze) mentioned one way this can
be worked around in the Portfile, using "echo p | svn ls ${svn.url}" to get
the cert accepted first.  So I added this in pre-fetch as a test and it
works quite nicely.

This can obviously be added to any port needing it, or perhaps even to base,
but is a bit kludgy overall; does anyone have any better ideas to fix this
or shall we start updating some Portfiles?

Bryan


From florian.ebeling at gmail.com  Thu Apr 23 23:52:48 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Fri, 24 Apr 2009 08:52:48 +0200
Subject: ruby_select experimental implementation
In-Reply-To: <20090422220051485505.e38ce4e0@macports.org>
References: <20090422220051485505.e38ce4e0@macports.org>
Message-ID: <5cbbe4ae0904232352i38787d63r1979490b00602d45@mail.gmail.com>

On Wed, Apr 22, 2009 at 3:00 PM, kimura wataru <kimuraw at macports.org> wrote:
> I write experimental ruby_select for ruby186 and ruby18.
>
> ?http://trac.macports.org/browser/users/kimuraw/ruby_select

I will test it shortly and try to add the ruby19 aspects to it.
Is it ok if I commit to your user space svn or do you prefer
if I branch it off to my space?

>
> == install destinations
>
> * different name for ruby bundled commands and libraries
> * share library and document directory for additional libraries
>
> this allows to activate both of ruby186 and ruby18.
>
>
> ?dir,file ? ? ? 1.8.6(ruby186) ? ? ? ? ? ? 1.8.7(ruby18)
> ------------------------------------------------------------
> bin/ruby ? ? ? ?bin/ruby186 ? ? ? ? ? ? ? ?bin/ruby18
> bin/irb ? ? ? ? bin/irb186 ? ? ? ? ? ? ? ? bin/irb18
> ?:
> libdir ? ? ? ? ?lib/ruby/1.8.6/ ? ? ? ? ? ?lib/ruby/1.8.7/
> sitedir ? ? ? ? lib/ruby/site_ruby/1.8/ ? ?(share)
> vendordir ? ? ? lib/ruby/vendor_ruby/1.8/ ?(share)
> libruby.so ? ? ?libruby186.dylib ? ? ? ? ? libruby18.dylib
> ri sysdir ? ? ? share/ri/1.8/system1.8.6/ ?share/ri/1.8/system1.8.7/
> ri sitedir ? ? ?share/ri/1.8/site/ ? ? ? ? (share)
> ------------------------------------------------------------
>
> macports' vendor-specific.rb and site-specific.rb are moved
> to lidir from vendordir and sitedir to avoid conflicts.

That's what I expected, only these remaining conflicts
I didn't expect.

>
> == ruby_select
>
> sysutils/ruby_select uses same tool as port:python_select or port:gcc_selct.
>
> ?% sudo ruby_select ruby18
> ?Selecting version "ruby18" for ruby
> ?% ls -l /opt/local/bin/ruby
> ?lrwxr-xr-x ?1 root ?admin ?21 Apr 18 21:03 /opt/local/bin/ruby@ -> /opt/local/bin/ruby18
> ?% sudo ruby_select ruby186
> ?Selecting version "ruby186" for ruby
> ?% ls -l /opt/local/bin/ruby
> ?lrwxr-xr-x ?1 root ?admin ?22 Apr 18 21:06 /opt/local/bin/ruby@ -> /opt/local/bin/ruby186
>
> the following files are targets of ruby_select.
> * bin/ ruby, erb, irb, rdoc, ri, testrb
> * lib/ libruby.dylib, libruby-static.a
>
> ruby_select make symlinks the above files at post-activate.
> then, install ruby_select means existence of ${prefix}/bin/ruby (without suffix).
> I expect this port become a meta port port:ruby.

Yes. We have to keep an eye on Bryan's point though, that the older
ruby port and the new ruby18 do conflict and that it can break installs
for the user if he does not upgrade (over which we have now control
besides from advising via ui_msgs). See his mail:

http://lists.macosforge.org/pipermail/macports-dev/2009-April/008258.html

>
> == linking libruby
>
> ruby_select introduce libruby.dylib. this file is a symbolic link for
> libruby186.dylib or libruby18.dylib. and, vendor-specific.rb changes
> LIBRUBYARG and so on.
>
> ?% ruby -rrbconfig -e 'p Config::CONFIG["LIBRUBYARG"]'
> ?"-lruby18"
> ?% ruby -rvendor-specific -rrbconfig -e 'p Config::CONFIG["LIBRUBYARG"]'
> ?"-lruby"
>
> so, port:rb-* links libruby.dylib and extension modules (.bundle)
> use ruby_select-ed libruby.

I'm not sure we want to interchange libraries between 1.8
and 1.9 transparently. If we don't want it, having a name
ending in 18 might be better. That way 1.8.6 and 1.8.7+
would share the name here, but not 1.9. Having the
executables share the same name seems to be the
important part to me anyway, not so much for makefile
in extensions and such (where the lib name would matter).

Florian

-- 
Florian Ebeling
Twitter: febeling
florian.ebeling at gmail.com

From afb at macports.org  Fri Apr 24 00:35:58 2009
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Fri, 24 Apr 2009 09:35:58 +0200
Subject: [50047] trunk/dports/x11/rox-filer/Portfile
In-Reply-To: <FAC6BC38-A9A7-4C3D-8399-43F2ED95EE67@macports.org>
References: <20090423120538.0BD201638075@beta.macosforge.org>
	<F14D7788-47F3-415A-AFEF-244C7525E44B@macports.org>
	<82ADA340-8FBA-4CCC-84A3-CACEF53FE325@macports.org>
	<75606FA3-C184-4AB0-A150-584A311B8465@macports.org>
	<B61440D8-2EC5-4940-8D8B-0165E6593052@macports.org>
	<FAC6BC38-A9A7-4C3D-8399-43F2ED95EE67@macports.org>
Message-ID: <859C12A1-958A-4970-98A8-6C908909488E@macports.org>

Jeremy Huddleston wrote:

>> In order to use a non-system X11, the port needed the usual  
>> workaround:
>> configure.args-append --x-include=${prefix}/include --x-lib=$ 
>> {prefix}/lib
>> Just wasn't obvious where to add them, when using Zero Install's -- 
>> compile.
>
> It should "just work".

Not with "use_configure no"...

Fortunately you could add args.

>> And obviously they would be wrong, when using +system_x11 (another  
>> story)
>
> The solution I've been using is just tricking AC_X_PATH by ALWAYS  
> using --x-include=${prefix}/include --x-lib=${prefix}/lib and  
> appending -I${x11prefix}/include and -L${x11prefix}/lib to  
> configure.cppflags and configure.ldflags if ${prefix}/lib/pkgconfig/ 
> x11.pc isn't available (just grep for AC_X_PATH in the tree, and  
> you'll see a port that is doing that).

I included the rest of the "trick" boilerplate as well.

I already had it shoved down some of my other ports...

>> But seems like it'll be able to pick up /usr/X11R6 anyway, due to  
>> it being
>> present in gtk2's pkg-config and it being the default. So should  
>> be good.
>
> Right... /usr/X11R6 should NOT be in gtk2's pc unless they're using  
> +system_x11

I meant "when I am" (using +system_x11). But I was wrong, as it didn't.
Sorta  built anyway, but the configure was all wrong due to ld errors.

It should now work for both ${prefix} and ${x11prefix} again. (finally)
These tricks should probably go into base, rather than into every port ?

--anders


From raimue at macports.org  Fri Apr 24 00:45:26 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Fri, 24 Apr 2009 09:45:26 +0200
Subject: Avoiding the issue with https and 'fetch.type svn'
In-Reply-To: <20090424060450.GR50911@ninagal.withay.com>
References: <20090424060450.GR50911@ninagal.withay.com>
Message-ID: <49F16E16.8020601@macports.org>

Bryan Blackburn wrote:
> Ports which use 'fetch.type svn' and have an https URL (eg, tickets #17419,
> #18429, and possibly #18583) will quite likely fail for people in the fetch
> stage.  svn from the current subversion port (version 1.6.1) has the
> --trust-server-cert option to avoid this, but /usr/bin/svn on 10.5 is too
> old to have it.  Unless we are going to add subversion as a dependency for
> all ports setting svn as the fetch type, this is a problem.

This would be a simple solution. I think we can neglect entity
authentication as we are also not doing anything like that when using
rsync and HTTP/FTP.

> The maintainer of the flashdot port (Tobias Elze) mentioned one way this can
> be worked around in the Portfile, using "echo p | svn ls ${svn.url}" to get
> the cert accepted first.  So I added this in pre-fetch as a test and it
> works quite nicely.

Looks like quite a hack to me.

We are currently using svn --non-interactive which avoids being asked
any questions. So if we would like to use this approach, we would have
to drop non-interactive, too. I am not sure if there is a situation
where this could cause problems.

> This can obviously be added to any port needing it, or perhaps even to base,
> but is a bit kludgy overall; does anyone have any better ideas to fix this
> or shall we start updating some Portfiles?

Let me share some crazy idea :-)

We could ship a special Subversion config directory which already
contains accepted certificates for the hosts in question. It would be
used instead of ~/.subversion/ like this:

  svn --config-dir=${portresourcepath}/port1.0/fetch/svn/

Accepted certificates are stored in the auth/svn.ssl.server/ directory.
The filenames are hashes of the hostname/URL (?).

Pro:
 * Works with svn 1.4 as shipped with Leopard
 * No user config involved any more
 * Keeps some way of entity authentication

Contra:
 * Harder to maintain at a global place instead of per port
   (I don't believe many ports where we have seen this are using the
   same svn server, e.g. sf.net uses sub-domains)


Note that manually accepting a cert would still be possible with write
permissions on the port resource path (and adding the --config-dir
option), but it would be reverted at the next sync.

Adding a dependency on svn 1.6 from MacPorts would be an immediate fix.
Shipping a custom config with sync would require some changes to base
and would have to wait until the next release.

Rainer

From ryandesign at macports.org  Fri Apr 24 02:03:23 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 24 Apr 2009 04:03:23 -0500
Subject: Avoiding the issue with https and 'fetch.type svn'
In-Reply-To: <49F16E16.8020601@macports.org>
References: <20090424060450.GR50911@ninagal.withay.com>
	<49F16E16.8020601@macports.org>
Message-ID: <7FBCA4F3-6296-429B-95E6-E0C6357454D3@macports.org>

On Apr 24, 2009, at 02:45, Rainer M?ller wrote:

> Bryan Blackburn wrote:
>
>> Ports which use 'fetch.type svn' and have an https URL (eg,  
>> tickets #17419,
>> #18429, and possibly #18583) will quite likely fail for people in  
>> the fetch
>> stage.  svn from the current subversion port (version 1.6.1) has the
>> --trust-server-cert option to avoid this, but /usr/bin/svn on 10.5  
>> is too
>> old to have it.  Unless we are going to add subversion as a  
>> dependency for
>> all ports setting svn as the fetch type, this is a problem.
>
> This would be a simple solution. I think we can neglect entity
> authentication as we are also not doing anything like that when using
> rsync and HTTP/FTP.

[snip]

> Adding a dependency on svn 1.6 from MacPorts would be an immediate  
> fix.

I think that's what we should do -- for the ports that require it.  
It's simple and straightforward. If you add a comment explaining why  
the MacPorts svn is required vs. the svn on Leopard that'll make it  
clear to anyone looking at the portfile later.


From ryandesign at macports.org  Fri Apr 24 02:05:12 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 24 Apr 2009 04:05:12 -0500
Subject: [50072] trunk/dports/x11/rox-filer/Portfile
In-Reply-To: <20090424072606.42A351643E86@beta.macosforge.org>
References: <20090424072606.42A351643E86@beta.macosforge.org>
Message-ID: <86030DF1-7FAF-4073-96EC-8BB922D7555A@macports.org>

On Apr 24, 2009, at 02:26, afb at macports.org wrote:

> Revision: 50072
>           http://trac.macports.org/changeset/50072
> Author:   afb at macports.org
> Date:     2009-04-24 00:26:05 -0700 (Fri, 24 Apr 2009)
> Log Message:
> -----------
> build.env is broken, work around it
>
> Modified Paths:
> --------------
>     trunk/dports/x11/rox-filer/Portfile
>
> Modified: trunk/dports/x11/rox-filer/Portfile
> ===================================================================
> --- trunk/dports/x11/rox-filer/Portfile	2009-04-24 07:24:42 UTC  
> (rev 50071)
> +++ trunk/dports/x11/rox-filer/Portfile	2009-04-24 07:26:05 UTC  
> (rev 50072)
> @@ -47,8 +47,8 @@
>      }
>  }
>
> -build.env	CC=${configure.cc} CPPFLAGS=${configure.cppflags}  
> LDFLAGS=${configure.ldflags}
> -build		{ system "cd ${worksrcpath}; ./ROX-Filer/AppRun --compile $ 
> {configure.args}" }
> +#build.env	CC=${configure.cc} CPPFLAGS=${configure.cppflags}  
> LDFLAGS=${configure.ldflags}
> +build		{ system "cd ${worksrcpath}; CC=${configure.cc} CPPFLAGS=\"$ 
> {configure.cppflags}\" LDFLAGS=\"${configure.ldflags}\" ./ROX-Filer/ 
> AppRun --compile ${configure.args}" }

build.env isn't broken, but it isn't used if you override the build  
phase, right?

Why not use the default build phase? Untested:

build.env ${configure.env}
build.cmd ./ROX-Filer/AppRun
build.args --compile ${configure.args}



From afb at macports.org  Fri Apr 24 04:08:17 2009
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Fri, 24 Apr 2009 13:08:17 +0200
Subject: [50072] trunk/dports/x11/rox-filer/Portfile
In-Reply-To: <86030DF1-7FAF-4073-96EC-8BB922D7555A@macports.org>
References: <20090424072606.42A351643E86@beta.macosforge.org>
	<86030DF1-7FAF-4073-96EC-8BB922D7555A@macports.org>
Message-ID: <84B5523C-B293-48EA-824C-794BD44CCBBE@macports.org>

Ryan Schmidt wrote:

>>
>> build.env isn't broken, but it isn't used if you override the  
>> build phase, right?
>
> Why not use the default build phase? Untested:
>
> build.env ${configure.env}
> build.cmd ./ROX-Filer/AppRun
> build.args --compile ${configure.args}

If I use ${configure.env}, I get:

DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.4'

If I populate build.env myself, it's:

DEBUG: Environment: CPPFLAGS='-I/opt/local/include'  
MACOSX_DEPLOYMENT_TARGET='10.4' LDFLAGS='-L/opt/local/lib' CC='/usr/ 
bin/gcc-4.0'

So the only way I could make it work was:

+ CC=/usr/bin/gcc-4.0
+ CPPFLAGS=-I/opt/local/include -I/usr/X11R6/include
+ LDFLAGS=-L/opt/local/lib -L/usr/X11R6/lib
+ ./ROX-Filer/AppRun --compile --x-include=/opt/local/include --x- 
lib=/opt/local/lib


But it's likely something else that is wrong here...
Them flags have an unhealthy attachment to configure.

So it's hardly worth the hassle, just for two prefixes ?
Might even be better to use Zero Install directly then:

0launch http://rox.sourceforge.net/2005/interfaces/ROX-Filer

Main reason for using MacPorts at all was to avoid having
to bundle/compile GTK+, which is rather tedious "by hand".

But it might be easier to do just that, and use system X11.
And that way it would work for other Zero Install apps too.

--anders


From raimue at macports.org  Fri Apr 24 06:32:08 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Fri, 24 Apr 2009 15:32:08 +0200
Subject: [spam probable] [50018] php5-eaccelerator Lint Report
In-Reply-To: <95FD71CD-DB42-4125-813B-DB0EF230BA42@macports.org>
References: <20090422143911.640EA2807E@relay11.apple.com>	<4E5CFE7F-0879-4DD3-BDF2-932DFACDB7B5@macports.org>
	<49EF887D.9070209@macports.org> <49EF8E3A.7020605@macports.org>
	<95FD71CD-DB42-4125-813B-DB0EF230BA42@macports.org>
Message-ID: <49F1BF58.5020505@macports.org>

Ryan Schmidt wrote:
> On Apr 22, 2009, at 16:38, Rainer M?ller wrote:
>> But we check the primary category against a hardcoded list of valid
>> categories and we also check the parent directory of the port  
>> directory.
>> To pass both tests, this list will always have to reflect the current
>> existing category directories in the repository. Therefore it is quite
>> useless.
> 
> Which part is useless? The separately-maintained list of valid  
> categories in portlint.tcl? I've thought that too...

Yes, I mean the lint_categories list in portlint.tcl.

> Then again, you might be developing a port in a separate directory,  
> say /Users/yourname/someport. In that case, port lint would complain  
> that "yourname" is not the same as the primary category declared in  
> the port, which is true, and you'd realize why lint is saying that  
> and ignore it. If we removed the list of valid categories from  
> portlint.tcl, then port lint wouldn't be able to detect if you had in  
> fact made a typo in your primary category name as listed in the  
> portfile. However, one could argue that this is a rare case and that  
> we don't need to handle it. It would certainly simplify things to  
> remove the list of categories from portlint.tcl, and leave it to just  
> check that the category directory name matches the primary category  
> declared in the portfile.

I think this is a rare case. If we remove the list, 'port lint' would
still print a message if the parent directory of the port directory does
not match the primary category. This check should be good enough to find
typos as it is moved into the repository.

Rainer

From captsolo at gmail.com  Fri Apr 24 11:57:24 2009
From: captsolo at gmail.com (Uldis Bojars)
Date: Fri, 24 Apr 2009 19:57:24 +0100
Subject: [MacPorts] #19386: rtmpdump: libkern/_OSByteOrder.h: No such file
	or directory
In-Reply-To: <068.c2cd0d696c8a8cc07b7d0dc6c26279d3@macports.org>
References: <059.ff7b6e5f29395cd5eff185c28f957719@macports.org>
	<068.c2cd0d696c8a8cc07b7d0dc6c26279d3@macports.org>
Message-ID: <64c81f720904241157i4b36c9fck53ee486a24eba6a4@mail.gmail.com>

If here is someone who has access to OS X 10.4, could you please check
if the patch attached to ticket [1] solves the compilation problem
reported?

Thanks,
Uldis

On Wed, Apr 22, 2009 at 12:35 AM, MacPorts <noreply at macports.org> wrote:
> #19386: rtmpdump: libkern/_OSByteOrder.h: No such file or directory
> -------------------------------------+--------------------------------------
> ?Reporter: ?ryandesign@? ? ? ? ? ? ? | ? ? ? Owner: ?captsolo@?
> ? ? Type: ?defect ? ? ? ? ? ? ? ? ? | ? ? ?Status: ?new
> ?Priority: ?Normal ? ? ? ? ? ? ? ? ? | ? Milestone: ?Port Bugs
> Component: ?ports ? ? ? ? ? ? ? ? ? ?| ? ? Version: ?1.7.1
> ?Keywords: ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ?Port: ?rtmpdump
> -------------------------------------+--------------------------------------
>
> Comment(by captsolo@?):
>
> ?Attached the new patch.
>
> --
> Ticket URL: <http://trac.macports.org/ticket/19386#comment:2>
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS
>

From captsolo at gmail.com  Fri Apr 24 12:03:21 2009
From: captsolo at gmail.com (Uldis Bojars)
Date: Fri, 24 Apr 2009 20:03:21 +0100
Subject: [MacPorts] #19386: rtmpdump: libkern/_OSByteOrder.h: No such file
	or directory
In-Reply-To: <64c81f720904241157i4b36c9fck53ee486a24eba6a4@mail.gmail.com>
References: <059.ff7b6e5f29395cd5eff185c28f957719@macports.org>
	<068.c2cd0d696c8a8cc07b7d0dc6c26279d3@macports.org>
	<64c81f720904241157i4b36c9fck53ee486a24eba6a4@mail.gmail.com>
Message-ID: <64c81f720904241203w142609dai5da492312a86702e@mail.gmail.com>

There is a follow-up report on SF.net saying that an additional patch
patch may also be needed:
https://sourceforge.net/forum/message.php?msg_id=7267196

But, again, I can not verify if that is so.

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

On Fri, Apr 24, 2009 at 7:57 PM, Uldis Bojars <captsolo at gmail.com> wrote:
> If here is someone who has access to OS X 10.4, could you please check
> if the patch attached to ticket [1] solves the compilation problem
> reported?
>
> Thanks,
> Uldis
>
> On Wed, Apr 22, 2009 at 12:35 AM, MacPorts <noreply at macports.org> wrote:
>> #19386: rtmpdump: libkern/_OSByteOrder.h: No such file or directory
>> -------------------------------------+--------------------------------------
>> ?Reporter: ?ryandesign@? ? ? ? ? ? ? | ? ? ? Owner: ?captsolo@?
>> ? ? Type: ?defect ? ? ? ? ? ? ? ? ? | ? ? ?Status: ?new
>> ?Priority: ?Normal ? ? ? ? ? ? ? ? ? | ? Milestone: ?Port Bugs
>> Component: ?ports ? ? ? ? ? ? ? ? ? ?| ? ? Version: ?1.7.1
>> ?Keywords: ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ?Port: ?rtmpdump
>> -------------------------------------+--------------------------------------
>>
>> Comment(by captsolo@?):
>>
>> ?Attached the new patch.
>>
>> --
>> Ticket URL: <http://trac.macports.org/ticket/19386#comment:2>
>> MacPorts <http://www.macports.org/>
>> Ports system for Mac OS
>>
>

From jeremyhu at macports.org  Fri Apr 24 12:23:18 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Fri, 24 Apr 2009 12:23:18 -0700
Subject: [49758] trunk/dports/net
In-Reply-To: <20090417154007.639EC15D8D36@beta.macosforge.org>
References: <20090417154007.639EC15D8D36@beta.macosforge.org>
Message-ID: <D17568DA-27A6-4980-9D50-DB2C521767EA@macports.org>

Why was this "universal_variant no"?  It builds universal here, and  
making this not universal breaks building libsoup which is a headache  
for gnome... so unless you want to !universal all of gnome, I suggest  
the following:

Index: Portfile
===================================================================
--- Portfile	(revision 50075)
+++ Portfile	(working copy)
@@ -5,6 +5,7 @@

  name                libproxy
  version             0.2.3
+revision            1
  categories          net
  maintainers         devans
  platforms           darwin
@@ -18,8 +19,6 @@
                      network resource, how do I reach it? It handles  
all \
                      the details, enabling you to get back to  
programming.

-universal_variant   no
-
  checksums           md5     86b635e1eb2d665cfbef4c6134fe6604 \
                      sha1    2b2b00a179740548035a1145bbae600db9b0a2ce \
                      rmd160  c86c4f8403cb879380e101d074af469c960b5c1c

On Apr 17, 2009, at 08:40, devans at macports.org wrote:

> Revision: 49758
>          http://trac.macports.org/changeset/49758
> Author:   devans at macports.org
> Date:     2009-04-17 08:40:06 -0700 (Fri, 17 Apr 2009)
> Log Message:
> -----------
> new port libproxy: automatic proxy configuration no matter what.
>
> Added Paths:
> -----------
>    trunk/dports/net/libproxy/
>    trunk/dports/net/libproxy/Portfile
>
> Added: trunk/dports/net/libproxy/Portfile
> ===================================================================
> --- trunk/dports/net/libproxy/Portfile	                        (rev 0)
> +++ trunk/dports/net/libproxy/Portfile	2009-04-17 15:40:06 UTC (rev  
> 49758)
> @@ -0,0 +1,49 @@
> +# -*- 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
> +
> +name                libproxy
> +version             0.2.3
> +categories          net
> +maintainers         devans
> +platforms           darwin
> +homepage            http://code.google.com/p/${name}/
> +master_sites        googlecode
> +
> +description         A library that provides automatic proxy  
> configuration management.
> +
> +
> +long_description    Libproxy exists to answer the question: Given a \
> +                    network resource, how do I reach it? It handles  
> all \
> +                    the details, enabling you to get back to  
> programming.
> +
> +universal_variant   no
> +
> +checksums           md5     86b635e1eb2d665cfbef4c6134fe6604 \
> +                    sha1     
> 2b2b00a179740548035a1145bbae600db9b0a2ce \
> +                    rmd160  c86c4f8403cb879380e101d074af469c960b5c1c
> +
> +depends_build       port:pkgconfig
> +
> +depends_lib         port:gconf \
> +                    port:python25 \
> +                    port:xorg-libXmu
> +
> +configure.python    ${prefix}/bin/python2.5
> +
> +configure.args      --without-webkit \
> +                    --without-kde \
> +                    --without-networkmanager \
> +                    --without-mozjs
> +
> +variant no_x11 conflicts kde {
> +        configure.args-append --without-x11
> +        depends_lib-delete port:xorg-libXmu
> +}
> +
> +variant kde conflicts no_x11 description {Enable kde plugin  
> (requires X11)} {
> +        configure.args-delete --without-kde
> +}
> +
> +livecheck.regex     "${name}-(\\d+(?:\\.\\d+)*)${extract.suffix}"
>
>
> Property changes on: trunk/dports/net/libproxy/Portfile
> ___________________________________________________________________
> Added: svn:keywords
>   + Id
> Added: svn:eol-style
>   + native
> _______________________________________________
> macports-changes mailing list
> macports-changes at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes


From dweber at macports.org  Fri Apr 24 13:37:48 2009
From: dweber at macports.org (Darren Weber)
Date: Fri, 24 Apr 2009 13:37:48 -0700
Subject: lengthy build - changed Portfile - need to continue without removing 
	build results
Message-ID: <b808b3510904241337x4f9bb1b0p7a580a537093dfa0@mail.gmail.com>

I'm working on vtk-devel Portfile and I have:
a) completed a lengthy build of VTK
b) edited parts of the Portfile that affect downstream stages from the build
(ie, destroot command)

How can I continue with the downstream stages without losing the build?

The default behavior is to clean everything when the Portfile is newer than
some state file (I don't yet understand how state files work).  I see the
following options to port that might be useful:

?f force mode (ignore state file)
?o honor state files older than Portfile
?k keep mode (don't autoclean after install)

Given everything is done up to 'port build <port>' and then Portfile is
changed to modify the destroot phase only, what is the best option to
proceed with destroot:

a) port -f destroot <port>
b) port -o destroot <port>

Thanks in advance,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090424/bd482388/attachment.html>

From kimuraw at macports.org  Fri Apr 24 15:57:57 2009
From: kimuraw at macports.org (kimura wataru)
Date: Sat, 25 Apr 2009 07:57:57 +0900
Subject: ruby_select experimental implementation
In-Reply-To: <5cbbe4ae0904232352i38787d63r1979490b00602d45@mail.gmail.com>
References: <20090422220051485505.e38ce4e0@macports.org>
	<5cbbe4ae0904232352i38787d63r1979490b00602d45@mail.gmail.com>
Message-ID: <20090425075757707156.a0a36eb2@macports.org>

Hi Florian,

On Fri, 24 Apr 2009 08:52:48 +0200, C. Florian Ebeling wrote:
> On Wed, Apr 22, 2009 at 3:00 PM, kimura wataru <kimuraw at macports.org> wrote:
>> I write experimental ruby_select for ruby186 and ruby18.
>> 
>>  http://trac.macports.org/browser/users/kimuraw/ruby_select
> 
> I will test it shortly and try to add the ruby19 aspects to it.
> Is it ok if I commit to your user space svn or do you prefer
> if I branch it off to my space?
> 
I'm welcome your commit to my svn space.

>> == ruby_select
>> 
>> sysutils/ruby_select uses same tool as port:python_select or 
>> port:gcc_selct.
>> 

>> ruby_select make symlinks the above files at post-activate.
>> then, install ruby_select means existence of ${prefix}/bin/ruby 
>> (without suffix).
>> I expect this port become a meta port port:ruby.
> 
> Yes. We have to keep an eye on Bryan's point though, that the older
> ruby port and the new ruby18 do conflict and that it can break installs
> for the user if he does not upgrade (over which we have now control
> besides from advising via ui_msgs). See his mail:
> 
> http://lists.macosforge.org/pipermail/macports-dev/2009-April/008258.html
> 

ruby18 and ruby do not conflict. ruby18 do not have any install files
with same path from ruby port.

>> 
>> == linking libruby
>> 
>> ruby_select introduce libruby.dylib. this file is a symbolic link for
>> libruby186.dylib or libruby18.dylib. and, vendor-specific.rb changes
>> LIBRUBYARG and so on.
>> 
>>  % ruby -rrbconfig -e 'p Config::CONFIG["LIBRUBYARG"]'
>>  "-lruby18"
>>  % ruby -rvendor-specific -rrbconfig -e 'p Config::CONFIG["LIBRUBYARG"]'
>>  "-lruby"
>> 
>> so, port:rb-* links libruby.dylib and extension modules (.bundle)
>> use ruby_select-ed libruby.
> 
> I'm not sure we want to interchange libraries between 1.8
> and 1.9 transparently. If we don't want it, having a name
> ending in 18 might be better. That way 1.8.6 and 1.8.7+
> would share the name here, but not 1.9. Having the
> executables share the same name seems to be the
> important part to me anyway, not so much for makefile
> in extensions and such (where the lib name would matter).
> 

I agree.
Recently 1.8 (1.8.6 or later) and 1.9 keep same C-API for 
extension modules. I think most of C-libraries for ruby 1.8 works
with 1.9 as well as pure ruby libraries. But, it means some
libraries do not work.


-- 
kimura wataru

From kimuraw at macports.org  Fri Apr 24 16:14:44 2009
From: kimuraw at macports.org (kimura wataru)
Date: Sat, 25 Apr 2009 08:14:44 +0900
Subject: ruby_select experimental implementation
In-Reply-To: <49EF93F6.2090108@macports.org>
References: <20090422220051485505.e38ce4e0@macports.org>
	<49EF93F6.2090108@macports.org>
Message-ID: <20090425081444767257.20a0aa2e@macports.org>

Hi,

On Thu, 23 Apr 2009 00:02:30 +0200, Rainer M?ller wrote:
> kimura wataru wrote:
>> I write experimental ruby_select for ruby186 and ruby18.
>> 
>>   http://trac.macports.org/browser/users/kimuraw/ruby_select
> 
> Will ruby19 be moved to ruby? Or what will happen to the existing ruby
> port at all?
> 
No, ruby becomes meta-port for ruby186/18/19 in this work.

> I would like to avoid the situation we created with python, where we
> have only the versioned ports. Currently if you install many ports
> dependencies will pull in all of python24, python25 and python26.
> Something like this should be avoided. And maybe there should also be a
> "default" python version.
> 

> I am not against providing multiple versions and allow switching, but we
> should avoid creating a dependency hell where multiple available
> versions are pulled in unecessary as happened for python.
> 
>> == ruby_select
>> 
>> sysutils/ruby_select uses same tool as port:python_select or 
>> port:gcc_selct.
>> [...]
> 
> The select files should be part of the corresponding ports and not be in
> ruby_select as it is for python. This avoids selection of a
> non-installed ruby version.
> 
> You can use the select port group at
> _resources/port1.0/group/select-1.0.tcl to set this up easily.
> 
Thanks, I'll try this.

>> so, port:rb-* links libruby.dylib and extension modules (.bundle)
>> use ruby_select-ed libruby.
> 
> This sounds like you will not be able to install modules for a specific
> ruby version while you can install multiple ruby versions at the same
> time. Is this correct? If so, where is the sense in that?
> 
One of the purposes of ruby_select is to enable to use the same:rb-* port
for all of ruby versions. 

-- 
kimura wataru

From blb at macports.org  Fri Apr 24 16:35:58 2009
From: blb at macports.org (Bryan Blackburn)
Date: Fri, 24 Apr 2009 17:35:58 -0600
Subject: lengthy build - changed Portfile - need to continue without
	removing build results
In-Reply-To: <b808b3510904241337x4f9bb1b0p7a580a537093dfa0@mail.gmail.com>
References: <b808b3510904241337x4f9bb1b0p7a580a537093dfa0@mail.gmail.com>
Message-ID: <20090424233558.GD98275@ninagal.withay.com>

On Fri, Apr 24, 2009 at 01:37:48PM -0700, Darren Weber said:
> I'm working on vtk-devel Portfile and I have:
> a) completed a lengthy build of VTK
> b) edited parts of the Portfile that affect downstream stages from the build
> (ie, destroot command)
> 
> How can I continue with the downstream stages without losing the build?
> 
> The default behavior is to clean everything when the Portfile is newer than
> some state file (I don't yet understand how state files work).  I see the
> following options to port that might be useful:
> 
> ?f force mode (ignore state file)
> ?o honor state files older than Portfile
> ?k keep mode (don't autoclean after install)
> 
> Given everything is done up to 'port build <port>' and then Portfile is
> changed to modify the destroot phase only, what is the best option to
> proceed with destroot:
> 
> a) port -f destroot <port>
> b) port -o destroot <port>

What I do when first building a port is to run through destroot normally,
and if there's anything to change just there, update the Portfile as
appropriate.  Then, remove the work/destroot directory, and finally edit the
statefile (work/.macports.<portname>.state) to remove the destroot target
line, so port thinks it has to destroot again.  This way the state file is
still newer than Portfile (since it was edited second) and I don't have to
wait for configure/build again.

Bryan


> 
> Thanks in advance,
> Darren

From markd at macports.org  Fri Apr 24 18:50:09 2009
From: markd at macports.org (markd at macports.org)
Date: Fri, 24 Apr 2009 18:50:09 -0700
Subject: NewHelpSystem
Message-ID: <fc.004c4c58120b3bfb004c4c58120b3bfb.12136595@biola.edu>

>First I want to apologize for being inactive in the last months.
>I only have sporadic access to a Mac at the moment (I switched to
>Linux with my main machine) so my activity was very low. But I
>like the MacPorts project and will continue to update my ports
>when I have time and access to my Mac. But as I will not be very
>active feel free to take over my ports.
>
>Regarding the guide. I think for now the guide should use DocBook
>at least until it's finished. Then we can decide if we want to
>switch. But the duplication pointed out by Mark is an important
>factor. So I think we should make a quick decision if the man
>pages should be written in DocBook or Asciidoc. And after the
>decision all other documents should be merged and removed so we
>only have one source and no duplication.
>
>If we switch the man pages to Asciidoc then all man pages in
>base/doc/ should only be generated through Asciidoc so we have a
>single format.
>
>The only problematic man page is portfile.7 as it is directly
>wired into the guide. I would like to remove it (or generate it
>through DocBook) and instead install the guide in
>/opt/local/share/doc/port/ so the user can access it.
>
>We should really remove all duplication and move documentation
>either to base/doc or doc, but not in both places.


Hi Simon,

Sorry to take so long to reply.  The first step I had in mind with the new
guide was to get into it at least all knowledge that the old guide had,
and then midway into it decided to add the content from the man pages too.
 Though I really think it is a serious mistake to split the man page
content from the guide because of the overlap, the reasons for it seem
selfevident enough to me that I really don't want to waste any more time
arguing this.

So basically I am saying that for those who consider rewriting the man
page *content* a separate project (though as I said I do not) then the
guide could be considered more or less complete if we've incorporated all
the useful information from the old guide.  I can do a quick scan of the
old guide and see.

I think it is fine to start writing man pages in asciidoc - I was never
really comfortable with man pages sourced from DocBook.  The way the XML
had to be formatted for man pages was kludgy and the processing it took to
generate the output was too.  I think asciidoc is an intriguing
possibility and I'll be taking a look at it soon.  If it made the task of
integrating the man page content into the guide easier it would be great,
and that is a goal of mine if no one else's goal.  I think people are
confusing the man pages with the man page content in this discussion.

So basically I'm saying that I think we should get on with doc projects,
whether they compete or not.  We've had enough of discusson already.  If
and when one of us has produced something real that is more complete or
better in some way than what we have now then we can discuss it at that
time.

Mark


From markd at macports.org  Fri Apr 24 19:02:34 2009
From: markd at macports.org (markd at macports.org)
Date: Fri, 24 Apr 2009 19:02:34 -0700
Subject: NewHelpSystem & man pages
Message-ID: <fc.004c4c58120b3d40004c4c58120b3d40.12136886@biola.edu>

>> This is also the reason why I am splitting this into multiple smaller
>> man pages describing one command only. This makes it much easier to 
>> find
>> what you are after than searching a long port(1).
>
>Just to talk about this one point for a moment, perl has its manpages 
>split up into several, as a consequence of which I can't ever find 
>anything in them and never use them, opting to search Google instead. 
>If it had a single manpage, I could type "man perl", press return, 
>press "/", type my search string, press return, and see the result. 
>But since there are well over a hundred perl manpages, I have no hope 
>of finding what I want.

I also don't like tiny man pages, and don't use them.  It almost sounds
like we're talking about some form of expanded command help.
>
>Similarly, I've almost never looked at the chunked Guide. I load the 
>single-page Guide, so that I can press Command-F, type my search 
>string, press return, and find what I'm looking for. Which isn't to 
>say we shouldn't have the chunked Guide; we should. I suppose I'm 
>saying there are trade-offs with either approach.

Yes the single page guide is very useful for searching.  If we could get a
good index in it somehow that make searches unnecessary that would make
the one-page version obsolete, but I'm not sure how feasible that is.

Mark


From ryandesign at macports.org  Fri Apr 24 20:43:51 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 24 Apr 2009 22:43:51 -0500
Subject: NewHelpSystem & man pages
In-Reply-To: <fc.004c4c58120b3d40004c4c58120b3d40.12136886@biola.edu>
References: <fc.004c4c58120b3d40004c4c58120b3d40.12136886@biola.edu>
Message-ID: <BBAEFE26-ECF2-400A-BC76-AFA35CD4A8BE@macports.org>


On Apr 24, 2009, at 21:02, markd at macports.org wrote:

>> Similarly, I've almost never looked at the chunked Guide. I load the
>> single-page Guide, so that I can press Command-F, type my search
>> string, press return, and find what I'm looking for. Which isn't to
>> say we shouldn't have the chunked Guide; we should. I suppose I'm
>> saying there are trade-offs with either approach.
>
> Yes the single page guide is very useful for searching.  If we  
> could get a
> good index in it somehow that make searches unnecessary that would  
> make
> the one-page version obsolete, but I'm not sure how feasible that is.

We could add a "site:guide.macports.org" Google search box to the  
Guide pages which might work too. There's ways to make it work either  
as a single full page or chunked.


From jeremy at lavergne.gotdns.org  Fri Apr 24 22:33:24 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Sat, 25 Apr 2009 01:33:24 -0400
Subject: googlecode livecheck
Message-ID: <D5F9C694-CD0B-420D-AF63-DDB58D3FA5AA@lavergne.gotdns.org>

Has anyone else witnessed the default livecheck.regex failing when  
using master_sites googlecode?

For me, it looks like there is style info and whitespace breaking the  
pattern.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2435 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090425/f3307eae/attachment.bin>

From perry at macports.org  Fri Apr 24 23:12:09 2009
From: perry at macports.org (Perry Lee)
Date: Fri, 24 Apr 2009 23:12:09 -0700
Subject: googlecode livecheck
In-Reply-To: <D5F9C694-CD0B-420D-AF63-DDB58D3FA5AA@lavergne.gotdns.org>
References: <D5F9C694-CD0B-420D-AF63-DDB58D3FA5AA@lavergne.gotdns.org>
Message-ID: <F476FA2F-FAA7-450E-B1ED-7FB1DF8A52B1@macports.org>

On Apr 24, 2009, at 10:33 PM, Jeremy Lavergne wrote:

> Has anyone else witnessed the default livecheck.regex failing when  
> using master_sites googlecode?
>
> For me, it looks like there is style info and whitespace breaking  
> the pattern.

I've witnessed this problem in distcc and libofa, both of which use  
the default googlecode livecheck.regex.

I think the problematic line in port1.0/portlivecheck.tcl is:

set livecheck.regex [list "<a href=\"http://[quotemeta $ 
{livecheck.name}].googlecode.com/files/[quotemeta $ 
{livecheck.distname}]\""]

In particular: [quotemeta ${livecheck.distname}]

quotemeta is backslashing the (.*) so you get something like:

distcc\-\(\.\*\)\.tar\.bz2

From perry at macports.org  Fri Apr 24 23:30:13 2009
From: perry at macports.org (Perry Lee)
Date: Fri, 24 Apr 2009 23:30:13 -0700
Subject: googlecode livecheck
In-Reply-To: <F476FA2F-FAA7-450E-B1ED-7FB1DF8A52B1@macports.org>
References: <D5F9C694-CD0B-420D-AF63-DDB58D3FA5AA@lavergne.gotdns.org>
	<F476FA2F-FAA7-450E-B1ED-7FB1DF8A52B1@macports.org>
Message-ID: <00FAEEC5-0BE7-4F59-828E-6427084B3D6C@macports.org>

On Apr 24, 2009, at 11:12 PM, Perry Lee wrote:
> I think the problematic line in port1.0/portlivecheck.tcl is:
>
> set livecheck.regex [list "<a href=\"http://[quotemeta $ 
> {livecheck.name}].googlecode.com/files/[quotemeta $ 
> {livecheck.distname}]\""]
>
> In particular: [quotemeta ${livecheck.distname}]
>
> quotemeta is backslashing the (.*) so you get something like:
>
> distcc\-\(\.\*\)\.tar\.bz2

Fixed in r50093.

From ryandesign at macports.org  Sat Apr 25 02:20:32 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 25 Apr 2009 04:20:32 -0500
Subject: [50093] trunk/base/src/port1.0/portlivecheck.tcl
In-Reply-To: <20090425062810.B4DEF1658A9D@beta.macosforge.org>
References: <20090425062810.B4DEF1658A9D@beta.macosforge.org>
Message-ID: <ECEE7874-AE12-4654-8DB5-C6FFC9AA7D6D@macports.org>


On Apr 25, 2009, at 01:28, perry at macports.org wrote:

> Revision: 50093
>           http://trac.macports.org/changeset/50093
> Author:   perry at macports.org
> Date:     2009-04-24 23:28:08 -0700 (Fri, 24 Apr 2009)
> Log Message:
> -----------
> port1.0/portlivecheck.tcl:
> * (.*) should not be quotemeta-ed in the default googlecheck  
> livecheck.regex.

But the distfile name should be, shouldn't it?


> Modified Paths:
> --------------
>     trunk/base/src/port1.0/portlivecheck.tcl
>
> Modified: trunk/base/src/port1.0/portlivecheck.tcl
> ===================================================================
> --- trunk/base/src/port1.0/portlivecheck.tcl	2009-04-25 05:52:47  
> UTC (rev 50092)
> +++ trunk/base/src/port1.0/portlivecheck.tcl	2009-04-25 06:28:08  
> UTC (rev 50093)
> @@ -150,10 +150,10 @@
>                  set livecheck.url "http://code.google.com/p/$ 
> {livecheck.name}/downloads/list"
>              }
>              if {${livecheck.distname} eq "default"} {
> -                set livecheck.distname [regsub ***=$ 
> {livecheck.version} [file tail [lindex ${distfiles} 0]] (.*)]
> +                set livecheck.distname [regsub ***=[quotemeta $ 
> {livecheck.version}] [quotemeta [file tail [lindex ${distfiles}  
> 0]]] (.*)]
>              }
>              if {${livecheck.regex} eq ""} {
> -                set livecheck.regex [list "<a href=\"http:// 
> [quotemeta ${livecheck.name}].googlecode.com/files/[quotemeta $ 
> {livecheck.distname}]\""]
> +                set livecheck.regex [list "<a href=\"http:// 
> [quotemeta ${livecheck.name}].googlecode.com/files/$ 
> {livecheck.distname}\""]
>              }
>              set livecheck.check "regex"
>          }



From perry at macports.org  Sat Apr 25 02:22:57 2009
From: perry at macports.org (Perry Lee)
Date: Sat, 25 Apr 2009 02:22:57 -0700
Subject: [50093] trunk/base/src/port1.0/portlivecheck.tcl
In-Reply-To: <ECEE7874-AE12-4654-8DB5-C6FFC9AA7D6D@macports.org>
References: <20090425062810.B4DEF1658A9D@beta.macosforge.org>
	<ECEE7874-AE12-4654-8DB5-C6FFC9AA7D6D@macports.org>
Message-ID: <FA3495C2-3009-4990-A5AF-102840CF742E@macports.org>

On Apr 25, 2009, at 2:20 AM, Ryan Schmidt wrote:
> On Apr 25, 2009, at 01:28, perry at macports.org wrote:
>
>> Revision: 50093
>>          http://trac.macports.org/changeset/50093
>> Author:   perry at macports.org
>> Date:     2009-04-24 23:28:08 -0700 (Fri, 24 Apr 2009)
>> Log Message:
>> -----------
>> port1.0/portlivecheck.tcl:
>> * (.*) should not be quotemeta-ed in the default googlecheck  
>> livecheck.regex.
>
> But the distfile name should be, shouldn't it?

Right, it still is.  For example:

DEBUG: The regex is "<a href="http://distcc.googlecode.com/files/distcc 
\-(.*)\.tar\.bz2""

From jeremyhu at macports.org  Sat Apr 25 17:36:41 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Sat, 25 Apr 2009 17:36:41 -0700
Subject: lint version hardcode
Message-ID: <49F3AC99.4020209@macports.org>

Can this check please be updated to not report false-positives that are 
in comments?

-------- Original Message --------
Subject: 	[50117] firefox-x11-devel Lint Report
Date: 	Sat, 25 Apr 2009 17:22:35 -0700
From: 	noreply at macports.org
To: 	jeremyhu at macports.org, jeremyhu at macports.org



Portfile: firefox-x11-devel


Warning: Line 163 seems to hardcode the version number, consider using ${version} instead




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090425/48642004/attachment.html>

From jmr at macports.org  Sun Apr 26 07:36:54 2009
From: jmr at macports.org (Joshua Root)
Date: Mon, 27 Apr 2009 00:36:54 +1000
Subject: lint version hardcode
In-Reply-To: <49F3AC99.4020209@macports.org>
References: <49F3AC99.4020209@macports.org>
Message-ID: <49F47186.9080801@macports.org>

Jeremy Huddleston wrote:
> Can this check please be updated to not report false-positives that are
> in comments?

Done. The comment detection is technically not quite correct, as a line
that looks like a comment may not be because of the previous line, but I
think it will suffice.

- Josh

From ryandesign at macports.org  Sun Apr 26 14:45:41 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 26 Apr 2009 16:45:41 -0500
Subject: lint version hardcode
In-Reply-To: <49F3AC99.4020209@macports.org>
References: <49F3AC99.4020209@macports.org>
Message-ID: <BE26E68E-3613-42E2-8C07-8FF3737C44AC@macports.org>

On Apr 25, 2009, at 19:36, Jeremy Huddleston wrote:

>> Portfile: firefox-x11-devel Warning: Line 163 seems to hardcode  
>> the version number, consider using ${version} instead
>
> Can this check please be updated to not report false-positives that  
> are in comments?

I'm not sure this check should ever have been added to lint. lint is  
for reporting problems; this is not a problem but a stylistic issue.

If the check stays in lint, perhaps it should only be activated if  
the --nitpick option is used.



From raimue at macports.org  Sun Apr 26 16:28:25 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Mon, 27 Apr 2009 01:28:25 +0200
Subject: lint version hardcode
In-Reply-To: <BE26E68E-3613-42E2-8C07-8FF3737C44AC@macports.org>
References: <49F3AC99.4020209@macports.org>
	<BE26E68E-3613-42E2-8C07-8FF3737C44AC@macports.org>
Message-ID: <49F4EE19.4050501@macports.org>

Ryan Schmidt wrote:
> On Apr 25, 2009, at 19:36, Jeremy Huddleston wrote:
> 
>>> Portfile: firefox-x11-devel Warning: Line 163 seems to hardcode  
>>> the version number, consider using ${version} instead
>> Can this check please be updated to not report false-positives that  
>> are in comments?
> 
> I'm not sure this check should ever have been added to lint. lint is  
> for reporting problems; this is not a problem but a stylistic issue.
> 
> If the check stays in lint, perhaps it should only be activated if  
> the --nitpick option is used.

This was just an idea to avoid hardcoding the version in Portfiles as I
have seen it in the past.

I already said in the log message [1]:
Can be removed again if it gives too many false positives.

Now we identified one false positive by excluding comments. But I agree
that this is just stylistic, so feel free to either move it to --nitpick
only or even remove it completely.

Rainer

[1] http://trac.macports.org/changeset/49406

From raimue at macports.org  Sun Apr 26 17:17:46 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Mon, 27 Apr 2009 02:17:46 +0200
Subject: [49087] trunk/base/src/port1.0
In-Reply-To: <20090403113433.0476913FD9F0@beta.macosforge.org>
References: <20090403113433.0476913FD9F0@beta.macosforge.org>
Message-ID: <49F4F9AA.8020402@macports.org>

raimue at macports.org wrote:
> Revision: 49087
>           http://trac.macports.org/changeset/49087
> Author:   raimue at macports.org
> Date:     2009-04-03 04:34:32 -0700 (Fri, 03 Apr 2009)
> Log Message:
> -----------
> port1.0:
> Create namespaces for the packages in port1.0, stop polluting the global
> namespace with many local helper functions.

[...]

> Modified: trunk/base/src/port1.0/portfetch.tcl
> ===================================================================
> --- trunk/base/src/port1.0/portfetch.tcl	2009-04-03 11:19:09 UTC (rev 49086)
> +++ trunk/base/src/port1.0/portfetch.tcl	2009-04-03 11:34:32 UTC (rev 49087)

[...]

>  # Given a distname, return a suffix based on the use_zip / use_bzip2 / use_dmg / extract.suffix options
> -proc suffix {distname} {
> +proc portfetch::suffix {distname} {
>      global extract.suffix fetch.type
>      switch -- "${fetch.type}" {
>      	cvs			-
> @@ -181,6 +189,9 @@
>      	default 	{ return "${distname}${extract.suffix}" }
>      }
>  }
> +# XXX import suffix into the global namespace as it is currently used from
> +# Portfiles, but should better go somewhere else
> +namespace import portfetch::suffix

What should I do with this suffix proc? It is currently used in
Portfiles, so we still need to have this in the global namespace.

So It is not namespace internal, so having it in portfetch:: and then
importing it into the global namespace is not really appropriate. But as
it is hard tied to the supported fetch types, I don't want to move it to
portutil or similar.

Would it be okay to have this as a global namespace proc in portfetch.tcl?

Rainer

From nox at macports.org  Mon Apr 27 06:56:48 2009
From: nox at macports.org (nox)
Date: Mon, 27 Apr 2009 15:56:48 +0200
Subject: lint version hardcode
In-Reply-To: <49F4EE19.4050501@macports.org>
References: <49F3AC99.4020209@macports.org>
	<BE26E68E-3613-42E2-8C07-8FF3737C44AC@macports.org>
	<49F4EE19.4050501@macports.org>
Message-ID: <25920591-C535-4334-BE40-C64B2A86BF98@macports.org>

Le 27 avr. 09 ? 01:28, Rainer M?ller a ?crit :

> Ryan Schmidt wrote:
>> On Apr 25, 2009, at 19:36, Jeremy Huddleston wrote:
>>
>>>> Portfile: firefox-x11-devel Warning: Line 163 seems to hardcode
>>>> the version number, consider using ${version} instead
>>> Can this check please be updated to not report false-positives that
>>> are in comments?
>>
>> I'm not sure this check should ever have been added to lint. lint is
>> for reporting problems; this is not a problem but a stylistic issue.
>>
>> If the check stays in lint, perhaps it should only be activated if
>> the --nitpick option is used.
>
> This was just an idea to avoid hardcoding the version in Portfiles  
> as I
> have seen it in the past.
>
> I already said in the log message [1]:
> Can be removed again if it gives too many false positives.
>
> Now we identified one false positive by excluding comments. But I  
> agree
> that this is just stylistic, so feel free to either move it to -- 
> nitpick
> only or even remove it completely.
>
> Rainer
>

Using php5*extension also makes this lint test reports false positive as
php5extension.setup sets ${version} itself.

From dweber at macports.org  Mon Apr 27 10:51:29 2009
From: dweber at macports.org (Darren Weber)
Date: Mon, 27 Apr 2009 10:51:29 -0700
Subject: local repository config file?
Message-ID: <b808b3510904271051x506fa532h82b9ed22c3195433@mail.gmail.com>

For development of ports, we can use a local repository as a sandbox to test
port changes before adding back to the trunk.  Would it be possible to set
some general configuration options that apply to any ports from this local
repository?

For example, the local repo is at ~/ports and it contains a PortIndex file
and an entry in /opt/local/etc/macports/sources.conf

Is it possible to have a file with settings from macports.conf in the local
repo (say ~/ports/macports.conf)?  It might contain a subset of variables,
which would override the defaults in $prefix/etc/macports/macports.conf, to
provide specific settings only for ports from the local repository.

For example, it would be handy to set "portautoclean off" for the local dev
repo, but keep it on for the regular operation of macports.  We can use a
command line option for the dev port process (-k).  To make it the default
for the local repo, ~/ports/macports.conf might contain "portautoclean off"
(among other settings) and those settings would override the same settings
in the general $prefix config.  Any settings missing from
~/ports/macports.conf would be defined by the general $prefix config.

Best, Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090427/fd800396/attachment.html>

From ryandesign at macports.org  Mon Apr 27 11:30:12 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 27 Apr 2009 13:30:12 -0500
Subject: lint version hardcode
In-Reply-To: <25920591-C535-4334-BE40-C64B2A86BF98@macports.org>
References: <49F3AC99.4020209@macports.org>
	<BE26E68E-3613-42E2-8C07-8FF3737C44AC@macports.org>
	<49F4EE19.4050501@macports.org>
	<25920591-C535-4334-BE40-C64B2A86BF98@macports.org>
Message-ID: <6D371DB5-6D2B-4D7A-8AA0-754320D6381D@macports.org>

On Apr 27, 2009, at 08:56, nox wrote:

> Using php5*extension also makes this lint test reports false  
> positive as
> php5extension.setup sets ${version} itself.

I haven't run trunk in awhile so I haven't seen this problem yet.

php5extension.setup was modeled on other portgroups -- the ruby,  
haskell and perl portgroups do the same thing. Do they experience the  
same problem then too?


From nox at macports.org  Mon Apr 27 15:04:47 2009
From: nox at macports.org (nox)
Date: Tue, 28 Apr 2009 00:04:47 +0200
Subject: lint version hardcode
In-Reply-To: <6D371DB5-6D2B-4D7A-8AA0-754320D6381D@macports.org>
References: <49F3AC99.4020209@macports.org>
	<BE26E68E-3613-42E2-8C07-8FF3737C44AC@macports.org>
	<49F4EE19.4050501@macports.org>
	<25920591-C535-4334-BE40-C64B2A86BF98@macports.org>
	<6D371DB5-6D2B-4D7A-8AA0-754320D6381D@macports.org>
Message-ID: <64FDA033-AB77-4DB8-B58E-4285CED27663@macports.org>

Le 27 avr. 09 ? 20:30, Ryan Schmidt a ?crit :

> On Apr 27, 2009, at 08:56, nox wrote:
>
>> Using php5*extension also makes this lint test reports false  
>> positive as
>> php5extension.setup sets ${version} itself.
>
> I haven't run trunk in awhile so I haven't seen this problem yet.
>
> php5extension.setup was modeled on other portgroups -- the ruby,  
> haskell and perl portgroups do the same thing. Do they experience  
> the same problem then too?
>

I haven't looked at the source but I think it just searches ${version}  
in the Portfile after having read it, and triggers the warning if it's  
not the version command. So if I'm right, the answer is yes.

From dweber at macports.org  Mon Apr 27 16:32:06 2009
From: dweber at macports.org (Darren Weber)
Date: Mon, 27 Apr 2009 16:32:06 -0700
Subject: Fwd: [50222] vtk-devel Lint Report
In-Reply-To: <20090427232704.6ABC3280AD@relay11.apple.com>
References: <20090427232704.6ABC3280AD@relay11.apple.com>
Message-ID: <b808b3510904271632r46183ddet796d68114eb8a46a@mail.gmail.com>

How do we specify that a variant conflicts with several other variants.
Lint indicates a problem with this syntax:

variant carbon conflicts {cocoa x11} description {Build with Carbon} {
...
}

Should it be:

variant carbon conflicts cocoa x11 ...

or maybe:

variant carbon conflicts cocoa conflicts x11 ...


Thanks, Darren




---------- Forwarded message ----------
From: <noreply at macports.org>
Date: Mon, Apr 27, 2009 at 4:27 PM
Subject: [50222] vtk-devel Lint Report
To: dweber at macports.org


Portfile: vtk-devel


Warning: Variant carbon conflicts with non-existing variant cocoa x11
Warning: Variant cocoa conflicts with non-existing variant carbon x11
Warning: Variant x11 conflicts with non-existing variant cocoa carbon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090427/4dc2920c/attachment.html>

From perry at macports.org  Mon Apr 27 16:40:48 2009
From: perry at macports.org (Perry Lee)
Date: Mon, 27 Apr 2009 16:40:48 -0700
Subject: [50222] vtk-devel Lint Report
In-Reply-To: <b808b3510904271632r46183ddet796d68114eb8a46a@mail.gmail.com>
References: <20090427232704.6ABC3280AD@relay11.apple.com>
	<b808b3510904271632r46183ddet796d68114eb8a46a@mail.gmail.com>
Message-ID: <029BAC09-43D2-48E9-AFB8-B5DBD8DA3826@macports.org>

On Apr 27, 2009, at 4:32 PM, Darren Weber wrote:
> How do we specify that a variant conflicts with several other  
> variants.  Lint indicates a problem with this syntax:
>
> variant carbon conflicts {cocoa x11} description {Build with Carbon} {
> ...
> }


variant carbon conflicts cocoa x11 description {Build with Carbon} {
...
}

From dweber at macports.org  Mon Apr 27 16:43:36 2009
From: dweber at macports.org (Darren Weber)
Date: Mon, 27 Apr 2009 16:43:36 -0700
Subject: [50222] vtk-devel Lint Report
In-Reply-To: <029BAC09-43D2-48E9-AFB8-B5DBD8DA3826@macports.org>
References: <20090427232704.6ABC3280AD@relay11.apple.com>
	<b808b3510904271632r46183ddet796d68114eb8a46a@mail.gmail.com>
	<029BAC09-43D2-48E9-AFB8-B5DBD8DA3826@macports.org>
Message-ID: <b808b3510904271643m6fc72d1bs7d88800ebb13f7f4@mail.gmail.com>

Seems that the svn lint checker is different from the port lint checker, ie:

[ me at XXX ~/ports ]$ port lint vtk-devel
--->  Verifying Portfile for vtk-devel
--->  0 errors and 0 warnings found.





On Mon, Apr 27, 2009 at 4:40 PM, Perry Lee <perry at macports.org> wrote:

> On Apr 27, 2009, at 4:32 PM, Darren Weber wrote:
>
>> How do we specify that a variant conflicts with several other variants.
>>  Lint indicates a problem with this syntax:
>>
>> variant carbon conflicts {cocoa x11} description {Build with Carbon} {
>> ...
>> }
>>
>
>
> variant carbon conflicts cocoa x11 description {Build with Carbon} {
> ...
> }
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090427/48cc2e17/attachment.html>

From raimue at macports.org  Mon Apr 27 16:45:55 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Tue, 28 Apr 2009 01:45:55 +0200
Subject: lint version hardcode
In-Reply-To: <64FDA033-AB77-4DB8-B58E-4285CED27663@macports.org>
References: <49F3AC99.4020209@macports.org>
	<BE26E68E-3613-42E2-8C07-8FF3737C44AC@macports.org>
	<49F4EE19.4050501@macports.org>
	<25920591-C535-4334-BE40-C64B2A86BF98@macports.org>
	<6D371DB5-6D2B-4D7A-8AA0-754320D6381D@macports.org>
	<64FDA033-AB77-4DB8-B58E-4285CED27663@macports.org>
Message-ID: <49F643B3.2010701@macports.org>

nox wrote:
> I haven't looked at the source but I think it just searches ${version}  
> in the Portfile after having read it, and triggers the warning if it's  
> not the version command. So if I'm right, the answer is yes.

The regex currently being used for exclusion is
{^PortSystem|^PortGroup|^version|^(perl5|ruby|haskell).setup}

And I added php5extension.setup to it in r50226.

Rainer

From wsiegrist at apple.com  Mon Apr 27 16:59:50 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Mon, 27 Apr 2009 16:59:50 -0700
Subject: [50222] vtk-devel Lint Report
In-Reply-To: <b808b3510904271643m6fc72d1bs7d88800ebb13f7f4@mail.gmail.com>
References: <20090427232704.6ABC3280AD@relay11.apple.com>
	<b808b3510904271632r46183ddet796d68114eb8a46a@mail.gmail.com>
	<029BAC09-43D2-48E9-AFB8-B5DBD8DA3826@macports.org>
	<b808b3510904271643m6fc72d1bs7d88800ebb13f7f4@mail.gmail.com>
Message-ID: <32BF20FB-654B-4B08-BDAB-5BEC508C2497@apple.com>

On Apr 27, 2009, at 4:43 PM, Darren Weber wrote:

>
> Seems that the svn lint checker is different from the port lint  
> checker, ie:
>


The server uses a recent trunk build, so it could be different than  
your local version.

-Bill



From ryandesign at macports.org  Mon Apr 27 17:01:27 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 27 Apr 2009 19:01:27 -0500
Subject: [50222] trunk/dports/graphics
In-Reply-To: <20090427232702.18A15168F388@beta.macosforge.org>
References: <20090427232702.18A15168F388@beta.macosforge.org>
Message-ID: <5AB8AB79-1E8A-400E-BAA8-0E643BB68F72@macports.org>

On Apr 27, 2009, at 18:27, dweber at macports.org wrote:

> Revision: 50222
>           http://trac.macports.org/changeset/50222
> Author:   dweber at macports.org
> Date:     2009-04-27 16:27:01 -0700 (Mon, 27 Apr 2009)
> Log Message:
> -----------
> The default installation with shared libraries appears to work now;  
> still lots of work to be done on wrapping for java, python, tcl,  
> among other things.
>
> Added Paths:
> -----------
>     trunk/dports/graphics/vtk-devel/
>     trunk/dports/graphics/vtk-devel/Portfile
>
> Added: trunk/dports/graphics/vtk-devel/Portfile
> ===================================================================
> --- trunk/dports/graphics/vtk-devel/ 
> Portfile	                        (rev 0)
> +++ trunk/dports/graphics/vtk-devel/Portfile	2009-04-27 23:27:01  
> UTC (rev 50222)
> @@ -0,0 +1,437 @@
> +# -*- 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
> +
> +name        vtk-devel
> +version     5.4.0
> +revision    0
> +
> +set branch	[join [lrange [split ${version} .] 0 1] .]
> +
> +categories  graphics math science devel
> +
> +maintainers dweber openmaintainer
> +
> +description 3D visualization toolkit (www.vtk.org)
> +
> +long_description \
> +An open source, freely available software system for computer  
> graphics, \
> +image processing, and visualization used by thousands of  
> researchers and \
> +developers around the world. VTK consists of a C++ class library,  
> and \
> +several interpreted interface layers including Tcl/Tk, Java, and  
> Python. \
> +default_variants: +examples +testing +tclSys
> +
> +homepage        http://www.vtk.org/
> +master_sites    http://www.vtk.org/files/release/${branch}
> +
> +distname        vtk-${branch}
> +distfiles       vtk-${version}.tar.gz \
> +                vtkdata-${version}.tar.gz
> +
> +checksums       vtk-${version}.tar.gz \
> +                    md5  3e7c6d5c37602c935674d580a8dd43c0 \
> +                    sha1 a227caf932315d944cf72008d75df90dd4c554e7 \
> +                    rmd160 e2140fc35ed974f5fde6b418089554904e197c21 \
> +                vtkdata-${version}.tar.gz \
> +                    md5  283d40f3e499b3a6102d86855d2ca20b \
> +                    sha1 a710227e7f7f25f481a36d2fa14bda49756bd39d \
> +                    ripemd160  
> 160129a0580bd7b70b40d3f7fa61bbd78b586ad8
> +
> +platforms       darwin
> +
> +#depends_build   bin:cmake:cmake
> +depends_build   port:cmake \
> +                port:gmake
> +depends_lib     port:readline

Since this port uses cmake, have you considered using the cmake  
portgroup to simplify it?


> +# Using this dummy stage to inspect macport variables (using 'port  
> -d fetch vtk-devel')
> +#fetch { system "echo ${workbuildpath} && echo ${worksrcpath} &&  
> echo ${destroot}" }
> +
> +
> +# Build in a separate directory from the source
> +set workbuildpath   ${workpath}/${distname}-build
> +post-extract {
> +    system "cd ${workpath}; mv VTK ${distname}; mv VTKData $ 
> {distname}-data;"
> +    system "mkdir ${workbuildpath}"
> +}

You shouldn't use "system" for tasks which can be performed in plain  
Tcl.

move ${workpath}/VTK ${workpath}/${distname}
move ${workpath}/VTKData ${workpath}/${distname}-data
file mkdir ${workbuildpath}


> +configure {
> +    system "cd ${workbuildpath} && ${configure.env} && cmake $ 
> {configure.args} ${worksrcpath}"
> +}

configure.env is not a command; running it by itself doesn't have any  
effect, as far as I know. If you want those environment variables to  
have effect for the cmake command, you would not separate  
configure.env from the cmake command with "&&". However, see below:

> +build {
> +    system "cd ${workbuildpath} && gmake"
> +}
> +destroot {
> +    system "cd ${workbuildpath} && gmake install DESTDIR=${destroot}"
> +}

Why override all these phases? Using the cmake portgroup will take  
care of the configure phase for you, and the build and destroot  
phases are better implemented by just setting the relevant .cmd.

build.cmd gmake
destroot.cmd gmake

Actually you can omit "destroot.cmd gmake" since the default for  
destroot.cmd is the value of build.cmd.


> +# Set the equivalent of ${configure.ldflags} ${configure.cppflags}
> +# cmake also has variables called:
> +# CMAKE_LIBRARY_PATH_FLAG => specify -L compiler options
> +# CMAKE_LINK_LIBRARY_FLAG => specify -l compiler options
> +configure.env \
> +    LDFLAGS=-L${prefix}/lib \
> +    CXXFLAGS=-I${prefix}/include

MacPorts already sets LDFLAGS, CXXFLAGS and other variables for you.

> +# To double-check all the cmake variable settings after the configure
> +#cd ${workbuildpath}
> +#sudo cmake -LAH ../vtk-${branch} > ~/cmake_vars.txt
> +# Similarly, for an interactive configuration with ccmake, try:
> +#cd ${workbuildpath}
> +#sudo ccmake ../vtk-${branch}
> +
> +configure.args \
> +    -DBUILD_DOCUMENTATION:BOOL=OFF \
> +    -DBUILD_EXAMPLES:BOOL=OFF \
> +    -DBUILD_TESTING:BOOL=OFF \
> +    -DBUILD_SHARED_LIBS:BOOL=OFF \
> +    -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo \
> +    -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON \
> +    -DCMAKE_INSTALL_PREFIX:PATH=${prefix} \
> +    -DCMAKE_INCLUDE_PATH:PATH=${prefix}/include \
> +    -DCMAKE_LIBRARY_PATH:PATH=${prefix}/lib \
> +    -DCMAKE_INSTALL_NAME_DIR:STRING=${prefix}/lib/${distname} \
> +    -DVTK_DATA_ROOT:PATH=${prefix}/share/${distname}-data \
> +    -DVTK_DEBUG_LEAKS:BOOL=ON \
> +    -DVTK_USE_HYBRID:BOOL=ON \
> +    -DVTK_USE_COCOA:BOOL=ON \
> +    -DVTK_USE_CARBON:BOOL=OFF \
> +    -DVTK_USE_X:BOOL=OFF \
> +    -DVTK_USE_GUISUPPORT:BOOL=ON \
> +    -DVTK_USE_INFOVIS:BOOL=ON \
> +    -DVTK_USE_PARALLEL:BOOL=ON \
> +    -DVTK_USE_RENDERING:BOOL=ON \
> +    -DVTK_USE_VIEWS:BOOL=ON \
> +    -DVTK_WRAP_TCL:BOOL=OFF \
> +    -DVTK_WRAP_JAVA:BOOL=OFF \
> +    -DVTK_WRAP_PYTHON:BOOL=OFF
> +
> +
> +    #-DVTK_USE_RPATH:BOOL=OFF \
> +    #-DVTK_REQUIRED_EXE_LINKER_FLAGS:STRING=-rpath ${prefix}/lib \
> +    #-DCMAKE_EXE_LINKER_FLAGS:STRING=-rpath ${prefix}/lib \
> +
> +
> +
> +# PLATFORMS: platform darwin <version>
> +# Can be used to handle different tasks depending
> +# on the version of Mac OS X.  The version can be:
> +# 6 for 10.2 Jaguar,
> +# 7 for 10.3 Panther,
> +# 8 for 10.4 Tiger, or
> +# 9 for 10.5 Leopard.
> +
> +platform darwin 8 {
> +    # I have not tested this [dweber]
> +    depends_build-append \
> +        port:gcc40
> +    configure.env-append \
> +        CC=/usr/bin/gcc-4.0 \
> +        CXX=/usr/bin/cpp-4.0 \
> +        MACOSX_DEPLOYMENT_TARGET=10.4
> +}

Why require port gcc40? Is the gcc 4.0.1 Apple provides with Xcode  
insufficient? If so, and a MacPorts gcc is truly required, you should  
use the latest stable version, which is currently gcc44.

MacPorts already sets MACOSX_DEPLOYMENT_TARGET for you.

> +#VTK_REQUIRED_OBJCXX_FLAGS "-fobjc-gc"
> +# When building VTK with Cocoa, in 10.5, Cocoa supports two memory  
> models:
> +# reference counting and garbage collection. This compiler flag  
> lets it work with both.
> +platform darwin 9 {
> +    configure.env-append \
> +        MACOSX_DEPLOYMENT_TARGET=10.5
> +    configure.args-append \
> +        VTK_REQUIRED_OBJCXX_FLAGS="-fobjc-gc"
> +}
> +
> +
> +# ------------------------------------------------------------------
> +# VARIANTS
> +#
> +# variant name [requires variant] [conflicts variant] [description  
> description]
> +
> +default_variants \
> +    +cocoa \
> +    +data \
> +    +examples \
> +    +shared
> +
> +variant data description {Install the example data [default]} {
> +}
> +
> +
> +variant doc description {Build the doxygen documentation} {
> +    depends_build-append \
> +        port:doxygen
> +    configure.args-append \
> +        -DBUILD_DOCUMENTATION:BOOL=ON
> +}
> +
> +
> +variant examples description {Build and install VTK examples  
> [default]} {
> +    configure.args-delete \
> +        -DBUILD_EXAMPLES:BOOL=OFF
> +    configure.args-append \
> +        -DBUILD_EXAMPLES:BOOL=ON
> +}

Having fewer variants is better, and since you already make +data and  
+examples default variants, why not just incorporate them into the  
port proper and remove the variants?

I would also prefer that the port have no default variants. If  
something should be in the port by default, make it so; if necessary,  
offer variants to turn the feature off again, e.g. a "no_shared" or a  
"no_data" variant. However think carefully about whether anyone  
really needs to turn that feature off. If not, don't give the option.


> +variant testing description {Build VTK tests} {
> +    configure.args-delete \
> +        -DBUILD_TESTING:BOOL=OFF
> +    configure.args-append \
> +        -DBUILD_TESTING:BOOL=ON
> +}
> +
> +
> +variant tclSys conflicts tclMacPorts description {Tcl Wrapper  
> (System Tcl/Tk)} {

Having capital letters in variant names is unusual. Other ports use  
underscore-separated lowercase words. To distinguish between a  
MacPorts library and a system library, I would prefer that the  
variant that uses the MacPorts library have no special suffix, and  
the variant that uses the system library have the _apple suffix.

variant tcl_apple conflicts tcl {...}
variant tcl conflicts tcl_apple {...}

> +    configure.args-delete \
> +        -DVTK_WRAP_TCL:BOOL=OFF
> +    configure.args-append \
> +        -DVTK_WRAP_TCL:BOOL=ON \
> +        -DTCL_TCLSH:FILEPATH=/usr/bin/tclsh \
> +        -DTCL_INCLUDE_PATH:PATH=/System/Library/Frameworks/ 
> Tcl.framework/Headers \
> +        -DTCL_LIBRARY:FILEPATH=/System/Library/Frameworks/ 
> tcl.framework \
> +        -DTK_INCLUDE_PATH:PATH=/System/Library/Frameworks/ 
> Tk.framework/Headers \
> +        -DTK_LIBRARY:FILEPATH=/System/Library/Frameworks/tk.framework
> +}
> +
> +# This provides a tcl variant that uses the macports tcl  
> installation. (It seems
> +# vtk 5.2 does not work with tcl8.5 - macports has 8.5, as of Sep  
> 2008).
> +variant tclMacPorts conflicts tclSys description {Tcl Wrapper  
> (MacPorts Tcl/Tk)} {
> +    depends_lib-append \
> +        port:tcl \
> +        port:tk
> +    configure.args-delete \
> +        -DVTK_WRAP_TCL:BOOL=OFF
> +    configure.args-append \
> +        -DVTK_WRAP_TCL:BOOL=ON \
> +        -DTCL_TCLSH:FILEPATH=${prefix}/bin/tclsh \
> +        -DTCL_INCLUDE_PATH:PATH=${prefix}/include \
> +        -DTCL_LIBRARY:FILEPATH=${prefix}/lib \
> +        -DTK_INCLUDE_PATH:PATH=${prefix}/include \
> +        -DTK_LIBRARY:FILEPATH=${prefix}/lib
> +}
> +# /opt/local/lib/tclConfig.sh
> +# /opt/local/lib/tkConfig.sh
> +
> +
> +variant java description {Java wrapping for VTK} {
> +    configure.args-append \
> +        -DVTK_WRAP_JAVA:BOOL=ON
> +}

This requires no additional dependency? If so, why not enable this  
feature always and remove the variant?


> +variant python requires shared description {Python Wrapping for  
> VTK} {
> +   depends_build-append    port:python26
> +   configure.args-delete \
> +       -DVTK_WRAP_PYTHON:BOOL=OFF \
> +   configure.args-append \
> +       -DVTK_WRAP_PYTHON:BOOL=ON \
> +       -DVTK_NO_PYTHON_THREADS:BOOL=OFF \
> +       -DPYTHON_INCLUDE_PATH:FILEPATH=${prefix}/include/python2.6 \
> +       -DPYTHON_LIBRARY:FILEPATH=${prefix}/lib/libpython2.6.dylib \
> +       -DPYTHON_DEBUG_LIBRARY:FILEPATH=${prefix}/lib/ 
> libpython2.6.dylib \
> +       -DPYTHON_EXECUTABLE:FILEPATH=${prefix}/bin/python2.6 \
> +       -DVTK_PYTHON_SETUP_ARGS:STRING="--prefix=${prefix} --root=$ 
> {destdir}"
> +}

You may want to call the variant python26 so that you can later offer  
other variants for other versions of python.


> +
> +
> +# ---------------------------------------------------------
> +# There is a problem with RPATH config for the shared libs.
> +# Until this is fixed, it will not be a default variant.

But you have made it a default variant. See above.

> +variant shared description {Build shared libraries [default]} {
> +    configure.args-delete \
> +        -DBUILD_SHARED_LIBS:BOOL=OFF
> +    configure.args-append \
> +        -DBUILD_SHARED_LIBS:BOOL=ON \
> +        -DCMAKE_SKIP_BUILD_RPATH:BOOL=ON \
> +        -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON \
> +        -DCMAKE_INSTALL_RPATH:STRING=${prefix}/lib/${distname} \
> +        -DVTK_USE_RPATH:BOOL=ON
> +}
> +
> +# CMAKE_EXE_LINKER_FLAGS:STRING=
> +
> +#  -DVTK_INSTALL_LIB_DIR:STRING=${prefix}/lib/vtk-5.2
> +#  -DVTK_USE_RPATH=ON \
> +#  -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=OFF \
> +
> +# -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON \
> +# Cannot use this RPATH setting because the build tree is
> +# used to bootstrap the build process, eg:
> +#
> +#[  4%] Generating vtkGLSLShaderLibrary.h
> +#dyld: Library not loaded: "/opt/local/lib/vtk-5.2"/libvtksys. 
> 5.2.dylib
> +#  Referenced from: /opt/local/var/macports/build/ 
> _Users_dweber_ports_graphics_vtk5/work/VTK/Utilities/ 
> MaterialLibrary/../../bin/ProcessShader
> +#  Reason: image not found
> +
> +# Might need variants for carbon vs. cocoa.  When doing a shared  
> library
> +# build, must use carbon, not cocoa.
> +
> +
> +variant carbon conflicts {cocoa x11} description {Build with  
> Carbon} {

So we have the choice between carbon, cocoa, and x11, and only 1 can  
be chosen. But you have made cocoa a default variant. You should only  
make cocoa the default variant if x11 or carbon have not already been  
chosen. See any of several ports for examples of how to handle this,  
such as minivmac or pdftk.

> +    configure.args-delete   \
> +        -DVTK_USE_COCOA:BOOL=ON \
> +        -DVTK_USE_CARBON:BOOL=OFF
> +    configure.args-append   \
> +        -DVTK_USE_COCOA:BOOL=OFF \
> +        -DVTK_USE_CARBON:BOOL=ON \
> +}
> +
> +
> +variant cocoa conflicts {carbon x11} description {Build with Cocoa  
> [Default]} {
> +}
> +
> +
> +variant x11 conflicts {cocoa carbon} description {Build with X11} {
> +    #depends_build-append    \
> +        port:xorg-libs \
> +        port:xorg-proto
> +    configure.args-delete   \
> +        -DVTK_USE_COCOA:BOOL=ON \
> +        -DVTK_USE_X:BOOL=OFF
> +    configure.args-append   \
> +        -DVTK_USE_COCOA:BOOL=OFF \
> +        -DVTK_USE_X:BOOL=ON \
> +        -DOPENGL_gl_LIBRARY:FILEPATH=${x11prefix}/lib/libGL.dylib \
> +        -DOPENGL_glu_LIBRARY:FILEPATH=${x11prefix}/lib/libGLU.dylib \
> +        -DOPENGL_INCLUDE_DIR:PATH=${x11prefix}/include \
> +        -DVTK_GLEXT_FILE:FILEPATH=${x11prefix}/include/GL/glext.h \
> +        -DVTK_GLXEXT_FILE:FILEPATH=${x11prefix}/include/GL/glxext.h
> +        -DVTK_OPENGL_HAS_OSMESA:BOOL=OFF
> +}

You're using items from ${x11prefix} but we now have X11 in $ 
{prefix}. The mesa port provides libGL.dylib and so forth. As I see  
you realize below. We have had the convention of the +x11 variant  
using the MacPorts x11 and the +system_x11 variant using the Apple  
X11. Though we may remove +system_x11 soon and no longer offer the  
option.


> +# This mesaOpenGL variant may not require the x11 variant, but the
> +# assumption here is that it's more likely to work with it than  
> without it.
> +
> +variant mesaOpenGL requires {x11} description {Use mesa OpenGL} {
> +    depends_build-append \
> +        port:mesa
> +    configure.args-append \
> +        -DOPENGL_INCLUDE_DIR:PATH=${prefix}/include \
> +        -DOPENGL_gl_LIBRARY:FILEPATH=${prefix}/lib/libGL.dylib \
> +        -DOPENGL_glu_LIBRARY:FILEPATH=${prefix}/lib/libGLU.dylib \
> +        -DVTK_GLEXT_FILE:FILEPATH=${prefix}/include/GL/glext.h \
> +        -DVTK_GLXEXT_FILE:FILEPATH=${prefix}/include/GL/glxext.h \
> +        -DVTK_OPENGL_HAS_OSMESA:BOOL=ON
> +}
> +
> +
> +variant mpi description {Use message passing interface (MPI) for  
> parallel support} {
> +    depends_lib-append \
> +        port:mpich2
> +    configure.args-append \
> +        -DVTK_USE_MPI:BOOL=ON
> +}
> +
> +
> +variant mysql description {Build the MySQL driver for  
> vtkSQLDatabase} {
> +    depends_build-append \
> +        port:mysql5

Please use path:bin/mysql_config5:mysql5 for any mysql5 dependency,  
so that mysql5-devel would also be able to satisfy it.

> +    configure.args-append \
> +        -DVTK_USE_MYSQL:BOOL=ON
> +}
> +
> +
> +variant pgsql description {Build the PostgreSQL driver for  
> vtkSQLDatabase} {
> +    depends_build-append \
> +        port:libpqxx
> +    configure.args-append \
> +        -DVTK_USE_POSTGRES:BOOL=ON
> +}
> +
> +
> +variant odbc description {Build the ODBC database interface} {
> +    depends_build-append \
> +        port:unixODBC
> +    configure.args-append \
> +        -DVTK_USE_ODBC:BOOL=ON
> +}
> +
> +
> +# ------------------------------------------------------------------
> +# POST DESTROOT
> +
> +set vtkDocPath  ${destroot}${prefix}/share/doc/${distname}
> +set vtkDataPath ${destroot}${prefix}/share/${distname}-data
> +
> +# Define variables used by install_name_tool for
> +# the shared libary installation RPATH
> +set libdestStr ${destroot}${prefix}/bin/libvtk
> +set libinstStr ${prefix}/lib/${distname}/libvtk
> +
> +post-destroot {
> +
> +    # Provide data files
> +    xinstall -d -m 0755 ${vtkDataPath}
> +    system "tar -C ${vtkDataPath} -zxvf ${distpath}/vtkdata-$ 
> {version}.tar.gz"
> +    system "mv ${vtkDataPath}/VTKData/* ${vtkDataPath}/"
> +    system "rm -rf ${vtkDataPath}/VTKData"
> +
> +    # Add basic documentation
> +    xinstall -d -m 0755 ${vtkDocPath}
> +    file copy ${worksrcpath}/README.html   ${vtkDocPath}
> +    file copy ${worksrcpath}/Copyright.txt ${vtkDocPath}
> +    file copy ${worksrcpath}/Testing.txt   ${vtkDocPath}
> +
> +    # Copy examples to the documentation path
> +    if {[variant_isset examples]} {
> +        file copy ${worksrcpath}/Examples ${vtkDocPath}
> +    }
> +
> +    # Provide some tests in the documentation path
> +    if {[variant_isset testing]} {
> +        foreach x { \
> +            CommonCxxTests \
> +            FilteringCxxTests \
> +            GenericFilteringCxxTests \
> +            GraphicsCxxTests \
> +            IOCxxTests \
> +            ImagingCxxTests \
> +            RenderingCxxTests \
> +            TestCxxFeatures \
> +            TestInstantiator \
> +            VTKBenchMark \
> +            VolumeRenderingCxxTests \
> +            WidgetsCxxTests } \
> +        {
> +            file copy ${worksrcpath}/bin/$x ${vtkDocPath}/Examples
> +        }
> +    }
> +
> +    #if {[variant_isset shared]} {
> +        # Must set RPATH on all .dylib for shared variant; the  
> RPATH settings
> +        # in the build are hi-jacked by the DESTDIR set by  
> macports during
> +        # 'make install'.  Add some system code here to correct  
> the RPATH
> +        # settings for shared libs?  Perhaps add the system code  
> to the shared
> +        # variant only.
> +
> +        # Use install_name_tool to change the
> +        # RPATH settings for each .dylib file.
> +
> +        # This doesn't work!
> +        #system "cd ${destroot}${prefix}/bin; install_name_tool - 
> change $libdestStr $libinstStr $*{version}.dylib"
> +        # See
> +        # http://qin.laya.com/tech_coding_help/dylib_linking.html
> +
> +        #for f in `otool -L libvtkRendering.5.2.0.dylib`; do
> +        #    echo $f | grep $libdestStr;
> +        #done
> +
> +        # otool -L ${dylib} | grep ${libdestStr} | sed  
> s/.dylib.*/.dylib/
> +
> +        # http://guide.macports.org/chunked/reference.phases.html
> +        # During the destroot phase, macports issues:
> +        # make install DESTDIR=${destroot}
> +        # in ${worksrcpath}.
> +    #}
> +}

It would be easier to understand the port if you put the parts that  
are specific to a variant inside that variant declaration.

So, instead of what you have:


variant examples {
     ...
}
variant testing {
     ...
}
variant shared {
     ...
}
post-destroot {
     ...
     if {[variant_isset examples]} {
         ...
     }
     if {[variant_isset testing]} {
         ...
     }
     if {[variant_isset shared]} {
         ...
     }
}


Do this:


variant examples {
     ...
     post-destroot {
         ...
     }
}
variant testing {
     ...
     post-destroot {
         ...
     }
}
variant shared {
     ...
     post-destroot {
         ...
     }
}
post-destroot {
     ...
}



From ryandesign at macports.org  Mon Apr 27 17:04:45 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 27 Apr 2009 19:04:45 -0500
Subject: lint version hardcode
In-Reply-To: <49F643B3.2010701@macports.org>
References: <49F3AC99.4020209@macports.org>
	<BE26E68E-3613-42E2-8C07-8FF3737C44AC@macports.org>
	<49F4EE19.4050501@macports.org>
	<25920591-C535-4334-BE40-C64B2A86BF98@macports.org>
	<6D371DB5-6D2B-4D7A-8AA0-754320D6381D@macports.org>
	<64FDA033-AB77-4DB8-B58E-4285CED27663@macports.org>
	<49F643B3.2010701@macports.org>
Message-ID: <237195A0-9F50-4D9C-A760-2F9FFE789D7E@macports.org>


On Apr 27, 2009, at 18:45, Rainer M?ller wrote:

> nox wrote:
>> I haven't looked at the source but I think it just searches $ 
>> {version}
>> in the Portfile after having read it, and triggers the warning if  
>> it's
>> not the version command. So if I'm right, the answer is yes.
>
> The regex currently being used for exclusion is
> {^PortSystem|^PortGroup|^version|^(perl5|ruby|haskell).setup}
>
> And I added php5extension.setup to it in r50226.

Ok, I added php5peclextension.setup in r50230. I didn't realize we  
had this list of portgroups in portlint. Can't we just make it accept  
any ${portgroup}.setup?



From dweber at macports.org  Mon Apr 27 17:48:30 2009
From: dweber at macports.org (Darren Weber)
Date: Mon, 27 Apr 2009 17:48:30 -0700
Subject: [50222] trunk/dports/graphics
In-Reply-To: <5AB8AB79-1E8A-400E-BAA8-0E643BB68F72@macports.org>
References: <20090427232702.18A15168F388@beta.macosforge.org>
	<5AB8AB79-1E8A-400E-BAA8-0E643BB68F72@macports.org>
Message-ID: <b808b3510904271748w2cca31b4t935e28108ee4cbf7@mail.gmail.com>

On Mon, Apr 27, 2009 at 5:01 PM, Ryan Schmidt <ryandesign at macports.org>wrote:

> On Apr 27, 2009, at 18:27, dweber at macports.org wrote:
>
>  Revision: 50222
>>          http://trac.macports.org/changeset/50222
>> Author:   dweber at macports.org
>> Date:     2009-04-27 16:27:01 -0700 (Mon, 27 Apr 2009)
>> Log Message:
>> -----------
>> The default installation with shared libraries appears to work now; still
>> lots of work to be done on wrapping for java, python, tcl, among other
>> things.
>>
>> Added Paths:
>> -----------
>>    trunk/dports/graphics/vtk-devel/
>>    trunk/dports/graphics/vtk-devel/Portfile
>>
>> Added: trunk/dports/graphics/vtk-devel/Portfile
>> ===================================================================
>> --- trunk/dports/graphics/vtk-devel/Portfile
>>  (rev 0)
>> +++ trunk/dports/graphics/vtk-devel/Portfile    2009-04-27 23:27:01 UTC
>> (rev 50222)
>> @@ -0,0 +1,437 @@
>> +# -*- 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
>> +
>> +name        vtk-devel
>> +version     5.4.0
>> +revision    0
>> +
>> +set branch     [join [lrange [split ${version} .] 0 1] .]
>> +
>> +categories  graphics math science devel
>> +
>> +maintainers dweber openmaintainer
>> +
>> +description 3D visualization toolkit (www.vtk.org)
>> +
>> +long_description \
>> +An open source, freely available software system for computer graphics, \
>> +image processing, and visualization used by thousands of researchers and
>> \
>> +developers around the world. VTK consists of a C++ class library, and \
>> +several interpreted interface layers including Tcl/Tk, Java, and Python.
>> \
>> +default_variants: +examples +testing +tclSys
>> +
>> +homepage        http://www.vtk.org/
>> +master_sites    http://www.vtk.org/files/release/${branch}<http://www.vtk.org/files/release/$%7Bbranch%7D>
>> +
>> +distname        vtk-${branch}
>> +distfiles       vtk-${version}.tar.gz \
>> +                vtkdata-${version}.tar.gz
>> +
>> +checksums       vtk-${version}.tar.gz \
>> +                    md5  3e7c6d5c37602c935674d580a8dd43c0 \
>> +                    sha1 a227caf932315d944cf72008d75df90dd4c554e7 \
>> +                    rmd160 e2140fc35ed974f5fde6b418089554904e197c21 \
>> +                vtkdata-${version}.tar.gz \
>> +                    md5  283d40f3e499b3a6102d86855d2ca20b \
>> +                    sha1 a710227e7f7f25f481a36d2fa14bda49756bd39d \
>> +                    ripemd160 160129a0580bd7b70b40d3f7fa61bbd78b586ad8
>> +
>> +platforms       darwin
>> +
>> +#depends_build   bin:cmake:cmake
>> +depends_build   port:cmake \
>> +                port:gmake
>> +depends_lib     port:readline
>>
>
> Since this port uses cmake, have you considered using the cmake portgroup
> to simplify it?
>



No, I didn't know such a portgroup exists and I have no idea how to use a
portgroup.




>
>
>  +# Using this dummy stage to inspect macport variables (using 'port -d
>> fetch vtk-devel')
>> +#fetch { system "echo ${workbuildpath} && echo ${worksrcpath} && echo
>> ${destroot}" }
>> +
>> +
>> +# Build in a separate directory from the source
>> +set workbuildpath   ${workpath}/${distname}-build
>> +post-extract {
>> +    system "cd ${workpath}; mv VTK ${distname}; mv VTKData
>> ${distname}-data;"
>> +    system "mkdir ${workbuildpath}"
>> +}
>>
>
> You shouldn't use "system" for tasks which can be performed in plain Tcl.
>
> move ${workpath}/VTK ${workpath}/${distname}
> move ${workpath}/VTKData ${workpath}/${distname}-data
> file mkdir ${workbuildpath}



OK, will adopt this change.



 +configure {
>> +    system "cd ${workbuildpath} && ${configure.env} && cmake
>> ${configure.args} ${worksrcpath}"
>> +}
>>
>
> configure.env is not a command; running it by itself doesn't have any
> effect, as far as I know. If you want those environment variables to have
> effect for the cmake command, you would not separate configure.env from the
> cmake command with "&&".



configure.env settings will be dropped, completely (see your comment below
also).



> However, see below:
>
>  +build {
>> +    system "cd ${workbuildpath} && gmake"
>> +}
>> +destroot {
>> +    system "cd ${workbuildpath} && gmake install DESTDIR=${destroot}"
>> +}
>>
>
> Why override all these phases? Using the cmake portgroup will take care of
> the configure phase for you, and the build and destroot phases are better
> implemented by just setting the relevant .cmd.
>
> build.cmd gmake
> destroot.cmd gmake
>
> Actually you can omit "destroot.cmd gmake" since the default for
> destroot.cmd is the value of build.cmd.




It's possibly pedantic to be explicit about using gmake, but there it is.
The option to set build.cmd occurred to me.  However, the default build
location is ${worksrcpath} and I want to use an out-of-source build path,
hence the specification to "cd ${workbuildpath}".  The reason is that I hope
to be able to install both static and dynamic libraries from this vtk port
and it might be wise to build out of source into several different build
paths.  The current incarnation uses only a dynamic build by default.  It
should be possible to add a +static variant that doesn't conflict with the
dynamic build.  I expect this will be built into ${workstaticbuildpath}.

I don't see any variable settings for doing out-of-source builds in
macports.  So, the overrides may stand as is.




>  +# Set the equivalent of ${configure.ldflags} ${configure.cppflags}
>> +# cmake also has variables called:
>> +# CMAKE_LIBRARY_PATH_FLAG => specify -L compiler options
>> +# CMAKE_LINK_LIBRARY_FLAG => specify -l compiler options
>> +configure.env \
>> +    LDFLAGS=-L${prefix}/lib \
>> +    CXXFLAGS=-I${prefix}/include
>>
>
> MacPorts already sets LDFLAGS, CXXFLAGS and other variables for you.
>
>  +# To double-check all the cmake variable settings after the configure
>> +#cd ${workbuildpath}
>> +#sudo cmake -LAH ../vtk-${branch} > ~/cmake_vars.txt
>> +# Similarly, for an interactive configuration with ccmake, try:
>> +#cd ${workbuildpath}
>> +#sudo ccmake ../vtk-${branch}
>> +
>> +configure.args \
>> +    -DBUILD_DOCUMENTATION:BOOL=OFF \
>> +    -DBUILD_EXAMPLES:BOOL=OFF \
>> +    -DBUILD_TESTING:BOOL=OFF \
>> +    -DBUILD_SHARED_LIBS:BOOL=OFF \
>> +    -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo \
>> +    -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON \
>> +    -DCMAKE_INSTALL_PREFIX:PATH=${prefix} \
>> +    -DCMAKE_INCLUDE_PATH:PATH=${prefix}/include \
>> +    -DCMAKE_LIBRARY_PATH:PATH=${prefix}/lib \
>> +    -DCMAKE_INSTALL_NAME_DIR:STRING=${prefix}/lib/${distname} \
>> +    -DVTK_DATA_ROOT:PATH=${prefix}/share/${distname}-data \
>> +    -DVTK_DEBUG_LEAKS:BOOL=ON \
>> +    -DVTK_USE_HYBRID:BOOL=ON \
>> +    -DVTK_USE_COCOA:BOOL=ON \
>> +    -DVTK_USE_CARBON:BOOL=OFF \
>> +    -DVTK_USE_X:BOOL=OFF \
>> +    -DVTK_USE_GUISUPPORT:BOOL=ON \
>> +    -DVTK_USE_INFOVIS:BOOL=ON \
>> +    -DVTK_USE_PARALLEL:BOOL=ON \
>> +    -DVTK_USE_RENDERING:BOOL=ON \
>> +    -DVTK_USE_VIEWS:BOOL=ON \
>> +    -DVTK_WRAP_TCL:BOOL=OFF \
>> +    -DVTK_WRAP_JAVA:BOOL=OFF \
>> +    -DVTK_WRAP_PYTHON:BOOL=OFF
>> +
>> +
>> +    #-DVTK_USE_RPATH:BOOL=OFF \
>> +    #-DVTK_REQUIRED_EXE_LINKER_FLAGS:STRING=-rpath ${prefix}/lib \
>> +    #-DCMAKE_EXE_LINKER_FLAGS:STRING=-rpath ${prefix}/lib \
>> +
>> +
>> +
>> +# PLATFORMS: platform darwin <version>
>> +# Can be used to handle different tasks depending
>> +# on the version of Mac OS X.  The version can be:
>> +# 6 for 10.2 Jaguar,
>> +# 7 for 10.3 Panther,
>> +# 8 for 10.4 Tiger, or
>> +# 9 for 10.5 Leopard.
>> +
>> +platform darwin 8 {
>> +    # I have not tested this [dweber]
>> +    depends_build-append \
>> +        port:gcc40
>> +    configure.env-append \
>> +        CC=/usr/bin/gcc-4.0 \
>> +        CXX=/usr/bin/cpp-4.0 \
>> +        MACOSX_DEPLOYMENT_TARGET=10.4
>> +}
>>
>
> Why require port gcc40? Is the gcc 4.0.1 Apple provides with Xcode
> insufficient? If so, and a MacPorts gcc is truly required, you should use
> the latest stable version, which is currently gcc44.
>
> MacPorts already sets MACOSX_DEPLOYMENT_TARGET for you.



That platform variant was adapted from vtk5, sounds like it can be dropped
as macports will deal with it automatically.



>
>  +#VTK_REQUIRED_OBJCXX_FLAGS "-fobjc-gc"
>> +# When building VTK with Cocoa, in 10.5, Cocoa supports two memory
>> models:
>> +# reference counting and garbage collection. This compiler flag lets it
>> work with both.
>> +platform darwin 9 {
>> +    configure.env-append \
>> +        MACOSX_DEPLOYMENT_TARGET=10.5
>> +    configure.args-append \
>> +        VTK_REQUIRED_OBJCXX_FLAGS="-fobjc-gc"
>> +}
>> +
>> +
>> +# ------------------------------------------------------------------
>> +# VARIANTS
>> +#
>> +# variant name [requires variant] [conflicts variant] [description
>> description]
>> +
>> +default_variants \
>> +    +cocoa \
>> +    +data \
>> +    +examples \
>> +    +shared
>> +
>> +variant data description {Install the example data [default]} {
>> +}
>> +
>> +
>> +variant doc description {Build the doxygen documentation} {
>> +    depends_build-append \
>> +        port:doxygen
>> +    configure.args-append \
>> +        -DBUILD_DOCUMENTATION:BOOL=ON
>> +}
>> +
>> +
>> +variant examples description {Build and install VTK examples [default]} {
>> +    configure.args-delete \
>> +        -DBUILD_EXAMPLES:BOOL=OFF
>> +    configure.args-append \
>> +        -DBUILD_EXAMPLES:BOOL=ON
>> +}
>>
>
> Having fewer variants is better, and since you already make +data and
> +examples default variants, why not just incorporate them into the port
> proper and remove the variants?



Simple -- choice.  Anyone can select -data or -examples, but only if they
are variants.



>
> I would also prefer that the port have no default variants. If something
> should be in the port by default, make it so; if necessary, offer variants
> to turn the feature off again, e.g. a "no_shared" or a "no_data" variant.
> However think carefully about whether anyone really needs to turn that
> feature off. If not, don't give the option.



Probably a difference of opinion or just a matter of style.  Using default
variants allows other ports to get "essential" features without having to
depend on any variant.  Users can switch it off with -<variant> and I prefer
to stick with +<variant> or -<variant> rather than introduce double
negatives like +<no_variant>.  Furthermore, the variant syntax provides
additional benefits, like description information to 'port variants
<portname>' and the capacity to specify requires and conflicts, with
additional stage processing options within the variant.



>
>
>  +variant testing description {Build VTK tests} {
>> +    configure.args-delete \
>> +        -DBUILD_TESTING:BOOL=OFF
>> +    configure.args-append \
>> +        -DBUILD_TESTING:BOOL=ON
>> +}
>> +
>> +
>> +variant tclSys conflicts tclMacPorts description {Tcl Wrapper (System
>> Tcl/Tk)} {
>>
>
> Having capital letters in variant names is unusual. Other ports use
> underscore-separated lowercase words. To distinguish between a MacPorts
> library and a system library, I would prefer that the variant that uses the
> MacPorts library have no special suffix, and the variant that uses the
> system library have the _apple suffix.
>
> variant tcl_apple conflicts tcl {...}
> variant tcl conflicts tcl_apple {...}
>


OK, will adopt as specified.





>
>  +    configure.args-delete \
>> +        -DVTK_WRAP_TCL:BOOL=OFF
>> +    configure.args-append \
>> +        -DVTK_WRAP_TCL:BOOL=ON \
>> +        -DTCL_TCLSH:FILEPATH=/usr/bin/tclsh \
>> +
>>  -DTCL_INCLUDE_PATH:PATH=/System/Library/Frameworks/Tcl.framework/Headers \
>> +        -DTCL_LIBRARY:FILEPATH=/System/Library/Frameworks/tcl.framework \
>> +
>>  -DTK_INCLUDE_PATH:PATH=/System/Library/Frameworks/Tk.framework/Headers \
>> +        -DTK_LIBRARY:FILEPATH=/System/Library/Frameworks/tk.framework
>> +}
>> +
>> +# This provides a tcl variant that uses the macports tcl installation.
>> (It seems
>> +# vtk 5.2 does not work with tcl8.5 - macports has 8.5, as of Sep 2008).
>> +variant tclMacPorts conflicts tclSys description {Tcl Wrapper (MacPorts
>> Tcl/Tk)} {
>> +    depends_lib-append \
>> +        port:tcl \
>> +        port:tk
>> +    configure.args-delete \
>> +        -DVTK_WRAP_TCL:BOOL=OFF
>> +    configure.args-append \
>> +        -DVTK_WRAP_TCL:BOOL=ON \
>> +        -DTCL_TCLSH:FILEPATH=${prefix}/bin/tclsh \
>> +        -DTCL_INCLUDE_PATH:PATH=${prefix}/include \
>> +        -DTCL_LIBRARY:FILEPATH=${prefix}/lib \
>> +        -DTK_INCLUDE_PATH:PATH=${prefix}/include \
>> +        -DTK_LIBRARY:FILEPATH=${prefix}/lib
>> +}
>> +# /opt/local/lib/tclConfig.sh
>> +# /opt/local/lib/tkConfig.sh
>> +
>> +
>> +variant java description {Java wrapping for VTK} {
>> +    configure.args-append \
>> +        -DVTK_WRAP_JAVA:BOOL=ON
>> +}
>>
>
> This requires no additional dependency? If so, why not enable this feature
> always and remove the variant?



This part is still in development.  It's a variant to notify everyone that
it's an option and to avoid the port failing if it doesn't build for some
reason (as yet unknown).




>
>  +variant python requires shared description {Python Wrapping for VTK} {
>> +   depends_build-append    port:python26
>> +   configure.args-delete \
>> +       -DVTK_WRAP_PYTHON:BOOL=OFF \
>> +   configure.args-append \
>> +       -DVTK_WRAP_PYTHON:BOOL=ON \
>> +       -DVTK_NO_PYTHON_THREADS:BOOL=OFF \
>> +       -DPYTHON_INCLUDE_PATH:FILEPATH=${prefix}/include/python2.6 \
>> +       -DPYTHON_LIBRARY:FILEPATH=${prefix}/lib/libpython2.6.dylib \
>> +       -DPYTHON_DEBUG_LIBRARY:FILEPATH=${prefix}/lib/libpython2.6.dylib \
>> +       -DPYTHON_EXECUTABLE:FILEPATH=${prefix}/bin/python2.6 \
>> +       -DVTK_PYTHON_SETUP_ARGS:STRING="--prefix=${prefix}
>> --root=${destdir}"
>> +}
>>
>
> You may want to call the variant python26 so that you can later offer other
> variants for other versions of python.
>


OK, good tip.




>
>
>  +
>> +
>> +# ---------------------------------------------------------
>> +# There is a problem with RPATH config for the shared libs.
>> +# Until this is fixed, it will not be a default variant.
>>
>
> But you have made it a default variant. See above.



That comment is removed now that it works.



>
>
>  +variant shared description {Build shared libraries [default]} {
>> +    configure.args-delete \
>> +        -DBUILD_SHARED_LIBS:BOOL=OFF
>> +    configure.args-append \
>> +        -DBUILD_SHARED_LIBS:BOOL=ON \
>> +        -DCMAKE_SKIP_BUILD_RPATH:BOOL=ON \
>> +        -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON \
>> +        -DCMAKE_INSTALL_RPATH:STRING=${prefix}/lib/${distname} \
>> +        -DVTK_USE_RPATH:BOOL=ON
>> +}
>> +
>> +# CMAKE_EXE_LINKER_FLAGS:STRING=
>> +
>> +#  -DVTK_INSTALL_LIB_DIR:STRING=${prefix}/lib/vtk-5.2
>> +#  -DVTK_USE_RPATH=ON \
>> +#  -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=OFF \
>> +
>> +# -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON \
>> +# Cannot use this RPATH setting because the build tree is
>> +# used to bootstrap the build process, eg:
>> +#
>> +#[  4%] Generating vtkGLSLShaderLibrary.h
>> +#dyld: Library not loaded: "/opt/local/lib/vtk-5.2"/libvtksys.5.2.dylib
>> +#  Referenced from:
>> /opt/local/var/macports/build/_Users_dweber_ports_graphics_vtk5/work/VTK/Utilities/MaterialLibrary/../../bin/ProcessShader
>> +#  Reason: image not found
>> +
>> +# Might need variants for carbon vs. cocoa.  When doing a shared library
>> +# build, must use carbon, not cocoa.
>> +
>> +
>> +variant carbon conflicts {cocoa x11} description {Build with Carbon} {
>>
>
> So we have the choice between carbon, cocoa, and x11, and only 1 can be
> chosen. But you have made cocoa a default variant. You should only make
> cocoa the default variant if x11 or carbon have not already been chosen. See
> any of several ports for examples of how to handle this, such as minivmac or
> pdftk.



I guessed that when the command line specifies +x11, for instance, the
variant conflict statment would automatically override the default +cocoa
variant.  So that's not true?



>
>
>  +    configure.args-delete   \
>> +        -DVTK_USE_COCOA:BOOL=ON \
>> +        -DVTK_USE_CARBON:BOOL=OFF
>> +    configure.args-append   \
>> +        -DVTK_USE_COCOA:BOOL=OFF \
>> +        -DVTK_USE_CARBON:BOOL=ON \
>> +}
>> +
>
>



All the variants below are yet to be evaluated and tested.  Soo much to do,
so little time.  At the very least, the "placeholders" are positioned for
further work.





>
>> +
>> +variant cocoa conflicts {carbon x11} description {Build with Cocoa
>> [Default]} {
>> +}
>> +
>> +
>> +variant x11 conflicts {cocoa carbon} description {Build with X11} {
>> +    #depends_build-append    \
>> +        port:xorg-libs \
>> +        port:xorg-proto
>> +    configure.args-delete   \
>> +        -DVTK_USE_COCOA:BOOL=ON \
>> +        -DVTK_USE_X:BOOL=OFF
>> +    configure.args-append   \
>> +        -DVTK_USE_COCOA:BOOL=OFF \
>> +        -DVTK_USE_X:BOOL=ON \
>> +        -DOPENGL_gl_LIBRARY:FILEPATH=${x11prefix}/lib/libGL.dylib \
>> +        -DOPENGL_glu_LIBRARY:FILEPATH=${x11prefix}/lib/libGLU.dylib \
>> +        -DOPENGL_INCLUDE_DIR:PATH=${x11prefix}/include \
>> +        -DVTK_GLEXT_FILE:FILEPATH=${x11prefix}/include/GL/glext.h \
>> +        -DVTK_GLXEXT_FILE:FILEPATH=${x11prefix}/include/GL/glxext.h
>> +        -DVTK_OPENGL_HAS_OSMESA:BOOL=OFF
>> +}
>>
>
> You're using items from ${x11prefix} but we now have X11 in ${prefix}. The
> mesa port provides libGL.dylib and so forth. As I see you realize below. We
> have had the convention of the +x11 variant using the MacPorts x11 and the
> +system_x11 variant using the Apple X11. Though we may remove +system_x11
> soon and no longer offer the option.



Oh, might get around to that someday.  Trying to get almost everything to
work with cocoa first.  If that fails, will certainly get into this a lot
more and draw on the recent additions to the vtk5 port.



>
>
>
>  +# This mesaOpenGL variant may not require the x11 variant, but the
>> +# assumption here is that it's more likely to work with it than without
>> it.
>> +
>> +variant mesaOpenGL requires {x11} description {Use mesa OpenGL} {
>> +    depends_build-append \
>> +        port:mesa
>> +    configure.args-append \
>> +        -DOPENGL_INCLUDE_DIR:PATH=${prefix}/include \
>> +        -DOPENGL_gl_LIBRARY:FILEPATH=${prefix}/lib/libGL.dylib \
>> +        -DOPENGL_glu_LIBRARY:FILEPATH=${prefix}/lib/libGLU.dylib \
>> +        -DVTK_GLEXT_FILE:FILEPATH=${prefix}/include/GL/glext.h \
>> +        -DVTK_GLXEXT_FILE:FILEPATH=${prefix}/include/GL/glxext.h \
>> +        -DVTK_OPENGL_HAS_OSMESA:BOOL=ON
>> +}
>> +
>> +
>> +variant mpi description {Use message passing interface (MPI) for parallel
>> support} {
>> +    depends_lib-append \
>> +        port:mpich2
>> +    configure.args-append \
>> +        -DVTK_USE_MPI:BOOL=ON
>> +}
>> +
>> +
>> +variant mysql description {Build the MySQL driver for vtkSQLDatabase} {
>> +    depends_build-append \
>> +        port:mysql5
>>
>
> Please use path:bin/mysql_config5:mysql5 for any mysql5 dependency, so that
> mysql5-devel would also be able to satisfy it.




Huh?  Is there a path: syntax to the depends_build option?




>
>
>  +    configure.args-append \
>> +        -DVTK_USE_MYSQL:BOOL=ON
>> +}
>> +
>> +
>> +variant pgsql description {Build the PostgreSQL driver for
>> vtkSQLDatabase} {
>> +    depends_build-append \
>> +        port:libpqxx
>> +    configure.args-append \
>> +        -DVTK_USE_POSTGRES:BOOL=ON
>> +}
>> +
>> +
>> +variant odbc description {Build the ODBC database interface} {
>> +    depends_build-append \
>> +        port:unixODBC
>> +    configure.args-append \
>> +        -DVTK_USE_ODBC:BOOL=ON
>> +}
>> +
>> +
>> +# ------------------------------------------------------------------
>> +# POST DESTROOT
>> +
>> +set vtkDocPath  ${destroot}${prefix}/share/doc/${distname}
>> +set vtkDataPath ${destroot}${prefix}/share/${distname}-data
>> +
>> +# Define variables used by install_name_tool for
>> +# the shared libary installation RPATH
>> +set libdestStr ${destroot}${prefix}/bin/libvtk
>> +set libinstStr ${prefix}/lib/${distname}/libvtk
>> +
>> +post-destroot {
>> +
>> +    # Provide data files
>> +    xinstall -d -m 0755 ${vtkDataPath}
>> +    system "tar -C ${vtkDataPath} -zxvf
>> ${distpath}/vtkdata-${version}.tar.gz"
>> +    system "mv ${vtkDataPath}/VTKData/* ${vtkDataPath}/"
>> +    system "rm -rf ${vtkDataPath}/VTKData"
>> +
>> +    # Add basic documentation
>> +    xinstall -d -m 0755 ${vtkDocPath}
>> +    file copy ${worksrcpath}/README.html   ${vtkDocPath}
>> +    file copy ${worksrcpath}/Copyright.txt ${vtkDocPath}
>> +    file copy ${worksrcpath}/Testing.txt   ${vtkDocPath}
>> +
>> +    # Copy examples to the documentation path
>> +    if {[variant_isset examples]} {
>> +        file copy ${worksrcpath}/Examples ${vtkDocPath}
>> +    }
>> +
>> +    # Provide some tests in the documentation path
>> +    if {[variant_isset testing]} {
>> +        foreach x { \
>> +            CommonCxxTests \
>> +            FilteringCxxTests \
>> +            GenericFilteringCxxTests \
>> +            GraphicsCxxTests \
>> +            IOCxxTests \
>> +            ImagingCxxTests \
>> +            RenderingCxxTests \
>> +            TestCxxFeatures \
>> +            TestInstantiator \
>> +            VTKBenchMark \
>> +            VolumeRenderingCxxTests \
>> +            WidgetsCxxTests } \
>> +        {
>> +            file copy ${worksrcpath}/bin/$x ${vtkDocPath}/Examples
>> +        }
>> +    }
>> +
>> +    #if {[variant_isset shared]} {
>> +        # Must set RPATH on all .dylib for shared variant; the RPATH
>> settings
>> +        # in the build are hi-jacked by the DESTDIR set by macports
>> during
>> +        # 'make install'.  Add some system code here to correct the RPATH
>> +        # settings for shared libs?  Perhaps add the system code to the
>> shared
>> +        # variant only.
>> +
>> +        # Use install_name_tool to change the
>> +        # RPATH settings for each .dylib file.
>> +
>> +        # This doesn't work!
>> +        #system "cd ${destroot}${prefix}/bin; install_name_tool -change
>> $libdestStr $libinstStr $*{version}.dylib"
>> +        # See
>> +        # http://qin.laya.com/tech_coding_help/dylib_linking.html
>> +
>> +        #for f in `otool -L libvtkRendering.5.2.0.dylib`; do
>> +        #    echo $f | grep $libdestStr;
>> +        #done
>> +
>> +        # otool -L ${dylib} | grep ${libdestStr} | sed s/.dylib.*/.dylib/
>> +
>> +        # http://guide.macports.org/chunked/reference.phases.html
>> +        # During the destroot phase, macports issues:
>> +        # make install DESTDIR=${destroot}
>> +        # in ${worksrcpath}.
>> +    #}
>> +}
>>
>
> It would be easier to understand the port if you put the parts that are
> specific to a variant inside that variant declaration.
>
> So, instead of what you have:
>
>
> variant examples {
>    ...
> }
> variant testing {
>    ...
> }
> variant shared {
>    ...
> }
> post-destroot {
>    ...
>    if {[variant_isset examples]} {
>        ...
>    }
>    if {[variant_isset testing]} {
>        ...
>    }
>    if {[variant_isset shared]} {
>        ...
>    }
> }
>
>
> Do this:
>
>
> variant examples {
>    ...
>    post-destroot {
>        ...
>    }
> }
> variant testing {
>    ...
>    post-destroot {
>        ...
>    }
> }
> variant shared {
>    ...
>    post-destroot {
>        ...
>    }
> }
> post-destroot {
>    ...
> }
>
>

Difference of opinion.  I find it easier to have it all in the post-destroot
because the variables for the doc and data path are set right before it and
most of the work in post-destroot is clearer when you can see those
variables defined right above it.  If all the post-destroot is split up all
over the variants, it's harder to see what the post-destroot is doing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090427/d48fb16e/attachment-0001.html>

From jannis at leidel.info  Tue Apr 28 00:02:35 2009
From: jannis at leidel.info (Jannis Leidel)
Date: Tue, 28 Apr 2009 09:02:35 +0200
Subject: "Lite" vs. "Full" Python Ports
In-Reply-To: <849726D2-C503-4EA0-BF86-F6066B554FD9@macports.org>
References: <F4917587-3230-4ED6-98BB-83F7EB14DAB7@macports.org>
	<20090412211712.GF15239@ninagal.withay.com>
	<49E339FD.7020509@macports.org>
	<0DA9CCCB-25D5-4764-81A0-828FCBA8B157@macports.org>
	<49E35DE1.3080002@macports.org>
	<20090413211903.GD651@ninagal.withay.com>
	<69527FED-FA3B-47A1-9E5E-F745764F3B8D@macports.org>
	<20090414200026.GC48922@ninagal.withay.com>
	<FA8A6947-4AF0-4E6A-B820-6C0D85A87067@leidel.info>
	<20090414233454.GJ48922@ninagal.withay.com>
	<116F2E90-5E15-43A1-A261-264390CB2D8A@leidel.info>
	<849726D2-C503-4EA0-BF86-F6066B554FD9@macports.org>
Message-ID: <2486F334-1996-497B-A97E-9DE4C67F3207@leidel.info>

> I've also looked through older port versions. None of them changes  
> the "python.pkgd" setting. Thus those modules will always get  
> installed into the site-packages directory and will not be imported.

So this means the fix is ready for checkin? Is there anything I can do?

> On 16.04.2009, at 13:34, Jannis Leidel wrote:
>>> Optimally, having an older version of one of the modules (eg, py25- 
>>> hashlib
>>> at 2.5.2) installed with python25 at 2.5.4 with hashlib builtin,  
>>> would be a
>>> meaningful test.  Then trying it with various bits that affect how  
>>> modules
>>> are loaded (eg, normal, with -S, others?) would answer it fully I  
>>> think.
>>
>> I haven't been able to downgrade the installed py25-hashlib to  
>> 2.5.2 but did some tests with python25 with the builtin hashlib and py25-hashlib at 2.5.4_0 
>>  installed. I also tested with a virtualenv and a sandboxed  
>> virtualenv (--no-site-packages).
>>
>> ~ $ python
>> Python 2.5.4 (r254:67916, Apr 10 2009, 23:33:06)
>> [GCC 4.0.1 (Apple Inc. build 5490)] on darwin
>> Type "help", "copyright", "credits" or "license" for more  
>> information.
>> >>> import hashlib
>> >>> hashlib.__file__
>> '/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
>> python2.5/hashlib.pyc'
>> >>>
>> ~ $ python -S
>> Python 2.5.4 (r254:67916, Apr 10 2009, 23:33:06)
>> [GCC 4.0.1 (Apple Inc. build 5490)] on darwin
>> >>> import hashlib
>> >>> hashlib.__file__
>> '/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
>> python2.5/hashlib.pyc'
>> >>>
>> ~ $ python -c "import hashlib; print hashlib.__file__"
>> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
>> python2.5/hashlib.pyc
>> ~ $
>> ~ $ port installed | grep py25-virtualenv
>> py25-virtualenv @1.3.2_0 (active)
>> ~ $ which virtualenv
>> /opt/local/bin/virtualenv
>> ~ $
>> ~ $ virtualenv hashlib-test
>> New python executable in hashlib-test/bin/python
>> Installing setuptools............done.
>> ~ $ source hashlib-test/bin/ac
>> activate          activate_this.py
>> ~ $ source hashlib-test/bin/activate
>> (hashlib-test)~ $ which python
>> /Users/Jannis/hashlib-test/bin/python
>> (hashlib-test)~ $ python
>> Python 2.5.4 (r254:67916, Apr 10 2009, 23:33:06)
>> [GCC 4.0.1 (Apple Inc. build 5490)] on darwin
>> Type "help", "copyright", "credits" or "license" for more  
>> information.
>> >>> import hashlib
>> >>> hashlib.__file__
>> '/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
>> python2.5/hashlib.pyc'
>> >>>
>> (hashlib-test)~ $ python -c "import hashlib; print hashlib.__file__"
>> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
>> python2.5/hashlib.pyc
>> (hashlib-test)~ $ deactivate
>> ~ $
>> ~ $
>> ~ $ virtualenv --no-site-packages hashlib-test2
>> New python executable in hashlib-test2/bin/python
>> Installing setuptools............done.
>> ~ $ source hashlib-test2/bin/activate
>> (hashlib-test2)~ $ python
>> Python 2.5.4 (r254:67916, Apr 10 2009, 23:33:06)
>> [GCC 4.0.1 (Apple Inc. build 5490)] on darwin
>> Type "help", "copyright", "credits" or "license" for more  
>> information.
>> >>> import hashlib
>> >>> hashlib.__file__
>> '/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
>> python2.5/hashlib.pyc'
>> >>>
>>
>> Jannis
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


From ryandesign at macports.org  Tue Apr 28 04:30:45 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 28 Apr 2009 06:30:45 -0500
Subject: [50222] trunk/dports/graphics
In-Reply-To: <b808b3510904271748w2cca31b4t935e28108ee4cbf7@mail.gmail.com>
References: <20090427232702.18A15168F388@beta.macosforge.org>
	<5AB8AB79-1E8A-400E-BAA8-0E643BB68F72@macports.org>
	<b808b3510904271748w2cca31b4t935e28108ee4cbf7@mail.gmail.com>
Message-ID: <2288E464-397F-464B-9160-2621F233DFF7@macports.org>

On Apr 27, 2009, at 19:48, Darren Weber wrote:

> On Mon, Apr 27, 2009 at 5:01 PM, Ryan Schmidt wrote:
>
>> Since this port uses cmake, have you considered using the cmake  
>> portgroup
>> to simplify it?
>
> No, I didn't know such a portgroup exists and I have no idea how to  
> use a
> portgroup.

Portgroups are basically include statements, allowing you include a  
set of definitions that are common to a class of ports. There is a  
section on portgroups in the guide. Unfortunately it does not have  
any general explanation of what a portgroup is. It just describes the  
options available in some of the existing portgroups.

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

The cmake portgroup is new and not yet documented in the guide, but  
you can read its source code here to see what it does:

http://trac.macports.org/browser/trunk/dports/_resources/port1.0/ 
group/cmake-1.0.tcl

Basically, all ports that use cmake need to do certain similar  
things, for example depend on the cmake port, use cmake in the  
configure phase, specify the prefix using -DCMAKE_INSTALL_PREFIX  
instead of --prefix, etc.; the cmake portgroup exists to simplify  
such ports.


>>> +configure {
>>> +    system "cd ${workbuildpath} && ${configure.env} && cmake
>>> ${configure.args} ${worksrcpath}"
>>> +}
>>>
>>
>> configure.env is not a command; running it by itself doesn't have any
>> effect, as far as I know. If you want those environment variables  
>> to have
>> effect for the cmake command, you would not separate configure.env  
>> from the
>> cmake command with "&&".
>
> configure.env settings will be dropped, completely (see your  
> comment below
> also).

That's what it looked like to me. And I assume that's not what you  
want. Anyway, using the cmake portgroup will take care of this for  
you automatically.


>>> +build {
>>> +    system "cd ${workbuildpath} && gmake"
>>> +}
>>> +destroot {
>>> +    system "cd ${workbuildpath} && gmake install DESTDIR=$ 
>>> {destroot}"
>>> +}
>>
>> Why override all these phases? Using the cmake portgroup will take  
>> care of
>> the configure phase for you, and the build and destroot phases are  
>> better
>> implemented by just setting the relevant .cmd.
>>
>> build.cmd gmake
>> destroot.cmd gmake
>>
>> Actually you can omit "destroot.cmd gmake" since the default for
>> destroot.cmd is the value of build.cmd.
>
> It's possibly pedantic to be explicit about using gmake, but there  
> it is.
> The option to set build.cmd occurred to me.


Actually, an even better way than specifying build.cmd is to use  
build.type. MacPorts knows about bsdmake (which it uses by default)  
and gnumake (a.k.a. gmake) which you can request by using:

build.type gnu

http://guide.macports.org/#reference.phases.build


> However, the default build
> location is ${worksrcpath} and I want to use an out-of-source build  
> path,
> hence the specification to "cd ${workbuildpath}".  The reason is  
> that I hope
> to be able to install both static and dynamic libraries from this  
> vtk port
> and it might be wise to build out of source into several different  
> build
> paths.  The current incarnation uses only a dynamic build by  
> default.  It
> should be possible to add a +static variant that doesn't conflict  
> with the
> dynamic build.  I expect this will be built into $ 
> {workstaticbuildpath}.
>
> I don't see any variable settings for doing out-of-source builds in
> macports.  So, the overrides may stand as is.

The existing variable to do that is called build.dir. You should use  
that instead of your own invention of workbuildpath.


>>> +default_variants \
>>> +    +cocoa \
>>> +    +data \
>>> +    +examples \
>>> +    +shared
>>> +
>>> +variant data description {Install the example data [default]} {
>>> +}
>>> +
>>> +
>>> +variant doc description {Build the doxygen documentation} {
>>> +    depends_build-append \
>>> +        port:doxygen
>>> +    configure.args-append \
>>> +        -DBUILD_DOCUMENTATION:BOOL=ON
>>> +}
>>> +
>>> +
>>> +variant examples description {Build and install VTK examples  
>>> [default]} {
>>> +    configure.args-delete \
>>> +        -DBUILD_EXAMPLES:BOOL=OFF
>>> +    configure.args-append \
>>> +        -DBUILD_EXAMPLES:BOOL=ON
>>> +}
>>>
>>
>> Having fewer variants is better, and since you already make +data and
>> +examples default variants, why not just incorporate them into the  
>> port
>> proper and remove the variants?
>
> Simple -- choice.  Anyone can select -data or -examples, but only  
> if they
> are variants.

And only if they remember to do so every time they want to upgrade or  
reinstall the port.

sudo port upgrade vtk-devel -data -examples

If they do not, your default variants will cause those variants to be  
re-added.

So a user will have to go to some effort to remove the data and the  
examples. Is there any reason anyone would want to do so? They don't  
add dependencies. How much additional disk space do they require? How  
much additional time to they take to build? If the additional build  
time and disk space are small, enable them by default. If they take  
awhile or are large, consider separate ports as you pointed out some  
other distributions do.

More choice is not necessarily better. Giving the user a choice means  
they have to choose, which takes time, effort and knowledge.


>> I would also prefer that the port have no default variants. If  
>> something
>> should be in the port by default, make it so; if necessary, offer  
>> variants
>> to turn the feature off again, e.g. a "no_shared" or a "no_data"  
>> variant.
>> However think carefully about whether anyone really needs to turn  
>> that
>> feature off. If not, don't give the option.
>
> Probably a difference of opinion or just a matter of style.  Using  
> default
> variants allows other ports to get "essential" features without  
> having to
> depend on any variant.  Users can switch it off with -<variant> and  
> I prefer
> to stick with +<variant> or -<variant> rather than introduce double
> negatives like +<no_variant>.  Furthermore, the variant syntax  
> provides
> additional benefits, like description information to 'port variants
> <portname>' and the capacity to specify requires and conflicts, with
> additional stage processing options within the variant.

The problem is that MacPorts always selects default variants, so even  
you had deselected them at install time, MacPorts will select them  
again for you at upgrade time. Therefore it is preferred to enable a  
feature in the port by default and offer a no_whatever variant to  
disable it, if there is really a reason to offer that choice. This is  
why ports have no_x11 variants, instead of an x11 variant that is  
specified as a default variant.

>>> +variant carbon conflicts {cocoa x11} description {Build with  
>>> Carbon} {
>>
>> So we have the choice between carbon, cocoa, and x11, and only 1  
>> can be
>> chosen. But you have made cocoa a default variant. You should only  
>> make
>> cocoa the default variant if x11 or carbon have not already been  
>> chosen. See
>> any of several ports for examples of how to handle this, such as  
>> minivmac or
>> pdftk.
>
> I guessed that when the command line specifies +x11, for instance, the
> variant conflict statment would automatically override the default  
> +cocoa
> variant.  So that's not true?

If the default_variants line specifies +cocoa, MacPorts will select  
the +cocoa variant, unless the user types "-cocoa" at the command line.

If the user only types "+x11", then MacPorts will print a message  
stating that +x11 conflicts with +cocoa and will abort. This is not  
user-friendly, therefore you should only specify +cocoa as a default  
variant if the user has not already selected +x11 or +carbon, as  
exemplified in minivmac or pdftk.


>>> +variant mysql description {Build the MySQL driver for  
>>> vtkSQLDatabase} {
>>> +    depends_build-append \
>>> +        port:mysql5
>>
>> Please use path:bin/mysql_config5:mysql5 for any mysql5  
>> dependency, so that
>> mysql5-devel would also be able to satisfy it.
>
> Huh?  Is there a path: syntax to the depends_build option?

It's not specific to depends_build. All depends_* options can use all  
dependency types. The available types are port:, bin:, lib: and path:.

http://guide.macports.org/#reference.dependencies.types

port: syntax only allows exactly the specified port to satisfy the  
dependency. bin: and lib: should not usually be used because a binary  
or library installed as part of Mac OS X would satisfy the  
dependency, and our policy is to require MacPorts versions of things.  
Older ports might still use bin: and lib: because port: syntax was  
added to MacPorts at a later date. There are also certain exceptions,  
like texlive, for which the bin: or lib: style is preferred. path:  
syntax should be used when more than one port exists which provides  
the necessary functionality. In the case of mysql5, a mysql5-devel  
port exists for the next development version of MySQL. To allow users  
using either mysql5 or mysql5-devel to use this variant of your port,  
use a path:-style dependency and list the path (relative to $ 
{prefix}) of a file provided by the port. I generally try to use  
pkgconfig files or _config scripts if they're available, so the  
mysql_config5 script in the case of MySQL. IMHO we should strive to  
always use path:-style dependencies and move away from using port:- 
style dependencies, because you never know when someone will want to  
add a -devel version of a port.


>> It would be easier to understand the port if you put the parts  
>> that are
>> specific to a variant inside that variant declaration.
>>
>> So, instead of what you have:
>>
>>
>> variant examples {
>>    ...
>> }
>> variant testing {
>>    ...
>> }
>> variant shared {
>>    ...
>> }
>> post-destroot {
>>    ...
>>    if {[variant_isset examples]} {
>>        ...
>>    }
>>    if {[variant_isset testing]} {
>>        ...
>>    }
>>    if {[variant_isset shared]} {
>>        ...
>>    }
>> }
>>
>>
>> Do this:
>>
>>
>> variant examples {
>>    ...
>>    post-destroot {
>>        ...
>>    }
>> }
>> variant testing {
>>    ...
>>    post-destroot {
>>        ...
>>    }
>> }
>> variant shared {
>>    ...
>>    post-destroot {
>>        ...
>>    }
>> }
>> post-destroot {
>>    ...
>> }
>
> Difference of opinion.  I find it easier to have it all in the post- 
> destroot
> because the variables for the doc and data path are set right  
> before it and
> most of the work in post-destroot is clearer when you can see those
> variables defined right above it.  If all the post-destroot is  
> split up all
> over the variants, it's harder to see what the post-destroot is doing.

Ok, I see the point regarding the variables. It can be worked around  
if desired by making them global variables.

I suppose you're right, it's a stylistic issue and could go either way.

Note that some older existing ports do it the way you do only because  
that used to be the only way MacPorts would function correctly.  
Phases defined in variants used to not be cumulative; they would  
override each other, and thus not do what you might expect. Now that  
MacPorts knows to run e.g. each of the post-destroot phases  
specified, instead of just one of them, it can be done either way.  
The guide has not yet been updated for this.

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




From ryandesign at macports.org  Tue Apr 28 04:33:05 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 28 Apr 2009 06:33:05 -0500
Subject: Trac Website & Documentation milestone and editing by anonymous users
Message-ID: <D925387A-2A77-4287-880D-AA6B636BE97D@macports.org>

Two questions about

http://trac.macports.org/ticket/18359#comment:4

1. Did I miss the deletion of the Website & Documentation milestone  
from Trac?

2. How did an anonymous user change a Trac ticket? When I am not  
logged in, I do not see any way to edit a ticket.



From jmr at macports.org  Tue Apr 28 04:43:41 2009
From: jmr at macports.org (Joshua Root)
Date: Tue, 28 Apr 2009 21:43:41 +1000
Subject: Trac Website & Documentation milestone and editing by anonymous
	users
In-Reply-To: <D925387A-2A77-4287-880D-AA6B636BE97D@macports.org>
References: <D925387A-2A77-4287-880D-AA6B636BE97D@macports.org>
Message-ID: <49F6EBED.30401@macports.org>

Ryan Schmidt wrote:
> Two questions about
> 
> http://trac.macports.org/ticket/18359#comment:4
> 
> 1. Did I miss the deletion of the Website & Documentation milestone from
> Trac?
> 
> 2. How did an anonymous user change a Trac ticket? When I am not logged
> in, I do not see any way to edit a ticket.

That was me, using the batch modify plugin, to fix #14909. The Guide now
tells users to just leave the milestone field blank.

- Josh

From wsiegrist at apple.com  Tue Apr 28 07:09:32 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Tue, 28 Apr 2009 07:09:32 -0700
Subject: Trac Website & Documentation milestone and editing by anonymous
	users
In-Reply-To: <49F6EBED.30401@macports.org>
References: <D925387A-2A77-4287-880D-AA6B636BE97D@macports.org>
	<49F6EBED.30401@macports.org>
Message-ID: <89FBB14D-635A-464A-A2DA-4D78C0CC5837@apple.com>

On Apr 28, 2009, at 4:43 AM, Joshua Root wrote:

> Ryan Schmidt wrote:
>> Two questions about
>>
>> http://trac.macports.org/ticket/18359#comment:4
>>
>> 1. Did I miss the deletion of the Website & Documentation milestone  
>> from
>> Trac?
>>
>> 2. How did an anonymous user change a Trac ticket? When I am not  
>> logged
>> in, I do not see any way to edit a ticket.
>
> That was me, using the batch modify plugin, to fix #14909. The Guide  
> now
> tells users to just leave the milestone field blank.
>


I'll look into why it got logged as anonymous, that is probably a bug  
in that plugin.

-Bill

From jmr at macports.org  Tue Apr 28 07:42:54 2009
From: jmr at macports.org (Joshua Root)
Date: Wed, 29 Apr 2009 00:42:54 +1000
Subject: Trac Website & Documentation milestone and editing by anonymous
	users
In-Reply-To: <89FBB14D-635A-464A-A2DA-4D78C0CC5837@apple.com>
References: <D925387A-2A77-4287-880D-AA6B636BE97D@macports.org>
	<49F6EBED.30401@macports.org>
	<89FBB14D-635A-464A-A2DA-4D78C0CC5837@apple.com>
Message-ID: <49F715EE.8090702@macports.org>

William Siegrist wrote:
> On Apr 28, 2009, at 4:43 AM, Joshua Root wrote:
> 
>> Ryan Schmidt wrote:
>>> Two questions about
>>>
>>> http://trac.macports.org/ticket/18359#comment:4
>>>
>>> 1. Did I miss the deletion of the Website & Documentation milestone from
>>> Trac?
>>>
>>> 2. How did an anonymous user change a Trac ticket? When I am not logged
>>> in, I do not see any way to edit a ticket.
>>
>> That was me, using the batch modify plugin, to fix #14909. The Guide now
>> tells users to just leave the milestone field blank.
>>
> 
> 
> I'll look into why it got logged as anonymous, that is probably a bug in
> that plugin.

Actually I think that particular comment would have been left when I
deleted the milestone using the admin interface. I only used the batch
plugin to change ticket types.

- Josh

From wsiegrist at apple.com  Tue Apr 28 08:32:36 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Tue, 28 Apr 2009 08:32:36 -0700
Subject: Trac Website & Documentation milestone and editing by anonymous
	users
In-Reply-To: <49F715EE.8090702@macports.org>
References: <D925387A-2A77-4287-880D-AA6B636BE97D@macports.org>
	<49F6EBED.30401@macports.org>
	<89FBB14D-635A-464A-A2DA-4D78C0CC5837@apple.com>
	<49F715EE.8090702@macports.org>
Message-ID: <DAE385E0-A1B0-4E49-A8D2-F649F0F1612B@apple.com>

On Apr 28, 2009, at 7:42 AM, Joshua Root wrote:

> William Siegrist wrote:
>> On Apr 28, 2009, at 4:43 AM, Joshua Root wrote:
>>
>>> Ryan Schmidt wrote:
>>>> Two questions about
>>>>
>>>> http://trac.macports.org/ticket/18359#comment:4
>>>>
>>>> 1. Did I miss the deletion of the Website & Documentation  
>>>> milestone from
>>>> Trac?
>>>>
>>>> 2. How did an anonymous user change a Trac ticket? When I am not  
>>>> logged
>>>> in, I do not see any way to edit a ticket.
>>>
>>> That was me, using the batch modify plugin, to fix #14909. The  
>>> Guide now
>>> tells users to just leave the milestone field blank.
>>>
>>
>>
>> I'll look into why it got logged as anonymous, that is probably a  
>> bug in
>> that plugin.
>
> Actually I think that particular comment would have been left when I
> deleted the milestone using the admin interface. I only used the batch
> plugin to change ticket types.
>

Okay, that makes more sense. I sent a patch upstream to fix it.

http://trac.edgewall.org/ticket/8247

-Bill


From blair at orcaware.com  Tue Apr 28 10:04:32 2009
From: blair at orcaware.com (Blair Zajac)
Date: Tue, 28 Apr 2009 10:04:32 -0700
Subject: hamcrest-core and backing out changes
Message-ID: <49F73720.1000604@orcaware.com>

Hi,

Regarding hamcrest-core r50259

     Revert r50223, this port is called hamcrest-core and thus should install
     only hamcrest-core, please create an hamcrest-library port if you need it.
     By the way, this change broke junit port as it expects to find an
     hamcrest-core

Please don't back out changes to commits without discussing it first, in an 
open-source project it's considered rude, especially since the port is marked as 
openmaintainer.  Additionally, finding out you backed out the change just 
through committing isn't cool.

Also, my changes left in hamcrest-core.jar, so I don't know why you would see 
breakage, I didn't see it in my testing.  When I upgrade ports, I do something like

$ port contents hamcrest-core | sort > 1
# install the new version of the port
$ port contents hamcrest-core | sort > 2
$ diff 1 2

to make sure there's no missing files.  What error are you seeing?

Regarding adding hamcrest-all.jar, I don't want another port just to install one 
more jar, I don't see the point in that.

Regards,
Blair

From nox at macports.org  Tue Apr 28 12:28:21 2009
From: nox at macports.org (nox)
Date: Tue, 28 Apr 2009 21:28:21 +0200
Subject: hamcrest-core and backing out changes
In-Reply-To: <49F73720.1000604@orcaware.com>
References: <49F73720.1000604@orcaware.com>
Message-ID: <4766976B-918B-49CA-AD8E-5D734EA4F929@macports.org>

Le 28 avr. 09 ? 19:04, Blair Zajac a ?crit :

> Hi,
>
> Regarding hamcrest-core r50259
>
>    Revert r50223, this port is called hamcrest-core and thus should  
> install
>    only hamcrest-core, please create an hamcrest-library port if you  
> need it.
>    By the way, this change broke junit port as it expects to find an
>    hamcrest-core
>
> Please don't back out changes to commits without discussing it  
> first, in an open-source project it's considered rude, especially  
> since the port is marked as openmaintainer.  Additionally, finding  
> out you backed out the change just through committing isn't cool.
>
> Also, my changes left in hamcrest-core.jar, so I don't know why you  
> would see breakage, I didn't see it in my testing.  When I upgrade  
> ports, I do something like
>
> $ port contents hamcrest-core | sort > 1
> # install the new version of the port
> $ port contents hamcrest-core | sort > 2
> $ diff 1 2
>
> to make sure there's no missing files.  What error are you seeing?
>
> Regarding adding hamcrest-all.jar, I don't want another port just to  
> install one more jar, I don't see the point in that.
>
> Regards,
> Blair

I don't see the point in having a port which installs hamcrest-core  
AND some other things even though it's called hamcrest-core. I thought  
you also changed the final jar name as it would have been at least  
consistent.

A port installing more than it should have is in no way a more  
expected thing than a big port installing less than you expect it to  
do (e.g. python). What's the problem with one more jar? disk space?

From blair at orcaware.com  Tue Apr 28 14:21:55 2009
From: blair at orcaware.com (Blair Zajac)
Date: Tue, 28 Apr 2009 14:21:55 -0700
Subject: hamcrest-core and backing out changes
In-Reply-To: <4766976B-918B-49CA-AD8E-5D734EA4F929@macports.org>
References: <49F73720.1000604@orcaware.com>
	<4766976B-918B-49CA-AD8E-5D734EA4F929@macports.org>
Message-ID: <49F77373.5090409@orcaware.com>

nox wrote:
> Le 28 avr. 09 ? 19:04, Blair Zajac a ?crit :
> 
>> Hi,
>>
>> Regarding hamcrest-core r50259
>>
>>    Revert r50223, this port is called hamcrest-core and thus should 
>> install
>>    only hamcrest-core, please create an hamcrest-library port if you 
>> need it.
>>    By the way, this change broke junit port as it expects to find an
>>    hamcrest-core
>>
>> Please don't back out changes to commits without discussing it first, 
>> in an open-source project it's considered rude, especially since the 
>> port is marked as openmaintainer.  Additionally, finding out you 
>> backed out the change just through committing isn't cool.
>>
>> Also, my changes left in hamcrest-core.jar, so I don't know why you 
>> would see breakage, I didn't see it in my testing.  When I upgrade 
>> ports, I do something like
>>
>> $ port contents hamcrest-core | sort > 1
>> # install the new version of the port
>> $ port contents hamcrest-core | sort > 2
>> $ diff 1 2
>>
>> to make sure there's no missing files.  What error are you seeing?
>>
>> Regarding adding hamcrest-all.jar, I don't want another port just to 
>> install one more jar, I don't see the point in that.
>>
>> Regards,
>> Blair
> 
> I don't see the point in having a port which installs hamcrest-core AND 
> some other things even though it's called hamcrest-core. I thought you 
> also changed the final jar name as it would have been at least consistent.
> 
> A port installing more than it should have is in no way a more expected 
> thing than a big port installing less than you expect it to do (e.g. 
> python). What's the problem with one more jar? disk space?

Since my project needs more jars than just hamcrest-core.jar.  I'll create a new 
hamcrest port that includes all the jars.

Also, you didn't address my point about acceptable policy in backing out 
changes.  Next time you are backing out a change, please double check before 
doing so.

Regards,
Blair


From nox at macports.org  Wed Apr 29 01:11:09 2009
From: nox at macports.org (nox)
Date: Wed, 29 Apr 2009 10:11:09 +0200
Subject: hamcrest-core and backing out changes
In-Reply-To: <49F77373.5090409@orcaware.com>
References: <49F73720.1000604@orcaware.com>
	<4766976B-918B-49CA-AD8E-5D734EA4F929@macports.org>
	<49F77373.5090409@orcaware.com>
Message-ID: <C496A833-6648-41C0-B646-F2F3A2A79EE3@macports.org>

Le 28 avr. 09 ? 23:21, Blair Zajac a ?crit :

> nox wrote:
>> Le 28 avr. 09 ? 19:04, Blair Zajac a ?crit :
>>> Hi,
>>>
>>> Regarding hamcrest-core r50259
>>>
>>>   Revert r50223, this port is called hamcrest-core and thus should  
>>> install
>>>   only hamcrest-core, please create an hamcrest-library port if  
>>> you need it.
>>>   By the way, this change broke junit port as it expects to find an
>>>   hamcrest-core
>>>
>>> Please don't back out changes to commits without discussing it  
>>> first, in an open-source project it's considered rude, especially  
>>> since the port is marked as openmaintainer.  Additionally, finding  
>>> out you backed out the change just through committing isn't cool.
>>>
>>> Also, my changes left in hamcrest-core.jar, so I don't know why  
>>> you would see breakage, I didn't see it in my testing.  When I  
>>> upgrade ports, I do something like
>>>
>>> $ port contents hamcrest-core | sort > 1
>>> # install the new version of the port
>>> $ port contents hamcrest-core | sort > 2
>>> $ diff 1 2
>>>
>>> to make sure there's no missing files.  What error are you seeing?
>>>
>>> Regarding adding hamcrest-all.jar, I don't want another port just  
>>> to install one more jar, I don't see the point in that.
>>>
>>> Regards,
>>> Blair
>> I don't see the point in having a port which installs hamcrest-core  
>> AND some other things even though it's called hamcrest-core. I  
>> thought you also changed the final jar name as it would have been  
>> at least consistent.
>> A port installing more than it should have is in no way a more  
>> expected thing than a big port installing less than you expect it  
>> to do (e.g. python). What's the problem with one more jar? disk  
>> space?
>
> Since my project needs more jars than just hamcrest-core.jar.  I'll  
> create a new hamcrest port that includes all the jars.
>

Then, we'll need to delete hamcrest-core. Separate ports look better  
to me.

> Also, you didn't address my point about acceptable policy in backing  
> out changes.  Next time you are backing out a change, please double  
> check before doing so.
>

Well, imho, your update was a major change, thus a ticket should have  
been filed.

From jeremyhu at macports.org  Wed Apr 29 01:38:19 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Wed, 29 Apr 2009 01:38:19 -0700
Subject: qt4-x11 and x11prefix
Message-ID: <E21877D0-D0D3-4909-B433-50F94C525099@macports.org>

qt4-x11's qmake is causing built applications to use /usr/X11 instead  
of /opt/local for X11... This has caused some problems here, and I'm  
sure others might see it too:

./src/lib/animations/triangletriad_0001/Makefile:DEFINES       = - 
D__USE_WS_X11__ -DUSE_DLOPEN
./src/lib/animations/triangletriad_0001/Makefile:INCPATH       = -I/ 
opt/local/libexec/qt4-x11/mkspecs/darwin-g++ -I. -I../.. -I.. -I/usr/ 
X11/include
./src/lib/animations/triangletriad_0001/Makefile:LIBS          = $ 
(SUBLIBS)  -L/usr/X11/lib -L../../../../lib -lpgl -lGLU -lGL

So to summarize, the qt libs themselves are linked against /opt/local/ 
lib/..., but applications that are built with the qmake build system  
are not.

--Jeremy


From n.oxyde at gmail.com  Wed Apr 29 02:55:27 2009
From: n.oxyde at gmail.com (nox)
Date: Wed, 29 Apr 2009 11:55:27 +0200
Subject: hamcrest-core and backing out changes
In-Reply-To: <C496A833-6648-41C0-B646-F2F3A2A79EE3@macports.org>
References: <49F73720.1000604@orcaware.com>
	<4766976B-918B-49CA-AD8E-5D734EA4F929@macports.org>
	<49F77373.5090409@orcaware.com>
	<C496A833-6648-41C0-B646-F2F3A2A79EE3@macports.org>
Message-ID: <9D5E9593-EC0E-4A70-8B50-72DB03DCD230@gmail.com>


Le 29 avr. 09 ? 10:11, nox a ?crit :

> Le 28 avr. 09 ? 23:21, Blair Zajac a ?crit :
>
>> nox wrote:
>>> Le 28 avr. 09 ? 19:04, Blair Zajac a ?crit :
>>>> <snip/>
>>
>
> Then, we'll need to delete hamcrest-core. Separate ports look better  
> to me.
>

hamcrest-library created in r50332.

From jmpp at macports.org  Wed Apr 29 09:55:45 2009
From: jmpp at macports.org (Juan Manuel Palacios)
Date: Wed, 29 Apr 2009 12:25:45 -0430
Subject: MacPorts article on ADC
Message-ID: <E63F84BF-066A-405D-B3EC-074D50578FEC@macports.org>


	Heyya people, quick hi after some serious lurking! I thought I'd  
forward this article on using MacPorts that appeared on ADC this  
february. Don't know if it's old news, as I say I've been lurking  
badly ;-), but it did catch my eye today as it was one of the top  
featured articles at the Mac Dev Center home (http://developer.apple.com/mac/ 
). Now how cool is that?!

	Haven't read it yet either, so don't flame me! :-P Enjoy!

http://developer.apple.com/mac/articles/opensource/workingwithmacports.html


- jmpp


From dweber at macports.org  Wed Apr 29 11:39:51 2009
From: dweber at macports.org (Darren Weber)
Date: Wed, 29 Apr 2009 11:39:51 -0700
Subject: xinstall glob question
Message-ID: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>

Are these equivalent?

A.
eval xinstall -m 755 [glob {!${build.dir}/bin/*.dylib}]
${destroot}/${vtkExamplePath}/bin

B.
cd ${build.dir}
for f in `find bin \! -name '*.dylib'`; do
  cp $f ${destroot}/${vtkExamplePath}/bin"
done


When using xinstall without resetting the file mode (ie, no -m option), do
directories and files retain their current modes?


Thanks in advance,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090429/c73c29e6/attachment.html>

From devans at macports.org  Wed Apr 29 11:40:36 2009
From: devans at macports.org (David Evans)
Date: Wed, 29 Apr 2009 11:40:36 -0700
Subject: [50351] trunk/dports/x11
In-Reply-To: <20090429173100.4CB9816B64A2@beta.macosforge.org>
References: <20090429173100.4CB9816B64A2@beta.macosforge.org>
Message-ID: <49F89F24.2050904@macports.org>

ryandesign at macports.org wrote:
>
> Revision
>     50351 <http://trac.macports.org/changeset/50351>
> Author
>     ryandesign at macports.org
> Date
>     2009-04-29 10:30:58 -0700 (Wed, 29 Apr 2009)
>
>
>       Log Message
>
> pango, pango-devel: still depend on gtk-doc, but don't use it, because doing so seems to be incompatible with the +no_x11 variant; see #19447
This fixed the problem. Thanks.

From jeremy at lavergne.gotdns.org  Wed Apr 29 11:42:20 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Wed, 29 Apr 2009 14:42:20 -0400
Subject: xinstall glob question
In-Reply-To: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>
References: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>
Message-ID: <6D456519-C643-4031-9AC1-A9EF284932C8@lavergne.gotdns.org>

> Are these equivalent?
>
> A.
> eval xinstall -m 755 [glob {!${build.dir}/bin/*.dylib}] ${destroot}/$ 
> {vtkExamplePath}/bin
>
> B.
> cd ${build.dir}
> for f in `find bin \! -name '*.dylib'`; do
>   cp $f ${destroot}/${vtkExamplePath}/bin"
> done

The only difference I see is the mode setting.
Feel free to get a second opinion from the seasoned veterans :-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2435 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090429/cfd7e202/attachment.bin>

From devans at macports.org  Wed Apr 29 11:45:58 2009
From: devans at macports.org (David Evans)
Date: Wed, 29 Apr 2009 11:45:58 -0700
Subject: [50352] trunk/dports
In-Reply-To: <20090429173823.B656316B6646@beta.macosforge.org>
References: <20090429173823.B656316B6646@beta.macosforge.org>
Message-ID: <49F8A066.7090207@macports.org>

ryandesign at macports.org wrote:
>
> Revision
>     50352 <http://trac.macports.org/changeset/50352>
> Author
>     ryandesign at macports.org
> Date
>     2009-04-29 10:38:23 -0700 (Wed, 29 Apr 2009)
>
>
>       Log Message
>
> php5-syck: Move from www to php category, with maintainer's permission
While you're reconsidering categories, how about moving pango and gtk2 
to devel from x11?  They're not just for X11 anymore. ;-)

From ryandesign at macports.org  Wed Apr 29 11:57:53 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 29 Apr 2009 13:57:53 -0500
Subject: [50352] trunk/dports
In-Reply-To: <49F8A066.7090207@macports.org>
References: <20090429173823.B656316B6646@beta.macosforge.org>
	<49F8A066.7090207@macports.org>
Message-ID: <97A758C8-AAF1-467B-BB3C-A2576B70B551@macports.org>


On Apr 29, 2009, at 13:45, David Evans wrote:

> While you're reconsidering categories, how about moving pango and  
> gtk2 to devel from x11?  They're not just for X11 anymore. ;-)

Sounds like a good idea to me. Any objection, Anthony?


From jeremyhu at macports.org  Wed Apr 29 12:24:04 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Wed, 29 Apr 2009 12:24:04 -0700
Subject: +system_x11 to bite the dust
Message-ID: <EEA15397-5D82-44CE-A36A-94DF37AA882F@macports.org>

So, the MacPorts-provided X11 libs should be regression free over what  
is installed in any x11prefix.  The hardware-rendering libGL was the  
last nail, and that's been fairly stable for the past 1-2 months.

Can we successfully nuke the backwards-compatible system_x11 variant  
now?  If any cares to answer "no," then you also need to explain why,  
so I can make sure to address your concerns before pulling the plug.

"no, I like not using MP's X11 libs" is not a valid reason.

"wait, wait... the XFree86 port still uses x11prefix" is also not a  
valid reason.  That port can be updated to be the *only* port using  
x11prefix (as a local variable).  It will install the server that pure  
darwin users will need in this alternate prefix, and any other X11  
application installed by MacPorts will use the new hotness X11 libs.

After this is done, I'm going to go through and start removing all the  
x11prefix references and workarounds in various ports.  If you are  
maintainer on a !openmaintainer port that has reference to $ 
{x11prefix}, speak now, or I consider your silence approval.

Once that is done, we can update base to no longer need x11prefix...  
and our lives should be much simpler...

--Jeremy



From ryandesign at macports.org  Wed Apr 29 12:35:42 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 29 Apr 2009 14:35:42 -0500
Subject: +system_x11 to bite the dust
In-Reply-To: <EEA15397-5D82-44CE-A36A-94DF37AA882F@macports.org>
References: <EEA15397-5D82-44CE-A36A-94DF37AA882F@macports.org>
Message-ID: <FC3DADE2-CF8A-4D25-A5C3-BF397E441A8B@macports.org>

On Apr 29, 2009, at 14:24, Jeremy Huddleston wrote:

> So, the MacPorts-provided X11 libs should be regression free over  
> what is installed in any x11prefix.  The hardware-rendering libGL  
> was the last nail, and that's been fairly stable for the past 1-2  
> months.
>
> Can we successfully nuke the backwards-compatible system_x11  
> variant now?  If any cares to answer "no," then you also need to  
> explain why, so I can make sure to address your concerns before  
> pulling the plug.
>
> "no, I like not using MP's X11 libs" is not a valid reason.
>
> "wait, wait... the XFree86 port still uses x11prefix" is also not a  
> valid reason.  That port can be updated to be the *only* port using  
> x11prefix (as a local variable).  It will install the server that  
> pure darwin users will need in this alternate prefix, and any other  
> X11 application installed by MacPorts will use the new hotness X11  
> libs.
>
> After this is done, I'm going to go through and start removing all  
> the x11prefix references and workarounds in various ports.  If you  
> are maintainer on a !openmaintainer port that has reference to $ 
> {x11prefix}, speak now, or I consider your silence approval.
>
> Once that is done, we can update base to no longer need  
> x11prefix... and our lives should be much simpler...

You've taken the lead on X11 stuff, and it seems to work in $ 
{prefix}, so I'm in favor of simplifying and getting rid of  
+system_x11 and the base requirement for X11User and X11SDK.


From blair at orcaware.com  Wed Apr 29 12:40:54 2009
From: blair at orcaware.com (Blair Zajac)
Date: Wed, 29 Apr 2009 12:40:54 -0700
Subject: hamcrest-core and backing out changes
In-Reply-To: <9D5E9593-EC0E-4A70-8B50-72DB03DCD230@gmail.com>
References: <49F73720.1000604@orcaware.com>
	<4766976B-918B-49CA-AD8E-5D734EA4F929@macports.org>
	<49F77373.5090409@orcaware.com>
	<C496A833-6648-41C0-B646-F2F3A2A79EE3@macports.org>
	<9D5E9593-EC0E-4A70-8B50-72DB03DCD230@gmail.com>
Message-ID: <49F8AD46.1010804@orcaware.com>

nox wrote:
> 
> Le 29 avr. 09 ? 10:11, nox a ?crit :
> 
>> Le 28 avr. 09 ? 23:21, Blair Zajac a ?crit :
>>
>>> nox wrote:
>>>> Le 28 avr. 09 ? 19:04, Blair Zajac a ?crit :
>>>>> <snip/>
>>>
>>
>> Then, we'll need to delete hamcrest-core. Separate ports look better 
>> to me.
>>
> 
> hamcrest-library created in r50332.

Sweet, thanks, that works like a charm.

Regards,
Blair


From devans at macports.org  Wed Apr 29 12:41:24 2009
From: devans at macports.org (David Evans)
Date: Wed, 29 Apr 2009 12:41:24 -0700
Subject: +system_x11 to bite the dust
In-Reply-To: <EEA15397-5D82-44CE-A36A-94DF37AA882F@macports.org>
References: <EEA15397-5D82-44CE-A36A-94DF37AA882F@macports.org>
Message-ID: <49F8AD64.9090407@macports.org>

Jeremy Huddleston wrote:
> So, the MacPorts-provided X11 libs should be regression free over what 
> is installed in any x11prefix.  The hardware-rendering libGL was the 
> last nail, and that's been fairly stable for the past 1-2 months.
>
> Can we successfully nuke the backwards-compatible system_x11 variant 
> now?  If any cares to answer "no," then you also need to explain why, 
> so I can make sure to address your concerns before pulling the plug.
>
> "no, I like not using MP's X11 libs" is not a valid reason.
>
> "wait, wait... the XFree86 port still uses x11prefix" is also not a 
> valid reason.  That port can be updated to be the *only* port using 
> x11prefix (as a local variable).  It will install the server that pure 
> darwin users will need in this alternate prefix, and any other X11 
> application installed by MacPorts will use the new hotness X11 libs.
>
> After this is done, I'm going to go through and start removing all the 
> x11prefix references and workarounds in various ports.  If you are 
> maintainer on a !openmaintainer port that has reference to 
> ${x11prefix}, speak now, or I consider your silence approval.
>
> Once that is done, we can update base to no longer need x11prefix... 
> and our lives should be much simpler...
>
> --Jeremy
>
I agree that this would be a move toward simplification, but the 
interest in universal builds makes me think that a number of people are 
using
MacPorts to build applications to be distributed in binary form to 
various target architectures.  It would make sense to me that in this 
case that
end users should be able to expect any X11 based applications to work 
correctly with the X11 server that MacOS provides out of the box. 

So is this true or would such users need to install xorg-server as 
well?  If so, do all Apple supplied X11 clients work correctly with 
xorg-server?

Dave

From blair at orcaware.com  Wed Apr 29 12:43:43 2009
From: blair at orcaware.com (Blair Zajac)
Date: Wed, 29 Apr 2009 12:43:43 -0700
Subject: hamcrest-core and backing out changes
In-Reply-To: <C496A833-6648-41C0-B646-F2F3A2A79EE3@macports.org>
References: <49F73720.1000604@orcaware.com>
	<4766976B-918B-49CA-AD8E-5D734EA4F929@macports.org>
	<49F77373.5090409@orcaware.com>
	<C496A833-6648-41C0-B646-F2F3A2A79EE3@macports.org>
Message-ID: <49F8ADEF.5000206@orcaware.com>

nox wrote:
> Le 28 avr. 09 ? 23:21, Blair Zajac a ?crit :
> 
>> nox wrote:
>>> Le 28 avr. 09 ? 19:04, Blair Zajac a ?crit :
>>>> Hi,
>>>>
>>>> Regarding hamcrest-core r50259
>>>>
>>>>   Revert r50223, this port is called hamcrest-core and thus should 
>>>> install
>>>>   only hamcrest-core, please create an hamcrest-library port if you 
>>>> need it.
>>>>   By the way, this change broke junit port as it expects to find an
>>>>   hamcrest-core
>>>>
>>>> Please don't back out changes to commits without discussing it 
>>>> first, in an open-source project it's considered rude, especially 
>>>> since the port is marked as openmaintainer.  Additionally, finding 
>>>> out you backed out the change just through committing isn't cool.
>>>>
>>>> Also, my changes left in hamcrest-core.jar, so I don't know why you 
>>>> would see breakage, I didn't see it in my testing.  When I upgrade 
>>>> ports, I do something like
>>>>
>>>> $ port contents hamcrest-core | sort > 1
>>>> # install the new version of the port
>>>> $ port contents hamcrest-core | sort > 2
>>>> $ diff 1 2
>>>>
>>>> to make sure there's no missing files.  What error are you seeing?
>>>>
>>>> Regarding adding hamcrest-all.jar, I don't want another port just to 
>>>> install one more jar, I don't see the point in that.
>>>>
>>>> Regards,
>>>> Blair
>>> I don't see the point in having a port which installs hamcrest-core 
>>> AND some other things even though it's called hamcrest-core. I 
>>> thought you also changed the final jar name as it would have been at 
>>> least consistent.
>>> A port installing more than it should have is in no way a more 
>>> expected thing than a big port installing less than you expect it to 
>>> do (e.g. python). What's the problem with one more jar? disk space?
>>
>> Since my project needs more jars than just hamcrest-core.jar.  I'll 
>> create a new hamcrest port that includes all the jars.
>>
> 
> Then, we'll need to delete hamcrest-core. Separate ports look better to me.
> 
>> Also, you didn't address my point about acceptable policy in backing 
>> out changes.  Next time you are backing out a change, please double 
>> check before doing so.
>>
> 
> Well, imho, your update was a major change, thus a ticket should have 
> been filed.

Well, I don't see adding a single jar as requiring a ticket, as it wasn't 
modifying the existing files.

But that still doesn't relate to backing out changes.  On the Subversion 
project, which I'm a committer on, we have a policy of discussing (and voting if 
necessary) before reverting.  I'm not against backing out the change in this 
case, since you wanted hamcrest-core to just be the core jar file, which is ok, 
but how it was done.

Regards,
Blair


From afb at macports.org  Wed Apr 29 12:43:57 2009
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Wed, 29 Apr 2009 21:43:57 +0200
Subject: +system_x11 to bite the dust
In-Reply-To: <EEA15397-5D82-44CE-A36A-94DF37AA882F@macports.org>
References: <EEA15397-5D82-44CE-A36A-94DF37AA882F@macports.org>
Message-ID: <C6F402DD-56AA-4FBB-A8E8-D865EE01FFE7@macports.org>

Jeremy Huddleston wrote:

> Can we successfully nuke the backwards-compatible system_x11  
> variant now?  If any cares to answer "no," then you also need to  
> explain why, so I can make sure to address your concerns before  
> pulling the plug.
>
> "no, I like not using MP's X11 libs" is not a valid reason.

That was my only reason, it was "easier" to use XFree86 from X11+SDK  
just like it was easier to use GCC from Xcode Tools... If X11 is no  
longer considered to be "outside" MacPorts, then so be it.

> After this is done, I'm going to go through and start removing all  
> the x11prefix references and workarounds in various ports.  If you  
> are maintainer on a !openmaintainer port that has reference to $ 
> {x11prefix}, speak now, or I consider your silence approval.

I think ${x11prefix} was mostly to avoid hardcoding /usr/X11R6 (or / 
usr/X11), but I gather you will be replacing it with ${prefix} now ?  
(It was /usr/local on FreeBSD, but that doesn't really matter)

--anders


From dweber at macports.org  Wed Apr 29 12:45:01 2009
From: dweber at macports.org (Darren Weber)
Date: Wed, 29 Apr 2009 12:45:01 -0700
Subject: xinstall glob question
In-Reply-To: <6D456519-C643-4031-9AC1-A9EF284932C8@lavergne.gotdns.org>
References: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>
	<6D456519-C643-4031-9AC1-A9EF284932C8@lavergne.gotdns.org>
Message-ID: <b808b3510904291245n593b57d8q5819d5e1b0112a34@mail.gmail.com>

The {!<pattern>} syntax is supposed to NOT that file name <pattern>.  I have
a directory of binary executables among a lot of .dylib files and I want to
exclude all the .dylib files from the glob.

The system command is working, so I'll go ahead with that.

Thanks, Darren


On Wed, Apr 29, 2009 at 11:42 AM, Jeremy Lavergne <
jeremy at lavergne.gotdns.org> wrote:

> Are these equivalent?
>>
>> A.
>> eval xinstall -m 755 [glob {!${build.dir}/bin/*.dylib}]
>> ${destroot}/${vtkExamplePath}/bin
>>
>> B.
>> cd ${build.dir}
>> for f in `find bin \! -name '*.dylib'`; do
>>  cp $f ${destroot}/${vtkExamplePath}/bin"
>> done
>>
>
> The only difference I see is the mode setting.
> Feel free to get a second opinion from the seasoned veterans :-)
>
>
> _______________________________________________
> 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/20090429/004d14c2/attachment.html>

From jeremyhu at macports.org  Wed Apr 29 12:50:01 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Wed, 29 Apr 2009 12:50:01 -0700
Subject: +system_x11 to bite the dust
In-Reply-To: <49F8AD64.9090407@macports.org>
References: <EEA15397-5D82-44CE-A36A-94DF37AA882F@macports.org>
	<49F8AD64.9090407@macports.org>
Message-ID: <48F92884-6F23-46E9-BB24-82E80674F400@macports.org>


On Apr 29, 2009, at 12:41, David Evans wrote:
> I agree that this would be a move toward simplification, but the  
> interest in universal builds makes me think that a number of people  
> are using
> MacPorts to build applications to be distributed in binary form to  
> various target architectures.  It would make sense to me that in  
> this case that
> end users should be able to expect any X11 based applications to  
> work correctly with the X11 server that MacOS provides out of the box.

Yes, the X11 applications will work on any X11 server.  You can even  
install Xfree86-3.x on FreeBSD on another machine and run the macports  
X11 apps on it.

> So is this true or would such users need to install xorg-server as  
> well?  If so, do all Apple supplied X11 clients work correctly with  
> xorg-server?

This would actually be preferred for Tiger users.  Apple's bundled X11  
server is quite dated.  The only known incompatibility is with the new  
libGL and the old server.  If users want good GLX performance on  
Tiger, they should use xorg-server instead of the Apple-provided  
X11.app.



From jeremyhu at macports.org  Wed Apr 29 12:52:59 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Wed, 29 Apr 2009 12:52:59 -0700
Subject: +system_x11 to bite the dust
In-Reply-To: <C6F402DD-56AA-4FBB-A8E8-D865EE01FFE7@macports.org>
References: <EEA15397-5D82-44CE-A36A-94DF37AA882F@macports.org>
	<C6F402DD-56AA-4FBB-A8E8-D865EE01FFE7@macports.org>
Message-ID: <E79AC2D1-C8B9-4D19-B969-67739BD7BE6D@macports.org>


On Apr 29, 2009, at 12:43, Anders F Bj?rklund wrote:
>
>> After this is done, I'm going to go through and start removing all  
>> the x11prefix references and workarounds in various ports.  If you  
>> are maintainer on a !openmaintainer port that has reference to $ 
>> {x11prefix}, speak now, or I consider your silence approval.
>
> I think ${x11prefix} was mostly to avoid hardcoding /usr/X11R6 (or / 
> usr/X11), but I gather you will be replacing it with ${prefix} now ?  
> (It was /usr/local on FreeBSD, but that doesn't really matter)

No, I won't be replacing it with anything.  It will be purged.   
XFree86/Portfile will still use it, but it will be self contained in  
that Portfile (ie not in base).  That will be used to install the pure  
darwin X11 server in a separate prefix (/usr/X11R6).



From devans at macports.org  Wed Apr 29 12:59:07 2009
From: devans at macports.org (David Evans)
Date: Wed, 29 Apr 2009 12:59:07 -0700
Subject: +system_x11 to bite the dust
In-Reply-To: <48F92884-6F23-46E9-BB24-82E80674F400@macports.org>
References: <EEA15397-5D82-44CE-A36A-94DF37AA882F@macports.org>
	<49F8AD64.9090407@macports.org>
	<48F92884-6F23-46E9-BB24-82E80674F400@macports.org>
Message-ID: <49F8B18B.7070806@macports.org>

Jeremy Huddleston wrote:
>
> On Apr 29, 2009, at 12:41, David Evans wrote:
>> I agree that this would be a move toward simplification, but the 
>> interest in universal builds makes me think that a number of people 
>> are using
>> MacPorts to build applications to be distributed in binary form to 
>> various target architectures.  It would make sense to me that in this 
>> case that
>> end users should be able to expect any X11 based applications to work 
>> correctly with the X11 server that MacOS provides out of the box.
>
> Yes, the X11 applications will work on any X11 server.  You can even 
> install Xfree86-3.x on FreeBSD on another machine and run the macports 
> X11 apps on it.
>
>> So is this true or would such users need to install xorg-server as 
>> well?  If so, do all Apple supplied X11 clients work correctly with 
>> xorg-server?
>
> This would actually be preferred for Tiger users.  Apple's bundled X11 
> server is quite dated.  The only known incompatibility is with the new 
> libGL and the old server.  If users want good GLX performance on 
> Tiger, they should use xorg-server instead of the Apple-provided X11.app.
>
>
Sounds good to me then.  Thanks for all your hard work on updating X11. 

From afb at macports.org  Wed Apr 29 13:19:28 2009
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Wed, 29 Apr 2009 22:19:28 +0200
Subject: +system_x11 to bite the dust
In-Reply-To: <E79AC2D1-C8B9-4D19-B969-67739BD7BE6D@macports.org>
References: <EEA15397-5D82-44CE-A36A-94DF37AA882F@macports.org>
	<C6F402DD-56AA-4FBB-A8E8-D865EE01FFE7@macports.org>
	<E79AC2D1-C8B9-4D19-B969-67739BD7BE6D@macports.org>
Message-ID: <F6CC1803-BE83-4B02-A43A-CAFCD196B17E@macports.org>

Jeremy Huddleston wrote:

>> I think ${x11prefix} was mostly to avoid hardcoding /usr/X11R6  
>> (or /usr/X11), but I gather you will be replacing it with $ 
>> {prefix} now ? (It was /usr/local on FreeBSD, but that doesn't  
>> really matter)
>
> No, I won't be replacing it with anything.  It will be purged.   
> XFree86/Portfile will still use it, but it will be self contained  
> in that Portfile (ie not in base).  That will be used to install  
> the pure darwin X11 server in a separate prefix (/usr/X11R6).

Meant something like "--x-include=${prefix}/include --x-lib=${prefix}/ 
lib"...

Like if one was to look for the "new" X11, one would look under $ 
{prefix} -
rather than under ${x11prefix} like one did with the "old" X11  
(+system_x11) ?

You might also want to remove all the X11 from base's configure, when  
purging.

--anders


From mcalhoun at macports.org  Wed Apr 29 13:57:54 2009
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Wed, 29 Apr 2009 20:57:54 +0000 (UTC)
Subject: =?utf-8?b?K3N5c3RlbV94MTE=?= to bite the dust
References: <EEA15397-5D82-44CE-A36A-94DF37AA882F@macports.org>
Message-ID: <loom.20090429T204935-565@post.gmane.org>

Jeremy Huddleston <jeremyhu at ...> writes:

> 
> So, the MacPorts-provided X11 libs should be regression free over what  
> is installed in any x11prefix.  The hardware-rendering libGL was the  
> last nail, and that's been fairly stable for the past 1-2 months.
> 
> Can we successfully nuke the backwards-compatible system_x11 variant  
> now?  If any cares to answer "no," then you also need to explain why,  
> so I can make sure to address your concerns before pulling the plug.
> 
> "no, I like not using MP's X11 libs" is not a valid reason.
> 

Isn't there a case to be made for hedging our bets?

I think it's safe to say that not too long ago, the MacPorts X11 libraries
were a mess of broken ports and inconsistent dependencies.
Thanks to the hard work of a select few, this is no longer the case.
If bit rot should ever creep into X11 again, I would not have a clue
how to fix it.

Because X11 is complicated but essential, shouldn't we keep the option
of reverting to the Apple X11?

My apologies if this sounds too much like the invalid
"no, I like not using MP's X11 libs" reason.

-Marcus






From mcalhoun at macports.org  Wed Apr 29 13:59:58 2009
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Wed, 29 Apr 2009 20:59:58 +0000 (UTC)
Subject: qt4-x11 and x11prefix
References: <E21877D0-D0D3-4909-B433-50F94C525099@macports.org>
Message-ID: <loom.20090429T205823-894@post.gmane.org>

Jeremy Huddleston <jeremyhu at ...> writes:

> 
> qt4-x11's qmake is causing built applications to use /usr/X11 instead  
> of /opt/local for X11... This has caused some problems here, and I'm  
> sure others might see it too:
> 
> ...
> 
> So to summarize, the qt libs themselves are linked against /opt/local/ 
> lib/..., but applications that are built with the qmake build system  
> are not.
> 
> --Jeremy

Thanks for pointing this out.

Over the next couple of days, I will update qt4-x11 to 4.5.1.
I will make the fix there.

-Marcus






From dweber at macports.org  Wed Apr 29 14:08:07 2009
From: dweber at macports.org (Darren Weber)
Date: Wed, 29 Apr 2009 14:08:07 -0700
Subject: [50222] trunk/dports/graphics
In-Reply-To: <2288E464-397F-464B-9160-2621F233DFF7@macports.org>
References: <20090427232702.18A15168F388@beta.macosforge.org>
	<5AB8AB79-1E8A-400E-BAA8-0E643BB68F72@macports.org>
	<b808b3510904271748w2cca31b4t935e28108ee4cbf7@mail.gmail.com>
	<2288E464-397F-464B-9160-2621F233DFF7@macports.org>
Message-ID: <b808b3510904291408l2946759etdf16dfcec27fb3f0@mail.gmail.com>

On Tue, Apr 28, 2009 at 4:30 AM, Ryan Schmidt <ryandesign at macports.org>wrote:

> On Apr 27, 2009, at 19:48, Darren Weber wrote:
>
>  On Mon, Apr 27, 2009 at 5:01 PM, Ryan Schmidt wrote:
>>
>>  Since this port uses cmake, have you considered using the cmake portgroup
>>> to simplify it?
>>>
>>
>> No, I didn't know such a portgroup exists and I have no idea how to use a
>> portgroup.
>>
>
> Portgroups are basically include statements, allowing you include a set of
> definitions that are common to a class of ports. There is a section on
> portgroups in the guide. Unfortunately it does not have any general
> explanation of what a portgroup is. It just describes the options available
> in some of the existing portgroups.
>
> http://guide.macports.org/#reference.portgroup
>
> The cmake portgroup is new and not yet documented in the guide, but you can
> read its source code here to see what it does:
>
> http://trac.macports.org/browser/trunk/dports/_resources/port1.0/
> group/cmake-1.0.tcl
>
> Basically, all ports that use cmake need to do certain similar things, for
> example depend on the cmake port, use cmake in the configure phase, specify
> the prefix using -DCMAKE_INSTALL_PREFIX instead of --prefix, etc.; the cmake
> portgroup exists to simplify such ports.
>


Interesting.  The vtk-devel will use options to cmake that conflict with
those in this portgroup (for a shared library build), ie:

    configure.args-append \
        -DBUILD_SHARED_LIBS:BOOL=ON \
        -DCMAKE_SKIP_BUILD_RPATH:BOOL=OFF \
        -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=OFF \
        -DCMAKE_INSTALL_RPATH:STRING=${prefix}/lib/${distname} \
        -DVTK_USE_RPATH:BOOL=ON

After a lot of reading and some testing, this combination of options appears
to be optimal for vtk-5.4.  There are some issues when building the examples
and testing binaries, but some post-destroot hacks with install_name_tool
will take care of that (a better solution might be a patch to the
CMakeLists.txt file for the examples and testing installation phase, which
should automatically apply the INSTALL_RPATH).

Best, Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090429/fec0be15/attachment.html>

From dweber at macports.org  Wed Apr 29 14:10:12 2009
From: dweber at macports.org (Darren Weber)
Date: Wed, 29 Apr 2009 14:10:12 -0700
Subject: [50222] trunk/dports/graphics
In-Reply-To: <b808b3510904291408l2946759etdf16dfcec27fb3f0@mail.gmail.com>
References: <20090427232702.18A15168F388@beta.macosforge.org>
	<5AB8AB79-1E8A-400E-BAA8-0E643BB68F72@macports.org>
	<b808b3510904271748w2cca31b4t935e28108ee4cbf7@mail.gmail.com>
	<2288E464-397F-464B-9160-2621F233DFF7@macports.org>
	<b808b3510904291408l2946759etdf16dfcec27fb3f0@mail.gmail.com>
Message-ID: <b808b3510904291410h6c3013a0obf4fdbf7379d7ecc@mail.gmail.com>

FYI, these are my current commens in the vtk-devel port (my local repo only
at this point), with regard to cmake RPATH config for macports build and
install:

# Notes on RPATH settings for the shared dylib build and install:
#
# CMake book, Appendix A, p 234: "CMAKE_SKIP_BUILD_RPATH: Do not include
RPATHs
# in the build tree.  Normally CMake uses the build tree for the RPATH when
# building executables etc. on systems that use RPATH.  When the software is
# installed the executables etc.  are relinked by CMake to have the install
# RPATH.  If this variable is set to true then the software is always built
with
# no RPATH."
#
# CMake book, Appendix B, p. 301: "... SKIP_BUILD_RPATH is a boolean
specifying
# whether to skip automatic generation of an rpath allowing the target to
run
# from the build tree.  BUILD_WITH_INSTALL_RPATH is a boolean specifying
whether
# to link the target in the build tree with the INSTALL_RPATH.  This takes
# precedence over SKIP_BUILD_RPATH and avoids the need for relinking before
# installation."
#
# Using CMAKE_SKIP_BUILD_RPATH:BOOL=OFF, we get all the executables and
dylibs
# built with the $build.dir in the rpath.  For this to work, we must also
have
# CMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=OFF.  After the build, at the destroot
# phase, all the installation candidates (which excludes the examples and
# testing binaries) have their rpath settings reset to the INSTALL_RPATH
(which
# should point to $prefix..., not the $destroot location).  VTK_USE_RPATH
# is required to ensure that rpath is set for all the installed executables
and
# dylibs.


Best, Darren



On Wed, Apr 29, 2009 at 2:08 PM, Darren Weber <dweber at macports.org> wrote:

>
>
> On Tue, Apr 28, 2009 at 4:30 AM, Ryan Schmidt <ryandesign at macports.org>wrote:
>
>> On Apr 27, 2009, at 19:48, Darren Weber wrote:
>>
>>  On Mon, Apr 27, 2009 at 5:01 PM, Ryan Schmidt wrote:
>>>
>>>  Since this port uses cmake, have you considered using the cmake
>>>> portgroup
>>>> to simplify it?
>>>>
>>>
>>> No, I didn't know such a portgroup exists and I have no idea how to use a
>>> portgroup.
>>>
>>
>> Portgroups are basically include statements, allowing you include a set of
>> definitions that are common to a class of ports. There is a section on
>> portgroups in the guide. Unfortunately it does not have any general
>> explanation of what a portgroup is. It just describes the options available
>> in some of the existing portgroups.
>>
>> http://guide.macports.org/#reference.portgroup
>>
>> The cmake portgroup is new and not yet documented in the guide, but you
>> can read its source code here to see what it does:
>>
>> http://trac.macports.org/browser/trunk/dports/_resources/port1.0/
>> group/cmake-1.0.tcl
>>
>> Basically, all ports that use cmake need to do certain similar things, for
>> example depend on the cmake port, use cmake in the configure phase, specify
>> the prefix using -DCMAKE_INSTALL_PREFIX instead of --prefix, etc.; the cmake
>> portgroup exists to simplify such ports.
>>
>
>
> Interesting.  The vtk-devel will use options to cmake that conflict with
> those in this portgroup (for a shared library build), ie:
>
>     configure.args-append \
>         -DBUILD_SHARED_LIBS:BOOL=ON \
>         -DCMAKE_SKIP_BUILD_RPATH:BOOL=OFF \
>         -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=OFF \
>         -DCMAKE_INSTALL_RPATH:STRING=${prefix}/lib/${distname} \
>         -DVTK_USE_RPATH:BOOL=ON
>
> After a lot of reading and some testing, this combination of options
> appears to be optimal for vtk-5.4.  There are some issues when building the
> examples and testing binaries, but some post-destroot hacks with
> install_name_tool will take care of that (a better solution might be a patch
> to the CMakeLists.txt file for the examples and testing installation phase,
> which should automatically apply the INSTALL_RPATH).
>
> Best, Darren
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090429/9384502e/attachment.html>

From dweber at macports.org  Wed Apr 29 14:21:13 2009
From: dweber at macports.org (Darren Weber)
Date: Wed, 29 Apr 2009 14:21:13 -0700
Subject: [50222] trunk/dports/graphics
In-Reply-To: <b808b3510904291408l2946759etdf16dfcec27fb3f0@mail.gmail.com>
References: <20090427232702.18A15168F388@beta.macosforge.org>
	<5AB8AB79-1E8A-400E-BAA8-0E643BB68F72@macports.org>
	<b808b3510904271748w2cca31b4t935e28108ee4cbf7@mail.gmail.com>
	<2288E464-397F-464B-9160-2621F233DFF7@macports.org>
	<b808b3510904291408l2946759etdf16dfcec27fb3f0@mail.gmail.com>
Message-ID: <b808b3510904291421r34952025k46ce07a326088f5@mail.gmail.com>

Oh, also vtk-devel is using a different build type,

-DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo

This is consistent with GNU distributions that use -O2 -g to provide some
degree of optimization and the capacity to attach to and debug running
processes, examine core dumps, etc.

Best, Darren

PS, The general cmake variables defined in vtk-devel are currently (among
others):

    -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo \
    -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON \
    -DCMAKE_INSTALL_PREFIX:PATH=${prefix} \
    -DCMAKE_INCLUDE_PATH:PATH=${prefix}/include \
    -DCMAKE_LIBRARY_PATH:PATH=${prefix}/lib \
    -DCMAKE_INSTALL_NAME_DIR:STRING=${prefix}/lib/${distname} \

Plus the shared dylib variant appends:

        -DBUILD_SHARED_LIBS:BOOL=ON \
        -DCMAKE_SKIP_BUILD_RPATH:BOOL=OFF \
        -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=OFF \
        -DCMAKE_INSTALL_RPATH:STRING=${prefix}/lib/${distname} \
        -DVTK_USE_RPATH:BOOL=ON

Some of these are in the cmake port group, some are not, for comparison see:
http://trac.macports.org/browser/trunk/dports/_resources/port1.0/group/cmake-1.0.tcl



On Wed, Apr 29, 2009 at 2:08 PM, Darren Weber <dweber at macports.org> wrote:

>
>
> On Tue, Apr 28, 2009 at 4:30 AM, Ryan Schmidt <ryandesign at macports.org>wrote:
>
>> On Apr 27, 2009, at 19:48, Darren Weber wrote:
>>
>>  On Mon, Apr 27, 2009 at 5:01 PM, Ryan Schmidt wrote:
>>>
>>>  Since this port uses cmake, have you considered using the cmake
>>>> portgroup
>>>> to simplify it?
>>>>
>>>
>>> No, I didn't know such a portgroup exists and I have no idea how to use a
>>> portgroup.
>>>
>>
>> Portgroups are basically include statements, allowing you include a set of
>> definitions that are common to a class of ports. There is a section on
>> portgroups in the guide. Unfortunately it does not have any general
>> explanation of what a portgroup is. It just describes the options available
>> in some of the existing portgroups.
>>
>> http://guide.macports.org/#reference.portgroup
>>
>> The cmake portgroup is new and not yet documented in the guide, but you
>> can read its source code here to see what it does:
>>
>> http://trac.macports.org/browser/trunk/dports/_resources/port1.0/
>> group/cmake-1.0.tcl
>>
>> Basically, all ports that use cmake need to do certain similar things, for
>> example depend on the cmake port, use cmake in the configure phase, specify
>> the prefix using -DCMAKE_INSTALL_PREFIX instead of --prefix, etc.; the cmake
>> portgroup exists to simplify such ports.
>>
>
>
> Interesting.  The vtk-devel will use options to cmake that conflict with
> those in this portgroup (for a shared library build), ie:
>
>     configure.args-append \
>         -DBUILD_SHARED_LIBS:BOOL=ON \
>         -DCMAKE_SKIP_BUILD_RPATH:BOOL=OFF \
>         -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=OFF \
>         -DCMAKE_INSTALL_RPATH:STRING=${prefix}/lib/${distname} \
>         -DVTK_USE_RPATH:BOOL=ON
>
> After a lot of reading and some testing, this combination of options
> appears to be optimal for vtk-5.4.  There are some issues when building the
> examples and testing binaries, but some post-destroot hacks with
> install_name_tool will take care of that (a better solution might be a patch
> to the CMakeLists.txt file for the examples and testing installation phase,
> which should automatically apply the INSTALL_RPATH).
>
> Best, Darren
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090429/670a0b0c/attachment-0001.html>

From jkh at apple.com  Wed Apr 29 15:07:24 2009
From: jkh at apple.com (Jordan K. Hubbard)
Date: Wed, 29 Apr 2009 15:07:24 -0700
Subject: xinstall glob question
In-Reply-To: <6D456519-C643-4031-9AC1-A9EF284932C8@lavergne.gotdns.org>
References: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>
	<6D456519-C643-4031-9AC1-A9EF284932C8@lavergne.gotdns.org>
Message-ID: <76A423F8-C583-45D6-BAF4-B8B7B8FA2134@apple.com>

Pretty much, yes.  I would also argue that (A) is clearer and easier  
to read, to say nothing of more efficient.  There are a number of  
processes being spawned in (B) - one for the sh(1) to run the for  
loop, another sh(1) to execute the find(1) in backticks, another for  
the find(1) itself, then n cp(1) invocations inside the loop.  That's  
a lot more fork/execs (which are expensive in MacOSX) than (A) (one).

- Jordan

On Apr 29, 2009, at 11:42 AM, Jeremy Lavergne wrote:

>> Are these equivalent?
>>
>> A.
>> eval xinstall -m 755 [glob {!${build.dir}/bin/*.dylib}] ${destroot}/ 
>> ${vtkExamplePath}/bin
>>
>> B.
>> cd ${build.dir}
>> for f in `find bin \! -name '*.dylib'`; do
>>  cp $f ${destroot}/${vtkExamplePath}/bin"
>> done
>
> The only difference I see is the mode setting.
> Feel free to get a second opinion from the seasoned veterans :-)
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


From raimue at macports.org  Wed Apr 29 15:37:29 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Thu, 30 Apr 2009 00:37:29 +0200
Subject: xinstall glob question
In-Reply-To: <b808b3510904291245n593b57d8q5819d5e1b0112a34@mail.gmail.com>
References: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>	<6D456519-C643-4031-9AC1-A9EF284932C8@lavergne.gotdns.org>
	<b808b3510904291245n593b57d8q5819d5e1b0112a34@mail.gmail.com>
Message-ID: <49F8D6A9.5010305@macports.org>

Darren Weber wrote:
> The {!<pattern>} syntax is supposed to NOT that file name <pattern>.  I
> have a directory of binary executables among a lot of .dylib files and I
> want to exclude all the .dylib files from the glob.

Tcl's glob is unable to invert a pattern. As you say, {!...} is not
going to work.

Some example how I would do this (untested!):

foreach f [glob ${build.dir}/bin/*] {
   if {![string match {*.dylib} ${f}]} {
     file copy ${f} ${destroot}/${vtkExamplePath}/bin/
   }
}

Rainer

From raimue at macports.org  Wed Apr 29 15:40:02 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Thu, 30 Apr 2009 00:40:02 +0200
Subject: [50222] trunk/dports/graphics
In-Reply-To: <b808b3510904291421r34952025k46ce07a326088f5@mail.gmail.com>
References: <20090427232702.18A15168F388@beta.macosforge.org>	<5AB8AB79-1E8A-400E-BAA8-0E643BB68F72@macports.org>	<b808b3510904271748w2cca31b4t935e28108ee4cbf7@mail.gmail.com>	<2288E464-397F-464B-9160-2621F233DFF7@macports.org>	<b808b3510904291408l2946759etdf16dfcec27fb3f0@mail.gmail.com>
	<b808b3510904291421r34952025k46ce07a326088f5@mail.gmail.com>
Message-ID: <49F8D742.9070903@macports.org>

Darren Weber wrote:
> 
> Oh, also vtk-devel is using a different build type,
> 
> -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo
> 
> This is consistent with GNU distributions that use -O2 -g to provide
> some degree of optimization and the capacity to attach to and debug
> running processes, examine core dumps, etc.

Personally, I would never use any optimization if I plan to attach a
debugger to it later. It may be hard to follow steps in optimized code.

By default ports are built using -O2, as defined in configure.optflags.

Rainer

From raimue at macports.org  Wed Apr 29 16:27:17 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 30 Apr 2009 01:27:17 +0200
Subject: lint version hardcode
In-Reply-To: <237195A0-9F50-4D9C-A760-2F9FFE789D7E@macports.org>
References: <49F3AC99.4020209@macports.org>
	<BE26E68E-3613-42E2-8C07-8FF3737C44AC@macports.org>
	<49F4EE19.4050501@macports.org>
	<25920591-C535-4334-BE40-C64B2A86BF98@macports.org>
	<6D371DB5-6D2B-4D7A-8AA0-754320D6381D@macports.org>
	<64FDA033-AB77-4DB8-B58E-4285CED27663@macports.org>
	<49F643B3.2010701@macports.org>
	<237195A0-9F50-4D9C-A760-2F9FFE789D7E@macports.org>
Message-ID: <49F8E255.30202@macports.org>

Ryan Schmidt wrote:
> Ok, I added php5peclextension.setup in r50230. I didn't realize we  
> had this list of portgroups in portlint. 

This was added by me as I implemented the hardcoded version check based
on existing PortGroups. So it is very new :-)

> Can't we just make it accept
> any ${portgroup}.setup?

As of r50375 lint will ignore any lines starting with
"^[a-z0-9]+\.setup". For the name this is the same regex used to verify
a PortGroup line. This should be sufficient as *.setup is usually only
defined in port groups.

<http://trac.macports.org/changeset/50375>

Rainer

From dweber at macports.org  Wed Apr 29 17:30:07 2009
From: dweber at macports.org (Darren Weber)
Date: Wed, 29 Apr 2009 17:30:07 -0700
Subject: [50222] trunk/dports/graphics
In-Reply-To: <49F8D742.9070903@macports.org>
References: <20090427232702.18A15168F388@beta.macosforge.org>
	<5AB8AB79-1E8A-400E-BAA8-0E643BB68F72@macports.org>
	<b808b3510904271748w2cca31b4t935e28108ee4cbf7@mail.gmail.com>
	<2288E464-397F-464B-9160-2621F233DFF7@macports.org>
	<b808b3510904291408l2946759etdf16dfcec27fb3f0@mail.gmail.com>
	<b808b3510904291421r34952025k46ce07a326088f5@mail.gmail.com>
	<49F8D742.9070903@macports.org>
Message-ID: <b808b3510904291730h62c9aab9ndb056ba9cbe491a6@mail.gmail.com>

On Wed, Apr 29, 2009 at 3:40 PM, Rainer M?ller <raimue at macports.org> wrote:

> Darren Weber wrote:
> >
> > Oh, also vtk-devel is using a different build type,
> >
> > -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo
> >
> > This is consistent with GNU distributions that use -O2 -g to provide
> > some degree of optimization and the capacity to attach to and debug
> > running processes, examine core dumps, etc.
>
> Personally, I would never use any optimization if I plan to attach a
> debugger to it later. It may be hard to follow steps in optimized code.
>
> By default ports are built using -O2, as defined in configure.optflags.
>
> Rainer
>


Does configure.optflags apply to CMAKE?  I don't think so.

While I agree that debugging during software development is better without
optimization, the real compromise here is for the release version of the vtk
library to contain some debug symbols (the optimisation is a given at the
point of a stable release).  I suppose a pure debug port or variant could be
used to provide the library with no optimisation and debug symbols.
However, for the most part, we should expect any release software that will
depend on the library to run better with the optimised library installed.

Take care, Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090429/73fd086e/attachment.html>

From raimue at macports.org  Wed Apr 29 17:42:06 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Thu, 30 Apr 2009 02:42:06 +0200
Subject: [50222] trunk/dports/graphics
In-Reply-To: <b808b3510904291730h62c9aab9ndb056ba9cbe491a6@mail.gmail.com>
References: <20090427232702.18A15168F388@beta.macosforge.org>	
	<5AB8AB79-1E8A-400E-BAA8-0E643BB68F72@macports.org>	
	<b808b3510904271748w2cca31b4t935e28108ee4cbf7@mail.gmail.com>	
	<2288E464-397F-464B-9160-2621F233DFF7@macports.org>	
	<b808b3510904291408l2946759etdf16dfcec27fb3f0@mail.gmail.com>	
	<b808b3510904291421r34952025k46ce07a326088f5@mail.gmail.com>	
	<49F8D742.9070903@macports.org>
	<b808b3510904291730h62c9aab9ndb056ba9cbe491a6@mail.gmail.com>
Message-ID: <49F8F3DE.30206@macports.org>

Darren Weber wrote:
> Does configure.optflags apply to CMAKE?  I don't think so.

Does not look like it does. I am not sure if this would be applicable
and how it would be done.

> While I agree that debugging during software development is better
> without optimization, the real compromise here is for the release
> version of the vtk library to contain some debug symbols (the
> optimisation is a given at the point of a stable release).  I suppose a
> pure debug port or variant could be used to provide the library with no
> optimisation and debug symbols.  However, for the most part, we should
> expect any release software that will depend on the library to run
> better with the optimised library installed.

Are you sure the debug symbols are installed at all if you use it like that?

Unlike on other systems, Mac OS X (as of Leopard) stores debug symbols
in external directories called *.dSYM by default. So if you are just
using -g, I am not even sure this will change anything what gets installed.

The cmake port groups already adds a +debug variant. I don't know cmake
internals, so I cannot tell what this -DCMAKE_BUILD_TYPE=debugFull will
actually do and which flags it will add to compiler calls.

Rainer

From ryandesign at macports.org  Wed Apr 29 21:44:12 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 29 Apr 2009 23:44:12 -0500
Subject: lint version hardcode
In-Reply-To: <49F8E255.30202@macports.org>
References: <49F3AC99.4020209@macports.org>
	<BE26E68E-3613-42E2-8C07-8FF3737C44AC@macports.org>
	<49F4EE19.4050501@macports.org>
	<25920591-C535-4334-BE40-C64B2A86BF98@macports.org>
	<6D371DB5-6D2B-4D7A-8AA0-754320D6381D@macports.org>
	<64FDA033-AB77-4DB8-B58E-4285CED27663@macports.org>
	<49F643B3.2010701@macports.org>
	<237195A0-9F50-4D9C-A760-2F9FFE789D7E@macports.org>
	<49F8E255.30202@macports.org>
Message-ID: <EC590CFE-93A3-4592-8DC1-8BB165559B6D@macports.org>


On Apr 29, 2009, at 18:27, Rainer M?ller wrote:

>> Can't we just make it accept
>> any ${portgroup}.setup?
>
> As of r50375 lint will ignore any lines starting with
> "^[a-z0-9]+\.setup". For the name this is the same regex used to  
> verify
> a PortGroup line. This should be sufficient as *.setup is usually only
> defined in port groups.
>
> <http://trac.macports.org/changeset/50375>

I like this, thanks.



From ryandesign at macports.org  Wed Apr 29 23:28:31 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 30 Apr 2009 01:28:31 -0500
Subject: [50191] trunk/dports/php/php5-eaccelerator/Portfile
In-Reply-To: <20090427142930.3FA901686C27@beta.macosforge.org>
References: <20090427142930.3FA901686C27@beta.macosforge.org>
Message-ID: <83A7CCC4-4268-4F3E-8537-FA2E53291EE6@macports.org>

On Apr 27, 2009, at 09:29, alakazam at macports.org wrote:

> Revision: 50191
>           http://trac.macports.org/changeset/50191
> Author:   alakazam at macports.org
> Date:     2009-04-27 07:29:29 -0700 (Mon, 27 Apr 2009)
> Log Message:
> -----------
> Migrate php5-eaccelerator to the php5extension PortGroup

Did you try whether the port still works? I haven't tried it yet but  
I didn't think this would work because eAccelerator is not a normal  
PHP extension but a Zend extension and therefore needs to be loaded  
with the zend_extension directive and not the extension directive. I  
was going to add an option to the php5extension portgroup to allow  
you to specify what type of extension it is so that the correct  
directive can be written to the .ini file.


> Modified Paths:
> --------------
>     trunk/dports/php/php5-eaccelerator/Portfile
>
> Modified: trunk/dports/php/php5-eaccelerator/Portfile
> ===================================================================
> --- trunk/dports/php/php5-eaccelerator/Portfile	2009-04-27 14:27:24  
> UTC (rev 50190)
> +++ trunk/dports/php/php5-eaccelerator/Portfile	2009-04-27 14:29:29  
> UTC (rev 50191)
> @@ -1,9 +1,10 @@
>  # $Id$
>
>  PortSystem        1.0
> +PortGroup         php5extension 1.0
>
> -name              php5-eaccelerator
> -version           0.9.5.3
> +php5extension.setup eaccelerator 0.9.5.3
> +revision          1
>
>  categories        php www devel
>  platforms         darwin freebsd openbsd
> @@ -22,35 +23,9 @@
>  checksums         md5 caf797223739516882f870342f74b935 \
>                    sha1 6671a105497f41c4e93e0b84da516b72df159fc5 \
>                    rmd160 9da55beec18e7a36761b5556d3bb4d5292d21650
> -distname          eaccelerator-${version}
>  use_bzip2         yes
> -depends_lib       path:bin/phpize:php5
>  configure.args    --with-php-config=${prefix}/bin/php-config
>
> -pre-configure {
> -    system "cd ${worksrcpath}; phpize"
> -}
> -
> -destroot.destdir INSTALL_ROOT=${destroot}
> -
> -post-install {
> -
> -    set ini_file          "${prefix}/etc/php.ini"
> -    set extension_file    "${prefix}/lib/php/extensions/no-debug- 
> non-zts-20060613/eaccelerator.so"
> -    set eaccelerator_docs "http://eaccelerator.net/wiki/Settings"
> -
> -    ui_msg "
> -     
> ********************************************************************** 
> *****
> -    * To enable the eaccelerator extension in php, add or edit the  
> following
> -    * lines in ${ini_file}:
> -    *
> -    * zend_extension=\"${extension_file}\"
> -    *
> -    * For more information and details about configuration  
> settings, see
> -    * ${eaccelerator_docs}
> -     
> ********************************************************************** 
> *****"
> -}
> -
>  variant shared_memory description {Enable shared memory access  
> functions [only enable in trusted environments]} {
>      configure.args-append --with-eaccelerator-shared-memory
>  }

From nox at macports.org  Thu Apr 30 04:25:37 2009
From: nox at macports.org (nox)
Date: Thu, 30 Apr 2009 13:25:37 +0200
Subject: [50352] trunk/dports
In-Reply-To: <97A758C8-AAF1-467B-BB3C-A2576B70B551@macports.org>
References: <20090429173823.B656316B6646@beta.macosforge.org>
	<49F8A066.7090207@macports.org>
	<97A758C8-AAF1-467B-BB3C-A2576B70B551@macports.org>
Message-ID: <1593A618-8A8A-4752-B558-109A23F9508E@macports.org>

Le 29 avr. 09 ? 20:57, Ryan Schmidt a ?crit :

>
> On Apr 29, 2009, at 13:45, David Evans wrote:
>
>> While you're reconsidering categories, how about moving pango and  
>> gtk2 to devel from x11?  They're not just for X11 anymore. ;-)
>
> Sounds like a good idea to me. Any objection, Anthony?
>

Sure, go ahead!
Regards.

From n.oxyde at gmail.com  Thu Apr 30 06:51:31 2009
From: n.oxyde at gmail.com (nox)
Date: Thu, 30 Apr 2009 15:51:31 +0200
Subject: xinstall glob question
In-Reply-To: <49F8D6A9.5010305@macports.org>
References: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>	<6D456519-C643-4031-9AC1-A9EF284932C8@lavergne.gotdns.org>
	<b808b3510904291245n593b57d8q5819d5e1b0112a34@mail.gmail.com>
	<49F8D6A9.5010305@macports.org>
Message-ID: <2A94297F-ADD5-4E01-9AD9-DF390523F8D7@gmail.com>

Le 30 avr. 09 ? 00:37, Rainer M?ller a ?crit :

> Darren Weber wrote:
>> The {!<pattern>} syntax is supposed to NOT that file name  
>> <pattern>.  I
>> have a directory of binary executables among a lot of .dylib files  
>> and I
>> want to exclude all the .dylib files from the glob.
>
> Tcl's glob is unable to invert a pattern. As you say, {!...} is not
> going to work.
>
> Some example how I would do this (untested!):
>
> foreach f [glob ${build.dir}/bin/*] {
>   if {![string match {*.dylib} ${f}]} {
>     file copy ${f} ${destroot}/${vtkExamplePath}/bin/
>   }
> }
>
> Rainer

And on a side note, [glob -directory ${dir} ${pattern}] should be  
preferred over
[glob ${dir}/${pattern}], see glob(n).


From dweber at macports.org  Thu Apr 30 12:40:26 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 30 Apr 2009 12:40:26 -0700
Subject: renaming vtk ports
Message-ID: <b808b3510904301240g6de356c4lc205e85049cc0ca3@mail.gmail.com>

I'm working on vtk ports this week, mainly vtk-devel.

Given prior discussion in the mailing list and ticket 19000
http://trac.macports.org/ticket/19000

We've agreed to rename:

vtk -> vtk4 or vtk44  (I've created vtk44 in the svn trunk).
vtk5 -> vtk
vtk54 -> vtk-devel  (Done, in the svn trunk.)

The svn trunk currently contains (At revision 50417):
vtk/
vtk-devel/
vtk44/
vtk5/

With
vtk @ 4.4.2
vtk44 @ 4.4.2  (This is a copy of vtk, with an old version name)
vtk5 @ 5.2.1
vtk-devel @ 5.4.0  (Still working on this)

The next step to "renaming" the ports is to move vtk5 over to vtk and then
remove vtk5, leaving

vtk44 @ 4.4.2
vtk @ 5.2.1
vtk-devel @ 5.4.0

What is the best way to proceed with this?  Maybe:

svn delete vtk
svn rename vtk5 vtk

Apart from the practicality of to change the svn repository, what are the
implications for the ports system?  I have nothing installed that depends on
these ports, so 'port dependents vtk' will not show me anything
interesting.  Is there a master dependency tree somewhere that can show what
ports specify vtk as a library dependency (or is there an easy shell command
to get this, using find to get all the Portfiles and grep or something to
pull out lines with 'vtk' or something)?  If we can identify these
dependencies, we can also change those Portfiles.

Take care,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090430/abb0ed8a/attachment.html>

From dweber at macports.org  Thu Apr 30 12:54:21 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 30 Apr 2009 12:54:21 -0700
Subject: distfile spec in variant?
Message-ID: <b808b3510904301254v5d90cb2cp8840de3f710fa350@mail.gmail.com>

Working on graphics/vtk-devel, which includes a doc variant with a large
download and install time.

Is it possible to specify the distfile, fetch, extract, etc. entirely within
the variant?  If the variant is not selected, the port should not download
the documentation archive.

Thanks in advance,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090430/43412fdf/attachment.html>

From jmr at macports.org  Thu Apr 30 13:18:24 2009
From: jmr at macports.org (Joshua Root)
Date: Fri, 01 May 2009 06:18:24 +1000
Subject: renaming vtk ports
In-Reply-To: <b808b3510904301240g6de356c4lc205e85049cc0ca3@mail.gmail.com>
References: <b808b3510904301240g6de356c4lc205e85049cc0ca3@mail.gmail.com>
Message-ID: <49FA0790.8030309@macports.org>

Darren Weber wrote:
> 
> I'm working on vtk ports this week, mainly vtk-devel.
> 
> Given prior discussion in the mailing list and ticket 19000
> http://trac.macports.org/ticket/19000
> 
> We've agreed to rename:
> 
> vtk -> vtk4 or vtk44  (I've created vtk44 in the svn trunk).
> vtk5 -> vtk
> vtk54 -> vtk-devel  (Done, in the svn trunk.)
> 
> The svn trunk currently contains (At revision 50417):
> vtk/
> vtk-devel/
> vtk44/
> vtk5/
> 
> With
> vtk @ 4.4.2
> vtk44 @ 4.4.2  (This is a copy of vtk, with an old version name)
> vtk5 @ 5.2.1
> vtk-devel @ 5.4.0  (Still working on this)
> 
> The next step to "renaming" the ports is to move vtk5 over to vtk and
> then remove vtk5, leaving
> 
> vtk44 @ 4.4.2
> vtk @ 5.2.1
> vtk-devel @ 5.4.0
> 
> What is the best way to proceed with this?  Maybe:
> 
> svn delete vtk
> svn rename vtk5 vtk
> 
> Apart from the practicality of to change the svn repository, what are
> the implications for the ports system?  I have nothing installed that
> depends on these ports, so 'port dependents vtk' will not show me
> anything interesting.  Is there a master dependency tree somewhere that
> can show what ports specify vtk as a library dependency (or is there an
> easy shell command to get this, using find to get all the Portfiles and
> grep or something to pull out lines with 'vtk' or something)?  If we can
> identify these dependencies, we can also change those Portfiles.

You can't just rename ports. Anyone who has the existing port installed
will never see it in the outdated list, so they'll never get the new one
unless they happen to discover it and install it manually. Additionally,
if you change dependents to depend on the new ports, there will be
conflicts with the old ports.

Rather than delete ports here, you need to leave them as stubs that tell
users to uninstall them and install the replacement. You can't even have
the stub depend on the new port, since dependencies are upgraded first
and the new port will conflict with the pre-stub version of the old one.

Unfortunately there is simply no way to make this "just work" at
present, so renaming ports is to be avoided whenever possible.

As for the svn mechanics, use svn mv whenever possible rather than
delete/add.

- Josh

From jmr at macports.org  Thu Apr 30 13:19:37 2009
From: jmr at macports.org (Joshua Root)
Date: Fri, 01 May 2009 06:19:37 +1000
Subject: distfile spec in variant?
In-Reply-To: <b808b3510904301254v5d90cb2cp8840de3f710fa350@mail.gmail.com>
References: <b808b3510904301254v5d90cb2cp8840de3f710fa350@mail.gmail.com>
Message-ID: <49FA07D9.80600@macports.org>

Darren Weber wrote:
> 
> Working on graphics/vtk-devel, which includes a doc variant with a large
> download and install time.
> 
> Is it possible to specify the distfile, fetch, extract, etc. entirely
> within the variant?  If the variant is not selected, the port should not
> download the documentation archive.

Use distfiles-append and another post-extract (if necessary) in the variant.

- Josh

From dweber at macports.org  Thu Apr 30 13:22:28 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 30 Apr 2009 13:22:28 -0700
Subject: distfile spec in variant?
In-Reply-To: <49FA07D9.80600@macports.org>
References: <b808b3510904301254v5d90cb2cp8840de3f710fa350@mail.gmail.com>
	<49FA07D9.80600@macports.org>
Message-ID: <b808b3510904301322q64cbbab1t80326e361accfcc9@mail.gmail.com>

Figured it out with a few tests.  It works!

Thanks, Darren


On Thu, Apr 30, 2009 at 1:19 PM, Joshua Root <jmr at macports.org> wrote:

> Darren Weber wrote:
> >
> > Working on graphics/vtk-devel, which includes a doc variant with a large
> > download and install time.
> >
> > Is it possible to specify the distfile, fetch, extract, etc. entirely
> > within the variant?  If the variant is not selected, the port should not
> > download the documentation archive.
>
> Use distfiles-append and another post-extract (if necessary) in the
> variant.
>
> - Josh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090430/5382293c/attachment.html>

From dweber at macports.org  Thu Apr 30 14:36:32 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 30 Apr 2009 14:36:32 -0700
Subject: xinstall glob question
In-Reply-To: <49F8D6A9.5010305@macports.org>
References: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>
	<6D456519-C643-4031-9AC1-A9EF284932C8@lavergne.gotdns.org>
	<b808b3510904291245n593b57d8q5819d5e1b0112a34@mail.gmail.com>
	<49F8D6A9.5010305@macports.org>
Message-ID: <b808b3510904301436n49ae3553i470ffa5200363e6f@mail.gmail.com>

On Wed, Apr 29, 2009 at 3:37 PM, Rainer M?ller <raimue at macports.org> wrote:

> Darren Weber wrote:
> > The {!<pattern>} syntax is supposed to NOT that file name <pattern>.  I
> > have a directory of binary executables among a lot of .dylib files and I
> > want to exclude all the .dylib files from the glob.
>
> Tcl's glob is unable to invert a pattern. As you say, {!...} is not
> going to work.
>
> Some example how I would do this (untested!):
>
> foreach f [glob ${build.dir}/bin/*] {
>   if {![string match {*.dylib} ${f}]} {
>     file copy ${f} ${destroot}/${vtkExamplePath}/bin/
>   }
> }
>
> Rainer
>


OK, this looks promising.  I forget how to drop into a tcl shell while
running macports.  It would be really nice to be able to set a breakpoint in
a Portfile somehow.

In python, we can import the pydb module and call it at any point in the
program, eg:
http://bashdb.sourceforge.net/pydb/pydb/lib/subsection-calling-pydb-inside-program.html

Does tcl have an equivalent?  How would you set a breakpoint in a Portfile?

Take care, Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090430/bbe01cf9/attachment.html>

From dweber at macports.org  Thu Apr 30 14:40:02 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 30 Apr 2009 14:40:02 -0700
Subject: xinstall glob question
In-Reply-To: <b808b3510904301436n49ae3553i470ffa5200363e6f@mail.gmail.com>
References: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>
	<6D456519-C643-4031-9AC1-A9EF284932C8@lavergne.gotdns.org>
	<b808b3510904291245n593b57d8q5819d5e1b0112a34@mail.gmail.com>
	<49F8D6A9.5010305@macports.org>
	<b808b3510904301436n49ae3553i470ffa5200363e6f@mail.gmail.com>
Message-ID: <b808b3510904301440l283e2946w890d13fced332cfa@mail.gmail.com>

Maybe this project is onto something to tcl debugging:
http://dashx.wiki.sourceforge.net/Scripting-Tcl


On Thu, Apr 30, 2009 at 2:36 PM, Darren Weber <dweber at macports.org> wrote:

>
>
> On Wed, Apr 29, 2009 at 3:37 PM, Rainer M?ller <raimue at macports.org>wrote:
>
>> Darren Weber wrote:
>> > The {!<pattern>} syntax is supposed to NOT that file name <pattern>.  I
>> > have a directory of binary executables among a lot of .dylib files and I
>> > want to exclude all the .dylib files from the glob.
>>
>> Tcl's glob is unable to invert a pattern. As you say, {!...} is not
>> going to work.
>>
>> Some example how I would do this (untested!):
>>
>> foreach f [glob ${build.dir}/bin/*] {
>>   if {![string match {*.dylib} ${f}]} {
>>     file copy ${f} ${destroot}/${vtkExamplePath}/bin/
>>   }
>> }
>>
>> Rainer
>>
>
>
> OK, this looks promising.  I forget how to drop into a tcl shell while
> running macports.  It would be really nice to be able to set a breakpoint in
> a Portfile somehow.
>
> In python, we can import the pydb module and call it at any point in the
> program, eg:
>
> http://bashdb.sourceforge.net/pydb/pydb/lib/subsection-calling-pydb-inside-program.html
>
> Does tcl have an equivalent?  How would you set a breakpoint in a Portfile?
>
> Take care, Darren
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090430/16675832/attachment-0001.html>

From dweber at macports.org  Thu Apr 30 14:42:08 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 30 Apr 2009 14:42:08 -0700
Subject: xinstall glob question
In-Reply-To: <b808b3510904301440l283e2946w890d13fced332cfa@mail.gmail.com>
References: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>
	<6D456519-C643-4031-9AC1-A9EF284932C8@lavergne.gotdns.org>
	<b808b3510904291245n593b57d8q5819d5e1b0112a34@mail.gmail.com>
	<49F8D6A9.5010305@macports.org>
	<b808b3510904301436n49ae3553i470ffa5200363e6f@mail.gmail.com>
	<b808b3510904301440l283e2946w890d13fced332cfa@mail.gmail.com>
Message-ID: <b808b3510904301442p61b088d5y2202bc6e68a8cead@mail.gmail.com>

Similarly, perhaps this module could be adapted into port somehow:
http://wiki.tcl.tk/11850


On Thu, Apr 30, 2009 at 2:40 PM, Darren Weber <dweber at macports.org> wrote:

>
> Maybe this project is onto something to tcl debugging:
> http://dashx.wiki.sourceforge.net/Scripting-Tcl
>
>
>
> On Thu, Apr 30, 2009 at 2:36 PM, Darren Weber <dweber at macports.org> wrote:
>
>>
>>
>> On Wed, Apr 29, 2009 at 3:37 PM, Rainer M?ller <raimue at macports.org>wrote:
>>
>>> Darren Weber wrote:
>>> > The {!<pattern>} syntax is supposed to NOT that file name <pattern>.  I
>>> > have a directory of binary executables among a lot of .dylib files and
>>> I
>>> > want to exclude all the .dylib files from the glob.
>>>
>>> Tcl's glob is unable to invert a pattern. As you say, {!...} is not
>>> going to work.
>>>
>>> Some example how I would do this (untested!):
>>>
>>> foreach f [glob ${build.dir}/bin/*] {
>>>   if {![string match {*.dylib} ${f}]} {
>>>     file copy ${f} ${destroot}/${vtkExamplePath}/bin/
>>>   }
>>> }
>>>
>>> Rainer
>>>
>>
>>
>> OK, this looks promising.  I forget how to drop into a tcl shell while
>> running macports.  It would be really nice to be able to set a breakpoint in
>> a Portfile somehow.
>>
>> In python, we can import the pydb module and call it at any point in the
>> program, eg:
>>
>> http://bashdb.sourceforge.net/pydb/pydb/lib/subsection-calling-pydb-inside-program.html
>>
>> Does tcl have an equivalent?  How would you set a breakpoint in a
>> Portfile?
>>
>> Take care, Darren
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090430/3c79ff9c/attachment.html>

From dweber at macports.org  Thu Apr 30 14:55:52 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 30 Apr 2009 14:55:52 -0700
Subject: xinstall glob question
In-Reply-To: <49F8D6A9.5010305@macports.org>
References: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>
	<6D456519-C643-4031-9AC1-A9EF284932C8@lavergne.gotdns.org>
	<b808b3510904291245n593b57d8q5819d5e1b0112a34@mail.gmail.com>
	<49F8D6A9.5010305@macports.org>
Message-ID: <b808b3510904301455t18839822qb32bd5626a95f59d@mail.gmail.com>

On Wed, Apr 29, 2009 at 3:37 PM, Rainer M?ller <raimue at macports.org> wrote:

> Darren Weber wrote:
> > The {!<pattern>} syntax is supposed to NOT that file name <pattern>.  I
> > have a directory of binary executables among a lot of .dylib files and I
> > want to exclude all the .dylib files from the glob.
>
> Tcl's glob is unable to invert a pattern. As you say, {!...} is not
> going to work.
>
> Some example how I would do this (untested!):
>
> foreach f [glob ${build.dir}/bin/*] {
>   if {![string match {*.dylib} ${f}]} {
>     file copy ${f} ${destroot}/${vtkExamplePath}/bin/
>   }
> }
>
> Rainer
>


Will the tcl 'file copy' work recursively?  Some of the items from
${build.dir}/bin are .app directories.

Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090430/c92e77d6/attachment.html>

From jjstickel at vcn.com  Thu Apr 30 15:01:47 2009
From: jjstickel at vcn.com (Jonathan Stickel)
Date: Thu, 30 Apr 2009 16:01:47 -0600
Subject: renaming vtk ports
In-Reply-To: <mailman.2016.1241127645.597.macports-dev@lists.macosforge.org>
References: <mailman.2016.1241127645.597.macports-dev@lists.macosforge.org>
Message-ID: <49FA1FCB.8040606@vcn.com>


On 4/30/09 macports-dev-request at lists.macosforge.org wrote:
> Date: Thu, 30 Apr 2009 12:40:26 -0700
> From: Darren Weber <dweber at macports.org>
> To: macports-dev Development <macports-dev at lists.macosforge.org>
> Cc: tgamblin at cs.unc.edu
> Subject: renaming vtk ports
> Message-ID:
> 	<b808b3510904301240g6de356c4lc205e85049cc0ca3 at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> I'm working on vtk ports this week, mainly vtk-devel.
> 
> Given prior discussion in the mailing list and ticket 19000
> http://trac.macports.org/ticket/19000
> 
> We've agreed to rename:
> 
> vtk -> vtk4 or vtk44  (I've created vtk44 in the svn trunk).
> vtk5 -> vtk
> vtk54 -> vtk-devel  (Done, in the svn trunk.)
> 
> The svn trunk currently contains (At revision 50417):
> vtk/
> vtk-devel/
> vtk44/
> vtk5/
> 
> With
> vtk @ 4.4.2
> vtk44 @ 4.4.2  (This is a copy of vtk, with an old version name)
> vtk5 @ 5.2.1
> vtk-devel @ 5.4.0  (Still working on this)
> 
> The next step to "renaming" the ports is to move vtk5 over to vtk and then
> remove vtk5, leaving
> 
> vtk44 @ 4.4.2
> vtk @ 5.2.1
> vtk-devel @ 5.4.0
> 
> What is the best way to proceed with this?  Maybe:
> 
> svn delete vtk
> svn rename vtk5 vtk
> 
> Apart from the practicality of to change the svn repository, what are the
> implications for the ports system?  I have nothing installed that depends on
> these ports, so 'port dependents vtk' will not show me anything
> interesting.  Is there a master dependency tree somewhere that can show what
> ports specify vtk as a library dependency (or is there an easy shell command
> to get this, using find to get all the Portfiles and grep or something to
> pull out lines with 'vtk' or something)?  If we can identify these
> dependencies, we can also change those Portfiles.

Related to vtk ports, I want to point out a ticket I submitted today:

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

I report that using x11prefix for libGL does not work on Tiger.  Since 
x11prefix is going away, it is probably a good idea to correct this 
regardless of the problem on Tiger.

Thanks,
Jonathan

From jmr at macports.org  Thu Apr 30 15:02:46 2009
From: jmr at macports.org (Joshua Root)
Date: Fri, 01 May 2009 08:02:46 +1000
Subject: xinstall glob question
In-Reply-To: <b808b3510904301455t18839822qb32bd5626a95f59d@mail.gmail.com>
References: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>	<6D456519-C643-4031-9AC1-A9EF284932C8@lavergne.gotdns.org>	<b808b3510904291245n593b57d8q5819d5e1b0112a34@mail.gmail.com>	<49F8D6A9.5010305@macports.org>
	<b808b3510904301455t18839822qb32bd5626a95f59d@mail.gmail.com>
Message-ID: <49FA2006.3060207@macports.org>

Darren Weber wrote:
> 
> 
> On Wed, Apr 29, 2009 at 3:37 PM, Rainer M?ller <raimue at macports.org
> <mailto:raimue at macports.org>> wrote:
> 
>     Darren Weber wrote:
>     > The {!<pattern>} syntax is supposed to NOT that file name
>     <pattern>.  I
>     > have a directory of binary executables among a lot of .dylib files
>     and I
>     > want to exclude all the .dylib files from the glob.
> 
>     Tcl's glob is unable to invert a pattern. As you say, {!...} is not
>     going to work.
> 
>     Some example how I would do this (untested!):
> 
>     foreach f [glob ${build.dir}/bin/*] {
>       if {![string match {*.dylib} ${f}]} {
>         file copy ${f} ${destroot}/${vtkExamplePath}/bin/
>       }
>     }
> 
>     Rainer
> 
> 
> 
> Will the tcl 'file copy' work recursively?  Some of the items from
> ${build.dir}/bin are .app directories.

Yes, see `man n file`. In Portfiles, you can use 'copy' as a synonym for
'file copy' BTW. <http://guide.macports.org/#reference.tcl-extensions>

- Josh

From dweber at macports.org  Thu Apr 30 15:18:22 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 30 Apr 2009 15:18:22 -0700
Subject: xinstall glob question
In-Reply-To: <49FA2006.3060207@macports.org>
References: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>
	<6D456519-C643-4031-9AC1-A9EF284932C8@lavergne.gotdns.org>
	<b808b3510904291245n593b57d8q5819d5e1b0112a34@mail.gmail.com>
	<49F8D6A9.5010305@macports.org>
	<b808b3510904301455t18839822qb32bd5626a95f59d@mail.gmail.com>
	<49FA2006.3060207@macports.org>
Message-ID: <b808b3510904301518h13c49fb1sea648bc3776a88cf@mail.gmail.com>

Please take a look at this mess to reset RPATH for all libs in a set of
binaries:

system "
    cd ${build.dir};
    find ${destroot}/${vtkExamplePath}/bin | grep -e '\[^(bin)\]\$' >
find.txt;
    for f in `cat find.txt`; do
        if \[ -f \${f} \] && \[ -x \${f} \]; then
            echo install_name_tool changing link libs for \${f};
            otool -L \${f} | grep 'libvtk' > otool_libs.txt;
            for lib in `cat otool_libs.txt`; do
                newlib=`echo \${lib} | sed
s#${build.dir}/bin#${prefix}/lib/${distname}#`;
                install_name_tool -change \${lib} \${newlib} \${f};
            done;
            rm otool_libs.txt;
        fi;
    done;
    rm find.txt;
    "

It works, but can it be done more efficiently?

Can you do file tests in tcl, like the bash tests [ -f $f ] && [ -x $f ] ?

Darren

PS, Don't ask me why it's required ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090430/160918ea/attachment.html>

From ryandesign at macports.org  Thu Apr 30 15:19:29 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 30 Apr 2009 17:19:29 -0500
Subject: xinstall glob question
In-Reply-To: <b808b3510904301436n49ae3553i470ffa5200363e6f@mail.gmail.com>
References: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>
	<6D456519-C643-4031-9AC1-A9EF284932C8@lavergne.gotdns.org>
	<b808b3510904291245n593b57d8q5819d5e1b0112a34@mail.gmail.com>
	<49F8D6A9.5010305@macports.org>
	<b808b3510904301436n49ae3553i470ffa5200363e6f@mail.gmail.com>
Message-ID: <594E0297-1F88-46EA-AD62-A6DBF7C49C8E@macports.org>


On Apr 30, 2009, at 16:36, Darren Weber wrote:

> I forget how to drop into a tcl shell while running macports.

I'm not sure what you mean.

> It would be really nice to be able to set a breakpoint in a  
> Portfile somehow.

I'm not aware of a way to do this.

I haven't looked at the links you sent.


From dweber at macports.org  Thu Apr 30 15:23:49 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 30 Apr 2009 15:23:49 -0700
Subject: renaming vtk ports
In-Reply-To: <49FA1FCB.8040606@vcn.com>
References: <mailman.2016.1241127645.597.macports-dev@lists.macosforge.org>
	<49FA1FCB.8040606@vcn.com>
Message-ID: <b808b3510904301523m4eb049afi91cd889f0500fab0@mail.gmail.com>

I've removed $x11prefix from the x11 variant in vtk-devel (@5.4.0 in the svn
trunk).  I've yet to test the x11 variant, but I will compare the settings
against vtk5.   I suppose your ticket applies to vtk5 and I'm not doing any
work on that (all my attention is on vtk-devel, as that is the most recent
release).

Best, Darren



On Thu, Apr 30, 2009 at 3:01 PM, Jonathan Stickel <jjstickel at vcn.com> wrote:

>
> On 4/30/09 macports-dev-request at lists.macosforge.org wrote:
>
>> Date: Thu, 30 Apr 2009 12:40:26 -0700
>> From: Darren Weber <dweber at macports.org>
>> To: macports-dev Development <macports-dev at lists.macosforge.org>
>> Cc: tgamblin at cs.unc.edu
>> Subject: renaming vtk ports
>> Message-ID:
>>        <b808b3510904301240g6de356c4lc205e85049cc0ca3 at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>>
>> I'm working on vtk ports this week, mainly vtk-devel.
>>
>> Given prior discussion in the mailing list and ticket 19000
>> http://trac.macports.org/ticket/19000
>>
>> We've agreed to rename:
>>
>> vtk -> vtk4 or vtk44  (I've created vtk44 in the svn trunk).
>> vtk5 -> vtk
>> vtk54 -> vtk-devel  (Done, in the svn trunk.)
>>
>> The svn trunk currently contains (At revision 50417):
>> vtk/
>> vtk-devel/
>> vtk44/
>> vtk5/
>>
>> With
>> vtk @ 4.4.2
>> vtk44 @ 4.4.2  (This is a copy of vtk, with an old version name)
>> vtk5 @ 5.2.1
>> vtk-devel @ 5.4.0  (Still working on this)
>>
>> The next step to "renaming" the ports is to move vtk5 over to vtk and then
>> remove vtk5, leaving
>>
>> vtk44 @ 4.4.2
>> vtk @ 5.2.1
>> vtk-devel @ 5.4.0
>>
>> What is the best way to proceed with this?  Maybe:
>>
>> svn delete vtk
>> svn rename vtk5 vtk
>>
>> Apart from the practicality of to change the svn repository, what are the
>> implications for the ports system?  I have nothing installed that depends
>> on
>> these ports, so 'port dependents vtk' will not show me anything
>> interesting.  Is there a master dependency tree somewhere that can show
>> what
>> ports specify vtk as a library dependency (or is there an easy shell
>> command
>> to get this, using find to get all the Portfiles and grep or something to
>> pull out lines with 'vtk' or something)?  If we can identify these
>> dependencies, we can also change those Portfiles.
>>
>
> Related to vtk ports, I want to point out a ticket I submitted today:
>
> http://trac.macports.org/ticket/19492
>
> I report that using x11prefix for libGL does not work on Tiger.  Since
> x11prefix is going away, it is probably a good idea to correct this
> regardless of the problem on Tiger.
>
> Thanks,
> Jonathan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090430/b748248e/attachment.html>

From ryandesign at macports.org  Thu Apr 30 15:24:07 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 30 Apr 2009 17:24:07 -0500
Subject: xinstall glob question
In-Reply-To: <b808b3510904301518h13c49fb1sea648bc3776a88cf@mail.gmail.com>
References: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>
	<6D456519-C643-4031-9AC1-A9EF284932C8@lavergne.gotdns.org>
	<b808b3510904291245n593b57d8q5819d5e1b0112a34@mail.gmail.com>
	<49F8D6A9.5010305@macports.org>
	<b808b3510904301455t18839822qb32bd5626a95f59d@mail.gmail.com>
	<49FA2006.3060207@macports.org>
	<b808b3510904301518h13c49fb1sea648bc3776a88cf@mail.gmail.com>
Message-ID: <D3F48D40-2E44-4D0B-9963-9B1AB13F2F9C@macports.org>

On Apr 30, 2009, at 17:18, Darren Weber wrote:

> Please take a look at this mess to reset RPATH for all libs in a  
> set of binaries:
>
> system "
>     cd ${build.dir};
>     find ${destroot}/${vtkExamplePath}/bin | grep -e '\[^(bin)\]\$'  
> > find.txt;
>     for f in `cat find.txt`; do
>         if \[ -f \${f} \] && \[ -x \${f} \]; then
>             echo install_name_tool changing link libs for \${f};
>             otool -L \${f} | grep 'libvtk' > otool_libs.txt;
>             for lib in `cat otool_libs.txt`; do
>                 newlib=`echo \${lib} | sed s#${build.dir}/bin#$ 
> {prefix}/lib/${distname}#`;
>                 install_name_tool -change \${lib} \${newlib} \${f};
>             done;
>             rm otool_libs.txt;
>         fi;
>     done;
>     rm find.txt;
>     "
>
> It works, but can it be done more efficiently?
>
> Can you do file tests in tcl, like the bash tests [ -f $f ] && [ -x  
> $f ] ?

Sure, those are respectively "file isfile" and "file executable".  
Take a look at the manual for the file command:

http://wiki.tcl.tk/1041


> PS, Don't ask me why it's required ;-)

I'm scared to...


From raimue at macports.org  Thu Apr 30 15:25:23 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Fri, 01 May 2009 00:25:23 +0200
Subject: xinstall glob question
In-Reply-To: <b808b3510904301436n49ae3553i470ffa5200363e6f@mail.gmail.com>
References: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>	
	<6D456519-C643-4031-9AC1-A9EF284932C8@lavergne.gotdns.org>	
	<b808b3510904291245n593b57d8q5819d5e1b0112a34@mail.gmail.com>	
	<49F8D6A9.5010305@macports.org>
	<b808b3510904301436n49ae3553i470ffa5200363e6f@mail.gmail.com>
Message-ID: <49FA2553.9010507@macports.org>

On 2009-04-30 23:36, Darren Weber wrote:
> In python, we can import the pydb module and call it at any point in the
> program, eg:
> http://bashdb.sourceforge.net/pydb/pydb/lib/subsection-calling-pydb-inside-program.html
> 
> Does tcl have an equivalent?  How would you set a breakpoint in a Portfile?

No, there is no way to set a breakpoint as much as I know. Also, I don't
think it would ever be possible to do this while running inside MacPorts.

But this could be helpful:
<http://trac.macports.org/wiki/CommittersTipsAndTricks#DoExplorativeProgrammingintclshwithReadlineSupport>

Rainer

From ryandesign at macports.org  Thu Apr 30 15:26:31 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 30 Apr 2009 17:26:31 -0500
Subject: [50191] trunk/dports/php/php5-eaccelerator/Portfile
In-Reply-To: <83A7CCC4-4268-4F3E-8537-FA2E53291EE6@macports.org>
References: <20090427142930.3FA901686C27@beta.macosforge.org>
	<83A7CCC4-4268-4F3E-8537-FA2E53291EE6@macports.org>
Message-ID: <E72587F1-CBC6-4809-8FB6-C409E0D84B81@macports.org>


On Apr 30, 2009, at 01:28, Ryan Schmidt wrote:

> On Apr 27, 2009, at 09:29, alakazam at macports.org wrote:
>
>> Revision: 50191
>>           http://trac.macports.org/changeset/50191
>> Author:   alakazam at macports.org
>> Date:     2009-04-27 07:29:29 -0700 (Mon, 27 Apr 2009)
>> Log Message:
>> -----------
>> Migrate php5-eaccelerator to the php5extension PortGroup
>
> Did you try whether the port still works? I haven't tried it yet  
> but I didn't think this would work because eAccelerator is not a  
> normal PHP extension but a Zend extension and therefore needs to be  
> loaded with the zend_extension directive and not the extension  
> directive. I was going to add an option to the php5extension  
> portgroup to allow you to specify what type of extension it is so  
> that the correct directive can be written to the .ini file.

Ok, it looks like eAccelerator is unique in that it can be used as  
either a Zend extension or as a regular extension, which is why it  
still works with the portgroup:

http://eaccelerator.net/wiki/ 
InstallFromSource#Step3.ConfiguringeAccelerator

But I can't tell which method is preferred or why.

I'll still have to add Zend extension capability to the portgroup for  
the other Zend extension ports that aren't so flexible.


From ryandesign at macports.org  Thu Apr 30 16:22:49 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 30 Apr 2009 18:22:49 -0500
Subject: [50431] trunk/dports/textproc
In-Reply-To: <20090430221724.BAB0516CE8BA@beta.macosforge.org>
References: <20090430221724.BAB0516CE8BA@beta.macosforge.org>
Message-ID: <6CD2436C-629B-47B1-9033-9A8888BB427A@macports.org>

On Apr 30, 2009, at 17:17, takanori at macports.org wrote:

> Revision: 50431
>           http://trac.macports.org/changeset/50431
> Author:   takanori at macports.org
> Date:     2009-04-30 15:17:24 -0700 (Thu, 30 Apr 2009)
> Log Message:
> -----------
> New port: eblook

[snip]

> Added: trunk/dports/textproc/eblook/files/patch-configure.diff
> ===================================================================
> --- trunk/dports/textproc/eblook/files/patch- 
> configure.diff	                        (rev 0)
> +++ trunk/dports/textproc/eblook/files/patch-configure.diff	 
> 2009-04-30 22:17:24 UTC (rev 50431)
> @@ -0,0 +1,86 @@
> +--- configure	2004-06-19 11:30:49.000000000 +0900
> ++++ configure	2007-09-16 20:06:43.000000000 +0900
> +@@ -21311,14 +21311,82 @@
> +
> +
> +
> ++ac_func=iconv
> ++save_LIBS="$LIBS"
> ++LIBS="$LIBS -L/opt/local/lib -liconv"
> ++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.  */

[snip]

It looks like this patch hard-codes the /opt/local path. You need to  
accommodate alternate MacPorts install prefixes.



From dweber at macports.org  Thu Apr 30 16:35:32 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 30 Apr 2009 16:35:32 -0700
Subject: xinstall glob question
In-Reply-To: <D3F48D40-2E44-4D0B-9963-9B1AB13F2F9C@macports.org>
References: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>
	<6D456519-C643-4031-9AC1-A9EF284932C8@lavergne.gotdns.org>
	<b808b3510904291245n593b57d8q5819d5e1b0112a34@mail.gmail.com>
	<49F8D6A9.5010305@macports.org>
	<b808b3510904301455t18839822qb32bd5626a95f59d@mail.gmail.com>
	<49FA2006.3060207@macports.org>
	<b808b3510904301518h13c49fb1sea648bc3776a88cf@mail.gmail.com>
	<D3F48D40-2E44-4D0B-9963-9B1AB13F2F9C@macports.org>
Message-ID: <b808b3510904301635v6318d760g644b11c574c17301@mail.gmail.com>

It seems that I should be able to replace most of the system calls as
follows (orig system call is commented here, with tcl replacements below):

#system "
#    cd ${build.dir};
#    find ${destroot}/${vtkExamplePath}/bin | grep -e '\[^(bin)\]\$' >
find.txt;
#    for f in `cat find.txt`; do
#        if \[ -f \${f} \] && \[ -x \${f} \]; then
#            echo install_name_tool changing link libs for \${f};
#            otool -L \${f} | grep 'libvtk' > otool_libs.txt;
#            for lib in `cat otool_libs.txt`; do
#                newlib=`echo \${lib} | sed
s#${build.dir}/bin#${prefix}/lib/${distname}#`;
#                install_name_tool -change \${lib} \${newlib} \${f};
#            done;
#            rm otool_libs.txt;
#        fi;
#    done;
#    rm find.txt;
#    "


foreach f [glob ${destroot}/${vtkExamplePath}/bin/*] {
    if { string equal [file extension ${f}] ".app" } {
        set exeName [file rootname [lindex [file split $f] end]]
        set f [format "%s/Contents/MacOS/%s" ${f} ${exeName}]
    }
    if { expr [file isfile ${f}] && [file executable ${f}] } {
        system "
            cd ${build.dir};
            otool -L \${f} | grep 'libvtk' > otool_libs.txt;
            for lib in `cat otool_libs.txt`; do
                newlib=`echo \${lib} | sed
s#${build.dir}/bin#${prefix}/lib/${distname}#`;
                install_name_tool -change \${lib} \${newlib} \${f};
            done;
            rm otool_libs.txt;
            "
    }
}



There is some problem with the tcl equivalent.  While it appears to work in
tclsh, it doesn't work in the Portfile.  Any ideas?

Thanks in advance,
Darren





On Thu, Apr 30, 2009 at 3:24 PM, Ryan Schmidt <ryandesign at macports.org>wrote:

> On Apr 30, 2009, at 17:18, Darren Weber wrote:
>
>  Please take a look at this mess to reset RPATH for all libs in a set of
>> binaries:
>>
>> system "
>>    cd ${build.dir};
>>    find ${destroot}/${vtkExamplePath}/bin | grep -e '\[^(bin)\]\$' >
>> find.txt;
>>    for f in `cat find.txt`; do
>>        if \[ -f \${f} \] && \[ -x \${f} \]; then
>>            echo install_name_tool changing link libs for \${f};
>>            otool -L \${f} | grep 'libvtk' > otool_libs.txt;
>>            for lib in `cat otool_libs.txt`; do
>>                newlib=`echo \${lib} | sed
>> s#${build.dir}/bin#${prefix}/lib/${distname}#`;
>>                install_name_tool -change \${lib} \${newlib} \${f};
>>            done;
>>            rm otool_libs.txt;
>>        fi;
>>    done;
>>    rm find.txt;
>>    "
>>
>> It works, but can it be done more efficiently?
>>
>> Can you do file tests in tcl, like the bash tests [ -f $f ] && [ -x $f ] ?
>>
>
> Sure, those are respectively "file isfile" and "file executable". Take a
> look at the manual for the file command:
>
> http://wiki.tcl.tk/1041
>
>
>  PS, Don't ask me why it's required ;-)
>>
>
> I'm scared to...
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090430/a1a28fd0/attachment-0001.html>

From jeremyhu at macports.org  Thu Apr 30 16:42:02 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Thu, 30 Apr 2009 16:42:02 -0700
Subject: +system_x11 to bite the dust
In-Reply-To: <loom.20090429T204935-565@post.gmane.org>
References: <EEA15397-5D82-44CE-A36A-94DF37AA882F@macports.org>
	<loom.20090429T204935-565@post.gmane.org>
Message-ID: <0BE988FB-DCF7-49BA-9660-5F82595E4D53@macports.org>


On Apr 29, 2009, at 13:57, Marcus Calhoun-Lopez wrote:
> Isn't there a case to be made for hedging our bets?
>
> I think it's safe to say that not too long ago, the MacPorts X11  
> libraries
> were a mess of broken ports and inconsistent dependencies.
> Thanks to the hard work of a select few, this is no longer the case.
> If bit rot should ever creep into X11 again, I would not have a clue
> how to fix it.
>
> Because X11 is complicated but essential, shouldn't we keep the option
> of reverting to the Apple X11?
>
> My apologies if this sounds too much like the invalid
> "no, I like not using MP's X11 libs" reason.

I'd say it's a bit more verbose and rooted than just "I like it that  
way" ...

You bring up a good point, but I don't think it's as big a concern as  
you might think.

If it happens that I get hired by some company tomorrow and have some  
clause about not contributing to open source (they'd have to make a  
*VERY* good offer for that to be the case, but let's just play the  
assumption game for a while), then X11 might "bitrot", and whoever  
might take my place at Apple might not want to work with MacPorts.   
That would be unfortunate, but I don't think it would be as dire as  
you believe.  I've taken great strides to ensure that all bits are  
pushed into upstream.  The client side (which is what is mainly  
important) is almost identical to what is used on every other  
platform.  The upkeep at this point is mainly just updating version  
numbers in the Portfile.

The server and libGL are the more fragile points, and yeah, they may  
bitrot if something horrible happens (like the scenario I mentioned  
above)... but that's the risk we take with every package... and the  
server isn't critical, since users can easily fall back on the Apple- 
provided X11 server by just executing /A/Utilities/X11.app rather  
than /A/MacPorts/X11.app



From ryandesign at macports.org  Thu Apr 30 16:42:32 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 30 Apr 2009 18:42:32 -0500
Subject: xinstall glob question
In-Reply-To: <b808b3510904301635v6318d760g644b11c574c17301@mail.gmail.com>
References: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>
	<6D456519-C643-4031-9AC1-A9EF284932C8@lavergne.gotdns.org>
	<b808b3510904291245n593b57d8q5819d5e1b0112a34@mail.gmail.com>
	<49F8D6A9.5010305@macports.org>
	<b808b3510904301455t18839822qb32bd5626a95f59d@mail.gmail.com>
	<49FA2006.3060207@macports.org>
	<b808b3510904301518h13c49fb1sea648bc3776a88cf@mail.gmail.com>
	<D3F48D40-2E44-4D0B-9963-9B1AB13F2F9C@macports.org>
	<b808b3510904301635v6318d760g644b11c574c17301@mail.gmail.com>
Message-ID: <31A180FE-1C89-43D3-B09F-89B68FC03AA7@macports.org>

On Apr 30, 2009, at 18:35, Darren Weber wrote:

> It seems that I should be able to replace most of the system calls  
> as follows (orig system call is commented here, with tcl  
> replacements below):
>
> #system "
> #    cd ${build.dir};
> #    find ${destroot}/${vtkExamplePath}/bin | grep -e '\[^(bin)\]\ 
> $' > find.txt;
> #    for f in `cat find.txt`; do
> #        if \[ -f \${f} \] && \[ -x \${f} \]; then
> #            echo install_name_tool changing link libs for \${f};
> #            otool -L \${f} | grep 'libvtk' > otool_libs.txt;
> #            for lib in `cat otool_libs.txt`; do
> #                newlib=`echo \${lib} | sed s#${build.dir}/bin#$ 
> {prefix}/lib/${distname}#`;
> #                install_name_tool -change \${lib} \${newlib} \${f};
> #            done;
> #            rm otool_libs.txt;
> #        fi;
> #    done;
> #    rm find.txt;
> #    "
>
>
> foreach f [glob ${destroot}/${vtkExamplePath}/bin/*] {
>     if { string equal [file extension ${f}] ".app" } {
>         set exeName [file rootname [lindex [file split $f] end]]
>         set f [format "%s/Contents/MacOS/%s" ${f} ${exeName}]
>     }
>     if { expr [file isfile ${f}] && [file executable ${f}] } {
>         system "
>             cd ${build.dir};
>             otool -L \${f} | grep 'libvtk' > otool_libs.txt;
>             for lib in `cat otool_libs.txt`; do
>                 newlib=`echo \${lib} | sed s#${build.dir}/bin#$ 
> {prefix}/lib/${distname}#`;
>                 install_name_tool -change \${lib} \${newlib} \${f};
>             done;
>             rm otool_libs.txt;
>             "
>     }
> }
>
>
> There is some problem with the tcl equivalent.  While it appears to  
> work in tclsh, it doesn't work in the Portfile.  Any ideas?



You may also want to look at the build phase of the oracle- 
instantclient port where I also do some install_name_tool / otool  
manipulations. I only use system to run install_name_tool, and I get  
the output of otool using exec.



From dweber at macports.org  Thu Apr 30 16:43:00 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 30 Apr 2009 16:43:00 -0700
Subject: xinstall glob question
In-Reply-To: <b808b3510904301635v6318d760g644b11c574c17301@mail.gmail.com>
References: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>
	<6D456519-C643-4031-9AC1-A9EF284932C8@lavergne.gotdns.org>
	<b808b3510904291245n593b57d8q5819d5e1b0112a34@mail.gmail.com>
	<49F8D6A9.5010305@macports.org>
	<b808b3510904301455t18839822qb32bd5626a95f59d@mail.gmail.com>
	<49FA2006.3060207@macports.org>
	<b808b3510904301518h13c49fb1sea648bc3776a88cf@mail.gmail.com>
	<D3F48D40-2E44-4D0B-9963-9B1AB13F2F9C@macports.org>
	<b808b3510904301635v6318d760g644b11c574c17301@mail.gmail.com>
Message-ID: <b808b3510904301642g4e9d66adpe41562acf56542fc@mail.gmail.com>

I get an error, ie:

Error: Target org.macports.destroot returned: syntax error in expression "
string equal [file extension ${f}] ".app" ": variable references require
preceding $




On Thu, Apr 30, 2009 at 4:35 PM, Darren Weber <dweber at macports.org> wrote:

>
> It seems that I should be able to replace most of the system calls as
> follows (orig system call is commented here, with tcl replacements below):
>
> #system "
> #    cd ${build.dir};
> #    find ${destroot}/${vtkExamplePath}/bin | grep -e '\[^(bin)\]\$' >
> find.txt;
> #    for f in `cat find.txt`; do
> #        if \[ -f \${f} \] && \[ -x \${f} \]; then
> #            echo install_name_tool changing link libs for \${f};
> #            otool -L \${f} | grep 'libvtk' > otool_libs.txt;
> #            for lib in `cat otool_libs.txt`; do
> #                newlib=`echo \${lib} | sed
> s#${build.dir}/bin#${prefix}/lib/${distname}#`;
> #                install_name_tool -change \${lib} \${newlib} \${f};
> #            done;
> #            rm otool_libs.txt;
> #        fi;
> #    done;
> #    rm find.txt;
> #    "
>
>
> foreach f [glob ${destroot}/${vtkExamplePath}/bin/*] {
>     if { string equal [file extension ${f}] ".app" } {
>         set exeName [file rootname [lindex [file split $f] end]]
>         set f [format "%s/Contents/MacOS/%s" ${f} ${exeName}]
>     }
>     if { expr [file isfile ${f}] && [file executable ${f}] } {
>         system "
>             cd ${build.dir};
>             otool -L \${f} | grep 'libvtk' > otool_libs.txt;
>             for lib in `cat otool_libs.txt`; do
>                 newlib=`echo \${lib} | sed
> s#${build.dir}/bin#${prefix}/lib/${distname}#`;
>                 install_name_tool -change \${lib} \${newlib} \${f};
>             done;
>             rm otool_libs.txt;
>             "
>     }
> }
>
>
>
> There is some problem with the tcl equivalent.  While it appears to work in
> tclsh, it doesn't work in the Portfile.  Any ideas?
>
> Thanks in advance,
> Darren
>
>
>
>
>
>
> On Thu, Apr 30, 2009 at 3:24 PM, Ryan Schmidt <ryandesign at macports.org>wrote:
>
>> On Apr 30, 2009, at 17:18, Darren Weber wrote:
>>
>>  Please take a look at this mess to reset RPATH for all libs in a set of
>>> binaries:
>>>
>>> system "
>>>    cd ${build.dir};
>>>    find ${destroot}/${vtkExamplePath}/bin | grep -e '\[^(bin)\]\$' >
>>> find.txt;
>>>    for f in `cat find.txt`; do
>>>        if \[ -f \${f} \] && \[ -x \${f} \]; then
>>>            echo install_name_tool changing link libs for \${f};
>>>            otool -L \${f} | grep 'libvtk' > otool_libs.txt;
>>>            for lib in `cat otool_libs.txt`; do
>>>                newlib=`echo \${lib} | sed
>>> s#${build.dir}/bin#${prefix}/lib/${distname}#`;
>>>                install_name_tool -change \${lib} \${newlib} \${f};
>>>            done;
>>>            rm otool_libs.txt;
>>>        fi;
>>>    done;
>>>    rm find.txt;
>>>    "
>>>
>>> It works, but can it be done more efficiently?
>>>
>>> Can you do file tests in tcl, like the bash tests [ -f $f ] && [ -x $f ]
>>> ?
>>>
>>
>> Sure, those are respectively "file isfile" and "file executable". Take a
>> look at the manual for the file command:
>>
>> http://wiki.tcl.tk/1041
>>
>>
>>  PS, Don't ask me why it's required ;-)
>>>
>>
>> I'm scared to...
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090430/6fc20ee2/attachment.html>

From ryandesign at macports.org  Thu Apr 30 16:55:21 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 30 Apr 2009 18:55:21 -0500
Subject: [50398] trunk/dports/java/spring-framework/Portfile
In-Reply-To: <20090430054333.4353E16C23AA@beta.macosforge.org>
References: <20090430054333.4353E16C23AA@beta.macosforge.org>
Message-ID: <8975DB5C-0DF8-49D0-B03F-EB6CF3AA93B9@macports.org>

On Apr 30, 2009, at 00:43, blair at macports.org wrote:

> Revision: 50398
>           http://trac.macports.org/changeset/50398
> Author:   blair at macports.org
> Date:     2009-04-29 22:43:32 -0700 (Wed, 29 Apr 2009)
> Log Message:
> -----------
> New upstream 2.5.6.SEC01 release.
>
> Modified Paths:
> --------------
>     trunk/dports/java/spring-framework/Portfile
>
> Modified: trunk/dports/java/spring-framework/Portfile
> ===================================================================
> --- trunk/dports/java/spring-framework/Portfile	2009-04-30 05:32:47  
> UTC (rev 50397)
> +++ trunk/dports/java/spring-framework/Portfile	2009-04-30 05:43:32  
> UTC (rev 50398)
> @@ -1,9 +1,9 @@
> -# $Id$
> +# $Id: Portfile 42503 2008-11-22 18:10:57Z blair at macports.org $

[snip]

I'm curious why we're seeing lines like these in the diffs. The  
Portfile does not have this allegedly changed Id line. As far as I  
understand, there's no way it could, since the Portfile has  
svn:keywords set to Id which means that the Subversion client is  
supposed to normalize all keywords in a file to their unexpanded form  
before sending the file to the repository.

The line even shows up like this on the command line:

$ svn di -c 50398
Index: Portfile
===================================================================
--- Portfile    (revision 50397)
+++ Portfile    (revision 50398)
@@ -1,9 +1,9 @@
-# $Id$
+# $Id: Portfile 42503 2008-11-22 18:10:57Z blair at macports.org $

[snip]

Blair, did you change the Id line to the above before committing?  
What version of the svn client are you using?


From blair at orcaware.com  Thu Apr 30 17:01:56 2009
From: blair at orcaware.com (Blair Zajac)
Date: Thu, 30 Apr 2009 17:01:56 -0700
Subject: [50398] trunk/dports/java/spring-framework/Portfile
In-Reply-To: <8975DB5C-0DF8-49D0-B03F-EB6CF3AA93B9@macports.org>
References: <20090430054333.4353E16C23AA@beta.macosforge.org>
	<8975DB5C-0DF8-49D0-B03F-EB6CF3AA93B9@macports.org>
Message-ID: <49FA3BF4.7040003@orcaware.com>

Ryan Schmidt wrote:
> On Apr 30, 2009, at 00:43, blair at macports.org wrote:
> 
>> Revision: 50398
>>           http://trac.macports.org/changeset/50398
>> Author:   blair at macports.org
>> Date:     2009-04-29 22:43:32 -0700 (Wed, 29 Apr 2009)
>> Log Message:
>> -----------
>> New upstream 2.5.6.SEC01 release.
>>
>> Modified Paths:
>> --------------
>>     trunk/dports/java/spring-framework/Portfile
>>
>> Modified: trunk/dports/java/spring-framework/Portfile
>> ===================================================================
>> --- trunk/dports/java/spring-framework/Portfile    2009-04-30 05:32:47 
>> UTC (rev 50397)
>> +++ trunk/dports/java/spring-framework/Portfile    2009-04-30 05:43:32 
>> UTC (rev 50398)
>> @@ -1,9 +1,9 @@
>> -# $Id$
>> +# $Id: Portfile 42503 2008-11-22 18:10:57Z blair at macports.org $
> 
> [snip]
> 
> I'm curious why we're seeing lines like these in the diffs. The Portfile 
> does not have this allegedly changed Id line. As far as I understand, 
> there's no way it could, since the Portfile has svn:keywords set to Id 
> which means that the Subversion client is supposed to normalize all 
> keywords in a file to their unexpanded form before sending the file to 
> the repository.
> 
> The line even shows up like this on the command line:
> 
> $ svn di -c 50398
> Index: Portfile
> ===================================================================
> --- Portfile    (revision 50397)
> +++ Portfile    (revision 50398)
> @@ -1,9 +1,9 @@
> -# $Id$
> +# $Id: Portfile 42503 2008-11-22 18:10:57Z blair at macports.org $
> 
> [snip]
> 
> Blair, did you change the Id line to the above before committing? What 
> version of the svn client are you using?

Ryan,

I'm now using git as an svn client, so that would explain that behavior.

I commit from an svn 1.3.2 (ouch!), which may explain this behavior somehow.  I 
haven't seen it when I use 1.6.x, but then I haven't checked for it either.

Regards,
Blair

From jmr at macports.org  Thu Apr 30 17:08:49 2009
From: jmr at macports.org (Joshua Root)
Date: Fri, 01 May 2009 10:08:49 +1000
Subject: xinstall glob question
In-Reply-To: <b808b3510904301642g4e9d66adpe41562acf56542fc@mail.gmail.com>
References: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>	
	<6D456519-C643-4031-9AC1-A9EF284932C8@lavergne.gotdns.org>	
	<b808b3510904291245n593b57d8q5819d5e1b0112a34@mail.gmail.com>	
	<49F8D6A9.5010305@macports.org>	
	<b808b3510904301455t18839822qb32bd5626a95f59d@mail.gmail.com>	
	<49FA2006.3060207@macports.org>	
	<b808b3510904301518h13c49fb1sea648bc3776a88cf@mail.gmail.com>	
	<D3F48D40-2E44-4D0B-9963-9B1AB13F2F9C@macports.org>	
	<b808b3510904301635v6318d760g644b11c574c17301@mail.gmail.com>
	<b808b3510904301642g4e9d66adpe41562acf56542fc@mail.gmail.com>
Message-ID: <49FA3D91.2020404@macports.org>

Darren Weber wrote:
> 
> 
> I get an error, ie:
> 
> Error: Target org.macports.destroot returned: syntax error in expression
> " string equal [file extension ${f}] ".app" ": variable references
> require preceding $

You're missing [] around the string equal call.

- Josh

From dweber at macports.org  Thu Apr 30 17:14:35 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 30 Apr 2009 17:14:35 -0700
Subject: xinstall glob question
In-Reply-To: <49FA3D91.2020404@macports.org>
References: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>
	<b808b3510904291245n593b57d8q5819d5e1b0112a34@mail.gmail.com>
	<49F8D6A9.5010305@macports.org>
	<b808b3510904301455t18839822qb32bd5626a95f59d@mail.gmail.com>
	<49FA2006.3060207@macports.org>
	<b808b3510904301518h13c49fb1sea648bc3776a88cf@mail.gmail.com>
	<D3F48D40-2E44-4D0B-9963-9B1AB13F2F9C@macports.org>
	<b808b3510904301635v6318d760g644b11c574c17301@mail.gmail.com>
	<b808b3510904301642g4e9d66adpe41562acf56542fc@mail.gmail.com>
	<49FA3D91.2020404@macports.org>
Message-ID: <b808b3510904301714j414e4333ibcf804b1300fe552@mail.gmail.com>

Many thanks!  These tcl replacements for the system calls are working (still
a few system calls in there, but not nearly as bad as before):

set buildBinPath ${build.dir}/bin
set vtkLibPath ${prefix}/lib/${distname}

foreach f [glob ${buildBinPath}/*] {
    if {![string match {*.dylib} ${f}]} {
      file copy ${f} ${destroot}/${vtkExamplePath}/bin/
    }
}

foreach f [glob ${destroot}/${vtkExamplePath}/bin/*] {
    if [string equal [file extension ${f}] ".app"] {
        set exeName [file rootname [lindex [file split ${f}] end]]
        set f [format "%s/Contents/MacOS/%s" ${f} ${exeName}]
    }
    if [expr [file isfile ${f}] && [file executable ${f}]] {
        foreach dep [exec otool -L ${f}] {
            if [string match "*/libvtk*.dylib" ${dep}] {
                set newdep [strsed ${dep} #${buildBinPath}#${vtkLibPath}#]
                system "install_name_tool -change ${dep} ${newdep} ${f}"
            }
        }
    }
}


Woohoo  (what a way to waste the day!)
Darren




On Thu, Apr 30, 2009 at 5:08 PM, Joshua Root <jmr at macports.org> wrote:

> Darren Weber wrote:
> >
> >
> > I get an error, ie:
> >
> > Error: Target org.macports.destroot returned: syntax error in expression
> > " string equal [file extension ${f}] ".app" ": variable references
> > require preceding $
>
> You're missing [] around the string equal call.
>
> - Josh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090430/0cab6d14/attachment.html>

From ryandesign at macports.org  Thu Apr 30 18:03:48 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 30 Apr 2009 20:03:48 -0500
Subject: [50398] trunk/dports/java/spring-framework/Portfile
In-Reply-To: <49FA3BF4.7040003@orcaware.com>
References: <20090430054333.4353E16C23AA@beta.macosforge.org>
	<8975DB5C-0DF8-49D0-B03F-EB6CF3AA93B9@macports.org>
	<49FA3BF4.7040003@orcaware.com>
Message-ID: <C4AC0B01-EAF0-46FE-9555-B4C28A73BA7F@macports.org>

On Apr 30, 2009, at 19:01, Blair Zajac wrote:

>> I'm curious why we're seeing lines like these in the diffs. The  
>> Portfile does not have this allegedly changed Id line. As far as I  
>> understand, there's no way it could, since the Portfile has  
>> svn:keywords set to Id which means that the Subversion client is  
>> supposed to normalize all keywords in a file to their unexpanded  
>> form before sending the file to the repository.
>> The line even shows up like this on the command line:
>> $ svn di -c 50398
>> Index: Portfile
>> ===================================================================
>> --- Portfile    (revision 50397)
>> +++ Portfile    (revision 50398)
>> @@ -1,9 +1,9 @@
>> -# $Id$
>> +# $Id: Portfile 42503 2008-11-22 18:10:57Z blair at macports.org $
>> [snip]
>> Blair, did you change the Id line to the above before committing?  
>> What version of the svn client are you using?
>
> Ryan,
>
> I'm now using git as an svn client, so that would explain that  
> behavior.
>
> I commit from an svn 1.3.2 (ouch!), which may explain this behavior  
> somehow.  I haven't seen it when I use 1.6.x, but then I haven't  
> checked for it either.

How and why does one use git as an svn client? And why do you use svn  
1.3.2 and not the current version?


From blair at orcaware.com  Thu Apr 30 22:38:24 2009
From: blair at orcaware.com (Blair Zajac)
Date: Thu, 30 Apr 2009 22:38:24 -0700
Subject: [50398] trunk/dports/java/spring-framework/Portfile
Message-ID: <0EED90BE-CC7E-402C-B328-65C7D551C832@orcaware.com>

There's a bunch of reasons to use hit which I won't get into from my  
iPhone :)

My Ubuntu box that I commit from is running Dapper Drake, is colocated  
and doing fine without an upgrade.  I don't commit from work since I  
don't want my MacPorts password sitting on disk there.

Blair

Sent from my iPhone

On Apr 30, 2009, at 6:03 PM, Ryan Schmidt <ryandesign at macports.org>  
wrote:

> On Apr 30, 2009, at 19:01, Blair Zajac wrote:
>
>>> I'm curious why we're seeing lines like these in the diffs. The  
>>> Portfile does not have this allegedly changed Id line. As far as I  
>>> understand, there's no way it could, since the Portfile has  
>>> svn:keywords set to Id which means that the Subversion client is  
>>> supposed to normalize all keywords in a file to their unexpanded  
>>> form before sending the file to the repository.
>>> The line even shows up like this on the command line:
>>> $ svn di -c 50398
>>> Index: Portfile
>>> ===================================================================
>>> --- Portfile    (revision 50397)
>>> +++ Portfile    (revision 50398)
>>> @@ -1,9 +1,9 @@
>>> -# $Id$
>>> +# $Id: Portfile 42503 2008-11-22 18:10:57Z blair at macports.org $
>>> [snip]
>>> Blair, did you change the Id line to the above before committing?  
>>> What version of the svn client are you using?
>>
>> Ryan,
>>
>> I'm now using git as an svn client, so that would explain that  
>> behavior.
>>
>> I commit from an svn 1.3.2 (ouch!), which may explain this behavior  
>> somehow.  I haven't seen it when I use 1.6.x, but then I haven't  
>> checked for it either.
>
> How and why does one use git as an svn client? And why do you use  
> svn 1.3.2 and not the current version?
>


From mcalhoun at macports.org  Thu Apr 30 23:49:32 2009
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Fri, 1 May 2009 06:49:32 +0000 (UTC)
Subject: =?utf-8?b?K3N5c3RlbV94MTE=?= to bite the dust
References: <EEA15397-5D82-44CE-A36A-94DF37AA882F@macports.org>
	<loom.20090429T204935-565@post.gmane.org>
	<0BE988FB-DCF7-49BA-9660-5F82595E4D53@macports.org>
Message-ID: <loom.20090501T064652-977@post.gmane.org>

Jeremy Huddleston <jeremyhu at ...> writes:

> 
> You bring up a good point, but I don't think it's as big a concern as  
> you might think.
> 
> The client side (which is what is mainly  
> important) is almost identical to what is used on every other  
> platform.  The upkeep at this point is mainly just updating version  
> numbers in the Portfile.
> 

That sounds very reasonable.
Thanks for the explanation.

-Marcus