From sal at ri.cmu.edu  Tue May  1 10:16:03 2007
From: sal at ri.cmu.edu (Salvatore Domenick Desiano)
Date: Tue Oct  9 16:40:16 2007
Subject: Mailing List Prefix
Message-ID: <Pine.LNX.4.64.0705011314420.27034@linux4.gp.cs.cmu.edu>

Have we had the mailng list prefix argument? As my spam increases, I 
find it very useful to be able to visually pick out which items are from 
MacPorts. I'm sure I can write a filter to prepend it on my end, but I'm 
noticing it from a number of other lists recently and I find it useful. 
There is, of course, the counter argument about wasting screen real 
estate. Even [MPD] and [MPU] would help.

-- Sal
smile.


--------------
   Salvatore Domenick Desiano
     Doctoral Candidate
       Robotics Institute
         Carnegie Mellon University

From jmpp at macports.org  Tue May  1 10:45:04 2007
From: jmpp at macports.org (Juan Manuel Palacios)
Date: Tue Oct  9 16:40:16 2007
Subject: Mailing List Prefix
In-Reply-To: <Pine.LNX.4.64.0705011314420.27034@linux4.gp.cs.cmu.edu>
References: <Pine.LNX.4.64.0705011314420.27034@linux4.gp.cs.cmu.edu>
Message-ID: <0C8514A2-8858-4A91-8F4C-C5E2C8E5DCC8@macports.org>


On May 1, 2007, at 1:16 PM, Salvatore Domenick Desiano wrote:

> Have we had the mailng list prefix argument? As my spam increases,  
> I find it very useful to be able to visually pick out which items  
> are from MacPorts. I'm sure I can write a filter to prepend it on  
> my end, but I'm noticing it from a number of other lists recently  
> and I find it useful. There is, of course, the counter argument  
> about wasting screen real estate. Even [MPD] and [MPU] would help.
>
> -- Sal
> smile.


	Why not use the "List-Id" header field (its value for this list  
being "MacPorts project developers list <macports- 
dev.lists.macosforge.org>") to rule based filter messages sent to  
this list? You can create a mailbox and send all these messages in  
there, just a suggestions (which works dandy for me!)

	Regards,...


-jmpp


From sal at ri.cmu.edu  Tue May  1 11:16:28 2007
From: sal at ri.cmu.edu (Salvatore Domenick Desiano)
Date: Tue Oct  9 16:40:16 2007
Subject: Mailing List Prefix
In-Reply-To: <0C8514A2-8858-4A91-8F4C-C5E2C8E5DCC8@macports.org>
References: <Pine.LNX.4.64.0705011314420.27034@linux4.gp.cs.cmu.edu>
	<0C8514A2-8858-4A91-8F4C-C5E2C8E5DCC8@macports.org>
Message-ID: <Pine.LNX.4.64.0705011414400.27034@linux4.gp.cs.cmu.edu>

o 	Why not use the "List-Id" header field (its value for this list 
o being "MacPorts project developers list 
o <macports-dev.lists.macosforge.org>") to rule based filter messages 
o sent to this list? You can create a mailbox and send all these 
o messages in there, just a suggestions (which works dandy for me!)

I've considered this, but my general mail handling data flow precludes 
multiple mailboxes (at least for e-mail to a given e-mail address). If 
MP mail went to a different folder, I'd never read it. I suspect this is 
the case for many people.

-- Sal
smile.



--------------
  Salvatore Domenick Desiano
    Doctoral Candidate
      Robotics Institute
        Carnegie Mellon University

On Tue, 1 May 2007, Juan Manuel Palacios wrote:

o 
o On May 1, 2007, at 1:16 PM, Salvatore Domenick Desiano wrote:
o 
o > Have we had the mailng list prefix argument? As my spam increases, I find it
o > very useful to be able to visually pick out which items are from MacPorts.
o > I'm sure I can write a filter to prepend it on my end, but I'm noticing it
o > from a number of other lists recently and I find it useful. There is, of
o > course, the counter argument about wasting screen real estate. Even [MPD]
o > and [MPU] would help.
o > 
o > -- Sal
o > smile.
o 
o 
o 
o 	Regards,...
o 
o 
o -jmpp
o 
o 

From ryandesign at macports.org  Tue May  1 14:24:41 2007
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue Oct  9 16:40:16 2007
Subject: Mailing List Prefix
In-Reply-To: <Pine.LNX.4.64.0705011414400.27034@linux4.gp.cs.cmu.edu>
References: <Pine.LNX.4.64.0705011314420.27034@linux4.gp.cs.cmu.edu>
	<0C8514A2-8858-4A91-8F4C-C5E2C8E5DCC8@macports.org>
	<Pine.LNX.4.64.0705011414400.27034@linux4.gp.cs.cmu.edu>
Message-ID: <617DBA8F-E80C-4F3A-A403-8BC74FE0D0AA@macports.org>


On May 1, 2007, at 13:16, Salvatore Domenick Desiano wrote:

> On Tue, 1 May 2007, Juan Manuel Palacios wrote:
>
>> On May 1, 2007, at 1:16 PM, Salvatore Domenick Desiano wrote:
>>
>>> Have we had the mailng list prefix argument? As my spam  
>>> increases, I find it
>>> very useful to be able to visually pick out which items are from  
>>> MacPorts.
>>> I'm sure I can write a filter to prepend it on my end, but I'm  
>>> noticing it
>>> from a number of other lists recently and I find it useful. There  
>>> is, of
>>> course, the counter argument about wasting screen real estate.  
>>> Even [MPD]
>>> and [MPU] would help.
>>
>> Why not use the "List-Id" header field (its value for this list
>> being "MacPorts project developers list
>> <macports-dev.lists.macosforge.org>") to rule based filter messages
>> sent to this list? You can create a mailbox and send all these
>> messages in there, just a suggestions (which works dandy for me!)
>
> I've considered this, but my general mail handling data flow precludes
> multiple mailboxes (at least for e-mail to a given e-mail address). If
> MP mail went to a different folder, I'd never read it. I suspect  
> this is
> the case for many people.

Well, the lists originally had a prefix, but it was removed following  
the discussion "Remove list prefix?" available here:

http://lists.macosforge.org/pipermail/macports-users/2006-September/ 
thread.html

Granted, the discussion also argued for using an abbreviated prefix  
like "[MPD]". But the List-Id header is sufficient to configure your  
mail program's filters. I  have it configured to move mail to another  
mail folder. If you don't want to do that, you can have your mail  
program do something else -- whatever options your mail program  
offers. Set the color of the message when shown in the list, for  
example. However, I recommend you use separate mail folders. It  
really is much better. Why do you think you would never read mail in  
another folder?

List prefixes are problematic for various reasons. They take up  
horizontal space in the message list, as you know. And things become  
worse when messages are cross-posted to multiple lists and then gain  
multiple prefixes.



From etiffany at alum.mit.edu  Tue May  1 15:04:28 2007
From: etiffany at alum.mit.edu (Eric Tiffany)
Date: Tue Oct  9 16:40:16 2007
Subject: Mailing List Prefix
In-Reply-To: <617DBA8F-E80C-4F3A-A403-8BC74FE0D0AA@macports.org>
Message-ID: <C25D31AC.1FBC5%etiffany@alum.mit.edu>

Hmm, that thread certainly doesn't lead to the conclusion that the prefix
should be removed.  In fact, it seems to be the consensus that something
like [mp-users] or [mp-dev] would be the right choice for a prefix.

I would actually prefer [mports-d], but any prefix would help.  I don't want
to filter my messages into other boxes and I like the visual cue of the
prefix.

ET


On 5/1/07 5:24 PM, "Ryan Schmidt" <ryandesign@macports.org> wrote:

> 
> On May 1, 2007, at 13:16, Salvatore Domenick Desiano wrote:
> 
>> On Tue, 1 May 2007, Juan Manuel Palacios wrote:
>> 
>>> On May 1, 2007, at 1:16 PM, Salvatore Domenick Desiano wrote:
>>> 
>>>> Have we had the mailng list prefix argument? As my spam
>>>> increases, I find it
>>>> very useful to be able to visually pick out which items are from
>>>> MacPorts.
>>>> I'm sure I can write a filter to prepend it on my end, but I'm
>>>> noticing it
>>>> from a number of other lists recently and I find it useful. There
>>>> is, of
>>>> course, the counter argument about wasting screen real estate.
>>>> Even [MPD]
>>>> and [MPU] would help.
>>> 
>>> Why not use the "List-Id" header field (its value for this list
>>> being "MacPorts project developers list
>>> <macports-dev.lists.macosforge.org>") to rule based filter messages
>>> sent to this list? You can create a mailbox and send all these
>>> messages in there, just a suggestions (which works dandy for me!)
>> 
>> I've considered this, but my general mail handling data flow precludes
>> multiple mailboxes (at least for e-mail to a given e-mail address). If
>> MP mail went to a different folder, I'd never read it. I suspect
>> this is
>> the case for many people.
> 
> Well, the lists originally had a prefix, but it was removed following
> the discussion "Remove list prefix?" available here:
> 
> http://lists.macosforge.org/pipermail/macports-users/2006-September/
> thread.html
> 
> Granted, the discussion also argued for using an abbreviated prefix
> like "[MPD]". But the List-Id header is sufficient to configure your
> mail program's filters. I  have it configured to move mail to another
> mail folder. If you don't want to do that, you can have your mail
> program do something else -- whatever options your mail program
> offers. Set the color of the message when shown in the list, for
> example. However, I recommend you use separate mail folders. It
> really is much better. Why do you think you would never read mail in
> another folder?
> 
> List prefixes are problematic for various reasons. They take up
> horizontal space in the message list, as you know. And things become
> worse when messages are cross-posted to multiple lists and then gain
> multiple prefixes.
> 
> 
> _______________________________________________
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev




From ryandesign at macports.org  Tue May  1 15:32:11 2007
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue Oct  9 16:40:16 2007
Subject: Mailing List Prefix
In-Reply-To: <C25D31AC.1FBC5%etiffany@alum.mit.edu>
References: <C25D31AC.1FBC5%etiffany@alum.mit.edu>
Message-ID: <59D5B3D7-4B22-4DFE-BDDE-9FA3E870AD60@macports.org>

On May 1, 2007, at 17:04, Eric Tiffany wrote:

> On 5/1/07 5:24 PM, Ryan Schmidt wrote:
>
>> Well, the lists originally had a prefix, but it was removed following
>> the discussion "Remove list prefix?" available here:
>>
>> http://lists.macosforge.org/pipermail/macports-users/2006-September/
>> thread.html
>>
>> Granted, the discussion also argued for using an abbreviated prefix
>> like "[MPD]". But the List-Id header is sufficient to configure your
>> mail program's filters. I  have it configured to move mail to another
>> mail folder. If you don't want to do that, you can have your mail
>> program do something else -- whatever options your mail program
>> offers. Set the color of the message when shown in the list, for
>> example. However, I recommend you use separate mail folders. It
>> really is much better. Why do you think you would never read mail in
>> another folder?
>>
>> List prefixes are problematic for various reasons. They take up
>> horizontal space in the message list, as you know. And things become
>> worse when messages are cross-posted to multiple lists and then gain
>> multiple prefixes.
>
> Hmm, that thread certainly doesn't lead to the conclusion that the  
> prefix
> should be removed.  In fact, it seems to be the consensus that  
> something
> like [mp-users] or [mp-dev] would be the right choice for a prefix.
>
> I would actually prefer [mports-d], but any prefix would help.  I  
> don't want
> to filter my messages into other boxes and I like the visual cue of  
> the
> prefix.

I agree there was something of a leap between the discussion that  
took place and the action which eventually resulted. However, I  
believe it was the correct action to take. If what I have said so far  
has not convinced you of this, perhaps someone else's article will:

http://www.l33tskillz.org/writing/tagging-harmful/




From glasser at mit.edu  Tue May  1 15:53:11 2007
From: glasser at mit.edu (David Glasser)
Date: Tue Oct  9 16:40:16 2007
Subject: python2.5 has wrong value for
	distutils.sysconfig.get_config_var("PYTHON")
In-Reply-To: <1ea387f60705011534j54c68280vd9e167810becb9df@mail.gmail.com>
References: <1ea387f60705011534j54c68280vd9e167810becb9df@mail.gmail.com>
Message-ID: <1ea387f60705011553w1b4643d3hff42d303ce9f4268@mail.gmail.com>

[oops, wasn't on mailing list the first time I tried to send this]

Currently, MacPorts installs python2.4 as /opt/local/bin/python and
Python 2.5 only as python2.5.  However, the Python 2.5 install doesn't
know this; in its makefile (which ends up installed as
/opt/local/lib/python2.5/config/makefile), it still believes that

PYTHON=         python$(EXE)

which means that

 distutils.sysconfig.get_config_var("PYTHON")

returns "python" instead of "python2.5", which means that python
programs that rely on this config var to be able to run python from
the command line run the wrong version of python.

Can we fix the build process so that python 2.5 is configured with
PYTHON=python2.5, instead of tricking it into thinking it is called
python and just deleting python in the post-destroot?

--dave

--
David Glasser | glasser@mit.edu | http://www.davidglasser.net/


-- 
David Glasser | glasser@mit.edu | http://www.davidglasser.net/

From blair at orcaware.com  Tue May  1 16:19:34 2007
From: blair at orcaware.com (Blair Zajac)
Date: Tue Oct  9 16:40:16 2007
Subject: python2.5 has wrong value
	for	distutils.sysconfig.get_config_var("PYTHON")
In-Reply-To: <1ea387f60705011553w1b4643d3hff42d303ce9f4268@mail.gmail.com>
References: <1ea387f60705011534j54c68280vd9e167810becb9df@mail.gmail.com>
	<1ea387f60705011553w1b4643d3hff42d303ce9f4268@mail.gmail.com>
Message-ID: <4637CB06.6020403@orcaware.com>

David Glasser wrote:
> [oops, wasn't on mailing list the first time I tried to send this]
> 
> Currently, MacPorts installs python2.4 as /opt/local/bin/python and
> Python 2.5 only as python2.5.  However, the Python 2.5 install doesn't
> know this; in its makefile (which ends up installed as
> /opt/local/lib/python2.5/config/makefile), it still believes that
> 
> PYTHON=         python$(EXE)
> 
> which means that
> 
> distutils.sysconfig.get_config_var("PYTHON")
> 
> returns "python" instead of "python2.5", which means that python
> programs that rely on this config var to be able to run python from
> the command line run the wrong version of python.
> 
> Can we fix the build process so that python 2.5 is configured with
> PYTHON=python2.5, instead of tricking it into thinking it is called
> python and just deleting python in the post-destroot?

Hi David,

Can you write a quick patch for the python2.5 Portfile to do what you're 
referring to here?

Regards,
Blair

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

From glasser at mit.edu  Tue May  1 16:23:31 2007
From: glasser at mit.edu (David Glasser)
Date: Tue Oct  9 16:40:16 2007
Subject: python2.5 has wrong value for
	distutils.sysconfig.get_config_var("PYTHON")
In-Reply-To: <4637CB06.6020403@orcaware.com>
References: <1ea387f60705011534j54c68280vd9e167810becb9df@mail.gmail.com>
	<1ea387f60705011553w1b4643d3hff42d303ce9f4268@mail.gmail.com>
	<4637CB06.6020403@orcaware.com>
Message-ID: <1ea387f60705011623i21860272h670bc819fb56a286@mail.gmail.com>

On 5/1/07, Blair Zajac <blair@orcaware.com> wrote:
> Can you write a quick patch for the python2.5 Portfile to do what you're
> referring to here?

Working on it.  I've never been so good about understanding how to
test my own Portfiles though --- I mean, I know I can just put
Portfile in a random directory and type "port install", but how do I
make it forget completely about my version and upgrade to the "real"
version once my patch has been accepted by MacPorts?

(About the issue itself: it looks like this actually requires patching
the Makefile, since PYTHON is not actually a configure argument.
Ugh.)

(BTW Blair, this is to get David James' svn ctypes stuff working.)

--dave

-- 
David Glasser | glasser@mit.edu | http://www.davidglasser.net/

From ryandesign at macports.org  Tue May  1 17:48:47 2007
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue Oct  9 16:40:16 2007
Subject: Fixed-width font in commit mails?
In-Reply-To: <43665530-9765-4305-80EB-DC30ABED16D5@macports.org>
References: <E6BCE6A1-CD58-453D-9891-B1163F39AA47@macports.org>
	<6AFB75BC-0D88-4350-98E0-0AF9EEEE8FB6@geeklair.net>
	<FBB587B5-AD8E-451B-A485-485DCA7FF2BE@macports.org>
	<2808237C-9098-4FF5-A940-95C5110FEB7F@geeklair.net>
	<43665530-9765-4305-80EB-DC30ABED16D5@macports.org>
Message-ID: <2A1DFDFB-911E-41D8-86CE-DF18183333DB@macports.org>


On Apr 30, 2007, at 04:31, Ryan Schmidt wrote:

>>>> Otherwise, I think the commit mails are the default SVN::Notify  
>>>> HTML::ColorDiff style. I'm not sure if there's a simple hook to  
>>>> change the font that the CSS sets.
>>>
>>> I wanted to play with svnnotify to see if I could find such an  
>>> option, but I don't know how to install it. Is there a MacPorts  
>>> way to install svnnotify?
>>
>> It's just the SVN::Notify perl module, so it's easy :)
>>
>> ... but I just created a macports port for it (p5-svn-notify), so  
>> you should be able to install it from macports soon.
>
> Thanks, Daniel. I've tried installing perl modules myself before,  
> outside of MacPorts, and have always been rather incompetent. And,  
> see, installing p5-svn-notify ended up installing 16 other p5  
> ports. So I'm glad that went smoothly. Now I'll look into setting  
> it up.

Ok. I'm trying to set it up. I don't have a local SMTP server so I  
want to use a remote one. So I'm using the options --smtp, --smtp- 
user and --smtp-pass. But I don't seem to have the required modules  
to do this:

Can't locate Net/SMTP_auth.pm in @INC (@INC contains: /opt/local/lib/ 
perl5/5.8.8/darwin-2level /opt/local/lib/perl5/5.8.8 /opt/local/lib/ 
perl5/site_perl/5.8.8/darwin-2level /opt/local/lib/perl5/site_perl/ 
5.8.8 /opt/local/lib/perl5/site_perl /opt/local/lib/perl5/vendor_perl/ 
5.8.8/darwin-2level /opt/local/lib/perl5/vendor_perl/5.8.8 /opt/local/ 
lib/perl5/vendor_perl .) at /opt/local/lib/perl5/vendor_perl/5.8.8/ 
SVN/Notify.pm line 2047.

Using "port search p5" and "port search smtp" I can't find this Net/ 
SMTP_auth.pm. Is it available via MacPorts? If not, can it be made  
available?




From blair at orcaware.com  Tue May  1 18:12:14 2007
From: blair at orcaware.com (Blair Zajac)
Date: Tue Oct  9 16:40:16 2007
Subject: python2.5 has wrong value for
	distutils.sysconfig.get_config_var("PYTHON")
In-Reply-To: <1ea387f60705011623i21860272h670bc819fb56a286@mail.gmail.com>
References: <1ea387f60705011534j54c68280vd9e167810becb9df@mail.gmail.com>	
	<1ea387f60705011553w1b4643d3hff42d303ce9f4268@mail.gmail.com>	
	<4637CB06.6020403@orcaware.com>
	<1ea387f60705011623i21860272h670bc819fb56a286@mail.gmail.com>
Message-ID: <4637E56E.1010703@orcaware.com>

David Glasser wrote:
> On 5/1/07, Blair Zajac <blair@orcaware.com> wrote:
>> Can you write a quick patch for the python2.5 Portfile to do what you're
>> referring to here?
> 
> Working on it.  I've never been so good about understanding how to
> test my own Portfiles though --- I mean, I know I can just put
> Portfile in a random directory and type "port install", but how do I
> make it forget completely about my version and upgrade to the "real"
> version once my patch has been accepted by MacPorts?

I use the port at the same revision number as the official port, then 
uninstall the current version, put my local port repository in 
$prefix/etc/ports/sources.conf as a file:/// before the rsync one, then 
use portindex.  When I'm happy, I submit it upstream with a bump in 
revision and move the port out of my local repository (say into a 
retired ports directory that MacPorts doesn't nsee), since it shadows 
the main one.

> (About the issue itself: it looks like this actually requires patching
> the Makefile, since PYTHON is not actually a configure argument.
> Ugh.)
> 
> (BTW Blair, this is to get David James' svn ctypes stuff working.)

Cool.  That'll be nice to get in.

Regards,


From markd at macports.org  Tue May  1 18:11:44 2007
From: markd at macports.org (markd@macports.org)
Date: Tue Oct  9 16:40:16 2007
Subject: Fixed-width font in commit mails?
In-Reply-To: <2A1DFDFB-911E-41D8-86CE-DF18183333DB@macports.org>
References: <2A1DFDFB-911E-41D8-86CE-DF18183333DB@macports.org>
Message-ID: <fc.004c4c580c86a9703b9aca00e98a98ef.c86ac28@biola.edu>

Ryan Schmidt <ryandesign@macports.org> on Tuesday, May 1, 2007 at 5:48 PM
-0800 wrote:
>>>>> Otherwise, I think the commit mails are the default SVN::Notify  
>>>>> HTML::ColorDiff style. I'm not sure if there's a simple hook to  
>>>>> change the font that the CSS sets.
>>>>
>>>> I wanted to play with svnnotify to see if I could find such an  
>>>> option, but I don't know how to install it. Is there a MacPorts  
>>>> way to install svnnotify?
>>>
>>> It's just the SVN::Notify perl module, so it's easy :)
>>>
>>> ... but I just created a macports port for it (p5-svn-notify), so  
>>> you should be able to install it from macports soon.
>>
>> Thanks, Daniel. I've tried installing perl modules myself before,  
>> outside of MacPorts, and have always been rather incompetent. And,  
>> see, installing p5-svn-notify ended up installing 16 other p5  
>> ports. So I'm glad that went smoothly. Now I'll look into setting  
>> it up.
>
>Ok. I'm trying to set it up. I don't have a local SMTP server so I  
>want to use a remote one. So I'm using the options --smtp, --smtp- 
>user and --smtp-pass. But I don't seem to have the required modules  
>to do this:
>
>Can't locate Net/SMTP_auth.pm in @INC (@INC contains: /opt/local/lib/ 
>perl5/5.8.8/darwin-2level /opt/local/lib/perl5/5.8.8 /opt/local/lib/ 
>perl5/site_perl/5.8.8/darwin-2level /opt/local/lib/perl5/site_perl/ 
>5.8.8 /opt/local/lib/perl5/site_perl /opt/local/lib/perl5/vendor_perl/ 
>5.8.8/darwin-2level /opt/local/lib/perl5/vendor_perl/5.8.8 /opt/local/ 
>lib/perl5/vendor_perl .) at /opt/local/lib/perl5/vendor_perl/5.8.8/ 
>SVN/Notify.pm line 2047.
>
>Using "port search p5" and "port search smtp" I can't find this Net/ 
>SMTP_auth.pm. Is it available via MacPorts? If not, can it be made  
>available?

Oops, sent with wrong address again.  Resending minus CC's
------

See if this has what you need:

p5-net

I created that recently and it has SMTP stuff in it and is listed on CPAN
as Net::SMTP.  I called it p5-net because FreeBSD did that, there are a
lot of non-mail modules, and there are quite a few libraries listed on
CPAN listed as Net::SMTP:XXX (none of which are ported.)  If it isn't that
one you'll need to find the right one on CPAN and port it.

Mark


From chpickel at stwing.upenn.edu  Tue May  1 23:14:10 2007
From: chpickel at stwing.upenn.edu (Chris Pickel)
Date: Tue Oct  9 16:40:16 2007
Subject: Framework Install Dir
Message-ID: <4405F136-209A-4834-B465-962729868808@stwing.upenn.edu>

On the subject of frameworks:

Is there a standard install directory for frameworks? On some  
Portfiles (notably the libsdl*-framework ports), frameworks are  
installed to /Library/Frameworks. On others (such as python2[45]),  
they are installed to ${prefix}/Library/Frameworks.

Personally, I think the latter (in ${prefix}) is much better  
practice, though it might be a good gesture to to provide a symlink  
within /Library.


Once I have an answer on this, I'll put in a fix to mzscheme.


Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070502/ade79b65/PGP.bin
From blair at orcaware.com  Tue May  1 23:16:12 2007
From: blair at orcaware.com (Blair Zajac)
Date: Tue Oct  9 16:40:16 2007
Subject: Framework Install Dir
In-Reply-To: <4405F136-209A-4834-B465-962729868808@stwing.upenn.edu>
References: <4405F136-209A-4834-B465-962729868808@stwing.upenn.edu>
Message-ID: <E79AB4AE-C26D-479B-B48C-6DA6B34C20D3@orcaware.com>


On May 1, 2007, at 11:14 PM, Chris Pickel wrote:

> On the subject of frameworks:
>
> Is there a standard install directory for frameworks? On some  
> Portfiles (notably the libsdl*-framework ports), frameworks are  
> installed to /Library/Frameworks. On others (such as python2[45]),  
> they are installed to ${prefix}/Library/Frameworks.

+1 on the later, as I sometimes need to make portable firewire/USB  
drives with a complete MacPorts build under /Volumes/something.

Regards,
Blair

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



From ryandesign at macports.org  Wed May  2 00:15:00 2007
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue Oct  9 16:40:16 2007
Subject: Framework Install Dir
In-Reply-To: <E79AB4AE-C26D-479B-B48C-6DA6B34C20D3@orcaware.com>
References: <4405F136-209A-4834-B465-962729868808@stwing.upenn.edu>
	<E79AB4AE-C26D-479B-B48C-6DA6B34C20D3@orcaware.com>
Message-ID: <246538B0-5BC2-4E0E-8F9C-CFEC247F7E9D@macports.org>

On May 2, 2007, at 01:16, Blair Zajac wrote:

> On May 1, 2007, at 11:14 PM, Chris Pickel wrote:
>
>> On the subject of frameworks:
>>
>> Is there a standard install directory for frameworks? On some  
>> Portfiles (notably the libsdl*-framework ports), frameworks are  
>> installed to /Library/Frameworks. On others (such as python2[45]),  
>> they are installed to ${prefix}/Library/Frameworks.
>
> +1 on the later, as I sometimes need to make portable firewire/USB  
> drives with a complete MacPorts build under /Volumes/something.

Based on the source code in base/src/port1.0/resources/group/ 
xcode-1.0.tcl it looks like the standard is for applications to get  
installed in /Applications/MacPorts and frameworks to get installed  
in /Library/Frameworks. Would it still work for frameworks to be in $ 
{prefix}?



From ryandesign at macports.org  Wed May  2 01:07:19 2007
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue Oct  9 16:40:16 2007
Subject: Fixed-width font in commit mails?
In-Reply-To: <fc.004c4c580c86a9703b9aca00e98a98ef.c86ac28@biola.edu>
References: <2A1DFDFB-911E-41D8-86CE-DF18183333DB@macports.org>
	<fc.004c4c580c86a9703b9aca00e98a98ef.c86ac28@biola.edu>
Message-ID: <7D197EA3-1413-4EBC-887E-9E8FA02B02BB@macports.org>

On May 1, 2007, at 20:11, Mark Duling wrote:

>> Can't locate Net/SMTP_auth.pm in @INC (@INC contains: /opt/local/lib/
>> perl5/5.8.8/darwin-2level /opt/local/lib/perl5/5.8.8 /opt/local/lib/
>> perl5/site_perl/5.8.8/darwin-2level /opt/local/lib/perl5/site_perl/
>> 5.8.8 /opt/local/lib/perl5/site_perl /opt/local/lib/perl5/ 
>> vendor_perl/
>> 5.8.8/darwin-2level /opt/local/lib/perl5/vendor_perl/5.8.8 /opt/ 
>> local/
>> lib/perl5/vendor_perl .) at /opt/local/lib/perl5/vendor_perl/5.8.8/
>> SVN/Notify.pm line 2047.
>
> See if this has what you need:
>
> p5-net
>
> I created that recently and it has SMTP stuff in it and is listed  
> on CPAN
> as Net::SMTP.  I called it p5-net because FreeBSD did that, there  
> are a
> lot of non-mail modules, and there are quite a few libraries listed on
> CPAN listed as Net::SMTP:XXX (none of which are ported.)  If it  
> isn't that
> one you'll need to find the right one on CPAN and port it.

Thanks for the tip! It looks like that contains Net/SMTP.pm, but not  
Net/SMTP_auth.pm.

So I made a new port, p5-net-smtp_auth. This is my first perl module  
port so I hope I got it all right. svnnotify seems to work now.  
Still, I'd appreciate it if a p5 expert would look over the new port  
and make any necessary corrections.

http://trac.macosforge.org/projects/macports/browser/trunk/dports/ 
perl/p5-net-smtp_auth/Portfile


Daniel, I think p5-net-smtp_auth should be added as a dependency to  
p5-svn-notify; this is what I get now when I install it:

$ sudo port -t install p5-svn-notify
--->  Fetching p5-svn-notify
--->  Verifying checksum(s) for p5-svn-notify
--->  Extracting p5-svn-notify
--->  Configuring p5-svn-notify
Warning: Target configure has an undeclared dependency on p5-net- 
smtp_auth
--->  Building p5-svn-notify with target all
--->  Staging p5-svn-notify into destroot
--->  Installing p5-svn-notify 2.65_0
--->  Activating p5-svn-notify 2.65_0
--->  Cleaning p5-svn-notify
$



From ryandesign at macports.org  Wed May  2 02:43:26 2007
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue Oct  9 16:40:16 2007
Subject: Let's add variant descriptions
In-Reply-To: <92443306-425B-4CE2-B49B-D7F828100014@macports.org>
References: <37864CC8-FF04-4975-81E6-44D8A8DA126B@macports.org>
	<fc.004c4c580c8043d13b9aca009ae55da7.c804602@biola.edu>
	<607B9618-00A5-4927-9842-BCB6A9949A8B@macports.org>
	<92443306-425B-4CE2-B49B-D7F828100014@macports.org>
Message-ID: <3487D8B3-90EB-45B5-A55B-8CEFCB937308@macports.org>


On Apr 30, 2007, at 10:04, Elias Pipping wrote:

> On Apr 29, 2007, at 9:55 AM, Ryan Schmidt wrote:
>
>> It's annoying that "port search" shows description, but "port  
>> info" only shows long_description.
>
> Isn't that precisely what description and long_description were  
> made for?

Is it? I don't know.

It seemed to me that "port info" should show more info -- should show  
everything you can see with "port search" and then some. Nothing that  
you can see with "port search" (i.e. the (short) description) should  
be omitted.

Though I have seen some portfiles that set the description and  
long_description to the same thing, so those would look silly in  
"port info" if it were changed to show both strings.

Though these ports currently already look silly in "port info"  
because it prints curly braces around the long description. For example:


$ port info p5-archive-tar
p5-archive-tar 1.30, perl/p5-archive-tar (Variants: universal)
http://search.cpan.org/dist/Archive-Tar/

{Creation and in-memory manipulation of tar files}

Library Dependencies: perl5.8, p5-io-zlib, p5-text-diff
Platforms: darwin
Maintainers: narf_tm@macports.org




From sbranzo at gmail.com  Wed May  2 09:35:42 2007
From: sbranzo at gmail.com (Sbranzo)
Date: Tue Oct  9 16:40:16 2007
Subject: Mutt-devel problem, maybe headers-cache
Message-ID: <20070502163542.GA27459@sbranzo.piglets>

Maybe someone could help me with mutt-devel.
After forcing portindex update I was trying to port upgrade mutt-devel
but:

sudo port upgrade outdated
Password:
--->  Building mutt-devel with target all
Error: Target com.apple.build returned: shell command " cd
"/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_mail_mutt-devel/work/mutt-1.5.15"
&& make all " returned error 2
Command output: ( echo '#include "config.h"'; echo '#include "mutt.h"';
) \
| gcc -E -DPKGDATADIR=\"/opt/local/share/mutt\"
-DSYSCONFDIR=\"/opt/local/etc\" -DBINDIR=\"/opt/local/bin\"
-DMUTTLOCALEDIR=\"/opt/local/share/locale\" -DHAVE_CONFIG_H=1 -I. -I.
-I.  -I. -I. -I./imap  -Iintl -I/opt/local/include/db4
-I/opt/local/include -I/opt/local/include/db44 -I/opt/local/include
-I./intl - | ./hcachever.sh hcversion.h
ERROR: no MD5 tool found
<built-in>:0: fatal error: when writing output to : Broken pipe
compilation terminated.
make: *** [hcversion.h] Error 1

This is the current installed version:
$ port installed mutt-devel
The following ports are currently installed:
mutt-devel @1.5.14_1+db4+headercache+imap+pop (active)


Maybe I'm overlooking something trivial.

Thanks,
Gufo

From olaf at foellinger.de  Wed May  2 11:24:28 2007
From: olaf at foellinger.de (Olaf Foellinger)
Date: Tue Oct  9 16:40:16 2007
Subject: Mutt-devel problem, maybe headers-cache
In-Reply-To: <20070502163542.GA27459@sbranzo.piglets>
References: <20070502163542.GA27459@sbranzo.piglets>
Message-ID: <20070502182428.GA735@foellinger.de>

Hi,

* Sbranzo <sbranzo@gmail.com> [02.05.07 18:35]wrote:

> Maybe someone could help me with mutt-devel.
> After forcing portindex update I was trying to port upgrade mutt-devel
> but:
> 
> sudo port upgrade outdated
> Password:
> --->  Building mutt-devel with target all
> Error: Target com.apple.build returned: shell command " cd
> "/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_mail_mutt-devel/work/mutt-1.5.15"
> && make all " returned error 2
> Command output: ( echo '#include "config.h"'; echo '#include "mutt.h"';
> ) \
> | gcc -E -DPKGDATADIR=\"/opt/local/share/mutt\"
> -DSYSCONFDIR=\"/opt/local/etc\" -DBINDIR=\"/opt/local/bin\"
> -DMUTTLOCALEDIR=\"/opt/local/share/locale\" -DHAVE_CONFIG_H=1 -I. -I.
> -I.  -I. -I. -I./imap  -Iintl -I/opt/local/include/db4
> -I/opt/local/include -I/opt/local/include/db44 -I/opt/local/include
> -I./intl - | ./hcachever.sh hcversion.h
> ERROR: no MD5 tool found
> <built-in>:0: fatal error: when writing output to : Broken pipe
> compilation terminated.
> make: *** [hcversion.h] Error 1
> 
> This is the current installed version:
> $ port installed mutt-devel
> The following ports are currently installed:
> mutt-devel @1.5.14_1+db4+headercache+imap+pop (active)
> 
> 
> Maybe I'm overlooking something trivial.

I'll have a look at it after my port index has been updated.

Gruss Olaf

From olaf at foellinger.de  Wed May  2 14:21:56 2007
From: olaf at foellinger.de (Olaf Foellinger)
Date: Tue Oct  9 16:40:16 2007
Subject: Mutt-devel problem, maybe headers-cache
In-Reply-To: <20070502163542.GA27459@sbranzo.piglets>
References: <20070502163542.GA27459@sbranzo.piglets>
Message-ID: <20070502212156.GA1338@foellinger.de>

Hi

* Sbranzo <sbranzo@gmail.com> [02.05.07 18:35]wrote:

> Maybe someone could help me with mutt-devel.
> After forcing portindex update I was trying to port upgrade mutt-devel
> but:
> 
> sudo port upgrade outdated
> Password:
> --->  Building mutt-devel with target all
> Error: Target com.apple.build returned: shell command " cd
> "/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_mail_mutt-devel/work/mutt-1.5.15"
> && make all " returned error 2
> Command output: ( echo '#include "config.h"'; echo '#include "mutt.h"';
> ) \
> | gcc -E -DPKGDATADIR=\"/opt/local/share/mutt\"
> -DSYSCONFDIR=\"/opt/local/etc\" -DBINDIR=\"/opt/local/bin\"
> -DMUTTLOCALEDIR=\"/opt/local/share/locale\" -DHAVE_CONFIG_H=1 -I. -I.
> -I.  -I. -I. -I./imap  -Iintl -I/opt/local/include/db4
> -I/opt/local/include -I/opt/local/include/db44 -I/opt/local/include
> -I./intl - | ./hcachever.sh hcversion.h
> ERROR: no MD5 tool found
> <built-in>:0: fatal error: when writing output to : Broken pipe
> compilation terminated.
> make: *** [hcversion.h] Error 1
> 
> This is the current installed version:
> $ port installed mutt-devel
> The following ports are currently installed:
> mutt-devel @1.5.14_1+db4+headercache+imap+pop (active)
> 
> 
> Maybe I'm overlooking something trivial.

it builds fine here with these options. 

What's shown above is the message

ERROR: no MD5 tool found

which comes from the lines 

if test -x "`which md5`"
then
  MD5=md5
  elif test -x "`which md5sum`"
  then
    MD5=md5sum
    elif test -x "`which openssl`"
  then
      MD5="openssl md5 -hex"
      else
        echo "ERROR: no MD5 tool found"
  exit 1
 fi

 in hcachever.sh from the root of the mutt source directory
			  
Here is 

$ which md5
/sbin/md5

Is /sbin in your path? Are you on Mac OS X? Which version? Is there
another md5 tool in your path?

Gruss Olaf

From dluke at geeklair.net  Wed May  2 14:30:00 2007
From: dluke at geeklair.net (Daniel J. Luke)
Date: Tue Oct  9 16:40:16 2007
Subject: Fixed-width font in commit mails?
In-Reply-To: <7D197EA3-1413-4EBC-887E-9E8FA02B02BB@macports.org>
References: <2A1DFDFB-911E-41D8-86CE-DF18183333DB@macports.org>
	<fc.004c4c580c86a9703b9aca00e98a98ef.c86ac28@biola.edu>
	<7D197EA3-1413-4EBC-887E-9E8FA02B02BB@macports.org>
Message-ID: <34BDE7CE-091B-4F98-A459-66DF6C1FFB75@geeklair.net>

On May 2, 2007, at 4:07 AM, Ryan Schmidt wrote:
> So I made a new port, p5-net-smtp_auth. This is my first perl  
> module port so I hope I got it all right. svnnotify seems to work  
> now. Still, I'd appreciate it if a p5 expert would look over the  
> new port and make any necessary corrections.
>
> http://trac.macosforge.org/projects/macports/browser/trunk/dports/ 
> perl/p5-net-smtp_auth/Portfile
>
> Daniel, I think p5-net-smtp_auth should be added as a dependency to  
> p5-svn-notify;

the Net::SMTP_auth module isn't needed for SVN::Notify (unless you  
want/need to use SMTP auth)... but it probably doesn't make the build  
take too long, so I'll go ahead and add it to the p5-svn-notify port.

> this is what I get now when I install it:
>
> $ sudo port -t install p5-svn-notify
> --->  Fetching p5-svn-notify
> --->  Verifying checksum(s) for p5-svn-notify
> --->  Extracting p5-svn-notify
> --->  Configuring p5-svn-notify
> Warning: Target configure has an undeclared dependency on p5-net- 
> smtp_auth
> --->  Building p5-svn-notify with target all
> --->  Staging p5-svn-notify into destroot
> --->  Installing p5-svn-notify 2.65_0
> --->  Activating p5-svn-notify 2.65_0
> --->  Cleaning p5-svn-notify
> $

That's an artifact of how the perl build system and trace mode  
interact (if you remove the smtp_auth module installed, svn-notify  
would still build/test/install/work fine, but with it installed it  
will allow that additional functionality)

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070502/e8b0baff/PGP.bin
From sal at ri.cmu.edu  Wed May  2 15:03:30 2007
From: sal at ri.cmu.edu (Salvatore Domenick Desiano)
Date: Tue Oct  9 16:40:16 2007
Subject: Job control in tcsh 6.15.00
Message-ID: <Pine.LNX.4.64.0705021802480.27034@linux4.gp.cs.cmu.edu>

Anybody else having trouble with job control in the current version of 
tcsh? I just upgraded from 6.13, and I can no longer suspend or 
interrupt programs.

-- Sal
smile.


--------------
   Salvatore Domenick Desiano
     Doctoral Candidate
       Robotics Institute
         Carnegie Mellon University

From guido.soranzio at gmail.com  Thu May  3 02:40:59 2007
From: guido.soranzio at gmail.com (Guido Soranzio)
Date: Tue Oct  9 16:40:16 2007
Subject: New "file delete" implementation breaks ncurses
Message-ID: <00A8B080-2CA9-4CDA-8864-0E9D5AA54F14@gmail.com>

After the changes to the "file delete" implementation, the  
installation of
ncurses fails because it tries to follow the target of a symbolic link.


By reversing the order of the arguments from

delete ${destroot}${prefix}/share ${destroot}${prefix}/lib/terminfo

into

delete ${destroot}${prefix}/lib/terminfo ${destroot}${prefix}/share

ncurses installs correctly (lib/terminfo is a symbolic link to ../ 
share/terminfo).


I have already submitted a bug report through Trac
(http://trac.macosforge.org/projects/macports/ticket/11878)
but it doesn't have been reviewed for too long.

From mww at macports.org  Thu May  3 03:31:44 2007
From: mww at macports.org (Weissmann Markus)
Date: Tue Oct  9 16:40:16 2007
Subject: [24526] trunk/dports/lang/gcc42/Portfile
In-Reply-To: <DA5F8D01-EE29-43E5-979C-55457E9E94F8@macports.org>
References: <20070427153046.0BECF5D9885@cvs.opensource.apple.com>
	<DA5F8D01-EE29-43E5-979C-55457E9E94F8@macports.org>
Message-ID: <C5FD5600-6524-46F5-94D7-BE9BC9B53CB6@macports.org>

Hi Juan,

On 27 Apr 2007, at 18:04, Juan Manuel Palacios wrote:

> On Apr 27, 2007, at 11:30 AM, source_changes@macosforge.org wrote:
>
>> Revision 24526 Author mww@macports.org Date 2007-04-27 08:30:45  
>> -0700 (Fri, 27 Apr 2007) Log Message version (prerelease)  
>> 4.2.0-20070316, change program suffix to "-mp-${major}"
>
>
> 	Nice going with this rename, in sync with my dp2mp-move branch ;-)  
> Will we see this move in other gcc ports, like gcc41, even though  
> they're no longer current? I figure some users might still have a  
> need for them, and will probably be confused by the deprecated "dp"  
> prefix. Maybe we should get a message out to all port maintainers  
> who use any incarnation of  [dD]arwin[pP]orts in their  
> installations to move to the new naming.... /me thinks...
>
>

I think for the gcc42 port, it's no big problem chaning the suffix as  
only four (?) ports use it at all. Also gcc 4.2 is in beta phase so  
it is not guaranteed to work at all and people will update much more  
likely than with the gcc40 or gcc41 ports.
For those I'd say we leave symlinks for backwards compatibility, like  
"gcc-mp-4.0" being the name of the binary and a symlink pointing to  
it with name "gcc-dp-4.0". I suppose we should document this naming  
scheme anywhere though - both, the old and new one.


salut,

-Markus

---
Markus W. Weissmann
http://www.mweissmann.de/



From sbranzo at gmail.com  Thu May  3 03:51:06 2007
From: sbranzo at gmail.com (Sbranzo)
Date: Tue Oct  9 16:40:16 2007
Subject: Mutt-devel problem, maybe headers-cache
In-Reply-To: <20070502212156.GA1338@foellinger.de>
References: <20070502163542.GA27459@sbranzo.piglets>
	<20070502212156.GA1338@foellinger.de>
Message-ID: <20070503105106.GA649@sbranzo.crema.unimi.it>

On 02/05/07 23:21, Olaf Foellinger wrote:
> Here is 
> 
> $ which md5
> /sbin/md5
> 
> Is /sbin in your path? Are you on Mac OS X? Which version? Is there
> another md5 tool in your path?

[sbranzo] root ~ # /opt/local/bin/port upgrade mutt-devel
--->  Fetching mutt-devel
--->  Verifying checksum(s) for mutt-devel
--->  Extracting mutt-devel
--->  Configuring mutt-devel
--->  Building mutt-devel with target all
--->  Staging mutt-devel into destroot
--->  Packaging tgz archive for mutt-devel
1.5.15_1+db4+headercache+imap+pop
--->  Deactivating mutt-devel 1.5.14_1+db4+headercache+imap+pop
--->  Installing mutt-devel 1.5.15_1+db4+headercache+imap+pop
--->  Activating mutt-devel 1.5.15_1+db4+headercache+imap+pop
--->  Cleaning mutt-devel

Which is ok, but through sudo I had the same problem as before:

[sbranzo] gufo ~ $ sudo port upgrade mutt-devel
--->  Building mutt-devel with target all
Error: Target com.apple.build returned: shell command " cd
"/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_mail_mutt-devel/work/mutt-1.5.15"
&& make all " returned error 2
Command output: ( echo '#include "config.h"'; echo '#include "mutt.h"';
) \
| gcc -E -DPKGDATADIR=\"/opt/local/share/mutt\"
-DSYSCONFDIR=\"/opt/local/etc\" -DBINDIR=\"/opt/local/bin\"
-DMUTTLOCALEDIR=\"/opt/local/share/locale\" -DHAVE_CONFIG_H=1 -I. -I.
-I.  -I. -I. -I./imap  -Iintl -I/opt/local/include/db4
-I/opt/local/include -I/opt/local/include/db44 -I/opt/local/include
-I./intl - | ./hcachever.sh hcversion.h
ERROR: no MD5 tool found
<built-in>:0: fatal error: when writing output to : Broken pipe
compilation terminated.
make: *** [hcversion.h] Error 1

Error: Unable to upgrade port: 1

even if:
[sbranzo] gufo ~ $ which md5sum 
/opt/local/bin/md5sum
[sbranzo] gufo ~ $ which md5
/sbin/md5
[sbranzo] gufo ~ $ sudo which md5
Password:
/sbin/md5
[sbranzo] gufo ~ $ sudo which md5sum
/opt/local/bin/md5sum

At the very least now mutt is updated...

Thanks!

Gufo

From eridius at macports.org  Thu May  3 15:06:29 2007
From: eridius at macports.org (Kevin Ballard)
Date: Tue Oct  9 16:40:16 2007
Subject: New "file delete" implementation breaks ncurses
In-Reply-To: <00A8B080-2CA9-4CDA-8864-0E9D5AA54F14@gmail.com>
References: <00A8B080-2CA9-4CDA-8864-0E9D5AA54F14@gmail.com>
Message-ID: <E3968521-D9CA-4E49-8C61-FBAB22A7344B@macports.org>

Oh hrm, it didn't occur to me that this would happen, but I know  
exactly why.

However, I'm on vacation. Can this wait a week? It's a problem that  
only affects trunk.

On May 3, 2007, at 5:40 AM, Guido Soranzio wrote:

> After the changes to the "file delete" implementation, the  
> installation of
> ncurses fails because it tries to follow the target of a symbolic  
> link.
>
>
> By reversing the order of the arguments from
>
> delete ${destroot}${prefix}/share ${destroot}${prefix}/lib/terminfo
>
> into
>
> delete ${destroot}${prefix}/lib/terminfo ${destroot}${prefix}/share
>
> ncurses installs correctly (lib/terminfo is a symbolic link to ../ 
> share/terminfo).

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070503/1f449700/attachment.html
From sal at ri.cmu.edu  Thu May  3 22:00:26 2007
From: sal at ri.cmu.edu (Salvatore Domenick Desiano)
Date: Tue Oct  9 16:40:16 2007
Subject: Stellarium Port
Message-ID: <Pine.LNX.4.64.0705040058080.2638@linux4.gp.cs.cmu.edu>

Paul and I just had a talk about the Stellarium port. The port was once 
useful when there were no binaries available for OSX, but now the 
project is releasing DMG's on a regular basis. Not only that, there is 
some undocumented voodoo for building on OSX/Intel, which we don't have 
in our portfile.

As maintainer of the port, I recommend that we remove it from our port 
tree. Objections?

As a person who keeps forgetting to get his commit bit set, can somebody 
do the deed? I can file a bug if that person prefers. Thank you.

-- Sal
smile

--------------
   Salvatore Domenick Desiano
     Doctoral Candidate
       Robotics Institute
         Carnegie Mellon University

From pipping at macports.org  Thu May  3 23:09:01 2007
From: pipping at macports.org (Elias Pipping)
Date: Tue Oct  9 16:40:16 2007
Subject: Stellarium Port
In-Reply-To: <Pine.LNX.4.64.0705040058080.2638@linux4.gp.cs.cmu.edu>
References: <Pine.LNX.4.64.0705040058080.2638@linux4.gp.cs.cmu.edu>
Message-ID: <6E2B402E-3BFD-4D60-8117-0A75BFFF37CD@macports.org>

On May 4, 2007, at 7:00 AM, Salvatore Domenick Desiano wrote:

> As maintainer of the port, I recommend that we remove it from our  
> port tree. Objections?
>
> As a person who keeps forgetting to get his commit bit set, can  
> somebody do the deed? I can file a bug if that person prefers.  
> Thank you.

Done[1].

[1] http://trac.macports.org/projects/macports/changeset/24781


Regards,

Elias Pipping

From sal at ri.cmu.edu  Thu May  3 23:12:16 2007
From: sal at ri.cmu.edu (Salvatore Domenick Desiano)
Date: Tue Oct  9 16:40:16 2007
Subject: Stellarium Port
In-Reply-To: <6E2B402E-3BFD-4D60-8117-0A75BFFF37CD@macports.org>
References: <Pine.LNX.4.64.0705040058080.2638@linux4.gp.cs.cmu.edu>
	<6E2B402E-3BFD-4D60-8117-0A75BFFF37CD@macports.org>
Message-ID: <Pine.LNX.4.64.0705040212130.2638@linux4.gp.cs.cmu.edu>

Danke!


--------------
  Salvatore Domenick Desiano
    Doctoral Candidate
      Robotics Institute
        Carnegie Mellon University

On Fri, 4 May 2007, Elias Pipping wrote:

o On May 4, 2007, at 7:00 AM, Salvatore Domenick Desiano wrote:
o 
o > As maintainer of the port, I recommend that we remove it from our port tree.
o > Objections?
o > 
o > As a person who keeps forgetting to get his commit bit set, can somebody do
o > the deed? I can file a bug if that person prefers. Thank you.
o 
o Done[1].
o 
o [1] http://trac.macports.org/projects/macports/changeset/24781
o 
o 
o Regards,
o 
o Elias Pipping
o 

From t.lucas at toolmantim.com  Fri May  4 00:27:41 2007
From: t.lucas at toolmantim.com (Tim Lucas)
Date: Tue Oct  9 16:40:16 2007
Subject: New port for ruby-dbi with odbc support
Message-ID: <E003B23F-4D76-4ED9-B858-95FF0194187C@toolmantim.com>

There's two port files, rb-dbd-pg and db-dbd-mysql that currently  
just extend rb-dbi with a few configure args. They should probably  
use variants, but I digress. I've created another Portfile, in the  
spirit of these two, so you can install ruby-dbi with odbc support  
via macports, just like you can with mysql or postgres. It's a dead- 
simple Portfile.

How can I get this added to the ports tree?

(feel free to point me to an FAQ... the macports site+docos are  
excruciating, have spent ages looking already)

-- tim


From boeyms at macports.org  Fri May  4 01:11:57 2007
From: boeyms at macports.org (Boey Maun Suang)
Date: Tue Oct  9 16:40:16 2007
Subject: New port for ruby-dbi with odbc support
In-Reply-To: <E003B23F-4D76-4ED9-B858-95FF0194187C@toolmantim.com>
References: <E003B23F-4D76-4ED9-B858-95FF0194187C@toolmantim.com>
Message-ID: <B656B14C-ABF6-4A05-816C-AE13348EC61B@macports.org>

Hi Tim,

> There's two port files, rb-dbd-pg and db-dbd-mysql that currently  
> just extend rb-dbi with a few configure args. They should probably  
> use variants, but I digress. I've created another Portfile, in the  
> spirit of these two, so you can install ruby-dbi with odbc support  
> via macports, just like you can with mysql or postgres. It's a dead- 
> simple Portfile.
>
> How can I get this added to the ports tree?

The most transparent way is to submit a ticket for the new port in  
the requested format [1]; don't forget to enter the addresses in the  
Cc field as described.  A committer will then check it and commit it  
if they're happy with it.  As for rb-dbd-pg and rb-dbd-mysql, it'd be  
great if you could file a ticket about those too so that the  
maintainer(s) know about your suggestion.

> (feel free to point me to an FAQ... the macports site+docos are  
> excruciating, have spent ages looking already)

There has been some discussion recently on macports-dev@ about our  
documentation, but unfortunately none of us has gotten around to  
doing some organised planning and work on it.  It'll be one of my  
priorities when I get enough free time.

Thanks the new port!

Kind regards,


Maun Suang

[1] http://trac.macports.org/projects/macports/wiki/TracTicketing

-- 
Boey Maun Suang (Boey is my surname)
Email: boeyms@macports.org




From mww at macports.org  Fri May  4 03:46:55 2007
From: mww at macports.org (Weissmann Markus)
Date: Tue Oct  9 16:40:16 2007
Subject: python2.5 has wrong value for
	distutils.sysconfig.get_config_var("PYTHON")
In-Reply-To: <4637E56E.1010703@orcaware.com>
References: <1ea387f60705011534j54c68280vd9e167810becb9df@mail.gmail.com>	
	<1ea387f60705011553w1b4643d3hff42d303ce9f4268@mail.gmail.com>	
	<4637CB06.6020403@orcaware.com>
	<1ea387f60705011623i21860272h670bc819fb56a286@mail.gmail.com>
	<4637E56E.1010703@orcaware.com>
Message-ID: <D3B2CA65-BD2E-455F-8047-EC04F23A2010@macports.org>

On 2 May 2007, at 03:12, Blair Zajac wrote:

> David Glasser wrote:
>> On 5/1/07, Blair Zajac <blair@orcaware.com> wrote:
>>> Can you write a quick patch for the python2.5 Portfile to do what  
>>> you're
>>> referring to here?
>> Working on it.  I've never been so good about understanding how to
>> test my own Portfiles though --- I mean, I know I can just put
>> Portfile in a random directory and type "port install", but how do I
>> make it forget completely about my version and upgrade to the "real"
>> version once my patch has been accepted by MacPorts?
>
> I use the port at the same revision number as the official port,  
> then uninstall the current version, put my local port repository in  
> $prefix/etc/ports/sources.conf as a file:/// before the rsync one,  
> then use portindex.  When I'm happy, I submit it upstream with a  
> bump in revision and move the port out of my local repository (say  
> into a retired ports directory that MacPorts doesn't nsee), since  
> it shadows the main one.
>
>> (About the issue itself: it looks like this actually requires  
>> patching
>> the Makefile, since PYTHON is not actually a configure argument.
>> Ugh.)
>> (BTW Blair, this is to get David James' svn ctypes stuff working.)
>
> Cool.  That'll be nice to get in.
>

o.k. - I've just submitted revision 1 of python25 that includes a fix  
for this - the PYTHON variable now points to @bindir@/python2.5 (e.  
g. /opt/local/bin/python2.5).

Please let me know if this causes any troubles elsewhere and if it  
fixes the ctypes problem (or if we need to patch more stuff)


salut,

-Markus

---
Markus W. Weissmann
http://www.mweissmann.de/



From glasser at mit.edu  Fri May  4 04:09:00 2007
From: glasser at mit.edu (David Glasser)
Date: Tue Oct  9 16:40:16 2007
Subject: python2.5 has wrong value for
	distutils.sysconfig.get_config_var("PYTHON")
In-Reply-To: <D3B2CA65-BD2E-455F-8047-EC04F23A2010@macports.org>
References: <1ea387f60705011534j54c68280vd9e167810becb9df@mail.gmail.com>
	<1ea387f60705011553w1b4643d3hff42d303ce9f4268@mail.gmail.com>
	<4637CB06.6020403@orcaware.com>
	<1ea387f60705011623i21860272h670bc819fb56a286@mail.gmail.com>
	<4637E56E.1010703@orcaware.com>
	<D3B2CA65-BD2E-455F-8047-EC04F23A2010@macports.org>
Message-ID: <1ea387f60705040409q1ca9dda2hc55d952f05fa488@mail.gmail.com>

On 5/4/07, Weissmann Markus <mww@macports.org> wrote:
> o.k. - I've just submitted revision 1 of python25 that includes a fix
> for this - the PYTHON variable now points to @bindir@/python2.5 (e.
> g. /opt/local/bin/python2.5).
>
> Please let me know if this causes any troubles elsewhere and if it
> fixes the ctypes problem (or if we need to patch more stuff)

Cool!

For what it's worth, though, it was pointed out to me that I should
probably just use sys.executable instead of
distutils.sysconfig.get_config_var("PYTHON").

--dave

-- 
David Glasser | glasser@mit.edu | http://www.davidglasser.net/

From evenson at panix.com  Fri May  4 09:33:08 2007
From: evenson at panix.com (Mark Evenson)
Date: Tue Oct  9 16:40:16 2007
Subject: Maintainer but not committer with update: Submitted a Trac ticket, 
 now I just wait?
Message-ID: <f1fn7v$3mk$1@sea.gmane.org>

I am the maintainer of 'lang/slime' for which I have submitted a ticket 
to Trac [1], attaching it to the Milestone "Port Updates".

Now I just wait for a committer to notice this, or should I bring it to 
some email address's attention?  The Wiki has the start [2] of guide to 
these questions, but no answers, for which it would be good to fill in 
even provisional answers to the procedure.


1: http://trac.macports.org/projects/macports/ticket/11902

2: http://trac.macosforge.org/projects/macports/wiki/MaintainingAPort


From emory.smith at gmail.com  Fri May  4 10:02:14 2007
From: emory.smith at gmail.com (Emory Smith)
Date: Tue Oct  9 16:40:16 2007
Subject: Maintainer but not committer with update: Submitted a Trac
	ticket, now I just wait?
In-Reply-To: <f1fn7v$3mk$1@sea.gmane.org>
References: <f1fn7v$3mk$1@sea.gmane.org>
Message-ID: <70918D6F-EF18-489A-BC6F-8E86EB6EAD0A@gmail.com>

ive been wondering the same thing ... sometimes they snatched up  
right away, others might sit indefinitely, as these two appear to  
have been doing for the last month:

php5-memcache (http://trac.macports.org/projects/macports/ticket/11753)

php5-syck (http://trac.macports.org/projects/macports/ticket/11754)

-emory


On May 4, 2007, at 10:33 AM, Mark Evenson wrote:

> I am the maintainer of 'lang/slime' for which I have submitted a  
> ticket to Trac [1], attaching it to the Milestone "Port Updates".
>
> Now I just wait for a committer to notice this, or should I bring  
> it to some email address's attention?  The Wiki has the start [2]  
> of guide to these questions, but no answers, for which it would be  
> good to fill in even provisional answers to the procedure.
>
>
> 1: http://trac.macports.org/projects/macports/ticket/11902
>
> 2: http://trac.macosforge.org/projects/macports/wiki/MaintainingAPort
>
> _______________________________________________
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev


From pipping at macports.org  Fri May  4 10:52:38 2007
From: pipping at macports.org (Elias Pipping)
Date: Tue Oct  9 16:40:16 2007
Subject: Maintainer but not committer with update: Submitted a Trac
	ticket, now I just wait?
In-Reply-To: <f1fn7v$3mk$1@sea.gmane.org>
References: <f1fn7v$3mk$1@sea.gmane.org>
Message-ID: <AD711EEF-659F-429E-9E5D-1778F0B6662A@macports.org>

committed in r24798[1].


Regards,

Elias Pipping


[1] http://trac.macports.org/projects/macports/changeset/24798


On May 4, 2007, at 6:33 PM, Mark Evenson wrote:

> I am the maintainer of 'lang/slime' for which I have submitted a  
> ticket to Trac [1], attaching it to the Milestone "Port Updates".
>
> Now I just wait for a committer to notice this, or should I bring  
> it to some email address's attention?  The Wiki has the start [2]  
> of guide to these questions, but no answers, for which it would be  
> good to fill in even provisional answers to the procedure.
>
>
> 1: http://trac.macports.org/projects/macports/ticket/11902
>
> 2: http://trac.macosforge.org/projects/macports/wiki/MaintainingAPort
>
> _______________________________________________
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev


From meissnem at gmail.com  Fri May  4 11:03:05 2007
From: meissnem at gmail.com (Matt Meissner)
Date: Tue Oct  9 16:40:16 2007
Subject: Maintainer but not committer with update: Submitted a Trac
	ticket, now I just wait?
In-Reply-To: <70918D6F-EF18-489A-BC6F-8E86EB6EAD0A@gmail.com>
References: <f1fn7v$3mk$1@sea.gmane.org>
	<70918D6F-EF18-489A-BC6F-8E86EB6EAD0A@gmail.com>
Message-ID: <F9C8A6C7-604D-4CB7-96CC-72FA4462CE0F@gmail.com>

On May 4, 2007, at 12:02 PM, Emory Smith wrote:

> On May 4, 2007, at 10:33 AM, Mark Evenson wrote:
>
>> I am the maintainer of 'lang/slime' for which I have submitted a  
>> ticket to Trac [1], attaching it to the Milestone "Port Updates".
>>
>> Now I just wait for a committer to notice this, or should I bring  
>> it to some email address's attention?  The Wiki has the start [2]  
>> of guide to these questions, but no answers, for which it would be  
>> good to fill in even provisional answers to the procedure.
>>
>>
>> 1: http://trac.macports.org/projects/macports/ticket/11902
>>
>> 2: http://trac.macosforge.org/projects/macports/wiki/MaintainingAPort
>
> ive been wondering the same thing ... sometimes they snatched up  
> right away, others might sit indefinitely, as these two appear to  
> have been doing for the last month:
>
> php5-memcache (http://trac.macports.org/projects/macports/ticket/ 
> 11753)
>
> php5-syck (http://trac.macports.org/projects/macports/ticket/11754)
>

Back in the day, there was a committer or two assigned to each port  
category.  Submitters were instructed to change the owner of a bug to  
the category committer.

Portmgr, is that policy still in effect?  If so, where is the up-to- 
date list of category owners?

Thanks,
matt

-- 
Matt Meissner
meissnem at gmail.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2419 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070504/204c639a/smime.bin
From gwhitney at pobox.com  Fri May  4 19:19:47 2007
From: gwhitney at pobox.com (Glen Whitney)
Date: Tue Oct  9 16:40:16 2007
Subject: dependency options in portfiles
Message-ID: <463BE9C3.3090300@pobox.com>

  Dear MacPorts folks,

  Portfiles currently have three dependency options:
  depends_build, depends_run, and depends_lib.

  However, the correspondence between these options and the processing 
phases (I guess "targets" in the internal terminology of the MacPorts 
base code) is weak: depends_build does record the dependencies that are 
necessary for the build target, but there is no run target or lib 
target, rather the following rich collection of targets:

  main, unarchive, fetch, checksum, extract, patch, configure, build, 
test, destroot, archive, install, activate (and port understands the 
relationship among these with the requires/provides attributes of the 
targets).

  Currently, depends_run corresponds to the destroot phase (but 
conceptually it seems like it should either correspond to test or 
activate, from the name) and depends_lib corresponds to configure.

  In any case, it's clearly natural to classify dependencies by the 
phase at which they kick in; and conversely, various other of the above 
phases could quite reasonably have dependencies specific to them. For 
example, if a package is released with a spiffy new compression 
algorithm which is not yet universally available, the extract step for 
that package could depend on the port of the decompressor for that 
algorithm. Or the real backstory here: I'm trying to create Portfiles 
which capture the current gtk+osx build process, which I have gotten to 
work manually all the way up to Gnucash, but which I never want to have 
to do by hand again.  Currently one needs to extract the cairo 
development head by git for this all to work. I would therefore like the 
fetch phase to depend on the git port, but currently there's no way to 
specify any dependency for fetch.

  So the following proposal seems like it would be a big win to me. 
Each target should have an optional depends attribute, i.e.

  configure.depends port:libiconv  #typical case now

  or

  fetch.depends port:git_core     #my case

  or

  activate.depends port:ghostview #e.g., previewer is never used until 
active pkg is invoked by user, but this is our Last Chance

  Before MacPorts executes any target, it would ensure that all of the 
dependencies for that target (and the targets it requires, i.e. the 
earlier build phases) are activated.

   From looking at the code, there are a number of places where the list 
of targets is reiterated in order to figure out whether to compute 
dependencies, which depends options to look at, etc. It seems to me that 
this change would actually end up simplifying the code noticeably and 
remove a number of these anti-modular lists of targets in the code, 
easing any potential addition of future targets.

  Of course, for backwards compatibility, depends_lib, depends_build, 
and depends_run would remain as (deprecated) aliases of 
configure.depends, build.depends, and destroot.depends. (How do I 
implement that aliasing? I'm not experienced with Tcl.)

  What do people think? I'm happy to write and submit a patch to make 
this change if the new functionality stands a high likelihood of being 
accepted.  From reading the code, and writing the patch for  a -y "dry 
run" option (submitted to ticket #11892, which may be of independent 
interest), I do not think that it will be that hard.

       Thanks for your thoughts,
         Glen

From ryandesign at macports.org  Fri May  4 19:48:25 2007
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue Oct  9 16:40:16 2007
Subject: [24808] trunk/dports/gnome/libgtop/Portfile
In-Reply-To: <20070505004821.A1CF75E247F@cvs.opensource.apple.com>
References: <20070505004821.A1CF75E247F@cvs.opensource.apple.com>
Message-ID: <A0342E4C-273C-4542-8C4E-A33D84DE0EE4@macports.org>

On May 4, 2007, at 19:48, source_changes@macosforge.org wrote:

> Revision: 24808
>           http://trac.macosforge.org/projects/macports/changeset/24808
> Author:   rhwood@macports.org
> Date:     2007-05-04 17:48:21 -0700 (Fri, 04 May 2007)
>
> Log Message:
> -----------
> Clean configuration settings per ticket:11664
>
> Modified Paths:
> --------------
>     trunk/dports/gnome/libgtop/Portfile
>
> Modified: trunk/dports/gnome/libgtop/Portfile
> ===================================================================
> --- trunk/dports/gnome/libgtop/Portfile	2007-05-05 00:46:49 UTC  
> (rev 24807)
> +++ trunk/dports/gnome/libgtop/Portfile	2007-05-05 00:48:21 UTC  
> (rev 24808)
> @@ -18,5 +18,4 @@
>  use_bzip2 	yes
>  configure.args	--mandir=${prefix}/share/man --infodir=${prefix}/ 
> share/info \
>  		--disable-static
> -configure.env   CPPFLAGS="-L${prefix}/lib -I${prefix}/include" \
> -		CFLAGS="-no-cpp-precomp -lintl"
> +configure.cflags-append	-lintl

Randall, I see you making these changes to many ports. Your log  
message only refers to ticket #11664 but you're also removing -no-cpp- 
precomp which isn't mentioned in that ticket. What's -no-cpp-precomp  
for, why was it in all those ports before, and why is it ok to remove  
it now? Thanks.



From vincent at AI.SRI.COM  Fri May  4 21:27:26 2007
From: vincent at AI.SRI.COM (Regis Vincent)
Date: Tue Oct  9 16:40:16 2007
Subject: Update for Player 2.0.4 
Message-ID: <790D8315-3B35-40C5-A615-0DE2264FBB12@ai.sri.com>

hi,

Player 2.0.4 has been released yesterday I have submit a path to the  
Portfile to keep it up to date, can you someone commit it, please !

thanks.

Ticket 11906: http://trac.macports.org/projects/macports/ticket/11906
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2622 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070504/5e2b7194/smime.bin
From boeyms at macports.org  Fri May  4 23:47:02 2007
From: boeyms at macports.org (Boey Maun Suang)
Date: Tue Oct  9 16:40:16 2007
Subject: Maintainer but not committer with update: Submitted a Trac
	ticket, now I just wait?
In-Reply-To: <F9C8A6C7-604D-4CB7-96CC-72FA4462CE0F@gmail.com>
References: <f1fn7v$3mk$1@sea.gmane.org>
	<70918D6F-EF18-489A-BC6F-8E86EB6EAD0A@gmail.com>
	<F9C8A6C7-604D-4CB7-96CC-72FA4462CE0F@gmail.com>
Message-ID: <BB3147CA-B5C8-4D23-84B1-1EFEA5A05AE9@macports.org>

Hi there,

>> I am the maintainer of 'lang/slime' for which I have submitted a  
>> ticket to Trac [1], attaching it to the Milestone "Port Updates".
>>
>> Now I just wait for a committer to notice this, or should I bring  
>> it to some email address's attention?  The Wiki has the start [2]  
>> of guide to these questions, but no answers, for which it would be  
>> good to fill in even provisional answers to the procedure.
>
> ive been wondering the same thing ... sometimes they snatched up  
> right away, others might sit indefinitely, as these two appear to  
> have been doing for the last month:

The problem is that, at the moment, Trac does not automatically send  
a notification email to the assignee of a ticket, so you need to put  
the assignee's email address into the Cc: field.  I don't know  
whether or not anyone is trying to fix this problem, but it is  
documented [1].  I agree, however that it should at least be linked  
to from [2]; I'll try to do that in the next day or so.  There is  
also a macports-tickets@ mailing list that ostensibly has mail posted  
to it by Trac whenever a ticket is opened, but I've never received  
anything from it; does anyone know why this feature isn't working  
either?

On 05/05/2007, at 04:03, Matt Meissner wrote:

> Back in the day, there was a committer or two assigned to each port  
> category.  Submitters were instructed to change the owner of a bug  
> to the category committer.
>
> Portmgr, is that policy still in effect?  If so, where is the up-to- 
> date list of category owners?

The policy in [1] suggests to me that the current policy is just to  
assign bugs to macports-dev@ when there is no other obvious  
assignee.  I'm not aware of the old policy that you describe (I've  
been a user since DarwinPorts ran on 10.2, but I've only been  
contributing for a few months now), so my guess is that it has lapsed  
due to churn of contributors or similar.  I certainly think that the  
old policy has merit, but it seems to me that MacPorts needs a little  
more organisational structure among its current contributors before  
we can return to it.

Kind regards,


Maun Suang

[1] http://trac.macosforge.org/projects/macports/wiki/TracTicketing
[2] http://trac.macosforge.org/projects/macports/wiki/MaintainingAPort

-- 
Boey Maun Suang (Boey is my surname)
Email: boeyms@macports.org




From rhwood at mac.com  Sat May  5 17:53:39 2007
From: rhwood at mac.com (Randall Wood)
Date: Tue Oct  9 16:40:16 2007
Subject: [24832] trunk/base/src/port/port.tcl
In-Reply-To: <20070506004151.EBEEA5E34DE@cvs.opensource.apple.com>
References: <20070506004151.EBEEA5E34DE@cvs.opensource.apple.com>
Message-ID: <4D729591-9547-48B9-9920-D0ED5836EBF2@mac.com>


On 5 May 2007, at 20:41, source_changes@macosforge.org wrote:

> Revision 24832 Author jberry@macports.org Date 2007-05-05 17:41:51  
> -0700 (Sat, 05 May 2007) Log MessageStore readline history in  
> ~/.macports/.history instead of ~/.port_history

Why ~/.macports/.history and not ~/.macports/history (why a .file in  
a .dir)?

And while I'm asking why not use ~/Library/Application Support/ 
Macports instead of ~/.macports? Isn't it the Apple way to use the  
Library instead of .dirs?

> Modified Paths
> trunk/base/src/port/port.tcl
> Diff
> Modified: trunk/base/src/port/port.tcl (24831 => 24832) --- trunk/ 
> base/src/port/port.tcl	2007-05-06 00:35:02 UTC (rev 24831) +++  
> trunk/base/src/port/port.tcl	2007-05-06 00:41:51 UTC (rev 24832) @@  
> -2434,13 +2434,14 @@ proc process_command_file { in } { global  
> current_portdir +	global darwinports::autoconf::macports_user_dir #  
> Initialize readline set isstdin [string match $in "stdin"] set name  
> "port" set use_readline [expr $isstdin && [readline init $name]] -	 
> set history_file [file normalize "~/.${name}_history"] -	 +	set  
> history_file [file normalize "${macports_user_dir}/.history"] + #  
> Read readline history if {$use_readline} { rl_history read  
> $history_file
> _______________________________________________
> macports-changes mailing list
> macports-changes@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-changes



Randall Wood
rhwood@mac.com
http://shyramblings.blogspot.com

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



From jberry at macports.org  Sat May  5 19:04:09 2007
From: jberry at macports.org (James Berry)
Date: Tue Oct  9 16:40:16 2007
Subject: [24832] trunk/base/src/port/port.tcl
In-Reply-To: <4D729591-9547-48B9-9920-D0ED5836EBF2@mac.com>
References: <20070506004151.EBEEA5E34DE@cvs.opensource.apple.com>
	<4D729591-9547-48B9-9920-D0ED5836EBF2@mac.com>
Message-ID: <F3EC0D0F-6E7B-4346-8CDB-6894CE7267E2@macports.org>

Hi Randall,

On May 5, 2007, at 5:53 PM, Randall Wood wrote:

>
> On 5 May 2007, at 20:41, source_changes@macosforge.org wrote:
>
>> Revision 24832 Author jberry@macports.org Date 2007-05-05 17:41:51  
>> -0700 (Sat, 05 May 2007) Log MessageStore readline history in  
>> ~/.macports/.history instead of ~/.port_history
>
> Why ~/.macports/.history and not ~/.macports/history (why a .file  
> in a .dir)?

Well, my reasoning may have been a bit lame, but it seemed like since  
it's not normally a file anybody wants to read (while there are other  
files in ~/.macports that they do) that it was just as well to keep  
it hidden and out of the way.

> And while I'm asking why not use ~/Library/Application Support/ 
> Macports instead of ~/.macports? Isn't it the Apple way to use the  
> Library instead of .dirs?

Very good question. I'd be happy to hear feedback from other  
developers. I'd happy with either.

>> Modified Paths
>> trunk/base/src/port/port.tcl
>> Diff
>> Modified: trunk/base/src/port/port.tcl (24831 => 24832) --- trunk/ 
>> base/src/port/port.tcl	2007-05-06 00:35:02 UTC (rev 24831) +++  
>> trunk/base/src/port/port.tcl	2007-05-06 00:41:51 UTC (rev 24832)  
>> @@ -2434,13 +2434,14 @@ proc process_command_file { in } { global  
>> current_portdir +	global darwinports::autoconf::macports_user_dir  
>> # Initialize readline set isstdin [string match $in "stdin"] set  
>> name "port" set use_readline [expr $isstdin && [readline init  
>> $name]] -	set history_file [file normalize "~/.${name}_history"]  
>> -	 +	set history_file [file normalize "$ 
>> {macports_user_dir}/.history"] + # Read readline history if  
>> {$use_readline} { rl_history read $history_file
>> _______________________________________________
>> macports-changes mailing list
>> macports-changes@lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo/macports-changes
>
>
>
> Randall Wood
> rhwood@mac.com
> http://shyramblings.blogspot.com
>
> "The rules are simple: The ball is round. The game lasts 90  
> minutes. All the
> rest is just philosophy."
>
>


From chpickel at stwing.upenn.edu  Sat May  5 19:31:08 2007
From: chpickel at stwing.upenn.edu (Chris Pickel)
Date: Tue Oct  9 16:40:16 2007
Subject: [24832] trunk/base/src/port/port.tcl
In-Reply-To: <F3EC0D0F-6E7B-4346-8CDB-6894CE7267E2@macports.org>
References: <20070506004151.EBEEA5E34DE@cvs.opensource.apple.com>
	<4D729591-9547-48B9-9920-D0ED5836EBF2@mac.com>
	<F3EC0D0F-6E7B-4346-8CDB-6894CE7267E2@macports.org>
Message-ID: <D6A62A8B-14DD-4598-AE54-BF85DF69C55E@stwing.upenn.edu>

On 05 May, 2007, at 22:04, James Berry wrote:
> On May 5, 2007, at 5:53 PM, Randall Wood wrote:
>> Why ~/.macports/.history and not ~/.macports/history (why a .file  
>> in a .dir)?
>
> Well, my reasoning may have been a bit lame, but it seemed like  
> since it's not normally a file anybody wants to read (while there  
> are other files in ~/.macports that they do) that it was just as  
> well to keep it hidden and out of the way.

I'd just as soon have it visible. On the off chance I _did_ want to  
look at it, I'd never have thought to look for a dot-file there.

>> And while I'm asking why not use ~/Library/Application Support/ 
>> Macports instead of ~/.macports? Isn't it the Apple way to use the  
>> Library instead of .dirs?
>
> Very good question. I'd be happy to hear feedback from other  
> developers. I'd happy with either.

I would say that, in an ideal world, MacPorts configuration would go  
in Application Support instead of a dot-file. However, almost  
everything that MacPorts installs has its configuration in dot-files.  
It would be inconsistent to put MacPorts configuration in a different  
place from all of these.

So, unless someone wants to patch all of the ports to use Application  
Support too, I think ~/.macports/ is better


Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070505/bcc6d345/PGP.bin
From boeyms at macports.org  Sun May  6 02:13:01 2007
From: boeyms at macports.org (Boey Maun Suang)
Date: Tue Oct  9 16:40:16 2007
Subject: [24832] trunk/base/src/port/port.tcl
In-Reply-To: <D6A62A8B-14DD-4598-AE54-BF85DF69C55E@stwing.upenn.edu>
References: <20070506004151.EBEEA5E34DE@cvs.opensource.apple.com>
	<4D729591-9547-48B9-9920-D0ED5836EBF2@mac.com>
	<F3EC0D0F-6E7B-4346-8CDB-6894CE7267E2@macports.org>
	<D6A62A8B-14DD-4598-AE54-BF85DF69C55E@stwing.upenn.edu>
Message-ID: <9AD4A49D-BCFA-4FB8-A3C5-6DD8740242DE@macports.org>


>>> Why ~/.macports/.history and not ~/.macports/history (why a .file  
>>> in a .dir)?
>>>
>>
>> Well, my reasoning may have been a bit lame, but it seemed like  
>> since it's not normally a file anybody wants to read (while there  
>> are other files in ~/.macports that they do) that it was just as  
>> well to keep it hidden and out of the way.
>
> I'd just as soon have it visible. On the off chance I _did_ want to  
> look at it, I'd never have thought to look for a dot-file there.

+1 from me on the latter view; furthermore, every other program that  
I've run that made a ~/.blah directory (elinks, mplayer, gnupg,  
subversion, tor, ssh, wireshark, etc., etc.) creates all its files in  
~/.blah without a leading dot.

>>> And while I'm asking why not use ~/Library/Application Support/ 
>>> Macports instead of ~/.macports? Isn't it the Apple way to use  
>>> the Library instead of .dirs?
>>
>> Very good question. I'd be happy to hear feedback from other  
>> developers. I'd happy with either.
>
> I would say that, in an ideal world, MacPorts configuration would  
> go in Application Support instead of a dot-file. However, almost  
> everything that MacPorts installs has its configuration in dot- 
> files. It would be inconsistent to put MacPorts configuration in a  
> different place from all of these.

To me, Library/Application Support is the place where Cocoa apps put  
things, while Unixish apps, especially command-line ones, use dot- 
files and dot-directories, so I'd stick with ~/.macports.

Kind regards,


Maun Suang

-- 
Boey Maun Suang (Boey is my surname)
Email: boeyms@macports.org




From jfrederich at gmail.com  Sun May  6 08:33:52 2007
From: jfrederich at gmail.com (Jens Frederich)
Date: Tue Oct  9 16:40:16 2007
Subject: New Port (cgdb)
Message-ID: <C263C200.34%jfrederich@gmail.com>

Hi all,

I?m new here. I would add a new port for the ncurses based debugger frondend
cgdb.
What must I do, for accepting the port?

    Jens

Port File:
# $Id$

PortSystem 1.0

name            cgdb
version         0.6.4
categories      devel
platforms       darwin
maintainers     jfrederich@gmail.com
description     A curses-based interface to the GNU Debugger (GDB).
long_description \
  CGDB is a curses-based interface to the GNU Debugger (GDB). \
  The goal of CGDB is to be lightweight and responsive; not   \
  encumbered with unnecessary features.                       \

homepage        http://cgdb.sourceforge.net
master_sites    sourceforge
checksums       md5  bddcaaee7b20ab2c17f1f4e197db74c0 \
                sha1 5f1246d151dc419aa08890291175b4b2094e62c9

depends_lib     port:ncurses port:readline

configure.type  gnu
configure.args  --infodir=${prefix}/share/info \
                --mandir=${prefix}/share/man   \





From boeyms at macports.org  Sun May  6 22:08:23 2007
From: boeyms at macports.org (Boey Maun Suang)
Date: Tue Oct  9 16:40:16 2007
Subject: New Port (cgdb)
In-Reply-To: <C263C200.34%jfrederich@gmail.com>
References: <C263C200.34%jfrederich@gmail.com>
Message-ID: <D469CD05-CAAF-499E-9EB4-BA7B64A8D42C@macports.org>

Hi Jens,

> I?m new here. I would add a new port for the ncurses based debugger  
> frondend
> cgdb.
> What must I do, for accepting the port?

As described in [1] and [2], set up an account on MacPorts and file a  
ticket for the port to be added with you as maintainer.  Usually you  
would assign the ticket to macports-dev@, but in this case you can  
assign it to me if you like.  Don't forget to put both your and the  
assignee's email addresses in the Cc: field so that both receive  
notification about the ticket.  If you have any further questions,  
just drop us a line.

Thanks for the new port!

Kind regards,


Maun Suang

[1] http://trac.macosforge.org/projects/macports/wiki/TracTicketing
[2] http://trac.macosforge.org/projects/macports/wiki/MaintainingAPort

-- 
Boey Maun Suang (Boey is my surname)
Email: boeyms@macports.org




From t.lucas at toolmantim.com  Mon May  7 00:44:11 2007
From: t.lucas at toolmantim.com (Tim Lucas)
Date: Tue Oct  9 16:40:16 2007
Subject: New port for ruby-dbi with odbc support
In-Reply-To: <B656B14C-ABF6-4A05-816C-AE13348EC61B@macports.org>
References: <E003B23F-4D76-4ED9-B858-95FF0194187C@toolmantim.com>
	<B656B14C-ABF6-4A05-816C-AE13348EC61B@macports.org>
Message-ID: <5F9A0E4F-4E75-4F76-B319-8606ED53C308@toolmantim.com>

Thanks Boey,

On 04/05/2007, at 6:11 PM, Boey Maun Suang wrote:

>> There's two port files, rb-dbd-pg and db-dbd-mysql that currently  
>> just extend rb-dbi with a few configure args. They should probably  
>> use variants, but I digress. I've created another Portfile, in the  
>> spirit of these two, so you can install ruby-dbi with odbc support  
>> via macports, just like you can with mysql or postgres. It's a  
>> dead-simple Portfile.
>>
>> How can I get this added to the ports tree?
>
> The most transparent way is to submit a ticket for the new port in  
> the requested format [1]; don't forget to enter the addresses in  
> the Cc field as described.  A committer will then check it and  
> commit it if they're happy with it.  As for rb-dbd-pg and rb-dbd- 
> mysql, it'd be great if you could file a ticket about those too so  
> that the maintainer(s) know about your suggestion.

Done: http://trac.macports.org/projects/macports/ticket/11913
and done: http://trac.macports.org/projects/macports/ticket/11914

-- tim


From gwhitney at pobox.com  Mon May  7 08:57:39 2007
From: gwhitney at pobox.com (Glen Whitney)
Date: Tue Oct  9 16:40:16 2007
Subject: --pretend & --fetch-all options
References: D07F228F-E6FF-40E3-9B7B-6DB9EF824412@gmx.net
Message-ID: <463F4C73.30104@pobox.com>

Quoting from macports-users 20 Feb 2007:
>> That said, it still remains second to the first idea
>> of mel who started this thread, to implement a dry
>> run feature. Maybe, dry run would just be half of
>> the implementation of prefetch.
> 
> Due to the reason above, I'd prefer the the dry run feature
> to be implemented first, because I think in the long run
> it will help to improve port's variants feature.

I have submitted a patch (dry.3.patch attached to 
http://trac.macports.org/projects/macports/ticket/11892)
against the current svn version (r24893) which adds a -y option
for dry run. (I chose -y since it's the only letter left from "dry" 
which was not already an option.) It turns out to be a pretty simple 
patch, only touching one tcl source file except for documentation and 
parsing the switch. I now use it all the time for checking out recursive 
dependencies and the behavior of different variants.  Perhaps it will 
catch the eye of someone who can incorporate it into the development 
version of MacPorts.

Hope this is helpful,
      Glen Whitney

From dluke at geeklair.net  Mon May  7 12:22:47 2007
From: dluke at geeklair.net (Daniel J. Luke)
Date: Tue Oct  9 16:40:16 2007
Subject: Maintainer but not committer with update: Submitted a Trac
	ticket, now I just wait?
In-Reply-To: <BB3147CA-B5C8-4D23-84B1-1EFEA5A05AE9@macports.org>
References: <f1fn7v$3mk$1@sea.gmane.org>
	<70918D6F-EF18-489A-BC6F-8E86EB6EAD0A@gmail.com>
	<F9C8A6C7-604D-4CB7-96CC-72FA4462CE0F@gmail.com>
	<BB3147CA-B5C8-4D23-84B1-1EFEA5A05AE9@macports.org>
Message-ID: <FB686FA4-C70D-4726-B94F-05165C63510C@geeklair.net>

On May 5, 2007, at 2:47 AM, Boey Maun Suang wrote:
> The problem is that, at the moment, Trac does not automatically  
> send a notification email to the assignee of a ticket, so you need  
> to put the assignee's email address into the Cc: field.  I don't  
> know whether or not anyone is trying to fix this problem, but it is  
> documented [1].

It's likely that the fix is to add always_notify_owner = true to the  
[notification] section of the trac.ini file.

There may be some other reason why this isn't set, though.

> I agree, however that it should at least be linked to from [2];  
> I'll try to do that in the next day or so.  There is also a  
> macports-tickets@ mailing list that ostensibly has mail posted to  
> it by Trac whenever a ticket is opened, but I've never received  
> anything from it; does anyone know why this feature isn't working  
> either?

I think I briefly saw tickets being sent to the list, but I haven't  
seen them in a while. That would correspond to either the  
smtp_alwyas_bcc or smtp_always_cc settings.

Again, I don't know why it's not currently enabled.

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070507/94466a10/PGP.bin
From olaf at foellinger.de  Mon May  7 13:19:56 2007
From: olaf at foellinger.de (Olaf Foellinger)
Date: Tue Oct  9 16:40:16 2007
Subject: Ticket 7050 can be closed
Message-ID: <20070507201956.GA28993@foellinger.de>

Hi,

I've checked the ticket
http://trac.macports.org/projects/macports/ticket/7050 and it can be
closed now(see my comment in the ticket).

Gruss Olaf

From ryandesign at macports.org  Mon May  7 21:14:41 2007
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue Oct  9 16:40:16 2007
Subject: [24905] trunk/base/ChangeLog
In-Reply-To: <20070508033327.305B05E6877@cvs.opensource.apple.com>
References: <20070508033327.305B05E6877@cvs.opensource.apple.com>
Message-ID: <C82302B8-B5EF-4EDB-A84A-320299D44CFF@macports.org>

On May 7, 2007, at 22:33, source_changes@macosforge.org wrote:

> Revision: 24905
>           http://trac.macosforge.org/projects/macports/changeset/24905
> Author:   jberry@macports.org
> Date:     2007-05-07 20:33:26 -0700 (Mon, 07 May 2007)
>
> Log Message:
> -----------
> Update ChangeLog in preparation for release 1.4.40.
>
> Modified Paths:
> --------------
>     trunk/base/ChangeLog
>
> Modified: trunk/base/ChangeLog
> ===================================================================
> --- trunk/base/ChangeLog	2007-05-08 03:28:22 UTC (rev 24904)
> +++ trunk/base/ChangeLog	2007-05-08 03:33:26 UTC (rev 24905)
> @@ -6,6 +6,13 @@
>
>  (unreleased):
>
> +Release 1.4.40 (7-May-2007):
> +
> +    - Note the bump in version naming. To leave ourselves lots of  
> room in our versioning
> +      scheme, we've jumped from 1.4.3 to 1.4.40. The floating  
> point represenation as
> +      reported by port version (1.440) will still be the same;  
> we're just interpreting
> +      it differently.
> +
>      - variable tracing now works in a much better way and handles  
> unsets properly.
>        Similarly, ${option}-delete now works better. Depends  
> validation no longer
>        attempts to validate when the variable is unset.  
> Additionally, the validation

Out of curiosity, why are we using these weird version numbers?

The standard in the unix software world (which is the world of  
software that MacPorts installs so it's not unreasonable to make the  
comparison) would be that you have 1.4.0, 1.4.1, 1.4.2 etc up to  
1.4.9, then 1.4.10, 1.4.11, etc. Simply count up the last number,  
until it's time to increment the middle number and reset the last  
number back to zero.

But this change log entry seems to describe a rather different  
version strategy for MacPorts. In particular, it seems to mean that  
the version after 1.4.9 must be 1.5.0; that there is no room for a  
1.4.10 or any larger version (unless you say that "1.491" corresponds  
to 1.4.10, "1.492" to 1.4.11, etc., which would be a mess). Is there  
a reason why we are intentionally limiting ourselves with this  
numbering scheme? Is this a reason for wanting to do fewer releases  
-- so that we don't have to prematurely come to version 1.5.0 which  
might then not be substantially different from 1.4.9?



From jberry at macports.org  Mon May  7 21:59:02 2007
From: jberry at macports.org (James Berry)
Date: Tue Oct  9 16:40:16 2007
Subject: MacPorts v1.4.40 released for self update
Message-ID: <272BA956-50F4-4F4F-A3C4-6AA3D1885AA9@macports.org>

Here's the change log:

James

Release 1.4.40 (7-May-2007, tagged at r24909 by jberry):

     - Note the bump in version naming. To leave ourselves lots of  
room in our versioning
       scheme, we've jumped from 1.4.3 to 1.4.40. The floating point  
represenation as
       reported by port version (1.440) will still be the same; we're  
just interpreting
       it differently.

     - variable tracing now works in a much better way and handles  
unsets properly.
       Similarly, ${option}-delete now works better. Depends  
validation no longer
       attempts to validate when the variable is unset. Additionally,  
the validation
       now actually validates each depspec instead of simply finding  
a single spec
       within the list that works (ticket #11868, eridius r24678).

     - macports infrastructure now easier to use from scripts.
       ui_prefix and ui_channels have default implementations, and
       all arguments to dportinit are now optional (ticket #11837,  
eridius r24460).

     - ln now accepts combined flags (ex. ln -sf foo bar) (eridius  
r24452)

     - default_variants now handles multiple values correctly (ticket  
#11828, eridius r24450).

     - ln uses new symlink command so it can create symlinks that  
point to
       files that don't actually exist (eridius r24444).

     - New bare-bones Pextlib command `symlink source target` (ticket  
#11840, eridius r24444).

     - delete reimplemented using fs-traverse (eridius r24435).

     - fs-traverse now uses the fts(3) family of functions instead of  
readdir/opendir.
       This fixes a couple behavioral oddities, and makes deleting  
during traversal work on 10.3
       (ticket #11839, eridius r24423).

     - fs-traverse now takes a list of targets rather than a variable  
number of arguments
       (ticket #11836, eridius r24410).

     - Fixed a potential crasher in fs-traverse when showing error  
message
       (ticket #11827, eridius r24396, thanks sfiera).

     - Fixed a bug where livecheck failed on ports that do not define  
a homepage
       (ticket #11818, pguyot r24319).

     - Added the downloads section of our repo to the macports  
mirrors list (jmpp r24278).

     - Fixed a bug with the archive mode introduced with r23238  
change (1.4.1)
       (pguyot r24273).

     - Trace mode now take dependencies into account when executing  
the activate
       phase. This fixes an unwanted warning when activating ports  
that depend
       on teTeX (pguyot r24199).

     - Support for mpwa submit through "port submit".
       This work is in progress. (jberry)
        - Expose autoconf XAR variable as  
portutil::autoconf::xar_path. (r24194).
        - Start to build portpkg.xar and meta data, hijacking Kevin's
          portsubmit.tcl. (r24195-24196).

     - Revise error messages in port image activation to use syntax that
       matches port(1). (jberry r24543, r24548).

     - Create new interp variable prefix_frozen, which is available  
to port phases
       even when the Portfile redefines prefix. (jberry r24848-r24849)

     - Search for prefix-relative commands in prefix_frozen rather  
than prefix.
       Affects port submit (xar) and port fetch (svn). (jberry r24849)

     - Always create a ~/.macports user directory if it doesn't yet  
exist. (jberry r24831)

     - Move port(1) readline history file to ~/.macports/history  
(jberry r24832, r24843)



From jberry at macports.org  Mon May  7 22:25:42 2007
From: jberry at macports.org (James Berry)
Date: Tue Oct  9 16:40:16 2007
Subject: [24905] trunk/base/ChangeLog
In-Reply-To: <C82302B8-B5EF-4EDB-A84A-320299D44CFF@macports.org>
References: <20070508033327.305B05E6877@cvs.opensource.apple.com>
	<C82302B8-B5EF-4EDB-A84A-320299D44CFF@macports.org>
Message-ID: <56F2135A-E938-4D63-BC17-09EB52B6450F@macports.org>

Hi Ryan,

On May 7, 2007, at 9:14 PM, Ryan Schmidt wrote:

> On May 7, 2007, at 22:33, source_changes@macosforge.org wrote:
>> +Release 1.4.40 (7-May-2007):
>> +
>> +    - Note the bump in version naming. To leave ourselves lots of  
>> room in our versioning
>> +      scheme, we've jumped from 1.4.3 to 1.4.40. The floating  
>> point represenation as
>> +      reported by port version (1.440) will still be the same;  
>> we're just interpreting
>> +      it differently.
>> +
>>      - variable tracing now works in a much better way and handles  
>> unsets properly.
>>        Similarly, ${option}-delete now works better. Depends  
>> validation no longer
>>        attempts to validate when the variable is unset.  
>> Additionally, the validation
>
> Out of curiosity, why are we using these weird version numbers?
>
> The standard in the unix software world (which is the world of  
> software that MacPorts installs so it's not unreasonable to make  
> the comparison) would be that you have 1.4.0, 1.4.1, 1.4.2 etc up  
> to 1.4.9, then 1.4.10, 1.4.11, etc. Simply count up the last  
> number, until it's time to increment the middle number and reset  
> the last number back to zero.
>
> But this change log entry seems to describe a rather different  
> version strategy for MacPorts. In particular, it seems to mean that  
> the version after 1.4.9 must be 1.5.0; that there is no room for a  
> 1.4.10 or any larger version (unless you say that "1.491"  
> corresponds to 1.4.10, "1.492" to 1.4.11, etc., which would be a  
> mess). Is there a reason why we are intentionally limiting  
> ourselves with this numbering scheme? Is this a reason for wanting  
> to do fewer releases -- so that we don't have to prematurely come  
> to version 1.5.0 which might then not be substantially different  
> from 1.4.9?

Actually, the change mentioned above was to give ourselves lots more  
version numbers so that we _don't_ run out of numbers. The problem is  
that our versioning is governed by a single floating point number,  
which needs to increase from one release to the next, and which maps  
to our human readable number. So 1.4.3 is 1.430000... If we had  
continued on our path, we would soon have got to 1.4.9 = 1.49 and  
we'd be at the end of our 1.4 release.

So our new scheme essentially allocates another digit, so now we can  
go 1.4.40, 1.4.41, 1.4.42, ... 1.4.51 ... 1.4.68, ... 1.4.79 etc.  
It's not ideal, but the floating point form isn't ideal either; at  
some point we'll want to change that.

James

From blair at orcaware.com  Mon May  7 23:10:54 2007
From: blair at orcaware.com (Blair Zajac)
Date: Tue Oct  9 16:40:16 2007
Subject: MacPorts v1.4.40 released for self update
In-Reply-To: <272BA956-50F4-4F4F-A3C4-6AA3D1885AA9@macports.org>
References: <272BA956-50F4-4F4F-A3C4-6AA3D1885AA9@macports.org>
Message-ID: <151634FA-63AA-410A-81C8-D59D3126278D@orcaware.com>


On May 7, 2007, at 9:59 PM, James Berry wrote:

> Here's the change log:
>
> James
>
> Release 1.4.40 (7-May-2007, tagged at r24909 by jberry):
>

James,

Thanks for pushing this release out.

Did the changes to bz2 make it in in the unarchive?  I didn't see the  
revisions in this list.

Also, I tried to figure out on branches/release_1_4 what's been  
merged in and there's no information in the log message on what  
revisions were merged from trunk.  The one place that svn isn't great  
is in merge tracking support; without an explicit log message or  
other tool to keep track of what's been merged, there's no way to  
tell what's been merged.  So I request we do the following:

1) Document the revisions merged into the branch in the log message.
2) Switch to using svnmerge.py for the next branch 1.5.  This will  
allow us to see what revisions have been merged.

Regards,
Blair

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



From jkh at brierdr.com  Tue May  8 00:46:38 2007
From: jkh at brierdr.com (Jordan K. Hubbard)
Date: Tue Oct  9 16:40:16 2007
Subject: New "file delete" implementation breaks ncurses
In-Reply-To: <E3968521-D9CA-4E49-8C61-FBAB22A7344B@macports.org>
References: <00A8B080-2CA9-4CDA-8864-0E9D5AA54F14@gmail.com>
	<E3968521-D9CA-4E49-8C61-FBAB22A7344B@macports.org>
Message-ID: <6455FCFB-2FCD-4B3F-B25B-F3D114CBA408@brierdr.com>

Why can't we get the work-around committed for now?  A lot of things  
depend on ncurses, and it's a fallacy to assume that a lot of people  
don't track trunk and it can be safely broken for periods of time. :-(

- Jordan

On May 3, 2007, at 3:06 PM, Kevin Ballard wrote:

> Oh hrm, it didn't occur to me that this would happen, but I know  
> exactly why.
>
> However, I'm on vacation. Can this wait a week? It's a problem that  
> only affects trunk.
>
> On May 3, 2007, at 5:40 AM, Guido Soranzio wrote:
>
>> After the changes to the "file delete" implementation, the  
>> installation of
>> ncurses fails because it tries to follow the target of a symbolic  
>> link.
>>
>>
>> By reversing the order of the arguments from
>>
>> delete ${destroot}${prefix}/share ${destroot}${prefix}/lib/terminfo
>>
>> into
>>
>> delete ${destroot}${prefix}/lib/terminfo ${destroot}${prefix}/share
>>
>> ncurses installs correctly (lib/terminfo is a symbolic link to ../ 
>> share/terminfo).
>
> -- 
> Kevin Ballard
> http://kevin.sb.org
> eridius@macports.org
> http://www.tildesoft.com
>
>
> _______________________________________________
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070508/46fca8b1/attachment.html
From ryandesign at macports.org  Tue May  8 01:01:35 2007
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue Oct  9 16:40:16 2007
Subject: New "file delete" implementation breaks ncurses
In-Reply-To: <6455FCFB-2FCD-4B3F-B25B-F3D114CBA408@brierdr.com>
References: <00A8B080-2CA9-4CDA-8864-0E9D5AA54F14@gmail.com>
	<E3968521-D9CA-4E49-8C61-FBAB22A7344B@macports.org>
	<6455FCFB-2FCD-4B3F-B25B-F3D114CBA408@brierdr.com>
Message-ID: <DB8AF8C0-8C1E-4F8D-8CF8-F86B81E738EF@macports.org>

MacPorts 1.4.40 was released, so I hope the fix made it into that...

On May 8, 2007, at 02:46, Jordan K. Hubbard wrote:

> Why can't we get the work-around committed for now?  A lot of  
> things depend on ncurses, and it's a fallacy to assume that a lot  
> of people don't track trunk and it can be safely broken for periods  
> of time. :-(
>
> On May 3, 2007, at 3:06 PM, Kevin Ballard wrote:
>
>> Oh hrm, it didn't occur to me that this would happen, but I know  
>> exactly why.
>>
>> However, I'm on vacation. Can this wait a week? It's a problem  
>> that only affects trunk.
>>
>> On May 3, 2007, at 5:40 AM, Guido Soranzio wrote:
>>
>>> After the changes to the "file delete" implementation, the  
>>> installation of
>>> ncurses fails because it tries to follow the target of a symbolic  
>>> link.
>>>
>>>
>>> By reversing the order of the arguments from
>>>
>>> delete ${destroot}${prefix}/share ${destroot}${prefix}/lib/terminfo
>>>
>>> into
>>>
>>> delete ${destroot}${prefix}/lib/terminfo ${destroot}${prefix}/share
>>>
>>> ncurses installs correctly (lib/terminfo is a symbolic link to ../ 
>>> share/terminfo).
>>
>>


From jkh at brierdr.com  Tue May  8 01:04:12 2007
From: jkh at brierdr.com (Jordan K. Hubbard)
Date: Tue Oct  9 16:40:16 2007
Subject: New "file delete" implementation breaks ncurses
In-Reply-To: <DB8AF8C0-8C1E-4F8D-8CF8-F86B81E738EF@macports.org>
References: <00A8B080-2CA9-4CDA-8864-0E9D5AA54F14@gmail.com>
	<E3968521-D9CA-4E49-8C61-FBAB22A7344B@macports.org>
	<6455FCFB-2FCD-4B3F-B25B-F3D114CBA408@brierdr.com>
	<DB8AF8C0-8C1E-4F8D-8CF8-F86B81E738EF@macports.org>
Message-ID: <126ED9CD-2537-404F-B190-F78E2F8B5D07@brierdr.com>

AFAIK, the fix hasn't even been committed to trunk yet...

- Jordan

On May 8, 2007, at 1:01 AM, Ryan Schmidt wrote:

> MacPorts 1.4.40 was released, so I hope the fix made it into that...
>
> On May 8, 2007, at 02:46, Jordan K. Hubbard wrote:
>
>> Why can't we get the work-around committed for now?  A lot of  
>> things depend on ncurses, and it's a fallacy to assume that a lot  
>> of people don't track trunk and it can be safely broken for  
>> periods of time. :-(
>>
>> On May 3, 2007, at 3:06 PM, Kevin Ballard wrote:
>>
>>> Oh hrm, it didn't occur to me that this would happen, but I know  
>>> exactly why.
>>>
>>> However, I'm on vacation. Can this wait a week? It's a problem  
>>> that only affects trunk.
>>>
>>> On May 3, 2007, at 5:40 AM, Guido Soranzio wrote:
>>>
>>>> After the changes to the "file delete" implementation, the  
>>>> installation of
>>>> ncurses fails because it tries to follow the target of a  
>>>> symbolic link.
>>>>
>>>>
>>>> By reversing the order of the arguments from
>>>>
>>>> delete ${destroot}${prefix}/share ${destroot}${prefix}/lib/terminfo
>>>>
>>>> into
>>>>
>>>> delete ${destroot}${prefix}/lib/terminfo ${destroot}${prefix}/share
>>>>
>>>> ncurses installs correctly (lib/terminfo is a symbolic link  
>>>> to ../share/terminfo).
>>>
>>>
>


From pguyot at kallisys.net  Tue May  8 01:07:56 2007
From: pguyot at kallisys.net (Paul Guyot)
Date: Tue Oct  9 16:40:16 2007
Subject: New "file delete" implementation breaks ncurses
In-Reply-To: <126ED9CD-2537-404F-B190-F78E2F8B5D07@brierdr.com>
References: <00A8B080-2CA9-4CDA-8864-0E9D5AA54F14@gmail.com>
	<E3968521-D9CA-4E49-8C61-FBAB22A7344B@macports.org>
	<6455FCFB-2FCD-4B3F-B25B-F3D114CBA408@brierdr.com>
	<DB8AF8C0-8C1E-4F8D-8CF8-F86B81E738EF@macports.org>
	<126ED9CD-2537-404F-B190-F78E2F8B5D07@brierdr.com>
Message-ID: <D614EEF6-7901-4FA6-AA19-01948E11C037@kallisys.net>

So maybe it's time for 1.4.41 :D

Paul

On May 8, 2007, at 5:04 PM, Jordan K. Hubbard wrote:

> AFAIK, the fix hasn't even been committed to trunk yet...
>
> - Jordan
>
> On May 8, 2007, at 1:01 AM, Ryan Schmidt wrote:
>
>> MacPorts 1.4.40 was released, so I hope the fix made it into that...

-- 
http://paul-guyot.com/


From jberry at macports.org  Tue May  8 05:47:19 2007
From: jberry at macports.org (James Berry)
Date: Tue Oct  9 16:40:17 2007
Subject: New "file delete" implementation breaks ncurses
In-Reply-To: <126ED9CD-2537-404F-B190-F78E2F8B5D07@brierdr.com>
References: <00A8B080-2CA9-4CDA-8864-0E9D5AA54F14@gmail.com>
	<E3968521-D9CA-4E49-8C61-FBAB22A7344B@macports.org>
	<6455FCFB-2FCD-4B3F-B25B-F3D114CBA408@brierdr.com>
	<DB8AF8C0-8C1E-4F8D-8CF8-F86B81E738EF@macports.org>
	<126ED9CD-2537-404F-B190-F78E2F8B5D07@brierdr.com>
Message-ID: <62808822-9E43-436F-8A5B-046F9C61892A@macports.org>

If I understand Guido's suggestion, the workaround is to the  
Portfile, not to trunk, right? Who wants to fix it?

James

On May 8, 2007, at 1:04 AM, Jordan K. Hubbard wrote:

> AFAIK, the fix hasn't even been committed to trunk yet...
>
> - Jordan
>
> On May 8, 2007, at 1:01 AM, Ryan Schmidt wrote:
>
>> MacPorts 1.4.40 was released, so I hope the fix made it into that...
>>
>> On May 8, 2007, at 02:46, Jordan K. Hubbard wrote:
>>
>>> Why can't we get the work-around committed for now?  A lot of  
>>> things depend on ncurses, and it's a fallacy to assume that a lot  
>>> of people don't track trunk and it can be safely broken for  
>>> periods of time. :-(
>>>
>>> On May 3, 2007, at 3:06 PM, Kevin Ballard wrote:
>>>
>>>> Oh hrm, it didn't occur to me that this would happen, but I know  
>>>> exactly why.
>>>>
>>>> However, I'm on vacation. Can this wait a week? It's a problem  
>>>> that only affects trunk.
>>>>
>>>> On May 3, 2007, at 5:40 AM, Guido Soranzio wrote:
>>>>
>>>>> After the changes to the "file delete" implementation, the  
>>>>> installation of
>>>>> ncurses fails because it tries to follow the target of a  
>>>>> symbolic link.
>>>>>
>>>>>
>>>>> By reversing the order of the arguments from
>>>>>
>>>>> delete ${destroot}${prefix}/share ${destroot}${prefix}/lib/ 
>>>>> terminfo
>>>>>
>>>>> into
>>>>>
>>>>> delete ${destroot}${prefix}/lib/terminfo ${destroot}${prefix}/ 
>>>>> share
>>>>>
>>>>> ncurses installs correctly (lib/terminfo is a symbolic link  
>>>>> to ../share/terminfo).
>>>>
>>>>
>>
>
> _______________________________________________
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev


From jberry at macports.org  Tue May  8 05:52:23 2007
From: jberry at macports.org (James Berry)
Date: Tue Oct  9 16:40:17 2007
Subject: MacPorts v1.4.40 released for self update
In-Reply-To: <151634FA-63AA-410A-81C8-D59D3126278D@orcaware.com>
References: <272BA956-50F4-4F4F-A3C4-6AA3D1885AA9@macports.org>
	<151634FA-63AA-410A-81C8-D59D3126278D@orcaware.com>
Message-ID: <E608826A-96FB-4D2B-A831-2CB0C9001B58@macports.org>

Hi Blair,

On May 7, 2007, at 11:10 PM, Blair Zajac wrote:

>
> On May 7, 2007, at 9:59 PM, James Berry wrote:
>
>> Here's the change log:
>>
>> James
>>
>> Release 1.4.40 (7-May-2007, tagged at r24909 by jberry):
>>
>
> James,
>
> Thanks for pushing this release out.
>
> Did the changes to bz2 make it in in the unarchive?  I didn't see  
> the revisions in this list.

I do remember something about those, but it's  bit foggy. Did the  
changes make it into trunk, or is there a particular ticket they were  
submitted on?

> Also, I tried to figure out on branches/release_1_4 what's been  
> merged in and there's no information in the log message on what  
> revisions were merged from trunk.  The one place that svn isn't  
> great is in merge tracking support; without an explicit log message  
> or other tool to keep track of what's been merged, there's no way  
> to tell what's been merged.  So I request we do the following:
>
> 1) Document the revisions merged into the branch in the log message.
> 2) Switch to using svnmerge.py for the next branch 1.5.  This will  
> allow us to see what revisions have been merged.

In recent releases (and until we can't) release_1_4 branch has just  
be tracking trunk, with all changes in trunk merged over. Its easy to  
merge and easy to document. But if there's failure to document  
something that goes into trunk, there's likewise failure to document  
what comes out the other end in release_1_4.

Thanks for the suggestion of svnmerge.py. I haven't had time to even  
think about it. You want to become the release manager for MacPorts?

James

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


From jberry at macports.org  Tue May  8 06:31:07 2007
From: jberry at macports.org (James Berry)
Date: Tue Oct  9 16:40:17 2007
Subject: [24922] trunk/dports/PortIndex
In-Reply-To: <20070508130627.6E71B5E717B@cvs.opensource.apple.com>
References: <20070508130627.6E71B5E717B@cvs.opensource.apple.com>
Message-ID: <084B63A7-0939-4B03-84AB-6E641DD95060@macports.org>


On May 8, 2007, at 6:06 AM, source_changes@macosforge.org wrote:

> Revision
> 24922
> Author
> dluke@macports.org
> Date
> 2007-05-08 06:06:26 -0700 (Tue, 08 May 2007)
> Log Message
>
> Total number of ports parsed:	3911
> Ports successfully parsed:	3907	
> Ports failed:			4
>
>
> Failed to parse file devel/libxfcegui4/Portfile: can't set  
> "depends_lib": invalid depspec: port::libxfce4util
> Failed to parse file math/cadabra/Portfile: can't set  
> "depends_lib": invalid depspec: port:pcre++
> Failed to parse file perl/p5-html-scrubber/Portfile: can't set  
> "depends_lib": invalid depspec: port:port:p5-html-parser
> Failed to parse file perl/p5-text-quoted/Portfile: can't set  
> "depends_lib": invalid depspec: port:p5-text-tabs+wrap
Okay, who changed the parsing of the dep spec?

Two of those actually are bad, two of them actually are good.

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070508/e566df4f/attachment.html
From dluke at geeklair.net  Tue May  8 06:35:16 2007
From: dluke at geeklair.net (Daniel J. Luke)
Date: Tue Oct  9 16:40:17 2007
Subject: [24922] trunk/dports/PortIndex
In-Reply-To: <084B63A7-0939-4B03-84AB-6E641DD95060@macports.org>
References: <20070508130627.6E71B5E717B@cvs.opensource.apple.com>
	<084B63A7-0939-4B03-84AB-6E641DD95060@macports.org>
Message-ID: <896D93B0-63F7-4296-843B-485A79D0D330@geeklair.net>

On May 8, 2007, at 9:31 AM, James Berry wrote:
> On May 8, 2007, at 6:06 AM, source_changes@macosforge.org wrote:
>
>> Revision 24922 Author dluke@macports.org Date 2007-05-08 06:06:26  
>> -0700 (Tue, 08 May 2007) Log MessageTotal number of ports parsed:	 
>> 3911 Ports successfully parsed:	3907	 Ports failed:	 4 Failed to  
>> parse file devel/libxfcegui4/Portfile: can't set "depends_lib":  
>> invalid depspec: port::libxfce4util Failed to parse file math/ 
>> cadabra/Portfile: can't set "depends_lib": invalid depspec:  
>> port:pcre++ Failed to parse file perl/p5-html-scrubber/Portfile:  
>> can't set "depends_lib": invalid depspec: port:port:p5-html-parser  
>> Failed to parse file perl/p5-text-quoted/Portfile: can't set  
>> "depends_lib": invalid depspec: port:p5-text-tabs+wrap
> Okay, who changed the parsing of the dep spec?

I don't think anyone did?

> Two of those actually are bad, two of them actually are good.

The two good ones have plusses in them (and I thought we weren't  
going to have plusses in port names?)
--
Daniel J. Luke
+========================================================+
| *---------------- dluke@geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
|   Opinions expressed are mine and do not necessarily   |
|          reflect the opinions of my employer.          |
+========================================================+


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070508/b69168e4/PGP.bin
From guido.soranzio at gmail.com  Tue May  8 07:05:19 2007
From: guido.soranzio at gmail.com (Guido Soranzio)
Date: Tue Oct  9 16:40:17 2007
Subject: New "file delete" implementation breaks ncurses
In-Reply-To: <62808822-9E43-436F-8A5B-046F9C61892A@macports.org>
References: <00A8B080-2CA9-4CDA-8864-0E9D5AA54F14@gmail.com>
	<E3968521-D9CA-4E49-8C61-FBAB22A7344B@macports.org>
	<6455FCFB-2FCD-4B3F-B25B-F3D114CBA408@brierdr.com>
	<DB8AF8C0-8C1E-4F8D-8CF8-F86B81E738EF@macports.org>
	<126ED9CD-2537-404F-B190-F78E2F8B5D07@brierdr.com>
	<62808822-9E43-436F-8A5B-046F9C61892A@macports.org>
Message-ID: <921F174A-7344-4C7C-B5FC-9136051854AE@gmail.com>


On May 8, 2007, at 2:47 PM, James Berry wrote:

> If I understand Guido's suggestion, the workaround is to the  
> Portfile, not to trunk, right?

The problem is that "delete" now tries to follow the orphan symbolic  
links.

IMHO, the "can't find" message is confusing: the orphan links should
simply be deleted without trying to traverse them. 

From blair at orcaware.com  Tue May  8 08:33:53 2007
From: blair at orcaware.com (Blair Zajac)
Date: Tue Oct  9 16:40:17 2007
Subject: MacPorts v1.4.40 released for self update
In-Reply-To: <E608826A-96FB-4D2B-A831-2CB0C9001B58@macports.org>
References: <272BA956-50F4-4F4F-A3C4-6AA3D1885AA9@macports.org>
	<151634FA-63AA-410A-81C8-D59D3126278D@orcaware.com>
	<E608826A-96FB-4D2B-A831-2CB0C9001B58@macports.org>
Message-ID: <C87E2AF7-B1A3-4CFE-80FC-209DB69DAD28@orcaware.com>


On May 8, 2007, at 5:52 AM, James Berry wrote:

> Hi Blair,
>
> On May 7, 2007, at 11:10 PM, Blair Zajac wrote:
>
>>
>> On May 7, 2007, at 9:59 PM, James Berry wrote:
>>
>>> Here's the change log:
>>>
>>> James
>>>
>>> Release 1.4.40 (7-May-2007, tagged at r24909 by jberry):
>>>
>>
>> James,
>>
>> Thanks for pushing this release out.
>>
>> Did the changes to bz2 make it in in the unarchive?  I didn't see  
>> the revisions in this list.
>
> I do remember something about those, but it's  bit foggy. Did the  
> changes make it into trunk, or is there a particular ticket they  
> were submitted on?

Yes, they made it into trunk and there's no ticket for them.  I guess  
I need to merge my change in trunk over to the release_1_4 branch?

>
>> Also, I tried to figure out on branches/release_1_4 what's been  
>> merged in and there's no information in the log message on what  
>> revisions were merged from trunk.  The one place that svn isn't  
>> great is in merge tracking support; without an explicit log  
>> message or other tool to keep track of what's been merged, there's  
>> no way to tell what's been merged.  So I request we do the following:
>>
>> 1) Document the revisions merged into the branch in the log message.
>> 2) Switch to using svnmerge.py for the next branch 1.5.  This will  
>> allow us to see what revisions have been merged.
>
> In recent releases (and until we can't) release_1_4 branch has just  
> be tracking trunk, with all changes in trunk merged over. Its easy  
> to merge and easy to document. But if there's failure to document  
> something that goes into trunk, there's likewise failure to  
> document what comes out the other end in release_1_4.

How are you doing the merge now?  How are you keeping track of which  
revisions have been merged over?

>
> Thanks for the suggestion of svnmerge.py. I haven't had time to  
> even think about it. You want to become the release manager for  
> MacPorts?

svnmerge.py will make life simplier, and there's a command  
'svnmerge.py avail -l' that shows all unmerged changes.  Also,  
'svnmerge.py merge' creates a commit message file containing all the  
commits on the trunk, so there's almost no additional documentation  
work.

And I'll pass on being the release manager :)

Regards,
Blair



From ryandesign at macports.org  Tue May  8 09:18:36 2007
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue Oct  9 16:40:17 2007
Subject: [24922] trunk/dports/PortIndex
In-Reply-To: <896D93B0-63F7-4296-843B-485A79D0D330@geeklair.net>
References: <20070508130627.6E71B5E717B@cvs.opensource.apple.com>
	<084B63A7-0939-4B03-84AB-6E641DD95060@macports.org>
	<896D93B0-63F7-4296-843B-485A79D0D330@geeklair.net>
Message-ID: <F1790E24-B441-4CD8-9C5F-24D9128EB1A7@macports.org>


On May 8, 2007, at 08:35, Daniel J. Luke wrote:

> On May 8, 2007, at 9:31 AM, James Berry wrote:
>
>> On May 8, 2007, at 6:06 AM, source_changes@macosforge.org wrote:
>>
>> > Failed to parse file devel/libxfcegui4/Portfile: can't set
>> > "depends_lib": invalid depspec: port::libxfce4util
>> > Failed to parse file math/cadabra/Portfile: can't set
>> > "depends_lib": invalid depspec: port:pcre++
>> > Failed to parse file perl/p5-html-scrubber/Portfile: can't set
>> > "depends_lib": invalid depspec: port:port:p5-html-parser
>> > Failed to parse file perl/p5-text-quoted/Portfile: can't set
>> > "depends_lib": invalid depspec: port:p5-text-tabs+wrap
>>
>> Okay, who changed the parsing of the dep spec?
>
> I don't think anyone did?

Well, Kevin fixed the regex to actually validate what it was meant to  
validate originally:

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

And then James merged it to the 1.4 branch:

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


>> Two of those actually are bad, two of them actually are good.
>
> The two good ones have plusses in them (and I thought we weren't  
> going to have plusses in port names?)

Well, we got 'em now. Now what? Do we rename the two ports or expand  
the regex?



From ryandesign at macports.org  Tue May  8 09:24:05 2007
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue Oct  9 16:40:17 2007
Subject: New "file delete" implementation breaks ncurses
In-Reply-To: <62808822-9E43-436F-8A5B-046F9C61892A@macports.org>
References: <00A8B080-2CA9-4CDA-8864-0E9D5AA54F14@gmail.com>
	<E3968521-D9CA-4E49-8C61-FBAB22A7344B@macports.org>
	<6455FCFB-2FCD-4B3F-B25B-F3D114CBA408@brierdr.com>
	<DB8AF8C0-8C1E-4F8D-8CF8-F86B81E738EF@macports.org>
	<126ED9CD-2537-404F-B190-F78E2F8B5D07@brierdr.com>
	<62808822-9E43-436F-8A5B-046F9C61892A@macports.org>
Message-ID: <886B2E79-53A3-41F4-A5DB-698B0E0EA396@macports.org>


On May 8, 2007, at 07:47, James Berry wrote:

> If I understand Guido's suggestion, the workaround is to the  
> Portfile, not to trunk, right? Who wants to fix it?

Looks like you committed a fix already:

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

Why did that necessitate a revision bump, by the way? If I already  
had ncurses successfully installed using a version of MacPorts where  
delete works properly (<=1.4.3?), then there is no need for me to  
install it again. And if I had a version of MacPorts with the new  
"file delete" implementation (>1.4.3?), then wouldn't I have been  
completely unable to install ncurses in the first place?


From jberry at macports.org  Tue May  8 09:24:48 2007
From: jberry at macports.org (James Berry)
Date: Tue Oct  9 16:40:17 2007
Subject: [24922] trunk/dports/PortIndex
In-Reply-To: <F1790E24-B441-4CD8-9C5F-24D9128EB1A7@macports.org>
References: <20070508130627.6E71B5E717B@cvs.opensource.apple.com>
	<084B63A7-0939-4B03-84AB-6E641DD95060@macports.org>
	<896D93B0-63F7-4296-843B-485A79D0D330@geeklair.net>
	<F1790E24-B441-4CD8-9C5F-24D9128EB1A7@macports.org>
Message-ID: <4762B178-8136-448F-A95E-3B7BD45AFC88@macports.org>


On May 8, 2007, at 9:18 AM, Ryan Schmidt wrote:

>>> Two of those actually are bad, two of them actually are good.
>>
>> The two good ones have plusses in them (and I thought we weren't  
>> going to have plusses in port names?)
>
> Well, we got 'em now. Now what? Do we rename the two ports or  
> expand the regex?

I exanded the regex to allow + in portnames (r24929), at least until  
something else is decided ;)

James

From pipping at macports.org  Tue May  8 09:33:17 2007
From: pipping at macports.org (Elias Pipping)
Date: Tue Oct  9 16:40:17 2007
Subject: [24922] trunk/dports/PortIndex
In-Reply-To: <F1790E24-B441-4CD8-9C5F-24D9128EB1A7@macports.org>
References: <20070508130627.6E71B5E717B@cvs.opensource.apple.com>
	<084B63A7-0939-4B03-84AB-6E641DD95060@macports.org>
	<896D93B0-63F7-4296-843B-485A79D0D330@geeklair.net>
	<F1790E24-B441-4CD8-9C5F-24D9128EB1A7@macports.org>
Message-ID: <8038C932-8263-435A-88C8-A65A527FC42F@macports.org>

On May 8, 2007, at 6:18 PM, Ryan Schmidt wrote:

> Well, we got 'em now. Now what? Do we rename the two ports or  
> expand the regex?

I believe both is happening right now[1][2].

[1] http://trac.macosforge.org/projects/macports/changeset/24932
[2] http://trac.macosforge.org/projects/macports/changeset/24929


Regards,

Elias

From jberry at macports.org  Tue May  8 09:31:04 2007
From: jberry at macports.org (James Berry)
Date: Tue Oct  9 16:40:17 2007
Subject: New "file delete" implementation breaks ncurses
In-Reply-To: <886B2E79-53A3-41F4-A5DB-698B0E0EA396@macports.org>
References: <00A8B080-2CA9-4CDA-8864-0E9D5AA54F14@gmail.com>
	<E3968521-D9CA-4E49-8C61-FBAB22A7344B@macports.org>
	<6455FCFB-2FCD-4B3F-B25B-F3D114CBA408@brierdr.com>
	<DB8AF8C0-8C1E-4F8D-8CF8-F86B81E738EF@macports.org>
	<126ED9CD-2537-404F-B190-F78E2F8B5D07@brierdr.com>
	<62808822-9E43-436F-8A5B-046F9C61892A@macports.org>
	<886B2E79-53A3-41F4-A5DB-698B0E0EA396@macports.org>
Message-ID: <032B9398-8F30-489F-9036-E7601DCC0A53@macports.org>


On May 8, 2007, at 9:24 AM, Ryan Schmidt wrote:

>
> On May 8, 2007, at 07:47, James Berry wrote:
>
>> If I understand Guido's suggestion, the workaround is to the  
>> Portfile, not to trunk, right? Who wants to fix it?
>
> Looks like you committed a fix already:
>
> http://trac.macosforge.org/projects/macports/changeset/24928
>
> Why did that necessitate a revision bump, by the way? If I already  
> had ncurses successfully installed using a version of MacPorts  
> where delete works properly (<=1.4.3?), then there is no need for  
> me to install it again. And if I had a version of MacPorts with the  
> new "file delete" implementation (>1.4.3?), then wouldn't I have  
> been completely unable to install ncurses in the first place?
>

Hi Ryan,

I wasn't sure what state this caused things to end up in. I've  
removed the revision bump.

James

From jberry at macports.org  Tue May  8 09:52:42 2007
From: jberry at macports.org (James Berry)
Date: Tue Oct  9 16:40:17 2007
Subject: Disallow + in portnames
In-Reply-To: <4762B178-8136-448F-A95E-3B7BD45AFC88@macports.org>
References: <20070508130627.6E71B5E717B@cvs.opensource.apple.com>
	<084B63A7-0939-4B03-84AB-6E641DD95060@macports.org>
	<896D93B0-63F7-4296-843B-485A79D0D330@geeklair.net>
	<F1790E24-B441-4CD8-9C5F-24D9128EB1A7@macports.org>
	<4762B178-8136-448F-A95E-3B7BD45AFC88@macports.org>
Message-ID: <3EC36389-138C-4F45-A1DE-76D687CDF8A4@macports.org>


On May 8, 2007, at 9:24 AM, James Berry wrote:

>
> On May 8, 2007, at 9:18 AM, Ryan Schmidt wrote:
>
>>>> Two of those actually are bad, two of them actually are good.
>>>
>>> The two good ones have plusses in them (and I thought we weren't  
>>> going to have plusses in port names?)
>>
>> Well, we got 'em now. Now what? Do we rename the two ports or  
>> expand the regex?
>
> I exanded the regex to allow + in portnames (r24929), at least  
> until something else is decided ;)

I'm inclined, by the way, to disallow the +, as I think it leads to  
other problems. We have only two ports with plus signs:

%port list 'name:\+'
p5-text-tabs+wrap              @2006.0711      perl/p5-text-tabs+wrap
pcre++                         @0.9.5          devel/pcre++


I propose that these two be changed, and that I remove the + sign  
allowance. Any dissent?

James

From jmpp at macports.org  Tue May  8 09:57:39 2007
From: jmpp at macports.org (Juan Manuel Palacios)
Date: Tue Oct  9 16:40:17 2007
Subject: [24932] trunk/dports/math/cadabra
In-Reply-To: <20070508161414.BE8835E740C@cvs.opensource.apple.com>
References: <20070508161414.BE8835E740C@cvs.opensource.apple.com>
Message-ID: <8F084009-73DC-4907-BEFC-747F9AABEB8B@macports.org>


	Hi Gregory!

On May 8, 2007, at 12:14 PM, source_changes@macosforge.org wrote:

>>
>  depends_lib	port:modglue	\
>  		port:pcre	\
> -		port:pcre++	\
> +		port:pcrexx	\
>  		port:gmp	\
>  		port:LiE

	Does the pcrexx port really exist? I couldn't find it with a simple  
search. If that's just a workaround for the + sign causing failures,  
James introduced a fix for that in trunk/base seconds ago. Doesn't an  
installation attempt fail if a dependency on a non-existent port is  
listed....?

	Regards,...


-jmpp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070508/715402bc/attachment.html
From jmpp at macports.org  Tue May  8 10:07:31 2007
From: jmpp at macports.org (Juan Manuel Palacios)
Date: Tue Oct  9 16:40:17 2007
Subject: MacPorts v1.4.40 released for self update
In-Reply-To: <E608826A-96FB-4D2B-A831-2CB0C9001B58@macports.org>
References: <272BA956-50F4-4F4F-A3C4-6AA3D1885AA9@macports.org>
	<151634FA-63AA-410A-81C8-D59D3126278D@orcaware.com>
	<E608826A-96FB-4D2B-A831-2CB0C9001B58@macports.org>
Message-ID: <B77F1180-9AC8-453F-BBC8-8411AD4C6DD2@macports.org>


On May 8, 2007, at 8:52 AM, James Berry wrote:

> Hi Blair,
>
> On May 7, 2007, at 11:10 PM, Blair Zajac wrote:
>
>>
>> On May 7, 2007, at 9:59 PM, James Berry wrote:
>>
>>> Here's the change log:
>>>
>>> James
>>>
>>> Release 1.4.40 (7-May-2007, tagged at r24909 by jberry):
>>>
>>
>> James,
>>
>> Thanks for pushing this release out.
>>
>> Did the changes to bz2 make it in in the unarchive?  I didn't see  
>> the revisions in this list.
>
> I do remember something about those, but it's  bit foggy. Did the  
> changes make it into trunk, or is there a particular ticket they  
> were submitted on?


	Archivemode supporting both creating and unpacking *bz[2] archives  
now works, both in trunk and in the 1.4.40 release. Blair fixed some  
bits and I fixed others, but I can't find the relevant commits for  
the live of me at the moment, But in any case, it should all Just  
Work, otherwise I'd be happy to look into it!

	Regards,...


-jmpp


From dluke at geeklair.net  Tue May  8 10:12:36 2007
From: dluke at geeklair.net (Daniel J. Luke)
Date: Tue Oct  9 16:40:17 2007
Subject: [24922] trunk/dports/PortIndex
In-Reply-To: <F1790E24-B441-4CD8-9C5F-24D9128EB1A7@macports.org>
References: <20070508130627.6E71B5E717B@cvs.opensource.apple.com>
	<084B63A7-0939-4B03-84AB-6E641DD95060@macports.org>
	<896D93B0-63F7-4296-843B-485A79D0D330@geeklair.net>
	<F1790E24-B441-4CD8-9C5F-24D9128EB1A7@macports.org>
Message-ID: <4084EB0A-B464-4BBB-8C2F-CC1280F02186@geeklair.net>

On May 8, 2007, at 12:18 PM, Ryan Schmidt wrote:
>>> Two of those actually are bad, two of them actually are good.
>>
>> The two good ones have plusses in them (and I thought we weren't  
>> going to have plusses in port names?)
>
> Well, we got 'em now. Now what? Do we rename the two ports or  
> expand the regex?

I vote for renaming the ports.

Having them there makes it harder to search for them with port search  
(since that's regex based).

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070508/dc08acb7/PGP.bin
From jmpp at macports.org  Tue May  8 10:11:33 2007
From: jmpp at macports.org (Juan Manuel Palacios)
Date: Tue Oct  9 16:40:17 2007
Subject: Disallow + in portnames
In-Reply-To: <3EC36389-138C-4F45-A1DE-76D687CDF8A4@macports.org>
References: <20070508130627.6E71B5E717B@cvs.opensource.apple.com>
	<084B63A7-0939-4B03-84AB-6E641DD95060@macports.org>
	<896D93B0-63F7-4296-843B-485A79D0D330@geeklair.net>
	<F1790E24-B441-4CD8-9C5F-24D9128EB1A7@macports.org>
	<4762B178-8136-448F-A95E-3B7BD45AFC88@macports.org>
	<3EC36389-138C-4F45-A1DE-76D687CDF8A4@macports.org>
Message-ID: <A79808E9-2DF5-4826-A086-3084980F1202@macports.org>


On May 8, 2007, at 12:52 PM, James Berry wrote:

>
> On May 8, 2007, at 9:24 AM, James Berry wrote:
>
>>
>> On May 8, 2007, at 9:18 AM, Ryan Schmidt wrote:
>>
>>>>> Two of those actually are bad, two of them actually are good.
>>>>
>>>> The two good ones have plusses in them (and I thought we weren't  
>>>> going to have plusses in port names?)
>>>
>>> Well, we got 'em now. Now what? Do we rename the two ports or  
>>> expand the regex?
>>
>> I exanded the regex to allow + in portnames (r24929), at least  
>> until something else is decided ;)
>
> I'm inclined, by the way, to disallow the +, as I think it leads to  
> other problems. We have only two ports with plus signs:
>
> %port list 'name:\+'
> p5-text-tabs+wrap              @2006.0711      perl/p5-text-tabs+wrap
> pcre++                         @0.9.5          devel/pcre++
>
>
> I propose that these two be changed, and that I remove the + sign  
> allowance. Any dissent?
>
> James


	I second the move, + signs have caused lots of problems before (at  
times needing several escapes to even mildly work) and lots of ports  
(some of them pertaining to C++ development) have already been moved  
to a *xx naming scheme. These two should be pcrexx and p5-text- 
tabsxwrap (or something...), respectively.


-jmpp


From dluke at geeklair.net  Tue May  8 10:32:57 2007
From: dluke at geeklair.net (Daniel J. Luke)
Date: Tue Oct  9 16:40:17 2007
Subject: [24915] branches/release_1_4/base
In-Reply-To: <20070508051157.458495E6A60@cvs.opensource.apple.com>
References: <20070508051157.458495E6A60@cvs.opensource.apple.com>
Message-ID: <829CFEDC-C34C-4835-8B55-E562064F4FC8@geeklair.net>

On May 8, 2007, at 1:11 AM, source_changes@macosforge.org wrote:
> Also, moving the IndexRegen.sh script to check out from the tags  
> dir, thus keeping the checkout always in sync with the latest  
> MacPorts release. NOTE to dluke: You should probably reinstall this  
> script and bootstrap it again ;-)

This change won't actually work the way you want it to.

Currently, I manually move a copy of IndexRegen.sh into position to  
actually run on my machine (as I don't particularly want anyone with  
commit access to be able to run arbitrary shell scripts on my machine  
(although it's probably a mute point as anyone with commit access  
could modify any of the base/ code that gets executed just as easily)).

SVN_BASE_URL isn't actually used by the script for much more than  
documentation, so changing it wont change where the checkout happens.

The script pulls from the latest release branch, and therefore  
doesn't need intervention unless/until major releases (when I would  
manually switch the repo to the later branch). Changing to a tag  
would require manual intervention on my part for every release.

In fact, I would rather we went in the opposite direction, where  
there was a 'current-release' branch that was used for the index regen.

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070508/58a047c0/PGP.bin
From eridius at macports.org  Tue May  8 12:16:53 2007
From: eridius at macports.org (Kevin Ballard)
Date: Tue Oct  9 16:40:17 2007
Subject: New "file delete" implementation breaks ncurses
In-Reply-To: <886B2E79-53A3-41F4-A5DB-698B0E0EA396@macports.org>
References: <00A8B080-2CA9-4CDA-8864-0E9D5AA54F14@gmail.com>
	<E3968521-D9CA-4E49-8C61-FBAB22A7344B@macports.org>
	<6455FCFB-2FCD-4B3F-B25B-F3D114CBA408@brierdr.com>
	<DB8AF8C0-8C1E-4F8D-8CF8-F86B81E738EF@macports.org>
	<126ED9CD-2537-404F-B190-F78E2F8B5D07@brierdr.com>
	<62808822-9E43-436F-8A5B-046F9C61892A@macports.org>
	<886B2E79-53A3-41F4-A5DB-698B0E0EA396@macports.org>
Message-ID: <9FC811B8-DA0C-4FCF-ACAB-69BC898F4D45@macports.org>

That's not actually a fix. You should revert it, then change it to  
two different commands a - delete for the real folder, and a 'file  
delete' for the symlink. The reason this isn't a fix is it will not  
delete the symlink this way.

I'll commit a fix to trunk for the 'delete