From jmr at macports.org  Sat Nov  1 01:25:04 2008
From: jmr at macports.org (Joshua Root)
Date: Sat, 01 Nov 2008 19:25:04 +1100
Subject: -flat_namespace and -undefined suppress
In-Reply-To: <490AAE9E.5090004@macports.org>
References: <20081031044708.3FA565F8548@beta.macosforge.org>
	<D64C0FAE-D40F-449A-A049-543FCE7C084F@macports.org>
	<490AAE9E.5090004@macports.org>
Message-ID: <490C1260.30401@macports.org>

Joshua Root wrote:
> Before Panther, there was only flat namespace. The dynamic linker always
> loaded symbols from the first-loaded library that defined them.
> 
> Panther introduced two-level namespace, which keeps track of which
> library each symbol is meant to come from. Two-level namespace has been
> the default for a long time now.

A correction: it turns out that two-level namespace was actually first
introduced in Puma (10.1). The relevant feature introduced in Panther is
"-undefined dynamic_lookup", which is now the recommended way to link
plugin-type objects that reference symbols in the executable into which
they will be loaded but are not explicitly linked against it, rather
than using "-flat_namespace -undefined suppress".

Reference:
<http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachOTopics/Articles/executing_files.html>

- Josh

From raimue at macports.org  Sat Nov  1 05:35:18 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 01 Nov 2008 13:35:18 +0100
Subject: fetch.ignore_sslcert yes still checking ssl cert
In-Reply-To: <799406d60810310738x471f155cmd9e0a54b0d6b2f68@mail.gmail.com>
References: <799406d60810251000i2b56c058m8b647ff0ec5240a0@mail.gmail.com>
	<799406d60810310738x471f155cmd9e0a54b0d6b2f68@mail.gmail.com>
Message-ID: <490C4D06.4040006@macports.org>

Adam Mercer wrote:
> Anyone know what's going on here? This isn't as pressing now as I
> asked upstream to distribute the tarballs over both http and https,
> but its still causing a problem with livecheck as the project pages as
> over https?

I just tried it with the master_sites URL you gave in the original mail.
After adding 'fetch.ignore_sslcert yes' the download works for me.

Tested with both 1.6.0 and trunk r41391.

Rainer

From raimue at macports.org  Sat Nov  1 05:39:40 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 01 Nov 2008 13:39:40 +0100
Subject: Retry on checksum failures?
In-Reply-To: <490B560E.20204@macports.org>
References: <490B4AF9.3060203@macports.org>	<20081031183415.GD454@ninagal.withay.com>
	<490B560E.20204@macports.org>
Message-ID: <490C4E0C.5050600@macports.org>

David Evans wrote:
> In addition, it would be nice to have a maintainer tool a bit like
> distcheck that would iterate
> through a ports site list and download and checksum each site to check
> for this sort of problem.

Isn't this exactly what 'port distcheck' does? It is downloading from
all mirrors and checking checksums against the Portfile.

Rainer

From ram at macports.org  Sat Nov  1 09:44:29 2008
From: ram at macports.org (Adam Mercer)
Date: Sat, 1 Nov 2008 11:44:29 -0500
Subject: fetch.ignore_sslcert yes still checking ssl cert
In-Reply-To: <490C4D06.4040006@macports.org>
References: <799406d60810251000i2b56c058m8b647ff0ec5240a0@mail.gmail.com>
	<799406d60810310738x471f155cmd9e0a54b0d6b2f68@mail.gmail.com>
	<490C4D06.4040006@macports.org>
Message-ID: <799406d60811010944y2a9f599ft522c6f82f2eeb690@mail.gmail.com>

On Sat, Nov 1, 2008 at 07:35, Rainer M?ller <raimue at macports.org> wrote:

> I just tried it with the master_sites URL you gave in the original mail.
> After adding 'fetch.ignore_sslcert yes' the download works for me.
>
> Tested with both 1.6.0 and trunk r41391.

Just tried again, and fetch is now working (not sure what I was doing
wrong last time). However livecheck is still causing problems. With
the attached Portfile I get the following when running livecheck:

[ram at cizin metaio]$ sudo port livecheck
Error: cannot check if metaio was updated (peer certificate cannot be
authenticated with known CA certificates)
[ram at cizin metaio]$

Cheers

Adam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Portfile
Type: application/octet-stream
Size: 905 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20081101/94e56790/attachment.obj>

From raimue at macports.org  Sat Nov  1 10:03:31 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 01 Nov 2008 18:03:31 +0100
Subject: fetch.ignore_sslcert yes still checking ssl cert
In-Reply-To: <799406d60811010944y2a9f599ft522c6f82f2eeb690@mail.gmail.com>
References: <799406d60810251000i2b56c058m8b647ff0ec5240a0@mail.gmail.com>	
	<799406d60810310738x471f155cmd9e0a54b0d6b2f68@mail.gmail.com>	
	<490C4D06.4040006@macports.org>
	<799406d60811010944y2a9f599ft522c6f82f2eeb690@mail.gmail.com>
Message-ID: <490C8BE3.5040907@macports.org>

Adam Mercer wrote:
> On Sat, Nov 1, 2008 at 07:35, Rainer M?ller <raimue at macports.org> wrote:
> 
>> I just tried it with the master_sites URL you gave in the original mail.
>> After adding 'fetch.ignore_sslcert yes' the download works for me.
>>
>> Tested with both 1.6.0 and trunk r41391.
> 
> Just tried again, and fetch is now working (not sure what I was doing
> wrong last time). However livecheck is still causing problems. With
> the attached Portfile I get the following when running livecheck:
> 
> [ram at cizin metaio]$ sudo port livecheck
> Error: cannot check if metaio was updated (peer certificate cannot be
> authenticated with known CA certificates)
> [ram at cizin metaio]$

The same with distcheck. Seems like both commands do not honor this
option, but fetch does.

Rainer

From ram at macports.org  Sat Nov  1 10:07:50 2008
From: ram at macports.org (Adam Mercer)
Date: Sat, 1 Nov 2008 12:07:50 -0500
Subject: fetch.ignore_sslcert yes still checking ssl cert
In-Reply-To: <490C8BE3.5040907@macports.org>
References: <799406d60810251000i2b56c058m8b647ff0ec5240a0@mail.gmail.com>
	<799406d60810310738x471f155cmd9e0a54b0d6b2f68@mail.gmail.com>
	<490C4D06.4040006@macports.org>
	<799406d60811010944y2a9f599ft522c6f82f2eeb690@mail.gmail.com>
	<490C8BE3.5040907@macports.org>
Message-ID: <799406d60811011007s28153e30nb210e4d21f105f14@mail.gmail.com>

On Sat, Nov 1, 2008 at 12:03, Rainer M?ller <raimue at macports.org> wrote:

> The same with distcheck. Seems like both commands do not honor this
> option, but fetch does.

Thanks for confirming its not just me. I'll file a ticket.

Cheers

Adam

From raimue at macports.org  Sat Nov  1 10:36:43 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 01 Nov 2008 18:36:43 +0100
Subject: fetch.ignore_sslcert yes still checking ssl cert
In-Reply-To: <799406d60811011007s28153e30nb210e4d21f105f14@mail.gmail.com>
References: <799406d60810251000i2b56c058m8b647ff0ec5240a0@mail.gmail.com>	
	<799406d60810310738x471f155cmd9e0a54b0d6b2f68@mail.gmail.com>	
	<490C4D06.4040006@macports.org>	
	<799406d60811010944y2a9f599ft522c6f82f2eeb690@mail.gmail.com>	
	<490C8BE3.5040907@macports.org>
	<799406d60811011007s28153e30nb210e4d21f105f14@mail.gmail.com>
Message-ID: <490C93AB.1000703@macports.org>

Adam Mercer wrote:
> On Sat, Nov 1, 2008 at 12:03, Rainer M?ller <raimue at macports.org> wrote:
> 
>> The same with distcheck. Seems like both commands do not honor this
>> option, but fetch does.
> 
> Thanks for confirming its not just me. I'll file a ticket.

Please assign the new ticket to me, I am already working on a fix.

Currently only [curl fetch] takes a --ignore-ssl-cert option, so this
needs additional work in pextlib1.0/curl.c.

Rainer

From ryandesign at macports.org  Sat Nov  1 11:39:40 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 1 Nov 2008 13:39:40 -0500
Subject: [41395] trunk/dports/devel/autoconf/Portfile
In-Reply-To: <20081101182913.D9D32603091@beta.macosforge.org>
References: <20081101182913.D9D32603091@beta.macosforge.org>
Message-ID: <0CCA5933-60CE-4F9C-83F2-47E05467A025@macports.org>

On Nov 1, 2008, at 13:29, jmr at macports.org wrote:

> Revision: 41395
>           http://trac.macports.org/changeset/41395
> Author:   jmr at macports.org
> Date:     2008-11-01 11:29:13 -0700 (Sat, 01 Nov 2008)
> Log Message:
> -----------
> autoconf: fix path to perl in dependency
>
> Modified Paths:
> --------------
>     trunk/dports/devel/autoconf/Portfile
>
> Modified: trunk/dports/devel/autoconf/Portfile
> ===================================================================
> --- trunk/dports/devel/autoconf/Portfile	2008-11-01 18:05:23 UTC  
> (rev 41394)
> +++ trunk/dports/devel/autoconf/Portfile	2008-11-01 18:29:13 UTC  
> (rev 41395)
> @@ -31,7 +31,7 @@
>                  sha1 f15e14aa34acf871b47f659ef99a2e6707db4a18 \
>                  rmd160 273448a60bc4dfcfcb3ee455ef012333eeca3256
>
> -depends_lib     path:${prefix}/bin/perl:perl5 \
> +depends_lib     path:bin/perl:perl5 \
>                  port:m4 \
>                  port:help2man

Why remove ${prefix} from the path? That doesn't seem right to me...  
I've always included ${prefix} when defining a path:-style  
dependency. The Guide also shows that the ${prefix} should be there  
in its lone path:-style dependency example:

http://guide.macports.org/#reference.dependencies.types


From jmr at macports.org  Sat Nov  1 12:15:08 2008
From: jmr at macports.org (Joshua Root)
Date: Sun, 02 Nov 2008 06:15:08 +1100
Subject: [41395] trunk/dports/devel/autoconf/Portfile
In-Reply-To: <0CCA5933-60CE-4F9C-83F2-47E05467A025@macports.org>
References: <20081101182913.D9D32603091@beta.macosforge.org>
	<0CCA5933-60CE-4F9C-83F2-47E05467A025@macports.org>
Message-ID: <490CAABC.6070008@macports.org>

Ryan Schmidt wrote:
> On Nov 1, 2008, at 13:29, jmr at macports.org wrote:
> 
>> Revision: 41395
>>           http://trac.macports.org/changeset/41395
>> Author:   jmr at macports.org
>> Date:     2008-11-01 11:29:13 -0700 (Sat, 01 Nov 2008)
>> Log Message:
>> -----------
>> autoconf: fix path to perl in dependency
>>
>> Modified Paths:
>> --------------
>>     trunk/dports/devel/autoconf/Portfile
>>
>> Modified: trunk/dports/devel/autoconf/Portfile
>> ===================================================================
>> --- trunk/dports/devel/autoconf/Portfile    2008-11-01 18:05:23 UTC
>> (rev 41394)
>> +++ trunk/dports/devel/autoconf/Portfile    2008-11-01 18:29:13 UTC
>> (rev 41395)
>> @@ -31,7 +31,7 @@
>>                  sha1 f15e14aa34acf871b47f659ef99a2e6707db4a18 \
>>                  rmd160 273448a60bc4dfcfcb3ee455ef012333eeca3256
>>
>> -depends_lib     path:${prefix}/bin/perl:perl5 \
>> +depends_lib     path:bin/perl:perl5 \
>>                  port:m4 \
>>                  port:help2man
> 
> Why remove ${prefix} from the path? That doesn't seem right to me...
> I've always included ${prefix} when defining a path:-style dependency.
> The Guide also shows that the ${prefix} should be there in its lone
> path:-style dependency example:
> 
> http://guide.macports.org/#reference.dependencies.types

Because I noticed that when I upgraded autoconf, it was trying to
install perl5 despite ${prefix}/bin/perl existing due to perl5.8 being
installed, and I therefore went and read the actual code. :-)

Turns out that depspecs are escaped, so variable substitution is not
performed. Additionally, ${prefix} is prepended to any path that doesn't
start with a slash. So it was actually looking for
/opt/local/\${prefix}/bin/perl.

- Josh

From ryandesign at macports.org  Sat Nov  1 12:34:18 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 1 Nov 2008 14:34:18 -0500
Subject: [41395] trunk/dports/devel/autoconf/Portfile
In-Reply-To: <490CAABC.6070008@macports.org>
References: <20081101182913.D9D32603091@beta.macosforge.org>
	<0CCA5933-60CE-4F9C-83F2-47E05467A025@macports.org>
	<490CAABC.6070008@macports.org>
Message-ID: <F5E3F04C-EC93-42FC-B615-F12AC01A778A@macports.org>

On Nov 1, 2008, at 14:15, Joshua Root wrote:

> Ryan Schmidt wrote:
>
>> On Nov 1, 2008, at 13:29, jmr at macports.org wrote:
>>
>>> Revision: 41395
>>>           http://trac.macports.org/changeset/41395
>>> Author:   jmr at macports.org
>>> Date:     2008-11-01 11:29:13 -0700 (Sat, 01 Nov 2008)
>>> Log Message:
>>> -----------
>>> autoconf: fix path to perl in dependency
>>>
>>> Modified Paths:
>>> --------------
>>>     trunk/dports/devel/autoconf/Portfile
>>>
>>> Modified: trunk/dports/devel/autoconf/Portfile
>>> ===================================================================
>>> --- trunk/dports/devel/autoconf/Portfile    2008-11-01 18:05:23 UTC
>>> (rev 41394)
>>> +++ trunk/dports/devel/autoconf/Portfile    2008-11-01 18:29:13 UTC
>>> (rev 41395)
>>> @@ -31,7 +31,7 @@
>>>                  sha1 f15e14aa34acf871b47f659ef99a2e6707db4a18 \
>>>                  rmd160 273448a60bc4dfcfcb3ee455ef012333eeca3256
>>>
>>> -depends_lib     path:${prefix}/bin/perl:perl5 \
>>> +depends_lib     path:bin/perl:perl5 \
>>>                  port:m4 \
>>>                  port:help2man
>>
>> Why remove ${prefix} from the path? That doesn't seem right to me...
>> I've always included ${prefix} when defining a path:-style  
>> dependency.
>> The Guide also shows that the ${prefix} should be there in its lone
>> path:-style dependency example:
>>
>> http://guide.macports.org/#reference.dependencies.types
>
> Because I noticed that when I upgraded autoconf, it was trying to
> install perl5 despite ${prefix}/bin/perl existing due to perl5.8 being
> installed, and I therefore went and read the actual code. :-)
>
> Turns out that depspecs are escaped, so variable substitution is not
> performed. Additionally, ${prefix} is prepended to any path that  
> doesn't
> start with a slash. So it was actually looking for
> /opt/local/\${prefix}/bin/perl.

Well, the documentation shows that the path should start with $ 
{prefix} if that's what's meant. Such usage is easily understandable.  
Auto-prepending ${prefix} for non-absolute paths is a convenience,  
and one which is not documented, and which until your change to  
autoconf was not used by any port [1]. We could document it and begin  
using it. But lack of variable substitution in depspecs must be a  
bug. As of r41396, we have 206 occurrences of "path:${prefix}" in the  
ports tree [2]. There are also several depspecs that expect variable  
substitution of variables other than ${prefix} [3].

So I think it would be easier and better to fix the base code to  
match the documentation, rather than change the documentation and all  
the affected ports.


[1] grep 'path:[^$ /]' */*/Portfile

[2] grep 'path:${prefix}' */*/Portfile

[3] grep 'path:\$' */*/Portfile | grep -v 'path:${prefix}'




From jmr at macports.org  Sat Nov  1 12:46:11 2008
From: jmr at macports.org (Joshua Root)
Date: Sun, 02 Nov 2008 06:46:11 +1100
Subject: [41395] trunk/dports/devel/autoconf/Portfile
In-Reply-To: <F5E3F04C-EC93-42FC-B615-F12AC01A778A@macports.org>
References: <20081101182913.D9D32603091@beta.macosforge.org>
	<0CCA5933-60CE-4F9C-83F2-47E05467A025@macports.org>
	<490CAABC.6070008@macports.org>
	<F5E3F04C-EC93-42FC-B615-F12AC01A778A@macports.org>
Message-ID: <490CB203.80106@macports.org>

Ryan Schmidt wrote:
> Well, the documentation shows that the path should start with ${prefix}
> if that's what's meant. Such usage is easily understandable.
> Auto-prepending ${prefix} for non-absolute paths is a convenience, and
> one which is not documented, and which until your change to autoconf was
> not used by any port [1]. We could document it and begin using it. But
> lack of variable substitution in depspecs must be a bug. As of r41396,
> we have 206 occurrences of "path:${prefix}" in the ports tree [2]. There
> are also several depspecs that expect variable substitution of variables
> other than ${prefix} [3].
> 
> So I think it would be easier and better to fix the base code to match
> the documentation, rather than change the documentation and all the
> affected ports.

We can try to fix it for 1.7, but as of right now it's broken in both
1.6.0 and trunk. Autoconf was an immediate problem because the
dependency had been switched from perl5.8 to perl5, and the bad path
made the upgrade break.

- Josh

From devans at macports.org  Sat Nov  1 13:08:03 2008
From: devans at macports.org (David Evans)
Date: Sat, 01 Nov 2008 13:08:03 -0700
Subject: Retry on checksum failures?
In-Reply-To: <490C4E0C.5050600@macports.org>
References: <490B4AF9.3060203@macports.org>	<20081031183415.GD454@ninagal.withay.com>
	<490B560E.20204@macports.org> <490C4E0C.5050600@macports.org>
Message-ID: <490CB723.3050106@macports.org>

Rainer M?ller wrote:
> David Evans wrote:
>   
>> In addition, it would be nice to have a maintainer tool a bit like
>> distcheck that would iterate
>> through a ports site list and download and checksum each site to check
>> for this sort of problem.
>>     
>
> Isn't this exactly what 'port distcheck' does? It is downloading from
> all mirrors and checking checksums against the Portfile.
>
> Rainer
>
>   
According to the guide:

Distcheck reports whether or not the distfile(s) specified in a Portfile
are still available on the developer's download site.

And it says that the default for distcheck.check is "moddate".  So my
undertanding is that it attempts to fetch the moddate for the file which
allows it to test if the site if available and the file exists and that
it is older than
the Portfile.

In the case of the problem site that I cited originally, distcheck
returned a warning that the target file was
newer than the Portfile.

On the other hand, now that I am reading this section of the guide, I
see that livecheck has a livecheck.md5
variable to specify an md5 comparison on thel ivecheck.url.   So if I
set the livecheck.url to the actual
distribution file url and set the livecheck.md5 to its md5 checksum then
maybe I would get some like what
I am looking for. However, livecheck only allows a single URL.

What I was looking for was a maintainer command (or even external
utility) that would essentially do
the fetch and checksum phases iteratively for each site in master_sites
and report any errors as a
warning message. 

Dave



From ryandesign at macports.org  Sat Nov  1 13:29:09 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 1 Nov 2008 15:29:09 -0500
Subject: Retry on checksum failures?
In-Reply-To: <490CB723.3050106@macports.org>
References: <490B4AF9.3060203@macports.org>	<20081031183415.GD454@ninagal.withay.com>
	<490B560E.20204@macports.org> <490C4E0C.5050600@macports.org>
	<490CB723.3050106@macports.org>
Message-ID: <61BA1B3C-EA4A-4B0E-ADF7-ADE72E12E9E1@macports.org>

On Nov 1, 2008, at 15:08, David Evans wrote:

> On the other hand, now that I am reading this section of the guide, I
> see that livecheck has a livecheck.md5
> variable to specify an md5 comparison on thel ivecheck.url.   So if I
> set the livecheck.url to the actual
> distribution file url and set the livecheck.md5 to its md5 checksum  
> then
> maybe I would get some like what
> I am looking for. However, livecheck only allows a single URL.

Using livecheck.md5 and setting livecheck.url to the distfile is not  
a good idea, because MacPorts has to download the indicated file in  
its entirety before it can compute its checksum. That means every  
time you or anyone else livechecks the port, a huge wasteful download  
has to take place. Find an HTML page or other small file to download  
instead.

> What I was looking for was a maintainer command (or even external
> utility) that would essentially do
> the fetch and checksum phases iteratively for each site in  
> master_sites
> and report any errors as a
> warning message.

I don't know if distcheck does this; I haven't used that command. But  
I did write a script to do this for ImageMagick, which has been  
notorious for having different files on different servers.


From raimue at macports.org  Sat Nov  1 13:39:38 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 01 Nov 2008 21:39:38 +0100
Subject: Retry on checksum failures?
In-Reply-To: <490CB723.3050106@macports.org>
References: <490B4AF9.3060203@macports.org>	<20081031183415.GD454@ninagal.withay.com>
	<490B560E.20204@macports.org> <490C4E0C.5050600@macports.org>
	<490CB723.3050106@macports.org>
Message-ID: <490CBE8A.3060301@macports.org>

David Evans wrote:
> According to the guide:
> 
> Distcheck reports whether or not the distfile(s) specified in a Portfile
> are still available on the developer's download site.
> 
> And it says that the default for distcheck.check is "moddate".  So my
> undertanding is that it attempts to fetch the moddate for the file which
> allows it to test if the site if available and the file exists and that
> it is older than
> the Portfile.

You are right. Sorry, I was mistakenly assuming it is also comparing
checksums...

[...]
> What I was looking for was a maintainer command (or even external
> utility) that would essentially do
> the fetch and checksum phases iteratively for each site in master_sites
> and report any errors as a
> warning message. 

So I suppose we should extend distcheck to also generate and compare
distcheck. I don't think an external tool would be easy to write, since
it would only work for fetch.type == "standard".

Rainer

From devans at macports.org  Sat Nov  1 14:07:18 2008
From: devans at macports.org (David Evans)
Date: Sat, 01 Nov 2008 14:07:18 -0700
Subject: Update on instance of gimp2 checksum failure
In-Reply-To: <490CB723.3050106@macports.org>
References: <490B4AF9.3060203@macports.org>	<20081031183415.GD454@ninagal.withay.com>	<490B560E.20204@macports.org>
	<490C4E0C.5050600@macports.org> <490CB723.3050106@macports.org>
Message-ID: <490CC506.5070104@macports.org>

As a follow up, it turns out the site in question[1] is broken and
redirects to
the sites home page when trying to access the url of the distribution. 
So the
checksums returned were for this home page. 

GIMP developers have removed the site from their SVN although this will not
be reflected on their home page for a while.

So nothing sinister at work here.

Dave

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

From devans at macports.org  Sat Nov  1 14:22:30 2008
From: devans at macports.org (David Evans)
Date: Sat, 01 Nov 2008 14:22:30 -0700
Subject: [41395] trunk/dports/devel/autoconf/Portfile
In-Reply-To: <20081101182913.D9D32603091@beta.macosforge.org>
References: <20081101182913.D9D32603091@beta.macosforge.org>
Message-ID: <490CC896.80809@macports.org>

jmr at macports.org wrote:
>
> Revision
>     41395 <http://trac.macports.org/changeset/41395>
> Author
>     jmr at macports.org
> Date
>     2008-11-01 11:29:13 -0700 (Sat, 01 Nov 2008)
>
>
>       Log Message
>
> autoconf: fix path to perl in dependency
>
>
>       Modified Paths
>
>     * trunk/dports/devel/autoconf/Portfile
>       <#trunkdportsdevelautoconfPortfile>
>
>
>       Diff
>
>
>         Modified: trunk/dports/devel/autoconf/Portfile (41394 => 41395)
>
>
> --- trunk/dports/devel/autoconf/Portfile	2008-11-01 18:05:23 UTC (rev 41394)
> +++ trunk/dports/devel/autoconf/Portfile	2008-11-01 18:29:13 UTC (rev 41395)
> @@ -31,7 +31,7 @@
>                  sha1 f15e14aa34acf871b47f659ef99a2e6707db4a18 \
>                  rmd160 273448a60bc4dfcfcb3ee455ef012333eeca3256
>  
> -depends_lib     path:${prefix}/bin/perl:perl5 \
> +depends_lib     path:bin/perl:perl5 \
>                  port:m4 \
>                  port:help2man
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> macports-changes mailing list
> macports-changes at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes
>   
Something not right here.  I just tried upgrading autoconf and even
though the path
/opt/local/bin/perl exists (because perl5.8 is installed), port perl5
was built but activation
failed because of the conflict with perl5.8.


From devans at macports.org  Sat Nov  1 14:27:06 2008
From: devans at macports.org (David Evans)
Date: Sat, 01 Nov 2008 14:27:06 -0700
Subject: Retry on checksum failures?
In-Reply-To: <490CBE8A.3060301@macports.org>
References: <490B4AF9.3060203@macports.org>	<20081031183415.GD454@ninagal.withay.com>
	<490B560E.20204@macports.org> <490C4E0C.5050600@macports.org>
	<490CB723.3050106@macports.org> <490CBE8A.3060301@macports.org>
Message-ID: <490CC9AA.4040502@macports.org>

Rainer M?ller wrote:
> David Evans wrote:
>   
>> According to the guide:
>>
>> Distcheck reports whether or not the distfile(s) specified in a Portfile
>> are still available on the developer's download site.
>>
>> And it says that the default for distcheck.check is "moddate".  So my
>> undertanding is that it attempts to fetch the moddate for the file which
>> allows it to test if the site if available and the file exists and that
>> it is older than
>> the Portfile.
>>     
>
> You are right. Sorry, I was mistakenly assuming it is also comparing
> checksums...
>
> [...]
>   
>> What I was looking for was a maintainer command (or even external
>> utility) that would essentially do
>> the fetch and checksum phases iteratively for each site in master_sites
>> and report any errors as a
>> warning message. 
>>     
>
> So I suppose we should extend distcheck to also generate and compare
> distcheck. I don't think an external tool would be easy to write, since
> it would only work for fetch.type == "standard".
>
> Rainer
>
>   
How about adding a value for distcheck.check of "checksum" that would
provide this functionality
so there is a choice?  As some pointed out, this can be a very heavy
operation for large distributions
with many sites.

Dave

From jmr at macports.org  Sat Nov  1 14:31:37 2008
From: jmr at macports.org (Joshua Root)
Date: Sun, 02 Nov 2008 08:31:37 +1100
Subject: Retry on checksum failures?
In-Reply-To: <490CC9AA.4040502@macports.org>
References: <490B4AF9.3060203@macports.org>	<20081031183415.GD454@ninagal.withay.com>	<490B560E.20204@macports.org>
	<490C4E0C.5050600@macports.org>	<490CB723.3050106@macports.org>
	<490CBE8A.3060301@macports.org> <490CC9AA.4040502@macports.org>
Message-ID: <490CCAB9.9090106@macports.org>

David Evans wrote:
> Rainer M?ller wrote:
>> So I suppose we should extend distcheck to also generate and compare
>> distcheck. I don't think an external tool would be easy to write, since
>> it would only work for fetch.type == "standard".
>>
>> Rainer
>>
>>   
> How about adding a value for distcheck.check of "checksum" that would
> provide this functionality
> so there is a choice?  As some pointed out, this can be a very heavy
> operation for large distributions
> with many sites.

Or perhaps an option like --checksum for distcheck.

- Josh

From jmr at macports.org  Sat Nov  1 14:33:33 2008
From: jmr at macports.org (Joshua Root)
Date: Sun, 02 Nov 2008 08:33:33 +1100
Subject: [41395] trunk/dports/devel/autoconf/Portfile
In-Reply-To: <490CC84C.4010709@orindasoftware.com>
References: <20081101182913.D9D32603091@beta.macosforge.org>
	<490CC84C.4010709@orindasoftware.com>
Message-ID: <490CCB2D.4080906@macports.org>

David Evans wrote:
> Something not right here.  I just tried upgrading autoconf and even
> though the path
> /opt/local/bin/perl exists (because perl5.8 is installed), port perl5
> was built but activation
> failed because of the conflict with perl5.8.  

That's the problem that my change fixed. Is your PortIndex up to date?
That's where upgrade gets the depspecs.

- Josh

From ram at macports.org  Sat Nov  1 14:45:32 2008
From: ram at macports.org (Adam Mercer)
Date: Sat, 1 Nov 2008 16:45:32 -0500
Subject: [41362] trunk/dports/science/libframe/Portfile
In-Reply-To: <DA29C782-2E57-49D5-81E0-C20AFCE0C2D0@macports.org>
References: <20081031162816.599505FB4BE@beta.macosforge.org>
	<DA29C782-2E57-49D5-81E0-C20AFCE0C2D0@macports.org>
Message-ID: <799406d60811011445k4811315cye5b70742eeec010e@mail.gmail.com>

On Fri, Oct 31, 2008 at 20:07, Ryan Schmidt <ryandesign at macports.org> wrote:

> Why were the checksums wrong?

Due to changes on the upstream server I am now getting the tarball
from a different location. This tarball has some minor differences to
the build scripts (one used automake-1.9.5 and the other used
automake-1.9.6). Apart from that there are no changes to source, they
are both created from the same CVS tag, and the installed product is
identical. Due to this I thought that it would be better not to force
a rebuild by bumping the revision and modifying the dist_subdir when
the installed products are identical. I have contacted upstream to
clarify this issue and why there are two slightly different tarballs.

Although if you think it would be better to bump the revision etc...
I'll do that?

Cheers

Adam

From devans at macports.org  Sat Nov  1 14:53:33 2008
From: devans at macports.org (David Evans)
Date: Sat, 01 Nov 2008 14:53:33 -0700
Subject: [41395] trunk/dports/devel/autoconf/Portfile
In-Reply-To: <490CCB2D.4080906@macports.org>
References: <20081101182913.D9D32603091@beta.macosforge.org>
	<490CC84C.4010709@orindasoftware.com>
	<490CCB2D.4080906@macports.org>
Message-ID: <490CCFDD.5080409@macports.org>

Joshua Root wrote:
> David Evans wrote:
>   
>> Something not right here.  I just tried upgrading autoconf and even
>> though the path
>> /opt/local/bin/perl exists (because perl5.8 is installed), port perl5
>> was built but activation
>> failed because of the conflict with perl5.8.  
>>     
>
> That's the problem that my change fixed. Is your PortIndex up to date?
> That's where upgrade gets the depspecs.
>
> - Josh
>
>   
Well, learned something new.  Yes, the Portfile had your fix but the
PortIndex hadn't regenerated yet.  I'll revert the autoconf installation
and check again, but I suspect that it isn't a problem.

Sorry.

Dave


From devans at macports.org  Sat Nov  1 15:02:06 2008
From: devans at macports.org (David Evans)
Date: Sat, 01 Nov 2008 15:02:06 -0700
Subject: Retry on checksum failures?
In-Reply-To: <490CCAB9.9090106@macports.org>
References: <490B4AF9.3060203@macports.org>	<20081031183415.GD454@ninagal.withay.com>	<490B560E.20204@macports.org>
	<490C4E0C.5050600@macports.org>	<490CB723.3050106@macports.org>
	<490CBE8A.3060301@macports.org> <490CC9AA.4040502@macports.org>
	<490CCAB9.9090106@macports.org>
Message-ID: <490CD1DE.3080006@macports.org>

Joshua Root wrote:
> David Evans wrote:
>   
>> Rainer M?ller wrote:
>>     
>>> So I suppose we should extend distcheck to also generate and compare
>>> distcheck. I don't think an external tool would be easy to write, since
>>> it would only work for fetch.type == "standard".
>>>
>>> Rainer
>>>
>>>   
>>>       
>> How about adding a value for distcheck.check of "checksum" that would
>> provide this functionality
>> so there is a choice?  As some pointed out, this can be a very heavy
>> operation for large distributions
>> with many sites.
>>     
>
> Or perhaps an option like --checksum for distcheck.
>
> - Josh
>
>   
Actually, I like this best.  Due to the cost of doing this check, I can
only see myself wanting to do this
in the following cases:

1) on initial creation of a Portfile
2) when adding new sites to master_sites
3) when the normal distcheck (moddate mode) indicates that a
distribution file is newer than the Portfile.

Dave

From devans at macports.org  Sat Nov  1 16:21:54 2008
From: devans at macports.org (David Evans)
Date: Sat, 01 Nov 2008 16:21:54 -0700
Subject: [41395] trunk/dports/devel/autoconf/Portfile
In-Reply-To: <490CCB2D.4080906@macports.org>
References: <20081101182913.D9D32603091@beta.macosforge.org>	<490CC84C.4010709@orindasoftware.com>
	<490CCB2D.4080906@macports.org>
Message-ID: <490CE492.7020808@macports.org>

Joshua Root wrote:
> David Evans wrote:
>   
>> Something not right here.  I just tried upgrading autoconf and even
>> though the path
>> /opt/local/bin/perl exists (because perl5.8 is installed), port perl5
>> was built but activation
>> failed because of the conflict with perl5.8.  
>>     
>
> That's the problem that my change fixed. Is your PortIndex up to date?
> That's where upgrade gets the depspecs.
>   
After syncing to get the new Portindex, I reverted back to the
previously built autoconf @2.62_0.

As a result of the previous upgrade attempt, I now have two versions of
perl installed as follows:

  perl5 @5.8.8_0
  perl5.8 @5.8.8_3+darwin_8 (active)

Upon attempting to upgrade to autoconf @2.63_0, port decided to try and
activate perl5 since it is installed rather than go with the perl5.8
that was already active. Of course, this didn't work.

So the dependency

depends_lib path:bin/perl:perl5

seems to mean: "use perl5 if you have it installed (even if it isn't
active) but if it's not installed don't install it if the specified path
exists."

I'm not sure what the agenda is with the new perl5 port but if the idea
is to eventually replace port perl5.8 with it then ports that depend on
perl5.8 shouldn't be changed to perl5 (even with a path dependency)
until we're ready for the switch and then change the dependencies in all
effected ports at once.

Looks like doing this piecemeal won't work since you can't have perl5
installed for some and perl5.8 installed for others.

Dave

From opendarwin.org at darkart.com  Sat Nov  1 19:49:46 2008
From: opendarwin.org at darkart.com (Eric Hall)
Date: Sun, 2 Nov 2008 02:49:46 +0000
Subject: [41395] trunk/dports/devel/autoconf/Portfile
In-Reply-To: <490CE492.7020808@macports.org>
References: <20081101182913.D9D32603091@beta.macosforge.org>
	<490CC84C.4010709@orindasoftware.com>
	<490CCB2D.4080906@macports.org> <490CE492.7020808@macports.org>
Message-ID: <20081102024946.GW13985@darkart.com>

On Sat, Nov 01, 2008 at 04:21:54PM -0700, David Evans wrote:
> 
> I'm not sure what the agenda is with the new perl5 port but if the idea
> is to eventually replace port perl5.8 with it then ports that depend on
> perl5.8 shouldn't be changed to perl5 (even with a path dependency)
> until we're ready for the switch and then change the dependencies in all
> effected ports at once.
> 
> Looks like doing this piecemeal won't work since you can't have perl5
> installed for some and perl5.8 installed for others.
> 

	Why do we have a perl5 port alongside the perl5.8 and perl5.10
ports?  If its breaking things it seems to me we shouldn't have a plain
'perl5' port until we're ready to make an proper switch to it.


		-eric


From mcalhoun at macports.org  Sat Nov  1 20:16:42 2008
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Sun, 2 Nov 2008 03:16:42 +0000 (UTC)
Subject: [41395] trunk/dports/devel/autoconf/Portfile
References: <20081101182913.D9D32603091@beta.macosforge.org>
	<490CC84C.4010709@orindasoftware.com>
	<490CCB2D.4080906@macports.org> <490CE492.7020808@macports.org>
	<20081102024946.GW13985@darkart.com>
Message-ID: <loom.20081102T031023-32@post.gmane.org>

Eric Hall <opendarwin.org at ...> writes:
>  
> 	Why do we have a perl5 port alongside the perl5.8 and perl5.10
> ports?  If its breaking things it seems to me we shouldn't have a plain
> 'perl5' port until we're ready to make an proper switch to it.
> 
> 		-eric
> 
> 

Both the perl5 creation and the autoconf unpleasantness were my doing.
My apologies for any problems, but I am glad to now know the correct use
of path dependencies.
Thanks for the fix.

The rationale for perl5 is documented in #16830
(http://trac.macports.org/ticket/16830).

I still think a piecemeal transition is possible with the correct use of
path dependencies.
A proper switch would have to wait until the next version of MacPorts
because perl5-1.0.tcl depends on perl5.8.

-Marcus




From ryandesign at macports.org  Sat Nov  1 20:17:02 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 1 Nov 2008 22:17:02 -0500
Subject: [41395] trunk/dports/devel/autoconf/Portfile
In-Reply-To: <20081102024946.GW13985@darkart.com>
References: <20081101182913.D9D32603091@beta.macosforge.org>
	<490CC84C.4010709@orindasoftware.com>
	<490CCB2D.4080906@macports.org> <490CE492.7020808@macports.org>
	<20081102024946.GW13985@darkart.com>
Message-ID: <57E39713-882F-4AAE-9026-E41CD57FC2D9@macports.org>


On Nov 1, 2008, at 21:49, Eric Hall wrote:

> Why do we have a perl5 port alongside the perl5.8 and perl5.10
> ports?  If its breaking things it seems to me we shouldn't have a  
> plain
> 'perl5' port until we're ready to make an proper switch to it.

For this reason:

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




From opendarwin.org at darkart.com  Sat Nov  1 21:35:40 2008
From: opendarwin.org at darkart.com (Eric Hall)
Date: Sun, 2 Nov 2008 04:35:40 +0000
Subject: [41395] trunk/dports/devel/autoconf/Portfile
In-Reply-To: <57E39713-882F-4AAE-9026-E41CD57FC2D9@macports.org>
References: <20081101182913.D9D32603091@beta.macosforge.org>
	<490CC84C.4010709@orindasoftware.com>
	<490CCB2D.4080906@macports.org> <490CE492.7020808@macports.org>
	<20081102024946.GW13985@darkart.com>
	<57E39713-882F-4AAE-9026-E41CD57FC2D9@macports.org>
Message-ID: <20081102043540.GX13985@darkart.com>

On Sat, Nov 01, 2008 at 10:17:02PM -0500, Ryan Schmidt wrote:
> 
> On Nov 1, 2008, at 21:49, Eric Hall wrote:
> 
> >Why do we have a perl5 port alongside the perl5.8 and perl5.10
> >ports?  If its breaking things it seems to me we shouldn't have a  
> >plain
> >'perl5' port until we're ready to make an proper switch to it.
> 
> For this reason:
> 
> http://trac.macports.org/ticket/16830
> 

	I agree, we need to fix it.  I don't think we should
install something that breaks ports until we're ready to make
a clean cutover.  If its not breaking ports all good.


		-eric


From neric27 at wanadoo.fr  Sun Nov  2 11:42:25 2008
From: neric27 at wanadoo.fr (Eric)
Date: Sun, 02 Nov 2008 20:42:25 +0100
Subject: [MacPorts] #16738: transmission-x11 1.34 : new release
In-Reply-To: <063.54ff9556b121e83bdc064e8c3355b3d0@macports.org>
References: <054.f5ea28bbae428f938dec1c6361ea0256@macports.org>
	<063.54ff9556b121e83bdc064e8c3355b3d0@macports.org>
Message-ID: <490E02A1.8080804@wanadoo.fr>

As per a previous thread, I thought we had agreed to remove the aqua
variant altogether.
At least, someone with Leopard should try to build it with aquat variant
set, as I can't do it myself.

Cheers,


MacPorts a ?crit :
> #16738: transmission-x11 1.34 : new release
> ---------------------------------+------------------------------------------
>   Reporter:  neric27 at wanadoo.fr  |       Owner:  macports-tickets at lists.macosforge.org
>       Type:  enhancement         |      Status:  closed                               
>   Priority:  Normal              |   Milestone:  Port Updates                         
>  Component:  ports               |     Version:  1.6.0                                
> Resolution:  fixed               |    Keywords:                                       
>       Port:  transmission-x11    |  
> ---------------------------------+------------------------------------------
> Changes (by macsforever2000 at macports.org):
>
>   * status:  new => closed
>   * resolution:  => fixed
>
>
> Comment:
>
>  I'm closing this ticket. The port appears to have been updated by revision
>  r40957.
>
>   


From frstan at bellsouth.net  Sun Nov  2 13:26:34 2008
From: frstan at bellsouth.net (William Davis)
Date: Sun, 2 Nov 2008 16:26:34 -0500
Subject: [MacPorts] #16738: transmission-x11 1.34 : new release
In-Reply-To: <490E02A1.8080804@wanadoo.fr>
References: <054.f5ea28bbae428f938dec1c6361ea0256@macports.org>
	<063.54ff9556b121e83bdc064e8c3355b3d0@macports.org>
	<490E02A1.8080804@wanadoo.fr>
Message-ID: <FD72C85D-3D1E-4D8F-AB4D-1B1F89C4F738@bellsouth.net>

On Leopard transmission-x11 build just fine right dow to start of  
activate phase. Ill report back on that shortly
WD
On Nov 2, 2008, at 2:42 PM, Eric wrote:

> As per a previous thread, I thought we had agreed to remove the aqua
> variant altogether.
> At least, someone with Leopard should try to build it with aquat  
> variant
> set, as I can't do it myself.
>
> Cheers,
>
>
> MacPorts a ?crit :
>> #16738: transmission-x11 1.34 : new release
>> --------------------------------- 
>> +------------------------------------------
>>  Reporter:  neric27 at wanadoo.fr  |       Owner:  macports-tickets at lists.macosforge.org
>>      Type:  enhancement         |      Status:  closed
>>  Priority:  Normal              |   Milestone:  Port Updates
>> Component:  ports               |     Version:  1.6.0
>> Resolution:  fixed               |    Keywords:
>>      Port:  transmission-x11    |
>> --------------------------------- 
>> +------------------------------------------
>> Changes (by macsforever2000 at macports.org):
>>
>>  * status:  new => closed
>>  * resolution:  => fixed
>>
>>
>> Comment:
>>
>> I'm closing this ticket. The port appears to have been updated by  
>> revision
>> r40957.
>>
>>
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


From n.oxyde at gmail.com  Wed Nov  5 03:09:32 2008
From: n.oxyde at gmail.com (nox)
Date: Wed, 5 Nov 2008 12:09:32 +0100
Subject: [41517] trunk/dports/x11/gtk2/Portfile
In-Reply-To: <20081105105533.E47246253DB@beta.macosforge.org>
References: <20081105105533.E47246253DB@beta.macosforge.org>
Message-ID: <4F4F6082-7C87-4586-B403-9EEE3E8B7AAB@gmail.com>

Le 5 nov. 08 ? 11:55, devans at macports.org a ?crit :

> Revision41517Authordevans at macports.orgDate2008-11-05 02:55:31 -0800  
> (Wed, 05 Nov 2008)Log Message
> gtk2: fix +no_x11 build failure on Tiger.  See #16978.
> Modified Paths
> 	? trunk/dports/x11/gtk2/Portfile
> Diff
> Modified: trunk/dports/x11/gtk2/Portfile (41516 => 41517)
> --- trunk/dports/x11/gtk2/Portfile	2008-11-05 10:30:42 UTC (rev 41516)
> +++ trunk/dports/x11/gtk2/Portfile	2008-11-05 10:55:31 UTC (rev 41517)
> @@ -107,6 +107,12 @@
>      depends_build-append    port:cups-headers
>  }
>
> +platform darwin 8 {
> +    if {[variant_isset quartz] || [variant_isset no_x11]} {
> +        configure.env-append   LDFLAGS="-framework Cocoa -framework  
> Carbon"
> +    }
> +}
> +
>  variant no_x11 description {Same as +quartz} {
>      pre-fetch {
>          if {[file exists ${prefix}/lib/libpangox-1.0.dylib]} {

configure.ldflags-append -framework Cocoa -framework Carbon seems more  
appropriate, doesn't it?

From devans at macports.org  Wed Nov  5 04:03:18 2008
From: devans at macports.org (David Evans)
Date: Wed, 05 Nov 2008 04:03:18 -0800
Subject: [41517] trunk/dports/x11/gtk2/Portfile
In-Reply-To: <4F4F6082-7C87-4586-B403-9EEE3E8B7AAB@gmail.com>
References: <20081105105533.E47246253DB@beta.macosforge.org>
	<4F4F6082-7C87-4586-B403-9EEE3E8B7AAB@gmail.com>
Message-ID: <49118B86.8000801@macports.org>

nox wrote:
> Le 5 nov. 08 ? 11:55, devans at macports.org a ?crit :
>
>> Revision41517Authordevans at macports.orgDate2008-11-05 02:55:31 -0800
>> (Wed, 05 Nov 2008)Log Message
>> gtk2: fix +no_x11 build failure on Tiger.  See #16978.
>> Modified Paths
>>     ? trunk/dports/x11/gtk2/Portfile
>> Diff
>> Modified: trunk/dports/x11/gtk2/Portfile (41516 => 41517)
>> --- trunk/dports/x11/gtk2/Portfile    2008-11-05 10:30:42 UTC (rev
>> 41516)
>> +++ trunk/dports/x11/gtk2/Portfile    2008-11-05 10:55:31 UTC (rev
>> 41517)
>> @@ -107,6 +107,12 @@
>>      depends_build-append    port:cups-headers
>>  }
>>
>> +platform darwin 8 {
>> +    if {[variant_isset quartz] || [variant_isset no_x11]} {
>> +        configure.env-append   LDFLAGS="-framework Cocoa -framework
>> Carbon"
>> +    }
>> +}
>> +
>>  variant no_x11 description {Same as +quartz} {
>>      pre-fetch {
>>          if {[file exists ${prefix}/lib/libpangox-1.0.dylib]} {
>
> configure.ldflags-append -framework Cocoa -framework Carbon seems more
> appropriate, doesn't it?
Good point.  Changed in r41519.

From nox at macports.org  Wed Nov  5 07:04:19 2008
From: nox at macports.org (nox)
Date: Wed, 5 Nov 2008 16:04:19 +0100
Subject: Pending tickets on Trac
Message-ID: <CA154CC8-024B-4ED4-A108-A13996034E4C@macports.org>

Hi there.

I was wandering around the Trac tickets and there is a lot of them  
which need user feedbacks or are just outdated.
What is our policy in these cases? Should we close them?

From jmr at macports.org  Wed Nov  5 07:11:13 2008
From: jmr at macports.org (Joshua Root)
Date: Thu, 06 Nov 2008 02:11:13 +1100
Subject: Pending tickets on Trac
In-Reply-To: <CA154CC8-024B-4ED4-A108-A13996034E4C@macports.org>
References: <CA154CC8-024B-4ED4-A108-A13996034E4C@macports.org>
Message-ID: <4911B791.8080003@macports.org>

nox wrote:
> Hi there.
> 
> I was wandering around the Trac tickets and there is a lot of them which
> need user feedbacks or are just outdated.
> What is our policy in these cases? Should we close them?

If you can't reproduce the problem in the current version and the
reporter has not supplied requested info after a reasonable period of
time, go ahead and close them as worksforme.

- Josh

From ryandesign at macports.org  Wed Nov  5 14:26:27 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 5 Nov 2008 16:26:27 -0600
Subject: [41513] trunk/dports/devel
In-Reply-To: <20081105082734.A7A8061A8B4@beta.macosforge.org>
References: <20081105082734.A7A8061A8B4@beta.macosforge.org>
Message-ID: <48CBCD45-B4E0-468E-8FB4-58759B943879@macports.org>


On Nov 5, 2008, at 02:27, devans at macports.org wrote:

> +master_sites	${homepage}attachment/wiki/WikiStart/
> +distfiles       ${distname}${extract.suffix}?format=raw

Cool trick!

Hmm, except for the fact that that's the filename that ends up on the  
user's system, and on the mirror; see:

http://distfiles.macports.org/gtkimageview/

See attached patch for a better solution.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gtkimageview.diff
Type: application/octet-stream
Size: 562 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20081105/313e820f/attachment.obj>
-------------- next part --------------



From ryandesign at macports.org  Wed Nov  5 14:38:29 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 5 Nov 2008 16:38:29 -0600
Subject: Running tests on trunk (was: [41522] trunk/base/tests/test)
In-Reply-To: <20081105133324.291D0625A31@beta.macosforge.org>
References: <20081105133324.291D0625A31@beta.macosforge.org>
Message-ID: <4743CA16-3165-4CFB-B6ED-B3C70C221388@macports.org>


On Nov 5, 2008, at 07:33, pguyot at kallisys.net wrote:

> Revision: 41522
>           http://trac.macports.org/changeset/41522
> Author:   pguyot at kallisys.net
> Date:     2008-11-05 05:33:22 -0800 (Wed, 05 Nov 2008)
> Log Message:
> -----------
> Fixed expectations in tests to reflect changes in the code  
> (obviously tests are simply not run)

Obviously! I didn't even know we had tests.

What should we be doing before committing changes to base? Is it just  
"make test"?


From nox at macports.org  Wed Nov  5 14:55:57 2008
From: nox at macports.org (nox)
Date: Wed, 5 Nov 2008 23:55:57 +0100
Subject: [41513] trunk/dports/devel
In-Reply-To: <48CBCD45-B4E0-468E-8FB4-58759B943879@macports.org>
References: <20081105082734.A7A8061A8B4@beta.macosforge.org>
	<48CBCD45-B4E0-468E-8FB4-58759B943879@macports.org>
Message-ID: <844C49EF-4878-4BB0-8611-D8B69DCCA033@macports.org>

Le 5 nov. 08 ? 23:26, Ryan Schmidt a ?crit :

>
> On Nov 5, 2008, at 02:27, devans at macports.org wrote:
>
>> +master_sites	${homepage}attachment/wiki/WikiStart/
>> +distfiles       ${distname}${extract.suffix}?format=raw
>
> Cool trick!
>
> Hmm, except for the fact that that's the filename that ends up on  
> the user's system, and on the mirror; see:
>
> http://distfiles.macports.org/gtkimageview/
>
> See attached patch for a better solution.
>
> <gtkimageview.diff>

By the way, shouldn't it be better to create a new variable  
`fetchfiles` which would
replace the default mechanism offered with master_sites distname  
extract.suffix and all?
Tricky ports like this one would just have to write the url of the  
file(s) to fetch in `fetchfiles`.

My $0.02.

From ryandesign at macports.org  Wed Nov  5 15:01:31 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 5 Nov 2008 17:01:31 -0600
Subject: [41513] trunk/dports/devel
In-Reply-To: <844C49EF-4878-4BB0-8611-D8B69DCCA033@macports.org>
References: <20081105082734.A7A8061A8B4@beta.macosforge.org>
	<48CBCD45-B4E0-468E-8FB4-58759B943879@macports.org>
	<844C49EF-4878-4BB0-8611-D8B69DCCA033@macports.org>
Message-ID: <6FC32295-CCBE-4033-A6CA-17B6753EE69A@macports.org>


On Nov 5, 2008, at 16:55, nox wrote:

> Le 5 nov. 08 ? 23:26, Ryan Schmidt a ?crit :
>
>>
>> On Nov 5, 2008, at 02:27, devans at macports.org wrote:
>>
>>> +master_sites	${homepage}attachment/wiki/WikiStart/
>>> +distfiles       ${distname}${extract.suffix}?format=raw
>>
>> Cool trick!
>>
>> Hmm, except for the fact that that's the filename that ends up on  
>> the user's system, and on the mirror; see:
>>
>> http://distfiles.macports.org/gtkimageview/
>>
>> See attached patch for a better solution.
>>
>> <gtkimageview.diff>
>
> By the way, shouldn't it be better to create a new variable  
> `fetchfiles` which would
> replace the default mechanism offered with master_sites distname  
> extract.suffix and all?
> Tricky ports like this one would just have to write the url of the  
> file(s) to fetch in `fetchfiles`.

How would that work together with the distfiles mirrors?


From nox at macports.org  Wed Nov  5 15:07:43 2008
From: nox at macports.org (nox)
Date: Thu, 6 Nov 2008 00:07:43 +0100
Subject: [41513] trunk/dports/devel
In-Reply-To: <6FC32295-CCBE-4033-A6CA-17B6753EE69A@macports.org>
References: <20081105082734.A7A8061A8B4@beta.macosforge.org>
	<48CBCD45-B4E0-468E-8FB4-58759B943879@macports.org>
	<844C49EF-4878-4BB0-8611-D8B69DCCA033@macports.org>
	<6FC32295-CCBE-4033-A6CA-17B6753EE69A@macports.org>
Message-ID: <86722C93-5B4D-4D48-9782-002B4ADBB710@macports.org>


Le 6 nov. 08 ? 00:01, Ryan Schmidt a ?crit :

>
> On Nov 5, 2008, at 16:55, nox wrote:
>
>> Le 5 nov. 08 ? 23:26, Ryan Schmidt a ?crit :
>>
>>>
>>> On Nov 5, 2008, at 02:27, devans at macports.org wrote:
>>>
>>>> +master_sites	${homepage}attachment/wiki/WikiStart/
>>>> +distfiles       ${distname}${extract.suffix}?format=raw
>>>
>>> Cool trick!
>>>
>>> Hmm, except for the fact that that's the filename that ends up on  
>>> the user's system, and on the mirror; see:
>>>
>>> http://distfiles.macports.org/gtkimageview/
>>>
>>> See attached patch for a better solution.
>>>
>>> <gtkimageview.diff>
>>
>> By the way, shouldn't it be better to create a new variable  
>> `fetchfiles` which would
>> replace the default mechanism offered with master_sites distname  
>> extract.suffix and all?
>> Tricky ports like this one would just have to write the url of the  
>> file(s) to fetch in `fetchfiles`.
>
> How would that work together with the distfiles mirrors?
>

The same way as it does with distfiles, the file fetched from the URL  
can be uploaded to /$name/ on the distfiles mirrors.


From raimue at macports.org  Wed Nov  5 15:12:26 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 06 Nov 2008 00:12:26 +0100
Subject: [41513] trunk/dports/devel
In-Reply-To: <86722C93-5B4D-4D48-9782-002B4ADBB710@macports.org>
References: <20081105082734.A7A8061A8B4@beta.macosforge.org>	<48CBCD45-B4E0-468E-8FB4-58759B943879@macports.org>	<844C49EF-4878-4BB0-8611-D8B69DCCA033@macports.org>	<6FC32295-CCBE-4033-A6CA-17B6753EE69A@macports.org>
	<86722C93-5B4D-4D48-9782-002B4ADBB710@macports.org>
Message-ID: <4912285A.4040206@macports.org>

nox wrote:
>>> By the way, shouldn't it be better to create a new variable  
>>> `fetchfiles` which would
>>> replace the default mechanism offered with master_sites distname  
>>> extract.suffix and all?
>>> Tricky ports like this one would just have to write the url of the  
>>> file(s) to fetch in `fetchfiles`.
>> How would that work together with the distfiles mirrors?
>>
> 
> The same way as it does with distfiles, the file fetched from the URL  
> can be uploaded to /$name/ on the distfiles mirrors.

But we need to extract a name from that URL given to fetchfiles, so we
would stillt need the distfiles directive (or assume default
${name}-${version}${extract.suffix}).

Rainer

From devans at macports.org  Wed Nov  5 15:51:03 2008
From: devans at macports.org (David Evans)
Date: Wed, 05 Nov 2008 15:51:03 -0800
Subject: [41513] trunk/dports/devel
In-Reply-To: <48CBCD45-B4E0-468E-8FB4-58759B943879@macports.org>
References: <20081105082734.A7A8061A8B4@beta.macosforge.org>
	<48CBCD45-B4E0-468E-8FB4-58759B943879@macports.org>
Message-ID: <49123167.4090302@macports.org>

Ryan Schmidt wrote:
>
> On Nov 5, 2008, at 02:27, devans at macports.org wrote:
>
>> +master_sites    ${homepage}attachment/wiki/WikiStart/
>> +distfiles       ${distname}${extract.suffix}?format=raw
>
> Cool trick!
>
> Hmm, except for the fact that that's the filename that ends up on the
> user's system, and on the mirror; see:
>
> http://distfiles.macports.org/gtkimageview/
>
> See attached patch for a better solution.
>
>
>
Implemented in r41553.  Thanks for the suggestion.


From ryandesign at macports.org  Wed Nov  5 18:29:46 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 5 Nov 2008 20:29:46 -0600
Subject: [41513] trunk/dports/devel
In-Reply-To: <844C49EF-4878-4BB0-8611-D8B69DCCA033@macports.org>
References: <20081105082734.A7A8061A8B4@beta.macosforge.org>
	<48CBCD45-B4E0-468E-8FB4-58759B943879@macports.org>
	<844C49EF-4878-4BB0-8611-D8B69DCCA033@macports.org>
Message-ID: <F2EEF1CC-B3DD-42E4-AFD4-E0D4C1E300E6@macports.org>

On Nov 5, 2008, at 16:55, nox wrote:

> Le 5 nov. 08 ? 23:26, Ryan Schmidt a ?crit :
>
>> On Nov 5, 2008, at 02:27, devans at macports.org wrote:
>>
>>> +master_sites	${homepage}attachment/wiki/WikiStart/
>>> +distfiles       ${distname}${extract.suffix}?format=raw
>>
>> Cool trick!
>>
>> Hmm, except for the fact that that's the filename that ends up on  
>> the user's system, and on the mirror; see:
>>
>> http://distfiles.macports.org/gtkimageview/
>>
>> See attached patch for a better solution.
>>
>> <gtkimageview.diff>
>
> By the way, shouldn't it be better to create a new variable  
> `fetchfiles` which would
> replace the default mechanism offered with master_sites distname  
> extract.suffix and all?
> Tricky ports like this one would just have to write the url of the  
> file(s) to fetch in `fetchfiles`.

I'm not seeing how "fetchfiles" would work, in all the variations  
that we have to support (one or multiple distfiles, on one or  
multiple master sites).

I'm comfortable with the workaround presented in my patch. It's used  
by several ports already. We could document it in the Guide and in  
that way make it an official recommendation for this situation (when  
downloading through a server-side script instead of just downloading  
from a server directory).



From ryandesign at macports.org  Wed Nov  5 19:11:33 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 5 Nov 2008 21:11:33 -0600
Subject: BBEdit/TextWrangler language module
Message-ID: <8750D31D-F421-4B86-9E73-E0F806AD5625@macports.org>

Can we please put the BBEdit/TextWrangler language module in the  
contrib directory in the repository, instead of attached to the wiki  
page? The repository is where we store code; it's not efficient, when  
we need to make changes to the file, to have to download it from the  
wiki, change it, and upload a changed version.


From blb at macports.org  Wed Nov  5 19:19:16 2008
From: blb at macports.org (Bryan Blackburn)
Date: Wed, 5 Nov 2008 20:19:16 -0700
Subject: [41513] trunk/dports/devel
In-Reply-To: <F2EEF1CC-B3DD-42E4-AFD4-E0D4C1E300E6@macports.org>
References: <20081105082734.A7A8061A8B4@beta.macosforge.org>
	<48CBCD45-B4E0-468E-8FB4-58759B943879@macports.org>
	<844C49EF-4878-4BB0-8611-D8B69DCCA033@macports.org>
	<F2EEF1CC-B3DD-42E4-AFD4-E0D4C1E300E6@macports.org>
Message-ID: <20081106031916.GN454@ninagal.withay.com>

On Wed, Nov 05, 2008 at 08:29:46PM -0600, Ryan Schmidt said:
> On Nov 5, 2008, at 16:55, nox wrote:
>
>> Le 5 nov. 08 ? 23:26, Ryan Schmidt a ?crit :
>>
>>> On Nov 5, 2008, at 02:27, devans at macports.org wrote:
>>>
>>>> +master_sites	${homepage}attachment/wiki/WikiStart/
>>>> +distfiles       ${distname}${extract.suffix}?format=raw
>>>
>>> Cool trick!
>>>
>>> Hmm, except for the fact that that's the filename that ends up on the 
>>> user's system, and on the mirror; see:
>>>
>>> http://distfiles.macports.org/gtkimageview/
>>>
>>> See attached patch for a better solution.
>>>
>>> <gtkimageview.diff>
>>
>> By the way, shouldn't it be better to create a new variable  
>> `fetchfiles` which would
>> replace the default mechanism offered with master_sites distname  
>> extract.suffix and all?
>> Tricky ports like this one would just have to write the url of the  
>> file(s) to fetch in `fetchfiles`.
>
> I'm not seeing how "fetchfiles" would work, in all the variations that we 
> have to support (one or multiple distfiles, on one or multiple master 
> sites).
>
> I'm comfortable with the workaround presented in my patch. It's used by 
> several ports already. We could document it in the Guide and in that way 
> make it an official recommendation for this situation (when downloading 
> through a server-side script instead of just downloading from a server 
> directory).

Doesn't your workaround also have issues with multiple distfiles since you
use that variable in the URL?

master_sites ${homepage}attachment/wiki/WikiStart/${distfiles}?format=raw&dummy=

How does that work with 2+ files?  Perhaps a different approach could be to
use just a placeholder in master_sites:

master_sites ${homepage}attachment/wiki/WikiStart/<file>?format=raw&dummy=

or something to that effect (since <> are not valid in HTTP URLs).  When no
<file> is present, append to the end like we do now.

Bryan


From ryandesign at macports.org  Wed Nov  5 19:53:11 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 5 Nov 2008 21:53:11 -0600
Subject: [41513] trunk/dports/devel
In-Reply-To: <20081106031916.GN454@ninagal.withay.com>
References: <20081105082734.A7A8061A8B4@beta.macosforge.org>
	<48CBCD45-B4E0-468E-8FB4-58759B943879@macports.org>
	<844C49EF-4878-4BB0-8611-D8B69DCCA033@macports.org>
	<F2EEF1CC-B3DD-42E4-AFD4-E0D4C1E300E6@macports.org>
	<20081106031916.GN454@ninagal.withay.com>
Message-ID: <3D6131C0-1096-4F64-850E-B90E3755939C@macports.org>

On Nov 5, 2008, at 21:19, Bryan Blackburn wrote:

> On Wed, Nov 05, 2008 at 08:29:46PM -0600, Ryan Schmidt said:
>
>> On Nov 5, 2008, at 16:55, nox wrote:
>>
>>> Le 5 nov. 08 ? 23:26, Ryan Schmidt a ?crit :
>>>
>>>> On Nov 5, 2008, at 02:27, devans at macports.org wrote:
>>>>
>>>>> +master_sites	${homepage}attachment/wiki/WikiStart/
>>>>> +distfiles       ${distname}${extract.suffix}?format=raw
>>>>
>>>> Cool trick!
>>>>
>>>> Hmm, except for the fact that that's the filename that ends up  
>>>> on the
>>>> user's system, and on the mirror; see:
>>>>
>>>> http://distfiles.macports.org/gtkimageview/
>>>>
>>>> See attached patch for a better solution.
>>>>
>>>> <gtkimageview.diff>
>>>
>>> By the way, shouldn't it be better to create a new variable
>>> `fetchfiles` which would
>>> replace the default mechanism offered with master_sites distname
>>> extract.suffix and all?
>>> Tricky ports like this one would just have to write the url of the
>>> file(s) to fetch in `fetchfiles`.
>>
>> I'm not seeing how "fetchfiles" would work, in all the variations  
>> that we
>> have to support (one or multiple distfiles, on one or multiple master
>> sites).
>>
>> I'm comfortable with the workaround presented in my patch. It's  
>> used by
>> several ports already. We could document it in the Guide and in  
>> that way
>> make it an official recommendation for this situation (when  
>> downloading
>> through a server-side script instead of just downloading from a  
>> server
>> directory).
>
> Doesn't your workaround also have issues with multiple distfiles  
> since you
> use that variable in the URL?
>
> master_sites ${homepage}attachment/wiki/WikiStart/${distfiles}? 
> format=raw&dummy=
>
> How does that work with 2+ files?

It... totally doesn't. I guess I didn't think through my objection  
very well. :)

> Perhaps a different approach could be to use just a placeholder in  
> master_sites:
>
> master_sites ${homepage}attachment/wiki/WikiStart/<file>? 
> format=raw&dummy=
>
> or something to that effect (since <> are not valid in HTTP URLs).   
> When no
> <file> is present, append to the end like we do now.

Placeholder sounds very good. I might prefer a sprintf placeholder,  
like %s (% isn't valid by itself in a URL either).



From blb at macports.org  Wed Nov  5 20:22:12 2008
From: blb at macports.org (Bryan Blackburn)
Date: Wed, 5 Nov 2008 21:22:12 -0700
Subject: [41513] trunk/dports/devel
In-Reply-To: <3D6131C0-1096-4F64-850E-B90E3755939C@macports.org>
References: <20081105082734.A7A8061A8B4@beta.macosforge.org>
	<48CBCD45-B4E0-468E-8FB4-58759B943879@macports.org>
	<844C49EF-4878-4BB0-8611-D8B69DCCA033@macports.org>
	<F2EEF1CC-B3DD-42E4-AFD4-E0D4C1E300E6@macports.org>
	<20081106031916.GN454@ninagal.withay.com>
	<3D6131C0-1096-4F64-850E-B90E3755939C@macports.org>
Message-ID: <20081106042212.GT454@ninagal.withay.com>

On Wed, Nov 05, 2008 at 09:53:11PM -0600, Ryan Schmidt said:
[...]
>
>> Perhaps a different approach could be to use just a placeholder in  
>> master_sites:
>>
>> master_sites ${homepage}attachment/wiki/WikiStart/<file>? 
>> format=raw&dummy=
>>
>> or something to that effect (since <> are not valid in HTTP URLs).   
>> When no
>> <file> is present, append to the end like we do now.
>
> Placeholder sounds very good. I might prefer a sprintf placeholder, like 
> %s (% isn't valid by itself in a URL either).

% is valid for escaping; I wanted to pick something that wouldn't otherwise
appear in any URL so the template-replacing code would be simpler.

Bryan


From ryandesign at macports.org  Wed Nov  5 20:31:37 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 5 Nov 2008 22:31:37 -0600
Subject: [41513] trunk/dports/devel
In-Reply-To: <20081106042212.GT454@ninagal.withay.com>
References: <20081105082734.A7A8061A8B4@beta.macosforge.org>
	<48CBCD45-B4E0-468E-8FB4-58759B943879@macports.org>
	<844C49EF-4878-4BB0-8611-D8B69DCCA033@macports.org>
	<F2EEF1CC-B3DD-42E4-AFD4-E0D4C1E300E6@macports.org>
	<20081106031916.GN454@ninagal.withay.com>
	<3D6131C0-1096-4F64-850E-B90E3755939C@macports.org>
	<20081106042212.GT454@ninagal.withay.com>
Message-ID: <D9F3160D-D93F-4338-8A53-F53F1E0C658A@macports.org>

On Nov 5, 2008, at 22:22, Bryan Blackburn wrote:

> On Wed, Nov 05, 2008 at 09:53:11PM -0600, Ryan Schmidt said:
>
>>> Perhaps a different approach could be to use just a placeholder in
>>> master_sites:
>>>
>>> master_sites ${homepage}attachment/wiki/WikiStart/<file>?
>>> format=raw&dummy=
>>>
>>> or something to that effect (since <> are not valid in HTTP URLs).
>>> When no
>>> <file> is present, append to the end like we do now.
>>
>> Placeholder sounds very good. I might prefer a sprintf  
>> placeholder, like
>> %s (% isn't valid by itself in a URL either).
>
> % is valid for escaping; I wanted to pick something that wouldn't  
> otherwise
> appear in any URL so the template-replacing code would be simpler.

But %s by itself is not valid in URLs, and %s is the standard string  
replacement placeholder for the printf function. Um, which in tcl is  
the format function. So the replacement code is simple:

[format ${url} ${distfile}]

Or something like that.


From blb at macports.org  Wed Nov  5 20:57:52 2008
From: blb at macports.org (Bryan Blackburn)
Date: Wed, 5 Nov 2008 21:57:52 -0700
Subject: [41513] trunk/dports/devel
In-Reply-To: <D9F3160D-D93F-4338-8A53-F53F1E0C658A@macports.org>
References: <20081105082734.A7A8061A8B4@beta.macosforge.org>
	<48CBCD45-B4E0-468E-8FB4-58759B943879@macports.org>
	<844C49EF-4878-4BB0-8611-D8B69DCCA033@macports.org>
	<F2EEF1CC-B3DD-42E4-AFD4-E0D4C1E300E6@macports.org>
	<20081106031916.GN454@ninagal.withay.com>
	<3D6131C0-1096-4F64-850E-B90E3755939C@macports.org>
	<20081106042212.GT454@ninagal.withay.com>
	<D9F3160D-D93F-4338-8A53-F53F1E0C658A@macports.org>
Message-ID: <20081106045752.GU454@ninagal.withay.com>

On Wed, Nov 05, 2008 at 10:31:37PM -0600, Ryan Schmidt said:
> On Nov 5, 2008, at 22:22, Bryan Blackburn wrote:
>
>> On Wed, Nov 05, 2008 at 09:53:11PM -0600, Ryan Schmidt said:
>>
>>>> Perhaps a different approach could be to use just a placeholder in
>>>> master_sites:
>>>>
>>>> master_sites ${homepage}attachment/wiki/WikiStart/<file>?
>>>> format=raw&dummy=
>>>>
>>>> or something to that effect (since <> are not valid in HTTP URLs).
>>>> When no
>>>> <file> is present, append to the end like we do now.
>>>
>>> Placeholder sounds very good. I might prefer a sprintf placeholder, 
>>> like
>>> %s (% isn't valid by itself in a URL either).
>>
>> % is valid for escaping; I wanted to pick something that wouldn't  
>> otherwise
>> appear in any URL so the template-replacing code would be simpler.
>
> But %s by itself is not valid in URLs, and %s is the standard string  
> replacement placeholder for the printf function. Um, which in tcl is the 
> format function. So the replacement code is simple:
>
> [format ${url} ${distfile}]
>
> Or something like that.
>

% format "http://distfiles.macports.org/stuff/%s" "test-1.2.3.tar.gz"
http://distfiles.macports.org/stuff/test-1.2.3.tar.gz

Okay, makes sense, but

% format "http://distfiles.macports.org/stuff%20here/%s" "test-1.2.3.tar.gz"
expected floating-point number but got "test-1.2.3.tar.gz"

So if there's any % escaping, format may not be the best choice...granted
some work would have to go into using a different style as well, so it's
hard to say which is the better way to go.

Bryan


From pguyot at kallisys.net  Wed Nov  5 21:29:49 2008
From: pguyot at kallisys.net (Paul Guyot)
Date: Thu, 6 Nov 2008 06:29:49 +0100
Subject: Running tests on trunk (was: [41522] trunk/base/tests/test)
In-Reply-To: <4743CA16-3165-4CFB-B6ED-B3C70C221388@macports.org>
References: <20081105133324.291D0625A31@beta.macosforge.org>
	<4743CA16-3165-4CFB-B6ED-B3C70C221388@macports.org>
Message-ID: <B01628FF-239D-416E-8D27-91FB0D3022A6@kallisys.net>


Le 5 nov. 08 ? 23:38, Ryan Schmidt a ?crit :

> Obviously! I didn't even know we had tests.
>
> What should we be doing before committing changes to base? Is it  
> just "make test"?

Indeed.

Paul


From ryandesign at macports.org  Thu Nov  6 00:23:57 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 6 Nov 2008 02:23:57 -0600
Subject: [41513] trunk/dports/devel
In-Reply-To: <20081106045752.GU454@ninagal.withay.com>
References: <20081105082734.A7A8061A8B4@beta.macosforge.org>
	<48CBCD45-B4E0-468E-8FB4-58759B943879@macports.org>
	<844C49EF-4878-4BB0-8611-D8B69DCCA033@macports.org>
	<F2EEF1CC-B3DD-42E4-AFD4-E0D4C1E300E6@macports.org>
	<20081106031916.GN454@ninagal.withay.com>
	<3D6131C0-1096-4F64-850E-B90E3755939C@macports.org>
	<20081106042212.GT454@ninagal.withay.com>
	<D9F3160D-D93F-4338-8A53-F53F1E0C658A@macports.org>
	<20081106045752.GU454@ninagal.withay.com>
Message-ID: <61CC0C09-61CF-4183-A875-39A14EF6E127@macports.org>

On Nov 5, 2008, at 22:57, Bryan Blackburn wrote:

> On Wed, Nov 05, 2008 at 10:31:37PM -0600, Ryan Schmidt said:
>
>> On Nov 5, 2008, at 22:22, Bryan Blackburn wrote:
>>
>>> On Wed, Nov 05, 2008 at 09:53:11PM -0600, Ryan Schmidt said:
>>>
>>>>> Perhaps a different approach could be to use just a placeholder in
>>>>> master_sites:
>>>>>
>>>>> master_sites ${homepage}attachment/wiki/WikiStart/<file>?
>>>>> format=raw&dummy=
>>>>>
>>>>> or something to that effect (since <> are not valid in HTTP URLs).
>>>>> When no
>>>>> <file> is present, append to the end like we do now.
>>>>
>>>> Placeholder sounds very good. I might prefer a sprintf placeholder,
>>>> like
>>>> %s (% isn't valid by itself in a URL either).
>>>
>>> % is valid for escaping; I wanted to pick something that wouldn't
>>> otherwise
>>> appear in any URL so the template-replacing code would be simpler.
>>
>> But %s by itself is not valid in URLs, and %s is the standard string
>> replacement placeholder for the printf function. Um, which in tcl  
>> is the
>> format function. So the replacement code is simple:
>>
>> [format ${url} ${distfile}]
>>
>> Or something like that.
>
> % format "http://distfiles.macports.org/stuff/%s" "test-1.2.3.tar.gz"
> http://distfiles.macports.org/stuff/test-1.2.3.tar.gz
>
> Okay, makes sense, but
>
> % format "http://distfiles.macports.org/stuff%20here/%s"  
> "test-1.2.3.tar.gz"
> expected floating-point number but got "test-1.2.3.tar.gz"
>
> So if there's any % escaping, format may not be the best choice...

Good catch. "%20h" is valid printf formatting for 20 characters of  
hexadecimal digits... not what we want. So scratch that idea.

> granted some work would have to go into using a different style as  
> well,
> so it's hard to say which is the better way to go.

Let's go with your <file> idea instead.


From nox at macports.org  Thu Nov  6 01:01:41 2008
From: nox at macports.org (nox)
Date: Thu, 6 Nov 2008 10:01:41 +0100
Subject: [41513] trunk/dports/devel
In-Reply-To: <F2EEF1CC-B3DD-42E4-AFD4-E0D4C1E300E6@macports.org>
References: <20081105082734.A7A8061A8B4@beta.macosforge.org>
	<48CBCD45-B4E0-468E-8FB4-58759B943879@macports.org>
	<844C49EF-4878-4BB0-8611-D8B69DCCA033@macports.org>
	<F2EEF1CC-B3DD-42E4-AFD4-E0D4C1E300E6@macports.org>
Message-ID: <A90CE77C-C6E7-4000-BCF2-47151A253C23@macports.org>

Le 6 nov. 08 ? 03:29, Ryan Schmidt a ?crit :

> On Nov 5, 2008, at 16:55, nox wrote:
>
>> Le 5 nov. 08 ? 23:26, Ryan Schmidt a ?crit :
>>
>>> On Nov 5, 2008, at 02:27, devans at macports.org wrote:
>>>
>>>> +master_sites	${homepage}attachment/wiki/WikiStart/
>>>> +distfiles       ${distname}${extract.suffix}?format=raw
>>>
>>> Cool trick!
>>>
>>> Hmm, except for the fact that that's the filename that ends up on  
>>> the user's system, and on the mirror; see:
>>>
>>> http://distfiles.macports.org/gtkimageview/
>>>
>>> See attached patch for a better solution.
>>>
>>> <gtkimageview.diff>
>>
>> By the way, shouldn't it be better to create a new variable  
>> `fetchfiles` which would
>> replace the default mechanism offered with master_sites distname  
>> extract.suffix and all?
>> Tricky ports like this one would just have to write the url of the  
>> file(s) to fetch in `fetchfiles`.
>
> I'm not seeing how "fetchfiles" would work, in all the variations  
> that we have to support (one or multiple distfiles, on one or  
> multiple master sites).
>
> I'm comfortable with the workaround presented in my patch. It's used  
> by several ports already. We could document it in the Guide and in  
> that way make it an official recommendation for this situation (when  
> downloading through a server-side script instead of just downloading  
> from a server directory).

Indeed I haven't thought about how to guess the filename from the URL.
The filename should be the filename part of the url if the url is not  
a list.
Otherwise if the url is a list of two elements, the fetched file  
should be saved under the name in the second element of the list

For example, for the following code:

fetchfiles	http://example.com/foo.tar.gz \
		http://example.com/foo-doc.tar.gz?format=raw \
		{http://example.com/file.php?id=42 thing-without-a-name.zip}

3 files would be fetch: foo.tar.gz, foo-doc.tar.gz and thing-without-a- 
name.zip.
As the filename is written in the Portfile, curl could use it when  
fetching the url to save the response under a correct filename,
regardless of the headers sent by the webserver.


From pguyot at kallisys.net  Thu Nov  6 02:27:54 2008
From: pguyot at kallisys.net (Paul Guyot)
Date: Thu, 6 Nov 2008 11:27:54 +0100
Subject: [macports-mgr] Dependencies and variants
In-Reply-To: <F343E143-FD21-4FE2-8C7A-5A355BB4B3DE@macports.org>
References: <F89E5DD8-13CD-4B3D-A550-8C04730F7054@kallisys.net>
	<20081106012228.GJ454@ninagal.withay.com>
	<8232025E-E1B0-4850-A0C2-3A5E966F3C55@kallisys.net>
	<20081106085941.GX454@ninagal.withay.com>
	<46A78A84-5121-4C0E-B8C0-31806EFE28D2@kallisys.net>
	<F343E143-FD21-4FE2-8C7A-5A355BB4B3DE@macports.org>
Message-ID: <0A208A9E-F188-4787-8BF4-DFB27AB39370@kallisys.net>


Le 6 nov. 08 ? 10:44, Ryan Schmidt a ?crit :

> I would still like this discussion to take place on macports-dev,  
> not macports-mgr.

True.

A quick summary for macports-dev: the discussion is about r41526 and  
r41527, i.e. allowing a new syntax for dependencies in the next  
release without actually implementing them. The idea is to allow work  
and testing for bug #126 (dependencies should take variants into  
consideration) on trunk, with ports in trunk using the new syntax but  
remaining compatible with released base/. Experience with livecheck  
showed that if we wait for the implementation to support the syntax,  
we will need several releases to get it right and get the new syntax  
adopted by maintainers. I asked portmgr to consider it for the next  
release, and portmgr asked what I had in mind for the syntax, since  
there is just no implementation or guideline in r41526 and r41527. To  
what I replied that I prefer not to force any syntax for many syntaxes  
came up in the past for #126, and my belief is that it's eventually up  
to whoever implements that. Therefore, the changes allow for :

depends_*	port:[whatever:]port_name

where we currently have

depends_*	port:port_name

as this is coherent with the current depends_* lines.

It also allow for a new syntax

depends		whatever

if whoever works on #126 wants to get rid of the old depends_* syntax  
for more freedom. While I would just be happy with whatever comes up  
that fixes #126, I argued that depends_* were somewhat ugly and  
confusing.

> I don't see why depends_* is ugly or should be abandoned.

:)

> depends_build is for things which are needed to build the software.  
> Note: this is not only the build phase, but (in MacPorts trunk) any  
> phase involved in building the software, including fetch, extract,  
> and configure. (I think I'm remembering that right.)

AFAIK, no dependency is processed for extract and fetch. In other  
words, all ports that use fetching using git on 10.5 and fetching  
using svn and git on 10.4 just don't fetch with trace mode enabled.

> Things declared as depends_build can be uninstalled after the port  
> is installed with no ill effects. The others cannot. Putting all  
> dependencies into a single "depends" negates this possibility.

Depends how the depends syntax is designed. It could be:

depends {
	build { awk }
	lib { glib2 }
	run { evince }
}

Paul


From jmr at macports.org  Thu Nov  6 03:36:06 2008
From: jmr at macports.org (Joshua Root)
Date: Thu, 06 Nov 2008 22:36:06 +1100
Subject: [macports-mgr] Dependencies and variants
In-Reply-To: <0A208A9E-F188-4787-8BF4-DFB27AB39370@kallisys.net>
References: <F89E5DD8-13CD-4B3D-A550-8C04730F7054@kallisys.net>	<20081106012228.GJ454@ninagal.withay.com>	<8232025E-E1B0-4850-A0C2-3A5E966F3C55@kallisys.net>	<20081106085941.GX454@ninagal.withay.com>	<46A78A84-5121-4C0E-B8C0-31806EFE28D2@kallisys.net>	<F343E143-FD21-4FE2-8C7A-5A355BB4B3DE@macports.org>
	<0A208A9E-F188-4787-8BF4-DFB27AB39370@kallisys.net>
Message-ID: <4912D6A6.9090001@macports.org>

Paul Guyot wrote:
>> depends_build is for things which are needed to build the software.
>> Note: this is not only the build phase, but (in MacPorts trunk) any
>> phase involved in building the software, including fetch, extract, and
>> configure. (I think I'm remembering that right.)
> 
> AFAIK, no dependency is processed for extract and fetch. In other words,
> all ports that use fetching using git on 10.5 and fetching using svn and
> git on 10.4 just don't fetch with trace mode enabled.

Indeed, the current depends_* classes are not sufficient, and their
implementation needs work. I opened #15161 to track this. I think they
can be fixed without starting from scratch, though. :-)

- Josh

From macsforever2000 at macports.org  Thu Nov  6 08:48:11 2008
From: macsforever2000 at macports.org (Frank Schima)
Date: Thu, 6 Nov 2008 09:48:11 -0700
Subject: BBEdit/TextWrangler language module
In-Reply-To: <8750D31D-F421-4B86-9E73-E0F806AD5625@macports.org>
References: <8750D31D-F421-4B86-9E73-E0F806AD5625@macports.org>
Message-ID: <B2F1D2C2-CC65-4FAC-8BB6-E1A588B84F6C@macports.org>

Hi Ryan,


On Nov 5, 2008, at 8:11 PM, Ryan Schmidt wrote:

> Can we please put the BBEdit/TextWrangler language module in the  
> contrib directory in the repository, instead of attached to the wiki  
> page? The repository is where we store code; it's not efficient,  
> when we need to make changes to the file, to have to download it  
> from the wiki, change it, and upload a changed version.

I have added the file to the contrib area [1]. I edited the wiki page  
to point to the new file location, but I can't figure out how to  
delete an attachment from the wiki page [2]! Any ideas?

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


Cheers!
Frank


From wsiegrist at apple.com  Thu Nov  6 09:11:49 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Thu, 06 Nov 2008 09:11:49 -0800
Subject: BBEdit/TextWrangler language module
In-Reply-To: <B2F1D2C2-CC65-4FAC-8BB6-E1A588B84F6C@macports.org>
References: <8750D31D-F421-4B86-9E73-E0F806AD5625@macports.org>
	<B2F1D2C2-CC65-4FAC-8BB6-E1A588B84F6C@macports.org>
Message-ID: <50CC5088-9BA7-43A6-82EB-908C220AAD74@apple.com>

On Nov 6, 2008, at 8:48 AM, Frank Schima wrote:

> Hi Ryan,
>
>
> On Nov 5, 2008, at 8:11 PM, Ryan Schmidt wrote:
>
>> Can we please put the BBEdit/TextWrangler language module in the  
>> contrib directory in the repository, instead of attached to the  
>> wiki page? The repository is where we store code; it's not  
>> efficient, when we need to make changes to the file, to have to  
>> download it from the wiki, change it, and upload a changed version.
>
> I have added the file to the contrib area [1]. I edited the wiki  
> page to point to the new file location, but I can't figure out how  
> to delete an attachment from the wiki page [2]! Any ideas?
>
> [1] <http://trac.macports.org/changeset/41582>
> [2] <http://trac.macports.org/wiki/BbeditLanguageModule>
>
>


Deleting attachments requires more privileges, so I took care of it  
for you.  I also changed the link to svn.macports.org since Trac  
defaults to an html display, and with ?format=raw appended .txt to the  
end of the file. And the svn link is less work for the servers and  
thus loads faster.


-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/20081106/36657b54/attachment.bin>

From florian.ebeling at gmail.com  Thu Nov  6 12:04:44 2008
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Thu, 6 Nov 2008 21:04:44 +0100
Subject: [macports-mgr] Dependencies and variants
In-Reply-To: <0A208A9E-F188-4787-8BF4-DFB27AB39370@kallisys.net>
References: <F89E5DD8-13CD-4B3D-A550-8C04730F7054@kallisys.net>
	<20081106012228.GJ454@ninagal.withay.com>
	<8232025E-E1B0-4850-A0C2-3A5E966F3C55@kallisys.net>
	<20081106085941.GX454@ninagal.withay.com>
	<46A78A84-5121-4C0E-B8C0-31806EFE28D2@kallisys.net>
	<F343E143-FD21-4FE2-8C7A-5A355BB4B3DE@macports.org>
	<0A208A9E-F188-4787-8BF4-DFB27AB39370@kallisys.net>
Message-ID: <5cbbe4ae0811061204s13ff02b9se2983b5911008216@mail.gmail.com>

On Thu, Nov 6, 2008 at 11:27 AM, Paul Guyot <pguyot at kallisys.net> wrote:
>
> Le 6 nov. 08 ? 10:44, Ryan Schmidt a ?crit :
>
>> I would still like this discussion to take place on macports-dev, not
>> macports-mgr.
>
> True.

Why are such things discussed on a closed list?! I was already
wondering why there is no discussion going on. Isn't this projects
also built on the notion of openness etc? Also I didn't hear
anything about the R-word since the the management is
in office.

I think I'm a patient person but mp starts to bore me abit tbh.


>
> A quick summary for macports-dev: the discussion is about r41526 and r41527,
> i.e. allowing a new syntax for dependencies in the next release without
> actually implementing them. The idea is to allow work and testing for bug
> #126 (dependencies should take variants into consideration) on trunk, with
> ports in trunk using the new syntax but remaining compatible with released
> base/. Experience with livecheck showed that if we wait for the
> implementation to support the syntax, we will need several releases to get
> it right and get the new syntax adopted by maintainers. I asked portmgr to
> consider it for the next release, and portmgr asked what I had in mind for
> the syntax, since there is just no implementation or guideline in r41526 and
> r41527. To what I replied that I prefer not to force any syntax for many
> syntaxes came up in the past for #126, and my belief is that it's eventually
> up to whoever implements that. Therefore, the changes allow for :
>
> depends_*       port:[whatever:]port_name
>
> where we currently have
>
> depends_*       port:port_name
>
> as this is coherent with the current depends_* lines.
>
> It also allow for a new syntax
>
> depends         whatever
>
> if whoever works on #126 wants to get rid of the old depends_* syntax for
> more freedom. While I would just be happy with whatever comes up that fixes
> #126, I argued that depends_* were somewhat ugly and confusing.
>
>> I don't see why depends_* is ugly or should be abandoned.
>
> :)
>
>> depends_build is for things which are needed to build the software. Note:
>> this is not only the build phase, but (in MacPorts trunk) any phase involved
>> in building the software, including fetch, extract, and configure. (I think
>> I'm remembering that right.)
>
> AFAIK, no dependency is processed for extract and fetch. In other words, all
> ports that use fetching using git on 10.5 and fetching using svn and git on
> 10.4 just don't fetch with trace mode enabled.
>
>> Things declared as depends_build can be uninstalled after the port is
>> installed with no ill effects. The others cannot. Putting all dependencies
>> into a single "depends" negates this possibility.
>
> Depends how the depends syntax is designed. It could be:
>
> depends {
>        build { awk }
>        lib { glib2 }
>        run { evince }
> }
>
> Paul
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>



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

From ryandesign at macports.org  Thu Nov  6 13:47:14 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 6 Nov 2008 15:47:14 -0600
Subject: [41581] trunk/dports/devel/libidl/Portfile
In-Reply-To: <20081106134003.0FD6862F816@beta.macosforge.org>
References: <20081106134003.0FD6862F816@beta.macosforge.org>
Message-ID: <66458700-77DA-4BAD-96DA-850E95D7EE7D@macports.org>

On Nov 6, 2008, at 07:40, mcalhoun at macports.org wrote:

> Revision: 41581
>           http://trac.macports.org/changeset/41581
> Author:   mcalhoun at macports.org
> Date:     2008-11-06 05:40:00 -0800 (Thu, 06 Nov 2008)
> Log Message:
> -----------
> libidl: use system bison since MacPorts bison 2.4 (#41450) does not  
> work

Could you elaborate how MacPorts bison 2.4 does not work for you? I'm  
having trouble with it too, for pure-devel [1], but using the system  
bison is not an option for me as I need at least version 2.1a and  
Tiger provides version 1.28.


[1] http://groups.google.com/group/pure-lang/browse_thread/thread/ 
60593b93dc8fcf63



From blb at macports.org  Thu Nov  6 14:09:53 2008
From: blb at macports.org (Bryan Blackburn)
Date: Thu, 6 Nov 2008 15:09:53 -0700
Subject: [macports-mgr] Dependencies and variants
In-Reply-To: <5cbbe4ae0811061204s13ff02b9se2983b5911008216@mail.gmail.com>
References: <F89E5DD8-13CD-4B3D-A550-8C04730F7054@kallisys.net>
	<20081106012228.GJ454@ninagal.withay.com>
	<8232025E-E1B0-4850-A0C2-3A5E966F3C55@kallisys.net>
	<20081106085941.GX454@ninagal.withay.com>
	<46A78A84-5121-4C0E-B8C0-31806EFE28D2@kallisys.net>
	<F343E143-FD21-4FE2-8C7A-5A355BB4B3DE@macports.org>
	<0A208A9E-F188-4787-8BF4-DFB27AB39370@kallisys.net>
	<5cbbe4ae0811061204s13ff02b9se2983b5911008216@mail.gmail.com>
Message-ID: <20081106220953.GD709@ninagal.withay.com>

On Thu, Nov 06, 2008 at 09:04:44PM +0100, C. Florian Ebeling said:
> On Thu, Nov 6, 2008 at 11:27 AM, Paul Guyot <pguyot at kallisys.net> wrote:
> >
> > Le 6 nov. 08 ? 10:44, Ryan Schmidt a ?crit :
> >
> >> I would still like this discussion to take place on macports-dev, not
> >> macports-mgr.
> >
> > True.
> 
> Why are such things discussed on a closed list?! I was already
> wondering why there is no discussion going on. Isn't this projects
> also built on the notion of openness etc? Also I didn't hear
> anything about the R-word since the the management is
> in office.

Probably because it just started there, until as you see, it moved to -dev.
As far as 1.7, I'll put out an email here in a minute about it.

Bryan


> 
> I think I'm a patient person but mp starts to bore me abit tbh.
> 
> 
[...]
> 
> -- 
> Florian Ebeling
> Twitter: febeling
> florian.ebeling at gmail.com

From blb at macports.org  Thu Nov  6 14:17:34 2008
From: blb at macports.org (Bryan Blackburn)
Date: Thu, 6 Nov 2008 15:17:34 -0700
Subject: MacPorts 1.7.0
Message-ID: <20081106221734.GE709@ninagal.withay.com>

The plan for 1.7.0 is basically to get the last remaining tickets which are
assigned to the 1.7.0 milestone:

<http://trac.macports.org/milestone/MacPorts%201.7.0>

Which shows three tickets remaining, though two are interrelated.  The third
is just for an apparent edge-case of the "we-love-you-so-much" Tcl
environment bug.

Once these are put into place, we'll get a beta1 put out there for testing,
unless someone has some other issues.  Like, for example, Paul's idea for
making dependencies a bit more forward-compatible so #126 can be worked on
without needing to wait for further releases to get things working.

If you have something really pressing bring it up, but I'd like to see 1.8.0
much sooner than 1.7.0 was from the previous, as I already have a few things
to put into 1.8.0...

Bryan


From mcalhoun at macports.org  Thu Nov  6 14:35:59 2008
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Thu, 6 Nov 2008 22:35:59 +0000 (UTC)
Subject: [41581] trunk/dports/devel/libidl/Portfile
References: <20081106134003.0FD6862F816@beta.macosforge.org>
	<66458700-77DA-4BAD-96DA-850E95D7EE7D@macports.org>
Message-ID: <loom.20081106T221741-959@post.gmane.org>

Ryan Schmidt <ryandesign at ...> writes:

> 
> On Nov 6, 2008, at 07:40, mcalhoun at ... wrote:
> 
> > Revision: 41581
> >           http://trac.macports.org/changeset/41581
> > Author:   mcalhoun at ...
> > Date:     2008-11-06 05:40:00 -0800 (Thu, 06 Nov 2008)
> > Log Message:
> > -----------
> > libidl: use system bison since MacPorts bison 2.4 (#41450) does not  
> > work
> 
> Could you elaborate how MacPorts bison 2.4 does not work for you? I'm  
> having trouble with it too, for pure-devel [1], but using the system  
> bison is not an option for me as I need at least version 2.1a and  
> Tiger provides version 1.28.
>

The libidl Makefile calls
bison -y -d -v 2>/dev/null ./parser.y

The MacPorts version of bison is called, and an error ensues:
/opt/local/bin/bison -y -d -v ./parser.y
./parser.y:610.9-10:
        $$ for the midrule at $6 of `struct_type' has no declared type
./parser.y:627.9-10: $$
        for the midrule at $10 of `union_type' has no declared type

The Leopard version of bison gives innocuous looking warnings:
/usr/bin/bison -y -d -v ./parser.y
./parser.y:606.25-618.1: warning: unused value: $3
./parser.y:621.25-635.1: warning: unused value: $3
./parser.y:716.25-732.1: warning: unused value: $4
./parser.y:780.25-781.68: warning: unused value: $1
./parser.y:811.25-818.1: warning: unused value: $3
./parser.y:926.25-933.1: warning: unused value: $3

Unfortunately, I know very little about Bison and Yacc, so the quickest fix
seemed to be to simply call the system bison.

This was not needed a few days ago, so it seems to be a result of the upgrade
of bison 2.3 -> 2.4.

I know it is a really bad idea, but if Bison 2.4 is a significant change that is
causing problems with several ports, we could always create a bison-compat
port which would remain at version 2.3.

-Marcus









From frstan at bellsouth.net  Thu Nov  6 15:19:19 2008
From: frstan at bellsouth.net (William Davis)
Date: Thu, 6 Nov 2008 18:19:19 -0500
Subject: MacPorts 1.7.0
In-Reply-To: <20081106221734.GE709@ninagal.withay.com>
References: <20081106221734.GE709@ninagal.withay.com>
Message-ID: <874E6FE6-FB68-45E0-A785-A99BCBF97BD3@bellsouth.net>


On Nov 6, 2008, at 5:17 PM, Bryan Blackburn wrote:

> The plan for 1.7.0 is basically to get the last remaining tickets  
> which are
> assigned to the 1.7.0 milestone:
>
> <http://trac.macports.org/milestone/MacPorts%201.7.0>
>
> Which shows three tickets remaining, though two are interrelated.   
> The third
> is just for an apparent edge-case of the "we-love-you-so-much" Tcl
> environment bug.
>
> Once these are put into place, we'll get a beta1 put out there for  
> testing,
> unless someone has some other issues.  Like, for example, Paul's  
> idea for
> making dependencies a bit more forward-compatible so #126 can be  
> worked on
> without needing to wait for further releases to get things working.
>
> If you have something really pressing bring it up, but I'd like to  
> see 1.8.0
> much sooner than 1.7.0 was from the previous, as I already have a  
> few things
> to put into 1.8.0...
>
> Bryan
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

thank you and all the other new portmgrs for this.  Please dont let  
anyone make "the Perfect the enemy of the Good".
Get 1.7 out and let the improvements come in 1.8

thanks again for all your hard work...........

WDD




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

Mundus vult decepi, ego non


From devans at macports.org  Thu Nov  6 15:20:25 2008
From: devans at macports.org (David Evans)
Date: Thu, 06 Nov 2008 15:20:25 -0800
Subject: MacPorts 1.7.0
In-Reply-To: <20081106221734.GE709@ninagal.withay.com>
References: <20081106221734.GE709@ninagal.withay.com>
Message-ID: <49137BB9.2050001@macports.org>

Bryan Blackburn wrote:
> The plan for 1.7.0 is basically to get the last remaining tickets which are
> assigned to the 1.7.0 milestone:
>
> <http://trac.macports.org/milestone/MacPorts%201.7.0>
>
> Which shows three tickets remaining, though two are interrelated.  The third
> is just for an apparent edge-case of the "we-love-you-so-much" Tcl
> environment bug.
>
> Once these are put into place, we'll get a beta1 put out there for testing,
> unless someone has some other issues.  Like, for example, Paul's idea for
> making dependencies a bit more forward-compatible so #126 can be worked on
> without needing to wait for further releases to get things working.
>
> If you have something really pressing bring it up, but I'd like to see 1.8.0
> much sooner than 1.7.0 was from the previous, as I already have a few things
> to put into 1.8.0...
>
> Bryan
>   
Great news.

This being the case, I wonder if it would be useful to add a MacPorts
1.8.0 milestone to Trac and perhaps
a Macports 1.7.1 if minor releases are contemplated.  This would allow
the release team a mechanism
for categorizing outstanding tickets in a way that is visible to the
community. 

As of now, I see 84 open tickets assigned to MacPorts base bugs, some of
which seem to have a
solution attached but for whatever reason have not been committed.  And
some of these have been
around for some time.  A good example is #8221.

Is there an effort afoot to address any low hanging fruit here that can
be incorporated into a 1.7.0
release without too much effort?  Or is it too late for that?

Perhaps some that are now irrelevant that can be closed out?

Is there anything that the rest of us can do to help?

From ryandesign at macports.org  Thu Nov  6 16:52:03 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 6 Nov 2008 18:52:03 -0600
Subject: MacPorts 1.7.0
In-Reply-To: <49137BB9.2050001@macports.org>
References: <20081106221734.GE709@ninagal.withay.com>
	<49137BB9.2050001@macports.org>
Message-ID: <ED8733B6-D7AD-4F0A-BE1E-ACB7EBE514BF@macports.org>

On Nov 6, 2008, at 17:20, David Evans wrote:

> This being the case, I wonder if it would be useful to add a MacPorts
> 1.8.0 milestone to Trac and perhaps
> a Macports 1.7.1 if minor releases are contemplated.  This would allow
> the release team a mechanism
> for categorizing outstanding tickets in a way that is visible to the
> community.

At this time, I'm not going to be going through tickets figuring out  
what should be in what release. I'm not too fussed about release  
numbering and such actually. I'm much more interested in releasing  
what's on trunk, then adding more features and bug fixes on trunk,  
then releasing that again, etc. I don't need milestones to do that.  
Changes will get included in MacPorts when they're done. Others may  
see it differently and want to prioritize certain things...


> As of now, I see 84 open tickets assigned to MacPorts base bugs,  
> some of
> which seem to have a
> solution attached but for whatever reason have not been committed.   
> And
> some of these have been
> around for some time.  A good example is #8221.

Have you tested the solution attached to that ticket? Does it work?  
You could add a note to the ticket with your findings. I admit I have  
not tested it.


> Is there an effort afoot to address any low hanging fruit here that  
> can
> be incorporated into a 1.7.0
> release without too much effort?  Or is it too late for that?

I'd rather not. We already have a year's worth of good changes in  
trunk. I'd like to release that as 1.7.0 as soon as possible. Let's  
not delay any further trying to fix other things.

The next release after 1.7.0 should appear in much less time so there  
needn't be such a push to add more things to 1.7.0.


> Perhaps some that are now irrelevant that can be closed out?
>
> Is there anything that the rest of us can do to help?

Certainly you can examine the open bugs and see if they are still  
relevant, and close them if not.



From ryandesign at macports.org  Thu Nov  6 16:53:18 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 6 Nov 2008 18:53:18 -0600
Subject: [41581] trunk/dports/devel/libidl/Portfile
In-Reply-To: <loom.20081106T221741-959@post.gmane.org>
References: <20081106134003.0FD6862F816@beta.macosforge.org>
	<66458700-77DA-4BAD-96DA-850E95D7EE7D@macports.org>
	<loom.20081106T221741-959@post.gmane.org>
Message-ID: <F1B35E43-45FB-4542-A4D3-0E02926C3E1C@macports.org>

On Nov 6, 2008, at 16:35, Marcus Calhoun-Lopez wrote:

> Ryan Schmidt <ryandesign at ...> writes:
>
>> On Nov 6, 2008, at 07:40, mcalhoun at ... wrote:
>>
>>> Revision: 41581
>>>           http://trac.macports.org/changeset/41581
>>> Author:   mcalhoun at ...
>>> Date:     2008-11-06 05:40:00 -0800 (Thu, 06 Nov 2008)
>>> Log Message:
>>> -----------
>>> libidl: use system bison since MacPorts bison 2.4 (#41450) does not
>>> work
>>
>> Could you elaborate how MacPorts bison 2.4 does not work for you? I'm
>> having trouble with it too, for pure-devel [1], but using the system
>> bison is not an option for me as I need at least version 2.1a and
>> Tiger provides version 1.28.
>
> The libidl Makefile calls
> bison -y -d -v 2>/dev/null ./parser.y
>
> The MacPorts version of bison is called, and an error ensues:
> /opt/local/bin/bison -y -d -v ./parser.y
> ./parser.y:610.9-10:
>         $$ for the midrule at $6 of `struct_type' has no declared type
> ./parser.y:627.9-10: $$
>         for the midrule at $10 of `union_type' has no declared type
>
> The Leopard version of bison gives innocuous looking warnings:
> /usr/bin/bison -y -d -v ./parser.y
> ./parser.y:606.25-618.1: warning: unused value: $3
> ./parser.y:621.25-635.1: warning: unused value: $3
> ./parser.y:716.25-732.1: warning: unused value: $4
> ./parser.y:780.25-781.68: warning: unused value: $1
> ./parser.y:811.25-818.1: warning: unused value: $3
> ./parser.y:926.25-933.1: warning: unused value: $3
>
> Unfortunately, I know very little about Bison and Yacc, so the  
> quickest fix
> seemed to be to simply call the system bison.
>
> This was not needed a few days ago, so it seems to be a result of  
> the upgrade
> of bison 2.3 -> 2.4.
>
> I know it is a really bad idea, but if Bison 2.4 is a significant  
> change that is
> causing problems with several ports, we could always create a bison- 
> compat
> port which would remain at version 2.3.

I already requested a bison23 port be created:

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




From devans at macports.org  Thu Nov  6 17:40:20 2008
From: devans at macports.org (David Evans)
Date: Thu, 06 Nov 2008 17:40:20 -0800
Subject: MacPorts 1.7.0
In-Reply-To: <ED8733B6-D7AD-4F0A-BE1E-ACB7EBE514BF@macports.org>
References: <20081106221734.GE709@ninagal.withay.com>
	<49137BB9.2050001@macports.org>
	<ED8733B6-D7AD-4F0A-BE1E-ACB7EBE514BF@macports.org>
Message-ID: <49139C84.4010303@macports.org>

Ryan Schmidt wrote:
>
>>  A good example is #8221.
>
> Have you tested the solution attached to that ticket? Does it work?
> You could add a note to the ticket with your findings. I admit I have
> not tested it.
Will give it a shot.  Frankly, it never crossed my mind that someone
would submit a patch that he/she hadn't
at least quickly tested.
> Certainly you can examine the open bugs and see if they are still
> relevant, and close them if not.
Will do what I can as time permits, quietly. :-)

Thanks to you and the others for all your work in moving things along as
you have recently.  Looking forward
to 1.7.0 beta 1

Dave

From blb at macports.org  Thu Nov  6 19:02:04 2008
From: blb at macports.org (Bryan Blackburn)
Date: Thu, 6 Nov 2008 20:02:04 -0700
Subject: MacPorts 1.7.0
In-Reply-To: <49137BB9.2050001@macports.org>
References: <20081106221734.GE709@ninagal.withay.com>
	<49137BB9.2050001@macports.org>
Message-ID: <20081107030204.GL709@ninagal.withay.com>

On Thu, Nov 06, 2008 at 03:20:25PM -0800, David Evans said:
[...]
> This being the case, I wonder if it would be useful to add a MacPorts
> 1.8.0 milestone to Trac and perhaps
> a Macports 1.7.1 if minor releases are contemplated.  This would allow
> the release team a mechanism
> for categorizing outstanding tickets in a way that is visible to the
> community. 
> 
> As of now, I see 84 open tickets assigned to MacPorts base bugs, some of
> which seem to have a
> solution attached but for whatever reason have not been committed.  And
> some of these have been
> around for some time.  A good example is #8221.
> 
> Is there an effort afoot to address any low hanging fruit here that can
> be incorporated into a 1.7.0
> release without too much effort?  Or is it too late for that?

Unless it's a really big deal, it'd be best to leave it for a later release
so 1.7.0 can be available.  We still see frequent reports of PATH and Tcl
env bug issues, so those long-standing issues can be dealt with finally.
Not to mention there are already quite a few changes already in 1.7.0 [1]
and there will probably be a few bugs here and there, so best to get those
ironed out too without adding even more features.

> 
> Perhaps some that are now irrelevant that can be closed out?

That's possible, I've been going through old port bugs currently (and I see
nox has as well), once done I do plan on doing the same for base bugs,
hopefully some will be irrelevant now, since that's the easiest fix...

> 
> Is there anything that the rest of us can do to help?

As Ryan said, going through bugs is definitely a help, many are against
nomaintainer ports so need someone to fix them, even if you don't take over
maintainership of it.

Bryan

[1] - <http://trac.macports.org/browser/trunk/base/ChangeLog>


From afb at macports.org  Fri Nov  7 00:05:16 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Fri, 7 Nov 2008 09:05:16 +0100
Subject: MacPorts 1.7.0
In-Reply-To: <20081107030204.GL709@ninagal.withay.com>
References: <20081106221734.GE709@ninagal.withay.com>
	<49137BB9.2050001@macports.org>
	<20081107030204.GL709@ninagal.withay.com>
Message-ID: <9A95ED8B-4032-4151-83CE-84C9044AB88E@macports.org>

Bryan Blackburn wrote:

>> Is there an effort afoot to address any low hanging fruit here  
>> that can
>> be incorporated into a 1.7.0
>> release without too much effort?  Or is it too late for that?
>
> Unless it's a really big deal, it'd be best to leave it for a later  
> release
> so 1.7.0 can be available.  We still see frequent reports of PATH  
> and Tcl
> env bug issues, so those long-standing issues can be dealt with  
> finally.

That could have been wrapped in a 1.6.1, but there are other changes  
too.
(such as dependency engine fixes that address some very common  
issues...)

But there shouldn't be any more stuff added to 1.7.0, rather the  
opposite
(postpone some things to 1.8) - had removing features not caused more  
bugs.
If there's anything easy that is omissed, then that can come in a 1.7.1
revision through "selfupdate" as long as the initial PKG work as  
expected.

The only rule I've seen so far is that only .0 releases get a disk  
image.
But "elsewhere" in development, major changes get major version  
increases
(usually when it breaks API, for instance new Portfile syntax for  
MacPorts)
but minor bugfixes and such can go as revisions with minor version  
numbers.

The sooner the release_1_7 branch can be created and tested as betas,
the better. But I know that svnmerge caused a lot of grief last time.

--anders


From florian.ebeling at gmail.com  Fri Nov  7 00:55:04 2008
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Fri, 7 Nov 2008 09:55:04 +0100
Subject: [macports-mgr] Dependencies and variants
In-Reply-To: <20081106220953.GD709@ninagal.withay.com>
References: <F89E5DD8-13CD-4B3D-A550-8C04730F7054@kallisys.net>
	<20081106012228.GJ454@ninagal.withay.com>
	<8232025E-E1B0-4850-A0C2-3A5E966F3C55@kallisys.net>
	<20081106085941.GX454@ninagal.withay.com>
	<46A78A84-5121-4C0E-B8C0-31806EFE28D2@kallisys.net>
	<F343E143-FD21-4FE2-8C7A-5A355BB4B3DE@macports.org>
	<0A208A9E-F188-4787-8BF4-DFB27AB39370@kallisys.net>
	<5cbbe4ae0811061204s13ff02b9se2983b5911008216@mail.gmail.com>
	<20081106220953.GD709@ninagal.withay.com>
Message-ID: <5cbbe4ae0811070055i24e7d807ma3a0acfaeb4255da@mail.gmail.com>

On Thu, Nov 6, 2008 at 11:09 PM, Bryan Blackburn <blb at macports.org> wrote:
> On Thu, Nov 06, 2008 at 09:04:44PM +0100, C. Florian Ebeling said:
>> On Thu, Nov 6, 2008 at 11:27 AM, Paul Guyot <pguyot at kallisys.net> wrote:
>> >
>> > Le 6 nov. 08 ? 10:44, Ryan Schmidt a ?crit :
>> >
>> >> I would still like this discussion to take place on macports-dev, not
>> >> macports-mgr.
>> >
>> > True.
>>
>> Why are such things discussed on a closed list?! I was already
>> wondering why there is no discussion going on. Isn't this projects
>> also built on the notion of openness etc? Also I didn't hear
>> anything about the R-word since the the management is
>> in office.
>
> Probably because it just started there, until as you see, it moved to -dev.
> As far as 1.7, I'll put out an email here in a minute about it.

ok, sounds fine. sorry, was a bit tired yesterday.


>
> Bryan
>
>
>>
>> I think I'm a patient person but mp starts to bore me abit tbh.
>>
>>
> [...]
>>
>> --
>> Florian Ebeling
>> Twitter: febeling
>> florian.ebeling at gmail.com
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>



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

From raimue at macports.org  Fri Nov  7 05:50:17 2008
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Fri, 07 Nov 2008 14:50:17 +0100
Subject: [macports-mgr] Dependencies and variants
In-Reply-To: <5cbbe4ae0811061204s13ff02b9se2983b5911008216@mail.gmail.com>
References: <F89E5DD8-13CD-4B3D-A550-8C04730F7054@kallisys.net>	<20081106012228.GJ454@ninagal.withay.com>	<8232025E-E1B0-4850-A0C2-3A5E966F3C55@kallisys.net>	<20081106085941.GX454@ninagal.withay.com>	<46A78A84-5121-4C0E-B8C0-31806EFE28D2@kallisys.net>	<F343E143-FD21-4FE2-8C7A-5A355BB4B3DE@macports.org>	<0A208A9E-F188-4787-8BF4-DFB27AB39370@kallisys.net>
	<5cbbe4ae0811061204s13ff02b9se2983b5911008216@mail.gmail.com>
Message-ID: <49144799.7050109@macports.org>

C. Florian Ebeling wrote:
> On Thu, Nov 6, 2008 at 11:27 AM, Paul Guyot <pguyot at kallisys.net> wrote:
>> Le 6 nov. 08 ? 10:44, Ryan Schmidt a ?crit :
>>
>>> I would still like this discussion to take place on macports-dev, not
>>> macports-mgr.
>> True.
> 
> Why are such things discussed on a closed list?! I was already
> wondering why there is no discussion going on. Isn't this projects
> also built on the notion of openness etc? Also I didn't hear
> anything about the R-word since the the management is
> in office.

There was no real discussion on macports-mgr about this. Paul sent us a
mail to explain his changes to base in r41526 and r41527, but we asked
him to discuss this on macports-dev instead of macports-mgr. There is no
hidden discussion taking place. Sorry about the confusion.

About the release, see the separate thread started by Bryan.

Rainer

From raimue at macports.org  Fri Nov  7 05:52:44 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Fri, 07 Nov 2008 14:52:44 +0100
Subject: MacPorts 1.7.0
In-Reply-To: <9A95ED8B-4032-4151-83CE-84C9044AB88E@macports.org>
References: <20081106221734.GE709@ninagal.withay.com>	<49137BB9.2050001@macports.org>	<20081107030204.GL709@ninagal.withay.com>
	<9A95ED8B-4032-4151-83CE-84C9044AB88E@macports.org>
Message-ID: <4914482C.70508@macports.org>

Anders F Bj?rklund wrote:
> The sooner the release_1_7 branch can be created and tested as betas,
> the better. But I know that svnmerge caused a lot of grief last time.

But now we have svn 1.5 with merge tracking. Let's see :-)

I would say we branch off release_1_7 for the release candidates once
the last remaining tickets are fixed.

Rainer

From n.oxyde at gmail.com  Fri Nov  7 08:45:31 2008
From: n.oxyde at gmail.com (nox)
Date: Fri, 7 Nov 2008 17:45:31 +0100
Subject: [macports-mgr] Dependencies and variants
In-Reply-To: <49144799.7050109@macports.org>
References: <F89E5DD8-13CD-4B3D-A550-8C04730F7054@kallisys.net>	<20081106012228.GJ454@ninagal.withay.com>	<8232025E-E1B0-4850-A0C2-3A5E966F3C55@kallisys.net>	<20081106085941.GX454@ninagal.withay.com>	<46A78A84-5121-4C0E-B8C0-31806EFE28D2@kallisys.net>	<F343E143-FD21-4FE2-8C7A-5A355BB4B3DE@macports.org>	<0A208A9E-F188-4787-8BF4-DFB27AB39370@kallisys.net>
	<5cbbe4ae0811061204s13ff02b9se2983b5911008216@mail.gmail.com>
	<49144799.7050109@macports.org>
Message-ID: <065AD6F2-8863-4ED5-BAF5-4F7E88216094@gmail.com>

Le 7 nov. 08 ? 14:50, Rainer M?ller a ?crit :
> There was no real discussion on macports-mgr about this.

You don't have to make up lies, we all know you are conspiracing to  
take over the world.
We will support you. You just have to take it over with  
openmaintainership.

From devans at macports.org  Fri Nov  7 17:25:28 2008
From: devans at macports.org (David Evans)
Date: Fri, 07 Nov 2008 17:25:28 -0800
Subject: Strange errors with port
Message-ID: <4914EA88.5030508@macports.org>

Since upgrading trunk from svn today, port randomly crashes with the
following error types:

segmentation fault
buss error

and my favorite

tclsh(16432,0xa000ed88) malloc: *** error for object 0x3128a0: incorrect
checksum for freed object - object was probably modified after being
freed, break at szone_error to debug
tclsh(16432,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug

The last one often (but not always) occurs at the end of the
configuration phase.

I scrubbed base and updated from svn and reinstalled with no change in
this behavior.

Has anyone else run into the same thing?

Dave

From blb at macports.org  Sat Nov  8 00:35:54 2008
From: blb at macports.org (Bryan Blackburn)
Date: Sat, 8 Nov 2008 01:35:54 -0700
Subject: Strange errors with port
In-Reply-To: <4914EA88.5030508@macports.org>
References: <4914EA88.5030508@macports.org>
Message-ID: <20081108083554.GW657@ninagal.withay.com>

On Fri, Nov 07, 2008 at 05:25:28PM -0800, David Evans said:
> Since upgrading trunk from svn today, port randomly crashes with the
> following error types:
> 
> segmentation fault
> buss error
> 
> and my favorite
> 
> tclsh(16432,0xa000ed88) malloc: *** error for object 0x3128a0: incorrect
> checksum for freed object - object was probably modified after being
> freed, break at szone_error to debug
> tclsh(16432,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug
> 
> The last one often (but not always) occurs at the end of the
> configuration phase.
> 
> I scrubbed base and updated from svn and reinstalled with no change in
> this behavior.
> 
> Has anyone else run into the same thing?

Yeah, it appears that 10.4 or at least tclsh on 10.4 doesn't like the method
I used to clear out the environment for the Tcl env bug.  I guess that
technique isn't quite so completely cross platform...

I'm putting together a safer version now and testing it on 10.3-10.5 this
time.

Bryan


> 
> Dave

From devans at macports.org  Sat Nov  8 19:35:08 2008
From: devans at macports.org (David Evans)
Date: Sat, 08 Nov 2008 19:35:08 -0800
Subject: ASSP out of date
In-Reply-To: <08D5DB3B-2C9F-4458-8CB6-4811E90A0B85@newgeo.com>
References: <49123482.5010305@macports.org>	<230DCBED-6A40-4921-9226-EC5F6DB53E71@newgeo.com>	<20081106040511.GO454@ninagal.withay.com>	<1F4CAB57-B9F8-475B-A7F6-C12F614FED63@newgeo.com>	<F0502140-F139-4577-9E7A-9B2F810A89BD@macports.org>	<A4356F68-0525-4620-BA97-7A7E5A0542BE@newgeo.com>	<8D19E4C3-C03C-4092-AA48-674F1F8DCFF6@macports.org>	<57525FAB-8AE9-49AF-ABA5-83B49FE12FBE@newgeo.com>	<29A51E92-AEA1-4CFD-9760-3EAACBA7FF50@macports.org>	<AA0C6C61-5023-4AC1-A81F-9F75199B1628@newgeo.com>	<20081106090638.GY454@ninagal.withay.com>	<E75D9EB5-4903-4E04-8BD5-6EB3D795726B@newgeo.com>
	<F3141E72-51FC-457C-ABA4-E5039411C394@newgeo.com>
	<49161589.5020702@macports.org>
	<08D5DB3B-2C9F-4458-8CB6-4811E90A0B85@newgeo.com>
Message-ID: <49165A6C.40506@macports.org>

Scott Haneda wrote:
>> Concerning the dependencies
>> if there are so many, perhaps if you published a list of what's needed
>> others might lend a hand.
>
> Sure, I can find some, but not others:
> Net::DNS
> Compress::Zlib
> Digest::MD5
> Email::MIME::Modifier new
> Email::Valid
> File::ReadBackwards
> Mail::SPF new
> Mail::SPF::Query
> Mail::SRS
> Net::CIDR::Lite new
> Net::IP::Match::Regexp new
> Net::LDAP
> Net::SMTP new
> Net::SenderBase new
> Net::Syslog
> Sys::Syslog
> Tie::RDBM
> Time::HiRes
> Win32::Daemon
A lot of these are there already you can use

port contents perl5.8

to see a list of the files installed with the basic perl (after you have
installed it)

and

port search p5-

will give you a list of other perl modules available such as

p5-compress-zlib
p5-digest-md5
p5-email-valid
p5-net-dns
p5-time-hires

to pick just a few quickly -- you get the idea

Dave
>
> I assume ClamAV, which is not in that list, should be already
> available, and ready to go.
>


From devans at macports.org  Sat Nov  8 19:38:01 2008
From: devans at macports.org (David Evans)
Date: Sat, 08 Nov 2008 19:38:01 -0800
Subject: ASSP out of date
In-Reply-To: <49165A6C.40506@macports.org>
References: <49123482.5010305@macports.org>	<230DCBED-6A40-4921-9226-EC5F6DB53E71@newgeo.com>	<20081106040511.GO454@ninagal.withay.com>	<1F4CAB57-B9F8-475B-A7F6-C12F614FED63@newgeo.com>	<F0502140-F139-4577-9E7A-9B2F810A89BD@macports.org>	<A4356F68-0525-4620-BA97-7A7E5A0542BE@newgeo.com>	<8D19E4C3-C03C-4092-AA48-674F1F8DCFF6@macports.org>	<57525FAB-8AE9-49AF-ABA5-83B49FE12FBE@newgeo.com>	<29A51E92-AEA1-4CFD-9760-3EAACBA7FF50@macports.org>	<AA0C6C61-5023-4AC1-A81F-9F75199B1628@newgeo.com>	<20081106090638.GY454@ninagal.withay.com>	<E75D9EB5-4903-4E04-8BD5-6EB3D795726B@newgeo.com>	<F3141E72-51FC-457C-ABA4-E5039411C394@newgeo.com>	<49161589.5020702@macports.org>	<08D5DB3B-2C9F-4458-8CB6-4811E90A0B85@newgeo.com>
	<49165A6C.40506@macports.org>
Message-ID: <49165B19.9070506@macports.org>

wrong list, sorry

From frstan at bellsouth.net  Sun Nov  9 06:03:04 2008
From: frstan at bellsouth.net (William Davis)
Date: Sun, 9 Nov 2008 09:03:04 -0500
Subject: portindex updates
Message-ID: <ADF10BE4-6F9C-4F10-ACEB-A4D1F7B5AB97@bellsouth.net>

RSS just told me:

Commit by ryandesign at macports.org :: r41701 /trunk/base/src/port/ 
portindex.tcl: (link)
http://trac.macports.org/changeset/41701
portindex.tcl: Generate the port index in a temporary file first, then  
replace the PortIndex file all at once; fixes #16234

If this is the case cant we easily update the index more than twice a  
day now?  Perhaps even every half hour?




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

Mundus vult decepi, ego non

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

From dluke at geeklair.net  Sun Nov  9 07:31:02 2008
From: dluke at geeklair.net (Daniel J. Luke)
Date: Sun, 9 Nov 2008 10:31:02 -0500
Subject: portindex updates
In-Reply-To: <ADF10BE4-6F9C-4F10-ACEB-A4D1F7B5AB97@bellsouth.net>
References: <ADF10BE4-6F9C-4F10-ACEB-A4D1F7B5AB97@bellsouth.net>
Message-ID: <4B57A93C-DC3C-416E-8378-F41512BF57A2@geeklair.net>

On Nov 9, 2008, at 9:03 AM, William Davis wrote:
> Commit by ryandesign at macports.org :: r41701 /trunk/base/src/port/ 
> portindex.tcl: (link)
> http://trac.macports.org/changeset/41701
> portindex.tcl: Generate the port index in a temporary file first,  
> then replace the PortIndex file all at once; fixes #16234
>
> If this is the case cant we easily update the index more than twice  
> a day now?  Perhaps even every half hour?


portindex is an annoyingly expensive operation. I don't know if the  
added load on the macports servers would be worth it?

If someone gets around to implementing an incremental portindex option  
(say we store the index in an sqlite database and we add a post-commit  
hook that just updates the index entries for the ports that were just  
committed) then we could probably have an always up-to-date index  
without the huge resource requirements.

--
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/20081109/86ff1306/attachment.bin>

From frstan at bellsouth.net  Sun Nov  9 07:48:14 2008
From: frstan at bellsouth.net (William Davis)
Date: Sun, 9 Nov 2008 10:48:14 -0500
Subject: portindex updates
In-Reply-To: <4B57A93C-DC3C-416E-8378-F41512BF57A2@geeklair.net>
References: <ADF10BE4-6F9C-4F10-ACEB-A4D1F7B5AB97@bellsouth.net>
	<4B57A93C-DC3C-416E-8378-F41512BF57A2@geeklair.net>
Message-ID: <F6726AB5-4E28-4718-B5E2-89E6EFDC89F8@bellsouth.net>


On Nov 9, 2008, at 10:31 AM, Daniel J. Luke wrote:

> On Nov 9, 2008, at 9:03 AM, William Davis wrote:
>> Commit by ryandesign at macports.org :: r41701 /trunk/base/src/port/ 
>> portindex.tcl: (link)
>> http://trac.macports.org/changeset/41701
>> portindex.tcl: Generate the port index in a temporary file first,  
>> then replace the PortIndex file all at once; fixes #16234
>>
>> If this is the case cant we easily update the index more than twice  
>> a day now?  Perhaps even every half hour?
>
>
> portindex is an annoyingly expensive operation. I don't know if the  
> added load on the macports servers would be worth it?
>
> If someone gets around to implementing an incremental portindex  
> option (say we store the index in an sqlite database and we add a  
> post-commit hook that just updates the index entries for the ports  
> that were just committed) then we could probably have an always up- 
> to-date index without the huge resource requirements.
>
> --
> 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.          |
> +========================================================+
>
>
>

Daniel, I think that is a wonderful idea.  It is beyond my skill  
level, but hopefully once MacPorts 1.7 is out, someone will come  
forward to work on that.

WD




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

Mundus vult decepi, ego non


From frstan at bellsouth.net  Sun Nov  9 08:02:28 2008
From: frstan at bellsouth.net (William Davis)
Date: Sun, 9 Nov 2008 11:02:28 -0500
Subject: portindex updates
In-Reply-To: <4B57A93C-DC3C-416E-8378-F41512BF57A2@geeklair.net>
References: <ADF10BE4-6F9C-4F10-ACEB-A4D1F7B5AB97@bellsouth.net>
	<4B57A93C-DC3C-416E-8378-F41512BF57A2@geeklair.net>
Message-ID: <36E9DE5C-1717-447A-8744-EEEDD4BD31F8@bellsouth.net>


On Nov 9, 2008, at 10:31 AM, Daniel J. Luke wrote:

> On Nov 9, 2008, at 9:03 AM, William Davis wrote:
>> Commit by ryandesign at macports.org :: r41701 /trunk/base/src/port/ 
>> portindex.tcl: (link)
>> http://trac.macports.org/changeset/41701
>> portindex.tcl: Generate the port index in a temporary file first,  
>> then replace the PortIndex file all at once; fixes #16234
>>
>> If this is the case cant we easily update the index more than twice  
>> a day now?  Perhaps even every half hour?
>
>
> portindex is an annoyingly expensive operation. I don't know if the  
> added load on the macports servers would be worth it?
>
> If someone gets around to implementing an incremental portindex  
> option (say we store the index in an sqlite database and we add a  
> post-commit hook that just updates the index entries for the ports  
> that were just committed) then we could probably have an always up- 
> to-date index without the huge resource requirements.
>
> --
> 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.          |
> +========================================================+
>
>
>

I have written an enhancement request ticket on this:
Ticket #17157 (new enhancement)


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

Mundus vult decepi, ego non

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20081109/a13efda3/attachment-0001.html>

From jkh at apple.com  Sun Nov  9 14:32:19 2008
From: jkh at apple.com (Jordan K. Hubbard)
Date: Sun, 9 Nov 2008 14:32:19 -0800
Subject: portindex updates
In-Reply-To: <4B57A93C-DC3C-416E-8378-F41512BF57A2@geeklair.net>
References: <ADF10BE4-6F9C-4F10-ACEB-A4D1F7B5AB97@bellsouth.net>
	<4B57A93C-DC3C-416E-8378-F41512BF57A2@geeklair.net>
Message-ID: <09227A50-2DDA-45F7-B581-ED071565AD5D@apple.com>


On Nov 9, 2008, at 7:31 AM, Daniel J. Luke wrote:

> If someone gets around to implementing an incremental portindex  
> option (say we store the index in an sqlite database and we add a  
> post-commit hook that just updates the index entries for the ports  
> that were just committed) then we could probably have an always up- 
> to-date index without the huge resource requirements.

Of course, if someone gets around to finishing Kevin's "remote  
index" (or just starting over with it, given the age of those bits)  
then we wouldn't even need a PortIndex since ports would always live  
on the server and simply be pulled over individually as needed or  
mirrored as one big database to some local server.  Either way, the  
index would be a property of the database itself and get updated  
simply as a consequence of adding new ports to it.  We could also tag  
ports with attributes then ("experimental", "stable", "submitted-but- 
not-validated") and solve another set of problems in the process...     
I know, I know, I suppose I want a pony, too...

- Jordan


From raimue at macports.org  Sun Nov  9 18:02:42 2008
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Mon, 10 Nov 2008 03:02:42 +0100
Subject: [40056] trunk/base/src
In-Reply-To: <20080919024247.806DE383469@beta.macosforge.org>
References: <20080919024247.806DE383469@beta.macosforge.org>
Message-ID: <49179642.8010709@macports.org>

toby at macports.org wrote:
> Revision: 40056
>           http://trac.macports.org/changeset/40056
> Author:   toby at macports.org
> Date:     2008-09-18 19:42:46 -0700 (Thu, 18 Sep 2008)
> Log Message:
> -----------
> Stop setting MACOSX_DEPLOYMENT_TARGET
> 
> Modified Paths:
> --------------
>     trunk/base/src/pextlib1.0/Makefile
>     trunk/base/src/registry2.0/Makefile
>     trunk/base/src/tclobjc1.0/Makefile.in
> 
> Modified: trunk/base/src/pextlib1.0/Makefile
> ===================================================================
> --- trunk/base/src/pextlib1.0/Makefile	2008-09-19 02:33:48 UTC (rev 40055)
> +++ trunk/base/src/pextlib1.0/Makefile	2008-09-19 02:42:46 UTC (rev 40056)
> @@ -4,7 +4,6 @@
>  		tracelib.o tty.o
>  SHLIB_NAME=	Pextlib${SHLIB_SUFFIX}
>  INSTALLDIR= ${DESTDIR}${datadir}/macports/Tcl/pextlib1.0
> -export MACOSX_DEPLOYMENT_TARGET=10.3
>  
>  include ../../Mk/macports.autoconf.mk
>  include ../../Mk/macports.tea.mk
> 
[...]

This revision broke tracemode on trunk. Now I get a lot of the following
warnings, using 'port -t':
  Warning: setrlimit failed (22)

errno 22 is EINVAL.

According to the man page of setrlimit(2), the interface changed
somewhere between 10.3 and 10.5:

| COMPATIBILITY
|      setrlimit() now returns with errno set to EINVAL in places that
historically
|      succeeded.  It no longer accepts "rlim_cur = RLIM_INFINITY" for
RLIM_NOFILE.
|      Use "rlim_cur = min(OPEN_MAX, rlim_max)".

We should either restore the MACOSX_DEPLOYMENT_TARGET or change that
code in TracelibRunCmd() in pextlib1.0/tracelib.c.

Rainer

From ryandesign at macports.org  Sun Nov  9 18:49:16 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 9 Nov 2008 20:49:16 -0600
Subject: portindex updates
In-Reply-To: <ADF10BE4-6F9C-4F10-ACEB-A4D1F7B5AB97@bellsouth.net>
References: <ADF10BE4-6F9C-4F10-ACEB-A4D1F7B5AB97@bellsouth.net>
Message-ID: <AD6B85EB-334F-4153-B1D4-ED94AAD8BB28@macports.org>


On Nov 9, 2008, at 08:03, William Davis wrote:

> RSS just told me:
>
>> Commit by ryandesign at macports.org :: r41701 /trunk/base/src/port/ 
>> portindex.tcl: (link)
>> http://trac.macports.org/changeset/41701
>> portindex.tcl: Generate the port index in a temporary file first,  
>> then replace the PortIndex file all at once; fixes #16234
>
>
> If this is the case cant we easily update the index more than twice  
> a day now?  Perhaps even every half hour?

I don't think my commit changes anything for the frequency of  
portindex updates. All it does is make sure that until the new  
portindex is done being regenerated, the old portindex is still  
around so it can be used by other port operations.

I don't know why the portindex is only regenerated every 12 hours.


From frstan at bellsouth.net  Sun Nov  9 19:12:50 2008
From: frstan at bellsouth.net (William Davis)
Date: Sun, 9 Nov 2008 22:12:50 -0500
Subject: portindex updates
In-Reply-To: <AD6B85EB-334F-4153-B1D4-ED94AAD8BB28@macports.org>
References: <ADF10BE4-6F9C-4F10-ACEB-A4D1F7B5AB97@bellsouth.net>
	<AD6B85EB-334F-4153-B1D4-ED94AAD8BB28@macports.org>
Message-ID: <9DFF66D3-99A4-4AE3-8050-D2F474610CAE@bellsouth.net>


On Nov 9, 2008, at 9:49 PM, Ryan Schmidt wrote:

>
> On Nov 9, 2008, at 08:03, William Davis wrote:
>
>> RSS just told me:
>>
>>> Commit by ryandesign at macports.org :: r41701 /trunk/base/src/port/ 
>>> portindex.tcl: (link)
>>> http://trac.macports.org/changeset/41701
>>> portindex.tcl: Generate the port index in a temporary file first,  
>>> then replace the PortIndex file all at once; fixes #16234
>>
>>
>> If this is the case cant we easily update the index more than twice  
>> a day now?  Perhaps even every half hour?
>
> I don't think my commit changes anything for the frequency of  
> portindex updates. All it does is make sure that until the new  
> portindex is done being regenerated, the old portindex is still  
> around so it can be used by other port operations.
>
> I don't know why the portindex is only regenerated every 12 hours.
>

Ryan, I know you didnt change the update frequency.  My point was that  
with your change in place it seems possible  AFTERWARDS to update the  
index more frequently now that the old index can be used while the new  
one is building.




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

Mundus vult decepi, ego non


From ryandesign at macports.org  Sun Nov  9 19:33:11 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 9 Nov 2008 21:33:11 -0600
Subject: portindex updates
In-Reply-To: <9DFF66D3-99A4-4AE3-8050-D2F474610CAE@bellsouth.net>
References: <ADF10BE4-6F9C-4F10-ACEB-A4D1F7B5AB97@bellsouth.net>
	<AD6B85EB-334F-4153-B1D4-ED94AAD8BB28@macports.org>
	<9DFF66D3-99A4-4AE3-8050-D2F474610CAE@bellsouth.net>
Message-ID: <911B0AB4-36C0-45D0-BFBC-1A80CE931097@macports.org>

On Nov 9, 2008, at 21:12, William Davis wrote:

> On Nov 9, 2008, at 9:49 PM, Ryan Schmidt wrote:
>
>> On Nov 9, 2008, at 08:03, William Davis wrote:
>>
>>> RSS just told me:
>>>
>>>> Commit by ryandesign at macports.org :: r41701 /trunk/base/src/port/ 
>>>> portindex.tcl: (link)
>>>> http://trac.macports.org/changeset/41701
>>>> portindex.tcl: Generate the port index in a temporary file  
>>>> first, then replace the PortIndex file all at once; fixes #16234
>>>
>>>
>>> If this is the case cant we easily update the index more than  
>>> twice a day now?  Perhaps even every half hour?
>>
>> I don't think my commit changes anything for the frequency of  
>> portindex updates. All it does is make sure that until the new  
>> portindex is done being regenerated, the old portindex is still  
>> around so it can be used by other port operations.
>>
>> I don't know why the portindex is only regenerated every 12 hours.
>
> Ryan, I know you didnt change the update frequency.  My point was  
> that with your change in place it seems possible  AFTERWARDS to  
> update the index more frequently now that the old index can be used  
> while the new one is building.

I didn't think the server used the portindex for anything.


From frstan at bellsouth.net  Sun Nov  9 20:05:22 2008
From: frstan at bellsouth.net (William Davis)
Date: Sun, 9 Nov 2008 23:05:22 -0500
Subject: portindex updates
In-Reply-To: <911B0AB4-36C0-45D0-BFBC-1A80CE931097@macports.org>
References: <ADF10BE4-6F9C-4F10-ACEB-A4D1F7B5AB97@bellsouth.net>
	<AD6B85EB-334F-4153-B1D4-ED94AAD8BB28@macports.org>
	<9DFF66D3-99A4-4AE3-8050-D2F474610CAE@bellsouth.net>
	<911B0AB4-36C0-45D0-BFBC-1A80CE931097@macports.org>
Message-ID: <191B8DAD-2EE5-46D0-96D6-407ECF626D67@bellsouth.net>


On Nov 9, 2008, at 10:33 PM, Ryan Schmidt wrote:

> On Nov 9, 2008, at 21:12, William Davis wrote:
>
>> On Nov 9, 2008, at 9:49 PM, Ryan Schmidt wrote:
>>
>>> On Nov 9, 2008, at 08:03, William Davis wrote:
>>>
>>>> RSS just told me:
>>>>
>>>>> Commit by ryandesign at macports.org :: r41701 /trunk/base/src/port/ 
>>>>> portindex.tcl: (link)
>>>>> http://trac.macports.org/changeset/41701
>>>>> portindex.tcl: Generate the port index in a temporary file  
>>>>> first, then replace the PortIndex file all at once; fixes #16234
>>>>
>>>>
>>>> If this is the case cant we easily update the index more than  
>>>> twice a day now?  Perhaps even every half hour?
>>>
>>> I don't think my commit changes anything for the frequency of  
>>> portindex updates. All it does is make sure that until the new  
>>> portindex is done being regenerated, the old portindex is still  
>>> around so it can be used by other port operations.
>>>
>>> I don't know why the portindex is only regenerated every 12 hours.
>>
>> Ryan, I know you didnt change the update frequency.  My point was  
>> that with your change in place it seems possible  AFTERWARDS to  
>> update the index more frequently now that the old index can be used  
>> while the new one is building.
>
> I didn't think the server used the portindex for anything.
>

It doesnt as far I know, but the people who are running selfupdate do,  
dont they?




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

Mundus vult decepi, ego non


From blb at macports.org  Sun Nov  9 20:24:41 2008
From: blb at macports.org (Bryan Blackburn)
Date: Sun, 9 Nov 2008 21:24:41 -0700
Subject: portindex updates
In-Reply-To: <191B8DAD-2EE5-46D0-96D6-407ECF626D67@bellsouth.net>
References: <ADF10BE4-6F9C-4F10-ACEB-A4D1F7B5AB97@bellsouth.net>
	<AD6B85EB-334F-4153-B1D4-ED94AAD8BB28@macports.org>
	<9DFF66D3-99A4-4AE3-8050-D2F474610CAE@bellsouth.net>
	<911B0AB4-36C0-45D0-BFBC-1A80CE931097@macports.org>
	<191B8DAD-2EE5-46D0-96D6-407ECF626D67@bellsouth.net>
Message-ID: <20081110042441.GK519@ninagal.withay.com>

On Sun, Nov 09, 2008 at 11:05:22PM -0500, William Davis said:
>
> On Nov 9, 2008, at 10:33 PM, Ryan Schmidt wrote:
>
>> On Nov 9, 2008, at 21:12, William Davis wrote:
>>
>>> On Nov 9, 2008, at 9:49 PM, Ryan Schmidt wrote:
>>>
>>>> On Nov 9, 2008, at 08:03, William Davis wrote:
>>>>
>>>>> RSS just told me:
>>>>>
>>>>>> Commit by ryandesign at macports.org :: r41701 
>>>>>> /trunk/base/src/port/portindex.tcl: (link)
>>>>>> http://trac.macports.org/changeset/41701
>>>>>> portindex.tcl: Generate the port index in a temporary file  
>>>>>> first, then replace the PortIndex file all at once; fixes #16234
>>>>>
>>>>>
>>>>> If this is the case cant we easily update the index more than  
>>>>> twice a day now?  Perhaps even every half hour?
>>>>
>>>> I don't think my commit changes anything for the frequency of  
>>>> portindex updates. All it does is make sure that until the new  
>>>> portindex is done being regenerated, the old portindex is still  
>>>> around so it can be used by other port operations.
>>>>
>>>> I don't know why the portindex is only regenerated every 12 hours.
>>>
>>> Ryan, I know you didnt change the update frequency.  My point was  
>>> that with your change in place it seems possible  AFTERWARDS to  
>>> update the index more frequently now that the old index can be used  
>>> while the new one is building.
>>
>> I didn't think the server used the portindex for anything.
>>
>
> It doesnt as far I know, but the people who are running selfupdate do,  
> dont they?

That change to portindex only affects when you run it, using selfupdate
simply gets the new PortIndex from the server.  Hence, this shouldn't be
affecting you unless you also have a local repository and run portindex on
it (which I think was the initial reason for the ticket which resulted in
the change).

Bryan


>
>
>
>
> William Davis
> frstanATbellsouthDOTnet
> Mac OS X.5.5 Darwin 9.5.0
> XQuartz 2.3.2 (xorg-server 1.4.2-apple21)
> Mac Mini Intel Duo @ 1.86 GHz
>
> Mundus vult decepi, ego non
>

From frstan at bellsouth.net  Sun Nov  9 20:48:51 2008
From: frstan at bellsouth.net (William Davis)
Date: Sun, 9 Nov 2008 23:48:51 -0500
Subject: portindex updates
In-Reply-To: <20081110042441.GK519@ninagal.withay.com>
References: <ADF10BE4-6F9C-4F10-ACEB-A4D1F7B5AB97@bellsouth.net>
	<AD6B85EB-334F-4153-B1D4-ED94AAD8BB28@macports.org>
	<9DFF66D3-99A4-4AE3-8050-D2F474610CAE@bellsouth.net>
	<911B0AB4-36C0-45D0-BFBC-1A80CE931097@macports.org>
	<191B8DAD-2EE5-46D0-96D6-407ECF626D67@bellsouth.net>
	<20081110042441.GK519@ninagal.withay.com>
Message-ID: <909C09C8-7B87-49CC-8C52-F7DEAF8340B8@bellsouth.net>


On Nov 9, 2008, at 11:24 PM, Bryan Blackburn wrote:

> On Sun, Nov 09, 2008 at 11:05:22PM -0500, William Davis said:
>>
>> On Nov 9, 2008, at 10:33 PM, Ryan Schmidt wrote:
>>
>>> On Nov 9, 2008, at 21:12, William Davis wrote:
>>>
>>>> On Nov 9, 2008, at 9:49 PM, Ryan Schmidt wrote:
>>>>
>>>>> On Nov 9, 2008, at 08:03, William Davis wrote:
>>>>>
>>>>>> RSS just told me:
>>>>>>
>>>>>>> Commit by ryandesign at macports.org :: r41701
>>>>>>> /trunk/base/src/port/portindex.tcl: (link)
>>>>>>> http://trac.macports.org/changeset/41701
>>>>>>> portindex.tcl: Generate the port index in a temporary file
>>>>>>> first, then replace the PortIndex file all at once; fixes #16234
>>>>>>
>>>>>>
>>>>>> If this is the case cant we easily update the index more than
>>>>>> twice a day now?  Perhaps even every half hour?
>>>>>
>>>>> I don't think my commit changes anything for the frequency of
>>>>> portindex updates. All it does is make sure that until the new
>>>>> portindex is done being regenerated, the old portindex is still
>>>>> around so it can be used by other port operations.
>>>>>
>>>>> I don't know why the portindex is only regenerated every 12 hours.
>>>>
>>>> Ryan, I know you didnt change the update frequency.  My point was
>>>> that with your change in place it seems possible  AFTERWARDS to
>>>> update the index more frequently now that the old index can be used
>>>> while the new one is building.
>>>
>>> I didn't think the server used the portindex for anything.
>>>
>>
>> It doesnt as far I know, but the people who are running selfupdate  
>> do,
>> dont they?
>
> That change to portindex only affects when you run it, using  
> selfupdate
> simply gets the new PortIndex from the server.  Hence, this  
> shouldn't be
> affecting you unless you also have a local repository and run  
> portindex on
> it (which I think was the initial reason for the ticket which  
> resulted in
> the change).
>
> Bryan


I'll try one more time: Ryan made a change that will cause portindex  
to be updated all at once by building it in a temp file and then  
overwritting the old file all at once.
THEREFORE
there will be no problem with sections of portindex being locked when  
someone runs selfupdate.
THEREFORE
unless there are other constrains, it should now be possible to update  
portindex more often without end-users having problems.

Im speaking here from the end-user's point of view.



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

Mundus vult decepi, ego non


From ryandesign at macports.org  Sun Nov  9 21:15:34 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 9 Nov 2008 23:15:34 -0600
Subject: portindex updates
In-Reply-To: <191B8DAD-2EE5-46D0-96D6-407ECF626D67@bellsouth.net>
References: <ADF10BE4-6F9C-4F10-ACEB-A4D1F7B5AB97@bellsouth.net>
	<AD6B85EB-334F-4153-B1D4-ED94AAD8BB28@macports.org>
	<9DFF66D3-99A4-4AE3-8050-D2F474610CAE@bellsouth.net>
	<911B0AB4-36C0-45D0-BFBC-1A80CE931097@macports.org>
	<191B8DAD-2EE5-46D0-96D6-407ECF626D67@bellsouth.net>
Message-ID: <E068299C-51EB-4C0F-9CBE-AC9843321E89@macports.org>

On Nov 9, 2008, at 22:05, William Davis wrote:

> On Nov 9, 2008, at 10:33 PM, Ryan Schmidt wrote:
>
>> On Nov 9, 2008, at 21:12, William Davis wrote:
>>
>>> On Nov 9, 2008, at 9:49 PM, Ryan Schmidt wrote:
>>>
>>>> On Nov 9, 2008, at 08:03, William Davis wrote:
>>>>
>>>>> RSS just told me:
>>>>>
>>>>>> Commit by ryandesign at macports.org :: r41701 /trunk/base/src/ 
>>>>>> port/portindex.tcl: (link)
>>>>>> http://trac.macports.org/changeset/41701
>>>>>> portindex.tcl: Generate the port index in a temporary file  
>>>>>> first, then replace the PortIndex file all at once; fixes #16234
>>>>>
>>>>> If this is the case cant we easily update the index more than  
>>>>> twice a day now?  Perhaps even every half hour?
>>>>
>>>> I don't think my commit changes anything for the frequency of  
>>>> portindex updates. All it does is make sure that until the new  
>>>> portindex is done being regenerated, the old portindex is still  
>>>> around so it can be used by other port operations.
>>>>
>>>> I don't know why the portindex is only regenerated every 12 hours.
>>>
>>> Ryan, I know you didnt change the update frequency.  My point was  
>>> that with your change in place it seems possible  AFTERWARDS to  
>>> update the index more frequently now that the old index can be  
>>> used while the new one is building.
>>
>> I didn't think the server used the portindex for anything.
>
> It doesnt as far I know, but the people who are running selfupdate  
> do, dont they?

Surely the portindex is generated in one place (like where the svn  
working copy of dports is) and then this is synced to another place  
(the one where rsync syncs from). So even now there should never be a  
time when a user syncs and gets an incomplete portindex.

The only reason for the above ticket/commit is that I occasionally  
want to regenerate the portindex on my local machine, but during the  
minutes that takes to run, I might want to also do other things with  
MacPorts. Now I can.


From jmr at macports.org  Sun Nov  9 21:19:50 2008
From: jmr at macports.org (Joshua Root)
Date: Mon, 10 Nov 2008 16:19:50 +1100
Subject: portindex updates
In-Reply-To: <909C09C8-7B87-49CC-8C52-F7DEAF8340B8@bellsouth.net>
References: <ADF10BE4-6F9C-4F10-ACEB-A4D1F7B5AB97@bellsouth.net>	<AD6B85EB-334F-4153-B1D4-ED94AAD8BB28@macports.org>	<9DFF66D3-99A4-4AE3-8050-D2F474610CAE@bellsouth.net>	<911B0AB4-36C0-45D0-BFBC-1A80CE931097@macports.org>	<191B8DAD-2EE5-46D0-96D6-407ECF626D67@bellsouth.net>	<20081110042441.GK519@ninagal.withay.com>
	<909C09C8-7B87-49CC-8C52-F7DEAF8340B8@bellsouth.net>
Message-ID: <4917C476.7020600@macports.org>

William Davis wrote:
> I'll try one more time: Ryan made a change that will cause portindex to
> be updated all at once by building it in a temp file and then
> overwritting the old file all at once.
> THEREFORE
> there will be no problem with sections of portindex being locked when
> someone runs selfupdate.
> THEREFORE
> unless there are other constrains, it should now be possible to update
> portindex more often without end-users having problems.

Server-side, the new PortIndex is only committed to svn after it is
finished being regenerated, so an end user could never get a partial
index from rsync.

The issue with there being a partial index was only present when the
index in a local ports tree was rebuilt. The one advantage to end users
of updating the PortIndex more often would be that new ports would be
available sooner.

- Josh

From frstan at bellsouth.net  Sun Nov  9 22:33:25 2008
From: frstan at bellsouth.net (William Davis)
Date: Mon, 10 Nov 2008 01:33:25 -0500
Subject: portindex updates
In-Reply-To: <4917C476.7020600@macports.org>
References: <ADF10BE4-6F9C-4F10-ACEB-A4D1F7B5AB97@bellsouth.net>	<AD6B85EB-334F-4153-B1D4-ED94AAD8BB28@macports.org>	<9DFF66D3-99A4-4AE3-8050-D2F474610CAE@bellsouth.net>	<911B0AB4-36C0-45D0-BFBC-1A80CE931097@macports.org>	<191B8DAD-2EE5-46D0-96D6-407ECF626D67@bellsouth.net>	<20081110042441.GK519@ninagal.withay.com>
	<909C09C8-7B87-49CC-8C52-F7DEAF8340B8@bellsouth.net>
	<4917C476.7020600@macports.org>
Message-ID: <FDF1AB31-492D-4C57-9FFB-4EE99B1F0307@bellsouth.net>


On Nov 10, 2008, at 12:19 AM, Joshua Root wrote:

> William Davis wrote:
>> I'll try one more time: Ryan made a change that will cause  
>> portindex to
>> be updated all at once by building it in a temp file and then
>> overwritting the old file all at once.
>> THEREFORE
>> there will be no problem with sections of portindex being locked when
>> someone runs selfupdate.
>> THEREFORE
>> unless there are other constrains, it should now be possible to  
>> update
>> portindex more often without end-users having problems.
>
> Server-side, the new PortIndex is only committed to svn after it is
> finished being regenerated, so an end user could never get a partial
> index from rsync.
>
> The issue with there being a partial index was only present when the
> index in a local ports tree was rebuilt. The one advantage to end  
> users
> of updating the PortIndex more often would be that new ports would be
> available sooner.
>
> - Josh


No doubt you are quite right.  Still I wonder where those error mesgs  
saying something about port foo being updated I sometimes get inserted  
into the middle of the file list as its copyed down come from......

But! getting updates more often was indeed the point......

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

Mundus vult decepi, ego non


From blb at macports.org  Sun Nov  9 23:11:22 2008
From: blb at macports.org (Bryan Blackburn)
Date: Mon, 10 Nov 2008 00:11:22 -0700
Subject: portindex updates
In-Reply-To: <FDF1AB31-492D-4C57-9FFB-4EE99B1F0307@bellsouth.net>
References: <ADF10BE4-6F9C-4F10-ACEB-A4D1F7B5AB97@bellsouth.net>
	<AD6B85EB-334F-4153-B1D4-ED94AAD8BB28@macports.org>
	<9DFF66D3-99A4-4AE3-8050-D2F474610CAE@bellsouth.net>
	<911B0AB4-36C0-45D0-BFBC-1A80CE931097@macports.org>
	<191B8DAD-2EE5-46D0-96D6-407ECF626D67@bellsouth.net>
	<20081110042441.GK519@ninagal.withay.com>
	<909C09C8-7B87-49CC-8C52-F7DEAF8340B8@bellsouth.net>
	<4917C476.7020600@macports.org>
	<FDF1AB31-492D-4C57-9FFB-4EE99B1F0307@bellsouth.net>
Message-ID: <20081110071122.GM519@ninagal.withay.com>

On Mon, Nov 10, 2008 at 01:33:25AM -0500, William Davis said:
>
> On Nov 10, 2008, at 12:19 AM, Joshua Root wrote:
>
>> William Davis wrote:
>>> I'll try one more time: Ryan made a change that will cause portindex 
>>> to
>>> be updated all at once by building it in a temp file and then
>>> overwritting the old file all at once.
>>> THEREFORE
>>> there will be no problem with sections of portindex being locked when
>>> someone runs selfupdate.
>>> THEREFORE
>>> unless there are other constrains, it should now be possible to  
>>> update
>>> portindex more often without end-users having problems.
>>
>> Server-side, the new PortIndex is only committed to svn after it is
>> finished being regenerated, so an end user could never get a partial
>> index from rsync.
>>
>> The issue with there being a partial index was only present when the
>> index in a local ports tree was rebuilt. The one advantage to end users
>> of updating the PortIndex more often would be that new ports would be
>> available sooner.
>>
>> - Josh
>
>
> No doubt you are quite right.  Still I wonder where those error mesgs  
> saying something about port foo being updated I sometimes get inserted  
> into the middle of the file list as its copyed down come from......

How often do you see these, and do you have an example?  Perhaps you have
caught it during the time it's syncing between subversion and what the rsync
server offers.

>
> But! getting updates more often was indeed the point......

I think portindex currently takes 7-8 minutes to run, and probably puts a
load on the server, so that would be one limiting issue on just how often it
is run.

Bryan


>
> William Davis
> frstanATbellsouthDOTnet
> Mac OS X.5.5 Darwin 9.5.0
> XQuartz 2.3.2 (xorg-server 1.4.2-apple21)
> Mac Mini Intel Duo @ 1.86 GHz
>
> Mundus vult decepi, ego non
>

From wsiegrist at apple.com  Mon Nov 10 00:39:17 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Mon, 10 Nov 2008 00:39:17 -0800
Subject: portindex updates
In-Reply-To: <20081110071122.GM519@ninagal.withay.com>
References: <ADF10BE4-6F9C-4F10-ACEB-A4D1F7B5AB97@bellsouth.net>
	<AD6B85EB-334F-4153-B1D4-ED94AAD8BB28@macports.org>
	<9DFF66D3-99A4-4AE3-8050-D2F474610CAE@bellsouth.net>
	<911B0AB4-36C0-45D0-BFBC-1A80CE931097@macports.org>
	<191B8DAD-2EE5-46D0-96D6-407ECF626D67@bellsouth.net>
	<20081110042441.GK519@ninagal.withay.com>
	<909C09C8-7B87-49CC-8C52-F7DEAF8340B8@bellsouth.net>
	<4917C476.7020600@macports.org>
	<FDF1AB31-492D-4C57-9FFB-4EE99B1F0307@bellsouth.net>
	<20081110071122.GM519@ninagal.withay.com>
Message-ID: <52992BE5-395E-4C0B-AB09-833D3911A226@apple.com>

On Nov 9, 2008, at 11:11 PM, Bryan Blackburn wrote:

> On Mon, Nov 10, 2008 at 01:33:25AM -0500, William Davis said:
>>
>> On Nov 10, 2008, at 12:19 AM, Joshua Root wrote:
>>
>>> William Davis wrote:
>>>> I'll try one more time: Ryan made a change that will cause  
>>>> portindex
>>>> to
>>>> be updated all at once by building it in a temp file and then
>>>> overwritting the old file all at once.
>>>> THEREFORE
>>>> there will be no problem with sections of portindex being locked  
>>>> when
>>>> someone runs selfupdate.
>>>> THEREFORE
>>>> unless there are other constrains, it should now be possible to
>>>> update
>>>> portindex more often without end-users having problems.
>>>
>>> Server-side, the new PortIndex is only committed to svn after it is
>>> finished being regenerated, so an end user could never get a partial
>>> index from rsync.
>>>
>>> The issue with there being a partial index was only present when the
>>> index in a local ports tree was rebuilt. The one advantage to end  
>>> users
>>> of updating the PortIndex more often would be that new ports would  
>>> be
>>> available sooner.
>>>
>>> - Josh
>>
>>
>> No doubt you are quite right.  Still I wonder where those error mesgs
>> saying something about port foo being updated I sometimes get  
>> inserted
>> into the middle of the file list as its copyed down come from......
>
> How often do you see these, and do you have an example?  Perhaps you  
> have
> caught it during the time it's syncing between subversion and what  
> the rsync
> server offers.
>
>>
>> But! getting updates more often was indeed the point......
>
> I think portindex currently takes 7-8 minutes to run, and probably  
> puts a
> load on the server, so that would be one limiting issue on just how  
> often it
> is run.
>

The index makes no noticeable impact on server load.  I can run it as  
often as you want. I havnt timed it on the server lately, but assuming  
its < 30m, then I can just run it in sync with the rsync server  
updates which are already every 30m.

-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/20081110/c08daad5/attachment.bin>

From blb at macports.org  Mon Nov 10 01:17:33 2008
From: blb at macports.org (Bryan Blackburn)
Date: Mon, 10 Nov 2008 02:17:33 -0700
Subject: portindex updates
In-Reply-To: <52992BE5-395E-4C0B-AB09-833D3911A226@apple.com>
References: <AD6B85EB-334F-4153-B1D4-ED94AAD8BB28@macports.org>
	<9DFF66D3-99A4-4AE3-8050-D2F474610CAE@bellsouth.net>
	<911B0AB4-36C0-45D0-BFBC-1A80CE931097@macports.org>
	<191B8DAD-2EE5-46D0-96D6-407ECF626D67@bellsouth.net>
	<20081110042441.GK519@ninagal.withay.com>
	<909C09C8-7B87-49CC-8C52-F7DEAF8340B8@bellsouth.net>
	<4917C476.7020600@macports.org>
	<FDF1AB31-492D-4C57-9FFB-4EE99B1F0307@bellsouth.net>
	<20081110071122.GM519@ninagal.withay.com>
	<52992BE5-395E-4C0B-AB09-833D3911A226@apple.com>
Message-ID: <20081110091732.GN519@ninagal.withay.com>

On Mon, Nov 10, 2008 at 12:39:17AM -0800, William Siegrist said:
[...]
>
> The index makes no noticeable impact on server load.  I can run it as  
> often as you want. I havnt timed it on the server lately, but assuming  
> its < 30m, then I can just run it in sync with the rsync server updates 
> which are already every 30m.

portindex is run at 0045 right?  The checkin always seems to happen around
0052, hence my 7-8 minute guess.  Running it here on my local repo, watching
top, it does take up some CPU (>50% of a core), so I wasn't sure how
intensive it might be on the server, nor how big of an effect its intensity
would be on the server.

If it isn't that bad of a load, we could definitely bump it up to four to
six times a day instead of twice, as a help to upgrade, etc, commands which
use the index; until a better indexing solution is put in place.

Bryan


>
> -Bill
>

From wsiegrist at apple.com  Mon Nov 10 11:28:03 2008
From: wsiegrist at apple.com (William Siegrist)
Date: Mon, 10 Nov 2008 11:28:03 -0800
Subject: portindex updates
In-Reply-To: <20081110091732.GN519@ninagal.withay.com>
References: <AD6B85EB-334F-4153-B1D4-ED94AAD8BB28@macports.org>
	<9DFF66D3-99A4-4AE3-8050-D2F474610CAE@bellsouth.net>
	<911B0AB4-36C0-45D0-BFBC-1A80CE931097@macports.org>
	<191B8DAD-2EE5-46D0-96D6-407ECF626D67@bellsouth.net>
	<20081110042441.GK519@ninagal.withay.com>
	<909C09C8-7B87-49CC-8C52-F7DEAF8340B8@bellsouth.net>
	<4917C476.7020600@macports.org>
	<FDF1AB31-492D-4C57-9FFB-4EE99B1F0307@bellsouth.net>
	<20081110071122.GM519@ninagal.withay.com>
	<52992BE5-395E-4C0B-AB09-833D3911A226@apple.com>
	<20081110091732.GN519@ninagal.withay.com>
Message-ID: <0C489C00-618D-4114-BA92-878BA5ECFA85@apple.com>


On Nov 10, 2008, at 1:17 AM, Bryan Blackburn wrote:

> On Mon, Nov 10, 2008 at 12:39:17AM -0800, William Siegrist said:
> [...]
>>
>> The index makes no noticeable impact on server load.  I can run it as
>> often as you want. I havnt timed it on the server lately, but  
>> assuming
>> its < 30m, then I can just run it in sync with the rsync server  
>> updates
>> which are already every 30m.
>
> portindex is run at 0045 right?  The checkin always seems to happen  
> around
> 0052, hence my 7-8 minute guess.  Running it here on my local repo,  
> watching
> top, it does take up some CPU (>50% of a core), so I wasn't sure how
> intensive it might be on the server, nor how big of an effect its  
> intensity
> would be on the server.
>
> If it isn't that bad of a load, we could definitely bump it up to  
> four to
> six times a day instead of twice, as a help to upgrade, etc,  
> commands which
> use the index; until a better indexing solution is put in place.
>

PortIndex will now run at 45m after each hour.

-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/20081110/87f580f7/attachment.bin>

From florian.ebeling at gmail.com  Mon Nov 10 11:36:01 2008
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Mon, 10 Nov 2008 20:36:01 +0100
Subject: [MacPorts] #17099: Erlang : update to R12B-5
In-Reply-To: <064.5f2daeb4ccf639e7afda9382498d3bdf@macports.org>
References: <055.54b586e72cf2ca1180b903ac3a7c6653@macports.org>
	<064.5f2daeb4ccf639e7afda9382498d3bdf@macports.org>
Message-ID: <5cbbe4ae0811101136h43b32578ub1105eef56d89a11@mail.gmail.com>

Ok, I removed standalone Eunit port in r41792.

Florian

On Sun, Nov 9, 2008 at 1:55 AM, MacPorts <noreply at macports.org> wrote:
> #17099: Erlang : update to R12B-5
> ----------------------------------+-----------------------------------------
>  Reporter:  pguyot at kallisys.net  |       Owner:  bfulgham at macports.org
>      Type:  defect               |      Status:  closed
>  Priority:  Normal               |   Milestone:  Port Bugs
>  Component:  ports                |     Version:  1.7.0
> Resolution:  fixed                |    Keywords:
>      Port:  erlang               |
> ----------------------------------+-----------------------------------------
> Changes (by bfulgham at macports.org):
>
>  * status:  assigned => closed
>  * resolution:  => fixed
>
>
> Comment:
>
>  Applied in @r41672
>
> --
> Ticket URL: <http://trac.macports.org/ticket/17099#comment:4>
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS
>



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

From frstan at bellsouth.net  Mon Nov 10 14:07:45 2008
From: frstan at bellsouth.net (William Davis)
Date: Mon, 10 Nov 2008 17:07:45 -0500
Subject: portindex updates
In-Reply-To: <0C489C00-618D-4114-BA92-878BA5ECFA85@apple.com>
References: <AD6B85EB-334F-4153-B1D4-ED94AAD8BB28@macports.org>
	<9DFF66D3-99A4-4AE3-8050-D2F474610CAE@bellsouth.net>
	<911B0AB4-36C0-45D0-BFBC-1A80CE931097@macports.org>
	<191B8DAD-2EE5-46D0-96D6-407ECF626D67@bellsouth.net>
	<20081110042441.GK519@ninagal.withay.com>
	<909C09C8-7B87-49CC-8C52-F7DEAF8340B8@bellsouth.net>
	<4917C476.7020600@macports.org>
	<FDF1AB31-492D-4C57-9FFB-4EE99B1F0307@bellsouth.net>
	<20081110071122.GM519@ninagal.withay.com>
	<52992BE5-395E-4C0B-AB09-833D3911A226@apple.com>
	<20081110091732.GN519@ninagal.withay.com>
	<0C489C00-618D-4114-BA92-878BA5ECFA85@apple.com>
Message-ID: <E3E779E3-7FCF-41C7-A4CC-D17C16379592@bellsouth.net>


On Nov 10, 2008, at 2:28 PM, William Siegrist wrote:

>
> On Nov 10, 2008, at 1:17 AM, Bryan Blackburn wrote:
>
>> On Mon, Nov 10, 2008 at 12:39:17AM -0800, William Siegrist said:
>> [...]
>>>
>>> The index makes no noticeable impact on server load.  I can run it  
>>> as
>>> often as you want. I havnt timed it on the server lately, but  
>>> assuming
>>> its < 30m, then I can just run it in sync with the rsync server  
>>> updates
>>> which are already every 30m.
>>
>> portindex is run at 0045 right?  The checkin always seems to happen  
>> around
>> 0052, hence my 7-8 minute guess.  Running it here on my local repo,  
>> watching
>> top, it does take up some CPU (>50% of a core), so I wasn't sure how
>> intensive it might be on the server, nor how big of an effect its  
>> intensity
>> would be on the server.
>>
>> If it isn't that bad of a load, we could definitely bump it up to  
>> four to
>> six times a day instead of twice, as a help to upgrade, etc,  
>> commands which
>> use the index; until a better indexing solution is put in place.
>>
>
> PortIndex will now run at 45m after each hour.
>
> -Bill
>


Bill, that is wonderful! Thank you very much, indeed.


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

Mundus vult decepi, ego non


From ryandesign at macports.org  Tue Nov 11 03:21:48 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 11 Nov 2008 05:21:48 -0600
Subject: [41852] trunk/dports/games/ctetris
In-Reply-To: <20081111091402.AE6E16829EC@beta.macosforge.org>
References: <20081111091402.AE6E16829EC@beta.macosforge.org>
Message-ID: <1870254D-83E5-4B37-BB98-1CD2CE5E7404@macports.org>

On Nov 11, 2008, at 03:14, toby at macports.org wrote:

> Revision: 41852
>           http://trac.macports.org/changeset/41852
> Author:   toby at macports.org
> Date:     2008-11-11 01:14:02 -0800 (Tue, 11 Nov 2008)
> Log Message:
> -----------
> update to 0.42

How will users who had ctetris 0.30 installed learn that the port has  
changed names to ctris? They won't, unfortunately. Which is why you  
need to keep a stub ctetris port around which does nothing but inform  
the user to install ctris instead. See for example the libopensync  
port which was renamed to opensync:

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

Copy the last version of ctetris back into place using svn copy and  
the peg revision 41851. Increase the version number so users are  
informed it's outdated (increasing the version to the current version  
of ctris seems good). And make it not download or install anything  
except a readme.

> Modified Paths:
> --------------
>     trunk/dports/games/ctetris/Portfile
>     trunk/dports/games/ctetris/files/patch-Makefile.diff
>
> Removed Paths:
> -------------
>     trunk/dports/games/ctetris/files/patch-brick.h
>     trunk/dports/games/ctetris/files/patch-game.h
>     trunk/dports/games/ctetris/files/patch-screen.h
>
> Modified: trunk/dports/games/ctetris/Portfile
> ===================================================================
> --- trunk/dports/games/ctetris/Portfile	2008-11-11 08:44:37 UTC  
> (rev 41851)
> +++ trunk/dports/games/ctetris/Portfile	2008-11-11 09:14:02 UTC  
> (rev 41852)
> @@ -2,8 +2,8 @@
>
>  PortSystem 1.0
>
> -name	   ctetris
> -version	   0.30
> +name	   ctris
> +version	   0.42
>  categories	games
>  platforms	darwin
>  maintainers	jmpp openmaintainer
>

From n.oxyde at gmail.com  Tue Nov 11 07:14:31 2008
From: n.oxyde at gmail.com (nox)
Date: Tue, 11 Nov 2008 16:14:31 +0100
Subject: [41852] trunk/dports/games/ctetris
In-Reply-To: <1870254D-83E5-4B37-BB98-1CD2CE5E7404@macports.org>
References: <20081111091402.AE6E16829EC@beta.macosforge.org>
	<1870254D-83E5-4B37-BB98-1CD2CE5E7404@macports.org>
Message-ID: <FB2C966F-6B15-4DE5-8894-F25469796A68@gmail.com>

Le 11 nov. 08 ? 12:21, Ryan Schmidt a ?crit :

> On Nov 11, 2008, at 03:14, toby at macports.org wrote:
>
>> Revision: 41852
>>          http://trac.macports.org/changeset/41852
>> Author:   toby at macports.org
>> Date:     2008-11-11 01:14:02 -0800 (Tue, 11 Nov 2008)
>> Log Message:
>> -----------
>> update to 0.42
>
> How will users who had ctetris 0.30 installed learn that the port  
> has changed names to ctris? They won't, unfortunately. Which is why  
> you need to keep a stub ctetris port around which does nothing but  
> inform the user to install ctris instead. See for example the  
> libopensync port which was renamed to opensync:
>
> http://trac.macports.org/changeset/41839
>
> Copy the last version of ctetris back into place using svn copy and  
> the peg revision 41851. Increase the version number so users are  
> informed it's outdated (increasing the version to the current  
> version of ctris seems good). And make it not download or install  
> anything except a readme.
>
>> <snip/>

Can't we just create some sort of a weekly newsletter with some news  
about MacPorts and in particular renamed/nuked/superseded ports?


From ryandesign at macports.org  Tue Nov 11 13:28:14 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 11 Nov 2008 15:28:14 -0600
Subject: [41852] trunk/dports/games/ctetris
In-Reply-To: <FB2C966F-6B15-4DE5-8894-F25469796A68@gmail.com>
References: <20081111091402.AE6E16829EC@beta.macosforge.org>
	<1870254D-83E5-4B37-BB98-1CD2CE5E7404@macports.org>
	<FB2C966F-6B15-4DE5-8894-F25469796A68@gmail.com>
Message-ID: <3DE8B64E-99D1-4437-9FCF-B04221108F81@macports.org>

On Nov 11, 2008, at 09:14, nox wrote:

> Le 11 nov. 08 ? 12:21, Ryan Schmidt a ?crit :
>
>> On Nov 11, 2008, at 03:14, toby at macports.org wrote:
>>
>>> Revision: 41852
>>>          http://trac.macports.org/changeset/41852
>>> Author:   toby at macports.org
>>> Date:     2008-11-11 01:14:02 -0800 (Tue, 11 Nov 2008)
>>> Log Message:
>>> -----------
>>> update to 0.42
>>
>> How will users who had ctetris 0.30 installed learn that the port  
>> has changed names to ctris? They won't, unfortunately. Which is  
>> why you need to keep a stub ctetris port around which does nothing  
>> but inform the user to install ctris instead. See for example the  
>> libopensync port which was renamed to opensync:
>>
>> http://trac.macports.org/changeset/41839
>>
>> Copy the last version of ctetris back into place using svn copy  
>> and the peg revision 41851. Increase the version number so users  
>> are informed it's outdated (increasing the version to the current  
>> version of ctris seems good). And make it not download or install  
>> anything except a readme.
>>
>>> <snip/>
>
> Can't we just create some sort of a weekly newsletter with some  
> news about MacPorts and in particular renamed/nuked/superseded ports?

I'm sure only a small portion of MacPorts users are on the macports- 
users mailing list. So I don't think that would be helpful.


From frstan at bellsouth.net  Tue Nov 11 14:39:33 2008
From: frstan at bellsouth.net (William Davis)
Date: Tue, 11 Nov 2008 17:39:33 -0500
Subject: Fwd: [Xquartz-dev] 2.3.2_beta3
References: <7EEA4529-9EAB-47AB-8DC4-2D2302F5AD61@ensight.com>
Message-ID: <1C5790F1-6C67-4DC7-A958-158D14A5E911@bellsouth.net>

macintosh:~ frstan$ port info libpixman
libpixman 0.12.0, Revision 1, graphics/libpixman (Variants: universal)
http://www.x.org/

libpixman is a generic library for manipulating pixel regions. A  
PixRegion is a set of Y-X banded rectangles that cover the desired  
region.

Platforms: darwin
Maintainers: ryandesign at macports.org
macintosh:~ frstan$


Begin forwarded message:

> From: Mike Krogh <mfkrogh at ensight.com>
> Date: November 11, 2008 5:27:32 PM EST
> To: Developer talk about Xquartz <xquartz-dev at lists.macosforge.org>
> Subject: Re: [Xquartz-dev] 2.3.2_beta3
> Reply-To: Developer talk about Xquartz <xquartz-dev at lists.macosforge.org 
> >
>
>
> Turns out the CrashLog has a clue.  But I'm not sure how to resolve  
> it:
>
> Dyld Error Message:
>  Library not loaded: /usr/X11/lib/libpixman-1.0.dylib
>  Referenced from: /Applications/Utilities/X11.app/Contents/MacOS/X11
>  Reason: Incompatible library version: X11 requires version 13.0.0  
> or later, but libpixman-1.0.dylib provides version 12.0.0
>
> On Nov 11, 2008, at 5:21 PM, Mike Krogh wrote:
>
>> Hi,
>>
>> I just installed 2.3.2_beta3 on my Leopard 10.5.5 MacBook and am  
>> having several problems with our X11 based application now.
>>
>> First, I tried to install X11-2.3.1.pkg after trying 2.3.2-beta3  
>> but it crashes every time I try to start the X11 server.  I've  
>> rebooted, reinstall a couple of times but no luck.  X11 now just  
>> crashes immediately.  How does one downgrade X11?
>>
>> Second, at least with 2.3.2_beta3 our application's dialogs now  
>> frequently, but not always, pop to the upper left corner of the  
>> desktop (dual monitors) after twiddling some of the dialog's widgets.
>>
>> Third, the application opens multiple connections to the X server  
>> since it uses both Motif and QT4.  With 2.3.2_beta3, some dialogs  
>> created via PyQT are now causing the X11 server to crash; the main  
>> app is Motif based.
>>
>> Unfortunately, I have not been keeping up with all the 2.3.x  
>> updates so I don't know how far back this problem goes.  Prior to  
>> this I was running 2.2.2 without these problems.  I'll be happy to  
>> try the various 2.2.x and 2.3.x release to see when the problem was  
>> introduced if someone can tell me how to properly downgrade.
>>
>> Thanks!
>>
>> Mike
>>
>>
>
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev



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

Mundus vult decepi, ego non

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20081111/ed917e9d/attachment-0001.html>

From ryandesign at macports.org  Tue Nov 11 14:47:22 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 11 Nov 2008 16:47:22 -0600
Subject: [Xquartz-dev] 2.3.2_beta3
In-Reply-To: <1C5790F1-6C67-4DC7-A958-158D14A5E911@bellsouth.net>
References: <7EEA4529-9EAB-47AB-8DC4-2D2302F5AD61@ensight.com>
	<1C5790F1-6C67-4DC7-A958-158D14A5E911@bellsouth.net>
Message-ID: <9A2BB9A9-03D9-4451-9463-8C958535758A@macports.org>

On Nov 11, 2008, at 16:39, William Davis wrote:

> macintosh:~ frstan$ port info libpixman
> libpixman 0.12.0, Revision 1, graphics/libpixman (Variants: universal)
> http://www.x.org/
>
> libpixman is a generic library for manipulating pixel regions. A  
> PixRegion is a set of Y-X banded rectangles that cover the desired  
> region.
>
> Platforms: darwin
> Maintainers: ryandesign at macports.org
> macintosh:~ frstan$

What's your question? :)

If you're asking me about providing libpixman 0.13.x in MacPorts,  
I'll be happy to update the libpixman-devel port to that unstable  
version when it's made available. I don't see anything past 0.12.0 on  
their server at this time, though:

http://ftp.x.org/pub/individual/lib/


> Begin forwarded message:
>
>> From: Mike Krogh <mfkrogh at ensight.com>
>> Date: November 11, 2008 5:27:32 PM EST
>> To: Developer talk about Xquartz <xquartz-dev at lists.macosforge.org>
>> Subject: Re: [Xquartz-dev] 2.3.2_beta3
>> Reply-To: Developer talk about Xquartz <xquartz- 
>> dev at lists.macosforge.org>
>>
>>
>> Turns out the CrashLog has a clue.  But I'm not sure how to  
>> resolve it:
>>
>> Dyld Error Message:
>>  Library not loaded: /usr/X11/lib/libpixman-1.0.dylib
>>  Referenced from: /Applications/Utilities/X11.app/Contents/MacOS/X11
>>  Reason: Incompatible library version: X11 requires version 13.0.0  
>> or later, but libpixman-1.0.dylib provides version 12.0.0
>>
>> On Nov 11, 2008, at 5:21 PM, Mike Krogh wrote:
>>
>>> Hi,
>>>
>>> I just installed 2.3.2_beta3 on my Leopard 10.5.5 MacBook and am  
>>> having several problems with our X11 based application now.
>>>
>>> First, I tried to install X11-2.3.1.pkg after trying 2.3.2-beta3  
>>> but it crashes every time I try to start the X11 server.  I've  
>>> rebooted, reinstall a couple of times but no luck.  X11 now just  
>>> crashes immediately.  How does one downgrade X11?
>>>
>>> Second, at least with 2.3.2_beta3 our application's dialogs now  
>>> frequently, but not always, pop to the upper left corner of the  
>>> desktop (dual monitors) after twiddling some of the dialog's  
>>> widgets.
>>>
>>> Third, the application opens multiple connections to the X server  
>>> since it uses both Motif and QT4.  With 2.3.2_beta3, some dialogs  
>>> created via PyQT are now causing the X11 server to crash; the  
>>> main app is Motif based.
>>>
>>> Unfortunately, I have not been keeping up with all the 2.3.x  
>>> updates so I don't know how far back this problem goes.  Prior to  
>>> this I was running 2.2.2 without these problems.  I'll be happy  
>>> to try the various 2.2.x and 2.3.x release to see when the  
>>> problem was introduced if someone can tell me how to properly  
>>> downgrade.

From jeremyhu at macports.org  Tue Nov 11 14:53:14 2008
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Tue, 11 Nov 2008 14:53:14 -0800
Subject: [Xquartz-dev] 2.3.2_beta3
In-Reply-To: <1C5790F1-6C67-4DC7-A958-158D14A5E911@bellsouth.net>
References: <7EEA4529-9EAB-47AB-8DC4-2D2302F5AD61@ensight.com>
	<1C5790F1-6C67-4DC7-A958-158D14A5E911@bellsouth.net>
Message-ID: <53CA5298-8D07-4C7B-9EC9-570576CED355@macports.org>

This is a bug in glibtool not setting the correct compat version in  
dylibs...

<rdar://problem/6351733> glibtool sets incorrect current/compatibility  
version on dylibs

Here's an example from fontconfig (my comments from that above radar):

2008.11.07 11:23 Jeremy Huddleston:
10.5.4 contained fontconfig-2.4.1 (the 1.1 / 3.0.0 version)
10.5.5 contained fontconfig-2.5.0 (the 1.3 / 5.0.0 version)

The 1.1.0 version was kept around because it wasn't nuked by the SU.   
A vanilla install of SULeoGaia should not contain the 1.1.0 version.

As far as compatability goes, on the fontconfig website:
"These also apply to 2.5 and 2.6 which are ABI and API compatible with  
2.4."

The file is created with libtool using the following in Makefile.am:
libfontconfig_la_LDFLAGS = -version-info @LIBT_VERSION_INFO@

configure.in:
LIBT_VERSION_INFO="$LIBT_CURRENT:$LIBT_REVISION:$LIBT_AGE"

2.5.0 had:
LIBT_CURRENT=4
LIBT_REVISION=0
LIBT_AGE=3

2.4.1 had:
LT_CURRENT=2
LT_REVISION=0
LT_AGE=1

Note:
bump revision when fixing bugs
bump current and age, reset revision to zero when adding APIs
bump current, leave age, reset revision to zero when changing/removing  
APIS

So API was added "twice" without changing/removing API.

This looks like a libtool bug.  Libtool is using the LIBT_CURRENT as  
the dylib compat version ... is should be:

compat version = CURRENT - AGE . 0 . 0
current version = CURRENT - AGE . AGE . REVISION

<snip/>

2008.11.08 14:24 Jeremy Huddleston:
After thinking about this a bit, I realized the situation is not as  
dire as I had once thought.

The library name is libfontconfig.1.dylib ... If there was an ABI  
breakage bump, the *name* would be libfontconfig.2.dylib ... so we can  
actually get away with using compat version = 1.0.0 for all cases...  
then just do:

current = CURRENT + 1 . REVISION . 0 (same as what is done now ... my  
comment above is wrong)
compat = 1.0.0 (instead of CURRENT + 1 . 0 . 0 which it is now...)

The library name itself takes care of ensuring the ABI compatability





On Nov 11, 2008, at 14:39, William Davis wrote:

> macintosh:~ frstan$ port info libpixman
> libpixman 0.12.0, Revision 1, graphics/libpixman (Variants: universal)
> http://www.x.org/
>
> libpixman is a generic library for manipulating pixel regions. A  
> PixRegion is a set of Y-X banded rectangles that cover the desired  
> region.
>
> Platforms: darwin
> Maintainers: ryandesign at macports.org
> macintosh:~ frstan$
>
>
> Begin forwarded message:
>
>> From: Mike Krogh <mfkrogh at ensight.com>
>> Date: November 11, 2008 5:27:32 PM EST
>> To: Developer talk about Xquartz <xquartz-dev at lists.macosforge.org>
>> Subject: Re: [Xquartz-dev] 2.3.2_beta3
>> Reply-To: Developer talk about Xquartz <xquartz-dev at lists.macosforge.org 
>> >
>>
>>
>> Turns out the CrashLog has a clue.  But I'm not sure how to resolve  
>> it:
>>
>> Dyld Error Message:
>> Library not loaded: /usr/X11/lib/libpixman-1.0.dylib
>> Referenced from: /Applications/Utilities/X11.app/Contents/MacOS/X11
>> Reason: Incompatible library version: X11 requires version 13.0.0  
>> or later, but libpixman-1.0.dylib provides version 12.0.0
>>
>> On Nov 11, 2008, at 5:21 PM, Mike Krogh wrote:
>>
>>> Hi,
>>>
>>> I just installed 2.3.2_beta3 on my Leopard 10.5.5 MacBook and am  
>>> having several problems with our X11 based application now.
>>>
>>> First, I tried to install X11-2.3.1.pkg after trying 2.3.2-beta3  
>>> but it crashes every time I try to start the X11 server.  I've  
>>> rebooted, reinstall a couple of times but no luck.  X11 now just  
>>> crashes immediately.  How does one downgrade X11?
>>>
>>> Second, at least with 2.3.2_beta3 our application's dialogs now  
>>> frequently, but not always, pop to the upper left corner of the  
>>> desktop (dual monitors) after twiddling some of the dialog's  
>>> widgets.
>>>
>>> Third, the application opens multiple connections to the X server  
>>> since it uses both Motif and QT4.  With 2.3.2_beta3, some dialogs  
>>> created via PyQT are now causing the X11 server to crash; the main  
>>> app is Motif based.
>>>
>>> Unfortunately, I have not been keeping up with all the 2.3.x  
>>> updates so I don't know how far back this problem goes.  Prior to  
>>> this I was running 2.2.2 without these problems.  I'll be happy to  
>>> try the various 2.2.x and 2.3.x release to see when the problem  
>>> was introduced if someone can tell me how to properly downgrade.
>>>
>>> Thanks!
>>>
>>> Mike
>>>
>>>
>>
>> _______________________________________________
>> Xquartz-dev mailing list
>> Xquartz-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>
>
>
> William Davis
> frstanATbellsouthDOTnet
> Mac OS X.5.5 Darwin 9.5.0
> XQuartz 2.3.2 (xorg-server 1.4.2-apple21)
> Mac Mini Intel Duo @ 1.86 GHz
>
> Mundus vult decepi, ego non
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


From n.oxyde at gmail.com  Tue Nov 11 15:03:36 2008
From: n.oxyde at gmail.com (nox)
Date: Wed, 12 Nov 2008 00:03:36 +0100
Subject: [41852] trunk/dports/games/ctetris
In-Reply-To: <3DE8B64E-99D1-4437-9FCF-B04221108F81@macports.org>
References: <20081111091402.AE6E16829EC@beta.macosforge.org>
	<1870254D-83E5-4B37-BB98-1CD2CE5E7404@macports.org>
	<FB2C966F-6B15-4DE5-8894-F25469796A68@gmail.com>
	<3DE8B64E-99D1-4437-9FCF-B04221108F81@macports.org>
Message-ID: <33C7FD50-12E7-43B8-B890-893146901529@gmail.com>


Le 11 nov. 08 ? 22:28, Ryan Schmidt a ?crit :

> On Nov 11, 2008, at 09:14, nox wrote:
>
>> Le 11 nov. 08 ? 12:21, Ryan Schmidt a ?crit :
>>
>>> On Nov 11, 2008, at 03:14, toby at macports.org wrote:
>>>
>>>> Revision: 41852
>>>>         http://trac.macports.org/changeset/41852
>>>> Author:   toby at macports.org
>>>> Date:     2008-11-11 01:14:02 -0800 (Tue, 11 Nov 2008)
>>>> Log Message:
>>>> -----------
>>>> update to 0.42
>>>
>>> How will users who had ctetris 0.30 installed learn that the port  
>>> has changed names to ctris? They won't, unfortunately. Which is  
>>> why you need to keep a stub ctetris port around which does nothing  
>>> but inform the user to install ctris instead. See for example the  
>>> libopensync port which was renamed to opensync:
>>>
>>> http://trac.macports.org/changeset/41839
>>>
>>> Copy the last version of ctetris back into place using svn copy  
>>> and the peg revision 41851. Increase the version number so users  
>>> are informed it's outdated (increasing the version to the current  
>>> version of ctris seems good). And make it not download or install  
>>> anything except a readme.
>>>
>>>> <snip/>
>>
>> Can't we just create some sort of a weekly newsletter with some  
>> news about MacPorts and in particular renamed/nuked/superseded ports?
>
> I'm sure only a small portion of MacPorts users are on the macports- 
> users mailing list. So I don't think that would be helpful.
>

I'm not talking about a new mailing list or whatever but some kind of  
a webpage, the URL of it could be added to the output of the  
selfupdate action.


From blb at macports.org  Tue Nov 11 15:03:46 2008
From: blb at macports.org (Bryan Blackburn)
Date: Tue, 11 Nov 2008 16:03:46 -0700
Subject: [41852] trunk/dports/games/ctetris
In-Reply-To: <3DE8B64E-99D1-4437-9FCF-B04221108F81@macports.org>
References: <20081111091402.AE6E16829EC@beta.macosforge.org>
	<1870254D-83E5-4B37-BB98-1CD2CE5E7404@macports.org>
	<FB2C966F-6B15-4DE5-8894-F25469796A68@gmail.com>
	<3DE8B64E-99D1-4437-9FCF-B04221108F81@macports.org>
Message-ID: <20081111230346.GH596@ninagal.withay.com>

On Tue, Nov 11, 2008 at 03:28:14PM -0600, Ryan Schmidt said:
> On Nov 11, 2008, at 09:14, nox wrote:
[...]
>>
>> Can't we just create some sort of a weekly newsletter with some news 
>> about MacPorts and in particular renamed/nuked/superseded ports?
>
> I'm sure only a small portion of MacPorts users are on the macports-users 
> mailing list. So I don't think that would be helpful.

Note that there are over 1000 people on -users, only a bit over 100 on
-announce; no way to tell how many people follow the news page [1], so
-users would be the best place for such a thing if the widest readership was
desired.

Then, of course, someone willing to actually write the newsletter would need
to step up and do so.

Bryan

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


From ryandesign at macports.org  Tue Nov 11 15:46:07 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 11 Nov 2008 17:46:07 -0600
Subject: [41852] trunk/dports/games/ctetris
In-Reply-To: <33C7FD50-12E7-43B8-B890-893146901529@gmail.com>
References: <20081111091402.AE6E16829EC@beta.macosforge.org>
	<1870254D-83E5-4B37-BB98-1CD2CE5E7404@macports.org>
	<FB2C966F-6B15-4DE5-8894-F25469796A68@gmail.com>
	<3DE8B64E-99D1-4437-9FCF-B04221108F81@macports.org>
	<33C7FD50-12E7-43B8-B890-893146901529@gmail.com>
Message-ID: <838C1713-DAB3-4289-BF24-90A61DBF30D0@macports.org>

On Nov 11, 2008, at 17:03, nox wrote:

> Le 11 nov. 08 ? 22:28, Ryan Schmidt a ?crit :
>
>> On Nov 11, 2008, at 09:14, nox wrote:
>>
>>> Le 11 nov. 08 ? 12:21, Ryan Schmidt a ?crit :
>>>
>>>> On Nov 11, 2008, at 03:14, toby at macports.org wrote:
>>>>
>>>>> Revision: 41852
>>>>>         http://trac.macports.org/changeset/41852
>>>>> Author:   toby at macports.org
>>>>> Date:     2008-11-11 01:14:02 -0800 (Tue, 11 Nov 2008)
>>>>> Log Message:
>>>>> -----------
>>>>> update to 0.42
>>>>
>>>> How will users who had ctetris 0.30 installed learn that the  
>>>> port has changed names to ctris? They won't, unfortunately.  
>>>> Which is why you need to keep a stub ctetris port around which  
>>>> does nothing but inform the user to install ctris instead. See  
>>>> for example the libopensync port which was renamed to opensync:
>>>>
>>>> http://trac.macports.org/changeset/41839
>>>>
>>>> Copy the last version of ctetris back into place using svn copy  
>>>> and the peg revision 41851. Increase the version number so users  
>>>> are informed it's outdated (increasing the version to the  
>>>> current version of ctris seems good). And make it not download  
>>>> or install anything except a readme.
>>>>
>>>>> <snip/>
>>>
>>> Can't we just create some sort of a weekly newsletter with some  
>>> news about MacPorts and in particular renamed/nuked/superseded  
>>> ports?
>>
>> I'm sure only a small portion of MacPorts users are on the  
>> macports-users mailing list. So I don't think that would be helpful.
>
> I'm not talking about a new mailing list or whatever but some kind  
> of a webpage, the URL of it could be added to the output of the  
> selfupdate action.

My friend Kevin has MacPorts installed to get Apache, MySQL and PHP,  
but he doesn't update until I ask him to test something new on his  
machine. If he selfupdates now, it will pull in 6 months worth of new  
ports. How will it show all the ports Kevin has installed which have  
been renamed in the past 6 months?

What if Kevin last selfupdated 6 months ago, but the last time he  
actually tried to upgrade any ports was 12 months ago? How will he  
know which of the ports he has installed have been renamed?

No, I don't want a new web page. I want the existing "port outdated"  
mechanism to handle this. Since MacPorts base has no feature to  
handle port renames, we must currently jump through some hoops in  
ports, keeping a stub port around under the old name to inform users  
to switch to the new name. Improvements to base to help this  
situation are of course welcome!



From ryandesign at macports.org  Tue Nov 11 16:46:00 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 11 Nov 2008 18:46:00 -0600
Subject: Typo in dp2mp-move code in dmg preflight
Message-ID: <55FCC2FA-5D6B-4DEC-B665-B2B3A1CCDE93@macports.org>

Do we have a typo here?

http://trac.macports.org/browser/trunk/base/portmgr/dmg/preflight? 
rev=32397#L47

[ ! -d /opt/local/share/darwinports ] || rm -rf /opt/local/darwinports

Shouldn't that be

[ ! -d /opt/local/share/darwinports ] || rm -rf /opt/local/share/ 
darwinports

It looks like this typo was introduced here:

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


From ryandesign at macports.org  Tue Nov 11 19:39:53 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 11 Nov 2008 21:39:53 -0600
Subject: [41898] trunk/dports/gis
In-Reply-To: <20081112030237.933E368B40A@beta.macosforge.org>
References: <20081112030237.933E368B40A@beta.macosforge.org>
Message-ID: <766DE177-1734-4866-93DC-A0E0DB99AECF@macports.org>

On Nov 11, 2008, at 21:02, macsforever2000 at macports.org wrote:

> +set cgi_path "/Library/WebServer/CGI-Executables/"
> +
> +# apache macport interop
> +if {[ file exists ${prefix}/sbin/httpd]} {
> +    set cgi_path "${prefix}/www/cgi-bin/"
> +}

It's not good for a port to behave differently depending on what else  
the user has installed. A port should behave identically on  
everyone's system (modulo such details as OS version and processor  
architecture).

Instead, I recommend some variants to let the user select whether  
they want to use MacPorts Apache 1, MacPorts Apache 2, or whatever  
Apache Apple includes with Mac OS X.


variant apache conflicts apache2 apache_apple description {Use  
MacPorts Apache 1} {
	depends_run-append port:apache
	set cgi_path "${prefix}/www/cgi-bin/"
}

variant apache2 conflicts apache apache_apple description {Use  
MacPorts Apache 2} {
	depends_run-append port:apache2
	set cgi_path "${prefix}/apache2/cgi-bin/"
}

variant apache_apple conflicts apache apache2 description {Use Apple  
Apache} {
	set cgi_path "/Library/WebServer/CGI-Executables/"
}

if {![variant_isset apache] && ![variant_isset apache2] && ! 
[variant_isset apache_apple]} {
	default_variants +apache2
}


Actually there are also web servers other than Apache -- lighttpd for  
example...


From macsforever2000 at macports.org  Tue Nov 11 19:53:22 2008
From: macsforever2000 at macports.org (Frank Schima)
Date: Tue, 11 Nov 2008 20:53:22 -0700
Subject: [41898] trunk/dports/gis
In-Reply-To: <766DE177-1734-4866-93DC-A0E0DB99AECF@macports.org>
References: <20081112030237.933E368B40A@beta.macosforge.org>
	<766DE177-1734-4866-93DC-A0E0DB99AECF@macports.org>
Message-ID: <D0540444-C684-41C2-903A-B098AA2A7DC9@macports.org>

Hi Ryan,


On Nov 11, 2008, at 8:39 PM, Ryan Schmidt wrote:

> On Nov 11, 2008, at 21:02, macsforever2000 at macports.org wrote:
>
>> +set cgi_path "/Library/WebServer/CGI-Executables/"
>> +
>> +# apache macport interop
>> +if {[ file exists ${prefix}/sbin/httpd]} {
>> +    set cgi_path "${prefix}/www/cgi-bin/"
>> +}
>
> It's not good for a port to behave differently depending on what  
> else the user has installed. A port should behave identically on  
> everyone's system (modulo such details as OS version and processor  
> architecture).
>
> Instead, I recommend some variants to let the user select whether  
> they want to use MacPorts Apache 1, MacPorts Apache 2, or whatever  
> Apache Apple includes with Mac OS X.
>
>
> variant apache conflicts apache2 apache_apple description {Use  
> MacPorts Apache 1} {
> 	depends_run-append port:apache
> 	set cgi_path "${prefix}/www/cgi-bin/"
> }
>
> variant apache2 conflicts apache apache_apple description {Use  
> MacPorts Apache 2} {
> 	depends_run-append port:apache2
> 	set cgi_path "${prefix}/apache2/cgi-bin/"
> }
>
> variant apache_apple conflicts apache apache2 description {Use Apple  
> Apache} {
> 	set cgi_path "/Library/WebServer/CGI-Executables/"
> }
>
> if {![variant_isset apache] && ![variant_isset apache2] && ! 
> [variant_isset apache_apple]} {
> 	default_variants +apache2
> }
>
>
> Actually there are also web servers other than Apache -- lighttpd  
> for example...

Excellent idea! I will be happy to implement this, however since  
mbarchfe agreed to be maintainer for the mapserver port, he should  
first approve this change.

mbarchfe, just let me know. Otherwise in 3 days I will implement this  
according to the maintainer timeout rules.


Cheers!
Frank


From blb at macports.org  Tue Nov 11 19:56:59 2008
From: blb at macports.org (Bryan Blackburn)
Date: Tue, 11 Nov 2008 20:56:59 -0700
Subject: Typo in dp2mp-move code in dmg preflight
In-Reply-To: <55FCC2FA-5D6B-4DEC-B665-B2B3A1CCDE93@macports.org>
References: <55FCC2FA-5D6B-4DEC-B665-B2B3A1CCDE93@macports.org>
Message-ID: <20081112035659.GR596@ninagal.withay.com>

On Tue, Nov 11, 2008 at 06:46:00PM -0600, Ryan Schmidt said:
> Do we have a typo here?
>
> http://trac.macports.org/browser/trunk/base/portmgr/dmg/preflight? 
> rev=32397#L47
>
> [ ! -d /opt/local/share/darwinports ] || rm -rf /opt/local/darwinports
>
> Shouldn't that be
>
> [ ! -d /opt/local/share/darwinports ] || rm -rf /opt/local/share/ 
> darwinports

Looks like it to me, though at this stage I hope nobody's still running DP.
If I recall, some paths may have been changed around a bit, but I can't
remember if it was stuff under share or var...

Bryan


>
> It looks like this typo was introduced here:
>
> http://trac.macports.org/changeset/26518
>

From ryandesign at macports.org  Tue Nov 11 20:44:50 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 11 Nov 2008 22:44:50 -0600
Subject: Typo in dp2mp-move code in dmg preflight
In-Reply-To: <20081112035659.GR596@ninagal.withay.com>
References: <55FCC2FA-5D6B-4DEC-B665-B2B3A1CCDE93@macports.org>
	<20081112035659.GR596@ninagal.withay.com>
Message-ID: <5D7D89A0-2B51-451B-A2D6-37CB086EE0C1@macports.org>


On Nov 11, 2008, at 21:56, Bryan Blackburn wrote:

> On Tue, Nov 11, 2008 at 06:46:00PM -0600, Ryan Schmidt said:
>> Do we have a typo here?
>>
>> http://trac.macports.org/browser/trunk/base/portmgr/dmg/preflight?
>> rev=32397#L47
>>
>> [ ! -d /opt/local/share/darwinports ] || rm -rf /opt/local/ 
>> darwinports
>>
>> Shouldn't that be
>>
>> [ ! -d /opt/local/share/darwinports ] || rm -rf /opt/local/share/
>> darwinports
>
> Looks like it to me, though at this stage I hope nobody's still  
> running DP.

Fixed in r41907. Though few should still have dp installed,  
presumably anyone who has been upgrading since dp will still have  
that directory around, which this fix will cause to now be properly  
removed.

> If I recall, some paths may have been changed around a bit, but I  
> can't
> remember if it was stuff under share or var...

You mean, other things have changed a bit, after the dp2mp rename?


From blb at macports.org  Wed Nov 12 00:20:17 2008
From: blb at macports.org (Bryan Blackburn)
Date: Wed, 12 Nov 2008 01:20:17 -0700
Subject: Typo in dp2mp-move code in dmg preflight
In-Reply-To: <5D7D89A0-2B51-451B-A2D6-37CB086EE0C1@macports.org>
References: <55FCC2FA-5D6B-4DEC-B665-B2B3A1CCDE93@macports.org>
	<20081112035659.GR596@ninagal.withay.com>
	<5D7D89A0-2B51-451B-A2D6-37CB086EE0C1@macports.org>
Message-ID: <20081112082017.GV596@ninagal.withay.com>

On Tue, Nov 11, 2008 at 10:44:50PM -0600, Ryan Schmidt said:
>
> On Nov 11, 2008, at 21:56, Bryan Blackburn wrote:
>
>> On Tue, Nov 11, 2008 at 06:46:00PM -0600, Ryan Schmidt said:
>>> Do we have a typo here?
>>>
>>> http://trac.macports.org/browser/trunk/base/portmgr/dmg/preflight?
>>> rev=32397#L47
>>>
>>> [ ! -d /opt/local/share/darwinports ] || rm -rf /opt/local/ 
>>> darwinports
>>>
>>> Shouldn't that be
>>>
>>> [ ! -d /opt/local/share/darwinports ] || rm -rf /opt/local/share/
>>> darwinports
>>
>> Looks like it to me, though at this stage I hope nobody's still running 
>> DP.
>
> Fixed in r41907. Though few should still have dp installed, presumably 
> anyone who has been upgrading since dp will still have that directory 
> around, which this fix will cause to now be properly removed.
>
>> If I recall, some paths may have been changed around a bit, but I can't
>> remember if it was stuff under share or var...
>
> You mean, other things have changed a bit, after the dp2mp rename?

Before the rename, but it wasn't share, it was the stuff under var, namely,
DP put stuff in ${prefix}/var/db/dports, so that wouldn't have been the
mistake above, so you can ignore me...

Bryan


From jmpp at macports.org  Wed Nov 12 09:37:50 2008
From: jmpp at macports.org (Juan Manuel Palacios)
Date: Wed, 12 Nov 2008 13:07:50 -0430
Subject: Typo in dp2mp-move code in dmg preflight
In-Reply-To: <20081112082017.GV596@ninagal.withay.com>
References: <55FCC2FA-5D6B-4DEC-B665-B2B3A1CCDE93@macports.org>
	<20081112035659.GR596@ninagal.withay.com>
	<5D7D89A0-2B51-451B-A2D6-37CB086EE0C1@macports.org>
	<20081112082017.GV596@ninagal.withay.com>
Message-ID: <1A572676-899D-4DF7-951E-93488FCE911E@macports.org>


On Nov 12, 2008, at 3:50 AM, Bryan Blackburn wrote:

> On Tue, Nov 11, 2008 at 10:44:50PM -0600, Ryan Schmidt said:
>>
>> On Nov 11, 2008, at 21:56, Bryan Blackburn wrote:
>>
>>> On Tue, Nov 11, 2008 at 06:46:00PM -0600, Ryan Schmidt said:
>>>> Do we have a typo here?
>>>>
>>>> http://trac.macports.org/browser/trunk/base/portmgr/dmg/preflight?
>>>> rev=32397#L47
>>>>
>>>> [ ! -d /opt/local/share/darwinports ] || rm -rf /opt/local/
>>>> darwinports
>>>>
>>>> Shouldn't that be
>>>>
>>>> [ ! -d /opt/local/share/darwinports ] || rm -rf /opt/local/share/
>>>> darwinports


	Yes, absolutely, that was a gross oversight on my part that I frankly  
don't know how it wasn't caught before. Thanks for that catch, Ryan!


>>>>
>>>
>>> Looks like it to me, though at this stage I hope nobody's still  
>>> running
>>> DP.
>>
>> Fixed in r41907. Though few should still have dp installed,  
>> presumably
>> anyone who has been upgrading since dp will still have that directory
>> around, which this fix will cause to now be properly removed.
>>
>>> If I recall, some paths may have been changed around a bit, but I  
>>> can't
>>> remember if it was stuff under share or var...
>>
>> You mean, other things have changed a bit, after the dp2mp rename?
>
> Before the rename, but it wasn't share, it was the stuff under var,  
> namely,
> DP put stuff in ${prefix}/var/db/dports, so that wouldn't have been  
> the
> mistake above, so you can ignore me...
>


	From what I recall, not much of the dp layout under var/dp/ changed  
after archivemode was introduced, which only added the packages/  
subdir and its hierarchy. But other than that, the var/dp/dports tree  
was pretty much static for the remainder of dp. But in any case, the  
rule Ryan corrected was indeed meant to delete the old $prefix/share/ 
darwinports directory, which would be replaced by the new $prefix/ 
share/macports one.

	And all in all, that code is indeed getting a bit old, I'd say you  
guys should start considering removing it from base. If at any point  
someone still running dp runs into trouble, they can always upgrade to  
1.6 first (which will move them to the new namespace) and then onto  
anything that's current at the time.

	Regards,...


-jmpp


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20081112/3f793674/attachment.html>

From frstan at bellsouth.net  Wed Nov 12 20:09:11 2008
From: frstan at bellsouth.net (William Davis)
Date: Wed, 12 Nov 2008 23:09:11 -0500
Subject: using port -R
Message-ID: <351D7107-3715-450C-9E47-656FAC9C13F2@bellsouth.net>

using sudo port -unR upgrade foo {libsoup in the present case}:
.....
-->  Fetching gnome-applets
DEBUG: Executing org.macports.fetch (gnome-applets)
--->  gnome-applets-2.24.0.tar.bz2 doesn't seem to exist in /opt/local/ 
var/macports/distfiles/gnome-applets/gnome-applets/gnome-applets/gnome- 
applets/gnome-applets/gnome-applets/gnome-applets/gnome-applets/gnome- 
applets/gnome-applets/gnome-applets/gnome-applets/gnome-applets
--->  Attempting to fetch gnome-applets-2.24.0.tar.bz2 from http://mandril.creatis.insa-lyon.fr/linux/gnome.org/sources/gnome-applets/2.24/
   % Total    % Received % Xferd  Average Speed   Time    Time      
Time  Current
                                  Dload  Upload   Total   Spent     
Left  Speed
  44 7291k   44 3215k    0     0  93842      0  0:01:19  0:00:35   
0:00:44 96460

I hope this is fixed in 1.7............


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

Mundus vult decepi, ego non


From frstan at bellsouth.net  Wed Nov 12 20:25:59 2008
From: frstan at bellsouth.net (William Davis)
Date: Wed, 12 Nov 2008 23:25:59 -0500
Subject: gnunextstep-gui
Message-ID: <4A34E9B3-3E84-42DF-AF52-5A1C7C2D4AE6@bellsouth.net>


j/GSNibLoader.o obj/NSPasteboard.o   -L/opt/local/lib      -L/opt/ 
local/GNUstep/Local/Library/Libraries/ -L/opt/local/GNUstep/System/ 
Library/Libraries/   -lgnustep-base -laudiofile -laspell -lungif -lpng  
-ltiff -lz -ljpeg -lm     && (cd ./obj; rm -f libgnustep-gui.dylib; if  
[ "libgnustep-gui.dylib.0.12" != "libgnustep-gui.dylib.0.12.0" ]; then  
rm -f libgnustep-gui.dylib.0.12; ln -s libgnustep-gui.dylib.0.12.0  
libgnustep-gui.dylib.0.12; fi; ln -s libgnustep-gui.dylib.0.12.0  
libgnustep-gui.dylib)
ld warning: duplicate dylib /opt/local/lib/gcc42/libgcc_s.1.dylib
ld: file not found: /opt/local/lib/libffi-2.1.dylib
/usr/bin/libtool: internal link edit command failed
gnumake[2]: *** [obj/libgnustep-gui.dylib.0.12.0] Error 1
gnumake[1]: *** [libgnustep-gui.all.library.variables] Error 2
gnumake: *** [internal-all] Error 2

Warning: the following items did not execute (for gnustep-gui):  
org.macports.destroot org.macports.build
DEBUG:
Error: Unable to upgrade port: 1


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

Mundus vult decepi, ego non


From jmr at macports.org  Wed Nov 12 20:49:29 2008
From: jmr at macports.org (Joshua Root)
Date: Thu, 13 Nov 2008 15:49:29 +1100
Subject: using port -R
In-Reply-To: <351D7107-3715-450C-9E47-656FAC9C13F2@bellsouth.net>
References: <351D7107-3715-450C-9E47-656FAC9C13F2@bellsouth.net>
Message-ID: <491BB1D9.20304@macports.org>

William Davis wrote:
> using sudo port -unR upgrade foo {libsoup in the present case}:
> .....
> -->  Fetching gnome-applets
> DEBUG: Executing org.macports.fetch (gnome-applets)
> --->  gnome-applets-2.24.0.tar.bz2 doesn't seem to exist in
> /opt/local/var/macports/distfiles/gnome-applets/gnome-applets/gnome-applets/gnome-applets/gnome-applets/gnome-applets/gnome-applets/gnome-applets/gnome-applets/gnome-applets/gnome-applets/gnome-applets/gnome-applets
> 
> --->  Attempting to fetch gnome-applets-2.24.0.tar.bz2 from
> http://mandril.creatis.insa-lyon.fr/linux/gnome.org/sources/gnome-applets/2.24/
> 
>   % Total    % Received % Xferd  Average Speed   Time    Time     Time 
> Current
>                                  Dload  Upload   Total   Spent    Left 
> Speed
>  44 7291k   44 3215k    0     0  93842      0  0:01:19  0:00:35  0:00:44
> 96460
> 
> I hope this is fixed in 1.7............

It is. That's <http://trac.macports.org/ticket/11971>.

- Josh

From jmr at macports.org  Wed Nov 12 20:56:38 2008
From: jmr at macports.org (Joshua Root)
Date: Thu, 13 Nov 2008 15:56:38 +1100
Subject: gnunextstep-gui
In-Reply-To: <4A34E9B3-3E84-42DF-AF52-5A1C7C2D4AE6@bellsouth.net>
References: <4A34E9B3-3E84-42DF-AF52-5A1C7C2D4AE6@bellsouth.net>
Message-ID: <491BB386.9040107@macports.org>

William Davis wrote:
> 
> j/GSNibLoader.o obj/NSPasteboard.o   -L/opt/local/lib     
> -L/opt/local/GNUstep/Local/Library/Libraries/
> -L/opt/local/GNUstep/System/Library/Libraries/   -lgnustep-base
> -laudiofile -laspell -lungif -lpng -ltiff -lz -ljpeg -lm     && (cd
> ./obj; rm -f libgnustep-gui.dylib; if [ "libgnustep-gui.dylib.0.12" !=
> "libgnustep-gui.dylib.0.12.0" ]; then rm -f libgnustep-gui.dylib.0.12;
> ln -s libgnustep-gui.dylib.0.12.0 libgnustep-gui.dylib.0.12; fi; ln -s
> libgnustep-gui.dylib.0.12.0 libgnustep-gui.dylib)
> ld warning: duplicate dylib /opt/local/lib/gcc42/libgcc_s.1.dylib
> ld: file not found: /opt/local/lib/libffi-2.1.dylib
> /usr/bin/libtool: internal link edit command failed
> gnumake[2]: *** [obj/libgnustep-gui.dylib.0.12.0] Error 1
> gnumake[1]: *** [libgnustep-gui.all.library.variables] Error 2
> gnumake: *** [internal-all] Error 2
> 
> Warning: the following items did not execute (for gnustep-gui):
> org.macports.destroot org.macports.build
> DEBUG:
> Error: Unable to upgrade port: 1

Looks like gnustep-base might be built against an older version of
libffi. Try rebuilding it: sudo port -fn upgrade gnustep-base

- Josh

From ryandesign at macports.org  Wed Nov 12 21:31:09 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 12 Nov 2008 23:31:09 -0600
Subject: using port -R
In-Reply-To: <491BB1D9.20304@macports.org>
References: <351D7107-3715-450C-9E47-656FAC9C13F2@bellsouth.net>
	<491BB1D9.20304@macports.org>
Message-ID: <771A652B-9EC4-443F-8BA2-580B2B2A9C94@macports.org>

On Nov 12, 2008, at 22:49, Joshua Root wrote:

> William Davis wrote:
>> using sudo port -unR upgrade foo {libsoup in the present case}:
>> .....
>> -->  Fetching gnome-applets
>> DEBUG: Executing org.macports.fetch (gnome-applets)
>> --->  gnome-applets-2.24.0.tar.bz2 doesn't seem to exist in
>> /opt/local/var/macports/distfiles/gnome-applets/gnome-applets/ 
>> gnome-applets/gnome-applets/gnome-applets/gnome-applets/gnome- 
>> applets/gnome-applets/gnome-applets/gnome-applets/gnome-applets/ 
>> gnome-applets/gnome-applets
>>
>> --->  Attempting to fetch gnome-applets-2.24.0.tar.bz2 from
>> http://mandril.creatis.insa-lyon.fr/linux/gnome.org/sources/gnome- 
>> applets/2.24/
>>
>>   % Total    % Received % Xferd  Average Speed   Time    Time      
>> Time
>> Current
>>                                  Dload  Upload   Total   Spent     
>> Left
>> Speed
>>  44 7291k   44 3215k    0     0  93842      0  0:01:19  0:00:35   
>> 0:00:44
>> 96460
>>
>> I hope this is fixed in 1.7............
>
> It is. That's <http://trac.macports.org/ticket/11971>.

Amazing! Thanks, Joshua.


From frstan at bellsouth.net  Thu Nov 13 06:02:31 2008
From: frstan at bellsouth.net (William Davis)
Date: Thu, 13 Nov 2008 09:02:31 -0500
Subject: using port -R
In-Reply-To: <491BB1D9.20304@macports.org>
References: <351D7107-3715-450C-9E47-656FAC9C13F2@bellsouth.net>
	<491BB1D9.20304@macports.org>
Message-ID: <C8104FA2-2CD0-4877-B5D4-BFEEDB195A8C@bellsouth.net>


On Nov 12, 2008, at 11:49 PM, Joshua Root wrote:

> William Davis wrote:
>> using sudo port -unR upgrade foo {libsoup in the present case}:
>> .....
>> -->  Fetching gnome-applets
>> DEBUG: Executing org.macports.fetch (gnome-applets)
>> --->  gnome-applets-2.24.0.tar.bz2 doesn't seem to exist in
>> /opt/local/var/macports/distfiles/gnome-applets/gnome-applets/gnome- 
>> applets/gnome-applets/gnome-applets/gnome-applets/gnome-applets/ 
>> gnome-applets/gnome-applets/gnome-applets/gnome-applets/gnome- 
>> applets/gnome-applets
>>
>> --->  Attempting to fetch gnome-applets-2.24.0.tar.bz2 from
>> http://mandril.creatis.insa-lyon.fr/linux/gnome.org/sources/gnome-applets/2.24/
>>
>>  % Total    % Received % Xferd  Average Speed   Time    Time     Time
>> Current
>>                                 Dload  Upload   Total   Spent    Left
>> Speed
>> 44 7291k   44 3215k    0     0  93842      0  0:01:19  0:00:35   
>> 0:00:44
>> 96460
>>
>> I hope this is fixed in 1.7............
>
> It is. That's <http://trac.macports.org/ticket/11971>.
>
> - Josh

Josh, that's wonderful. :)

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

Mundus vult decepi, ego non


From ryandesign at macports.org  Thu Nov 13 13:38:00 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 13 Nov 2008 15:38:00 -0600
Subject: [42000] trunk/dports/x11/gtk2-murrine-configurator
In-Reply-To: <20081113133251.E9F276993AE@beta.macosforge.org>
References: <20081113133251.E9F276993AE@beta.macosforge.org>
Message-ID: <A5BBFB01-DA06-4A82-9986-BD9E47B152C2@macports.org>

On Nov 13, 2008, at 07:32, nox at macports.org wrote:

> -    reinplace -E "s|/usr/bin/env python|${prefix}/bin/python2.5|" \
> -        ${worksrcpath}/src/newmurrineconfigurator.py
> +    reinplace -E s|@PREFIX@|$prefix| \
> +        $worksrcpath/src/newmurrineconfigurator.py

Just out of curiosity, why are you in the habit lately of removing  
the braces from variables?  We've been using braces around variables  
almost everywhere in MacPorts for a long time... why change now?



From ryandesign at macports.org  Thu Nov 13 13:39:48 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 13 Nov 2008 15:39:48 -0600
Subject: [42009] trunk/dports/graphics/tiff/Portfile
In-Reply-To: <20081113153802.0053269A079@beta.macosforge.org>
References: <20081113153802.0053269A079@beta.macosforge.org>
Message-ID: <93E930D2-9A7F-4B09-9FEB-9F66655057EA@macports.org>

On Nov 13, 2008, at 09:38, nox at macports.org wrote:

> Revision: 42009
>           http://trac.macports.org/changeset/42009
> Author:   nox at macports.org
> Date:     2008-11-13 07:38:01 -0800 (Thu, 13 Nov 2008)
> Log Message:
> -----------
> tiff: Fixed livecheck.
>
> Modified Paths:
> --------------
>     trunk/dports/graphics/tiff/Portfile
>
> Modified: trunk/dports/graphics/tiff/Portfile
> ===================================================================
> --- trunk/dports/graphics/tiff/Portfile	2008-11-13 15:32:26 UTC  
> (rev 42008)
> +++ trunk/dports/graphics/tiff/Portfile	2008-11-13 15:38:01 UTC  
> (rev 42009)
> @@ -4,7 +4,6 @@
>
>  name		tiff
>  version		3.8.2
> -revision	2
>  categories	graphics
>  maintainers	waqar at macports.org
>  description	Library and tools for dealing with Tag Image File Format

I don't think it's right to remove the revision for this change....


From nox at macports.org  Thu Nov 13 13:50:40 2008
From: nox at macports.org (nox)
Date: Thu, 13 Nov 2008 22:50:40 +0100
Subject: [42009] trunk/dports/graphics/tiff/Portfile
In-Reply-To: <93E930D2-9A7F-4B09-9FEB-9F66655057EA@macports.org>
References: <20081113153802.0053269A079@beta.macosforge.org>
	<93E930D2-9A7F-4B09-9FEB-9F66655057EA@macports.org>
Message-ID: <C9407080-0C65-410B-9A82-C3F2915D66C6@macports.org>

Le 13 nov. 08 ? 22:39, Ryan Schmidt a ?crit :

> On Nov 13, 2008, at 09:38, nox at macports.org wrote:
>
>> Revision: 42009
>>          http://trac.macports.org/changeset/42009
>> Author:   nox at macports.org
>> Date:     2008-11-13 07:38:01 -0800 (Thu, 13 Nov 2008)
>> Log Message:
>> -----------
>> tiff: Fixed livecheck.
>>
>> Modified Paths:
>> --------------
>>    trunk/dports/graphics/tiff/Portfile
>>
>> Modified: trunk/dports/graphics/tiff/Portfile
>> ===================================================================
>> --- trunk/dports/graphics/tiff/Portfile	2008-11-13 15:32:26 UTC  
>> (rev 42008)
>> +++ trunk/dports/graphics/tiff/Portfile	2008-11-13 15:38:01 UTC  
>> (rev 42009)
>> @@ -4,7 +4,6 @@
>>
>> name		tiff
>> version		3.8.2
>> -revision	2
>> categories	graphics
>> maintainers	waqar at macports.org
>> description	Library and tools for dealing with Tag Image File Format
>
> I don't think it's right to remove the revision for this change....
>

That was a mistake. In fact, the previous livecheck reported 4.0.0, so  
I began to update the Portfile.
Then I figured out 4.0.0 is in fact 4.0.0alpha and that the port  
should not be updated.
I should have just run `svn revert` instead of manually restoring the  
version, my bad.

Reverted in r42046.

From nox at macports.org  Thu Nov 13 13:51:50 2008
From: nox at macports.org (nox)
Date: Thu, 13 Nov 2008 22:51:50 +0100
Subject: [42000] trunk/dports/x11/gtk2-murrine-configurator
In-Reply-To: <A5BBFB01-DA06-4A82-9986-BD9E47B152C2@macports.org>
References: <20081113133251.E9F276993AE@beta.macosforge.org>
	<A5BBFB01-DA06-4A82-9986-BD9E47B152C2@macports.org>
Message-ID: <0315BC33-74E4-40A5-9897-6C617239EEC5@macports.org>

Le 13 nov. 08 ? 22:38, Ryan Schmidt a ?crit :

> On Nov 13, 2008, at 07:32, nox at macports.org wrote:
>
>> -    reinplace -E "s|/usr/bin/env python|${prefix}/bin/python2.5|" \
>> -        ${worksrcpath}/src/newmurrineconfigurator.py
>> +    reinplace -E s|@PREFIX@|$prefix| \
>> +        $worksrcpath/src/newmurrineconfigurator.py
>
> Just out of curiosity, why are you in the habit lately of removing  
> the braces from variables?  We've been using braces around variables  
> almost everywhere in MacPorts for a long time... why change now?

Got the habit writing shell scripts, does it bother you? I can lose  
this habit if you want.

From blb at macports.org  Thu Nov 13 14:48:00 2008
From: blb at macports.org (Bryan Blackburn)
Date: Thu, 13 Nov 2008 15:48:00 -0700
Subject: [42000] trunk/dports/x11/gtk2-murrine-configurator
In-Reply-To: <0315BC33-74E4-40A5-9897-6C617239EEC5@macports.org>
References: <20081113133251.E9F276993AE@beta.macosforge.org>
	<A5BBFB01-DA06-4A82-9986-BD9E47B152C2@macports.org>
	<0315BC33-74E4-40A5-9897-6C617239EEC5@macports.org>
Message-ID: <20081113224800.GG515@ninagal.withay.com>

On Thu, Nov 13, 2008 at 10:51:50PM +0100, nox said:
> Le 13 nov. 08 ? 22:38, Ryan Schmidt a ?crit :
>
>> On Nov 13, 2008, at 07:32, nox at macports.org wrote:
>>
>>> -    reinplace -E "s|/usr/bin/env python|${prefix}/bin/python2.5|" \
>>> -        ${worksrcpath}/src/newmurrineconfigurator.py
>>> +    reinplace -E s|@PREFIX@|$prefix| \
>>> +        $worksrcpath/src/newmurrineconfigurator.py
>>
>> Just out of curiosity, why are you in the habit lately of removing the 
>> braces from variables?  We've been using braces around variables almost 
>> everywhere in MacPorts for a long time... why change now?
>
> Got the habit writing shell scripts, does it bother you? I can lose this 
> habit if you want.

${variable} works in shell scripts too; while only needed when other
variable-valid characters follow, it definitely isn't hurting things, though
if it is your port, it's your choice.

Bryan


From macsforever2000 at macports.org  Thu Nov 13 17:47:10 2008
From: macsforever2000 at macports.org (Frank Schima)
Date: Thu, 13 Nov 2008 18:47:10 -0700
Subject: [41898] trunk/dports/gis
In-Reply-To: <766DE177-1734-4866-93DC-A0E0DB99AECF@macports.org>
References: <20081112030237.933E368B40A@beta.macosforge.org>
	<766DE177-1734-4866-93DC-A0E0DB99AECF@macports.org>
Message-ID: <9F7A12AD-F6CB-43F8-8AFD-FD57E5A1E076@macports.org>

Hi Ryan,


On Nov 11, 2008, at 8:39 PM, Ryan Schmidt wrote:

> On Nov 11, 2008, at 21:02, macsforever2000 at macports.org wrote:
>
>> +set cgi_path "/Library/WebServer/CGI-Executables/"
>> +
>> +# apache macport interop
>> +if {[ file exists ${prefix}/sbin/httpd]} {
>> +    set cgi_path "${prefix}/www/cgi-bin/"
>> +}
>
> It's not good for a port to behave differently depending on what  
> else the user has installed. A port should behave identically on  
> everyone's system (modulo such details as OS version and processor  
> architecture).
>
> Instead, I recommend some variants to let the user select whether  
> they want to use MacPorts Apache 1, MacPorts Apache 2, or whatever  
> Apache Apple includes with Mac OS X.
>
>
> variant apache conflicts apache2 apache_apple description {Use  
> MacPorts Apache 1} {
> 	depends_run-append port:apache
> 	set cgi_path "${prefix}/www/cgi-bin/"
> }
>
> variant apache2 conflicts apache apache_apple description {Use  
> MacPorts Apache 2} {
> 	depends_run-append port:apache2
> 	set cgi_path "${prefix}/apache2/cgi-bin/"
> }
>
> variant apache_apple conflicts apache apache2 description {Use Apple  
> Apache} {
> 	set cgi_path "/Library/WebServer/CGI-Executables/"
> }
>
> if {![variant_isset apache] && ![variant_isset apache2] && ! 
> [variant_isset apache_apple]} {
> 	default_variants +apache2
> }
>
>
> Actually there are also web servers other than Apache -- lighttpd  
> for example...

I made the change but I get an error when building:

$ sudo port install mapserver
--->  Fetching mapserver
--->  Verifying checksum(s) for mapserver
--->  Extracting mapserver
--->  Applying patches to mapserver
--->  Configuring mapserver
--->  Building mapserver with target all
--->  Staging mapserver into destroot
Error: Target org.macports.destroot returned: can't read "cgi_path":  
no such variable
Error: Status 1 encountered during processing.

I'm not sure how to fix it. I'm attaching my Portfile.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Portfile
Type: application/octet-stream
Size: 1905 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20081113/2335e5a8/attachment.obj>
-------------- next part --------------



Cheers!
Frank




From ryandesign at macports.org  Thu Nov 13 22:04:25 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 14 Nov 2008 00:04:25 -0600
Subject: [41898] trunk/dports/gis
In-Reply-To: <9F7A12AD-F6CB-43F8-8AFD-FD57E5A1E076@macports.org>
References: <20081112030237.933E368B40A@beta.macosforge.org>
	<766DE177-1734-4866-93DC-A0E0DB99AECF@macports.org>
	<9F7A12AD-F6CB-43F8-8AFD-FD57E5A1E076@macports.org>
Message-ID: <6D8BF6C8-8D41-4449-9BB0-EA3100FCE0CA@macports.org>

Sorry... in each variant before you set cgi_path, add the line  
"global cgi_path", that should do it.


On Nov 13, 2008, at 19:47, Frank Schima wrote:

> Hi Ryan,
>
>
> On Nov 11, 2008, at 8:39 PM, Ryan Schmidt wrote:
>
>> On Nov 11, 2008, at 21:02, macsforever2000 at macports.org wrote:
>>
>>> +set cgi_path "/Library/WebServer/CGI-Executables/"
>>> +
>>> +# apache macport interop
>>> +if {[ file exists ${prefix}/sbin/httpd]} {
>>> +    set cgi_path "${prefix}/www/cgi-bin/"
>>> +}
>>
>> It's not good for a port to behave differently depending on what  
>> else the user has installed. A port should behave identically on  
>> everyone's system (modulo such details as OS version and processor  
>> architecture).
>>
>> Instead, I recommend some variants to let the user select whether  
>> they want to use MacPorts Apache 1, MacPorts Apache 2, or whatever  
>> Apache Apple includes with Mac OS X.
>>
>>
>> variant apache conflicts apache2 apache_apple description {Use  
>> MacPorts Apache 1} {
>> 	depends_run-append port:apache
>> 	set cgi_path "${prefix}/www/cgi-bin/"
>> }
>>
>> variant apache2 conflicts apache apache_apple description {Use  
>> MacPorts Apache 2} {
>> 	depends_run-append port:apache2
>> 	set cgi_path "${prefix}/apache2/cgi-bin/"
>> }
>>
>> variant apache_apple conflicts apache apache2 description {Use  
>> Apple Apache} {
>> 	set cgi_path "/Library/WebServer/CGI-Executables/"
>> }
>>
>> if {![variant_isset apache] && ![variant_isset apache2] && ! 
>> [variant_isset apache_apple]} {
>> 	default_variants +apache2
>> }
>>
>>
>> Actually there are also web servers other than Apache -- lighttpd  
>> for example...
>
> I made the change but I get an error when building:
>
> $ sudo port install mapserver
> --->  Fetching mapserver
> --->  Verifying checksum(s) for mapserver
> --->  Extracting mapserver
> --->  Applying patches to mapserver
> --->  Configuring mapserver
> --->  Building mapserver with target all
> --->  Staging mapserver into destroot
> Error: Target org.macports.destroot returned: can't read  
> "cgi_path": no such variable
> Error: Status 1 encountered during processing.
>
> I'm not sure how to fix it. I'm attaching my Portfile.<Portfile>
>
>
> Cheers!
> Frank
>
>
>


From ryandesign at macports.org  Thu Nov 13 22:45:33 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 14 Nov 2008 00:45:33 -0600
Subject: [42000] trunk/dports/x11/gtk2-murrine-configurator
In-Reply-To: <20081113224800.GG515@ninagal.withay.com>
References: <20081113133251.E9F276993AE@beta.macosforge.org>
	<A5BBFB01-DA06-4A82-9986-BD9E47B152C2@macports.org>
	<0315BC33-74E4-40A5-9897-6C617239EEC5@macports.org>
	<20081113224800.GG515@ninagal.withay.com>
Message-ID: <E769361E-0AC2-4322-96C1-E165A8765E99@macports.org>

On Nov 13, 2008, at 16:48, Bryan Blackburn wrote:

> On Thu, Nov 13, 2008 at 10:51:50PM +0100, nox said:
>
>> Le 13 nov. 08 ? 22:38, Ryan Schmidt a ?crit :
>>
>>> On Nov 13, 2008, at 07:32, nox at macports.org wrote:
>>>
>>>> -    reinplace -E "s|/usr/bin/env python|${prefix}/bin/ 
>>>> python2.5|" \
>>>> -        ${worksrcpath}/src/newmurrineconfigurator.py
>>>> +    reinplace -E s|@PREFIX@|$prefix| \
>>>> +        $worksrcpath/src/newmurrineconfigurator.py
>>>
>>> Just out of curiosity, why are you in the habit lately of  
>>> removing the
>>> braces from variables?  We've been using braces around variables  
>>> almost
>>> everywhere in MacPorts for a long time... why change now?
>>
>> Got the habit writing shell scripts, does it bother you? I can  
>> lose this
>> habit if you want.
>
> ${variable} works in shell scripts too; while only needed when other
> variable-valid characters follow, it definitely isn't hurting  
> things, though
> if it is your port, it's your choice.

While I know the braces aren't necessary, they have been our style,  
so for consistency I'd like to keep them. I also find it helps me to  
visually spot variables more easily when I'm skimming Portfiles.


From macsforever2000 at macports.org  Fri Nov 14 08:27:28 2008
From: macsforever2000 at macports.org (Frank Schima)
Date: Fri, 14 Nov 2008 09:27:28 -0700
Subject: [41898] trunk/dports/gis
In-Reply-To: <6D8BF6C8-8D41-4449-9BB0-EA3100FCE0CA@macports.org>
References: <20081112030237.933E368B40A@beta.macosforge.org>
	<766DE177-1734-4866-93DC-A0E0DB99AECF@macports.org>
	<9F7A12AD-F6CB-43F8-8AFD-FD57E5A1E076@macports.org>
	<6D8BF6C8-8D41-4449-9BB0-EA3100FCE0CA@macports.org>
Message-ID: <151954DC-CB46-41C2-A53F-0B9C712AEDC0@macports.org>

Hi Ryan,


On Nov 13, 2008, at 11:04 PM, Ryan Schmidt wrote:

> Sorry... in each variant before you set cgi_path, add the line  
> "global cgi_path", that should do it.

That fixed it. Thanks! I've added the changes in r42073.

Although now it complains as follows:

--->  Staging mapserver into destroot
Warning: violation by /opt/local/apache2
Warning: mapserver violates the layout of the ports-filesystems!
Warning: Please fix or indicate this misbehavior (if it is intended),  
it will be an error in future releases!
--->  Installing mapserver @5.2.0_0+apache2
--->  Activating mapserver @5.2.0_0+apache2
--->  Cleaning mapserver

According to port contents, it contains the following file:

/opt/local/apache2/cgi-bin/mapserv

Is that a problem? If so, what is the fix?


Cheers!
Frank


From jmr at macports.org  Fri Nov 14 08:33:05 2008
From: jmr at macports.org (Joshua Root)
Date: Sat, 15 Nov 2008 03:33:05 +1100
Subject: [41898] trunk/dports/gis
In-Reply-To: <151954DC-CB46-41C2-A53F-0B9C712AEDC0@macports.org>
References: <20081112030237.933E368B40A@beta.macosforge.org>	<766DE177-1734-4866-93DC-A0E0DB99AECF@macports.org>	<9F7A12AD-F6CB-43F8-8AFD-FD57E5A1E076@macports.org>	<6D8BF6C8-8D41-4449-9BB0-EA3100FCE0CA@macports.org>
	<151954DC-CB46-41C2-A53F-0B9C712AEDC0@macports.org>
Message-ID: <491DA841.1000004@macports.org>

Frank Schima wrote:
> Although now it complains as follows:
> 
> --->  Staging mapserver into destroot
> Warning: violation by /opt/local/apache2
> Warning: mapserver violates the layout of the ports-filesystems!
> Warning: Please fix or indicate this misbehavior (if it is intended), it
> will be an error in future releases!
> --->  Installing mapserver @5.2.0_0+apache2
> --->  Activating mapserver @5.2.0_0+apache2
> --->  Cleaning mapserver
> 
> According to port contents, it contains the following file:
> 
> /opt/local/apache2/cgi-bin/mapserv
> 
> Is that a problem? If so, what is the fix?

Not a big problem, apache2 just puts things outside the usual places for
whatever reason. The thing to add is:

destroot.violate_mtree      yes

- Josh

From macsforever2000 at macports.org  Fri Nov 14 08:45:52 2008
From: macsforever2000 at macports.org (Frank Schima)
Date: Fri, 14 Nov 2008 09:45:52 -0700
Subject: [41898] trunk/dports/gis
In-Reply-To: <491DA841.1000004@macports.org>
References: <20081112030237.933E368B40A@beta.macosforge.org>	<766DE177-1734-4866-93DC-A0E0DB99AECF@macports.org>	<9F7A12AD-F6CB-43F8-8AFD-FD57E5A1E076@macports.org>	<6D8BF6C8-8D41-4449-9BB0-EA3100FCE0CA@macports.org>
	<151954DC-CB46-41C2-A53F-0B9C712AEDC0@macports.org>
	<491DA841.1000004@macports.org>
Message-ID: <47E507A3-D7FB-46B1-BE97-3BFB23E79F10@macports.org>


On Nov 14, 2008, at 9:33 AM, Joshua Root wrote:

> Frank Schima wrote:
>> Although now it complains as follows:
>>
>> --->  Staging mapserver into destroot
>> Warning: violation by /opt/local/apache2
>> Warning: mapserver violates the layout of the ports-filesystems!
>> Warning: Please fix or indicate this misbehavior (if it is  
>> intended), it
>> will be an error in future releases!
>> --->  Installing mapserver @5.2.0_0+apache2
>> --->  Activating mapserver @5.2.0_0+apache2
>> --->  Cleaning mapserver
>>
>> According to port contents, it contains the following file:
>>
>> /opt/local/apache2/cgi-bin/mapserv
>>
>> Is that a problem? If so, what is the fix?
>
> Not a big problem, apache2 just puts things outside the usual places  
> for
> whatever reason. The thing to add is:
>
> destroot.violate_mtree      yes

That lessened the warning message. Thanks! Committed in r42074.


Cheers!
Frank



From tomaslin at gmail.com  Fri Nov 14 09:33:19 2008
From: tomaslin at gmail.com (Tomas Lin)
Date: Fri, 14 Nov 2008 12:33:19 -0500
Subject: Grails port updated to 1.0.4
Message-ID: <144114be0811140933v4a00a9a2k3b1bc6ecbe59de81@mail.gmail.com>

Grails has been updated to 1.0.4, and the port file is openmantainer.

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

can someone take a look at this ticket?

Thanks,

Tomas

From vincent-opdarw at vinc17.org  Fri Nov 14 18:18:26 2008
From: vincent-opdarw at vinc17.org (Vincent Lefevre)
Date: Sat, 15 Nov 2008 03:18:26 +0100
Subject: charset.alias bug
Message-ID: <20081115021826.GB1644@prunille.vinc17.org>

At least 5 ports installed a broken ${prefix}/lib/charset.alias file:
  http://trac.macports.org/ticket/11474
  http://trac.macports.org/ticket/11968
  http://trac.macports.org/ticket/16152
  http://trac.macports.org/ticket/17084

Since this seems to be a more or less global problem, shouldn't the
removal of this file be handled by the base?

-- 
Vincent Lef?vre <vincent at vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

From blb at macports.org  Fri Nov 14 18:33:32 2008
From: blb at macports.org (Bryan Blackburn)
Date: Fri, 14 Nov 2008 19:33:32 -0700
Subject: charset.alias bug
In-Reply-To: <20081115021826.GB1644@prunille.vinc17.org>
References: <20081115021826.GB1644@prunille.vinc17.org>
Message-ID: <20081115023332.GQ748@ninagal.withay.com>

On Sat, Nov 15, 2008 at 03:18:26AM +0100, Vincent Lefevre said:
> At least 5 ports installed a broken ${prefix}/lib/charset.alias file:
>   http://trac.macports.org/ticket/11474
>   http://trac.macports.org/ticket/11968
>   http://trac.macports.org/ticket/16152
>   http://trac.macports.org/ticket/17084
> 
> Since this seems to be a more or less global problem, shouldn't the
> removal of this file be handled by the base?

That's my opinion, considering the list Ryan mentioned in #16122:

<http://trac.macports.org/ticket/16122#comment:2>

Bryan


> 
> -- 
> Vincent Lef?vre <vincent at vinc17.org> - Web: <http://www.vinc17.org/>
> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

From ryandesign at macports.org  Fri Nov 14 20:14:51 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 14 Nov 2008 22:14:51 -0600
Subject: charset.alias bug
In-Reply-To: <20081115023332.GQ748@ninagal.withay.com>
References: <20081115021826.GB1644@prunille.vinc17.org>
	<20081115023332.GQ748@ninagal.withay.com>
Message-ID: <09497223-C35D-40B3-ADE0-49192B8DF9D9@macports.org>


On Nov 14, 2008, at 20:33, Bryan Blackburn wrote:

> On Sat, Nov 15, 2008 at 03:18:26AM +0100, Vincent Lefevre said:
>> At least 5 ports installed a broken ${prefix}/lib/charset.alias file:
>>   http://trac.macports.org/ticket/11474
>>   http://trac.macports.org/ticket/11968
>>   http://trac.macports.org/ticket/16152
>>   http://trac.macports.org/ticket/17084
>>
>> Since this seems to be a more or less global problem, shouldn't the
>> removal of this file be handled by the base?
>
> That's my opinion, considering the list Ryan mentioned in #16122:
>
> <http://trac.macports.org/ticket/16122#comment:2>

I wrote a list?

(checks)

Oh yes. Look that. Sure, base could take care of deleting ${destroot}$ 
{prefix}/lib/charset.alias for you.

If it did, it should probably delete ${destroot}${prefix}/share/ 
locale/locale.alias as well.

We also have a problem with files named perllocal.pod anywhere in $ 
{destroot}. Several ports go to some lengths to delete these, not all  
correctly.



From ryandesign at macports.org  Sun Nov 16 00:25:08 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 16 Nov 2008 02:25:08 -0600
Subject: [42158] trunk/dports/lang/llvm/Portfile
In-Reply-To: <20081116071334.506226B57E0@beta.macosforge.org>
References: <20081116071334.506226B57E0@beta.macosforge.org>
Message-ID: <908878DB-E4A2-445E-B5AD-01157DE6EE40@macports.org>

On Nov 16, 2008, at 01:13, erickt at macports.org wrote:

> Revision: 42158
>           http://trac.macports.org/changeset/42158
> Author:   erickt at macports.org
> Date:     2008-11-15 23:13:33 -0800 (Sat, 15 Nov 2008)
> Log Message:
> -----------
> Adding a pic option to llvm from {17268}. Thanks Arto!

In the future it would be best not to increment the revision unless  
rebuilding the port will result in different files being installed on  
the user's system. In this case, no existing users have the pic  
variant because it did not exist before, so forcing everyone to  
rebuild is not necessary, and doesn't gain anyone anything.

I'm also curious to know: for what reason might I want to use this  
variant? What is position-independent code and why might I want or  
not want it?


> Modified Paths:
> --------------
>     trunk/dports/lang/llvm/Portfile
>
> Modified: trunk/dports/lang/llvm/Portfile
> ===================================================================
> --- trunk/dports/lang/llvm/Portfile	2008-11-16 06:51:29 UTC (rev  
> 42157)
> +++ trunk/dports/lang/llvm/Portfile	2008-11-16 07:13:33 UTC (rev  
> 42158)
> @@ -4,6 +4,7 @@
>
>  name                    llvm
>  version                 2.4
> +revision                1
>  categories              lang
>  platforms               darwin
>  use_parallel_build      yes
> @@ -57,3 +58,7 @@
>          }
>      }
>  }
> +
> +variant pic description {Enable generation of position independent  
> code} {
> +    configure.args-append --enable-pic
> +}



From blb at macports.org  Sun Nov 16 00:34:06 2008
From: blb at macports.org (Bryan Blackburn)
Date: Sun, 16 Nov 2008 01:34:06 -0700
Subject: [42158] trunk/dports/lang/llvm/Portfile
In-Reply-To: <908878DB-E4A2-445E-B5AD-01157DE6EE40@macports.org>
References: <20081116071334.506226B57E0@beta.macosforge.org>
	<908878DB-E4A2-445E-B5AD-01157DE6EE40@macports.org>
Message-ID: <20081116083406.GL512@ninagal.withay.com>

On Sun, Nov 16, 2008 at 02:25:08AM -0600, Ryan Schmidt said:
> On Nov 16, 2008, at 01:13, erickt at macports.org wrote:
>
>> Revision: 42158
>>           http://trac.macports.org/changeset/42158
>> Author:   erickt at macports.org
>> Date:     2008-11-15 23:13:33 -0800 (Sat, 15 Nov 2008)
>> Log Message:
>> -----------
>> Adding a pic option to llvm from {17268}. Thanks Arto!
>
> In the future it would be best not to increment the revision unless  
> rebuilding the port will result in different files being installed on the 
> user's system. In this case, no existing users have the pic variant 
> because it did not exist before, so forcing everyone to rebuild is not 
> necessary, and doesn't gain anyone anything.
>
> I'm also curious to know: for what reason might I want to use this  
> variant? What is position-independent code and why might I want or not 
> want it?

I'd like to know if there's any reason why it can't be part of the default
build instead of being a variant.  Position-independent code (PIC) is
basically code which can be relocated in memory which is what's used by
shared libraries and such.  Note that on Mac OS X, PIC is the default case
when using gcc, and since the Mac really likes dynamic libraries over
static, PIC would make more sense.

Bryan


>
>
>> Modified Paths:
>> --------------
>>     trunk/dports/lang/llvm/Portfile
>>
>> Modified: trunk/dports/lang/llvm/Portfile
>> ===================================================================
>> --- trunk/dports/lang/llvm/Portfile	2008-11-16 06:51:29 UTC (rev 42157)
>> +++ trunk/dports/lang/llvm/Portfile	2008-11-16 07:13:33 UTC (rev 42158)
>> @@ -4,6 +4,7 @@
>>
>>  name                    llvm
>>  version                 2.4
>> +revision                1
>>  categories              lang
>>  platforms               darwin
>>  use_parallel_build      yes
>> @@ -57,3 +58,7 @@
>>          }
>>      }
>>  }
>> +
>> +variant pic description {Enable generation of position independent  
>> code} {
>> +    configure.args-append --enable-pic
>> +}
>

From macsforever2000 at macports.org  Mon Nov 17 08:18:49 2008
From: macsforever2000 at macports.org (Frank Schima)
Date: Mon, 17 Nov 2008 09:18:49 -0700
Subject: [42213] trunk/dports/science
In-Reply-To: <20081116215007.3C5846C0BB5@beta.macosforge.org>
References: <20081116215007.3C5846C0BB5@beta.macosforge.org>
Message-ID: <5CF0D8E8-DA1E-452E-9A9E-0E8E576F849A@macports.org>


On Nov 16, 2008, at 2:50 PM, mmoll at macports.org wrote:
> Revision
> 42213
> Author
> mmoll at macports.org
> Date
> 2008-11-16 13:50:06 -0800 (Sun, 16 Nov 2008)
> Log Message
>
> New port: hdf5-18. HDF5 1.8.2 is the latest official release. The  
> hdf5 port is for version 1.6. Version 1.6 and 1.8 are not compatible  
> with each other. So to avoid breaking code that depends on the  
> existing hdf5 port, I created a new port. See also ticket #16263.
> Added Paths
>
> trunk/dports/science/hdf5-18/
> trunk/dports/science/hdf5-18/Portfile
> Diff
>
> Added: trunk/dports/science/hdf5-18/Portfile (0 => 42213)
> --- trunk/dports/science/hdf5-18/Portfile	                         
> (rev 0)
> +++ trunk/dports/science/hdf5-18/Portfile	2008-11-16 21:50:06 UTC  
> (rev 42213)
> @@ -0,0 +1,54 @@
> +# -*- coding: utf-8; mode: tcl; c-basic-offset: 4; indent-tabs- 
> mode: nil; tab-width: 4; truncate-lines: t -*-  
> vim:fenc=utf-8:et:sw=4:ts=4:sts=4
> +# $Id$
> +
> +PortSystem          1.0
> +
> +set realname        hdf5
> +name                ${realname}-18
> +version             1.8.2
> +categories          science
> +maintainers         mmoll nomaintainer

I assume you mean openmaintainer here?

> +
> +description         HDF5 general purpose library and file format  
> for storing scientific data
> +long_description    ${description}
> +homepage            http://www.hdfgroup.org/HDF5/
> +platforms           darwin
> +master_sites        ftp://ftp.hdfgroup.org/HDF5/current/src/
> +checksums           md5 af92ef65ef495dbd205131574ad4eee1 \
> +                    sha1 76bca25b0d23c1921fd97f87b8d2b21d580f0618 \
> +                    rmd160 809aa6860ef095e7d72bb79ddc4a857f8cc39424
> +distname            ${realname}-${version}
> +extract.suffix      .tar.gz
> +depends_lib         port:zlib port:szip port:openmpi
> +
> +use_parallel_build  yes
> +
> +configure.args      --with-zlib=yes --with-szlib=yes --enable- 
> filters=all \
> +                    --enable-production --enable-parallel --disable- 
> fortran \
> +                    --disable-cxx
> +configure.cc        ${prefix}/bin/openmpicc
> +configure.cxx       ${prefix}/bin/openmpicxx
> +configure.fc        ${prefix}/bin/openmpif77
> +
> +# variant descriptions
> +
> +variant fortran description {Include the Fortran interface} {
> +    if { [variant_isset gcc43] || [variant_isset gcc42] ||  
> [variant_isset g95] } {
> +        configure.args-delete   --disable-fortran
> +        configure.args-append   --enable-fortran
> +    } else {
> +        error "You must specify a compiler variant in order to  
> build the Fortran interface"
> +    }
> +}
> +
> +variant gcc42 requires fortran conflicts g95 gcc43 description  
> {Compile using GCC 4.2} {
> +    depends_lib-append          port:gcc42
> +}
> +
> +variant gcc43 requires fortran conflicts g95 gcc42 description  
> {Compile using GCC 4.3} {
> +    depends_lib-append          port:gcc43
> +}
> +
> +variant g95 requires fortran conflicts gcc42 gcc43 description {Use  
> g95 Fortran compiler (unsupported)} {
> +    depends_lib-append          port:g95
> +}
> Property changes on: trunk/dports/science/hdf5-18/Portfile
> ___________________________________________________________________
> Added: svn:keywords
> Added: svn:eol-style
> _______________________________________________
> macports-changes mailing list
> macports-changes at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20081117/d36aa7c2/attachment.html>

From n.oxyde at gmail.com  Mon Nov 17 10:29:50 2008
From: n.oxyde at gmail.com (nox)
Date: Mon, 17 Nov 2008 19:29:50 +0100
Subject: [42257] trunk/dports/devel/git-core/files/patch-Makefile.diff
In-Reply-To: <20081117180146.E16B76D86D9@beta.macosforge.org>
References: <20081117180146.E16B76D86D9@beta.macosforge.org>
Message-ID: <2E094CBC-EA13-4C66-A079-E71AAB5060C6@gmail.com>

Le 17 nov. 08 ? 19:01, simon at macports.org a ?crit :

> Revision42257Authorsimon at macports.orgDate2008-11-17 10:01:45 -0800  
> (Mon, 17 Nov 2008)Log Message
> devel/git-core: Fixed compiling on Tiger, closes #17222. Thanks to maccheck at gmail.com 
> .
> Modified Paths
> 	? trunk/dports/devel/git-core/files/patch-Makefile.diff
> Diff
> Modified: trunk/dports/devel/git-core/files/patch-Makefile.diff  
> (42256 => 42257)
> --- trunk/dports/devel/git-core/files/patch-Makefile.diff	2008-11-17  
> 17:51:48 UTC (rev 42256)
> +++ trunk/dports/devel/git-core/files/patch-Makefile.diff	2008-11-17  
> 18:01:45 UTC (rev 42257)
> @@ -1,5 +1,5 @@
> ---- Makefile.orig	2008-10-22 11:12:25.000000000 +0200
> -+++ Makefile	2008-10-22 11:13:23.000000000 +0200
> +--- Makefile.orig	2008-11-13 19:55:15.000000000 +0100
> ++++ Makefile	2008-11-13 19:56:36.000000000 +0100
>  @@ -113,7 +113,7 @@
>   #
>   # Define NO_R_TO_GCC_LINKER if your gcc does not like "-R/path/lib"
> @@ -23,7 +23,7 @@
>   	# Some gcc does not accept and pass -R to the linker to specify
>   	# the runtime dynamic library path.
>  -	CC_LD_DYNPATH = -Wl,-rpath=
> -+	CC_LD_DYNPATH = -Wl,-rpath,
> ++	CC_LD_DYNPATH = -L
>   else
>   	CC_LD_DYNPATH = -R
>   endif

Instead of a patch, can't you just do `build.args-append  
CC_LD_DYNPATH=-L`?

Regards,
Anthony Ramine.


From ryandesign at macports.org  Mon Nov 17 16:03:39 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 17 Nov 2008 18:03:39 -0600
Subject: [42265] trunk/dports/lang/ghc
In-Reply-To: <20081117215303.A0A906DA690@beta.macosforge.org>
References: <20081117215303.A0A906DA690@beta.macosforge.org>
Message-ID: <01BB0AE5-4955-4E37-BD39-11380DFCC8DC@macports.org>

On Nov 17, 2008, at 15:53, gwright at macports.org wrote:

> Revision: 42265
>           http://trac.macports.org/changeset/42265
> Author:   gwright at macports.org
> Date:     2008-11-17 13:53:03 -0800 (Mon, 17 Nov 2008)
> Log Message:
> -----------
> Fix the builds on ppc/Tiger, i386/Tiger and (maybe) ppc/Leopard.


It doesn't seem to work yet on Tiger on Intel:

$ port upgrade ghc
--->  Fetching ghc
--->  Attempting to fetch ghc-6.6-darwin-i386-tiger-bootstrap- 
rev1.tar.bz2 from http://haskell.org/ghc/dist/6.6/
--->  Verifying checksum(s) for ghc
Error: No checksum set for ghc-6.6-darwin-i386-tiger-bootstrap- 
rev1.tar.bz2
Error: Target org.macports.checksum returned: Unable to verify file  
checksums
Error: Unable to upgrade port: 1



From n.oxyde at gmail.com  Tue Nov 18 07:07:48 2008
From: n.oxyde at gmail.com (nox)
Date: Tue, 18 Nov 2008 16:07:48 +0100
Subject: [42296] trunk/dports/databases/db46/Portfile
In-Reply-To: <20081118145520.AABBA6E2573@beta.macosforge.org>
References: <20081118145520.AABBA6E2573@beta.macosforge.org>
Message-ID: <71F23A4D-958B-487D-97E0-EE11B005C738@gmail.com>

Le 18 nov. 08 ? 15:55, nottwo at macports.org a ?crit :

> Revision42296Authornottwo at macports.orgDate2008-11-18 06:55:20 -0800  
> (Tue, 18 Nov 2008)Log Message
> Add variant that builds db_dump185.  Closes #16301
> Modified Paths
> 	? trunk/dports/databases/db46/Portfile
> Diff
> Modified: trunk/dports/databases/db46/Portfile (42295 => 42296)
> --- trunk/dports/databases/db46/Portfile	2008-11-18 14:51:39 UTC  
> (rev 42295)
> +++ trunk/dports/databases/db46/Portfile	2008-11-18 14:55:20 UTC  
> (rev 42296)
> @@ -51,12 +51,21 @@
>  		move ${destroot}${prefix}/bin/db_${bin} \
>  			${destroot}${prefix}/bin/db46_${bin}
>  	}
> +
> +        if { [ variant_isset dump185 ] } {
> +            move ${destroot}${prefix}/bin/db_dump185 \
> +                ${destroot}${prefix}/bin/db46_dump185
> +        }
>  }
>
>  variant java description {Enable java bindings} {
>  	configure.args-append --enable-java
>  }
>
> +variant dump185 description {Build db_dump185 tool} {
> +        configure.args-append --enable-dump185
> +}
> +
>  livecheck.check regex
>  livecheck.url   http://www.oracle.com/technology/documentation/berkeley-db/db/ref/changelog/4.6.html
>  livecheck.regex {Berkeley DB (\d+(?:\.\d+)*)}
One question and a little suggestion:
Why a variant for this small utility?
Instead of testing whether the variant is set, you could write another  
post-destroot block in the variant itself.

From devans at macports.org  Tue Nov 18 10:11:17 2008
From: devans at macports.org (David Evans)
Date: Tue, 18 Nov 2008 10:11:17 -0800
Subject: [MacPorts] #17299: ffmpeg build fails: ld error
	(Undefined	symbol): _dvbsub_decoder while installing gimp2
In-Reply-To: <063.66d629b46ca2422a4b9deb277a00a6f0@macports.org>
References: <054.46ba4501eaad248ce9c7b6fdd3a8da3c@macports.org>
	<063.66d629b46ca2422a4b9deb277a00a6f0@macports.org>
Message-ID: <49230545.9080007@macports.org>

>
> #17299: ffmpeg build fails: ld error (Undefined symbol): _dvbsub_decoder while
> installing gimp2
> ---------------------------------+------------------------------------------
>   Reporter:  hauriege1 at llnl.gov  |       Owner:  acho at macports.org
>       Type:  defect              |      Status:  new              
>   Priority:  Normal              |   Milestone:  Port Bugs        
>  Component:  ports               |     Version:  1.6.0            
> Resolution:                      |    Keywords:  gimp2            
>       Port:  ffmpeg              |  
> ---------------------------------+------------------------------------------
> Changes (by devans at macports.org):
>
>  * cc: acho at macports.org (removed)
>   * owner:  devans at macports.org => acho at macports.org
>
>
> Comment:
>
>  Well, I'm confused now.  This log shows an entirely different problem:
>  {{{
>  gcc-4.0 -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
>  -D_ISOC9X_SOURCE -I.
>  -I"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_multimedia_ffmpeg/work/trunk"
>  -O2 -DHAVE_LRINTF -I/opt/local/include -pipe -force_cpusubtype_ALL -Wno-
>  sign-compare -fomit-frame-pointer -g -Wdeclaration-after-statement -Wall
>  -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls
>  -Wno-pointer-sign -Wcast-qual -Wwrite-strings -O3 -fno-math-errno       -c
>  -o libavcodec/h264.o libavcodec/h264.c
>  In file included from libavcodec/h264.c:31:
>  libavcodec/h264.h:365: error: parse error before 'CABACContext'
>  libavcodec/h264.h:365: warning: no semicolon at end of struct or union
>  }}}
>
>  which again, I do not see here.  The only difference is that I'm on ppc
>  and you're on
>  intel.  This results in additional compile switches in my case to enable
>  altivec and
>  pic but I can't see why that would make a difference.
>
>  I guess it would be helpful if someone with the same configuration as you
>  could
>  confirm or deny the error to rule out something specific to your
>  installation.  In
>  the meantime, you might want to go to the work directory and see if you
>  can understand
>  why this error is being generated.
>  {{{
>  cd
>  /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_multimedia_ffmpeg/work/trunk
>  }}}
>
>  and look at avcodec/h264.h avcodec/h264.c etc.
>
>  Sorry I can't be more help right now.  Will reassign to ffmpeg maintainer.
>
>   
Wonder if someone who has access to a 10.4.11 intel system could look at
this and see if they
can reproduce the reported problem.  Works for me on 10.4.11 ppc.

Dave

From simon at ruderich.org  Tue Nov 18 13:29:33 2008
From: simon at ruderich.org (Simon Ruderich)
Date: Tue, 18 Nov 2008 22:29:33 +0100
Subject: [42257] trunk/dports/devel/git-core/files/patch-Makefile.diff
In-Reply-To: <2E094CBC-EA13-4C66-A079-E71AAB5060C6@gmail.com>
References: <20081117180146.E16B76D86D9@beta.macosforge.org>
	<2E094CBC-EA13-4C66-A079-E71AAB5060C6@gmail.com>
Message-ID: <20081118212933.GA19093@ruderich.org>

On Mon, Nov 17, 2008 at 07:29:50PM +0100, nox wrote:
> Le 17 nov. 08 ? 19:01, simon at macports.org a ?crit :
>
>> ---- Makefile.orig	2008-10-22 11:12:25.000000000 +0200
>> -+++ Makefile	2008-10-22 11:13:23.000000000 +0200
>> +--- Makefile.orig	2008-11-13 19:55:15.000000000 +0100
>> ++++ Makefile	2008-11-13 19:56:36.000000000 +0100
>>  @@ -113,7 +113,7 @@
>>   #
>>   # Define NO_R_TO_GCC_LINKER if your gcc does not like "-R/path/lib"
>> @@ -23,7 +23,7 @@
>>   	# Some gcc does not accept and pass -R to the linker to specify
>>   	# the runtime dynamic library path.
>>  -	CC_LD_DYNPATH = -Wl,-rpath=
>> -+	CC_LD_DYNPATH = -Wl,-rpath,
>> ++	CC_LD_DYNPATH = -L
>>   else
>>   	CC_LD_DYNPATH = -R
>>   endif
>
> Instead of a patch, can't you just do `build.args-append
> CC_LD_DYNPATH=-L`?
>
> Regards,
> Anthony Ramine.

I didn't test this as the patch worked fine for me and others on the ticket.
Feel free to change it if it works.

But I like the patch idea a bit more because it makes clear what we (MacPorts)
changed to get the application to build. If git changed the Makefile we would
immediately know it because the patch fails.

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/20081118/5dac717f/attachment.bin>

From ryandesign at macports.org  Tue Nov 18 15:25:07 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 18 Nov 2008 17:25:07 -0600
Subject: [42296] trunk/dports/databases/db46/Portfile
In-Reply-To: <20081118145520.AABBA6E2573@beta.macosforge.org>
References: <20081118145520.AABBA6E2573@beta.macosforge.org>
Message-ID: <B566D96A-9FE7-4629-BCBD-D762AF641774@macports.org>

On Nov 18, 2008, at 08:55, nottwo at macports.org wrote:

> Revision: 42296
>           http://trac.macports.org/changeset/42296
> Author:   nottwo at macports.org
> Date:     2008-11-18 06:55:20 -0800 (Tue, 18 Nov 2008)
> Log Message:
> -----------
> Add variant that builds db_dump185.  Closes #16301

Why a variant? Is there any detriment to including this in the  
default install?


> Modified Paths:
> --------------
>     trunk/dports/databases/db46/Portfile
>
> Modified: trunk/dports/databases/db46/Portfile
> ===================================================================
> --- trunk/dports/databases/db46/Portfile	2008-11-18 14:51:39 UTC  
> (rev 42295)
> +++ trunk/dports/databases/db46/Portfile	2008-11-18 14:55:20 UTC  
> (rev 42296)
> @@ -51,12 +51,21 @@
>  		move ${destroot}${prefix}/bin/db_${bin} \
>  			${destroot}${prefix}/bin/db46_${bin}
>  	}
> +
> +        if { [ variant_isset dump185 ] } {
> +            move ${destroot}${prefix}/bin/db_dump185 \
> +                ${destroot}${prefix}/bin/db46_dump185
> +        }
>  }
>
>  variant java description {Enable java bindings} {
>  	configure.args-append --enable-java
>  }
>
> +variant dump185 description {Build db_dump185 tool} {
> +        configure.args-append --enable-dump185
> +}
> +
>  livecheck.check regex
>  livecheck.url   http://www.oracle.com/technology/documentation/ 
> berkeley-db/db/ref/changelog/4.6.html
>  livecheck.regex {Berkeley DB (\d+(?:\.\d+)*)}


From ryandesign at macports.org  Tue Nov 18 15:56:00 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 18 Nov 2008 17:56:00 -0600
Subject: [42296] trunk/dports/databases/db46/Portfile
In-Reply-To: <B566D96A-9FE7-4629-BCBD-D762AF641774@macports.org>
References: <20081118145520.AABBA6E2573@beta.macosforge.org>
	<B566D96A-9FE7-4629-BCBD-D762AF641774@macports.org>
Message-ID: <D893113F-D4A9-4D90-AAC0-CC8B2EE021B5@macports.org>


On Nov 18, 2008, at 17:25, Ryan Schmidt wrote:

> On Nov 18, 2008, at 08:55, nottwo at macports.org wrote:
>
>> Revision: 42296
>>           http://trac.macports.org/changeset/42296
>> Author:   nottwo at macports.org
>> Date:     2008-11-18 06:55:20 -0800 (Tue, 18 Nov 2008)
>> Log Message:
>> -----------
>> Add variant that builds db_dump185.  Closes #16301
>
> Why a variant? Is there any detriment to including this in the  
> default install?

Oops, sorry, didn't see Anthony had already asked the same question.



From devans at macports.org  Tue Nov 18 16:57:23 2008
From: devans at macports.org (David Evans)
Date: Tue, 18 Nov 2008 16:57:23 -0800
Subject: Too many  libconfig's
Message-ID: <49236473.40709@macports.org>

I was trying to install ntfsprogs +crypto today and found that it failed
configuration looking for a pkg-config file for libconfig.

We have a port libconfig but it doesn't provide pkg-config files and
definitely isn't the one that ntfsprogs is looking for (completely
different API). 

The homepage for our libconfig is

http://www.rkeene.org/oss/libconfig

Found the libconfig that ntfsprogs is looking for at

http://www.hyperrealm.com/libconfig/


So the question is how to differentiate these two packages:

1) Current libconfig port  is not referenced by any other port based on
grep of the current dports tree. Could replace this one with the new one
but they really are different packages and someone might be using the
current one somewhere.

2) Commit the new libconfig package as libconfig-new or the like
(suggestions welcome) and make ntfsprogs depend upon it.

3) Rename the existing one (libconfig-old) and make the new one libconfig.

4) Something else.

Ideas and suggestions are solicited and appreciated.

By the way, the newer package has both C and C++ interfaces which may be
the story behind this ticket:

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

From ryandesign at macports.org  Tue Nov 18 17:12:39 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 18 Nov 2008 19:12:39 -0600
Subject: Too many  libconfig's
In-Reply-To: <49236473.40709@macports.org>
References: <49236473.40709@macports.org>
Message-ID: <63F98E3E-8F23-47FE-9226-EF0A009A82AE@macports.org>

On Nov 18, 2008, at 18:57, David Evans wrote:

> I was trying to install ntfsprogs +crypto today and found that it  
> failed
> configuration looking for a pkg-config file for libconfig.
>
> We have a port libconfig but it doesn't provide pkg-config files and
> definitely isn't the one that ntfsprogs is looking for (completely
> different API).
>
> The homepage for our libconfig is
>
> http://www.rkeene.org/oss/libconfig
>
> Found the libconfig that ntfsprogs is looking for at
>
> http://www.hyperrealm.com/libconfig/
>
>
> So the question is how to differentiate these two packages:
>
> 1) Current libconfig port  is not referenced by any other port  
> based on
> grep of the current dports tree. Could replace this one with the  
> new one
> but they really are different packages and someone might be using the
> current one somewhere.
>
> 2) Commit the new libconfig package as libconfig-new or the like
> (suggestions welcome) and make ntfsprogs depend upon it.
>
> 3) Rename the existing one (libconfig-old) and make the new one  
> libconfig.
>
> 4) Something else.
>
> Ideas and suggestions are solicited and appreciated.
>
> By the way, the newer package has both C and C++ interfaces which  
> may be
> the story behind this ticket:
>
> http://trac.macports.org/ticket/14035

(3) is problematic because there is no built-in way to rename ports.  
Sure, you can "svn mv" the old port to a different directory, but  
MacPorts doesn't know you did that; any users who have the old port  
installed will think it's the same as the new port since they'll  
share the same name.

You may want to contact the authors of both software packages. Ask if  
there is any relation between the two, if one is meant to replace the  
other, or what. And if not, if they have any suggestions for  
disambiguating the names (this problem won't be unique to MacPorts  
and should ideally be fixed upstream).



From ryandesign at macports.org  Tue Nov 18 17:15:33 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 18 Nov 2008 19:15:33 -0600
Subject: [42293] trunk/dports/perl/p5-json-xs/Portfile
In-Reply-To: <20081118142214.49C8C6E2007@beta.macosforge.org>
References: <20081118142214.49C8C6E2007@beta.macosforge.org>
Message-ID: <BDAB3BE9-4CAD-44E1-A08B-29F24824D22E@macports.org>


On Nov 18, 2008, at 08:22, nottwo at macports.org wrote:

> Revision: 42293
>           http://trac.macports.org/changeset/42293
> Author:   nottwo at macports.org
> Date:     2008-11-18 06:22:12 -0800 (Tue, 18 Nov 2008)
> Log Message:
> -----------
> p5-json-xs: new version
>
> Modified Paths:
> --------------
>     trunk/dports/perl/p5-json-xs/Portfile
>
> Modified: trunk/dports/perl/p5-json-xs/Portfile
> ===================================================================
> --- trunk/dports/perl/p5-json-xs/Portfile	2008-11-18 13:51:44 UTC  
> (rev 42292)
> +++ trunk/dports/perl/p5-json-xs/Portfile	2008-11-18 14:22:12 UTC  
> (rev 42293)
> @@ -3,7 +3,7 @@
>  PortSystem          1.0
>  PortGroup           perl5 1.0
>
> -perl5.setup         JSON-XS 2.2222
> +perl5.setup         JSON-XS 2.23

Don't forget that when you update a version in a way that expects the  
version to be a floating point number instead of a dotted decimal,  
you need to increase the epoch, because we have not yet resolved this  
ticket:

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

I did it for you today:

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



From blb at macports.org  Tue Nov 18 18:57:57 2008
From: blb at macports.org (Bryan Blackburn)
Date: Tue, 18 Nov 2008 19:57:57 -0700
Subject: Too many  libconfig's
In-Reply-To: <63F98E3E-8F23-47FE-9226-EF0A009A82AE@macports.org>
References: <49236473.40709@macports.org>
	<63F98E3E-8F23-47FE-9226-EF0A009A82AE@macports.org>
Message-ID: <20081119025757.GE503@ninagal.withay.com>

On Tue, Nov 18, 2008 at 07:12:39PM -0600, Ryan Schmidt said:
> On Nov 18, 2008, at 18:57, David Evans wrote:
[...]
>>
>> The homepage for our libconfig is
>>
>> http://www.rkeene.org/oss/libconfig
>>
>> Found the libconfig that ntfsprogs is looking for at
>>
>> http://www.hyperrealm.com/libconfig/

There's also

<http://sourceforge.net/projects/libconfig/>

>>
>>
>> So the question is how to differentiate these two packages:
>>
>> 1) Current libconfig port  is not referenced by any other port based on
>> grep of the current dports tree. Could replace this one with the new one
>> but they really are different packages and someone might be using the
>> current one somewhere.

That could be confusing, maybe someone is using it currently.

>>
>> 2) Commit the new libconfig package as libconfig-new or the like
>> (suggestions welcome) and make ntfsprogs depend upon it.

Definitely the way to go, though a better name I think would be
libconfig-cxx (since it has C++ support as well) or libconfig-lgpl since
that's the license it uses.  Or other options maybe?

>>
>> 3) Rename the existing one (libconfig-old) and make the new one  
>> libconfig.
>>
>> 4) Something else.
>>
>> Ideas and suggestions are solicited and appreciated.
>>
>> By the way, the newer package has both C and C++ interfaces which may be
>> the story behind this ticket:
>>
>> http://trac.macports.org/ticket/14035
>
> (3) is problematic because there is no built-in way to rename ports.  
> Sure, you can "svn mv" the old port to a different directory, but  
> MacPorts doesn't know you did that; any users who have the old port  
> installed will think it's the same as the new port since they'll share the 
> same name.
>
> You may want to contact the authors of both software packages. Ask if  
> there is any relation between the two, if one is meant to replace the  
> other, or what. And if not, if they have any suggestions for  
> disambiguating the names (this problem won't be unique to MacPorts and 
> should ideally be fixed upstream).

Unfortunately I think this is just a case where a library is needed and
handles config info, so several different people all came up with
'libconfig'.

Bryan


From blb at macports.org  Tue Nov 18 19:06:59 2008
From: blb at macports.org (Bryan Blackburn)
Date: Tue, 18 Nov 2008 20:06:59 -0700
Subject: [42317] trunk/dports/lang/python26
In-Reply-To: <20081119020508.7CEFD6EC2B2@beta.macosforge.org>
References: <20081119020508.7CEFD6EC2B2@beta.macosforge.org>
Message-ID: <20081119030659.GF503@ninagal.withay.com>

On Tue, Nov 18, 2008 at 06:05:08PM -0800, mcalhoun at macports.org said:
> Revision: 42317
>           http://trac.macports.org/changeset/42317
> Author:   mcalhoun at macports.org
> Date:     2008-11-18 18:05:08 -0800 (Tue, 18 Nov 2008)
> Log Message:
> -----------
> python26: the module binascii requires port:zlib.
> Adding binascii to the disabled_module_list in patch-setup.py.diff
>     would have required several other modules to be added as well.
> Since port:zlib is a dependency anyway, remove zlib module from disabled_module_list.

Will this need to be propagated to other python versions?

Bryan


From ryandesign at macports.org  Tue Nov 18 23:21:01 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 19 Nov 2008 01:21:01 -0600
Subject: [42290] trunk/dports/lang/ghc/Portfile
In-Reply-To: <20081118133238.51CB66E1A2A@beta.macosforge.org>
References: <20081118133238.51CB66E1A2A@beta.macosforge.org>
Message-ID: <D7AC668E-4092-45DA-8CBE-447FEB4BCC5A@macports.org>

On Nov 18, 2008, at 07:32, gwright at macports.org wrote:

> Revision: 42290
>           http://trac.macports.org/changeset/42290
> Author:   gwright at macports.org
> Date:     2008-11-18 05:32:36 -0800 (Tue, 18 Nov 2008)
> Log Message:
> -----------
> Fix a typo in the i386/Tiger build.
>
> Modified Paths:
> --------------
>     trunk/dports/lang/ghc/Portfile
>
> Modified: trunk/dports/lang/ghc/Portfile
> ===================================================================
> --- trunk/dports/lang/ghc/Portfile	2008-11-18 10:51:35 UTC (rev 42289)
> +++ trunk/dports/lang/ghc/Portfile	2008-11-18 13:32:36 UTC (rev 42290)
> @@ -99,7 +99,7 @@
>
>  		distfiles-append	${name}-${ghc_bootversion}-darwin-i386-tiger- 
> bootstrap-rev1.tar.bz2:bootstrap
>
> -		checksums-append	${name}-${ghc_bootversion}-darwin-i386-tiger- 
> bootstrap.tar.bz2 md5 f01663cecefd50b5f1e1f524f49cd6df
> +		checksums-append	${name}-${ghc_bootversion}-darwin-i386-tiger- 
> bootstrapi-rev1.tar.bz2 md5 f01663cecefd50b5f1e1f524f49cd6df

That's still a typo. :)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ghc.diff
Type: application/octet-stream
Size: 614 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20081119/0b4a4ba9/attachment.obj>

From nottwo at macports.org  Wed Nov 19 14:19:58 2008
From: nottwo at macports.org (Trannie Carter)
Date: Wed, 19 Nov 2008 17:19:58 -0500
Subject: [42296] trunk/dports/databases/db46/Portfile
Message-ID: <20081119221957.GA19697@xserve.internal.designvox.com>

On Tue, Nov 18, 2008 at 10:07 AM, nox <n.oxyde at gmail.com> wrote:
>>
>>     +
>>     +        if { [ variant_isset dump185 ] } {
>>     +            move ${destroot}${prefix}/bin/db_dump185 \
>>     +                ${destroot}${prefix}/bin/db46_dump185
>>     +        }
>>      }
>>
>   One question and a little suggestion:
>   Why a variant for this small utility?

You mean as opposed to making it part of the default build?  I agree that it is
a relatively small utility to get its own variant.  The db44 port enabled
db_dump185 by default and mentioned it in the port description.  db46
explicitly dropped that and I assumed there was a reason;  Probably because not
many people use db1.8 anymore :)  But I found an old bdb file I needed access
to, so I added a variant.

I'll start posting to macports-dev when there's ambiguity.  I'm still pretty
new to ports best practices.
 

> Instead of testing whether the variant is set, you could write another
> post-destroot block in the variant itself.

Oh, I'm not familiar with that pattern.  I modeled that section after the
MacPorts Guide section 4.4.2 Variant Actions in a Phase.  Maybe this new style
is described in the trunk version of the guide.

thanks! 

trannie

From raimue at macports.org  Wed Nov 19 15:18:21 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 20 Nov 2008 00:18:21 +0100
Subject: [42296] trunk/dports/databases/db46/Portfile
In-Reply-To: <20081119221957.GA19697@xserve.internal.designvox.com>
References: <20081119221957.GA19697@xserve.internal.designvox.com>
Message-ID: <49249EBD.4080606@macports.org>

Trannie Carter wrote:
>> Instead of testing whether the variant is set, you could write another
>> post-destroot block in the variant itself.
> 
> Oh, I'm not familiar with that pattern.  I modeled that section after the
> MacPorts Guide section 4.4.2 Variant Actions in a Phase.  Maybe this new style
> is described in the trunk version of the guide.

There is only one version of the guide. The description of new features
introduced on trunk only should note that they are not released yet.

Rainer

From n.oxyde at gmail.com  Wed Nov 19 17:06:45 2008
From: n.oxyde at gmail.com (nox)
Date: Thu, 20 Nov 2008 02:06:45 +0100
Subject: [42296] trunk/dports/databases/db46/Portfile
In-Reply-To: <49249EBD.4080606@macports.org>
References: <20081119221957.GA19697@xserve.internal.designvox.com>
	<49249EBD.4080606@macports.org>
Message-ID: <9BDA7C2A-35FD-44FC-B313-3AED24EFFFCA@gmail.com>


Le 20 nov. 08 ? 00:18, Rainer M?ller a ?crit :

> Trannie Carter wrote:
>>> Instead of testing whether the variant is set, you could write  
>>> another
>>> post-destroot block in the variant itself.
>>
>> Oh, I'm not familiar with that pattern.  I modeled that section  
>> after the
>> MacPorts Guide section 4.4.2 Variant Actions in a Phase.  Maybe  
>> this new style
>> is described in the trunk version of the guide.
>
> There is only one version of the guide. The description of new  
> features
> introduced on trunk only should note that they are not released yet.
>
> Rainer

I'm not talking about a new feature:

post-destroot {
     ...
}

variant dump185 {
     configure.args-append   --enable-dump185

     post-destroot {
         move ${destroot}${prefix}/bin/db_dump185 \
             ${destroot}${prefix}/bin/db46_dump185
     }
}

From nox at macports.org  Wed Nov 19 17:09:51 2008
From: nox at macports.org (nox)
Date: Thu, 20 Nov 2008 02:09:51 +0100
Subject: upgrading cyrus-sasl2
In-Reply-To: <4EF2E4C4-3E86-4E6E-8FC1-F6BCDF565461@dxradio.demon.co.uk>
References: <4EF2E4C4-3E86-4E6E-8FC1-F6BCDF565461@dxradio.demon.co.uk>
Message-ID: <86F3C127-6F14-4F78-8F1D-0625FD85CF0D@macports.org>

Le 20 nov. 08 ? 01:44, Mark Hattam a ?crit :

> iMac:~ mark$ sudo port upgrade outdated
> --->  Building cyrus-sasl2 with target all
> Error: cyrus-sasl2 must be deactivated before upgrade.
> Error: Target org.macports.build returned: Please run `sudo port  
> deactivate cyrus-sasl2` and try again.
> Error: Unable to upgrade port: 1
>
> iMac:~ mark$ sudo port deactivate cyrus-sasl2
> --->  Deactivating cyrus-sasl2
>
> iMac:~ mark$ sudo port upgrade outdated
> Can't map the URL 'file://.' to a port description file ("Could not  
> find Portfile in /Users/mark").
> Please verify that the directory and portfile syntax are correct.
> To use the current port, you must be in a port's directory.
> (you might also see this message if a pseudo-port such as
> outdated or installed expands to no ports).
> Error: No port  found.

This looks like a base bug, not a bug in cyrus-sasl2 port itself.

From blb at macports.org  Wed Nov 19 17:17:31 2008
From: blb at macports.org (Bryan Blackburn)
Date: Wed, 19 Nov 2008 18:17:31 -0700
Subject: upgrading cyrus-sasl2
In-Reply-To: <86F3C127-6F14-4F78-8F1D-0625FD85CF0D@macports.org>
References: <4EF2E4C4-3E86-4E6E-8FC1-F6BCDF565461@dxradio.demon.co.uk>
	<86F3C127-6F14-4F78-8F1D-0625FD85CF0D@macports.org>
Message-ID: <20081120011731.GG486@ninagal.withay.com>

On Thu, Nov 20, 2008 at 02:09:51AM +0100, nox said:
> Le 20 nov. 08 ? 01:44, Mark Hattam a ?crit :
>
>> iMac:~ mark$ sudo port upgrade outdated
>> --->  Building cyrus-sasl2 with target all
>> Error: cyrus-sasl2 must be deactivated before upgrade.
>> Error: Target org.macports.build returned: Please run `sudo port  
>> deactivate cyrus-sasl2` and try again.
>> Error: Unable to upgrade port: 1
>>
>> iMac:~ mark$ sudo port deactivate cyrus-sasl2
>> --->  Deactivating cyrus-sasl2
>>
>> iMac:~ mark$ sudo port upgrade outdated
>> Can't map the URL 'file://.' to a port description file ("Could not  
>> find Portfile in /Users/mark").
>> Please verify that the directory and portfile syntax are correct.
>> To use the current port, you must be in a port's directory.
>> (you might also see this message if a pseudo-port such as
>> outdated or installed expands to no ports).
>> Error: No port  found.
>
> This looks like a base bug, not a bug in cyrus-sasl2 port itself.

That's 12288:

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

so much-improved in 1.7.

Though the port in need of an upgrade was still installed just deactivated,
so the big question is whether outdated should pay attention to deactivated
as well?  And I think for cyrus-sasl2, don't you have to completely
uninstall as it'll be reactivated if you try doing an upgrade of it?

Bryan


From ryandesign at macports.org  Wed Nov 19 19:48:56 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 19 Nov 2008 21:48:56 -0600
Subject: [42296] trunk/dports/databases/db46/Portfile
In-Reply-To: <20081119221957.GA19697@xserve.internal.designvox.com>
References: <20081119221957.GA19697@xserve.internal.designvox.com>
Message-ID: <A1FE4997-B047-47FE-8368-905CE290BB6B@macports.org>

On Nov 19, 2008, at 16:19, Trannie Carter wrote:

>>   One question and a little suggestion:
>>   Why a variant for this small utility?
>
> You mean as opposed to making it part of the default build?  I  
> agree that it is
> a relatively small utility to get its own variant.  The db44 port  
> enabled
> db_dump185 by default and mentioned it in the port description.  db46
> explicitly dropped that and I assumed there was a reason;  Probably  
> because not
> many people use db1.8 anymore :)  But I found an old bdb file I  
> needed access
> to, so I added a variant.
>
> I'll start posting to macports-dev when there's ambiguity.  I'm  
> still pretty
> new to ports best practices.

A variant should only be added if there is a really good reason why  
someone would want to not use it. :) For example, a good reason would  
be if the variant adds dependencies which are large or take a long  
time to build, or when there are conflicting options to choose from.  
Like php5 has mysql3, mysql4 and mysql5 variants; you must pick one  
of these if you want MySQL support, but you have to choose the one  
that matches your MySQL version. Also, e.g. mysql5 is a large  
download (27MiB), takes a lot of space after install (41MiB) and  
takes a long time to build (I forget how long at the moment).

You could ask whoever committed the removal of that program from db46  
initially why they did so.


>> Instead of testing whether the variant is set, you could write  
>> another
>> post-destroot block in the variant itself.
>
> Oh, I'm not familiar with that pattern.  I modeled that section  
> after the
> MacPorts Guide section 4.4.2 Variant Actions in a Phase.  Maybe  
> this new style
> is described in the trunk version of the guide.

The guide says [1]:

> If a variant requires options in addition to those provided by  
> keywords using -append and/or -delete, in other words, any actions  
> that would normally take place within a port installation phase, do  
> not try to do this within the variant declaration. Rather, modify  
> the behavior of any affected phases when the variant is invoked  
> using the variant_isset keyword.
>
> post-destroot {
>     xinstall -m 755 -d ${destroot}${prefix}/etc/
>     xinstall ${worksrcpath}/examples/foo.conf \
>         ${destroot}${prefix}/etc/
>
>     if {[variant_isset carbon]} {
>         delete ${destroot}${prefix}/bin/emacs
>         delete ${destroot}${prefix}/bin/emacs-${version}
>     }
> }


I have no idea why it says that. :) There's no reason I can think of  
not to do it within the variant declaration; in fact, I think it's  
preferable to keep all of the variant's dealings together in one  
place (the variant declaration).


[1] http://guide.macports.org/#development.variants.phase


From jmr at macports.org  Wed Nov 19 21:02:06 2008
From: jmr at macports.org (Joshua Root)
Date: Thu, 20 Nov 2008 16:02:06 +1100
Subject: upgrading cyrus-sasl2
In-Reply-To: <20081120011731.GG486@ninagal.withay.com>
References: <4EF2E4C4-3E86-4E6E-8FC1-F6BCDF565461@dxradio.demon.co.uk>	<86F3C127-6F14-4F78-8F1D-0625FD85CF0D@macports.org>
	<20081120011731.GG486@ninagal.withay.com>
Message-ID: <4924EF4E.8080905@macports.org>

Bryan Blackburn wrote:
> That's 12288:
> 
> <http://trac.macports.org/ticket/12288>
> 
> so much-improved in 1.7.
> 
> Though the port in need of an upgrade was still installed just deactivated,
> so the big question is whether outdated should pay attention to deactivated
> as well?  And I think for cyrus-sasl2, don't you have to completely
> uninstall as it'll be reactivated if you try doing an upgrade of it?

If you want to keep the old version around in case of problems, you have
deactivate the old version, and then use `port install` to install the
new version.

I fixed a bug where upgrade would fail to activate the current version
of the port, but I don't understand why it needs to do that in the first
place. Its behaviour is still rather buggy:
<http://trac.macports.org/ticket/16085>

It does need to end up with some version of the port active, however,
because upgrade is recursive and you don't want a dependency to be
installed but not active when you're building. In theory, it should be
possible to rearrange the code to ensure this without causing these
sorts of problems.

- Josh

From jmr at macports.org  Thu Nov 20 09:04:08 2008
From: jmr at macports.org (Joshua Root)
Date: Fri, 21 Nov 2008 04:04:08 +1100
Subject: MacPorts 1.7.1 milestone created
Message-ID: <49259888.6000201@macports.org>

I've created a MacPorts 1.7.1 milestone on Trac. I think we should move
most of the open tickets from the 1.7.0 milestone to 1.7.1, and release
a 1.7.0 beta.

- Josh

From blb at macports.org  Thu Nov 20 13:31:36 2008
From: blb at macports.org (Bryan Blackburn)
Date: Thu, 20 Nov 2008 14:31:36 -0700
Subject: MacPorts 1.7.1 milestone created
In-Reply-To: <49259888.6000201@macports.org>
References: <49259888.6000201@macports.org>
Message-ID: <20081120213136.GD760@ninagal.withay.com>

On Fri, Nov 21, 2008 at 04:04:08AM +1100, Joshua Root said:
> I've created a MacPorts 1.7.1 milestone on Trac. I think we should move
> most of the open tickets from the 1.7.0 milestone to 1.7.1, and release
> a 1.7.0 beta.

13141 [1], if we ship a 1.7.1 dmg, then it makes sense; otherwise we could
even move it to 1.8.0.

15434 [2], I think some decision should be made first on the best choice
first, then decide which version (since one decision is to ship as is with
1.7.0 now).

15868 [3], this makes sense, it's an issue but I don't recall seeing it too
frequently.

16085 [4], it seems the work done so far on it may suggest that fixing it
could be bigger than a couple of lines, so it might be quite a bit of time,
hence it could also be moved to 1.7.1 or even 1.8.0.

14482/14553 definitely are needed for 1.7.0 so port groups can be added in
the future without major releases.

Bryan

[1] - <http://trac.macports.org/ticket/13141>
[2] - <http://trac.macports.org/ticket/15434>
[3] - <http://trac.macports.org/ticket/15868>
[4] - <http://trac.macports.org/ticket/16085>

> 
> - Josh

From ryandesign at macports.org  Thu Nov 20 15:03:02 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 20 Nov 2008 17:03:02 -0600
Subject: [42389] trunk/dports/x11/xinit/Portfile
In-Reply-To: <20081120102938.E8FD46FDBCD@beta.macosforge.org>
References: <20081120102938.E8FD46FDBCD@beta.macosforge.org>
Message-ID: <0E508678-0B43-4AA7-9ECB-306C49695B98@macports.org>


From loshea at gmail.com  Thu Nov 20 17:25:00 2008
From: loshea at gmail.com (Luis O'Shea)
Date: Thu, 20 Nov 2008 20:25:00 -0500
Subject: Port update needs commit
Message-ID: <a87d8aa50811201725x9b58f4ao3464e25f47736440@mail.gmail.com>

Could someone commit my update to the asymptote port?  See Ticket
#13249 (http://trac.macports.org/ticket/13249).  Note that this is a
closed ticket, but I have been using it to attach updates.

Thanks,

Luis

From blb at macports.org  Thu Nov 20 18:16:08 2008
From: blb at macports.org (Bryan Blackburn)
Date: Thu, 20 Nov 2008 19:16:08 -0700
Subject: Port update needs commit
In-Reply-To: <a87d8aa50811201725x9b58f4ao3464e25f47736440@mail.gmail.com>
References: <a87d8aa50811201725x9b58f4ao3464e25f47736440@mail.gmail.com>
Message-ID: <20081121021608.GH760@ninagal.withay.com>

On Thu, Nov 20, 2008 at 08:25:00PM -0500, Luis O'Shea said:
> Could someone commit my update to the asymptote port?  See Ticket
> #13249 (http://trac.macports.org/ticket/13249).  Note that this is a
> closed ticket, but I have been using it to attach updates.

That's probably why it wasn't noticed, just create a new ticket for port
updates.

However, trying 1.51, I get errors on 10.5.5/Intel Xcode 3.1.1:

/usr/bin/g++-4.0 -Wall -ansi -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -DUSEGC
-I/opt/local/include -pipe -O2  -I . -Igc-7.1/include -o drawsurface.o -c
drawsurface.cc
drawsurface.cc: In member function 'virtual void
camp::drawSurface::render(GLUnurbs*, double, const camp::triple&, const
camp::triple&, double, bool)':
drawsurface.cc:260: error: invalid conversion from 'GLvoid (*)(...)' to
'GLvoid (*)()'
drawsurface.cc:260: error:   initializing argument 3 of 'void
gluNurbsCallback(GLUnurbs*, GLenum, GLvoid (*)())'
make: *** [drawsurface.o] Error 1

Bryan


> 
> Thanks,
> 
> Luis

From ryandesign at macports.org  Fri Nov 21 00:15:33 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 21 Nov 2008 02:15:33 -0600
Subject: [42389] trunk/dports/x11/xinit/Portfile
In-Reply-To: <20081120102938.E8FD46FDBCD@beta.macosforge.org>
References: <20081120102938.E8FD46FDBCD@beta.macosforge.org>
Message-ID: <D37D7F6E-7402-4864-AAF3-4F66F73AAD6B@macports.org>

On Nov 20, 2008, at 04:29, jmr at macports.org wrote:

> Revision: 42389
>           http://trac.macports.org/changeset/42389
> Author:   jmr at macports.org
> Date:     2008-11-20 02:29:38 -0800 (Thu, 20 Nov 2008)
> Log Message:
> -----------
> xinit: use x11prefix instead of hardcoding (#16743, maintainer  
> timeout)
>
> Modified Paths:
> --------------
>     trunk/dports/x11/xinit/Portfile
>
> Modified: trunk/dports/x11/xinit/Portfile
> ===================================================================
> --- trunk/dports/x11/xinit/Portfile	2008-11-20 10:27:48 UTC (rev  
> 42388)
> +++ trunk/dports/x11/xinit/Portfile	2008-11-20 10:29:38 UTC (rev  
> 42389)
> @@ -19,7 +19,7 @@
>
>  depends_lib         lib:libX11:xorg-libX11
>
> -configure.env       PKG_CONFIG_PATH=/usr/X11/lib/pkgconfig
> +configure.pkg_config_path ${x11prefix}/lib/pkgconfig

Actually I think you should be able to remove this entirely, since  
pkgconfig searches there by default now.

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



From ryandesign at macports.org  Fri Nov 21 00:21:24 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 21 Nov 2008 02:21:24 -0600
Subject: [42405] trunk/dports/science/freehdl/Portfile
In-Reply-To: <20081121013336.7D5B070B824@beta.macosforge.org>
References: <20081121013336.7D5B070B824@beta.macosforge.org>
Message-ID: <B8622233-35BC-4A94-A307-3D84A6124BD0@macports.org>


On Nov 20, 2008, at 19:33, rowue at macports.org wrote:

> Revision: 42405
>           http://trac.macports.org/changeset/42405
> Author:   rowue at macports.org
> Date:     2008-11-20 17:33:36 -0800 (Thu, 20 Nov 2008)
> Log Message:
> -----------
> Updated to Version 0.0.6,
> changed whitespaces

It would be great if in the future you could do separate commits: one  
for whitespace changes, and one (or more) for functional changes.  
When they're all combined into one commit, it's hard to see by  
looking at the diff what functional changes took place.

> Modified Paths:
> --------------
>     trunk/dports/science/freehdl/Portfile
>
> Modified: trunk/dports/science/freehdl/Portfile
> ===================================================================
> --- trunk/dports/science/freehdl/Portfile	2008-11-21 01:31:07 UTC  
> (rev 42404)
> +++ trunk/dports/science/freehdl/Portfile	2008-11-21 01:33:36 UTC  
> (rev 42405)
> @@ -1,12 +1,16 @@
> +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode:  
> nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
>  # $Id$
> -PortSystem		1.0
> -name			freehdl
> -version			0.0.4
> -categories		science math
> -maintainers		rowue at digitalis.org
> -description		A free VHDL simualtor used for digital simulations by  
> qucs
> -long_description	A project to develop a free, open source, GPL'ed  
> VHDL simulator \
> -			for Linux!
> -homepage		http://www.freehdl.seul.org
> -master_sites		http://seul.org/~enaroska/
> -checksums		freehdl-0.0.4.tar.gz md5 0992a05d61aad6d890a0eb1bc39655e8
> +PortSystem          1.0
> +name                freehdl
> +version             0.0.6
> +categories          science math
> +maintainers         rowue at digitalis.org
> +description         A free VHDL simualtor used for digital  
> simulations by qucs
> +long_description    A project to develop a free, open source,  
> GPL'ed VHDL simulator \
> +                    for Linux!
> +depends_lib         port:pkgconfig
> +homepage            http://www.freehdl.seul.org
> +master_sites        http://freehdl.seul.org/~enaroska/
> +checksums           md5 bd168382c72f9fbd392f89ab2c5fddf8 \
> +                    sha1 3742570543d271823433298ee67d441199ef6fbf \
> +                    rmd160 325b954f3fee88ff14f5e66bd780ea8ae4d8ecb5



From ryandesign at macports.org  Fri Nov 21 00:34:01 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 21 Nov 2008 02:34:01 -0600
Subject: [42413] trunk/dports/devel
In-Reply-To: <20081121060933.19FE870FB1E@beta.macosforge.org>
References: <20081121060933.19FE870FB1E@beta.macosforge.org>
Message-ID: <D4A76A73-91EF-4ABA-8934-F9B047C063FA@macports.org>

On Nov 21, 2008, at 00:09, ricci at macports.org wrote:

> +set distbase        QScintilla-gpl-${version}
> +distfiles           ${distbase}.tar.gz
> +master_sites        http://www.riverbankcomputing.com/static/ 
> Downloads/QScintilla2/
> +
> +checksums           md5     2e112d01988f2e044c43a1e7f5e1dd87 \
> +                    sha1     
> d34ae9907e6221d221c5b5c1324e9b263553d2cb \
> +                    rmd160  de7828d4b965156771034eb622ee9614b2aea9be
> +
> +depends_lib         port:qt4-mac
> +
> +worksrcdir          ${distbase}

Couldn't you use ${distname} instead of making a new variable $ 
{distbase}?

I haven't tried installing the port this way because it depends on  
qt4-mac which takes forever and a half to build, but it does get  
through the checksum phase ok.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: qscintilla-distname.diff
Type: application/octet-stream
Size: 754 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20081121/101ded6f/attachment.obj>

From opendarwin.org at darkart.com  Fri Nov 21 09:19:03 2008
From: opendarwin.org at darkart.com (Eric Hall)
Date: Fri, 21 Nov 2008 17:19:03 +0000
Subject: [42413] trunk/dports/devel
In-Reply-To: <D4A76A73-91EF-4ABA-8934-F9B047C063FA@macports.org>
References: <20081121060933.19FE870FB1E@beta.macosforge.org>
	<D4A76A73-91EF-4ABA-8934-F9B047C063FA@macports.org>
Message-ID: <20081121171903.GR13985@darkart.com>

On Fri, Nov 21, 2008 at 02:34:01AM -0600, Ryan Schmidt wrote:
> On Nov 21, 2008, at 00:09, ricci at macports.org wrote:
> 
> >+set distbase        QScintilla-gpl-${version}
> >+distfiles           ${distbase}.tar.gz
> >+master_sites        http://www.riverbankcomputing.com/static/ 
> >Downloads/QScintilla2/
> >+
> >+checksums           md5     2e112d01988f2e044c43a1e7f5e1dd87 \
> >+                    sha1     
> >d34ae9907e6221d221c5b5c1324e9b263553d2cb \
> >+                    rmd160  de7828d4b965156771034eb622ee9614b2aea9be
> >+
> >+depends_lib         port:qt4-mac
> >+
> >+worksrcdir          ${distbase}
> 
> Couldn't you use ${distname} instead of making a new variable $ 
> {distbase}?

	Yeah, that's better - didn't find it in my quick
(lighting) search for an example that would do what I needed.
Changed to distname in r42442.

> 
> I haven't tried installing the port this way because it depends on  
> qt4-mac which takes forever and a half to build, but it does get  
> through the checksum phase ok.

	Aye, it took a good chunk of the work day for qt4-mac to
build. 
	 As an FYI, I used qt4-mac and qscintilla to build sqliteman,
which appears to launch, open DBs, and look around inside them - 
closing DBs and quitting is a problem, no idea if that's sqliteman
or any of the Qt stuff.



		-eric


From n.oxyde at gmail.com  Fri Nov 21 10:48:05 2008
From: n.oxyde at gmail.com (nox)
Date: Fri, 21 Nov 2008 19:48:05 +0100
Subject: [42457] trunk/dports/aqua/aquaterm/Portfile
In-Reply-To: <20081121183432.36A31719BE8@beta.macosforge.org>
References: <20081121183432.36A31719BE8@beta.macosforge.org>
Message-ID: <6EF6E1D1-7B0E-4D69-A720-DC42D3D9F954@gmail.com>


Le 21 nov. 08 ? 19:34, mcalhoun at macports.org a ?crit :

> Revision42457Authormcalhoun at macports.orgDate2008-11-21 10:34:31  
> -0800 (Fri, 21 Nov 2008)Log Message
> aquaterm: allow universal build
> Modified Paths
> 	? trunk/dports/aqua/aquaterm/Portfile
> Diff
> Modified: trunk/dports/aqua/aquaterm/Portfile (42456 => 42457)
> --- trunk/dports/aqua/aquaterm/Portfile	2008-11-21 17:58:39 UTC (rev  
> 42456)
> +++ trunk/dports/aqua/aquaterm/Portfile	2008-11-21 18:34:31 UTC (rev  
> 42457)
> @@ -44,3 +44,7 @@
>  xcode.destroot.type		mixed
>  xcode.destroot.settings USER_APPS_DIR=${applications_dir} \
>  						FRAMEWORKS_DIR=${frameworks_dir}
> +
> +variant universal {
> +	patchfiles-delete  patch-disable-universal.diff
> +}

The custom variant will have to be removed when 1.7.0 is released.  
trunk/ already sets the correct ARCHS xcodebuild argument when a  
universal build is requested. I haven't committed the variant because  
I forgot this behaviour does not exist in 1.6.0.

We really need to release the 1.7.0 version soon.


From mcalhoun at macports.org  Fri Nov 21 11:01:28 2008
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Fri, 21 Nov 2008 19:01:28 +0000 (UTC)
Subject: [42457] trunk/dports/aqua/aquaterm/Portfile
References: <20081121183432.36A31719BE8@beta.macosforge.org>
	<6EF6E1D1-7B0E-4D69-A720-DC42D3D9F954@gmail.com>
Message-ID: <loom.20081121T185848-982@post.gmane.org>

nox <n.oxyde at ...> writes:


> The custom variant will have to be removed when 1.7.0 is released.

I will make a note of it in the Portfile and hopefully remember to
remove the variant after 1.7.0 is released.





From loshea at gmail.com  Fri Nov 21 12:56:15 2008
From: loshea at gmail.com (Luis O'Shea)
Date: Fri, 21 Nov 2008 15:56:15 -0500
Subject: Port update needs commit
In-Reply-To: <20081121021608.GH760@ninagal.withay.com>
References: <a87d8aa50811201725x9b58f4ao3464e25f47736440@mail.gmail.com>
	<20081121021608.GH760@ninagal.withay.com>
Message-ID: <a87d8aa50811211256s50b62412o75d7bec4f63cd0ef@mail.gmail.com>

> On Thu, Nov 20, 2008 at 08:25:00PM -0500, Luis O'Shea said:
>> Could someone commit my update to the asymptote port?  See Ticket
>> #13249 (http://trac.macports.org/ticket/13249).  Note that this is a
>> closed ticket, but I have been using it to attach updates.
>
> That's probably why it wasn't noticed, just create a new ticket for port
> updates.

Fair enough.  In previous updates to this port I have attached diffs
to the Portfile to the original ticket as requested by another
committer.  See

  http://trac.macports.org/ticket/15936#comment:3

However this time I attached the diff to the wrong ticket.  In future
I'll follow your suggestion.

> However, trying 1.51, I get errors on 10.5.5/Intel Xcode 3.1.1:
>
> /usr/bin/g++-4.0 -Wall -ansi -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -DUSEGC
> -I/opt/local/include -pipe -O2  -I . -Igc-7.1/include -o drawsurface.o -c
> drawsurface.cc
> drawsurface.cc: In member function 'virtual void
> camp::drawSurface::render(GLUnurbs*, double, const camp::triple&, const
> camp::triple&, double, bool)':
> drawsurface.cc:260: error: invalid conversion from 'GLvoid (*)(...)' to
> 'GLvoid (*)()'
> drawsurface.cc:260: error:   initializing argument 3 of 'void
> gluNurbsCallback(GLUnurbs*, GLenum, GLvoid (*)())'
> make: *** [drawsurface.o] Error 1

I am (still) on 10.4 (and don't have access to a 10.5 machine).  I
will consider upgrading.  In the meantime, what is macports policy in
this situation (i.e., we have a port which builds on one version of
the OS but not another)?  Is to wait until it builds on all versions
before committing?

Thanks,

Luis

From blb at macports.org  Fri Nov 21 15:01:15 2008
From: blb at macports.org (Bryan Blackburn)
Date: Fri, 21 Nov 2008 16:01:15 -0700
Subject: Port update needs commit
In-Reply-To: <a87d8aa50811211256s50b62412o75d7bec4f63cd0ef@mail.gmail.com>
References: <a87d8aa50811201725x9b58f4ao3464e25f47736440@mail.gmail.com>
	<20081121021608.GH760@ninagal.withay.com>
	<a87d8aa50811211256s50b62412o75d7bec4f63cd0ef@mail.gmail.com>
Message-ID: <20081121230115.GG538@ninagal.withay.com>

On Fri, Nov 21, 2008 at 03:56:15PM -0500, Luis O'Shea said:
> > On Thu, Nov 20, 2008 at 08:25:00PM -0500, Luis O'Shea said:
> >> Could someone commit my update to the asymptote port?  See Ticket
> >> #13249 (http://trac.macports.org/ticket/13249).  Note that this is a
> >> closed ticket, but I have been using it to attach updates.
> >
> > That's probably why it wasn't noticed, just create a new ticket for port
> > updates.
> 
> Fair enough.  In previous updates to this port I have attached diffs
> to the Portfile to the original ticket as requested by another
> committer.  See
> 
>   http://trac.macports.org/ticket/15936#comment:3

Perhaps Simon was referring to just the bit in your comment about "It might
be useful to factor out the version of the gc lib into its own variable (in
a separate commit)."?  At least I hope so, since the "Port Updates"
milestone in trac is meant for exactly what your new patch does.

> 
> However this time I attached the diff to the wrong ticket.  In future
> I'll follow your suggestion.
> 
> > However, trying 1.51, I get errors on 10.5.5/Intel Xcode 3.1.1:
> >
> > /usr/bin/g++-4.0 -Wall -ansi -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -DUSEGC
> > -I/opt/local/include -pipe -O2  -I . -Igc-7.1/include -o drawsurface.o -c
> > drawsurface.cc
> > drawsurface.cc: In member function 'virtual void
> > camp::drawSurface::render(GLUnurbs*, double, const camp::triple&, const
> > camp::triple&, double, bool)':
> > drawsurface.cc:260: error: invalid conversion from 'GLvoid (*)(...)' to
> > 'GLvoid (*)()'
> > drawsurface.cc:260: error:   initializing argument 3 of 'void
> > gluNurbsCallback(GLUnurbs*, GLenum, GLvoid (*)())'
> > make: *** [drawsurface.o] Error 1
> 
> I am (still) on 10.4 (and don't have access to a 10.5 machine).  I
> will consider upgrading.  In the meantime, what is macports policy in
> this situation (i.e., we have a port which builds on one version of
> the OS but not another)?  Is to wait until it builds on all versions
> before committing?

If something is definitely known to not work on a given platform, and would
require extensive work to fix, then you can error out as necessary.  For
example, some ports work on 10.5 only (Lingon, Smultron, and others).

Note that the current version, 1.46, builds fine here, and my personal
policy is that I won't commit something if I can't at least verify it succeeds
through the destroot phase.  It would appear this issue has been fixed at
least in svn though:

<https://sourceforge.net/tracker2/?func=detail&aid=2262140&group_id=120000&atid=685683>

If the patch can be found, we could always apply it to 1.51, or wait until
1.52.

Bryan


> 
> Thanks,
> 
> Luis

From ryandesign at macports.org  Fri Nov 21 15:01:52 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 21 Nov 2008 17:01:52 -0600
Subject: [42442] trunk/dports/devel/qscintilla/Portfile
In-Reply-To: <20081121171540.DA4567186A4@beta.macosforge.org>
References: <20081121171540.DA4567186A4@beta.macosforge.org>
Message-ID: <2E5699E6-C6CF-4791-857A-42063CABE741@macports.org>

On Nov 21, 2008, at 11:15, ricci at macports.org wrote:

> Revision: 42442
>           http://trac.macports.org/changeset/42442
> Author:   ricci at macports.org
> Date:     2008-11-21 09:15:40 -0800 (Fri, 21 Nov 2008)
> Log Message:
> -----------
> use distname instead of 'distbase'
>
> Modified Paths:
> --------------
>     trunk/dports/devel/qscintilla/Portfile
>
> Modified: trunk/dports/devel/qscintilla/Portfile
> ===================================================================
> --- trunk/dports/devel/qscintilla/Portfile	2008-11-21 16:52:01 UTC  
> (rev 42441)
> +++ trunk/dports/devel/qscintilla/Portfile	2008-11-21 17:15:40 UTC  
> (rev 42442)
> @@ -22,8 +22,8 @@
>  	bold and italics, multiple foreground and background colours and	\
>  	multiple fonts.
>
> -set distbase        QScintilla-gpl-${version}
> -distfiles           ${distbase}.tar.gz
> +distname            QScintilla-gpl-${version}
> +distfiles           ${distname}.tar.gz
>  master_sites        http://www.riverbankcomputing.com/static/ 
> Downloads/QScintilla2/
>
>  checksums           md5     2e112d01988f2e044c43a1e7f5e1dd87 \
> @@ -32,7 +32,7 @@
>
>  depends_lib         port:qt4-mac
>
> -worksrcdir          ${distbase}
> +worksrcdir          ${distname}

But FYI, as I showed in my patch, you don't need to set distfiles to $ 
{distname}.tar.gz or worksrcdir to ${distname}; those are already the  
defaults.


From ryandesign at macports.org  Fri Nov 21 15:10:29 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 21 Nov 2008 17:10:29 -0600
Subject: [42458] trunk/dports/lang/sbcl/Portfile
In-Reply-To: <20081121184217.4D7C2719CB4@beta.macosforge.org>
References: <20081121184217.4D7C2719CB4@beta.macosforge.org>
Message-ID: <9CAED882-CE8F-4757-B3A1-DE5E14E44706@macports.org>

On Nov 21, 2008, at 12:42, gwright at macports.org wrote:

> Revision: 42458
>           http://trac.macports.org/changeset/42458
> Author:   gwright at macports.org
> Date:     2008-11-21 10:42:16 -0800 (Fri, 21 Nov 2008)
> Log Message:
> -----------
> Build html documentation.
>
> Modified Paths:
> --------------
>     trunk/dports/lang/sbcl/Portfile
>
> Modified: trunk/dports/lang/sbcl/Portfile
> ===================================================================
> --- trunk/dports/lang/sbcl/Portfile	2008-11-21 18:34:31 UTC (rev  
> 42457)
> +++ trunk/dports/lang/sbcl/Portfile	2008-11-21 18:42:16 UTC (rev  
> 42458)
> @@ -78,8 +78,16 @@
>  	system "unset LD_PREBIND && unset LD_PREBIND_ALLOW_OVERLAP && sh  
> make.sh ${host_lisp}"
>  }
>
> -default_variants	+test
> +post-build {
> +	if {[variant_isset html]} {
> +		system "cd ${worksrcpath}/doc; INSTALL_ROOT=${destroot}${prefix}  
> sh ${worksrcpath}/doc/make-doc.sh"
> +	}
> +}
>
> +default_variants	+test +html
> +
> +variant html description {Builds the SBCL and ASDF documentation  
> as HTML} {}

Why make this a variant? Unless it takes terribly long to build, I'd  
do it always.


From ryandesign at macports.org  Fri Nov 21 15:13:27 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 21 Nov 2008 17:13:27 -0600
Subject: [42463] trunk/dports/x11/xorg-applewmproto/Portfile
In-Reply-To: <20081121193749.56C6571A67E@beta.macosforge.org>
References: <20081121193749.56C6571A67E@beta.macosforge.org>
Message-ID: <5F81BF5B-C6AF-4DC4-8425-FADE3DAEFD51@macports.org>

On Nov 21, 2008, at 13:37, jeremyhu at macports.org wrote:

> Revision: 42463
>           http://trac.macports.org/changeset/42463
> Author:   jeremyhu at macports.org
> Date:     2008-11-21 11:37:48 -0800 (Fri, 21 Nov 2008)
> Log Message:
> -----------
> Bump version of xorg-applewmproto to 1.1.1
>
> Modified Paths:
> --------------
>     trunk/dports/x11/xorg-applewmproto/Portfile
>
> Modified: trunk/dports/x11/xorg-applewmproto/Portfile
> ===================================================================
> --- trunk/dports/x11/xorg-applewmproto/Portfile	2008-11-21 19:08:14  
> UTC (rev 42462)
> +++ trunk/dports/x11/xorg-applewmproto/Portfile	2008-11-21 19:37:48  
> UTC (rev 42463)
> @@ -2,9 +2,9 @@
>  PortSystem 1.0
>
>  name		xorg-applewmproto
> -version		1.0.3
> +version		1.1.1
>  categories	x11 devel
> -maintainers	bbyer at macports.org
> +maintainers	jeremyhu at macports.org

Ben is ok with you taking over these ports?


From jeremyhu at macports.org  Fri Nov 21 15:18:07 2008
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Fri, 21 Nov 2008 15:18:07 -0800
Subject: [42463] trunk/dports/x11/xorg-applewmproto/Portfile
In-Reply-To: <5F81BF5B-C6AF-4DC4-8425-FADE3DAEFD51@macports.org>
References: <20081121193749.56C6571A67E@beta.macosforge.org>
	<5F81BF5B-C6AF-4DC4-8425-FADE3DAEFD51@macports.org>
Message-ID: <70E3AB97-0C98-495B-9A96-34BA9DE2D51D@macports.org>

Yeah, he wanted me to months ago... so now he's getting his wish ;)

On Nov 21, 2008, at 15:13, Ryan Schmidt wrote:

> On Nov 21, 2008, at 13:37, jeremyhu at macports.org wrote:
>
>> Revision: 42463
>>          http://trac.macports.org/changeset/42463
>> Author:   jeremyhu at macports.org
>> Date:     2008-11-21 11:37:48 -0800 (Fri, 21 Nov 2008)
>> Log Message:
>> -----------
>> Bump version of xorg-applewmproto to 1.1.1
>>
>> Modified Paths:
>> --------------
>>    trunk/dports/x11/xorg-applewmproto/Portfile
>>
>> Modified: trunk/dports/x11/xorg-applewmproto/Portfile
>> ===================================================================
>> --- trunk/dports/x11/xorg-applewmproto/Portfile	2008-11-21 19:08:14  
>> UTC (rev 42462)
>> +++ trunk/dports/x11/xorg-applewmproto/Portfile	2008-11-21 19:37:48  
>> UTC (rev 42463)
>> @@ -2,9 +2,9 @@
>> PortSystem 1.0
>>
>> name		xorg-applewmproto
>> -version		1.0.3
>> +version		1.1.1
>> categories	x11 devel
>> -maintainers	bbyer at macports.org
>> +maintainers	jeremyhu at macports.org
>
> Ben is ok with you taking over these ports?
>


From simon at ruderich.org  Sat Nov 22 05:44:27 2008
From: simon at ruderich.org (Simon Ruderich)
Date: Sat, 22 Nov 2008 14:44:27 +0100
Subject: Port update needs commit
In-Reply-To: <20081121230115.GG538@ninagal.withay.com>
References: <a87d8aa50811201725x9b58f4ao3464e25f47736440@mail.gmail.com>
	<20081121021608.GH760@ninagal.withay.com>
	<a87d8aa50811211256s50b62412o75d7bec4f63cd0ef@mail.gmail.com>
	<20081121230115.GG538@ninagal.withay.com>
Message-ID: <20081122134427.GA23221@ruderich.org>

On Fri, Nov 21, 2008 at 04:01:15PM -0700, Bryan Blackburn wrote:
> Perhaps Simon was referring to just the bit in your comment about "It might
> be useful to factor out the version of the gc lib into its own variable (in
> a separate commit)."?  At least I hope so, since the "Port Updates"
> milestone in trac is meant for exactly what your new patch does.

Yes, I was referring to this sentence.

> Note that the current version, 1.46, builds fine here, and my personal
> policy is that I won't commit something if I can't at least verify it
> succeeds through the destroot phase.  It would appear this issue has been
> fixed at least in svn though:
>
> <https://sourceforge.net/tracker2/?func=detail&aid=2262140&group_id=120000&atid=685683>
>
> If the patch can be found, we could always apply it to 1.51, or wait until
> 1.52.
>
> Bryan

I tried to extract the patch from SVN and attached it to this mail. It builds
fine for me on 10.4 but could you please test if it works on Leopard?

Thanks,
Simon
-- 
+ privacy is necessary
+ using http://gnupg.org
+ public key id: 0x6115F804EFB33229
-------------- next part --------------
--- a/dports/graphics/asymptote/Portfile
+++ b/dports/graphics/asymptote/Portfile
@@ -34,6 +34,9 @@ post-extract {
   file copy ${distpath}/gc-7.1.tar.gz ${worksrcpath}
 }
 
+# Already fixed upstream, can be removed after next version.
+patchfiles-append patch-leopard.diff
+
 post-activate {
   # run `mktexlsr` to make sure the asymptote files are found:
   system "mktexlsr"
--- /dev/null
+++ b/dports/graphics/asymptote/files/patch-leopard.diff
@@ -0,0 +1,34 @@
+--- glrender.h	2008-11-22 14:08:09.000000000 +0100
++++ glrender.h	2008-11-22 14:15:34.000000000 +0100
+@@ -15,8 +15,12 @@
+ #include <OpenGL/glext.h>
+ #include <OpenGL/glu.h>
+ #include <GLUT/glut.h>
++#ifdef GLU_TESS_CALLBACK_TRIPLEDOT
+ typedef GLvoid (* _GLUfuncptr)(...);
+ #else
++typedef GLvoid (* _GLUfuncptr)();
++#endif
++#else
+ #include <GL/gl.h>
+ #include <GL/glext.h>
+ #include <GL/glu.h>
+--- configure.ac	2008/11/18 17:46:00	3757
++++ configure.ac	2008/11/18 20:46:51	3758
+@@ -213,6 +213,16 @@
+      darwin*) AC_CHECK_HEADER(GLUT/glut.h,
+                                 [AC_DEFINE(HAVE_LIBGLUT, 1,
+ 		   [Define if you have the `glut' library (-lglut).])
++AC_COMPILE_IFELSE(AC_LANG_PROGRAM([
++#include <OpenGL/gl.h>
++#include <OpenGL/glu.h>
++#ifndef GLU_TESS_CALLBACK_TRIPLEDOT
++typedef GLvoid (* _GLUfuncptr)(...);
++void f(void) {
++  gluNurbsCallback(gluNewNurbsRenderer(),GLU_NURBS_BEGIN,(_GLUfuncptr) glBegin);
++}
++#endif
++]),[AC_DEFINE(GLU_TESS_CALLBACK_TRIPLEDOT, 1, [Define if gluNurbsCallback expects a variadic function.])])
+ 			   LIBS=$LIBS"-framework GLUT -framework OpenGL -framework Cocoa"],
+ 				 AC_MSG_NOTICE([*** Could not find glut: will compile without OpenGL support ***]));;
+      *) AC_CHECK_LIB([glut], [glutMainLoop],,
-------------- 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/20081122/79cb7a89/attachment.bin>

From frstan at bellsouth.net  Sat Nov 22 08:49:27 2008
From: frstan at bellsouth.net (William Davis)
Date: Sat, 22 Nov 2008 11:49:27 -0500
Subject: Macports Installation instructions
Message-ID: <2FFA3806-FFEB-4C4C-9FDA-08197D6892A0@bellsouth.net>

re: http://trac.macports.org/wiki/InstallingMacPorts

I know told our former Release Engineer that the directions given on  
this page concerning setting the DISPLAY env value were incorrect for  
Mac OS 10.5 and later.  He wrote me that he had updated this. I just  
reviewed the page and note that it still omits mention that setting  
$DISPLAY=:0 is incorrect for OS 10.5.

Was this somehow changed back or what? Ill post this as a trac ticket  
shortly


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

Mundus vult decepi, ego non


From frstan at bellsouth.net  Sat Nov 22 08:55:28 2008
From: frstan at bellsouth.net (William Davis)
Date: Sat, 22 Nov 2008 11:55:28 -0500
Subject: Macports Installation instructions
In-Reply-To: <2FFA3806-FFEB-4C4C-9FDA-08197D6892A0@bellsouth.net>
References: <2FFA3806-FFEB-4C4C-9FDA-08197D6892A0@bellsouth.net>
Message-ID: <7FD2C836-E1FB-4D35-92CD-2BF21AF746FF@bellsouth.net>


On Nov 22, 2008, at 11:49 AM, William Davis wrote:

> re: http://trac.macports.org/wiki/InstallingMacPorts
>
> I know told our former Release Engineer that the directions given on  
> this page concerning setting the DISPLAY env value were incorrect  
> for Mac OS 10.5 and later.  He wrote me that he had updated this. I  
> just reviewed the page and note that it still omits mention that  
> setting $DISPLAY=:0 is incorrect for OS 10.5.
>
> Was this somehow changed back or what? Ill post this as a trac  
> ticket shortly
>
>
> William Davis

made trak ticket Ticket #17359 (new defect)



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

Mundus vult decepi, ego non

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20081122/41c19e7b/attachment.html>

From blb at macports.org  Sat Nov 22 13:35:08 2008
From: blb at macports.org (Bryan Blackburn)
Date: Sat, 22 Nov 2008 14:35:08 -0700
Subject: Port update needs commit
In-Reply-To: <20081122134427.GA23221@ruderich.org>
References: <a87d8aa50811201725x9b58f4ao3464e25f47736440@mail.gmail.com>
	<20081121021608.GH760@ninagal.withay.com>
	<a87d8aa50811211256s50b62412o75d7bec4f63cd0ef@mail.gmail.com>
	<20081121230115.GG538@ninagal.withay.com>
	<20081122134427.GA23221@ruderich.org>
Message-ID: <20081122213508.GD471@ninagal.withay.com>

On Sat, Nov 22, 2008 at 02:44:27PM +0100, Simon Ruderich said:
[...]
> 
> I tried to extract the patch from SVN and attached it to this mail. It builds
> fine for me on 10.4 but could you please test if it works on Leopard?

Nice, builds fine on 10.5.5 now.  If Luis is okay with it, either Simon or I
can commit the update.

Bryan


> 
> Thanks,
> Simon
> -- 
> + privacy is necessary
> + using http://gnupg.org
> + public key id: 0x6115F804EFB33229

From perry at whatisinaname.org  Sat Nov 22 14:39:08 2008
From: perry at whatisinaname.org (Perry Lee)
Date: Sat, 22 Nov 2008 14:39:08 -0800
Subject: Question regarding new Python ports and PortGroup
Message-ID: <49288A0C.7040604@whatisinaname.org>

For new Python ports, what should the PortGroup be set to?  I recently
noticed the warning message "Warning: This portgroup is deprecated and
will be removed in a future version!" while running a portindex.

Thanks,

Perry

From ryandesign at macports.org  Sat Nov 22 14:48:34 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 22 Nov 2008 16:48:34 -0600
Subject: Question regarding new Python ports and PortGroup
In-Reply-To: <49288A0C.7040604@whatisinaname.org>
References: <49288A0C.7040604@whatisinaname.org>
Message-ID: <7EB9FB2C-E27D-416C-9EE7-75F8A9E33E20@macports.org>


On Nov 22, 2008, at 16:39, Perry Lee wrote:

> For new Python ports, what should the PortGroup be set to?  I recently
> noticed the warning message "Warning: This portgroup is deprecated and
> will be removed in a future version!" while running a portindex.

Which PortGroup did you use?

Note there's currently this idea to consolidate the Python PortGroups:

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



From perry at whatisinaname.org  Sat Nov 22 15:13:13 2008
From: perry at whatisinaname.org (Perry Lee)
Date: Sat, 22 Nov 2008 15:13:13 -0800
Subject: Question regarding new Python ports and PortGroup
In-Reply-To: <7EB9FB2C-E27D-416C-9EE7-75F8A9E33E20@macports.org>
References: <49288A0C.7040604@whatisinaname.org>
	<7EB9FB2C-E27D-416C-9EE7-75F8A9E33E20@macports.org>
Message-ID: <49289209.4020601@whatisinaname.org>

Ryan Schmidt wrote:
> Which PortGroup did you use?

I tried python and python24.  At the time, I thought both groups were
returning the warning message, but it looks I was wrong about the latter
(I just tried it again).  Sorry, my bad.

> Note there's currently this idea to consolidate the Python PortGroups:
> http://trac.macports.org/ticket/16723

Thanks, since this new PortGroup isn't slated for 1.7.0, I take it that
it's still okay to file a Port Submission for a port that uses the
python24 group?

Perry

From ryandesign at macports.org  Sat Nov 22 15:17:00 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 22 Nov 2008 17:17:00 -0600
Subject: Question regarding new Python ports and PortGroup
In-Reply-To: <49289209.4020601@whatisinaname.org>
References: <49288A0C.7040604@whatisinaname.org>
	<7EB9FB2C-E27D-416C-9EE7-75F8A9E33E20@macports.org>
	<49289209.4020601@whatisinaname.org>
Message-ID: <9A6EB85A-E4F7-4CF1-98E5-8C45CDBC9A0B@macports.org>

On Nov 22, 2008, at 17:13, Perry Lee wrote:

> Ryan Schmidt wrote:
>
>> Which PortGroup did you use?
>
> I tried python and python24.  At the time, I thought both groups were
> returning the warning message, but it looks I was wrong about the  
> latter
> (I just tried it again).  Sorry, my bad.
>
>> Note there's currently this idea to consolidate the Python  
>> PortGroups:
>> http://trac.macports.org/ticket/16723
>
> Thanks, since this new PortGroup isn't slated for 1.7.0, I take it  
> that
> it's still okay to file a Port Submission for a port that uses the
> python24 group?

Sure! I think the hope was just that before we start duplicating all  
the py- and py25- ports into py26- versions, we make a plan for  
unifying them instead.


From blb at macports.org  Sat Nov 22 16:50:53 2008
From: blb at macports.org (Bryan Blackburn)
Date: Sat, 22 Nov 2008 17:50:53 -0700
Subject: Port update needs commit
In-Reply-To: <61772881-A355-4509-A93E-74F8EB04ED13@gmail.com>
References: <a87d8aa50811201725x9b58f4ao3464e25f47736440@mail.gmail.com>
	<20081121021608.GH760@ninagal.withay.com>
	<a87d8aa50811211256s50b62412o75d7bec4f63cd0ef@mail.gmail.com>
	<20081121230115.GG538@ninagal.withay.com>
	<20081122134427.GA23221@ruderich.org>
	<20081122213508.GD471@ninagal.withay.com>
	<61772881-A355-4509-A93E-74F8EB04ED13@gmail.com>
Message-ID: <20081123005053.GH471@ninagal.withay.com>

On Sat, Nov 22, 2008 at 04:54:06PM -0500, Luis O'Shea said:
> On Nov 22, 2008, at 4:35 PM, Bryan Blackburn wrote:
>
>> On Sat, Nov 22, 2008 at 02:44:27PM +0100, Simon Ruderich said:
>> [...]
>>>
>>> I tried to extract the patch from SVN and attached it to this mail. It 
>>> builds
>>> fine for me on 10.4 but could you please test if it works on Leopard?
>>
>> Nice, builds fine on 10.5.5 now.  If Luis is okay with it, either Simon 
>> or I
>> can commit the update.
>
> Great.  Thanks Bryan, Simon.  Please commit.

Updated in r42507.  And don't forget to use reply-all to make sure your
email makes it back to the list.

Bryan

>
> Luis

From jeremyhu at macports.org  Sat Nov 22 21:00:53 2008
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Sat, 22 Nov 2008 21:00:53 -0800
Subject: X11 in Macports
Message-ID: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>

For those of you who don't know me, I took over development of X11 in  
OSX when Ben Byer moved on to bigger and better things at the  
beginning of 2009.  I've been poke, prodded, nudged, and otherwise  
motivated into trying to "fix the X11 problem in Macports" as well...  
so I figured I'd make some proper introductions, and offer some  
suggestions to see what everyone's thoughts are on the subject before  
I start changing things only to have 100 people lash out at me for  
"breaking" something... so here goes...

1) The dependency issue

X11 lives in a grey area in Macports' dependency policy.  X11 is  
actually given as the example for something that is appropriate to use  
the lib:* or bin:* dependency rather than a port:* dependency, yet  
there are plenty of ports that are still using a port: dependency.  I  
believe this is mainly for things like libXrender (rather than libX11)  
as a legacy of what was available in Tiger's X11.  I'd very much like  
to use anything in /usr/X11/* over installing a duplicate in /opt/ 
local, and I'm sure others are in the same boat.  I have seen a fair  
share of bug reports on xquartz-dev that came about simply because the  
macports version didn't have a fix that was in the system version or  
macports config files (eg: for fontconfig) didn't match system  
configurations, so users were wondering why some fonts weren't  
available in some programs.

I intend to go through all the x11 related ports and update  
dependencies to be lib: or bin: where appropriate instead of port: (if  
a port is not nomaintainer or openmaintainer, I will file a bug in  
trac to be on the safe side... unless general consensus here is that  
such reports would be overkill and I should just do it myself)

2) The other dependency issue

Now, for what port to actually depend on... Quickly grepping though  
the code, I have seen the following dependencies for libX11:

lib:libX11.6:XFree86
lib:libX11.6:xorg
lib:libX11:XFree86
lib:libX11:xorg
lib:libX11:xorg-libX11

I'd like to standardize this to be xorg-libX11

3) The old monolith xorg and XFree86

I'd like to eventually punt these in favor of having just one X11  
solution in Macports based on the latest release.



Thoughts?

From jeremyhu at macports.org  Sat Nov 22 21:09:27 2008
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Sat, 22 Nov 2008 21:09:27 -0800
Subject: X11 in Macports
In-Reply-To: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
Message-ID: <6B57E5F8-CB28-4A96-A09A-205A431B6536@macports.org>

Oh and one more issue I just remembered... I've seen quite a few ports  
do:

prefix ${x11prefix}

This seems to be a clear violation of the "nothing in /usr" policy...  
and as someone who feels some amount of ownership of /usr/X11, I don't  
want to see it get potentially thrashed...

Am I correct in assuming that this is flat out wrong and should be  
reverted back to installing into the macports dstroot?  Or was there  
some reason for doing this that I'm not seeing?


On Nov 22, 2008, at 21:00, Jeremy Huddleston wrote:

> For those of you who don't know me, I took over development of X11  
> in OSX when Ben Byer moved on to bigger and better things at the  
> beginning of 2009.  I've been poke, prodded, nudged, and otherwise  
> motivated into trying to "fix the X11 problem in Macports" as  
> well... so I figured I'd make some proper introductions, and offer  
> some suggestions to see what everyone's thoughts are on the subject  
> before I start changing things only to have 100 people lash out at  
> me for "breaking" something... so here goes...
>
> 1) The dependency issue
>
> X11 lives in a grey area in Macports' dependency policy.  X11 is  
> actually given as the example for something that is appropriate to  
> use the lib:* or bin:* dependency rather than a port:* dependency,  
> yet there are plenty of ports that are still using a port:  
> dependency.  I believe this is mainly for things like libXrender  
> (rather than libX11) as a legacy of what was available in Tiger's  
> X11.  I'd very much like to use anything in /usr/X11/* over  
> installing a duplicate in /opt/local, and I'm sure others are in the  
> same boat.  I have seen a fair share of bug reports on xquartz-dev  
> that came about simply because the macports version didn't have a  
> fix that was in the system version or macports config files (eg: for  
> fontconfig) didn't match system configurations, so users were  
> wondering why some fonts weren't available in some programs.
>
> I intend to go through all the x11 related ports and update  
> dependencies to be lib: or bin: where appropriate instead of port:  
> (if a port is not nomaintainer or openmaintainer, I will file a bug  
> in trac to be on the safe side... unless general consensus here is  
> that such reports would be overkill and I should just do it myself)
>
> 2) The other dependency issue
>
> Now, for what port to actually depend on... Quickly grepping though  
> the code, I have seen the following dependencies for libX11:
>
> lib:libX11.6:XFree86
> lib:libX11.6:xorg
> lib:libX11:XFree86
> lib:libX11:xorg
> lib:libX11:xorg-libX11
>
> I'd like to standardize this to be xorg-libX11
>
> 3) The old monolith xorg and XFree86
>
> I'd like to eventually punt these in favor of having just one X11  
> solution in Macports based on the latest release.
>
>
>
> Thoughts?
> _______________________________________________
> 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 Nov 22 21:26:15 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 22 Nov 2008 23:26:15 -0600
Subject: X11 in Macports
In-Reply-To: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
Message-ID: <99BE27F0-C48D-4E62-8D8C-B625438AAF73@macports.org>


On Nov 22, 2008, at 23:00, Jeremy Huddleston wrote:

> For those of you who don't know me, I took over development of X11  
> in OSX when Ben Byer moved on to bigger and better things at the  
> beginning of 2009.

Shhhh! I thought people weren't supposed to know you have a time  
machine. :)


> I've been poke, prodded, nudged, and otherwise motivated into  
> trying to "fix the X11 problem in Macports" as well... so I figured  
> I'd make some proper introductions, and offer some suggestions to  
> see what everyone's thoughts are on the subject before I start  
> changing things only to have 100 people lash out at me for  
> "breaking" something... so here goes...
>
> 1) The dependency issue
>
> X11 lives in a grey area in Macports' dependency policy.  X11 is  
> actually given as the example for something that is appropriate to  
> use the lib:* or bin:* dependency rather than a port:* dependency,  
> yet there are plenty of ports that are still using a port:  
> dependency.  I believe this is mainly for things like libXrender  
> (rather than libX11) as a legacy of what was available in Tiger's  
> X11.  I'd very much like to use anything in /usr/X11/* over  
> installing a duplicate in /opt/local, and I'm sure others are in  
> the same boat.  I have seen a fair share of bug reports on xquartz- 
> dev that came about simply because the macports version didn't have  
> a fix that was in the system version or macports config files (eg:  
> for fontconfig) didn't match system configurations, so users were  
> wondering why some fonts weren't available in some programs.
>
> I intend to go through all the x11 related ports and update  
> dependencies to be lib: or bin: where appropriate instead of port:  
> (if a port is not nomaintainer or openmaintainer, I will file a bug  
> in trac to be on the safe side... unless general consensus here is  
> that such reports would be overkill and I should just do it myself)
>
> 2) The other dependency issue
>
> Now, for what port to actually depend on... Quickly grepping though  
> the code, I have seen the following dependencies for libX11:
>
> lib:libX11.6:XFree86
> lib:libX11.6:xorg
> lib:libX11:XFree86
> lib:libX11:xorg
> lib:libX11:xorg-libX11
>
> I'd like to standardize this to be xorg-libX11

We did have consensus and standardization: everything that needed X11  
declared a dependency on "lib:libX11.6:XFree86". Then some people  
started changing some ports to "lib:libX11.6:xorg" for an unknown  
reason.

As I understand it, the reason we have a policy exception to allow  
Apple X11 to be used instead of XFree86 or xorg in MacPorts is that  
Apple X11 integrates nicely with Mac OS X. I've never used xorg in  
MacPorts, but I tried installing XFree86 some time ago and when it  
launched, it had a weird cursor, weird window behavior, it launched 5  
weird-shaped and weird-colored terminal windows I couldn't figure out  
how to deal with, and it was just a very off-putting experience. I  
figured I didn't know what I was doing, uninstalled it, and returned  
to Apple X11 which always worked great.

My initial impression is that we shouldn't have a policy exception  
for everything Leopard's X11 provides, however. fontconfig, xrender,  
etc. are surely newer in MacPorts than they are in Tiger, and we  
still support Tiger, and some people even still use MacPorts on  
Panther. If there are things in Leopard's X11 that are newer than  
what we have in MacPorts, then let's update what we have in MacPorts.  
If a MacPorts port configuration (you say fontconfig?) doesn't  
integrate well with the OS, then let's fix that port.


> 3) The old monolith xorg and XFree86
>
> I'd like to eventually punt these in favor of having just one X11  
> solution in Macports based on the latest release.

I have no problem with changing the recommended non-Apple X11 from  
XFree8 to xorg for example. (I understand that Apple's X11 switched  
from being based on XFree86 to being based on xorg, and that would be  
a fine reason to also prefer xorg as the fallback in MacPorts.) If  
that's decided, then it should be done in all ports at once.  
Otherwise people are left wondering why some ports depend on one X  
implementation and others on another.

As long as both projects continue to exist and function on current  
OSes, there's no reason to delete one or the other, however, is  
there? Choice is a good thing, and we certainly have other cases of  
duplicate functionality in ports.



From ryandesign at macports.org  Sat Nov 22 21:27:30 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 22 Nov 2008 23:27:30 -0600
Subject: X11 in Macports
In-Reply-To: <6B57E5F8-CB28-4A96-A09A-205A431B6536@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
	<6B57E5F8-CB28-4A96-A09A-205A431B6536@macports.org>
Message-ID: <9E493544-2258-4A13-82B9-C02E9E42EBD2@macports.org>

On Nov 22, 2008, at 23:09, Jeremy Huddleston wrote:

> Oh and one more issue I just remembered... I've seen quite a few  
> ports do:
>
> prefix ${x11prefix}
>
> This seems to be a clear violation of the "nothing in /usr"  
> policy... and as someone who feels some amount of ownership of /usr/ 
> X11, I don't want to see it get potentially thrashed...
>
> Am I correct in assuming that this is flat out wrong and should be  
> reverted back to installing into the macports dstroot?  Or was  
> there some reason for doing this that I'm not seeing?

I had assumed that the ports that installed into ${x11prefix} had  
some need to do so. I had not actually tried to use any of that  
software. If it works fine in ${prefix} then absolutely it should go  
there instead.



From jmr at macports.org  Sat Nov 22 22:54:05 2008
From: jmr at macports.org (Joshua Root)
Date: Sun, 23 Nov 2008 17:54:05 +1100
Subject: X11 in Macports
In-Reply-To: <9E493544-2258-4A13-82B9-C02E9E42EBD2@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>	<6B57E5F8-CB28-4A96-A09A-205A431B6536@macports.org>
	<9E493544-2258-4A13-82B9-C02E9E42EBD2@macports.org>
Message-ID: <4928FE0D.10907@macports.org>

Ryan Schmidt wrote:
> On Nov 22, 2008, at 23:09, Jeremy Huddleston wrote:
> 
>> Oh and one more issue I just remembered... I've seen quite a few ports
>> do:
>>
>> prefix ${x11prefix}
>>
>> This seems to be a clear violation of the "nothing in /usr" policy...
>> and as someone who feels some amount of ownership of /usr/X11, I don't
>> want to see it get potentially thrashed...
>>
>> Am I correct in assuming that this is flat out wrong and should be
>> reverted back to installing into the macports dstroot?  Or was there
>> some reason for doing this that I'm not seeing?
> 
> I had assumed that the ports that installed into ${x11prefix} had some
> need to do so. I had not actually tried to use any of that software. If
> it works fine in ${prefix} then absolutely it should go there instead.

Yeah, I say move them to ${prefix}, and if they don't work there, fix
them so they do.

- Josh

From jeremyhu at macports.org  Sat Nov 22 23:06:32 2008
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Sat, 22 Nov 2008 23:06:32 -0800
Subject: X11 in Macports
In-Reply-To: <99BE27F0-C48D-4E62-8D8C-B625438AAF73@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
	<99BE27F0-C48D-4E62-8D8C-B625438AAF73@macports.org>
Message-ID: <5EE0FA1D-E9BE-4ED4-B93C-5B4A247BF9A0@macports.org>


On Nov 22, 2008, at 21:26, Ryan Schmidt wrote:
> On Nov 22, 2008, at 23:00, Jeremy Huddleston wrote:
>> For those of you who don't know me, I took over development of X11  
>> in OSX when Ben Byer moved on to bigger and better things at the  
>> beginning of 2009.
>
> Shhhh! I thought people weren't supposed to know you have a time  
> machine. :)

Psht... 2008... =p

>> 2) The other dependency issue
>>
>> Now, for what port to actually depend on... Quickly grepping though  
>> the code, I have seen the following dependencies for libX11:
>>
>> lib:libX11.6:XFree86
>> lib:libX11.6:xorg
>> lib:libX11:XFree86
>> lib:libX11:xorg
>> lib:libX11:xorg-libX11
>>
>> I'd like to standardize this to be xorg-libX11
>
> We did have consensus and standardization: everything that needed  
> X11 declared a dependency on "lib:libX11.6:XFree86". Then some  
> people started changing some ports to "lib:libX11.6:xorg" for an  
> unknown reason.
>
> As I understand it, the reason we have a policy exception to allow  
> Apple X11 to be used instead of XFree86 or xorg in MacPorts is that  
> Apple X11 integrates nicely with Mac OS X. I've never used xorg in  
> MacPorts, but I tried installing XFree86 some time ago and when it  
> launched, it had a weird cursor, weird window behavior, it launched  
> 5 weird-shaped and weird-colored terminal windows I couldn't figure  
> out how to deal with, and it was just a very off-putting experience.  
> I figured I didn't know what I was doing, uninstalled it, and  
> returned to Apple X11 which always worked great.
>
> My initial impression is that we shouldn't have a policy exception  
> for everything Leopard's X11 provides, however. fontconfig, xrender,  
> etc. are surely newer in MacPorts than they are in Tiger, and we  
> still support Tiger, and some people even still use MacPorts on  
> Panther. If there are things in Leopard's X11 that are newer than  
> what we have in MacPorts, then let's update what we have in  
> MacPorts. If a MacPorts port configuration (you say fontconfig?)  
> doesn't integrate well with the OS, then let's fix that port.

Right, I agree that we should update what we have in Macports...  
that's not at issue here... what's at issue is that libX11 can be  
provided by 3 different packages in Macporgs (xorg, XFree86, and xorg- 
libX11)... and I'd like to change that to just what is actually  
maintained and updated (xorg-libX11)...

As for supporting Tiger (and not intentionally trying to break  
Panther), but think that we should still use the lib:... dependency so  
that it "works better" on Leopard and SnowLeopard... also, users can  
opt to use the macports libs by pulling them in instead of the Tiger  
ones...

Perhaps the port:* dep should be used on Tiger and the lib:* dep on  
Leopard?  I don't really like that option, but I'd be willing to  
compromise on it if that would be satisfactory.

>> 3) The old monolith xorg and XFree86
>>
>> I'd like to eventually punt these in favor of having just one X11  
>> solution in Macports based on the latest release.
>
> I have no problem with changing the recommended non-Apple X11 from  
> XFree8 to xorg for example.

Well, the xorg port itself is actually the old monolithic 6.8.2  
release.  The xorg-server port is actually the latest release...

Perhaps we could update the xorg port to be a meta for xorg-server,  
xorg-libX11, etc...

> (I understand that Apple's X11 switched from being based on XFree86  
> to being based on xorg, and that would be a fine reason to also  
> prefer xorg as the fallback in MacPorts.) If that's decided, then it  
> should be done in all ports at once. Otherwise people are left  
> wondering why some ports depend on one X implementation and others  
> on another.

Agreed...

> As long as both projects continue to exist and function on current  
> OSes, there's no reason to delete one or the other, however, is  
> there? Choice is a good thing, and we certainly have other cases of  
> duplicate functionality in ports.

Does the XFree86 port actually function?  It didn't even build last I  
tried (granted it was over a year ago, but there doesn't seem to have  
been much movement on the port)... and the xorg port is using a  
codebase from 3 years ago and hasn't been touched since 2007-08-10...



From jeremyhu at macports.org  Sat Nov 22 23:08:29 2008
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Sat, 22 Nov 2008 23:08:29 -0800
Subject: X11 in Macports
In-Reply-To: <4928FE0D.10907@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
	<6B57E5F8-CB28-4A96-A09A-205A431B6536@macports.org>
	<9E493544-2258-4A13-82B9-C02E9E42EBD2@macports.org>
	<4928FE0D.10907@macports.org>
Message-ID: <2E5E3A8C-BD1B-43E0-B596-40F540F38032@macports.org>


On Nov 22, 2008, at 22:54, Joshua Root wrote:

> Ryan Schmidt wrote:
>> On Nov 22, 2008, at 23:09, Jeremy Huddleston wrote:
>>
>>> Oh and one more issue I just remembered... I've seen quite a few  
>>> ports
>>> do:
>>>
>>> prefix ${x11prefix}
>>>
>>> This seems to be a clear violation of the "nothing in /usr"  
>>> policy...
>>> and as someone who feels some amount of ownership of /usr/X11, I  
>>> don't
>>> want to see it get potentially thrashed...
>>>
>>> Am I correct in assuming that this is flat out wrong and should be
>>> reverted back to installing into the macports dstroot?  Or was there
>>> some reason for doing this that I'm not seeing?
>>
>> I had assumed that the ports that installed into ${x11prefix} had  
>> some
>> need to do so. I had not actually tried to use any of that  
>> software. If
>> it works fine in ${prefix} then absolutely it should go there  
>> instead.
>
> Yeah, I say move them to ${prefix}, and if they don't work there, fix
> them so they do.

Ok, I'll atleast start working on that front while we debate the fate  
of dependencies.


From jmr at macports.org  Sat Nov 22 23:13:53 2008
From: jmr at macports.org (Joshua Root)
Date: Sun, 23 Nov 2008 18:13:53 +1100
Subject: X11 in Macports
In-Reply-To: <99BE27F0-C48D-4E62-8D8C-B625438AAF73@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
	<99BE27F0-C48D-4E62-8D8C-B625438AAF73@macports.org>
Message-ID: <492902B1.2040402@macports.org>

Ryan Schmidt wrote:
>> I intend to go through all the x11 related ports and update
>> dependencies to be lib: or bin: where appropriate instead of port: (if
>> a port is not nomaintainer or openmaintainer, I will file a bug in
>> trac to be on the safe side... unless general consensus here is that
>> such reports would be overkill and I should just do it myself)

As Ryan explained, that's only a good idea on Darwin 9 (and of course,
development of its X11 will eventually stop too...) So maybe a better
idea is to delete the unneeded dependencies in a 'platform darwin 9'
section. Or, only add them on darwin 7 and 8, that way non-Darwin
platforms could also use their own libs if present. (Good idea? I don't
know.)

>> I'd like to standardize this to be xorg-libX11
> 
> We did have consensus and standardization: everything that needed X11
> declared a dependency on "lib:libX11.6:XFree86". Then some people
> started changing some ports to "lib:libX11.6:xorg" for an unknown reason.

It doesn't matter so much what they depend on, as long as that port has
a check like that currently in XFree86 (since we really want people to
use Apple's binary X11 on Mac OS X). So the depended-on port will only
be installed on other platforms, in which case I think xorg-libX11 is
fine. Hopefully users on non-Mac platforms will know that they also need
an X server somewhere.

>> 3) The old monolith xorg and XFree86
>>
>> I'd like to eventually punt these in favor of having just one X11
>> solution in Macports based on the latest release.

A port that installed XQuartz (or the appropriate Apple X11 package on
older OSes) would be nice, actually. Would save us having to tell users
"install X11 like it says on the Installing MacPorts page" all the time.

> As long as both projects continue to exist and function on current OSes,
> there's no reason to delete one or the other, however, is there? Choice
> is a good thing, and we certainly have other cases of duplicate
> functionality in ports.

Agreed - though xorg is broken at present.

- Josh

From jmr at macports.org  Sat Nov 22 23:21:53 2008
From: jmr at macports.org (Joshua Root)
Date: Sun, 23 Nov 2008 18:21:53 +1100
Subject: X11 in Macports
In-Reply-To: <5EE0FA1D-E9BE-4ED4-B93C-5B4A247BF9A0@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>	<99BE27F0-C48D-4E62-8D8C-B625438AAF73@macports.org>
	<5EE0FA1D-E9BE-4ED4-B93C-5B4A247BF9A0@macports.org>
Message-ID: <49290491.4020409@macports.org>

Jeremy Huddleston wrote:
> Does the XFree86 port actually function?  It didn't even build last I
> tried (granted it was over a year ago, but there doesn't seem to have
> been much movement on the port)... and the xorg port is using a codebase
> from 3 years ago and hasn't been touched since 2007-08-10...

Some people are apparently using the XFree86 port on PureDarwin.

- Josh

From afb at macports.org  Sun Nov 23 01:01:53 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Sun, 23 Nov 2008 10:01:53 +0100
Subject: X11 in Macports
In-Reply-To: <49290491.4020409@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>	<99BE27F0-C48D-4E62-8D8C-B625438AAF73@macports.org>
	<5EE0FA1D-E9BE-4ED4-B93C-5B4A247BF9A0@macports.org>
	<49290491.4020409@macports.org>
Message-ID: <01B374A1-2D2D-467E-9DD7-65B88F40E738@macports.org>

Joshua Root wrote:

>> Does the XFree86 port actually function?  It didn't even build last I
>> tried (granted it was over a year ago, but there doesn't seem to have
>> been much movement on the port)... and the xorg port is using a  
>> codebase
>> from 3 years ago and hasn't been touched since 2007-08-10...
>
> Some people are apparently using the XFree86 port on PureDarwin.

I've used XFree86 4.5.0 and XFree86 4.7.0 successfully with Darwin 8
(Darwin 7 came bundled with a system XFree86 4.3.0, so didn't need it)

I *think* PureDarwin.org and Darwin 9 are looking to upgrade to X.Org
eventually, but that it is not yet working with IOKit without Quartz ?

--anders


From jeremyhu at macports.org  Sun Nov 23 02:26:04 2008
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Sun, 23 Nov 2008 02:26:04 -0800
Subject: X11 in Macports
In-Reply-To: <49290491.4020409@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
	<99BE27F0-C48D-4E62-8D8C-B625438AAF73@macports.org>
	<5EE0FA1D-E9BE-4ED4-B93C-5B4A247BF9A0@macports.org>
	<49290491.4020409@macports.org>
Message-ID: <32D0C7B4-86A4-4E28-80CC-8EF4D0585C80@macports.org>


On Nov 22, 2008, at 23:21, Joshua Root wrote:

> Jeremy Huddleston wrote:
>> Does the XFree86 port actually function?  It didn't even build last I
>> tried (granted it was over a year ago, but there doesn't seem to have
>> been much movement on the port)... and the xorg port is using a  
>> codebase
>> from 3 years ago and hasn't been touched since 2007-08-10...
>
> Some people are apparently using the XFree86 port on PureDarwin.

Ah... people still do that?  Ok...


From jeremyhu at macports.org  Sun Nov 23 02:27:30 2008
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Sun, 23 Nov 2008 02:27:30 -0800
Subject: X11 in Macports
In-Reply-To: <492902B1.2040402@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
	<99BE27F0-C48D-4E62-8D8C-B625438AAF73@macports.org>
	<492902B1.2040402@macports.org>
Message-ID: <FF35E495-6609-4745-A200-6179E829936D@macports.org>


On Nov 22, 2008, at 23:13, Joshua Root wrote:

> Ryan Schmidt wrote:
>>> I intend to go through all the x11 related ports and update
>>> dependencies to be lib: or bin: where appropriate instead of port:  
>>> (if
>>> a port is not nomaintainer or openmaintainer, I will file a bug in
>>> trac to be on the safe side... unless general consensus here is that
>>> such reports would be overkill and I should just do it myself)
>
> As Ryan explained, that's only a good idea on Darwin 9 (and of course,
> development of its X11 will eventually stop too...) So maybe a better
> idea is to delete the unneeded dependencies in a 'platform darwin 9'
> section. Or, only add them on darwin 7 and 8, that way non-Darwin
> platforms could also use their own libs if present. (Good idea? I  
> don't
> know.)

Yeah, I mentioned that as an alternative as well...

>> We did have consensus and standardization: everything that needed X11
>> declared a dependency on "lib:libX11.6:XFree86". Then some people
>> started changing some ports to "lib:libX11.6:xorg" for an unknown  
>> reason.
>
> It doesn't matter so much what they depend on, as long as that port  
> has
> a check like that currently in XFree86 (since we really want people to
> use Apple's binary X11 on Mac OS X). So the depended-on port will only
> be installed on other platforms, in which case I think xorg-libX11 is
> fine. Hopefully users on non-Mac platforms will know that they also  
> need
> an X server somewhere.

Well the x server itself can be xorg-server... but there's no real  
reason that we *need* an X server... we just need to worry about the  
client side deps and the user can run it on whatever server they want  
(they can use Exceed on windows for all we care)

>>> 3) The old monolith xorg and XFree86
>>>
>>> I'd like to eventually punt these in favor of having just one X11
>>> solution in Macports based on the latest release.
>
> A port that installed XQuartz (or the appropriate Apple X11 package on
> older OSes) would be nice, actually.

I wasn't really talking about installing the binary Apple package...  
I'm talking about building it from source from Macports if the user  
desires to use it instead of the one on their system...



From afb at macports.org  Sun Nov 23 03:22:13 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Sun, 23 Nov 2008 12:22:13 +0100
Subject: X11 in Macports
In-Reply-To: <6B57E5F8-CB28-4A96-A09A-205A431B6536@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
	<6B57E5F8-CB28-4A96-A09A-205A431B6536@macports.org>
Message-ID: <547D79EF-5775-4B10-8C32-773D62C202D7@macports.org>

Jeremy Huddleston wrote:

> Oh and one more issue I just remembered... I've seen quite a few  
> ports do:
>
> prefix ${x11prefix}
>
> This seems to be a clear violation of the "nothing in /usr"  
> policy... and as someone who feels some amount of ownership of /usr/ 
> X11, I don't want to see it get potentially thrashed...

I think /usr/X11{,R6} was an exception, then it again the policy  
wasn't enforced much.

Then again /usr/X11R6 used to be hardcoded too, so things have  
changed a bit since.

> Am I correct in assuming that this is flat out wrong and should be  
> reverted back to installing into the macports dstroot?  Or was  
> there some reason for doing this that I'm not seeing?

Think it was a technical limitation, with some things not working  
outside ${x11prefix}...

Something like how .app bundles don't work fully outside an / 
Applications location or so.

--anders


From jmr at macports.org  Sun Nov 23 03:32:35 2008
From: jmr at macports.org (Joshua Root)
Date: Sun, 23 Nov 2008 22:32:35 +1100
Subject: X11 in Macports
In-Reply-To: <FF35E495-6609-4745-A200-6179E829936D@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
	<99BE27F0-C48D-4E62-8D8C-B625438AAF73@macports.org>
	<492902B1.2040402@macports.org>
	<FF35E495-6609-4745-A200-6179E829936D@macports.org>
Message-ID: <49293F53.5070503@macports.org>

Jeremy Huddleston wrote:
> 
> On Nov 22, 2008, at 23:13, Joshua Root wrote:
> 
>> It doesn't matter so much what they depend on, as long as that port has
>> a check like that currently in XFree86 (since we really want people to
>> use Apple's binary X11 on Mac OS X). So the depended-on port will only
>> be installed on other platforms, in which case I think xorg-libX11 is
>> fine. Hopefully users on non-Mac platforms will know that they also need
>> an X server somewhere.
> 
> Well the x server itself can be xorg-server... but there's no real
> reason that we *need* an X server... we just need to worry about the
> client side deps and the user can run it on whatever server they want
> (they can use Exceed on windows for all we care)

I was thinking of the case where a newbie doesn't have an X server,
installs GIMP or something, and complains that it won't run.

>>>> 3) The old monolith xorg and XFree86
>>>>
>>>> I'd like to eventually punt these in favor of having just one X11
>>>> solution in Macports based on the latest release.
>>
>> A port that installed XQuartz (or the appropriate Apple X11 package on
>> older OSes) would be nice, actually.
> 
> I wasn't really talking about installing the binary Apple package... I'm
> talking about building it from source from Macports if the user desires
> to use it instead of the one on their system...

Ah, yeah, that would be nice too. :-)

- Josh

From afb at macports.org  Sun Nov 23 03:36:27 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Sun, 23 Nov 2008 12:36:27 +0100
Subject: X11 in Macports
In-Reply-To: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
Message-ID: <E3AC96C7-8814-4B5B-9313-A931221085FC@macports.org>

Jeremy Huddleston wrote:

> 1) The dependency issue
>
> X11 lives in a grey area in Macports' dependency policy.  X11 is  
> actually given as the example for something that is appropriate to  
> use the lib:* or bin:* dependency rather than a port:* dependency,  
> yet there are plenty of ports that are still using a port:  
> dependency.  I believe this is mainly for things like libXrender  
> (rather than libX11) as a legacy of what was available in Tiger's  
> X11.  I'd very much like to use anything in /usr/X11/* over  
> installing a duplicate in /opt/local, and I'm sure others are in  
> the same boat.  I have seen a fair share of bug reports on xquartz- 
> dev that came about simply because the macports version didn't have  
> a fix that was in the system version or macports config files (eg:  
> for fontconfig) didn't match system configurations, so users were  
> wondering why some fonts weren't available in some programs.

I think the defacto recommendation is to install Xcode and X11+SDK,  
rather than using the various gcc and xorg ports... But like you say,  
this is a grey area and so it uses a lot of "both".

But this isn't something that is typical of X11, the same "issue"  
appears in a lot of places in MacPorts whether it is about OpenSSL/ 
libz/libbz2 or if it's about Perl/Python/Ruby...

> 2) The other dependency issue
>
> Now, for what port to actually depend on... Quickly grepping though  
> the code, I have seen the following dependencies for libX11:
>
> lib:libX11.6:XFree86
> lib:libX11.6:xorg
> lib:libX11:XFree86
> lib:libX11:xorg
> lib:libX11:xorg-libX11
>
> I'd like to standardize this to be xorg-libX11

Supposedly the "standard" used to be lib:libX11.6:XFree86 which
was meant to be supplied through /usr/X11/lib/libX11.6.dylib
on Leopard and from /usr/X11R6/lib/libX11.6.dylib on Tiger.
(i.e. nobody installed should need the "XFree86" port anyway)

> 3) The old monolith xorg and XFree86
>
> I'd like to eventually punt these in favor of having just one X11  
> solution in Macports based on the latest release.

You might want to move some of this functionality into "base".
So that ports could simply say something like "use_x11 yes" ?


I would also like to see something that would loook better than:

platform macosx {}
if { [variant_isset macosx] && ![variant_isset x11] }  
{ default_variants +aqua }
if { [variant_isset puredarwin] } { default_variants +x11 }
if { [variant_isset freebsd] } { default_variants +x11 }

That some ports currently have to use to allow both +x11 and +aqua.

There's also the +no_x11 and +quartz variants, muddying up further.
So it seems like it needs something better than Portfile workarounds ?

--anders


From afb at macports.org  Sun Nov 23 03:38:34 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Sun, 23 Nov 2008 12:38:34 +0100
Subject: X11 in Macports
In-Reply-To: <49293F53.5070503@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
	<99BE27F0-C48D-4E62-8D8C-B625438AAF73@macports.org>
	<492902B1.2040402@macports.org>
	<FF35E495-6609-4745-A200-6179E829936D@macports.org>
	<49293F53.5070503@macports.org>
Message-ID: <BEBC8DF6-C328-4CB0-9013-8EAF392E199C@macports.org>

Joshua Root wrote:

>> Well the x server itself can be xorg-server... but there's no real
>> reason that we *need* an X server... we just need to worry about the
>> client side deps and the user can run it on whatever server they want
>> (they can use Exceed on windows for all we care)
>
> I was thinking of the case where a newbie doesn't have an X server,
> installs GIMP or something, and complains that it won't run.

Does GIMP require X11 ? I thought it only needed (any) GTK+...

But yeah, if "something" is an X program then sure it needs X.

--anders


From jmr at macports.org  Sun Nov 23 03:44:42 2008
From: jmr at macports.org (Joshua Root)
Date: Sun, 23 Nov 2008 22:44:42 +1100
Subject: X11 in Macports
In-Reply-To: <BEBC8DF6-C328-4CB0-9013-8EAF392E199C@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
	<99BE27F0-C48D-4E62-8D8C-B625438AAF73@macports.org>
	<492902B1.2040402@macports.org>
	<FF35E495-6609-4745-A200-6179E829936D@macports.org>
	<49293F53.5070503@macports.org>
	<BEBC8DF6-C328-4CB0-9013-8EAF392E199C@macports.org>
Message-ID: <4929422A.9050509@macports.org>

Anders F Bj?rklund wrote:
> Joshua Root wrote:
> 
>>> Well the x server itself can be xorg-server... but there's no real
>>> reason that we *need* an X server... we just need to worry about the
>>> client side deps and the user can run it on whatever server they want
>>> (they can use Exceed on windows for all we care)
>>
>> I was thinking of the case where a newbie doesn't have an X server,
>> installs GIMP or something, and complains that it won't run.
> 
> Does GIMP require X11 ? I thought it only needed (any) GTK+...

True, but the x11 variant is selected by default.

- Josh

From jeremyhu at macports.org  Sun Nov 23 10:35:49 2008
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Sun, 23 Nov 2008 10:35:49 -0800
Subject: X11 in Macports
In-Reply-To: <547D79EF-5775-4B10-8C32-773D62C202D7@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
	<6B57E5F8-CB28-4A96-A09A-205A431B6536@macports.org>
	<547D79EF-5775-4B10-8C32-773D62C202D7@macports.org>
Message-ID: <7F3CA942-8AA0-4A8F-BFF5-13F79CA2D542@macports.org>


On Nov 23, 2008, at 03:22, Anders F Bj?rklund wrote:
>> Am I correct in assuming that this is flat out wrong and should be  
>> reverted back to installing into the macports dstroot?  Or was  
>> there some reason for doing this that I'm not seeing?
>
> Think it was a technical limitation, with some things not working  
> outside ${x11prefix}...

Well then it's a bug in the build system or something because it  
should work fine wherever you install it (and if it doesn't, that's a  
bug)

> Something like how .app bundles don't work fully outside an / 
> Applications location or so.

Uhm... .app bundles should work outside /Applications


From jeremyhu at macports.org  Sun Nov 23 10:39:13 2008
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Sun, 23 Nov 2008 10:39:13 -0800
Subject: X11 in Macports
In-Reply-To: <49293F53.5070503@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
	<99BE27F0-C48D-4E62-8D8C-B625438AAF73@macports.org>
	<492902B1.2040402@macports.org>
	<FF35E495-6609-4745-A200-6179E829936D@macports.org>
	<49293F53.5070503@macports.org>
Message-ID: <2F51245B-F11C-4116-8276-B33F15257BFB@macports.org>


On Nov 23, 2008, at 03:32, Joshua Root wrote:

> Jeremy Huddleston wrote:
>>
>> Well the x server itself can be xorg-server... but there's no real
>> reason that we *need* an X server... we just need to worry about the
>> client side deps and the user can run it on whatever server they want
>> (they can use Exceed on windows for all we care)
>
> I was thinking of the case where a newbie doesn't have an X server,
> installs GIMP or something, and complains that it won't run.

Right... good point...  I don't like the idea of depending on an X  
server since it's not technically needed on the system... but if that  
is something we want to do, I'll do it... let's face it, it's rare  
that someone would actually want to use gimp remotely... and if  
someone REALLY wants to not install the server, they can just hack the  
portfile or uninstall it after...

>> I wasn't really talking about installing the binary Apple  
>> package... I'm
>> talking about building it from source from Macports if the user  
>> desires
>> to use it instead of the one on their system...
>
> Ah, yeah, that would be nice too. :-)

And should be close... Someone in the xquartz-dev list has been trying  
to get it building on Tiger, so I've been pushing in fixes for all the  
obstacles he's been running into.


From afb at macports.org  Sun Nov 23 11:08:54 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Sun, 23 Nov 2008 20:08:54 +0100
Subject: X11 in Macports
In-Reply-To: <7F3CA942-8AA0-4A8F-BFF5-13F79CA2D542@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
	<6B57E5F8-CB28-4A96-A09A-205A431B6536@macports.org>
	<547D79EF-5775-4B10-8C32-773D62C202D7@macports.org>
	<7F3CA942-8AA0-4A8F-BFF5-13F79CA2D542@macports.org>
Message-ID: <9357A17A-7560-4767-AFC0-E6ED07A9A34D@macports.org>

Jeremy Huddleston wrote:

>> Something like how .app bundles don't work fully outside an / 
>> Applications location or so.
>
> Uhm... .app bundles should work outside /Applications

Sure, but there was something about Services or other features that
works from /Applications/MacPorts but not from ${prefix}/Applications ?

--anders


From jmr at macports.org  Sun Nov 23 11:23:28 2008
From: jmr at macports.org (Joshua Root)
Date: Mon, 24 Nov 2008 06:23:28 +1100
Subject: X11 in Macports
In-Reply-To: <9357A17A-7560-4767-AFC0-E6ED07A9A34D@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>	<6B57E5F8-CB28-4A96-A09A-205A431B6536@macports.org>	<547D79EF-5775-4B10-8C32-773D62C202D7@macports.org>	<7F3CA942-8AA0-4A8F-BFF5-13F79CA2D542@macports.org>
	<9357A17A-7560-4767-AFC0-E6ED07A9A34D@macports.org>
Message-ID: <4929ADB0.4010806@macports.org>

Anders F Bj?rklund wrote:
> Jeremy Huddleston wrote:
> 
>>> Something like how .app bundles don't work fully outside an
>>> /Applications location or so.
>>
>> Uhm... .app bundles should work outside /Applications
> 
> Sure, but there was something about Services or other features that
> works from /Applications/MacPorts but not from ${prefix}/Applications ?

The app doesn't automatically get registered with LaunchServices, so the
file type associations and whatnot aren't set up.

- Josh

From jeremyhu at macports.org  Sun Nov 23 12:45:48 2008
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Sun, 23 Nov 2008 12:45:48 -0800
Subject: X11 in Macports
In-Reply-To: <4929ADB0.4010806@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
	<6B57E5F8-CB28-4A96-A09A-205A431B6536@macports.org>
	<547D79EF-5775-4B10-8C32-773D62C202D7@macports.org>
	<7F3CA942-8AA0-4A8F-BFF5-13F79CA2D542@macports.org>
	<9357A17A-7560-4767-AFC0-E6ED07A9A34D@macports.org>
	<4929ADB0.4010806@macports.org>
Message-ID: <7D0FA542-D38B-459B-9D71-BF827DA08CC1@macports.org>


On Nov 23, 2008, at 11:23, Joshua Root wrote:

> Anders F Bj?rklund wrote:
>> Jeremy Huddleston wrote:
>>
>>>> Something like how .app bundles don't work fully outside an
>>>> /Applications location or so.
>>>
>>> Uhm... .app bundles should work outside /Applications
>>
>> Sure, but there was something about Services or other features that
>> works from /Applications/MacPorts but not from ${prefix}/ 
>> Applications ?
>
> The app doesn't automatically get registered with LaunchServices, so  
> the
> file type associations and whatnot aren't set up.

Was this maybe a bug in Tiger?  I have the exact opposite problem?  I  
can't figure out how to make LaunchServices NOT register a .app that  
is in my development space or DISTROOT... I can't tell you how many  
times I've had a problem because LaunchServices preferred /Users/ 
jeremy/src/freedesktop/pkg/X11/Applications/Utilities/X11.app over / 
Applications/Utilities/X11.app



From blb at macports.org  Sun Nov 23 19:15:21 2008
From: blb at macports.org (Bryan Blackburn)
Date: Sun, 23 Nov 2008 20:15:21 -0700
Subject: [42551] trunk/dports/python
In-Reply-To: <20081124024800.46E7074BF9D@beta.macosforge.org>
References: <20081124024800.46E7074BF9D@beta.macosforge.org>
Message-ID: <20081124031520.GJ506@ninagal.withay.com>

On Sun, Nov 23, 2008 at 06:48:00PM -0800, erickt at macports.org said:
> Revision: 42551
>           http://trac.macports.org/changeset/42551
> Author:   erickt at macports.org
> Date:     2008-11-23 18:47:59 -0800 (Sun, 23 Nov 2008)
> Log Message:
> -----------
> Version bump for pygments to 1.0.
[...]
> +PortSystem          1.0
> +PortGroup           python26 1.0

Note, there's currently no python26 port group so this isn't going to work
(not to mention, no py26-setuptools).

Bryan


From ryandesign at macports.org  Sun Nov 23 21:31:48 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 23 Nov 2008 23:31:48 -0600
Subject: [42539] trunk/dports/graphics
In-Reply-To: <20081124005012.F402774A875@beta.macosforge.org>
References: <20081124005012.F402774A875@beta.macosforge.org>
Message-ID: <6383AAE1-60FE-4535-BD7F-CC773B554919@macports.org>

On Nov 23, 2008, at 18:50, illogic-al at macports.org wrote:

> +configure.args      ../${distname} -DBUILD_SHARED_LIBS:BOOL=ON \
> +		-DCMAKE_VERBOSE_MAKEFILE=ON \
> +		-DCMAKE_BUILD_TYPE=Release \
> +		-DCMAKE_SYSTEM_PREFIX_PATH=\"/opt/local\;/usr\" \
> +		-DCMAKE_INSTALL_PREFIX=${prefix} \
> +        -DCMAKE_OSX_SYSROOT=${sysroot} \
> +		-Wno-dev

Shouldn't "/opt/local" up there be replaced with "${prefix}"?


From ryandesign at macports.org  Sun Nov 23 23:36:28 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 24 Nov 2008 01:36:28 -0600
Subject: kde4 ports
Message-ID: <AF1A80DD-BAAE-4170-A5C8-9112E466BDE8@macports.org>

Regarding all the kde4 ports you've committed...


You're fetching them all from the Subversion repository. Are  
distfiles not available for any of them? If there are distfiles  
provided, they should be used. If not, then you need to add svn as a  
build dependency. I recommend you declare it as "bin:svn:subversion",  
that way the Subversion client that Apple provides in Leopard and  
later can be used on those systems since it should be sufficient, and  
for those using Tiger or earlier or other OSes without built-in  
Subversion clients the subversion port will be built.


What is the idea behind the line "pre-configure { file mkdir $ 
{worksrcpath} }"?


I mentioned this earlier regarding qimageblitz but I see now it  
applies to all of them: /opt/local should not appear in the ports;  
the variable ${prefix} should be used.


These ports use cmake, and I see several things you've had to do in  
each port to accommodate this. Should there be a cmake portgroup?  
Since you're gaining familiarity with what cmake needs as a result of  
these ports, maybe you could work on such a portgroup.


For the universal variant, is there a way to make use of $ 
{configure.universal_archs} so that the user's selected architectures  
are built, instead of assuming they want ppc and i386?




From n.oxyde at gmail.com  Mon Nov 24 01:16:52 2008
From: n.oxyde at gmail.com (nox)
Date: Mon, 24 Nov 2008 10:16:52 +0100
Subject: X11 in Macports
In-Reply-To: <7D0FA542-D38B-459B-9D71-BF827DA08CC1@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
	<6B57E5F8-CB28-4A96-A09A-205A431B6536@macports.org>
	<547D79EF-5775-4B10-8C32-773D62C202D7@macports.org>
	<7F3CA942-8AA0-4A8F-BFF5-13F79CA2D542@macports.org>
	<9357A17A-7560-4767-AFC0-E6ED07A9A34D@macports.org>
	<4929ADB0.4010806@macports.org>
	<7D0FA542-D38B-459B-9D71-BF827DA08CC1@macports.org>
Message-ID: <D2821292-47CA-4979-B7AC-CC5829FE7331@gmail.com>


Le 23 nov. 08 ? 21:45, Jeremy Huddleston a ?crit :

>
> On Nov 23, 2008, at 11:23, Joshua Root wrote:
>
>> Anders F Bj?rklund wrote:
>>> Jeremy Huddleston wrote:
>>>
>>>>> Something like how .app bundles don't work fully outside an
>>>>> /Applications location or so.
>>>>
>>>> Uhm... .app bundles should work outside /Applications
>>>
>>> Sure, but there was something about Services or other features that
>>> works from /Applications/MacPorts but not from ${prefix}/ 
>>> Applications ?
>>
>> The app doesn't automatically get registered with LaunchServices,  
>> so the
>> file type associations and whatnot aren't set up.
>
> Was this maybe a bug in Tiger?  I have the exact opposite problem?   
> I can't figure out how to make LaunchServices NOT register a .app  
> that is in my development space or DISTROOT... I can't tell you how  
> many times I've had a problem because LaunchServices preferred / 
> Users/jeremy/src/freedesktop/pkg/X11/Applications/Utilities/X11.app  
> over /Applications/Utilities/X11.app

$HOME is a different thing, LaunchServices discover applications in  
this directory.
Not in ${prefix}.

From jmr at macports.org  Mon Nov 24 01:23:16 2008
From: jmr at macports.org (Joshua Root)
Date: Mon, 24 Nov 2008 20:23:16 +1100
Subject: X11 in Macports
In-Reply-To: <D2821292-47CA-4979-B7AC-CC5829FE7331@gmail.com>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
	<6B57E5F8-CB28-4A96-A09A-205A431B6536@macports.org>
	<547D79EF-5775-4B10-8C32-773D62C202D7@macports.org>
	<7F3CA942-8AA0-4A8F-BFF5-13F79CA2D542@macports.org>
	<9357A17A-7560-4767-AFC0-E6ED07A9A34D@macports.org>
	<4929ADB0.4010806@macports.org>
	<7D0FA542-D38B-459B-9D71-BF827DA08CC1@macports.org>
	<D2821292-47CA-4979-B7AC-CC5829FE7331@gmail.com>
Message-ID: <492A7284.1000401@macports.org>

nox wrote:
> 
> Le 23 nov. 08 ? 21:45, Jeremy Huddleston a ?crit :
> 
>>
>> On Nov 23, 2008, at 11:23, Joshua Root wrote:
>>
>>> Anders F Bj?rklund wrote:
>>>> Jeremy Huddleston wrote:
>>>>
>>>>>> Something like how .app bundles don't work fully outside an
>>>>>> /Applications location or so.
>>>>>
>>>>> Uhm... .app bundles should work outside /Applications
>>>>
>>>> Sure, but there was something about Services or other features that
>>>> works from /Applications/MacPorts but not from ${prefix}/Applications ?
>>>
>>> The app doesn't automatically get registered with LaunchServices, so the
>>> file type associations and whatnot aren't set up.
>>
>> Was this maybe a bug in Tiger?  I have the exact opposite problem?  I
>> can't figure out how to make LaunchServices NOT register a .app that
>> is in my development space or DISTROOT... I can't tell you how many
>> times I've had a problem because LaunchServices preferred
>> /Users/jeremy/src/freedesktop/pkg/X11/Applications/Utilities/X11.app
>> over /Applications/Utilities/X11.app
> 
> $HOME is a different thing, LaunchServices discover applications in this
> directory.
> Not in ${prefix}.

~/Applications is automatically searched, but not the rest of the home
dir. Apps do still get registered when you launch them or open the
enclosing folder in Finder.

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

- Josh

From jeremyhu at macports.org  Mon Nov 24 09:52:05 2008
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Mon, 24 Nov 2008 09:52:05 -0800
Subject: X11 in Macports
In-Reply-To: <492A7284.1000401@macports.org>
References: <9E93958C-1305-4739-91E0-219DC5A19149@macports.org>
	<6B57E5F8-CB28-4A96-A09A-205A431B6536@macports.org>
	<547D79EF-5775-4B10-8C32-773D62C202D7@macports.org>
	<7F3CA942-8AA0-4A8F-BFF5-13F79CA2D542@macports.org>
	<9357A17A-7560-4767-AFC0-E6ED07A9A34D@macports.org>
	<4929ADB0.4010806@macports.org>
	<7D0FA542-D38B-459B-9D71-BF827DA08CC1@macports.org>
	<D2821292-47CA-4979-B7AC-CC5829FE7331@gmail.com>
	<492A7284.1000401@macports.org>
Message-ID: <4ECE66AF-63FB-4AE4-8D9D-192CE4E6BAA8@macports.org>


On Nov 24, 2008, at 01:23, Joshua Root wrote:
>> $HOME is a different thing, LaunchServices discover applications in  
>> this
>> directory.
>> Not in ${prefix}.
>
> ~/Applications is automatically searched, but not the rest of the home
> dir. Apps do still get registered when you launch them or open the
> enclosing folder in Finder.
>
> <http://developer.apple.com/documentation/Carbon/Conceptual/LaunchServicesConcepts/LSCConcepts/chapter_2_section_5.html#//apple_ref/doc/uid/TP30000999-CH202-BABEJFCD 
> >

Yeah, this is the one that bites me:
* The Finder automatically registers all applications as it becomes  
aware of them, such as when they are dragged onto the user?s disk or  
when the user navigates to a folder containing them.

In any event, that still doesn't justify dumping stuff in $ 
{x11prefix} ...



From jmr at macports.org  Mon Nov 24 11:12:55 2008
From: jmr at macports.org (Joshua Root)
Date: Tue, 25 Nov 2008 06:12:55 +1100
Subject: [macports-mgr] libdvdread lacks dependency
In-Reply-To: <8ce799460811240957x40e0ccc2p235dfec12d121ccb@mail.gmail.com>
References: <8ce799460811240957x40e0ccc2p235dfec12d121ccb@mail.gmail.com>
Message-ID: <492AFCB7.702@macports.org>

Alexandre Fiori wrote:
> 
> hi.
> 
> im using a fresh new install of macports and i've found that libdvdread
> is lacking the dependency of libtool.

Posts to macports-mgr only go to the project managers. Messages like
this should go to macports-dev or macports-users, or in a Trac ticket.

Anyhow, fixed in r42570.

- Josh

From florian.ebeling at gmail.com  Tue Nov 25 01:23:46 2008
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Tue, 25 Nov 2008 10:23:46 +0100
Subject: Valgrind and Darwin (was: [42576] users/raimue)
Message-ID: <5cbbe4ae0811250123n568a7830o4451f39096d0394@mail.gmail.com>

On Tue, Nov 25, 2008 at 2:21 AM,  <raimue at macports.org> wrote:
> Revision 42576 Author raimue at macports.org Date 2008-11-24 17:21:15 -0800
> (Mon, 24 Nov 2008)
>
> Log Message
>
> devel/valgrind: Experimental valgrind port
> This is not intended for the general public yet, but if someone is really
> interested, this port can be found here in my tree.

Are there any good news on Darwin support in Valgrind?

Florian



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

From raimue at macports.org  Tue Nov 25 02:01:43 2008
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Tue, 25 Nov 2008 11:01:43 +0100
Subject: Valgrind and Darwin (was: [42576] users/raimue)
In-Reply-To: <5cbbe4ae0811250123n568a7830o4451f39096d0394@mail.gmail.com>
References: <5cbbe4ae0811250123n568a7830o4451f39096d0394@mail.gmail.com>
Message-ID: <492BCD07.8090606@macports.org>

C. Florian Ebeling wrote:
> On Tue, Nov 25, 2008 at 2:21 AM,  <raimue at macports.org> wrote:
>> Revision 42576 Author raimue at macports.org Date 2008-11-24 17:21:15 -0800
>> (Mon, 24 Nov 2008)
>>
>> Log Message
>>
>> devel/valgrind: Experimental valgrind port
>> This is not intended for the general public yet, but if someone is really
>> interested, this port can be found here in my tree.
> 
> Are there any good news on Darwin support in Valgrind?

Greg Parker is working on a patch to bring valgrind to Darwin/Mac OS X.

Check the homepage of the port:
    http://www.sealiesoftware.com/valgrind/
    Valgrind for Mac OS X. Some assembly required.

I just wanted to by write a Portfile doing the svn checkouts and
patching for convenience.

I don't think this is ready for the general public, so I did not create
a valgrind port in the official ports tree. But I wanted to save my work
somewhere and maybe someone else wants to try it out without much
assembly required :-)

Rainer

From ryandesign at macports.org  Tue Nov 25 21:52:51 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 25 Nov 2008 23:52:51 -0600
Subject: kde4 ports
In-Reply-To: <797cc39c0811251135pb05226cx5a7812d59adf94a2@mail.gmail.com>
References: <AF1A80DD-BAAE-4170-A5C8-9112E466BDE8@macports.org>
	<797cc39c0811251135pb05226cx5a7812d59adf94a2@mail.gmail.com>
Message-ID: <24CBB3B4-7FEE-4817-85E1-197E47DC92B1@macports.org>


On Nov 25, 2008, at 13:35, Big O wrote:

> On Mon, Nov 24, 2008 at 2:36 AM, Ryan Schmidt wrote:
>
>> Regarding all the kde4 ports you've committed...
>>
>>
>> You're fetching them all from the Subversion repository. Are  
>> distfiles not
>> available for any of them? If there are distfiles provided, they  
>> should be
>> used. If not, then you need to add svn as a build dependency. I  
>> recommend
>> you declare it as "bin:svn:subversion", that way the Subversion  
>> client that
>> Apple provides in Leopard and later can be used on those systems  
>> since it
>> should be sufficient, and for those using Tiger or earlier or  
>> other OSes
>> without built-in Subversion clients the subversion port will be  
>> built.
>
> Ah yes, actually. distfiles are available. I just find it easier to
> work from svn as I don't have to deal with the checksum section.  I'll
> use those if you want though.

Yes, we do want you to use distfiles when available. Fetching from  
svn is a last resort.


>> What is the idea behind the line "pre-configure { file mkdir $ 
>> {worksrcpath}
>> }"?
>
> I forget. :-) I think it creates the build directory. kde requires out
> of source bids, so we use "build" as that directory. I'll check.

Ok, that sounds fine.


>> I mentioned this earlier regarding qimageblitz but I see now it  
>> applies to
>> all of them: /opt/local should not appear in the ports; the variable
>> ${prefix} should be used.
>
> I'll change that. I forgot about those.

Ok great, thanks.


>> These ports use cmake, and I see several things you've had to do  
>> in each
>> port to accommodate this. Should there be a cmake portgroup? Since  
>> you're
>> gaining familiarity with what cmake needs as a result of these  
>> ports, maybe
>> you could work on such a portgroup.
>
> Sure. What's a portgroup :-)

Read the guide:

http://guide.macports.org/#reference.portgroup

A portgroup encapsulates behavior that would otherwise need to be  
repeated in many ports. Most python 2.5 ports use the python25  
portgroup. Most ports that compile using an xcode project use the  
xcode portgroup. Now that we're having lots of cmake-using ports, it  
might make sense to have a cmake portgroup.


>> For the universal variant, is there a way to make use of
>> ${configure.universal_archs} so that the user's selected  
>> architectures are
>> built, instead of assuming they want ppc and i386?
>
> Well if they are selecting universal don't they want i386 and ppc? I
> don't get it. Are you referring to x86_64 and ppc64 (does that even
> exist) archs being options as well.
> I don't know that cmake supports any options here besides ppc and
> i386. I'll check though.

By default a universal build in MacPorts is i386 ppc. But as of  
MacPorts 1.7.0, the user can select in the macports.conf which  
architectures they want. Maybe they want i386 ppc x86_64 ppc_64.  
Maybe they want just i386 x86_64. The variable $ 
{configure.universal_archs} contains the user's selection, and ports  
should use it. (Actually, hopefully, ports would never need to look  
there and it would happen automatically, which it hopefully would if  
there were a cmake portgroup; it would handle this once so all cmake- 
using ports would benefit from it.)


> CC me. not subscribed :-)

Please subscribe, so that you can post to the list and so that we can  
have conversations with you. If you're developing ports, and  
especially if you're a committer, you really need to be subscribed to  
and reading the lists.



From florian.ebeling at gmail.com  Wed Nov 26 03:59:54 2008
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Wed, 26 Nov 2008 12:59:54 +0100
Subject: MacPorts 1.7.1 milestone created
In-Reply-To: <20081120213136.GD760@ninagal.withay.com>
References: <49259888.6000201@macports.org>
	<20081120213136.GD760@ninagal.withay.com>
Message-ID: <5cbbe4ae0811260359k3a1a2852m1ec42b5e7c2b05a5@mail.gmail.com>

Let me quickly revive this thread :)

On Thu, Nov 20, 2008 at 10:31 PM, Bryan Blackburn <blb at macports.org> wrote:
> On Fri, Nov 21, 2008 at 04:04:08AM +1100, Joshua Root said:
>> I've created a MacPorts 1.7.1 milestone on Trac. I think we should move
>> most of the open tickets from the 1.7.0 milestone to 1.7.1, and release
>> a 1.7.0 beta.
>
> 13141 [1], if we ship a 1.7.1 dmg, then it makes sense; otherwise we could
> even move it to 1.8.0.

Check OS X version: This is an approval of Josh's suggestion.


> 15434 [2], I think some decision should be made first on the best choice
> first, then decide which version (since one decision is to ship as is with
> 1.7.0 now).

Search fields: decision pending. (I personally like trunk search.)


> 15868 [3], this makes sense, it's an issue but I don't recall seeing it too
> frequently.

Old subversion: approval.


> 16085 [4], it seems the work done so far on it may suggest that fixing it
> could be bigger than a couple of lines, so it might be quite a bit of time,
> hence it could also be moved to 1.7.1 or even 1.8.0.

Deactivation infinite loop: approval.

>
> 14482/14553 definitely are needed for 1.7.0 so port groups can be added in
> the future without major releases.

Updating port groups: Bryan thinks this is blocker.


> [1] - <http://trac.macports.org/ticket/13141>
> [2] - <http://trac.macports.org/ticket/15434>
> [3] - <http://trac.macports.org/ticket/15868>
> [4] - <http://trac.macports.org/ticket/16085>

Is this now reflected in the milestone, or was there no agreement? I
think it's not, is it?

Milstone:

http://trac.macports.org/query?status=assigned&status=new&status=reopened&group=status&milestone=MacPorts+1.7.0

So largely there seems to be an agreement, with the exception of
Updating Port Groups. That would be nice, I admit it. But I think
we could also live without until the next release comes, which is
hoped to be sooner anyway.

I will see if I find time to have a look at port groups, but I'm pessimistic
on that, a bit (unfortunately). Maybe somebody else fancies having a look at
it, because that seems to be the only blockers left, according to 50% of
port managers team. The reward would be quite high, because it would
unlock roughly a year worth of changes.

:)

Florian




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

From raimue at macports.org  Wed Nov 26 09:05:54 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Wed, 26 Nov 2008 18:05:54 +0100
Subject: MacPorts 1.7.1 milestone created
In-Reply-To: <5cbbe4ae0811260359k3a1a2852m1ec42b5e7c2b05a5@mail.gmail.com>
References: <49259888.6000201@macports.org>	<20081120213136.GD760@ninagal.withay.com>
	<5cbbe4ae0811260359k3a1a2852m1ec42b5e7c2b05a5@mail.gmail.com>
Message-ID: <492D81F2.5030201@macports.org>

C. Florian Ebeling wrote:
> So largely there seems to be an agreement, with the exception of
> Updating Port Groups. That would be nice, I admit it. But I think
> we could also live without until the next release comes, which is
> hoped to be sooner anyway.
> 
> I will see if I find time to have a look at port groups, but I'm pessimistic
> on that, a bit (unfortunately). Maybe somebody else fancies having a look at
> it, because that seems to be the only blockers left, according to 50% of
> port managers team. The reward would be quite high, because it would
> unlock roughly a year worth of changes.

Actually it should be all on the variants-descs-14482 branch, I just
have not gotten around to merge it back to trunk, which also means
moving port1.0/resources to dports/.

Last thing we have not decided on is how to name the resources
directory. I wanted to use .resources to make a clear difference to port
categories and to prevent portindex recursing there, but there was a
concern about using hidden directories. So I would be fine with using
_resources and let portindex ignore directories starting with an underscore.

Rainer

From blb at macports.org  Wed Nov 26 14:25:17 2008
From: blb at macports.org (Bryan Blackburn)
Date: Wed, 26 Nov 2008 15:25:17 -0700
Subject: MacPorts 1.7.1 milestone created
In-Reply-To: <492D81F2.5030201@macports.org>
References: <49259888.6000201@macports.org>
	<20081120213136.GD760@ninagal.withay.com>
	<5cbbe4ae0811260359k3a1a2852m1ec42b5e7c2b05a5@mail.gmail.com>
	<492D81F2.5030201@macports.org>
Message-ID: <20081126222517.GM706@ninagal.withay.com>

On Wed, Nov 26, 2008 at 06:05:54PM +0100, Rainer M?ller said:
> C. Florian Ebeling wrote:
> > So largely there seems to be an agreement, with the exception of
> > Updating Port Groups. That would be nice, I admit it. But I think
> > we could also live without until the next release comes, which is
> > hoped to be sooner anyway.
> > 
> > I will see if I find time to have a look at port groups, but I'm pessimistic
> > on that, a bit (unfortunately). Maybe somebody else fancies having a look at
> > it, because that seems to be the only blockers left, according to 50% of
> > port managers team. The reward would be quite high, because it would
> > unlock roughly a year worth of changes.
> 
> Actually it should be all on the variants-descs-14482 branch, I just
> have not gotten around to merge it back to trunk, which also means
> moving port1.0/resources to dports/.
> 
> Last thing we have not decided on is how to name the resources
> directory. I wanted to use .resources to make a clear difference to port
> categories and to prevent portindex recursing there, but there was a
> concern about using hidden directories. So I would be fine with using
> _resources and let portindex ignore directories starting with an underscore.

I don't see any problem with .resources, these are all files which are
included by port when needed (mirror_sites and the various port groups).
Most people aren't messing around with them so visibility isn't that big a
deal, and we don't have to add code to portindex/mporttraverse/ReaddirCmd()
to skip it.

Bryan


> 
> Rainer

From ryandesign at macports.org  Wed Nov 26 15:20:11 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 26 Nov 2008 17:20:11 -0600
Subject: kde4 ports
In-Reply-To: <797cc39c0811261342p5fd31577w7398f4cbf39f8415@mail.gmail.com>
References: <AF1A80DD-BAAE-4170-A5C8-9112E466BDE8@macports.org>
	<797cc39c0811251135pb05226cx5a7812d59adf94a2@mail.gmail.com>
	<24CBB3B4-7FEE-4817-85E1-197E47DC92B1@macports.org>
	<797cc39c0811261342p5fd31577w7398f4cbf39f8415@mail.gmail.com>
Message-ID: <40589888-8460-4987-BB43-FD3285D95308@macports.org>

On Nov 26, 2008, at 15:42, Big O wrote:

> On Wed, Nov 26, 2008 at 12:52 AM, Ryan Schmidt wrote:
>
>> On Nov 25, 2008, at 13:35, Big O wrote:
>>
>>> On Mon, Nov 24, 2008 at 2:36 AM, Ryan Schmidt wrote:
>>>
>>>> Regarding all the kde4 ports you've committed...
>>>>
>>>>
>>>> You're fetching them all from the Subversion repository. Are  
>>>> distfiles
>>>> not
>>>> available for any of them? If there are distfiles provided, they  
>>>> should
>>>> be
>>>> used. If not, then you need to add svn as a build dependency. I  
>>>> recommend
>>>> you declare it as "bin:svn:subversion", that way the Subversion  
>>>> client
>>>> that
>>>> Apple provides in Leopard and later can be used on those systems  
>>>> since it
>>>> should be sufficient, and for those using Tiger or earlier or  
>>>> other OSes
>>>> without built-in Subversion clients the subversion port will be  
>>>> built.
>>>
>>> Ah yes, actually. distfiles are available. I just find it easier to
>>> work from svn as I don't have to deal with the checksum section.   
>>> I'll
>>> use those if you want though.
>>
>> Yes, we do want you to use distfiles when available. Fetching from  
>> svn is a
>> last resort.
>
> Done.
>
>>>> What is the idea behind the line "pre-configure { file mkdir
>>>> ${worksrcpath}
>>>> }"?
>>>
>>> I forget. :-) I think it creates the build directory. kde  
>>> requires out
>>> of source bids, so we use "build" as that directory. I'll check.
>>
>> Ok, that sounds fine.
>>
>>
>>>> I mentioned this earlier regarding qimageblitz but I see now it  
>>>> applies
>>>> to
>>>> all of them: /opt/local should not appear in the ports; the  
>>>> variable
>>>> ${prefix} should be used.
>>>
>>> I'll change that. I forgot about those.
>>
>> Ok great, thanks.
>
> Fixed.
>
>>>> These ports use cmake, and I see several things you've had to do  
>>>> in each
>>>> port to accommodate this. Should there be a cmake portgroup?  
>>>> Since you're
>>>> gaining familiarity with what cmake needs as a result of these  
>>>> ports,
>>>> maybe
>>>> you could work on such a portgroup.
>>>
>>> Sure. What's a portgroup :-)
>>
>> Read the guide:
>>
>> http://guide.macports.org/#reference.portgroup
>
> Will look into it after thanksgiving.
>
>> A portgroup encapsulates behavior that would otherwise need to be  
>> repeated
>> in many ports. Most python 2.5 ports use the python25 portgroup.  
>> Most ports
>> that compile using an xcode project use the xcode portgroup. Now  
>> that we're
>> having lots of cmake-using ports, it might make sense to have a cmake
>> portgroup.
>>
>>
>>>> For the universal variant, is there a way to make use of
>>>> ${configure.universal_archs} so that the user's selected  
>>>> architectures
>>>> are
>>>> built, instead of assuming they want ppc and i386?
>
> cmake universal setting separates architechtures with a semi-colon ( ;
> ) so this would requires a lot more work to get right.

It's not too difficult..... ${configure.universal_archs} is the space- 
separated list of architectures, so the semicolon-separated list is  
just [strsed ${configure.universal_archs} "g/ /;/"]


>>> Well if they are selecting universal don't they want i386 and ppc? I
>>> don't get it. Are you referring to x86_64 and ppc64 (does that even
>>> exist) archs being options as well.
>>> I don't know that cmake supports any options here besides ppc and
>>> i386. I'll check though.
>>
>> By default a universal build in MacPorts is i386 ppc. But as of  
>> MacPorts
>> 1.7.0, the user can select in the macports.conf which  
>> architectures they
>> want. Maybe they want i386 ppc x86_64 ppc_64. Maybe they want just  
>> i386
>> x86_64. The variable ${configure.universal_archs} contains the user's
>> selection, and ports should use it. (Actually, hopefully, ports  
>> would never
>> need to look there and it would happen automatically, which it  
>> hopefully
>> would if there were a cmake portgroup; it would handle this once  
>> so all
>> cmake-using ports would benefit from it.)
>>
>>
>>> CC me. not subscribed :-)
>>
>> Please subscribe, so that you can post to the list and so that we  
>> can have
>> conversations with you. If you're developing ports, and especially  
>> if you're
>> a committer, you really need to be subscribed to and reading the  
>> lists.
>
> Subscribed.


From raimue at macports.org  Wed Nov 26 15:26:40 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 27 Nov 2008 00:26:40 +0100
Subject: MacPorts 1.7.1 milestone created
In-Reply-To: <20081126222517.GM706@ninagal.withay.com>
References: <49259888.6000201@macports.org>	<20081120213136.GD760@ninagal.withay.com>	<5cbbe4ae0811260359k3a1a2852m1ec42b5e7c2b05a5@mail.gmail.com>	<492D81F2.5030201@macports.org>
	<20081126222517.GM706@ninagal.withay.com>
Message-ID: <492DDB30.1050701@macports.org>

Bryan Blackburn wrote:
> On Wed, Nov 26, 2008 at 06:05:54PM +0100, Rainer M?ller said:
>> Last thing we have not decided on is how to name the resources
>> directory. I wanted to use .resources to make a clear difference to port
>> categories and to prevent portindex recursing there, but there was a
>> concern about using hidden directories. So I would be fine with using
>> _resources and let portindex ignore directories starting with an underscore.
> 
> I don't see any problem with .resources, these are all files which are
> included by port when needed (mirror_sites and the various port groups).
> Most people aren't messing around with them so visibility isn't that big a
> deal, and we don't have to add code to portindex/mporttraverse/ReaddirCmd()
> to skip it.

I just did a check and portindex actually does parse directories
starting with a dot. So it does not matter if we name it .resources or
_resources. Also, as long as we do not have any "Portfile" in resources,
we could also delay changes to portindex/mporttraverse to 1.7.1.

Rainer

From blb at macports.org  Wed Nov 26 17:53:24 2008
From: blb at macports.org (Bryan Blackburn)
Date: Wed, 26 Nov 2008 18:53:24 -0700
Subject: MacPorts 1.7.1 milestone created
In-Reply-To: <492DDB30.1050701@macports.org>
References: <49259888.6000201@macports.org>
	<20081120213136.GD760@ninagal.withay.com>
	<5cbbe4ae0811260359k3a1a2852m1ec42b5e7c2b05a5@mail.gmail.com>
	<492D81F2.5030201@macports.org>
	<20081126222517.GM706@ninagal.withay.com>
	<492DDB30.1050701@macports.org>
Message-ID: <20081127015324.GQ706@ninagal.withay.com>

On Thu, Nov 27, 2008 at 12:26:40AM +0100, Rainer M?ller said:
> Bryan Blackburn wrote:
> > On Wed, Nov 26, 2008 at 06:05:54PM +0100, Rainer M?ller said:
> >> Last thing we have not decided on is how to name the resources
> >> directory. I wanted to use .resources to make a clear difference to port
> >> categories and to prevent portindex recursing there, but there was a
> >> concern about using hidden directories. So I would be fine with using
> >> _resources and let portindex ignore directories starting with an underscore.
> > 
> > I don't see any problem with .resources, these are all files which are
> > included by port when needed (mirror_sites and the various port groups).
> > Most people aren't messing around with them so visibility isn't that big a
> > deal, and we don't have to add code to portindex/mporttraverse/ReaddirCmd()
> > to skip it.
> 
> I just did a check and portindex actually does parse directories
> starting with a dot. So it does not matter if we name it .resources or
> _resources. Also, as long as we do not have any "Portfile" in resources,
> we could also delay changes to portindex/mporttraverse to 1.7.1.

Hmm, so it does; my original test created one too many subdirs.  Note that
we would actually just need to avoid .resources/subdir/Portfile as just
.resources/Portfile is ignored, as is .resources/subdir/subdir2/Portfile (my
original test).

And I'd say the update would be needed in mporttraverse since that'll get
anything trying to access multiple Portfiles, instead of putting the check
in portindex.  Though it looks like the change may be as simple as adding

   if {[string index $category 0] == "."} {continue}

This would skip any dot files/directories (including .svn for those of us
with svn instead of rsync repos).

Bryan


> 
> Rainer

From jmr at macports.org  Thu Nov 27 00:16:08 2008
From: jmr at macports.org (Joshua Root)
Date: Thu, 27 Nov 2008 19:16:08 +1100
Subject: MacPorts 1.7.1 milestone created
In-Reply-To: <492DDB30.1050701@macports.org>
References: <49259888.6000201@macports.org>	<20081120213136.GD760@ninagal.withay.com>	<5cbbe4ae0811260359k3a1a2852m1ec42b5e7c2b05a5@mail.gmail.com>	<492D81F2.5030201@macports.org>	<20081126222517.GM706@ninagal.withay.com>
	<492DDB30.1050701@macports.org>
Message-ID: <492E5748.3070904@macports.org>

Rainer M?ller wrote:
> Bryan Blackburn wrote:
>> On Wed, Nov 26, 2008 at 06:05:54PM +0100, Rainer M?ller said:
>>> Last thing we have not decided on is how to name the resources
>>> directory. I wanted to use .resources to make a clear difference to port
>>> categories and to prevent portindex recursing there, but there was a
>>> concern about using hidden directories. So I would be fine with using
>>> _resources and let portindex ignore directories starting with an underscore.
>> I don't see any problem with .resources, these are all files which are
>> included by port when needed (mirror_sites and the various port groups).
>> Most people aren't messing around with them so visibility isn't that big a
>> deal, and we don't have to add code to portindex/mporttraverse/ReaddirCmd()
>> to skip it.
> 
> I just did a check and portindex actually does parse directories
> starting with a dot. So it does not matter if we name it .resources or
> _resources. Also, as long as we do not have any "Portfile" in resources,
> we could also delay changes to portindex/mporttraverse to 1.7.1.

I'd say it's high time this was merged back into trunk. I'm sure I'm not
the only one who doesn't have a separate install for testing the branch. :-)

- Josh

From ryandesign at macports.org  Thu Nov 27 01:21:44 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 27 Nov 2008 03:21:44 -0600
Subject: [42611] trunk/dports/kde/kdegraphics4/Portfile
In-Reply-To: <20081126165141.442FF78BA65@beta.macosforge.org>
References: <20081126165141.442FF78BA65@beta.macosforge.org>
Message-ID: <2DAD4C72-FFAD-45B6-A415-7A9059E9A6D9@macports.org>

In revision 42611 you made a bunch of changes to the kdegraphics4  
Portfile but gave an empty commit message.

In revision 42612 you deleted a blank line at the end of the  
Portfile, and gave this log message:

On Nov 26, 2008, at 10:54, illogic-al at macports.org wrote:

> use ${prefix} and some other cleanups. prevent ccache use until  
> cmake portgroup lands
> This is the changelog for the last change.


You should go back and edit the log messages of both of these  
revisions so that they state what was actually done in those  
revisions. Don't commit a second revision to describe a previous one.

Here's how you would edit those log messages:

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

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

This assumes your EDITOR environment variable is set appropriately.


From ryandesign at macports.org  Thu Nov 27 01:49:25 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 27 Nov 2008 03:49:25 -0600
Subject: [42620] trunk/dports/databases/mysql5-devel/Portfile
In-Reply-To: <20081126214836.8C35C790F7E@beta.macosforge.org>
References: <20081126214836.8C35C790F7E@beta.macosforge.org>
Message-ID: <E08F70E8-56C2-4AE4-BF1D-B97CD0F7847E@macports.org>

On Nov 26, 2008, at 15:48, illogic-al at macports.org wrote:

> Revision: 42620
>           http://trac.macports.org/changeset/42620
> Author:   illogic-al at macports.org
> Date:     2008-11-26 13:48:36 -0800 (Wed, 26 Nov 2008)
> Log Message:
> -----------
> Add embedded_server variant. Add revision. Fixes ticket #17410.

I'll have to look at this feature, but I may want to just build this  
all the time and forget the variant. (Variants should be created  
sparingly and only when really necessary.) I'm just not sure what's  
up with the -fPIC and --with-pic business. Can you explain?

Some discussion on this change beforehand would have been good. You  
did nothing wrong since the port is openmaintainer, and mysql5-devel  
is a low-profile port because nobody should be using -devel ports for  
anything important, however mysql5 is a high-profile port and I  
strive to keep mysql5 and mysql5-devel in sync in terms of features.  
So I'm going to remove openmaintainer from mysql5-devel now. I'm  
happy to entertain any changes you want to make, I just need to know  
about them and understand them so that I can properly support users  
who come to me asking about them.


> Modified Paths:
> --------------
>     trunk/dports/databases/mysql5-devel/Portfile
>
> Modified: trunk/dports/databases/mysql5-devel/Portfile
> ===================================================================
> --- trunk/dports/databases/mysql5-devel/Portfile	2008-11-26  
> 21:45:29 UTC (rev 42619)
> +++ trunk/dports/databases/mysql5-devel/Portfile	2008-11-26  
> 21:48:36 UTC (rev 42620)
> @@ -5,6 +5,7 @@
>  name                    mysql5-devel
>  set vers                5.1.29
>  version                 ${vers}-rc
> +revision                2

Note that

a) there was no reason to increase the revision when only adding a  
variant, because nothing will change for anyone who already had the  
port installed; anyone who wants this variant still has to rebuild  
the port with the new variant (though if we change it to build the  
embedded server always, and delete the variant, as I suggested above,  
then we will have to increase the revision, because that will change  
the files that get installed)

b) the default revision is 0, not 1, so if you add a revision line to  
a port that didn't have one, in order to increase the revision, the  
line should set the revision to 1, not 2


>  set branch              [join [lrange [split ${version} .] 0 1] .]
>  homepage                http://www.mysql.com/
>  categories              databases
> @@ -95,6 +96,13 @@
>      configure.cppflags-append   -I${worksrcpath}/include
>  }
>
> +variant embedded_server description "Build libmysqld embedded  
> server" {
> +    configure.cflags-append -fPIC
> +    configure.cxxflags-append -fPIC
> +    configure.args-append --with-embedded-server \
> +    --with-pic
> +}
> +
>  variant server description {add a startup item} {
>      configure.args-delete --without-server
>      # Create a startupitem to start/stop the server
> @@ -131,21 +139,21 @@
>      # Some directories we must have in all cases
>      xinstall -m 755 -d ${destroot}${sysconfdir}
>      destroot.keepdirs-append ${destroot}${sysconfdir}
> -
> +
>      # It has trouble installing in parallel if this doesn't  
> already exist
>      # See http://bugs.mysql.com/36560
>      xinstall -d ${destroot}${prefix}/mysql-test
>      xinstall -d ${destroot}${prefix}/mysql-test/ndb
> -
> +
>      # Setup only for server
>      if { [variant_isset server] } {
>          addgroup ${mysqluser}
>          set gid [existsgroup ${mysqluser}]
>          adduser ${mysqluser} gid=${gid} realname=MySQL\ Server
> -
> +
>          # Some directories we must have only if we're running as a  
> server
>          xinstall -m 755 -o root -d ${destroot}${prefix}/var/run
> -
> +
>          xinstall -m 755 -o ${mysqluser} -g ${mysqluser} -d \
>              ${destroot}${dbdir} \
>              ${destroot}${prefix}/var/run/${mysql}
> @@ -157,7 +165,7 @@
>
>  post-destroot {
>      delete ${destroot}${prefix}/mysql-test
> -
> +
>      # Fix paths in manpages and sample configuration files
>      foreach manpage [glob -type f ${destroot}${prefix}/share/man/ 
> man\[1-9\]/*] {
>          reinplace "s|/etc/my.cnf|${sysconfdir}/my.cnf|g" ${manpage}
> @@ -165,7 +173,7 @@
>      foreach samp_conffile [glob -type f ${destroot}${prefix}/share/ 
> ${mysql}/mysql/my-*.cnf] {
>          reinplace "s|/etc/my.cnf|${sysconfdir}/my.cnf|g" $ 
> {samp_conffile}
>      }
> -
> +
>      # Symlink mysql binaries into bin directory, with $ 
> {major_version} appended to the name
>      foreach f [glob -tails -directory ${destroot}${bindir} my*] {
>          ln -sf ${bindir}/${f} ${destroot}${prefix}/bin/${f}$ 
> {major_version}

Please don't make stylistic whitespace changes in ports that others  
maintain. :) In this case there's again consistency with mysql5 (and  
to a lesser extent mysql4) to consider, and it's also just the style  
I use in most of my ports so I like to keep it that way.



From ian.grant at cl.cam.ac.uk  Thu Nov 27 09:05:40 2008
From: ian.grant at cl.cam.ac.uk (Ian Grant)
Date: Thu, 27 Nov 2008 17:05:40 +0000
Subject: Example of a port with a custom build { } script
Message-ID: <FC12A18C-ABA5-40DE-8621-A7B3246AF254@cl.cam.ac.uk>

Hi All

I am trying to build a port which has a more complicated build  
procedure than just 'make xxx' I have to first build and install the  
main package and then go back into several subdirectories of the build  
directory and build and install plugins.

Can anyone point me to an example port which does something like this?  
I guess I need to add a  post-destroot { } section to do this. But how  
to change the working directory and run the make. Do I just use the  
tcl 'cd' and 'exec' commands, or is there some sophisticated error  
handling that I need to do?

Just being able to read the default build { } script would be a good  
start. Where is that kept?

Ian

From ryandesign at macports.org  Thu Nov 27 10:16:31 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 27 Nov 2008 12:16:31 -0600
Subject: Example of a port with a custom build { } script
In-Reply-To: <FC12A18C-ABA5-40DE-8621-A7B3246AF254@cl.cam.ac.uk>
References: <FC12A18C-ABA5-40DE-8621-A7B3246AF254@cl.cam.ac.uk>
Message-ID: <DBF018E7-ED9B-453B-BDC1-12E512D271BD@macports.org>


On Nov 27, 2008, at 11:05, Ian Grant wrote:

> I am trying to build a port which has a more complicated build  
> procedure than just 'make xxx' I have to first build and install  
> the main package and then go back into several subdirectories of  
> the build directory and build and install plugins.
>
> Can anyone point me to an example port which does something like  
> this? I guess I need to add a  post-destroot { } section to do  
> this. But how to change the working directory and run the make. Do  
> I just use the tcl 'cd' and 'exec' commands, or is there some  
> sophisticated error handling that I need to do?

Actually if you're wanting to "make" additional things, then that  
should happen in post-build, not post-destroot. Destroot is only for  
moving stuff that has already been built into the staging area. So  
maybe you need a post-build to build the plugins, and also a post- 
destroot to stage them. For the post-build, you would probably just  
use the tcl "system" command. You may not use the tcl "cd" command;  
it is deprecated and will not be in MacPorts 1.7.0 and later. You  
might do something like this:

set plugins {foo bar baz}

post-build {
	foreach plugin ${plugins} {
		system "cd ${worksrcpath}/plugins/${plugin} && make"
	}
}

post-destroot {
	foreach plugin ${plugins} {
		system "cd ${worksrcpath}/plugins/${plugin} && make install"
	}
}

Or you might consider fixing their existing Makefile so that it  
installs the plugins, and contributing that change back to the  
authors of the software. Then the Portfile becomes simpler.

> Just being able to read the default build { } script would be a  
> good start. Where is that kept?

That's probably a lot more complicated than you need but it's here:

http://trac.macports.org/browser/trunk/base/src/port1.0/portbuild.tcl


From jmr at macports.org  Thu Nov 27 10:43:09 2008
From: jmr at macports.org (Joshua Root)
Date: Fri, 28 Nov 2008 05:43:09 +1100
Subject: Example of a port with a custom build { } script
In-Reply-To: <FC12A18C-ABA5-40DE-8621-A7B3246AF254@cl.cam.ac.uk>
References: <FC12A18C-ABA5-40DE-8621-A7B3246AF254@cl.cam.ac.uk>
Message-ID: <492EEA3D.3040808@macports.org>

Ian Grant wrote:
> Hi All
> 
> I am trying to build a port which has a more complicated build procedure
> than just 'make xxx' I have to first build and install the main package
> and then go back into several subdirectories of the build directory and
> build and install plugins.
> 
> Can anyone point me to an example port which does something like this? I
> guess I need to add a  post-destroot { } section to do this. But how to
> change the working directory and run the make. Do I just use the tcl
> 'cd' and 'exec' commands, or is there some sophisticated error handling
> that I need to do?

Please don't use the Tcl 'cd' command, it can cause problems with base
code that assumes that the working directory won't be changed behind its
back. It will disappear altogether in MacPorts 1.7.

> Just being able to read the default build { } script would be a good
> start. Where is that kept?

The default build phase code has some abstractions and special cases
which mean it isn't as clear as what you'd see in a Portfile, but you
can find it in /opt/local/share/macports/Tcl/port1.0/portbuild.tcl.

>From your description it sounds like you might just want to use
build.target-append and destroot.target-append to add the targets that
build and install the plugins. But if that's not possible, then you'd do
something like:

post-build {
	system "cd ${worksrcpath}/plugin_subdir && make"
}
post-destroot {
	system "cd ${worksrcpath}/plugin_subdir && make install"
}

(Possibly using a foreach loop if you have to do the same thing in
several subdirs.)

- Josh

From illogical1 at gmail.com  Thu Nov 27 20:42:01 2008
From: illogical1 at gmail.com (Big O)
Date: Thu, 27 Nov 2008 23:42:01 -0500
Subject: [42620] trunk/dports/databases/mysql5-devel/Portfile
In-Reply-To: <E08F70E8-56C2-4AE4-BF1D-B97CD0F7847E@macports.org>
References: <20081126214836.8C35C790F7E@beta.macosforge.org>
	<E08F70E8-56C2-4AE4-BF1D-B97CD0F7847E@macports.org>
Message-ID: <797cc39c0811272042m397d4e54h72fc4be7dac28865@mail.gmail.com>

On Thu, Nov 27, 2008 at 4:49 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Nov 26, 2008, at 15:48, illogic-al at macports.org wrote:
>
>> Revision: 42620
>>          http://trac.macports.org/changeset/42620
>> Author:   illogic-al at macports.org
>> Date:     2008-11-26 13:48:36 -0800 (Wed, 26 Nov 2008)
>> Log Message:
>> -----------
>> Add embedded_server variant. Add revision. Fixes ticket #17410.
>
> I'll have to look at this feature, but I may want to just build this all the
> time and forget the variant. (Variants should be created sparingly and only
> when really necessary.) I'm just not sure what's up with the -fPIC and
> --with-pic business. Can you explain?
libmysqld.a needs to be built with -fPIC because it will be linked in
a shared library. the configure flag --with-pic is supposed to do this
but, do to a bug in mysql-5.1 it does not. That's why the c(xx)flag
-fPIC is explicitly added.
http://bugs.mysql.com/bug.php?id=39288
I don't know how building all of mysql with -fPIC would change/affect
anything so I thought making the change in a variant would keep any
issues localized to +embedded_server users (i.e. amarok users).

> Some discussion on this change beforehand would have been good. You did
> nothing wrong since the port is openmaintainer, and mysql5-devel is a
> low-profile port because nobody should be using -devel ports for anything
> important, however mysql5 is a high-profile port and I strive to keep mysql5
> and mysql5-devel in sync in terms of features. So I'm going to remove
> openmaintainer from mysql5-devel now. I'm happy to entertain any changes you
> want to make, I just need to know about them and understand them so that I
> can properly support users who come to me asking about them.
mysql5 can build libmysqld.a as well but from what I understand, this
isn't a supported feature. From all reports though, it works fine.

>
>
>> Modified Paths:
>> --------------
>>    trunk/dports/databases/mysql5-devel/Portfile
>>
>> Modified: trunk/dports/databases/mysql5-devel/Portfile
>> ===================================================================
>> --- trunk/dports/databases/mysql5-devel/Portfile        2008-11-26
>> 21:45:29 UTC (rev 42619)
>> +++ trunk/dports/databases/mysql5-devel/Portfile        2008-11-26
>> 21:48:36 UTC (rev 42620)
>> @@ -5,6 +5,7 @@
>>  name                    mysql5-devel
>>  set vers                5.1.29
>>  version                 ${vers}-rc
>> +revision                2
>
> Note that
>
> a) there was no reason to increase the revision when only adding a variant,
> because nothing will change for anyone who already had the port installed;
> anyone who wants this variant still has to rebuild the port with the new
> variant (though if we change it to build the embedded server always, and
> delete the variant, as I suggested above, then we will have to increase the
> revision, because that will change the files that get installed)
I misunderstood the revision's purpose then. I thought that if new
files were being installed that I had to add a revision. Sorry.

>
> b) the default revision is 0, not 1, so if you add a revision line to a port
> that didn't have one, in order to increase the revision, the line should set
> the revision to 1, not 2
Should I fix that?

>
>
>>  set branch              [join [lrange [split ${version} .] 0 1] .]
>>  homepage                http://www.mysql.com/
>>  categories              databases
>> @@ -95,6 +96,13 @@
>>     configure.cppflags-append   -I${worksrcpath}/include
>>  }
>>
>> +variant embedded_server description "Build libmysqld embedded server" {
>> +    configure.cflags-append -fPIC
>> +    configure.cxxflags-append -fPIC
>> +    configure.args-append --with-embedded-server \
>> +    --with-pic
>> +}
>> +
>>  variant server description {add a startup item} {
>>     configure.args-delete --without-server
>>     # Create a startupitem to start/stop the server
>> @@ -131,21 +139,21 @@
>>     # Some directories we must have in all cases
>>     xinstall -m 755 -d ${destroot}${sysconfdir}
>>     destroot.keepdirs-append ${destroot}${sysconfdir}
>> -
>> +
>>     # It has trouble installing in parallel if this doesn't already exist
>>     # See http://bugs.mysql.com/36560
>>     xinstall -d ${destroot}${prefix}/mysql-test
>>     xinstall -d ${destroot}${prefix}/mysql-test/ndb
>> -
>> +
>>     # Setup only for server
>>     if { [variant_isset server] } {
>>         addgroup ${mysqluser}
>>         set gid [existsgroup ${mysqluser}]
>>         adduser ${mysqluser} gid=${gid} realname=MySQL\ Server
>> -
>> +
>>         # Some directories we must have only if we're running as a server
>>         xinstall -m 755 -o root -d ${destroot}${prefix}/var/run
>> -
>> +
>>         xinstall -m 755 -o ${mysqluser} -g ${mysqluser} -d \
>>             ${destroot}${dbdir} \
>>             ${destroot}${prefix}/var/run/${mysql}
>> @@ -157,7 +165,7 @@
>>
>>  post-destroot {
>>     delete ${destroot}${prefix}/mysql-test
>> -
>> +
>>     # Fix paths in manpages and sample configuration files
>>     foreach manpage [glob -type f
>> ${destroot}${prefix}/share/man/man\[1-9\]/*] {
>>         reinplace "s|/etc/my.cnf|${sysconfdir}/my.cnf|g" ${manpage}
>> @@ -165,7 +173,7 @@
>>     foreach samp_conffile [glob -type f
>> ${destroot}${prefix}/share/${mysql}/mysql/my-*.cnf] {
>>         reinplace "s|/etc/my.cnf|${sysconfdir}/my.cnf|g" ${samp_conffile}
>>     }
>> -
>> +
>>     # Symlink mysql binaries into bin directory, with ${major_version}
>> appended to the name
>>     foreach f [glob -tails -directory ${destroot}${bindir} my*] {
>>         ln -sf ${bindir}/${f}
>> ${destroot}${prefix}/bin/${f}${major_version}
>
> Please don't make stylistic whitespace changes in ports that others
> maintain. :) In this case there's again consistency with mysql5 (and to a
> lesser extent mysql4) to consider, and it's also just the style I use in
> most of my ports so I like to keep it that way.
heheh. Sorry about that.

>
>
>



-- 
All your gmail are belong to us.

From ryandesign at macports.org  Fri Nov 28 01:32:48 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 28 Nov 2008 03:32:48 -0600
Subject: [42620] trunk/dports/databases/mysql5-devel/Portfile
In-Reply-To: <797cc39c0811272042m397d4e54h72fc4be7dac28865@mail.gmail.com>
References: <20081126214836.8C35C790F7E@beta.macosforge.org>
	<E08F70E8-56C2-4AE4-BF1D-B97CD0F7847E@macports.org>
	<797cc39c0811272042m397d4e54h72fc4be7dac28865@mail.gmail.com>
Message-ID: <F744E289-EB3A-4757-BCB8-00A59AB1DB9E@macports.org>

On Nov 27, 2008, at 22:42, Big O wrote:

> On Thu, Nov 27, 2008 at 4:49 AM, Ryan Schmidt wrote:
>
>> On Nov 26, 2008, at 15:48, illogic-al at macports.org wrote:
>>
>>> Revision: 42620
>>>          http://trac.macports.org/changeset/42620
>>> Author:   illogic-al at macports.org
>>> Date:     2008-11-26 13:48:36 -0800 (Wed, 26 Nov 2008)
>>> Log Message:
>>> -----------
>>> Add embedded_server variant. Add revision. Fixes ticket #17410.
>>
>> I'll have to look at this feature, but I may want to just build  
>> this all the
>> time and forget the variant. (Variants should be created sparingly  
>> and only
>> when really necessary.) I'm just not sure what's up with the -fPIC  
>> and
>> --with-pic business. Can you explain?
>
> libmysqld.a needs to be built with -fPIC because it will be linked in
> a shared library. the configure flag --with-pic is supposed to do this
> but, do to a bug in mysql-5.1 it does not. That's why the c(xx)flag
> -fPIC is explicitly added.
> http://bugs.mysql.com/bug.php?id=39288
> I don't know how building all of mysql with -fPIC would change/affect
> anything so I thought making the change in a variant would keep any
> issues localized to +embedded_server users (i.e. amarok users).

How did you know to use the --with-pic option, and what is the  
symptom of not using it?


>> Some discussion on this change beforehand would have been good.  
>> You did
>> nothing wrong since the port is openmaintainer, and mysql5-devel is a
>> low-profile port because nobody should be using -devel ports for  
>> anything
>> important, however mysql5 is a high-profile port and I strive to  
>> keep mysql5
>> and mysql5-devel in sync in terms of features. So I'm going to remove
>> openmaintainer from mysql5-devel now. I'm happy to entertain any  
>> changes you
>> want to make, I just need to know about them and understand them  
>> so that I
>> can properly support users who come to me asking about them.
>
> mysql5 can build libmysqld.a as well but from what I understand, this
> isn't a supported feature. From all reports though, it works fine.

5.1.x is now the recommended ("generally available") version of  
MySQL, so I'll have to update the mysql5 port to that version soon.


>>> Modified Paths:
>>> --------------
>>>    trunk/dports/databases/mysql5-devel/Portfile
>>>
>>> Modified: trunk/dports/databases/mysql5-devel/Portfile
>>> ===================================================================
>>> --- trunk/dports/databases/mysql5-devel/Portfile        2008-11-26
>>> 21:45:29 UTC (rev 42619)
>>> +++ trunk/dports/databases/mysql5-devel/Portfile        2008-11-26
>>> 21:48:36 UTC (rev 42620)
>>> @@ -5,6 +5,7 @@
>>>  name                    mysql5-devel
>>>  set vers                5.1.29
>>>  version                 ${vers}-rc
>>> +revision                2
>>
>> Note that
>>
>> a) there was no reason to increase the revision when only adding a  
>> variant,
>> because nothing will change for anyone who already had the port  
>> installed;
>> anyone who wants this variant still has to rebuild the port with  
>> the new
>> variant (though if we change it to build the embedded server  
>> always, and
>> delete the variant, as I suggested above, then we will have to  
>> increase the
>> revision, because that will change the files that get installed)
>
> I misunderstood the revision's purpose then. I thought that if new
> files were being installed that I had to add a revision. Sorry.

Yes, you need to increase the revision when the port is changed to  
install different files. However, there is no difference in files for  
any users who had mysql5-devel @5.1.29_0 installed so there's no  
reason to force them to rebuild the port. The only way users will get  
the different files is to uninstall the port and reinstall it with  
the new variant selected.

If, on the other hand, you had changed the files that get installed  
by an existing variant, or by the port itself when no variant is  
selected, then increasing the revision is warranted.


>> b) the default revision is 0, not 1, so if you add a revision line  
>> to a port
>> that didn't have one, in order to increase the revision, the line  
>> should set
>> the revision to 1, not 2
>
> Should I fix that?

No, but do keep it in mind for future port updates.



From illogical1 at gmail.com  Fri Nov 28 08:33:08 2008
From: illogical1 at gmail.com (Big O)
Date: Fri, 28 Nov 2008 11:33:08 -0500
Subject: [42620] trunk/dports/databases/mysql5-devel/Portfile
In-Reply-To: <F744E289-EB3A-4757-BCB8-00A59AB1DB9E@macports.org>
References: <20081126214836.8C35C790F7E@beta.macosforge.org>
	<E08F70E8-56C2-4AE4-BF1D-B97CD0F7847E@macports.org>
	<797cc39c0811272042m397d4e54h72fc4be7dac28865@mail.gmail.com>
	<F744E289-EB3A-4757-BCB8-00A59AB1DB9E@macports.org>
Message-ID: <797cc39c0811280833w45be97epa058bba4a453c4d5@mail.gmail.com>

On Fri, Nov 28, 2008 at 4:32 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
> On Nov 27, 2008, at 22:42, Big O wrote:
>
>> On Thu, Nov 27, 2008 at 4:49 AM, Ryan Schmidt wrote:
>>
>>> On Nov 26, 2008, at 15:48, illogic-al at macports.org wrote:
>>>
>>>> Revision: 42620
>>>>         http://trac.macports.org/changeset/42620
>>>> Author:   illogic-al at macports.org
>>>> Date:     2008-11-26 13:48:36 -0800 (Wed, 26 Nov 2008)
>>>> Log Message:
>>>> -----------
>>>> Add embedded_server variant. Add revision. Fixes ticket #17410.
>>>
>>> I'll have to look at this feature, but I may want to just build this all
>>> the
>>> time and forget the variant. (Variants should be created sparingly and
>>> only
>>> when really necessary.) I'm just not sure what's up with the -fPIC and
>>> --with-pic business. Can you explain?
>>
>> libmysqld.a needs to be built with -fPIC because it will be linked in
>> a shared library. the configure flag --with-pic is supposed to do this
>> but, do to a bug in mysql-5.1 it does not. That's why the c(xx)flag
>> -fPIC is explicitly added.
>> http://bugs.mysql.com/bug.php?id=39288
>> I don't know how building all of mysql with -fPIC would change/affect
>> anything so I thought making the change in a variant would keep any
>> issues localized to +embedded_server users (i.e. amarok users).
>
> How did you know to use the --with-pic option, and what is the symptom of
> not using it?
Discussion of this took place around september on the amarok-devel
mailing list. here's an excerpt
"By the way, forgot to mention that the "-fPIC or not -fPIC" debate is
irrelevant. Mysql's configure script has a --with-pic flag, so
packaging a PIC-enabled libmysqld is not screwing with the package
everyone uses, but adding a flexibility, suggested by mysql itself. On
the other hand, this flag is borked and does nothing for libmysqld,
but upstream agreed that it's their fault (see relevant mysql bug), so
it's package maintainers' responsibility to fix it downstream."
For any code going into a shared library -fPIC is required. Basically
libmysqld.a (static lib) is being linked to libamarok-sqlcollection.so
 (dynamic lib) and that's why we need -fPIC when creating libmysqld.a.
One downside of this is that the resulting shared lib is rather large
(especially when doing a universal build). Using -fpic instead might
solve this but I haven't tried and don't intend to.
The mailing list is private so I can't link to it here, but this
gentoo bug report provides more info as well, including how to build a
shared library which I tried and didn't get to work properly.
http://bugs.gentoo.org/show_bug.cgi?id=238487

>
>
>>> Some discussion on this change beforehand would have been good. You did
>>> nothing wrong since the port is openmaintainer, and mysql5-devel is a
>>> low-profile port because nobody should be using -devel ports for anything
>>> important, however mysql5 is a high-profile port and I strive to keep
>>> mysql5
>>> and mysql5-devel in sync in terms of features. So I'm going to remove
>>> openmaintainer from mysql5-devel now. I'm happy to entertain any changes
>>> you
>>> want to make, I just need to know about them and understand them so that
>>> I
>>> can properly support users who come to me asking about them.
>>
>> mysql5 can build libmysqld.a as well but from what I understand, this
>> isn't a supported feature. From all reports though, it works fine.
>
> 5.1.x is now the recommended ("generally available") version of MySQL, so
> I'll have to update the mysql5 port to that version soon.
>
>
>>>> Modified Paths:
>>>> --------------
>>>>   trunk/dports/databases/mysql5-devel/Portfile
>>>>
>>>> Modified: trunk/dports/databases/mysql5-devel/Portfile
>>>> ===================================================================
>>>> --- trunk/dports/databases/mysql5-devel/Portfile        2008-11-26
>>>> 21:45:29 UTC (rev 42619)
>>>> +++ trunk/dports/databases/mysql5-devel/Portfile        2008-11-26
>>>> 21:48:36 UTC (rev 42620)
>>>> @@ -5,6 +5,7 @@
>>>>  name                    mysql5-devel
>>>>  set vers                5.1.29
>>>>  version                 ${vers}-rc
>>>> +revision                2
>>>
>>> Note that
>>>
>>> a) there was no reason to increase the revision when only adding a
>>> variant,
>>> because nothing will change for anyone who already had the port
>>> installed;
>>> anyone who wants this variant still has to rebuild the port with the new
>>> variant (though if we change it to build the embedded server always, and
>>> delete the variant, as I suggested above, then we will have to increase
>>> the
>>> revision, because that will change the files that get installed)
>>
>> I misunderstood the revision's purpose then. I thought that if new
>> files were being installed that I had to add a revision. Sorry.
>
> Yes, you need to increase the revision when the port is changed to install
> different files. However, there is no difference in files for any users who
> had mysql5-devel @5.1.29_0 installed so there's no reason to force them to
> rebuild the port. The only way users will get the different files is to
> uninstall the port and reinstall it with the new variant selected.
>
> If, on the other hand, you had changed the files that get installed by an
> existing variant, or by the port itself when no variant is selected, then
> increasing the revision is warranted.
>
>
>>> b) the default revision is 0, not 1, so if you add a revision line to a
>>> port
>>> that didn't have one, in order to increase the revision, the line should
>>> set
>>> the revision to 1, not 2
>>
>> Should I fix that?
>
> No, but do keep it in mind for future port updates.
>
Will do.



-- 
All your gmail are belong to us.

From jmr at macports.org  Fri Nov 28 08:50:09 2008
From: jmr at macports.org (Joshua Root)
Date: Sat, 29 Nov 2008 03:50:09 +1100
Subject: [42620] trunk/dports/databases/mysql5-devel/Portfile
In-Reply-To: <797cc39c0811280833w45be97epa058bba4a453c4d5@mail.gmail.com>
References: <20081126214836.8C35C790F7E@beta.macosforge.org>	<E08F70E8-56C2-4AE4-BF1D-B97CD0F7847E@macports.org>	<797cc39c0811272042m397d4e54h72fc4be7dac28865@mail.gmail.com>	<F744E289-EB3A-4757-BCB8-00A59AB1DB9E@macports.org>
	<797cc39c0811280833w45be97epa058bba4a453c4d5@mail.gmail.com>
Message-ID: <49302141.1060208@macports.org>

Big O wrote:
> On Fri, Nov 28, 2008 at 4:32 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
>> How did you know to use the --with-pic option, and what is the symptom of
>> not using it?
> Discussion of this took place around september on the amarok-devel
> mailing list. here's an excerpt
> "By the way, forgot to mention that the "-fPIC or not -fPIC" debate is
> irrelevant. Mysql's configure script has a --with-pic flag, so
> packaging a PIC-enabled libmysqld is not screwing with the package
> everyone uses, but adding a flexibility, suggested by mysql itself. On
> the other hand, this flag is borked and does nothing for libmysqld,
> but upstream agreed that it's their fault (see relevant mysql bug), so
> it's package maintainers' responsibility to fix it downstream."
> For any code going into a shared library -fPIC is required. Basically
> libmysqld.a (static lib) is being linked to libamarok-sqlcollection.so
>  (dynamic lib) and that's why we need -fPIC when creating libmysqld.a.

The gcc man page says, "-fPIC is the default on Darwin and Mac OS X."
You have to use -mdynamic-no-pic if you don't want it to produce PIC.

- Josh

From illogical1 at gmail.com  Fri Nov 28 09:48:31 2008
From: illogical1 at gmail.com (Big O)
Date: Fri, 28 Nov 2008 12:48:31 -0500
Subject: [42620] trunk/dports/databases/mysql5-devel/Portfile
In-Reply-To: <49302141.1060208@macports.org>
References: <20081126214836.8C35C790F7E@beta.macosforge.org>
	<E08F70E8-56C2-4AE4-BF1D-B97CD0F7847E@macports.org>
	<797cc39c0811272042m397d4e54h72fc4be7dac28865@mail.gmail.com>
	<F744E289-EB3A-4757-BCB8-00A59AB1DB9E@macports.org>
	<797cc39c0811280833w45be97epa058bba4a453c4d5@mail.gmail.com>
	<49302141.1060208@macports.org>
Message-ID: <797cc39c0811280948h90d0129p1411634779667a15@mail.gmail.com>

On Fri, Nov 28, 2008 at 11:50 AM, Joshua Root <jmr at macports.org> wrote:
> Big O wrote:
>> On Fri, Nov 28, 2008 at 4:32 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
>>> How did you know to use the --with-pic option, and what is the symptom of
>>> not using it?
>> Discussion of this took place around september on the amarok-devel
>> mailing list. here's an excerpt
>> "By the way, forgot to mention that the "-fPIC or not -fPIC" debate is
>> irrelevant. Mysql's configure script has a --with-pic flag, so
>> packaging a PIC-enabled libmysqld is not screwing with the package
>> everyone uses, but adding a flexibility, suggested by mysql itself. On
>> the other hand, this flag is borked and does nothing for libmysqld,
>> but upstream agreed that it's their fault (see relevant mysql bug), so
>> it's package maintainers' responsibility to fix it downstream."
>> For any code going into a shared library -fPIC is required. Basically
>> libmysqld.a (static lib) is being linked to libamarok-sqlcollection.so
>>  (dynamic lib) and that's why we need -fPIC when creating libmysqld.a.
>
> The gcc man page says, "-fPIC is the default on Darwin and Mac OS X."
> You have to use -mdynamic-no-pic if you don't want it to produce PIC.
>
> - Josh
>
I think this is referring to shared libs. We want static libs with fPIC.


-- 
All your gmail are belong to us.

From ryandesign at macports.org  Fri Nov 28 11:27:26 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 28 Nov 2008 13:27:26 -0600
Subject: [42620] trunk/dports/databases/mysql5-devel/Portfile
In-Reply-To: <797cc39c0811280833w45be97epa058bba4a453c4d5@mail.gmail.com>
References: <20081126214836.8C35C790F7E@beta.macosforge.org>
	<E08F70E8-56C2-4AE4-BF1D-B97CD0F7847E@macports.org>
	<797cc39c0811272042m397d4e54h72fc4be7dac28865@mail.gmail.com>
	<F744E289-EB3A-4757-BCB8-00A59AB1DB9E@macports.org>
	<797cc39c0811280833w45be97epa058bba4a453c4d5@mail.gmail.com>
Message-ID: <135ED162-E087-44C9-8DB7-4B7E4ECDB4F4@macports.org>


On Nov 28, 2008, at 10:33, Big O wrote:

>> How did you know to use the --with-pic option, and what is the  
>> symptom of
>> not using it?
>
> Discussion of this took place around september on the amarok-devel
> mailing list. here's an excerpt
> "By the way, forgot to mention that the "-fPIC or not -fPIC" debate is
> irrelevant. Mysql's configure script has a --with-pic flag, so
> packaging a PIC-enabled libmysqld is not screwing with the package
> everyone uses, but adding a flexibility, suggested by mysql itself. On
> the other hand, this flag is borked and does nothing for libmysqld,
> but upstream agreed that it's their fault (see relevant mysql bug), so
> it's package maintainers' responsibility to fix it downstream."
> For any code going into a shared library -fPIC is required. Basically
> libmysqld.a (static lib) is being linked to libamarok-sqlcollection.so
>  (dynamic lib) and that's why we need -fPIC when creating libmysqld.a.
> One downside of this is that the resulting shared lib is rather large
> (especially when doing a universal build). Using -fpic instead might
> solve this but I haven't tried and don't intend to.
> The mailing list is private so I can't link to it here, but this
> gentoo bug report provides more info as well, including how to build a
> shared library which I tried and didn't get to work properly.
> http://bugs.gentoo.org/show_bug.cgi?id=238487

In that bug the Gentoo MySQL maintainer says that adding -fPIC is not  
a good idea:

http://bugs.gentoo.org/show_bug.cgi?id=238487#c34

He says building a shared library would be better, and I know shared  
libraries are greatly preferred over static ones on Mac OS X. So we  
should do that, if we can figure out how, or convince MySQL AB to do  
so in a future version of MySQL.


From peter at pogma.com  Fri Nov 28 11:46:45 2008
From: peter at pogma.com (Peter O'Gorman)
Date: Fri, 28 Nov 2008 13:46:45 -0600
Subject: [42620] trunk/dports/databases/mysql5-devel/Portfile
In-Reply-To: <797cc39c0811280948h90d0129p1411634779667a15@mail.gmail.com>
References: <20081126214836.8C35C790F7E@beta.macosforge.org>	<E08F70E8-56C2-4AE4-BF1D-B97CD0F7847E@macports.org>	<797cc39c0811272042m397d4e54h72fc4be7dac28865@mail.gmail.com>	<F744E289-EB3A-4757-BCB8-00A59AB1DB9E@macports.org>	<797cc39c0811280833w45be97epa058bba4a453c4d5@mail.gmail.com>	<49302141.1060208@macports.org>
	<797cc39c0811280948h90d0129p1411634779667a15@mail.gmail.com>
Message-ID: <49304AA5.10709@pogma.com>

Big O wrote:

> I think this is referring to shared libs. We want static libs with fPIC.
> 

pic is the default on Mac OS X, if you add --with-pic or --without-pic,
you should still get a static archive that can be used to create a
shared library. Was this an actual problem for someone on Mac OS X?

Peter
-- 
Peter O'Gorman
http://pogma.com

From illogical1 at gmail.com  Fri Nov 28 11:57:18 2008
From: illogical1 at gmail.com (Big O)
Date: Fri, 28 Nov 2008 14:57:18 -0500
Subject: [42620] trunk/dports/databases/mysql5-devel/Portfile
In-Reply-To: <135ED162-E087-44C9-8DB7-4B7E4ECDB4F4@macports.org>
References: <20081126214836.8C35C790F7E@beta.macosforge.org>
	<E08F70E8-56C2-4AE4-BF1D-B97CD0F7847E@macports.org>
	<797cc39c0811272042m397d4e54h72fc4be7dac28865@mail.gmail.com>
	<F744E289-EB3A-4757-BCB8-00A59AB1DB9E@macports.org>
	<797cc39c0811280833w45be97epa058bba4a453c4d5@mail.gmail.com>
	<135ED162-E087-44C9-8DB7-4B7E4ECDB4F4@macports.org>
Message-ID: <797cc39c0811281157k2e51c88fkcf566c5c9e40a55f@mail.gmail.com>

On Fri, Nov 28, 2008 at 2:27 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On Nov 28, 2008, at 10:33, Big O wrote:
>
>>> How did you know to use the --with-pic option, and what is the symptom of
>>> not using it?
>>
>> Discussion of this took place around september on the amarok-devel
>> mailing list. here's an excerpt
>> "By the way, forgot to mention that the "-fPIC or not -fPIC" debate is
>> irrelevant. Mysql's configure script has a --with-pic flag, so
>> packaging a PIC-enabled libmysqld is not screwing with the package
>> everyone uses, but adding a flexibility, suggested by mysql itself. On
>> the other hand, this flag is borked and does nothing for libmysqld,
>> but upstream agreed that it's their fault (see relevant mysql bug), so
>> it's package maintainers' responsibility to fix it downstream."
>> For any code going into a shared library -fPIC is required. Basically
>> libmysqld.a (static lib) is being linked to libamarok-sqlcollection.so
>>  (dynamic lib) and that's why we need -fPIC when creating libmysqld.a.
>> One downside of this is that the resulting shared lib is rather large
>> (especially when doing a universal build). Using -fpic instead might
>> solve this but I haven't tried and don't intend to.
>> The mailing list is private so I can't link to it here, but this
>> gentoo bug report provides more info as well, including how to build a
>> shared library which I tried and didn't get to work properly.
>> http://bugs.gentoo.org/show_bug.cgi?id=238487
>
> In that bug the Gentoo MySQL maintainer says that adding -fPIC is not a good
> idea:
>
> http://bugs.gentoo.org/show_bug.cgi?id=238487#c34
>
> He says building a shared library would be better, and I know shared
> libraries are greatly preferred over static ones on Mac OS X. So we should
> do that, if we can figure out how, or convince MySQL AB to do so in a future
> version of MySQL.
>
>
Yes building a shared lib would be better but this is what we have to
work with.
I tried creating a shared lib from the static one and failed. Please
feel free to try the fedora link in the BR. that links to a rpm spec
file where they build a shared lib from the static lib.
Mysql knows about the issue and scheduled the fix for 6.0. It was in
the first mysql bug report link.
The gentoo doesn't apply here since a) -fPIC is only turned in the
variant, b) the only people so far using it is me for amarok.
-- 
All your gmail are belong to us.

From blb at macports.org  Sat Nov 29 00:40:18 2008
From: blb at macports.org (Bryan Blackburn)
Date: Sat, 29 Nov 2008 01:40:18 -0700
Subject: 1.7.0 beta 1 tagged and ready to test
Message-ID: <20081129084018.GA505@ninagal.withay.com>

A 1.7.0 branch has been created [1] and a tag for 1.7.0 beta1 is available
for testing [2].  Considering the stability of trunk lately, this will
hopefully be the only beta and we can move to a release candidate soon,
barring issues.  When testing, be sure to check the 1.7.1 milestone [3] as
there are a few issues already known which have been moved to 1.7.1 so a
1.7.0 can be pushed out the door to finally (finally!) get people away from
the postflight and Tcl environment problems.

So everyone test it out, and be sure to have a look at the long list of
changes [4] since 1.6.0, as there are quite a few...

Bryan

[1] - <http://trac.macports.org/browser/branches/release_1_7>
[2] - <http://trac.macports.org/browser/tags/release_1_7_0-beta1> and
      <http://svn.macports.org/repository/macports/tags/release_1_7_0-beta1>
[3] - <http://trac.macports.org/milestone/MacPorts%201.7.1>
[4] - <http://trac.macports.org/browser/tags/release_1_7_0-beta1/base/ChangeLog>


From afb at macports.org  Sat Nov 29 01:20:43 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Sat, 29 Nov 2008 10:20:43 +0100
Subject: 1.7.0 beta 1 tagged and ready to test
In-Reply-To: <20081129084018.GA505@ninagal.withay.com>
References: <20081129084018.GA505@ninagal.withay.com>
Message-ID: <C7DA9D5D-0A7D-4854-BCA5-1D981FBD01C5@macports.org>

Bryan Blackburn wrote:

> So everyone test it out, and be sure to have a look at the long  
> list of
> changes [4] since 1.6.0, as there are quite a few...

I got this error while doing "port destroot" on a release_1_7 tarball:

error renaming "/opt/local/etc/macports/sources.conf" to "/opt/local/ 
etc/macports/sources.conf.mpsaved": file already exists
     while executing
"file rename ${sourcesConf} "${sourcesConf}.mpsaved""

It's wrong on several levels, since it does things outside of destroot ?


But once I removed the old backup file, it then built ok.
Should probably "file delete" any existing such .mpsaved ?

And it probably needs a MacPorts-1.7.0-beta1.dmg disk image
made to see any real (i.e. end user) beta testing, though ?

--anders


From jeremyhu at macports.org  Sat Nov 29 02:02:26 2008
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Sat, 29 Nov 2008 02:02:26 -0800
Subject: committing update to configure
Message-ID: <EA273077-9E89-4D9D-866B-0448DD5DBDB4@macports.org>

I had a small update to configure.ac that I wanted to push (below).  I  
decided to regen configure since it was made with an old version of  
autoconf that doesn't detect X11 properly.  I got an error from svn  
about inconsistent line ending style... I find it odd that svn:eol- 
style is set on a generated file, so I thought I'd satisfy by  
bewilderment by asking here... so... yeah, what's up with that?

--Jeremy



~/src/macports/trunk/base $ svn ci -m "Updated list of outdated os  
versions and rebuilt configure with newer autoconf that searches for  
X11 properly (looking for libX11.dylib instead of just libX11.so)"
Sending        base/configure
Sending        base/configure.ac
Transmitting file data .svn: Commit failed (details follow):
svn: While preparing '/Users/jeremy/src/macports/trunk/base/configure'  
for commit
svn: Inconsistent line ending style

~/src/macports/trunk/base $ svn pl configure
Properties on 'configure':
   svn:executable
   svn:keywords
   svn:eol-style

~/src/macports/trunk/base $ svn diff configure.ac
Index: configure.ac
===================================================================
--- configure.ac	(revision 42677)
+++ configure.ac	(working copy)
@@ -31,7 +31,7 @@
      AC_WARN(This version of Mac OS X is not supported)
      AC_WARN(Please upgrade at http://store.apple.com/)
      ;;
-  10.1.[[0-4]]|10.2.[[0-7]]|10.3.[[0-8]]|10.4.[[0-8]])
+  10.1.[[0-4]]|10.2.[[0-7]]|10.3.[[0-8]]|10.4.[[0-9]]|10.4.10|10.5. 
[[0-4]])
      AC_WARN(This version of Mac OS X is out of date)
      AC_WARN(Please run Software Update to update it)
      ;;



From jmr at macports.org  Sat Nov 29 07:35:12 2008
From: jmr at macports.org (Joshua Root)
Date: Sun, 30 Nov 2008 02:35:12 +1100
Subject: 1.7.0 beta 1 tagged and ready to test
In-Reply-To: <C7DA9D5D-0A7D-4854-BCA5-1D981FBD01C5@macports.org>
References: <20081129084018.GA505@ninagal.withay.com>
	<C7DA9D5D-0A7D-4854-BCA5-1D981FBD01C5@macports.org>
Message-ID: <49316130.5060805@macports.org>

Anders F Bj?rklund wrote:
> Bryan Blackburn wrote:
> 
>> So everyone test it out, and be sure to have a look at the long list of
>> changes [4] since 1.6.0, as there are quite a few...
> 
> I got this error while doing "port destroot" on a release_1_7 tarball:
> 
> error renaming "/opt/local/etc/macports/sources.conf" to
> "/opt/local/etc/macports/sources.conf.mpsaved": file already exists
>     while executing
> "file rename ${sourcesConf} "${sourcesConf}.mpsaved""
> 
> It's wrong on several levels, since it does things outside of destroot ?

Right, I guess we need a different makefile target that will install
without doing all the upgrade stuff.

Fixed the rename failure in r42683.

- Josh

From jmr at macports.org  Sat Nov 29 07:38:02 2008
From: jmr at macports.org (Joshua Root)
Date: Sun, 30 Nov 2008 02:38:02 +1100
Subject: 1.7.0 beta 1 tagged and ready to test
In-Reply-To: <C7DA9D5D-0A7D-4854-BCA5-1D981FBD01C5@macports.org>
References: <20081129084018.GA505@ninagal.withay.com>
	<C7DA9D5D-0A7D-4854-BCA5-1D981FBD01C5@macports.org>
Message-ID: <493161DA.6060705@macports.org>

Anders F Bj?rklund wrote:
> And it probably needs a MacPorts-1.7.0-beta1.dmg disk image
> made to see any real (i.e. end user) beta testing, though ?

@jmpp: I don't see any tarballs or dmgs for older rc/beta releases. Did
they never exist, or are they kept somewhere I'm not looking?

- Josh

From raimue at macports.org  Sat Nov 29 08:00:52 2008
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Sat, 29 Nov 2008 17:00:52 +0100
Subject: [42674] branches/release_1_7/base/
In-Reply-To: <20081129080925.8FFC57B9EFE@beta.macosforge.org>
References: <20081129080925.8FFC57B9EFE@beta.macosforge.org>
Message-ID: <49316734.5030205@macports.org>

blb at macports.org wrote:
> Revision
>     42674 <http://trac.macports.org/changeset/42674>
> Author
>     blb at macports.org
> Date
>     2008-11-29 00:09:22 -0800 (Sat, 29 Nov 2008)
> 
> 
>       Log Message
> 
> Initialized merge tracking via "svnmerge" with revisions "1-42672" from 
> https://svn.macports.org/repository/macports/trunk/base

As we got a Subversion server with version 1.5 now, shouldn't we use the
integrated merge tracking?

variants-descs-14482 was still using svnmerge.py as I started the branch
before 1.5 was available.

Rainer

From ryandesign at macports.org  Sat Nov 29 12:21:44 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 29 Nov 2008 14:21:44 -0600
Subject: [42693] trunk/dports/x11/xrender/Portfile
In-Reply-To: <20081129194306.95D6A7BE3DD@beta.macosforge.org>
References: <20081129194306.95D6A7BE3DD@beta.macosforge.org>
Message-ID: <49B382E5-F4C3-4390-870D-EB22F7A2272D@macports.org>

On Nov 29, 2008, at 13:43, jeremyhu at macports.org wrote:

> Revision: 42693
>           http://trac.macports.org/changeset/42693
> Author:   jeremyhu at macports.org
> Date:     2008-11-29 11:43:06 -0800 (Sat, 29 Nov 2008)
> Log Message:
> -----------
> Much needed update to libXrender

Indeed. Thank you!

> Modified Paths:
> --------------
>     trunk/dports/x11/xrender/Portfile
>
> Modified: trunk/dports/x11/xrender/Portfile
> ===================================================================
> --- trunk/dports/x11/xrender/Portfile	2008-11-29 19:15:44 UTC (rev  
> 42692)
> +++ trunk/dports/x11/xrender/Portfile	2008-11-29 19:43:06 UTC (rev  
> 42693)
> @@ -3,47 +3,47 @@
>  PortSystem			1.0
>
>  name				xrender
> -set my_name         libXrender
> -version				0.9.0
> -revision            3
> +set my_name			libXrender
> +version				0.9.4
> +revision			1

For future reference, note that the first revision of a particular  
version of a port should be 0, not 1; you can simply delete the  
revision line to achieve this. Don't change it now, but do keep it in  
mind for future updates.


>  configure.env \
> -    RENDER_CFLAGS=-I${prefix}/include \
> -    RENDER_LIBS=-L${prefix}/lib
> +    CPPFLAGS=-I${prefix}/include -I${x11prefix}/include \
> +    LDFLAGS=-L${prefix}/lib -L${x11prefix}/lib \
> +    PKG_CONFIG_PATH=${x11prefix}/lib/pkgconfig

Note that CPPFLAGS and LDFLAGS should not be put into the environment  
manually like this, but instead like this:

configure.cppflags-append -I${x11prefix}/include
configure.ldflags-append -L${x11prefix}/lib

-I${prefix}/include is already in the CPPFLAGS by default, and -L$ 
{prefix}/lib is already in the LDFLAGS by default, so you just need  
to append the new values.

And you shouldn't need to put ${x11prefix}/lib/pkgconfig into the  
PKG_CONFIG_PATH because it's already set properly for you as of two  
weeks ago; see:

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



From blb at macports.org  Sat Nov 29 13:16:39 2008
From: blb at macports.org (Bryan Blackburn)
Date: Sat, 29 Nov 2008 14:16:39 -0700
Subject: 1.7.0 beta 1 tagged and ready to test
In-Reply-To: <49316130.5060805@macports.org>
References: <20081129084018.GA505@ninagal.withay.com>
	<C7DA9D5D-0A7D-4854-BCA5-1D981FBD01C5@macports.org>
	<49316130.5060805@macports.org>
Message-ID: <20081129211639.GB525@ninagal.withay.com>

On Sun, Nov 30, 2008 at 02:35:12AM +1100, Joshua Root said:
> Anders F Bj?rklund wrote:
> > Bryan Blackburn wrote:
> > 
> >> So everyone test it out, and be sure to have a look at the long list of
> >> changes [4] since 1.6.0, as there are quite a few...
> > 
> > I got this error while doing "port destroot" on a release_1_7 tarball:
> > 
> > error renaming "/opt/local/etc/macports/sources.conf" to
> > "/opt/local/etc/macports/sources.conf.mpsaved": file already exists
> >     while executing
> > "file rename ${sourcesConf} "${sourcesConf}.mpsaved""
> > 
> > It's wrong on several levels, since it does things outside of destroot ?
> 
> Right, I guess we need a different makefile target that will install
> without doing all the upgrade stuff.

That script should really be running against DESTDIR, since it'll be a noop
against a new sources.conf.  But then it still does need to be run in
postflight.  Does the same go for dep_map_clean.tcl?

Bryan


> 
> Fixed the rename failure in r42683.
> 
> - Josh

From blb at macports.org  Sat Nov 29 13:18:32 2008
From: blb at macports.org (Bryan Blackburn)
Date: Sat, 29 Nov 2008 14:18:32 -0700
Subject: 1.7.0 beta 1 tagged and ready to test
In-Reply-To: <493161DA.6060705@macports.org>
References: <20081129084018.GA505@ninagal.withay.com>
	<C7DA9D5D-0A7D-4854-BCA5-1D981FBD01C5@macports.org>
	<493161DA.6060705@macports.org>
Message-ID: <20081129211832.GC525@ninagal.withay.com>

On Sun, Nov 30, 2008 at 02:38:02AM +1100, Joshua Root said:
> Anders F Bj?rklund wrote:
> > And it probably needs a MacPorts-1.7.0-beta1.dmg disk image
> > made to see any real (i.e. end user) beta testing, though ?
> 
> @jmpp: I don't see any tarballs or dmgs for older rc/beta releases. Did
> they never exist, or are they kept somewhere I'm not looking?

I checked and as far as I could tell, dmg's have always only been released
when a version was finalized; that's why I did this the same way, with the
svn tag only for now.

Though, given Anders' error, maybe we should add a step into the
ReleaseProcess that at least a dmg should be built before tagging, to test
for such things?

Bryan


> 
> - Josh

From jmr at macports.org  Sat Nov 29 13:20:34 2008
From: jmr at macports.org (Joshua Root)
Date: Sun, 30 Nov 2008 08:20:34 +1100
Subject: 1.7.0 beta 1 tagged and ready to test
In-Reply-To: <20081129211639.GB525@ninagal.withay.com>
References: <20081129084018.GA505@ninagal.withay.com>	<C7DA9D5D-0A7D-4854-BCA5-1D981FBD01C5@macports.org>	<49316130.5060805@macports.org>
	<20081129211639.GB525@ninagal.withay.com>
Message-ID: <4931B222.8050902@macports.org>

Bryan Blackburn wrote:
> On Sun, Nov 30, 2008 at 02:35:12AM +1100, Joshua Root said:
>> Anders F Bj?rklund wrote:
>>> Bryan Blackburn wrote:
>>>
>>>> So everyone test it out, and be sure to have a look at the long list of
>>>> changes [4] since 1.6.0, as there are quite a few...
>>> I got this error while doing "port destroot" on a release_1_7 tarball:
>>>
>>> error renaming "/opt/local/etc/macports/sources.conf" to
>>> "/opt/local/etc/macports/sources.conf.mpsaved": file already exists
>>>     while executing
>>> "file rename ${sourcesConf} "${sourcesConf}.mpsaved""
>>>
>>> It's wrong on several levels, since it does things outside of destroot ?
>> Right, I guess we need a different makefile target that will install
>> without doing all the upgrade stuff.
> 
> That script should really be running against DESTDIR, since it'll be a noop
> against a new sources.conf.  But then it still does need to be run in
> postflight.  Does the same go for dep_map_clean.tcl?

Yes, it's similarly useless to fix the dep_map in the MP install that is
building the package.

- Josh

From blb at macports.org  Sat Nov 29 13:20:43 2008
From: blb at macports.org (Bryan Blackburn)
Date: Sat, 29 Nov 2008 14:20:43 -0700
Subject: [42674] branches/release_1_7/base/
In-Reply-To: <49316734.5030205@macports.org>
References: <20081129080925.8FFC57B9EFE@beta.macosforge.org>
	<49316734.5030205@macports.org>
Message-ID: <20081129212043.GD525@ninagal.withay.com>

On Sat, Nov 29, 2008 at 05:00:52PM +0100, Rainer M?ller said:
> blb at macports.org wrote:
> > Revision
> >     42674 <http://trac.macports.org/changeset/42674>
> > Author
> >     blb at macports.org
> > Date
> >     2008-11-29 00:09:22 -0800 (Sat, 29 Nov 2008)
> > 
> > 
> >       Log Message
> > 
> > Initialized merge tracking via "svnmerge" with revisions "1-42672" from 
> > https://svn.macports.org/repository/macports/trunk/base
> 
> As we got a Subversion server with version 1.5 now, shouldn't we use the
> integrated merge tracking?

Good question, I know how to use svnmerge.py so it wasn't a big deal.
Haven't looked at all into the integrated stuff yet.  Obviously this would
require anyone to have svn from someplace other than the default since 10.5
has 1.4.4.

Bryan


> 
> variants-descs-14482 was still using svnmerge.py as I started the branch
> before 1.5 was available.
> 
> Rainer

From ryandesign at macports.org  Sat Nov 29 19:53:04 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 29 Nov 2008 21:53:04 -0600
Subject: [42686] trunk/dports/math/metis/Portfile
In-Reply-To: <20081129175409.034187BD944@beta.macosforge.org>
References: <20081129175409.034187BD944@beta.macosforge.org>
Message-ID: <CC16B3F3-EA53-42AC-95E5-8F10169E75A2@macports.org>

On Nov 29, 2008, at 11:54, mcalhoun at macports.org wrote:

> Revision: 42686
>           http://trac.macports.org/changeset/42686
> Author:   mcalhoun at macports.org
> Date:     2008-11-29 09:54:07 -0800 (Sat, 29 Nov 2008)
> Log Message:
> -----------
> metis: Ensure that the correct C compiler is used.
>
> Modified Paths:
> --------------
>     trunk/dports/math/metis/Portfile
>
> Modified: trunk/dports/math/metis/Portfile
> ===================================================================
> --- trunk/dports/math/metis/Portfile	2008-11-29 17:31:01 UTC (rev  
> 42685)
> +++ trunk/dports/math/metis/Portfile	2008-11-29 17:54:07 UTC (rev  
> 42686)
> @@ -23,6 +23,11 @@
>
>  build.target
>
> +post-configure {
> +	# ensure that the correct compiler is used
> +	build.args-append CC=${configure.cc}
> +}

That doesn't work if someone says

sudo port configure metis
sudo port install metis



From ryandesign at macports.org  Sat Nov 29 19:57:35 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 29 Nov 2008 21:57:35 -0600
Subject: [42678] trunk/dports/devel/automoc/Portfile
In-Reply-To: <20081129101821.DD3957BB157@beta.macosforge.org>
References: <20081129101821.DD3957BB157@beta.macosforge.org>
Message-ID: <66E5060A-C6D9-44F5-81D6-765C5C2F7E45@macports.org>

On Nov 29, 2008, at 04:18, illogic-al at macports.org wrote:

> Revision: 42678
>           http://trac.macports.org/changeset/42678
> Author:   illogic-al at macports.org
> Date:     2008-11-29 02:18:19 -0800 (Sat, 29 Nov 2008)
> Log Message:
> -----------
> Overlooked this while updating the other kde4 portfiles.
> With this all kde4 Portfiles should use distfiles and ${prefix}.
>
> Modified Paths:
> --------------
>     trunk/dports/devel/automoc/Portfile
>
> Modified: trunk/dports/devel/automoc/Portfile
> ===================================================================
> --- trunk/dports/devel/automoc/Portfile	2008-11-29 09:02:30 UTC  
> (rev 42677)
> +++ trunk/dports/devel/automoc/Portfile	2008-11-29 10:18:19 UTC  
> (rev 42678)
> @@ -3,39 +3,37 @@
>  PortSystem          1.0
>
>  name                automoc
> -version             0.9.87
> +version             0.9.84

If you really want to downgrade the version from 0.9.87 to 0.9.84,  
you need to increase the epoch. Since the port doesn't have an epoch  
line yet, its epoch is 0, so you should set it to at least 1 by  
writing "epoch 1". Note that that line can then never be removed from  
the portfile.


>  revision            1

Note that the first revision of a particular version of a port should  
be 0, not 1, and that you can achieve this by simply removing the  
revision line.


> +distname            ${name}-${version}
> +distfiles           ${distname}.tar.bz2

Note that there's no reason to write these two lines; those are the  
default already.


From ryandesign at macports.org  Sat Nov 29 20:06:43 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 29 Nov 2008 22:06:43 -0600
Subject: committing update to configure
In-Reply-To: <EA273077-9E89-4D9D-866B-0448DD5DBDB4@macports.org>
References: <EA273077-9E89-4D9D-866B-0448DD5DBDB4@macports.org>
Message-ID: <FEC038A2-7FCB-42F3-A7C5-3CEC544FFDF5@macports.org>


On Nov 29, 2008, at 04:02, Jeremy Huddleston wrote:

> I had a small update to configure.ac that I wanted to push (below).

Looks good to me.

> I decided to regen configure since it was made with an old version  
> of autoconf that doesn't detect X11 properly.

You should definitely regenerate configure after modifying  
configure.ac. However changing the version of autoconf used should be  
discussed first. In what way does the version of autoconf we've been  
using not detect X11 properly, and what is the implication of that  
improper detection?

> I got an error from svn about inconsistent line ending style... I  
> find it odd that svn:eol-style is set on a generated file, so I  
> thought I'd satisfy by bewilderment by asking here... so... yeah,  
> what's up with that?

I can't find the revision that change was made in so I don't know why  
it was done. On the other hand, why are the line endings in your  
newly generated configure script inconsistent?


> --Jeremy
>
>
>
> ~/src/macports/trunk/base $ svn ci -m "Updated list of outdated os  
> versions and rebuilt configure with newer autoconf that searches  
> for X11 properly (looking for libX11.dylib instead of just libX11.so)"
> Sending        base/configure
> Sending        base/configure.ac
> Transmitting file data .svn: Commit failed (details follow):
> svn: While preparing '/Users/jeremy/src/macports/trunk/base/ 
> configure' for commit
> svn: Inconsistent line ending style
>
> ~/src/macports/trunk/base $ svn pl configure
> Properties on 'configure':
>   svn:executable
>   svn:keywords
>   svn:eol-style
>
> ~/src/macports/trunk/base $ svn diff configure.ac
> Index: configure.ac
> ===================================================================
> --- configure.ac	(revision 42677)
> +++ configure.ac	(working copy)
> @@ -31,7 +31,7 @@
>      AC_WARN(This version of Mac OS X is not supported)
>      AC_WARN(Please upgrade at http://store.apple.com/)
>      ;;
> -  10.1.[[0-4]]|10.2.[[0-7]]|10.3.[[0-8]]|10.4.[[0-8]])
> +  10.1.[[0-4]]|10.2.[[0-7]]|10.3.[[0-8]]|10.4.[[0-9]]|10.4.10|10.5. 
> [[0-4]])
>      AC_WARN(This version of Mac OS X is out of date)
>      AC_WARN(Please run Software Update to update it)
>      ;;
>


From ryandesign at macports.org  Sat Nov 29 20:07:53 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 29 Nov 2008 22:07:53 -0600
Subject: [42674] branches/release_1_7/base/
In-Reply-To: <20081129212043.GD525@ninagal.withay.com>
References: <20081129080925.8FFC57B9EFE@beta.macosforge.org>
	<49316734.5030205@macports.org>
	<20081129212043.GD525@ninagal.withay.com>
Message-ID: <EB474425-4657-4C16-AC9A-B01D79990D7F@macports.org>


On Nov 29, 2008, at 15:20, Bryan Blackburn wrote:

> On Sat, Nov 29, 2008 at 05:00:52PM +0100, Rainer M?ller said:
>> blb at macports.org wrote:
>>> Revision
>>>     42674 <http://trac.macports.org/changeset/42674>
>>> Author
>>>     blb at macports.org
>>> Date
>>>     2008-11-29 00:09:22 -0800 (Sat, 29 Nov 2008)
>>>
>>>
>>>       Log Message
>>>
>>> Initialized merge tracking via "svnmerge" with revisions  
>>> "1-42672" from
>>> https://svn.macports.org/repository/macports/trunk/base
>>
>> As we got a Subversion server with version 1.5 now, shouldn't we  
>> use the
>> integrated merge tracking?
>
> Good question, I know how to use svnmerge.py so it wasn't a big deal.
> Haven't looked at all into the integrated stuff yet.  Obviously  
> this would
> require anyone to have svn from someplace other than the default  
> since 10.5
> has 1.4.4.

I don't see why anyone using MacPorts wouldn't use the MacPorts  
subversion since it's newer than what Mac OS X provides.



From blb at macports.org  Sat Nov 29 20:16:21 2008
From: blb at macports.org (Bryan Blackburn)
Date: Sat, 29 Nov 2008 21:16:21 -0700
Subject: committing update to configure
In-Reply-To: <FEC038A2-7FCB-42F3-A7C5-3CEC544FFDF5@macports.org>
References: <EA273077-9E89-4D9D-866B-0448DD5DBDB4@macports.org>
	<FEC038A2-7FCB-42F3-A7C5-3CEC544FFDF5@macports.org>
Message-ID: <20081130041621.GN525@ninagal.withay.com>

On Sat, Nov 29, 2008 at 10:06:43PM -0600, Ryan Schmidt said:
>
> On Nov 29, 2008, at 04:02, Jeremy Huddleston wrote:
>
>> I had a small update to configure.ac that I wanted to push (below).
>
> Looks good to me.
>
>> I decided to regen configure since it was made with an old version of 
>> autoconf that doesn't detect X11 properly.
>
> You should definitely regenerate configure after modifying configure.ac. 
> However changing the version of autoconf used should be discussed first. 
> In what way does the version of autoconf we've been using not detect X11 
> properly, and what is the implication of that improper detection?
>
>> I got an error from svn about inconsistent line ending style... I find 
>> it odd that svn:eol-style is set on a generated file, so I thought I'd 
>> satisfy by bewilderment by asking here... so... yeah, what's up with 
>> that?
>
> I can't find the revision that change was made in so I don't know why it 
> was done. On the other hand, why are the line endings in your newly 
> generated configure script inconsistent?

I ran into this as well with autoconf 2.63 when I updated trunk to 1.8;
autoconf 2.63 adds a variable, ac_cr, which is set to a Ctrl-M, and is
what I believe is confusing subversion.  Otherwise, the file itself is still
normal *nix-style line endings.

Bryan


>
>
>> --Jeremy
>>

From mcalhoun at macports.org  Sat Nov 29 20:19:32 2008
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Sun, 30 Nov 2008 04:19:32 +0000 (UTC)
Subject: [42686] trunk/dports/math/metis/Portfile
References: <20081129175409.034187BD944@beta.macosforge.org>
	<CC16B3F3-EA53-42AC-95E5-8F10169E75A2@macports.org>
Message-ID: <loom.20081130T041653-925@post.gmane.org>

Ryan Schmidt <ryandesign at ...> writes:


> That doesn't work if someone says
> 
> sudo port configure metis
> sudo port install metis

Thank you for pointing out my oversight.
It should be fixed in r42730 (http://trac.macports.org/changeset/42730).

-Marcus





From ryandesign at macports.org  Sat Nov 29 20:30:09 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 29 Nov 2008 22:30:09 -0600
Subject: committing update to configure
In-Reply-To: <20081130041621.GN525@ninagal.withay.com>
References: <EA273077-9E89-4D9D-866B-0448DD5DBDB4@macports.org>
	<FEC038A2-7FCB-42F3-A7C5-3CEC544FFDF5@macports.org>
	<20081130041621.GN525@ninagal.withay.com>
Message-ID: <649CA0FE-D773-4B9D-86F4-61C27043B431@macports.org>


On Nov 29, 2008, at 22:16, Bryan Blackburn wrote:

> On Sat, Nov 29, 2008 at 10:06:43PM -0600, Ryan Schmidt said:
>>
>> On Nov 29, 2008, at 04:02, Jeremy Huddleston wrote:
>>
>>> I had a small update to configure.ac that I wanted to push (below).
>>
>> Looks good to me.
>>
>>> I decided to regen configure since it was made with an old  
>>> version of
>>> autoconf that doesn't detect X11 properly.
>>
>> You should definitely regenerate configure after modifying  
>> configure.ac.
>> However changing the version of autoconf used should be discussed  
>> first.
>> In what way does the version of autoconf we've been using not  
>> detect X11
>> properly, and what is the implication of that improper detection?
>>
>>> I got an error from svn about inconsistent line ending style... I  
>>> find
>>> it odd that svn:eol-style is set on a generated file, so I  
>>> thought I'd
>>> satisfy by bewilderment by asking here... so... yeah, what's up with
>>> that?
>>
>> I can't find the revision that change was made in so I don't know  
>> why it
>> was done. On the other hand, why are the line endings in your newly
>> generated configure script inconsistent?
>
> I ran into this as well with autoconf 2.63 when I updated trunk to  
> 1.8;
> autoconf 2.63 adds a variable, ac_cr, which is set to a Ctrl-M, and is
> what I believe is confusing subversion.  Otherwise, the file itself  
> is still
> normal *nix-style line endings.

Ok, I figured it was something like that. Well, we can remove the  
property.


From ryandesign at macports.org  Sat Nov 29 20:41:45 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 29 Nov 2008 22:41:45 -0600
Subject: [42732] trunk/dports/x11/xrender/Portfile
In-Reply-To: <20081130043250.2945D7C6748@beta.macosforge.org>
References: <20081130043250.2945D7C6748@beta.macosforge.org>
Message-ID: <12D2A27E-F125-4A21-944F-7C2389BCA7F2@macports.org>

On Nov 29, 2008, at 22:32, mcalhoun at macports.org wrote:

> Revision: 42732
>           http://trac.macports.org/changeset/42732
> Author:   mcalhoun at macports.org
> Date:     2008-11-29 20:32:49 -0800 (Sat, 29 Nov 2008)
> Log Message:
> -----------
> xrender: workaround for lack of x11.pc and xproto.pc on Apple's X11  
> prior to XQuartz.
> Attempt to fix #17429.
> There is no revision increase because xrender either builds  
> correctly or not at all.

Thanks.


> -    set docdir ${prefix}/share/doc/${name}-${version}
> +    set docdir ${prefix}/share/doc/${name}

We had been on a push to switch ports from unversioned to versioned  
documentation directories. If you want to undo that now, it would be  
good to first discuss it on the list and reach a consensus, and then  
apply it consistently in all ports.


From blb at macports.org  Sat Nov 29 20:52:09 2008
From: blb at macports.org (Bryan Blackburn)
Date: Sat, 29 Nov 2008 21:52:09 -0700
Subject: [42732] trunk/dports/x11/xrender/Portfile
In-Reply-To: <12D2A27E-F125-4A21-944F-7C2389BCA7F2@macports.org>
References: <20081130043250.2945D7C6748@beta.macosforge.org>
	<12D2A27E-F125-4A21-944F-7C2389BCA7F2@macports.org>
Message-ID: <20081130045209.GP525@ninagal.withay.com>

On Sat, Nov 29, 2008 at 10:41:45PM -0600, Ryan Schmidt said:
> On Nov 29, 2008, at 22:32, mcalhoun at macports.org wrote:
>
>> Revision: 42732
>>           http://trac.macports.org/changeset/42732
>> Author:   mcalhoun at macports.org
>> Date:     2008-11-29 20:32:49 -0800 (Sat, 29 Nov 2008)
>> Log Message:
>> -----------
>> xrender: workaround for lack of x11.pc and xproto.pc on Apple's X11  
>> prior to XQuartz.
>> Attempt to fix #17429.
>> There is no revision increase because xrender either builds correctly or 
>> not at all.
>
> Thanks.
>
>
>> -    set docdir ${prefix}/share/doc/${name}-${version}
>> +    set docdir ${prefix}/share/doc/${name}
>
> We had been on a push to switch ports from unversioned to versioned  
> documentation directories. If you want to undo that now, it would be good 
> to first discuss it on the list and reach a consensus, and then apply it 
> consistently in all ports.

What was the reasoning for that?  Since only one version of a port can be
installed at one time, there shouldn't be any conflicts.  Appending the
version means that every upgrade moves the documentation...

Bryan


From ryandesign at macports.org  Sat Nov 29 20:59:05 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 29 Nov 2008 22:59:05 -0600
Subject: versioned documentation directory (Was: Re: [42732]
	trunk/dports/x11/xrender/Portfile)
In-Reply-To: <20081130045209.GP525@ninagal.withay.com>
References: <20081130043250.2945D7C6748@beta.macosforge.org>
	<12D2A27E-F125-4A21-944F-7C2389BCA7F2@macports.org>
	<20081130045209.GP525@ninagal.withay.com>
Message-ID: <2202D10E-07A0-4B36-8F8F-A6CBC72ABA7D@macports.org>

On Nov 29, 2008, at 22:52, Bryan Blackburn wrote:

> On Sat, Nov 29, 2008 at 10:41:45PM -0600, Ryan Schmidt said:
>> On Nov 29, 2008, at 22:32, mcalhoun at macports.org wrote:
>>
>>> Revision: 42732
>>>           http://trac.macports.org/changeset/42732
>>> Author:   mcalhoun at macports.org
>>> Date:     2008-11-29 20:32:49 -0800 (Sat, 29 Nov 2008)
>>> Log Message:
>>> -----------
>>> xrender: workaround for lack of x11.pc and xproto.pc on Apple's X11
>>> prior to XQuartz.
>>> Attempt to fix #17429.
>>> There is no revision increase because xrender either builds  
>>> correctly or
>>> not at all.
>>
>> Thanks.
>>
>>
>>> -    set docdir ${prefix}/share/doc/${name}-${version}
>>> +    set docdir ${prefix}/share/doc/${name}
>>
>> We had been on a push to switch ports from unversioned to versioned
>> documentation directories. If you want to undo that now, it would  
>> be good
>> to first discuss it on the list and reach a consensus, and then  
>> apply it
>> consistently in all ports.
>
> What was the reasoning for that?  Since only one version of a port  
> can be
> installed at one time, there shouldn't be any conflicts.  Appending  
> the
> version means that every upgrade moves the documentation...

I believe it was Anthony's initiative.

From mcalhoun at macports.org  Sat Nov 29 21:21:48 2008
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Sun, 30 Nov 2008 05:21:48 +0000 (UTC)
Subject: [42732] trunk/dports/x11/xrender/Portfile
References: <20081130043250.2945D7C6748@beta.macosforge.org>
	<12D2A27E-F125-4A21-944F-7C2389BCA7F2@macports.org>
Message-ID: <loom.20081130T051418-458@post.gmane.org>

Ryan Schmidt <ryandesign at ...> writes:

> We had been on a push to switch ports from unversioned to versioned  
> documentation directories. If you want to undo that now, it would be  
> good to first discuss it on the list and reach a consensus, and then  
> apply it consistently in all ports.

I must have missed this discussion.
The versioned documentation for xrender has been restored in r42735
(http://trac.macports.org/changeset/42735).

For what its worth, I prefer the unversioned directories so I do not have to
update any bookmarks to html documents when I upgrade a port.

-Marcus





From blb at macports.org  Sat Nov 29 21:25:53 2008
From: blb at macports.org (Bryan Blackburn)
Date: Sat, 29 Nov 2008 22:25:53 -0700
Subject: [42674] branches/release_1_7/base/
In-Reply-To: <EB474425-4657-4C16-AC9A-B01D79990D7F@macports.org>
References: <20081129080925.8FFC57B9EFE@beta.macosforge.org>
	<49316734.5030205@macports.org>
	<20081129212043.GD525@ninagal.withay.com>
	<EB474425-4657-4C16-AC9A-B01D79990D7F@macports.org>
Message-ID: <20081130052553.GT525@ninagal.withay.com>

On Sat, Nov 29, 2008 at 10:07:53PM -0600, Ryan Schmidt said:
>
> On Nov 29, 2008, at 15:20, Bryan Blackburn wrote:
>
>> On Sat, Nov 29, 2008 at 05:00:52PM +0100, Rainer M?ller said:
>>> blb at macports.org wrote:
>>>> Revision
>>>>     42674 <http://trac.macports.org/changeset/42674>
>>>> Author
>>>>     blb at macports.org
>>>> Date
>>>>     2008-11-29 00:09:22 -0800 (Sat, 29 Nov 2008)
>>>>
>>>>
>>>>       Log Message
>>>>
>>>> Initialized merge tracking via "svnmerge" with revisions "1-42672" 
>>>> from
>>>> https://svn.macports.org/repository/macports/trunk/base
>>>
>>> As we got a Subversion server with version 1.5 now, shouldn't we use 
>>> the
>>> integrated merge tracking?
>>
>> Good question, I know how to use svnmerge.py so it wasn't a big deal.
>> Haven't looked at all into the integrated stuff yet.  Obviously this 
>> would
>> require anyone to have svn from someplace other than the default since 
>> 10.5
>> has 1.4.4.
>
> I don't see why anyone using MacPorts wouldn't use the MacPorts  
> subversion since it's newer than what Mac OS X provides.

FYI, since Josh used 'svn merge' for a couple of bits [1,2], I have as well
[3]; fortunately it isn't all that different from svnmerge.py, but doesn't
appear to need to do an init like svnmerge.py.

So at this point use 'svn merge' instead, as I'm sure that
svnmerge-integrated property is now out of date.

Bryan

[1] - <http://trac.macports.org/changeset/42684>
[2] - <http://trac.macports.org/changeset/42698>
[3] - <http://trac.macports.org/changeset/42736>


From afb at macports.org  Sun Nov 30 02:15:28 2008
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Sun, 30 Nov 2008 11:15:28 +0100
Subject: 1.7.0 beta 1 tagged and ready to test
In-Reply-To: <20081129211832.GC525@ninagal.withay.com>
References: <20081129084018.GA505@ninagal.withay.com>
	<C7DA9D5D-0A7D-4854-BCA5-1D981FBD01C5@macports.org>
	<493161DA.6060705@macports.org>
	<20081129211832.GC525@ninagal.withay.com>
Message-ID: <DAC56707-A3FE-4423-802D-1993CEF15230@macports.org>

Bryan Blackburn wrote:

> On Sun, Nov 30, 2008 at 02:38:02AM +1100, Joshua Root said:
>> Anders F Bj?rklund wrote:
>>> And it probably needs a MacPorts-1.7.0-beta1.dmg disk image
>>> made to see any real (i.e. end user) beta testing, though ?
>>
>> @jmpp: I don't see any tarballs or dmgs for older rc/beta  
>> releases. Did
>> they never exist, or are they kept somewhere I'm not looking?
>
> I checked and as far as I could tell, dmg's have always only been  
> released
> when a version was finalized; that's why I did this the same way,  
> with the
> svn tag only for now.

Some of the earlier "unofficial" tarballs are in
http://trac.macports.org/browser/distfiles/MacPorts/

But QA testing packagings should go somewhere else,
to clearly separate from the "release" versions... ?

> Though, given Anders' error, maybe we should add a step into the
> ReleaseProcess that at least a dmg should be built before tagging,  
> to test
> for such things?

Judging from MacPorts 1.6.0 dmg, probably a good idea.

That the MacPorts installation doesn't respect any
chroot/DESTDIR and requires admin/root privileges
shouldn't stop the release, though, as it's mostly
something "wrong" and can be worked around / lived with.

At least that was the way it has been handled earlier.

--anders


From jmr at macports.org  Sun Nov 30 08:02:01 2008
From: jmr at macports.org (Joshua Root)
Date: Mon, 01 Dec 2008 03:02:01 +1100
Subject: [42747] trunk/base/src/macports1.0/macports.tcl
In-Reply-To: <20081130152003.AEE637C9DC4@beta.macosforge.org>
References: <20081130152003.AEE637C9DC4@beta.macosforge.org>
Message-ID: <4932B8F9.1050808@macports.org>

simon at macports.org wrote:
> Revision: 42747
>           http://trac.macports.org/changeset/42747
> Author:   simon at macports.org
> Date:     2008-11-30 07:20:02 -0800 (Sun, 30 Nov 2008)
> Log Message:
> -----------
> base/src: Make sure the default port source is specified.
> 
> Modified Paths:
> --------------
>     trunk/base/src/macports1.0/macports.tcl
> 
> Modified: trunk/base/src/macports1.0/macports.tcl
> ===================================================================
> --- trunk/base/src/macports1.0/macports.tcl	2008-11-30 15:01:19 UTC (rev 42746)
> +++ trunk/base/src/macports1.0/macports.tcl	2008-11-30 15:20:02 UTC (rev 42747)
> @@ -432,6 +432,13 @@
>              }
>          }
>      }
> +    # Make sure the default port source is defined. Otherwise
> +    # [macports::getportresourcepath] fails when the first source doesn't
> +    # contain _resources.
> +    if {![info exists sources_default]} {
> +        return -code error "No default port source specified in $sources_conf"
> +    }
> +
>      if {![info exists sources]} {
>          if {[file isdirectory ports]} {
>              set sources "file://[pwd]/ports"

Presumably you discovered this the hard way? Is there a problem with the
upgrade script, or was this the result of a manual edit?

- Josh

From ram at macports.org  Sun Nov 30 08:41:05 2008
From: ram at macports.org (Adam Mercer)
Date: Sun, 30 Nov 2008 10:41:05 -0600
Subject: [42751] branches/release_1_7
In-Reply-To: <20081130160911.416FB7CA7CF@beta.macosforge.org>
References: <20081130160911.416FB7CA7CF@beta.macosforge.org>
Message-ID: <799406d60811300841w5e5459c4i2ce44be1be014fea@mail.gmail.com>

On Sun, Nov 30, 2008 at 10:09,  <jmr at macports.org> wrote:
> Revision 42751 Author jmr at macports.org Date 2008-11-30 08:09:10 -0800 (Sun,
> 30 Nov 2008)
>
> Log Message
>
> Merge r42747 from trunk:
>     Make sure the default port source is specified.
>
> Modified Paths
>
> branches/release_1_7/base/src/macports1.0/macports.tcl
>
> Property Changed
>
> branches/release_1_7/
>
> Diff
>
> Property changes: branches/release_1_7
>
> Modified: svn:mergeinfo
>
> + /trunk:42683,42697,42734,42747
>
> Modified: branches/release_1_7/base/src/macports1.0/macports.tcl (42750 =>
> 42751)
>
> --- branches/release_1_7/base/src/macports1.0/macports.tcl	2008-11-30
> 16:05:26 UTC (rev 42750)
> +++ branches/release_1_7/base/src/macports1.0/macports.tcl	2008-11-30
> 16:09:10 UTC (rev 42751)
> @@ -432,6 +432,13 @@
>              }
>          }
>      }
> +    # Make sure the default port source is defined. Otherwise
> +    # [macports::getportresourcepath] fails when the first source doesn't
> +    # contain _resources.
> +    if {![info exists sources_default]} {
> +        return -code error "No default port source specified in
> $sources_conf"
> +    }
> +
>      if {![info exists sources]} {
>          if {[file isdirectory ports]} {
>              set sources "file://[pwd]/ports"

This seems to be failing from me. When installing base from the
release_1_7 branch at r42751 I get the following error:

<snip>
/usr/bin/tclsh src/dep_map_clean.tcl /Library/Tcl
No default port source specified in /opt/local/etc/macports/sources.conf
    while executing
"mportinit"
    (file "src/dep_map_clean.tcl" line 12)
make: *** [install] Error 1
[ram at cizin base]$ cat /opt/local/etc/macports/sources.conf
#rsync://rsync.macports.org/release/ports/
file:///Users/ram/opt/macports [nosync]
[ram at cizin base]$

Comment lines clipped for clarity. Looking at the code this seems to
be failing because it thinks there is no _resources directory in the
first souces link (which is a svn checkout), but there is:

[ram at cizin base]$ ls -l /Users/ram/opt/macports/_resources/
total 0
drwxr-xr-x  6 ram  staff  204 29 Nov 09:41 port1.0
[ram at cizin base]$

Any idea why base is complianing this directory doesn't exist when it does?

Cheers

Adam

From jmr at macports.org  Sun Nov 30 08:59:03 2008
From: jmr at macports.org (Joshua Root)
Date: Mon, 01 Dec 2008 03:59:03 +1100
Subject: [42751] branches/release_1_7
In-Reply-To: <799406d60811300841w5e5459c4i2ce44be1be014fea@mail.gmail.com>
References: <20081130160911.416FB7CA7CF@beta.macosforge.org>
	<799406d60811300841w5e5459c4i2ce44be1be014fea@mail.gmail.com>
Message-ID: <4932C657.4010602@macports.org>

Adam Mercer wrote:
> <snip>
> /usr/bin/tclsh src/dep_map_clean.tcl /Library/Tcl
> No default port source specified in /opt/local/etc/macports/sources.conf
>     while executing
> "mportinit"
>     (file "src/dep_map_clean.tcl" line 12)
> make: *** [install] Error 1
> [ram at cizin base]$ cat /opt/local/etc/macports/sources.conf
> #rsync://rsync.macports.org/release/ports/
> file:///Users/ram/opt/macports [nosync]
> [ram at cizin base]$
> 
> Comment lines clipped for clarity. Looking at the code this seems to
> be failing because it thinks there is no _resources directory in the
> first souces link (which is a svn checkout), but there is:
> 
> [ram at cizin base]$ ls -l /Users/ram/opt/macports/_resources/
> total 0
> drwxr-xr-x  6 ram  staff  204 29 Nov 09:41 port1.0
> [ram at cizin base]$
> 
> Any idea why base is complianing this directory doesn't exist when it does?

It's actually failing because sources.conf doesn't have an entry with a
[default] tag. Fixed in r42760 and merged to branch in r42761.

- Josh

From simon at ruderich.org  Sun Nov 30 09:03:47 2008
From: simon at ruderich.org (Simon Ruderich)
Date: Sun, 30 Nov 2008 18:03:47 +0100
Subject: [42747] trunk/base/src/macports1.0/macports.tcl
In-Reply-To: <4932B8F9.1050808@macports.org>
References: <20081130152003.AEE637C9DC4@beta.macosforge.org>
	<4932B8F9.1050808@macports.org>
Message-ID: <20081130170347.GA23598@ruderich.org>

On Mon, Dec 01, 2008 at 03:02:01AM +1100, Joshua Root wrote:
> Presumably you discovered this the hard way? Is there a problem with the
> upgrade script, or was this the result of a manual edit?
>
> - Josh

This was the result of a manual edit. I'm using a custom sources.conf and
forgot to use [default]. It did work before but when I updated to the latest
version I got an error that $sources_default wasn't defined.

So don't worry, no problem with the upgrade script ;-)

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/20081130/7a88623d/attachment.bin>

From simon at ruderich.org  Sun Nov 30 09:44:06 2008
From: simon at ruderich.org (Simon Ruderich)
Date: Sun, 30 Nov 2008 18:44:06 +0100
Subject: [42751] branches/release_1_7
In-Reply-To: <799406d60811300841w5e5459c4i2ce44be1be014fea@mail.gmail.com>
References: <20081130160911.416FB7CA7CF@beta.macosforge.org>
	<799406d60811300841w5e5459c4i2ce44be1be014fea@mail.gmail.com>
Message-ID: <20081130174406.GB23598@ruderich.org>

On Sun, Nov 30, 2008 at 10:41:05AM -0600, Adam Mercer wrote:
> [snip]
>
> [ram at cizin base]$ cat /opt/local/etc/macports/sources.conf
> #rsync://rsync.macports.org/release/ports/
> file:///Users/ram/opt/macports [nosync]
> [ram at cizin base]$
>
> [snip]
>
> Any idea why base is complianing this directory doesn't exist when it does?
>
> Cheers
>
> Adam

The problem is that you don't have a [default] port in your sources.conf. Then
MacPorts fails sometimes because of a missing $sources_default in
[macports::getportresourcepath] (see my other mail). Thats why I committed
this change so the problem can be easily found.

Now I think it would be better to just issue a warning if no [default] is
there and use the first source as default. I attached the change as patch
default.diff. It also fixes the problem when no sources are defined at all but
a directory "ports" exists.

But maybe the best way would be to try to find the resource in all sources
(default first).

I just saw r42760 [1] and the question is if my patch should be committed or
not. It maybe useful to people who change their sources.conf later or have it
in a custom place but otherwise it's not necessary (except for the ports fix).
Please tell me if it should be committed.

Thanks,
Simon

[1]: http://trac.macports.org/changeset/42760
-- 
+ privacy is necessary
+ using http://gnupg.org
+ public key id: 0x6115F804EFB33229
-------------- next part --------------
diff --git a/base/src/macports1.0/macports.tcl b/base/src/macports1.0/macports.tcl
index 170ce0d..60a78fd 100644
--- a/base/src/macports1.0/macports.tcl
+++ b/base/src/macports1.0/macports.tcl
@@ -432,19 +432,23 @@ proc mportinit {{up_ui_options {}} {up_options {}} {up_variations {}}} {
             }
         }
     }
-    # Make sure the default port source is defined. Otherwise
-    # [macports::getportresourcepath] fails when the first source doesn't
-    # contain _resources.
-    if {![info exists sources_default]} {
-        return -code error "No default port source specified in $sources_conf"
-    }
 
+    # If no sources are defined try to use the "ports" directory in pwd as
+    # source.
     if {![info exists sources]} {
         if {[file isdirectory ports]} {
             set sources "file://[pwd]/ports"
+            set sources_default [concat [list $sources] [list default]]
         } else {
             return -code error "No sources defined in $sources_conf"
         }
+    # If no default source was defined in sources.conf use the first source
+    # as default and issue an error. This prevents an 'can't read
+    # "sources_default"' error in [macports::getportresourcepath] if the
+    # requested resource doesn't exist (in this source).
+    } elseif {![info exists sources_default]} {
+        set sources_default [lindex $sources 0]
+        ui_error "$sources_default specifies no default source."
     }
 
     if {[info exists variants_conf]} {
-------------- 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/20081130/0ccfbeb6/attachment.bin>

From simon at ruderich.org  Sun Nov 30 09:47:53 2008
From: simon at ruderich.org (Simon Ruderich)
Date: Sun, 30 Nov 2008 18:47:53 +0100
Subject: [42747] trunk/base/src/macports1.0/macports.tcl
In-Reply-To: <20081130170347.GA23598@ruderich.org>
References: <20081130152003.AEE637C9DC4@beta.macosforge.org>
	<4932B8F9.1050808@macports.org>
	<20081130170347.GA23598@ruderich.org>
Message-ID: <20081130174753.GC23598@ruderich.org>

On Sun, Nov 30, 2008 at 06:03:47PM +0100, Simon Ruderich wrote:
> So don't worry, no problem with the upgrade script ;-)
>
> Simon

> This seems to be failing from me. When installing base from the
> release_1_7 branch at r42751 I get the following error:
> 
> <snip>
> /usr/bin/tclsh src/dep_map_clean.tcl /Library/Tcl
> No default port source specified in /opt/local/etc/macports/sources.conf
>     while executing
> "mportinit"
>     (file "src/dep_map_clean.tcl" line 12)
> make: *** [install] Error 1
> [ram at cizin base]$ cat /opt/local/etc/macports/sources.conf
> #rsync://rsync.macports.org/release/ports/
> file:///Users/ram/opt/macports [nosync]
> [ram at cizin base]$

Well, I was wrong, but you fixed 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/20081130/60c77bf0/attachment.bin>

From ram at macports.org  Sun Nov 30 10:12:09 2008
From: ram at macports.org (Adam Mercer)
Date: Sun, 30 Nov 2008 12:12:09 -0600
Subject: [42751] branches/release_1_7
In-Reply-To: <4932C657.4010602@macports.org>
References: <20081130160911.416FB7CA7CF@beta.macosforge.org>
	<799406d60811300841w5e5459c4i2ce44be1be014fea@mail.gmail.com>
	<4932C657.4010602@macports.org>
Message-ID: <799406d60811301012u7cf04346j6c070a1a74b06f4a@mail.gmail.com>

On Sun, Nov 30, 2008 at 10:59, Joshua Root <jmr at macports.org> wrote:

> It's actually failing because sources.conf doesn't have an entry with a
> [default] tag. Fixed in r42760 and merged to branch in r42761.

Thanks Josh

Cheers

Adam

From jeremyhu at macports.org  Sun Nov 30 11:02:16 2008
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Sun, 30 Nov 2008 11:02:16 -0800
Subject: committing update to configure
In-Reply-To: <FEC038A2-7FCB-42F3-A7C5-3CEC544FFDF5@macports.org>
References: <EA273077-9E89-4D9D-866B-0448DD5DBDB4@macports.org>
	<FEC038A2-7FCB-42F3-A7C5-3CEC544FFDF5@macports.org>
Message-ID: <FA2461C9-D591-4BDB-B825-7DC044E2A52C@macports.org>


On Nov 29, 2008, at 20:06, Ryan Schmidt wrote:

>> I decided to regen configure since it was made with an old version  
>> of autoconf that doesn't detect X11 properly.
>
> You should definitely regenerate configure after modifying  
> configure.ac. However changing the version of autoconf used should  
> be discussed first. In what way does the version of autoconf we've  
> been using not detect X11 properly, and what is the implication of  
> that improper detection?

The older version of autoconf searches for libX11.so to find X11, but  
it should be searching for libX11.dylib :

# With the configure generated by the newer autoconf:
~/src/macports/trunk/base $ grep dylib configure
     for ac_extension in a so sl dylib la dll; do
   for ac_extension in a so sl dylib la dll; do


From ryandesign at macports.org  Sun Nov 30 11:51:55 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 30 Nov 2008 13:51:55 -0600
Subject: [42769] trunk/dports/devel/rlog
In-Reply-To: <20081130194454.50A977CC16A@beta.macosforge.org>
References: <20081130194454.50A977CC16A@beta.macosforge.org>
Message-ID: <9B9EB0DE-CF90-4D2A-8945-E4A64A439D26@macports.org>


On Nov 30, 2008, at 13:44, toby at macports.org wrote:

> Revision: 42769
>           http://trac.macports.org/changeset/42769
> Author:   toby at macports.org
> Date:     2008-11-30 11:44:53 -0800 (Sun, 30 Nov 2008)
> Log Message:
> -----------
> rlog 1.4, fixes #17430

Thank you for all the work you've been doing to update ports lately,  
but do note that we have a policy of allowing 72 hours for the  
maintainer of a port to react to a ticket; after that time, it's fine  
to commit changes, but until then, please allow the maintainer an  
opportunity to respond. If the maintainer already gave approval for  
this update to be committed, it helps to indicate that in the commit  
message and/or ticket note so there's no confusion.


From ryandesign at macports.org  Sun Nov 30 11:52:29 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 30 Nov 2008 13:52:29 -0600
Subject: committing update to configure
In-Reply-To: <FA2461C9-D591-4BDB-B825-7DC044E2A52C@macports.org>
References: <EA273077-9E89-4D9D-866B-0448DD5DBDB4@macports.org>
	<FEC038A2-7FCB-42F3-A7C5-3CEC544FFDF5@macports.org>
	<FA2461C9-D591-4BDB-B825-7DC044E2A52C@macports.org>
Message-ID: <F4B4D303-2FCC-4BD8-840C-38F90A1D7115@macports.org>

On Nov 30, 2008, at 13:02, Jeremy Huddleston wrote:

> On Nov 29, 2008, at 20:06, Ryan Schmidt wrote:
>
>>> I decided to regen configure since it was made with an old  
>>> version of autoconf that doesn't detect X11 properly.
>>
>> You should definitely regenerate configure after modifying  
>> configure.ac. However changing the version of autoconf used should  
>> be discussed first. In what way does the version of autoconf we've  
>> been using not detect X11 properly, and what is the implication of  
>> that improper detection?
>
> The older version of autoconf searches for libX11.so to find X11,  
> but it should be searching for libX11.dylib :
>
> # With the configure generated by the newer autoconf:
> ~/src/macports/trunk/base $ grep dylib configure
>     for ac_extension in a so sl dylib la dll; do
>   for ac_extension in a so sl dylib la dll; do

Doesn't that mean that MacPorts has thus never detected X11  
correctly, and therefore that it really hasn't mattered?


From jmr at macports.org  Sun Nov 30 12:24:34 2008
From: jmr at macports.org (Joshua Root)
Date: Mon, 01 Dec 2008 07:24:34 +1100
Subject: committing update to configure
In-Reply-To: <F4B4D303-2FCC-4BD8-840C-38F90A1D7115@macports.org>
References: <EA273077-9E89-4D9D-866B-0448DD5DBDB4@macports.org>	<FEC038A2-7FCB-42F3-A7C5-3CEC544FFDF5@macports.org>	<FA2461C9-D591-4BDB-B825-7DC044E2A52C@macports.org>
	<F4B4D303-2FCC-4BD8-840C-38F90A1D7115@macports.org>
Message-ID: <4932F682.5080803@macports.org>

Ryan Schmidt wrote:
> On Nov 30, 2008, at 13:02, Jeremy Huddleston wrote:
> 
>> On Nov 29, 2008, at 20:06, Ryan Schmidt wrote:
>>
>>>> I decided to regen configure since it was made with an old version
>>>> of autoconf that doesn't detect X11 properly.
>>>
>>> You should definitely regenerate configure after modifying
>>> configure.ac. However changing the version of autoconf used should be
>>> discussed first. In what way does the version of autoconf we've been
>>> using not detect X11 properly, and what is the implication of that
>>> improper detection?
>>
>> The older version of autoconf searches for libX11.so to find X11, but
>> it should be searching for libX11.dylib :
>>
>> # With the configure generated by the newer autoconf:
>> ~/src/macports/trunk/base $ grep dylib configure
>>     for ac_extension in a so sl dylib la dll; do
>>   for ac_extension in a so sl dylib la dll; do
> 
> Doesn't that mean that MacPorts has thus never detected X11 correctly,
> and therefore that it really hasn't mattered?

It works on Darwin <= 9 because MP_CHECK_X11 in aclocal.m4 has some
special cases.

- Josh

From neil at voidfx.net  Sun Nov 30 13:40:38 2008
From: neil at voidfx.net (Neil)
Date: Sun, 30 Nov 2008 16:40:38 -0500
Subject: Install Order
Message-ID: <A653C70C-BB8A-4336-8115-CE49E100985F@voidfx.net>

(Stolen from Ryan Schmidt's mail on 29 Nov 2008, at 14:48.)

Order of Operations to Install
      1  fetch
      2  checksum
      3  extract
      4  patch
      5  configure
      6  build
      7  destroot
      8  install
      9  deactivate
     10  activate
     11  clean

(I'm kind of thinking out loud here...)

Proposal:
What if we changed the order slightly, so we do steps 1-7 for all the  
packages first, and then, if there are no errors, do 8-11?

"Why?":
Suppose we have pkg2 which depends on pkg1.  If they both build fine,  
then we're dandy.  But if pkg2 fails, pkg1 is still installed.  If  
there are a lot of dependencies, it can be a pain to track them down.   
If we separate the steps into two phases, then most breaks during the  
installation (which mostly happen during 5-6, I think) won't leave  
unneeded ports on the system (at least not after a clean command).

Thoughts?


From raimue at macports.org  Sun Nov 30 14:46:55 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sun, 30 Nov 2008 23:46:55 +0100
Subject: Install Order
In-Reply-To: <A653C70C-BB8A-4336-8115-CE49E100985F@voidfx.net>
References: <A653C70C-BB8A-4336-8115-CE49E100985F@voidfx.net>
Message-ID: <493317DF.4050701@macports.org>

Neil wrote:
> (Stolen from Ryan Schmidt's mail on 29 Nov 2008, at 14:48.)
> 
> Order of Operations to Install
>       1  fetch
>       2  checksum
>       3  extract
>       4  patch
>       5  configure
>       6  build
>       7  destroot
>       8  install
>       9  deactivate
>      10  activate
>      11  clean
> 
> (I'm kind of thinking out loud here...)
> 
> Proposal:
> What if we changed the order slightly, so we do steps 1-7 for all the  
> packages first, and then, if there are no errors, do 8-11?

This is not possible, because dependencies have to be installed and
active or they cannot be used on building dependents.

Rainer


From neil at voidfx.net  Sun Nov 30 14:50:52 2008
From: neil at voidfx.net (Neil)
Date: Sun, 30 Nov 2008 17:50:52 -0500
Subject: Install Order
In-Reply-To: <493317C4.4060100@codingfarm.de>
References: <A653C70C-BB8A-4336-8115-CE49E100985F@voidfx.net>
	<493317C4.4060100@codingfarm.de>
Message-ID: <53370062-6682-455E-9632-2968554E86B8@voidfx.net>


On 30 Nov 2008, at 17:46, Rainer M?ller wrote:

> Neil wrote:
>> (Stolen from Ryan Schmidt's mail on 29 Nov 2008, at 14:48.)
>>
>> Order of Operations to Install
>>      1  fetch
>>      2  checksum
>>      3  extract
>>      4  patch
>>      5  configure
>>      6  build
>>      7  destroot
>>      8  install
>>      9  deactivate
>>     10  activate
>>     11  clean
>>
>> (I'm kind of thinking out loud here...)
>>
>> Proposal:
>> What if we changed the order slightly, so we do steps 1-7 for all the
>> packages first, and then, if there are no errors, do 8-11?
>
> This is not possible, because dependencies have to be installed and
> active or they cannot be used on building dependents.

Well, never mind then.  :P

Does MacPorts keep track of which ports were installed explicitly and  
which were installed as deps?


From raimue at macports.org  Sun Nov 30 14:52:53 2008
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sun, 30 Nov 2008 23:52:53 +0100
Subject: Install Order
In-Reply-To: <53370062-6682-455E-9632-2968554E86B8@voidfx.net>
References: <A653C70C-BB8A-4336-8115-CE49E100985F@voidfx.net>
	<493317C4.4060100@codingfarm.de>
	<53370062-6682-455E-9632-2968554E86B8@voidfx.net>
Message-ID: <49331945.90600@macports.org>

Neil wrote:
> Does MacPorts keep track of which ports were installed explicitly and  
> which were installed as deps?

No, not yet. See http://trac.macports.org/ticket/15260

Rainer


From jmr at macports.org  Sun Nov 30 14:53:33 2008
From: jmr at macports.org (Joshua Root)
Date: Mon, 01 Dec 2008 09:53:33 +1100
Subject: Install Order
In-Reply-To: <A653C70C-BB8A-4336-8115-CE49E100985F@voidfx.net>
References: <A653C70C-BB8A-4336-8115-CE49E100985F@voidfx.net>
Message-ID: <4933196D.2090007@macports.org>

Neil wrote:
> (Stolen from Ryan Schmidt's mail on 29 Nov 2008, at 14:48.)
> 
> Order of Operations to Install
>      1  fetch
>      2  checksum
>      3  extract
>      4  patch
>      5  configure
>      6  build
>      7  destroot
>      8  install
>      9  deactivate
>     10  activate
>     11  clean
> 
> (I'm kind of thinking out loud here...)
> 
> Proposal:
> What if we changed the order slightly, so we do steps 1-7 for all the
> packages first, and then, if there are no errors, do 8-11?
> 
> "Why?":
> Suppose we have pkg2 which depends on pkg1.  If they both build fine,
> then we're dandy.  But if pkg2 fails, pkg1 is still installed.  If there
> are a lot of dependencies, it can be a pain to track them down.  If we
> separate the steps into two phases, then most breaks during the
> installation (which mostly happen during 5-6, I think) won't leave
> unneeded ports on the system (at least not after a clean command).
> 
> Thoughts?

<http://trac.macports.org/ticket/15260> is a proposal for a more general
way of handling the unneeded dependency problem.

Also, if pkg2 depends on pkg1, then usually pkg1 has to be active for
pkg2 to build.

- Josh

From ryandesign at macports.org  Sun Nov 30 21:15:53 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 30 Nov 2008 23:15:53 -0600
Subject: committing update to configure
In-Reply-To: <4932F682.5080803@macports.org>
References: <EA273077-9E89-4D9D-866B-0448DD5DBDB4@macports.org>	<FEC038A2-7FCB-42F3-A7C5-3CEC544FFDF5@macports.org>	<FA2461C9-D591-4BDB-B825-7DC044E2A52C@macports.org>
	<F4B4D303-2FCC-4BD8-840C-38F90A1D7115@macports.org>
	<4932F682.5080803@macports.org>
Message-ID: <9665BACA-5737-4E1B-BD35-FD3DE5799A38@macports.org>

On Nov 30, 2008, at 14:24, Joshua Root wrote:

> Ryan Schmidt wrote:
>> On Nov 30, 2008, at 13:02, Jeremy Huddleston wrote:
>>
>>> On Nov 29, 2008, at 20:06, Ryan Schmidt wrote:
>>>
>>>>> I decided to regen configure since it was made with an old version
>>>>> of autoconf that doesn't detect X11 properly.
>>>>
>>>> You should definitely regenerate configure after modifying
>>>> configure.ac. However changing the version of autoconf used  
>>>> should be
>>>> discussed first. In what way does the version of autoconf we've  
>>>> been
>>>> using not detect X11 properly, and what is the implication of that
>>>> improper detection?
>>>
>>> The older version of autoconf searches for libX11.so to find X11,  
>>> but
>>> it should be searching for libX11.dylib :
>>>
>>> # With the configure generated by the newer autoconf:
>>> ~/src/macports/trunk/base $ grep dylib configure
>>>     for ac_extension in a so sl dylib la dll; do
>>>   for ac_extension in a so sl dylib la dll; do
>>
>> Doesn't that mean that MacPorts has thus never detected X11  
>> correctly,
>> and therefore that it really hasn't mattered?
>
> It works on Darwin <= 9 because MP_CHECK_X11 in aclocal.m4 has some
> special cases.

Oh, ok. So this is only an issue for future versions of Mac OS X? Ok,  
then let's use newer autoconf :)


From ryandesign at macports.org  Sun Nov 30 21:39:02 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 30 Nov 2008 23:39:02 -0600
Subject: [MacPorts] UsingMacPortsQuickStart modified
In-Reply-To: <20081130211835.8FE342802F@relay14.apple.com>
References: <20081130211835.8FE342802F@relay14.apple.com>
Message-ID: <5EE88B08-9B65-406D-BF4A-8D38686BE67F@macports.org>

On Nov 30, 2008, at 15:17, MacPorts wrote:

>  `sudo port upgrade outdated`
>
> -(you can add the `-v` flag following "port" in the above command  
> if you'd like to watch the compiler output).
> +To upgrade all outdated ports and their dependencies:
> +
> +`sudo port upgrade -R outdated`
> +
> +(You can add the "`-v`" flag following "`port`" in the above  
> commands if you'd like to watch the compiler output.)

Do we really want to advise users, in the quick-start guide, to use  
the -R option, which, according to multiple reports, doesn't work so  
great?


From ryandesign at macports.org  Sun Nov 30 21:48:22 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 30 Nov 2008 23:48:22 -0600
Subject: [MacPorts] UsingMacPortsQuickStart modified
In-Reply-To: <81618959-48C0-416D-AAD7-FD6B7485B2C3@gmail.com>
References: <20081130211835.8FE342802F@relay14.apple.com>
	<5EE88B08-9B65-406D-BF4A-8D38686BE67F@macports.org>
	<81618959-48C0-416D-AAD7-FD6B7485B2C3@gmail.com>
Message-ID: <3A714F18-37BD-4CDC-8339-BC44FD13FB47@macports.org>


On Nov 30, 2008, at 23:46, Neil wrote:

>
> On 1 Dec 2008, at 00:39, Ryan Schmidt wrote:
>
>> On Nov 30, 2008, at 15:17, MacPorts wrote:
>>
>>> `sudo port upgrade outdated`
>>>
>>> -(you can add the `-v` flag following "port" in the above command  
>>> if you'd like to watch the compiler output).
>>> +To upgrade all outdated ports and their dependencies:
>>> +
>>> +`sudo port upgrade -R outdated`
>>> +
>>> +(You can add the "`-v`" flag following "`port`" in the above  
>>> commands if you'd like to watch the compiler output.)
>>
>> Do we really want to advise users, in the quick-start guide, to  
>> use the -R option, which, according to multiple reports, doesn't  
>> work so great?
>>
>
> I didn't know.  If it doesn't work well, you could take it out; or  
> perhaps you might simply consider putting a disclaimer on it.  I  
> didn't find it anywhere else in the documentation except for man  
> pages, and I thought it could also be useful.
>
> Then again, how often does an update of a port induce a new  
> dependency?  (Since existing dependencies should be caught up in  
> `sudo port upgrade outdated`...)

"port upgrade -R foo" also upgrades dependents (ports that depend on  
foo), not dependencies (ports that foo depends on); dependencies are  
always upgraded unless you use the "-n" flag.


From ryandesign at macports.org  Sun Nov 30 22:29:12 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 1 Dec 2008 00:29:12 -0600
Subject: No default port source specified in /mp/etc/macports/sources.conf 
Message-ID: <F07D8718-6753-4E5F-9596-F9B622C99F59@macports.org>

I tried updating my MacPorts trunk base just now (r42837) and got this:


===> making install in src/programs/daemondo
/usr/bin/install -c -o rschmidt -g admin -m 555 build/daemondo /mp/bin
/usr/bin/install -c -o rschmidt -g admin -m 444 setupenv.bash  /mp/ 
share/macports/
/usr/bin/tclsh src/upgrade_sources_conf_default.tcl /mp
/usr/bin/tclsh src/dep_map_clean.tcl /mp/Library/Tcl
No default port source specified in /mp/etc/macports/sources.conf
     while executing
"mportinit"
     (file "src/dep_map_clean.tcl" line 12)
make: *** [install] Error 1


The only non-comment line in my sources.conf is:

file:///Users/rschmidt/macports/dports

So it does not have anything in brackets after the URL.



From ryandesign at macports.org  Sun Nov 30 22:43:38 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 1 Dec 2008 00:43:38 -0600
Subject: No default port source specified in /mp/etc/macports/sources.conf
In-Reply-To: <F07D8718-6753-4E5F-9596-F9B622C99F59@macports.org>
References: <F07D8718-6753-4E5F-9596-F9B622C99F59@macports.org>
Message-ID: <BFE9C812-5CFF-4F2E-90AA-96D88F5842A5@macports.org>

On Dec 1, 2008, at 00:29, Ryan Schmidt wrote:

> I tried updating my MacPorts trunk base just now (r42837) and got  
> this:
>
>
> ===> making install in src/programs/daemondo
> /usr/bin/install -c -o rschmidt -g admin -m 555 build/daemondo /mp/bin
> /usr/bin/install -c -o rschmidt -g admin -m 444 setupenv.bash  /mp/ 
> share/macports/
> /usr/bin/tclsh src/upgrade_sources_conf_default.tcl /mp
> /usr/bin/tclsh src/dep_map_clean.tcl /mp/Library/Tcl
> No default port source specified in /mp/etc/macports/sources.conf
>     while executing
> "mportinit"
>     (file "src/dep_map_clean.tcl" line 12)
> make: *** [install] Error 1
>
>
> The only non-comment line in my sources.conf is:
>
> file:///Users/rschmidt/macports/dports
>
> So it does not have anything in brackets after the URL.

And the port command doesn't work either now:

$ port
No default port source specified in /mp/etc/macports/sources.conf
     while executing
"mportinit ui_options global_options global_variations"
Error: /mp/bin/port: Failed to initialize MacPorts, No default port  
source specified in /mp/etc/macports/sources.conf
$

Is there supposed to be code that changes my sources.conf to  
designate one as a default?


From ryandesign at macports.org  Sun Nov 30 23:14:16 2008
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 1 Dec 2008 01:14:16 -0600
Subject: No default port source specified in /mp/etc/macports/sources.conf
In-Reply-To: <BFE9C812-5CFF-4F2E-90AA-96D88F5842A5@macports.org>
References: <F07D8718-6753-4E5F-9596-F9B622C99F59@macports.org>
	<BFE9C812-5CFF-4F2E-90AA-96D88F5842A5@macports.org>
Message-ID: <9CF3E16B-A901-4061-B61C-572A265F7FBC@macports.org>

On Dec 1, 2008, at 00:43, Ryan Schmidt wrote:

> On Dec 1, 2008, at 00:29, Ryan Schmidt wrote:
>
>> I tried updating my MacPorts trunk base just now (r42837) and got  
>> this:
>>
>>
>> ===> making install in src/programs/daemondo
>> /usr/bin/install -c -o rschmidt -g admin -m 555 build/daemondo /mp/ 
>> bin
>> /usr/bin/install -c -o rschmidt -g admin -m 444 setupenv.bash  /mp/ 
>> share/macports/
>> /usr/bin/tclsh src/upgrade_sources_conf_default.tcl /mp
>> /usr/bin/tclsh src/dep_map_clean.tcl /mp/Library/Tcl
>> No default port source specified in /mp/etc/macports/sources.conf
>>     while executing
>> "mportinit"
>>     (file "src/dep_map_clean.tcl" line 12)
>> make: *** [install] Error 1
>>
>>
>> The only non-comment line in my sources.conf is:
>>
>> file:///Users/rschmidt/macports/dports
>>
>> So it does not have anything in brackets after the URL.
>
> And the port command doesn't work either now:
>
> $ port
> No default port source specified in /mp/etc/macports/sources.conf
>     while executing
> "mportinit ui_options global_options global_variations"
> Error: /mp/bin/port: Failed to initialize MacPorts, No default port  
> source specified in /mp/etc/macports/sources.conf
> $
>
> Is there supposed to be code that changes my sources.conf to  
> designate one as a default?

On another machine, on which I have multiple MacPorts installs  
sharing a sources.conf, "[default]" appears to have been added by  
something. Because I updated one install, and then the other said:

$ port sync
Warning: /mp/etc/macports/sources.conf source 'file:///Volumes/data/ 
macports/ports [default]' specifies invalid flag 'default'
Error: Synchronization of the local ports tree failed doing an svn  
update
port sync failed: Synchronization of 1 source(s) failed
$

And sources.conf does (now) have "[default]" at the end of the one  
non-comment line.


From blb at macports.org  Sun Nov 30 23:40:34 2008
From: blb at macports.org (Bryan Blackburn)
Date: Mon, 1 Dec 2008 00:40:34 -0700
Subject: No default port source specified in /mp/etc/macports/sources.conf
In-Reply-To: <9CF3E16B-A901-4061-B61C-572A265F7FBC@macports.org>
References: <F07D8718-6753-4E5F-9596-F9B622C99F59@macports.org>
	<BFE9C812-5CFF-4F2E-90AA-96D88F5842A5@macports.org>
	<9CF3E16B-A901-4061-B61C-572A265F7FBC@macports.org>
Message-ID: <20081201074034.GK722@ninagal.withay.com>

On Mon, Dec 01, 2008 at 01:14:16AM -0600, Ryan Schmidt said:
> On Dec 1, 2008, at 00:43, Ryan Schmidt wrote:
>
>> On Dec 1, 2008, at 00:29, Ryan Schmidt wrote:
>>
>>> I tried updating my MacPorts trunk base just now (r42837) and got  
>>> this:
>>>
>>>
>>> ===> making install in src/programs/daemondo
>>> /usr/bin/install -c -o rschmidt -g admin -m 555 build/daemondo /mp/ 
>>> bin
>>> /usr/bin/install -c -o rschmidt -g admin -m 444 setupenv.bash  /mp/ 
>>> share/macports/
>>> /usr/bin/tclsh src/upgrade_sources_conf_default.tcl /mp
>>> /usr/bin/tclsh src/dep_map_clean.tcl /mp/Library/Tcl
>>> No default port source specified in /mp/etc/macports/sources.conf
>>>     while executing
>>> "mportinit"
>>>     (file "src/dep_map_clean.tcl" line 12)
>>> make: *** [install] Error 1
>>>
>>>
>>> The only non-comment line in my sources.conf is:
>>>
>>> file:///Users/rschmidt/macports/dports
>>>
>>> So it does not have anything in brackets after the URL.
>>
>> And the port command doesn't work either now:
>>
>> $ port
>> No default port source specified in /mp/etc/macports/sources.conf
>>     while executing
>> "mportinit ui_options global_options global_variations"
>> Error: /mp/bin/port: Failed to initialize MacPorts, No default port  
>> source specified in /mp/etc/macports/sources.conf
>> $
>>
>> Is there supposed to be code that changes my sources.conf to designate 
>> one as a default?

Yes, base/src/upgrade_sources_conf_default.tcl does this.  However there are
a few cases where it is/was failing.  The above source you used,
file:///Users/rschmidt/macports/dports, is that an svn-checkout?  If so, is
the URL for it at svn.macosforge.org instead of macports.org (use 'svn info
/Users/rschmidt/macports/dports' to see)?  If so, I'm working on fixing that
at the moment.

>
> On another machine, on which I have multiple MacPorts installs sharing a 
> sources.conf, "[default]" appears to have been added by something. Because 
> I updated one install, and then the other said:
>
> $ port sync
> Warning: /mp/etc/macports/sources.conf source 'file:///Volumes/data/ 
> macports/ports [default]' specifies invalid flag 'default'
> Error: Synchronization of the local ports tree failed doing an svn update
> port sync failed: Synchronization of 1 source(s) failed
> $
>
> And sources.conf does (now) have "[default]" at the end of the one  
> non-comment line.

Did this sources.conf have a tag already, most likely [nosync] in it?  That
was fixed in r42734 for trunk and r42736 for 1.7 branch, to use the correct
'[nosync,default]' instead of '[nosync] [default]'.

Bryan