On Mar 9, 2009, at 20:59, ma...@macports.org wrote:
Here's how I see the Guide at this time w.r.t. what kind of person
should read that section:
1. Introduction -- all users
2. Installing MacPorts -- all users
3. Using MacPorts -- all users
4. Portfile Development -- port maintainers
5. Portfil
On Tue, Mar 10, 2009 at 12:16:44AM -0500, Ryan Schmidt said:
>> Many of those tickets say "the guide should ..." and give not a lot of
>> helpful information. Not all. Ryan's doc tickets are particularly
>> helpful I should say. But as an example of ones that will linger:
>> http://trac.macports
Many of those tickets say "the guide should ..." and give not a lot of
helpful information. Not all. Ryan's doc tickets are particularly
helpful I should say. But as an example of ones that will linger:
http://trac.macports.org/ticket/15784 Since the creator didn't
give any
directly usable
On Mar 9, 2009, at 6:19 PM, Marcus Calhoun-Lopez wrote:
Eric Hall writes:
Given that MP installs (most) modules into vendor_perl,
I think the order should be:
site, vendor, then perl base/core.
I like the line(s) you have for showing the directory ordering
in the pa
On Mar 9, 2009, at 6:01 PM, Eric Hall wrote:
On Tue, Mar 10, 2009 at 12:27:39AM +, Marcus Calhoun-Lopez wrote:
Eric Hall writes:
On Mon, Mar 09, 2009 at 02:03:57PM -0700, Bradley Giesbrecht wrote:
I have played around with my perl5.8 port and I have what appears
to
me to be a soluti
On Mar 9, 2009, at 5:27 PM, Marcus Calhoun-Lopez wrote:
Eric Hall writes:
On Mon, Mar 09, 2009 at 02:03:57PM -0700, Bradley Giesbrecht wrote:
I have played around with my perl5.8 port and I have what appears to
me to be a solution to the path collision/registry issue.
I modified my perl5.
>> I think the distinction between types of users for documentation is
>> problematic.
>
>Problematic in what way? Do you mean you think it would be
>problematic to write the Guide to target different classes of users?
>Or do you mean you think users will currently find it problematic to
>identi
On Mar 9, 2009, at 3:55 PM, Eric Hall wrote:
On Mon, Mar 09, 2009 at 02:03:57PM -0700, Bradley Giesbrecht wrote:
I have played around with my perl5.8 port and I have what appears to
me to be a solution to the path collision/registry issue.
I modified my perl5.8 Portfile like so:
configure.ar
>> We don't want more people writing the Guide. It should stay as a
>> coherent document authored by one or a few individuals who have a
>> handle on the whole thing.
>
>I want more people writing the guide :-)
>At least I count some TODOs in the guide which are probably there for as
>long as I u
>> I think the distinction between types of users for documentation is
>> problematic. But chunking documents into "topics" and assembling them
>> into various docs as needed would at least allow it in theory. It is
>> called DITA. Another XML standard. I know, ugh. But I just don't see
>> how
Eric Hall writes:
> Given that MP installs (most) modules into vendor_perl,
> I think the order should be:
>
> site, vendor, then perl base/core.
>
> I like the line(s) you have for showing the directory ordering
> in the patch, I'll incorporate those.
>
> I have a diff
On Tue, Mar 10, 2009 at 12:27:39AM +, Marcus Calhoun-Lopez wrote:
> Eric Hall writes:
>
> >
> > On Mon, Mar 09, 2009 at 02:03:57PM -0700, Bradley Giesbrecht wrote:
> > > I have played around with my perl5.8 port and I have what appears to
> > > me to be a solution to the path collision/reg
Eric Hall writes:
>
> On Mon, Mar 09, 2009 at 02:03:57PM -0700, Bradley Giesbrecht wrote:
> > I have played around with my perl5.8 port and I have what appears to
> > me to be a solution to the path collision/registry issue.
> >
> > I modified my perl5.8 Portfile like so:
> >
> > configure.a
On Mon, Mar 09, 2009 at 02:03:57PM -0700, Bradley Giesbrecht wrote:
> I have played around with my perl5.8 port and I have what appears to
> me to be a solution to the path collision/registry issue.
>
> I modified my perl5.8 Portfile like so:
>
> configure.args-append -D man1dir='/opt/local/sha
Ryan Schmidt wrote:
> Trying to upgrade rpm51 running MacPorts 1.7 release branch r47786 I get
> this curious message; any ideas? I was able to upgrade other ports (that
> have no variants selected) successfully. Perhaps it has to do with the
> fact that this port has an autoselected platform varia
Trying to upgrade rpm51 running MacPorts 1.7 release branch r47786 I
get this curious message; any ideas? I was able to upgrade other
ports (that have no variants selected) successfully. Perhaps it has
to do with the fact that this port has an autoselected platform
variant (+macosx) but no
On Sun, Mar 08, 2009 at 02:41:50AM +, Marcus Calhoun-Lopez wrote:
> Bradley Giesbrecht writes:
>
> Thank you for the clarification.
>
> > > If I understand what is being discussed (please correct me if I'm
> > > wrong),
> > > we would
> > > * copy perl5.8 -> perl5.8-core.
> > > * creat
On Mon, Mar 9, 2009 at 9:36 PM, Daniel J. Luke wrote:
> But how about a future where things are somewhat different:
>
> - Portfiles are stored remotely
> - Portfiles can be submitted by anyone and submitting a portfile
> automatically causes a build farm to attempt to build a package (failures
> a
I have played around with my perl5.8 port and I have what appears to
me to be a solution to the path collision/registry issue.
I modified my perl5.8 Portfile like so:
configure.args-append -D man1dir='/opt/local/share/man/man1' -D
man1direxp='/opt/local/share/man/man1' -D man3dir='/opt/local
On 9 Mar 2009, at 20:38, Daniel J. Luke wrote:
On Mar 9, 2009, at 4:22 PM, Anil Madhavapeddy wrote:
Most of the ports involved are openmaintainers and the updates are
a bit interlinked due to ocaml being updated to 3.11.0.
In a case like this, I would open one ticket and CC all of the
mai
On Mar 9, 2009, at 4:22 PM, Anil Madhavapeddy wrote:
Most of the ports involved are openmaintainers and the updates are a
bit interlinked due to ocaml being updated to 3.11.0.
In a case like this, I would open one ticket and CC all of the
maintainers of the various ports (and discuss there
On Mar 9, 2009, at 12:44 PM, Ryan Schmidt wrote:
But I'm not sure what alternative to this method I can offer.
At least not currently...
But how about a future where things are somewhat different:
- Portfiles are stored remotely
- Portfiles can be submitted by anyone and submitting a portfile
Hi,
I have a macports repository up at: http://github.com/avsm/darwinports
... with a number of updates to ocaml-related ports (and also some new
ports). Most of the ports involved are openmaintainers and the
updates are a bit interlinked due to ocaml being updated to 3.11.0.
What would b
On Mar 9, 2009, at 12:32, Mark Hattam wrote:
On 9 Mar 2009, at 16:37, Ryan Schmidt wrote:
On Mar 8, 2009, at 13:58, Joshua Root wrote:
Adam Byrtek wrote:
On Sun, Mar 8, 2009 at 19:38, Rainer Müller
wrote:
So the port munin could be the node only, and munin +server
additionally
installs
On 9 Mar 2009, at 16:37, Ryan Schmidt wrote:
On Mar 8, 2009, at 13:58, Joshua Root wrote:
Adam Byrtek wrote:
On Sun, Mar 8, 2009 at 19:38, Rainer Müller
wrote:
So the port munin could be the node only, and munin +server
additionally
installs the server. This would be reasonable as the n
Ryan Schmidt wrote:
> On Mar 8, 2009, at 11:51, Martin Krischik wrote:
>> Ryan Schmidt schrieb:
>>> On Mar 8, 2009, at 07:18, Martin Krischik wrote:
I don't know - writing tickets with new ports attached did not
work all
that well.
>>> That is our process. What about it didn't work
On Mar 8, 2009, at 11:51, Martin Krischik wrote:
Ryan Schmidt schrieb:
On Mar 8, 2009, at 07:18, Martin Krischik wrote:
Ryan Schmidt schrieb:
If there are specific things missing from the guide, please file
tickets
requesting that documentation. Please file tickets for any
issues you
On Mar 8, 2009, at 13:00, Rainer Müller wrote:
Ryan Schmidt wrote:
Especially if the concern is the guide being outdated, I see the
problem
in the guide format. We had the recent discussion to move the
guide to
another markup language but it was teared down. What else can we
do to
attract
On Mar 8, 2009, at 13:58, Joshua Root wrote:
Adam Byrtek wrote:
On Sun, Mar 8, 2009 at 19:38, Rainer Müller
wrote:
So the port munin could be the node only, and munin +server
additionally
installs the server. This would be reasonable as the node gets
installed
more often than the server
Hi,
The MacPorts Project will apply again for the Google Summer of Code
(GSoC) program this year. I think most of you will already have heard of
it. Google pays students to work on various Open Source projects over
the summer. It is also a good start for students into Open Source
development.
See
On 2009-03-09 05:19:35 +, Marcus Calhoun-Lopez wrote:
> Vincent Lefevre writes:
>
> > On 2009-03-08 18:22:46 +0100, Rainer Müller wrote:
> > > Adam Byrtek wrote:
> > > > When playing with dependencies for a new port that requires certain
> > > > CPAN libraries I found out that there are multi
Rainer Müller wrote:
> b...@macports.org wrote:
>> Revision: 47871
>> http://trac.macports.org/changeset/47871
>> Author: b...@macports.org
>> Date: 2009-03-09 00:38:20 -0700 (Mon, 09 Mar 2009)
>> Log Message:
>> ---
>> macports1.0/macports.tcl - don't bother with .quick wor
b...@macports.org wrote:
> Revision: 47871
> http://trac.macports.org/changeset/47871
> Author: b...@macports.org
> Date: 2009-03-09 00:38:20 -0700 (Mon, 09 Mar 2009)
> Log Message:
> ---
> macports1.0/macports.tcl - don't bother with .quick work when the PortIndex
> isn't a
33 matches
Mail list logo
