From blb at macports.org  Sat May  2 00:06:56 2009
From: blb at macports.org (Bryan Blackburn)
Date: Sat, 2 May 2009 01:06:56 -0600
Subject: [50487] trunk/dports/x11/xorg-cf-files/Portfile
In-Reply-To: <20090501171246.1A4CF16DA8BA@beta.macosforge.org>
References: <20090501171246.1A4CF16DA8BA@beta.macosforge.org>
Message-ID: <20090502070656.GH67675@ninagal.withay.com>

On Fri, May 01, 2009 at 10:12:45AM -0700, mcalhoun at macports.org said:
> Revision: 50487
>           http://trac.macports.org/changeset/50487
> Author:   mcalhoun at macports.org
> Date:     2009-05-01 10:12:45 -0700 (Fri, 01 May 2009)
> Log Message:
> -----------
> xorg-cf-files: By default, X11 is installed into prefix.

Since this changes the installed site.def should this have a revision
increase as well?

Bryan


> 
> Modified Paths:
> --------------
>     trunk/dports/x11/xorg-cf-files/Portfile
> 
> Modified: trunk/dports/x11/xorg-cf-files/Portfile
> ===================================================================
> --- trunk/dports/x11/xorg-cf-files/Portfile	2009-05-01 16:58:22 UTC (rev 50486)
> +++ trunk/dports/x11/xorg-cf-files/Portfile	2009-05-01 17:12:45 UTC (rev 50487)
> @@ -7,7 +7,7 @@
>  version      1.0.2
>  categories   x11 devel
>  platforms    darwin
> -maintainers  mcalhoun
> +maintainers  mcalhoun openmaintainer
>  
>  description       Build files for discontinued imake build system.
>  long_description  ${description}
> @@ -28,9 +28,6 @@
>      rmd160 dc42aa06d7fb5bc073d51958763bf1bfcfd22926
>  
>  post-configure {
> -    #ensure that X11 libraries and includes are found
> -    reinplace s|${prefix}|${x11prefix}|g ${worksrcpath}/site.def
> -
>      #ensure that configuration files are found
>      reinplace "s|#define ConfigDir \$(LIBDIR)/config|#define ConfigDir ${prefix}/lib/X11/config|g" ${worksrcpath}/X11.tmpl
>  

From mcalhoun at macports.org  Sat May  2 00:13:46 2009
From: mcalhoun at macports.org (Marcus Calhoun-Lopez)
Date: Sat, 2 May 2009 07:13:46 +0000 (UTC)
Subject: [50487] trunk/dports/x11/xorg-cf-files/Portfile
References: <20090501171246.1A4CF16DA8BA@beta.macosforge.org>
	<20090502070656.GH67675@ninagal.withay.com>
Message-ID: <loom.20090502T071206-455@post.gmane.org>

Bryan Blackburn <blb at ...> writes:
> Since this changes the installed site.def should this have a revision
> increase as well?
> 
> Bryan
> 

Thanks for catching this.
Fixed in http://trac.macports.org/changeset/50517/trunk/dports/x11/xorg-cf-files/Portfile.





From jeremyhu at macports.org  Sat May  2 13:24:51 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Sat, 2 May 2009 13:24:51 -0700
Subject: [PATCH 01/01] RFC: Nuke x11prefix 
Message-ID: <298B84D1-D9C4-4800-B6F1-E18B31DF2F95@macports.org>

I just updated all the xorg-lib* ports to nuke the system_x11  
variant.  I did not revbump them.  If users activated +system_x11,  
they'll need to rebuild all their x11 ports and everything that  
depends on them manually.  We could go through and revbump all the x11  
and dependent ports, but that would push a rebuild on the majority of  
users that didn't enable system_x11 that don't need the rebuild.

Comments on this revision bumping are appreciated, since I'm not  
entirely certain what the best solution is.

Attached is a patch that removes $x11prefix from dports/*

Please comment.

Thanks,
Jeremy


-------------- next part --------------
A non-text attachment was scrubbed...
Name: nuke_x11prefix.patch
Type: application/octet-stream
Size: 92073 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090502/95fce3dd/attachment-0001.obj>
-------------- next part --------------


From raimue at macports.org  Sun May  3 07:26:31 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sun, 03 May 2009 16:26:31 +0200
Subject: [PATCH 01/01] RFC: Nuke x11prefix
In-Reply-To: <298B84D1-D9C4-4800-B6F1-E18B31DF2F95@macports.org>
References: <298B84D1-D9C4-4800-B6F1-E18B31DF2F95@macports.org>
Message-ID: <49FDA997.9090902@macports.org>

On 2009-05-02 22:24, Jeremy Huddleston wrote:
> I just updated all the xorg-lib* ports to nuke the system_x11  
> variant.  I did not revbump them.  If users activated +system_x11,  
> they'll need to rebuild all their x11 ports and everything that  
> depends on them manually.  We could go through and revbump all the x11  
> and dependent ports, but that would push a rebuild on the majority of  
> users that didn't enable system_x11 that don't need the rebuild.
> 
> Comments on this revision bumping are appreciated, since I'm not  
> entirely certain what the best solution is.

I don't think many users are actually using the +system_x11 variant as
we never recommend to use it. And those who use it are also reading the
macports-dev list - at least I hope so ;-)

> Attached is a patch that removes $x11prefix from dports/*

I looked through the patch and it looks good to me. No objections.

I noticed that many ports now need
  configure.args --x-include=${prefix}/include --x-lib=${prefix}/lib
Maybe we could add some macro to add these in a simpler fashion?

Thanks for your work on the X11 part, Jeremy!

Rainer

From jmr at macports.org  Sun May  3 10:15:35 2009
From: jmr at macports.org (Joshua Root)
Date: Mon, 04 May 2009 03:15:35 +1000
Subject: [PATCH 01/01] RFC: Nuke x11prefix
In-Reply-To: <49FDA997.9090902@macports.org>
References: <298B84D1-D9C4-4800-B6F1-E18B31DF2F95@macports.org>
	<49FDA997.9090902@macports.org>
Message-ID: <49FDD137.4050409@macports.org>

Rainer M?ller wrote:
> On 2009-05-02 22:24, Jeremy Huddleston wrote:
>> Attached is a patch that removes $x11prefix from dports/*
> 
> I looked through the patch and it looks good to me. No objections.

+1

I notice that a few unrelated changes seem to have crept in, but nothing
that looks problematic.

- Josh

From vince at macports.org  Mon May  4 08:35:22 2009
From: vince at macports.org (vincent habchi)
Date: Mon, 4 May 2009 17:35:22 +0200
Subject: [MacPorts] #19397: scipy not completely universal
References: <4C9F526D-6C20-4BB8-9BAD-8EA13710AC75@macports.org>
Message-ID: <4F42E439-8425-45B2-B8C4-399833407E13@macports.org>

Le 23 avr. 09 ? 09:37, MacPorts a ?crit :

> #19397: scipy not completely universal
> ------------------------------------------- 
> +--------------------------------
> Reporter:  daweonline@?                   |       Owner:  jmr@?
>    Type:  defect                         |      Status:  new
> Priority:  Normal                         |   Milestone:  Port Bugs
> Component:  ports                          |     Version:  1.7.1
> Keywords:  scipy python universal binary  |        Port:  py26-scipy
> ------------------------------------------- 
> +--------------------------------
>
> Comment(by daweonline@?):
>
> I've done modifying this line
>
> 265             for arch in ["i686", "x86_64"]:
>
> in
>
> /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
> python2.6
> /site-packages/numpy/distutils/fcompiler/gnu.py
>
> and installing without macports... It should be said this way used
> gfortran-4.2 downloaded here
>
> [http://www.maths.otago.ac.nz/~fonnesbeck/gfortran-4.2.3.dmg]

This version of gfortran is also available here : http://r.research.att.com/tools/

But the way it handles the command line is buggy. For example :

-> /usr/local/bin/gfortran -arch i386
i686-apple-darwin8-gfortran-4.2: no input files
-> /usr/local/bin/gfortran -arch i386 -arch x86_64
->

Strange, no? If two archs flags are present, there is no stderr output.

Here is a way to build a universal scipy with this compiler located  
in /usr/local/bin:

1. Add this file in the ${portpath} file directory, it wraps /usr/ 
local/bin/gfortran-4.2, fixes the bug above and another one in the  
building process (automatic addition of -arch i686 and -arch ppc;  
why ???):

-> more files/gf.in
#!/bin/sh

NOF=yes
IGNORE=no
ARGS=

for i in $@ ; do
  if [ $IGNORE == 'yes' ]; then
    IGNORE=no
  else
    if [ $i == '-arch' ]; then
      IGNORE=yes
    else
      ARGS=`echo $ARGS " " $i`
      if [ $i == '-o' ]; then
        NOF=no
      fi
    fi
  fi
done

if [ $NOF == 'yes' ]; then
  /usr/local/bin/gfortran-4.2 $@
else
  /usr/local/bin/gfortran-4.2 XXX $ARGS
fi

2. Add this variant to Portfile

variant gf42univ conflicts gcc42 gcc43 gcc44 description "Use  
gfortan-4.2 from http://r.research.att.com/tools to build universal  
binaries" {

  if {! [file exists /usr/local/bin/gfortran-4.2]} then {
     puts "> Please install gfortran universal from http://// 
r.research.att.com//tools//"
     exit 1
  }

  set fc_options "build_clib --fcompiler=gnu95 build_ext -- 
fcompiler=gnu95 config_fc --fcompiler=gnu95 \
		  --f77exec ${portpath}/files/gf --f90exec ${portpath}/files/gf"

  set uarch ""
  foreach arch ${universal_archs} {
  	append uarch "-arch " ${arch} " "
  }

  delete ${portpath}/files/gf
  copy ${portpath}/files/gf.in ${portpath}/files/gf
  reinplace "s|XXX|${uarch}|" ${portpath}/files/gf

  build.cmd-append      ${fc_options}
  destroot.cmd-append   ${fc_options}
}

Vincent


From simon at ruderich.org  Mon May  4 08:51:41 2009
From: simon at ruderich.org (Simon Ruderich)
Date: Mon, 4 May 2009 17:51:41 +0200
Subject: [50564] homebank Lint Report
In-Reply-To: <20090504141537.5326828085@relay14.apple.com>
References: <20090504141537.5326828085@relay14.apple.com>
Message-ID: <20090504155141.GA26626@ruderich.org>

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

On Mon, May 04, 2009 at 07:15:37AM -0700, noreply at macports.org wrote:
> Portfile: homebank
>
> Warning: Can't open index file: /rsync/macports-san/release/ports/PortIndex

Hi,

Just got this lint report. Looks like a problem with the server.
Not sure if this is only temporary or not.

Simon
- -- 
+ privacy is necessary
+ using http://gnupg.org
+ public key id: 0x6115F804EFB33229
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkn/Dw0ACgkQYRX4BO+zMinxrACgzfz+EtyKPtIoH5RNMQJW/tnL
OHUAn0yalpn/FfZRAWRRIj7sCyO8inzN
=dqWs
-----END PGP SIGNATURE-----

From wsiegrist at apple.com  Mon May  4 09:36:52 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Mon, 04 May 2009 09:36:52 -0700
Subject: [50564] homebank Lint Report
In-Reply-To: <20090504155141.GA26626@ruderich.org>
References: <20090504141537.5326828085@relay14.apple.com>
	<20090504155141.GA26626@ruderich.org>
Message-ID: <E3742A57-E5FB-433B-920C-ED002B7B76AF@apple.com>

On May 4, 2009, at 8:51 AM, Simon Ruderich wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mon, May 04, 2009 at 07:15:37AM -0700, noreply at macports.org wrote:
>> Portfile: homebank
>>
>> Warning: Can't open index file: /rsync/macports-san/release/ports/ 
>> PortIndex
>
> Hi,
>
> Just got this lint report. Looks like a problem with the server.
> Not sure if this is only temporary or not.
>


Its a known issue due to a "race condition" amongst the various server- 
side jobs. It should be rare, so if it happens to you every time, or  
often, let me know. I'm still trying to track it down, but its hard to  
reproduce manually so far.

Thanks
-Bill

From simon at ruderich.org  Mon May  4 09:51:43 2009
From: simon at ruderich.org (Simon Ruderich)
Date: Mon, 4 May 2009 18:51:43 +0200
Subject: [50564] homebank Lint Report
In-Reply-To: <E3742A57-E5FB-433B-920C-ED002B7B76AF@apple.com>
References: <20090504141537.5326828085@relay14.apple.com>
	<20090504155141.GA26626@ruderich.org>
	<E3742A57-E5FB-433B-920C-ED002B7B76AF@apple.com>
Message-ID: <20090504165143.GA5127@ruderich.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, May 04, 2009 at 09:36:52AM -0700, William Siegrist wrote:
> On May 4, 2009, at 8:51 AM, Simon Ruderich wrote:
>
> Its a known issue due to a "race condition" amongst the various server
> side jobs. It should be rare, so if it happens to you every time, or
> often, let me know. I'm still trying to track it down, but its hard to
> reproduce manually so far.
>
> Thanks
> -Bill

Thanks for your quick reply. If it happens often I will tell you.

Simon
- -- 
+ privacy is necessary
+ using http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJJ/x0fAAoJEJL+/bfkTDL5vSEP/Rmjw3gPOCRl12ext++O1byj
8VhCkfsII4XabOfaqo79Ephhcu+5PLbu+nHCRyP6Gj4zzjmzL0INUE7esYxEMB0c
MnDlOM5BnemcH9SzVBLjyACkNKSrdKfYxZqxxZjMHJznh7bSIOpRG/hZpfTOPqz5
bReJRY/wxv/G8gzKdthX5dXBvYpJ/6ckvVhVhduKZMm7rr/RBpMJ6v6eCZIo/LEu
08gvxo4WJcELBpdHDSTvI9IHyUBadVdpCF1IdeLiIvQEQ36T4OdOMfGY9F6nct/R
NFFXEftMIQz/Yg4B5hXko0LRqmkdI5mPM7gWlHP7koFxI71UsL9Xf71XISmahSwl
niNhjT2LJAtNWRnEbEIk6a79a22yCusDKgPhQD3y+VPy/4QSvJul5M/mtGF82g5+
mP4sx/0Q+xy3cJQskqvRdspfujjJnA3lAd985A7lphKnTU7WwRs2sVsBBJUDMadq
astq95iBxv4vePI2aOfZQ9tvUdTgc9GQAQb9q48kCO8DeJ0hPWlPWj9H0SL48ahn
tWH8sVA4T8PeK27JYS/chZbGZ9zCSpRFnx3AxZ9rJmorSvrz84ZubyeKhXQFrwZ+
n+m2wJ542F6ek/d+maOt3dvcHrvH1u2olPDzA93Az/KPiZgsbR5DCEywJeeiQQV6
p4tGAJnQqKbXg/X80lEv
=nvk6
-----END PGP SIGNATURE-----

From jeremyhu at macports.org  Mon May  4 13:13:25 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Mon, 4 May 2009 13:13:25 -0700
Subject: No more x11prefix
Message-ID: <1BE0741C-1DC6-4822-A05B-C54FA4BD278E@macports.org>

I just pushed the patch I submitted two days ago and a follwup patch  
to base that removes its search for a system X11 SDK at build time and  
all references to x11prefix.

At this point, no ports in MP should be referencing /usr/X11 in any  
way.  If you discover a port that is linking against /usr/X11/lib/...,  
please let me or the maintainer of the port know.  The most likely  
cause is that it's an autoconf package that is using AC_PATH_X to find  
X11 (poke upstream to use pkg-config first, then fall back on  
AC_PATH_X).

Older versions of AC_PATH_X didn't know about the .dylib extension for  
libraries.  Furthermore, AC_PATH_X defaults to "asking" xmkmf  
(port:imake) for the location of X11 headers and libraries if it's  
available.  Now that $x11prefix/bin is not in base's build $PATH  
(granted it will take a while to reach users), this is less of a  
problem (although port:imake needs to be updated since it seems to be  
reporting /usr/X11 too...)

The easiest solution to this right now is to just add the following to  
configure.args for ports that misbehave:
--x-include=${prefix}/include --x-lib=${prefix}/lib

Most ports that use AC_PATH_X will probably build and link correctly  
even if they find /usr/X11 because $prefix should be before it on the  
command line.

--Jeremy


From devans at macports.org  Mon May  4 15:16:54 2009
From: devans at macports.org (David Evans)
Date: Mon, 04 May 2009 15:16:54 -0700
Subject: [50581] trunk/dports/graphics/fontconfig/Portfile
In-Reply-To: <20090504203119.B93EE17179DB@beta.macosforge.org>
References: <20090504203119.B93EE17179DB@beta.macosforge.org>
Message-ID: <49FF6956.9090906@macports.org>

blb at macports.org wrote:
>
> Revision
>     50581 <http://trac.macports.org/changeset/50581>
> Author
>     blb at macports.org
> Date
>     2009-05-04 13:31:19 -0700 (Mon, 04 May 2009)
>
>
>       Log Message
>
> graphics/fontconfig - hardcode X11 prefix since x11prefix variable was removed in r50573
>
>
>       Modified Paths
>
>     * trunk/dports/graphics/fontconfig/Portfile
>       <#trunkdportsgraphicsfontconfigPortfile>
>
>
>       Diff
>
>
>         Modified: trunk/dports/graphics/fontconfig/Portfile (50580 =>
>         50581)
>
>
> --- trunk/dports/graphics/fontconfig/Portfile	2009-05-04 20:20:05 UTC (rev 50580)
> +++ trunk/dports/graphics/fontconfig/Portfile	2009-05-04 20:31:19 UTC (rev 50581)
> @@ -31,7 +31,7 @@
>      port:expat \
>      port:freetype
>  
> -set add_fonts           ${x11prefix}/lib/X11/fonts
> +set add_fonts           /usr/X11R6/lib/X11/fonts
>  set docdir              ${prefix}/share/doc/${name}-${version}
>  
>  configure.args \
Shouldn't this now be ${prefix}/share/fonts  ?



From blb at macports.org  Mon May  4 16:14:30 2009
From: blb at macports.org (Bryan Blackburn)
Date: Mon, 4 May 2009 17:14:30 -0600
Subject: [50581] trunk/dports/graphics/fontconfig/Portfile
In-Reply-To: <49FF6956.9090906@macports.org>
References: <20090504203119.B93EE17179DB@beta.macosforge.org>
	<49FF6956.9090906@macports.org>
Message-ID: <20090504231430.GF855@ninagal.withay.com>

On Mon, May 04, 2009 at 03:16:54PM -0700, David Evans said:
> blb at macports.org wrote:
[...]
>> --- trunk/dports/graphics/fontconfig/Portfile	2009-05-04 20:20:05 UTC (rev 50580)
>> +++ trunk/dports/graphics/fontconfig/Portfile	2009-05-04 20:31:19 UTC (rev 50581)
>> @@ -31,7 +31,7 @@
>>      port:expat \
>>      port:freetype
>>  -set add_fonts           ${x11prefix}/lib/X11/fonts
>> +set add_fonts           /usr/X11R6/lib/X11/fonts
>>  set docdir              ${prefix}/share/doc/${name}-${version}
>>   configure.args \
> Shouldn't this now be ${prefix}/share/fonts  ?

I was just dealing with the immediate issue of x11prefix going away;
however, note that ${prefix}/share/fonts is added to that list later,
though it is done in a macosx platform section [1]; probably should be added
on that 'set add_fonts' line with X11...

Bryan

[1] - <http://trac.macports.org/browser/trunk/dports/graphics/fontconfig/Portfile#L81>


From raimue at macports.org  Mon May  4 16:40:26 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Tue, 05 May 2009 01:40:26 +0200
Subject: [MacPorts] Tickets modified
In-Reply-To: <20090504233519.41A2928082@relay14.apple.com>
References: <20090504233519.41A2928082@relay14.apple.com>
Message-ID: <49FF7CEA.6070507@macports.org>

On 2009-05-05 01:35, MacPorts wrote:
> Changed page "Tickets" by raimue at macports.org from 91.11.184.2*
> Page URL: <http://trac.macports.org/wiki/Tickets>
> Diff URL: <http://trac.macports.org/wiki/Tickets?action=diff&version=4>
> Revision 4
> 
> -------8<------8<------8<------8<------8<------8<------8<------8<--------
> Index: Tickets
> =========================================================================
> --- Tickets (version: 3)
> +++ Tickets (version: 4)

[...]

> +== Keywords ==
> +
> + [query:keywords~=lack-of-interest lack-of-interest]::
> +    Tickets with keyword ''lack-of-interest'' set and older than 3 days can probably be closed as nobody seems to be interested anymore.
> + [query:keywords~=needs-commit needs-commit]::
> +    Tickets which need a committer to take care of. Should be set by maintainers without commit access to approve port updates/patches. This makes it easier to identify uncommitted port patches.

Awww...

My idea was to propose to make more use of keywords in our bug tracker
to fight the never-ending amount of open tickets [1]. But now I realize
that maintainers without commit access would also not be able to set
such keywords...

Rainer

[1] http://student.physik.uni-mainz.de/~reiffert/macports/

From wsiegrist at apple.com  Mon May  4 16:48:44 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Mon, 04 May 2009 16:48:44 -0700
Subject: Commit Linting
Message-ID: <5CC40FF2-A5E6-4FCD-A48F-9540C71062AD@apple.com>

The post-commit linting has been changed to use MacPorts v1.7.1 with  
the portlint.tcl script from trunk. This appears to work for me, but  
please let me know if you get any strange lint messages.  This change  
should fix the errors about svn.revision for ports using svn fetching.

Thanks
-Bill


From david.osguthorpe at gmail.com  Tue May  5 06:44:24 2009
From: david.osguthorpe at gmail.com (David Osguthorpe)
Date: Tue, 5 May 2009 07:44:24 -0600
Subject: Issues where macports python fails but ssystem python works
In-Reply-To: <1BE0741C-1DC6-4822-A05B-C54FA4BD278E@macports.org>
References: <1BE0741C-1DC6-4822-A05B-C54FA4BD278E@macports.org>
Message-ID: <20090505134424.GA2429@mactelhm.local>


From david.osguthorpe at gmail.com  Tue May  5 07:01:01 2009
From: david.osguthorpe at gmail.com (David Osguthorpe)
Date: Tue, 5 May 2009 08:01:01 -0600
Subject: Issues where macports python fails but system python works
In-Reply-To: <1BE0741C-1DC6-4822-A05B-C54FA4BD278E@macports.org>
References: <1BE0741C-1DC6-4822-A05B-C54FA4BD278E@macports.org>
Message-ID: <20090505140101.GC2429@mactelhm.local>


Hi,

I know the macports developers dont like using Apple supplied stuff
but here is an inverse case - where the system supplied python works
but macports python doesnt.

running macports python with a python script that has worked for a year or so
(from Panther to Leopard) gives the following errors:

>Traceback (most recent call last):
>  File "ofx.py", line 179, in <module>
>    client.doQuery(query, argv[1]+"_"+argv[3]+"_"+dtnow+".ofx")
>  File "ofx.py", line 144, in doQuery
>    f = urllib2.urlopen(request)
>  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 124, in urlopen
>    return _opener.open(url, data)
>  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 381, in open
>    response = self._open(req, data)
>  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 404, in _open
>    'unknown_open', req)
>  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 360, in _call_chain
>    result = func(*args)
>  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 1140, in unknown_open
>    raise URLError('unknown url type: %s' % type)
>urllib2.URLError: <urlopen error unknown url type: https>


its nice that urllib2.py thinks https is an unknown url type

running with the system python everything works

the macports python probably got installed because Im using  py-gtk2 which seems
to be working in another project - and why this script used to work under Leopard before
installing the py-gtk2 port

differencing the system urllib2.py and macports shows some differences - but not a reason why getting
the above error

diff /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py
58c58,61
< authinfo.add_password('realm', 'host', 'username', 'password')
---
> authinfo.add_password(realm='PDQ Application',
>                       uri='https://mahler:8092/site-updates.py',
>                       user='klem',
>                       passwd='geheim$parole')
297a301,304
>         if not hasattr(handler, "add_parent"):
>             raise TypeError("expected BaseHandler instance, got %r" %
>                             type(handler))
> 
948c955
<             pass
---
>             raise URLError("qop '%s' is not supported." % qop)


if you are going to re-install all these system provided utilities it would be good
if they worked

probably some base python dependency isnt being included to make this work - Im wondering if its
something to do with ssl and some specific extra python module needed for that to work
- but I dont really want to be hunting this down - particularly if it works with the system python

David

From jmr at macports.org  Tue May  5 07:55:46 2009
From: jmr at macports.org (Joshua Root)
Date: Wed, 06 May 2009 00:55:46 +1000
Subject: Issues where macports python fails but system python works
In-Reply-To: <20090505140101.GC2429@mactelhm.local>
References: <1BE0741C-1DC6-4822-A05B-C54FA4BD278E@macports.org>
	<20090505140101.GC2429@mactelhm.local>
Message-ID: <4A005372.1090907@macports.org>

David Osguthorpe wrote:
> Hi,
> 
> I know the macports developers dont like using Apple supplied stuff
> but here is an inverse case - where the system supplied python works
> but macports python doesnt.
> 
> running macports python with a python script that has worked for a year or so
> (from Panther to Leopard) gives the following errors:
> 
>> Traceback (most recent call last):
>>  File "ofx.py", line 179, in <module>
>>    client.doQuery(query, argv[1]+"_"+argv[3]+"_"+dtnow+".ofx")
>>  File "ofx.py", line 144, in doQuery
>>    f = urllib2.urlopen(request)
>>  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 124, in urlopen
>>    return _opener.open(url, data)
>>  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 381, in open
>>    response = self._open(req, data)
>>  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 404, in _open
>>    'unknown_open', req)
>>  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 360, in _call_chain
>>    result = func(*args)
>>  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 1140, in unknown_open
>>    raise URLError('unknown url type: %s' % type)
>> urllib2.URLError: <urlopen error unknown url type: https>

<http://trac.macports.org/wiki/FAQ#WhycantIimportfooinPython2.5>

You probably need to install py25-socket-ssl. Note that we went with the
"batteries included" option in python26, and people regularly complain
about that too:

<http://trac.macports.org/wiki/FAQ#pydeps>

If you're seeing an error like the above when running something
installed by a port, it's missing a dependency, and you should file a
ticket.

- Josh

From jannis at leidel.info  Tue May  5 08:16:18 2009
From: jannis at leidel.info (Jannis Leidel)
Date: Tue, 5 May 2009 17:16:18 +0200
Subject: Issues where macports python fails but system python works
In-Reply-To: <4A005372.1090907@macports.org>
References: <1BE0741C-1DC6-4822-A05B-C54FA4BD278E@macports.org>
	<20090505140101.GC2429@mactelhm.local>
	<4A005372.1090907@macports.org>
Message-ID: <F95A7D44-4054-44D2-8639-1E02F34328BD@leidel.info>


Am 05.05.2009 um 16:55 schrieb Joshua Root:

> <http://trac.macports.org/wiki/FAQ#WhycantIimportfooinPython2.5>
>
> You probably need to install py25-socket-ssl. Note that we went with  
> the
> "batteries included" option in python26, and people regularly complain
> about that too:
>
> <http://trac.macports.org/wiki/FAQ#pydeps>
>
> If you're seeing an error like the above when running something
> installed by a port, it's missing a dependency, and you should file a
> ticket.

I'm kinda confused about that since I thought this is actually a bug  
in the Python 2.5 port. Ticket 12369 has a fix and been tested (http://lists.macosforge.org/pipermail/macports-dev/2009-April/008235.html 
  et al).

Jannis

From david.osguthorpe at gmail.com  Tue May  5 11:39:49 2009
From: david.osguthorpe at gmail.com (David Osguthorpe)
Date: Tue, 5 May 2009 12:39:49 -0600
Subject: Issues where macports python fails but system python works
In-Reply-To: <4A005372.1090907@macports.org>
References: <1BE0741C-1DC6-4822-A05B-C54FA4BD278E@macports.org>
	<20090505140101.GC2429@mactelhm.local>
	<4A005372.1090907@macports.org>
Message-ID: <20090505183949.GA3064@mactelhm.local>

On Tue, May 05, 2009 at 08:55:46AM -0600, Joshua Root wrote:
> >>    result = func(*args)
> >>  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 1140, in unknown_open
> >>    raise URLError('unknown url type: %s' % type)
> >> urllib2.URLError: <urlopen error unknown url type: https>
> 
> <http://trac.macports.org/wiki/FAQ#WhycantIimportfooinPython2.5>
> 
> You probably need to install py25-socket-ssl. Note that we went with the
> "batteries included" option in python26, and people regularly complain
> about that too:
> 
> <http://trac.macports.org/wiki/FAQ#pydeps>
> 
> If you're seeing an error like the above when running something
> installed by a port, it's missing a dependency, and you should file a
> ticket.
> 

but in this case its not - its some python script I downloaded and have
modified some time ago and has been working perfectly OK so far - and still is

you can put me down for by default when replacing the system python macports
should "replace" the system python  (so I dont care about 2.4 or 2.6 pythons because thats
not the system python on Leopard - 2.5 is - a macports user has to specifically request 2.6)

I dont care whether its python-lite python-full - what it should be is python-apple
ie. the same dependencies as Apples python - so I dont get surprises like this

note there is no way I know which python module to install at this point - urllib2.py
seems to be part of the main python install (which is what the script imports)
so has no dependencies defined for it
- I was just beginning to guess that the reason https doesnt exist is probably because
of something wrong in the ssl layer somewhere
- nowhere is there a message about failing to import foo so that FAQ doesnt help

but you are right - you need to install py25-socket-ssl to get the _ssl.so module which
is what seems to be missing (diffing /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload
shows the following modules missing in macports
_curses.o, _curses_panel.so, _hashlib.so, _sha256.so, _sha512.so, _sqlite2.so, _ssl.so _tkinter.so
bz2.so readline.so zlib.so)

David

From david.osguthorpe at gmail.com  Tue May  5 11:40:38 2009
From: david.osguthorpe at gmail.com (David Osguthorpe)
Date: Tue, 5 May 2009 12:40:38 -0600
Subject: correct fixup for main python install
In-Reply-To: <4A005372.1090907@macports.org>
References: <1BE0741C-1DC6-4822-A05B-C54FA4BD278E@macports.org>
	<20090505140101.GC2429@mactelhm.local>
	<4A005372.1090907@macports.org>
Message-ID: <20090505184038.GB3064@mactelhm.local>

On Tue, May 05, 2009 at 08:55:46AM -0600, Joshua Root wrote:
> David Osguthorpe wrote:
> > Hi,
> > 
> > I know the macports developers dont like using Apple supplied stuff
> > but here is an inverse case - where the system supplied python works
> > but macports python doesnt.
> > 
> > running macports python with a python script that has worked for a year or so
> > (from Panther to Leopard) gives the following errors:
> > 
> >> Traceback (most recent call last):
> >>  File "ofx.py", line 179, in <module>
> >>    client.doQuery(query, argv[1]+"_"+argv[3]+"_"+dtnow+".ofx")
> >>  File "ofx.py", line 144, in doQuery
> >>    f = urllib2.urlopen(request)
> >>  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 124, in urlopen
> >>    return _opener.open(url, data)
> >>  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 381, in open
> >>    response = self._open(req, data)
> >>  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 404, in _open
> >>    'unknown_open', req)
> >>  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 360, in _call_chain
> >>    result = func(*args)
> >>  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 1140, in unknown_open
> >>    raise URLError('unknown url type: %s' % type)
> >> urllib2.URLError: <urlopen error unknown url type: https>
> 
> <http://trac.macports.org/wiki/FAQ#WhycantIimportfooinPython2.5>
> 
> You probably need to install py25-socket-ssl. Note that we went with the
> "batteries included" option in python26, and people regularly complain
> about that too:
> 
> <http://trac.macports.org/wiki/FAQ#pydeps>
> 
> If you're seeing an error like the above when running something
> installed by a port, it's missing a dependency, and you should file a
> ticket.
> 
> - Josh
> 

From jeremyhu at macports.org  Tue May  5 12:04:00 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Tue, 5 May 2009 12:04:00 -0700
Subject: kazehakase build failuers ... gtk deprecated code
Message-ID: <15E08A26-2601-4F6D-8A95-A9B805B8CA18@macports.org>

So kazehakase explicitly disables support for GTK deprecated code, but  
then it goes ahead and uses something that's been deprecated for at  
least 7 years!  What's going on here?

  /usr/bin/gcc-4.0 -DHAVE_CONFIG_H -I. -I../.. -D_REENTRANT -I/opt/ 
local/include/gtk-2.0 -I/opt/local/lib/gtk-2.0/include -I/opt/local/ 
include/atk-1.0 -I/opt/local/include/cairo -I/opt/local/include/ 
pango-1.0 -I/opt/local/include -I/opt/local/include/glib-2.0 -I/opt/ 
local/lib/glib-2.0/include -I/opt/local/include/pixman-1 -I/opt/local/ 
include/freetype2 -I/opt/local/include/libpng12 -I../../src/dialogs - 
I../../src/utils -I../../src/net -I../../src/bookmarks -I../../src/ 
widget -I../../src/libegg/dropdowntoolbutton -I../../src/libegg/ 
pixbufthumbnail -I../../src -DGTK_DISABLE_DEPRECATED=1 - 
DGDK_DISABLE_DEPRECATED=1 -DG_LOG_DOMAIN=\"Kazehakase-Actions\" - 
DG_DISABLE_DEPRECATED=1 -I/opt/local/include -O2 -Wall -Wmissing- 
declarations -Wmissing-prototypes -Wpointer-arith -Wcast-align -MT kz- 
actions-tab.lo -MD -MP -MF .deps/kz-actions-tab.Tpo -c kz-actions- 
tab.c  -fno-common -DPIC -o .libs/kz-actions-tab.o
kz-actions-dynamic.c: In function  
'cb_copy_in_user_format_menuitem_activate':
kz-actions-dynamic.c:168: warning: implicit declaration of function  
'GTK_CHECK_CAST'
kz-actions-dynamic.c:168: error: syntax error before 'KzStatusbar'
kz-actions-dynamic.c:168: error: too few arguments to function  
'kz_statusbar_set_copied_text'
kz-actions-dynamic.c:168: warning: left-hand operand of comma  
expression has no effect
kz-actions-dynamic.c:168: error: syntax error before ')' token

From david.osguthorpe at gmail.com  Tue May  5 12:12:50 2009
From: david.osguthorpe at gmail.com (David Osguthorpe)
Date: Tue, 5 May 2009 13:12:50 -0600
Subject: Correct fixup for main python ports
In-Reply-To: <4A005372.1090907@macports.org>
References: <1BE0741C-1DC6-4822-A05B-C54FA4BD278E@macports.org>
	<20090505140101.GC2429@mactelhm.local>
	<4A005372.1090907@macports.org>
Message-ID: <20090505191250.GC3064@mactelhm.local>


Hi,

OK - so here is the real deal for solving what extra modules to install with the base python
port

_ssl.so most definitely should be installed

why??

because in the particular case of _ssl.so there is no "failed to import" message - as that
is protected in socket.py by try/except  - the object my script imported was urllib2.py
which then does import both socket and hashlib (hashlib appears to have been installed from
other python stuff installed as part of py-gtk2)

so you get the extremely obscure error message:   the url type https does not exist

looking at it there appears to be no consistency between which scripts in 
Frameworks/Python.framework/Versions/2.5/lib/python2.5
use unprotected imports of these modules and ones which you do not get an error message for eg. pdb.py
does protect the readline import with try/except - and gives no error message if it does
not exist 

so

macports should install by default any module which is imported from .py scripts in Frameworks/Python.framework/Versions/2.5/lib/python2.5 
(which is identical between /System/Library from apple and /opt/local/Library from macports)

_tkinter, _sqlite3, _curses, _curse_panel,  are not imported by any .py file in that directory

_hashlib, _sha256, _sh512, _sqlite3, _ssl, bz2, readline, zlib are imported by .py files in that directory

as the .py files in Frameworks/Python.framework/Versions/2.5/lib/python2.5 are from the main python
install there are no dependencies defined for them so you can never tell what you need to install

David

From afb at macports.org  Wed May  6 00:19:58 2009
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Wed, 6 May 2009 09:19:58 +0200
Subject: kazehakase build failuers ... gtk deprecated code
In-Reply-To: <15E08A26-2601-4F6D-8A95-A9B805B8CA18@macports.org>
References: <15E08A26-2601-4F6D-8A95-A9B805B8CA18@macports.org>
Message-ID: <85099619-5C15-4455-A997-3C618FCB1EE0@macports.org>

Jeremy Huddleston wrote:

> So kazehakase explicitly disables support for GTK deprecated code,  
> but then it goes ahead and uses something that's been deprecated  
> for at least 7 years!  What's going on here?

No idea, but should be fairly safe to drop the port if it can't be  
patched (or fixed)... Back then all X11 browsers were broken, so were  
trying a few different ones out. Nowadays both Firefox and Midori  
should work.

--anders


From alakazam at macports.org  Wed May  6 09:21:45 2009
From: alakazam at macports.org (Olivier Le Floch)
Date: Wed, 6 May 2009 18:21:45 +0200
Subject: [50191] trunk/dports/php/php5-eaccelerator/Portfile
In-Reply-To: <E72587F1-CBC6-4809-8FB6-C409E0D84B81@macports.org>
References: <20090427142930.3FA901686C27@beta.macosforge.org>
	<83A7CCC4-4268-4F3E-8537-FA2E53291EE6@macports.org>
	<E72587F1-CBC6-4809-8FB6-C409E0D84B81@macports.org>
Message-ID: <E21C7C91-8B79-420E-AB04-997EF66621BB@macports.org>

On 1 mai 09, at 00:26, Ryan Schmidt wrote:

> On Apr 30, 2009, at 01:28, Ryan Schmidt wrote:
>
>> On Apr 27, 2009, at 09:29, alakazam at macports.org wrote:
>>
>>> Revision: 50191
>>>          http://trac.macports.org/changeset/50191
>>> Author:   alakazam at macports.org
>>> Date:     2009-04-27 07:29:29 -0700 (Mon, 27 Apr 2009)
>>> Log Message:
>>> -----------
>>> Migrate php5-eaccelerator to the php5extension PortGroup
>>
>> Did you try whether the port still works? I haven't tried it yet  
>> but I didn't think this would work because eAccelerator is not a  
>> normal PHP extension but a Zend extension and therefore needs to be  
>> loaded with the zend_extension directive and not the extension  
>> directive. I was going to add an option to the php5extension  
>> portgroup to allow you to specify what type of extension it is so  
>> that the correct directive can be written to the .ini file.

I had tried it and it worked (if I'm not mistaken), but had forgotten  
about this distinction.

> Ok, it looks like eAccelerator is unique in that it can be used as  
> either a Zend extension or as a regular extension, which is why it  
> still works with the portgroup:

Lucky me :p

> http://eaccelerator.net/wiki/InstallFromSource#Step3.ConfiguringeAccelerator
>
> But I can't tell which method is preferred or why.

I think using it as a regular PHP extension is better for stability  
reasons :

> http://bugs.php.net/bug.php?id=42002#c128772

But I really can't find anything more regarding this issue...

From raimue at macports.org  Wed May  6 22:51:10 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Thu, 07 May 2009 07:51:10 +0200
Subject: [50694] branches/images-and-archives/base/src
In-Reply-To: <20090507054121.5BD25175749E@beta.macosforge.org>
References: <20090507054121.5BD25175749E@beta.macosforge.org>
Message-ID: <4A0276CE.1030107@macports.org>

On 2009-05-07 07:41, blb at macports.org wrote:
> Revision: 50694
>           http://trac.macports.org/changeset/50694
> Author:   blb at macports.org
> Date:     2009-05-06 22:41:19 -0700 (Wed, 06 May 2009)
> Log Message:
> -----------
> Remove source/binary only options

I think the -b and -s options were quite useful to select if archives
should be used or the software should be built from source. How do you
think this will work in the future?

Rainer

From blb at macports.org  Wed May  6 23:05:00 2009
From: blb at macports.org (Bryan Blackburn)
Date: Thu, 7 May 2009 00:05:00 -0600
Subject: [50694] branches/images-and-archives/base/src
In-Reply-To: <4A0276CE.1030107@macports.org>
References: <20090507054121.5BD25175749E@beta.macosforge.org>
	<4A0276CE.1030107@macports.org>
Message-ID: <20090507060500.GM79127@ninagal.withay.com>

On Thu, May 07, 2009 at 07:51:10AM +0200, Rainer M?ller said:
> On 2009-05-07 07:41, blb at macports.org wrote:
> > Revision: 50694
> >           http://trac.macports.org/changeset/50694
> > Author:   blb at macports.org
> > Date:     2009-05-06 22:41:19 -0700 (Wed, 06 May 2009)
> > Log Message:
> > -----------
> > Remove source/binary only options
> 
> I think the -b and -s options were quite useful to select if archives
> should be used or the software should be built from source. How do you
> think this will work in the future?

The way this branch will work is that the distinction between archives and
what's installed will be gone.  In the case of -b, that option won't make
sense anymore since "installed" is having the image file (archive as called
now) available, so you just have to activate the right one.  For -s, it's
like now if you disable archive mode, just uninstall the port to build from
source.

Bryan


> 
> Rainer

From ryandesign at macports.org  Thu May  7 01:56:30 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 7 May 2009 03:56:30 -0500
Subject: [50191] trunk/dports/php/php5-eaccelerator/Portfile
In-Reply-To: <E21C7C91-8B79-420E-AB04-997EF66621BB@macports.org>
References: <20090427142930.3FA901686C27@beta.macosforge.org>
	<83A7CCC4-4268-4F3E-8537-FA2E53291EE6@macports.org>
	<E72587F1-CBC6-4809-8FB6-C409E0D84B81@macports.org>
	<E21C7C91-8B79-420E-AB04-997EF66621BB@macports.org>
Message-ID: <45C39297-42EB-4B41-A714-4E6383163570@macports.org>


On May 6, 2009, at 11:21, Olivier Le Floch wrote:

> On 1 mai 09, at 00:26, Ryan Schmidt wrote:
>
>> On Apr 30, 2009, at 01:28, Ryan Schmidt wrote:
>>
>>> On Apr 27, 2009, at 09:29, alakazam at macports.org wrote:
>>>
>>>> Revision: 50191
>>>>          http://trac.macports.org/changeset/50191
>>>> Author:   alakazam at macports.org
>>>> Date:     2009-04-27 07:29:29 -0700 (Mon, 27 Apr 2009)
>>>> Log Message:
>>>> -----------
>>>> Migrate php5-eaccelerator to the php5extension PortGroup
>>>
>>> Did you try whether the port still works? I haven't tried it yet  
>>> but I didn't think this would work because eAccelerator is not a  
>>> normal PHP extension but a Zend extension and therefore needs to  
>>> be loaded with the zend_extension directive and not the extension  
>>> directive. I was going to add an option to the php5extension  
>>> portgroup to allow you to specify what type of extension it is so  
>>> that the correct directive can be written to the .ini file.
>
> I had tried it and it worked (if I'm not mistaken), but had  
> forgotten about this distinction.
>
>> Ok, it looks like eAccelerator is unique in that it can be used as  
>> either a Zend extension or as a regular extension, which is why it  
>> still works with the portgroup:
>
> Lucky me :p
>
>> http://eaccelerator.net/wiki/ 
>> InstallFromSource#Step3.ConfiguringeAccelerator
>>
>> But I can't tell which method is preferred or why.
>
> I think using it as a regular PHP extension is better for stability  
> reasons :
>
>> http://bugs.php.net/bug.php?id=42002#c128772
>
> But I really can't find anything more regarding this issue...

That ticket doesn't seem to have reached a meaningful conclusion...  
"No feedback"...

My research suggests that a zend extension would perform faster, but  
that some zend extensions cannot be used with other zend extensions,  
so it would be more compatible to load eAccelerator as a php  
extension to avoid that issue.

Maybe on ports that can be loaded either as a zend extension or as a  
php extension, we should be providing variants to allow the user to  
choose? with php extension being the default? Though I'm inclined to  
do nothing, and just leave it as a php extension, until someone  
complains.

The php5extension portgroup now allows you to specify that an  
extension should be loaded as a zend extension. The only port  
currently using this is php5-xdebug (it cannot be loaded as a php  
extension).



From alakazam at macports.org  Thu May  7 02:02:23 2009
From: alakazam at macports.org (Olivier Le Floch)
Date: Thu, 7 May 2009 11:02:23 +0200
Subject: [50191] trunk/dports/php/php5-eaccelerator/Portfile
In-Reply-To: <45C39297-42EB-4B41-A714-4E6383163570@macports.org>
References: <20090427142930.3FA901686C27@beta.macosforge.org>
	<83A7CCC4-4268-4F3E-8537-FA2E53291EE6@macports.org>
	<E72587F1-CBC6-4809-8FB6-C409E0D84B81@macports.org>
	<E21C7C91-8B79-420E-AB04-997EF66621BB@macports.org>
	<45C39297-42EB-4B41-A714-4E6383163570@macports.org>
Message-ID: <AAEFB963-94A1-4AB5-88B9-68E29F11E452@macports.org>

>> I think using it as a regular PHP extension is better for stability  
>> reasons :
>>
>>> http://bugs.php.net/bug.php?id=42002#c128772
>>
>> But I really can't find anything more regarding this issue...
>
> That ticket doesn't seem to have reached a meaningful conclusion...  
> "No feedback"...

I was actually just (more specifically) referring to derick at php.net's  
comment :
> Do not file bugs when you have Zend extensions (zend_extension=)  
> loaded. Examples are Zend Optimizer, Zend Debugger, Turck MM Cache,  
> APC, Xdebug and ionCube loader. These extensions often modify engine  
> behavior which is not related to PHP itself.
> My research suggests that a zend extension would perform faster, but  
> that some zend extensions cannot be used with other zend extensions,  
> so it would be more compatible to load eAccelerator as a php  
> extension to avoid that issue.
>
> Maybe on ports that can be loaded either as a zend extension or as a  
> php extension, we should be providing variants to allow the user to  
> choose? with php extension being the default? Though I'm inclined to  
> do nothing, and just leave it as a php extension, until someone  
> complains.

That's also my take on this issue ; I'm not sure many people will  
encounter performance problems with eaccelerator that would be best  
adressed by switching it to a zend extension.


From ryandesign at macports.org  Thu May  7 03:25:36 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 7 May 2009 05:25:36 -0500
Subject: [50694] branches/images-and-archives/base/src
In-Reply-To: <20090507060500.GM79127@ninagal.withay.com>
References: <20090507054121.5BD25175749E@beta.macosforge.org>
	<4A0276CE.1030107@macports.org>
	<20090507060500.GM79127@ninagal.withay.com>
Message-ID: <38635B7C-5D10-4578-BD87-F3C2169DAF88@macports.org>

On May 7, 2009, at 01:05, Bryan Blackburn wrote:

> On Thu, May 07, 2009 at 07:51:10AM +0200, Rainer M?ller said:
>> On 2009-05-07 07:41, blb at macports.org wrote:
>>> Revision: 50694
>>>           http://trac.macports.org/changeset/50694
>>> Author:   blb at macports.org
>>> Date:     2009-05-06 22:41:19 -0700 (Wed, 06 May 2009)
>>> Log Message:
>>> -----------
>>> Remove source/binary only options
>>
>> I think the -b and -s options were quite useful to select if archives
>> should be used or the software should be built from source. How do  
>> you
>> think this will work in the future?
>
> The way this branch will work is that the distinction between  
> archives and
> what's installed will be gone.  In the case of -b, that option  
> won't make
> sense anymore since "installed" is having the image file (archive  
> as called
> now) available, so you just have to activate the right one.  For - 
> s, it's
> like now if you disable archive mode, just uninstall the port to  
> build from
> source.

Is there an explanation somewhere about this branch, what goals  
you're trying to accomplish, etc.? Is there a ticket or a wiki page?




From ryandesign at macports.org  Thu May  7 03:28:00 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 7 May 2009 05:28:00 -0500
Subject: [MacPorts] Tickets modified
In-Reply-To: <49FF7CEA.6070507@macports.org>
References: <20090504233519.41A2928082@relay14.apple.com>
	<49FF7CEA.6070507@macports.org>
Message-ID: <448BD57A-709D-4923-8C62-18FEA5C3E75D@macports.org>

On May 4, 2009, at 18:40, Rainer M?ller wrote:

> My idea was to propose to make more use of keywords in our bug tracker
> to fight the never-ending amount of open tickets [1]. But now I  
> realize
> that maintainers without commit access would also not be able to set
> such keywords...

Are you saying regular users cannot modify tickets' keywords? Maybe  
we should let them do this? I'm pretty sure regular users can already  
add any keywords they want at ticket creation time, so why not let  
them modify keywords later?



From ryandesign at macports.org  Thu May  7 03:30:27 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 7 May 2009 05:30:27 -0500
Subject: [50674] trunk/dports/audio/ardour2
In-Reply-To: <20090506193650.2670C174E901@beta.macosforge.org>
References: <20090506193650.2670C174E901@beta.macosforge.org>
Message-ID: <96FA03BE-1084-4514-89B9-6BD0542D25AF@macports.org>

On May 6, 2009, at 14:36, devans at macports.org wrote:

> Revision: 50674
>           http://trac.macports.org/changeset/50674
> Author:   devans at macports.org
> Date:     2009-05-06 12:36:49 -0700 (Wed, 06 May 2009)
> Log Message:
> -----------
> ardour2:
>
>   * patch to build with latest scons versions
>   * simplify dependencies
>   * disable broken LV2 plugin support by default
>   * add +lv2 variant to enable LV2 for testing
>
> Modified Paths:
> --------------
>     trunk/dports/audio/ardour2/Portfile
>
> Added Paths:
> -----------
>     trunk/dports/audio/ardour2/files/
>     trunk/dports/audio/ardour2/files/patch-SConstruct.diff

Your patch hardcodes the location /opt/local. You must change this to  
support whatever prefix MacPorts is currently running in, which could  
be different.



> Modified: trunk/dports/audio/ardour2/Portfile
> ===================================================================
> --- trunk/dports/audio/ardour2/Portfile	2009-05-06 19:31:11 UTC  
> (rev 50673)
> +++ trunk/dports/audio/ardour2/Portfile	2009-05-06 19:36:49 UTC  
> (rev 50674)
> @@ -5,6 +5,7 @@
>
>  name                    ardour2
>  version                 2.5
> +revision                1
>  distname                ardour-${version}
>  maintainers             devans
>  categories              audio x11
> @@ -34,27 +35,18 @@
>
>  depends_build           port:gettext \
>                          port:pkgconfig \
> -                        port:libtool \
>                          port:python25 \
>                          port:scons
>
> -depends_lib             port:jack \
> -                        port:libxslt \
> -                        port:libxml2 \
> -                        port:libart_lgpl \
> -                        port:libsamplerate \
> -                        port:raptor \
> -                        port:liblrdf \
> -                        port:glib2 \
> -                        port:gtk2 \
> +depends_lib             port:liblrdf \
>                          port:libgnomecanvas \
>                          port:liblo \
>                          port:boost \
> -                        port:fftw-3 \
>                          port:fftw-3-single \
> -                        port:aubio \
> -                        port:slv2
> +                        port:aubio
>
> +patchfiles              patch-SConstruct.diff
> +
>  post-patch {
>      reinplace "s%/opt/local%${prefix}%g" ${worksrcpath}/SConstruct
>  }
> @@ -63,8 +55,14 @@
>
>  build.cmd               scons
>  build.target
> -build.args              PREFIX=${prefix} VST=0 AUBIO=1 FREESOUND=1  
> LV2=1
> +build.args              PREFIX=${prefix} VST=0 AUBIO=1 FREESOUND=1  
> LV2=0
>
> +variant lv2 description {Add support for LV2 plugins (currently  
> broken)} {
> +        build.args-delete LV2=0
> +        build.args-append LV2=1
> +        depends_lib-append port:slv2
> +}
> +
>  livecheck.check         regex
>  livecheck.url           ${homepage}
>  livecheck.regex         "current release: ardour (\\d+(?:\\.\\d+)*)"
>
> Added: trunk/dports/audio/ardour2/files/patch-SConstruct.diff
> ===================================================================
> --- trunk/dports/audio/ardour2/files/patch- 
> SConstruct.diff	                        (rev 0)
> +++ trunk/dports/audio/ardour2/files/patch-SConstruct.diff	 
> 2009-05-06 19:36:49 UTC (rev 50674)
> @@ -0,0 +1,171 @@
> +--- SConstruct.orig	2008-07-07 08:29:40.000000000 -0700
> ++++ SConstruct	2009-04-20 14:23:06.000000000 -0700
> +@@ -508,27 +508,27 @@
> + #libraries['sndfile'].ParseConfig('pkg-config --cflags --libs  
> sndfile')
> +
> + libraries['lrdf'] = LibraryInfo()
> +-libraries['lrdf'].ParseConfig('pkg-config --cflags --libs lrdf')
> ++libraries['lrdf'].ParseConfig('/opt/local/bin/pkg-config --cflags  
> --libs lrdf')
> +
> + libraries['raptor'] = LibraryInfo()
> +-libraries['raptor'].ParseConfig('pkg-config --cflags --libs raptor')
> ++libraries['raptor'].ParseConfig('/opt/local/bin/pkg-config -- 
> cflags --libs raptor')
> +
> + libraries['samplerate'] = LibraryInfo()
> +-libraries['samplerate'].ParseConfig('pkg-config --cflags --libs  
> samplerate')
> ++libraries['samplerate'].ParseConfig('/opt/local/bin/pkg-config -- 
> cflags --libs samplerate')
> +
> + conf = env.Configure (custom_tests = { 'CheckPKGExists' :  
> CheckPKGExists } )
> +
> + if conf.CheckPKGExists ('fftw3f'):
> +     libraries['fftw3f'] = LibraryInfo()
> +-    libraries['fftw3f'].ParseConfig('pkg-config --cflags --libs  
> fftw3f')
> ++    libraries['fftw3f'].ParseConfig('/opt/local/bin/pkg-config -- 
> cflags --libs fftw3f')
> +
> + if conf.CheckPKGExists ('fftw3'):
> +     libraries['fftw3'] = LibraryInfo()
> +-    libraries['fftw3'].ParseConfig('pkg-config --cflags --libs  
> fftw3')
> ++    libraries['fftw3'].ParseConfig('/opt/local/bin/pkg-config -- 
> cflags --libs fftw3')
> +
> + if conf.CheckPKGExists ('aubio'):
> +     libraries['aubio'] = LibraryInfo()
> +-    libraries['aubio'].ParseConfig('pkg-config --cflags --libs  
> aubio')
> ++    libraries['aubio'].ParseConfig('/opt/local/bin/pkg-config -- 
> cflags --libs aubio')
> +
> + env = conf.Finish ()
> +
> +@@ -569,7 +569,7 @@
> + 		print ('Ardour cannot be compiled without the curl headers,  
> which do not seem to be installed')
> + 		sys.exit (1)
> + 	else:
> +-		libraries['curl'].ParseConfig('pkg-config --cflags --libs  
> libcurl')
> ++		libraries['curl'].ParseConfig('/opt/local/bin/pkg-config -- 
> cflags --libs libcurl')
> + 	conf.Finish()
> + else:
> + 	print 'FREESOUND support is not enabled.  Build with \'scons  
> FREESOUND=1\' to enable.'
> +@@ -579,7 +579,7 @@
> + 	
> + 	if conf.CheckPKGExists ('\"slv2 >= 0.6.0\"'):
> + 		libraries['slv2'] = LibraryInfo()
> +-		libraries['slv2'].ParseConfig('pkg-config --cflags --libs slv2')
> ++		libraries['slv2'].ParseConfig('/opt/local/bin/pkg-config -- 
> cflags --libs slv2')
> +                 env.Append (CCFLAGS="-DHAVE_LV2")
> + 	else:
> + 		print 'Building Ardour with LV2 support requires SLV2 >= 0.6.0'
> +@@ -592,31 +592,31 @@
> + 	print 'LV2 support is not enabled.  Build with \'scons LV2=1\'  
> to enable.'
> +
> + libraries['jack'] = LibraryInfo()
> +-libraries['jack'].ParseConfig('pkg-config --cflags --libs jack')
> ++libraries['jack'].ParseConfig('/opt/local/bin/pkg-config --cflags  
> --libs jack')
> +
> + libraries['xml'] = LibraryInfo()
> +-libraries['xml'].ParseConfig('pkg-config --cflags --libs  
> libxml-2.0')
> ++libraries['xml'].ParseConfig('/opt/local/bin/pkg-config --cflags  
> --libs libxml-2.0')
> +
> + libraries['xslt'] = LibraryInfo()
> +-libraries['xslt'].ParseConfig('pkg-config --cflags --libs libxslt')
> ++libraries['xslt'].ParseConfig('/opt/local/bin/pkg-config --cflags  
> --libs libxslt')
> +
> + libraries['glib2'] = LibraryInfo()
> +-libraries['glib2'].ParseConfig ('pkg-config --cflags --libs  
> glib-2.0')
> +-libraries['glib2'].ParseConfig ('pkg-config --cflags --libs  
> gobject-2.0')
> +-libraries['glib2'].ParseConfig ('pkg-config --cflags --libs  
> gmodule-2.0')
> +-libraries['glib2'].ParseConfig ('pkg-config --cflags --libs  
> gthread-2.0')
> ++libraries['glib2'].ParseConfig('/opt/local/bin/pkg-config -- 
> cflags --libs glib-2.0')
> ++libraries['glib2'].ParseConfig('/opt/local/bin/pkg-config -- 
> cflags --libs gobject-2.0')
> ++libraries['glib2'].ParseConfig('/opt/local/bin/pkg-config -- 
> cflags --libs gmodule-2.0')
> ++libraries['glib2'].ParseConfig('/opt/local/bin/pkg-config -- 
> cflags --libs gthread-2.0')
> +
> + libraries['freetype2'] = LibraryInfo()
> +-libraries['freetype2'].ParseConfig ('pkg-config --cflags --libs  
> freetype2')
> ++libraries['freetype2'].ParseConfig('/opt/local/bin/pkg-config -- 
> cflags --libs freetype2')
> +
> + libraries['gtk2'] = LibraryInfo()
> +-libraries['gtk2'].ParseConfig ('pkg-config --cflags --libs gtk 
> +-2.0')
> ++libraries['gtk2'].ParseConfig('/opt/local/bin/pkg-config --cflags  
> --libs gtk+-2.0')
> +
> + libraries['pango'] = LibraryInfo()
> +-libraries['pango'].ParseConfig ('pkg-config --cflags --libs pango')
> ++libraries['pango'].ParseConfig('/opt/local/bin/pkg-config -- 
> cflags --libs pango')
> +
> + libraries['libgnomecanvas2'] = LibraryInfo()
> +-libraries['libgnomecanvas2'].ParseConfig ('pkg-config --cflags -- 
> libs libgnomecanvas-2.0')
> ++libraries['libgnomecanvas2'].ParseConfig('/opt/local/bin/pkg- 
> config --cflags --libs libgnomecanvas-2.0')
> +
> + #libraries['flowcanvas'] = LibraryInfo(LIBS='flowcanvas',  
> LIBPATH='#/libs/flowcanvas', CPPPATH='#libs/flowcanvas')
> +
> +@@ -867,7 +867,7 @@
> +
> + conf = Configure (env)
> +
> +-if conf.CheckHeader ('fftw3.h'):
> ++if conf.CheckHeader ('/opt/local/include/fftw3.h'):
> +     env['RUBBERBAND'] = True
> +     libraries['rubberband'] = LibraryInfo (LIBS='rubberband',
> +                                            LIBPATH='#libs/ 
> rubberband',
> +@@ -910,7 +910,7 @@
> +
> + libraries['flac'] = LibraryInfo ()
> + prep_libcheck(env, libraries['flac'])
> +-libraries['flac'].Append(CPPPATH="/usr/local/include", LIBPATH="/ 
> usr/local/lib")
> ++libraries['flac'].Append(CPPPATH="/opt/local/include", LIBPATH="/ 
> opt/local/lib")
> +
> + #
> + # june 1st 2007: look for a function that is in FLAC 1.1.2 and  
> not in later versions
> +@@ -934,7 +934,7 @@
> +
> + libraries['boost'] = LibraryInfo ()
> + prep_libcheck(env, libraries['boost'])
> +-libraries['boost'].Append(CPPPATH="/usr/local/include", LIBPATH="/ 
> usr/local/lib")
> ++libraries['boost'].Append(CPPPATH="/opt/local/include", LIBPATH="/ 
> opt/local/lib")
> + conf = Configure (libraries['boost'])
> + if conf.CheckHeader ('boost/shared_ptr.hpp', language='CXX') ==  
> False:
> +         print "Boost header files do not appear to be installed.  
> You also might be running a buggy version of scons. Try scons 0.97  
> if you can."
> +@@ -948,6 +948,7 @@
> + if env['LIBLO']:
> +     libraries['lo'] = LibraryInfo ()
> +     prep_libcheck(env, libraries['lo'])
> ++    libraries['lo'].Append(CPPPATH="/opt/local/include",  
> LIBPATH="/opt/local/lib")
> +
> +     conf = Configure (libraries['lo'])
> +     if conf.CheckLib ('lo', 'lo_server_new') == False:
> +@@ -1044,21 +1045,21 @@
> +     env = conf.Finish()
> +
> +     libraries['sigc2'] = LibraryInfo()
> +-    libraries['sigc2'].ParseConfig('pkg-config --cflags --libs  
> sigc++-2.0')
> ++    libraries['sigc2'].ParseConfig('/opt/local/bin/pkg-config -- 
> cflags --libs sigc++-2.0')
> +     libraries['glibmm2'] = LibraryInfo()
> +-    libraries['glibmm2'].ParseConfig('pkg-config --cflags --libs  
> glibmm-2.4')
> ++    libraries['glibmm2'].ParseConfig('/opt/local/bin/pkg-config -- 
> cflags --libs glibmm-2.4')
> +     libraries['cairomm'] = LibraryInfo()
> +-    libraries['cairomm'].ParseConfig('pkg-config --cflags --libs  
> cairomm-1.0')
> ++    libraries['cairomm'].ParseConfig('/opt/local/bin/pkg-config -- 
> cflags --libs cairomm-1.0')
> +     libraries['gdkmm2'] = LibraryInfo()
> +-    libraries['gdkmm2'].ParseConfig ('pkg-config --cflags --libs  
> gdkmm-2.4')
> ++    libraries['gdkmm2'].ParseConfig('/opt/local/bin/pkg-config -- 
> cflags --libs gdkmm-2.4')
> +     libraries['gtkmm2'] = LibraryInfo()
> +-    libraries['gtkmm2'].ParseConfig ('pkg-config --cflags --libs  
> gtkmm-2.4')
> ++    libraries['gtkmm2'].ParseConfig('/opt/local/bin/pkg-config -- 
> cflags --libs gtkmm-2.4')
> +     libraries['atkmm'] = LibraryInfo()
> +-    libraries['atkmm'].ParseConfig ('pkg-config --cflags --libs  
> atkmm-1.6')
> ++    libraries['atkmm'].ParseConfig('/opt/local/bin/pkg-config -- 
> cflags --libs atkmm-1.6')
> +     libraries['pangomm'] = LibraryInfo()
> +-    libraries['pangomm'].ParseConfig ('pkg-config --cflags --libs  
> pangomm-1.4')
> ++    libraries['pangomm'].ParseConfig('/opt/local/bin/pkg-config -- 
> cflags --libs pangomm-1.4')
> +     libraries['libgnomecanvasmm'] = LibraryInfo()
> +-    libraries['libgnomecanvasmm'].ParseConfig ('pkg-config -- 
> cflags --libs libgnomecanvasmm-2.6')
> ++    libraries['libgnomecanvasmm'].ParseConfig('/opt/local/bin/pkg- 
> config --cflags --libs libgnomecanvasmm-2.6')
> +
> + #
> + # cannot use system one for the time being
> +@@ -1272,7 +1273,7 @@
> +     else:
> +         print "Found msgmerge"
> +
> +-    if not conf.CheckCHeader('libintl.h'):
> ++    if not conf.CheckCHeader('/opt/local/include/libintl.h'):
> +         nls_error += ' No libintl.h.'
> +         env['NLS'] = 0



From raimue at macports.org  Thu May  7 04:08:19 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 07 May 2009 13:08:19 +0200
Subject: [MacPorts] Tickets modified
In-Reply-To: <448BD57A-709D-4923-8C62-18FEA5C3E75D@macports.org>
References: <20090504233519.41A2928082@relay14.apple.com>
	<49FF7CEA.6070507@macports.org>
	<448BD57A-709D-4923-8C62-18FEA5C3E75D@macports.org>
Message-ID: <4A02C123.6060409@macports.org>

Ryan Schmidt wrote:
> On May 4, 2009, at 18:40, Rainer M?ller wrote:
> 
>> My idea was to propose to make more use of keywords in our bug tracker
>> to fight the never-ending amount of open tickets [1]. But now I realize
>> that maintainers without commit access would also not be able to set
>> such keywords...
> 
> Are you saying regular users cannot modify tickets' keywords? Maybe we
> should let them do this? I'm pretty sure regular users can already add
> any keywords they want at ticket creation time, so why not let them
> modify keywords later?

This would be the same reason they cannot assign tickets to others, edit
the CC field (why Bill has written the "CC Me!" plugin) or mark tickets
as closed.

As far as I know we only could give them access to all fields, not to
some specific values.

And yes, they can specify keywords at filing new tickets, but editing is
limited to committers.

Rainer

From devans at macports.org  Thu May  7 06:30:53 2009
From: devans at macports.org (David Evans)
Date: Thu, 07 May 2009 06:30:53 -0700
Subject: [50674] trunk/dports/audio/ardour2
In-Reply-To: <96FA03BE-1084-4514-89B9-6BD0542D25AF@macports.org>
References: <20090506193650.2670C174E901@beta.macosforge.org>
	<96FA03BE-1084-4514-89B9-6BD0542D25AF@macports.org>
Message-ID: <4A02E28D.9070902@macports.org>

Ryan Schmidt wrote:
> On May 6, 2009, at 14:36, devans at macports.org wrote:
>
>> Revision: 50674
>>           http://trac.macports.org/changeset/50674
>> Author:   devans at macports.org
>> Date:     2009-05-06 12:36:49 -0700 (Wed, 06 May 2009)
>> Log Message:
>> -----------
>> ardour2:
>>
>>   * patch to build with latest scons versions
>>   * simplify dependencies
>>   * disable broken LV2 plugin support by default
>>   * add +lv2 variant to enable LV2 for testing
>>
>> Modified Paths:
>> --------------
>>     trunk/dports/audio/ardour2/Portfile
>>
>> Added Paths:
>> -----------
>>     trunk/dports/audio/ardour2/files/
>>     trunk/dports/audio/ardour2/files/patch-SConstruct.diff
>
> Your patch hardcodes the location /opt/local. You must change this to 
> support whatever prefix MacPorts is currently running in, which could 
> be different.
>
>
>
>> Modified: trunk/dports/audio/ardour2/Portfile
>> ===================================================================
>> --- trunk/dports/audio/ardour2/Portfile    2009-05-06 19:31:11 UTC 
>> (rev 50673)
>> +++ trunk/dports/audio/ardour2/Portfile    2009-05-06 19:36:49 UTC 
>> (rev 50674)
>> @@ -5,6 +5,7 @@
>>
>>  name                    ardour2
>>  version                 2.5
>> +revision                1
>>  distname                ardour-${version}
>>  maintainers             devans
>>  categories              audio x11
>> @@ -34,27 +35,18 @@
>>
>>  depends_build           port:gettext \
>>                          port:pkgconfig \
>> -                        port:libtool \
>>                          port:python25 \
>>                          port:scons
>>
>> -depends_lib             port:jack \
>> -                        port:libxslt \
>> -                        port:libxml2 \
>> -                        port:libart_lgpl \
>> -                        port:libsamplerate \
>> -                        port:raptor \
>> -                        port:liblrdf \
>> -                        port:glib2 \
>> -                        port:gtk2 \
>> +depends_lib             port:liblrdf \
>>                          port:libgnomecanvas \
>>                          port:liblo \
>>                          port:boost \
>> -                        port:fftw-3 \
>>                          port:fftw-3-single \
>> -                        port:aubio \
>> -                        port:slv2
>> +                        port:aubio
>>
>> +patchfiles              patch-SConstruct.diff
>> +
>>  post-patch {
>>      reinplace "s%/opt/local%${prefix}%g" ${worksrcpath}/SConstruct
>>  }
>> @@ -63,8 +55,14 @@
>>
>>  build.cmd               scons
>>  build.target
>> -build.args              PREFIX=${prefix} VST=0 AUBIO=1 FREESOUND=1 
>> LV2=1
>> +build.args              PREFIX=${prefix} VST=0 AUBIO=1 FREESOUND=1 
>> LV2=0
>>
>> +variant lv2 description {Add support for LV2 plugins (currently 
>> broken)} {
>> +        build.args-delete LV2=0
>> +        build.args-append LV2=1
>> +        depends_lib-append port:slv2
>> +}
>> +
>>  livecheck.check         regex
>>  livecheck.url           ${homepage}
>>  livecheck.regex         "current release: ardour (\\d+(?:\\.\\d+)*)"
>>
>> Added: trunk/dports/audio/ardour2/files/patch-SConstruct.diff
>> ===================================================================
>> --- 
>> trunk/dports/audio/ardour2/files/patch-SConstruct.diff                            
>> (rev 0)
>> +++ trunk/dports/audio/ardour2/files/patch-SConstruct.diff    
>> 2009-05-06 19:36:49 UTC (rev 50674)
>> @@ -0,0 +1,171 @@
>> +--- SConstruct.orig    2008-07-07 08:29:40.000000000 -0700
>> ++++ SConstruct    2009-04-20 14:23:06.000000000 -0700
>> +@@ -508,27 +508,27 @@
>> + #libraries['sndfile'].ParseConfig('pkg-config --cflags --libs 
>> sndfile')
>> +
>> + libraries['lrdf'] = LibraryInfo()
>> +-libraries['lrdf'].ParseConfig('pkg-config --cflags --libs lrdf')
>> ++libraries['lrdf'].ParseConfig('/opt/local/bin/pkg-config --cflags 
>> --libs lrdf')
>> +
>> + libraries['raptor'] = LibraryInfo()
>> +-libraries['raptor'].ParseConfig('pkg-config --cflags --libs raptor')
>> ++libraries['raptor'].ParseConfig('/opt/local/bin/pkg-config --cflags 
>> --libs raptor')
>> +
>> + libraries['samplerate'] = LibraryInfo()
>> +-libraries['samplerate'].ParseConfig('pkg-config --cflags --libs 
>> samplerate')
>> ++libraries['samplerate'].ParseConfig('/opt/local/bin/pkg-config 
>> --cflags --libs samplerate')
>> +
>> + conf = env.Configure (custom_tests = { 'CheckPKGExists' : 
>> CheckPKGExists } )
>> +
>> + if conf.CheckPKGExists ('fftw3f'):
>> +     libraries['fftw3f'] = LibraryInfo()
>> +-    libraries['fftw3f'].ParseConfig('pkg-config --cflags --libs 
>> fftw3f')
>> ++    libraries['fftw3f'].ParseConfig('/opt/local/bin/pkg-config 
>> --cflags --libs fftw3f')
>> +
>> + if conf.CheckPKGExists ('fftw3'):
>> +     libraries['fftw3'] = LibraryInfo()
>> +-    libraries['fftw3'].ParseConfig('pkg-config --cflags --libs fftw3')
>> ++    libraries['fftw3'].ParseConfig('/opt/local/bin/pkg-config 
>> --cflags --libs fftw3')
>> +
>> + if conf.CheckPKGExists ('aubio'):
>> +     libraries['aubio'] = LibraryInfo()
>> +-    libraries['aubio'].ParseConfig('pkg-config --cflags --libs aubio')
>> ++    libraries['aubio'].ParseConfig('/opt/local/bin/pkg-config 
>> --cflags --libs aubio')
>> +
>> + env = conf.Finish ()
>> +
>> +@@ -569,7 +569,7 @@
>> +         print ('Ardour cannot be compiled without the curl headers, 
>> which do not seem to be installed')
>> +         sys.exit (1)
>> +     else:
>> +-        libraries['curl'].ParseConfig('pkg-config --cflags --libs 
>> libcurl')
>> ++        libraries['curl'].ParseConfig('/opt/local/bin/pkg-config 
>> --cflags --libs libcurl')
>> +     conf.Finish()
>> + else:
>> +     print 'FREESOUND support is not enabled.  Build with \'scons 
>> FREESOUND=1\' to enable.'
>> +@@ -579,7 +579,7 @@
>> +    
>> +     if conf.CheckPKGExists ('\"slv2 >= 0.6.0\"'):
>> +         libraries['slv2'] = LibraryInfo()
>> +-        libraries['slv2'].ParseConfig('pkg-config --cflags --libs 
>> slv2')
>> ++        libraries['slv2'].ParseConfig('/opt/local/bin/pkg-config 
>> --cflags --libs slv2')
>> +                 env.Append (CCFLAGS="-DHAVE_LV2")
>> +     else:
>> +         print 'Building Ardour with LV2 support requires SLV2 >= 
>> 0.6.0'
>> +@@ -592,31 +592,31 @@
>> +     print 'LV2 support is not enabled.  Build with \'scons LV2=1\' 
>> to enable.'
>> +
>> + libraries['jack'] = LibraryInfo()
>> +-libraries['jack'].ParseConfig('pkg-config --cflags --libs jack')
>> ++libraries['jack'].ParseConfig('/opt/local/bin/pkg-config --cflags 
>> --libs jack')
>> +
>> + libraries['xml'] = LibraryInfo()
>> +-libraries['xml'].ParseConfig('pkg-config --cflags --libs libxml-2.0')
>> ++libraries['xml'].ParseConfig('/opt/local/bin/pkg-config --cflags 
>> --libs libxml-2.0')
>> +
>> + libraries['xslt'] = LibraryInfo()
>> +-libraries['xslt'].ParseConfig('pkg-config --cflags --libs libxslt')
>> ++libraries['xslt'].ParseConfig('/opt/local/bin/pkg-config --cflags 
>> --libs libxslt')
>> +
>> + libraries['glib2'] = LibraryInfo()
>> +-libraries['glib2'].ParseConfig ('pkg-config --cflags --libs glib-2.0')
>> +-libraries['glib2'].ParseConfig ('pkg-config --cflags --libs 
>> gobject-2.0')
>> +-libraries['glib2'].ParseConfig ('pkg-config --cflags --libs 
>> gmodule-2.0')
>> +-libraries['glib2'].ParseConfig ('pkg-config --cflags --libs 
>> gthread-2.0')
>> ++libraries['glib2'].ParseConfig('/opt/local/bin/pkg-config --cflags 
>> --libs glib-2.0')
>> ++libraries['glib2'].ParseConfig('/opt/local/bin/pkg-config --cflags 
>> --libs gobject-2.0')
>> ++libraries['glib2'].ParseConfig('/opt/local/bin/pkg-config --cflags 
>> --libs gmodule-2.0')
>> ++libraries['glib2'].ParseConfig('/opt/local/bin/pkg-config --cflags 
>> --libs gthread-2.0')
>> +
>> + libraries['freetype2'] = LibraryInfo()
>> +-libraries['freetype2'].ParseConfig ('pkg-config --cflags --libs 
>> freetype2')
>> ++libraries['freetype2'].ParseConfig('/opt/local/bin/pkg-config 
>> --cflags --libs freetype2')
>> +
>> + libraries['gtk2'] = LibraryInfo()
>> +-libraries['gtk2'].ParseConfig ('pkg-config --cflags --libs gtk+-2.0')
>> ++libraries['gtk2'].ParseConfig('/opt/local/bin/pkg-config --cflags 
>> --libs gtk+-2.0')
>> +
>> + libraries['pango'] = LibraryInfo()
>> +-libraries['pango'].ParseConfig ('pkg-config --cflags --libs pango')
>> ++libraries['pango'].ParseConfig('/opt/local/bin/pkg-config --cflags 
>> --libs pango')
>> +
>> + libraries['libgnomecanvas2'] = LibraryInfo()
>> +-libraries['libgnomecanvas2'].ParseConfig ('pkg-config --cflags 
>> --libs libgnomecanvas-2.0')
>> ++libraries['libgnomecanvas2'].ParseConfig('/opt/local/bin/pkg-config 
>> --cflags --libs libgnomecanvas-2.0')
>> +
>> + #libraries['flowcanvas'] = LibraryInfo(LIBS='flowcanvas', 
>> LIBPATH='#/libs/flowcanvas', CPPPATH='#libs/flowcanvas')
>> +
>> +@@ -867,7 +867,7 @@
>> +
>> + conf = Configure (env)
>> +
>> +-if conf.CheckHeader ('fftw3.h'):
>> ++if conf.CheckHeader ('/opt/local/include/fftw3.h'):
>> +     env['RUBBERBAND'] = True
>> +     libraries['rubberband'] = LibraryInfo (LIBS='rubberband',
>> +                                            LIBPATH='#libs/rubberband',
>> +@@ -910,7 +910,7 @@
>> +
>> + libraries['flac'] = LibraryInfo ()
>> + prep_libcheck(env, libraries['flac'])
>> +-libraries['flac'].Append(CPPPATH="/usr/local/include", 
>> LIBPATH="/usr/local/lib")
>> ++libraries['flac'].Append(CPPPATH="/opt/local/include", 
>> LIBPATH="/opt/local/lib")
>> +
>> + #
>> + # june 1st 2007: look for a function that is in FLAC 1.1.2 and not 
>> in later versions
>> +@@ -934,7 +934,7 @@
>> +
>> + libraries['boost'] = LibraryInfo ()
>> + prep_libcheck(env, libraries['boost'])
>> +-libraries['boost'].Append(CPPPATH="/usr/local/include", 
>> LIBPATH="/usr/local/lib")
>> ++libraries['boost'].Append(CPPPATH="/opt/local/include", 
>> LIBPATH="/opt/local/lib")
>> + conf = Configure (libraries['boost'])
>> + if conf.CheckHeader ('boost/shared_ptr.hpp', language='CXX') == False:
>> +         print "Boost header files do not appear to be installed. 
>> You also might be running a buggy version of scons. Try scons 0.97 if 
>> you can."
>> +@@ -948,6 +948,7 @@
>> + if env['LIBLO']:
>> +     libraries['lo'] = LibraryInfo ()
>> +     prep_libcheck(env, libraries['lo'])
>> ++    libraries['lo'].Append(CPPPATH="/opt/local/include", 
>> LIBPATH="/opt/local/lib")
>> +
>> +     conf = Configure (libraries['lo'])
>> +     if conf.CheckLib ('lo', 'lo_server_new') == False:
>> +@@ -1044,21 +1045,21 @@
>> +     env = conf.Finish()
>> +
>> +     libraries['sigc2'] = LibraryInfo()
>> +-    libraries['sigc2'].ParseConfig('pkg-config --cflags --libs 
>> sigc++-2.0')
>> ++    libraries['sigc2'].ParseConfig('/opt/local/bin/pkg-config 
>> --cflags --libs sigc++-2.0')
>> +     libraries['glibmm2'] = LibraryInfo()
>> +-    libraries['glibmm2'].ParseConfig('pkg-config --cflags --libs 
>> glibmm-2.4')
>> ++    libraries['glibmm2'].ParseConfig('/opt/local/bin/pkg-config 
>> --cflags --libs glibmm-2.4')
>> +     libraries['cairomm'] = LibraryInfo()
>> +-    libraries['cairomm'].ParseConfig('pkg-config --cflags --libs 
>> cairomm-1.0')
>> ++    libraries['cairomm'].ParseConfig('/opt/local/bin/pkg-config 
>> --cflags --libs cairomm-1.0')
>> +     libraries['gdkmm2'] = LibraryInfo()
>> +-    libraries['gdkmm2'].ParseConfig ('pkg-config --cflags --libs 
>> gdkmm-2.4')
>> ++    libraries['gdkmm2'].ParseConfig('/opt/local/bin/pkg-config 
>> --cflags --libs gdkmm-2.4')
>> +     libraries['gtkmm2'] = LibraryInfo()
>> +-    libraries['gtkmm2'].ParseConfig ('pkg-config --cflags --libs 
>> gtkmm-2.4')
>> ++    libraries['gtkmm2'].ParseConfig('/opt/local/bin/pkg-config 
>> --cflags --libs gtkmm-2.4')
>> +     libraries['atkmm'] = LibraryInfo()
>> +-    libraries['atkmm'].ParseConfig ('pkg-config --cflags --libs 
>> atkmm-1.6')
>> ++    libraries['atkmm'].ParseConfig('/opt/local/bin/pkg-config 
>> --cflags --libs atkmm-1.6')
>> +     libraries['pangomm'] = LibraryInfo()
>> +-    libraries['pangomm'].ParseConfig ('pkg-config --cflags --libs 
>> pangomm-1.4')
>> ++    libraries['pangomm'].ParseConfig('/opt/local/bin/pkg-config 
>> --cflags --libs pangomm-1.4')
>> +     libraries['libgnomecanvasmm'] = LibraryInfo()
>> +-    libraries['libgnomecanvasmm'].ParseConfig ('pkg-config --cflags 
>> --libs libgnomecanvasmm-2.6')
>> ++    
>> libraries['libgnomecanvasmm'].ParseConfig('/opt/local/bin/pkg-config 
>> --cflags --libs libgnomecanvasmm-2.6')
>> +
>> + #
>> + # cannot use system one for the time being
>> +@@ -1272,7 +1273,7 @@
>> +     else:
>> +         print "Found msgmerge"
>> +
>> +-    if not conf.CheckCHeader('libintl.h'):
>> ++    if not conf.CheckCHeader('/opt/local/include/libintl.h'):
>> +         nls_error += ' No libintl.h.'
>> +         env['NLS'] = 0
>
>
yes, but they are replaced by the post-patch reinplace.  See above.



From blb at macports.org  Thu May  7 11:46:59 2009
From: blb at macports.org (Bryan Blackburn)
Date: Thu, 7 May 2009 12:46:59 -0600
Subject: [50694] branches/images-and-archives/base/src
In-Reply-To: <38635B7C-5D10-4578-BD87-F3C2169DAF88@macports.org>
References: <20090507054121.5BD25175749E@beta.macosforge.org>
	<4A0276CE.1030107@macports.org>
	<20090507060500.GM79127@ninagal.withay.com>
	<38635B7C-5D10-4578-BD87-F3C2169DAF88@macports.org>
Message-ID: <20090507184659.GE97995@ninagal.withay.com>

On Thu, May 07, 2009 at 05:25:36AM -0500, Ryan Schmidt said:
> On May 7, 2009, at 01:05, Bryan Blackburn wrote:
>
>> On Thu, May 07, 2009 at 07:51:10AM +0200, Rainer M?ller said:
>>> On 2009-05-07 07:41, blb at macports.org wrote:
>>>> Revision: 50694
>>>>           http://trac.macports.org/changeset/50694
>>>> Author:   blb at macports.org
>>>> Date:     2009-05-06 22:41:19 -0700 (Wed, 06 May 2009)
>>>> Log Message:
>>>> -----------
>>>> Remove source/binary only options
>>>
>>> I think the -b and -s options were quite useful to select if archives
>>> should be used or the software should be built from source. How do  
>>> you
>>> think this will work in the future?
>>
>> The way this branch will work is that the distinction between archives 
>> and
>> what's installed will be gone.  In the case of -b, that option won't 
>> make
>> sense anymore since "installed" is having the image file (archive as 
>> called
>> now) available, so you just have to activate the right one.  For -s, 
>> it's
>> like now if you disable archive mode, just uninstall the port to build 
>> from
>> source.
>
> Is there an explanation somewhere about this branch, what goals you're 
> trying to accomplish, etc.? Is there a ticket or a wiki page?

Yes, that would be #19458:

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

Bryan


From ryandesign at macports.org  Thu May  7 14:39:46 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 7 May 2009 16:39:46 -0500
Subject: [50674] trunk/dports/audio/ardour2
In-Reply-To: <4A02E28D.9070902@macports.org>
References: <20090506193650.2670C174E901@beta.macosforge.org>
	<96FA03BE-1084-4514-89B9-6BD0542D25AF@macports.org>
	<4A02E28D.9070902@macports.org>
Message-ID: <887FA624-DCCF-4B8F-9071-8D191955704F@macports.org>

On May 7, 2009, at 08:30, David Evans wrote:

> Ryan Schmidt wrote:
>
>> Your patch hardcodes the location /opt/local. You must change this  
>> to support whatever prefix MacPorts is currently running in, which  
>> could be different.

>>>  post-patch {
>>>      reinplace "s%/opt/local%${prefix}%g" ${worksrcpath}/SConstruct
>>>  }

> yes, but they are replaced by the post-patch reinplace.  See above.

Oh! So it is, I missed that.

It would be helpful if you could use something like "@PREFIX@"  
instead of "/opt/local" in the reinplace and in the patchfiles, for  
two reasons: 1) I have a rule in my email program to flag MacPorts  
changes emails containing "/opt/local" so that I can identify changes  
that hardcode /opt/local, and the way ardour2 is doing it makes it a  
false positive. I might also want to do a grep for "/opt/local" in  
all Portfiles to identify such ports, which would again be a false  
positive with ardour2. 2) The patch in #15514 will cause a warning to  
be printed if a reinplace doesn't replace anything. The reinplace in  
ardour2 will cause this warning to be printed if the prefix is /opt/ 
local.



From ryandesign at macports.org  Thu May  7 14:44:02 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 7 May 2009 16:44:02 -0500
Subject: [50694] branches/images-and-archives/base/src
In-Reply-To: <20090507184659.GE97995@ninagal.withay.com>
References: <20090507054121.5BD25175749E@beta.macosforge.org>
	<4A0276CE.1030107@macports.org>
	<20090507060500.GM79127@ninagal.withay.com>
	<38635B7C-5D10-4578-BD87-F3C2169DAF88@macports.org>
	<20090507184659.GE97995@ninagal.withay.com>
Message-ID: <0B39930F-C0D6-46FD-AD27-F15C500E7A0D@macports.org>


On May 7, 2009, at 13:46, Bryan Blackburn wrote:

> On Thu, May 07, 2009 at 05:25:36AM -0500, Ryan Schmidt said:
>
>> Is there an explanation somewhere about this branch, what goals  
>> you're
>> trying to accomplish, etc.? Is there a ticket or a wiki page?
>
> Yes, that would be #19458:
>
> <http://trac.macports.org/ticket/19458>

Thanks. Sounds good to me!



From dweber at macports.org  Thu May  7 16:07:07 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 7 May 2009 16:07:07 -0700
Subject: fetch aliases?
Message-ID: <b808b3510905071607k38f6ba12h4d796e53533a0699@mail.gmail.com>

For a variant in the InsightToolkit, it would be useful to get all the data
files from here:
http://public.kitware.com/pub/itk/Data/BrainWeb/

ie:

[image: [DIR]]Parent Directory
<http://public.kitware.com/pub/itk/Data/>  - [image:
[ ]]BrainPart1.tgz<http://public.kitware.com/pub/itk/Data/BrainWeb/BrainPart1.tgz>19-Mar-2002
10:12 5.6M [image: [
]]BrainPart1Rotated10Translated15.tgz<http://public.kitware.com/pub/itk/Data/BrainWeb/BrainPart1Rotated10Translated15.tgz>07-May-2002
18:11 4.9M [image: [
]]BrainPart1Rotated20Translated20.tgz<http://public.kitware.com/pub/itk/Data/BrainWeb/BrainPart1Rotated20Translated20.tgz>07-May-2002
18:11 4.3M [image: [
]]BrainPart2.tgz<http://public.kitware.com/pub/itk/Data/BrainWeb/BrainPart2.tgz>19-Mar-2002
10:12 5.3M [image: [
]]BrainPart2Rotated10Translated15.tgz<http://public.kitware.com/pub/itk/Data/BrainWeb/BrainPart2Rotated10Translated15.tgz>07-May-2002
18:11 4.6M [image: [
]]BrainPart2Rotated20Translated20.tgz<http://public.kitware.com/pub/itk/Data/BrainWeb/BrainPart2Rotated20Translated20.tgz>07-May-2002
18:11 4.1M [image: [
]]BrainPart3.tgz<http://public.kitware.com/pub/itk/Data/BrainWeb/BrainPart3.tgz>19-Mar-2002
10:12 5.8M [image: [
]]BrainPart3Rotated10Translated15.tgz<http://public.kitware.com/pub/itk/Data/BrainWeb/BrainPart3Rotated10Translated15.tgz>07-May-2002
18:11 5.1M [image: [
]]BrainPart3Rotated20Translated20.tgz<http://public.kitware.com/pub/itk/Data/BrainWeb/BrainPart3Rotated20Translated20.tgz>07-May-2002
18:11 4.5M

Is it possible to specify a fetch filename alias to get all the files like
"BrainPart*.tgz"?

Would you override the fetch phase in a variant, maybe something like:

variant braindata {
   fetch {
      exec wget -r -l1 --no-parent -A.tgz
http://public.kitware.com/pub/itk/Data/BrainWeb/
      # some code to put these downloads in the right place, like
${distfiles}
   }
}


Thanks in advance,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090507/995d08db/attachment.html>

From devans at macports.org  Thu May  7 16:11:55 2009
From: devans at macports.org (David Evans)
Date: Thu, 07 May 2009 16:11:55 -0700
Subject: [50674] trunk/dports/audio/ardour2
In-Reply-To: <887FA624-DCCF-4B8F-9071-8D191955704F@macports.org>
References: <20090506193650.2670C174E901@beta.macosforge.org>
	<96FA03BE-1084-4514-89B9-6BD0542D25AF@macports.org>
	<4A02E28D.9070902@macports.org>
	<887FA624-DCCF-4B8F-9071-8D191955704F@macports.org>
Message-ID: <4A036ABB.50307@macports.org>

Ryan Schmidt wrote:
>
>
> It would be helpful if you could use something like "@PREFIX@" instead 
> of "/opt/local" in the reinplace and in the patchfiles, for two 
> reasons: 1) I have a rule in my email program to flag MacPorts changes 
> emails containing "/opt/local" so that I can identify changes that 
> hardcode /opt/local, and the way ardour2 is doing it makes it a false 
> positive. I might also want to do a grep for "/opt/local" in all 
> Portfiles to identify such ports, which would again be a false 
> positive with ardour2. 2) The patch in #15514 will cause a warning to 
> be printed if a reinplace doesn't replace anything. The reinplace in 
> ardour2 will cause this warning to be printed if the prefix is 
> /opt/local.
>
Commited in r50723.   Thanks for your input.


From n.oxyde at gmail.com  Thu May  7 16:21:39 2009
From: n.oxyde at gmail.com (nox)
Date: Fri, 8 May 2009 01:21:39 +0200
Subject: fetch aliases?
In-Reply-To: <b808b3510905071607k38f6ba12h4d796e53533a0699@mail.gmail.com>
References: <b808b3510905071607k38f6ba12h4d796e53533a0699@mail.gmail.com>
Message-ID: <77621BD7-1A42-4D97-975D-80A18F96B0DD@gmail.com>

Bad idea. Every fetched file need to have its checksums verified.
If you have the checksums, you inevitably also have the filenames and  
thus do not have to use a glob pattern.
If you don't have fhe filenames, then you don't have the checksums.

Regards.

Le 8 mai 09 ? 01:07, Darren Weber a ?crit :

>
> For a variant in the InsightToolkit, it would be useful to get all  
> the data files from here:
> http://public.kitware.com/pub/itk/Data/BrainWeb/
>
> ie: <snip/>
>
> Is it possible to specify a fetch filename alias to get all the  
> files like "BrainPart*.tgz"?
>
> Would you override the fetch phase in a variant, maybe something like:
>
> variant braindata {
>    fetch {
>       exec wget -r -l1 --no-parent -A.tgz http://public.kitware.com/pub/itk/Data/BrainWeb/
>       # some code to put these downloads in the right place, like $ 
> {distfiles}
>    }
> }
>
>
> Thanks in advance,
> 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  Thu May  7 16:28:38 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 7 May 2009 16:28:38 -0700
Subject: fetch aliases?
In-Reply-To: <77621BD7-1A42-4D97-975D-80A18F96B0DD@gmail.com>
References: <b808b3510905071607k38f6ba12h4d796e53533a0699@mail.gmail.com>
	<77621BD7-1A42-4D97-975D-80A18F96B0DD@gmail.com>
Message-ID: <b808b3510905071628p4c4a0f7sc8ba0e4796a29149@mail.gmail.com>

Can a variant have "master_sites-append" ?



On Thu, May 7, 2009 at 4:21 PM, nox <n.oxyde at gmail.com> wrote:

> Bad idea. Every fetched file need to have its checksums verified.
> If you have the checksums, you inevitably also have the filenames and thus
> do not have to use a glob pattern.
> If you don't have fhe filenames, then you don't have the checksums.
>
> Regards.
>
> Le 8 mai 09 ? 01:07, Darren Weber a ?crit :
>
>
>> For a variant in the InsightToolkit, it would be useful to get all the
>> data files from here:
>> http://public.kitware.com/pub/itk/Data/BrainWeb/
>>
>> ie: <snip/>
>>
>> Is it possible to specify a fetch filename alias to get all the files like
>> "BrainPart*.tgz"?
>>
>> Would you override the fetch phase in a variant, maybe something like:
>>
>> variant braindata {
>>   fetch {
>>      exec wget -r -l1 --no-parent -A.tgz
>> http://public.kitware.com/pub/itk/Data/BrainWeb/
>>      # some code to put these downloads in the right place, like
>> ${distfiles}
>>   }
>> }
>>
>>
>> Thanks in advance,
>> 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/20090507/7283cfd6/attachment-0001.html>

From dweber at macports.org  Thu May  7 16:46:12 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 7 May 2009 16:46:12 -0700
Subject: fetch aliases?
In-Reply-To: <77621BD7-1A42-4D97-975D-80A18F96B0DD@gmail.com>
References: <b808b3510905071607k38f6ba12h4d796e53533a0699@mail.gmail.com>
	<77621BD7-1A42-4D97-975D-80A18F96B0DD@gmail.com>
Message-ID: <b808b3510905071646x513cb3cagc13dca6132045dc0@mail.gmail.com>

OK, so all the files and checksums are in the variant (using append
clauses), but the extract phase should not work on these data files.  Will
something like this work:

variant somedata {
   master_sites-append http://extraDataFileURL/
   distfiles-append  aBunchOfDataFiles
   checksums-append  yadda yadda ;-)
   extract {}
   post-destroot {
       # use tar on the $distfiles to extract all the data somewhere useful
   }
}

Thanks in advance,
Darren


On Thu, May 7, 2009 at 4:21 PM, nox <n.oxyde at gmail.com> wrote:

> Bad idea. Every fetched file need to have its checksums verified.
> If you have the checksums, you inevitably also have the filenames and thus
> do not have to use a glob pattern.
> If you don't have fhe filenames, then you don't have the checksums.
>
> Regards.
>
> Le 8 mai 09 ? 01:07, Darren Weber a ?crit :
>
>
>> For a variant in the InsightToolkit, it would be useful to get all the
>> data files from here:
>> http://public.kitware.com/pub/itk/Data/BrainWeb/
>>
>> ie: <snip/>
>>
>> Is it possible to specify a fetch filename alias to get all the files like
>> "BrainPart*.tgz"?
>>
>> Would you override the fetch phase in a variant, maybe something like:
>>
>> variant braindata {
>>   fetch {
>>      exec wget -r -l1 --no-parent -A.tgz
>> http://public.kitware.com/pub/itk/Data/BrainWeb/
>>      # some code to put these downloads in the right place, like
>> ${distfiles}
>>   }
>> }
>>
>>
>> Thanks in advance,
>> 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/20090507/af2a32e5/attachment.html>

From nox at macports.org  Thu May  7 17:13:28 2009
From: nox at macports.org (nox)
Date: Fri, 8 May 2009 02:13:28 +0200
Subject: xinstall glob question
In-Reply-To: <49FA3D91.2020404@macports.org>
References: <b808b3510904291139q28ea724blc0e2ae2a5b42bb0b@mail.gmail.com>	
	<6D456519-C643-4031-9AC1-A9EF284932C8@lavergne.gotdns.org>	
	<b808b3510904291245n593b57d8q5819d5e1b0112a34@mail.gmail.com>	
	<49F8D6A9.5010305@macports.org>	
	<b808b3510904301455t18839822qb32bd5626a95f59d@mail.gmail.com>	
	<49FA2006.3060207@macports.org>	
	<b808b3510904301518h13c49fb1sea648bc3776a88cf@mail.gmail.com>	
	<D3F48D40-2E44-4D0B-9963-9B1AB13F2F9C@macports.org>	
	<b808b3510904301635v6318d760g644b11c574c17301@mail.gmail.com>
	<b808b3510904301642g4e9d66adpe41562acf56542fc@mail.gmail.com>
	<49FA3D91.2020404@macports.org>
Message-ID: <E7F44914-B47C-47D9-A9DD-2555E88A59E2@macports.org>

By the way, the two following snippets are equivalent:
if {[string equal ${str1} ${str2}]} { ... }
if {${str1} eq ${str2}} { ... }

The opposite operator of "eq" is "ne".

Regars.

Le 1 mai 09 ? 02:08, Joshua Root a ?crit :

> Darren Weber wrote:
>>
>>
>> I get an error, ie:
>>
>> Error: Target org.macports.destroot returned: syntax error in  
>> expression
>> " string equal [file extension ${f}] ".app" ": variable references
>> require preceding $
>
> You're missing [] around the string equal call.
>
> - Josh
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


From n.oxyde at gmail.com  Thu May  7 17:20:48 2009
From: n.oxyde at gmail.com (nox)
Date: Fri, 8 May 2009 02:20:48 +0200
Subject: fetch aliases?
In-Reply-To: <b808b3510905071646x513cb3cagc13dca6132045dc0@mail.gmail.com>
References: <b808b3510905071607k38f6ba12h4d796e53533a0699@mail.gmail.com>
	<77621BD7-1A42-4D97-975D-80A18F96B0DD@gmail.com>
	<b808b3510905071646x513cb3cagc13dca6132045dc0@mail.gmail.com>
Message-ID: <446D4028-39CE-4824-A388-46FCC5252619@gmail.com>

First, you should give a name to the master site:

variant somedata {
	master_sites-append http://example.com:foo
	distfiles-append file1:foo file2:foo ...
	...
}

This way port won't try to fetch the extra distfiles from the main
master site.

For the extract phase, you need to set extract.only before appending new
distfiles:

variant somedata {
	...
	eval extract.only ${distfiles}
	distfiles-append ...
}

On a last note, you don't need to separate the checksums of the  
distfiles appended by the variant
from those of the main distfile, I think keeping checksums together is  
easier on the eyes and brain:

checksums	[suffix ${distname}] \
			checksums of the main distfile
		extra_file_1 \
  			... \
		extra_file_2 \
			... \
		...

Le 8 mai 09 ? 01:46, Darren Weber a ?crit :

>
> OK, so all the files and checksums are in the variant (using append  
> clauses), but the extract phase should not work on these data  
> files.  Will something like this work:
>
> variant somedata {
>    master_sites-append http://extraDataFileURL/
>    distfiles-append  aBunchOfDataFiles
>    checksums-append  yadda yadda ;-)
>    extract {}
>    post-destroot {
>        # use tar on the $distfiles to extract all the data somewhere  
> useful
>    }
> }
>
> Thanks in advance,
> Darren
>
>
> On Thu, May 7, 2009 at 4:21 PM, nox <n.oxyde at gmail.com> wrote:
> Bad idea. Every fetched file need to have its checksums verified.
> If you have the checksums, you inevitably also have the filenames  
> and thus do not have to use a glob pattern.
> If you don't have fhe filenames, then you don't have the checksums.
>
> Regards.
>
> Le 8 mai 09 ? 01:07, Darren Weber a ?crit :
>
>
> For a variant in the InsightToolkit, it would be useful to get all  
> the data files from here:
> http://public.kitware.com/pub/itk/Data/BrainWeb/
>
> ie: <snip/>
>
>
> Is it possible to specify a fetch filename alias to get all the  
> files like "BrainPart*.tgz"?
>
> Would you override the fetch phase in a variant, maybe something like:
>
> variant braindata {
>   fetch {
>      exec wget -r -l1 --no-parent -A.tgz http://public.kitware.com/pub/itk/Data/BrainWeb/
>      # some code to put these downloads in the right place, like $ 
> {distfiles}
>   }
> }
>
>
> Thanks in advance,
> Darren
>
> _______________________________________________
> 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 ryandesign at macports.org  Fri May  8 02:53:14 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 8 May 2009 04:53:14 -0500
Subject: [50737] trunk/dports/devel/cmake/Portfile
In-Reply-To: <20090508094812.5F0F5176CD45@beta.macosforge.org>
References: <20090508094812.5F0F5176CD45@beta.macosforge.org>
Message-ID: <AD42A980-C6C9-4648-BDA6-6E7BC9550FC8@macports.org>


On May 8, 2009, at 04:48, toby at macports.org wrote:

> Revision: 50737
>           http://trac.macports.org/changeset/50737
> Author:   toby at macports.org
> Date:     2009-05-08 02:48:11 -0700 (Fri, 08 May 2009)
> Log Message:
> -----------
> cmake 2.6.4

This update was approved by the maintainer of the port, or there was  
a ticket to which the maintainer did not respond for 72 hours? You  
did not indicate in your commit message...


> Modified Paths:
> --------------
>     trunk/dports/devel/cmake/Portfile
>
> Modified: trunk/dports/devel/cmake/Portfile
> ===================================================================
> --- trunk/dports/devel/cmake/Portfile	2009-05-08 09:31:48 UTC (rev  
> 50736)
> +++ trunk/dports/devel/cmake/Portfile	2009-05-08 09:48:11 UTC (rev  
> 50737)
> @@ -3,7 +3,7 @@
>  PortSystem 1.0
>
>  name		cmake
> -version		2.6.3
> +version		2.6.4
>  categories	devel
>  maintainers	css
>  description	Cross-platform make
> @@ -15,9 +15,9 @@
>  homepage	http://www.cmake.org/
>  platforms	darwin freebsd
>  master_sites	http://www.cmake.org/files/v2.6/
> -checksums	md5 5ba47a94ce276f326abca1fd72a7e7c6 \
> -		sha1 bf34e1661954d808ac3a3eb9d394b69e4d3b1a98 \
> -		rmd160 14f0e878844f55a1b3d02837e98087dcaabb16be
> +checksums	md5 50f387d0436696c4a68b5512a72c9cde \
> +		sha1 c7e295683e061c2ed19773a1f0444972f75db092 \
> +		rmd160 e4217067537f76e52317514cb5bb0cf38733d16a
>  configure.args	--mandir=/share/man --docdir=/share/doc/cmake
>
>  post-destroot {




From ryandesign at macports.org  Fri May  8 03:00:55 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 8 May 2009 05:00:55 -0500
Subject: fetch aliases?
In-Reply-To: <446D4028-39CE-4824-A388-46FCC5252619@gmail.com>
References: <b808b3510905071607k38f6ba12h4d796e53533a0699@mail.gmail.com>
	<77621BD7-1A42-4D97-975D-80A18F96B0DD@gmail.com>
	<b808b3510905071646x513cb3cagc13dca6132045dc0@mail.gmail.com>
	<446D4028-39CE-4824-A388-46FCC5252619@gmail.com>
Message-ID: <525591C1-FAC0-4B25-ACDD-F7AEDF8765D6@macports.org>


On May 7, 2009, at 19:20, nox wrote:

> First, you should give a name to the master site:
>
> variant somedata {
> 	master_sites-append http://example.com:foo
> 	distfiles-append file1:foo file2:foo ...
> 	...
> }
>
> This way port won't try to fetch the extra distfiles from the main
> master site.
>
> For the extract phase, you need to set extract.only before  
> appending new
> distfiles:
>
> variant somedata {
> 	...
> 	eval extract.only ${distfiles}
> 	distfiles-append ...
> }

Right, and relatedly, you would thus not override the extract phase  
with "extract {}" (which there is never a reason to do, and which in  
the future lint will complain about).


> On a last note, you don't need to separate the checksums of the  
> distfiles appended by the variant
> from those of the main distfile, I think keeping checksums together  
> is easier on the eyes and brain:
>
> checksums	[suffix ${distname}] \
> 			checksums of the main distfile
> 		extra_file_1 \
>  			... \
> 		extra_file_2 \
> 			... \
> 		...

Perhaps.

It can be done either way.

The same can be said of master_sites.

In the mysql5-devel port, for example, there is the innodb_plugin  
variant which downloads an additional file from a different location.  
In mysql5-devel, I have the master_sites all defined in the global  
part of the portfile, but append the checksums in the variant. I  
could have put both in the global section, or both in the variant.  
All that matters is that only in the variant is the new distfile  
appended to the distfiles variable.

From dweber at macports.org  Fri May  8 11:07:07 2009
From: dweber at macports.org (Darren Weber)
Date: Fri, 8 May 2009 11:07:07 -0700
Subject: fetch aliases?
In-Reply-To: <525591C1-FAC0-4B25-ACDD-F7AEDF8765D6@macports.org>
References: <b808b3510905071607k38f6ba12h4d796e53533a0699@mail.gmail.com>
	<77621BD7-1A42-4D97-975D-80A18F96B0DD@gmail.com>
	<b808b3510905071646x513cb3cagc13dca6132045dc0@mail.gmail.com>
	<446D4028-39CE-4824-A388-46FCC5252619@gmail.com>
	<525591C1-FAC0-4B25-ACDD-F7AEDF8765D6@macports.org>
Message-ID: <b808b3510905081107s24b1034anab38af2e750298d@mail.gmail.com>

On Fri, May 8, 2009 at 3:00 AM, Ryan Schmidt <ryandesign at macports.org>wrote:

>
> On May 7, 2009, at 19:20, nox wrote:
>
>  First, you should give a name to the master site:
>>
>> variant somedata {
>>        master_sites-append http://example.com:foo
>>        distfiles-append file1:foo file2:foo ...
>>        ...
>> }
>>
>> This way port won't try to fetch the extra distfiles from the main
>> master site.
>>
>> For the extract phase, you need to set extract.only before appending new
>> distfiles:
>>
>> variant somedata {
>>        ...
>>        eval extract.only ${distfiles}
>>        distfiles-append ...
>> }
>>
>
> Right, and relatedly, you would thus not override the extract phase with
> "extract {}" (which there is never a reason to do, and which in the future
> lint will complain about).
>
>
>  On a last note, you don't need to separate the checksums of the distfiles
>> appended by the variant
>> from those of the main distfile, I think keeping checksums together is
>> easier on the eyes and brain:
>>
>> checksums       [suffix ${distname}] \
>>                        checksums of the main distfile
>>                extra_file_1 \
>>                        ... \
>>                extra_file_2 \
>>                        ... \
>>                ...
>>
>
> Perhaps.
>
> It can be done either way.
>
> The same can be said of master_sites.
>
> In the mysql5-devel port, for example, there is the innodb_plugin variant
> which downloads an additional file from a different location. In
> mysql5-devel, I have the master_sites all defined in the global part of the
> portfile, but append the checksums in the variant. I could have put both in
> the global section, or both in the variant. All that matters is that only in
> the variant is the new distfile appended to the distfiles variable.
>




Got it, thanks very much for clarifications.  I hope to commit an update to
InsightToolkit soon.  This data variant is now looking like this (let me
know if you see any problems):

{{{

variant brainweb description {provide ITK BrainWeb data:
${prefix}/share/${distname}/data]} {
    master_sites-append \
        http://public.kitware.com/pub/itk/Data/BrainWeb:brainweb
    eval extract.only ${distfiles}
    distfiles-append \
        BrainPart1.tgz:brainweb \
        BrainPart1Rotated10Translated15.tgz:brainweb \
        BrainPart1Rotated20Translated20.tgz:brainweb \
        BrainPart2.tgz:brainweb \
        BrainPart2Rotated10Translated15.tgz:brainweb \
        BrainPart2Rotated20Translated20.tgz:brainweb \
        BrainPart3.tgz:brainweb \
        BrainPart3Rotated10Translated15.tgz:brainweb \
        BrainPart3Rotated20Translated20.tgz:brainweb
    checksums-append \
        BrainPart1.tgz \
            md5  e722d697f9d0b51023652b3fe7348658 \
            sha1 e91f5c4928c880b944e1559eee015170c1badc4b \
            rmd160 b5cbb557df0b019afe3f411deea72ef464626ace \
        BrainPart1Rotated10Translated15.tgz \
            md5  9d052710929477b1ddb5095575a5d7f9 \
            sha1 effc10374f1e70ded967fb55237cd600b6ef51ca \
            rmd160 3e1f19dbe48b7912f46f255459330fde50f96b62 \
        BrainPart1Rotated20Translated20.tgz \
            md5  36af81caf9ea7ce9b72987ff6d08ddf3 \
            sha1 4c10b5ab612282361f344d1432664067bc94c736 \
            rmd160 d6d23117fbf8803b0488b4fd5bddb739576d983f \
        BrainPart2.tgz \
            md5  458b0903a2fb52a1cae616eddf817142 \
            sha1 21659b5ee37a9ed0958c79a1943dd5ebafbe27ec \
            rmd160 dc85b393c8dfbf04ba2aa0690237acfb185ada4e \
        BrainPart2Rotated10Translated15.tgz \
            md5  8c978a660e442e4ed06e77bc4f769af2 \
            sha1 58c1b5a6d9e8a965f3e73febca012747b0246702 \
            rmd160 3867b0d006fa8b5af084a78fa812aff69c2ad0c1 \
        BrainPart2Rotated20Translated20.tgz \
            md5  5f53d805ab4346b933ce52c7b34e67b2 \
            sha1 f29740e4760ffc602e9a6b2aa2b96efabcff1aa6 \
            rmd160 2441747f0c98e9f2fa24a1c7ca9294bed729dcc0 \
        BrainPart3.tgz \
            md5  c6f5edccbb2c0ba418e4666fe989eb15 \
            sha1 20cdee786c710aed0df6943bcbaa9c62bb82e773 \
            rmd160 3f730bf426a6509c73c58902220b64cb3324b136 \
        BrainPart3Rotated10Translated15.tgz \
            md5  61893ca3df13d24530275758de702fef \
            sha1 4f6ba74d68a7e477fd43237213d4d4e4ce839503 \
            rmd160 ba408d2ff6297af7f76af82ae24e9afe519bb80c \
        BrainPart3Rotated20Translated20.tgz \
            md5  db63c7567d1c021860d59812eb41dfa9 \
            sha1 2e14b66beef00acc8cd17942d9bf0c155841a934 \
            rmd160 42d403505116e8b9885d00964376cee909711bd0
    global itkDataPath
    configure.args-append \
        -DITK_BRAINWEB_DATA_ROOT:PATH=${itkDataPath}
    post-destroot {
        global itkDataPath
        xinstall -d -o root -g admin -m 0755 ${destroot}/${itkDataPath}
        foreach tgz [exec find ${distpath} -name "BrainPart*.tgz"] {
            system "tar -C ${destroot}/${itkDataPath} -zxf ${tgz}"
        }
    }
}

}}}



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

From dweber at macports.org  Fri May  8 11:14:48 2009
From: dweber at macports.org (Darren Weber)
Date: Fri, 8 May 2009 11:14:48 -0700
Subject: Ruby headers?
Message-ID: <b808b3510905081114r76a4f23btf888747128f591f9@mail.gmail.com>

Where are the ruby headers?

There's $prefix/lib/libruby* but no headers in $prefix/include or
$prefix/Library/Frameworks/

I have
ruby @1.8.7-p160_1+thread_hooks (active)

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

From dluke at geeklair.net  Fri May  8 12:09:17 2009
From: dluke at geeklair.net (Daniel J. Luke)
Date: Fri, 8 May 2009 15:09:17 -0400
Subject: Ruby headers?
In-Reply-To: <b808b3510905081114r76a4f23btf888747128f591f9@mail.gmail.com>
References: <b808b3510905081114r76a4f23btf888747128f591f9@mail.gmail.com>
Message-ID: <8143FF19-864B-4869-83EB-99E7B3121545@geeklair.net>

On May 8, 2009, at 2:14 PM, Darren Weber wrote:
> Where are the ruby headers?
>
> There's $prefix/lib/libruby* but no headers in $prefix/include or  
> $prefix/Library/Frameworks/
>
> I have
> ruby @1.8.7-p160_1+thread_hooks (active)


I don't know which headers you're specifically looking for, but  
perhaps port can help you find them?

% port contents ruby | grep ruby.h
   /opt/local/lib/ruby/1.8/i686-darwin9/ruby.h

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



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

From n.oxyde at gmail.com  Fri May  8 16:05:01 2009
From: n.oxyde at gmail.com (nox)
Date: Sat, 9 May 2009 01:05:01 +0200
Subject: fetch aliases?
In-Reply-To: <b808b3510905081107s24b1034anab38af2e750298d@mail.gmail.com>
References: <b808b3510905071607k38f6ba12h4d796e53533a0699@mail.gmail.com>
	<77621BD7-1A42-4D97-975D-80A18F96B0DD@gmail.com>
	<b808b3510905071646x513cb3cagc13dca6132045dc0@mail.gmail.com>
	<446D4028-39CE-4824-A388-46FCC5252619@gmail.com>
	<525591C1-FAC0-4B25-ACDD-F7AEDF8765D6@macports.org>
	<b808b3510905081107s24b1034anab38af2e750298d@mail.gmail.com>
Message-ID: <EF8FB9D0-48FC-4710-8939-9B514EDB39D8@gmail.com>

As far as I know, variants and other code blocks already imports
every defined variable into the local scope, so you don't need
to use global.

Le 8 mai 09 ? 20:07, Darren Weber a ?crit :

> <snip/>
>     global itkDataPath
> <snip/>
>


From ryandesign at macports.org  Sat May  9 02:47:54 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 9 May 2009 04:47:54 -0500
Subject: [50759] trunk/dports/graphics/InsightToolkit/Portfile
In-Reply-To: <20090508222945.ACD181778A68@beta.macosforge.org>
References: <20090508222945.ACD181778A68@beta.macosforge.org>
Message-ID: <60DACCAB-71EE-4B07-AA54-F93D1CCAC57D@macports.org>

On May 8, 2009, at 17:29, dweber at macports.org wrote:

> Revision: 50759
>           http://trac.macports.org/changeset/50759
> Author:   dweber at macports.org
> Date:     2009-05-08 15:29:45 -0700 (Fri, 08 May 2009)
> Log Message:
> -----------
> updated version; trying to add new variants for wrapping, etc.

> Modified: trunk/dports/graphics/InsightToolkit/Portfile

> -maintainers		p.schmiedeskamp at auckland.ac.nz

> +maintainers     dweber openmaintainer

The previous maintainer OK'd this change of maintainership? You  
didn't indicate in your commit message.



From florian.ebeling at gmail.com  Sat May  9 02:51:12 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Sat, 9 May 2009 11:51:12 +0200
Subject: Ruby headers?
In-Reply-To: <8143FF19-864B-4869-83EB-99E7B3121545@geeklair.net>
References: <b808b3510905081114r76a4f23btf888747128f591f9@mail.gmail.com>
	<8143FF19-864B-4869-83EB-99E7B3121545@geeklair.net>
Message-ID: <5cbbe4ae0905090251o16145102r43e69a6f4aaf82b2@mail.gmail.com>

On Fri, May 8, 2009 at 9:09 PM, Daniel J. Luke <dluke at geeklair.net> wrote:
> On May 8, 2009, at 2:14 PM, Darren Weber wrote:
>>
>> Where are the ruby headers?
>>
>> There's $prefix/lib/libruby* but no headers in $prefix/include or
>> $prefix/Library/Frameworks/
>>
>> I have
>> ruby @1.8.7-p160_1+thread_hooks (active)
>
>
> I don't know which headers you're specifically looking for, but perhaps port
> can help you find them?
>
> % port contents ruby | grep ruby.h
> ?/opt/local/lib/ruby/1.8/i686-darwin9/ruby.h

Yes, this is the one you usually use for extensions.
The location path contains the architecture to be able to keep more
than one architecture in the same image or file system.

On a linux machine this might be:
/usr/lib/ruby/1.8/i486-linux/ruby.h

This location is determined during (autoconf) configure phase of the
package. The location is named the 'archdir' of the package,
and you can examine it from within ruby because it is saved
in a require-able file, rbconfig.rb. This shell line gives you the
value in a shell script:

  ruby -r rbconfig -e 'puts Config::CONFIG["archdir"]'

So if you write a build script you might want to reference
it using this variable, to make it usable on systems other
the your current one.

Florian

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

From ryandesign at macports.org  Sat May  9 21:33:45 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 9 May 2009 23:33:45 -0500
Subject: [50796] trunk/dports/devel/git-core
In-Reply-To: <20090509201624.476D31809F92@beta.macosforge.org>
References: <20090509201624.476D31809F92@beta.macosforge.org>
Message-ID: <7E178971-238B-4BF9-8AD9-7863450A2BA5@macports.org>

On May 9, 2009, at 15:16, ram at macports.org wrote:

> Revision: 50796
>           http://trac.macports.org/changeset/50796
> Author:   ram at macports.org
> Date:     2009-05-09 13:16:23 -0700 (Sat, 09 May 2009)
> Log Message:
> -----------
> devel/git-core: maintainer update to 1.6.3, closes #19563
>

Are we sure 1.6.3 is a stable version? The git homepage says the  
latest stable version is 1.6.2.5.

http://git-scm.com/



From ram at macports.org  Sat May  9 21:58:09 2009
From: ram at macports.org (Adam Mercer)
Date: Sat, 9 May 2009 23:58:09 -0500
Subject: [50796] trunk/dports/devel/git-core
In-Reply-To: <7E178971-238B-4BF9-8AD9-7863450A2BA5@macports.org>
References: <20090509201624.476D31809F92@beta.macosforge.org> 
	<7E178971-238B-4BF9-8AD9-7863450A2BA5@macports.org>
Message-ID: <799406d60905092158o73442d25qea4aba3504d23e19@mail.gmail.com>

On Sat, May 9, 2009 at 23:33, Ryan Schmidt <ryandesign at macports.org> wrote:

> Are we sure 1.6.3 is a stable version? The git homepage says the latest
> stable version is 1.6.2.5.

Here's the announcement, there's no mention of it being a development release:

http://marc.info/?l=linux-kernel&m=124168020423520&w=2

Cheers

Adam

From florian.ebeling at gmail.com  Sun May 10 05:12:44 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Sun, 10 May 2009 14:12:44 +0200
Subject: ruby_select experimental implementation
In-Reply-To: <20090422220051485505.e38ce4e0@macports.org>
References: <20090422220051485505.e38ce4e0@macports.org>
Message-ID: <5cbbe4ae0905100512h2a48579frae2242c2cc3af123@mail.gmail.com>

Hi Kimura,

I just committed the ruby 1.9.1 parts to the ruby_select branch.
It works fundamentally now. Here are a number of things I have noticed:

- errors when no ruby whatsoever is installed. If a versin is not install
  but then selected, then user doesn't get a warning nor an
  error. This behaviour comes from select-0.2.1, I'm aware, but it's
  still a bit unintuitive.

- version suffix: ruby19 has the executable suffix 1.9 (with dot),
  ruby18 has 18 (without dot) -- not quite consistent. With ruby19 I
  have adopted this scheme (name without dots, executable with dots)
  from mp python ports. I would suggest you consider switching to
  suffix "1.8" and "1.8.6" as well, for the sake of consistency (also
  since the suffixes for 1.8 rubys are not out at the users yet) Would
  that be acceptable to you?

- symlinked libs: I think this is not worth the trouble, and between
  1.8 and 1.9 it would even look a bit hazardous to me. Python does
  not try to do this, if I'm not mistaken, and the description of the
  ruby_select port also only mentions the interpreter (which we would
  need to extend to irb, ri, etc, anyway). I would leave them out for
  simplicity :) Would you mind?

- rake1.9, gem1.9: Not sure what to do with rake1.9 and gem1.9. These
  should be accessible via their basename as well, but we probably
  don't want separate rake_select and gem_select ports. The fundamental
  idea is that 1.8 and 1.9 can stay installed and active, while keeping
  the simple 'ruby', 'irb',
  etc. invokations. But when can neither easily add them to the
  collection of executables we switch here, since they don't come with
  a suffix, nor can I just add symlinks to the ruby19 port, since then
  it would conflict with rb-rubygems and rb-rake. (Perhaps still
  the best would be to accept that rb-rubygems/rb-rake and ruby19 do
  conflict and tell users to deactivate them for them time being.)
  Please tell me if you have an idea for that or what you would
  prefer.

I haven't thought about the renaming of port ruby to ruby18 yet, but
we would have to have something for that as well before this whole
patch can go into trunk.

Florian


On Wed, Apr 22, 2009 at 3:00 PM, kimura wataru <kimuraw at macports.org> wrote:
> Hi,
>
> I write experimental ruby_select for ruby186 and ruby18.
>
> ?http://trac.macports.org/browser/users/kimuraw/ruby_select
>
> == install destinations
>
> * different name for ruby bundled commands and libraries
> * share library and document directory for additional libraries
>
> this allows to activate both of ruby186 and ruby18.
>
>
> ?dir,file ? ? ? 1.8.6(ruby186) ? ? ? ? ? ? 1.8.7(ruby18)
> ------------------------------------------------------------
> bin/ruby ? ? ? ?bin/ruby186 ? ? ? ? ? ? ? ?bin/ruby18
> bin/irb ? ? ? ? bin/irb186 ? ? ? ? ? ? ? ? bin/irb18
> ?:
> libdir ? ? ? ? ?lib/ruby/1.8.6/ ? ? ? ? ? ?lib/ruby/1.8.7/
> sitedir ? ? ? ? lib/ruby/site_ruby/1.8/ ? ?(share)
> vendordir ? ? ? lib/ruby/vendor_ruby/1.8/ ?(share)
> libruby.so ? ? ?libruby186.dylib ? ? ? ? ? libruby18.dylib
> ri sysdir ? ? ? share/ri/1.8/system1.8.6/ ?share/ri/1.8/system1.8.7/
> ri sitedir ? ? ?share/ri/1.8/site/ ? ? ? ? (share)
> ------------------------------------------------------------
>
> macports' vendor-specific.rb and site-specific.rb are moved
> to lidir from vendordir and sitedir to avoid conflicts.
>
> == ruby_select
>
> sysutils/ruby_select uses same tool as port:python_select or port:gcc_selct.
>
> ?% sudo ruby_select ruby18
> ?Selecting version "ruby18" for ruby
> ?% ls -l /opt/local/bin/ruby
> ?lrwxr-xr-x ?1 root ?admin ?21 Apr 18 21:03 /opt/local/bin/ruby@ -> /opt/local/bin/ruby18
> ?% sudo ruby_select ruby186
> ?Selecting version "ruby186" for ruby
> ?% ls -l /opt/local/bin/ruby
> ?lrwxr-xr-x ?1 root ?admin ?22 Apr 18 21:06 /opt/local/bin/ruby@ -> /opt/local/bin/ruby186
>
> the following files are targets of ruby_select.
> * bin/ ruby, erb, irb, rdoc, ri, testrb
> * lib/ libruby.dylib, libruby-static.a
>
> ruby_select make symlinks the above files at post-activate.
> then, install ruby_select means existence of ${prefix}/bin/ruby (without suffix).
> I expect this port become a meta port port:ruby.
>
> == linking libruby
>
> ruby_select introduce libruby.dylib. this file is a symbolic link for
> libruby186.dylib or libruby18.dylib. and, vendor-specific.rb changes
> LIBRUBYARG and so on.
>
> ?% ruby -rrbconfig -e 'p Config::CONFIG["LIBRUBYARG"]'
> ?"-lruby18"
> ?% ruby -rvendor-specific -rrbconfig -e 'p Config::CONFIG["LIBRUBYARG"]'
> ?"-lruby"
>
> so, port:rb-* links libruby.dylib and extension modules (.bundle)
> use ruby_select-ed libruby.
>
> this implementation is not enough. please tell me your thoughts.
>
> --
> kimura wataru
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>



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

From florian.ebeling at gmail.com  Sun May 10 07:34:58 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Sun, 10 May 2009 16:34:58 +0200
Subject: ruby_select experimental implementation
In-Reply-To: <5cbbe4ae0905100512h2a48579frae2242c2cc3af123@mail.gmail.com>
References: <20090422220051485505.e38ce4e0@macports.org>
	<5cbbe4ae0905100512h2a48579frae2242c2cc3af123@mail.gmail.com>
Message-ID: <5cbbe4ae0905100734n3f9a49d6i46c9a47ea53995b@mail.gmail.com>

On Sun, May 10, 2009 at 2:12 PM, C. Florian Ebeling
<florian.ebeling at gmail.com> wrote:
> - errors when no ruby whatsoever is installed. If a versin is not install
> ?but then selected, then user doesn't get a warning nor an
> ?error. This behaviour comes from select-0.2.1, I'm aware, but it's
> ?still a bit unintuitive.

One other thing I noticed is that ruby_select does not
declare any dependency on any ruby, which surprised me
a bit. But python does not require any python either.
There is probably some reasoning behind this. I would
like to learn more about the this.

These two behaviours together, though, leave users in the
situation where they install ruby_select, then issue

  sudo ruby_select ruby186

which does not complain, but there won't be a usable ruby
afterwards, only a couple of symlinks pointing into the nowhere.

At least I was surprised at first about this, and others
may be as well.

Florian


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

From raimue at macports.org  Sun May 10 08:55:52 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Sun, 10 May 2009 17:55:52 +0200
Subject: ruby_select experimental implementation
In-Reply-To: <5cbbe4ae0905100734n3f9a49d6i46c9a47ea53995b@mail.gmail.com>
References: <20090422220051485505.e38ce4e0@macports.org>	<5cbbe4ae0905100512h2a48579frae2242c2cc3af123@mail.gmail.com>
	<5cbbe4ae0905100734n3f9a49d6i46c9a47ea53995b@mail.gmail.com>
Message-ID: <4A06F908.8080202@macports.org>

C. Florian Ebeling wrote:
> One other thing I noticed is that ruby_select does not
> declare any dependency on any ruby, which surprised me
> a bit. But python does not require any python either.
> There is probably some reasoning behind this. I would
> like to learn more about the this.

I would find it a bit strange if *_select required a specific version.
Instead, the ruby and python versions should require *_select.

See <http://trac.macports.org/ticket/19126>

> These two behaviours together, though, leave users in the
> situation where they install ruby_select, then issue
> 
>   sudo ruby_select ruby186
> 
> which does not complain, but there won't be a usable ruby
> afterwards, only a couple of symlinks pointing into the nowhere.

As I said before, the select files should be part of the corresponding
ports and not of *_select. This way it is only possible to select
versions which are installed and active.

See the pythonXX ports as an example using the select port group.

Rainer

From florian.ebeling at gmail.com  Sun May 10 11:31:10 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Sun, 10 May 2009 20:31:10 +0200
Subject: ruby_select experimental implementation
In-Reply-To: <4A06F908.8080202@macports.org>
References: <20090422220051485505.e38ce4e0@macports.org>
	<5cbbe4ae0905100512h2a48579frae2242c2cc3af123@mail.gmail.com>
	<5cbbe4ae0905100734n3f9a49d6i46c9a47ea53995b@mail.gmail.com>
	<4A06F908.8080202@macports.org>
Message-ID: <5cbbe4ae0905101131i6f86a83cnc7efbb6fd17c71b3@mail.gmail.com>

On Sun, May 10, 2009 at 5:55 PM, Rainer M?ller <raimue at macports.org> wrote:
> C. Florian Ebeling wrote:
>> One other thing I noticed is that ruby_select does not
>> declare any dependency on any ruby, which surprised me
>> a bit. But python does not require any python either.
>> There is probably some reasoning behind this. I would
>> like to learn more about the this.
>
> I would find it a bit strange if *_select required a specific version.
> Instead, the ruby and python versions should require *_select.

Ok, that way around it sounds reasonable. Although, you could immediately
select a default, if we were pulling one version via the select port, and offer
flexibility using variants.


> See <http://trac.macports.org/ticket/19126>
>
>> These two behaviours together, though, leave users in the
>> situation where they install ruby_select, then issue
>>
>> ? sudo ruby_select ruby186
>>
>> which does not complain, but there won't be a usable ruby
>> afterwards, only a couple of symlinks pointing into the nowhere.
>
> As I said before, the select files should be part of the corresponding
> ports and not of *_select. This way it is only possible to select
> versions which are installed and active.

Ok, got it. Cheers :)

As it seems it is even possible to have a variable number of executables
or files in the various selectables, is that true? That might help
with rake and gem, which are only part of the 1.9 release.

Any idea what select does when it encouters a real file being in the place
where it intends to put a symlink?

Btw: The 'port select' in trunk, which is mentioned in the ticket, does
that indeed obsolete all these efforts?


Florian

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

From raimue at macports.org  Sun May 10 11:37:09 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Sun, 10 May 2009 20:37:09 +0200
Subject: ruby_select experimental implementation
In-Reply-To: <5cbbe4ae0905101131i6f86a83cnc7efbb6fd17c71b3@mail.gmail.com>
References: <20090422220051485505.e38ce4e0@macports.org>	
	<5cbbe4ae0905100512h2a48579frae2242c2cc3af123@mail.gmail.com>	
	<5cbbe4ae0905100734n3f9a49d6i46c9a47ea53995b@mail.gmail.com>	
	<4A06F908.8080202@macports.org>
	<5cbbe4ae0905101131i6f86a83cnc7efbb6fd17c71b3@mail.gmail.com>
Message-ID: <4A071ED5.6050804@macports.org>

On 2009-05-10 20:31, C. Florian Ebeling wrote:
> On Sun, May 10, 2009 at 5:55 PM, Rainer M?ller <raimue at macports.org> wrote:
>> C. Florian Ebeling wrote:
>>> One other thing I noticed is that ruby_select does not
>>> declare any dependency on any ruby, which surprised me
>>> a bit. But python does not require any python either.
>>> There is probably some reasoning behind this. I would
>>> like to learn more about the this.
>> I would find it a bit strange if *_select required a specific version.
>> Instead, the ruby and python versions should require *_select.
> 
> Ok, that way around it sounds reasonable. Although, you could immediately
> select a default, if we were pulling one version via the select port, and offer
> flexibility using variants.

Which would also mean you would have to install this specific version to
get the *_select port.

> As it seems it is even possible to have a variable number of executables
> or files in the various selectables, is that true? That might help
> with rake and gem, which are only part of the 1.9 release.

All files have to be in the base file, but the select file can use "-"
to indicate that there should not be any symlink at this location.

> Any idea what select does when it encouters a real file being in the place
> where it intends to put a symlink?

It will overwrite the file.

> Btw: The 'port select' in trunk, which is mentioned in the ticket, does
> that indeed obsolete all these efforts?

It obsoletes the various *_select tools based on select.sh by providing
the same functionality in base.

Rainer

From florian.ebeling at gmail.com  Sun May 10 11:50:51 2009
From: florian.ebeling at gmail.com (C. Florian Ebeling)
Date: Sun, 10 May 2009 20:50:51 +0200
Subject: ruby_select experimental implementation
In-Reply-To: <4A071ED5.6050804@macports.org>
References: <20090422220051485505.e38ce4e0@macports.org>
	<5cbbe4ae0905100512h2a48579frae2242c2cc3af123@mail.gmail.com>
	<5cbbe4ae0905100734n3f9a49d6i46c9a47ea53995b@mail.gmail.com>
	<4A06F908.8080202@macports.org>
	<5cbbe4ae0905101131i6f86a83cnc7efbb6fd17c71b3@mail.gmail.com>
	<4A071ED5.6050804@macports.org>
Message-ID: <5cbbe4ae0905101150k15b3b06t19157eb741f7068b@mail.gmail.com>

>> Any idea what select does when it encouters a real file being in the place
>> where it intends to put a symlink?
>
> It will overwrite the file.

bummer. With ruby the situation is that there are
executables in 1.9 which are provided by ports
in 1.8.

lang/ruby: ruby1.8, irb1.8
ruby/rb-rubygems: gem

lang/ruby19: ruby1.9, irb1.9, gem1.9

Gems also don't allow a suffix on installation
for executables.

The only solution I see now is to make the symlinks
to unprefixed symlinks already in the portfile, and make
it plain conflicting with the ports installing unprefixed
executables. Even though that makes them not fully
parallel-installable. That, or some serious patching
of rb-rubygems to force suffix.

Florian


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

From ram at macports.org  Sun May 10 12:26:11 2009
From: ram at macports.org (Adam Mercer)
Date: Sun, 10 May 2009 14:26:11 -0500
Subject: [50796] trunk/dports/devel/git-core
In-Reply-To: <799406d60905092158o73442d25qea4aba3504d23e19@mail.gmail.com>
References: <20090509201624.476D31809F92@beta.macosforge.org> 
	<7E178971-238B-4BF9-8AD9-7863450A2BA5@macports.org>
	<799406d60905092158o73442d25qea4aba3504d23e19@mail.gmail.com>
Message-ID: <799406d60905101226r793ee575m79e338a9c590b737@mail.gmail.com>

On Sat, May 9, 2009 at 23:58, Adam Mercer <ram at macports.org> wrote:
> On Sat, May 9, 2009 at 23:33, Ryan Schmidt <ryandesign at macports.org> wrote:
>
>> Are we sure 1.6.3 is a stable version? The git homepage says the latest
>> stable version is 1.6.2.5.
>
> Here's the announcement, there's no mention of it being a development release:
>
> http://marc.info/?l=linux-kernel&m=124168020423520&w=2

Looks like they've updated the homepage following your email to the
git list, 1.6.3 is now listed as the latest stable release.

Cheers

Adam

From ryandesign at macports.org  Mon May 11 01:10:53 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 11 May 2009 03:10:53 -0500
Subject: [50749] trunk/dports/x11/quartz-wm/Portfile
In-Reply-To: <20090508191044.E7036177604E@beta.macosforge.org>
References: <20090508191044.E7036177604E@beta.macosforge.org>
Message-ID: <E2E42292-2616-4EF9-883B-97BD31002928@macports.org>

On May 8, 2009, at 14:10, jeremyhu at macports.org wrote:

> Revision: 50749
>           http://trac.macports.org/changeset/50749
> Author:   jeremyhu at macports.org
> Date:     2009-05-08 12:10:43 -0700 (Fri, 08 May 2009)
> Log Message:
> -----------
> quartz-wm: Fix quartz-wm when prefix is not /opt/local

Should we bump the revision so that those who do have MacPorts  
installed in a nonstandard prefix will get this change?


> Modified Paths:
> --------------
>     trunk/dports/x11/quartz-wm/Portfile
>
> Modified: trunk/dports/x11/quartz-wm/Portfile
> ===================================================================
> --- trunk/dports/x11/quartz-wm/Portfile	2009-05-08 19:08:19 UTC  
> (rev 50748)
> +++ trunk/dports/x11/quartz-wm/Portfile	2009-05-08 19:10:43 UTC  
> (rev 50749)
> @@ -45,4 +45,11 @@
>  	} else {
>  		xinstall -m 755 ${worksrcpath}/quartz-wm-${version}-Leopard $ 
> {destroot}${prefix}/bin/quartz-wm
>  	}
> +
> +	if {${prefix} != "/opt/local"} {
> +		system "install_name_tool -change /opt/local/lib/libXinerama. 
> 1.dylib ${prefix}/lib/libXinerama.1.dylib ${destroot}${prefix}/bin/ 
> quartz-wm"
> +		system "install_name_tool -change /opt/local/lib/libXext.6.dylib  
> ${prefix}/lib/libXext.6.dylib ${destroot}${prefix}/bin/quartz-wm"
> +		system "install_name_tool -change /opt/local/lib/libX11.6.dylib $ 
> {prefix}/lib/libX11.6.dylib ${destroot}${prefix}/bin/quartz-wm"
> +		system "install_name_tool -change /opt/local/lib/libAppleWM. 
> 7.dylib ${prefix}/lib/libAppleWM.7.dylib ${destroot}${prefix}/bin/ 
> quartz-wm"
> +	}
>  }



From dweber at macports.org  Mon May 11 11:16:58 2009
From: dweber at macports.org (Darren Weber)
Date: Mon, 11 May 2009 11:16:58 -0700
Subject: [50759] trunk/dports/graphics/InsightToolkit/Portfile
In-Reply-To: <AB819A6E5247C845B1DD69FD8DC068951908D50D81@UXCHANGE7-1.UoA.auckland.ac.nz>
References: <20090508222945.ACD181778A68@beta.macosforge.org>
	<60DACCAB-71EE-4B07-AA54-F93D1CCAC57D@macports.org>
	<AB819A6E5247C845B1DD69FD8DC068951908D50D81@UXCHANGE7-1.UoA.auckland.ac.nz>
Message-ID: <b808b3510905111116s530fcaf0g79c827269ada8444@mail.gmail.com>

Sorry, that was oversight on my part.  I did a copy and paste from vtk-devel
into Insight to use a few tricks while updating Insight.  I forgot to change
the maintainer fields after the paste.

Thanks for bringing it up.

Take care, Darren



On Sun, May 10, 2009 at 11:53 AM, Peter Schmiedeskamp <
p.schmiedeskamp at auckland.ac.nz> wrote:

> Hi Everybody,
>
> I'm happy for maintenance to fall to someone else. I didn't notice this was
> going to my spam folder until today. I'll be leaving my present job soon
> (where I originally created the port) so it's probably best anyway.
>
> Cheers,
> Peter
>
> ________________________________________
> From: Ryan Schmidt [ryandesign at macports.org]
> Sent: Saturday, May 09, 2009 9:47 PM
> To: macports-dev at lists.macosforge.org; dweber at macports.org
> Cc: Peter Schmiedeskamp
> Subject: Re: [50759] trunk/dports/graphics/InsightToolkit/Portfile
>
> On May 8, 2009, at 17:29, dweber at macports.org wrote:
>
> > Revision: 50759
> >           http://trac.macports.org/changeset/50759
> > Author:   dweber at macports.org
> > Date:     2009-05-08 15:29:45 -0700 (Fri, 08 May 2009)
> > Log Message:
> > -----------
> > updated version; trying to add new variants for wrapping, etc.
>
> > Modified: trunk/dports/graphics/InsightToolkit/Portfile
>
> > -maintainers          p.schmiedeskamp at auckland.ac.nz
>
> > +maintainers     dweber openmaintainer
>
> The previous maintainer OK'd this change of maintainership? You
> didn't indicate in your commit message.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090511/702e3445/attachment.html>

From dweber at macports.org  Mon May 11 11:23:34 2009
From: dweber at macports.org (Darren Weber)
Date: Mon, 11 May 2009 11:23:34 -0700
Subject: Ruby headers?
In-Reply-To: <5cbbe4ae0905090251o16145102r43e69a6f4aaf82b2@mail.gmail.com>
References: <b808b3510905081114r76a4f23btf888747128f591f9@mail.gmail.com>
	<8143FF19-864B-4869-83EB-99E7B3121545@geeklair.net>
	<5cbbe4ae0905090251o16145102r43e69a6f4aaf82b2@mail.gmail.com>
Message-ID: <b808b3510905111123l5aad39c5n7097bca74967b615@mail.gmail.com>

>   ruby -r rbconfig -e 'puts Config::CONFIG["archdir"]'
>
> So if you write a build script you might want to reference
> it using this variable, to make it usable on systems other
> the your current one.
>
> Florian
>


How do you wrap this in tcl for macports?  I've tried all of the following:

% exec ruby -r rbconfig -e 'puts Config::CONFIG["archdir"]'
invalid command name "archdir"
% exec "ruby -r rbconfig -e 'puts Config::CONFIG["archdir"]'"
invalid command name "archdir"
% exec "ruby -r rbconfig -e 'puts Config::CONFIG[\"archdir\"]'"
invalid command name ""archdir""
% exec ruby -r rbconfig -e 'puts Config::CONFIG[\"archdir\"]'
invalid command name ""archdir""
% exec ruby -r rbconfig -e 'puts Config::CONFIG[\'archdir\']'
invalid command name "'archdir'"
% exec ruby -r rbconfig -e 'puts Config::CONFIG[archdir]'
invalid command name "archdir"
% exec ruby -r rbconfig -e 'puts Config::CONFIG\[archdir\]'
-e:1: unterminated string meets end of file
% exec ruby -r rbconfig -e 'puts Config::CONFIG\[\"archdir\"\]'
-e:1: unterminated string meets end of file
% exec "ruby -r rbconfig -e 'puts Config::CONFIG\[\"archdir\"\]'"
couldn't execute "ruby -r rbconfig -e 'puts Config::CONFIG["archdir"]'": no
such file or directory


Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090511/4719c60f/attachment.html>

From dweber at macports.org  Mon May 11 11:37:28 2009
From: dweber at macports.org (Darren Weber)
Date: Mon, 11 May 2009 11:37:28 -0700
Subject: fetch aliases?
In-Reply-To: <EF8FB9D0-48FC-4710-8939-9B514EDB39D8@gmail.com>
References: <b808b3510905071607k38f6ba12h4d796e53533a0699@mail.gmail.com>
	<77621BD7-1A42-4D97-975D-80A18F96B0DD@gmail.com>
	<b808b3510905071646x513cb3cagc13dca6132045dc0@mail.gmail.com>
	<446D4028-39CE-4824-A388-46FCC5252619@gmail.com>
	<525591C1-FAC0-4B25-ACDD-F7AEDF8765D6@macports.org>
	<b808b3510905081107s24b1034anab38af2e750298d@mail.gmail.com>
	<EF8FB9D0-48FC-4710-8939-9B514EDB39D8@gmail.com>
Message-ID: <b808b3510905111137g67db8636n21b8e8d64456fc7a@mail.gmail.com>

On Fri, May 8, 2009 at 4:05 PM, nox <n.oxyde at gmail.com> wrote:

> As far as I know, variants and other code blocks already imports
> every defined variable into the local scope, so you don't need
> to use global.
>
> Le 8 mai 09 ? 20:07, Darren Weber a ?crit :
>
>  <snip/>
>>    global itkDataPath
>> <snip/>
>>
>>
>
I'm getting a little confused.  There must be some discussion of this in
another thread.  It may be that in some places I've defined a variable
within a variant and it doesn't pass into the post-destroot of that variant,
so even though the syntax appears to wrap the post-destroot within the
variant, that's not actually what happens.  That is, this fails:

variant foo {
  set myPortLibPath ${prefix}/lib/myPort
  configure.args-append  LIB=${myPortLibPath}
  ...
  post-destroot {
     move ${build.dir}/bin/*.dylib ${myPortLibPath}
  }
}


However, I think what your saying is that this works for both the variant
and the post-destroot, without global:

set myPortLibPath ${prefix}/lib/myPort

variant foo {
  configure.args-append  LIB=${myPortLibPath}
  ...
  post-destroot {
     move ${build.dir}/bin/*.dylib ${myPortLibPath}
  }
}


Thanks, Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090511/04ef36e4/attachment.html>

From jameskyle at ucla.edu  Mon May 11 11:48:43 2009
From: jameskyle at ucla.edu (James Kyle)
Date: Mon, 11 May 2009 11:48:43 -0700
Subject: Mac Science Collaboration group
Message-ID: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>

Morning,

I'm new to the the macports dev list, but I've been actively  
maintaining a chunk of ports for about a year now and patching for  
longer (commit request pending).

I'd like to propose a new collaboration group called Mac Science that  
would, in spirit, be very similar to the Debian Science initiative.
http://wiki.debian.org/DebianScience

My incentive for this proposal is due to three observations I've made  
as mac desktop user and researcher. I also have a moderate level of  
confidence that I could enlist some level of direct apple support or  
collaboration in the project.

I welcome any and all feedback in the matter, both positive and  
negative. :)


I'll outline my incentives for the proposal below.

Issue:
"Holes" in the science library. This isn't necessarily a macports  
issue. Currently, there is no one-stop answer to a curious researcher  
on where to go for his science apps. MacPorts provides some but not by  
any means all of the usual suspects for computational work. Especially  
some of the more specialized libraries.

Solution:
A Mac Science project could specialize in these types of Port  
requests. We could host a wiki with a "provided list" and "hit list"  
of missing portfiles for developers to whittle away at including  
ticket # links and any current issues with them. The only clear  
advantage I see in this is the specialization aspect and the "one  
stop" answer to the "what does macports have for science? What does it  
need?" questions.

-------------
Issue:
Coordination between package releases and versions

When updating science oriented (math, analysis, etc) ports, I've often  
noticed a cascade effect where several other ports also require  
updating and/or patching. As these are often maintained by others,  
ensuring that everything gets updated in synchrony can be touch and go.

Solution:
A Mac Science project could have project level point releases which  
could ensure that, at any given project release, that all packages  
work well together.

---------------
Issue:
Desirability of a "one shot, up and running" collection of meta-ports.  
This is highly desirable amongst researchers. They don't just want  
numpy, they want numpy + matplotlib + scipy + pymvpa + shogun + etc  
etc. And the catch is, sometimes they don't know it. . . they just  
know they want "all that numerical stuff for python" or "all that R  
stuff for machine learning" and so on.

Solution:
This is addressed to a certain extent by variants, but meta packages  
provide a more straight shot, lower barrier to entry solution. Meta- 
packages could serve as a "best fit for most people" bundles that  
address specific areas of science. This is *highly* desirable in a lab  
environment where there are two kinds of researchers: the ones who  
"get" all this compiling, building, terminal, etc. "stuff" and those  
who often do not need or have a desire to know anything but the  
limited subset of commands they need to get their daily work done.

Cheers,

James Kyle
Center for Cognitive Neuroscience, UCLA

From n.oxyde at gmail.com  Mon May 11 12:50:12 2009
From: n.oxyde at gmail.com (nox)
Date: Mon, 11 May 2009 21:50:12 +0200
Subject: Ruby headers?
In-Reply-To: <b808b3510905111123l5aad39c5n7097bca74967b615@mail.gmail.com>
References: <b808b3510905081114r76a4f23btf888747128f591f9@mail.gmail.com>
	<8143FF19-864B-4869-83EB-99E7B3121545@geeklair.net>
	<5cbbe4ae0905090251o16145102r43e69a6f4aaf82b2@mail.gmail.com>
	<b808b3510905111123l5aad39c5n7097bca74967b615@mail.gmail.com>
Message-ID: <DEC57F56-34D8-4961-8F54-C0B735F287B5@gmail.com>

Le 11 mai 09 ? 20:23, Darren Weber a ?crit :

>
>   ruby -r rbconfig -e 'puts Config::CONFIG["archdir"]'
>
> So if you write a build script you might want to reference
> it using this variable, to make it usable on systems other
> the your current one.
>
> Florian
>
>
> How do you wrap this in tcl for macports?  I've tried all of the  
> following:
>
> % exec ruby -r rbconfig -e 'puts Config::CONFIG["archdir"]'
> invalid command name "archdir"
> % exec "ruby -r rbconfig -e 'puts Config::CONFIG["archdir"]'"
> invalid command name "archdir"
> % exec "ruby -r rbconfig -e 'puts Config::CONFIG[\"archdir\"]'"
> invalid command name ""archdir""
> % exec ruby -r rbconfig -e 'puts Config::CONFIG[\"archdir\"]'
> invalid command name ""archdir""
> % exec ruby -r rbconfig -e 'puts Config::CONFIG[\'archdir\']'
> invalid command name "'archdir'"
> % exec ruby -r rbconfig -e 'puts Config::CONFIG[archdir]'
> invalid command name "archdir"
> % exec ruby -r rbconfig -e 'puts Config::CONFIG\[archdir\]'
> -e:1: unterminated string meets end of file
> % exec ruby -r rbconfig -e 'puts Config::CONFIG\[\"archdir\"\]'
> -e:1: unterminated string meets end of file
> % exec "ruby -r rbconfig -e 'puts Config::CONFIG\[\"archdir\"\]'"
> couldn't execute "ruby -r rbconfig -e 'puts  
> Config::CONFIG["archdir"]'": no such file or directory
>

try this:
exec ruby -r rbconfig -e {puts Config::CONFIG["archdir"]}


From dweber at macports.org  Mon May 11 14:53:12 2009
From: dweber at macports.org (Darren Weber)
Date: Mon, 11 May 2009 14:53:12 -0700
Subject: Mac Science Collaboration group
In-Reply-To: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>
References: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>
Message-ID: <b808b3510905111453g564e639bud0f619970f72647e@mail.gmail.com>

Count me in.  All sounds good to me.  Not clear on the mechanics of
meta-ports (maybe they contain tcl code with exec's to call port for
installations of ports and all the variants required).  The idea of a
science milestone might work in trac (but maybe raises issues of conflicts
about whether port tickets can tag multiple milestones).

Best, Darren



On Mon, May 11, 2009 at 11:48 AM, James Kyle <jameskyle at ucla.edu> wrote:

> Morning,
>
> I'm new to the the macports dev list, but I've been actively maintaining a
> chunk of ports for about a year now and patching for longer (commit request
> pending).
>
> I'd like to propose a new collaboration group called Mac Science that
> would, in spirit, be very similar to the Debian Science initiative.
> http://wiki.debian.org/DebianScience
>
> My incentive for this proposal is due to three observations I've made as
> mac desktop user and researcher. I also have a moderate level of confidence
> that I could enlist some level of direct apple support or collaboration in
> the project.
>
> I welcome any and all feedback in the matter, both positive and negative.
> :)
>
>
> I'll outline my incentives for the proposal below.
>
> Issue:
> "Holes" in the science library. This isn't necessarily a macports issue.
> Currently, there is no one-stop answer to a curious researcher on where to
> go for his science apps. MacPorts provides some but not by any means all of
> the usual suspects for computational work. Especially some of the more
> specialized libraries.
>
> Solution:
> A Mac Science project could specialize in these types of Port requests. We
> could host a wiki with a "provided list" and "hit list" of missing portfiles
> for developers to whittle away at including ticket # links and any current
> issues with them. The only clear advantage I see in this is the
> specialization aspect and the "one stop" answer to the "what does macports
> have for science? What does it need?" questions.
>
> -------------
> Issue:
> Coordination between package releases and versions
>
> When updating science oriented (math, analysis, etc) ports, I've often
> noticed a cascade effect where several other ports also require updating
> and/or patching. As these are often maintained by others, ensuring that
> everything gets updated in synchrony can be touch and go.
>
> Solution:
> A Mac Science project could have project level point releases which could
> ensure that, at any given project release, that all packages work well
> together.
>
> ---------------
> Issue:
> Desirability of a "one shot, up and running" collection of meta-ports. This
> is highly desirable amongst researchers. They don't just want numpy, they
> want numpy + matplotlib + scipy + pymvpa + shogun + etc etc. And the catch
> is, sometimes they don't know it. . . they just know they want "all that
> numerical stuff for python" or "all that R stuff for machine learning" and
> so on.
>
> Solution:
> This is addressed to a certain extent by variants, but meta packages
> provide a more straight shot, lower barrier to entry solution. Meta-packages
> could serve as a "best fit for most people" bundles that address specific
> areas of science. This is *highly* desirable in a lab environment where
> there are two kinds of researchers: the ones who "get" all this compiling,
> building, terminal, etc. "stuff" and those who often do not need or have a
> desire to know anything but the limited subset of commands they need to get
> their daily work done.
>
> Cheers,
>
> James Kyle
> Center for Cognitive Neuroscience, UCLA
> _______________________________________________
> 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/20090511/3fdb0eca/attachment.html>

From dweber at macports.org  Mon May 11 15:23:35 2009
From: dweber at macports.org (Darren Weber)
Date: Mon, 11 May 2009 15:23:35 -0700
Subject: postgres dependency variables
Message-ID: <b808b3510905111523m49f3c5d9r8178f0d075bfe093@mail.gmail.com>

Can you see any significant problems with this code to find the current
postgre config (for a vtk-devel variant):

variant pgsql description {build the PostgreSQL driver for vtkSQLDatabase} {
    set pgconf [exec pg_config]
    set includeIdx [lsearch -regex ${pgconf} "^INCLUDEDIR"]
    set includePath [lindex ${pgconf} [expr ${includeIdx} + 2]]
    set libIdx [lsearch -regex $pgconf "^LIBDIR"]
    set libPath [lindex $pgconf [expr $libIdx + 2]]
    set libFile [exec find ${libPath} -name "libpq.dylib"]
    depends_lib-append \
        port:libpqxx
    configure.args-append \
        -DVTK_USE_POSTGRES:BOOL=ON \
        -DPOSTGRES_INCLUDE_DIRECTORIES:PATH=${includePath} \
        -DPOSTGRES_LIBRARIES:FILEPATH=${libFile}
        #// A URL for a PostgreSQL server of the form
        #// psql://[[username[:password]@]hostname[:port]]/[dbname]
        #VTK_PSQL_TEST_URL:STRING=
}


Do you think this will work for any version of postgres?  Should the variant
be version specific to a port of postgres, like postgres83 and then specify
a full path to pg_config for that port?

Thanks, Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090511/66e03e01/attachment.html>

From mdcrawford at gmail.com  Mon May 11 15:35:28 2009
From: mdcrawford at gmail.com (Michael Crawford)
Date: Mon, 11 May 2009 15:35:28 -0700
Subject: Mac Science Collaboration group
In-Reply-To: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>
References: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>
Message-ID: <dc9f86e80905111535p637c985amf853cda4d9695326@mail.gmail.com>

Apple has some scienific computing software, that is specially
optimized for the Mac OS and the processors it uses.  Here's one:

   https://www.apple.com/science/profiles/osxporting/index2.html

Try a google search for:

   mac os x high performance computing

and you'll find lots of interesting stuff.

While discussing a product idea with a friend of mine, I mentioned
that Bjarne Stroustrup was dismayed that C cannot guarantee that
arrays don't overlap - when a function receives an array as a function
argument, it's just a pointer, and there is no way of knowing whether
it points to the beginning of an array, just past the end or somewhere
in the middle.

While one can supply a length to iterate over, it's quite possible -
and common - that the whole array is larger than the given length.

But FORTRAN *does* have that guarantee, and so FORTRAN compilers can
optimize array operations in ways that C compilers - and, by extension
- C++ compilers cannot.

In The Design and Evolution of C++, Stroustrup laments that in some
cases, FORTRAN optimizers can speed up array ops by a factor of
THIRTY.  I don't think I can recall a C or C++ optimizer ever getting
so much as a factor of two improvement from unoptimized code.

So when I said all that, my friend suggested that we ought to write
our product in FORTRAN!  It would be a very numerically intensive
application, with lots of big arrays.

Now, for ease of coding and maintenance, I would prefer to write in
C++ - but FORTRAN was my first language, and I've written lots of it.
So I could see how we could write all the numerically intensive stuff
in FORTRAN.

Mike
-- 
Michael David Crawford
mdcrawford at gmail dot com

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

From jameskyle at ucla.edu  Mon May 11 16:18:05 2009
From: jameskyle at ucla.edu (James Kyle)
Date: Mon, 11 May 2009 16:18:05 -0700
Subject: Mac Science Collaboration group
In-Reply-To: <dc9f86e80905111535p637c985amf853cda4d9695326@mail.gmail.com>
References: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>
	<dc9f86e80905111535p637c985amf853cda4d9695326@mail.gmail.com>
Message-ID: <F63899B2-FFA3-4DD9-BCB7-DA258F50A937@ucla.edu>


On May 11, 2009, at 3:35 PM, Michael Crawford wrote:

> Apple has some scienific computing software, that is specially
> optimized for the Mac OS and the processors it uses.  Here's one:
>
>   https://www.apple.com/science/profiles/osxporting/index2.html
>
> Try a google search for:
>
>   mac os x high performance computing
>
> and you'll find lots of interesting stuff.

I'd also throw this link up there:
http://www.macresearch.org/

I think this site is at least partially backed by apple, we were  
contacted by our apple rep and asked to participate in the site.  
There's a lot of useful information there as well as a decent  
selection of research oriented tutorials and articles.

-james

From mdcrawford at gmail.com  Mon May 11 16:28:25 2009
From: mdcrawford at gmail.com (Michael Crawford)
Date: Mon, 11 May 2009 16:28:25 -0700
Subject: Mac Science Collaboration group
In-Reply-To: <F63899B2-FFA3-4DD9-BCB7-DA258F50A937@ucla.edu>
References: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>
	<dc9f86e80905111535p637c985amf853cda4d9695326@mail.gmail.com>
	<F63899B2-FFA3-4DD9-BCB7-DA258F50A937@ucla.edu>
Message-ID: <dc9f86e80905111628y3b5d3326q91681bd6ebbb273a@mail.gmail.com>

I did my UCSC undergraduate Physics thesis on a Monte Carlo
calculation built on CERNLIB.  It's a numerical physics library
distributed by - you guess it! - CERN.  And I got to spend the Summer
of '93 at the big accellerator lab in Geneva.  We were searching for
non-conservation of lepton number; had we actually found it, my
advisor Clem Heusch would almost certainly have gotten the Nobel
Prize.

We never did find it though.

CERNLIB can numerically calculate just about Anything Known To Man
about Physics.

It's written in FORTRAN.

I'm not real sure that it's in wide use anymore, as back then - in
1993 - the High Energy Physics community was just beginning to move to
C++.  The reason I was given was that newly entering grad students
didn't know FORTRAN anymore, as it was no longer taught to
undergraduates.  I was among the last to get FORTRAN in school, I
think.

But given all that, would anyone be interested in a CERNLIB built for Mac OS X?

Unfortunately, much of CERNLIB and its associated tools have to be
about the cruftiest, arcane, absolutely half-baked bunch of obfuscated
code I have ever had the misfortune to come across.  This because many
of its coders, being physics grad students, had no actual experience
in software engineering.

The other students were all astounded at the Beauty and the Grace of
my own FORTRAN code.  I'd been out of school for several years,
working as a coder in Silicon Valley.

I've been toying lately, with the idea of going back to school to
finally get my Physics PhD.  But not to study particle physics this
time.  Instead it would be to help develop new, non-polluting and
renewable forms of energy.

I understand that's all the rage these days.

In any case, building CERNLIB on OS X would be a good way to brush up
on so much that I've forgotten.

Mike
-- 
Michael David Crawford
mdcrawford at gmail dot com

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

From ryandesign at macports.org  Tue May 12 00:04:06 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 12 May 2009 02:04:06 -0500
Subject: [50870] trunk/dports/graphics/vtk-devel/Portfile
In-Reply-To: <20090512015914.4BC5218AE8B2@beta.macosforge.org>
References: <20090512015914.4BC5218AE8B2@beta.macosforge.org>
Message-ID: <36742676-FDDA-41C4-A3AD-C731C7C76855@macports.org>

On May 11, 2009, at 20:59, dweber at macports.org wrote:

> Revision: 50870
>           http://trac.macports.org/changeset/50870
> Author:   dweber at macports.org
> Date:     2009-05-11 18:59:13 -0700 (Mon, 11 May 2009)
> Log Message:
> -----------
> bug-fix for py26 library path; currently working on database support
>
> Modified Paths:
> --------------
>     trunk/dports/graphics/vtk-devel/Portfile
>
> Modified: trunk/dports/graphics/vtk-devel/Portfile
> ===================================================================
> --- trunk/dports/graphics/vtk-devel/Portfile	2009-05-12 01:57:43  
> UTC (rev 50869)
> +++ trunk/dports/graphics/vtk-devel/Portfile	2009-05-12 01:59:13  
> UTC (rev 50870)
> @@ -38,7 +38,7 @@
>  build.type      gnu
>  build.dir       ${workpath}/${distname}-build
>
> -# Using this dummy stage to inspect MacPorts variables (using  
> 'port -d fetch vtk-devel')
> +# Using this dummy stage to inspect macport variables (using 'port  
> -d fetch vtk-devel')
>  #fetch { system "echo ${distfiles} && echo ${checksums}" }
>
>  post-extract {
> @@ -344,11 +344,11 @@
>
>  # --- Language wrappers: java, python, tcl
>  #
> -# VTK has its own language parser, it doesn't depend on swig or  
> cableswig (as
> +# VTK has it's own language parser, it doesn't depend on swig or  
> cableswig (as
>  # of May 2009).  Since the VTK CVS repository and source  
> distributions include
>  # the output of byacc and flex, there is no need for a dependency  
> on these
>  # to build VTK.  If that were to change at some point, use byacc  
> and not bison,
> -# i.e.: depends_build-append port:byacc port:flex
> +# ie: depends_build-append port:byacc port:flex
>
>
>  variant java description {java wrapper} {
> @@ -358,7 +358,7 @@
>          -DVTK_WRAP_JAVA:BOOL=ON
>      #
>      # All of the following were detected automatically by cmake.   
> They use the
> -    # system java framework.  To replace them with a MacPorts  
> java, reset
> +    # system java framework.  To replace them with a macports  
> java, reset
>      # these variables and add the required dependencies.
>      #
>      #JAVA_ARCHIVE:FILEPATH=/usr/bin/jar
> @@ -376,7 +376,7 @@
>  # that may require separate ports because the build and install  
> process for vtk
>  # can only work with one at a time.  The build is a lengthy  
> process and there
>  # may be no easy way to short-circuit it with a dependency on a  
> prior binary
> -# install of vtk.  If there are separate ports of vtk for  
> different versions of
> +# install of vtk.  If there are seperate ports of vtk for  
> different versions of
>  # python, each port will incur a lengthy build process.  Moreover,  
> it's not
>  # clear that the install process can be specifically selected for  
> python only,
>  # without also installing all of vtk.  For that reason, it may be  
> best to avoid

The above part of your commit undid the changes I made in r50785 and  
r50786. I redid them in r50880. Please be careful to look at the diff  
before you commit and make sure every change listed is in fact one  
you intend to make with that commit.


> @@ -387,6 +387,16 @@
>  # py25 variant could disappear.  Likewise py26 could disappear if  
> vtk works in
>  # python 3.x
>
> +# Note: currently vtkpython depends on libutil and finds it in:
> +# // Utility library needed for vtkpython
> +# PYTHON_UTIL_LIBRARY:FILEPATH=/usr/lib/libutil.dylib
> +# I don't see a macport for libutil.  If one arises, it should  
> become a
> +# dependency for any python variant.
> +#
> +#// Extra libraries to link when linking to python (such as "z"  
> for zlib).  Separate multiple libraries with semicolons.
> +#PYTHON_EXTRA_LIBS:STRING=
> +#
> +
>  variant py25 conflicts py26 requires shared description {python  
> 2.5 wrapper} {
>      set pyver        2.5
>      set python       python${pyver}
> @@ -444,7 +454,7 @@
>      configure.args-append \
>          -DVTK_WRAP_PYTHON:BOOL=ON \
>          -DVTK_NO_PYTHON_THREADS:BOOL=OFF \
> -        -DPYTHON_INCLUDE_PATH:FILEPATH=${prefix}/Library/ 
> Frameworks/Python.framework/Headers \
> +        -DPYTHON_INCLUDE_PATH:FILEPATH=${prefix}/Library/ 
> Frameworks/Python.framework/Versions/${pyver}/Headers \
>          -DPYTHON_LIBRARY:FILEPATH=${prefix}/lib/lib${python}.dylib \
>          -DPYTHON_DEBUG_LIBRARY:FILEPATH=${prefix}/lib/lib$ 
> {python}.dylib \
>          -DPYTHON_EXECUTABLE:FILEPATH=${prefix}/bin/${python} \
> @@ -518,35 +528,67 @@
>
>  # --- Database variants
>
> -#
> -#variant mysql description {build the MySQL driver for  
> vtkSQLDatabase} {
> -#    depends_lib-append \
> -#        port:mysql5
> -#    configure.args-append \
> -#        -DVTK_USE_MYSQL:BOOL=ON
> -#        #MYSQL_INCLUDE_DIRECTORIES
> -#        #MYSQL_LIBRARY
> -#}
> -#
> -#
> -#variant pgsql description {build the PostgreSQL driver for  
> vtkSQLDatabase} {
> -#    depends_lib-append \
> -#        port:libpqxx
> -#    configure.args-append \
> -#        -DVTK_USE_POSTGRES:BOOL=ON
> -#        #POSTGRES_INCLUDE_DIRECTORIES
> -#        #POSTGRES_LIBRARIES
> -#}
> -#
> -#
> -#variant odbc description {build the ODBC database interface} {
> -#    depends_lib-append \
> -#        port:unixODBC
> -#    configure.args-append \
> -#        -DVTK_USE_ODBC:BOOL=ON
> -#}
>
> +variant mysql5 description {build the MySQL driver for  
> vtkSQLDatabase} {
> +    # Find the directory containing mysql.h
> +    set includePath [exec ${prefix}/bin/mysql_config5 --include]
> +    set includePath [exec ${prefix}/bin/mysql_config5 --include]
> +    set includePath [string trim ${includePath} -I ]
> +    #if [ exec find $includePath -name "mysql.h" ]
> +    set libs [exec ${prefix}/bin/mysql_config5 --libs]
> +    set libIdx [lsearch -regex $libs "${prefix}/lib/mysql"]
> +    set libPath [lindex $libs $libIdx]
> +    set libPath [string trim ${libPath} -L ]
> +    set libFile [exec find ${libPath} -name "libmysqlclient.dylib"]

Note that you shouldn't call mysql_config5 here, because mysql5 might  
not yet be installed. If it is not, an error will occur, because  
variants are evaluated before dependencies are computed.


$ sudo port deactivate mysql5
Password:
--->  Deactivating mysql5
$ port install vtk-devel +mysql5
Error: Error executing mysql5: couldn't execute "/mp/bin/ 
mysql_config5": no such file or directory
Error: Unable to open port: Error evaluating variants
$


To fix this, all the above and the configure.args-append below can be  
moved into a pre-configure block in this variant. I made this change  
in r50884.


> +    depends_build-append \
> +        path:bin/mysql_config5:mysql5
> +    depends_lib-append \
> +        port:mysql5 \
> +        port:zlib

Adding something to depends_lib is the same as adding it to  
depends_build and depends_run. Therefore there's no need to add  
mysql5 to depends_build since it's already in depends_lib. The  
preferred dependency style to use is the path: one, not the port:  
one, so that mysql5-devel could also satisfy the dependency. I fixed  
this in r50881.


> +    configure.args-append \
> +        -DVTK_USE_MYSQL:BOOL=ON \
> +        -DMYSQL_INCLUDE_DIRECTORIES:PATH=${includePath} \
> +        -DMYSQL_LIBRARY:FILEPATH=${libFile} \
> +        -DMYSQL_EXTRA_LIBRARIES:FILEPATH=${prefix}/lib/libz.dylib
> +        # A URL for a MySQL server of the form
> +        # mysql://[[username[:password]@]hostname[:port]]/[dbname]
> +        #VTK_MYSQL_TEST_URL:STRING=
> +}
>
> +
> +variant pgsql83 description {build the PostgreSQL 8.3 driver for  
> vtkSQLDatabase} {
> +    set pgconf [exec ${prefix}/lib/postgresql83/bin/pg_config ]
> +    set includeIdx [lsearch -regex ${pgconf} "^INCLUDEDIR"]
> +    set includePath [lindex ${pgconf} [expr ${includeIdx} + 2]]
> +    set libIdx [lsearch -regex $pgconf "^LIBDIR"]
> +    set libPath [lindex $pgconf [expr $libIdx + 2]]
> +    set libFile [exec find ${libPath} -name "libpq.dylib"]
> +    depends_build-append \
> +        path:lib/postgresql83/bin/pg_config:postgresql83
> +    depends_lib-append \
> +        port:postgresql83
> +    configure.args-append \
> +        -DVTK_USE_POSTGRES:BOOL=ON \
> +        -DPOSTGRES_INCLUDE_DIRECTORIES:PATH=${includePath} \
> +        -DPOSTGRES_LIBRARIES:FILEPATH=${libFile}
> +        #// A URL for a PostgreSQL server of the form
> +        #// psql://[[username[:password]@]hostname[:port]]/[dbname]
> +        #VTK_PSQL_TEST_URL:STRING=
> +}

The same comments as for the mysql5 variant apply to the pgsql83  
variant and were also fixed by r50884 and r50881.


> +
> +
> +variant odbc description {build the ODBC database interface} {
> +    depends_lib-append \
> +        port:unixODBC
> +    configure.args-append \
> +        -DVTK_USE_ODBC:BOOL=ON \
> +        -DODBC_INCLUDE_DIRECTORIES:PATH=/opt/local/include \
> +        -DODBC_LIBRARY:FILEPATH=/opt/local/lib/libodbc.dylib
> +        #// A data source name (DSN) for an ODBC database  
> connection to use for testing.
> +        #-DVTK_ODBC_TEST_DSN:STRING=
> +}

/opt/local should not be hardcoded. I changed this to ${prefix} in  
r50883.




From ryandesign at macports.org  Tue May 12 03:35:42 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 12 May 2009 05:35:42 -0500
Subject: Mac Science Collaboration group
In-Reply-To: <b808b3510905111453g564e639bud0f619970f72647e@mail.gmail.com>
References: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>
	<b808b3510905111453g564e639bud0f619970f72647e@mail.gmail.com>
Message-ID: <9AF52AB9-3DFC-4675-8F1B-A1BB5C35321F@macports.org>


On May 11, 2009, at 16:53, Darren Weber wrote:

> Not clear on the mechanics of meta-ports (maybe they contain tcl  
> code with exec's to call port for installations of ports and all  
> the variants required).

Ports should not exec port to install ports. Meta-ports just declare  
dependencies on some set of ports without themselves installing (m) 
any files (a port must however install at least 1 file or the  
destroot explodes; meta-ports thus often install just a readme).


> The idea of a science milestone might work in trac (but maybe  
> raises issues of conflicts about whether port tickets can tag  
> multiple milestones).

I don't believe a ticket can have multiple milestones, and I don't  
think we should have milestones specific to certain groups of ports.


From wsiegrist at apple.com  Tue May 12 07:08:44 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Tue, 12 May 2009 07:08:44 -0700
Subject: Mac Science Collaboration group
In-Reply-To: <9AF52AB9-3DFC-4675-8F1B-A1BB5C35321F@macports.org>
References: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>
	<b808b3510905111453g564e639bud0f619970f72647e@mail.gmail.com>
	<9AF52AB9-3DFC-4675-8F1B-A1BB5C35321F@macports.org>
Message-ID: <36881026-B637-491C-91D3-0827B28A0E80@apple.com>

On May 12, 2009, at 3:35 AM, Ryan Schmidt wrote:

>
>> The idea of a science milestone might work in trac (but maybe  
>> raises issues of conflicts about whether port tickets can tag  
>> multiple milestones).
>
> I don't believe a ticket can have multiple milestones, and I don't  
> think we should have milestones specific to certain groups of ports.
>


If you want a way to list and track science-related tickets, you can  
add a keyword such as "science" to tickets. Then you can use the  
ticket query wiki macro to list science tickets on the wiki page.  Or  
you can create a custom report that filters on the keyword (you  
probably need an admin to make the report for you).

-Bill


From jameskyle at ucla.edu  Tue May 12 07:49:53 2009
From: jameskyle at ucla.edu (James Kyle)
Date: Tue, 12 May 2009 07:49:53 -0700
Subject: Mac Science Collaboration group
In-Reply-To: <36881026-B637-491C-91D3-0827B28A0E80@apple.com>
References: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>
	<b808b3510905111453g564e639bud0f619970f72647e@mail.gmail.com>
	<9AF52AB9-3DFC-4675-8F1B-A1BB5C35321F@macports.org>
	<36881026-B637-491C-91D3-0827B28A0E80@apple.com>
Message-ID: <C7B11313-9ABF-42C2-9F50-020F2E45AD65@ucla.edu>

> If you want a way to list and track science-related tickets, you can  
> add a keyword such as "science" to tickets. Then you can use the  
> ticket query wiki macro to list science tickets on the wiki page.   
> Or you can create a custom report that filters on the keyword (you  
> probably need an admin to make the report for you).

This sounds like a perfectly fine solution. The main idea simply being  
a concerted effort toward the goal of a solid, maintained selection of  
science applications.

With the milestones, I think the idea was to present a unified front.  
Or a higher degree of certainty that any given science/analysis/math  
program will play nice with the other applications being worked on  
within "science" scope. Would there be another means of accomplishing  
this? Or would the idea of a "science tickets" wiki view be sufficient?

-james

From jmr at macports.org  Tue May 12 08:55:04 2009
From: jmr at macports.org (Joshua Root)
Date: Wed, 13 May 2009 01:55:04 +1000
Subject: Mac Science Collaboration group
In-Reply-To: <C7B11313-9ABF-42C2-9F50-020F2E45AD65@ucla.edu>
References: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>	<b808b3510905111453g564e639bud0f619970f72647e@mail.gmail.com>	<9AF52AB9-3DFC-4675-8F1B-A1BB5C35321F@macports.org>	<36881026-B637-491C-91D3-0827B28A0E80@apple.com>
	<C7B11313-9ABF-42C2-9F50-020F2E45AD65@ucla.edu>
Message-ID: <4A099BD8.3050803@macports.org>

James Kyle wrote:
>> If you want a way to list and track science-related tickets, you can
>> add a keyword such as "science" to tickets. Then you can use the
>> ticket query wiki macro to list science tickets on the wiki page.  Or
>> you can create a custom report that filters on the keyword (you
>> probably need an admin to make the report for you).
> 
> This sounds like a perfectly fine solution. The main idea simply being a
> concerted effort toward the goal of a solid, maintained selection of
> science applications.
> 
> With the milestones, I think the idea was to present a unified front. Or
> a higher degree of certainty that any given science/analysis/math
> program will play nice with the other applications being worked on
> within "science" scope. Would there be another means of accomplishing
> this? Or would the idea of a "science tickets" wiki view be sufficient?

Milestones are not tags, and Trac has recently been reconfigured to not
abuse them as such. A special keyword would be the right tool here as
Ryan suggested.

- Josh

From dweber at macports.org  Tue May 12 12:17:29 2009
From: dweber at macports.org (Darren Weber)
Date: Tue, 12 May 2009 12:17:29 -0700
Subject: Mac Science Collaboration group
In-Reply-To: <4A099BD8.3050803@macports.org>
References: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>
	<b808b3510905111453g564e639bud0f619970f72647e@mail.gmail.com>
	<9AF52AB9-3DFC-4675-8F1B-A1BB5C35321F@macports.org>
	<36881026-B637-491C-91D3-0827B28A0E80@apple.com>
	<C7B11313-9ABF-42C2-9F50-020F2E45AD65@ucla.edu>
	<4A099BD8.3050803@macports.org>
Message-ID: <b808b3510905121217g58ad59b3pa6afe0243083c737@mail.gmail.com>

On Tue, May 12, 2009 at 8:55 AM, Joshua Root <jmr at macports.org> wrote:

> James Kyle wrote:
> >> If you want a way to list and track science-related tickets, you can
> >> add a keyword such as "science" to tickets. Then you can use the
> >> ticket query wiki macro to list science tickets on the wiki page.  Or
> >> you can create a custom report that filters on the keyword (you
> >> probably need an admin to make the report for you).
> >
> > This sounds like a perfectly fine solution. The main idea simply being a
> > concerted effort toward the goal of a solid, maintained selection of
> > science applications.
> >
> > With the milestones, I think the idea was to present a unified front. Or
> > a higher degree of certainty that any given science/analysis/math
> > program will play nice with the other applications being worked on
> > within "science" scope. Would there be another means of accomplishing
> > this? Or would the idea of a "science tickets" wiki view be sufficient?
>
> Milestones are not tags, and Trac has recently been reconfigured to not
> abuse them as such. A special keyword would be the right tool here as
> Ryan suggested.
>
> - Josh
>


There is a port category for "science".  For example, although
InsightToolkit is primarily an image processing library, it contains many
"scientific" algorithms for image transformations and co-registration.  It's
primary category is "graphics", as it works on images, but in the Portfile
it can list many categories, so the current listing for this port contains:

categories       graphics math science devel

Anyhow, the purpose of the categories is to provide grouping or tagging of
ports.  A port has a primary category, and only one of these, because the
svn tree for port development is two directories deep, eg:

macports-trunk/dports/<category>/<portname>/Portfile

Hence, it's not only ports within the svn trunk or release tree under
.../dports/science/ that need to play well together.  Rather, it may be any
ports anywhere in the port tree that contain the "science" category in their
Portfile.

It may be true that category use in Portfiles is loosely defined, in the
sense that ports may be identified in some sense to belong to a field of
computing (games, office apps, editors, etc.).  I doubt that anyone uses a
category with a mindset that everything in that category should be a part of
an integrated build system.  In general, the hope is that the entire tree is
part of an integrated build system that is reliable and efficient, but to my
knowledge there is currently no focus on having within-category build
testing or anything of that sort.  A focus on science might help to direct
human resources to some extent.  From the discussion on this thread to date,
it appears the focus might be more on math than science generally.  I
suppose some intelligent analysis of the dependency tree will identify the
base libraries and applications that some large percentage of the science
apps depend on.  If those base libraries etc. are really well maintained and
build reliably and efficiently, the layers above should benefit from that.

Regards, Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090512/28eeaeea/attachment.html>

From dweber at macports.org  Tue May 12 12:26:40 2009
From: dweber at macports.org (Darren Weber)
Date: Tue, 12 May 2009 12:26:40 -0700
Subject: Mac Science Collaboration group
In-Reply-To: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>
References: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>
Message-ID: <b808b3510905121226y335e24dbk440a0a599a07861d@mail.gmail.com>

On Mon, May 11, 2009 at 11:48 AM, James Kyle <jameskyle at ucla.edu> wrote:

> Morning,
>
> I'm new to the the macports dev list, but I've been actively maintaining a
> chunk of ports for about a year now and patching for longer (commit request
> pending).
>
> I'd like to propose a new collaboration group called Mac Science that
> would, in spirit, be very similar to the Debian Science initiative.
> http://wiki.debian.org/DebianScience
>
> My incentive for this proposal is due to three observations I've made as
> mac desktop user and researcher. I also have a moderate level of confidence
> that I could enlist some level of direct apple support or collaboration in
> the project.
>
> I welcome any and all feedback in the matter, both positive and negative.
> :)
>
>
> I'll outline my incentives for the proposal below.
>
> Issue:
> "Holes" in the science library. This isn't necessarily a macports issue.
> Currently, there is no one-stop answer to a curious researcher on where to
> go for his science apps. MacPorts provides some but not by any means all of
> the usual suspects for computational work. Especially some of the more
> specialized libraries.



In considering how to introduce scientists to macports, this GUI is very
helpful:
http://www.apple.com/downloads/macosx/development_tools/porticus.html

This GUI provides a nice interface for those users who are not familiar with
the terminal.  The ports are listed by category, including a science
category.  It's not clear to me how the categories are defined (they could
be based on the port tree categories or on each Portfile entry for
"categories").

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

From dweber at macports.org  Tue May 12 12:39:14 2009
From: dweber at macports.org (Darren Weber)
Date: Tue, 12 May 2009 12:39:14 -0700
Subject: [50870] trunk/dports/graphics/vtk-devel/Portfile
In-Reply-To: <36742676-FDDA-41C4-A3AD-C731C7C76855@macports.org>
References: <20090512015914.4BC5218AE8B2@beta.macosforge.org>
	<36742676-FDDA-41C4-A3AD-C731C7C76855@macports.org>
Message-ID: <b808b3510905121239g27490f20qcaed77d4fd3db1cc@mail.gmail.com>

On Tue, May 12, 2009 at 12:04 AM, Ryan Schmidt <ryandesign at macports.org>wrote:

> On May 11, 2009, at 20:59, dweber at macports.org wrote:
>
>  Revision: 50870
>>          http://trac.macports.org/changeset/50870
>> Author:   dweber at macports.org
>> Date:     2009-05-11 18:59:13 -0700 (Mon, 11 May 2009)
>> Log Message:
>> -----------
>> bug-fix for py26 library path; currently working on database support
>>
>> Modified Paths:
>> --------------
>>    trunk/dports/graphics/vtk-devel/Portfile
>>
>> Modified: trunk/dports/graphics/vtk-devel/Portfile
>> ===================================================================
>> --- trunk/dports/graphics/vtk-devel/Portfile    2009-05-12 01:57:43 UTC
>> (rev 50869)
>> +++ trunk/dports/graphics/vtk-devel/Portfile    2009-05-12 01:59:13 UTC
>> (rev 50870)
>> @@ -38,7 +38,7 @@
>>  build.type      gnu
>>  build.dir       ${workpath}/${distname}-build
>>
>> -# Using this dummy stage to inspect MacPorts variables (using 'port -d
>> fetch vtk-devel')
>> +# Using this dummy stage to inspect macport variables (using 'port -d
>> fetch vtk-devel')
>>  #fetch { system "echo ${distfiles} && echo ${checksums}" }
>>
>>  post-extract {
>> @@ -344,11 +344,11 @@
>>
>>  # --- Language wrappers: java, python, tcl
>>  #
>> -# VTK has its own language parser, it doesn't depend on swig or cableswig
>> (as
>> +# VTK has it's own language parser, it doesn't depend on swig or
>> cableswig (as
>>  # of May 2009).  Since the VTK CVS repository and source distributions
>> include
>>  # the output of byacc and flex, there is no need for a dependency on
>> these
>>  # to build VTK.  If that were to change at some point, use byacc and not
>> bison,
>> -# i.e.: depends_build-append port:byacc port:flex
>> +# ie: depends_build-append port:byacc port:flex
>>
>>
>>  variant java description {java wrapper} {
>> @@ -358,7 +358,7 @@
>>         -DVTK_WRAP_JAVA:BOOL=ON
>>     #
>>     # All of the following were detected automatically by cmake.  They use
>> the
>> -    # system java framework.  To replace them with a MacPorts java, reset
>> +    # system java framework.  To replace them with a macports java, reset
>>     # these variables and add the required dependencies.
>>     #
>>     #JAVA_ARCHIVE:FILEPATH=/usr/bin/jar
>> @@ -376,7 +376,7 @@
>>  # that may require separate ports because the build and install process
>> for vtk
>>  # can only work with one at a time.  The build is a lengthy process and
>> there
>>  # may be no easy way to short-circuit it with a dependency on a prior
>> binary
>> -# install of vtk.  If there are separate ports of vtk for different
>> versions of
>> +# install of vtk.  If there are seperate ports of vtk for different
>> versions of
>>  # python, each port will incur a lengthy build process.  Moreover, it's
>> not
>>  # clear that the install process can be specifically selected for python
>> only,
>>  # without also installing all of vtk.  For that reason, it may be best to
>> avoid
>>
>
> The above part of your commit undid the changes I made in r50785 and
> r50786. I redid them in r50880. Please be careful to look at the diff before
> you commit and make sure every change listed is in fact one you intend to
> make with that commit.
>
>
>  @@ -387,6 +387,16 @@
>>  # py25 variant could disappear.  Likewise py26 could disappear if vtk
>> works in
>>  # python 3.x
>>
>> +# Note: currently vtkpython depends on libutil and finds it in:
>> +# // Utility library needed for vtkpython
>> +# PYTHON_UTIL_LIBRARY:FILEPATH=/usr/lib/libutil.dylib
>> +# I don't see a macport for libutil.  If one arises, it should become a
>> +# dependency for any python variant.
>> +#
>> +#// Extra libraries to link when linking to python (such as "z" for
>> zlib).  Separate multiple libraries with semicolons.
>> +#PYTHON_EXTRA_LIBS:STRING=
>> +#
>> +
>>  variant py25 conflicts py26 requires shared description {python 2.5
>> wrapper} {
>>     set pyver        2.5
>>     set python       python${pyver}
>> @@ -444,7 +454,7 @@
>>     configure.args-append \
>>         -DVTK_WRAP_PYTHON:BOOL=ON \
>>         -DVTK_NO_PYTHON_THREADS:BOOL=OFF \
>> -
>>  -DPYTHON_INCLUDE_PATH:FILEPATH=${prefix}/Library/Frameworks/Python.framework/Headers
>> \
>> +
>>  -DPYTHON_INCLUDE_PATH:FILEPATH=${prefix}/Library/Frameworks/Python.framework/Versions/${pyver}/Headers
>> \
>>         -DPYTHON_LIBRARY:FILEPATH=${prefix}/lib/lib${python}.dylib \
>>         -DPYTHON_DEBUG_LIBRARY:FILEPATH=${prefix}/lib/lib${python}.dylib \
>>         -DPYTHON_EXECUTABLE:FILEPATH=${prefix}/bin/${python} \
>> @@ -518,35 +528,67 @@
>>
>>  # --- Database variants
>>
>> -#
>> -#variant mysql description {build the MySQL driver for vtkSQLDatabase} {
>> -#    depends_lib-append \
>> -#        port:mysql5
>> -#    configure.args-append \
>> -#        -DVTK_USE_MYSQL:BOOL=ON
>> -#        #MYSQL_INCLUDE_DIRECTORIES
>> -#        #MYSQL_LIBRARY
>> -#}
>> -#
>> -#
>> -#variant pgsql description {build the PostgreSQL driver for
>> vtkSQLDatabase} {
>> -#    depends_lib-append \
>> -#        port:libpqxx
>> -#    configure.args-append \
>> -#        -DVTK_USE_POSTGRES:BOOL=ON
>> -#        #POSTGRES_INCLUDE_DIRECTORIES
>> -#        #POSTGRES_LIBRARIES
>> -#}
>> -#
>> -#
>> -#variant odbc description {build the ODBC database interface} {
>> -#    depends_lib-append \
>> -#        port:unixODBC
>> -#    configure.args-append \
>> -#        -DVTK_USE_ODBC:BOOL=ON
>> -#}
>>
>> +variant mysql5 description {build the MySQL driver for vtkSQLDatabase} {
>> +    # Find the directory containing mysql.h
>> +    set includePath [exec ${prefix}/bin/mysql_config5 --include]
>> +    set includePath [exec ${prefix}/bin/mysql_config5 --include]
>> +    set includePath [string trim ${includePath} -I ]
>> +    #if [ exec find $includePath -name "mysql.h" ]
>> +    set libs [exec ${prefix}/bin/mysql_config5 --libs]
>> +    set libIdx [lsearch -regex $libs "${prefix}/lib/mysql"]
>> +    set libPath [lindex $libs $libIdx]
>> +    set libPath [string trim ${libPath} -L ]
>> +    set libFile [exec find ${libPath} -name "libmysqlclient.dylib"]
>>
>
> Note that you shouldn't call mysql_config5 here, because mysql5 might not
> yet be installed. If it is not, an error will occur, because variants are
> evaluated before dependencies are computed.
>
>
> $ sudo port deactivate mysql5
> Password:
> --->  Deactivating mysql5
> $ port install vtk-devel +mysql5
> Error: Error executing mysql5: couldn't execute "/mp/bin/mysql_config5": no
> such file or directory
> Error: Unable to open port: Error evaluating variants
> $
>
>
> To fix this, all the above and the configure.args-append below can be moved
> into a pre-configure block in this variant. I made this change in r50884.
>
>
>  +    depends_build-append \
>> +        path:bin/mysql_config5:mysql5
>> +    depends_lib-append \
>> +        port:mysql5 \
>> +        port:zlib
>>
>
> Adding something to depends_lib is the same as adding it to depends_build
> and depends_run. Therefore there's no need to add mysql5 to depends_build
> since it's already in depends_lib. The preferred dependency style to use is
> the path: one, not the port: one, so that mysql5-devel could also satisfy
> the dependency. I fixed this in r50881.
>
>
>  +    configure.args-append \
>> +        -DVTK_USE_MYSQL:BOOL=ON \
>> +        -DMYSQL_INCLUDE_DIRECTORIES:PATH=${includePath} \
>> +        -DMYSQL_LIBRARY:FILEPATH=${libFile} \
>> +        -DMYSQL_EXTRA_LIBRARIES:FILEPATH=${prefix}/lib/libz.dylib
>> +        # A URL for a MySQL server of the form
>> +        # mysql://[[username[:password]@]hostname[:port]]/[dbname]
>> +        #VTK_MYSQL_TEST_URL:STRING=
>> +}
>>
>> +
>> +variant pgsql83 description {build the PostgreSQL 8.3 driver for
>> vtkSQLDatabase} {
>> +    set pgconf [exec ${prefix}/lib/postgresql83/bin/pg_config ]
>> +    set includeIdx [lsearch -regex ${pgconf} "^INCLUDEDIR"]
>> +    set includePath [lindex ${pgconf} [expr ${includeIdx} + 2]]
>> +    set libIdx [lsearch -regex $pgconf "^LIBDIR"]
>> +    set libPath [lindex $pgconf [expr $libIdx + 2]]
>> +    set libFile [exec find ${libPath} -name "libpq.dylib"]
>> +    depends_build-append \
>> +        path:lib/postgresql83/bin/pg_config:postgresql83
>> +    depends_lib-append \
>> +        port:postgresql83
>> +    configure.args-append \
>> +        -DVTK_USE_POSTGRES:BOOL=ON \
>> +        -DPOSTGRES_INCLUDE_DIRECTORIES:PATH=${includePath} \
>> +        -DPOSTGRES_LIBRARIES:FILEPATH=${libFile}
>> +        #// A URL for a PostgreSQL server of the form
>> +        #// psql://[[username[:password]@]hostname[:port]]/[dbname]
>> +        #VTK_PSQL_TEST_URL:STRING=
>> +}
>>
>
> The same comments as for the mysql5 variant apply to the pgsql83 variant
> and were also fixed by r50884 and r50881.
>
>
>  +
>> +
>> +variant odbc description {build the ODBC database interface} {
>> +    depends_lib-append \
>> +        port:unixODBC
>> +    configure.args-append \
>> +        -DVTK_USE_ODBC:BOOL=ON \
>> +        -DODBC_INCLUDE_DIRECTORIES:PATH=/opt/local/include \
>> +        -DODBC_LIBRARY:FILEPATH=/opt/local/lib/libodbc.dylib
>> +        #// A data source name (DSN) for an ODBC database connection to
>> use for testing.
>> +        #-DVTK_ODBC_TEST_DSN:STRING=
>> +}
>>
>
> /opt/local should not be hardcoded. I changed this to ${prefix} in r50883.
>
>
>
>

Great, thanks for the careful review Ryan!

I was wondering about the tcl exec code and whether that would work.  Maybe
it's overkill and all those paths should be coded directly for a version
specific install of mysqlX or postgresqlXY.  I was dreaming that by using
the tcl exec, with maybe a prior find within $prefix, that I could get a
version independent config for mysql and postgresql from their respective
config utilities.  There may be still a way to do that, as you point out,
using the pre-config.  The issue still remains of how to specify dependency
on version-independent mysql or postgresql - maybe it's just a dream.

Sorry about the loss of your prior changes.  I assume you did all the
updating (some of it again), so now it's all up-to-date in svn?  I'll run an
svn update and get on board with your changes.  My development practice is
to copy the svn trunk version into a local repo and work on that.  Once it's
at a point that can be checked in again, I've copied it back into the svn
checkout (overwriting the svn Portfile) and then do the svn commit.  I did
run a colordiff to check changes between my local repo and the svn update,
but I didn't notice any significant conflicts.  I'll take more time to check
it carefully.  I know this is clunky, maybe I will work directly on the svn
trunk.

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

From dweber at macports.org  Tue May 12 14:10:44 2009
From: dweber at macports.org (Darren Weber)
Date: Tue, 12 May 2009 14:10:44 -0700
Subject: how to use tcl extension: ln
Message-ID: <b808b3510905121410n26d311aaw74306cda999037d0@mail.gmail.com>

With regard to:
http://guide.macports.org/#reference.tcl-extensions

How is the ln command used?  Does it have any options, like -s for symbolic
link?

In general, how do we get help information on the macport tcl extensions,
apart from the terse descriptions in the guide?

Thanks,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090512/64b2ee4e/attachment.html>

From dweber at macports.org  Tue May 12 15:52:05 2009
From: dweber at macports.org (Darren Weber)
Date: Tue, 12 May 2009 15:52:05 -0700
Subject: Can we create proc{} Portfile?
Message-ID: <b808b3510905121552m39374acfrc302decd9ac8451f@mail.gmail.com>

Can we create a proc within a Portfile?

I'm currently using this in several places for the vtk-devel port (to set
different python version variables):

    set pyver        2.6
    set python       python${pyver}
    set pyport       [join [lrange [split ${python} .] 0 1] ""]
    set pyframe
${prefix}/Library/Frameworks/Python.framework/Versions/${pyver}


Can we create a global proc in a Portfile?  Something like this:

proc setPython { major minor } {
    global pyver python pyport pyframe
    set pyver        ${major}.${minor}
    set python       python${pyver}
    set pyport       python${major}${minor}
    set pyframe
${prefix}/Library/Frameworks/Python.framework/Versions/${pyver}
}


Regards,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090512/7373daa0/attachment.html>

From dweber at macports.org  Tue May 12 16:21:56 2009
From: dweber at macports.org (Darren Weber)
Date: Tue, 12 May 2009 16:21:56 -0700
Subject: how to control distfile extraction
Message-ID: <b808b3510905121621h54fec26dycaa8d3078757e4a4@mail.gmail.com>

In a prior thread, a solution to control distfile extraction was discussed,
using extract.only, e.g.:

variant data description {install example data [default: ${vtkDataPath}]} {
    eval extract.only   ${distfiles}
    distfiles-append    ${vtkDataFile}
    checksums-append    ${vtkDataFile} \
                            md5  283d40f3e499b3a6102d86855d2ca20b \
                            sha1 a710227e7f7f25f481a36d2fa14bda49756bd39d \
                            rmd160 160129a0580bd7b70b40d3f7fa61bbd78b586ad8
}

variant doc description {provide doxygen documentation [default:
${vtkDocPath}]} {
    eval extract.only   ${distfiles}
    distfiles-append    ${vtkDocFile}
    checksums-append    ${vtkDocFile} \
                            md5 eb8fcaa5fa8bc8f463084f071b2b978b \
                            sha1 1a8f8ff20b18bc7ac707846a8ba056b04c827392 \
                            rmd160 c657f9ce0850eca1bb0a0d7537f0bcf631132f30
}

I have the two variants defined above (plus additional post-destroot
statements).  It appears that the data distfile is still extracted.  Is it
true that the 'eval extract.only' statement can be used and effective in
multiple variants? The idea here is not to extract any of the data or doc
distfiles.

Thanks,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090512/931bc106/attachment.html>

From dweber at macports.org  Tue May 12 16:24:34 2009
From: dweber at macports.org (Darren Weber)
Date: Tue, 12 May 2009 16:24:34 -0700
Subject: how to control distfile extraction
In-Reply-To: <b808b3510905121621h54fec26dycaa8d3078757e4a4@mail.gmail.com>
References: <b808b3510905121621h54fec26dycaa8d3078757e4a4@mail.gmail.com>
Message-ID: <b808b3510905121624y2a7f5393i5dacffa89f43c452@mail.gmail.com>

On Tue, May 12, 2009 at 4:21 PM, Darren Weber <dweber at macports.org> wrote:

>
> In a prior thread, a solution to control distfile extraction was discussed,
> using extract.only, e.g.:
>
> variant data description {install example data [default: ${vtkDataPath}]} {
>     eval extract.only   ${distfiles}
>     distfiles-append    ${vtkDataFile}
>     checksums-append    ${vtkDataFile} \
>                             md5  283d40f3e499b3a6102d86855d2ca20b \
>                             sha1 a710227e7f7f25f481a36d2fa14bda49756bd39d \
>                             rmd160 160129a0580bd7b70b40d3f7fa61bbd78b586ad8
> }
>
> variant doc description {provide doxygen documentation [default:
> ${vtkDocPath}]} {
>     eval extract.only   ${distfiles}
>     distfiles-append    ${vtkDocFile}
>     checksums-append    ${vtkDocFile} \
>                             md5 eb8fcaa5fa8bc8f463084f071b2b978b \
>                             sha1 1a8f8ff20b18bc7ac707846a8ba056b04c827392 \
>                             rmd160 c657f9ce0850eca1bb0a0d7537f0bcf631132f30
> }
>
> I have the two variants defined above (plus additional post-destroot
> statements).  It appears that the data distfile is still extracted.  Is it
> true that the 'eval extract.only' statement can be used and effective in
> multiple variants? The idea here is not to extract any of the data or doc
> distfiles.
>
> Thanks,
> Darren
>
>

PS, Actually, the idea is not to even fetch the data or doc files is the
variants are not selected.  If they are selected, they should be fetched,
but not extracted, because that is handled in a post-destroot phase (where
tar is called on the ${distpath} files directly, rather than on any files
extracted to the work area).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090512/28bffcdc/attachment.html>

From dweber at macports.org  Tue May 12 16:29:00 2009
From: dweber at macports.org (Darren Weber)
Date: Tue, 12 May 2009 16:29:00 -0700
Subject: variable eval and expansion in variant descriptions
Message-ID: <b808b3510905121629w25e6a00cgabc1d5e837e4497c@mail.gmail.com>

The following example doesn't expand the variable in the results to 'port
variants <portname>'


set exDataPath ${prefix}/share/${distname}/data

variant data description {install example data [default: ${exDataPath}]} {
    ....
}

It would be nice if a user can find this installation information using
'port variants <portname>'.  I suppose 'port contents <portname>' is another
option.

Regards, Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090512/b0eed3df/attachment-0001.html>

From dweber at macports.org  Tue May 12 16:39:09 2009
From: dweber at macports.org (Darren Weber)
Date: Tue, 12 May 2009 16:39:09 -0700
Subject: Can we create proc{} Portfile?
In-Reply-To: <b808b3510905121552m39374acfrc302decd9ac8451f@mail.gmail.com>
References: <b808b3510905121552m39374acfrc302decd9ac8451f@mail.gmail.com>
Message-ID: <b808b3510905121639p378d9adewbd7148bcdde70499@mail.gmail.com>

On Tue, May 12, 2009 at 3:52 PM, Darren Weber <dweber at macports.org> wrote:

>
> Can we create a proc within a Portfile?
>
> I'm currently using this in several places for the vtk-devel port (to set
> different python version variables):
>
>     set pyver        2.6
>     set python       python${pyver}
>     set pyport       [join [lrange [split ${python} .] 0 1] ""]
>     set pyframe
> ${prefix}/Library/Frameworks/Python.framework/Versions/${pyver}
>
>
> Can we create a global proc in a Portfile?  Something like this:
>
> proc setPython { major minor } {
>     global pyver python pyport pyframe
>     set pyver        ${major}.${minor}
>     set python       python${pyver}
>     set pyport       python${major}${minor}
>     set pyframe
> ${prefix}/Library/Frameworks/Python.framework/Versions/${pyver}
> }
>
>
> Regards,
> Darren
>
>


I've tried something that is not working (it doesn't crash, but it's not
effective), i.e.:


# Set some default python variables
set pyver        2.6
set python       python${pyver}
set pyport       [join [lrange [split ${python} .] 0 1] ""]
set pyframe      Library/Frameworks/Python.framework/Versions/${pyver}
global pyver python pyport pyframe

# A function to reset the python variables
proc setPython { major minor } {
    global pyver python pyport pyframe
    set pyver        ${major}.${minor}
    set python       python${pyver}
    set pyport       python${major}${minor}
    set pyframe      Library/Frameworks/Python.framework/Versions/${pyver}
}

variant py25 conflicts py26 requires shared description {python 2.5 wrapper}
{
    pre-configure {
        setPython 2 5
    }
    #set pyver        2.5
    #set python       python${pyver}
    #set pyport       [join [lrange [split ${python} .] 0 1] ""]
    #set pyframe
${prefix}/Library/Frameworks/Python.framework/Versions/${pyver}
    depends_lib-append \
        port:${pyport}
    configure.args-delete \
        -DVTK_WRAP_PYTHON:BOOL=OFF
    configure.args-append \
        -DVTK_WRAP_PYTHON:BOOL=ON \
        -DVTK_NO_PYTHON_THREADS:BOOL=OFF \
        -DPYTHON_INCLUDE_PATH:FILEPATH=${prefix}/include/${python} \
        -DPYTHON_LIBRARY:FILEPATH=${prefix}/lib/lib${python}.dylib \
        -DPYTHON_DEBUG_LIBRARY:FILEPATH=${prefix}/lib/lib${python}.dylib \
        -DPYTHON_EXECUTABLE:FILEPATH=${prefix}/bin/${python} \
        -DVTK_PYTHON_SETUP_ARGS:STRING='--prefix=${prefix}
--root=${destroot}'
        # The VTK_PYTHON_SETUP_ARGS *MUST* be in single quotes
    post-destroot {
        # Redefine all the python variables in this clause (they are not
carried
        # through from the definitions above in the variant).
        #set pyver        2.5
        #set python       python${pyver}
        #set pyport       [join [lrange [split ${python} .] 0 1] ""]
        #set pyframe
${prefix}/Library/Frameworks/Python.framework/Versions/${pyver}
        # Reset the name of the vtkpython binary (create a symlink to the
        # version specific installation, in case other apps look for
vtkpython)
        move ${destroot}${prefix}/bin/vtkpython
${destroot}${prefix}/bin/vtk-${branch}-${pyport}
        ln -f -s ${destroot}${prefix}/bin/vtk-${branch}-${pyport}
${destroot}${prefix}/bin/vtkpython
        # Is it possible to change the python site-package name and have it
all work OK?
        # from:  /opt/local/lib/python2.6/site-packages/vtk
        # to:    /opt/local/lib/python2.6/site-packages/vtk-5.4
        # Reset the RPATH for all the python .so files
        set buildBinPath ${build.dir}/bin
        set vtkLibPath ${prefix}/lib/${distname}
        set vtkPythonPackage
${destroot}${prefix}/lib/${python}/site-packages/vtk
        foreach f [glob ${vtkPythonPackage}/*.so] {
            foreach dep [exec otool -L ${f}] {
                if [string match "*libvtk*.dylib" ${dep}] {
                    set newdep [strsed ${dep}
#${buildBinPath}#${vtkLibPath}#]
                    system "install_name_tool -change ${dep} ${newdep} ${f}"
                }
            }
        }
    }
}


What is wrong here?  Does it require global declarations in the variant?

Thanks in advance,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090512/d5f827a5/attachment.html>

From raimue at macports.org  Tue May 12 16:45:28 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Wed, 13 May 2009 01:45:28 +0200
Subject: how to use tcl extension: ln
In-Reply-To: <b808b3510905121410n26d311aaw74306cda999037d0@mail.gmail.com>
References: <b808b3510905121410n26d311aaw74306cda999037d0@mail.gmail.com>
Message-ID: <4A0A0A18.6010505@macports.org>

On 2009-05-12 23:10, Darren Weber wrote:
> With regard to:
> http://guide.macports.org/#reference.tcl-extensions
> 
> How is the ln command used?  Does it have any options, like -s for symbolic
> link?

Yes.

See
<http://trac.macports.org/browser/trunk/base/src/port1.0/portutil.tcl#L1023>

> In general, how do we get help information on the macport tcl extensions,
> apart from the terse descriptions in the guide?

If something is not documented in the guide your only chance is to find
answers in the base code itself.

Rainer

From raimue at macports.org  Tue May 12 16:54:28 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Wed, 13 May 2009 01:54:28 +0200
Subject: Mac Science Collaboration group
In-Reply-To: <36881026-B637-491C-91D3-0827B28A0E80@apple.com>
References: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>	<b808b3510905111453g564e639bud0f619970f72647e@mail.gmail.com>	<9AF52AB9-3DFC-4675-8F1B-A1BB5C35321F@macports.org>
	<36881026-B637-491C-91D3-0827B28A0E80@apple.com>
Message-ID: <4A0A0C34.8070006@macports.org>

On 2009-05-12 16:08, William Siegrist wrote:
> If you want a way to list and track science-related tickets, you can  
> add a keyword such as "science" to tickets. Then you can use the  
> ticket query wiki macro to list science tickets on the wiki page.  Or  
> you can create a custom report that filters on the keyword (you  
> probably need an admin to make the report for you).

The wiki macro for querying tickets is relatively easy  to use by
everyone. You just need to copy the query string from a custom query. So
you could add a wiki page listing all science related ports by filtering
on a keyword "science".

Reports are a little bit more flexible as they allow custom SQL, but for
most stuff the Trac query language is sufficient.

Rainer

From raimue at macports.org  Tue May 12 16:56:14 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Wed, 13 May 2009 01:56:14 +0200
Subject: Mac Science Collaboration group
In-Reply-To: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>
References: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>
Message-ID: <4A0A0C9E.8010106@macports.org>

On 2009-05-11 20:48, James Kyle wrote:
> I'm new to the the macports dev list, but I've been actively  
> maintaining a chunk of ports for about a year now and patching for  
> longer (commit request pending).
> 
> I'd like to propose a new collaboration group called Mac Science that  
> would, in spirit, be very similar to the Debian Science initiative.
> http://wiki.debian.org/DebianScience
> 
> My incentive for this proposal is due to three observations I've made  
> as mac desktop user and researcher. I also have a moderate level of  
> confidence that I could enlist some level of direct apple support or  
> collaboration in the project.

I would really appreciate such efforts. For example, we already have
groups of developers working on KDE or Ruby related ports. Developers in
these groups would just need to figure out a good way of coordinating
their work using branches, tickets and wiki pages.

Rainer

From raimue at macports.org  Tue May 12 17:05:20 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Wed, 13 May 2009 02:05:20 +0200
Subject: how to control distfile extraction
In-Reply-To: <b808b3510905121621h54fec26dycaa8d3078757e4a4@mail.gmail.com>
References: <b808b3510905121621h54fec26dycaa8d3078757e4a4@mail.gmail.com>
Message-ID: <4A0A0EC0.7000805@macports.org>

On 2009-05-13 01:21, Darren Weber wrote:
> I have the two variants defined above (plus additional post-destroot
> statements).  It appears that the data distfile is still extracted.  Is it
> true that the 'eval extract.only' statement can be used and effective in
> multiple variants? The idea here is not to extract any of the data or doc
> distfiles.

No, it is not true. Better set extract.only outside the variants. Also,
I would rather list the individual files to be extracted (but using
${distname} etc.) instead of relying on ${distfiles}.

Rainer

From raimue at macports.org  Tue May 12 17:09:00 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Wed, 13 May 2009 02:09:00 +0200
Subject: variable eval and expansion in variant descriptions
In-Reply-To: <b808b3510905121629w25e6a00cgabc1d5e837e4497c@mail.gmail.com>
References: <b808b3510905121629w25e6a00cgabc1d5e837e4497c@mail.gmail.com>
Message-ID: <4A0A0F9C.6000201@macports.org>

On 2009-05-13 01:29, Darren Weber wrote:
> The following example doesn't expand the variable in the results to 'port
> variants <portname>'
> 
> 
> set exDataPath ${prefix}/share/${distname}/data
> 
> variant data description {install example data [default: ${exDataPath}]} {
>     ....
> }
> 
> It would be nice if a user can find this installation information using
> 'port variants <portname>'.  I suppose 'port contents <portname>' is another
> option.

You are currently using {} around the description which makes Tcl treat
this as a literal string. If you want variable expansion and proc
substitution, use "" instead. Of course you need to escape any special
characters in this case.

variant data description "install example data \[default: ${exDataPath}\]" {

Rainer

From dweber at macports.org  Tue May 12 17:29:45 2009
From: dweber at macports.org (Darren Weber)
Date: Tue, 12 May 2009 17:29:45 -0700
Subject: pre-dependency phase?
Message-ID: <b808b3510905121729g376b8a1ci36d8d8ca0de41cf2@mail.gmail.com>

Perhaps entertain this idea for a few minutes and then forget about it.

The idea is to have a couple of variants for python25 and python26 in
vtk-devel.  If it works, the same logic might apply for any port that has
variants for a dependency on another version specific port, such that it
could effect multiple variants, e.g.: py25-<portname>, py26-<portname> could
be all accommodated as variants as in: port install <portname> +py25 or the
same port with python26 using: port install <portname> +py26  (I don't know
if it's possible to get both, as in: port install <portname> +py25 +py26).
Of course, let's assume that variant dependencies were possible for this to
be a potential reality (renaming all the py25-* ports would be a huge
change).


# A procedure to set or reset python variables
proc setPython { {major 2} {minor 6} } {
    global pyver python pyport pyframe
    set pyver        ${major}.${minor}
    set python       python${pyver}
    set pyport       python${major}${minor}
    set pyframe      Library/Frameworks/Python.framework/Versions/${pyver}
}
setPython

# The proc could be called from within a variant like this:
#pre-configure { setPython 2 6 }
#pre-configure { setPython }      # defaults to version 2.6

# For example,
variant py25 conflicts py26 requires shared description {python 2.5 wrapper}
{
    pre-configure { setPython 2 5 }
    depends_lib-append \
        port:${pyport}
    configure.args-delete \
        -DVTK_WRAP_PYTHON:BOOL=OFF
    configure.args-append \
        -DVTK_WRAP_PYTHON:BOOL=ON \
        -DVTK_NO_PYTHON_THREADS:BOOL=OFF \
        -DPYTHON_INCLUDE_PATH:FILEPATH=${prefix}/include/${python} \
        -DPYTHON_LIBRARY:FILEPATH=${prefix}/lib/lib${python}.dylib \
        -DPYTHON_DEBUG_LIBRARY:FILEPATH=${prefix}/lib/lib${python}.dylib \
        -DPYTHON_EXECUTABLE:FILEPATH=${prefix}/bin/${python} \
        -DVTK_PYTHON_SETUP_ARGS:STRING='--prefix=${prefix}
--root=${destroot}'
        # The VTK_PYTHON_SETUP_ARGS *MUST* be in single quotes
    post-destroot {
        # Reset the name of the vtkpython binary (create a symlink to the
        # version specific installation, in case other apps look for
vtkpython)
        move ${destroot}${prefix}/bin/vtkpython
${destroot}${prefix}/bin/vtk-${branch}-${pyport}
        ln -f -s ${destroot}${prefix}/bin/vtk-${branch}-${pyport}
${destroot}${prefix}/bin/vtkpython
        # etc
    }
}


The problem with this example is that the current port system would get
python26 in the depends-lib-append statement, which would be wrong for this
variant (right?).  Is it possible to call the setPython proc within a
variant such that all the python variables are set (or reset) before the
depends_lib-append is evaluated?  In this example, ${pyport} is python26
during the eval of depends_lib-append.  Only after pre-configure would it
become python25.  (Note this variant specifies that it conflicts with py26,
as only one can be used in the build.)

The same kind of proc might be used for things like mysql5, postgresqlXY,
etc.  In addition, within the proc, it should be possible to call things
like python_select or pg_config to init a bunch of variables for the current
version that a user has selected (if something is selected, otherwise
sensible defaults or no settings could be used in the init).

Regards,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090512/8b7250e8/attachment.html>

From jmr at macports.org  Tue May 12 17:47:00 2009
From: jmr at macports.org (Joshua Root)
Date: Wed, 13 May 2009 10:47:00 +1000
Subject: how to use tcl extension: ln
In-Reply-To: <4A0A0A18.6010505@macports.org>
References: <b808b3510905121410n26d311aaw74306cda999037d0@mail.gmail.com>
	<4A0A0A18.6010505@macports.org>
Message-ID: <4A0A1884.8000906@macports.org>

On 2009-5-13 09:45, Rainer M?ller wrote:
> On 2009-05-12 23:10, Darren Weber wrote:
>> With regard to:
>> http://guide.macports.org/#reference.tcl-extensions
>>
>> How is the ln command used?  Does it have any options, like -s for symbolic
>> link?
> 
> Yes.

Like the description says, it mimics the BSD ln command.

>> In general, how do we get help information on the macport tcl extensions,
>> apart from the terse descriptions in the guide?
> 
> If something is not documented in the guide your only chance is to find
> answers in the base code itself.

Or by experimentation. :-)

- Josh

From ryandesign at macports.org  Tue May 12 20:45:06 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 12 May 2009 22:45:06 -0500
Subject: [50870] trunk/dports/graphics/vtk-devel/Portfile
In-Reply-To: <b808b3510905121239g27490f20qcaed77d4fd3db1cc@mail.gmail.com>
References: <20090512015914.4BC5218AE8B2@beta.macosforge.org>
	<36742676-FDDA-41C4-A3AD-C731C7C76855@macports.org>
	<b808b3510905121239g27490f20qcaed77d4fd3db1cc@mail.gmail.com>
Message-ID: <719CF898-E58D-486A-90E0-DEFA271159F7@macports.org>


On May 12, 2009, at 14:39, Darren Weber wrote:

> Sorry about the loss of your prior changes.  I assume you did all  
> the updating (some of it again), so now it's all up-to-date in svn?

Yes, I re-did my changes so if you svn update you should get the latest.


From ryandesign at macports.org  Tue May 12 21:09:10 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 12 May 2009 23:09:10 -0500
Subject: [50905] trunk/dports/science
In-Reply-To: <20090512155536.A731D18FA771@beta.macosforge.org>
References: <20090512155536.A731D18FA771@beta.macosforge.org>
Message-ID: <B3D9AB36-5C60-4149-B372-C59BDCF9E2A3@macports.org>

On May 12, 2009, at 10:55, ram at macports.org wrote:

> Revision: 50905
>           http://trac.macports.org/changeset/50905
> Author:   ram at macports.org
> Date:     2009-05-12 08:55:36 -0700 (Tue, 12 May 2009)
> Log Message:
> -----------
> science/lscsoft-deps: add new lscsoft dependencies meta-port
>
> Added Paths:
> -----------
>     trunk/dports/science/lscsoft-deps/
>     trunk/dports/science/lscsoft-deps/Portfile
>
> Added: trunk/dports/science/lscsoft-deps/Portfile
> ===================================================================
> --- trunk/dports/science/lscsoft-deps/ 
> Portfile	                        (rev 0)
> +++ trunk/dports/science/lscsoft-deps/Portfile	2009-05-12 15:55:36  
> UTC (rev 50905)
> @@ -0,0 +1,51 @@
> +# $Id$
> +
> +PortSystem    1.0
> +
> +name          lscsoft-deps
> +version       20090512
> +categories    science
> +maintainers   ram
> +platforms     darwin
> +
> +description   LSCSoft dependencies meta-port
> +long_description  This is a meta-port that depends on all the ports \
> +  needed for developing LSC Software including glue, lal, and  
> lalapps.
> +
> +homepage      http://www.lsc-group.phys.uwm.edu/daswg
> +master_sites  ${homepage}
> +
> +depends_run   port:python25 \
> +              port:python_select \
> +              port:py25-numpy \
> +              port:py25-pyrxp \
> +              port:py25-socket-ssl \
> +              port:py25-m2crypto \
> +              port:pkgconfig \

This port doesn't appear to make any use of pkgconfig so I would  
delete this dependency.

If you think you must keep it, then it should be a build dependency  
and not a runtime dependency.


> +              port:fftw-3 \
> +              port:fftw-3-single \
> +              port:libframe \
> +              port:metaio \
> +              port:libxml2 \
> +              port:cfitsio \
> +              port:git-core \
> +              port:autoconf \
> +              port:automake

autoconf and automake are also likely to be build dependencies only,  
and not of this port, so I would remove these here as well.

Or maybe I don't understand the purpose of this port...


> +fetch {}
> +checksum {}

You shouldn't override the fetch or checksum phases. Instead, set  
distfiles to the empty string (write "distfiles" by itself on a line  
of the portfile).

> +build {}
> +destroot {
> +  xinstall -d ${destroot}${prefix}/share/doc/${name}-${version}
> +  system "echo ${long_description} > ${destroot}${prefix}/share/ 
> doc/${name}-${version}/README.txt"
> +}
> +
> +post-activate {
> +  ui_msg "\nTo complete the installation and prepare your system  
> for use, please run:
> +\n\tsudo python_select python25\n"
> +}
> +
> +use_configure no
> +universal_variant no
> +
> +livecheck.check none



From ram at macports.org  Tue May 12 21:39:29 2009
From: ram at macports.org (Adam Mercer)
Date: Tue, 12 May 2009 23:39:29 -0500
Subject: [50905] trunk/dports/science
In-Reply-To: <B3D9AB36-5C60-4149-B372-C59BDCF9E2A3@macports.org>
References: <20090512155536.A731D18FA771@beta.macosforge.org> 
	<B3D9AB36-5C60-4149-B372-C59BDCF9E2A3@macports.org>
Message-ID: <799406d60905122139v50efc2a8see0bff9f89ff449e@mail.gmail.com>

On Tue, May 12, 2009 at 23:09, Ryan Schmidt <ryandesign at macports.org> wrote:

Ryan

>> +depends_run ? port:python25 \
>> + ? ? ? ? ? ? ?port:python_select \
>> + ? ? ? ? ? ? ?port:py25-numpy \
>> + ? ? ? ? ? ? ?port:py25-pyrxp \
>> + ? ? ? ? ? ? ?port:py25-socket-ssl \
>> + ? ? ? ? ? ? ?port:py25-m2crypto \
>> + ? ? ? ? ? ? ?port:pkgconfig \
>
> This port doesn't appear to make any use of pkgconfig so I would delete this
> dependency.
>
> If you think you must keep it, then it should be a build dependency and not
> a runtime dependency.
>
>
>> + ? ? ? ? ? ? ?port:fftw-3 \
>> + ? ? ? ? ? ? ?port:fftw-3-single \
>> + ? ? ? ? ? ? ?port:libframe \
>> + ? ? ? ? ? ? ?port:metaio \
>> + ? ? ? ? ? ? ?port:libxml2 \
>> + ? ? ? ? ? ? ?port:cfitsio \
>> + ? ? ? ? ? ? ?port:git-core \
>> + ? ? ? ? ? ? ?port:autoconf \
>> + ? ? ? ? ? ? ?port:automake
>
> autoconf and automake are also likely to be build dependencies only, and not
> of this port, so I would remove these here as well.
>
> Or maybe I don't understand the purpose of this port...

I work in the LIGO Scientific Collaboration and the idea of this port
is so that scientists can just install one port which installs all the
dependencies required for developing the analysis software we use.
Essentially its so that I can write in the instructions install the
lscsoft-deps port instead of listing all the different ports that our
software needs.

The scientists need to check out the latest version of the software
from the git repository and therefore need autoconf and automake to
generate the build system, and our software uses pkg-config in order
to find the libraries it uses. I therefore added these as run
dependencies so that if the scientists tired to remove them port would
produce a warning saying that they were a required dependency, which
would not happen if these were set to build dependencies. This port is
just an effort to make my life easier, if you can think of a better
way to achieve this then I'd be grateful.

>> +fetch {}
>> +checksum {}
>
> You shouldn't override the fetch or checksum phases. Instead, set distfiles
> to the empty string (write "distfiles" by itself on a line of the portfile).

Thanks, I've updated it to do this in r50930.

Cheers

Adam

From ryandesign at macports.org  Tue May 12 21:47:20 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 12 May 2009 23:47:20 -0500
Subject: [50905] trunk/dports/science
In-Reply-To: <799406d60905122139v50efc2a8see0bff9f89ff449e@mail.gmail.com>
References: <20090512155536.A731D18FA771@beta.macosforge.org>
	<B3D9AB36-5C60-4149-B372-C59BDCF9E2A3@macports.org>
	<799406d60905122139v50efc2a8see0bff9f89ff449e@mail.gmail.com>
Message-ID: <F1C03856-AF56-498B-9FB2-149E1FD6B8CA@macports.org>


On May 12, 2009, at 23:39, Adam Mercer wrote:

> I work in the LIGO Scientific Collaboration and the idea of this port
> is so that scientists can just install one port which installs all the
> dependencies required for developing the analysis software we use.
> Essentially its so that I can write in the instructions install the
> lscsoft-deps port instead of listing all the different ports that our
> software needs.
>
> The scientists need to check out the latest version of the software
> from the git repository and therefore need autoconf and automake to
> generate the build system, and our software uses pkg-config in order
> to find the libraries it uses. I therefore added these as run
> dependencies so that if the scientists tired to remove them port would
> produce a warning saying that they were a required dependency, which
> would not happen if these were set to build dependencies. This port is
> just an effort to make my life easier, if you can think of a better
> way to achieve this then I'd be grateful.

Ok, so this is for installing the dependencies of software for which  
there are no ports?

Do you think there will some day be ports for that software, or is  
there a reason why that wouldn't work? (closed source, ...)

From ryandesign at macports.org  Tue May 12 22:13:13 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 13 May 2009 00:13:13 -0500
Subject: Can we create proc{} Portfile?
In-Reply-To: <b808b3510905121639p378d9adewbd7148bcdde70499@mail.gmail.com>
References: <b808b3510905121552m39374acfrc302decd9ac8451f@mail.gmail.com>
	<b808b3510905121639p378d9adewbd7148bcdde70499@mail.gmail.com>
Message-ID: <4B8B16FA-95F8-4782-8D69-D6CBB64BA6DA@macports.org>


On May 12, 2009, at 18:39, Darren Weber wrote:

> On Tue, May 12, 2009 at 3:52 PM, Darren Weber wrote:
>
>> Can we create a proc within a Portfile?

Yes, you can. You can see the not-quite-finished minivmac v3 portfile  
in my users directory in the repository for an example port that  
defines a few procedures of its own (e.g. to mount a disk image).

http://trac.macports.org/browser/users/ryandesign/minivmac/Portfile#L255


>> I'm currently using this in several places for the vtk-devel port  
>> (to set different python version variables):
>>
>>     set pyver        2.6
>>     set python       python${pyver}
>>     set pyport       [join [lrange [split ${python} .] 0 1] ""]
>>     set pyframe      ${prefix}/Library/Frameworks/Python.framework/ 
>> Versions/${pyver}
>>
>>
>> Can we create a global proc in a Portfile?  Something like this:
>>
>> proc setPython { major minor } {
>>     global pyver python pyport pyframe
>>     set pyver        ${major}.${minor}
>>     set python       python${pyver}
>>     set pyport       python${major}${minor}
>>     set pyframe      ${prefix}/Library/Frameworks/Python.framework/ 
>> Versions/${pyver}
>> }
>
>
> I've tried something that is not working (it doesn't crash, but  
> it's not effective), i.e.:
>
>
> # Set some default python variables
> set pyver        2.6
> set python       python${pyver}
> set pyport       [join [lrange [split ${python} .] 0 1] ""]
> set pyframe      Library/Frameworks/Python.framework/Versions/${pyver}
> global pyver python pyport pyframe
>
> # A function to reset the python variables
> proc setPython { major minor } {
>     global pyver python pyport pyframe
>     set pyver        ${major}.${minor}
>     set python       python${pyver}
>     set pyport       python${major}${minor}
>     set pyframe      Library/Frameworks/Python.framework/Versions/$ 
> {pyver}
> }
>
> variant py25 conflicts py26 requires shared description {python 2.5  
> wrapper} {
>     pre-configure {
>         setPython 2 5
>     }

Here you are calling your setPython proc at pre-configure time.

>     #set pyver        2.5
>     #set python       python${pyver}
>     #set pyport       [join [lrange [split ${python} .] 0 1] ""]
>     #set pyframe      ${prefix}/Library/Frameworks/Python.framework/ 
> Versions/${pyver}
>     depends_lib-append \
>         port:${pyport}

Here you are expecting the pyport variable to have been defined way  
before pre-configure time.

As long as the proc only sets variables, you can call it directly,  
outside of the pre-configure phase, and that might work. (I haven't  
tried, or completely evaluated the rest of your code.)

>     configure.args-delete \
>         -DVTK_WRAP_PYTHON:BOOL=OFF
>     configure.args-append \
>         -DVTK_WRAP_PYTHON:BOOL=ON \
>         -DVTK_NO_PYTHON_THREADS:BOOL=OFF \
>         -DPYTHON_INCLUDE_PATH:FILEPATH=${prefix}/include/${python} \
>         -DPYTHON_LIBRARY:FILEPATH=${prefix}/lib/lib${python}.dylib \
>         -DPYTHON_DEBUG_LIBRARY:FILEPATH=${prefix}/lib/lib$ 
> {python}.dylib \
>         -DPYTHON_EXECUTABLE:FILEPATH=${prefix}/bin/${python} \
>         -DVTK_PYTHON_SETUP_ARGS:STRING='--prefix=${prefix} --root=$ 
> {destroot}'
>         # The VTK_PYTHON_SETUP_ARGS *MUST* be in single quotes
>     post-destroot {
>         # Redefine all the python variables in this clause (they  
> are not carried
>         # through from the definitions above in the variant).
>         #set pyver        2.5
>         #set python       python${pyver}
>         #set pyport       [join [lrange [split ${python} .] 0 1] ""]
>         #set pyframe      ${prefix}/Library/Frameworks/ 
> Python.framework/Versions/${pyver}
>         # Reset the name of the vtkpython binary (create a symlink  
> to the
>         # version specific installation, in case other apps look  
> for vtkpython)
>         move ${destroot}${prefix}/bin/vtkpython ${destroot}$ 
> {prefix}/bin/vtk-${branch}-${pyport}
>         ln -f -s ${destroot}${prefix}/bin/vtk-${branch}-${pyport} $ 
> {destroot}${prefix}/bin/vtkpython
>         # Is it possible to change the python site-package name and  
> have it all work OK?
>         # from:  /opt/local/lib/python2.6/site-packages/vtk
>         # to:    /opt/local/lib/python2.6/site-packages/vtk-5.4
>         # Reset the RPATH for all the python .so files
>         set buildBinPath ${build.dir}/bin
>         set vtkLibPath ${prefix}/lib/${distname}
>         set vtkPythonPackage ${destroot}${prefix}/lib/${python}/ 
> site-packages/vtk
>         foreach f [glob ${vtkPythonPackage}/*.so] {
>             foreach dep [exec otool -L ${f}] {
>                 if [string match "*libvtk*.dylib" ${dep}] {
>                     set newdep [strsed ${dep} #${buildBinPath}#$ 
> {vtkLibPath}#]
>                     system "install_name_tool -change ${dep} $ 
> {newdep} ${f}"
>                 }
>             }
>         }
>     }
> }
>
>
> What is wrong here?  Does it require global declarations in the  
> variant?

I'm not sure.



From ryandesign at macports.org  Tue May 12 22:15:52 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 13 May 2009 00:15:52 -0500
Subject: fetch aliases?
In-Reply-To: <b808b3510905111137g67db8636n21b8e8d64456fc7a@mail.gmail.com>
References: <b808b3510905071607k38f6ba12h4d796e53533a0699@mail.gmail.com>
	<77621BD7-1A42-4D97-975D-80A18F96B0DD@gmail.com>
	<b808b3510905071646x513cb3cagc13dca6132045dc0@mail.gmail.com>
	<446D4028-39CE-4824-A388-46FCC5252619@gmail.com>
	<525591C1-FAC0-4B25-ACDD-F7AEDF8765D6@macports.org>
	<b808b3510905081107s24b1034anab38af2e750298d@mail.gmail.com>
	<EF8FB9D0-48FC-4710-8939-9B514EDB39D8@gmail.com>
	<b808b3510905111137g67db8636n21b8e8d64456fc7a@mail.gmail.com>
Message-ID: <DC3ABFF6-F362-46D9-835D-88B153B70C93@macports.org>


On May 11, 2009, at 13:37, Darren Weber wrote:

> I'm getting a little confused.  There must be some discussion of  
> this in another thread.  It may be that in some places I've defined  
> a variable within a variant and it doesn't pass into the post- 
> destroot of that variant, so even though the syntax appears to wrap  
> the post-destroot within the variant, that's not actually what  
> happens.  That is, this fails:
>
> variant foo {
>   set myPortLibPath ${prefix}/lib/myPort
>   configure.args-append  LIB=${myPortLibPath}
>   ...
>   post-destroot {
>      move ${build.dir}/bin/*.dylib ${myPortLibPath}
>   }
> }

I can see that it can be confusing.

What is happening is that within the variant you are declaring and  
setting a local variable (myPortLibPath). That variable ceases to  
exist once the variant has been processed. Yes, your variant lists a  
post-destroot phase, but all MacPorts does at the time that it parses  
the variant is to add that post-destroot phase to its list of things  
to do at post-destroot time. By the time that code actually gets  
executed, the myPortLibPath has long since gone out of scope.


> However, I think what your saying is that this works for both the  
> variant and the post-destroot, without global:
>
> set myPortLibPath ${prefix}/lib/myPort
>
> variant foo {
>   configure.args-append  LIB=${myPortLibPath}
>   ...
>   post-destroot {
>      move ${build.dir}/bin/*.dylib ${myPortLibPath}
>   }
> }

Yes, that will work, because here you are declaring myPortLibPath as  
a global variable, so it is available everywhere.



I don't know whether the current behavior should be considered a bug,  
but at least, that is how it behaves, so now you know.




From ram at macports.org  Wed May 13 05:29:08 2009
From: ram at macports.org (Adam Mercer)
Date: Wed, 13 May 2009 07:29:08 -0500
Subject: [50905] trunk/dports/science
In-Reply-To: <F1C03856-AF56-498B-9FB2-149E1FD6B8CA@macports.org>
References: <20090512155536.A731D18FA771@beta.macosforge.org> 
	<B3D9AB36-5C60-4149-B372-C59BDCF9E2A3@macports.org>
	<799406d60905122139v50efc2a8see0bff9f89ff449e@mail.gmail.com> 
	<F1C03856-AF56-498B-9FB2-149E1FD6B8CA@macports.org>
Message-ID: <799406d60905130529m66b5f1bbiaabcafaedae150cb@mail.gmail.com>

On Tue, May 12, 2009 at 23:47, Ryan Schmidt <ryandesign at macports.org> wrote:

> Ok, so this is for installing the dependencies of software for which there
> are no ports?
>
> Do you think there will some day be ports for that software, or is there a
> reason why that wouldn't work? (closed source, ...)

Released versions of the software in question is already available in
MacPorts (science/glue, science/lal, and science/lalapps) however at
the moment the code is under very active development and the released
versions can't really be used for anything its just too old. Things
are starting to settle down and we are hoping that released versions
will be good enough for most people in the not too distant future.

In the meantime everyone needs to run out of the git repository and
adding this "lscsoft-deps" port seemed the easiest way to get all the
necessary dependencies onto scientists machines. I did think of saying
to install the release versions and then removing them, leaving the
dependencies behind, but then people would most likely forget to
remove them and then have environment issues when the older libraries
would be picked up.

Cheers

Adam

From dluke at geeklair.net  Wed May 13 06:09:47 2009
From: dluke at geeklair.net (Daniel J. Luke)
Date: Wed, 13 May 2009 09:09:47 -0400
Subject: [50905] trunk/dports/science
In-Reply-To: <799406d60905130529m66b5f1bbiaabcafaedae150cb@mail.gmail.com>
References: <20090512155536.A731D18FA771@beta.macosforge.org>
	<B3D9AB36-5C60-4149-B372-C59BDCF9E2A3@macports.org>
	<799406d60905122139v50efc2a8see0bff9f89ff449e@mail.gmail.com>
	<F1C03856-AF56-498B-9FB2-149E1FD6B8CA@macports.org>
	<799406d60905130529m66b5f1bbiaabcafaedae150cb@mail.gmail.com>
Message-ID: <74239364-23C4-4AA6-8E13-5C132A5AB3E6@geeklair.net>

On May 13, 2009, at 8:29 AM, Adam Mercer wrote:
> In the meantime everyone needs to run out of the git repository

it's possible to create a port that fetches from git...

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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090513/27edd3cf/attachment.bin>

From ram at macports.org  Wed May 13 06:14:56 2009
From: ram at macports.org (Adam Mercer)
Date: Wed, 13 May 2009 08:14:56 -0500
Subject: [50905] trunk/dports/science
In-Reply-To: <74239364-23C4-4AA6-8E13-5C132A5AB3E6@geeklair.net>
References: <20090512155536.A731D18FA771@beta.macosforge.org> 
	<B3D9AB36-5C60-4149-B372-C59BDCF9E2A3@macports.org>
	<799406d60905122139v50efc2a8see0bff9f89ff449e@mail.gmail.com> 
	<F1C03856-AF56-498B-9FB2-149E1FD6B8CA@macports.org>
	<799406d60905130529m66b5f1bbiaabcafaedae150cb@mail.gmail.com> 
	<74239364-23C4-4AA6-8E13-5C132A5AB3E6@geeklair.net>
Message-ID: <799406d60905130614x1cddeb46p1dbf489462ce43d2@mail.gmail.com>

On Wed, May 13, 2009 at 08:09, Daniel J. Luke <dluke at geeklair.net> wrote:

>> In the meantime everyone needs to run out of the git repository
>
> it's possible to create a port that fetches from git...

I know, unfortunately there are many different branches and tags that
people need to build so a port that builds from master won't be
enough.

Cheers

Adam

From jeremy at lavergne.gotdns.org  Wed May 13 10:59:32 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Wed, 13 May 2009 13:59:32 -0400
Subject: Port depends Qt4-XXX
Message-ID: <E1018F3D-1988-42D9-8312-1F0F17043563@lavergne.gotdns.org>

If a port uses Qt 4, should I provide variants for which qt4 (kde,  
mac, x11) it uses?

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

From dweber at macports.org  Wed May 13 11:24:28 2009
From: dweber at macports.org (Darren Weber)
Date: Wed, 13 May 2009 11:24:28 -0700
Subject: Can we create proc{} Portfile?
In-Reply-To: <4B8B16FA-95F8-4782-8D69-D6CBB64BA6DA@macports.org>
References: <b808b3510905121552m39374acfrc302decd9ac8451f@mail.gmail.com>
	<b808b3510905121639p378d9adewbd7148bcdde70499@mail.gmail.com>
	<4B8B16FA-95F8-4782-8D69-D6CBB64BA6DA@macports.org>
Message-ID: <b808b3510905131124g7aaa5971g98591bff6ce508fa@mail.gmail.com>

On Tue, May 12, 2009 at 10:13 PM, Ryan Schmidt <ryandesign at macports.org>wrote:

>
> On May 12, 2009, at 18:39, Darren Weber wrote:
>
>  On Tue, May 12, 2009 at 3:52 PM, Darren Weber wrote:
>>
>>  Can we create a proc within a Portfile?
>>>
>>
> Yes, you can. You can see the not-quite-finished minivmac v3 portfile in my
> users directory in the repository for an example port that defines a few
> procedures of its own (e.g. to mount a disk image).
>
> http://trac.macports.org/browser/users/ryandesign/minivmac/Portfile#L255
>
>
>  I'm currently using this in several places for the vtk-devel port (to set
>>> different python version variables):
>>>
>>>    set pyver        2.6
>>>    set python       python${pyver}
>>>    set pyport       [join [lrange [split ${python} .] 0 1] ""]
>>>    set pyframe
>>>  ${prefix}/Library/Frameworks/Python.framework/Versions/${pyver}
>>>
>>>
>>> Can we create a global proc in a Portfile?  Something like this:
>>>
>>> proc setPython { major minor } {
>>>    global pyver python pyport pyframe
>>>    set pyver        ${major}.${minor}
>>>    set python       python${pyver}
>>>    set pyport       python${major}${minor}
>>>    set pyframe
>>>  ${prefix}/Library/Frameworks/Python.framework/Versions/${pyver}
>>> }
>>>
>>
>>
>> I've tried something that is not working (it doesn't crash, but it's not
>> effective), i.e.:
>>
>>
>> # Set some default python variables
>> set pyver        2.6
>> set python       python${pyver}
>> set pyport       [join [lrange [split ${python} .] 0 1] ""]
>> set pyframe      Library/Frameworks/Python.framework/Versions/${pyver}
>> global pyver python pyport pyframe
>>
>> # A function to reset the python variables
>> proc setPython { major minor } {
>>    global pyver python pyport pyframe
>>    set pyver        ${major}.${minor}
>>    set python       python${pyver}
>>    set pyport       python${major}${minor}
>>    set pyframe      Library/Frameworks/Python.framework/Versions/${pyver}
>> }
>>
>> variant py25 conflicts py26 requires shared description {python 2.5
>> wrapper} {
>>    pre-configure {
>>        setPython 2 5
>>    }
>>
>
> Here you are calling your setPython proc at pre-configure time.
>
>     #set pyver        2.5
>>    #set python       python${pyver}
>>    #set pyport       [join [lrange [split ${python} .] 0 1] ""]
>>    #set pyframe
>>  ${prefix}/Library/Frameworks/Python.framework/Versions/${pyver}
>>    depends_lib-append \
>>        port:${pyport}
>>
>
> Here you are expecting the pyport variable to have been defined way before
> pre-configure time.
>
> As long as the proc only sets variables, you can call it directly, outside
> of the pre-configure phase, and that might work. (I haven't tried, or
> completely evaluated the rest of your code.)
>
>
>     configure.args-delete \
>>        -DVTK_WRAP_PYTHON:BOOL=OFF
>>    configure.args-append \
>>        -DVTK_WRAP_PYTHON:BOOL=ON \
>>        -DVTK_NO_PYTHON_THREADS:BOOL=OFF \
>>        -DPYTHON_INCLUDE_PATH:FILEPATH=${prefix}/include/${python} \
>>        -DPYTHON_LIBRARY:FILEPATH=${prefix}/lib/lib${python}.dylib \
>>        -DPYTHON_DEBUG_LIBRARY:FILEPATH=${prefix}/lib/lib${python}.dylib \
>>        -DPYTHON_EXECUTABLE:FILEPATH=${prefix}/bin/${python} \
>>        -DVTK_PYTHON_SETUP_ARGS:STRING='--prefix=${prefix}
>> --root=${destroot}'
>>        # The VTK_PYTHON_SETUP_ARGS *MUST* be in single quotes
>>    post-destroot {
>>        # Redefine all the python variables in this clause (they are not
>> carried
>>        # through from the definitions above in the variant).
>>        #set pyver        2.5
>>        #set python       python${pyver}
>>        #set pyport       [join [lrange [split ${python} .] 0 1] ""]
>>        #set pyframe
>>  ${prefix}/Library/Frameworks/Python.framework/Versions/${pyver}
>>        # Reset the name of the vtkpython binary (create a symlink to the
>>        # version specific installation, in case other apps look for
>> vtkpython)
>>        move ${destroot}${prefix}/bin/vtkpython
>> ${destroot}${prefix}/bin/vtk-${branch}-${pyport}
>>        ln -f -s ${destroot}${prefix}/bin/vtk-${branch}-${pyport}
>> ${destroot}${prefix}/bin/vtkpython
>>        # Is it possible to change the python site-package name and have it
>> all work OK?
>>        # from:  /opt/local/lib/python2.6/site-packages/vtk
>>        # to:    /opt/local/lib/python2.6/site-packages/vtk-5.4
>>        # Reset the RPATH for all the python .so files
>>        set buildBinPath ${build.dir}/bin
>>        set vtkLibPath ${prefix}/lib/${distname}
>>        set vtkPythonPackage
>> ${destroot}${prefix}/lib/${python}/site-packages/vtk
>>        foreach f [glob ${vtkPythonPackage}/*.so] {
>>            foreach dep [exec otool -L ${f}] {
>>                if [string match "*libvtk*.dylib" ${dep}] {
>>                    set newdep [strsed ${dep}
>> #${buildBinPath}#${vtkLibPath}#]
>>                    system "install_name_tool -change ${dep} ${newdep}
>> ${f}"
>>                }
>>            }
>>        }
>>    }
>> }
>>
>>
>> What is wrong here?  Does it require global declarations in the variant?
>>
>
> I'm not sure.
>
>
>


The following is working:


# A function to set or reset python variables (defaults to version 2.6)
proc setPython { {major 2} {minor 6} } {
    global pyver python pyport pyframe
    set pyver        ${major}.${minor}
    set python       python${pyver}
    set pyport       python${major}${minor}
    set pyframe      Library/Frameworks/Python.framework/Versions/${pyver}
}
# Initialize the global variables for python26
setPython
# This proc is called from within pyXY variants like this:
#setPython X Y


variant py25 conflicts py26 requires shared description {python 2.5 wrapper}
{
    # Note that python25 is NOT installed as a framework (May 2009)
    setPython 2 5
    depends_lib-append \
        port:${pyport}
    configure.args-delete \
        -DVTK_WRAP_PYTHON:BOOL=OFF
    configure.args-append \
        -DVTK_WRAP_PYTHON:BOOL=ON \
        -DVTK_NO_PYTHON_THREADS:BOOL=OFF \
        -DPYTHON_INCLUDE_PATH:FILEPATH=${prefix}/include/${python} \
        -DPYTHON_LIBRARY:FILEPATH=${prefix}/lib/lib${python}.dylib \
        -DPYTHON_DEBUG_LIBRARY:FILEPATH=${prefix}/lib/lib${python}.dylib \
        -DPYTHON_EXECUTABLE:FILEPATH=${prefix}/bin/${python} \
        -DVTK_PYTHON_SETUP_ARGS:STRING='--prefix=${prefix}
--root=${destroot}'
        # The VTK_PYTHON_SETUP_ARGS *MUST* be in single quotes
    post-destroot {
        setPython 2 5
        # Reset the name of the vtkpython binary (create a symlink to the
        # version specific installation, in case other apps look for
vtkpython)
        move ${destroot}${prefix}/bin/vtkpython
${destroot}${prefix}/bin/vtk-${branch}-${pyport}
        ln -f -s ${destroot}${prefix}/bin/vtk-${branch}-${pyport}
${destroot}${prefix}/bin/vtkpython
        # Reset the RPATH for all the python .so files
        set buildBinPath ${build.dir}/bin
        set vtkLibPath ${prefix}/lib/${distname}
        set vtkSitePackage
${destroot}/${prefix}/lib/${python}/site-packages/vtk
        foreach f [glob ${vtkSitePackage}/*.so] {
            foreach dep [exec otool -L ${f}] {
                if [string match "*libvtk*.dylib" ${dep}] {
                    set newdep [strsed ${dep}
#${buildBinPath}#${vtkLibPath}#]
                    system "install_name_tool -change ${dep} ${newdep} ${f}"
                }
            }
        }
    }
}



Regards,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090513/61038e32/attachment-0001.html>

From dweber at macports.org  Wed May 13 14:56:32 2009
From: dweber at macports.org (Darren Weber)
Date: Wed, 13 May 2009 14:56:32 -0700
Subject: port outdated parse error?
Message-ID: <b808b3510905131456k6993553aicb29cb455aeec40@mail.gmail.com>

Just noticed this from 'port outdated'

libtheora                      1.0_0 < 1.0_0

Appears to be a glitch somewhere in port or libtheora.

Regards, Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090513/0362ef0c/attachment.html>

From jeremy at lavergne.gotdns.org  Wed May 13 15:18:03 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Wed, 13 May 2009 18:18:03 -0400
Subject: port outdated parse error?
In-Reply-To: <b808b3510905131456k6993553aicb29cb455aeec40@mail.gmail.com>
References: <b808b3510905131456k6993553aicb29cb455aeec40@mail.gmail.com>
Message-ID: <2ED6D9B7-6E5B-42EB-B38B-97D2BC4DDB17@lavergne.gotdns.org>

The epoch for the port is set to 1, so it shows up as outdated from  
your epoch 0 version.

On May 13, 2009, at 5:56 PM, Darren Weber wrote:

> libtheora                      1.0_0 < 1.0_0


From raimue at macports.org  Wed May 13 15:21:57 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Thu, 14 May 2009 00:21:57 +0200
Subject: port outdated parse error?
In-Reply-To: <b808b3510905131456k6993553aicb29cb455aeec40@mail.gmail.com>
References: <b808b3510905131456k6993553aicb29cb455aeec40@mail.gmail.com>
Message-ID: <4A0B4805.8050209@macports.org>

On 2009-05-13 23:56, Darren Weber wrote:
> Just noticed this from 'port outdated'
> 
> libtheora                      1.0_0 < 1.0_0

libtheora has recently seen an epoch increment after a wrong update has
been committed. This port is now considered outdated for everyone as the
epoch is being used in the version comparison.

See also the pending patch in #19138 [1] to make 'port outdated' show an
indicator what is going on.

Rainer

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

From raimue at macports.org  Wed May 13 15:42:01 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Thu, 14 May 2009 00:42:01 +0200
Subject: port outdated parse error?
In-Reply-To: <4A0B4805.8050209@macports.org>
References: <b808b3510905131456k6993553aicb29cb455aeec40@mail.gmail.com>
	<4A0B4805.8050209@macports.org>
Message-ID: <4A0B4CB9.9070502@macports.org>

On 2009-05-14 00:21, Rainer M?ller wrote:
> libtheora has recently seen an epoch increment after a wrong update has
> been committed. This port is now considered outdated for everyone as the
> epoch is being used in the version comparison.

Small correction: There was no revert, but an upgrade from version
1.0beta3 to 1.0. So the versioning scheme changed and therefore required
the epoch increment.

Rainer

From raimue at macports.org  Wed May 13 16:49:44 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Thu, 14 May 2009 01:49:44 +0200
Subject: [50947] trunk/dports/devel
In-Reply-To: <20090513232230.EAE431955144@beta.macosforge.org>
References: <20090513232230.EAE431955144@beta.macosforge.org>
Message-ID: <4A0B5C98.6070902@macports.org>

On 2009-05-14 01:22, dweber at macports.org wrote:
> +name        cableswig
> +version     cvs
> +# CableSwig is only available from cvs and there are no release tags

You could use cvs.date to pin it to a more specific version.

Rainer

From ryandesign at macports.org  Wed May 13 17:05:50 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 13 May 2009 19:05:50 -0500
Subject: [50947] trunk/dports/devel
In-Reply-To: <20090513232230.EAE431955144@beta.macosforge.org>
References: <20090513232230.EAE431955144@beta.macosforge.org>
Message-ID: <C9E2EC84-9486-4624-B5C2-C5B1EABE7EB2@macports.org>

On May 13, 2009, at 18:22, dweber at macports.org wrote:

> Revision: 50947
>           http://trac.macports.org/changeset/50947
> Author:   dweber at macports.org
> Date:     2009-05-13 16:22:30 -0700 (Wed, 13 May 2009)
> Log Message:
> -----------
> new port for CableSwig
>
> Added Paths:
> -----------
>     trunk/dports/devel/cableswig/
>     trunk/dports/devel/cableswig/Portfile
>
> Added: trunk/dports/devel/cableswig/Portfile
> ===================================================================
> --- trunk/dports/devel/cableswig/Portfile	                         
> (rev 0)
> +++ trunk/dports/devel/cableswig/Portfile	2009-05-13 23:22:30 UTC  
> (rev 50947)
> @@ -0,0 +1,60 @@
> +# -*- 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        cableswig
> +version     cvs
> +# CableSwig is only available from cvs and there are no release tags

[snip]

> +fetch.type      cvs
> +cvs.root        :pserver:anonymous at public.kitware.com:/cvsroot/ 
> CableSwig
> +cvs.module      CableSwig

It looks like this port is downloading from cvs head, meaning if you  
install the port today, and then some more development occurs, and I  
install the port tomorrow, we have different versions of software  
installed on our computers, though we installed the same  
"version" ("cvs") of the port. This isn't how ports should work.  
Ports should install the same software on everyone's computer.

As Rainer said, you should restrict the date of the cvs checkout to  
some specific date that you know to work properly. You can use that  
in the "version" variable too. (So then "version" will be something  
like "20090513".)

I think you will then have to increase the epoch so that MacPorts  
knows that your new version number is supposed to be treated as newer  
than the string "cvs".


> +configure {
> +    xinstall -d -o root -g admin -m 0755 ${build.dir}

Is it really necessary to make this directory as root? Some of us  
prefer using MacPorts in a prefix that is not owned by root, and the  
above will cause this port to fail for us.


> +    system "cd ${build.dir} && cmake ${configure.args} $ 
> {worksrcpath}"
> +}
> +
> +configure.args \
> +    -DCMAKE_OSX_SYSROOT=${universal_sysroot} \
> +    -DCMAKE_BUILD_TYPE:STRING=Release \
> +    -DBUILD_SHARED_LIBS:BOOL=ON \
> +    -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON \
> +    -DCMAKE_INSTALL_RPATH:STRING=${prefix}/lib/cableswig \
> +    -DCMAKE_INSTALL_PREFIX:PATH=${prefix} \
> +    -DCMAKE_INCLUDE_PATH:PATH=${prefix}/include \
> +    -DCMAKE_LIBRARY_PATH:PATH=${prefix}/lib \
> +    -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON \
> +    -DCSWIG_USE_SYSTEM_GCCXML:BOOL=ON

Have you tried using the cmake portgroup yet? It should simplify  
ports that use cmake to build.







From ryandesign at macports.org  Wed May 13 17:07:52 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 13 May 2009 19:07:52 -0500
Subject: Port depends Qt4-XXX
In-Reply-To: <E1018F3D-1988-42D9-8312-1F0F17043563@lavergne.gotdns.org>
References: <E1018F3D-1988-42D9-8312-1F0F17043563@lavergne.gotdns.org>
Message-ID: <96F8FDC4-394E-4690-BB35-035F44E9A857@macports.org>


On May 13, 2009, at 12:59, Jeremy Lavergne wrote:

> If a port uses Qt 4, should I provide variants for which qt4 (kde,  
> mac, x11) it uses?

qt4-kde exists only because kde ports are currently incompatible with  
qt4 4.5. So qt4-kde was created for version 4.4. Presumably if your  
port is a kde port, you will need to use qt4-kde. And if your port is  
not a kde port, you should not use qt4-kde.

As for qt4-mac vs qt4-x11, I'm not sure how other ports have been  
handling that. You could grep the portfiles to find out.




From ryandesign at macports.org  Wed May 13 20:35:28 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 13 May 2009 22:35:28 -0500
Subject: can't read "configure.universal_ldflags": no such variable
In-Reply-To: <6F1859E6-412B-4195-B936-FBC6CA96F2A0@macports.org>
References: <6F1859E6-412B-4195-B936-FBC6CA96F2A0@macports.org>
Message-ID: <F5C13EBE-2335-4AAE-B6A9-A147185B85E1@macports.org>


On Apr 21, 2009, at 08:37, Ryan Schmidt wrote:

> I am having trouble upgrading an increasing number of ports (for  
> example whois, glib2, python25). I'm only seeing this problem on  
> one machine, as far as I can tell, which is running Mac OS X  
> 10.4.11 Intel, Xcode 2.5, MacPorts 1.7.1. Any ideas? Is anyone else  
> seeing this?
>
>
> $ port -uxd upgrade whois

[snip]

> DEBUG: can't read "configure.universal_ldflags": no such variable
>     while executing
> "eval configure.ldflags-append   ${configure.universal_ldflags}"
>     (procedure "variant-universal" line 18)
>     invoked from within
> "variant-universal"
>     invoked from within
> "catch "variant-${name}" result"
> Error: Error executing universal: can't read  
> "configure.universal_ldflags": no such variable
> DEBUG: Error evaluating variants
>     while executing
> "error "Error evaluating variants""
>     (procedure "mportopen" line 57)
>     invoked from within
> "mportopen $porturl $options $variations"
>     (procedure "mportdepends" line 66)
>     invoked from within
> "mportdepends $mport $target"
>     (procedure "mportexec" line 23)
>     invoked from within
> "mportexec $workername $upgrade_action"
> Error: Unable to upgrade port: Error evaluating variants
> $


I have continued to experience this problem since I originally  
reported it and have just been dealing with not being able to upgrade  
some of my ports.

I have now figured out the problem, and it looks like it will not  
manifest on PowerPC or Leopard machines, at least not with MacPorts  
1.7.x, which explains why Joshua wasn't able to duplicate it on Tiger  
on PowerPC.

First, consider MacPorts 1.7.1's configure_get_universal_ldflags  
procedure:

http://trac.macports.org/browser/tags/release_1_7_1/base/src/port1.0/ 
portconfigure.tcl#L241

As you can see, the universal_ldflags will always end up containing  
the arch flags. On PowerPC, an additional part is appended. On  
Leopard, a different additional part is appended. The extra Leopard  
part has already been removed from trunk

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

so I think users of trunk would also experience the issue on Leopard,  
if they are not on PowerPC.

The problem lies in these lines of the muniversal portgroup:

http://trac.macports.org/browser/trunk/dports/_resources/port1.0/ 
group/muniversal-1.0.tcl?rev=49951#L91

     foreach arch ${universal_archs} {
         configure.universal_cflags-delete    -arch ${arch}
         configure.universal_cxxflags-delete  -arch ${arch}
         configure.universal_ldflags-delete   -arch ${arch}
     }

On non-PowerPC non-Leopard, this will end up with universal_ldflags  
becoming empty, which will cause it to be unset entirely. Therefore  
an error occurs when we then try to append the now-nonexistent  
universal_ldflags to configure.ldflags below:

     eval configure.args-append      ${configure.universal_args}
     eval configure.cflags-append    ${configure.universal_cflags}
     eval configure.cxxflags-append  ${configure.universal_cxxflags}
     eval configure.objcflags-append ${configure.universal_cflags}
     eval configure.ldflags-append   ${configure.universal_ldflags}
     eval configure.cppflags-append  ${configure.universal_cppflags}

This change is the one that caused the problem:

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

If I revert that, things work again.




From jmr at macports.org  Wed May 13 20:49:40 2009
From: jmr at macports.org (Joshua Root)
Date: Thu, 14 May 2009 13:49:40 +1000
Subject: can't read "configure.universal_ldflags": no such variable
In-Reply-To: <F5C13EBE-2335-4AAE-B6A9-A147185B85E1@macports.org>
References: <6F1859E6-412B-4195-B936-FBC6CA96F2A0@macports.org>
	<F5C13EBE-2335-4AAE-B6A9-A147185B85E1@macports.org>
Message-ID: <4A0B94D4.6030400@macports.org>

On 2009-5-14 13:35, Ryan Schmidt wrote:
> 
> On Apr 21, 2009, at 08:37, Ryan Schmidt wrote:
> 
> As you can see, the universal_ldflags will always end up containing the
> arch flags. On PowerPC, an additional part is appended. On Leopard, a
> different additional part is appended. The extra Leopard part has
> already been removed from trunk
> 
> http://trac.macports.org/changeset/46451
> 
> so I think users of trunk would also experience the issue on Leopard, if
> they are not on PowerPC.
[snip]
> 
> On non-PowerPC non-Leopard, this will end up with universal_ldflags
> becoming empty, which will cause it to be unset entirely. Therefore an
> error occurs when we then try to append the now-nonexistent
> universal_ldflags to configure.ldflags below:

Actually, the option-delete behaviour didn't make much sense, so it was
changed: <http://trac.macports.org/changeset/44901>

- Josh

From ryandesign at macports.org  Wed May 13 21:11:15 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 13 May 2009 23:11:15 -0500
Subject: can't read "configure.universal_ldflags": no such variable
In-Reply-To: <4A0B94D4.6030400@macports.org>
References: <6F1859E6-412B-4195-B936-FBC6CA96F2A0@macports.org>
	<F5C13EBE-2335-4AAE-B6A9-A147185B85E1@macports.org>
	<4A0B94D4.6030400@macports.org>
Message-ID: <07E42C69-4825-4A13-9B96-5F14DAC91594@macports.org>

On May 13, 2009, at 22:49, Joshua Root wrote:

> On 2009-5-14 13:35, Ryan Schmidt wrote:
>
>> On Apr 21, 2009, at 08:37, Ryan Schmidt wrote:
>>
>> As you can see, the universal_ldflags will always end up  
>> containing the
>> arch flags. On PowerPC, an additional part is appended. On Leopard, a
>> different additional part is appended. The extra Leopard part has
>> already been removed from trunk
>>
>> http://trac.macports.org/changeset/46451
>>
>> so I think users of trunk would also experience the issue on  
>> Leopard, if
>> they are not on PowerPC.
> [snip]
>>
>> On non-PowerPC non-Leopard, this will end up with universal_ldflags
>> becoming empty, which will cause it to be unset entirely.  
>> Therefore an
>> error occurs when we then try to append the now-nonexistent
>> universal_ldflags to configure.ldflags below:
>
> Actually, the option-delete behaviour didn't make much sense, so it  
> was
> changed: <http://trac.macports.org/changeset/44901>

Ok, that's good. I wasn't sure if there was a reason for that  
behavior. I guess, if there was, it wasn't important anymore.

This still means that no Intel Tiger users can build universal  
versions of ports that use the muniversal portgroup until MacPorts  
1.8.0 is released, unless this issue is fixed in some other way in  
the muniversal portgroup.

Or we could release 1.8.0 soon, or we could backport this fix to the  
1.7 branch and release a 1.7.2 soon...


From blb at macports.org  Wed May 13 23:20:27 2009
From: blb at macports.org (Bryan Blackburn)
Date: Thu, 14 May 2009 00:20:27 -0600
Subject: New wiki page PortfileRecipes
Message-ID: <20090514062027.GM69468@ninagal.withay.com>

FYI I've added a new wiki page:

<http://trac.macports.org/wiki/PortfileRecipes>

The basic idea being to list certain otherwise-undocumented best practices
that come up from time to time.  Many techniques may have the basic commands
documented (like reinplace) but some of the common uses aren't, so these
bits tend to come up from time to time on the list.

One important thing I think for this page is to always have examples or
references to actual ports using the given technique (or both) to help with
those new to creating ports.

Obviously some which aren't "failures" in port can be moved to the guide
when cleaned up and whatnot, others should probably have tickets if they
don't already, and the rest probably can become integrated where needed.

Bryan


From jameskyle at ucla.edu  Thu May 14 09:30:28 2009
From: jameskyle at ucla.edu (James Kyle)
Date: Thu, 14 May 2009 09:30:28 -0700
Subject: Mac Science Collaboration group
In-Reply-To: <4A0A0C9E.8010106@macports.org>
References: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>
	<4A0A0C9E.8010106@macports.org>
Message-ID: <3FF9E3CB-9E08-4D22-AB4B-3CB4BE5ED320@ucla.edu>

> I would really appreciate such efforts. For example, we already have
> groups of developers working on KDE or Ruby related ports.  
> Developers in
> these groups would just need to figure out a good way of coordinating
> their work using branches, tickets and wiki pages.
>
> Rainer

What would be the next step towards making this a reality for macports?

-james

From dweber at macports.org  Thu May 14 13:02:35 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 14 May 2009 13:02:35 -0700
Subject: [50947] trunk/dports/devel
In-Reply-To: <C9E2EC84-9486-4624-B5C2-C5B1EABE7EB2@macports.org>
References: <20090513232230.EAE431955144@beta.macosforge.org>
	<C9E2EC84-9486-4624-B5C2-C5B1EABE7EB2@macports.org>
Message-ID: <b808b3510905141302y2686b3c7pa935001b31e6ac70@mail.gmail.com>

On Wed, May 13, 2009 at 5:05 PM, Ryan Schmidt <ryandesign at macports.org>wrote:

> On May 13, 2009, at 18:22, dweber at macports.org wrote:
>
>  Revision: 50947
>>          http://trac.macports.org/changeset/50947
>> Author:   dweber at macports.org
>> Date:     2009-05-13 16:22:30 -0700 (Wed, 13 May 2009)
>> Log Message:
>> -----------
>> new port for CableSwig
>>
>> Added Paths:
>> -----------
>>    trunk/dports/devel/cableswig/
>>    trunk/dports/devel/cableswig/Portfile
>>
>> Added: trunk/dports/devel/cableswig/Portfile
>> ===================================================================
>> --- trunk/dports/devel/cableswig/Portfile
>> (rev 0)
>> +++ trunk/dports/devel/cableswig/Portfile       2009-05-13 23:22:30 UTC
>> (rev 50947)
>> @@ -0,0 +1,60 @@
>> +# -*- 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        cableswig
>> +version     cvs
>> +# CableSwig is only available from cvs and there are no release tags
>>
>
> [snip]
>
>  +fetch.type      cvs
>> +cvs.root        :pserver:anonymous at public.kitware.com:/cvsroot/CableSwig
>> +cvs.module      CableSwig
>>
>
> It looks like this port is downloading from cvs head, meaning if you
> install the port today, and then some more development occurs, and I install
> the port tomorrow, we have different versions of software installed on our
> computers, though we installed the same "version" ("cvs") of the port. This
> isn't how ports should work. Ports should install the same software on
> everyone's computer.
>
> As Rainer said, you should restrict the date of the cvs checkout to some
> specific date that you know to work properly. You can use that in the
> "version" variable too. (So then "version" will be something like
> "20090513".)
>
> I think you will then have to increase the epoch so that MacPorts knows
> that your new version number is supposed to be treated as newer than the
> string "cvs".



If cableswig is not yet in the rsync release, can I just replace the svn
with a new version and skip the epoch definition?

How does this comparison work out?  Do we actually get lucky with an upgrade
in this case?

version 20090514

vs

version cvs_0





>
>
>
>  +configure {
>> +    xinstall -d -o root -g admin -m 0755 ${build.dir}
>>
>
> Is it really necessary to make this directory as root? Some of us prefer
> using MacPorts in a prefix that is not owned by root, and the above will
> cause this port to fail for us.
>



I guess not.  Seems to work without it, so it can go.




>  +    system "cd ${build.dir} && cmake ${configure.args} ${worksrcpath}"
>> +}
>> +
>> +configure.args \
>> +    -DCMAKE_OSX_SYSROOT=${universal_sysroot} \
>> +    -DCMAKE_BUILD_TYPE:STRING=Release \
>> +    -DBUILD_SHARED_LIBS:BOOL=ON \
>> +    -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON \
>> +    -DCMAKE_INSTALL_RPATH:STRING=${prefix}/lib/cableswig \
>> +    -DCMAKE_INSTALL_PREFIX:PATH=${prefix} \
>> +    -DCMAKE_INCLUDE_PATH:PATH=${prefix}/include \
>> +    -DCMAKE_LIBRARY_PATH:PATH=${prefix}/lib \
>> +    -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON \
>> +    -DCSWIG_USE_SYSTEM_GCCXML:BOOL=ON
>>
>
> Have you tried using the cmake portgroup yet? It should simplify ports that
> use cmake to build.
>


I did consider it for vtk-devel, where it doesn't apply exactly.  I figure
it's clearer to define everything directly.  It will avoid dependency on the
port group, which could change at some point.  There are some overlaps in
this port and the port group (as it stands), but ... the dependency seems
like just another layer of complexity for management (in my view).  The
configure is fairly simple in this port and it's all right there in front of
me when it's all in the port (no need to lookup the port group or worry
about it changing).

The port group abstraction may be useful.  Maybe I'll change my mind some
day ;-)

Best, Darren


PS, There is an issue with this port for cableswig, i.e.:

[ dweber at X ~/ports ]$ cswig
Cannot find SWIG Lib directory.  Checked:

/opt/local/var/macports/build/_Users_dweber_ports_devel_cableswig/work/cableswig-20090514/SWIG/Lib
[ dweber at X ~/ports ]$
[ dweber at X ~/ports ]$ otool -L /opt/local/bin/cswig
/opt/local/bin/cswig:
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version
7.4.0)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
111.1.3)

I have no idea how to correct this, got to check back with the ITK crew on
what's going on here.  Good reason for a ticket on this one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090514/615175f1/attachment.html>

From vincent-opdarw at vinc17.org  Thu May 14 14:45:37 2009
From: vincent-opdarw at vinc17.org (Vincent Lefevre)
Date: Thu, 14 May 2009 23:45:37 +0200
Subject: [50984] trunk/dports
In-Reply-To: <20090514210915.0335F19AE40B@beta.macosforge.org>
References: <20090514210915.0335F19AE40B@beta.macosforge.org>
Message-ID: <20090514214537.GA1221@prunille.vinc17.org>

On 2009-05-14 14:08:45 -0700, and.damore at macports.org wrote:
> Revision: 50984
>           http://trac.macports.org/changeset/50984
> Author:   and.damore at macports.org
> Date:     2009-05-14 14:08:43 -0700 (Thu, 14 May 2009)
> Log Message:
> -----------
> Maintainer email change, second batch, mail without @macpors.org domain are put in domain:user form.

There seems to be a problem with this change:

Index: graphics/optipng/Portfile
===================================================================
--- graphics/optipng/Portfile   (revision 50983)
+++ graphics/optipng/Portfile   (revision 50984)
@@ -6,7 +6,7 @@
 version         0.6.2
 revision        1
 categories      graphics
-maintainers     vincent-opdarw at vinc17.org
+maintainers     vincent-vinc17.org:opdarw
 description     PNG file optimizer
 long_description \
         OptiPNG is a PNG optimizer that recompresses the image files to a \

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

From dweber at macports.org  Thu May 14 16:39:19 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 14 May 2009 16:39:19 -0700
Subject: symlink for g++ broken link to /usr/bin/bin/g+cc-4.0
Message-ID: <b808b3510905141639q5bfdbc8dje821ab6b749bbe68@mail.gmail.com>

[ dweber at X ~ ]$ ll /opt/local/bin/g++
lrwxr-xr-x 1 root admin 20 2008-10-29 10:35 /opt/local/bin/g++ ->
/usr/bin/bin/g++-4.0

[ dweber at X ~ ]$ ll /usr/bin/bin/g++-4.0
/opt/local/bin/gls: cannot access /usr/bin/bin/g++-4.0: No such file or
directory

[ dweber at X ~ ]$ port provides /opt/local/bin/g++
/opt/local/bin/g++ does not exist.


Is this peculiar to me or a problem in MacPorts generally?

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

From jmr at macports.org  Thu May 14 17:15:33 2009
From: jmr at macports.org (Joshua Root)
Date: Fri, 15 May 2009 10:15:33 +1000
Subject: symlink for g++ broken link to /usr/bin/bin/g+cc-4.0
In-Reply-To: <b808b3510905141639q5bfdbc8dje821ab6b749bbe68@mail.gmail.com>
References: <b808b3510905141639q5bfdbc8dje821ab6b749bbe68@mail.gmail.com>
Message-ID: <4A0CB425.8010600@macports.org>

On 2009-5-15 09:39, Darren Weber wrote:
> 
> [ dweber at X ~ ]$ ll /opt/local/bin/g++
> lrwxr-xr-x 1 root admin 20 2008-10-29 10:35 /opt/local/bin/g++ ->
> /usr/bin/bin/g++-4.0
> 
> [ dweber at X ~ ]$ ll /usr/bin/bin/g++-4.0
> /opt/local/bin/gls: cannot access /usr/bin/bin/g++-4.0: No such file or
> directory
> 
> [ dweber at X ~ ]$ port provides /opt/local/bin/g++
> /opt/local/bin/g++ does not exist.
> 
> 
> Is this peculiar to me or a problem in MacPorts generally?

That would be a bug in gcc_select.

- Josh

From ryandesign at macports.org  Thu May 14 20:23:23 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 14 May 2009 22:23:23 -0500
Subject: [51000] trunk/dports/devel
In-Reply-To: <20090515031118.E529819C28FA@beta.macosforge.org>
References: <20090515031118.E529819C28FA@beta.macosforge.org>
Message-ID: <05B9BB61-F873-4C0F-83E1-503786BD98E1@macports.org>

On May 14, 2009, at 22:11, macsforever2000 at macports.org wrote:

> Revision: 51000
>           http://trac.macports.org/changeset/51000
> Author:   macsforever2000 at macports.org
> Date:     2009-05-14 20:11:18 -0700 (Thu, 14 May 2009)
> Log Message:
> -----------
> Added new port. (#19624)



> +post-patch {
> +	reinplace "s|-lbluetooth||g" "${worksrcpath}/Commands/Legoctl/ 
> Makefile"
> +	if {${os.major} == 9} {
> +		reinplace "s|echo -e|echo|g" "${worksrcpath}/Commands/Legoctl/ 
> Makefile"
> +		reinplace "s|echo -e|echo|g" "${worksrcpath}/Commands/Vexctl/ 
> Makefile"
> +		reinplace "s|echo -e|echo|g" "${worksrcpath}/Libs/C/Makefile"
> +	}
> +}

FYI, you can simplify this to be a single reinplace command, and you  
don't need quotes around the file paths:

         reinplace "s|echo -e|echo|g" \
             ${worksrcpath}/Commands/Legoctl/Makefile
             ${worksrcpath}/Commands/Vexctl/Makefile
             ${worksrcpath}/Libs/C/Makefile


Possibly, this change would be needed on any Darwin version greater  
than or equal to 9, not just on 9. I haven't seen Darwin 10 yet I  
don't know for sure, but my impression was that this change in Darwin  
9 was intentional, for UNIX compliance, so that change would be  
unlikely to be undone again in a future OS version.


> +checksums	 md5 60dcbaea81d06a632493ff0ddb2e0cdc
> +checksums	 sha1 7c6c84a6bc7328ca95c07f12702387d404d44db1
> +checksums	 rmd160 a188c924bf4ba01049cb2e0eadc91aeb31f47741

You should probably write this as a single statement:

checksums   md5 60dcbaea81d06a632493ff0ddb2e0cdc \
             sha1 7c6c84a6bc7328ca95c07f12702387d404d44db1 \
             rmd160 a188c924bf4ba01049cb2e0eadc91aeb31f47741




From ryandesign at macports.org  Thu May 14 20:38:32 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 14 May 2009 22:38:32 -0500
Subject: symlink for g++ broken link to /usr/bin/bin/g+cc-4.0
In-Reply-To: <4A0CB425.8010600@macports.org>
References: <b808b3510905141639q5bfdbc8dje821ab6b749bbe68@mail.gmail.com>
	<4A0CB425.8010600@macports.org>
Message-ID: <58FFC92D-D54B-4F13-A504-F21F457E477B@macports.org>


On May 14, 2009, at 19:15, Joshua Root wrote:

> On 2009-5-15 09:39, Darren Weber wrote:
>
>> [ dweber at X ~ ]$ ll /opt/local/bin/g++
>> lrwxr-xr-x 1 root admin 20 2008-10-29 10:35 /opt/local/bin/g++ ->
>> /usr/bin/bin/g++-4.0
>>
>> [ dweber at X ~ ]$ ll /usr/bin/bin/g++-4.0
>> /opt/local/bin/gls: cannot access /usr/bin/bin/g++-4.0: No such  
>> file or
>> directory
>>
>> [ dweber at X ~ ]$ port provides /opt/local/bin/g++
>> /opt/local/bin/g++ does not exist.
>>
>>
>> Is this peculiar to me or a problem in MacPorts generally?
>
> That would be a bug in gcc_select.

Joshua fixed in r50991. Thanks for reporting the problem.



From ryandesign at macports.org  Thu May 14 20:43:42 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 14 May 2009 22:43:42 -0500
Subject: [50984] trunk/dports
In-Reply-To: <20090514214537.GA1221@prunille.vinc17.org>
References: <20090514210915.0335F19AE40B@beta.macosforge.org>
	<20090514214537.GA1221@prunille.vinc17.org>
Message-ID: <29AE8178-7D33-4618-B3D8-03DEC968B248@macports.org>


On May 14, 2009, at 16:45, Vincent Lefevre wrote:

> On 2009-05-14 14:08:45 -0700, and.damore at macports.org wrote:
>> Revision: 50984
>>           http://trac.macports.org/changeset/50984
>> Author:   and.damore at macports.org
>> Date:     2009-05-14 14:08:43 -0700 (Thu, 14 May 2009)
>> Log Message:
>> -----------
>> Maintainer email change, second batch, mail without @macpors.org  
>> domain are put in domain:user form.
>
> There seems to be a problem with this change:
>
> Index: graphics/optipng/Portfile
> ===================================================================
> --- graphics/optipng/Portfile   (revision 50983)
> +++ graphics/optipng/Portfile   (revision 50984)
> @@ -6,7 +6,7 @@
>  version         0.6.2
>  revision        1
>  categories      graphics
> -maintainers     vincent-opdarw at vinc17.org
> +maintainers     vincent-vinc17.org:opdarw
>  description     PNG file optimizer
>  long_description \
>          OptiPNG is a PNG optimizer that recompresses the image  
> files to a \

Andrea, I see you fixed this for optipng in r50998, but what about  
the rest of Vincent's ports?

Are you sure no other maintainers' addresses were affected by this  
problem? If you show us how you made the changes originally, maybe we  
can determine what other ports might be affected. I'm guessing  
maintainers with hyphens in the portion before the @ are affected, at  
least. I see problems in several ports using this command:

port -q info --maintainer --name  maintainer:-

Just picking a few:

catdoc ("julian-9k.de at hal")
flashdot ("macports-elze.de at tobias")
gpsbabel ("macports-behrendt.net at michael")
gtkmm1 ("gongloo-server.no-ip.com at charlies")
httrack ("ross-williams.net at ross")

What prompted you to make this change in the first place? I'm in  
favor of obfuscating email addresses in portfiles for the sake of  
consistency and the potential reduction of spam, but up to now, we've  
left it to up to each individual maintainer to decide how they wanted  
to format their email address in the portfile. And I don't recall a  
mailing list discussion about changing that, and you didn't list a  
ticket number in your commit message.



From macsforever2000 at macports.org  Thu May 14 20:38:22 2009
From: macsforever2000 at macports.org (Frank Schima)
Date: Thu, 14 May 2009 21:38:22 -0600
Subject: [51000] trunk/dports/devel
In-Reply-To: <05B9BB61-F873-4C0F-83E1-503786BD98E1@macports.org>
References: <20090515031118.E529819C28FA@beta.macosforge.org>
	<05B9BB61-F873-4C0F-83E1-503786BD98E1@macports.org>
Message-ID: <4D1872B1-2027-4980-BDB3-785491675D14@macports.org>


On May 14, 2009, at 9:23 PM, Ryan Schmidt wrote:

> On May 14, 2009, at 22:11, macsforever2000 at macports.org wrote:
>
>> Revision: 51000
>>          http://trac.macports.org/changeset/51000
>> Author:   macsforever2000 at macports.org
>> Date:     2009-05-14 20:11:18 -0700 (Thu, 14 May 2009)
>> Log Message:
>> -----------
>> Added new port. (#19624)
>
>
>
>> +post-patch {
>> +	reinplace "s|-lbluetooth||g" "${worksrcpath}/Commands/Legoctl/
>> Makefile"
>> +	if {${os.major} == 9} {
>> +		reinplace "s|echo -e|echo|g" "${worksrcpath}/Commands/Legoctl/
>> Makefile"
>> +		reinplace "s|echo -e|echo|g" "${worksrcpath}/Commands/Vexctl/
>> Makefile"
>> +		reinplace "s|echo -e|echo|g" "${worksrcpath}/Libs/C/Makefile"
>> +	}
>> +}
>
> FYI, you can simplify this to be a single reinplace command, and you
> don't need quotes around the file paths:
>
>         reinplace "s|echo -e|echo|g" \
>             ${worksrcpath}/Commands/Legoctl/Makefile
>             ${worksrcpath}/Commands/Vexctl/Makefile
>             ${worksrcpath}/Libs/C/Makefile
>
>
> Possibly, this change would be needed on any Darwin version greater
> than or equal to 9, not just on 9. I haven't seen Darwin 10 yet I
> don't know for sure, but my impression was that this change in Darwin
> 9 was intentional, for UNIX compliance, so that change would be
> unlikely to be undone again in a future OS version.
>
>
>> +checksums	 md5 60dcbaea81d06a632493ff0ddb2e0cdc
>> +checksums	 sha1 7c6c84a6bc7328ca95c07f12702387d404d44db1
>> +checksums	 rmd160 a188c924bf4ba01049cb2e0eadc91aeb31f47741
>
> You should probably write this as a single statement:
>
> checksums   md5 60dcbaea81d06a632493ff0ddb2e0cdc \
>             sha1 7c6c84a6bc7328ca95c07f12702387d404d44db1 \
>             rmd160 a188c924bf4ba01049cb2e0eadc91aeb31f47741

Good suggestions. Fixed in r51003.


Cheers!
Frank


From afb at macports.org  Thu May 14 23:40:46 2009
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Fri, 15 May 2009 08:40:46 +0200
Subject: Lint Spam
Message-ID: <E4C90ABB-56E5-4D99-9118-54A01A5C4994@macports.org>


Lots of lint reports for the latest email obfuscations
and the false positives from the version number checks...

Would it be possible to include a link to the revision ?
Something like "http://trac.macports.org/changeset/50980"

--anders


From wsiegrist at apple.com  Thu May 14 23:44:34 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Thu, 14 May 2009 23:44:34 -0700
Subject: Lint Spam
In-Reply-To: <E4C90ABB-56E5-4D99-9118-54A01A5C4994@macports.org>
References: <E4C90ABB-56E5-4D99-9118-54A01A5C4994@macports.org>
Message-ID: <1E3D8BBE-DF22-4943-9455-102E4260AE43@apple.com>

On May 14, 2009, at 11:40 PM, Anders F Bj?rklund wrote:

>
> Lots of lint reports for the latest email obfuscations
> and the false positives from the version number checks...
>
> Would it be possible to include a link to the revision ?
> Something like "http://trac.macports.org/changeset/50980"
>


Sure, but the subject line does include the rev number. A convenience  
link is a good idea though.



From raimue at macports.org  Fri May 15 00:30:10 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Fri, 15 May 2009 09:30:10 +0200
Subject: Lint Spam
In-Reply-To: <E4C90ABB-56E5-4D99-9118-54A01A5C4994@macports.org>
References: <E4C90ABB-56E5-4D99-9118-54A01A5C4994@macports.org>
Message-ID: <4A0D1A02.3040709@macports.org>

On 2009-05-15 08:40, Anders F Bj?rklund wrote:
> Lots of lint reports for the latest email obfuscations
> and the false positives from the version number checks...

Does it still hit many false positives? Could you please give some examples?

Rainer

From vincent-opdarw at vinc17.org  Fri May 15 01:27:44 2009
From: vincent-opdarw at vinc17.org (Vincent Lefevre)
Date: Fri, 15 May 2009 10:27:44 +0200
Subject: Lint Spam
In-Reply-To: <4A0D1A02.3040709@macports.org>
References: <E4C90ABB-56E5-4D99-9118-54A01A5C4994@macports.org>
	<4A0D1A02.3040709@macports.org>
Message-ID: <20090515082744.GE1221@prunille.vinc17.org>

On 2009-05-15 09:30:10 +0200, Rainer M?ller wrote:
> On 2009-05-15 08:40, Anders F Bj?rklund wrote:
> > Lots of lint reports for the latest email obfuscations
> > and the false positives from the version number checks...
> 
> Does it still hit many false positives? Could you please give some
> examples?

I got a lint e-mail complaining that for optipng 0.6.2, ${version}
was not used in the line:

patchfiles      optipng-0.6.2.1.diff

But this patch file is specific to version 0.6.2 and will be removed
in the next version. I don't think that using ${version} is really
useful and it may be better to keep the filename as it is (making
copy-paste easier and so on).

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

From afb at macports.org  Fri May 15 01:33:11 2009
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Fri, 15 May 2009 10:33:11 +0200
Subject: Lint Spam
In-Reply-To: <4A0D1A02.3040709@macports.org>
References: <E4C90ABB-56E5-4D99-9118-54A01A5C4994@macports.org>
	<4A0D1A02.3040709@macports.org>
Message-ID: <7F54D3C1-9900-4DBB-8E44-DEA89AEACE89@macports.org>

Rainer M?ller wrote:

>> Lots of lint reports for the latest email obfuscations
>> and the false positives from the version number checks...
>
> Does it still hit many false positives? Could you please give some  
> examples?

Well, if you have a version like say "2" you'll hit a few. :-)
But you are right, there aren't as many of those nags anymore...

So it's just the "Variant foo does not have a description" and
"use_configure no" instead of declaring an empty configure phase


But it could also be the surprise factor of having someone else
mess around with the ports, more than the lint process itself.

--anders


From and.damore at macports.org  Fri May 15 01:51:06 2009
From: and.damore at macports.org (Andrea D'Amore)
Date: Fri, 15 May 2009 10:51:06 +0200
Subject: [50984] trunk/dports
In-Reply-To: <29AE8178-7D33-4618-B3D8-03DEC968B248@macports.org>
References: <20090514210915.0335F19AE40B@beta.macosforge.org>
	<20090514214537.GA1221@prunille.vinc17.org>
	<29AE8178-7D33-4618-B3D8-03DEC968B248@macports.org>
Message-ID: <31DB5D50-AFF8-474C-9CEB-602BCFFF8293@macports.org>

On 15/mag/09, at 05:43, Ryan Schmidt wrote:

> Andrea, I see you fixed this for optipng in r50998, but what about  
> the rest of Vincent's ports?

I assumed he only had one as he wrote "a problem".

> Are you sure no other maintainers' addresses were affected by this  
> problem?

I'm sure every other mail address containing a hypens is affected.

> If you show us how you made the changes originally, maybe we can  
> determine what other ports might be affected. I'm guessing  
> maintainers with hyphens in the portion before the @ are affected,  
> at least.

I used a "find" command to match only 'Portfile' file that are not in  
unix hidden directories:

$ find . -type f ! -regex '.*\/\..*' -name 'Portfile'


I chained find with sed, running it twice, first time to delete  
"@macports.org" in lines starting with "maintainers":

$ find . -type f ! -regex '.*\/\..*' -name 'Portfile' -print0 | xargs  
-0 sed -i '/^maintainers/s/@macports\.org//g'

second time to replace the remaining emails, i.e. all those not in  
@macports.org domain, using backreference:

$ find . -type f ! -regex '.*\/\..*' -name 'Portfile' -print0 | xargs  
-0 sed -i '' '/^maintainers/s/\([a-zA-Z0-9_\.]*\)\@\([a-zA-Z0-9_\.]*\)/ 
\2:\1/g'


As you can see I didn't put a "\-" in the grouping so it was left out,  
my bad.
Other uncommon chars could lead to problem, I'm hereby assuming that  
alpha-digits and the set "-_." covers all email addresses. Any  
different advice?

> I see problems in several ports using this command:
> port -q info --maintainer --name  maintainer:-
>
> Just picking a few:
>
> catdoc ("julian-9k.de at hal")
> flashdot ("macports-elze.de at tobias")
> gpsbabel ("macports-behrendt.net at michael")
> gtkmm1 ("gongloo-server.no-ip.com at charlies")
> httrack ("ross-williams.net at ross")
>
> What prompted you to make this change in the first place?

I was editing portfiles containing my old handles and email.

When I searched for "@macports.org" I got more than 300 hits, and more  
than 1k for plain email address.
Global Keyword in Guide suggests to just keep the handle for those, It  
just seemed natural to me to alter them accordingly to the Guide.

> I'm in favor of obfuscating email addresses in portfiles for the  
> sake of consistency and the potential reduction of spam, but up to  
> now, we've left it to up to each individual maintainer to decide how  
> they wanted to format their email address in the portfile. And I  
> don't recall a mailing list discussion about changing that, and you  
> didn't list a ticket number in your commit message.

You're right and I apologize with everybody for that, I just talked  
about it on the channel.

I've searched the dports tree with find searching for maintainers line  
containig "-", I searched using port -q info for "maintainer:-", I cut  
off everything but the email addresses, I sorted the two files and I  
parsed them with uniq.

This way I've got two files, the actual email containing "-" in  
portfiles and the info from port command.
Does port info take its data from the Portfile or from the Portindex?
I.e. is the output of "port -q info" reliable or has the Portindex  
already rebuilt from the wrong emails?

This time I'm gonna file a ticket before patching.


Regards

Andrea

From and.damore at macports.org  Fri May 15 02:25:11 2009
From: and.damore at macports.org (Andrea D'Amore)
Date: Fri, 15 May 2009 11:25:11 +0200
Subject: [50984] trunk/dports
In-Reply-To: <31DB5D50-AFF8-474C-9CEB-602BCFFF8293@macports.org>
References: <20090514210915.0335F19AE40B@beta.macosforge.org>
	<20090514214537.GA1221@prunille.vinc17.org>
	<29AE8178-7D33-4618-B3D8-03DEC968B248@macports.org>
	<31DB5D50-AFF8-474C-9CEB-602BCFFF8293@macports.org>
Message-ID: <A530DC82-57FF-471D-AC1E-8217C07236E7@macports.org>

On 15/mag/09, at 10:51, Andrea D'Amore wrote:

> Does port info take its data from the Portfile or from the Portindex?
> I.e. is the output of "port -q info" reliable or has the Portindex  
> already rebuilt from the wrong emails?

I just read about the --index option for info command, to be sure I'm  
reverting the Portfile and check the actual right email addresses.

Now I'm not sure how I am supposed to go for the fix, I should open a  
ticket cc'ed to all affected email addresses asking for the actual  
maintainers to correct the addresses I messed up, right?

I ended founding 21 of them.

From dluke at geeklair.net  Fri May 15 06:34:46 2009
From: dluke at geeklair.net (Daniel J. Luke)
Date: Fri, 15 May 2009 09:34:46 -0400
Subject: [50984] trunk/dports
In-Reply-To: <A530DC82-57FF-471D-AC1E-8217C07236E7@macports.org>
References: <20090514210915.0335F19AE40B@beta.macosforge.org>
	<20090514214537.GA1221@prunille.vinc17.org>
	<29AE8178-7D33-4618-B3D8-03DEC968B248@macports.org>
	<31DB5D50-AFF8-474C-9CEB-602BCFFF8293@macports.org>
	<A530DC82-57FF-471D-AC1E-8217C07236E7@macports.org>
Message-ID: <DA57475B-1FF2-434B-9774-4A407D98EE9A@geeklair.net>

On May 15, 2009, at 5:25 AM, Andrea D'Amore wrote:
> On 15/mag/09, at 10:51, Andrea D'Amore wrote:
> Now I'm not sure how I am supposed to go for the fix, I should open  
> a ticket cc'ed to all affected email addresses asking for the actual  
> maintainers to correct the addresses I messed up, right?
>
> I ended founding 21 of them.


If you figured out the problem with your substitution pattern, you  
could probably revert the change you committed in your checkout, run  
the now-corrected substitution and then commit it.

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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090515/1a2471b8/attachment.bin>

From and.damore at macports.org  Fri May 15 09:03:12 2009
From: and.damore at macports.org (Andrea D'Amore)
Date: Fri, 15 May 2009 18:03:12 +0200
Subject: [50984] trunk/dports
In-Reply-To: <DA57475B-1FF2-434B-9774-4A407D98EE9A@geeklair.net>
References: <20090514210915.0335F19AE40B@beta.macosforge.org>
	<20090514214537.GA1221@prunille.vinc17.org>
	<29AE8178-7D33-4618-B3D8-03DEC968B248@macports.org>
	<31DB5D50-AFF8-474C-9CEB-602BCFFF8293@macports.org>
	<A530DC82-57FF-471D-AC1E-8217C07236E7@macports.org>
	<DA57475B-1FF2-434B-9774-4A407D98EE9A@geeklair.net>
Message-ID: <C4CA3965-8554-4DEC-BFDF-CEDB4FF01A82@macports.org>


On 15/mag/09, at 15:34, Daniel J. Luke wrote:

> If you figured out the problem with your substitution pattern, you  
> could probably revert the change you committed in your checkout, run  
> the now-corrected substitution and then commit it.

I reverted messed up addresses in r51021, these addresses contained  
either '-' or '+' char.
I'm now opening a ticket inviting respective maintainers to edit their  
own portfiles.

I apologize again for not having respected Macports' policy.

Affected ports in r51021 are:

aqua/NicePlayer/Portfile
comms/gnokii/Portfile
databases/postgis/Portfile
devel/mpfr/Portfile
devel/ppl/Portfile
devel/vttest/Portfile
devel/wxd/Portfile
fuse/mp3fs/Portfile
games/frotz/Portfile
games/gtetrinet/Portfile
gnome/gramps/Portfile
gnome/libgtkhtml/Portfile
gnome/liferea/Portfile
graphics/dvi2bitmap/Portfile
graphics/freeimage/Portfile
graphics/libpano13/Portfile
mail/gensig/Portfile
mail/mairix/Portfile
mail/spambnc/Portfile
math/gmp-ecm/Portfile
math/pari/Portfile
math/wxMaxima/Portfile
multimedia/photopc/Portfile
net/httrack/Portfile
news/tin-recent/Portfile
perl/p5-appconfig-std/Portfile
perl/p5-compress-raw-bzip2/Portfile
perl/p5-io-compress-bzip2/Portfile
perl/p5-libvorbis-perl/Portfile
perl/p5-math-mpfr/Portfile
perl/p5-net-dict/Portfile
perl/p5-term-gnuplot/Portfile
perl/p5-term-readkey/Portfile
perl/p5-term-readline-gnu/Portfile
print/psutils/Portfile
science/flashdot/Portfile
sysutils/libfwbuilder/Portfile
sysutils/multitail/Portfile
sysutils/rmtrash/Portfile
tex/latexmk/Portfile
tex/tetex-frogg/Portfile
textproc/catdoc/Portfile
textproc/cmconvert/Portfile
textproc/gpsbabel/Portfile
textproc/stardict-xmlittre/Portfile
textproc/texinfo/Portfile
www/sitecopy/Portfile
www/urlview/Portfile
x11/gtkmm1/Portfile



Bye


--
Andrea D'Amore
and.damore at macports.org


From ryandesign at macports.org  Fri May 15 14:03:53 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 15 May 2009 16:03:53 -0500
Subject: [51027] trunk/dports/devel
In-Reply-To: <20090515185534.411FA1A0CFDD@beta.macosforge.org>
References: <20090515185534.411FA1A0CFDD@beta.macosforge.org>
Message-ID: <178B57FE-8C32-4DB7-89BF-AC00D9515456@macports.org>


On May 15, 2009, at 13:55, toby at macports.org wrote:

> Revision: 51027
>           http://trac.macports.org/changeset/51027
> Author:   toby at macports.org
> Date:     2009-05-15 11:55:33 -0700 (Fri, 15 May 2009)
> Log Message:
> -----------
> libmowgli 0.7.0

[snip]

> +# Why do we set a bogus CPP value, anyway?
> +configure.cpp

What is bogus about it? Are you referring to this idea:

http://lists.macosforge.org/pipermail/macports-dev/2009-April/ 
008148.html

If so, let's discuss it (on the list, not as comments in  
portfiles :)). Thus far, nobody offered any input on my message so  
nothing has happened yet.



From jmr at macports.org  Fri May 15 14:18:55 2009
From: jmr at macports.org (Joshua Root)
Date: Sat, 16 May 2009 07:18:55 +1000
Subject: [51027] trunk/dports/devel
In-Reply-To: <178B57FE-8C32-4DB7-89BF-AC00D9515456@macports.org>
References: <20090515185534.411FA1A0CFDD@beta.macosforge.org>
	<178B57FE-8C32-4DB7-89BF-AC00D9515456@macports.org>
Message-ID: <4A0DDC3F.3070306@macports.org>

On 2009-5-16 07:03, Ryan Schmidt wrote:
> 
> On May 15, 2009, at 13:55, toby at macports.org wrote:
> 
>> Revision: 51027
>>           http://trac.macports.org/changeset/51027
>> Author:   toby at macports.org
>> Date:     2009-05-15 11:55:33 -0700 (Fri, 15 May 2009)
>> Log Message:
>> -----------
>> libmowgli 0.7.0
> 
> [snip]
> 
>> +# Why do we set a bogus CPP value, anyway?
>> +configure.cpp
> 
> What is bogus about it? Are you referring to this idea:
> 
> http://lists.macosforge.org/pipermail/macports-dev/2009-April/008148.html

Doesn't look related to me, the default value for configure.cpp is
something like /usr/bin/cpp-4.0.

- Josh

From ryandesign at macports.org  Fri May 15 14:31:27 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 15 May 2009 16:31:27 -0500
Subject: [51027] trunk/dports/devel
In-Reply-To: <4A0DDC3F.3070306@macports.org>
References: <20090515185534.411FA1A0CFDD@beta.macosforge.org>
	<178B57FE-8C32-4DB7-89BF-AC00D9515456@macports.org>
	<4A0DDC3F.3070306@macports.org>
Message-ID: <5FE85E33-E7BF-4235-8B90-5C516409EA79@macports.org>


On May 15, 2009, at 16:18, Joshua Root wrote:

> On 2009-5-16 07:03, Ryan Schmidt wrote:
>>
>> On May 15, 2009, at 13:55, toby at macports.org wrote:
>>
>>> Revision: 51027
>>>           http://trac.macports.org/changeset/51027
>>> Author:   toby at macports.org
>>> Date:     2009-05-15 11:55:33 -0700 (Fri, 15 May 2009)
>>> Log Message:
>>> -----------
>>> libmowgli 0.7.0
>>
>> [snip]
>>
>>> +# Why do we set a bogus CPP value, anyway?
>>> +configure.cpp
>>
>> What is bogus about it? Are you referring to this idea:
>>
>> http://lists.macosforge.org/pipermail/macports-dev/2009-April/ 
>> 008148.html
>
> Doesn't look related to me, the default value for configure.cpp is
> something like /usr/bin/cpp-4.0.

Oh, whoops, I was confusing configure.cppflags with configure.cpp.

So right. /usr/bin/cpp-4.0 is the default value of configure.cpp, and  
is what we want to be there. (We want to use that specific version of  
cpp, and not whatever other version the user might have  
gcc_select'd.) What problems did you encounter with that value in  
your port, Toby?




From toby at macports.org  Sat May 16 00:57:46 2009
From: toby at macports.org (Toby Peterson)
Date: Sat, 16 May 2009 00:57:46 -0700
Subject: [51027] trunk/dports/devel
In-Reply-To: <178B57FE-8C32-4DB7-89BF-AC00D9515456@macports.org>
References: <20090515185534.411FA1A0CFDD@beta.macosforge.org>
	<178B57FE-8C32-4DB7-89BF-AC00D9515456@macports.org>
Message-ID: <74c219d30905160057t2a8f8d2cn18a1881c82f81c3a@mail.gmail.com>

On Fri, May 15, 2009 at 14:03, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On May 15, 2009, at 13:55, toby at macports.org wrote:
>
>> Revision: 51027
>> ? ? ? ? ?http://trac.macports.org/changeset/51027
>> Author: ? toby at macports.org
>> Date: ? ? 2009-05-15 11:55:33 -0700 (Fri, 15 May 2009)
>> Log Message:
>> -----------
>> libmowgli 0.7.0
>
> [snip]
>
>> +# Why do we set a bogus CPP value, anyway?
>> +configure.cpp
>
> What is bogus about it? Are you referring to this idea:
>
> http://lists.macosforge.org/pipermail/macports-dev/2009-April/008148.html
>
> If so, let's discuss it (on the list, not as comments in portfiles :)). Thus
> far, nobody offered any input on my message so nothing has happened yet.

It should be "gcc -E". To illustrate the problem:

% touch foo.c bar.c
% gcc -E foo.c bar.c
# 1 "foo.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "foo.c"
# 1 "bar.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "bar.c"
% cpp foo.c bar.c
%

Most configure scripts will just use "$CC -E" if CPP isn't specified
explicitly, which is what I'm taking advantage of there. And, if you
run nearly any configure script with no special setup:

checking how to run the C preprocessor... gcc -E

I'd vote for just never setting CPP, but setting it to "$CC -E" would
probably work too.

- Toby

From ryandesign at macports.org  Sat May 16 01:40:35 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 16 May 2009 03:40:35 -0500
Subject: [51027] trunk/dports/devel
In-Reply-To: <74c219d30905160057t2a8f8d2cn18a1881c82f81c3a@mail.gmail.com>
References: <20090515185534.411FA1A0CFDD@beta.macosforge.org>
	<178B57FE-8C32-4DB7-89BF-AC00D9515456@macports.org>
	<74c219d30905160057t2a8f8d2cn18a1881c82f81c3a@mail.gmail.com>
Message-ID: <147D87D8-6AEA-4CCC-9C26-E659190588D2@macports.org>


On May 16, 2009, at 02:57, Toby Peterson wrote:

> On Fri, May 15, 2009 at 14:03, Ryan Schmidt wrote:
>
>> On May 15, 2009, at 13:55, toby at macports.org wrote:
>>
>>> Revision: 51027
>>>          http://trac.macports.org/changeset/51027
>>> Author:   toby at macports.org
>>> Date:     2009-05-15 11:55:33 -0700 (Fri, 15 May 2009)
>>> Log Message:
>>> -----------
>>> libmowgli 0.7.0
>>
>> [snip]
>>
>>> +# Why do we set a bogus CPP value, anyway?
>>> +configure.cpp
>>
>> What is bogus about it? [snip]
>
> It should be "gcc -E". To illustrate the problem:
>
> % touch foo.c bar.c
> % gcc -E foo.c bar.c
> # 1 "foo.c"
> # 1 "<built-in>"
> # 1 "<command line>"
> # 1 "foo.c"
> # 1 "bar.c"
> # 1 "<built-in>"
> # 1 "<command line>"
> # 1 "bar.c"
> % cpp foo.c bar.c
> %
>
> Most configure scripts will just use "$CC -E" if CPP isn't specified
> explicitly, which is what I'm taking advantage of there. And, if you
> run nearly any configure script with no special setup:
>
> checking how to run the C preprocessor... gcc -E
>
> I'd vote for just never setting CPP, but setting it to "$CC -E" would
> probably work too.

Interesting. I can't offer much input as all I know about compiling  
software comes from maintaining ports in MacPorts; I haven't written  
compiled software myself and I'm not fluent on what a preprocessor is  
supposed to do or how it's supposed to work. But now I'm curious why  
there is an executable called "cpp" whose manpage says it is "The C  
Preprocessor" if that's not in fact the C preprocessor one is meant  
to use.

After some Googling, I think I'm understanding that "gcc -E"  
internally calls "cpp"? They just appear to handle output  
differently. For example, I see that "gcc -E foo.c bar.c" causes the  
output to appear as you showed, and foo.c and bar.c remain empty,  
whereas "cpp foo.c bar.c" causes no output to appear, and modifies  
bar.c to contain the foo-related lines you showed, and the bar- 
related lines don't seem to be anywhere. This appears to match the  
usage explanation from the cpp manpage, "cpp infile outfile". In  
contrast, gcc appears to take a bunch of input files and print output  
to stdout.

MacPorts has set CPP to /usr/bin/cpp-4.0 since r27018 was committed  
on 2007-07-15, and this was released as part of MacPorts 1.5.1 in  
August 2007. And I haven't heard any mention of a problems with this  
approach until now. So my first instinct is to wonder if this is less  
a general problem and more an issue in the particular software you're  
porting. I'm not opposed to changing this in MacPorts base if that  
can be demonstrated to be more correct and to help more ports than it  
harms. But the fact that AFAIK no prior problems were reported with  
this method in 22 months speaks to the method not being totally  
crazy. I certainly wouldn't call it "bogus."




From jmr at macports.org  Sat May 16 02:05:12 2009
From: jmr at macports.org (Joshua Root)
Date: Sat, 16 May 2009 19:05:12 +1000
Subject: [51027] trunk/dports/devel
In-Reply-To: <147D87D8-6AEA-4CCC-9C26-E659190588D2@macports.org>
References: <20090515185534.411FA1A0CFDD@beta.macosforge.org>	<178B57FE-8C32-4DB7-89BF-AC00D9515456@macports.org>	<74c219d30905160057t2a8f8d2cn18a1881c82f81c3a@mail.gmail.com>
	<147D87D8-6AEA-4CCC-9C26-E659190588D2@macports.org>
Message-ID: <4A0E81C8.5030707@macports.org>

On 2009-5-16 18:40, Ryan Schmidt wrote:
> 
> On May 16, 2009, at 02:57, Toby Peterson wrote:
> 
>> On Fri, May 15, 2009 at 14:03, Ryan Schmidt wrote:
>>
>>> On May 15, 2009, at 13:55, toby at macports.org wrote:
>>>
>>>> Revision: 51027
>>>>          http://trac.macports.org/changeset/51027
>>>> Author:   toby at macports.org
>>>> Date:     2009-05-15 11:55:33 -0700 (Fri, 15 May 2009)
>>>> Log Message:
>>>> -----------
>>>> libmowgli 0.7.0
>>>
>>> [snip]
>>>
>>>> +# Why do we set a bogus CPP value, anyway?
>>>> +configure.cpp
>>>
>>> What is bogus about it? [snip]
>>
>> It should be "gcc -E". To illustrate the problem:
>>
>> % touch foo.c bar.c
>> % gcc -E foo.c bar.c
>> # 1 "foo.c"
>> # 1 "<built-in>"
>> # 1 "<command line>"
>> # 1 "foo.c"
>> # 1 "bar.c"
>> # 1 "<built-in>"
>> # 1 "<command line>"
>> # 1 "bar.c"
>> % cpp foo.c bar.c
>> %
>>
>> Most configure scripts will just use "$CC -E" if CPP isn't specified
>> explicitly, which is what I'm taking advantage of there. And, if you
>> run nearly any configure script with no special setup:
>>
>> checking how to run the C preprocessor... gcc -E
>>
>> I'd vote for just never setting CPP, but setting it to "$CC -E" would
>> probably work too.
> 
> Interesting. I can't offer much input as all I know about compiling
> software comes from maintaining ports in MacPorts; I haven't written
> compiled software myself and I'm not fluent on what a preprocessor is
> supposed to do or how it's supposed to work. But now I'm curious why
> there is an executable called "cpp" whose manpage says it is "The C
> Preprocessor" if that's not in fact the C preprocessor one is meant to use.
> 
> After some Googling, I think I'm understanding that "gcc -E" internally
> calls "cpp"? They just appear to handle output differently. For example,
> I see that "gcc -E foo.c bar.c" causes the output to appear as you
> showed, and foo.c and bar.c remain empty, whereas "cpp foo.c bar.c"
> causes no output to appear, and modifies bar.c to contain the
> foo-related lines you showed, and the bar-related lines don't seem to be
> anywhere. This appears to match the usage explanation from the cpp
> manpage, "cpp infile outfile". In contrast, gcc appears to take a bunch
> of input files and print output to stdout.
> 
> MacPorts has set CPP to /usr/bin/cpp-4.0 since r27018 was committed on
> 2007-07-15, and this was released as part of MacPorts 1.5.1 in August
> 2007. And I haven't heard any mention of a problems with this approach
> until now. So my first instinct is to wonder if this is less a general
> problem and more an issue in the particular software you're porting. I'm
> not opposed to changing this in MacPorts base if that can be
> demonstrated to be more correct and to help more ports than it harms.
> But the fact that AFAIK no prior problems were reported with this method
> in 22 months speaks to the method not being totally crazy. I certainly
> wouldn't call it "bogus."

That or most build systems don't actually use $CPP. (There's no reason
to if you're just doing a normal compile.)

- Josh

From toby at macports.org  Sat May 16 12:40:37 2009
From: toby at macports.org (Toby Peterson)
Date: Sat, 16 May 2009 12:40:37 -0700
Subject: [51027] trunk/dports/devel
In-Reply-To: <4A0E81C8.5030707@macports.org>
References: <20090515185534.411FA1A0CFDD@beta.macosforge.org>
	<178B57FE-8C32-4DB7-89BF-AC00D9515456@macports.org>
	<74c219d30905160057t2a8f8d2cn18a1881c82f81c3a@mail.gmail.com>
	<147D87D8-6AEA-4CCC-9C26-E659190588D2@macports.org>
	<4A0E81C8.5030707@macports.org>
Message-ID: <74c219d30905161240u2ce39257p81e04b49f07d9ba9@mail.gmail.com>

On Sat, May 16, 2009 at 02:05, Joshua Root <jmr at macports.org> wrote:
> On 2009-5-16 18:40, Ryan Schmidt wrote:
>>
>> On May 16, 2009, at 02:57, Toby Peterson wrote:
>>
>>> On Fri, May 15, 2009 at 14:03, Ryan Schmidt wrote:
>>>
>>>> On May 15, 2009, at 13:55, toby at macports.org wrote:
>>>>
>>>>> Revision: 51027
>>>>> ? ? ? ? ?http://trac.macports.org/changeset/51027
>>>>> Author: ? toby at macports.org
>>>>> Date: ? ? 2009-05-15 11:55:33 -0700 (Fri, 15 May 2009)
>>>>> Log Message:
>>>>> -----------
>>>>> libmowgli 0.7.0
>>>>
>>>> [snip]
>>>>
>>>>> +# Why do we set a bogus CPP value, anyway?
>>>>> +configure.cpp
>>>>
>>>> What is bogus about it? [snip]
>>>
>>> It should be "gcc -E". To illustrate the problem:
>>>
>>> % touch foo.c bar.c
>>> % gcc -E foo.c bar.c
>>> # 1 "foo.c"
>>> # 1 "<built-in>"
>>> # 1 "<command line>"
>>> # 1 "foo.c"
>>> # 1 "bar.c"
>>> # 1 "<built-in>"
>>> # 1 "<command line>"
>>> # 1 "bar.c"
>>> % cpp foo.c bar.c
>>> %
>>>
>>> Most configure scripts will just use "$CC -E" if CPP isn't specified
>>> explicitly, which is what I'm taking advantage of there. And, if you
>>> run nearly any configure script with no special setup:
>>>
>>> checking how to run the C preprocessor... gcc -E
>>>
>>> I'd vote for just never setting CPP, but setting it to "$CC -E" would
>>> probably work too.
>>
>> Interesting. I can't offer much input as all I know about compiling
>> software comes from maintaining ports in MacPorts; I haven't written
>> compiled software myself and I'm not fluent on what a preprocessor is
>> supposed to do or how it's supposed to work. But now I'm curious why
>> there is an executable called "cpp" whose manpage says it is "The C
>> Preprocessor" if that's not in fact the C preprocessor one is meant to use.
>>
>> After some Googling, I think I'm understanding that "gcc -E" internally
>> calls "cpp"? They just appear to handle output differently. For example,
>> I see that "gcc -E foo.c bar.c" causes the output to appear as you
>> showed, and foo.c and bar.c remain empty, whereas "cpp foo.c bar.c"
>> causes no output to appear, and modifies bar.c to contain the
>> foo-related lines you showed, and the bar-related lines don't seem to be
>> anywhere. This appears to match the usage explanation from the cpp
>> manpage, "cpp infile outfile". In contrast, gcc appears to take a bunch
>> of input files and print output to stdout.
>>
>> MacPorts has set CPP to /usr/bin/cpp-4.0 since r27018 was committed on
>> 2007-07-15, and this was released as part of MacPorts 1.5.1 in August
>> 2007. And I haven't heard any mention of a problems with this approach
>> until now. So my first instinct is to wonder if this is less a general
>> problem and more an issue in the particular software you're porting. I'm
>> not opposed to changing this in MacPorts base if that can be
>> demonstrated to be more correct and to help more ports than it harms.
>> But the fact that AFAIK no prior problems were reported with this method
>> in 22 months speaks to the method not being totally crazy. I certainly
>> wouldn't call it "bogus."
>
> That or most build systems don't actually use $CPP. (There's no reason
> to if you're just doing a normal compile.)

Many/most ports that do use $CPP probably only run it on one file, in
which case it will behave as expected. Also, I have run into this
before: http://trac.macports.org/changeset/40070

- Toby

From ryandesign at macports.org  Sat May 16 17:29:17 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 16 May 2009 19:29:17 -0500
Subject: [51036] trunk/dports/textproc/aspell-dict-bg/Portfile
In-Reply-To: <20090516170513.B51171A5DEE1@beta.macosforge.org>
References: <20090516170513.B51171A5DEE1@beta.macosforge.org>
Message-ID: <265272A7-6684-4AB3-9754-4CC043960D7F@macports.org>


On May 16, 2009, at 12:05, macsforever2000 at macports.org wrote:

> Revision: 51036
>           http://trac.macports.org/changeset/51036
> Author:   macsforever2000 at macports.org
> Date:     2009-05-16 10:05:13 -0700 (Sat, 16 May 2009)
> Log Message:
> -----------
> Maintainer update to version 4.1. Add homepage. Fix  
> long_description. (#19627)

[snip]

> -depends_build	port:aspell
> +depends_build	bin:aspell:aspell

Why did you undo r19623 with this commit?


From ryandesign at macports.org  Sat May 16 17:36:20 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 16 May 2009 19:36:20 -0500
Subject: [51041] trunk/dports/textproc/gpsbabel
In-Reply-To: <20090516185149.46FDB1A5ED1B@beta.macosforge.org>
References: <20090516185149.46FDB1A5ED1B@beta.macosforge.org>
Message-ID: <555294FF-F34A-412F-9382-6709F8A45B2C@macports.org>

On May 16, 2009, at 13:51, snc at macports.org wrote:

> Revision: 51041
>           http://trac.macports.org/changeset/51041
> Author:   snc at macports.org
> Date:     2009-05-16 11:51:47 -0700 (Sat, 16 May 2009)
> Log Message:
> -----------
> version update, maintainer timeout, adding self as openmaintainer

[snip]

>  name	    	gpsbabel
> -version	    	1.3.5
> +version	    	1.3.6
>  categories  	textproc comms
> -maintainers 	macports at michael-behrendt.net
> +maintainers 	snc openmaintainer

It's fine that you committed the proposed update since the maintainer  
did not respond within 72 hours, but did the maintainer really agree  
to give the port up to you? Was there a port abandonment request filed?

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



From jeremy at lavergne.gotdns.org  Sat May 16 18:14:29 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Sat, 16 May 2009 21:14:29 -0400
Subject: [51041] trunk/dports/textproc/gpsbabel
In-Reply-To: <555294FF-F34A-412F-9382-6709F8A45B2C@macports.org>
References: <20090516185149.46FDB1A5ED1B@beta.macosforge.org>
	<555294FF-F34A-412F-9382-6709F8A45B2C@macports.org>
Message-ID: <30F605FE-2847-48E3-B8AE-036561510872@lavergne.gotdns.org>

The portfile posted in the ticket said it was nomaintainer.

I decided that, rather than dropping it entirely I'd pick it up as an  
openmaintainer.

On May 16, 2009, at 8:36 PM, Ryan Schmidt wrote:

> On May 16, 2009, at 13:51, snc at macports.org wrote:
>
>> Revision: 51041
>>          http://trac.macports.org/changeset/51041
>> Author:   snc at macports.org
>> Date:     2009-05-16 11:51:47 -0700 (Sat, 16 May 2009)
>> Log Message:
>> -----------
>> version update, maintainer timeout, adding self as openmaintainer
>
> [snip]
>
>> name	    	gpsbabel
>> -version	    	1.3.5
>> +version	    	1.3.6
>> categories  	textproc comms
>> -maintainers 	macports at michael-behrendt.net
>> +maintainers 	snc openmaintainer
>
> It's fine that you committed the proposed update since the  
> maintainer did not respond within 72 hours, but did the maintainer  
> really agree to give the port up to you? Was there a port  
> abandonment request filed?
>
> http://guide.macports.org/#project.update-policies.abandonment
>
>
>

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

From ryandesign at macports.org  Sat May 16 18:30:47 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 16 May 2009 20:30:47 -0500
Subject: [51041] trunk/dports/textproc/gpsbabel
In-Reply-To: <30F605FE-2847-48E3-B8AE-036561510872@lavergne.gotdns.org>
References: <20090516185149.46FDB1A5ED1B@beta.macosforge.org>
	<555294FF-F34A-412F-9382-6709F8A45B2C@macports.org>
	<30F605FE-2847-48E3-B8AE-036561510872@lavergne.gotdns.org>
Message-ID: <EC78F9BC-81FD-4C9C-9192-8243E508D961@macports.org>

On May 16, 2009, at 20:14, Jeremy Lavergne wrote:

> On May 16, 2009, at 8:36 PM, Ryan Schmidt wrote:
>
>> On May 16, 2009, at 13:51, snc at macports.org wrote:
>>
>>> Revision: 51041
>>>          http://trac.macports.org/changeset/51041
>>> Author:   snc at macports.org
>>> Date:     2009-05-16 11:51:47 -0700 (Sat, 16 May 2009)
>>> Log Message:
>>> -----------
>>> version update, maintainer timeout, adding self as openmaintainer
>>
>> [snip]
>>
>>> name	    	gpsbabel
>>> -version	    	1.3.5
>>> +version	    	1.3.6
>>> categories  	textproc comms
>>> -maintainers 	macports at michael-behrendt.net
>>> +maintainers 	snc openmaintainer
>>
>> It's fine that you committed the proposed update since the  
>> maintainer did not respond within 72 hours, but did the maintainer  
>> really agree to give the port up to you? Was there a port  
>> abandonment request filed?
>>
>> http://guide.macports.org/#project.update-policies.abandonment
>
> The portfile posted in the ticket said it was nomaintainer.
>
> I decided that, rather than dropping it entirely I'd pick it up as  
> an openmaintainer.

Ok, I see that now, but the ticket does not explain why the submitter  
of the ticket would have the authority to reassign the port to  
nomaintainer. If there has been communication with the previous  
maintainer and he has agreed to release the port, or if multiple  
attempts have been made to reach the previous maintainer and he is  
unreachable, then that's fine, it just needs to be documented  
somewhere. If no such communication has occurred, then you cannot  
change the maintainer of the port.



From ryandesign at macports.org  Sat May 16 23:43:05 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 17 May 2009 01:43:05 -0500
Subject: propchange - r51061 svn:log
In-Reply-To: <20090517063915.C855A558002@relay16.apple.com>
References: <20090517063915.C855A558002@relay16.apple.com>
Message-ID: <820CE827-594E-42D7-B36B-4B1EADA5E8C2@macports.org>

On May 17, 2009, at 01:39, ryandesign at macports.org wrote:

> Author: ryandesign at macports.org (original author:  
> jeremyhu at macports.org)
> Revision: 51061
> Property Name: svn:log
>
>


I didn't change anything in the log message, and indeed no diff is  
shown in the email, so I'm surprised a mail was sent at all. I was  
just checking that I got the log editing syntax right, to pass it on  
to Jeremy, since he asked about it.



From ryandesign at macports.org  Sat May 16 23:54:56 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 17 May 2009 01:54:56 -0500
Subject: [51062] trunk/dports/fuse/mp3fs/Portfile
In-Reply-To: <20090517050619.574431A651D6@beta.macosforge.org>
References: <20090517050619.574431A651D6@beta.macosforge.org>
Message-ID: <C9BE182B-C4C1-42D1-8999-736A3369C703@macports.org>


On May 17, 2009, at 00:06, and.damore at macports.org wrote:

> Revision: 51062
>           http://trac.macports.org/changeset/51062
> Author:   and.damore at macports.org
> Date:     2009-05-16 22:06:18 -0700 (Sat, 16 May 2009)
> Log Message:
> -----------
> Update per ticket no. 19646

If you refer to Trac ticket numbers by writing the number preceded  
with by "#" then Trac automatically links such text to the ticket, if  
you're looking at the revision in Trac. Similarly, when referring to  
revision numbers, precede the number with "r" and Trac will link that  
text to that revision's changeset page.


> Modified Paths:
> --------------
>     trunk/dports/fuse/mp3fs/Portfile
>
> Modified: trunk/dports/fuse/mp3fs/Portfile
> ===================================================================
> --- trunk/dports/fuse/mp3fs/Portfile	2009-05-17 04:31:40 UTC (rev  
> 51061)
> +++ trunk/dports/fuse/mp3fs/Portfile	2009-05-17 05:06:18 UTC (rev  
> 51062)
> @@ -1,5 +1,5 @@
>  # -*- 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$
> +# $Id:

Looks like the Id tag got messed up. I fixed it in r51067. Andrea,  
don't forget to look at the diff before you commit, so incorrect  
changes don't get committed. :) Uwe, it's best to submit diffs  
instead of full Portfiles, so that everyone can see exactly what's  
being changed, and so that you can be sure that each change you're  
proposing is one you're wanting to have made. It also helps in case  
other changes have been made to the port before your new portfile is  
committed, so that those other changes aren't inadvertently undone.



From ryandesign at macports.org  Sun May 17 08:09:34 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 17 May 2009 10:09:34 -0500
Subject: [51077] trunk/base/portmgr/bots/trac.rb
In-Reply-To: <20090517145252.2D5E11AAA9DB@beta.macosforge.org>
References: <20090517145252.2D5E11AAA9DB@beta.macosforge.org>
Message-ID: <70C6887E-D090-458A-9E18-A6C0F5A8AEE6@macports.org>


On May 17, 2009, at 09:52, and.damore at macports.org wrote:

> Revision: 51077
>           http://trac.macports.org/changeset/51077
> Author:   and.damore at macports.org
> Date:     2009-05-17 07:52:50 -0700 (Sun, 17 May 2009)
> Log Message:
> -----------
> "paste" superpower for mpbot.

Thanks for your continued improvements!

It looks like you also made whitespace changes to this file in this  
commit. While it's true that we'd prefer source files to contain  
spaces and not tabs, and it's fine to make such changes, I'd like to  
ask for whitespace changes to be committed separately from functional  
changes in the future. This way, when I'm looking through the log and  
see a commit with the message "whitespace changes only" I can ignore  
it, and when I see a commit with the message "'paste' superpower for  
mpbot" I can look at the diff and see exactly what changes were  
necessary to implement that feature. As it is, looking at the below  
diff, I have to spend a lot of time trying to figure out where your  
real changes are.


> Modified Paths:
> --------------
>     trunk/base/portmgr/bots/trac.rb
>
> Modified: trunk/base/portmgr/bots/trac.rb
> ===================================================================
> --- trunk/base/portmgr/bots/trac.rb	2009-05-17 14:21:55 UTC (rev  
> 51076)
> +++ trunk/base/portmgr/bots/trac.rb	2009-05-17 14:52:50 UTC (rev  
> 51077)
> @@ -1,61 +1,66 @@
>  #
> -#	trac.rb
> +#   trac.rb
>  #
> -#	Plugin to rbot (http://ruby-rbot.org/), an irc bot, to provide
> -#	services related to MacPorts trac systemfor the #macports channel
> -#	on freenode.net, created from PortPlugin by James D. Berry
> +#   Plugin to rbot (http://ruby-rbot.org/), an irc bot, to provide
> +#   services related to MacPorts trac systemfor the #macports channel
> +#   on freenode.net, created from PortPlugin by James D. Berry
>  #
> -#	By Andrea D'Amore
> +#   By Andrea D'Amore
>  #
> -#	$Id: $
> +#   $Id: $
>
>  require 'stringio'
>
>  class TracPlugin < Plugin
>
> -	def help(plugin, topic="")
> -		case topic
> -		  when "ticket"
> -			return "ticket <ticket no.> => show http link for ticket #  
> <ticket no.>"
> -		  when "faq"
> -			return "faq => show FAQs' URL"
> -		  when "guide"
> -			return "guide [chunked] => show The Guide's URL. Don't Panic."		
> -		  else
> -			return "trac module provides: !ticket, !faq, !guide"
> -		end
> -	end
> +    def help(plugin, topic="")
> +        case topic
> +          when "ticket"
> +            return "ticket <ticket no.> => show http link for  
> ticket # <ticket no.>"
> +          when "faq"
> +            return "faq => show FAQs' URL"
> +          when "guide"
> +            return "guide [chunked] => show The Guide's URL. Don't  
> Panic."
> +          else
> +            return "trac module provides: !ticket, !faq, !guide"
> +        end
> +    end
>
> -	def ticket(m, params)
> -		number = params[:number][/^#?(\d*)$/,1]
> -		if ( number )
> -			url = "http://trac.macports.org/ticket/"+number
> -			m.reply "#{url}"
> -		else
> -			m.reply "Use either #1234 or 1234 for ticket number"
> -		end
> -	end
> +    def ticket(m, params)
> +        number = params[:number][/^#?(\d*)$/,1]
> +        if ( number )
> +            url = "http://trac.macports.org/ticket/"+number
> +            m.reply "#{url}"
> +        else
> +            m.reply "Use either #1234 or 1234 for ticket number"
> +        end
> +    end
>
> -	def faq(m, params)
> -		m.reply "FAQs are at: http://trac.macports.org/wiki/FAQ"
> -	end
> +    def faq(m, params)
> +        m.reply "FAQs are at: http://trac.macports.org/wiki/FAQ"
> +    end
>
> -	def guide(m, params)
> -		if ( params[:parm] == "chunked" )
> -			m.reply "http://guide.macports.org/chunked/index.html"
> -		else
> -			m.reply "http://guide.macports.org/"
> -		end
> -	end
> -	
> -	def team(m, params)
> -		m.reply "http://trac.macports.org/wiki/MacPortsDevelopers"
> -	end
> +    def paste(m, params)
> +        m.reply "Paste texts more than 3 rows using: http:// 
> paste.lisp.org/new/macports"
> +    end
>
> +    def guide(m, params)
> +        if ( params[:parm] == "chunked" )
> +            m.reply "http://guide.macports.org/chunked/index.html"
> +        else
> +            m.reply "http://guide.macports.org/"
> +        end
> +    end
> +
> +    def team(m, params)
> +        m.reply "http://trac.macports.org/wiki/MacPortsDevelopers"
> +    end
> +
>  end
>
>  plugin = TracPlugin.new
> -plugin.map 'ticket :number', :action => 'ticket'
> -plugin.map 'faq :parm', :action => 'faq', :defaults => {:parm => ""}
> -plugin.map 'guide :parm', :action => 'guide', :defaults => {:parm  
> => ""}
> -plugin.map 'team', :action => 'team'
> \ No newline at end of file
> +plugin.map 'ticket :number',    :action => 'ticket'
> +plugin.map 'faq :parm',         :action => 'faq'
> +plugin.map 'paste :parm',       :action => 'paste'
> +plugin.map 'guide :parm',       :action => 'guide',     :defaults  
> => {:parm => ""}
> +plugin.map 'team',              :action => 'team'
> \ No newline at end of file




From macsforever2000 at macports.org  Sun May 17 11:23:09 2009
From: macsforever2000 at macports.org (Frank Schima)
Date: Sun, 17 May 2009 12:23:09 -0600
Subject: [51036] trunk/dports/textproc/aspell-dict-bg/Portfile
In-Reply-To: <265272A7-6684-4AB3-9754-4CC043960D7F@macports.org>
References: <20090516170513.B51171A5DEE1@beta.macosforge.org>
	<265272A7-6684-4AB3-9754-4CC043960D7F@macports.org>
Message-ID: <EDC845B0-CD67-49B8-871A-A6F0AE7A46BC@macports.org>


On May 16, 2009, at 6:29 PM, Ryan Schmidt wrote:

>
> On May 16, 2009, at 12:05, macsforever2000 at macports.org wrote:
>
>> Revision: 51036
>>          http://trac.macports.org/changeset/51036
>> Author:   macsforever2000 at macports.org
>> Date:     2009-05-16 10:05:13 -0700 (Sat, 16 May 2009)
>> Log Message:
>> -----------
>> Maintainer update to version 4.1. Add homepage. Fix
>> long_description. (#19627)
>
> [snip]
>
>> -depends_build	port:aspell
>> +depends_build	bin:aspell:aspell
>
> Why did you undo r19623 with this commit?


That was a mistake. Fixed in r51079. Thanks for spotting that!


-Frank


From jeremy at lavergne.gotdns.org  Sun May 17 12:44:52 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Sun, 17 May 2009 15:44:52 -0400
Subject: [51041] trunk/dports/textproc/gpsbabel
In-Reply-To: <EC78F9BC-81FD-4C9C-9192-8243E508D961@macports.org>
References: <20090516185149.46FDB1A5ED1B@beta.macosforge.org>
	<555294FF-F34A-412F-9382-6709F8A45B2C@macports.org>
	<30F605FE-2847-48E3-B8AE-036561510872@lavergne.gotdns.org>
	<EC78F9BC-81FD-4C9C-9192-8243E508D961@macports.org>
Message-ID: <BF04BFBD-4514-4303-A97B-7ABBF3A47028@lavergne.gotdns.org>

We're updating the ticket to include the fact that the maintainer has  
been out of contact for a very long time (on the order of a year --  
there appears to be no ticket for when he was involved in the 1.3.5  
update from 11 months ago).

Additionally, he has still not responded to the ticket, our attempts  
to contact him about the new version, and that we'd like to replace him.

On May 16, 2009, at 9:30 PM, Ryan Schmidt wrote:

> Ok, I see that now, but the ticket does not explain why the  
> submitter of the ticket would have the authority to reassign the  
> port to nomaintainer. If there has been communication with the  
> previous maintainer and he has agreed to release the port, or if  
> multiple attempts have been made to reach the previous maintainer  
> and he is unreachable, then that's fine, it just needs to be  
> documented somewhere. If no such communication has occurred, then  
> you cannot change the maintainer of the port.

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

From and.damore at macports.org  Sun May 17 23:46:42 2009
From: and.damore at macports.org (Andrea D'Amore)
Date: Mon, 18 May 2009 08:46:42 +0200
Subject: gnat-gcc reproduce bug
Message-ID: <8DBE5290-42E4-4EFA-BA92-D38531D87A10@macports.org>

Hello,
I've got a bug while trying to build gnat-gcc +macada using  
macada.org's binary as bootstrap compiler, I'm on Leopard 10.5.6 and I  
have XCode tools 3.1.2 installed.
I reported the bug in #19668 but krischik won't support PowerPC .

Before filing a bug I'd like someone else with a ppc and macports try  
to build and see if he can reproduce the bug, steps are simple:

- download <http://www.macada.org/macada/Downloads_files/ 
GnatPPC-4.3.dmg> , ~140Mb
- install the resulting .pkg, it'll go in /usr/local/ada-4.3.3
- build gnat-gcc using +macada variant, this will select the compiler  
just installed from .pkg


It may take a little time, say an hour or two depending on your  
computer, please save the full output of terminal in a file and keep  
it apart, then reply here.


Thanks


Andrea

From ryandesign at macports.org  Mon May 18 01:38:00 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 18 May 2009 03:38:00 -0500
Subject: trac.macports.org: No usable temporary directory
Message-ID: <C6336D59-9D9B-4FA4-99D3-C21947FF6C5F@macports.org>

When trying to save changes to a Trac ticket just now, I get:


Internal Server Error

TracError: IOError: [Errno 2] No usable temporary directory found in  
['/tmp', '/var/tmp', '/usr/tmp', '/']



From wsiegrist at apple.com  Mon May 18 07:39:41 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Mon, 18 May 2009 07:39:41 -0700
Subject: trac.macports.org: No usable temporary directory
In-Reply-To: <C6336D59-9D9B-4FA4-99D3-C21947FF6C5F@macports.org>
References: <C6336D59-9D9B-4FA4-99D3-C21947FF6C5F@macports.org>
Message-ID: <2DFB87BF-5383-4143-B6FF-C79351002F68@apple.com>

On May 18, 2009, at 1:38 AM, Ryan Schmidt wrote:

> When trying to save changes to a Trac ticket just now, I get:
>
>
> Internal Server Error
>
> TracError: IOError: [Errno 2] No usable temporary directory found in  
> ['/tmp', '/var/tmp', '/usr/tmp', '/']
>
>


This has been fixed. 

From raimue at macports.org  Mon May 18 13:43:44 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Mon, 18 May 2009 22:43:44 +0200
Subject: Mac Science Collaboration group
In-Reply-To: <3FF9E3CB-9E08-4D22-AB4B-3CB4BE5ED320@ucla.edu>
References: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>	<4A0A0C9E.8010106@macports.org>
	<3FF9E3CB-9E08-4D22-AB4B-3CB4BE5ED320@ucla.edu>
Message-ID: <4A11C880.4080102@macports.org>

On 2009-05-14 18:30, James Kyle wrote:
>> I would really appreciate such efforts. For example, we already have
>> groups of developers working on KDE or Ruby related ports.  
>> Developers in
>> these groups would just need to figure out a good way of coordinating
>> their work using branches, tickets and wiki pages.
> 
> What would be the next step towards making this a reality for macports?

One step was to approve your request for commit access, for which you
should have gotten a separate mail. :-)

I think it is important to find a way of working which would work best
for the involved developers. For example, you could open your own branch
of the ports tree where updates to science ports are being prepared and
tested and later merged back into the main ports tree.

Your next steps really depend how you want to work, or rather you have
to find a workflow which works for you and other contributors. I would
recommend to start with a wiki page and document your goals and how you
want to achieve them. Gather other developers to join your efforts and
then discuss with them.

So, everyone interested into science related software being available as
ports should get in contact with James now!

Rainer

From wsiegrist at apple.com  Mon May 18 14:11:55 2009
From: wsiegrist at apple.com (William Siegrist)
Date: Mon, 18 May 2009 14:11:55 -0700
Subject: Mac Science Collaboration group
In-Reply-To: <4A11C880.4080102@macports.org>
References: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>
	<4A0A0C9E.8010106@macports.org>
	<3FF9E3CB-9E08-4D22-AB4B-3CB4BE5ED320@ucla.edu>
	<4A11C880.4080102@macports.org>
Message-ID: <B581BFE2-88B4-46DF-ACBF-BE0B9307E8C9@apple.com>

On May 18, 2009, at 1:43 PM, Rainer M?ller wrote:

> On 2009-05-14 18:30, James Kyle wrote:
>>> I would really appreciate such efforts. For example, we already have
>>> groups of developers working on KDE or Ruby related ports.
>>> Developers in
>>> these groups would just need to figure out a good way of  
>>> coordinating
>>> their work using branches, tickets and wiki pages.
>>
>> What would be the next step towards making this a reality for  
>> macports?
>
> One step was to approve your request for commit access, for which you
> should have gotten a separate mail. :-)
>
> I think it is important to find a way of working which would work best
> for the involved developers. For example, you could open your own  
> branch
> of the ports tree where updates to science ports are being prepared  
> and
> tested and later merged back into the main ports tree.
>
> Your next steps really depend how you want to work, or rather you have
> to find a workflow which works for you and other contributors. I would
> recommend to start with a wiki page and document your goals and how  
> you
> want to achieve them. Gather other developers to join your efforts and
> then discuss with them.
>
> So, everyone interested into science related software being  
> available as
> ports should get in contact with James now!
>


In case it was not obvious, Mac OS Forge can provide extra mailing  
lists for this if needed.

-Bill

From jameskyle at ucla.edu  Mon May 18 15:40:13 2009
From: jameskyle at ucla.edu (James Kyle)
Date: Mon, 18 May 2009 15:40:13 -0700
Subject: Mac Science Collaboration group
In-Reply-To: <B581BFE2-88B4-46DF-ACBF-BE0B9307E8C9@apple.com>
References: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>
	<4A0A0C9E.8010106@macports.org>
	<3FF9E3CB-9E08-4D22-AB4B-3CB4BE5ED320@ucla.edu>
	<4A11C880.4080102@macports.org>
	<B581BFE2-88B4-46DF-ACBF-BE0B9307E8C9@apple.com>
Message-ID: <8C798995-390D-457B-9ADA-BCB0CBEAA973@ucla.edu>

>> Your next steps really depend how you want to work, or rather you  
>> have
>> to find a workflow which works for you and other contributors. I  
>> would
>> recommend to start with a wiki page and document your goals and how  
>> you
>> want to achieve them. Gather other developers to join your efforts  
>> and
>> then discuss with them.

This is what I was thinking. I assume that wiki editing is connected  
to commit access? I poked around the wiki page and didn't see any page  
creation or editing links.

-james

From dweber at macports.org  Mon May 18 15:48:54 2009
From: dweber at macports.org (Darren Weber)
Date: Mon, 18 May 2009 15:48:54 -0700
Subject: tcl catch syntax
Message-ID: <b808b3510905181548k4e733bf5r534e4552e1e6ab96@mail.gmail.com>

The following works in tclsh:

# Find all the example executables by parsing all the
# CMakeLists.txt files within the src Examples path
set exe {}
foreach f [exec find ${worksrcpath}/Examples -name "CMakeLists.txt"] {
    catch {exec -ignorestderr grep -e "ADD_EXECUTABLE" ${f} } results
options
    if {[dict get ${options} -code] == 0} {
        # Remove the string "ADD_EXECUTABLE(", with or without whitespace
        regsub -all "\[ \t\]*ADD_EXECUTABLE\[(\]\[ \t\]*" ${results} ""
results
        # Remove the string ".cxx)", with or without whitespace
        regsub -all ".cxx\[ \t\]*\[)\]" ${results} "" results
        set exe [concat ${exe} ${results}]
    }
}


The idea here is to parse a file tree to pull out all the lines in files
called "CMakeLists.txt" that contain the string "ADD_EXECUTABLES".  The bash
shell syntax using grep and sed is quite simple, but it get's messy when
translated to tcl.  Anyhow, it works in tclsh, but the destroot phase fails
with this error:

DEBUG: Executing proc-post-org.macports.destroot-destroot-2
Error: Target org.macports.destroot returned: wrong # args: should be "catch
command ?varName?"
Warning: the following items did not execute (for InsightToolkit):
org.macports.destroot
Error: Status 1 encountered during processing.


Here in the tcl 8.5 documentation, we have a different syntax that allows
the "option" variable:
http://www.tcl.tk/man/tcl8.5/TclCmd/catch.htm

Where is this error about tcl syntax generated?  Is this error tcl-version
specific?

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

From blb at macports.org  Mon May 18 16:04:46 2009
From: blb at macports.org (Bryan Blackburn)
Date: Mon, 18 May 2009 17:04:46 -0600
Subject: Mac Science Collaboration group
In-Reply-To: <8C798995-390D-457B-9ADA-BCB0CBEAA973@ucla.edu>
References: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>
	<4A0A0C9E.8010106@macports.org>
	<3FF9E3CB-9E08-4D22-AB4B-3CB4BE5ED320@ucla.edu>
	<4A11C880.4080102@macports.org>
	<B581BFE2-88B4-46DF-ACBF-BE0B9307E8C9@apple.com>
	<8C798995-390D-457B-9ADA-BCB0CBEAA973@ucla.edu>
Message-ID: <20090518230446.GK826@ninagal.withay.com>

On Mon, May 18, 2009 at 03:40:13PM -0700, James Kyle said:
>>> Your next steps really depend how you want to work, or rather you  
>>> have
>>> to find a workflow which works for you and other contributors. I  
>>> would
>>> recommend to start with a wiki page and document your goals and how  
>>> you
>>> want to achieve them. Gather other developers to join your efforts  
>>> and
>>> then discuss with them.
>
> This is what I was thinking. I assume that wiki editing is connected to 
> commit access? I poked around the wiki page and didn't see any page  
> creation or editing links.

Nope, it just requires you to be logged in (with any account, not just
@macports).  To create a new page just go to the page, eg:

<http://trac.macports.org/wiki/Science>

The other choice is to create a link to it with CamelCase which is
auto-linked by the wiki, then you can go to it from there.  Also check out

<http://trac.macports.org/wiki/TracWiki>

Bryan


>
> -james

From dweber at macports.org  Mon May 18 16:07:31 2009
From: dweber at macports.org (Darren Weber)
Date: Mon, 18 May 2009 16:07:31 -0700
Subject: tcl catch syntax
In-Reply-To: <b808b3510905181548k4e733bf5r534e4552e1e6ab96@mail.gmail.com>
References: <b808b3510905181548k4e733bf5r534e4552e1e6ab96@mail.gmail.com>
Message-ID: <b808b3510905181607j2b0250fbn9796268d8f28153d@mail.gmail.com>

On Mon, May 18, 2009 at 3:48 PM, Darren Weber <dweber at macports.org> wrote:

>
> The following works in tclsh:
>
> # Find all the example executables by parsing all the
> # CMakeLists.txt files within the src Examples path
> set exe {}
> foreach f [exec find ${worksrcpath}/Examples -name "CMakeLists.txt"] {
>     catch {exec -ignorestderr grep -e "ADD_EXECUTABLE" ${f} } results
> options
>     if {[dict get ${options} -code] == 0} {
>         # Remove the string "ADD_EXECUTABLE(", with or without whitespace
>         regsub -all "\[ \t\]*ADD_EXECUTABLE\[(\]\[ \t\]*" ${results} ""
> results
>         # Remove the string ".cxx)", with or without whitespace
>         regsub -all ".cxx\[ \t\]*\[)\]" ${results} "" results
>         set exe [concat ${exe} ${results}]
>     }
> }
>
>
> The idea here is to parse a file tree to pull out all the lines in files
> called "CMakeLists.txt" that contain the string "ADD_EXECUTABLES".  The bash
> shell syntax using grep and sed is quite simple, but it get's messy when
> translated to tcl.  Anyhow, it works in tclsh, but the destroot phase fails
> with this error:
>
> DEBUG: Executing proc-post-org.macports.destroot-destroot-2
> Error: Target org.macports.destroot returned: wrong # args: should be
> "catch command ?varName?"
> Warning: the following items did not execute (for InsightToolkit):
> org.macports.destroot
> Error: Status 1 encountered during processing.
>
>
> Here in the tcl 8.5 documentation, we have a different syntax that allows
> the "option" variable:
> http://www.tcl.tk/man/tcl8.5/TclCmd/catch.htm
>
> Where is this error about tcl syntax generated?  Is this error tcl-version
> specific?
>
> Thanks, Darren
>
>

The following is another way of doing this without the option variable in
the catch statement:

        set exe {}
        foreach f [exec find ${worksrcpath}/Examples -name "CMakeLists.txt"]
{
            catch {exec -ignorestderr grep -e "ADD_EXECUTABLE" ${f} }
results
            if [expr ! [string match "*child process*" ${results}] ] {
                # Remove the string "ADD_EXECUTABLE(", with or without
whitespace
                regsub -all "\[ \t\]*ADD_EXECUTABLE\[(\]\[ \t\]*" ${results}
"" results
                # Remove the string ".cxx)", with or without whitespace
                regsub -all ".cxx\[ \t\]*\[)\]" ${results} "" results
                set exe [concat ${exe} ${results}]
            }
        }

The destroot stage still fails, this time with a different error that is
almost impossible to track down:

Error: Target org.macports.destroot returned: list element in quotes
followed by ":" instead of space
Warning: the following items did not execute (for InsightToolkit):
org.macports.destroot
Error: Status 1 encountered during processing.

Where is this error coming from and how can I track it down?

Thanks in advance,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090518/a6fd7114/attachment-0001.html>

From raimue at macports.org  Mon May 18 16:08:34 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Tue, 19 May 2009 01:08:34 +0200
Subject: tcl catch syntax
In-Reply-To: <b808b3510905181548k4e733bf5r534e4552e1e6ab96@mail.gmail.com>
References: <b808b3510905181548k4e733bf5r534e4552e1e6ab96@mail.gmail.com>
Message-ID: <4A11EA72.1070102@macports.org>

On 2009-05-19 00:48, Darren Weber wrote:
> DEBUG: Executing proc-post-org.macports.destroot-destroot-2
> Error: Target org.macports.destroot returned: wrong # args: should be
> "catch command ?varName?"
> Warning: the following items did not execute (for InsightToolkit):
> org.macports.destroot
> Error: Status 1 encountered during processing.
> 
> 
> Here in the tcl 8.5 documentation, we have a different syntax that
> allows the "option" variable:
> http://www.tcl.tk/man/tcl8.5/TclCmd/catch.htm

MacPorts uses Tcl 8.4 as provided by Mac OS X. You are probably reading
8.5 documentation which has been installed by the MacPorts tcl port.

You can use man to view the man page supplied by the system by using the
full path:
  man /usr/share/man/mann/catch.ntcl.gz

Rainer

From raimue at macports.org  Mon May 18 16:10:00 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Tue, 19 May 2009 01:10:00 +0200
Subject: Mac Science Collaboration group
In-Reply-To: <8C798995-390D-457B-9ADA-BCB0CBEAA973@ucla.edu>
References: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>	<4A0A0C9E.8010106@macports.org>	<3FF9E3CB-9E08-4D22-AB4B-3CB4BE5ED320@ucla.edu>	<4A11C880.4080102@macports.org>	<B581BFE2-88B4-46DF-ACBF-BE0B9307E8C9@apple.com>
	<8C798995-390D-457B-9ADA-BCB0CBEAA973@ucla.edu>
Message-ID: <4A11EAC8.60807@macports.org>

On 2009-05-19 00:40, James Kyle wrote:
> This is what I was thinking. I assume that wiki editing is connected  
> to commit access? I poked around the wiki page and didn't see any page  
> creation or editing links.

Editing wiki pages is allowed for everyone. But for spam protection and
for reference who made a change, it is required to register an account
on MacOSForge. An account is also required to file tickets. You will
find the link for registration and login at the upper right corner on
each page of <http://trac.macports.org/>.

After registering and logging in, you will see a "Edit this page" button
at the bottom of each wiki page. To create new pages, simply visit the
page with the desired name and click the button there.

Rainer

From dweber at macports.org  Mon May 18 16:15:26 2009
From: dweber at macports.org (Darren Weber)
Date: Mon, 18 May 2009 16:15:26 -0700
Subject: tcl catch syntax
In-Reply-To: <4A11EA72.1070102@macports.org>
References: <b808b3510905181548k4e733bf5r534e4552e1e6ab96@mail.gmail.com>
	<4A11EA72.1070102@macports.org>
Message-ID: <b808b3510905181615p6ac0b88bje7a8515f4834b30@mail.gmail.com>

On Mon, May 18, 2009 at 4:08 PM, Rainer M?ller <raimue at macports.org> wrote:

> On 2009-05-19 00:48, Darren Weber wrote:
> > DEBUG: Executing proc-post-org.macports.destroot-destroot-2
> > Error: Target org.macports.destroot returned: wrong # args: should be
> > "catch command ?varName?"
> > Warning: the following items did not execute (for InsightToolkit):
> > org.macports.destroot
> > Error: Status 1 encountered during processing.
> >
> >
> > Here in the tcl 8.5 documentation, we have a different syntax that
> > allows the "option" variable:
> > http://www.tcl.tk/man/tcl8.5/TclCmd/catch.htm
>
> MacPorts uses Tcl 8.4 as provided by Mac OS X. You are probably reading
> 8.5 documentation which has been installed by the MacPorts tcl port.
>
> You can use man to view the man page supplied by the system by using the
> full path:
>  man /usr/share/man/mann/catch.ntcl.gz
>
> Rainer
>


Yes, I've been "debugging" using the 'tclsh' symlink to tclsh8.5 provided by
macports (/opt/local/bin/tclsh8.5) and reading the 8.5 documentation at
http://www.tcl.tk/doc/

I'll switch over to tclsh8.4 and see if that helps.

Thanks!
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090518/ac539051/attachment.html>

From dweber at macports.org  Mon May 18 16:17:08 2009
From: dweber at macports.org (Darren Weber)
Date: Mon, 18 May 2009 16:17:08 -0700
Subject: tcl catch syntax
In-Reply-To: <b808b3510905181615p6ac0b88bje7a8515f4834b30@mail.gmail.com>
References: <b808b3510905181548k4e733bf5r534e4552e1e6ab96@mail.gmail.com>
	<4A11EA72.1070102@macports.org>
	<b808b3510905181615p6ac0b88bje7a8515f4834b30@mail.gmail.com>
Message-ID: <b808b3510905181617v77483433j412218e29f42561b@mail.gmail.com>

AAAAAAaaaarggggggg, NO readline support in apple tclsh8.4 :-(

Is there any easy way to get it?  Maybe a module include or something?

Thanks, again,
Darren



On Mon, May 18, 2009 at 4:15 PM, Darren Weber <dweber at macports.org> wrote:

>
>
> On Mon, May 18, 2009 at 4:08 PM, Rainer M?ller <raimue at macports.org>wrote:
>
>> On 2009-05-19 00:48, Darren Weber wrote:
>> > DEBUG: Executing proc-post-org.macports.destroot-destroot-2
>> > Error: Target org.macports.destroot returned: wrong # args: should be
>> > "catch command ?varName?"
>> > Warning: the following items did not execute (for InsightToolkit):
>> > org.macports.destroot
>> > Error: Status 1 encountered during processing.
>> >
>> >
>> > Here in the tcl 8.5 documentation, we have a different syntax that
>> > allows the "option" variable:
>> > http://www.tcl.tk/man/tcl8.5/TclCmd/catch.htm
>>
>> MacPorts uses Tcl 8.4 as provided by Mac OS X. You are probably reading
>> 8.5 documentation which has been installed by the MacPorts tcl port.
>>
>> You can use man to view the man page supplied by the system by using the
>> full path:
>>  man /usr/share/man/mann/catch.ntcl.gz
>>
>> Rainer
>>
>
>
> Yes, I've been "debugging" using the 'tclsh' symlink to tclsh8.5 provided
> by macports (/opt/local/bin/tclsh8.5) and reading the 8.5 documentation at
> http://www.tcl.tk/doc/
>
> I'll switch over to tclsh8.4 and see if that helps.
>
> Thanks!
> Darren
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090518/fd3bc3f9/attachment.html>

From dweber at macports.org  Mon May 18 16:18:28 2009
From: dweber at macports.org (Darren Weber)
Date: Mon, 18 May 2009 16:18:28 -0700
Subject: tcl catch syntax
In-Reply-To: <b808b3510905181617v77483433j412218e29f42561b@mail.gmail.com>
References: <b808b3510905181548k4e733bf5r534e4552e1e6ab96@mail.gmail.com>
	<4A11EA72.1070102@macports.org>
	<b808b3510905181615p6ac0b88bje7a8515f4834b30@mail.gmail.com>
	<b808b3510905181617v77483433j412218e29f42561b@mail.gmail.com>
Message-ID: <b808b3510905181618g5d677be0sa280266dbe8b0b28@mail.gmail.com>

Oh, yea,

rlwrap tclsh8.4



On Mon, May 18, 2009 at 4:17 PM, Darren Weber <dweber at macports.org> wrote:

>
>
> AAAAAAaaaarggggggg, NO readline support in apple tclsh8.4 :-(
>
> Is there any easy way to get it?  Maybe a module include or something?
>
> Thanks, again,
> Darren
>
>
>
>
> On Mon, May 18, 2009 at 4:15 PM, Darren Weber <dweber at macports.org> wrote:
>
>>
>>
>> On Mon, May 18, 2009 at 4:08 PM, Rainer M?ller <raimue at macports.org>wrote:
>>
>>> On 2009-05-19 00:48, Darren Weber wrote:
>>> > DEBUG: Executing proc-post-org.macports.destroot-destroot-2
>>> > Error: Target org.macports.destroot returned: wrong # args: should be
>>> > "catch command ?varName?"
>>> > Warning: the following items did not execute (for InsightToolkit):
>>> > org.macports.destroot
>>> > Error: Status 1 encountered during processing.
>>> >
>>> >
>>> > Here in the tcl 8.5 documentation, we have a different syntax that
>>> > allows the "option" variable:
>>> > http://www.tcl.tk/man/tcl8.5/TclCmd/catch.htm
>>>
>>> MacPorts uses Tcl 8.4 as provided by Mac OS X. You are probably reading
>>> 8.5 documentation which has been installed by the MacPorts tcl port.
>>>
>>> You can use man to view the man page supplied by the system by using the
>>> full path:
>>>  man /usr/share/man/mann/catch.ntcl.gz
>>>
>>> Rainer
>>>
>>
>>
>> Yes, I've been "debugging" using the 'tclsh' symlink to tclsh8.5 provided
>> by macports (/opt/local/bin/tclsh8.5) and reading the 8.5 documentation at
>> http://www.tcl.tk/doc/
>>
>> I'll switch over to tclsh8.4 and see if that helps.
>>
>> Thanks!
>> Darren
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090518/36d91598/attachment.html>

From dweber at macports.org  Mon May 18 16:30:08 2009
From: dweber at macports.org (Darren Weber)
Date: Mon, 18 May 2009 16:30:08 -0700
Subject: source .tcl script on tclsh startup, and remain in interactive mode
Message-ID: <b808b3510905181630p42c9cf22xf669eaa681ddde58@mail.gmail.com>

Let the file ~/bin/macports.tcl contain the following:

source /Library/Tcl/macports1.0/macports_fastload.tcl
package require Pextlib

Then, how do you startup tclsh8.4 with a command line option to source this
file and remain in an interactive mode?  The man page and a google search
are not providing a clear answer to this simple problem.  I'm not a tcl
expert, but I would have thought there is a tclsh command line option to
source a .tcl script (and then remain interactive).

Thanks in advance,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090518/20f218be/attachment-0001.html>

From dweber at macports.org  Mon May 18 16:40:07 2009
From: dweber at macports.org (Darren Weber)
Date: Mon, 18 May 2009 16:40:07 -0700
Subject: source .tcl script on tclsh startup, and remain in interactive 
	mode
In-Reply-To: <b808b3510905181630p42c9cf22xf669eaa681ddde58@mail.gmail.com>
References: <b808b3510905181630p42c9cf22xf669eaa681ddde58@mail.gmail.com>
Message-ID: <b808b3510905181640w307e6094h93b950f69d022884@mail.gmail.com>

On Mon, May 18, 2009 at 4:30 PM, Darren Weber <dweber at macports.org> wrote:

>
> Let the file ~/bin/macports.tcl contain the following:
>
> source /Library/Tcl/macports1.0/macports_fastload.tcl
> package require Pextlib
>
> Then, how do you startup tclsh8.4 with a command line option to source this
> file and remain in an interactive mode?  The man page and a google search
> are not providing a clear answer to this simple problem.  I'm not a tcl
> expert, but I would have thought there is a tclsh command line option to
> source a .tcl script (and then remain interactive).
>
> Thanks in advance,
> Darren
>
>

Interesting note on autoloading:
http://www.ccp4.ac.uk/peter/programming/tcl_autoloading.html

Section 13.7 of Tcl and Tk Toolkit by Ousterhout is interesting also.
http://www.amazon.com/Tcl-Toolkit-Addison-Wesley-Professional-Computing/dp/020163337X
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090518/5746c2cf/attachment.html>

From ryandesign at macports.org  Tue May 19 06:41:40 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 19 May 2009 08:41:40 -0500
Subject: [51048] trunk/dports/science/vis5d+/Portfile
In-Reply-To: <20090517010403.EDB531A62EB4@beta.macosforge.org>
References: <20090517010403.EDB531A62EB4@beta.macosforge.org>
Message-ID: <DF2C9C6D-CF3A-4255-B9ED-E0A261891C29@macports.org>

On May 16, 2009, at 20:04, takeshi at macports.org wrote:

> Revision: 51048
>           http://trac.macports.org/changeset/51048
> Author:   takeshi at macports.org
> Date:     2009-05-16 18:04:00 -0700 (Sat, 16 May 2009)
> Log Message:
> -----------
> vis5d+: removed conflicts gcc43 in g95 variant
>
> Modified Paths:
> --------------
>     trunk/dports/science/vis5d+/Portfile
>
> Modified: trunk/dports/science/vis5d+/Portfile
> ===================================================================
> --- trunk/dports/science/vis5d+/Portfile	2009-05-16 21:53:52 UTC  
> (rev 51047)
> +++ trunk/dports/science/vis5d+/Portfile	2009-05-17 01:04:00 UTC  
> (rev 51048)
> @@ -93,8 +93,7 @@
>          ${destroot}${prefix}/share/doc/${name}/html/stylesheet-images
>  }
>
> -variant g95 description {compiles fortran interface for g95} \
> -    conflicts gcc43 {
> +variant g95 description {compiles fortran interface for g95} { \

There should not be a backslash at the end of that line now.

>          depends_build           port:g95

Is it your intention to overwrite the port's global depends_build  
here (and in the commented-out gcc43 variant)? This is removing the  
pkgconfig dependency if this variant is selected.



From dweber at macports.org  Tue May 19 13:12:23 2009
From: dweber at macports.org (Darren Weber)
Date: Tue, 19 May 2009 13:12:23 -0700
Subject: framework.dir - global var documentation?
Message-ID: <b808b3510905191312h59aafab4j4498ac3e89083433@mail.gmail.com>

Can we add ${framework.dir} to the global variable documentation?

http://guide.macports.org/#reference.variables

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

From dweber at macports.org  Tue May 19 13:17:46 2009
From: dweber at macports.org (Darren Weber)
Date: Tue, 19 May 2009 13:17:46 -0700
Subject: framework.dir - global var documentation?
In-Reply-To: <b808b3510905191312h59aafab4j4498ac3e89083433@mail.gmail.com>
References: <b808b3510905191312h59aafab4j4498ac3e89083433@mail.gmail.com>
Message-ID: <b808b3510905191317v4c080e7aq744f076fbba578e7@mail.gmail.com>

On Tue, May 19, 2009 at 1:12 PM, Darren Weber <dweber at macports.org> wrote:

>
> Can we add ${framework.dir} to the global variable documentation?
>
> http://guide.macports.org/#reference.variables
>
> Regards,
> Darren
>
>

Actually, is it possible and easy to change from $frameworks_dir to
$frameworkpath?  Where is frameworks_dir created?  Should it be used in the
same way as $prefix?

For instance, port:python26 seems to prefer something like that, e.g.:

configure.args          --enable-framework=${frameworks_dir} \
                        --enable-ipv6

...

post-destroot {
   set framewpath ${frameworks_dir}/Python.framework
   set framewdir  ${framewpath}/Versions/${branch}

...


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

From dweber at macports.org  Wed May 20 13:07:40 2009
From: dweber at macports.org (Darren Weber)
Date: Wed, 20 May 2009 13:07:40 -0700
Subject: python2.5 pretends to be a framework installation
Message-ID: <b808b3510905201307s6de75779wd2b1d0ffaeb6338f@mail.gmail.com>

There's a problem with activating an installation of InsightToolkit
(currently in revision), when building it against python2.5 as a framework,
i.e.:


DEBUG: Adding file to file_map:
/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/WrapITK.pth
for: InsightToolkit
Error: Target org.macports.activate returned: Not a directory
Warning: the following items did not execute (for InsightToolkit):
org.macports.activate
Error: Status 1 encountered during processing.

[ root at X ]# ls -l
/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5
lrwxr-xr-x 1 root wheel 24 2009-05-13 14:28
/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5 ->
/opt/local/lib/python2.5/


Perhaps the python2.5 port could not "pretend" to be a framework
installation (i.e., place no symlinks into the python framework, or actually
install as a framework, as in python2.6), or the port activation process
could be a little more flexible to allow the activation against a symlink
location.

The fix for this InsightToolkit port will be to change the build
configuration to point directly to the python2.5 installs under
${prefix}/lib, ${prefix}/include, etc.

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

From raimue at macports.org  Wed May 20 13:53:02 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Wed, 20 May 2009 22:53:02 +0200
Subject: python2.5 pretends to be a framework installation
In-Reply-To: <b808b3510905201307s6de75779wd2b1d0ffaeb6338f@mail.gmail.com>
References: <b808b3510905201307s6de75779wd2b1d0ffaeb6338f@mail.gmail.com>
Message-ID: <4A146DAE.8070204@macports.org>

On 2009-05-20 22:07, Darren Weber wrote:
> Perhaps the python2.5 port could not "pretend" to be a framework
> installation (i.e., place no symlinks into the python framework, or
> actually install as a framework, as in python2.6), or the port
> activation process could be a little more flexible to allow the
> activation against a symlink location.

The symlinks have been introduced as python25 switched from a "normal"
build to the framework to ease the transition. It is just not possible
to change this now without causing major problems for all users. It
would require everyone to uninstall all dependents of python25, upgrade
and then reinstall.

> The fix for this InsightToolkit port will be to change the build
> configuration to point directly to the python2.5 installs under
> ${prefix}/lib, ${prefix}/include, etc.

The workaround is to move the files in a post-destroot phase to the
right location in ${prefix}/lib/python2.5.

Rainer

From raimue at macports.org  Wed May 20 14:12:08 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Wed, 20 May 2009 23:12:08 +0200
Subject: Mac Science Collaboration group
In-Reply-To: <B581BFE2-88B4-46DF-ACBF-BE0B9307E8C9@apple.com>
References: <31CC7832-2F67-4062-A348-BA0DAF3A76E2@ucla.edu>
	<4A0A0C9E.8010106@macports.org>
	<3FF9E3CB-9E08-4D22-AB4B-3CB4BE5ED320@ucla.edu>
	<4A11C880.4080102@macports.org>
	<B581BFE2-88B4-46DF-ACBF-BE0B9307E8C9@apple.com>
Message-ID: <4A147228.5020502@macports.org>

On 2009-05-18 23:11, William Siegrist wrote:
> In case it was not obvious, Mac OS Forge can provide extra mailing  
> lists for this if needed.

Thanks for the reminder, Bill. Having extra lists might be nice.

But for now with only a few developers it could be better to just post
on macports-dev with a [Science] tag. It would be easier for others to
chime in and attract more people for this group. But if we really have a
group of at least 4-5 people willing to work on this an extra list for
coordination would make sense. Moving the thing now to an extra list
before it even has started would hide it away from possible interested
contributors.

Rainer

From ryandesign at macports.org  Wed May 20 19:22:51 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 20 May 2009 21:22:51 -0500
Subject: Panther tickets
In-Reply-To: <065.c129f4215823d49ec7e0c6f172f3928a@macports.org>
References: <056.8c0a9be3e8d65bb3091c817ea800dfdc@macports.org>
	<065.c129f4215823d49ec7e0c6f172f3928a@macports.org>
Message-ID: <D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>

On May 20, 2009, at 20:59, MacPorts wrote:

> #10989: BUG: gcc41 build failure on Mac OS X 10.3.9
> ----------------------------------- 
> +----------------------------------------
>   Reporter:  roland@?              |       Owner:  mww@?
>       Type:  defect                |      Status:  closed
>   Priority:  High                  |   Milestone:
>  Component:  ports                 |     Version:  1.3.2
> Resolution:  wontfix               |    Keywords:  gcc41 libstc++  
> nm odnm Panther
>       Port:                        |
> ----------------------------------- 
> +----------------------------------------
> Changes (by toby@?):
>
>   * status:  reopened => closed
>   * resolution:  => wontfix
>
>
> Comment:
>
>  Closing again. We don't support Panther, and there obviously isn't
>  anything being done about this bug. Given that we have about 1500  
> more
>  open tickets than we can deal with, I believe this a reasonable  
> course of
>  action.

This is the second time you've closed this ticket for the sole reason  
that the problem occurs only on Panther. I previously reopened this  
ticket explaining that's not a good reason for closing. You've closed  
other tickets for the same reason. Up to now, we have not had a  
policy of closing tickets for the sole reason that they are Panther- 
specific. While we do not officially support Panther, the policy thus  
far has been that we would still accept patches to fix things for  
Panther. I find it useful to have bug reports filed for issues, even  
if a fix is not immediately known, that way interested parties can  
see the report and Cc themselves and offer input. The number of open  
tickets in the database has no bearing on this. If you would like  
MacPorts to adopt a policy of declining to fix Panther issues and  
immediately closing Panther tickets, let's discuss that proposal here.

My feeling was that getting the gcc4 ports working again on Panther  
was of particular importance, since otherwise no software that  
requires gcc 4.x can be compiled on Panther, since Panther's Xcode  
1.5 only includes gcc 3.3. That is why I filed some gcc tickets and  
added comments to others.


From blb at macports.org  Wed May 20 19:39:37 2009
From: blb at macports.org (Bryan Blackburn)
Date: Wed, 20 May 2009 20:39:37 -0600
Subject: Panther tickets
In-Reply-To: <D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>
References: <056.8c0a9be3e8d65bb3091c817ea800dfdc@macports.org>
	<065.c129f4215823d49ec7e0c6f172f3928a@macports.org>
	<D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>
Message-ID: <20090521023937.GM22252@ninagal.withay.com>

On Wed, May 20, 2009 at 09:22:51PM -0500, Ryan Schmidt said:
[...]
>
> This is the second time you've closed this ticket for the sole reason  
> that the problem occurs only on Panther. I previously reopened this  
> ticket explaining that's not a good reason for closing. You've closed  
> other tickets for the same reason. Up to now, we have not had a policy of 
> closing tickets for the sole reason that they are Panther-specific. While 
> we do not officially support Panther, the policy thus far has been that we 
> would still accept patches to fix things for Panther. I find it useful to 
> have bug reports filed for issues, even if a fix is not immediately known, 
> that way interested parties can see the report and Cc themselves and offer 
> input. The number of open tickets in the database has no bearing on this. 
> If you would like MacPorts to adopt a policy of declining to fix Panther 
> issues and immediately closing Panther tickets, let's discuss that 
> proposal here.

The number of open tickets does affect one's ability to go through the list
of old, open tickets looking for things to fix.  Granted, you can look
(usually) in the summary, or opening the ticket to see in the description,
that it is against 10.3 and move on, but it's still just one more thing to
deal with.

For MacPorts on 10.3, without some major changes to base either in redoing
some of the GSoC privileges code or bringing in an implementation of lchown,
MacPorts trunk/1.8 isn't going to even build on 10.3.  With 10.6 looming and
MacPorts' continual shortness of people contributing (especially on base,
and more especially on base for 10.3), I really don't think even vaguely
hinting that supporting 10.3 is all that honest for us at this point.
Personally I don't think that is fair to the users, and I am sorry for those
still using 10.3 but if we don't have anyone actively using 10.3 and
developing on MacPorts, we need to be true to what can be done.

>
> My feeling was that getting the gcc4 ports working again on Panther was of 
> particular importance, since otherwise no software that requires gcc 4.x 
> can be compiled on Panther, since Panther's Xcode 1.5 only includes gcc 
> 3.3. That is why I filed some gcc tickets and added comments to others.

Do we know if anyone is actually attempting to get any gcc4 building on
10.3?  Also, for real support wouldn't we need to bring in Apple's patches
against gcc4 (like gcc 4.0.1 on Xcode 2+) to truly bring support of gcc4?  I
know there are some things which compile fine with Xcode's gcc but not with
one of the ports.

Bryan


From jkh at apple.com  Wed May 20 20:43:56 2009
From: jkh at apple.com (Jordan K. Hubbard)
Date: Wed, 20 May 2009 20:43:56 -0700
Subject: Panther tickets
In-Reply-To: <D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>
References: <056.8c0a9be3e8d65bb3091c817ea800dfdc@macports.org>
	<065.c129f4215823d49ec7e0c6f172f3928a@macports.org>
	<D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>
Message-ID: <A35FF40E-2092-4B98-8448-2A51E481B4E4@apple.com>


On May 20, 2009, at 7:22 PM, Ryan Schmidt wrote:

> This is the second time you've closed this ticket for the sole  
> reason that the problem occurs only on Panther. I previously  
> reopened this ticket explaining that's not a good reason for  
> closing. You've closed other tickets for the same reason. Up to now,  
> we have not had a policy of closing tickets for the sole reason that  
> they are Panther-specific. While we do not officially support  
> Panther, the policy thus far has been that we would still accept  
> patches to fix things for Panther. I find it useful to have bug  
> reports filed for issues, even if a fix is not immediately known,  
> that way interested parties can see the report and Cc themselves and  
> offer input. The number of open tickets in the database has no  
> bearing on this. If you would like MacPorts to adopt a policy of  
> declining to fix Panther issues and immediately closing Panther  
> tickets, let's discuss that proposal here.

OK, so, let's discuss it.  I'll start:  I think continuing to support  
Panther, even by inference or continued acceptance of patches to  
support it, is a really bad idea and here are some (though by no means  
all) of the reasons why it's a bad idea:

1. Every #ifdef or Panther-only work around adds to the overall  
support burden of MacPorts.  Some day, assuming MacPorts lives long  
enough to have such problems, most of the current set of people will  
be retired / MIA / dead and it will fall to a new crop of engineers to  
support the aging ball of goop collectively known as MacPorts.  For  
each and every line of legacy support code, the justification(s) for  
which will have long since vanished into the fog of history, the  
burdens on these people will only be increased.  Think of your  
successors ("think of the children!") even if it's a burden you,  
personally are willing to shoulder today.

2. The marketing figures are not generally available, nor can I make  
such figures generally available, so you're just going to have to take  
my word for it that the overall percentage of Apple customers still  
running Panther is small.  It might be a user base which is  
occasionally loud, in certain specific cases, but that still does not  
make it large or even noteworthy.  "The needs of the many outweigh the  
needs of the few", to quote Spock (and what argument isn't instantly  
won by quoting Spock, I ask you? :-).  If you're not someone who goes  
in for Spock, then simply substitute the law of diminishing returns.

3. At the risk of stating the obvious, you are an open source project  
that provides its labor for free.  Given that fact, there will also  
always be users / companies / evil foreign governments who are more  
than willing to ask for, nay demand, the moon and the stars because  
there are these silly people giving celestial objects away for free,  
or so they heard anyway, and WHAT HAVE YOU DONE FOR US LATELY?  In  
such an environment, it has also been shown that the decibel level of  
ambient whining can be significantly decreased once the project  
demonstrates some ability to set and enforce the boundaries of "just  
what we're willing to do", drawing various lines in the sand when  
appropriate.  An n-release support policy, where n is some mutually  
agreeable constant (my favorite is "2"), is also one such useful line  
in the sand to draw.

- Jordan






From talklists at newgeo.com  Wed May 20 23:06:28 2009
From: talklists at newgeo.com (Scott Haneda)
Date: Wed, 20 May 2009 23:06:28 -0700
Subject: Ports Future [was Re: Panther tickets]
In-Reply-To: <A35FF40E-2092-4B98-8448-2A51E481B4E4@apple.com>
References: <056.8c0a9be3e8d65bb3091c817ea800dfdc@macports.org>
	<065.c129f4215823d49ec7e0c6f172f3928a@macports.org>
	<D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>
	<A35FF40E-2092-4B98-8448-2A51E481B4E4@apple.com>
Message-ID: <3FE72974-0108-4DD0-8C40-782B9C45C352@newgeo.com>

Hijacking this to a new thread.  First time posting to the dev list,  
be gentle...

On May 20, 2009, at 8:43 PM, Jordan K. Hubbard wrote:

> 1. Every #ifdef or Panther-only work around adds to the overall  
> support burden of MacPorts.  Some day, assuming MacPorts lives long  
> enough to have such problems, most of the current set of people will  
> be retired / MIA / dead and it will fall to a new crop of engineers  
> to support the aging ball of goop collectively known as MacPorts.

This sounds ominous.  I push ports over fink all the time.  I never  
really knew why, until one day.  I saw there were a few apple.com  
email addresses on this list, and I also saw it was part of  
MacOSForge, which has a tie in to Apple in some way.

I translated this as meaning there was at least a stronger chance of  
ports lasting the test of time than anything else.

Is MacPorts in danger of dying a slow death?  I am still working on a  
number of ports, that one day will all tie into each other, to produce  
a simple and cohesive system/tool that I think will be valuable to a  
very large set of Mac OS X users.

It is a lot of work, should I be worried at all?
Thank you for your responses on this topic.
-- 
Scott * If you contact me off list replace talklists@ with scott@ *


From talklists at newgeo.com  Wed May 20 23:17:09 2009
From: talklists at newgeo.com (Scott Haneda)
Date: Wed, 20 May 2009 23:17:09 -0700
Subject: Panther tickets
In-Reply-To: <20090521023937.GM22252@ninagal.withay.com>
References: <056.8c0a9be3e8d65bb3091c817ea800dfdc@macports.org>
	<065.c129f4215823d49ec7e0c6f172f3928a@macports.org>
	<D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>
	<20090521023937.GM22252@ninagal.withay.com>
Message-ID: <6FD2B7B6-8375-4003-A4B2-FAB77F73ECCD@newgeo.com>

On May 20, 2009, at 7:39 PM, Bryan Blackburn wrote:

> The number of open tickets does affect one's ability to go through  
> the list
> of old, open tickets looking for things to fix.  Granted, you can look
> (usually) in the summary, or opening the ticket to see in the  
> description,
> that it is against 10.3 and move on, but it's still just one more  
> thing to
> deal with.


I probably can not get up to seed enough to assist in the core of  
Ports.  I was once told it is all just tcl code, if that is the case,  
there may be a chance I could contribute.  The mention of ifdefs makes  
me think it is not in fact just tcl.

Can I take a role in the ticketing system?  How would I go about  
proving myself to be capable of adding support in the area of the bug  
tracker?

I have extra machines, I can at the very least, take the new ports,  
test if they build, and give them a thumbs up or down in regards to if  
they build out or not.

I think I grasp the general idea of how a port file works well enough  
to see blatant bugs in a portfile, at least, new ones.  Older ones,  
seem to have a good system in place where dialogue is hashed out to  
get them working correctly.

I can make the time to help, if my offer is warranted or needed.  I  
would love to give back something for all the hand holding I received  
originally on the users list when I first was getting my feet wet.

For what it is worth, I would officially drop 10.3 support. It is  
getting to the point where the hardware that runs 10.3 will be slower  
than the next iPhone :)  Further, ports very nature is a technical  
one.  Most of the ports are command line tools.  Yes, there are those  
that are window managed, those would probably run terribly on 10.3  
hardware as well.

If the one of the very core natures of ports is for an "advanced" use,  
it makes sense that people would want to take advantage of current  
compilers, and current features of the most modern OS there is.  Not  
to say that 10.3 can not be used with ports, I am sure versions will  
still be downloadable, but I do not feel any of the already limited  
resources should be put towards 10.3.
-- 
Scott * If you contact me off list replace talklists@ with scott@ *


From jkh at apple.com  Wed May 20 23:27:51 2009
From: jkh at apple.com (Jordan K. Hubbard)
Date: Wed, 20 May 2009 23:27:51 -0700
Subject: Ports Future [was Re: Panther tickets]
In-Reply-To: <3FE72974-0108-4DD0-8C40-782B9C45C352@newgeo.com>
References: <056.8c0a9be3e8d65bb3091c817ea800dfdc@macports.org>
	<065.c129f4215823d49ec7e0c6f172f3928a@macports.org>
	<D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>
	<A35FF40E-2092-4B98-8448-2A51E481B4E4@apple.com>
	<3FE72974-0108-4DD0-8C40-782B9C45C352@newgeo.com>
Message-ID: <23DE5E86-2467-4CAD-A7DA-58E49D4E7CE6@apple.com>


On May 20, 2009, at 11:06 PM, Scott Haneda wrote:

> Hijacking this to a new thread.  First time posting to the dev list,  
> be gentle...
>
> On May 20, 2009, at 8:43 PM, Jordan K. Hubbard wrote:
>
>> 1. Every #ifdef or Panther-only work around adds to the overall  
>> support burden of MacPorts.  Some day, assuming MacPorts lives long  
>> enough to have such problems, most of the current set of people  
>> will be retired / MIA / dead and it will fall to a new crop of  
>> engineers to support the aging ball of goop collectively known as  
>> MacPorts.
>
> This sounds ominous.  I push ports over fink all the time.  I never  
> really knew why, until one day.  I saw there were a few apple.com  
> email addresses on this list, and I also saw it was part of  
> MacOSForge, which has a tie in to Apple in some way.
>
> I translated this as meaning there was at least a stronger chance of  
> ports lasting the test of time than anything else.

Anything is possible, though also bear in mind the fact that we  
probably have different time-scales in mind for those "ominous words"  
I uttered.  When I said "some day", I meant "sometime in the next 20  
years" since those are the time scales in which I consider software  
(unless said software is a computer language, in which case double  
that) living a full and complete life-span.

I don't see that MacPorts is in any imminent danger, no.  My  
prediction is rather that it will continue to grow and slowly morph as  
it tracks various Mac OS X releases from Apple.  It's specifically the  
fact that it has to "impedance match" for each OS release differently  
that makes the length of its legacy tail even more critical than it  
would be for most software systems, since that matching extends from  
the base infrastructure all the way out into the various ports which  
sometimes need to specify different platform blocks for each release  
variant they're expected to support.  That's a big ship to try to send  
in 4 directions at once.

If it were me calling the shots, and it's not, what I'd probably do is  
fork the entire macports tree with a -legacy branch, the purpose for  
which is defined as "everything from Panther back to Cheetah, if  
people really want", and leave -trunk advancing along with a "whatever  
the last n releases are" support policy, older releases dropping off  
into the -legacy branch to die a slower, semi-supported death.  Then,  
at least, those poor unfortunates who are constrained to $ 
{someOldRelease} of MacOSX have the option of self-support by being  
given a place to work.

- Jordan


From afb at macports.org  Thu May 21 01:02:47 2009
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Thu, 21 May 2009 10:02:47 +0200
Subject: Panther tickets
In-Reply-To: <D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>
References: <056.8c0a9be3e8d65bb3091c817ea800dfdc@macports.org>
	<065.c129f4215823d49ec7e0c6f172f3928a@macports.org>
	<D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>
Message-ID: <C1465554-7F82-4829-8710-E186397EF390@macports.org>

Ryan Schmidt wrote:

> This is the second time you've closed this ticket for the sole  
> reason that the problem occurs only on Panther. I previously  
> reopened this ticket explaining that's not a good reason for  
> closing. You've closed other tickets for the same reason. Up to  
> now, we have not had a policy of closing tickets for the sole  
> reason that they are Panther-specific. While we do not officially  
> support Panther, the policy thus far has been that we would still  
> accept patches to fix things for Panther. I find it useful to have  
> bug reports filed for issues, even if a fix is not immediately  
> known, that way interested parties can see the report and Cc  
> themselves and offer input. The number of open tickets in the  
> database has no bearing on this. If you would like MacPorts to  
> adopt a policy of declining to fix Panther issues and immediately  
> closing Panther tickets, let's discuss that proposal here.

Other build systems support "chroot" building, and with those it  
isn't such a
hassle to build for older systems by using something like a SDK or  
even a full
OS installation in order to test the package after it has been built.  
But since
MacPorts doesn't have that, it makes supporting older releases more  
manual labor ?

I think you should explicitly drop Panther support for MacPorts 1.8  
and beyond,
do something like Fink did: http://www.finkproject.org/news/ (under  
2008-07-23).
However I do think that MP should support Tiger for a while longer,  
even with the
two Leopards, although it makes for supporting three releases. But  
that's just me.


My own reasons for dropping Panther was that my motherboard did on my  
old machine
and because it was easier to use the same SDK (10.4u) when doing  
universal builds.
Before it would use one SDK and one compiler (3.3) on PowerPC and  
another SDK and
another compiler (4.0) on Intel and it made for tricky debugging. So  
I upgraded...

There were a few complaints about Panther missing, but more about  
Leopard issues -
fortunately most of them could be handled by revising the Universal/ 
10.4u build.
These days the issues seems to mostly be about 64-bit Intel rather  
than PowerPC,
but supporting that would require getting a new computer (or do  
"blind" builds).


> My feeling was that getting the gcc4 ports working again on Panther  
> was of particular importance, since otherwise no software that  
> requires gcc 4.x can be compiled on Panther, since Panther's Xcode  
> 1.5 only includes gcc 3.3. That is why I filed some gcc tickets and  
> added comments to others.

Or just let Panther die with gcc-3.3, just like Jaguar had 3.1 or  
Puma had 2.95 ?

I'm sure there are going to be new stuff that only builds with  
gcc-4.2 and later.

--anders


From jmr at macports.org  Thu May 21 01:46:11 2009
From: jmr at macports.org (Joshua Root)
Date: Thu, 21 May 2009 18:46:11 +1000
Subject: Panther tickets
In-Reply-To: <20090521023937.GM22252@ninagal.withay.com>
References: <056.8c0a9be3e8d65bb3091c817ea800dfdc@macports.org>	<065.c129f4215823d49ec7e0c6f172f3928a@macports.org>	<D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>
	<20090521023937.GM22252@ninagal.withay.com>
Message-ID: <4A1514D3.1060204@macports.org>

On 2009-5-21 12:39, Bryan Blackburn wrote:
> For MacPorts on 10.3, without some major changes to base either in redoing
> some of the GSoC privileges code or bringing in an implementation of lchown,
> MacPorts trunk/1.8 isn't going to even build on 10.3.  With 10.6 looming and
> MacPorts' continual shortness of people contributing (especially on base,
> and more especially on base for 10.3), I really don't think even vaguely
> hinting that supporting 10.3 is all that honest for us at this point.
> Personally I don't think that is fair to the users, and I am sorry for those
> still using 10.3 but if we don't have anyone actively using 10.3 and
> developing on MacPorts, we need to be true to what can be done.

+1

Panther has been unsupported since 1.6.0 (as per the 2-latest-releases
policy), and we're basically just continuing to provide dmgs for it
because someone happens to have an machine with it installed and 1.7.1
still builds there without any special coercion. If this is giving the
wrong impression, we should stop (if the release of 1.8 doesn't stop it
for us first).

If we need to come up with an official policy for handling tickets
related to unsupported platforms, I would suggested immediately closing
them as WONTFIX unless a patch is provided. While Jordan certainly has a
point about future maintainability, I don't think it's too bad if the
legacy goop is all contained inside a darwin_7 platform variant, so
rejecting patches seems a little harsh.

Finally, if someone really wants to create a branch for legacy support,
they are welcome to do so, though I agree it seems like a lot of work
for the benefit it would provide.

- Josh

From afb at macports.org  Thu May 21 02:13:52 2009
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Thu, 21 May 2009 11:13:52 +0200
Subject: Ports Future [was Re: Panther tickets]
In-Reply-To: <23DE5E86-2467-4CAD-A7DA-58E49D4E7CE6@apple.com>
References: <056.8c0a9be3e8d65bb3091c817ea800dfdc@macports.org>
	<065.c129f4215823d49ec7e0c6f172f3928a@macports.org>
	<D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>
	<A35FF40E-2092-4B98-8448-2A51E481B4E4@apple.com>
	<3FE72974-0108-4DD0-8C40-782B9C45C352@newgeo.com>
	<23DE5E86-2467-4CAD-A7DA-58E49D4E7CE6@apple.com>
Message-ID: <55AE6A22-7D3C-431F-92A3-5025FBB0E9DD@macports.org>

Jordan K. Hubbard wrote:

> If it were me calling the shots, and it's not, what I'd probably do  
> is fork the entire macports tree with a -legacy branch, the purpose  
> for which is defined as "everything from Panther back to Cheetah,  
> if people really want", and leave -trunk advancing along with a  
> "whatever the last n releases are" support policy, older releases  
> dropping off into the -legacy branch to die a slower, semi- 
> supported death.  Then, at least, those poor unfortunates who are  
> constrained to ${someOldRelease} of MacOSX have the option of self- 
> support by being given a place to work.

Gathered some statistical legacy data:

MacPorts Mac OS X Releases Build Date
-------- ----------------- ----------
1.0      10.2, 10.3, 10.4  2005-04-28
1.1      10.2, 10.3, 10.4  2005-10-10
1.2            10.3, 10.4  2005-12-14
1.3                  10.4  2006-07-27
dp2mp
1.4.0    10.3, 10.4        2007-03-27
1.5.0    10.3, 10.4, 10.5  2007-07-09
1.6.0    10.3, 10.4, 10.5  2007-12-16
1.7.0    10.3, 10.4, 10.5  2008-12-14

It seems the value of n is around 3...

So the "logical" follow up would be:

1.8.0    10.4, 10.5, 10.6  2009 or so
1.9.0    10.4, 10.5, 10.6  2010 or so

And hopefully - by then the "Ports 2.0"
would provide something better instead :-)

Like an integrated package manager say,
and a better (graphic?) user experience...

--anders


From ryandesign at macports.org  Thu May 21 02:22:09 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 21 May 2009 04:22:09 -0500
Subject: Gettext only at build time (was: [51224]
	trunk/dports/gnome/gdl/Portfile
In-Reply-To: <20090521072615.F0CD91B8EFDB@beta.macosforge.org>
References: <20090521072615.F0CD91B8EFDB@beta.macosforge.org>
Message-ID: <DCBA9F54-4B17-42A7-A39C-1C3624AEBEAD@macports.org>


On May 21, 2009, at 02:26, devans at macports.org wrote:

> +depends_build       port:pkgconfig \
> +                    port:intltool \
> +                    port:gettext \
> +                    port:p5-xml-parser \
> +                    port:gtk-doc

I've seen other ports list gettext as a build dependency, but I've  
always wondered what kind of software would want to use gettext at  
build time but not at runtime? How does that work? It is a  
localization system, and the way it's usually used is to compile text  
message catalogs into a binary form at build time, and to link with  
the libintl library, and at runtime to use libintl to load those  
message catalogs and pull translations out of them.


From milosh at macports.org  Thu May 21 02:43:19 2009
From: milosh at macports.org (Emmanuel Hainry)
Date: Thu, 21 May 2009 11:43:19 +0200
Subject: Panther tickets
In-Reply-To: <4A1514D3.1060204@macports.org>
References: <056.8c0a9be3e8d65bb3091c817ea800dfdc@macports.org>
	<065.c129f4215823d49ec7e0c6f172f3928a@macports.org>
	<D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>
	<20090521023937.GM22252@ninagal.withay.com>
	<4A1514D3.1060204@macports.org>
Message-ID: <20090521094319.GA2798@velsheda.lateralis.org>

Citando Joshua Root :
> 
> Panther has been unsupported since 1.6.0 (as per the 2-latest-releases
> policy), and we're basically just continuing to provide dmgs for it
> because someone happens to have an machine with it installed and 1.7.1
> still builds there without any special coercion. If this is giving the
> wrong impression, we should stop (if the release of 1.8 doesn't stop it
> for us first).

The problem with panther is that it doesn't have svn, so building from
source is quite difficult. However, I agree that macports should not
provide official binaries for unsupported architectures.

> If we need to come up with an official policy for handling tickets
> related to unsupported platforms, I would suggested immediately closing
> them as WONTFIX unless a patch is provided. While Jordan certainly has a
> point about future maintainability, I don't think it's too bad if the
> legacy goop is all contained inside a darwin_7 platform variant, so
> rejecting patches seems a little harsh.

You should also drop bugfixing for anything not macosx (linux, bsd,
puredarwin). Jordan's plan would mean you can remove a lot of code from
base: why are there different gcc default, different x11prefix? Why
should you care that some people use powerpc architectures, their
machines should already be dead (mine is) so only supporting the next
macosx release should be okay.

If browsing the hundreds of open tickets is a hassle because of 10
concerning other systems than leopard, give them a particular milestone
or filter or whatever like "port submissions" has so that they don't
appear in the list of "broken things that concern supported os". I
consider that closing them as wontfix should only be done once they have
laid untouched for some weeks.

Emmanuel

From jmr at macports.org  Thu May 21 03:26:31 2009
From: jmr at macports.org (Joshua Root)
Date: Thu, 21 May 2009 20:26:31 +1000
Subject: Panther tickets
In-Reply-To: <20090521094319.GA2798@velsheda.lateralis.org>
References: <056.8c0a9be3e8d65bb3091c817ea800dfdc@macports.org>	<065.c129f4215823d49ec7e0c6f172f3928a@macports.org>	<D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>	<20090521023937.GM22252@ninagal.withay.com>	<4A1514D3.1060204@macports.org>
	<20090521094319.GA2798@velsheda.lateralis.org>
Message-ID: <4A152C57.7000501@macports.org>

On 2009-5-21 19:43, Emmanuel Hainry wrote:
> The problem with panther is that it doesn't have svn, so building from
> source is quite difficult.

We do provide source tarballs for each release.

- Josh

From david.osguthorpe at gmail.com  Thu May 21 07:39:39 2009
From: david.osguthorpe at gmail.com (David Osguthorpe)
Date: Thu, 21 May 2009 08:39:39 -0600
Subject: Panther tickets
In-Reply-To: <20090521094319.GA2798@velsheda.lateralis.org>
References: <056.8c0a9be3e8d65bb3091c817ea800dfdc@macports.org>
	<065.c129f4215823d49ec7e0c6f172f3928a@macports.org>
	<D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>
	<20090521023937.GM22252@ninagal.withay.com>
	<4A1514D3.1060204@macports.org>
	<20090521094319.GA2798@velsheda.lateralis.org>
Message-ID: <20090521143939.GA2884@mactelhm.local>

On Thu, May 21, 2009 at 03:43:19AM -0600, Emmanuel Hainry wrote:
> 
> 
> You should also drop bugfixing for anything not macosx (linux, bsd,
> puredarwin). Jordan's plan would mean you can remove a lot of code from
> base: why are there different gcc default, different x11prefix? Why
> should you care that some people use powerpc architectures, their
> machines should already be dead (mine is) so only supporting the next
> macosx release should be okay.
> 

I really get concerned when I see statements like this - so much that I start
thinking maybe forking macports to eg. linuxports is needed - or maybe back
to darwinports

I only switched to Tiger early last year (does nobody remember how unstable Tiger was
compared to Panther) - and it still doesnt have a feature
I was using under Panther - that is a working kernel extension for reading and writing
ext2/3 filesystems - my Pismo machine (came with OS 9) is still running under Linux
so life time can be a lot longer than yours  (my NexT black slab still booted last time I tried)
- Ive had a delay for a year or so from Darwinports/Macports because of the
Darwinports/Macports name change and didnt want to destroy
my working setup with the name change - Im sure the update procedure would not have changed the
targets of the symbolic links I was using under /opt/local/var/db/dports
Only reason why Im getting back now is because I recently got a new machine which
of course is now Intel so nothing from any previous powerpc machine was useful so I had no
option but a fresh install - and Im working through re-implementing my various fixups to base
(I still dont have a working reading/writing ext2/3 file reader - Im using fuse on OSX
but neither of the 2 ext2/3 fuse modules look reliable enough for writing at the moment
- and yes I dual boot linux so I need access to ext2/ext3 file systems)

One if the things that I like about Darwinports/Macports was the encapsulation of the
building of open source projects - I do a lot of downloading software and adding my own
personalizations and Ive found the Portfile approach relatively easy to adapt for this
(yes Ive made my own SPEC files for rpms and Portfiles seemed much simpler to the Fink
Makefiles which Ive looked at and what Ive seen of dpkgs so far for Ubuntu doesnt seem easy)
so Im seriously thinking about using "LinuxPorts" on the Linux side to control 
software I might download and add changes to

By keeping to very basic generic Unix tools/options/commands you can solve the above
problems and keep Darwinports/Macports working for as many systems as possible

David

From brad at pixilla.com  Thu May 21 08:40:25 2009
From: brad at pixilla.com (Bradley Giesbrecht)
Date: Thu, 21 May 2009 08:40:25 -0700
Subject: Panther tickets
In-Reply-To: <20090521143939.GA2884@mactelhm.local>
References: <056.8c0a9be3e8d65bb3091c817ea800dfdc@macports.org>
	<065.c129f4215823d49ec7e0c6f172f3928a@macports.org>
	<D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>
	<20090521023937.GM22252@ninagal.withay.com>
	<4A1514D3.1060204@macports.org>
	<20090521094319.GA2798@velsheda.lateralis.org>
	<20090521143939.GA2884@mactelhm.local>
Message-ID: <783DCFDB-D68B-4819-995D-2465D0DC9816@pixilla.com>


On May 21, 2009, at 7:39 AM, David Osguthorpe wrote:

> On Thu, May 21, 2009 at 03:43:19AM -0600, Emmanuel Hainry wrote:
>>
>>
>> You should also drop bugfixing for anything not macosx (linux, bsd,
>> puredarwin). Jordan's plan would mean you can remove a lot of code  
>> from
>> base: why are there different gcc default, different x11prefix? Why
>> should you care that some people use powerpc architectures, their
>> machines should already be dead (mine is) so only supporting the next
>> macosx release should be okay.
>>
>
> I really get concerned when I see statements like this - so much  
> that I start
> thinking maybe forking macports to eg. linuxports is needed - or  
> maybe back
> to darwinports

<snip>

This concerns me as well. Emmanuel, we should care because if you keep  
dividing up the user base like that we end up supporting less and  
less. Go ahead and make the same decision but do so while caring about  
others.

I just recently retired my G3 mail server (12+ years) replacing it  
with a dual G5 powerpc not because it died but because the software I  
was using no longer met my needs.

I plan on keeping G5 machines around for another 10 years or so. G5's  
are masterfully constructed and should not add to landfills for some   
time to come.

I'm not voting for or against Panther. I do vote to support platforms  
and systems as long as is economically viable.


//Brad

From afb at macports.org  Thu May 21 08:44:40 2009
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Thu, 21 May 2009 17:44:40 +0200
Subject: Panther tickets
In-Reply-To: <20090521143939.GA2884@mactelhm.local>
References: <056.8c0a9be3e8d65bb3091c817ea800dfdc@macports.org>
	<065.c129f4215823d49ec7e0c6f172f3928a@macports.org>
	<D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>
	<20090521023937.GM22252@ninagal.withay.com>
	<4A1514D3.1060204@macports.org>
	<20090521094319.GA2798@velsheda.lateralis.org>
	<20090521143939.GA2884@mactelhm.local>
Message-ID: <E3291214-A289-454D-8AF3-BEA404510BAD@macports.org>

David Osguthorpe wrote:
> On Thu, May 21, 2009 at 03:43:19AM -0600, Emmanuel Hainry wrote:
>> You should also drop bugfixing for anything not macosx (linux, bsd,
>> puredarwin). Jordan's plan would mean you can remove a lot of code  
>> from
>> base: why are there different gcc default, different x11prefix? Why
>> should you care that some people use powerpc architectures, their
>> machines should already be dead (mine is) so only supporting the next
>> macosx release should be okay.

Only supporting Snow Leopard seems a bit narrow, in terms of  
platforms...

I think it would make sense to keep the +puredarwin variant now that
puredarwin.org are using it to provide software for the Darwin 9 OS ?
Not supporting the previous releases (Darwin 7.0 and Darwin 8.0) seems
reasonable, even though MacPorts still did work OK on those as well.

Support for FreeBSD was revived in order to have a free OS platform to
test it on, and then GNU/Linux was added just to test the portability.
Neither of those are very serious, in terms of actual available ports,
even they do come in handy some times for mirroring and other purposes.

But neither (pure/bsd/gnu) is "supported" like Mac OS X is, of course.

> I really get concerned when I see statements like this - so much  
> that I start
> thinking maybe forking macports to eg. linuxports is needed - or  
> maybe back
> to darwinports
...
> One if the things that I like about Darwinports/Macports was the  
> encapsulation of the
> building of open source projects - I do a lot of downloading  
> software and adding my own
> personalizations and Ive found the Portfile approach relatively  
> easy to adapt for this
> (yes Ive made my own SPEC files for rpms and Portfiles seemed much  
> simpler to the Fink
> Makefiles which Ive looked at and what Ive seen of dpkgs so far for  
> Ubuntu doesnt seem easy)
> so Im seriously thinking about using "LinuxPorts" on the Linux side  
> to control
> software I might download and add changes to
...
> By keeping to very basic generic Unix tools/options/commands you  
> can solve the above
> problems and keep Darwinports/Macports working for as many systems  
> as possible


It should be _easier_ to run MacPorts on other platforms now that the
Foundation requirement (e.g. GNUstep) has been made optional instead ?

Ironically it was the Tcl requirement that was causing the problems on
newer Linux, since it doesn't always come with the threaded capability
that MacPorts requires (for instance Fedora's tcl package doesn't work),
even if for instance mtree and gnustep weren't normally available  
either.

There are several things, like user creation or service starting/ 
stopping,
that needs porting to other operating systems if it should be usable  
there.
And probably a large number of ports also would need some minor  
patching or
adjustments before they would run on other platforms, due to  
hardcoding Mac.

But it should still be "possible" to install MP 1.7 on Linux, even if  
there
were no packages* made for it - due to the lack of cross-platform  
interest...

--anders


* Like the ones for MP 1.6: http://trac.macports.org/browser/users/ 
afb/GA
   Packages were available for FreeBSD (tbz), Fedora (rpm) and Ubuntu  
(deb)


From devans at macports.org  Thu May 21 09:55:32 2009
From: devans at macports.org (David Evans)
Date: Thu, 21 May 2009 09:55:32 -0700
Subject: Gettext only at build time
In-Reply-To: <DCBA9F54-4B17-42A7-A39C-1C3624AEBEAD@macports.org>
References: <20090521072615.F0CD91B8EFDB@beta.macosforge.org>
	<DCBA9F54-4B17-42A7-A39C-1C3624AEBEAD@macports.org>
Message-ID: <4A158784.3040901@macports.org>

Ryan Schmidt wrote:
>
> On May 21, 2009, at 02:26, devans at macports.org wrote:
>
>> +depends_build       port:pkgconfig \
>> +                    port:intltool \
>> +                    port:gettext \
>> +                    port:p5-xml-parser \
>> +                    port:gtk-doc
>
> I've seen other ports list gettext as a build dependency, but I've 
> always wondered what kind of software would want to use gettext at 
> build time but not at runtime? How does that work? It is a 
> localization system, and the way it's usually used is to compile text 
> message catalogs into a binary form at build time, and to link with 
> the libintl library, and at runtime to use libintl to load those 
> message catalogs and pull translations out of them.
>
You're right, of course, Ryan.  Feel free to remove the build dependency 
on gettext anywhere you see  it in the gnome ports I've been
updating.  At the same time, it doesn't need to be added to depends_lib 
for these ports (or any gtk2 app) because it is a library dependency
of gtk2. 

Thanks for calling me on this.  A second pair of eyes is always useful.

Dave

From walt at wump.org  Thu May 21 10:28:12 2009
From: walt at wump.org (Walt Pawley)
Date: Thu, 21 May 2009 10:28:12 -0700
Subject: Panther tickets
In-Reply-To: <E3291214-A289-454D-8AF3-BEA404510BAD@macports.org>
References: <056.8c0a9be3e8d65bb3091c817ea800dfdc@macports.org>
	<065.c129f4215823d49ec7e0c6f172f3928a@macports.org>
	<D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>
	<20090521023937.GM22252@ninagal.withay.com>
	<4A1514D3.1060204@macports.org>
	<20090521094319.GA2798@velsheda.lateralis.org>
	<20090521143939.GA2884@mactelhm.local>
	<E3291214-A289-454D-8AF3-BEA404510BAD@macports.org>
Message-ID: <p06240834c63b3c831967@[10.0.0.10]>

Not that my opinion matters, but here it is anyway.

I have basically quit attempting to use Macports, though I
still pay some attention to the list. Long ago it became
obvious to me that Macports was more about surfing the bleeding
edge than about developing and maintaining useful software ...
much as is the case with Apple itself. Apple has a motive:
selling new stuff. What the Macports motive is escapes me.

There are lots of old Macs out there. Having a solid base of
open source software available for them would be a tremendously
useful thing. Unfortunately, IMHO, Macports has let the
opportunity to do that die in the wakes of the surf boards.
-- 

Walter M. Pawley <walt at wump.org>
Wump Research & Company
676 River Bend Road, Roseburg, OR 97471
         541-672-8975

From devans at macports.org  Thu May 21 10:29:19 2009
From: devans at macports.org (David Evans)
Date: Thu, 21 May 2009 10:29:19 -0700
Subject: [50797] trunk/dports/gnome/gnome-platform-suite/Portfile
In-Reply-To: <20090509204053.E4AA7180A9D5@beta.macosforge.org>
References: <20090509204053.E4AA7180A9D5@beta.macosforge.org>
Message-ID: <4A158F6F.40503@macports.org>

ryandesign at macports.org wrote:
>
> Revision
>     50797 <http://trac.macports.org/changeset/50797>
> Author
>     ryandesign at macports.org
> Date
>     2009-05-09 13:40:52 -0700 (Sat, 09 May 2009)
>
>
>       Log Message
>
> gnome-platform-suite:
>
>  * allow pango-devel to satisfy pango dependency
>  * pkgconfig is a build dependency, not a library dependency
>
>
>       Modified Paths
>
>     * trunk/dports/gnome/gnome-platform-suite/Portfile
>       <#trunkdportsgnomegnomeplatformsuitePortfile>
>
>
>       Diff
>
>
>         Modified: trunk/dports/gnome/gnome-platform-suite/Portfile
>         (50796 => 50797)
>
>
> --- trunk/dports/gnome/gnome-platform-suite/Portfile	2009-05-09 20:16:23 UTC (rev 50796)
> +++ trunk/dports/gnome/gnome-platform-suite/Portfile	2009-05-09 20:40:52 UTC (rev 50797)
> @@ -18,6 +18,7 @@
>  homepage        http://www.gnome.org/
>  master_sites    gnome
>  
> +depends_build   path:bin/pkg-config:pkgconfig
>  depends_lib     port:at-spi     \
>                  port:atk    \
>                  port:esound     \
> @@ -39,8 +40,7 @@
>                  port:libxml2    \
>                  port:libxslt    \
>                  port:orbit2     \
> -                port:pango      \
> -                port:pkgconfig  \
> +                path:lib/pkgconfig/pango.pc:pango \
>                  port:policykit-gnome
>  
>  distfiles

Ryan --

I agree with your pango change here but with respect to pkgconfig there 
was some method to my madness.   This is a meta package
that attempts to install a set of ports that the GNOME project refers to 
as the GNOME platform modules -- the basic set of packages
needed to develop GNOME applications and they list pkgconfig as one of 
these.  Thus, it seemed appropriate to me to make it a library
dependency in this case (one that shouldn't be removed after 
installation of this port) even though it strictly doesn't provide any
libraries used at run-time and normally would be a build dependency 
anywhere else.

Does this make any sense?   Also I'm not sure why you made it a path 
dependency.  Should this be done globally?

Dave

From jkh at apple.com  Thu May 21 11:39:23 2009
From: jkh at apple.com (Jordan K. Hubbard)
Date: Thu, 21 May 2009 11:39:23 -0700
Subject: Panther tickets
In-Reply-To: <20090521143939.GA2884@mactelhm.local>
References: <056.8c0a9be3e8d65bb3091c817ea800dfdc@macports.org>
	<065.c129f4215823d49ec7e0c6f172f3928a@macports.org>
	<D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>
	<20090521023937.GM22252@ninagal.withay.com>
	<4A1514D3.1060204@macports.org>
	<20090521094319.GA2798@velsheda.lateralis.org>
	<20090521143939.GA2884@mactelhm.local>
Message-ID: <7932E549-81C4-4A0E-8DA6-35BAB971874F@apple.com>


On May 21, 2009, at 7:39 AM, David Osguthorpe wrote:

> I really get concerned when I see statements like this - so much  
> that I start
> thinking maybe forking macports to eg. linuxports is needed - or  
> maybe back
> to darwinports

Which would gain you ... ?

We've had this debate before, and it always seems to boil down to  
"Hey, let's rip the non-MacOSX stuff out.  We're MacPorts, not  
*Ports!"  "No no, I had some Linux support working last year, even  
though it hasn't been maintained at all and only 10 ports actually  
work with it!" and then everyone tries to placate the person who put  
in that well-intentioned, but ultimately doomed (to rot) support by  
simply dropping the subject until the next time it comes up.

The fact remains pretty clear that the Linux folks and all the *BSDs  
have their own systems for managing software, and no more than a tiny  
fraction of their user base will ever use ours (the Gentoo BSD folks  
come to mind as another good example of that principle in action).   
Without users in any quantity, there is very little attention actually  
paid to the code in question and without attention, it becomes little  
more than the personal hobby of the few people who actually use that  
Linux/BSD/Solaris support code and MacPorts becomes an amalgam of  
common-good code and personal, pet projects.  Not my idea of a good  
time.

- Jordan


From jkh at apple.com  Thu May 21 11:47:46 2009
From: jkh at apple.com (Jordan K. Hubbard)
Date: Thu, 21 May 2009 11:47:46 -0700
Subject: Panther tickets
In-Reply-To: <p06240834c63b3c831967@[10.0.0.10]>
References: <056.8c0a9be3e8d65bb3091c817ea800dfdc@macports.org>
	<065.c129f4215823d49ec7e0c6f172f3928a@macports.org>
	<D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>
	<20090521023937.GM22252@ninagal.withay.com>
	<4A1514D3.1060204@macports.org>
	<20090521094319.GA2798@velsheda.lateralis.org>
	<20090521143939.GA2884@mactelhm.local>
	<E3291214-A289-454D-8AF3-BEA404510BAD@macports.org>
	<p06240834c63b3c831967@[10.0.0.10]>
Message-ID: <B0EFC4C4-3B78-4601-B263-6FADAED6218B@apple.com>


On May 21, 2009, at 10:28 AM, Walt Pawley wrote:

> I have basically quit attempting to use Macports, though I
> still pay some attention to the list. Long ago it became
> obvious to me that Macports was more about surfing the bleeding
> edge than about developing and maintaining useful software ...

Dr. Hyperbole, you have a call on line one!   Paging Dr. Hyperbole! ;-)

That's truly an unfounded assertion.  MacPorts has put considerable  
time and effort into supporting Tiger, Leopard and even SnowLeopard  
well in advance of its release.  If you check your calendar, you'll  
also notice that Tiger was released on April 29th, 2005 - just over 4  
years ago - and by the time support for Tiger is eventually dropped,  
which no one (you'll notice) is even *talking* about, MacPorts will  
have faithfully supported those users for 6 years or more.  "Bleeding  
edge?", puh-leeeze!

- Jordan


From dluke at geeklair.net  Thu May 21 12:12:57 2009
From: dluke at geeklair.net (Daniel J. Luke)
Date: Thu, 21 May 2009 15:12:57 -0400
Subject: Panther tickets
In-Reply-To: <B0EFC4C4-3B78-4601-B263-6FADAED6218B@apple.com>
References: <056.8c0a9be3e8d65bb3091c817ea800dfdc@macports.org>
	<065.c129f4215823d49ec7e0c6f172f3928a@macports.org>
	<D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>
	<20090521023937.GM22252@ninagal.withay.com>
	<4A1514D3.1060204@macports.org>
	<20090521094319.GA2798@velsheda.lateralis.org>
	<20090521143939.GA2884@mactelhm.local>
	<E3291214-A289-454D-8AF3-BEA404510BAD@macports.org>
	<p06240834c63b3c831967@[10.0.0.10]>
	<B0EFC4C4-3B78-4601-B263-6FADAED6218B@apple.com>
Message-ID: <9830A8D7-2581-4D90-8C90-EEE79D0F11E7@geeklair.net>

On May 21, 2009, at 2:47 PM, Jordan K. Hubbard wrote:
> That's truly an unfounded assertion.  MacPorts has put considerable  
> time and effort into supporting Tiger, Leopard and even SnowLeopard  
> well in advance of its release.  If you check your calendar, you'll  
> also notice that Tiger was released on April 29th, 2005 - just over  
> 4 years ago - and by the time support for Tiger is eventually  
> dropped, which no one (you'll notice) is even *talking* about,  
> MacPorts will have faithfully supported those users for 6 years or  
> more.  "Bleeding edge?", puh-leeeze!


It's probably also worth noting that eventually even Apple stops  
releasing updates for old OS versions, and in general people should  
probably not be running machines that are no longer receiving vender  
security updates.

... of course, anyone who wants to preserve support for old releases  
can always:

1- Generate patches
2- fork the project

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



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

From afb at macports.org  Thu May 21 15:34:47 2009
From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=)
Date: Fri, 22 May 2009 00:34:47 +0200
Subject: Panther tickets
In-Reply-To: <7932E549-81C4-4A0E-8DA6-35BAB971874F@apple.com>
References: <056.8c0a9be3e8d65bb3091c817ea800dfdc@macports.org>
	<065.c129f4215823d49ec7e0c6f172f3928a@macports.org>
	<D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>
	<20090521023937.GM22252@ninagal.withay.com>
	<4A1514D3.1060204@macports.org>
	<20090521094319.GA2798@velsheda.lateralis.org>
	<20090521143939.GA2884@mactelhm.local>
	<7932E549-81C4-4A0E-8DA6-35BAB971874F@apple.com>
Message-ID: <C29ADD5B-5CBB-4AA7-BCEF-03E4B0B786DA@macports.org>

Jordan K. Hubbard wrote:

> We've had this debate before, and it always seems to boil down to  
> "Hey, let's rip the non-MacOSX stuff out.  We're MacPorts, not  
> *Ports!"  "No no, I had some Linux support working last year, even  
> though it hasn't been maintained at all and only 10 ports actually  
> work with it!" and then everyone tries to placate the person who  
> put in that well-intentioned, but ultimately doomed (to rot)  
> support by simply dropping the subject until the next time it comes  
> up.

It would be easier if MacPorts did say right out what it was, and  
then any and all non-Mac stuff could indeed be forked off to a  
separate LinuxPorts branch instead. Would be easier to follow than  
this "we might be portable and maybe we can run elsewhere" policy.

The understanding so far was "that it can stay unless it gets in the  
way".

So if it does get in the way, then drop them at the same time as  
Panther ?

> The fact remains pretty clear that the Linux folks and all the  
> *BSDs have their own systems for managing software, and no more  
> than a tiny fraction of their user base will ever use ours (the  
> Gentoo BSD folks come to mind as another good example of that  
> principle in action).  Without users in any quantity, there is very  
> little attention actually paid to the code in question and without  
> attention, it becomes little more than the personal hobby of the  
> few people who actually use that Linux/BSD/Solaris support code and  
> MacPorts becomes an amalgam of common-good code and personal, pet  
> projects.  Not my idea of a good time.

I thought the idea was to have one system that could run on several,  
but since package management is one of the major brandings besides  
colors and mascots - it probably will never happen. It's even so  
"great" that GNU has a few and BSD has a few and Mac has a few.

So it's easier to make wrappers, and let each have their own  
implementation.

A single system could still be useful, but maybe MacPorts is not that  
system.

--anders


From brad at pixilla.com  Thu May 21 19:18:36 2009
From: brad at pixilla.com (Bradley Giesbrecht)
Date: Thu, 21 May 2009 19:18:36 -0700
Subject: Panther tickets
In-Reply-To: <7932E549-81C4-4A0E-8DA6-35BAB971874F@apple.com>
References: <056.8c0a9be3e8d65bb3091c817ea800dfdc@macports.org>
	<065.c129f4215823d49ec7e0c6f172f3928a@macports.org>
	<D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>
	<20090521023937.GM22252@ninagal.withay.com>
	<4A1514D3.1060204@macports.org>
	<20090521094319.GA2798@velsheda.lateralis.org>
	<20090521143939.GA2884@mactelhm.local>
	<7932E549-81C4-4A0E-8DA6-35BAB971874F@apple.com>
Message-ID: <BB312E63-FB3D-4595-B352-3760E33C73E6@pixilla.com>


On May 21, 2009, at 11:39 AM, Jordan K. Hubbard wrote:

>
> On May 21, 2009, at 7:39 AM, David Osguthorpe wrote:
>
>> I really get concerned when I see statements like this - so much  
>> that I start
>> thinking maybe forking macports to eg. linuxports is needed - or  
>> maybe back
>> to darwinports
>
> Which would gain you ... ?
>
> We've had this debate before, and it always seems to boil down to  
> "Hey, let's rip the non-MacOSX stuff out.  We're MacPorts, not  
> *Ports!"  "No no, I had some Linux support working last year, even  
> though it hasn't been maintained at all and only 10 ports actually  
> work with it!" and then everyone tries to placate the person who put  
> in that well-intentioned, but ultimately doomed (to rot) support by  
> simply dropping the subject until the next time it comes up.
>
> The fact remains pretty clear that the Linux folks and all the *BSDs  
> have their own systems for managing software, and no more than a  
> tiny fraction of their user base will ever use ours (the Gentoo BSD  
> folks come to mind as another good example of that principle in  
> action).  Without users in any quantity, there is very little  
> attention actually paid to the code in question and without  
> attention, it becomes little more than the personal hobby of the few  
> people who actually use that Linux/BSD/Solaris support code and  
> MacPorts becomes an amalgam of common-good code and personal, pet  
> projects.  Not my idea of a good time.

For the record this is what would concern me:
>> Why should you care that some people use powerpc architectures

I have expense high end work stations and servers that are powerpc.  
They should last a long long time.

I would hope that we wouldn't drop powerpc support unless it was  
seriously holding the user base back.

//Brad

From christophe.haro at free.fr  Fri May 22 00:52:44 2009
From: christophe.haro at free.fr (Christophe HARO)
Date: Fri, 22 May 2009 09:52:44 +0200 (CEST)
Subject: [MacPorts] #19717: gnome-keyring @2.26.1 build failure
In-Reply-To: <18586611.7107861242978108422.JavaMail.root@spooler4-g27.priv.proxad.net>
Message-ID: <9316792.7109191242978764714.JavaMail.root@spooler4-g27.priv.proxad.net>

The installed version of my gtk2 port is :

     gtk2 @2.16.1_4X11(active)

Thanks,

-- 
Christophe HARO
Christophe.HARO at free.fr
----------------------------

----- "MacPorts" <noreply at macports.org> a ?crit :

> #19717: gnome-keyring @2.26.1 build failure
> -------------------------------------+--------------------------------------
>  Reporter:  christophe.haro@?        |       Owner: 
> macports-tickets@?                   
>      Type:  defect                   |      Status:  new              
>                    
>  Priority:  Normal                   |   Milestone:                   
>                    
> Component:  ports                    |     Version:  1.7.1            
>                    
>  Keywords:                           |        Port:  gnome-keyring    
>                    
> -------------------------------------+--------------------------------------
> Changes (by blb@?):
> 
>   * port:  gnome-keyring @2.26.1 => gnome-keyring
> 
> 
> Old description:
> 
> > When I try to upgrade gnome-keyring with this command :
> >  sudo port -u upgrade gnome-keyring
> > the reponse is :
> >
> > --->  Fetching gnome-keyring
> > --->  Verifying checksum(s) for gnome-keyring
> > --->  Extracting gnome-keyring
> > --->  Configuring gnome-keyring
> > --->  Building gnome-keyring
> > Error: Target org.macports.build returned: shell command " cd
> >
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports
> > .org_release_ports_gnome_gnome-keyring/work/gnome-keyring-2.26.1" &&
> make
> > all " returned error 2
> > Command output: /bin/sh ../libtool --tag=CC   --mode=link
> > /usr/bin/gcc-4.0
> -DPKCS11_MODULE_PATH=\""/opt/local/lib/gnome-keyring
> > /gnome-keyring-pkcs11.so"\" -DGCR_API_SUBJECT_TO_CHANGE
> > -DUIDIR=\""/opt/local/share/gcr/ui/"\" -Wall     -Wchar-subscripts
> > -Wmissing-declarations -Wmissing-prototypes   -Wnested-externs
> -Wpointer-
> > arith        -Wcast-align -Wsign-compare     -O2
> -Wno-strict-aliasing
> > -Wno-sign-compare -version-info 0:0:0 -no-undefined
> -export-symbols-regex
> > 'gcr_*' -L/opt/local/lib -o libgcr.la -rpath /opt/local/lib
> libgcr_la-
> > gcr-certificate.lo libgcr_la-gcr-certificate-basics-widget.lo
> libgcr_la-
> > gcr-certificate-details-widget.lo libgcr_la-gcr-import-dialog.lo
> > libgcr_la-gcr-importer.lo libgcr_la-gcr-library.lo libgcr_la-gcr-
> > parser.lo libgcr_la-gcr-simple-certificate.lo
> libgcr_la-gcr-marshal.lo
> > ../egg/libegg.la ../egg/libegg-secure-entry.la ../gp11/libgp11.la
> > -L/opt/local/lib -lgobject-2.0 -lglib-2.0 -lintl -liconv
> > -L/opt/local/lib -lglib-2.0 -lintl -liconv   -L/opt/local/lib
> -lgcrypt
> > -lgpg-error -L/opt/local/lib -ltasn1   -L/opt/local/lib
> -lgtk-x11-2.0
> > -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lgio-2.0
> > -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage
> -lpangoft2-1.0
> > -lXext -lXfixes -lcairo -lpixman-1 -lpng12 -lXrender -lX11 -lXau
> -lXdmcp
> > -lpango-1.0 -lm -lfontconfig -lexpat -lfreetype -lz -lgobject-2.0
> > -lgmodule-2.0 -lglib-2.0 -lintl -liconv
> > libtool: link: /usr/bin/nm -p  .libs/libgcr_la-gcr-certificate.o
> .libs
> > /libgcr_la-gcr-certificate-basics-widget.o .libs/libgcr_la-gcr-
> > certificate-details-widget.o .libs/libgcr_la-gcr-import-dialog.o
> .libs
> > /libgcr_la-gcr-importer.o .libs/libgcr_la-gcr-library.o
> .libs/libgcr_la-
> > gcr-parser.o .libs/libgcr_la-gcr-simple-certificate.o
> .libs/libgcr_la-
> > gcr-marshal.o   ../egg/.libs/libegg.a
> ../egg/.libs/libegg-secure-entry.a
> > | sed -n -e 's/^.*[    ]\([BCDEGRST][BCDEGRST]*\)[     ][     
> ]*_\([_A-
> > Za-z][_A-Za-z0-9]*\)$/\1 _\2 \2/p' | /opt/local/bin/gsed 's/.* //' |
> sort
> > | uniq > .libs/libgcr.exp
> > libtool: link: /usr/bin/grep -E -e "gcr_*" ".libs/libgcr.exp" >
> > ".libs/libgcr.expT"
> > libtool: link: mv -f ".libs/libgcr.expT" ".libs/libgcr.exp"
> > libtool: link: (cd .libs/libgcr.lax/libegg.a && ar x
> >
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports
> > .org_release_ports_gnome_gnome-keyring/work/gnome-
> > keyring-2.26.1/gcr/../egg/.libs/libegg.a")
> > libtool: link: (cd .libs/libgcr.lax/libegg-secure-entry.a && ar x
> >
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports
> > .org_release_ports_gnome_gnome-keyring/work/gnome-
> > keyring-2.26.1/gcr/../egg/.libs/libegg-secure-entry.a")
> > libtool: link: sed 's,^,_,' < .libs/libgcr.exp > .libs/libgcr-
> > symbols.expsym
> > libtool: link: /usr/bin/gcc-4.0 -dynamiclib  -o
> .libs/libgcr.0.dylib
> > .libs/libgcr_la-gcr-certificate.o
> .libs/libgcr_la-gcr-certificate-basics-
> > widget.o .libs/libgcr_la-gcr-certificate-details-widget.o .libs
> > /libgcr_la-gcr-import-dialog.o .libs/libgcr_la-gcr-importer.o .libs
> > /libgcr_la-gcr-library.o .libs/libgcr_la-gcr-parser.o
> .libs/libgcr_la-
> > gcr-simple-certificate.o .libs/libgcr_la-gcr-marshal.o
> > .libs/libgcr.lax/libegg.a/libegg_la-egg-asn1.o
> .libs/libgcr.lax/libegg.a
> > /libegg_la-egg-buffer.o
> .libs/libgcr.lax/libegg.a/libegg_la-egg-hex.o
> > .libs/libgcr.lax/libegg.a/libegg_la-egg-libgcrypt.o
> > .libs/libgcr.lax/libegg.a/libegg_la-egg-oid.o
> .libs/libgcr.lax/libegg.a
> > /libegg_la-egg-openssl.o
> .libs/libgcr.lax/libegg.a/libegg_la-egg-secure-
> > memory.o .libs/libgcr.lax/libegg.a/libegg_la-egg-symkey.o
> > .libs/libgcr.lax/libegg.a/libegg_la-egg-unix-credentials.o
> >
> .libs/libgcr.lax/libegg-secure-entry.a/libegg_secure_entry_la-egg-secure-
> > entry.o   -L/opt/local/lib ../gp11/.libs/libgp11.dylib
> > /opt/local/lib/libgthread-2.0.dylib /opt/local/lib/libgcrypt.dylib
> > /opt/local/lib/libgpg-error.dylib /opt/local/lib/libtasn1.dylib
> > /opt/local/lib/libgtk-x11-2.0.dylib
> /opt/local/lib/libgdk-x11-2.0.dylib
> > /opt/local/lib/libatk-1.0.dylib
> /opt/local/lib/libgdk_pixbuf-2.0.dylib
> > /opt/local/lib/libpangocairo-1.0.dylib
> /opt/local/lib/libgio-2.0.dylib
> > /opt/local/lib/libXinerama.dylib /opt/local/lib/libXi.dylib
> > /opt/local/lib/libXrandr.dylib /opt/local/lib/libXcursor.dylib
> > /opt/local/lib/libXcomposite.dylib /opt/local/lib/libXdamage.dylib
> > /opt/local/lib/libpangoft2-1.0.dylib /opt/local/lib/libXext.dylib
> > /opt/local/lib/libXfixes.dylib /opt/local/lib/libcairo.dylib
> > /opt/local/lib/libpixman-1.dylib /opt/local/lib/libpng12.dylib
> > /opt/local/lib/libXrender.dylib /opt/local/lib/libX11.dylib
> > /opt/local/lib/libXau.dylib /opt/local/lib/libXdmcp.dylib
> > /opt/local/lib/libpango-1.0.dylib -lm
> /opt/local/lib/libfontconfig.dylib
> > /opt/local/lib/libexpat.dylib /opt/local/lib/libfreetype.dylib -lz
> > /opt/local/lib/libgobject-2.0.dylib
> /opt/local/lib/libgmodule-2.0.dylib
> > /opt/local/lib/libglib-2.0.dylib /opt/local/lib/libintl.dylib -lc
> > /opt/local/lib/libiconv.dylib    -framework Carbon -install_name
> > /opt/local/lib/libgcr.0.dylib -compatibility_version 1
> -current_version
> > 1.0 -Wl,-single_module -Wl,-exported_symbols_list,.libs/libgcr-
> > symbols.expsym
> > libtool: link: dsymutil .libs/libgcr.0.dylib || :
> > warning: no debug symbols in executable (-arch i386)
> > libtool: link: (cd ".libs" && rm -f "libgcr.dylib" && ln -s
> > "libgcr.0.dylib" "libgcr.dylib")
> > libtool: link: rm -fr .libs/libgcr.lax
> > libtool: link: ( cd ".libs" && rm -f "libgcr.la" && ln -s
> "../libgcr.la"
> > "libgcr.la" )
> > cp gcr.pc gcr-0.pc
> > gtk-builder-convert --skip-windows
> gcr-certificate-basics-widget.glade
> > gcr-certificate-basics-widget.ui
> > Traceback (most recent call last):
> >   File "/opt/local/bin/gtk-builder-convert", line 756, in <module>
> >     sys.exit(main(sys.argv))
> >   File "/opt/local/bin/gtk-builder-convert", line 744, in main
> >     conv.parse_file(input_filename)
> >   File "/opt/local/bin/gtk-builder-convert", line 161, in
> parse_file
> >     self._parse()
> >   File "/opt/local/bin/gtk-builder-convert", line 279, in _parse
> >     root_objects.sort(lambda a, b: cmp(b.getAttribute('id'),
> > TypeError: must use keyword argument for key function
> > make[4]: *** [gcr-certificate-basics-widget.ui] Error 1
> > make[3]: *** [all-recursive] Error 1
> > make[2]: *** [all] Error 2
> > make[1]: *** [all-recursive] Error 1
> > make: *** [all] Error 2
> >
> > Error: Unable to upgrade port: 1
> >
> > I do not figure out what is the problem. Can someone help me ?
> >
> > Here you can find my configuration :
> >
> > Mac OS X 10.5.7
> > callisto:~ haro$ uname -a
> > Darwin callisto.local 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31
> > 22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386 i386
> >
> > Thanks
> >
> > Christophe HARO
> 
> New description:
> 
>  When I try to upgrade gnome-keyring with this command :
>   sudo port -u upgrade gnome-keyring
>  the reponse is :
>  {{{
>  --->  Fetching gnome-keyring
>  --->  Verifying checksum(s) for gnome-keyring
>  --->  Extracting gnome-keyring
>  --->  Configuring gnome-keyring
>  --->  Building gnome-keyring
>  Error: Target org.macports.build returned: shell command " cd
> 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports
>  .org_release_ports_gnome_gnome-keyring/work/gnome-keyring-2.26.1" &&
> make
>  all " returned error 2
>  Command output: /bin/sh ../libtool --tag=CC   --mode=link
> /usr/bin/gcc-4.0
>  -DPKCS11_MODULE_PATH=\""/opt/local/lib/gnome-keyring/gnome-keyring-
>  pkcs11.so"\" -DGCR_API_SUBJECT_TO_CHANGE
>  -DUIDIR=\""/opt/local/share/gcr/ui/"\" -Wall     -Wchar-subscripts
>  -Wmissing-declarations -Wmissing-prototypes   -Wnested-externs
> -Wpointer-
>  arith        -Wcast-align -Wsign-compare     -O2
> -Wno-strict-aliasing
>  -Wno-sign-compare -version-info 0:0:0 -no-undefined
> -export-symbols-regex
>  'gcr_*' -L/opt/local/lib -o libgcr.la -rpath /opt/local/lib
> libgcr_la-gcr-
>  certificate.lo libgcr_la-gcr-certificate-basics-widget.lo
> libgcr_la-gcr-
>  certificate-details-widget.lo libgcr_la-gcr-import-dialog.lo
> libgcr_la-
>  gcr-importer.lo libgcr_la-gcr-library.lo libgcr_la-gcr-parser.lo
>  libgcr_la-gcr-simple-certificate.lo libgcr_la-gcr-marshal.lo
>  ../egg/libegg.la ../egg/libegg-secure-entry.la ../gp11/libgp11.la
>  -L/opt/local/lib -lgobject-2.0 -lglib-2.0 -lintl -liconv
>  -L/opt/local/lib -lglib-2.0 -lintl -liconv   -L/opt/local/lib
> -lgcrypt
>  -lgpg-error -L/opt/local/lib -ltasn1   -L/opt/local/lib
> -lgtk-x11-2.0
>  -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lgio-2.0
>  -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage
> -lpangoft2-1.0
>  -lXext -lXfixes -lcairo -lpixman-1 -lpng12 -lXrender -lX11 -lXau
> -lXdmcp
>  -lpango-1.0 -lm -lfontconfig -lexpat -lfreetype -lz -lgobject-2.0
>  -lgmodule-2.0 -lglib-2.0 -lintl -liconv
>  libtool: link: /usr/bin/nm -p  .libs/libgcr_la-gcr-certificate.o
> .libs
>  /libgcr_la-gcr-certificate-basics-widget.o .libs/libgcr_la-gcr-
>  certificate-details-widget.o .libs/libgcr_la-gcr-import-dialog.o
> .libs
>  /libgcr_la-gcr-importer.o .libs/libgcr_la-gcr-library.o
> .libs/libgcr_la-
>  gcr-parser.o .libs/libgcr_la-gcr-simple-certificate.o
> .libs/libgcr_la-gcr-
>  marshal.o   ../egg/.libs/libegg.a ../egg/.libs/libegg-secure-entry.a
> | sed
>  -n -e 's/^.*[    ]\([BCDEGRST][BCDEGRST]*\)[     ][     
> ]*_\([_A-Za-z
>  ][_A-Za-z0-9]*\)$/\1 _\2 \2/p' | /opt/local/bin/gsed 's/.* //' | sort
> |
>  uniq > .libs/libgcr.exp
>  libtool: link: /usr/bin/grep -E -e "gcr_*" ".libs/libgcr.exp" >
>  ".libs/libgcr.expT"
>  libtool: link: mv -f ".libs/libgcr.expT" ".libs/libgcr.exp"
>  libtool: link: (cd .libs/libgcr.lax/libegg.a && ar x
> 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports
>  .org_release_ports_gnome_gnome-keyring/work/gnome-
>  keyring-2.26.1/gcr/../egg/.libs/libegg.a")
>  libtool: link: (cd .libs/libgcr.lax/libegg-secure-entry.a && ar x
> 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports
>  .org_release_ports_gnome_gnome-keyring/work/gnome-
>  keyring-2.26.1/gcr/../egg/.libs/libegg-secure-entry.a")
>  libtool: link: sed 's,^,_,' < .libs/libgcr.exp > .libs/libgcr-
>  symbols.expsym
>  libtool: link: /usr/bin/gcc-4.0 -dynamiclib  -o .libs/libgcr.0.dylib
>  .libs/libgcr_la-gcr-certificate.o
> .libs/libgcr_la-gcr-certificate-basics-
>  widget.o .libs/libgcr_la-gcr-certificate-details-widget.o
> .libs/libgcr_la-
>  gcr-import-dialog.o .libs/libgcr_la-gcr-importer.o
> .libs/libgcr_la-gcr-
>  library.o .libs/libgcr_la-gcr-parser.o .libs/libgcr_la-gcr-simple-
>  certificate.o .libs/libgcr_la-gcr-marshal.o  
> .libs/libgcr.lax/libegg.a
>  /libegg_la-egg-asn1.o
> .libs/libgcr.lax/libegg.a/libegg_la-egg-buffer.o
>  .libs/libgcr.lax/libegg.a/libegg_la-egg-hex.o
> .libs/libgcr.lax/libegg.a
>  /libegg_la-egg-libgcrypt.o
> .libs/libgcr.lax/libegg.a/libegg_la-egg-oid.o
>  .libs/libgcr.lax/libegg.a/libegg_la-egg-openssl.o
>  .libs/libgcr.lax/libegg.a/libegg_la-egg-secure-memory.o
>  .libs/libgcr.lax/libegg.a/libegg_la-egg-symkey.o
> .libs/libgcr.lax/libegg.a
>  /libegg_la-egg-unix-credentials.o 
> .libs/libgcr.lax/libegg-secure-entry.a
>  /libegg_secure_entry_la-egg-secure-entry.o   -L/opt/local/lib
>  ../gp11/.libs/libgp11.dylib /opt/local/lib/libgthread-2.0.dylib
>  /opt/local/lib/libgcrypt.dylib /opt/local/lib/libgpg-error.dylib
>  /opt/local/lib/libtasn1.dylib /opt/local/lib/libgtk-x11-2.0.dylib
>  /opt/local/lib/libgdk-x11-2.0.dylib /opt/local/lib/libatk-1.0.dylib
>  /opt/local/lib/libgdk_pixbuf-2.0.dylib
>  /opt/local/lib/libpangocairo-1.0.dylib
> /opt/local/lib/libgio-2.0.dylib
>  /opt/local/lib/libXinerama.dylib /opt/local/lib/libXi.dylib
>  /opt/local/lib/libXrandr.dylib /opt/local/lib/libXcursor.dylib
>  /opt/local/lib/libXcomposite.dylib /opt/local/lib/libXdamage.dylib
>  /opt/local/lib/libpangoft2-1.0.dylib /opt/local/lib/libXext.dylib
>  /opt/local/lib/libXfixes.dylib /opt/local/lib/libcairo.dylib
>  /opt/local/lib/libpixman-1.dylib /opt/local/lib/libpng12.dylib
>  /opt/local/lib/libXrender.dylib /opt/local/lib/libX11.dylib
>  /opt/local/lib/libXau.dylib /opt/local/lib/libXdmcp.dylib
>  /opt/local/lib/libpango-1.0.dylib -lm
> /opt/local/lib/libfontconfig.dylib
>  /opt/local/lib/libexpat.dylib /opt/local/lib/libfreetype.dylib -lz
>  /opt/local/lib/libgobject-2.0.dylib
> /opt/local/lib/libgmodule-2.0.dylib
>  /opt/local/lib/libglib-2.0.dylib /opt/local/lib/libintl.dylib -lc
>  /opt/local/lib/libiconv.dylib    -framework Carbon -install_name
>  /opt/local/lib/libgcr.0.dylib -compatibility_version 1
> -current_version
>  1.0 -Wl,-single_module -Wl,-exported_symbols_list,.libs/libgcr-
>  symbols.expsym
>  libtool: link: dsymutil .libs/libgcr.0.dylib || :
>  warning: no debug symbols in executable (-arch i386)
>  libtool: link: (cd ".libs" && rm -f "libgcr.dylib" && ln -s
>  "libgcr.0.dylib" "libgcr.dylib")
>  libtool: link: rm -fr .libs/libgcr.lax
>  libtool: link: ( cd ".libs" && rm -f "libgcr.la" && ln -s
> "../libgcr.la"
>  "libgcr.la" )
>  cp gcr.pc gcr-0.pc
>  gtk-builder-convert --skip-windows
> gcr-certificate-basics-widget.glade
>  gcr-certificate-basics-widget.ui
>  Traceback (most recent call last):
>    File "/opt/local/bin/gtk-builder-convert", line 756, in <module>
>      sys.exit(main(sys.argv))
>    File "/opt/local/bin/gtk-builder-convert", line 744, in main
>      conv.parse_file(input_filename)
>    File "/opt/local/bin/gtk-builder-convert", line 161, in parse_file
>      self._parse()
>    File "/opt/local/bin/gtk-builder-convert", line 279, in _parse
>      root_objects.sort(lambda a, b: cmp(b.getAttribute('id'),
>  TypeError: must use keyword argument for key function
>  make[4]: *** [gcr-certificate-basics-widget.ui] Error 1
>  make[3]: *** [all-recursive] Error 1
>  make[2]: *** [all] Error 2
>  make[1]: *** [all-recursive] Error 1
>  make: *** [all] Error 2
> 
>  Error: Unable to upgrade port: 1
>  }}}
>  I do not figure out what is the problem. Can someone help me ?
> 
>  Here you can find my configuration :
>  {{{
>  Mac OS X 10.5.7
>  callisto:~ haro$ uname -a
>  Darwin callisto.local 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31
>  22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386 i386
>  }}}
>  Thanks
> 
>  Christophe HARO
> 
> --
> 
> Comment:
> 
>  What is the installed version of your gtk2 port?  {{{port installed
>  gtk2}}}
> 
> -- 
> Ticket URL: <http://trac.macports.org/ticket/19717#comment:1>
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS

From jmr at macports.org  Fri May 22 03:24:00 2009
From: jmr at macports.org (Joshua Root)
Date: Fri, 22 May 2009 20:24:00 +1000
Subject: Panther tickets
In-Reply-To: <BB312E63-FB3D-4595-B352-3760E33C73E6@pixilla.com>
References: <056.8c0a9be3e8d65bb3091c817ea800dfdc@macports.org>	<065.c129f4215823d49ec7e0c6f172f3928a@macports.org>	<D1115F4B-A4AD-475C-BDC8-35D087C47FB3@macports.org>	<20090521023937.GM22252@ninagal.withay.com>	<4A1514D3.1060204@macports.org>	<20090521094319.GA2798@velsheda.lateralis.org>	<20090521143939.GA2884@mactelhm.local>	<7932E549-81C4-4A0E-8DA6-35BAB971874F@apple.com>
	<BB312E63-FB3D-4595-B352-3760E33C73E6@pixilla.com>
Message-ID: <4A167D40.7020201@macports.org>

On 2009-5-22 12:18, Bradley Giesbrecht wrote:
> 
> For the record this is what would concern me:
>>> Why should you care that some people use powerpc architectures
> 
> I have expense high end work stations and servers that are powerpc. They
> should last a long long time.
> 
> I would hope that we wouldn't drop powerpc support unless it was
> seriously holding the user base back.

Nobody has said anything about dropping ppc support besides Emmanuel. Do
I really need to point out that his opinions are his own and do not
represent project policy?

- Josh

From dweber at macports.org  Fri May 22 12:07:41 2009
From: dweber at macports.org (Darren Weber)
Date: Fri, 22 May 2009 12:07:41 -0700
Subject: python install anomalies - tcl code to set paths
Message-ID: <b808b3510905221207l3b231b9wc883a5fbed97dbc7@mail.gmail.com>

The python 2.x installs contain can variations in paths for the include and
lib installations (python2.6 deviates from the prior patterns set by 2.4 and
2.5).

The following tcl code should work for python 2.4, 2.5, and 2.6 (as of May
2009).  The nice thing about this tcl code is that a port can use it to set
a python dependency for configuration that will be specific to a python
version.  This proc can be called from within variants to set or reset a
python dependency easily (e.g., say you want more than one python variant to
depend on a specific python install).

proc setPython { pyVer } {
    global pyVer python pyPort pyFrame pyLib pyBin pySite pyInc
    #set pyVer       2.5
    set python      python${pyVer}
    set pyPort      [join [split $python .] ""]
    set pyFrame
${prefix}/Library/Frameworks/Python.framework/Versions/${pyVer}
    set pyLib       ${pyFrame}/Python
    set pyBin       ${prefix}/bin/${python}
    set pySite      ${prefix}/lib/${python}/site-packages
    set pyInc       ${prefix}/include/${python}
    if [string match "2.6" ${pyVer}] {
        # python2.6 is a true framework installation; whereas installs for
2.4
        # and 2.5 contain symlinks in the framework path to the prefix path;
and
        # those symlinks can break the file_map stage of port activation.
        set pyBin       ${pyFrame}/bin/${python}
        set pySite      ${pyFrame}/lib/${python}/site-packages
        set pyInc       ${pyFrame}/include/${python}
    }
}
# Init the python variables
setPython 2.5


Regards, Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090522/83bb6bbe/attachment.html>

From dweber at macports.org  Fri May 22 13:17:29 2009
From: dweber at macports.org (Darren Weber)
Date: Fri, 22 May 2009 13:17:29 -0700
Subject: python install anomalies - tcl code to set paths
In-Reply-To: <b808b3510905221207l3b231b9wc883a5fbed97dbc7@mail.gmail.com>
References: <b808b3510905221207l3b231b9wc883a5fbed97dbc7@mail.gmail.com>
Message-ID: <b808b3510905221317r4ea8c84gca67decf97ec2841@mail.gmail.com>

On Fri, May 22, 2009 at 12:07 PM, Darren Weber <dweber at macports.org> wrote:

>
> The python 2.x installs contain can variations in paths for the include and
> lib installations (python2.6 deviates from the prior patterns set by 2.4 and
> 2.5).
>
> The following tcl code should work for python 2.4, 2.5, and 2.6 (as of May
> 2009).  The nice thing about this tcl code is that a port can use it to set
> a python dependency for configuration that will be specific to a python
> version.  This proc can be called from within variants to set or reset a
> python dependency easily (e.g., say you want more than one python variant to
> depend on a specific python install).
>
> proc setPython { pyVer } {
>     global pyVer python pyPort pyFrame pyLib pyBin pySite pyInc
>     #set pyVer       2.5
>     set python      python${pyVer}
>     set pyPort      [join [split $python .] ""]
>     set pyFrame
> ${prefix}/Library/Frameworks/Python.framework/Versions/${pyVer}
>     set pyLib       ${pyFrame}/Python
>     set pyBin       ${prefix}/bin/${python}
>     set pySite      ${prefix}/lib/${python}/site-packages
>     set pyInc       ${prefix}/include/${python}
>     if [string match "2.6" ${pyVer}] {
>         # python2.6 is a true framework installation; whereas installs for
> 2.4
>         # and 2.5 contain symlinks in the framework path to the prefix
> path; and
>         # those symlinks can break the file_map stage of port activation.
>         set pyBin       ${pyFrame}/bin/${python}
>         set pySite      ${pyFrame}/lib/${python}/site-packages
>         set pyInc       ${pyFrame}/include/${python}
>     }
> }
> # Init the python variables
> setPython 2.5
>
>
> Regards, Darren
>
>


Some revisions on the tcl code above are required because it seems that
${prefix} is not defined when the proc is defined in a global scope for a
Portfile (not clear why that is the case).


proc setPython { {major 2} {minor 6} } {
    global pyVer python pyPort pyBin pyLib pyInc pyFrame pySite
    set pyVer       ${major}.${minor}
    set python      python${pyVer}
    set pyPort      python${major}${minor}
    set pyFrame     Library/Frameworks/Python.framework/Versions/${pyVer}
    set pyLib       ${pyFrame}/Python
    set pyBin       bin/${python}
    set pyInc       include/${python}
    set pySite      lib/${python}/site-packages
    if [string match "2.6" ${pyVer}] {
        # python2.6 is a true framework installation; whereas installs for
2.4
        # and 2.5 contain symlinks in the framework path to the prefix path;
and
        # those symlinks can break the file_map stage of port activation.
        set pyBin   ${pyFrame}/bin/${python}
        set pyInc   ${pyFrame}/include/${python}
        set pySite  ${pyFrame}/lib/${python}/site-packages
    }
}
setPython

# Here's some dummy variants that provide a "switch" between python25 or
python26

variant py26 conflicts py25 {
    setPython 2 6
    depends_lib-append \
        port:${pyPort}
    # Note how the ${prefix} must be included here:
    configure.args-append \
        -DPYTHON_EXECUTABLE:FILEPATH=${prefix}/${pyBin} \
        -DPYTHON_INCLUDE_PATH:FILEPATH=${prefix}/${pyInc} \
        -DPYTHON_LIBRARY:FILEPATH=${prefix}/${pyLib}
}

variant py25 conflicts py26 {
    setPython 2 5
    depends_lib-append \
        port:${pyPort}
    configure.args-append \
        -DPYTHON_EXECUTABLE:FILEPATH=${prefix}/${pyBin} \
        -DPYTHON_INCLUDE_PATH:FILEPATH=${prefix}/${pyInc} \
        -DPYTHON_LIBRARY:FILEPATH=${prefix}/${pyLib}
}


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

From raimue at macports.org  Fri May 22 15:58:31 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Sat, 23 May 2009 00:58:31 +0200
Subject: python install anomalies - tcl code to set paths
In-Reply-To: <b808b3510905221207l3b231b9wc883a5fbed97dbc7@mail.gmail.com>
References: <b808b3510905221207l3b231b9wc883a5fbed97dbc7@mail.gmail.com>
Message-ID: <4A172E17.40809@macports.org>

On 2009-05-22 21:07, Darren Weber wrote:
> The following tcl code should work for python 2.4, 2.5, and 2.6 (as of
> May 2009).  The nice thing about this tcl code is that a port can use it
> to set a python dependency for configuration that will be specific to a
> python version.  This proc can be called from within variants to set or
> reset a python dependency easily (e.g., say you want more than one
> python variant to depend on a specific python install).

The pythonXX port groups already define some variables. Would it make
sense to have your proposed code in another port group? At least we
should stick to the same variable names.

Rainer

From billitch at gmail.com  Fri May 22 16:28:27 2009
From: billitch at gmail.com (Thomas de Grivel)
Date: Sat, 23 May 2009 01:28:27 +0200
Subject: Commit rights
Message-ID: <4ec7f0880905221628n55406f4fvc31d2e1a3bad974f@mail.gmail.com>

Dear MacPorts maintainers,

I have been using, following and contributing to MacPorts for several years
now. I also maintain a few packages (gnome-planner, php-mode.el, d-mode.el,
speex, list is non-exhaustive =). Also I recently learned Lisp and will be
glad to help MacPorts and Lisp to get along.

Tonight (I live in France) I was browsing through the bug reports and some
were tempting me and I think I could help with those (#17774, #11119,
#11634, for starters). They are high priority and some are aged of more than
a year ..! If you were to allow me I could accept these tickets and maybe
close them in less than a year..  ; )

Cheers,

-- 
Thomas de Grivel
http://b.lowh.net/billitch/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090523/72d6ffc1/attachment.html>

From dweber at macports.org  Fri May 22 16:59:28 2009
From: dweber at macports.org (Darren Weber)
Date: Fri, 22 May 2009 16:59:28 -0700
Subject: python install anomalies - tcl code to set paths
In-Reply-To: <4A172E17.40809@macports.org>
References: <b808b3510905221207l3b231b9wc883a5fbed97dbc7@mail.gmail.com>
	<4A172E17.40809@macports.org>
Message-ID: <b808b3510905221659h63d3ca28mdda6e55139a8b5e2@mail.gmail.com>

On Fri, May 22, 2009 at 3:58 PM, Rainer M?ller <raimue at macports.org> wrote:

> On 2009-05-22 21:07, Darren Weber wrote:
> > The following tcl code should work for python 2.4, 2.5, and 2.6 (as of
> > May 2009).  The nice thing about this tcl code is that a port can use it
> > to set a python dependency for configuration that will be specific to a
> > python version.  This proc can be called from within variants to set or
> > reset a python dependency easily (e.g., say you want more than one
> > python variant to depend on a specific python install).
>
> The pythonXX port groups already define some variables. Would it make
> sense to have your proposed code in another port group? At least we
> should stick to the same variable names.
>
> Rainer
>


It's good to raise this point.  It's occurred to me that the python port
group might define a lot of this already.  I've not done any research on
this to consider whether to integrate this tcl proc into the python port
group or to adopt the variable names of the port group in this tcl proc.

The motivation for this was to provide a small procedural abstraction,
within a Portfile, to make it easier to define multiple pyXY variants.  It's
been useful in vtk-devel and InsightToolkit (revision 1 to be committed
soon), where it should be possible to build with one of several possible
python installations.  The proc abstraction in the Portfile avoids any
concern about using the python port group.  Given that vtk-devel and
InsightToolkit are not specifically python ports, I didn't want to
complicate them with the addition of the python port group (which was partly
a lazy decision based on ignorance).

Anyhow, this post to the dev list might help others with similar problems.
Perhaps someone familiar with the purpose and intent of the python port
group can take a look at this tcl proc to see if it might add anything
useful to the port group.

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

From ryandesign at macports.org  Fri May 22 23:01:53 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 23 May 2009 01:01:53 -0500
Subject: [51325] trunk/dports/lang/ghc/Portfile
In-Reply-To: <20090523014603.E402A1C0A014@beta.macosforge.org>
References: <20090523014603.E402A1C0A014@beta.macosforge.org>
Message-ID: <3969906C-0B86-4564-A51A-D0204B721158@macports.org>


On May 22, 2009, at 20:46, gwright at macports.org wrote:

> Revision: 51325
>           http://trac.macports.org/changeset/51325
> Author:   gwright at macports.org
> Date:     2009-05-22 18:46:03 -0700 (Fri, 22 May 2009)
> Log Message:
> -----------
> Fix Xcode version testing on Tiger (10.4).

Thanks. I would have filed a ticket but I was just running out the  
door so I just sent an email.

> @@ -5,6 +5,7 @@
>  name		ghc
>  set canonicalname	ghc
>  version		6.10.3
> +revision	1
>  categories	lang haskell
>  maintainers	gwright
>  platforms	darwin

FYI, you should not increase the revision for changes of this kind.  
Either the user was unable to build the port at all (like me, since I  
was on Tiger and thus did not (and could not) have Xcode 3), or the  
user was able to build the port, in which case forcing them to  
rebuild now serves no purpose. If the files the port installs, or the  
port's dependencies, haven't changed, then there's usually no reason  
to increase the revision. Don't decrease it again now, but do keep it  
in mind for the future to keep your users from having to rebuild  
unnecessarily.



From emer at emer.net  Fri May 22 23:21:07 2009
From: emer at emer.net (Mark Anderson)
Date: Sat, 23 May 2009 02:21:07 -0400
Subject: [MacPorts] #19681: tesseract fails to stage
In-Reply-To: <059.6c8a05237c67966f660f81ca57b15ac5@macports.org>
References: <050.0fcddb37e6376ef10d01c092f8b7ad0c@macports.org> 
	<059.6c8a05237c67966f660f81ca57b15ac5@macports.org>
Message-ID: <2cf4100f0905222321w359188fblf0506e946568d7ff@mail.gmail.com>

Can I get some more information on this? (OS, system, etc)

It builds fine on my machine. Not a whole lot goes on in the java directory.

Mark

On Fri, May 22, 2009 at 5:22 AM, MacPorts <noreply at macports.org> wrote:

> #19681: tesseract fails to stage
>
> ----------------------------+-----------------------------------------------
>  Reporter:  hans@?          |       Owner:  emer@?
>     Type:  defect          |      Status:  new
>  Priority:  Normal          |   Milestone:
> Component:  ports           |     Version:
>  Keywords:                  |        Port:  tesseract
>
> ----------------------------+-----------------------------------------------
> Changes (by toby@?):
>
>  * version:  1.7.1 =>
>
>
> Old description:
>
> > Making install in java
> > make[1]: *** No rule to make target `install'.  Stop.
> > make: *** [install-recursive] Error 1
> >
> > Error: Status 1 encountered during processing.
>
> New description:
>
>  {{{
>  Making install in java
>  make[1]: *** No rule to make target `install'.  Stop.
>  make: *** [install-recursive] Error 1
>
>  Error: Status 1 encountered during processing.
>  }}}
>
> --
>
> --
> Ticket URL: <http://trac.macports.org/ticket/19681#comment:2>
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090523/0b1bbaa8/attachment.html>

From ryandesign at macports.org  Sat May 23 00:00:27 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 23 May 2009 02:00:27 -0500
Subject: [51342] trunk/dports/security/suhosin/Portfile
In-Reply-To: <20090523064740.91F111C0CBBE@beta.macosforge.org>
References: <20090523064740.91F111C0CBBE@beta.macosforge.org>
Message-ID: <6A7F6C2D-7ADC-4BE6-80D0-A68F7DE5B40C@macports.org>


On May 23, 2009, at 01:47, snc at macports.org wrote:

> Revision: 51342
>           http://trac.macports.org/changeset/51342
> Author:   snc at macports.org
> Date:     2009-05-22 23:47:39 -0700 (Fri, 22 May 2009)
> Log Message:
> -----------
> updated version

Unless there's a special reason you downgraded the version, you  
should revert this change. 0.9.27 is from August 2008 while 0.9.5 is  
from September 2006.


> Modified Paths:
> --------------
>     trunk/dports/security/suhosin/Portfile
>
> Modified: trunk/dports/security/suhosin/Portfile
> ===================================================================
> --- trunk/dports/security/suhosin/Portfile	2009-05-23 06:29:13 UTC  
> (rev 51341)
> +++ trunk/dports/security/suhosin/Portfile	2009-05-23 06:47:39 UTC  
> (rev 51342)
> @@ -4,7 +4,7 @@
>  PortSystem		    1.0
>
>  name                suhosin
> -version             0.9.27
> +version             0.9.5
>  categories          security www
>  maintainers         snc openmaintainer
>  description         Advanced protection extension for PHP
> @@ -22,9 +22,9 @@
>  master_sites        http://download.suhosin.org/
>  extract.suffix      .tgz
>
> -checksums           md5 9aae02bc2d2bcf9b8bd97cd22f56a8b8\
> -                    sha1 3033bd3840c75786179cf8240f63d97b5f6accbf\
> -                    rmd160 46bf47daf0dab05359da62fde8a76ba7c43b3dbc
> +checksums           md5    f35fc0b5ce3c3d890a016131d2240737 \
> +                    sha1   8ddf4effbc1bdd5dfc65246911608cd60d9759a0 \
> +                    rmd160 326ce6366697c6965603f3db4a3988f1bd9193f9
>
>  pre-configure {
>      system "cd ${worksrcpath} && phpize"
> @@ -35,6 +35,3 @@
>  test.run            yes
>
>  destroot.destdir    INSTALL_ROOT=${destroot}
> -post-destroot {
> -    xinstall -m 644 ${worksrcpath}/suhosin.ini ${destroot}$ 
> {prefix}/etc/suhosin.ini
> -}
> _______________________________________________
> macports-changes mailing list
> macports-changes at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes


From ryandesign at macports.org  Sat May 23 00:04:41 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 23 May 2009 02:04:41 -0500
Subject: python install anomalies - tcl code to set paths
In-Reply-To: <b808b3510905221317r4ea8c84gca67decf97ec2841@mail.gmail.com>
References: <b808b3510905221207l3b231b9wc883a5fbed97dbc7@mail.gmail.com>
	<b808b3510905221317r4ea8c84gca67decf97ec2841@mail.gmail.com>
Message-ID: <6A0F9F7D-8100-4E29-B3C5-9700BDDCA5B6@macports.org>


On May 22, 2009, at 15:17, Darren Weber wrote:

> Some revisions on the tcl code above are required because it seems  
> that ${prefix} is not defined when the proc is defined in a global  
> scope for a Portfile (not clear why that is the case).

Try adding "global prefix" at the top of the proc.



From ryandesign at macports.org  Sat May 23 00:08:36 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 23 May 2009 02:08:36 -0500
Subject: [50797] trunk/dports/gnome/gnome-platform-suite/Portfile
In-Reply-To: <4A158F6F.40503@macports.org>
References: <20090509204053.E4AA7180A9D5@beta.macosforge.org>
	<4A158F6F.40503@macports.org>
Message-ID: <49C93220-8C16-4003-987A-666C2A16B3A8@macports.org>

On May 21, 2009, at 12:29, David Evans wrote:

> ryandesign at macports.org wrote:
>
>> --- trunk/dports/gnome/gnome-platform-suite/Portfile	2009-05-09  
>> 20:16:23 UTC (rev 50796)
>> +++ trunk/dports/gnome/gnome-platform-suite/Portfile	2009-05-09  
>> 20:40:52 UTC (rev 50797)
>> @@ -18,6 +18,7 @@
>>  homepage        http://www.gnome.org/
>>  master_sites    gnome
>>  +depends_build   path:bin/pkg-config:pkgconfig
>>  depends_lib     port:at-spi     \
>>                  port:atk    \
>>                  port:esound     \
>> @@ -39,8 +40,7 @@
>>                  port:libxml2    \
>>                  port:libxslt    \
>>                  port:orbit2     \
>> -                port:pango      \
>> -                port:pkgconfig  \
>> +                path:lib/pkgconfig/pango.pc:pango \
>>                  port:policykit-gnome
>>   distfiles
>
> Ryan --
>
> I agree with your pango change here but with respect to pkgconfig  
> there was some method to my madness.   This is a meta package
> that attempts to install a set of ports that the GNOME project  
> refers to as the GNOME platform modules -- the basic set of packages
> needed to develop GNOME applications and they list pkgconfig as one  
> of these.  Thus, it seemed appropriate to me to make it a library
> dependency in this case (one that shouldn't be removed after  
> installation of this port) even though it strictly doesn't provide any
> libraries used at run-time and normally would be a build dependency  
> anywhere else.
>
> Does this make any sense?

Ok, my apologies, feel free to change it back. There was another port  
recently where that was given as the reason too.

> Also I'm not sure why you made it a path dependency.  Should this  
> be done globally?

I am getting tired of having to monitor ports' dependencies for  
things like "port:pango" and "port:cairo" and "port:glib2" and  
"port:graphviz" and any other port:-style dependency on something for  
which a -devel version exists, and then change it to a path  
dependency. :) I'm trying to get in the habit of using a path:-style  
dependency always, even if a -devel version does not currently exist,  
because maybe tomorrow someone will want to create a -devel version.  
We may want to make path:-style dependencies the recommended way to  
specify dependencies.



From jeremy at lavergne.gotdns.org  Sat May 23 00:48:38 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Sat, 23 May 2009 03:48:38 -0400
Subject: [51342] trunk/dports/security/suhosin/Portfile
In-Reply-To: <6A7F6C2D-7ADC-4BE6-80D0-A68F7DE5B40C@macports.org>
References: <20090523064740.91F111C0CBBE@beta.macosforge.org>
	<6A7F6C2D-7ADC-4BE6-80D0-A68F7DE5B40C@macports.org>
Message-ID: <920CBFFF-7044-452A-AC34-4094C0040E33@lavergne.gotdns.org>

Nope, the only reason was I trusted livecheck.

My apologies.

On May 23, 2009, at 3:00 AM, Ryan Schmidt wrote:

> Unless there's a special reason you downgraded the version, you  
> should revert this change. 0.9.27 is from August 2008 while 0.9.5 is  
> from September 2006.

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

From ryandesign at macports.org  Sat May 23 01:00:08 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 23 May 2009 03:00:08 -0500
Subject: [51342] trunk/dports/security/suhosin/Portfile
In-Reply-To: <920CBFFF-7044-452A-AC34-4094C0040E33@lavergne.gotdns.org>
References: <20090523064740.91F111C0CBBE@beta.macosforge.org>
	<6A7F6C2D-7ADC-4BE6-80D0-A68F7DE5B40C@macports.org>
	<920CBFFF-7044-452A-AC34-4094C0040E33@lavergne.gotdns.org>
Message-ID: <1467E304-2CC2-461A-91DA-7705383B2FE7@macports.org>


On May 23, 2009, at 02:48, Jeremy Lavergne wrote:

> On May 23, 2009, at 3:00 AM, Ryan Schmidt wrote:
>
>> Unless there's a special reason you downgraded the version, you  
>> should revert this change. 0.9.27 is from August 2008 while 0.9.5  
>> is from September 2006.
>
> Nope, the only reason was I trusted livecheck.

Ah yes, its freshmeat entry seems to be very stale. I changed the  
livecheck in r51346 to something that should work better.


From jkh at apple.com  Sat May 23 02:11:43 2009
From: jkh at apple.com (Jordan K. Hubbard)
Date: Sat, 23 May 2009 02:11:43 -0700
Subject: How are new volunteers "processed" these days?
Message-ID: <6CFDC712-BB50-4289-80DB-2445EE6E29C8@apple.com>

Hi guys (core?),

After seeing 2 people volunteer their services as MacPorts committers  
recently, it occurred to me to wonder just how these sorts of ad-hoc,  
informal "how can I help?" messages are being acted on.  If someone  
from project management has already quietly followed up to those folks  
off-list, with encouraging words and the usual array of necessary  
questions, then I apologize in advance for even implying that the team  
is anything but totally on top of this important function!

Thanks,

- Jordan


From jmr at macports.org  Sat May 23 02:13:58 2009
From: jmr at macports.org (Joshua Root)
Date: Sat, 23 May 2009 19:13:58 +1000
Subject: [51342] trunk/dports/security/suhosin/Portfile
In-Reply-To: <920CBFFF-7044-452A-AC34-4094C0040E33@lavergne.gotdns.org>
References: <20090523064740.91F111C0CBBE@beta.macosforge.org>	<6A7F6C2D-7ADC-4BE6-80D0-A68F7DE5B40C@macports.org>
	<920CBFFF-7044-452A-AC34-4094C0040E33@lavergne.gotdns.org>
Message-ID: <4A17BE56.6040700@macports.org>

Livecheck intentionally only tells you that the versions *differ*. This
information is useful whether the portfile version is older or newer
than the one from the web: in the former case the port needs updating,
and in the latter case the livecheck needs fixing.

On 2009-5-23 17:48, Jeremy Lavergne wrote:
> Nope, the only reason was I trusted livecheck.
> 
> My apologies.
> 
> On May 23, 2009, at 3:00 AM, Ryan Schmidt wrote:
> 
>> Unless there's a special reason you downgraded the version, you should
>> revert this change. 0.9.27 is from August 2008 while 0.9.5 is from
>> September 2006.


From ryandesign at macports.org  Sat May 23 02:32:31 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 23 May 2009 04:32:31 -0500
Subject: How are new volunteers "processed" these days?
In-Reply-To: <6CFDC712-BB50-4289-80DB-2445EE6E29C8@apple.com>
References: <6CFDC712-BB50-4289-80DB-2445EE6E29C8@apple.com>
Message-ID: <518F244D-5CE5-448A-9579-84A68900B134@macports.org>


On May 23, 2009, at 04:11, Jordan K. Hubbard wrote:

> After seeing 2 people volunteer their services as MacPorts  
> committers recently, it occurred to me to wonder just how these  
> sorts of ad-hoc, informal "how can I help?" messages are being  
> acted on.  If someone from project management has already quietly  
> followed up to those folks off-list, with encouraging words and the  
> usual array of necessary questions, then I apologize in advance for  
> even implying that the team is anything but totally on top of this  
> important function!

The way we'd like it to be handled is this way:

http://guide.macports.org/#project.membership

Someone who wishes to become a committer sends a message to the  
portmgr email address and demonstrates how they have fulfilled the  
requirements listed there.

Rainer already forwarded Thomas de Grivel's request to the portmgr  
list where we will now discuss the request and then give a response.

The portmgr list is for the managers only and is not open so regular  
users and committers can't see these requests or discussions, so the  
first indication of the existence of a new committer might be the  
addition of their handle to the MacPortsDevelopers wiki page, or  
their first commit coming through on the macports-changes list. The  
history of that page can show who was added when.

http://trac.macports.org/wiki/MacPortsDevelopers?action=history

Though the comment field is often blank, we ask new committers to add  
themselves to the list, so the first occurrence of a new address in  
the Author column is probably when that person became a committer.


From ryandesign at macports.org  Sat May 23 07:12:17 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 23 May 2009 09:12:17 -0500
Subject: [51366] trunk/dports/science/irsim/Portfile
In-Reply-To: <20090523140133.69F991C100BD@beta.macosforge.org>
References: <20090523140133.69F991C100BD@beta.macosforge.org>
Message-ID: <EC0FE2EA-68D5-47D5-BC13-AB139FB6721E@macports.org>


On May 23, 2009, at 09:01, and.damore at macports.org wrote:

> -master_sites        http://opencircuitdesign.com/irsim/archive/
> +master_sites        http://opencircuitdesign.com/irsim/

I don't believe this change was correct. The files are in fact still  
located in the archive subdirectory, as far as I can tell.


From loshea at gmail.com  Sat May 23 08:10:40 2009
From: loshea at gmail.com (Luis O'Shea)
Date: Sat, 23 May 2009 11:10:40 -0400
Subject: Asymptote port needs commit
Message-ID: <69EB18F1-13EC-4DC0-9701-7C31D2F72BFE@gmail.com>

See http://trac.macports.org/ticket/19687

Thanks.

Luis

From and.damore at macports.org  Sat May 23 09:05:50 2009
From: and.damore at macports.org (Andrea D'Amore)
Date: Sat, 23 May 2009 18:05:50 +0200
Subject: [51366] trunk/dports/science/irsim/Portfile
In-Reply-To: <EC0FE2EA-68D5-47D5-BC13-AB139FB6721E@macports.org>
References: <20090523140133.69F991C100BD@beta.macosforge.org>
	<EC0FE2EA-68D5-47D5-BC13-AB139FB6721E@macports.org>
Message-ID: <8F428013-3826-4F86-A499-BAE48D126371@macports.org>

On 23/mag/09, at 16:12, Ryan Schmidt wrote:

> I don't believe this change was correct. The files are in fact still  
> located in the archive subdirectory, as far as I can tell.

Definitely, I misread and thought it was homepage instead.

Fixed in r51374 .


--

Andrea

From and.damore at macports.org  Sat May 23 09:13:42 2009
From: and.damore at macports.org (Andrea D'Amore)
Date: Sat, 23 May 2009 18:13:42 +0200
Subject: Asymptote port needs commit
In-Reply-To: <69EB18F1-13EC-4DC0-9701-7C31D2F72BFE@gmail.com>
References: <69EB18F1-13EC-4DC0-9701-7C31D2F72BFE@gmail.com>
Message-ID: <3EEDFA8B-FA1E-4E9A-9EB2-052F20444FC6@macports.org>

On 23/mag/09, at 17:10, Luis O'Shea wrote:

> See http://trac.macports.org/ticket/19687

Committed in r51375 .

From smibrahim at gmail.com  Sat May 23 09:27:16 2009
From: smibrahim at gmail.com (S. M. Ibrahim (Lavlu))
Date: Sat, 23 May 2009 22:27:16 +0600
Subject: How are new volunteers "processed" these days?
In-Reply-To: <518F244D-5CE5-448A-9579-84A68900B134@macports.org>
References: <6CFDC712-BB50-4289-80DB-2445EE6E29C8@apple.com>
	<518F244D-5CE5-448A-9579-84A68900B134@macports.org>
Message-ID: <4997275b0905230927w60cd7f10g77634742bbfbd6c2@mail.gmail.com>

2009/5/23 Ryan Schmidt <ryandesign at macports.org>:
>
> On May 23, 2009, at 04:11, Jordan K. Hubbard wrote:
>
>> After seeing 2 people volunteer their services as MacPorts committers
>> recently, it occurred to me to wonder just how these sorts of ad-hoc,
>> informal "how can I help?" messages are being acted on. ?If someone from
>> project management has already quietly followed up to those folks off-list,
>> with encouraging words and the usual array of necessary questions, then I
>> apologize in advance for even implying that the team is anything but totally
>> on top of this important function!
>
> The way we'd like it to be handled is this way:
>
> http://guide.macports.org/#project.membership
>
> Someone who wishes to become a committer sends a message to the portmgr
> email address and demonstrates how they have fulfilled the requirements
> listed there.
>
> Rainer already forwarded Thomas de Grivel's request to the portmgr list
> where we will now discuss the request and then give a response.
>
> The portmgr list is for the managers only and is not open so regular users
> and committers can't see these requests or discussions, so the first
> indication of the existence of a new committer might be the addition of
> their handle to the MacPortsDevelopers wiki page, or their first commit
> coming through on the macports-changes list. The history of that page can
> show who was added when.
>
> http://trac.macports.org/wiki/MacPortsDevelopers?action=history
>
> Though the comment field is often blank, we ask new committers to add
> themselves to the list, so the first occurrence of a new address in the
> Author column is probably when that person became a committer.
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>
ryan,
i already mailed to portmgr 2 times for commit permission. but never
got any reply from them. i think if you (portmgr) deny my request, i
expect a reply from you with details.

thanks


-- 
S. M. Ibrahim Lavlu
software engineer, php
somewhere in...
http://www.somewherein.net

bangla blog: http://www.somewhereinblog.net
my blog: http://www.lavluda.com
mac blog: htttp://www.mac-talks.com

From raimue at macports.org  Sat May 23 09:31:19 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 23 May 2009 18:31:19 +0200
Subject: How are new volunteers "processed" these days?
In-Reply-To: <6CFDC712-BB50-4289-80DB-2445EE6E29C8@apple.com>
References: <6CFDC712-BB50-4289-80DB-2445EE6E29C8@apple.com>
Message-ID: <4A1824D7.20504@macports.org>

On 2009-05-23 11:11, Jordan K. Hubbard wrote:
> After seeing 2 people volunteer their services as MacPorts committers  
> recently, it occurred to me to wonder just how these sorts of ad-hoc,  
> informal "how can I help?" messages are being acted on.  If someone  
> from project management has already quietly followed up to those folks  
> off-list, with encouraging words and the usual array of necessary  
> questions, then I apologize in advance for even implying that the team  
> is anything but totally on top of this important function!

Yes, we followed up the requests for commit rights on the portmgr list.

If it makes the process more transparent, should we announce new
committers on macports-dev as an introduction to the community?

Rainer

From raimue at macports.org  Sat May 23 09:39:26 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 23 May 2009 18:39:26 +0200
Subject: [50797] trunk/dports/gnome/gnome-platform-suite/Portfile
In-Reply-To: <49C93220-8C16-4003-987A-666C2A16B3A8@macports.org>
References: <20090509204053.E4AA7180A9D5@beta.macosforge.org>	<4A158F6F.40503@macports.org>
	<49C93220-8C16-4003-987A-666C2A16B3A8@macports.org>
Message-ID: <4A1826BE.1070708@macports.org>

On 2009-05-23 09:08, Ryan Schmidt wrote:
> On May 21, 2009, at 12:29, David Evans wrote:
>> Also I'm not sure why you made it a path dependency.  Should this  
>> be done globally?
> 
> I am getting tired of having to monitor ports' dependencies for  
> things like "port:pango" and "port:cairo" and "port:glib2" and  
> "port:graphviz" and any other port:-style dependency on something for  
> which a -devel version exists, and then change it to a path  
> dependency. :) I'm trying to get in the habit of using a path:-style  
> dependency always, even if a -devel version does not currently exist,  
> because maybe tomorrow someone will want to create a -devel version.  
> We may want to make path:-style dependencies the recommended way to  
> specify dependencies.

We need some 'provides' keyword which would allow multiple ports to
provide the same thing. This would be used in -devel ports to indicate
they are providing the same thing. Also, it should not be possible to
install two ports providing the same thing so it would be some kind of
conflict indicator.

But for now, using path:-style is the only option we have.

Rainer

From opendarwin.org at darkart.com  Sat May 23 10:11:55 2009
From: opendarwin.org at darkart.com (Eric Hall)
Date: Sat, 23 May 2009 17:11:55 +0000
Subject: How are new volunteers "processed" these days?
In-Reply-To: <4A1824D7.20504@macports.org>
References: <6CFDC712-BB50-4289-80DB-2445EE6E29C8@apple.com>
	<4A1824D7.20504@macports.org>
Message-ID: <20090523171154.GD1033@darkart.com>

On Sat, May 23, 2009 at 06:31:19PM +0200, Rainer M?ller wrote:
> On 2009-05-23 11:11, Jordan K. Hubbard wrote:
> > After seeing 2 people volunteer their services as MacPorts committers  
> > recently, it occurred to me to wonder just how these sorts of ad-hoc,  
> > informal "how can I help?" messages are being acted on.  If someone  
> > from project management has already quietly followed up to those folks  
> > off-list, with encouraging words and the usual array of necessary  
> > questions, then I apologize in advance for even implying that the team  
> > is anything but totally on top of this important function!
> 
> Yes, we followed up the requests for commit rights on the portmgr list.
> 
> If it makes the process more transparent, should we announce new
> committers on macports-dev as an introduction to the community?
> 

	I think that'd be great - it provides visibility of the
new committers and indications to others that the project gets
and accepts new blood.


		-eric


From jkh at apple.com  Sat May 23 12:48:30 2009
From: jkh at apple.com (Jordan K. Hubbard)
Date: Sat, 23 May 2009 12:48:30 -0700
Subject: How are new volunteers "processed" these days?
In-Reply-To: <4A1824D7.20504@macports.org>
References: <6CFDC712-BB50-4289-80DB-2445EE6E29C8@apple.com>
	<4A1824D7.20504@macports.org>
Message-ID: <42624474-7506-4DC8-BAC8-8B23A6C978FB@apple.com>


On May 23, 2009, at 9:31 AM, Rainer M?ller wrote:

> If it makes the process more transparent, should we announce new
> committers on macports-dev as an introduction to the community?

I think that's a great idea, and one which will also make new  
committers feel more, well, welcome!

- Jordan

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

From ryandesign at macports.org  Sat May 23 15:31:21 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 23 May 2009 17:31:21 -0500
Subject: How are new volunteers "processed" these days?
In-Reply-To: <4997275b0905230927w60cd7f10g77634742bbfbd6c2@mail.gmail.com>
References: <6CFDC712-BB50-4289-80DB-2445EE6E29C8@apple.com>
	<518F244D-5CE5-448A-9579-84A68900B134@macports.org>
	<4997275b0905230927w60cd7f10g77634742bbfbd6c2@mail.gmail.com>
Message-ID: <3E668B88-9ED5-4D4A-9411-8450E81F530C@macports.org>

On May 23, 2009, at 11:27, S. M. Ibrahim (Lavlu) wrote:

> i already mailed to portmgr 2 times for commit permission. but never
> got any reply from them. i think if you (portmgr) deny my request, i
> expect a reply from you with details.

I apologize for the delay. We have been considering your request.



From talklists at newgeo.com  Sat May 23 16:56:52 2009
From: talklists at newgeo.com (Scott Haneda)
Date: Sat, 23 May 2009 16:56:52 -0700
Subject: Port approval
Message-ID: <9137D2B8-C356-4968-81B8-A0D971633025@newgeo.com>

Starting to get the feeling someone does not like these two port  
files, if that is the case, please let me know...

I posted this to the users list, and have been updating the trac  
comments as well:

 From the users list:
> Hello, can someone closer to these two ports give me an idea of what  
> their status is?
> http://trac.macports.org/ticket/17709
> http://trac.macports.org/ticket/19432
>
> Maybe I am reading it wrong.  When there is a list, I can see  
> "status", though when I am on the details page, there does not seem  
> to be a status.
>
> I have tested both, thoroughly, and can confirm, that on 10.5, PPC,  
> and Intel, the patches work great.  On the PPC side, I have put  
> numerous hours into testing and configuring.  All seems well.
>
> I would love to see these up soon, so I can work on a new set of  
> install notes for postfix and dovecot, and also look into bumping  
> the versions of both, as releases for both were made last week on  
> postfix, and today, I believe, on dovecot.

I have patches for both that rely on these above patches.  And I am  
about to make more, to bump them.

Current postfix @2.5.5 Postfix is at 2.6 stable.  I am not sure going  
to 2.6 from the 2.5.5 is best, perhaps make a new port, as it may have  
changed significantly, to where an upgrade one would break a lot. At  
the very least, we can do 2.5.7, which has significant updates and is  
I believe, the last release in that branch to date.  I would love to  
supply this portfile, but need the above pushed out first.

Doveoct dovecot @1.1.11 should be easier at v1.1.15, I suspect just  
changing the version in the port file.

Myself and one other user here, who if he wants to reply can make  
himself known, are highly motivated with these two packages.  We are  
the only two to have them running via MacPorts with database backend  
support.

I took extensive detailed notes that are not far away from being able  
to fully replace whatever aged docs there are now.

What is the reason for the delay?  I have been pretty diligent in  
keeping an eye on them, making the users list aware of them, since I  
know there are people on that list that are here also.  I do not know  
anyone who has not made a mess of their system with tools like postfix  
enabler. In short time, MacPorts would become the definitive way to  
get POP/IMAP/SMTP with SSL/TLS on Mac OS X in a few commands in the  
shell.

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


From raimue at macports.org  Sat May 23 17:16:14 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sun, 24 May 2009 02:16:14 +0200
Subject: Port approval
In-Reply-To: <9137D2B8-C356-4968-81B8-A0D971633025@newgeo.com>
References: <9137D2B8-C356-4968-81B8-A0D971633025@newgeo.com>
Message-ID: <4A1891CE.6040407@macports.org>

On 2009-05-24 01:56, Scott Haneda wrote:
>  From the users list:
>> Hello, can someone closer to these two ports give me an idea of what  
>> their status is?
>> http://trac.macports.org/ticket/17709

No patch has been attached. Could you please attach it as it sounds you
are already using it?

>> http://trac.macports.org/ticket/19432

Committed in r51390.

Rainer

From talklists at newgeo.com  Sat May 23 18:17:30 2009
From: talklists at newgeo.com (Scott Haneda)
Date: Sat, 23 May 2009 18:17:30 -0700
Subject: Port approval
In-Reply-To: <4A1891CE.6040407@macports.org>
References: <9137D2B8-C356-4968-81B8-A0D971633025@newgeo.com>
	<4A1891CE.6040407@macports.org>
Message-ID: <9ED780C2-6805-47F1-85F4-6A9257E94F30@newgeo.com>

On May 23, 2009, at 5:16 PM, Rainer M?ller wrote:

> On 2009-05-24 01:56, Scott Haneda wrote:
>> From the users list:
>>> Hello, can someone closer to these two ports give me an idea of what
>>> their status is?
>>> http://trac.macports.org/ticket/17709
>
> No patch has been attached. Could you please attach it as it sounds  
> you
> are already using it?

Totally bizarre, I have attached a patch.  It was supplied to me by  
another macports users, which I have noted on the attachement.  It is  
the very one I have deployed against.

>>> http://trac.macports.org/ticket/19432
>
> Committed in r51390.

Thanks.  When they are committed, does that mean I have access to  
them, selfupdate would pick them up, or is there some waiting time?
-- 
Scott * If you contact me off list replace talklists@ with scott@ *


From jmr at macports.org  Sat May 23 18:47:05 2009
From: jmr at macports.org (Joshua Root)
Date: Sun, 24 May 2009 11:47:05 +1000
Subject: Port approval
In-Reply-To: <9ED780C2-6805-47F1-85F4-6A9257E94F30@newgeo.com>
References: <9137D2B8-C356-4968-81B8-A0D971633025@newgeo.com>	<4A1891CE.6040407@macports.org>
	<9ED780C2-6805-47F1-85F4-6A9257E94F30@newgeo.com>
Message-ID: <4A18A719.8000501@macports.org>

On 2009-5-24 11:17, Scott Haneda wrote:
> On May 23, 2009, at 5:16 PM, Rainer M?ller wrote:
>> Committed in r51390.
> 
> Thanks.  When they are committed, does that mean I have access to them,
> selfupdate would pick them up, or is there some waiting time?

Up to about 30 minutes before it hits rsync, and up to about an hour
before it reaches the PortIndex.

- Josh

From macports-mgr at lists.macosforge.org  Sun May 24 13:15:08 2009
From: macports-mgr at lists.macosforge.org (macports-mgr at lists.macosforge.org)
Date: Sun, 24 May 2009 13:15:08 -0700 (PDT)
Subject: PortIndex2MySQL run failure on Sunday 2009-05-24 at 13:15:00
Message-ID: <20090524201508.E47852BE6376@gamma.macosforge.org>


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

From blb at macports.org  Sun May 24 13:33:29 2009
From: blb at macports.org (Bryan Blackburn)
Date: Sun, 24 May 2009 14:33:29 -0600
Subject: PortIndex2MySQL run failure on Sunday 2009-05-24 at 13:15:00
In-Reply-To: <20090524201508.E47852BE6376@gamma.macosforge.org>
References: <20090524201508.E47852BE6376@gamma.macosforge.org>
Message-ID: <20090524203329.GE88633@ninagal.withay.com>

On Sun, May 24, 2009 at 01:15:08PM -0700, macports-mgr at lists.macosforge.org said:
> 
> Synchronizing local ports tree from file:///rsync/macports-san/release/ports/
> Error: CHILDSTATUS 18426 1: ERROR 1062 (23000) at line 43625: Duplicate entry 'midgard2-core' for key 1

So we now have a midgard2-core under devel [1] and one in www [2],
considering r51369 [3] I'm guessing the one in www should be deleted?

Bryan

[1] - <http://trac.macports.org/log/trunk/dports/devel/midgard2-core>
[2] - <http://trac.macports.org/log/trunk/dports/www/midgard2-core>
[3] - <http://trac.macports.org/changeset/51369>


From joseph at josephholsten.com  Sun May 24 14:04:48 2009
From: joseph at josephholsten.com (Joseph A Holsten)
Date: Sun, 24 May 2009 16:04:48 -0500
Subject: PortIndex2MySQL run failure on Sunday 2009-05-24 at 13:15:00
In-Reply-To: <20090524203329.GE88633@ninagal.withay.com>
References: <20090524201508.E47852BE6376@gamma.macosforge.org>
	<20090524203329.GE88633@ninagal.withay.com>
Message-ID: <0FE7B876-03A6-4F5B-9B6E-7BC02F37E4F4@josephholsten.com>

Bryan Blackburn wrote:
> So we now have a midgard2-core under devel [1] and one in www [2],
> considering r51369 [3] I'm guessing the one in www should be deleted?
>
> [1] - <http://trac.macports.org/log/trunk/dports/devel/midgard2-core>
> [2] - <http://trac.macports.org/log/trunk/dports/www/midgard2-core>
> [3] - <http://trac.macports.org/changeset/51369>

If that's going to change, www/midgard-{apache2,core,data} probably  
need to move too.

http://josephholsten.com

From macports-mgr at lists.macosforge.org  Mon May 25 01:15:09 2009
From: macports-mgr at lists.macosforge.org (macports-mgr at lists.macosforge.org)
Date: Mon, 25 May 2009 01:15:09 -0700 (PDT)
Subject: PortIndex2MySQL run failure on Monday 2009-05-25 at 01:15:00
Message-ID: <20090525081509.193592BF4F1C@gamma.macosforge.org>


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

From ryandesign at macports.org  Mon May 25 02:19:27 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Mon, 25 May 2009 04:19:27 -0500
Subject: PortIndex2MySQL run failure on Sunday 2009-05-24 at 13:15:00
In-Reply-To: <0FE7B876-03A6-4F5B-9B6E-7BC02F37E4F4@josephholsten.com>
References: <20090524201508.E47852BE6376@gamma.macosforge.org>
	<20090524203329.GE88633@ninagal.withay.com>
	<0FE7B876-03A6-4F5B-9B6E-7BC02F37E4F4@josephholsten.com>
Message-ID: <6F51DD5E-D865-45EB-AE72-2654E6C4000D@macports.org>


On May 24, 2009, at 16:04, Joseph A Holsten wrote:

> Bryan Blackburn wrote:
>
>> So we now have a midgard2-core under devel [1] and one in www [2],
>> considering r51369 [3] I'm guessing the one in www should be deleted?
>>
>> [1] - <http://trac.macports.org/log/trunk/dports/devel/midgard2-core>
>> [2] - <http://trac.macports.org/log/trunk/dports/www/midgard2-core>
>> [3] - <http://trac.macports.org/changeset/51369>

Agreed, I removed the copy in www in r51449.


> If that's going to change, www/midgard-{apache2,core,data} probably  
> need to move too.

The description of each of those ports reads:

"Midgard is a content management system platform using Apache, PHP  
and MySQL."

The description of midgard2-core reads:

"Midgard is a content repository system platform with bindings in  
PHP, Python etc."

The commit message for r51369 reads:

"change categories to reflect the changed nature of Midgard2  
framework from the previous version"

Based on that, I assumed Midgard 1 was properly placed in www, while  
Midgard 2 now has a larger focus. But I don't know Midgard so I will  
let the maintainer decide.



From raimue at macports.org  Mon May 25 04:58:20 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Mon, 25 May 2009 13:58:20 +0200
Subject: [51429] trunk/base/src/macports1.0/macports_fastload.tcl.in
In-Reply-To: <20090525041744.39A331C22DEC@beta.macosforge.org>
References: <20090525041744.39A331C22DEC@beta.macosforge.org>
Message-ID: <4A1A87DC.5000701@macports.org>

On 2009-05-25 06:17, blb at macports.org wrote:
> Revision: 51429
>           http://trac.macports.org/changeset/51429
> Author:   blb at macports.org
> Date:     2009-05-24 21:17:42 -0700 (Sun, 24 May 2009)
> Log Message:
> -----------
> macports1.0/macports_fastload.tcl.in - don't try sourcing files from a
> non-existent directory; fixes an issue during make to a new prefix where
> the share/macports/Tcl dir doesn't yet exist
> 
> Modified Paths:
> --------------
>     trunk/base/src/macports1.0/macports_fastload.tcl.in
> 
> Modified: trunk/base/src/macports1.0/macports_fastload.tcl.in
> ===================================================================
> --- trunk/base/src/macports1.0/macports_fastload.tcl.in	2009-05-25 03:30:44 UTC (rev 51428)
> +++ trunk/base/src/macports1.0/macports_fastload.tcl.in	2009-05-25 04:17:42 UTC (rev 51429)
> @@ -73,8 +73,11 @@
>  set dir [file join "@TCL_PACKAGE_DIR@" macports1.0]
>  catch {source [file join $dir pkgIndex.tcl]}
>  
> -foreach dir [glob -directory "@prefix_expanded@" -join share macports Tcl *] {
> -	catch {source [file join $dir pkgIndex.tcl]}
> +set sharetcldir [file join "@prefix_expanded@" share macports Tcl]
> +if {[file exists $sharetcldir]} {
> +	foreach dir [glob -directory $sharetcldir *] {
> +		catch {source [file join $dir pkgIndex.tcl]}
> +	}
>  }

Shouldn't this correctly result in an error otherwise as it failed to
load port1.0 and others?

Is the problem with one of the Tcl scripts we run at install time? Maybe
they have to be delayed until all files are copied then.

Rainer

From jeremy at lavergne.gotdns.org  Mon May 25 10:08:40 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Mon, 25 May 2009 13:08:40 -0400
Subject: [MacPorts] howto/InstallingOlderPort modified
In-Reply-To: <20090525170729.DE2A92807F@relay11.apple.com>
References: <20090525170729.DE2A92807F@relay11.apple.com>
Message-ID: <D3D37A6E-B670-4CDC-BB1F-E1589FDD8829@lavergne.gotdns.org>

You might consider mentioning that older versions can be kept just  
deactivated. So if something goes wrong you can "rollback" the version.

On May 25, 2009, at 1:07 PM, MacPorts wrote:

>
> Changed page "howto/InstallingOlderPort" by ryandesign at macports.org  
> from 70.114.129.90*
> Page URL: <http://trac.macports.org/wiki/howto/InstallingOlderPort>
> Diff URL: <http://trac.macports.org/wiki/howto/InstallingOlderPort?action=diff&version=7 
> >
> Revision 7
> Comment: reword introduction, removing word "limitation"
>
> -------8 
> <------8<------8<------8<------8<------8<------8<------8<--------
> Index: howto/InstallingOlderPort
> = 
> = 
> = 
> ======================================================================
> --- howto/InstallingOlderPort (version: 6)
> +++ howto/InstallingOlderPort (version: 7)
> @@ -7,7 +7,7 @@
>
> == Introduction ==
>
> -MacPorts does not include a feature to let you install an older  
> version of a port. It only lets you install the current version of  
> the port that has been created by the port author. But by getting an  
> older version of the portfile from the Subversion versioning system,  
> this limitation can be worked around.
> +MacPorts does not include a feature to let you install an older  
> version of a port. It only lets you install the current version of  
> the port that has been created by the port author. You can work  
> around this by getting an older version of the portfile from the  
> Subversion repository.
>
> == Installation ==
>
>
> -------8 
> <------8<------8<------8<------8<------8<------8<------8<--------
>
> * The IP shown here might not mean anything if the user or the  
> server is
> behind a proxy.
>
> --
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS
>
> This is an automated message. Someone at http://www.macports.org/  
> added your email
> address to be notified of changes on howto/InstallingOlderPort. If  
> it was not you, please
> report to .
> _______________________________________________
> macports-changes mailing list
> macports-changes at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes
>

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

From pgnet.dev+macports at gmail.com  Mon May 25 12:37:12 2009
From: pgnet.dev+macports at gmail.com (PGNet Dev)
Date: Mon, 25 May 2009 12:37:12 -0700
Subject: depends_* with variants in Portfiles?
Message-ID: <94f2e81e0905251237r37eeef8ard2936aa76ec1810@mail.gmail.com>

( i just joined list; if there's a pre-existing thread on this topic
in macports-dev, can someone 'point' to it? thx!)

i'm mod'ing ncurses' release Portfile to include config for the ABI=6 variant.

it's a trivial addition,

  variant abi6 description {new ABI for > 256 Color Support} {
      configure.args-append "--with-abi-version=6"
  }

but ...

the ncurses Portfile includes,

  ...
  # required for terminfo
  depends_run     port:ncursesw
  ...

which, in the case of the "+abi6" variant, should _also_ be a
similarly mod'd "+abi6" variant of port:ncursesw.

i'd thought/hoped that that could be dealt with simply by, e.g.,

 ---   depends_run     port:ncursesw
 +++   depends_run     port:ncursesw +abi6

it seems, however, that that's not so simple, per,

  "dependencies need to allow inclusion of variant"
   http://trac.macports.org/ticket/126  ( Opened 7 years ago !? )

         " ... but if you would like to discuss why this should be
implemented and how it could be done, by all means bring it up on
macports-dev. When a consensus is reached, more code can be written.
..."

it's not yet doable :-/

so, 1st, the "why".

if not 'with variants' for depends_*, how -- e.g., in my particular
case of "ncurses(w) +abi6" -- else should this be done? not an
uncommon occurrence, I'd suggest.   there is, of course, the path of
completely separate ports/Portfiles, but that seems silly ...

From blb at macports.org  Mon May 25 12:52:55 2009
From: blb at macports.org (Bryan Blackburn)
Date: Mon, 25 May 2009 13:52:55 -0600
Subject: [51429] trunk/base/src/macports1.0/macports_fastload.tcl.in
In-Reply-To: <4A1A87DC.5000701@macports.org>
References: <20090525041744.39A331C22DEC@beta.macosforge.org>
	<4A1A87DC.5000701@macports.org>
Message-ID: <20090525195255.GE817@ninagal.withay.com>

On Mon, May 25, 2009 at 01:58:20PM +0200, Rainer M?ller said:
> On 2009-05-25 06:17, blb at macports.org wrote:
> > Revision: 51429
> >           http://trac.macports.org/changeset/51429
[...]
> > -foreach dir [glob -directory "@prefix_expanded@" -join share macports Tcl *] {
> > -	catch {source [file join $dir pkgIndex.tcl]}
> > +set sharetcldir [file join "@prefix_expanded@" share macports Tcl]
> > +if {[file exists $sharetcldir]} {
> > +	foreach dir [glob -directory $sharetcldir *] {
> > +		catch {source [file join $dir pkgIndex.tcl]}
> > +	}
> >  }
> 
> Shouldn't this correctly result in an error otherwise as it failed to
> load port1.0 and others?

The problem is that it does result in an error, during make; for a new
prefix, the share/macports/Tcl dir doesn't exist and glob errors out.  For
example:

$ ./configure --prefix=/newlocation
...
$ make
...
===> making all in src/macports1.0
gcc -c -DUSE_TCL_STUBS -DTCL_NO_DEPRECATED -g -O2 -W -Wall -pedantic
-DHAVE_CONFIG_H -I.. -I.  -I"/usr/include" -fno-common macports.c -o
macports.o
cc -dynamiclib -L/usr/local/lib  macports.o -o MacPorts.dylib
-L/System/Library/Frameworks/Tcl.framework/Versions/8.4 -ltclstub8.4
-L/usr/local/lib  
warning: error while sourcing macports_fastload.tcl: no files matched glob
pattern "*"
make[2]: *** [pkgIndex.tcl] Error 1
make[1]: *** [all] Error 1
make: *** [all] Error 1


Since macports_fastload.tcl doesn't know whether it's being called during
make or actual runtime, I couldn't think of a better solution than this.

> 
> Is the problem with one of the Tcl scripts we run at install time? Maybe
> they have to be delayed until all files are copied then.

It's part of the pkgIndex stuff so when you made it more sensitive to errors
with pkg_mkindex.sh the error now stops make.  Note that if you run make
again all is fine...

Bryan


> 
> Rainer

From macports-mgr at lists.macosforge.org  Mon May 25 13:15:08 2009
From: macports-mgr at lists.macosforge.org (macports-mgr at lists.macosforge.org)
Date: Mon, 25 May 2009 13:15:08 -0700 (PDT)
Subject: PortIndex2MySQL run failure on Monday 2009-05-25 at 13:15:00
Message-ID: <20090525201508.C75902C0774A@gamma.macosforge.org>


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

From jmr at macports.org  Mon May 25 15:13:21 2009
From: jmr at macports.org (Joshua Root)
Date: Tue, 26 May 2009 08:13:21 +1000
Subject: depends_* with variants in Portfiles?
In-Reply-To: <94f2e81e0905251237r37eeef8ard2936aa76ec1810@mail.gmail.com>
References: <94f2e81e0905251237r37eeef8ard2936aa76ec1810@mail.gmail.com>
Message-ID: <4A1B1801.8010101@macports.org>

On 2009-5-26 05:37, PGNet Dev wrote:
>   "dependencies need to allow inclusion of variant"
>    http://trac.macports.org/ticket/126  ( Opened 7 years ago !? )
> 
>          " ... but if you would like to discuss why this should be
> implemented and how it could be done, by all means bring it up on
> macports-dev. When a consensus is reached, more code can be written.
> ..."
> 
> it's not yet doable :-/

A proper fix needs some more information stored in the registry, so #126
is effectively blocked on the completion of registry2.0. After that,
what needs to be done isn't conceptually difficult, it's just a lot of work.

- Josh

From raimue at macports.org  Mon May 25 15:32:16 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Tue, 26 May 2009 00:32:16 +0200
Subject: [51429] trunk/base/src/macports1.0/macports_fastload.tcl.in
In-Reply-To: <20090525195255.GE817@ninagal.withay.com>
References: <20090525041744.39A331C22DEC@beta.macosforge.org>	<4A1A87DC.5000701@macports.org>
	<20090525195255.GE817@ninagal.withay.com>
Message-ID: <4A1B1C70.2020609@macports.org>

On 2009-05-25 21:52, Bryan Blackburn wrote:
> On Mon, May 25, 2009 at 01:58:20PM +0200, Rainer M?ller said:
>> On 2009-05-25 06:17, blb at macports.org wrote:
> Since macports_fastload.tcl doesn't know whether it's being called during
> make or actual runtime, I couldn't think of a better solution than this.
> 
>> Is the problem with one of the Tcl scripts we run at install time? Maybe
>> they have to be delayed until all files are copied then.
> 
> It's part of the pkgIndex stuff so when you made it more sensitive to errors
> with pkg_mkindex.sh the error now stops make.  Note that if you run make
> again all is fine...

Oh, so pkg_mkIndex actually evaluates the code. I thought it just parses
for procs in the files. I did a quick test by adding a puts statement in
the file and it really gets executed.

Good to be aware it does that, but also kind of evil...

Rainer

From emer at emer.net  Mon May 25 15:33:18 2009
From: emer at emer.net (Mark Anderson)
Date: Mon, 25 May 2009 18:33:18 -0400
Subject: [MacPorts] #19748: tesseract: fails doing "make install"
In-Reply-To: <066.aca33db306d7528d47ffc8ed88727bd8@macports.org>
References: <057.e33023a8b7451775a688a8557c60d077@macports.org> 
	<066.aca33db306d7528d47ffc8ed88727bd8@macports.org>
Message-ID: <2cf4100f0905251533g33a823fbm6a28fe37e3f187de@mail.gmail.com>

Yeah, I was going to do something similar. Thanks. I'll have to start
checking against Case-Sensitive file systems.

Mark

On Mon, May 25, 2009 at 1:15 AM, MacPorts <noreply at macports.org> wrote:

> #19748: tesseract: fails doing "make install"
>
> ------------------------------------+---------------------------------------
>  Reporter:  Damien@?               |       Owner:  emer@?
>       Type:  defect                 |      Status:  closed
>   Priority:  Normal                 |   Milestone:
>  Component:  ports                  |     Version:  1.7.1
> Resolution:  fixed                  |    Keywords:  make, install, java
>      Port:  tesseract              |
>
> ------------------------------------+---------------------------------------
> Changes (by blb@?):
>
>  * status:  new => closed
>  * resolution:  => fixed
>
>
> Comment:
>
>  Replying to [comment:5 hans@?]:
>  > Leopard on Intel, Xcode 3.0 (though I think it's irrelevant). I still
>  think the case-sensitive filesystem is causing the makefile problem.
>
>  Note that there are issues with some of the tools shipped with Xcode 3.0
>  which are fixed in 3.1.x; though this isn't one of them.
>
>  It looks like there is a java/makefile on extract, which is overwritten by
>  Makefile during configure on case-insensitive filesystems; but obviously
>  not on case-sensitive, so the error occurs.  Fixed in r51430 (not awaiting
>  maintainer approval since it is broken for some).
>
> --
> Ticket URL: <http://trac.macports.org/ticket/19748#comment:7>
> MacPorts <http://www.macports.org/>
> Ports system for Mac OS
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090525/d8dc625d/attachment-0001.html>

From blb at macports.org  Mon May 25 18:52:41 2009
From: blb at macports.org (Bryan Blackburn)
Date: Mon, 25 May 2009 19:52:41 -0600
Subject: [51429] trunk/base/src/macports1.0/macports_fastload.tcl.in
In-Reply-To: <4A1B1C70.2020609@macports.org>
References: <20090525041744.39A331C22DEC@beta.macosforge.org>
	<4A1A87DC.5000701@macports.org>
	<20090525195255.GE817@ninagal.withay.com>
	<4A1B1C70.2020609@macports.org>
Message-ID: <20090526015241.GG817@ninagal.withay.com>

On Tue, May 26, 2009 at 12:32:16AM +0200, Rainer M?ller said:
> On 2009-05-25 21:52, Bryan Blackburn wrote:
> > On Mon, May 25, 2009 at 01:58:20PM +0200, Rainer M?ller said:
> >> On 2009-05-25 06:17, blb at macports.org wrote:
> > Since macports_fastload.tcl doesn't know whether it's being called during
> > make or actual runtime, I couldn't think of a better solution than this.
> > 
> >> Is the problem with one of the Tcl scripts we run at install time? Maybe
> >> they have to be delayed until all files are copied then.
> > 
> > It's part of the pkgIndex stuff so when you made it more sensitive to errors
> > with pkg_mkindex.sh the error now stops make.  Note that if you run make
> > again all is fine...
> 
> Oh, so pkg_mkIndex actually evaluates the code. I thought it just parses
> for procs in the files. I did a quick test by adding a puts statement in
> the file and it really gets executed.
> 
> Good to be aware it does that, but also kind of evil...

Yeah, pkg_mkIndex basically sources each file, or to quote the man page

   It does this by loading each file into a slave interpreter and seeing
   what packages and new commands appear (this is why it is essential to
   have package provide commands or Tcl_PkgProvide calls in the files,
   as described above).

At least fastload was the only one causing an issue.

Bryan


> 
> Rainer

From markd at macports.org  Mon May 25 20:12:37 2009
From: markd at macports.org (markd at macports.org)
Date: Mon, 25 May 2009 20:12:37 -0700
Subject: Port approval
Message-ID: <fc.004c4c581259e737004c4c581259e737.1259eb76@biola.edu>

>Current postfix @2.5.5 Postfix is at 2.6 stable.  I am not sure going 
>to 2.6 from the 2.5.5 is best, perhaps make a new port, as it may have 
>changed significantly, to where an upgrade one would break a lot. At 
>the very least, we can do 2.5.7, which has significant updates and is 
>I believe, the last release in that branch to date.  I would love to 
>supply this portfile, but need the above pushed out first. 

This is where MacPorts differs from other package managers as far as I can
tell.  That a new release might break stuff is always the case, and not a
sufficient reason to create multiple versions of the same port (though
-devel is a standard for non-stable code).  Postfix 2.6.1 is listed as
stable and so the preference would be to update the port to that or wait
until a future rev if not possible (reporting trouble to the postfix
developers in that case).  That said, the postfix port is in desperate
need of a maintainer, and I'm not at all certain that the portfile is how
it should be (I wonder if the Makefile could not be used instead of
xinstalls and such).  I have cleaned it up from a horrible mess in the
past since no one else did but I wish someone who uses it in production
would step up and maintain it.

Mark


From ryandesign at macports.org  Mon May 25 23:51:25 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Tue, 26 May 2009 01:51:25 -0500
Subject: depends_* with variants in Portfiles?
In-Reply-To: <94f2e81e0905251237r37eeef8ard2936aa76ec1810@mail.gmail.com>
References: <94f2e81e0905251237r37eeef8ard2936aa76ec1810@mail.gmail.com>
Message-ID: <68B4A5AF-C698-455E-B707-F9A016A41021@macports.org>


On May 25, 2009, at 14:37, PGNet Dev wrote:

>   "dependencies need to allow inclusion of variant"
>    http://trac.macports.org/ticket/126  ( Opened 7 years ago !? )
>
>          " ... but if you would like to discuss why this should be
> implemented and how it could be done, by all means bring it up on
> macports-dev. When a consensus is reached, more code can be written.
> ..."
>
> it's not yet doable :-/
>
> so, 1st, the "why".
>
> if not 'with variants' for depends_*, how -- e.g., in my particular
> case of "ncurses(w) +abi6" -- else should this be done? not an
> uncommon occurrence, I'd suggest.   there is, of course, the path of
> completely separate ports/Portfiles, but that seems silly ...

In ncurses +abi6 you can check whether a particular file installed by  
ncursesw +abi6 is present. If not, bail and tell the user to first  
install ncursesw +abi6.

You can see an example of this strategy in the pango port, whose  
quartz and no_x11 variants check that cairo has been installed with  
the same variants before proceeding.

If ncursesw +abi6 does not cause any different set of files to be  
installed, you could install a dummy file in the variant, which you  
could then check for.


From macports-mgr at lists.macosforge.org  Tue May 26 01:15:08 2009
From: macports-mgr at lists.macosforge.org (macports-mgr at lists.macosforge.org)
Date: Tue, 26 May 2009 01:15:08 -0700 (PDT)
Subject: PortIndex2MySQL run failure on Tuesday 2009-05-26 at 01:15:00
Message-ID: <20090526081508.393002C186B1@gamma.macosforge.org>


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

From talklists at newgeo.com  Tue May 26 12:05:53 2009
From: talklists at newgeo.com (Scott Haneda)
Date: Tue, 26 May 2009 12:05:53 -0700
Subject: Port approval
In-Reply-To: <fc.004c4c581259e737004c4c581259e737.1259eb76@biola.edu>
References: <fc.004c4c581259e737004c4c581259e737.1259eb76@biola.edu>
Message-ID: <8E609289-AC45-4160-9C36-2C9F95D6CD6E@newgeo.com>

On May 25, 2009, at 8:12 PM, markd at macports.org wrote:

>> Current postfix @2.5.5 Postfix is at 2.6 stable.  I am not sure going
>> to 2.6 from the 2.5.5 is best, perhaps make a new port, as it may  
>> have
>> changed significantly, to where an upgrade one would break a lot. At
>> the very least, we can do 2.5.7, which has significant updates and is
>> I believe, the last release in that branch to date.  I would love to
>> supply this portfile, but need the above pushed out first.
>
> This is where MacPorts differs from other package managers as far as  
> I can
> tell.  That a new release might break stuff is always the case, and  
> not a
> sufficient reason to create multiple versions of the same port (though
> -devel is a standard for non-stable code).  Postfix 2.6.1 is listed as
> stable and so the preference would be to update the port to that or  
> wait
> until a future rev if not possible (reporting trouble to the postfix
> developers in that case).  That said, the postfix port is in desperate
> need of a maintainer, and I'm not at all certain that the portfile  
> is how
> it should be (I wonder if the Makefile could not be used instead of
> xinstalls and such).  I have cleaned it up from a horrible mess in the
> past since no one else did but I wish someone who uses it in  
> production
> would step up and maintain it.


I think that myself and a friend will end up stepping into the  
position of maintaining it.  It does work in the current form now, but  
it takes some fiddling to get it there.  I would have to review my  
notes, IIRC, there are users/groups/permissions, and directories that  
all need to be made to get it working well.  In no way does `port  
install postfix` get you a MTA that is good for more than pointing a  
php script at it.

I brought up the versioning issues on the postfix list.  That list is  
a little bit of walking on eggshells :)  The general idea there, is do  
not upgrade unless you need the new features of the latest stable  
release.  So 2.5.7 contains only non new features of the 2.6 branch,  
but has back revisions of 2.6.x that are bug or security related.  I  
believe that is an accurate summary of what I was told.

That means, to me, that 2.6 is all new features.  That being the case,  
it may not be possible to gracefully go from 2.5 to 2.6, I will have  
to look into it.

Can you elaborate on your comments about using makefile over xinstall?

My next question, while not about postfix, applies perfectly to this  
thread as well.  For ages now, I am working on an ASSP portfile.  The  
number of perl depens is huge, the second I get it close, they update  
ASSP, and a new depens comes along that is not in MacPorts.  Make a  
new port for that, find it depens on some other, rinse, repeat.  Ugh.

With all this, I see no possible, conceivable way that the old ASSP  
port is going to be able to have a `port upgrade assp`.   It can not  
work.  The only way it could work, would be to riddle the port file  
with conditions to cover every version of ASSP from then to now,  
probably 50 revisions.

To me, sounds like this postfix issue is the same, the original port  
file was nice to have, someone put in the time to do it, we are all  
grateful.  A lot has changed since then, to try to keep that portfile  
relevant moving forward, means a lot more work for a new maintainer.   
Postfix's portfile may not be that out of date, so keep this more  
theoretical in discussion that just about postfix.

What do we do in cases where older ports are part of software that  
changes rapidly, and a huge duration of time has passed with no port  
update happening.  To me, if the portfile has not been updated close  
to the update cycle of the software it builds, in a lot of cases, the  
only logical thing to do would be to "fork" the port, and start clean.

A lot of these ports are "systems".  It is not like awk, sed, nano,  
tail etc, where you have one small little binary you are messing  
with.  These "systems" have a binary, but they sit on top of, or next  
to, user data, users, groups, permissions, scripts.  In cases like  
that we need a very committed maintainer, who will stick with it.   
Otherwise, I fear we end up with what I am doing now, making a local  
port, not worrying about previous ports, and moving on.  Then I  
distribute that port off list, off project, and the community does not  
benefit from it.  That is a huge shame, one I do not like to be a part  
of, but I also do not want to be a part of breaking every postfix mail  
server out there based on ports :)

Suggestions, comments?
-- 
Scott * If you contact me off list replace talklists@ with scott@ *


From dluke at geeklair.net  Tue May 26 12:47:47 2009
From: dluke at geeklair.net (Daniel J. Luke)
Date: Tue, 26 May 2009 15:47:47 -0400
Subject: Port approval
In-Reply-To: <8E609289-AC45-4160-9C36-2C9F95D6CD6E@newgeo.com>
References: <fc.004c4c581259e737004c4c581259e737.1259eb76@biola.edu>
	<8E609289-AC45-4160-9C36-2C9F95D6CD6E@newgeo.com>
Message-ID: <21609B4C-E929-4B98-AAAC-FF33B183E65E@geeklair.net>

On May 26, 2009, at 3:05 PM, Scott Haneda wrote:
> That means, to me, that 2.6 is all new features.  That being the  
> case, it may not be possible to gracefully go from 2.5 to 2.6, I  
> will have to look into it.

My non-macports managed postfix install has been fine from 2.4 - 2.6  
(without having to mess with the rather simple config I have set up).

I would guess that more complicated installs may have issues, but  
presumably nothing that the people who set up the install would be  
unable to deal with.

I would encourage you to use 2.6.1 (or whatever the latest current  
stable release is around when you get time to work on it).

> I also do not want to be a part of breaking every postfix mail  
> server out there based on ports :)


While it's nice when port maintainers go to a lot of effort to make  
'port upgrade' just do the right thing, it's not possible in all  
cases. I don't think it's necessary to split the port up in all of  
those situations.

Ultimately, it's up to the maintainer to make the decision about what  
level of effort should be put into trying to handle everything  
automatically and at what point to perhaps just point the person doing  
the upgrade/install to the documentation for that particular piece of  
software so that the end-user can figure out how to manage migration  
from one version to another.
--
Daniel J. Luke
+========================================================+
| *---------------- dluke at geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
|   Opinions expressed are mine and do not necessarily   |
|          reflect the opinions of my employer.          |
+========================================================+



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

From markd at macports.org  Tue May 26 15:23:27 2009
From: markd at macports.org (markd at macports.org)
Date: Tue, 26 May 2009 15:23:27 -0700
Subject: Port approval
Message-ID: <fc.004c4c58125bdfeb004c4c58125bdfeb.125bed19@biola.edu>


On May 26, 2009, at 3:05 PM, Scott Haneda wrote:
>Can you elaborate on your comments about using makefile over xinstall?

The portfile has a custom destroot section.  Look at what is between
'destroot {  }'  Normally this is not required and mp simply does a 'make
install' by default.  Not sure if this is really necessary still or a
legacy of an earlier poorly behaved version of postfix.
>
>My next question, while not about postfix, applies perfectly to this 
>thread as well.  For ages now, I am working on an ASSP portfile.  The 
>number of perl depens is huge, the second I get it close, they update 
>ASSP, and a new depens comes along that is not in MacPorts.  Make a 
>new port for that, find it depens on some other, rinse, repeat.  Ugh.

I've seen updates require other modules that haven't been ported too.  But
with perl modules, making ports is as easy as it gets so it isn't as bad
as it sounds.
>
>With all this, I see no possible, conceivable way that the old ASSP 
>port is going to be able to have a `port upgrade assp`.   It can not 
>work.  The only way it could work, would be to riddle the port file 
>with conditions to cover every version of ASSP from then to now, 
>probably 50 revisions.

It is great that you consider the users time and effort, but in my view
you are putting too much emphasis on possible breakage with 'port
upgrade'.  I don't use upgrade that much (so I don't see why it won't work
in this situation), but there are many circumstances beyond our control
that make upgrades difficult or impossible.  If the developer provides no
good way to upgrade, then we should not feel bad about failing to make a
port upgrade by overcoming what the developer could not or did not do.  I
think that it a burden that only makes us responsible for what we have no
responsibility for, and makes it harder for the end users in the end.
>
>To me, sounds like this postfix issue is the same, the original port 
>file was nice to have, someone put in the time to do it, we are all 
>grateful.  A lot has changed since then, to try to keep that portfile 
>relevant moving forward, means a lot more work for a new maintainer.  
>Postfix's portfile may not be that out of date, so keep this more 
>theoretical in discussion that just about postfix.
>
>What do we do in cases where older ports are part of software that 
>changes rapidly, and a huge duration of time has passed with no port 
>update happening.  To me, if the portfile has not been updated close 
>to the update cycle of the software it builds, in a lot of cases, the 
>only logical thing to do would be to "fork" the port, and start clean.
>
>A lot of these ports are "systems".  It is not like awk, sed, nano, 
>tail etc, where you have one small little binary you are messing 
>with.  These "systems" have a binary, but they sit on top of, or next 
>to, user data, users, groups, permissions, scripts.  In cases like 
>that we need a very committed maintainer, who will stick with it.  
>Otherwise, I fear we end up with what I am doing now, making a local 
>port, not worrying about previous ports, and moving on.  Then I 
>distribute that port off list, off project, and the community does not 
>benefit from it.  That is a huge shame, one I do not like to be a part 
>of, but I also do not want to be a part of breaking every postfix mail 
>server out there based on ports :)
>
I agree that some ports are "systems", and that is why I see if any
dependencies of ports I'm updating are out-of-date when I get ready to
update a port and do it or request a maintainer do so.  But even though
they may be "systems" in some sense, we all knew what we were getting into
with modular software to begin with and I guess it still seems to me you
are thinking about shouldering some burdens that the developers have
chosen not to worry about and I think that won't work in the end.  But
maybe I've misunderstood your point here.

On May 26, 2009, at 3:05 PM, Daniel J. Luke wrote:
>I would encourage you to use 2.6.1 (or whatever the latest current  
>stable release is around when you get time to work on it).

I agree.  And often when people say "create a portxx" because there are
some issues on OS X, it turns out that there are issues because no one
tested the new source (or at least reported bugs to the developer) until
the port was updated to the latest.  This happened with rrdtool 1.2 ->
1.3.  It worked for me (so I updated the port) but others had issues.  But
there were quickly reported to the developer by the mp users and fixed,
whereas had the port been relegated to the port-xx ghetto there is no
telling how long it would have taken to get 1.3 de-bugged on OS X. 

Mark


From raimue at macports.org  Tue May 26 15:41:50 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Wed, 27 May 2009 00:41:50 +0200
Subject: New committers: breskeby, billitch
Message-ID: <4A1C702E.80003@macports.org>

Please join us in welcoming the following new MacPorts committers:

   - Ren? Gr?schke (breskeby)
   - Thomas de Grivel (billitch)

We look forward to continued excellent contributions from these new
team members.

- Bryan, Joshua, Rainer, and Ryan


Do you want to join the MacPorts team? If you would like to be
considered for team membership and commit access, please read this
section of the Guide:

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

From dweber at macports.org  Tue May 26 21:43:34 2009
From: dweber at macports.org (Darren Weber)
Date: Tue, 26 May 2009 21:43:34 -0700
Subject: How to build an xcode project
Message-ID: <b808b3510905262143m7d1bc533gdc37fe206a982d66@mail.gmail.com>

For example,

http://ridiculousfish.com/svn/HexFiend/trunk/

What is the configure and build for an xcode source?  Can this be done
within MacPorts?

Thanks,
Darren

PS, draft Portfile for this HexFiend attached.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090526/e60b11ba/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Portfile
Type: application/octet-stream
Size: 1630 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090526/e60b11ba/attachment.obj>

From blb at macports.org  Tue May 26 22:05:40 2009
From: blb at macports.org (Bryan Blackburn)
Date: Tue, 26 May 2009 23:05:40 -0600
Subject: How to build an xcode project
In-Reply-To: <b808b3510905262143m7d1bc533gdc37fe206a982d66@mail.gmail.com>
References: <b808b3510905262143m7d1bc533gdc37fe206a982d66@mail.gmail.com>
Message-ID: <20090527050540.GL58205@ninagal.withay.com>

On Tue, May 26, 2009 at 09:43:34PM -0700, Darren Weber said:
> For example,
> 
> http://ridiculousfish.com/svn/HexFiend/trunk/
> 
> What is the configure and build for an xcode source?  Can this be done
> within MacPorts?

Try the xcode portgroup, documented at

<http://guide.macports.org/#reference.portgroup.xcode>

Should be quite a few examples in the aqua/ category.

Bryan


> 
> Thanks,
> Darren
> 
> PS, draft Portfile for this HexFiend attached.

From dweber at macports.org  Tue May 26 23:47:58 2009
From: dweber at macports.org (Darren Weber)
Date: Tue, 26 May 2009 23:47:58 -0700
Subject: reinplace - how to escape \. ?
Message-ID: <b808b3510905262347vc4f2961u4c9947d1c447ffe0@mail.gmail.com>

For a regular sed on the following, the last example is what is required:

[ root at X /ports/graphics/InsightToolkit ]# cat tmp.txt
PREFIX/lib/InsightToolkit
"${dir}/../lib/InsightToolkit"
[ root at X /ports/graphics/InsightToolkit ]# cat tmp.txt | sed -e
's|../lib/InsightToolkit|../lib/InsightToolkit-3.12|g'
PREF../lib/InsightToolkit-3.12
"${dir}/../lib/InsightToolkit-3.12"
[ root at X /ports/graphics/InsightToolkit ]# cat tmp.txt | sed -e
's|\.\./lib/InsightToolkit|\.\./lib/InsightToolkit-3.12|g'
PREFIX/lib/InsightToolkit
"${dir}/../lib/InsightToolkit-3.12"

However, when the \. is used in reinplace for a Portfile, e.g.:

reinplace "s|\.\./lib/${name}|\.\./lib/${distname}|g"}
${destroot}${findITKbranch}

The result is the same as the second example above (i.e. PREFIX becomes
PREF..).

I also tried this:

reinplace {"s|[.][.]/lib/${name}|[.][.]/lib/${distname}|g"}
${destroot}${findITKbranch}

That doesn't work.  I don't understand how this is parsed through the tcl
and port parsers.  How would you do it?

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

From dweber at macports.org  Tue May 26 23:49:37 2009
From: dweber at macports.org (Darren Weber)
Date: Tue, 26 May 2009 23:49:37 -0700
Subject: How to build an xcode project
In-Reply-To: <20090527050540.GL58205@ninagal.withay.com>
References: <b808b3510905262143m7d1bc533gdc37fe206a982d66@mail.gmail.com>
	<20090527050540.GL58205@ninagal.withay.com>
Message-ID: <b808b3510905262349s102f234cl219dbff36bc5a9ba@mail.gmail.com>

On Tue, May 26, 2009 at 10:05 PM, Bryan Blackburn <blb at macports.org> wrote:

> On Tue, May 26, 2009 at 09:43:34PM -0700, Darren Weber said:
> > For example,
> >
> > http://ridiculousfish.com/svn/HexFiend/trunk/
> >
> > What is the configure and build for an xcode source?  Can this be done
> > within MacPorts?
>
> Try the xcode portgroup, documented at
>
> <http://guide.macports.org/#reference.portgroup.xcode>
>
> Should be quite a few examples in the aqua/ category.
>
> Bryan
>
>

Yes, the build and install worked without a hitch using "PortGroup xcode
1.0", but the runtime is faulty, i.e.:


Dyld Error Message:
  Library not loaded: @executable_path/../
Frameworks/LuaObjCBridge.framework/Versions/A/LuaObjCBridge
  Referenced from: /Applications/MacPorts/Hex Fiend.app/Contents/MacOS/Hex
Fiend
  Reason: image not found


This is the installation tree:

/Applications/MacPorts/Hex Fiend.app/
/Applications/MacPorts/Hex Fiend.app//Contents
/Applications/MacPorts/Hex Fiend.app//Contents/Info.plist
/Applications/MacPorts/Hex Fiend.app//Contents/MacOS
/Applications/MacPorts/Hex Fiend.app//Contents/MacOS/Hex Fiend
/Applications/MacPorts/Hex Fiend.app//Contents/PkgInfo
/Applications/MacPorts/Hex Fiend.app//Contents/Resources
/Applications/MacPorts/Hex Fiend.app//Contents/Resources/English.lproj
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/Credits.rtfd
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/Credits.rtfd/hex_icon2.png
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/Credits.rtfd/TXT.rtf
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/FindAndReplace.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/FindAndReplace.nib/classes.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/FindAndReplace.nib/info.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/FindAndReplace.nib/keyedobjects.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/InfoPlist.strings
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/MainMenu.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/MainMenu.nib/classes.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/MainMenu.nib/info.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/MainMenu.nib/keyedobjects.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/MyDocument.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/MyDocument.nib/classes.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/MyDocument.nib/info.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/MyDocument.nib/keyedobjects.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/MyDocument.nib/objects.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/OpenPanelAccessoryView.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/OpenPanelAccessoryView.nib/classes.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/OpenPanelAccessoryView.nib/info.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/OpenPanelAccessoryView.nib/keyedobjects.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/SaveProgressBar.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/SaveProgressBar.nib/classes.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/SaveProgressBar.nib/info.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/SaveProgressBar.nib/keyedobjects.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/SuppressibleAlert.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/SuppressibleAlert.nib/classes.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/SuppressibleAlert.nib/info.nib
/Applications/MacPorts/Hex
Fiend.app//Contents/Resources/English.lproj/SuppressibleAlert.nib/keyedobjects.nib
/Applications/MacPorts/Hex Fiend.app//Contents/Resources/hex_icon.icns



Is this a dependency issue, a configuration issue, or some kind of
post-destroot hack required?  The port used only defaults from the xcode
PortGroup.

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

From jeremy at lavergne.gotdns.org  Tue May 26 23:49:29 2009
From: jeremy at lavergne.gotdns.org (Jeremy Lavergne)
Date: Wed, 27 May 2009 02:49:29 -0400
Subject: reinplace - how to escape \. ?
In-Reply-To: <b808b3510905262347vc4f2961u4c9947d1c447ffe0@mail.gmail.com>
References: <b808b3510905262347vc4f2961u4c9947d1c447ffe0@mail.gmail.com>
Message-ID: <5C3B1FDC-3F10-4DB3-A418-D29BC47958DE@lavergne.gotdns.org>

It likely needs a double escape.

Try \\.

Good luck!
On May 27, 2009, at 2:47 AM, Darren Weber wrote:

> That doesn't work.  I don't understand how this is parsed through  
> the tcl and port parsers.  How would you do it?

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

From francis at devrx.org  Wed May 27 09:08:11 2009
From: francis at devrx.org (Francis Devereux)
Date: Wed, 27 May 2009 17:08:11 +0100
Subject: How to build an xcode project
In-Reply-To: <b808b3510905262349s102f234cl219dbff36bc5a9ba@mail.gmail.com>
References: <b808b3510905262143m7d1bc533gdc37fe206a982d66@mail.gmail.com>
	<20090527050540.GL58205@ninagal.withay.com>
	<b808b3510905262349s102f234cl219dbff36bc5a9ba@mail.gmail.com>
Message-ID: <9CBBA07A-1937-485B-82EF-A1F951AF3767@devrx.org>

On 27 May 2009, at 07:49, Darren Weber wrote:

> On Tue, May 26, 2009 at 10:05 PM, Bryan Blackburn <blb at macports.org>  
> wrote:
> On Tue, May 26, 2009 at 09:43:34PM -0700, Darren Weber said:
> > For example,
> >
> > http://ridiculousfish.com/svn/HexFiend/trunk/
> >
> > What is the configure and build for an xcode source?  Can this be  
> done
> > within MacPorts?
>
> Try the xcode portgroup, documented at
>
> <http://guide.macports.org/#reference.portgroup.xcode>
>
> Should be quite a few examples in the aqua/ category.
>
> Bryan
>
>
>
> Yes, the build and install worked without a hitch using "PortGroup  
> xcode 1.0", but the runtime is faulty, i.e.:
>
>
> Dyld Error Message:
>   Library not loaded: @executable_path/../
> Frameworks/LuaObjCBridge.framework/Versions/A/LuaObjCBridge
>   Referenced from: /Applications/MacPorts/Hex Fiend.app/Contents/ 
> MacOS/Hex Fiend
>   Reason: image not found

I get the same error if I build and run Hex Fiend from the Xcode GUI  
(i.e. without using MacPorts), so I think that there is something  
wrong with the Xcode project (or it is incompatible with the versions  
of Xcode we're using - mine is 3.1.2).

Francis

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

From dweber at macports.org  Wed May 27 09:50:36 2009
From: dweber at macports.org (Darren Weber)
Date: Wed, 27 May 2009 09:50:36 -0700
Subject: How to build an xcode project
In-Reply-To: <9CBBA07A-1937-485B-82EF-A1F951AF3767@devrx.org>
References: <b808b3510905262143m7d1bc533gdc37fe206a982d66@mail.gmail.com>
	<20090527050540.GL58205@ninagal.withay.com>
	<b808b3510905262349s102f234cl219dbff36bc5a9ba@mail.gmail.com>
	<9CBBA07A-1937-485B-82EF-A1F951AF3767@devrx.org>
Message-ID: <b808b3510905270950n5906fbf3j370ed465ecc04f61@mail.gmail.com>

On Wed, May 27, 2009 at 9:08 AM, Francis Devereux <francis at devrx.org> wrote:

> On 27 May 2009, at 07:49, Darren Weber wrote:
>
> On Tue, May 26, 2009 at 10:05 PM, Bryan Blackburn <blb at macports.org>wrote:
>
>> On Tue, May 26, 2009 at 09:43:34PM -0700, Darren Weber said:
>> > For example,
>> >
>> > http://ridiculousfish.com/svn/HexFiend/trunk/
>> >
>> > What is the configure and build for an xcode source?  Can this be done
>> > within MacPorts?
>>
>> Try the xcode portgroup, documented at
>>
>> <http://guide.macports.org/#reference.portgroup.xcode>
>>
>> Should be quite a few examples in the aqua/ category.
>>
>> Bryan
>>
>>
>
> Yes, the build and install worked without a hitch using "PortGroup xcode
> 1.0", but the runtime is faulty, i.e.:
>
>
> Dyld Error Message:
>   Library not loaded: @executable_path/../Frameworks/LuaObjCBridge.framework/Versions/A/LuaObjCBridge
>   Referenced from: /Applications/MacPorts/Hex Fiend.app/Contents/MacOS/Hex
> Fiend
>   Reason: image not found
>
>
> I get the same error if I build and run Hex Fiend from the Xcode GUI (i.e.
> without using MacPorts), so I think that there is something wrong with the
> Xcode project (or it is incompatible with the versions of Xcode we're using
> - mine is 3.1.2).
>
> Francis
>
>

I don't see any ports for the Lua-ObjC bridge framework.  Maybe someone with
more experience with xcode builds can resolve the issue, so I have committed
a new Portfile under 'editors/hexfiend/Portfile' in the hope it will
stimulate further work on it.

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

From jmr at macports.org  Wed May 27 10:00:35 2009
From: jmr at macports.org (Joshua Root)
Date: Thu, 28 May 2009 03:00:35 +1000
Subject: How to build an xcode project
In-Reply-To: <b808b3510905270950n5906fbf3j370ed465ecc04f61@mail.gmail.com>
References: <b808b3510905262143m7d1bc533gdc37fe206a982d66@mail.gmail.com>	<20090527050540.GL58205@ninagal.withay.com>	<b808b3510905262349s102f234cl219dbff36bc5a9ba@mail.gmail.com>	<9CBBA07A-1937-485B-82EF-A1F951AF3767@devrx.org>
	<b808b3510905270950n5906fbf3j370ed465ecc04f61@mail.gmail.com>
Message-ID: <4A1D71B3.10602@macports.org>

On 2009-5-28 02:50, Darren Weber wrote:
> I don't see any ports for the Lua-ObjC bridge framework.  Maybe someone
> with more experience with xcode builds can resolve the issue, so I have
> committed a new Portfile under 'editors/hexfiend/Portfile' in the hope
> it will stimulate further work on it.

Does this port work at all? If not, please don't keep it in the main
ports tree. That is just going to frustrate anyone who tries to install
it. You can put works-in-progress in your users/ directory in the svn repo.

- Josh

From ryandesign at macports.org  Wed May 27 10:09:10 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 27 May 2009 12:09:10 -0500
Subject: reinplace - how to escape \. ?
In-Reply-To: <5C3B1FDC-3F10-4DB3-A418-D29BC47958DE@lavergne.gotdns.org>
References: <b808b3510905262347vc4f2961u4c9947d1c447ffe0@mail.gmail.com>
	<5C3B1FDC-3F10-4DB3-A418-D29BC47958DE@lavergne.gotdns.org>
Message-ID: <CC1FFCE6-AF9A-49D7-9FB8-01EF2931B922@macports.org>


On May 27, 2009, at 01:49, Jeremy Lavergne wrote:

> On May 27, 2009, at 2:47 AM, Darren Weber wrote:
>
>> That doesn't work.  I don't understand how this is parsed through  
>> the tcl and port parsers.  How would you do it?
>
> It likely needs a double escape.
>
> Try \\.

Correct. The first backslash escapes from the tcl interpreter. The  
next backslash espaces from the regular expression engine.

reinplace "s|\\.\\./lib/${name}|\\.\\./lib/${distname}|g"} ${destroot} 
${findITKbranch}


If you don't need any variables in your regular expression, you can  
enclose it in {brackets} instead of "quotes" and then you only need a  
single level of escaping. But you are using variables name and  
distname so you need quotes and thus both levels of escaping.



From jwa at macports.org  Wed May 27 10:36:48 2009
From: jwa at macports.org (Jyrki Wahlstedt)
Date: Wed, 27 May 2009 20:36:48 +0300
Subject: PortIndex2MySQL run failure on Sunday 2009-05-24 at 13:15:00
In-Reply-To: <6F51DD5E-D865-45EB-AE72-2654E6C4000D@macports.org>
References: <20090524201508.E47852BE6376@gamma.macosforge.org>
	<20090524203329.GE88633@ninagal.withay.com>
	<0FE7B876-03A6-4F5B-9B6E-7BC02F37E4F4@josephholsten.com>
	<6F51DD5E-D865-45EB-AE72-2654E6C4000D@macports.org>
Message-ID: <0E666FB4-C368-4603-96D5-B1E3B213B298@macports.org>


On 25.5.2009, at 12.19, Ryan Schmidt wrote:

>
> On May 24, 2009, at 16:04, Joseph A Holsten wrote:
>
>> Bryan Blackburn wrote:
>>
>>> So we now have a midgard2-core under devel [1] and one in www [2],
>>> considering r51369 [3] I'm guessing the one in www should be  
>>> deleted?
>>>
>>> [1] - <http://trac.macports.org/log/trunk/dports/devel/midgard2- 
>>> core>
>>> [2] - <http://trac.macports.org/log/trunk/dports/www/midgard2-core>
>>> [3] - <http://trac.macports.org/changeset/51369>
>
> Agreed, I removed the copy in www in r51449.
>
>
>> If that's going to change, www/midgard-{apache2,core,data} probably  
>> need to move too.
>
> The description of each of those ports reads:
>
> "Midgard is a content management system platform using Apache, PHP  
> and MySQL."
>
> The description of midgard2-core reads:
>
> "Midgard is a content repository system platform with bindings in  
> PHP, Python etc."
>
> The commit message for r51369 reads:
>
> "change categories to reflect the changed nature of Midgard2  
> framework from the previous version"
>
> Based on that, I assumed Midgard 1 was properly placed in www, while  
> Midgard 2 now has a larger focus. But I don't know Midgard so I will  
> let the maintainer decide.
>
>
Yes,
you have made quite the correct assumption. Midgard2 is a general  
framework, its correct place is in development, as well as  
corresponding php package belongs to php category. I am very sorry  
about the confusion.

To explain, not to defend, I used svn move to do the transfer. When I  
did the commit, there were some permission issues, and I didn't notice  
that the old ports were not deleted. This goes for midgard2-core and  
php5-midgard2 in www. The latter caused some problems also today, but  
I checked that it at least isn't visible there at the moment.

!
! Jyrki Wahlstedt
!	http://www.wahlstedt.fi/jyrki/
!
! Our life is no dream; but it ought to become one and perhaps will.
! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0  A780  
6366 EFD9 139C C386




From dweber at macports.org  Wed May 27 12:12:29 2009
From: dweber at macports.org (Darren Weber)
Date: Wed, 27 May 2009 12:12:29 -0700
Subject: How to build an xcode project
In-Reply-To: <4A1D71B3.10602@macports.org>
References: <b808b3510905262143m7d1bc533gdc37fe206a982d66@mail.gmail.com>
	<20090527050540.GL58205@ninagal.withay.com>
	<b808b3510905262349s102f234cl219dbff36bc5a9ba@mail.gmail.com>
	<9CBBA07A-1937-485B-82EF-A1F951AF3767@devrx.org>
	<b808b3510905270950n5906fbf3j370ed465ecc04f61@mail.gmail.com>
	<4A1D71B3.10602@macports.org>
Message-ID: <b808b3510905271212u455ffb09ufc53def8f1a8a2dc@mail.gmail.com>

On Wed, May 27, 2009 at 10:00 AM, Joshua Root <jmr at macports.org> wrote:

> On 2009-5-28 02:50, Darren Weber wrote:
> > I don't see any ports for the Lua-ObjC bridge framework.  Maybe someone
> > with more experience with xcode builds can resolve the issue, so I have
> > committed a new Portfile under 'editors/hexfiend/Portfile' in the hope
> > it will stimulate further work on it.
>
> Does this port work at all? If not, please don't keep it in the main
> ports tree. That is just going to frustrate anyone who tries to install
> it. You can put works-in-progress in your users/ directory in the svn repo.



What is the users/ directory in the svn repo?

Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090527/19e36553/attachment.html>

From blb at macports.org  Wed May 27 12:50:15 2009
From: blb at macports.org (Bryan Blackburn)
Date: Wed, 27 May 2009 13:50:15 -0600
Subject: How to build an xcode project
In-Reply-To: <b808b3510905271212u455ffb09ufc53def8f1a8a2dc@mail.gmail.com>
References: <b808b3510905262143m7d1bc533gdc37fe206a982d66@mail.gmail.com>
	<20090527050540.GL58205@ninagal.withay.com>
	<b808b3510905262349s102f234cl219dbff36bc5a9ba@mail.gmail.com>
	<9CBBA07A-1937-485B-82EF-A1F951AF3767@devrx.org>
	<b808b3510905270950n5906fbf3j370ed465ecc04f61@mail.gmail.com>
	<4A1D71B3.10602@macports.org>
	<b808b3510905271212u455ffb09ufc53def8f1a8a2dc@mail.gmail.com>
Message-ID: <20090527195015.GD19192@ninagal.withay.com>

On Wed, May 27, 2009 at 12:12:29PM -0700, Darren Weber said:
> On Wed, May 27, 2009 at 10:00 AM, Joshua Root <jmr at macports.org> wrote:
> 
> > On 2009-5-28 02:50, Darren Weber wrote:
> > > I don't see any ports for the Lua-ObjC bridge framework.  Maybe someone
> > > with more experience with xcode builds can resolve the issue, so I have
> > > committed a new Portfile under 'editors/hexfiend/Portfile' in the hope
> > > it will stimulate further work on it.
> >
> > Does this port work at all? If not, please don't keep it in the main
> > ports tree. That is just going to frustrate anyone who tries to install
> > it. You can put works-in-progress in your users/ directory in the svn repo.
> 
> 
> 
> What is the users/ directory in the svn repo?

It's for any kind of work that doesn't/shouldn't be in trunk, like starting
off with a new port but which doesn't work yet, side projects for MacPorts,
etc.

<http://trac.macports.org/browser/users/>

Just make a dir there with your username and put stuff in there as needed.

Bryan


> 
> Darren

From ryandesign at macports.org  Wed May 27 13:15:44 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Wed, 27 May 2009 15:15:44 -0500
Subject: How to build an xcode project
In-Reply-To: <b808b3510905270950n5906fbf3j370ed465ecc04f61@mail.gmail.com>
References: <b808b3510905262143m7d1bc533gdc37fe206a982d66@mail.gmail.com>
	<20090527050540.GL58205@ninagal.withay.com>
	<b808b3510905262349s102f234cl219dbff36bc5a9ba@mail.gmail.com>
	<9CBBA07A-1937-485B-82EF-A1F951AF3767@devrx.org>
	<b808b3510905270950n5906fbf3j370ed465ecc04f61@mail.gmail.com>
Message-ID: <FD0A434F-B01D-4951-A9A2-B12E9C3B8EBF@macports.org>

On May 27, 2009, at 11:50, Darren Weber wrote:

>> Dyld Error Message:
>>   Library not loaded: @executable_path/../
>> Frameworks/LuaObjCBridge.framework/Versions/A/LuaObjCBridge
>>   Referenced from: /Applications/MacPorts/Hex Fiend.app/Contents/ 
>> MacOS/Hex Fiend
>>   Reason: image not found
>


> I don't see any ports for the Lua-ObjC bridge framework.  Maybe  
> someone with more experience with xcode builds can resolve the  
> issue, so I have committed a new Portfile under 'editors/hexfiend/ 
> Portfile' in the hope it will stimulate further work on it.

Based on the error message, it seems to be looking for a framework  
called LuaObjCBridge.framework to exist inside the Hex Fiend  
application bundle, but the contents you showed earlier does not show  
any such framework. Perhaps there is a separate target in the Xcode  
project that builds this framework. Or maybe you need to ask the  
developers of Hex Fiend how to get this framework built.



From dweber at macports.org  Wed May 27 14:23:29 2009
From: dweber at macports.org (Darren Weber)
Date: Wed, 27 May 2009 14:23:29 -0700
Subject: tcl testing: where is reinplace declared?
Message-ID: <b808b3510905271423k3516c5acycd1b81fecc5c7344@mail.gmail.com>

Following the wiki dev tips, I'm doing this:

rlwrap tclsh8.4
% source /Library/Tcl/macports1.0/macports_fastload.tcl
% package require Pextlib

It doesn't provide the 'reinplace' command.  Also, the following comes up
with nothing:

grep "*reinplace*" /Library/Tcl/macports1.0/*

Where is this little gem and can it be required in tclsh8.4?

Thanks in advance,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090527/ab7a16ba/attachment.html>

From toby at apple.com  Wed May 27 14:29:08 2009
From: toby at apple.com (Toby Peterson)
Date: Wed, 27 May 2009 14:29:08 -0700
Subject: tcl testing: where is reinplace declared?
In-Reply-To: <b808b3510905271423k3516c5acycd1b81fecc5c7344@mail.gmail.com>
References: <b808b3510905271423k3516c5acycd1b81fecc5c7344@mail.gmail.com>
Message-ID: <BE3AFC7E-5938-4F33-8654-8431A22F6F18@apple.com>

On May 27, 2009, at 2:23 PM, Darren Weber wrote:

> Following the wiki dev tips, I'm doing this:
>
> rlwrap tclsh8.4
> % source /Library/Tcl/macports1.0/macports_fastload.tcl
> % package require Pextlib
>
> It doesn't provide the 'reinplace' command.  Also, the following  
> comes up with nothing:
>
> grep "*reinplace*" /Library/Tcl/macports1.0/*
>
> Where is this little gem and can it be required in tclsh8.4?

It's in the 'port' package, normally only available inside Portfiles.  
Also, your grep syntax is bogus... grep != glob

- Toby

From raimue at macports.org  Wed May 27 14:43:57 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Wed, 27 May 2009 23:43:57 +0200
Subject: tcl testing: where is reinplace declared?
In-Reply-To: <b808b3510905271423k3516c5acycd1b81fecc5c7344@mail.gmail.com>
References: <b808b3510905271423k3516c5acycd1b81fecc5c7344@mail.gmail.com>
Message-ID: <4A1DB41D.60409@macports.org>

On 2009-05-27 23:23, Darren Weber wrote:
> 
> Following the wiki dev tips, I'm doing this:
> 
> rlwrap tclsh8.4
> % source /Library/Tcl/macports1.0/macports_fastload.tcl
> % package require Pextlib
> 
> It doesn't provide the 'reinplace' command.  Also, the following comes
> up with nothing:
> 
> grep "*reinplace*" /Library/Tcl/macports1.0/*
> 
> Where is this little gem and can it be required in tclsh8.4?

It is defined in port1.0.

$ rlwrap tclsh
% source /Library/Tcl/macports1.0/macports_fastload.tcl
0
% package require macports 1.0
1.0
% set portarchivemode no
no
% package require port 1.0
1.0
% reinplace
reinplace ?-E? pattern file ...
%

Don't ask me why it looks for a global variable portarchivemode... But
setting it to any value works around the problem.

HTH,
Rainer

From dweber at macports.org  Wed May 27 15:17:48 2009
From: dweber at macports.org (Darren Weber)
Date: Wed, 27 May 2009 15:17:48 -0700
Subject: How to build an xcode project
In-Reply-To: <FD0A434F-B01D-4951-A9A2-B12E9C3B8EBF@macports.org>
References: <b808b3510905262143m7d1bc533gdc37fe206a982d66@mail.gmail.com>
	<20090527050540.GL58205@ninagal.withay.com>
	<b808b3510905262349s102f234cl219dbff36bc5a9ba@mail.gmail.com>
	<9CBBA07A-1937-485B-82EF-A1F951AF3767@devrx.org>
	<b808b3510905270950n5906fbf3j370ed465ecc04f61@mail.gmail.com>
	<FD0A434F-B01D-4951-A9A2-B12E9C3B8EBF@macports.org>
Message-ID: <b808b3510905271517x400e5a7bq5b5f110269ad8350@mail.gmail.com>

On Wed, May 27, 2009 at 1:15 PM, Ryan Schmidt <ryandesign at macports.org>wrote:

> On May 27, 2009, at 11:50, Darren Weber wrote:
>
>  Dyld Error Message:
>>>  Library not loaded: @executable_path/../
>>> Frameworks/LuaObjCBridge.framework/Versions/A/LuaObjCBridge
>>>  Referenced from: /Applications/MacPorts/Hex Fiend.app/Contents/MacOS/Hex
>>> Fiend
>>>  Reason: image not found
>>>
>>
>>
>
>  I don't see any ports for the Lua-ObjC bridge framework.  Maybe someone
>> with more experience with xcode builds can resolve the issue, so I have
>> committed a new Portfile under 'editors/hexfiend/Portfile' in the hope it
>> will stimulate further work on it.
>>
>
> Based on the error message, it seems to be looking for a framework called
> LuaObjCBridge.framework to exist inside the Hex Fiend application bundle,
> but the contents you showed earlier does not show any such framework.
> Perhaps there is a separate target in the Xcode project that builds this
> framework. Or maybe you need to ask the developers of Hex Fiend how to get
> this framework built.
>
>
>
Yes, right.  OK, OK, OK.

It's fixed, with a post-destroot hack to copy the framework into the app
bundle.  Works for me.

Lesson learned - don't create work for someone else.

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

From dweber at macports.org  Wed May 27 15:20:04 2009
From: dweber at macports.org (Darren Weber)
Date: Wed, 27 May 2009 15:20:04 -0700
Subject: How to build an xcode project
In-Reply-To: <20090527195015.GD19192@ninagal.withay.com>
References: <b808b3510905262143m7d1bc533gdc37fe206a982d66@mail.gmail.com>
	<20090527050540.GL58205@ninagal.withay.com>
	<b808b3510905262349s102f234cl219dbff36bc5a9ba@mail.gmail.com>
	<9CBBA07A-1937-485B-82EF-A1F951AF3767@devrx.org>
	<b808b3510905270950n5906fbf3j370ed465ecc04f61@mail.gmail.com>
	<4A1D71B3.10602@macports.org>
	<b808b3510905271212u455ffb09ufc53def8f1a8a2dc@mail.gmail.com>
	<20090527195015.GD19192@ninagal.withay.com>
Message-ID: <b808b3510905271520s33bfe7e9r46159a97c074ca68@mail.gmail.com>

On Wed, May 27, 2009 at 12:50 PM, Bryan Blackburn <blb at macports.org> wrote:

>
> >
> > What is the users/ directory in the svn repo?
>
> It's for any kind of work that doesn't/shouldn't be in trunk, like starting
> off with a new port but which doesn't work yet, side projects for MacPorts,
> etc.
>
> <http://trac.macports.org/browser/users/>
>
> Just make a dir there with your username and put stuff in there as needed.
>
> Bryan
>


What's the svn url?  Tried and failed on:

svn checkout http://svn.macports.org/repository/users/trunk

Thanks, Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090527/41ebdaa6/attachment.html>

From dweber at macports.org  Wed May 27 15:28:15 2009
From: dweber at macports.org (Darren Weber)
Date: Wed, 27 May 2009 15:28:15 -0700
Subject: tcl testing: where is reinplace declared?
In-Reply-To: <4A1DB41D.60409@macports.org>
References: <b808b3510905271423k3516c5acycd1b81fecc5c7344@mail.gmail.com>
	<4A1DB41D.60409@macports.org>
Message-ID: <b808b3510905271528y7fa3b886la3744125d54622f2@mail.gmail.com>

On Wed, May 27, 2009 at 2:43 PM, Rainer M?ller <raimue at macports.org> wrote:

> On 2009-05-27 23:23, Darren Weber wrote:
> >
> > Following the wiki dev tips, I'm doing this:
> >
> > rlwrap tclsh8.4
> > % source /Library/Tcl/macports1.0/macports_fastload.tcl
> > % package require Pextlib
> >
> > It doesn't provide the 'reinplace' command.  Also, the following comes
> > up with nothing:
> >
> > grep "*reinplace*" /Library/Tcl/macports1.0/*
> >
> > Where is this little gem and can it be required in tclsh8.4?
>
> It is defined in port1.0.
>
> $ rlwrap tclsh
> % source /Library/Tcl/macports1.0/macports_fastload.tcl
> 0
> % package require macports 1.0
> 1.0
> % set portarchivemode no
> no
> % package require port 1.0
> 1.0
> % reinplace
> reinplace ?-E? pattern file ...
> %
>
> Don't ask me why it looks for a global variable portarchivemode... But
> setting it to any value works around the problem.
>
> HTH,
> Rainer
>


Very helpful, thanks Rainer!

So ~/bin/macports_testing.tcl now looks like this:

source /Library/Tcl/macports1.0/macports_fastload.tcl
package require macports 1.0
set portarchivemode no
package require port 1.0
package require Pextlib


Then, being sure to use tclsh8.4,

[ dweber at X ~ ]$ rlwrap tclsh8.4
% source /Users/dweber/bin/macports_testing.tcl
1.0
% reinplace
reinplace ?-E? pattern file ...
%


Thanks again,
Darren

PS, I know grep isn't glob ;-)  The grep was a bash command to search all
the macport .tcl files.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090527/e64b4353/attachment-0001.html>

From raimue at macports.org  Wed May 27 15:28:15 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Thu, 28 May 2009 00:28:15 +0200
Subject: How to build an xcode project
In-Reply-To: <b808b3510905271520s33bfe7e9r46159a97c074ca68@mail.gmail.com>
References: <b808b3510905262143m7d1bc533gdc37fe206a982d66@mail.gmail.com>	<20090527050540.GL58205@ninagal.withay.com>	<b808b3510905262349s102f234cl219dbff36bc5a9ba@mail.gmail.com>	<9CBBA07A-1937-485B-82EF-A1F951AF3767@devrx.org>	<b808b3510905270950n5906fbf3j370ed465ecc04f61@mail.gmail.com>	<4A1D71B3.10602@macports.org>	<b808b3510905271212u455ffb09ufc53def8f1a8a2dc@mail.gmail.com>	<20090527195015.GD19192@ninagal.withay.com>
	<b808b3510905271520s33bfe7e9r46159a97c074ca68@mail.gmail.com>
Message-ID: <4A1DBE7F.7040208@macports.org>

On 2009-05-28 00:20, Darren Weber wrote:
> What's the svn url?  Tried and failed on:
> 
> svn checkout http://svn.macports.org/repository/users/trunk

You probably do not really want to checkout the directories of all users
as that would be quite big. Use the Trac Browser to find out the paths
before.

You got the location wrong, the repository root is located at
<https://svn.macosforge.org/repository/macports>

(But svn.macports.org works too).

If you want to create your own users directory, you can do that remotely
without a checkout of all users directories first:

  svn mkdir https://svn.macports.org/repository/macports/users/dweber
  svn co https://svn.macports.org/repository/macports/users/dweber

Rainer

From toby at apple.com  Wed May 27 16:02:05 2009
From: toby at apple.com (Toby Peterson)
Date: Wed, 27 May 2009 16:02:05 -0700
Subject: tcl testing: where is reinplace declared?
In-Reply-To: <b808b3510905271528y7fa3b886la3744125d54622f2@mail.gmail.com>
References: <b808b3510905271423k3516c5acycd1b81fecc5c7344@mail.gmail.com>
	<4A1DB41D.60409@macports.org>
	<b808b3510905271528y7fa3b886la3744125d54622f2@mail.gmail.com>
Message-ID: <6FBAD8C2-9F84-4723-ACE3-5EE5E4C4A2AF@apple.com>

On May 27, 2009, at 3:28 PM, Darren Weber wrote:

> PS, I know grep isn't glob ;-)  The grep was a bash command to  
> search all the macport .tcl files.

Indeed, but "*reinplace*" means it's looking for the literal string  
"*reinplac" followed by 0 or more "e" characters.

- Toby

From dank at kegel.com  Thu May 28 09:51:59 2009
From: dank at kegel.com (Dan Kegel)
Date: Thu, 28 May 2009 09:51:59 -0700
Subject: Valgrind and Darwin
Message-ID: <a71bd89a0905280951v7c626b46m58e6fab27a61fbdc@mail.gmail.com>

On Tue, Nov 25, 2008, Rainer M?ller wrote:
>Greg Parker is working on a patch to bring valgrind to Darwin/Mac OS X.
>
>Check the homepage of the port:
>    http://www.sealiesoftware.com/valgrind/
>    Valgrind for Mac OS X. Some assembly required.
>
>I just wanted to by write a Portfile doing the svn checkouts and
>patching for convenience.
>
>I don't think this is ready for the general public, so I did not create
>a valgrind port in the official ports tree.

According to
http://blog.mozilla.com/nnethercote/2009/05/28/mac-os-x-now-supported-on-the-valgrind-trunk
the port is now in the valgrind trunk.  It may be about ready for
the general public.  We've been using it on Chromium for months
now, and it has found quite a few leaks and other problems.
(Including a bug in the ATI drivers that can crash Desktop Manager...
so until Apple/ATI fix their drivers, we have had to switch to Nvidia
cards on systems that run valgrind.)
- Dan

From dweber at macports.org  Thu May 28 10:39:40 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 28 May 2009 10:39:40 -0700
Subject: CMAKE modules and InsightToolkit
Message-ID: <b808b3510905281039u4c4dd703waea45de495decb89@mail.gmail.com>

See details in ticket
https://trac.macports.org/ticket/19781

Thanks,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090528/07722c99/attachment.html>

From ryandesign at macports.org  Thu May 28 11:04:27 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 28 May 2009 13:04:27 -0500
Subject: [51592] users/dweber
In-Reply-To: <20090528174820.C724F1C90786@beta.macosforge.org>
References: <20090528174820.C724F1C90786@beta.macosforge.org>
Message-ID: <23D2F15B-FE79-4BB4-B3EC-AD8DD4845379@macports.org>


On May 28, 2009, at 12:48, dweber at macports.org wrote:

> Revision: 51592
>           http://trac.macports.org/changeset/51592
> Author:   dweber at macports.org
> Date:     2009-05-28 10:48:20 -0700 (Thu, 28 May 2009)
> Log Message:
> -----------
> copy cmake to try modifications to cmake modules

But you should really do so using "svn copy" so that you have the  
benefit of being able to look at the port's history with "svn blame"  
and "svn log", and so that you can later merge your changes into the  
original port using "svn merge".



From ryandesign at macports.org  Thu May 28 11:24:03 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 28 May 2009 13:24:03 -0500
Subject: [51564] users/dweber
In-Reply-To: <20090527225417.BA3031C7DA9B@beta.macosforge.org>
References: <20090527225417.BA3031C7DA9B@beta.macosforge.org>
Message-ID: <00B8206F-3D2B-4FDA-833C-9234395CDB80@macports.org>


On May 27, 2009, at 17:54, dweber at macports.org wrote:

> Revision: 51564
>           http://trac.macports.org/changeset/51564
> Author:   dweber at macports.org
> Date:     2009-05-27 15:54:16 -0700 (Wed, 27 May 2009)
> Log Message:
> -----------


> Added: users/dweber/tmp/aqua/qt4-mac/Portfile
> ===================================================================
> --- users/dweber/tmp/aqua/qt4-mac/Portfile	                         
> (rev 0)
> +++ users/dweber/tmp/aqua/qt4-mac/Portfile	2009-05-27 22:54:16 UTC  
> (rev 51564)
> @@ -0,0 +1,198 @@
> +# -*- coding: utf-8; mode: tcl; c-basic-offset: 4; indent-tabs- 
> mode: nil; tab-width: 4; truncate-lines: t -*-  
> vim:fenc=utf-8:et:sw=4:ts=4:sts=4
> +# $Id$
> +
> +PortSystem          1.0
> +
> +name                qt4-mac
> +version             4.4.3

[snip]

Making copies of ports in your user directory to play around with is  
great, but it looks like you took very old versions of these ports.  
For example, the qt4-mac is currently at version 4.5.1. Since you did  
not "svn copy" from the original files, but instead committed files  
that are entirely new, we can't tell what version of the official  
ports your versions are based on, nor figure out what changes you've  
made. This will also make it hard for you to contribute any changes  
back to the official portfiles.



From dweber at macports.org  Thu May 28 12:52:10 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 28 May 2009 12:52:10 -0700
Subject: [51564] users/dweber
In-Reply-To: <00B8206F-3D2B-4FDA-833C-9234395CDB80@macports.org>
References: <20090527225417.BA3031C7DA9B@beta.macosforge.org>
	<00B8206F-3D2B-4FDA-833C-9234395CDB80@macports.org>
Message-ID: <b808b3510905281252u4ffe714bua7d22fc00dda716a@mail.gmail.com>

On Thu, May 28, 2009 at 11:24 AM, Ryan Schmidt <ryandesign at macports.org>wrote:

>
> On May 27, 2009, at 17:54, dweber at macports.org wrote:
>
>  Revision: 51564
>>          http://trac.macports.org/changeset/51564
>> Author:   dweber at macports.org
>> Date:     2009-05-27 15:54:16 -0700 (Wed, 27 May 2009)
>> Log Message:
>> -----------
>>
>
>
>  Added: users/dweber/tmp/aqua/qt4-mac/Portfile
>> ===================================================================
>> --- users/dweber/tmp/aqua/qt4-mac/Portfile
>>  (rev 0)
>> +++ users/dweber/tmp/aqua/qt4-mac/Portfile      2009-05-27 22:54:16 UTC
>> (rev 51564)
>> @@ -0,0 +1,198 @@
>> +# -*- coding: utf-8; mode: tcl; c-basic-offset: 4; indent-tabs-mode: nil;
>> tab-width: 4; truncate-lines: t -*- vim:fenc=utf-8:et:sw=4:ts=4:sts=4
>> +# $Id$
>> +
>> +PortSystem          1.0
>> +
>> +name                qt4-mac
>> +version             4.4.3
>>
>
> [snip]
>
> Making copies of ports in your user directory to play around with is great,
> but it looks like you took very old versions of these ports. For example,
> the qt4-mac is currently at version 4.5.1. Since you did not "svn copy" from
> the original files, but instead committed files that are entirely new, we
> can't tell what version of the official ports your versions are based on,
> nor figure out what changes you've made. This will also make it hard for you
> to contribute any changes back to the official portfiles.
>
>
>

All good points, thanks.  I was not aware of the user svn facility until a
few days ago.  I've been working on various things for several months, in a
local repository.  I didn't want to lose any of those files, so they were
all added to my user svn yesterday.  Many of those local repo files, like
the qt4-mac and postgresql ports, are certainly outdated.

I've had a nagging thought in the back of my mind about merging changes into
the macports-trunk, so I do need education on how to do that from my user
svn.  Is this stuff covered in the developers section of the wiki?  I don't
recall reading it before.  I was working on the basis of the local
repository information at:

I think it would help to have more information about this svn user facility
and how to use it at:
*https://trac.macports.org/wiki/CommittersTipsAndTricks
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090528/1f560991/attachment.html>

From dweber at macports.org  Thu May 28 12:53:55 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 28 May 2009 12:53:55 -0700
Subject: tcl testing: where is reinplace declared?
In-Reply-To: <b808b3510905271528y7fa3b886la3744125d54622f2@mail.gmail.com>
References: <b808b3510905271423k3516c5acycd1b81fecc5c7344@mail.gmail.com>
	<4A1DB41D.60409@macports.org>
	<b808b3510905271528y7fa3b886la3744125d54622f2@mail.gmail.com>
Message-ID: <b808b3510905281253rbbe2f56hddd3f5462be9fcdd@mail.gmail.com>

Updated the wiki with this useful tip.  See:
https://trac.macports.org/wiki/CommittersTipsAndTricks


On Wed, May 27, 2009 at 3:28 PM, Darren Weber <dweber at macports.org> wrote:

>
>
> On Wed, May 27, 2009 at 2:43 PM, Rainer M?ller <raimue at macports.org>wrote:
>
>> On 2009-05-27 23:23, Darren Weber wrote:
>> >
>> > Following the wiki dev tips, I'm doing this:
>> >
>> > rlwrap tclsh8.4
>> > % source /Library/Tcl/macports1.0/macports_fastload.tcl
>> > % package require Pextlib
>> >
>> > It doesn't provide the 'reinplace' command.  Also, the following comes
>> > up with nothing:
>> >
>> > grep "*reinplace*" /Library/Tcl/macports1.0/*
>> >
>> > Where is this little gem and can it be required in tclsh8.4?
>>
>> It is defined in port1.0.
>>
>> $ rlwrap tclsh
>> % source /Library/Tcl/macports1.0/macports_fastload.tcl
>> 0
>> % package require macports 1.0
>> 1.0
>> % set portarchivemode no
>> no
>> % package require port 1.0
>> 1.0
>> % reinplace
>> reinplace ?-E? pattern file ...
>> %
>>
>> Don't ask me why it looks for a global variable portarchivemode... But
>> setting it to any value works around the problem.
>>
>> HTH,
>> Rainer
>>
>
>
> Very helpful, thanks Rainer!
>
> So ~/bin/macports_testing.tcl now looks like this:
>
> source /Library/Tcl/macports1.0/macports_fastload.tcl
> package require macports 1.0
> set portarchivemode no
> package require port 1.0
> package require Pextlib
>
>
> Then, being sure to use tclsh8.4,
>
> [ dweber at X ~ ]$ rlwrap tclsh8.4
> % source /Users/dweber/bin/macports_testing.tcl
> 1.0
> % reinplace
> reinplace ?-E? pattern file ...
> %
>
>
> Thanks again,
> Darren
>
> PS, I know grep isn't glob ;-)  The grep was a bash command to search all
> the macport .tcl files.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090528/94dbf284/attachment-0001.html>

From dweber at macports.org  Thu May 28 13:21:30 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 28 May 2009 13:21:30 -0700
Subject: [51564] users/dweber
In-Reply-To: <b808b3510905281252u4ffe714bua7d22fc00dda716a@mail.gmail.com>
References: <20090527225417.BA3031C7DA9B@beta.macosforge.org>
	<00B8206F-3D2B-4FDA-833C-9234395CDB80@macports.org>
	<b808b3510905281252u4ffe714bua7d22fc00dda716a@mail.gmail.com>
Message-ID: <b808b3510905281321h531e564em4b2f5a51858dceab@mail.gmail.com>

On Thu, May 28, 2009 at 12:52 PM, Darren Weber <dweber at macports.org> wrote:

>
>
> On Thu, May 28, 2009 at 11:24 AM, Ryan Schmidt <ryandesign at macports.org>wrote:
>
>>
>> On May 27, 2009, at 17:54, dweber at macports.org wrote:
>>
>>  Revision: 51564
>>>          http://trac.macports.org/changeset/51564
>>> Author:   dweber at macports.org
>>> Date:     2009-05-27 15:54:16 -0700 (Wed, 27 May 2009)
>>> Log Message:
>>> -----------
>>>
>>
>>
>>  Added: users/dweber/tmp/aqua/qt4-mac/Portfile
>>> ===================================================================
>>> --- users/dweber/tmp/aqua/qt4-mac/Portfile
>>>  (rev 0)
>>> +++ users/dweber/tmp/aqua/qt4-mac/Portfile      2009-05-27 22:54:16 UTC
>>> (rev 51564)
>>> @@ -0,0 +1,198 @@
>>> +# -*- coding: utf-8; mode: tcl; c-basic-offset: 4; indent-tabs-mode:
>>> nil; tab-width: 4; truncate-lines: t -*- vim:fenc=utf-8:et:sw=4:ts=4:sts=4
>>> +# $Id$
>>> +
>>> +PortSystem          1.0
>>> +
>>> +name                qt4-mac
>>> +version             4.4.3
>>>
>>
>> [snip]
>>
>> Making copies of ports in your user directory to play around with is
>> great, but it looks like you took very old versions of these ports. For
>> example, the qt4-mac is currently at version 4.5.1. Since you did not "svn
>> copy" from the original files, but instead committed files that are entirely
>> new, we can't tell what version of the official ports your versions are
>> based on, nor figure out what changes you've made. This will also make it
>> hard for you to contribute any changes back to the official portfiles.
>>
>>
>>
>
> All good points, thanks.  I was not aware of the user svn facility until a
> few days ago.  I've been working on various things for several months, in a
> local repository.  I didn't want to lose any of those files, so they were
> all added to my user svn yesterday.  Many of those local repo files, like
> the qt4-mac and postgresql ports, are certainly outdated.
>
> I've had a nagging thought in the back of my mind about merging changes
> into the macports-trunk, so I do need education on how to do that from my
> user svn.  Is this stuff covered in the developers section of the wiki?  I
> don't recall reading it before.  I was working on the basis of the local
> repository information at:
>
> I think it would help to have more information about this svn user facility
> and how to use it at:
> *https://trac.macports.org/wiki/CommittersTipsAndTricks
> *
>


I went ahead and started the additional notes, see the new section and add
more details as required:
https://trac.macports.org/wiki/CommittersTipsAndTricks

Seems like a good place to note this, but maybe it could be elsewhere or
linked from elsewhere too.

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

From dweber at macports.org  Thu May 28 13:23:54 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 28 May 2009 13:23:54 -0700
Subject: How to build an xcode project
In-Reply-To: <4A1DBE7F.7040208@macports.org>
References: <b808b3510905262143m7d1bc533gdc37fe206a982d66@mail.gmail.com>
	<20090527050540.GL58205@ninagal.withay.com>
	<b808b3510905262349s102f234cl219dbff36bc5a9ba@mail.gmail.com>
	<9CBBA07A-1937-485B-82EF-A1F951AF3767@devrx.org>
	<b808b3510905270950n5906fbf3j370ed465ecc04f61@mail.gmail.com>
	<4A1D71B3.10602@macports.org>
	<b808b3510905271212u455ffb09ufc53def8f1a8a2dc@mail.gmail.com>
	<20090527195015.GD19192@ninagal.withay.com>
	<b808b3510905271520s33bfe7e9r46159a97c074ca68@mail.gmail.com>
	<4A1DBE7F.7040208@macports.org>
Message-ID: <b808b3510905281323ta7fb231s1a3c76fadc5c9152@mail.gmail.com>

On Wed, May 27, 2009 at 3:28 PM, Rainer M?ller <raimue at macports.org> wrote:

> On 2009-05-28 00:20, Darren Weber wrote:
> > What's the svn url?  Tried and failed on:
> >
> > svn checkout http://svn.macports.org/repository/users/trunk
>
> You probably do not really want to checkout the directories of all users
> as that would be quite big. Use the Trac Browser to find out the paths
> before.
>
> You got the location wrong, the repository root is located at
> <https://svn.macosforge.org/repository/macports>
>
> (But svn.macports.org works too).
>
> If you want to create your own users directory, you can do that remotely
> without a checkout of all users directories first:
>
>  svn mkdir https://svn.macports.org/repository/macports/users/dweber
>  svn co https://svn.macports.org/repository/macports/users/dweber
>
> Rainer
>


Added these valuable tips to the wiki at:
https://trac.macports.org/wiki/CommittersTipsAndTricks

Please review and add more details on how to commit and merge changes back
to the trunk.

This seems like a good place to note this, but maybe it could be elsewhere
or linked from elsewhere too.

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

From dweber at macports.org  Thu May 28 15:00:07 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 28 May 2009 15:00:07 -0700
Subject: how to merge my users svn Portfile into macports trunk?
Message-ID: <b808b3510905281500u5ed1c862vd9a7117171cfce70@mail.gmail.com>

The file in ~/myports/graphics/InsightToolkit/Portfile is now in the user
svn at:
https://svn.macosforge.org/repository/macports/users/dweber/graphics/InsightToolkit/Portfile

This file is now ready to be merged into the main trunk at:
https://svn.macosforge.org/repository/macports/trunk/dports/graphics/InsightToolkit/Portfile

What is the right way to do this, using svn?

Thanks in advance,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090528/e93c9c35/attachment.html>

From ryandesign at macports.org  Thu May 28 15:35:07 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Thu, 28 May 2009 17:35:07 -0500
Subject: [51564] users/dweber
In-Reply-To: <b808b3510905281252u4ffe714bua7d22fc00dda716a@mail.gmail.com>
References: <20090527225417.BA3031C7DA9B@beta.macosforge.org>
	<00B8206F-3D2B-4FDA-833C-9234395CDB80@macports.org>
	<b808b3510905281252u4ffe714bua7d22fc00dda716a@mail.gmail.com>
Message-ID: <B2AD473C-16C6-49E5-A84B-8BD7C5823A87@macports.org>


On May 28, 2009, at 14:52, Darren Weber wrote:

> All good points, thanks.  I was not aware of the user svn facility  
> until a few days ago.  I've been working on various things for  
> several months, in a local repository.  I didn't want to lose any  
> of those files, so they were all added to my user svn yesterday.   
> Many of those local repo files, like the qt4-mac and postgresql  
> ports, are certainly outdated.

I figured that's probably how this came about. And there wouldn't  
have been an automated way to have it now retroactively figure out  
what revisions of each port you had based your changes on and make  
"svn cp"ies of them correctly now. It would have been an involved  
manual process.


> I've had a nagging thought in the back of my mind about merging  
> changes into the macports-trunk, so I do need education on how to  
> do that from my user svn.  Is this stuff covered in the developers  
> section of the wiki?  I don't recall reading it before.  I was  
> working on the basis of the local repository information at:

I don't think that's covered. How to use Subversion for merging  
changes is best learned by reading the Subversion book:

http://svnbook.org/



From dweber at macports.org  Thu May 28 15:44:11 2009
From: dweber at macports.org (Darren Weber)
Date: Thu, 28 May 2009 15:44:11 -0700
Subject: [51564] users/dweber
In-Reply-To: <B2AD473C-16C6-49E5-A84B-8BD7C5823A87@macports.org>
References: <20090527225417.BA3031C7DA9B@beta.macosforge.org>
	<00B8206F-3D2B-4FDA-833C-9234395CDB80@macports.org>
	<b808b3510905281252u4ffe714bua7d22fc00dda716a@mail.gmail.com>
	<B2AD473C-16C6-49E5-A84B-8BD7C5823A87@macports.org>
Message-ID: <b808b3510905281544x20232eaahdfd991e3b1a33119@mail.gmail.com>

On Thu, May 28, 2009 at 3:35 PM, Ryan Schmidt <ryandesign at macports.org>wrote:

>
> On May 28, 2009, at 14:52, Darren Weber wrote:
>
>  All good points, thanks.  I was not aware of the user svn facility until a
>> few days ago.  I've been working on various things for several months, in a
>> local repository.  I didn't want to lose any of those files, so they were
>> all added to my user svn yesterday.  Many of those local repo files, like
>> the qt4-mac and postgresql ports, are certainly outdated.
>>
>
> I figured that's probably how this came about. And there wouldn't have been
> an automated way to have it now retroactively figure out what revisions of
> each port you had based your changes on and make "svn cp"ies of them
> correctly now. It would have been an involved manual process.
>

I did manage my local ports repo with cvs on my local machine.  It might be
possible to track back to the initial version of the file in my cvs and find
a match for it in the macports trunk.  Extra work, are the benefits worth
it?  When I thought the local repo versions were doing what I wanted, I did
submit some trac tickets, so maybe the changes were adopted (maybe not).   I
don't recall the ticket numbers, but they could be found easily enough.
I've gotta get back to real work, I've done way too much on vtk and
InsightToolkit in the last few months.  Hopefully, I'm now set to develop
some useful things based on that foundation.  I may come back to the other
port modifications (like postgresql, qt4-mac), if necessary.



>
>
>
>  I've had a nagging thought in the back of my mind about merging changes
>> into the macports-trunk, so I do need education on how to do that from my
>> user svn.  Is this stuff covered in the developers section of the wiki?  I
>> don't recall reading it before.  I was working on the basis of the local
>> repository information at:
>>
>
> I don't think that's covered. How to use Subversion for merging changes is
> best learned by reading the Subversion book:
>
> http://svnbook.org/
>
>
>
OK.

Thanks,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090528/40298d9b/attachment-0001.html>

From toby at apple.com  Fri May 29 02:05:14 2009
From: toby at apple.com (Toby Peterson)
Date: Fri, 29 May 2009 02:05:14 -0700
Subject: how to merge my users svn Portfile into macports trunk?
In-Reply-To: <b808b3510905281500u5ed1c862vd9a7117171cfce70@mail.gmail.com>
References: <b808b3510905281500u5ed1c862vd9a7117171cfce70@mail.gmail.com>
Message-ID: <3D120679-598A-4EDA-ADF7-F4C2D820B87D@apple.com>

On May 28, 2009, at 3:00 PM, Darren Weber wrote:

> The file in ~/myports/graphics/InsightToolkit/Portfile is now in the  
> user svn at:
> https://svn.macosforge.org/repository/macports/users/dweber/graphics/InsightToolkit/Portfile
>
> This file is now ready to be merged into the main trunk at:
> https://svn.macosforge.org/repository/macports/trunk/dports/graphics/InsightToolkit/Portfile
>
> What is the right way to do this, using svn?

Please see `svn merge --help`. You most likely want the third usage  
case.

- Toby

From ryandesign at macports.org  Fri May 29 10:00:07 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 29 May 2009 12:00:07 -0500
Subject: [51564] users/dweber
In-Reply-To: <b808b3510905281544x20232eaahdfd991e3b1a33119@mail.gmail.com>
References: <20090527225417.BA3031C7DA9B@beta.macosforge.org>
	<00B8206F-3D2B-4FDA-833C-9234395CDB80@macports.org>
	<b808b3510905281252u4ffe714bua7d22fc00dda716a@mail.gmail.com>
	<B2AD473C-16C6-49E5-A84B-8BD7C5823A87@macports.org>
	<b808b3510905281544x20232eaahdfd991e3b1a33119@mail.gmail.com>
Message-ID: <8CE9865A-E695-497A-B2A0-FC96AE46D94C@macports.org>


On May 28, 2009, at 17:44, Darren Weber wrote:

> I did manage my local ports repo with cvs on my local machine.  It  
> might be possible to track back to the initial version of the file  
> in my cvs and find a match for it in the macports trunk.  Extra  
> work, are the benefits worth it?  When I thought the local repo  
> versions were doing what I wanted, I did submit some trac tickets,  
> so maybe the changes were adopted (maybe not).   I don't recall the  
> ticket numbers, but they could be found easily enough.  I've gotta  
> get back to real work, I've done way too much on vtk and  
> InsightToolkit in the last few months.  Hopefully, I'm now set to  
> develop some useful things based on that foundation.  I may come  
> back to the other port modifications (like postgresql, qt4-mac), if  
> necessary.

My concern was just if you plan to contribute your changes back to  
the maintainer to be incorporated into the official portfile, what  
mechanism will you use to provide a diff of your changes? Since you  
have not used "svn copy" you can't use "svn diff" to do it for you  
and will have to either manually compare the official port and yours  
and risk missing a change, or figure out what version of the official  
port you based your changes on and do diff. But the whitespace  
changes you've also been committing to your local copies will make  
that less useful than it might otherwise be.



From talklists at newgeo.com  Fri May 29 11:34:57 2009
From: talklists at newgeo.com (Scott Haneda)
Date: Fri, 29 May 2009 11:34:57 -0700
Subject: Building imaptest and a port
Message-ID: <16E04D98-E7AB-4C3E-B4EE-C41F86C3CB60@newgeo.com>

Hello, I want to make a portfile for IMAP test.
http://www.imapwiki.org/ImapTest/Installation

I built it by hand, but ran into some problems, hopefully I can get  
some pointers here.

In my .bashrc I have
export CLICOLOR=1

When I try to build this I get
$./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... configure: error: ls -t  
appears to fail.  Make sure there is not a broken
alias in your environment
configure: error: newly created file is older than distributed files!
Check your system clock

If I remove the CLICOLOR variable, it will build fine.  Since I have  
had MacPorts build so many things, and never had this issue, I was  
hoping someone here can explain to me how to make sure MacPorts does  
not get hung on this issue.

The man page for `ls`, as far as I can see, is not explaining how the  
CLICOLOR could affect the output of `ls`. ( Aside from coloring it of  
course )

Second, as per the install notes, imaptest also needs library  
functions for dovecot, but does not need make install, libs just need  
to be there.  There is already a Dovecot port, but that will install  
the entire package.  In this case, do I make a new Dovecot port that  
skips the make install part, or do I wrap this all into one?

Third, when a distro points to name-latest.tar.gz, am I to pick a  
version or just always stick with the latest, which is a moving  
target? I can not even guarantee that in that download path the older  
versions stick around much, it looks like they roll them out every now  
and then.

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


From dluke at geeklair.net  Fri May 29 11:52:25 2009
From: dluke at geeklair.net (Daniel J. Luke)
Date: Fri, 29 May 2009 14:52:25 -0400
Subject: Building imaptest and a port
In-Reply-To: <16E04D98-E7AB-4C3E-B4EE-C41F86C3CB60@newgeo.com>
References: <16E04D98-E7AB-4C3E-B4EE-C41F86C3CB60@newgeo.com>
Message-ID: <2915DD98-AF61-407F-BE3C-F095F9AF9420@geeklair.net>

On May 29, 2009, at 2:34 PM, Scott Haneda wrote:
> If I remove the CLICOLOR variable, it will build fine.  Since I have  
> had MacPorts build so many things, and never had this issue, I was  
> hoping someone here can explain to me how to make sure MacPorts does  
> not get hung on this issue.


Macports does some cleaning of environment variables before building  
software.

It's easy enough to build a Portfile that I don't usually try to build  
things by hand first and then make a Portfile (and instead just start  
out building up the Portfile).

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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090529/2264daff/attachment.bin>

From ryandesign at macports.org  Fri May 29 12:46:54 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 29 May 2009 14:46:54 -0500
Subject: Building imaptest and a port
In-Reply-To: <16E04D98-E7AB-4C3E-B4EE-C41F86C3CB60@newgeo.com>
References: <16E04D98-E7AB-4C3E-B4EE-C41F86C3CB60@newgeo.com>
Message-ID: <333C1EA4-ED81-4C56-BC07-F4EB0608BC78@macports.org>


On May 29, 2009, at 13:34, Scott Haneda wrote:

> Hello, I want to make a portfile for IMAP test.
> http://www.imapwiki.org/ImapTest/Installation
>
> I built it by hand, but ran into some problems, hopefully I can get  
> some pointers here.
>
> In my .bashrc I have
> export CLICOLOR=1
>
> When I try to build this I get
> $./configure
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... configure: error: ls - 
> t appears to fail.  Make sure there is not a broken
> alias in your environment
> configure: error: newly created file is older than distributed files!
> Check your system clock
>
> If I remove the CLICOLOR variable, it will build fine.  Since I  
> have had MacPorts build so many things, and never had this issue, I  
> was hoping someone here can explain to me how to make sure MacPorts  
> does not get hung on this issue.
>
> The man page for `ls`, as far as I can see, is not explaining how  
> the CLICOLOR could affect the output of `ls`. ( Aside from coloring  
> it of course )

Since MacPorts clears the environment, this should not be a problem  
when building within MacPorts.


> Second, as per the install notes, imaptest also needs library  
> functions for dovecot, but does not need make install, libs just  
> need to be there.  There is already a Dovecot port, but that will  
> install the entire package.  In this case, do I make a new Dovecot  
> port that skips the make install part, or do I wrap this all into one?

If you don't "make install" then nothing would be installed, right?  
So that wouldn't help anything. You'd have a port that spends a lot  
of time building things in the work directory, then doesn't install  
them, then cleans up the work directory.


> Third, when a distro points to name-latest.tar.gz, am I to pick a  
> version or just always stick with the latest, which is a moving  
> target? I can not even guarantee that in that download path the  
> older versions stick around much, it looks like they roll them out  
> every now and then.

You should not use a distfile name like name-latest.tar.gz precisely  
because it might be something different later and someone would then  
get a checksum error. So, if offered, you should use a distfile name  
that contains the version number.

In the case of dovecot-latest.tar.gz, it looks like that's not the  
latest stable, but the latest nightly snapshot. Ports should be for  
the latest stable version. If you need to make a port for a  
development version, usually that's done by naming the port with the  
"-devel" suffix (e.g. graphviz-devel, pango-devel, cairo-devel, glib2- 
devel, etc.) I see the problem in this case is that dovecot 1.1.15 is  
the latest stable released version but imaptest needs dovecot 1.2  
which is currently in release candidate 4 status. Maybe 1.2 final  
will be released soon and the dovecot port can be updated to that  
version and there is no problem. If you need dovecot 1.2 immediately,  
then you could make a dovecot-devel port for version 1.2rc4  
downloaded from

http://dovecot.org/releases/1.2/rc/

You should coordinate any such effort with the maintainer of dovecot.




From dweber at macports.org  Fri May 29 12:51:12 2009
From: dweber at macports.org (Darren Weber)
Date: Fri, 29 May 2009 12:51:12 -0700
Subject: how to merge my users svn Portfile into macports trunk?
In-Reply-To: <3D120679-598A-4EDA-ADF7-F4C2D820B87D@apple.com>
References: <b808b3510905281500u5ed1c862vd9a7117171cfce70@mail.gmail.com>
	<3D120679-598A-4EDA-ADF7-F4C2D820B87D@apple.com>
Message-ID: <b808b3510905291251w57cad6dcu717e774234122171@mail.gmail.com>

On Fri, May 29, 2009 at 2:05 AM, Toby Peterson <toby at apple.com> wrote:

> On May 28, 2009, at 3:00 PM, Darren Weber wrote:
>
>  The file in ~/myports/graphics/InsightToolkit/Portfile is now in the user
>> svn at:
>>
>> https://svn.macosforge.org/repository/macports/users/dweber/graphics/InsightToolkit/Portfile
>>
>> This file is now ready to be merged into the main trunk at:
>>
>> https://svn.macosforge.org/repository/macports/trunk/dports/graphics/InsightToolkit/Portfile
>>
>> What is the right way to do this, using svn?
>>
>
> Please see `svn merge --help`. You most likely want the third usage case.
>
> - Toby
>


Please forgive my ignorance of svn (I am in the process of R'ing TFM).  I've
used cvs more than svn (but that is changing fast).  For now, I want to get
this right, so I would appreciate some advice on the best practice to run a
merge or update on two versions of InsightToolkit, i.e.:

https://svn.macosforge.org/repository/macports/trunk/dports/graphics/InsightToolkit/Portfile

https://svn.macosforge.org/repository/macports/users/dweber/graphics/InsightToolkit/Portfile

The latter revision 3 of the port has been modified and tested within my
'user' svn repository.  It's now ready for the trunk.  What is the best way
to do this, so that svn will migrate the revision comments that were made in
my user repository over to the trunk?

When I was using a local repository, following the guide info (
http://guide.macports.org/#development.local-repositories), I would do the
following in the bash shell:

$ cp ~/myports/graphics/InsightToolkit/Portfile \
     ~/macports-trunk/dports/graphics/InsightToolkit/Portfile
$ cd ~/macports-trunk/dports/graphics/InsightToolkit/
$ svn commit -m "..." Portfile

However, now that ~/myports is part of the macports svn tree, there must be
a better way to do this with svn.  So, what about this:

$ svn merge ~/myports/graphics/InsightToolkit/Portfile \
     ~/macports-trunk/dports/graphics/InsightToolkit/Portfile \
     -m "merge port rev 3 into the trunk"

Will this merge all the revision comments from both development trees, i.e.:

[ dweber at X ~ ]$ svn log ~/myports/graphics/InsightToolkit/Portfile
------------------------------------------------------------------------
r51603 | dweber at macports.org | 2009-05-28 19:52:43 -0700 (Thu, 28 May 2009)
| 2 lines

-m "ensure post-destroot and any other hacks do not depend on the port name,
so the port can be renamed; created $itkName to serve as a global variable
to identify the conventional library name for ITK"

------------------------------------------------------------------------
r51600 | dweber at macports.org | 2009-05-28 13:39:54 -0700 (Thu, 28 May 2009)
| 2 lines

removing hack for FindITK.cmake after making that change in my copy of cmake
in my user svn

------------------------------------------------------------------------
r51573 | dweber at macports.org | 2009-05-27 17:37:29 -0700 (Wed, 27 May 2009)
| 2 lines

post-destroot hacks for FindITK.cmake

------------------------------------------------------------------------
r51562 | dweber at macports.org | 2009-05-27 15:49:47 -0700 (Wed, 27 May 2009)
| 2 lines



------------------------------------------------------------------------
[ dweber at X ~ ]$ svn log
~/macports-trunk/dports/graphics/InsightToolkit/Portfile
------------------------------------------------------------------------
r51478 | dweber at macports.org | 2009-05-25 22:51:35 -0700 (Mon, 25 May 2009)
| 2 lines

many bug fixes for wrapping, works for python25 and itkwish is working

------------------------------------------------------------------------
r51322 | dweber at macports.org | 2009-05-22 17:40:21 -0700 (Fri, 22 May 2009)
| 2 lines

Revision 1; adding tweaks for the examples and testing variants; the
wrapping seems to work now - at least for python

------------------------------------------------------------------------
r50785 | ryandesign at macports.org | 2009-05-09 02:53:31 -0700 (Sat, 09 May
2009) | 2 lines

InsightToolkit, vtk-devel: Fix typo in comment

------------------------------------------------------------------------
r50784 | ryandesign at macports.org | 2009-05-09 02:47:01 -0700 (Sat, 09 May
2009) | 2 lines

InsightToolkit: correct typos in long description and comments

------------------------------------------------------------------------
r50759 | dweber at macports.org | 2009-05-08 15:29:45 -0700 (Fri, 08 May 2009)
| 2 lines

updated version; trying to add new variants for wrapping, etc.

------------------------------------------------------------------------
r50757 | dweber at macports.org | 2009-05-08 15:28:30 -0700 (Fri, 08 May 2009)
| 2 lines

Move InsightToolkit to graphics, where VTK is already, as this is primarily
an image processing library

------------------------------------------------------------------------
r34064 | ryandesign at macports.org | 2008-02-11 11:55:24 -0800 (Mon, 11 Feb
2008) | 2 lines

InsightToolkit: new port! See #13932

------------------------------------------------------------------------


As an svn novice, the following is a bit confusing:

$ svn diff ~/myports/graphics/InsightToolkit/Portfile
~/macports-trunk/dports/graphics/InsightToolkit/Portfile
$
$ colordiff ~/myports/graphics/InsightToolkit/Portfile
~/macports-trunk/dports/graphics/InsightToolkit/Portfile
2c2
< # $Id: Portfile 51603 2009-05-29 02:52:43Z dweber at macports.org $
---
> # $Id: Portfile 51478 2009-05-26 05:51:35Z dweber at macports.org $
8c8
< revision        3
---
> revision        2
53,54c53
< # The parallel build would be nice, but it's not reliable.
< #use_parallel_build  yes
---
> use_parallel_build  yes
.
.
.


Thanks in advance,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090529/76ada15f/attachment-0001.html>

From dweber at macports.org  Fri May 29 13:00:37 2009
From: dweber at macports.org (Darren Weber)
Date: Fri, 29 May 2009 13:00:37 -0700
Subject: how to merge my users svn Portfile into macports trunk?
In-Reply-To: <b808b3510905291251w57cad6dcu717e774234122171@mail.gmail.com>
References: <b808b3510905281500u5ed1c862vd9a7117171cfce70@mail.gmail.com>
	<3D120679-598A-4EDA-ADF7-F4C2D820B87D@apple.com>
	<b808b3510905291251w57cad6dcu717e774234122171@mail.gmail.com>
Message-ID: <b808b3510905291300v52b6a2a5mb7ec43a2ead4a743@mail.gmail.com>

On Fri, May 29, 2009 at 12:51 PM, Darren Weber <dweber at macports.org> wrote:

>
>
> On Fri, May 29, 2009 at 2:05 AM, Toby Peterson <toby at apple.com> wrote:
>
>> On May 28, 2009, at 3:00 PM, Darren Weber wrote:
>>
>>  The file in ~/myports/graphics/InsightToolkit/Portfile is now in the user
>>> svn at:
>>>
>>> https://svn.macosforge.org/repository/macports/users/dweber/graphics/InsightToolkit/Portfile
>>>
>>> This file is now ready to be merged into the main trunk at:
>>>
>>> https://svn.macosforge.org/repository/macports/trunk/dports/graphics/InsightToolkit/Portfile
>>>
>>> What is the right way to do this, using svn?
>>>
>>
>> Please see `svn merge --help`. You most likely want the third usage case.
>>
>> - Toby
>>
>
>
> Please forgive my ignorance of svn (I am in the process of R'ing TFM).
> I've used cvs more than svn (but that is changing fast).  For now, I want to
> get this right, so I would appreciate some advice on the best practice to
> run a merge or update on two versions of InsightToolkit, i.e.:
>
>
> https://svn.macosforge.org/repository/macports/trunk/dports/graphics/InsightToolkit/Portfile
>
>
> https://svn.macosforge.org/repository/macports/users/dweber/graphics/InsightToolkit/Portfile
>
> The latter revision 3 of the port has been modified and tested within my
> 'user' svn repository.  It's now ready for the trunk.  What is the best way
> to do this, so that svn will migrate the revision comments that were made in
> my user repository over to the trunk?
>
> When I was using a local repository, following the guide info (
> http://guide.macports.org/#development.local-repositories), I would do the
> following in the bash shell:
>
> $ cp ~/myports/graphics/InsightToolkit/Portfile \
>      ~/macports-trunk/dports/graphics/InsightToolkit/Portfile
> $ cd ~/macports-trunk/dports/graphics/InsightToolkit/
> $ svn commit -m "..." Portfile
>
> However, now that ~/myports is part of the macports svn tree, there must be
> a better way to do this with svn.  So, what about this:
>
> $ svn merge ~/myports/graphics/InsightToolkit/Portfile \
>      ~/macports-trunk/dports/graphics/InsightToolkit/Portfile \
>      -m "merge port rev 3 into the trunk"
>
> Will this merge all the revision comments from both development trees,
> i.e.:
>
> [ dweber at X ~ ]$ svn log ~/myports/graphics/InsightToolkit/Portfile
> ------------------------------------------------------------------------
> r51603 | dweber at macports.org | 2009-05-28 19:52:43 -0700 (Thu, 28 May
> 2009) | 2 lines
>
> -m "ensure post-destroot and any other hacks do not depend on the port
> name, so the port can be renamed; created $itkName to serve as a global
> variable to identify the conventional library name for ITK"
>
> ------------------------------------------------------------------------
> r51600 | dweber at macports.org | 2009-05-28 13:39:54 -0700 (Thu, 28 May
> 2009) | 2 lines
>
> removing hack for FindITK.cmake after making that change in my copy of
> cmake in my user svn
>
> ------------------------------------------------------------------------
> r51573 | dweber at macports.org | 2009-05-27 17:37:29 -0700 (Wed, 27 May
> 2009) | 2 lines
>
> post-destroot hacks for FindITK.cmake
>
> ------------------------------------------------------------------------
> r51562 | dweber at macports.org | 2009-05-27 15:49:47 -0700 (Wed, 27 May
> 2009) | 2 lines
>
>
>
> ------------------------------------------------------------------------
> [ dweber at X ~ ]$ svn log
> ~/macports-trunk/dports/graphics/InsightToolkit/Portfile
> ------------------------------------------------------------------------
> r51478 | dweber at macports.org | 2009-05-25 22:51:35 -0700 (Mon, 25 May
> 2009) | 2 lines
>
> many bug fixes for wrapping, works for python25 and itkwish is working
>
> ------------------------------------------------------------------------
> r51322 | dweber at macports.org | 2009-05-22 17:40:21 -0700 (Fri, 22 May
> 2009) | 2 lines
>
> Revision 1; adding tweaks for the examples and testing variants; the
> wrapping seems to work now - at least for python
>
> ------------------------------------------------------------------------
> r50785 | ryandesign at macports.org | 2009-05-09 02:53:31 -0700 (Sat, 09 May
> 2009) | 2 lines
>
> InsightToolkit, vtk-devel: Fix typo in comment
>
> ------------------------------------------------------------------------
> r50784 | ryandesign at macports.org | 2009-05-09 02:47:01 -0700 (Sat, 09 May
> 2009) | 2 lines
>
> InsightToolkit: correct typos in long description and comments
>
> ------------------------------------------------------------------------
> r50759 | dweber at macports.org | 2009-05-08 15:29:45 -0700 (Fri, 08 May
> 2009) | 2 lines
>
> updated version; trying to add new variants for wrapping, etc.
>
> ------------------------------------------------------------------------
> r50757 | dweber at macports.org | 2009-05-08 15:28:30 -0700 (Fri, 08 May
> 2009) | 2 lines
>
> Move InsightToolkit to graphics, where VTK is already, as this is primarily
> an image processing library
>
> ------------------------------------------------------------------------
> r34064 | ryandesign at macports.org | 2008-02-11 11:55:24 -0800 (Mon, 11 Feb
> 2008) | 2 lines
>
> InsightToolkit: new port! See #13932
>
> ------------------------------------------------------------------------
>
>
> As an svn novice, the following is a bit confusing:
>
> $ svn diff ~/myports/graphics/InsightToolkit/Portfile
> ~/macports-trunk/dports/graphics/InsightToolkit/Portfile
> $
> $ colordiff ~/myports/graphics/InsightToolkit/Portfile
> ~/macports-trunk/dports/graphics/InsightToolkit/Portfile
> 2c2
> < # $Id: Portfile 51603 2009-05-29 02:52:43Z dweber at macports.org $
> ---
> > # $Id: Portfile 51478 2009-05-26 05:51:35Z dweber at macports.org $
> 8c8
> < revision        3
> ---
> > revision        2
> 53,54c53
> < # The parallel build would be nice, but it's not reliable.
> < #use_parallel_build  yes
> ---
> > use_parallel_build  yes
> .
> .
> .
>
>
> Thanks in advance,
> Darren
>
>

Looks like I did not use svn copy to start working on this port:

$ svn log -v ~/myports/graphics/InsightToolkit/Portfile
------------------------------------------------------------------------
r51603 | dweber at macports.org | 2009-05-28 19:52:43 -0700 (Thu, 28 May 2009)
| 2 lines
Changed paths:
   M /users/dweber/graphics/InsightToolkit/Portfile

-m "ensure post-destroot and any other hacks do not depend on the port name,
so the port can be renamed; created $itkName to serve as a global variable
to identify the conventional library name for ITK"

------------------------------------------------------------------------
r51600 | dweber at macports.org | 2009-05-28 13:39:54 -0700 (Thu, 28 May 2009)
| 2 lines
Changed paths:
   M /users/dweber/graphics/InsightToolkit/Portfile

removing hack for FindITK.cmake after making that change in my copy of cmake
in my user svn

------------------------------------------------------------------------
r51573 | dweber at macports.org | 2009-05-27 17:37:29 -0700 (Wed, 27 May 2009)
| 2 lines
Changed paths:
   M /users/dweber/graphics/InsightToolkit/Portfile

post-destroot hacks for FindITK.cmake

------------------------------------------------------------------------
r51562 | dweber at macports.org | 2009-05-27 15:49:47 -0700 (Wed, 27 May 2009)
| 2 lines
Changed paths:
   A /users/dweber/graphics
   A /users/dweber/graphics/InsightToolkit
   A /users/dweber/graphics/InsightToolkit/Portfile
   A /users/dweber/graphics/paraview
   A /users/dweber/graphics/paraview/Portfile
   A /users/dweber/graphics/vtk-devel
   A /users/dweber/graphics/vtk-devel/Portfile



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

From talklists at newgeo.com  Fri May 29 13:10:28 2009
From: talklists at newgeo.com (Scott Haneda)
Date: Fri, 29 May 2009 13:10:28 -0700
Subject: Building imaptest and a port
In-Reply-To: <333C1EA4-ED81-4C56-BC07-F4EB0608BC78@macports.org>
References: <16E04D98-E7AB-4C3E-B4EE-C41F86C3CB60@newgeo.com>
	<333C1EA4-ED81-4C56-BC07-F4EB0608BC78@macports.org>
Message-ID: <265076F6-D5BC-4973-9CCF-AA4A5DF8DD5F@newgeo.com>

On May 29, 2009, at 12:46 PM, Ryan Schmidt wrote:

> On May 29, 2009, at 13:34, Scott Haneda wrote:
>
>> Second, as per the install notes, imaptest also needs library  
>> functions for dovecot, but does not need make install, libs just  
>> need to be there.  There is already a Dovecot port, but that will  
>> install the entire package.  In this case, do I make a new Dovecot  
>> port that skips the make install part, or do I wrap this all into  
>> one?
>
> If you don't "make install" then nothing would be installed, right?  
> So that wouldn't help anything. You'd have a port that spends a lot  
> of time building things in the work directory, then doesn't install  
> them, then cleans up the work directory.

Well, I would take what I needed.  `make install` is going to actually  
install dovecot, which I wold not want to do, I just need some  
libraries.

Here is what I want to do, though I think I will need advising on the  
best way:
	download a known stable of dovecot
	run configure
	run make
	download imaptest
	run configure with ./configure --with-dovecot=../path to above sources
	run make
	copy src/imaptest to an appropriate location in MacPorts
	clean whatever I need to

This is what I did to test it locally and use it.

>> Third, when a distro points to name-latest.tar.gz, am I to pick a  
>> version or just always stick with the latest, which is a moving  
>> target? I can not even guarantee that in that download path the  
>> older versions stick around much, it looks like they roll them out  
>> every now and then.
>
> You should not use a distfile name like name-latest.tar.gz precisely  
> because it might be something different later and someone would then  
> get a checksum error. So, if offered, you should use a distfile name  
> that contains the version number.

Ok, I will pick the latest version.

> In the case of dovecot-latest.tar.gz, it looks like that's not the  
> latest stable, but the latest nightly snapshot. Ports should be for  
> the latest stable version. If you need to make a port for a  
> development version, usually that's done by naming the port with the  
> "-devel" suffix (e.g. graphviz-devel, pango-devel, cairo-devel,  
> glib2-devel, etc.)

Ok, I can call this one devel, no problem.

> I see the problem in this case is that dovecot 1.1.15 is the latest  
> stable released version but imaptest needs dovecot 1.2 which is  
> currently in release candidate 4 status. Maybe 1.2 final will be  
> released soon and the dovecot port can be updated to that version  
> and there is no problem. If you need dovecot 1.2 immediately, then  
> you could make a dovecot-devel port for version 1.2rc4 downloaded from

I am fine with the devel idea, Dovecot is only needed in this case to  
get to some libs that imaptest needs.  I am just not sure, since this  
is to clear separate installs, but at the smae time, they completely  
play off each other in this case.

I need a little hand holding on this one, as I am not sure how to best  
do these, as two ports, or one, and if one, if it is even possible to  
download and build two items in the same port.

I am also not entirely clear from the docs on how to alter configure  
to remove the install path, which I do not need, and how to skip make  
install.  I think I can figure out the xinstall stuff, to move the  
files where I need to when done, or I guess just the one binary.

Actually, there is a helpful imap mbox file that is allowed to be  
downloaded as a test file.  If I wanted to add that into this install,  
where is the best place to put that file, and how do I start the  
download of that within a port?

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


From dweber at macports.org  Fri May 29 13:20:40 2009
From: dweber at macports.org (Darren Weber)
Date: Fri, 29 May 2009 13:20:40 -0700
Subject: how to merge my users svn Portfile into macports trunk?
In-Reply-To: <b808b3510905291300v52b6a2a5mb7ec43a2ead4a743@mail.gmail.com>
References: <b808b3510905281500u5ed1c862vd9a7117171cfce70@mail.gmail.com>
	<3D120679-598A-4EDA-ADF7-F4C2D820B87D@apple.com>
	<b808b3510905291251w57cad6dcu717e774234122171@mail.gmail.com>
	<b808b3510905291300v52b6a2a5mb7ec43a2ead4a743@mail.gmail.com>
Message-ID: <b808b3510905291320h9541437i1cd7ce5f07a728d8@mail.gmail.com>

On Fri, May 29, 2009 at 1:00 PM, Darren Weber <dweber at macports.org> wrote:

>
>
> On Fri, May 29, 2009 at 12:51 PM, Darren Weber <dweber at macports.org>wrote:
>
>>
>>
>> On Fri, May 29, 2009 at 2:05 AM, Toby Peterson <toby at apple.com> wrote:
>>
>>> On May 28, 2009, at 3:00 PM, Darren Weber wrote:
>>>
>>>  The file in ~/myports/graphics/InsightToolkit/Portfile is now in the
>>>> user svn at:
>>>>
>>>> https://svn.macosforge.org/repository/macports/users/dweber/graphics/InsightToolkit/Portfile
>>>>
>>>> This file is now ready to be merged into the main trunk at:
>>>>
>>>> https://svn.macosforge.org/repository/macports/trunk/dports/graphics/InsightToolkit/Portfile
>>>>
>>>> What is the right way to do this, using svn?
>>>>
>>>
>>> Please see `svn merge --help`. You most likely want the third usage case.
>>>
>>> - Toby
>>>
>>
>>
>> Please forgive my ignorance of svn (I am in the process of R'ing TFM).
>> I've used cvs more than svn (but that is changing fast).  For now, I want to
>> get this right, so I would appreciate some advice on the best practice to
>> run a merge or update on two versions of InsightToolkit, i.e.:
>>
>>
>> https://svn.macosforge.org/repository/macports/trunk/dports/graphics/InsightToolkit/Portfile
>>
>>
>> https://svn.macosforge.org/repository/macports/users/dweber/graphics/InsightToolkit/Portfile
>>
>> The latter revision 3 of the port has been modified and tested within my
>> 'user' svn repository.  It's now ready for the trunk.  What is the best way
>> to do this, so that svn will migrate the revision comments that were made in
>> my user repository over to the trunk?
>>
>> When I was using a local repository, following the guide info (
>> http://guide.macports.org/#development.local-repositories), I would do
>> the following in the bash shell:
>>
>> $ cp ~/myports/graphics/InsightToolkit/Portfile \
>>      ~/macports-trunk/dports/graphics/InsightToolkit/Portfile
>> $ cd ~/macports-trunk/dports/graphics/InsightToolkit/
>> $ svn commit -m "..." Portfile
>>
>> However, now that ~/myports is part of the macports svn tree, there must
>> be a better way to do this with svn.  So, what about this:
>>
>> $ svn merge ~/myports/graphics/InsightToolkit/Portfile \
>>      ~/macports-trunk/dports/graphics/InsightToolkit/Portfile \
>>      -m "merge port rev 3 into the trunk"
>>
>> Will this merge all the revision comments from both development trees,
>> i.e.:
>>
>> [ dweber at X ~ ]$ svn log ~/myports/graphics/InsightToolkit/Portfile
>> ------------------------------------------------------------------------
>> r51603 | dweber at macports.org | 2009-05-28 19:52:43 -0700 (Thu, 28 May
>> 2009) | 2 lines
>>
>> -m "ensure post-destroot and any other hacks do not depend on the port
>> name, so the port can be renamed; created $itkName to serve as a global
>> variable to identify the conventional library name for ITK"
>>
>> ------------------------------------------------------------------------
>> r51600 | dweber at macports.org | 2009-05-28 13:39:54 -0700 (Thu, 28 May
>> 2009) | 2 lines
>>
>> removing hack for FindITK.cmake after making that change in my copy of
>> cmake in my user svn
>>
>> ------------------------------------------------------------------------
>> r51573 | dweber at macports.org | 2009-05-27 17:37:29 -0700 (Wed, 27 May
>> 2009) | 2 lines
>>
>> post-destroot hacks for FindITK.cmake
>>
>> ------------------------------------------------------------------------
>> r51562 | dweber at macports.org | 2009-05-27 15:49:47 -0700 (Wed, 27 May
>> 2009) | 2 lines
>>
>>
>>
>> ------------------------------------------------------------------------
>> [ dweber at X ~ ]$ svn log
>> ~/macports-trunk/dports/graphics/InsightToolkit/Portfile
>> ------------------------------------------------------------------------
>> r51478 | dweber at macports.org | 2009-05-25 22:51:35 -0700 (Mon, 25 May
>> 2009) | 2 lines
>>
>> many bug fixes for wrapping, works for python25 and itkwish is working
>>
>> ------------------------------------------------------------------------
>> r51322 | dweber at macports.org | 2009-05-22 17:40:21 -0700 (Fri, 22 May
>> 2009) | 2 lines
>>
>> Revision 1; adding tweaks for the examples and testing variants; the
>> wrapping seems to work now - at least for python
>>
>> ------------------------------------------------------------------------
>> r50785 | ryandesign at macports.org | 2009-05-09 02:53:31 -0700 (Sat, 09 May
>> 2009) | 2 lines
>>
>> InsightToolkit, vtk-devel: Fix typo in comment
>>
>> ------------------------------------------------------------------------
>> r50784 | ryandesign at macports.org | 2009-05-09 02:47:01 -0700 (Sat, 09 May
>> 2009) | 2 lines
>>
>> InsightToolkit: correct typos in long description and comments
>>
>> ------------------------------------------------------------------------
>> r50759 | dweber at macports.org | 2009-05-08 15:29:45 -0700 (Fri, 08 May
>> 2009) | 2 lines
>>
>> updated version; trying to add new variants for wrapping, etc.
>>
>> ------------------------------------------------------------------------
>> r50757 | dweber at macports.org | 2009-05-08 15:28:30 -0700 (Fri, 08 May
>> 2009) | 2 lines
>>
>> Move InsightToolkit to graphics, where VTK is already, as this is
>> primarily an image processing library
>>
>> ------------------------------------------------------------------------
>> r34064 | ryandesign at macports.org | 2008-02-11 11:55:24 -0800 (Mon, 11 Feb
>> 2008) | 2 lines
>>
>> InsightToolkit: new port! See #13932
>>
>> ------------------------------------------------------------------------
>>
>>
>> As an svn novice, the following is a bit confusing:
>>
>> $ svn diff ~/myports/graphics/InsightToolkit/Portfile
>> ~/macports-trunk/dports/graphics/InsightToolkit/Portfile
>> $
>> $ colordiff ~/myports/graphics/InsightToolkit/Portfile
>> ~/macports-trunk/dports/graphics/InsightToolkit/Portfile
>> 2c2
>> < # $Id: Portfile 51603 2009-05-29 02:52:43Z dweber at macports.org $
>> ---
>> > # $Id: Portfile 51478 2009-05-26 05:51:35Z dweber at macports.org $
>> 8c8
>> < revision        3
>> ---
>> > revision        2
>> 53,54c53
>> < # The parallel build would be nice, but it's not reliable.
>> < #use_parallel_build  yes
>> ---
>> > use_parallel_build  yes
>> .
>> .
>> .
>>
>>
>> Thanks in advance,
>> Darren
>>
>>
>
> Looks like I did not use svn copy to start working on this port:
>
> $ svn log -v ~/myports/graphics/InsightToolkit/Portfile
> ------------------------------------------------------------------------
> r51603 | dweber at macports.org | 2009-05-28 19:52:43 -0700 (Thu, 28 May
> 2009) | 2 lines
> Changed paths:
>    M /users/dweber/graphics/InsightToolkit/Portfile
>
> -m "ensure post-destroot and any other hacks do not depend on the port
> name, so the port can be renamed; created $itkName to serve as a global
> variable to identify the conventional library name for ITK"
>
> ------------------------------------------------------------------------
> r51600 | dweber at macports.org | 2009-05-28 13:39:54 -0700 (Thu, 28 May
> 2009) | 2 lines
> Changed paths:
>    M /users/dweber/graphics/InsightToolkit/Portfile
>
> removing hack for FindITK.cmake after making that change in my copy of
> cmake in my user svn
>
> ------------------------------------------------------------------------
> r51573 | dweber at macports.org | 2009-05-27 17:37:29 -0700 (Wed, 27 May
> 2009) | 2 lines
> Changed paths:
>    M /users/dweber/graphics/InsightToolkit/Portfile
>
> post-destroot hacks for FindITK.cmake
>
> ------------------------------------------------------------------------
> r51562 | dweber at macports.org | 2009-05-27 15:49:47 -0700 (Wed, 27 May
> 2009) | 2 lines
> Changed paths:
>    A /users/dweber/graphics
>    A /users/dweber/graphics/InsightToolkit
>    A /users/dweber/graphics/InsightToolkit/Portfile
>    A /users/dweber/graphics/paraview
>    A /users/dweber/graphics/paraview/Portfile
>    A /users/dweber/graphics/vtk-devel
>    A /users/dweber/graphics/vtk-devel/Portfile
>
>
>
> ------------------------------------------------------------------------
>
>
>

Tried the following:

$ svn merge \

https://svn.macosforge.org/repository/macports/users/dweber/graphics/InsightToolkit/Portfile\

https://svn.macosforge.org/repository/macports/trunk/dports/graphics/InsightToolkit/Portfile\
  macports-trunk/dports/graphics/InsightToolkit/Portfile
--- Merging differences between repository URLs into
'macports-trunk/dports/graphics/InsightToolkit/Portfile':
   C macports-trunk/dports/graphics/InsightToolkit/Portfile
svn: Attempt to add tree conflict that already exists
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090529/89142b4c/attachment-0001.html>

From ryandesign at macports.org  Fri May 29 14:01:27 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Fri, 29 May 2009 16:01:27 -0500
Subject: Building imaptest and a port
In-Reply-To: <265076F6-D5BC-4973-9CCF-AA4A5DF8DD5F@newgeo.com>
References: <16E04D98-E7AB-4C3E-B4EE-C41F86C3CB60@newgeo.com>
	<333C1EA4-ED81-4C56-BC07-F4EB0608BC78@macports.org>
	<265076F6-D5BC-4973-9CCF-AA4A5DF8DD5F@newgeo.com>
Message-ID: <FBE56EB0-216B-47E1-B8D6-6E09501CC5DB@macports.org>

On May 29, 2009, at 15:10, Scott Haneda wrote:

> On May 29, 2009, at 12:46 PM, Ryan Schmidt wrote:
>
>> On May 29, 2009, at 13:34, Scott Haneda wrote:
>>
>>> Second, as per the install notes, imaptest also needs library  
>>> functions for dovecot, but does not need make install, libs just  
>>> need to be there.  There is already a Dovecot port, but that will  
>>> install the entire package.  In this case, do I make a new  
>>> Dovecot port that skips the make install part, or do I wrap this  
>>> all into one?
>>
>> If you don't "make install" then nothing would be installed,  
>> right? So that wouldn't help anything. You'd have a port that  
>> spends a lot of time building things in the work directory, then  
>> doesn't install them, then cleans up the work directory.
>
> Well, I would take what I needed.  `make install` is going to  
> actually install dovecot, which I wold not want to do, I just need  
> some libraries.
>
> Here is what I want to do, though I think I will need advising on  
> the best way:
> 	download a known stable of dovecot
> 	run configure
> 	run make
> 	download imaptest
> 	run configure with ./configure --with-dovecot=../path to above  
> sources
> 	run make
> 	copy src/imaptest to an appropriate location in MacPorts
> 	clean whatever I need to
>
> This is what I did to test it locally and use it.
>
>>> Third, when a distro points to name-latest.tar.gz, am I to pick a  
>>> version or just always stick with the latest, which is a moving  
>>> target? I can not even guarantee that in that download path the  
>>> older versions stick around much, it looks like they roll them  
>>> out every now and then.
>>
>> You should not use a distfile name like name-latest.tar.gz  
>> precisely because it might be something different later and  
>> someone would then get a checksum error. So, if offered, you  
>> should use a distfile name that contains the version number.
>
> Ok, I will pick the latest version.
>
>> In the case of dovecot-latest.tar.gz, it looks like that's not the  
>> latest stable, but the latest nightly snapshot. Ports should be  
>> for the latest stable version. If you need to make a port for a  
>> development version, usually that's done by naming the port with  
>> the "-devel" suffix (e.g. graphviz-devel, pango-devel, cairo- 
>> devel, glib2-devel, etc.)
>
> Ok, I can call this one devel, no problem.
>
>> I see the problem in this case is that dovecot 1.1.15 is the  
>> latest stable released version but imaptest needs dovecot 1.2  
>> which is currently in release candidate 4 status. Maybe 1.2 final  
>> will be released soon and the dovecot port can be updated to that  
>> version and there is no problem. If you need dovecot 1.2  
>> immediately, then you could make a dovecot-devel port for version  
>> 1.2rc4 downloaded from
>
> I am fine with the devel idea, Dovecot is only needed in this case  
> to get to some libs that imaptest needs.  I am just not sure, since  
> this is to clear separate installs, but at the smae time, they  
> completely play off each other in this case.
>
> I need a little hand holding on this one, as I am not sure how to  
> best do these, as two ports, or one, and if one, if it is even  
> possible to download and build two items in the same port.
>
> I am also not entirely clear from the docs on how to alter  
> configure to remove the install path, which I do not need, and how  
> to skip make install.  I think I can figure out the xinstall stuff,  
> to move the files where I need to when done, or I guess just the  
> one binary.

I think the reasonable options that exist are:

1. Use the libraries that were installed by the dovecot (or dovecot- 
devel) port. I recommend this method, unless there's some strong  
reason I don't know about why installing dovecot would be detrimental  
to something.
2. Within the imaptest port, also download and build dovecot, and  
then use those libraries.


> Actually, there is a helpful imap mbox file that is allowed to be  
> downloaded as a test file.  If I wanted to add that into this  
> install, where is the best place to put that file, and how do I  
> start the download of that within a port?


Perhaps some place under ${prefix}/share/${name} would be a good  
place for the file.

Add any additional files you want downloaded to the distfiles  
variable. MacPorts will download it for you.

If the additional file needs to be downloaded from a different place  
than the main distfile, you need to add a second master_sites value  
and put tags on both master_sites and distfiles values to tell  
MacPorts which file to download from which site.

If the mbox file is not compressed and thus MacPorts should not try  
to decompress it, define extract.only to contain only those items you  
want MacPorts to decompress.

Example:

master_sites \
http://dovecot.org/nightly/imaptest/:main \
http://dir/where/mbox/is/:mbox

set main_distfile [suffix ${distname}]
set mbox_distfile test.mbox

distfiles \
${main_distfile}:main \
${mbox_distfile}:mbox

checksums \
${main_distfile} \
md5 ... \
sha1 ... \
rmd160 ... \
${mbox_distfile} \
md5 ... \
sha1 ... \
rmd160 ...

extract.only ${main_distfile}



From dweber at macports.org  Fri May 29 15:11:16 2009
From: dweber at macports.org (Darren Weber)
Date: Fri, 29 May 2009 15:11:16 -0700
Subject: reinplace - how to remove a new line char
Message-ID: <b808b3510905291511i490990ch853da965756d96a3@mail.gmail.com>

An example of how to remove a line with some search text in it.  Assume
tmp.txt contains:

# BEGIN (not in file)
abc
def
# END (not in file)

reinplace {$!N;s|^.*abc.*\\n||g} tmp.txt

If you need to include variables -- escape, escape, escape!

set abcVar abc
reinplace "\$!N;s|^.*${abcVar}.*\\n||g"

The result should be:

# BEGIN (not in file)
def
# END (not in file)


Regards,
Darren

PS, Thanks to google refs for some relevant sed tips, e.g.:
http://www.computing.net/answers/unix/remove-all-n-in-sed/7399.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20090529/fc8c2d15/attachment.html>

From blb at macports.org  Fri May 29 17:24:21 2009
From: blb at macports.org (Bryan Blackburn)
Date: Fri, 29 May 2009 18:24:21 -0600
Subject: how to merge my users svn Portfile into macports trunk?
In-Reply-To: <b808b3510905291320h9541437i1cd7ce5f07a728d8@mail.gmail.com>
References: <b808b3510905281500u5ed1c862vd9a7117171cfce70@mail.gmail.com>
	<3D120679-598A-4EDA-ADF7-F4C2D820B87D@apple.com>
	<b808b3510905291251w57cad6dcu717e774234122171@mail.gmail.com>
	<b808b3510905291300v52b6a2a5mb7ec43a2ead4a743@mail.gmail.com>
	<b808b3510905291320h9541437i1cd7ce5f07a728d8@mail.gmail.com>
Message-ID: <20090530002421.GF68902@ninagal.withay.com>

On Fri, May 29, 2009 at 01:20:40PM -0700, Darren Weber said:
[...]
> 
> Tried the following:
> 
> $ svn merge \
> 
> https://svn.macosforge.org/repository/macports/users/dweber/graphics/InsightToolkit/Portfile\
> 
> https://svn.macosforge.org/repository/macports/trunk/dports/graphics/InsightToolkit/Portfile\
>   macports-trunk/dports/graphics/InsightToolkit/Portfile
> --- Merging differences between repository URLs into
> 'macports-trunk/dports/graphics/InsightToolkit/Portfile':
>    C macports-trunk/dports/graphics/InsightToolkit/Portfile
> svn: Attempt to add tree conflict that already exists

Don't merge from remote to remote, you want to be sitting in the checkout
for your merge-to target (.../trunk/dports/graphics/InsightToolkit in this
case) and merge from where you've been doing your work.  So something like

$ cd /path/to/macports/checkout/trunk/dports/graphics/InsightToolkit
$ svn merge http://svn.macports.org/repository/macports/users/dweber/graphics/InsightToolkit

The reason for doing it like this is so that you can review changes before
committing, and if there are any conflicts you will have to resolve those
prior to comitting.

Bryan


From blair at orcaware.com  Fri May 29 17:32:03 2009
From: blair at orcaware.com (Blair Zajac)
Date: Fri, 29 May 2009 17:32:03 -0700
Subject: how to merge my users svn Portfile into macports trunk?
In-Reply-To: <20090530002421.GF68902@ninagal.withay.com>
References: <b808b3510905281500u5ed1c862vd9a7117171cfce70@mail.gmail.com>	<3D120679-598A-4EDA-ADF7-F4C2D820B87D@apple.com>	<b808b3510905291251w57cad6dcu717e774234122171@mail.gmail.com>	<b808b3510905291300v52b6a2a5mb7ec43a2ead4a743@mail.gmail.com>	<b808b3510905291320h9541437i1cd7ce5f07a728d8@mail.gmail.com>
	<20090530002421.GF68902@ninagal.withay.com>
Message-ID: <4A207E83.20606@orcaware.com>

Bryan Blackburn wrote:
> On Fri, May 29, 2009 at 01:20:40PM -0700, Darren Weber said:
> [...]
>> Tried the following:
>>
>> $ svn merge \
>>
>> https://svn.macosforge.org/repository/macports/users/dweber/graphics/InsightToolkit/Portfile\
>>
>> https://svn.macosforge.org/repository/macports/trunk/dports/graphics/InsightToolkit/Portfile\
>>   macports-trunk/dports/graphics/InsightToolkit/Portfile
>> --- Merging differences between repository URLs into
>> 'macports-trunk/dports/graphics/InsightToolkit/Portfile':
>>    C macports-trunk/dports/graphics/InsightToolkit/Portfile
>> svn: Attempt to add tree conflict that already exists
> 
> Don't merge from remote to remote, you want to be sitting in the checkout
> for your merge-to target (.../trunk/dports/graphics/InsightToolkit in this
> case) and merge from where you've been doing your work.  So something like
> 
> $ cd /path/to/macports/checkout/trunk/dports/graphics/InsightToolkit
> $ svn merge http://svn.macports.org/repository/macports/users/dweber/graphics/InsightToolkit
> 
> The reason for doing it like this is so that you can review changes before
> committing, and if there are any conflicts you will have to resolve those
> prior to comitting.

Just to be pedantic, one can never merge directly into the repository using 
Subversion, one always needs to merge into a working copy and then commit from 
there.  There is no "merge into the repos" operation in svn.

Blair


From akitada at macports.org  Fri May 29 23:03:14 2009
From: akitada at macports.org (Akira Kitada)
Date: Sat, 30 May 2009 15:03:14 +0900
Subject: DVCS for MacPorts Project?
Message-ID: <90bb445a0905292303j1f0915c8pa743eca8fcec414e@mail.gmail.com>

Hi,

Is there any plan to change trac.macports.org backend to DVCS?

Regards

From toby at macports.org  Fri May 29 23:07:29 2009
From: toby at macports.org (Toby Peterson)
Date: Fri, 29 May 2009 23:07:29 -0700
Subject: DVCS for MacPorts Project?
In-Reply-To: <90bb445a0905292303j1f0915c8pa743eca8fcec414e@mail.gmail.com>
References: <90bb445a0905292303j1f0915c8pa743eca8fcec414e@mail.gmail.com>
Message-ID: <74c219d30905292307p940bc4fxea693451a25511be@mail.gmail.com>

On Fri, May 29, 2009 at 23:03, Akira Kitada <akitada at macports.org> wrote:
> Is there any plan to change trac.macports.org backend to DVCS?

No.

From blair at orcaware.com  Fri May 29 23:12:32 2009
From: blair at orcaware.com (Blair Zajac)
Date: Fri, 29 May 2009 23:12:32 -0700
Subject: DVCS for MacPorts Project?
In-Reply-To: <74c219d30905292307p940bc4fxea693451a25511be@mail.gmail.com>
References: <90bb445a0905292303j1f0915c8pa743eca8fcec414e@mail.gmail.com>
	<74c219d30905292307p940bc4fxea693451a25511be@mail.gmail.com>
Message-ID: <4A20CE50.2010401@orcaware.com>

Toby Peterson wrote:
> On Fri, May 29, 2009 at 23:03, Akira Kitada <akitada at macports.org> wrote:
>> Is there any plan to change trac.macports.org backend to DVCS?
> 
> No.

One can always check out from the svn repository using git svn, which works 
nicely (except it commits the $Id$ properties using an expanded value).

Regards,
Blair

From ryandesign at macports.org  Sat May 30 01:57:58 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sat, 30 May 2009 03:57:58 -0500
Subject: DVCS for MacPorts Project?
In-Reply-To: <4A20CE50.2010401@orcaware.com>
References: <90bb445a0905292303j1f0915c8pa743eca8fcec414e@mail.gmail.com>
	<74c219d30905292307p940bc4fxea693451a25511be@mail.gmail.com>
	<4A20CE50.2010401@orcaware.com>
Message-ID: <95FD7CAA-1427-40CD-9D49-CD2F2FE41F2E@macports.org>

On May 30, 2009, at 01:12, Blair Zajac wrote:

> Toby Peterson wrote:
>> On Fri, May 29, 2009 at 23:03, Akira Kitada <akitada at macports.org>  
>> wrote:
>>> Is there any plan to change trac.macports.org backend to DVCS?
>> No.
>
> One can always check out from the svn repository using git svn,  
> which works nicely (except it commits the $Id$ properties using an  
> expanded value).

Is there already a bug report with the developers for that problem?


From raimue at macports.org  Sat May 30 05:45:03 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 30 May 2009 14:45:03 +0200
Subject: DVCS for MacPorts Project?
In-Reply-To: <95FD7CAA-1427-40CD-9D49-CD2F2FE41F2E@macports.org>
References: <90bb445a0905292303j1f0915c8pa743eca8fcec414e@mail.gmail.com>	<74c219d30905292307p940bc4fxea693451a25511be@mail.gmail.com>	<4A20CE50.2010401@orcaware.com>
	<95FD7CAA-1427-40CD-9D49-CD2F2FE41F2E@macports.org>
Message-ID: <4A212A4F.700@macports.org>

On 2009-05-30 10:57, Ryan Schmidt wrote:
> On May 30, 2009, at 01:12, Blair Zajac wrote:
>> One can always check out from the svn repository using git svn,  
>> which works nicely (except it commits the $Id$ properties using an  
>> expanded value).
> 
> Is there already a bug report with the developers for that problem?

The man page for git-svn says in the BUGS section:
  "We ignore all SVN properties except svn:executable."

But as git does not use a bug tracker and only a mailing list, I don't
know if anyone is still aware of this problem.

Rainer

From akitada at macports.org  Sat May 30 05:50:01 2009
From: akitada at macports.org (Akira Kitada)
Date: Sat, 30 May 2009 21:50:01 +0900
Subject: DVCS for MacPorts Project?
In-Reply-To: <4A212A4F.700@macports.org>
References: <90bb445a0905292303j1f0915c8pa743eca8fcec414e@mail.gmail.com> 
	<74c219d30905292307p940bc4fxea693451a25511be@mail.gmail.com> 
	<4A20CE50.2010401@orcaware.com>
	<95FD7CAA-1427-40CD-9D49-CD2F2FE41F2E@macports.org> 
	<4A212A4F.700@macports.org>
Message-ID: <90bb445a0905300550p54b6f7e0xf2956b1411d2365c@mail.gmail.com>

It seems Git and Mercurial just think keyword substitutions are't so
useful, and even it hurts, maybe.
So if there were a report on that, I wonder it will be fixed.
By the way, I also do not find $id$ is so useful. I just use it
because MacPorts Guide recommends it.

On Sat, May 30, 2009 at 9:45 PM, Rainer M?ller <raimue at macports.org> wrote:
> On 2009-05-30 10:57, Ryan Schmidt wrote:
>> On May 30, 2009, at 01:12, Blair Zajac wrote:
>>> One can always check out from the svn repository using git svn,
>>> which works nicely (except it commits the $Id$ properties using an
>>> expanded value).
>>
>> Is there already a bug report with the developers for that problem?
>
> The man page for git-svn says in the BUGS section:
> ?"We ignore all SVN properties except svn:executable."
>
> But as git does not use a bug tracker and only a mailing list, I don't
> know if anyone is still aware of this problem.
>
> Rainer
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
>

From raimue at macports.org  Sat May 30 06:32:01 2009
From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=)
Date: Sat, 30 May 2009 15:32:01 +0200
Subject: reinplace - how to remove a new line char
In-Reply-To: <b808b3510905291511i490990ch853da965756d96a3@mail.gmail.com>
References: <b808b3510905291511i490990ch853da965756d96a3@mail.gmail.com>
Message-ID: <4A213551.1010203@macports.org>

On 2009-05-30 00:11, Darren Weber wrote:
> An example of how to remove a line with some search text in it.  Assume
> tmp.txt contains:
> 
> # BEGIN (not in file)
> abc
> def
> # END (not in file)
> 
> reinplace {$!N;s|^.*abc.*\\n||g} tmp.txt

Easier sed syntax to remove a line would be:

reinplace {/^.*abc.*/d} tmp.txt

Rainer

From raimue at macports.org  Sat May 30 07:09:13 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 30 May 2009 16:09:13 +0200
Subject: DVCS for MacPorts Project?
In-Reply-To: <90bb445a0905300550p54b6f7e0xf2956b1411d2365c@mail.gmail.com>
References: <90bb445a0905292303j1f0915c8pa743eca8fcec414e@mail.gmail.com>
	<74c219d30905292307p940bc4fxea693451a25511be@mail.gmail.com>
	<4A20CE50.2010401@orcaware.com>
	<95FD7CAA-1427-40CD-9D49-CD2F2FE41F2E@macports.org>
	<4A212A4F.700@macports.org>
	<90bb445a0905300550p54b6f7e0xf2956b1411d2365c@mail.gmail.com>
Message-ID: <4A213E09.7050802@macports.org>

On 2009-05-30 14:50, Akira Kitada wrote:
> It seems Git and Mercurial just think keyword substitutions are't so
> useful, and even it hurts, maybe.
> So if there were a report on that, I wonder it will be fixed.
> By the way, I also do not find $id$ is so useful. I just use it
> because MacPorts Guide recommends it.

It can be useful to make sure that someone is really using the latest or
a specific Portfile. Portfiles may be changed without incrementing the
revision. So it is good to have another identifier in the file than just
version/revision/epoch.

For example, this can be helpful some times:
$ port cat <portname> | head -n1

Rainer

From raimue at macports.org  Sat May 30 07:30:09 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 30 May 2009 16:30:09 +0200
Subject: Building imaptest and a port
In-Reply-To: <2915DD98-AF61-407F-BE3C-F095F9AF9420@geeklair.net>
References: <16E04D98-E7AB-4C3E-B4EE-C41F86C3CB60@newgeo.com>
	<2915DD98-AF61-407F-BE3C-F095F9AF9420@geeklair.net>
Message-ID: <4A2142F1.6060201@macports.org>

On 2009-05-29 20:52, Daniel J. Luke wrote:
> On May 29, 2009, at 2:34 PM, Scott Haneda wrote:
>> If I remove the CLICOLOR variable, it will build fine.  Since I have  
>> had MacPorts build so many things, and never had this issue, I was  
>> hoping someone here can explain to me how to make sure MacPorts does  
>> not get hung on this issue.
> 
> 
> Macports does some cleaning of environment variables before building  
> software.

I think that does not help here... The configure script is executed in a
new shell which sources the user's .bashrc (as /bin/sh is bash).
Therefore CLICOLOR=1 is in the environment there.

I really don't understand why autotools is relying on `ls` in the shell
here and not using `which ls` to avoid aliases. I tried to reproduce the
problem with CLICOLOR=1 in my .bashrc, but this alone did not cause any
error. Did you alias ls to something?

Rainer

From raimue at macports.org  Sat May 30 07:53:03 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sat, 30 May 2009 16:53:03 +0200
Subject: how to merge my users svn Portfile into macports trunk?
In-Reply-To: <20090530002421.GF68902@ninagal.withay.com>
References: <b808b3510905281500u5ed1c862vd9a7117171cfce70@mail.gmail.com>	<3D120679-598A-4EDA-ADF7-F4C2D820B87D@apple.com>	<b808b3510905291251w57cad6dcu717e774234122171@mail.gmail.com>	<b808b3510905291300v52b6a2a5mb7ec43a2ead4a743@mail.gmail.com>	<b808b3510905291320h9541437i1cd7ce5f07a728d8@mail.gmail.com>
	<20090530002421.GF68902@ninagal.withay.com>
Message-ID: <4A21484F.2080507@macports.org>

On 2009-05-30 02:24, Bryan Blackburn wrote:
> $ cd /path/to/macports/checkout/trunk/dports/graphics/InsightToolkit
> $ svn merge http://svn.macports.org/repository/macports/users/dweber/graphics/InsightToolkit

A small side-note, as of Subversion 1.6 you do not have to type the full
URL anymore. See the release notes:
<http://subversion.tigris.org/svn_1.6_releasenotes.html#repository-root-relative-urls>

So, for this it would be enough to type:

$ svn merge ^/users/dweber/graphics/InsightToolkit

This is my personal favorite for best new feature of Subversion 1.6 ;-)

Rainer

From talklists at newgeo.com  Sat May 30 12:21:24 2009
From: talklists at newgeo.com (Scott Haneda)
Date: Sat, 30 May 2009 12:21:24 -0700
Subject: Building imaptest and a port
In-Reply-To: <4A2142F1.6060201@macports.org>
References: <16E04D98-E7AB-4C3E-B4EE-C41F86C3CB60@newgeo.com>
	<2915DD98-AF61-407F-BE3C-F095F9AF9420@geeklair.net>
	<4A2142F1.6060201@macports.org>
Message-ID: <4B498E20-3CB2-4B4E-840B-E2C266F6E4B4@newgeo.com>

On May 30, 2009, at 7:30 AM, Rainer M?ller wrote:

> On 2009-05-29 20:52, Daniel J. Luke wrote:
>> On May 29, 2009, at 2:34 PM, Scott Haneda wrote:
>>> If I remove the CLICOLOR variable, it will build fine.  Since I have
>>> had MacPorts build so many things, and never had this issue, I was
>>> hoping someone here can explain to me how to make sure MacPorts does
>>> not get hung on this issue.
>>
>>
>> Macports does some cleaning of environment variables before building
>> software.
>
> I think that does not help here... The configure script is executed  
> in a
> new shell which sources the user's .bashrc (as /bin/sh is bash).
> Therefore CLICOLOR=1 is in the environment there.
>
> I really don't understand why autotools is relying on `ls` in the  
> shell
> here and not using `which ls` to avoid aliases. I tried to reproduce  
> the
> problem with CLICOLOR=1 in my .bashrc, but this alone did not cause  
> any
> error. Did you alias ls to something?


I think in order to fully replicate the behavior:
# Color output
export CLICOLOR=1
export CLICOLOR_FORCE=1
export LSCOLORS=dxfxcxdxbxegedabagacad

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


From brad at pixilla.com  Sat May 30 13:00:17 2009
From: brad at pixilla.com (Bradley Giesbrecht)
Date: Sat, 30 May 2009 13:00:17 -0700
Subject: port cat
Message-ID: <70964EEA-F740-49AE-8664-AE7054A578FC@pixilla.com>

What do you think about having "port -v cat assp" print the file port  
is running cat on and then dump the contents?

//Brad

From raimue at macports.org  Sat May 30 16:00:26 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sun, 31 May 2009 01:00:26 +0200
Subject: port cat
In-Reply-To: <70964EEA-F740-49AE-8664-AE7054A578FC@pixilla.com>
References: <70964EEA-F740-49AE-8664-AE7054A578FC@pixilla.com>
Message-ID: <4A21BA8A.1090608@macports.org>

On 2009-05-30 22:00, Bradley Giesbrecht wrote:
> What do you think about having "port -v cat assp" print the file port  
> is running cat on and then dump the contents?

Would be easy to implement, but what is your use case for the additional
filename?

Note you can run multiple commands at once against one port by using the
interactive syntax:

$ port cd <portname> \; file \; cat

But I would not expect that many people know this or that is in common
use...

Rainer

From brad at pixilla.com  Sat May 30 16:23:18 2009
From: brad at pixilla.com (Bradley Giesbrecht)
Date: Sat, 30 May 2009 16:23:18 -0700
Subject: port cat
In-Reply-To: <4A21BA8A.1090608@macports.org>
References: <70964EEA-F740-49AE-8664-AE7054A578FC@pixilla.com>
	<4A21BA8A.1090608@macports.org>
Message-ID: <11A8492F-D296-46AE-94C9-DB73DC3202ED@pixilla.com>


On May 30, 2009, at 4:00 PM, Rainer M?ller wrote:

> On 2009-05-30 22:00, Bradley Giesbrecht wrote:
>> What do you think about having "port -v cat assp" print the file port
>> is running cat on and then dump the contents?
>
> Would be easy to implement, but what is your use case for the  
> additional
> filename?
>
> Note you can run multiple commands at once against one port by using  
> the
> interactive syntax:
>
> $ port cd <portname> \; file \; cat
>
> But I would not expect that many people know this or that is in common
> use...

This is good. I doubt I will remember it.

The reason I suggested the -v change is to assist in building Portfiles.

Sometimes dependencies don't do what you need and I was looking for an  
easy way to see if I was already using a local Portfile for dependences.

Maybe a list of Portfiles that will be called is available?

//Brad

From raimue at macports.org  Sat May 30 17:06:52 2009
From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=)
Date: Sun, 31 May 2009 02:06:52 +0200
Subject: Building imaptest and a port
In-Reply-To: <4B498E20-3CB2-4B4E-840B-E2C266F6E4B4@newgeo.com>
References: <16E04D98-E7AB-4C3E-B4EE-C41F86C3CB60@newgeo.com>
	<2915DD98-AF61-407F-BE3C-F095F9AF9420@geeklair.net>
	<4A2142F1.6060201@macports.org>
	<4B498E20-3CB2-4B4E-840B-E2C266F6E4B4@newgeo.com>
Message-ID: <4A21CA1C.2060707@macports.org>

On 2009-05-30 21:21, Scott Haneda wrote:
> I think in order to fully replicate the behavior:
> # Color output
> export CLICOLOR=1
> export CLICOLOR_FORCE=1
> export LSCOLORS=dxfxcxdxbxegedabagacad

Ah, it is the CLICOLOR_FORCE which causes the problem. Usually ls will
not output color codes if the output does not go to a terminal, but you
forced ls to do it always. I am also using CLICOLOR=1, but did not
experience any problems yet.

Rainer

From ryandesign at macports.org  Sat May 30 22:41:51 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 31 May 2009 00:41:51 -0500
Subject: [51616] trunk/dports/science/hdf5/Portfile
In-Reply-To: <20090529093242.346811C9C9C8@beta.macosforge.org>
References: <20090529093242.346811C9C9C8@beta.macosforge.org>
Message-ID: <2EEA5544-D738-4BCD-A5BE-836AEBEF4ADB@macports.org>

On May 29, 2009, at 04:32, jochen at macports.org wrote:

> Revision: 51616
>           http://trac.macports.org/changeset/51616
> Author:   jochen at macports.org
> Date:     2009-05-29 02:32:41 -0700 (Fri, 29 May 2009)
> Log Message:
> -----------
> add x86_64 variant for 64bit version


> +variant x86_64 description {Build 64 bit version} {
> +    configure.cflags-append     -m64
> +    configure.cxxflags-append   -m64
> +    configure.fflags-append     -m64
> +    configure.ldflags-append    -m64
> +}

I don't see any code that would prevent someone from selecting this  
on, say, a Power Mac G5. Would it work? If so, the name "x86_64"  
would be wrong.

I don't think we've had any variants before that do what you're doing  
here, switching from a 32-bit to 64-bit build. Though it is the  
strategy I think we should be employing moving forward for universal  
builds. As I wrote some time ago, I think ports should build only for  
the 32-bit local arch by default as they do now, and there should be  
a variant (probably a platform variant) to build only for the 64-bit  
local arch, and we would have a PowerPC and an Intel build machine,  
and each would build each port twice, once for 32-bit and once for 64- 
bit, and the results of all four builds would be merged together. If  
we employ this strategy, we may want to settle on a different variant  
name than "x86_64".


From ryandesign at macports.org  Sun May 31 00:13:18 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 31 May 2009 02:13:18 -0500
Subject: DVCS for MacPorts Project?
In-Reply-To: <90bb445a0905300550p54b6f7e0xf2956b1411d2365c@mail.gmail.com>
References: <90bb445a0905292303j1f0915c8pa743eca8fcec414e@mail.gmail.com>
	<74c219d30905292307p940bc4fxea693451a25511be@mail.gmail.com>
	<4A20CE50.2010401@orcaware.com>
	<95FD7CAA-1427-40CD-9D49-CD2F2FE41F2E@macports.org>
	<4A212A4F.700@macports.org>
	<90bb445a0905300550p54b6f7e0xf2956b1411d2365c@mail.gmail.com>
Message-ID: <462903CF-4E1D-456B-B3E2-0E23828C7B73@macports.org>


On May 30, 2009, at 07:50, Akira Kitada wrote:

> It seems Git and Mercurial just think keyword substitutions are't so
> useful, and even it hurts, maybe.
> So if there were a report on that, I wonder it will be fixed.

Wonderful. So they knowingly distribute a client that does not  
conform to the client/server agreement.

If we care enough to prevent these malformed commits from getting  
into our repository, we can write a pre-commit hook to prevent them.


> By the way, I also do not find $id$ is so useful. I just use it
> because MacPorts Guide recommends it.

Thank you for abiding by the guideline. The $Id$ keyword has been  
useful to me many times already, in looking at modified portfiles  
submitted in Trac tickets, to determine what revision of the original  
portfile the new one was based on.


From akitada at macports.org  Sun May 31 01:24:29 2009
From: akitada at macports.org (Akira Kitada)
Date: Sun, 31 May 2009 17:24:29 +0900
Subject: DVCS for MacPorts Project?
In-Reply-To: <462903CF-4E1D-456B-B3E2-0E23828C7B73@macports.org>
References: <90bb445a0905292303j1f0915c8pa743eca8fcec414e@mail.gmail.com> 
	<74c219d30905292307p940bc4fxea693451a25511be@mail.gmail.com> 
	<4A20CE50.2010401@orcaware.com>
	<95FD7CAA-1427-40CD-9D49-CD2F2FE41F2E@macports.org> 
	<4A212A4F.700@macports.org>
	<90bb445a0905300550p54b6f7e0xf2956b1411d2365c@mail.gmail.com> 
	<462903CF-4E1D-456B-B3E2-0E23828C7B73@macports.org>
Message-ID: <90bb445a0905310124o4aad1886v20748313877121b1@mail.gmail.com>

Just in case you're interested in this topic:

http://kerneltrap.org/mailarchive/git/2006/10/9/223932
http://www.selenic.com/mercurial/wiki/KeywordPlan

On Sun, May 31, 2009 at 4:13 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On May 30, 2009, at 07:50, Akira Kitada wrote:
>
>> It seems Git and Mercurial just think keyword substitutions are't so
>> useful, and even it hurts, maybe.
>> So if there were a report on that, I wonder it will be fixed.
>
> Wonderful. So they knowingly distribute a client that does not conform to
> the client/server agreement.
>
> If we care enough to prevent these malformed commits from getting into our
> repository, we can write a pre-commit hook to prevent them.
>
>
>> By the way, I also do not find $id$ is so useful. I just use it
>> because MacPorts Guide recommends it.
>
> Thank you for abiding by the guideline. The $Id$ keyword has been useful to
> me many times already, in looking at modified portfiles submitted in Trac
> tickets, to determine what revision of the original portfile the new one was
> based on.
>
>

From febeling at macports.org  Sun May 31 01:57:40 2009
From: febeling at macports.org (C. Florian Ebeling)
Date: Sun, 31 May 2009 10:57:40 +0200
Subject: DVCS for MacPorts Project?
In-Reply-To: <462903CF-4E1D-456B-B3E2-0E23828C7B73@macports.org>
References: <90bb445a0905292303j1f0915c8pa743eca8fcec414e@mail.gmail.com>
	<74c219d30905292307p940bc4fxea693451a25511be@mail.gmail.com>
	<4A20CE50.2010401@orcaware.com>
	<95FD7CAA-1427-40CD-9D49-CD2F2FE41F2E@macports.org>
	<4A212A4F.700@macports.org>
	<90bb445a0905300550p54b6f7e0xf2956b1411d2365c@mail.gmail.com>
	<462903CF-4E1D-456B-B3E2-0E23828C7B73@macports.org>
Message-ID: <5cbbe4ae0905310157o298b761ax4ee6d336ca72f8ec@mail.gmail.com>

On Sun, May 31, 2009 at 9:13 AM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> On May 30, 2009, at 07:50, Akira Kitada wrote:
>
>> It seems Git and Mercurial just think keyword substitutions are't so
>> useful, and even it hurts, maybe.
>> So if there were a report on that, I wonder it will be fixed.
>
> Wonderful. So they knowingly distribute a client that does not conform to
> the client/server agreement.
>
> If we care enough to prevent these malformed commits from getting into our
> repository, we can write a pre-commit hook to prevent them.
>
>> By the way, I also do not find $id$ is so useful. I just use it
>> because MacPorts Guide recommends it.
>
> Thank you for abiding by the guideline.

Ryan, I find your communication style quite unfriendly here. I don't
see why Akira's considerately presented preference, which is different
from the one mp makes, deserves such a sarcastic reply.

If you drive away a single contributer by applying this style, you
have hurt the project more than anyone could by not adhering to some
minor guideline.



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

From toby at apple.com  Sun May 31 02:18:37 2009
From: toby at apple.com (Toby Peterson)
Date: Sun, 31 May 2009 02:18:37 -0700
Subject: DVCS for MacPorts Project?
In-Reply-To: <5cbbe4ae0905310157o298b761ax4ee6d336ca72f8ec@mail.gmail.com>
References: <90bb445a0905292303j1f0915c8pa743eca8fcec414e@mail.gmail.com>
	<74c219d30905292307p940bc4fxea693451a25511be@mail.gmail.com>
	<4A20CE50.2010401@orcaware.com>
	<95FD7CAA-1427-40CD-9D49-CD2F2FE41F2E@macports.org>
	<4A212A4F.700@macports.org>
	<90bb445a0905300550p54b6f7e0xf2956b1411d2365c@mail.gmail.com>
	<462903CF-4E1D-456B-B3E2-0E23828C7B73@macports.org>
	<5cbbe4ae0905310157o298b761ax4ee6d336ca72f8ec@mail.gmail.com>
Message-ID: <3D1C40CE-A1D2-4A94-8809-BE5417701151@apple.com>

On May 31, 2009, at 1:57 AM, C. Florian Ebeling wrote:

> On Sun, May 31, 2009 at 9:13 AM, Ryan Schmidt  
> <ryandesign at macports.org> wrote:
>>
>> On May 30, 2009, at 07:50, Akira Kitada wrote:
>>
>>> It seems Git and Mercurial just think keyword substitutions are't so
>>> useful, and even it hurts, maybe.
>>> So if there were a report on that, I wonder it will be fixed.
>>
>> Wonderful. So they knowingly distribute a client that does not  
>> conform to
>> the client/server agreement.
>>
>> If we care enough to prevent these malformed commits from getting  
>> into our
>> repository, we can write a pre-commit hook to prevent them.
>>
>>> By the way, I also do not find $id$ is so useful. I just use it
>>> because MacPorts Guide recommends it.
>>
>> Thank you for abiding by the guideline.
>
> Ryan, I find your communication style quite unfriendly here. I don't
> see why Akira's considerately presented preference, which is different
> from the one mp makes, deserves such a sarcastic reply.
>
> If you drive away a single contributer by applying this style, you
> have hurt the project more than anyone could by not adhering to some
> minor guideline.

I haven't seen any issues from people using other (non-svn) clients to  
commit - afaik the $Id$ tag expansion is a server-side operation...

We aren't switching to any other system, and people can use any client  
they wish. I don't think there's an issue here.

- Toby

From blair at orcaware.com  Sun May 31 09:35:22 2009
From: blair at orcaware.com (Blair Zajac)
Date: Sun, 31 May 2009 09:35:22 -0700
Subject: DVCS for MacPorts Project?
In-Reply-To: <3D1C40CE-A1D2-4A94-8809-BE5417701151@apple.com>
References: <90bb445a0905292303j1f0915c8pa743eca8fcec414e@mail.gmail.com>
	<74c219d30905292307p940bc4fxea693451a25511be@mail.gmail.com>
	<4A20CE50.2010401@orcaware.com>
	<95FD7CAA-1427-40CD-9D49-CD2F2FE41F2E@macports.org>
	<4A212A4F.700@macports.org>
	<90bb445a0905300550p54b6f7e0xf2956b1411d2365c@mail.gmail.com>
	<462903CF-4E1D-456B-B3E2-0E23828C7B73@macports.org>
	<5cbbe4ae0905310157o298b761ax4ee6d336ca72f8ec@mail.gmail.com>
	<3D1C40CE-A1D2-4A94-8809-BE5417701151@apple.com>
Message-ID: <DB2CB825-00BF-4B85-9281-06E03A81605B@orcaware.com>


On May 31, 2009, at 2:18 AM, Toby Peterson wrote:

> On May 31, 2009, at 1:57 AM, C. Florian Ebeling wrote:
>
>> On Sun, May 31, 2009 at 9:13 AM, Ryan Schmidt <ryandesign at macports.org 
>> > wrote:
>>>
>>> On May 30, 2009, at 07:50, Akira Kitada wrote:
>>>
>>>> It seems Git and Mercurial just think keyword substitutions are't  
>>>> so
>>>> useful, and even it hurts, maybe.
>>>> So if there were a report on that, I wonder it will be fixed.
>>>
>>> Wonderful. So they knowingly distribute a client that does not  
>>> conform to
>>> the client/server agreement.
>>>
>>> If we care enough to prevent these malformed commits from getting  
>>> into our
>>> repository, we can write a pre-commit hook to prevent them.
>>>
>>>> By the way, I also do not find $id$ is so useful. I just use it
>>>> because MacPorts Guide recommends it.
>>>
>>> Thank you for abiding by the guideline.
>>
>> Ryan, I find your communication style quite unfriendly here. I don't
>> see why Akira's considerately presented preference, which is  
>> different
>> from the one mp makes, deserves such a sarcastic reply.
>>
>> If you drive away a single contributer by applying this style, you
>> have hurt the project more than anyone could by not adhering to some
>> minor guideline.
>
> I haven't seen any issues from people using other (non-svn) clients  
> to commit - afaik the $Id$ tag expansion is a server-side operation...

It's a client side operation.  The client removes the characters after  
the d and before the $ when it sends the file to the server and adds  
the contents when it checks out or updates the file.

For example, look at this URL in a browser, not an svn client:

http://svn.macports.org/repository/macports/trunk/dports/java/jna/Portfile

Blair


From ryandesign at macports.org  Sun May 31 09:40:35 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 31 May 2009 11:40:35 -0500
Subject: DVCS for MacPorts Project?
In-Reply-To: <90bb445a0905310124o4aad1886v20748313877121b1@mail.gmail.com>
References: <90bb445a0905292303j1f0915c8pa743eca8fcec414e@mail.gmail.com>
	<74c219d30905292307p940bc4fxea693451a25511be@mail.gmail.com>
	<4A20CE50.2010401@orcaware.com>
	<95FD7CAA-1427-40CD-9D49-CD2F2FE41F2E@macports.org>
	<4A212A4F.700@macports.org>
	<90bb445a0905300550p54b6f7e0xf2956b1411d2365c@mail.gmail.com>
	<462903CF-4E1D-456B-B3E2-0E23828C7B73@macports.org>
	<90bb445a0905310124o4aad1886v20748313877121b1@mail.gmail.com>
Message-ID: <77104A2C-CF6C-431E-B82C-D4F7C77B58BC@macports.org>


On May 31, 2009, at 03:24, Akira Kitada wrote:

> On Sun, May 31, 2009 at 4:13 PM, Ryan Schmidt  
> <ryandesign at macports.org> wrote:
>>
>> On May 30, 2009, at 07:50, Akira Kitada wrote:
>>
>>> It seems Git and Mercurial just think keyword substitutions are't so
>>> useful, and even it hurts, maybe.
>>> So if there were a report on that, I wonder it will be fixed.
>>
>> Wonderful. So they knowingly distribute a client that does not  
>> conform to
>> the client/server agreement.
>>
>> If we care enough to prevent these malformed commits from getting  
>> into our
>> repository, we can write a pre-commit hook to prevent them.
>
> Just in case you're interested in this topic:
>
> http://kerneltrap.org/mailarchive/git/2006/10/9/223932
> http://www.selenic.com/mercurial/wiki/KeywordPlan

Thanks for those references. They seem to state, as you mentioned  
earlier, that the developers of git think keywords are bad and they  
don't want to support them.

I have no problem with that as it pertains to git. However git can be  
used as a Subversion client. It is the responsibility of a Subversion  
client to normalize keywords to unexpanded form before sending to the  
repository, and the git Subversion client does not appear to do this.  
Therefore git's Subversion client mode is faulty.


From ryandesign at macports.org  Sun May 31 09:42:40 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 31 May 2009 11:42:40 -0500
Subject: DVCS for MacPorts Project?
In-Reply-To: <5cbbe4ae0905310157o298b761ax4ee6d336ca72f8ec@mail.gmail.com>
References: <90bb445a0905292303j1f0915c8pa743eca8fcec414e@mail.gmail.com>
	<74c219d30905292307p940bc4fxea693451a25511be@mail.gmail.com>
	<4A20CE50.2010401@orcaware.com>
	<95FD7CAA-1427-40CD-9D49-CD2F2FE41F2E@macports.org>
	<4A212A4F.700@macports.org>
	<90bb445a0905300550p54b6f7e0xf2956b1411d2365c@mail.gmail.com>
	<462903CF-4E1D-456B-B3E2-0E23828C7B73@macports.org>
	<5cbbe4ae0905310157o298b761ax4ee6d336ca72f8ec@mail.gmail.com>
Message-ID: <F954F32D-16EB-4191-97B8-925445E4567F@macports.org>


On May 31, 2009, at 03:57, C. Florian Ebeling wrote:

>>> By the way, I also do not find $id$ is so useful. I just use it
>>> because MacPorts Guide recommends it.
>>
>> Thank you for abiding by the guideline.
>
> Ryan, I find your communication style quite unfriendly here. I don't
> see why Akira's considerately presented preference, which is different
> from the one mp makes, deserves such a sarcastic reply.
>
> If you drive away a single contributer by applying this style, you
> have hurt the project more than anyone could by not adhering to some
> minor guideline.

You're right, that sounded a little snarky and I apologize. I really  
did just mean exactly what I wrote: thanking Akira for abiding by the  
guideline. Sometimes ports get committed that don't, and then I fix  
them; I like it when I don't have to do that. I should have probably  
put a smiley after that sentence.

What I wrote above that:

>> Wonderful. So they knowingly distribute a client that does not  
>> conform to
>> the client/server agreement.
>>
>> If we care enough to prevent these malformed commits from getting  
>> into our
>> repository, we can write a pre-commit hook to prevent them.

was intended to be more critical, but of the developers of git, not  
of Akira. Just a rant, which would probably have been more effective  
if sent to the developers of git.


From jmr at macports.org  Sun May 31 09:49:24 2009
From: jmr at macports.org (Joshua Root)
Date: Mon, 01 Jun 2009 02:49:24 +1000
Subject: DVCS for MacPorts Project?
In-Reply-To: <F954F32D-16EB-4191-97B8-925445E4567F@macports.org>
References: <90bb445a0905292303j1f0915c8pa743eca8fcec414e@mail.gmail.com>	<74c219d30905292307p940bc4fxea693451a25511be@mail.gmail.com>	<4A20CE50.2010401@orcaware.com>	<95FD7CAA-1427-40CD-9D49-CD2F2FE41F2E@macports.org>	<4A212A4F.700@macports.org>	<90bb445a0905300550p54b6f7e0xf2956b1411d2365c@mail.gmail.com>	<462903CF-4E1D-456B-B3E2-0E23828C7B73@macports.org>	<5cbbe4ae0905310157o298b761ax4ee6d336ca72f8ec@mail.gmail.com>
	<F954F32D-16EB-4191-97B8-925445E4567F@macports.org>
Message-ID: <4A22B514.6030002@macports.org>

On 2009-6-1 02:42, Ryan Schmidt wrote:
> Just a rant, which would probably have been more effective if
> sent to the developers of git.

Unlikely IMHO. :-)

- Josh

From ryandesign at macports.org  Sun May 31 09:58:40 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 31 May 2009 11:58:40 -0500
Subject: DVCS for MacPorts Project?
In-Reply-To: <DB2CB825-00BF-4B85-9281-06E03A81605B@orcaware.com>
References: <90bb445a0905292303j1f0915c8pa743eca8fcec414e@mail.gmail.com>
	<74c219d30905292307p940bc4fxea693451a25511be@mail.gmail.com>
	<4A20CE50.2010401@orcaware.com>
	<95FD7CAA-1427-40CD-9D49-CD2F2FE41F2E@macports.org>
	<4A212A4F.700@macports.org>
	<90bb445a0905300550p54b6f7e0xf2956b1411d2365c@mail.gmail.com>
	<462903CF-4E1D-456B-B3E2-0E23828C7B73@macports.org>
	<5cbbe4ae0905310157o298b761ax4ee6d336ca72f8ec@mail.gmail.com>
	<3D1C40CE-A1D2-4A94-8809-BE5417701151@apple.com>
	<DB2CB825-00BF-4B85-9281-06E03A81605B@orcaware.com>
Message-ID: <C7BF2D3D-325A-430D-94D7-8CD1A6F693C9@macports.org>

On May 31, 2009, at 11:35, Blair Zajac wrote:

> On May 31, 2009, at 2:18 AM, Toby Peterson wrote:
>
>> I haven't seen any issues from people using other (non-svn)  
>> clients to commit - afaik the $Id$ tag expansion is a server-side  
>> operation...
>
> It's a client side operation.  The client removes the characters  
> after the d and before the $ when it sends the file to the server  
> and adds the contents when it checks out or updates the file.
>
> For example, look at this URL in a browser, not an svn client:
>
> http://svn.macports.org/repository/macports/trunk/dports/java/jna/ 
> Portfile

Right, and there was recently a brief thread on the dev list where I  
noticed commits where this normalizing of the Id was not happening  
and git seemed to be implicated:

http://lists.macosforge.org/pipermail/macports-dev/2009-April/ 
008467.html


From brad at pixilla.com  Sun May 31 10:50:40 2009
From: brad at pixilla.com (Bradley Giesbrecht)
Date: Sun, 31 May 2009 10:50:40 -0700
Subject: openssl
Message-ID: <5759EA69-99A5-4571-AB49-469D22C4CFFB@pixilla.com>

I'm befuddled:
bash-3.2# port installed|grep openssl
   openssl @0.9.8j_0
   openssl @1.0.0-beta1_0 (active)

bash-3.2# port info openssl
openssl @0.9.8k (devel, security)

Was openssl @1.0.0-beta1_0 removed from macports?

I'm attempting to bump local versions for p5-net-ssleay which starts  
to download openssl,  @0.9.8j_0 I presume.

bash-3.2# port deps p5-net-ssleay
p5-net-ssleay has build dependencies on:
	openssl

What should I do now? Maybe add a local openssl @1.(current beta)?

I'm a little nervous. I need and am currently using openssl on this  
system. Having ssl problems would be for me.


//Brad

From frstan at bellsouth.net  Sun May 31 11:01:25 2009
From: frstan at bellsouth.net (William Davis)
Date: Sun, 31 May 2009 14:01:25 -0400
Subject: openssl
In-Reply-To: <5759EA69-99A5-4571-AB49-469D22C4CFFB@pixilla.com>
References: <5759EA69-99A5-4571-AB49-469D22C4CFFB@pixilla.com>
Message-ID: <7701414D-1B86-499F-BE01-27D9F97C2A6F@bellsouth.net>


On May 31, 2009, at 1:50 PM, Bradley Giesbrecht wrote:

> I'm befuddled:
> bash-3.2# port installed|grep openssl
>  openssl @0.9.8j_0
>  openssl @1.0.0-beta1_0 (active)
>
> bash-3.2# port info openssl
> openssl @0.9.8k (devel, security)
>
> Was openssl @1.0.0-beta1_0 removed from macports?
>
> I'm attempting to bump local versions for p5-net-ssleay which starts  
> to download openssl,  @0.9.8j_0 I presume.
>

port info openssl shows 0.9.8k as the current version on the MacPorts  
server. That is what would have downloaded ....
WSD



> bash-3.2# port deps p5-net-ssleay
> p5-net-ssleay has build dependencies on:
> 	openssl
>
> What should I do now? Maybe add a local openssl @1.(current beta)?
>
> I'm a little nervous. I need and am currently using openssl on this  
> system. Having ssl problems would be for me.
>
>
> //Brad



William Davis
frstanATbellsouthDOTnet
Mac OS X.5.7 Darwin 9.7.0
XQuartz 2.3.3.2 (xorg-server 1.4.2-apple42)
Mac Mini Intel Duo @ 1.86 GHz

Mundus vult decepi, ego non


From blair at orcaware.com  Sun May 31 11:20:38 2009
From: blair at orcaware.com (Blair Zajac)
Date: Sun, 31 May 2009 11:20:38 -0700
Subject: openssl
In-Reply-To: <7701414D-1B86-499F-BE01-27D9F97C2A6F@bellsouth.net>
References: <5759EA69-99A5-4571-AB49-469D22C4CFFB@pixilla.com>
	<7701414D-1B86-499F-BE01-27D9F97C2A6F@bellsouth.net>
Message-ID: <919B569A-212F-47A7-8B7B-853A60720902@orcaware.com>


On May 31, 2009, at 11:01 AM, William Davis wrote:

>
> On May 31, 2009, at 1:50 PM, Bradley Giesbrecht wrote:
>
>> I'm befuddled:
>> bash-3.2# port installed|grep openssl
>> openssl @0.9.8j_0
>> openssl @1.0.0-beta1_0 (active)
>>
>> bash-3.2# port info openssl
>> openssl @0.9.8k (devel, security)
>>
>> Was openssl @1.0.0-beta1_0 removed from macports?
>>
>> I'm attempting to bump local versions for p5-net-ssleay which  
>> starts to download openssl,  @0.9.8j_0 I presume.
>>
>
> port info openssl shows 0.9.8k as the current version on the  
> MacPorts server. That is what would have downloaded ....
> WSD

Right.  The epoch was set so that 1.0.9.8k is greater than 0.1.0.0- 
beta1 (the first digit being the epoch value):

name                    openssl
version                 0.9.8k
epoch                   1

Blair


From ryandesign at macports.org  Sun May 31 11:56:26 2009
From: ryandesign at macports.org (Ryan Schmidt)
Date: Sun, 31 May 2009 13:56:26 -0500
Subject: openssl
In-Reply-To: <5759EA69-99A5-4571-AB49-469D22C4CFFB@pixilla.com>
References: <5759EA69-99A5-4571-AB49-469D22C4CFFB@pixilla.com>
Message-ID: <E057C274-1471-4D0D-8404-1C1F3F6FC7EA@macports.org>


On May 31, 2009, at 12:50, Bradley Giesbrecht wrote:

> I'm befuddled:
> bash-3.2# port installed|grep openssl
>   openssl @0.9.8j_0
>   openssl @1.0.0-beta1_0 (active)
>
> bash-3.2# port info openssl
> openssl @0.9.8k (devel, security)
>
> Was openssl @1.0.0-beta1_0 removed from macports?

Yes, I believe it was found to cause problems so it was removed.


> I'm attempting to bump local versions for p5-net-ssleay which  
> starts to download openssl,  @0.9.8j_0 I presume.

If you "port upgrade openssl" it should uninstall 1.0.0-beta1_0 and  
install 0.9.8k_0.


> bash-3.2# port deps p5-net-ssleay
> p5-net-ssleay has build dependencies on:
> 	openssl
>
> What should I do now? Maybe add a local openssl @1.(current beta)?
>
> I'm a little nervous. I need and am currently using openssl on this  
> system. Having ssl problems would be for me.

You should probably allow MacPorts to do what it's doing. Unless you  
specifically require openssl 1.x, in which case, you should speak  
with the maintainer about the issues that caused its removal and see  
what can be done to resolve them.

After 0.9.8k is installed, you may need to forcibly rebuild any ports  
that had linked with 1.0.0.


From jeremyhu at macports.org  Sun May 31 13:07:48 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Sun, 31 May 2009 13:07:48 -0700
Subject: configure oddity when run via MacPorts
Message-ID: <898B407B-BD0B-47ED-8190-56A8498C5F88@macports.org>

I'm trying to update cdparanoia.  I can build it manually, but it  
fails configure via port (I updated base yesterday):

...
--->  Configuring cdparanoia
checking build system type... powerpc-apple-darwin9.7.0
checking host system type... powerpc-apple-darwin9.7.0
checking for ranlib... ranlib
checking for ar... ar
checking for install... /usr/bin/install -c
checking how to run the C preprocessor... /usr/bin/cpp-4.0
checking for egrep... grep -E
checking for ANSI C header files... no
checking for sys/types.h... no
checking for sys/stat.h... no
checking for stdlib.h... no
checking for string.h... no
checking for memory.h... no
checking for strings.h... no
checking for inttypes.h... no
checking for stdint.h... no
checking for unistd.h... no
checking for short... no
checking size of short... 0
checking for int... no
checking size of int... 0
checking for long... no
checking size of long... 0
checking for long long... no
checking size of long long... 0
checking for int16_t... no
checking for int32_t... no
configure: error: No 16 bit type found on this platform!
Error: Target org.macports.configure returned: configure failure:  
shell command " cd "/opt/local/var/macports/build/ 
_Volumes_MyBook_src_macports-trunk_dports_audio_cdparanoia/work/ 
cdparanoia-III-10.2" && ./configure --prefix=/opt/local " returned  
error 1
Command output: checking build system type... powerpc-apple-darwin9.7.0
...

but it works fine manually:

/opt/local/var/macports/build/_Volumes_MyBook_src_macports- 
trunk_dports_audio_cdparanoia/work/cdparanoia-III-10.2 $ sudo ./ 
configure --prefix=/opt/local
checking build system type... powerpc-apple-darwin9.7.0
checking host system type... powerpc-apple-darwin9.7.0
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for ranlib... ranlib
checking for ar... ar
checking for install... install
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
...

----

here's a snippit from config.log for the missing stdlib.h:

configure:2936: test -s conftest.
configure:2939: $? = 1

----

compared to when I do it manually:

configure:2936: test -s conftest.o
configure:2939: $? = 0


----

The configure script is skipping all these tests when run through  
MacPorts:

checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed

so it doesn't know about the ".o" suffix.

Does anyone have a clue why this is happening?



From blb at macports.org  Sun May 31 13:36:17 2009
From: blb at macports.org (Bryan Blackburn)
Date: Sun, 31 May 2009 14:36:17 -0600
Subject: configure oddity when run via MacPorts
In-Reply-To: <898B407B-BD0B-47ED-8190-56A8498C5F88@macports.org>
References: <898B407B-BD0B-47ED-8190-56A8498C5F88@macports.org>
Message-ID: <20090531203617.GC14575@ninagal.withay.com>

On Sun, May 31, 2009 at 01:07:48PM -0700, Jeremy Huddleston said:
> I'm trying to update cdparanoia.  I can build it manually, but it fails 
> configure via port (I updated base yesterday):
>
> ...
> --->  Configuring cdparanoia
> checking build system type... powerpc-apple-darwin9.7.0
> checking host system type... powerpc-apple-darwin9.7.0
> checking for ranlib... ranlib
[...]
>
> Does anyone have a clue why this is happening?

It looks like configure.in does

   if test -z "$CC"; then
      AC_PROG_CC
   fi

which means that, since MacPorts sets CC to what should be the right one for
the platform, configure skips all the various stuff from AC_PROG_CC...

Removing that if and always doing AC_PROG_CC at least gets it to configure.

Bryan


From jeremyhu at macports.org  Sun May 31 14:01:53 2009
From: jeremyhu at macports.org (Jeremy Huddleston)
Date: Sun, 31 May 2009 14:01:53 -0700
Subject: configure oddity when run via MacPorts
In-Reply-To: <20090531203617.GC14575@ninagal.withay.com>
References: <898B407B-BD0B-47ED-8190-56A8498C5F88@macports.org>
	<20090531203617.GC14575@ninagal.withay.com>
Message-ID: <9E73F2B2-7C2F-4767-BDEF-00BCD65BE75A@macports.org>

Yep, that was it.  Thanks.

new cdparanoia is in MP.

--Jeremy

On May 31, 2009, at 13:36, Bryan Blackburn wrote:

> On Sun, May 31, 2009 at 01:07:48PM -0700, Jeremy Huddleston said:
>> I'm trying to update cdparanoia.  I can build it manually, but it  
>> fails
>> configure via port (I updated base yesterday):
>>
>> ...
>> --->  Configuring cdparanoia
>> checking build system type... powerpc-apple-darwin9.7.0
>> checking host system type... powerpc-apple-darwin9.7.0
>> checking for ranlib... ranlib
> [...]
>>
>> Does anyone have a clue why this is happening?
>
> It looks like configure.in does
>
>   if test -z "$CC"; then
>      AC_PROG_CC
>   fi
>
> which means that, since MacPorts sets CC to what should be the right  
> one for
> the platform, configure skips all the various stuff from AC_PROG_CC...
>
> Removing that if and always doing AC_PROG_CC at least gets it to  
> configure.
>
> Bryan
>
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev