From akitada at macports.org  Thu Jan  1 21:54:46 2009
From: akitada at macports.org (Akira Kitada)
Date: Fri, 2 Jan 2009 14:54:46 +0900
Subject: Restructuring Python ports?
In-Reply-To: <90bb445a0812312113x75d2cd6dn3c5dd69ba45e2f16@mail.gmail.com>
References: <90bb445a0812310214q522a068cp5f48f50dd99755c7@mail.gmail.com>
	<20090101013946.GD781@ninagal.withay.com>
	<90bb445a0812312113x75d2cd6dn3c5dd69ba45e2f16@mail.gmail.com>
Message-ID: <90bb445a0901012154g40a46bfer8504d86153876dcc@mail.gmail.com>

I had a good discussion on this with Bryan at #macports.

I proposed that we should change all python ports (python2[4-6] and
maybe python30) to be built
the way just as python ports in FreeBSD port system to make it a
little lightweight and bring consistency
to python ports of MacPorts, even if it will break existing ports.
Bryan declined this by saying "for 3.0 i'll definitely contact mww;
but for 2.4/2.5 i'm not sure of the breakage that will happen".

So it's going to remain the same: all-in-one python26 port and other
sliced python ports.
No intentional breakages are introduced.

On Thu, Jan 1, 2009 at 2:13 PM, Akira Kitada <akitada at macports.org> wrote:
> Hi Bryan,
>
>> Like python26 does now?  The advantage is of course that it works as some
>> who expect it to work like the system python, or the official one you
>> download from python.org.  The disadvantage is that it is heavier on
>> dependencies, adding the following to what python25 needs: zlib, openssl,
>> sqlite3, db46, gdbm, tcl, tk, and X11 (because of tk).
>
> And it might be convenient to be able to update each dependent port
> independently,
> but I'm not sure we would really want to update each of them that way.
>
> As always, we could probably learn some ideas from our senior project,
> FreeBSD Ports.
> Here is the patch-setup.py from FreeBSD's. [1]
>
>    # This global variable is used to hold the list of modules to be disabled.
>    -disabled_module_list = []
>    +disabled_module_list = ["_bsddb", "_sqlite3", "_tkinter", "gdbm", "mpz"]
>
> To me, it looks moderate and more pragmatic configuration than
> MacPorts's, where it disables:
>
>    # This global variable is used to hold the list of modules to be disabled.
>    -disabled_module_list = []
>    +disabled_module_list =
> ["zlib","_hashlib","_ssl","_bsddb","_sqlite3","_tkinter","bz2","gdbm","readline","_curses","_curses_panel"]
>
>
> (By the way, I must confess I didn't know python26 changed the way how
> it's built *again*.
> I worry it would bring some more confusions to python ports.)
>
> [1] http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python25/files/patch-setup.py
>
>> If we're not sure just yet which is preferred, do note that I haven't heard
>> anything personally that python26 brings in too many dependencies, nor have
>> any tickets been filed.  Of course 2.6 is still pretty new, and doesn't yet
>> have the module support the older versions do.
>
> I would like to go in the middle.
>
> Regards,
>
>> Bryan
>>
>>
>>>
>>> [1] MacPorts FAQ: Why can't I import foo in Python 2.5?
>>> http://trac.macports.org/wiki/FAQ#WhycantIimportfooinPython2.5
>>>
>>> [2] About FreeBSD Ports
>>> http://www.freebsd.org/ports/
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>>
>

From mcalhoun at macports.org  Thu Jan  1 23:48:29 2009
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Fri, 2 Jan 2009 07:48:29 +0000 (UTC)
Subject: Restructuring Python ports?
References: <90bb445a0812310214q522a068cp5f48f50dd99755c7@mail.gmail.com>
	<20090101013946.GD781@ninagal.withay.com>
	<90bb445a0812312113x75d2cd6dn3c5dd69ba45e2f16@mail.gmail.com>
	<90bb445a0901012154g40a46bfer8504d86153876dcc@mail.gmail.com>
Message-ID: <loom.20090102T073157-920@post.gmane.org>

Akira Kitada <akitada at ...> writes:

> So it's going to remain the same: all-in-one python26 port and other
> sliced python ports.
> No intentional breakages are introduced.

For what it's worth, I was a proponent of getting rid of
disabled_module_list in python26 (http://trac.macports.org/changeset/42841).
Most importantly, disabled_module_list precludes an exact replication of
a full install (http://trac.macports.org/ticket/12369).
It also makes maintenance easier.

Having python ports be "dependency heavy" does not strike me as
overly burdensome.
Python does a lot of useful things, and it seems right and good that
it require many dependencies to help it achieve its goals.

> Bryan declined this by saying "for 3.0 i'll definitely contact mww;
> but for 2.4/2.5 i'm not sure of the breakage that will happen".

A few days ago, I proposed getting rid of disabled_module_list in python30
(http://trac.macports.org/ticket/17796).

-Marcus


From akitada at macports.org  Fri Jan  2 02:17:36 2009
From: akitada at macports.org (Akira Kitada)
Date: Fri, 2 Jan 2009 19:17:36 +0900
Subject: Restructuring Python ports?
In-Reply-To: <loom.20090102T073157-920@post.gmane.org>
References: <90bb445a0812310214q522a068cp5f48f50dd99755c7@mail.gmail.com>
	<20090101013946.GD781@ninagal.withay.com>
	<90bb445a0812312113x75d2cd6dn3c5dd69ba45e2f16@mail.gmail.com>
	<90bb445a0901012154g40a46bfer8504d86153876dcc@mail.gmail.com>
	<loom.20090102T073157-920@post.gmane.org>
Message-ID: <90bb445a0901020217y410e0258m40f0b6a72c2ea03c@mail.gmail.com>

I prefer the way how python26 is built now to python25's, mostly
because it eliminated the need to specify
"depends_lib-append port:py25-hashlib port:py25-zlib" again and again...

I'm so happy with it and really hate the way it was in python25,
and that's why I wanted it to be propagated to other versions of python,
even it breaks the existing ports. (To me they are already broken in
different way)

I think it's safe to drop "bsddb", "sqlite3", "tkinter" and  "gdbm",
just as in FreeBSD Port system, though.

On Fri, Jan 2, 2009 at 4:48 PM, Marcus Calhoun-Lopez
<mcalhoun at macports.org> wrote:
> Akira Kitada <akitada at ...> writes:
>
>> So it's going to remain the same: all-in-one python26 port and other
>> sliced python ports.
>> No intentional breakages are introduced.
>
> For what it's worth, I was a proponent of getting rid of
> disabled_module_list in python26 (http://trac.macports.org/changeset/42841).
> Most importantly, disabled_module_list precludes an exact replication of
> a full install (http://trac.macports.org/ticket/12369).
> It also makes maintenance easier.
>
> Having python ports be "dependency heavy" does not strike me as
> overly burdensome.
> Python does a lot of useful things, and it seems right and good that
> it require many dependencies to help it achieve its goals.
>
>> Bryan declined this by saying "for 3.0 i'll definitely contact mww;
>> but for 2.4/2.5 i'm not sure of the breakage that will happen".
>
> A few days ago, I proposed getting rid of disabled_module_list in python30
> (http://trac.macports.org/ticket/17796).
>
> -Marcus
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>

From akitada at macports.org  Fri Jan  2 04:30:21 2009
From: akitada at macports.org (Akira Kitada)
Date: Fri, 2 Jan 2009 21:30:21 +0900
Subject: bin/foo or bin/foo-x.y?
Message-ID: <90bb445a0901020430u85d281dw4e65ef439a15334e@mail.gmail.com>

Hi,

How should I avoid conflict when there are two or more ports
installing the same file to the same path?
For Python ports, there seems to be a convension that a port that's
considered to be "default version" takes the name bin/foo,
and ones of other versions use bin/foo-x.y.

Is this still valid convension? If so, how can I know what version of
Python is "default"?

From randall.h.wood at alexandriasoftware.com  Fri Jan  2 08:48:09 2009
From: randall.h.wood at alexandriasoftware.com (Randall Wood)
Date: Fri, 2 Jan 2009 11:48:09 -0500
Subject: Restructuring Python ports?
In-Reply-To: <90bb445a0901020217y410e0258m40f0b6a72c2ea03c@mail.gmail.com>
References: <90bb445a0812310214q522a068cp5f48f50dd99755c7@mail.gmail.com>
	<20090101013946.GD781@ninagal.withay.com>
	<90bb445a0812312113x75d2cd6dn3c5dd69ba45e2f16@mail.gmail.com>
	<90bb445a0901012154g40a46bfer8504d86153876dcc@mail.gmail.com>
	<loom.20090102T073157-920@post.gmane.org>
	<90bb445a0901020217y410e0258m40f0b6a72c2ea03c@mail.gmail.com>
Message-ID: <335BEC8A-1E3F-48C4-8CB6-086DED5692D6@alexandriasoftware.com>

I would like to suggest the following:

That for each version of python (pythonxy), there be the following  
ports:

pythonxy, which installs nothing (maybe a readme file so that macports  
can consider it installed), but which depends on the following:

pythonxy-core, which is analogous to the current python24 and python25  
ports,

pyxy-whatever, which, when all pyxy-whatever ports are installed,  
provide a complete basic python installation of the core modules. (I'm  
not suggesting that every pyxy-* port be installed, only those which  
are required to provide the disabled modules)

We may also want to provide a pythonxy-x11 or pythonxy-core-gui port  
which would include the basic python tk/x11 gui capabilities so that  
pythonxy-core does not include an X11 dependency.

This may provide an advantage over throwing everything into a single  
port in that it would allow the pyxy-whatever ports to be updated  
independently of the pythonxy-core port if they need to be.

On 2 Jan 2009, at 05:17, Akira Kitada wrote:

> I prefer the way how python26 is built now to python25's, mostly
> because it eliminated the need to specify
> "depends_lib-append port:py25-hashlib port:py25-zlib" again and  
> again...
>
> I'm so happy with it and really hate the way it was in python25,
> and that's why I wanted it to be propagated to other versions of  
> python,
> even it breaks the existing ports. (To me they are already broken in
> different way)
>
> I think it's safe to drop "bsddb", "sqlite3", "tkinter" and  "gdbm",
> just as in FreeBSD Port system, though.
>
> On Fri, Jan 2, 2009 at 4:48 PM, Marcus Calhoun-Lopez
> <mcalhoun at macports.org> wrote:
>> Akira Kitada <akitada at ...> writes:
>>
>>> So it's going to remain the same: all-in-one python26 port and other
>>> sliced python ports.
>>> No intentional breakages are introduced.
>>
>> For what it's worth, I was a proponent of getting rid of
>> disabled_module_list in python26 (http://trac.macports.org/changeset/42841 
>> ).
>> Most importantly, disabled_module_list precludes an exact  
>> replication of
>> a full install (http://trac.macports.org/ticket/12369).
>> It also makes maintenance easier.
>>
>> Having python ports be "dependency heavy" does not strike me as
>> overly burdensome.
>> Python does a lot of useful things, and it seems right and good that
>> it require many dependencies to help it achieve its goals.
>>
>>> Bryan declined this by saying "for 3.0 i'll definitely contact mww;
>>> but for 2.4/2.5 i'm not sure of the breakage that will happen".
>>
>> A few days ago, I proposed getting rid of disabled_module_list in  
>> python30
>> (http://trac.macports.org/ticket/17796).
>>
>> -Marcus
>>
>> _______________________________________________
>> 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 ram at macports.org  Fri Jan  2 10:44:25 2009
From: ram at macports.org (Adam Mercer)
Date: Fri, 2 Jan 2009 18:44:25 +0000
Subject: [44730] trunk/dports/graphics/cairo/Portfile
In-Reply-To: <20090102181830.8A1F0B1EB80@beta.macosforge.org>
References: <20090102181830.8A1F0B1EB80@beta.macosforge.org>
Message-ID: <799406d60901021044p692152fdlf3cae5a744a8d37c@mail.gmail.com>

On Fri, Jan 2, 2009 at 18:18,  <jeremyhu at macports.org> wrote:
> Revision 44730 Author jeremyhu at macports.org Date 2009-01-02 10:18:30 -0800
> (Fri, 02 Jan 2009)
>
> Log Message
>
> cairo: Added missing dep on librsvg

What does this bring cario, as adding this brings in quite a few gnome packages?

Cheers

Adam

From kngspook at gmail.com  Fri Jan  2 11:58:41 2009
From: kngspook at gmail.com (Neil)
Date: Fri, 2 Jan 2009 11:58:41 -0800
Subject: Restructuring Python ports?
In-Reply-To: <335BEC8A-1E3F-48C4-8CB6-086DED5692D6@alexandriasoftware.com>
References: <90bb445a0812310214q522a068cp5f48f50dd99755c7@mail.gmail.com>
	<20090101013946.GD781@ninagal.withay.com>
	<90bb445a0812312113x75d2cd6dn3c5dd69ba45e2f16@mail.gmail.com>
	<90bb445a0901012154g40a46bfer8504d86153876dcc@mail.gmail.com>
	<loom.20090102T073157-920@post.gmane.org>
	<90bb445a0901020217y410e0258m40f0b6a72c2ea03c@mail.gmail.com>
	<335BEC8A-1E3F-48C4-8CB6-086DED5692D6@alexandriasoftware.com>
Message-ID: <77e4079b0901021158o4e3e5587h961b1b24c74787a3@mail.gmail.com>

On Fri, Jan 2, 2009 at 8:48 AM, Randall Wood
<randall.h.wood at alexandriasoftware.com> wrote:
> I would like to suggest the following:
>
> That for each version of python (pythonxy), there be the following ports:
>
> pythonxy, which installs nothing (maybe a readme file so that macports can
> consider it installed), but which depends on the following:
>
> pythonxy-core, which is analogous to the current python24 and python25
> ports,
>
> pyxy-whatever, which, when all pyxy-whatever ports are installed, provide a
> complete basic python installation of the core modules. (I'm not suggesting
> that every pyxy-* port be installed, only those which are required to
> provide the disabled modules)
>
> We may also want to provide a pythonxy-x11 or pythonxy-core-gui port which
> would include the basic python tk/x11 gui capabilities so that pythonxy-core
> does not include an X11 dependency.
>
> This may provide an advantage over throwing everything into a single port in
> that it would allow the pyxy-whatever ports to be updated independently of
> the pythonxy-core port if they need to be.
>
[snip]

Why not just take advantage of variants?

We could have python##, with three variants:
minimal: just the basic python stuff (ie. python-core)
normal: most, but not all, of the dependencies, as in FreeBSD
full: a full standard installation, with all deps

And then just make the normal variant the default.

From jeremyhu at macports.org  Fri Jan  2 12:08:39 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Fri, 2 Jan 2009 12:08:39 -0800
Subject: [44730] trunk/dports/graphics/cairo/Portfile
In-Reply-To: <799406d60901021044p692152fdlf3cae5a744a8d37c@mail.gmail.com>
References: <20090102181830.8A1F0B1EB80@beta.macosforge.org>
	<799406d60901021044p692152fdlf3cae5a744a8d37c@mail.gmail.com>
Message-ID: <5D5DACB3-7ABD-45FF-8F19-EB2F5542C631@macports.org>


On Jan 2, 2009, at 10:44, Adam Mercer wrote:

> On Fri, Jan 2, 2009 at 18:18,  <jeremyhu at macports.org> wrote:
>> Revision 44730 Author jeremyhu at macports.org Date 2009-01-02  
>> 10:18:30 -0800
>> (Fri, 02 Jan 2009)
>>
>> Log Message
>>
>> cairo: Added missing dep on librsvg
>
> What does this bring cario, as adding this brings in quite a few  
> gnome packages?
>
> Cheers
>
> Adam

I was getting an error running a gtk2 application that was trying to  
open an svg file.  I noticed cairo "fail" looking for librsvg, and  
installing it first fixed the problem.  When I looked into it deeper,  
I realized cairo only uses rsvg to test svg support and that the real  
place the dep needed to be was in gtk2.

--Jeremy



From jmpp at macports.org  Fri Jan  2 12:31:53 2009
From: jmpp at macports.org (Juan Manuel Palacios)
Date: Fri, 2 Jan 2009 16:01:53 -0430
Subject: [44730] trunk/dports/graphics/cairo/Portfile
In-Reply-To: <5D5DACB3-7ABD-45FF-8F19-EB2F5542C631@macports.org>
References: <20090102181830.8A1F0B1EB80@beta.macosforge.org>
	<799406d60901021044p692152fdlf3cae5a744a8d37c@mail.gmail.com>
	<5D5DACB3-7ABD-45FF-8F19-EB2F5542C631@macports.org>
Message-ID: <891D6CFD-EFBB-4F62-8124-C0E3D0F98032@macports.org>


On Jan 2, 2009, at 3:38 PM, Jeremy Huddleston wrote:

>
> On Jan 2, 2009, at 10:44, Adam Mercer wrote:
>
>> On Fri, Jan 2, 2009 at 18:18,  <jeremyhu at macports.org> wrote:
>>> Revision 44730 Author jeremyhu at macports.org Date 2009-01-02  
>>> 10:18:30 -0800
>>> (Fri, 02 Jan 2009)
>>>
>>> Log Message
>>>
>>> cairo: Added missing dep on librsvg
>>
>> What does this bring cario, as adding this brings in quite a few  
>> gnome packages?
>>
>> Cheers
>>
>> Adam
>
> I was getting an error running a gtk2 application that was trying to  
> open an svg file.  I noticed cairo "fail" looking for librsvg, and  
> installing it first fixed the problem.  When I looked into it  
> deeper, I realized cairo only uses rsvg to test svg support and that  
> the real place the dep needed to be was in gtk2.
>
> --Jeremy


	Maybe gtk2 could provide this functionality as a variant, "svg",  
since it does bring in quite a number of new dependencies to an  
already large tree.

	Just my 2 cents,...


-jmpp


From blb at macports.org  Fri Jan  2 13:16:41 2009
From: blb at macports.org (Bryan Blackburn)
Date: Fri, 2 Jan 2009 14:16:41 -0700
Subject: Restructuring Python ports?
In-Reply-To: <335BEC8A-1E3F-48C4-8CB6-086DED5692D6@alexandriasoftware.com>
References: <90bb445a0812310214q522a068cp5f48f50dd99755c7@mail.gmail.com>
	<20090101013946.GD781@ninagal.withay.com>
	<90bb445a0812312113x75d2cd6dn3c5dd69ba45e2f16@mail.gmail.com>
	<90bb445a0901012154g40a46bfer8504d86153876dcc@mail.gmail.com>
	<loom.20090102T073157-920@post.gmane.org>
	<90bb445a0901020217y410e0258m40f0b6a72c2ea03c@mail.gmail.com>
	<335BEC8A-1E3F-48C4-8CB6-086DED5692D6@alexandriasoftware.com>
Message-ID: <20090102211641.GC1008@ninagal.withay.com>

On Fri, Jan 02, 2009 at 11:48:09AM -0500, Randall Wood said:
> I would like to suggest the following:
>
> That for each version of python (pythonxy), there be the following ports:
>
> pythonxy, which installs nothing (maybe a readme file so that macports  
> can consider it installed), but which depends on the following:
>
> pythonxy-core, which is analogous to the current python24 and python25  
> ports,
>
> pyxy-whatever, which, when all pyxy-whatever ports are installed, provide 
> a complete basic python installation of the core modules. (I'm not 
> suggesting that every pyxy-* port be installed, only those which are 
> required to provide the disabled modules)
>
> We may also want to provide a pythonxy-x11 or pythonxy-core-gui port  
> which would include the basic python tk/x11 gui capabilities so that  
> pythonxy-core does not include an X11 dependency.
>
> This may provide an advantage over throwing everything into a single port 
> in that it would allow the pyxy-whatever ports to be updated  
> independently of the pythonxy-core port if they need to be.

Note that those modules which are split out from the python core are only
updated with python itself, so they'd only be updated when the base python
port is also updated.

Also, the way this works currently, it causes these split-out modules to be
installed in site-packages, not lib-dynload (which is where they are
installed when handled with the core python).  This then breaks running
python with the -S option:

   -S   Disable the import of the module site and the site-dependent
        manipulations of sys.path that it entails.

since site-packages is part of what is disabled, and lib-dynload is not.
Since there is a >0 number of people using this option [1],[2], unless we
have a good way of installing those modules (and only those, not all python
modules) into lib-dynload, python functions best with all modules built as
it expects.

Bryan

[1] - <http://trac.macports.org/ticket/12369#comment:18>
[2] - <http://trac.macports.org/ticket/14844>

[...]


From devans at macports.org  Fri Jan  2 13:17:44 2009
From: devans at macports.org (David Evans)
Date: Fri, 02 Jan 2009 13:17:44 -0800
Subject: [44730] trunk/dports/graphics/cairo/Portfile
In-Reply-To: <5D5DACB3-7ABD-45FF-8F19-EB2F5542C631@macports.org>
References: <20090102181830.8A1F0B1EB80@beta.macosforge.org>	<799406d60901021044p692152fdlf3cae5a744a8d37c@mail.gmail.com>
	<5D5DACB3-7ABD-45FF-8F19-EB2F5542C631@macports.org>
Message-ID: <495E8478.1090809@macports.org>

Jeremy Huddleston wrote:
>
> On Jan 2, 2009, at 10:44, Adam Mercer wrote:
>
>> On Fri, Jan 2, 2009 at 18:18,  <jeremyhu at macports.org> wrote:
>>> Revision 44730 Author jeremyhu at macports.org Date 2009-01-02 10:18:30
>>> -0800
>>> (Fri, 02 Jan 2009)
>>>
>>> Log Message
>>>
>>> cairo: Added missing dep on librsvg
>>
>> What does this bring cario, as adding this brings in quite a few
>> gnome packages?
>>
>> Cheers
>>
>> Adam
>
> I was getting an error running a gtk2 application that was trying to
> open an svg file.  I noticed cairo "fail" looking for librsvg, and
> installing it first fixed the problem.  When I looked into it deeper,
> I realized cairo only uses rsvg to test svg support and that the real
> place the dep needed to be was in gtk2.
>
> --Jeremy
I think you had it right the first time.  gtk has no direct dependencies
on librsvg but cairo supports an SVG
surface backend which requires it.  This is controlled during cairo
configure using

  --enable-svg=[no/auto/yes]
                          Enable cairo's SVG surface backend feature
                          [default=yes]

Since cairo's default is to include the SVG backend, then I think the
dependency on librsvg should be
included by default and a variant added to disable SVG surfaces
(removing the dependency) if this is not desired.

Currently, cairo will automatically enable SVG surfaces if librsvg
happens to be installed and disable it
otherwise, leading to unpredictable configurations and/or results.

From blb at macports.org  Fri Jan  2 13:18:48 2009
From: blb at macports.org (Bryan Blackburn)
Date: Fri, 2 Jan 2009 14:18:48 -0700
Subject: Restructuring Python ports?
In-Reply-To: <77e4079b0901021158o4e3e5587h961b1b24c74787a3@mail.gmail.com>
References: <90bb445a0812310214q522a068cp5f48f50dd99755c7@mail.gmail.com>
	<20090101013946.GD781@ninagal.withay.com>
	<90bb445a0812312113x75d2cd6dn3c5dd69ba45e2f16@mail.gmail.com>
	<90bb445a0901012154g40a46bfer8504d86153876dcc@mail.gmail.com>
	<loom.20090102T073157-920@post.gmane.org>
	<90bb445a0901020217y410e0258m40f0b6a72c2ea03c@mail.gmail.com>
	<335BEC8A-1E3F-48C4-8CB6-086DED5692D6@alexandriasoftware.com>
	<77e4079b0901021158o4e3e5587h961b1b24c74787a3@mail.gmail.com>
Message-ID: <20090102211848.GD1008@ninagal.withay.com>

On Fri, Jan 02, 2009 at 11:58:41AM -0800, Neil said:
[...]
> 
> Why not just take advantage of variants?
> 
> We could have python##, with three variants:
> minimal: just the basic python stuff (ie. python-core)
> normal: most, but not all, of the dependencies, as in FreeBSD
> full: a full standard installation, with all deps
> 
> And then just make the normal variant the default.

The problem with using variants is two-fold: one, you can't depend on
variants currently [1]; and two, if someone installs python without what
they need, they need to completely rebuild the port with the new variant,
instead of just adding the other bits later.

Bryan

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


From jeremyhu at macports.org  Fri Jan  2 14:27:00 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Fri, 2 Jan 2009 14:27:00 -0800
Subject: [44730] trunk/dports/graphics/cairo/Portfile
In-Reply-To: <495E8478.1090809@macports.org>
References: <20090102181830.8A1F0B1EB80@beta.macosforge.org>
	<799406d60901021044p692152fdlf3cae5a744a8d37c@mail.gmail.com>
	<5D5DACB3-7ABD-45FF-8F19-EB2F5542C631@macports.org>
	<495E8478.1090809@macports.org>
Message-ID: <DA3EDDAD-8D29-4CC6-BE3F-89C54D2E2345@macports.org>


On Jan 2, 2009, at 13:17, David Evans wrote:

> Jeremy Huddleston wrote:
>>
>> On Jan 2, 2009, at 10:44, Adam Mercer wrote:
>>
>>> On Fri, Jan 2, 2009 at 18:18,  <jeremyhu at macports.org> wrote:
>>>> Revision 44730 Author jeremyhu at macports.org Date 2009-01-02  
>>>> 10:18:30
>>>> -0800
>>>> (Fri, 02 Jan 2009)
>>>>
>>>> Log Message
>>>>
>>>> cairo: Added missing dep on librsvg
>>>
>>> What does this bring cario, as adding this brings in quite a few
>>> gnome packages?
>>>
>>> Cheers
>>>
>>> Adam
>>
>> I was getting an error running a gtk2 application that was trying to
>> open an svg file.  I noticed cairo "fail" looking for librsvg, and
>> installing it first fixed the problem.  When I looked into it deeper,
>> I realized cairo only uses rsvg to test svg support and that the real
>> place the dep needed to be was in gtk2.
>>
>> --Jeremy
> I think you had it right the first time.  gtk has no direct  
> dependencies
> on librsvg but cairo supports an SVG
> surface backend which requires it.  This is controlled during cairo
> configure using
>
>  --enable-svg=[no/auto/yes]
>                          Enable cairo's SVG surface backend feature
>                          [default=yes]
>
> Since cairo's default is to include the SVG backend, then I think the
> dependency on librsvg should be
> included by default and a variant added to disable SVG surfaces
> (removing the dependency) if this is not desired.
>
> Currently, cairo will automatically enable SVG surfaces if librsvg
> happens to be installed and disable it
> otherwise, leading to unpredictable configurations and/or results.

No, the only thing that uses LIBRSVG_CFLAGS in cairo is test/ 
Makefile.am.

After recompiling cairo with librsvg installed, the application still  
didn't work.  After uninstalling and installing gtk2, it did work.



From ryandesign at macports.org  Fri Jan  2 18:00:13 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 2 Jan 2009 20:00:13 -0600
Subject: Any Macintosh available via SSH?
In-Reply-To: <1230747991.15562.1.camel@debian>
References: <1230747991.15562.1.camel@debian>
Message-ID: <7FF51329-F699-43EF-B807-9D3547DA4590@macports.org>


On Dec 31, 2008, at 12:26, Jean-Michel Pour? wrote:

> As there is still no Kdenlive+MLT port, would someone be so kind to
> provide SSH access to a MacOsX station, so I can prepare packages
> myself.
>
> Kdenlive is a really interesting software for video enthousiasts using
> MacOsX and I don't understand why it is not already in MacPorts.

As for most software that is not in MacPorts, the reason is probably  
that nobody has made a Portfile for it yet.



From ryandesign at macports.org  Fri Jan  2 18:04:08 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 2 Jan 2009 20:04:08 -0600
Subject: bin/foo or bin/foo-x.y?
In-Reply-To: <90bb445a0901020430u85d281dw4e65ef439a15334e@mail.gmail.com>
References: <90bb445a0901020430u85d281dw4e65ef439a15334e@mail.gmail.com>
Message-ID: <510522EB-D526-4255-97B3-81F3E2FD468F@macports.org>

On Jan 2, 2009, at 06:30, Akira Kitada wrote:

> How should I avoid conflict when there are two or more ports
> installing the same file to the same path?
> For Python ports, there seems to be a convension that a port that's
> considered to be "default version" takes the name bin/foo,
> and ones of other versions use bin/foo-x.y.
>
> Is this still valid convension? If so, how can I know what version of
> Python is "default"?

For the specific case of python{24,25,26,30}, none of these installs $ 
{prefix}/bin/python. The python_select port does install this, as a  
symlink, pointing to whatever binary version of Python you instruct  
it to.

If your question is about software other than Python, what port(s)  
are they?



From jmr at macports.org  Fri Jan  2 18:56:57 2009
From: jmr at macports.org (Joshua Root)
Date: Sat, 03 Jan 2009 13:56:57 +1100
Subject: Restructuring Python ports?
In-Reply-To: <90bb445a0901020217y410e0258m40f0b6a72c2ea03c@mail.gmail.com>
References: <90bb445a0812310214q522a068cp5f48f50dd99755c7@mail.gmail.com>	<20090101013946.GD781@ninagal.withay.com>	<90bb445a0812312113x75d2cd6dn3c5dd69ba45e2f16@mail.gmail.com>	<90bb445a0901012154g40a46bfer8504d86153876dcc@mail.gmail.com>	<loom.20090102T073157-920@post.gmane.org>
	<90bb445a0901020217y410e0258m40f0b6a72c2ea03c@mail.gmail.com>
Message-ID: <495ED3F9.50701@macports.org>

Akira Kitada wrote:
> I prefer the way how python26 is built now to python25's, mostly
> because it eliminated the need to specify
> "depends_lib-append port:py25-hashlib port:py25-zlib" again and again...
> 
> I'm so happy with it and really hate the way it was in python25,
> and that's why I wanted it to be propagated to other versions of python,
> even it breaks the existing ports. (To me they are already broken in
> different way)
> 
> I think it's safe to drop "bsddb", "sqlite3", "tkinter" and  "gdbm",
> just as in FreeBSD Port system, though.

Note that IDLE doesn't work without tkinter...

- Josh

From akitada at macports.org  Fri Jan  2 19:58:37 2009
From: akitada at macports.org (Akira Kitada)
Date: Sat, 3 Jan 2009 12:58:37 +0900
Subject: bin/foo or bin/foo-x.y?
In-Reply-To: <510522EB-D526-4255-97B3-81F3E2FD468F@macports.org>
References: <90bb445a0901020430u85d281dw4e65ef439a15334e@mail.gmail.com>
	<510522EB-D526-4255-97B3-81F3E2FD468F@macports.org>
Message-ID: <90bb445a0901021958j2cdd21d6x596ceddf0a45e222@mail.gmail.com>

py*-setuptools, py*-ipython, py*-virtualenv, py*-django etc...

On Sat, Jan 3, 2009 at 11:04 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Jan 2, 2009, at 06:30, Akira Kitada wrote:
>
>> How should I avoid conflict when there are two or more ports
>> installing the same file to the same path?
>> For Python ports, there seems to be a convension that a port that's
>> considered to be "default version" takes the name bin/foo,
>> and ones of other versions use bin/foo-x.y.
>>
>> Is this still valid convension? If so, how can I know what version of
>> Python is "default"?
>
> For the specific case of python{24,25,26,30}, none of these installs
> ${prefix}/bin/python. The python_select port does install this, as a
> symlink, pointing to whatever binary version of Python you instruct it to.
>
> If your question is about software other than Python, what port(s) are they?
>
>
>

From akitada at macports.org  Fri Jan  2 20:29:37 2009
From: akitada at macports.org (Akira Kitada)
Date: Sat, 3 Jan 2009 13:29:37 +0900
Subject: Restructuring Python ports?
In-Reply-To: <495ED3F9.50701@macports.org>
References: <90bb445a0812310214q522a068cp5f48f50dd99755c7@mail.gmail.com>
	<20090101013946.GD781@ninagal.withay.com>
	<90bb445a0812312113x75d2cd6dn3c5dd69ba45e2f16@mail.gmail.com>
	<90bb445a0901012154g40a46bfer8504d86153876dcc@mail.gmail.com>
	<loom.20090102T073157-920@post.gmane.org>
	<90bb445a0901020217y410e0258m40f0b6a72c2ea03c@mail.gmail.com>
	<495ED3F9.50701@macports.org>
Message-ID: <90bb445a0901022029x2d43e3b1ib3cb28cb379a5040@mail.gmail.com>

You got me...

Then I think current python26 is the best we can.
would like to break the other pythons to be built in this way...

On Sat, Jan 3, 2009 at 11:56 AM, Joshua Root <jmr at macports.org> wrote:
> Akira Kitada wrote:
>> I prefer the way how python26 is built now to python25's, mostly
>> because it eliminated the need to specify
>> "depends_lib-append port:py25-hashlib port:py25-zlib" again and again...
>>
>> I'm so happy with it and really hate the way it was in python25,
>> and that's why I wanted it to be propagated to other versions of python,
>> even it breaks the existing ports. (To me they are already broken in
>> different way)
>>
>> I think it's safe to drop "bsddb", "sqlite3", "tkinter" and  "gdbm",
>> just as in FreeBSD Port system, though.
>
> Note that IDLE doesn't work without tkinter...
>
> - Josh
>

From raimue at macports.org  Sat Jan  3 01:06:36 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 03 Jan 2009 10:06:36 +0100
Subject: Improving trace mode
Message-ID: <495F2A9C.50102@macports.org>

Hello,

Trace mode (port -t) is a very good way to find out which files are
accessed and need to be available during building a port. But currently
this is not fully usable, as it has some problems with the way it
currently works.

When a file access outside of the sandbox (deps, Xcode, SDKs etc.) is
detected, it denies access to this file. But if you build some port and
it cannot access a file the build often either fails completely or is
unfinished.

In order to improve this, I would like to change the behavior of trace
mode. In my opinion it would be sufficient to report access to files
outside of the sandbox only and let the maintainer decide if these are
valid or not. Denying access in trace mode makes the build behave
differently as if it is run without trace mode.

Although I don't think the current behavior is really useful, we could
keep it and as an alternative add a new switch (port -T?) to implement
the behavior I am asking for.

Rainer

From jkh at apple.com  Sat Jan  3 01:34:22 2009
From: jkh at apple.com (Jordan K. Hubbard)
Date: Sat, 3 Jan 2009 01:34:22 -0800
Subject: Improving trace mode
In-Reply-To: <495F2A9C.50102@macports.org>
References: <495F2A9C.50102@macports.org>
Message-ID: <C314B29E-666A-402F-A01A-A497F57D52E3@apple.com>


On Jan 3, 2009, at 1:06 AM, Rainer M?ller wrote:

> When a file access outside of the sandbox (deps, Xcode, SDKs etc.) is
> detected, it denies access to this file. But if you build some port  
> and
> it cannot access a file the build often either fails completely or is
> unfinished.

 From what I recall from the conversations between Paul Guyot, Landon  
Fuller, and others behind trace mode, this is sort of the point.  A  
port is supposed to declare its dependencies, not write to areas  
outside of MacPorts' control, and otherwise behave itself.  If it's  
not behaving itself then one might argue that it *should* fail so that  
a bug report will be filed appropriately.  Unless I misunderstand your  
proposal completely, it sounds like you want to simply neuter trace  
mode so it's no longer, in effect, fulfilling its expected purpose.

- Jordan


From raimue at macports.org  Sat Jan  3 02:30:01 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 03 Jan 2009 11:30:01 +0100
Subject: Improving trace mode
In-Reply-To: <C314B29E-666A-402F-A01A-A497F57D52E3@apple.com>
References: <495F2A9C.50102@macports.org>
	<C314B29E-666A-402F-A01A-A497F57D52E3@apple.com>
Message-ID: <495F3E29.1090600@macports.org>

Jordan K. Hubbard wrote:
>  From what I recall from the conversations between Paul Guyot, Landon  
> Fuller, and others behind trace mode, this is sort of the point.  A  
> port is supposed to declare its dependencies, not write to areas  
> outside of MacPorts' control, and otherwise behave itself.  If it's  
> not behaving itself then one might argue that it *should* fail so that  
> a bug report will be filed appropriately.  Unless I misunderstand your  
> proposal completely, it sounds like you want to simply neuter trace  
> mode so it's no longer, in effect, fulfilling its expected purpose.

I understand that trace mode was meant to catch any access outside of
the scope of the dependencies, but at the moment it just does not work
in this way.

There are currently some binaries on which most ports do not declare
dependencies on, for example grep and awk.

For grep it is sufficient to add bin:grep:grep to depends_build. But for
awk, most configure scripts are satisfied by either gawk or awk, with
preference of gawk. There is currently no way to specify such a
dependency with alternatives. Specifying bin:awk:gawk is a workaround,
but actually it is wrong - gawk does not provide a binary named 'awk'.
Without trace mode, it would be using ${prefix}/bin/awk, but with trace
mode it falls back to /usr/bin/awk due to 'Permission denied' on the
first one. That is what I mean with "behave differently".

I have seen some configure scripts trying to access gmkdir, gnm, gstrip,
etc. (provided by coreutils/binutils), but they also just use the
non-gnu binaries in /usr/bin if g* is not available. Here we have the
same problem as for gawk.

There are a lot of these standard tools configure scripts may check for.
As a port author I just give up at that point, because adding them all
to every port is a lot of work, although only needed if the GNU tools
are installed through MacPorts (some ports even explicitely require GNU
tools).

When using trace mode, I always get messages:
  Warning: An activity was attempted outside sandbox:
/var/root/.CFUserTextEncoding
What is this?

Further problems are ccache and distcc. No port declares a dependency on
them as they are added by base. This is issue #12218 [1]. Probably this
could be fixed by adding a dependency if they are used, but no actual
patch is there yet.

And last, I would rather have trace mode report all issues at the end
than having to run it over and over again. If access to some file is
denied, the build usually fails and I have to edit the Portfile for that
dependency, run the command again, until it fails for the next file
again, edit the Portfile, ...

In my opinion it would be more useful if it would just print out a list
of files the build accessed outside the sandbox without interrupting the
build.

Rainer

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

From akitada at macports.org  Sat Jan  3 07:36:22 2009
From: akitada at macports.org (Akira Kitada)
Date: Sun, 4 Jan 2009 00:36:22 +0900
Subject: MacPorts Special Interest Group for Python
In-Reply-To: <90bb445a0901020753m13a774a4g7a01ecf53476c145@mail.gmail.com>
References: <90bb445a0901020753m13a774a4g7a01ecf53476c145@mail.gmail.com>
Message-ID: <90bb445a0901030736t374fead3wfa36178f836b41e1@mail.gmail.com>

CC'ing to macports-dev

On Sat, Jan 3, 2009 at 12:53 AM, Akira Kitada <akitada at macports.org> wrote:
> Hi Python maintainers,
>
> I would like to propose that MacPorts should have an "interest group"
> for Python.
> MacPorts has been adding many Python ports to its collection,
> but they are rather individual works and lacks the plan for the long term.
>
> The group will
> - Plan and mark specific version of Python as "default".
> - Provide Template Portfile for Python modules.
> - Share Python related problems and solutions.
> - Write Python ports specific documentations.
> - has a lead for Python ports, who makes decisions.
> - etc, etc.
>
>
> What do you think of this idea?
>
> Thanks,
>

From jeremyhu at macports.org  Sat Jan  3 10:28:48 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Sat, 3 Jan 2009 10:28:48 -0800
Subject: [PATCH] system_x11 variant
Message-ID: <0CA5251A-7E17-4ED3-B42C-AC297705ACA1@macports.org>

Last week, I mentioned the idea of a system_x11 variant which would  
allow users to continue using their ${x11prefix} X11SDK.  Below is a  
patch that I'd like to get reviewed.  I've tested it, and it works  
here on Leopard.  I suspect xorg-libXcomposite (and others that aren't  
installed on Tiger) probably need some additional pkgconfig-foo to  
find X11 (see the bottom of xinit/Portfile if you're curious what I  
mean).

This is essentially step 1 towards transitioning all ports to using  
dependencies like "port:xorg-libXext port:xorg-libXaw" instead of  
"lib:libX11:XFree86" or "lib:libXext.6:xorg-libXext lib:libXaw:xorg- 
libXaw"

This has the benefit of allowing us to develop against an identical  
X11 setup on all platforms while allowing expert users to set a  
variant if they really don't want to use our X11 libraries.   
Additionally, with this variant set, we are better off that our  
current situation because we won't install an X11 library into $ 
{prefix} after a macports binary was already linking against the one  
in ${x11prefix} (this is the main problem behind http://trac.macports.org/ticket/17558 
  ).

Step 2 will be converting the existing lib:...:xorg-libXXXX  
dependencies to port:xorg-libXXXX dependencies and lib:libX11:XFree86  
deps to port:xorg-libs (simple sedage).  This will require a revision  
bump on the affected Portfiles and should be done simultaneously!

Step 3 will be changing the port:xorg-libs dependencies to pull in  
only the ports needed rather than all the X11 libs.


Index: xorg-libXext/Portfile
===================================================================
--- xorg-libXext/Portfile	(revision 44790)
+++ xorg-libXext/Portfile	(working copy)
@@ -29,3 +29,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXext-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXext.dylib] && ! [string equal  
${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libs/Portfile
===================================================================
--- xorg-libs/Portfile	(revision 44790)
+++ xorg-libs/Portfile	(working copy)
@@ -65,3 +65,18 @@

  use_configure no
  universal_variant no
+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libs.dylib] && ! [string equal $ 
{prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXevie/Portfile
===================================================================
--- xorg-libXevie/Portfile	(revision 44790)
+++ xorg-libXevie/Portfile	(working copy)
@@ -28,3 +28,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXevie-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXevie.dylib] && ! [string  
equal ${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: mesa/Portfile
===================================================================
--- mesa/Portfile	(revision 44790)
+++ mesa/Portfile	(working copy)
@@ -50,3 +50,18 @@
  	}
  	build.args-append RC_ARCHS="${universal_archs}"
  }
+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libGLU.dylib] && ! [string equal $ 
{prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libpthread-stubs/Portfile
===================================================================
--- xorg-libpthread-stubs/Portfile	(revision 44790)
+++ xorg-libpthread-stubs/Portfile	(working copy)
@@ -21,3 +21,18 @@
  livecheck.check regex
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libpthread-stubs-(\\d+(?:\\.\\d+)*)
+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libpthread-stubs.dylib] && !  
[string equal ${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libxcb/Portfile
===================================================================
--- xorg-libxcb/Portfile	(revision 44790)
+++ xorg-libxcb/Portfile	(working copy)
@@ -37,3 +37,18 @@
  livecheck.check regex
  livecheck.url   ${master_sites}?C=M&O=D
  livecheck.regex libxcb-(\\d+(?:\\.\\d+)*)
+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libxcb.dylib] && ! [string equal $ 
{prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXdamage/Portfile
===================================================================
--- xorg-libXdamage/Portfile	(revision 44790)
+++ xorg-libXdamage/Portfile	(working copy)
@@ -30,3 +30,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXdamage-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXdamage.dylib] && ! [string  
equal ${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: Xft2/Portfile
===================================================================
--- Xft2/Portfile	(revision 44790)
+++ Xft2/Portfile	(working copy)
@@ -47,3 +47,18 @@
  livecheck.check     regex
  livecheck.url       ${master_sites}?C=M&O=D
  livecheck.regex     libXft-(\[0-9.\]+)\\.tar\\.bz2
+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXft.dylib] && ! [string equal $ 
{prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXxf86vm/Portfile
===================================================================
--- xorg-libXxf86vm/Portfile	(revision 44790)
+++ xorg-libXxf86vm/Portfile	(working copy)
@@ -30,3 +30,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXxf86vm-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXxf86vm.dylib] && ! [string  
equal ${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libice/Portfile
===================================================================
--- xorg-libice/Portfile	(revision 44790)
+++ xorg-libice/Portfile	(working copy)
@@ -28,3 +28,18 @@
  livecheck.check regex
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libICE-(\\d+(?:\\.\\d+)*)
+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libICE.dylib] && ! [string equal $ 
{prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libdmx/Portfile
===================================================================
--- xorg-libdmx/Portfile	(revision 44790)
+++ xorg-libdmx/Portfile	(working copy)
@@ -32,3 +32,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libdmx-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libdmx.dylib] && ! [string equal $ 
{prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXcomposite/Portfile
===================================================================
--- xorg-libXcomposite/Portfile	(revision 44790)
+++ xorg-libXcomposite/Portfile	(working copy)
@@ -31,3 +31,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXcomposite-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXcomposite.dylib] && ! [string  
equal ${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libAppleWM/Portfile
===================================================================
--- xorg-libAppleWM/Portfile	(revision 44790)
+++ xorg-libAppleWM/Portfile	(working copy)
@@ -40,3 +40,18 @@
  livecheck.check regex
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libAppleWM-(\\d+(?:\\.\\d+)*)
+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libAppleWM.dylib] && ! [string  
equal ${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXfixes/Portfile
===================================================================
--- xorg-libXfixes/Portfile	(revision 44790)
+++ xorg-libXfixes/Portfile	(working copy)
@@ -30,3 +30,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXfixes-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXfixes.dylib] && ! [string  
equal ${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXvMC/Portfile
===================================================================
--- xorg-libXvMC/Portfile	(revision 44790)
+++ xorg-libXvMC/Portfile	(working copy)
@@ -29,3 +29,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXvMC-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXvMC.dylib] && ! [string equal  
${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXdmcp/Portfile
===================================================================
--- xorg-libXdmcp/Portfile	(revision 44790)
+++ xorg-libXdmcp/Portfile	(working copy)
@@ -24,3 +24,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXdmcp-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXdmcp.dylib] && ! [string  
equal ${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXxf86dga/Portfile
===================================================================
--- xorg-libXxf86dga/Portfile	(revision 44790)
+++ xorg-libXxf86dga/Portfile	(working copy)
@@ -30,3 +30,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXxf86dga-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXxf86dga.dylib] && ! [string  
equal ${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXres/Portfile
===================================================================
--- xorg-libXres/Portfile	(revision 44790)
+++ xorg-libXres/Portfile	(working copy)
@@ -28,3 +28,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXres-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXres.dylib] && ! [string equal  
${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXfontcache/Portfile
===================================================================
--- xorg-libXfontcache/Portfile	(revision 44790)
+++ xorg-libXfontcache/Portfile	(working copy)
@@ -32,3 +32,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXfontcache-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXfontcache.dylib] && ! [string  
equal ${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libfontenc/Portfile
===================================================================
--- xorg-libfontenc/Portfile	(revision 44790)
+++ xorg-libfontenc/Portfile	(working copy)
@@ -27,3 +27,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libfontenc-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libfontenc.dylib] && ! [string  
equal ${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXScrnSaver/Portfile
===================================================================
--- xorg-libXScrnSaver/Portfile	(revision 44790)
+++ xorg-libXScrnSaver/Portfile	(working copy)
@@ -29,3 +29,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXScrnSaver-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXss.dylib] && ! [string equal $ 
{prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXrandr/Portfile
===================================================================
--- xorg-libXrandr/Portfile	(revision 44790)
+++ xorg-libXrandr/Portfile	(working copy)
@@ -33,3 +33,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXrandr-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXrandr.dylib] && ! [string  
equal ${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libxkbui/Portfile
===================================================================
--- xorg-libxkbui/Portfile	(revision 44790)
+++ xorg-libxkbui/Portfile	(working copy)
@@ -30,3 +30,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libxkbui-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libxkbui.dylib] && ! [string  
equal ${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXtst/Portfile
===================================================================
--- xorg-libXtst/Portfile	(revision 44790)
+++ xorg-libXtst/Portfile	(working copy)
@@ -31,3 +31,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXtst-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXtst.dylib] && ! [string equal  
${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xpm/Portfile
===================================================================
--- xpm/Portfile	(revision 44790)
+++ xpm/Portfile	(working copy)
@@ -27,3 +27,18 @@
  livecheck.check regex
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXpm-(\\d+(?:\\.\\d+)*)
+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXpm.dylib] && ! [string equal $ 
{prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXcursor/Portfile
===================================================================
--- xorg-libXcursor/Portfile	(revision 44790)
+++ xorg-libXcursor/Portfile	(working copy)
@@ -32,3 +32,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXcursor-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXcursor.dylib] && ! [string  
equal ${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libsm/Portfile
===================================================================
--- xorg-libsm/Portfile	(revision 44790)
+++ xorg-libsm/Portfile	(working copy)
@@ -35,3 +35,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libSM-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libSM.dylib] && ! [string equal $ 
{prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libxkbfile/Portfile
===================================================================
--- xorg-libxkbfile/Portfile	(revision 44790)
+++ xorg-libxkbfile/Portfile	(working copy)
@@ -30,3 +30,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libxkbfile-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libxkbfile.dylib] && ! [string  
equal ${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXfont/Portfile
===================================================================
--- xorg-libXfont/Portfile	(revision 44790)
+++ xorg-libXfont/Portfile	(working copy)
@@ -40,3 +40,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXfont-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXfont.dylib] && ! [string  
equal ${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libFS/Portfile
===================================================================
--- xorg-libFS/Portfile	(revision 44790)
+++ xorg-libFS/Portfile	(working copy)
@@ -27,3 +27,18 @@
  livecheck.check regex
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libFS-(\\d+(?:\\.\\d+)*)
+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libFS.dylib] && ! [string equal $ 
{prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXmu/Portfile
===================================================================
--- xorg-libXmu/Portfile	(revision 44790)
+++ xorg-libXmu/Portfile	(working copy)
@@ -32,3 +32,18 @@
  livecheck.regex libXmu-(\\d+(?:\\.\\d+)*)


+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXmu.dylib] && ! [string equal $ 
{prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libX11/Portfile
===================================================================
--- xorg-libX11/Portfile	(revision 44790)
+++ xorg-libX11/Portfile	(working copy)
@@ -41,3 +41,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libX11-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libX11.dylib] && ! [string equal $ 
{prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xrender/Portfile
===================================================================
--- xrender/Portfile	(revision 44790)
+++ xrender/Portfile	(working copy)
@@ -69,3 +69,18 @@
  livecheck.check regex
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex ${my_name}-(\\d+(?:\\.\\d+)*)
+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXrender.dylib] && ! [string  
equal ${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXTrap/Portfile
===================================================================
--- xorg-libXTrap/Portfile	(revision 44790)
+++ xorg-libXTrap/Portfile	(working copy)
@@ -23,3 +23,18 @@

  depends_lib         lib:libXext.6:xorg-libXext lib:libXt.6:xorg-libXt

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXTrap.dylib] && ! [string  
equal ${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-liboldX/Portfile
===================================================================
--- xorg-liboldX/Portfile	(revision 44790)
+++ xorg-liboldX/Portfile	(working copy)
@@ -27,3 +27,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex liboldX-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/liboldX.dylib] && ! [string equal  
${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXi/Portfile
===================================================================
--- xorg-libXi/Portfile	(revision 44790)
+++ xorg-libXi/Portfile	(working copy)
@@ -29,3 +29,18 @@
  livecheck.check regex
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXi-(\\d+(?:\\.\\d+)*)
+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXi.dylib] && ! [string equal $ 
{prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-liblbxutil/Portfile
===================================================================
--- xorg-liblbxutil/Portfile	(revision 44790)
+++ xorg-liblbxutil/Portfile	(working copy)
@@ -31,3 +31,18 @@
  livecheck.check regex
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex liblbxutil-(\\d+(?:\\.\\d+)*)
+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/liblbxutil.dylib] && ! [string  
equal ${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXp/Portfile
===================================================================
--- xorg-libXp/Portfile	(revision 44790)
+++ xorg-libXp/Portfile	(working copy)
@@ -30,3 +30,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXp-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXp.dylib] && ! [string equal $ 
{prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXt/Portfile
===================================================================
--- xorg-libXt/Portfile	(revision 44790)
+++ xorg-libXt/Portfile	(working copy)
@@ -33,3 +33,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXt-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXt.dylib] && ! [string equal $ 
{prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXv/Portfile
===================================================================
--- xorg-libXv/Portfile	(revision 44790)
+++ xorg-libXv/Portfile	(working copy)
@@ -29,3 +29,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXv-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXv.dylib] && ! [string equal $ 
{prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXau/Portfile
===================================================================
--- xorg-libXau/Portfile	(revision 44790)
+++ xorg-libXau/Portfile	(working copy)
@@ -26,3 +26,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXau-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXau.dylib] && ! [string equal $ 
{prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXxf86misc/Portfile
===================================================================
--- xorg-libXxf86misc/Portfile	(revision 44790)
+++ xorg-libXxf86misc/Portfile	(working copy)
@@ -33,3 +33,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXxf86misc-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXxf86misc.dylib] && ! [string  
equal ${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXaw/Portfile
===================================================================
--- xorg-libXaw/Portfile	(revision 44790)
+++ xorg-libXaw/Portfile	(working copy)
@@ -36,3 +36,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXaw-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXaw.dylib] && ! [string equal $ 
{prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}
Index: xorg-libXinerama/Portfile
===================================================================
--- xorg-libXinerama/Portfile	(revision 44790)
+++ xorg-libXinerama/Portfile	(working copy)
@@ -30,3 +30,18 @@
  livecheck.url   [lindex ${master_sites} 0]?C=M&O=D
  livecheck.regex libXinerama-(\\d+(?:\\.\\d+)*)

+
+variant system_x11 description {Install a stub package to use the  
system X11 libraries rather than Macports} {
+	if { [file exists ${x11prefix}/lib/libXinerama.dylib] && ! [string  
equal ${prefix} ${x11prefix}] } {
+		fetch           { }
+		checksum        { }
+		build           { }
+		destroot        {
+			xinstall -d ${destroot}${prefix}/share/doc/${name}
+			system "echo ${long_description} > ${destroot}${prefix}/share/doc/$ 
{name}/README.txt"
+		}
+		archive		{ }
+		activate	{ }
+		use_configure no
+	}
+}


From ram at macports.org  Sat Jan  3 10:31:07 2009
From: ram at macports.org (Adam Mercer)
Date: Sat, 3 Jan 2009 18:31:07 +0000
Subject: [44730] trunk/dports/graphics/cairo/Portfile
In-Reply-To: <DA3EDDAD-8D29-4CC6-BE3F-89C54D2E2345@macports.org>
References: <20090102181830.8A1F0B1EB80@beta.macosforge.org>
	<799406d60901021044p692152fdlf3cae5a744a8d37c@mail.gmail.com>
	<5D5DACB3-7ABD-45FF-8F19-EB2F5542C631@macports.org>
	<495E8478.1090809@macports.org>
	<DA3EDDAD-8D29-4CC6-BE3F-89C54D2E2345@macports.org>
Message-ID: <799406d60901031031l2a50b4eaobb766788b03b97d7@mail.gmail.com>

On Fri, Jan 2, 2009 at 22:27, Jeremy Huddleston <jeremyhu at macports.org> wrote:
\
> No, the only thing that uses LIBRSVG_CFLAGS in cairo is test/Makefile.am.
>
> After recompiling cairo with librsvg installed, the application still didn't
> work.  After uninstalling and installing gtk2, it did work.

Are you sure? As I can't find any mention of librsvg in the gtk2 sources:

[ram at cizin gtk+-2.14.5]$ grep -r librsvg *
[ram at cizin gtk+-2.14.5]$ grep -r LIBRSVG *
[ram at cizin gtk+-2.14.5]$

Cheers

Adam

From jeremyhu at macports.org  Sat Jan  3 10:43:12 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Sat, 3 Jan 2009 10:43:12 -0800
Subject: [44730] trunk/dports/graphics/cairo/Portfile
In-Reply-To: <799406d60901031031l2a50b4eaobb766788b03b97d7@mail.gmail.com>
References: <20090102181830.8A1F0B1EB80@beta.macosforge.org>
	<799406d60901021044p692152fdlf3cae5a744a8d37c@mail.gmail.com>
	<5D5DACB3-7ABD-45FF-8F19-EB2F5542C631@macports.org>
	<495E8478.1090809@macports.org>
	<DA3EDDAD-8D29-4CC6-BE3F-89C54D2E2345@macports.org>
	<799406d60901031031l2a50b4eaobb766788b03b97d7@mail.gmail.com>
Message-ID: <02DF22A0-E730-4523-81BD-961949B43D1C@macports.org>


On Jan 3, 2009, at 10:31, Adam Mercer wrote:

> On Fri, Jan 2, 2009 at 22:27, Jeremy Huddleston  
> <jeremyhu at macports.org> wrote:
> \
>> No, the only thing that uses LIBRSVG_CFLAGS in cairo is test/ 
>> Makefile.am.
>>
>> After recompiling cairo with librsvg installed, the application  
>> still didn't
>> work.  After uninstalling and installing gtk2, it did work.
>>
>
> Are you sure? As I can't find any mention of librsvg in the gtk2  
> sources:
>
> [ram at cizin gtk+-2.14.5]$ grep -r librsvg *
> [ram at cizin gtk+-2.14.5]$ grep -r LIBRSVG *
> [ram at cizin gtk+-2.14.5]$

Then WTH.  All I did to get it to work was uninstall gtk2 then  
reinstall gtk2.   The error I was getting was something like "gobject:  
Unrecognized image format" ... after reinstalling gtk2, it worked fine.

I'll back it out of gtk2 since it doesn't belong there, but we still  
need to figure out where it does belong =/

If anyone else is interested in the problem, I found it in deluge.  It  
fails to startup because it loads an svg icon with some py25-gtk foo.

--Jeremy

From blb at macports.org  Sat Jan  3 13:39:15 2009
From: blb at macports.org (Bryan Blackburn)
Date: Sat, 3 Jan 2009 14:39:15 -0700
Subject: [44843] trunk/dports/kde/amarok/Portfile
In-Reply-To: <20090103163347.9FA26B30488@beta.macosforge.org>
References: <20090103163347.9FA26B30488@beta.macosforge.org>
Message-ID: <20090103213915.GF755@ninagal.withay.com>

On Sat, Jan 03, 2009 at 08:33:47AM -0800, illogic-al at macports.org said:
> Revision: 44843
>           http://trac.macports.org/changeset/44843
[...]
> -maintainers         illogic-al at macports.org openmaintainer
> +maintainers         macports.org:illogic-al openmaintainer

FYI, for @macports.org you can remove the domain entirely, so just
'illogic-al' works; see 'port info amarok' and you'll see it does this for
openmaintainer/nomaintainer as well.

Bryan

[...]


From blb at macports.org  Sun Jan  4 01:17:13 2009
From: blb at macports.org (Bryan Blackburn)
Date: Sun, 4 Jan 2009 02:17:13 -0700
Subject: [PATCH] system_x11 variant
In-Reply-To: <0CA5251A-7E17-4ED3-B42C-AC297705ACA1@macports.org>
References: <0CA5251A-7E17-4ED3-B42C-AC297705ACA1@macports.org>
Message-ID: <20090104091713.GL755@ninagal.withay.com>

On Sat, Jan 03, 2009 at 10:28:48AM -0800, Jeremy Huddleston said:
> Last week, I mentioned the idea of a system_x11 variant which would allow 
> users to continue using their ${x11prefix} X11SDK.  Below is a patch that 
> I'd like to get reviewed.  I've tested it, and it works here on Leopard.  
> I suspect xorg-libXcomposite (and others that aren't installed on Tiger) 
> probably need some additional pkgconfig-foo to find X11 (see the bottom of 
> xinit/Portfile if you're curious what I mean).
>
> This is essentially step 1 towards transitioning all ports to using  
> dependencies like "port:xorg-libXext port:xorg-libXaw" instead of  
> "lib:libX11:XFree86" or "lib:libXext.6:xorg-libXext lib:libXaw:xorg- 
> libXaw"
>
> This has the benefit of allowing us to develop against an identical X11 
> setup on all platforms while allowing expert users to set a variant if 
> they really don't want to use our X11 libraries.  Additionally, with this 
> variant set, we are better off that our current situation because we won't 
> install an X11 library into ${prefix} after a macports binary was already 
> linking against the one in ${x11prefix} (this is the main problem behind 
> http://trac.macports.org/ticket/17558 ).

Two ports look odd: xorg-libs, which tests for libs.dylib (and being a
meta-port, probably not meant at all here?); and xorg-libpthread-stubs
which tests for libpthread-stubs.dylib that I don't see in Xquartz
(2.3.2.1).

Also, I'm curious about why you override the archive and activate phases in
these (as well as the X11 meta-ports xorg, xorg-apps, xorg-fonts, xorg-libs,
and xorg-proto).  Overriding activate causes them to be installed but then
remain inactive, and hence show in 'port installed inactive' as well as
possiblity causing confusion for those who use 'port uninstall inactive'.

Bryan

[...]

From jmr at macports.org  Sun Jan  4 04:24:13 2009
From: jmr at macports.org (Joshua Root)
Date: Sun, 04 Jan 2009 23:24:13 +1100
Subject: Improving trace mode
In-Reply-To: <495F3E29.1090600@macports.org>
References: <495F2A9C.50102@macports.org>	<C314B29E-666A-402F-A01A-A497F57D52E3@apple.com>
	<495F3E29.1090600@macports.org>
Message-ID: <4960AA6D.5050905@macports.org>

Rainer M?ller wrote:
> Jordan K. Hubbard wrote:
>>  From what I recall from the conversations between Paul Guyot, Landon  
>> Fuller, and others behind trace mode, this is sort of the point.  A  
>> port is supposed to declare its dependencies, not write to areas  
>> outside of MacPorts' control, and otherwise behave itself.  If it's  
>> not behaving itself then one might argue that it *should* fail so that  
>> a bug report will be filed appropriately.  Unless I misunderstand your  
>> proposal completely, it sounds like you want to simply neuter trace  
>> mode so it's no longer, in effect, fulfilling its expected purpose.
> 
> I understand that trace mode was meant to catch any access outside of
> the scope of the dependencies, but at the moment it just does not work
> in this way.
[...]
> I have seen some configure scripts trying to access gmkdir, gnm, gstrip,
> etc. (provided by coreutils/binutils), but they also just use the
> non-gnu binaries in /usr/bin if g* is not available. Here we have the
> same problem as for gawk.
> 
> There are a lot of these standard tools configure scripts may check for.
> As a port author I just give up at that point, because adding them all
> to every port is a lot of work, although only needed if the GNU tools
> are installed through MacPorts (some ports even explicitely require GNU
> tools).

It sounds to me like trace mode just needs a better whitelist, and also
a "greylist" which would warn on access but not prevent it.

- Josh

From ram at macports.org  Sun Jan  4 06:50:29 2009
From: ram at macports.org (Adam Mercer)
Date: Sun, 4 Jan 2009 14:50:29 +0000
Subject: [44889] trunk/dports/_resources/port1.0/group
In-Reply-To: <20090104143037.BB5BAB3DD6E@beta.macosforge.org>
References: <20090104143037.BB5BAB3DD6E@beta.macosforge.org>
Message-ID: <799406d60901040650l5043c8c4tc4da70036955b6db@mail.gmail.com>

On Sun, Jan 4, 2009 at 14:30,  <akitada at macports.org> wrote:
> Revision 44889 Author akitada at macports.org Date 2009-01-04 06:30:37 -0800
> (Sun, 04 Jan 2009)
>
> Log Message
>
> Introduced new variables: python.version and python.branch

What is python.version used for, and won't this require the portgroup
to be updated when the python port is bumped?

Cheers

Adam

From cssdev at mac.com  Sun Jan  4 08:29:18 2009
From: cssdev at mac.com (cssdev at mac.com)
Date: Sun, 04 Jan 2009 11:29:18 -0500
Subject: Fwd: [44897] vtk Lint Report
References: <20090104153259.D7FF528059@relay14.apple.com>
Message-ID: <57C87015-1A16-4905-A544-6EB03CAB62FA@mac.com>

Begin forwarded message:

> Subject: [44897] vtk Lint Report
>
> Portfile: vtk
>
>
> Error: Portfile directory vtk does not match port name VTK

So it looks like I should change the portname from VTK to vtk. What  
kind of havoc might that wreak? Will that completely break tracking  
for anyone that has the current port installed?

Chris

From toby at macports.org  Sun Jan  4 08:36:34 2009
From: toby at macports.org (Toby Peterson)
Date: Sun, 4 Jan 2009 08:36:34 -0800
Subject: [44897] vtk Lint Report
In-Reply-To: <57C87015-1A16-4905-A544-6EB03CAB62FA@mac.com>
References: <20090104153259.D7FF528059@relay14.apple.com>
	<57C87015-1A16-4905-A544-6EB03CAB62FA@mac.com>
Message-ID: <74c219d30901040836j2a7e3673tfc51e120594e7ddf@mail.gmail.com>

On Sun, Jan 4, 2009 at 8:29 AM,  <cssdev at mac.com> wrote:
> Begin forwarded message:
>
>> Subject: [44897] vtk Lint Report
>>
>> Portfile: vtk
>>
>>
>> Error: Portfile directory vtk does not match port name VTK
>
> So it looks like I should change the portname from VTK to vtk. What kind of
> havoc might that wreak? Will that completely break tracking for anyone that
> has the current port installed?

Why not just rename the directory?

- Toby

From akitada at macports.org  Sun Jan  4 08:45:40 2009
From: akitada at macports.org (Akira Kitada)
Date: Mon, 5 Jan 2009 01:45:40 +0900
Subject: [44889] trunk/dports/_resources/port1.0/group
In-Reply-To: <799406d60901040650l5043c8c4tc4da70036955b6db@mail.gmail.com>
References: <20090104143037.BB5BAB3DD6E@beta.macosforge.org>
	<799406d60901040650l5043c8c4tc4da70036955b6db@mail.gmail.com>
Message-ID: <90bb445a0901040845u52e71f80i47a0cb7125fa6ce2@mail.gmail.com>

Good catch.
It's been removed from each portgroup...

On Sun, Jan 4, 2009 at 11:50 PM, Adam Mercer <ram at macports.org> wrote:
> On Sun, Jan 4, 2009 at 14:30,  <akitada at macports.org> wrote:
>> Revision 44889 Author akitada at macports.org Date 2009-01-04 06:30:37 -0800
>> (Sun, 04 Jan 2009)
>>
>> Log Message
>>
>> Introduced new variables: python.version and python.branch
>
> What is python.version used for, and won't this require the portgroup
> to be updated when the python port is bumped?
>
> Cheers
>
> Adam
>

From illogical1 at gmail.com  Sun Jan  4 10:01:10 2009
From: illogical1 at gmail.com (Orville Bennett)
Date: Sun, 4 Jan 2009 13:01:10 -0500
Subject: [44843] trunk/dports/kde/amarok/Portfile
In-Reply-To: <20090103213915.GF755@ninagal.withay.com>
References: <20090103163347.9FA26B30488@beta.macosforge.org>
	<20090103213915.GF755@ninagal.withay.com>
Message-ID: <DDBAD2F1-CC26-4D21-AC92-B62EC8930DE7@gmail.com>


On Jan 3, 2009, at 4:39 PM, Bryan Blackburn wrote:

> On Sat, Jan 03, 2009 at 08:33:47AM -0800, illogic-al at macports.org  
> said:
>> Revision: 44843
>>         http://trac.macports.org/changeset/44843
> [...]
>> -maintainers         illogic-al at macports.org openmaintainer
>> +maintainers         macports.org:illogic-al openmaintainer
>
> FYI, for @macports.org you can remove the domain entirely, so just
> 'illogic-al' works; see 'port info amarok' and you'll see it does  
> this for
> openmaintainer/nomaintainer as well.
>
> Bryan
>
> [...]
Thanks for the info.
How do you reply to port commits? Just copy paste from the trac page?


From jeremyhu at macports.org  Sun Jan  4 12:25:56 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Sun, 4 Jan 2009 12:25:56 -0800
Subject: [PATCH] system_x11 variant
In-Reply-To: <20090104091713.GL755@ninagal.withay.com>
References: <0CA5251A-7E17-4ED3-B42C-AC297705ACA1@macports.org>
	<20090104091713.GL755@ninagal.withay.com>
Message-ID: <7ECA5E71-A3D3-4D7A-BEB8-AAC71407DAE5@macports.org>


On Jan 4, 2009, at 01:17, Bryan Blackburn wrote:

> On Sat, Jan 03, 2009 at 10:28:48AM -0800, Jeremy Huddleston said:
>> Last week, I mentioned the idea of a system_x11 variant which would  
>> allow
>> users to continue using their ${x11prefix} X11SDK.  Below is a  
>> patch that
>> I'd like to get reviewed.  I've tested it, and it works here on  
>> Leopard.
>> I suspect xorg-libXcomposite (and others that aren't installed on  
>> Tiger)
>> probably need some additional pkgconfig-foo to find X11 (see the  
>> bottom of
>> xinit/Portfile if you're curious what I mean).
>>
>> This is essentially step 1 towards transitioning all ports to using
>> dependencies like "port:xorg-libXext port:xorg-libXaw" instead of
>> "lib:libX11:XFree86" or "lib:libXext.6:xorg-libXext lib:libXaw:xorg-
>> libXaw"
>>
>> This has the benefit of allowing us to develop against an identical  
>> X11
>> setup on all platforms while allowing expert users to set a variant  
>> if
>> they really don't want to use our X11 libraries.  Additionally,  
>> with this
>> variant set, we are better off that our current situation because  
>> we won't
>> install an X11 library into ${prefix} after a macports binary was  
>> already
>> linking against the one in ${x11prefix} (this is the main problem  
>> behind
>> http://trac.macports.org/ticket/17558 ).
>
> Two ports look odd: xorg-libs, which tests for libs.dylib (and being a
> meta-port, probably not meant at all here?);

Yeah, I noticed that after I sent the email.  That meta port should  
have no such variant.  Additionally xorg-xcb-util should have the  
variant but wasn't in the patch I submitted.

> and xorg-libpthread-stubs
> which tests for libpthread-stubs.dylib that I don't see in Xquartz
> (2.3.2.1).

Oh yeah.  Ditto for that.  That port isn't really needed for much of  
anything.

> Also, I'm curious about why you override the archive and activate  
> phases in
> these (as well as the X11 meta-ports xorg, xorg-apps, xorg-fonts,  
> xorg-libs,
> and xorg-proto).

Honestly, I didn't make xorg-proto, and I just used what was in xorg- 
proto as the base for xorg, xorg-apps, xorg-fonts, xorg-libs...

> Overriding activate causes them to be installed but then
> remain inactive, and hence show in 'port installed inactive' as well  
> as
> possiblity causing confusion for those who use 'port uninstall  
> inactive'.

Ok, so if I nuke those overrides, we should be good then, right?


From ryandesign at macports.org  Sun Jan  4 12:33:47 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 4 Jan 2009 14:33:47 -0600
Subject: [44897] vtk Lint Report
In-Reply-To: <74c219d30901040836j2a7e3673tfc51e120594e7ddf@mail.gmail.com>
References: <20090104153259.D7FF528059@relay14.apple.com>
	<57C87015-1A16-4905-A544-6EB03CAB62FA@mac.com>
	<74c219d30901040836j2a7e3673tfc51e120594e7ddf@mail.gmail.com>
Message-ID: <1BED5666-B9EC-4A6F-8937-29BBBF7CD449@macports.org>

On Jan 4, 2009, at 10:36, Toby Peterson wrote:

> On Sun, Jan 4, 2009 at 8:29 AM, wrote:
>
>> Begin forwarded message:
>>
>>> Subject: [44897] vtk Lint Report
>>>
>>> Portfile: vtk
>>>
>>>
>>> Error: Portfile directory vtk does not match port name VTK
>>
>> So it looks like I should change the portname from VTK to vtk.  
>> What kind of
>> havoc might that wreak? Will that completely break tracking for  
>> anyone that
>> has the current port installed?
>
> Why not just rename the directory?

Changing the port name to match the directory name might cause  
problems because MacPorts does not expect this and does not have any  
means for you to tell it that a port has changed names, and port  
names are case-sensitive.

Changing the directory name to match the port name is probably the  
better option, but might not be entirely without its own problems as  
well; see:

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

Hopefully this would only affect the few users using a Subversion  
working copy of the ports tree, and not the majority who are using an  
rsync copy.


From akitada at macports.org  Sun Jan  4 12:45:07 2009
From: akitada at macports.org (Akira Kitada)
Date: Mon, 5 Jan 2009 05:45:07 +0900
Subject: mysql5, mysql5-devel
In-Reply-To: <90bb445a0901041243ne765a8fv3ea4e0e5582612ce@mail.gmail.com>
References: <90bb445a0901041243ne765a8fv3ea4e0e5582612ce@mail.gmail.com>
Message-ID: <90bb445a0901041245m6e82627fo6e2968b6ad570e14@mail.gmail.com>

I once heard that -devel suffix denotes the port is development release.
Now that MySQL 5.1 is GA release, maybe can we promote strip the -devel?
(in that case, we would lose 5.0... I'm not a big fan of -devel naming)

From jkh at apple.com  Sun Jan  4 12:52:30 2009
From: jkh at apple.com (Jordan K. Hubbard)
Date: Sun, 4 Jan 2009 12:52:30 -0800
Subject: Improving trace mode
In-Reply-To: <4960AA6D.5050905@macports.org>
References: <495F2A9C.50102@macports.org>
	<C314B29E-666A-402F-A01A-A497F57D52E3@apple.com>
	<495F3E29.1090600@macports.org> <4960AA6D.5050905@macports.org>
Message-ID: <014FCF63-9477-4FD1-8198-EDE088BA32D0@apple.com>


On Jan 4, 2009, at 4:24 AM, Joshua Root wrote:

> It sounds to me like trace mode just needs a better whitelist, and  
> also
> a "greylist" which would warn on access but not prevent it.

+1.  I agree, this is the best direction for making tracemode "more  
reasonable" while still making sure that ports are at least *aware*  
of, and willing to essentially document in a formalized way, their  
more unusual dependencies through some regexp'y set of whitelist/ 
greylist entries (I'm just designing off the top of my head now here,  
but it also seems like whether the action is "allow", "warn", or  
"other" should simply be some expression passed as an argument to the  
function which registers whitelist entries).

- Jordan


From ryandesign at macports.org  Sun Jan  4 13:02:31 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 4 Jan 2009 15:02:31 -0600
Subject: mysql5, mysql5-devel
In-Reply-To: <90bb445a0901041243ne765a8fv3ea4e0e5582612ce@mail.gmail.com>
References: <90bb445a0901041243ne765a8fv3ea4e0e5582612ce@mail.gmail.com>
Message-ID: <42764CF2-F8E2-41AB-B303-D5F0D16413C8@macports.org>


On Jan 4, 2009, at 14:43, Akira Kitada wrote:

> I once heard that -devel suffix denotes the port is development  
> release.

Correct. This is a convention that is employed by dozens of ports so  
far. It's not documented yet in the guide, but it should be; see:

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


> Now that MySQL 5.1 is GA release, maybe can we promote strip the - 
> devel?

You're right that 5.1 is now the generally-available version of  
MySQL, so it would follow that the mysql5 port should be updated to  
that version. The mysql5-devel port can stay around and be updated to  
MySQL 5.2 or 6.0 or whatever is next in the pipeline. I was holding  
off on updating the mysql5 port for a few reasons. First, there are a  
few things I want to change about the way the MySQL ports work, and I  
figured the major version bump would be a good time to introduce  
those, such as:

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

Second, the original developer of MySQL states that the 5.1 GA  
release (5.1.30) has many problems:

http://monty-says.blogspot.com/2008/11/oops-we-did-it-again-mysql-51- 
released.html

He says the new 5.1 features are buggy, but that the existing 5.0  
features are improved, so that still sounds like a reason for me to  
update the port. Still, I was hoping a bugfix version might appear  
soon that I could update the port to instead.


> (in that case, we would lose 5.0... I'm not a big fan of -devel  
> naming)

I'm sorry you're not a fan of the naming convention, but it has been  
in place for some time so I see no need to change it.


From blb at macports.org  Sun Jan  4 13:35:42 2009
From: blb at macports.org (Bryan Blackburn)
Date: Sun, 4 Jan 2009 14:35:42 -0700
Subject: [PATCH] system_x11 variant
In-Reply-To: <7ECA5E71-A3D3-4D7A-BEB8-AAC71407DAE5@macports.org>
References: <0CA5251A-7E17-4ED3-B42C-AC297705ACA1@macports.org>
	<20090104091713.GL755@ninagal.withay.com>
	<7ECA5E71-A3D3-4D7A-BEB8-AAC71407DAE5@macports.org>
Message-ID: <20090104213542.GB630@ninagal.withay.com>

On Sun, Jan 04, 2009 at 12:25:56PM -0800, Jeremy Huddleston said:
>
> On Jan 4, 2009, at 01:17, Bryan Blackburn wrote:
[...]
>
>> Also, I'm curious about why you override the archive and activate  
>> phases in
>> these (as well as the X11 meta-ports xorg, xorg-apps, xorg-fonts,  
>> xorg-libs,
>> and xorg-proto).
>
> Honestly, I didn't make xorg-proto, and I just used what was in xorg- 
> proto as the base for xorg, xorg-apps, xorg-fonts, xorg-libs...
>
>> Overriding activate causes them to be installed but then
>> remain inactive, and hence show in 'port installed inactive' as well as
>> possiblity causing confusion for those who use 'port uninstall  
>> inactive'.
>
> Ok, so if I nuke those overrides, we should be good then, right?

Right, which I see you've already done.  I'm not sure what the side-effects
would be from overriding archive like that (beyond it simply not making one
of course), but overriding active definitely creates confusion.

Bryan


From mark at dxradio.demon.co.uk  Sun Jan  4 17:55:14 2009
From: mark at dxradio.demon.co.uk (Mark Hattam)
Date: Mon, 5 Jan 2009 01:55:14 +0000
Subject: mysql5, mysql5-devel
In-Reply-To: <90bb445a0901041245m6e82627fo6e2968b6ad570e14@mail.gmail.com>
References: <90bb445a0901041243ne765a8fv3ea4e0e5582612ce@mail.gmail.com>
	<90bb445a0901041245m6e82627fo6e2968b6ad570e14@mail.gmail.com>
Message-ID: <DA89B571-9E50-47CB-9EBF-D3C3B498D75A@dxradio.demon.co.uk>


On 4 Jan 2009, at 20:45, Akira Kitada wrote:

> I once heard that -devel suffix denotes the port is development  
> release.
> Now that MySQL 5.1 is GA release, maybe can we promote strip the - 
> devel?
> (in that case, we would lose 5.0... I'm not a big fan of -devel  
> naming)


Hmmm ... 5.0 is still described as GA release too

http://dev.mysql.com/downloads/mysql/5.0.html


And I notice that the source distro is now 5.0.75 ... up from 5.0.67 !!


Mark


From ryandesign at macports.org  Sun Jan  4 19:45:31 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 4 Jan 2009 21:45:31 -0600
Subject: mysql5, mysql5-devel
In-Reply-To: <DA89B571-9E50-47CB-9EBF-D3C3B498D75A@dxradio.demon.co.uk>
References: <90bb445a0901041243ne765a8fv3ea4e0e5582612ce@mail.gmail.com>
	<90bb445a0901041245m6e82627fo6e2968b6ad570e14@mail.gmail.com>
	<DA89B571-9E50-47CB-9EBF-D3C3B498D75A@dxradio.demon.co.uk>
Message-ID: <626B5E55-11C1-4BF6-9AD2-EC4C0400BED1@macports.org>


On Jan 4, 2009, at 19:55, Mark Hattam wrote:

> And I notice that the source distro is now 5.0.75 ... up from  
> 5.0.67 !!

Thanks for telling me! I updated mysql5 to this version.

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



From ryandesign at macports.org  Sun Jan  4 19:46:12 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 4 Jan 2009 21:46:12 -0600
Subject: [44939] trunk/dports/lang/erlang/Portfile
In-Reply-To: <20090104232247.ED3FCB43CC9@beta.macosforge.org>
References: <20090104232247.ED3FCB43CC9@beta.macosforge.org>
Message-ID: <5CD93292-2928-46ED-8549-C9764724D5AA@macports.org>


On Jan 4, 2009, at 17:22, bfulgham at macports.org wrote:

> -variant hipe {
> +variant no-hipe {
>  	# Currently produces bus errors in 10.5.3 due to changes in
>  	# signal handling
> -	configure.args-append	--enable-hipe
> +	configure.args-delete   --enable-hipe
>  }

Ah, but hyphens are not legal for variant names:

$ port lint erlang
--->  Verifying Portfile for erlang
Warning: Variant smp does not have a description
Warning: Variant ssl does not have a description
Error: Variant name no-hipe is not valid; use [A-Za-z0-9_]+ only
--->  1 errors and 2 warnings found.
$

You should use an underscore instead. "no_hipe".


From ryandesign at macports.org  Sun Jan  4 23:26:04 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 5 Jan 2009 01:26:04 -0600
Subject: [44460] trunk/base/src/port1.0/portfetch.tcl
In-Reply-To: <20081229014829.09420AB8902@beta.macosforge.org>
References: <20081229014829.09420AB8902@beta.macosforge.org>
Message-ID: <DBB79FCF-FBC2-4ACD-83B1-61ADD8920325@macports.org>


On Dec 28, 2008, at 19:48, jmr at macports.org wrote:

> Revision: 44460
>           http://trac.macports.org/changeset/44460
> Author:   jmr at macports.org
> Date:     2008-12-28 17:48:28 -0800 (Sun, 28 Dec 2008)
> Log Message:
> -----------
> portfetch: use export rather than checkout as the default cvs and  
> svn fetch method, since checkouts aren't persistent anyway.



Was there really any advantage, other than disk space savings during  
build, of changing this?

I'd rather make svn checkouts persist; see:

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


From ryandesign at macports.org  Sun Jan  4 23:32:42 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 5 Jan 2009 01:32:42 -0600
Subject: [PATCH] system_x11 variant
In-Reply-To: <20090104213542.GB630@ninagal.withay.com>
References: <0CA5251A-7E17-4ED3-B42C-AC297705ACA1@macports.org>
	<20090104091713.GL755@ninagal.withay.com>
	<7ECA5E71-A3D3-4D7A-BEB8-AAC71407DAE5@macports.org>
	<20090104213542.GB630@ninagal.withay.com>
Message-ID: <234906CA-2962-4A22-A5F3-48166C2EE582@macports.org>


On Jan 4, 2009, at 15:35, Bryan Blackburn wrote:

>>> Overriding activate causes them to be installed but then
>>> remain inactive, and hence show in 'port installed inactive' as  
>>> well as
>>> possiblity causing confusion for those who use 'port uninstall
>>> inactive'.
>>
>> Ok, so if I nuke those overrides, we should be good then, right?
>
> Right, which I see you've already done.  I'm not sure what the side- 
> effects
> would be from overriding archive like that (beyond it simply not  
> making one
> of course), but overriding active definitely creates confusion.

Is there a way that MacPorts base could prevent ports from overriding  
the activate phase? Don't we already do that for commands like load  
and distfiles? At least that's what it seems to me the following  
output during an install means:

DEBUG: org.macports.load registered provides 'load', a pre-existing  
procedure. Target override will not be provided
DEBUG: org.macports.distfiles registered provides 'distfiles', a pre- 
existing procedure. Target override will not be provided



From jmr at macports.org  Sun Jan  4 23:43:56 2009
From: jmr at macports.org (Joshua Root)
Date: Mon, 05 Jan 2009 18:43:56 +1100
Subject: [44843] trunk/dports/kde/amarok/Portfile
In-Reply-To: <DDBAD2F1-CC26-4D21-AC92-B62EC8930DE7@gmail.com>
References: <20090103163347.9FA26B30488@beta.macosforge.org>	<20090103213915.GF755@ninagal.withay.com>
	<DDBAD2F1-CC26-4D21-AC92-B62EC8930DE7@gmail.com>
Message-ID: <4961BA3C.4000605@macports.org>

Orville Bennett wrote:
> How do you reply to port commits? Just copy paste from the trac page?

Commit messages get sent to the macports-changes mailing list[1].

- Josh

[1] <http://lists.macosforge.org/mailman/listinfo/macports-changes/>

From jmr at macports.org  Sun Jan  4 23:50:23 2009
From: jmr at macports.org (Joshua Root)
Date: Mon, 05 Jan 2009 18:50:23 +1100
Subject: [44460] trunk/base/src/port1.0/portfetch.tcl
In-Reply-To: <DBB79FCF-FBC2-4ACD-83B1-61ADD8920325@macports.org>
References: <20081229014829.09420AB8902@beta.macosforge.org>
	<DBB79FCF-FBC2-4ACD-83B1-61ADD8920325@macports.org>
Message-ID: <4961BBBF.4070901@macports.org>

Ryan Schmidt wrote:
> 
> On Dec 28, 2008, at 19:48, jmr at macports.org wrote:
> 
>> Revision: 44460
>>           http://trac.macports.org/changeset/44460
>> Author:   jmr at macports.org
>> Date:     2008-12-28 17:48:28 -0800 (Sun, 28 Dec 2008)
>> Log Message:
>> -----------
>> portfetch: use export rather than checkout as the default cvs and svn
>> fetch method, since checkouts aren't persistent anyway.
> 
> 
> 
> Was there really any advantage, other than disk space savings during
> build, of changing this?

Mainly it avoids inadvertent installation of CVS or .svn directories. It
also saves a little bandwidth.

> I'd rather make svn checkouts persist; see:
> 
> http://trac.macports.org/ticket/16373

Feel free, the process described in that ticket sounds great. :-)

- Josh

From jeremyhu at macports.org  Mon Jan  5 00:23:33 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Mon, 5 Jan 2009 00:23:33 -0800
Subject: svn post-commit hook
Message-ID: <EA4378CE-6E82-4606-9690-DD809FE19025@macports.org>

Transmitting file data .
Committed revision 44964.

Warning: post-commit hook failed (exit code 128) with output:
/svn/hooks/common: fork: Resource temporarily unavailable
/svn/hooks/common: fork: Resource temporarily unavailable
/svn/repositories/macports/hooks/post-commit: fork: Resource  
temporarily unavailable

Should I be worried?

From ryandesign at macports.org  Mon Jan  5 00:45:03 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 5 Jan 2009 02:45:03 -0600
Subject: [44460] trunk/base/src/port1.0/portfetch.tcl
In-Reply-To: <4961BBBF.4070901@macports.org>
References: <20081229014829.09420AB8902@beta.macosforge.org>
	<DBB79FCF-FBC2-4ACD-83B1-61ADD8920325@macports.org>
	<4961BBBF.4070901@macports.org>
Message-ID: <6018BACE-34A7-48CA-AF35-0F14101DB75E@macports.org>


On Jan 5, 2009, at 01:50, Joshua Root wrote:

> Ryan Schmidt wrote:
>
>> On Dec 28, 2008, at 19:48, jmr at macports.org wrote:
>>
>>> Revision: 44460
>>>           http://trac.macports.org/changeset/44460
>>> Author:   jmr at macports.org
>>> Date:     2008-12-28 17:48:28 -0800 (Sun, 28 Dec 2008)
>>> Log Message:
>>> -----------
>>> portfetch: use export rather than checkout as the default cvs and  
>>> svn
>>> fetch method, since checkouts aren't persistent anyway.
>>
>> Was there really any advantage, other than disk space savings during
>> build, of changing this?
>
> Mainly it avoids inadvertent installation of CVS or .svn directories.

That's a good point.

> It also saves a little bandwidth.

Hmm. I thought Subversion pulled the same information over the wire,  
regardless of whether it's an export or a checkout, and that where  
they differ is just in where that information then gets written to disk.


>> I'd rather make svn checkouts persist; see:
>>
>> http://trac.macports.org/ticket/16373
>
> Feel free, the process described in that ticket sounds great. :-)

I might, one day. :) Until then exports instead of checkouts are  
probably a good idea.



From jmr at macports.org  Mon Jan  5 00:57:27 2009
From: jmr at macports.org (Joshua Root)
Date: Mon, 05 Jan 2009 19:57:27 +1100
Subject: [44460] trunk/base/src/port1.0/portfetch.tcl
In-Reply-To: <6018BACE-34A7-48CA-AF35-0F14101DB75E@macports.org>
References: <20081229014829.09420AB8902@beta.macosforge.org>
	<DBB79FCF-FBC2-4ACD-83B1-61ADD8920325@macports.org>
	<4961BBBF.4070901@macports.org>
	<6018BACE-34A7-48CA-AF35-0F14101DB75E@macports.org>
Message-ID: <4961CB77.7010305@macports.org>

Ryan Schmidt wrote:
> 
> On Jan 5, 2009, at 01:50, Joshua Root wrote:
> 
>> Ryan Schmidt wrote:
>>
>>> On Dec 28, 2008, at 19:48, jmr at macports.org wrote:
>>>
>>>> Revision: 44460
>>>>           http://trac.macports.org/changeset/44460
>>>> Author:   jmr at macports.org
>>>> Date:     2008-12-28 17:48:28 -0800 (Sun, 28 Dec 2008)
>>>> Log Message:
>>>> -----------
>>>> portfetch: use export rather than checkout as the default cvs and svn
>>>> fetch method, since checkouts aren't persistent anyway.
>>>
>>> Was there really any advantage, other than disk space savings during
>>> build, of changing this?
>>
>> Mainly it avoids inadvertent installation of CVS or .svn directories.
> 
> That's a good point.
> 
>> It also saves a little bandwidth.
> 
> Hmm. I thought Subversion pulled the same information over the wire,
> regardless of whether it's an export or a checkout, and that where they
> differ is just in where that information then gets written to disk.

I admit I haven't actually measured how much each downloads, but export
definitely takes less time than checkout.

- Josh

From blb at macports.org  Mon Jan  5 01:02:08 2009
From: blb at macports.org (Bryan Blackburn)
Date: Mon, 5 Jan 2009 02:02:08 -0700
Subject: [44460] trunk/base/src/port1.0/portfetch.tcl
In-Reply-To: <6018BACE-34A7-48CA-AF35-0F14101DB75E@macports.org>
References: <20081229014829.09420AB8902@beta.macosforge.org>
	<DBB79FCF-FBC2-4ACD-83B1-61ADD8920325@macports.org>
	<4961BBBF.4070901@macports.org>
	<6018BACE-34A7-48CA-AF35-0F14101DB75E@macports.org>
Message-ID: <20090105090208.GE630@ninagal.withay.com>

On Mon, Jan 05, 2009 at 02:45:03AM -0600, Ryan Schmidt said:
> On Jan 5, 2009, at 01:50, Joshua Root wrote:
[...]
>>
>> Feel free, the process described in that ticket sounds great. :-)
>
> I might, one day. :) Until then exports instead of checkouts are probably 
> a good idea.

And when you must have a checkout:

<http://trac.macports.org/changeset/44952>

Bryan


From blair at orcaware.com  Mon Jan  5 08:22:47 2009
From: blair at orcaware.com (Blair Zajac)
Date: Mon, 5 Jan 2009 08:22:47 -0800
Subject: [44460] trunk/base/src/port1.0/portfetch.tcl
In-Reply-To: <6018BACE-34A7-48CA-AF35-0F14101DB75E@macports.org>
References: <20081229014829.09420AB8902@beta.macosforge.org>
	<DBB79FCF-FBC2-4ACD-83B1-61ADD8920325@macports.org>
	<4961BBBF.4070901@macports.org>
	<6018BACE-34A7-48CA-AF35-0F14101DB75E@macports.org>
Message-ID: <29C869D1-AC9B-4BAB-94C1-3B2A0C9C52B9@orcaware.com>


On Jan 5, 2009, at 12:45 AM, Ryan Schmidt wrote:

>
> On Jan 5, 2009, at 01:50, Joshua Root wrote:
>
>> Ryan Schmidt wrote:
>>
>>> On Dec 28, 2008, at 19:48, jmr at macports.org wrote:
>>>
>>>> Revision: 44460
>>>>          http://trac.macports.org/changeset/44460
>>>> Author:   jmr at macports.org
>>>> Date:     2008-12-28 17:48:28 -0800 (Sun, 28 Dec 2008)
>>>> Log Message:
>>>> -----------
>>>> portfetch: use export rather than checkout as the default cvs and  
>>>> svn
>>>> fetch method, since checkouts aren't persistent anyway.
>>>
>>> Was there really any advantage, other than disk space savings during
>>> build, of changing this?
>>
>> Mainly it avoids inadvertent installation of CVS or .svn directories.
>
> That's a good point.
>
>> It also saves a little bandwidth.
>
> Hmm. I thought Subversion pulled the same information over the wire,  
> regardless of whether it's an export or a checkout, and that where  
> they differ is just in where that information then gets written to  
> disk.

It doesn't save bandwidth but will save disk IO.

Blair

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



From wsiegrist at apple.com  Mon Jan  5 09:21:44 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Mon, 05 Jan 2009 09:21:44 -0800
Subject: svn post-commit hook
In-Reply-To: <EA4378CE-6E82-4606-9690-DD809FE19025@macports.org>
References: <EA4378CE-6E82-4606-9690-DD809FE19025@macports.org>
Message-ID: <A5A68F5A-068B-478F-B550-A01C94907F6C@apple.com>

On Jan 5, 2009, at 12:23 AM, Jeremy Huddleston wrote:

> Transmitting file data .
> Committed revision 44964.
>
> Warning: post-commit hook failed (exit code 128) with output:
> /svn/hooks/common: fork: Resource temporarily unavailable
> /svn/hooks/common: fork: Resource temporarily unavailable
> /svn/repositories/macports/hooks/post-commit: fork: Resource  
> temporarily unavailable
>
> Should I be worried?
>

The server has been fixed. I dont think the failed post-commit is a  
problem looking at your changes.

-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/20090105/79800662/attachment.bin>

From devans at macports.org  Mon Jan  5 09:37:42 2009
From: devans at macports.org (David Evans)
Date: Mon, 05 Jan 2009 09:37:42 -0800
Subject: [MacPorts] #17884: gimp2 2.6.4 build fails
In-Reply-To: <056.f34fae4b44a666a27b638a4664007b24@macports.org>
References: <056.f34fae4b44a666a27b638a4664007b24@macports.org>
Message-ID: <49624566.9060009@macports.org>

MacPorts wrote:
> #17884: gimp2 2.6.4 build fails
> -------------------------------------+--------------------------------------
>  Reporter:  calle.kabo@?             |       Owner:  macports-tickets@?                   
>      Type:  defect                   |      Status:  new                                  
>  Priority:  Normal                   |   Milestone:  Port Bugs                            
> Component:  ports                    |     Version:  1.7.0                                
>  Keywords:  gimp2 2.6.4 XML::Parser  |        Port:  gimp2                                
> -------------------------------------+--------------------------------------
>  I got an error when upgrading to gimp2 2.6.4.
>  {{{
>  checking for XML::Parser... configure: error: XML::Parser perl module is
>  required for intltool
>  }}}
>   
Replying by email as trac doesn't seem to be working this morning.

I tried rebuilding gimp2 this morning but was unable to reproduce this
problem.
>  So I did:
>  {{{
>  $ sudo cpan
>  cpan> install XML::Parser
>  }}}
>   
This is unnecessary (and perhaps not desireable) as XML::Parser is
provided by port
p5-xml-parser which is declared as a dependency by the gimp2 port.

If fact, the output you submitted says that this port is installed:

 DEBUG: Found port in
 file:///opt/local/var/macports/sources/rsync.macports.org/release/ports/perl/p5
 -xml-parser
 DEBUG: epoch: in tree: 0 installed: 0
 DEBUG: p5-xml-parser 2.36_0 exists in the ports tree
 DEBUG: p5-xml-parser 2.36_0 is installed
 DEBUG: No need to upgrade! p5-xml-parser 2.36_0 >= p5-xml-parser 2.36_0

So there is potentially some problem with your perl configuration or the
installation of p5-xml-parser

Try the following command (this is the test configure uses)

$ /opt/local/bin/perl -e "require XML::Parser"

This should complete silently without any error but is apparently not
doing so in configure's
context at least.  Any error output from this may point you in the
proper direction.

Of course

$ which perl

should return

/opt/local/bin/perl

Again, from your output, configure seems to have properly detected this.

If nothing else works you might try

$ sudo port -fn upgrade p5-xml-parser

to force p5-xml-parser to reinstall in case its installation is damaged
in some way.

I thought originally that this might be a result of the recent upgrade
of perl from 5.8.8 to
5.8.9 (which it looks like you have completed) but that doesn't seem to
be an issue on
my system (10.4.11 ppc) at least.

Sorry I can't be of more help right now but please reply with any
further information you
may develop.




From toby at macports.org  Mon Jan  5 12:51:00 2009
From: toby at macports.org (Toby Peterson)
Date: Mon, 5 Jan 2009 12:51:00 -0800
Subject: [PATCH] system_x11 variant
In-Reply-To: <234906CA-2962-4A22-A5F3-48166C2EE582@macports.org>
References: <0CA5251A-7E17-4ED3-B42C-AC297705ACA1@macports.org>
	<20090104091713.GL755@ninagal.withay.com>
	<7ECA5E71-A3D3-4D7A-BEB8-AAC71407DAE5@macports.org>
	<20090104213542.GB630@ninagal.withay.com>
	<234906CA-2962-4A22-A5F3-48166C2EE582@macports.org>
Message-ID: <74c219d30901051251l5cf425f1q15873f450394683c@mail.gmail.com>

On Sun, Jan 4, 2009 at 11:32 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On Jan 4, 2009, at 15:35, Bryan Blackburn wrote:
>
>>>> Overriding activate causes them to be installed but then
>>>> remain inactive, and hence show in 'port installed inactive' as well as
>>>> possiblity causing confusion for those who use 'port uninstall
>>>> inactive'.
>>>
>>> Ok, so if I nuke those overrides, we should be good then, right?
>>
>> Right, which I see you've already done.  I'm not sure what the
>> side-effects
>> would be from overriding archive like that (beyond it simply not making
>> one
>> of course), but overriding active definitely creates confusion.
>
> Is there a way that MacPorts base could prevent ports from overriding the
> activate phase? Don't we already do that for commands like load and
> distfiles? At least that's what it seems to me the following output during
> an install means:
>
> DEBUG: org.macports.load registered provides 'load', a pre-existing
> procedure. Target override will not be provided
> DEBUG: org.macports.distfiles registered provides 'distfiles', a
> pre-existing procedure. Target override will not be provided

No, in this case the messages mean what they say. Target overrides are
provided by procedures, as are options. Since there's already an
option named "distfiles" (and a tcl builtin proc named "load"), the
target overrides cannot be provided.

Anyway, it should be pretty easy to add some kind of option to
target_provides to have that target not allow any overrides.

- Toby

From raimue at macports.org  Mon Jan  5 13:19:03 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Mon, 05 Jan 2009 22:19:03 +0100
Subject: ticket 17595 for Tomcat: when will this be fixed
In-Reply-To: <49624DBC.6080600@lbl.gov>
References: <49624DBC.6080600@lbl.gov>
Message-ID: <49627947.2070304@macports.org>

David Robertson (ITG staff) wrote:
> This is a one-character change (from 25 to 27) and has been a ticket for
> almost a month.  I prefer using MacPorts to install Tomcat even though I
> realize I could install it myself.

Please do not email macports-tickets directly, use macports-dev instead.

I tried updating the port to 5.5.27 by changing version and checksums,
but the build failed for me. I will leave debugging that further to
someone who knows tomcat better as I usually do not use it.

The file is available from
<http://archive.apache.org/dist/tomcat/tomcat-5/v5.5.25/src/> and that
is also in the apache mirror list. I can fetch it fine from there and
also from the distfiles mirrors.

You can still fetch the file manually, please see
<http://trac.macports.org/wiki/ProblemHotlist#Fetchfailures>

Rainer

From mcalhoun at macports.org  Tue Jan  6 01:49:35 2009
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Tue, 6 Jan 2009 09:49:35 +0000 (UTC)
Subject: =?utf-8?b?dW5pdmVyc2FsX3ZhcmlhbnQ=?= depending on
	=?utf-8?b?dW5pdmVyc2FsX2FyY2hz?=
Message-ID: <loom.20090106T093713-194@post.gmane.org>

Recently, the universal variant of libffi was disabled
(http://trac.macports.org/changeset/44994/trunk/dports/devel/libffi/Portfile).

After a little experimentation, it seems getting full universal to work would
be an unpleasant undertaking.
Building a 32/64 bit universal seems to work fine though:
foreach arch ${universal_archs} {
	if { ${os.arch}=="i386" && (${arch}=="ppc" || ${arch}=="ppc64") } {
		universal_variant   no
	}
        if { ${os.arch}=="powerpc" && (${arch}=="i368" || ${arch}=="x86_64") } {
		universal_variant   no
	}
}

Such a change might cause difficulties for Portindex.
Even still, might this be a reasonable solution?

-Marcus




From jeremyhu at macports.org  Tue Jan  6 11:24:45 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Tue, 6 Jan 2009 11:24:45 -0800
Subject: system_x11 variant - where to draw the line
Message-ID: <C829EA57-D112-48D3-A2BA-A402959D79FD@macports.org>

So right now the system_x11 variant exists in all the xorg library  
ports.  This covers everything that could be installed in ${x11prefix}/ 
lib with the exception of freetype, cairo, fontconfig, and png.  I did  
that since that's more or less where the boundary is between "what we  
use from x11prefix" and "what we use from prefix" is now by default  
(enforced by the lib:...:... style dependencies for xorg libs and  
port: style dependencies for the others mentioned above).  I'd like to  
expand that by adding a system_x11 variant to freetype, cairo, and  
fontconfig to allow users to use the version of these packages in  
x11prefix if they're available.  Does anyone have compelling reasons  
why not to do that which I might be missing?


From illogical1 at gmail.com  Tue Jan  6 16:18:15 2009
From: illogical1 at gmail.com (Orville Bennett)
Date: Tue, 6 Jan 2009 19:18:15 -0500
Subject: [44843] trunk/dports/kde/amarok/Portfile
In-Reply-To: <4961BA3C.4000605@macports.org>
References: <20090103163347.9FA26B30488@beta.macosforge.org>	<20090103213915.GF755@ninagal.withay.com>
	<DDBAD2F1-CC26-4D21-AC92-B62EC8930DE7@gmail.com>
	<4961BA3C.4000605@macports.org>
Message-ID: <78EEA2D5-301A-4D6C-B6B0-57E14C9D16D6@gmail.com>


On Jan 5, 2009, at 2:43 AM, Joshua Root wrote:

> Orville Bennett wrote:
>> How do you reply to port commits? Just copy paste from the trac page?
>
> Commit messages get sent to the macports-changes mailing list[1].
>
> - Josh
>
> [1] <http://lists.macosforge.org/mailman/listinfo/macports-changes/>
thanks.

From jmr at macports.org  Tue Jan  6 22:42:29 2009
From: jmr at macports.org (Joshua Root)
Date: Wed, 07 Jan 2009 17:42:29 +1100
Subject: system_x11 variant - where to draw the line
In-Reply-To: <C829EA57-D112-48D3-A2BA-A402959D79FD@macports.org>
References: <C829EA57-D112-48D3-A2BA-A402959D79FD@macports.org>
Message-ID: <49644ED5.6080805@macports.org>

Jeremy Huddleston wrote:
> So right now the system_x11 variant exists in all the xorg library
> ports.  This covers everything that could be installed in
> ${x11prefix}/lib with the exception of freetype, cairo, fontconfig, and
> png.  I did that since that's more or less where the boundary is between
> "what we use from x11prefix" and "what we use from prefix" is now by
> default (enforced by the lib:...:... style dependencies for xorg libs
> and port: style dependencies for the others mentioned above).  I'd like
> to expand that by adding a system_x11 variant to freetype, cairo, and
> fontconfig to allow users to use the version of these packages in
> x11prefix if they're available.  Does anyone have compelling reasons why
> not to do that which I might be missing?

It seems odd to call the variant 'system_x11' in those cases, since
they're not necessarily used as part of X11 at all. Would it be more
appropriate to change the dependents that use them with X11?

I admit I haven't looked into it enough to know if there would be
problems either way.

BTW, does all this mean that we should be mass-changing lib:libX11:blah
deps to port:xorg-libX11? (Or a different port?)

- Josh

From jeremyhu at macports.org  Tue Jan  6 22:46:43 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Tue, 6 Jan 2009 22:46:43 -0800
Subject: system_x11 variant - where to draw the line
In-Reply-To: <49644ED5.6080805@macports.org>
References: <C829EA57-D112-48D3-A2BA-A402959D79FD@macports.org>
	<49644ED5.6080805@macports.org>
Message-ID: <22A24976-96D9-4D88-846A-00D150535ED3@macports.org>


On Jan 6, 2009, at 22:42, Joshua Root wrote:

> Jeremy Huddleston wrote:
>> So right now the system_x11 variant exists in all the xorg library
>> ports.  This covers everything that could be installed in
>> ${x11prefix}/lib with the exception of freetype, cairo, fontconfig,  
>> and
>> png.  I did that since that's more or less where the boundary is  
>> between
>> "what we use from x11prefix" and "what we use from prefix" is now by
>> default (enforced by the lib:...:... style dependencies for xorg libs
>> and port: style dependencies for the others mentioned above).  I'd  
>> like
>> to expand that by adding a system_x11 variant to freetype, cairo, and
>> fontconfig to allow users to use the version of these packages in
>> x11prefix if they're available.  Does anyone have compelling  
>> reasons why
>> not to do that which I might be missing?
>
> It seems odd to call the variant 'system_x11' in those cases, since
> they're not necessarily used as part of X11 at all. Would it be more
> appropriate to change the dependents that use them with X11?

True, hence why I'm bringing it up.

> BTW, does all this mean that we should be mass-changing  
> lib:libX11:blah
> deps to port:xorg-libX11? (Or a different port?)

Yes... see my email from a couple days ago... it will need to be all  
at once and revbump the affected ports... I'll post a patch to  
macports-dev and let it sit a few days before I push.

From jeremyhu at macports.org  Tue Jan  6 23:47:45 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Tue, 6 Jan 2009 23:47:45 -0800
Subject: system_x11 variant - where to draw the line
In-Reply-To: <49644ED5.6080805@macports.org>
References: <C829EA57-D112-48D3-A2BA-A402959D79FD@macports.org>
	<49644ED5.6080805@macports.org>
Message-ID: <A8D7E63E-47A9-49B3-A167-B1FFB1AB2374@macports.org>

BTW, how are you building all the dependencies?  Are you using fink?  
macports? by hand?

On Jan 6, 2009, at 22:42, Joshua Root wrote:

> Jeremy Huddleston wrote:
>> So right now the system_x11 variant exists in all the xorg library
>> ports.  This covers everything that could be installed in
>> ${x11prefix}/lib with the exception of freetype, cairo, fontconfig,  
>> and
>> png.  I did that since that's more or less where the boundary is  
>> between
>> "what we use from x11prefix" and "what we use from prefix" is now by
>> default (enforced by the lib:...:... style dependencies for xorg libs
>> and port: style dependencies for the others mentioned above).  I'd  
>> like
>> to expand that by adding a system_x11 variant to freetype, cairo, and
>> fontconfig to allow users to use the version of these packages in
>> x11prefix if they're available.  Does anyone have compelling  
>> reasons why
>> not to do that which I might be missing?
>
> It seems odd to call the variant 'system_x11' in those cases, since
> they're not necessarily used as part of X11 at all. Would it be more
> appropriate to change the dependents that use them with X11?
>
> I admit I haven't looked into it enough to know if there would be
> problems either way.
>
> BTW, does all this mean that we should be mass-changing  
> lib:libX11:blah
> deps to port:xorg-libX11? (Or a different port?)
>
> - Josh


From jeremyhu at macports.org  Tue Jan  6 23:56:18 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Tue, 6 Jan 2009 23:56:18 -0800
Subject: system_x11 variant - where to draw the line
In-Reply-To: <A8D7E63E-47A9-49B3-A167-B1FFB1AB2374@macports.org>
References: <C829EA57-D112-48D3-A2BA-A402959D79FD@macports.org>
	<49644ED5.6080805@macports.org>
	<A8D7E63E-47A9-49B3-A167-B1FFB1AB2374@macports.org>
Message-ID: <E8C7D033-7F83-4082-83FB-351365D947D4@macports.org>

replied to the wrong email there... please ignore...

On Jan 6, 2009, at 23:47, Jeremy Huddleston wrote:

> BTW, how are you building all the dependencies?  Are you using fink?  
> macports? by hand?
>
> On Jan 6, 2009, at 22:42, Joshua Root wrote:
>
>> Jeremy Huddleston wrote:
>>> So right now the system_x11 variant exists in all the xorg library
>>> ports.  This covers everything that could be installed in
>>> ${x11prefix}/lib with the exception of freetype, cairo,  
>>> fontconfig, and
>>> png.  I did that since that's more or less where the boundary is  
>>> between
>>> "what we use from x11prefix" and "what we use from prefix" is now by
>>> default (enforced by the lib:...:... style dependencies for xorg  
>>> libs
>>> and port: style dependencies for the others mentioned above).  I'd  
>>> like
>>> to expand that by adding a system_x11 variant to freetype, cairo,  
>>> and
>>> fontconfig to allow users to use the version of these packages in
>>> x11prefix if they're available.  Does anyone have compelling  
>>> reasons why
>>> not to do that which I might be missing?
>>
>> It seems odd to call the variant 'system_x11' in those cases, since
>> they're not necessarily used as part of X11 at all. Would it be more
>> appropriate to change the dependents that use them with X11?
>>
>> I admit I haven't looked into it enough to know if there would be
>> problems either way.
>>
>> BTW, does all this mean that we should be mass-changing  
>> lib:libX11:blah
>> deps to port:xorg-libX11? (Or a different port?)
>>
>> - Josh
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


From illogical1 at gmail.com  Wed Jan  7 05:26:53 2009
From: illogical1 at gmail.com (Orville Bennett)
Date: Wed, 7 Jan 2009 08:26:53 -0500
Subject: Any Macintosh available via SSH?
In-Reply-To: <1230747991.15562.1.camel@debian>
References: <1230747991.15562.1.camel@debian>
Message-ID: <CC228546-1D61-493B-9B58-9AEEAF933DAE@gmail.com>


On Dec 31, 2008, at 1:26 PM, Jean-Michel Pour? wrote:

> Dear Friends,
>
> As there is still no Kdenlive+MLT port, would someone be so kind to
> provide SSH access to a MacOsX station, so I can prepare packages
> myself.
>
> Kdenlive is a really interesting software for video enthousiasts using
> MacOsX and I don't understand why it is not already in MacPorts.
>
> Kind regards,
> Jean-Michel
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Hi Jean-Michel,
I'm not sure if you've received any feedback on this so here's my input.
Get in touch w/ KDE's mac branch on their mailing list 'kde-mac at kde  
dot org' (or on freenode #kde-mac) and ask someone there for a) ssh  
access b) to create a Portfile for mlt and kdenlive. Once a portfile  
is created submit it here or using trac (or just e-mail it to me).

If mlt and kdenlive build cleanly they'll be added to macports in  
short order.
Yes, I'm also with kde-mac, no I'm not volunteering to do this :-)
(Mlt and kdenlive seem to have a lot of dependencies that I have  
neither time nor inclination to wrestle with. Sorry.)

Lastly, if no one on this list has an interest in the software you're  
providing it won't be included unless it is a dependency of other  
software which is of interest. e.g. soprano only recently got  
included, because of kdelibs4.
I don't speak for anyone here, but it seems there isn't much interest  
in doing the work necessary to get kdenlive included. Just looking at  
the dependencies page made _me_ cringe, and I like KDE software.  
Imagine what somewhat who has no interest would think. Again, you're  
best bet: kde-mac mailing list.

Good luck.

From frstan at bellsouth.net  Wed Jan  7 07:34:53 2009
From: frstan at bellsouth.net (William Davis)
Date: Wed, 7 Jan 2009 10:34:53 -0500
Subject: ::ui_init
Message-ID: <C5588181-129C-417A-A1E6-3FE1A84AF286@bellsouth.net>

Warning: the following items did not execute (for xorg-libice):  
org.macports.destroot org.macports.build
DEBUG: invalid command name "::ui_init"
     while executing
"::ui_init $priority $prefix $channels $message"
     ("uplevel" body line 2)
     invoked from within
"uplevel 1 $body"
Error: Unable to upgrade port: 1
macintosh:~ frstan$

There are now something like 5 ports which fail update with 'invalid  
command name "::ui_init".
What's the story?


William Davis
frstanATbellsouthDOTnet
Mac OS X.5.6 Darwin 9.5.0
XQuartz 2.3.2 (xorg-server 1.4.2-apple31)
Mac Mini Intel Duo @ 1.86 GHz

Mundus vult decepi, ego non


From jmr at macports.org  Wed Jan  7 07:58:35 2009
From: jmr at macports.org (Joshua Root)
Date: Thu, 08 Jan 2009 02:58:35 +1100
Subject: ::ui_init
In-Reply-To: <C5588181-129C-417A-A1E6-3FE1A84AF286@bellsouth.net>
References: <C5588181-129C-417A-A1E6-3FE1A84AF286@bellsouth.net>
Message-ID: <4964D12B.7030600@macports.org>

William Davis wrote:
> Warning: the following items did not execute (for xorg-libice):
> org.macports.destroot org.macports.build
> DEBUG: invalid command name "::ui_init"
>     while executing
> "::ui_init $priority $prefix $channels $message"
>     ("uplevel" body line 2)
>     invoked from within
> "uplevel 1 $body"
> Error: Unable to upgrade port: 1
> macintosh:~ frstan$
> 
> There are now something like 5 ports which fail update with 'invalid
> command name "::ui_init".
> What's the story?

The ui_init thing is not what is causing the failure, you'll notice that
it happens after another error. Previous mention on the list:
<http://lists.macosforge.org/pipermail/macports-dev/2008-December/006786.html>

- Josh

From jm at poure.com  Thu Jan  8 11:31:45 2009
From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=)
Date: Thu, 08 Jan 2009 20:31:45 +0100
Subject: Any Macintosh available via SSH?
In-Reply-To: <CC228546-1D61-493B-9B58-9AEEAF933DAE@gmail.com>
References: <1230747991.15562.1.camel@debian>
	<CC228546-1D61-493B-9B58-9AEEAF933DAE@gmail.com>
Message-ID: <1231443105.5672.6.camel@debian>

On Wed, 2009-01-07 at 08:26 -0500, Orville Bennett wrote:
> If mlt and kdenlive build cleanly they'll be added to macports in  
> short order.

A Kdenlive user showed up and we will probably to try together to submit
something to Kdenlive mailing list.

> I don't speak for anyone here, but it seems there isn't much
> interest in doing the work necessary to get kdenlive included.

I think Kdenlive can be a good reason for Mac users to install MacPorts.

Kind regards,
Jean-Michel


From markd at macports.org  Thu Jan  8 12:31:19 2009
From: markd at macports.org (markd at macports.org)
Date: Thu, 08 Jan 2009 12:31:19 -0800
Subject: DB_File perl module?
Message-ID: <fc.004c4c58112e6620004c4c58112e6620.112e69bf@biola.edu>

Hello all,

I have two problems.

1) I installed the new perl 5.8.9 and now a port I used to install (one of
my own - sympa) says it won't install because DB_File is not found.  Was
that included in perl 5.8.8?

2) Then I tried to port DB_File and I get:

blah, blah, blah ....
Writing
/opt/local/var/macports/build/_Users_<my-dir>_mports_perl_p5-db_file/work/destroot/opt/local/lib/perl5/5.8.9/darwin-2level/auto/DB_File/.packlist
DEBUG: Executing proc-post-org.macports.destroot-destroot-0
Error: Target org.macports.destroot returned: no such file or directory

The thing is that .packlist exists in the destroot directory, so I don't
know what file or directory it is claiming does not exist.  The MP 1.7
release and HEAD behave the same.  Any ideas?

Mark


From mroman at eduapple.pl  Thu Jan  8 13:38:31 2009
From: mroman at eduapple.pl (Marcin Roman)
Date: Thu, 8 Jan 2009 22:38:31 +0100
Subject: djvulibre ports
Message-ID: <6083E28C-F92B-47DE-B4E8-7C80A0382872@eduapple.pl>

Could anyone commit these ports:

http://trac.macports.org/ticket/16988 - new djview port, depends on qt4
http://trac.macports.org/ticket/16941 - updated djvulibre port

It seems some additional variants can be added to djvulibre port:
	- QuickLook plugin
	- Spotlight plugin
The problem is that the main makefile doesn't handle the additional  
project. I don't know how to modify phases to build them all.

mr

From opendarwin.org at darkart.com  Thu Jan  8 14:18:14 2009
From: opendarwin.org at darkart.com (Eric Hall)
Date: Thu, 8 Jan 2009 22:18:14 +0000
Subject: DB_File perl module?
In-Reply-To: <fc.004c4c58112e6620004c4c58112e6620.112e69bf@biola.edu>
References: <fc.004c4c58112e6620004c4c58112e6620.112e69bf@biola.edu>
Message-ID: <20090108221814.GN1155@darkart.com>

On Thu, Jan 08, 2009 at 12:31:19PM -0800, markd at macports.org wrote:
> Hello all,
> 
> I have two problems.
> 
> 1) I installed the new perl 5.8.9 and now a port I used to install (one of
> my own - sympa) says it won't install because DB_File is not found.  Was
> that included in perl 5.8.8?

	Yes, it was (.../lib/perl5/5.8.8./darwin-thread-multi-2level/DB_File.pm)
and its not part of 5.8.9 (so far as the macport install goes).  Hmm, not sure
why its not installing DB_File, I suspect its not finding the Berkeley DB stuff.
There is a variant for adding Berkeley DB support (builds db4.7), testing...
Bah, db47 fails to configure w/o tclConfig.sh (see #17922).  Fixing locally
and continuing on...  Well, it configured to use DB_File, I'll check on the
build later to make sure it works, but you could try adding +db (after db47
fix gets committed).


> 
> 2) Then I tried to port DB_File and I get:
> 
> blah, blah, blah ....
> Writing
> /opt/local/var/macports/build/_Users_<my-dir>_mports_perl_p5-db_file/work/destroot/opt/local/lib/perl5/5.8.9/darwin-2level/auto/DB_File/.packlist
> DEBUG: Executing proc-post-org.macports.destroot-destroot-0
> Error: Target org.macports.destroot returned: no such file or directory
> 
> The thing is that .packlist exists in the destroot directory, so I don't
> know what file or directory it is claiming does not exist.  The MP 1.7
> release and HEAD behave the same.  Any ideas?
> 


	Any reason you can't use NDBM_File instead?  (that's the DB/DBM module I have
installed via macports for perl5.8 5.8.9)



From ryandesign at macports.org  Thu Jan  8 19:54:34 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 8 Jan 2009 21:54:34 -0600
Subject: nice configure
Message-ID: <9B38B4DE-9601-4065-853A-9834062F4A06@macports.org>

If you set "buildnicevalue" in ${prefix}/etc/macports/macports.conf,  
MacPorts runs the build phase through the "nice" command so that  
"port" runs at a lower priority and doesn't steal cycles from other  
processor-intensive tasks you might have running.

Would there be any advantage (or rather any disadvantage) to making  
the other phases, in particular the configure phase, nice as well?



From frstan at bellsouth.net  Thu Jan  8 20:02:33 2009
From: frstan at bellsouth.net (William Davis)
Date: Thu, 8 Jan 2009 23:02:33 -0500
Subject: nice configure
In-Reply-To: <9B38B4DE-9601-4065-853A-9834062F4A06@macports.org>
References: <9B38B4DE-9601-4065-853A-9834062F4A06@macports.org>
Message-ID: <492C1356-29A4-43D4-A8AD-47CE5BBD22A9@bellsouth.net>


On Jan 8, 2009, at 10:54 PM, Ryan Schmidt wrote:

> If you set "buildnicevalue" in ${prefix}/etc/macports/macports.conf,  
> MacPorts runs the build phase through the "nice" command so that  
> "port" runs at a lower priority and doesn't steal cycles from other  
> processor-intensive tasks you might have running.
>
> Would there be any advantage (or rather any disadvantage) to making  
> the other phases, in particular the configure phase, nice as well?
>
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

AFAIK the nice command has been broken for a very long time.  Just  
bring up Activity Monitor and check it out.  You will fine the %CPU  
used by "nice" processes is always zero (unless you are using a really  
old OS).

William Davis
frstanATbellsouthDOTnet
Mac OS X.5.6 Darwin 9.5.0
XQuartz 2.3.2 (xorg-server 1.4.2-apple31)
Mac Mini Intel Duo @ 1.86 GHz

Mundus vult decepi, ego non


From ryandesign at macports.org  Thu Jan  8 20:20:20 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 8 Jan 2009 22:20:20 -0600
Subject: nice configure
In-Reply-To: <492C1356-29A4-43D4-A8AD-47CE5BBD22A9@bellsouth.net>
References: <9B38B4DE-9601-4065-853A-9834062F4A06@macports.org>
	<492C1356-29A4-43D4-A8AD-47CE5BBD22A9@bellsouth.net>
Message-ID: <5AD14BB4-6929-4199-9AD7-DA5B0CAC02C9@macports.org>

On Jan 8, 2009, at 22:02, William Davis wrote:

> On Jan 8, 2009, at 10:54 PM, Ryan Schmidt wrote:
>
>> If you set "buildnicevalue" in ${prefix}/etc/macports/ 
>> macports.conf, MacPorts runs the build phase through the "nice"  
>> command so that "port" runs at a lower priority and doesn't steal  
>> cycles from other processor-intensive tasks you might have running.
>>
>> Would there be any advantage (or rather any disadvantage) to  
>> making the other phases, in particular the configure phase, nice  
>> as well?
>
> AFAIK the nice command has been broken for a very long time.  Just  
> bring up Activity Monitor and check it out.  You will fine the %CPU  
> used by "nice" processes is always zero (unless you are using a  
> really old OS).

The buildnicevalue definitely has the intended effect for me, during  
the build phase. When I use buildnicevalue, I can see this in my CPU  
meter in the menubar (MenuMeters), and I can feel an increase in  
system responsiveness. I am using Tiger.

So my question is whether it would help anything to also run the  
configure phase nicely, not just the build phase.


There are ports for which the buildnicevalue will not take effect --  
specifically ports that replace build.cmd with something that  
contains a space.



From ryandesign at macports.org  Thu Jan  8 23:41:01 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 9 Jan 2009 01:41:01 -0600
Subject: [45140] trunk/dports/multimedia/smpeg/Portfile
In-Reply-To: <20090109024430.4EF01B9C0EE@beta.macosforge.org>
References: <20090109024430.4EF01B9C0EE@beta.macosforge.org>
Message-ID: <CBC206A0-4F68-43DF-85AA-8255B9FFFF71@macports.org>

On Jan 8, 2009, at 20:44, jeremyhu at macports.org wrote:

> Revision: 45140
>           http://trac.macports.org/changeset/45140
> Author:   jeremyhu at macports.org
> Date:     2009-01-08 18:44:29 -0800 (Thu, 08 Jan 2009)
> Log Message:
> -----------
> smpeg: Build universal.  Ticket #17909

Did you have Markus' permission to do this? If yes, you should so  
indicate in the ticket and/or commit message. Otherwise, since the  
ticket was just filed 24 hours ago, it looks like you're updating a  
port without waiting the prescribed 72 hours for a maintainer response.


> +	system "ln -s ${prefix}/bin/glibtool ${worksrcpath}/libtool"

You shouldn't use "system" just to make a symlink. There's a Tcl  
command for this, and it's simply "ln -s". I fixed it here for you  
but please keep it in mind for future updates.



From jmr at macports.org  Fri Jan  9 00:09:38 2009
From: jmr at macports.org (Joshua Root)
Date: Fri, 09 Jan 2009 19:09:38 +1100
Subject: [45146] trunk/dports/graphics/gd2/Portfile
In-Reply-To: <20090109075751.A23F7B9F2C0@beta.macosforge.org>
References: <20090109075751.A23F7B9F2C0@beta.macosforge.org>
Message-ID: <49670642.7050803@macports.org>

ryandesign at macports.org wrote:
> Revision: 45146
>           http://trac.macports.org/changeset/45146
> Author:   ryandesign at macports.org
> Date:     2009-01-08 23:57:50 -0800 (Thu, 08 Jan 2009)
> Log Message:
> -----------
> gd2: use "use_autoconf" to autoreconf
> 
> Modified Paths:
> --------------
>     trunk/dports/graphics/gd2/Portfile
> 
> Modified: trunk/dports/graphics/gd2/Portfile
> ===================================================================
> --- trunk/dports/graphics/gd2/Portfile	2009-01-09 07:48:52 UTC (rev 45145)
> +++ trunk/dports/graphics/gd2/Portfile	2009-01-09 07:57:50 UTC (rev 45146)
> @@ -62,11 +62,8 @@
>      copy -force ${prefix}/share/libtool/config/ltmain.sh ${worksrcpath}/config/ltmain.sh
>  }
>  
> -pre-configure {
> -    set cmd "cd ${worksrcpath} && autoreconf"
> -    ui_debug ${cmd}
> -    system "${cmd}"
> -}
> +use_autoconf            yes
> +autoconf.cmd            ${prefix}/bin/autoreconf

Why not just "use_autoreconf yes"?

- Josh

From ryandesign at macports.org  Fri Jan  9 00:13:29 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 9 Jan 2009 02:13:29 -0600
Subject: [45146] trunk/dports/graphics/gd2/Portfile
In-Reply-To: <49670642.7050803@macports.org>
References: <20090109075751.A23F7B9F2C0@beta.macosforge.org>
	<49670642.7050803@macports.org>
Message-ID: <3F9192EB-FB3B-41C8-95C3-95620ABE7517@macports.org>


On Jan 9, 2009, at 02:09, Joshua Root wrote:

>> -pre-configure {
>> -    set cmd "cd ${worksrcpath} && autoreconf"
>> -    ui_debug ${cmd}
>> -    system "${cmd}"
>> -}
>> +use_autoconf            yes
>> +autoconf.cmd            ${prefix}/bin/autoreconf
>
> Why not just "use_autoreconf yes"?

Oh yes, I forgot we can do that in MacPorts 1.7.0 now too! I'll fix it.


From ryandesign at macports.org  Fri Jan  9 01:32:44 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 9 Jan 2009 03:32:44 -0600
Subject: [44639] trunk/dports/x11
In-Reply-To: <20090101175947.B5191AFC928@beta.macosforge.org>
References: <20090101175947.B5191AFC928@beta.macosforge.org>
Message-ID: <B13FEB47-D8F1-414D-A3EE-42CFD089D10B@macports.org>

On Jan 1, 2009, at 11:59, css at macports.org wrote:

> +worksrcdir	Mesa-${version}
> +build.cmd	cd "${worksrcpath}/src/glw" && make
> +build.target

Why not set build.dir instead of build.cmd? I haven't tested it but  
shouldn't this work:


Index: Portfile
===================================================================
--- Portfile	(revision 45155)
+++ Portfile	(working copy)
@@ -30,7 +30,7 @@
  configure.args-append	--enable-motif

  worksrcdir	Mesa-${version}
-build.cmd	cd "${worksrcpath}/src/glw" && make
+build.dir	${worksrcpath}/src/glw
  build.target

  variant darwin {



From florian.ebeling at gmail.com  Fri Jan  9 03:29:17 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Fri, 9 Jan 2009 12:29:17 +0100
Subject: [45158] trunk/dports/net/tuntaposx/Portfile
In-Reply-To: <20090109103821.9B0F9BA06AD@beta.macosforge.org>
References: <20090109103821.9B0F9BA06AD@beta.macosforge.org>
Message-ID: <5cbbe4ae0901090329m282e7f4dg35d579c6962ff497@mail.gmail.com>

> --- trunk/dports/net/tuntaposx/Portfile	2009-01-09 09:52:24 UTC (rev 45157)
> +++ trunk/dports/net/tuntaposx/Portfile	2009-01-09 10:38:19 UTC (rev 45158)
> +configure {
> +	reinplace "s|CCP = g++|CCP = ${configure.cxx}|"
> ${worksrcpath}/src/tun/Makefile \
> +	
> ${worksrcpath}/src/tap/Makefile
> +	reinplace "s|CC = gcc|CC = ${configure.cc}|"
> ${worksrcpath}/src/tun/Makefile \
> +	
> ${worksrcpath}/src/tap/Makefile
> +	if {[variant_isset universal]} {
> +	    reinplace "s|/Developer/SDKs/MacOSX10.4u.sdk/|${universal_sysroot}|" \
> +	        ${worksrcpath}/src/tun/Makefile ${worksrcpath}/src/tap/Makefile
> +	} else {
> +	    reinplace "s|-arch ppc -arch i386 -isysroot
> /Developer/SDKs/MacOSX10.4u.sdk/| |" \
> +	        ${worksrcpath}/src/tun/Makefile ${worksrcpath}/src/tap/Makefile
> +	}
>  }

Ok :)

Looks convincing.

Any idea whats wrong with fscript by any chance? Unrelated, but the error looks
like an sysroot problem as well (intel/10.5.6):

=== BUILDING NATIVE TARGET FScriptPalette OF PROJECT FScript WITH
CONFIGURATION Deployment ===

Checking Dependencies...

Ld /opt/local/var/macports/build/_Users_febeling_vendor_macports-svn_dports_aqua_FScript/work/FScriptSources-20070421/FScript/build/FScript.build/Deployment/FScriptPalette.build/Objects-normal/ppc/FScriptPalette
normal ppc
    cd /opt/local/var/macports/build/_Users_febeling_vendor_macports-svn_dports_aqua_FScript/work/FScriptSources-20070421/FScript
    /Developer/usr/bin/gcc-4.0 -arch ppc -bundle -isysroot
/Developer/SDKs/MacOSX10.4u.sdk
-L/opt/local/var/macports/build/_Users_febeling_vendor_macports-svn_dports_aqua_FScript/work/FScriptSources-20070421/FScript/build/Deployment
-F/opt/local/var/macports/build/_Users_febeling_vendor_macports-svn_dports_aqua_FScript/work/FScriptSources-20070421/FScript/build/Deployment
-filelist /opt/local/var/macports/build/_Users_febeling_vendor_macports-svn_dports_aqua_FScript/work/FScriptSources-20070421/FScript/build/FScript.build/Deployment/FScriptPalette.build/Objects-normal/ppc/FScriptPalette.LinkFileList
-mmacosx-version-min=10.3 -bundle -framework JavaVM -framework
ExceptionHandling -framework Cocoa -framework InterfaceBuilder -o
/opt/local/var/macports/build/_Users_febeling_vendor_macports-svn_dports_aqua_FScript/work/FScriptSources-20070421/FScript/build/FScript.build/Deployment/FScriptPalette.build/Objects-normal/ppc/FScriptPalette
ld: file not found:
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks//InterfaceBuilder.framework/../../../../PrivateFrameworks/DevToolsRemoteClient.framework/Versions/A/DevToolsRemoteClient
collect2: ld returned 1 exit status

Ld /opt/local/var/macports/build/_Users_febeling_vendor_macports-svn_dports_aqua_FScript/work/FScriptSources-20070421/FScript/build/FScript.build/Deployment/FScriptPalette.build/Objects-normal/i386/FScriptPalette
normal i386
    cd /opt/local/var/macports/build/_Users_febeling_vendor_macports-svn_dports_aqua_FScript/work/FScriptSources-20070421/FScript
    /Developer/usr/bin/gcc-4.0 -arch i386 -bundle -isysroot
/Developer/SDKs/MacOSX10.4u.sdk
-L/opt/local/var/macports/build/_Users_febeling_vendor_macports-svn_dports_aqua_FScript/work/FScriptSources-20070421/FScript/build/Deployment
-F/opt/local/var/macports/build/_Users_febeling_vendor_macports-svn_dports_aqua_FScript/work/FScriptSources-20070421/FScript/build/Deployment
-filelist /opt/local/var/macports/build/_Users_febeling_vendor_macports-svn_dports_aqua_FScript/work/FScriptSources-20070421/FScript/build/FScript.build/Deployment/FScriptPalette.build/Objects-normal/i386/FScriptPalette.LinkFileList
-mmacosx-version-min=10.4 -bundle -framework JavaVM -framework
ExceptionHandling -framework Cocoa -framework InterfaceBuilder -o
/opt/local/var/macports/build/_Users_febeling_vendor_macports-svn_dports_aqua_FScript/work/FScriptSources-20070421/FScript/build/FScript.build/Deployment/FScriptPalette.build/Objects-normal/i386/FScriptPalette
ld: file not found:
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks//InterfaceBuilder.framework/../../../../PrivateFrameworks/DevToolsRemoteClient.framework/Versions/A/DevToolsRemoteClient
collect2: ld returned 1 exit status
** BUILD FAILED **

The following build commands failed:
FScriptPalette:
	Ld /opt/local/var/macports/build/_Users_febeling_vendor_macports-svn_dports_aqua_FScript/work/FScriptSources-20070421/FScript/build/FScript.build/Deployment/FScriptPalette.build/Objects-normal/ppc/FScriptPalette
normal ppc
	Ld /opt/local/var/macports/build/_Users_febeling_vendor_macports-svn_dports_aqua_FScript/work/FScriptSources-20070421/FScript/build/FScript.build/Deployment/FScriptPalette.build/Objects-normal/i386/FScriptPalette
normal i386
(2 failures)


Warning: the following items did not execute (for FScript):
org.macports.activate org.macports.build org.macports.destroot
org.macports.install
Error: Status 1 encountered during processing.




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

From jmr at macports.org  Fri Jan  9 03:59:52 2009
From: jmr at macports.org (Joshua Root)
Date: Fri, 09 Jan 2009 22:59:52 +1100
Subject: [45158] trunk/dports/net/tuntaposx/Portfile
In-Reply-To: <5cbbe4ae0901090329m282e7f4dg35d579c6962ff497@mail.gmail.com>
References: <20090109103821.9B0F9BA06AD@beta.macosforge.org>
	<5cbbe4ae0901090329m282e7f4dg35d579c6962ff497@mail.gmail.com>
Message-ID: <49673C38.8090704@macports.org>

C. Florian Ebeling wrote:
>> --- trunk/dports/net/tuntaposx/Portfile	2009-01-09 09:52:24 UTC (rev 45157)
>> +++ trunk/dports/net/tuntaposx/Portfile	2009-01-09 10:38:19 UTC (rev 45158)
>> +configure {
>> +	reinplace "s|CCP = g++|CCP = ${configure.cxx}|"
>> ${worksrcpath}/src/tun/Makefile \
>> +	
>> ${worksrcpath}/src/tap/Makefile
>> +	reinplace "s|CC = gcc|CC = ${configure.cc}|"
>> ${worksrcpath}/src/tun/Makefile \
>> +	
>> ${worksrcpath}/src/tap/Makefile
>> +	if {[variant_isset universal]} {
>> +	    reinplace "s|/Developer/SDKs/MacOSX10.4u.sdk/|${universal_sysroot}|" \
>> +	        ${worksrcpath}/src/tun/Makefile ${worksrcpath}/src/tap/Makefile
>> +	} else {
>> +	    reinplace "s|-arch ppc -arch i386 -isysroot
>> /Developer/SDKs/MacOSX10.4u.sdk/| |" \
>> +	        ${worksrcpath}/src/tun/Makefile ${worksrcpath}/src/tap/Makefile
>> +	}
>>  }
> 
> Ok :)
> 
> Looks convincing.
> 
> Any idea whats wrong with fscript by any chance? Unrelated, but the error looks
> like an sysroot problem as well (intel/10.5.6):

It looks like maybe you don't have the 10.4u SDK and it needs it.

- Josh

From cssdev at mac.com  Fri Jan  9 04:38:31 2009
From: cssdev at mac.com (cssdev at mac.com)
Date: Fri, 09 Jan 2009 07:38:31 -0500
Subject: [44639] trunk/dports/x11
In-Reply-To: <B13FEB47-D8F1-414D-A3EE-42CFD089D10B@macports.org>
References: <20090101175947.B5191AFC928@beta.macosforge.org>
	<B13FEB47-D8F1-414D-A3EE-42CFD089D10B@macports.org>
Message-ID: <8289E64F-45D8-42B9-A192-6A7BED0F8365@mac.com>

On Jan 9, 2009, at 4:32 AM, Ryan Schmidt wrote:

> On Jan 1, 2009, at 11:59, css at macports.org wrote:
>
>> +worksrcdir	Mesa-${version}
>> +build.cmd	cd "${worksrcpath}/src/glw" && make
>> +build.target
>
> Why not set build.dir instead of build.cmd? I haven't tested it but  
> shouldn't this work:

Mainly just that I didn't think of it. :) That patch works fine, and  
it's cleaner. Thanks!

Chris

From florian.ebeling at gmail.com  Fri Jan  9 04:42:42 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Fri, 9 Jan 2009 13:42:42 +0100
Subject: [45158] trunk/dports/net/tuntaposx/Portfile
In-Reply-To: <49673C38.8090704@macports.org>
References: <20090109103821.9B0F9BA06AD@beta.macosforge.org>
	<5cbbe4ae0901090329m282e7f4dg35d579c6962ff497@mail.gmail.com>
	<49673C38.8090704@macports.org>
Message-ID: <5cbbe4ae0901090442k7188a920pc298ab0861ea9b4d@mail.gmail.com>

>> Any idea whats wrong with fscript by any chance? Unrelated, but the error looks
>> like an sysroot problem as well (intel/10.5.6):
>
> It looks like maybe you don't have the 10.4u SDK and it needs it.

At least the directory /Developer/SDKs/MacOSX10.4u.sdk is there.
Are there optional parts, which might be missing?

It is #16580 [1], btw. but seems a bit like I'm the only one experiencing it.
Maybe someone else one the list could try to install it and confirm or
comment...

Florian


1 http://trac.macports.org/ticket/16580

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

From ram at macports.org  Fri Jan  9 05:46:57 2009
From: ram at macports.org (Adam Mercer)
Date: Fri, 9 Jan 2009 07:46:57 -0600
Subject: nice configure
In-Reply-To: <492C1356-29A4-43D4-A8AD-47CE5BBD22A9@bellsouth.net>
References: <9B38B4DE-9601-4065-853A-9834062F4A06@macports.org>
	<492C1356-29A4-43D4-A8AD-47CE5BBD22A9@bellsouth.net>
Message-ID: <799406d60901090546x590fbf47ic5e4e45e3834310@mail.gmail.com>

On Thu, Jan 8, 2009 at 22:02, William Davis <frstan at bellsouth.net> wrote:

> AFAIK the nice command has been broken for a very long time.  Just bring up
> Activity Monitor and check it out.  You will fine the %CPU used by "nice"
> processes is always zero (unless you are using a really old OS).

Thats a bug in ActivityMonitor not reporting nice'd processes
properly, I have a bug open with Apple about this. If you use top on
the command line then the nice'd processes will be properly displayed.

Cheers

Adam

From raimue at macports.org  Fri Jan  9 06:11:11 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Fri, 09 Jan 2009 15:11:11 +0100
Subject: [45158] trunk/dports/net/tuntaposx/Portfile
In-Reply-To: <5cbbe4ae0901090442k7188a920pc298ab0861ea9b4d@mail.gmail.com>
References: <20090109103821.9B0F9BA06AD@beta.macosforge.org>	<5cbbe4ae0901090329m282e7f4dg35d579c6962ff497@mail.gmail.com>	<49673C38.8090704@macports.org>
	<5cbbe4ae0901090442k7188a920pc298ab0861ea9b4d@mail.gmail.com>
Message-ID: <49675AFF.7030005@macports.org>

C. Florian Ebeling wrote:
> It is #16580 [1], btw. but seems a bit like I'm the only one experiencing it.
> Maybe someone else one the list could try to install it and confirm or
> comment...

I get the same error message as you.

Rainer

From jmr at macports.org  Fri Jan  9 07:03:23 2009
From: jmr at macports.org (Joshua Root)
Date: Sat, 10 Jan 2009 02:03:23 +1100
Subject: [44914] trunk/dports/devel/git-core/Portfile
In-Reply-To: <20090104195028.76C93B41DF7@beta.macosforge.org>
References: <20090104195028.76C93B41DF7@beta.macosforge.org>
Message-ID: <4967673B.1070806@macports.org>

blair at macports.org wrote:
> Revision: 44914
>           http://trac.macports.org/changeset/44914
> Author:   blair at macports.org
> Date:     2009-01-04 11:50:27 -0800 (Sun, 04 Jan 2009)
> Log Message:
> -----------
> Add a depends_build on p5-scalar-list-utils.  Without this, the
> installation fails when Scalar::Util cannot be found.
> 
> Modified Paths:
> --------------
>     trunk/dports/devel/git-core/Portfile
> 
> Modified: trunk/dports/devel/git-core/Portfile
> ===================================================================
> --- trunk/dports/devel/git-core/Portfile	2009-01-04 18:52:21 UTC (rev 44913)
> +++ trunk/dports/devel/git-core/Portfile	2009-01-04 19:50:27 UTC (rev 44914)
> @@ -4,6 +4,7 @@
>  
>  name              git-core
>  version           1.6.1
> +revision          1
>  description       A fast version control system
>  long_description  Git is a fast, scalable, distributed open source version \
>                    control system focusing on speed and efficiency.
> @@ -22,6 +23,7 @@
>  checksums    git-${version}${extract.suffix} sha1 4caeafd06a5482337052f142073be66f2a39134a \
>               git-manpages-${version}${extract.suffix} sha1 fa2d94dc966484b14ae11d39d0d8336946a93001
>  
> +depends_build port:p5-scalar-list-utils

The p5-scalar-list-utils port conflicts with perl5.8, and git-core seems
to build fine without that dependency. Maybe the update to perl 5.8.9
made this happen.

- Josh

From blair at orcaware.com  Fri Jan  9 10:13:41 2009
From: blair at orcaware.com (Blair Zajac)
Date: Fri, 09 Jan 2009 10:13:41 -0800
Subject: [44914] trunk/dports/devel/git-core/Portfile
In-Reply-To: <4967673B.1070806@macports.org>
References: <20090104195028.76C93B41DF7@beta.macosforge.org>
	<4967673B.1070806@macports.org>
Message-ID: <496793D5.6040304@orcaware.com>

Joshua Root wrote:
> blair at macports.org wrote:
>> Revision: 44914
>>           http://trac.macports.org/changeset/44914
>> Author:   blair at macports.org
>> Date:     2009-01-04 11:50:27 -0800 (Sun, 04 Jan 2009)
>> Log Message:
>> -----------
>> Add a depends_build on p5-scalar-list-utils.  Without this, the
>> installation fails when Scalar::Util cannot be found.
>>
>> Modified Paths:
>> --------------
>>     trunk/dports/devel/git-core/Portfile
>>
>> Modified: trunk/dports/devel/git-core/Portfile
>> ===================================================================
>> --- trunk/dports/devel/git-core/Portfile	2009-01-04 18:52:21 UTC (rev 44913)
>> +++ trunk/dports/devel/git-core/Portfile	2009-01-04 19:50:27 UTC (rev 44914)
>> @@ -4,6 +4,7 @@
>>  
>>  name              git-core
>>  version           1.6.1
>> +revision          1
>>  description       A fast version control system
>>  long_description  Git is a fast, scalable, distributed open source version \
>>                    control system focusing on speed and efficiency.
>> @@ -22,6 +23,7 @@
>>  checksums    git-${version}${extract.suffix} sha1 4caeafd06a5482337052f142073be66f2a39134a \
>>               git-manpages-${version}${extract.suffix} sha1 fa2d94dc966484b14ae11d39d0d8336946a93001
>>  
>> +depends_build port:p5-scalar-list-utils
> 
> The p5-scalar-list-utils port conflicts with perl5.8, and git-core seems
> to build fine without that dependency. Maybe the update to perl 5.8.9
> made this happen.

It looks like perl 5.8.9 now includes Scalar::List::Utils so we could drop that 
dependency.  I was having issues installing git-core with 5.8.8.

Blair

From jjstickel at vcn.com  Fri Jan  9 13:24:20 2009
From: jjstickel at vcn.com (Jonathan Stickel)
Date: Fri, 09 Jan 2009 14:24:20 -0700
Subject: new ports libqalculate and qalculate-gtk
Message-ID: <4967C084.9050105@vcn.com>

Someone ("devens@") looked at my new port request for Qalculate a few 
days ago (ticket 17618), but I don't see him/her cc'd on the ticket. 
Anyway, I have resolved an issue I reported there, and I think the ports 
are ready to commit if someone would like to take a look.

Thanks,
Jonathan

From frstan at bellsouth.net  Sat Jan 10 11:11:40 2009
From: frstan at bellsouth.net (William Davis)
Date: Sat, 10 Jan 2009 14:11:40 -0500
Subject: nice configure
In-Reply-To: <799406d60901090546x590fbf47ic5e4e45e3834310@mail.gmail.com>
References: <9B38B4DE-9601-4065-853A-9834062F4A06@macports.org>
	<492C1356-29A4-43D4-A8AD-47CE5BBD22A9@bellsouth.net>
	<799406d60901090546x590fbf47ic5e4e45e3834310@mail.gmail.com>
Message-ID: <79A8A2E0-CE86-49ED-847A-77EBD00B7009@bellsouth.net>


On Jan 9, 2009, at 8:46 AM, Adam Mercer wrote:

> On Thu, Jan 8, 2009 at 22:02, William Davis <frstan at bellsouth.net>  
> wrote:
>
>> AFAIK the nice command has been broken for a very long time.  Just  
>> bring up
>> Activity Monitor and check it out.  You will fine the %CPU used by  
>> "nice"
>> processes is always zero (unless you are using a really old OS).
>
> Thats a bug in ActivityMonitor not reporting nice'd processes
> properly, I have a bug open with Apple about this. If you use top on
> the command line then the nice'd processes will be properly displayed.
>
> Cheers
>
> Adam

Really Adam?  Please show me where in this print of top I can see that:

Processes:  75 total, 4 running, 2 stuck, 69 sleeping... 282  
threads    14:06:05
Load Avg:  3.48,  3.59,  3.16    CPU usage: 68.64% user,  7.27% sys,  
24.09% idle
SharedLibs: num =    8, resident =   81M code, 1984K data, 5068K  
linkedit.
MemRegions: num = 14244, resident =  493M +   32M private,  407M shared.
PhysMem:  304M wired, 1146M active,  307M inactive, 1769M used,  279M  
free.
VM: 11G + 373M   321202(0) pageins, 0(0) pageouts

   PID COMMAND      %CPU   TIME   #TH #PRTS #MREGS RPRVT  RSHRD   
RSIZE  VSIZE
29068 top          7.8%  0:17.80   1    18     29  504K   188K   
1096K    18M
29066 xclock       0.0%  0:19.62   1    14    123 3996K  2852K   
6320K    26M
29013 PubSubAgen   0.0%  0:00.10   2    57     27  544K  2136K   
1588K    20M
28938 bash         0.0%  0:00.03   1    14     19  300K   704K    
944K    18M
28937 login        0.0%  0:00.01   1    17     55  300K   268K   
1076K    19M
28929 pmTool       0.0%  0:16.95   1    24     25  464K  4664K   
1328K    27M
28927 Activity M   0.5%  0:20.49   5   112    264 4984K    28M     
12M   391M
28924 quartz-wm    0.0%  0:00.06   2    43     64  476K  5120K   
2548K   299M
28820 X11.bin      0.7%  0:01.55   8   135    269 6160K    21M     
14M   390M
28819 Xquartz      0.0%  0:00.00   1    25     25  164K  2160K    
892K    20M
28818 xinit        0.0%  0:00.00   1    13     31  120K   968K    
512K    18M
28767 sh           0.0%  0:00.01   1    13     18  152K   184K    
688K    18M
28766 xedit        0.0%  0:00.06   1    13     68  880K  2064K   
2772K    21M
28723 bash         0.0%  0:00.02   1    14     19  304K   704K    
944K    18M
28722 login        0.0%  0:00.03   1    17     55  296K   268K   
1072K    19M
28721 Terminal     2.5%  0:07.43   3   100    170 3460K+   16M+ 9444K 
+  361M+


William Davis
frstanATbellsouthDOTnet
Mac OS X.5.6 Darwin 9.5.0
XQuartz 2.3.2 (xorg-server 1.4.2-apple31)
Mac Mini Intel Duo @ 1.86 GHz

Mundus vult decepi, ego non


From jmr at macports.org  Sat Jan 10 11:22:25 2009
From: jmr at macports.org (Joshua Root)
Date: Sun, 11 Jan 2009 06:22:25 +1100
Subject: nice configure
In-Reply-To: <79A8A2E0-CE86-49ED-847A-77EBD00B7009@bellsouth.net>
References: <9B38B4DE-9601-4065-853A-9834062F4A06@macports.org>	<492C1356-29A4-43D4-A8AD-47CE5BBD22A9@bellsouth.net>	<799406d60901090546x590fbf47ic5e4e45e3834310@mail.gmail.com>
	<79A8A2E0-CE86-49ED-847A-77EBD00B7009@bellsouth.net>
Message-ID: <4968F571.6030102@macports.org>

William Davis wrote:
> 
> On Jan 9, 2009, at 8:46 AM, Adam Mercer wrote:
> 
>> On Thu, Jan 8, 2009 at 22:02, William Davis <frstan at bellsouth.net> wrote:
>>
>>> AFAIK the nice command has been broken for a very long time.  Just
>>> bring up
>>> Activity Monitor and check it out.  You will fine the %CPU used by
>>> "nice"
>>> processes is always zero (unless you are using a really old OS).
>>
>> Thats a bug in ActivityMonitor not reporting nice'd processes
>> properly, I have a bug open with Apple about this. If you use top on
>> the command line then the nice'd processes will be properly displayed.
>>
>> Cheers
>>
>> Adam
> 
> Really Adam?  Please show me where in this print of top I can see that:

I just tested on 10.5.6 by running 'nice nbench', and both Activity
Monitor and top show it using ~99% CPU...

- Josh

From jkh at apple.com  Sat Jan 10 13:55:37 2009
From: jkh at apple.com (Jordan K. Hubbard)
Date: Sat, 10 Jan 2009 13:55:37 -0800
Subject: nice configure
In-Reply-To: <4968F571.6030102@macports.org>
References: <9B38B4DE-9601-4065-853A-9834062F4A06@macports.org>
	<492C1356-29A4-43D4-A8AD-47CE5BBD22A9@bellsouth.net>
	<799406d60901090546x590fbf47ic5e4e45e3834310@mail.gmail.com>
	<79A8A2E0-CE86-49ED-847A-77EBD00B7009@bellsouth.net>
	<4968F571.6030102@macports.org>
Message-ID: <CE1B9608-7EBD-40F1-9765-03C9B226D49F@apple.com>


On Jan 10, 2009, at 11:22 AM, Joshua Root wrote:

> I just tested on 10.5.6 by running 'nice nbench', and both Activity
> Monitor and top show it using ~99% CPU...

A processes' nice factor can generally only be seen to produce results  
when there is enough contention for CPU resources that it *needs* to  
be "nice".  If there's little to no contention for CPU, however, then  
the nice'd process is still going to get pretty much whatever it asks  
for.

A much more realistic test would be to run n CPU-hungry processes,  
where n is > the number of cores you have, and then nice one of them.

- Jordan


From ram at macports.org  Sat Jan 10 14:31:03 2009
From: ram at macports.org (Adam Mercer)
Date: Sat, 10 Jan 2009 16:31:03 -0600
Subject: nice configure
In-Reply-To: <79A8A2E0-CE86-49ED-847A-77EBD00B7009@bellsouth.net>
References: <9B38B4DE-9601-4065-853A-9834062F4A06@macports.org>
	<492C1356-29A4-43D4-A8AD-47CE5BBD22A9@bellsouth.net>
	<799406d60901090546x590fbf47ic5e4e45e3834310@mail.gmail.com>
	<79A8A2E0-CE86-49ED-847A-77EBD00B7009@bellsouth.net>
Message-ID: <799406d60901101431n692dfb40v2d248b594a19ae42@mail.gmail.com>

On Sat, Jan 10, 2009 at 13:11, William Davis <frstan at bellsouth.net> wrote:

> Really Adam?  Please show me where in this print of top I can see that:

Sorry, ignore me. The terminal I was running top in when I wrote that
email was in an ssh session running on a Linux box, and top on linux
shows the nice factor.

Cheers

Adam

From ryandesign at macports.org  Sat Jan 10 19:00:23 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 10 Jan 2009 21:00:23 -0600
Subject: Using a password-protected mirror
Message-ID: <1C72E095-804F-4D42-BE94-A6492A40126F@macports.org>

Is there a way to use a password-protected mirror with MacPorts?


See, I've enjoyed using the new MacPorts 1.7.0 feature where you can  
easily add mirrors by editing dports/_resources/port1.0/fetch/ 
mirror_sites.tcl. I've set up each of the machines on my local  
network to make their distfiles available via http and have added  
their URLs to the file like this:


set portfetch::mirror_sites::sites(macports_distfiles) {
     http://machine1.local/distfiles/:mirror
     http://machine2.local/distfiles/:mirror
     http://distfiles.macports.org/:mirror
...


This works great: now if any of my machines already has the distfile  
downloaded, it'll get pulled from there instead of from the Internet.  
Neat.

But now I'd like to password-protect my servers. I've set up HTTP  
basic authentication and tried changing the mirror entries like this:


set portfetch::mirror_sites::sites(macports_distfiles) {
     http://username:password at machine1.local/distfiles/:mirror
     http://username:password at machine2.local/distfiles/:mirror
     http://distfiles.macports.org/:mirror
...


But this doesn't work.


--->  Fetching clex
DEBUG: Executing org.macports.fetch (clex)
--->  clex-4.0.tar.gz doesn't seem to exist in /mp/var/macports/ 
distfiles/clex
DEBUG: Pinging www.clex.sk...
DEBUG: Pinging usernameclex...
DEBUG: Pinging distfiles.macports.org...
DEBUG: Pinging trd.no.distfiles.macports.org...
DEBUG: Pinging arn.se.distfiles.macports.org...
DEBUG: www.clex.sk ping time is 164.769
DEBUG: usernameclex ping time is 55.002
DEBUG: distfiles.macports.org ping time is 63.104
DEBUG: trd.no.distfiles.macports.org ping time is 185.866
DEBUG: arn.se.distfiles.macports.org ping time is 169.125


See, it cut the URL at the colon after the username, and seems to  
have inserted the port name instead.


--->  Attempting to fetch clex-4.0.tar.gz from http://usernameclex
   % Total    % Received % Xferd  Average Speed   Time    Time      
Time  Current
                                  Dload  Upload   Total   Spent     
Left  Speed
21450   256  21450 42982    0     0  42783      0 --:--:--  0:00:01  
--:--:-- 42783
$ port checksum
--->  Verifying checksum(s) for clex
Error: Checksum (md5) mismatch for clex-4.0.tar.gz
Error: Checksum (sha1) mismatch for clex-4.0.tar.gz
Error: Checksum (rmd160) mismatch for clex-4.0.tar.gz
Error: Target org.macports.checksum returned: Unable to verify file  
checksums
Error: Status 1 encountered during processing.


And because my ISP has provided me with one of those wonderful DNS  
servers that can never say no, attempting to download from this  
nonexistent URL in fact succeeds with a 200 status code and gives me  
some awful search results page that I never wanted, so the checksums  
fail.

Sorry for that rant, I just hate those kinds of DNS servers so much.




From jmr at macports.org  Sun Jan 11 00:28:47 2009
From: jmr at macports.org (Joshua Root)
Date: Sun, 11 Jan 2009 19:28:47 +1100
Subject: Using a password-protected mirror
In-Reply-To: <1C72E095-804F-4D42-BE94-A6492A40126F@macports.org>
References: <1C72E095-804F-4D42-BE94-A6492A40126F@macports.org>
Message-ID: <4969ADBF.4060201@macports.org>

Ryan Schmidt wrote:
> set portfetch::mirror_sites::sites(macports_distfiles) {
>     http://username:password at machine1.local/distfiles/:mirror
>     http://username:password at machine2.local/distfiles/:mirror
>     http://distfiles.macports.org/:mirror
> ...
> 
> 
> But this doesn't work.
> 
> 
> --->  Fetching clex
> DEBUG: Executing org.macports.fetch (clex)
> --->  clex-4.0.tar.gz doesn't seem to exist in
> /mp/var/macports/distfiles/clex
> DEBUG: Pinging www.clex.sk...
> DEBUG: Pinging usernameclex...
> DEBUG: Pinging distfiles.macports.org...
> DEBUG: Pinging trd.no.distfiles.macports.org...
> DEBUG: Pinging arn.se.distfiles.macports.org...
> DEBUG: www.clex.sk ping time is 164.769
> DEBUG: usernameclex ping time is 55.002
> DEBUG: distfiles.macports.org ping time is 63.104
> DEBUG: trd.no.distfiles.macports.org ping time is 185.866
> DEBUG: arn.se.distfiles.macports.org ping time is 169.125
> 
> 
> See, it cut the URL at the colon after the username, and seems to have
> inserted the port name instead.

Colon is used as a marker to separate the URL from the tags. I think
this is what fetch.user and fetch.password are for. But of course they
can't be set globally.

- Josh

From jmr at macports.org  Sun Jan 11 00:32:39 2009
From: jmr at macports.org (Joshua Root)
Date: Sun, 11 Jan 2009 19:32:39 +1100
Subject: nice configure
In-Reply-To: <CE1B9608-7EBD-40F1-9765-03C9B226D49F@apple.com>
References: <9B38B4DE-9601-4065-853A-9834062F4A06@macports.org>
	<492C1356-29A4-43D4-A8AD-47CE5BBD22A9@bellsouth.net>
	<799406d60901090546x590fbf47ic5e4e45e3834310@mail.gmail.com>
	<79A8A2E0-CE86-49ED-847A-77EBD00B7009@bellsouth.net>
	<4968F571.6030102@macports.org>
	<CE1B9608-7EBD-40F1-9765-03C9B226D49F@apple.com>
Message-ID: <4969AEA7.90704@macports.org>

Jordan K. Hubbard wrote:
> 
> On Jan 10, 2009, at 11:22 AM, Joshua Root wrote:
> 
>> I just tested on 10.5.6 by running 'nice nbench', and both Activity
>> Monitor and top show it using ~99% CPU...
> 
> A processes' nice factor can generally only be seen to produce results
> when there is enough contention for CPU resources that it *needs* to be
> "nice".  If there's little to no contention for CPU, however, then the
> nice'd process is still going to get pretty much whatever it asks for.
> 
> A much more realistic test would be to run n CPU-hungry processes, where
> n is > the number of cores you have, and then nice one of them.

Are you saying that the problem only shows up when there is scheduling
contention? I realise that it's normal for this example to use all the
CPU despite being niced. It seemed like Adam and William were saying
that any nice process will show 0% CPU usage.

- Josh

From jmr at macports.org  Sun Jan 11 00:41:18 2009
From: jmr at macports.org (Joshua Root)
Date: Sun, 11 Jan 2009 19:41:18 +1100
Subject: nice configure
In-Reply-To: <4969AEA7.90704@macports.org>
References: <9B38B4DE-9601-4065-853A-9834062F4A06@macports.org>	<492C1356-29A4-43D4-A8AD-47CE5BBD22A9@bellsouth.net>	<799406d60901090546x590fbf47ic5e4e45e3834310@mail.gmail.com>	<79A8A2E0-CE86-49ED-847A-77EBD00B7009@bellsouth.net>	<4968F571.6030102@macports.org>	<CE1B9608-7EBD-40F1-9765-03C9B226D49F@apple.com>
	<4969AEA7.90704@macports.org>
Message-ID: <4969B0AE.3020805@macports.org>

Joshua Root wrote:
> Jordan K. Hubbard wrote:
>> On Jan 10, 2009, at 11:22 AM, Joshua Root wrote:
>>
>>> I just tested on 10.5.6 by running 'nice nbench', and both Activity
>>> Monitor and top show it using ~99% CPU...
>> A processes' nice factor can generally only be seen to produce results
>> when there is enough contention for CPU resources that it *needs* to be
>> "nice".  If there's little to no contention for CPU, however, then the
>> nice'd process is still going to get pretty much whatever it asks for.
>>
>> A much more realistic test would be to run n CPU-hungry processes, where
>> n is > the number of cores you have, and then nice one of them.
> 
> Are you saying that the problem only shows up when there is scheduling
> contention? I realise that it's normal for this example to use all the
> CPU despite being niced. It seemed like Adam and William were saying
> that any nice process will show 0% CPU usage.

Running 5 nbench instances, one of which is niced, on a 4-core machine:

 PID COMMAND      %CPU   TIME   #TH #PRTS #MREGS RPRVT  RSHRD  RSIZE  VSIZE
70605 top          8.3%  0:01.74   1    18     29  560K   200K  1156K
 18M
70604 nbench      58.9%  0:11.67   1    13     16  140K   232K   376K
 20M
70602 nbench      78.8%  0:20.36   1    13     16  140K   232K   376K
 20M
70600 nbench      81.9%  0:23.64   1    13     16  140K   232K   376K
 20M
70599 nbench      79.6%  0:26.08   1    13     16  140K   232K   376K
 20M
70598 nbench      79.8%  0:28.34   1    13     15   84K   232K   328K
 20M

Seems to be exactly as expected, and Activity Monitor shows essentially
the same numbers (they fluctuate a little of course).

- Josh

From raimue at macports.org  Sun Jan 11 06:31:13 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sun, 11 Jan 2009 15:31:13 +0100
Subject: selfupdate and readline support
Message-ID: <496A02B1.6020100@macports.org>

Hello,

The readline support for MacPorts is disabled by default and has to be
enabled using --enable-readline. The release disk images we release are
built with support for that. But on running selfupdate, there is no
--enable-readline in the default configure flags, no matter if the
currently installed version supports readline or not. So everyone
updating using selfupdate will have port without readline support.

What was the reason again to make readline not the default? Is this also
the same reason why it is not enabled in selfupdate?

Rainer

From jmr at macports.org  Sun Jan 11 07:03:50 2009
From: jmr at macports.org (Joshua Root)
Date: Mon, 12 Jan 2009 02:03:50 +1100
Subject: selfupdate and readline support
In-Reply-To: <496A02B1.6020100@macports.org>
References: <496A02B1.6020100@macports.org>
Message-ID: <496A0A56.4000607@macports.org>

Rainer M?ller wrote:
> Hello,
> 
> The readline support for MacPorts is disabled by default and has to be
> enabled using --enable-readline. The release disk images we release are
> built with support for that. But on running selfupdate, there is no
> --enable-readline in the default configure flags, no matter if the
> currently installed version supports readline or not. So everyone
> updating using selfupdate will have port without readline support.
> 
> What was the reason again to make readline not the default? Is this also
> the same reason why it is not enabled in selfupdate?

This thread is what led to readline being disabled by default:
<http://lists.macosforge.org/pipermail/macports-users/2007-November/006973.html>

- Josh

From raimue at macports.org  Sun Jan 11 09:44:23 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Sun, 11 Jan 2009 18:44:23 +0100
Subject: [44827] trunk/dports/lang/python25/Portfile
In-Reply-To: <20090103095740.C5B1EB2C88B@beta.macosforge.org>
References: <20090103095740.C5B1EB2C88B@beta.macosforge.org>
Message-ID: <496A2FF7.7050500@macports.org>

afb at macports.org wrote:
> Revision: 44827
>           http://trac.macports.org/changeset/44827
> Author:   afb at macports.org
> Date:     2009-01-03 01:57:38 -0800 (Sat, 03 Jan 2009)
> Log Message:
> -----------
> add +puredarwin platform variant (#16863)
> 
> Modified Paths:
> --------------
>     trunk/dports/lang/python25/Portfile
> 
> Modified: trunk/dports/lang/python25/Portfile
> ===================================================================
> --- trunk/dports/lang/python25/Portfile	2009-01-03 08:51:47 UTC (rev 44826)
> +++ trunk/dports/lang/python25/Portfile	2009-01-03 09:57:38 UTC (rev 44827)
> @@ -66,6 +66,7 @@
>  
>  destroot.target         frameworkinstall maninstall
>  
> +platform macosx {
>  post-destroot {
>          set framewpath ${frameworks_dir}/Python.framework
>          set framewdir  ${framewpath}/Versions/${branch}
> @@ -96,6 +97,7 @@
>          xinstall -m 755 -d ${destroot}${prefix}/etc/select/python
>          xinstall -m 644 ${filespath}/python[string map {. {}} ${branch}] ${destroot}${prefix}/etc/select/python/
>  }
> +}

Adding this platform results in the following error message on upgrade
on Mac OS X:

  Warning: Skipping upgrade since python25 2.5.4_0 >= python25 2.5.4_0,
  even though installed variant +darwin_9 does not match
  +darwin_9+macosx. Specify -f to force upgrade.

I think the revision should have been bumped, right?

Rainer

From afb at macports.org  Sun Jan 11 10:32:49 2009
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Sun, 11 Jan 2009 19:32:49 +0100
Subject: [44827] trunk/dports/lang/python25/Portfile
In-Reply-To: <496A2FF7.7050500@macports.org>
References: <20090103095740.C5B1EB2C88B@beta.macosforge.org>
	<496A2FF7.7050500@macports.org>
Message-ID: <1E762118-531B-4E85-90C1-C8FFF513F696@macports.org>

Rainer M?ller:

> Adding this platform results in the following error message on upgrade
> on Mac OS X:
>
>   Warning: Skipping upgrade since python25 2.5.4_0 >= python25  
> 2.5.4_0,
>   even though installed variant +darwin_9 does not match
>   +darwin_9+macosx. Specify -f to force upgrade.
>
> I think the revision should have been bumped, right?

Probably. Then again, nothing was changed so skipping it is alright too.
i.e. bumping the revision just causes a rebuild of an identical  
version ?

--anders


From blair at orcaware.com  Sun Jan 11 13:16:46 2009
From: blair at orcaware.com (Blair Zajac)
Date: Sun, 11 Jan 2009 13:16:46 -0800
Subject: [44914] trunk/dports/devel/git-core/Portfile
In-Reply-To: <496793D5.6040304@orcaware.com>
References: <20090104195028.76C93B41DF7@beta.macosforge.org>
	<4967673B.1070806@macports.org> <496793D5.6040304@orcaware.com>
Message-ID: <09CEF256-185E-46EA-AC10-583CEF074CAA@orcaware.com>


On Jan 9, 2009, at 10:13 AM, Blair Zajac wrote:

> Joshua Root wrote:
>> blair at macports.org wrote:
>>> Revision: 44914
>>>          http://trac.macports.org/changeset/44914
>>> Author:   blair at macports.org
>>> Date:     2009-01-04 11:50:27 -0800 (Sun, 04 Jan 2009)
>>> Log Message:
>>> -----------
>>> Add a depends_build on p5-scalar-list-utils.  Without this, the
>>> installation fails when Scalar::Util cannot be found.
>>>
>>> Modified Paths:
>>> --------------
>>>    trunk/dports/devel/git-core/Portfile
>>>
>>> Modified: trunk/dports/devel/git-core/Portfile
>>> ===================================================================
>>> --- trunk/dports/devel/git-core/Portfile	2009-01-04 18:52:21 UTC  
>>> (rev 44913)
>>> +++ trunk/dports/devel/git-core/Portfile	2009-01-04 19:50:27 UTC  
>>> (rev 44914)
>>> @@ -4,6 +4,7 @@
>>>  name              git-core
>>> version           1.6.1
>>> +revision          1
>>> description       A fast version control system
>>> long_description  Git is a fast, scalable, distributed open source  
>>> version \
>>>                   control system focusing on speed and efficiency.
>>> @@ -22,6 +23,7 @@
>>> checksums    git-${version}${extract.suffix} sha1  
>>> 4caeafd06a5482337052f142073be66f2a39134a \
>>>              git-manpages-${version}${extract.suffix} sha1  
>>> fa2d94dc966484b14ae11d39d0d8336946a93001
>>> +depends_build port:p5-scalar-list-utils
>> The p5-scalar-list-utils port conflicts with perl5.8, and git-core  
>> seems
>> to build fine without that dependency. Maybe the update to perl 5.8.9
>> made this happen.
>
> It looks like perl 5.8.9 now includes Scalar::List::Utils so we  
> could drop that dependency.  I was having issues installing git-core  
> with 5.8.8.
>
> Blair

Fixed in r45236.  I only removed the depend_build and didn't increment  
the revision number since it's only a depends_build.

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  Sun Jan 11 17:07:13 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 11 Jan 2009 19:07:13 -0600
Subject: [45214] trunk/dports/devel/gmp/Portfile
In-Reply-To: <20090111084044.5630EBF02EC@beta.macosforge.org>
References: <20090111084044.5630EBF02EC@beta.macosforge.org>
Message-ID: <37616966-BDEA-4C7B-AE2F-C7250CACDFA7@macports.org>


On Jan 11, 2009, at 02:40, mcalhoun at macports.org wrote:

> -platform i386 {
> -    configure.env-delete    ABI=32
> -    configure.args-append   --host=none-apple-darwin
> -    configure.cflags-delete -force_cpusubtype_ALL
> +platform ppc {
> +    configure.cflags-append -force_cpusubtype_ALL
>  }

There is no "platform ppc"; it's "platform powerpc".


From ryandesign at macports.org  Sun Jan 11 22:38:31 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 12 Jan 2009 00:38:31 -0600
Subject: [45250] trunk/dports
In-Reply-To: <20090112035404.38366C04189@beta.macosforge.org>
References: <20090112035404.38366C04189@beta.macosforge.org>
Message-ID: <C29D9F59-D97C-4D37-9C81-4BD2B4C081BB@macports.org>

On Jan 11, 2009, at 21:54, illogic-al at macports.org wrote:

> Revision: 45250
>           http://trac.macports.org/changeset/45250
> Author:   illogic-al at macports.org
> Date:     2009-01-11 19:54:03 -0800 (Sun, 11 Jan 2009)
> Log Message:
> -----------
> Obfuscate.

[snip]

> Modified: trunk/dports/kde/ktorrent/Portfile
> ===================================================================
> --- trunk/dports/kde/ktorrent/Portfile	2009-01-12 02:11:05 UTC (rev  
> 45249)
> +++ trunk/dports/kde/ktorrent/Portfile	2009-01-12 03:54:03 UTC (rev  
> 45250)
> @@ -6,7 +6,7 @@
>  version             3.1.5
>  revision            1
>  categories          kde kde4
> -maintainers         illogic-al at macports.org openmaintainer
> +maintainers         illogic-al openmaintainer
>  description         KDE4 bittorrent client.
>  long_description    Bittorrent client for KDE4 supporting a  
> variety of \
>                      features such as uPNP.
> @@ -19,7 +19,7 @@
>  depends_lib         path:${prefix}/bin/kde4:kdebase4-runtime \
>                      port:qca port:gmp
>
> -depends_build       port:cmake
> +depends_build       port:cmake port:automoc

Did you also mean to add this build dependency to ktorrent?



From blb at macports.org  Sun Jan 11 22:54:09 2009
From: blb at macports.org (Bryan Blackburn)
Date: Sun, 11 Jan 2009 23:54:09 -0700
Subject: MacPorts Special Interest Group for Python
In-Reply-To: <90bb445a0901030736t374fead3wfa36178f836b41e1@mail.gmail.com>
References: <90bb445a0901020753m13a774a4g7a01ecf53476c145@mail.gmail.com>
	<90bb445a0901030736t374fead3wfa36178f836b41e1@mail.gmail.com>
Message-ID: <20090112065409.GJ656@ninagal.withay.com>

On Sat, Jan 3, 2009 at 12:53 AM, Akira Kitada wrote:
> Hi Python maintainers,
>
> I would like to propose that MacPorts should have an "interest group"
> for Python.
> MacPorts has been adding many Python ports to its collection,
> but they are rather individual works and lacks the plan for the long term.

I definitely like the idea of having more than one person to handle each of
the base python ports themselves (as well as other, similar ports like
perl, ruby, etc), since these can take some work to maintain and are a
critical part of the dependency chain for many other ports.

As far as a separate group for more big-picture stuff, I'm not sure we
really need that.  The -dev list here isn't exactly a really high traffic
list and python-specific discussion isn't going to be major, at least once a
few decisions can be made.

Hitting your points:

>
> The group will
> - Plan and mark specific version of Python as "default".

This affects a large number of ports above python itself, so shouldn't be
chosen without input from maintainers who have such ports (like mercurial,
bindings for subversion, and dozens of others).  Some applications most
likely won't be working with a newer version when it is first available (eg,
how many currently work with 2.6, let alone 3.0, right now?).

> - Provide Template Portfile for Python modules.

To some degree, the group code should take care of this, once we get a few
more bits moved into it.

> - Share Python related problems and solutions.
> - Write Python ports specific documentations.
> - has a lead for Python ports, who makes decisions.
> - etc, etc.

In my opinion, these all fall into my thinking that -dev would be better,
since bits of these points are going to affect those who aren't involved
with python* or py-* ports directly, but apps which use them.  Since they'll
have different viewpoints and different needs, it only makes sense to try
and bring the larger group of -dev into it.

>
> What do you think of this idea?

What the python stuff needs most right now is consistency (as you've noticed
before).  The most immediate is to decide on how best to handle module ports
which install the same-named files (bin/foo for py25-foo and py26-foo) and
associated files (like man pages).  This can then be put into the group code
so that Portfile authors can do something like

python.install_bin   foo

and the rest (renaming to foo-2.5 or foo-2.6 as necessary) can happen
automagically.

After that, making the base python ports more consistent is needed.

Anyone else have thoughts/observations/complaints?

Bryan


>
> Thanks,
>

From mcalhoun at macports.org  Mon Jan 12 00:43:43 2009
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Mon, 12 Jan 2009 08:43:43 +0000 (UTC)
Subject: [45214] trunk/dports/devel/gmp/Portfile
References: <20090111084044.5630EBF02EC@beta.macosforge.org>
	<37616966-BDEA-4C7B-AE2F-C7250CACDFA7@macports.org>
Message-ID: <loom.20090112T084001-852@post.gmane.org>

Ryan Schmidt <ryandesign at ...> writes:

> 
> There is no "platform ppc"; it's "platform powerpc".
> 

Thank you for pointing this out.
It was fixed in r45254.

-Marcus


From mcalhoun at macports.org  Mon Jan 12 13:19:06 2009
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Mon, 12 Jan 2009 21:19:06 +0000 (UTC)
Subject: A PortGroup for building more 32/64-bit universal packages
Message-ID: <loom.20090112T211017-72@post.gmane.org>

I have a need of more 32/64-bit universal packages.
To facilitate this, I would like to propose a PortGroup with a different
universal build mechanism than the default.
See http://trac.macports.org/ticket/17972.

It is intended to be an improvement of the merge function.

Any feedback would be greatly appreciated.
The only time I write in Tcl is on MacPorts related projects.

-Marcus




From kw at codebykevin.com  Mon Jan 12 15:07:52 2009
From: kw at codebykevin.com (Kevin Walzer)
Date: Mon, 12 Jan 2009 18:07:52 -0500
Subject: PortAuthority 2.7 released
Message-ID: <496BCD48.1010605@codebykevin.com>

Code by Kevin has released PortAuthority 2.7, a GUI for the MacPorts 
package management system for Mac OS X.

PortAuthority provides a graphical user interface for the MacPorts 
package management system for Mac OS X. MacPorts is a powerful 
command-line tool for installing and updating a variety of Unix-based 
applications for the Mac. Its power, though, comes at the cost of some 
complexity; in the past the only way to utilize MacPorts was to type in 
various commands into the Mac's Terminal application, which can be 
intimidating for those users without a Unix background.

PortAuthority aims to bring the power of MacPorts to the traditional Mac 
user by providing a user-friendly graphical interface to MacPorts. Using 
a familiar combination of windows, icons, and menus, PortAuthority users 
can search, install, update, and remove MacPorts programs and the 
MacPorts infrastructure itself.

Among the features and improvements in this release:

* Bug fix: Demo version no longer crashes on initial startup.

* Can now print log output to default printer.

* Now uses integrated help viewer.

* Saves window position on application close.

* New graphics engine for improved UI appearance.

PortAuthority is shareware; a license costs $24.95 and a 30-day demo is 
available. Mac OS X 10.4 is the minimum supported OS. PortAuthority is a 
universal binary.

For more information about PortAuthority, including download links, see 
http://www.codebykevin.com/portauthority.html.
-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

From ryandesign at macports.org  Mon Jan 12 16:35:35 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 12 Jan 2009 18:35:35 -0600
Subject: [45280] trunk/dports/x11/gtk2/Portfile
In-Reply-To: <20090112190137.39DF5C14EE6@beta.macosforge.org>
References: <20090112190137.39DF5C14EE6@beta.macosforge.org>
Message-ID: <100D3E6A-9599-43ED-B7F3-B2A129102AD7@macports.org>

On Jan 12, 2009, at 13:01, jmr at macports.org wrote:

> Revision: 45280
>           http://trac.macports.org/changeset/45280
> Author:   jmr at macports.org
> Date:     2009-01-12 11:01:36 -0800 (Mon, 12 Jan 2009)
> Log Message:
> -----------
> gtk2: remove -no-cpp-precomp because it's obsolete, and -funroll- 
> loops because it's more likely to make things slower

And the revision should be bumped so everyone gets the faster build,  
yes?


From ryandesign at macports.org  Mon Jan 12 16:41:14 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 12 Jan 2009 18:41:14 -0600
Subject: Wiki-like markup for Guide
In-Reply-To: <20090112131511.2738E2808F@relay13.apple.com>
References: <20090112131511.2738E2808F@relay13.apple.com>
Message-ID: <42A2A3A0-DC6D-45A4-A901-E3566A5375FC@macports.org>

On Jan 12, 2009, at 07:15, MacPorts wrote:

> + 1. make guide use a reasonable (wiki-like) markup, not docbook-xml.

I think we like our docbook-xml Guide... a lot of work was put into  
getting it the way it is. What objections do you have to the way it's  
being done now? Let's discuss.


From ryandesign at macports.org  Mon Jan 12 16:47:29 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 12 Jan 2009 18:47:29 -0600
Subject: [45273] trunk/dports/math
In-Reply-To: <20090112172415.4D67EC12D32@beta.macosforge.org>
References: <20090112172415.4D67EC12D32@beta.macosforge.org>
Message-ID: <BCB9F0AE-F99B-441E-AAE7-63A5E377018E@macports.org>

On Jan 12, 2009, at 11:24, devans at macports.org wrote:

> --- trunk/dports/math/libqalculate/Portfile	                         
> (rev 0)
> +++ trunk/dports/math/libqalculate/Portfile	2009-01-12 17:24:14 UTC  
> (rev 45273)
[snip]
> +depends_lib	port:cln\
> +		port:libxml2\
> +		port:glib2\
> +		lib:libreadline:readline

Should always use MacPorts readline, so this should be  
"port:readline" and then make sure the port actually does use  
MacPorts readline.


> --- trunk/dports/math/qalculate-gtk/ 
> Portfile	                        (rev 0)
> +++ trunk/dports/math/qalculate-gtk/Portfile	2009-01-12 17:24:14  
> UTC (rev 45273)
[snip]
> +variant yelp description {Provides GUI help via yelp} {
> +	depends_run-append	port:yelp\
> +				port:libgnome
> +}

A variant must do more than just add a dependency. It must also  
instruct the software (e.g. via a configure argument) that it is ok  
to use these extra libraries. Or put another way: the software must  
not attempt to use these libraries if this variant is not selected,  
even if those libraries were coincidentally already installed.


From ryandesign at macports.org  Mon Jan 12 16:56:15 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 12 Jan 2009 18:56:15 -0600
Subject: [45250] trunk/dports
In-Reply-To: <C1BC07A1-F614-4918-AC98-447786B41660@gmail.com>
References: <20090112035404.38366C04189@beta.macosforge.org>
	<C29D9F59-D97C-4D37-9C81-4BD2B4C081BB@macports.org>
	<C1BC07A1-F614-4918-AC98-447786B41660@gmail.com>
Message-ID: <80DD1A2B-21DF-4818-804D-364E2D92A872@macports.org>

On Jan 12, 2009, at 08:53, Orville Bennett wrote:

> On Jan 12, 2009, at 1:38 AM, Ryan Schmidt wrote:
>
>> On Jan 11, 2009, at 21:54, illogic-al at macports.org wrote:
>>
>>> Revision: 45250
>>>          http://trac.macports.org/changeset/45250
>>> Author:   illogic-al at macports.org
>>> Date:     2009-01-11 19:54:03 -0800 (Sun, 11 Jan 2009)
>>> Log Message:
>>> -----------
>>> Obfuscate.
>>
>> [snip]
>>
>>> Modified: trunk/dports/kde/ktorrent/Portfile
>>> ===================================================================
>>> --- trunk/dports/kde/ktorrent/Portfile	2009-01-12 02:11:05 UTC  
>>> (rev 45249)
>>> +++ trunk/dports/kde/ktorrent/Portfile	2009-01-12 03:54:03 UTC  
>>> (rev 45250)
>>> @@ -6,7 +6,7 @@
>>> version             3.1.5
>>> revision            1
>>> categories          kde kde4
>>> -maintainers         illogic-al at macports.org openmaintainer
>>> +maintainers         illogic-al openmaintainer
>>> description         KDE4 bittorrent client.
>>> long_description    Bittorrent client for KDE4 supporting a  
>>> variety of \
>>>                     features such as uPNP.
>>> @@ -19,7 +19,7 @@
>>> depends_lib         path:${prefix}/bin/kde4:kdebase4-runtime \
>>>                     port:qca port:gmp
>>>
>>> -depends_build       port:cmake
>>> +depends_build       port:cmake port:automoc
>>
>> Did you also mean to add this build dependency to ktorrent?
>
> yip. snuck that one in there :-)

Ok, then please revise the log message for r45250 to indicate that  
you also meant to do that. Otherwise what you say you changed and  
what you actually changed don't match, and someone looking through  
the history might be confused. Here's how you can do this:


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




From raimue at macports.org  Mon Jan 12 16:58:24 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Tue, 13 Jan 2009 01:58:24 +0100
Subject: selfupdate and readline support
In-Reply-To: <496A0A56.4000607@macports.org>
References: <496A02B1.6020100@macports.org> <496A0A56.4000607@macports.org>
Message-ID: <496BE730.8050304@macports.org>

Joshua Root wrote:
> This thread is what led to readline being disabled by default:
> <http://lists.macosforge.org/pipermail/macports-users/2007-November/006973.html>

So anyone who wants readline support should just install from the disk
images? I think most people do not use the interactive port shell at all
and do not need readline, therefore this should be a reasonable decision.

Thanks for digging in the archives for me ;-)

Rainer

From blair at orcaware.com  Mon Jan 12 17:01:39 2009
From: blair at orcaware.com (Blair Zajac)
Date: Mon, 12 Jan 2009 17:01:39 -0800
Subject: selfupdate and readline support
In-Reply-To: <496BE730.8050304@macports.org>
References: <496A02B1.6020100@macports.org> <496A0A56.4000607@macports.org>
	<496BE730.8050304@macports.org>
Message-ID: <496BE7F3.8000409@orcaware.com>

Rainer M?ller wrote:
> Joshua Root wrote:
>> This thread is what led to readline being disabled by default:
>> <http://lists.macosforge.org/pipermail/macports-users/2007-November/006973.html>
> 
> So anyone who wants readline support should just install from the disk
> images? I think most people do not use the interactive port shell at all
> and do not need readline, therefore this should be a reasonable decision.
> 
> Thanks for digging in the archives for me ;-)

You can always wrap the interactive command with rlwrap or ledit to get history 
and in-line editing also.

Blair


From jkh at apple.com  Mon Jan 12 18:13:47 2009
From: jkh at apple.com (Jordan K. Hubbard)
Date: Mon, 12 Jan 2009 18:13:47 -0800
Subject: A PortGroup for building more 32/64-bit universal packages
In-Reply-To: <loom.20090112T211017-72@post.gmane.org>
References: <loom.20090112T211017-72@post.gmane.org>
Message-ID: <992D602D-D4B6-4C80-BB01-EF3B80AE0BF2@apple.com>

Another interesting point about the default universal arches is that  
today, they're set to "i386 ppc" whereas "the future" would tend to  
suggest that "i386 x86_64" will be a better choice, so at some point  
the defaults are also going to have to change.  Is this a knob that we  
currently support setting on a site-specific basis?

- Jordan

On Jan 12, 2009, at 1:19 PM, Marcus Calhoun-Lopez wrote:

> I have a need of more 32/64-bit universal packages.
> To facilitate this, I would like to propose a PortGroup with a  
> different
> universal build mechanism than the default.
> See http://trac.macports.org/ticket/17972.
>
> It is intended to be an improvement of the merge function.
>
> Any feedback would be greatly appreciated.
> The only time I write in Tcl is on MacPorts related projects.
>
> -Marcus
>
>
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


From blb at macports.org  Mon Jan 12 18:26:10 2009
From: blb at macports.org (Bryan Blackburn)
Date: Mon, 12 Jan 2009 19:26:10 -0700
Subject: A PortGroup for building more 32/64-bit universal packages
In-Reply-To: <992D602D-D4B6-4C80-BB01-EF3B80AE0BF2@apple.com>
References: <loom.20090112T211017-72@post.gmane.org>
	<992D602D-D4B6-4C80-BB01-EF3B80AE0BF2@apple.com>
Message-ID: <20090113022610.GC774@ninagal.withay.com>

On Mon, Jan 12, 2009 at 06:13:47PM -0800, Jordan K. Hubbard said:
> Another interesting point about the default universal arches is that  
> today, they're set to "i386 ppc" whereas "the future" would tend to  
> suggest that "i386 x86_64" will be a better choice, so at some point the 
> defaults are also going to have to change.  Is this a knob that we  
> currently support setting on a site-specific basis?

universal_archs in etc/macports/macports.conf is probably what you're
looking for; setting to 'i386 x86_64' and building +universal does work, for
at least those ports that can build 64bit.

Bryan


>
> - Jordan
>
> On Jan 12, 2009, at 1:19 PM, Marcus Calhoun-Lopez wrote:
>
>> I have a need of more 32/64-bit universal packages.
>> To facilitate this, I would like to propose a PortGroup with a  
>> different
>> universal build mechanism than the default.
>> See http://trac.macports.org/ticket/17972.
>>
>> It is intended to be an improvement of the merge function.
>>
>> Any feedback would be greatly appreciated.
>> The only time I write in Tcl is on MacPorts related projects.
>>
>> -Marcus
>>

From ryandesign at macports.org  Mon Jan 12 20:38:44 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 12 Jan 2009 22:38:44 -0600
Subject: selfupdate and readline support
In-Reply-To: <496BE7F3.8000409@orcaware.com>
References: <496A02B1.6020100@macports.org> <496A0A56.4000607@macports.org>
	<496BE730.8050304@macports.org> <496BE7F3.8000409@orcaware.com>
Message-ID: <594EECDD-F7C9-4FDF-BA75-1862B4B0766A@macports.org>


On Jan 12, 2009, at 19:01, Blair Zajac wrote:

> Rainer M?ller wrote:
>> Joshua Root wrote:
>>> This thread is what led to readline being disabled by default:
>>> <http://lists.macosforge.org/pipermail/macports-users/2007- 
>>> November/006973.html>
>> So anyone who wants readline support should just install from the  
>> disk
>> images? I think most people do not use the interactive port shell  
>> at all
>> and do not need readline, therefore this should be a reasonable  
>> decision.
>> Thanks for digging in the archives for me ;-)

I think it's wrong that we ship binaries that enable readline, and  
then a selfupdate disables readline again. The selfupdate should keep  
the readline support enabled. Thanks for pointing out this problem.

> You can always wrap the interactive command with rlwrap or ledit to  
> get history and in-line editing also.

That's a workaround only, not a solution.

To summarize the November 2007 thread, the --enable-readline switch  
to MacPorts' configure script can cause the build to fail with a  
weird error if the user has installed another version of readline in  
the prefix /usr/local. In that particular case, the user had a  
PowerPC version of readline on their Intel Mac that had been migrated  
there from an older Mac by Apple's Migration Assistant. The user may  
not know or remember that they installed readline there. Because  
similar issues were affecting other users, readline was disabled by  
default.

I said then [1], and still say now, that we need a more general  
solution that makes MacPorts display a warning to the user if they  
install software in the prefix /usr/local. We have never supported  
the user installing software in the prefix /usr/local [2] and it  
causes problems in many more situations than this. MacPorts should  
actively inform users that they are doing things they should not, and  
how to correct them (even if that's only by providing a link to a FAQ  
entry or Guide section).

[1] http://lists.macosforge.org/pipermail/macports-users/2007- 
November/006982.html

[2] http://trac.macports.org/ticket/15077




From ryandesign at macports.org  Mon Jan 12 22:11:36 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 13 Jan 2009 00:11:36 -0600
Subject: Using a password-protected mirror
In-Reply-To: <4969ADBF.4060201@macports.org>
References: <1C72E095-804F-4D42-BE94-A6492A40126F@macports.org>
	<4969ADBF.4060201@macports.org>
Message-ID: <045A8DEE-DAFC-4798-BD8E-4CAE95E6CFA4@macports.org>

On Jan 11, 2009, at 02:28, Joshua Root wrote:

>> See, it cut the URL at the colon after the username, and seems to  
>> have
>> inserted the port name instead.
>
> Colon is used as a marker to separate the URL from the tags. I think
> this is what fetch.user and fetch.password are for. But of course they
> can't be set globally.

I doubt we'll have any official mirrors that need passwords, so I'll  
reconfigure my private web servers to password-protect everything  
except for the distfiles URL.


From jmr at macports.org  Tue Jan 13 00:24:02 2009
From: jmr at macports.org (Joshua Root)
Date: Tue, 13 Jan 2009 19:24:02 +1100
Subject: [45280] trunk/dports/x11/gtk2/Portfile
In-Reply-To: <100D3E6A-9599-43ED-B7F3-B2A129102AD7@macports.org>
References: <20090112190137.39DF5C14EE6@beta.macosforge.org>
	<100D3E6A-9599-43ED-B7F3-B2A129102AD7@macports.org>
Message-ID: <496C4FA2.7060501@macports.org>

Ryan Schmidt wrote:
> On Jan 12, 2009, at 13:01, jmr at macports.org wrote:
> 
>> Revision: 45280
>>           http://trac.macports.org/changeset/45280
>> Author:   jmr at macports.org
>> Date:     2009-01-12 11:01:36 -0800 (Mon, 12 Jan 2009)
>> Log Message:
>> -----------
>> gtk2: remove -no-cpp-precomp because it's obsolete, and -funroll-loops
>> because it's more likely to make things slower
> 
> And the revision should be bumped so everyone gets the faster build, yes?

I doubt the time saved by the faster build during its lifetime would be
greater than the time taken to rebuild.

- Josh

From florian.ebeling at gmail.com  Tue Jan 13 02:04:10 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Tue, 13 Jan 2009 11:04:10 +0100
Subject: Wiki-like markup for Guide
In-Reply-To: <42A2A3A0-DC6D-45A4-A901-E3566A5375FC@macports.org>
References: <20090112131511.2738E2808F@relay13.apple.com>
	<42A2A3A0-DC6D-45A4-A901-E3566A5375FC@macports.org>
Message-ID: <5cbbe4ae0901130204w77a877e6r8498a3f1dca65632@mail.gmail.com>

On Tue, Jan 13, 2009 at 1:41 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Jan 12, 2009, at 07:15, MacPorts wrote:
>
>> + 1. make guide use a reasonable (wiki-like) markup, not docbook-xml.
>
> I think we like our docbook-xml Guide... a lot of work was put into getting
> it the way it is. What objections do you have to the way it's being done
> now? Let's discuss.

I dislike editing XML, because it is so quirky. And I dislike docbook-xml
because it has this vast vocabulary, which few poeple really use. Only a very
small subset of it is used in the guide. And this makes it hard for
new or occasional
contributers (like me) to help. I think there are solutions out there
that don't force
me to think about online and offline document type definitions, well-formedness
of ampersands, and if I can nest a certain element at this tree position.
I find thinking of a text as a tree quite unnatural. Why not keep it as
a stream of characters? But xml forces one to look at it as a tree.

Mark once kindly offered me to accept text changes and make the actual editing.
That's very generous. I'm sure he offers that to everyone else as well.
But that still feels a bit indirect, and I don't really want to bother
somebody else
with a small change. I guess others are reluctant to do so as well. Still the
many but small changes are the important asset in any open source project,
and they are the means to get tedious work like documentation done.

So a simple and straightforward, maybe even well-known markup as wikis
tend to use them might help. I know about all the semantics and the structure
arguments, and that the rendering is a separate matter. But
documenting should not become
harder than just writing an understandable text, which is hard enough
in it's own right.

So, these are my points against docbook. OTOH, if the majority is happy with
the current setup, then let's leave it as it is, by all means. But if not, then
such a change might help to get more contributions here, and thereby more
current documentation.

Florian

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

From ryandesign at macports.org  Tue Jan 13 03:38:18 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 13 Jan 2009 05:38:18 -0600
Subject: make sure the LP64 patch sticks
In-Reply-To: <20090113101749.5E924C23532@beta.macosforge.org>
References: <20090113101749.5E924C23532@beta.macosforge.org>
Message-ID: <0E255956-2049-4C18-976C-D2241B9217B9@macports.org>


On Jan 13, 2009, at 04:17, jmr at macports.org wrote:

> Revision: 45300
>           http://trac.macports.org/changeset/45300
> Author:   jmr at macports.org
> Date:     2009-01-13 02:17:46 -0800 (Tue, 13 Jan 2009)
> Log Message:
> -----------
> dbus: make sure the LP64 patch sticks
>
> Modified Paths:
> --------------
>     trunk/dports/devel/dbus/Portfile
>
> Modified: trunk/dports/devel/dbus/Portfile
> ===================================================================
> --- trunk/dports/devel/dbus/Portfile	2009-01-13 08:51:58 UTC (rev  
> 45299)
> +++ trunk/dports/devel/dbus/Portfile	2009-01-13 10:17:46 UTC (rev  
> 45300)
> @@ -41,7 +41,7 @@
>
>  post-configure {
>      if {[variant_isset universal] && [lsearch -glob $ 
> {universal_archs} *64] != -1} {
> -        system "cd ${worksrcpath} && patch -p0 < ${filespath}/ 
> patch-config.h.diff"
> +        system "cd ${worksrcpath} && patch -p0 < ${filespath}/ 
> patch-config.h.diff && touch stamp-h1"
>      }
>  }

Could you elaborate on what this is doing? I'm curious. :)



From jmr at macports.org  Tue Jan 13 04:35:29 2009
From: jmr at macports.org (Joshua Root)
Date: Tue, 13 Jan 2009 23:35:29 +1100
Subject: make sure the LP64 patch sticks
In-Reply-To: <0E255956-2049-4C18-976C-D2241B9217B9@macports.org>
References: <20090113101749.5E924C23532@beta.macosforge.org>
	<0E255956-2049-4C18-976C-D2241B9217B9@macports.org>
Message-ID: <496C8A91.1000702@macports.org>

Ryan Schmidt wrote:
> 
> On Jan 13, 2009, at 04:17, jmr at macports.org wrote:
> 
>> Revision: 45300
>>           http://trac.macports.org/changeset/45300
>> Author:   jmr at macports.org
>> Date:     2009-01-13 02:17:46 -0800 (Tue, 13 Jan 2009)
>> Log Message:
>> -----------
>> dbus: make sure the LP64 patch sticks
>>
>> Modified Paths:
>> --------------
>>     trunk/dports/devel/dbus/Portfile
>>
>> Modified: trunk/dports/devel/dbus/Portfile
>> ===================================================================
>> --- trunk/dports/devel/dbus/Portfile    2009-01-13 08:51:58 UTC (rev
>> 45299)
>> +++ trunk/dports/devel/dbus/Portfile    2009-01-13 10:17:46 UTC (rev
>> 45300)
>> @@ -41,7 +41,7 @@
>>
>>  post-configure {
>>      if {[variant_isset universal] && [lsearch -glob
>> ${universal_archs} *64] != -1} {
>> -        system "cd ${worksrcpath} && patch -p0 <
>> ${filespath}/patch-config.h.diff"
>> +        system "cd ${worksrcpath} && patch -p0 <
>> ${filespath}/patch-config.h.diff && touch stamp-h1"
>>      }
>>  }
> 
> Could you elaborate on what this is doing? I'm curious. :)

The file 'stamp-h1' is a timestamp. If config.h is more recent than it,
the Makefile re-runs config.status, thus clobbering the patched config.h.

- Josh

From shreevatsa.public at gmail.com  Tue Jan 13 08:27:22 2009
From: shreevatsa.public at gmail.com (Shreevatsa R)
Date: Tue, 13 Jan 2009 11:27:22 -0500
Subject: selfupdate and readline support
In-Reply-To: <594EECDD-F7C9-4FDF-BA75-1862B4B0766A@macports.org>
References: <496A02B1.6020100@macports.org> <496A0A56.4000607@macports.org>
	<496BE730.8050304@macports.org> <496BE7F3.8000409@orcaware.com>
	<594EECDD-F7C9-4FDF-BA75-1862B4B0766A@macports.org>
Message-ID: <7675454e0901130827gd54385fue24a8e818d20859e@mail.gmail.com>

On Mon, Jan 12, 2009 at 11:38 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> I said then [1], and still say now, that we need a more general solution
> that makes MacPorts display a warning to the user if they install software
> in the prefix /usr/local. We have never supported the user installing
> software in the prefix /usr/local [2] and it causes problems in many more
> situations than this. MacPorts should actively inform users that they are
> doing things they should not, and how to correct them (even if that's only
> by providing a link to a FAQ entry or Guide section).
>
> [1]
> http://lists.macosforge.org/pipermail/macports-users/2007-November/006982.html
>
> [2] http://trac.macports.org/ticket/15077
>

I don't think this is a reasonable policy for MacPorts to have.
/usr/local is the "standard" location for software manually installed
by the user. Are you suggesting that
(1) users should configure all their software with some other prefix, or
(2) they should not install anything at all outside of MacPorts?
Neither of them is a practical solution. There are application bundles
that *do* install to /usr/local, and it is impossible to use "just
MacPorts" because of the thousands of things that don't work:
http://trac.macports.org/report/1

The proper solution is for MacPorts to figure out a way of preventing
its ports from looking outside ${prefix} -- whether /usr/local or /usr
or any directory at all.

From jmr at macports.org  Tue Jan 13 08:40:10 2009
From: jmr at macports.org (Joshua Root)
Date: Wed, 14 Jan 2009 03:40:10 +1100
Subject: selfupdate and readline support
In-Reply-To: <7675454e0901130827gd54385fue24a8e818d20859e@mail.gmail.com>
References: <496A02B1.6020100@macports.org>
	<496A0A56.4000607@macports.org>	<496BE730.8050304@macports.org>
	<496BE7F3.8000409@orcaware.com>	<594EECDD-F7C9-4FDF-BA75-1862B4B0766A@macports.org>
	<7675454e0901130827gd54385fue24a8e818d20859e@mail.gmail.com>
Message-ID: <496CC3EA.8030608@macports.org>

Shreevatsa R wrote:
> The proper solution is for MacPorts to figure out a way of preventing
> its ports from looking outside ${prefix} -- whether /usr/local or /usr
> or any directory at all.

Unless you have a patch ready that fixes the problem The Right Way, I
don't see how informing users of the problem is a bad thing.

- Josh

From apple at frinabulax.org  Tue Jan 13 09:27:05 2009
From: apple at frinabulax.org (robert delius royar)
Date: Tue, 13 Jan 2009 12:27:05 -0500
Subject: selfupdate and readline support
In-Reply-To: <7675454e0901130827gd54385fue24a8e818d20859e@mail.gmail.com>
References: <496A02B1.6020100@macports.org> <496A0A56.4000607@macports.org>
	<496BE730.8050304@macports.org> <496BE7F3.8000409@orcaware.com>
	<594EECDD-F7C9-4FDF-BA75-1862B4B0766A@macports.org>
	<7675454e0901130827gd54385fue24a8e818d20859e@mail.gmail.com>
Message-ID: <alpine.OSX.2.00L.0901131217210.15262@sehabohynk.sevanohynk.bet>

Tue, 13 Jan 2009 (11:27 -0500 UTC) Shreevatsa R wrote:

> On Mon, Jan 12, 2009 at 11:38 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>> I said then [1], and still say now, that we need a more general solution
>> that makes MacPorts display a warning to the user if they install software
>> in the prefix /usr/local. We have never supported the user installing
>> software in the prefix /usr/local [2] and it causes problems in many more
>> situations than this. MacPorts should actively inform users that they are
>> doing things they should not, and how to correct them (even if that's only
>> by providing a link to a FAQ entry or Guide section).
>>
>> [1]
>> http://lists.macosforge.org/pipermail/macports-users/2007-November/006982.html
>>
>> [2] http://trac.macports.org/ticket/15077
>>
>
> I don't think this is a reasonable policy for MacPorts to have.
> /usr/local is the "standard" location for software manually installed
> by the user. Are you suggesting that
> (1) users should configure all their software with some other prefix, or
> (2) they should not install anything at all outside of MacPorts?
> Neither of them is a practical solution. There are application bundles
> that *do* install to /usr/local, and it is impossible to use "just
> MacPorts" because of the thousands of things that don't work:
> http://trac.macports.org/report/1

Try `grep -R /usr/local /opt/local` just to see how many Macports 
reference files in /usr/local.  If you install Macports gcc, I suspect 
even that tool searches /usr/local/include and /usr/local/lib.  The 
auto tools used to install with /usr/local as the preferred place to 
look for configuration files, headers, and libraries.  I haven't checked 
recently, but I suspect that is still the case.

>
> The proper solution is for MacPorts to figure out a way of preventing
> its ports from looking outside ${prefix} -- whether /usr/local or /usr
> or any directory at all.

It is probably not practical, but if ports were each to run a recursive 
sed on source trees to change all references to '/usr/local/' from that 
to '/opt/local', you might get some safety from the /usr/local 
pollution.

-- 
Dr. Robert Delius Royar                   Associate Professor of English
Morehead State University                             Morehead, Kentucky


From shreevatsa.public at gmail.com  Tue Jan 13 10:22:46 2009
From: shreevatsa.public at gmail.com (Shreevatsa R)
Date: Tue, 13 Jan 2009 13:22:46 -0500
Subject: selfupdate and readline support
In-Reply-To: <alpine.OSX.2.00L.0901131217210.15262@sehabohynk.sevanohynk.bet>
	<496CC3EA.8030608@macports.org>
References: <594EECDD-F7C9-4FDF-BA75-1862B4B0766A@macports.org>
	<7675454e0901130827gd54385fue24a8e818d20859e@mail.gmail.com>
	<alpine.OSX.2.00L.0901131217210.15262@sehabohynk.sevanohynk.bet>
	<496A02B1.6020100@macports.org> <496A0A56.4000607@macports.org>
	<496BE730.8050304@macports.org> <496BE7F3.8000409@orcaware.com>
	<594EECDD-F7C9-4FDF-BA75-1862B4B0766A@macports.org>
	<7675454e0901130827gd54385fue24a8e818d20859e@mail.gmail.com>
	<496CC3EA.8030608@macports.org>
Message-ID: <496cdbfb.c6c1f10a.626b.7eb7@mx.google.com>

On Wed, Jan 14, 2009 at 03:40:10AM +1100, Joshua Root wrote:
> Shreevatsa R wrote:
> > The proper solution is for MacPorts to figure out a way of preventing
> > its ports from looking outside ${prefix} -- whether /usr/local or /usr
> > or any directory at all.
> 
> Unless you have a patch ready that fixes the problem The Right Way, I
> don't see how informing users of the problem is a bad thing.

Agreed that informing users of the problem is a good thing. Was only
objecting to the idea that "they are doing things they should not", when
it is actually MacPorts that is doing something that it should not, by
allowing its ports to use libraries outside its prefix.

On Tue, Jan 13, 2009 at 12:27:05PM -0500, robert delius royar wrote:
> Try `grep -R /usr/local /opt/local` just to see how many Macports  
> reference files in /usr/local.  If you install Macports gcc, I suspect  
> even that tool searches /usr/local/include and /usr/local/lib.  The auto 
> tools used to install with /usr/local as the preferred place to look for 
> configuration files, headers, and libraries.  I haven't checked  
> recently, but I suspect that is still the case.

Yes, autotools looks in /usr/local by default, and it can be pretty hard to
track down all instances and change this. That's why I said that it's not
reasonable to expect that users will be able to avoid having anything
installed in /usr/local at all.

>> The proper solution is for MacPorts to figure out a way of preventing
>> its ports from looking outside ${prefix} -- whether /usr/local or /usr
>> or any directory at all.
>
> It is probably not practical, but if ports were each to run a recursive  
> sed on source trees to change all references to '/usr/local/' from that  
> to '/opt/local', you might get some safety from the /usr/local  
> pollution.

That might change quite a few things unintentionally, and leave some
things unchanged. Another crude approach might be what is mentioned in
#15077,  "to rename it (e.g. to /usr/local-off), clean the affected port,
and [perform] the installation".

I do not know enough about this, but the right approach might be for
everything to be built in a chroot-ed environment, where /usr/local (and
other directories outside /opt/local) are not visible or available.
I think some other package management systems do something like this,
but I'm not sure.

From ryandesign at macports.org  Tue Jan 13 11:23:49 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 13 Jan 2009 13:23:49 -0600
Subject: [45324] trunk/dports/lang
In-Reply-To: <20090113160733.D5524C274E4@beta.macosforge.org>
References: <20090113160733.D5524C274E4@beta.macosforge.org>
Message-ID: <6C7B01E6-EF56-4663-97CC-684519295825@macports.org>


On Jan 13, 2009, at 10:07, davidnichols at macports.org wrote:

> +master_sites        http://downloads.sourceforge.net/qore/qore- 
> mysql-module-1.0.2.tar.gz

You should remove "qore-mysql-module-1.0.2.tar.gz" from this line.  
MacPorts knows to add that automatically.



From jmr at macports.org  Tue Jan 13 12:19:54 2009
From: jmr at macports.org (Joshua Root)
Date: Wed, 14 Jan 2009 07:19:54 +1100
Subject: [45324] trunk/dports/lang
In-Reply-To: <6C7B01E6-EF56-4663-97CC-684519295825@macports.org>
References: <20090113160733.D5524C274E4@beta.macosforge.org>
	<6C7B01E6-EF56-4663-97CC-684519295825@macports.org>
Message-ID: <496CF76A.9080209@macports.org>

Ryan Schmidt wrote:
> 
> On Jan 13, 2009, at 10:07, davidnichols at macports.org wrote:
> 
>> +master_sites       
>> http://downloads.sourceforge.net/qore/qore-mysql-module-1.0.2.tar.gz
> 
> You should remove "qore-mysql-module-1.0.2.tar.gz" from this line.
> MacPorts knows to add that automatically.

In fact, since we have a sourceforge mirror group, you can just use
"master_sites sourceforge:qore".

- Josh

From jmr at macports.org  Tue Jan 13 13:09:00 2009
From: jmr at macports.org (Joshua Root)
Date: Wed, 14 Jan 2009 08:09:00 +1100
Subject: [45324] trunk/dports/lang
In-Reply-To: <C4F1C145-9C47-4D14-A272-10DF7A8D53D1@gmail.com>
References: <20090113160733.D5524C274E4@beta.macosforge.org>
	<6C7B01E6-EF56-4663-97CC-684519295825@macports.org>
	<496CF76A.9080209@macports.org>
	<C4F1C145-9C47-4D14-A272-10DF7A8D53D1@gmail.com>
Message-ID: <496D02EC.70309@macports.org>

<http://guide.macports.org/#reference.phases.fetch> :-)

- Josh

David Nichols wrote:
> thanks guys, I tried to find a reference to this somewhere before I
> committed the Portfile, but couldn't find it.
> 
> anyway, I just committed the fix.
> 
> thanks again,
> david
> 
> 
> On Jan 13, 2009, at 9:19 PM, Joshua Root wrote:
> 
>> Ryan Schmidt wrote:
>>>
>>> On Jan 13, 2009, at 10:07, davidnichols at macports.org wrote:
>>>
>>>> +master_sites
>>>> http://downloads.sourceforge.net/qore/qore-mysql-module-1.0.2.tar.gz
>>>
>>> You should remove "qore-mysql-module-1.0.2.tar.gz" from this line.
>>> MacPorts knows to add that automatically.
>>
>> In fact, since we have a sourceforge mirror group, you can just use
>> "master_sites sourceforge:qore".
>>
>> - Josh
> 


From markd at macports.org  Wed Jan 14 00:10:04 2009
From: markd at macports.org (markd at macports.org)
Date: Wed, 14 Jan 2009 00:10:04 -0800
Subject: Wiki-like markup for Guide
Message-ID: <fc.004c4c581137be94004c4c581137be94.1137c3a7@biola.edu>

>>> + 1. make guide use a reasonable (wiki-like) markup, not docbook-xml.
>>
>> I think we like our docbook-xml Guide... a lot of work was put into
>getting
>> it the way it is. What objections do you have to the way it's being done
>> now? Let's discuss.
>
>I dislike editing XML, because it is so quirky. And I dislike docbook-xml
>because it has this vast vocabulary, which few poeple really use. Only a
>very
>small subset of it is used in the guide. And this makes it hard for
>new or occasional
>contributers (like me) to help. I think there are solutions out there
>that don't force
>me to think about online and offline document type definitions,
>well-formedness
>of ampersands, and if I can nest a certain element at this tree position.
>I find thinking of a text as a tree quite unnatural. Why not keep it as
>a stream of characters? But xml forces one to look at it as a tree.
>
>Mark once kindly offered me to accept text changes and make the actual
>editing.
>That's very generous. I'm sure he offers that to everyone else as well.
>But that still feels a bit indirect, and I don't really want to bother
>somebody else
>with a small change. I guess others are reluctant to do so as well. Still
>the
>many but small changes are the important asset in any open source project,
>and they are the means to get tedious work like documentation done.
>
>So a simple and straightforward, maybe even well-known markup as wikis
>tend to use them might help. I know about all the semantics and the
>structure
>arguments, and that the rendering is a separate matter. But
>documenting should not become
>harder than just writing an understandable text, which is hard enough
>in it's own right.
>
>So, these are my points against docbook. OTOH, if the majority is happy
>with
>the current setup, then let's leave it as it is, by all means. But if
>not, then
>such a change might help to get more contributions here, and thereby more
>current documentation.

There are several issues that I think have made wikis not sufficiently
attractive for us.

1) Editorial control - It isn't practical for many people to make major
edits.  It can fragment the docs so they lose overall coherence.  However,
one of my goals for the new guide was that incremental changes were easy
to make and I think we have had some great commits of additional reference
material by our base coders and I thought that was great.

2) Single source - We want to source the man pages out of the guide and
we're really only a few days of hard work from that, despite the fact that
not a lot of documentation work has happened in the past year.  Using a
single source is the only way to have accurate docs and guide, which will
eliminate a lot of work and the innaccuracy that has plagued the docs in
the past.

I think docbook works well considering the overall goals we have.  And i
think the goals will make for better and more accurate docs.  The single
source issue is huge -no way for us to have separate man and guide docs
that are accurate otherwise.  And I don't think we can do that without
xml.  Also, I use a wysiwyg editor so I do very little xml coding
directly.  And I'm open to any method of contribution.  Using Trac leaves
something to be desired.  Maybe a wiki scratchpad of some sort would be
better.  And at least by summer's end I intend to have the missing parts
of the guide filled in and make a transition to the single source man
pages with Simon's help.

I understand your frustrations though, so I'm not sure how satisfying
these answers will be.  But I hope that helps.

Mark


From florian.ebeling at gmail.com  Wed Jan 14 00:42:15 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Wed, 14 Jan 2009 09:42:15 +0100
Subject: Wiki-like markup for Guide
In-Reply-To: <fc.004c4c581137be94004c4c581137be94.1137c3a7@biola.edu>
References: <fc.004c4c581137be94004c4c581137be94.1137c3a7@biola.edu>
Message-ID: <5cbbe4ae0901140042t569eab8ai44f2ff8469d5f3ce@mail.gmail.com>

On Wed, Jan 14, 2009 at 9:10 AM,  <markd at macports.org> wrote:
>>>> + 1. make guide use a reasonable (wiki-like) markup, not docbook-xml.
>>>
>>> I think we like our docbook-xml Guide... a lot of work was put into
>>getting
>>> it the way it is. What objections do you have to the way it's being done
>>> now? Let's discuss.
>
> There are several issues that I think have made wikis not sufficiently
> attractive for us.

Ok, I guess I didn't make my intent clear enough. My suggestion is not
to use a wiki as documentation. I think we have that already, that's fine,
and it serves a different need.

My suggestion is about using a different format: instead of an complicated
XML vocabulary a lightweight markup language [1]. I think Textile and Markdown
are the most commonly used ones. Those are best known as the raw format of
wikis, that's why I called it wiki-like. That way the documentation
would still be in
a single place in the svn. I find that an important property as well.
But it does
not necessitate use of xml.

Florian

[1] http://en.wikipedia.org/wiki/Lightweight_markup_language

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

From markd at macports.org  Wed Jan 14 09:01:19 2009
From: markd at macports.org (markd at macports.org)
Date: Wed, 14 Jan 2009 09:01:19 -0800
Subject: Wiki-like markup for Guide
Message-ID: <fc.004c4c5811388f1a004c4c5811388f1a.1138aaf5@biola.edu>

>> There are several issues that I think have made wikis not sufficiently
>> attractive for us.
>
>Ok, I guess I didn't make my intent clear enough. My suggestion is not
>to use a wiki as documentation. I think we have that already, that's fine,
>and it serves a different need.
>
>My suggestion is about using a different format: instead of an complicated
>XML vocabulary a lightweight markup language [1]. I think Textile and
>Markdown
>are the most commonly used ones. Those are best known as the raw format of
>wikis, that's why I called it wiki-like. That way the documentation
>would still be in
>a single place in the svn. I find that an important property as well.
>But it does
>not necessitate use of xml. 

But there is more to it than having it in a single place.  It must have
enough of a data structure to support what we're doing.  There is a
current toolchain to get us from XML DocBook to man pages automatically. 
I think we'd end up rolling our own toolchain to accomplish the same thing
with markdown.  Simon could give a better answer because he's been doing
the scripting work, but I suspect there would be new challenges with
something like markdown to man pages.

And I think the more complex structured environment of DocBook has been a
benefit.  I realize that markdown (and other ones) support a structure as
well, but we'd I think we'd have to come up with a fairly complex style
guide for its use to support a consistent style to get the functionality
we now have.  In other words, we'd end up creating a DTD, which is what
DocBook is.  So my opinion is that it would take a lot of work to get the
functionality we now have, and we'd likely not do a good enough job with a
DTD to have as consistent a style as we have now.

Mark


From florian.ebeling at gmail.com  Wed Jan 14 09:18:09 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Wed, 14 Jan 2009 18:18:09 +0100
Subject: Wiki-like markup for Guide
In-Reply-To: <fc.004c4c5811388f1a004c4c5811388f1a.1138aaf5@biola.edu>
References: <fc.004c4c5811388f1a004c4c5811388f1a.1138aaf5@biola.edu>
Message-ID: <5cbbe4ae0901140918l5aedf54m217d34b658e74fa3@mail.gmail.com>

On Wed, Jan 14, 2009 at 6:01 PM,  <markd at macports.org> wrote:
>>> There are several issues that I think have made wikis not sufficiently
>>> attractive for us.
>>
>>Ok, I guess I didn't make my intent clear enough. My suggestion is not
>>to use a wiki as documentation. I think we have that already, that's fine,
>>and it serves a different need.
>>
>>My suggestion is about using a different format: instead of an complicated
>>XML vocabulary a lightweight markup language [1]. I think Textile and
>>Markdown
>>are the most commonly used ones. Those are best known as the raw format of
>>wikis, that's why I called it wiki-like. That way the documentation
>>would still be in
>>a single place in the svn. I find that an important property as well.
>>But it does
>>not necessitate use of xml.
>
> But there is more to it than having it in a single place.  It must have
> enough of a data structure to support what we're doing.  There is a
> current toolchain to get us from XML DocBook to man pages automatically.
> I think we'd end up rolling our own toolchain to accomplish the same thing
> with markdown.  Simon could give a better answer because he's been doing
> the scripting work, but I suspect there would be new challenges with
> something like markdown to man pages.
>
> And I think the more complex structured environment of DocBook has been a
> benefit.  I realize that markdown (and other ones) support a structure as
> well, but we'd I think we'd have to come up with a fairly complex style
> guide for its use to support a consistent style to get the functionality
> we now have.  In other words, we'd end up creating a DTD, which is what
> DocBook is.  So my opinion is that it would take a lot of work to get the
> functionality we now have, and we'd likely not do a good enough job with a
> DTD to have as consistent a style as we have now.

Ok, then let's just keep docbook. I thought other might consider it combersome
as well, but if that's not the case, then so be it :)

Those who'd better like something else still can alleviate their pain
with Pandoc:
http://johnmacfarlane.net/pandoc/try

Florian


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

From wsiegrist at apple.com  Wed Jan 14 09:41:47 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Wed, 14 Jan 2009 09:41:47 -0800
Subject: Wiki-like markup for Guide
In-Reply-To: <5cbbe4ae0901140918l5aedf54m217d34b658e74fa3@mail.gmail.com>
References: <fc.004c4c5811388f1a004c4c5811388f1a.1138aaf5@biola.edu>
	<5cbbe4ae0901140918l5aedf54m217d34b658e74fa3@mail.gmail.com>
Message-ID: <157CC6F9-24D9-4D89-B779-3BD2CA62FBF3@apple.com>

On Jan 14, 2009, at 9:18 AM, C. Florian Ebeling wrote:

> On Wed, Jan 14, 2009 at 6:01 PM,  <markd at macports.org> wrote:
>>>> There are several issues that I think have made wikis not  
>>>> sufficiently
>>>> attractive for us.
>>>
>>> Ok, I guess I didn't make my intent clear enough. My suggestion is  
>>> not
>>> to use a wiki as documentation. I think we have that already,  
>>> that's fine,
>>> and it serves a different need.
>>>
>>> My suggestion is about using a different format: instead of an  
>>> complicated
>>> XML vocabulary a lightweight markup language [1]. I think Textile  
>>> and
>>> Markdown
>>> are the most commonly used ones. Those are best known as the raw  
>>> format of
>>> wikis, that's why I called it wiki-like. That way the documentation
>>> would still be in
>>> a single place in the svn. I find that an important property as  
>>> well.
>>> But it does
>>> not necessitate use of xml.
>>
>> But there is more to it than having it in a single place.  It must  
>> have
>> enough of a data structure to support what we're doing.  There is a
>> current toolchain to get us from XML DocBook to man pages  
>> automatically.
>> I think we'd end up rolling our own toolchain to accomplish the  
>> same thing
>> with markdown.  Simon could give a better answer because he's been  
>> doing
>> the scripting work, but I suspect there would be new challenges with
>> something like markdown to man pages.
>>
>> And I think the more complex structured environment of DocBook has  
>> been a
>> benefit.  I realize that markdown (and other ones) support a  
>> structure as
>> well, but we'd I think we'd have to come up with a fairly complex  
>> style
>> guide for its use to support a consistent style to get the  
>> functionality
>> we now have.  In other words, we'd end up creating a DTD, which is  
>> what
>> DocBook is.  So my opinion is that it would take a lot of work to  
>> get the
>> functionality we now have, and we'd likely not do a good enough job  
>> with a
>> DTD to have as consistent a style as we have now.
>
> Ok, then let's just keep docbook. I thought other might consider it  
> combersome
> as well, but if that's not the case, then so be it :)
>
> Those who'd better like something else still can alleviate their pain
> with Pandoc:
> http://johnmacfarlane.net/pandoc/try
>

So you dont feel like you're the only one... :) It is definitely  
cumbersome to edit manually. The few times I've had to touch the guide  
I did it with vi. So I agree on that point, but also agree that the  
structure gives a lot of benefits. The bottom line is if you're going  
to spend any significant time on the guide, find a gui or other tool  
to do the xml for you.

-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/20090114/7d20f0cd/attachment.bin>

From jmr at macports.org  Wed Jan 14 15:09:03 2009
From: jmr at macports.org (Joshua Root)
Date: Thu, 15 Jan 2009 10:09:03 +1100
Subject: Status of registry2.0
In-Reply-To: <485DDA49.6060407@macports.org>
References: <480AA35A.20404@macports.org>	<0455052E-CE67-4C75-8EDC-6D827C912004@macports.org>
	<485DDA49.6060407@macports.org>
Message-ID: <496E708F.5000608@macports.org>

Chris Pickel wrote:
> On 19 Apr, 2008, at 21:58, Rainer M?ller wrote:
>> What is the current status of registry 2.0? As we are still putting  
>> new features (recursive uninstall) into registry1.0 I was wondering  
>> what the status of registry2.0 is at the moment. It is sitting  
>> around in trunk now for quite some time without active work.
>>
>> What is missing from registry2.0, what needs to be done? Where can  
>> somebody jump in and help? Not necessarily me, I just want to put  
>> general attention to the new registry.
> 
> I am very busy and haven't looked in a while.
> 
> If I haven't given a better response within 3 weeks or so, feel free  
> to remind me to do so.

Still very interested in this info. :-)

It would be nice if we could get registry2.0 fully working in time for 1.8.

- Josh

From raimue at macports.org  Wed Jan 14 17:13:59 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 15 Jan 2009 02:13:59 +0100
Subject: Wiki-like markup for Guide
In-Reply-To: <5cbbe4ae0901140918l5aedf54m217d34b658e74fa3@mail.gmail.com>
References: <fc.004c4c5811388f1a004c4c5811388f1a.1138aaf5@biola.edu>
	<5cbbe4ae0901140918l5aedf54m217d34b658e74fa3@mail.gmail.com>
Message-ID: <496E8DD7.7040001@macports.org>

C. Florian Ebeling wrote:
>> And I think the more complex structured environment of DocBook has been a
>> benefit.  I realize that markdown (and other ones) support a structure as
>> well, but we'd I think we'd have to come up with a fairly complex style
>> guide for its use to support a consistent style to get the functionality
>> we now have.  In other words, we'd end up creating a DTD, which is what
>> DocBook is.  So my opinion is that it would take a lot of work to get the
>> functionality we now have, and we'd likely not do a good enough job with a
>> DTD to have as consistent a style as we have now.
> 
> Ok, then let's just keep docbook. I thought other might consider it combersome
> as well, but if that's not the case, then so be it :)

I agree with Florian that editing our guide is not very easy. XML is a
nice exchange format for structured data, but I don't like to edit it by
hand.

Maybe we could consider asciidoc as it offers an easy syntax, but is in
fact a converter from ASCII to DocBook XML.

  http://www.methods.co.nz/asciidoc/

Rainer

From ryandesign at macports.org  Wed Jan 14 18:15:56 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 14 Jan 2009 20:15:56 -0600
Subject: cairo on Tiger: can't locate file for: -lXrender
Message-ID: <C15F7E24-F677-47C4-9128-88A2787BF7B4@macports.org>

I can't install cairo on Tiger:


libtool: link: /usr/bin/gcc-4.0 -dynamiclib  -o .libs/libcairo. 
2.dylib  .libs/cairo-analysis-surface.o .libs/cairo-arc.o .libs/cairo- 
array.o .libs/cairo-atomic.o .libs/cairo-base85-stream.o .libs/cairo- 
bentley-ottmann.o .libs/cairo.o .libs/cairo-cache.o .libs/cairo- 
clip.o .libs/cairo-color.o .libs/cairo-debug.o .libs/cairo- 
fixed.o .libs/cairo-font-face.o .libs/cairo-font-face-twin.o .libs/ 
cairo-font-face-twin-data.o .libs/cairo-font-options.o .libs/cairo- 
freelist.o .libs/cairo-gstate.o .libs/cairo-hash.o .libs/cairo- 
hull.o .libs/cairo-image-surface.o .libs/cairo-lzw.o .libs/cairo- 
matrix.o .libs/cairo-meta-surface.o .libs/cairo-misc.o .libs/cairo- 
mutex.o .libs/cairo-output-stream.o .libs/cairo-paginated- 
surface.o .libs/cairo-path-bounds.o .libs/cairo-path.o .libs/cairo- 
path-fill.o .libs/cairo-path-fixed.o .libs/cairo-path-stroke.o .libs/ 
cairo-pattern.o .libs/cairo-pen.o .libs/cairo-polygon.o .libs/cairo- 
rectangle.o .libs/cairo-region.o .libs/cairo-scaled-font.o .libs/ 
cairo-skiplist.o .libs/cairo-slope.o .libs/cairo-spline.o .libs/cairo- 
stroke-style.o .libs/cairo-surface.o .libs/cairo-surface- 
fallback.o .libs/cairo-system.o .libs/cairo-traps.o .libs/cairo- 
unicode.o .libs/cairo-user-font.o .libs/cairo-version.o .libs/cairo- 
wideint.o .libs/cairo-cff-subset.o .libs/cairo-scaled-font- 
subsets.o .libs/cairo-truetype-subset.o .libs/cairo-type1- 
fallback.o .libs/cairo-type1-subset.o .libs/cairo-type3-glyph- 
surface.o .libs/cairo-pdf-operators.o .libs/cairo-xlib- 
display.o .libs/cairo-xlib-screen.o .libs/cairo-xlib-surface.o .libs/ 
cairo-xlib-visual.o .libs/cairo-quartz-surface.o .libs/cairo-quartz- 
font.o .libs/cairo-quartz-image-surface.o .libs/cairo-png.o .libs/ 
cairo-ft-font.o .libs/cairo-ps-surface.o .libs/cairo-pdf- 
surface.o .libs/cairo-deflate-stream.o .libs/cairo-svg-surface.o   -L/ 
mp/lib /mp/lib/libpixman-1.dylib -lm /mp/lib/libfontconfig.dylib /mp/ 
lib/libiconv.dylib /mp/lib/libexpat.dylib /mp/lib/libfreetype.dylib / 
mp/lib/libpng12.dylib /mp/lib/libX11.dylib /mp/lib/libXau.dylib /mp/ 
lib/libXdmcp.dylib -lz -lXrender  -Wl,-framework -Wl,CoreServices - 
Wl,-framework -Wl,ApplicationServices -Wl,-framework -Wl,CoreServices  
-Wl,-framework -Wl,ApplicationServices -Wl,-framework - 
Wl,ApplicationServices   -install_name  /mp/lib/libcairo.2.dylib - 
compatibility_version 10803 -current_version 10803.6 -Wl,-single_module
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/libtool: can't locate file  
for: -lXrender
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/libtool: file: -lXrender is  
not an object file (not allowed in a library)
make[3]: *** [libcairo.la] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Error: Status 1 encountered during processing.


Here are the xorg ports I have installed:


$ port installed xorg-*
The following ports are currently installed:
   xorg-bigreqsproto @1.0.2_0 (active)
   xorg-inputproto @1.5.0_0 (active)
   xorg-kbproto @1.0.3_0 (active)
   xorg-libpthread-stubs @0.1_0 (active)
   xorg-libX11 @1.1.5_1+universal (active)
   xorg-libXau @1.0.4_0+universal (active)
   xorg-libxcb @1.1_0+universal (active)
   xorg-libXdmcp @1.0.2_0+universal (active)
   xorg-renderproto @0.9.3_0 (active)
   xorg-util-macros @1.2.1_0 (active)
   xorg-xcb-proto @1.3_0+python26 (active)
   xorg-xcmiscproto @1.1.2_0 (active)
   xorg-xextproto @7.0.4_0 (active)
   xorg-xf86bigfontproto @1.1.2_0 (active)
   xorg-xproto @7.0.14_1 (active)
   xorg-xtrans @1.2.2_0+universal (active)
$


The xrender port is not installed. It had been, but then r43644 and  
r43686 changed xrender to a lib dependency and sometime later I  
uninstalled it. Does anyone know (Jeremy?) what should be done here?




From mvfranz at gmail.com  Wed Jan 14 18:24:32 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Wed, 14 Jan 2009 21:24:32 -0500
Subject: [MacPorts] #17997: ice-cpp conflicts with xorg-libice
In-Reply-To: <063.dc4d0699bc022c8a63b5df24d93c65fb@macports.org>
References: <054.7035c562f6d4e3def1be708697901796@macports.org>
	<063.dc4d0699bc022c8a63b5df24d93c65fb@macports.org>
Message-ID: <fee4d890901141824u224d0c6bs290fc26eba764e69@mail.gmail.com>

I cannot login to the trac system.  I request a new password, which is sent
to me.  I click the link to get the new password, but it does not let me in.


On Wed, Jan 14, 2009 at 7:58 PM, MacPorts <noreply at macports.org> wrote:

> #17997: ice-cpp conflicts with xorg-libice
>
> --------------------------------+-------------------------------------------
>  Reporter:  stromnov@?          |       Owner:  blair@?
>     Type:  defect              |      Status:  new
>  Priority:  Normal              |   Milestone:  Port Bugs
> Component:  ports               |     Version:  1.7.0
>  Keywords:                      |        Port:  ice-cpp xorg-libice
>
> --------------------------------+-------------------------------------------
> Changes (by blair@?):
>
>  * cc: mvfranz@? (added)
>
>
> Comment:
>
>  [Adding the xorg-libice port maintiner to the cc].
>
>  Do you have a suggested fix for this?
>
>  At first glance, I don't have any intentions of changing the shared
>  library name,
>  esepcially given that Mac OS X provides a libICE.dylib in /usr/X11R6/lib.
>
> --
> Ticket URL: <http://trac.macports.org/ticket/17997#comment:2>
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090114/22a6aa2f/attachment.html>

From wsiegrist at apple.com  Wed Jan 14 18:45:27 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Wed, 14 Jan 2009 18:45:27 -0800
Subject: [MacPorts] #17997: ice-cpp conflicts with xorg-libice
In-Reply-To: <fee4d890901141824u224d0c6bs290fc26eba764e69@mail.gmail.com>
References: <054.7035c562f6d4e3def1be708697901796@macports.org>
	<063.dc4d0699bc022c8a63b5df24d93c65fb@macports.org>
	<fee4d890901141824u224d0c6bs290fc26eba764e69@mail.gmail.com>
Message-ID: <28870186-857C-4A76-AC25-1916E3C808D2@apple.com>


On Jan 14, 2009, at 6:24 PM, Michael Franz wrote:

> I cannot login to the trac system.  I request a new password, which  
> is sent to me.  I click the link to get the new password, but it  
> does not let me in.
>
>
>


You need to provide more information... Do you get any errors when you  
try to login? Do you actually get a new password displayed when you  
reset it?

-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/20090114/bfe63fef/attachment.bin>

From mvfranz at gmail.com  Wed Jan 14 18:55:01 2009
From: mvfranz at gmail.com (Michael Franz)
Date: Wed, 14 Jan 2009 21:55:01 -0500
Subject: [MacPorts] #17997: ice-cpp conflicts with xorg-libice
In-Reply-To: <28870186-857C-4A76-AC25-1916E3C808D2@apple.com>
References: <054.7035c562f6d4e3def1be708697901796@macports.org>
	<063.dc4d0699bc022c8a63b5df24d93c65fb@macports.org>
	<fee4d890901141824u224d0c6bs290fc26eba764e69@mail.gmail.com>
	<28870186-857C-4A76-AC25-1916E3C808D2@apple.com>
Message-ID: <fee4d890901141855t63e262f9se9002fc6416d4d43@mail.gmail.com>

Sorry,  I get a new random password after the link.  Then get the 'Unknown
username email or password.' message when I try to use the new password.  I
have tried this 3 times.

On Wed, Jan 14, 2009 at 9:45 PM, William Siegrist <wsiegrist at apple.com>wrote:

>
> On Jan 14, 2009, at 6:24 PM, Michael Franz wrote:
>
>  I cannot login to the trac system.  I request a new password, which is
>> sent to me.  I click the link to get the new password, but it does not let
>> me in.
>>
>>
>>
>>
>
> You need to provide more information... Do you get any errors when you try
> to login? Do you actually get a new password displayed when you reset it?
>
> -Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090114/524027b5/attachment.html>

From jeremyhu at macports.org  Wed Jan 14 19:12:23 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Wed, 14 Jan 2009 19:12:23 -0800
Subject: cairo on Tiger: can't locate file for: -lXrender
In-Reply-To: <C15F7E24-F677-47C4-9128-88A2787BF7B4@macports.org>
References: <C15F7E24-F677-47C4-9128-88A2787BF7B4@macports.org>
Message-ID: <18615471-0B60-405A-9EF4-863A5AFE7CE1@macports.org>


On Jan 14, 2009, at 18:15, Ryan Schmidt wrote:

> I can't install cairo on Tiger:

<snip/>

> Here are the xorg ports I have installed:
>
>
> $ port installed xorg-*
> The following ports are currently installed:
>  xorg-bigreqsproto @1.0.2_0 (active)
>  xorg-inputproto @1.5.0_0 (active)
>  xorg-kbproto @1.0.3_0 (active)
>  xorg-libpthread-stubs @0.1_0 (active)
>  xorg-libX11 @1.1.5_1+universal (active)
>  xorg-libXau @1.0.4_0+universal (active)
>  xorg-libxcb @1.1_0+universal (active)
>  xorg-libXdmcp @1.0.2_0+universal (active)
>  xorg-renderproto @0.9.3_0 (active)
>  xorg-util-macros @1.2.1_0 (active)
>  xorg-xcb-proto @1.3_0+python26 (active)
>  xorg-xcmiscproto @1.1.2_0 (active)
>  xorg-xextproto @7.0.4_0 (active)
>  xorg-xf86bigfontproto @1.1.2_0 (active)
>  xorg-xproto @7.0.14_1 (active)
>  xorg-xtrans @1.2.2_0+universal (active)
> $
>
>
> The xrender port is not installed. It had been, but then r43644 and  
> r43686 changed xrender to a lib dependency and sometime later I  
> uninstalled it. Does anyone know (Jeremy?) what should be done here?

The problem is with your xorg-lib* libs.  Cairo is finding all of them  
in /mp, so it's expecting -lXrender to be in /mp as well.  Mixing libs  
between x11prefix and prefix actually causes problems (see #17558).   
I'd recommend one of two courses:

1) uninstall xorg-lib* and set the +system_x11 variant, so they are  
just stubs when we switch to port:* dependencies

or

2) Just install xorg-libs to make sure you have all the X11 libraries  
in /mp.

You should probably go through and rebuild everything that depends on  
X11 to make sure you have consistent linking

From blb at macports.org  Wed Jan 14 19:16:49 2009
From: blb at macports.org (Bryan Blackburn)
Date: Wed, 14 Jan 2009 20:16:49 -0700
Subject: cairo on Tiger: can't locate file for: -lXrender
In-Reply-To: <C15F7E24-F677-47C4-9128-88A2787BF7B4@macports.org>
References: <C15F7E24-F677-47C4-9128-88A2787BF7B4@macports.org>
Message-ID: <20090115031649.GH711@ninagal.withay.com>

On Wed, Jan 14, 2009 at 08:15:56PM -0600, Ryan Schmidt said:
> I can't install cairo on Tiger:
[...]
> .libs/cairo-deflate-stream.o .libs/cairo-svg-surface.o   -L/mp/lib 
> /mp/lib/libpixman-1.dylib -lm /mp/lib/libfontconfig.dylib /mp/ 
> lib/libiconv.dylib /mp/lib/libexpat.dylib /mp/lib/libfreetype.dylib / 
> mp/lib/libpng12.dylib /mp/lib/libX11.dylib /mp/lib/libXau.dylib /mp/ 
> lib/libXdmcp.dylib -lz -lXrender  -Wl,-framework -Wl,CoreServices - 
> Wl,-framework -Wl,ApplicationServices -Wl,-framework -Wl,CoreServices  
> -Wl,-framework -Wl,ApplicationServices -Wl,-framework - 
> Wl,ApplicationServices   -install_name  /mp/lib/libcairo.2.dylib - 
> compatibility_version 10803 -current_version 10803.6 -Wl,-single_module
> /usr/libexec/gcc/i686-apple-darwin8/4.0.1/libtool: can't locate file for: 
> -lXrender

The xrender port is the one that supplies libXrender, so I'd say if you
don't have one in /usr/X11R6/lib then you'll need the port.  Though oddly I
notice there's no reference to /usr/X11R6/lib in that compile line at all,
which means it may not see one there even if you do have it.  Since things
have been in flux, perhaps something became attached to the one in
${prefix}/lib so it isn't looking in /usr/X11R6 at all now?

Bryan

[...]
>
> The xrender port is not installed. It had been, but then r43644 and  
> r43686 changed xrender to a lib dependency and sometime later I  
> uninstalled it. Does anyone know (Jeremy?) what should be done here?

From ryandesign at macports.org  Wed Jan 14 19:42:13 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 14 Jan 2009 21:42:13 -0600
Subject: cairo on Tiger: can't locate file for: -lXrender
In-Reply-To: <18615471-0B60-405A-9EF4-863A5AFE7CE1@macports.org>
References: <C15F7E24-F677-47C4-9128-88A2787BF7B4@macports.org>
	<18615471-0B60-405A-9EF4-863A5AFE7CE1@macports.org>
Message-ID: <F29BD595-31CA-44E9-BC17-6ACEDC0635A6@macports.org>

On Jan 14, 2009, at 21:12, Jeremy Huddleston wrote:

> On Jan 14, 2009, at 18:15, Ryan Schmidt wrote:
>
>> I can't install cairo on Tiger:
>
> <snip/>
>
>> Here are the xorg ports I have installed:
>>
>>
>> $ port installed xorg-*
>> The following ports are currently installed:
>>  xorg-bigreqsproto @1.0.2_0 (active)
>>  xorg-inputproto @1.5.0_0 (active)
>>  xorg-kbproto @1.0.3_0 (active)
>>  xorg-libpthread-stubs @0.1_0 (active)
>>  xorg-libX11 @1.1.5_1+universal (active)
>>  xorg-libXau @1.0.4_0+universal (active)
>>  xorg-libxcb @1.1_0+universal (active)
>>  xorg-libXdmcp @1.0.2_0+universal (active)
>>  xorg-renderproto @0.9.3_0 (active)
>>  xorg-util-macros @1.2.1_0 (active)
>>  xorg-xcb-proto @1.3_0+python26 (active)
>>  xorg-xcmiscproto @1.1.2_0 (active)
>>  xorg-xextproto @7.0.4_0 (active)
>>  xorg-xf86bigfontproto @1.1.2_0 (active)
>>  xorg-xproto @7.0.14_1 (active)
>>  xorg-xtrans @1.2.2_0+universal (active)
>> $
>>
>>
>> The xrender port is not installed. It had been, but then r43644  
>> and r43686 changed xrender to a lib dependency and sometime later  
>> I uninstalled it. Does anyone know (Jeremy?) what should be done  
>> here?
>
> The problem is with your xorg-lib* libs.  Cairo is finding all of  
> them in /mp, so it's expecting -lXrender to be in /mp as well.   
> Mixing libs between x11prefix and prefix actually causes problems  
> (see #17558).  I'd recommend one of two courses:
>
> 1) uninstall xorg-lib* and set the +system_x11 variant, so they are  
> just stubs when we switch to port:* dependencies

Set... do you mean put it in variants.conf?

> or
>
> 2) Just install xorg-libs to make sure you have all the X11  
> libraries in /mp.
>
> You should probably go through and rebuild everything that depends  
> on X11 to make sure you have consistent linking


For that, do I use the script you posted some time ago?

It just seems to me that any Tiger user with any X-using ports would  
run into this issue. How are users supposed to be handling this issue?




From jeremyhu at macports.org  Wed Jan 14 21:04:00 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Wed, 14 Jan 2009 21:04:00 -0800
Subject: cairo on Tiger: can't locate file for: -lXrender
In-Reply-To: <F29BD595-31CA-44E9-BC17-6ACEDC0635A6@macports.org>
References: <C15F7E24-F677-47C4-9128-88A2787BF7B4@macports.org>
	<18615471-0B60-405A-9EF4-863A5AFE7CE1@macports.org>
	<F29BD595-31CA-44E9-BC17-6ACEDC0635A6@macports.org>
Message-ID: <CA6AC09C-18AE-49BC-95DB-82F3F65D696F@macports.org>


On Jan 14, 2009, at 19:42, Ryan Schmidt wrote:

>> The problem is with your xorg-lib* libs.  Cairo is finding all of  
>> them in /mp, so it's expecting -lXrender to be in /mp as well.   
>> Mixing libs between x11prefix and prefix actually causes problems  
>> (see #17558).  I'd recommend one of two courses:
>>
>> 1) uninstall xorg-lib* and set the +system_x11 variant, so they are  
>> just stubs when we switch to port:* dependencies
>
> Set... do you mean put it in variants.conf?

Yeah...

>> or
>>
>> 2) Just install xorg-libs to make sure you have all the X11  
>> libraries in /mp.
>>
>> You should probably go through and rebuild everything that depends  
>> on X11 to make sure you have consistent linking
>
> For that, do I use the script you posted some time ago?

Yeah, that would do it for you... but I'm a bit more anal than that...  
I'd port uninstall then port install them ;)

> It just seems to me that any Tiger user with any X-using ports would  
> run into this issue. How are users supposed to be handling this issue?

by doing just as I mentioned above or by waiting until the  
dependencies are changed to port:XXXX instead of lib:XXXX and it  
should "just work"...

From blb at macports.org  Wed Jan 14 21:21:56 2009
From: blb at macports.org (Bryan Blackburn)
Date: Wed, 14 Jan 2009 22:21:56 -0700
Subject: haskell port group
Message-ID: <20090115052156.GL711@ninagal.withay.com>

FYI, for those interested, I just added a port group for haskell [1], which
currently supports only ghc (which seems okay since the other hs-* ports I
checked are all ghc-specific).  It does the standard 'runhaskell Setup...'
routine.

I also updated three ports to use it, so you can use them as examples:

<http://trac.macports.org/browser/trunk/dports/devel/hs-digest/Portfile>
<http://trac.macports.org/browser/trunk/dports/devel/hs-utf8-string/Portfile>
<http://trac.macports.org/browser/trunk/dports/devel/hs-zip-archive/Portfile>

Bryan

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


From ryandesign at macports.org  Wed Jan 14 21:27:55 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 14 Jan 2009 23:27:55 -0600
Subject: cairo on Tiger: can't locate file for: -lXrender
In-Reply-To: <CA6AC09C-18AE-49BC-95DB-82F3F65D696F@macports.org>
References: <C15F7E24-F677-47C4-9128-88A2787BF7B4@macports.org>
	<18615471-0B60-405A-9EF4-863A5AFE7CE1@macports.org>
	<F29BD595-31CA-44E9-BC17-6ACEDC0635A6@macports.org>
	<CA6AC09C-18AE-49BC-95DB-82F3F65D696F@macports.org>
Message-ID: <53CF8BC2-3EA2-46D9-87B9-682E599CC0C1@macports.org>

On Jan 14, 2009, at 23:04, Jeremy Huddleston wrote:

> On Jan 14, 2009, at 19:42, Ryan Schmidt wrote:
>
>>> The problem is with your xorg-lib* libs.  Cairo is finding all of  
>>> them in /mp, so it's expecting -lXrender to be in /mp as well.   
>>> Mixing libs between x11prefix and prefix actually causes problems  
>>> (see #17558).  I'd recommend one of two courses:
>>>
>>> 1) uninstall xorg-lib* and set the +system_x11 variant, so they  
>>> are just stubs when we switch to port:* dependencies
>>
>> Set... do you mean put it in variants.conf?
>
> Yeah...
>
>>> or
>>>
>>> 2) Just install xorg-libs to make sure you have all the X11  
>>> libraries in /mp.
>>>
>>> You should probably go through and rebuild everything that  
>>> depends on X11 to make sure you have consistent linking
>>
>> For that, do I use the script you posted some time ago?
>
> Yeah, that would do it for you...

You initially posted these instructions for uninstalling and  
reinstalling ports:

http://trac.macports.org/ticket/17558#comment:33

And then this script which just modifies the libraries using  
install_name_tool:

http://trac.macports.org/ticket/17558#comment:39

The script ends with the message "This tool does not update libtool  
archives, so your .la files might be incorrect." How would the user  
know which .la files are affected, and how to fix them?


> but I'm a bit more anal than that... I'd port uninstall then port  
> install them ;)

How would I identify which ports those are that I should uninstall  
and reinstall?


>> It just seems to me that any Tiger user with any X-using ports  
>> would run into this issue. How are users supposed to be handling  
>> this issue?
>
> by doing just as I mentioned above or by waiting until the  
> dependencies are changed to port:XXXX instead of lib:XXXX and it  
> should "just work"...

We certainly a Problem Hotlist entry about this then, telling users  
how to do this.

It sounds like our ports tree is just broken for existing Tiger users  
without significant manual intervention by the user, which is not a  
good state for the tree to be in. If the fix is to change the  
dependencies from lib:X:X back to port:X again, what is the plan for  
doing that? Can it be done now or are there remaining outstanding  
issues?



From jeremyhu at macports.org  Wed Jan 14 21:47:16 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Wed, 14 Jan 2009 21:47:16 -0800
Subject: cairo on Tiger: can't locate file for: -lXrender
In-Reply-To: <53CF8BC2-3EA2-46D9-87B9-682E599CC0C1@macports.org>
References: <C15F7E24-F677-47C4-9128-88A2787BF7B4@macports.org>
	<18615471-0B60-405A-9EF4-863A5AFE7CE1@macports.org>
	<F29BD595-31CA-44E9-BC17-6ACEDC0635A6@macports.org>
	<CA6AC09C-18AE-49BC-95DB-82F3F65D696F@macports.org>
	<53CF8BC2-3EA2-46D9-87B9-682E599CC0C1@macports.org>
Message-ID: <DB0B1DF8-8651-48D7-8D1C-66961474B211@macports.org>


On Jan 14, 2009, at 21:27, Ryan Schmidt wrote:

> The script ends with the message "This tool does not update libtool  
> archives, so your .la files might be incorrect." How would the user  
> know which .la files are affected, and how to fix them?

"rm -f /opt/local/lib/*.la" is my recommendation... short of that  
'grep '/usr/X11' /opt/local/lib/*.la

>> but I'm a bit more anal than that... I'd port uninstall then port  
>> install them ;)
>
> How would I identify which ports those are that I should uninstall  
> and reinstall?

'otool -L' and 'grep /usr/X11' should do it... same as the  
install_name_tool does...

>>> It just seems to me that any Tiger user with any X-using ports  
>>> would run into this issue. How are users supposed to be handling  
>>> this issue?
>>
>> by doing just as I mentioned above or by waiting until the  
>> dependencies are changed to port:XXXX instead of lib:XXXX and it  
>> should "just work"...
>
> We certainly a Problem Hotlist entry about this then, telling users  
> how to do this.
>
> It sounds like our ports tree is just broken for existing Tiger  
> users without significant manual intervention by the user, which is  
> not a good state for the tree to be in. If the fix is to change the  
> dependencies from lib:X:X back to port:X again

They're not going back to port:X.  They're going to port:X.  They  
haven't been at port:X before.

As is, there shouldn't be any port: dependencies for the X11 libraries  
except from other X11 libraries.

> , what is the plan for doing that? Can it be done now or are there  
> remaining outstanding issues?

As mentioned, it needs to be done all at once and affected ports need  
to be revision bumped (is there a tool to automatically revision bump  
a file?  If not, manually setting the revision will probably be the  
bottleneck).

The only issue with it that I'm aware of is with ice-cpp conflicting  
with xorg-libice on case-insensitive file systems.

From ryandesign at macports.org  Wed Jan 14 22:47:23 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 15 Jan 2009 00:47:23 -0600
Subject: cairo on Tiger: can't locate file for: -lXrender
In-Reply-To: <20090115031649.GH711@ninagal.withay.com>
References: <C15F7E24-F677-47C4-9128-88A2787BF7B4@macports.org>
	<20090115031649.GH711@ninagal.withay.com>
Message-ID: <B63D1A2B-02C3-4303-BC24-16B68112B77E@macports.org>


On Jan 14, 2009, at 21:16, Bryan Blackburn wrote:

> On Wed, Jan 14, 2009 at 08:15:56PM -0600, Ryan Schmidt said:
>> I can't install cairo on Tiger:
> [...]
>> .libs/cairo-deflate-stream.o .libs/cairo-svg-surface.o   -L/mp/lib
>> /mp/lib/libpixman-1.dylib -lm /mp/lib/libfontconfig.dylib /mp/
>> lib/libiconv.dylib /mp/lib/libexpat.dylib /mp/lib/libfreetype.dylib /
>> mp/lib/libpng12.dylib /mp/lib/libX11.dylib /mp/lib/libXau.dylib /mp/
>> lib/libXdmcp.dylib -lz -lXrender  -Wl,-framework -Wl,CoreServices -
>> Wl,-framework -Wl,ApplicationServices -Wl,-framework -Wl,CoreServices
>> -Wl,-framework -Wl,ApplicationServices -Wl,-framework -
>> Wl,ApplicationServices   -install_name  /mp/lib/libcairo.2.dylib -
>> compatibility_version 10803 -current_version 10803.6 -Wl,- 
>> single_module
>> /usr/libexec/gcc/i686-apple-darwin8/4.0.1/libtool: can't locate  
>> file for:
>> -lXrender
>
> The xrender port is the one that supplies libXrender, so I'd say if  
> you
> don't have one in /usr/X11R6/lib then you'll need the port.

Yes I do have:

-rw-r--r--   1 root  wheel  78144 Feb 26  2008 /usr/X11R6/lib/ 
libXrender.1.2.dylib
lrwxr-xr-x   1 root  wheel     20 Sep  5 20:11 /usr/X11R6/lib/ 
libXrender.1.dylib -> libXrender.1.2.dylib
-rw-r--r--   1 root  wheel  78684 Mar 23  2007 /usr/X11R6/lib/ 
libXrender.a
lrwxr-xr-x   1 root  wheel     20 Sep  5 20:11 /usr/X11R6/lib/ 
libXrender.dylib -> libXrender.1.2.dylib


> Though oddly I
> notice there's no reference to /usr/X11R6/lib in that compile line  
> at all,
> which means it may not see one there even if you do have it.  Since  
> things
> have been in flux, perhaps something became attached to the one in
> ${prefix}/lib so it isn't looking in /usr/X11R6 at all now?

I would not be surprised if it assumed that libXrender is in the same  
place that libX11 is. I may just have to reinstall all X-using ports,  
like Jeremy says.




From florian.ebeling at gmail.com  Thu Jan 15 12:57:14 2009
From: florian.ebeling at gmail.com (Florian Ebeling)
Date: Thu, 15 Jan 2009 21:57:14 +0100
Subject: Wiki-like markup for Guide
In-Reply-To: <496E8DD7.7040001@macports.org>
References: <fc.004c4c5811388f1a004c4c5811388f1a.1138aaf5@biola.edu>
	<5cbbe4ae0901140918l5aedf54m217d34b658e74fa3@mail.gmail.com>
	<496E8DD7.7040001@macports.org>
Message-ID: <299AB760-0ECD-4B3C-9114-CE2B1CF03497@gmail.com>

On 15.01.2009, at 02:13, Rainer M?ller <raimue at macports.org> wrote:

> C. Florian Ebeling wrote:
>>> And I think the more complex structured environment of DocBook has  
>>> been a
>>> benefit.  I realize that markdown (and other ones) support a  
>>> structure as
>>> well, but we'd I think we'd have to come up with a fairly complex  
>>> style
>>> guide for its use to support a consistent style to get the  
>>> functionality
>>> we now have.  In other words, we'd end up creating a DTD, which is  
>>> what
>>> DocBook is.  So my opinion is that it would take a lot of work to  
>>> get the
>>> functionality we now have, and we'd likely not do a good enough  
>>> job with a
>>> DTD to have as consistent a style as we have now.
>>
>> Ok, then let's just keep docbook. I thought other might consider it  
>> combersome
>> as well, but if that's not the case, then so be it :)
>
> I agree with Florian that editing our guide is not very easy. XML is a
> nice exchange format for structured data, but I don't like to edit  
> it by
> hand.
>
> Maybe we could consider asciidoc as it offers an easy syntax, but is  
> in
> fact a converter from ASCII to DocBook XML.
>
>  http://www.methods.co.nz/asciidoc/

I had a look at it and I really like it. It pretty much what I had in  
mind. Plus it has the additional benefit of covering the fully  
expressiveness of docbook.

I contacted the author already about the one question that remains  
open; unfortunately there isn't currently a translator from xml to the  
markup. However that's not an unsurmountable obstacle either.

Florian



>
>
> Rainer

From ryandesign at macports.org  Thu Jan 15 16:24:32 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 15 Jan 2009 18:24:32 -0600
Subject: [45428] trunk/dports/aqua/Books/Portfile
In-Reply-To: <20090115213150.88C6FC56717@beta.macosforge.org>
References: <20090115213150.88C6FC56717@beta.macosforge.org>
Message-ID: <B0F9918F-B405-474C-8B87-1537E2F1B270@macports.org>

On Jan 15, 2009, at 15:31, snc at macports.org wrote:

> Revision: 45428
>           http://trac.macports.org/changeset/45428
> Author:   snc at macports.org
> Date:     2009-01-15 13:31:50 -0800 (Thu, 15 Jan 2009)
> Log Message:
> -----------
> updated version/download per ticket #17363, add missing attrs
>
> Modified Paths:
> --------------
>     trunk/dports/aqua/Books/Portfile
>
> Modified: trunk/dports/aqua/Books/Portfile
> ===================================================================
> --- trunk/dports/aqua/Books/Portfile	2009-01-15 20:56:57 UTC (rev  
> 45427)
> +++ trunk/dports/aqua/Books/Portfile	2009-01-15 21:31:50 UTC (rev  
> 45428)
> @@ -1,10 +1,10 @@
> +# -*- 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
> -PortGroup		xcode 1.0
>
>  name			Books
> -version			2.2.0
> +version			3.2.2
>  categories		aqua
>  maintainers		nomaintainer
>  description		Books provides a virtual card catalog for your  
> personal library.
> @@ -17,18 +17,44 @@
>  					retrieval, and XML support for importing and exporting \
>  					collection information in HTML and XML.
>
> +platforms       darwin
>  homepage		http://books.aetherial.net/
> -master_sites	http://homepage.mac.com/cjkarr/Books/
> -distname		Source-${version}
> -extract.suffix	.tgz
> +master_sites	${homepage}downloads/
> +distname		${name}_${version}
> +extract.cmd     bzip2

Please use "use_bzip2 yes" instead of setting the extract.cmd.

> +extract.suffix  .tbz
>
> -checksums		md5 a7c75e8931dee9b5bc0733a71c3f307e \
> -				sha1 2a1460331f9037c2da9112cfd03b19d62ee30d46 \
> -				rmd160 0a8932fb148f389f878b1ea89211420f606d9875
> +platform darwin 6 {
> +pre-fetch {
> +return -code error "\n
> +    ${name} ${version} will not install on less than OS X 10.4 and  
> there isn't a
> +    a ${name} 2.x port contributed as yet to accomodate 10.3.9\n"
> +}
> +}
>
> +platform darwin 7 {
> +pre-fetch {
> +return -code error "\n
> +    ${name} ${version} will not install on less than OS X 10.4 and  
> there isn't a
> +    a ${name} 2.x port contributed as yet to accomodate 10.3.9\n"
> +}
> +}
> +
> +checksums		md5 4c832de22a99f8b30e10cd988a8dd36d \
> +				sha1 e086b62972a243465bd5d1d223c93b4ac0e44f83 \
> +				rmd160 4a0cf32a8d79daf92fbf80c6e92f5048fe9e82ef
> +
>  worksrcdir		${name}
>
> +prefix          /Applications/MacPorts

Please use ${applications_dir} instead of assuming /Applications/ 
MacPorts; this is a user-configurable location as of MacPorts 1.7.0.

>  universal_variant no
> +use_configure   no
> +build {}
> +destroot {
> +    set appPath ${destroot}/Applications/MacPorts
> +    xinstall -d ${appPath}
> +    file copy ${worksrcpath}.app ${appPath}
> +}
>
>  livecheck.check	regex
>  livecheck.url	http://books.aetherial.net/wordpress/


From ryandesign at macports.org  Thu Jan 15 19:45:35 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 15 Jan 2009 21:45:35 -0600
Subject: nice configure
In-Reply-To: <9B38B4DE-9601-4065-853A-9834062F4A06@macports.org>
References: <9B38B4DE-9601-4065-853A-9834062F4A06@macports.org>
Message-ID: <1A01CC8F-4F8F-4708-AF64-F17BEB29BA58@macports.org>


On Jan 8, 2009, at 21:54, Ryan Schmidt wrote:

> If you set "buildnicevalue" in ${prefix}/etc/macports/ 
> macports.conf, MacPorts runs the build phase through the "nice"  
> command so that "port" runs at a lower priority and doesn't steal  
> cycles from other processor-intensive tasks you might have running.
>
> Would there be any advantage (or rather any disadvantage) to making  
> the other phases, in particular the configure phase, nice as well?

I can now provide one example in favor of this change: during the  
configure phase, the cmake port compiles a bootstrap version of  
cmake. So it would be nice (a-ha!) if that would also be run through  
nice.

Can anybody suggest a reason why we would not want to make this  
change? If not, I will file an enhancement request.



From ryandesign at macports.org  Thu Jan 15 20:33:12 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 15 Jan 2009 22:33:12 -0600
Subject: haskell port group
In-Reply-To: <20090115052156.GL711@ninagal.withay.com>
References: <20090115052156.GL711@ninagal.withay.com>
Message-ID: <9ECD6A33-65A4-484D-8949-8438E785820F@macports.org>

On Jan 14, 2009, at 23:21, Bryan Blackburn wrote:

> FYI, for those interested, I just added a port group for haskell  
> [1], which
> currently supports only ghc (which seems okay since the other hs-*  
> ports I
> checked are all ghc-specific).  It does the standard 'runhaskell  
> Setup...'
> routine.


This is good, that we can add port groups so easily now.

We should add one for cmake too. If nobody else is working on that,  
maybe I can tackle it soon.




From ryandesign at macports.org  Thu Jan 15 22:51:27 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 16 Jan 2009 00:51:27 -0600
Subject: cairo on Tiger: can't locate file for: -lXrender
In-Reply-To: <18615471-0B60-405A-9EF4-863A5AFE7CE1@macports.org>
References: <C15F7E24-F677-47C4-9128-88A2787BF7B4@macports.org>
	<18615471-0B60-405A-9EF4-863A5AFE7CE1@macports.org>
Message-ID: <F07BE2C0-814D-40CF-BF99-548DBB513D20@macports.org>


On Jan 14, 2009, at 21:12, Jeremy Huddleston wrote:

> 1) uninstall xorg-lib* and set the +system_x11 variant, so they are  
> just stubs when we switch to port:* dependencies
>
> or
>
> 2) Just install xorg-libs to make sure you have all the X11  
> libraries in /mp.
>
> You should probably go through and rebuild everything that depends  
> on X11 to make sure you have consistent linking

I'm going with option 2 at the moment, hence the tickets I've been  
filing about various xorg-* ports. :)


From jeremyhu at macports.org  Fri Jan 16 00:12:14 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Fri, 16 Jan 2009 00:12:14 -0800
Subject: cairo on Tiger: can't locate file for: -lXrender
In-Reply-To: <F07BE2C0-814D-40CF-BF99-548DBB513D20@macports.org>
References: <C15F7E24-F677-47C4-9128-88A2787BF7B4@macports.org>
	<18615471-0B60-405A-9EF4-863A5AFE7CE1@macports.org>
	<F07BE2C0-814D-40CF-BF99-548DBB513D20@macports.org>
Message-ID: <85FFE1E9-7E54-40EC-B7B6-E840CF79646F@macports.org>


On Jan 15, 2009, at 22:51, Ryan Schmidt wrote:

>
> On Jan 14, 2009, at 21:12, Jeremy Huddleston wrote:
>
>> 1) uninstall xorg-lib* and set the +system_x11 variant, so they are  
>> just stubs when we switch to port:* dependencies
>>
>> or
>>
>> 2) Just install xorg-libs to make sure you have all the X11  
>> libraries in /mp.
>>
>> You should probably go through and rebuild everything that depends  
>> on X11 to make sure you have consistent linking
>
> I'm going with option 2 at the moment, hence the tickets I've been  
> filing about various xorg-* ports. :)

Great!  Thanks, that can certainly use the stress to weed out corner  
cases and catch those +universal and manpath stuff that slips through  
the filters sometimes. =)





From illogical1 at gmail.com  Fri Jan 16 04:13:31 2009
From: illogical1 at gmail.com (Orville Bennett)
Date: Fri, 16 Jan 2009 07:13:31 -0500
Subject: cmake portgroup (then kde portgroup)
Message-ID: <00B6BF79-944C-4486-BADA-C82884AE8504@gmail.com>

A while ago ryan asked if i could make a cmake portgroup and i  
accepted the job, with some trepidation. I have some free time now and  
would like to begin working on that. I'd like some information on how  
to go about doing this portgroup.

disclaimer: it would be totally based on the needs of the kde  
portfiles i'm maintaining, which by the way, are finally ready to be  
widely used now :-)
If there is anything outside of kde and its dependencies using cmake i  
don't about it.
Also I'm not mr. ?ber coder guy so wordy documentation on this is a  
plus. I've seen http://trac.macports.org/browser/trunk/dports/_resources/port1.0/group/haskell-1.0.tcl?rev=45388 
  and i'm still confused. :-)

P.S. if you've told me any of this information before i've forgotten.  
This thread is an attempt at preventing that from happening once again.
@ ryan: sorry for taking so long, i hadn't forgotten, was just quite  
busy.



From ryandesign at macports.org  Fri Jan 16 07:48:15 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 16 Jan 2009 09:48:15 -0600
Subject: cmake portgroup (then kde portgroup)
In-Reply-To: <00B6BF79-944C-4486-BADA-C82884AE8504@gmail.com>
References: <00B6BF79-944C-4486-BADA-C82884AE8504@gmail.com>
Message-ID: <BD59D75F-7BA2-42DB-9A28-652E8C7C3BA2@macports.org>

On Jan 16, 2009, at 06:13, Orville Bennett wrote:

> A while ago ryan asked if i could make a cmake portgroup and i  
> accepted the job, with some trepidation. I have some free time now  
> and would like to begin working on that. I'd like some information  
> on how to go about doing this portgroup.
>
> disclaimer: it would be totally based on the needs of the kde  
> portfiles i'm maintaining, which by the way, are finally ready to  
> be widely used now :-)
> If there is anything outside of kde and its dependencies using  
> cmake i don't about it.
> Also I'm not mr. ?ber coder guy so wordy documentation on this is a  
> plus. I've seen http://trac.macports.org/browser/trunk/dports/ 
> _resources/port1.0/group/haskell-1.0.tcl?rev=45388 and i'm still  
> confused. :-)
>
> P.S. if you've told me any of this information before i've  
> forgotten. This thread is an attempt at preventing that from  
> happening once again.
> @ ryan: sorry for taking so long, i hadn't forgotten, was just  
> quite busy.

I don't know what documentation we have, but basically you take any  
statements that you find yourself repeating over and over again in  
portfiles and move them into a portgroup file. Look at the existing  
portgroup files for more information.

And yes, there are plenty of non-KDE ports using cmake. You might  
want to seek them out and look at them to see if there are ways of  
dealing with cmake that you haven't been using in your KDE ports, or  
maybe you'll see parts that you thought were common to cmake but  
which are only common to your KDE ports (hence probably your thought  
of a KDE portgroup next).



From blb at macports.org  Fri Jan 16 13:01:48 2009
From: blb at macports.org (Bryan Blackburn)
Date: Fri, 16 Jan 2009 14:01:48 -0700
Subject: cmake portgroup (then kde portgroup)
In-Reply-To: <BD59D75F-7BA2-42DB-9A28-652E8C7C3BA2@macports.org>
References: <00B6BF79-944C-4486-BADA-C82884AE8504@gmail.com>
	<BD59D75F-7BA2-42DB-9A28-652E8C7C3BA2@macports.org>
Message-ID: <20090116210148.GB995@ninagal.withay.com>

On Fri, Jan 16, 2009 at 09:48:15AM -0600, Ryan Schmidt said:
> On Jan 16, 2009, at 06:13, Orville Bennett wrote:
>
>> A while ago ryan asked if i could make a cmake portgroup and i accepted 
>> the job, with some trepidation. I have some free time now and would like 
>> to begin working on that. I'd like some information on how to go about 
>> doing this portgroup.
>>
>> disclaimer: it would be totally based on the needs of the kde portfiles 
>> i'm maintaining, which by the way, are finally ready to be widely used 
>> now :-)
>> If there is anything outside of kde and its dependencies using cmake i 
>> don't about it.
>> Also I'm not mr. ?ber coder guy so wordy documentation on this is a  
>> plus. I've seen http://trac.macports.org/browser/trunk/dports/ 
>> _resources/port1.0/group/haskell-1.0.tcl?rev=45388 and i'm still  
>> confused. :-)
>>
>> P.S. if you've told me any of this information before i've forgotten. 
>> This thread is an attempt at preventing that from happening once again.
>> @ ryan: sorry for taking so long, i hadn't forgotten, was just quite 
>> busy.
>
> I don't know what documentation we have, but basically you take any  
> statements that you find yourself repeating over and over again in  
> portfiles and move them into a portgroup file. Look at the existing  
> portgroup files for more information.

Looking at the existing should be a good start, but start with the python
ones first, they're the simplest.  perl and haskell are slightly more code
but should still be pretty obvious.  It's when you get to ruby and xcode
that you see quite a bit of code.

But basically, like Ryan says, the simplest (like the python ones) just set
stuff you normally see in a Portfile, since PortGroup is basically like an
#include in C/C++ (or require, import, etc, depending on what languages you
may know).

At least perl and haskell have a .setup proc that you call from the Portfile
with a few arguments and that allows them to create varying fields for the
port (like name, version, distname).  But the python bits just setup how to
basically build a python module, leaving all the rest to the Portfile.

Bryan


From alakazam at macports.org  Fri Jan 16 14:49:27 2009
From: alakazam at macports.org (Olivier Le Floch)
Date: Fri, 16 Jan 2009 23:49:27 +0100
Subject: [MacPorts] #18050: Octave failes to build, Issue with CSparse
In-Reply-To: <258e18ac0901161447k4f34338aj43dbf4788f99052@mail.gmail.com>
References: <050.f1e8cadf7b297b291b3c5480f8f1c80f@macports.org>
	<059.4bc553caeff53ef6323c6b5841dd7236@macports.org>
	<258e18ac0901161447k4f34338aj43dbf4788f99052@mail.gmail.com>
Message-ID: <1895F9DC-02C4-423B-9AE5-5ED4F3DA7B91@macports.org>

On 16 janv. 09, at 23:47, Egan Ford wrote:

> It's very large.  I uploaded to here:
> http://xmission.com/~egan/octave-build.out.gz

Please keep the discussion on trac :

>> Ticket URL: <http://trac.macports.org/ticket/18050#comment:2>
>>


I've attached your log to it :

> http://trac.macports.org/attachment/ticket/18050/octave-build.out


Thanks,

-- 
Olivier Le Floch


From jmr at macports.org  Sat Jan 17 06:01:41 2009
From: jmr at macports.org (Joshua Root)
Date: Sun, 18 Jan 2009 01:01:41 +1100
Subject: [MacPorts] #17983: gettext: universal LP64 fixes
In-Reply-To: <061.fbc15d811221dfc7779858e36cdf5350@macports.org>
References: <052.66dc3927c0634a2a853b0243777a1962@macports.org>
	<061.fbc15d811221dfc7779858e36cdf5350@macports.org>
Message-ID: <4971E4C5.4040509@macports.org>

MacPorts wrote:
> #17983: gettext: universal LP64 fixes
> ------------------------------+---------------------------------------------
>  Reporter:  jmr@?             |       Owner:  ryandesign@?           
>      Type:  defect            |      Status:  assigned               
>  Priority:  Normal            |   Milestone:  Port Bugs              
> Component:  ports             |     Version:  1.7.0                  
>  Keywords:                    |        Port:  gettext                
> ------------------------------+---------------------------------------------
> Changes (by ryandesign@?):
> 
>   * status:  new => assigned
> 
> 
> Comment:
> 
>  Thanks, I'll get to work on this.
> 
>  How do you find these things? I mean, the port builds for all four archs
>  without these changes. How can I know that, even though it built, it isn't
>  right?

So far, by manual inspection of config.h. A more scalable solution going
forward would be a script that configures both ways and checks for any
difference.

- Josh

From jeremyhu at macports.org  Sat Jan 17 11:38:02 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Sat, 17 Jan 2009 11:38:02 -0800
Subject: [PATCH] port: dependencies for X11
Message-ID: <1E6DE4DE-E855-4576-87A6-0700830C7B78@macports.org>

This patch touches the 252 ports (listed at bottom) which depend on  
X11 with a lib: style dependency.  It changes these to port:  
dependencies.  If it was lib:...:XFree86 or lib:...:xorg, the new  
dependency is port:xorg-libs.

The ports with port:xorg-libs in their dependencies haven't been  
tested by me.  Most of these are outside the x11 category.  After this  
effort gets committed, I'll start simplifying the dependencies in  
those ports like I did most of the ones in the x11 category.

http://people.freedesktop.org/~jeremyhu/x11-dep.patch

Please review.

Thanks,
Jeremy


Affected ports:
aqua/osx2x/Portfile
audio/arts/Portfile
devel/allegro/Portfile
devel/dbus/Portfile
devel/ddd/Portfile
devel/gtkglext/Portfile
devel/inventor/Portfile
devel/libast/Portfile
devel/libgdiplus/Portfile
devel/libsdl/Portfile
devel/mono/Portfile
devel/ode/Portfile
devel/pnetlib/Portfile
devel/rdesktop-devel/Portfile
devel/t1lib/Portfile
editors/TeXmacs/Portfile
editors/aee/Portfile
editors/efte/Portfile
editors/elvis/Portfile
editors/emacs/Portfile
editors/vim/Portfile
editors/yudit/Portfile
emulators/basiliskii/Portfile
emulators/freesci/Portfile
emulators/pearpc/Portfile
emulators/spim/Portfile
emulators/vice/Portfile
games/angband/Portfile
games/cannonsmash/Portfile
games/gnushogi/Portfile
games/lincity-ng/Portfile
games/lincity/Portfile
games/qthello/Portfile
games/teg/Portfile
games/wesnoth/Portfile
games/xbill/Portfile
games/xboard/Portfile
games/xdigger/Portfile
games/xmahjongg/Portfile
games/xmj/Portfile
games/xskat/Portfile
gnome/eog/Portfile
gnome/gnome-desktop/Portfile
gnome/gnome-mag/Portfile
gnome/startup-notification/Portfile
graphics/Coin/Portfile
graphics/ImageMagick/Portfile
graphics/SimGear/Portfile
graphics/aalib/Portfile
graphics/antigraingeometry/Portfile
graphics/cairo-devel/Portfile
graphics/cairo/Portfile
graphics/fnlib/Portfile
graphics/fontforge/Portfile
graphics/gd2/Portfile
graphics/glitz/Portfile
graphics/glut/Portfile
graphics/graphviz-devel/Portfile
graphics/graphviz/Portfile
graphics/imlib2/Portfile
graphics/jasper/Portfile
graphics/libcaca/Portfile
graphics/libungif/Portfile
graphics/libwmf/Portfile
graphics/magicpoint/Portfile
graphics/pgplot/Portfile
graphics/plotutils/Portfile
graphics/povray/Portfile
graphics/tgif/Portfile
graphics/vtk/Portfile
graphics/vtk5/Portfile
graphics/xaos/Portfile
graphics/xli/Portfile
graphics/xpdf/Portfile
graphics/xv/Portfile
kde/kdelibs3/Portfile
lang/mit-scheme/Portfile
lang/polyml/Portfile
lang/squeak/Portfile
lang/swi-prolog-devel/Portfile
lang/swi-prolog/Portfile
lang/yabasic/Portfile
math/R/Portfile
math/gnuplot/Portfile
math/oleo/Portfile
math/ploticus/Portfile
multimedia/MPlayer/Portfile
multimedia/emotion/Portfile
multimedia/mpeg2vidcodec/Portfile
multimedia/xine-lib/Portfile
net/gpsd/Portfile
net/rdesktop/Portfile
net/scotty/Portfile
net/wap11gui/Portfile
perl/p5-term-gnuplot/Portfile
print/espgs/Portfile
print/ghostscript/Portfile
print/gv/Portfile
print/teTeX/Portfile
science/geomview/Portfile
science/molden/Portfile
science/rasmol/Portfile
science/tempo/Portfile
science/triangle/Portfile
science/xastir/Portfile
security/pwsafe/Portfile
sysutils/wmcpuload/Portfile
sysutils/wmmemmon/Portfile
tex/pTeX/Portfile
tex/texlive_base/Portfile
textproc/most/Portfile
textproc/tkman/Portfile
www/links/Portfile
x11/Eterm/Portfile
x11/SoXt/Portfile
x11/Xaw3d/Portfile
x11/abclock/Portfile
x11/advi/Portfile
x11/appres/Portfile
x11/aterm/Portfile
x11/awesome/Portfile
x11/bdftopcf/Portfile
x11/bitmap/Portfile
x11/blackbox/Portfile
x11/blt/Portfile
x11/desklaunch/Portfile
x11/editres/Portfile
x11/emiclock/Portfile
x11/enlightenment/Portfile
x11/evilwm/Portfile
x11/eyeclock/Portfile
x11/fireworkx/Portfile
x11/fluxbox/Portfile
x11/fonttosfnt/Portfile
x11/fox/Portfile
x11/fslsfonts/Portfile
x11/fstobdf/Portfile
x11/fvwm/Portfile
x11/fvwm2/Portfile
x11/glw/Portfile
x11/grace/Portfile
x11/gtk1/Portfile
x11/gtk2/Portfile
x11/gtk28/Portfile
x11/iceauth/Portfile
x11/icewm/Portfile
x11/ico/Portfile
x11/keylaunch/Portfile
x11/kinput2-macim/Portfile
x11/lesstif/Portfile
x11/listres/Portfile
x11/luit/Portfile
x11/mesa/Portfile
x11/mkfontscale/Portfile
x11/mlterm/Portfile
x11/mrxvt/Portfile
x11/neXtaw/Portfile
x11/oclock/Portfile
x11/openbox/Portfile
x11/openmotif/Portfile
x11/oroborus/Portfile
x11/pango-devel/Portfile
x11/pango/Portfile
x11/qt3/Portfile
x11/qt4-x11/Portfile
x11/ratpoison/Portfile
x11/rxvt-unicode/Portfile
x11/rxvt/Portfile
x11/setxkbmap/Portfile
x11/showfont/Portfile
x11/tightvnc/Portfile
x11/tk/Portfile
x11/twm/Portfile
x11/unclutter/Portfile
x11/viewres/Portfile
x11/vnc/Portfile
x11/vtwm/Portfile
x11/windowmaker/Portfile
x11/wine-devel/Portfile
x11/wine/Portfile
x11/wmcalclock/Portfile
x11/wmclock/Portfile
x11/wmcube/Portfile
x11/wmii/Portfile
x11/x11perf/Portfile
x11/xauth/Portfile
x11/xcalc/Portfile
x11/xcb/Portfile
x11/xclipboard/Portfile
x11/xclock/Portfile
x11/xconsole/Portfile
x11/xcursorgen/Portfile
x11/xditview/Portfile
x11/xdm/Portfile
x11/xdpyinfo/Portfile
x11/xearth/Portfile
x11/xedit/Portfile
x11/xev/Portfile
x11/xeyes/Portfile
x11/xfd/Portfile
x11/xfontsel/Portfile
x11/xforms/Portfile
x11/xfs/Portfile
x11/xfsinfo/Portfile
x11/xgc/Portfile
x11/xhost/Portfile
x11/xinit/Portfile
x11/xinput/Portfile
x11/xkbcomp/Portfile
x11/xkbevd/Portfile
x11/xkbprint/Portfile
x11/xkbutils/Portfile
x11/xkill/Portfile
x11/xload/Portfile
x11/xlogo/Portfile
x11/xlsatoms/Portfile
x11/xlsclients/Portfile
x11/xlsfonts/Portfile
x11/xmag/Portfile
x11/xman/Portfile
x11/xmessage/Portfile
x11/xmh/Portfile
x11/xmodmap/Portfile
x11/xmore/Portfile
x11/xnee/Portfile
x11/xping/Portfile
x11/xplanet/Portfile
x11/xpr/Portfile
x11/xprop/Portfile
x11/xrandr/Portfile
x11/xrdb/Portfile
x11/xrefresh/Portfile
x11/xrender/Portfile
x11/xrmap/Portfile
x11/xroot/Portfile
x11/xruskb/Portfile
x11/xsel/Portfile
x11/xset/Portfile
x11/xsetmode/Portfile
x11/xsetpointer/Portfile
x11/xsetroot/Portfile
x11/xsm/Portfile
x11/xstdcmap/Portfile
x11/xteddy/Portfile
x11/xterm/Portfile
x11/xtrap/Portfile
x11/xvinfo/Portfile
x11/xwd/Portfile
x11/xwininfo/Portfile
x11/xwud/Portfile
xfce/libxfce4mcs/Portfile
xfce/xfwm4/Portfile


From macports-mgr at lists.macosforge.org  Sat Jan 17 13:15:03 2009
From: macports-mgr at lists.macosforge.org (macports-mgr at lists.macosforge.org)
Date: Sat, 17 Jan 2009 13:15:03 -0800 (PST)
Subject: PortIndex2MySQL run failure on Saturday 2009-01-17 at 13:15:00
Message-ID: <20090117211503.EC1C11ADDE6A@gamma.macosforge.org>


Synchronizing local ports tree from file:///rsync/macports-san/release/ports/
Error: CHILDSTATUS 49264 1: ERROR 1062 (23000) at line 1670: Duplicate entry 'phonon' for key 1

From jm at poure.com  Sun Jan 18 01:49:52 2009
From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=)
Date: Sun, 18 Jan 2009 10:49:52 +0100
Subject: How to test a port file locally?
Message-ID: <1232272192.9606.4.camel@debian>

Dear Friends,

Following a message on the list a few weeks ago, I was able to get
access to a remote MacOsX computer via SSH. 

I plan to submit a set a packages to be able to build MLT and Kdenlive
video editor to bring free tool to MacOsX users in the GNU philosophy.

First question about writing ports, that i did not find on
http://guide.macports.org

Is there a way to test your portfile locally before submiting it? This
reduces the risk for errors.

Thank you very much for your attention and help.

Kind regards,
Jean-Michel


From jmr at macports.org  Sun Jan 18 04:36:45 2009
From: jmr at macports.org (Joshua Root)
Date: Sun, 18 Jan 2009 23:36:45 +1100
Subject: How to test a port file locally?
In-Reply-To: <1232272192.9606.4.camel@debian>
References: <1232272192.9606.4.camel@debian>
Message-ID: <4973225D.2030402@macports.org>

Jean-Michel Pour? wrote:
> Dear Friends,
> 
> Following a message on the list a few weeks ago, I was able to get
> access to a remote MacOsX computer via SSH. 
> 
> I plan to submit a set a packages to be able to build MLT and Kdenlive
> video editor to bring free tool to MacOsX users in the GNU philosophy.
> 
> First question about writing ports, that i did not find on
> http://guide.macports.org
> 
> Is there a way to test your portfile locally before submiting it? This
> reduces the risk for errors.

The easiest way for a single port is to cd to the directory containing
the Portfile. Then when you don't specify a port name on the command
line, port will use the one in the current directory. For example:

cd path/to/my_port
sudo port -v install

If there are dependencies on other ports that are not yet in the
official tree, you need to add a local repository. See:
<http://guide.macports.org/#development.local-repositories>

- Josh

From jeremyhu at macports.org  Sun Jan 18 16:30:23 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Sun, 18 Jan 2009 16:30:23 -0800
Subject: Updating xorg-libs dependencies
Message-ID: <7FFC6932-FCF5-46C7-9A87-1E599A7073E2@macports.org>

So there are 94 ports that have a 'port:xorg-libs' dependency.  Rather  
than relying on this meta-port, these ports should selectively rely on  
individual X11 libraries.  I've made a bash script to help determine  
these dependencies, and I'd like to pass it on in hopes others looking  
for something to do can tackle this too.

At the bottom of this email is a list of ports that need to be  
updated.  This shell script is a little hackish.  If you don't use '/ 
opt/local', you should edit the top of the script and set MP to your  
prefix.  This script takes a single argument (the name of the port you  
wish to check) and spits out a list of X11 dependencies it found.  It  
just checks 'otool -L' output from $prefix/bin/* and $prefix/lib/*, so  
if the port installs items into other places or does a dlopen(),  
you'll need to check that separately.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mk_x11_deps.sh
Type: application/octet-stream
Size: 4090 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090118/1813fee8/attachment.obj>
-------------- next part --------------



Here are a list of ports that need to be updated:
aqua/osx2x
audio/arts
devel/allegro
devel/inventor
devel/mono
devel/ode
devel/pnetlib
devel/rdesktop-devel
editors/TeXmacs
editors/aee
editors/efte
editors/elvis
editors/emacs
editors/vim
editors/yudit
emulators/basiliskii
emulators/pearpc
emulators/vice
games/angband
games/cannonsmash
games/gnushogi
games/lincity
games/lincity-ng
games/qthello
games/wesnoth
games/xbill
games/xboard
games/xdigger
games/xmahjongg
games/xmj
games/xskat
gnome/gnome-desktop
graphics/ImageMagick
graphics/SimGear
graphics/antigraingeometry
graphics/fnlib
graphics/gd2
graphics/glitz
graphics/glut
graphics/graphviz
graphics/graphviz-devel
graphics/libcaca
graphics/pgplot
graphics/plotutils
graphics/povray
graphics/vtk
graphics/vtk5
graphics/xaos
graphics/xli
graphics/xpdf
graphics/xv
kde/kdelibs3
lang/mit-scheme
lang/polyml
lang/squeak
lang/swi-prolog
lang/swi-prolog-devel
lang/yabasic
math/gnuplot
math/oleo
math/ploticus
multimedia/MPlayer
multimedia/emotion
multimedia/mpeg2vidcodec
multimedia/xine-lib
net/gpsd
net/scotty
net/wap11gui
perl/p5-term-gnuplot
print/espgs
print/teTeX
science/geomview
science/molden
science/rasmol
science/tempo
science/triangle
science/xastir
security/pwsafe
sysutils/wmcpuload
sysutils/wmmemmon
tex/pTeX
tex/texlive_base
textproc/most
textproc/tkman
www/links
x11/blt
x11/gtk28
x11/kinput2-macim
x11/vnc
x11/wmcalclock
x11/xrmap
x11/xruskb
xfce/libxfce4mcs
xfce/xfwm4


From emer at emer.net  Sun Jan 18 17:03:43 2009
From: emer at emer.net (Mark Anderson)
Date: Sun, 18 Jan 2009 20:03:43 -0500
Subject: [MacPorts] #18077: tesseract: upgrade to 2.03
In-Reply-To: <066.735465453bbfd60757ba8ebb56d771ce@macports.org>
References: <057.ad42f2fd6c68cb3869b3a8e564dff239@macports.org>
	<066.735465453bbfd60757ba8ebb56d771ce@macports.org>
Message-ID: <2cf4100f0901181703u6d4e77bdyfa7555ad90453889@mail.gmail.com>

I'm on it.   I really don't think it should be a big deal.

Mark

On Sun, Jan 18, 2009 at 8:41 AM, MacPorts <noreply at macports.org> wrote:
> #18077: tesseract: upgrade to 2.03
> -----------------------------------+----------------------------------------
>  Reporter:  steven@?               |       Owner:  emer@?
>     Type:  enhancement            |      Status:  new
>  Priority:  Normal                 |   Milestone:  Port Updates
> Component:  ports                  |     Version:  1.7.0
>  Keywords:                         |        Port:  tesseract
> -----------------------------------+----------------------------------------
> Changes (by jmr@?):
>
>  * owner:  macports-tickets@? => emer@?
>  * type:  defect => enhancement
>  * milestone:  Port Bugs => Port Updates
>
>
> --
> Ticket URL: <http://trac.macports.org/ticket/18077#comment:1>
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS
>

From ryandesign at macports.org  Sun Jan 18 17:21:48 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 18 Jan 2009 19:21:48 -0600
Subject: [45614] trunk/base/src/port1.0/portdestroot.tcl
In-Reply-To: <20090119000745.0D9AFC87812@beta.macosforge.org>
References: <20090119000745.0D9AFC87812@beta.macosforge.org>
Message-ID: <CAE1B2BE-E797-427B-AA0B-3D9A74504276@macports.org>

On Jan 18, 2009, at 18:07, raimue at macports.org wrote:

> Revision: 45614
>           http://trac.macports.org/changeset/45614
> Author:   raimue at macports.org
> Date:     2009-01-18 16:07:44 -0800 (Sun, 18 Jan 2009)
> Log Message:
> -----------
> port1.0/portdestroot.tcl:
> Create ${applications_dir} and ${frameworks_dir} in destroot_start,  
> so we do
> not have to create them in Portfiles.

Thank you! Great idea.

> Modified Paths:
> --------------
>     trunk/base/src/port1.0/portdestroot.tcl
>
> Modified: trunk/base/src/port1.0/portdestroot.tcl
> ===================================================================
> --- trunk/base/src/port1.0/portdestroot.tcl	2009-01-19 00:05:38 UTC  
> (rev 45613)
> +++ trunk/base/src/port1.0/portdestroot.tcl	2009-01-19 00:07:44 UTC  
> (rev 45614)
> @@ -88,6 +88,7 @@
>  proc destroot_start {args} {
>      global UI_PREFIX prefix portname porturl destroot os.platform  
> destroot.clean portsharepath
>      global destroot::oldmask destroot.umask
> +    global applications_dir frameworks_dir
>
>      ui_msg "$UI_PREFIX [format [msgcat::mc "Staging %s into  
> destroot"] ${portname}]"
>
> @@ -101,6 +102,8 @@
>      file mkdir "${destroot}"
>      if { ${os.platform} == "darwin" } {
>          system "cd \"${destroot}\" && ${mtree} -e -U -f [file join  
> ${portsharepath} install macosx.mtree]"
> +        file mkdir "${destroot}/${applications_dir}"
> +        file mkdir "${destroot}/${frameworks_dir}"
>      }
>      file mkdir "${destroot}/${prefix}"
>      system "cd \"${destroot}/${prefix}\" && ${mtree} -e -U -f  
> [file join ${portsharepath} install prefix.mtree]"

They don't need slashes between them, though, do they?




From raimue at macports.org  Sun Jan 18 17:27:16 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Mon, 19 Jan 2009 02:27:16 +0100
Subject: [45614] trunk/base/src/port1.0/portdestroot.tcl
In-Reply-To: <CAE1B2BE-E797-427B-AA0B-3D9A74504276@macports.org>
References: <20090119000745.0D9AFC87812@beta.macosforge.org>
	<CAE1B2BE-E797-427B-AA0B-3D9A74504276@macports.org>
Message-ID: <4973D6F4.9090602@macports.org>

Ryan Schmidt wrote:
>> @@ -101,6 +102,8 @@
>>      file mkdir "${destroot}"
>>      if { ${os.platform} == "darwin" } {
>>          system "cd \"${destroot}\" && ${mtree} -e -U -f [file join  
>> ${portsharepath} install macosx.mtree]"
>> +        file mkdir "${destroot}/${applications_dir}"
>> +        file mkdir "${destroot}/${frameworks_dir}"
>>      }
>>      file mkdir "${destroot}/${prefix}"
>>      system "cd \"${destroot}/${prefix}\" && ${mtree} -e -U -f  
>> [file join ${portsharepath} install prefix.mtree]"
> 
> They don't need slashes between them, though, do they?

I was not sure if it would be okay to leave the slashes out, but as
there is a slash between ${destroot} and ${prefix} a few lines below I
added them.

Probably we could leave it out in all cases, as we always expect
${applications_dir}, ${frameworks_dir} and ${prefix} to be absolute
paths starting with a slash, right?

Rainer

From ryandesign at macports.org  Sun Jan 18 17:29:42 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 18 Jan 2009 19:29:42 -0600
Subject: [45614] trunk/base/src/port1.0/portdestroot.tcl
In-Reply-To: <4973D6F4.9090602@macports.org>
References: <20090119000745.0D9AFC87812@beta.macosforge.org>
	<CAE1B2BE-E797-427B-AA0B-3D9A74504276@macports.org>
	<4973D6F4.9090602@macports.org>
Message-ID: <3FF7C884-8CBC-4F90-9540-2BBBFBF59EE4@macports.org>


On Jan 18, 2009, at 19:27, Rainer M?ller wrote:

> Ryan Schmidt wrote:
>>> @@ -101,6 +102,8 @@
>>>      file mkdir "${destroot}"
>>>      if { ${os.platform} == "darwin" } {
>>>          system "cd \"${destroot}\" && ${mtree} -e -U -f [file join
>>> ${portsharepath} install macosx.mtree]"
>>> +        file mkdir "${destroot}/${applications_dir}"
>>> +        file mkdir "${destroot}/${frameworks_dir}"
>>>      }
>>>      file mkdir "${destroot}/${prefix}"
>>>      system "cd \"${destroot}/${prefix}\" && ${mtree} -e -U -f
>>> [file join ${portsharepath} install prefix.mtree]"
>>
>> They don't need slashes between them, though, do they?
>
> I was not sure if it would be okay to leave the slashes out, but as
> there is a slash between ${destroot} and ${prefix} a few lines below I
> added them.
>
> Probably we could leave it out in all cases, as we always expect
> ${applications_dir}, ${frameworks_dir} and ${prefix} to be absolute
> paths starting with a slash, right?

Right. There should never be a slash before ${prefix}, $ 
{applications_dir} or ${frameworks_dir}, anywhere in MacPorts base or  
in any Portfile, because those variables always begin with a slash.



From ryandesign at macports.org  Sun Jan 18 17:36:36 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 18 Jan 2009 19:36:36 -0600
Subject: [45614] trunk/base/src/port1.0/portdestroot.tcl
In-Reply-To: <3FF7C884-8CBC-4F90-9540-2BBBFBF59EE4@macports.org>
References: <20090119000745.0D9AFC87812@beta.macosforge.org>
	<CAE1B2BE-E797-427B-AA0B-3D9A74504276@macports.org>
	<4973D6F4.9090602@macports.org>
	<3FF7C884-8CBC-4F90-9540-2BBBFBF59EE4@macports.org>
Message-ID: <3085C246-59F6-4B79-945E-64CF4703C228@macports.org>


On Jan 18, 2009, at 19:29, Ryan Schmidt wrote:

> Right. There should never be a slash before ${prefix}, $ 
> {applications_dir} or ${frameworks_dir}, anywhere in MacPorts base  
> or in any Portfile, because those variables always begin with a slash.


I once went on a cleaning spree for this issue; see:

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

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

However there are probably still some maintained ports with this  
issue, and I did not touch the base code.


From ryandesign at macports.org  Sun Jan 18 18:04:42 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 18 Jan 2009 20:04:42 -0600
Subject: [45620] trunk/dports/kde
In-Reply-To: <20090119013119.5F9C9C88EE7@beta.macosforge.org>
References: <20090119013119.5F9C9C88EE7@beta.macosforge.org>
Message-ID: <05E5338F-A034-4659-8E2A-B9776423A12B@macports.org>


On Jan 18, 2009, at 19:31, illogic-al at macports.org wrote:

> Revision: 45620
>           http://trac.macports.org/changeset/45620
> Author:   illogic-al at macports.org
> Date:     2009-01-18 17:31:18 -0800 (Sun, 18 Jan 2009)
> Log Message:
> -----------
> Install programs to ${applications_dir}. When people upgrade crap  
> will be left over in /Applications/KDE4. What's the best way to  
> deal with this?

What will be left over?

If it's necessary data, users will have to move it to wherever it's  
now needed.

If it's unnecessary, they can delete it.


From illogical1 at gmail.com  Sun Jan 18 20:15:20 2009
From: illogical1 at gmail.com (Orville Bennett)
Date: Sun, 18 Jan 2009 23:15:20 -0500
Subject: [45620] trunk/dports/kde
In-Reply-To: <05E5338F-A034-4659-8E2A-B9776423A12B@macports.org>
References: <20090119013119.5F9C9C88EE7@beta.macosforge.org>
	<05E5338F-A034-4659-8E2A-B9776423A12B@macports.org>
Message-ID: <D8F2B97C-721A-4FA6-857E-7CDAE33235DB@gmail.com>


On Jan 18, 2009, at 9:04 PM, Ryan Schmidt wrote:

>
> On Jan 18, 2009, at 19:31, illogic-al at macports.org wrote:
>
>> Revision: 45620
>>         http://trac.macports.org/changeset/45620
>> Author:   illogic-al at macports.org
>> Date:     2009-01-18 17:31:18 -0800 (Sun, 18 Jan 2009)
>> Log Message:
>> -----------
>> Install programs to ${applications_dir}. When people upgrade crap  
>> will be left over in /Applications/KDE4. What's the best way to  
>> deal with this?
>
> What will be left over?
>
> If it's necessary data, users will have to move it to wherever it's  
> now needed.
>
> If it's unnecessary, they can delete it.
>
It's unnecessary. It's the bundles left over that launch the programs.

From ryandesign at macports.org  Sun Jan 18 20:25:03 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 18 Jan 2009 22:25:03 -0600
Subject: [45620] trunk/dports/kde
In-Reply-To: <D8F2B97C-721A-4FA6-857E-7CDAE33235DB@gmail.com>
References: <20090119013119.5F9C9C88EE7@beta.macosforge.org>
	<05E5338F-A034-4659-8E2A-B9776423A12B@macports.org>
	<D8F2B97C-721A-4FA6-857E-7CDAE33235DB@gmail.com>
Message-ID: <119450C1-3B28-4104-BEE1-8539CC47012A@macports.org>

On Jan 18, 2009, at 22:15, Orville Bennett wrote:

> On Jan 18, 2009, at 9:04 PM, Ryan Schmidt wrote:
>
>> On Jan 18, 2009, at 19:31, illogic-al at macports.org wrote:
>>
>>> Revision: 45620
>>>          http://trac.macports.org/changeset/45620
>>> Author:   illogic-al at macports.org
>>> Date:     2009-01-18 17:31:18 -0800 (Sun, 18 Jan 2009)
>>> Log Message:
>>> -----------
>>> Install programs to ${applications_dir}. When people upgrade crap  
>>> will be left over in /Applications/KDE4. What's the best way to  
>>> deal with this?
>>
>> What will be left over?
>>
>> If it's necessary data, users will have to move it to wherever  
>> it's now needed.
>>
>> If it's unnecessary, they can delete it.
>
> It's unnecessary. It's the bundles left over that launch the programs.

Were they not part of the destroot, or why are they not being removed  
when the old port is uninstalled?


From illogical1 at gmail.com  Sun Jan 18 20:31:57 2009
From: illogical1 at gmail.com (Orville Bennett)
Date: Sun, 18 Jan 2009 23:31:57 -0500
Subject: [45620] trunk/dports/kde
In-Reply-To: <119450C1-3B28-4104-BEE1-8539CC47012A@macports.org>
References: <20090119013119.5F9C9C88EE7@beta.macosforge.org>
	<05E5338F-A034-4659-8E2A-B9776423A12B@macports.org>
	<D8F2B97C-721A-4FA6-857E-7CDAE33235DB@gmail.com>
	<119450C1-3B28-4104-BEE1-8539CC47012A@macports.org>
Message-ID: <8A7FEA9A-F0A3-4D52-9765-A28C4BA25DCA@gmail.com>


On Jan 18, 2009, at 11:25 PM, Ryan Schmidt wrote:

> On Jan 18, 2009, at 22:15, Orville Bennett wrote:
>
>> On Jan 18, 2009, at 9:04 PM, Ryan Schmidt wrote:
>>
>>> On Jan 18, 2009, at 19:31, illogic-al at macports.org wrote:
>>>
>>>> Revision: 45620
>>>>         http://trac.macports.org/changeset/45620
>>>> Author:   illogic-al at macports.org
>>>> Date:     2009-01-18 17:31:18 -0800 (Sun, 18 Jan 2009)
>>>> Log Message:
>>>> -----------
>>>> Install programs to ${applications_dir}. When people upgrade crap  
>>>> will be left over in /Applications/KDE4. What's the best way to  
>>>> deal with this?
>>>
>>> What will be left over?
>>>
>>> If it's necessary data, users will have to move it to wherever  
>>> it's now needed.
>>>
>>> If it's unnecessary, they can delete it.
>>
>> It's unnecessary. It's the bundles left over that launch the  
>> programs.
>
> Were they not part of the destroot, or why are they not being  
> removed when the old port is uninstalled?
>
Well, they are a part of the destroot, so ...
just ignore that.

From ryandesign at macports.org  Sun Jan 18 23:42:19 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 19 Jan 2009 01:42:19 -0600
Subject: [45627] trunk/dports/x11/gtk28/Portfile
In-Reply-To: <20090119063833.A09F2C8C019@beta.macosforge.org>
References: <20090119063833.A09F2C8C019@beta.macosforge.org>
Message-ID: <A7240562-7148-48E0-8FED-ACF1E1F1BB42@macports.org>

On Jan 19, 2009, at 00:38, jeremyhu at macports.org wrote:

> gtk28: Simplified X11 dependencies... do we still need this port???

According to r19421 it was created "for those having problems with  
2.10 (or those that need 2.8 for whatever reason)" but I see no ports  
using it and I would guess we can remove it.

There are two open tickets on gtk28; you could ask the reporters of  
those tickets if they have any special need for that version.


From mcalhoun at macports.org  Mon Jan 19 05:33:39 2009
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Mon, 19 Jan 2009 13:33:39 +0000 (UTC)
Subject: xorg-*proto ports and =?utf-8?b?c3lzdGVtX3gxMQ==?=
Message-ID: <loom.20090119T131856-743@post.gmane.org>

Why do the xorg-* ports which have a system_x11 variant still
pull in xorg-*proto ports?
If I need to install install Xft2 +system_x11 (for tk),
I still get header files from xorg-xproto.

I am far from an expert on X11, but it seems to me that we either need to
add a system_x11 variant to the proto ports or trim down the dependencies
of the current system_x11 ports.

I know that there has been much discussion about X11 recently
(some of which I have missed).
Please forgive me if this was covered already.

-Marcus






From emer at emer.net  Mon Jan 19 10:11:31 2009
From: emer at emer.net (Mark Anderson)
Date: Mon, 19 Jan 2009 13:11:31 -0500
Subject: [MacPorts] #18077: tesseract: upgrade to 2.03
In-Reply-To: <066.735465453bbfd60757ba8ebb56d771ce@macports.org>
References: <057.ad42f2fd6c68cb3869b3a8e564dff239@macports.org>
	<066.735465453bbfd60757ba8ebb56d771ce@macports.org>
Message-ID: <2cf4100f0901191011i754fdf3fm24b7ed6c2cf5ae79@mail.gmail.com>

Ok, I've attached a new Portfile to the Ticket.  All that was needed
was a version and checksum update.  Try it out, and let me know if you
run into trouble.

Mark

On Sun, Jan 18, 2009 at 8:41 AM, MacPorts <noreply at macports.org> wrote:
> #18077: tesseract: upgrade to 2.03
> -----------------------------------+----------------------------------------
>  Reporter:  steven@?               |       Owner:  emer@?
>     Type:  enhancement            |      Status:  new
>  Priority:  Normal                 |   Milestone:  Port Updates
> Component:  ports                  |     Version:  1.7.0
>  Keywords:                         |        Port:  tesseract
> -----------------------------------+----------------------------------------
> Changes (by jmr@?):
>
>  * owner:  macports-tickets@? => emer@?
>  * type:  defect => enhancement
>  * milestone:  Port Bugs => Port Updates
>
>
> --
> Ticket URL: <http://trac.macports.org/ticket/18077#comment:1>
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS
>

From jeremyhu at macports.org  Mon Jan 19 10:14:00 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Mon, 19 Jan 2009 10:14:00 -0800
Subject: xorg-*proto ports and system_x11
In-Reply-To: <loom.20090119T131856-743@post.gmane.org>
References: <loom.20090119T131856-743@post.gmane.org>
Message-ID: <B197C5D9-36DD-40FD-A4C1-75F34641E260@macports.org>


On Jan 19, 2009, at 05:33, Marcus Calhoun-Lopez wrote:

> Why do the xorg-* ports which have a system_x11 variant still
> pull in xorg-*proto ports?

yeah, I was on the fence about that, TBH.  They're just header files  
(which need to be compatible with whatever is in $x11prefix anyways),  
and the main reason for doing all of this is to control the lib linking.

> If I need to install install Xft2 +system_x11 (for tk),
> I still get header files from xorg-xproto.

Yeah... it just really complicates things on Tiger with +system_x11 if  
we start pruning out header files that are already available.  For  
example, libAppleWM has stayed the same, but the protocol headers have  
been updated to add new functionality that is necessary for the new  
server.

> I am far from an expert on X11, but it seems to me that we either  
> need to
> add a system_x11 variant to the proto ports or trim down the  
> dependencies
> of the current system_x11 ports.

I'd be fore that once the variant-aware dependencies are in order, so  
we could say things like depends_build port:xorg-applewmproto:- 
system_x11 or whatever the syntax would be.

For now, yeah... it's overkill bringing in a few extra headers, but  
it's safer.


From jeremyhu at macports.org  Mon Jan 19 10:24:00 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Mon, 19 Jan 2009 10:24:00 -0800
Subject: xorg-*proto ports and system_x11
In-Reply-To: <B197C5D9-36DD-40FD-A4C1-75F34641E260@macports.org>
References: <loom.20090119T131856-743@post.gmane.org>
	<B197C5D9-36DD-40FD-A4C1-75F34641E260@macports.org>
Message-ID: <22BBA554-1FB3-4493-856B-CCE3659DE651@macports.org>


> Yeah... it just really complicates things on Tiger with +system_x11  
> if we start pruning out header files that are already available.   
> For example, libAppleWM has stayed the same, but the protocol  
> headers have been updated to add new functionality that is necessary  
> for the new server.
>
>> I am far from an expert on X11, but it seems to me that we either  
>> need to
>> add a system_x11 variant to the proto ports or trim down the  
>> dependencies
>> of the current system_x11 ports.

> I'd be fore that once the variant-aware dependencies are in order,  
> so we could say things like depends_build port:xorg-applewmproto:- 
> system_x11 or whatever the syntax would be.

Actually, the protocol headers should be pulled in by the ports  
needing them, not the libs, so my example above is invalid because  
xorg-server itself needs the new applewmproto, but libAppleWM does not.

I pushed your patch from http://trac.macports.org/ticket/18098 which  
removes the dependencies from the libs when +system_x11



From emer at emer.net  Mon Jan 19 15:13:48 2009
From: emer at emer.net (Mark Anderson)
Date: Mon, 19 Jan 2009 18:13:48 -0500
Subject: [MacPorts] #18077: tesseract: upgrade to 2.03
In-Reply-To: <066.6e3e7f0ca5e90f8edf743b5ee3c5547e@macports.org>
References: <057.ad42f2fd6c68cb3869b3a8e564dff239@macports.org>
	<066.6e3e7f0ca5e90f8edf743b5ee3c5547e@macports.org>
Message-ID: <2cf4100f0901191513j972991bma99f1f55dfbd2da@mail.gmail.com>

Whoops.  Uploaded a 2.03 diff.

Mark

On Mon, Jan 19, 2009 at 1:31 PM, MacPorts <noreply at macports.org> wrote:
> #18077: tesseract: upgrade to 2.03
> -----------------------------------+----------------------------------------
>  Reporter:  steven@?               |       Owner:  emer@?
>     Type:  enhancement            |      Status:  new
>  Priority:  Normal                 |   Milestone:  Port Updates
> Component:  ports                  |     Version:  1.7.0
>  Keywords:                         |        Port:  tesseract
> -----------------------------------+----------------------------------------
>
> Comment(by macsforever2000@?):
>
>  This looks like version 2.01. It's best if you attach a
>  [http://guide.macports.org/#development.patches.portfile unified diff] of
>  the portfile, not a whole portfile. Thanks!
>
> --
> Ticket URL: <http://trac.macports.org/ticket/18077#comment:2>
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS
>

From opendarwin.org at darkart.com  Mon Jan 19 15:58:47 2009
From: opendarwin.org at darkart.com (Eric Hall)
Date: Mon, 19 Jan 2009 23:58:47 +0000
Subject: [PATCH] port: dependencies for X11
In-Reply-To: <1E6DE4DE-E855-4576-87A6-0700830C7B78@macports.org>
References: <1E6DE4DE-E855-4576-87A6-0700830C7B78@macports.org>
Message-ID: <20090119235847.GE1155@darkart.com>

On Sat, Jan 17, 2009 at 11:38:02AM -0800, Jeremy Huddleston wrote:
> This patch touches the 252 ports (listed at bottom) which depend on  
> X11 with a lib: style dependency.  It changes these to port:  
> dependencies.  If it was lib:...:XFree86 or lib:...:xorg, the new  
> dependency is port:xorg-libs.
> 
> The ports with port:xorg-libs in their dependencies haven't been  
> tested by me.  Most of these are outside the x11 category.  After this  
> effort gets committed, I'll start simplifying the dependencies in  
> those ports like I did most of the ones in the x11 category.
> 
> http://people.freedesktop.org/~jeremyhu/x11-dep.patch
> 
[snip]

	Were you planning on adding the +system_x11 variant
to these ports as well?


		-eric


From jeremyhu at macports.org  Mon Jan 19 18:04:46 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Mon, 19 Jan 2009 18:04:46 -0800
Subject: [PATCH] port: dependencies for X11
In-Reply-To: <20090119235847.GE1155@darkart.com>
References: <1E6DE4DE-E855-4576-87A6-0700830C7B78@macports.org>
	<20090119235847.GE1155@darkart.com>
Message-ID: <C2C75DC7-ECEC-4D1A-9EB1-D6F0DFC8DE54@macports.org>


On Jan 19, 2009, at 15:58, Eric Hall wrote:

> On Sat, Jan 17, 2009 at 11:38:02AM -0800, Jeremy Huddleston wrote:
>> This patch touches the 252 ports (listed at bottom) which depend on
>> X11 with a lib: style dependency.  It changes these to port:
>> dependencies.  If it was lib:...:XFree86 or lib:...:xorg, the new
>> dependency is port:xorg-libs.
>>
>> The ports with port:xorg-libs in their dependencies haven't been
>> tested by me.  Most of these are outside the x11 category.  After  
>> this
>> effort gets committed, I'll start simplifying the dependencies in
>> those ports like I did most of the ones in the x11 category.
>>
>> http://people.freedesktop.org/~jeremyhu/x11-dep.patch
>>
> [snip]
>
> 	Were you planning on adding the +system_x11 variant
> to these ports as well?

To what ports?


From opendarwin.org at darkart.com  Mon Jan 19 21:08:09 2009
From: opendarwin.org at darkart.com (Eric Hall)
Date: Tue, 20 Jan 2009 05:08:09 +0000
Subject: [PATCH] port: dependencies for X11
In-Reply-To: <C2C75DC7-ECEC-4D1A-9EB1-D6F0DFC8DE54@macports.org>
References: <1E6DE4DE-E855-4576-87A6-0700830C7B78@macports.org>
	<20090119235847.GE1155@darkart.com>
	<C2C75DC7-ECEC-4D1A-9EB1-D6F0DFC8DE54@macports.org>
Message-ID: <20090120050808.GF1155@darkart.com>

On Mon, Jan 19, 2009 at 06:04:46PM -0800, Jeremy Huddleston wrote:
> 
> On Jan 19, 2009, at 15:58, Eric Hall wrote:
> 
> >On Sat, Jan 17, 2009 at 11:38:02AM -0800, Jeremy Huddleston wrote:
> >>This patch touches the 252 ports (listed at bottom) which depend on
> >>X11 with a lib: style dependency.  It changes these to port:
> >>dependencies.  If it was lib:...:XFree86 or lib:...:xorg, the new
> >>dependency is port:xorg-libs.
> >>
> >>The ports with port:xorg-libs in their dependencies haven't been
> >>tested by me.  Most of these are outside the x11 category.  After  
> >>this
> >>effort gets committed, I'll start simplifying the dependencies in
> >>those ports like I did most of the ones in the x11 category.
> >>
> >>http://people.freedesktop.org/~jeremyhu/x11-dep.patch
> >>
> >[snip]
> >
> >	Were you planning on adding the +system_x11 variant
> >to these ports as well?
> 
> To what ports?
> 

	I figured all of them, in case people want to use
the system installed X11.  Perhaps I misunderstood something
in the various emails, I thought there was mention of having
variants to allow the use of the system installed X11.


		-eric




From blb at macports.org  Mon Jan 19 21:22:14 2009
From: blb at macports.org (Bryan Blackburn)
Date: Mon, 19 Jan 2009 22:22:14 -0700
Subject: [PATCH] port: dependencies for X11
In-Reply-To: <20090120050808.GF1155@darkart.com>
References: <1E6DE4DE-E855-4576-87A6-0700830C7B78@macports.org>
	<20090119235847.GE1155@darkart.com>
	<C2C75DC7-ECEC-4D1A-9EB1-D6F0DFC8DE54@macports.org>
	<20090120050808.GF1155@darkart.com>
Message-ID: <20090120052214.GO785@ninagal.withay.com>

On Tue, Jan 20, 2009 at 05:08:09AM +0000, Eric Hall said:
> On Mon, Jan 19, 2009 at 06:04:46PM -0800, Jeremy Huddleston wrote:
> > 
> > On Jan 19, 2009, at 15:58, Eric Hall wrote:
> > 
> > >On Sat, Jan 17, 2009 at 11:38:02AM -0800, Jeremy Huddleston wrote:
> > >>This patch touches the 252 ports (listed at bottom) which depend on
> > >>X11 with a lib: style dependency.  It changes these to port:
> > >>dependencies.  If it was lib:...:XFree86 or lib:...:xorg, the new
> > >>dependency is port:xorg-libs.
> > >>
> > >>The ports with port:xorg-libs in their dependencies haven't been
> > >>tested by me.  Most of these are outside the x11 category.  After  
> > >>this
> > >>effort gets committed, I'll start simplifying the dependencies in
> > >>those ports like I did most of the ones in the x11 category.
> > >>
> > >>http://people.freedesktop.org/~jeremyhu/x11-dep.patch
> > >>
> > >[snip]
> > >
> > >	Were you planning on adding the +system_x11 variant
> > >to these ports as well?
> > 
> > To what ports?
> > 
> 
> 	I figured all of them, in case people want to use
> the system installed X11.  Perhaps I misunderstood something
> in the various emails, I thought there was mention of having
> variants to allow the use of the system installed X11.

That's in the respective xorg-lib* ports, eg, xorg-libX11 [1]; so if
port xyz depends on xorg-libX11, that either installs the library or,
with +system_x11 set, nothing.

Bryan

[1] - <http://trac.macports.org/browser/trunk/dports/x11/xorg-libX11/Portfile#L45>

> 
> 
> 		-eric

From opendarwin.org at darkart.com  Mon Jan 19 21:29:00 2009
From: opendarwin.org at darkart.com (Eric Hall)
Date: Tue, 20 Jan 2009 05:29:00 +0000
Subject: [PATCH] port: dependencies for X11
In-Reply-To: <20090120052214.GO785@ninagal.withay.com>
References: <1E6DE4DE-E855-4576-87A6-0700830C7B78@macports.org>
	<20090119235847.GE1155@darkart.com>
	<C2C75DC7-ECEC-4D1A-9EB1-D6F0DFC8DE54@macports.org>
	<20090120050808.GF1155@darkart.com>
	<20090120052214.GO785@ninagal.withay.com>
Message-ID: <20090120052900.GH1155@darkart.com>

On Mon, Jan 19, 2009 at 10:22:14PM -0700, Bryan Blackburn wrote:
> On Tue, Jan 20, 2009 at 05:08:09AM +0000, Eric Hall said:
[snip]
> > 
> > 	I figured all of them, in case people want to use
> > the system installed X11.  Perhaps I misunderstood something
> > in the various emails, I thought there was mention of having
> > variants to allow the use of the system installed X11.
> 
> That's in the respective xorg-lib* ports, eg, xorg-libX11 [1]; so if
> port xyz depends on xorg-libX11, that either installs the library or,
> with +system_x11 set, nothing.
> 
> Bryan
> 
> [1] - <http://trac.macports.org/browser/trunk/dports/x11/xorg-libX11/Portfile#L45>
> 

	Ahhhhh.  So close and yet so far...
	Much cleaner and nicer too (variant in one port rather
than in many many).


		-eric



From blb at macports.org  Mon Jan 19 21:36:30 2009
From: blb at macports.org (Bryan Blackburn)
Date: Mon, 19 Jan 2009 22:36:30 -0700
Subject: [PATCH] port: dependencies for X11
In-Reply-To: <20090120052900.GH1155@darkart.com>
References: <1E6DE4DE-E855-4576-87A6-0700830C7B78@macports.org>
	<20090119235847.GE1155@darkart.com>
	<C2C75DC7-ECEC-4D1A-9EB1-D6F0DFC8DE54@macports.org>
	<20090120050808.GF1155@darkart.com>
	<20090120052214.GO785@ninagal.withay.com>
	<20090120052900.GH1155@darkart.com>
Message-ID: <20090120053630.GP785@ninagal.withay.com>

On Tue, Jan 20, 2009 at 05:29:00AM +0000, Eric Hall said:
> On Mon, Jan 19, 2009 at 10:22:14PM -0700, Bryan Blackburn wrote:
> > On Tue, Jan 20, 2009 at 05:08:09AM +0000, Eric Hall said:
> [snip]
> > > 
> > > 	I figured all of them, in case people want to use
> > > the system installed X11.  Perhaps I misunderstood something
> > > in the various emails, I thought there was mention of having
> > > variants to allow the use of the system installed X11.
> > 
> > That's in the respective xorg-lib* ports, eg, xorg-libX11 [1]; so if
> > port xyz depends on xorg-libX11, that either installs the library or,
> > with +system_x11 set, nothing.
> > 
> > Bryan
> > 
> > [1] - <http://trac.macports.org/browser/trunk/dports/x11/xorg-libX11/Portfile#L45>
> > 
> 
> 	Ahhhhh.  So close and yet so far...
> 	Much cleaner and nicer too (variant in one port rather
> than in many many).

Actual, in several (30-some-odd xorg-lib* ports and a couple of other,
similar ones), but at least grouped just to those X11-specific ports instead
of having to go into any app-type port which needs X11...

Bryan


> 
> 
> 		-eric

From raimue at macports.org  Tue Jan 20 03:23:17 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Tue, 20 Jan 2009 12:23:17 +0100
Subject: [41054] trunk/dports/net/openssh/Portfile
In-Reply-To: <20081021123627.3B83A527D86@beta.macosforge.org>
References: <20081021123627.3B83A527D86@beta.macosforge.org>
Message-ID: <4975B425.9070009@macports.org>

jmr at macports.org wrote:
>  # For X11 Forwarding
> -variant apple_x11 description "use (apple's) X11 for forwarding" { # set for X11 forwarding
> +variant apple_x11 description "use (apple's) X11 for forwarding" {
>    configure.args-append --with-xauth=${x11prefix}/bin/xauth
>   }

Maybe this variant should be named system_x11 to match the current state
of other xorg-* ports?

This would make it possible to use +system_x11 in variants.conf in a
consistent way. We could also move the description to
_resources/port1.0/variant_descriptions.conf.

Rainer

From jmr at macports.org  Tue Jan 20 03:49:29 2009
From: jmr at macports.org (Joshua Root)
Date: Tue, 20 Jan 2009 22:49:29 +1100
Subject: [PATCH] port: dependencies for X11
In-Reply-To: <20090120053630.GP785@ninagal.withay.com>
References: <1E6DE4DE-E855-4576-87A6-0700830C7B78@macports.org>	<20090119235847.GE1155@darkart.com>	<C2C75DC7-ECEC-4D1A-9EB1-D6F0DFC8DE54@macports.org>	<20090120050808.GF1155@darkart.com>	<20090120052214.GO785@ninagal.withay.com>	<20090120052900.GH1155@darkart.com>
	<20090120053630.GP785@ninagal.withay.com>
Message-ID: <4975BA49.3090107@macports.org>

Bryan Blackburn wrote:
> On Tue, Jan 20, 2009 at 05:29:00AM +0000, Eric Hall said:
>> On Mon, Jan 19, 2009 at 10:22:14PM -0700, Bryan Blackburn wrote:
>>> On Tue, Jan 20, 2009 at 05:08:09AM +0000, Eric Hall said:
>> [snip]
>>>> 	I figured all of them, in case people want to use
>>>> the system installed X11.  Perhaps I misunderstood something
>>>> in the various emails, I thought there was mention of having
>>>> variants to allow the use of the system installed X11.
>>> That's in the respective xorg-lib* ports, eg, xorg-libX11 [1]; so if
>>> port xyz depends on xorg-libX11, that either installs the library or,
>>> with +system_x11 set, nothing.
>>>
>>> Bryan
>>>
>>> [1] - <http://trac.macports.org/browser/trunk/dports/x11/xorg-libX11/Portfile#L45>
>>>
>> 	Ahhhhh.  So close and yet so far...
>> 	Much cleaner and nicer too (variant in one port rather
>> than in many many).
> 
> Actual, in several (30-some-odd xorg-lib* ports and a couple of other,
> similar ones), but at least grouped just to those X11-specific ports instead
> of having to go into any app-type port which needs X11...

This means, of course, that if you want to use +system_x11, you're best
off setting it in variants.conf.

- Josh

From raphael at ira.uka.de  Tue Jan 20 10:00:00 2009
From: raphael at ira.uka.de (Raphael Straub)
Date: Tue, 20 Jan 2009 19:00:00 +0100
Subject: Geomview port does not work with xorg-libs of MacPorts
Message-ID: <1DA3AB3A-18C8-46FF-8CC6-399B3084E895@ira.uka.de>

Hi,

I'm the maintainer of the geomview port and I just discovered that it  
does not work anymore. The problem seems to be the new port:xorg-libs  
dependency.

After installing Geomview with MacPorts (and even after adding "--x- 
includes=${prefix}/include --x-libraries=${prefix}/lib" to  
configure.args) "gvx" (the Geomview binary, "geomview" is just a start  
script) is linked against the following libraries:

 > otool -L /opt/local/libexec/geomview/gvx
/opt/local/libexec/geomview/gvx:
	/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/ 
libGL.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/libXm.4.dylib (compatibility version 5.0.0, current  
version 5.1.0)
	/opt/local/lib/libXp.6.dylib (compatibility version 9.0.0, current  
version 9.0.0)
	/opt/local/lib/libXft.2.dylib (compatibility version 4.0.0, current  
version 4.13.0)
	/usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current  
version 9.0.0)
	/usr/X11/lib/libXau.6.dylib (compatibility version 7.0.0, current  
version 7.0.0)
	/usr/X11/lib/libXdmcp.6.dylib (compatibility version 7.0.0, current  
version 7.0.0)
	/opt/local/lib/libXrender.1.dylib (compatibility version 5.0.0,  
current version 5.0.0)
	/opt/local/lib/libfontconfig.1.dylib (compatibility version 5.0.0,  
current version 5.0.0)
	/opt/local/lib/libiconv.2.dylib (compatibility version 7.0.0, current  
version 7.0.0)
	/opt/local/lib/libexpat.1.dylib (compatibility version 7.0.0, current  
version 7.2.0)
	/opt/local/lib/libfreetype.6.dylib (compatibility version 10.0.0,  
current version 10.19.0)
	/opt/local/lib/libjpeg.62.dylib (compatibility version 63.0.0,  
current version 63.0.0)
	/opt/local/lib/libpng12.0.dylib (compatibility version 35.0.0,  
current version 35.0.0)
	/opt/local/lib/libXmu.6.dylib (compatibility version 9.0.0, current  
version 9.0.0)
	/opt/local/lib/libgeomview-1.9.4.dylib (compatibility version 0.0.0,  
current version 0.0.0)
	/usr/X11/lib/libGL.1.dylib (compatibility version 1.2.0, current  
version 1.2.0)
	/usr/X11/lib/libGLU.1.dylib (compatibility version 1.3.0, current  
version 1.3.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current  
version 1.2.3)
	/opt/local/lib/libXt.6.dylib (compatibility version 7.0.0, current  
version 7.0.0)
	/opt/local/lib/libSM.6.dylib (compatibility version 7.0.0, current  
version 7.0.0)
	/opt/local/lib/libICE.6.dylib (compatibility version 10.0.0, current  
version 10.0.0)
	/opt/local/lib/libXext.6.dylib (compatibility version 11.0.0, current  
version 11.0.0)
	/opt/local/lib/libX11.6.dylib (compatibility version 9.0.0, current  
version 9.0.0)
	/opt/local/lib/libXau.6.dylib (compatibility version 7.0.0, current  
version 7.0.0)
	/opt/local/lib/libXdmcp.6.dylib (compatibility version 7.0.0, current  
version 7.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current  
version 111.1.3)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current  
version 1.0.0)

As you can see, some libraries are double in this list. In addition,  
there is no ${prefix}/lib/libGL.dylib and no ${prefix}/lib/ 
libGLU.dylib to link against so /usr/X11/lib/libGL.1.dylib and /usr/ 
X11/lib/libGLU.1.dylib are taken. The resulting binary just exits with  
no error message.

Does anybody have an idea how to solve the problem without  
reinstalling all xorg-* ports with the system_x11 variant?

Regards,
	Raphael
-- 
Raphael Straub                              E-Mail: raphael at ira.uka.de
Universit?t Karlsruhe                       Tel.  : +49 721 608-4383
Institut f?r Betriebs- und Dialogsysteme    Fax   : +49 721 608-8330
Am Fasanengarten 5, 76128 Karlsruhe         Geb. 50.34, Raum 127


From jeremyhu at macports.org  Tue Jan 20 10:27:22 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Tue, 20 Jan 2009 10:27:22 -0800
Subject: Geomview port does not work with xorg-libs of MacPorts
In-Reply-To: <1DA3AB3A-18C8-46FF-8CC6-399B3084E895@ira.uka.de>
References: <1DA3AB3A-18C8-46FF-8CC6-399B3084E895@ira.uka.de>
Message-ID: <D1ABA5A7-9936-429C-BE59-F13D50445A5E@macports.org>

Looks like #17558 ... Did you actually do a 'sudo port -v upgrade  
outdated' ?  If not, do that and you should be fine.  If you still  
have the same linking issues, go into /opt/local/lib and figure out  
what libs are still linking against /usr/X11/lib/*.  This should do it:

cd /opt/local/lib; for f in *.dylib; do otool -L $f | grep -q /usr/X  
&& echo $f; done

---

If things are setup right, applications shouldn't need --x-include and  
--x-lib (libs that make pkg-config files and use AC_X_PATH will).  If  
you do need to disable AC_X_PATH for some reason, do it like this:

         # AC_X_PATH blindly asks xmkmf where X11 is, and it always  
uses /usr/X11R6.
         # These next three lines should cause AC_X_PATH to let us  
setup our CPPFLAGS
         # and LDFLAGS without interference
         configure.args-append --x-include=${prefix}/include --x-lib=$ 
{prefix}/lib
         configure.cppflags-append -I${x11prefix}/include
         configure.ldflags-append  -L${x11prefix}/lib

The cppflags and ldflags are important for users who do +system_x11



On Jan 20, 2009, at 10:00, Raphael Straub wrote:

> Hi,
>
> I'm the maintainer of the geomview port and I just discovered that  
> it does not work anymore. The problem seems to be the new port:xorg- 
> libs dependency.
>
> After installing Geomview with MacPorts (and even after adding "--x- 
> includes=${prefix}/include --x-libraries=${prefix}/lib" to  
> configure.args) "gvx" (the Geomview binary, "geomview" is just a  
> start script) is linked against the following libraries:
>
> > otool -L /opt/local/libexec/geomview/gvx
> /opt/local/libexec/geomview/gvx:
> 	/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/ 
> libGL.dylib (compatibility version 1.0.0, current version 1.0.0)
> 	/opt/local/lib/libXm.4.dylib (compatibility version 5.0.0, current  
> version 5.1.0)
> 	/opt/local/lib/libXp.6.dylib (compatibility version 9.0.0, current  
> version 9.0.0)
> 	/opt/local/lib/libXft.2.dylib (compatibility version 4.0.0, current  
> version 4.13.0)
> 	/usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current  
> version 9.0.0)
> 	/usr/X11/lib/libXau.6.dylib (compatibility version 7.0.0, current  
> version 7.0.0)
> 	/usr/X11/lib/libXdmcp.6.dylib (compatibility version 7.0.0, current  
> version 7.0.0)
> 	/opt/local/lib/libXrender.1.dylib (compatibility version 5.0.0,  
> current version 5.0.0)
> 	/opt/local/lib/libfontconfig.1.dylib (compatibility version 5.0.0,  
> current version 5.0.0)
> 	/opt/local/lib/libiconv.2.dylib (compatibility version 7.0.0,  
> current version 7.0.0)
> 	/opt/local/lib/libexpat.1.dylib (compatibility version 7.0.0,  
> current version 7.2.0)
> 	/opt/local/lib/libfreetype.6.dylib (compatibility version 10.0.0,  
> current version 10.19.0)
> 	/opt/local/lib/libjpeg.62.dylib (compatibility version 63.0.0,  
> current version 63.0.0)
> 	/opt/local/lib/libpng12.0.dylib (compatibility version 35.0.0,  
> current version 35.0.0)
> 	/opt/local/lib/libXmu.6.dylib (compatibility version 9.0.0, current  
> version 9.0.0)
> 	/opt/local/lib/libgeomview-1.9.4.dylib (compatibility version  
> 0.0.0, current version 0.0.0)
> 	/usr/X11/lib/libGL.1.dylib (compatibility version 1.2.0, current  
> version 1.2.0)
> 	/usr/X11/lib/libGLU.1.dylib (compatibility version 1.3.0, current  
> version 1.3.0)
> 	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current  
> version 1.2.3)
> 	/opt/local/lib/libXt.6.dylib (compatibility version 7.0.0, current  
> version 7.0.0)
> 	/opt/local/lib/libSM.6.dylib (compatibility version 7.0.0, current  
> version 7.0.0)
> 	/opt/local/lib/libICE.6.dylib (compatibility version 10.0.0,  
> current version 10.0.0)
> 	/opt/local/lib/libXext.6.dylib (compatibility version 11.0.0,  
> current version 11.0.0)
> 	/opt/local/lib/libX11.6.dylib (compatibility version 9.0.0, current  
> version 9.0.0)
> 	/opt/local/lib/libXau.6.dylib (compatibility version 7.0.0, current  
> version 7.0.0)
> 	/opt/local/lib/libXdmcp.6.dylib (compatibility version 7.0.0,  
> current version 7.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current  
> version 111.1.3)
> 	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current  
> version 1.0.0)
>
> As you can see, some libraries are double in this list. In addition,  
> there is no ${prefix}/lib/libGL.dylib and no ${prefix}/lib/ 
> libGLU.dylib to link against so /usr/X11/lib/libGL.1.dylib and /usr/ 
> X11/lib/libGLU.1.dylib are taken. The resulting binary just exits  
> with no error message.
>
> Does anybody have an idea how to solve the problem without  
> reinstalling all xorg-* ports with the system_x11 variant?
>
> Regards,
> 	Raphael
> -- 
> Raphael Straub                              E-Mail: raphael at ira.uka.de
> Universit?t Karlsruhe                       Tel.  : +49 721 608-4383
> Institut f?r Betriebs- und Dialogsysteme    Fax   : +49 721 608-8330
> Am Fasanengarten 5, 76128 Karlsruhe         Geb. 50.34, Raum 127
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


From ryandesign at macports.org  Tue Jan 20 13:45:05 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 20 Jan 2009 15:45:05 -0600
Subject: [MacPorts] #17960: curl: build failure when building universal
	for i386 ppc x86_64 ppc64
In-Reply-To: <068.8f4f73e618250f9866377504265337e4@macports.org>
References: <059.d66933508b8a1de630f8601aa79e7b55@macports.org>
	<068.8f4f73e618250f9866377504265337e4@macports.org>
Message-ID: <97686E0F-B768-4909-A0C2-D03043E89066@macports.org>

On Jan 20, 2009, at 15:28, MacPorts wrote:

> #17960: curl: build failure when building universal for i386 ppc  
> x86_64 ppc64
> ------------------------------------- 
> +--------------------------------------
>  Reporter:  ryandesign@?             |       Owner:  ryandesign@?
>      Type:  defect                   |      Status:  new
>  Priority:  Normal                   |   Milestone:  Port Bugs
> Component:  ports                    |     Version:  1.7.0
>  Keywords:                           |        Port:  curl
> ------------------------------------- 
> +--------------------------------------
>
> Comment(by mcalhoun@?):
>
>  Replying to [comment:4 ryandesign@?]:
>> I'm not prepared to, for every new version of curl, configure for  
>> each
>>  architecture and manually compare the headers to see how they  
>> differ, so
>>  I'll have to look for an automated solution, maybe the merge()  
>> function,
>>  maybe the new merge-universal portgroup.
>
>
>  For what it's worth, this is the type of situation I had in mind  
> for the
>  merge-universal portgroup.[[BR]]
>  I have not yet had time to add merge-universal to any ports in the  
> trunk
>  (only my local repository), but I can look into it.

With all the 64-bit issues I'm seeing with various ports of mine, or  
more especially with the reports of 64-bit issues from others which  
have no readily-apparent symptoms, I'm about ready to use use the  
merge-universal portgroup for every port.



From billitch at gmail.com  Tue Jan 20 18:08:58 2009
From: billitch at gmail.com (Thomas de Grivel)
Date: Wed, 21 Jan 2009 03:08:58 +0100
Subject: Macports revdep-rebuild
In-Reply-To: <4ec7f0880901201801t66c70273sa95bf14d34cffd23@mail.gmail.com>
References: <d27d7610901201722j598cbba0t313f24f464db03ae@mail.gmail.com>
	<4ec7f0880901201801t66c70273sa95bf14d34cffd23@mail.gmail.com>
Message-ID: <4ec7f0880901201808t62750350wf215fbd721ded770@mail.gmail.com>

Fellow linkage dreaders,

I recently started to port revdep-rebuild to macports. It is still a
bit brutal but it works.
What still lacks is mainly ports order resolution and I would need
some pointers / contribution as to how to do it.
I tried to adapt gentoo/portage vocabulary to macports but maybe
forgot some options.

it is already useful in case of major linkage breakage as it detects
well ports that need to be rebuilt and it does rebuild them.

if you want to try it :
# svn co https://svn.lowh.net/billitch/mp-revdep-rebuild/mp-revdep-rebuild

if you just want to see it :
https://trac.lowh.net/billitch/browser/mp-revdep-rebuild/mp-revdep-rebuild

please tell me about bugs ;)

-- 
 Thomas de Grivel
 http://b.lowh.net/billitch/

From raimue at macports.org  Wed Jan 21 02:31:59 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Wed, 21 Jan 2009 11:31:59 +0100
Subject: [MacPorts] #18128: Enhancement to distinguish between Apple and
	non-Apple compilers
In-Reply-To: <052.5e4ef2cfd5d0707eac613278b4ed3f82@macports.org>
References: <052.5e4ef2cfd5d0707eac613278b4ed3f82@macports.org>
Message-ID: <4976F99F.3070907@macports.org>

MacPorts wrote:
> #18128: Enhancement to distinguish between Apple and non-Apple compilers
> ------------------------------+---------------------------------------------
>  Reporter:  mlk@?             |       Owner:  macports-tickets@?                   
>      Type:  enhancement       |      Status:  new                                  
>  Priority:  Normal            |   Milestone:  Port Enhancements                    
> Component:  ports             |     Version:  1.7.0                                
>  Keywords:                    |        Port:                                       
> ------------------------------+---------------------------------------------
>  I've recently found and corrected an issue on at least three port
>  (tuntaposx, macclipboard-gimp, and macfile-gimp) which ''require'' 'gcc'
>  (or 'g++') be an Apple compiler but were instead using just 'gcc' (first
>  in the PATH); this issue surely exists in other Ports.  The 'fix' seems to
>  be reinplace 'gcc' with '${configure.cc}' wherever needed (ditto for 'g++'
>  with '${configure.cxx}' etc.) .
> 
>  There should be a better way, e.g., use '${configure.apple_cc}' for those
>  ports which require Apple's 'cc', and then have a pre-defined default
>  (e.g., '/usr/bin/cc' , etc.) which can be overridden in the Portfile if
>  desired but must ''always'' provide an Apple compiler.
> 
>  There are plenty of ports which do not require Apple's gcc, and hence IMHO
>  it makes sense to provide both configure.cc and configure.apple_cc in
>  order to allow ports access to whichever makes the most sense, to
>  distinguish between them.
> 
>  Is something like this already in place?  If so, then at least these three
>  ports' Portfile's should be updated; if not, then IMHO it should be
>  considered.  Thanks for listening. - MLD

There is configure.compiler to choose a specific compiler, but it only
exports CC/CXX etc. at the moment. If the Makefile does not respect this
and uses 'gcc' from PATH (as in these ports) it does not work.

To avoid such problems with CC versus 'gcc' in PATH without examining
and patching all ports, we would need the choosen compiler to be first
in PATH. So we could create a temporary directory, add symlinks to the
choosen compiler to it in the configure phase and then add this in front
of PATH. Any access to 'gcc' without absolute path will be the right
compiler.

Would there be any disadvantages I don't see right now?

Rainer

From jmr at macports.org  Wed Jan 21 03:53:58 2009
From: jmr at macports.org (Joshua Root)
Date: Wed, 21 Jan 2009 22:53:58 +1100
Subject: texlive_base: Duplicate symbols in libXt, libXaw
Message-ID: <49770CD6.7070407@macports.org>

Upgrading the outdated ports on a ppc Tiger machine went fine, pulling
in the new X libs, until it got to texlive_base, which failed thus:

/usr/bin/gcc-4.0 -o xdvi-xaw.bin browser.o dvi-draw.o dvi-init.o
dvisel.o encodings.o events.o filehist.o font-open.o gf.o hypertex.o
image-magick.o mime.o my-snprintf.o my-vsnprintf.o pagehist.o pk.o
print-internal.o psdps.o psgs.o psheader.o psnews.o read-mapfile.o
search-internal.o special.o string-utils.o tfmload.o util.o vf.o xdvi.o
xserver-info.o x_util.o  -L/opt/local/lib ./gui/libgui.a
../../libs/t1lib/libt1.a ../../libs/t1lib/../type1/libtype1.a
-L/usr/X11R6/lib -lXaw -lXmu -lXt -lSM -lICE -lXp -lXext -lXpm -lintl
-lc -lX11 -lXau -lXdmcp -liconv ../kpathsea/.libs/libkpathsea.a -lm
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning multiple
definitions of symbol _XtRemoveTimeOut
events.o definition of _XtRemoveTimeOut in section (__TEXT,__text)
/opt/local/lib/libXt.dylib(NextEvent.o) definition of _XtRemoveTimeOut
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning multiple
definitions of symbol _XtAddTimeOut
events.o definition of _XtAddTimeOut in section (__TEXT,__text)
/opt/local/lib/libXt.dylib(NextEvent.o) definition of _XtAddTimeOut
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning multiple
definitions of symbol _XtAppAddTimeOut
events.o definition of _XtAppAddTimeOut in section (__TEXT,__text)
/opt/local/lib/libXt.dylib(NextEvent.o) definition of _XtAppAddTimeOut
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: multiple definitions of
symbol _hash_create
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libc.dylib(strhash.So)
definition of _hash_create
../kpathsea/.libs/libkpathsea.a(hash.o) definition of _hash_create in
section (__TEXT,__text)
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning multiple
definitions of symbol _vendorShellWidgetClass
/opt/local/lib/libXaw.dylib(single module) definition of
_vendorShellWidgetClass
/opt/local/lib/libXt.dylib(Vendor.o) definition of _vendorShellWidgetClass
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning multiple
definitions of symbol _vendorShellClassRec
/opt/local/lib/libXaw.dylib(single module) definition of
_vendorShellClassRec
/opt/local/lib/libXt.dylib(Vendor.o) definition of _vendorShellClassRec
collect2: ld returned 1 exit status

So, why would this be happening and how can we fix it? :-)

- Josh

From ryandesign at macports.org  Wed Jan 21 03:57:18 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 21 Jan 2009 05:57:18 -0600
Subject: [MacPorts] #18128: Enhancement to distinguish between Apple and
	non-Apple compilers
In-Reply-To: <4976F99F.3070907@macports.org>
References: <052.5e4ef2cfd5d0707eac613278b4ed3f82@macports.org>
	<4976F99F.3070907@macports.org>
Message-ID: <9C27815E-EFBB-499C-99F8-548410789898@macports.org>

On Jan 21, 2009, at 04:31, Rainer M?ller wrote:

> MacPorts wrote:
>> #18128: Enhancement to distinguish between Apple and non-Apple  
>> compilers
>> ------------------------------ 
>> +---------------------------------------------
>>  Reporter:  mlk@?             |       Owner:  macports-tickets@?
>>      Type:  enhancement       |      Status:  new
>>  Priority:  Normal            |   Milestone:  Port Enhancements
>> Component:  ports             |     Version:  1.7.0
>>  Keywords:                    |        Port:
>> ------------------------------ 
>> +---------------------------------------------
>>  I've recently found and corrected an issue on at least three port
>>  (tuntaposx, macclipboard-gimp, and macfile-gimp) which  
>> ''require'' 'gcc'
>>  (or 'g++') be an Apple compiler but were instead using just  
>> 'gcc' (first
>>  in the PATH); this issue surely exists in other Ports.  The 'fix'  
>> seems to
>>  be reinplace 'gcc' with '${configure.cc}' wherever needed (ditto  
>> for 'g++'
>>  with '${configure.cxx}' etc.) .
>>
>>  There should be a better way, e.g., use '${configure.apple_cc}'  
>> for those
>>  ports which require Apple's 'cc', and then have a pre-defined  
>> default
>>  (e.g., '/usr/bin/cc' , etc.) which can be overridden in the  
>> Portfile if
>>  desired but must ''always'' provide an Apple compiler.
>>
>>  There are plenty of ports which do not require Apple's gcc, and  
>> hence IMHO
>>  it makes sense to provide both configure.cc and  
>> configure.apple_cc in
>>  order to allow ports access to whichever makes the most sense, to
>>  distinguish between them.
>>
>>  Is something like this already in place?  If so, then at least  
>> these three
>>  ports' Portfile's should be updated; if not, then IMHO it should be
>>  considered.  Thanks for listening. - MLD
>
> There is configure.compiler to choose a specific compiler, but it only
> exports CC/CXX etc. at the moment. If the Makefile does not respect  
> this
> and uses 'gcc' from PATH (as in these ports) it does not work.
>
> To avoid such problems with CC versus 'gcc' in PATH without examining
> and patching all ports, we would need the choosen compiler to be first
> in PATH. So we could create a temporary directory, add symlinks to the
> choosen compiler to it in the configure phase and then add this in  
> front
> of PATH. Any access to 'gcc' without absolute path will be the right
> compiler.
>
> Would there be any disadvantages I don't see right now?

The path to gcc used to compile the program must be the same as the  
path to gcc used to compile the libtool it's using. Remember we had  
lots of problems with "unable to infer tagged configuration" until we  
realized this and forced various libtools to rebuild after we changed  
MacPorts from using "gcc" to using "/usr/bin/gcc-4.0".


From ryandesign at macports.org  Wed Jan 21 04:00:15 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 21 Jan 2009 06:00:15 -0600
Subject: texlive_base: Duplicate symbols in libXt, libXaw
In-Reply-To: <49770CD6.7070407@macports.org>
References: <49770CD6.7070407@macports.org>
Message-ID: <BD1A9481-74AF-4435-8BB1-DEFDE2194093@macports.org>

On Jan 21, 2009, at 05:53, Joshua Root wrote:

> Upgrading the outdated ports on a ppc Tiger machine went fine, pulling
> in the new X libs, until it got to texlive_base, which failed thus:
>
> /usr/bin/gcc-4.0 -o xdvi-xaw.bin browser.o dvi-draw.o dvi-init.o
> dvisel.o encodings.o events.o filehist.o font-open.o gf.o hypertex.o
> image-magick.o mime.o my-snprintf.o my-vsnprintf.o pagehist.o pk.o
> print-internal.o psdps.o psgs.o psheader.o psnews.o read-mapfile.o
> search-internal.o special.o string-utils.o tfmload.o util.o vf.o  
> xdvi.o
> xserver-info.o x_util.o  -L/opt/local/lib ./gui/libgui.a
> ../../libs/t1lib/libt1.a ../../libs/t1lib/../type1/libtype1.a
> -L/usr/X11R6/lib -lXaw -lXmu -lXt -lSM -lICE -lXp -lXext -lXpm -lintl
> -lc -lX11 -lXau -lXdmcp -liconv ../kpathsea/.libs/libkpathsea.a -lm
> /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning multiple
> definitions of symbol _XtRemoveTimeOut
> events.o definition of _XtRemoveTimeOut in section (__TEXT,__text)
> /opt/local/lib/libXt.dylib(NextEvent.o) definition of _XtRemoveTimeOut
> /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning multiple
> definitions of symbol _XtAddTimeOut
> events.o definition of _XtAddTimeOut in section (__TEXT,__text)
> /opt/local/lib/libXt.dylib(NextEvent.o) definition of _XtAddTimeOut
> /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning multiple
> definitions of symbol _XtAppAddTimeOut
> events.o definition of _XtAppAddTimeOut in section (__TEXT,__text)
> /opt/local/lib/libXt.dylib(NextEvent.o) definition of _XtAppAddTimeOut
> /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: multiple  
> definitions of
> symbol _hash_create
> /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libc.dylib 
> (strhash.So)
> definition of _hash_create
> ../kpathsea/.libs/libkpathsea.a(hash.o) definition of _hash_create in
> section (__TEXT,__text)
> /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning multiple
> definitions of symbol _vendorShellWidgetClass
> /opt/local/lib/libXaw.dylib(single module) definition of
> _vendorShellWidgetClass
> /opt/local/lib/libXt.dylib(Vendor.o) definition of  
> _vendorShellWidgetClass
> /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning multiple
> definitions of symbol _vendorShellClassRec
> /opt/local/lib/libXaw.dylib(single module) definition of
> _vendorShellClassRec
> /opt/local/lib/libXt.dylib(Vendor.o) definition of  
> _vendorShellClassRec
> collect2: ld returned 1 exit status
>
> So, why would this be happening and how can we fix it? :-)


I'm also having a problem upgrading texlive_base, on an Intel Tiger  
machine.


From ryandesign at macports.org  Thu Jan 22 01:37:42 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 22 Jan 2009 03:37:42 -0600
Subject: [MacPorts] #17925: recode +universal: Undefined symbols
	_libintl_bindtextdomain _libintl_gettext _libintl_textdomain
In-Reply-To: <D87631BB-CF67-494F-BCCE-296EAB3F7194@users.sourceforge.net>
References: <059.2394c67ddbe74f3f554dc8f450f81cb9@macports.org>
	<068.4159f840fc98c5aa8f4effeb3f78f224@macports.org>
	<D87631BB-CF67-494F-BCCE-296EAB3F7194@users.sourceforge.net>
Message-ID: <88809E9C-5BF4-44CB-AE61-727A095D1941@macports.org>

Ticket 17925 is for problems building recode +universal. You've  
succeeded in building recode non-universal and are now having  
problems building sbcl. As such, I don't think your issue is related.

You could look at the existing tickets about sbcl:

http://trac.macports.org/query? 
status=new&status=assigned&status=reopened&summary=~sbcl

If none of those is this issue, you could file a new one.


On Jan 21, 2009, at 14:05, jbauck at users.sourceforge.net wrote:

> Thanks for the update, Ryan.
>
> I tried installing wxMaxma (after cleaning it and recode) as non- 
> universal, which means PPC (on 10.4.11). I don't know if this is  
> helpful to you at this point, but this is what happened.
>
> Jerry
>
>
>
> The process bombed with this dialog:
>
> The application sbcl quit unexpectedly.
>
> <time and date>
>
> EXC-BAC-ACCESSD (0X0001)
> KERN-PROTECTION-FAILURE (0X0002) AT
> 0X00000000
>
> EXC_BAD_ACCESS (0x0001)
> KERN_PROTECTION_FAILURE (0x0002) at 0x00000000
>
> Thread 0 Crashed:
> 0    _malloc_initialize + 1016
> 1    malloc + 48
> 2    successful_malloc + 28
> 3    copied_string + 32
> 4    os_get_runtime_executable_path + 76
> 5    main + 104
> 6    start + 68
>
>
>
> Here is the rest of the output:
>
> Port command started with PID 19971
> Fetching recode
> Verifying checksum(s) for recode
> Extracting recode
> Applying patches to recode
> Configuring recode
> Building recode
> Staging recode into destroot
> Installing recode @3.6_3
> Activating recode @3.6_3
> Cleaning recode
> Fetching sbcl
> Attempting to fetch sbcl-1.0.24-source.tar.bz2 from http:// 
> internap.dl.sourceforge.net/sbcl
> Attempting to fetch sbcl-1.0.22-powerpc-darwin-binary.tar.bz2 from  
> http://internap.dl.sourceforge.net/sbcl
> Verifying checksum(s) for sbcl
> Extracting sbcl
> Applying patches to sbcl
> Configuring sbcl
> Building sbcl
> Error: Target org.macports.build returned: shell command "unset  
> LD_PREBIND && unset LD_PREBIND_ALLOW_OVERLAP && sh make.sh "/opt/ 
> local/var/macports/build/ 
> _opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ 
> sbcl/work/sbcl-1.0.22-powerpc-darwin/src/runtime/sbcl --core /opt/ 
> local/var/macports/build/ 
> _opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ 
> sbcl/work/sbcl-1.0.22-powerpc-darwin/output/sbcl.core --disable- 
> debugger --sysinit /dev/null --userinit /dev/null" " returned
>  error 1
> Command output: //starting build: Wed Jan 21 12:37:07 MST 2009
> //SBCL_XC_HOST="/opt/local/var/macports/build/ 
> _opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ 
> sbcl/work/sbcl-1.0.22-powerpc-darwin/src/runtime/sbcl --core /opt/ 
> local/var/macports/build/ 
> _opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ 
> sbcl/work/sbcl-1.0.22-powerpc-darwin/output/sbcl.core --disable- 
> debugger --sysinit /dev/null --userinit /dev/null"
> //entering make-config.sh
> //ensuring the exist
> ence of output/ directory
> //initializing /opt/local/var/macports/build/ 
> _opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ 
> sbcl/work/sbcl-1.0.24/local-target-features.lisp-expr
> //guessing default target CPU architecture from host architecture
> //setting up CPU-architecture-dependent information
> sbcl_arch="ppc"
> //setting up symlink src/compiler/target
> //setting up symlink src/assembly/target
> //setting up symlink src/compiler/assembly
> //setting up OS-dependent information
> //finishing /opt/l
> ocal/var/macports/build/ 
> _opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ 
> sbcl/work/sbcl-1.0.24/local-target-features.lisp-expr
> /in canonicalize-whitespace-1
> /$*=./customize-target-features.lisp ./local-target-features.lisp- 
> expr ./tests/test-status.lisp-expr ./contrib/sb-bsd-sockets/foo.c ./ 
> contrib/sb-posix/foo.c ./src/runtime/runtime.c ./src/runtime/target- 
> arch-os.h ./src/runtime/target-arch.h ./src/runtime/target- 
> lispregs.h ./src/runtime/target-os.h
> /$scratchfilename=/tmp/canonicaliz
> e-whitespace-1.25698.tmp
> //entering make-host-1.sh
> //building cross-compiler, and doing first genesis
> make-host-1.sh: line 31: 25711 Bus error                
> $SBCL_XC_HOST <make-host-1.lisp
> Error: The following dependencies failed to build: maxima sbcl  
> wxWidgets libsdl_mixer libogg libvorbis pkgconfig smpeg tiff
> Error: Status 1 encountered during processing.
> Executing: /opt/local/bin/port install wxMaxima
>
>
>
>
>
>
>> On Jan 21, 2009, at 3:03 AM, MacPorts wrote:
>>
>> #17925: recode +universal: Undefined symbols _libintl_bindtextdomain
>> _libintl_gettext _libintl_textdomain
>> ------------------------------------- 
>> +--------------------------------------
>>  Reporter:  ryandesign@?             |       Owner:  ryandesign@?
>>      Type:  defect                   |      Status:  new
>>  Priority:  Normal                   |   Milestone:  Port Bugs
>> Component:  ports                    |     Version:  1.7.0
>>  Keywords:                           |        Port:  recode, gettext
>> ------------------------------------- 
>> +--------------------------------------
>>
>> Comment(by ryandesign@?):
>>
>>  When not building universal, recode's configure script finds  
>> gettext and
>>  therefore adds -lintl to the build commands and it works. But when
>>  building universal, recode's configure script doesn't find  
>> gettext so it
>>  doesn't add -lintl to the build commands so it fails. Now we need to
>>  examine why recode's configure script behaves like that, or  
>> perhaps, we
>>  just need to autoreconf recode.
>>
>> -- 
>> Ticket URL: <http://trac.macports.org/ticket/17925#comment:1>
>> MacPorts <http://www.macports.org/>
>> Ports system for Mac OS
>>
>
>
>
>


From ryandesign at macports.org  Thu Jan 22 01:42:17 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 22 Jan 2009 03:42:17 -0600
Subject: [MacPorts] #18128: Enhancement to distinguish between Apple and
	non-Apple compilers
In-Reply-To: <1D60DA63-627C-4B31-A04E-F43FF5185C6A@alum.mit.edu>
References: <052.5e4ef2cfd5d0707eac613278b4ed3f82@macports.org>
	<4976F99F.3070907@macports.org>
	<9C27815E-EFBB-499C-99F8-548410789898@macports.org>
	<1D60DA63-627C-4B31-A04E-F43FF5185C6A@alum.mit.edu>
Message-ID: <ECCF61DF-DFA2-4AD7-9E36-E3472FDCB161@macports.org>

On Jan 21, 2009, at 07:59, Michael Dickens wrote:

> On Jan 21, 2009, at 6:57 AM, Ryan Schmidt wrote:
>> On Jan 21, 2009, at 04:31, Rainer M?ller wrote:
>>> There is configure.compiler to choose a specific compiler, but it  
>>> only
>>> exports CC/CXX etc. at the moment. If the Makefile does not  
>>> respect this
>>> and uses 'gcc' from PATH (as in these ports) it does not work.
>
> I was thinking of a 2-pronged approach:
>
> 1) For those ports which use 'gcc' explicitly, use a patch file and/ 
> or reinplace to correct that issue.
>
> 2) Create a new 'configure.apple_cc' or whatever, as a viable  
> option to 'configure.cc', which would be put in via a reinplace  
> (possibly after a patch to create a unique string to reinplace).
>
> Using this approach, one can easily choose which compiler to use  
> for a given circumstance ... even both in a given Port's  
> compilation if wanted.
>
>>> To avoid such problems with CC versus 'gcc' in PATH without  
>>> examining
>>> and patching all ports, we would need the choosen compiler to be  
>>> first
>>> in PATH. So we could create a temporary directory, add symlinks  
>>> to the
>>> choosen compiler to it in the configure phase and then add this  
>>> in front
>>> of PATH. Any access to 'gcc' without absolute path will be the right
>>> compiler.
>>>
>>> Would there be any disadvantages I don't see right now?
>>
>> The path to gcc used to compile the program must be the same as  
>> the path to gcc used to compile the libtool it's using. Remember  
>> we had lots of problems with "unable to infer tagged  
>> configuration" until we realized this and forced various libtools  
>> to rebuild after we changed MacPorts from using "gcc" to using "/ 
>> usr/bin/gcc-4.0".
>
> The 'temporary directory with symlinks' concept might work for a  
> single version of cc/gcc to be used, but not multiple versions (one  
> for 'gcc' and another for 'apple_cc').  Not sure if this matters or  
> not ... just pointing it out.
>
> Another idea: Instead of a temporary directory, one could create a  
> set of scripts - sort of like those used by gcc_select, one per cc/ 
> gcc version -, which set default environment variables to be  
> "correct" (prepending to PATH and/or setting CC, CXX, CPATH,  
> CCFLAGS, CXXFLAGS, and so forth; possibly overloading whatever the  
> user provides) for the selected version of cc/gcc.  This would be  
> executed first thing in a Portfile, via some keyword (if provided)  
> or a default (if no keyword provided).  The user can select  
> "apple_cc_4.0" or "apple_cc_4.2" or "macports_cc_4.2" or whatever  
> is available.  Or something like this.


Ports can already indicate what compiler they want by setting $ 
{configure.compiler}. For example, the default value for this  
variable on Leopard is "gcc-4.0", meaning the GCC 4.0 provided by  
Apple with Xcode. If a port author wanted, they could change this  
variable to "gcc-4.2", meaning the GCC 4.2 provided by Apple with  
Xcode, or to "macports-gcc-4.3", meaning the GCC 4.3 provided by  
MacPorts in the gcc43 port. There are options for every other GCC  
compiler that's available. As far as I know this has been sufficient  
to cover the needs of all ports so far. So I have yet to understand  
what your proposed changes would improve.



From ryandesign at macports.org  Thu Jan 22 02:30:22 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 22 Jan 2009 04:30:22 -0600
Subject: [45758] trunk/dports/textproc
In-Reply-To: <20090121141500.33E0BCDCA54@beta.macosforge.org>
References: <20090121141500.33E0BCDCA54@beta.macosforge.org>
Message-ID: <C4419BA0-8BFE-416B-9ACE-DBF79D220146@macports.org>


On Jan 21, 2009, at 08:14, snc at macports.org wrote:

> +configure {
> +# configure is done via the patch
> +}

You should write "use_configure no" instead of this.


From ryandesign at macports.org  Thu Jan 22 04:10:05 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 22 Jan 2009 06:10:05 -0600
Subject: A PortGroup for building more 32/64-bit universal packages
In-Reply-To: <loom.20090112T211017-72@post.gmane.org>
References: <loom.20090112T211017-72@post.gmane.org>
Message-ID: <C03A6AA5-2CDD-4D7B-B462-3F7C1F2D0225@macports.org>

On Jan 12, 2009, at 15:19, Marcus Calhoun-Lopez wrote:

> I have a need of more 32/64-bit universal packages.
> To facilitate this, I would like to propose a PortGroup with a  
> different
> universal build mechanism than the default.
> See http://trac.macports.org/ticket/17972.
>
> It is intended to be an improvement of the merge function.
>
> Any feedback would be greatly appreciated.
> The only time I write in Tcl is on MacPorts related projects.

As I mentioned before, I wanted to start switching my ports to this  
mechanism because I'm tired of bit-size issues and to a lesser extent  
endian issues with the old all-at-once mechanism which one never  
knows about until one tries to use some part of the software and it  
doesn't work right.

I decided to start with pkgconfig because it has no dependencies and  
has issues building 64-bit with the old way.

It doesn't build 64-bit with the new way either. Turns out its  
included copy of glib 1.2.10 wants to run a compiled program during  
the configure phase. I'm on a 64-bit Intel Mac, so once it gets to  
the ppc64 architecture, it can't run that program, because Rosetta  
can't run 64-bit PowerPC code. Presumably if I were on a G5 Mac it  
would be able to get through the ppc and ppc64 architectures, but not  
the i386 or x86_64 architectures. If I were on a G4 Mac it would  
probably only manage the ppc architecture.

The merge-universal portgroup has this fancy new  
universal_archs_supported keyword -- thanks for that! -- but I'm not  
sure how to write a portfile to express:

if {build machine is powerpc} {
	if {build machine is 64-bit} {
		universal_archs_supported ppc ppc64
	} else if {build machine is 32-bit} {
		universal_archs_supoprted ppc
		# at this point I may as well just write "universal_variant no"
	}
} else if {build machine is intel} {
	if {build machine is 64-bit} {
		universal_archs_supported ppc i386 x86_64
	} else if {build machine is 32-bit} {
		universal_archs_supported ppc i386
	}
}

Even if there were portfile syntax to test the bit-ness of the build  
machine, I wouldn't want to have the above situation; it's awful.

There's a bug open with the authors of pkg-config but there has been  
no response to it in a year and a half so I'm not hopeful. I suppose  
I should ask the authors of glib instead.

https://bugs.freedesktop.org/show_bug.cgi?id=11464



From ryandesign at macports.org  Thu Jan 22 04:28:42 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 22 Jan 2009 06:28:42 -0600
Subject: haskell port group
In-Reply-To: <20090116041116.GJ805@ninagal.withay.com>
References: <20090115052156.GL711@ninagal.withay.com>
	<0A6F9D5B-FCF1-4547-97FC-19DD6BF7D963@macports.org>
	<20090116041116.GJ805@ninagal.withay.com>
Message-ID: <32805DA2-85D6-4E02-8454-301F365DE4B9@macports.org>


On Jan 14, 2009, at 23:21, Bryan Blackburn wrote:

> FYI, for those interested, I just added a port group for haskell  
> [1], which
> currently supports only ghc (which seems okay since the other hs-*  
> ports I
> checked are all ghc-specific).  It does the standard 'runhaskell  
> Setup...'
> routine.

Could you fix up this portgroup to use 4 spaces per tab like the rest  
of the MacPorts source, instead of 3, and add a corresponding  
modeline? Thanks.


From ryandesign at macports.org  Thu Jan 22 04:31:58 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 22 Jan 2009 06:31:58 -0600
Subject: A PortGroup for building more 32/64-bit universal packages
In-Reply-To: <C03A6AA5-2CDD-4D7B-B462-3F7C1F2D0225@macports.org>
References: <loom.20090112T211017-72@post.gmane.org>
	<C03A6AA5-2CDD-4D7B-B462-3F7C1F2D0225@macports.org>
Message-ID: <535C8C58-0098-407C-9BA3-149E661D53BF@macports.org>

On Jan 22, 2009, at 06:10, Ryan Schmidt wrote:

> On Jan 12, 2009, at 15:19, Marcus Calhoun-Lopez wrote:
>
>> I have a need of more 32/64-bit universal packages.
>> To facilitate this, I would like to propose a PortGroup with a  
>> different
>> universal build mechanism than the default.
>> See http://trac.macports.org/ticket/17972.
>>
>> It is intended to be an improvement of the merge function.
>>
>> Any feedback would be greatly appreciated.
>> The only time I write in Tcl is on MacPorts related projects.
>
> As I mentioned before, I wanted to start switching my ports to this  
> mechanism because I'm tired of bit-size issues and to a lesser  
> extent endian issues with the old all-at-once mechanism which one  
> never knows about until one tries to use some part of the software  
> and it doesn't work right.
>
> I decided to start with pkgconfig because it has no dependencies  
> and has issues building 64-bit with the old way.
>
> It doesn't build 64-bit with the new way either. Turns out its  
> included copy of glib 1.2.10 wants to run a compiled program during  
> the configure phase. I'm on a 64-bit Intel Mac, so once it gets to  
> the ppc64 architecture, it can't run that program, because Rosetta  
> can't run 64-bit PowerPC code. Presumably if I were on a G5 Mac it  
> would be able to get through the ppc and ppc64 architectures, but  
> not the i386 or x86_64 architectures. If I were on a G4 Mac it  
> would probably only manage the ppc architecture.

[snip]

I tried zlib too, and it doesn't work with merge-universal either.  
Its configure script is not made by autoconf and it does not  
understand the --host option merge-universal adds so I get:

DEBUG: Assembled command: 'cd "/mp/var/macports/build/ 
_Users_rschmidt_macports_dports_archivers_zlib/work/ppc64" && ./ 
configure --prefix=/mp --shared --host=powerpc64-apple-darwin'
usage:
   configure [--shared] [--prefix=PREFIX]  [--exec_prefix=EXPREFIX]
      [--libdir=LIBDIR] [--includedir=INCLUDEDIR]

zlib uses a post-configure phase to insert the $ 
{configure.universal_cflags} into the Makefile in the right place.  
With merge-universal, the universal CFLAGS change for each arch. Does  
merge-universal call the post-configure procedure once for each arch  
with the correct value of ${configure.universal_cflags} and $ 
{worksrcpath} for that arch? I don't think it does, but I imagine  
that "weird" ports that don't have usual autoconf-based configure  
scripts are especially in need of help with universal builds, so I  
think we need to give the port the freedom to do things in post- 
configure or other pre- and post- phases, per arch.



From apple at frinabulax.org  Thu Jan 22 05:52:15 2009
From: apple at frinabulax.org (robert delius royar)
Date: Thu, 22 Jan 2009 08:52:15 -0500
Subject: A PortGroup for building more 32/64-bit universal packages
In-Reply-To: <535C8C58-0098-407C-9BA3-149E661D53BF@macports.org>
References: <loom.20090112T211017-72@post.gmane.org>
	<C03A6AA5-2CDD-4D7B-B462-3F7C1F2D0225@macports.org>
	<535C8C58-0098-407C-9BA3-149E661D53BF@macports.org>
Message-ID: <alpine.OSX.2.00L.0901220833170.14888@teraqry.sevanohynk.bet>

Thu, 22 Jan 2009 (06:31 -0600 UTC) Ryan Schmidt wrote:

> zlib uses a post-configure phase to insert the ${configure.universal_cflags} 
> into the Makefile in the right place. With merge-universal, the universal 
> CFLAGS change for each arch. Does merge-universal call the post-configure 
> procedure once for each arch with the correct value of 
> ${configure.universal_cflags} and ${worksrcpath} for that arch? I don't think 
> it does, but I imagine that "weird" ports that don't have usual 
> autoconf-based configure scripts are especially in need of help with 
> universal builds, so I think we need to give the port the freedom to do 
> things in post-configure or other pre- and post- phases, per arch.

With the latest version of autoconf in macports (2.63_0) used as one of 
the auto-tools, any configure will see an -arch statement as a possible 
signal for ENDIAN setting.  If any -arch is used and the system is 
MAC_OS, it sets ac_cv_c_bigendian=universal.  Some configure scripts' 
programs see this as ac_cv_c_bigendian=no because they test for a 'yes' 
value.  The program may compile and run but have errors when it needs to 
access bitwise information.

I discovered this when I compiled (on my own) a recent version of XEmacs 
21.5 (beta28).  I was trying to test it with bignum support for ppc64. 
It failed to dump when it tried to access a byte-compiled lisp file that 
depended on the bit order of a variable.

The XEmacs team knows about this problem, but judging from the tests in 
/opt/local/share/autoconf/autoconf/c.m4, it looks to me that other 
packages that depend on configure could make the same error if the ones 
who maintain the package (upstream) don't have a way to further check 
the ENDIANess on the machine (or know directly about fat binaries).

I just stumbled on this because I wanted to be able to report whether 
the 64-bit compilation would work for PPC.  There had been previous 
reported problems on SPARC and at least one other for 64 bit.  The error 
is the type that might go unnoticed if all you looked for was the 
program's ability to load and run.  The crash was in lisp code and not a 
"real" crash.

-- 
Dr. Robert Delius Royar                   Associate Professor of English
Morehead State University                             Morehead, Kentucky

From ryandesign at macports.org  Thu Jan 22 06:16:36 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 22 Jan 2009 08:16:36 -0600
Subject: A PortGroup for building more 32/64-bit universal packages
In-Reply-To: <42F9E575-EE49-4803-A7D0-335B642DD22F@me.com>
References: <loom.20090112T211017-72@post.gmane.org>
	<5309C989-0EF4-4B7C-A574-45CCA2F1E774@macports.org>
	<42F9E575-EE49-4803-A7D0-335B642DD22F@me.com>
Message-ID: <34268EAC-B2CA-411C-892D-79A402E2DABC@macports.org>

I don't believe this reply from Marcus ever made it to the list, so  
I'm sending it there now with some commentary of my own.

On Jan 13, 2009, at 05:49, Marcus Calhoun-Lopez wrote:

> On Jan 12, 2009, at 7:30 PM, Ryan Schmidt wrote:
>
>> Any particular reason you chose to implement it as a PortGroup?
> The only reason was how quickly it could be refined, tested, and  
> put into use.
>
> Ports like cairo (as you well know), openssl, and fftw-3 spend a  
> fair amount of code trying to support universal builds.
> Their support is a little fragile due to the need to merge header  
> files.
> Further, openssl was recently updated without maintainer approval,  
> so it is not guaranteed that all of that universal code still works  
> as intended.

Of course, just because a maintainer updates a port doesn't mean the  
update is perfect. I would guess most maintainers do not try every  
variant of their ports with every update, and that would include the  
universal variant. Sometimes for example platform-specific patches do  
not get updated (and then fail to apply on that platform) because the  
maintainer did not have access to that platform.

> So I see a strong need for a better merge capability.

The need is certainly there.

> So far, I have only used merge_universal-1.0.tcl to build universal  
> versions of gmp, libffi, and mpfr.
> No doubt further features are needed to be of general use.
> Using a PortGroup would allow faster refinement.

That is the one reason I can see for having it as a portgroup -- that  
portgroups can be used right away, since they're now part of the  
dports tree, whereas a base change would have to wait for a new  
MacPorts release before it could be incorporated into ports.

> As a side note, mpfr built using both universal mechanisms (- 
> arch ... -arch ... and merging), but they produced different binaries
> due to a variable HAVE_LDOUBLE_IEEE_EXT_LITTLE.
>
> Perhaps it is bad policy to use a PortGroup this way, but it seemed  
> better than waiting for the next version release
> (perhaps even two releases if bugs are found).

By now you've committed it as a portgroup so it's out there and we  
may as well try to use it in a few ports and see what happens. We can  
always bring it back into base later if it works well.

My concern with it being a portgroup was whether there was any chance  
that someone might want to use this merge mechanism in a port that  
already used another portgroup. On the other hand, maybe every  
portgroup needs to provide its own universal mechanism. Universal  
builds are certainly different in the xcode portgroup for example.

>> I had figured we should modify the base code to offer different  
>> universal build mechanisms, and then the "universal_variant"  
>> boolean keyword would go away and be replaced with something more  
>> descriptive like "universal_method" which would say how to build  
>> universal. There should be ways to accommodate all the situations:
>>
>> * port builds universal with one configure/build with multiple  
>> arch flags (existing MacPorts way)
>> * port builds universal with multiple configures/builds with one  
>> arch flag each time (your way)
>> * port has no architecture-specific files and is arch-agnostic
>> * port is broken and cannot be built universal
>> * (default value:) port's universal capabilities are not known;  
>> provide a universal variant but warn that it may not work
> This sounds like a good idea.
> Ports like xorg-cf-files (which installs only text files) and gcc43  
> (which does not support universal builds) should not
> be lumped together as "universal_variant  no."
>
>> * port builds universal with no help (or is distributed as a  
>> binary that is universal)
> The port AquaTerm builds (ppc/i386) universal by default.
> A patch is applied to keep it on a single architecture without the  
> universal variant.
> This seems like a reasonable policy: try as much as possible to not  
> have universal unless asked for.

Yes... I introduced this "always universal" thing in several of my  
ports, and some others, because I did not have the expertise to apply  
such patches to disable the universal build.

> This may be more trouble than it is worth, but lipo could be used  
> to "thin out" a port which is distributed as a universal binary.

Using lipo to thin a provided universal binary is an interesting idea  
I hadn't considered.

>> We also have the need for a port to be able to indicate which  
>> architectures it can be built for (or possibly, which  
>> architectures it cannot be built for). This way a user could  
>> define universal_archs to the full set of i386 ppc x86_64 ppc64 in  
>> macports.conf and if a particular port does not work with all of  
>> those at this time, it could specify.
> So there could be a variable universal_support which could have the  
> values, for example,
> one_processor   for just 32/64 universal (the default?)
>                 just32   for just ppc/i386 universal
>                      full    for all four architectures
> These variable could then be used to construct a variable  
> universal_archs_supported which would be universal_archs (supplied  
> by the user)
> pruned down based on universal_support.

I don't know that we need such abstractions as "one_processor",  
"just32" or "full". I think it will suffice for the portfile to  
specify either the architectures it can be built on, or the  
architectures it cannot be built on (I'm not sure which of those is  
better yet, though I'm leaning towards the former).

>> I had also wanted for MacPorts to record for which architectures a  
>> port was built, and then for it to be able to show this in places  
>> like "port installed". Otherwise it's confusing when you want to  
>> upgrade a port from say a 2-way universal to a 4-way universal build.
> I am not all that familiar with the registry, but this doesn't  
> sound too bad.
> Is it just a matter of saving universal_archs_supported in the  
> registry using property_store?

I think you've just demonstrated that you know more about the  
registry than I. :)

>> There are other messages in the archive where I've talked about  
>> these topics before.
> I will try to read up.

I mostly just made the same suggestions about future directions. I  
don't recall there being much ensuing discussion.


From raphael at ira.uka.de  Thu Jan 22 11:30:19 2009
From: raphael at ira.uka.de (Raphael Straub)
Date: Thu, 22 Jan 2009 20:30:19 +0100
Subject: Geomview port does not work with xorg-libs of MacPorts
In-Reply-To: <D1ABA5A7-9936-429C-BE59-F13D50445A5E@macports.org>
References: <1DA3AB3A-18C8-46FF-8CC6-399B3084E895@ira.uka.de>
	<D1ABA5A7-9936-429C-BE59-F13D50445A5E@macports.org>
Message-ID: <62DBB44E-6A0B-466E-99FF-5F9AFBE9F012@ira.uka.de>

Jeremy Huddleston wrote:
> Looks like #17558

Yes, it seems to be a similar problem.

> Did you actually do a 'sudo port -v upgrade outdated' ?

I first only upgraded geomview and all its dependencies. But even now,  
after upgrading all outdated ports, I still have the same problems.

> If you still have the same linking issues, go into /opt/local/lib  
> and figure out what libs are still linking against /usr/X11/lib/*.

Yes, some libraries in ${prefix}/lib are still linked against /usr/X11/ 
lib/*. For example, libXm.4.0.1.dylib (openmotif) and libXaw3d. 
8.0.dylib (Xaw3d). In both cases a complete rebuild of these libraries  
does not help.

Can anybody confirm these issues or this just my MacPorts  
installation? I have MacPorts 1.7 with Xcode 3.1.2 on a MacBook Pro  
Core Duo with Mac OS X 10.5.6. The only non-standard parts of my  
MacPorts configuration are a different ${prefix} and a different  
install user and group.

Regards,
	Raphael
-- 
Raphael Straub                              E-Mail: raphael at ira.uka.de
Universit?t Karlsruhe                       Tel.  : +49 721 608-4383
Institut f?r Betriebs- und Dialogsysteme    Fax   : +49 721 608-8330
Am Fasanengarten 5, 76128 Karlsruhe         Geb. 50.34, Raum 127


From florian.ebeling at gmail.com  Thu Jan 22 12:55:49 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Thu, 22 Jan 2009 21:55:49 +0100
Subject: Macports revdep-rebuild
In-Reply-To: <4ec7f0880901201808t62750350wf215fbd721ded770@mail.gmail.com>
References: <d27d7610901201722j598cbba0t313f24f464db03ae@mail.gmail.com>
	<4ec7f0880901201801t66c70273sa95bf14d34cffd23@mail.gmail.com>
	<4ec7f0880901201808t62750350wf215fbd721ded770@mail.gmail.com>
Message-ID: <5cbbe4ae0901221255q57fbdc0bh547e3321cc62781@mail.gmail.com>

Hi Thomas,

> I recently started to port revdep-rebuild to macports. It is still a
> bit brutal but it works.
> What still lacks is mainly ports order resolution and I would need
> some pointers / contribution as to how to do it.
> I tried to adapt gentoo/portage vocabulary to macports but maybe
> forgot some options.
>
> please tell me about bugs ;)

I haven't tested anything yet and can't give qualified feedback
but big ups for working on that! I think it's one important missing
piece to (heh:) emerge.

Florian



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

From blb at macports.org  Thu Jan 22 13:20:55 2009
From: blb at macports.org (Bryan Blackburn)
Date: Thu, 22 Jan 2009 14:20:55 -0700
Subject: haskell port group
In-Reply-To: <32805DA2-85D6-4E02-8454-301F365DE4B9@macports.org>
References: <20090115052156.GL711@ninagal.withay.com>
	<0A6F9D5B-FCF1-4547-97FC-19DD6BF7D963@macports.org>
	<20090116041116.GJ805@ninagal.withay.com>
	<32805DA2-85D6-4E02-8454-301F365DE4B9@macports.org>
Message-ID: <20090122212055.GD691@ninagal.withay.com>

On Thu, Jan 22, 2009 at 06:28:42AM -0600, Ryan Schmidt said:
>
> On Jan 14, 2009, at 23:21, Bryan Blackburn wrote:
>
>> FYI, for those interested, I just added a port group for haskell [1], 
>> which
>> currently supports only ghc (which seems okay since the other hs-*  
>> ports I
>> checked are all ghc-specific).  It does the standard 'runhaskell  
>> Setup...'
>> routine.
>
> Could you fix up this portgroup to use 4 spaces per tab like the rest of 
> the MacPorts source, instead of 3, and add a corresponding modeline? 
> Thanks.

Umm, there are no tabs; I can switch it to 4-space indentation if that'd
make you happy though?

Bryan


From simon at ruderich.org  Thu Jan 22 14:10:27 2009
From: simon at ruderich.org (Simon Ruderich)
Date: Thu, 22 Jan 2009 23:10:27 +0100
Subject: [45792] trunk/dports/net/ASFRecorder/Portfile
In-Reply-To: <20090122075857.8081ACF7D86@beta.macosforge.org>
References: <20090122075857.8081ACF7D86@beta.macosforge.org>
Message-ID: <20090122221027.GA14590@ruderich.org>

On Wed, Jan 21, 2009 at 11:58:57PM -0800, digdog at macports.org wrote:
> Revision: 45792
>           http://trac.macports.org/changeset/45792
> Author:   digdog at macports.org
> Date:     2009-01-21 23:58:56 -0800 (Wed, 21 Jan 2009)
> Log Message:
> -----------
> update maintainer tag
> remove freebsd platform

Hi,

Why are you removing the freebsd platform? I know MacPorts is now
MacPorts, but if the ports also work on different platforms I
don't think we should break it deliberately.

Simon
-- 
+ privacy is necessary
+ using http://gnupg.org
+ public key id: 0x6115F804EFB33229
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090122/f2e43190/attachment.bin>

From mcalhoun at macports.org  Thu Jan 22 14:25:15 2009
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Thu, 22 Jan 2009 22:25:15 +0000 (UTC)
Subject: A PortGroup for building more 32/64-bit universal packages
References: <loom.20090112T211017-72@post.gmane.org>
	<C03A6AA5-2CDD-4D7B-B462-3F7C1F2D0225@macports.org>
Message-ID: <loom.20090122T214320-671@post.gmane.org>

Ryan Schmidt <ryandesign at ...> writes:

> I decided to start with pkgconfig because it has no dependencies and  
> has issues building 64-bit with the old way.
I got pkgconfig and merge_universal to build with the following addition
if { ${os.arch}=="i386" } {
        set universal_archs_supported  "ppc i386 x86_64"
} else {
        set universal_archs_supported  "ppc ppc64"
}

I think that the only time this will fail is on a non-G5 PowerPC system
whose user has (for some reason) set universal_archs to include ppc64.

I will open a ticket as a place to put the still small number of ports which
seem to work with merge_universal.

> There's a bug open with the authors of pkg-config but there has been  
> no response to it in a year and a half so I'm not hopeful. I suppose  
> I should ask the authors of glib instead.

I would suggest that PowerPC/x86 universal should be a low priority.
Of course, that is easy for me to say since I have no need of it.

-Marcus


From jeremyhu at macports.org  Thu Jan 22 14:26:20 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Thu, 22 Jan 2009 14:26:20 -0800
Subject: Geomview port does not work with xorg-libs of MacPorts
In-Reply-To: <62DBB44E-6A0B-466E-99FF-5F9AFBE9F012@ira.uka.de>
References: <1DA3AB3A-18C8-46FF-8CC6-399B3084E895@ira.uka.de>
	<D1ABA5A7-9936-429C-BE59-F13D50445A5E@macports.org>
	<62DBB44E-6A0B-466E-99FF-5F9AFBE9F012@ira.uka.de>
Message-ID: <34EFB0F8-8943-4127-8A74-7F3A86C7B960@macports.org>


On Jan 22, 2009, at 11:30, Raphael Straub wrote:
> Yes, some libraries in ${prefix}/lib are still linked against /usr/ 
> X11/lib/*. For example, libXm.4.0.1.dylib (openmotif) and libXaw3d. 
> 8.0.dylib (Xaw3d). In both cases a complete rebuild of these  
> libraries does not help.

Ok, then there is a bug in those ports and they need to be adjusted to  
link against the correct libs.  Please file a ticket and assign it to  
me, and I'll get to it soon.

> Can anybody confirm these issues or this just my MacPorts  
> installation? I have MacPorts 1.7 with Xcode 3.1.2 on a MacBook Pro  
> Core Duo with Mac OS X 10.5.6. The only non-standard parts of my  
> MacPorts configuration are a different ${prefix} and a different  
> install user and group.


In the mean time, there's a code snippet to do some install_name_tool  
fixes in bug #17558 that you can use.



From mcalhoun at macports.org  Thu Jan 22 14:26:16 2009
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Thu, 22 Jan 2009 22:26:16 +0000 (UTC)
Subject: A PortGroup for building more 32/64-bit universal packages
References: <loom.20090112T211017-72@post.gmane.org>
	<C03A6AA5-2CDD-4D7B-B462-3F7C1F2D0225@macports.org>
	<535C8C58-0098-407C-9BA3-149E661D53BF@macports.org>
Message-ID: <loom.20090122T221507-682@post.gmane.org>

Ryan Schmidt <ryandesign at ...> writes:

> I  think we need to give the port the freedom to do things in post- 
> configure or other pre- and post- phases, per arch.
As it stands now, any port which uses
post-configure, pre-build, post-build, or pre-destroot
will have to be modified to work with the merge_universal PortGroup.
pre-configure and post-destroot might work fine.

Fixing this would be great, but I am not sure of how to proceed.

-Marcus







From mcalhoun at macports.org  Thu Jan 22 14:25:36 2009
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Thu, 22 Jan 2009 22:25:36 +0000 (UTC)
Subject: A PortGroup for building more 32/64-bit universal packages
References: <loom.20090112T211017-72@post.gmane.org>
	<C03A6AA5-2CDD-4D7B-B462-3F7C1F2D0225@macports.org>
	<535C8C58-0098-407C-9BA3-149E661D53BF@macports.org>
	<alpine.OSX.2.00L.0901220833170.14888@teraqry.sevanohynk.bet>
Message-ID: <loom.20090122T221249-486@post.gmane.org>

robert delius royar <apple at ...> writes:

>  If any -arch is used and the system is 
> MAC_OS, it sets ac_cv_c_bigendian=universal.
In the merge_universal PortGroup, -m32 and -m64 are used instead
-arch ... if possible.
Would these same problems arise with -m...?






From jeremyhu at macports.org  Thu Jan 22 15:17:54 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Thu, 22 Jan 2009 15:17:54 -0800
Subject: Geomview port does not work with xorg-libs of MacPorts
In-Reply-To: <62DBB44E-6A0B-466E-99FF-5F9AFBE9F012@ira.uka.de>
References: <1DA3AB3A-18C8-46FF-8CC6-399B3084E895@ira.uka.de>
	<D1ABA5A7-9936-429C-BE59-F13D50445A5E@macports.org>
	<62DBB44E-6A0B-466E-99FF-5F9AFBE9F012@ira.uka.de>
Message-ID: <B3507656-888A-436F-B86F-B6F92A6B882F@macports.org>


On Jan 22, 2009, at 11:30, Raphael Straub wrote:

> Yes, some libraries in ${prefix}/lib are still linked against /usr/ 
> X11/lib/*. For example, libXm.4.0.1.dylib (openmotif) and libXaw3d. 
> 8.0.dylib (Xaw3d). In both cases a complete rebuild of these  
> libraries does not help.

Those ports have now been updated to link against the libs in $prefix  
rather than $x11prefix


From apple at frinabulax.org  Thu Jan 22 15:21:13 2009
From: apple at frinabulax.org (robert delius royar)
Date: Thu, 22 Jan 2009 18:21:13 -0500
Subject: A PortGroup for building more 32/64-bit universal packages
In-Reply-To: <loom.20090122T221249-486@post.gmane.org>
References: <loom.20090112T211017-72@post.gmane.org>
	<C03A6AA5-2CDD-4D7B-B462-3F7C1F2D0225@macports.org>
	<535C8C58-0098-407C-9BA3-149E661D53BF@macports.org>
	<alpine.OSX.2.00L.0901220833170.14888@teraqry.sevanohynk.bet>
	<loom.20090122T221249-486@post.gmane.org>
Message-ID: <alpine.OSX.2.00L.0901221813090.2980@teraqry.sevanohynk.bet>

Thu, 22 Jan 2009 (22:25 -0000 UTC) Marcus Calhoun-Lopez wrote:

> robert delius royar <apple at ...> writes:
>
>>  If any -arch is used and the system is
>> MAC_OS, it sets ac_cv_c_bigendian=universal.
> In the merge_universal PortGroup, -m32 and -m64 are used instead
> -arch ... if possible.
> Would these same problems arise with -m...?

I just tried the -m64 flag with the XEmacs configure file that was 
configured with autoconf 2.63, the build completed, including the dump 
and configure saw BIGENDIAN as yes.  I will try the -m32 flag and lipo 
when I have some time to figure out how to do this for XEmacs, but it 
looks like this one problem could be avoided with -m32 and -m64 rather 
than using -arch.

-- 
Dr. Robert Delius Royar                   Associate Professor of English
Morehead State University                             Morehead, Kentucky

From ryandesign at macports.org  Fri Jan 23 00:15:30 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 23 Jan 2009 02:15:30 -0600
Subject: sh is crashing, errors in szone_malloc, fork
Message-ID: <6FFF0EA2-D2C3-40C1-858A-E4BD90246294@macports.org>

I can't install php5 on one of my machines. As a maintainer of php5,  
this is a bit of a problem. I also can't upgrade libxml2. The error  
is different everytime but often it's sh that crashes, and often the  
error message mentions libtool. This is a MacBookPro3,1 with Mac OS X  
10.4.11 and MacPorts 1.7.0. I have restarted the computer, I have  
uninstalled and reinstalled Xcode 2.5, I have uninstalled and  
reinstalled libtool @2.2.6a_0. From the error messages below, does  
anyone have any suggestions? I'm not in the mood for an OS reinstall.


------------------------------------


php5:


2009-01-23 01:41:17 -0600

EXC_BAD_ACCESS (0x0001)
KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
0    0x1000 + 61155
1    0x1000 + 57355
2    0x1000 + 67011
3    0x1000 + 58795
4    0x1000 + 218128
5    0x1000 + 112990
6    0x1000 + 131800
7    0x1000 + 136043
8    0x1000 + 137012
9    0x1000 + 138548


libtool: compile: cannot determine name of library object from `'


------------------------------------


2009-01-23 01:45:40 -0600

EXC_BAD_ACCESS (0x0001)
KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
0    0x1000 + 61128
1    0x1000 + 57355
2    0x1000 + 67137
3    0x1000 + 58795
4    0x1000 + 218128
5    0x1000 + 112990
6    0x1000 + 131800
7    0x1000 + 136043
8    0x1000 + 137012
9    0x1000 + 138548


/mp/var/macports/build/_Users_rschmidt_macports_dports_www_php5/work/ 
php-5.2.8/libtool: line 1:  2491 Bus error


------------------------------------


2009-01-23 01:50:58 -0600

EXC_BAD_ACCESS (0x0001)
KERN_PROTECTION_FAILURE (0x0002) at 0x9043d7e0

Thread 0 Crashed:
0    szone_malloc + 522
1    malloc + 597
2    0x1000 + 209427
3    0x1000 + 40990
4    0x1000 + 83489
5    0x1000 + 134344
6    0x1000 + 61366
7    0x1000 + 57355
8    0x1000 + 67011
9    0x1000 + 58795


2009-01-23 01:51:20 -0600

EXC_BAD_ACCESS (0x0001)
KERN_PROTECTION_FAILURE (0x0002) at 0x9003b7dc

Thread 0 Crashed:
0    fork + 199
1    0x1000 + 61071
2    0x1000 + 57355
3    0x1000 + 67137
4    0x1000 + 58795
5    0x1000 + 218128
6    0x1000 + 112990
7    0x1000 + 131800
8    0x1000 + 136043
9    0x1000 + 137012


i686-apple-darwin8-gcc-4.0.1: no input files


------------------------------------


libxml2:


2009-01-23 02:02:20 -0600

EXC_BAD_ACCESS (0x0001)
KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
0    0x1000 + 61155
1    0x1000 + 57355
2    0x1000 + 67011
3    0x1000 + 58795
4    0x1000 + 218128
5    0x1000 + 112990
6    0x1000 + 131800
7    0x1000 + 136043
8    0x1000 + 137012
9    0x1000 + 138548


rm: .libs/: is a directory
rm: .libs/: is a directory
  /usr/bin/gcc-4.0 -DHAVE_CONFIG_H -I. -I./include -I./include - 
D_REENTRANT -I/mp/include -isysroot /Developer/SDKs/MacOSX10.4u.sdk - 
O2 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch x86_64 - 
arch ppc -arch ppc64 -pedantic -W -Wformat -Wunused -Wimplicit - 
Wreturn-type -Wswitch -Wcomment -Wtrigraphs -Wformat -Wchar- 
subscripts -Wuninitialized -Wparentheses -Wshadow -Wpointer-arith - 
Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes - 
Wmissing-prototypes -Wnested-externs -Winline -Wredundant-decls -c  
xmlmodule.c  -fno-common -DPIC -o .libs/
lipo: can't create output file: .libs/ (Is a directory)




From ryandesign at macports.org  Fri Jan 23 00:20:23 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 23 Jan 2009 02:20:23 -0600
Subject: haskell port group
In-Reply-To: <20090122212055.GD691@ninagal.withay.com>
References: <20090115052156.GL711@ninagal.withay.com>
	<0A6F9D5B-FCF1-4547-97FC-19DD6BF7D963@macports.org>
	<20090116041116.GJ805@ninagal.withay.com>
	<32805DA2-85D6-4E02-8454-301F365DE4B9@macports.org>
	<20090122212055.GD691@ninagal.withay.com>
Message-ID: <651FD82F-C327-4964-BEB7-40CC370D7589@macports.org>


On Jan 22, 2009, at 15:20, Bryan Blackburn wrote:

> On Thu, Jan 22, 2009 at 06:28:42AM -0600, Ryan Schmidt said:
>>
>> On Jan 14, 2009, at 23:21, Bryan Blackburn wrote:
>>
>>> FYI, for those interested, I just added a port group for haskell  
>>> [1],
>>> which
>>> currently supports only ghc (which seems okay since the other hs-*
>>> ports I
>>> checked are all ghc-specific).  It does the standard 'runhaskell
>>> Setup...'
>>> routine.
>>
>> Could you fix up this portgroup to use 4 spaces per tab like the  
>> rest of
>> the MacPorts source, instead of 3, and add a corresponding modeline?
>> Thanks.
>
> Umm, there are no tabs; I can switch it to 4-space indentation if  
> that'd
> make you happy though?

Right, that's what I meant. Other source files in MacPorts,  
Portfiles, and our recommended modeline say code should use four  
spaces in place of a tab character, but yours uses 3. I think we  
should use consistent style in our base source files.




From opendarwin.org at darkart.com  Fri Jan 23 09:36:48 2009
From: opendarwin.org at darkart.com (Eric Hall)
Date: Fri, 23 Jan 2009 17:36:48 +0000
Subject: sh is crashing, errors in szone_malloc, fork
In-Reply-To: <6FFF0EA2-D2C3-40C1-858A-E4BD90246294@macports.org>
References: <6FFF0EA2-D2C3-40C1-858A-E4BD90246294@macports.org>
Message-ID: <20090123173648.GK1155@darkart.com>

On Fri, Jan 23, 2009 at 02:15:30AM -0600, Ryan Schmidt wrote:
> I can't install php5 on one of my machines. As a maintainer of php5,  
> this is a bit of a problem. I also can't upgrade libxml2. The error  
> is different everytime but often it's sh that crashes, and often the  
> error message mentions libtool. This is a MacBookPro3,1 with Mac OS X  
> 10.4.11 and MacPorts 1.7.0. I have restarted the computer, I have  
> uninstalled and reinstalled Xcode 2.5, I have uninstalled and  
> reinstalled libtool @2.2.6a_0. From the error messages below, does  
> anyone have any suggestions? I'm not in the mood for an OS reinstall.
> 

	Have you run a memory check?  Do other things crash
at random?


		-eric


From brad at pixilla.com  Fri Jan 23 13:06:57 2009
From: brad at pixilla.com (Bradley Giesbrecht)
Date: Fri, 23 Jan 2009 13:06:57 -0800
Subject: [MacPorts] #17783: bind9 9.5.0-P2 add variant +dlz_mysql5
In-Reply-To: <061.121556b7391db1eeae1ca3a0ff7c52f6@macports.org>
References: <052.afd8ce25043c7ef939df49ffceb03bc3@macports.org>
	<061.121556b7391db1eeae1ca3a0ff7c52f6@macports.org>
Message-ID: <44C332CA-FFFC-41CF-A3AB-10A05B0ADAE6@pixilla.com>

On Jan 23, 2009, at 10:51 AM, MacPorts wrote:

> #17783: bind9 9.5.0-P2 add variant +dlz_mysql5
> ------------------------------ 
> +---------------------------------------------
> Reporter:  brad@?            |       Owner:  dluke@?
>     Type:  enhancement       |      Status:  new
> Priority:  Normal            |   Milestone:  Port Enhancements
> Component:  ports             |     Version:  1.7.0
> Keywords:  bind mysql dlz    |        Port:  bind9
> ------------------------------ 
> +---------------------------------------------
>
> Comment(by dluke@?):
>
> Per our email conversation, you wouldn't have had a chance to update  
> this
> to pass the mysql include/lib directories into the build instead of
> creating those symlinks would you?

Sorry, I forgot to get back with you. My bad.

So what I was doing was creating a link to the mysql include/lib  
directories in work/mysql and adding --with-dlz-mysql=${workpath}/mysql.

I guess this isn't a good idea, right?
This is how php5 is built which is where I got the idea.

BTW, I named it dlz_mysql so if some other port has bind9 as a  
dependency and also has a +mysql variant it won't automatically build  
bind9 with dlz-mysql.
Is this a good idea or does it even work that way?


From dluke at geeklair.net  Fri Jan 23 13:34:29 2009
From: dluke at geeklair.net (Daniel J. Luke)
Date: Fri, 23 Jan 2009 16:34:29 -0500
Subject: [MacPorts] #17783: bind9 9.5.0-P2 add variant +dlz_mysql5
In-Reply-To: <44C332CA-FFFC-41CF-A3AB-10A05B0ADAE6@pixilla.com>
References: <052.afd8ce25043c7ef939df49ffceb03bc3@macports.org>
	<061.121556b7391db1eeae1ca3a0ff7c52f6@macports.org>
	<44C332CA-FFFC-41CF-A3AB-10A05B0ADAE6@pixilla.com>
Message-ID: <E0ABD236-617A-4601-89EC-50FBF3715853@geeklair.net>

On Jan 23, 2009, at 4:06 PM, Bradley Giesbrecht wrote:
> So what I was doing was creating a link to the mysql include/lib  
> directories in work/mysql and adding --with-dlz-mysql=${workpath}/ 
> mysql.
>
> I guess this isn't a good idea, right?

It's a style thing. I generally prefer not doing it (especially if you  
can pass appropriate directories to the configure script so it adds -I  
and -L options when building).

> This is how php5 is built which is where I got the idea.
>
> BTW, I named it dlz_mysql so if some other port has bind9 as a  
> dependency and also has a +mysql variant it won't automatically  
> build bind9 with dlz-mysql.
> Is this a good idea or does it even work that way?


I think it's a good idea.

--
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/20090123/c60c7c4f/attachment.bin>

From raimue at macports.org  Fri Jan 23 19:29:08 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 24 Jan 2009 04:29:08 +0100
Subject: [45792] trunk/dports/net/ASFRecorder/Portfile
In-Reply-To: <20090122221027.GA14590@ruderich.org>
References: <20090122075857.8081ACF7D86@beta.macosforge.org>
	<20090122221027.GA14590@ruderich.org>
Message-ID: <497A8B04.80109@macports.org>

Simon Ruderich wrote:
> On Wed, Jan 21, 2009 at 11:58:57PM -0800, digdog at macports.org wrote:
>> Revision: 45792
>>           http://trac.macports.org/changeset/45792
>> Author:   digdog at macports.org
>> Date:     2009-01-21 23:58:56 -0800 (Wed, 21 Jan 2009)
>> Log Message:
>> -----------
>> update maintainer tag
>> remove freebsd platform
> 
> Hi,
> 
> Why are you removing the freebsd platform? I know MacPorts is now
> MacPorts, but if the ports also work on different platforms I
> don't think we should break it deliberately.

Actually the platform statement is not used at all at the moment and is
not checked against the OS platform when installing a port. But it is a
mandatory field for a Portfile and can be used by maintainers to express
on which platforms this was tested or is supposed to work on.

Rainer

From illogical1 at gmail.com  Fri Jan 23 20:43:16 2009
From: illogical1 at gmail.com (Orville Bennett)
Date: Fri, 23 Jan 2009 23:43:16 -0500
Subject: cmake and kde4 portgroups
Message-ID: <D4EBDAE8-D3A4-42BA-9437-54F0945506E1@gmail.com>

Tried my hand at cmake and kde4 portgroups. Here's what I came up  
with. I don't know how to use these so that I can test them though...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kde4-1.0.tcl
Type: application/octet-stream
Size: 1980 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090123/b080a0ae/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmake-1.0.tcl
Type: application/octet-stream
Size: 1469 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090123/b080a0ae/attachment-0001.obj>

From ryandesign at macports.org  Sat Jan 24 00:19:48 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 24 Jan 2009 02:19:48 -0600
Subject: cmake and kde4 portgroups
In-Reply-To: <D4EBDAE8-D3A4-42BA-9437-54F0945506E1@gmail.com>
References: <D4EBDAE8-D3A4-42BA-9437-54F0945506E1@gmail.com>
Message-ID: <97C14C2C-51CB-4E2C-8851-B59D57DD7FE5@macports.org>

On Jan 23, 2009, at 22:43, Orville Bennett wrote:

> Tried my hand at cmake and kde4 portgroups. Here's what I came up  
> with. I don't know how to use these so that I can test them though...

I think you just have to put them in your dports/_resources/port1.0/ 
group directory and then use them from a port with a statement like  
"PortGroup cmake 1.0"

In the cmake portgroup, I think -DCMAKE_INSTALL_PREFIX=${prefix}  
shouldn't be in configure.args; it should replace what's in  
configure.pre_args.


From illogical1 at gmail.com  Sat Jan 24 10:55:25 2009
From: illogical1 at gmail.com (Orville Bennett)
Date: Sat, 24 Jan 2009 13:55:25 -0500
Subject: cmake and kde4 portgroups
In-Reply-To: <97C14C2C-51CB-4E2C-8851-B59D57DD7FE5@macports.org>
References: <D4EBDAE8-D3A4-42BA-9437-54F0945506E1@gmail.com>
	<97C14C2C-51CB-4E2C-8851-B59D57DD7FE5@macports.org>
Message-ID: <8F69C76C-A6F5-4A29-8801-29F0D07E14FF@gmail.com>


On Jan 24, 2009, at 3:19 AM, Ryan Schmidt wrote:

> On Jan 23, 2009, at 22:43, Orville Bennett wrote:
>
>> Tried my hand at cmake and kde4 portgroups. Here's what I came up  
>> with. I don't know how to use these so that I can test them though...
>
> I think you just have to put them in your dports/_resources/port1.0/ 
> group directory and then use them from a port with a statement like  
> "PortGroup cmake 1.0"
That seems to work
>
>
> In the cmake portgroup, I think -DCMAKE_INSTALL_PREFIX=${prefix}  
> shouldn't be in configure.args; it should replace what's in  
> configure.pre_args.
Done. I'll commit "soon"
Here're what the new ones look like
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmake-1.0.tcl
Type: application/octet-stream
Size: 1541 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090124/5a44842d/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kde4-1.0.tcl
Type: application/octet-stream
Size: 1677 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090124/5a44842d/attachment-0001.obj>

From blb at macports.org  Sat Jan 24 12:59:38 2009
From: blb at macports.org (Bryan Blackburn)
Date: Sat, 24 Jan 2009 13:59:38 -0700
Subject: cmake and kde4 portgroups
In-Reply-To: <8F69C76C-A6F5-4A29-8801-29F0D07E14FF@gmail.com>
References: <D4EBDAE8-D3A4-42BA-9437-54F0945506E1@gmail.com>
	<97C14C2C-51CB-4E2C-8851-B59D57DD7FE5@macports.org>
	<8F69C76C-A6F5-4A29-8801-29F0D07E14FF@gmail.com>
Message-ID: <20090124205938.GF827@ninagal.withay.com>

On Sat, Jan 24, 2009 at 01:55:25PM -0500, Orville Bennett said:
>
> On Jan 24, 2009, at 3:19 AM, Ryan Schmidt wrote:
>
>> On Jan 23, 2009, at 22:43, Orville Bennett wrote:
>>
>>> Tried my hand at cmake and kde4 portgroups. Here's what I came up  
>>> with. I don't know how to use these so that I can test them though...
>>
>> I think you just have to put them in your dports/_resources/port1.0/ 
>> group directory and then use them from a port with a statement like  
>> "PortGroup cmake 1.0"
> That seems to work
>>
>>
>> In the cmake portgroup, I think -DCMAKE_INSTALL_PREFIX=${prefix}  
>> shouldn't be in configure.args; it should replace what's in  
>> configure.pre_args.
> Done. I'll commit "soon"
> Here're what the new ones look like

A couple of notes:

For cmake, the bit

configure.pre_args-delete       --prefix=${prefix}
configure.pre_args-append       -DCMAKE_INSTALL_PREFIX=${prefix}

can be simplified to just

configure.pre_args    -DCMAKE_INSTALL_PREFIX=${prefix}

For kde4, I believe the line

post-extract            { file mkdir ${worksrcpath} }

can be replaced with the (new in 1.7)

extract.mkdir    yes

to create it automatically for you.  Though it does it in pre-extract so is
kde4 not using it during extract since yours is post-extract?

Also in kde4, the BUILD_DOC=on in +docs needs to be added to something, I'm
guessing, with a -append?

Bryan


From illogical1 at gmail.com  Sat Jan 24 21:24:47 2009
From: illogical1 at gmail.com (O)
Date: Sun, 25 Jan 2009 00:24:47 -0500
Subject: [45811] trunk/dports/graphics/djvulibre/Portfile
In-Reply-To: <20090122144905.7E9B1D008EA@beta.macosforge.org>
References: <20090122144905.7E9B1D008EA@beta.macosforge.org>
Message-ID: <797cc39c0901242124t79e17d6qb03eee10e0643dbc@mail.gmail.com>

On Thu, Jan 22, 2009 at 9:49 AM,  <macsforever2000 at macports.org> wrote:
> Revision 45811 Author macsforever2000 at macports.org Date 2009-01-22 06:48:59
> -0800 (Thu, 22 Jan 2009)
>
> Log Message
>
> Updated to 3.5.21. (#16941)
>
> Modified Paths
>
> trunk/dports/graphics/djvulibre/Portfile
>
> Diff
>
> Modified: trunk/dports/graphics/djvulibre/Portfile (45810 => 45811)
>
> --- trunk/dports/graphics/djvulibre/Portfile	2009-01-22 14:28:17 UTC (rev
> 45810)
> +++ trunk/dports/graphics/djvulibre/Portfile	2009-01-22 14:48:59 UTC (rev
> 45811)
> @@ -3,7 +3,7 @@
>  PortSystem 1.0
>
>  name       djvulibre
> -version    3.5.19
> +version    3.5.21
>  categories      graphics www
>  platforms       darwin
>  maintainers     nomaintainer
> @@ -15,21 +15,27 @@
>                              looks nicer on a screen and consume less client
> resources than competing \
>                              formats.
>
> -homepage        http://djvulibre.djvuzone.org/
> +homepage        http://djvulibre.sourceforge.net/
>  master_sites    sourceforge:djvu
> -checksums       md5 0330d87ad337e408e21e1018eb511839
> +checksums       md5 4c6f3eb03ffbd067b6d2fe2344b0d9ad
>
>  depends_lib     port:libiconv \
> -		port:jpeg \
> +		        port:jpeg \
>                  port:tiff \
> -		port:qt3
> +                port:libpng \
> +		        port:zlib
>
> -configure.cflags-append "-I${prefix}/include"
> -
> -configure.ldflags-append    "-dylib_file
> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib"
> -
>  configure.args	--mandir=${prefix}/share/man \
>  		--enable-threads \
>  		--enable-shared \
>  		--enable-xmltools \
> -		--with-qt=${prefix}/lib/qt3
> +		--disable-djview
> +		
> +
> +variant djview3 description {Build the (outdated) djview3 viewer. The newer
> QT4-based viewer called 'djview4' is now a separate package called
> 'djview'.} {
> +    depends_lib-append          port:qt3
> +    configure.args-delete       --disable-djview
> +    configure.args-append       --with-qt=${prefix}/lib/qt3
> +    configure.ldflags-append    "-dylib_file
> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib"
> +}
> +
>
> _______________________________________________
> macports-changes mailing list
> macports-changes at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes
>
>
Thanks been meaning to do this so that kdegraphics4 doesn't pull in X
(or qt3). If you view djvu files regularly you might want to check out
okular :-)


-- 

Fred Allen  - "Television is a medium because anything well done is rare."

From ryandesign at macports.org  Sun Jan 25 00:59:57 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 25 Jan 2009 02:59:57 -0600
Subject: cmake and kde4 portgroups
In-Reply-To: <20090124205938.GF827@ninagal.withay.com>
References: <D4EBDAE8-D3A4-42BA-9437-54F0945506E1@gmail.com>
	<97C14C2C-51CB-4E2C-8851-B59D57DD7FE5@macports.org>
	<8F69C76C-A6F5-4A29-8801-29F0D07E14FF@gmail.com>
	<20090124205938.GF827@ninagal.withay.com>
Message-ID: <36F87ADE-3E7E-4561-9504-840AA9BF4385@macports.org>


On Jan 24, 2009, at 14:59, Bryan Blackburn wrote:

> A couple of notes:
>
> For cmake, the bit
>
> configure.pre_args-delete       --prefix=${prefix}
> configure.pre_args-append       -DCMAKE_INSTALL_PREFIX=${prefix}
>
> can be simplified to just
>
> configure.pre_args    -DCMAKE_INSTALL_PREFIX=${prefix}

Agree.


> For kde4, I believe the line
>
> post-extract            { file mkdir ${worksrcpath} }
>
> can be replaced with the (new in 1.7)
>
> extract.mkdir    yes
>
> to create it automatically for you.  Though it does it in pre- 
> extract so is
> kde4 not using it during extract since yours is post-extract?

extract.mkdir was added in MacPorts 1.6.0.

And here he's not making the directory he wants to extract into; he's  
making the directory he wants to build in. Apparently the kde  
recommendation is to build in a directory outside of the source tree.  
So while "extract.mkdir yes" would make the directory for him, it  
would also cause the extraction to happen in that directory, which is  
not what he wants.

I guess the confusion arises because worksrcdir is supposed to be the  
directory where the source is, but you're changing its meaning to be  
where the build is. Perhaps setting build.dir instead of worksrcdir  
would still work and be clearer. Unless you need the configure phase  
to run in that directory as well, in which case you would also set  
configure.dir to the same value. I forget at the moment whether  
configure.dir and build.dir are relative or absolute paths...


> Also in kde4, the BUILD_DOC=on in +docs needs to be added to  
> something, I'm
> guessing, with a -append?

Right... Is this supposed to be an environment variable? In that  
case, "build.env-append BUILD_DOC=on".

And the first word of the description -- "Enables installation of  
documentation" -- isn't right. It should read like a radio button  
label, so it should begin with "Enable" not "Enables". Or better and  
simpler: "Install documentation".

Is "-DKDE_DEFAULT_HOME=Library/Preferences/KDE" correct? Just making  
sure, since that's a relative path.

The line "PortGroup cmake 1.0" at the top of the kde4 portgroup is  
wrong. :)



From blb at macports.org  Sun Jan 25 01:14:49 2009
From: blb at macports.org (Bryan Blackburn)
Date: Sun, 25 Jan 2009 02:14:49 -0700
Subject: cmake and kde4 portgroups
In-Reply-To: <36F87ADE-3E7E-4561-9504-840AA9BF4385@macports.org>
References: <D4EBDAE8-D3A4-42BA-9437-54F0945506E1@gmail.com>
	<97C14C2C-51CB-4E2C-8851-B59D57DD7FE5@macports.org>
	<8F69C76C-A6F5-4A29-8801-29F0D07E14FF@gmail.com>
	<20090124205938.GF827@ninagal.withay.com>
	<36F87ADE-3E7E-4561-9504-840AA9BF4385@macports.org>
Message-ID: <20090125091449.GH827@ninagal.withay.com>

On Sun, Jan 25, 2009 at 02:59:57AM -0600, Ryan Schmidt said:
> On Jan 24, 2009, at 14:59, Bryan Blackburn wrote:
[...]
>> can be replaced with the (new in 1.7)
>>
>> extract.mkdir    yes
>>
>> to create it automatically for you.  Though it does it in pre-extract so 
>> is
>> kde4 not using it during extract since yours is post-extract?
>
> extract.mkdir was added in MacPorts 1.6.0.

Hmm, so it was; not sure why I was thinking 1.7...

>
> And here he's not making the directory he wants to extract into; he's  
> making the directory he wants to build in. Apparently the kde  
> recommendation is to build in a directory outside of the source tree. So 
> while "extract.mkdir yes" would make the directory for him, it would also 
> cause the extraction to happen in that directory, which is not what he 
> wants.
>
> I guess the confusion arises because worksrcdir is supposed to be the  
> directory where the source is, but you're changing its meaning to be  
> where the build is. Perhaps setting build.dir instead of worksrcdir would 
> still work and be clearer. Unless you need the configure phase to run in 
> that directory as well, in which case you would also set configure.dir to 
> the same value. I forget at the moment whether configure.dir and build.dir 
> are relative or absolute paths...

Yeah, that was my confusion having looked at the port group in isolation;
though if a separate build dir is required, the gcc* ports have done this
for ages, which do create the worksrcpath themselves...

[...]
>
> The line "PortGroup cmake 1.0" at the top of the kde4 portgroup is wrong. 
> :)

I was figuring that meant that the kde4 group needs the cmake one, so it
would make an interesting test of recursive port groups...

Bryan


From ryandesign at macports.org  Sun Jan 25 01:26:28 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 25 Jan 2009 03:26:28 -0600
Subject: cmake and kde4 portgroups
In-Reply-To: <20090125091449.GH827@ninagal.withay.com>
References: <D4EBDAE8-D3A4-42BA-9437-54F0945506E1@gmail.com>
	<97C14C2C-51CB-4E2C-8851-B59D57DD7FE5@macports.org>
	<8F69C76C-A6F5-4A29-8801-29F0D07E14FF@gmail.com>
	<20090124205938.GF827@ninagal.withay.com>
	<36F87ADE-3E7E-4561-9504-840AA9BF4385@macports.org>
	<20090125091449.GH827@ninagal.withay.com>
Message-ID: <01E57792-EAC0-4807-A0EC-AE80947DEA5E@macports.org>

On Jan 25, 2009, at 03:14, Bryan Blackburn wrote:

>> The line "PortGroup cmake 1.0" at the top of the kde4 portgroup is  
>> wrong.
>> :)
>
> I was figuring that meant that the kde4 group needs the cmake one,  
> so it
> would make an interesting test of recursive port groups...

Indeed that seems to be what's intended. I didn't know we could  
include one portgroup in another, but it's great if we can.


From simon at ruderich.org  Sun Jan 25 08:16:34 2009
From: simon at ruderich.org (Simon Ruderich)
Date: Sun, 25 Jan 2009 17:16:34 +0100
Subject: [45792] trunk/dports/net/ASFRecorder/Portfile
In-Reply-To: <497A8B04.80109@macports.org>
References: <20090122075857.8081ACF7D86@beta.macosforge.org>
	<20090122221027.GA14590@ruderich.org> <497A8B04.80109@macports.org>
Message-ID: <20090125161511.GA22553@ruderich.org>

On Sat, Jan 24, 2009 at 04:29:08AM +0100, Rainer M?ller wrote:
>
> Actually the platform statement is not used at all at the moment and is
> not checked against the OS platform when installing a port. But it is a
> mandatory field for a Portfile and can be used by maintainers to express
> on which platforms this was tested or is supposed to work on.
>
> Rainer

Hi,

I didn't knew that, I thought if a platform is missing from
"platforms" then the port can't be installed. Thanks for the
information.

Then it's of course a good idea to remove it.

Simon
-- 
+ privacy is necessary
+ using http://gnupg.org
+ public key id: 0x6115F804EFB33229
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090125/edece056/attachment.bin>

From ryandesign at macports.org  Sun Jan 25 16:06:55 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 25 Jan 2009 18:06:55 -0600
Subject: [45792] trunk/dports/net/ASFRecorder/Portfile
In-Reply-To: <20090125161511.GA22553@ruderich.org>
References: <20090122075857.8081ACF7D86@beta.macosforge.org>
	<20090122221027.GA14590@ruderich.org> <497A8B04.80109@macports.org>
	<20090125161511.GA22553@ruderich.org>
Message-ID: <0F2E0F1C-55AC-4C4B-8411-DB71E25A3485@macports.org>


On Jan 25, 2009, at 10:16, Simon Ruderich wrote:

> On Sat, Jan 24, 2009 at 04:29:08AM +0100, Rainer M?ller wrote:
>
>> Actually the platform statement is not used at all at the moment  
>> and is
>> not checked against the OS platform when installing a port. But it  
>> is a
>> mandatory field for a Portfile and can be used by maintainers to  
>> express
>> on which platforms this was tested or is supposed to work on.
>
> I didn't knew that, I thought if a platform is missing from
> "platforms" then the port can't be installed. Thanks for the
> information.
>
> Then it's of course a good idea to remove it.

It is not used, but I imagine the idea is that it will some day be  
used. Therefore, it is a good idea to make sure the platforms keyword  
is set correctly in your ports.



From ryandesign at macports.org  Sun Jan 25 16:07:08 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 25 Jan 2009 18:07:08 -0600
Subject: [45920] trunk/dports/_resources/port1.0/group/kde4-1.0.tcl
In-Reply-To: <20090125153428.5E56FD4E148@beta.macosforge.org>
References: <20090125153428.5E56FD4E148@beta.macosforge.org>
Message-ID: <B8987A7E-5925-452F-9BEA-7FFC6ECE34EA@macports.org>

On Jan 25, 2009, at 09:34, illogic-al at macports.org wrote:

> -variant with_docs description "Enables installation of  
> documentation" {
> +variant with_docs description "Install documentation" {

Could you call the variant just "docs" please? Our variant naming  
convention should be "foo" for a variant that adds "foo", and  
"no_foo" for a variant that removes "foo".




From illogical1 at gmail.com  Sun Jan 25 17:07:09 2009
From: illogical1 at gmail.com (O)
Date: Sun, 25 Jan 2009 20:07:09 -0500
Subject: [45920] trunk/dports/_resources/port1.0/group/kde4-1.0.tcl
In-Reply-To: <B8987A7E-5925-452F-9BEA-7FFC6ECE34EA@macports.org>
References: <20090125153428.5E56FD4E148@beta.macosforge.org>
	<B8987A7E-5925-452F-9BEA-7FFC6ECE34EA@macports.org>
Message-ID: <797cc39c0901251707n5e7ff02ma567760722c22f3c@mail.gmail.com>

On Sun, Jan 25, 2009 at 7:07 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Jan 25, 2009, at 09:34, illogic-al at macports.org wrote:
>
>> -variant with_docs description "Enables installation of documentation" {
>> +variant with_docs description "Install documentation" {
>
> Could you call the variant just "docs" please? Our variant naming convention
> should be "foo" for a variant that adds "foo", and "no_foo" for a variant
> that removes "foo".
Can do.

-- 

Robert Benchley  - "Drawing on my fine command of the English
language, I said nothing."

From perry at macports.org  Sun Jan 25 21:06:04 2009
From: perry at macports.org (Perry Lee)
Date: Sun, 25 Jan 2009 21:06:04 -0800
Subject: Announce: port_cutleaves
Message-ID: <31C19007-ADC2-40A1-8A8E-629BBF09E0A1@macports.org>

Hi All,

I've gone ahead and committed port_cutleaves to contrib (I talked to  
Bryan beforehand).

port_cutleaves is an interactive script that eases the uninstallation  
of "leaves" - ports that have no dependents. You can see an example  
run here: http://svn.macports.org/repository/macports/contrib/port_cutleaves/README

After a little more testing, I will be committing a Portfile to dports.

Feel free to enhance it or fix bugs - you don't need to ask me first :).

Perry

From raimue at macports.org  Mon Jan 26 01:51:54 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Mon, 26 Jan 2009 10:51:54 +0100
Subject: Announce: port_cutleaves
In-Reply-To: <31C19007-ADC2-40A1-8A8E-629BBF09E0A1@macports.org>
References: <31C19007-ADC2-40A1-8A8E-629BBF09E0A1@macports.org>
Message-ID: <497D87BA.8080101@macports.org>

Perry Lee wrote:
> port_cutleaves is an interactive script that eases the uninstallation  
> of "leaves" - ports that have no dependents. You can see an example  
> run here: http://svn.macports.org/repository/macports/contrib/port_cutleaves/README

Thanks Perry, that is really helpful to cleanup an installation.

Rainer

From raphael at ira.uka.de  Tue Jan 27 02:34:05 2009
From: raphael at ira.uka.de (Raphael Straub)
Date: Tue, 27 Jan 2009 11:34:05 +0100
Subject: Geomview port does not work with xorg-libs of MacPorts
In-Reply-To: <B3507656-888A-436F-B86F-B6F92A6B882F@macports.org>
References: <1DA3AB3A-18C8-46FF-8CC6-399B3084E895@ira.uka.de>
	<D1ABA5A7-9936-429C-BE59-F13D50445A5E@macports.org>
	<62DBB44E-6A0B-466E-99FF-5F9AFBE9F012@ira.uka.de>
	<B3507656-888A-436F-B86F-B6F92A6B882F@macports.org>
Message-ID: <B20F1EA4-5432-44B4-B863-CEE97A750BCD@ira.uka.de>

Jeremy Huddleston wrote:
> On Jan 22, 2009, at 11:30, Raphael Straub wrote:
>
>> Yes, some libraries in ${prefix}/lib are still linked against /usr/ 
>> X11/lib/*. For example, libXm.4.0.1.dylib (openmotif) and libXaw3d. 
>> 8.0.dylib (Xaw3d). In both cases a complete rebuild of these  
>> libraries does not help.
>
> Those ports have now been updated to link against the libs in  
> $prefix rather than $x11prefix

Thanks, Jeremy!

Now, I have a geomview version that uses only MacPorts' X11 libraries:

 > otool -L /opt/local/geomview/gvx
/client/libexec/geomview/gvx:
	/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/ 
libGL.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/libXm.4.dylib (compatibility version 5.0.0, current  
version 5.1.0)
	/opt/local/lib/libXp.6.dylib (compatibility version 9.0.0, current  
version 9.0.0)
	/opt/local/lib/libXft.2.dylib (compatibility version 4.0.0, current  
version 4.13.0)
	/opt/local/lib/libXrender.1.dylib (compatibility version 5.0.0,  
current version 5.0.0)
	/opt/local/lib/libfontconfig.1.dylib (compatibility version 5.0.0,  
current version 5.0.0)
	/opt/local/lib/libiconv.2.dylib (compatibility version 7.0.0, current  
version 7.0.0)
	/opt/local/lib/libexpat.1.dylib (compatibility version 7.0.0, current  
version 7.2.0)
	/opt/local/lib/libfreetype.6.dylib (compatibility version 10.0.0,  
current version 10.19.0)
	/opt/local/lib/libjpeg.62.dylib (compatibility version 63.0.0,  
current version 63.0.0)
	/opt/local/lib/libpng12.0.dylib (compatibility version 35.0.0,  
current version 35.0.0)
	/opt/local/lib/libXmu.6.dylib (compatibility version 9.0.0, current  
version 9.0.0)
	/opt/local/lib/libgeomview-1.9.4.dylib (compatibility version 0.0.0,  
current version 0.0.0)
	/opt/local/lib/libGL.1.dylib (compatibility version 1.2.0, current  
version 1.2.0)
	/opt/local/lib/libGLU.1.dylib (compatibility version 1.3.0, current  
version 1.3.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current  
version 1.2.3)
	/opt/local/lib/libXt.6.dylib (compatibility version 7.0.0, current  
version 7.0.0)
	/opt/local/lib/libSM.6.dylib (compatibility version 7.0.0, current  
version 7.0.0)
	/opt/local/lib/libICE.6.dylib (compatibility version 10.0.0, current  
version 10.0.0)
	/opt/local/lib/libXext.6.dylib (compatibility version 11.0.0, current  
version 11.0.0)
	/opt/local/lib/libX11.6.dylib (compatibility version 9.0.0, current  
version 9.0.0)
	/opt/local/lib/libXau.6.dylib (compatibility version 7.0.0, current  
version 7.0.0)
	/opt/local/lib/libXdmcp.6.dylib (compatibility version 7.0.0, current  
version 7.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current  
version 111.1.3)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current  
version 1.0.0)

But geomview still doesn't work. Starting geomview with the "-gdb"  
option gives the following error:

Warning: Widget must be a VendorShell.
Error: attempt to add non-widget child "dsm" to parent "gvx" which  
supports only widgets

This is a message from openmotif and it seems to be related to <http://trac.macports.org/ticket/18114 
 >. The Motif FAQ <http://www.faqs.org/faqs/motif-faq/part9/section-29.html 
 > says that this error comes from linking the libraries in the wrong  
order, but I don't see that this is the case here as libXm is the  
first library.

I linked geomview against the GL libraries provided by the mesa port,  
because they use libX11 from MacPorts and not /usr/X11/lib/ 
libX11.dylib like the GL libraries in /usr/X11. But I assume that mesa  
does not use hardware accelerated OpenGL as it does not use the OpenGL  
system framework. How can I use hardware accelerated OpenGL in X11  
applications?

Regards,
	Raphael
-- 
Raphael Straub                              E-Mail: raphael at ira.uka.de
Universit?t Karlsruhe                       Tel.  : +49 721 608-4383
Institut f?r Betriebs- und Dialogsysteme    Fax   : +49 721 608-8330
Am Fasanengarten 5, 76128 Karlsruhe         Geb. 50.34, Raum 127


From ryandesign at macports.org  Tue Jan 27 03:40:52 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 27 Jan 2009 05:40:52 -0600
Subject: PortGroup tickets in Trac
Message-ID: <B36A68C1-4142-44CB-A204-8D9D6F2C2AFB@macports.org>

Now that PortGroups aren't tied to MacPorts base releases and are  
stored in the dports tree, how should we categorize PortGroup tickets  
in Trac?

Should we duplicate the milestones and components that relate to  
ports, adding milestones "PortGroup Bugs", "PortGroup Enhancements",  
"PortGroup Requests" and "PortGroup Submissions", and a component  
"PortGroups"?

Or should we still file them under component "base"? That's what I  
did recently, and set the milestone to "MacPorts Future", though  
since PortGroups are now decoupled from base they should be fixed  
much quicker than "MacPorts Future" would suggest.


From jmr at macports.org  Tue Jan 27 07:29:07 2009
From: jmr at macports.org (Joshua Root)
Date: Wed, 28 Jan 2009 02:29:07 +1100
Subject: r45997 "Start using new kde4 portgroup."
Message-ID: <497F2843.4050403@macports.org>

Did you mean to commit a strigi version update in
<http://trac.macports.org/changeset/45997>?

- Josh

From illogical1 at gmail.com  Tue Jan 27 07:58:36 2009
From: illogical1 at gmail.com (O)
Date: Tue, 27 Jan 2009 10:58:36 -0500
Subject: r45997 "Start using new kde4 portgroup."
In-Reply-To: <497F2843.4050403@macports.org>
References: <497F2843.4050403@macports.org>
Message-ID: <797cc39c0901270758w6679b16dl4b957c6ad8a1d009@mail.gmail.com>

Yip.

On Tue, Jan 27, 2009 at 10:29 AM, Joshua Root <jmr at macports.org> wrote:
> Did you mean to commit a strigi version update in
> <http://trac.macports.org/changeset/45997>?
>
> - Josh
>

From ryandesign at macports.org  Tue Jan 27 10:02:45 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 27 Jan 2009 12:02:45 -0600
Subject: [46020] trunk/dports/_resources/port1.0/group/kde4-1.0.tcl
In-Reply-To: <20090127122952.440FAD81692@beta.macosforge.org>
References: <20090127122952.440FAD81692@beta.macosforge.org>
Message-ID: <D2CFE1D2-11AB-420A-8E0D-D49E0CB40CFC@macports.org>


On Jan 27, 2009, at 06:29, illogic-al at macports.org wrote:

> Revision: 46020
>           http://trac.macports.org/changeset/46020
> Author:   illogic-al at macports.org
> Date:     2009-01-27 04:29:50 -0800 (Tue, 27 Jan 2009)
> Log Message:
> -----------
> Let's build docs by default
>
> Modified Paths:
> --------------
>     trunk/dports/_resources/port1.0/group/kde4-1.0.tcl
>
> Modified: trunk/dports/_resources/port1.0/group/kde4-1.0.tcl
> ===================================================================
> --- trunk/dports/_resources/port1.0/group/kde4-1.0.tcl	2009-01-27  
> 11:52:14 UTC (rev 46019)
> +++ trunk/dports/_resources/port1.0/group/kde4-1.0.tcl	2009-01-27  
> 12:29:50 UTC (rev 46020)
> @@ -40,8 +40,11 @@
>  configure.compiler      gcc-4.2
>
>  configure.args-append   -DBUILD_SHARED_LIBS=ON \
> +                        -DBUILD_doc=OFF \
>                          -DKDE_DISTRIBUTION_TEXT="MacPorts\/Mac OS X"
>
> +default_variants        +docs
> +
>  variant docs description "Install documentation" {
>      depends_lib             port:doxygen
>      configure.args-append   -DBUILD_doc=ON

You should not use default variants in this way. How would a user  
turn off documentation if they did not want it? The user could "sudo  
port install foo -docs" but as soon as they need to upgrade foo, "- 
docs" will disappear (MacPorts never records negative variants) and  
the +docs variant will be selected again.

Either remove the docs variant and just make the documentation build  
always, or if there is value in letting the user remove the  
documentation, then make it a (non-default) no_docs variant that does  
so.




From blb at macports.org  Tue Jan 27 12:53:01 2009
From: blb at macports.org (Bryan Blackburn)
Date: Tue, 27 Jan 2009 13:53:01 -0700
Subject: PortGroup tickets in Trac
In-Reply-To: <B36A68C1-4142-44CB-A204-8D9D6F2C2AFB@macports.org>
References: <B36A68C1-4142-44CB-A204-8D9D6F2C2AFB@macports.org>
Message-ID: <20090127205301.GE965@ninagal.withay.com>

On Tue, Jan 27, 2009 at 05:40:52AM -0600, Ryan Schmidt said:
> Now that PortGroups aren't tied to MacPorts base releases and are stored 
> in the dports tree, how should we categorize PortGroup tickets in Trac?
>
> Should we duplicate the milestones and components that relate to ports, 
> adding milestones "PortGroup Bugs", "PortGroup Enhancements", "PortGroup 
> Requests" and "PortGroup Submissions", and a component "PortGroups"?
>
> Or should we still file them under component "base"? That's what I did 
> recently, and set the milestone to "MacPorts Future", though since 
> PortGroups are now decoupled from base they should be fixed much quicker 
> than "MacPorts Future" would suggest.

I'd rather simply see them with ports, since they are just include files for
ports.

Bryan


From illogical1 at gmail.com  Tue Jan 27 13:27:09 2009
From: illogical1 at gmail.com (Orville Bennett)
Date: Tue, 27 Jan 2009 16:27:09 -0500
Subject: [46020] trunk/dports/_resources/port1.0/group/kde4-1.0.tcl
In-Reply-To: <D2CFE1D2-11AB-420A-8E0D-D49E0CB40CFC@macports.org>
References: <20090127122952.440FAD81692@beta.macosforge.org>
	<D2CFE1D2-11AB-420A-8E0D-D49E0CB40CFC@macports.org>
Message-ID: <C5D702E4-9ECD-4F96-9A21-25F02FC96F79@gmail.com>


On Jan 27, 2009, at 1:02 PM, Ryan Schmidt wrote:

>
> On Jan 27, 2009, at 06:29, illogic-al at macports.org wrote:
>
>> Revision: 46020
>>          http://trac.macports.org/changeset/46020
>> Author:   illogic-al at macports.org
>> Date:     2009-01-27 04:29:50 -0800 (Tue, 27 Jan 2009)
>> Log Message:
>> -----------
>> Let's build docs by default
>>
>> Modified Paths:
>> --------------
>>    trunk/dports/_resources/port1.0/group/kde4-1.0.tcl
>>
>> Modified: trunk/dports/_resources/port1.0/group/kde4-1.0.tcl
>> ===================================================================
>> --- trunk/dports/_resources/port1.0/group/kde4-1.0.tcl	2009-01-27  
>> 11:52:14 UTC (rev 46019)
>> +++ trunk/dports/_resources/port1.0/group/kde4-1.0.tcl	2009-01-27  
>> 12:29:50 UTC (rev 46020)
>> @@ -40,8 +40,11 @@
>> configure.compiler      gcc-4.2
>>
>> configure.args-append   -DBUILD_SHARED_LIBS=ON \
>> +                        -DBUILD_doc=OFF \
>>                         -DKDE_DISTRIBUTION_TEXT="MacPorts\/Mac OS X"
>>
>> +default_variants        +docs
>> +
>> variant docs description "Install documentation" {
>>     depends_lib             port:doxygen
>>     configure.args-append   -DBUILD_doc=ON
>
> You should not use default variants in this way. How would a user  
> turn off documentation if they did not want it? The user could "sudo  
> port install foo -docs" but as soon as they need to upgrade foo, "- 
> docs" will disappear (MacPorts never records negative variants) and  
> the +docs variant will be selected again.
>
> Either remove the docs variant and just make the documentation build  
> always, or if there is value in letting the user remove the  
> documentation, then make it a (non-default) no_docs variant that  
> does so.
Hmm. OK. I've changed it just now. Need to modify the rest of my  
portfiles as well then.

From jeremyhu at macports.org  Tue Jan 27 13:28:35 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Tue, 27 Jan 2009 13:28:35 -0800
Subject: Geomview port does not work with xorg-libs of MacPorts
In-Reply-To: <B20F1EA4-5432-44B4-B863-CEE97A750BCD@ira.uka.de>
References: <1DA3AB3A-18C8-46FF-8CC6-399B3084E895@ira.uka.de>
	<D1ABA5A7-9936-429C-BE59-F13D50445A5E@macports.org>
	<62DBB44E-6A0B-466E-99FF-5F9AFBE9F012@ira.uka.de>
	<B3507656-888A-436F-B86F-B6F92A6B882F@macports.org>
	<B20F1EA4-5432-44B4-B863-CEE97A750BCD@ira.uka.de>
Message-ID: <1F308B15-CD53-464F-A597-D7B8570C9607@macports.org>


On Jan 27, 2009, at 02:34, Raphael Straub wrote:

> Jeremy Huddleston wrote:
>> On Jan 22, 2009, at 11:30, Raphael Straub wrote:
>>
>>> Yes, some libraries in ${prefix}/lib are still linked against /usr/ 
>>> X11/lib/*. For example, libXm.4.0.1.dylib (openmotif) and libXaw3d. 
>>> 8.0.dylib (Xaw3d). In both cases a complete rebuild of these  
>>> libraries does not help.
>>
>> Those ports have now been updated to link against the libs in  
>> $prefix rather than $x11prefix
>
> Thanks, Jeremy!
>
> I linked geomview against the GL libraries provided by the mesa  
> port, because they use libX11 from MacPorts and not /usr/X11/lib/ 
> libX11.dylib like the GL libraries in /usr/X11. But I assume that  
> mesa does not use hardware accelerated OpenGL as it does not use the  
> OpenGL system framework. How can I use hardware accelerated OpenGL  
> in X11 applications?

We're in the process of creating a new HW-accelerated (via  
OpenGL.framework) glx libGL.  It was just released today actually in  
XQuartz-2.4.0_alpha2.  It is not yet in MacPorts.

This brings up an interesting question about how to handle libGL in  
MacPorts...

mesa provides both libGL and libGLU.

Option 1)  Change this to TWO ports: mesa-GLU and mesa-GL... then  
introduce a new port for the HW Accelerated libGL.
Option 2)  Have the mesa port default to installing this new HW  
accelerated libGL with a variant to install the SW libGL.

Thoughts?



From ryandesign at macports.org  Tue Jan 27 20:12:01 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 27 Jan 2009 22:12:01 -0600
Subject: [46046] trunk/dports
In-Reply-To: <20090127221137.3B570D8C782@beta.macosforge.org>
References: <20090127221137.3B570D8C782@beta.macosforge.org>
Message-ID: <E79C453F-55E2-4286-89F7-1B09659828BA@macports.org>


On Jan 27, 2009, at 16:11, illogic-al at macports.org wrote:

> Append depends_lib because the one in the kde4 portgroup will get  
> lost otherwise.
> We should have depends_lib.pre_args :-)

No I don't think so.

But maybe we should be getting in the habit of always using  
"depends_foo-append" instead of "depends_foo".



From ryandesign at macports.org  Tue Jan 27 20:12:27 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 27 Jan 2009 22:12:27 -0600
Subject: [46043] trunk/dports
In-Reply-To: <20090127212434.B08B6D8BDBC@beta.macosforge.org>
References: <20090127212434.B08B6D8BDBC@beta.macosforge.org>
Message-ID: <F4A5B40E-4F26-4A26-A3A0-29551675D7F4@macports.org>


On Jan 27, 2009, at 15:24, illogic-al at macports.org wrote:

> -default_variants        +docs
> -
> -variant docs description "Install documentation" {
> -    depends_lib             port:doxygen
> -    configure.args-append   -DBUILD_doc=ON
> +variant no_docs description "Does not install documentation" {
> +    depends_lib-delete      port:doxygen
> +    configure.args-delete   -DBUILD_doc=ON
> +    configure.args-append   -DBUILD_doc=OFF
>  }

Remember, variant descriptions should read like radio buttons. So  
"Don't install documentation" or "Omit documentation" would be  
preferable to "Does not install documentation".


From alakazam at macports.org  Wed Jan 28 01:48:58 2009
From: alakazam at macports.org (Olivier Le Floch)
Date: Wed, 28 Jan 2009 10:48:58 +0100
Subject: [46046] trunk/dports
In-Reply-To: <E79C453F-55E2-4286-89F7-1B09659828BA@macports.org>
References: <20090127221137.3B570D8C782@beta.macosforge.org>
	<E79C453F-55E2-4286-89F7-1B09659828BA@macports.org>
Message-ID: <63F2898F-9C14-4DF8-B94D-CF01AA06FA6F@macports.org>

On 28 janv. 09, at 05:12, Ryan Schmidt wrote:

> On Jan 27, 2009, at 16:11, illogic-al at macports.org wrote:
>
>> Append depends_lib because the one in the kde4 portgroup will get  
>> lost otherwise.
>> We should have depends_lib.pre_args :-)
>
> No I don't think so.
>
> But maybe we should be getting in the habit of always using  
> "depends_foo-append" instead of "depends_foo".

Would it make sense in that case to make depends_foo do depends_foo- 
append, by default (and add depends_foo-reset for variants that might  
need to supersede *all* dependencies instead of removing specific ones  
with depends_foo-delete) ?

From illogical1 at gmail.com  Wed Jan 28 05:59:19 2009
From: illogical1 at gmail.com (O)
Date: Wed, 28 Jan 2009 08:59:19 -0500
Subject: Updating apple-gcc42
Message-ID: <797cc39c0901280559w2e5a719cia30ae462c0190663@mail.gmail.com>

Hi, I'd really like to update the apple-gcc42 port so that users can
compile kde software on OS 10.4.
The reason I want to do this are all laid out in
https://trac.macports.org/ticket/16666 so please read that before
asking why here.

In short: kde won't work without an up to date c++ compiler.
The current apple-gcc42 doesn't compile c++, even if it did, it has
bugs so it still won't work.
Bumping the rev of that port is not enough to get it to work.

Potential issues. The port attached to the ticket installs to /usr, not $prefix.

From jm at poure.com  Wed Jan 28 08:04:40 2009
From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=)
Date: Wed, 28 Jan 2009 17:04:40 +0100
Subject: [MacPorts] #18247: gavl 1.1.0
In-Reply-To: <057.9dc00c9269a8d6ea2dc028b0d8e1624d@macports.org>
References: <048.19a5a1b92b9f8ab0f7b9da241372d7c4@macports.org>
	<057.9dc00c9269a8d6ea2dc028b0d8e1624d@macports.org>
Message-ID: <1233158680.29649.5.camel@debian>

On Wed, 2009-01-28 at 15:48 +0000, MacPorts wrote:
>  I gave it a brief look. The master_sites should not be a complete
> URL. The
>  "gavl-1.1.0.tar.gz" part should be removed from it. Macports will
> look for
>  that by default. See the dist_name property in the guide.

Thanks. I will follow these guidelines in the next submissions. There is
already frei0r-plugins uploaded, but in the next packages :)


From jm at poure.com  Wed Jan 28 08:41:31 2009
From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=)
Date: Wed, 28 Jan 2009 17:41:31 +0100
Subject: How to specify dependencies with variants
Message-ID: <1233160891.29649.8.camel@debian>

Hello,

I am writing a port for MLT. MLT needs FFmpeg with all variants. How to
write it in the port. I wrote this, but obviously it is not working:

depends_lib         port:atk \
                    port:gavl \
                    port:opencv \
                    port:ffmpeg +a52 +avfilter +extvorbis +faac +faad
+gpl +lame +postproc +theora +x264 +xvid \
                    port:kdelibs4 \
                    port:kdelibs4-devel \
                    port:libquicktime \
                    port:libsamplerate \
                    port:pkgconfig \
                    port:sox \

Kind regards,
Jean-Michel


From bob.spamnot at gmail.com  Wed Jan 28 08:42:29 2009
From: bob.spamnot at gmail.com (Bob)
Date: Wed, 28 Jan 2009 09:42:29 -0700
Subject: gv error
Message-ID: <760710620901280842p7eb301aocacd43118447aa10@mail.gmail.com>

I just rebuilt my Macports (gnome-term, gnu emacs X11 version, and gv are
the things I use most from Macports) and get the following when I try to run
gv 3.6.6:

gv idl.ps
Warning: No type converter registered for 'String' to
'InitialResourcesPersistent' conversion.
Warning: No type converter registered for 'translations' to
'InitialResourcesPersistent' conversion.
Warning: No type converter registered for 'String' to 'Translations'
conversion.
Warning: No type converter registered for 'TranslationTable' to
'Translations' conversion.
Warning: No type converter registered for 'TranslationTable' to
'Translations' conversion.
Warning: No type converter registered for 'TranslationTable' to 'Color'
conversion.
Warning: No type converter registered for 'String' to
'InitialResourcesPersistent' conversion.
Warning: No type converter registered for 'TranslationTable' to
'InitialResourcesPersistent' conversion.
Warning: No type converter registered for 'translations' to 'Meta'
conversion.
Bus error

And it crashes there.  gs worked for me previously (I probably updated my
Macports a month ago and that version worked fine).  Also, if I view the
file directly with gs it works.

Does anyone have any ideas?

Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090128/436f3659/attachment.html>

From jm at poure.com  Wed Jan 28 09:20:40 2009
From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=)
Date: Wed, 28 Jan 2009 18:20:40 +0100
Subject: error: /opt/local/include/X11/extensions/render.h is being used by
	the active render port.
Message-ID: <1233163240.7318.3.camel@debian>

sudo port -v install ffmpeg-devel
--->  Activating xorg-renderproto @0.9.3_0
Error: Target org.macports.activate returned: Image
error: /opt/local/include/X11/extensions/render.h is being used by the
active render port.  Please deactivate this port first, or use the -f
flag to force the activation.
Warning: the following items did not execute (for xorg-renderproto):
org.macports.activate
Error: The following dependencies failed to build: libsdl xorg-libXrandr
xorg-renderproto
Error: Status 1 encountered during processing.

df -lh
Filesystem     Size   Used  Avail Capacity  Mounted on
/dev/disk0s2   233G   193G    39G    83%    /
/dev/disk1s1   501M   501M   640K   100%    /Volumes/NO NAME
/dev/disk2s2    60M    55M   4.8M    92%    /Volumes/iSkysoft Video
Converter

Pardon my ignorance, but what should I do to build ffmpeg-devel? I am
completely new to MacPorts and thank you in advance.

Kind regards,
Jean-Michel


From devans at macports.org  Wed Jan 28 09:37:02 2009
From: devans at macports.org (David Evans)
Date: Wed, 28 Jan 2009 09:37:02 -0800
Subject: error: /opt/local/include/X11/extensions/render.h is being used
	by	the active render port.
In-Reply-To: <1233163240.7318.3.camel@debian>
References: <1233163240.7318.3.camel@debian>
Message-ID: <498097BE.1030605@macports.org>

Jean-Michel Pour? wrote:
> sudo port -v install ffmpeg-devel
> --->  Activating xorg-renderproto @0.9.3_0
> Error: Target org.macports.activate returned: Image
> error: /opt/local/include/X11/extensions/render.h is being used by the
> active render port.  Please deactivate this port first, or use the -f
> flag to force the activation.
> Warning: the following items did not execute (for xorg-renderproto):
> org.macports.activate
> Error: The following dependencies failed to build: libsdl xorg-libXrandr
> xorg-renderproto
> Error: Status 1 encountered during processing.
>
> df -lh
> Filesystem     Size   Used  Avail Capacity  Mounted on
> /dev/disk0s2   233G   193G    39G    83%    /
> /dev/disk1s1   501M   501M   640K   100%    /Volumes/NO NAME
> /dev/disk2s2    60M    55M   4.8M    92%    /Volumes/iSkysoft Video
> Converter
>
> Pardon my ignorance, but what should I do to build ffmpeg-devel? I am
> completely new to MacPorts and thank you in advance.
>
> Kind regards,
> Jean-Michel
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>
>   
Do as it says and deactivate port render

sudo port deactivate render

then try again.

You should also make sure that you have updated any outdated xorg-* 
ports as there have been a lot of changes in dependencies here
recently.

If you have port ffmpeg installed and activate you will want to 
deactivate that too as ffmpeg and ffmpeg-devel will want to install the 
same files so only one can be active at the same time.

To see what ffmpeg you have installed

sudo port installed ffmpeg




From jmr at macports.org  Wed Jan 28 09:45:27 2009
From: jmr at macports.org (Joshua Root)
Date: Thu, 29 Jan 2009 04:45:27 +1100
Subject: error: /opt/local/include/X11/extensions/render.h is being used
	by	the active render port.
In-Reply-To: <1233163240.7318.3.camel@debian>
References: <1233163240.7318.3.camel@debian>
Message-ID: <498099B7.5040103@macports.org>

Jean-Michel Pour? wrote:
> sudo port -v install ffmpeg-devel
> --->  Activating xorg-renderproto @0.9.3_0
> Error: Target org.macports.activate returned: Image
> error: /opt/local/include/X11/extensions/render.h is being used by the
> active render port.  Please deactivate this port first, or use the -f
> flag to force the activation.
> Warning: the following items did not execute (for xorg-renderproto):
> org.macports.activate
> Error: The following dependencies failed to build: libsdl xorg-libXrandr
> xorg-renderproto
> Error: Status 1 encountered during processing.
> 
> df -lh
> Filesystem     Size   Used  Avail Capacity  Mounted on
> /dev/disk0s2   233G   193G    39G    83%    /
> /dev/disk1s1   501M   501M   640K   100%    /Volumes/NO NAME
> /dev/disk2s2    60M    55M   4.8M    92%    /Volumes/iSkysoft Video
> Converter
> 
> Pardon my ignorance, but what should I do to build ffmpeg-devel? I am
> completely new to MacPorts and thank you in advance.

The render port was removed a while ago, and for quite a while before
that it installed no files because it has been replaced by
xorg-renderproto. Anyway, render is no longer needed, so to get rid of
it just run `sudo port -f uninstall render`.

- Josh

From jmr at macports.org  Wed Jan 28 10:27:47 2009
From: jmr at macports.org (Joshua Root)
Date: Thu, 29 Jan 2009 05:27:47 +1100
Subject: How to specify dependencies with variants
In-Reply-To: <1233160891.29649.8.camel@debian>
References: <1233160891.29649.8.camel@debian>
Message-ID: <4980A3A3.7000000@macports.org>

Jean-Michel Pour? wrote:
> Hello,
> 
> I am writing a port for MLT. MLT needs FFmpeg with all variants. How to
> write it in the port. I wrote this, but obviously it is not working:
> 
> depends_lib         port:atk \
>                     port:gavl \
>                     port:opencv \
>                     port:ffmpeg +a52 +avfilter +extvorbis +faac +faad
> +gpl +lame +postproc +theora +x264 +xvid \
>                     port:kdelibs4 \
>                     port:kdelibs4-devel \
>                     port:libquicktime \
>                     port:libsamplerate \
>                     port:pkgconfig \
>                     port:sox \

You can't. That's <http://trac.macports.org/ticket/126>.

- Josh

From blb at macports.org  Wed Jan 28 11:27:18 2009
From: blb at macports.org (Bryan Blackburn)
Date: Wed, 28 Jan 2009 12:27:18 -0700
Subject: [46046] trunk/dports
In-Reply-To: <63F2898F-9C14-4DF8-B94D-CF01AA06FA6F@macports.org>
References: <20090127221137.3B570D8C782@beta.macosforge.org>
	<E79C453F-55E2-4286-89F7-1B09659828BA@macports.org>
	<63F2898F-9C14-4DF8-B94D-CF01AA06FA6F@macports.org>
Message-ID: <20090128192718.GD747@ninagal.withay.com>

On Wed, Jan 28, 2009 at 10:48:58AM +0100, Olivier Le Floch said:
> On 28 janv. 09, at 05:12, Ryan Schmidt wrote:
>
>> On Jan 27, 2009, at 16:11, illogic-al at macports.org wrote:
>>
>>> Append depends_lib because the one in the kde4 portgroup will get  
>>> lost otherwise.
>>> We should have depends_lib.pre_args :-)
>>
>> No I don't think so.
>>
>> But maybe we should be getting in the habit of always using  
>> "depends_foo-append" instead of "depends_foo".
>
> Would it make sense in that case to make depends_foo do depends_foo- 
> append, by default (and add depends_foo-reset for variants that might  
> need to supersede *all* dependencies instead of removing specific ones  
> with depends_foo-delete) ?

Seeing as how the only place that's going to be setting depends_foo prior to
a Portfile would be a port group, that makes sense.  Considering their
functionality, would a Portfile ever need to override a group's
dependencies?

Bryan


From dluke at geeklair.net  Wed Jan 28 11:33:35 2009
From: dluke at geeklair.net (Daniel J. Luke)
Date: Wed, 28 Jan 2009 14:33:35 -0500
Subject: [46046] trunk/dports
In-Reply-To: <20090128192718.GD747@ninagal.withay.com>
References: <20090127221137.3B570D8C782@beta.macosforge.org>
	<E79C453F-55E2-4286-89F7-1B09659828BA@macports.org>
	<63F2898F-9C14-4DF8-B94D-CF01AA06FA6F@macports.org>
	<20090128192718.GD747@ninagal.withay.com>
Message-ID: <259718FF-8BEB-43FB-85C5-EB47ADA6A49E@geeklair.net>

On Jan 28, 2009, at 2:27 PM, Bryan Blackburn wrote:
>> Would it make sense in that case to make depends_foo do depends_foo-
>> append, by default (and add depends_foo-reset for variants that might
>> need to supersede *all* dependencies instead of removing specific  
>> ones
>> with depends_foo-delete) ?
>
> Seeing as how the only place that's going to be setting depends_foo  
> prior to
> a Portfile would be a port group, that makes sense.  Considering their
> functionality, would a Portfile ever need to override a group's
> dependencies?


I've done it before (for a portfile I don't think I ever submitted,  
though).

I find the current syntax clear, and would rather just see the  
documentation and examples updated to recommend using the -append  
versions.

--
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/20090128/7580c5d5/attachment-0001.bin>

From bob.spamnot at gmail.com  Wed Jan 28 11:53:47 2009
From: bob.spamnot at gmail.com (Bob)
Date: Wed, 28 Jan 2009 12:53:47 -0700
Subject: gv error
In-Reply-To: <760710620901280842p7eb301aocacd43118447aa10@mail.gmail.com>
References: <760710620901280842p7eb301aocacd43118447aa10@mail.gmail.com>
Message-ID: <760710620901281153h26466332m28361bd09b8c1e0e@mail.gmail.com>

Looking at the crash report it would seem there is a problem with all the
new X11 code in Macports.  Here is the report, hope it helps:

Process:         gv [69188]
Path:            /opt/local/bin/gv
Identifier:      gv
Version:         ??? (???)
Code Type:       X86 (Native)
Parent Process:  bash [85690]

Date/Time:       2009-01-28 12:49:55.615 -0700
OS Version:      Mac OS X 10.5.6 (9G55)
Report Version:  6

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000004
Crashed Thread:  0

Thread 0 Crashed:
0   libXt.6.dylib                     0x000de776
XtWidgetToApplicationContext + 52
1   libXt.6.dylib                     0x000d7392 _XtConvert + 29
2   libXt.6.dylib                     0x000f0444 GetResources + 2972
3   libXt.6.dylib                     0x000f0e45 _XtGetResources + 367
4   libXt.6.dylib                     0x000dc9ce xtCreate + 352
5   libXt.6.dylib                     0x000dcd82 _XtAppCreateShell + 221
6   libXt.6.dylib                     0x000dcec3 XtAppCreateShell + 126
7   gv                                0x0001907e main + 2990
8   gv                                0x00001a26 start + 54

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x00000000  ebx: 0x000d7380  ecx: 0xbfffe7ac  edx: 0x0000001b
  edi: 0x00000008  esi: 0x0060c790  ebp: 0xbfffd688  esp: 0xbfffd670
   ss: 0x0000001f  efl: 0x00010202  eip: 0x000de776   cs: 0x00000017
   ds: 0x0000001f   es: 0x0000001f   fs: 0x00000000   gs: 0x00000037
  cr2: 0x00000004

Binary Images:
    0x1000 -    0x43fef +gv ??? (???) <4ee153ac99434245f126f44fdb0b0145>
/opt/local/bin/gv
   0x63000 -    0x63ffc +libXinerama.1.dylib ??? (???)
<bcf00f1228ea980a495e49623315db8a> /usr/X11/lib/libXinerama.1.dylib
   0x67000 -    0x96fef +libXaw3d.8.dylib ??? (???)
<91bbd27951482bcc986651f6abb5b5b2> /opt/local/lib/libXaw3d.8.dylib
   0xaf000 -    0xb9fe3 +libXpm.4.dylib ??? (???)
<231cbc796197209086e8606850892311> /usr/X11/lib/libXpm.4.dylib
   0xbe000 -    0xccfe7 +libXmu.6.dylib ??? (???)
<792ed72b0f9b77da27dcb2b1603e15ba> /usr/X11/lib/libXmu.6.dylib
   0xd4000 -   0x10cff8 +libXt.6.dylib ??? (???)
<ebe4afb62044a73d6478ce4e287fa033> /usr/X11/lib/libXt.6.dylib
  0x11f000 -   0x127ffe +libXext.6.dylib ??? (???)
<92f1505af0a4fc57094668a5b1524acc> /usr/X11/lib/libXext.6.dylib
  0x12d000 -   0x131ffc +libSM.6.dylib ??? (???)
<641c0d32730dd6038452d624a0541b77> /usr/X11/lib/libSM.6.dylib
  0x136000 -   0x144fff +libICE.6.dylib ??? (???)
<f920e44cca0647ce7e5fa8079a3336b2> /usr/X11/lib/libICE.6.dylib
  0x14c000 -   0x211fff +libX11.6.dylib ??? (???)
<0968e054e405d6539ce3d7fb6857999e> /usr/X11/lib/libX11.6.dylib
  0x231000 -   0x241ffd +libz.1.dylib ??? (???)
<2989882d55fd828d3f37c0c133c236d8> /opt/local/lib/libz.1.dylib
  0x246000 -   0x254fff +libbz2.1.0.dylib ??? (???)
<3d5cbe27e28db7e5e0512d3f05c65f98> /opt/local/lib/libbz2.1.0.dylib
  0x259000 -   0x259ffe +libXau.6.dylib ??? (???)
<ca0ad4845daf9d6c1d965645fa33b4b6> /usr/X11/lib/libXau.6.dylib
  0x25d000 -   0x25ffef +libXdmcp.6.dylib ??? (???)
<8c515dab0a08f9bfbdad8d197c507599> /usr/X11/lib/libXdmcp.6.dylib
  0x263000 -   0x273fe7 +libXmu.6.dylib ??? (???)
<24a2f9ebac150e4bed34c0d32f7d0066> /opt/local/lib/libXmu.6.dylib
  0x27b000 -   0x2bbff8 +libXt.6.dylib ??? (???)
<995f9ba8ac6aeafbc3b7ba67242e84b5> /opt/local/lib/libXt.6.dylib
  0x2ce000 -   0x2d3ff4 +libSM.6.dylib ??? (???)
<960dfa2ff23a3cef3c3de4e1d8e86e9f> /opt/local/lib/libSM.6.dylib
  0x2d8000 -   0x2e8ff7 +libICE.6.dylib ??? (???)
<774a29f97b38e2bb5d16490d9d7128e8> /opt/local/lib/libICE.6.dylib
  0x2f0000 -   0x2faff6 +libXext.6.dylib ??? (???)
<baf9d677e443af1aefc6a4a184f8930e> /opt/local/lib/libXext.6.dylib
  0x300000 -   0x3d7fe7 +libX11.6.dylib ??? (???)
<b7c3f695371c53e34c97f3c082c0d834> /opt/local/lib/libX11.6.dylib
  0x3f7000 -   0x403fe3 +libXpm.4.dylib ??? (???)
<9303e50c2cbd0d9c918fe78358849c91> /opt/local/lib/libXpm.4.dylib
  0x408000 -   0x40cff3 +libXp.6.dylib ??? (???)
<0bbd95d97cb82fd0060a1d2b4a17a8d1> /opt/local/lib/libXp.6.dylib
  0x411000 -   0x411ffe +libXau.6.dylib ??? (???)
<52c10d89cc1019147f661080cf5e0222> /opt/local/lib/libXau.6.dylib
  0x415000 -   0x417fef +libXdmcp.6.dylib ??? (???)
<fe8a3aeedc67bb89d9c3f4f4f173ff44> /opt/local/lib/libXdmcp.6.dylib
  0x41b000 -   0x422ff3 +libintl.8.dylib ??? (???)
<8e4dda78b0312c1c9b3f9e7f5753afa9> /opt/local/lib/libintl.8.dylib
  0x427000 -   0x51eff0 +libiconv.2.dylib ??? (???)
<9495682248f36bb46d4a4d40e187ecf0> /opt/local/lib/libiconv.2.dylib
0x8fe00000 - 0x8fe2db43  dyld 97.1 (???) <100d362e03410f181a34e04e94189ae5>
/usr/lib/dyld
0x908a2000 - 0x90982fff  libobjc.A.dylib ??? (???)
<7b92613fdf804fd9a0a3733a0674c30b> /usr/lib/libobjc.A.dylib
0x91cc7000 - 0x91dfafff  com.apple.CoreFoundation 6.5.5 (476.17)
<4a70c8dbb582118e31412c53dc1f407f>
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x92323000 - 0x92380ffb  libstdc++.6.dylib ??? (???)
<6106b1f2b0b303b06ae476253dbb5f3f> /usr/lib/libstdc++.6.dylib
0x9249c000 - 0x925d4ff7  libicucore.A.dylib ??? (???)
<18098dcf431603fe47ee027a60006c85> /usr/lib/libicucore.A.dylib
0x948a8000 - 0x948acfff  libmathCommon.A.dylib ??? (???)
/usr/lib/system/libmathCommon.A.dylib
0x9492f000 - 0x9495afe7  libauto.dylib ??? (???)
<2072d673706bbe463ed2426af57a28d7> /usr/lib/libauto.dylib
0x954fe000 - 0x95665ff3  libSystem.B.dylib ??? (???)
<d68880dfb1f8becdbdac6928db1510fb> /usr/lib/libSystem.B.dylib
0x9651b000 - 0x96522fe9  libgcc_s.1.dylib ??? (???)
<28a7cbc3a5ca2982d124668306f422d9> /usr/lib/libgcc_s.1.dylib
0xfffe8000 - 0xfffebfff  libobjc.A.dylib ??? (???) /usr/lib/libobjc.A.dylib
0xffff0000 - 0xffff1780  libSystem.B.dylib ??? (???)
/usr/lib/libSystem.B.dylib



On Wed, Jan 28, 2009 at 9:42 AM, Bob <bob.spamnot at gmail.com> wrote:

> I just rebuilt my Macports (gnome-term, gnu emacs X11 version, and gv are
> the things I use most from Macports) and get the following when I try to run
> gv 3.6.6:
>
> gv idl.ps
> Warning: No type converter registered for 'String' to
> 'InitialResourcesPersistent' conversion.
> Warning: No type converter registered for 'translations' to
> 'InitialResourcesPersistent' conversion.
> Warning: No type converter registered for 'String' to 'Translations'
> conversion.
> Warning: No type converter registered for 'TranslationTable' to
> 'Translations' conversion.
> Warning: No type converter registered for 'TranslationTable' to
> 'Translations' conversion.
> Warning: No type converter registered for 'TranslationTable' to 'Color'
> conversion.
> Warning: No type converter registered for 'String' to
> 'InitialResourcesPersistent' conversion.
> Warning: No type converter registered for 'TranslationTable' to
> 'InitialResourcesPersistent' conversion.
> Warning: No type converter registered for 'translations' to 'Meta'
> conversion.
> Bus error
>
> And it crashes there.  gs worked for me previously (I probably updated my
> Macports a month ago and that version worked fine).  Also, if I view the
> file directly with gs it works.
>
> Does anyone have any ideas?
>
> Bob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090128/cfabf0bb/attachment.html>

From jmr at macports.org  Wed Jan 28 11:58:30 2009
From: jmr at macports.org (Joshua Root)
Date: Thu, 29 Jan 2009 06:58:30 +1100
Subject: gv error
In-Reply-To: <760710620901281153h26466332m28361bd09b8c1e0e@mail.gmail.com>
References: <760710620901280842p7eb301aocacd43118447aa10@mail.gmail.com>
	<760710620901281153h26466332m28361bd09b8c1e0e@mail.gmail.com>
Message-ID: <4980B8E6.6050607@macports.org>

Bob wrote:
> Looking at the crash report it would seem there is a problem with all
> the new X11 code in Macports.

More the opposite, sort of. The library where the crash happened is
/usr/X11/lib/libXt.6.dylib. It should be using /opt/local/lib/libXt.6.dylib.

- Josh

From ryandesign at macports.org  Wed Jan 28 12:04:46 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 28 Jan 2009 14:04:46 -0600
Subject: [MacPorts] #18128: Enhancement to distinguish between Apple and
	non-Apple compilers
In-Reply-To: <824F0447-51A8-4B14-B6E9-A321C72A565B@alum.mit.edu>
References: <052.5e4ef2cfd5d0707eac613278b4ed3f82@macports.org>
	<4976F99F.3070907@macports.org>
	<9C27815E-EFBB-499C-99F8-548410789898@macports.org>
	<1D60DA63-627C-4B31-A04E-F43FF5185C6A@alum.mit.edu>
	<ECCF61DF-DFA2-4AD7-9E36-E3472FDCB161@macports.org>
	<824F0447-51A8-4B14-B6E9-A321C72A565B@alum.mit.edu>
Message-ID: <82493139-CC5B-44FF-AEE5-C90ACB2CE197@macports.org>

On Jan 22, 2009, at 08:11, Michael Dickens wrote:

> On Jan 22, 2009, at 4:42 AM, Ryan Schmidt wrote:
>
>> Ports can already indicate what compiler they want by setting $ 
>> {configure.compiler}. For example, the default value for this  
>> variable on Leopard is "gcc-4.0", meaning the GCC 4.0 provided by  
>> Apple with Xcode. If a port author wanted, they could change this  
>> variable to "gcc-4.2", meaning the GCC 4.2 provided by Apple with  
>> Xcode, or to "macports-gcc-4.3", meaning the GCC 4.3 provided by  
>> MacPorts in the gcc43 port. There are options for every other GCC  
>> compiler that's available.
>
> I had no idea that one could specify the compiler suite in a  
> Portfile; the best I could find was using ${configure.cc}  
> specifically to 'reinplace' a given string to get the correct CC  
> for a port.  I'm sure this feature is documented somewhere, but I  
> couldn't find it (I did look using Google and MacPorts searches  
> before posting this suggestion, really) ... now that you've told me  
> what to look for, I finally found it parsing through < http:// 
> guide.macports.org/#reference.phases.configure >.  Thanks for  
> pointing this feature out to me.

Setting configure.compiler in a portfile causes configure.cc and a  
whole bunch of other variables to be automatically set to  
corresponding values. MacPorts sets CC in the configure phase to be  
the value of configure.cc, and similarly for other variables. If a  
particular software does not observe the CC environment variable  
during the configure phase, then that port must do something with  
configure.cc (for example reinplace it into a Makefile, or pass it as  
CC in build.env) to ensure that it gets used.


> My suggestion is to make 2 different compiler suites available for  
> Ports to use simultaneously: one of Apple's, and one of a non-Apple  
> (via MacPorts or some other means).  I can't imagine a need for  
> more than 2 different compiler suites, but I can imagine using the  
> possibility of using 2 different compiler suites in a given Port:  
> one for general compiling (e.g., macports-gcc-4.3 to get #pragma or  
> similar options available to 4.3 or newer) and another for Apple- 
> specific compiling (for linking and such).  I will admit to never  
> having tried this out directly, just imagining it [though, it is  
> probable that some of the ports I mentioned where we reinplace'd  
> 'gcc' with ${compiler.cc}, 2 different CC compilers were  
> inadvertently used].

In those ports where you see reinplaces of ${configure.cc} being  
added, the situation before that change was likely that the software  
was building with "cc" or "gcc" instead. On unmodified Macs, that  
should be the same as ${configure.cc}. But some users have used the  
program gcc_select to make a different compiler the default on their  
Mac, and this can break some software. That is why MacPorts was  
changed to always use the absolute path to the compiler that we know  
works, via CC=${configure.cc} etc.


>> As far as I know this has been sufficient to cover the needs of  
>> all ports so far. So I have yet to understand what your proposed  
>> changes would improve.
>
> If y'all believe that there will -never- (with reasonable  
> probability) be a time when it would be beneficial to have 2  
> different compiler suites (one for Apple and another for non-Apple)  
> available to use simultaneously, then there is no need for my  
> suggestion given what you've written above about selecting a given  
> compiler suite.
>
> Thanks for the info and the quick responses! - MLD

I don't know of a port that currently needs to build some parts with  
an Apple compiler and other parts with another compiler. If such a  
case should arise, then the port can arrange for that to happen. For  
example, the port would not set configure.compiler (thus, Apple's  
compiler will be in configure.cc et al), and for the parts that must  
use a MacPorts gcc, use a patchfile or reinplace to get those parts  
to use e.g. ${prefix}/bin/gcc-mp-4.3, and then declare a dependency  
on e.g. port:gcc43. I don't think we need any changes in MacPorts  
base for this, especially as it's a hypothetical situation so far.



From bob.spamnot at gmail.com  Wed Jan 28 12:07:26 2009
From: bob.spamnot at gmail.com (Bob)
Date: Wed, 28 Jan 2009 13:07:26 -0700
Subject: gv error
In-Reply-To: <4980B8E6.6050607@macports.org>
References: <760710620901280842p7eb301aocacd43118447aa10@mail.gmail.com>
	<760710620901281153h26466332m28361bd09b8c1e0e@mail.gmail.com>
	<4980B8E6.6050607@macports.org>
Message-ID: <760710620901281207x1e068ec0i2784651587c58c9b@mail.gmail.com>

On Wed, Jan 28, 2009 at 12:58 PM, Joshua Root <jmr at macports.org> wrote:

> Bob wrote:
> > Looking at the crash report it would seem there is a problem with all
> > the new X11 code in Macports.
>
> More the opposite, sort of. The library where the crash happened is
> /usr/X11/lib/libXt.6.dylib. It should be using
> /opt/local/lib/libXt.6.dylib.
>
> - Josh
>

OK.  Here are the linked libraries:

otool -L /opt/local/bin/gv
/opt/local/bin/gv:
    /usr/X11/lib/libXinerama.1.dylib (compatibility version 2.0.0, current
version 2.0.0)
    /opt/local/lib/libXaw3d.8.dylib (compatibility version 8.0.0, current
version 8.0.0)
    /usr/X11/lib/libXpm.4.dylib (compatibility version 16.0.0, current
version 16.0.0)
    /usr/X11/lib/libXmu.6.dylib (compatibility version 9.0.0, current
version 9.0.0)
    /usr/X11/lib/libXt.6.dylib (compatibility version 7.0.0, current version
7.0.0)
    /usr/X11/lib/libXext.6.dylib (compatibility version 11.0.0, current
version 11.0.0)
    /usr/X11/lib/libSM.6.dylib (compatibility version 7.0.0, current version
7.0.0)
    /usr/X11/lib/libICE.6.dylib (compatibility version 10.0.0, current
version 10.0.0)
    /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current
version 9.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
111.1.3)
    /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.2.3)
    /opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current
version 1.0.4)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
1.0.0)

How do I fix this?

Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090128/839d2c8e/attachment-0001.html>

From jm at poure.com  Wed Jan 28 12:24:36 2009
From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=)
Date: Wed, 28 Jan 2009 21:24:36 +0100
Subject: How to required packages with variants
In-Reply-To: <4980B54A.6020602@macports.org>
References: <1233167085.9791.1.camel@debian> <4980AB42.9020200@macports.org>
	<1233170041.11335.1.camel@debian>  <4980B54A.6020602@macports.org>
Message-ID: <1233174276.14198.4.camel@debian>

On Wed, 2009-01-28 at 11:43 -0800, David Evans wrote:
> My understanding is the without the x264 option, ffmpeg includes its
> own 
> codec (h264) and
> with it an additional libx264 codec is included.  So I guess it
> depends 
> on whether the libx264
> codec is being called by name and what the relative facilities of
> each 
> are -- you probably
> know more about this than I do though.
> 

FFmpeg includes codecs for reading and writing. Read and write support
is not the same.

=> In the case of H264, FFMpeg can read natively but needs x264 to write
to
H264.

=> The same happens for mp3 : FFmpeg can read natively and not write.
Therefore FFmpeg needs liblame. 

I had a look at the sox package that MLT uses for effect and sound
conversion. Well, I was surprised to see several variants:

Variants: ffmpeg flac lame mad universal vorbis 

Sox is the swizz army knife for converting files. What is the interest
of Sox for users if people cannot read/write in vorbis or flac or even
use FFmpeg with it. This could lead to problems in softwares like MLT or
Kdenlive.

Kind regards,
JM


From jjstickel at vcn.com  Wed Jan 28 12:24:58 2009
From: jjstickel at vcn.com (Jonathan Stickel)
Date: Wed, 28 Jan 2009 13:24:58 -0700
Subject: gv error
In-Reply-To: <mailman.5005.1233173249.184.macports-dev@lists.macosforge.org>
References: <mailman.5005.1233173249.184.macports-dev@lists.macosforge.org>
Message-ID: <4980BF1A.4050305@vcn.com>


On 1/28/09 macports-dev-request at lists.macosforge.org wrote:
> Date: Wed, 28 Jan 2009 13:07:26 -0700
> From: Bob <bob.spamnot at gmail.com>
> Subject: Re: gv error
> To: macports-dev at lists.macosforge.org, Joshua Root <jmr at macports.org>
> Message-ID:
> 	<760710620901281207x1e068ec0i2784651587c58c9b at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> On Wed, Jan 28, 2009 at 12:58 PM, Joshua Root <jmr at macports.org> wrote:
> 
>> > Bob wrote:
>>> > > Looking at the crash report it would seem there is a problem with all
>>> > > the new X11 code in Macports.
>> >
>> > More the opposite, sort of. The library where the crash happened is
>> > /usr/X11/lib/libXt.6.dylib. It should be using
>> > /opt/local/lib/libXt.6.dylib.
>> >
>> > - Josh
>> >
> 
> OK.  Here are the linked libraries:
> 
> otool -L /opt/local/bin/gv
> /opt/local/bin/gv:
>     /usr/X11/lib/libXinerama.1.dylib (compatibility version 2.0.0, current
> version 2.0.0)
>     /opt/local/lib/libXaw3d.8.dylib (compatibility version 8.0.0, current
> version 8.0.0)
>     /usr/X11/lib/libXpm.4.dylib (compatibility version 16.0.0, current
> version 16.0.0)
>     /usr/X11/lib/libXmu.6.dylib (compatibility version 9.0.0, current
> version 9.0.0)
>     /usr/X11/lib/libXt.6.dylib (compatibility version 7.0.0, current version
> 7.0.0)
>     /usr/X11/lib/libXext.6.dylib (compatibility version 11.0.0, current
> version 11.0.0)
>     /usr/X11/lib/libSM.6.dylib (compatibility version 7.0.0, current version
> 7.0.0)
>     /usr/X11/lib/libICE.6.dylib (compatibility version 10.0.0, current
> version 10.0.0)
>     /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current
> version 9.0.0)
>     /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 111.1.3)
>     /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current
> version 1.2.3)
>     /opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current
> version 1.0.4)
>     /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
> 1.0.0)
> 
> How do I fix this?
> 
> Bob

Plase see ticket 18249:

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

I put a partial fix to the Portfile there.

Jonathan

From bob.spamnot at gmail.com  Wed Jan 28 13:01:30 2009
From: bob.spamnot at gmail.com (Bob)
Date: Wed, 28 Jan 2009 14:01:30 -0700
Subject: gv error
In-Reply-To: <2729CDBA-7ACA-47D1-8327-F985B84C76AD@berkeley.edu>
References: <760710620901280842p7eb301aocacd43118447aa10@mail.gmail.com>
	<760710620901281153h26466332m28361bd09b8c1e0e@mail.gmail.com>
	<4980B8E6.6050607@macports.org>
	<760710620901281207x1e068ec0i2784651587c58c9b@mail.gmail.com>
	<2729CDBA-7ACA-47D1-8327-F985B84C76AD@berkeley.edu>
Message-ID: <760710620901281301y677e595ejbf205f766b1186cc@mail.gmail.com>

How can I tell if I am using +system_X11 variant?  I left MacPorts stock so
I don't think I am.  My macports is up to date and if fact was built from
scratch last night.

Bob

On Wed, Jan 28, 2009 at 1:47 PM, Jeremy Huddleston <jeremyhu at berkeley.edu>wrote:

> That otool -L output looks fine for a +system_X11 variant system, but I see
> references to /opt/local/lib/libX* in your crash report which means you
> probably are suffering from bug #17558.
>
> Do a 'sudo port -v upgrade outdated'
>
> Then if you're still having problems, figure out what libs in
> /opt/local/lib are still linking against /usr/X11/lib/* and report those as
> bugs
>
>
> On Jan 28, 2009, at 12:07, Bob wrote:
>
>  On Wed, Jan 28, 2009 at 12:58 PM, Joshua Root <jmr at macports.org> wrote:
>>
>>  Bob wrote:
>>>
>>>> Looking at the crash report it would seem there is a problem with all
>>>> the new X11 code in Macports.
>>>>
>>>
>>> More the opposite, sort of. The library where the crash happened is
>>> /usr/X11/lib/libXt.6.dylib. It should be using
>>> /opt/local/lib/libXt.6.dylib.
>>>
>>> - Josh
>>>
>>>
>> OK.  Here are the linked libraries:
>>
>> otool -L /opt/local/bin/gv
>> /opt/local/bin/gv:
>>   /usr/X11/lib/libXinerama.1.dylib (compatibility version 2.0.0, current
>> version 2.0.0)
>>   /opt/local/lib/libXaw3d.8.dylib (compatibility version 8.0.0, current
>> version 8.0.0)
>>   /usr/X11/lib/libXpm.4.dylib (compatibility version 16.0.0, current
>> version 16.0.0)
>>   /usr/X11/lib/libXmu.6.dylib (compatibility version 9.0.0, current
>> version 9.0.0)
>>   /usr/X11/lib/libXt.6.dylib (compatibility version 7.0.0, current version
>> 7.0.0)
>>   /usr/X11/lib/libXext.6.dylib (compatibility version 11.0.0, current
>> version 11.0.0)
>>   /usr/X11/lib/libSM.6.dylib (compatibility version 7.0.0, current version
>> 7.0.0)
>>   /usr/X11/lib/libICE.6.dylib (compatibility version 10.0.0, current
>> version 10.0.0)
>>   /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current
>> version 9.0.0)
>>   /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
>> 111.1.3)
>>   /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current
>> version 1.2.3)
>>   /opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current
>> version 1.0.4)
>>   /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
>> 1.0.0)
>>
>> How do I fix this?
>>
>> Bob
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090128/ad5af069/attachment.html>

From jeremyhu at macports.org  Wed Jan 28 14:04:46 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Wed, 28 Jan 2009 14:04:46 -0800
Subject: gv error
In-Reply-To: <760710620901281301y677e595ejbf205f766b1186cc@mail.gmail.com>
References: <760710620901280842p7eb301aocacd43118447aa10@mail.gmail.com>
	<760710620901281153h26466332m28361bd09b8c1e0e@mail.gmail.com>
	<4980B8E6.6050607@macports.org>
	<760710620901281207x1e068ec0i2784651587c58c9b@mail.gmail.com>
	<2729CDBA-7ACA-47D1-8327-F985B84C76AD@berkeley.edu>
	<760710620901281301y677e595ejbf205f766b1186cc@mail.gmail.com>
Message-ID: <49663DDB-9BA3-49E9-9B94-5DC3D58A0499@macports.org>

If you don't know, then you're not.

It looks like gv is bugged and needs to be fixed (see the bug number  
from a parallel thread).  Now that I know about it, I'll try to have  
it fixed tonight.  For now, you can look in the bug and manually apply  
the fix I suggested.  It should work, but I need to test it first...

--Jeremy

On Jan 28, 2009, at 13:01, Bob wrote:

> How can I tell if I am using +system_X11 variant?  I left MacPorts  
> stock so
> I don't think I am.  My macports is up to date and if fact was built  
> from
> scratch last night.
>
> Bob
>
> On Wed, Jan 28, 2009 at 1:47 PM, Jeremy Huddleston <jeremyhu at berkeley.edu 
> >wrote:
>
>> That otool -L output looks fine for a +system_X11 variant system,  
>> but I see
>> references to /opt/local/lib/libX* in your crash report which means  
>> you
>> probably are suffering from bug #17558.
>>
>> Do a 'sudo port -v upgrade outdated'
>>
>> Then if you're still having problems, figure out what libs in
>> /opt/local/lib are still linking against /usr/X11/lib/* and report  
>> those as
>> bugs
>>
>>
>> On Jan 28, 2009, at 12:07, Bob wrote:
>>
>> On Wed, Jan 28, 2009 at 12:58 PM, Joshua Root <jmr at macports.org>  
>> wrote:
>>>
>>> Bob wrote:
>>>>
>>>>> Looking at the crash report it would seem there is a problem  
>>>>> with all
>>>>> the new X11 code in Macports.
>>>>>
>>>>
>>>> More the opposite, sort of. The library where the crash happened is
>>>> /usr/X11/lib/libXt.6.dylib. It should be using
>>>> /opt/local/lib/libXt.6.dylib.
>>>>
>>>> - Josh
>>>>
>>>>
>>> OK.  Here are the linked libraries:
>>>
>>> otool -L /opt/local/bin/gv
>>> /opt/local/bin/gv:
>>>  /usr/X11/lib/libXinerama.1.dylib (compatibility version 2.0.0,  
>>> current
>>> version 2.0.0)
>>>  /opt/local/lib/libXaw3d.8.dylib (compatibility version 8.0.0,  
>>> current
>>> version 8.0.0)
>>>  /usr/X11/lib/libXpm.4.dylib (compatibility version 16.0.0, current
>>> version 16.0.0)
>>>  /usr/X11/lib/libXmu.6.dylib (compatibility version 9.0.0, current
>>> version 9.0.0)
>>>  /usr/X11/lib/libXt.6.dylib (compatibility version 7.0.0, current  
>>> version
>>> 7.0.0)
>>>  /usr/X11/lib/libXext.6.dylib (compatibility version 11.0.0, current
>>> version 11.0.0)
>>>  /usr/X11/lib/libSM.6.dylib (compatibility version 7.0.0, current  
>>> version
>>> 7.0.0)
>>>  /usr/X11/lib/libICE.6.dylib (compatibility version 10.0.0, current
>>> version 10.0.0)
>>>  /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current
>>> version 9.0.0)
>>>  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current  
>>> version
>>> 111.1.3)
>>>  /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current
>>> version 1.2.3)
>>>  /opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0,  
>>> current
>>> version 1.0.4)
>>>  /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current  
>>> version
>>> 1.0.0)
>>>
>>> How do I fix this?
>>>
>>> Bob
>>> _______________________________________________
>>> 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 devans at macports.org  Wed Jan 28 14:53:23 2009
From: devans at macports.org (David Evans)
Date: Wed, 28 Jan 2009 14:53:23 -0800
Subject: How to required packages with variants
In-Reply-To: <1233174276.14198.4.camel@debian>
References: <1233167085.9791.1.camel@debian>
	<4980AB42.9020200@macports.org>	<1233170041.11335.1.camel@debian>
	<4980B54A.6020602@macports.org> <1233174276.14198.4.camel@debian>
Message-ID: <4980E1E3.9040106@macports.org>

Jean-Michel Pour? wrote:
> On Wed, 2009-01-28 at 11:43 -0800, David Evans wrote:
>   
>> My understanding is the without the x264 option, ffmpeg includes its
>> own 
>> codec (h264) and
>> with it an additional libx264 codec is included.  So I guess it
>> depends 
>> on whether the libx264
>> codec is being called by name and what the relative facilities of
>> each 
>> are -- you probably
>> know more about this than I do though.
>>
>>     
>
> FFmpeg includes codecs for reading and writing. Read and write support
> is not the same.
>
> => In the case of H264, FFMpeg can read natively but needs x264 to write
> to
> H264.
>
> => The same happens for mp3 : FFmpeg can read natively and not write.
> Therefore FFmpeg needs liblame. 
>
> I had a look at the sox package that MLT uses for effect and sound
> conversion. Well, I was surprised to see several variants:
>
> Variants: ffmpeg flac lame mad universal vorbis 
>
> Sox is the swizz army knife for converting files. What is the interest
> of Sox for users if people cannot read/write in vorbis or flac or even
> use FFmpeg with it. This could lead to problems in softwares like MLT or
> Kdenlive.
>
> Kind regards,
> JM
>
>   
Have opened a ticket for enhancement of ffmpeg based on JM's 
comments[1].  Please direct any further comments and/or suggestions there.

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

From ryandesign at macports.org  Wed Jan 28 15:11:31 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 28 Jan 2009 17:11:31 -0600
Subject: [46081] trunk/dports/kde/kdelibs4/Portfile
In-Reply-To: <20090128214208.D56EBDACE09@beta.macosforge.org>
References: <20090128214208.D56EBDACE09@beta.macosforge.org>
Message-ID: <72AC3C61-C925-436C-819D-B05777DCD320@macports.org>


On Jan 28, 2009, at 15:42, illogic-al at macports.org wrote:

> +    ui_msg "######################################################"
> +    ui_msg "#  Programs will not start until you issue the foll: #"

"the foll"?

> +    ui_msg "#  'sudo chown -R $USER ~/Library/Preferences/KDE'   #"
> +    ui_msg "#  replacing $USER with your username, followed by   #"
> +    ui_msg "#  'open /Applications/Macports/KDE4/kdeinit4.app'   #"

Use ${applications_dir} here.

> +    ui_msg "#  in a Terminal.                                    #"
> +    ui_msg "######################################################"



From raimue at macports.org  Wed Jan 28 19:31:30 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 29 Jan 2009 04:31:30 +0100
Subject: [46020] trunk/dports/_resources/port1.0/group/kde4-1.0.tcl
In-Reply-To: <D2CFE1D2-11AB-420A-8E0D-D49E0CB40CFC@macports.org>
References: <20090127122952.440FAD81692@beta.macosforge.org>
	<D2CFE1D2-11AB-420A-8E0D-D49E0CB40CFC@macports.org>
Message-ID: <49812312.4030300@macports.org>

Ryan Schmidt wrote:
> You should not use default variants in this way. How would a user  
> turn off documentation if they did not want it? The user could "sudo  
> port install foo -docs" but as soon as they need to upgrade foo, "- 
> docs" will disappear (MacPorts never records negative variants) and  
> the +docs variant will be selected again.
> 
> Either remove the docs variant and just make the documentation build  
> always, or if there is value in letting the user remove the  
> documentation, then make it a (non-default) no_docs variant that does  
> so.

Can we please remember to add support for storing deselected variants?
(registry2.0 *hint, hint*). I don't like those no_* variants very much
as they just do not feel "natural".

The problem occurred again in another port recently (ffmpeg, #18256 [1])
and there are also many other ports using this approach [2]. But I would
consider this only a workaround until we have support in base to do it
right and replace the no_* variants.

Rainer

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

[2] $ port echo variant:^no_ |wc -l
      38

From ryandesign at macports.org  Wed Jan 28 21:42:46 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 28 Jan 2009 23:42:46 -0600
Subject: [46011] trunk/dports/mail
In-Reply-To: <20090127075527.4C608D7EABF@beta.macosforge.org>
References: <20090127075527.4C608D7EABF@beta.macosforge.org>
Message-ID: <07B2F339-7269-46D9-A3BD-F97814568156@macports.org>

On Jan 27, 2009, at 01:55, raimue at macports.org wrote:

> Revision: 46011
>           http://trac.macports.org/changeset/46011
> Author:   raimue at macports.org
> Date:     2009-01-26 23:55:26 -0800 (Mon, 26 Jan 2009)
> Log Message:
> -----------
> mail/vpopmail:
> New port, closes #14022
>
> Added Paths:
> -----------
>     trunk/dports/mail/vpopmail/
>     trunk/dports/mail/vpopmail/Portfile
>     trunk/dports/mail/vpopmail/files/
>     trunk/dports/mail/vpopmail/files/patch-configure.diff
>
> Added: trunk/dports/mail/vpopmail/Portfile
> ===================================================================
> --- trunk/dports/mail/vpopmail/Portfile	                         
> (rev 0)
> +++ trunk/dports/mail/vpopmail/Portfile	2009-01-27 07:55:26 UTC  
> (rev 46011)
> @@ -0,0 +1,143 @@
> +# $Id$
> +
> +PortSystem      1.0
> +
> +name				vpopmail
> +version				5.4.25
> +categories			mail
> +maintainers			yahoo.com:compconsultant
> +platforms			darwin
> +
> +description			Manage multiple virtual domains with Qmail
> +
> +long_description	        Vpopmail is a set of programs for  
> creating and managing multiple virtual domains on a qmail server,  
> with full support for many POP/IMAP servers.
> +
> +variant onchange description {Enable use on the ONCHANGE script} {
> +	configure.args-append	--enable-onchange-script
> +}
> +
> +variant mysql5 description {Store vpopmail users and more in  
> MySQL5} {
> +	configure.args-append	--enable-auth-module=mysql \
> +				--enable-auth-logging \
> +				--enable-sql-logging \
> +				--enable-incdir=${prefix}/include/mysql5/mysql \
> +				--enable-libdir=${prefix}/lib/mysql5/mysql \
> +				--enable-valias
> +	depends_lib-append	port:mysql5
> +}

To give the user the choice of using the mysql5 or mysql5-devel  
ports, the dependency on mysql should be changed from "port:mysql5"  
to e.g. "path:bin/mysql_config5:mysql5"

> +variant roaming description {Enable POP before SMTP functionality} {
> +	configure.args-append	--enable-roaming-users \
> +				--enable-tcpserver-file=${prefix}/var/${name}/etc/tcp.smtp
> +}
> +
> +variant noclearpasswords description {Do not store a cleartext  
> version of the password} {
> +	configure.args-append	--disable-clear-passwd
> +}
> +
> +variant learnpasswords description {If user password is not set,  
> learn it the first time they authenticate} {
> +	configure.args-append	--enable-learn-passwords
> +}
> +
> +variant spamassassin description {Enable spamassassin integration} {
> +	configure.args-append	--enable=spamassassin \
> +				--enable-spamc-prog=${prefix}/bin/spamc
> +	depends_lib-append	port:p5-mail-spamassassin
> +}
> +
> +variant maildrop description {Enable maildrop integration} {
> +	configure.args-append	--enable-maildrop \
> +				--enable-maildrop-prog=${prefix}/bin/maildrop
> +	depends_lib-append	port:maildrop
> +}
> +
> +variant logverbose conflicts logpwds logall description {Enables  
> verbose logging of all attempts, with passwords} {
> +	configure.args-append	--enable-logging=v
> +}
> +
> +variant logpwds conflicts logverbose logall description {Log  
> errors with passwords} {
> +	configure.args-append	--enable-logging=p
> +}
> +
> +variant logall conflicts logpwds logverbose description {Log all  
> attempts, no passwords} {
> +	configure.args-append	--enable-logging=y
> +}

There are a lot of variants here. Can this be reduced at all? For  
example, could the user specify the logging options in a  
configuration file instead?

> +homepage			http://www.inter7.com/index.php?page=vpopmail
> +
> +depends_lib			port:qmail-spamcontrol \
> +				port:ucspi-tcp
> +
> +master_sites		        sourceforge
> +				
> +checksums			md5 273c2c25906aed5206e97b01a2593aa6 \
> +				sha1 ce62415fbd338b80f1962a477d94276f622756d0 \
> +				rmd160 57142cca0617bd95ef2e5f4aa74ab5fa0844d6df
> +
> +patchfiles			patch-configure.diff
> +
> +configure.args			--enable-qmaildir=${prefix}/var/qmail \
> +				--enable-tcprules-prog=${prefix}/bin/tcprules \
> +				--enable-qmail-ext \
> +				--prefix=/opt/local \
> +				--exec-prefix=/opt/local

Please use the ${prefix} variable instead of assuming it's /opt/ 
local. Actually, "--prefix=${prefix}" is already in  
configure.pre_args by default, so you should remove "--prefix=/opt/ 
local" from configure.args entirely. And --exec-prefix by default is  
the value of --prefix, so you don't need the line "--exec-prefix=/opt/ 
local" either.

> +build.target
> +
> +destroot.target		install-strip
> +destroot.keepdirs	${destroot}${prefix}/var/${name}/domains
> +
> +pre-configure {
> +
> +	# The vpopmail users and groups are required before compilation
> +	addgroup vchkpw gid=2109
> +	adduser vpopmail uid=7797 gid=[existsgroup vchkpw]  
> realname=vpopmail home=${prefix}/var/${name} shell=/usr/bin/true
> +}
> +
> +post-destroot {
> +	if {[variant_isset roaming]} {
> +		system "echo \"127.:allow,RELAYCLIENT=''\" > ${destroot}$ 
> {prefix}/var/${name}/etc/tcp.smtp.sample"
> +		system "echo \"localhost|0|user|password|database\" >${destroot}$ 
> {prefix}/var/${name}/etc/tcp.smtp.sample"
> +		system "chown vpopmail:vchkpw ${destroot}${prefix}/var/${name}/ 
> etc/tcp.smtp.sample"
> +                xinstall -m 644 -W ${worksrcpath}  
> README.roamingusers ${destroot}${prefix}/var/${name}/doc
> +	}
> +	if {[variant_isset mysql5]} {
> +		file rename ${destroot}/${prefix}/var/${name}/etc/vpopmail.mysql  
> ${destroot}/${prefix}/var/${name}/etc/vpopmail.mysql.sample

You should not put a slash before the variable ${prefix} because the  
variable ${prefix} already begins with a slash.

> +                xinstall -m 644 -W ${worksrcpath} README.mysql $ 
> {destroot}${prefix}/var/${name}/doc
> +	}
> +	if {[variant_isset maildrop]} {
> +                xinstall -m 644 -W ${worksrcpath} README.maildrop $ 
> {destroot}${prefix}/var/${name}/doc
> +	}
> +	if {[variant_isset onchange]} {
> +                xinstall -m 644 -W ${worksrcpath} README.onchange $ 
> {destroot}${prefix}/var/${name}/doc
> +	}
> +	if {[variant_isset spamassassin]} {
> +                xinstall -m 644 -W ${worksrcpath}  
> README.spamassassin ${destroot}${prefix}/var/${name}/doc
> +	}
> +}

The usual place for documentation files would be ${prefix}/share/doc/$ 
{name} or ${prefix}/share/doc/${name}-${version}... or is vpopmail  
already storing other documentation in ${prefix}/var/${name}/doc?  
Would users of other vpopmail distributions expect it there?

I have the same concerns about the configuration files which, based  
on the above, appear to live in ${prefix}/var/${name}/etc/ but a more  
traditional place would be ${prefix}/etc or ${prefix}/etc/${name}.



From jm at poure.com  Thu Jan 29 07:49:39 2009
From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=)
Date: Thu, 29 Jan 2009 16:49:39 +0100
Subject: [MacPorts] #18261: sox should be upgraded to support
	pkg-config and include all ports by defaults
In-Reply-To: <057.de09c7ee604fcd5cacf30755df84aeff@macports.org>
References: <048.7a87369f16287c0732a7384fd48e1e00@macports.org>
	<057.de09c7ee604fcd5cacf30755df84aeff@macports.org>
Message-ID: <1233244179.8808.0.camel@debian>

On Thu, 2009-01-29 at 14:01 +0000, MacPorts wrote:
> 
>  Unfortunately there is no maintainer on this port. Ideally you could
> post
>  a patch, but hopefully someone will get to it soon.

I will post a patch and can maintain the sox port.


From alakazam at macports.org  Thu Jan 29 18:25:52 2009
From: alakazam at macports.org (Olivier Le Floch)
Date: Fri, 30 Jan 2009 03:25:52 +0100
Subject: [MacPorts] MacPortsDevelopers modified
In-Reply-To: <20090130022413.AB270280A4@relay13.apple.com>
References: <20090130022413.AB270280A4@relay13.apple.com>
Message-ID: <79906088-9C1C-4744-92C1-D68B5EDBA0C3@macports.org>

On 30 janv. 09, at 03:24, MacPorts wrote:

> Changed page "MacPortsDevelopers" by rasmus at macports.org from  
> 85.226.146.20*
> Page URL: <http://trac.macports.org/wiki/MacPortsDevelopers>
> Diff URL: <http://trac.macports.org/wiki/MacPortsDevelopers?action=diff&version=125 
> >
> Revision 125
> Comment: Added myself to the list. Was unsure about sorting policy,  
> so I used the standard asc. surname order.

It seems to me that they were sorted by handle ?

From blb at macports.org  Thu Jan 29 19:08:53 2009
From: blb at macports.org (Bryan Blackburn)
Date: Thu, 29 Jan 2009 20:08:53 -0700
Subject: [MacPorts] MacPortsDevelopers modified
In-Reply-To: <79906088-9C1C-4744-92C1-D68B5EDBA0C3@macports.org>
References: <20090130022413.AB270280A4@relay13.apple.com>
	<79906088-9C1C-4744-92C1-D68B5EDBA0C3@macports.org>
Message-ID: <20090130030853.GG1546@ninagal.withay.com>

On Fri, Jan 30, 2009 at 03:25:52AM +0100, Olivier Le Floch said:
> On 30 janv. 09, at 03:24, MacPorts wrote:
>
>> Changed page "MacPortsDevelopers" by rasmus at macports.org from  
>> 85.226.146.20*
>> Page URL: <http://trac.macports.org/wiki/MacPortsDevelopers>
>> Diff URL: 
>> <http://trac.macports.org/wiki/MacPortsDevelopers?action=diff&version=125 
>> >
>> Revision 125
>> Comment: Added myself to the list. Was unsure about sorting policy, so I 
>> used the standard asc. surname order.
>
> It seems to me that they were sorted by handle ?

Right, I've added a note to that effect now.

Bryan


From jm at poure.com  Fri Jan 30 02:59:19 2009
From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=)
Date: Fri, 30 Jan 2009 11:59:19 +0100
Subject: Various questions
Message-ID: <1233313159.15944.7.camel@debian>

Dear friends,

Three minor issues:

* I am curious to learn why GTK2 port should rely (ultimately after a
few depencies) on FFMpeg port. Under Debian GNU/Linux, this is not the
case and not the case also on most GNU/Linux systems. So there may be
place for discussion to removal FFmpeg dependency from one GTK2
dependant package.

* Also out of interest, when FFmpeg is required in dependencies and
FFmpeg-devel is installed, why does MacPorts complain? Is there a
workaround. The reason of my question is to add ffmpeg-devel as depency
of MLT, because a  lot of bugs were fixed in FFmpeg-devel (including
Mpeg-2 timestamps, which is crutial for MLT).

* How to become MacPorts maintainer. I checked out the SVN tree. I would
like to apply for maintenance of sox, mlt, gavl, frei0r, ladspa-sdk and
kdenlive. Please contact me if you need my SSH pub key. I manage
kdenlive.org website and you don't have to worry.

Kind regards,
Jean-Michel


From jm at poure.com  Fri Jan 30 04:41:07 2009
From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=)
Date: Fri, 30 Jan 2009 13:41:07 +0100
Subject: Sox package
Message-ID: <1233319267.20365.2.camel@debian>

Dear friends,

I would like to propose a patch to upgrade Sox package to 14.2.0
version. Also, as sox is a swiss army knife in sound conversion, I would
like to link against ffmpeg and lame by default. Variant no_gpl would
disable both ffmpeg and lame. Any suggestion?

Kind regards,
Jean-Michel


From illogical1 at gmail.com  Fri Jan 30 05:31:57 2009
From: illogical1 at gmail.com (O)
Date: Fri, 30 Jan 2009 08:31:57 -0500
Subject: Sox package
In-Reply-To: <1233319267.20365.2.camel@debian>
References: <1233319267.20365.2.camel@debian>
Message-ID: <797cc39c0901300531y1a97923fw511386288b49f6ec@mail.gmail.com>

On Fri, Jan 30, 2009 at 7:41 AM, Jean-Michel Pour? <jm at poure.com> wrote:
> Dear friends,
>
> I would like to propose a patch to upgrade Sox package to 14.2.0
> version. Also, as sox is a swiss army knife in sound conversion, I would
> like to link against ffmpeg and lame by default. Variant no_gpl would
> disable both ffmpeg and lame. Any suggestion?
sounds good to me.

From florian.ebeling at gmail.com  Fri Jan 30 06:25:40 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Fri, 30 Jan 2009 15:25:40 +0100
Subject: Various questions
In-Reply-To: <1233313159.15944.7.camel@debian>
References: <1233313159.15944.7.camel@debian>
Message-ID: <5cbbe4ae0901300625r61509ba1p8ef36cdd8b5fb2a9@mail.gmail.com>

Hi Jean-Michel,

> * How to become MacPorts maintainer. I checked out the SVN tree. I would
> like to apply for maintenance of sox, mlt, gavl, frei0r, ladspa-sdk and
> kdenlive. Please contact me if you need my SSH pub key. I manage
> kdenlive.org website and you don't have to worry.

The official version of the project rules are in the guide:
http://guide.macports.org/#project.contributing

Basically, you can take over the maintainership of any nomaintainer
port in the collection. Note, though, that maintainers are not
automatically committers. I find that not very practical, but you
are supposed then to work together with a maintainer-comitter,
and mail him you patches. I for one mostly skipped this step,
and nobody really complained about it. And it does not really
fit my ideas of quick internet collaboration, induces addtional latency,
ambiguity about how much testing the committer has to do
after maintainer approval and such. But it's been put down and
is the official rule now. I'd say rather apply for commit right away
than get repelled by the wording there. Somebody said to me
in a direct mail that these rules were from a different time.

To get commit rights you have to send a mail requesting them
to the manager list. See the guide again for details. I hope you
join the band :)

Florian



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

From jeremyhu at macports.org  Fri Jan 30 09:58:59 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Fri, 30 Jan 2009 09:58:59 -0800
Subject: Sox package
In-Reply-To: <1233319267.20365.2.camel@debian>
References: <1233319267.20365.2.camel@debian>
Message-ID: <FDE1062D-213D-4274-ADBC-39799EF30261@macports.org>

Why should no_gpl disable ffmpeg?  It seems to make sense to me that  
no_gpl should still pull in ffmpeg since ffmpeg+no_gpl should be GPL- 
free (if that's not the case, then it should be... I think the confopt  
os --disable-gpl).


On Jan 30, 2009, at 04:41, Jean-Michel Pour? wrote:

> Dear friends,
>
> I would like to propose a patch to upgrade Sox package to 14.2.0
> version. Also, as sox is a swiss army knife in sound conversion, I  
> would
> like to link against ffmpeg and lame by default. Variant no_gpl would
> disable both ffmpeg and lame. Any suggestion?
>
> Kind regards,
> Jean-Michel
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


From devans at macports.org  Fri Jan 30 10:06:01 2009
From: devans at macports.org (David Evans)
Date: Fri, 30 Jan 2009 10:06:01 -0800
Subject: Sox package
In-Reply-To: <FDE1062D-213D-4274-ADBC-39799EF30261@macports.org>
References: <1233319267.20365.2.camel@debian>
	<FDE1062D-213D-4274-ADBC-39799EF30261@macports.org>
Message-ID: <49834189.4090509@macports.org>

Jeremy Huddleston wrote:
> Why should no_gpl disable ffmpeg?  It seems to make sense to me that 
> no_gpl should still pull in ffmpeg since ffmpeg+no_gpl should be 
> GPL-free (if that's not the case, then it should be... I think the 
> confopt os --disable-gpl).
>
The no_gpl idea has been scratched.  See #18261.

From jeremyhu at macports.org  Fri Jan 30 10:15:25 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Fri, 30 Jan 2009 10:15:25 -0800
Subject: Sox package
In-Reply-To: <49834189.4090509@macports.org>
References: <1233319267.20365.2.camel@debian>
	<FDE1062D-213D-4274-ADBC-39799EF30261@macports.org>
	<49834189.4090509@macports.org>
Message-ID: <5534470B-CEDD-4565-952D-C26E29C2A4A6@macports.org>


On Jan 30, 2009, at 10:06, David Evans wrote:

> Jeremy Huddleston wrote:
>> Why should no_gpl disable ffmpeg?  It seems to make sense to me  
>> that no_gpl should still pull in ffmpeg since ffmpeg+no_gpl should  
>> be GPL-free (if that's not the case, then it should be... I think  
>> the confopt os --disable-gpl).
>>
> The no_gpl idea has been scratched.  See #18261.

I don't really any mention of no_gpl at http://trac.macports.org/ticket/18261

... ?

From jm at poure.com  Fri Jan 30 10:16:17 2009
From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=)
Date: Fri, 30 Jan 2009 19:16:17 +0100
Subject: [MacPorts] #18285: Sox 14.2.0 upgrade
In-Reply-To: <057.eec95ec4811bd2449f969742052fd851@macports.org>
References: <048.c77445f5612fd6c3c03987e05ace7963@macports.org>
	<057.eec95ec4811bd2449f969742052fd851@macports.org>
Message-ID: <1233339377.6658.0.camel@debian>

On Fri, 2009-01-30 at 17:39 +0000, MacPorts wrote:
> 
>   * the --enable-x items in configure.args are unnecessary as
> configure
>  will check for each item unless you say --without-x
>   * the following dependencies are missing:
>   *      port:file  (for libmagic)
>   *      port:libpng
>   *      port:wavpack (for libwavpack)

It make sense. Sorry for the confusion.


From jm at poure.com  Fri Jan 30 10:21:57 2009
From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=)
Date: Fri, 30 Jan 2009 19:21:57 +0100
Subject: [MacPorts] #18286: mlt framework port
In-Reply-To: <048.3c9a73332944b4d11fd9866fd6936d8f@macports.org>
References: <048.3c9a73332944b4d11fd9866fd6936d8f@macports.org>
Message-ID: <1233339717.6658.5.camel@debian>

On Fri, 2009-01-30 at 15:21 +0000, MacPorts wrote:
>  This port is not compiling, probably because it needs a sox upgrade.
> But I
>  am creating the ticket and will update the port attached file from
> time to
>  time.

Please note that MLT requires a very recent FFmpeg, as FFmpeg was
massively fixed a few weeks ago, mainly with timestamp issues in H264
and Mpeg2. So there may be a need to compile MLT against FFmpeg-devel.

In fact, the FFmpeg version in MacPorts is deprecated. It is too old and
too buggy and I don't see any interest in keeping it. Maybe it could be
replaced with a more recent snapshot of FFmpeg SVN. This is why I left
ffmpeg as a dependency. 

Kind regards,
Jean-Michel


From devans at macports.org  Fri Jan 30 10:41:21 2009
From: devans at macports.org (David Evans)
Date: Fri, 30 Jan 2009 10:41:21 -0800
Subject: Sox package
In-Reply-To: <5534470B-CEDD-4565-952D-C26E29C2A4A6@macports.org>
References: <1233319267.20365.2.camel@debian>
	<FDE1062D-213D-4274-ADBC-39799EF30261@macports.org>
	<49834189.4090509@macports.org>
	<5534470B-CEDD-4565-952D-C26E29C2A4A6@macports.org>
Message-ID: <498349D1.4000205@macports.org>

Jeremy Huddleston wrote:
>
> On Jan 30, 2009, at 10:06, David Evans wrote:
>
>> Jeremy Huddleston wrote:
>>> Why should no_gpl disable ffmpeg?  It seems to make sense to me that 
>>> no_gpl should still pull in ffmpeg since ffmpeg+no_gpl should be 
>>> GPL-free (if that's not the case, then it should be... I think the 
>>> confopt os --disable-gpl).
>>>
>> The no_gpl idea has been scratched.  See #18261.
>
> I don't really any mention of no_gpl at 
> http://trac.macports.org/ticket/18261
>
> ... ?
>
My mistake, try http://trac.macports.org/ticket/18285.


From devans at macports.org  Fri Jan 30 10:42:17 2009
From: devans at macports.org (David Evans)
Date: Fri, 30 Jan 2009 10:42:17 -0800
Subject: [MacPorts] #18286: mlt framework port
In-Reply-To: <1233339717.6658.5.camel@debian>
References: <048.3c9a73332944b4d11fd9866fd6936d8f@macports.org>
	<1233339717.6658.5.camel@debian>
Message-ID: <49834A09.7090205@macports.org>

Jean-Michel Pour? wrote:
> On Fri, 2009-01-30 at 15:21 +0000, MacPorts wrote:
>   
>>  This port is not compiling, probably because it needs a sox upgrade.
>> But I
>>  am creating the ticket and will update the port attached file from
>> time to
>>  time.
>>     
>
> Please note that MLT requires a very recent FFmpeg, as FFmpeg was
> massively fixed a few weeks ago, mainly with timestamp issues in H264
> and Mpeg2. So there may be a need to compile MLT against FFmpeg-devel.
>
> In fact, the FFmpeg version in MacPorts is deprecated. It is too old and
> too buggy and I don't see any interest in keeping it. Maybe it could be
> replaced with a more recent snapshot of FFmpeg SVN. This is why I left
> ffmpeg as a dependency. 
>
> Kind regards,
> Jean-Michel
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>
>   
Yes, this is a problem in more ways than one.   In principal, ffmpeg
should be updated to a more
recent revision but to proceed beyond the current one breaks the API/ABI
for libavcodec (version
52 vs 51).  Version 52 is not backwardly compatible with Version 51.
Hence ffmpeg-devel which
attempts to provide a newer version for people who don't mind the API
change.

Additionally, there are other problems.  For instance right now
ffmpeg-devel has libx264 support
disabled because the current x264 port is too old to build against it.
On the other hand, the newer
version of x264 that builds with ffmpeg-devel has apparently changed its
API as well and so it
will not build with ffmpeg -- ffmpeg requires the older one.

Same sort of thing with speex and speex-devel.  ffmpeg-devel will only
build against speex-devel.

To upgrade ffmpeg itself to a later revision, all ports that depend upon
it need to be identified and
evaluated to see if they can live with the new API.  I assume that
applications that use ffmpeg
are in the process of switching upstream but the status of that is
unknown to me at this point.

It looks to me that we need to start this process and get rid of
ffmpeg-devel before things get too
far out of hand.

Would you like to help?

Dave


From jm at poure.com  Fri Jan 30 12:10:17 2009
From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=)
Date: Fri, 30 Jan 2009 21:10:17 +0100
Subject: [MacPorts] #18286: mlt framework port
In-Reply-To: <49834A09.7090205@macports.org>
References: <048.3c9a73332944b4d11fd9866fd6936d8f@macports.org>
	<1233339717.6658.5.camel@debian>  <49834A09.7090205@macports.org>
Message-ID: <1233346217.9890.19.camel@debian>

On Fri, 2009-01-30 at 10:42 -0800, David Evans wrote:
> To upgrade ffmpeg itself to a later revision, all ports that depend
> upon
> it need to be identified and
> evaluated to see if they can live with the new API.  I assume that
> applications that use ffmpeg
> are in the process of switching upstream but the status of that is
> unknown to me at this point.
> 
> It looks to me that we need to start this process and get rid of
> ffmpeg-devel before things get too
> far out of hand.
> 
> Would you like to help?

Debian GNU/Linux has the same problems.

The solution in Debian is to create separate packages for FFmpeg
executables and libraries and develpment headers. FFmpeg is usualy
compiled from a recent SVN snapshot and from releases

Examples:
libavcodec51	3:20080706-0.3 (=recent release or old snapshot)
libavcodec52	3:20090108-0.0 (=svn snapshot)

There is more granularity in packages, which cannot be achieved in
MacPorts.

To achieve this in MacPorts we could:

* Build ffmpeg executables + libraries from recent SVN. For
simplication, we could choose the same svn revisions as Christian
Marillat. The package would be called ffmpeg-52.

* Build old ffmpeg libraries without executables. FFmpeg has these
options during compilation:   --disable-ffmpeg --disable-ffplay
--disable-ffserver. The package would be called ffmpeg-51.

Normally, both versions should be able to live together. Also it would
have the advantage of not breaking existing MacPorts.

I don't have practical knowledged to know if this will work. Maybe a
solution to compile would be to hide FFmpeg incude files somewhere
outside the /opt/local/include path. In each FFmpeg dependant package we
would add /opt/local/include/ffmpeg-51 or /opt/local/include/ffmpeg-52
to the library path before compilation. I have no idea if this can work.

What do you think ? Do you think it is technically possible?

Otherwize, I believe most packages should be able to build against the
newer FFmpeg libraries. But migrating all packages is not a suitable
solution. Some packages will never migrate. Usually this means that
these packages are dead.

Kind regards,
Jean-Michel


From devans at macports.org  Fri Jan 30 12:10:36 2009
From: devans at macports.org (David Evans)
Date: Fri, 30 Jan 2009 12:10:36 -0800
Subject: Various questions
In-Reply-To: <1233313159.15944.7.camel@debian>
References: <1233313159.15944.7.camel@debian>
Message-ID: <49835EBC.8020005@macports.org>

Jean-Michel Pour? wrote:
> Dear friends,
>
> Three minor issues:
>
> * I am curious to learn why GTK2 port should rely (ultimately after a
> few depencies) on FFMpeg port. Under Debian GNU/Linux, this is not the
> case and not the case also on most GNU/Linux systems. So there may be
> place for discussion to removal FFmpeg dependency from one GTK2
> dependant package.
>   
I'm not sure this is the case (see attached dependency tree for gtk2).  
Can you describe
what exactly happened that convinced you of this?
> * Also out of interest, when FFmpeg is required in dependencies and
> FFmpeg-devel is installed, why does MacPorts complain? Is there a
> workaround. The reason of my question is to add ffmpeg-devel as depency
> of MLT, because a  lot of bugs were fixed in FFmpeg-devel (including
> Mpeg-2 timestamps, which is crutial for MLT).
>   
ffmpeg and ffmpeg-devel are essentially the same port and install the 
same files only
with different revisions from ffmpeg svn trunk.  Because of this 
conflict, MacPorts
will not allow you to have both activated at the same time.  Its 
possible to state a
dependency in terms of the presence of a specific libary or file path.  
In that case,
you could convince a port to accept either as a solution for the 
dependency and you
could switch between one and other by deactivating one and activating 
the other.

This doesn't really work for ffmpeg and ffmpeg-devel because they are 
not API/ABI
compatible with each other.  Best thing is to upgrade ffmpeg to the 
latest relatively
stable revision and fix all the dependent ports that are broken by the 
API change. 

I would prefer to find all the dependent ports first, rather than change 
ffmpeg
and see what breaks.  Not user friendly, really.

In the meantime, if you want to use ffmpeg-devel for testing locally, 
set your
dependency to ffmpeg-devel and then deactivate ffmpeg and activate
ffmpeg-devel (assuming its also installed) like this using the 
appropriate version numbers
for what you have installed

sudo port deactivate ffmpeg @15261_3+a52
sudo port activate ffmpeg-devel @15943_1

to see what's installed

sudo port installed ffmpeg\*

Is r15943 good enough for your purposes or does it need to be 
incremented to a later revision?

Dave
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gtk2-dep-tree.txt
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090130/1ef363c3/attachment-0001.txt>

From jm at poure.com  Fri Jan 30 12:21:41 2009
From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=)
Date: Fri, 30 Jan 2009 21:21:41 +0100
Subject: Various questions
In-Reply-To: <49835EBC.8020005@macports.org>
References: <1233313159.15944.7.camel@debian> <49835EBC.8020005@macports.org>
Message-ID: <1233346901.11271.3.camel@debian>

On Fri, 2009-01-30 at 12:10 -0800, David Evans wrote:
> I'm not sure this is the case (see attached dependency tree for
> gtk2).  
> Can you describe
> what exactly happened that convinced you of this?

I ran sudo port install gtk2 and it installed FFmpeg. I was surprised.


From jm at poure.com  Fri Jan 30 12:25:19 2009
From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=)
Date: Fri, 30 Jan 2009 21:25:19 +0100
Subject: Various questions
In-Reply-To: <49835EBC.8020005@macports.org>
References: <1233313159.15944.7.camel@debian> <49835EBC.8020005@macports.org>
Message-ID: <1233347119.11271.8.camel@debian>

On Fri, 2009-01-30 at 12:10 -0800, David Evans wrote:
> Is r15943 good enough for your purposes or does it need to be 
> incremented to a later revision?

Thank you very much for the explanations. For using MLT and Kdenlive in
good conditions, we really need a cutting edge ffmpeg-devel version.
Debian multimedia provides SVN 20090128, which is r16844.

 ffmpeg -i
FFmpeg version SVN-r16844, Copyright (c) 2000-2009 Fabrice Bellard, et
al.

This is mainly a timestamp issue. Video editing is more precise and
audio is well synced with a very recent snapshot.

If you want, when I have SVN access, I can bump Debian multimedia SVN
versions to stick to them. FFmpeg is usualy upgraded twice a month,
depending on fixed in FFmpeg.

I will be able to help the best I can, knowing that I use a remote
MacOsX computer and that this computer will not be here forever. But
there will be probably other people in the kdenlive community willing to
help and maintain Kdenlive/MLT/FFmpeg. 

Kind regards,
Jean-Michel


From jmpp at macports.org  Fri Jan 30 12:36:12 2009
From: jmpp at macports.org (Juan Manuel Palacios)
Date: Fri, 30 Jan 2009 16:06:12 -0430
Subject: [46151] trunk/dports/sysutils/nrg4iso/Portfile
In-Reply-To: <20090130170754.C70E0DDD5D2@beta.macosforge.org>
References: <20090130170754.C70E0DDD5D2@beta.macosforge.org>
Message-ID: <A82D083C-1471-4039-9409-5C4F0FEE289F@macports.org>


On Jan 30, 2009, at 12:37 PM, krischik at macports.org wrote:

> Revision
> 46151
> Author
> krischik at macports.org
> Date
> 2009-01-30 09:07:52 -0800 (Fri, 30 Jan 2009)
> Log Message
>
> just a tiny typo - good that I checked.
> Modified Paths
>
> trunk/dports/sysutils/nrg4iso/Portfile
> Diff
>
> Modified: trunk/dports/sysutils/nrg4iso/Portfile (46150 => 46151)
> --- trunk/dports/sysutils/nrg4iso/Portfile	2009-01-30 16:52:47 UTC  
> (rev 46150)
> +++ trunk/dports/sysutils/nrg4iso/Portfile	2009-01-30 17:07:52 UTC  
> (rev 46151)
> @@ -5,7 +5,7 @@
>
>  name				nrg4iso
>  version				1.0.1
> -revision			1
> +revision			2
>  platforms			darwin
>  categories			sysutils
>  maintainers			macports:macports.org
> @@ -17,7 +17,7 @@
>
>  homepage			http://nrg4iso.googlecode.com
>  master_sites		http://nrg4iso.googlecode.com/files
> -:xa
> +
>  extract.suffix      .tgz
>
>  checksums			md5		e865f0cfe587032dee852bdc6739a27d \

	Does this correction change the final build results in any way...? If  
not, then there's no reason what-so-ever to increase the revision, as  
that'll erroneously indicate that the package should be reinstalled.


-jmpp


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

From devans at macports.org  Fri Jan 30 12:55:42 2009
From: devans at macports.org (David Evans)
Date: Fri, 30 Jan 2009 12:55:42 -0800
Subject: Various questions
In-Reply-To: <1233347119.11271.8.camel@debian>
References: <1233313159.15944.7.camel@debian>	 <49835EBC.8020005@macports.org>
	<1233347119.11271.8.camel@debian>
Message-ID: <4983694E.1000003@macports.org>

Jean-Michel Pour? wrote:
> On Fri, 2009-01-30 at 12:10 -0800, David Evans wrote:
>   
>> Is r15943 good enough for your purposes or does it need to be 
>> incremented to a later revision?
>>     
>
> Thank you very much for the explanations. For using MLT and Kdenlive in
> good conditions, we really need a cutting edge ffmpeg-devel version.
> Debian multimedia provides SVN 20090128, which is r16844.
>
>  ffmpeg -i
> FFmpeg version SVN-r16844, Copyright (c) 2000-2009 Fabrice Bellard, et
> al.
>
> This is mainly a timestamp issue. Video editing is more precise and
> audio is well synced with a very recent snapshot.
>
> If you want, when I have SVN access, I can bump Debian multimedia SVN
> versions to stick to them. FFmpeg is usualy upgraded twice a month,
> depending on fixed in FFmpeg.
>
> I will be able to help the best I can, knowing that I use a remote
> MacOsX computer and that this computer will not be here forever. But
> there will be probably other people in the kdenlive community willing to
> help and maintain Kdenlive/MLT/FFmpeg. 
>
> Kind regards,
> Jean-Michel
>
>   
Great, I'm working on creating a list of ports that depend on ffmpeg in 
some sense then we
can split them up and see what happens when they try to build against 
ffmpeg-devel.  Hopefully,
its not a long list.  Already I see that some apps that claim to be 
using ffmpeg use an internal
snapshot of some previous version and disavow any responsibility if you 
use an external version
(gimp-gap for instance which really only uses ffmpeg to load video for 
editing in gimp).

I'll try ffmpeg-devel at r16844 and see what happens.  Don't want to 
update too often
as people may object to rebuilding all the time since its a big build.  
So probably want
to pay attention to what changes are being made and update only when 
something significant
happens.  Right now the upstream developers are actually talking about a 
0.5 release!

NB Fedora 10 is now using the 20080908 snapshot of ffmpeg.

Dave

From blb at macports.org  Fri Jan 30 12:59:07 2009
From: blb at macports.org (Bryan Blackburn)
Date: Fri, 30 Jan 2009 13:59:07 -0700
Subject: Various questions
In-Reply-To: <1233346901.11271.3.camel@debian>
References: <1233313159.15944.7.camel@debian> <49835EBC.8020005@macports.org>
	<1233346901.11271.3.camel@debian>
Message-ID: <20090130205907.GE848@ninagal.withay.com>

On Fri, Jan 30, 2009 at 09:21:41PM +0100, Jean-Michel Pour? said:
> On Fri, 2009-01-30 at 12:10 -0800, David Evans wrote:
> > I'm not sure this is the case (see attached dependency tree for
> > gtk2).  
> > Can you describe
> > what exactly happened that convinced you of this?
> 
> I ran sudo port install gtk2 and it installed FFmpeg. I was surprised.

As am I; I definitely don't see ffmpeg anywhere in the dependency chain for
gtk2 (either with port-rdeps [1] or running a 'port -dy install gtk2' to see
what it would do [2]).

Can you run a 'port dependents ffmpeg' to see which port brought it in?

Bryan

[1] - <http://trac.macports.org/browser/contrib/port-rdeps>
[2] - note that -y (dry-run) is only available on trunk


From jm at poure.com  Fri Jan 30 13:14:29 2009
From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=)
Date: Fri, 30 Jan 2009 22:14:29 +0100
Subject: Various questions
In-Reply-To: <20090130205907.GE848@ninagal.withay.com>
References: <1233313159.15944.7.camel@debian>
	<49835EBC.8020005@macports.org> <1233346901.11271.3.camel@debian>
	<20090130205907.GE848@ninagal.withay.com>
Message-ID: <1233350069.13856.9.camel@debian>

On Fri, 2009-01-30 at 13:59 -0700, Bryan Blackburn wrote:
> Can you run a 'port dependents ffmpeg' to see which port brought it
> in?

ffmpeg @15261_2+a52+darwin_i386 (active)
ffmpeg-devel @15943_1+darwin_i386

port dependant ffmpeg
gegl depends on ffmpeg
sox depends on ffmpeg

port dependents gegl
gimp2 depends on gegl

port dependents gtk2    
libopenraw depends on gtk2
gconf depends on gtk2
gegl depends on gtk2
gnome-keyring depends on gtk2
libglade2 depends on gtk2
libgnomecanvas depends on gtk2
libbonoboui depends on gtk2
poppler depends on gtk2
py25-gtk depends on gtk2
gtk-nodoka-engine depends on gtk2
gtkimageview depends on gtk2
xsane depends on gtk2
opencv depends on gtk2
wireshark depends on gtk2

So installing gtk2 will install gegl which will install ffmpeg.
Very strange! But still possible in a computer world :)


From blb at macports.org  Fri Jan 30 13:16:14 2009
From: blb at macports.org (Bryan Blackburn)
Date: Fri, 30 Jan 2009 14:16:14 -0700
Subject: [46149] trunk/dports
In-Reply-To: <20090130165307.5151CDDD085@beta.macosforge.org>
References: <20090130165307.5151CDDD085@beta.macosforge.org>
Message-ID: <20090130211614.GF848@ninagal.withay.com>

On Fri, Jan 30, 2009 at 08:52:58AM -0800, krischik at macports.org said:
> Revision: 46149
>           http://trac.macports.org/changeset/46149
> Author:   krischik at macports.org
> Date:     2009-01-30 08:52:45 -0800 (Fri, 30 Jan 2009)
> Log Message:
> -----------
> O dear - nrg4iso is of course a sysutil and not an emulator. It is in fact a better nrg2iso.
[...]
> -categories			emulators
> -maintainers			me.com:krischik
> +categories			sysutils
> +maintainers			macports:macports.org

There are several formats the email address in maintainers can take:
standard/unobfuscated 'me at example.com', the preferred obfuscated form
'example.com:me', and the committer form, which is just 'me' (macports.org
is implied).  So in this case I think you just want:

maintainers   krischik

Bryan

[...]


From devans at macports.org  Fri Jan 30 13:26:29 2009
From: devans at macports.org (David Evans)
Date: Fri, 30 Jan 2009 13:26:29 -0800
Subject: Various questions
In-Reply-To: <1233350069.13856.9.camel@debian>
References: <1233313159.15944.7.camel@debian>	<49835EBC.8020005@macports.org>
	<1233346901.11271.3.camel@debian>	<20090130205907.GE848@ninagal.withay.com>
	<1233350069.13856.9.camel@debian>
Message-ID: <49837085.2010607@macports.org>

Jean-Michel Pour? wrote:
> On Fri, 2009-01-30 at 13:59 -0700, Bryan Blackburn wrote:
>   
>> Can you run a 'port dependents ffmpeg' to see which port brought it
>> in?
>>     
>
> ffmpeg @15261_2+a52+darwin_i386 (active)
> ffmpeg-devel @15943_1+darwin_i386
>
> port dependant ffmpeg
> gegl depends on ffmpeg
> sox depends on ffmpeg
>
> port dependents gegl
> gimp2 depends on gegl
>
> port dependents gtk2    
> libopenraw depends on gtk2
> gconf depends on gtk2
> gegl depends on gtk2
> gnome-keyring depends on gtk2
> libglade2 depends on gtk2
> libgnomecanvas depends on gtk2
> libbonoboui depends on gtk2
> poppler depends on gtk2
> py25-gtk depends on gtk2
> gtk-nodoka-engine depends on gtk2
> gtkimageview depends on gtk2
> xsane depends on gtk2
> opencv depends on gtk2
> wireshark depends on gtk2
>
> So installing gtk2 will install gegl which will install ffmpeg.
> Very strange! But still possible in a computer world :)
>
>   

I think you're reading this wrong.    gegl depends on ffmpeg and gtk2   
but gtk2 does not depend on gegl.

installing gegl will install ffmpeg and gtk2

Dave

From jmr at macports.org  Fri Jan 30 13:29:42 2009
From: jmr at macports.org (Joshua Root)
Date: Sat, 31 Jan 2009 08:29:42 +1100
Subject: Various questions
In-Reply-To: <1233350069.13856.9.camel@debian>
References: <1233313159.15944.7.camel@debian>	<49835EBC.8020005@macports.org>
	<1233346901.11271.3.camel@debian>	<20090130205907.GE848@ninagal.withay.com>
	<1233350069.13856.9.camel@debian>
Message-ID: <49837146.5000205@macports.org>

Jean-Michel Pour? wrote:
> On Fri, 2009-01-30 at 13:59 -0700, Bryan Blackburn wrote:
>> Can you run a 'port dependents ffmpeg' to see which port brought it
>> in?
> 
> ffmpeg @15261_2+a52+darwin_i386 (active)
> ffmpeg-devel @15943_1+darwin_i386
> 
> port dependant ffmpeg
> gegl depends on ffmpeg
> sox depends on ffmpeg
> 
> port dependents gegl
> gimp2 depends on gegl
> 
> port dependents gtk2    
> libopenraw depends on gtk2
> gconf depends on gtk2
> gegl depends on gtk2
> gnome-keyring depends on gtk2
> libglade2 depends on gtk2
> libgnomecanvas depends on gtk2
> libbonoboui depends on gtk2
> poppler depends on gtk2
> py25-gtk depends on gtk2
> gtk-nodoka-engine depends on gtk2
> gtkimageview depends on gtk2
> xsane depends on gtk2
> opencv depends on gtk2
> wireshark depends on gtk2
> 
> So installing gtk2 will install gegl which will install ffmpeg.
> Very strange! But still possible in a computer world :)

That isn't what the info above describes. Installing gegl will bring in
gtk2 as a dependency, not vice versa.

- Josh

From jjstickel at vcn.com  Fri Jan 30 13:37:08 2009
From: jjstickel at vcn.com (Jonathan Stickel)
Date: Fri, 30 Jan 2009 14:37:08 -0700
Subject: newticket web error
Message-ID: <49837304.70904@vcn.com>

If I am not first logged in, I am seeing this when I try to access 
http://trac.macports.org/newticket:

  Portfile
		
2	2	
3	3	PortSystem 1.0
4	4	name                    subversion
5	 	version                 1.4.5
  	5	version                 1.4.6
6	6	categories              devel
7	7	platforms               darwin
8	8	maintainers             dluke at geeklair.net
? 	? 	
15	15	homepage                http://subversion.tigris.org/
16	16	master_sites            ${homepage}downloads/
17	17	use_bzip2               yes
18	 	checksums               md5 4c333a5fe827568c67d195cda7a5e154
  	18	checksums               md5 9c7cf517362c1c9332b610339e5cce6b
19	19	
20	20	depends_lib             port:expat port:neon \
21	21	                        port:apr port:apr-util \

Regards,
Jonathan

From wsiegrist at apple.com  Fri Jan 30 13:48:56 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Fri, 30 Jan 2009 13:48:56 -0800
Subject: newticket web error
In-Reply-To: <49837304.70904@vcn.com>
References: <49837304.70904@vcn.com>
Message-ID: <B52EF6C8-A7F1-404B-A101-54801A446C7C@apple.com>

Fixed.

-Bill

On Jan 30, 2009, at 1:37 PM, Jonathan Stickel wrote:

> If I am not first logged in, I am seeing this when I try to access http://trac.macports.org/newticket 
> :
>
> Portfile
> 		
> 2	2	
> 3	3	PortSystem 1.0
> 4	4	name                    subversion
> 5	 	version                 1.4.5
> 	5	version                 1.4.6
> 6	6	categories              devel
> 7	7	platforms               darwin
> 8	8	maintainers             dluke at geeklair.net
> ? 	? 	
> 15	15	homepage                http://subversion.tigris.org/
> 16	16	master_sites            ${homepage}downloads/
> 17	17	use_bzip2               yes
> 18	 	checksums               md5 4c333a5fe827568c67d195cda7a5e154
> 	18	checksums               md5 9c7cf517362c1c9332b610339e5cce6b
> 19	19	
> 20	20	depends_lib             port:expat port:neon \
> 21	21	                        port:apr port:apr-util \
>
> Regards,
> Jonathan
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev




----
William Siegrist
BSD / Darwin Team







From raimue at macports.org  Sat Jan 31 01:05:09 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Sat, 31 Jan 2009 10:05:09 +0100
Subject: [46176] trunk/dports/net/wget/Portfile
In-Reply-To: <20090131081106.3CA8ADECC6A@beta.macosforge.org>
References: <20090131081106.3CA8ADECC6A@beta.macosforge.org>
Message-ID: <49841445.80800@macports.org>

ryandesign at macports.org wrote:
> Revision: 46176
>           http://trac.macports.org/changeset/46176
> Author:   ryandesign at macports.org
> Date:     2009-01-31 00:11:00 -0800 (Sat, 31 Jan 2009)
> Log Message:
> -----------
> wget:
> 
>  * Fix universal build on Tiger so it includes gettext and (if not deselected) openssl support. See #18276.
>  * Use muniversal portgroup because I have greater confidence in it generally to produce a viable universal binary.
> 
> Modified Paths:
> --------------
>     trunk/dports/net/wget/Portfile

[...]

> +# So that +universal can use gettext and openssl on Tiger; see #18276.
> +configure.ldflags-append        -liconv
> +if {![variant_isset no_ssl]} {
> +    depends_build-append        port:pkgconfig
> +    configure.ldflags-append    [exec ${prefix}/bin/pkg-config --libs libssl]
> +}
> +

This is not a good idea as you need pkgconfig now installed to parse
this Portfile. The last PortIndex failed because of this.

Rainer

From godboutn at yahoo.ca  Sat Jan 31 08:10:05 2009
From: godboutn at yahoo.ca (Nicolas Godbout)
Date: Sat, 31 Jan 2009 08:10:05 -0800 (PST)
Subject: nudge: please commit updates to pcb and ng-spice for subsequent gEDA
	port
Message-ID: <762596.20831.qm@web59201.mail.re1.yahoo.com>

Hello,

As suggested in the MacPorts guide, I take the liberty to nudge committers on the dev list to process updates for the following ports following a 72 hour grace period:

port pcb : ticket #18172, submitted four days ago.
has been assigned to the listed maintainer, but is more than likely abandoned.  The current port version dates from almost four years ago.

While you're at it, you can process
port ng-spice: ticket #18208, submitted only two days ago, but still has not been assigned at all.  This is a 'nomaintainer' port and could be processed immediately by any maintainer.

Sorry for leaning on the side of impatience, but I'm trying to complete a list of ports for the whole gEDA (GPL's Electronic Design Automation) suite and that's a total of about fifteen ports.  Having up-to-date ports for present portions of that suite would be really helpful.

Actually, I'd like to have your opinion on this: the core gEDA package consists of 10 ports that I already have working on my local repository.  Should I:
1) open 10 tickets, one for each port submission?
2) open 1 ticket with all port files and patches in a compressed file?
3) apply first as a port maintainer so that I can also commit all these new packages?

Your feedback on this would be appreciated.

With my salutations,

Nicolas.


      __________________________________________________________________
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now at
http://ca.toolbar.yahoo.com.

From simon at ruderich.org  Sat Jan 31 12:46:20 2009
From: simon at ruderich.org (Simon Ruderich)
Date: Sat, 31 Jan 2009 21:46:20 +0100
Subject: Problem installing xorg-server on Tiger
Message-ID: <20090131204620.GA3021@ruderich.org>

Hi,

Today I tried to install xorg-server on my Intel Tiger. The
installation worked fine, but when I want to start X11.app in
/Applications/MacPorts I get the following error:

X11.app: main(): argc=1
	argv[0] = /Applications/MacPorts/X11.app/Contents/MacOS/X11.bin
Waiting for startup parameters via Mach IPC.
X11.app: Could not connect to server (DISPLAY is not set).  Starting X server.
X11.app: Launching /opt/local/bin/startx:
	argv[0] = /bin/sh
	argv[1] = -c
	argv[2] = /opt/local/bin/startx
bootstrap_look_up(): 1102l
font_cache: Scanning user font directories to generate X11 font caches
font_cache: Updating FC cache
/opt/local/bin/font_cache: line 197: /opt/local/bin/fc-cache: No such file or directory
font_cache: Done
xauth:  creating new authority file /Users/simonruderich/.serverauth.3088

X11.app: do_start_x11_server(): argc=6
	argv[0] = /opt/local/bin/X
	argv[1] = :1
	argv[2] = -nolisten
	argv[3] = tcp
	argv[4] = -auth
	argv[5] = /Users/simonruderich/.serverauth.3088
X11.app: Debug Info: kKLuchrData failed, trying kKLKCHRData.
If you are using a 3rd party keyboard layout, please see http://xquartz.macosforge.org/trac/ticket/154
Xquartz starting:
X.Org X Server 1.4.2-apple31
Build Date: 20090131
(EE) XKB: Couldn't open rules file /opt/local/share/X11/xkb/rules/base
(EE) XKB: Couldn't open rules file /opt/local/share/X11/xkb/rules/base
Could not init font path element /opt/local/share/fonts/misc/, removing from list!
Could not init font path element /opt/local/share/fonts/TTF/, removing from list!
Could not init font path element /opt/local/share/fonts/OTF, removing from list!
Could not init font path element /opt/local/share/fonts/Type1/, removing from list!
Could not init font path element /opt/local/share/fonts/100dpi/, removing from list!
Could not init font path element /opt/local/share/fonts/75dpi/, removing from list!
Could not init font path element /Library/Fonts, removing from list!
Could not init font path element /System/Library/Fonts, removing from list!

Fatal server error:
could not open default font 'fixed'
   AbortDDX
Quitting Xquartz...
Xquartz: start_x11_server: (ipc/mig) server died
giving up.
xinit:  Connection refused (errno 61):  unable to connect to X server
xinit:  No such process (errno 3):  Server error.

The first error (X11.app: Debug Info: kKLuchrData failed, trying
kKLKCHRData.) can be fixed by using a US keyboard layout (I use a
German one). But I have no idea how to fix the others.

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

From jeremyhu at macports.org  Sat Jan 31 13:14:47 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Sat, 31 Jan 2009 13:14:47 -0800
Subject: Problem installing xorg-server on Tiger
In-Reply-To: <20090131204620.GA3021@ruderich.org>
References: <20090131204620.GA3021@ruderich.org>
Message-ID: <9B39571A-AFAD-4003-A357-BC37B8E41C2E@macports.org>

Well that's odd...

1) Why don't you have fontconfig installed (should be pulled in by  
xorg-server)?

2) Do you have xorg-fonts installed?

Run the following and provide output:

sudo font_cache -f -v -s
ls /opt/local/share/fonts/misc

On Jan 31, 2009, at 12:46, Simon Ruderich wrote:

> Hi,
>
> Today I tried to install xorg-server on my Intel Tiger. The
> installation worked fine, but when I want to start X11.app in
> /Applications/MacPorts I get the following error:
>
> X11.app: main(): argc=1
> 	argv[0] = /Applications/MacPorts/X11.app/Contents/MacOS/X11.bin
> Waiting for startup parameters via Mach IPC.
> X11.app: Could not connect to server (DISPLAY is not set).  Starting  
> X server.
> X11.app: Launching /opt/local/bin/startx:
> 	argv[0] = /bin/sh
> 	argv[1] = -c
> 	argv[2] = /opt/local/bin/startx
> bootstrap_look_up(): 1102l
> font_cache: Scanning user font directories to generate X11 font caches
> font_cache: Updating FC cache
> /opt/local/bin/font_cache: line 197: /opt/local/bin/fc-cache: No  
> such file or directory
> font_cache: Done
> xauth:  creating new authority file /Users/simonruderich/.serverauth. 
> 3088
>
> X11.app: do_start_x11_server(): argc=6
> 	argv[0] = /opt/local/bin/X
> 	argv[1] = :1
> 	argv[2] = -nolisten
> 	argv[3] = tcp
> 	argv[4] = -auth
> 	argv[5] = /Users/simonruderich/.serverauth.3088
> X11.app: Debug Info: kKLuchrData failed, trying kKLKCHRData.
> If you are using a 3rd party keyboard layout, please see http://xquartz.macosforge.org/trac/ticket/154
> Xquartz starting:
> X.Org X Server 1.4.2-apple31
> Build Date: 20090131
> (EE) XKB: Couldn't open rules file /opt/local/share/X11/xkb/rules/base
> (EE) XKB: Couldn't open rules file /opt/local/share/X11/xkb/rules/base
> Could not init font path element /opt/local/share/fonts/misc/,  
> removing from list!
> Could not init font path element /opt/local/share/fonts/TTF/,  
> removing from list!
> Could not init font path element /opt/local/share/fonts/OTF,  
> removing from list!
> Could not init font path element /opt/local/share/fonts/Type1/,  
> removing from list!
> Could not init font path element /opt/local/share/fonts/100dpi/,  
> removing from list!
> Could not init font path element /opt/local/share/fonts/75dpi/,  
> removing from list!
> Could not init font path element /Library/Fonts, removing from list!
> Could not init font path element /System/Library/Fonts, removing  
> from list!
>
> Fatal server error:
> could not open default font 'fixed'
>   AbortDDX
> Quitting Xquartz...
> Xquartz: start_x11_server: (ipc/mig) server died
> giving up.
> xinit:  Connection refused (errno 61):  unable to connect to X server
> xinit:  No such process (errno 3):  Server error.
>
> The first error (X11.app: Debug Info: kKLuchrData failed, trying
> kKLKCHRData.) can be fixed by using a US keyboard layout (I use a
> German one). But I have no idea how to fix the others.
>
> Thanks for your help,
> Simon
> -- 
> + privacy is necessary
> + using http://gnupg.org
> + public key id: 0x6115F804EFB33229
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


From jmr at macports.org  Sat Jan 31 13:33:45 2009
From: jmr at macports.org (Joshua Root)
Date: Sun, 01 Feb 2009 08:33:45 +1100
Subject: Problem installing xorg-server on Tiger
In-Reply-To: <9B39571A-AFAD-4003-A357-BC37B8E41C2E@macports.org>
References: <20090131204620.GA3021@ruderich.org>
	<9B39571A-AFAD-4003-A357-BC37B8E41C2E@macports.org>
Message-ID: <4984C3B9.1010706@macports.org>

Jeremy Huddleston wrote:
> Well that's odd...
> 
> 1) Why don't you have fontconfig installed (should be pulled in by
> xorg-server)?

It actually doesn't look like it is pulled in.

- Josh

From simon at ruderich.org  Sat Jan 31 14:54:18 2009
From: simon at ruderich.org (Simon Ruderich)
Date: Sat, 31 Jan 2009 23:54:18 +0100
Subject: Problem installing xorg-server on Tiger
In-Reply-To: <9B39571A-AFAD-4003-A357-BC37B8E41C2E@macports.org>
References: <20090131204620.GA3021@ruderich.org>
	<9B39571A-AFAD-4003-A357-BC37B8E41C2E@macports.org>
Message-ID: <20090131225418.GA7276@ruderich.org>

On Sat, Jan 31, 2009 at 01:14:47PM -0800, Jeremy Huddleston wrote:
> Well that's odd...
>
> 1) Why don't you have fontconfig installed (should be pulled in by
> xorg-server)?

I didn't have it installed (this was a new MacPorts
installation). Installed it now, but still doesn't work.

> 2) Do you have xorg-fonts installed?

Yes.

The following ports are currently installed:
  xorg-fonts @20090102_1 (active)

> Run the following and provide output:
>
> sudo font_cache -f -v -s

font_cache: Scanning system font directories to generate X11 font caches
font_cache: Making fonts.dir for updated directories.
font_cache:    /System/Library/Fonts
Unknown Type 1 weight "All"
Couldn't determine weight for HelveLTMM
Unknown Type 1 weight "All"
Couldn't determine weight for Helvetica LT MM
Unknown Type 1 weight "All"
Couldn't determine weight for Times LT MM
Unknown Type 1 weight "All"
Couldn't determine weight for TimesLTMM
font_cache:    /Library/Fonts
font_cache:    /opt/local/share/fonts/100dpi
font_cache:    /opt/local/share/fonts/75dpi
font_cache:    /opt/local/share/fonts/OTF
font_cache:    /opt/local/share/fonts/Speedo
font_cache:    /opt/local/share/fonts/TTF
font_cache:    /opt/local/share/fonts/Type1
font_cache:    /opt/local/share/fonts/cyrillic
font_cache:    /opt/local/share/fonts/misc
font_cache: Updating FC cache
/usr/share/fonts: skipping, no such directory
/usr/X11R6/lib/X11/fonts: caching, new cache contents: 0 fonts, 11 dirs
/usr/X11R6/lib/X11/fonts/100dpi: caching, new cache contents: 398 fonts, 0 dirs
/usr/X11R6/lib/X11/fonts/75dpi: caching, new cache contents: 398 fonts, 0 dirs
/usr/X11R6/lib/X11/fonts/CID: caching, new cache contents: 0 fonts, 0 dirs
/usr/X11R6/lib/X11/fonts/Speedo: caching, new cache contents: 0 fonts, 0 dirs
/usr/X11R6/lib/X11/fonts/TTF: caching, new cache contents: 22 fonts, 0 dirs
/usr/X11R6/lib/X11/fonts/Type1: caching, new cache contents: 29 fonts, 0 dirs
/usr/X11R6/lib/X11/fonts/cyrillic: caching, new cache contents: 0 fonts, 0 dirs
/usr/X11R6/lib/X11/fonts/encodings: caching, new cache contents: 0 fonts, 1 dirs
/usr/X11R6/lib/X11/fonts/encodings/large: caching, new cache contents: 0 fonts, 0 dirs
/usr/X11R6/lib/X11/fonts/local: caching, new cache contents: 0 fonts, 0 dirs
/usr/X11R6/lib/X11/fonts/misc: caching, new cache contents: 60 fonts, 0 dirs
/usr/X11R6/lib/X11/fonts/util: caching, new cache contents: 0 fonts, 0 dirs
/Library/Fonts: caching, new cache contents: 143 fonts, 0 dirs
/Network/Library/Fonts: skipping, no such directory
/System/Library/Fonts: caching, new cache contents: 61 fonts, 0 dirs
/opt/local/share/fonts: caching, new cache contents: 0 fonts, 9 dirs
/opt/local/share/fonts/100dpi: /opt/local/share/fonts/100dpi: failed to write cache
caching, new cache contents: 398 fonts, 0 dirs
/opt/local/share/fonts/75dpi: caching, new cache contents: 398 fonts, 0 dirs
/opt/local/share/fonts/OTF: caching, new cache contents: 23 fonts, 0 dirs
/opt/local/share/fonts/Speedo: caching, new cache contents: 0 fonts, 0 dirs
/opt/local/share/fonts/TTF: caching, new cache contents: 13 fonts, 0 dirs
/opt/local/share/fonts/Type1: caching, new cache contents: 29 fonts, 0 dirs
/opt/local/share/fonts/cyrillic: caching, new cache contents: 0 fonts, 0 dirs
/opt/local/share/fonts/encodings: caching, new cache contents: 0 fonts, 1 dirs
/opt/local/share/fonts/encodings/large: /opt/local/share/fonts/encodings/large: failed to write cache
caching, new cache contents: 0 fonts, 0 dirs
/opt/local/share/fonts/misc: caching, new cache contents: 59 fonts, 0 dirs
/opt/local/var/cache/fontconfig: cleaning cache directory
/opt/local/bin/fc-cache: failed
font_cache: Done

> ls /opt/local/share/fonts/misc

10x20-ISO8859-1.pcf.gz
10x20-ISO8859-10.pcf.gz
10x20-ISO8859-11.pcf.gz
10x20-ISO8859-13.pcf.gz
10x20-ISO8859-14.pcf.gz
10x20-ISO8859-15.pcf.gz
10x20-ISO8859-16.pcf.gz
10x20-ISO8859-2.pcf.gz
10x20-ISO8859-3.pcf.gz
10x20-ISO8859-4.pcf.gz
10x20-ISO8859-5.pcf.gz
10x20-ISO8859-7.pcf.gz
10x20-ISO8859-8.pcf.gz
10x20-ISO8859-9.pcf.gz
10x20-KOI8-R.pcf.gz
10x20.pcf.gz
12x13ja.pcf.gz
12x24.pcf.gz
12x24rk.pcf.gz
18x18ja.pcf.gz
18x18ko.pcf.gz
4x6-ISO8859-1.pcf.gz
4x6-ISO8859-10.pcf.gz
4x6-ISO8859-13.pcf.gz
4x6-ISO8859-14.pcf.gz
4x6-ISO8859-15.pcf.gz
4x6-ISO8859-16.pcf.gz
4x6-ISO8859-2.pcf.gz
4x6-ISO8859-3.pcf.gz
4x6-ISO8859-4.pcf.gz
4x6-ISO8859-5.pcf.gz
4x6-ISO8859-7.pcf.gz
4x6-ISO8859-8.pcf.gz
4x6-ISO8859-9.pcf.gz
4x6-KOI8-R.pcf.gz
4x6.pcf.gz
5x7-ISO8859-1.pcf.gz
5x7-ISO8859-10.pcf.gz
5x7-ISO8859-13.pcf.gz
5x7-ISO8859-14.pcf.gz
5x7-ISO8859-15.pcf.gz
5x7-ISO8859-16.pcf.gz
5x7-ISO8859-2.pcf.gz
5x7-ISO8859-3.pcf.gz
5x7-ISO8859-4.pcf.gz
5x7-ISO8859-5.pcf.gz
5x7-ISO8859-7.pcf.gz
5x7-ISO8859-8.pcf.gz
5x7-ISO8859-9.pcf.gz
5x7-KOI8-R.pcf.gz
5x7.pcf.gz
5x8-ISO8859-1.pcf.gz
5x8-ISO8859-10.pcf.gz
5x8-ISO8859-13.pcf.gz
5x8-ISO8859-14.pcf.gz
5x8-ISO8859-15.pcf.gz
5x8-ISO8859-16.pcf.gz
5x8-ISO8859-2.pcf.gz
5x8-ISO8859-3.pcf.gz
5x8-ISO8859-4.pcf.gz
5x8-ISO8859-5.pcf.gz
5x8-ISO8859-7.pcf.gz
5x8-ISO8859-8.pcf.gz
5x8-ISO8859-9.pcf.gz
5x8-KOI8-R.pcf.gz
5x8.pcf.gz
6x10-ISO8859-1.pcf.gz
6x10-ISO8859-10.pcf.gz
6x10-ISO8859-13.pcf.gz
6x10-ISO8859-14.pcf.gz
6x10-ISO8859-15.pcf.gz
6x10-ISO8859-16.pcf.gz
6x10-ISO8859-2.pcf.gz
6x10-ISO8859-3.pcf.gz
6x10-ISO8859-4.pcf.gz
6x10-ISO8859-5.pcf.gz
6x10-ISO8859-7.pcf.gz
6x10-ISO8859-8.pcf.gz
6x10-ISO8859-9.pcf.gz
6x10-KOI8-R.pcf.gz
6x10.pcf.gz
6x12-ISO8859-1.pcf.gz
6x12-ISO8859-10.pcf.gz
6x12-ISO8859-13.pcf.gz
6x12-ISO8859-14.pcf.gz
6x12-ISO8859-15.pcf.gz
6x12-ISO8859-16.pcf.gz
6x12-ISO8859-2.pcf.gz
6x12-ISO8859-3.pcf.gz
6x12-ISO8859-4.pcf.gz
6x12-ISO8859-5.pcf.gz
6x12-ISO8859-7.pcf.gz
6x12-ISO8859-8.pcf.gz
6x12-ISO8859-9.pcf.gz
6x12-KOI8-R.pcf.gz
6x12.pcf.gz
6x13-ISO8859-1.pcf.gz
6x13-ISO8859-10.pcf.gz
6x13-ISO8859-11.pcf.gz
6x13-ISO8859-13.pcf.gz
6x13-ISO8859-14.pcf.gz
6x13-ISO8859-15.pcf.gz
6x13-ISO8859-16.pcf.gz
6x13-ISO8859-2.pcf.gz
6x13-ISO8859-3.pcf.gz
6x13-ISO8859-4.pcf.gz
6x13-ISO8859-5.pcf.gz
6x13-ISO8859-7.pcf.gz
6x13-ISO8859-8.pcf.gz
6x13-ISO8859-9.pcf.gz
6x13-KOI8-R.pcf.gz
6x13.pcf.gz
6x13B-ISO8859-1.pcf.gz
6x13B-ISO8859-10.pcf.gz
6x13B-ISO8859-13.pcf.gz
6x13B-ISO8859-14.pcf.gz
6x13B-ISO8859-15.pcf.gz
6x13B-ISO8859-16.pcf.gz
6x13B-ISO8859-2.pcf.gz
6x13B-ISO8859-3.pcf.gz
6x13B-ISO8859-4.pcf.gz
6x13B-ISO8859-5.pcf.gz
6x13B-ISO8859-7.pcf.gz
6x13B-ISO8859-8.pcf.gz
6x13B-ISO8859-9.pcf.gz
6x13B.pcf.gz
6x13O-ISO8859-1.pcf.gz
6x13O-ISO8859-10.pcf.gz
6x13O-ISO8859-13.pcf.gz
6x13O-ISO8859-14.pcf.gz
6x13O-ISO8859-15.pcf.gz
6x13O-ISO8859-16.pcf.gz
6x13O-ISO8859-2.pcf.gz
6x13O-ISO8859-3.pcf.gz
6x13O-ISO8859-4.pcf.gz
6x13O-ISO8859-5.pcf.gz
6x13O-ISO8859-7.pcf.gz
6x13O-ISO8859-9.pcf.gz
6x13O.pcf.gz
6x9-ISO8859-1.pcf.gz
6x9-ISO8859-10.pcf.gz
6x9-ISO8859-13.pcf.gz
6x9-ISO8859-14.pcf.gz
6x9-ISO8859-15.pcf.gz
6x9-ISO8859-16.pcf.gz
6x9-ISO8859-2.pcf.gz
6x9-ISO8859-3.pcf.gz
6x9-ISO8859-4.pcf.gz
6x9-ISO8859-5.pcf.gz
6x9-ISO8859-7.pcf.gz
6x9-ISO8859-8.pcf.gz
6x9-ISO8859-9.pcf.gz
6x9-KOI8-R.pcf.gz
6x9.pcf.gz
7x13-ISO8859-1.pcf.gz
7x13-ISO8859-10.pcf.gz
7x13-ISO8859-11.pcf.gz
7x13-ISO8859-13.pcf.gz
7x13-ISO8859-14.pcf.gz
7x13-ISO8859-15.pcf.gz
7x13-ISO8859-16.pcf.gz
7x13-ISO8859-2.pcf.gz
7x13-ISO8859-3.pcf.gz
7x13-ISO8859-4.pcf.gz
7x13-ISO8859-5.pcf.gz
7x13-ISO8859-7.pcf.gz
7x13-ISO8859-8.pcf.gz
7x13-ISO8859-9.pcf.gz
7x13-KOI8-R.pcf.gz
7x13.pcf.gz
7x13B-ISO8859-1.pcf.gz
7x13B-ISO8859-10.pcf.gz
7x13B-ISO8859-11.pcf.gz
7x13B-ISO8859-13.pcf.gz
7x13B-ISO8859-14.pcf.gz
7x13B-ISO8859-15.pcf.gz
7x13B-ISO8859-16.pcf.gz
7x13B-ISO8859-2.pcf.gz
7x13B-ISO8859-3.pcf.gz
7x13B-ISO8859-4.pcf.gz
7x13B-ISO8859-5.pcf.gz
7x13B-ISO8859-7.pcf.gz
7x13B-ISO8859-8.pcf.gz
7x13B-ISO8859-9.pcf.gz
7x13B.pcf.gz
7x13O-ISO8859-1.pcf.gz
7x13O-ISO8859-10.pcf.gz
7x13O-ISO8859-11.pcf.gz
7x13O-ISO8859-13.pcf.gz
7x13O-ISO8859-14.pcf.gz
7x13O-ISO8859-15.pcf.gz
7x13O-ISO8859-16.pcf.gz
7x13O-ISO8859-2.pcf.gz
7x13O-ISO8859-3.pcf.gz
7x13O-ISO8859-4.pcf.gz
7x13O-ISO8859-5.pcf.gz
7x13O-ISO8859-7.pcf.gz
7x13O-ISO8859-9.pcf.gz
7x13O.pcf.gz
7x14-ISO8859-1.pcf.gz
7x14-ISO8859-10.pcf.gz
7x14-ISO8859-11.pcf.gz
7x14-ISO8859-13.pcf.gz
7x14-ISO8859-14.pcf.gz
7x14-ISO8859-15.pcf.gz
7x14-ISO8859-16.pcf.gz
7x14-ISO8859-2.pcf.gz
7x14-ISO8859-3.pcf.gz
7x14-ISO8859-4.pcf.gz
7x14-ISO8859-5.pcf.gz
7x14-ISO8859-7.pcf.gz
7x14-ISO8859-8.pcf.gz
7x14-ISO8859-9.pcf.gz
7x14-JISX0201.1976-0.pcf.gz
7x14-KOI8-R.pcf.gz
7x14.pcf.gz
7x14B-ISO8859-1.pcf.gz
7x14B-ISO8859-10.pcf.gz
7x14B-ISO8859-11.pcf.gz
7x14B-ISO8859-13.pcf.gz
7x14B-ISO8859-14.pcf.gz
7x14B-ISO8859-15.pcf.gz
7x14B-ISO8859-16.pcf.gz
7x14B-ISO8859-2.pcf.gz
7x14B-ISO8859-3.pcf.gz
7x14B-ISO8859-4.pcf.gz
7x14B-ISO8859-5.pcf.gz
7x14B-ISO8859-7.pcf.gz
7x14B-ISO8859-8.pcf.gz
7x14B-ISO8859-9.pcf.gz
7x14B.pcf.gz
8x13-ISO8859-1.pcf.gz
8x13-ISO8859-10.pcf.gz
8x13-ISO8859-13.pcf.gz
8x13-ISO8859-14.pcf.gz
8x13-ISO8859-15.pcf.gz
8x13-ISO8859-16.pcf.gz
8x13-ISO8859-2.pcf.gz
8x13-ISO8859-3.pcf.gz
8x13-ISO8859-4.pcf.gz
8x13-ISO8859-5.pcf.gz
8x13-ISO8859-7.pcf.gz
8x13-ISO8859-8.pcf.gz
8x13-ISO8859-9.pcf.gz
8x13-KOI8-R.pcf.gz
8x13.pcf.gz
8x13B-ISO8859-1.pcf.gz
8x13B-ISO8859-10.pcf.gz
8x13B-ISO8859-13.pcf.gz
8x13B-ISO8859-14.pcf.gz
8x13B-ISO8859-15.pcf.gz
8x13B-ISO8859-16.pcf.gz
8x13B-ISO8859-2.pcf.gz
8x13B-ISO8859-3.pcf.gz
8x13B-ISO8859-4.pcf.gz
8x13B-ISO8859-5.pcf.gz
8x13B-ISO8859-7.pcf.gz
8x13B-ISO8859-8.pcf.gz
8x13B-ISO8859-9.pcf.gz
8x13B.pcf.gz
8x13O-ISO8859-1.pcf.gz
8x13O-ISO8859-10.pcf.gz
8x13O-ISO8859-13.pcf.gz
8x13O-ISO8859-14.pcf.gz
8x13O-ISO8859-15.pcf.gz
8x13O-ISO8859-16.pcf.gz
8x13O-ISO8859-2.pcf.gz
8x13O-ISO8859-3.pcf.gz
8x13O-ISO8859-4.pcf.gz
8x13O-ISO8859-5.pcf.gz
8x13O-ISO8859-7.pcf.gz
8x13O-ISO8859-9.pcf.gz
8x13O.pcf.gz
8x16.pcf.gz
8x16rk.pcf.gz
9x15-ISO8859-1.pcf.gz
9x15-ISO8859-10.pcf.gz
9x15-ISO8859-11.pcf.gz
9x15-ISO8859-13.pcf.gz
9x15-ISO8859-14.pcf.gz
9x15-ISO8859-15.pcf.gz
9x15-ISO8859-16.pcf.gz
9x15-ISO8859-2.pcf.gz
9x15-ISO8859-3.pcf.gz
9x15-ISO8859-4.pcf.gz
9x15-ISO8859-5.pcf.gz
9x15-ISO8859-7.pcf.gz
9x15-ISO8859-8.pcf.gz
9x15-ISO8859-9.pcf.gz
9x15-KOI8-R.pcf.gz
9x15.pcf.gz
9x15B-ISO8859-1.pcf.gz
9x15B-ISO8859-10.pcf.gz
9x15B-ISO8859-11.pcf.gz
9x15B-ISO8859-13.pcf.gz
9x15B-ISO8859-14.pcf.gz
9x15B-ISO8859-15.pcf.gz
9x15B-ISO8859-16.pcf.gz
9x15B-ISO8859-2.pcf.gz
9x15B-ISO8859-3.pcf.gz
9x15B-ISO8859-4.pcf.gz
9x15B-ISO8859-5.pcf.gz
9x15B-ISO8859-7.pcf.gz
9x15B-ISO8859-8.pcf.gz
9x15B-ISO8859-9.pcf.gz
9x15B.pcf.gz
9x18-ISO8859-1.pcf.gz
9x18-ISO8859-10.pcf.gz
9x18-ISO8859-11.pcf.gz
9x18-ISO8859-13.pcf.gz
9x18-ISO8859-14.pcf.gz
9x18-ISO8859-15.pcf.gz
9x18-ISO8859-16.pcf.gz
9x18-ISO8859-2.pcf.gz
9x18-ISO8859-3.pcf.gz
9x18-ISO8859-4.pcf.gz
9x18-ISO8859-5.pcf.gz
9x18-ISO8859-7.pcf.gz
9x18-ISO8859-8.pcf.gz
9x18-ISO8859-9.pcf.gz
9x18-KOI8-R.pcf.gz
9x18.pcf.gz
9x18B-ISO8859-1.pcf.gz
9x18B-ISO8859-10.pcf.gz
9x18B-ISO8859-13.pcf.gz
9x18B-ISO8859-14.pcf.gz
9x18B-ISO8859-15.pcf.gz
9x18B-ISO8859-16.pcf.gz
9x18B-ISO8859-2.pcf.gz
9x18B-ISO8859-3.pcf.gz
9x18B-ISO8859-4.pcf.gz
9x18B-ISO8859-5.pcf.gz
9x18B-ISO8859-7.pcf.gz
9x18B-ISO8859-8.pcf.gz
9x18B-ISO8859-9.pcf.gz
9x18B.pcf.gz
arabic24.pcf.gz
clB6x10.pcf.gz
clB6x12.pcf.gz
clB8x10.pcf.gz
clB8x12.pcf.gz
clB8x13.pcf.gz
clB8x14.pcf.gz
clB8x16.pcf.gz
clB8x8.pcf.gz
clB9x15.pcf.gz
clI6x12.pcf.gz
clI8x8.pcf.gz
clR4x6.pcf.gz
clR5x10.pcf.gz
clR5x6.pcf.gz
clR5x8.pcf.gz
clR6x10.pcf.gz
clR6x12-ISO8859-1.pcf.gz
clR6x12-ISO8859-10.pcf.gz
clR6x12-ISO8859-13.pcf.gz
clR6x12-ISO8859-14.pcf.gz
clR6x12-ISO8859-15.pcf.gz
clR6x12-ISO8859-16.pcf.gz
clR6x12-ISO8859-2.pcf.gz
clR6x12-ISO8859-3.pcf.gz
clR6x12-ISO8859-4.pcf.gz
clR6x12-ISO8859-5.pcf.gz
clR6x12-ISO8859-7.pcf.gz
clR6x12-ISO8859-8.pcf.gz
clR6x12-ISO8859-9.pcf.gz
clR6x12-KOI8-R.pcf.gz
clR6x12.pcf.gz
clR6x13.pcf.gz
clR6x6.pcf.gz
clR6x8.pcf.gz
clR7x10.pcf.gz
clR7x12.pcf.gz
clR7x14.pcf.gz
clR7x8.pcf.gz
clR8x10.pcf.gz
clR8x12.pcf.gz
clR8x13.pcf.gz
clR8x14.pcf.gz
clR8x16.pcf.gz
clR8x8.pcf.gz
clR9x15.pcf.gz
cu-alt12.pcf.gz
cu-arabic12.pcf.gz
cu-devnag12.pcf.gz
cu-lig12.pcf.gz
cu-pua12.pcf.gz
cu12.pcf.gz
cuarabic12.pcf.gz
cudevnag12.pcf.gz
cursor.pcf.gz
deccurs.pcf.gz
decsess.pcf.gz
encodings.dir
fonts.alias
fonts.dir
fonts.list
fonts.scale
gb16fs.pcf.gz
gb16st.pcf.gz
gb24st.pcf.gz
hanglg16.pcf.gz
hanglm16.pcf.gz
hanglm24.pcf.gz
jiskan16.pcf.gz
jiskan24.pcf.gz
k14.pcf.gz
micro.pcf.gz
nil2.pcf.gz
olcursor.pcf.gz
olgl10.pcf.gz
olgl12.pcf.gz
olgl14.pcf.gz
olgl19.pcf.gz

The error from X11.app hasn't change much after installing
fontconfig and running font_cache. This is missing from error
output when I run X11.app now.

/opt/local/bin/font_cache: line 197: /opt/local/bin/fc-cache: No such file or directory
font_cache: Done

Thanks,
Simon
-- 
+ privacy is necessary
+ using http://gnupg.org
+ public key id: 0x6115F804EFB33229
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090131/3ff40bee/attachment-0001.bin>

From illogical1 at gmail.com  Sat Jan 31 16:14:44 2009
From: illogical1 at gmail.com (Orville Bennett)
Date: Sat, 31 Jan 2009 19:14:44 -0500
Subject: nudge: please commit updates to pcb and ng-spice for subsequent
	gEDA port
In-Reply-To: <762596.20831.qm@web59201.mail.re1.yahoo.com>
References: <762596.20831.qm@web59201.mail.re1.yahoo.com>
Message-ID: <2872E9DA-0802-4620-BD47-C4F316EB566D@gmail.com>


On Jan 31, 2009, at 11:10 AM, Nicolas Godbout wrote:

> Hello,
>
> As suggested in the MacPorts guide, I take the liberty to nudge  
> committers on the dev list to process updates for the following  
> ports following a 72 hour grace period:
>
> port pcb : ticket #18172, submitted four days ago.
> has been assigned to the listed maintainer, but is more than likely  
> abandoned.  The current port version dates from almost four years ago.
>
> While you're at it, you can process
> port ng-spice: ticket #18208, submitted only two days ago, but still  
> has not been assigned at all.  This is a 'nomaintainer' port and  
> could be processed immediately by any maintainer.
>
> Sorry for leaning on the side of impatience, but I'm trying to  
> complete a list of ports for the whole gEDA (GPL's Electronic Design  
> Automation) suite and that's a total of about fifteen ports.  Having  
> up-to-date ports for present portions of that suite would be really  
> helpful.
>
> Actually, I'd like to have your opinion on this: the core gEDA  
> package consists of 10 ports that I already have working on my local  
> repository.  Should I:
> 1) open 10 tickets, one for each port submission?
> 2) open 1 ticket with all port files and patches in a compressed file?
> 3) apply first as a port maintainer so that I can also commit all  
> these new packages?
Having recently gone through a similar process and having done steps  
1, 2 and 3, I'd say go with 3. Stuff goes faster that way :-)

>
>
> Your feedback on this would be appreciated.
>
> With my salutations,
>
> Nicolas.
>
>
>       
> __________________________________________________________________
> Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark  
> your favourite sites. Download it now at
> http://ca.toolbar.yahoo.com.
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


From ryandesign at macports.org  Sat Jan 31 16:48:50 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 31 Jan 2009 18:48:50 -0600
Subject: nudge: please commit updates to pcb and ng-spice for subsequent
	gEDA port
In-Reply-To: <762596.20831.qm@web59201.mail.re1.yahoo.com>
References: <762596.20831.qm@web59201.mail.re1.yahoo.com>
Message-ID: <6ACA509D-0B6E-4DEE-B615-0E4D0CE1E1AF@macports.org>

On Jan 31, 2009, at 10:10, Nicolas Godbout wrote:

> As suggested in the MacPorts guide, I take the liberty to nudge  
> committers on the dev list to process updates for the following  
> ports following a 72 hour grace period:
>
> port pcb : ticket #18172, submitted four days ago.
> has been assigned to the listed maintainer, but is more than likely  
> abandoned.  The current port version dates from almost four years ago.
>
> While you're at it, you can process
> port ng-spice: ticket #18208, submitted only two days ago, but  
> still has not been assigned at all.  This is a 'nomaintainer' port  
> and could be processed immediately by any maintainer.
>
> Sorry for leaning on the side of impatience, but I'm trying to  
> complete a list of ports for the whole gEDA (GPL's Electronic  
> Design Automation) suite and that's a total of about fifteen  
> ports.  Having up-to-date ports for present portions of that suite  
> would be really helpful.
>
> Actually, I'd like to have your opinion on this: the core gEDA  
> package consists of 10 ports that I already have working on my  
> local repository.  Should I:
> 1) open 10 tickets, one for each port submission?
> 2) open 1 ticket with all port files and patches in a compressed file?
> 3) apply first as a port maintainer so that I can also commit all  
> these new packages?
>
> Your feedback on this would be appreciated.


It's good practice to file tickets even if you're going to commit  
changes yourself. That way there's not just a record of what you did  
(the commit) but also a thorough explanation of why (the ticket).

As with all new maintainers, we would like to see your portfiles  
before they're added to the tree. That's why we don't necessarily  
grant commit access to new members right away. We would like there to  
be a history of good contributions from you first. Once we see that  
you know how to write portfiles properly that take into account all  
the nuances, then we'll be happy to grant commit access.




From ryandesign at macports.org  Sat Jan 31 19:25:06 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 31 Jan 2009 21:25:06 -0600
Subject: [46213] trunk/dports/net
In-Reply-To: <20090131211849.73E7ADFAA67@beta.macosforge.org>
References: <20090131211849.73E7ADFAA67@beta.macosforge.org>
Message-ID: <AA3CBAE1-44F0-4256-98B4-B5661710AC54@macports.org>

On Jan 31, 2009, at 15:18, snc at macports.org wrote:

> Revision: 46213
>           http://trac.macports.org/changeset/46213
> Author:   snc at macports.org
> Date:     2009-01-31 13:18:44 -0800 (Sat, 31 Jan 2009)
> Log Message:
> -----------
> created net/murmur, #18289
>
> Added Paths:
> -----------
>     trunk/dports/net/murmur/
>     trunk/dports/net/murmur/Portfile
>
> Added: trunk/dports/net/murmur/Portfile
> ===================================================================
> --- trunk/dports/net/murmur/Portfile	                        (rev 0)
> +++ trunk/dports/net/murmur/Portfile	2009-01-31 21:18:44 UTC (rev  
> 46213)
> @@ -0,0 +1,121 @@
> +# -*- coding: utf-8; mode: tcl; tab-width: 4; truncate-lines: t;  
> indent-tabs-mode: nil; c-basic-offset: 4 -*-  
> vim:fenc=utf-8:et:sw=4:ts=4:sts=4
> +# $Id$
> +
> +PortSystem          1.0
> +
> +name                murmur
> +version             1.1.7
> +categories          net audio
> +maintainers         nomaintainer
> +description         server for mumble - low latency voice chat for  
> gaming
> +long_description \
> +    Server component of Mumble - an open source, low-latency, high  
> quality \
> +    voice chat software primarily intended for use while gaming.
> +
> +homepage            http://mumble.sourceforge.net/
> +platforms           macosx
> +
> +master_sites        sourceforge:mumble
> +checksums           md5 5a382d5c065bb264abfe240ca6f03ddc
> +distname            mumble-${version}
> +
> +livecheck.check     regex
> +livecheck.url       ${homepage}
> +livecheck.regex     ">Latest version: (.*?)<"
> +
> +depends_lib \
> +    port:qt4-mac \
> +    port:openssl
> +
> +depends_build \
> +    port:boost
> +
> +configure.cmd       qmake-mac
> +configure.pre_args  CONFIG-=app_bundle CONFIG+=\"
> +configure.post_args \"
> +configure.args      release no-universal no-client no-ice
> +
> +variant universal {
> +    configure.args-delete no-universal
> +}
> +
> +variant ice description "Enable ice support" {
> +    configure.args-delete no-ice
> +    depends_lib-append port:ice-cpp
> +}
> +
> +startupitem.create  yes
> +startupitem.type    launchd
> +startupitem.name    Murmur
> +startupitem.start   "${prefix}/sbin/murmurd -ini ${prefix}/etc/ 
> murmur/murmur.ini"
> +startupitem.stop    "kill -TERM `cat ${prefix}/var/run/murmur/ 
> murmur.pid`"
> +startupitem.pidfile auto "${prefix}/var/run/murmur/murmur.pid"
> +
> +build {
> +    system "cd ${worksrcpath} && make"
> +}

Why override the standard build phase?

> +destroot {
> +    addgroup murmur
> +    adduser murmur gid=[existsgroup murmur] realname=Murmur\ -\  
> Mumble\ Voice\ Chat
> +
> +    set dp      ${destroot}/${prefix}

There should not be a slash before ${prefix} because ${prefix}  
already begins with a slash. (Several occurrences in the portfile.)

> +    set w       ${worksrcpath}
> +
> +    set logdir  ${dp}/var/log/murmur/
> +    set dbdir   ${dp}/var/lib/murmur/
> +    set piddir  ${dp}/var/run/murmur/
> +
> +    xinstall -m 740 -o murmur -g murmur -d \
> +        ${logdir} \
> +        ${dbdir} \
> +        ${piddir}
> +
> +    destroot.keepdirs-append \
> +        ${logdir} \
> +        ${dbdir} \
> +        ${piddir}
> +
> +    file mkdir ${dp}/etc/murmur/
> +    file mkdir ${dp}/sbin/
> +    file mkdir ${dp}/etc/dbus-1/system.d/
> +
> +    file copy ${w}/release/murmurd ${dp}/sbin/murmurd
> +
> +    set conf ${dp}/etc/murmur/murmur.ini
> +    file copy ${w}/scripts/murmur.ini.system ${conf}
> +    system "sed -i '' -e 's,database=.*,database=${prefix}/var/lib/ 
> murmur/murmur.sqlite,' ${conf}"
> +    system "sed -i '' -e 's,pidfile=.*,pidfile=${prefix}/var/run/ 
> murmur/murmur.pid,' ${conf}"
> +    system "sed -i '' -e 's,logfile=.*','logfile=${prefix}/var/log/ 
> murmur/murmur.log,' ${conf}"
> +
> +    if {![variant_isset ice]} {
> +        # This change is made only to avoid confusion. Murmur ignores
> +        # the ice= config option when built without Ice support.
> +        system "sed -i -e 's,ice=,\#ice=,' ${destroot}/${prefix}/ 
> etc/murmur/murmur.ini"
> +    }
> +
> +    set dbusservice ${dp}/etc/dbus-1/system.d/murmur.conf
> +    file copy ${w}/scripts/murmur.conf ${dbusservice}
> +    system "sed -i '' -e 's,user=.*\",user=\"murmur\",' $ 
> {dbusservice}"
> +}
> +
> +pre-install {
> +    set plist ${destroot}/${prefix}/etc/LaunchDaemons/ 
> org.macports.Murmur/org.macports.Murmur.plist
> +    system "sed -i '' -e 's,</dict>,<key>UserName</ 
> key><string>murmur</string></dict>,' ${plist}"
> +}

Could all of these system-sed calls be replaced with reinplace commands?

> +post-install {
> +    ui_msg ""
> +    ui_msg  
> "***************************************************************"
> +    ui_msg "* To set up a password for the SuperUser user on your  
> Murmur"
> +    ui_msg "* server, execute:"
> +    ui_msg "*"
> +    ui_msg "*   ${prefix}/sbin/murmurd -ini ${prefix}/etc/murmur/ 
> murmur.ini -supw \[password\]"
> +    ui_msg "*"
> +    ui_msg "* In case you want to interface with a different  
> database than"
> +    ui_msg "* sqlite, then take a look at the +psql and +mysql5  
> variants of"
> +    ui_msg "* qt4-mac."
> +    ui_msg "*"
> +    ui_msg  
> "***************************************************************"
> +    ui_msg ""
> +}



From ryandesign at macports.org  Sat Jan 31 19:26:58 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 31 Jan 2009 21:26:58 -0600
Subject: [46211] trunk/dports/aqua
In-Reply-To: <20090131211602.0A179DFA987@beta.macosforge.org>
References: <20090131211602.0A179DFA987@beta.macosforge.org>
Message-ID: <A37EBA48-5778-4587-B17E-FEA7BFD01004@macports.org>

On Jan 31, 2009, at 15:16, snc at macports.org wrote:

> Revision: 46211
>           http://trac.macports.org/changeset/46211
> Author:   snc at macports.org
> Date:     2009-01-31 13:16:01 -0800 (Sat, 31 Jan 2009)
> Log Message:
> -----------
> created aqua/mumble, #18289
>
> Added Paths:
> -----------
>     trunk/dports/aqua/mumble/
>     trunk/dports/aqua/mumble/Portfile-mumble

Some of the same comments I sent for murmur:


> Added: trunk/dports/aqua/mumble/Portfile-mumble
> ===================================================================
> --- trunk/dports/aqua/mumble/Portfile- 
> mumble	                        (rev 0)
> +++ trunk/dports/aqua/mumble/Portfile-mumble	2009-01-31 21:16:01  
> UTC (rev 46211)
> @@ -0,0 +1,59 @@
> +# -*- coding: utf-8; mode: tcl; tab-width: 4; truncate-lines: t;  
> indent-tabs-mode: nil; c-basic-offset: 4 -*-  
> vim:fenc=utf-8:et:sw=4:ts=4:sts=4
> +# $Id$
> +
> +PortSystem          1.0
> +
> +name                mumble
> +version             1.1.7
> +categories          aqua audio
> +maintainers         nomaintainer
> +description         low-latency voice chat for gaming
> +long_description \
> +    Mumble is an open source, low-latency, high quality \
> +    voice chat software primarily intended for use while gaming.
> +homepage            http://mumble.sourceforge.net/
> +platforms           macosx
> +
> +master_sites        sourceforge:mumble
> +checksums           md5 5a382d5c065bb264abfe240ca6f03ddc
> +distname            mumble-${version}
> +
> +livecheck.check     regex
> +livecheck.url       ${homepage}
> +livecheck.regex     ">Latest version: (.*?)<"
> +
> +depends_lib \
> +    port:qt4-mac \
> +    port:openssl \
> +    port:portaudio
> +
> +depends_build \
> +    port:boost
> +
> +configure.cmd       qmake-mac
> +configure.pre_args  CONFIG+=\"
> +configure.post_args \" DEFINES+=NO_UPDATE_CHECK
> +configure.args      release no-dbus no-universal no-server
> +
> +variant dbus description {Build DBus support} {
> +    configure.args-delete no-dbus
> +}
> +
> +variant universal {
> +    configure.args-delete no-universal
> +}
> +
> +pre-build {
> +    system "sed -i '' -e 's,a.setLibraryPaths(QStringList 
> ());,a.setLibraryPaths(QStringList(\"${prefix}/libexec/qt4-mac/ 
> plugins\"));,' ${worksrcpath}/src/mumble/main.cpp"
> +}

Can you use reinplace instead?

> +build {
> +    system "cd ${worksrcpath} && make"
> +}

Can you use the standard build phase instead?

> +destroot {
> +    set appPath ${destroot}/Applications/MacPorts

Can you use ${applications_dir} instead of /Applications/MacPorts?

> +    file mkdir ${appPath}
> +    file copy ${worksrcpath}/release/Mumble.app ${appPath}/Mumble.app
> +    file copy ${worksrcpath}/release/plugins ${appPath}/Mumble.app/ 
> Contents/Plugins
> +}





From ryandesign at macports.org  Sat Jan 31 20:48:10 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 31 Jan 2009 22:48:10 -0600
Subject: sh is crashing, errors in szone_malloc, fork
In-Reply-To: <20090123173648.GK1155@darkart.com>
References: <6FFF0EA2-D2C3-40C1-858A-E4BD90246294@macports.org>
	<20090123173648.GK1155@darkart.com>
Message-ID: <FD69B3FF-9215-42FF-81AE-F3A746956D29@macports.org>


On Jan 23, 2009, at 11:36, Eric Hall wrote:

> On Fri, Jan 23, 2009 at 02:15:30AM -0600, Ryan Schmidt wrote:
>
>> I can't install php5 on one of my machines. As a maintainer of php5,
>> this is a bit of a problem. I also can't upgrade libxml2. The error
>> is different everytime but often it's sh that crashes, and often the
>> error message mentions libtool. This is a MacBookPro3,1 with Mac OS X
>> 10.4.11 and MacPorts 1.7.0. I have restarted the computer, I have
>> uninstalled and reinstalled Xcode 2.5, I have uninstalled and
>> reinstalled libtool @2.2.6a_0. From the error messages below, does
>> anyone have any suggestions? I'm not in the mood for an OS reinstall.
>
> 	Have you run a memory check?  Do other things crash
> at random?

Thanks for the suggestion. It does smack of a hardware issue, doesn't  
it? But no, nothing else crashes; only when I compile some things  
with MacPorts. And I ran RAM, processor and logic board tests  
overnight and everything comes up clean.

I had this same problem maybe 6 months ago and found no hardware  
issue then either. I think I ended up uninstalling all of MacPorts  
and reinstalling the ports I used.

Today I was able to narrow the problem down to having gsed @4.1.5_3 
+universal (4-way universal) installed. If I uninstall gsed, or  
install gsed (non-universal), or install gsed+universal (2-way 32-bit  
universal), there is no problem compiling php5 (which I'm not  
compiling universal, by the way). I also reproduced the issues on a  
second computer, a MacBookPro2,2.

I tried switching gsed to the muniversal portgroup but that didn't  
have any effect. So there must be some serious 64-bit issues going on  
in gsed. We should probably switch gsed to the muniversal portgroup  
and list only i386 ppc as the supported architectures, until it can  
build a properly-functioning 64-bit binary. I filed a ticket:

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



From ryandesign at macports.org  Sat Jan 31 21:50:03 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 31 Jan 2009 23:50:03 -0600
Subject: [46178] trunk/dports/archivers
In-Reply-To: <20090131091141.CDFADDED117@beta.macosforge.org>
References: <20090131091141.CDFADDED117@beta.macosforge.org>
Message-ID: <DA6A8109-075C-4D36-B412-AA09D51E33CB@macports.org>


On Jan 31, 2009, at 03:11, illogic-al at macports.org wrote:

> Revision: 46178
>           http://trac.macports.org/changeset/46178
> Author:   illogic-al at macports.org
> Date:     2009-01-31 01:11:38 -0800 (Sat, 31 Jan 2009)
> Log Message:
> -----------
> New portfile libzip. Whatever could that mean?

I don't know. What does that mean?


From akopa.gmane.poster at gmail.com  Sat Jan 31 22:48:07 2009
From: akopa.gmane.poster at gmail.com (Matthew D. Swank)
Date: Sun, 1 Feb 2009 06:48:07 +0000 (UTC)
Subject: =?utf-8?b?dGV4bGl2ZV9iYXNlOg==?= Duplicate symbols in libXt,
	libXaw
References: <49770CD6.7070407@macports.org>
Message-ID: <loom.20090201T064443-774@post.gmane.org>

Joshua Root <jmr at ...> writes:

> 
> Upgrading the outdated ports on a ppc Tiger machine went fine, pulling
> in the new X libs, until it got to texlive_base, which failed

I am also having this problem (Tiger, PPC32). TEX is a reasonably important
package for me; is there another place we should be reporting this?

Matt




From iane at sussex.ac.uk  Fri Jan 30 08:39:28 2009
From: iane at sussex.ac.uk (Ian Eiloart)
Date: Fri, 30 Jan 2009 16:39:28 +0000
Subject: Various questions
In-Reply-To: <5cbbe4ae0901300625r61509ba1p8ef36cdd8b5fb2a9@mail.gmail.com>
References: <1233313159.15944.7.camel@debian>
	<5cbbe4ae0901300625r61509ba1p8ef36cdd8b5fb2a9@mail.gmail.com>
Message-ID: <2D3C00CE7C20D638782134B2@lewes.staff.uscs.susx.ac.uk>



--On 30 January 2009 15:25:40 +0100 "C. Florian Ebeling" 
<florian.ebeling at gmail.com> wrote:

> Hi Jean-Michel,
>
>> * How to become MacPorts maintainer. I checked out the SVN tree. I would
>> like to apply for maintenance of sox, mlt, gavl, frei0r, ladspa-sdk and
>> kdenlive. Please contact me if you need my SSH pub key. I manage
>> kdenlive.org website and you don't have to worry.
>
> The official version of the project rules are in the guide:
> http://guide.macports.org/#project.contributing

Ah, this'll be a spur to action for me.

A couple of years ago, I acquired the handle ianeiloart at macports.org 
However, I was never able to get logged in to trac. That problem seems to 
have gone away. I've also noticed that there is no longer a maintainer for 
the "exim" port, which is my main interest.

Does having the handle mean that I have commit rights?

Is there a beginners guide to making a commit for a single portfile?

If that last question doesn't scare anyone, can I become maintainer of the 
mail/exim and mail/mailman ports, please? I'd also like to create ports for 
libspf2 and dkim libraries.

-- 
Ian Eiloart
IT Services, University of Sussex
x3148