From florian.ebeling at gmail.com  Wed Oct  1 01:11:20 2008
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Wed, 1 Oct 2008 10:11:20 +0200
Subject: Important: MacPorts PortMgr Changes
In-Reply-To: <CDC52471-1C3A-4799-8895-BAB650B028FF@macports.org>
References: <CDC52471-1C3A-4799-8895-BAB650B028FF@macports.org>
Message-ID: <5cbbe4ae0810010111x2ae7fe40i2b19761750468f39@mail.gmail.com>

I think one way of organizing what you want would be
to put up a foundation. Then you have clear separation
of responsibilities. Finance and other assets governed by
a separate legal body, and the software project, which
means simply interested individuals. And the latter would still
be the cause of this new legal body, advising, organizing
support and whatever more in the background, and more
longterm. The term Elders sounds a bit weird to me, to be honest.

OTOH, my biggest concern is to get regular releases, anyway.
And if this new construct allows for that, and still is open
to incremental improvement, than I'm +1, too.

Florian

On Tue, Sep 30, 2008 at 6:18 PM, James Berry <jberry at macports.org> wrote:
> As many of you know, MacPorts is loosely governed by the "PortMgr"
> team, which is currently made up of three people: Markus Weissmann,
> Juan Manual Palacios, and James Berry.
>
> We each love MacPorts, and hope to see it continue to prosper and grow
> in the future. And we want to continue to contribute to the success of
> MacPorts as our time and professional lives allow in the future.
>
> But we each also have other significant professional and personal
> commitments that have made it difficult for us to put what we feel is
> an appropriate amount of time, energy, and enthusiasm into MacPorts in
> recent months and years, to the extent that we feel that additional
> day-to-day leadership is needed to ensure continued success and growth
> for the MacPorts project.
>
> So we want to propose some ideas to get new leadership blood into
> MacPorts, while retaining the systemic knowledge and continuity that
> our continued presence can allow. We therefore want to put the
> following plan forward for community comment (and hopefully,
> thereafter, implementation):
>
> (1) That the MacPorts community elect a new slate of PortMgr
> individuals, probably three people, to continue to guide day-to-day
> MacPorts operations and direction.
>
> (2) That the three of us move into an Elder-council ("advisory board",
> "trustees", "steering committee", etc), which will continue to help
> out and give guidance as needed, and watch over the long-term health
> of MacPorts assets such as domains and finances.
>
> The idea for the Elder council is based on our experience in the last
> several years. We've hesitated to make changes to PortMgr because we
> didn't want to disrupt continuity, but that has meant that PortMgr has
> stagnated as year-by-year changes in our lives affected our respective
> abilities to effectively govern day to day. We (collectively) need the
> ability to make swifter more responsive changes at the PortMgr level,
> while also ensuring the longer term continuity of the community and
> the infrastructure it relies on.
>
> We propose that PortMgr members be appointed by the community and have
> full control of all day-to-day operations of MacPorts. The Elder
> council will give advice and help to PortMgr members as requested, or
> as they see fit, but will not have the ability to replace or remove
> PortMgr members: that responsibility lies with the community. The
> Elder council might from time to time add or remove its own members:
> it's primary function is to oversee the long-term health and direction
> of the project, including long-term assets such as finances and
> domains. We also see the Elder council as a broader group from which
> PortMgr can draw for help if its members become temporarily
> preoccupied with life.
>
> We have asked Jordan Hubbard, the father of MacPorts, to join us on
> the Elder Council, and he has given his tentative acceptance.
>
> We'd like to ask for community comment on this plan, following which
> we hope to call for new PortMgr nominations and election in the coming
> weeks.
>
> We believe that successful nominees for the portmgr positions will
> have demonstrated an active participation in the MacPorts community,
> will have the technical and organizational skills to help lead and
> direct the project, and will have the time, energy, and experience to
> make and inspire great contributions to the project.
>
> The PortMgr team: Markus, Juan, and James
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>



-- 
Florian Ebeling
florian.ebeling at gmail.com

From macsforever2000 at macports.org  Wed Oct  1 15:16:11 2008
From: macsforever2000 at macports.org (Frank Schima)
Date: Wed, 1 Oct 2008 16:16:11 -0600
Subject: Adding finance and gis as primary categories
Message-ID: <C0AF1B09-EA8D-4D2A-9411-7D6C85D2CD6E@macports.org>

Are there any objections to me adding "finance" as a primary category  
- i.e. a new directory under dports? In particular I'm thinking of it  
for the proposed new port for ledger [1].

Also, a "gis" primary category would be good for MapServer [2], GRASS  
(should that ever happen) and probably a few more.

[1] <http://trac.macports.org/ticket/16684>
[2] <http://trac.macports.org/ticket/16238>


Cheers!
Frank


From raimue at macports.org  Wed Oct  1 15:37:30 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 02 Oct 2008 00:37:30 +0200
Subject: Adding finance and gis as primary categories
In-Reply-To: <C0AF1B09-EA8D-4D2A-9411-7D6C85D2CD6E@macports.org>
References: <C0AF1B09-EA8D-4D2A-9411-7D6C85D2CD6E@macports.org>
Message-ID: <48E3FBAA.8060609@macports.org>

Frank Schima wrote:
> Are there any objections to me adding "finance" as a primary category  
> - i.e. a new directory under dports? In particular I'm thinking of it  
> for the proposed new port for ledger [1].
> 
> Also, a "gis" primary category would be good for MapServer [2], GRASS  
> (should that ever happen) and probably a few more.

No objections. "finance" also sounds reasonable for other ports like
gnucash.

Please remember to append new primary categories to the list of valid
categories in port1.0/portlint.tcl.

Rainer

From wsiegrist at apple.com  Wed Oct  1 17:25:43 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Wed, 01 Oct 2008 17:25:43 -0700
Subject: Adding finance and gis as primary categories
In-Reply-To: <48E3FBAA.8060609@macports.org>
References: <C0AF1B09-EA8D-4D2A-9411-7D6C85D2CD6E@macports.org>
	<48E3FBAA.8060609@macports.org>
Message-ID: <760CEC59-1E71-4C42-8C15-FE4975B74F6A@apple.com>

On Oct 1, 2008, at 3:37 PM, Rainer M?ller wrote:

> Frank Schima wrote:
>> Are there any objections to me adding "finance" as a primary category
>> - i.e. a new directory under dports? In particular I'm thinking of it
>> for the proposed new port for ledger [1].
>>
>> Also, a "gis" primary category would be good for MapServer [2], GRASS
>> (should that ever happen) and probably a few more.
>
> No objections. "finance" also sounds reasonable for other ports like
> gnucash.
>
> Please remember to append new primary categories to the list of valid
> categories in port1.0/portlint.tcl.
>

BTW, in general if you change portlint.tcl, you need to email me with  
the rev number(s) so I can make sure the server that does the  
autolinting has the latest changes.



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

From jmr at macports.org  Wed Oct  1 22:46:37 2008
From: jmr at macports.org (Joshua Root)
Date: Thu, 02 Oct 2008 15:46:37 +1000
Subject: [MacPorts] #16723: unify the python portgroups
In-Reply-To: <052.94fab989ab68cb25f3bc6f6c380fdd16@macports.org>
References: <052.94fab989ab68cb25f3bc6f6c380fdd16@macports.org>
Message-ID: <48E4603D.3030306@macports.org>

For those that don't watch -tickets:

MacPorts wrote:
> #16723: unify the python portgroups
> ------------------------------+---------------------------------------------
>  Reporter:  jmr at macports.org  |       Owner:  macports-tickets at lists.macosforge.org
>      Type:  enhancement       |      Status:  new                                  
>  Priority:  Normal            |   Milestone:  MacPorts base enhancements           
> Component:  base              |     Version:  1.7.0                                
>  Keywords:                    |        Port:                                       
> ------------------------------+---------------------------------------------
>  The current practice of having separate ports of modules for each python
>  version is awkward, and will get far worse now that python 2.6 and 3.0 are
>  being released. Here is a portgroup that should be able to replace the
>  current python25 and python24 groups, and can install for any combination
>  of the available python versions at once via variants.

Please test and suggest improvements. One I can think of off the top of
my head is the ability to suppress the variants for unsupported python
versions.

- Josh

From febeling at macports.org  Thu Oct  2 00:58:04 2008
From: febeling at macports.org (C. Florian Ebeling)
Date: Thu, 2 Oct 2008 09:58:04 +0200
Subject: Fwd: [MacPorts] #16551: p5-mac-carbon does not install without
	forcing (-f)
In-Reply-To: <057.c4b5779e61735f20979b2dc5934222a9@macports.org>
References: <057.c4b5779e61735f20979b2dc5934222a9@macports.org>
Message-ID: <5cbbe4ae0810020058n36c1664bi5c0f8bd59068851d@mail.gmail.com>

I posted a patch for this bug Sep. 16, and the maintainer did
not react. I know there was this maintainer timeout rule, but I
also remember that there was discussion about abandoning it.
Can I apply this change now?

Florian

---------- Forwarded message ----------
From: MacPorts <noreply at macports.org>
Date: Tue, Sep 16, 2008 at 10:27 AM
Subject: [MacPorts] #16551: p5-mac-carbon does not install without forcing (-f)
To: febeling at macports.org, sal at email.arc.nasa.gov
Cc: macports-tickets at lists.macosforge.org


#16551: p5-mac-carbon does not install without forcing (-f)
-----------------------------------+----------------------------------------
 Reporter:  febeling at macports.org  |       Owner:  sal at email.arc.nasa.gov
    Type:  defect                 |      Status:  new
 Priority:  Normal                 |   Milestone:  Port Bugs
Component:  ports                  |     Version:  1.6.0
 Keywords:                         |        Port:  p5-mac-carbon
-----------------------------------+----------------------------------------
 The cause is a dependency "port:p5-test-simple".

 p5-test-simple overwrites files of the perl5.8 installation, and this
 causes  the failure, if -f is not present. (test-simple depends
 on p5-test-harness, and that has the same problem as test-simple).

 It seems that p5-mac-carbon does not really need the port p5-test-simple,
 so it should be removed as a dependency. There were other ports which
 declared test-simple as a dependency even though they didn't really need
 it, and this is probably just another case.

 Port p5-test-simple does not provide additional packages, but rather an
 update of perl5.8 components. So only ports which depend on these updates
 have to use p5-test-simple. Many may well work without, even if they use
 Test::Simple package.

--
Ticket URL: <http://trac.macports.org/ticket/16551>
MacPorts <http://www.macports.org/>
Ports system for Mac OS



-- 
Florian Ebeling
florian.ebeling at gmail.com

From florian.ebeling at gmail.com  Thu Oct  2 01:05:41 2008
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Thu, 2 Oct 2008 10:05:41 +0200
Subject: Adding finance and gis as primary categories
In-Reply-To: <48E3FBAA.8060609@macports.org>
References: <C0AF1B09-EA8D-4D2A-9411-7D6C85D2CD6E@macports.org>
	<48E3FBAA.8060609@macports.org>
Message-ID: <5cbbe4ae0810020105l388018et9f396dc9a11781bd@mail.gmail.com>

On Thu, Oct 2, 2008 at 12:37 AM, Rainer M?ller <raimue at macports.org> wrote:
> Frank Schima wrote:
>> Are there any objections to me adding "finance" as a primary category
>> - i.e. a new directory under dports? In particular I'm thinking of it
>> for the proposed new port for ledger [1].
>>
>> Also, a "gis" primary category would be good for MapServer [2], GRASS
>> (should that ever happen) and probably a few more.
>
> No objections. "finance" also sounds reasonable for other ports like
> gnucash.
>
> Please remember to append new primary categories to the list of valid
> categories in port1.0/portlint.tcl.

Now I understand why I was getting warnings about erlang ports.
I thought that was due to release lag. I just added it.

@Bill: portlint.tcl at 40445 contains the erlang category, but you probably
want finance and gis in as well before you update the running lint, I guess.

Florian

-- 
Florian Ebeling
florian.ebeling at gmail.com

From ryandesign at macports.org  Thu Oct  2 02:45:16 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 2 Oct 2008 04:45:16 -0500
Subject: [MacPorts] #16551: p5-mac-carbon does not install without forcing
	(-f)
In-Reply-To: <5cbbe4ae0810020058n36c1664bi5c0f8bd59068851d@mail.gmail.com>
References: <057.c4b5779e61735f20979b2dc5934222a9@macports.org>
	<5cbbe4ae0810020058n36c1664bi5c0f8bd59068851d@mail.gmail.com>
Message-ID: <1A921641-757D-4F09-865E-4FBE79FC3BB1@macports.org>


On Oct 2, 2008, at 2:58 AM, C. Florian Ebeling wrote:

> I posted a patch for this bug Sep. 16, and the maintainer did
> not react. I know there was this maintainer timeout rule, but I
> also remember that there was discussion about abandoning it.
> Can I apply this change now?

I think the discussion was about changing the maintainer timeout, not  
abandoning it, but I don't think it got anywhere. It's still  
documented in the Guide that if a maintainer does not respond to a  
ticket in 72 hours, anybody else can take it, and I recommend still  
following that rule.

> ---------- Forwarded message ----------
> From: MacPorts <noreply at macports.org>
> Date: Tue, Sep 16, 2008 at 10:27 AM
> Subject: [MacPorts] #16551: p5-mac-carbon does not install without  
> forcing (-f)
> To: febeling at macports.org, sal at email.arc.nasa.gov
> Cc: macports-tickets at lists.macosforge.org
>
>
> #16551: p5-mac-carbon does not install without forcing (-f)
> ----------------------------------- 
> +----------------------------------------
>  Reporter:  febeling at macports.org  |       Owner:   
> sal at email.arc.nasa.gov
>     Type:  defect                 |      Status:  new
>  Priority:  Normal                 |   Milestone:  Port Bugs
> Component:  ports                  |     Version:  1.6.0
>  Keywords:                         |        Port:  p5-mac-carbon
> ----------------------------------- 
> +----------------------------------------
>  The cause is a dependency "port:p5-test-simple".
>
>  p5-test-simple overwrites files of the perl5.8 installation, and this
>  causes  the failure, if -f is not present. (test-simple depends
>  on p5-test-harness, and that has the same problem as test-simple).
>
>  It seems that p5-mac-carbon does not really need the port p5-test- 
> simple,
>  so it should be removed as a dependency. There were other ports which
>  declared test-simple as a dependency even though they didn't  
> really need
>  it, and this is probably just another case.
>
>  Port p5-test-simple does not provide additional packages, but  
> rather an
>  update of perl5.8 components. So only ports which depend on these  
> updates
>  have to use p5-test-simple. Many may well work without, even if  
> they use
>  Test::Simple package.
>
> --
> Ticket URL: <http://trac.macports.org/ticket/16551>
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS

From raimue at macports.org  Thu Oct  2 02:51:00 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 02 Oct 2008 11:51:00 +0200
Subject: [MacPorts] #16551: p5-mac-carbon does not install without forcing
	(-f)
In-Reply-To: <1A921641-757D-4F09-865E-4FBE79FC3BB1@macports.org>
References: <057.c4b5779e61735f20979b2dc5934222a9@macports.org>	<5cbbe4ae0810020058n36c1664bi5c0f8bd59068851d@mail.gmail.com>
	<1A921641-757D-4F09-865E-4FBE79FC3BB1@macports.org>
Message-ID: <48E49984.4080502@macports.org>

Ryan Schmidt wrote:
> I think the discussion was about changing the maintainer timeout, not  
> abandoning it, but I don't think it got anywhere. It's still  
> documented in the Guide that if a maintainer does not respond to a  
> ticket in 72 hours, anybody else can take it, and I recommend still  
> following that rule.

But it is also documented that if the maintainer does not respond in
three weeks, the port should be considered abandoned.

<http://guide.macports.org/#project.update-policies.abandonment>

But if tickets are always picked up after 72h, there will never be the
three weeks timeout and the unresponding maintainer will never be removed...

Rainer

From ryandesign at macports.org  Thu Oct  2 03:04:40 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 2 Oct 2008 05:04:40 -0500
Subject: [MacPorts] #16551: p5-mac-carbon does not install without forcing
	(-f)
In-Reply-To: <48E49984.4080502@macports.org>
References: <057.c4b5779e61735f20979b2dc5934222a9@macports.org>	<5cbbe4ae0810020058n36c1664bi5c0f8bd59068851d@mail.gmail.com>
	<1A921641-757D-4F09-865E-4FBE79FC3BB1@macports.org>
	<48E49984.4080502@macports.org>
Message-ID: <098FA316-08C9-4980-BB3B-9631B585A9A3@macports.org>


On Oct 2, 2008, at 4:51 AM, Rainer M?ller wrote:

> Ryan Schmidt wrote:
>> I think the discussion was about changing the maintainer timeout, not
>> abandoning it, but I don't think it got anywhere. It's still
>> documented in the Guide that if a maintainer does not respond to a
>> ticket in 72 hours, anybody else can take it, and I recommend still
>> following that rule.
>
> But it is also documented that if the maintainer does not respond in
> three weeks, the port should be considered abandoned.
>
> <http://guide.macports.org/#project.update-policies.abandonment>
>
> But if tickets are always picked up after 72h, there will never be the
> three weeks timeout and the unresponding maintainer will never be  
> removed...

Yes, I do agree the port abandonment procedure is in conflict with  
the maintainer timeout rule. I think the timeout rule is fine; we  
just need a better abandonment procedure.

It currently says if a maintainer has not acknowledged a ticket  
within 3 weeks, then a new port abandonment ticket should be filed,  
and that the port abandonment ticket can be acted upon immediately to  
assign a new maintainer. I propose this be changed so that if there  
are n or more tickets about a maintainer's ports that he has not  
acknowledged, and it has been more than 72 hours since they were  
filed, then a new port abandonment ticket should be filed and  
assigned to the maintainer. If the maintainer does not respond to  
that ticket within 3 weeks, then the port is considered abandoned. n  
could be some number between, say, 2 and 5. How about a nice round 3?


From febeling at macports.org  Thu Oct  2 04:46:17 2008
From: febeling at macports.org (C. Florian Ebeling)
Date: Thu, 2 Oct 2008 13:46:17 +0200
Subject: [MacPorts] #16551: p5-mac-carbon does not install without forcing
	(-f)
In-Reply-To: <098FA316-08C9-4980-BB3B-9631B585A9A3@macports.org>
References: <057.c4b5779e61735f20979b2dc5934222a9@macports.org>
	<5cbbe4ae0810020058n36c1664bi5c0f8bd59068851d@mail.gmail.com>
	<1A921641-757D-4F09-865E-4FBE79FC3BB1@macports.org>
	<48E49984.4080502@macports.org>
	<098FA316-08C9-4980-BB3B-9631B585A9A3@macports.org>
Message-ID: <5cbbe4ae0810020446x47e6f611i3a9df2bf51b8df74@mail.gmail.com>

On Thu, Oct 2, 2008 at 12:04 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Oct 2, 2008, at 4:51 AM, Rainer M?ller wrote:
>> Ryan Schmidt wrote:
>>>
>>> I think the discussion was about changing the maintainer timeout, not
>>> abandoning it, but I don't think it got anywhere. It's still
>>> documented in the Guide that if a maintainer does not respond to a
>>> ticket in 72 hours, anybody else can take it, and I recommend still
>>> following that rule.
>>
>> But it is also documented that if the maintainer does not respond in
>> three weeks, the port should be considered abandoned.
>>
>> <http://guide.macports.org/#project.update-policies.abandonment>
>>
>> But if tickets are always picked up after 72h, there will never be the
>> three weeks timeout and the unresponding maintainer will never be
>> removed...
>
> Yes, I do agree the port abandonment procedure is in conflict with the
> maintainer timeout rule. I think the timeout rule is fine; we just need a
> better abandonment procedure.
>
> It currently says if a maintainer has not acknowledged a ticket within 3
> weeks, then a new port abandonment ticket should be filed, and that the port
> abandonment ticket can be acted upon immediately to assign a new maintainer.
> I propose this be changed so that if there are n or more tickets about a
> maintainer's ports that he has not acknowledged, and it has been more than
> 72 hours since they were filed, then a new port abandonment ticket should be
> filed and assigned to the maintainer. If the maintainer does not respond to
> that ticket within 3 weeks, then the port is considered abandoned. n could
> be some number between, say, 2 and 5. How about a nice round 3?

the number of ports this maintainer is responsible for has to
go into the equation as well I guess. Otherwise one-port-maintainers
have indefinite grace period :)

but to be honest I find this whole Abandonment procedure a bit draconian
and scary. Why not just make a rule that says that after more than 72 hours
a port becomes openmaintainer? maybe that was discussed already in the
other thread, though. but I would not really file abandonment to fix a bug
in a port I'm marginally interested in.

and only when you are really angry with the oblivious maintainer or really
interested in this particular port, you would file the abandonment ticket.

maybe then this whole abandonment procedure should be relevant to all
ports of a maintainer, though, because when you do not respond to the
abandoned ticket, this person is clearly no longer interested in macports
in general. the least one would expect would be to acknowledge that you
don't want or cannot do maintenance any longer and officially remove you
maintainer entry.

that's even more draconian than though :)

what I take away for this example is is that I can fix it.

Florian

-- 
Florian Ebeling
florian.ebeling at gmail.com

From macsforever2000 at macports.org  Thu Oct  2 07:28:38 2008
From: macsforever2000 at macports.org (Frank Schima)
Date: Thu, 2 Oct 2008 08:28:38 -0600
Subject: Adding finance and gis as primary categories
In-Reply-To: <760CEC59-1E71-4C42-8C15-FE4975B74F6A@apple.com>
References: <C0AF1B09-EA8D-4D2A-9411-7D6C85D2CD6E@macports.org>
	<48E3FBAA.8060609@macports.org>
	<760CEC59-1E71-4C42-8C15-FE4975B74F6A@apple.com>
Message-ID: <02147398-2BED-4D65-98AA-870ECE59FAA0@macports.org>

Hi William,


On Oct 1, 2008, at 6:25 PM, William Siegrist wrote:

> On Oct 1, 2008, at 3:37 PM, Rainer M?ller wrote:
>
>> Frank Schima wrote:
>>> Are there any objections to me adding "finance" as a primary  
>>> category
>>> - i.e. a new directory under dports? In particular I'm thinking of  
>>> it
>>> for the proposed new port for ledger [1].
>>>
>>> Also, a "gis" primary category would be good for MapServer [2],  
>>> GRASS
>>> (should that ever happen) and probably a few more.
>>
>> No objections. "finance" also sounds reasonable for other ports like
>> gnucash.
>>
>> Please remember to append new primary categories to the list of valid
>> categories in port1.0/portlint.tcl.
>
> BTW, in general if you change portlint.tcl, you need to email me  
> with the rev number(s) so I can make sure the server that does the  
> autolinting has the latest changes.


On Oct 2, 2008, at 2:05 AM, C. Florian Ebeling wrote:
> On Thu, Oct 2, 2008 at 12:37 AM, Rainer M?ller <raimue at macports.org>  
> wrote:
>> Frank Schima wrote:
>>> Are there any objections to me adding "finance" as a primary  
>>> category
>>> - i.e. a new directory under dports? In particular I'm thinking of  
>>> it
>>> for the proposed new port for ledger [1].
>>>
>>> Also, a "gis" primary category would be good for MapServer [2],  
>>> GRASS
>>> (should that ever happen) and probably a few more.
>>
>> No objections. "finance" also sounds reasonable for other ports like
>> gnucash.
>>
>> Please remember to append new primary categories to the list of valid
>> categories in port1.0/portlint.tcl.
>
> Now I understand why I was getting warnings about erlang ports.
> I thought that was due to release lag. I just added it.
>
> @Bill: portlint.tcl at 40445 contains the erlang category, but you  
> probably
> want finance and gis in as well before you update the running lint,  
> I guess.

I have added finance and gis to the primary categories in portlint.tcl  
in revision r40450.

Note that office was also added recently by afb in revision r39257.


Cheers!
Frank

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

From db.evans at gmail.com  Thu Oct  2 11:05:13 2008
From: db.evans at gmail.com (David Evans)
Date: Thu, 02 Oct 2008 11:05:13 -0700
Subject: Comitter help requested
Message-ID: <48E50D59.2030606@gmail.com>

I would greatly appreciate it if a comitter could take a look at the
patch for the ffmpeg Portfile
submitted with the following ticket

https://trac.macports.org/ticket/16589

No response for 2 weeks from the maintainer or otherwise and the port is
marked
as openmaintainer.

Thanks for any help

From macsforever2000 at macports.org  Thu Oct  2 11:35:59 2008
From: macsforever2000 at macports.org (Frank Schima)
Date: Thu, 2 Oct 2008 12:35:59 -0600
Subject: Comitter help requested
In-Reply-To: <48E50D59.2030606@gmail.com>
References: <48E50D59.2030606@gmail.com>
Message-ID: <AB076B2A-722B-4970-8440-B828147C8827@macports.org>


On Oct 2, 2008, at 12:05 PM, David Evans wrote:

> I would greatly appreciate it if a comitter could take a look at the
> patch for the ffmpeg Portfile
> submitted with the following ticket
>
> https://trac.macports.org/ticket/16589
>
> No response for 2 weeks from the maintainer or otherwise and the  
> port is
> marked
> as openmaintainer.

Done!

<https://trac.macports.org/changeset/40473>


Cheers!
Frank


From opendarwin.org at darkart.com  Thu Oct  2 12:02:24 2008
From: opendarwin.org at darkart.com (Eric Hall)
Date: Thu, 2 Oct 2008 19:02:24 +0000
Subject: [MacPorts] #16551: p5-mac-carbon does not install without
	forcing (-f)
In-Reply-To: <5cbbe4ae0810020446x47e6f611i3a9df2bf51b8df74@mail.gmail.com>
References: <057.c4b5779e61735f20979b2dc5934222a9@macports.org>
	<5cbbe4ae0810020058n36c1664bi5c0f8bd59068851d@mail.gmail.com>
	<1A921641-757D-4F09-865E-4FBE79FC3BB1@macports.org>
	<48E49984.4080502@macports.org>
	<098FA316-08C9-4980-BB3B-9631B585A9A3@macports.org>
	<5cbbe4ae0810020446x47e6f611i3a9df2bf51b8df74@mail.gmail.com>
Message-ID: <20081002190224.GZ31151@darkart.com>

On Thu, Oct 02, 2008 at 01:46:17PM +0200, C. Florian Ebeling wrote:
> On Thu, Oct 2, 2008 at 12:04 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> > On Oct 2, 2008, at 4:51 AM, Rainer M??ller wrote:
> >> Ryan Schmidt wrote:
> >>>
> >>> I think the discussion was about changing the maintainer timeout, not
> >>> abandoning it, but I don't think it got anywhere. It's still
> >>> documented in the Guide that if a maintainer does not respond to a
> >>> ticket in 72 hours, anybody else can take it, and I recommend still
> >>> following that rule.
> >>
> >> But it is also documented that if the maintainer does not respond in
> >> three weeks, the port should be considered abandoned.
> >>
> >> <http://guide.macports.org/#project.update-policies.abandonment>
> >>
> >> But if tickets are always picked up after 72h, there will never be the
> >> three weeks timeout and the unresponding maintainer will never be
> >> removed...
> >
> > Yes, I do agree the port abandonment procedure is in conflict with the
> > maintainer timeout rule. I think the timeout rule is fine; we just need a
> > better abandonment procedure.
> >
> > It currently says if a maintainer has not acknowledged a ticket within 3
> > weeks, then a new port abandonment ticket should be filed, and that the port
> > abandonment ticket can be acted upon immediately to assign a new maintainer.
> > I propose this be changed so that if there are n or more tickets about a
> > maintainer's ports that he has not acknowledged, and it has been more than
> > 72 hours since they were filed, then a new port abandonment ticket should be
> > filed and assigned to the maintainer. If the maintainer does not respond to
> > that ticket within 3 weeks, then the port is considered abandoned. n could
> > be some number between, say, 2 and 5. How about a nice round 3?
> 
> the number of ports this maintainer is responsible for has to
> go into the equation as well I guess. Otherwise one-port-maintainers
> have indefinite grace period :)
> 
> but to be honest I find this whole Abandonment procedure a bit draconian
> and scary. Why not just make a rule that says that after more than 72 hours
> a port becomes openmaintainer? maybe that was discussed already in the
> other thread, though. but I would not really file abandonment to fix a bug
> in a port I'm marginally interested in.

	I think making a port openmaintainer after 72 hours is a bad idea,
think about a time when a maintainer is on vacation for a week.  The idea of
filing an abandonment ticket and assigning it to the maintainer makes sense
to me when there's an indication that the maintainer isn't responding to
outstanding tickets against a port.  The three week grace period covers most
cases of vacations and the like (not sure how we let people indicate
they'll be away for longer than three weeks).
	


		-eric


From ryandesign at macports.org  Thu Oct  2 13:31:52 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 2 Oct 2008 15:31:52 -0500
Subject: [MacPorts] #16551: p5-mac-carbon does not install without forcing
	(-f)
In-Reply-To: <20081002190224.GZ31151@darkart.com>
References: <057.c4b5779e61735f20979b2dc5934222a9@macports.org>
	<5cbbe4ae0810020058n36c1664bi5c0f8bd59068851d@mail.gmail.com>
	<1A921641-757D-4F09-865E-4FBE79FC3BB1@macports.org>
	<48E49984.4080502@macports.org>
	<098FA316-08C9-4980-BB3B-9631B585A9A3@macports.org>
	<5cbbe4ae0810020446x47e6f611i3a9df2bf51b8df74@mail.gmail.com>
	<20081002190224.GZ31151@darkart.com>
Message-ID: <B7F8AD6A-F68A-485B-A240-B1A93D660A3A@macports.org>


On Oct 2, 2008, at 2:02 PM, Eric Hall wrote:

> On Thu, Oct 02, 2008 at 01:46:17PM +0200, C. Florian Ebeling wrote:
>> On Thu, Oct 2, 2008 at 12:04 PM, Ryan Schmidt  
>> <ryandesign at macports.org> wrote:
>>> On Oct 2, 2008, at 4:51 AM, Rainer M??ller wrote:
>>>> Ryan Schmidt wrote:
>>>>>
>>>>> I think the discussion was about changing the maintainer  
>>>>> timeout, not
>>>>> abandoning it, but I don't think it got anywhere. It's still
>>>>> documented in the Guide that if a maintainer does not respond to a
>>>>> ticket in 72 hours, anybody else can take it, and I recommend  
>>>>> still
>>>>> following that rule.
>>>>
>>>> But it is also documented that if the maintainer does not  
>>>> respond in
>>>> three weeks, the port should be considered abandoned.
>>>>
>>>> <http://guide.macports.org/#project.update-policies.abandonment>
>>>>
>>>> But if tickets are always picked up after 72h, there will never  
>>>> be the
>>>> three weeks timeout and the unresponding maintainer will never be
>>>> removed...
>>>
>>> Yes, I do agree the port abandonment procedure is in conflict  
>>> with the
>>> maintainer timeout rule. I think the timeout rule is fine; we  
>>> just need a
>>> better abandonment procedure.
>>>
>>> It currently says if a maintainer has not acknowledged a ticket  
>>> within 3
>>> weeks, then a new port abandonment ticket should be filed, and  
>>> that the port
>>> abandonment ticket can be acted upon immediately to assign a new  
>>> maintainer.
>>> I propose this be changed so that if there are n or more tickets  
>>> about a
>>> maintainer's ports that he has not acknowledged, and it has been  
>>> more than
>>> 72 hours since they were filed, then a new port abandonment  
>>> ticket should be
>>> filed and assigned to the maintainer. If the maintainer does not  
>>> respond to
>>> that ticket within 3 weeks, then the port is considered  
>>> abandoned. n could
>>> be some number between, say, 2 and 5. How about a nice round 3?
>>
>> the number of ports this maintainer is responsible for has to
>> go into the equation as well I guess. Otherwise one-port-maintainers
>> have indefinite grace period :)
>>
>> but to be honest I find this whole Abandonment procedure a bit  
>> draconian
>> and scary. Why not just make a rule that says that after more than  
>> 72 hours
>> a port becomes openmaintainer? maybe that was discussed already in  
>> the
>> other thread, though. but I would not really file abandonment to  
>> fix a bug
>> in a port I'm marginally interested in.
>
> 	I think making a port openmaintainer after 72 hours is a bad idea,
> think about a time when a maintainer is on vacation for a week.   
> The idea of
> filing an abandonment ticket and assigning it to the maintainer  
> makes sense
> to me when there's an indication that the maintainer isn't  
> responding to
> outstanding tickets against a port.  The three week grace period  
> covers most
> cases of vacations and the like (not sure how we let people indicate
> they'll be away for longer than three weeks).


The maintainer could just send an email to the dev list. I think then  
we'd remember the maintainer's name if it came up in an abandonment  
request ticket.



From ryandesign at macports.org  Thu Oct  2 14:05:49 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 2 Oct 2008 16:05:49 -0500
Subject: [40473] trunk/dports/multimedia/ffmpeg/Portfile
In-Reply-To: <20081002183352.7802145AEFD@beta.macosforge.org>
References: <20081002183352.7802145AEFD@beta.macosforge.org>
Message-ID: <446EB859-29BF-4C74-A6DD-A87AB0E0BC19@macports.org>

On Oct 2, 2008, at 1:33 PM, macsforever2000 at macports.org wrote:

> Revision: 40473
>           http://trac.macports.org/changeset/40473
> Author:   macsforever2000 at macports.org
> Date:     2008-10-02 11:33:51 -0700 (Thu, 02 Oct 2008)
> Log Message:
> -----------
> Fix for displaying version number. Closes ticket #16589.
>
> Modified Paths:
> --------------
>     trunk/dports/multimedia/ffmpeg/Portfile
>
> Modified: trunk/dports/multimedia/ffmpeg/Portfile
> ===================================================================
> --- trunk/dports/multimedia/ffmpeg/Portfile	2008-10-02 18:13:33 UTC  
> (rev 40472)
> +++ trunk/dports/multimedia/ffmpeg/Portfile	2008-10-02 18:33:51 UTC  
> (rev 40473)
> @@ -4,7 +4,7 @@
>
>  name		ffmpeg
>  version		0.4.9-pre1
> -revision	11
> +revision	12
>  categories	multimedia
>  maintainers	acho at macports.org openmaintainer
>  description	Digital VCR and streaming server
> @@ -43,11 +43,19 @@
>
>  set svn_rev 14381
>
> +pre-fetch {
> +    if {[file isdirectory ${distpath}/${svn_rev}]} {
> +        if {![file isdirectory ${distpath}/${svn_rev}/trunk/.svn]} {
> +             file delete -force ${distpath}/${svn_rev}
> +        }
> +    }
> +}
> +
>  fetch {
>      if {![file isdirectory ${distpath}/${svn_rev}]} {
>          file mkdir ${distpath}/${svn_rev}
> -        system "svn export -r${svn_rev} --ignore-externals svn:// 
> svn.mplayerhq.hu/ffmpeg/trunk ${distpath}/${svn_rev}/trunk"
> -        system "svn export -r27349 svn://svn.mplayerhq.hu/mplayer/ 
> trunk/libswscale ${distpath}/${svn_rev}/trunk/libswscale"
> +        system "svn co -r${svn_rev} --ignore-externals svn:// 
> svn.mplayerhq.hu/ffmpeg/trunk ${distpath}/${svn_rev}/trunk"
> +        system "svn co -r27349 svn://svn.mplayerhq.hu/mplayer/ 
> trunk/libswscale ${distpath}/${svn_rev}/trunk/libswscale"
>      }
>  }

But this just forces the working copy to be discarded and checked out  
again every time you try to install. I thought the point of having a  
working copy was so that it could be reused. It would be nice if the  
working copy were only deleted in the pre-fetch phase if the revision  
number of the working copy (see the "svnversion" command) doesn't  
match the revision the port wants to check out.


From macsforever2000 at macports.org  Thu Oct  2 14:18:15 2008
From: macsforever2000 at macports.org (Frank Schima)
Date: Thu, 2 Oct 2008 15:18:15 -0600
Subject: [40473] trunk/dports/multimedia/ffmpeg/Portfile
In-Reply-To: <446EB859-29BF-4C74-A6DD-A87AB0E0BC19@macports.org>
References: <20081002183352.7802145AEFD@beta.macosforge.org>
	<446EB859-29BF-4C74-A6DD-A87AB0E0BC19@macports.org>
Message-ID: <8E1758B2-1785-4C96-AA9F-851D689EB9A8@macports.org>

Hi Ryan,


On Oct 2, 2008, at 3:05 PM, Ryan Schmidt wrote:

> But this just forces the working copy to be discarded and checked  
> out again every time you try to install. I thought the point of  
> having a working copy was so that it could be reused. It would be  
> nice if the working copy were only deleted in the pre-fetch phase if  
> the revision number of the working copy (see the "svnversion"  
> command) doesn't match the revision the port wants to check out.

I added your comment to the ticket in question [1] and maybe the patch  
submitter will update it.

[1] <http://trac.macports.org/ticket/16589>


Cheers!
Frank


From ryandesign at macports.org  Thu Oct  2 15:29:57 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 2 Oct 2008 17:29:57 -0500
Subject: [40473] trunk/dports/multimedia/ffmpeg/Portfile
In-Reply-To: <8E1758B2-1785-4C96-AA9F-851D689EB9A8@macports.org>
References: <20081002183352.7802145AEFD@beta.macosforge.org>
	<446EB859-29BF-4C74-A6DD-A87AB0E0BC19@macports.org>
	<8E1758B2-1785-4C96-AA9F-851D689EB9A8@macports.org>
Message-ID: <97061BDC-E4B8-4192-9AEE-A82329C15AB1@macports.org>

On Oct 2, 2008, at 4:18 PM, Frank Schima wrote:

> On Oct 2, 2008, at 3:05 PM, Ryan Schmidt wrote:
>
>> But this just forces the working copy to be discarded and checked
>> out again every time you try to install. I thought the point of
>> having a working copy was so that it could be reused. It would be
>> nice if the working copy were only deleted in the pre-fetch phase if
>> the revision number of the working copy (see the "svnversion"
>> command) doesn't match the revision the port wants to check out.
>
> I added your comment to the ticket in question [1] and maybe the patch
> submitter will update it.
>
> [1] <http://trac.macports.org/ticket/16589>

My mistake, I misread the patch. It's fine as it is. I see now that  
it only deletes the distpath directory if it is an export and not a  
working copy.



From febeling at macports.org  Fri Oct  3 04:25:06 2008
From: febeling at macports.org (C. Florian Ebeling)
Date: Fri, 3 Oct 2008 13:25:06 +0200
Subject: problem with multiple active ports
Message-ID: <5cbbe4ae0810030425o5936f836v9a0f951b9c78a9f1@mail.gmail.com>

I managed to have multiple active ports, and they are not
uninstallable. Any idea how to solve this problem[1]? And any
idea what caused it? The only unusual thing here is
the pseudo version number 0.0 I use, since the project
does not have a proper version number.

DEBUG: Executing org.macports.activate (mochiweb)
--->  Activating mochiweb @0.0_2
Error: Target org.macports.activate returned: Image error: Another
version of this port (mochiweb @0.0_0) is already active.
Warning: the following items did not execute (for mochiweb):
org.macports.activate
Error: Status 1 encountered during processing.
flomac:mochiweb febeling$ port installed mochiweb
The following ports are currently installed:
  mochiweb @0.0_0 (active)
  mochiweb @0.0_1 (active)
  mochiweb @0.0_2 (active)
flomac:mochiweb febeling$ sudo port -f uninstall mochiweb mochiweb @0.0_0
--->  The following versions of mochiweb are currently installed:
--->  	mochiweb @0.0_0 (active)
--->  	mochiweb @0.0_1 (active)
--->  	mochiweb @0.0_2 (active)
Error: port uninstall failed: Registry error: Please specify the full
version as recorded in the port registry.

Also, what do you do in cases where there is no version
to be had.

Florian

[1] short of reinstalling everything



-- 
Florian Ebeling
florian.ebeling at gmail.com

From febeling at macports.org  Fri Oct  3 04:51:52 2008
From: febeling at macports.org (C. Florian Ebeling)
Date: Fri, 3 Oct 2008 13:51:52 +0200
Subject: problem with multiple active ports
In-Reply-To: <5cbbe4ae0810030425o5936f836v9a0f951b9c78a9f1@mail.gmail.com>
References: <5cbbe4ae0810030425o5936f836v9a0f951b9c78a9f1@mail.gmail.com>
Message-ID: <5cbbe4ae0810030451q6af165bck2362948d20253966@mail.gmail.com>

On Fri, Oct 3, 2008 at 1:25 PM, C. Florian Ebeling
<febeling at macports.org> wrote:
> I managed to have multiple active ports, and they are not
> uninstallable. Any idea how to solve this problem[1]? And any
> idea what caused it? The only unusual thing here is
> the pseudo version number 0.0 I use, since the project
> does not have a proper version number.

Filed as #16740.

https://trac.macports.org/ticket/16740

Where is the "active" state maintained? Is it possible to clean up by hand?

Florian

-- 
Florian Ebeling
florian.ebeling at gmail.com

From raimue at macports.org  Fri Oct  3 05:17:44 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Fri, 03 Oct 2008 14:17:44 +0200
Subject: problem with multiple active ports
In-Reply-To: <5cbbe4ae0810030451q6af165bck2362948d20253966@mail.gmail.com>
References: <5cbbe4ae0810030425o5936f836v9a0f951b9c78a9f1@mail.gmail.com>
	<5cbbe4ae0810030451q6af165bck2362948d20253966@mail.gmail.com>
Message-ID: <48E60D68.7080707@macports.org>

C. Florian Ebeling wrote:
> Where is the "active" state maintained? Is it possible to clean up by hand?

Have a look at ${prefi}/var/macports/receipts/

The receipt.bz2 files are normal text files, just decompress them. There
 will be "active 1" inside the file, change it to "active 0".

HTH,
Rainer

From febeling at macports.org  Fri Oct  3 05:44:26 2008
From: febeling at macports.org (C. Florian Ebeling)
Date: Fri, 3 Oct 2008 14:44:26 +0200
Subject: problem with multiple active ports
In-Reply-To: <48E60D68.7080707@macports.org>
References: <5cbbe4ae0810030425o5936f836v9a0f951b9c78a9f1@mail.gmail.com>
	<5cbbe4ae0810030451q6af165bck2362948d20253966@mail.gmail.com>
	<48E60D68.7080707@macports.org>
Message-ID: <5cbbe4ae0810030544i6726d536g93d3f2582872cf92@mail.gmail.com>

On Fri, Oct 3, 2008 at 2:17 PM, Rainer M?ller <raimue at macports.org> wrote:
> C. Florian Ebeling wrote:
>> Where is the "active" state maintained? Is it possible to clean up by hand?
>
> Have a look at ${prefi}/var/macports/receipts/
>
> The receipt.bz2 files are normal text files, just decompress them. There
>  will be "active 1" inside the file, change it to "active 0".

that was definitely helpful, thanks!

Florian




-- 
Florian Ebeling
florian.ebeling at gmail.com

From frstan at bellsouth.net  Fri Oct  3 08:32:24 2008
From: frstan at bellsouth.net (William Davis)
Date: Fri, 3 Oct 2008 11:32:24 -0400
Subject: problem with multiple active ports
In-Reply-To: <5cbbe4ae0810030544i6726d536g93d3f2582872cf92@mail.gmail.com>
References: <5cbbe4ae0810030425o5936f836v9a0f951b9c78a9f1@mail.gmail.com>
	<5cbbe4ae0810030451q6af165bck2362948d20253966@mail.gmail.com>
	<48E60D68.7080707@macports.org>
	<5cbbe4ae0810030544i6726d536g93d3f2582872cf92@mail.gmail.com>
Message-ID: <C33C664E-DFAA-4B19-A053-41399E35BFF4@bellsouth.net>


On Oct 3, 2008, at 8:44 AM, C. Florian Ebeling wrote:

> On Fri, Oct 3, 2008 at 2:17 PM, Rainer M?ller <raimue at macports.org>  
> wrote:
>> C. Florian Ebeling wrote:
>>> Where is the "active" state maintained? Is it possible to clean up  
>>> by hand?
>>
>> Have a look at ${prefi}/var/macports/receipts/
>>
>> The receipt.bz2 files are normal text files, just decompress them.  
>> There
>> will be "active 1" inside the file, change it to "active 0".
>
> that was definitely helpful, thanks!
>
> Florian
>

If you use:
sudo port -u upgrade foo
port will automatically uninstall the old version when it installs the  
new one.

William Davis
frstanATbellsouthDOTnet
Mac OS X.5.5 Darwin 9.5.0
XQuartz 2.3.1 (xorg-server 1.4.2-apple17)
Mac Mini Intel Duo @ 1.86 GHz

Mundus vult decepi, ego non


From wsiegrist at apple.com  Fri Oct  3 08:40:01 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Fri, 03 Oct 2008 08:40:01 -0700
Subject: Adding finance and gis as primary categories
In-Reply-To: <4784B4F0-9DF1-45FA-A9A7-D7A93AFA8332@macports.org>
References: <C0AF1B09-EA8D-4D2A-9411-7D6C85D2CD6E@macports.org>
	<48E3FBAA.8060609@macports.org>
	<760CEC59-1E71-4C42-8C15-FE4975B74F6A@apple.com>
	<4784B4F0-9DF1-45FA-A9A7-D7A93AFA8332@macports.org>
Message-ID: <7F095810-BFE7-4A82-8BC4-B58C8DFD1DC9@apple.com>

The servers have been updated.

Thanks
-Bill


On Oct 2, 2008, at 6:22 AM, Frank Schima wrote:

> Hi William,
>
>
> On Oct 1, 2008, at 6:25 PM, William Siegrist wrote:
>
>> On Oct 1, 2008, at 3:37 PM, Rainer M?ller wrote:
>>
>>> Frank Schima wrote:
>>>> Are there any objections to me adding "finance" as a primary  
>>>> category
>>>> - i.e. a new directory under dports? In particular I'm thinking  
>>>> of it
>>>> for the proposed new port for ledger [1].
>>>>
>>>> Also, a "gis" primary category would be good for MapServer [2],  
>>>> GRASS
>>>> (should that ever happen) and probably a few more.
>>>
>>> No objections. "finance" also sounds reasonable for other ports like
>>> gnucash.
>>>
>>> Please remember to append new primary categories to the list of  
>>> valid
>>> categories in port1.0/portlint.tcl.
>>>
>>
>> BTW, in general if you change portlint.tcl, you need to email me  
>> with the rev number(s) so I can make sure the server that does the  
>> autolinting has the latest changes.
>
>
> On Oct 2, 2008, at 2:05 AM, C. Florian Ebeling wrote:
>
>> Now I understand why I was getting warnings about erlang ports.
>> I thought that was due to release lag. I just added it.
>>
>> @Bill: portlint.tcl at 40445 contains the erlang category, but you  
>> probably
>> want finance and gis in as well before you update the running lint,  
>> I guess.
>
>
> I have added finance and gis to the primary categories in  
> portlint.tcl in revision r40450.
>
> Note that office was also added recently by afb in revision r39257.
>
>
> Cheers!
> Frank
>




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







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

From db.evans at gmail.com  Sat Oct  4 11:39:19 2008
From: db.evans at gmail.com (David Evans)
Date: Sat, 04 Oct 2008 11:39:19 -0700
Subject: help committing gimp2 2.60 upgrade
Message-ID: <48E7B857.8080607@gmail.com>

Would appreciate committer help in submitting the patch to upgrade gimp2
to 2.60 and
its new required dependencies gegl and babl

See

https://trac.macports.org/ticket/16729  (babl)
https://trac.macports.org/ticket/16730  (gegl)
https://trac.macports.org/ticket/16735  (gimp2)

Thanks

Dave


From blair at orcaware.com  Mon Oct  6 11:00:19 2008
From: blair at orcaware.com (Blair Zajac)
Date: Mon, 06 Oct 2008 11:00:19 -0700
Subject: MacPorts mirrors of beanshell files not working
Message-ID: <48EA5233.1000000@orcaware.com>

I'm doing some work on the beanshell port and beanshell.org is down so none of 
the files can be downloaded and doing a fetch doesn't try to get anything from 
our mirrors.

$
DEBUG: Executing org.macports.fetch (beanshell)
--->  bsh-2.0b4.jar doesn't seem to exist in 
/Users/blair/my-macports/var/macports/distfiles/beanshell
--->  Attempting to fetch bsh-2.0b4.jar from http://www.beanshell.org/
   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                  Dload  Upload   Total   Spent    Left  Speed
   0     0    0     0    0     0      0      0 --:--:--  0:01:15 --:--:--     0
DEBUG: Fetching failed:: HTTP response code said error
Error: Target org.macports.fetch returned: fetch failed
Warning: the following items did not execute (for beanshell): 
org.macports.fetchError: Status 1 encountered during processing.
$

Is there anything in this Portfile that's preventing it from working:

https://svn.macports.org/repository/macports/trunk/dports/java/beanshell/Portfile


Regards,
Blair

From jmr at macports.org  Mon Oct  6 11:45:08 2008
From: jmr at macports.org (Joshua Root)
Date: Tue, 07 Oct 2008 05:45:08 +1100
Subject: MacPorts mirrors of beanshell files not working
In-Reply-To: <48EA5233.1000000@orcaware.com>
References: <48EA5233.1000000@orcaware.com>
Message-ID: <48EA5CB4.3040402@macports.org>

Blair Zajac wrote:
> I'm doing some work on the beanshell port and beanshell.org is down so none of 
> the files can be downloaded and doing a fetch doesn't try to get anything from 
> our mirrors.
[...]
> Is there anything in this Portfile that's preventing it from working:
> 
> https://svn.macports.org/repository/macports/trunk/dports/java/beanshell/Portfile

There hasn't been a base release since distfiles.macports.org was
created, so for now you'll have to add it manually to master_sites if
you want the port to use it.

- Josh

From wsiegrist at apple.com  Mon Oct  6 12:49:34 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Mon, 06 Oct 2008 12:49:34 -0700
Subject: MacPorts mirrors of beanshell files not working
In-Reply-To: <48EA5CB4.3040402@macports.org>
References: <48EA5233.1000000@orcaware.com> <48EA5CB4.3040402@macports.org>
Message-ID: <6274CD44-4C7C-4744-8166-D9EF83F4FE5B@apple.com>


On Oct 6, 2008, at 11:45 AM, Joshua Root wrote:

> Blair Zajac wrote:
>> I'm doing some work on the beanshell port and beanshell.org is down  
>> so none of
>> the files can be downloaded and doing a fetch doesn't try to get  
>> anything from
>> our mirrors.
> [...]
>> Is there anything in this Portfile that's preventing it from working:
>>
>> https://svn.macports.org/repository/macports/trunk/dports/java/beanshell/Portfile
>
> There hasn't been a base release since distfiles.macports.org was
> created, so for now you'll have to add it manually to master_sites if
> you want the port to use it.
>

And for convenience, the URL is:

http://distfiles.macports.org/beanshell/

-Bill



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

From blair at orcaware.com  Mon Oct  6 13:56:25 2008
From: blair at orcaware.com (Blair Zajac)
Date: Mon, 06 Oct 2008 13:56:25 -0700
Subject: MacPorts mirrors of beanshell files not working
In-Reply-To: <6274CD44-4C7C-4744-8166-D9EF83F4FE5B@apple.com>
References: <48EA5233.1000000@orcaware.com> <48EA5CB4.3040402@macports.org>
	<6274CD44-4C7C-4744-8166-D9EF83F4FE5B@apple.com>
Message-ID: <48EA7B79.2060101@orcaware.com>

William Siegrist wrote:
> 
> On Oct 6, 2008, at 11:45 AM, Joshua Root wrote:
> 
>> Blair Zajac wrote:
>>> I'm doing some work on the beanshell port and beanshell.org is down 
>>> so none of
>>> the files can be downloaded and doing a fetch doesn't try to get 
>>> anything from
>>> our mirrors.
>> [...]
>>> Is there anything in this Portfile that's preventing it from working:
>>>
>>> https://svn.macports.org/repository/macports/trunk/dports/java/beanshell/Portfile 
>>>
>>
>> There hasn't been a base release since distfiles.macports.org was
>> created, so for now you'll have to add it manually to master_sites if
>> you want the port to use it.
>>
> 
> And for convenience, the URL is:
> 
> http://distfiles.macports.org/beanshell/
> 
> -Bill

Great, that works.

Thanks,
Blair


From gaspard at teti.ch  Tue Oct  7 05:50:48 2008
From: gaspard at teti.ch (Gaspard Bucher)
Date: Tue, 7 Oct 2008 14:50:48 +0200
Subject: Creating a new port
Message-ID: <5F9CB650-F59B-45B6-9B3A-9D57E5BD3BF4@teti.ch>

Hello !

I would like to create a port to ease installation of zena (a ruby on  
rails based CMS, http://zenadmin.org). The idea is to

1. write the dependencies in a Portfile

build-essential apache2 mysql-server libmagick9-dev gs-gpl libssl-dev  
gettext libgettext-ruby libreadline5 libreadline5-dev zlib1g-dev  
libncurses5 libncurses5-dev temcap-compat unzip liburi-perl jpeg tiff  
ruby rb-rubygems

2. trigger a script to install ruby gems, some with specified versions

gem install gettext --version 1.90.0
gem install RedCloth --version 3.0.4
gem install rake mongrel mongrel_cluster rmagick tzinfo RedCloth  
syntax mongrel_upload_progress uuidtools daemons ruby-debug
gem install --source http://www.loonsoft.com/recaptcha/pkg/ recaptcha

3. find a way to fetch zena sources somewhere in /opt/... (idealy with  
svn/git so it is easy to update the code)

4. install a script to start/stop/update zena


Is all this a really bad idea because there are other (simpler) ways  
to achieve this ?

What do you think ?

Gaspard

From florian.ebeling at gmail.com  Tue Oct  7 07:00:17 2008
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Tue, 7 Oct 2008 16:00:17 +0200
Subject: Creating a new port
In-Reply-To: <5F9CB650-F59B-45B6-9B3A-9D57E5BD3BF4@teti.ch>
References: <5F9CB650-F59B-45B6-9B3A-9D57E5BD3BF4@teti.ch>
Message-ID: <5cbbe4ae0810070700h1067cc6fke9fc21fed709ec87@mail.gmail.com>

> I would like to create a port to ease installation of zena (a ruby on
> rails based CMS, http://zenadmin.org). The idea is to
>
> 1. write the dependencies in a Portfile
>
> build-essential apache2 mysql-server libmagick9-dev gs-gpl libssl-dev
> gettext libgettext-ruby libreadline5 libreadline5-dev zlib1g-dev
> libncurses5 libncurses5-dev temcap-compat unzip liburi-perl jpeg tiff
> ruby rb-rubygems
>
> 2. trigger a script to install ruby gems, some with specified versions
>
> gem install gettext --version 1.90.0
> gem install RedCloth --version 3.0.4
> gem install rake mongrel mongrel_cluster rmagick tzinfo RedCloth
> syntax mongrel_upload_progress uuidtools daemons ruby-debug
> gem install --source http://www.loonsoft.com/recaptcha/pkg/ recaptcha
>
> 3. find a way to fetch zena sources somewhere in /opt/... (idealy with
> svn/git so it is easy to update the code)
>
> 4. install a script to start/stop/update zena
>
>
> Is all this a really bad idea because there are other (simpler) ways
> to achieve this ?

all this is possible right now, with two exceptions:
- you cannot specify a gem version, you just have to
depend on the port-wrapped gem that is current with
macports.
- git is not supported for fetching, but svn is.

the gem version requirements could be a problem
if they exist already and the maintainer is not willing
to switch to these versions. but i guess you want rather
new versions, and he should usually upgrade if you
ask, maybe even with a ticket + patch.
if the gem does not exist already, then you can just add
that as well and become maintainer. then you have
control over the version included in mp.
for starting and stopping there is support present in the
form of startup items, see the mp guide.

the whole scenario is not a bad idea at all, but rather
pretty much the most common use case for mp :)

to prepare the ruby ports you  want to use ruby port
group functionalty. you can pretty much have a whole
port file (or the interesting parts of it) covered by a single
call to ruby.setup function.

unfortunately this call is not properly documented in the
guide. i wanted to do this but i didn't have the time right
now. you will rather have to look at other portfiles or
read the source:

http://trac.macports.org/browser/branches/release_1_6/base/src/port1.0/resources/group/ruby-1.0.tcl


Florian



-- 
Florian Ebeling
florian.ebeling at gmail.com

From florian.ebeling at gmail.com  Tue Oct  7 08:09:59 2008
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Tue, 7 Oct 2008 17:09:59 +0200
Subject: Creating a new port
In-Reply-To: <2C480FD9-6163-4978-A821-F92DA7912C59@teti.ch>
References: <5F9CB650-F59B-45B6-9B3A-9D57E5BD3BF4@teti.ch>
	<5cbbe4ae0810070700h1067cc6fke9fc21fed709ec87@mail.gmail.com>
	<2C480FD9-6163-4978-A821-F92DA7912C59@teti.ch>
Message-ID: <5cbbe4ae0810070809s200527c9m7eaa9a37e0b32f48@mail.gmail.com>

On Tue, Oct 7, 2008 at 4:18 PM, Gaspard Bucher <gaspard at teti.ch> wrote:
>
> On 7 oct. 08, at 16:00, C. Florian Ebeling wrote:
>
>>> I would like to create a port to ease installation of zena (a ruby on
>>> rails based CMS, http://zenadmin.org). The idea is to
>>>
>>> 1. write the dependencies in a Portfile
>>>
>>> build-essential apache2 mysql-server libmagick9-dev gs-gpl libssl-dev
>>> gettext libgettext-ruby libreadline5 libreadline5-dev zlib1g-dev
>>> libncurses5 libncurses5-dev temcap-compat unzip liburi-perl jpeg tiff
>>> ruby rb-rubygems
>>>
>>> 2. trigger a script to install ruby gems, some with specified versions
>>>
>>> gem install gettext --version 1.90.0
>>> gem install RedCloth --version 3.0.4
>>> gem install rake mongrel mongrel_cluster rmagick tzinfo RedCloth
>>> syntax mongrel_upload_progress uuidtools daemons ruby-debug
>>> gem install --source http://www.loonsoft.com/recaptcha/pkg/ recaptcha
>>>
>>> 3. find a way to fetch zena sources somewhere in /opt/... (idealy with
>>> svn/git so it is easy to update the code)
>>>
>>> 4. install a script to start/stop/update zena
>>>
>>>
>>> Is all this a really bad idea because there are other (simpler) ways
>>> to achieve this ?
>>
>> all this is possible right now, with two exceptions:
>> - you cannot specify a gem version, you just have to
>> depend on the port-wrapped gem that is current with
>> macports.
>>
>> - git is not supported for fetching, but svn is.
>
> svn would be fine
>
>>
>>
>> the gem version requirements could be a problem
>> if they exist already and the maintainer is not willing
>> to switch to these versions. but i guess you want rather
>> new versions, and he should usually upgrade if you
>> ask, maybe even with a ticket + patch.
>
> Actually, no, I'm stuck with old ones due to a big redesign in RedCloth 4.
> To avoid this issue, I could include the code from
> these versions into the application's vendor directory (as it is done with
> rails). So that's not a problem.
>
>>
>> if the gem does not exist already, then you can just add
>> that as well and become maintainer. then you have
>> control over the version included in mp.
>
> From the existing ports list, the following gems would need to be added to
> macports:
> mongrel_upload_progress
> syntax
> tzinfo
> uuidtools
> recaptcha
>
>>
>> for starting and stopping there is support present in the
>> form of startup items, see the mp guide.
>>
>> the whole scenario is not a bad idea at all, but rather
>> pretty much the most common use case for mp :)
>>
>> to prepare the ruby ports you  want to use ruby port
>> group functionalty. you can pretty much have a whole
>> port file (or the interesting parts of it) covered by a single
>> call to ruby.setup function.
>
> I'll have to dive into tcl for this (totally unknown language for me). I
> also have to learn how ports src are organised.
>
> Before I jump deep in this, I have a first question about the rb-... ports.
> Why isn't this covered with calls using "gem" ? Is this to have control over
> which versions are included ? To make sure the sources are available during
> install ?

mp just wraps over gem in the case of a gem installation type.


>
> Anyway, thanks for your help, having a macports for zena would be really
> great because I keep getting questions about installation issues and it's
> not very interesting...
>
> I'd love to have a one line answer like:
>
> sudo port install zena

i will see that i put together a section on ruby.setup. might be on
the weekend though.

otherwise you have always the option to put a port request into the
issue tracker, but that does not garuantee you that it happens as
soon, unless zena is popular with mp users/maintainers. and it depends
on quit a few other new ports as well, which need to be added first.

Florian

ps. please use reply-all when responding to the list, mp-dev
does not set reploy-to header, as some other lists do. dont
question this policy, it is an emotional topic :)


>
> :-)
>
> Gaspard
>>
>>
>> unfortunately this call is not properly documented in the
>> guide. i wanted to do this but i didn't have the time right
>> now. you will rather have to look at other portfiles or
>> read the source:
>>
>>
>> http://trac.macports.org/browser/branches/release_1_6/base/src/port1.0/resources/group/ruby-1.0.tcl
>>
>>
>> Florian
>>
>>
>>
>> --
>> Florian Ebeling
>> florian.ebeling at gmail.com
>
>



-- 
Florian Ebeling
florian.ebeling at gmail.com

From gaspard at teti.ch  Tue Oct  7 08:16:01 2008
From: gaspard at teti.ch (Gaspard Bucher)
Date: Tue, 7 Oct 2008 17:16:01 +0200
Subject: Creating a new port
In-Reply-To: <5cbbe4ae0810070809s200527c9m7eaa9a37e0b32f48@mail.gmail.com>
References: <5F9CB650-F59B-45B6-9B3A-9D57E5BD3BF4@teti.ch>
	<5cbbe4ae0810070700h1067cc6fke9fc21fed709ec87@mail.gmail.com>
	<2C480FD9-6163-4978-A821-F92DA7912C59@teti.ch>
	<5cbbe4ae0810070809s200527c9m7eaa9a37e0b32f48@mail.gmail.com>
Message-ID: <AB2E4B80-4107-46BD-911B-67BB26869A7E@teti.ch>

I had a look at some ruby ports and all this seems to be workable  
quite easily. I am actually testing a clean reinstall
using macports into /Applications/zena.app/opt (just a test to see if  
producing a full binary could be an option). This
will give me the exact dependencies I need and let me test the setup  
before writing a port for zena.

Thanks for your help and ... I'll be back soon !

Gaspard

On 7 oct. 08, at 17:09, C. Florian Ebeling wrote:

> On Tue, Oct 7, 2008 at 4:18 PM, Gaspard Bucher <gaspard at teti.ch>  
> wrote:
>>
>> On 7 oct. 08, at 16:00, C. Florian Ebeling wrote:
>>
>>>> I would like to create a port to ease installation of zena (a  
>>>> ruby on
>>>> rails based CMS, http://zenadmin.org). The idea is to
>>>>
>>>> 1. write the dependencies in a Portfile
>>>>
>>>> build-essential apache2 mysql-server libmagick9-dev gs-gpl libssl- 
>>>> dev
>>>> gettext libgettext-ruby libreadline5 libreadline5-dev zlib1g-dev
>>>> libncurses5 libncurses5-dev temcap-compat unzip liburi-perl jpeg  
>>>> tiff
>>>> ruby rb-rubygems
>>>>
>>>> 2. trigger a script to install ruby gems, some with specified  
>>>> versions
>>>>
>>>> gem install gettext --version 1.90.0
>>>> gem install RedCloth --version 3.0.4
>>>> gem install rake mongrel mongrel_cluster rmagick tzinfo RedCloth
>>>> syntax mongrel_upload_progress uuidtools daemons ruby-debug
>>>> gem install --source http://www.loonsoft.com/recaptcha/pkg/  
>>>> recaptcha
>>>>
>>>> 3. find a way to fetch zena sources somewhere in /opt/... (idealy  
>>>> with
>>>> svn/git so it is easy to update the code)
>>>>
>>>> 4. install a script to start/stop/update zena
>>>>
>>>>
>>>> Is all this a really bad idea because there are other (simpler)  
>>>> ways
>>>> to achieve this ?
>>>
>>> all this is possible right now, with two exceptions:
>>> - you cannot specify a gem version, you just have to
>>> depend on the port-wrapped gem that is current with
>>> macports.
>>>
>>> - git is not supported for fetching, but svn is.
>>
>> svn would be fine
>>
>>>
>>>
>>> the gem version requirements could be a problem
>>> if they exist already and the maintainer is not willing
>>> to switch to these versions. but i guess you want rather
>>> new versions, and he should usually upgrade if you
>>> ask, maybe even with a ticket + patch.
>>
>> Actually, no, I'm stuck with old ones due to a big redesign in  
>> RedCloth 4.
>> To avoid this issue, I could include the code from
>> these versions into the application's vendor directory (as it is  
>> done with
>> rails). So that's not a problem.
>>
>>>
>>> if the gem does not exist already, then you can just add
>>> that as well and become maintainer. then you have
>>> control over the version included in mp.
>>
>> From the existing ports list, the following gems would need to be  
>> added to
>> macports:
>> mongrel_upload_progress
>> syntax
>> tzinfo
>> uuidtools
>> recaptcha
>>
>>>
>>> for starting and stopping there is support present in the
>>> form of startup items, see the mp guide.
>>>
>>> the whole scenario is not a bad idea at all, but rather
>>> pretty much the most common use case for mp :)
>>>
>>> to prepare the ruby ports you  want to use ruby port
>>> group functionalty. you can pretty much have a whole
>>> port file (or the interesting parts of it) covered by a single
>>> call to ruby.setup function.
>>
>> I'll have to dive into tcl for this (totally unknown language for  
>> me). I
>> also have to learn how ports src are organised.
>>
>> Before I jump deep in this, I have a first question about the  
>> rb-... ports.
>> Why isn't this covered with calls using "gem" ? Is this to have  
>> control over
>> which versions are included ? To make sure the sources are  
>> available during
>> install ?
>
> mp just wraps over gem in the case of a gem installation type.
>
>
>>
>> Anyway, thanks for your help, having a macports for zena would be  
>> really
>> great because I keep getting questions about installation issues  
>> and it's
>> not very interesting...
>>
>> I'd love to have a one line answer like:
>>
>> sudo port install zena
>
> i will see that i put together a section on ruby.setup. might be on
> the weekend though.
>
> otherwise you have always the option to put a port request into the
> issue tracker, but that does not garuantee you that it happens as
> soon, unless zena is popular with mp users/maintainers. and it depends
> on quit a few other new ports as well, which need to be added first.
>
> Florian
>
> ps. please use reply-all when responding to the list, mp-dev
> does not set reploy-to header, as some other lists do. dont
> question this policy, it is an emotional topic :)
>
>
>>
>> :-)
>>
>> Gaspard
>>>
>>>
>>> unfortunately this call is not properly documented in the
>>> guide. i wanted to do this but i didn't have the time right
>>> now. you will rather have to look at other portfiles or
>>> read the source:
>>>
>>>
>>> http://trac.macports.org/browser/branches/release_1_6/base/src/port1.0/resources/group/ruby-1.0.tcl
>>>
>>>
>>> Florian
>>>
>>>
>>>
>>> --
>>> Florian Ebeling
>>> florian.ebeling at gmail.com
>>
>>
>
>
>
> -- 
> Florian Ebeling
> florian.ebeling at gmail.com


From blair at orcaware.com  Tue Oct  7 12:04:57 2008
From: blair at orcaware.com (Blair Zajac)
Date: Tue, 7 Oct 2008 12:04:57 -0700
Subject: lzmautils and configure
Message-ID: <FB4504FF-1A78-413F-8095-524882782EAB@orcaware.com>

Hello,

I was building the new lzmautils and saw these warnings:

--->  Verifying checksum(s) for lzmautils
--->  Checksumming lzma-4.32.7.tar.gz
--->  Extracting lzmautils
--->  Extracting lzma-4.32.7.tar.gz
--->  Configuring lzmautils
configure: WARNING: Unrecognized options: --with-libiconv-prefix, -- 
with-libintl
-prefix


I then tried to change the Portfile to read

configure.args  --with-libiconv=${prefix} --with-libintl=${prefix}

but this also generates

Oct  7 11:37:02 orca1-internal /System/Library/CoreServices/ 
backupd[1110]: Start--->  Verifying checksum(s) for lzmautils
--->  Checksumming lzma-4.32.7.tar.gz
--->  Extracting lzmautils
--->  Extracting lzma-4.32.7.tar.gz
--->  Configuring lzmautils
configure: WARNING: Unrecognized options: --with-libiconv, --with- 
libintl

So I think having these doesn't help.

Also, doing a

$ port contents lzmautils | xargs otool -L | less

doesn't show anything linking against port:libiconv port:gettext, so  
do we need these?

Regards,
Blair

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



From afb at macports.org  Tue Oct  7 12:32:34 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Tue, 7 Oct 2008 21:32:34 +0200
Subject: lzmautils and configure
In-Reply-To: <FB4504FF-1A78-413F-8095-524882782EAB@orcaware.com>
References: <FB4504FF-1A78-413F-8095-524882782EAB@orcaware.com>
Message-ID: <8CC30833-9800-41C7-8752-B65D519C9F74@macports.org>

Blair Zajac wrote:

> I was building the new lzmautils and saw these warnings:
>
> --->  Verifying checksum(s) for lzmautils
> --->  Checksumming lzma-4.32.7.tar.gz
> --->  Extracting lzmautils
> --->  Extracting lzma-4.32.7.tar.gz
> --->  Configuring lzmautils
> configure: WARNING: Unrecognized options: --with-libiconv-prefix, -- 
> with-libintl
> -prefix

> Also, doing a
>
> $ port contents lzmautils | xargs otool -L | less
>
> doesn't show anything linking against port:libiconv port:gettext,  
> so do we need these?

They might only be needed by the newer version of lzmautils.
(i.e. the one currently residing in port "lzmautils-devel")

So could be noise...

--anders


From blair at orcaware.com  Tue Oct  7 12:44:18 2008
From: blair at orcaware.com (Blair Zajac)
Date: Tue, 7 Oct 2008 12:44:18 -0700
Subject: lzmautils and configure
In-Reply-To: <8CC30833-9800-41C7-8752-B65D519C9F74@macports.org>
References: <FB4504FF-1A78-413F-8095-524882782EAB@orcaware.com>
	<8CC30833-9800-41C7-8752-B65D519C9F74@macports.org>
Message-ID: <4382854D-22BA-4EF2-939B-BB2AE9ACB6EA@orcaware.com>


On Oct 7, 2008, at 12:32 PM, Anders F Bj?rklund wrote:

> Blair Zajac wrote:
>
>> I was building the new lzmautils and saw these warnings:
>>
>> --->  Verifying checksum(s) for lzmautils
>> --->  Checksumming lzma-4.32.7.tar.gz
>> --->  Extracting lzmautils
>> --->  Extracting lzma-4.32.7.tar.gz
>> --->  Configuring lzmautils
>> configure: WARNING: Unrecognized options: --with-libiconv-prefix, -- 
>> with-libintl
>> -prefix
>
>> Also, doing a
>>
>> $ port contents lzmautils | xargs otool -L | less
>>
>> doesn't show anything linking against port:libiconv port:gettext,  
>> so do we need these?
>
> They might only be needed by the newer version of lzmautils.
> (i.e. the one currently residing in port "lzmautils-devel")
>
> So could be noise...
>
> --anders

OK.  I see that they are used in the lzma-4.42.0alpha6 tarball.

Blair


From jmr at macports.org  Tue Oct  7 13:10:04 2008
From: jmr at macports.org (Joshua Root)
Date: Wed, 08 Oct 2008 07:10:04 +1100
Subject: Creating a new port
In-Reply-To: <5cbbe4ae0810070700h1067cc6fke9fc21fed709ec87@mail.gmail.com>
References: <5F9CB650-F59B-45B6-9B3A-9D57E5BD3BF4@teti.ch>
	<5cbbe4ae0810070700h1067cc6fke9fc21fed709ec87@mail.gmail.com>
Message-ID: <48EBC21C.3070708@macports.org>

C. Florian Ebeling wrote:
> - git is not supported for fetching, but svn is.

You can write your own fetch phase if you really need to use git. Also,
fetch.type git is available in trunk (not that that really helps right now).

- Josh

From florian.ebeling at gmail.com  Tue Oct  7 13:14:40 2008
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Tue, 7 Oct 2008 22:14:40 +0200
Subject: Creating a new port
In-Reply-To: <48EBC21C.3070708@macports.org>
References: <5F9CB650-F59B-45B6-9B3A-9D57E5BD3BF4@teti.ch>
	<5cbbe4ae0810070700h1067cc6fke9fc21fed709ec87@mail.gmail.com>
	<48EBC21C.3070708@macports.org>
Message-ID: <5cbbe4ae0810071314l2d18ac84r8b67089e23b3cc8f@mail.gmail.com>

On Tue, Oct 7, 2008 at 10:10 PM, Joshua Root <jmr at macports.org> wrote:
> C. Florian Ebeling wrote:
>> - git is not supported for fetching, but svn is.
>
> You can write your own fetch phase if you really need to use git.

that's one thing i would like to hear more about. how do you do that?
or can you point to an example portfile maybe? is the understanding
that you still have cached distfiles, or would you pull them regardless
what lies around already?

Florian



-- 
Florian Ebeling
florian.ebeling at gmail.com

From jmr at macports.org  Tue Oct  7 14:31:46 2008
From: jmr at macports.org (Joshua Root)
Date: Wed, 08 Oct 2008 08:31:46 +1100
Subject: Creating a new port
In-Reply-To: <5cbbe4ae0810071314l2d18ac84r8b67089e23b3cc8f@mail.gmail.com>
References: <5F9CB650-F59B-45B6-9B3A-9D57E5BD3BF4@teti.ch>	
	<5cbbe4ae0810070700h1067cc6fke9fc21fed709ec87@mail.gmail.com>	
	<48EBC21C.3070708@macports.org>
	<5cbbe4ae0810071314l2d18ac84r8b67089e23b3cc8f@mail.gmail.com>
Message-ID: <48EBD542.10003@macports.org>

C. Florian Ebeling wrote:
> On Tue, Oct 7, 2008 at 10:10 PM, Joshua Root <jmr at macports.org> wrote:
>> C. Florian Ebeling wrote:
>>> - git is not supported for fetching, but svn is.
>> You can write your own fetch phase if you really need to use git.
> 
> that's one thing i would like to hear more about. how do you do that?
> or can you point to an example portfile maybe? is the understanding
> that you still have cached distfiles, or would you pull them regardless
> what lies around already?

You'd do something like:

depends_build port:git-core

fetch {
    set git.url <whatever>
    system "cd ${workpath} && git clone ${git.url} ${worksrcdir}"
}

You could be a bit more clever by fetching to ${distpath} and copying to
${workpath} in extract, which would save cloning every time.

- Josh

From febeling at macports.org  Tue Oct  7 14:37:24 2008
From: febeling at macports.org (C. Florian Ebeling)
Date: Tue, 7 Oct 2008 23:37:24 +0200
Subject: Fwd: [40483] trunk/dports/erlang/mochiweb
In-Reply-To: <20081003135620.4B48746A3A6@beta.macosforge.org>
References: <20081003135620.4B48746A3A6@beta.macosforge.org>
Message-ID: <5cbbe4ae0810071437o1d29a89fi331252a58be603fe@mail.gmail.com>

---------- Forwarded message ----------
From:  <febeling at macports.org>
Date: Fri, Oct 3, 2008 at 3:56 PM
Subject: [40483] trunk/dports/erlang/mochiweb
To: macports-changes at lists.macosforge.org

+	xinstall -d -m 0755 ${privdir}/skel/priv/www
+	xinstall -d -m 0755 ${privdir}/skel/deps
+	xinstall -d -m 0755 ${privdir}/skel/docs
+	xinstall -d -m 0755 ${privdir}/skel/ebin
+	xinstall -d -m 0755 ${privdir}/skel/include
+	xinstall -d -m 0755 ${privdir}/skel/src
+	xinstall -d -m 0755 ${privdir}/skel/support
+	xinstall -m 0644 ${worksrcpath}/priv/skel/Makefile \
+		${privdir}/skel
+	eval xinstall -m 0644 [glob ${worksrcpath}/priv/skel/start*.sh] \
+		${privdir}/skel
+	eval xinstall -m 0644 ${worksrcpath}/priv/skel/priv/www/index.html \
+		${privdir}/skel/priv/www
+	eval xinstall -m 0644 [glob
${worksrcpath}/priv/skel/src/{Makefile,*.html,*.erl,*.hrl,*.app}] \
+		${privdir}/skel/src
+	xinstall -m 0644 ${worksrcpath}/priv/skel/support/include.mk \
+		${privdir}/skel/support

Recently I wanted to copy over a whole directory form worksrcpath
to destdir, and that turned out to be quite tedious. Is it possible to
do this any easier than this?

I noticed a construct for this task in the ruby port group file, so i guess
it is actually not available in general. Is that so? Wouldn't that be a
valuable addition? (Or is it maybe in trunk :)

I think this is quite a general thing, be it generated docs which you
want to  install, or sources in addition to compiled stuff. In the above
case it was just necessary resources.

Florian

-- 
Florian Ebeling
florian.ebeling at gmail.com

From jmr at macports.org  Tue Oct  7 14:47:15 2008
From: jmr at macports.org (Joshua Root)
Date: Wed, 08 Oct 2008 08:47:15 +1100
Subject: Fwd: [40483] trunk/dports/erlang/mochiweb
In-Reply-To: <5cbbe4ae0810071437o1d29a89fi331252a58be603fe@mail.gmail.com>
References: <20081003135620.4B48746A3A6@beta.macosforge.org>
	<5cbbe4ae0810071437o1d29a89fi331252a58be603fe@mail.gmail.com>
Message-ID: <48EBD8E3.3010104@macports.org>

C. Florian Ebeling wrote:
> ---------- Forwarded message ----------
> From:  <febeling at macports.org>
> Date: Fri, Oct 3, 2008 at 3:56 PM
> Subject: [40483] trunk/dports/erlang/mochiweb
> To: macports-changes at lists.macosforge.org
> 
> +	xinstall -d -m 0755 ${privdir}/skel/priv/www
> +	xinstall -d -m 0755 ${privdir}/skel/deps
> +	xinstall -d -m 0755 ${privdir}/skel/docs
> +	xinstall -d -m 0755 ${privdir}/skel/ebin
> +	xinstall -d -m 0755 ${privdir}/skel/include
> +	xinstall -d -m 0755 ${privdir}/skel/src
> +	xinstall -d -m 0755 ${privdir}/skel/support
> +	xinstall -m 0644 ${worksrcpath}/priv/skel/Makefile \
> +		${privdir}/skel
> +	eval xinstall -m 0644 [glob ${worksrcpath}/priv/skel/start*.sh] \
> +		${privdir}/skel
> +	eval xinstall -m 0644 ${worksrcpath}/priv/skel/priv/www/index.html \
> +		${privdir}/skel/priv/www
> +	eval xinstall -m 0644 [glob
> ${worksrcpath}/priv/skel/src/{Makefile,*.html,*.erl,*.hrl,*.app}] \
> +		${privdir}/skel/src
> +	xinstall -m 0644 ${worksrcpath}/priv/skel/support/include.mk \
> +		${privdir}/skel/support
> 
> Recently I wanted to copy over a whole directory form worksrcpath
> to destdir, and that turned out to be quite tedious. Is it possible to
> do this any easier than this?

"copy ${worksrcpath}/priv/skel ${privdir}/skel" should do it, unless
I've misunderstood?

- Josh

From jmr at macports.org  Tue Oct  7 20:59:08 2008
From: jmr at macports.org (Joshua Root)
Date: Wed, 08 Oct 2008 14:59:08 +1100
Subject: There is no release manager! There is no release manager!
In-Reply-To: <E5E779B3-CBC8-47F8-8A49-E990DAE7DF14@macports.org>
References: <3E95BC31-BCE9-4940-BA73-F5BAE02F9569@imem.cnr.it>	<0EDBB856-8EEE-4D3E-ACF7-44C6F9E9FD43@macports.org>	<7E2CDFE0-6318-4BDA-85F6-D609B4AE38FD@bellsouth.net>	<C8D8DA25-06F6-42D7-B3AC-89790830D63D@geeklair.net>	<2872F975-FFE5-4158-BE10-AF1D99FBB154@apple.com>	<3a73f7f00810061949q2d23e50u607741f53984c27f@mail.gmail.com>
	<E5E779B3-CBC8-47F8-8A49-E990DAE7DF14@macports.org>
Message-ID: <48EC300C.3010603@macports.org>

Anders F Bj?rklund wrote:
> Julio Biason wrote:
> 
>>> Perhaps we should send out some sort of announcement calling formally
>>> for volunteers for the position?
>> Oh, what the hell, I have plenty of time these days. What should a
>> Release Manager do?
> 
> There's a summary of some of the things that needs to be done at:
> http://trac.macports.org/browser/trunk/base/portmgr/ReleaseProcess

Additionally, before actually doing the release, the goals for the
release need to be laid out. A Trac milestone should be created and the
tickets which need to be resolved in order to meet the release goals
should be associated with it. Then developers will probably need to be
prodded in the right direction to get the tickets closed.

Of course, at this point there's probably far more good to be done by
releasing something very close to the current trunk than by delaying
further to get more fixes or features in.

And thank you very much for volunteering.

- Josh

From markd at macports.org  Tue Oct  7 21:12:07 2008
From: markd at macports.org (markd at macports.org)
Date: Tue, 07 Oct 2008 21:12:07 -0700
Subject: Need to resurrect the 1.2.x rrdtool port in the repository
Message-ID: <fc.004c4c58106bbead004c4c58106bbead.10762001@biola.edu>

It seems that the developer can't solve the mystery of the failed builds
of rrdtool > 1.3.2 and up on OS X 10.4, so I guess there is nothing else
to do but have an 'rrdtool12' port since the 1.2 series works ok.  Can
anyone give tips on getting that done in svn?

Mark


From blair at orcaware.com  Tue Oct  7 21:16:45 2008
From: blair at orcaware.com (Blair Zajac)
Date: Tue, 07 Oct 2008 21:16:45 -0700
Subject: Need to resurrect the 1.2.x rrdtool port in the repository
In-Reply-To: <fc.004c4c58106bbead004c4c58106bbead.10762001@biola.edu>
References: <fc.004c4c58106bbead004c4c58106bbead.10762001@biola.edu>
Message-ID: <48EC342D.3090600@orcaware.com>

markd at macports.org wrote:
> It seems that the developer can't solve the mystery of the failed builds
> of rrdtool > 1.3.2 and up on OS X 10.4, so I guess there is nothing else
> to do but have an 'rrdtool12' port since the 1.2 series works ok.  Can
> anyone give tips on getting that done in svn?

Find the last revision of rrdtool using svn log that had the 1.2.x port and do 
these.  It looks like 36855 is the youngest commit for 1.2.x.

$ cd net
$ svn cp -r 36855 
https://svn.macports.org/repository/macports/trunk/dports/net/rrdtool rrdtool12
$ cd rrdtool12
$ # rename port in Portfile
$ cd ..
$ svn commit

Regards,
Blair

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

From ryandesign at macports.org  Tue Oct  7 22:24:03 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 8 Oct 2008 00:24:03 -0500
Subject: Important: MacPorts PortMgr Changes
In-Reply-To: <CDC52471-1C3A-4799-8895-BAB650B028FF@macports.org>
References: <CDC52471-1C3A-4799-8895-BAB650B028FF@macports.org>
Message-ID: <8C0333BF-BC12-4C3D-AE32-D725B058262E@macports.org>

On Sep 30, 2008, at 11:18, James Berry wrote:

> As many of you know, MacPorts is loosely governed by the "PortMgr"
> team, which is currently made up of three people: Markus Weissmann,
> Juan Manual Palacios, and James Berry.
>
> We each love MacPorts, and hope to see it continue to prosper and grow
> in the future. And we want to continue to contribute to the success of
> MacPorts as our time and professional lives allow in the future.
>
> But we each also have other significant professional and personal
> commitments that have made it difficult for us to put what we feel is
> an appropriate amount of time, energy, and enthusiasm into MacPorts in
> recent months and years, to the extent that we feel that additional
> day-to-day leadership is needed to ensure continued success and growth
> for the MacPorts project.
>
> So we want to propose some ideas to get new leadership blood into
> MacPorts, while retaining the systemic knowledge and continuity that
> our continued presence can allow. We therefore want to put the
> following plan forward for community comment (and hopefully,
> thereafter, implementation):
>
> (1) That the MacPorts community elect a new slate of PortMgr
> individuals, probably three people, to continue to guide day-to-day
> MacPorts operations and direction.
>
> (2) That the three of us move into an Elder-council ("advisory board",
> "trustees", "steering committee", etc), which will continue to help
> out and give guidance as needed, and watch over the long-term health
> of MacPorts assets such as domains and finances.
>
> The idea for the Elder council is based on our experience in the last
> several years. We've hesitated to make changes to PortMgr because we
> didn't want to disrupt continuity, but that has meant that PortMgr has
> stagnated as year-by-year changes in our lives affected our respective
> abilities to effectively govern day to day. We (collectively) need the
> ability to make swifter more responsive changes at the PortMgr level,
> while also ensuring the longer term continuity of the community and
> the infrastructure it relies on.
>
> We propose that PortMgr members be appointed by the community and have
> full control of all day-to-day operations of MacPorts. The Elder
> council will give advice and help to PortMgr members as requested, or
> as they see fit, but will not have the ability to replace or remove
> PortMgr members: that responsibility lies with the community. The
> Elder council might from time to time add or remove its own members:
> it's primary function is to oversee the long-term health and direction
> of the project, including long-term assets such as finances and
> domains. We also see the Elder council as a broader group from which
> PortMgr can draw for help if its members become temporarily
> preoccupied with life.
>
> We have asked Jordan Hubbard, the father of MacPorts, to join us on
> the Elder Council, and he has given his tentative acceptance.
>
> We'd like to ask for community comment on this plan, following which
> we hope to call for new PortMgr nominations and election in the coming
> weeks.
>
> We believe that successful nominees for the portmgr positions will
> have demonstrated an active participation in the MacPorts community,
> will have the technical and organizational skills to help lead and
> direct the project, and will have the time, energy, and experience to
> make and inspire great contributions to the project.
>
> The PortMgr team: Markus, Juan, and James

Sounds like a good idea to me! I for one would be delighted to join  
the PortMgr team. I've been with the MacPorts project for three years  
and have been a committer for two years. I'm maintainer of over four  
dozen ports and have made some improvements to base as well. I try to  
keep an eye on the new unassigned tickets and try to resolve or  
assign them. I try to read every commit mail that comes through the  
changes list and provide constructive criticism. And of course I  
answer questions on the users and dev mailing lists. I also think I  
could be helpful with MacPorts releases, since I have both PowerPC  
and Intel Macs running all the versions of Mac OS X MacPorts  
supports. In short, if we agree to the plan Markus, Juan and James  
proposed and open up the floor for nominations for PortMgr  
membership, I would be honored to accept your nomination. :-)


From febeling at macports.org  Tue Oct  7 23:17:38 2008
From: febeling at macports.org (C. Florian Ebeling)
Date: Wed, 8 Oct 2008 08:17:38 +0200
Subject: Fwd: [40483] trunk/dports/erlang/mochiweb
In-Reply-To: <48EBD8E3.3010104@macports.org>
References: <20081003135620.4B48746A3A6@beta.macosforge.org>
	<5cbbe4ae0810071437o1d29a89fi331252a58be603fe@mail.gmail.com>
	<48EBD8E3.3010104@macports.org>
Message-ID: <5cbbe4ae0810072317t368c36aaqf9357d1e8551b1fa@mail.gmail.com>

>> Recently I wanted to copy over a whole directory form worksrcpath
>> to destdir, and that turned out to be quite tedious. Is it possible to
>> do this any easier than this?
>
> "copy ${worksrcpath}/priv/skel ${privdir}/skel" should do it, unless
> I've misunderstood?

hm, I thought I get leftover files after uninstall then, but maybe it's
just me who is complicated ... I ran into an image problem and was
just assuming that was the cause. I have to check it. Thanks :)

Florian



-- 
Florian Ebeling
florian.ebeling at gmail.com

From krischik at users.sourceforge.net  Tue Oct  7 23:30:39 2008
From: krischik at users.sourceforge.net (Martin Krischik)
Date: Wed, 8 Oct 2008 08:30:39 +0200
Subject: [Ticket #16549] gcc43: patch to add Ada support
Message-ID: <016F6894-7471-410B-8E3D-58DCB13034B2@users.sourceforge.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

The Trac Ticket #16549 [1] now open for 3 weeks  and it seem to be  
stalled. And it seems that the ticket is stalled over the fundamental  
problem on how to handle self hosted systems [2]. Now I still would  
like to go ahead so I would like to put the problem up for discussion.  
Both on user as well as development list, as both parties are affected  
on the possible outcome of discussion.

Now I hope there is an outcome, otherwise I'll be forces to "Plan-C":  
a complete fork into the GNU Ada Project [1]. Which at least for the  
potential users would be the worse outcome.

To understand the problem I suggest to read up the wikipedia page [2].  
As you see in a "normal" binary based distribution the normal users  
would never notice as the developers and packagers would take care of  
the difficult part. And they should have the experience as well to  
deal with it.

However MacPorts is source based so one need a "user friendly" which  
is a little trickier.

My current solution is a variant in gcc43 which can only be used when  
certain pre-condition are meed. However it was suggested that the  
Portfile should download and install everything needed on its own.  
That would result in a rather complex Portfile.

At compl.lang.ada it was suggested that a separate gnat Portfile so  
the gcc* maintainer is not burdened by this approach.

So what is everybody thinking.

Regards

Martin

[1] http://trac.macports.org/ticket/16549
[2] http://en.wikipedia.org/wiki/Self-hosting
[3] http://gnuada.sourceforge.net
- --
Martin Krischik
krischik at users.sourceforge.net

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iD8DBQFI7FOPijwKaHyem9cRAqrhAKDZ6I1YzhCUxNBwcVEsxT/tQEXmkQCfYXCG
E8mrybxOROepqAVRK8lIAk0=
=06w9
-----END PGP SIGNATURE-----

From ryandesign at macports.org  Tue Oct  7 23:38:51 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 8 Oct 2008 01:38:51 -0500
Subject: [40593] trunk/dports/lang/gcj34/Portfile
In-Reply-To: <20081008060313.E74294A8767@beta.macosforge.org>
References: <20081008060313.E74294A8767@beta.macosforge.org>
Message-ID: <3C51EE19-FDBE-42BD-B77E-2E00AB664BB7@macports.org>


On Oct 8, 2008, at 01:03, jmr at macports.org wrote:

> Revision: 40593
>           http://trac.macports.org/changeset/40593
> Author:   jmr at macports.org
> Date:     2008-10-07 23:03:12 -0700 (Tue, 07 Oct 2008)
> Log Message:
> -----------
> gcj34: remove use of cd
>
> Modified Paths:
> --------------
>     trunk/dports/lang/gcj34/Portfile
>
> Modified: trunk/dports/lang/gcj34/Portfile
> ===================================================================
> --- trunk/dports/lang/gcj34/Portfile	2008-10-08 03:52:39 UTC (rev  
> 40592)
> +++ trunk/dports/lang/gcj34/Portfile	2008-10-08 06:03:12 UTC (rev  
> 40593)
> @@ -49,25 +49,24 @@
>
>  # Since we install in a subdir dedicated to gcj, this gets it  
> visibility
>  post-destroot {
> -    cd ${destroot}${prefix}/${name}-${version}/share/man/
>      foreach n {1 7} {
>          foreach f [glob man${n}/*.${n}] {

Doesn't this glob now fail? The glob relied on the current directory  
being the man directory to find the man${n} directories. I think you  
want the "-directory" switch to the glob command.

http://tmml.sourceforge.net/doc/tcl/glob.html

> -            system "gzip -9 ${f}"
> +            system "cd ${destroot}${prefix}/${name}-${version}/ 
> share/man/ && gzip -9 ${f}"

And then you would revert this change, since ${f} will then contain  
the full path to the file.

I would test it on my PowerPC machine except I can't access it until  
tomorrow.

>          }
>      }

[snip]



From afb at macports.org  Tue Oct  7 23:46:14 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Wed, 8 Oct 2008 08:46:14 +0200
Subject: [Ticket #16549] gcc43: patch to add Ada support
In-Reply-To: <016F6894-7471-410B-8E3D-58DCB13034B2@users.sourceforge.net>
References: <016F6894-7471-410B-8E3D-58DCB13034B2@users.sourceforge.net>
Message-ID: <8F13C56D-5EA0-48F3-A9F1-125AF45D60EB@macports.org>

Martin Krischik wrote:

> The Trac Ticket #16549 [1] now open for 3 weeks  and it seem to be
> stalled. And it seems that the ticket is stalled over the fundamental
> problem on how to handle self hosted systems [2]. Now I still would
> like to go ahead so I would like to put the problem up for discussion.
> Both on user as well as development list, as both parties are affected
> on the possible outcome of discussion.

I don't really use the MacPorts versions of GCC (nor the ones of X11)
on Mac OS X, I did on Darwin OS but don't really bother with it now...
And for those languages that are _not_ available in Xcode Tools, like
the D programming language for instance, I use external installers...

Anyway, I can see how having a gcc port with Ada would be a good thing.

> However MacPorts is source based so one need a "user friendly" which
> is a little trickier.
>
> My current solution is a variant in gcc43 which can only be used when
> certain pre-condition are meed. However it was suggested that the
> Portfile should download and install everything needed on its own.
> That would result in a rather complex Portfile.

I'd go with the +macada variant. MacPorts uses outside stuff like
/usr/bin/gcc and /usr/X11R6 already, so it's even not that "dirty".
If you look at the "ghc" port, you'll see that it also uses an
available binary Mac distribution in order to bootstrap itself...

And sure, it's a lot trickier than your regular standard port.

--anders


From jmr at macports.org  Wed Oct  8 00:23:00 2008
From: jmr at macports.org (Joshua Root)
Date: Wed, 08 Oct 2008 18:23:00 +1100
Subject: [40593] trunk/dports/lang/gcj34/Portfile
In-Reply-To: <3C51EE19-FDBE-42BD-B77E-2E00AB664BB7@macports.org>
References: <20081008060313.E74294A8767@beta.macosforge.org>
	<3C51EE19-FDBE-42BD-B77E-2E00AB664BB7@macports.org>
Message-ID: <48EC5FD4.1040401@macports.org>

Ryan Schmidt wrote:
> 
> On Oct 8, 2008, at 01:03, jmr at macports.org wrote:
> 
>> Revision: 40593
>>           http://trac.macports.org/changeset/40593
>> Author:   jmr at macports.org
>> Date:     2008-10-07 23:03:12 -0700 (Tue, 07 Oct 2008)
>> Log Message:
>> -----------
>> gcj34: remove use of cd
>>
>> Modified Paths:
>> --------------
>>     trunk/dports/lang/gcj34/Portfile
>>
>> Modified: trunk/dports/lang/gcj34/Portfile
>> ===================================================================
>> --- trunk/dports/lang/gcj34/Portfile    2008-10-08 03:52:39 UTC (rev
>> 40592)
>> +++ trunk/dports/lang/gcj34/Portfile    2008-10-08 06:03:12 UTC (rev
>> 40593)
>> @@ -49,25 +49,24 @@
>>
>>  # Since we install in a subdir dedicated to gcj, this gets it visibility
>>  post-destroot {
>> -    cd ${destroot}${prefix}/${name}-${version}/share/man/
>>      foreach n {1 7} {
>>          foreach f [glob man${n}/*.${n}] {
> 
> Doesn't this glob now fail? The glob relied on the current directory
> being the man directory to find the man${n} directories. I think you
> want the "-directory" switch to the glob command.

Whoops, right you are.

- Josh

From febeling at macports.org  Wed Oct  8 00:40:35 2008
From: febeling at macports.org (C. Florian Ebeling)
Date: Wed, 8 Oct 2008 09:40:35 +0200
Subject: Important: MacPorts PortMgr Changes
In-Reply-To: <8C0333BF-BC12-4C3D-AE32-D725B058262E@macports.org>
References: <CDC52471-1C3A-4799-8895-BAB650B028FF@macports.org>
	<8C0333BF-BC12-4C3D-AE32-D725B058262E@macports.org>
Message-ID: <5cbbe4ae0810080040j4ac97343vf85d7d27ec801263@mail.gmail.com>

> In short, if we agree to the plan Markus, Juan and James
> proposed and open up the floor for nominations for PortMgr
> membership, I would be honored to accept your nomination. :-)

Ok, then I hereby officially nominate you :) I wanted to do that
anyway.

Also I would like to nominate the following members
(alphabetically ordered):
- Bryan Blackburn
- Rainer Mueller
- Joshua Root

Do the nominees accept the nomination? :)

All this provided that the suggested plan is accepted.
I don't know how we can officially establish acceptance
for such a plan, but I think there was largely consent,
so we should assume it is accepted. Am I wrong?

By the way, who was meant to be able to vote eventually?
All users or mailing list participants, or just maintainers/
members?

Florian

-- 
Florian Ebeling
florian.ebeling at gmail.com
febeling at macports.org

From ryandesign at macports.org  Wed Oct  8 00:53:24 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 8 Oct 2008 02:53:24 -0500
Subject: Important: MacPorts PortMgr Changes
In-Reply-To: <5cbbe4ae0810080040j4ac97343vf85d7d27ec801263@mail.gmail.com>
References: <CDC52471-1C3A-4799-8895-BAB650B028FF@macports.org>
	<8C0333BF-BC12-4C3D-AE32-D725B058262E@macports.org>
	<5cbbe4ae0810080040j4ac97343vf85d7d27ec801263@mail.gmail.com>
Message-ID: <4D54ADC7-BCB4-414B-B3DB-9C2976B29E20@macports.org>


On Oct 8, 2008, at 02:40, C. Florian Ebeling wrote:

>> In short, if we agree to the plan Markus, Juan and James
>> proposed and open up the floor for nominations for PortMgr
>> membership, I would be honored to accept your nomination. :-)
>
> Ok, then I hereby officially nominate you :) I wanted to do that
> anyway.

Thank you! :)

> Also I would like to nominate the following members
> (alphabetically ordered):
> - Bryan Blackburn
> - Rainer Mueller
> - Joshua Root
>
> Do the nominees accept the nomination? :)

I second all three of these nominations!



From jmpp at macports.org  Wed Oct  8 02:01:20 2008
From: jmpp at macports.org (Juan Manuel Palacios)
Date: Wed, 8 Oct 2008 04:31:20 -0430
Subject: Important: MacPorts PortMgr Changes
In-Reply-To: <5cbbe4ae0810080040j4ac97343vf85d7d27ec801263@mail.gmail.com>
References: <CDC52471-1C3A-4799-8895-BAB650B028FF@macports.org>
	<8C0333BF-BC12-4C3D-AE32-D725B058262E@macports.org>
	<5cbbe4ae0810080040j4ac97343vf85d7d27ec801263@mail.gmail.com>
Message-ID: <C4EDFED1-6363-4BB8-9FBA-306E4971BE51@macports.org>


On Oct 8, 2008, at 3:10 AM, C. Florian Ebeling wrote:

>> In short, if we agree to the plan Markus, Juan and James
>> proposed and open up the floor for nominations for PortMgr
>> membership, I would be honored to accept your nomination. :-)
>
> Ok, then I hereby officially nominate you :) I wanted to do that
> anyway.
>
> Also I would like to nominate the following members
> (alphabetically ordered):
> - Bryan Blackburn
> - Rainer Mueller
> - Joshua Root
>
> Do the nominees accept the nomination? :)
>
> All this provided that the suggested plan is accepted.
> I don't know how we can officially establish acceptance
> for such a plan, but I think there was largely consent,
> so we should assume it is accepted. Am I wrong?
>
> By the way, who was meant to be able to vote eventually?
> All users or mailing list participants, or just maintainers/
> members?
>
> Florian
>


	I would like to thank everyone who has participated in this very  
important thread for the comments they put forth and for, at least up  
until now, accepting and endorsing our proposed plan. Unless we  
experience any roadblocks from this point onward, I guess it's safe to  
say that Markus, James and I can now sit down to sort out the  
implementation details ASAP for sooner than later implementation.

	In any case, and as a personal draft note based on previous  
experience, I think the likelihood is that only active committers will  
be allowed to vote, for some definition of "active" that we'll  
certainly have to sort out; but in conclusion, no general public open  
voting. But in any case that's just me talking, so please don't take  
it as an official stance, not just yet.

	And with respect to nominations: it's very exciting to see people  
already warming up for the race, but if I may suggest anything it'd be  
to hold your horses a bit. For instance, PortMgr may come up with some  
sort of loose template through which we'd ask you to state to the  
public a couple of facts about yourself as the foundations for your  
ticket, or who knows what else, so until we have that sorted out it  
may not be too productive to have a potentially disordered influx of  
messages saying "I'm in!" in various different ways.

	I promise we'll get the plan fully ironed out pretty quick now, just  
hold your horses a bit longer! ;-)

	And, again, thanks to everyone for their participation and for  
continuously breathing life into the project!


> -- 
> Florian Ebeling
> florian.ebeling at gmail.com
> febeling at macports.org


	Regards,...


-jmpp

PS: Need I not say, we're open as always to suggestions on these  
implementation details we now need to iron out, like for instance on  
the couple of "maybe" cues I used as examples here.


From ryandesign at macports.org  Wed Oct  8 02:44:46 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 8 Oct 2008 04:44:46 -0500
Subject: [40604] trunk/dports/ruby/rb-rubycon/Portfile
In-Reply-To: <20081008081301.F3D274AB0B9@beta.macosforge.org>
References: <20081008081301.F3D274AB0B9@beta.macosforge.org>
Message-ID: <94153CE2-6505-4184-A26A-F416793217C0@macports.org>


On Oct 8, 2008, at 03:13, jmr at macports.org wrote:

> Revision: 40604
>           http://trac.macports.org/changeset/40604
> Author:   jmr at macports.org
> Date:     2008-10-08 01:13:00 -0700 (Wed, 08 Oct 2008)
> Log Message:
> -----------
> rb-rubycon: update checksums, master_sites and homepage; remove use  
> of cd

You updated the checksums without updating the version... so a  
stealth update occurred? If so, you must change the dist_subdir so  
that anyone who still had the old distfile will not now get a  
checksum error.

Is the installed product of this new 0.8 different from that of the  
old 0.8? If so, you must also increase the port revision so anyone  
who already had the old one installed will get informed of the update.


From raimue at macports.org  Wed Oct  8 04:04:40 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Wed, 08 Oct 2008 13:04:40 +0200
Subject: Important: MacPorts PortMgr Changes
In-Reply-To: <CDC52471-1C3A-4799-8895-BAB650B028FF@macports.org>
References: <CDC52471-1C3A-4799-8895-BAB650B028FF@macports.org>
Message-ID: <48EC93C8.7040705@macports.org>

James Berry wrote:
> So we want to propose some ideas to get new leadership blood into  
> MacPorts, while retaining the systemic knowledge and continuity that  
> our continued presence can allow. We therefore want to put the  
> following plan forward for community comment (and hopefully,  
> thereafter, implementation):
> 
> (1) That the MacPorts community elect a new slate of PortMgr  
> individuals, probably three people, to continue to guide day-to-day  
> MacPorts operations and direction.

I think it would be good to add a time limitation to the PortMgr status.
I propose to elect PortMgrs for the period of a year and hold a new
election every year.

This would allow existing PortMgrs to easily step back if they no longer
have much time for the project.

> (2) That the three of us move into an Elder-council ("advisory board",  
> "trustees", "steering committee", etc), which will continue to help  
> out and give guidance as needed, and watch over the long-term health  
> of MacPorts assets such as domains and finances.

I like this idea. Your experience and advice is still valuable!

Rainer

PS: It took some time to write this mail as I was a bit busy last week,
but finally I managed to do so.

From raimue at macports.org  Wed Oct  8 04:20:37 2008
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Wed, 08 Oct 2008 13:20:37 +0200
Subject: Important: MacPorts PortMgr Changes
In-Reply-To: <5cbbe4ae0810080040j4ac97343vf85d7d27ec801263@mail.gmail.com>
References: <CDC52471-1C3A-4799-8895-BAB650B028FF@macports.org>	
	<8C0333BF-BC12-4C3D-AE32-D725B058262E@macports.org>
	<5cbbe4ae0810080040j4ac97343vf85d7d27ec801263@mail.gmail.com>
Message-ID: <48EC9785.1050307@macports.org>

C. Florian Ebeling wrote:
>> In short, if we agree to the plan Markus, Juan and James
>> proposed and open up the floor for nominations for PortMgr
>> membership, I would be honored to accept your nomination. :-)
> 
> Ok, then I hereby officially nominate you :) I wanted to do that
> anyway.
> 
> Also I would like to nominate the following members
> (alphabetically ordered):
> - Bryan Blackburn
> - Rainer Mueller
> - Joshua Root
> 
> Do the nominees accept the nomination? :)

Yes, of course. Thank you, I am proud to be nominated.

I realize that I am now with MacPorts for more than 1.5 years and I
still enjoy working on it. I hope I have gathered enough experience with
this project in this time to become a PortMgr :-)

> All this provided that the suggested plan is accepted.
> I don't know how we can officially establish acceptance
> for such a plan, but I think there was largely consent,
> so we should assume it is accepted. Am I wrong?

Once we get an election plan it should be written down somewhere in the
wiki (or even in the guide?) for reference. At least nobody had
objections yet, so this is kind of accepted.

> By the way, who was meant to be able to vote eventually?
> All users or mailing list participants, or just maintainers/
> members?

We could restrict it to people listed on MacPortsDevelopers [1],
although some of them seem to be inactive. And we have other people
caring about MacPorts who are not developers.

Rainer

[1] http://trac.macports.org/wiki/MacPortsDevelopers

From jkh at apple.com  Wed Oct  8 05:55:41 2008
From: jkh at apple.com (Jordan K. Hubbard)
Date: Wed, 8 Oct 2008 05:55:41 -0700
Subject: Hey, I would like to propose that we cut the gordian knot.
In-Reply-To: <5cbbe4ae0810080040j4ac97343vf85d7d27ec801263@mail.gmail.com>
References: <CDC52471-1C3A-4799-8895-BAB650B028FF@macports.org>
	<8C0333BF-BC12-4C3D-AE32-D725B058262E@macports.org>
	<5cbbe4ae0810080040j4ac97343vf85d7d27ec801263@mail.gmail.com>
Message-ID: <658735B6-2E1C-45BF-B17A-D043C08B8757@apple.com>

(http://en.wikipedia.org/wiki/Gordian_knot)

Having just read jmpp's request for "a bit more time" to sort out a  
voting process, I must confess to feeling more trepidation than  
assurance.  To be completely fair, he does note several times that he  
and the rest of the moribund portmgr team would like to move quickly,  
but given the degree to which that group has also demonstrated itself  
to be overworked and less than involved in the day to day affairs of  
MacPorts, anything which delays a solution also runs the risk of  
blunting some of the current enthusiasm should said "process" end up  
dragging out longer than anticipated (which, as experience amply  
suggests, it invariably does) and I honestly don't think we can afford  
that at this late stage.

I would therefore like to suggest that we simply ratify the following  
list rather than dragging out a lengthy "voting" process for a set of  
positions which, from a certain angle, might even be viewed as largely  
ceremonial since there is no real "power" afforded by membership in  
the portmgr team.   Volunteers will always choose to follow (or not)  
such a group on the basis of the credibility of its individual members  
rather than any fancy paper hats they may be wearing, and the sooner  
we simply slam those hats on some credible heads and say "Thank you!   
Get started!", the sooner we can all get back to discussing the real  
question of how to get to where we need to go next.

As a courtesy to the outgoing portmgr team, I would also be perfectly  
happy to see them be the official "ratifiers" of this new team,  
assuming it passes their sniff test and they're also willing to do so  
in the next day or two, otherwise I would be just as happy with a  
statement along the lines of "if there are no significant, well-argued  
objections in the next 72 hours, they're it!  Quick, before they  
change their minds!" :-)

Portmgr (subject to individual acceptance, of course - we still  
haven't heard from two of the four):
Ryan Schmidt
Bryan Blackburn
Rainer Mueller
Joshua Root
[Note:  Any subset of the above would also be acceptable - 4 is not  
some magic minimum number, for all the reasons I've already outlined]

Release engineering team:
Ryan Schmidt (interim or longer, if he wants it)
Julio Biason

I'm really not trying to undercut anyone here, least of all jmpp, but  
seriously folks - we've been suffering from a leadership/directional  
vacuum for quite some time now and I don't think we need to bog down  
the only solution to be offered in quite some time by getting all  
constitutional about it or saying "hey, wait, let's all think about  
this for awhile and engage in lengthy discussion!"    That might have  
been a good plan of action about a year ago, and I would be also more  
than happy to see the "new portmgr" establish a framework for  
elections and term limits and all the other checks and balances that  
they might wish to create for future generations, but what we need  
right now is an immediate "interim government" and some long overdue  
action on the release engineering front.

Any objections?

- Jordan

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

From jberry at macports.org  Wed Oct  8 07:42:16 2008
From: jberry at macports.org (James Berry)
Date: Wed, 8 Oct 2008 07:42:16 -0700
Subject: [macports-mgr] Hey,
	I would like to propose that we cut the gordian knot.
In-Reply-To: <658735B6-2E1C-45BF-B17A-D043C08B8757@apple.com>
References: <CDC52471-1C3A-4799-8895-BAB650B028FF@macports.org>
	<8C0333BF-BC12-4C3D-AE32-D725B058262E@macports.org>
	<5cbbe4ae0810080040j4ac97343vf85d7d27ec801263@mail.gmail.com>
	<658735B6-2E1C-45BF-B17A-D043C08B8757@apple.com>
Message-ID: <B17BD218-88AC-45D1-A521-A4F59B43B248@macports.org>

Hi Jordan,

As usual, you work well to cut through the bureaucracy ;) I'm not so  
opposed to going along with your suggestion to just get this thing  
done, or that an official "vote" may be superflous. But I also think  
it's premature to assume that the list of nominees so far, is  
complete, given that we haven't called for nominees (or "interested  
parties") yet.

So I'd like to request that anybody interested in PortMgr announce  
their intent (via nomination, or not) by the close of this Friday.

James

On Oct 8, 2008, at 5:55 AM, Jordan K. Hubbard wrote:

> (http://en.wikipedia.org/wiki/Gordian_knot)
>
> Having just read jmpp's request for "a bit more time" to sort out a  
> voting process, I must confess to feeling more trepidation than  
> assurance.  To be completely fair, he does note several times that  
> he and the rest of the moribund portmgr team would like to move  
> quickly, but given the degree to which that group has also  
> demonstrated itself to be overworked and less than involved in the  
> day to day affairs of MacPorts, anything which delays a solution  
> also runs the risk of blunting some of the current enthusiasm should  
> said "process" end up dragging out longer than anticipated (which,  
> as experience amply suggests, it invariably does) and I honestly  
> don't think we can afford that at this late stage.
>
> I would therefore like to suggest that we simply ratify the  
> following list rather than dragging out a lengthy "voting" process  
> for a set of positions which, from a certain angle, might even be  
> viewed as largely ceremonial since there is no real "power" afforded  
> by membership in the portmgr team.   Volunteers will always choose  
> to follow (or not) such a group on the basis of the credibility of  
> its individual members rather than any fancy paper hats they may be  
> wearing, and the sooner we simply slam those hats on some credible  
> heads and say "Thank you!  Get started!", the sooner we can all get  
> back to discussing the real question of how to get to where we need  
> to go next.
>
> As a courtesy to the outgoing portmgr team, I would also be  
> perfectly happy to see them be the official "ratifiers" of this new  
> team, assuming it passes their sniff test and they're also willing  
> to do so in the next day or two, otherwise I would be just as happy  
> with a statement along the lines of "if there are no significant,  
> well-argued objections in the next 72 hours, they're it!  Quick,  
> before they change their minds!" :-)
>
> Portmgr (subject to individual acceptance, of course - we still  
> haven't heard from two of the four):
> Ryan Schmidt
> Bryan Blackburn
> Rainer Mueller
> Joshua Root
> [Note:  Any subset of the above would also be acceptable - 4 is not  
> some magic minimum number, for all the reasons I've already outlined]
>
> Release engineering team:
> Ryan Schmidt (interim or longer, if he wants it)
> Julio Biason
>
> I'm really not trying to undercut anyone here, least of all jmpp,  
> but seriously folks - we've been suffering from a leadership/ 
> directional vacuum for quite some time now and I don't think we need  
> to bog down the only solution to be offered in quite some time by  
> getting all constitutional about it or saying "hey, wait, let's all  
> think about this for awhile and engage in lengthy discussion!"     
> That might have been a good plan of action about a year ago, and I  
> would be also more than happy to see the "new portmgr" establish a  
> framework for elections and term limits and all the other checks and  
> balances that they might wish to create for future generations, but  
> what we need right now is an immediate "interim government" and some  
> long overdue action on the release engineering front.
>
> Any objections?
>
> - Jordan
>
> _______________________________________________
> macports-mgr mailing list
> macports-mgr at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-mgr

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20081008/dfe7e8da/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2761 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20081008/dfe7e8da/attachment.bin 

From jberry at macports.org  Wed Oct  8 07:49:32 2008
From: jberry at macports.org (James Berry)
Date: Wed, 8 Oct 2008 07:49:32 -0700
Subject: Call for PortMgr interest/nominations
Message-ID: <73A3849F-1DAB-44FE-BF91-5B4F8365A8B9@macports.org>

Per my previous note to Jordan, I'd like to set a deadline of this  
coming Friday, Oct 10, for those wishing to be part of the new PortMgr  
slate. If you are interested in these posts, please express your  
interest, or ask somebody to nominate you, by that time.

In throwing in your hat, or accepting a nomination, I think it would  
be appropriate to include a paragraph or so about what makes you want  
to be involved, and why we should care ;) Such notices should be given  
in email to the MacPorts development list. If you have already written  
such a note, you don't need to do so again.

Based on the amount of interest, we'll decide on an appropriate way to  
select the new slate.

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

From febeling at macports.org  Wed Oct  8 08:15:17 2008
From: febeling at macports.org (C. Florian Ebeling)
Date: Wed, 8 Oct 2008 17:15:17 +0200
Subject: Hey, I would like to propose that we cut the gordian knot.
In-Reply-To: <658735B6-2E1C-45BF-B17A-D043C08B8757@apple.com>
References: <CDC52471-1C3A-4799-8895-BAB650B028FF@macports.org>
	<8C0333BF-BC12-4C3D-AE32-D725B058262E@macports.org>
	<5cbbe4ae0810080040j4ac97343vf85d7d27ec801263@mail.gmail.com>
	<658735B6-2E1C-45BF-B17A-D043C08B8757@apple.com>
Message-ID: <5cbbe4ae0810080815k6dc6ef4dj7504c814cf9a11e4@mail.gmail.com>

Well spoken, Jordan!

On Wed, Oct 8, 2008 at 2:55 PM, Jordan K. Hubbard <jkh at apple.com> wrote:
> (http://en.wikipedia.org/wiki/Gordian_knot)
> Having just read jmpp's request for "a bit more time" to sort out a voting
> process, I must confess to feeling more trepidation than assurance.  To be
> completely fair, he does note several times that he and the rest of the
> moribund portmgr team would like to move quickly, but given the degree to
> which that group has also demonstrated itself to be overworked and less than
> involved in the day to day affairs of MacPorts, anything which delays a
> solution also runs the risk of blunting some of the current enthusiasm
> should said "process" end up dragging out longer than anticipated (which, as
> experience amply suggests, it invariably does) and I honestly don't think we
> can afford that at this late stage.
> I would therefore like to suggest that we simply ratify the following list
> rather than dragging out a lengthy "voting" process for a set of positions
> which, from a certain angle, might even be viewed as largely ceremonial
> since there is no real "power" afforded by membership in the portmgr team.
> Volunteers will always choose to follow (or not) such a group on the basis
> of the credibility of its individual members rather than any fancy paper
> hats they may be wearing, and the sooner we simply slam those hats on some
> credible heads and say "Thank you!  Get started!", the sooner we can all get
> back to discussing the real question of how to get to where we need to go
> next.
> As a courtesy to the outgoing portmgr team, I would also be perfectly happy
> to see them be the official "ratifiers" of this new team, assuming it passes
> their sniff test and they're also willing to do so in the next day or two,
> otherwise I would be just as happy with a statement along the lines of "if
> there are no significant, well-argued objections in the next 72 hours,
> they're it!  Quick, before they change their minds!" :-)
> Portmgr (subject to individual acceptance, of course - we still haven't
> heard from two of the four):
> Ryan Schmidt
> Bryan Blackburn
> Rainer Mueller
> Joshua Root
> [Note:  Any subset of the above would also be acceptable - 4 is not some
> magic minimum number, for all the reasons I've already outlined]
> Release engineering team:
> Ryan Schmidt (interim or longer, if he wants it)
> Julio Biason
> I'm really not trying to undercut anyone here, least of all jmpp, but
> seriously folks - we've been suffering from a leadership/directional vacuum
> for quite some time now and I don't think we need to bog down the only
> solution to be offered in quite some time by getting all constitutional
> about it or saying "hey, wait, let's all think about this for awhile and
> engage in lengthy discussion!"    That might have been a good plan of action
> about a year ago, and I would be also more than happy to see the "new
> portmgr" establish a framework for elections and term limits and all the
> other checks and balances that they might wish to create for future
> generations, but what we need right now is an immediate "interim government"
> and some long overdue action on the release engineering front.
> Any objections?
> - Jordan
>
> _______________________________________________
> macports-users mailing list
> macports-users at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
>
>



-- 
Florian Ebeling
florian.ebeling at gmail.com

From jmr at macports.org  Wed Oct  8 11:37:22 2008
From: jmr at macports.org (Joshua Root)
Date: Thu, 09 Oct 2008 05:37:22 +1100
Subject: [40604] trunk/dports/ruby/rb-rubycon/Portfile
In-Reply-To: <94153CE2-6505-4184-A26A-F416793217C0@macports.org>
References: <20081008081301.F3D274AB0B9@beta.macosforge.org>
	<94153CE2-6505-4184-A26A-F416793217C0@macports.org>
Message-ID: <48ECFDE2.6020206@macports.org>

Ryan Schmidt wrote:
> 
> On Oct 8, 2008, at 03:13, jmr at macports.org wrote:
> 
>> Revision: 40604
>>           http://trac.macports.org/changeset/40604
>> Author:   jmr at macports.org
>> Date:     2008-10-08 01:13:00 -0700 (Wed, 08 Oct 2008)
>> Log Message:
>> -----------
>> rb-rubycon: update checksums, master_sites and homepage; remove use of cd
> 
> You updated the checksums without updating the version... so a stealth
> update occurred? If so, you must change the dist_subdir so that anyone
> who still had the old distfile will not now get a checksum error.
> 
> Is the installed product of this new 0.8 different from that of the old
> 0.8? If so, you must also increase the port revision so anyone who
> already had the old one installed will get informed of the update.

The extract.suffix changed too so I figured it would be OK. I have no
clue what else may have changed, as the old zip distfile is nowhere to
be found.

- Josh

From ryandesign at macports.org  Wed Oct  8 12:11:07 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 8 Oct 2008 14:11:07 -0500
Subject: [40604] trunk/dports/ruby/rb-rubycon/Portfile
In-Reply-To: <48ECFDE2.6020206@macports.org>
References: <20081008081301.F3D274AB0B9@beta.macosforge.org>
	<94153CE2-6505-4184-A26A-F416793217C0@macports.org>
	<48ECFDE2.6020206@macports.org>
Message-ID: <18578F64-10CE-47EE-91A3-3C924127135C@macports.org>


On Oct 8, 2008, at 13:37, Joshua Root wrote:

> Ryan Schmidt wrote:
>
>> On Oct 8, 2008, at 03:13, jmr at macports.org wrote:
>>
>>> Revision: 40604
>>>           http://trac.macports.org/changeset/40604
>>> Author:   jmr at macports.org
>>> Date:     2008-10-08 01:13:00 -0700 (Wed, 08 Oct 2008)
>>> Log Message:
>>> -----------
>>> rb-rubycon: update checksums, master_sites and homepage; remove  
>>> use of cd
>>
>> You updated the checksums without updating the version... so a  
>> stealth
>> update occurred? If so, you must change the dist_subdir so that  
>> anyone
>> who still had the old distfile will not now get a checksum error.
>>
>> Is the installed product of this new 0.8 different from that of  
>> the old
>> 0.8? If so, you must also increase the port revision so anyone who
>> already had the old one installed will get informed of the update.
>
> The extract.suffix changed too so I figured it would be OK.

Oh yes, sorry, I missed that; then that's fine.

> I have no
> clue what else may have changed, as the old zip distfile is nowhere to
> be found.

I can't find it either. No results for "rubycon-0.8-src.zip" on  
Google. I guess we can assume it's just a repackaging of the same  
software. So then no additional changes needed after all. /me goes  
away...



From ryandesign at macports.org  Wed Oct  8 16:15:12 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 8 Oct 2008 18:15:12 -0500
Subject: [40614] trunk/dports/devel
In-Reply-To: <20081008131025.AE8C24AC601@beta.macosforge.org>
References: <20081008131025.AE8C24AC601@beta.macosforge.org>
Message-ID: <116CF6D6-F78C-4F7B-A87C-74D9420D42B3@macports.org>

On Oct 8, 2008, at 08:10, jann at macports.org wrote:

> Revision: 40614
>           http://trac.macports.org/changeset/40614
> Author:   jann at macports.org
> Date:     2008-10-08 06:10:23 -0700 (Wed, 08 Oct 2008)
> Log Message:
> -----------
> New port: Spin


> +build       {
> +    cd ${worksrcpath}/Src${version}
> +    exec make
> +}


The "cd" command has been deleted from MacPorts and will be  
unavailable in a future version, so you should not use it. But why  
override the build phase at all? It runs make by default. If the  
target "all" is the problem, set the target to empty by replacing the  
above lines with "build.target" (with no value after it).


From ryandesign at macports.org  Wed Oct  8 16:19:25 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 8 Oct 2008 18:19:25 -0500
Subject: Creating a new port
In-Reply-To: <AB2E4B80-4107-46BD-911B-67BB26869A7E@teti.ch>
References: <5F9CB650-F59B-45B6-9B3A-9D57E5BD3BF4@teti.ch>
	<5cbbe4ae0810070700h1067cc6fke9fc21fed709ec87@mail.gmail.com>
	<2C480FD9-6163-4978-A821-F92DA7912C59@teti.ch>
	<5cbbe4ae0810070809s200527c9m7eaa9a37e0b32f48@mail.gmail.com>
	<AB2E4B80-4107-46BD-911B-67BB26869A7E@teti.ch>
Message-ID: <4353AC48-5813-4E74-BE82-EEAB0DB6269B@macports.org>


On Oct 7, 2008, at 10:16, Gaspard Bucher wrote:

> I had a look at some ruby ports and all this seems to be workable
> quite easily. I am actually testing a clean reinstall
> using macports into /Applications/zena.app/opt (just a test to see if
> producing a full binary could be an option). This
> will give me the exact dependencies I need and let me test the setup
> before writing a port for zena.

The correct path to install MacPorts applications to is in the  
variable ${applications_dir}. This exists as of MacPorts 1.7.0 which  
is not yet released. Until it is, follow a strategy as in the port  
lisaem, where you set that variable to its default value if it is not  
already set to something.


From jmr at macports.org  Wed Oct  8 17:30:21 2008
From: jmr at macports.org (Joshua Root)
Date: Thu, 09 Oct 2008 11:30:21 +1100
Subject: There is no release manager! There is no release manager!
In-Reply-To: <016E33BD-1574-4BB7-A8FB-9190D8995268@macports.org>
References: <aeca57d90810071936w53dd35b1m6ad6229bcb5417ef@mail.gmail.com>
	<016E33BD-1574-4BB7-A8FB-9190D8995268@macports.org>
Message-ID: <48ED509D.5080605@macports.org>

Ryan Schmidt wrote:
> For the next release, I think we need version 1.7.0, not 1.6.1,  
> because there are countless new features and a year's worth of bug  
> fixes. That much work deserves more than just a bugfix version number  
> increase. That means we release from trunk, not the 1.6 branch.

So shall we close all the fixed tickets that have been left open pending
the fix being merged into the release branch?

> A  
> concern of mine is that the 1.6 branch contains some work that was  
> done only there and not on trunk. I believe some of it was done on  
> trunk in a different way, but I don't know if all changes from the  
> 1.6 branch got put in trunk. Someone needs to figure out whether it  
> was, and if not, identify what needs to be ported from 1.6 to trunk.  
> Ideally that would happen before a 1.7.0 release.

I believe the only work done on the 1.6 branch was in the postflight
script, and IIRC, Rainer merged that back into trunk.

- Josh

From raimue at macports.org  Wed Oct  8 19:53:56 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 09 Oct 2008 04:53:56 +0200
Subject: There is no release manager! There is no release manager!
In-Reply-To: <48ED509D.5080605@macports.org>
References: <aeca57d90810071936w53dd35b1m6ad6229bcb5417ef@mail.gmail.com>	<016E33BD-1574-4BB7-A8FB-9190D8995268@macports.org>
	<48ED509D.5080605@macports.org>
Message-ID: <48ED7244.6@macports.org>

Joshua Root wrote:
> I believe the only work done on the 1.6 branch was in the postflight
> script, and IIRC, Rainer merged that back into trunk.

Yes, the fixed postflight script is already on trunk.

Rainer

From ryandesign at macports.org  Wed Oct  8 23:42:40 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 9 Oct 2008 01:42:40 -0500
Subject: Creating a new port
In-Reply-To: <917242BC-72EB-4FF4-996B-830853714CB6@teti.ch>
References: <5F9CB650-F59B-45B6-9B3A-9D57E5BD3BF4@teti.ch>
	<5cbbe4ae0810070700h1067cc6fke9fc21fed709ec87@mail.gmail.com>
	<2C480FD9-6163-4978-A821-F92DA7912C59@teti.ch>
	<5cbbe4ae0810070809s200527c9m7eaa9a37e0b32f48@mail.gmail.com>
	<AB2E4B80-4107-46BD-911B-67BB26869A7E@teti.ch>
	<4353AC48-5813-4E74-BE82-EEAB0DB6269B@macports.org>
	<917242BC-72EB-4FF4-996B-830853714CB6@teti.ch>
Message-ID: <F0B9F56D-B71C-4135-BF9B-D54E1FD208E6@macports.org>


On Oct 9, 2008, at 01:15, Gaspard Bucher wrote:

> I think you misunderstood my experiment. I am install ALL ports  
> into /Applications/zena.app/opt instead of /opt. This should  
> produce a drag&drop binary
> with all dependencies. (It's just an experiment to use macports as  
> a way to produce a binary package).

Sorry, yes, I did misunderstand.

I don't think your plan is a good idea.

MacPorts is designed for users to install software on their machines.  
It is not designed to be used by application developers to distribute  
their own software.

Software installed with MacPorts is largely not relocatable. That  
means if you install in the prefix /Applications/zena.app/opt, that  
prefix is hardcoded into everything you build. Mac users expect to be  
able to rename their applications or put them in a place other than / 
Applications ($HOME/Applications is a common alternative choice), but  
they would not be able to do so if your app needs to use a MacPorts  
installation that's inside the app's bundle.


> For the "zena" port itself, I will not need to install any  
> application (just a script in /$prefix/local/bin).

The default MacPorts prefix is "/opt/local" (not "opt") thus your  
script would be in ${prefix}/bin.


P.S: Please remember to Reply All so your reply goes to the list too,  
not just to me.


From gaspard at teti.ch  Thu Oct  9 00:03:54 2008
From: gaspard at teti.ch (Gaspard Bucher)
Date: Thu, 9 Oct 2008 09:03:54 +0200
Subject: Creating a new port
In-Reply-To: <F0B9F56D-B71C-4135-BF9B-D54E1FD208E6@macports.org>
References: <5F9CB650-F59B-45B6-9B3A-9D57E5BD3BF4@teti.ch>
	<5cbbe4ae0810070700h1067cc6fke9fc21fed709ec87@mail.gmail.com>
	<2C480FD9-6163-4978-A821-F92DA7912C59@teti.ch>
	<5cbbe4ae0810070809s200527c9m7eaa9a37e0b32f48@mail.gmail.com>
	<AB2E4B80-4107-46BD-911B-67BB26869A7E@teti.ch>
	<4353AC48-5813-4E74-BE82-EEAB0DB6269B@macports.org>
	<917242BC-72EB-4FF4-996B-830853714CB6@teti.ch>
	<F0B9F56D-B71C-4135-BF9B-D54E1FD208E6@macports.org>
Message-ID: <1E73D69E-5191-47A6-A313-DA66769A3179@teti.ch>

Sorry for the reply-all (I'll make an effort to remember to use it).

I abandoned the idea of macporting to /Applications/zena.app/... For  
those who do not want to compile, I'll try to adapt http:// 
www.mamp.info to include ruby stuff (they hard code the location into  
the configure scritps of PHP, mysql et al). Hard coding to / 
Application/MAMP/Library/... can be seen as a bad idea, but if it  
eases deployment to none tech-savvy users that will not try to  
relocate, then why not.

Anyway, I'll start putting energy in a zena portfile to start with.

Gaspard
>
> On Oct 9, 2008, at 01:15, Gaspard Bucher wrote:
>
>> I think you misunderstood my experiment. I am install ALL ports  
>> into /Applications/zena.app/opt instead of /opt. This should  
>> produce a drag&drop binary
>> with all dependencies. (It's just an experiment to use macports as  
>> a way to produce a binary package).
>
> Sorry, yes, I did misunderstand.
>
> I don't think your plan is a good idea.
>
> MacPorts is designed for users to install software on their  
> machines. It is not designed to be used by application developers to  
> distribute their own software.
>
> Software installed with MacPorts is largely not relocatable. That  
> means if you install in the prefix /Applications/zena.app/opt, that  
> prefix is hardcoded into everything you build. Mac users expect to  
> be able to rename their applications or put them in a place other  
> than /Applications ($HOME/Applications is a common alternative  
> choice), but they would not be able to do so if your app needs to  
> use a MacPorts installation that's inside the app's bundle.
>
>
>> For the "zena" port itself, I will not need to install any  
>> application (just a script in /$prefix/local/bin).
>
> The default MacPorts prefix is "/opt/local" (not "opt") thus your  
> script would be in ${prefix}/bin.
>
>
> P.S: Please remember to Reply All so your reply goes to the list  
> too, not just to me.
>


From febeling at macports.org  Thu Oct  9 06:32:05 2008
From: febeling at macports.org (C. Florian Ebeling)
Date: Thu, 9 Oct 2008 15:32:05 +0200
Subject: Fwd: [40483] trunk/dports/erlang/mochiweb
In-Reply-To: <5cbbe4ae0810072317t368c36aaqf9357d1e8551b1fa@mail.gmail.com>
References: <20081003135620.4B48746A3A6@beta.macosforge.org>
	<5cbbe4ae0810071437o1d29a89fi331252a58be603fe@mail.gmail.com>
	<48EBD8E3.3010104@macports.org>
	<5cbbe4ae0810072317t368c36aaqf9357d1e8551b1fa@mail.gmail.com>
Message-ID: <5cbbe4ae0810090632xbd7338bld8d71aa63be24f38@mail.gmail.com>

On Wed, Oct 8, 2008 at 8:17 AM, C. Florian Ebeling
<febeling at macports.org> wrote:
>>> Recently I wanted to copy over a whole directory form worksrcpath
>>> to destdir, and that turned out to be quite tedious. Is it possible to
>>> do this any easier than this?
>>
>> "copy ${worksrcpath}/priv/skel ${privdir}/skel" should do it, unless
>> I've misunderstood?

true actually :)  was confused.

I have another problem now, though. since its a svn checkout, by simply
copying i get all these crappy little .svn directories plus their content.
something like an -exclude PATTERN doesn't seem to exist though.
Any idea for that additional problem? :)

Gruss,
Florian




-- 
Florian Ebeling
florian.ebeling at gmail.com

From ryan_ware at me.com  Thu Oct  9 10:42:43 2008
From: ryan_ware at me.com (Ware, Ryan R)
Date: Thu, 09 Oct 2008 10:42:43 -0700
Subject: Hey, I would like to propose that we cut the gordian knot.
In-Reply-To: <658735B6-2E1C-45BF-B17A-D043C08B8757@apple.com>
References: <CDC52471-1C3A-4799-8895-BAB650B028FF@macports.org>
	<8C0333BF-BC12-4C3D-AE32-D725B058262E@macports.org>
	<5cbbe4ae0810080040j4ac97343vf85d7d27ec801263@mail.gmail.com>
	<658735B6-2E1C-45BF-B17A-D043C08B8757@apple.com>
Message-ID: <6D9D60F9-2769-48E0-AC8A-6D2EACD50E19@me.com>

I would have to say that given what I've seen, I encourage this  
approach unless the current portmgr team wants to stand up immediately  
and say they can commit to the short-term time needed to defining and  
ratifying a voting process.  If that is not something they can commit  
to, then I would suggest that given acceptance of the individuals  
noted below (or some subset of them likely no less then three  
individuals in size), that their first task is to determine what the  
voting process will be in the future.

I would also strongly support a time limit on the terms so that the  
community has some method to impact how the project is being governed  
as well as giving members of the portmgr team a method of moving on if  
they can no longer commit their time and energy.

Ryan

On Oct 8, 2008, at 5:55 AM, Jordan K. Hubbard wrote:

> (http://en.wikipedia.org/wiki/Gordian_knot)
>
> Having just read jmpp's request for "a bit more time" to sort out a  
> voting process, I must confess to feeling more trepidation than  
> assurance.  To be completely fair, he does note several times that  
> he and the rest of the moribund portmgr team would like to move  
> quickly, but given the degree to which that group has also  
> demonstrated itself to be overworked and less than involved in the  
> day to day affairs of MacPorts, anything which delays a solution  
> also runs the risk of blunting some of the current enthusiasm should  
> said "process" end up dragging out longer than anticipated (which,  
> as experience amply suggests, it invariably does) and I honestly  
> don't think we can afford that at this late stage.
>
> I would therefore like to suggest that we simply ratify the  
> following list rather than dragging out a lengthy "voting" process  
> for a set of positions which, from a certain angle, might even be  
> viewed as largely ceremonial since there is no real "power" afforded  
> by membership in the portmgr team.   Volunteers will always choose  
> to follow (or not) such a group on the basis of the credibility of  
> its individual members rather than any fancy paper hats they may be  
> wearing, and the sooner we simply slam those hats on some credible  
> heads and say "Thank you!  Get started!", the sooner we can all get  
> back to discussing the real question of how to get to where we need  
> to go next.
>
> As a courtesy to the outgoing portmgr team, I would also be  
> perfectly happy to see them be the official "ratifiers" of this new  
> team, assuming it passes their sniff test and they're also willing  
> to do so in the next day or two, otherwise I would be just as happy  
> with a statement along the lines of "if there are no significant,  
> well-argued objections in the next 72 hours, they're it!  Quick,  
> before they change their minds!" :-)
>
> Portmgr (subject to individual acceptance, of course - we still  
> haven't heard from two of the four):
> Ryan Schmidt
> Bryan Blackburn
> Rainer Mueller
> Joshua Root
> [Note:  Any subset of the above would also be acceptable - 4 is not  
> some magic minimum number, for all the reasons I've already outlined]
>
> Release engineering team:
> Ryan Schmidt (interim or longer, if he wants it)
> Julio Biason
>
> I'm really not trying to undercut anyone here, least of all jmpp,  
> but seriously folks - we've been suffering from a leadership/ 
> directional vacuum for quite some time now and I don't think we need  
> to bog down the only solution to be offered in quite some time by  
> getting all constitutional about it or saying "hey, wait, let's all  
> think about this for awhile and engage in lengthy discussion!"     
> That might have been a good plan of action about a year ago, and I  
> would be also more than happy to see the "new portmgr" establish a  
> framework for elections and term limits and all the other checks and  
> balances that they might wish to create for future generations, but  
> what we need right now is an immediate "interim government" and some  
> long overdue action on the release engineering front.
>
> Any objections?
>
> - Jordan
>
> _______________________________________________
> macports-users mailing list
> macports-users at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-users

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

From jmr at macports.org  Thu Oct  9 12:01:59 2008
From: jmr at macports.org (Joshua Root)
Date: Fri, 10 Oct 2008 06:01:59 +1100
Subject: Fwd: [40483] trunk/dports/erlang/mochiweb
In-Reply-To: <5cbbe4ae0810090632xbd7338bld8d71aa63be24f38@mail.gmail.com>
References: <20081003135620.4B48746A3A6@beta.macosforge.org>	
	<5cbbe4ae0810071437o1d29a89fi331252a58be603fe@mail.gmail.com>	
	<48EBD8E3.3010104@macports.org>	
	<5cbbe4ae0810072317t368c36aaqf9357d1e8551b1fa@mail.gmail.com>
	<5cbbe4ae0810090632xbd7338bld8d71aa63be24f38@mail.gmail.com>
Message-ID: <48EE5527.2000904@macports.org>

C. Florian Ebeling wrote:
> On Wed, Oct 8, 2008 at 8:17 AM, C. Florian Ebeling
> <febeling at macports.org> wrote:
>>>> Recently I wanted to copy over a whole directory form worksrcpath
>>>> to destdir, and that turned out to be quite tedious. Is it possible to
>>>> do this any easier than this?
>>> "copy ${worksrcpath}/priv/skel ${privdir}/skel" should do it, unless
>>> I've misunderstood?
> 
> true actually :)  was confused.
> 
> I have another problem now, though. since its a svn checkout, by simply
> copying i get all these crappy little .svn directories plus their content.
> something like an -exclude PATTERN doesn't seem to exist though.
> Any idea for that additional problem? :)

Hmm, svn fetch should probably use export rather than checkout. I guess
you can use system and find(1) to delete them.

- Josh

From db.evans at gmail.com  Thu Oct  9 21:18:51 2008
From: db.evans at gmail.com (David Evans)
Date: Thu, 09 Oct 2008 21:18:51 -0700
Subject: [MacPorts] #16803: graphics/gimp2:  maintainer update to 2.6.1
In-Reply-To: <063.9448a466e7a2bc756eae7c24eda95031@macports.org>
References: <054.e013754cc802ef497914d6025b96874a@macports.org>
	<063.9448a466e7a2bc756eae7c24eda95031@macports.org>
Message-ID: <48EED7AB.9010905@gmail.com>

MacPorts wrote:
> #16803: graphics/gimp2:  maintainer update to 2.6.1
> ---------------------------------+------------------------------------------
>   Reporter:  db.evans at gmail.com  |       Owner:  macsforever2000 at macports.org
>       Type:  enhancement         |      Status:  closed                      
>   Priority:  Normal              |   Milestone:  Port Enhancements           
>  Component:  ports               |     Version:  1.7.0                       
> Resolution:  fixed               |    Keywords:  help browser gtk-webkit     
>       Port:  gimp2               |  
> ---------------------------------+------------------------------------------
>
> Comment(by myschizobuddy at gmail.com):
>
>  one more thing regarding help.
>  without help build in, it gives you the option of going online and viewing
>  the help. but when you click on it, it complains about not having GIO
>  backend and gvfs should be installed. Looking at the configure script. it
>  uses one of the 4 libs to connect to the web, gvfs, gnomefs, curl or wget.
>  gvfs is the prefered method and it doesn't work. I'll try gnomefs, curl
>  and wget and see which one takes you online for help.
>  that also means that curl is an optional dependency. if gnomefs works then
>  curl isn't needed.
>
>  more testing is needed to resolve this help issue.
>
>   
Yes, I agree that there a number of things not working with help (more
than one I expect).  By
the way,  in the current configuration it is supposed to be using
gnomevfs but it still wants to
use GIO which is the way of the future for GTK/GNOME apps.  So best long
range plan
is to debug gvfs and get it working. If you have any specific tested
solutions, please post them
as a new enhancement request as opposed to adding on to closed tickets.
Thanks.




From ryandesign at macports.org  Thu Oct  9 23:59:41 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 10 Oct 2008 01:59:41 -0500
Subject: [40644] trunk/dports/devel/darcs/Portfile
In-Reply-To: <20081009173120.04A3D4B9F44@beta.macosforge.org>
References: <20081009173120.04A3D4B9F44@beta.macosforge.org>
Message-ID: <698199A4-EB17-4BE6-9C99-45A493C1A7BD@macports.org>

On Oct 9, 2008, at 12:31, gwright at macports.org wrote:

> +configure.env	RGBDEF=/usr/X11/share/X11/rgb.txt

X11 is not located in /usr/X11 on Mac OS X 10.4 and earlier. You  
should use the variable ${x11prefix} instead of hardcoding it in the  
portfile.


From ryandesign at macports.org  Fri Oct 10 00:15:14 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 10 Oct 2008 02:15:14 -0500
Subject: [MacPorts] #12914: "cd" TCL procedure should not be used in
	Portfiles anymore
In-Reply-To: <061.26401c5cc89cfeb6f95a334abdea72e9@macports.org>
References: <052.94b03854b72c2866ff7c4a50f8a4f572@macports.org>
	<061.26401c5cc89cfeb6f95a334abdea72e9@macports.org>
Message-ID: <C73790AC-5294-4F99-84F1-6626F31A57BD@macports.org>

On Oct 9, 2008, at 18:20, MacPorts wrote:

> #12914: "cd" TCL procedure should not be used in Portfiles anymore
> ------------------------------- 
> +--------------------------------------------
>   Reporter:  nox at macports.org  |       Owner:  ryandesign at macports.org
>       Type:  defect            |      Status:  new
>   Priority:  High              |   Milestone:  Port Bugs
>  Component:  ports             |     Version:  1.6.0
> Resolution:                    |    Keywords:
>       Port:                    |
> ------------------------------- 
> +--------------------------------------------
> Changes (by jmr at macports.org):
>
>  * cc: nox at macports.org, ryandesign at macports.org (removed)
>  * cc: gwright at macports.org, mww at macports.org, waqar at macports.org  
> (added)
>
>
> Comment:
>
>  All nomaintainer and openmaintainer ports are now fixed. Ryan's  
> script now
>  shows 72 affected ports (two of which are false hits, incidentally).
>  Adding the main offenders to cc.

I've been watching your commits come in. This is tedious and fiddly  
work. Thanks for diving in and fixing it. Nice work, Joshua!


From ryandesign at macports.org  Sat Oct 11 00:08:26 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 11 Oct 2008 02:08:26 -0500
Subject: [40682] trunk/dports
In-Reply-To: <20081010171940.7A6E84CDB17@beta.macosforge.org>
References: <20081010171940.7A6E84CDB17@beta.macosforge.org>
Message-ID: <31FF4DF5-0D26-4310-B05E-6D5C8F9C1512@macports.org>

On Oct 10, 2008, at 12:19, nox at macports.org wrote:

> Revision: 40682
>           http://trac.macports.org/changeset/40682
> Author:   nox at macports.org
> Date:     2008-10-10 10:19:39 -0700 (Fri, 10 Oct 2008)
> Log Message:
> -----------
> cln, nestedsums, qmail-spamcontrol, xloops: Errors in platform  
> blocks are now executed in a pre-fetch block.
>
> Modified Paths:
> --------------
>     trunk/dports/mail/qmail-spamcontrol/Portfile
>     trunk/dports/math/cln/Portfile
>     trunk/dports/math/nestedsums/Portfile
>     trunk/dports/science/xloops/Portfile
>
> Modified: trunk/dports/mail/qmail-spamcontrol/Portfile
> ===================================================================
> --- trunk/dports/mail/qmail-spamcontrol/Portfile	2008-10-10  
> 16:44:12 UTC (rev 40681)
> +++ trunk/dports/mail/qmail-spamcontrol/Portfile	2008-10-10  
> 17:19:39 UTC (rev 40682)
> @@ -243,7 +243,9 @@
>  }
>
>  platform darwin 6 {
> -	return -code error "${name} requires Mac OS X 10.3 or newer."
> +	pre-fetch {
> +		error "${name} requires Mac OS X 10.3 or newer."
> +	}
>  }

What is the difference between "error" and "return -code error"? I  
keep learning about new ways of returning errors from ports. It's  
disconcerting that there are so many ways. :/



From nox at macports.org  Sat Oct 11 00:15:32 2008
From: nox at macports.org (nox)
Date: Sat, 11 Oct 2008 09:15:32 +0200
Subject: [40682] trunk/dports
In-Reply-To: <31FF4DF5-0D26-4310-B05E-6D5C8F9C1512@macports.org>
References: <20081010171940.7A6E84CDB17@beta.macosforge.org>
	<31FF4DF5-0D26-4310-B05E-6D5C8F9C1512@macports.org>
Message-ID: <A7E7679E-AAEB-4A1D-8093-AD1F6076D960@macports.org>

Le 11 oct. 08 ? 09:08, Ryan Schmidt a ?crit :

> On Oct 10, 2008, at 12:19, nox at macports.org wrote:
>
>> Revision: 40682
>>          http://trac.macports.org/changeset/40682
>> Author:   nox at macports.org
>> Date:     2008-10-10 10:19:39 -0700 (Fri, 10 Oct 2008)
>> Log Message:
>> -----------
>> cln, nestedsums, qmail-spamcontrol, xloops: Errors in platform  
>> blocks are now executed in a pre-fetch block.
>>
>> Modified Paths:
>> --------------
>>    trunk/dports/mail/qmail-spamcontrol/Portfile
>>    trunk/dports/math/cln/Portfile
>>    trunk/dports/math/nestedsums/Portfile
>>    trunk/dports/science/xloops/Portfile
>>
>> Modified: trunk/dports/mail/qmail-spamcontrol/Portfile
>> ===================================================================
>> --- trunk/dports/mail/qmail-spamcontrol/Portfile	2008-10-10  
>> 16:44:12 UTC (rev 40681)
>> +++ trunk/dports/mail/qmail-spamcontrol/Portfile	2008-10-10  
>> 17:19:39 UTC (rev 40682)
>> @@ -243,7 +243,9 @@
>> }
>>
>> platform darwin 6 {
>> -	return -code error "${name} requires Mac OS X 10.3 or newer."
>> +	pre-fetch {
>> +		error "${name} requires Mac OS X 10.3 or newer."
>> +	}
>> }
>
> What is the difference between "error" and "return -code error"? I  
> keep learning about new ways of returning errors from ports. It's  
> disconcerting that there are so many ways. :/
>

None.
 From the manpages, `error string` <=> `return -code error string`


From jmr at macports.org  Sat Oct 11 01:55:07 2008
From: jmr at macports.org (Joshua Root)
Date: Sat, 11 Oct 2008 19:55:07 +1100
Subject: [40682] trunk/dports
In-Reply-To: <A7E7679E-AAEB-4A1D-8093-AD1F6076D960@macports.org>
References: <20081010171940.7A6E84CDB17@beta.macosforge.org>	<31FF4DF5-0D26-4310-B05E-6D5C8F9C1512@macports.org>
	<A7E7679E-AAEB-4A1D-8093-AD1F6076D960@macports.org>
Message-ID: <48F069EB.2090900@macports.org>

nox wrote:
>> What is the difference between "error" and "return -code error"? I  
>> keep learning about new ways of returning errors from ports. It's  
>> disconcerting that there are so many ways. :/
>>
> 
> None.
>  From the manpages, `error string` <=> `return -code error string`

I think technically 'error' generates an error in the current context,
while 'return -code error' generates it in the caller's context. I don't
think there's any practical difference for Portfile purposes.

- Josh

From 0x62_0x6c_0x62 at pobox.com  Sat Oct 11 14:23:22 2008
From: 0x62_0x6c_0x62 at pobox.com (Bryan Blackburn)
Date: Sat, 11 Oct 2008 15:23:22 -0600
Subject: Framework install location
Message-ID: <20081011212322.GF771@ninagal.withay.com>

We currently have an inconsistency concerning framework install locations:
trunk, by default, sets frameworks_dir to /Library/Frameworks [1]; the
python ports (2.4 and later versions) all use ${prefix}/Library/Frameworks.

Fortunately, frameworks_dir is only on trunk right now so can be pretty
safely changed (trunk is the in-development version, after all), and it
makes more sense to keep as much as possible under ${prefix}, so I propose
we change aclocal.m4 to use the same location as the python ports by
default.  Going forward, the python ports will need to be updated to use
frameworks_dir instead of hardcoding, but that isn't too difficult (I've
done that for 2.6 in #16765 [2]).  Only one other port uses frameworks_dir
currently, MacPorts_Framework, so not too much work to update.

Are there any objections to this change?  The only issue is that
${prefix}/Library/Frameworks isn't in the default framework search path like
/Library/Frameworks, but that is rectified with a compiler switch (just like
needing to use a switch to use libraries and headers in ${prefix} now).

Bryan

[1] - <http://trac.macports.org/browser/trunk/base/aclocal.m4#L392>
[2] - <http://trac.macports.org/ticket/16765>


From adambyrtek at gmail.com  Sat Oct 11 15:18:24 2008
From: adambyrtek at gmail.com (Adam Byrtek)
Date: Sun, 12 Oct 2008 00:18:24 +0200
Subject: [PATCH] Inheritance of macports.conf configuration files
In-Reply-To: <48E2EACB.1000008@macports.org>
References: <670d23ff0808220121g1ebe7680of841f988dfc5fc28@mail.gmail.com>
	<670d23ff0809301203g4e1cef41p67aac56c89395fbe@mail.gmail.com>
	<48E2EACB.1000008@macports.org>
Message-ID: <670d23ff0810111518y28e8bba6j4c2eb58d55e95658@mail.gmail.com>

On Wed, Oct 1, 2008 at 5:13 AM, Rainer M?ller <raimue at macports.org> wrote:
> Sometimes macports-dev is not so responsive and everybody seems busy.
> Good that you sent out the reminder, I just forgot about this patch already.
>
> +1 on applying the patch.

Thanks! Anybody with commit access willing to commit this?

Best regards,
Adam

From blair at orcaware.com  Sat Oct 11 17:25:42 2008
From: blair at orcaware.com (Blair Zajac)
Date: Sat, 11 Oct 2008 17:25:42 -0700
Subject: Framework install location
In-Reply-To: <20081011212322.GF771@ninagal.withay.com>
References: <20081011212322.GF771@ninagal.withay.com>
Message-ID: <2BFA4ADF-DE8E-48DF-B4EC-4F8BA09F8FB6@orcaware.com>


On Oct 11, 2008, at 2:23 PM, Bryan Blackburn wrote:

> We currently have an inconsistency concerning framework install  
> locations:
> trunk, by default, sets frameworks_dir to /Library/Frameworks [1]; the
> python ports (2.4 and later versions) all use ${prefix}/Library/ 
> Frameworks.
>
> Fortunately, frameworks_dir is only on trunk right now so can be  
> pretty
> safely changed (trunk is the in-development version, after all), and  
> it
> makes more sense to keep as much as possible under ${prefix}, so I  
> propose
> we change aclocal.m4 to use the same location as the python ports by
> default.  Going forward, the python ports will need to be updated to  
> use
> frameworks_dir instead of hardcoding, but that isn't too difficult  
> (I've
> done that for 2.6 in #16765 [2]).  Only one other port uses  
> frameworks_dir
> currently, MacPorts_Framework, so not too much work to update.

>
>
> Are there any objections to this change?  The only issue is that
> ${prefix}/Library/Frameworks isn't in the default framework search  
> path like
> /Library/Frameworks, but that is rectified with a compiler switch  
> (just like
> needing to use a switch to use libraries and headers in ${prefix}  
> now).
>

Agreed it should be under ${prefix} so you can have multiple MacPorts  
installed at the same time.

Blair

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



From raimue at macports.org  Sat Oct 11 19:55:23 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sun, 12 Oct 2008 04:55:23 +0200
Subject: [PATCH] Inheritance of macports.conf configuration files
In-Reply-To: <670d23ff0810111518y28e8bba6j4c2eb58d55e95658@mail.gmail.com>
References: <670d23ff0808220121g1ebe7680of841f988dfc5fc28@mail.gmail.com>	<670d23ff0809301203g4e1cef41p67aac56c89395fbe@mail.gmail.com>	<48E2EACB.1000008@macports.org>
	<670d23ff0810111518y28e8bba6j4c2eb58d55e95658@mail.gmail.com>
Message-ID: <48F1671B.5020409@macports.org>

Adam Byrtek wrote:
> On Wed, Oct 1, 2008 at 5:13 AM, Rainer M?ller <raimue at macports.org> wrote:
>> +1 on applying the patch.
> 
> Thanks! Anybody with commit access willing to commit this?

Committed in r40712.

Rainer

From afb at macports.org  Sun Oct 12 02:02:07 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Sun, 12 Oct 2008 11:02:07 +0200
Subject: Framework install location
In-Reply-To: <20081011212322.GF771@ninagal.withay.com>
References: <20081011212322.GF771@ninagal.withay.com>
Message-ID: <EF08C657-FD89-4A3E-910F-AE5B75F1E982@macports.org>

Bryan Blackburn wrote:

> We currently have an inconsistency concerning framework install  
> locations:
> trunk, by default, sets frameworks_dir to /Library/Frameworks [1]; the
> python ports (2.4 and later versions) all use ${prefix}/Library/ 
> Frameworks.

I don't think the python ports follow anyone elses rules. It might even
still have installed under ${prefix}/lib when frameworks_dir was added.

But it would probably be a good idea to install all frameworks to the
same location, I think libsdl-framework still uses /Library/Frameworks.

> Fortunately, frameworks_dir is only on trunk right now so can be  
> pretty
> safely changed (trunk is the in-development version, after all),  
> and it
> makes more sense to keep as much as possible under ${prefix}, so I  
> propose
> we change aclocal.m4 to use the same location as the python ports by
> default.  Going forward, the python ports will need to be updated  
> to use
> frameworks_dir instead of hardcoding, but that isn't too difficult  
> (I've
> done that for 2.6 in #16765 [2]).  Only one other port uses  
> frameworks_dir
> currently, MacPorts_Framework, so not too much work to update.

The configure scripts used the /Applications and /Library locations
(or ~/Applications and ~/Library) because that was the rule at the time,
made it easier to integrate with things outside of MacPorts itself such
as Xcode or Services. That applied to applications/frameworks/ 
tclpackage.

I would prefer prefix, myself...

> Are there any objections to this change?  The only issue is that
> ${prefix}/Library/Frameworks isn't in the default framework search  
> path like
> /Library/Frameworks, but that is rectified with a compiler switch  
> (just like
> needing to use a switch to use libraries and headers in ${prefix}  
> now).

No objections from me, at least.

Last time I looked, the Xcode group rules needed some additions to use
the ${applications_dir} and ${frameworks_dir} instead of project  
settings.
So when stopping with hardcoding the paths, those would need adding too
in order to keep all the MP-installed frameworks in the same location.

--anders


From adambyrtek at gmail.com  Sun Oct 12 04:00:40 2008
From: adambyrtek at gmail.com (Adam Byrtek)
Date: Sun, 12 Oct 2008 13:00:40 +0200
Subject: [PATCH] Inheritance of macports.conf configuration files
In-Reply-To: <48F1671B.5020409@macports.org>
References: <670d23ff0808220121g1ebe7680of841f988dfc5fc28@mail.gmail.com>
	<670d23ff0809301203g4e1cef41p67aac56c89395fbe@mail.gmail.com>
	<48E2EACB.1000008@macports.org>
	<670d23ff0810111518y28e8bba6j4c2eb58d55e95658@mail.gmail.com>
	<48F1671B.5020409@macports.org>
Message-ID: <670d23ff0810120400o105e9a1ft41d8e35cfa4a35ba@mail.gmail.com>

On Sun, Oct 12, 2008 at 4:55 AM, Rainer M?ller <raimue at macports.org> wrote:
> Adam Byrtek wrote:
>> On Wed, Oct 1, 2008 at 5:13 AM, Rainer M?ller <raimue at macports.org> wrote:
>>> +1 on applying the patch.
>>
>> Thanks! Anybody with commit access willing to commit this?
>
> Committed in r40712.

Thank you!

Regards,
Adam

From ryandesign at macports.org  Sun Oct 12 12:14:26 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 12 Oct 2008 14:14:26 -0500
Subject: [40703] trunk/dports/perl/p5-io-aio/Portfile
In-Reply-To: <20081011164031.E190E4D4BCD@beta.macosforge.org>
References: <20081011164031.E190E4D4BCD@beta.macosforge.org>
Message-ID: <4F4BCDFC-3541-44CB-9150-5633A1372E85@macports.org>

On Oct 11, 2008, at 11:40, pmq at macports.org wrote:

> Revision: 40703
>           http://trac.macports.org/changeset/40703
> Author:   pmq at macports.org
> Date:     2008-10-11 09:40:30 -0700 (Sat, 11 Oct 2008)
> Log Message:
> -----------
> Version bump to 3.1.
>
> Modified Paths:
> --------------
>     trunk/dports/perl/p5-io-aio/Portfile
>
> Modified: trunk/dports/perl/p5-io-aio/Portfile
> ===================================================================
> --- trunk/dports/perl/p5-io-aio/Portfile	2008-10-11 15:32:09 UTC  
> (rev 40702)
> +++ trunk/dports/perl/p5-io-aio/Portfile	2008-10-11 16:40:30 UTC  
> (rev 40703)
> @@ -3,7 +3,7 @@
>  PortSystem          1.0
>  PortGroup	    perl5 1.0
>
> -perl5.setup	    IO-AIO 3.07
> +perl5.setup	    IO-AIO 3.1

You need to increase the port's epoch so that MacPorts will consider  
"1" to be greater than "07", since this ticket has not been resolved:

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



From ryandesign at macports.org  Sun Oct 12 15:29:01 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 12 Oct 2008 17:29:01 -0500
Subject: applications_dir under prefix (was: Re: Framework install location)
In-Reply-To: <EF08C657-FD89-4A3E-910F-AE5B75F1E982@macports.org>
References: <20081011212322.GF771@ninagal.withay.com>
	<EF08C657-FD89-4A3E-910F-AE5B75F1E982@macports.org>
Message-ID: <CC735966-5026-4C84-971D-53BD35CCC853@macports.org>

On Oct 12, 2008, at 04:02, Anders F Bj?rklund wrote:

> The configure scripts used the /Applications and /Library locations
> (or ~/Applications and ~/Library) because that was the rule at the  
> time,
> made it easier to integrate with things outside of MacPorts itself  
> such
> as Xcode or Services. That applied to applications/frameworks/
> tclpackage.
>
> I would prefer prefix, myself...

I don't know the implications of having the frameworks outside of / 
Library/Frameworks (e.g. in ${prefix}/Library/Frameworks) but for  
applications I thought the point was that the OS wouldn't know about  
them (e.g. things like "open -a foo" wouldn't work unless foo.app was  
somewhere under /Applications). Though testing this right now, I  
can't reproduce that.

If that is a problem, we could have MacPorts create a symlink at / 
Applications/MacPorts pointing to ${prefix}/Applications/MacPorts if  
one does not already exist (if installing as root). This would  
satisfy the majority of users who have just a single installation,  
but still work fine for those with multiple installations. Finally  
there could be a configure switch to not make that symlink.


From mcalhoun at macports.org  Sun Oct 12 15:41:06 2008
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Sun, 12 Oct 2008 22:41:06 +0000 (UTC)
Subject: Making changes to portgroups
Message-ID: <loom.20081012T221948-527@post.gmane.org>

Sometime in the future (after discussion is complete), I was hoping to commit a
change to the perl5 portgroup based on the discussion in #16830.
(http://trac.macports.org/ticket/16830)

I was also hoping to commit a python26 portgroup I have based on the
discussion in #16334.
(http://trac.macports.org/ticket/16334)

>From on #14553, it seems that any such change would have to wait until a
version update.
(http://trac.macports.org/ticket/14553)

Forgive my ignorance, but what is the correct and responsible procedure
for making such a change?
The documentation discusses how to change a Portfile, but I can not find
any information on making changes to the base.

Thank you,
Marcus





From jmr at macports.org  Sun Oct 12 16:06:32 2008
From: jmr at macports.org (Joshua Root)
Date: Mon, 13 Oct 2008 10:06:32 +1100
Subject: Making changes to portgroups
In-Reply-To: <loom.20081012T221948-527@post.gmane.org>
References: <loom.20081012T221948-527@post.gmane.org>
Message-ID: <48F282F8.9090405@macports.org>

Marcus Calhoun-Lopez wrote:
> Sometime in the future (after discussion is complete), I was hoping to commit a
> change to the perl5 portgroup based on the discussion in #16830.
> (http://trac.macports.org/ticket/16830)
> 
> I was also hoping to commit a python26 portgroup I have based on the
> discussion in #16334.
> (http://trac.macports.org/ticket/16334)

The alternative approach is <http://trac.macports.org/ticket/16723>. We
need to decide which way we want to go.

>>From on #14553, it seems that any such change would have to wait until a
> version update.
> (http://trac.macports.org/ticket/14553)

Right. We really should resolve #14553 soon, as it will make changing
portgroups much easier in future.

> Forgive my ignorance, but what is the correct and responsible procedure
> for making such a change?
> The documentation discusses how to change a Portfile, but I can not find
> any information on making changes to the base.

There isn't an official procedure for base changes. The way it seems to
go is you can just dive in and fix things that are obviously broken,
while you should open tickets for disruptive changes. Then discuss them
on the list and with other base hackers directly until a consensus
emerges that the change is OK to go in.

- Josh

From n.oxyde at gmail.com  Mon Oct 13 01:05:41 2008
From: n.oxyde at gmail.com (nox)
Date: Mon, 13 Oct 2008 10:05:41 +0200
Subject: applications_dir under prefix (was: Re: Framework install
	location)
In-Reply-To: <CC735966-5026-4C84-971D-53BD35CCC853@macports.org>
References: <20081011212322.GF771@ninagal.withay.com>
	<EF08C657-FD89-4A3E-910F-AE5B75F1E982@macports.org>
	<CC735966-5026-4C84-971D-53BD35CCC853@macports.org>
Message-ID: <0A31830D-A56D-49EB-B299-001B758C5EF9@gmail.com>


Le 13 oct. 08 ? 00:29, Ryan Schmidt a ?crit :

> On Oct 12, 2008, at 04:02, Anders F Bj?rklund wrote:
>
>> The configure scripts used the /Applications and /Library locations
>> (or ~/Applications and ~/Library) because that was the rule at the
>> time,
>> made it easier to integrate with things outside of MacPorts itself
>> such
>> as Xcode or Services. That applied to applications/frameworks/
>> tclpackage.
>>
>> I would prefer prefix, myself...
>
> I don't know the implications of having the frameworks outside of /
> Library/Frameworks (e.g. in ${prefix}/Library/Frameworks) but for
> applications I thought the point was that the OS wouldn't know about
> them (e.g. things like "open -a foo" wouldn't work unless foo.app was
> somewhere under /Applications). Though testing this right now, I
> can't reproduce that.
>
> If that is a problem, we could have MacPorts create a symlink at /
> Applications/MacPorts pointing to ${prefix}/Applications/MacPorts if
> one does not already exist (if installing as root). This would
> satisfy the majority of users who have just a single installation,
> but still work fine for those with multiple installations. Finally
> there could be a configure switch to not make that symlink.
>

Applications outside /Applications or ~ are not found by the system,  
so "open" and Finder won't be able to use them to open files.
To install frameworks inside $prefix/Library/Frameworks we will need  
to tell xcodebuild to search frameworks there when using the xcode
portgroup.

From ryandesign at macports.org  Mon Oct 13 12:05:14 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 13 Oct 2008 14:05:14 -0500
Subject: applications_dir under prefix (was: Re: Framework install
	location)
In-Reply-To: <0A31830D-A56D-49EB-B299-001B758C5EF9@gmail.com>
References: <20081011212322.GF771@ninagal.withay.com>
	<EF08C657-FD89-4A3E-910F-AE5B75F1E982@macports.org>
	<CC735966-5026-4C84-971D-53BD35CCC853@macports.org>
	<0A31830D-A56D-49EB-B299-001B758C5EF9@gmail.com>
Message-ID: <79953036-8373-4565-8B88-1EFB1F57E61E@macports.org>


On Oct 13, 2008, at 03:05, nox wrote:

> Le 13 oct. 08 ? 00:29, Ryan Schmidt a ?crit :
>
>> On Oct 12, 2008, at 04:02, Anders F Bj?rklund wrote:
>>
>>> The configure scripts used the /Applications and /Library locations
>>> (or ~/Applications and ~/Library) because that was the rule at the
>>> time,
>>> made it easier to integrate with things outside of MacPorts itself
>>> such
>>> as Xcode or Services. That applied to applications/frameworks/
>>> tclpackage.
>>>
>>> I would prefer prefix, myself...
>>
>> I don't know the implications of having the frameworks outside of /
>> Library/Frameworks (e.g. in ${prefix}/Library/Frameworks) but for
>> applications I thought the point was that the OS wouldn't know about
>> them (e.g. things like "open -a foo" wouldn't work unless foo.app was
>> somewhere under /Applications). Though testing this right now, I
>> can't reproduce that.
>>
>> If that is a problem, we could have MacPorts create a symlink at /
>> Applications/MacPorts pointing to ${prefix}/Applications/MacPorts if
>> one does not already exist (if installing as root). This would
>> satisfy the majority of users who have just a single installation,
>> but still work fine for those with multiple installations. Finally
>> there could be a configure switch to not make that symlink.
>
> Applications outside /Applications or ~ are not found by the system,
> so "open" and Finder won't be able to use them to open files.

As I said, I was unable to verify that. I moved my /Applications/ 
MacPorts outside /Applications and "open -a" was still able to find  
them. Maybe they were cached in some way. Maybe a reboot would have  
made them unavailable again. Can someone test this? And then, test  
whether placing a symlink in /Applications/MacPorts pointing to where  
the apps are allows it to work again?

> To install frameworks inside $prefix/Library/Frameworks we will need
> to tell xcodebuild to search frameworks there when using the xcode
> portgroup.



From dluke at geeklair.net  Mon Oct 13 12:14:58 2008
From: dluke at geeklair.net (Daniel J. Luke)
Date: Mon, 13 Oct 2008 15:14:58 -0400
Subject: applications_dir under prefix (was: Re: Framework install
	location)
In-Reply-To: <79953036-8373-4565-8B88-1EFB1F57E61E@macports.org>
References: <20081011212322.GF771@ninagal.withay.com>
	<EF08C657-FD89-4A3E-910F-AE5B75F1E982@macports.org>
	<CC735966-5026-4C84-971D-53BD35CCC853@macports.org>
	<0A31830D-A56D-49EB-B299-001B758C5EF9@gmail.com>
	<79953036-8373-4565-8B88-1EFB1F57E61E@macports.org>
Message-ID: <3E26F5F8-8278-48F3-8C2A-F09D9F710138@geeklair.net>

On Oct 13, 2008, at 3:05 PM, Ryan Schmidt wrote:
>> Applications outside /Applications or ~ are not found by the system,
>> so "open" and Finder won't be able to use them to open files.
>
> As I said, I was unable to verify that. I moved my /Applications/
> MacPorts outside /Applications and "open -a" was still able to find
> them. Maybe they were cached in some way.

Yes, they were cached.

See

http://developer.apple.com/documentation/Carbon/Conceptual/LaunchServicesConcepts/LSCConcepts/chapter_2_section_5.html#/ 
/apple_ref/doc/uid/TP30000999-CH202-BABEJFCD

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



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

From ryandesign at macports.org  Mon Oct 13 12:22:47 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 13 Oct 2008 14:22:47 -0500
Subject: [40737] trunk/dports/devel/hs-zlib/Portfile
In-Reply-To: <20081013163813.8967D4E2D76@beta.macosforge.org>
References: <20081013163813.8967D4E2D76@beta.macosforge.org>
Message-ID: <3A3DE026-FFE8-411C-96ED-46DCFFF51C79@macports.org>

On Oct 13, 2008, at 11:38, gwright at macports.org wrote:

> Revision: 40737
>           http://trac.macports.org/changeset/40737
> Author:   gwright at macports.org
> Date:     2008-10-13 09:38:12 -0700 (Mon, 13 Oct 2008)
> Log Message:
> -----------
> Build profiling library too.

You should increase the port's revision so anybody who already had it  
installed gets this change (since it results in different files being  
installed on the user's system, right?)


> Modified Paths:
> --------------
>     trunk/dports/devel/hs-zlib/Portfile
>
> Modified: trunk/dports/devel/hs-zlib/Portfile
> ===================================================================
> --- trunk/dports/devel/hs-zlib/Portfile	2008-10-13 16:36:24 UTC  
> (rev 40736)
> +++ trunk/dports/devel/hs-zlib/Portfile	2008-10-13 16:38:12 UTC  
> (rev 40737)
> @@ -26,7 +26,7 @@
>  depends_build	port:ghc
>  depends_lib	port:zlib
>
> -configure	{ system "cd ${worksrcpath} && runhaskell Setup  
> configure --ghc --prefix=${prefix} --with-compiler=${prefix}/bin/ghc"
> +configure	{ system "cd ${worksrcpath} && runhaskell Setup  
> configure --ghc --prefix=${prefix} --enable-library-profiling -- 
> with-compiler=${prefix}/bin/ghc"
>  		}
>
>  build		{ system "cd ${worksrcpath} && runhaskell Setup build"



From ryandesign at macports.org  Mon Oct 13 13:29:48 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 13 Oct 2008 15:29:48 -0500
Subject: [40745] trunk/dports/graphics
In-Reply-To: <20081013201435.4E2224E4019@beta.macosforge.org>
References: <20081013201435.4E2224E4019@beta.macosforge.org>
Message-ID: <3D2B2B17-E6B5-485F-A363-F0A0286875CB@macports.org>

On Oct 13, 2008, at 15:14, devans at macports.org wrote:

> Revision: 40745
>           http://trac.macports.org/changeset/40745
> Author:   devans at macports.org
> Date:     2008-10-13 13:14:34 -0700 (Mon, 13 Oct 2008)
> Log Message:
> -----------
> New port libopenraw-0.0.5, a free software implementation for  
> camera RAW files decoding.
>
> Added Paths:
> -----------
>     trunk/dports/graphics/libopenraw/
>     trunk/dports/graphics/libopenraw/Portfile
>     trunk/dports/graphics/libopenraw/files/
>     trunk/dports/graphics/libopenraw/files/patch-Makefile.in.diff
>
> Added: trunk/dports/graphics/libopenraw/Portfile
> ===================================================================
> --- trunk/dports/graphics/libopenraw/ 
> Portfile	                        (rev 0)
> +++ trunk/dports/graphics/libopenraw/Portfile	2008-10-13 20:14:34  
> UTC (rev 40745)
> @@ -0,0 +1,47 @@
> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode:  
> nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
> +# $Id$
> +
> +PortSystem      1.0
> +
> +name            libopenraw
> +version         0.0.5
> +categories      graphics
> +maintainers     devans
> +platforms       darwin
> +homepage        http://libopenraw.freedesktop.org/wiki/
> +master_sites    http://libopenraw.freedesktop.org/download/
> +
> +description \
> +    libopenraw is an ongoing project to provide a free software  
> implementation for camera RAW files decoding.
> +
> +long_description \
> +    libopenraw is an ongoing project to provide a free software  
> implementation for camera RAW files decoding. \
> +    One of the main reasons is that dcraw is not suited for easy  
> integration into applications, and there is a \
> +    need for an easy to use API to build free software digital  
> image processing applications. It also has the \
> +    goal to address features missing from dcraw such as meta-data  
> decoding and easy thumbnail extraction.
> +
> +checksums       md5     90f9038cc6b47374ea1dd9aa347dfe5a \
> +                sha1    c2752b879ddc34682f1f0195b9499b1c4e983dc8 \
> +                rmd160  9493041dd61a8dd9245fce71db4199c15abbbdfb
> +
> +patchfiles      patch-Makefile.in.diff
> +
> +depends_build \
> +    port:pkgconfig
> +
> +depends_lib \
> +    port:glib2 \
> +    port:jpeg \
> +    port:boost
> +
> +configure.args-append  --with-darwinports

You should remove this configure argument. According to ./configure -- 
help, "--with-darwinports" simply "add[s] /opt/local/... to CPP/ 
LDFLAGS" but a) MacPorts already adds its prefix to CPPFLAGS/LDFLAGS,  
and b) the MacPorts prefix might not be /opt/local.

Also, it can't find boost on my system (maybe because my MacPorts is  
not in /opt/local) unless I add --with-boost=${prefix} to the  
configure.args.

See attached patch.


> +variant no_gnome description {Build without GNOME/GTK2 support}  {
> +    depends_lib-delete port:glib2
> +    configure.args-append  --disable-gnome
> +}
> +
> +livecheck.check regex
> +livecheck.url   ${homepage}
> +livecheck.regex {version\ (\d+(?:\.\d+)*)}

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

From devans at macports.org  Mon Oct 13 14:18:01 2008
From: devans at macports.org (David Evans)
Date: Mon, 13 Oct 2008 14:18:01 -0700
Subject: [40745] trunk/dports/graphics
In-Reply-To: <3D2B2B17-E6B5-485F-A363-F0A0286875CB@macports.org>
References: <20081013201435.4E2224E4019@beta.macosforge.org>
	<3D2B2B17-E6B5-485F-A363-F0A0286875CB@macports.org>
Message-ID: <48F3BB09.1060907@macports.org>

Ryan Schmidt wrote:
> On Oct 13, 2008, at 15:14, devans at macports.org wrote:
>
>> Revision: 40745
>>           http://trac.macports.org/changeset/40745
>> Author:   devans at macports.org
>> Date:     2008-10-13 13:14:34 -0700 (Mon, 13 Oct 2008)
>> Log Message:
>> -----------
>> New port libopenraw-0.0.5, a free software implementation for camera
>> RAW files decoding.
>>
>> Added Paths:
>> -----------
>>     trunk/dports/graphics/libopenraw/
>>     trunk/dports/graphics/libopenraw/Portfile
>>     trunk/dports/graphics/libopenraw/files/
>>     trunk/dports/graphics/libopenraw/files/patch-Makefile.in.diff
>>
>> Added: trunk/dports/graphics/libopenraw/Portfile
>> ===================================================================
>> ---
>> trunk/dports/graphics/libopenraw/Portfile                           
>> (rev 0)
>> +++ trunk/dports/graphics/libopenraw/Portfile    2008-10-13 20:14:34
>> UTC (rev 40745)
>> @@ -0,0 +1,47 @@
>> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil;
>> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
>> +# $Id$
>> +
>> +PortSystem      1.0
>> +
>> +name            libopenraw
>> +version         0.0.5
>> +categories      graphics
>> +maintainers     devans
>> +platforms       darwin
>> +homepage        http://libopenraw.freedesktop.org/wiki/
>> +master_sites    http://libopenraw.freedesktop.org/download/
>> +
>> +description \
>> +    libopenraw is an ongoing project to provide a free software
>> implementation for camera RAW files decoding.
>> +
>> +long_description \
>> +    libopenraw is an ongoing project to provide a free software
>> implementation for camera RAW files decoding. \
>> +    One of the main reasons is that dcraw is not suited for easy
>> integration into applications, and there is a \
>> +    need for an easy to use API to build free software digital image
>> processing applications. It also has the \
>> +    goal to address features missing from dcraw such as meta-data
>> decoding and easy thumbnail extraction.
>> +
>> +checksums       md5     90f9038cc6b47374ea1dd9aa347dfe5a \
>> +                sha1    c2752b879ddc34682f1f0195b9499b1c4e983dc8 \
>> +                rmd160  9493041dd61a8dd9245fce71db4199c15abbbdfb
>> +
>> +patchfiles      patch-Makefile.in.diff
>> +
>> +depends_build \
>> +    port:pkgconfig
>> +
>> +depends_lib \
>> +    port:glib2 \
>> +    port:jpeg \
>> +    port:boost
>> +
>> +configure.args-append  --with-darwinports
>
> You should remove this configure argument. According to ./configure
> --help, "--with-darwinports" simply "add[s] /opt/local/... to
> CPP/LDFLAGS" but a) MacPorts already adds its prefix to
> CPPFLAGS/LDFLAGS, and b) the MacPorts prefix might not be /opt/local.
>
> Also, it can't find boost on my system (maybe because my MacPorts is
> not in /opt/local) unless I add --with-boost=${prefix} to the
> configure.args.
>
> See attached patch.
>
>
>> +variant no_gnome description {Build without GNOME/GTK2 support}  {
>> +    depends_lib-delete port:glib2
>> +    configure.args-append  --disable-gnome
>> +}
>> +
>> +livecheck.check regex
>> +livecheck.url   ${homepage}
>> +livecheck.regex {version\ (\d+(?:\.\d+)*)}
>
Patch applied in r40746.  Thanks.

From febeling at macports.org  Mon Oct 13 23:43:00 2008
From: febeling at macports.org (C. Florian Ebeling)
Date: Tue, 14 Oct 2008 08:43:00 +0200
Subject: Fwd: Port fails to install as image. Problem with cleaning the
	registry.
In-Reply-To: <5cbbe4ae0810132341hb8b76fdsd0f7a61c80c11a97@mail.gmail.com>
References: <b808b3510810131829m71c282d3o470d0c909ecc8d48@mail.gmail.com>
	<5cbbe4ae0810132341hb8b76fdsd0f7a61c80c11a97@mail.gmail.com>
Message-ID: <5cbbe4ae0810132343k47adab8ekc8156e500247a311@mail.gmail.com>

[Forgot Reply-All]

Darren, are you running trunk? What is the output of

 port installed postgresql83-server

I can't given much detailed information on reproduction right now, but
I had somewhat similar
problems recently on trunk. I saw multiple active versions of the same
port, without many unusual
port commands. Feels like we had some regression and uninstall does
not always work
properly anylonger. We should watch this.

Florian

On Tue, Oct 14, 2008 at 3:29 AM, Darren Weber <dweber at macports.org> wrote:
>
> I have a sandbox for some ports, including postgresql83-server (see
> attached) and I've got some issues with my installation.  I'm curious about
> why the 'port clean --all <portname>' doesn't remove the registry entry?
> Here's a terminal session where I incur an issue with the registry and my
> port fails to install as an image:
>
> [ dweber at XXX ~/ports ]$ sudo port install postgresql83-server
> Password:
> Portfile changed since last build; discarding previous state.
> --->  Fetching postgresql83-server
> --->  Verifying checksum(s) for postgresql83-server
> --->  Extracting postgresql83-server
> --->  Configuring postgresql83-server
> --->  Building postgresql83-server with target all
> --->  Staging postgresql83-server into destroot
> --->  Creating launchd control script
> ###########################################################
> # A startup item has been generated that will aid in
> # starting postgresql83-server with launchd. It is disabled
> # by default. Execute the following command to start it,
> # and to cause it to launch at startup:
> #
> # sudo launchctl load -w
> /Library/LaunchDaemons/org.macports.postgresql83-server.plist
> ###########################################################
> --->  Installing postgresql83-server 8.3.4_0
> Error: Target org.macports.install returned: Registry error:
> postgresql83-server @8.3.4_0 already registered as installed.  Please
> uninstall it first.
> Error: Status 1 encountered during processing.
> [ dweber at XXX ~/ports ]$ sudo port uninstall postgresql83-server
> --->  Uninstalling postgresql83-server 8.3.4_0
> [ dweber at XXX ~/ports ]$ sudo port clean --all postgresql83-server
> --->  Cleaning postgresql83-server
> [ dweber at XXX ~/ports ]$ sudo port install postgresql83-server
> --->  Fetching postgresql83-server
> --->  Verifying checksum(s) for postgresql83-server
> --->  Extracting postgresql83-server
> --->  Configuring postgresql83-server
> --->  Building postgresql83-server with target all
> --->  Staging postgresql83-server into destroot
> --->  Creating launchd control script
> ###########################################################
> # A startup item has been generated that will aid in
> # starting postgresql83-server with launchd. It is disabled
> # by default. Execute the following command to start it,
> # and to cause it to launch at startup:
> #
> # sudo launchctl load -w
> /Library/LaunchDaemons/org.macports.postgresql83-server.plist
> ###########################################################
> --->  Installing postgresql83-server 8.3.4_0
> Error: Target org.macports.install returned: Registry error:
> postgresql83-server @8.3.4_0 already registered as installed.  Please
> uninstall it first.
> Error: Status 1 encountered during processing.
> [ dweber at XXX ~/ports ]$ sudo rm
> /opt/local/var/macports/receipts/postgresql83-server/8.3.4_0/receipt.bz2
> [ dweber at XXX ~/ports ]$ sudo port install postgresql83-server
> --->  Installing postgresql83-server 8.3.4_0
>
> To create a database instance, after install do
> %% sudo mkdir -p /opt/local/var/db/postgresql83/defaultdb
> %% sudo chown postgres:postgres /opt/local/var/db/postgresql83/defaultdb
> %% sudo su postgres -c '/opt/local/lib/postgresql83/bin/initdb -D
> /opt/local/var/db/postgresql83/defaultdb'
>
> To tweak your DBMS, consider increasing kern.sysv.shmmax
> by adding an increased kern.sysv.shmmax .. to /etc/sysctl.conf
>
> To load the startup deamon, run:
> %% sudo launchctl load -w
> /Library/LaunchDaemons/org.macports.postgresql83-server.plist
>
> To unload the startup deamon, run:
> %% sudo launchctl unload -w
> /Library/LaunchDaemons/org.macports.postgresql83-server.plist
>
> Run 'port install pgAdmin3' to administer PostgreSQL
> Run 'port install slony1' to manage replication for PostgreSQL
>
> --->  Activating postgresql83-server 8.3.4_0
> Error: Target org.macports.activate returned: Image error:
> postgresql83-server @8.3.4_0 not installed as an image.
> Error: Status 1 encountered during processing.
>
>
> _______________________________________________
> macports-users mailing list
> macports-users at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
>
>



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

From florian.ebeling at gmail.com  Tue Oct 14 00:19:25 2008
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Tue, 14 Oct 2008 09:19:25 +0200
Subject: Call for PortMgr interest/nominations
In-Reply-To: <73A3849F-1DAB-44FE-BF91-5B4F8365A8B9@macports.org>
References: <73A3849F-1DAB-44FE-BF91-5B4F8365A8B9@macports.org>
Message-ID: <5cbbe4ae0810140019j263f1e23y1232fdc6602ffc67@mail.gmail.com>

Hi,

> Based on the amount of interest, we'll decide on an appropriate way to
> select the new slate.

can you give a status update?

Florian


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

From randall.h.wood at alexandriasoftware.com  Tue Oct 14 02:06:27 2008
From: randall.h.wood at alexandriasoftware.com (Randall Wood)
Date: Tue, 14 Oct 2008 05:06:27 -0400
Subject: applications_dir under prefix (was: Re: Framework install
	location)
In-Reply-To: <CC735966-5026-4C84-971D-53BD35CCC853@macports.org>
References: <20081011212322.GF771@ninagal.withay.com>
	<EF08C657-FD89-4A3E-910F-AE5B75F1E982@macports.org>
	<CC735966-5026-4C84-971D-53BD35CCC853@macports.org>
Message-ID: <c24012060810140206k7850a168i31a18f30bcf39452@mail.gmail.com>

On Sun, Oct 12, 2008 at 6:29 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Oct 12, 2008, at 04:02, Anders F Bj?rklund wrote:
>
>> The configure scripts used the /Applications and /Library locations
>> (or ~/Applications and ~/Library) because that was the rule at the
>> time,
>> made it easier to integrate with things outside of MacPorts itself
>> such
>> as Xcode or Services. That applied to applications/frameworks/
>> tclpackage.
>>
>> I would prefer prefix, myself...
>
> I don't know the implications of having the frameworks outside of /
> Library/Frameworks (e.g. in ${prefix}/Library/Frameworks) but for
> applications I thought the point was that the OS wouldn't know about
> them (e.g. things like "open -a foo" wouldn't work unless foo.app was
> somewhere under /Applications). Though testing this right now, I
> can't reproduce that.
>
> If that is a problem, we could have MacPorts create a symlink at /
> Applications/MacPorts pointing to ${prefix}/Applications/MacPorts if
> one does not already exist (if installing as root). This would
> satisfy the majority of users who have just a single installation,
> but still work fine for those with multiple installations. Finally
> there could be a configure switch to not make that symlink.

Symlinks break in the 'list view' for the Applications folder in the
Dock. If you drag your applications folder to the dock, and place it
in list view, you get a "menu" of applications. Subfolders can be
navigated through like submenus, but symlinks are not followed. I'd
keep applications in /Applications/MacPorts

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



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

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

From jberry at macports.org  Tue Oct 14 06:39:12 2008
From: jberry at macports.org (James Berry)
Date: Tue, 14 Oct 2008 06:39:12 -0700
Subject: New PortMgr team announced!
Message-ID: <606AE2C8-7721-45E1-826F-E0B65AA1F325@macports.org>

The (current) PortMgr team is pleased to be able to announce the  
appointment of a new PortMgr team.

Four people expressed interest in the PortMgr positions, and have all  
been appointed by proclamation:

	Ryan Schmidt
	Rainer M?ller
	Joshua Root
	Bryan Blackburn

We, the (previous) members of the PortMgr team, will do all we can to  
assist in a transition to the new members. As previously discussed, we  
will move to a group (loosely and temporarily named the "MacPorts  
Council of Elders") which serves as an advisory board to the project.

Please welcome Ryan, Rainer, Joshua, and Bryan, and direct further  
questions at them ;)

Sincerely, the past portmgr members,

Juan, Markus, James

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

From ernest.prabhakar at gmail.com  Tue Oct 14 06:50:12 2008
From: ernest.prabhakar at gmail.com (Ernest Prabhakar)
Date: Tue, 14 Oct 2008 06:50:12 -0700
Subject: New PortMgr team announced!
In-Reply-To: <606AE2C8-7721-45E1-826F-E0B65AA1F325@macports.org>
References: <606AE2C8-7721-45E1-826F-E0B65AA1F325@macports.org>
Message-ID: <E7D20381-7393-401F-8AB7-8AE584FE6332@gmail.com>

Congratulations!

On Oct 14, 2008, at 6:39 AM, James Berry wrote:

> The (current) PortMgr team is pleased to be able to announce the  
> appointment of a new PortMgr team.
>
> Four people expressed interest in the PortMgr positions, and have  
> all been appointed by proclamation:
>
> 	Ryan Schmidt
> 	Rainer M?ller
> 	Joshua Root
> 	Bryan Blackburn
>
> We, the (previous) members of the PortMgr team, will do all we can  
> to assist in a transition to the new members. As previously  
> discussed, we will move to a group (loosely and temporarily named  
> the "MacPorts Council of Elders") which serves as an advisory board  
> to the project.
>
> Please welcome Ryan, Rainer, Joshua, and Bryan, and direct further  
> questions at them ;)
>
> Sincerely, the past portmgr members,
>
> Juan, Markus, James
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


From florian.ebeling at gmail.com  Tue Oct 14 07:03:12 2008
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Tue, 14 Oct 2008 16:03:12 +0200
Subject: New PortMgr team announced!
In-Reply-To: <606AE2C8-7721-45E1-826F-E0B65AA1F325@macports.org>
References: <606AE2C8-7721-45E1-826F-E0B65AA1F325@macports.org>
Message-ID: <5cbbe4ae0810140703s4e23edaftc18ae64bf74fe62c@mail.gmail.com>

On Tue, Oct 14, 2008 at 3:39 PM, James Berry <jberry at macports.org> wrote:
> The (current) PortMgr team is pleased to be able to announce the appointment
> of a new PortMgr team.
>
> Four people expressed interest in the PortMgr positions, and have all been
> appointed by proclamation:
>
>        Ryan Schmidt
>        Rainer M?ller
>        Joshua Root
>        Bryan Blackburn
>
> We, the (previous) members of the PortMgr team, will do all we can to assist
> in a transition to the new members.

Congratulations, guys! Also I'm happy that I got all of my candidates
through ;)

Looking forward to work with you making mp a bliss to use again.

Florian





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

From macsforever2000 at macports.org  Tue Oct 14 08:27:06 2008
From: macsforever2000 at macports.org (Frank Schima)
Date: Tue, 14 Oct 2008 09:27:06 -0600
Subject: New PortMgr team announced!
In-Reply-To: <606AE2C8-7721-45E1-826F-E0B65AA1F325@macports.org>
References: <606AE2C8-7721-45E1-826F-E0B65AA1F325@macports.org>
Message-ID: <0CA11CF9-E3E5-4634-9298-4B2CA70E5328@macports.org>


On Oct 14, 2008, at 7:39 AM, James Berry wrote:

> The (current) PortMgr team is pleased to be able to announce the  
> appointment of a new PortMgr team.
>
> Four people expressed interest in the PortMgr positions, and have  
> all been appointed by proclamation:
>
> 	Ryan Schmidt
> 	Rainer M?ller
> 	Joshua Root
> 	Bryan Blackburn
>
> We, the (previous) members of the PortMgr team, will do all we can  
> to assist in a transition to the new members. As previously  
> discussed, we will move to a group (loosely and temporarily named  
> the "MacPorts Council of Elders") which serves as an advisory board  
> to the project.
>
> Please welcome Ryan, Rainer, Joshua, and Bryan, and direct further  
> questions at them ;)
>
> Sincerely, the past portmgr members,
>
> Juan, Markus, James

Congratulations!! This is a very strong team and hopefully we can  
break through some roadblocks (the 1.7 release of MacPorts comes to  
mind).

Now can someone get Bryan svn commit access? ;)


Cheers!
Frank


From ernest.prabhakar at gmail.com  Tue Oct 14 09:12:04 2008
From: ernest.prabhakar at gmail.com (Ernest Prabhakar)
Date: Tue, 14 Oct 2008 09:12:04 -0700
Subject: Terms? Re: New PortMgr team announced!
In-Reply-To: <606AE2C8-7721-45E1-826F-E0B65AA1F325@macports.org>
References: <606AE2C8-7721-45E1-826F-E0B65AA1F325@macports.org>
Message-ID: <9D65E61F-4600-4BB8-9D2E-C022CBA327A1@gmail.com>

Hi James et al,

Are there any explicit "terms of service" (in both senses of the  
phrase :-)?

I'd like to propose that the new team commit to serve from Oct 1st,  
2008  (retroactively) to Oct 1st, 2009, with an option for them to  
renew in one year blocks.

In particular, they need to indicate their desire to continue as  
PortMgr by July 1st, 2009, so as to give plenty of notice in case they  
need a replacement.

Is that reasonable?

-- Ernie P.

On Oct 14, 2008, at 6:39 AM, James Berry wrote:

> The (current) PortMgr team is pleased to be able to announce the  
> appointment of a new PortMgr team.
>
> Four people expressed interest in the PortMgr positions, and have  
> all been appointed by proclamation:
>
> 	Ryan Schmidt
> 	Rainer M?ller
> 	Joshua Root
> 	Bryan Blackburn
>
> We, the (previous) members of the PortMgr team, will do all we can  
> to assist in a transition to the new members. As previously  
> discussed, we will move to a group (loosely and temporarily named  
> the "MacPorts Council of Elders") which serves as an advisory board  
> to the project.
>
> Please welcome Ryan, Rainer, Joshua, and Bryan, and direct further  
> questions at them ;)
>
> Sincerely, the past portmgr members,
>
> Juan, Markus, James
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


From jkh at apple.com  Tue Oct 14 10:49:57 2008
From: jkh at apple.com (Jordan K. Hubbard)
Date: Tue, 14 Oct 2008 10:49:57 -0700
Subject: New PortMgr team announced!
In-Reply-To: <606AE2C8-7721-45E1-826F-E0B65AA1F325@macports.org>
References: <606AE2C8-7721-45E1-826F-E0B65AA1F325@macports.org>
Message-ID: <AF50AC12-4A1B-42DA-A5B6-5A44DED61AA7@apple.com>

Awesome!  I would like to suggest to the new PortMgr team that, as  
their first official act, they quickly appoint some folks to do  
Release Engineering duties before those someones change their minds. :-)

- Jordan

On Oct 14, 2008, at 6:39 AM, James Berry wrote:

> The (current) PortMgr team is pleased to be able to announce the  
> appointment of a new PortMgr team.
>
> Four people expressed interest in the PortMgr positions, and have  
> all been appointed by proclamation:
>
> 	Ryan Schmidt
> 	Rainer M?ller
> 	Joshua Root
> 	Bryan Blackburn
>
> We, the (previous) members of the PortMgr team, will do all we can  
> to assist in a transition to the new members. As previously  
> discussed, we will move to a group (loosely and temporarily named  
> the "MacPorts Council of Elders") which serves as an advisory board  
> to the project.
>
> Please welcome Ryan, Rainer, Joshua, and Bryan, and direct further  
> questions at them ;)
>
> Sincerely, the past portmgr members,
>
> Juan, Markus, James
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


From lists-macports at shopwatch.org  Tue Oct 14 12:20:45 2008
From: lists-macports at shopwatch.org (Jay Levitt)
Date: Tue, 14 Oct 2008 15:20:45 -0400
Subject: Terms? Re: New PortMgr team announced!
In-Reply-To: <9D65E61F-4600-4BB8-9D2E-C022CBA327A1@gmail.com>
References: <606AE2C8-7721-45E1-826F-E0B65AA1F325@macports.org>
	<9D65E61F-4600-4BB8-9D2E-C022CBA327A1@gmail.com>
Message-ID: <48F4F10D.1000603@shopwatch.org>

Ernest Prabhakar wrote:
> Hi James et al,
> 
> Are there any explicit "terms of service" (in both senses of the  
> phrase :-)?

Personally, I think it's high past time to throw the bums out!  This 
announcement went out over three hours ago, and I still don't see any binary 
packages.  My platform is "86,400 or fight".  Who's with me?

Seriously, congrats to all.

Jay


From ryandesign at macports.org  Tue Oct 14 15:05:57 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 14 Oct 2008 17:05:57 -0500
Subject: applications_dir under prefix (was: Re: Framework install
	location)
In-Reply-To: <c24012060810140206k7850a168i31a18f30bcf39452@mail.gmail.com>
References: <20081011212322.GF771@ninagal.withay.com>
	<EF08C657-FD89-4A3E-910F-AE5B75F1E982@macports.org>
	<CC735966-5026-4C84-971D-53BD35CCC853@macports.org>
	<c24012060810140206k7850a168i31a18f30bcf39452@mail.gmail.com>
Message-ID: <F205FEC9-406B-48D1-9D66-371C3E909E5F@macports.org>


On Oct 14, 2008, at 04:06, Randall Wood wrote:

>> I don't know the implications of having the frameworks outside of /
>> Library/Frameworks (e.g. in ${prefix}/Library/Frameworks) but for
>> applications I thought the point was that the OS wouldn't know about
>> them (e.g. things like "open -a foo" wouldn't work unless foo.app was
>> somewhere under /Applications). Though testing this right now, I
>> can't reproduce that.
>>
>> If that is a problem, we could have MacPorts create a symlink at /
>> Applications/MacPorts pointing to ${prefix}/Applications/MacPorts if
>> one does not already exist (if installing as root). This would
>> satisfy the majority of users who have just a single installation,
>> but still work fine for those with multiple installations. Finally
>> there could be a configure switch to not make that symlink.
>
> Symlinks break in the 'list view' for the Applications folder in the
> Dock. If you drag your applications folder to the dock, and place it
> in list view, you get a "menu" of applications. Subfolders can be
> navigated through like submenus, but symlinks are not followed. I'd
> keep applications in /Applications/MacPorts

Ok, those sound like convincing reasons to me.


From jberry at macports.org  Tue Oct 14 15:17:04 2008
From: jberry at macports.org (James Berry)
Date: Tue, 14 Oct 2008 15:17:04 -0700
Subject: Terms? Re: New PortMgr team announced!
In-Reply-To: <9D65E61F-4600-4BB8-9D2E-C022CBA327A1@gmail.com>
References: <606AE2C8-7721-45E1-826F-E0B65AA1F325@macports.org>
	<9D65E61F-4600-4BB8-9D2E-C022CBA327A1@gmail.com>
Message-ID: <9FF6ECD0-D380-4E3A-AD38-EDB4C7F2F29C@macports.org>

Hi Ernie,

Your question is an excellent one, and probably one best addressed by  
the new portmgr team...  I think your proposal sounds good.

James

On Oct 14, 2008, at 9:12 AM, Ernest Prabhakar wrote:

> Hi James et al,
>
> Are there any explicit "terms of service" (in both senses of the  
> phrase :-)?
>
> I'd like to propose that the new team commit to serve from Oct 1st,  
> 2008  (retroactively) to Oct 1st, 2009, with an option for them to  
> renew in one year blocks.
>
> In particular, they need to indicate their desire to continue as  
> PortMgr by July 1st, 2009, so as to give plenty of notice in case  
> they need a replacement.
>
> Is that reasonable?
>
> -- Ernie P.
>
> On Oct 14, 2008, at 6:39 AM, James Berry wrote:
>
>> The (current) PortMgr team is pleased to be able to announce the  
>> appointment of a new PortMgr team.
>>
>> Four people expressed interest in the PortMgr positions, and have  
>> all been appointed by proclamation:
>>
>> 	Ryan Schmidt
>> 	Rainer M?ller
>> 	Joshua Root
>> 	Bryan Blackburn
>>
>> We, the (previous) members of the PortMgr team, will do all we can  
>> to assist in a transition to the new members. As previously  
>> discussed, we will move to a group (loosely and temporarily named  
>> the "MacPorts Council of Elders") which serves as an advisory board  
>> to the project.
>>
>> Please welcome Ryan, Rainer, Joshua, and Bryan, and direct further  
>> questions at them ;)
>>
>> Sincerely, the past portmgr members,
>>
>> Juan, Markus, James
>>
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>


From jmr at macports.org  Tue Oct 14 15:21:36 2008
From: jmr at macports.org (Joshua Root)
Date: Wed, 15 Oct 2008 09:21:36 +1100
Subject: Terms? Re: New PortMgr team announced!
In-Reply-To: <9D65E61F-4600-4BB8-9D2E-C022CBA327A1@gmail.com>
References: <606AE2C8-7721-45E1-826F-E0B65AA1F325@macports.org>
	<9D65E61F-4600-4BB8-9D2E-C022CBA327A1@gmail.com>
Message-ID: <48F51B70.6050403@macports.org>

Ernest Prabhakar wrote:
> Hi James et al,
> 
> Are there any explicit "terms of service" (in both senses of the  
> phrase :-)?
> 
> I'd like to propose that the new team commit to serve from Oct 1st,  
> 2008  (retroactively) to Oct 1st, 2009, with an option for them to  
> renew in one year blocks.
> 
> In particular, they need to indicate their desire to continue as  
> PortMgr by July 1st, 2009, so as to give plenty of notice in case they  
> need a replacement.
> 
> Is that reasonable?

Sounds fine to me.

- Josh

From ryandesign at macports.org  Tue Oct 14 16:22:40 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 14 Oct 2008 18:22:40 -0500
Subject: [40784] trunk/dports/devel/distract/Portfile
In-Reply-To: <20081014223815.A70114EAFCC@beta.macosforge.org>
References: <20081014223815.A70114EAFCC@beta.macosforge.org>
Message-ID: <FEC27E65-3592-4284-B2BD-2586A84935DA@macports.org>


On Oct 14, 2008, at 17:38, tommyd at macports.org wrote:

> Revision: 40784
>           http://trac.macports.org/changeset/40784
> Author:   tommyd at macports.org
> Date:     2008-10-14 15:38:14 -0700 (Tue, 14 Oct 2008)
> Log Message:
> -----------
> * distract: make the port's name lowercase so it matches the  
> directory and makes port lint happy
>
> Modified Paths:
> --------------
>     trunk/dports/devel/distract/Portfile
>
> Modified: trunk/dports/devel/distract/Portfile
> ===================================================================
> --- trunk/dports/devel/distract/Portfile	2008-10-14 22:27:30 UTC  
> (rev 40783)
> +++ trunk/dports/devel/distract/Portfile	2008-10-14 22:38:14 UTC  
> (rev 40784)
> @@ -2,7 +2,7 @@
>
>  PortSystem 1.0
>
> -name		DisTract
> +name		distract
>  version		0.2.5
>  categories	devel
>  maintainers	tommyd

Have you tested what happens if a user has "DisTract" installed and  
then you update the port to a new version when it's called "distract"  
and the user needs to upgrade? Does "port outdated" consider  
"DisTract" and "distract" to be the same thing -- does it properly  
suggest the new version? Does the upgrade work properly?

Probably when the port name and directory name do not match, it's  
better to change the directory name rather than the port name.  
Perhaps the lint message should be changed to suggest that.



From jmr at macports.org  Tue Oct 14 16:46:19 2008
From: jmr at macports.org (Joshua Root)
Date: Wed, 15 Oct 2008 10:46:19 +1100
Subject: [40784] trunk/dports/devel/distract/Portfile
In-Reply-To: <FEC27E65-3592-4284-B2BD-2586A84935DA@macports.org>
References: <20081014223815.A70114EAFCC@beta.macosforge.org>
	<FEC27E65-3592-4284-B2BD-2586A84935DA@macports.org>
Message-ID: <48F52F4B.8020309@macports.org>

Ryan Schmidt wrote:
> Have you tested what happens if a user has "DisTract" installed and  
> then you update the port to a new version when it's called "distract"  
> and the user needs to upgrade? Does "port outdated" consider  
> "DisTract" and "distract" to be the same thing -- does it properly  
> suggest the new version? Does the upgrade work properly?
> 
> Probably when the port name and directory name do not match, it's  
> better to change the directory name rather than the port name.  
> Perhaps the lint message should be changed to suggest that.

Port names are case insensitive in trunk, but I'm not so sure this will
work properly in 1.6.

- Josh

From tommyd at macports.org  Tue Oct 14 16:54:59 2008
From: tommyd at macports.org (Thomas Keller)
Date: Wed, 15 Oct 2008 01:54:59 +0200
Subject: [40784] trunk/dports/devel/distract/Portfile
In-Reply-To: <FEC27E65-3592-4284-B2BD-2586A84935DA@macports.org>
References: <20081014223815.A70114EAFCC@beta.macosforge.org>
	<FEC27E65-3592-4284-B2BD-2586A84935DA@macports.org>
Message-ID: <48F53153.3050809@macports.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ryan Schmidt schrieb:
> 
> On Oct 14, 2008, at 17:38, tommyd at macports.org wrote:
> 
>> Revision: 40784
>>           http://trac.macports.org/changeset/40784
>> Author:   tommyd at macports.org
>> Date:     2008-10-14 15:38:14 -0700 (Tue, 14 Oct 2008)
>> Log Message:
>> -----------
>> * distract: make the port's name lowercase so it matches the directory
>> and makes port lint happy
>>
>> Modified Paths:
>> --------------
>>     trunk/dports/devel/distract/Portfile
>>
>> Modified: trunk/dports/devel/distract/Portfile
>> ===================================================================
>> --- trunk/dports/devel/distract/Portfile    2008-10-14 22:27:30 UTC
>> (rev 40783)
>> +++ trunk/dports/devel/distract/Portfile    2008-10-14 22:38:14 UTC
>> (rev 40784)
>> @@ -2,7 +2,7 @@
>>
>>  PortSystem 1.0
>>
>> -name        DisTract
>> +name        distract
>>  version        0.2.5
>>  categories    devel
>>  maintainers    tommyd
> 
> Have you tested what happens if a user has "DisTract" installed and then
> you update the port to a new version when it's called "distract" and the
> user needs to upgrade? Does "port outdated" consider "DisTract" and
> "distract" to be the same thing -- does it properly suggest the new
> version? Does the upgrade work properly?

Hrm... I raised the version number temporarily to the non-existant
version 0.2.6, rebuilded my local port index and it seems as if port
outdated does not pick this up.

I've seen "set canonicalname" in a couple of haskell-related ports -
could this be used to set "distract" and leave name intact while making
port lint happy?

> Probably when the port name and directory name do not match, it's better
> to change the directory name rather than the port name. Perhaps the lint
> message should be changed to suggest that.

I've ask on IRC and it was suggested that the port name is changed,
because it would have made problems on case insensitive file systems
(since only the case changed).

Alternatively I could probably remove this port altogether, since the
author stated in a personal email a couple of months ago, that he has no
more time nor interest continueing the project. Are there any guidelines
when ports should be removed?

Thomas.

- --
GPG-Key 0x160D1092 | tommyd3mdi at jabber.ccc.de | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkj1MVMACgkQaf7NlBYNEJIqcQCg/Sw6c9MeXAYLFVNiUkcf63Er
J+QAn3rDgr7ampe+2S0tf57rVlPc+W6b
=gLm5
-----END PGP SIGNATURE-----

From ryandesign at macports.org  Tue Oct 14 17:40:25 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 14 Oct 2008 19:40:25 -0500
Subject: [40784] trunk/dports/devel/distract/Portfile
In-Reply-To: <48F52F4B.8020309@macports.org>
References: <20081014223815.A70114EAFCC@beta.macosforge.org>
	<FEC27E65-3592-4284-B2BD-2586A84935DA@macports.org>
	<48F52F4B.8020309@macports.org>
Message-ID: <8CFA1AF2-F435-4A7A-A3A2-CB552D29448D@macports.org>

On Oct 14, 2008, at 18:46, Joshua Root wrote:

> Ryan Schmidt wrote:
>
>> Have you tested what happens if a user has "DisTract" installed and
>> then you update the port to a new version when it's called "distract"
>> and the user needs to upgrade? Does "port outdated" consider
>> "DisTract" and "distract" to be the same thing -- does it properly
>> suggest the new version? Does the upgrade work properly?
>>
>> Probably when the port name and directory name do not match, it's
>> better to change the directory name rather than the port name.
>> Perhaps the lint message should be changed to suggest that.
>
> Port names are case insensitive in trunk, but I'm not so sure this  
> will
> work properly in 1.6.

Are you telling me we should have those new portmgrs actually do a  
release? :P


From ryandesign at macports.org  Tue Oct 14 18:06:54 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 14 Oct 2008 20:06:54 -0500
Subject: [40784] trunk/dports/devel/distract/Portfile
In-Reply-To: <48F53153.3050809@macports.org>
References: <20081014223815.A70114EAFCC@beta.macosforge.org>
	<FEC27E65-3592-4284-B2BD-2586A84935DA@macports.org>
	<48F53153.3050809@macports.org>
Message-ID: <7605EB63-62BD-4544-A929-FCF1ACA31CBE@macports.org>

On Oct 14, 2008, at 18:54, Thomas Keller wrote:

> Ryan Schmidt schrieb:
>
>> On Oct 14, 2008, at 17:38, tommyd at macports.org wrote:
>>
>>> Revision: 40784
>>>           http://trac.macports.org/changeset/40784
>>> Author:   tommyd at macports.org
>>> Date:     2008-10-14 15:38:14 -0700 (Tue, 14 Oct 2008)
>>> Log Message:
>>> -----------
>>> * distract: make the port's name lowercase so it matches the  
>>> directory
>>> and makes port lint happy
>>>
>>> Modified Paths:
>>> --------------
>>>     trunk/dports/devel/distract/Portfile
>>>
>>> Modified: trunk/dports/devel/distract/Portfile
>>> ===================================================================
>>> --- trunk/dports/devel/distract/Portfile    2008-10-14 22:27:30 UTC
>>> (rev 40783)
>>> +++ trunk/dports/devel/distract/Portfile    2008-10-14 22:38:14 UTC
>>> (rev 40784)
>>> @@ -2,7 +2,7 @@
>>>
>>>  PortSystem 1.0
>>>
>>> -name        DisTract
>>> +name        distract
>>>  version        0.2.5
>>>  categories    devel
>>>  maintainers    tommyd
>>
>> Have you tested what happens if a user has "DisTract" installed  
>> and then
>> you update the port to a new version when it's called "distract"  
>> and the
>> user needs to upgrade? Does "port outdated" consider "DisTract" and
>> "distract" to be the same thing -- does it properly suggest the new
>> version? Does the upgrade work properly?
>
> Hrm... I raised the version number temporarily to the non-existant
> version 0.2.6, rebuilded my local port index and it seems as if port
> outdated does not pick this up.

I suspected this might happen, though perhaps as JMR says it will  
work with MacPorts trunk.

> I've seen "set canonicalname" in a couple of haskell-related ports -
> could this be used to set "distract" and leave name intact while  
> making
> port lint happy?

I don't think that will help. port lint is just telling you the name  
of the port (its ${name} variable) and the name of the directory the  
Portfile is in should match, including case.


>> Probably when the port name and directory name do not match, it's  
>> better
>> to change the directory name rather than the port name. Perhaps  
>> the lint
>> message should be changed to suggest that.
>
> I've ask on IRC and it was suggested that the port name is changed,
> because it would have made problems on case insensitive file systems
> (since only the case changed).

Blah. That's true, that can be a problem too. I'm not sure how rsync  
handles it. I think those using a Subversion working copy it might  
need to do something special to update:

http://subversion.tigris.org/faq.html#case-change


> Alternatively I could probably remove this port altogether, since the
> author stated in a personal email a couple of months ago, that he  
> has no
> more time nor interest continueing the project. Are there any  
> guidelines
> when ports should be removed?

If the software is still useful to you or others, we can keep it,  
even if it's not being updated. Unfortunately we gather no statistics  
on how many people use which ports.

Once the port no longer works with newer OS versions and it cannot be  
fixed, then it might be time to think about removing it.



From ryandesign at macports.org  Tue Oct 14 22:57:56 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 15 Oct 2008 00:57:56 -0500
Subject: New PortMgr team announced!
In-Reply-To: <606AE2C8-7721-45E1-826F-E0B65AA1F325@macports.org>
References: <606AE2C8-7721-45E1-826F-E0B65AA1F325@macports.org>
Message-ID: <10A4F7C7-A0AD-4467-8597-DEBB9D31481B@macports.org>

On Oct 14, 2008, at 08:39, James Berry wrote:

> The (current) PortMgr team is pleased to be able to announce the  
> appointment of a new PortMgr team.
>
> Four people expressed interest in the PortMgr positions, and have  
> all been appointed by proclamation:
>
> 	Ryan Schmidt
> 	Rainer M?ller
> 	Joshua Root
> 	Bryan Blackburn
>
> We, the (previous) members of the PortMgr team, will do all we can  
> to assist in a transition to the new members. As previously  
> discussed, we will move to a group (loosely and temporarily named  
> the "MacPorts Council of Elders") which serves as an advisory board  
> to the project.
>
> Please welcome Ryan, Rainer, Joshua, and Bryan, and direct further  
> questions at them ;)
>
> Sincerely, the past portmgr members,
>
> Juan, Markus, James

Thank you all! I'm delighted to continue to serve the project in the  
new capacity of portmgr. Let's get this party started! :)


From ryandesign at macports.org  Wed Oct 15 14:23:05 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 15 Oct 2008 16:23:05 -0500
Subject: [40810] trunk/dports/perl/p5-datetime-timezone/Portfile
In-Reply-To: <20081015140445.2E3094F0173@beta.macosforge.org>
References: <20081015140445.2E3094F0173@beta.macosforge.org>
Message-ID: <AE4DE68A-D0EA-4A3D-891E-A2FC26A05031@macports.org>

On Oct 15, 2008, at 09:04, narf_tm at macports.org wrote:

> Revision: 40810
>           http://trac.macports.org/changeset/40810
> Author:   narf_tm at macports.org
> Date:     2008-10-15 07:04:44 -0700 (Wed, 15 Oct 2008)
> Log Message:
> -----------
> Updated to 0.82.
>
> Modified Paths:
> --------------
>     trunk/dports/perl/p5-datetime-timezone/Portfile
>
> Modified: trunk/dports/perl/p5-datetime-timezone/Portfile
> ===================================================================
> --- trunk/dports/perl/p5-datetime-timezone/Portfile	2008-10-15  
> 14:02:22 UTC (rev 40809)
> +++ trunk/dports/perl/p5-datetime-timezone/Portfile	2008-10-15  
> 14:04:44 UTC (rev 40810)
> @@ -3,8 +3,8 @@
>  PortSystem                1.0
>  PortGroup                 perl5 1.0
>
> -perl5.setup               DateTime-TimeZone 0.81
> -epoch                     3
> +perl5.setup               DateTime-TimeZone 0.82
> +epoch                     4

FYI, there's no problem with increasing the epoch every time, but you  
don't need to unless you update the version in a way that's affected  
by #11873. For this update from 0.81 to 0.82, MacPorts should have no  
problem because "82" is greater than "81".



From ryan_ware at me.com  Wed Oct 15 15:11:05 2008
From: ryan_ware at me.com (Ware, Ryan R)
Date: Wed, 15 Oct 2008 18:11:05 -0400
Subject: Terms? Re: New PortMgr team announced!
In-Reply-To: <48F51B70.6050403@macports.org>
References: <606AE2C8-7721-45E1-826F-E0B65AA1F325@macports.org>
	<9D65E61F-4600-4BB8-9D2E-C022CBA327A1@gmail.com>
	<48F51B70.6050403@macports.org>
Message-ID: <01486A35-8F52-46D0-AD8B-BE8F889D995B@me.com>

Congratulations to the new Overlords.  All hail Kodos!

Seriously though, while some folks on the list want to know what the  
terms of the proclimation are, I suggest letting the PortMgr team work  
through getting a new release out the door so people can quit being  
informed about the postflight script.  In addition, they can make a  
dent in the pile of work that exists and take some time among  
themselves to determine what they'd like to propose.

I personally like the time limits let's see what the new team feels  
when then get the chance to catch a breath.

Ryan

On Oct 14, 2008, at 6:21 PM, Joshua Root wrote:

> Ernest Prabhakar wrote:
>> Hi James et al,
>>
>> Are there any explicit "terms of service" (in both senses of the
>> phrase :-)?
>>
>> I'd like to propose that the new team commit to serve from Oct 1st,
>> 2008  (retroactively) to Oct 1st, 2009, with an option for them to
>> renew in one year blocks.
>>
>> In particular, they need to indicate their desire to continue as
>> PortMgr by July 1st, 2009, so as to give plenty of notice in case  
>> they
>> need a replacement.
>>
>> Is that reasonable?
>
> Sounds fine to me.
>
> - Josh
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


From blb at macports.org  Thu Oct 16 21:38:33 2008
From: blb at macports.org (Bryan Blackburn)
Date: Thu, 16 Oct 2008 22:38:33 -0600
Subject: [40877] trunk/dports/textproc/libwpd/Portfile
In-Reply-To: <20081017041811.02B264FC680@beta.macosforge.org>
References: <20081017041811.02B264FC680@beta.macosforge.org>
Message-ID: <20081017043833.GK8046@ninagal.withay.com>

On Thu, Oct 16, 2008 at 09:18:10PM -0700, devans at macports.org said:
> Revision: 40877
>           http://trac.macports.org/changeset/40877
> Author:   devans at macports.org
[...]
>  name		libwpd
>  version		0.8.9
> -revision	1

I'm guessing you didn't mean to delete the revision here right?

Bryan

[...]

From devans at macports.org  Thu Oct 16 21:50:43 2008
From: devans at macports.org (David Evans)
Date: Thu, 16 Oct 2008 21:50:43 -0700
Subject: [40877] trunk/dports/textproc/libwpd/Portfile
In-Reply-To: <20081017043833.GK8046@ninagal.withay.com>
References: <20081017041811.02B264FC680@beta.macosforge.org>
	<20081017043833.GK8046@ninagal.withay.com>
Message-ID: <48F819A3.1070109@macports.org>

Bryan Blackburn wrote:
> On Thu, Oct 16, 2008 at 09:18:10PM -0700, devans at macports.org said:
>   
>> Revision: 40877
>>           http://trac.macports.org/changeset/40877
>> Author:   devans at macports.org
>>     
> [...]
>   
>>  name		libwpd
>>  version		0.8.9
>> -revision	1
>>     
>
> I'm guessing you didn't mean to delete the revision here right?
>
> Bryan
>
> [...]
>
>   
Sorry.  Was in the middle of a two step process (cleanup then update)
but I got ahead of
myself should be correct now at 0.8.14.  A dependency of a dependency
for inkscape.

From florian.ebeling at gmail.com  Thu Oct 16 23:54:42 2008
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Fri, 17 Oct 2008 08:54:42 +0200
Subject: Fwd: [40828] contrib/mpab/chroot-scripts/buildports
In-Reply-To: <20081015195826.9E7394F2592@beta.macosforge.org>
References: <20081015195826.9E7394F2592@beta.macosforge.org>
Message-ID: <5cbbe4ae0810162354v31504ccfh2c38bf75e329f17@mail.gmail.com>

Hi Bryan,

---------- Forwarded message ----------
From:  <blb at macports.org>
Date: Wed, Oct 15, 2008 at 9:58 PM
Subject: [40828] contrib/mpab/chroot-scripts/buildports
To: macports-changes at lists.macosforge.org


Revision 40828 Author blb at macports.org Date 2008-10-15 12:58:26 -0700
(Wed, 15 Oct 2008)

Log Message

Use deactivate instead of uninstall to speed up cleanup times between
each port build

Modified Paths

contrib/mpab/chroot-scripts/buildports

Diff

Modified: contrib/mpab/chroot-scripts/buildports (40827 => 40828)

--- contrib/mpab/chroot-scripts/buildports	2008-10-15 19:53:00 UTC (rev 40827)
+++ contrib/mpab/chroot-scripts/buildports	2008-10-15 19:58:26 UTC (rev 40828)
@@ -34,7 +34,7 @@
 {
    installedPorts=`/opt/local/bin/port installed | /usr/bin/tail +2 |
/usr/bin/awk '{print $1}'`
    for uninstallPort in $installedPorts; do
-      portOutput=`/opt/local/bin/port -dvf uninstall $uninstallPort 2>&1`
+      portOutput=`/opt/local/bin/port -dvf deactivate $uninstallPort 2>&1`
       if [[ $? != 0 ]]; then
          echo $portOutput
          break

I think this breaks things a bit. Running my little build server script
I noticed many more failing builds. They complain ultimately about
the port in question already being installed, after otherwise building fine.

This is due to the somewhat surprising behaviour that when
a port is deactivated and you run "port install", it builds right away
not looking if there was a deactivated one of the same version. Then
it tries to activate as well, and that fails. One could argue that install
should resolve a by looking at deactivated installs first, though.

Florian


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

From blb at macports.org  Fri Oct 17 00:30:03 2008
From: blb at macports.org (Bryan Blackburn)
Date: Fri, 17 Oct 2008 01:30:03 -0600
Subject: Fwd: [40828] contrib/mpab/chroot-scripts/buildports
In-Reply-To: <5cbbe4ae0810162354v31504ccfh2c38bf75e329f17@mail.gmail.com>
References: <20081015195826.9E7394F2592@beta.macosforge.org>
	<5cbbe4ae0810162354v31504ccfh2c38bf75e329f17@mail.gmail.com>
Message-ID: <20081017073003.GL8046@ninagal.withay.com>

On Fri, Oct 17, 2008 at 08:54:42AM +0200, C. Florian Ebeling said:
> Hi Bryan,
> 
[...]
> -      portOutput=`/opt/local/bin/port -dvf uninstall $uninstallPort 2>&1`
> +      portOutput=`/opt/local/bin/port -dvf deactivate $uninstallPort 2>&1`
>        if [[ $? != 0 ]]; then
>           echo $portOutput
>           break
> 
> I think this breaks things a bit. Running my little build server script
> I noticed many more failing builds. They complain ultimately about
> the port in question already being installed, after otherwise building fine.
> 

Is it running a trunk build?  It definitely had no issues with my trunk
build, but I didn't try it against a 1.6 build.

> This is due to the somewhat surprising behaviour that when
> a port is deactivated and you run "port install", it builds right away
> not looking if there was a deactivated one of the same version. Then
> it tries to activate as well, and that fails. One could argue that install
> should resolve a by looking at deactivated installs first, though.
> 
> Florian
> 
> 
> -- 
> Florian Ebeling
> Twitter: febeling
> florian.ebeling at gmail.com

From florian.ebeling at gmail.com  Fri Oct 17 02:53:37 2008
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Fri, 17 Oct 2008 11:53:37 +0200
Subject: Fwd: [40828] contrib/mpab/chroot-scripts/buildports
In-Reply-To: <20081017073003.GL8046@ninagal.withay.com>
References: <20081015195826.9E7394F2592@beta.macosforge.org>
	<5cbbe4ae0810162354v31504ccfh2c38bf75e329f17@mail.gmail.com>
	<20081017073003.GL8046@ninagal.withay.com>
Message-ID: <5cbbe4ae0810170253s45ee0be6i9108266326523b25@mail.gmail.com>

On Fri, Oct 17, 2008 at 9:30 AM, Bryan Blackburn <blb at macports.org> wrote:
> On Fri, Oct 17, 2008 at 08:54:42AM +0200, C. Florian Ebeling said:
>> Hi Bryan,
>>
> [...]
>> -      portOutput=`/opt/local/bin/port -dvf uninstall $uninstallPort 2>&1`
>> +      portOutput=`/opt/local/bin/port -dvf deactivate $uninstallPort 2>&1`
>>        if [[ $? != 0 ]]; then
>>           echo $portOutput
>>           break
>>
>> I think this breaks things a bit. Running my little build server script
>> I noticed many more failing builds. They complain ultimately about
>> the port in question already being installed, after otherwise building fine.
>>
>
> Is it running a trunk build?  It definitely had no issues with my trunk
> build, but I didn't try it against a 1.6 build.

yes, running trunk, and I dropped the mp-shadow image.
Also when I rolled back that revision all the failing ports
succeed again.

Did you run it with a larger set of ports as well, or even all?

Florian



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

From florian.ebeling at gmail.com  Fri Oct 17 03:23:36 2008
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Fri, 17 Oct 2008 12:23:36 +0200
Subject: Fwd: [40828] contrib/mpab/chroot-scripts/buildports
In-Reply-To: <5cbbe4ae0810170253s45ee0be6i9108266326523b25@mail.gmail.com>
References: <20081015195826.9E7394F2592@beta.macosforge.org>
	<5cbbe4ae0810162354v31504ccfh2c38bf75e329f17@mail.gmail.com>
	<20081017073003.GL8046@ninagal.withay.com>
	<5cbbe4ae0810170253s45ee0be6i9108266326523b25@mail.gmail.com>
Message-ID: <5cbbe4ae0810170323n46029358s8aab90316e84d6ba@mail.gmail.com>

On Fri, Oct 17, 2008 at 11:53 AM, C. Florian Ebeling
<florian.ebeling at gmail.com> wrote:
> On Fri, Oct 17, 2008 at 9:30 AM, Bryan Blackburn <blb at macports.org> wrote:
>> On Fri, Oct 17, 2008 at 08:54:42AM +0200, C. Florian Ebeling said:
>>> I think this breaks things a bit. Running my little build server script
>>> I noticed many more failing builds. They complain ultimately about
>>> the port in question already being installed, after otherwise building fine.
>>
>> Is it running a trunk build?  It definitely had no issues with my trunk
>> build, but I didn't try it against a 1.6 build.

This is the effect I mean:

# port installed tree
The following ports are currently installed:
  tree @1.5.1.1_0 (active)
# port deactivate tree
--->  Deactivating tree
# port install tree
--->  Installing tree @1.5.1.1_0
Error: Target org.macports.install returned: Registry error: tree
@1.5.1.1_0 already registered as installed.  Please uninstall it
first.
Error: Status 1 encountered during processing.

Florian


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

From simon at ruderich.org  Fri Oct 17 06:48:36 2008
From: simon at ruderich.org (Simon Ruderich)
Date: Fri, 17 Oct 2008 15:48:36 +0200
Subject: Mercurial fetch support
Message-ID: <20081017134836.GA1784@ruderich.org>

Hi,

I added support to fetch via Mercurial [1]. But as I don't know anything about
autoconf I didn't add anything to port_autoconf.tcl.in or configure.ac.

Please tell what changes I have to make so the path to hg is available in
hg_path like it's now with git_path.

Thanks,
Simon

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

From blb at macports.org  Fri Oct 17 11:47:51 2008
From: blb at macports.org (Bryan Blackburn)
Date: Fri, 17 Oct 2008 12:47:51 -0600
Subject: Fwd: [40828] contrib/mpab/chroot-scripts/buildports
In-Reply-To: <5cbbe4ae0810170253s45ee0be6i9108266326523b25@mail.gmail.com>
References: <20081015195826.9E7394F2592@beta.macosforge.org>
	<5cbbe4ae0810162354v31504ccfh2c38bf75e329f17@mail.gmail.com>
	<20081017073003.GL8046@ninagal.withay.com>
	<5cbbe4ae0810170253s45ee0be6i9108266326523b25@mail.gmail.com>
Message-ID: <20081017184751.GE68596@ninagal.withay.com>

On Fri, Oct 17, 2008 at 11:53:37AM +0200, C. Florian Ebeling said:
> On Fri, Oct 17, 2008 at 9:30 AM, Bryan Blackburn <blb at macports.org> wrote:
> > On Fri, Oct 17, 2008 at 08:54:42AM +0200, C. Florian Ebeling said:
> >> Hi Bryan,
> >>
> > [...]
> >> -      portOutput=`/opt/local/bin/port -dvf uninstall $uninstallPort 2>&1`
> >> +      portOutput=`/opt/local/bin/port -dvf deactivate $uninstallPort 2>&1`
> >>        if [[ $? != 0 ]]; then
> >>           echo $portOutput
> >>           break
> >>
> >> I think this breaks things a bit. Running my little build server script
> >> I noticed many more failing builds. They complain ultimately about
> >> the port in question already being installed, after otherwise building fine.
> >>
> >
> > Is it running a trunk build?  It definitely had no issues with my trunk
> > build, but I didn't try it against a 1.6 build.
> 
> yes, running trunk, and I dropped the mp-shadow image.
> Also when I rolled back that revision all the failing ports
> succeed again.
> 

Definitely strange, I ran quite a few ports through it once I initially made
that change locally.  I'll give it a try again in the next couple of days
and see if fails for me this time.

> Did you run it with a larger set of ports as well, or even all?

Definitely not all, that'd take forever on my MBP, I usually let it build
150-200 as a test, but I let it run without a port list and kill it after a
while.

Bryan


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

From florian.ebeling at gmail.com  Fri Oct 17 12:08:54 2008
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Fri, 17 Oct 2008 21:08:54 +0200
Subject: Fwd: [40828] contrib/mpab/chroot-scripts/buildports
In-Reply-To: <20081017184751.GE68596@ninagal.withay.com>
References: <20081015195826.9E7394F2592@beta.macosforge.org>
	<5cbbe4ae0810162354v31504ccfh2c38bf75e329f17@mail.gmail.com>
	<20081017073003.GL8046@ninagal.withay.com>
	<5cbbe4ae0810170253s45ee0be6i9108266326523b25@mail.gmail.com>
	<20081017184751.GE68596@ninagal.withay.com>
Message-ID: <5cbbe4ae0810171208r2cc4b6edmaa42ae22a3531f10@mail.gmail.com>

On Fri, Oct 17, 2008 at 8:47 PM, Bryan Blackburn <blb at macports.org> wrote:
> On Fri, Oct 17, 2008 at 11:53:37AM +0200, C. Florian Ebeling said:
>> On Fri, Oct 17, 2008 at 9:30 AM, Bryan Blackburn <blb at macports.org> wrote:
>> > On Fri, Oct 17, 2008 at 08:54:42AM +0200, C. Florian Ebeling said:
>> >> Hi Bryan,
>> >>
>> > [...]
>> >> -      portOutput=`/opt/local/bin/port -dvf uninstall $uninstallPort 2>&1`
>> >> +      portOutput=`/opt/local/bin/port -dvf deactivate $uninstallPort 2>&1`
>> >>        if [[ $? != 0 ]]; then
>> >>           echo $portOutput
>> >>           break
> Definitely not all, that'd take forever on my MBP, I usually let it build
> 150-200 as a test, but I let it run without a port list and kill it after a
> while.

But mpab sorts the list of ports on dependencies before running, so they
maybe have all zero dependencies at the start. And those should indeed
not be effected, because they get explicitly uninstalled, other than the
dependency ports. I think that explains it :)

Florian




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

From ryandesign at macports.org  Fri Oct 17 14:59:05 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 17 Oct 2008 16:59:05 -0500
Subject: [40890] trunk/dports/multimedia/libtheora
In-Reply-To: <20081017080541.348AF4FDB09@beta.macosforge.org>
References: <20081017080541.348AF4FDB09@beta.macosforge.org>
Message-ID: <3DF84BC0-1C1A-45BB-9637-5808B94AFBD1@macports.org>


On Oct 17, 2008, at 03:05, boeyms at macports.org wrote:

> Revision: 40890
>           http://trac.macports.org/changeset/40890
> Author:   boeyms at macports.org
> Date:     2008-10-17 01:05:40 -0700 (Fri, 17 Oct 2008)
> Log Message:
> -----------
> libtheora: update to latest version (1.0beta3).
>
> This changeset updates libtheora to version 1.0beta3, and includes  
> revisions
> to the patches required to make it compile.  Those patches have  
> been further
> split from the previous monolithic patch file into one per changed  
> file, as
> per the MacPorts documentation.

Note that the documentation does say:

"You should create one patch file for each file to be patched, though  
it is permissible to use existing patches you find that patch  
multiple files."

http://guide.macports.org/#development.patches.source

I think we decided, though the documentation doesn't reflect that  
yet, that one patch per issue is also permissible. If you need to  
patch multiple files to fix one issue, then it's fine (perhaps even  
clearer) to put them all into a single patch file.


From ryandesign at macports.org  Fri Oct 17 15:27:14 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 17 Oct 2008 17:27:14 -0500
Subject: Remove ftp.uu.net from gnu fetch group
Message-ID: <3296FC25-8E9C-45E1-A036-D8287749B841@macports.org>

The readline port uses the gnu fetch group to download.

ftp://ftp.uu.net/archive/systems/gnu/ is in that group.

But ftp://ftp.uu.net/archive/systems/gnu/readline/ doesn't appear to  
have any current readline files.

All modifications dates on that server seem to be 2001-06-29. If the  
mirror hasn't been updated since then, we should remove it from the  
list of gnu mirrors.

Comments?


From blb at macports.org  Fri Oct 17 15:59:30 2008
From: blb at macports.org (Bryan Blackburn)
Date: Fri, 17 Oct 2008 16:59:30 -0600
Subject: Remove ftp.uu.net from gnu fetch group
In-Reply-To: <3296FC25-8E9C-45E1-A036-D8287749B841@macports.org>
References: <3296FC25-8E9C-45E1-A036-D8287749B841@macports.org>
Message-ID: <20081017225929.GK68596@ninagal.withay.com>

On Fri, Oct 17, 2008 at 05:27:14PM -0500, Ryan Schmidt said:
> The readline port uses the gnu fetch group to download.
> 
> ftp://ftp.uu.net/archive/systems/gnu/ is in that group.
> 
> But ftp://ftp.uu.net/archive/systems/gnu/readline/ doesn't appear to  
> have any current readline files.
> 
> All modifications dates on that server seem to be 2001-06-29. If the  
> mirror hasn't been updated since then, we should remove it from the  
> list of gnu mirrors.
> 

I think there are several stale mirrors in gnu, gnupg, and a few other
lists; unfortunately I didn't keep track of which ones at the time.  I'd say
delete any that are obviously out of date like that one you list, and
long-term come up with something like livecheck only for mirror sites to
ease pruning.

Bryan


> Comments?
> 

From jmr at macports.org  Fri Oct 17 16:12:00 2008
From: jmr at macports.org (Joshua Root)
Date: Sat, 18 Oct 2008 10:12:00 +1100
Subject: Remove ftp.uu.net from gnu fetch group
In-Reply-To: <3296FC25-8E9C-45E1-A036-D8287749B841@macports.org>
References: <3296FC25-8E9C-45E1-A036-D8287749B841@macports.org>
Message-ID: <48F91BC0.9070701@macports.org>

Ryan Schmidt wrote:
> The readline port uses the gnu fetch group to download.
> 
> ftp://ftp.uu.net/archive/systems/gnu/ is in that group.
> 
> But ftp://ftp.uu.net/archive/systems/gnu/readline/ doesn't appear to  
> have any current readline files.
> 
> All modifications dates on that server seem to be 2001-06-29. If the  
> mirror hasn't been updated since then, we should remove it from the  
> list of gnu mirrors.
> 
> Comments?

Agreed, there's no point having such a stale mirror in the list.

- Josh

From ryandesign at macports.org  Fri Oct 17 16:19:50 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 17 Oct 2008 18:19:50 -0500
Subject: Remove ftp.uu.net from gnu fetch group
In-Reply-To: <48F91BC0.9070701@macports.org>
References: <3296FC25-8E9C-45E1-A036-D8287749B841@macports.org>
	<48F91BC0.9070701@macports.org>
Message-ID: <783E4014-3D21-4A61-850A-CAF035D18E86@macports.org>


On Oct 17, 2008, at 18:12, Joshua Root wrote:

> Ryan Schmidt wrote:
>> The readline port uses the gnu fetch group to download.
>>
>> ftp://ftp.uu.net/archive/systems/gnu/ is in that group.
>>
>> But ftp://ftp.uu.net/archive/systems/gnu/readline/ doesn't appear to
>> have any current readline files.
>>
>> All modifications dates on that server seem to be 2001-06-29. If the
>> mirror hasn't been updated since then, we should remove it from the
>> list of gnu mirrors.
>>
>> Comments?
>
> Agreed, there's no point having such a stale mirror in the list.

Gone!

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

Thanks.



From blb at macports.org  Fri Oct 17 16:27:28 2008
From: blb at macports.org (Bryan Blackburn)
Date: Fri, 17 Oct 2008 17:27:28 -0600
Subject: Fwd: [40828] contrib/mpab/chroot-scripts/buildports
In-Reply-To: <5cbbe4ae0810171208r2cc4b6edmaa42ae22a3531f10@mail.gmail.com>
References: <20081015195826.9E7394F2592@beta.macosforge.org>
	<5cbbe4ae0810162354v31504ccfh2c38bf75e329f17@mail.gmail.com>
	<20081017073003.GL8046@ninagal.withay.com>
	<5cbbe4ae0810170253s45ee0be6i9108266326523b25@mail.gmail.com>
	<20081017184751.GE68596@ninagal.withay.com>
	<5cbbe4ae0810171208r2cc4b6edmaa42ae22a3531f10@mail.gmail.com>
Message-ID: <20081017232728.GM68596@ninagal.withay.com>

On Fri, Oct 17, 2008 at 09:08:54PM +0200, C. Florian Ebeling said:
> On Fri, Oct 17, 2008 at 8:47 PM, Bryan Blackburn <blb at macports.org> wrote:
> > On Fri, Oct 17, 2008 at 11:53:37AM +0200, C. Florian Ebeling said:
> >> On Fri, Oct 17, 2008 at 9:30 AM, Bryan Blackburn <blb at macports.org> wrote:
> >> > On Fri, Oct 17, 2008 at 08:54:42AM +0200, C. Florian Ebeling said:
> >> >> Hi Bryan,
> >> >>
> >> > [...]
> >> >> -      portOutput=`/opt/local/bin/port -dvf uninstall $uninstallPort 2>&1`
> >> >> +      portOutput=`/opt/local/bin/port -dvf deactivate $uninstallPort 2>&1`
> >> >>        if [[ $? != 0 ]]; then
> >> >>           echo $portOutput
> >> >>           break
> > Definitely not all, that'd take forever on my MBP, I usually let it build
> > 150-200 as a test, but I let it run without a port list and kill it after a
> > while.
> 
> But mpab sorts the list of ports on dependencies before running, so they
> maybe have all zero dependencies at the start. And those should indeed
> not be effected, because they get explicitly uninstalled, other than the
> dependency ports. I think that explains it :)
> 

Right, but in fact one of the reasons I tried the deactivate in the first
place was I was already seeing quite a few being build which require the
curse of ncurses, which needs ncursesw and has over 3000 files;
uninstall/reinstall even from archive on that takes some time...

However, this is odd; looking at libpng which needs zlib, I see:

DEBUG: Skipping org.macports.main (zlib) since this port is already
installed
DEBUG: Found TGZ archive:
/opt/local/var/macports/packages/darwin/i386/zlib-1.2.3_1.i386.tgz
--->  Unpacking tgz archive for zlib 1.2.3_1
DEBUG: Executing org.macports.unarchive (zlib)
DEBUG: Using /usr/bin/tar
DEBUG: Using /usr/bin/gzip
--->  Extracting zlib-1.2.3_1.i386.tgz

So it would appear it re-extracted it from the archive...even though the
port was simply deactivated and not uninstalled.  Different from the error
you're seeing, and working, but definitely not what's expected.

Bryan


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

From raimue at macports.org  Sat Oct 18 03:45:48 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 18 Oct 2008 12:45:48 +0200
Subject: Remove ftp.uu.net from gnu fetch group
In-Reply-To: <20081017225929.GK68596@ninagal.withay.com>
References: <3296FC25-8E9C-45E1-A036-D8287749B841@macports.org>
	<20081017225929.GK68596@ninagal.withay.com>
Message-ID: <48F9BE5C.5040109@macports.org>

Bryan Blackburn wrote:
> I think there are several stale mirrors in gnu, gnupg, and a few other
> lists; unfortunately I didn't keep track of which ones at the time.  I'd say
> delete any that are obviously out of date like that one you list, and
> long-term come up with something like livecheck only for mirror sites to
> ease pruning.

There is already 'port distcheck' which tries to download from each mirror.

Rainer

From simon at ruderich.org  Sat Oct 18 06:03:14 2008
From: simon at ruderich.org (Simon Ruderich)
Date: Sat, 18 Oct 2008 15:03:14 +0200
Subject: [40890] trunk/dports/multimedia/libtheora
In-Reply-To: <3DF84BC0-1C1A-45BB-9637-5808B94AFBD1@macports.org>
References: <20081017080541.348AF4FDB09@beta.macosforge.org>
	<3DF84BC0-1C1A-45BB-9637-5808B94AFBD1@macports.org>
Message-ID: <20081018130314.GA3975@ruderich.org>

On Fri, Oct 17, 2008 at 04:59:05PM -0500, Ryan Schmidt wrote:
> http://guide.macports.org/#development.patches.source
>
> I think we decided, though the documentation doesn't reflect that
> yet, that one patch per issue is also permissible. If you need to
> patch multiple files to fix one issue, then it's fine (perhaps even
> clearer) to put them all into a single patch file.

Hi Ryan,

I committed this in r40919 [1]. Please tell me if this is okay and if not
please change it.

Thanks,
Simon

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

From ryandesign at macports.org  Sat Oct 18 12:28:43 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 18 Oct 2008 14:28:43 -0500
Subject: [40890] trunk/dports/multimedia/libtheora
In-Reply-To: <20081018130314.GA3975@ruderich.org>
References: <20081017080541.348AF4FDB09@beta.macosforge.org>
	<3DF84BC0-1C1A-45BB-9637-5808B94AFBD1@macports.org>
	<20081018130314.GA3975@ruderich.org>
Message-ID: <7256E1AE-F37A-4A9F-8BEE-4B0D49CC2348@macports.org>

On Oct 18, 2008, at 08:03, Simon Ruderich wrote:

> On Fri, Oct 17, 2008 at 04:59:05PM -0500, Ryan Schmidt wrote:
>> http://guide.macports.org/#development.patches.source
>>
>> I think we decided, though the documentation doesn't reflect that
>> yet, that one patch per issue is also permissible. If you need to
>> patch multiple files to fix one issue, then it's fine (perhaps even
>> clearer) to put them all into a single patch file.
>
> Hi Ryan,
>
> I committed this in r40919 [1]. Please tell me if this is okay and  
> if not
> please change it.
>
> Thanks,
> Simon
>
> [1]: http://trac.macports.org/changeset/40919

Thanks, that looks great!



From ryandesign at macports.org  Sat Oct 18 13:07:54 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 18 Oct 2008 15:07:54 -0500
Subject: [40947] trunk/dports
In-Reply-To: <20081018200113.4E73F512198@beta.macosforge.org>
References: <20081018200113.4E73F512198@beta.macosforge.org>
Message-ID: <AB43A94F-C082-4387-A1C6-B284DB03BD64@macports.org>


On Oct 18, 2008, at 15:01, ryandesign at macports.org wrote:

> Revision: 40947
>           http://trac.macports.org/changeset/40947
> Author:   ryandesign at macports.org
> Date:     2008-10-18 13:01:12 -0700 (Sat, 18 Oct 2008)
> Log Message:
> -----------
> Set svn:eol-style of Portfiles to native per current policy

Strange: the HTML version of the mail doesn't say tell what value I  
set svn:eol-style to, though the text version of the mail does. Can  
this information be added to the HTML version of the mail?


From blb at macports.org  Sat Oct 18 13:15:58 2008
From: blb at macports.org (Bryan Blackburn)
Date: Sat, 18 Oct 2008 14:15:58 -0600
Subject: [40913] trunk/dports/graphics/ImageMagick/Portfile
In-Reply-To: <20081018090751.BA2C350A8F5@beta.macosforge.org>
References: <20081018090751.BA2C350A8F5@beta.macosforge.org>
Message-ID: <20081018201558.GD38952@ninagal.withay.com>

On Sat, Oct 18, 2008 at 02:07:51AM -0700, ryandesign at macports.org said:
> Revision: 40913
>           http://trac.macports.org/changeset/40913
> Author:   ryandesign at macports.org
[...]
> +variant lqr description {Support Liquid Rescale (experimental)} {
> +    configure.args-delete \
> +        --without-lqr
> +    configure.args-append \
> +        --with-lqr
> +}
> +

Shouldn't this also depend on port:liblqr?

Bryan


From ryandesign at macports.org  Sat Oct 18 13:20:17 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 18 Oct 2008 15:20:17 -0500
Subject: [40913] trunk/dports/graphics/ImageMagick/Portfile
In-Reply-To: <20081018201558.GD38952@ninagal.withay.com>
References: <20081018090751.BA2C350A8F5@beta.macosforge.org>
	<20081018201558.GD38952@ninagal.withay.com>
Message-ID: <F1DD0EC8-4182-411A-9FFB-1FF5BB4DEDF0@macports.org>


On Oct 18, 2008, at 15:15, Bryan Blackburn wrote:

> On Sat, Oct 18, 2008 at 02:07:51AM -0700, ryandesign at macports.org  
> said:
>> Revision: 40913
>>           http://trac.macports.org/changeset/40913
>> Author:   ryandesign at macports.org
> [...]
>> +variant lqr description {Support Liquid Rescale (experimental)} {
>> +    configure.args-delete \
>> +        --without-lqr
>> +    configure.args-append \
>> +        --with-lqr
>> +}
>> +
>
> Shouldn't this also depend on port:liblqr?

Totally. Done! Thanks for catching that.


From ryandesign at macports.org  Sat Oct 18 19:10:02 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 18 Oct 2008 21:10:02 -0500
Subject: [40957] trunk/dports/net/transmission-x11/Portfile
In-Reply-To: <20081019014436.CDA4D5155C7@beta.macosforge.org>
References: <20081019014436.CDA4D5155C7@beta.macosforge.org>
Message-ID: <416859C1-6E15-4B3B-B747-40DD51B4CB76@macports.org>


On Oct 18, 2008, at 20:44, raimue at macports.org wrote:

>
> +variant aqua description {Build Aqua front-end} {
> +	configure.args-delete	--disable-darwin
> +	configure.args-append	--enable-darwin
> +}
> +
> +pre-fetch {
> +	if { [variant_isset aqua] } {
> +		set comparison [string  compare "${os.platform} ${os.major}"  
> "darwin 9"]
> +		if {$comparison != 0} {
> +			return -code error "The aqua front-end only builds on Mac OS X  
> Leopard (10.5.x). try the gtk variant"
> +		}
> +	}
> +}

It builds only on 10.5? or it builds on 10.5 or greater? If the  
latter, I recommend something like:

variant aqua description {Build Aqua front-end} {
	pre-fetch {
		if { ${os.major} < 9 } {
			return -code error "The aqua front-end of ${name} requires Mac OS  
X 10.5 or greater. Try the gtk variant instead."
		}
	}
	configure.args-delete	--disable-darwin
	configure.args-append	--enable-darwin
}


From randall.h.wood at alexandriasoftware.com  Sun Oct 19 03:38:46 2008
From: randall.h.wood at alexandriasoftware.com (Randall Wood)
Date: Sun, 19 Oct 2008 06:38:46 -0400
Subject: [40957] trunk/dports/net/transmission-x11/Portfile
In-Reply-To: <416859C1-6E15-4B3B-B747-40DD51B4CB76@macports.org>
References: <20081019014436.CDA4D5155C7@beta.macosforge.org>
	<416859C1-6E15-4B3B-B747-40DD51B4CB76@macports.org>
Message-ID: <5026ECA6-1B8A-44E4-BC75-E239FD4EC1CE@alexandriasoftware.com>

I would remove this variant and get the net/transmission port working  
instead.

On 18 Oct 2008, at 22:10, Ryan Schmidt wrote:

>
> On Oct 18, 2008, at 20:44, raimue at macports.org wrote:
>
>>
>> +variant aqua description {Build Aqua front-end} {
>> +	configure.args-delete	--disable-darwin
>> +	configure.args-append	--enable-darwin
>> +}
>> +
>> +pre-fetch {
>> +	if { [variant_isset aqua] } {
>> +		set comparison [string  compare "${os.platform} ${os.major}"
>> "darwin 9"]
>> +		if {$comparison != 0} {
>> +			return -code error "The aqua front-end only builds on Mac OS X
>> Leopard (10.5.x). try the gtk variant"
>> +		}
>> +	}
>> +}
>
> It builds only on 10.5? or it builds on 10.5 or greater? If the
> latter, I recommend something like:
>
> variant aqua description {Build Aqua front-end} {
> 	pre-fetch {
> 		if { ${os.major} < 9 } {
> 			return -code error "The aqua front-end of ${name} requires Mac OS
> X 10.5 or greater. Try the gtk variant instead."
> 		}
> 	}
> 	configure.args-delete	--disable-darwin
> 	configure.args-append	--enable-darwin
> }
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


From neric27 at wanadoo.fr  Sun Oct 19 05:02:59 2008
From: neric27 at wanadoo.fr (Eric)
Date: Sun, 19 Oct 2008 14:02:59 +0200
Subject: [40957] trunk/dports/net/transmission-x11/Portfile
In-Reply-To: <5026ECA6-1B8A-44E4-BC75-E239FD4EC1CE@alexandriasoftware.com>
References: <20081019014436.CDA4D5155C7@beta.macosforge.org>	<416859C1-6E15-4B3B-B747-40DD51B4CB76@macports.org>
	<5026ECA6-1B8A-44E4-BC75-E239FD4EC1CE@alexandriasoftware.com>
Message-ID: <48FB21F3.50303@wanadoo.fr>


I don't have leopard to begin with, so I don't now if it builds correctly.
The aqua version looks superior to me : growl integration, good-looking
UI, etc.
Unfortunately, it runs well on Tiger but doesn't build.

@Randall : you're right, but I wonder why there was this split in the
first place : it's the same package, after all...



Randall Wood a ?crit :
> I would remove this variant and get the net/transmission port working  
> instead.
>
> On 18 Oct 2008, at 22:10, Ryan Schmidt wrote:
>
>   
>> On Oct 18, 2008, at 20:44, raimue at macports.org wrote:
>>
>>     
>>> +variant aqua description {Build Aqua front-end} {
>>> +	configure.args-delete	--disable-darwin
>>> +	configure.args-append	--enable-darwin
>>> +}
>>> +
>>> +pre-fetch {
>>> +	if { [variant_isset aqua] } {
>>> +		set comparison [string  compare "${os.platform} ${os.major}"
>>> "darwin 9"]
>>> +		if {$comparison != 0} {
>>> +			return -code error "The aqua front-end only builds on Mac OS X
>>> Leopard (10.5.x). try the gtk variant"
>>> +		}
>>> +	}
>>> +}
>>>       
>> It builds only on 10.5? or it builds on 10.5 or greater? If the
>> latter, I recommend something like:
>>
>> variant aqua description {Build Aqua front-end} {
>> 	pre-fetch {
>> 		if { ${os.major} < 9 } {
>> 			return -code error "The aqua front-end of ${name} requires Mac OS
>> X 10.5 or greater. Try the gtk variant instead."
>> 		}
>> 	}
>> 	configure.args-delete	--disable-darwin
>> 	configure.args-append	--enable-darwin
>> }
>>
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>>     
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>
>
>   


From raimue at macports.org  Sun Oct 19 05:39:22 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sun, 19 Oct 2008 14:39:22 +0200
Subject: [40957] trunk/dports/net/transmission-x11/Portfile
In-Reply-To: <416859C1-6E15-4B3B-B747-40DD51B4CB76@macports.org>
References: <20081019014436.CDA4D5155C7@beta.macosforge.org>
	<416859C1-6E15-4B3B-B747-40DD51B4CB76@macports.org>
Message-ID: <48FB2A7A.50702@macports.org>

Ryan Schmidt wrote:
> It builds only on 10.5? or it builds on 10.5 or greater? If the  
> latter, I recommend something like:
> 
> variant aqua description {Build Aqua front-end} {
> 	pre-fetch {
> 		if { ${os.major} < 9 } {
> 			return -code error "The aqua front-end of ${name} requires Mac OS  
> X 10.5 or greater. Try the gtk variant instead."
> 		}
> 	}
> 	configure.args-delete	--disable-darwin
> 	configure.args-append	--enable-darwin
> }

Okay, moving this into the aqua variant is better. But you missed the
platform check on ${os.platform}.

Rainer


From neric27 at wanadoo.fr  Sun Oct 19 05:45:09 2008
From: neric27 at wanadoo.fr (Eric)
Date: Sun, 19 Oct 2008 14:45:09 +0200
Subject: [40957] trunk/dports/net/transmission-x11/Portfile
In-Reply-To: <48FB2A7A.50702@macports.org>
References: <20081019014436.CDA4D5155C7@beta.macosforge.org>	<416859C1-6E15-4B3B-B747-40DD51B4CB76@macports.org>
	<48FB2A7A.50702@macports.org>
Message-ID: <48FB2BD5.6050906@wanadoo.fr>

It's not what's written in the guide, is it ?
http://guide.macports.org/#development.variants.phase

Rainer M?ller a ?crit :
> Ryan Schmidt wrote:
>   
>> It builds only on 10.5? or it builds on 10.5 or greater? If the  
>> latter, I recommend something like:
>>
>> variant aqua description {Build Aqua front-end} {
>> 	pre-fetch {
>> 		if { ${os.major} < 9 } {
>> 			return -code error "The aqua front-end of ${name} requires Mac OS  
>> X 10.5 or greater. Try the gtk variant instead."
>> 		}
>> 	}
>> 	configure.args-delete	--disable-darwin
>> 	configure.args-append	--enable-darwin
>> }
>>     
>
> Okay, moving this into the aqua variant is better. But you missed the
> platform check on ${os.platform}.
>
> Rainer
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>
>
>   


From ryandesign at macports.org  Sun Oct 19 14:39:14 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 19 Oct 2008 16:39:14 -0500
Subject: [40957] trunk/dports/net/transmission-x11/Portfile
In-Reply-To: <48FB2BD5.6050906@wanadoo.fr>
References: <20081019014436.CDA4D5155C7@beta.macosforge.org>	<416859C1-6E15-4B3B-B747-40DD51B4CB76@macports.org>
	<48FB2A7A.50702@macports.org> <48FB2BD5.6050906@wanadoo.fr>
Message-ID: <3155D0EA-4D93-47FE-BF5D-85F501E6532A@macports.org>

On Oct 19, 2008, at 07:45, Eric wrote:

> Rainer M?ller a ?crit :
>
>> Ryan Schmidt wrote:
>>
>>> It builds only on 10.5? or it builds on 10.5 or greater? If the
>>> latter, I recommend something like:
>>>
>>> variant aqua description {Build Aqua front-end} {
>>> 	pre-fetch {
>>> 		if { ${os.major} < 9 } {
>>> 			return -code error "The aqua front-end of ${name} requires Mac OS
>>> X 10.5 or greater. Try the gtk variant instead."
>>> 		}
>>> 	}
>>> 	configure.args-delete	--disable-darwin
>>> 	configure.args-append	--enable-darwin
>>> }
>>
>> Okay, moving this into the aqua variant is better. But you missed the
>> platform check on ${os.platform}.
>
> It's not what's written in the guide, is it ?
> http://guide.macports.org/#development.variants.phase

Then we should fix the guide :)





From ryandesign at macports.org  Sun Oct 19 14:40:50 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 19 Oct 2008 16:40:50 -0500
Subject: [40957] trunk/dports/net/transmission-x11/Portfile
In-Reply-To: <48FB2A7A.50702@macports.org>
References: <20081019014436.CDA4D5155C7@beta.macosforge.org>
	<416859C1-6E15-4B3B-B747-40DD51B4CB76@macports.org>
	<48FB2A7A.50702@macports.org>
Message-ID: <6F94A430-113B-446B-83D1-E23D66DFE063@macports.org>


On Oct 19, 2008, at 07:39, Rainer M?ller wrote:

> Ryan Schmidt wrote:
>
>> It builds only on 10.5? or it builds on 10.5 or greater? If the
>> latter, I recommend something like:
>>
>> variant aqua description {Build Aqua front-end} {
>> 	pre-fetch {
>> 		if { ${os.major} < 9 } {
>> 			return -code error "The aqua front-end of ${name} requires Mac OS
>> X 10.5 or greater. Try the gtk variant instead."
>> 		}
>> 	}
>> 	configure.args-delete	--disable-darwin
>> 	configure.args-append	--enable-darwin
>> }
>
> Okay, moving this into the aqua variant is better. But you missed the
> platform check on ${os.platform}.

I didn't so much miss it as just left it out. :) "Aqua" implies Mac  
OS X anyway. So if anything, you'd want to throw a fatal error if the  
user attempts to use the +aqua variant and is not running Mac OS X.


From wsiegrist at apple.com  Mon Oct 20 00:45:35 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Mon, 20 Oct 2008 00:45:35 -0700
Subject: [40947] trunk/dports
In-Reply-To: <AB43A94F-C082-4387-A1C6-B284DB03BD64@macports.org>
References: <20081018200113.4E73F512198@beta.macosforge.org>
	<AB43A94F-C082-4387-A1C6-B284DB03BD64@macports.org>
Message-ID: <360AC238-3B73-4CB8-B33D-67ADD30F9447@apple.com>

On Oct 18, 2008, at 1:07 PM, Ryan Schmidt wrote:

>
> On Oct 18, 2008, at 15:01, ryandesign at macports.org wrote:
>
>> Revision: 40947
>>          http://trac.macports.org/changeset/40947
>> Author:   ryandesign at macports.org
>> Date:     2008-10-18 13:01:12 -0700 (Sat, 18 Oct 2008)
>> Log Message:
>> -----------
>> Set svn:eol-style of Portfiles to native per current policy
>
> Strange: the HTML version of the mail doesn't say tell what value I  
> set svn:eol-style to, though the text version of the mail does. Can  
> this information be added to the HTML version of the mail?
>

I believe thats just how the Perl modules are written (the diff comes  
from SVN::Notify::HTML::ColorDiff).  Go ahead and file a ticket to  
track this, but I didnt see a quick fix so it might be a while.

-Bill



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

From ryandesign at macports.org  Mon Oct 20 13:46:16 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 20 Oct 2008 15:46:16 -0500
Subject: [40991] trunk/dports/science/gromacs/Portfile
In-Reply-To: <20081020145951.BCD9651F68D@beta.macosforge.org>
References: <20081020145951.BCD9651F68D@beta.macosforge.org>
Message-ID: <C1ED399D-EDE2-4C9F-8DF6-9F137CE9F99A@macports.org>


On Oct 20, 2008, at 09:59, macsforever2000 at macports.org wrote:

> Revision: 40991
>           http://trac.macports.org/changeset/40991
> Author:   macsforever2000 at macports.org
> Date:     2008-10-20 07:59:51 -0700 (Mon, 20 Oct 2008)
> Log Message:
> -----------
> Updated to version 4.0. Added double and mpi variants.  
> mac.com:mlund is now maintainer. (#15947)
>
> Modified Paths:
> --------------
>     trunk/dports/science/gromacs/Portfile
>
> Modified: trunk/dports/science/gromacs/Portfile
> ===================================================================
> --- trunk/dports/science/gromacs/Portfile	2008-10-20 12:34:10 UTC  
> (rev 40990)
> +++ trunk/dports/science/gromacs/Portfile	2008-10-20 14:59:51 UTC  
> (rev 40991)
> @@ -2,9 +2,9 @@
>
>  PortSystem 1.0
>  name		gromacs
> -version		3.3.1
> +version		4.0
>  categories	science math
> -maintainers	nomaintainer
> +maintainers	mac.com:mlund
>  description	The World's fastest Molecular Dynamics package
>  long_description	GROMACS is a versatile package to perform  
> molecular \
>  	dynamics, i.e. simulate the Newtonian equations of motion for \
> @@ -17,12 +17,29 @@
>  platforms	darwin
>
>  homepage	http://www.gromacs.org/
> -master_sites	ftp://ftp.gromacs.org/pub/${name}
> +master_sites	ftp://ftp.gromacs.org/pub/${name} \
> +                http://cluster.earlham.edu/detail/home/charliep/ 
> packages

cluster.earlham.edu doesn't seem to have gromacs-4.0.tar.gz. Do you  
know that it will be added there soon?


> -checksums	md5 1af34a99950813ca7cf893253c447cd1
> +checksums       md5 bfc18a2ecc998f542438316b9148b7ff \
> +                sha1 5c8f0c3bfa2950bb936b4bfc5e9241028ffb8f1d \
> +                rmd160 3156220f6b98ec4c04c264c8f798c616ce668a07
>
> -depends_lib 	port:fftw-3-single
> +depends_lib 	port:fftw-3-single port:openmotif
>
> -configure.args	--exec-prefix=${prefix}/lib/${name}	\
> -		--mandir=${prefix}/share/man
> +configure.args  --bindir=${prefix}/lib/${name}/bin --with-x
>
> +variant nox description {Disable X11/Motif GUI} {
> +  depends_lib-delete       port:openmotif
> +  configure.args-delete    --with-x
> +  configure.args-append    --without-x
> +}
> +variant double description {Double precision floating-point  
> arithmetics} {
> +  depends_lib-delete       port:fftw-3-single
> +  depends_lib-append       port:fftw-3
> +  configure.args-append    --enable-double
> +}
> +platform darwin powerpc {
> +  build_lib-append         port:gcc42

Syntax error. :-) Fixed:

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

> +  configure.compiler       macports-gcc-4.2
> +}



From macsforever2000 at macports.org  Mon Oct 20 14:05:29 2008
From: macsforever2000 at macports.org (Frank Schima)
Date: Mon, 20 Oct 2008 15:05:29 -0600
Subject: [40991] trunk/dports/science/gromacs/Portfile
In-Reply-To: <C1ED399D-EDE2-4C9F-8DF6-9F137CE9F99A@macports.org>
References: <20081020145951.BCD9651F68D@beta.macosforge.org>
	<C1ED399D-EDE2-4C9F-8DF6-9F137CE9F99A@macports.org>
Message-ID: <729F23DF-02B4-4DF0-87C3-62560BC06C6B@macports.org>


On Oct 20, 2008, at 2:46 PM, Ryan Schmidt wrote:

> On Oct 20, 2008, at 09:59, macsforever2000 at macports.org wrote:
>
>> Revision: 40991
>>          http://trac.macports.org/changeset/40991
>> Author:   macsforever2000 at macports.org
>> Date:     2008-10-20 07:59:51 -0700 (Mon, 20 Oct 2008)
>> Log Message:
>> -----------
>> Updated to version 4.0. Added double and mpi variants.  
>> mac.com:mlund is now maintainer. (#15947)
>>
>> Modified Paths:
>> --------------
>>    trunk/dports/science/gromacs/Portfile
>>
>> Modified: trunk/dports/science/gromacs/Portfile
>> ===================================================================
>> --- trunk/dports/science/gromacs/Portfile	2008-10-20 12:34:10 UTC  
>> (rev 40990)
>> +++ trunk/dports/science/gromacs/Portfile	2008-10-20 14:59:51 UTC  
>> (rev 40991)
>> @@ -2,9 +2,9 @@
>>
>> PortSystem 1.0
>> name		gromacs
>> -version		3.3.1
>> +version		4.0
>> categories	science math
>> -maintainers	nomaintainer
>> +maintainers	mac.com:mlund
>> description	The World's fastest Molecular Dynamics package
>> long_description	GROMACS is a versatile package to perform  
>> molecular \
>> 	dynamics, i.e. simulate the Newtonian equations of motion for \
>> @@ -17,12 +17,29 @@
>> platforms	darwin
>>
>> homepage	http://www.gromacs.org/
>> -master_sites	ftp://ftp.gromacs.org/pub/${name}
>> +master_sites	ftp://ftp.gromacs.org/pub/${name} \
>> +                http://cluster.earlham.edu/detail/home/charliep/packages
>
> cluster.earlham.edu doesn't seem to have gromacs-4.0.tar.gz. Do you  
> know that it will be added there soon?

That's a question for the patch submitter.

>> -checksums	md5 1af34a99950813ca7cf893253c447cd1
>> +checksums       md5 bfc18a2ecc998f542438316b9148b7ff \
>> +                sha1 5c8f0c3bfa2950bb936b4bfc5e9241028ffb8f1d \
>> +                rmd160 3156220f6b98ec4c04c264c8f798c616ce668a07
>>
>> -depends_lib 	port:fftw-3-single
>> +depends_lib 	port:fftw-3-single port:openmotif
>>
>> -configure.args	--exec-prefix=${prefix}/lib/${name}	\
>> -		--mandir=${prefix}/share/man
>> +configure.args  --bindir=${prefix}/lib/${name}/bin --with-x
>>
>> +variant nox description {Disable X11/Motif GUI} {
>> +  depends_lib-delete       port:openmotif
>> +  configure.args-delete    --with-x
>> +  configure.args-append    --without-x
>> +}
>> +variant double description {Double precision floating-point  
>> arithmetics} {
>> +  depends_lib-delete       port:fftw-3-single
>> +  depends_lib-append       port:fftw-3
>> +  configure.args-append    --enable-double
>> +}
>> +platform darwin powerpc {
>> +  build_lib-append         port:gcc42
>
> Syntax error. :-) Fixed:
>
> http://trac.macports.org/changeset/41003

I did see that and forgot to fix it. Thanks!


Cheers!
Frank


From macsforever2000 at macports.org  Tue Oct 21 14:55:48 2008
From: macsforever2000 at macports.org (Frank Schima)
Date: Tue, 21 Oct 2008 15:55:48 -0600
Subject: BBEdit language module for Portfiles
Message-ID: <A8553603-9FA5-47BA-B33D-C9AAF7685830@macports.org>

Hi,


I have created a preliminary BBEdit language module for editing a  
MacPorts Portfile. I don't have a place to host it right now, so I  
created a ticket and attached the file. Instructions on how to use it  
are all there:

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

Improvements are welcome. I hope others will find it as helpful as it  
is for me. Please let me know if this is useful to others and I will  
continue to post my updates to the ticket. Enjoy!


Cheers!
Frank


From wsiegrist at apple.com  Tue Oct 21 15:01:51 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Tue, 21 Oct 2008 15:01:51 -0700
Subject: BBEdit language module for Portfiles
In-Reply-To: <A8553603-9FA5-47BA-B33D-C9AAF7685830@macports.org>
References: <A8553603-9FA5-47BA-B33D-C9AAF7685830@macports.org>
Message-ID: <D80F15AD-ED0C-4589-8D62-EEC01822366F@apple.com>

On Oct 21, 2008, at 2:55 PM, Frank Schima wrote:

> Hi,
>
>
> I have created a preliminary BBEdit language module for editing a  
> MacPorts Portfile. I don't have a place to host it right now, so I  
> created a ticket and attached the file.


Seems like the contrib "branch" would be a good place to stick it:

http://svn.macports.org/repository/macports/contrib/

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

From blb at macports.org  Tue Oct 21 16:27:45 2008
From: blb at macports.org (Bryan Blackburn)
Date: Tue, 21 Oct 2008 17:27:45 -0600
Subject: BBEdit language module for Portfiles
In-Reply-To: <D80F15AD-ED0C-4589-8D62-EEC01822366F@apple.com>
References: <A8553603-9FA5-47BA-B33D-C9AAF7685830@macports.org>
	<D80F15AD-ED0C-4589-8D62-EEC01822366F@apple.com>
Message-ID: <20081021232744.GK34057@ninagal.withay.com>

On Tue, Oct 21, 2008 at 03:01:51PM -0700, William Siegrist said:
> On Oct 21, 2008, at 2:55 PM, Frank Schima wrote:
>
>> Hi,
>>
>>
>> I have created a preliminary BBEdit language module for editing a  
>> MacPorts Portfile. I don't have a place to host it right now, so I  
>> created a ticket and attached the file.
>
>
> Seems like the contrib "branch" would be a good place to stick it:
>
> http://svn.macports.org/repository/macports/contrib/
>

Agreed, though maybe we should call it something generic like
editor-bindings (I don't like that name, but hopefully you get the idea) as
I can probably take that plist of Frank's and make something similar for
vim, and maybe TextMate.  There's probably other editors people use as well.

Bryan


> -Bill


From raimue at macports.org  Tue Oct 21 18:03:36 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Wed, 22 Oct 2008 03:03:36 +0200
Subject: BBEdit language module for Portfiles
In-Reply-To: <20081021232744.GK34057@ninagal.withay.com>
References: <A8553603-9FA5-47BA-B33D-C9AAF7685830@macports.org>	<D80F15AD-ED0C-4589-8D62-EEC01822366F@apple.com>
	<20081021232744.GK34057@ninagal.withay.com>
Message-ID: <48FE7BE8.8000105@macports.org>

Bryan Blackburn wrote:
>>> I have created a preliminary BBEdit language module for editing a  
>>> MacPorts Portfile. I don't have a place to host it right now, so I  
>>> created a ticket and attached the file.
>>
>> Seems like the contrib "branch" would be a good place to stick it:
>>
>> http://svn.macports.org/repository/macports/contrib/
>>
> 
> Agreed, though maybe we should call it something generic like
> editor-bindings (I don't like that name, but hopefully you get the idea) as
> I can probably take that plist of Frank's and make something similar for
> vim, and maybe TextMate.  There's probably other editors people use as well.

I wouldn't add them to the repository. I assume most of them need some
instructions how to install/use them, as was given in the description of
the ticket Frank created. So I think it would be better to add them to
the wiki where you can place the description right next to the download
link. Additionally, the wiki can be found by external search engines or
by the search on Trac.

I suggest to either add them directly on CommittersTipsAndTricks [1] or
create a dedicated wiki page for editor support and link it from there.

Personally I use filetype=tcl for Portfile editing in vim. Works mostly
fine, except that it highlights some keywords at the wrong place (e.g.
it highlights "append" in "build.args-append"). But as you can use Tcl
code in Portfiles, hopefully everything possible should be covered.

If you are using vim, put the following line in your ~/.vim/filetype.vim:
  au BufRead,BufNewFile Portfile set filetype=tcl

Rainer

[1] <http://trac.macports.org/wiki/CommittersTipsAndTricks>

From afb at macports.org  Tue Oct 21 23:28:13 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Wed, 22 Oct 2008 08:28:13 +0200
Subject: BBEdit language module for Portfiles
In-Reply-To: <A8553603-9FA5-47BA-B33D-C9AAF7685830@macports.org>
References: <A8553603-9FA5-47BA-B33D-C9AAF7685830@macports.org>
Message-ID: <E994ADC0-1E71-46F9-A53D-C072E6382F89@macports.org>

Frank Schima wrote:

> I have created a preliminary BBEdit language module for editing a  
> MacPorts Portfile. I don't have a place to host it right now, so I  
> created a ticket and attached the file. Instructions on how to use  
> it are all there:
>
> <http://trac.macports.org/ticket/16948>
>
> Improvements are welcome. I hope others will find it as helpful as  
> it is for me. Please let me know if this is useful to others and I  
> will continue to post my updates to the ticket. Enjoy!

I like it, it works well with TextWrangler and
the "EDITOR=edit port edit" command as well...

http://www.barebones.com/products/textwrangler/

To work with Portfiles directly, they would need
some kind of extension added (like e.g. *.port)
But that's another discussion completely, like
the *.diff extension that was forced on patches.

--anders


From ryandesign at macports.org  Wed Oct 22 01:43:00 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 22 Oct 2008 03:43:00 -0500
Subject: BBEdit language module for Portfiles
In-Reply-To: <E994ADC0-1E71-46F9-A53D-C072E6382F89@macports.org>
References: <A8553603-9FA5-47BA-B33D-C9AAF7685830@macports.org>
	<E994ADC0-1E71-46F9-A53D-C072E6382F89@macports.org>
Message-ID: <78C016D2-477F-4E06-963C-9988FF5620DA@macports.org>

On Oct 22, 2008, at 01:28, Anders F Bj?rklund wrote:

> Frank Schima wrote:
>
>> I have created a preliminary BBEdit language module for editing a  
>> MacPorts Portfile. I don't have a place to host it right now, so I  
>> created a ticket and attached the file. Instructions on how to use  
>> it are all there:
>>
>> <http://trac.macports.org/ticket/16948>
>>
>> Improvements are welcome. I hope others will find it as helpful as  
>> it is for me. Please let me know if this is useful to others and I  
>> will continue to post my updates to the ticket. Enjoy!
>
> I like it, it works well with TextWrangler and
> the "EDITOR=edit port edit" command as well...
>
> http://www.barebones.com/products/textwrangler/
>
> To work with Portfiles directly, they would need
> some kind of extension added (like e.g. *.port)
> But that's another discussion completely, like
> the *.diff extension that was forced on patches.

Yeah, I'm gonna undo that and the whitespace pedantry in lint.

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

We can bring it back as an option later, with a command-line switch.


From macsforever2000 at macports.org  Wed Oct 22 10:06:06 2008
From: macsforever2000 at macports.org (Frank Schima)
Date: Wed, 22 Oct 2008 11:06:06 -0600
Subject: BBEdit language module for Portfiles
In-Reply-To: <48FE7BE8.8000105@macports.org>
References: <A8553603-9FA5-47BA-B33D-C9AAF7685830@macports.org>	<D80F15AD-ED0C-4589-8D62-EEC01822366F@apple.com>
	<20081021232744.GK34057@ninagal.withay.com>
	<48FE7BE8.8000105@macports.org>
Message-ID: <436E1D00-29A6-4811-A6D3-20A6FFEEE811@macports.org>


On Oct 21, 2008, at 7:03 PM, Rainer M?ller wrote:
> I wouldn't add them to the repository. I assume most of them need some
> instructions how to install/use them, as was given in the  
> description of
> the ticket Frank created. So I think it would be better to add them to
> the wiki where you can place the description right next to the  
> download
> link. Additionally, the wiki can be found by external search engines  
> or
> by the search on Trac.
>
> I suggest to either add them directly on CommittersTipsAndTricks [1]  
> or
> create a dedicated wiki page for editor support and link it from  
> there.

OK, I have created a new wiki page [2] for the BBEdit language module.  
I also added a link to it from the CommittersTipsAndTricks [1] page.

[1] <http://trac.macports.org/wiki/CommittersTipsAndTricks>
[2] <http://trac.macports.org/wiki/BbeditLanguageModule>


Cheers!
Frank

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20081022/91e3ba73/attachment.html>

From blb at macports.org  Wed Oct 22 12:52:22 2008
From: blb at macports.org (Bryan Blackburn)
Date: Wed, 22 Oct 2008 13:52:22 -0600
Subject: [41080] trunk/dports/graphics/gimp2/Portfile
In-Reply-To: <20081022180427.56EFA56B6D4@beta.macosforge.org>
References: <20081022180427.56EFA56B6D4@beta.macosforge.org>
Message-ID: <20081022195222.GD97084@ninagal.withay.com>

On Wed, Oct 22, 2008 at 11:04:27AM -0700, devans at macports.org said:
> Revision: 41080
>           http://trac.macports.org/changeset/41080
> Author:   devans at macports.org
[...]
> +master_sites    ftp://ftp.gimp.org/pub/gimp/v${branch}/ \
>                  ftp://ftp.mirrorservice.org/sites/ftp.gimp.org/pub/gimp/v${branch}/ \
> -                ftp://ftp.gimp.org/pub/gimp/v${branch}/
> +                http://www.mirrorservice.org/sites/ftp.gimp.org/pub/gimp/v${branch}/ \
> +                http://gimp.mirrors.hoobly.com/gimp/v${branch}/ \
> +                http://gimp.site2nd.org/v${branch}/ \
> +                http://mirror.umoss.org/gimp/gimp/v${branch}/ \
[...]

I'd say it's time for a gimp mirror_site to be added to mirror_sites.tcl,
especially since devens has helpfully already enumerated them.

Bryan


From devans at macports.org  Wed Oct 22 13:32:52 2008
From: devans at macports.org (David Evans)
Date: Wed, 22 Oct 2008 13:32:52 -0700
Subject: [41080] trunk/dports/graphics/gimp2/Portfile
In-Reply-To: <20081022195222.GD97084@ninagal.withay.com>
References: <20081022180427.56EFA56B6D4@beta.macosforge.org>
	<20081022195222.GD97084@ninagal.withay.com>
Message-ID: <48FF8DF4.9020806@macports.org>

Bryan Blackburn wrote:
> On Wed, Oct 22, 2008 at 11:04:27AM -0700, devans at macports.org said:
>   
>> Revision: 41080
>>           http://trac.macports.org/changeset/41080
>> Author:   devans at macports.org
>>     
> [...]
>   
>> +master_sites    ftp://ftp.gimp.org/pub/gimp/v${branch}/ \
>>                  ftp://ftp.mirrorservice.org/sites/ftp.gimp.org/pub/gimp/v${branch}/ \
>> -                ftp://ftp.gimp.org/pub/gimp/v${branch}/
>> +                http://www.mirrorservice.org/sites/ftp.gimp.org/pub/gimp/v${branch}/ \
>> +                http://gimp.mirrors.hoobly.com/gimp/v${branch}/ \
>> +                http://gimp.site2nd.org/v${branch}/ \
>> +                http://mirror.umoss.org/gimp/gimp/v${branch}/ \
>>     
> [...]
>
> I'd say it's time for a gimp mirror_site to be added to mirror_sites.tcl,
> especially since devens has helpfully already enumerated them.
>
> Bryan
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>
>   
That's devans, please. :-)

Actually, I was thinking of asking about that when I got the list right
but as it turns out there
are two lists.  A larger list which just mirror the gimp2, gimp-gap,
stuff and a subset of that
that also mirrors the two dependencies gegl and babl.

So if one were to do as you say, then the smaller list would serve a
larger list of ports and reflects
the full contents of the current gimp.org site.

Dave

From blb at macports.org  Wed Oct 22 14:54:01 2008
From: blb at macports.org (Bryan Blackburn)
Date: Wed, 22 Oct 2008 15:54:01 -0600
Subject: [41080] trunk/dports/graphics/gimp2/Portfile
In-Reply-To: <48FF8DF4.9020806@macports.org>
References: <20081022180427.56EFA56B6D4@beta.macosforge.org>
	<20081022195222.GD97084@ninagal.withay.com>
	<48FF8DF4.9020806@macports.org>
Message-ID: <20081022215401.GG97084@ninagal.withay.com>

On Wed, Oct 22, 2008 at 01:32:52PM -0700, David Evans said:
> Bryan Blackburn wrote:
[...]
> >
> > I'd say it's time for a gimp mirror_site to be added to mirror_sites.tcl,
> > especially since devens has helpfully already enumerated them.
> >
> > Bryan
> >
> >   
> That's devans, please. :-)
> 

Oops, sorry, at least it wasn't an odd typo...

> Actually, I was thinking of asking about that when I got the list right
> but as it turns out there
> are two lists.  A larger list which just mirror the gimp2, gimp-gap,
> stuff and a subset of that
> that also mirrors the two dependencies gegl and babl.
> 
> So if one were to do as you say, then the smaller list would serve a
> larger list of ports and reflects
> the full contents of the current gimp.org site.
> 

At least initially the smaller one would probably be better, especially if
it's still quite a few machines.  Otherwise we'd probably have to use a
gimp and a gimp-app set or something to that effect.

Also note that, unfortunately, you won't be able to use an updated list
until a new version of MacPorts is pushed out, but hopefully tickets #14482
and #14553 will take care of that in the future.

Bryan


> Dave


From devans at macports.org  Wed Oct 22 15:20:32 2008
From: devans at macports.org (David Evans)
Date: Wed, 22 Oct 2008 15:20:32 -0700
Subject: [41080] trunk/dports/graphics/gimp2/Portfile
In-Reply-To: <20081022215401.GG97084@ninagal.withay.com>
References: <20081022180427.56EFA56B6D4@beta.macosforge.org>	<20081022195222.GD97084@ninagal.withay.com>	<48FF8DF4.9020806@macports.org>
	<20081022215401.GG97084@ninagal.withay.com>
Message-ID: <48FFA730.4040805@macports.org>

Bryan Blackburn wrote:
> At least initially the smaller one would probably be better, especially if
> it's still quite a few machines.  Otherwise we'd probably have to use a
> gimp and a gimp-app set or something to that effect.
>
> Also note that, unfortunately, you won't be able to use an updated list
> until a new version of MacPorts is pushed out, but hopefully tickets #14482
> and #14553 will take care of that in the future.
>
> Bryan
>
>   
Good point.  So now's a good time to add the short list to the mirrors
list before the next push but
wait until then to use it in the Portfiles.  Will take a look at it. 
Hopefully, the short list
will grow over time to match the long list as more sites adapt to
mirroring the newer gimp.org structure.

Dave

From devans at macports.org  Wed Oct 22 16:05:47 2008
From: devans at macports.org (David Evans)
Date: Wed, 22 Oct 2008 16:05:47 -0700
Subject: [41080] trunk/dports/graphics/gimp2/Portfile
In-Reply-To: <48FFA730.4040805@macports.org>
References: <20081022180427.56EFA56B6D4@beta.macosforge.org>	<20081022195222.GD97084@ninagal.withay.com>	<48FF8DF4.9020806@macports.org>	<20081022215401.GG97084@ninagal.withay.com>
	<48FFA730.4040805@macports.org>
Message-ID: <48FFB1CB.9040406@macports.org>

David Evans wrote:
> Good point.  So now's a good time to add the short list to the mirrors
> list before the next push but
> wait until then to use it in the Portfiles.  Will take a look at it. 
> Hopefully, the short list
> will grow over time to match the long list as more sites adapt to
> mirroring the newer gimp.org structure.
>
> Dave
>   
GIMP (short) mirror_list added to mirror_lists.tcl in r41097.



From andrea.damore at macports.org  Thu Oct 23 05:10:25 2008
From: andrea.damore at macports.org (Andrea D'Amore)
Date: Thu, 23 Oct 2008 14:10:25 +0200
Subject: BBEdit language module for Portfiles
In-Reply-To: <A8553603-9FA5-47BA-B33D-C9AAF7685830@macports.org>
References: <A8553603-9FA5-47BA-B33D-C9AAF7685830@macports.org>
Message-ID: <A564CDBB-B572-4188-B6CF-11ADBA89C4C8@macports.org>


On 21/ott/08, at 23:55, Frank Schima wrote:

> Improvements are welcome. I hope others will find it as helpful as  
> it is for me. Please let me know if this is useful to others and I  
> will continue to post my updates to the ticket.

I noticed a weird behaviour with portfile that contains a double  
quoted string with escaped quotes.
For example luarocks Portfile has \"rocks\" in long_description, the  
first \" is interpreted as a string opening but the second is  
considered an escaped quote inside a regular string thus making the  
whole following content of the file commented.

I'm not even sure if long_description need to have escaped string at  
all.
The language-module-side solution is removing the "Escape Char in  
Strings 2" key, I'm not sure if this could be an issue.

Anyone using Smultron? I'm trying to convert the language module to  
syntax definition for it.


Andrea


P.S.
Obviously I sent the email to Frank rather than the ml

From macsforever2000 at macports.org  Thu Oct 23 08:27:43 2008
From: macsforever2000 at macports.org (Frank Schima)
Date: Thu, 23 Oct 2008 09:27:43 -0600
Subject: BBEdit language module for Portfiles
In-Reply-To: <A564CDBB-B572-4188-B6CF-11ADBA89C4C8@macports.org>
References: <A8553603-9FA5-47BA-B33D-C9AAF7685830@macports.org>
	<A564CDBB-B572-4188-B6CF-11ADBA89C4C8@macports.org>
Message-ID: <D0C9BC9D-BEF7-4D08-B040-78C5A82E88FA@macports.org>

On Oct 23, 2008, at 6:10 AM, Andrea D'Amore wrote:

> On 21/ott/08, at 23:55, Frank Schima wrote:
>
>> Improvements are welcome. I hope others will find it as helpful as  
>> it is for me. Please let me know if this is useful to others and I  
>> will continue to post my updates to the ticket.
>
> I noticed a weird behaviour with portfile that contains a double  
> quoted string with escaped quotes.
> For example luarocks Portfile has \"rocks\" in long_description, the  
> first \" is interpreted as a string opening but the second is  
> considered an escaped quote inside a regular string thus making the  
> whole following content of the file commented.
>
> I'm not even sure if long_description need to have escaped string at  
> all.
> The language-module-side solution is removing the "Escape Char in  
> Strings 2" key, I'm not sure if this could be an issue.

The gimp port has the problem too. The problem with that fix is that  
it is legitimate to escape a double quote in strings. So that will  
"break" syntax coloring in other ports. Really the issue is that the  
long_description is itself a string but is not quoted as such. I  
tested changing the bacula port (a port I manage) and added double  
quotes around the long_description [1] and it seems to cause no  
problems and will fix the improper syntax coloring issue you noticed.

So I think the proper fix is to change the affected ports by adding  
double quotes around the long_description. Does anyone see any  
problems with doing that?


[1] <http://trac.macports.org/changeset/41108>


Cheers!
Frank

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20081023/2457b0d5/attachment.html>

From devans at macports.org  Thu Oct 23 09:01:47 2008
From: devans at macports.org (David Evans)
Date: Thu, 23 Oct 2008 09:01:47 -0700
Subject: BBEdit language module for Portfiles
In-Reply-To: <D0C9BC9D-BEF7-4D08-B040-78C5A82E88FA@macports.org>
References: <A8553603-9FA5-47BA-B33D-C9AAF7685830@macports.org>	<A564CDBB-B572-4188-B6CF-11ADBA89C4C8@macports.org>
	<D0C9BC9D-BEF7-4D08-B040-78C5A82E88FA@macports.org>
Message-ID: <49009FEB.2070609@macports.org>

Frank Schima wrote:
> On Oct 23, 2008, at 6:10 AM, Andrea D'Amore wrote:
>
>> On 21/ott/08, at 23:55, Frank Schima wrote:
>>
>>> Improvements are welcome. I hope others will find it as helpful as
>>> it is for me. Please let me know if this is useful to others and I
>>> will continue to post my updates to the ticket.
>>
>> I noticed a weird behaviour with portfile that contains a double
>> quoted string with escaped quotes.
>> For example luarocks Portfile has \"rocks\" in long_description, the
>> first \" is interpreted as a string opening but the second is
>> considered an escaped quote inside a regular string thus making the
>> whole following content of the file commented.
>>
>> I'm not even sure if long_description need to have escaped string at all.
>> The language-module-side solution is removing the "Escape Char in
>> Strings 2" key, I'm not sure if this could be an issue.
>
> The gimp port has the problem too. The problem with that fix is that
> it is legitimate to escape a double quote in strings. So that will
> "break" syntax coloring in other ports. Really the issue is that the
> long_description is itself a string but is not quoted as such. I
> tested changing the bacula port (a port I manage) and added double
> quotes around the long_description [1] and it seems to cause no
> problems and will fix the improper syntax coloring issue you noticed.
>
> So I think the proper fix is to change the affected ports by adding
> double quotes around the long_description. Does anyone see any
> problems with doing that?
>
>
> [1] <http://trac.macports.org/changeset/41108>
>
Done gimp in r41109.

From andrea.damore at macports.org  Thu Oct 23 11:30:26 2008
From: andrea.damore at macports.org (Andrea D'Amore)
Date: Thu, 23 Oct 2008 20:30:26 +0200
Subject: BBEdit language module for Portfiles
In-Reply-To: <D0C9BC9D-BEF7-4D08-B040-78C5A82E88FA@macports.org>
References: <A8553603-9FA5-47BA-B33D-C9AAF7685830@macports.org>
	<A564CDBB-B572-4188-B6CF-11ADBA89C4C8@macports.org>
	<D0C9BC9D-BEF7-4D08-B040-78C5A82E88FA@macports.org>
Message-ID: <909A9DBA-E9F2-4567-BBD5-08FE82652F2A@macports.org>


On 23/ott/08, at 17:27, Frank Schima wrote:

> So I think the proper fix is to change the affected ports by adding  
> double quotes around the long_description. Does anyone see any  
> problems with doing that?

It's up to the author then, unless we want to change guidelines for  
writing portfiles.
After all this is just a syntax coloring issue with BBEdit and  
TextWrangler not an intrinsic problem.

So I'd say: let people who uses that editor decide after, I myself  
mainly use vi when editing.


Andrea

From andrea.damore at macports.org  Thu Oct 23 23:43:20 2008
From: andrea.damore at macports.org (Andrea D'Amore)
Date: Fri, 24 Oct 2008 08:43:20 +0200
Subject: BBEdit language module for Portfiles
In-Reply-To: <909A9DBA-E9F2-4567-BBD5-08FE82652F2A@macports.org>
References: <A8553603-9FA5-47BA-B33D-C9AAF7685830@macports.org>
	<A564CDBB-B572-4188-B6CF-11ADBA89C4C8@macports.org>
	<D0C9BC9D-BEF7-4D08-B040-78C5A82E88FA@macports.org>
	<909A9DBA-E9F2-4567-BBD5-08FE82652F2A@macports.org>
Message-ID: <EBC4ACBF-E73A-43E0-9500-5351ADA144DA@macports.org>


On 23/ott/08, at 20:30, Andrea D'Amore wrote:

> decide after,

That was supposed to be: "decide, after all"

From ryandesign at macports.org  Fri Oct 24 01:04:32 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 24 Oct 2008 03:04:32 -0500
Subject: Uninstalling MacPorts
Message-ID: <6BF82EAC-5486-405D-9FC2-3C07DE604C1E@macports.org>

We have uninstall instructions here:

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

They say:

> MacPorts can be removed by issuing the following command from  
> within Terminal using the regular bash shell (${prefix} being the  
> directory onto which you installed MacPorts, /opt/local by default):
>
> sudo rm -rf ${prefix} \
> /Applications/MacPorts \
> /Applications/DarwinPorts \
> /Library/Tcl/macports1.0 \
> /Library/Tcl/darwinports1.0 \
> /Library/LaunchDaemons/org.macports.* \
> /Library/StartupItems/DarwinPortsStartup \
> /Library/Receipts/MacPorts*.pkg \
> /Library/Receipts/DarwinPorts*.pkg \
> /etc/manpaths.d/macports \
> /etc/paths.d/macports


Problems:

1. This doesn't uninstall ports that install into weird locations,  
like those that install into ${x11prefix}. This is mentioned later in  
the FAQ entry.
2. It doesn't take into account that users can install the  
macports1.0 Tcl package into a different location.
3. It doesn't take into account that users can as of MacPorts 1.7.0  
select a different applications directory.
4. It doesn't uninstall frameworks installed by MacPorts. Those have  
until now gone into /Library/Frameworks which can also contain non- 
MacPorts items. In 1.7.0, the frameworks directory is also user- 
configurable.
5. It does uninstall user configuration files.

To take care of 1, 3, 4, and 5, maybe we should tell people to run  
"sudo port -f uninstall installed" first. Then look through ${prefix}  
for any remaining non-port-owned files they may still want to keep.

Maybe MacPorts should come with an uninstall script? How might we  
want that to work? It could uninstall all ports as above, then move  
the remaining parts of itself into a "Previous MacPorts" folder (like  
a Mac OS X Archive & Install puts the parts of the old OS into a  
"Previous Systems" folder).



From afb at macports.org  Fri Oct 24 02:23:49 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Fri, 24 Oct 2008 11:23:49 +0200
Subject: Uninstalling MacPorts
In-Reply-To: <6BF82EAC-5486-405D-9FC2-3C07DE604C1E@macports.org>
References: <6BF82EAC-5486-405D-9FC2-3C07DE604C1E@macports.org>
Message-ID: <A9D71229-2723-4686-B890-52BBB2C2A33F@macports.org>

Ryan Schmidt wrote:

> Maybe MacPorts should come with an uninstall script? How might we  
> want that to work? It could uninstall all ports as above, then move  
> the remaining parts of itself into a "Previous MacPorts" folder  
> (like a Mac OS X Archive & Install puts the parts of the old OS  
> into a "Previous Systems" folder).

Indeed it should, add it to the todo for the 1.7 disk image ;-)

https://trac.macports.org/ticket/12799

--anders


From ram at macports.org  Sat Oct 25 10:00:55 2008
From: ram at macports.org (Adam Mercer)
Date: Sat, 25 Oct 2008 12:00:55 -0500
Subject: fetch.ignore_sslcert yes still checking ssl cert
Message-ID: <799406d60810251000i2b56c058m8b647ff0ec5240a0@mail.gmail.com>

Hi

The upstream sources of a few packages I maintain have recently
switched to be served over https. Fetching from this https server is
failing with the following:

Warning: couldn't fetch
https://www.lsc-group.phys.uwm.edu/daswg/projects/metaio/release-7-2/metaio-7.2.tar.gz
for metaio (peer certificate cannot be authenticated with known CA
certificates)

After consulting the guide I added:

fetch.ignore_sslcert yes

to the Portfile, yet the fetch still fails with the above. Isn't the
fetch.ignore_sslcert statement supposed to supress this?

Cheers

Adam

From wsiegrist at apple.com  Sat Oct 25 17:43:26 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Sat, 25 Oct 2008 17:43:26 -0700
Subject: [MacPorts] #16028: Add search form for just summaries and
	portnames
In-Reply-To: <064.ce48fbb619217cfaeb06ef52c4252787@macports.org>
References: <055.926adeb418c6b771d55f18b3912f4f0b@macports.org>
	<064.ce48fbb619217cfaeb06ef52c4252787@macports.org>
Message-ID: <CA1D6182-8310-4A3E-A86F-8B6837C502A5@apple.com>

Could I get some feedback on the following changes? Do we want a link  
in ports.php that is a quick jump for "tickets about this port"?  
Neither of the two new links are perfect, but are what Trac allows  
easily. I can implement Ryan's form as an entire custom page if it  
needs to be exact.

Thanks
-Bill


On Oct 25, 2008, at 5:37 PM, MacPorts wrote:

> #16028: Add search form for just summaries and portnames
> ---------------------------------- 
> +-----------------------------------------
>  Reporter:  wsiegrist at apple.com  |       Owner:  wsiegrist at apple.com
>      Type:  enhancement          |      Status:  assigned
>  Priority:  Normal               |   Milestone:
> Component:  server/hosting       |     Version:
> Resolution:                       |    Keywords:  trac 0.11 plugin
>      Port:                       |
> ---------------------------------- 
> +-----------------------------------------
>
> Comment(by wsiegrist at apple.com):
>
> I've added a plugin that provides the new "Ticket Port & Summary"  
> search.
> It returns all tickets, regardless of state, much like the existing  
> Ticket
> search. Unlike the existing Ticket search, it does _not_ search  
> comments
> and description, but it _does_ search the port field.
>
> I added two new links in the left nav for "Ticket Search" and "Ticket
> Query". The first of which is a shortcut to the search module with  
> just
> this new filter.  The 2nd is a pre-made custom query that has a  
> Summary
> and Port field already.
>
> -- 
> Ticket URL: <http://trac.macports.org/ticket/16028#comment:4>
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS





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

From raimue at macports.org  Sun Oct 26 05:26:49 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sun, 26 Oct 2008 13:26:49 +0100
Subject: [MacPorts] #16028: Add search form for just summaries
	and	portnames
In-Reply-To: <CA1D6182-8310-4A3E-A86F-8B6837C502A5@apple.com>
References: <055.926adeb418c6b771d55f18b3912f4f0b@macports.org>	<064.ce48fbb619217cfaeb06ef52c4252787@macports.org>
	<CA1D6182-8310-4A3E-A86F-8B6837C502A5@apple.com>
Message-ID: <49046209.9050105@macports.org>

William Siegrist wrote:
> Could I get some feedback on the following changes? Do we want a link  
> in ports.php that is a quick jump for "tickets about this port"?  
> Neither of the two new links are perfect, but are what Trac allows  
> easily. I can implement Ryan's form as an entire custom page if it  
> needs to be exact.

I think your current changes are sufficient, it's now easy enough to
filter tickets for a specific port.

Thanks for adding this!

Rainer

From blb at macports.org  Sun Oct 26 18:10:38 2008
From: blb at macports.org (Bryan Blackburn)
Date: Sun, 26 Oct 2008 19:10:38 -0600
Subject: ChangeLog and 1.7.0
Message-ID: <20081027011038.GE48767@ninagal.withay.com>

Is there anything else needed for the ChangeLog?  I've updated it for all
the closed 1.7.0 milestone tickets (there are three open still), so it
should be good ticket-wise.

Bryan


From jmr at macports.org  Sun Oct 26 20:21:53 2008
From: jmr at macports.org (Joshua Root)
Date: Mon, 27 Oct 2008 14:21:53 +1100
Subject: Trivial +server variants considered harmful
Message-ID: <490533D1.4060206@macports.org>

There seem to be some ports (e.g. ntop, mysql5) with a +server variant
that does nothing but create a startupitem. It seems to me that it would
be much better to remove the variant and just always create the
startupitem, since the cost of creating a startupitem is negligible,
while the cost of having to recompile the port if you forget to specify
+server is considerable.

- Josh

From jkh at apple.com  Sun Oct 26 20:29:58 2008
From: jkh at apple.com (Jordan K. Hubbard)
Date: Sun, 26 Oct 2008 20:29:58 -0700
Subject: Trivial +server variants considered harmful
In-Reply-To: <490533D1.4060206@macports.org>
References: <490533D1.4060206@macports.org>
Message-ID: <99F54F20-80F2-4C36-845A-6365A82BDA48@apple.com>

I would have to concur.   More broadly speaking, I would say that  
variants should continue to serve as very coarse-grained knobs, not  
fine-grained ones, and mysql5 acting like a server would be more of an  
expectation than a knob in any case so these are wrong on two  
counts. :-)

- Jordan

On Oct 26, 2008, at 8:21 PM, Joshua Root wrote:

> There seem to be some ports (e.g. ntop, mysql5) with a +server variant
> that does nothing but create a startupitem. It seems to me that it  
> would
> be much better to remove the variant and just always create the
> startupitem, since the cost of creating a startupitem is negligible,
> while the cost of having to recompile the port if you forget to  
> specify
> +server is considerable.
>
> - Josh
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


From wsiegrist at apple.com  Sun Oct 26 20:49:39 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Sun, 26 Oct 2008 20:49:39 -0700
Subject: Trivial +server variants considered harmful
In-Reply-To: <490533D1.4060206@macports.org>
References: <490533D1.4060206@macports.org>
Message-ID: <028F6EEE-AC6A-4BD6-9655-EEF996EA303E@apple.com>

On Oct 26, 2008, at 8:21 PM, Joshua Root wrote:

> There seem to be some ports (e.g. ntop, mysql5) with a +server variant
> that does nothing but create a startupitem. It seems to me that it  
> would
> be much better to remove the variant and just always create the
> startupitem, since the cost of creating a startupitem is negligible,
> while the cost of having to recompile the port if you forget to  
> specify
> +server is considerable.
>

Agreed. And if the server functionality is expensive to build, I  
prefer the postgresql model of having *-server ports that can be built  
separately when possible.


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

From ryandesign at macports.org  Sun Oct 26 23:11:19 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 27 Oct 2008 01:11:19 -0500
Subject: Trivial +server variants considered harmful
In-Reply-To: <028F6EEE-AC6A-4BD6-9655-EEF996EA303E@apple.com>
References: <490533D1.4060206@macports.org>
	<028F6EEE-AC6A-4BD6-9655-EEF996EA303E@apple.com>
Message-ID: <9BA15A36-DE21-4017-BB22-E28A7B606D6B@macports.org>

On Oct 26, 2008, at 22:49, William Siegrist wrote:

> On Oct 26, 2008, at 8:21 PM, Joshua Root wrote:
>
>> There seem to be some ports (e.g. ntop, mysql5) with a +server  
>> variant
>> that does nothing but create a startupitem. It seems to me that it  
>> would
>> be much better to remove the variant and just always create the
>> startupitem, since the cost of creating a startupitem is negligible,
>> while the cost of having to recompile the port if you forget to  
>> specify
>> +server is considerable.
>
> Agreed. And if the server functionality is expensive to build, I  
> prefer the postgresql model of having *-server ports that can be  
> built separately when possible.

It's possible to disable building the server parts by adding -- 
without-server. The mysql5-devel port does this; it was requested in  
this ticket:

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

However, that's incompatible with the desire to have a separate  
mysql5-server port as requested in this ticket:

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

The server variant was added to mysql5 in this revision:

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

I can't say I know why it was added as a variant and not by default.  
I'm not opposed to changing it.

There are those who complain when ports cannot be installed by non- 
root and then we end up adding +no_startupitem variants, like the  
apache2 port has. Comments on this?


From raimue at macports.org  Sun Oct 26 23:34:32 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Mon, 27 Oct 2008 07:34:32 +0100
Subject: ChangeLog and 1.7.0
In-Reply-To: <20081027011038.GE48767@ninagal.withay.com>
References: <20081027011038.GE48767@ninagal.withay.com>
Message-ID: <490560F8.2070900@macports.org>

Bryan Blackburn wrote:
> Is there anything else needed for the ChangeLog?  I've updated it for all
> the closed 1.7.0 milestone tickets (there are three open still), so it
> should be good ticket-wise.

What about 'port distfiles' which was added to ease mirroring, but is
not used now. Do we want to keep it?

Rainer

From opendarwin.org at darkart.com  Mon Oct 27 12:29:48 2008
From: opendarwin.org at darkart.com (Eric Hall)
Date: Mon, 27 Oct 2008 19:29:48 +0000
Subject: Trivial +server variants considered harmful
In-Reply-To: <9BA15A36-DE21-4017-BB22-E28A7B606D6B@macports.org>
References: <490533D1.4060206@macports.org>
	<028F6EEE-AC6A-4BD6-9655-EEF996EA303E@apple.com>
	<9BA15A36-DE21-4017-BB22-E28A7B606D6B@macports.org>
Message-ID: <20081027192948.GO13985@darkart.com>

On Mon, Oct 27, 2008 at 01:11:19AM -0500, Ryan Schmidt wrote:
[snip]
> 
> There are those who complain when ports cannot be installed by non- 
> root and then we end up adding +no_startupitem variants, like the  
> apache2 port has. Comments on this?
> 

	I think splitting a port into 'plain' (aka client bits only)
and a -server port is the right answer to the problem.  



		-eric



From gaspard at teti.ch  Mon Oct 27 13:49:27 2008
From: gaspard at teti.ch (Gaspard Bucher)
Date: Mon, 27 Oct 2008 21:49:27 +0100
Subject: Fixed Portfile for Ragel [maintainers: mww]
Message-ID: <90540BD5-B36E-4505-8EF2-1DFFC032AADF@teti.ch>

It seems Ragel has changed its website. This new Portfile reflects  
this change and works (sources could not be found in old website).

Gaspard

ports/lang/ragel/Portfile

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Portfile
Type: application/octet-stream
Size: 1119 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20081027/1e52d8db/attachment.obj>
-------------- next part --------------


From ryandesign at macports.org  Mon Oct 27 15:07:22 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 27 Oct 2008 17:07:22 -0500
Subject: Fixed Portfile for Ragel [maintainers: mww]
In-Reply-To: <90540BD5-B36E-4505-8EF2-1DFFC032AADF@teti.ch>
References: <90540BD5-B36E-4505-8EF2-1DFFC032AADF@teti.ch>
Message-ID: <0FBD3EAA-F509-44B6-B6B3-FD941B021F8A@macports.org>


On Oct 27, 2008, at 15:49, Gaspard Bucher wrote:

> It seems Ragel has changed its website. This new Portfile reflects  
> this change and works (sources could not be found in old website).
>
> Gaspard
>
> ports/lang/ragel/Portfile

Thanks. Toby committed the change:

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





From ryandesign at macports.org  Tue Oct 28 12:52:42 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 28 Oct 2008 14:52:42 -0500
Subject: [41224] trunk/dports/ruby/rb-cocoa
In-Reply-To: <20081028134525.B7A6D5C94D8@beta.macosforge.org>
References: <20081028134525.B7A6D5C94D8@beta.macosforge.org>
Message-ID: <4680127E-73FB-4AE0-A4D3-256DF4EF9D65@macports.org>

On Oct 28, 2008, at 08:45, kimuraw at macports.org wrote:

> +post-extract {
> +  cd ${worksrcpath}
> +  system "find . -type d -name '.svn' | xargs /bin/rm -rf"
> +}

Could you change this to not use the cd command, please? The cd  
command will not be available in MacPorts 1.7.0 and later. Try:

system "find ${worksrcpath} -type d -name '.svn' | xargs /bin/rm -rf"



From ryandesign at macports.org  Tue Oct 28 15:58:52 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 28 Oct 2008 17:58:52 -0500
Subject: [41224] trunk/dports/ruby/rb-cocoa
In-Reply-To: <74c219d30810281546s49a77b6ap21d73767980598ae@mail.gmail.com>
References: <20081028134525.B7A6D5C94D8@beta.macosforge.org>
	<4680127E-73FB-4AE0-A4D3-256DF4EF9D65@macports.org>
	<74c219d30810281546s49a77b6ap21d73767980598ae@mail.gmail.com>
Message-ID: <03C2DF43-32AD-4C10-82D9-7C7177B94253@macports.org>

On Oct 28, 2008, at 17:46, Toby Peterson wrote:

> On Tue, Oct 28, 2008 at 12:52 PM, Ryan Schmidt wrote:
>
>> On Oct 28, 2008, at 08:45, kimuraw at macports.org wrote:
>>
>>> +post-extract {
>>> +  cd ${worksrcpath}
>>> +  system "find . -type d -name '.svn' | xargs /bin/rm -rf"
>>> +}
>>
>> Could you change this to not use the cd command, please? The cd  
>> command will
>> not be available in MacPorts 1.7.0 and later. Try:
>>
>> system "find ${worksrcpath} -type d -name '.svn' | xargs /bin/rm -rf"
>
> Seems potentially dangerous if ${worksrcpath} happens to contain  
> spaces
>
> find ${worksrcpath} -type d -name '.svn' -exec rm -r '{}' \;

worksrcpaths containing spaces are pretty dangerous already, which is  
why ports don't generally have them.

If you really need to support such paths, you'll need quotes around  
the worksrcpath:

find "${worksrcpath}" -type d -name '.svn' -exec rm -r '{}' \;

Or the original way:

find "${worksrcpath}" -type d -name '.svn' -print0 | xargs -0 /bin/rm  
-rf



From ryandesign at macports.org  Wed Oct 29 01:01:49 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 29 Oct 2008 03:01:49 -0500
Subject: [41229] trunk/dports/science
In-Reply-To: <20081028201733.E85085CB6E6@beta.macosforge.org>
References: <20081028201733.E85085CB6E6@beta.macosforge.org>
Message-ID: <8158D9B7-7F37-401E-ACED-2892D40807D0@macports.org>

On Oct 28, 2008, at 15:17, macsforever2000 at macports.org wrote:

> +distfiles        fastcap-${version}wr
> +worksrcdir       fastcap-${version}wr

For both fastcap and fasthenry, it's weird that you're downloading a  
distfile file with no extension at all. They have a file with the  
usual .tar.gz extension so that would be preferable. The attached  
patch fixes it.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fast1.diff
Type: application/octet-stream
Size: 1263 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20081029/1e9acaa2/attachment.obj>

From ryandesign at macports.org  Wed Oct 29 01:07:01 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 29 Oct 2008 03:07:01 -0500
Subject: [41229] trunk/dports/science
In-Reply-To: <20081028201733.E85085CB6E6@beta.macosforge.org>
References: <20081028201733.E85085CB6E6@beta.macosforge.org>
Message-ID: <35C03101-C402-4DA7-A051-1546978D805E@macports.org>

On Oct 28, 2008, at 15:17, macsforever2000 at macports.org wrote:

> +destroot {
> +    xinstall -m 755 ${worksrcpath}/bin/busgen ${destroot}${prefix}/ 
> bin
> +    xinstall -m 755 ${worksrcpath}/bin/capgen ${destroot}${prefix}/ 
> bin
> +    xinstall -m 755 ${worksrcpath}/bin/cubegen ${destroot}$ 
> {prefix}/bin
> +    xinstall -m 755 ${worksrcpath}/bin/fastcap ${destroot}$ 
> {prefix}/bin
> +    xinstall -m 755 ${worksrcpath}/bin/pipedgen ${destroot}$ 
> {prefix}/bin
> +    xinstall -m 755 ${worksrcpath}/bin/pyragen ${destroot}$ 
> {prefix}/bin

You can simplify the destroot of fastcap and fasthenry by installing  
all binaries in a single xinstall command. See attached patch.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fast2.diff
Type: application/octet-stream
Size: 1691 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20081029/c973d301/attachment.obj>

From macsforever2000 at macports.org  Wed Oct 29 08:50:53 2008
From: macsforever2000 at macports.org (Frank Schima)
Date: Wed, 29 Oct 2008 09:50:53 -0600
Subject: [41229] trunk/dports/science
In-Reply-To: <35C03101-C402-4DA7-A051-1546978D805E@macports.org>
References: <20081028201733.E85085CB6E6@beta.macosforge.org>
	<35C03101-C402-4DA7-A051-1546978D805E@macports.org>
Message-ID: <CC4F0855-F608-4F7B-9CBA-8C10E336324D@macports.org>

Hi Ryan,


On Oct 29, 2008, at 2:07 AM, Ryan Schmidt wrote:

> On Oct 28, 2008, at 15:17, macsforever2000 at macports.org wrote:
>
>> +distfiles        fastcap-${version}wr
>> +worksrcdir       fastcap-${version}wr
>
> For both fastcap and fasthenry, it's weird that you're downloading a  
> distfile file with no extension at all. They have a file with the  
> usual .tar.gz extension so that would be preferable. The attached  
> patch fixes it.
>
> <fast1.diff>

and

>> +destroot {
>> +    xinstall -m 755 ${worksrcpath}/bin/busgen ${destroot}${prefix}/ 
>> bin
>> +    xinstall -m 755 ${worksrcpath}/bin/capgen ${destroot}${prefix}/ 
>> bin
>> +    xinstall -m 755 ${worksrcpath}/bin/cubegen ${destroot}$ 
>> {prefix}/bin
>> +    xinstall -m 755 ${worksrcpath}/bin/fastcap ${destroot}$ 
>> {prefix}/bin
>> +    xinstall -m 755 ${worksrcpath}/bin/pipedgen ${destroot}$ 
>> {prefix}/bin
>> +    xinstall -m 755 ${worksrcpath}/bin/pyragen ${destroot}$ 
>> {prefix}/bin
>
> You can simplify the destroot of fastcap and fasthenry by installing  
> all binaries in a single xinstall command. See attached patch.
>
> <fast2.diff>

Changed in r41263 and r41264. Thanks!


Cheers!
Frank

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20081029/5dcef359/attachment.html>

From devans at macports.org  Wed Oct 29 09:35:20 2008
From: devans at macports.org (David Evans)
Date: Wed, 29 Oct 2008 09:35:20 -0700
Subject: [41253] trunk/dports/graphics/cairomm/Portfile
In-Reply-To: <20081029115019.2394E5E123C@beta.macosforge.org>
References: <20081029115019.2394E5E123C@beta.macosforge.org>
Message-ID: <490890C8.6050500@macports.org>

jmr at macports.org wrote:
>
> Revision
>     41253 <http://trac.macports.org/changeset/41253>
> Author
>     jmr at macports.org
> Date
>     2008-10-29 04:50:17 -0700 (Wed, 29 Oct 2008)
>
>
>       Log Message
>
> cairomm: update to 1.7.0. Also remove dependencies apart from cairo, since
> the rest will be pulled in via cairo, and will vary depending on how cairo is
> built.
>
>
>       Modified Paths
>
>     * trunk/dports/graphics/cairomm/Portfile
>       <#trunkdportsgraphicscairommPortfile>
>
>
>       Diff
>
>
>         Modified: trunk/dports/graphics/cairomm/Portfile (41252 => 41253)
>
>
> --- trunk/dports/graphics/cairomm/Portfile	2008-10-29 11:19:52 UTC (rev 41252)
> +++ trunk/dports/graphics/cairomm/Portfile	2008-10-29 11:50:17 UTC (rev 41253)
> @@ -3,7 +3,7 @@
>  PortSystem 1.0
>  
>  name		cairomm
> -version		1.6.4
> +version		1.7.0
>  categories	graphics
>  maintainers	nomaintainer
>  description	Cairo is a vector graphics library with cross-device output support.
> @@ -15,12 +15,11 @@
>  master_sites 	${homepage}releases/
>  platforms	darwin
>  
> -checksums	md5 63561c62536173a98f03005dfe55c90e \
> -		sha1 61f1a1adcd3f147da89faf3311842e4f68763db4 \
> -		rmd160 95ba7bf4a2c8ff706eaceef2a31aaa19375fbf6c
> +checksums	md5 8c67b8abd49960b6b0f42ad28d19fd55 \
> +		sha1 6d19e71717abf559ffb868423669ba23860fc94b \
> +		rmd160 32976a31a7922f241a7700aef48b9d136555f32c
>  
> -depends_lib	port:xrender port:fontconfig port:freetype port:libpng \
> -		port:render port:zlib port:expat port:cairo
> +depends_lib	port:cairo
>  
>  livecheck.check regex
>  livecheck.url   http://cairographics.org/releases/
> ------------------------------------------------------------------------
I really don't think this is a good idea as 1.7.0 is an unstable release
that is known to break parts of the
previous API/ABI and therefore probably a lot of ports that depend on it.

See the announcement attached.

Dave

-------------- next part --------------
An embedded message was scrubbed...
From: Jonathon Jongsma <jonathon at quotidian.org>
Subject: [cairo] [cairo-announce] cairomm release 1.7.0 (UNSTABLE) now
	available
Date: Sat, 25 Oct 2008 23:46:16 -0500
Size: 8553
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20081029/7d5b76d5/attachment.mht>

From frstan at bellsouth.net  Wed Oct 29 10:25:09 2008
From: frstan at bellsouth.net (William Davis)
Date: Wed, 29 Oct 2008 13:25:09 -0400
Subject: evince wants old libopenjpeg
In-Reply-To: <EE6E306D-09F7-41AB-B3F7-D76431358336@bellsouth.net>
References: <EE6E306D-09F7-41AB-B3F7-D76431358336@bellsouth.net>
Message-ID: <BB0D54B0-BD36-404D-8391-600C3A632CE1@bellsouth.net>

I have made ticket Ticket #17044 (new defect)
Opened 4 seconds ago
evince wants old libopenjeg


for this.  I post it here because evince has no maintainer.


On Oct 28, 2008, at 11:30 AM, William Davis wrote:

> The new evince upgrade is looking for libopenjpeg 2.1.2
> but libopenjpeg is at version 2.1.3 in the current openjpeg.
>
> ld: file not found: libopenjpeg-2.1.2.0.dylib
> collect2: ld returned 1 exit status
> make[3]: *** [libpdfdocument.la] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20081029/049fcd81/attachment.html>

From devans at macports.org  Wed Oct 29 10:58:34 2008
From: devans at macports.org (David Evans)
Date: Wed, 29 Oct 2008 10:58:34 -0700
Subject: [41253] trunk/dports/graphics/cairomm/Portfile
In-Reply-To: <490890C8.6050500@macports.org>
References: <20081029115019.2394E5E123C@beta.macosforge.org>
	<490890C8.6050500@macports.org>
Message-ID: <4908A44A.1000109@macports.org>

David Evans wrote:
> jmr at macports.org wrote:
>   
>> Revision
>>     41253 <http://trac.macports.org/changeset/41253>
>> Author
>>     jmr at macports.org
>> Date
>>     2008-10-29 04:50:17 -0700 (Wed, 29 Oct 2008)
>>
>>
>>       Log Message
>>
>> cairomm: update to 1.7.0. Also remove dependencies apart from cairo, since
>> the rest will be pulled in via cairo, and will vary depending on how cairo is
>> built.
>>
>>
>>     
> I really don't think this is a good idea as 1.7.0 is an unstable release
> that is known to break parts of the
> previous API/ABI and therefore probably a lot of ports that depend on it.
>
> See the announcement attached.
>
> Dave
>
>   
In addition, I just tried building cairomm 1.7.0 from svn trunk and it
fails as shown below.

There's current thread on the cairo list concerning this same failure in
Fink.

This breaks inkscape among others.

I suggest that we roll back cairomm to the previous version (1.6.4) and
add a new port
cairomm-devel  for 1.7.0 unstable branch similar to what Ryan has done
with pango and cairo.

That way people can experiment with the cairomm-devel version and we
retain the stable cairomm
so as not to break the apps that depend on it.

Is this OK?

/bin/sh ../libtool --tag=CXX   --mode=compile /usr/bin/g++-4.0
-DHAVE_CONFIG_H -I. -I.. -DXTHREADS -I/opt/local/include/cairo
-I/opt/local/include/pixman-1 -I/opt/local/include/freetype2
-I/opt/local/include -I/opt/local/include/libpng12 -I/usr/X11R6/include
-I/opt/local/include/sigc++-2.0 -I/opt/local/lib/sigc++-2.0/include   
-I/opt/local/include  -O2 -MT quartz_font.lo -MD -MP -MF
.deps/quartz_font.Tpo -c -o quartz_font.lo quartz_font.cc
 /usr/bin/g++-4.0 -DHAVE_CONFIG_H -I. -I.. -DXTHREADS
-I/opt/local/include/cairo -I/opt/local/include/pixman-1
-I/opt/local/include/freetype2 -I/opt/local/include
-I/opt/local/include/libpng12 -I/usr/X11R6/include
-I/opt/local/include/sigc++-2.0 -I/opt/local/lib/sigc++-2.0/include
-I/opt/local/include -O2 -MT quartz_font.lo -MD -MP -MF
.deps/quartz_font.Tpo -c quartz_font.cc  -fno-common -DPIC -o
.libs/quartz_font.o
/opt/local/include/sigc++-2.0/sigc++/functors/functor_trait.h:37: error:
expected identifier before numeric constant
/opt/local/include/sigc++-2.0/sigc++/functors/functor_trait.h:37: error:
expected unqualified-id before numeric constant
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1088: error:
expected type-specifier before numeric constant
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1088: error:
expected `>' before numeric constant
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1090: error:
'T_arg2' was not declared in this scope
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1090: error:
'T_arg3' was not declared in this scope
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1090: error:
'T_arg4' was not declared in this scope
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1090: error:
'T_arg5' was not declared in this scope
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1090: error:
'T_arg6' was not declared in this scope
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1090: error:
'T_arg7' was not declared in this scope
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1090: error:
template argument 3 is invalid
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1090: error:
template argument 4 is invalid
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1090: error:
template argument 5 is invalid
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1090: error:
template argument 6 is invalid
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1090: error:
template argument 7 is invalid
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1090: error:
template argument 8 is invalid
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1093: error:
'T_arg2' was not declared in this scope
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1093: error:
'T_arg3' was not declared in this scope
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1093: error:
'T_arg4' was not declared in this scope
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1093: error:
'T_arg5' was not declared in this scope
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1093: error:
'T_arg6' was not declared in this scope
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1093: error:
'T_arg7' was not declared in this scope
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1093: error:
template argument 3 is invalid
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1093: error:
template argument 4 is invalid
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1093: error:
template argument 5 is invalid
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1093: error:
template argument 6 is invalid
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1093: error:
template argument 7 is invalid
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1093: error:
template argument 8 is invalid
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h: In constructor
'sigc::slot<T_return, T_arg1>::slot(const T_functor&)':
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1102: error:
'typedef int sigc::slot<T_return, T_arg1>::parent_type' is not a
non-static data member of 'sigc::slot<T_return, T_arg1>'
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h: In copy
constructor 'sigc::slot<T_return, T_arg1>::slot(const
sigc::slot<T_return, T_arg1>&)':
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1105: error:
'typedef int sigc::slot<T_return, T_arg1>::parent_type' is not a
non-static data member of 'sigc::slot<T_return, T_arg1>'
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h: At global scope:
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1117: error: wrong
number of template arguments (8, should be 2)
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1089: error:
provided for 'template<class T_return, class T_arg1> class sigc::slot'
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1144: error: wrong
number of template arguments (8, should be 2)
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1089: error:
provided for 'template<class T_return, class T_arg1> class sigc::slot'
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1171: error: wrong
number of template arguments (8, should be 2)
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1089: error:
provided for 'template<class T_return, class T_arg1> class sigc::slot'
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1198: error: wrong
number of template arguments (8, should be 2)
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1089: error:
provided for 'template<class T_return, class T_arg1> class sigc::slot'
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1225: error: wrong
number of template arguments (8, should be 2)
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1089: error:
provided for 'template<class T_return, class T_arg1> class sigc::slot'
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1252: error: wrong
number of template arguments (8, should be 2)
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1089: error:
provided for 'template<class T_return, class T_arg1> class sigc::slot'
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1279: error: wrong
number of template arguments (8, should be 2)
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1089: error:
provided for 'template<class T_return, class T_arg1> class sigc::slot'
../cairomm/fontface.h:187: error: wrong number of template arguments (4,
should be 2)
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1089: error:
provided for 'template<class T_return, class T_arg1> class sigc::slot'
../cairomm/fontface.h:239: error: wrong number of template arguments (4,
should be 2)
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1089: error:
provided for 'template<class T_return, class T_arg1> class sigc::slot'
../cairomm/fontface.h:301: error: wrong number of template arguments (5,
should be 2)
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1089: error:
provided for 'template<class T_return, class T_arg1> class sigc::slot'
../cairomm/fontface.h:360: error: wrong number of template arguments (6,
should be 2)
/opt/local/include/sigc++-2.0/sigc++/functors/slot.h:1089: error:
provided for 'template<class T_return, class T_arg1> class sigc::slot'
make[3]: *** [quartz_font.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1



From febeling at macports.org  Wed Oct 29 14:30:17 2008
From: febeling at macports.org (C. Florian Ebeling)
Date: Wed, 29 Oct 2008 22:30:17 +0100
Subject: General OS X question: DYLD_LIBRARY_PATH and install name
Message-ID: <5cbbe4ae0810291430s7e381f0fu329bbed369764be6@mail.gmail.com>

Hi,

I recently came across the statement that one needs to set the DYLD_LIBRARY_PATH
variable if you want to run an executable linked against a dynamic
library which is not to be found
in any of the standard locations (~/lib:/usr/lib:/usr/local/lib). That
is the case for all mp installed
libraries, I'd say. My immediate reaction was that this is not true,
and that everything is fine
without the variable as long as `otool -L' points to the right
location. So the "install name" counts.
To be sure I reviewed some of the apple documentation [1][2], and that
read quite like you _do_
really need the variable. So what is the truth now? :) Please
enlighten me. Do you really
need a special environment at run time when you use a library
installed by MacPorts? -- because
that's what it comes down to, effectively.

(Add-on question: are dynamic libraries usually "dependent libraries"
or are the "dynamically loaded
libaries" -- and how do you tell?)

Cheers,
Florian

[1] http://url.ie/ug8
[2] http://url.ie/uga


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

From blb at macports.org  Wed Oct 29 14:49:08 2008
From: blb at macports.org (Bryan Blackburn)
Date: Wed, 29 Oct 2008 15:49:08 -0600
Subject: General OS X question: DYLD_LIBRARY_PATH and install name
In-Reply-To: <5cbbe4ae0810291430s7e381f0fu329bbed369764be6@mail.gmail.com>
References: <5cbbe4ae0810291430s7e381f0fu329bbed369764be6@mail.gmail.com>
Message-ID: <20081029214908.GA863@ninagal.withay.com>

On Wed, Oct 29, 2008 at 10:30:17PM +0100, C. Florian Ebeling said:
> Hi,
> 
> I recently came across the statement that one needs to set the DYLD_LIBRARY_PATH
> variable if you want to run an executable linked against a dynamic
> library which is not to be found
> in any of the standard locations (~/lib:/usr/lib:/usr/local/lib). That
> is the case for all mp installed
> libraries, I'd say. My immediate reaction was that this is not true,
> and that everything is fine
> without the variable as long as `otool -L' points to the right
> location. So the "install name" counts.
> To be sure I reviewed some of the apple documentation [1][2], and that
> read quite like you _do_
> really need the variable. So what is the truth now? :) Please
> enlighten me. Do you really
> need a special environment at run time when you use a library
> installed by MacPorts? -- because
> that's what it comes down to, effectively.
> 

You might be commingling two different, but similar, ideas: an item
can be linked directly against a dylib (eg, what you see with 'otool -L')
and you can load a dylib (or bundle) at runtime using dlopen().

If 'otool -L' shows a given item linked against the right libs, then for
those you don't need to fool with any env variables.  dlopen(), I believe,
does need to know if you're installing items outside the standard locations.

Also, I believe that using the fallback version is preferred when one must
be used, there's been issues with the system having trouble finding stuff
when DYLD_LIBRARY_PATH was used.

Bryan


> (Add-on question: are dynamic libraries usually "dependent libraries"
> or are the "dynamically loaded
> libaries" -- and how do you tell?)
> 
> Cheers,
> Florian
> 
> [1] http://url.ie/ug8
> [2] http://url.ie/uga
> 
> 
> -- 
> Florian Ebeling
> Twitter: febeling
> florian.ebeling at gmail.com

From jmr at macports.org  Wed Oct 29 18:29:38 2008
From: jmr at macports.org (Joshua Root)
Date: Thu, 30 Oct 2008 12:29:38 +1100
Subject: [41253] trunk/dports/graphics/cairomm/Portfile
In-Reply-To: <49088E1C.2030101@orindasoftware.com>
References: <20081029115019.2394E5E123C@beta.macosforge.org>
	<49088E1C.2030101@orindasoftware.com>
Message-ID: <49090E02.5030208@macports.org>

David Evans wrote:
> jmr at macports.org wrote:
>> --- trunk/dports/graphics/cairomm/Portfile	2008-10-29 11:19:52 UTC (rev 41252)
>> +++ trunk/dports/graphics/cairomm/Portfile	2008-10-29 11:50:17 UTC (rev 41253)
>> @@ -3,7 +3,7 @@
>>  PortSystem 1.0
>>  
>>  name		cairomm
>> -version		1.6.4
>> +version		1.7.0

>> ------------------------------------------------------------------------
> I really don't think this is a good idea as 1.7.0 is an unstable release
> that is known to break parts of the
> previous API/ABI and therefore probably a lot of ports that depend on it. 

You're right of course. Thanks for catching and fixing.

- Josh

From ryandesign at macports.org  Thu Oct 30 00:22:47 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 30 Oct 2008 02:22:47 -0500
Subject: [41277] trunk/dports/graphics/cairomm/Portfile
In-Reply-To: <20081029184059.EDD085E3772@beta.macosforge.org>
References: <20081029184059.EDD085E3772@beta.macosforge.org>
Message-ID: <F8831B2C-93DD-490E-B778-91F05C79182E@macports.org>


On Oct 29, 2008, at 13:40, devans at macports.org wrote:

> Revision: 41277
>           http://trac.macports.org/changeset/41277
> Author:   devans at macports.org
> Date:     2008-10-29 11:40:59 -0700 (Wed, 29 Oct 2008)
> Log Message:
> -----------
> Revert to latest stable version 1.6.4 to avoid breakage of  
> dependents.  Will create a new cairomm-devel for the unstable 1.7.0  
> branch.

> -version		1.7.0
> +version		1.6.4

You could add "epoch 1" to the port. That way, if anybody had already  
upgraded to 1.7.0, they will now be informed via "port outdated" that  
they should go back to 1.6.4.


From florian.ebeling at gmail.com  Thu Oct 30 01:14:04 2008
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Thu, 30 Oct 2008 09:14:04 +0100
Subject: General OS X question: DYLD_LIBRARY_PATH and install name
In-Reply-To: <20081029214908.GA863@ninagal.withay.com>
References: <5cbbe4ae0810291430s7e381f0fu329bbed369764be6@mail.gmail.com>
	<20081029214908.GA863@ninagal.withay.com>
Message-ID: <5cbbe4ae0810300114j6d9de1a9yca2702bb46753596@mail.gmail.com>

On Wed, Oct 29, 2008 at 10:49 PM, Bryan Blackburn <blb at macports.org> wrote:
> On Wed, Oct 29, 2008 at 10:30:17PM +0100, C. Florian Ebeling said:
>> I recently came across the statement that one needs to set the DYLD_LIBRARY_PATH
>> variable if you want to run an executable linked against a dynamic
>> library which is not to be found
>> in any of the standard locations (~/lib:/usr/lib:/usr/local/lib). That
>> is the case for all mp installed
>> libraries, I'd say. My immediate reaction was that this is not true,
>> and that everything is fine
>> without the variable as long as `otool -L' points to the right
>> location. So the "install name" counts.
>
> You might be commingling two different, but similar, ideas: an item
> can be linked directly against a dylib (eg, what you see with 'otool -L')
> and you can load a dylib (or bundle) at runtime using dlopen().

True, actually. I mixed those two up, even though I kind of know the
difference.

I think the dyld(1) documentation could be made a bit clearer
on this matter, because it didn't reduce my confusion. I do
realize that this is not the right place to complain about apple
documentation, though. :)

So, for usual operation of something linked against mp libs, no
DYLD_* environment variables have to be set. This might be different if
you deal with plugin-like objects opened by dlopen, which is
probably an exceptional case, but in general the rule holds. Right?

Florian


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

From macports-mgr at lists.macosforge.org  Thu Oct 30 01:15:05 2008
From: macports-mgr at lists.macosforge.org (macports-mgr at lists.macosforge.org)
Date: Thu, 30 Oct 2008 01:15:05 -0700 (PDT)
Subject: PortIndex2MySQL run failure on Thursday 2008-10-30 at 01:15:00
Message-ID: <20081030081505.B089E1086B71@gamma.macosforge.org>


Synchronizing local ports tree from file:///admin/var/macports/ports/
Synchronizing local ports tree from file:///rsync/macports-san/release/ports/
Error: CHILDSTATUS 11797 1: ERROR 1062 (23000) at line 16252: Duplicate entry 'ruby' for key 1

From jmr at macports.org  Thu Oct 30 01:20:26 2008
From: jmr at macports.org (Joshua Root)
Date: Thu, 30 Oct 2008 19:20:26 +1100
Subject: [41277] trunk/dports/graphics/cairomm/Portfile
In-Reply-To: <F8831B2C-93DD-490E-B778-91F05C79182E@macports.org>
References: <20081029184059.EDD085E3772@beta.macosforge.org>
	<F8831B2C-93DD-490E-B778-91F05C79182E@macports.org>
Message-ID: <49096E4A.90501@macports.org>

Ryan Schmidt wrote:
> 
> On Oct 29, 2008, at 13:40, devans at macports.org wrote:
> 
>> Revision: 41277
>>           http://trac.macports.org/changeset/41277
>> Author:   devans at macports.org
>> Date:     2008-10-29 11:40:59 -0700 (Wed, 29 Oct 2008)
>> Log Message:
>> -----------
>> Revert to latest stable version 1.6.4 to avoid breakage of
>> dependents.  Will create a new cairomm-devel for the unstable 1.7.0
>> branch.
> 
>> -version        1.7.0
>> +version        1.6.4
> 
> You could add "epoch 1" to the port. That way, if anybody had already
> upgraded to 1.7.0, they will now be informed via "port outdated" that
> they should go back to 1.6.4.

He reverted the update before it was indexed, so it should be OK.

- Josh

From kimuraw at macports.org  Thu Oct 30 07:06:38 2008
From: kimuraw at macports.org (kimura wataru)
Date: Thu, 30 Oct 2008 23:06:38 +0900
Subject: [41224] trunk/dports/ruby/rb-cocoa
In-Reply-To: <03C2DF43-32AD-4C10-82D9-7C7177B94253@macports.org>
References: <20081028134525.B7A6D5C94D8@beta.macosforge.org>
	<4680127E-73FB-4AE0-A4D3-256DF4EF9D65@macports.org>
	<74c219d30810281546s49a77b6ap21d73767980598ae@mail.gmail.com>
	<03C2DF43-32AD-4C10-82D9-7C7177B94253@macports.org>
Message-ID: <20081030230638436859.e4686bdc@macports.org>

Thanks Ryan and Toby,

I fixed rb-cocoa Portfile at r41309.

On Tue, 28 Oct 2008 17:58:52 -0500, Ryan Schmidt wrote:
>>> Could you change this to not use the cd command, please? The cd 
>>> command will
>>> not be available in MacPorts 1.7.0 and later. Try:
>>> 
>>> system "find ${worksrcpath} -type d -name '.svn' | xargs /bin/rm -rf"
>> 
>> Seems potentially dangerous if ${worksrcpath} happens to contain spaces
>> 
>> find ${worksrcpath} -type d -name '.svn' -exec rm -r '{}' \;
> 
> worksrcpaths containing spaces are pretty dangerous already, which is 
> why ports don't generally have them.
> 
> If you really need to support such paths, you'll need quotes around 
> the worksrcpath:
> 
> find "${worksrcpath}" -type d -name '.svn' -exec rm -r '{}' \;
> 
> Or the original way:
> 
> find "${worksrcpath}" -type d -name '.svn' -print0 | xargs -0 /bin/rm -rf
> 
> 

From andrea.damore at macports.org  Thu Oct 30 12:19:17 2008
From: andrea.damore at macports.org (Andrea D'Amore)
Date: Thu, 30 Oct 2008 20:19:17 +0100
Subject: dummy package for new portfile
Message-ID: <E9248B79-BD9B-467D-8C09-4B93A683C7CB@macports.org>

Hello,
I'm starting a new portfile and, as always, I'd like to have an empty  
scratch portfile to start with.

Usually I copy a previous portfile or the example from the Guide so  
this led me to think if we could have a port named "dummy" or  
"portfile-dummy" as file skeleton with all variables, maybe commented.
This could speed up new port writing, what do you think?

I'm aware that probably people just made their own templates in  
whatever editor they use, I was wondering if we could have a port  
option for this.


Bye

Andrea

From wsiegrist at apple.com  Thu Oct 30 12:25:07 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Thu, 30 Oct 2008 12:25:07 -0700
Subject: PortIndex2MySQL run failure on Thursday 2008-10-30 at 01:15:00
In-Reply-To: <20081030081505.B089E1086B71@gamma.macosforge.org>
References: <20081030081505.B089E1086B71@gamma.macosforge.org>
Message-ID: <B10CD0FA-1A3C-47C0-8F69-F63A22D7D90A@apple.com>

This  has been corrected and the index regenerated.

-Bill


On Oct 30, 2008, at 1:15 AM, macports-mgr at lists.macosforge.org wrote:

>
> Synchronizing local ports tree from file:///admin/var/macports/ports/
> Synchronizing local ports tree from file:///rsync/macports-san/release/ports/
> Error: CHILDSTATUS 11797 1: ERROR 1062 (23000) at line 16252:  
> Duplicate entry 'ruby' for key 1
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev



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

From ryandesign at macports.org  Thu Oct 30 12:32:33 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 30 Oct 2008 14:32:33 -0500
Subject: dummy package for new portfile
In-Reply-To: <E9248B79-BD9B-467D-8C09-4B93A683C7CB@macports.org>
References: <E9248B79-BD9B-467D-8C09-4B93A683C7CB@macports.org>
Message-ID: <A1D7924A-A2C1-48D9-9F26-0CA526338414@macports.org>


On Oct 30, 2008, at 14:19, Andrea D'Amore wrote:

> I'm starting a new portfile and, as always, I'd like to have an  
> empty scratch portfile to start with.
>
> Usually I copy a previous portfile or the example from the Guide so  
> this led me to think if we could have a port named "dummy" or  
> "portfile-dummy" as file skeleton with all variables, maybe commented.
> This could speed up new port writing, what do you think?
>
> I'm aware that probably people just made their own templates in  
> whatever editor they use, I was wondering if we could have a port  
> option for this.

If we were to do this, we would need, at least, one dummy that does  
not use a portgroup, and one dummy per portgroup. (A port that uses  
the xcode portgroup, for example, would be rather different from one  
that doesn't use a portgroup, or from one that uses one of the python  
portgroups.)

When I make a new port I suppose I end up going to one of my existing  
ports, copying parts of it, and modifying. "port lint" can tell you  
if you've forgotten something important.


From florian.ebeling at gmail.com  Thu Oct 30 12:45:29 2008
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Thu, 30 Oct 2008 20:45:29 +0100
Subject: dummy package for new portfile
In-Reply-To: <A1D7924A-A2C1-48D9-9F26-0CA526338414@macports.org>
References: <E9248B79-BD9B-467D-8C09-4B93A683C7CB@macports.org>
	<A1D7924A-A2C1-48D9-9F26-0CA526338414@macports.org>
Message-ID: <5cbbe4ae0810301245k7675b0d8wf7d0541035edac55@mail.gmail.com>

On Thu, Oct 30, 2008 at 8:32 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On Oct 30, 2008, at 14:19, Andrea D'Amore wrote:
>
>> I'm starting a new portfile and, as always, I'd like to have an empty
>> scratch portfile to start with.
>>
>> Usually I copy a previous portfile or the example from the Guide so this
>> led me to think if we could have a port named "dummy" or "portfile-dummy" as
>> file skeleton with all variables, maybe commented.
>> This could speed up new port writing, what do you think?
>>
>> I'm aware that probably people just made their own templates in whatever
>> editor they use, I was wondering if we could have a port option for this.
>
> If we were to do this, we would need, at least, one dummy that does not use
> a portgroup, and one dummy per portgroup. (A port that uses the xcode
> portgroup, for example, would be rather different from one that doesn't use
> a portgroup, or from one that uses one of the python portgroups.)
>
> When I make a new port I suppose I end up going to one of my existing ports,
> copying parts of it, and modifying. "port lint" can tell you if you've
> forgotten something important.

yes, they tend to be pretty deverse in the end. Maybe a wiki page with
links to particularly beautiful examples from a range of types would be good?

Should we make a beauty contest for portfiles? ;)

Florian

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

From jkh at apple.com  Thu Oct 30 14:17:36 2008
From: jkh at apple.com (Jordan K. Hubbard)
Date: Thu, 30 Oct 2008 14:17:36 -0700
Subject: dummy package for new portfile
In-Reply-To: <E9248B79-BD9B-467D-8C09-4B93A683C7CB@macports.org>
References: <E9248B79-BD9B-467D-8C09-4B93A683C7CB@macports.org>
Message-ID: <8917798C-4489-4F27-8959-9C30434E5E88@apple.com>

This has been requested before, and doesn't seem a bad idea, though  
one alternate approach might be to add a "template" command to  
port(1).  Then you would just say "port template > mynewportfile" and  
not have to go looking for the template buried somewhere in the  
dports/ directory.

- Jordan

On Oct 30, 2008, at 12:19 PM, Andrea D'Amore wrote:

> Usually I copy a previous portfile or the example from the Guide so  
> this led me to think if we could have a port named "dummy" or  
> "portfile-dummy" as file skeleton with all variables, maybe commented.
> This could speed up new port writing, what do you think?


From blb at macports.org  Thu Oct 30 19:51:16 2008
From: blb at macports.org (Bryan Blackburn)
Date: Thu, 30 Oct 2008 20:51:16 -0600
Subject: dummy package for new portfile
In-Reply-To: <8917798C-4489-4F27-8959-9C30434E5E88@apple.com>
References: <E9248B79-BD9B-467D-8C09-4B93A683C7CB@macports.org>
	<8917798C-4489-4F27-8959-9C30434E5E88@apple.com>
Message-ID: <20081031025116.GK453@ninagal.withay.com>

On Thu, Oct 30, 2008 at 02:17:36PM -0700, Jordan K. Hubbard said:
> This has been requested before, and doesn't seem a bad idea, though one 
> alternate approach might be to add a "template" command to port(1).  Then 
> you would just say "port template > mynewportfile" and not have to go 
> looking for the template buried somewhere in the dports/ directory.
>

I just added:

<http://trac.macports.org/browser/contrib/portfile-gen/portfile-gen>

which is a very basic wrapper script around the templates I've used for
years.  It's not much but a place to start, just run it with the port name
and version (and optional port group), redirect into a Portfile and replace
the 'replaceme' bits as needed.  It's written in Tcl so that it should be
easy to integrate into port if it's actually useful.

It currently only handles perl5, python25, and ruby port groups as those are
the only ones I've used.  Feel free to update it if you feel the motivation.

Bryan


> - Jordan
>
> On Oct 30, 2008, at 12:19 PM, Andrea D'Amore wrote:
>
>> Usually I copy a previous portfile or the example from the Guide so  
>> this led me to think if we could have a port named "dummy" or  
>> "portfile-dummy" as file skeleton with all variables, maybe commented.
>> This could speed up new port writing, what do you think?
>

From ryandesign at macports.org  Thu Oct 30 23:08:51 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 31 Oct 2008 01:08:51 -0500
Subject: -flat_namespace and -undefined suppress
In-Reply-To: <20081031044708.3FA565F8548@beta.macosforge.org>
References: <20081031044708.3FA565F8548@beta.macosforge.org>
Message-ID: <D64C0FAE-D40F-449A-A049-543FCE7C084F@macports.org>

Joshua,

I saw many commits come through today with log messages like this:

On Oct 30, 2008, at 23:47, jmr at macports.org wrote:

> don't use -flat_namespace or -undefined suppress

Could you tell us a bit more about what the implications are here?  
Can you speculate about why that was in the portfiles in the first  
place, and tell us why you're removing it now? I've seen it in many  
portfiles and never really known why.


From jmr at macports.org  Fri Oct 31 00:07:10 2008
From: jmr at macports.org (Joshua Root)
Date: Fri, 31 Oct 2008 18:07:10 +1100
Subject: -flat_namespace and -undefined suppress
In-Reply-To: <D64C0FAE-D40F-449A-A049-543FCE7C084F@macports.org>
References: <20081031044708.3FA565F8548@beta.macosforge.org>
	<D64C0FAE-D40F-449A-A049-543FCE7C084F@macports.org>
Message-ID: <490AAE9E.5090004@macports.org>

Ryan Schmidt wrote:
> Joshua,
> 
> I saw many commits come through today with log messages like this:
> 
> On Oct 30, 2008, at 23:47, jmr at macports.org wrote:
> 
>> don't use -flat_namespace or -undefined suppress
> 
> Could you tell us a bit more about what the implications are here? Can
> you speculate about why that was in the portfiles in the first place,
> and tell us why you're removing it now? I've seen it in many portfiles
> and never really known why.

Correct me if I'm wrong on any of this, but this is my understanding of
the situation.

Before Panther, there was only flat namespace. The dynamic linker always
loaded symbols from the first-loaded library that defined them.

Panther introduced two-level namespace, which keeps track of which
library each symbol is meant to come from. Two-level namespace has been
the default for a long time now.

Specifying -flat_namespace was a compatibility hack that was often
needed back when Panther was new, for software that expected that
behaviour. Practically everything, including libtool, now does the right
thing with two-level namespace.

Forcing -flat_namespace these days is usually just a recipe for pain, as
seen in some recent tickets about php5 and libxml2.

I haven't been bumping revisions because it generally isn't causing
immediate issues, so telling everyone to recompile seems unwarranted.

- Josh

From ramercer at gmail.com  Fri Oct 31 07:38:54 2008
From: ramercer at gmail.com (Adam Mercer)
Date: Fri, 31 Oct 2008 09:38:54 -0500
Subject: fetch.ignore_sslcert yes still checking ssl cert
In-Reply-To: <799406d60810251000i2b56c058m8b647ff0ec5240a0@mail.gmail.com>
References: <799406d60810251000i2b56c058m8b647ff0ec5240a0@mail.gmail.com>
Message-ID: <799406d60810310738x471f155cmd9e0a54b0d6b2f68@mail.gmail.com>

Hi

Anyone know what's going on here? This isn't as pressing now as I
asked upstream to distribute the tarballs over both http and https,
but its still causing a problem with livecheck as the project pages as
over https?

Cheers

Adam

On Sat, Oct 25, 2008 at 12:00, Adam Mercer <ram at macports.org> wrote:
> Hi
>
> The upstream sources of a few packages I maintain have recently
> switched to be served over https. Fetching from this https server is
> failing with the following:
>
> Warning: couldn't fetch
> https://www.lsc-group.phys.uwm.edu/daswg/projects/metaio/release-7-2/metaio-7.2.tar.gz
> for metaio (peer certificate cannot be authenticated with known CA
> certificates)
>
> After consulting the guide I added:
>
> fetch.ignore_sslcert yes
>
> to the Portfile, yet the fetch still fails with the above. Isn't the
> fetch.ignore_sslcert statement supposed to supress this?
>
> Cheers
>
> Adam
>

From devans at macports.org  Fri Oct 31 11:14:17 2008
From: devans at macports.org (David Evans)
Date: Fri, 31 Oct 2008 11:14:17 -0700
Subject: Retry on checksum failures?
Message-ID: <490B4AF9.3060203@macports.org>

After updating gimp2 to 2.6.2 last night, an incidence was reported this
morning of checksum failure
during a fetch from one site out of many on the port's master_sites
list.  Fetches from other sites on
the list were successful and so it appears that this one site had a
bogus copy of the distribution on
its server.  Nonetheless, the attempt to fetch failed with no recourse
for the user other than to
remove the offending server from the Portfile.  Not something that the
casual user of MacPorts
should be expected to do.

I wonder if it would be a difficult thing to modify port to retry with
other sites on the list until
a successful fetch occurs or all listed sites are exhausted?  Isn't this
the behavior when a fetch
from one of the master_sites fails for other reasons? (timeout, file
doesn't exist, etc)?

Seems that this would make fetches more reliable to the end user without
compromising verification of the
validity of the distribution.

Dave

From blb at macports.org  Fri Oct 31 11:34:15 2008
From: blb at macports.org (Bryan Blackburn)
Date: Fri, 31 Oct 2008 12:34:15 -0600
Subject: Retry on checksum failures?
In-Reply-To: <490B4AF9.3060203@macports.org>
References: <490B4AF9.3060203@macports.org>
Message-ID: <20081031183415.GD454@ninagal.withay.com>

On Fri, Oct 31, 2008 at 11:14:17AM -0700, David Evans said:
> After updating gimp2 to 2.6.2 last night, an incidence was reported this
> morning of checksum failure
> during a fetch from one site out of many on the port's master_sites
> list.  Fetches from other sites on
> the list were successful and so it appears that this one site had a
> bogus copy of the distribution on
> its server.  Nonetheless, the attempt to fetch failed with no recourse
> for the user other than to
> remove the offending server from the Portfile.  Not something that the
> casual user of MacPorts
> should be expected to do.
> 
> I wonder if it would be a difficult thing to modify port to retry with
> other sites on the list until
> a successful fetch occurs or all listed sites are exhausted?  Isn't this
> the behavior when a fetch
> from one of the master_sites fails for other reasons? (timeout, file
> doesn't exist, etc)?
> 

In theory, trying other servers on a checksum mismatch makes sense, but
there are a few areas where this would be really annoying.  Take, for
example, the texlive_texmf-docs port whose distfile is 255M; for large files
like that, I'm not sure we'd possibly want to re-download it multiple times.

I can think of a couple ways to improve the fetching: adding a distsize key,
and making use of HTTP's HEAD.

With distsize, port can check to see if what it downloaded is close to
what's expected when checksums don't match, and if if it's a really small
file (eg, HTML error page and not the distfile) try elsewhere.  Of course,
this still doesn't really fix what happens on either a stealth upgrade or
corruption.

With using HEAD, port could test first for things like size, maybe even
checking Last-Modified to try and be smarter about what it may be
downloading.

In the end, of course, any possible solution will need someone to implement
it as well...

Perhaps there's another, simpler, solution I'm not thinking about?

Bryan


> Seems that this would make fetches more reliable to the end user without
> compromising verification of the
> validity of the distribution.
> 
> Dave

From devans at macports.org  Fri Oct 31 12:01:34 2008
From: devans at macports.org (David Evans)
Date: Fri, 31 Oct 2008 12:01:34 -0700
Subject: Retry on checksum failures?
In-Reply-To: <20081031183415.GD454@ninagal.withay.com>
References: <490B4AF9.3060203@macports.org>
	<20081031183415.GD454@ninagal.withay.com>
Message-ID: <490B560E.20204@macports.org>

Bryan Blackburn wrote:
>
> In theory, trying other servers on a checksum mismatch makes sense, but
> there are a few areas where this would be really annoying.  Take, for
> example, the texlive_texmf-docs port whose distfile is 255M; for large files
> like that, I'm not sure we'd possibly want to re-download it multiple times.
>
> I can think of a couple ways to improve the fetching: adding a distsize key,
> and making use of HTTP's HEAD.
>
> With distsize, port can check to see if what it downloaded is close to
> what's expected when checksums don't match, and if if it's a really small
> file (eg, HTML error page and not the distfile) try elsewhere.  Of course,
> this still doesn't really fix what happens on either a stealth upgrade or
> corruption.
>
> With using HEAD, port could test first for things like size, maybe even
> checking Last-Modified to try and be smarter about what it may be
> downloading.
>
> In the end, of course, any possible solution will need someone to implement
> it as well...
>
> Perhaps there's another, simpler, solution I'm not thinking about?
>
> Bryan
>
>
>   
That would certainly help and would probably be easier to implement as
the check would
occur while still in the fetch phase and would not necessitate back
tracking to the fetch phase
when an error occurs in the checksum phase.

On the other hand, in the current situation, if the checksum fails then
there's no getting around
the fact that the user will have to fetch again (probably later than
sooner when the
Portfile has been changed) if he really wants the port.  And in
addition, he has to suffer the
frustration of not being able to do anything other than file a bug
report and wait to see what
happens before he can manually retry.  So even with a large file, I
would vote for an immediate
retry with another site.

This assumes however that the case is as it was today.  One site with a
bogus file rather than
the maintainer just forgetting to update the checksums (didn't he test?).

In addition, it would be nice to have a maintainer tool a bit like
distcheck that would iterate
through a ports site list and download and checksum each site to check
for this sort of problem.

It's a real pain to do this manually for a large list.

By the way, a distcheck of gimp2 showed that the file on the offending
site was newer than the Portfile
so either it was slow in syncing to the master GIMP site or it was
changed later.

Dave

[1] http://trac.macports.org/ticket/17057  (missing reference from
previous email)



From ryandesign at macports.org  Fri Oct 31 17:59:41 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 31 Oct 2008 19:59:41 -0500
Subject: [41374] trunk/dports/lang
In-Reply-To: <20081101001021.E7B2F5FE3C0@beta.macosforge.org>
References: <20081101001021.E7B2F5FE3C0@beta.macosforge.org>
Message-ID: <D9EB78A2-2E5A-4177-9602-810B4FDDDBCA@macports.org>


On Oct 31, 2008, at 19:10, jann at macports.org wrote:

> Revision: 41374
>           http://trac.macports.org/changeset/41374
> Author:   jann at macports.org
> Date:     2008-10-31 17:10:21 -0700 (Fri, 31 Oct 2008)
> Log Message:
> -----------
> New version of eiffel launcher
>
> Modified Paths:
> --------------
>     trunk/dports/lang/eiffelstudio/Portfile
>     trunk/dports/lang/eiffelstudio-devel/Portfile
>
> Modified: trunk/dports/lang/eiffelstudio/Portfile
> ===================================================================
> --- trunk/dports/lang/eiffelstudio/Portfile	2008-10-31 23:40:11 UTC  
> (rev 41373)
> +++ trunk/dports/lang/eiffelstudio/Portfile	2008-11-01 00:10:21 UTC  
> (rev 41374)
> @@ -29,7 +29,7 @@
>  extract.post_args
>  extract.pre_args  -xf
>  distname          PorterPackage_${branch}_${minor_version}
> -set eiffel_launch eiffel_launcher_20080219.tar.bz2
> +set eiffel_launch eiffel_launcher_20081101.tar.bz2
>  distfiles         ${distname}${extract.suffix}:source \
>                    ${eiffel_launch}:launcher
>  extract.only      ${distname}${extract.suffix}
> @@ -38,9 +38,9 @@
>  checksums         ${distname}${extract.suffix} md5  
> 75aedf2ed6165bc811db7ff00ab46f0e \
>                    ${distname}${extract.suffix} sha1  
> e8479557ccd6024bf2bb1a24f7666e7f780e152a \
>                    ${distname}${extract.suffix} rmd160  
> fdfa5569be7ffe8318cff86487d69af8d05cf84b \
> -                  ${eiffel_launch} md5  
> eb6c705e53c15883def619f0ba8181dc \
> -                  ${eiffel_launch} sha1  
> a5b8b55a7d5bdb9d8126fbe6236725cab060f561 \
> -                  ${eiffel_launch} rmd160  
> c8c8c0cfd7637bc92c0dd36ffbb5dc8477147257
> +                  ${eiffel_launch} md5  
> 7e5236620aed3147782678a879574ff5 \
> +                  ${eiffel_launch} sha1  
> 1f081d618801e4ddbb95ab35895610d56f2e6c73 \
> +                  ${eiffel_launch} rmd160  
> 9a6ffe7f1bbc302b60b72197c84ad3a93d31cc0c

You should increase the port revision so everyone who already had the  
port installed gets advised to rebuild it.


From ryandesign at macports.org  Fri Oct 31 18:07:25 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 31 Oct 2008 20:07:25 -0500
Subject: [41362] trunk/dports/science/libframe/Portfile
In-Reply-To: <20081031162816.599505FB4BE@beta.macosforge.org>
References: <20081031162816.599505FB4BE@beta.macosforge.org>
Message-ID: <DA29C782-2E57-49D5-81E0-C20AFCE0C2D0@macports.org>

On Oct 31, 2008, at 11:28, ram at macports.org wrote:

> Revision: 41362
>           http://trac.macports.org/changeset/41362
> Author:   ram at macports.org
> Date:     2008-10-31 09:28:16 -0700 (Fri, 31 Oct 2008)
> Log Message:
> -----------
> science/libframe: fix checksums

Why were the checksums wrong? If the maintainer did a stealth update,  
you should change the dist_subdir so that anyone who had the previous  
version of the distfile doesn't now get a checksum error. For  
example, do this:

dist_subdir ${name}/${version}_1

If the previous distfile and the new distfile actually differ in the  
files they end up installing, then you should increase the port  
revision so everyone who had the port installed before gets advised  
to rebuild it. In that case, it's easiest to use the revision in the  
dist_subdir:

revision 1
dist_subdir ${name}/${version}_${revision}


> Modified Paths:
> --------------
>     trunk/dports/science/libframe/Portfile
>
> Modified: trunk/dports/science/libframe/Portfile
> ===================================================================
> --- trunk/dports/science/libframe/Portfile	2008-10-31 16:17:29 UTC  
> (rev 41361)
> +++ trunk/dports/science/libframe/Portfile	2008-10-31 16:28:16 UTC  
> (rev 41362)
> @@ -19,9 +19,9 @@
>  homepage      http://lappweb.in2p3.fr/virgo/FrameL/
>  master_sites  http://www.lsc-group.phys.uwm.edu/daswg/download/ 
> software/source/
>
> -checksums     md5 7fb80962ff8b99000d11b8dba0344591 \
> -              sha1 a0136f82ff8fc5f2fdbbd3dd1a51ab74b4243510 \
> -              rmd160 e8912f928a8e0f900a685188aef367cb9509e9ad
> +checksums     md5 309cd4988f09f0d4ac218f9183919a7c \
> +              sha1 4c997129c7703e18fdbc75ee200d580aea0f8b3e \
> +              rmd160 8d9a52c2baa1a3a966fb5c92620e04fa113c4070
>
>  depends_lib   port:zlib
>