From akitada at macports.org  Sun Nov  1 06:23:20 2009
From: akitada at macports.org (Akira Kitada)
Date: Sun, 1 Nov 2009 23:23:20 +0900
Subject: Future of setuptools and distribute in MacPorts
In-Reply-To: <90bb445a0910091956p5118e478s882456678f5cec13@mail.gmail.com>
References: <90bb445a0910071009n6cd810e6gcb1ec9f25fae9749@mail.gmail.com> 
	<20091007202131.GF480@ninagal.withay.com>
	<90bb445a0910091956p5118e478s882456678f5cec13@mail.gmail.com>
Message-ID: <90bb445a0911010623n50ec5b19r22725dfc68a7d301@mail.gmail.com>

Appanrently Debian also adopted Distribute for setuptools, I mean,
aptitude install python-setuptools installs 'distribute'.

On Sat, Oct 10, 2009 at 11:56 AM, Akira Kitada <akitada at macports.org> wrote:
> On Thu, Oct 8, 2009 at 5:21 AM, Bryan Blackburn <blb at macports.org> wrote:
>> Moving over to distribute is one possibility, but the discussion on (at
>> least) distutils-sig seems like the python community hasn't quite decided on
>> where things are going yet...at least with the patched setuptools things
>> should still work as well as they have until we have a clearer overall idea
>> of where things will be going.
>
> I think that's not what the Python community decides but the
> distributer, in this case,
> the MacPorts community.
>
>> Note that I also added py26-distribute, but as you note it does conflict
>> with py26-setuptools, so moving to it would be painful. ?Maybe it can be the
>> preferred one for py27 ports?
>
> How about starting it now?
>
>>
>> Bryan
>>
>>>
>>> Any suggestions would be appreciated.
>>> Thanks.
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>>
>

From howarth at bromo.med.uc.edu  Sun Nov  1 10:18:19 2009
From: howarth at bromo.med.uc.edu (Jack Howarth)
Date: Sun, 1 Nov 2009 13:18:19 -0500
Subject: limiting installed (re)versions in port?
Message-ID: <20091101181819.GA16028@bromo.med.uc.edu>

  One aspect of MacPorts that concerns me (compared to
fink) is that it seems possible with port to accumulate
a huge number of installed (but deactivated) package
(re)versions over time. I can understand the concept of
keeping some of the most recent (re)versions but not
every single one. It would make much more sense to adopt
the approach where only those previous (re)versions would
be kept up to some user defined limit (perhaps defaulting
to 2 or 3 previous (re)versions of the same package).
When a new (re)version of the same package is installed 
and the limit of archived (re)versions has been meet,
the oldest copy would be purged from the system. Otherwise
the numbers of deactivated ports will bloat the system
over time. Has a ticket ever been opened for such a feature
in port?
             Jack

From jeremy at lavergne.gotdns.org  Sun Nov  1 10:23:04 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Sun, 1 Nov 2009 13:23:04 -0500
Subject: limiting installed (re)versions in port?
In-Reply-To: <20091101181819.GA16028@bromo.med.uc.edu>
References: <20091101181819.GA16028@bromo.med.uc.edu>
Message-ID: <6C9457FA-F976-401D-A697-2CC13E47AA8C@lavergne.gotdns.org>

> One aspect of MacPorts that concerns me (compared to fink) is that  
> it seems possible with port to accumulate
> a huge number of installed (but deactivated) package (re)versions  
> over time. I can understand the concept of
> keeping some of the most recent (re)versions but not every single  
> one. It would make much more sense to adopt
> the approach where only those previous (re)versions would be kept up  
> to some user defined limit (perhaps defaulting to 2 or 3 previous  
> (re)versions of the same package). When a new (re)version of the  
> same package is installed  and the limit of archived (re)versions  
> has been meet, the oldest copy would be purged from the system.  
> Otherwise the numbers of deactivated ports will bloat the system  
> over time. Has a ticket ever been opened for such a feature in port?

`port upgrade -u ...` somewhat covers that functionality in that it  
will remove the old version prior to activating the new one.

You can remove specific versions using the fully qualified name (port  
uninstall NAME @...[+VARIANTS]), which is available through `port  
installed [...]`

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

From talklists at newgeo.com  Sun Nov  1 20:30:52 2009
From: talklists at newgeo.com (Scott Haneda)
Date: Sun, 1 Nov 2009 20:30:52 -0800
Subject: SF.net aggravations
Message-ID: <EC0C4341-C644-4E5F-ADA7-0399832BA6C1@newgeo.com>

I have no idea if this is SF.net or the maintainer, but keeping up  
with the way they distribute this software is a pain in the rear.  One  
of the most useful peieves of software burdened by things that simply  
are not a burden elsewhere.  In the end, I think I am going to mirror  
this file on my machines as this is getting old, and fast.

name                ASSP
version             1.5.1.8
homepage            http://assp.sourceforge.net/
master_sites        sourceforge
livecheck.regex     "ASSP Installation ASSP (\\d+(?:\\.\\d+)*) released"
use_zip             yes
distname            ASSP_${version}-Install

That should be about all the port file needs for us to eval this debug  
output...

Here are all the http failures:
http://dl.getdropbox.com/u/340087/Drops/11.01.09/dl-f59f1cf2-202650.txt

DEBUG: Fetching failed:: HTTP response code said error
Error: Target org.macports.fetch returned: fetch failed
DEBUG: Backtrace: fetch failed
     while executing
"portfetch::fetchfiles"
     ("standard" arm line 1)
     invoked from within
"switch -- "${fetch.type}" {
         cvs     { return [cvsfetch] }
         svn     { return [svnfetch] }
         git     { return [gitfetch] }
         ..."
     (procedure "portfetch::fetch_main" line 10)
     invoked from within
"$procedure $targetname"
Warning: the following items did not execute (for ASSP):  
org.macports.activate org.macports.fetch org.macports.extract  
org.macports.checksum org.macports.patch org.macports.configure  
org.macports.build org.macports.destroot org.macports.install
Error: Status 1 encountered during processing.

I was using -f, as there were more p5 errors on this one than I have  
ever seen before.  This is on 1.8 which I suspect means I may have to  
make some adjustmetns,

I can manually go to SF and download fine at
http://softlayer.dl.sourceforge.net/project/assp/ASSP%20Installation/ASSP%201.5.1.8/ASSP_1.5.1.8-Install.zip

Putting the above file in /opt/local/var/macports/distfiles/assp and I  
get an install at least with the -f in use.
-- 
Scott * If you contact me off list replace talklists@ with scott@ *


From toby at macports.org  Sun Nov  1 20:35:25 2009
From: toby at macports.org (Toby Peterson)
Date: Sun, 1 Nov 2009 20:35:25 -0800
Subject: SF.net aggravations
In-Reply-To: <EC0C4341-C644-4E5F-ADA7-0399832BA6C1@newgeo.com>
References: <EC0C4341-C644-4E5F-ADA7-0399832BA6C1@newgeo.com>
Message-ID: <74c219d30911012035m36a7bc31o483cd1e43f496e40@mail.gmail.com>

afaik, sourceforge is case-sensitive, try sourceforge:assp

On Sun, Nov 1, 2009 at 20:30, Scott Haneda <talklists at newgeo.com> wrote:
> I have no idea if this is SF.net or the maintainer, but keeping up with the
> way they distribute this software is a pain in the rear. ?One of the most
> useful peieves of software burdened by things that simply are not a burden
> elsewhere. ?In the end, I think I am going to mirror this file on my
> machines as this is getting old, and fast.
>
> name ? ? ? ? ? ? ? ?ASSP
> version ? ? ? ? ? ? 1.5.1.8
> homepage ? ? ? ? ? ?http://assp.sourceforge.net/
> master_sites ? ? ? ?sourceforge
> livecheck.regex ? ? "ASSP Installation ASSP (\\d+(?:\\.\\d+)*) released"
> use_zip ? ? ? ? ? ? yes
> distname ? ? ? ? ? ?ASSP_${version}-Install
>
> That should be about all the port file needs for us to eval this debug
> output...
>
> Here are all the http failures:
> http://dl.getdropbox.com/u/340087/Drops/11.01.09/dl-f59f1cf2-202650.txt
>
> DEBUG: Fetching failed:: HTTP response code said error
> Error: Target org.macports.fetch returned: fetch failed
> DEBUG: Backtrace: fetch failed
> ? ?while executing
> "portfetch::fetchfiles"
> ? ?("standard" arm line 1)
> ? ?invoked from within
> "switch -- "${fetch.type}" {
> ? ? ? ?cvs ? ? { return [cvsfetch] }
> ? ? ? ?svn ? ? { return [svnfetch] }
> ? ? ? ?git ? ? { return [gitfetch] }
> ? ? ? ?..."
> ? ?(procedure "portfetch::fetch_main" line 10)
> ? ?invoked from within
> "$procedure $targetname"
> Warning: the following items did not execute (for ASSP):
> org.macports.activate org.macports.fetch org.macports.extract
> org.macports.checksum org.macports.patch org.macports.configure
> org.macports.build org.macports.destroot org.macports.install
> Error: Status 1 encountered during processing.
>
> I was using -f, as there were more p5 errors on this one than I have ever
> seen before. ?This is on 1.8 which I suspect means I may have to make some
> adjustmetns,
>
> I can manually go to SF and download fine at
> http://softlayer.dl.sourceforge.net/project/assp/ASSP%20Installation/ASSP%201.5.1.8/ASSP_1.5.1.8-Install.zip
>
> Putting the above file in /opt/local/var/macports/distfiles/assp and I get
> an install at least with the -f in use.
> --
> Scott * If you contact me off list replace talklists@ with scott@ *
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>

From ad at cs.toronto.edu  Mon Nov  2 07:01:38 2009
From: ad at cs.toronto.edu (Aran Donohue)
Date: Mon, 2 Nov 2009 10:01:38 -0500
Subject: stories of portfile maintenance
Message-ID: <c770530d0911020701s35b6ac69jdb207a1c04a6503c@mail.gmail.com>

Hi there,

I'm an MSc student at the University of Toronto. My thesis is a case study
of domain-specific language maintenance. I bet there are all sorts of great
stories of painful portfile bugs---I'd love to hear them. If you've got 30
minutes to spare for a non-personal non-confidential interview over the
phone or Skype, please get in touch!

Thanks,
Aran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20091102/df5d1747/attachment.html>

From evenson at panix.com  Mon Nov  2 04:38:18 2009
From: evenson at panix.com (Mark Evenson)
Date: Mon, 02 Nov 2009 13:38:18 +0100
Subject: [MacPorts] #21017: clisp 2.47 build failure 64-bit
In-Reply-To: <7B43E5E2-D2ED-4DDD-8868-7D96960ED07A@syr.edu>
References: <059.97b1d7c0738737a0050ab7932de2c796@macports.org>
	<068.c15d6f6a535bc47f57213cfb9e24d735@macports.org>
	<7B43E5E2-D2ED-4DDD-8868-7D96960ED07A@syr.edu>
Message-ID: <4AEED2BA.5080007@panix.com>

On 11/2/09 3:11 AM, Sheldon W Thomas wrote:
[?]
> Can anybody explain how to use the portfile listed on this bug to
> install a working copy of clisp on 64bit Snow Leopard?
> I'm so lost in documentation
[?]

1) create a directory somewhere called 'clisp'

2) copy the Portfile to the directory

3) from the 'clisp' directory issue the following command

     osx$ sudo port -D . -v install

The '-D .' tells port to use the Portfile in the current directory; the 
'sudo' is the elevation of privileges necessary in the default 
installation of MacPorts.

Unfortunately, when I tried the Portfile this morning, the configure 
phases failed when it tried to link with the 64bit version of 
libsigsegv.  Maybe building with the '+nolibsigsegv' variant would work, 
but I ran out of time to try this.

If you are merely looking for a Common Lisp from MacPorts on Snow 
Leopard, both 'ecl' and 'abcl' are currently working.


-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."

From talklists at newgeo.com  Wed Nov  4 14:44:24 2009
From: talklists at newgeo.com (Scott Haneda)
Date: Wed, 4 Nov 2009 14:44:24 -0800
Subject: Invoking tcl
Message-ID: <BAE2CDCE-66A1-4A8C-9628-56E208D320DF@newgeo.com>

I am trying to do some scripting in tcl for a port file that is a  
little out of the norm for what is needed in most ports.

How do I invoke tcl in a sample script?

In bash, I would create a new file, enter the shebang of #!/bin/bash  
and go at it.  I honestly can not find tcl on my system.

`which`, `whereis` return nothing.
-- 
Scott * If you contact me off list replace talklists@ with scott@ *


From jeremy at lavergne.gotdns.org  Wed Nov  4 14:50:48 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Wed, 4 Nov 2009 17:50:48 -0500
Subject: Invoking tcl
In-Reply-To: <BAE2CDCE-66A1-4A8C-9628-56E208D320DF@newgeo.com>
References: <BAE2CDCE-66A1-4A8C-9628-56E208D320DF@newgeo.com>
Message-ID: <9DFEB088-A3A8-4C97-80BD-12C0E04D1825@lavergne.gotdns.org>

tclsh

On Nov 4, 2009, at 5:44 PM, Scott Haneda wrote:

> I am trying to do some scripting in tcl for a port file that is a  
> little out of the norm for what is needed in most ports.
>
> How do I invoke tcl in a sample script?
>
> In bash, I would create a new file, enter the shebang of #!/bin/bash  
> and go at it.  I honestly can not find tcl on my system.
>
> `which`, `whereis` return nothing.

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

From jeremy at lavergne.gotdns.org  Wed Nov  4 18:18:07 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Wed, 4 Nov 2009 21:18:07 -0500
Subject: gnome-python-extras
Message-ID: <2FF1CCA7-1A17-4449-B736-B67928FF5D5D@lavergne.gotdns.org>

How does one make use of gnome-python-extras in python26?


From talklists at newgeo.com  Wed Nov  4 22:43:00 2009
From: talklists at newgeo.com (Scott Haneda)
Date: Wed, 4 Nov 2009 22:43:00 -0800
Subject: Invoking tcl
In-Reply-To: <9DFEB088-A3A8-4C97-80BD-12C0E04D1825@lavergne.gotdns.org>
References: <BAE2CDCE-66A1-4A8C-9628-56E208D320DF@newgeo.com>
	<9DFEB088-A3A8-4C97-80BD-12C0E04D1825@lavergne.gotdns.org>
Message-ID: <B189539F-BF78-4B45-B28C-7E708A81B11D@newgeo.com>

Thanks for setting me straight on the tcl and tclsh ting

I am working on taking a large list of variants, and generating the  
conflicts dynamically.  The below works, but I think I need to eval it  
is in some way to get ports to recognize it.

set variants {english french spanish japanese dutch}

foreach variant_name $variants {
      # Quick way to remove the working variant from the list
      set no_conflicts [lsearch -all -inline -not -exact $variants  
$variant_name]
      set a [subst {variant $variant_name conflicts $no_conflicts  
description "Use $variant_name for server messages" {
                configure.args-append --with-language=$variant_name }
      }]
      puts $a
}

Better representation here: http://pastie.org/684447

Here is what it is printing out output
http://pastie.org/684449

Which I could copy and paste into the portfile, but I want to be more  
dynamic abut it.  I have tried this previous example a few ways, and  
am not getting it:

# Add langugage variants
foreach {language arg} ${languages} {
    set variant lang_[strsed ${arg} {g/-/_/}]
    set conflicts {}
    foreach {ignore conflicting_arg} ${languages} {
        if {${conflicting_arg} != ${arg}} {
            set conflicting_variant lang_[strsed ${conflicting_arg}  
{g/-/_/}]
            lappend conflicts ${conflicting_variant}
        }
    }
    eval [subst {
        variant ${variant} conflicts ${conflicts} description "Use $ 
{language} language for server messages" {
            configure.args-append   --with-language=${arg}
        }
    }]
}

Yes, I can go with the existing code, but I seem to understand the one  
I wrote, and it seems to be shorter, and better tailored to this  
case.  Thanks for any pointers.  tcl is a weird language.
-- 
Scott * If you contact me off list replace talklists@ with scott@ * 

From dweber at macports.org  Thu Nov  5 17:46:58 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 5 Nov 2009 17:46:58 -0800
Subject: Any interest in using git for scm?
Message-ID: <b808b3510911051746i2b720381wb7550c1eac2e85a4@mail.gmail.com>

After listening to Linus Torvalds talk about git and looking at a video
tutorial from Scott Chacon, it would seem beneficial to use git for MacPorts
development.  It appears that git can be used with an existing svn
repository (man git-svn), or the svn repository could be imported into a new
master git repository (perhaps host it with github).  Is anyone currently
using git for MacPorts development?

After a few tips from MacPorts gurus and some experiments, I was able to
draft the instructions at
Create an experimental users directory in the MacPorts Subversion repository
http://trac.macports.org/wiki/CommittersTipsAndTricks

The merge process with svn takes a while to grok, but it works OK.  Is
anyone having an easier time with git?

The resources here are helpful in learning git:
http://www.linuxfoundation.org/search/node/git

Take care,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20091105/e4b6bc32/attachment.html>

From talklists at newgeo.com  Thu Nov  5 20:09:42 2009
From: talklists at newgeo.com (Scott Haneda)
Date: Thu, 5 Nov 2009 20:09:42 -0800
Subject: Invoking tcl
In-Reply-To: <B189539F-BF78-4B45-B28C-7E708A81B11D@newgeo.com>
References: <BAE2CDCE-66A1-4A8C-9628-56E208D320DF@newgeo.com>
	<9DFEB088-A3A8-4C97-80BD-12C0E04D1825@lavergne.gotdns.org>
	<B189539F-BF78-4B45-B28C-7E708A81B11D@newgeo.com>
Message-ID: <53B292DE-1B8A-4039-96AE-99E37F89D952@newgeo.com>

Any takers?  This is the last thing from getting me to port  
submission, or I can go the sloppy way and allow copy and paste, which  
makes the portfile about 50 lines more than it need be.

Thanks all.
-- 
Scott * If you contact me off list replace talklists@ with scott@ *

On Nov 4, 2009, at 10:43 PM, Scott Haneda wrote:

> Thanks for setting me straight on the tcl and tclsh ting
>
> I am working on taking a large list of variants, and generating the  
> conflicts dynamically.  The below works, but I think I need to eval  
> it is in some way to get ports to recognize it.
>
> set variants {english french spanish japanese dutch}
>
> foreach variant_name $variants {
>     # Quick way to remove the working variant from the list
>     set no_conflicts [lsearch -all -inline -not -exact $variants  
> $variant_name]
>     set a [subst {variant $variant_name conflicts $no_conflicts  
> description "Use $variant_name for server messages" {
>               configure.args-append --with-language=$variant_name }
>     }]
>     puts $a
> }
>
> Better representation here: http://pastie.org/684447
>
> Here is what it is printing out output
> http://pastie.org/684449
>
> Which I could copy and paste into the portfile, but I want to be  
> more dynamic abut it.  I have tried this previous example a few  
> ways, and am not getting it:
>
> # Add langugage variants
> foreach {language arg} ${languages} {
>   set variant lang_[strsed ${arg} {g/-/_/}]
>   set conflicts {}
>   foreach {ignore conflicting_arg} ${languages} {
>       if {${conflicting_arg} != ${arg}} {
>           set conflicting_variant lang_[strsed ${conflicting_arg}  
> {g/-/_/}]
>           lappend conflicts ${conflicting_variant}
>       }
>   }
>   eval [subst {
>       variant ${variant} conflicts ${conflicts} description "Use $ 
> {language} language for server messages" {
>           configure.args-append   --with-language=${arg}
>       }
>   }]
> }
>
> Yes, I can go with the existing code, but I seem to understand the  
> one I wrote, and it seems to be shorter, and better tailored to this  
> case.  Thanks for any pointers.  tcl is a weird language.


From neric27 at wanadoo.fr  Thu Nov  5 22:32:23 2009
From: neric27 at wanadoo.fr (Eric)
Date: Fri, 06 Nov 2009 07:32:23 +0100
Subject: gnome-python-extras
In-Reply-To: <2FF1CCA7-1A17-4449-B736-B67928FF5D5D@lavergne.gotdns.org>
References: <2FF1CCA7-1A17-4449-B736-B67928FF5D5D@lavergne.gotdns.org>
Message-ID: <4AF3C2F7.6090402@wanadoo.fr>

I submitted a new gnome-python26-extras a while ago, but it was broken :
a missing compilation flag.
Now that I fixed it, I hope snc will have time to re-consider it.
If you are proficient with using local ports, here is the ticket :
http://trac.macports.org/ticket/20608

Cheers,

NB: I only use the html part, so the other modules may not be working as
expected !

Jeremy Lavergne a ?crit :
>
> How does one make use of gnome-python-extras in python26?
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>
>


From takeshi at macports.org  Fri Nov  6 01:08:56 2009
From: takeshi at macports.org (Takeshi Enomoto)
Date: Fri, 6 Nov 2009 18:08:56 +0900
Subject: need help with variant_isset and default_variants
Message-ID: <2dc53b910911060108j6929befcye4007b623a830a77@mail.gmail.com>

Hello,

I am modifying Portfile for g95 to enable build on Snow Leopard.
It turned out that I need to link against gcc-4.2.x on Snow Leopard.
Although the fix also work fine on Intel Macs running Tiger and Leopard
as well as Snow Leopard, unfortunately this fix does not work on Power Macs.

So I decided to add a gcc42 variant.
I would like to make this variant automatically chosen for Snow Leopard
and user-option for Tiger and Leopard.

Currently gcc42 is not chosen automatically.
I am not clear if this is a port bug or a bug in port command.
It would be nice if someone let me know the behaviour of variant_isset
and default_variants
and how I should write.

Portfile and patches are found at attachment at #22359.

Thanks

Takeshi
----

if {[variant_isset gcc42]} {
    set version_gcc 4.2.4
    dist_subdir     gcc42
    array set barch {ppc powerpc ppc64 powerpc64 i386 i386 x86_64 x86_64}
    set triple      $barch(${build_arch})-apple-darwin${os.major}
} else {
    set version_gcc 4.0.4
    dist_subdir     gcc40
    set triple      ${os.arch}-apple-darwin${os.major}
}

# zap

platform darwin 10 {}

if {[variant_isset darwin_10]} {
    default_variants +gcc42
}

From blair at orcaware.com  Fri Nov  6 10:37:17 2009
From: blair at orcaware.com (Blair Zajac)
Date: Fri, 6 Nov 2009 10:37:17 -0800
Subject: Any interest in using git for scm?
In-Reply-To: <b808b3510911051746i2b720381wb7550c1eac2e85a4@mail.gmail.com>
References: <b808b3510911051746i2b720381wb7550c1eac2e85a4@mail.gmail.com>
Message-ID: <342C3F9D-4A27-4500-8A3D-0AEC59D0C90A@orcaware.com>


On Nov 5, 2009, at 5:46 PM, Darren Weber wrote:

>
> After listening to Linus Torvalds talk about git and looking at a  
> video tutorial from Scott Chacon, it would seem beneficial to use  
> git for MacPorts development.  It appears that git can be used with  
> an existing svn repository (man git-svn), or the svn repository  
> could be imported into a new master git repository (perhaps host it  
> with github).  Is anyone currently using git for MacPorts development?
>
> After a few tips from MacPorts gurus and some experiments, I was  
> able to draft the instructions at
> Create an experimental users directory in the MacPorts Subversion  
> repository
>
> http://trac.macports.org/wiki/CommittersTipsAndTricks
>
> The merge process with svn takes a while to grok, but it works OK.   
> Is anyone having an easier time with git?
>
> The resources here are helpful in learning git:
> http://www.linuxfoundation.org/search/node/git

While I use git svn on a daily on my own source code projects, I don't  
see the value in migrating from svn over to git for MacPorts for the  
repository.  Nothing stopping people from using git to checkout from  
svn.

Also, I don't keep a local svn checkout of the dports portion of the  
repository and the one thing I do when I want to update a port is just  
checkout the directory of the port I'm updating, which is a feature  
Subversion supports that git doesn't.

Regards,
Blair


From dreamcat4 at gmail.com  Fri Nov  6 10:46:41 2009
From: dreamcat4 at gmail.com (dreamcat four)
Date: Fri, 6 Nov 2009 18:46:41 +0000
Subject: Any interest in using git for scm?
In-Reply-To: <b808b3510911051746i2b720381wb7550c1eac2e85a4@mail.gmail.com>
References: <b808b3510911051746i2b720381wb7550c1eac2e85a4@mail.gmail.com>
Message-ID: <99cf22520911061046q7686ded1s39f91c3b42e79d7f@mail.gmail.com>

Hi,
Checkouts are always many times faster under git. Even small projects.

I'm not a macports committer, but if you want to continue with svn,
and add git then i'd recommend to look at the PHP project. Some guys
there have come up with some great scripts to help the two work better
together.

http://github.com/php/php-svn-helpers
http://github.com/php/php-mirror-scripts

Guess you just cron the mirror-script every hour or something.
Good luck!

On Fri, Nov 6, 2009 at 1:46 AM, Darren Weber <dweber at macports.org> wrote:
>
> After listening to Linus Torvalds talk about git and looking at a video
> tutorial from Scott Chacon, it would seem beneficial to use git for MacPorts
> development.? It appears that git can be used with an existing svn
> repository (man git-svn), or the svn repository could be imported into a new
> master git repository (perhaps host it with github).? Is anyone currently
> using git for MacPorts development?
>
> After a few tips from MacPorts gurus and some experiments, I was able to
> draft the instructions at
>
> Create an experimental users directory in the MacPorts Subversion repository
>
> http://trac.macports.org/wiki/CommittersTipsAndTricks
>
> The merge process with svn takes a while to grok, but it works OK.? Is
> anyone having an easier time with git?
>
> The resources here are helpful in learning git:
> http://www.linuxfoundation.org/search/node/git
>
> Take care,
> Darren
>
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>
>

From wsiegrist at apple.com  Fri Nov  6 10:49:27 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Fri, 6 Nov 2009 10:49:27 -0800
Subject: Any interest in using git for scm?
In-Reply-To: <b808b3510911051746i2b720381wb7550c1eac2e85a4@mail.gmail.com>
References: <b808b3510911051746i2b720381wb7550c1eac2e85a4@mail.gmail.com>
Message-ID: <D21C1E11-22E3-4C26-89D7-CA351215A788@apple.com>

On Nov 5, 2009, at 5:46 PM, Darren Weber wrote:

> 
> After listening to Linus Torvalds talk about git and looking at a video tutorial from Scott Chacon, it would seem beneficial to use git for MacPorts development.  It appears that git can be used with an existing svn repository (man git-svn), or the svn repository could be imported into a new master git repository (perhaps host it with github).  Is anyone currently using git for MacPorts development?
> 

Mac OS Forge (the hosting provider MacPorts lives on) does not currently provide read-write git repos. But we do provide a git mirror of the svn repo.  That at least saves you some time when creating your local git repo. 

https://www.macosforge.org/post/git-mirrors/

-Bill




From dweber at macports.org  Fri Nov  6 12:12:30 2009
From: dweber at macports.org (Darren Weber)
Date: Fri, 6 Nov 2009 12:12:30 -0800
Subject: Any interest in using git for scm?
In-Reply-To: <D21C1E11-22E3-4C26-89D7-CA351215A788@apple.com>
References: <b808b3510911051746i2b720381wb7550c1eac2e85a4@mail.gmail.com>
	<D21C1E11-22E3-4C26-89D7-CA351215A788@apple.com>
Message-ID: <b808b3510911061212g500a894aq86a6a165a4802d7c@mail.gmail.com>

On Fri, Nov 6, 2009 at 10:49 AM, William Siegrist <wsiegrist at apple.com>wrote:

> On Nov 5, 2009, at 5:46 PM, Darren Weber wrote:
>
> >
> > After listening to Linus Torvalds talk about git and looking at a video
> tutorial from Scott Chacon, it would seem beneficial to use git for MacPorts
> development.  It appears that git can be used with an existing svn
> repository (man git-svn), or the svn repository could be imported into a new
> master git repository (perhaps host it with github).  Is anyone currently
> using git for MacPorts development?
> >
>
> Mac OS Forge (the hosting provider MacPorts lives on) does not currently
> provide read-write git repos. But we do provide a git mirror of the svn
> repo.  That at least saves you some time when creating your local git repo.
>
> https://www.macosforge.org/post/git-mirrors/
>
> -Bill
>
>
>
>

Hey Bill,

So this means the MacPorts svn tree is already in a git repo that is in sync
with the svn repo - nice!  Thank you for the reference!

This is helpful, for sure:
http://trac.webkit.org/wiki/UsingGitWithWebKit

I found these MacPort installs to be useful:
sudo port install git-core +bash_completion +doc +svn +gitweb
sudo port install gc-utils
sudo port install qgit GitX

One thing in using git with MacPorts is that a remote clone requires the -u
option to specify a non-default path for the location of the git binary on
the remote server (when the remote server has git installed from MacPorts).
That is, on the "client" that connects to a "macports-server", run:

git clone -u /opt/local/bin/git-upload-pack <SRC_REPO_URL> <DIR>

The MacPorts svn checkout is about 230Mb, including:

$ ls macports/
Makefile  base/  doc/  doc-new/  dports/  www/

It's about 11,000 files (without .svn files):
$ /opt/local/bin/gfind ./macports -type f | awk '!/.svn/' | wc -l
   10826

That should be manageable with git.  There is the limitation that git cannot
checkout a subset of the tree (like macports/dports/devel/gc-utils).

In general, it is very interesting to see how git has evolved to solve the
challenges of distributed source code development for the linux kernel.
It's able to handle thousands of files and hundreds or thousands of
contributors, with high performance and integrity criteria.  While it's
healthy to maintain some scepticism about drinking any particular flavor of
cool-aid, the git cool-aid looks impressive ;-)  After listening to the
Google tech talk from Linus, one of the most striking things about git is
the sha1 hash to maintain integrity in the repo objects (other significant
features include the distributed repos for local work, true 'content'
management [full patches, not just file management], staging commits like a
transaction, easier and faster merging, etc.).  The sha1 is used to
guarantee that what goes in is exactly what comes out.  As he put it, this
evolved from an attempt to hack the linux source code when it was managed
under BitKeeper (which did provide a detection for the hacks).  It's not
exactly a security feature, it provides an integrity check and a byproduct
of that is the ability to detect corruption.  The distributed nature of the
git repos is also a default backup system of a sort.

Given the sha1 integrity checks in git (not available in any other scm
yet?), an import of source code from cvs, svn etc. into git is a persuasive
argument.  Are there any faults or gaps in that argument?

Best,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20091106/dc949757/attachment.html>

From blair at orcaware.com  Fri Nov  6 12:30:47 2009
From: blair at orcaware.com (Blair Zajac)
Date: Fri, 6 Nov 2009 12:30:47 -0800
Subject: Any interest in using git for scm?
In-Reply-To: <99cf22520911061046q7686ded1s39f91c3b42e79d7f@mail.gmail.com>
References: <b808b3510911051746i2b720381wb7550c1eac2e85a4@mail.gmail.com>
	<99cf22520911061046q7686ded1s39f91c3b42e79d7f@mail.gmail.com>
Message-ID: <F0D32F19-5FC6-49FD-A88A-238BE792B789@orcaware.com>

On Nov 6, 2009, at 10:46 AM, dreamcat four wrote:

> Hi,
> Checkouts are always many times faster under git. Even small projects.

That's being worked on for the 1.7 release.  We're moving to the model  
with a single top level .svn directory instead of a .svn directory per  
directory in the checkout so there's a lot less IO that has to be done.

Blair


From jkh at apple.com  Fri Nov  6 18:10:09 2009
From: jkh at apple.com (Jordan K. Hubbard)
Date: Fri, 6 Nov 2009 18:10:09 -0800
Subject: Invoking tcl
In-Reply-To: <53B292DE-1B8A-4039-96AE-99E37F89D952@newgeo.com>
References: <BAE2CDCE-66A1-4A8C-9628-56E208D320DF@newgeo.com>
	<9DFEB088-A3A8-4C97-80BD-12C0E04D1825@lavergne.gotdns.org>
	<B189539F-BF78-4B45-B28C-7E708A81B11D@newgeo.com>
	<53B292DE-1B8A-4039-96AE-99E37F89D952@newgeo.com>
Message-ID: <77B41AE8-09A5-47DA-9689-3D1596E2EF47@apple.com>

Well, I read your message a couple of times and still don't really see a question in there anywhere.  What specifically are you asking?

- Jordan

On Nov 5, 2009, at 8:09 PM, Scott Haneda wrote:

> Any takers?  This is the last thing from getting me to port submission, or I can go the sloppy way and allow copy and paste, which makes the portfile about 50 lines more than it need be.
> 
> Thanks all.
> -- 
> Scott * If you contact me off list replace talklists@ with scott@ *
> 
> On Nov 4, 2009, at 10:43 PM, Scott Haneda wrote:
> 
>> Thanks for setting me straight on the tcl and tclsh ting
>> 
>> I am working on taking a large list of variants, and generating the conflicts dynamically.  The below works, but I think I need to eval it is in some way to get ports to recognize it.
>> 
>> set variants {english french spanish japanese dutch}
>> 
>> foreach variant_name $variants {
>>    # Quick way to remove the working variant from the list
>>    set no_conflicts [lsearch -all -inline -not -exact $variants $variant_name]
>>    set a [subst {variant $variant_name conflicts $no_conflicts description "Use $variant_name for server messages" {
>>              configure.args-append --with-language=$variant_name }
>>    }]
>>    puts $a
>> }
>> 
>> Better representation here: http://pastie.org/684447
>> 
>> Here is what it is printing out output
>> http://pastie.org/684449
>> 
>> Which I could copy and paste into the portfile, but I want to be more dynamic abut it.  I have tried this previous example a few ways, and am not getting it:
>> 
>> # Add langugage variants
>> foreach {language arg} ${languages} {
>>  set variant lang_[strsed ${arg} {g/-/_/}]
>>  set conflicts {}
>>  foreach {ignore conflicting_arg} ${languages} {
>>      if {${conflicting_arg} != ${arg}} {
>>          set conflicting_variant lang_[strsed ${conflicting_arg} {g/-/_/}]
>>          lappend conflicts ${conflicting_variant}
>>      }
>>  }
>>  eval [subst {
>>      variant ${variant} conflicts ${conflicts} description "Use ${language} language for server messages" {
>>          configure.args-append   --with-language=${arg}
>>      }
>>  }]
>> }
>> 
>> Yes, I can go with the existing code, but I seem to understand the one I wrote, and it seems to be shorter, and better tailored to this case.  Thanks for any pointers.  tcl is a weird language.
> 
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


From talklists at newgeo.com  Fri Nov  6 18:24:00 2009
From: talklists at newgeo.com (Scott Haneda)
Date: Fri, 6 Nov 2009 18:24:00 -0800
Subject: Invoking tcl
In-Reply-To: <77B41AE8-09A5-47DA-9689-3D1596E2EF47@apple.com>
References: <BAE2CDCE-66A1-4A8C-9628-56E208D320DF@newgeo.com>
	<9DFEB088-A3A8-4C97-80BD-12C0E04D1825@lavergne.gotdns.org>
	<B189539F-BF78-4B45-B28C-7E708A81B11D@newgeo.com>
	<53B292DE-1B8A-4039-96AE-99E37F89D952@newgeo.com>
	<77B41AE8-09A5-47DA-9689-3D1596E2EF47@apple.com>
Message-ID: <78C9C3A2-2CD0-494C-9085-D0D411CABCBA@newgeo.com>

Doing this sucks:

variant lang_brazilian             description "Use Brazilian language  
for server messages" { configure.args-append --with-language=brazilian }

variant lang_czech                 description "Use Czech language for  
server messages" { configure.args-append --with-language=czech }

repeat 15 more times...
it also does not add in the fact that one language is going to  
conflict with another.

So I made a tcp iteration that generated the correct code for the  
portfile from a list.  I can copy the output into the file, but would  
rather it eval in place.

I can not get the eval to work when I run port variants pure-ftpd, it  
just ignores it.
-- 
Scott * If you contact me off list replace talklists@ with scott@ *

On Nov 6, 2009, at 6:10 PM, Jordan K. Hubbard wrote:

> Well, I read your message a couple of times and still don't really  
> see a question in there anywhere.  What specifically are you asking?


From akitada at macports.org  Fri Nov  6 20:03:56 2009
From: akitada at macports.org (Akira Kitada)
Date: Sat, 7 Nov 2009 13:03:56 +0900
Subject: Any interest in using git for scm?
In-Reply-To: <b808b3510911051746i2b720381wb7550c1eac2e85a4@mail.gmail.com>
References: <b808b3510911051746i2b720381wb7550c1eac2e85a4@mail.gmail.com>
Message-ID: <90bb445a0911062003i71df7691h7dba82737f1bfdc4@mail.gmail.com>

Hello Darren,

I posted a similar question on the list before and failed :-)

http://marc.info/?t=124395706900073&r=1&w=2

On Fri, Nov 6, 2009 at 10:46 AM, Darren Weber <dweber at macports.org> wrote:
>
> After listening to Linus Torvalds talk about git and looking at a video
> tutorial from Scott Chacon, it would seem beneficial to use git for MacPorts
> development.? It appears that git can be used with an existing svn
> repository (man git-svn), or the svn repository could be imported into a new
> master git repository (perhaps host it with github).? Is anyone currently
> using git for MacPorts development?
>
> After a few tips from MacPorts gurus and some experiments, I was able to
> draft the instructions at
>
> Create an experimental users directory in the MacPorts Subversion repository
>
> http://trac.macports.org/wiki/CommittersTipsAndTricks
>
> The merge process with svn takes a while to grok, but it works OK.? Is
> anyone having an easier time with git?
>
> The resources here are helpful in learning git:
> http://www.linuxfoundation.org/search/node/git
>
> Take care,
> Darren
>
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>
>

From dweber at macports.org  Fri Nov  6 20:47:19 2009
From: dweber at macports.org (Darren Weber)
Date: Fri, 6 Nov 2009 20:47:19 -0800
Subject: Any interest in using git for scm?
In-Reply-To: <90bb445a0911062003i71df7691h7dba82737f1bfdc4@mail.gmail.com>
References: <b808b3510911051746i2b720381wb7550c1eac2e85a4@mail.gmail.com>
	<90bb445a0911062003i71df7691h7dba82737f1bfdc4@mail.gmail.com>
Message-ID: <b808b3510911062047x74a97fe5ha93ba44049fc1196@mail.gmail.com>

Interesting thread.  Has there been any change in git-svn to support
keywords like Id?


On Fri, Nov 6, 2009 at 8:03 PM, Akira Kitada <akitada at macports.org> wrote:

> Hello Darren,
>
> I posted a similar question on the list before and failed :-)
>
> http://marc.info/?t=124395706900073&r=1&w=2
>
> On Fri, Nov 6, 2009 at 10:46 AM, Darren Weber <dweber at macports.org> wrote:
> >
> > After listening to Linus Torvalds talk about git and looking at a video
> > tutorial from Scott Chacon, it would seem beneficial to use git for
> MacPorts
> > development.  It appears that git can be used with an existing svn
> > repository (man git-svn), or the svn repository could be imported into a
> new
> > master git repository (perhaps host it with github).  Is anyone currently
> > using git for MacPorts development?
> >
> > After a few tips from MacPorts gurus and some experiments, I was able to
> > draft the instructions at
> >
> > Create an experimental users directory in the MacPorts Subversion
> repository
> >
> > http://trac.macports.org/wiki/CommittersTipsAndTricks
> >
> > The merge process with svn takes a while to grok, but it works OK.  Is
> > anyone having an easier time with git?
> >
> > The resources here are helpful in learning git:
> > http://www.linuxfoundation.org/search/node/git
> >
> > Take care,
> > Darren
> >
> >
> > _______________________________________________
> > macports-dev mailing list
> > macports-dev at lists.macosforge.org
> > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20091106/32626bfb/attachment.html>

From dweber at macports.org  Fri Nov  6 21:05:13 2009
From: dweber at macports.org (Darren Weber)
Date: Fri, 6 Nov 2009 21:05:13 -0800
Subject: Any interest in using git for scm?
In-Reply-To: <90bb445a0911062003i71df7691h7dba82737f1bfdc4@mail.gmail.com>
References: <b808b3510911051746i2b720381wb7550c1eac2e85a4@mail.gmail.com>
	<90bb445a0911062003i71df7691h7dba82737f1bfdc4@mail.gmail.com>
Message-ID: <b808b3510911062105ob6c489ana7298ec95cb941ba@mail.gmail.com>

In any case, regardless of keyword problems (if they persist in git-svn),
I'm glad to know that the svn repo is also in a git repo that is tracking
the svn.  The git repo should provide more integrity than the svn repo and a
reliable backup for the centralized svn repo.  (I have no idea, but I assume
the Mac OS Forge guys have a backup system all wrapped up anyway, so not to
worry about that.)  The point is that the algorithms in git for sha1 checks
are not available in any other scm, AFAIK.

One advantage of the sha1 hash is that it provides a truly unique ID for any
commit, which probably surpasses the purpose of any $Id$ and other keywords
for tracking commits.  Using global config settings, like user.name and
user.email, the commits are automatically identified by the
developer/commiter and they are useful in 'git blame'.  Looking at the git
log --graph or using gitk and other git GUI tools gives a nice graph of the
branch and commit history.  It seems easy to identify where any changes came
from.  No need for an Id guidelines and associated developer conformity ;-)
(That may be one reason that git doesn't support keywords ;-)).

Take care,
Darren

PPS, For keyword issues, see:
http://stackoverflow.com/questions/39742/does-git-have-anything-like-svn-propset-svnkeywords-or-pre-post-commit-hooks
http://stackoverflow.com/questions/62264/dealing-with-svn-keyword-expansion-with-git-svn#72874




On Fri, Nov 6, 2009 at 8:03 PM, Akira Kitada <akitada at macports.org> wrote:

> Hello Darren,
>
> I posted a similar question on the list before and failed :-)
>
> http://marc.info/?t=124395706900073&r=1&w=2
>
> On Fri, Nov 6, 2009 at 10:46 AM, Darren Weber <dweber at macports.org> wrote:
> >
> > After listening to Linus Torvalds talk about git and looking at a video
> > tutorial from Scott Chacon, it would seem beneficial to use git for
> MacPorts
> > development.  It appears that git can be used with an existing svn
> > repository (man git-svn), or the svn repository could be imported into a
> new
> > master git repository (perhaps host it with github).  Is anyone currently
> > using git for MacPorts development?
> >
> > After a few tips from MacPorts gurus and some experiments, I was able to
> > draft the instructions at
> >
> > Create an experimental users directory in the MacPorts Subversion
> repository
> >
> > http://trac.macports.org/wiki/CommittersTipsAndTricks
> >
> > The merge process with svn takes a while to grok, but it works OK.  Is
> > anyone having an easier time with git?
> >
> > The resources here are helpful in learning git:
> > http://www.linuxfoundation.org/search/node/git
> >
> > Take care,
> > Darren
> >
> >
> > _______________________________________________
> > macports-dev mailing list
> > macports-dev at lists.macosforge.org
> > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20091106/f732cd4c/attachment.html>

From dweber at macports.org  Fri Nov  6 21:24:09 2009
From: dweber at macports.org (Darren Weber)
Date: Fri, 6 Nov 2009 21:24:09 -0800
Subject: Any interest in using git for scm?
In-Reply-To: <b808b3510911062105ob6c489ana7298ec95cb941ba@mail.gmail.com>
References: <b808b3510911051746i2b720381wb7550c1eac2e85a4@mail.gmail.com>
	<90bb445a0911062003i71df7691h7dba82737f1bfdc4@mail.gmail.com>
	<b808b3510911062105ob6c489ana7298ec95cb941ba@mail.gmail.com>
Message-ID: <b808b3510911062124v87812a9i67f94366ff0c4de5@mail.gmail.com>

On Fri, Nov 6, 2009 at 9:05 PM, Darren Weber <dweber at macports.org> wrote:

>
> In any case, regardless of keyword problems (if they persist in git-svn),
> I'm glad to know that the svn repo is also in a git repo that is tracking
> the svn.  The git repo should provide more integrity than the svn repo and a
> reliable backup for the centralized svn repo.  (I have no idea, but I assume
> the Mac OS Forge guys have a backup system all wrapped up anyway, so not to
> worry about that.)  The point is that the algorithms in git for sha1 checks
> are not available in any other scm, AFAIK.
>
> One advantage of the sha1 hash is that it provides a truly unique ID for
> any commit, which probably surpasses the purpose of any $Id$ and other
> keywords for tracking commits.  Using global config settings, like
> user.name and user.email, the commits are automatically identified by the
> developer/commiter and they are useful in 'git blame'.  Looking at the git
> log --graph or using gitk and other git GUI tools gives a nice graph of the
> branch and commit history.  It seems easy to identify where any changes came
> from.  No need for an Id guidelines and associated developer conformity ;-)
> (That may be one reason that git doesn't support keywords ;-)).
>
> Take care,
> Darren
>
> PPS, For keyword issues, see:
>
> http://stackoverflow.com/questions/39742/does-git-have-anything-like-svn-propset-svnkeywords-or-pre-post-commit-hooks
>
> http://stackoverflow.com/questions/62264/dealing-with-svn-keyword-expansion-with-git-svn#72874
>
>
PS, Useful similarities between git and svn commands:
http://git.or.cz/course/svn.html





>
>
>
> On Fri, Nov 6, 2009 at 8:03 PM, Akira Kitada <akitada at macports.org> wrote:
>
>> Hello Darren,
>>
>> I posted a similar question on the list before and failed :-)
>>
>> http://marc.info/?t=124395706900073&r=1&w=2
>>
>> On Fri, Nov 6, 2009 at 10:46 AM, Darren Weber <dweber at macports.org>
>> wrote:
>> >
>> > After listening to Linus Torvalds talk about git and looking at a video
>> > tutorial from Scott Chacon, it would seem beneficial to use git for
>> MacPorts
>> > development.  It appears that git can be used with an existing svn
>> > repository (man git-svn), or the svn repository could be imported into a
>> new
>> > master git repository (perhaps host it with github).  Is anyone
>> currently
>> > using git for MacPorts development?
>> >
>> > After a few tips from MacPorts gurus and some experiments, I was able to
>> > draft the instructions at
>> >
>> > Create an experimental users directory in the MacPorts Subversion
>> repository
>> >
>> > http://trac.macports.org/wiki/CommittersTipsAndTricks
>> >
>> > The merge process with svn takes a while to grok, but it works OK.  Is
>> > anyone having an easier time with git?
>> >
>> > The resources here are helpful in learning git:
>> > http://www.linuxfoundation.org/search/node/git
>> >
>> > Take care,
>> > Darren
>> >
>> >
>> > _______________________________________________
>> > macports-dev mailing list
>> > macports-dev at lists.macosforge.org
>> > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>> >
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20091106/99b34d81/attachment-0001.html>

From akitada at macports.org  Fri Nov  6 21:33:16 2009
From: akitada at macports.org (Akira Kitada)
Date: Sat, 7 Nov 2009 14:33:16 +0900
Subject: Any interest in using git for scm?
In-Reply-To: <b808b3510911062047x74a97fe5ha93ba44049fc1196@mail.gmail.com>
References: <b808b3510911051746i2b720381wb7550c1eac2e85a4@mail.gmail.com> 
	<90bb445a0911062003i71df7691h7dba82737f1bfdc4@mail.gmail.com> 
	<b808b3510911062047x74a97fe5ha93ba44049fc1196@mail.gmail.com>
Message-ID: <90bb445a0911062133u370ae3a7nb0b1fd8a0fae33e2@mail.gmail.com>

Not sure about git but Mercurial does have an extension for it
http://mercurial.selenic.com/wiki/KeywordExtension

On Sat, Nov 7, 2009 at 1:47 PM, Darren Weber <dweber at macports.org> wrote:
>
> Interesting thread.? Has there been any change in git-svn to support
> keywords like Id?
>
>
> On Fri, Nov 6, 2009 at 8:03 PM, Akira Kitada <akitada at macports.org> wrote:
>>
>> Hello Darren,
>>
>> I posted a similar question on the list before and failed :-)
>>
>> http://marc.info/?t=124395706900073&r=1&w=2
>>
>> On Fri, Nov 6, 2009 at 10:46 AM, Darren Weber <dweber at macports.org> wrote:
>> >
>> > After listening to Linus Torvalds talk about git and looking at a video
>> > tutorial from Scott Chacon, it would seem beneficial to use git for
>> > MacPorts
>> > development.? It appears that git can be used with an existing svn
>> > repository (man git-svn), or the svn repository could be imported into a
>> > new
>> > master git repository (perhaps host it with github).? Is anyone
>> > currently
>> > using git for MacPorts development?
>> >
>> > After a few tips from MacPorts gurus and some experiments, I was able to
>> > draft the instructions at
>> >
>> > Create an experimental users directory in the MacPorts Subversion
>> > repository
>> >
>> > http://trac.macports.org/wiki/CommittersTipsAndTricks
>> >
>> > The merge process with svn takes a while to grok, but it works OK.? Is
>> > anyone having an easier time with git?
>> >
>> > The resources here are helpful in learning git:
>> > http://www.linuxfoundation.org/search/node/git
>> >
>> > Take care,
>> > Darren
>> >
>> >
>> > _______________________________________________
>> > macports-dev mailing list
>> > macports-dev at lists.macosforge.org
>> > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>> >
>> >
>
>

From jkh at apple.com  Fri Nov  6 22:02:04 2009
From: jkh at apple.com (Jordan K. Hubbard)
Date: Fri, 6 Nov 2009 22:02:04 -0800
Subject: Invoking tcl
In-Reply-To: <78C9C3A2-2CD0-494C-9085-D0D411CABCBA@newgeo.com>
References: <BAE2CDCE-66A1-4A8C-9628-56E208D320DF@newgeo.com>
	<9DFEB088-A3A8-4C97-80BD-12C0E04D1825@lavergne.gotdns.org>
	<B189539F-BF78-4B45-B28C-7E708A81B11D@newgeo.com>
	<53B292DE-1B8A-4039-96AE-99E37F89D952@newgeo.com>
	<77B41AE8-09A5-47DA-9689-3D1596E2EF47@apple.com>
	<78C9C3A2-2CD0-494C-9085-D0D411CABCBA@newgeo.com>
Message-ID: <C41A3EEA-D638-4A41-8480-3E55729E4B8A@apple.com>


On Nov 6, 2009, at 6:24 PM, Scott Haneda wrote:

> Doing this sucks:
> 
> variant lang_brazilian             description "Use Brazilian language for server messages" { configure.args-append --with-language=brazilian }
> 
> variant lang_czech                 description "Use Czech language for server messages" { configure.args-append --with-language=czech }

And how many ports do that?  I mean, if this pattern is pervasive across the collection then you probably want to create some sort of "lang" procedure which sets the appropriate configure args and checks an internal variable to see if two languages have been specified in conflict.  Otherwise, you'd still have to stick the same work procedure into each Portfile that wanted to use it, so I'm not sure how much it would save you unless each port also declared such variants multiple times.

> I can not get the eval to work when I run port variants pure-ftpd, it just ignores it.

Well, variant is itself a procedure and it's probably not going to eval its arguments in the way you want, unless you mean something else here...  Otherwise, you can insert any Tcl code you like into a Portfile and it will run if called through one of the existing hooks, so a hook proc could always create an expression dynamically and eval that, if that's what you want...

- Jordan

From blair at orcaware.com  Sat Nov  7 08:18:41 2009
From: blair at orcaware.com (Blair Zajac)
Date: Sat, 7 Nov 2009 08:18:41 -0800
Subject: Any interest in using git for scm?
In-Reply-To: <b808b3510911061212g500a894aq86a6a165a4802d7c@mail.gmail.com>
References: <b808b3510911051746i2b720381wb7550c1eac2e85a4@mail.gmail.com>
	<D21C1E11-22E3-4C26-89D7-CA351215A788@apple.com>
	<b808b3510911061212g500a894aq86a6a165a4802d7c@mail.gmail.com>
Message-ID: <482EC7D1-DD25-4992-B355-0806218A5E73@orcaware.com>


On Nov 6, 2009, at 12:12 PM, Darren Weber wrote:

>
>
> On Fri, Nov 6, 2009 at 10:49 AM, William Siegrist  
> <wsiegrist at apple.com> wrote:
> On Nov 5, 2009, at 5:46 PM, Darren Weber wrote:
>
> >
> > After listening to Linus Torvalds talk about git and looking at a  
> video tutorial from Scott Chacon, it would seem beneficial to use  
> git for MacPorts development.  It appears that git can be used with  
> an existing svn repository (man git-svn), or the svn repository  
> could be imported into a new master git repository (perhaps host it  
> with github).  Is anyone currently using git for MacPorts development?
> >
>
> Mac OS Forge (the hosting provider MacPorts lives on) does not  
> currently provide read-write git repos. But we do provide a git  
> mirror of the svn repo.  That at least saves you some time when  
> creating your local git repo.
>
> https://www.macosforge.org/post/git-mirrors/
>
> -Bill
>
> In general, it is very interesting to see how git has evolved to  
> solve the challenges of distributed source code development for the  
> linux kernel.  It's able to handle thousands of files and hundreds  
> or thousands of contributors, with high performance and integrity  
> criteria.  While it's healthy to maintain some scepticism about  
> drinking any particular flavor of cool-aid, the git cool-aid looks  
> impressive ;-)  After listening to the Google tech talk from Linus,  
> one of the most striking things about git is the sha1 hash to  
> maintain integrity in the repo objects (other significant features  
> include the distributed repos for local work, true 'content'  
> management [full patches, not just file management], staging commits  
> like a transaction, easier and faster merging, etc.).  The sha1 is  
> used to guarantee that what goes in is exactly what comes out.  As  
> he put it, this evolved from an attempt to hack the linux source  
> code when it was managed under BitKeeper (which did provide a  
> detection for the hacks).  It's not exactly a security feature, it  
> provides an integrity check and a byproduct of that is the ability  
> to detect corruption.  The distributed nature of the git repos is  
> also a default backup system of a sort.
>
> Given the sha1 integrity checks in git (not available in any other  
> scm yet?), an import of source code from cvs, svn etc. into git is a  
> persuasive argument.  Are there any faults or gaps in that argument?

Don't drink too much of the cool aid :)

Subversion maintains a md5 hash of all committed items and does  
consistency checks upon them when there are any operations.  There are  
hashes in the repository and in the client side checkouts to ensure  
that all operations are done correctly.

Subversion 1.7 is going to be using sha1 hashes in some places where  
md5 hashes are currently used.

Blair


From blair at orcaware.com  Sat Nov  7 14:03:36 2009
From: blair at orcaware.com (Blair Zajac)
Date: Sat, 07 Nov 2009 14:03:36 -0800
Subject: Any interest in using git for scm?
In-Reply-To: <b808b3510911062105ob6c489ana7298ec95cb941ba@mail.gmail.com>
References: <b808b3510911051746i2b720381wb7550c1eac2e85a4@mail.gmail.com>	<90bb445a0911062003i71df7691h7dba82737f1bfdc4@mail.gmail.com>
	<b808b3510911062105ob6c489ana7298ec95cb941ba@mail.gmail.com>
Message-ID: <4AF5EEB8.2000503@orcaware.com>

Darren Weber wrote:
> 
> In any case, regardless of keyword problems (if they persist in 
> git-svn), I'm glad to know that the svn repo is also in a git repo that 
> is tracking the svn.  The git repo should provide more integrity than 
> the svn repo and a reliable backup for the centralized svn repo.  (I 
> have no idea, but I assume the Mac OS Forge guys have a backup system 
> all wrapped up anyway, so not to worry about that.)  The point is that 
> the algorithms in git for sha1 checks are not available in any other 
> scm, AFAIK.

How does a git repo provide more integrity than svn?  There's nothing else in 
svn than we do to ensure that the repository and working copies are correctly 
protected.

Before making comparisions between git and svn, please do ask about the svn 
implementation.  I get the sense you've already decided and are interested about 
making a fair comparison.

> One advantage of the sha1 hash is that it provides a truly unique ID for 
> any commit, which probably surpasses the purpose of any $Id$ and other 
> keywords for tracking commits.  Using global config settings, like 
> user.name <http://user.name> and user.email, the commits are 
> automatically identified by the developer/commiter and they are useful 
> in 'git blame'.  Looking at the git log --graph or using gitk and other 
> git GUI tools gives a nice graph of the branch and commit history.  It 
> seems easy to identify where any changes came from.  No need for an Id 
> guidelines and associated developer conformity ;-)  (That may be one 
> reason that git doesn't support keywords ;-)).

The svn revision number is just as unique as the sha1 hash, in fact, guaranteed 
to be unique, unlike the extremely remote possibility that you get sha1 hash 
collision.

The $Id$ doesn't provide anything to track, it's just there so you can see 
without a svn log who last made the commit.

Blair


From jeremy at lavergne.gotdns.org  Sun Nov  8 10:03:22 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Sun, 8 Nov 2009 13:03:22 -0500
Subject: macports error reporting, stack traces
Message-ID: <04009386-C82C-45B2-8AC4-954D9BA2BBB8@lavergne.gotdns.org>

Should we add the typical steps for producing debug error logs to the  
output of the standard trace during a failure?

There are often tickets where people simply place the standard output  
and not the debug output.  Would supplying the steps to do this  
directly in the standard reporting help users figure this out?


From mmoll at macports.org  Sun Nov  8 15:50:20 2009
From: mmoll at macports.org (Mark Moll)
Date: Sun, 8 Nov 2009 17:50:20 -0600
Subject: HDF5 dilemma
In-Reply-To: <b808b3510911061534u21c75bbfv1ad07eb278a0f2a8@mail.gmail.com>
References: <b808b3510911061534u21c75bbfv1ad07eb278a0f2a8@mail.gmail.com>
Message-ID: <77804094-906A-4AB2-AD78-B7F6499AC21A@macports.org>

HDF5 1.6.10 and HDF5 1.8.4 are currently in prerelease. HDF5 1.6.10 is  
the last release of the 1.6.x series. HDF5 1.8.x can also be compiled  
in 1.6.x compatibility mode, but this shouldn?t be done by default. I  
think it?s hard to make a case for the hdf5_select approach you  
suggest. First, there?s only 2 or 3 ports that need hdf5 1.6 (I  
think). Second, with gcc and python there really are many versions  
simultaneously in use. The cost of switching versions is significant  
with gcc and python and it makes sense to support multiple versions.

Since I am the maintainer of the hdf5-18 port I might be somewhat  
biased, but the least bad solution might be to have the hdf5 port  
install its files in ${prefix}/lib/hdf5-16/.

On Nov 6, 2009, at 5:34 PM, Darren Weber wrote:

>
> I've got a hdf5 dilemma ;-)
>
> $ port installed hdf5*
> The following ports are currently installed:
> hdf5 @1.6.9_0+threadsafe (active)
> hdf5-18 @1.8.3_0
> hdf5-18 @1.8.3_1
>
> $ sudo port activate hdf5-18 @1.8.3_1
> --->  Activating hdf5-18 @1.8.3_1
> Error: port activate failed: Image error: /opt/local/bin/gif2h5 is  
> being used by the active hdf5 port.  Please deactivate this port  
> first, or use 'port -f activate hdf5-18' to force the activation.
>
> The hdf5 and hdf5-18 ports are behaving like separate ports, up to  
> the point of activation conflicts.  There are two maintainers for  
> these ports (in the CC list of this email); can we get together on  
> this and work out the activation conflict?
>
> Is it possible to have multiple version specific libs/bins  
> installed?  Is it as simple as providing some version specific file- 
> name mangles (with symlinks and maybe a hdf5_select utility like the  
> gcc_select or python_select utility)?
>
> A quick search on the user email list brings up a number of ports  
> that depend on hdf5 with dependency build issues.
>
> What is the current status of play on hdf5 and what is the  
> recommended version to have installed?
>
> Take care,
> Darren
>

-- 
Mark



-- 
Mark



-- 
Mark




From talklists at newgeo.com  Sun Nov  8 16:27:04 2009
From: talklists at newgeo.com (Scott Haneda)
Date: Sun, 8 Nov 2009 16:27:04 -0800
Subject: macports error reporting, stack traces
In-Reply-To: <04009386-C82C-45B2-8AC4-954D9BA2BBB8@lavergne.gotdns.org>
References: <04009386-C82C-45B2-8AC4-954D9BA2BBB8@lavergne.gotdns.org>
Message-ID: <B9A99687-5E49-48BD-9511-B6EB9E4D57A0@newgeo.com>

On Nov 8, 2009, at 10:03 AM, Jeremy Lavergne wrote:

> Should we add the typical steps for producing debug error logs to  
> the output of the standard trace during a failure?
>
> There are often tickets where people simply place the standard  
> output and not the debug output.  Would supplying the steps to do  
> this directly in the standard reporting help users figure this out?

Simply put, yes.  When in non debug, this message would be seen, and  
more than likely would be followed.  People are not going to read all  
the docs on how to post a proper report.  Hell, I have been around  
here long enough, and my port bug reports are far from perfect :)

I like the idea.

If my trac searching was better, I would go read and look over the  
issue to log the errors to a file, so it is even easier to generate a  
bug report.

When an error is hit, a file should be made that contains whatever  
suitable data is needed to allow the user to provide a good report.   
If that means a system profiler, uname, actual -d, and whatever else,  
it should be there.

There never should be a case in trac where the question of "Can you  
run -d and provide us that data", and "what os, how much ran, what  
architecture", etc, those should not be burdens on the user, and those  
should not stall a trac ticket waiting for the answer.

No user burden, and no developer/maintainer/manager burden needs to be  
a goal.  Fix bug, not waste time getting to the point where you can  
maybe start to consider fixing a bug.

People on the dev list get this, but a normal non dev user list user;  
in my opinion, we are lucky they even made it to the mailing list, let  
alone to trac.

My ideal situation:
Oops, looks like you ran into a build bug, please click this link, and  
a report will be auto entered into our trac system.  This will take  
them to a page where if they have an account, they can login, and the  
report will be connected to their account. Or they can "post bug  
anonymously".

They key is to get the data into the system, with as much detail as  
possible, and as little end user friction as possible.
-- 
Scott * If you contact me off list replace talklists@ with scott@ *


From ryandesign at macports.org  Sun Nov  8 16:52:04 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 8 Nov 2009 18:52:04 -0600
Subject: [60303] trunk/dports/sysutils/memcached/Portfile
In-Reply-To: <20091108210331.A58633052AC1@beta.macosforge.org>
References: <20091108210331.A58633052AC1@beta.macosforge.org>
Message-ID: <4470A018-FACA-4818-9956-56CB999B925B@macports.org>


On Nov 8, 2009, at 15:03, brett at macports.org wrote:

> Revision: 60303
>          http://trac.macports.org/changeset/60303
> Author:   brett at macports.org
> Date:     2009-11-08 13:03:31 -0800 (Sun, 08 Nov 2009)
> Log Message:
> -----------
> add umem variant to memcached


> +variant umem description {enable libumem support} {
> +    depends_lib-append     port:umem
> +}

The variant should do more than just add a dependency: it should also  
add a configure arg or environment variable or something that tells  
memcached that it's ok to use umem -- and you may have to add  
something to the default port build so that it will *not* use umem,  
even if umem is installed, unless the umem variant is selected.




From ryandesign at macports.org  Sun Nov  8 16:54:40 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 8 Nov 2009 18:54:40 -0600
Subject: [60317] trunk/dports/audio/libmpdclient/Portfile
In-Reply-To: <20091108234227.A48AA305F5E5@beta.macosforge.org>
References: <20091108234227.A48AA305F5E5@beta.macosforge.org>
Message-ID: <6EEFE3DE-7654-4B8E-A0AE-423FDB60A9C3@macports.org>


On Nov 8, 2009, at 17:42, rmsfisher at macports.org wrote:

> Revision: 60317
>          http://trac.macports.org/changeset/60317
> Author:   rmsfisher at macports.org
> Date:     2009-11-08 15:42:26 -0800 (Sun, 08 Nov 2009)
> Log Message:
> -----------
> audio/libmpdclient added dependency, use_autoreconf



> +depends_lib         port:automake

Are you sure automake is a library dependency? I would have expected  
it to be a build dependency only.




From ryandesign at macports.org  Sun Nov  8 16:57:06 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 8 Nov 2009 18:57:06 -0600
Subject: [60290] trunk/dports/lang/g95
In-Reply-To: <20091108134443.72AB5303CC5F@beta.macosforge.org>
References: <20091108134443.72AB5303CC5F@beta.macosforge.org>
Message-ID: <358D32A0-0345-49F3-A609-22C8E8079F37@macports.org>


On Nov 8, 2009, at 07:44, takeshi at macports.org wrote:

> Revision: 60290
>          http://trac.macports.org/changeset/60290
> Author:   takeshi at macports.org
> Date:     2009-11-08 05:44:39 -0800 (Sun, 08 Nov 2009)
> Log Message:
> -----------
> g95: Updated for Snow Leopard (links to gcc-4.2.4, defalut_variants  
> gcc42). Variant gcc42 works on Intel Mac but PPC Mac

Did you mean "works on Intel Mac but *NOT* PPC Mac"? If so, do you do  
anything to prevent a PowerPC user from trying to use that variant?


From ryandesign at macports.org  Sun Nov  8 17:33:42 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 8 Nov 2009 19:33:42 -0600
Subject: [60326] trunk/dports/audio/libmpdclient/Portfile
In-Reply-To: <20091109012835.377843067B3E@beta.macosforge.org>
References: <20091109012835.377843067B3E@beta.macosforge.org>
Message-ID: <BD451D82-C835-4AF5-8D13-BB70A013F48C@macports.org>


On Nov 8, 2009, at 19:28, rmsfisher at macports.org wrote:

> Revision: 60326
>          http://trac.macports.org/changeset/60326
> Author:   rmsfisher at macports.org
> Date:     2009-11-08 17:28:34 -0800 (Sun, 08 Nov 2009)
> Log Message:
> -----------
> audio/libmpdclient changed library dependency to build dependency  
> per Ryan's suggestion


> -depends_lib         port:automake
> +depends_build       port:automake

Actually, I'm sorry, I should have added that you don't need to  
specify it at all, because MacPorts already does for you because you  
added "use_autoreconf yes". See the output of "port lint":


--->  Verifying Portfile for libmpdclient
Warning: Dependency port:automake specified multiple times in  
depends_build
--->  0 errors and 1 warnings found.





From ryandesign at macports.org  Sun Nov  8 17:39:39 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 8 Nov 2009 19:39:39 -0600
Subject: [60204] trunk/dports/net/dnsmasq/Portfile
In-Reply-To: <20091105025153.D69FD2F3EC30@beta.macosforge.org>
References: <20091105025153.D69FD2F3EC30@beta.macosforge.org>
Message-ID: <88112FBC-8C7D-4A23-900E-83E6E9998C83@macports.org>

On Nov 4, 2009, at 20:51, snc at macports.org wrote:

> Revision: 60204
>          http://trac.macports.org/changeset/60204
> Author:   snc at macports.org
> Date:     2009-11-04 18:51:49 -0800 (Wed, 04 Nov 2009)
> Log Message:
> -----------
> add our own launchd script


> +    # If on Tiger or above, setup a launchd item.  The daemondo  
> wrapper is not
> +    # needed.
> +    #
> +    if {${os.major} >= 8} {

BTW, you don't need this check, because MacPorts 1.8.0 requires Darwin  
8 or above.



From ryandesign at macports.org  Sun Nov  8 17:45:15 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 8 Nov 2009 19:45:15 -0600
Subject: [60158] trunk/dports/devel
In-Reply-To: <20091103193607.0588A2EB6142@beta.macosforge.org>
References: <20091103193607.0588A2EB6142@beta.macosforge.org>
Message-ID: <804E19C5-98A5-4B24-8E96-BE9B2527D98C@macports.org>


On Nov 3, 2009, at 13:36, wsiegrist at apple.com wrote:

> Revision: 60158
>          http://trac.macports.org/changeset/60158
> Author:   wsiegrist at apple.com
> Date:     2009-11-03 11:36:03 -0800 (Tue, 03 Nov 2009)
> Log Message:
> -----------
> New darwinbuild ports to handle xcode conversion and legacy darwin  
> support.


> +	if {![variant_isset universal]} {
> +		return -code error "You must install ${name} with the universal  
> variant.\
> +				    Try running `port install ${name} +universal` "
> +	}	

You could use "default_variants +universal" to make this happen  
automatically. In the sleepwatcher port, I do it like this:


default_variants +universal
variant universal {}
pre-fetch {
     if {![variant_isset universal]} {
         return -code error "${name} is only available in a universal  
version"
     }
}




From ryandesign at macports.org  Sun Nov  8 18:38:48 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 8 Nov 2009 20:38:48 -0600
Subject: Three perl port submissions;
	p5-io, p5-io-socket-inet6, p5-lwp-attic
In-Reply-To: <FB547A20-E9C9-4B8B-9605-3422D34D3224@newgeo.com>
References: <FB547A20-E9C9-4B8B-9605-3422D34D3224@newgeo.com>
Message-ID: <8D243D66-7855-449A-BF71-6714F4C47295@macports.org>


On Oct 30, 2009, at 04:32, Scott Haneda wrote:

> I just went through all my local port repo's, and found which ones  
> were not in MacPorts official, and which were local to only me.  I  
> have three it appears that are ready for submission.
>
> As far as I can tell, there are no dependencies within these.  I  
> needed them for a software I was using, and quickly put them  
> together.  That software appears to work, so I am assuming these  
> work as well.
>
> https://trac.macports.org/ticket/22306
> https://trac.macports.org/ticket/22307
> https://trac.macports.org/ticket/22308

Added! Thanks.




From talklists at newgeo.com  Sun Nov  8 19:05:53 2009
From: talklists at newgeo.com (Scott Haneda)
Date: Sun, 8 Nov 2009 19:05:53 -0800
Subject: Diff supplied to track for libsdl
Message-ID: <A60C85DB-CEDD-43A1-B4C7-ECFCD1B19FF6@newgeo.com>

See: http://lists.macosforge.org/pipermail/macports-users/2009-November/017557.html

Here is a diff, which makes libsdl_mixer install clean
http://trac.macports.org/ticket/22425
-- 
Scott * If you contact me off list replace talklists@ with scott@ *


From jkh at apple.com  Sun Nov  8 19:13:02 2009
From: jkh at apple.com (Jordan K. Hubbard)
Date: Sun, 8 Nov 2009 19:13:02 -0800
Subject: macports error reporting, stack traces
In-Reply-To: <04009386-C82C-45B2-8AC4-954D9BA2BBB8@lavergne.gotdns.org>
References: <04009386-C82C-45B2-8AC4-954D9BA2BBB8@lavergne.gotdns.org>
Message-ID: <70FD4384-89A4-4664-AD2C-00DF53F71C5B@apple.com>


On Nov 8, 2009, at 10:03 AM, Jeremy Lavergne wrote:

> Should we add the typical steps for producing debug error logs to the output of the standard trace during a failure?

That certainly sounds like something that should be documented, though one would almost wish to then render that documentation obsolete by dumping debug output on error.  In other words, ui_debug would always generate debug information, the Debug flag merely indicating what the output fd was.  If not set, it's set to some temporary file which has already been unlinked (the open, unlink truck) but has a fd that can be rewound and copied to stderr on error, and if it's set then the fd points directly to stderr.  Whatever routine catches errors for a port build would be responsible for dumping the error log.  Sounds like an excellent Tcl / MacPorts base beginner's project. :)

- Jordan


From talklists at newgeo.com  Sun Nov  8 20:59:51 2009
From: talklists at newgeo.com (Scott Haneda)
Date: Sun, 8 Nov 2009 20:59:51 -0800
Subject: port command timing
Message-ID: <47E77CF5-F9D9-4E6A-B401-657521C49783@newgeo.com>

I have no way of testing this empirically any longer.  I am on 1.8+ on  
all machines now.  `port info portname`, `port search pattern`, and  
especially, though seemingly not all the time, `port installed` take a  
lot longer to run than they used to under 1.7. (Feels that way at least)

The one that is very noticeable, as I never used `port info portname`  
that much, instead, I have used `port edit portname` to see what the  
port is, and answer any questions I may have pre-install.

As with 1.7, I did this to .profile:
# For MacPorts to use the correct editor locally, and pico remotely
# Can remove the call to `mate` on remote machine, needs window server
export DISPLAY=:0.0
export EDITOR=/usr/bin/pico
if [[ -z $SSH_CLIENT ]]; then
        export EDITOR=/Users/me/bin/mate
else
        export EDITOR=/usr/bin/pico
fi;

I think MacPorts defaults to vi for a normal unchanged install, though  
echo $EDITOR returns nothing.  Where is this defined when not set via  
an export? Is it vi?  I never can seem to get the basic os what i need  
to know about that apps usage to be even remotely proficient.

At any rate, `port edit portname` takes a long time.  In the case of  
being local, and using `mate`, a way to send arbitrary data to open in  
TextMate, that takes the longest.  Yes, textMate is already launched.   
You can do nice things like `mate ~/macports/category/portname/` and  
it will open a project of all the files.

$echo "foo" | ~/bin/mate
	Opens TextMate instantly, under 1 second, with 'foo' in a new
	document, even if TextMate is not open, TextMate is a fast launcher  
regardless.

$port edit portname
	Regardless of port size, 3x, or more, to open TextMate.  The same is  
true
	on another machine where I only have ssh access, so `mate` is not part
	of my .profile, I just changed it to pico/nano.

This slowness is following me from one machine to another.  Not a big  
deal at all, I am talking seconds here, and in large part, a  
"feeling".  But I am just wondering, did 1.8 slow down in some regards?

-- 
Scott * If you contact me off list replace talklists@ with scott@ *


From ryandesign at macports.org  Sun Nov  8 21:58:24 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 8 Nov 2009 23:58:24 -0600
Subject: [59620] trunk/dports/java/javassist/
In-Reply-To: <20091017231412.370002A49603@beta.macosforge.org>
References: <20091017231412.370002A49603@beta.macosforge.org>
Message-ID: <F71A7D2E-3457-4147-BBF1-6E43F1687D8D@macports.org>


On Oct 17, 2009, at 18:14, nox at macports.org wrote:

> Revision: 59620
>          http://trac.macports.org/changeset/59620
> Author:   nox at macports.org
> Date:     2009-10-17 16:14:09 -0700 (Sat, 17 Oct 2009)
> Log Message:
> -----------
> javassist: New port.
>
> Added Paths:
> -----------
>    trunk/dports/java/javassist/

You only added an empty directory. Do you have a Portfile to go in  
there too? :)




From jmr at macports.org  Mon Nov  9 04:03:12 2009
From: jmr at macports.org (Joshua Root)
Date: Mon, 09 Nov 2009 23:03:12 +1100
Subject: macports error reporting, stack traces
In-Reply-To: <70FD4384-89A4-4664-AD2C-00DF53F71C5B@apple.com>
References: <04009386-C82C-45B2-8AC4-954D9BA2BBB8@lavergne.gotdns.org>
	<70FD4384-89A4-4664-AD2C-00DF53F71C5B@apple.com>
Message-ID: <4AF80500.3060200@macports.org>

On 2009-11-9 14:13, Jordan K. Hubbard wrote:
> On Nov 8, 2009, at 10:03 AM, Jeremy Lavergne wrote:
> 
>> Should we add the typical steps for producing debug error logs to the output of the standard trace during a failure?
> 
> That certainly sounds like something that should be documented, though one would almost wish to then render that documentation obsolete by dumping debug output on error.  In other words, ui_debug would always generate debug information, the Debug flag merely indicating what the output fd was.  If not set, it's set to some temporary file which has already been unlinked (the open, unlink truck) but has a fd that can be rewound and copied to stderr on error, and if it's set then the fd points directly to stderr.  Whatever routine catches errors for a port build would be responsible for dumping the error log.  Sounds like an excellent Tcl / MacPorts base beginner's project. :)

That is exactly what the gsoc09-logging branch does.

- Josh

From billitch at macports.org  Mon Nov  9 05:53:22 2009
From: billitch at macports.org (Thomas de Grivel)
Date: Mon, 9 Nov 2009 14:53:22 +0100
Subject: Any interest in using git for scm?
In-Reply-To: <342C3F9D-4A27-4500-8A3D-0AEC59D0C90A@orcaware.com>
References: <b808b3510911051746i2b720381wb7550c1eac2e85a4@mail.gmail.com>
	<342C3F9D-4A27-4500-8A3D-0AEC59D0C90A@orcaware.com>
Message-ID: <4ec7f0880911090553m1e7399bey9135ba6fee1a81fe@mail.gmail.com>

2009/11/6 Blair Zajac <blair at orcaware.com>:
>
> On Nov 5, 2009, at 5:46 PM, Darren Weber wrote:
>
>>
>> After listening to Linus Torvalds talk about git and looking at a video
>> tutorial from Scott Chacon, it would seem beneficial to use git for MacPorts
>> development. ?It appears that git can be used with an existing svn
>> repository (man git-svn), or the svn repository could be imported into a new
>> master git repository (perhaps host it with github). ?Is anyone currently
>> using git for MacPorts development?
>>
>> After a few tips from MacPorts gurus and some experiments, I was able to
>> draft the instructions at
>> Create an experimental users directory in the MacPorts Subversion
>> repository
>>
>> http://trac.macports.org/wiki/CommittersTipsAndTricks
>>
>> The merge process with svn takes a while to grok, but it works OK. ?Is
>> anyone having an easier time with git?
>>
>> The resources here are helpful in learning git:
>> http://www.linuxfoundation.org/search/node/git
>
> While I use git svn on a daily on my own source code projects, I don't see
> the value in migrating from svn over to git for MacPorts for the repository.
> ?Nothing stopping people from using git to checkout from svn.
>
> Also, I don't keep a local svn checkout of the dports portion of the
> repository and the one thing I do when I want to update a port is just
> checkout the directory of the port I'm updating, which is a feature
> Subversion supports that git doesn't.

The main interest would be for very easy create / merge of overlays as
branches, it could be much stimulating from an open-source with many
contributors point of view. Non-macports devs could be provided same
SCM tools as MacPorts commiters, while still needing them for
integration into MacPorts when stable.

This could provide easy sub-communities of testers while providing
everyone with the official, stable, ports tree.

I also would say that I also switched recently to git for a few of my
own projects and am very pleased. It is much faster and helps commits
to be really atomic, both because it's not reliant on network. Also
backing up / providing a git tree is really easy, as simple as copying
a directory. Even server-side I am glad to progressively saying
goodbye to subversion's fsfs and webdav (..yuck).

-- 
 Thomas de Grivel
 http://www.lowh.net/

From brett at macports.org  Mon Nov  9 10:25:20 2009
From: brett at macports.org (Brett Eisenberg)
Date: Mon, 9 Nov 2009 10:25:20 -0800
Subject: [60303] trunk/dports/sysutils/memcached/Portfile
In-Reply-To: <4470A018-FACA-4818-9956-56CB999B925B@macports.org>
References: <20091108210331.A58633052AC1@beta.macosforge.org>
	<4470A018-FACA-4818-9956-56CB999B925B@macports.org>
Message-ID: <75C93D27-2095-48CE-B86F-2C352F150B96@macports.org>

I don't actually agree with that, nor does it make sense to needlessly  
patch memcached's autoconf configuration to support what you're  
proposing.

Given that building with umem hooks provides no material change to the  
application unless the runtime environment is modified, there's simply  
no merit to the proposed solution.

best,
Brett

On Nov 8, 2009, at 4:52 PM, Ryan Schmidt wrote:

>
> On Nov 8, 2009, at 15:03, brett at macports.org wrote:
>
>> Revision: 60303
>>         http://trac.macports.org/changeset/60303
>> Author:   brett at macports.org
>> Date:     2009-11-08 13:03:31 -0800 (Sun, 08 Nov 2009)
>> Log Message:
>> -----------
>> add umem variant to memcached
>
>
>> +variant umem description {enable libumem support} {
>> +    depends_lib-append     port:umem
>> +}
>
> The variant should do more than just add a dependency: it should  
> also add a configure arg or environment variable or something that  
> tells memcached that it's ok to use umem -- and you may have to add  
> something to the default port build so that it will *not* use umem,  
> even if umem is installed, unless the umem variant is selected.
>
>
>
>
> !DSPAM:1000,4af767bc91021468!
>


From blair at orcaware.com  Mon Nov  9 10:38:47 2009
From: blair at orcaware.com (Blair Zajac)
Date: Mon, 09 Nov 2009 10:38:47 -0800
Subject: [60303] trunk/dports/sysutils/memcached/Portfile
In-Reply-To: <75C93D27-2095-48CE-B86F-2C352F150B96@macports.org>
References: <20091108210331.A58633052AC1@beta.macosforge.org>	<4470A018-FACA-4818-9956-56CB999B925B@macports.org>
	<75C93D27-2095-48CE-B86F-2C352F150B96@macports.org>
Message-ID: <4AF861B7.5040909@orcaware.com>

You actually do have to do this.  The reason is if you uninstall umem then the 
memcached port will fail.  MacPorts must warn the user if they are uninstalling 
a port if it'll break any other ports:

bash-3.2# memcached -v -u root
^CSIGINT handled.
bash-3.2# port -v uninstall umem
--->  Deactivating umem @1.0.1_0
--->  Uninstalling umem @1.0.1_0
--->  Uninstall is removing umem from the port registry.
bash-3.2# memcached -v -u root
dyld: Library not loaded: /opt/local/lib/libumem.0.dylib
   Referenced from: /opt/local/bin/memcached
   Reason: image not found
Trace/BPT trap

The standard in MacPorts is if you can pick up a dependency upon configuration 
time then you either need to specify a dependency upon it in the Portfile or not 
list it as a dependency and then tell configure not to find it.

In your case, I think adding a default ac_cv_search_umem_cache_create=no 
environmental variable should be sufficient to disable umem.  You also may need 
to do this for ac_cv_search_gethugepagesizes=no

Regards,
Blair

Brett Eisenberg wrote:
> I don't actually agree with that, nor does it make sense to needlessly 
> patch memcached's autoconf configuration to support what you're proposing.
> 
> Given that building with umem hooks provides no material change to the 
> application unless the runtime environment is modified, there's simply 
> no merit to the proposed solution.
> 
> best,
> Brett
> 
> On Nov 8, 2009, at 4:52 PM, Ryan Schmidt wrote:
> 
>>
>> On Nov 8, 2009, at 15:03, brett at macports.org wrote:
>>
>>> Revision: 60303
>>>         http://trac.macports.org/changeset/60303
>>> Author:   brett at macports.org
>>> Date:     2009-11-08 13:03:31 -0800 (Sun, 08 Nov 2009)
>>> Log Message:
>>> -----------
>>> add umem variant to memcached
>>
>>
>>> +variant umem description {enable libumem support} {
>>> +    depends_lib-append     port:umem
>>> +}
>>
>> The variant should do more than just add a dependency: it should also 
>> add a configure arg or environment variable or something that tells 
>> memcached that it's ok to use umem -- and you may have to add 
>> something to the default port build so that it will *not* use umem, 
>> even if umem is installed, unless the umem variant is selected.
>>
>>
>>
>>
>> !DSPAM:1000,4af767bc91021468!
>>
> 
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
> 


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

From jeremy at lavergne.gotdns.org  Mon Nov  9 18:00:14 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Mon, 9 Nov 2009 21:00:14 -0500
Subject: PortGroup Perl
Message-ID: <5DA12956-EC23-4D0B-9674-44FAA3710D45@lavergne.gotdns.org>

When do we plan to shift the default perl version to 5.10?

If the timing of the next release is relevant, we've received a submission for 5.12-devel (#22438).

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

From toby at macports.org  Mon Nov  9 18:04:36 2009
From: toby at macports.org (Toby Peterson)
Date: Mon, 9 Nov 2009 18:04:36 -0800
Subject: PortGroup Perl
In-Reply-To: <5DA12956-EC23-4D0B-9674-44FAA3710D45@lavergne.gotdns.org>
References: <5DA12956-EC23-4D0B-9674-44FAA3710D45@lavergne.gotdns.org>
Message-ID: <74c219d30911091804t19223cf4k2c8b9e52061a38b@mail.gmail.com>

On Mon, Nov 9, 2009 at 18:00, Jeremy Lavergne
<jeremy at lavergne.gotdns.org> wrote:
> When do we plan to shift the default perl version to 5.10?

When Perl 6 is released. :)

- Toby

From brooks at clarksonline.net  Mon Nov  9 20:00:55 2009
From: brooks at clarksonline.net (M. Brooks Clark)
Date: Mon, 9 Nov 2009 22:00:55 -0600
Subject: [MacPorts] #22423: radlib doesn't use MacPorts libraries
In-Reply-To: <059.98c1fd81517ca86cb8570dc6e9f7ff72@macports.org>
References: <059.98c1fd81517ca86cb8570dc6e9f7ff72@macports.org>
Message-ID: <F65A5673-1E10-4B51-8B9C-C83D65434E07@clarksonline.net>

Any suggestions for how I can get it to look for the libs in /opt/ 
local/lib before it finds the ones in /usr/lib?

Thanks,

Brooks



On Nov 8, 2009, at 8:13 PM, MacPorts wrote:

> #22423: radlib doesn't use MacPorts libraries
> ------------------------------------- 
> +--------------------------------------
> Reporter:  ryandesign@?             |       Owner:  mbrooksclark@?
>     Type:  defect                   |      Status:  new
> Priority:  Normal                   |   Milestone:
> Component:  ports                    |     Version:  1.8.1
> Keywords:                           |        Port:  radlib
> ------------------------------------- 
> +--------------------------------------
> radlib uses openssl, zlib, and sqlite3 from Mac OS X; it should use  
> the
> MacPorts version of these libraries. It should also declare a  
> dependency
> on the openssl port (which will bring in a dependency on the zlib  
> port).
>
> {{{
> $ port installed radlib
> The following ports are currently installed:
>   radlib @2.8.4_0+mysql5+sqlite3 (active)
> }}}
>
> {{{
> $ otool -L /opt/local/bin/raddebug
> /opt/local/bin/raddebug:
>         /opt/local/lib/librad.0.dylib (compatibility version 1.0.0,
> current version 1.0.0)
>         /opt/local/lib/mysql5/mysql/libmysqlclient.16.dylib  
> (compatibility
> version 17.0.0, current version 17.0.0)
>         /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8,  
> current
> version 0.9.8)
>         /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8,
> current version 0.9.8)
>         /usr/lib/libz.1.dylib (compatibility version 1.0.0, current
> version 1.2.3)
>         /usr/lib/libsqlite3.dylib (compatibility version 9.0.0,  
> current
> version 9.6.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
> current
> version 124.1.1)
> }}}
>
> Mac OS X 10.6.1 [[BR]]
> Xcode 3.2.1 [[BR]]
> MacPorts 1.8.0
>
> -- 
> Ticket URL: <http://trac.macports.org/ticket/22423>
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS


From billitch at macports.org  Mon Nov  9 20:32:40 2009
From: billitch at macports.org (Thomas de Grivel)
Date: Tue, 10 Nov 2009 05:32:40 +0100
Subject: [MacPorts] #22423: radlib doesn't use MacPorts libraries
In-Reply-To: <F65A5673-1E10-4B51-8B9C-C83D65434E07@clarksonline.net>
References: <059.98c1fd81517ca86cb8570dc6e9f7ff72@macports.org>
	<F65A5673-1E10-4B51-8B9C-C83D65434E07@clarksonline.net>
Message-ID: <4ec7f0880911092032t7d5edb21wfda61d1ef002cbb@mail.gmail.com>

(sorry, posted from wrong address)

2009/11/10 M. Brooks Clark <brooks at clarksonline.net>:
> Any suggestions for how I can get it to look for the libs in /opt/local/lib
> before it finds the ones in /usr/lib?


Would adding something like this be sufficient ?

configure.cflags-append   -I${prefix}/include
configure.ldflags-append  -L${prefix}/lib

If not I guess you will have to patch the configure script..


> On Nov 8, 2009, at 8:13 PM, MacPorts wrote:
>
>> #22423: radlib doesn't use MacPorts libraries
>>
>> -------------------------------------+--------------------------------------
>> Reporter: ?ryandesign@? ? ? ? ? ? ? | ? ? ? Owner: ?mbrooksclark@?
>> ? ?Type: ?defect ? ? ? ? ? ? ? ? ? | ? ? ?Status: ?new
>> Priority: ?Normal ? ? ? ? ? ? ? ? ? | ? Milestone:
>> Component: ?ports ? ? ? ? ? ? ? ? ? ?| ? ? Version: ?1.8.1
>> Keywords: ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ?Port: ?radlib
>>
>> -------------------------------------+--------------------------------------
>> radlib uses openssl, zlib, and sqlite3 from Mac OS X; it should use the
>> MacPorts version of these libraries. It should also declare a dependency
>> on the openssl port (which will bring in a dependency on the zlib port).
>>
>> {{{
>> $ port installed radlib
>> The following ports are currently installed:
>> ?radlib @2.8.4_0+mysql5+sqlite3 (active)
>> }}}
>>
>> {{{
>> $ otool -L /opt/local/bin/raddebug
>> /opt/local/bin/raddebug:
>> ? ? ? ?/opt/local/lib/librad.0.dylib (compatibility version 1.0.0,
>> current version 1.0.0)
>> ? ? ? ?/opt/local/lib/mysql5/mysql/libmysqlclient.16.dylib (compatibility
>> version 17.0.0, current version 17.0.0)
>> ? ? ? ?/usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current
>> version 0.9.8)
>> ? ? ? ?/usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8,
>> current version 0.9.8)
>> ? ? ? ?/usr/lib/libz.1.dylib (compatibility version 1.0.0, current
>> version 1.2.3)
>> ? ? ? ?/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current
>> version 9.6.0)
>> ? ? ? ?/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> version 124.1.1)
>> }}}
>>
>> Mac OS X 10.6.1 [[BR]]
>> Xcode 3.2.1 [[BR]]
>> MacPorts 1.8.0
>>
>> --
>> Ticket URL: <http://trac.macports.org/ticket/22423>
>> MacPorts <http://www.macports.org/>
>> Ports system for Mac OS
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>



-- 
 Thomas de Grivel
 http://b.lowh.net/billitch/

From emer at emer.net  Mon Nov  9 20:42:36 2009
From: emer at emer.net (Mark Anderson)
Date: Mon, 9 Nov 2009 23:42:36 -0500
Subject: [MacPorts] #22226: gEDA Port Submission
In-Reply-To: <7FC56014-5217-4EEC-B933-74502F4F4268@macports.org>
References: <049.8bcd73659f07f450e7580703cafdab79@macports.org> 
	<2cf4100f0910270646r7aa6cee3qba9d28565d072090@mail.gmail.com> 
	<629BB755-84CD-4227-AE57-9E50C8098D72@macports.org>
	<2cf4100f0910281913g5126b446vca16fbae2304a854@mail.gmail.com> 
	<7FC56014-5217-4EEC-B933-74502F4F4268@macports.org>
Message-ID: <2cf4100f0911092042m3c7715edyfe42d28ca42cb2e4@mail.gmail.com>

I see it attached.  Is it not building?

Mark

On Mon, Nov 9, 2009 at 11:30 PM, Frank Schima <macports2000 at gmail.com> wrote:
> Where is the new Portfile? It's not on the ticket.
>
>
> Cheers!
> Frank
>
> On Oct 28, 2009, at 8:13 PM, Mark Anderson wrote:
>
>> Ok, well I fixed it and added all 3 checksums to boot. ?Can someone
>> commit it? Also, let me know if there are troubles.
>>
>> Mark
>>
>> On Tue, Oct 27, 2009 at 12:29 PM, Frank Schima
>> <macsforever2000 at macports.org> wrote:
>>> Yes, post a new portfile, you should be able to overwrite the old one on the
>>> ticket.
>>>
>>>
>>> Cheers!
>>> Frank
>>>
>>> On Oct 27, 2009, at 7:46 AM, Mark Anderson wrote:
>>>
>>>> Ok, so I screwed this port file up a bit. ?I forgot to add the
>>>> dependencies. ? Should I post a new Portfile, or a diff. ?Also, once
>>>> I've done that can someone commit it?
>>>>
>>>> On Sat, Oct 24, 2009 at 4:52 PM, MacPorts <noreply at macports.org> wrote:
>>>>>
>>>>> #22226: gEDA Port Submission
>>>>>
>>>>> ---------------------------+------------------------------------------------
>>>>> ?Reporter: ?emer@? ? ? ? ? | ? ? ? Owner: ?macports-tickets@?
>>>>> ? ?Type: ?submission ? ? | ? ? ?Status: ?new
>>>>> ?Priority: ?Normal ? ? ? ? | ? Milestone: ?MacPorts 1.8.2
>>>>> Component: ?ports ? ? ? ? ?| ? ? Version: ?1.8.99
>>>>> ?Keywords: ?electronics ? ?| ? ? ? ?Port:
>>>>>
>>>>> ---------------------------+------------------------------------------------
>>>>> ?Here is a Portfile to build the gEDA suite of tools.
>>>>>
>>>>> --
>>>>> Ticket URL: <http://trac.macports.org/ticket/22226>
>>>>> MacPorts <http://www.macports.org/>
>>>>> Ports system for Mac OS
>>>>>
>>>> _______________________________________________
>>>> macports-dev mailing list
>>>> macports-dev at lists.macosforge.org
>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>>>
>>>
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>
>

From macsforever2000 at macports.org  Mon Nov  9 21:34:40 2009
From: macsforever2000 at macports.org (Frank Schima)
Date: Mon, 9 Nov 2009 22:34:40 -0700
Subject: [MacPorts] #22226: gEDA Port Submission
In-Reply-To: <2cf4100f0911092042m3c7715edyfe42d28ca42cb2e4@mail.gmail.com>
References: <049.8bcd73659f07f450e7580703cafdab79@macports.org>
	<2cf4100f0910270646r7aa6cee3qba9d28565d072090@mail.gmail.com>
	<629BB755-84CD-4227-AE57-9E50C8098D72@macports.org>
	<2cf4100f0910281913g5126b446vca16fbae2304a854@mail.gmail.com>
	<7FC56014-5217-4EEC-B933-74502F4F4268@macports.org>
	<2cf4100f0911092042m3c7715edyfe42d28ca42cb2e4@mail.gmail.com>
Message-ID: <E8CB3DD8-6AF6-4898-87A3-07A4F258C9AB@macports.org>

Sorry, it was there. Added in r60361. 


On Nov 9, 2009, at 9:42 PM, Mark Anderson wrote:

> I see it attached.  Is it not building?
> 
> Mark
> 
> On Mon, Nov 9, 2009 at 11:30 PM, Frank Schima <macports2000 at gmail.com> wrote:
>> Where is the new Portfile? It's not on the ticket.
>> 
>> 
>> Cheers!
>> Frank
>> 
>> On Oct 28, 2009, at 8:13 PM, Mark Anderson wrote:
>> 
>>> Ok, well I fixed it and added all 3 checksums to boot.  Can someone
>>> commit it? Also, let me know if there are troubles.
>>> 
>>> Mark
>>> 
>>> On Tue, Oct 27, 2009 at 12:29 PM, Frank Schima
>>> <macsforever2000 at macports.org> wrote:
>>>> Yes, post a new portfile, you should be able to overwrite the old one on the
>>>> ticket.
>>>> 
>>>> 
>>>> Cheers!
>>>> Frank
>>>> 
>>>> On Oct 27, 2009, at 7:46 AM, Mark Anderson wrote:
>>>> 
>>>>> Ok, so I screwed this port file up a bit.  I forgot to add the
>>>>> dependencies.   Should I post a new Portfile, or a diff.  Also, once
>>>>> I've done that can someone commit it?
>>>>> 
>>>>> On Sat, Oct 24, 2009 at 4:52 PM, MacPorts <noreply at macports.org> wrote:
>>>>>> 
>>>>>> #22226: gEDA Port Submission
>>>>>> 
>>>>>> ---------------------------+------------------------------------------------
>>>>>>  Reporter:  emer@?         |       Owner:  macports-tickets@?
>>>>>>    Type:  submission     |      Status:  new
>>>>>>  Priority:  Normal         |   Milestone:  MacPorts 1.8.2
>>>>>> Component:  ports          |     Version:  1.8.99
>>>>>>  Keywords:  electronics    |        Port:
>>>>>> 
>>>>>> ---------------------------+------------------------------------------------
>>>>>>  Here is a Portfile to build the gEDA suite of tools.
>>>>>> 
>>>>>> --
>>>>>> Ticket URL: <http://trac.macports.org/ticket/22226>
>>>>>> MacPorts <http://www.macports.org/>
>>>>>> Ports system for Mac OS
>>>>>> 
>>>>> _______________________________________________
>>>>> macports-dev mailing list
>>>>> macports-dev at lists.macosforge.org
>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>>>> 
>>>> 
>>> _______________________________________________
>>> macports-dev mailing list
>>> macports-dev at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>> 
>> 


From jkh at apple.com  Mon Nov  9 23:21:45 2009
From: jkh at apple.com (Jordan K. Hubbard)
Date: Mon, 9 Nov 2009 23:21:45 -0800
Subject: macports error reporting, stack traces
In-Reply-To: <4AF80500.3060200@macports.org>
References: <04009386-C82C-45B2-8AC4-954D9BA2BBB8@lavergne.gotdns.org>
	<70FD4384-89A4-4664-AD2C-00DF53F71C5B@apple.com>
	<4AF80500.3060200@macports.org>
Message-ID: <39EF83FF-9353-402E-814E-EA203636DFEA@apple.com>


On Nov 9, 2009, at 4:03 AM, Joshua Root wrote:

> On 2009-11-9 14:13, Jordan K. Hubbard wrote:
>> On Nov 8, 2009, at 10:03 AM, Jeremy Lavergne wrote:
>> 
>>> Should we add the typical steps for producing debug error logs to the output of the standard trace during a failure?
>> 
>> That certainly sounds like something that should be documented, though one would almost wish to then render that documentation obsolete by dumping debug output on error.  In other words, ui_debug would always generate debug information, the Debug flag merely indicating what the output fd was.  If not set, it's set to some temporary file which has already been unlinked (the open, unlink truck) but has a fd that can be rewound and copied to stderr on error, and if it's set then the fd points directly to stderr.  Whatever routine catches errors for a port build would be responsible for dumping the error log.  Sounds like an excellent Tcl / MacPorts base beginner's project. :)
> 
> That is exactly what the gsoc09-logging branch does.

Even more awesome!   When's that scheduled for completion and merge with trunk? :-)

- Jordan

From jmr at macports.org  Tue Nov 10 01:29:04 2009
From: jmr at macports.org (Joshua Root)
Date: Tue, 10 Nov 2009 20:29:04 +1100
Subject: [MacPorts] #22423: radlib doesn't use MacPorts libraries
In-Reply-To: <4ec7f0880911092032t7d5edb21wfda61d1ef002cbb@mail.gmail.com>
References: <059.98c1fd81517ca86cb8570dc6e9f7ff72@macports.org>	<F65A5673-1E10-4B51-8B9C-C83D65434E07@clarksonline.net>
	<4ec7f0880911092032t7d5edb21wfda61d1ef002cbb@mail.gmail.com>
Message-ID: <4AF93260.3010303@macports.org>

On 2009-11-10 15:32, Thomas de Grivel wrote:
> (sorry, posted from wrong address)
> 
> 2009/11/10 M. Brooks Clark <brooks at clarksonline.net>:
>> Any suggestions for how I can get it to look for the libs in /opt/local/lib
>> before it finds the ones in /usr/lib?
> 
> 
> Would adding something like this be sufficient ?
> 
> configure.cflags-append   -I${prefix}/include

Possibly helpful, if the build system doesn't respect CPPFLAGS (which is
where this flag normally appears via configure.cppflags).

> configure.ldflags-append  -L${prefix}/lib

Not helpful, configure.ldflags has a default value of '-L${prefix}/lib'.

- Josh

From blb at macports.org  Tue Nov 10 01:55:08 2009
From: blb at macports.org (Bryan Blackburn)
Date: Tue, 10 Nov 2009 02:55:08 -0700
Subject: macports error reporting, stack traces
In-Reply-To: <39EF83FF-9353-402E-814E-EA203636DFEA@apple.com>
References: <04009386-C82C-45B2-8AC4-954D9BA2BBB8@lavergne.gotdns.org>
	<70FD4384-89A4-4664-AD2C-00DF53F71C5B@apple.com>
	<4AF80500.3060200@macports.org>
	<39EF83FF-9353-402E-814E-EA203636DFEA@apple.com>
Message-ID: <20091110095508.GH482@ninagal.withay.com>

On Mon, Nov 09, 2009 at 11:21:45PM -0800, Jordan K. Hubbard said:
> 
> On Nov 9, 2009, at 4:03 AM, Joshua Root wrote:
> 
> > On 2009-11-9 14:13, Jordan K. Hubbard wrote:
> >> On Nov 8, 2009, at 10:03 AM, Jeremy Lavergne wrote:
> >> 
> >>> Should we add the typical steps for producing debug error logs to the output of the standard trace during a failure?
> >> 
> >> That certainly sounds like something that should be documented, though one would almost wish to then render that documentation obsolete by dumping debug output on error.  In other words, ui_debug would always generate debug information, the Debug flag merely indicating what the output fd was.  If not set, it's set to some temporary file which has already been unlinked (the open, unlink truck) but has a fd that can be rewound and copied to stderr on error, and if it's set then the fd points directly to stderr.  Whatever routine catches errors for a port build would be responsible for dumping the error log.  Sounds like an excellent Tcl / MacPorts base beginner's project. :)
> > 
> > That is exactly what the gsoc09-logging branch does.
> 
> Even more awesome!   When's that scheduled for completion and merge with trunk? :-)

In r60372, now that I figured out the oddity from svn merge with a few files
with their own svn:mergeinfo properties...

'port help log' is a good place for people to start with it.

Bryan


> 
> - Jordan

From fnasser at redhat.com  Tue Nov 10 06:21:47 2009
From: fnasser at redhat.com (Fernando Nasser)
Date: Tue, 10 Nov 2009 09:21:47 -0500
Subject: Help needed to build gimp2 on Snow Leopard
Message-ID: <4AF976FB.7010002@redhat.com>

Hi,

I have a Snow Leopard MacBook Pro (not upgraded from Leopard) and I 
can't get gimp2 to install, which bloks many other things.

The problem is when compiling gimpunit.c and the kind of error message I 
am getting makes me suspect some autotools test detected the wrong thing.

Has anyone successifuly installed Gimp2?  Thanks in advance.



/bin/sh ../libtool --tag=CC   --mode=compile /usr/bin/gcc-4.2 
-DHAVE_CONFIG_H -I. -I.. -I.. -D_REENTRANT -I/opt/local/include/glib-2.0 
-I/opt/local/lib/glib-2.0/include -I/opt/local/include    
-I/opt/local/include -DPREFIX=\""/opt/local"\" -DGIMPDIR=\"".gimp-2.6"\" 
-DDATADIR=\""/opt/local/share/gimp/2.0"\" 
-DLOCALEDIR=\""/opt/local/share/locale"\" 
-DPLUGINDIR=\""/opt/local/lib/gimp/2.0"\" 
-DSYSCONFDIR=\""/opt/local/etc/gimp/2.0"\" -DGIMP_PACKAGE=\""gimp"\" 
-DGIMP_DATA_VERSION=\"2.0\" -DGIMP_SYSCONF_VERSION=\"2.0\" 
-DGIMP_PLUGIN_VERSION=\"2.0\" -DG_LOG_DOMAIN=\"LibGimpBase\" 
-I/opt/local/include -DGIMP_DISABLE_DEPRECATED -DGDK_MULTIHEAD_SAFE 
-DGTK_MULTIHEAD_SAFE  -O2 -arch x86_64 -Wall 
-Wdeclaration-after-statement -Wmissing-prototypes 
-Wmissing-declarations -Winit-self -Wpointer-arith 
-Wold-style-definition -MT gimpunit.lo -MD -MP -MF .deps/gimpunit.Tpo -c 
-o gimpunit.lo gimpunit.c
/var/tmp//ccHAIEoO.s:125:suffix or operands invalid for `pushf'
/var/tmp//ccHAIEoO.s:126:suffix or operands invalid for `pushf'
/var/tmp//ccHAIEoO.s:127:suffix or operands invalid for `pop'
/var/tmp//ccHAIEoO.s:130:suffix or operands invalid for `push'
/var/tmp//ccHAIEoO.s:131:suffix or operands invalid for `popf'
/var/tmp//ccHAIEoO.s:132:suffix or operands invalid for `pushf'
/var/tmp//ccHAIEoO.s:133:suffix or operands invalid for `pop'
/var/tmp//ccHAIEoO.s:134:suffix or operands invalid for `popf'
make[2]: *** [gimpcpuaccel.lo] Error 1


From jmr at macports.org  Tue Nov 10 08:17:10 2009
From: jmr at macports.org (Joshua Root)
Date: Wed, 11 Nov 2009 03:17:10 +1100
Subject: Help needed to build gimp2 on Snow Leopard
In-Reply-To: <4AF976FB.7010002@redhat.com>
References: <4AF976FB.7010002@redhat.com>
Message-ID: <4AF99206.7070800@macports.org>

On 2009-11-11 01:21, Fernando Nasser wrote:
> Hi,
> 
> I have a Snow Leopard MacBook Pro (not upgraded from Leopard) and I
> can't get gimp2 to install, which bloks many other things.
> 
> The problem is when compiling gimpunit.c and the kind of error message I
> am getting makes me suspect some autotools test detected the wrong thing.
> 
> Has anyone successifuly installed Gimp2?  Thanks in advance.
> 
> 
> 
> /bin/sh ../libtool --tag=CC   --mode=compile /usr/bin/gcc-4.2
> -DHAVE_CONFIG_H -I. -I.. -I.. -D_REENTRANT -I/opt/local/include/glib-2.0
> -I/opt/local/lib/glib-2.0/include -I/opt/local/include   
> -I/opt/local/include -DPREFIX=\""/opt/local"\" -DGIMPDIR=\"".gimp-2.6"\"
> -DDATADIR=\""/opt/local/share/gimp/2.0"\"
> -DLOCALEDIR=\""/opt/local/share/locale"\"
> -DPLUGINDIR=\""/opt/local/lib/gimp/2.0"\"
> -DSYSCONFDIR=\""/opt/local/etc/gimp/2.0"\" -DGIMP_PACKAGE=\""gimp"\"
> -DGIMP_DATA_VERSION=\"2.0\" -DGIMP_SYSCONF_VERSION=\"2.0\"
> -DGIMP_PLUGIN_VERSION=\"2.0\" -DG_LOG_DOMAIN=\"LibGimpBase\"
> -I/opt/local/include -DGIMP_DISABLE_DEPRECATED -DGDK_MULTIHEAD_SAFE
> -DGTK_MULTIHEAD_SAFE  -O2 -arch x86_64 -Wall
> -Wdeclaration-after-statement -Wmissing-prototypes
> -Wmissing-declarations -Winit-self -Wpointer-arith
> -Wold-style-definition -MT gimpunit.lo -MD -MP -MF .deps/gimpunit.Tpo -c
> -o gimpunit.lo gimpunit.c
> /var/tmp//ccHAIEoO.s:125:suffix or operands invalid for `pushf'
> /var/tmp//ccHAIEoO.s:126:suffix or operands invalid for `pushf'
> /var/tmp//ccHAIEoO.s:127:suffix or operands invalid for `pop'
> /var/tmp//ccHAIEoO.s:130:suffix or operands invalid for `push'
> /var/tmp//ccHAIEoO.s:131:suffix or operands invalid for `popf'
> /var/tmp//ccHAIEoO.s:132:suffix or operands invalid for `pushf'
> /var/tmp//ccHAIEoO.s:133:suffix or operands invalid for `pop'
> /var/tmp//ccHAIEoO.s:134:suffix or operands invalid for `popf'
> make[2]: *** [gimpcpuaccel.lo] Error 1

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

You can search trac for tickets against a particular port here:
<http://trac.macports.org/search?portsummarysearch=on>

- Josh

From fnasser at redhat.com  Tue Nov 10 08:31:20 2009
From: fnasser at redhat.com (Fernando Nasser)
Date: Tue, 10 Nov 2009 11:31:20 -0500
Subject: Help needed to build gimp2 on Snow Leopard
In-Reply-To: <4AF99206.7070800@macports.org>
References: <4AF976FB.7010002@redhat.com> <4AF99206.7070800@macports.org>
Message-ID: <4AF99558.3050803@redhat.com>

Joshua Root wrote:
> On 2009-11-11 01:21, Fernando Nasser wrote:
>   
>> Hi,
>>
>> I have a Snow Leopard MacBook Pro (not upgraded from Leopard) and I
>> can't get gimp2 to install, which bloks many other things.
>>
>> The problem is when compiling gimpunit.c and the kind of error message I
>> am getting makes me suspect some autotools test detected the wrong thing.
>>
>> Has anyone successifuly installed Gimp2?  Thanks in advance.
>>
>>
>>
>> /bin/sh ../libtool --tag=CC   --mode=compile /usr/bin/gcc-4.2
>> -DHAVE_CONFIG_H -I. -I.. -I.. -D_REENTRANT -I/opt/local/include/glib-2.0
>> -I/opt/local/lib/glib-2.0/include -I/opt/local/include   
>> -I/opt/local/include -DPREFIX=\""/opt/local"\" -DGIMPDIR=\"".gimp-2.6"\"
>> -DDATADIR=\""/opt/local/share/gimp/2.0"\"
>> -DLOCALEDIR=\""/opt/local/share/locale"\"
>> -DPLUGINDIR=\""/opt/local/lib/gimp/2.0"\"
>> -DSYSCONFDIR=\""/opt/local/etc/gimp/2.0"\" -DGIMP_PACKAGE=\""gimp"\"
>> -DGIMP_DATA_VERSION=\"2.0\" -DGIMP_SYSCONF_VERSION=\"2.0\"
>> -DGIMP_PLUGIN_VERSION=\"2.0\" -DG_LOG_DOMAIN=\"LibGimpBase\"
>> -I/opt/local/include -DGIMP_DISABLE_DEPRECATED -DGDK_MULTIHEAD_SAFE
>> -DGTK_MULTIHEAD_SAFE  -O2 -arch x86_64 -Wall
>> -Wdeclaration-after-statement -Wmissing-prototypes
>> -Wmissing-declarations -Winit-self -Wpointer-arith
>> -Wold-style-definition -MT gimpunit.lo -MD -MP -MF .deps/gimpunit.Tpo -c
>> -o gimpunit.lo gimpunit.c
>> /var/tmp//ccHAIEoO.s:125:suffix or operands invalid for `pushf'
>> /var/tmp//ccHAIEoO.s:126:suffix or operands invalid for `pushf'
>> /var/tmp//ccHAIEoO.s:127:suffix or operands invalid for `pop'
>> /var/tmp//ccHAIEoO.s:130:suffix or operands invalid for `push'
>> /var/tmp//ccHAIEoO.s:131:suffix or operands invalid for `popf'
>> /var/tmp//ccHAIEoO.s:132:suffix or operands invalid for `pushf'
>> /var/tmp//ccHAIEoO.s:133:suffix or operands invalid for `pop'
>> /var/tmp//ccHAIEoO.s:134:suffix or operands invalid for `popf'
>> make[2]: *** [gimpcpuaccel.lo] Error 1
>>     
>
> <http://trac.macports.org/ticket/21011>
>
> You can search trac for tickets against a particular port here:
> <http://trac.macports.org/search?portsummarysearch=on>
>   

My appologies.

And thanks.
> - Josh
>
>   


From jeremy at lavergne.gotdns.org  Tue Nov 10 16:21:17 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Tue, 10 Nov 2009 19:21:17 -0500
Subject: [MacPorts] #22442: dnsmasq launch config incorrect
In-Reply-To: <f60fe000911101617o7538ea16idcedd89de93a6bf4@mail.gmail.com>
References: <055.e28fa673aad809bbd33a8bad436c993b@macports.org>
	<064.fbce83803b0229a7d1af40940858888b@macports.org>
	<f60fe000911101617o7538ea16idcedd89de93a6bf4@mail.gmail.com>
Message-ID: <C339CDB3-1642-42DC-B61C-77F793E8F7B2@lavergne.gotdns.org>

dnsmasq was updated 6 days ago:
http://trac.macports.org/browser/trunk/dports/net/dnsmasq
The launchd script was added, as well some variants.

I'll bump the revision to force an upgrade.

`port load dnsmasq` is still valid.

On Nov 10, 2009, at 7:17 PM, Mark J. Reed wrote:

> The MacPorts install is less than 2 weeks old.  That script is what I
> got when I did "port load dnsmasq".  Is that not the correct proceure
> anymore?

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

From ryandesign at macports.org  Tue Nov 10 16:34:35 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 10 Nov 2009 18:34:35 -0600
Subject: [MacPorts] #22423: radlib doesn't use MacPorts libraries
In-Reply-To: <4ec7f0880911092032t7d5edb21wfda61d1ef002cbb@mail.gmail.com>
References: <059.98c1fd81517ca86cb8570dc6e9f7ff72@macports.org>
	<F65A5673-1E10-4B51-8B9C-C83D65434E07@clarksonline.net>
	<4ec7f0880911092032t7d5edb21wfda61d1ef002cbb@mail.gmail.com>
Message-ID: <6B7567DB-AA21-46BF-8DC0-17E83864E9B6@macports.org>


On Nov 9, 2009, at 22:32, Thomas de Grivel wrote:

> 2009/11/10 M. Brooks Clark <brooks at clarksonline.net>:
>> Any suggestions for how I can get it to look for the libs in /opt/ 
>> local/lib
>> before it finds the ones in /usr/lib?
>
> Would adding something like this be sufficient ?
>
> configure.cflags-append   -I${prefix}/include

MacPorts already puts -I${prefix}/include into cppflags. The above  
would only be useful for software that doesn't respect cppflags.

> configure.ldflags-append  -L${prefix}/lib

MacPorts already sets this. Perhaps the software ignores ldflags.


From talklists at newgeo.com  Tue Nov 10 16:54:56 2009
From: talklists at newgeo.com (Scott Haneda)
Date: Tue, 10 Nov 2009 16:54:56 -0800
Subject: [MacPorts] #22442: dnsmasq launch config incorrect
In-Reply-To: <C339CDB3-1642-42DC-B61C-77F793E8F7B2@lavergne.gotdns.org>
References: <055.e28fa673aad809bbd33a8bad436c993b@macports.org>
	<064.fbce83803b0229a7d1af40940858888b@macports.org>
	<f60fe000911101617o7538ea16idcedd89de93a6bf4@mail.gmail.com>
	<C339CDB3-1642-42DC-B61C-77F793E8F7B2@lavergne.gotdns.org>
Message-ID: <067D0DCA-9AA8-4037-81D8-E3875B0504EB@newgeo.com>

Lines 84 to 106, thats really cool, had no idea you could do that in  
TCL.  I think I just solved my issues with the variants problem I am  
tying to deal with in another port.
-- 
Scott * If you contact me off list replace talklists@ with scott@ *

On Nov 10, 2009, at 4:21 PM, Jeremy Lavergne wrote:

> dnsmasq was updated 6 days ago:
> http://trac.macports.org/browser/trunk/dports/net/dnsmasq
> The launchd script was added, as well some variants.
>
> I'll bump the revision to force an upgrade.
>
> `port load dnsmasq` is still valid.


From brooks at clarksonline.net  Tue Nov 10 22:08:33 2009
From: brooks at clarksonline.net (M. Brooks Clark)
Date: Wed, 11 Nov 2009 00:08:33 -0600
Subject: [MacPorts] #22423: radlib doesn't use MacPorts libraries
In-Reply-To: <6B7567DB-AA21-46BF-8DC0-17E83864E9B6@macports.org>
References: <059.98c1fd81517ca86cb8570dc6e9f7ff72@macports.org>
	<F65A5673-1E10-4B51-8B9C-C83D65434E07@clarksonline.net>
	<4ec7f0880911092032t7d5edb21wfda61d1ef002cbb@mail.gmail.com>
	<6B7567DB-AA21-46BF-8DC0-17E83864E9B6@macports.org>
Message-ID: <4C443BEA-928B-4F9D-85F5-E0F22038C708@clarksonline.net>

I don't see why raddebug is linking with /usr/lib/libsqlite3.dylib.

The libtool line looks like this:

/bin/sh ../libtool --tag=CC   --mode=link /usr/bin/gcc-4.2  -O2 -arch x86_64 -L../src/.libs   -L/usr/lib -L/usr/local/lib  -L/opt/local/lib -o raddebug raddebug.o -lc -lm -lrad   -lsqlite3 -lm -lc 

libtool: link: /usr/bin/gcc-4.2 -O2 -arch x86_64 -o .libs/raddebug raddebug.o  -L/opt/local/var/macports/build/_Users_mbclark_Dropbox_ports_devel_radlib/work/radlib-2.8.4/src/.libs -L/usr/lib -L/usr/local/lib -L/opt/local/lib /opt/local/var/macports/build/_Users_mbclark_Dropbox_ports_devel_radlib/work/radlib-2.8.4/src/.libs/librad.dylib -lsqlite3 -lm -lc

Maybe I'm wrong here, but I thought the -L option added directories to the *beginning* of the search path, so shouldn't /opt/local/lib be first in the search path?



On Nov 10, 2009, at 6:34 PM, Ryan Schmidt wrote:

> 
> On Nov 9, 2009, at 22:32, Thomas de Grivel wrote:
> 
>> 2009/11/10 M. Brooks Clark <brooks at clarksonline.net>:
>>> Any suggestions for how I can get it to look for the libs in /opt/local/lib
>>> before it finds the ones in /usr/lib?
>> 
>> Would adding something like this be sufficient ?
>> 
>> configure.cflags-append   -I${prefix}/include
> 
> MacPorts already puts -I${prefix}/include into cppflags. The above would only be useful for software that doesn't respect cppflags.
> 
>> configure.ldflags-append  -L${prefix}/lib
> 
> MacPorts already sets this. Perhaps the software ignores ldflags.
> 


From ryandesign at macports.org  Wed Nov 11 13:54:10 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 11 Nov 2009 15:54:10 -0600
Subject: [MacPorts] #22423: radlib doesn't use MacPorts libraries
In-Reply-To: <4C443BEA-928B-4F9D-85F5-E0F22038C708@clarksonline.net>
References: <059.98c1fd81517ca86cb8570dc6e9f7ff72@macports.org>
	<F65A5673-1E10-4B51-8B9C-C83D65434E07@clarksonline.net>
	<4ec7f0880911092032t7d5edb21wfda61d1ef002cbb@mail.gmail.com>
	<6B7567DB-AA21-46BF-8DC0-17E83864E9B6@macports.org>
	<4C443BEA-928B-4F9D-85F5-E0F22038C708@clarksonline.net>
Message-ID: <C358B147-3503-4AE3-ACFD-521242868369@macports.org>


On Nov 11, 2009, at 00:08, M. Brooks Clark wrote:

> I don't see why raddebug is linking with /usr/lib/libsqlite3.dylib.
>
> The libtool line looks like this:
>
> /bin/sh ../libtool --tag=CC   --mode=link /usr/bin/gcc-4.2  -O2 - 
> arch x86_64 -L../src/.libs   -L/usr/lib -L/usr/local/lib  -L/opt/ 
> local/lib -o raddebug raddebug.o -lc -lm -lrad   -lsqlite3 -lm -lc
>
> libtool: link: /usr/bin/gcc-4.2 -O2 -arch x86_64 -o .libs/raddebug  
> raddebug.o  -L/opt/local/var/macports/build/ 
> _Users_mbclark_Dropbox_ports_devel_radlib/work/radlib-2.8.4/ 
> src/.libs -L/usr/lib -L/usr/local/lib -L/opt/local/lib /opt/local/ 
> var/macports/build/_Users_mbclark_Dropbox_ports_devel_radlib/work/ 
> radlib-2.8.4/src/.libs/librad.dylib -lsqlite3 -lm -lc
>
> Maybe I'm wrong here, but I thought the -L option added directories  
> to the *beginning* of the search path, so shouldn't /opt/local/lib  
> be first in the search path?

As far as I understand, -L adds directories to the end of the search  
path. But I haven't tested that extensively.




From ryandesign at macports.org  Wed Nov 11 13:56:03 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 11 Nov 2009 15:56:03 -0600
Subject: [MacPorts] #22442: dnsmasq launch config incorrect
In-Reply-To: <067D0DCA-9AA8-4037-81D8-E3875B0504EB@newgeo.com>
References: <055.e28fa673aad809bbd33a8bad436c993b@macports.org>
	<064.fbce83803b0229a7d1af40940858888b@macports.org>
	<f60fe000911101617o7538ea16idcedd89de93a6bf4@mail.gmail.com>
	<C339CDB3-1642-42DC-B61C-77F793E8F7B2@lavergne.gotdns.org>
	<067D0DCA-9AA8-4037-81D8-E3875B0504EB@newgeo.com>
Message-ID: <DBE7A02B-632B-4C3C-B8C0-14D15140D8FB@macports.org>


On Nov 10, 2009, at 18:54, Scott Haneda wrote:

> On Nov 10, 2009, at 4:21 PM, Jeremy Lavergne wrote:
>
>> http://trac.macports.org/browser/trunk/dports/net/dnsmasq
>
> Lines 84 to 106, thats really cool, had no idea you could do that in  
> TCL.  I think I just solved my issues with the variants problem I am  
> tying to deal with in another port.

Though it might be clearer/easier to have a template plist file in the  
port's files directory, and use reinplace to replace the few dynamic  
bits when installing it.



From jeremy at lavergne.gotdns.org  Wed Nov 11 13:58:26 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Wed, 11 Nov 2009 16:58:26 -0500
Subject: [MacPorts] #22442: dnsmasq launch config incorrect
In-Reply-To: <DBE7A02B-632B-4C3C-B8C0-14D15140D8FB@macports.org>
References: <055.e28fa673aad809bbd33a8bad436c993b@macports.org>
	<064.fbce83803b0229a7d1af40940858888b@macports.org>
	<f60fe000911101617o7538ea16idcedd89de93a6bf4@mail.gmail.com>
	<C339CDB3-1642-42DC-B61C-77F793E8F7B2@lavergne.gotdns.org>
	<067D0DCA-9AA8-4037-81D8-E3875B0504EB@newgeo.com>
	<DBE7A02B-632B-4C3C-B8C0-14D15140D8FB@macports.org>
Message-ID: <B7691C93-6B15-418D-A5A6-1CA3257218A5@lavergne.gotdns.org>

>>> http://trac.macports.org/browser/trunk/dports/net/dnsmasq
>> 
>> Lines 84 to 106, thats really cool, had no idea you could do that in TCL.  I think I just solved my issues with the variants problem I am tying to deal with in another port.
> 
> Though it might be clearer/easier to have a template plist file in the port's files directory, and use reinplace to replace the few dynamic bits when installing it.

Had done that in the past and ended up trashing it.  The problem is the flags I'd pass are different that what people want.  Rather hard to win that one.

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

From dluke at geeklair.net  Wed Nov 11 14:39:59 2009
From: dluke at geeklair.net (Daniel J. Luke)
Date: Wed, 11 Nov 2009 17:39:59 -0500
Subject: [MacPorts] #22423: radlib doesn't use MacPorts libraries
In-Reply-To: <C358B147-3503-4AE3-ACFD-521242868369@macports.org>
References: <059.98c1fd81517ca86cb8570dc6e9f7ff72@macports.org>
	<F65A5673-1E10-4B51-8B9C-C83D65434E07@clarksonline.net>
	<4ec7f0880911092032t7d5edb21wfda61d1ef002cbb@mail.gmail.com>
	<6B7567DB-AA21-46BF-8DC0-17E83864E9B6@macports.org>
	<4C443BEA-928B-4F9D-85F5-E0F22038C708@clarksonline.net>
	<C358B147-3503-4AE3-ACFD-521242868369@macports.org>
Message-ID: <BD18CDB1-1E02-451A-A956-349EFEFA0F80@geeklair.net>

On Nov 11, 2009, at 4:54 PM, Ryan Schmidt wrote:
>> /bin/sh ../libtool --tag=CC   --mode=link /usr/bin/gcc-4.2  -O2 -arch x86_64 -L../src/.libs   -L/usr/lib -L/usr/local/lib  -L/opt/local/lib -o raddebug raddebug.o -lc -lm -lrad   -lsqlite3 -lm -lc
>> 
>> Maybe I'm wrong here, but I thought the -L option added directories to the *beginning* of the search path, so shouldn't /opt/local/lib be first in the search path?
> 
> As far as I understand, -L adds directories to the end of the search path. But I haven't tested that extensively.

The manpage for ld says "Directories specified with -L are searched in the order they appear on the command line and before the default search path."

So, the problem above is that -L/usr/lib is before -L${prefix}/lib (getting ${prefix} before -L/usr/local/lib could also help prevent problems for people who have stuff in /usr/local)

--
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.          |                          
+========================================================+




From ryandesign at macports.org  Thu Nov 12 08:18:46 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 12 Nov 2009 10:18:46 -0600
Subject: [60409] trunk/dports/aqua/qt4-mac-devel/Portfile
In-Reply-To: <20091111144309.044FB3165EFA@beta.macosforge.org>
References: <20091111144309.044FB3165EFA@beta.macosforge.org>
Message-ID: <C5AE7BA0-5B6B-462D-99E6-6D8505F993F3@macports.org>


On Nov 11, 2009, at 08:43, jochen at macports.org wrote:

> Revision: 60409
>          http://trac.macports.org/changeset/60409
> Author:   jochen at macports.org
> Date:     2009-11-11 06:43:08 -0800 (Wed, 11 Nov 2009)
> Log Message:
> -----------
> upgrade to 4.6.0-beta1 based on current qt4-mac port
>
> Modified Paths:
> --------------
>    trunk/dports/aqua/qt4-mac-devel/Portfile
>
> Modified: trunk/dports/aqua/qt4-mac-devel/Portfile
> ===================================================================
> --- trunk/dports/aqua/qt4-mac-devel/Portfile	2009-11-11 14:42:35 UTC  
> (rev 60408)
> +++ trunk/dports/aqua/qt4-mac-devel/Portfile	2009-11-11 14:43:08 UTC  
> (rev 60409)
> @@ -5,23 +5,23 @@
>
> name                qt4-mac-devel
> conflicts           qt4-mac
> -version             4.5.0
> -revision            1
> +version             4.6.0-beta1
> categories          aqua
> platforms           macosx
> -maintainers         illogic-al openmaintainer
> +maintainers         nomaintainer

Is Orville OK with losing maintainership of this port? qt4-mac was  
declared abandoned via #22052, but that was maintained by someone else.

It would be ideal if a single maintainer (or maintainers) who knows  
about Qt would take over all the Qt ports (qt4-mac, qt4-x11, qt4-mac- 
devel, qt4-kde, qt3, qt3-mac).


From allencmcbride at gmail.com  Thu Nov 12 12:35:42 2009
From: allencmcbride at gmail.com (Allen McBride)
Date: Thu, 12 Nov 2009 15:35:42 -0500
Subject: nudge on my patch to update GNU Solfege portfile
Message-ID: <29715577-54A6-42A0-8615-1598A655384D@gmail.com>

Hi folks,

Just a nudge to say that I submitted a patch to update GNU Solfege a little over a week ago: http://trac.macports.org/ticket/22022

The changes to the portfile itself are straightforward, though I also submitted a couple patchfiles.  They work fine for me, and I'm pretty sure I made them correctly, but it's my first time making patchfiles so it's possible I might have missed something.

Thanks,
Allen


From ryandesign at macports.org  Thu Nov 12 20:52:40 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 12 Nov 2009 22:52:40 -0600
Subject: nudge on my patch to update GNU Solfege portfile
In-Reply-To: <29715577-54A6-42A0-8615-1598A655384D@gmail.com>
References: <29715577-54A6-42A0-8615-1598A655384D@gmail.com>
Message-ID: <425921BD-FE3B-4C92-A730-3468D56D1F87@macports.org>


On Nov 12, 2009, at 14:35, Allen McBride wrote:

> Just a nudge to say that I submitted a patch to update GNU Solfege a little over a week ago: http://trac.macports.org/ticket/22022
> 
> The changes to the portfile itself are straightforward, though I also submitted a couple patchfiles.  They work fine for me, and I'm pretty sure I made them correctly, but it's my first time making patchfiles so it's possible I might have missed something.

Jeremy took care of this ticket. Thanks, Jeremy!


From jeremy at lavergne.gotdns.org  Fri Nov 13 10:12:23 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Fri, 13 Nov 2009 13:12:23 -0500
Subject: edits to googlecode.tcl
Message-ID: <66722DFD-DCA6-4B6B-ADE7-714FBC2284E5@lavergne.gotdns.org>

I edited googlecode.tcl to incorporate a second variation of the googecode URL.  After this change, however, there are a handful of portfiles that are breaking.

The first port that happens to be breaking for me is dot2tex.

It uses a custom homepage but the googlecode master_sites, and has it's own livecheck regex and url defined.

So the if condition for setting the livecheck.name follows ...
 * has home page
 * livecheck.name is still "default"
 * { pull regex from code.google.com or pull regex from *.googlecode.com }

It seems to me that the logic is correct and should return false, but I'm lost as to why it's an error now but wasn't in the past.

Any thoughts?

Relevant links:
http://trac.macports.org/ticket/20900
http://trac.macports.org/changeset/60451

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

From opendarwin.org at darkart.com  Fri Nov 13 13:58:02 2009
From: opendarwin.org at darkart.com (Eric Hall)
Date: Fri, 13 Nov 2009 21:58:02 +0000
Subject: PortGroup Perl
In-Reply-To: <5DA12956-EC23-4D0B-9674-44FAA3710D45@lavergne.gotdns.org>
References: <5DA12956-EC23-4D0B-9674-44FAA3710D45@lavergne.gotdns.org>
Message-ID: <20091113215802.GQ62534@darkart.com>

On Mon, Nov 09, 2009 at 09:00:14PM -0500, Jeremy Lavergne wrote:
> When do we plan to shift the default perl version to 5.10?
> 
> If the timing of the next release is relevant, we've received a submission for 5.12-devel (#22438).
> 


	I made some changes to the perl5 and perl5.10 ports
to better accomodate using the perl5 port to install either
perl5.8 or perl5.10 [1].  I have a few changes to make to the
perl5.8 port, then some testing.   The changes should allow
anyone to install either perl5.8 or perl5.10 and have that
version of perl be the one that is used. 
	I've successfully tested that much by installing
perl5 (using perl5.10) and then installing a large number
of perl modules.  There may still be ports that require
perl5.8 rather than perl5, if anyone has cycles to find
and resolve those ports that'd be great.


		-eric


[1]:
	The basic idea is to have perl5 continue to
default to perl5.8, I added a variant (+perl5_10)
that installs perl5.10 instead of perl5.8.  I've
also changed perl5.10 to conflict with perl5.8 unless
+mangle_names is installed, which, well, mangles the
names of the binaries, man pages, etc. (as the perl5.10
port currently does).  I plan to do the conflicts (w/ perl5.10)
and mangling variant to the perl5.8 port.



From ryandesign at macports.org  Fri Nov 13 14:03:34 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 13 Nov 2009 16:03:34 -0600
Subject: [60480] trunk/dports/net/psi-otr
In-Reply-To: <20091113162447.8F64C32168F9@beta.macosforge.org>
References: <20091113162447.8F64C32168F9@beta.macosforge.org>
Message-ID: <B8AEC47D-34AC-4A17-BF65-1F10CF70A49B@macports.org>

On Nov 13, 2009, at 10:24, rowue at macports.org wrote:

> Revision: 60480
>          http://trac.macports.org/changeset/60480
> Author:   rowue at macports.org
> Date:     2009-11-13 08:24:43 -0800 (Fri, 13 Nov 2009)
> Log Message:
> -----------
> Some changes to fix configure-errors (qmake-mac)


>         xinstall -m 755 -d ${destroot}/Applications/MacPorts/psi.app/Contents/Resources/plugins

You should change /Applications/MacPorts to ${applications_dir}.


> Modified: trunk/dports/net/psi-otr/files/patch-psi-otr.pro.diff
> ===================================================================


> +-LIBS += -lotr
> ++LIBS += -lotr -L/opt/local/lib
>  DEPENDPATH += .
>  INCLUDEPATH += .
> +INCLUDEPATH += /opt/local/include

You mustn't hardcode /opt/local; ${prefix} could be anything.



From dluke at geeklair.net  Fri Nov 13 14:31:14 2009
From: dluke at geeklair.net (Daniel J. Luke)
Date: Fri, 13 Nov 2009 17:31:14 -0500
Subject: PortGroup Perl
In-Reply-To: <20091113215802.GQ62534@darkart.com>
References: <5DA12956-EC23-4D0B-9674-44FAA3710D45@lavergne.gotdns.org>
	<20091113215802.GQ62534@darkart.com>
Message-ID: <16808286-A6E7-416C-BA54-C2FB160470F9@geeklair.net>

On Nov 13, 2009, at 4:58 PM, Eric Hall wrote:
> 	The basic idea is to have perl5 continue to
> default to perl5.8

This is probably OK for now, but we should really think about just defaulting to perl 5.10 ...
--
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.          |                          
+========================================================+




From opendarwin.org at darkart.com  Fri Nov 13 14:42:27 2009
From: opendarwin.org at darkart.com (Eric Hall)
Date: Fri, 13 Nov 2009 22:42:27 +0000
Subject: PortGroup Perl
In-Reply-To: <16808286-A6E7-416C-BA54-C2FB160470F9@geeklair.net>
References: <5DA12956-EC23-4D0B-9674-44FAA3710D45@lavergne.gotdns.org>
	<20091113215802.GQ62534@darkart.com>
	<16808286-A6E7-416C-BA54-C2FB160470F9@geeklair.net>
Message-ID: <20091113224227.GR62534@darkart.com>

On Fri, Nov 13, 2009 at 05:31:14PM -0500, Daniel J. Luke wrote:
> On Nov 13, 2009, at 4:58 PM, Eric Hall wrote:
> > 	The basic idea is to have perl5 continue to
> > default to perl5.8
> 
> This is probably OK for now, but we should really think about just defaulting to perl 5.10 ...

	Yes.  That'd be the part of the plan that didn't
make it from my brain to my fingers...
	My idea is to get through this set of changes so we
can do further and more wide-spread testing using perl5 as perl5.10
without altering perl5 (as perl5.8) for everyone who doesn't want
to test.  Then we can do the switch to defaulting to perl5.10.


		-eric


From emer at emer.net  Fri Nov 13 15:28:38 2009
From: emer at emer.net (Mark Anderson)
Date: Fri, 13 Nov 2009 18:28:38 -0500
Subject: [MacPorts] #22512: geda-gaf 1.6.0 complains about missing 
	update-desktop-database
In-Reply-To: <067.fcbebd3fd54e7d3deae60ea0ab00902f@macports.org>
References: <058.3f6b8b2c6d75b580d1076a652b33d124@macports.org> 
	<067.fcbebd3fd54e7d3deae60ea0ab00902f@macports.org>
Message-ID: <2cf4100f0911131528p52967d71m7a718afb8da19ba2@mail.gmail.com>

I posted a diff with the workaround, gEDA doesn't really need it
anyway.  It did not error for me, however.  Did you build on Quartz or
X11, and do you have Gnome installed?

Mark

On Fri, Nov 13, 2009 at 8:20 AM, MacPorts <noreply at macports.org> wrote:
> #22512: geda-gaf 1.6.0 complains about missing update-desktop-database
> ------------------------------------+---------------------------------------
> ?Reporter: ?michael@? ? ? ? ? ? ? ? | ? ? ? Owner: ?emer@?
> ? ? Type: ?defect ? ? ? ? ? ? ? ? ?| ? ? ?Status: ?new
> ?Priority: ?Normal ? ? ? ? ? ? ? ? ?| ? Milestone:
> Component: ?ports ? ? ? ? ? ? ? ? ? | ? ? Version: ?1.8.1
> ?Keywords: ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? ? ?Port: ?geda-gaf
> ------------------------------------+---------------------------------------
> Changes (by jmr@?):
>
> ?* cc: emer@? (removed)
> ?* owner: ?macports-tickets@? => emer@?
>
>
> --
> Ticket URL: <http://trac.macports.org/ticket/22512#comment:1>
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS
>

From perry at macports.org  Fri Nov 13 20:30:25 2009
From: perry at macports.org (Perry Lee)
Date: Fri, 13 Nov 2009 20:30:25 -0800
Subject: edits to googlecode.tcl
In-Reply-To: <66722DFD-DCA6-4B6B-ADE7-714FBC2284E5@lavergne.gotdns.org>
References: <66722DFD-DCA6-4B6B-ADE7-714FBC2284E5@lavergne.gotdns.org>
Message-ID: <4AFE3261.6010905@macports.org>

Jeremy Lavergne wrote:
> I edited googlecode.tcl to incorporate a second variation of the googecode URL.  After this change, however, there are a handful of portfiles that are breaking.
> 
> The first port that happens to be breaking for me is dot2tex.
> 
> It uses a custom homepage but the googlecode master_sites, and has it's own livecheck regex and url defined.
> 
> So the if condition for setting the livecheck.name follows ...
>  * has home page
>  * livecheck.name is still "default"
>  * { pull regex from code.google.com or pull regex from *.googlecode.com }
> 
> It seems to me that the logic is correct and should return false, but I'm lost as to why it's an error now but wasn't in the past.
> 
> Any thoughts?

Fixed in r60501. It was just a typo :) - 'regex' instead of 'regexp'.

From jeremy at lavergne.gotdns.org  Sat Nov 14 06:48:43 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Sat, 14 Nov 2009 09:48:43 -0500
Subject: edits to googlecode.tcl
In-Reply-To: <4AFE3261.6010905@macports.org>
References: <66722DFD-DCA6-4B6B-ADE7-714FBC2284E5@lavergne.gotdns.org>
	<4AFE3261.6010905@macports.org>
Message-ID: <06A4DA7E-BEBE-447E-9DC2-AA063036F07C@lavergne.gotdns.org>

>> I edited googlecode.tcl to incorporate a second variation of the googecode URL.  After this change, however, there are a handful of portfiles that are breaking.
>> The first port that happens to be breaking for me is dot2tex.
>> It uses a custom homepage but the googlecode master_sites, and has it's own livecheck regex and url defined.
>> So the if condition for setting the livecheck.name follows ...
>> * has home page
>> * livecheck.name is still "default"
>> * { pull regex from code.google.com or pull regex from *.googlecode.com }
>> It seems to me that the logic is correct and should return false, but I'm lost as to why it's an error now but wasn't in the past.
>> Any thoughts?
> 
> Fixed in r60501. It was just a typo :) - 'regex' instead of 'regexp'.

Bah, thank you!

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

From mmoll at macports.org  Sat Nov 14 08:38:37 2009
From: mmoll at macports.org (Mark Moll)
Date: Sat, 14 Nov 2009 10:38:37 -0600
Subject: [60495] trunk/dports/science/hdf5-18
In-Reply-To: <CD98A7B9-94B8-445F-98F5-D03838B28A9D@googlemail.com>
References: <20091114000401.BBA5F32395EA@beta.macosforge.org>
	<CD98A7B9-94B8-445F-98F5-D03838B28A9D@googlemail.com>
Message-ID: <B1312B76-F040-445C-9CA6-84AD62A3A738@macports.org>


On Nov 14, 2009, at 7:21 AM, Jochen K?pper wrote:

> On 14.11.2009, at 01:04, mmoll at macports.org wrote:
> 
>> Remove old cruft and threadsafe variant which is unsupported on OS X
> 
> Well, the variant was unsupported, but where does it say that the HDF5 configure option as such is unsupported on OS X?

http://www.hdfgroup.org/HDF5/release/SuppConfigFeats5.html

> Please leave the option in as a variant (unsupported by you, if you wish). We use it, it seems to work in our specific case?


Let me try this option and see if it passes ?make check?.

-- 
Mark




From mmoll at macports.org  Sat Nov 14 10:32:30 2009
From: mmoll at macports.org (Mark Moll)
Date: Sat, 14 Nov 2009 12:32:30 -0600
Subject: [60495] trunk/dports/science/hdf5-18
In-Reply-To: <B1312B76-F040-445C-9CA6-84AD62A3A738@macports.org>
References: <20091114000401.BBA5F32395EA@beta.macosforge.org>
	<CD98A7B9-94B8-445F-98F5-D03838B28A9D@googlemail.com>
	<B1312B76-F040-445C-9CA6-84AD62A3A738@macports.org>
Message-ID: <8EFDCA44-FE07-40AA-ABCD-29BFEA0A3623@macports.org>


On Nov 14, 2009, at 10:38 AM, Mark Moll wrote:
> On Nov 14, 2009, at 7:21 AM, Jochen K?pper wrote:
> 
>> On 14.11.2009, at 01:04, mmoll at macports.org wrote:
>> 
>>> Remove old cruft and threadsafe variant which is unsupported on OS X
>> 
>> Well, the variant was unsupported, but where does it say that the HDF5 configure option as such is unsupported on OS X?
> 
> http://www.hdfgroup.org/HDF5/release/SuppConfigFeats5.html
> 
>> Please leave the option in as a variant (unsupported by you, if you wish). We use it, it seems to work in our specific case?
> 
> 
> Let me try this option and see if it passes ?make check?.


It does. I added back the threadsafe variant in r60525. It should show up in PortIndex later today.

-- 
Mark


From ryandesign at macports.org  Sat Nov 14 13:54:07 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 14 Nov 2009 15:54:07 -0600
Subject: [60530] trunk/dports/science/gromacs/Portfile
In-Reply-To: <20091114205751.35EA832737C8@beta.macosforge.org>
References: <20091114205751.35EA832737C8@beta.macosforge.org>
Message-ID: <CD580CD1-2550-4A16-8E2D-F47079A14BBF@macports.org>


On Nov 14, 2009, at 14:57, adfernandes at macports.org wrote:

> Revision: 60530
>          http://trac.macports.org/changeset/60530
> Author:   adfernandes at macports.org
> Date:     2009-11-14 12:57:50 -0800 (Sat, 14 Nov 2009)
> Log Message:
> -----------
> Closes #22374; Splits gromacs into single (the default) and gromacs-double (double-precision) packages so they can be co-installed, much like fftw3 and fftw3-single
> 
> Modified Paths:

Is there no way to make the single "gromacs" port install both single- and double-precision parts at once? That's how I had hoped fftw would go.



From brooks at clarksonline.net  Sun Nov 15 15:50:26 2009
From: brooks at clarksonline.net (M. Brooks Clark)
Date: Sun, 15 Nov 2009 17:50:26 -0600
Subject: Please commit updated portfiles for radlib and wview
Message-ID: <7D162F65-ED30-4321-8727-1F40550117D3@clarksonline.net>

I have submitted new portfiles for radlib (Ticket #22556) and wview (Ticket #22558). These new portfiles target updated versions of both programs and address issues identified in the previous portfiles.

Can someone commit them to the distribution?


Thanks,


Brooks

http://www.clarkwx.net
________________________


From talklists at newgeo.com  Mon Nov 16 00:58:45 2009
From: talklists at newgeo.com (Scott Haneda)
Date: Mon, 16 Nov 2009 00:58:45 -0800
Subject: luabind
In-Reply-To: <37B228A5-4394-4A41-A10C-C7672BEF3E36@mokafolio.de>
References: <37B228A5-4394-4A41-A10C-C7672BEF3E36@mokafolio.de>
Message-ID: <D4B93303-E221-4C16-86F8-715859D95F5E@newgeo.com>

Updated the ticket on this one, cross posting to dev list as well:
https://trac.macports.org/ticket/22334
--  
Scott * If you contact me off list replace talklists@ with scott@ *

On Nov 13, 2009, at 7:57 AM, Matthias D?rfelt wrote:

> I just saw that luabind was submitted to macports. I am really  
> looking forward to it since I had a really hard time building it  
> from scratch last time (as far as I remember I could only manage to  
> do so, by making an xCode project to do so.- all my tries building  
> it with boost build from the terminal failed).
> The ticket is here:
> http://trac.macports.org/ticket/22334
>
> How long does it usually take till it will be available?


From dreamcat4 at gmail.com  Mon Nov 16 15:04:27 2009
From: dreamcat4 at gmail.com (dreamcat four)
Date: Mon, 16 Nov 2009 23:04:27 +0000
Subject: Improve launchd / startupitems functionality ?
Message-ID: <99cf22520911161504m30fda773n1a51fd43aab4f068@mail.gmail.com>

Hi all,

It's recently come to my attention that we could add / extend various
launchd settings functionality. My question is what are people's
opinions on improving the startupitems functionality? It seems no-one
is particularly keen to mess around with the portstartupitem.tcl too
much. BUT i'd dearly like to help contribute whatever improvements can
be made without upsetting the apple-cart, as it were.

TCL Source:
http://trac.macports.org/browser/trunk/base/src/port1.0/portstartupitem.tcl

1 Example (no ticket yet):

Extend these new `port load` and `port unload` commands. Couldn't we
make these commands map to any org.macports.service ? (and not just
the daemondo labels). I.e. if there is no daemondo label found, then
try to run "launchctl load -w
/Library/LaunchDaemons/org.macports.${service}.plist ?


Other Examples In Tickets:
http://trac.macports.org/ticket/18174
http://trac.macports.org/ticket/22570
http://trac.macports.org/ticket/22449
http://trac.macports.org/ticket/22471


It's my hope that such avenues are worthwhile to investigate, and
perhaps to implement them if no objections.
Some feedback would be appreciated.


dreamcat4
dreamcat4 at gmail.com

From talklists at newgeo.com  Mon Nov 16 15:31:20 2009
From: talklists at newgeo.com (Scott Haneda)
Date: Mon, 16 Nov 2009 15:31:20 -0800
Subject: replaced_by and final port review ( pureftpd pure-ftpd )
Message-ID: <EDB39A8E-EF25-46DF-B94E-8C36700F6B0A@newgeo.com>

I made an effort to use replaced_by, but I am not seeing it in the docs.

I have a new port, pure-ftpd, the old port is pureftpd (off by one dash)

My local repo is ~/macports
cd ~/macports/net
cp -R pure-ftpd pureftpd
cd pureftpd
port edit

Added into the Portfile, at the top, after the name:
replaced_by	pure-ftpd
Changed the name of the portfile to the old name, pureftpd

Saved the file

cd ~/macports; portindex

Creating software index in /Users/me/macports
Adding port net/pure-ftpd
Adding port net/pureftpd

cd ~/macports/pureftpd
sudo port -d install

And it happily went about installing itself.  Where did I slip up, and  
what is the bare min I need in the replaced_by Portfile? I was  
thinking just:
PortSystem          1.0

name                pureftpd
replaced_by	    pure-ftpd
categories          net
platforms           darwin

I then submit that diff to the original port?

I am going to submit this today/tonight if I finish up the launchd  
plist's that I want to add to this, but the Portfile seems to be done,  
and works.  There was an update to pure-ftpd two days ago, so I bumped  
it and made the needed changes.  It passed livecheck, which told me I  
needed an update before I bumped it.

http://dl.getdropbox.com/u/340087/Drops/11.16.09/Portfile-dea0db16-151709.txt

I am happy with the variants languages section, so if someone can look  
at that and tell me I did good or bad, I would appreciate it.  I have  
many languages, prepending lang_ to them, which of could would freak  
out configure since it does not want to see lang_.  With a little tcl  
repeat loop, I was able to make adding languages easier.

I wish I remember which port that was pointed to me that got me down  
the path of using an eval to generate the variants.

What else is cool, is that in working with the developer, I got -- 
localstatedir, which I think as of this release, is not needed  
anymore, but with that, and a few other things, every man page is  
updated to use ${prefix} as well.  At least, nothing is in /etc  
anymore.  Pretty nice.
-- 
Scott * If you contact me off list replace talklists@ with scott@ *


From ryandesign at macports.org  Mon Nov 16 15:48:29 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 16 Nov 2009 17:48:29 -0600
Subject: replaced_by and final port review ( pureftpd pure-ftpd )
In-Reply-To: <EDB39A8E-EF25-46DF-B94E-8C36700F6B0A@newgeo.com>
References: <EDB39A8E-EF25-46DF-B94E-8C36700F6B0A@newgeo.com>
Message-ID: <EBF50261-4100-4546-96BC-6DBA387528C0@macports.org>


On Nov 16, 2009, at 17:31, Scott Haneda wrote:

> I made an effort to use replaced_by, but I am not seeing it in the docs.

It is new for 1.8.0 and has yet to be documented.


> I have a new port, pure-ftpd, the old port is pureftpd (off by one dash)
> 
> My local repo is ~/macports
> cd ~/macports/net
> cp -R pure-ftpd pureftpd
> cd pureftpd
> port edit
> 
> Added into the Portfile, at the top, after the name:
> replaced_by	pure-ftpd
> Changed the name of the portfile to the old name, pureftpd
> 
> Saved the file
> 
> cd ~/macports; portindex
> 
> Creating software index in /Users/me/macports
> Adding port net/pure-ftpd
> Adding port net/pureftpd
> 
> cd ~/macports/pureftpd
> sudo port -d install
> 
> And it happily went about installing itself.

I recall somebody else reporting this too. As I recall, "replaced_by" makes it so that if a user already has pureftpd installed, "port outdated" will show they need to upgrade to pure-ftpd, and "sudo port upgrade pureftpd" will uninstall pureftpd and will install pure-ftpd. However, "replaced_by" does nothing to prevent a user from trying to "sudo port install pureftpd". If I'm remembering that correctly, then it would be nice if this were fixed in MacPorts base.


> Where did I slip up, and what is the bare min I need in the replaced_by Portfile? I was thinking just:
> PortSystem          1.0
> 
> name                pureftpd
> replaced_by	    pure-ftpd
> categories          net
> platforms           darwin

I think you'll at least need to add a version. To fix the above issue, I would also add a pre-fetch block to prevent installation. Run port lint, see what else it says. Though port lint may still need to be adjusted for the new realities of the replaced_by keyword.


> I then submit that diff to the original port?



From mdippery at gmail.com  Tue Nov 17 09:07:52 2009
From: mdippery at gmail.com (Michael Dippery)
Date: Tue, 17 Nov 2009 12:07:52 -0500
Subject: gambit-c patch
Message-ID: <70A2808D-A0A3-4CA7-BE8A-E3EC41440879@gmail.com>

Approximately 7 weeks ago, I submitted a patch for the gambit-c port  
that fixes a conflict with Ghostscript. The details of that patch are  
available at <http://trac.macports.org/ticket/21657>. I noticed that  
the version for gambit-c has been updated recently, but I have not  
heard anything about the patch, and it appears that no other changes  
have been made to the port. I'd like for the patch to be submitted, or  
least to have some discussion/feedback about the change.


Thanks,



=====================
Michael Dippery
mdippery at gmail.com


From ryandesign at macports.org  Tue Nov 17 15:07:47 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 17 Nov 2009 17:07:47 -0600
Subject: [60530] trunk/dports/science/gromacs/Portfile
In-Reply-To: <973ae5cd0911170752g68bfc92cxdfc35bab1cc64f16@mail.gmail.com>
References: <20091114205751.35EA832737C8@beta.macosforge.org>
	<CD580CD1-2550-4A16-8E2D-F47079A14BBF@macports.org>
	<973ae5cd0911170752g68bfc92cxdfc35bab1cc64f16@mail.gmail.com>
Message-ID: <89375A0D-D479-4480-9FAD-FD42AB74FFE8@macports.org>


On Nov 17, 2009, at 09:52, Andrew Fernandes wrote:

>> Is there no way to make the single "gromacs" port install both single- and double-precision parts at once? That's how I had hoped fftw would go.
> 
> Hi, Ryan - 
> 
> Excellent question - I beat my head against it for a while because I agree with you, but the build script (autotools) changes a *lot* of things if the "double-precision" option is selected.
> 
> Basically, you'd have to run two sequential builds, destroot them separately, then merge. Waaaay too much work. If someone wants to do that with the Portfile, I'd be happy with it, but... no simple way - and I tried.
> 
> The reality is that very very few people should need the double-precision mode. It is provided for a specific type of computation that is not super-common, hence why "single precision" is the default.

Ok, sounds good, thanks for the explanation.



From ryandesign at macports.org  Tue Nov 17 16:07:16 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 17 Nov 2009 18:07:16 -0600
Subject: gambit-c patch
In-Reply-To: <70A2808D-A0A3-4CA7-BE8A-E3EC41440879@gmail.com>
References: <70A2808D-A0A3-4CA7-BE8A-E3EC41440879@gmail.com>
Message-ID: <DB0ED4AA-74A6-4AF6-BA45-3961EC2E2E88@macports.org>


On Nov 17, 2009, at 11:07, Michael Dippery wrote:

> Approximately 7 weeks ago, I submitted a patch for the gambit-c port that fixes a conflict with Ghostscript. The details of that patch are available at <http://trac.macports.org/ticket/21657>. I noticed that the version for gambit-c has been updated recently, but I have not heard anything about the patch, and it appears that no other changes have been made to the port. I'd like for the patch to be submitted, or least to have some discussion/feedback about the change.

I have assigned the ticket to the port's maintainer who should take care of it.


From lists at supported.de  Thu Nov 19 01:47:25 2009
From: lists at supported.de (lists at supported.de)
Date: Thu, 19 Nov 2009 10:47:25 +0100
Subject: [#22529] No response on ticket for netatalk Port update/fix
Message-ID: <29da69cbf4f10669e05f6dce73d3b8a4@localhost>

Hello macporters,

I've filed a ticket to which there has been no resonse so far. My
apologies if it's still to early to bring this to attention here.
https://trac.macports.org/ticket/22529

The port is unmaintained and I'm *cough* somewhat familiar with it. If
necessary I'd be willing to maintain it. Shall I write to
macports-mgr at lists.macosforge.org regarding this?

Thanks!
-Frank

From dluke at geeklair.net  Thu Nov 19 07:06:03 2009
From: dluke at geeklair.net (Daniel J. Luke)
Date: Thu, 19 Nov 2009 10:06:03 -0500
Subject: [#22529] No response on ticket for netatalk Port update/fix
In-Reply-To: <29da69cbf4f10669e05f6dce73d3b8a4@localhost>
References: <29da69cbf4f10669e05f6dce73d3b8a4@localhost>
Message-ID: <138E2D25-DE60-4C35-A081-CA85DE434726@geeklair.net>

On Nov 19, 2009, at 4:47 AM, <lists at supported.de> <lists at supported.de> wrote:
> The port is unmaintained and I'm *cough* somewhat familiar with it. If
> necessary I'd be willing to maintain it. Shall I write to
> macports-mgr at lists.macosforge.org regarding this?

Since you've volunteered to maintain it, I've gone ahead and committed your patch (with a really minor change) and added you as the maintainer for the port.

Thanks for contributing!
--
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.          |                          
+========================================================+




From lists at supported.de  Thu Nov 19 08:18:15 2009
From: lists at supported.de (lists at supported.de)
Date: Thu, 19 Nov 2009 17:18:15 +0100
Subject: Port maintainer newbie (was: [#22529] No response on ticket for
	netatalk Port update/fix)
In-Reply-To: <138E2D25-DE60-4C35-A081-CA85DE434726@geeklair.net>
References: <29da69cbf4f10669e05f6dce73d3b8a4@localhost>
	<138E2D25-DE60-4C35-A081-CA85DE434726@geeklair.net>
Message-ID: <6a3c0c1d9049be5cd6287f4d42174c32@localhost>

On Thu, 19 Nov 2009 10:06:03 -0500, "Daniel J. Luke" <dluke at geeklair.net>
wrote:
> On Nov 19, 2009, at 4:47 AM, <lists at supported.de> <lists at supported.de>
> wrote:
>> The port is unmaintained and I'm *cough* somewhat familiar with it. If
>> necessary I'd be willing to maintain it. Shall I write to
>> macports-mgr at lists.macosforge.org regarding this?
> 
> Since you've volunteered to maintain it, I've gone ahead and committed
> your patch (with a really minor change) and added you as the maintainer
for
> the port.

Great, thanks!

What rights do I receive from the maintainer status and how do I use them?
RTFM? The guide? I've checked it but can't find any reference.

Thanks!
Ralph

From lists at supported.de  Thu Nov 19 08:45:19 2009
From: lists at supported.de (lists at supported.de)
Date: Thu, 19 Nov 2009 17:45:19 +0100
Subject: Port maintainer newbie (was: [#22529] No response on ticket for
	netatalk Port update/fix)
In-Reply-To: <6a3c0c1d9049be5cd6287f4d42174c32@localhost>
References: <29da69cbf4f10669e05f6dce73d3b8a4@localhost>
	<138E2D25-DE60-4C35-A081-CA85DE434726@geeklair.net>
	<6a3c0c1d9049be5cd6287f4d42174c32@localhost>
Message-ID: <ef96d9ca0b6d6e8f33c67d4b7a26cd42@localhost>

On Thu, 19 Nov 2009 17:18:15 +0100, <lists at supported.de> wrote:
> On Thu, 19 Nov 2009 10:06:03 -0500, "Daniel J. Luke"
<dluke at geeklair.net>
> wrote:
>> On Nov 19, 2009, at 4:47 AM, <lists at supported.de> <lists at supported.de>
>> wrote:
>>> The port is unmaintained and I'm *cough* somewhat familiar with it. If
>>> necessary I'd be willing to maintain it. Shall I write to
>>> macports-mgr at lists.macosforge.org regarding this?
>> 
>> Since you've volunteered to maintain it, I've gone ahead and committed
>> your patch (with a really minor change) and added you as the maintainer
> for
>> the port.
> 
> Great, thanks!
> 
> What rights do I receive from the maintainer status and how do I use
them?
> RTFM? The guide? I've checked it but can't find any reference.

I guess I found part two:
http://trac.macports.org/wiki/GetMacPortsSource

So the question remains: can I commit?

Thanks!

From ryandesign at macports.org  Thu Nov 19 08:54:04 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 19 Nov 2009 10:54:04 -0600
Subject: Port maintainer newbie (was: [#22529] No response on ticket for
	netatalk Port update/fix)
In-Reply-To: <ef96d9ca0b6d6e8f33c67d4b7a26cd42@localhost>
References: <29da69cbf4f10669e05f6dce73d3b8a4@localhost>
	<138E2D25-DE60-4C35-A081-CA85DE434726@geeklair.net>
	<6a3c0c1d9049be5cd6287f4d42174c32@localhost>
	<ef96d9ca0b6d6e8f33c67d4b7a26cd42@localhost>
Message-ID: <68BD4072-A873-473D-A185-A733F5A8BB8B@macports.org>


On Nov 19, 2009, at 10:45, <lists at supported.de> <lists at supported.de> wrote:

> On Thu, 19 Nov 2009 17:18:15 +0100, <lists at supported.de> wrote:
> 
>> What rights do I receive from the maintainer status and how do I use
>> them?

> So the question remains: can I commit?

Being the maintainer of a port means you are responsible for updating it in ways you see fit, and that tickets filed about the port will be assigned to you for resolution. In the absence of commit access, you supply your desired changes as patches in the issue tracker, which a committer will review and commit.

Commit access is separate, and the prerequisites for granting it are a history of involvement in the project. So I recommend you contribute patches and updates to your port and other ports (by filing tickets), volunteer to maintain additional ports if possible, and contribute on these mailing lists, and after a time, if you wish, then apply for commit access.

http://guide.macports.org/chunked/project.membership.html




From lists at supported.de  Thu Nov 19 09:46:26 2009
From: lists at supported.de (=?iso-8859-1?Q?Ralph_B=F6hme?=)
Date: Thu, 19 Nov 2009 18:46:26 +0100
Subject: Port maintainer newbie (was: [#22529] No response on ticket for
	netatalk Port update/fix)
In-Reply-To: <68BD4072-A873-473D-A185-A733F5A8BB8B@macports.org>
References: <29da69cbf4f10669e05f6dce73d3b8a4@localhost>
	<138E2D25-DE60-4C35-A081-CA85DE434726@geeklair.net>
	<6a3c0c1d9049be5cd6287f4d42174c32@localhost>
	<ef96d9ca0b6d6e8f33c67d4b7a26cd42@localhost>
	<68BD4072-A873-473D-A185-A733F5A8BB8B@macports.org>
Message-ID: <AE946D36-7C70-408C-B54D-F71B07FC0314@supported.de>


Am 19.11.2009 um 17:54 schrieb Ryan Schmidt:

> On Nov 19, 2009, at 10:45, <lists at supported.de> <lists at supported.de> wrote:
> 
>> On Thu, 19 Nov 2009 17:18:15 +0100, <lists at supported.de> wrote:
>> 
>>> What rights do I receive from the maintainer status and how do I use
>>> them?
> 
>> So the question remains: can I commit?
> 
> Being the maintainer of a port means you are responsible for updating it in ways you see fit, and that tickets filed about the port will be assigned to you for resolution. In the absence of commit access, you supply your desired changes as patches in the issue tracker, which a committer will review and commit.
> 
> Commit access is separate, and the prerequisites for granting it are a history of involvement in the project. So I recommend you contribute patches and updates to your port and other ports (by filing tickets), volunteer to maintain additional ports if possible, and contribute on these mailing lists, and after a time, if you wish, then apply for commit access.
> 
> http://guide.macports.org/chunked/project.membership.html

Ok, thanks! That way it's more time consuming for me but I see the necessity for some control on who can commit.

-Ralph

From jmr at macports.org  Thu Nov 19 10:07:10 2009
From: jmr at macports.org (Joshua Root)
Date: Fri, 20 Nov 2009 05:07:10 +1100
Subject: [60662] trunk/base/src/port1.0/portconfigure.tcl
In-Reply-To: <20091119173430.793FE33D1247@beta.macosforge.org>
References: <20091119173430.793FE33D1247@beta.macosforge.org>
Message-ID: <4B05894E.2070106@macports.org>

On 2031-9-15 05:59, jeremyhu at macports.org wrote:
> Revision: 60662
>           http://trac.macports.org/changeset/60662
> Author:   jeremyhu at macports.org
> Date:     2009-11-19 09:34:26 -0800 (Thu, 19 Nov 2009)
> Log Message:
> -----------
> Set LDFLAGS when changing build_arch.

I didn't do this in the first place because I wasn't sure if there would
be a problem with ports using non-Apple compilers, which would have -m32
or -m64 in LDFLAGS, and could end up calling ld with those flags
directly. Do you think this will be rare enough that it won't be a
problem to just fix up the few affected portfiles?

- Josh

From ryandesign at macports.org  Thu Nov 19 10:25:31 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 19 Nov 2009 12:25:31 -0600
Subject: Port maintainer newbie (was: [#22529] No response on ticket for
	netatalk Port update/fix)
In-Reply-To: <AE946D36-7C70-408C-B54D-F71B07FC0314@supported.de>
References: <29da69cbf4f10669e05f6dce73d3b8a4@localhost>
	<138E2D25-DE60-4C35-A081-CA85DE434726@geeklair.net>
	<6a3c0c1d9049be5cd6287f4d42174c32@localhost>
	<ef96d9ca0b6d6e8f33c67d4b7a26cd42@localhost>
	<68BD4072-A873-473D-A185-A733F5A8BB8B@macports.org>
	<AE946D36-7C70-408C-B54D-F71B07FC0314@supported.de>
Message-ID: <9757923D-68EF-4560-BBAB-442D45ACDE27@macports.org>


On Nov 19, 2009, at 11:46, Ralph B?hme wrote:

>> Being the maintainer of a port means you are responsible for updating it in ways you see fit, and that tickets filed about the port will be assigned to you for resolution. In the absence of commit access, you supply your desired changes as patches in the issue tracker, which a committer will review and commit.
>> 
>> Commit access is separate, and the prerequisites for granting it are a history of involvement in the project. So I recommend you contribute patches and updates to your port and other ports (by filing tickets), volunteer to maintain additional ports if possible, and contribute on these mailing lists, and after a time, if you wish, then apply for commit access.
>> 
>> http://guide.macports.org/chunked/project.membership.html
> 
> Ok, thanks! That way it's more time consuming for me but I see the necessity for some control on who can commit.

It is more time consuming, and I apologize for that inconvenience, but there are many nuances of Portfile writing that aren't always apparent at first glance. Submitting your proposals as diffs attached to tickets lets more experienced Portfile writers review your changes and suggest improvements or point out issues you may not have considered (or even known to consider). I have a few feedback items for you regarding the change from #22529 that I'll write up a little later. But once your patches are generally getting committed without changes, we'd be happy to have you as a committer.



From jeremyhu at macports.org  Thu Nov 19 11:44:18 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Thu, 19 Nov 2009 11:44:18 -0800
Subject: [60662] trunk/base/src/port1.0/portconfigure.tcl
In-Reply-To: <4B05894E.2070106@macports.org>
References: <20091119173430.793FE33D1247@beta.macosforge.org>
	<4B05894E.2070106@macports.org>
Message-ID: <296FAF4A-CE8C-4A9A-AD5C-B91C51B08530@macports.org>


On Nov 19, 2009, at 10:07, Joshua Root wrote:

> On 2031-9-15 05:59, jeremyhu at macports.org wrote:
>> Revision: 60662
>>          http://trac.macports.org/changeset/60662
>> Author:   jeremyhu at macports.org
>> Date:     2009-11-19 09:34:26 -0800 (Thu, 19 Nov 2009)
>> Log Message:
>> -----------
>> Set LDFLAGS when changing build_arch.
> 
> I didn't do this in the first place because I wasn't sure if there would
> be a problem with ports using non-Apple compilers, which would have -m32
> or -m64 in LDFLAGS, and could end up calling ld with those flags
> directly. Do you think this will be rare enough that it won't be a
> problem to just fix up the few affected portfiles?

I did it to fix a build issue with firefox-x11-devel.  I expected that setting the configure.build_arch would be sufficient, and I was surprised to see that it didn't set LDFLAGS as I expected.

As for "non-Apple toolchains" ... isnt' that what [arch_flag_supported] is designed to handle in this hunk:

@@ -220,7 +220,7 @@
    } elseif {[tbool configure.m32]} {
        set flags "-m32"
    } elseif {${configure.build_arch} != ""} {
-        if {[arch_flag_supported] && ($tool == "cc" || $tool == "cxx" || $tool == "objc")} {
+        if {[arch_flag_supported] && ($tool == "cc" || $tool == "cxx" || $tool == "objc" || $tool == "ld")} {
            set flags "-arch ${configure.build_arch}"
        } elseif {${configure.build_arch} == "x86_64" || ${configure.build_arch} == "ppc64"} {
            set flags "-m64"


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

From jmr at macports.org  Thu Nov 19 11:54:08 2009
From: jmr at macports.org (Joshua Root)
Date: Fri, 20 Nov 2009 06:54:08 +1100
Subject: [60662] trunk/base/src/port1.0/portconfigure.tcl
In-Reply-To: <296FAF4A-CE8C-4A9A-AD5C-B91C51B08530@macports.org>
References: <20091119173430.793FE33D1247@beta.macosforge.org>
	<4B05894E.2070106@macports.org>
	<296FAF4A-CE8C-4A9A-AD5C-B91C51B08530@macports.org>
Message-ID: <4B05A260.5070201@macports.org>

On 2009-11-20 06:44, Jeremy Huddleston wrote:
> On Nov 19, 2009, at 10:07, Joshua Root wrote:
> 
>> On 2031-9-15 05:59, jeremyhu at macports.org wrote:
>>> Revision: 60662
>>>          http://trac.macports.org/changeset/60662
>>> Author:   jeremyhu at macports.org
>>> Date:     2009-11-19 09:34:26 -0800 (Thu, 19 Nov 2009)
>>> Log Message:
>>> -----------
>>> Set LDFLAGS when changing build_arch.
>> I didn't do this in the first place because I wasn't sure if there would
>> be a problem with ports using non-Apple compilers, which would have -m32
>> or -m64 in LDFLAGS, and could end up calling ld with those flags
>> directly. Do you think this will be rare enough that it won't be a
>> problem to just fix up the few affected portfiles?
> 
> I did it to fix a build issue with firefox-x11-devel.  I expected that setting the configure.build_arch would be sufficient, and I was surprised to see that it didn't set LDFLAGS as I expected.

I agree it should be set when using an Apple compiler.

> As for "non-Apple toolchains" ... isnt' that what [arch_flag_supported] is designed to handle in this hunk:
> 
> @@ -220,7 +220,7 @@
>     } elseif {[tbool configure.m32]} {
>         set flags "-m32"
>     } elseif {${configure.build_arch} != ""} {
> -        if {[arch_flag_supported] && ($tool == "cc" || $tool == "cxx" || $tool == "objc")} {
> +        if {[arch_flag_supported] && ($tool == "cc" || $tool == "cxx" || $tool == "objc" || $tool == "ld")} {
>             set flags "-arch ${configure.build_arch}"
>         } elseif {${configure.build_arch} == "x86_64" || ${configure.build_arch} == "ppc64"} {
>             set flags "-m64"

Yes, but it's only doing the right thing for flags that are going to be
passed to a compiler. You can't do "ld -m64 ..."

- Josh

From jeremyhu at macports.org  Thu Nov 19 12:00:03 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Thu, 19 Nov 2009 12:00:03 -0800
Subject: [60662] trunk/base/src/port1.0/portconfigure.tcl
In-Reply-To: <4B05A260.5070201@macports.org>
References: <20091119173430.793FE33D1247@beta.macosforge.org>
	<4B05894E.2070106@macports.org>
	<296FAF4A-CE8C-4A9A-AD5C-B91C51B08530@macports.org>
	<4B05A260.5070201@macports.org>
Message-ID: <6368561C-6823-46F0-A178-4F6D275B095E@macports.org>

>> As for "non-Apple toolchains" ... isnt' that what [arch_flag_supported] is designed to handle in this hunk:
>> 
>> @@ -220,7 +220,7 @@
>>    } elseif {[tbool configure.m32]} {
>>        set flags "-m32"
>>    } elseif {${configure.build_arch} != ""} {
>> -        if {[arch_flag_supported] && ($tool == "cc" || $tool == "cxx" || $tool == "objc")} {
>> +        if {[arch_flag_supported] && ($tool == "cc" || $tool == "cxx" || $tool == "objc" || $tool == "ld")} {
>>            set flags "-arch ${configure.build_arch}"
>>        } elseif {${configure.build_arch} == "x86_64" || ${configure.build_arch} == "ppc64"} {
>>            set flags "-m64"
> 
> Yes, but it's only doing the right thing for flags that are going to be
> passed to a compiler. You can't do "ld -m64 ..."

Ah, ok.  I see what you were saying now...

So then how does one tell a non-Apple ld what arch to target?  Or is that not an option?

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

From jmr at macports.org  Thu Nov 19 12:04:15 2009
From: jmr at macports.org (Joshua Root)
Date: Fri, 20 Nov 2009 07:04:15 +1100
Subject: [60662] trunk/base/src/port1.0/portconfigure.tcl
In-Reply-To: <6368561C-6823-46F0-A178-4F6D275B095E@macports.org>
References: <20091119173430.793FE33D1247@beta.macosforge.org>
	<4B05894E.2070106@macports.org>
	<296FAF4A-CE8C-4A9A-AD5C-B91C51B08530@macports.org>
	<4B05A260.5070201@macports.org>
	<6368561C-6823-46F0-A178-4F6D275B095E@macports.org>
Message-ID: <4B05A4BF.3050504@macports.org>

On 2009-11-20 07:00, Jeremy Huddleston wrote:
>>> As for "non-Apple toolchains" ... isnt' that what [arch_flag_supported] is designed to handle in this hunk:
>>>
>>> @@ -220,7 +220,7 @@
>>>    } elseif {[tbool configure.m32]} {
>>>        set flags "-m32"
>>>    } elseif {${configure.build_arch} != ""} {
>>> -        if {[arch_flag_supported] && ($tool == "cc" || $tool == "cxx" || $tool == "objc")} {
>>> +        if {[arch_flag_supported] && ($tool == "cc" || $tool == "cxx" || $tool == "objc" || $tool == "ld")} {
>>>            set flags "-arch ${configure.build_arch}"
>>>        } elseif {${configure.build_arch} == "x86_64" || ${configure.build_arch} == "ppc64"} {
>>>            set flags "-m64"
>> Yes, but it's only doing the right thing for flags that are going to be
>> passed to a compiler. You can't do "ld -m64 ..."
> 
> Ah, ok.  I see what you were saying now...
> 
> So then how does one tell a non-Apple ld what arch to target?  Or is that not an option?

I don't think we care about non-Apple ld, so we can always use -arch if
the flag is in fact going to be passed straight to ld. The problem is
non-Apple gcc, which doesn't understand -arch. So we have to use
-m32/-m64 instead, which is fine to use in LDFLAGS if you link using
gcc, but not if you link with ld directly.

- Josh

From jeremyhu at macports.org  Thu Nov 19 12:35:04 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Thu, 19 Nov 2009 12:35:04 -0800
Subject: [60662] trunk/base/src/port1.0/portconfigure.tcl
In-Reply-To: <4B05A4BF.3050504@macports.org>
References: <20091119173430.793FE33D1247@beta.macosforge.org>
	<4B05894E.2070106@macports.org>
	<296FAF4A-CE8C-4A9A-AD5C-B91C51B08530@macports.org>
	<4B05A260.5070201@macports.org>
	<6368561C-6823-46F0-A178-4F6D275B095E@macports.org>
	<4B05A4BF.3050504@macports.org>
Message-ID: <985AEC52-C5A6-4A1F-9846-283934B6095F@macports.org>


On Nov 19, 2009, at 12:04, Joshua Root wrote:

> I don't think we care about non-Apple ld, so we can always use -arch if
> the flag is in fact going to be passed straight to ld. The problem is
> non-Apple gcc, which doesn't understand -arch. So we have to use
> -m32/-m64 instead, which is fine to use in LDFLAGS if you link using
> gcc, but not if you link with ld directly.

Ah... because of configure.m{32,64} ...

what about something like this?

Index: portconfigure.tcl
===================================================================
--- portconfigure.tcl	(revision 60662)
+++ portconfigure.tcl	(working copy)
@@ -228,6 +228,27 @@
             set flags "-m32"
         }
     }
+
+    if {$tool == "ld"} {
+        if {$flags == "-m64"} {
+            if {${configure.build_arch} == "i386" || ${configure.build_arch} == "x86_64"} {
+                set flags "-arch x86_64"
+            } elseif {${configure.build_arch} == "ppc" || ${configure.build_arch} == "ppc64"} {
+                set flags "-arch ppc64"
+            } else {
+                set flags ""
+            }
+        } elseif {$flags == "-m32"} {
+            if {${configure.build_arch} == "i386" || ${configure.build_arch} == "x86_64"} {
+                set flags "-arch i386"
+            } elseif {${configure.build_arch} == "ppc" || ${configure.build_arch} == "ppc64"} {
+                set flags "-arch ppc"
+            } else {
+                set flags ""
+            }
+        }
+    }
+
     return $flags
 }
 


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

From jmr at macports.org  Thu Nov 19 13:45:28 2009
From: jmr at macports.org (Joshua Root)
Date: Fri, 20 Nov 2009 08:45:28 +1100
Subject: [60662] trunk/base/src/port1.0/portconfigure.tcl
In-Reply-To: <985AEC52-C5A6-4A1F-9846-283934B6095F@macports.org>
References: <20091119173430.793FE33D1247@beta.macosforge.org>
	<4B05894E.2070106@macports.org>
	<296FAF4A-CE8C-4A9A-AD5C-B91C51B08530@macports.org>
	<4B05A260.5070201@macports.org>
	<6368561C-6823-46F0-A178-4F6D275B095E@macports.org>
	<4B05A4BF.3050504@macports.org>
	<985AEC52-C5A6-4A1F-9846-283934B6095F@macports.org>
Message-ID: <4B05BC78.6020805@macports.org>

On 2009-11-20 07:35, Jeremy Huddleston wrote:
> On Nov 19, 2009, at 12:04, Joshua Root wrote:
> 
>> I don't think we care about non-Apple ld, so we can always use -arch if
>> the flag is in fact going to be passed straight to ld. The problem is
>> non-Apple gcc, which doesn't understand -arch. So we have to use
>> -m32/-m64 instead, which is fine to use in LDFLAGS if you link using
>> gcc, but not if you link with ld directly.
> 
> Ah... because of configure.m{32,64} ...

Well, those are a problem too, but not what I was getting at. Anyway,
r60680 should take care of things.

- Josh

From jmr at macports.org  Fri Nov 20 09:43:38 2009
From: jmr at macports.org (Joshua Root)
Date: Sat, 21 Nov 2009 04:43:38 +1100
Subject: [60691] trunk/base/src/port1.0/porttest.tcl
In-Reply-To: <20091119235508.EF77633DD9C7@beta.macosforge.org>
References: <20091119235508.EF77633DD9C7@beta.macosforge.org>
Message-ID: <4B06D54A.3050502@macports.org>

On 2031-9-15 05:59, snc at macports.org wrote:
> Revision: 60691
>           http://trac.macports.org/changeset/60691
> Author:   snc at macports.org
> Date:     2009-11-19 15:55:08 -0800 (Thu, 19 Nov 2009)
> Log Message:
> -----------
> allow use of archives for test phase
> 
> Modified Paths:
> --------------
>     trunk/base/src/port1.0/porttest.tcl
> 
> Modified: trunk/base/src/port1.0/porttest.tcl
> ===================================================================
> --- trunk/base/src/port1.0/porttest.tcl	2009-11-19 23:54:20 UTC (rev 60690)
> +++ trunk/base/src/port1.0/porttest.tcl	2009-11-19 23:55:08 UTC (rev 60691)
> @@ -7,7 +7,11 @@
>  
>  set org.macports.test [target_new org.macports.test porttest::test_main]
>  target_provides ${org.macports.test} test
> -target_requires ${org.macports.test} main fetch extract checksum patch configure build
> +if {[option portarchivemode] == "yes"} {
> +target_requires ${org.macports.test} main unarchive fetch extract checksum patch configure build
> +} else {
> +    target_requires ${org.macports.test} main fetch extract checksum patch configure build
> +}
>  target_prerun ${org.macports.test} porttest::test_start
>  
>  namespace eval porttest {

Don't the vast majority of test phases require the worksrcdir, not just
the destroot?

- Josh

From jeremy at lavergne.gotdns.org  Fri Nov 20 09:53:43 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Fri, 20 Nov 2009 12:53:43 -0500
Subject: [60691] trunk/base/src/port1.0/porttest.tcl
In-Reply-To: <4B06D54A.3050502@macports.org>
References: <20091119235508.EF77633DD9C7@beta.macosforge.org>
	<4B06D54A.3050502@macports.org>
Message-ID: <C5B1F6EC-055A-4CF8-BFA6-328D607E8128@lavergne.gotdns.org>

I'm thinking you've got a good point.

Why am I full of fail lately?

On Nov 20, 2009, at 12:43 PM, Joshua Root wrote:

> Don't the vast majority of test phases require the worksrcdir, not just
> the destroot?

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

From lee at dropio.com  Wed Nov 25 07:00:18 2009
From: lee at dropio.com (Lee Azzarello)
Date: Wed, 25 Nov 2009 10:00:18 -0500
Subject: [MacPorts] #22219: opencore-amr port
In-Reply-To: <059.3afbfe458ff16a9ee5054062acfa5108@macports.org>
References: <050.d0a52223df806e22613da3a5af0fac30@macports.org>
	<059.3afbfe458ff16a9ee5054062acfa5108@macports.org>
Message-ID: <16b031c0911250700j5994f50bibf5d40008e92f23@mail.gmail.com>

The code has an Apache 2.0 license. Does that work with your distribution terms?

-lee

On Wed, Nov 25, 2009 at 3:39 AM, MacPorts <noreply at macports.org> wrote:
> #22219: opencore-amr port
> ----------------------------+-----------------------------------------------
> ?Reporter: ?lee@? ? ? ? ? ? | ? ? ? Owner: ?macports-tickets@?
> ? ? Type: ?submission ? ? ?| ? ? ?Status: ?new
> ?Priority: ?Normal ? ? ? ? ?| ? Milestone:
> Component: ?ports ? ? ? ? ? | ? ? Version:
> ?Keywords: ? ? ? ? ? ? ? ? ?| ? ? ? ?Port: ?opencore-amr
> ----------------------------+-----------------------------------------------
> Changes (by jmr@?):
>
> ?* cc: lee@? (removed)
> ?* keywords: ?audio =>
> ?* version: ?1.8.1 =>
> ?* port: ?audio/opencore-amr => opencore-amr
>
>
> Comment:
>
> ?Can we actually distribute this given that AMR is patent-encumbered?
>
> --
> Ticket URL: <http://trac.macports.org/ticket/22219#comment:2>
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS
>



-- 
_______________
Lee Azzarello
drop.io staff hacker

From ram at macports.org  Wed Nov 25 09:33:55 2009
From: ram at macports.org (Adam Mercer)
Date: Wed, 25 Nov 2009 11:33:55 -0600
Subject: Getting alerted when an attachment is added to a ticket
Message-ID: <799406d60911250933i4222343fw4d67bf54fcb85c67@mail.gmail.com>

Hi

Is there anyway that trac can be configured to send an email alert
when an attachment is added to a ticket? As I find my self constant
checking tickets to see if the requested log files have been uploaded.

Cheers

Adam

From wsiegrist at apple.com  Wed Nov 25 10:12:29 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Wed, 25 Nov 2009 10:12:29 -0800
Subject: Getting alerted when an attachment is added to a ticket
In-Reply-To: <799406d60911250933i4222343fw4d67bf54fcb85c67@mail.gmail.com>
References: <799406d60911250933i4222343fw4d67bf54fcb85c67@mail.gmail.com>
Message-ID: <2C74E0F9-AFCC-4E6D-BF73-196B2B7C8422@apple.com>

On Nov 25, 2009, at 9:33 AM, Adam Mercer wrote:

> Hi
> 
> Is there anyway that trac can be configured to send an email alert
> when an attachment is added to a ticket? As I find my self constant
> checking tickets to see if the requested log files have been uploaded.
> 


CC yourself on the ticket.

-Bill



From ram at macports.org  Wed Nov 25 11:11:17 2009
From: ram at macports.org (Adam Mercer)
Date: Wed, 25 Nov 2009 13:11:17 -0600
Subject: Getting alerted when an attachment is added to a ticket
In-Reply-To: <2C74E0F9-AFCC-4E6D-BF73-196B2B7C8422@apple.com>
References: <799406d60911250933i4222343fw4d67bf54fcb85c67@mail.gmail.com> 
	<2C74E0F9-AFCC-4E6D-BF73-196B2B7C8422@apple.com>
Message-ID: <799406d60911251111i666c06cai94eb032c9bcb3a64@mail.gmail.com>

On Wed, Nov 25, 2009 at 12:12, William Siegrist <wsiegrist at apple.com> wrote:

Bill

>> Is there anyway that trac can be configured to send an email alert
>> when an attachment is added to a ticket? As I find my self constant
>> checking tickets to see if the requested log files have been uploaded.
>
> CC yourself on the ticket.

I already am, but I receive no email whenever an attachment as added.

Cheers

Adam

From wsiegrist at apple.com  Wed Nov 25 11:26:25 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Wed, 25 Nov 2009 11:26:25 -0800
Subject: Getting alerted when an attachment is added to a ticket
In-Reply-To: <167F71AE-96F1-4F1D-9F94-DE0DE74EE64A@lavergne.gotdns.org>
References: <799406d60911250933i4222343fw4d67bf54fcb85c67@mail.gmail.com>
	<2C74E0F9-AFCC-4E6D-BF73-196B2B7C8422@apple.com>
	<167F71AE-96F1-4F1D-9F94-DE0DE74EE64A@lavergne.gotdns.org>
Message-ID: <A2BA06A4-8D8C-4F18-A506-512315BF09D2@apple.com>

Oh, you're right. 

http://trac.edgewall.org/ticket/2259

-Bill


On Nov 25, 2009, at 10:46 AM, Jeremy Lavergne wrote:

> From what I recall, that's never notified me of attachments before ...
> 
> On Nov 25, 2009, at 1:12 PM, William Siegrist wrote:
> 
>> On Nov 25, 2009, at 9:33 AM, Adam Mercer wrote:
>> 
>>> Hi
>>> 
>>> Is there anyway that trac can be configured to send an email alert
>>> when an attachment is added to a ticket? As I find my self constant
>>> checking tickets to see if the requested log files have been uploaded.
>>> 
>> 
>> 
>> CC yourself on the ticket.
>> 
>> -Bill
>> 





From ryandesign at macports.org  Wed Nov 25 14:57:50 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 25 Nov 2009 16:57:50 -0600
Subject: [MacPorts] Migration deleted version
In-Reply-To: <20091125190434.D89778098861@mail-out4.apple.com>
References: <20091125190434.D89778098861@mail-out4.apple.com>
Message-ID: <45375B07-5887-4601-88D6-B1BBB5CE07B5@macports.org>

On Nov 25, 2009, at 13:00, MacPorts wrote:

> Changed page "Migration" by molly.moonwalk at gmail.com from 209.250.241.41*
> Page URL: <http://trac.macports.org/wiki/Migration>
> Diff URL: <http://trac.macports.org/wiki/Migration?action=diff&version=16>
> Revision 16

[snip]


On Nov 25, 2009, at 13:04, MacPorts wrote:

> Page URL: <http://trac.macports.org/wiki/Migration>
> Deleted version "16" of page "Migration" by  ryandesign at macports.org from 70.253.95.39*

[snip]

Curious that it misreports the author of the version in the deletion message, and that they can't decide if it's a "version" or "revision". I suppose I should report these issues to the developers of Trac.


From ryandesign at macports.org  Wed Nov 25 15:03:16 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 25 Nov 2009 17:03:16 -0600
Subject: [60853] trunk/dports/multimedia
In-Reply-To: <20091125172851.9F30A350B980@beta.macosforge.org>
References: <20091125172851.9F30A350B980@beta.macosforge.org>
Message-ID: <58D8974E-67B3-4697-B8A2-FFC731EDF64E@macports.org>


On Nov 25, 2009, at 11:28, jameskyle at macports.org wrote:

> Revision: 60853
>          http://trac.macports.org/changeset/60853
> Author:   jameskyle at macports.org
> Date:     2009-11-25 09:28:47 -0800 (Wed, 25 Nov 2009)
> Log Message:
> -----------
> Development version of the mp4v2 library. Trunk accurately reports the artworkCount, a known issue with the stable release.
> 
> Added Paths:
> -----------
>    trunk/dports/multimedia/mp4v2-dev/
>    trunk/dports/multimedia/mp4v2-dev/Portfile
> 
> Added: trunk/dports/multimedia/mp4v2-dev/Portfile
> ===================================================================
> --- trunk/dports/multimedia/mp4v2-dev/Portfile	                        (rev 0)
> +++ trunk/dports/multimedia/mp4v2-dev/Portfile	2009-11-25 17:28:47 UTC (rev 60853)
> @@ -0,0 +1,34 @@
> +# -*- 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                mp4v2-dev

[snip]

The correct name for this port would be "mp4v2-devel". This is not documented in the guide yet, but is described here:

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




From jmr at macports.org  Wed Nov 25 21:39:59 2009
From: jmr at macports.org (Joshua Root)
Date: Thu, 26 Nov 2009 16:39:59 +1100
Subject: [MacPorts] #22219: opencore-amr port
In-Reply-To: <16b031c0911250700j5994f50bibf5d40008e92f23@mail.gmail.com>
References: <050.d0a52223df806e22613da3a5af0fac30@macports.org>	<059.3afbfe458ff16a9ee5054062acfa5108@macports.org>
	<16b031c0911250700j5994f50bibf5d40008e92f23@mail.gmail.com>
Message-ID: <4B0E14AF.1080509@macports.org>

That is a copyright license, not a patent license. It even says as much
in the source:
<http://opencore-amr.git.sourceforge.net/git/gitweb.cgi?p=opencore-amr/opencore-amr;a=blob_plain;f=opencore/codecs_v2/audio/gsm_amr/patent_disclaimer.txt;hb=HEAD>

- Josh

On 2009-11-26 02:00, Lee Azzarello wrote:
> The code has an Apache 2.0 license. Does that work with your distribution terms?
> 
> -lee
> 
> On Wed, Nov 25, 2009 at 3:39 AM, MacPorts <noreply at macports.org> wrote:
>> #22219: opencore-amr port
>> ----------------------------+-----------------------------------------------
>>  Reporter:  lee@?           |       Owner:  macports-tickets@?
>>     Type:  submission      |      Status:  new
>>  Priority:  Normal          |   Milestone:
>> Component:  ports           |     Version:
>>  Keywords:                  |        Port:  opencore-amr
>> ----------------------------+-----------------------------------------------
>> Changes (by jmr@?):
>>
>>  * cc: lee@? (removed)
>>  * keywords:  audio =>
>>  * version:  1.8.1 =>
>>  * port:  audio/opencore-amr => opencore-amr
>>
>>
>> Comment:
>>
>>  Can we actually distribute this given that AMR is patent-encumbered?
>>
>> --
>> Ticket URL: <http://trac.macports.org/ticket/22219#comment:2>
>> MacPorts <http://www.macports.org/>
>> Ports system for Mac OS

From ryandesign at macports.org  Thu Nov 26 01:22:37 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 26 Nov 2009 03:22:37 -0600
Subject: [MacPorts] #22219: opencore-amr port
In-Reply-To: <4B0E14AF.1080509@macports.org>
References: <050.d0a52223df806e22613da3a5af0fac30@macports.org>	<059.3afbfe458ff16a9ee5054062acfa5108@macports.org>
	<16b031c0911250700j5994f50bibf5d40008e92f23@mail.gmail.com>
	<4B0E14AF.1080509@macports.org>
Message-ID: <10F0B495-3002-4ADD-92CA-BC7DFEE1908E@macports.org>

On Nov 25, 2009, at 23:39, Joshua Root wrote:

> On 2009-11-26 02:00, Lee Azzarello wrote:
> 
>> On Wed, Nov 25, 2009 at 3:39 AM, Joshua Root wrote:
>> 
>>> Can we actually distribute this given that AMR is patent-encumbered?
>> 
>> The code has an Apache 2.0 license. Does that work with your distribution terms?
> 
> That is a copyright license, not a patent license. It even says as much
> in the source:
> <http://opencore-amr.git.sourceforge.net/git/gitweb.cgi?p=opencore-amr/opencore-amr;a=blob_plain;f=opencore/codecs_v2/audio/gsm_amr/patent_disclaimer.txt;hb=HEAD>

Well, if the source code is published, and can be compiled, then from a technical perspective it can be turned into a port. As to the patent license requirement, we have some precedent for that. For example, the +bytecode variant of the freetype port. This enables the patented TrueType bytecode interpreter. When installing with this variant, the port advises the user of the situation and directs them to http://www.freetype.org/patents.html for more information. An opencore-amr port could do similarly, assuming that is acceptable to the developers.




From mdcrawford at gmail.com  Thu Nov 26 03:50:28 2009
From: mdcrawford at gmail.com (Michael Crawford)
Date: Thu, 26 Nov 2009 03:50:28 -0800
Subject: Supporting Tiger Forever?
Message-ID: <dc9f86e80911260350h4e43ffeck9a960cb101745146@mail.gmail.com>

Hey Folks,

It occured to me recently that there could be a lot of benefit to both
MacPorts and to the Mac user community, if you were to commit to
supporting Mac OS X Tiger for a long time, if not forever.

The reason is that Leopard and all later releases won't run on PowerPC
G3s and the slower-clocked G4s.  The minimum config for Leopard is a
fast G4 or Intel.

Not everyone will have the money to buy a new box just to run a newer
OS X.  What will happen to them in the long run is that they will find
not just system software, but application software increasingly hard
to find.

I fully understand how much extra effort is required to support old
system builds.  Even if you can keep the software running, you may
lack the resources to test it adequately.

But if you can manage to do so somehow, then as support for these
slower Mac dwindles, you may find increasing numbers of enthusiastic
MacPorts users.  Maybe some of them can take up some of the load of
keeping Tiger support enabled.

I realize it's going to be a long time before this will really be an
issue, but thought it would be worth discussing.

Ever Faithful,

Mike
-- 
Michael David Crawford
mdcrawford at gmail dot com

   GoingWare's Bag of Programming Tricks
      http://www.goingware.com/tips/

From jmr at macports.org  Thu Nov 26 04:03:06 2009
From: jmr at macports.org (Joshua Root)
Date: Thu, 26 Nov 2009 23:03:06 +1100
Subject: Supporting Tiger Forever?
In-Reply-To: <dc9f86e80911260350h4e43ffeck9a960cb101745146@mail.gmail.com>
References: <dc9f86e80911260350h4e43ffeck9a960cb101745146@mail.gmail.com>
Message-ID: <4B0E6E7A.4070308@macports.org>

On 2009-11-26 22:50, Michael Crawford wrote:
> Hey Folks,
> 
> It occured to me recently that there could be a lot of benefit to both
> MacPorts and to the Mac user community, if you were to commit to
> supporting Mac OS X Tiger for a long time, if not forever.

Anyone is free to submit patches to keep base and/or ports working on
any OS release they like. The policy of primarily targeting the two most
recent OS releases is unlikely to change, but that's really just a
suggestion; the actual level of support for any given OS is entirely up
to the maintainers.

- Josh

From jkh at apple.com  Thu Nov 26 18:51:15 2009
From: jkh at apple.com (Jordan K. Hubbard)
Date: Thu, 26 Nov 2009 18:51:15 -0800
Subject: Supporting Tiger Forever?
In-Reply-To: <dc9f86e80911260350h4e43ffeck9a960cb101745146@mail.gmail.com>
References: <dc9f86e80911260350h4e43ffeck9a960cb101745146@mail.gmail.com>
Message-ID: <E7CB2EED-250A-4780-9A6C-A485009F2518@apple.com>


On Nov 26, 2009, at 3:50 AM, Michael Crawford wrote:

> It occured to me recently that there could be a lot of benefit to both
> MacPorts and to the Mac user community, if you were to commit to
> supporting Mac OS X Tiger for a long time, if not forever.
> 
> The reason is that Leopard and all later releases won't run on PowerPC
> G3s and the slower-clocked G4s.  The minimum config for Leopard is a
> fast G4 or Intel.

I'm sure those folks exist, but it's also worth pointing out that they represent a vanishingly small fraction of the overall installed base now, so I'm not sure how much bang for buck the MacPorts community would really get in supporting them "forever."  Sure, if you're one of those people then it's pretty darned important from your perspective but, as the years go by, you'll probably notice that your Mac/G3 user group meetings are getting smaller and smaller and the Newton User Group is showing increasing interest in merging with you. :-)

- Jordan


From talklists at newgeo.com  Thu Nov 26 21:12:06 2009
From: talklists at newgeo.com (Scott Haneda)
Date: Thu, 26 Nov 2009 21:12:06 -0800
Subject: Supporting Tiger Forever?
In-Reply-To: <E7CB2EED-250A-4780-9A6C-A485009F2518@apple.com>
References: <dc9f86e80911260350h4e43ffeck9a960cb101745146@mail.gmail.com>
	<E7CB2EED-250A-4780-9A6C-A485009F2518@apple.com>
Message-ID: <3B7BC50F-7126-4A4C-974F-5C0285654DE7@newgeo.com>

On Nov 26, 2009, at 6:51 PM, Jordan K. Hubbard wrote:

> On Nov 26, 2009, at 3:50 AM, Michael Crawford wrote:
>
>> It occured to me recently that there could be a lot of benefit to  
>> both
>> MacPorts and to the Mac user community, if you were to commit to
>> supporting Mac OS X Tiger for a long time, if not forever.
>>
>> The reason is that Leopard and all later releases won't run on  
>> PowerPC
>> G3s and the slower-clocked G4s.  The minimum config for Leopard is a
>> fast G4 or Intel.
>
> I'm sure those folks exist, but it's also worth pointing out that  
> they represent a vanishingly small fraction of the overall installed  
> base now, so I'm not sure how much bang for buck the MacPorts  
> community would really get in supporting them "forever."  Sure, if  
> you're one of those people then it's pretty darned important from  
> your perspective but, as the years go by, you'll probably notice  
> that your Mac/G3 user group meetings are getting smaller and smaller  
> and the Newton User Group is showing increasing interest in merging  
> with you. :-)

I have to agree with you on this point here strongly.  The only thing  
I can add, is that as time goes on, these computers keep getting less  
and less expensive.  The Mac Mini at 599.00 probably will not get that  
much less in cost, but used versions will, which will all support  
something current.

There is nothing that is going to make any of your current software  
that runs on your current hardware today break.  If it works now,  
today, it will work 10 years from now.  You may not be able to update,  
but it will continue to work.  I think date based bugs would be about  
the only marginal area in which this could prove wrong.
-- 
Scott * If you contact me off list replace talklists@ with scott@ *


From talklists at newgeo.com  Thu Nov 26 21:37:33 2009
From: talklists at newgeo.com (Scott Haneda)
Date: Thu, 26 Nov 2009 21:37:33 -0800
Subject: Suggestion on auto ticket filing
Message-ID: <BC352B39-1F66-4485-ABAB-30C9544F1680@newgeo.com>

In a past message on MP-users, subject of: Re: "Electric" failed to  
compile, Ryan suggested the use of:

	sudo port -d install electric 2>&1 | tee ~/Desktop/electric.txt

Then asked:
> Then file a new ticket in the issue tracker and attach electric.txt  
> from your desktop.

I have been wondering this for a while, and this is a good intro for  
me to ask...

As a result of any error in MacPorts, a message is written to the  
terminal of what the error was.  What if the last line was:

You may want to try the troubleshooting steps located at: http://trac.macports.org/wiki/FAQ#buildfails

Though I would like to point to a new wiki page, where it was much  
more orderly, a set of steps to try.  I see a lot of requests that are  
answered with "did you clean and try again", "yeah, I did, that  
worked, thanks".

Maybe that entire dialog could go away, with the pointing of a url at  
the very end of the error message.  Then, within the new wiki page, I  
would add the "If all else fails...".

	sudo port -d install portname 2>&1 | tee | mp-reporter

* Not sure I have that correct.

The idea is, that the output is passed to a small shell script, mp- 
reporter, which would automatically create the report in the ticketing  
system.  We would need one account for which this happened under.

I would like to make the mp-reporter script interactive, so if  
desired, they could login to trac right there, and the ticket would be  
made under their account.  Or they can decline, and it will be made  
under the general mp-reporter account.

I believe this is something within my abilities to create.  I think it  
can be done with curl and some pretty simple bash scripting.  Filing  
the ticket with the output as an attachment, over putting it into the  
ticket itself is up for discussion, and would be the only aspect of  
curl I am not familiar with off the bat.

Comments?
-- 
Scott * If you contact me off list replace talklists@ with scott@ *


From jeremy at lavergne.gotdns.org  Thu Nov 26 21:46:03 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Fri, 27 Nov 2009 00:46:03 -0500
Subject: Suggestion on auto ticket filing
In-Reply-To: <BC352B39-1F66-4485-ABAB-30C9544F1680@newgeo.com>
References: <BC352B39-1F66-4485-ABAB-30C9544F1680@newgeo.com>
Message-ID: <DCD6D8E3-FFAA-4E29-9581-C004491AD225@lavergne.gotdns.org>

The gsoc logging project assists us in that the log is already available---no more need to rerun with debug mode.

It also provides the path to the log file (copy/paste into Finder).

As for the port field and ticket owner, we can likely have a script auto-assign (and CC) the ticket based on the port field, and we could require the port to be set for ports-based tickets (the default, type I believe).

These requirements should cause people to read the instructions since the tickets won't submit without making sure they've added the port, but it will also remove the need for them to mark the owner.

While we're at it, we might consider logic to test that the reporter/owner isn't a CC.

On Nov 27, 2009, at 12:37 AM, Scott Haneda wrote:

> In a past message on MP-users, subject of: Re: "Electric" failed to compile, Ryan suggested the use of:
> 
> 	sudo port -d install electric 2>&1 | tee ~/Desktop/electric.txt
> 
> Then asked:
>> Then file a new ticket in the issue tracker and attach electric.txt from your desktop.
> 
> I have been wondering this for a while, and this is a good intro for me to ask...
> 
> As a result of any error in MacPorts, a message is written to the terminal of what the error was.  What if the last line was:
> 
> You may want to try the troubleshooting steps located at: http://trac.macports.org/wiki/FAQ#buildfails
> 
> Though I would like to point to a new wiki page, where it was much more orderly, a set of steps to try.  I see a lot of requests that are answered with "did you clean and try again", "yeah, I did, that worked, thanks".
> 
> Maybe that entire dialog could go away, with the pointing of a url at the very end of the error message.  Then, within the new wiki page, I would add the "If all else fails...".
> 
> 	sudo port -d install portname 2>&1 | tee | mp-reporter
> 
> * Not sure I have that correct.
> 
> The idea is, that the output is passed to a small shell script, mp-reporter, which would automatically create the report in the ticketing system.  We would need one account for which this happened under.
> 
> I would like to make the mp-reporter script interactive, so if desired, they could login to trac right there, and the ticket would be made under their account.  Or they can decline, and it will be made under the general mp-reporter account.
> 
> I believe this is something within my abilities to create.  I think it can be done with curl and some pretty simple bash scripting.  Filing the ticket with the output as an attachment, over putting it into the ticket itself is up for discussion, and would be the only aspect of curl I am not familiar with off the bat.
> 
> Comments?
> -- 
> Scott * If you contact me off list replace talklists@ with scott@ *
> 
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
> 

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

From ryandesign at macports.org  Sun Nov 29 06:33:26 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 29 Nov 2009 08:33:26 -0600
Subject: Can't access configure.env in portfile
Message-ID: <947340C9-EDDB-4279-9CCE-8FF09D761EE1@macports.org>

I feel like what I'm doing should work, but it doesn't. I want to access the variable ${configure.env}. But whenever I do, I only get values I've added to it with configure.env-append; I don't get the tons of values MacPorts adds automatically, which are the ones I'm actually interested in. Using the attached test portfile, I get:


--->  Configuring test
DEBUG: Using compiler 'Mac OS X gcc 4.2'
DEBUG: Executing proc-pre-org.macports.configure-configure-0
DEBUG: configure.env: FOO=bar
DEBUG: Executing org.macports.configure (test)
DEBUG: Environment: CFLAGS='-O2 -arch x86_64' CPPFLAGS='-I/opt/local/include' CXXFLAGS='-O2 -arch x86_64' MACOSX_DEPLOYMENT_TARGET='10.6' CXX='/usr/bin/g++-4.2' F90FLAGS='-O2 -m64' LDFLAGS='-L/opt/local/lib' FCFLAGS='-O2 -m64' OBJC='/usr/bin/gcc-4.2' INSTALL='/usr/bin/install -c' OBJCFLAGS='-O2 -arch x86_64' FFLAGS='-O2 -m64' FOO='bar' CC='/usr/bin/gcc-4.2'
DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/_private_tmp/work/test-1.0" && true --prefix=/opt/local'
DEBUG: Executing proc-post-org.macports.configure-configure-0
DEBUG: configure.env: FOO=bar


See, both before and after the configure phase, configure.env only contains the "FOO=bar" variable I added. But what I actually want to know about are the CFLAGS, CPPFLAGS, CXXFLAGS, etc. that MacPorts sets automatically. Yes, I know we have separate variables ${configure.cflags}, ${configure.cppflags}, ${configure.cxxflags}, etc. for most (all?) of those, but I'd rather not have to enumerate over them myself since to my mind MacPorts should have already done so for me somewhere.


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