From ryandesign at macports.org Sat Aug 1 10:34:05 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 1 Aug 2009 12:34:05 -0500 Subject: [54735] trunk/dports/lang In-Reply-To: <20090801124013.C011222863A6@beta.macosforge.org> References: <20090801124013.C011222863A6@beta.macosforge.org> Message-ID: <2580A0E5-DA3C-4B48-A9DF-F6388ECE9E42@macports.org> On Aug 1, 2009, at 07:40, mnick at macports.org wrote: > Revision: 54735 > http://trac.macports.org/changeset/54735 > Author: mnick at macports.org > Date: 2009-08-01 05:40:11 -0700 (Sat, 01 Aug 2009) > Log Message: > ----------- > new port: gccxml-devel (since there is no official release since 2004) Since this port builds using cmake, have you considered using the cmake portgroup? It does some more things than you do (universal setup, debug options, verbosity), and you do some more things than it does (build dir) but it may still be useful. > Added Paths: > ----------- > trunk/dports/lang/gccxml-devel/ > trunk/dports/lang/gccxml-devel/Portfile > > Added: trunk/dports/lang/gccxml-devel/Portfile > =================================================================== > --- trunk/dports/lang/gccxml-devel/Portfile > (rev 0) > +++ trunk/dports/lang/gccxml-devel/Portfile 2009-08-01 12:40:11 UTC > (rev 54735) > @@ -0,0 +1,34 @@ > +# $Id$ > + > +PortSystem 1.0 > + > +name gccxml-devel > +version 20090713 > +categories lang > +platforms darwin > +maintainers mnick openmaintainer > +description generates XML description of C++ code > +long_description generates an XML description of a C++ program > from GCC's \ > + internal representation > + > +homepage http://www.gccxml.org/ > +fetch.type cvs > +cvs.root :pserver:anoncvs at www.gccxml.org:/cvsroot/GCC_XML > +cvs.date 2009-07-13 > +cvs.module gccxml > +worksrcdir gccxml > + > +depends_build port:cmake > + > +post-extract { > + file mkdir ${workpath}/build > +} > + > +configure { > + system "cd ${workpath}/build \ > + && cmake ${worksrcpath} -DCMAKE_INSTALL_PREFIX:PATH=${prefix}" > +} > + > +build.dir ${workpath}/build > +destroot.dir ${workpath}/build From ryandesign at macports.org Sat Aug 1 11:16:04 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 1 Aug 2009 13:16:04 -0500 Subject: can't read "configure.universal_ldflags": no such variable In-Reply-To: <07E42C69-4825-4A13-9B96-5F14DAC91594@macports.org> References: <6F1859E6-412B-4195-B936-FBC6CA96F2A0@macports.org> <4A0B94D4.6030400@macports.org> <07E42C69-4825-4A13-9B96-5F14DAC91594@macports.org> Message-ID: On May 13, 2009, at 23:11, Ryan Schmidt wrote: > 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... It would be nice if Intel Tiger users were able to build universal ports again with the muniversal portgroup. When can we release 1.8.0 so this will be fixed? From jmr at macports.org Sat Aug 1 12:26:27 2009 From: jmr at macports.org (Joshua Root) Date: Sun, 02 Aug 2009 05:26:27 +1000 Subject: can't read "configure.universal_ldflags": no such variable In-Reply-To: References: <6F1859E6-412B-4195-B936-FBC6CA96F2A0@macports.org> <4A0B94D4.6030400@macports.org> <07E42C69-4825-4A13-9B96-5F14DAC91594@macports.org> Message-ID: <4A7496E3.5080905@macports.org> On 2009-8-2 04:16, Ryan Schmidt wrote: > On May 13, 2009, at 23:11, Ryan Schmidt wrote: > >> 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... > > It would be nice if Intel Tiger users were able to build universal ports > again with the muniversal portgroup. > > When can we release 1.8.0 so this will be fixed? The workaround is pretty simple and I thought someone already applied it to the portgroup. I just did so in r54754. - Josh From ryandesign at macports.org Sat Aug 1 13:20:30 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 1 Aug 2009 15:20:30 -0500 Subject: can't read "configure.universal_ldflags": no such variable In-Reply-To: <4A7496E3.5080905@macports.org> References: <6F1859E6-412B-4195-B936-FBC6CA96F2A0@macports.org> <4A0B94D4.6030400@macports.org> <07E42C69-4825-4A13-9B96-5F14DAC91594@macports.org> <4A7496E3.5080905@macports.org> Message-ID: On Aug 1, 2009, at 14:26, Joshua Root wrote: > On 2009-8-2 04:16, Ryan Schmidt wrote: > >> It would be nice if Intel Tiger users were able to build universal >> ports >> again with the muniversal portgroup. > > The workaround is pretty simple and I thought someone already > applied it > to the portgroup. I just did so in r54754. Thanks, that works great. Now I wish I had thought of that earlier. :) From jeremyhu at macports.org Sat Aug 1 15:37:39 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sat, 1 Aug 2009 15:37:39 -0700 Subject: invalid command name "..." Message-ID: <2DB8EE41-B6B5-48A3-86F8-55D251905B51@macports.org> So recent base has been giving me a problem... With a fresh checkout, I do: # First sanitize your environment to remove any reference to /opt/ local etc svn co https://svn.macosforge.org/repository/macports/trunk/base cd base ./configure && gnumake -j3 && sudo make install ? ===> making install in src/programs/daemondo /usr/bin/install -c -o root -g admin -m 555 build/daemondo /opt/local/ bin [ ! -f /opt/local/etc/macports/mp_version ] || rm -vf /opt/local/etc/ macports/mp_version /usr/bin/install -c -o root -g admin -m 444 setupenv.bash /opt/local/ share/macports/ /usr/bin/tclsh src/upgrade_sources_conf_default.tcl /opt/local /usr/bin/tclsh src/dep_map_clean.tcl /Library/Tcl invalid command name "sysctl" while executing "sysctl hw.cpu64bit_capable" (procedure "mportinit" line 363) invoked from within "mportinit" (file "src/dep_map_clean.tcl" line 12) make: *** [install] Error 1 The above failure happens on my intel box when installing for i386 or x86_64. The below failure happens on my Leopard G5 box: invalid command name "get_systemconfiguration_proxies" while executing "get_systemconfiguration_proxies" (procedure "mportinit" line 440) invoked from within "mportinit" (file "src/dep_map_clean.tcl" line 12) From ryandesign at macports.org Sat Aug 1 15:55:21 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 1 Aug 2009 17:55:21 -0500 Subject: [54765] trunk/dports/sysutils/dpkg/Portfile In-Reply-To: <20090801224716.3A9602289B66@beta.macosforge.org> References: <20090801224716.3A9602289B66@beta.macosforge.org> Message-ID: On Aug 1, 2009, at 17:47, snc at macports.org wrote: > Revision: 54765 > http://trac.macports.org/changeset/54765 > Author: snc at macports.org > Date: 2009-08-01 15:47:15 -0700 (Sat, 01 Aug 2009) > Log Message: > ----------- > update livecheck You also updated the version, but not the checksums. The fetch also fails; there doesn't seem to be a version 1.15.3 (though I see a 1.15.3.1). > Modified Paths: > -------------- > trunk/dports/sysutils/dpkg/Portfile > > Modified: trunk/dports/sysutils/dpkg/Portfile > =================================================================== > --- trunk/dports/sysutils/dpkg/Portfile 2009-08-01 22:45:59 UTC > (rev 54764) > +++ trunk/dports/sysutils/dpkg/Portfile 2009-08-01 22:47:15 UTC > (rev 54765) > @@ -2,8 +2,7 @@ > > PortSystem 1.0 > name dpkg > -version 1.10.28 > -revision 1 > +version 1.15.3 > platforms darwin freebsd > categories sysutils archivers > maintainers landonf > @@ -78,4 +77,4 @@ > > livecheck.check regex > livecheck.url http://ftp.debian.org/debian/pool/main/d/dpkg/ > -livecheck.regex "${name}_(\\d+\\.\\d+(\\.\\d+)?)" > +livecheck.regex "${name}_(\\d+\\.\\d+(\\.\\d+)*)" From jeremy at lavergne.gotdns.org Sat Aug 1 16:14:46 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 1 Aug 2009 19:14:46 -0400 Subject: [54765] trunk/dports/sysutils/dpkg/Portfile In-Reply-To: References: <20090801224716.3A9602289B66@beta.macosforge.org> Message-ID: <3D086E59-3D6B-4131-9FBF-B8B7B8005DB3@lavergne.gotdns.org> Big ol' my bad. Think I got it reversed in time for portindex. On Aug 1, 2009, at 6:55 PM, Ryan Schmidt wrote: > You also updated the version, but not the checksums. The fetch also > fails; there doesn't seem to be a version 1.15.3 (though I see a > 1.15.3.1). -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From toby at macports.org Sat Aug 1 17:33:58 2009 From: toby at macports.org (Toby Peterson) Date: Sat, 1 Aug 2009 17:33:58 -0700 Subject: invalid command name "..." In-Reply-To: <2DB8EE41-B6B5-48A3-86F8-55D251905B51@macports.org> References: <2DB8EE41-B6B5-48A3-86F8-55D251905B51@macports.org> Message-ID: <74c219d30908011733r22cc8b36i3ac556206c1adae3@mail.gmail.com> http://trac.macports.org/ticket/20378 On Sat, Aug 1, 2009 at 15:37, Jeremy Huddleston wrote: > So recent base has been giving me a problem... > > With a fresh checkout, I do: > > # First sanitize your environment to remove any reference to /opt/local etc > svn co https://svn.macosforge.org/repository/macports/trunk/base > cd base > ./configure && gnumake -j3 && sudo make install > ? > ===> making install in src/programs/daemondo > /usr/bin/install -c -o root -g admin -m 555 build/daemondo /opt/local/bin > [ ! -f /opt/local/etc/macports/mp_version ] || rm -vf > /opt/local/etc/macports/mp_version > /usr/bin/install -c -o root -g admin -m 444 setupenv.bash > ?/opt/local/share/macports/ > /usr/bin/tclsh src/upgrade_sources_conf_default.tcl /opt/local > /usr/bin/tclsh src/dep_map_clean.tcl /Library/Tcl > invalid command name "sysctl" > ? ?while executing > "sysctl hw.cpu64bit_capable" > ? ?(procedure "mportinit" line 363) > ? ?invoked from within > "mportinit" > ? ?(file "src/dep_map_clean.tcl" line 12) > make: *** [install] Error 1 > > > The above failure happens on my intel box when installing for i386 or > x86_64. > > > The below failure happens on my Leopard G5 box: > > invalid command name "get_systemconfiguration_proxies" > ? ?while executing > "get_systemconfiguration_proxies" > ? ?(procedure "mportinit" line 440) > ? ?invoked from within > "mportinit" > ? ?(file "src/dep_map_clean.tcl" line 12) > > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From ryandesign at macports.org Sat Aug 1 21:57:41 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 1 Aug 2009 23:57:41 -0500 Subject: [54758] trunk/dports/java/gant/Portfile In-Reply-To: <20090801202258.602BC22893B3@beta.macosforge.org> References: <20090801202258.602BC22893B3@beta.macosforge.org> Message-ID: <56D58375-70EC-41ED-BCF8-329FC828FE5A@macports.org> On Aug 1, 2009, at 15:22, breskeby at macports.org wrote: > + # Symlink gant into the bin directory > + system "cd ${destroot}${prefix}/bin && ln -s ${prefix}/share/java/ > ${name}/bin/gant" It would be better not to use "system" if you just want to create a symlink. Instead try the MacPorts ln command: ln -s ${prefix}/share/java/${name}/bin/gant ${destroot}${prefix}/bin From jeremy at lavergne.gotdns.org Sat Aug 1 22:03:17 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sun, 2 Aug 2009 01:03:17 -0400 Subject: [MacPorts] #20384: hgsvn update to 0.1.7 (with hgpushsvn) In-Reply-To: <066.e4c9a8cf794801dd5323989f358d7a27@macports.org> References: <057.28290b567785c368406d4c934b409a6a@macports.org> <066.e4c9a8cf794801dd5323989f358d7a27@macports.org> Message-ID: <7606AA95-E820-4DB3-953B-06C381B6220B@lavergne.gotdns.org> Thanks. On Aug 2, 2009, at 1:00 AM, MacPorts wrote: > Comment(by ryandesign@?): > > Looks like r54780 updated the checksums but not the version. I > updated the > version to match in r54793. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From kimuraw at macports.org Sat Aug 1 22:51:58 2009 From: kimuraw at macports.org (kimura wataru) Date: Sun, 2 Aug 2009 14:51:58 +0900 Subject: suggestion: split rb-gnome into rb-glib2, rb-pango, ... In-Reply-To: References: <20090728144048351418.81d4ecf1@macports.org> Message-ID: <20090802145158598703.44c2c474@macports.org> Thanks Ryan, I did this at r54785. On Tue, 28 Jul 2009 02:01:45 -0500, Ryan Schmidt wrote: > On Jul 28, 2009, at 00:40, kimura wataru wrote: > >> port:rb-gnome contains many ruby libraries and its dependencies >> are so many. I think that is not convenient such as install >> gnome-session to use ruby/gtk2. >> I'm planning to split rb-gnome into each library (like rb-glib2, >> rb-pango, ...). >> >> http://trac.macports.org/browser/users/kimuraw/rb-gnome > I don't know about ruby software, so I defer to someone who does -- > if you think this makes more sense, by all means please go ahead and > do it. > -- kimura wataru From mnick at macports.org Sun Aug 2 11:31:51 2009 From: mnick at macports.org (Maximilian Nickel) Date: Sun, 2 Aug 2009 20:31:51 +0200 Subject: [54735] trunk/dports/lang In-Reply-To: <2580A0E5-DA3C-4B48-A9DF-F6388ECE9E42@macports.org> References: <20090801124013.C011222863A6@beta.macosforge.org> <2580A0E5-DA3C-4B48-A9DF-F6388ECE9E42@macports.org> Message-ID: <7bad5d350908021131s36c36f99l4700ed6a2bc4d5c@mail.gmail.com> Changed to cmake port group in r54822. Thanks for the tip. Max On Sat, Aug 1, 2009 at 7:34 PM, Ryan Schmidt wrote: > On Aug 1, 2009, at 07:40, mnick at macports.org wrote: > >> Revision: 54735 >> ? ? ? ? ?http://trac.macports.org/changeset/54735 >> Author: ? mnick at macports.org >> Date: ? ? 2009-08-01 05:40:11 -0700 (Sat, 01 Aug 2009) >> Log Message: >> ----------- >> new port: gccxml-devel (since there is no official release since 2004) > > Since this port builds using cmake, have you considered using the cmake > portgroup? It does some more things than you do (universal setup, debug > options, verbosity), and you do some more things than it does (build dir) > but it may still be useful. > > >> Added Paths: >> ----------- >> ? ?trunk/dports/lang/gccxml-devel/ >> ? ?trunk/dports/lang/gccxml-devel/Portfile >> >> Added: trunk/dports/lang/gccxml-devel/Portfile >> =================================================================== >> --- trunk/dports/lang/gccxml-devel/Portfile >> (rev 0) >> +++ trunk/dports/lang/gccxml-devel/Portfile ? ? 2009-08-01 12:40:11 UTC >> (rev 54735) >> @@ -0,0 +1,34 @@ >> +# $Id$ >> + >> +PortSystem 1.0 >> + >> +name ? ? ? ? ? ? ? ? ? gccxml-devel >> +version ? ? ? ? ? ? ? ? ? ? ? ?20090713 >> +categories ? ? ? ? ? ? lang >> +platforms ? ? ? ? ? ? ?darwin >> +maintainers ? ? ? ? ? ?mnick openmaintainer >> +description ? ? ? ? ? ?generates XML description of C++ code >> +long_description ? ? ? generates an XML description of a C++ program from >> GCC's \ >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? internal representation >> + >> +homepage ? ? ? ? ? ? ? http://www.gccxml.org/ >> +fetch.type ? ? ? ? ? ? cvs >> +cvs.root ? ? ? ? ? ? ? :pserver:anoncvs at www.gccxml.org:/cvsroot/GCC_XML >> +cvs.date ? ? ? ? ? ? ? 2009-07-13 >> +cvs.module ? ? ? ? ? ? gccxml >> +worksrcdir ? ? ? ? ? ? gccxml >> + >> +depends_build ?port:cmake >> + >> +post-extract { >> + ? ? ? file mkdir ${workpath}/build >> +} >> + >> +configure { >> + ? ? ? system "cd ${workpath}/build \ >> + ? ? ? ? ? ? ? && cmake ${worksrcpath} >> -DCMAKE_INSTALL_PREFIX:PATH=${prefix}" >> +} >> + >> +build.dir ? ? ? ? ? ? ?${workpath}/build >> +destroot.dir ? ${workpath}/build > > > > From blb at macports.org Sun Aug 2 13:29:37 2009 From: blb at macports.org (Bryan Blackburn) Date: Sun, 2 Aug 2009 14:29:37 -0600 Subject: [54581] trunk/dports/lang In-Reply-To: <20090729200513.387392221F50@beta.macosforge.org> References: <20090729200513.387392221F50@beta.macosforge.org> Message-ID: <20090802202937.GV634@ninagal.withay.com> On Wed, Jul 29, 2009 at 01:05:13PM -0700, ryandesign at macports.org said: > Revision: 54581 > http://trac.macports.org/changeset/54581 > Author: ryandesign at macports.org > Date: 2009-07-29 13:05:12 -0700 (Wed, 29 Jul 2009) > Log Message: > ----------- > php4, php5: add AU mirror Should we add a php mirror group to mirror_sites.tcl, to reduce all that duplication? Bryan > > Modified Paths: > -------------- > trunk/dports/lang/php4/Portfile > trunk/dports/lang/php5/Portfile > > Modified: trunk/dports/lang/php4/Portfile > =================================================================== > --- trunk/dports/lang/php4/Portfile 2009-07-29 20:04:17 UTC (rev 54580) > +++ trunk/dports/lang/php4/Portfile 2009-07-29 20:05:12 UTC (rev 54581) > @@ -32,7 +32,8 @@ > http://gr.php.net/distributions/ \ > http://fr.php.net/distributions/ \ > http://es.php.net/distributions/ \ > - http://se.php.net/distributions/ > + http://se.php.net/distributions/ \ > + http://au.php.net/distributions/ > > checksums \ > md5 2e3b2a0e27f10cb84fd00e5ecd7a1880 \ > > Modified: trunk/dports/lang/php5/Portfile > =================================================================== > --- trunk/dports/lang/php5/Portfile 2009-07-29 20:04:17 UTC (rev 54580) > +++ trunk/dports/lang/php5/Portfile 2009-07-29 20:05:12 UTC (rev 54581) > @@ -33,7 +33,8 @@ > http://gr.php.net/distributions/ \ > http://fr.php.net/distributions/ \ > http://es.php.net/distributions/ \ > - http://se.php.net/distributions/ > + http://se.php.net/distributions/ \ > + http://au.php.net/distributions/ > > checksums \ > md5 846760cd655c98dfd86d6d97c3d964b0 \ From ryandesign at macports.org Sun Aug 2 14:09:47 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 2 Aug 2009 16:09:47 -0500 Subject: [54828] trunk/dports/python/py25-lint/Portfile In-Reply-To: <20090802205126.B54F52299014@beta.macosforge.org> References: <20090802205126.B54F52299014@beta.macosforge.org> Message-ID: <1AFA236A-C802-4E96-96FA-CC92E3096BB4@macports.org> On Aug 2, 2009, at 15:51, dh at macports.org wrote: > Revision: 54828 > http://trac.macports.org/changeset/54828 > Author: dh at macports.org > Date: 2009-08-02 13:51:26 -0700 (Sun, 02 Aug 2009) > Log Message: > ----------- > Comment changes only Don't change it now, but for future reference, you only increase the revision if the files installed by the port will change, or if the list of the port's library or runtime dependencies have changed. > Modified Paths: > -------------- > trunk/dports/python/py25-lint/Portfile > > Modified: trunk/dports/python/py25-lint/Portfile > =================================================================== > --- trunk/dports/python/py25-lint/Portfile 2009-08-02 20:44:29 UTC > (rev 54827) > +++ trunk/dports/python/py25-lint/Portfile 2009-08-02 20:51:26 UTC > (rev 54828) > @@ -6,6 +6,7 @@ > > name py25-lint > version 0.18.0 > +revision 1 > categories-append devel > maintainers dh openmaintainer > description Error (and style) checking for python > @@ -41,7 +42,7 @@ > ${destroot}${prefix}/share/doc/${name} > file delete ${destroot}${python.pkgd}/logilab/__init__.py > > - # macports 1.7 does not seem to have the ${python} variables > for python25 port group > + # there is no python.prefix variable for python25 and python24 > portgroups > foreach binfile {epylint pylint pylint-gui pyreverse symilar} { > file rename ${destroot}${prefix}/bin/${binfile} ${destroot} > ${prefix}/bin/${binfile}-${python.branch} > } From jeremyhu at macports.org Sun Aug 2 23:35:04 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sun, 2 Aug 2009 23:35:04 -0700 Subject: muniversal and use_autoconf Message-ID: It looks like updated configure scripts (via use_autoconf) aren't getting propagated to the arch-specific dir. Has something changed recently in recent base+muniversal that might be affecting this, or is it an outstanding issue? ~/src/macports-trunk/dports/audio/cdparanoia $ ls -l work/cdparanoia- III-10.2*/configure -rwxrwxr-x 1 root wheel 176456 Aug 16 2006 work/cdparanoia- III-10.2-x86_64/configure -rwxrwxr-x 1 root wheel 146246 Aug 2 23:25 work/cdparanoia- III-10.2/configure ~/src/macports-trunk/dports/audio/cdparanoia $ grep autoconf Portfile depends_build port:autoconf use_autoconf yes I filed a ticket since I couldn't find an existing one... http://trac.macports.org/ticket/20534 From jmr at macports.org Mon Aug 3 00:42:08 2009 From: jmr at macports.org (Joshua Root) Date: Mon, 03 Aug 2009 17:42:08 +1000 Subject: muniversal and use_autoconf In-Reply-To: References: Message-ID: <4A7694D0.8020305@macports.org> On 2009-8-3 16:35, Jeremy Huddleston wrote: > It looks like updated configure scripts (via use_autoconf) aren't > getting propagated to the arch-specific dir. Has something changed > recently in recent base+muniversal that might be affecting this, or is > it an outstanding issue? > > ~/src/macports-trunk/dports/audio/cdparanoia $ ls -l > work/cdparanoia-III-10.2*/configure > -rwxrwxr-x 1 root wheel 176456 Aug 16 2006 > work/cdparanoia-III-10.2-x86_64/configure > -rwxrwxr-x 1 root wheel 146246 Aug 2 23:25 > work/cdparanoia-III-10.2/configure > > ~/src/macports-trunk/dports/audio/cdparanoia $ grep autoconf Portfile > depends_build port:autoconf > use_autoconf yes > > > I filed a ticket since I couldn't find an existing one... > http://trac.macports.org/ticket/20534 The auto* commands get run in configure_main, so if you override the configure phase (as muniversal does), that never happens unless you do it yourself. - Josh From jameskyle at macports.org Mon Aug 3 14:28:48 2009 From: jameskyle at macports.org (James Kyle) Date: Mon, 3 Aug 2009 14:28:48 -0700 Subject: [MacPorts] #20496: permissions are set to root during install phase despite destroot permissions In-Reply-To: <067.d7e1e83aa7f07068f854fbd6c6f04547@macports.org> References: <058.8fa9b72308200ffb05857889fc7dede9@macports.org> <067.d7e1e83aa7f07068f854fbd6c6f04547@macports.org> Message-ID: Sure, I'll have to look at it when I get home. I'm doing one more clean install just to make sure I didn't miss something. -james On Aug 3, 2009, at 1:40 PM, MacPorts wrote: > #20496: permissions are set to root during install phase despite > destroot > permissions > ------------------------------------ > +--------------------------------------- > Reporter: jameskyle@? | Owner: macports-tickets@? > Type: defect | Status: new > Priority: Normal | Milestone: MacPorts 1.8.0 > Component: base | Version: 1.8.0 > Keywords: | Port: > ------------------------------------ > +--------------------------------------- > > Comment(by jmr@?): > > I can't reproduce on latest trunk, with a simple test port that > creates > nested directories in ${prefix}/var owned by me. Are you sure the top > level dir wasn't already present? > > -- > Ticket URL: > MacPorts > Ports system for Mac OS From ryandesign at macports.org Tue Aug 4 16:33:50 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 4 Aug 2009 18:33:50 -0500 Subject: [54949] trunk/dports/science In-Reply-To: <20090804231850.6779622B0366@beta.macosforge.org> References: <20090804231850.6779622B0366@beta.macosforge.org> Message-ID: On Aug 4, 2009, at 18:18, mnick at macports.org wrote: > Revision: 54949 > http://trac.macports.org/changeset/54949 > Author: mnick at macports.org > Date: 2009-08-04 16:18:49 -0700 (Tue, 04 Aug 2009) > Log Message: > ----------- > new port: libANN, version 1.1.1 > > Added Paths: > ----------- > trunk/dports/science/libANN/ > trunk/dports/science/libANN/Portfile [snip] > +destroot { > + file copy ${worksrcpath}/include/ANN ${destroot}/${prefix}/include > + file copy ${worksrcpath}/lib/libANN.a ${destroot}/${prefix}/lib > + eval file copy [glob ${worksrcpath}/bin/*] ${destroot}/${prefix}/bin > + file mkdir ${destroot}/${prefix}/share/doc > + file copy ${worksrcpath}/doc ${destroot}/${prefix}/share/doc/libANN > +} You should remove the slash between ${destroot} and ${prefix}; $ {prefix} always begins with a slash already. From ryandesign at macports.org Tue Aug 4 17:10:19 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 4 Aug 2009 19:10:19 -0500 Subject: backuppc In-Reply-To: <20090803192817.2937022A2BEE@beta.macosforge.org> References: <20090803192817.2937022A2BEE@beta.macosforge.org> Message-ID: <3FDCEC5D-6731-4B4F-88C8-B773AEF141A6@macports.org> A few comments on backuppc: On Aug 3, 2009, at 14:28, jameskyle at macports.org wrote: > Revision: 54884 > http://trac.macports.org/changeset/54884 > Author: jameskyle at macports.org > Date: 2009-08-03 12:28:16 -0700 (Mon, 03 Aug 2009) > Log Message: > ----------- > Initial commit. > backuppc user creation completed. > +master_sites sourceforge:${name} Note that you can simplify this to just "master_sites sourceforge" > +configure { > + if {[existsgroup "backuppc"]} { > + ui_debug "Found backuppc group." > + } else { > + ui_debug "Could not find backuppc group." > + ui_debug "Creating backuppc group." > + set gid [nextgid] > + ui_debug "gid: $gid" > + if {[catch {addgroup "backuppc" gid=${gid}}]} { > + return -code error "Failed to create backuppc group" > + } > + } > + > + ui_debug "Checking for backuppc user" > + if { [existsuser "backuppc"] } { > + ui_debug "Found backuppc user." > + } else { > + ui_debug "Could not find backuppc user." > + ui_debug "Creating backuppc user." > + set uid [nextuid] > + ui_debug "uid: $uid" > + if {[catch {adduser "backuppc" uid=${uid} gid=[existsgroup > backuppc]}]} { > + return -code error "Failed to create backuppc user" > + } > + } > +} I imagine this can be greatly simplified. Taking an example from the mysql5-server port, I think all you need is: configure { addgroup backuppc set gid [existsgroup backuppc] adduser backuppc gid=${gid} realname=BackupPC } I would be surprised if the adduser and addgroup functions in MacPorts base did not already have adequate error handling, and if they don't, then that's where it would need to be fixed, not in individual ports. On Aug 3, 2009, at 14:28, jameskyle at macports.org wrote: > Revision: 54885 > http://trac.macports.org/changeset/54885 > Author: jameskyle at macports.org > Date: 2009-08-03 12:28:18 -0700 (Mon, 03 Aug 2009) > Log Message: > ----------- > Added the BackupPC launchd script. > First working full install. > distfiles BackupPC-${version}.tar.gz [snip] > +worksrcdir BackupPC-${version} Note that these two lines can be simplified to "distname BackupPC-$ {version}" > +destroot.violate_mtree yes What violates the mtree? Is there a way to make it comply with the mtree? Ports should not violate the mtree unless they absolutely have to. > +destroot { > + system "cd ${worksrcpath} && ${prefix}/bin/perl5.8 > configure.pl ${configure.args}" Is there a reason why you're running the configure script in the destroot phase instead of in the configure phase? Finally, note that "port lint" shows that the port is missing the required "homepage" variable. From bob.spamnot at gmail.com Wed Aug 5 07:30:12 2009 From: bob.spamnot at gmail.com (Bob) Date: Wed, 5 Aug 2009 08:30:12 -0600 Subject: emacs 23.1 Message-ID: <760710620908050730y79546760x7069c8125e1c18fb@mail.gmail.com> Emacs 23.1 was released a week ago. I'm wondering when the emacs port will be ungraded to 23.1. I would think that it will only take minor modifications to the port file. Perhaps the present emacs port should be renamed emacs-22 for people who want to keep using that one. I emailed the maintainer but have not heard back. Thanks, Bob From macsforever2000 at macports.org Wed Aug 5 08:20:19 2009 From: macsforever2000 at macports.org (Frank Schima) Date: Wed, 5 Aug 2009 09:20:19 -0600 Subject: emacs 23.1 In-Reply-To: <760710620908050730y79546760x7069c8125e1c18fb@mail.gmail.com> References: <760710620908050730y79546760x7069c8125e1c18fb@mail.gmail.com> Message-ID: <506CF5B1-AD5F-44DD-8DF4-9CFFBA00C8C8@macports.org> On Aug 5, 2009, at 8:30 AM, Bob wrote: > Emacs 23.1 was released a week ago. I'm wondering when the emacs port > will be ungraded to 23.1. I would think that it will only take minor > modifications to the port file. Perhaps the present emacs port should > be renamed emacs-22 for people who want to keep using that one. I > emailed the maintainer but have not heard back. There are a few tickets related to this already. [1] [2] You should file a new ticket requesting emacs22 if you want that. [1] [2] Cheers! -Frank From bob.spamnot at gmail.com Wed Aug 5 08:55:25 2009 From: bob.spamnot at gmail.com (Bob) Date: Wed, 5 Aug 2009 09:55:25 -0600 Subject: emacs 23.1 In-Reply-To: <506CF5B1-AD5F-44DD-8DF4-9CFFBA00C8C8@macports.org> References: <760710620908050730y79546760x7069c8125e1c18fb@mail.gmail.com> <506CF5B1-AD5F-44DD-8DF4-9CFFBA00C8C8@macports.org> Message-ID: <760710620908050855u7d5c19cl3c916eabfb7b1293@mail.gmail.com> OK. Thanks. I added to the those tickets. I don't care about a emacs-22 version but imagine that some people might (especially when their .emacs doesn't work with 23.1 and they don't want to fix it, they can just install the emacs-22 port and be back in business). Bob On Wed, Aug 5, 2009 at 9:20 AM, Frank Schima wrote: > > On Aug 5, 2009, at 8:30 AM, Bob wrote: > >> Emacs 23.1 was released a week ago. ?I'm wondering when the emacs port >> will be ungraded to 23.1. ?I would think that it will only take minor >> modifications to the port file. ?Perhaps the present emacs port should >> be renamed emacs-22 for people who want to keep using that one. ?I >> emailed the maintainer but have not heard back. > > > There are a few tickets related to this already. [1] [2] > > You should file a new ticket requesting emacs22 if you want that. > > > [1] > [2] > > > Cheers! > -Frank > From msavory1 at nzbox.com Wed Aug 5 10:23:46 2009 From: msavory1 at nzbox.com (Mike Savory) Date: Wed, 5 Aug 2009 10:23:46 -0700 Subject: Ticket #18156: scapy not installing new version In-Reply-To: <760710620908050855u7d5c19cl3c916eabfb7b1293@mail.gmail.com> References: <760710620908050730y79546760x7069c8125e1c18fb@mail.gmail.com> <506CF5B1-AD5F-44DD-8DF4-9CFFBA00C8C8@macports.org> <760710620908050855u7d5c19cl3c916eabfb7b1293@mail.gmail.com> Message-ID: I don't have privilege to re-open this ticket so it is still showing as closed Can a Python guru have a look at this please Regards Mike From jeremy at lavergne.gotdns.org Wed Aug 5 11:23:37 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 5 Aug 2009 14:23:37 -0400 Subject: emacs 23.1 In-Reply-To: <760710620908050855u7d5c19cl3c916eabfb7b1293@mail.gmail.com> References: <760710620908050730y79546760x7069c8125e1c18fb@mail.gmail.com> <506CF5B1-AD5F-44DD-8DF4-9CFFBA00C8C8@macports.org> <760710620908050855u7d5c19cl3c916eabfb7b1293@mail.gmail.com> Message-ID: They could also choose to not upgrade -- no one forces them. On Aug 5, 2009, at 11:55 AM, Bob wrote: > I don't care about a emacs-22 version but imagine that some people > might (especially when their .emacs doesn't work with 23.1 and they > don't want to fix it, they can just install the emacs-22 port and be > back in business). -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From vincent-opdarw at vinc17.org Wed Aug 5 12:50:06 2009 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Wed, 5 Aug 2009 21:50:06 +0200 Subject: emacs 23.1 In-Reply-To: References: <760710620908050730y79546760x7069c8125e1c18fb@mail.gmail.com> <506CF5B1-AD5F-44DD-8DF4-9CFFBA00C8C8@macports.org> <760710620908050855u7d5c19cl3c916eabfb7b1293@mail.gmail.com> Message-ID: <20090805195006.GO18655@prunille.vinc17.org> On 2009-08-05 14:23:37 -0400, Jeremy Lavergne wrote: > They could also choose to not upgrade -- no one forces them. But it would be nice if they could be installed side by side, like under Debian. It's difficult to guess whether one would find annoying bugs in the new version during the following months. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From jeremy at lavergne.gotdns.org Wed Aug 5 12:53:17 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 5 Aug 2009 15:53:17 -0400 Subject: emacs 23.1 In-Reply-To: <20090805195006.GO18655@prunille.vinc17.org> References: <760710620908050730y79546760x7069c8125e1c18fb@mail.gmail.com> <506CF5B1-AD5F-44DD-8DF4-9CFFBA00C8C8@macports.org> <760710620908050855u7d5c19cl3c916eabfb7b1293@mail.gmail.com> <20090805195006.GO18655@prunille.vinc17.org> Message-ID: I believe one can deactivate emacs 22 and install emacs 23. If a revert is necessary, deactivate the new version and reactivate the old one. No need for an extra port that will only be around for a version. On Aug 5, 2009, at 3:50 PM, Vincent Lefevre wrote: > But it would be nice if they could be installed side by side, > like under Debian. It's difficult to guess whether one would find > annoying bugs in the new version during the following months. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From vincent-opdarw at vinc17.org Wed Aug 5 14:51:21 2009 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Wed, 5 Aug 2009 23:51:21 +0200 Subject: emacs 23.1 In-Reply-To: References: <760710620908050730y79546760x7069c8125e1c18fb@mail.gmail.com> <506CF5B1-AD5F-44DD-8DF4-9CFFBA00C8C8@macports.org> <760710620908050855u7d5c19cl3c916eabfb7b1293@mail.gmail.com> <20090805195006.GO18655@prunille.vinc17.org> Message-ID: <20090805215121.GP18655@prunille.vinc17.org> On 2009-08-05 15:53:17 -0400, Jeremy Lavergne wrote: > I believe one can deactivate emacs 22 and install emacs 23. If a > revert is necessary, deactivate the new version and reactivate the > old one. No need for an extra port that will only be around for a > version. I meant *without having to deactivate a port*. Deactivating and reactivating a port takes time, if one needs to use both. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From jeremy at lavergne.gotdns.org Wed Aug 5 16:19:45 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 5 Aug 2009 19:19:45 -0400 Subject: emacs 23.1 In-Reply-To: <20090805215121.GP18655@prunille.vinc17.org> References: <760710620908050730y79546760x7069c8125e1c18fb@mail.gmail.com> <506CF5B1-AD5F-44DD-8DF4-9CFFBA00C8C8@macports.org> <760710620908050855u7d5c19cl3c916eabfb7b1293@mail.gmail.com> <20090805195006.GO18655@prunille.vinc17.org> <20090805215121.GP18655@prunille.vinc17.org> Message-ID: If they both produce the binary filed named "emacs" then you're going to have problems any ways. On Aug 5, 2009, at 5:51 PM, Vincent Lefevre wrote: > I meant *without having to deactivate a port*. Deactivating and > reactivating a port takes time, if one needs to use both. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From ryandesign at macports.org Wed Aug 5 19:12:54 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 5 Aug 2009 21:12:54 -0500 Subject: [54989] trunk/dports/python In-Reply-To: <20090805171201.58E6222B79A7@beta.macosforge.org> References: <20090805171201.58E6222B79A7@beta.macosforge.org> Message-ID: <26F2EBFC-9C9D-405E-8FA2-A954A8DE7E0F@macports.org> On Aug 5, 2009, at 12:12, mnick at macports.org wrote: > +post-destroot { > + # Every scikit installs identical scikits/__init__.py. To > avoid conflicts > + # install only if not already present > + if {[file exists ${python.pkgd}/scikits/__init__.py]} { > + file delete ${destroot}${python.pkgd}/scikits/__init__.py > + } > +} Hmm, the problem here is that this introduces unstated dependencies between these ports. Assuming the __init__.py file is required by both ports, consider what happens if you install py26-scikits- audiolab (will install __init__.py), then install py26-scikits-ann (will not install __init__.py because it sees it's already there), and then uninstall py26-scikits-audiolab (will remove __init__.py), presumably leaving py26-scikits-ann nonfunctional. And the same situation happens if you interchange the port names in the previous sentence. I'm not sure how to handle this better, though. From mnick at macports.org Wed Aug 5 19:20:17 2009 From: mnick at macports.org (Maximilian Nickel) Date: Thu, 6 Aug 2009 04:20:17 +0200 Subject: [54989] trunk/dports/python In-Reply-To: <26F2EBFC-9C9D-405E-8FA2-A954A8DE7E0F@macports.org> References: <20090805171201.58E6222B79A7@beta.macosforge.org> <26F2EBFC-9C9D-405E-8FA2-A954A8DE7E0F@macports.org> Message-ID: <7bad5d350908051920o66794bbex4e963be577d0262b@mail.gmail.com> You are right, i forgot the uninstall case. I probably could create a py26-scikits-module port that only installs the common __init__.py file and that all py26-scikits-* depend upon. On Thu, Aug 6, 2009 at 4:12 AM, Ryan Schmidt wrote: > > On Aug 5, 2009, at 12:12, mnick at macports.org wrote: > >> +post-destroot { >> + ? ?# Every scikit installs identical scikits/__init__.py. To avoid >> conflicts >> + ? ?# install only if not already present >> + ? ?if {[file exists ${python.pkgd}/scikits/__init__.py]} { >> + ? ? ? ?file delete ${destroot}${python.pkgd}/scikits/__init__.py >> + ? ?} >> +} > > Hmm, the problem here is that this introduces unstated dependencies between > these ports. Assuming the __init__.py file is required by both ports, > consider what happens if you install py26-scikits-audiolab (will install > __init__.py), then install py26-scikits-ann (will not install __init__.py > because it sees it's already there), and then uninstall > py26-scikits-audiolab (will remove __init__.py), presumably leaving > py26-scikits-ann nonfunctional. And the same situation happens if you > interchange the port names in the previous sentence. > > I'm not sure how to handle this better, though. > > > From ryandesign at macports.org Wed Aug 5 20:24:00 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 5 Aug 2009 22:24:00 -0500 Subject: [55009] trunk/dports/devel In-Reply-To: <20090806024640.0376422BF785@beta.macosforge.org> References: <20090806024640.0376422BF785@beta.macosforge.org> Message-ID: <607F1D71-E89A-428D-BD1B-2C43304FBE09@macports.org> On Aug 5, 2009, at 21:46, snc at macports.org wrote: > Revision: 55009 > http://trac.macports.org/changeset/55009 > Author: snc at macports.org > Date: 2009-08-05 19:46:39 -0700 (Wed, 05 Aug 2009) > Log Message: > ----------- > created libftd2xx, ticket #20565 > +destroot { > + xinstall -o root -g wheel -d ${destroot}${prefix}/lib > + xinstall -o root -g wheel ${worksrcpath}/D2XX/bin/${name}.$ > {version}.dylib ${destroot}${prefix}/lib > + xinstall -o root -g wheel -d ${destroot}${prefix}/include > + xinstall -o root -g wheel ${worksrcpath}/D2XX/bin/ftd2xx.h $ > {destroot}${prefix}/include > + xinstall -o root -g wheel ${worksrcpath}/D2XX/Samples/ > WinTypes.h ${destroot}${prefix}/include > +} There isn't any reason to specify the user and group; just omit them and let MacPorts use the current user and group. You don't need to create the directories ${destroot}${prefix}/lib or $ {destroot}${prefix}/include; MacPorts does this for you. You can combine the two xinstalls that install to the include directory. I think you probably also want to add -m 644 to this, otherwise I think the default is for the files to get 755 permissions, which is not appropriate for header files. > +post-destroot { > + system "ln -sf ${name}.${version}.dylib ${destroot}${prefix}/ > lib/${name}.dylib" You shouldn't use "system" just to make a symlink. MacPorts has an "ln" procedure you can use for this. You don't need the -f flag because there's nothing that needs to be forced, no existing file in the destroot that needs to be overwritten. > + system "install_name_tool -id ${prefix}/lib/${name}.$ > {version}.dylib ${destroot}${prefix}/lib/${name}.${version}.dylib" > +} You can combine the post-destroot stuff into the destroot. So the final destroot would look like: destroot { xinstall ${worksrcpath}/D2XX/bin/${name}.${version}.dylib $ {destroot}${prefix}/lib xinstall -m 644 -W ${worksrcpath}/D2XX bin/ftd2xx.h Samples/ WinTypes.h ${destroot}${prefix}/include ln -s ${name}.${version}.dylib ${destroot}${prefix}/lib/$ {name}.dylib system "install_name_tool -id ${prefix}/lib/${name}.$ {version}.dylib ${destroot}${prefix}/lib/${name}.${version}.dylib" } From ryandesign at macports.org Wed Aug 5 20:29:39 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 5 Aug 2009 22:29:39 -0500 Subject: [54989] trunk/dports/python In-Reply-To: <7bad5d350908051920o66794bbex4e963be577d0262b@mail.gmail.com> References: <20090805171201.58E6222B79A7@beta.macosforge.org> <26F2EBFC-9C9D-405E-8FA2-A954A8DE7E0F@macports.org> <7bad5d350908051920o66794bbex4e963be577d0262b@mail.gmail.com> Message-ID: On Aug 5, 2009, at 21:20, Maximilian Nickel wrote: > You are right, i forgot the uninstall case. > I probably could create a py26-scikits-module port that only installs > the common __init__.py file and that all py26-scikits-* depend upon. Yeah, that would work. From ryandesign at macports.org Thu Aug 6 02:55:05 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 6 Aug 2009 04:55:05 -0500 Subject: [55042] trunk/dports/science/vis5d/Portfile In-Reply-To: <20090806094731.BD03722C7F01@beta.macosforge.org> References: <20090806094731.BD03722C7F01@beta.macosforge.org> Message-ID: <3DF795AB-37FC-4F9F-AEFA-A3B6B5458196@macports.org> On Aug 6, 2009, at 04:47, takeshi at macports.org wrote: > Revision: 55042 > http://trac.macports.org/changeset/55042 > Author: takeshi at macports.org > Date: 2009-08-06 02:47:31 -0700 (Thu, 06 Aug 2009) > Log Message: > ----------- > vis5d: fixed a problem finding -lGL on Tiger Shouldn't you be using ${prefix} for X11 on all platforms now? > Modified Paths: > -------------- > trunk/dports/science/vis5d/Portfile > > Modified: trunk/dports/science/vis5d/Portfile > =================================================================== > --- trunk/dports/science/vis5d/Portfile 2009-08-06 09:41:03 UTC > (rev 55041) > +++ trunk/dports/science/vis5d/Portfile 2009-08-06 09:47:31 UTC > (rev 55042) > @@ -68,7 +68,7 @@ > } > > #configure.env-append PTHREAD_LIBS=-lpthread > -configure.cppflags-append -I/usr/X11/include > +configure.cppflags-append -I/usr/X11R6/include > configure.args -disable-fortran \ > -disable-dependency-tracing \ > --x-includes=/usr/X11/include \ From raimue at macports.org Thu Aug 6 18:02:10 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Fri, 07 Aug 2009 03:02:10 +0200 Subject: Subject: New committers: avsm and scantor Message-ID: <4A7B7D12.9060303@macports.org> Please join us in welcoming the following new MacPorts committers: - Anil Madhavapeddy (avsm) - Scott Cantor (scantor) 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 jameskyle at macports.org Thu Aug 6 18:47:55 2009 From: jameskyle at macports.org (James Kyle) Date: Thu, 6 Aug 2009 18:47:55 -0700 Subject: backuppc In-Reply-To: <3FDCEC5D-6731-4B4F-88C8-B773AEF141A6@macports.org> References: <20090803192817.2937022A2BEE@beta.macosforge.org> <3FDCEC5D-6731-4B4F-88C8-B773AEF141A6@macports.org> Message-ID: On Aug 4, 2009, at 5:10 PM, Ryan Schmidt wrote: > A few comments on backuppc: > > > On Aug 3, 2009, at 14:28, jameskyle at macports.org wrote: > >> Revision: 54884 >> http://trac.macports.org/changeset/54884 >> Author: jameskyle at macports.org >> Date: 2009-08-03 12:28:16 -0700 (Mon, 03 Aug 2009) >> Log Message: >> ----------- >> Initial commit. >> backuppc user creation completed. > > >> +master_sites sourceforge:${name} > > Note that you can simplify this to just "master_sites sourceforge" Done. > > >> +configure { >> + if {[existsgroup "backuppc"]} { >> + ui_debug "Found backuppc group." >> + } else { >> + ui_debug "Could not find backuppc group." >> + ui_debug "Creating backuppc group." >> + set gid [nextgid] >> + ui_debug "gid: $gid" >> + if {[catch {addgroup "backuppc" gid=${gid}}]} { >> + return -code error "Failed to create backuppc group" >> + } >> + } >> + >> + ui_debug "Checking for backuppc user" >> + if { [existsuser "backuppc"] } { >> + ui_debug "Found backuppc user." >> + } else { >> + ui_debug "Could not find backuppc user." >> + ui_debug "Creating backuppc user." >> + set uid [nextuid] >> + ui_debug "uid: $uid" >> + if {[catch {adduser "backuppc" uid=${uid} gid=[existsgroup >> backuppc]}]} { >> + return -code error "Failed to create backuppc user" >> + } >> + } >> +} > > > I imagine this can be greatly simplified. Taking an example from the > mysql5-server port, I think all you need is: > > configure { > addgroup backuppc > set gid [existsgroup backuppc] > adduser backuppc gid=${gid} realname=BackupPC > } > > I would be surprised if the adduser and addgroup functions in > MacPorts base did not already have adequate error handling, and if > they don't, then that's where it would need to be fixed, not in > individual ports. > Done > > On Aug 3, 2009, at 14:28, jameskyle at macports.org wrote: > >> Revision: 54885 >> http://trac.macports.org/changeset/54885 >> Author: jameskyle at macports.org >> Date: 2009-08-03 12:28:18 -0700 (Mon, 03 Aug 2009) >> Log Message: >> ----------- >> Added the BackupPC launchd script. >> First working full install. > > >> distfiles BackupPC-${version}.tar.gz > [snip] >> +worksrcdir BackupPC-${version} > > Note that these two lines can be simplified to "distname BackupPC-$ > {version}" Done. > >> +destroot.violate_mtree yes > > What violates the mtree? Is there a way to make it comply with the > mtree? Ports should not violate the mtree unless they absolutely > have to. It installs files into /Library/LaunchDaemons. At first it also installed files into ${prefix}/apach2..but I believe I've taken care of this. > > >> +destroot { >> + system "cd ${worksrcpath} && ${prefix}/bin/perl5.8 >> configure.pl ${configure.args}" > > Is there a reason why you're running the configure script in the > destroot phase instead of in the configure phase? The configure.pl also installs into the destroot. > > > Finally, note that "port lint" shows that the port is missing the > required "homepage" variable. fixed Link checks out now. From ryandesign at macports.org Thu Aug 6 19:16:15 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 6 Aug 2009 21:16:15 -0500 Subject: [55062] trunk/dports/databases In-Reply-To: <20090806132351.E282022CB86B@beta.macosforge.org> References: <20090806132351.E282022CB86B@beta.macosforge.org> Message-ID: On Aug 6, 2009, at 08:23, snc at macports.org wrote: > Revision: 55062 > http://trac.macports.org/changeset/55062 > Author: snc at macports.org > Date: 2009-08-06 06:23:51 -0700 (Thu, 06 Aug 2009) > Log Message: > ----------- > created tokyocabinet-clj, ticket #19552. > > Added Paths: > ----------- > trunk/dports/databases/tokyocabinet-clj/ > trunk/dports/databases/tokyocabinet-clj/Portfile > > Added: trunk/dports/databases/tokyocabinet-clj/Portfile > =================================================================== > --- trunk/dports/databases/tokyocabinet-clj/ > Portfile (rev 0) > +++ trunk/dports/databases/tokyocabinet-clj/Portfile 2009-08-06 > 13:23:51 UTC (rev 55062) > @@ -0,0 +1,39 @@ > +# -*- coding: utf-8; mode: tcl; tab-width: 4; truncate-lines: t; > indent-tabs-mode: nil; c-basic-offset: 4 -*- > vim:fenc=utf-8:et:sw=4:ts=4:sts=4 > +# $Id$ > + > +PortSystem 1.0 > + > +name tokyocabinet-clj > +version 20090505 > +categories databases java > +maintainers ime > +description Java API for Tokyo Cabinet, a modern DBM > +long_description Clojure is a dynamic programming language for > the JVM. > + > +homepage http://github.com/jmtulloss/tokyo-cabinet-clj/ > tree/master > +platforms darwin > +depends_build port:tokyocabinet port:tokyocabinet-java > + > +fetch.type git > +git.url git://github.com/jmtulloss/tokyo-cabinet-clj.git > +git.branch cfab6104b9f3635f97968fda526218c8a706954d > + > +variant universal {} > + > +## configure ## > +use_configure no > + > +## build ## > +build.cmd ant > +build.target jar > + > +destroot { > + set javadir ${destroot}${prefix}/share/java > + set clojuredir ${javadir}/clojure/lib > + set jarfile tokyo-cabinet.jar > + set destfile ${clojuredir}/${jarfile} > + > + xinstall -m 0755 -d ${javadir} > + xinstall -m 0755 -d ${clojuredir} > + xinstall -m 0644 -W ${worksrcpath} ${jarfile} ${destfile} > +} > > > Property changes on: trunk/dports/databases/tokyocabinet-clj/Portfile > ___________________________________________________________________ > Added: svn:keywords > + Id > Added: svn:eol-style > + native > _______________________________________________ > macports-changes mailing list > macports-changes at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes From ryandesign at macports.org Thu Aug 6 19:18:52 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 6 Aug 2009 21:18:52 -0500 Subject: [55062] trunk/dports/databases In-Reply-To: <20090806132351.E282022CB86B@beta.macosforge.org> References: <20090806132351.E282022CB86B@beta.macosforge.org> Message-ID: On Aug 6, 2009, at 08:23, snc at macports.org wrote: > Revision: 55062 > http://trac.macports.org/changeset/55062 > Author: snc at macports.org > Date: 2009-08-06 06:23:51 -0700 (Thu, 06 Aug 2009) > Log Message: > ----------- > created tokyocabinet-clj, ticket #19552. > > Added Paths: > ----------- > trunk/dports/databases/tokyocabinet-clj/ > trunk/dports/databases/tokyocabinet-clj/Portfile > +maintainers ime The MacPortsDevelopers wiki page does not list a committer called "ime". Should this be changed to Ian's Gmail address? > +variant universal {} What's the story with this line? From ryandesign at macports.org Thu Aug 6 19:22:37 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 6 Aug 2009 21:22:37 -0500 Subject: backuppc In-Reply-To: References: <20090803192817.2937022A2BEE@beta.macosforge.org> <3FDCEC5D-6731-4B4F-88C8-B773AEF141A6@macports.org> Message-ID: On Aug 6, 2009, at 20:47, James Kyle wrote: > On Aug 4, 2009, at 5:10 PM, Ryan Schmidt wrote: > >>> +destroot.violate_mtree yes >> >> What violates the mtree? Is there a way to make it comply with the >> mtree? Ports should not violate the mtree unless they absolutely >> have to. > > It installs files into /Library/LaunchDaemons. Any port that uses the startupitem keywords would install files in there too. I think this is ok and not considered to be an mtree violation. If you remove "destroot.violate_mtree yes" now does it still complain about mtree violations? > At first it also installed files into ${prefix}/apach2..but I > believe I've taken care of this. >>> +destroot { >>> + system "cd ${worksrcpath} && ${prefix}/bin/perl5.8 >>> configure.pl ${configure.args}" >> >> Is there a reason why you're running the configure script in the >> destroot phase instead of in the configure phase? > > The configure.pl also installs into the destroot. Ok. From ryandesign at macports.org Thu Aug 6 21:01:42 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 6 Aug 2009 23:01:42 -0500 Subject: [55140] trunk/dports/gnome/gstreamer/Portfile In-Reply-To: <20090807024603.A0A0322DAF6B@beta.macosforge.org> References: <20090807024603.A0A0322DAF6B@beta.macosforge.org> Message-ID: <00C1DC34-0F9E-4D0B-85F7-C7F75492F548@macports.org> On Aug 6, 2009, at 21:46, rmsfisher at macports.org wrote: > Revision: 55140 > http://trac.macports.org/changeset/55140 > Author: rmsfisher at macports.org > Date: 2009-08-06 19:46:03 -0700 (Thu, 06 Aug 2009) > Log Message: > ----------- > gnome/gstreamer updated version, checksum, and dependencies, > revised ui_msg > depends_build \ > port:gzip \ > port:m4 \ > - path:bin/perl:perl5 \ > + port:perl5 \ > port:pkgconfig > depends_lib \ > port:bison \ > port:flex \ > port:gettext \ > - path:lib/pkgconfig/glib-2.0.pc:glib2 \ > + port:glib2 \ > port:libiconv \ > port:libxml2 \ > port:zlib You should put these dependencies back the way they were. The purpose of writing the perl5 dependency like that was so that perl5.8 (and maybe perl5.10?) could also satisfy the dependency. With the glib2 dependency, it allowed glib2-devel to satisfy it. See r41606 and r38077 (and r41808). From jmr at macports.org Thu Aug 6 21:15:55 2009 From: jmr at macports.org (Joshua Root) Date: Fri, 07 Aug 2009 14:15:55 +1000 Subject: [55148] trunk/dports/science/vis5d/Portfile In-Reply-To: <20090807035747.78CBF22DBCB9@beta.macosforge.org> References: <20090807035747.78CBF22DBCB9@beta.macosforge.org> Message-ID: <4A7BAA7B.4000400@macports.org> On 2031-9-15 05:59, takeshi at macports.org wrote: > Revision: 55148 > http://trac.macports.org/changeset/55148 > Author: takeshi at macports.org > Date: 2009-08-06 20:57:46 -0700 (Thu, 06 Aug 2009) > Log Message: > ----------- > vis5d: X11 => X11R6 for Tiger > > Modified Paths: > -------------- > trunk/dports/science/vis5d/Portfile > > Modified: trunk/dports/science/vis5d/Portfile > =================================================================== > --- trunk/dports/science/vis5d/Portfile 2009-08-07 03:53:35 UTC (rev 55147) > +++ trunk/dports/science/vis5d/Portfile 2009-08-07 03:57:46 UTC (rev 55148) > @@ -71,8 +71,8 @@ > configure.cppflags-append -I/usr/X11R6/include > configure.args -disable-fortran \ > -disable-dependency-tracing \ > - --x-includes=/usr/X11/include \ > - --x-libraries=/usr/X11/lib > + --x-includes=/usr/X11R6/include \ > + --x-libraries=/usr/X11R6/lib > # seems to use up CPU all the time > # -enable-threads Ports should be using the MacPorts-provided X11 in $prefix these days, rather than the system one. If you really need to use the system X11 for some reason, you should use ${x11prefix} instead of hardcoding /usr/X11R6 or /usr/X11. - Josh From jeremyhu at macports.org Thu Aug 6 22:08:08 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Thu, 6 Aug 2009 22:08:08 -0700 Subject: [55148] trunk/dports/science/vis5d/Portfile In-Reply-To: <4A7BAA7B.4000400@macports.org> References: <20090807035747.78CBF22DBCB9@beta.macosforge.org> <4A7BAA7B.4000400@macports.org> Message-ID: On Aug 6, 2009, at 21:15, Joshua Root wrote: > Ports should be using the MacPorts-provided X11 in $prefix these days, > rather than the system one. If you really need to use the system X11 > for > some reason, you should use ${x11prefix} instead of hardcoding > /usr/X11R6 or /usr/X11. x11prefix is no longer valid. This needs to be fixed to build against the MacPorts X11 libs. From seanasy at gmail.com Fri Aug 7 06:50:36 2009 From: seanasy at gmail.com (Sean Fulton) Date: Fri, 7 Aug 2009 09:50:36 -0400 Subject: [MacPorts] #20531: gdal build fails if pthsem is installed In-Reply-To: <059.1f7fe95ba506ada77a0e4e3771d1f9a0@macports.org> References: <059.1f7fe95ba506ada77a0e4e3771d1f9a0@macports.org> Message-ID: <420d14190908070650r58884831t72ce5aa3f4cb7a9@mail.gmail.com> I'll try to take a look at this this weekend, sorry for the delay. Does pthsem replace pth entirely? Sean On Sun, Aug 2, 2009 at 10:24 PM, MacPorts wrote: > #20531: gdal build fails if pthsem is installed > > -------------------------------------+-------------------------------------- > Reporter: ryandesign@? | Owner: seanasy@? > Type: defect | Status: new > Priority: Normal | Milestone: > Component: ports | Version: 1.7.1 > Keywords: | Port: gdal > > -------------------------------------+-------------------------------------- > Building gdal fails if pthsem is installed: > > {{{ > ---> Building gdal > DEBUG: Executing proc-pre-org.macports.build-build-0 > DEBUG: Executing org.macports.build (gdal) > DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.5' > DEBUG: Assembled command: 'cd > > "/mp/var/macports/build/_Users_rschmidt_macports_dports_science_gdal/work/gdal-1.6.0" > && nice -n 10 make' > (cd port; make) > /bin/sh > > /mp/var/macports/build/_Users_rschmidt_macports_dports_science_gdal/work/gdal-1.6.0/libtool > --mode=compile --tag=CXX /usr/bin/g++-4.0 -O2 -Wall -DOGR_ENABLED > -I/mp/include -I/mp/include > > -I/mp/var/macports/build/_Users_rschmidt_macports_dports_science_gdal/work/gdal-1.6.0/port > -I/mp -I/mp/include -I/mp -I/mp/include -I/mp/include -I/mp/include -I/mp > -I/mp/include -I../frmts/zlib -DHAVE_LIBZ -c -o cpl_conv.o > cpl_conv.cpp > libtool: compile: /usr/bin/g++-4.0 -O2 -Wall -DOGR_ENABLED -I/mp/include > -I/mp/include > > -I/mp/var/macports/build/_Users_rschmidt_macports_dports_science_gdal/work/gdal-1.6.0/port > -I/mp -I/mp/include -I/mp -I/mp/include -I/mp/include -I/mp/include -I/mp > -I/mp/include -I../frmts/zlib -DHAVE_LIBZ -c cpl_conv.cpp -fno-common > -DPIC -o .libs/cpl_conv.o > /mp/include/pthread.h:286: error: conflicting declaration 'typedef struct > pthread_attr_st* pthread_attr_t' > /usr/include/sys/signal.h:163: error: 'pthread_attr_t' has a previous > declaration as 'typedef struct __darwin_pthread_attr_t pthread_attr_t' > make[1]: *** [cpl_conv.o] Error 1 > make: *** [port-target] Error 2 > }}} > > It works if I uninstall pthsem, clean gdal and try again. Maybe gdal can > insulate itself from this somehow. > > -- > Ticket URL: > MacPorts > Ports system for Mac OS > -------------- next part -------------- An HTML attachment was scrubbed... URL: From talklists at newgeo.com Fri Aug 7 11:43:16 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 7 Aug 2009 11:43:16 -0700 Subject: OT launchd sleep and wake Message-ID: <95E2AA1A-C2C1-434F-B24F-68D14DB5C04B@newgeo.com> Before I jump over to the launchd mailing list, I wanted to see if anyone knew a way to detect a Mac going into sleep mode or waking from sleep mode. I'm looking to clear ssh-agent which is becoming an issue in and of itself. I was hoping there may be a file that was created or destroyed in wake/sleep that I could set launchd to look at as a watch folder. Or perhaps there are commands that can probe the PMU to get this data. I'm aware of sleepwatcher, which seems to work semi ubreliably, so I am looking for an alternative. I know sshkeychain has this ability, and while it is no longer developed, there is a chance I could pull just that code out and make a portfile that created a sleep/wake watching agent. Thanks for any suggestions. As an aside, if anyone has had success with clearing ssh keys from memory so you are re prompted via keychain I would love to know how you are reliably doing this. Stopping the agent does not seem to reliably clear the keys. There is not a ton of data on this, but I would like to use a laptop and know if it is stolen my ssh sessions will expire. I can not find a mailing list specific the ssh-agent, I assume the best place is the openSSH list, but this is also Apple specific since there is keychain interaction. Thanks -- Scott Iphone says hello. From kthenriksson at gmail.com Fri Aug 7 12:25:33 2009 From: kthenriksson at gmail.com (Kristofer Henriksson) Date: Fri, 7 Aug 2009 15:25:33 -0400 Subject: OT launchd sleep and wake In-Reply-To: <95E2AA1A-C2C1-434F-B24F-68D14DB5C04B@newgeo.com> References: <95E2AA1A-C2C1-434F-B24F-68D14DB5C04B@newgeo.com> Message-ID: <4809057c0908071225y281cf126y8dda46be3beac50b@mail.gmail.com> Off the top of my head, I can't speak as to detecting sleep/wake on a Mac. For clearing SSH keys, I'm surprised that stopping ssh-agent fails. However, there is also the command ssh-add -D which is meant to remove all keys from the agent. This should be what you are looking for. Regards, Kris Henriksson On Fri, Aug 7, 2009 at 2:43 PM, Scott Haneda wrote: > Before I jump over to the launchd mailing list, I wanted to see if anyone > knew a way to detect a Mac going into sleep mode or waking from sleep mode. > > I'm looking to clear ssh-agent which is becoming an issue in and of itself. > I was hoping there may be a file that was created or destroyed in wake/sleep > that I could set launchd to look at as a watch folder. > > Or perhaps there are commands that can probe the PMU to get this data. > > I'm aware of sleepwatcher, which seems to work semi ubreliably, so I am > looking for an alternative. > > I know sshkeychain has this ability, and while it is no longer developed, > there is a chance I could pull just that code out and make a portfile that > created a sleep/wake watching agent. > > Thanks for any suggestions. > > As an aside, if anyone has had success with clearing ssh keys from memory so > you are re prompted via keychain I would love to know how you are reliably > doing this. Stopping the agent does not seem to reliably clear the keys. > ?There is not a ton of data on this, but I would like to use a laptop and > know if it is stolen my ssh sessions will expire. > > I can not find a mailing list specific the ssh-agent, I assume the best > place is the openSSH list, but this is also Apple specific since there is > keychain interaction. > > Thanks > -- > Scott > Iphone says hello. > _______________________________________________ > 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 Aug 7 12:31:19 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 7 Aug 2009 14:31:19 -0500 Subject: [55052] trunk/dports/python In-Reply-To: <20090806114804.91BDE22CA89E@beta.macosforge.org> References: <20090806114804.91BDE22CA89E@beta.macosforge.org> Message-ID: <31692733-B080-4699-9EC9-934C4538FE68@macports.org> On Aug 6, 2009, at 06:48, mnick at macports.org wrote: > Revision: 55052 > http://trac.macports.org/changeset/55052 > Author: mnick at macports.org > Date: 2009-08-06 04:48:03 -0700 (Thu, 06 Aug 2009) > Log Message: > ----------- > new port: py26-scikits-module > provides scikits/__init__.py which is needed by all scikits > Added: trunk/dports/python/py26-scikits-module/Portfile > +master_sites ${homepage} > + > +# Nothing to see here, move along > +fetch {} > +checksum {} > +extract {} > +build {} Instead of overriding the fetch, checksum and extract phases, just clear distfiles. Since there isn't any distfile, you can also remove master_sites. So replace all of the above with just: distfiles From ryandesign at macports.org Fri Aug 7 12:53:50 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 7 Aug 2009 14:53:50 -0500 Subject: [55208] trunk/dports/sysutils/testdisk/Portfile In-Reply-To: <20090807142547.855A422E1183@beta.macosforge.org> References: <20090807142547.855A422E1183@beta.macosforge.org> Message-ID: On Aug 7, 2009, at 09:25, snc at macports.org wrote: > Revision: 55208 > http://trac.macports.org/changeset/55208 > Author: snc at macports.org > Date: 2009-08-07 07:25:46 -0700 (Fri, 07 Aug 2009) > Log Message: > ----------- > add some configure.args, add missing dependencies, ticket #20528. > does not seem to build with ossp-uuid active. ...which undid the fix I noted in http://trac.macports.org/ticket/20525#comment:2 With your change, now every user upgrading from testdisk 6.9 will encounter an error. See #20525 for much more discussion on how this might be resolved. From ryandesign at macports.org Fri Aug 7 13:04:38 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 7 Aug 2009 15:04:38 -0500 Subject: [55182] trunk/dports/lang/gnat-gcc/Portfile In-Reply-To: <20090807113625.DB1D222DF5E5@beta.macosforge.org> References: <20090807113625.DB1D222DF5E5@beta.macosforge.org> Message-ID: On Aug 7, 2009, at 06:36, snc at macports.org wrote: > Revision: 55182 > http://trac.macports.org/changeset/55182 > Author: snc at macports.org > Date: 2009-08-07 04:36:24 -0700 (Fri, 07 Aug 2009) > Log Message: > ----------- > remove hardcoded /opt/local. might consider modifying +gnatgpl to > be in ${prefix} like apache2 > Modified: trunk/dports/lang/gnat-gcc/Portfile > - set bootprefix /opt/local > + set bootprefix ${prefix} I think you misunderstand how the port is using these bootprefixes. These are not paths where the port will install files; rather, these are paths where the port requires there to be files in order to build itself. See new ticket: http://trac.macports.org/ticket/20598 From talklists at newgeo.com Fri Aug 7 13:29:02 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 7 Aug 2009 13:29:02 -0700 Subject: OT launchd sleep and wake In-Reply-To: <4809057c0908071225y281cf126y8dda46be3beac50b@mail.gmail.com> References: <95E2AA1A-C2C1-434F-B24F-68D14DB5C04B@newgeo.com> <4809057c0908071225y281cf126y8dda46be3beac50b@mail.gmail.com> Message-ID: <48B1E27F-761A-4BC8-9028-B9171EFCE2DD@newgeo.com> I know this is horribly off topic, but I have a feeling there are just enough people on this list that know about ssh-agent that I may be able to get where I need to be. I have a day in this, and it is now a war :) Basic ssh key based login, with password drwx------@ 5 me staff 170 Aug 6 23:21 .ssh $ls -la ~/.ssh -rw-------@ 1 me staff 1743 Feb 12 01:09 id_rsa -rw-r--r--@ 1 me staff 401 Feb 12 01:09 id_rsa.pub -rw-r--r-- 1 me staff 9890 Jul 29 18:49 known_hosts ssh-agent not running: $ps xa | grep ssh-agent | grep -v grep (empty result) $ssh me at remote.example.com ssh inspires a secure password dialogue box to pop up. ssh-agent is now running: $ps xa | grep ssh-agent | grep -v grep 658 ?? S 0:00.04 /usr/bin/ssh-agent -l Nothing in it yet: $ssh-add -l The agent has no identities. I enter in the password, and tell it to "Remember Password in Keychain". My keychains do not use the same password as the OS X login, which should not matter. $ssh me at remote.example.com I am no longer bothered with the secure password form. I have an identity $ssh-add -l 2048 xx:xx:xx:xx:xx:xx:xx...... /Users/me/.ssh/id_rsa (RSA) Looking in KeyChain Access, I see the entry. Lock it. I still am allowed to ssh in with no secure password dialogue. This is because locking the keychain does not clear the identity out. * I have moved the keychain entry to a new keychain called secure-ssh, set to lock on sleep. It is locked. I need to remove that identity, triggered by a sleep or wake event, for the sake of this issue, I just pretend the machine has hit a sleep or wake event, and I have the ability to trigger a script to do something on those events. So my goal is to remove that identity. # sleep event happens, and I run... $ssh-add -d Identity removed: /Users/me/.ssh/id_rsa (/Users/me/.ssh/id_rsa.pub) # Machine wakes up... $ssh me at remote.example.com Boom, asked for the secure password entry to get into the remote host, it is in my keychain, I should have been asked to unlock the keychain, and the login to the remote host should have happened automatically. This would just add another keychain item to the login keychain if I chose to save it. Try again, different method... # sleep event happens, and I run... $launchctl stop org.openbsd.ssh-agent $ps xa | grep ssh-agent | grep -v grep (empty result) That should do it, that stopped the agent, now, when I ssh in, it should start ssh-agent, try to add the identity, and see it needs to unlock the keychain I set up. # I am now in a woken up sate, the secure-ssh keychain is locked, as I set it to lock on sleep. $ssh me at remote.example.com I am logged right in, no authentication was asked. I could use ssh-add -d to remove the identities on sleep, and then ssh- add -k to add all the keychain identities on wake from sleep, but then, if I have no intention of using ssh at that time, I am going to be asked to unlock the keychain on every wake. This blog is about the only thing that talks about this in any detail, but is a few years dated http://www.dribin.org/dave/blog/archives/2007/11/28/securing_ssh_agent/ My methods are identical to his, though mine do not work for some reason. Stumped. On Aug 7, 2009, at 12:25 PM, Kristofer Henriksson wrote: > Off the top of my head, I can't speak as to detecting sleep/wake on > a Mac. > > For clearing SSH keys, I'm surprised that stopping ssh-agent fails. > However, there is also the command ssh-add -D which is meant to remove > all keys from the agent. This should be what you are looking for. -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Fri Aug 7 16:33:44 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 7 Aug 2009 18:33:44 -0500 Subject: OT launchd sleep and wake In-Reply-To: <95E2AA1A-C2C1-434F-B24F-68D14DB5C04B@newgeo.com> References: <95E2AA1A-C2C1-434F-B24F-68D14DB5C04B@newgeo.com> Message-ID: <820FD98C-F592-44DE-AD96-BEB969C994CA@macports.org> On Aug 7, 2009, at 13:43, Scott Haneda wrote: > Before I jump over to the launchd mailing list, I wanted to see if > anyone knew a way to detect a Mac going into sleep mode or waking > from sleep mode. [snip] > I'm aware of sleepwatcher, which seems to work semi ubreliably, so > I am looking for an alternative. Oh. This is the first I've heard of it being unreliable. What have you observed? From ryandesign at macports.org Fri Aug 7 16:35:32 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 7 Aug 2009 18:35:32 -0500 Subject: [MacPorts] #20531: gdal build fails if pthsem is installed In-Reply-To: <420d14190908070650r58884831t72ce5aa3f4cb7a9@mail.gmail.com> References: <059.1f7fe95ba506ada77a0e4e3771d1f9a0@macports.org> <420d14190908070650r58884831t72ce5aa3f4cb7a9@mail.gmail.com> Message-ID: <2B53179D-526E-44FC-B7DC-FD73BBE3EA9F@macports.org> On Aug 7, 2009, at 08:50, Sean Fulton wrote: > On Sun, Aug 2, 2009 at 10:24 PM, MacPorts wrote: > >> #20531: gdal build fails if pthsem is installed > > Does pthsem replace pth entirely? I have no idea what pthsem even is. I just happened to have it installed due to some previous port testing, and then noticed gdal failed to build. From ryandesign at macports.org Fri Aug 7 16:40:02 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 7 Aug 2009 18:40:02 -0500 Subject: [55200] trunk/dports/python/py-xlrd/Portfile In-Reply-To: <20090807124228.C4FB622E0024@beta.macosforge.org> References: <20090807124228.C4FB622E0024@beta.macosforge.org> Message-ID: On Aug 7, 2009, at 07:42, snc at macports.org wrote: > Revision: 55200 > http://trac.macports.org/changeset/55200 > Author: snc at macports.org > Date: 2009-08-07 05:42:28 -0700 (Fri, 07 Aug 2009) > Log Message: > ----------- > make into stub package, ticket #20564 > > Modified Paths: > -------------- > trunk/dports/python/py-xlrd/Portfile [snip] > +depends_build port:py25-xlrd The problem with making the old port depend on the new port like this is that anybody upgrading from the old port will encounter an error message like this: $ port upgrade py-xlrd ---> Fetching py25-xlrd ---> Attempting to fetch xlrd-0.7.1.zip from http://pypi.python.org/ packages/source/x/xlrd/ ---> Verifying checksum(s) for py25-xlrd ---> Extracting py25-xlrd ---> Configuring py25-xlrd ---> Building py25-xlrd ---> Staging py25-xlrd into destroot ---> Installing py25-xlrd @0.7.1_0 ---> Activating py25-xlrd @0.7.1_0 Error: Target org.macports.activate returned: Image error: /mp/bin/ runxlrd.py is being used by the active py-xlrd port. Please deactivate this port first, or use 'port -f activate py25-xlrd' to force the activation. $ So the old port should not declare a dependency on the new port, but should instead just print a message advising the user to install the new port. Once MacPorts 1.8.0 is released, the old port can instead use the new replaced_by keyword to automate this for the user. From seanasy at gmail.com Fri Aug 7 17:18:47 2009 From: seanasy at gmail.com (Sean Fulton) Date: Fri, 7 Aug 2009 20:18:47 -0400 Subject: [MacPorts] #20531: gdal build fails if pthsem is installed In-Reply-To: <2B53179D-526E-44FC-B7DC-FD73BBE3EA9F@macports.org> References: <059.1f7fe95ba506ada77a0e4e3771d1f9a0@macports.org> <420d14190908070650r58884831t72ce5aa3f4cb7a9@mail.gmail.com> <2B53179D-526E-44FC-B7DC-FD73BBE3EA9F@macports.org> Message-ID: <70AD5E34-1A17-4589-BA41-07B5CAE0636D@gmail.com> On 7 Aug, 2009, at 7:35 PM, Ryan Schmidt wrote: > > On Aug 7, 2009, at 08:50, Sean Fulton wrote: > >> On Sun, Aug 2, 2009 at 10:24 PM, MacPorts wrote: >> >>> #20531: gdal build fails if pthsem is installed >> >> Does pthsem replace pth entirely? > > I have no idea what pthsem even is. I just happened to have it > installed due to some previous port testing, and then noticed gdal > failed to build. > pthsem is pth + semaphores. Semaphores are used is parallel programming. The gdal port builds with pthreads if they are available but doesn't explicitly check for pth or pthsem. gdal doesn't really have any knowledge of pthsem. pthsem usually is installed alongside pth and only used if the compiler asks for it. If pthsem is overriding pth, that could be a problem with pthsem. One solution from the gdal perspective is to have a variant for pthreads and requite pth. In most cases I would accept that a variant is appropriate but here I'm not so sure. pthreads is the standard library for threads, I think, in the vast majority of OSS and pthsem shouldn't be overriding it. On the other hand, the gdal port is probably picking up the native OS X pthreads without being asked to. Should a port that wants threading stick to explicitly requesting MacPorts pth? How much can/should a port take in the OS libraries? Sean From jmr at macports.org Fri Aug 7 20:00:50 2009 From: jmr at macports.org (Joshua Root) Date: Sat, 08 Aug 2009 13:00:50 +1000 Subject: release_1_8 branch created Message-ID: <4A7CEA62.5070606@macports.org> A branch has been created in svn for MacPorts 1.8.x releases: This means that now is the time to start committing riskier changes to trunk. At this point, bug fixes should be merged into the branch only if they are low-risk or fix a regression. A 1.8.0-beta1 release has also been tagged, and an announcement will be sent to macports-users about that soon. - Josh From raimue at macports.org Fri Aug 7 21:51:52 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 08 Aug 2009 06:51:52 +0200 Subject: OT launchd sleep and wake In-Reply-To: <95E2AA1A-C2C1-434F-B24F-68D14DB5C04B@newgeo.com> References: <95E2AA1A-C2C1-434F-B24F-68D14DB5C04B@newgeo.com> Message-ID: <4A7D0468.10300@macports.org> On 2009-08-07 20:43 , Scott Haneda wrote: > I'm looking to clear ssh-agent which is becoming an issue in and of > itself. I was hoping there may be a file that was created or destroyed > in wake/sleep that I could set launchd to look at as a watch folder. > [...] > I know sshkeychain has this ability, and while it is no longer > developed, there is a chance I could pull just that code out and make > a portfile that created a sleep/wake watching agent. Although SSHKeychain may not be actively maintained anymore, I am happily using it for exactly this purpose. It is removing keys from ssh-agent and locking the Mac OS X keychain on screensaver activation or system sleep. Rainer From raimue at macports.org Fri Aug 7 22:04:23 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 08 Aug 2009 07:04:23 +0200 Subject: [MacPorts] #20531: gdal build fails if pthsem is installed In-Reply-To: <70AD5E34-1A17-4589-BA41-07B5CAE0636D@gmail.com> References: <059.1f7fe95ba506ada77a0e4e3771d1f9a0@macports.org> <420d14190908070650r58884831t72ce5aa3f4cb7a9@mail.gmail.com> <2B53179D-526E-44FC-B7DC-FD73BBE3EA9F@macports.org> <70AD5E34-1A17-4589-BA41-07B5CAE0636D@gmail.com> Message-ID: <4A7D0757.4050504@macports.org> On 2009-08-08 02:18 , Sean Fulton wrote: > One solution from the gdal perspective is to have a variant for > pthreads and requite pth. In most cases I would accept that a variant > is appropriate but here I'm not so sure. pthreads is the standard > library for threads, I think, in the vast majority of OSS and pthsem > shouldn't be overriding it. On the other hand, the gdal port is > probably picking up the native OS X pthreads without being asked to. pthreads is an essential interface on modern systems. On Mac OS X it is directly implemented in libSystem against which most binaries have to link anyway for the usual BSD library functions. If I read the description for pth correctly, it is purely implemented in user-mode and does not make use of kernel scheduling. Without using the kernel scheduler such a library cannot take advantage of multiple CPUs/cores. Therefore I would strongly recommend the Mac OS X provided pthreads interface. Rainer From giorgio_v at macports.org Fri Aug 7 23:58:51 2009 From: giorgio_v at macports.org (Giorgio Valoti) Date: Sat, 8 Aug 2009 08:58:51 +0200 Subject: Where to start: pointers? links? tickets? Message-ID: Hi all, maybe it?s a naive question, don?t know. I?d like to contribute some more to this project, so I thought I could browse the tickets and begin to fix some easy ones but I thought maybe it?s better to ask here. So, could someone tell me where could I start? Thanks again for your time. Ciao -- Giorgio Valoti From mail at uwe-arzt.de Sat Aug 8 03:00:06 2009 From: mail at uwe-arzt.de (Uwe Arzt) Date: Sat, 8 Aug 2009 12:00:06 +0200 Subject: [MacPorts] #20531: gdal build fails if pthsem is installed In-Reply-To: <4A7D0757.4050504@macports.org> References: <059.1f7fe95ba506ada77a0e4e3771d1f9a0@macports.org> <420d14190908070650r58884831t72ce5aa3f4cb7a9@mail.gmail.com> <2B53179D-526E-44FC-B7DC-FD73BBE3EA9F@macports.org> <70AD5E34-1A17-4589-BA41-07B5CAE0636D@gmail.com> <4A7D0757.4050504@macports.org> Message-ID: Hi all, correct ;). whenever possible the system libs should be used. Back to the bug: On my System (Intel Leopard 10.5.8) gdal builds fine when pthsem and/ or pth is installed. Could there be an dependency with other packages? What else can/should i try to reproduce the bug (as maintainer of pthsem)? And both libs have different filesets: ganymed:~ uwe$ sudo port contents pthsem Port pthsem contains: /opt/local/bin/pthsem-config /opt/local/include/pthsem.h /opt/local/lib/libpthsem.20.0.27.dylib /opt/local/lib/libpthsem.20.dylib /opt/local/lib/libpthsem.a /opt/local/lib/libpthsem.dylib /opt/local/lib/libpthsem.la /opt/local/man/man1/pthsem-config.1 /opt/local/man/man3/pthsem.3 /opt/local/share/aclocal/pthsem.m4 ganymed:~ uwe$ sudo port contents pth Port pth contains: /opt/local/bin/pth-config /opt/local/include/pth.h /opt/local/lib/libpth.20.0.27.dylib /opt/local/lib/libpth.20.dylib /opt/local/lib/libpth.a /opt/local/lib/libpth.dylib /opt/local/lib/libpth.la /opt/local/share/aclocal/pth.m4 /opt/local/share/doc/pth/ANNOUNCE /opt/local/share/doc/pth/AUTHORS /opt/local/share/doc/pth/ChangeLog /opt/local/share/doc/pth/COPYING /opt/local/share/doc/pth/HACKING /opt/local/share/doc/pth/HISTORY /opt/local/share/doc/pth/INSTALL /opt/local/share/doc/pth/NEWS /opt/local/share/doc/pth/PORTING /opt/local/share/doc/pth/README /opt/local/share/doc/pth/SUPPORT /opt/local/share/doc/pth/TESTS /opt/local/share/doc/pth/THANKS /opt/local/share/doc/pth/USERS /opt/local/share/man/man1/pth-config.1.gz /opt/local/share/man/man3/pth.3.gz Any help apreciated... BTW: pthsem doesn't even build on 10.4 (There is a bug in Trac for that). But have to get a grip on a 10.4 machine, before i can reproduce this issue. :q! Uwe Am 08.08.2009 um 07:04 schrieb Rainer M?ller: > On 2009-08-08 02:18 , Sean Fulton wrote: >> One solution from the gdal perspective is to have a variant for >> pthreads and requite pth. In most cases I would accept that a >> variant >> is appropriate but here I'm not so sure. pthreads is the standard >> library for threads, I think, in the vast majority of OSS and pthsem >> shouldn't be overriding it. On the other hand, the gdal port is >> probably picking up the native OS X pthreads without being asked to. > > pthreads is an essential interface on modern systems. On Mac OS X it > is > directly implemented in libSystem against which most binaries have to > link anyway for the usual BSD library functions. > > If I read the description for pth correctly, it is purely > implemented in > user-mode and does not make use of kernel scheduling. Without using > the > kernel scheduler such a library cannot take advantage of multiple > CPUs/cores. Therefore I would strongly recommend the Mac OS X provided > pthreads interface. > > Rainer > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev :q! Uwe -- mail at uwe-arzt.de www.uwe-arzt.de From ramercer at gmail.com Sat Aug 8 08:54:11 2009 From: ramercer at gmail.com (Adam Mercer) Date: Sat, 8 Aug 2009 10:54:11 -0500 Subject: [55085] trunk/dports/textproc/tth/Portfile In-Reply-To: <20090806183456.5D25A22D49C1@beta.macosforge.org> References: <20090806183456.5D25A22D49C1@beta.macosforge.org> Message-ID: <799406d60908080854g2316afdew1fad14f3fdf7f136@mail.gmail.com> On Thu, Aug 6, 2009 at 13:34, wrote: > -use_configure no > +# sigh > +configure {} > +set mycflags ${configure.cflags} > +if {[variant_isset universal]} { > + set mycflags "$mycflags ${configure.universal_cflags}" > +} else { > + set mycflags "$mycflags ${configure.cc_archflags}" > +} configure.cc_archflags doesn't seem to be in MacPorts 1.7.1, so PortIndex fails with: Failed to parse file textproc/tth/Portfile: can't read "configure.cc_archflags": no such variable when using MacPorts 1.7.1 Cheers Adam From ram at macports.org Sat Aug 8 09:03:15 2009 From: ram at macports.org (Adam Mercer) Date: Sat, 8 Aug 2009 11:03:15 -0500 Subject: 1.8.0 r55286 error from port outdated Message-ID: <799406d60908080903n13fbebej194d0d7a61e65ea8@mail.gmail.com> Hi Just updated my base installation to the current HEAD of the release_1_8 branch (r55286) and port outdated is failing with the following error: [ram at cizin base]$ port outdated can't read "portinfo(version)": no such element in array while executing "set latest_version $portinfo(version)" (procedure "action_outdated" line 67) invoked from within "$action_proc $action $portlist [array get global_options]" (procedure "process_cmd" line 92) invoked from within "process_cmd $remaining_args" invoked from within "if { [llength $remaining_args] > 0 } { # If there are remaining arguments, process those as a command set exit_status [process_cmd $remaining..." (file "/opt/local/bin/port" line 3672) [ram at cizin base]$ Is is an actual problem or have I messed something up? Cheers Adam From frstan at bellsouth.net Sat Aug 8 09:25:36 2009 From: frstan at bellsouth.net (William Davis) Date: Sat, 8 Aug 2009 12:25:36 -0400 Subject: 1.8.0 r55286 error from port outdated In-Reply-To: <799406d60908080903n13fbebej194d0d7a61e65ea8@mail.gmail.com> References: <799406d60908080903n13fbebej194d0d7a61e65ea8@mail.gmail.com> Message-ID: <62E39712-7590-4357-8208-94F8897EECC3@bellsouth.net> I downloaded the dmg and installed -- port outdated works fine here WSD On Aug 8, 2009, at 12:03 PM, Adam Mercer wrote: > Hi > > Just updated my base installation to the current HEAD of the > release_1_8 branch (r55286) and port outdated is failing with the > following error: > > [ram at cizin base]$ port outdated > can't read "portinfo(version)": no such element in array > while executing > "set latest_version $portinfo(version)" > (procedure "action_outdated" line 67) > invoked from within > "$action_proc $action $portlist [array get global_options]" > (procedure "process_cmd" line 92) > invoked from within > "process_cmd $remaining_args" > invoked from within > "if { [llength $remaining_args] > 0 } { > > # If there are remaining arguments, process those as a command > set exit_status [process_cmd $remaining..." > (file "/opt/local/bin/port" line 3672) > [ram at cizin base]$ > > Is is an actual problem or have I messed something up? > > Cheers > > Adam > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev William Davis frstanATbellsouthDOTnet Mac OS X.5.8 Darwin 9.8.0 XQuartz 2.4.0_rc2 (xorg-server 1.5.3-apple14) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non From vincent-opdarw at vinc17.org Sat Aug 8 12:30:31 2009 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Sat, 8 Aug 2009 21:30:31 +0200 Subject: use_xz? Message-ID: <20090808193031.GQ1360@prunille.vinc17.org> Does MacPorts have a use_xz variable? Some tarballs are now distributed in both gz and xz compression format, and xz is significantly smaller than gz. For instance, for the coreutils 7.4: .tar.gz 9.3 MB .tar.xz 3.9 MB -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) From talklists at newgeo.com Sat Aug 8 12:52:52 2009 From: talklists at newgeo.com (Scott Haneda) Date: Sat, 8 Aug 2009 12:52:52 -0700 Subject: OT launchd sleep and wake In-Reply-To: <820FD98C-F592-44DE-AD96-BEB969C994CA@macports.org> References: <95E2AA1A-C2C1-434F-B24F-68D14DB5C04B@newgeo.com> <820FD98C-F592-44DE-AD96-BEB969C994CA@macports.org> Message-ID: <0D344375-0D1A-45D3-B278-118207EFDA3D@newgeo.com> On Aug 7, 2009, at 4:33 PM, Ryan Schmidt wrote: > On Aug 7, 2009, at 13:43, Scott Haneda wrote: > >> Before I jump over to the launchd mailing list, I wanted to see if >> anyone knew a way to detect a Mac going into sleep mode or waking >> from sleep mode. > > [snip] > >> I'm aware of sleepwatcher, which seems to work semi ubreliably, so >> I am looking for an alternative. > > Oh. This is the first I've heard of it being unreliable. What have > you observed? First, it was just reading the comments on Version Tracker, which I sort of take with a gain of salt anyway, but it got me in the mind to at least pay attention. I made a very simply test case, which was to install, and I am using the Startup Item with it, but I also have tested with ./sleepwatcher - d as well. I put in ~/.sleep and ~/.wakeup. In each of those files, I have very basic code: #!/bin/bash date=`date` echo "$date Clearing out ssh-agent because we are sleeping" >> ~/ Library/Logs/sleepwatcher.log; launchctl stop org.openbsd.ssh-agent While the launchd may error, and cause issues, I do not think that is the case, the basic echo line should not cause any issues. My .wakeup is identical other than I change "...sleeping" to "...waking" I performed 10 total sleep and wake cycles, I ended up with only 18 lines total. So 8 sleep and 8 wake log lines were made. I believe it is reliable in that if it works, it will work both on the sleep and wake side of the equation. My experience shows a balance in the log lines, half are wake, half are sleep. My only guess is that if you sleep/wake too soon, there may be some confusion, perhaps the sleep did not fully enact, though that is just a guess. I will look into, and do my best to solve this, though first, I need to solve the ssh-agent issues, or I will not even need to use this application. I think the first thing I will do when I get ssh-agent playing nice, is to convert the startup item to a launchd item. -- Scott * If you contact me off list replace talklists@ with scott@ * From blb at macports.org Sat Aug 8 13:15:38 2009 From: blb at macports.org (Bryan Blackburn) Date: Sat, 8 Aug 2009 14:15:38 -0600 Subject: Where to start: pointers? links? tickets? In-Reply-To: References: Message-ID: <20090808201538.GX609@ninagal.withay.com> On Sat, Aug 08, 2009 at 08:58:51AM +0200, Giorgio Valoti said: > Hi all, > maybe it?s a naive question, don?t know. > > I?d like to contribute some more to this project, so I thought I > could browse the tickets and begin to fix some easy ones but I > thought maybe it?s better to ask here. > > So, could someone tell me where could I start? Thanks again for your > time. Definitely an easier way to get started; the simplest tickets to handle to begin with would be simple version updates, either to nomaintainer ports or submitted by maintainers who don't have commit access. These usually just entail applying the patch from the ticket, then testing the port to verify it installs fine. If it supports 'port test' you can run that as well. The major issue with this is you'll need to have quite a few ports installed as dependencies for some things... You can have a look at to find such tickets. Also good to start with are the new port submissions, though they tend to need more testing than updates at times. Bryan > > > Ciao > -- > Giorgio Valoti From talklists at newgeo.com Sat Aug 8 13:35:04 2009 From: talklists at newgeo.com (Scott Haneda) Date: Sat, 8 Aug 2009 13:35:04 -0700 Subject: OT launchd sleep and wake In-Reply-To: <4A7D0468.10300@macports.org> References: <95E2AA1A-C2C1-434F-B24F-68D14DB5C04B@newgeo.com> <4A7D0468.10300@macports.org> Message-ID: On Aug 7, 2009, at 9:51 PM, Rainer M?ller wrote: > On 2009-08-07 20:43 , Scott Haneda wrote: >> I'm looking to clear ssh-agent which is becoming an issue in and of >> itself. I was hoping there may be a file that was created or >> destroyed >> in wake/sleep that I could set launchd to look at as a watch folder. > >> [...] > >> I know sshkeychain has this ability, and while it is no longer >> developed, there is a chance I could pull just that code out and make >> a portfile that created a sleep/wake watching agent. > > Although SSHKeychain may not be actively maintained anymore, I am > happily using it for exactly this purpose. It is removing keys from > ssh-agent and locking the Mac OS X keychain on screensaver > activation or > system sleep. Very good to know. Are you on Intel by any chance? That was my concern, in that there are a some comments of massive memory usage on Intel. -- Scott * If you contact me off list replace talklists@ with scott@ * From jeremy at lavergne.gotdns.org Sat Aug 8 14:54:46 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 8 Aug 2009 17:54:46 -0400 Subject: OT launchd sleep and wake In-Reply-To: References: <95E2AA1A-C2C1-434F-B24F-68D14DB5C04B@newgeo.com> <4A7D0468.10300@macports.org> Message-ID: > I'm looking to clear ssh-agent which is becoming an issue in and of > itself. I was hoping there may be a file that was created or > destroyed in wake/sleep that I could set launchd to look at as a > watch folder. If this is only being used as a way to make sure people cannot use the ssh-agent after a wake, why not just require their password to use the computer at all after a wake? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jeremy at lavergne.gotdns.org Sat Aug 8 15:08:05 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 8 Aug 2009 18:08:05 -0400 Subject: Where to start: pointers? links? tickets? In-Reply-To: <20090808201538.GX609@ninagal.withay.com> References: <20090808201538.GX609@ninagal.withay.com> Message-ID: >> I?d like to contribute some more to this project, so I thought I >> could browse the tickets and begin to fix some easy ones but I >> thought maybe it?s better to ask here. > > Definitely an easier way to get started; the simplest tickets to > handle to > begin with would be simple version updates, either to nomaintainer > ports or > submitted by maintainers who don't have commit access. To that end, you might consider doing `port livecheck installed` to easily find out what ports you're using that are outdated. You could also do `port livecheck maintainer:openmaintainer` or `port livecheck maintainer:nomaintainer`. If you come across ports without livechecks, you might flex your regex (if applicable) and write some livechecks ;-) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From ram at macports.org Sat Aug 8 18:58:35 2009 From: ram at macports.org (Adam Mercer) Date: Sat, 8 Aug 2009 20:58:35 -0500 Subject: 1.8.0 r55286 error from port outdated In-Reply-To: <62E39712-7590-4357-8208-94F8897EECC3@bellsouth.net> References: <799406d60908080903n13fbebej194d0d7a61e65ea8@mail.gmail.com> <62E39712-7590-4357-8208-94F8897EECC3@bellsouth.net> Message-ID: <799406d60908081858w117b903ah7bb98a7dd27dfe73@mail.gmail.com> On Sat, Aug 8, 2009 at 11:25, William Davis wrote: > I downloaded the dmg and installed -- port outdated works fine here Same problem using the DMG, I've reverted back to 1.7.1 until this problem can be found. Cheers Adam From jmr at macports.org Sat Aug 8 19:41:43 2009 From: jmr at macports.org (Joshua Root) Date: Sun, 09 Aug 2009 12:41:43 +1000 Subject: 1.8.0 r55286 error from port outdated In-Reply-To: <799406d60908080903n13fbebej194d0d7a61e65ea8@mail.gmail.com> References: <799406d60908080903n13fbebej194d0d7a61e65ea8@mail.gmail.com> Message-ID: <4A7E3767.9010908@macports.org> On 2009-8-9 02:03, Adam Mercer wrote: > Hi > > Just updated my base installation to the current HEAD of the > release_1_8 branch (r55286) and port outdated is failing with the > following error: > > [ram at cizin base]$ port outdated > can't read "portinfo(version)": no such element in array > while executing > "set latest_version $portinfo(version)" > (procedure "action_outdated" line 67) > invoked from within > "$action_proc $action $portlist [array get global_options]" > (procedure "process_cmd" line 92) > invoked from within > "process_cmd $remaining_args" > invoked from within > "if { [llength $remaining_args] > 0 } { > > # If there are remaining arguments, process those as a command > set exit_status [process_cmd $remaining..." > (file "/opt/local/bin/port" line 3672) > [ram at cizin base]$ > > Is is an actual problem or have I messed something up? Looks like you have a port in one of your indices that has no version field. I'll commit a check to make action_outdated handle this error more gracefully. - Josh From ram at macports.org Sat Aug 8 21:17:51 2009 From: ram at macports.org (Adam Mercer) Date: Sat, 8 Aug 2009 23:17:51 -0500 Subject: 1.8.0 r55286 error from port outdated In-Reply-To: <4A7E3767.9010908@macports.org> References: <799406d60908080903n13fbebej194d0d7a61e65ea8@mail.gmail.com> <4A7E3767.9010908@macports.org> Message-ID: <799406d60908082117q77d6a290g2cef26cdec6d147c@mail.gmail.com> On Sat, Aug 8, 2009 at 21:41, Joshua Root wrote: > Looks like you have a port in one of your indices that has no version > field. I'll commit a check to make action_outdated handle this error > more gracefully. Thanks Josh, that wasn't the actual problem but the fix helped me find it. Turns out the index of one of my local port trees was generated using base 1.7.1 and 1.8.0 was choking on it. Updating the index using 1.8.0 and the problem goes away. Cheers Adam From giorgio_v at macports.org Sun Aug 9 04:06:57 2009 From: giorgio_v at macports.org (Giorgio Valoti) Date: Sun, 9 Aug 2009 13:06:57 +0200 Subject: Where to start: pointers? links? tickets? In-Reply-To: References: <20090808201538.GX609@ninagal.withay.com> Message-ID: <5730E75F-37CF-44EC-95E0-F723B5190241@macports.org> Il giorno 09/ago/09, alle ore 00:08, Jeremy Lavergne ha scritto: >>> I?d like to contribute some more to this project, so I thought I >>> could browse the tickets and begin to fix some easy ones but I >>> thought maybe it?s better to ask here. >> >> Definitely an easier way to get started; the simplest tickets to >> handle to >> begin with would be simple version updates, either to nomaintainer >> ports or >> submitted by maintainers who don't have commit access. > > To that end, you might consider doing `port livecheck installed` to > easily find out what ports you're using that are outdated. You > could also do `port livecheck maintainer:openmaintainer` or `port > livecheck maintainer:nomaintainer`. If you come across ports > without livechecks, you might flex your regex (if applicable) and > write some livechecks ;-) I?m already maintaining some ports, I was thinking doing something on the lower levels. I took a look at some tickets listed here: Maybe I?ll find something to start with. Re: the livechecks. Is there a way to maintain a parallel macports system, say one under /opt/local and one under ~/ports? -- Giorgio Valoti From raimue at macports.org Sun Aug 9 13:45:14 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 09 Aug 2009 22:45:14 +0200 Subject: OT launchd sleep and wake In-Reply-To: References: <95E2AA1A-C2C1-434F-B24F-68D14DB5C04B@newgeo.com> <4A7D0468.10300@macports.org> Message-ID: <4A7F355A.1090305@macports.org> On 2009-08-08 22:35 , Scott Haneda wrote: > Very good to know. Are you on Intel by any chance? That was my > concern, in that there are a some comments of massive memory usage on > Intel. Yes, I am on Intel using SSHKeychain from MacPorts. ... %CPU %MEM VSZ RSS ... TIME COMMAND ... 0.0 0.3 430976 11480 ... 0:05.41 /Applications/MacPorts/SSHKeychain.app/Contents/MacOS/SSHKeychain -psn_0_61455 This does not look like large amounts of RAM to me. Rainer From ryandesign at macports.org Sun Aug 9 14:09:58 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 9 Aug 2009 16:09:58 -0500 Subject: use_xz? In-Reply-To: <20090808193031.GQ1360@prunille.vinc17.org> References: <20090808193031.GQ1360@prunille.vinc17.org> Message-ID: <7A8A2606-F132-485E-8137-83FB0A1C564C@macports.org> On Aug 8, 2009, at 14:30, Vincent Lefevre wrote: > Does MacPorts have a use_xz variable? Some tarballs are now > distributed > in both gz and xz compression format, and xz is significantly smaller > than gz. For instance, for the coreutils 7.4: > > .tar.gz 9.3 MB > .tar.xz 3.9 MB No, I had not heard of xz until you mentioned it here. It can be added. But it looks like there is only an xz-devel port for version 4.999.8beta; no stable version available. They also state they prefer users to build the latest version in git rather than use the beta. Perhaps we should wait until their development cycle slows down a bit, a stable version is released and an xz port is created before promoting the use of these archives? From their homepage it looks like the .xv format was only stabilized in version 4.999.7beta from December 2008, assuming they don't change their mind and change the format again. From ryandesign at macports.org Sun Aug 9 14:17:40 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 9 Aug 2009 16:17:40 -0500 Subject: Where to start: pointers? links? tickets? In-Reply-To: <5730E75F-37CF-44EC-95E0-F723B5190241@macports.org> References: <20090808201538.GX609@ninagal.withay.com> <5730E75F-37CF-44EC-95E0-F723B5190241@macports.org> Message-ID: <698C2A27-173C-408B-A8EE-D6C653A7075E@macports.org> On Aug 9, 2009, at 06:06, Giorgio Valoti wrote: > Il giorno 09/ago/09, alle ore 00:08, Jeremy Lavergne ha scritto: > >>>> I?d like to contribute some more to this project, so I thought I >>>> could browse the tickets and begin to fix some easy ones but I >>>> thought maybe it?s better to ask here. >>> >>> Definitely an easier way to get started; the simplest tickets to >>> handle to >>> begin with would be simple version updates, either to >>> nomaintainer ports or >>> submitted by maintainers who don't have commit access. >> >> To that end, you might consider doing `port livecheck installed` >> to easily find out what ports you're using that are outdated. You >> could also do `port livecheck maintainer:openmaintainer` or `port >> livecheck maintainer:nomaintainer`. If you come across ports >> without livechecks, you might flex your regex (if applicable) and >> write some livechecks ;-) > > I?m already maintaining some ports, I was thinking doing something > on the lower levels. I took a look at some tickets listed here: > status=new&status=reopened&component=base&order=priority&col=id&col=su > mmary&col=status&col=owner&col=type&col=priority&col=port&type=% > 21enhancement> > > Maybe I?ll find something to start with. It's ambitious! Understanding how base works is a lot more involved than understanding how portfiles work. But feel free to dive in. We could certainly use more people working on base. > Re: the livechecks. Is there a way to maintain a parallel macports > system, say one under /opt/local and one under ~/ports? Sure. Just install another MacPorts with a different prefix. You need more than just the --prefix argument to the ./configure script though. You also need to tell it to put the Tcl package, applications and frameworks in different places, otherwise they will overwrite those files in your other MacPorts install. For example you could use: PREFIX=/wherever ./configure \ --prefix=$PREFIX \ --with-tclpackage=$PREFIX/Library/Tcl \ --with-applications-dir=$PREFIX/Applications \ --with-frameworks-dir=$PREFIX/Library/Frameworks \ --enable-readline make sudo make install When I install a second MacPorts for testing, I tend to link the portfiles and distfiles up to the ones I already have from my first installation, so I don't have to download them again. To do that, you would edit $PREFIX/etc/macports/sources.conf and tell it the file:///- based location of your existing ports tree, and delete $PREFIX/var/ macports/distfiles and replace it with a symlink to your existing distfiles directory, respectively. From ryandesign at macports.org Sun Aug 9 14:21:08 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 9 Aug 2009 16:21:08 -0500 Subject: 1.8.0 r55286 error from port outdated In-Reply-To: <799406d60908082117q77d6a290g2cef26cdec6d147c@mail.gmail.com> References: <799406d60908080903n13fbebej194d0d7a61e65ea8@mail.gmail.com> <4A7E3767.9010908@macports.org> <799406d60908082117q77d6a290g2cef26cdec6d147c@mail.gmail.com> Message-ID: <33E9A629-7728-4DD3-9297-4BA09044FF3E@macports.org> On Aug 8, 2009, at 23:17, Adam Mercer wrote: > On Sat, Aug 8, 2009 at 21:41, Joshua Root wrote: > >> Looks like you have a port in one of your indices that has no version >> field. I'll commit a check to make action_outdated handle this error >> more gracefully. > > Thanks Josh, that wasn't the actual problem but the fix helped me find > it. Turns out the index of one of my local port trees was generated > using base 1.7.1 and 1.8.0 was choking on it. Updating the index using > 1.8.0 and the problem goes away. But surely the PortIndex we are distributing with our ports tree today is being generated by 1.7.1? From raimue at macports.org Sun Aug 9 14:24:28 2009 From: raimue at macports.org (=?windows-1252?Q?Rainer_M=FCller?=) Date: Sun, 09 Aug 2009 23:24:28 +0200 Subject: Where to start: pointers? links? tickets? In-Reply-To: <5730E75F-37CF-44EC-95E0-F723B5190241@macports.org> References: <20090808201538.GX609@ninagal.withay.com> <5730E75F-37CF-44EC-95E0-F723B5190241@macports.org> Message-ID: <4A7F3E8C.1080203@macports.org> On 2009-08-09 13:06 , Giorgio Valoti wrote: > Re: the livechecks. Is there a way to maintain a parallel macports > system, say one under /opt/local and one under ~/ports? Yes, you can have as many MacPorts installations as you would like on the same machine. Just use distinct paths for each of them. Use a configure line like this: ./configure --prefix=/opt/foo/ --with-tclpackage=/opt/foo/Library/Tcl --with-applications-dir=/opt/foo/Applications --with-frameworks-dir=/opt/foo/Library/Frameworks --enable-readline If you want it to be a non-root installation, you would also have to use --with-install-user, --with-install-group and --with-directory-mode. Watch out that at the time of configure no other MacPorts installation is visible on PATH! You want to link against the system libraries, not another MacPorts prefix. To save some disk space and time, multiple installations can use the same ports tree in sources.conf so you only have to synchronize once. Rainer From blb at macports.org Sun Aug 9 14:31:17 2009 From: blb at macports.org (Bryan Blackburn) Date: Sun, 9 Aug 2009 15:31:17 -0600 Subject: 1.8.0 r55286 error from port outdated In-Reply-To: <33E9A629-7728-4DD3-9297-4BA09044FF3E@macports.org> References: <799406d60908080903n13fbebej194d0d7a61e65ea8@mail.gmail.com> <4A7E3767.9010908@macports.org> <799406d60908082117q77d6a290g2cef26cdec6d147c@mail.gmail.com> <33E9A629-7728-4DD3-9297-4BA09044FF3E@macports.org> Message-ID: <20090809213117.GX609@ninagal.withay.com> On Sun, Aug 09, 2009 at 04:21:08PM -0500, Ryan Schmidt said: > > On Aug 8, 2009, at 23:17, Adam Mercer wrote: > > >On Sat, Aug 8, 2009 at 21:41, Joshua Root wrote: > > > >>Looks like you have a port in one of your indices that has no version > >>field. I'll commit a check to make action_outdated handle this error > >>more gracefully. > > > >Thanks Josh, that wasn't the actual problem but the fix helped me find > >it. Turns out the index of one of my local port trees was generated > >using base 1.7.1 and 1.8.0 was choking on it. Updating the index using > >1.8.0 and the problem goes away. > > But surely the PortIndex we are distributing with our ports tree > today is being generated by 1.7.1? It's been generated by a version from trunk (don't know the precise rev) for some time, otherwise we wouldn't see the PortIndex.quick updates as well. Bryan From ryandesign at macports.org Sun Aug 9 15:40:25 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 9 Aug 2009 17:40:25 -0500 Subject: [55339] trunk/dports/audio/oggsplit/Portfile In-Reply-To: <20090809160139.E246522F2E4F@beta.macosforge.org> References: <20090809160139.E246522F2E4F@beta.macosforge.org> Message-ID: <82C3B8E9-039F-4475-ADB5-36C37928976F@macports.org> On Aug 9, 2009, at 11:01, yves at macports.org wrote: > Revision: 55339 > http://trac.macports.org/changeset/55339 > Author: yves at macports.org > Date: 2009-08-09 09:01:37 -0700 (Sun, 09 Aug 2009) > Log Message: > ----------- > Revision 1, fix for ticket:20331 Don't change it now, but note that there was no need to increase the port's revision. Doing so causes anyone who already had the port installed to rebuild it, but there's no reason to cause that, since the new port will install exactly the same files as the old one. > Modified: trunk/dports/audio/oggsplit/Portfile > =================================================================== > --- trunk/dports/audio/oggsplit/Portfile 2009-08-09 15:53:44 UTC > (rev 55338) > +++ trunk/dports/audio/oggsplit/Portfile 2009-08-09 16:01:37 UTC > (rev 55339) > @@ -4,6 +4,7 @@ > > name oggsplit > version 0.1.0 > +revision 1 > categories audio > maintainers yves > description Split multiplexed (grouped or chained) Ogg files > into separate streams > @@ -18,7 +19,7 @@ > > homepage http://www.freshports.org/audio/oggsplit/ > > -master_sites http://homepage.ntlworld.com/jfe1205/OggVorbis/ > +master_sites ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ > > use_bzip2 yes From ryandesign at macports.org Sun Aug 9 15:43:16 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 9 Aug 2009 17:43:16 -0500 Subject: Where to start: pointers? links? tickets? In-Reply-To: <4A7F3E8C.1080203@macports.org> References: <20090808201538.GX609@ninagal.withay.com> <5730E75F-37CF-44EC-95E0-F723B5190241@macports.org> <4A7F3E8C.1080203@macports.org> Message-ID: <178F8018-F011-4912-8192-4830E2B50AF1@macports.org> On Aug 9, 2009, at 16:24, Rainer M?ller wrote: > Watch out that at the time of configure no other MacPorts installation > is visible on PATH! You want to link against the system libraries, not > another MacPorts prefix. Yes! To do this, I use: export PATH="/bin:/sbin:/usr/bin:/usr/sbin" I often have the tcl port installed, which by default does not include thread support, but MacPorts requires thread support in tcl. Apple's tcl comes with thread support by default. So if I don't use the above, my MacPorts build fails. From takeshi at macports.org Sun Aug 9 16:38:54 2009 From: takeshi at macports.org (Takeshi Enomoto) Date: Mon, 10 Aug 2009 08:38:54 +0900 Subject: netcdf Message-ID: <2dc53b910908091638g1d9c657qc9fd753b0ee0c0ef@mail.gmail.com> Hi, I decided to take over the maintenance of netcdf. I made netcdf built without --enable-netcdf-4 by removing netcdf4 and dap from default variants. This removes new features but made much more compatible with many existing packages. For a few exceptions such as nco, cdo and wgrib2, one can build netcdf and these packages with +netcdf4. Quote from the homepage: Note: the netCDF-4.x releases will only build with the netCDF-4 enhanced features if "--enable-netcdf-4" is provided as a configure option. By default the distribution will build the classic netCDF-3 library. We believe that most users will not need the enhanced netCDF-4 features at this time. The packages maintained by volunteers other than myself does not seem to be modified for netcdf4. Takeshi From ryandesign at macports.org Sun Aug 9 20:11:47 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 9 Aug 2009 22:11:47 -0500 Subject: Where to start: pointers? links? tickets? In-Reply-To: <6adc49070908091903o9b896d3xaa049a5dba623fa3@mail.gmail.com> References: <20090808201538.GX609@ninagal.withay.com> <5730E75F-37CF-44EC-95E0-F723B5190241@macports.org> <698C2A27-173C-408B-A8EE-D6C653A7075E@macports.org> <6adc49070908091903o9b896d3xaa049a5dba623fa3@mail.gmail.com> Message-ID: <06FEA4F7-4834-4C7A-A0B6-89CF53981724@macports.org> On Aug 9, 2009, at 21:03, Arno Hautala wrote: > On Sun, Aug 9, 2009 at 17:17, Ryan Schmidt wrote: > >> You need more than just the --prefix argument to the ./configure >> script >> though. You also need to tell it to put the Tcl package, >> applications and >> frameworks in different places, otherwise they will overwrite >> those files in >> your other MacPorts install. For example you could use: >> ... > > I ran something similar in setting up my development prefix. But, I'm > not sure that I included the applications and frameworks options. How > can I check the current prefix values? applications_dir and framework_dir are listed in your macports.conf. The tclpackage directory is wherever you now have a directory "macports1.0" on your hard drive. The default is /Library/Tcl. From giorgio_v at macports.org Sun Aug 9 22:11:15 2009 From: giorgio_v at macports.org (Giorgio Valoti) Date: Mon, 10 Aug 2009 07:11:15 +0200 Subject: Where to start: pointers? links? tickets? In-Reply-To: <698C2A27-173C-408B-A8EE-D6C653A7075E@macports.org> References: <20090808201538.GX609@ninagal.withay.com> <5730E75F-37CF-44EC-95E0-F723B5190241@macports.org> <698C2A27-173C-408B-A8EE-D6C653A7075E@macports.org> Message-ID: <18099387-AF28-4816-B1EB-7B37D15F835A@macports.org> Il giorno 09/ago/09, alle ore 23:17, Ryan Schmidt ha scritto: > [?] >> >> I?m already maintaining some ports, I was thinking doing something >> on the lower levels. I took a look at some tickets listed here: >> > > >> >> Maybe I?ll find something to start with. > > It's ambitious! Understanding how base works is a lot more involved > than understanding how portfiles work. But feel free to dive in. We > could certainly use more people working on base. Yeah, most surely I?m too much ambitious! And let?s hope not to be completely drawn away by daily projects, I?m just emerging from crunch- mode one. -- Giorgio Valoti From afb at macports.org Sun Aug 9 23:41:56 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Mon, 10 Aug 2009 08:41:56 +0200 Subject: use_xz? In-Reply-To: <7A8A2606-F132-485E-8137-83FB0A1C564C@macports.org> References: <20090808193031.GQ1360@prunille.vinc17.org> <7A8A2606-F132-485E-8137-83FB0A1C564C@macports.org> Message-ID: <0CF4F559-65CD-4AE5-AF8B-72EA9513B89A@macports.org> Ryan Schmidt wrote: > On Aug 8, 2009, at 14:30, Vincent Lefevre wrote: > >> Does MacPorts have a use_xz variable? Some tarballs are now >> distributed >> in both gz and xz compression format, and xz is significantly smaller >> than gz. For instance, for the coreutils 7.4: >> >> .tar.gz 9.3 MB >> .tar.xz 3.9 MB > > No, I had not heard of xz until you mentioned it here. It can be > added. XZ is the new version of LZMA (from 7-zip), which might be more familiar. There is no major difference in general compression between the two formats, the changes are with file magic and checksums and multithreading and so on. It is slow to compress but fast to expand (2-3 times faster than bzip2), which is why it (LZMA compression) is popular for software distribution... MacPorts has support for creating XZ archives (.txz) and packages (rpm5) > But it looks like there is only an xz-devel port for version > 4.999.8beta; no stable version available. They also state they > prefer users to build the latest version in git rather than use the > beta. Perhaps we should wait until their development cycle slows > down a bit, a stable version is released and an xz port is created > before promoting the use of these archives? From their homepage it > looks like the .xv format was only stabilized in version > 4.999.7beta from December 2008, assuming they don't change their > mind and change the format again. The format is released, it is the code that isn't. You can still use .lzma if you don't trust the .xz format, the XZ tools can expand .lzma as well. Slackware Linux have changed all their packages from .tgz to .txz already, and Fedora 12 are recompressing all packages with XZ instead of old Gzip. --anders From david.osguthorpe at gmail.com Mon Aug 10 07:50:58 2009 From: david.osguthorpe at gmail.com (David Osguthorpe) Date: Mon, 10 Aug 2009 08:50:58 -0600 Subject: [MacPorts] #20626: patch to allow for proper functioning of pre-/post- install/uninstall/activate/deactivate procs In-Reply-To: <071.5891723d5303de4bca025a0da90b8544@macports.org> References: <062.57fbaa92779fb011806b788b1f2e3cef@macports.org> <071.5891723d5303de4bca025a0da90b8544@macports.org> Message-ID: <20090810145058.GA2005@mactelhm.local> > > Comment: > > I'd rather make these into real targets than replicate all this > infrastructure. Also, it might be better to wait until after the images- > and-archives branch is merged. > I dont think this is possible - what would deactivate/uninstall depend on? they cannot depend on install or activate (think what would happen if you then said uninstall a target that was not installed - it would install the target just to uninstall it - so you would always need a special check to detect that the target was already activated/installed first) do you like the internal munging of port install to port activate? also if port activate is the final phase the instructions for macports should read: to install a port with macports use the command port activate they also cannot be the same as install targets as deactivate/uninstall are not performed in the same environment - there is no work path, no destroot etc. (this is also true of activate - if you do install->deactivate->activate that last activate no longer has the work path/destroot etc. environment - probably why currently on that last activate no pre-/post- procs are run) in addition you would have to get the whole target system to somehow read the old version of the Portfile (do you know how to do this? - I thought about this but it looked as though it would require far more modifications than this working implementation) when will the image/archive branch be merged? David From jmr at macports.org Mon Aug 10 09:00:50 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 11 Aug 2009 02:00:50 +1000 Subject: [MacPorts] #20626: patch to allow for proper functioning of pre-/post- install/uninstall/activate/deactivate procs In-Reply-To: <20090810145058.GA2005@mactelhm.local> References: <062.57fbaa92779fb011806b788b1f2e3cef@macports.org> <071.5891723d5303de4bca025a0da90b8544@macports.org> <20090810145058.GA2005@mactelhm.local> Message-ID: <4A804432.5010402@macports.org> On 2009-8-11 00:50, David Osguthorpe wrote: >> Comment: >> >> I'd rather make these into real targets than replicate all this >> infrastructure. Also, it might be better to wait until after the images- >> and-archives branch is merged. >> > > I dont think this is possible - what would deactivate/uninstall depend on? Nothing. > they also cannot be the same as install targets as deactivate/uninstall are not > performed in the same environment - there is no work path, no destroot etc. I don't know what you mean by "the same as". There are constraints on what you can do there, sure. > in addition you would have to get the whole target system to somehow read the old > version of the Portfile (do you know how to do this? - I thought about this but > it looked as though it would require far more modifications than this working > implementation) Everything needed to run this stuff should live somewhere in the registry. > when will the image/archive branch be merged? When it's done. - Josh From jameskyle at macports.org Mon Aug 10 11:57:38 2009 From: jameskyle at macports.org (James Kyle) Date: Mon, 10 Aug 2009 11:57:38 -0700 Subject: Dual installs of macports collisions Message-ID: <9017D644-5B2B-4E64-B1E6-54353EFF7412@macports.org> I have two installations of macports in two different --prefixs. they're install registries seem to be stomping on each other. I have a feeling it's this: /Library/Tcl/macports1.0/ Would this be the configure value to set to prevent collisions: --with- tclpackage? If not, how can I prevent this? -james From ryandesign at macports.org Mon Aug 10 17:09:07 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 10 Aug 2009 19:09:07 -0500 Subject: Dual installs of macports collisions In-Reply-To: <9017D644-5B2B-4E64-B1E6-54353EFF7412@macports.org> References: <9017D644-5B2B-4E64-B1E6-54353EFF7412@macports.org> Message-ID: On Aug 10, 2009, at 13:57, James Kyle wrote: > I have two installations of macports in two different --prefixs. > they're install registries seem to be stomping on each other. > > I have a feeling it's this: /Library/Tcl/macports1.0/ > > Would this be the configure value to set to prevent collisions: -- > with-tclpackage? Yes. You should also set --with-applications-dir and --with- frameworks-dir so they don't collide either. > If not, how can I prevent this? From ryandesign at macports.org Mon Aug 10 17:09:12 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 10 Aug 2009 19:09:12 -0500 Subject: editors/sigil In-Reply-To: <20090810142930.D294F22FE56E@beta.macosforge.org> References: <20090810142930.D294F22FE56E@beta.macosforge.org> Message-ID: <48B62204-3236-4CA0-8127-F248C425DDA3@macports.org> On Aug 10, 2009, at 08:57, krischik at macports.org wrote: > Revision: 55419 > http://trac.macports.org/changeset/55419 > Author: krischik at macports.org > Date: 2009-08-10 06:57:38 -0700 (Mon, 10 Aug 2009) > Log Message: > ----------- > Sigil, the ePub editor > Modified: trunk/dports/editors/sigil/Portfile > =================================================================== > --- trunk/dports/devel/gnat-xmlada/Portfile 2009-06-30 11:53:09 UTC > (rev 53153) > +++ trunk/dports/editors/sigil/Portfile 2009-08-10 13:57:38 UTC > (rev 55419) sigil doesn't seem to be related at all to gnat-xmlada, so it's confusing that you created this port by "svn cp"ing that one. > +master_sites googlecode:sigil This can be simplified to master_sites googlecode > +distfiles Sigil_code_${version}.zip > +worksrcdir Sigil_code_${version}/src This can be simplified to distname Sigil_code_${version} worksrcdir ${distname}/src Although, in the configure phase below, I see you want to be outside the src directory. So it might be more straightforward to leave worksrcpath at its default of ${distname} and set build.dir to $ {worksrcpath}/src instead. Then again, you don't appear to want to be in the src directory in the build phase either; there, you're in the build directory. So, when is it that you want to be in the src directory? > use_configure yes This is the default; you don't need to state it. > +configure { > + system " > + if test ! -x /opt/local/bin/qmake ; then > + ln -s /opt/local/libexec/qt4-mac/bin/qmake /opt/local/bin; > + fi; > + mkdir -p ${workpath}/build; > + pushd ${workpath}/build; > + cmake -G \"Unix Makefiles\" ${workpath}/${worksrcdir}/Sigil; > + popd; > + " > } > +build { > + system " > + pushd ${workpath}/build; > + typeset -x LIBRARY_PATH=/opt/local/lib; > + gmake Sigil; > + popd; > + " > +} Is there a reason you're doing things in bash here instead of tcl? It looks like you're creating a symlink at ${prefix}/bin/qmake, outside of the destroot. Ports should not create files outside the destroot like this. Since you're using cmake and gmake to build, you should declare build dependencies on the cmake and gmake ports. On Aug 10, 2009, at 09:29, krischik at macports.org wrote: > Revision: 55422 > http://trac.macports.org/changeset/55422 > Author: krischik at macports.org > Date: 2009-08-10 07:29:30 -0700 (Mon, 10 Aug 2009) > Log Message: > ----------- > a few /opt/local slipped in again > Modified: trunk/dports/editors/sigil/Portfile > @@ -49,7 +49,7 @@ > build { > system " > pushd ${workpath}/build; > - typeset -x LIBRARY_PATH=/opt/local/lib; > + typeset -x LIBRARY_PATH=${prefix}; > gmake Sigil; > popd; > " Did you mean to replace /opt/local/lib with ${prefix} here? Or should it be ${prefix}/lib? From ryandesign at macports.org Mon Aug 10 20:24:49 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 10 Aug 2009 22:24:49 -0500 Subject: [55457] trunk/dports/irc In-Reply-To: <20090811031624.F0368230DE9A@beta.macosforge.org> References: <20090811031624.F0368230DE9A@beta.macosforge.org> Message-ID: <1ECD2745-62A8-418D-A8AD-11641207CAA3@macports.org> On Aug 10, 2009, at 22:16, toby at macports.org wrote: > Revision: 55457 > http://trac.macports.org/changeset/55457 > Author: toby at macports.org > Date: 2009-08-10 20:16:24 -0700 (Mon, 10 Aug 2009) > Log Message: > ----------- > livecheck > > Modified Paths: > -------------- > trunk/dports/irc/epic4/Portfile > trunk/dports/irc/epic5/Portfile > +livecheck.regex ${name}-(\[0-9\\.\]+)\\.tar FYI, inside a character class (between square brackets) a period doesn't have a special meaning, so you don't need to put a backslash before it like you do outside of a character class. From ryandesign at macports.org Tue Aug 11 01:32:51 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 11 Aug 2009 03:32:51 -0500 Subject: [55459] trunk/doc-new/guide/xml/portfiledev.xml In-Reply-To: <20090811061321.20BFD230F65B@beta.macosforge.org> References: <20090811061321.20BFD230F65B@beta.macosforge.org> Message-ID: <9015ABCE-F001-4CD7-9290-E7C350AF8D85@macports.org> On Aug 11, 2009, at 01:13, snc at macports.org wrote: > Revision: 55459 > http://trac.macports.org/changeset/55459 > Author: snc at macports.org > Date: 2009-08-10 23:13:17 -0700 (Mon, 10 Aug 2009) > Log Message: > ----------- > add basic ideas for licenses -- keep commented out until such > policy is formed > > Modified Paths: > -------------- > trunk/doc-new/guide/xml/portfiledev.xml > + Port license > + > + A port's license indicates the class of license > employed by the > + owner. Setting this signals the main intentions of the > license with > + respect to binary and source distribution. It is presently > only for > + informational purposes and MacPorts does not distribute > binaries. Since MacPorts doesn't distribute binaries, and won't for a long time (unless someone suddenly writes a lot of code), I would omit all reference to it, in this introduction here and in license descriptions below. > + GPL ? signifies the > requirements of GNU > + General Public License; the source be available in > the same place > + as the binary. > + > + LGPL ? use this for the GNU > Lesser General > + Public License, which mandates that the source > and binary are > + available in the same place. > + > + BSD ? covering the original > and new BSD > + license as well as MIT and Apache; these licenses > allow for optional > + inclusion of source code. > + > + Artistic ? aptly named to > indicate the > + Artistic license and derivatives. > + > + Artistic-GPL ? dual-licensed > under the > + Artistic and GPL licenses. > + > + /GFDL and /LDP varname> ? these > + suffixes indicate that the documentation provided is > under the GNU > + Free Documentation License or the Linux Documentation > Project Wouldn't you want to list the actual license? If the project is licensed under the MIT license, I would have thought the keyword would read "MIT", not "BSD". It might also be better to just link to the canonical version of each license, rather than try to summarize each one. > + RESTRICT ? when the licenses are > + restrictive. > + > + RESTRICT-EYESONLY ? if the > license does not > + permit distribution. > + > + PUBLIC ? the code is not > copyrighted: > + anyone can do anything I don't think these need to be in all caps. The others only are because they're acronyms. For "restrict", restrictive how? For "restrict-eyesonly", distribution of what? From krischik at macports.org Tue Aug 11 02:44:16 2009 From: krischik at macports.org (Martin Krischik) Date: Tue, 11 Aug 2009 11:44:16 +0200 Subject: editors/sigil In-Reply-To: <48B62204-3236-4CA0-8127-F248C425DDA3@macports.org> References: <20090810142930.D294F22FE56E@beta.macosforge.org> <48B62204-3236-4CA0-8127-F248C425DDA3@macports.org> Message-ID: <4A813D70.3000903@macports.org> Hi Ryan. Am 11.08.2009 um 02:09 schrieb Ryan Schmidt: > > On Aug 10, 2009, at 08:57, krischik at macports.org wrote: > >> Revision: 55419 >> http://trac.macports.org/changeset/55419 >> Author: krischik at macports.org >> Date: 2009-08-10 06:57:38 -0700 (Mon, 10 Aug 2009) >> Log Message: >> ----------- >> Sigil, the ePub editor > > >> Modified: trunk/dports/editors/sigil/Portfile >> =================================================================== >> --- trunk/dports/devel/gnat-xmlada/Portfile 2009-06-30 11:53:09 UTC >> (rev 53153) >> +++ trunk/dports/editors/sigil/Portfile 2009-08-10 13:57:38 UTC (rev >> 55419) > > sigil doesn't seem to be related at all to gnat-xmlada, so it's > confusing that you created this port by "svn cp"ing that one. If I "svn copy" then I get the meta data setup correctly. > > >> +master_sites googlecode:sigil > > This can be simplified to > > master_sites googlecode > > >> +distfiles Sigil_code_${version}.zip >> +worksrcdir Sigil_code_${version}/src > > This can be simplified to > > distname Sigil_code_${version} > worksrcdir ${distname}/src That was wrong - has been changed after talking to author. > > Although, in the configure phase below, I see you want to be outside > the src directory. So it might be more straightforward to leave > worksrcpath at its default of ${distname} and set build.dir to > ${worksrcpath}/src instead. > > Then again, you don't appear to want to be in the src directory in the > build phase either; there, you're in the build directory. So, when is > it that you want to be in the src directory? > > >> use_configure yes > > This is the default; you don't need to state it. > I removed it. > >> +configure { >> + system " >> + if test ! -x /opt/local/bin/qmake ; then >> + ln -s /opt/local/libexec/qt4-mac/bin/qmake /opt/local/bin; >> + fi; >> + mkdir -p ${workpath}/build; >> + pushd ${workpath}/build; >> + cmake -G \"Unix Makefiles\" ${workpath}/${worksrcdir}/Sigil; >> + popd; >> + " >> } > > >> +build { >> + system " >> + pushd ${workpath}/build; >> + typeset -x LIBRARY_PATH=/opt/local/lib; >> + gmake Sigil; >> + popd; >> + " >> +} > > > Is there a reason you're doing things in bash here instead of tcl? Apart from the fact that I have 10 years experience in writing shell scripts and only microscopic experience in tcl script? No. But after conferring with the author the build process is now a lot simpler - so I might turn it into tcl with the next release. > > It looks like you're creating a symlink at ${prefix}/bin/qmake, > outside of the destroot. Ports should not create files outside the > destroot like this. We have two ports to create qmake: lrwxr-xr-x 1 root admin 36 23. Jun 23:24 /opt/local/bin/qmake-kde -> /opt/local/libexec/qt4-kde/bin/qmake* lrwxr-xr-x 1 root admin 36 10. Aug 12:35 /opt/local/bin/qmake-mac -> /opt/local/libexec/qt4-mac/bin/qmake* but none to create /opt/local/bin/qmake itself. But I found a different solution which won't need the symlink. > > Since you're using cmake and gmake to build, you should declare build > dependencies on the cmake and gmake ports. Done that. > > > On Aug 10, 2009, at 09:29, krischik at macports.org wrote: > >> Revision: 55422 >> http://trac.macports.org/changeset/55422 >> Author: krischik at macports.org >> Date: 2009-08-10 07:29:30 -0700 (Mon, 10 Aug 2009) >> Log Message: >> ----------- >> a few /opt/local slipped in again > > >> Modified: trunk/dports/editors/sigil/Portfile > > >> @@ -49,7 +49,7 @@ >> build { >> system " >> pushd ${workpath}/build; >> - typeset -x LIBRARY_PATH=/opt/local/lib; >> + typeset -x LIBRARY_PATH=${prefix}; >> gmake Sigil; >> popd; >> " > > Did you mean to replace /opt/local/lib with ${prefix} here? Or should > it be ${prefix}/lib? > That line is not needed any more and has been removed. Martin -- Martin Krischik -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryandesign at macports.org Tue Aug 11 18:29:53 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 11 Aug 2009 20:29:53 -0500 Subject: Trac can't synchronize with the repository Message-ID: <99F5D051-637E-433D-9C21-3D959D3AB749@macports.org> Just tried to save a ticket note in Trac and it said: Warning: Can't synchronize with the repository (Unsupported version control system "svn": "dlopen(/opt/local/lib/svn-python2.5/libsvn/ _fs.so, 2): Symbol not found: _svn_mergeinfo__intersect2 Referenced from: /opt/local/lib/libsvn_client-1.0.dylib Expected in: /opt/local/ lib/libsvn_subr-1.0.dylib " ). Look in the Trac log for more information. From wsiegrist at apple.com Tue Aug 11 18:31:55 2009 From: wsiegrist at apple.com (William Siegrist) Date: Tue, 11 Aug 2009 18:31:55 -0700 Subject: Trac can't synchronize with the repository In-Reply-To: <99F5D051-637E-433D-9C21-3D959D3AB749@macports.org> References: <99F5D051-637E-433D-9C21-3D959D3AB749@macports.org> Message-ID: <1310C532-7A4F-4EDF-BA82-D50C32454BDD@apple.com> On Aug 11, 2009, at 6:29 PM, Ryan Schmidt wrote: > Just tried to save a ticket note in Trac and it said: > > > Warning: Can't synchronize with the repository (Unsupported version > control system "svn": "dlopen(/opt/local/lib/svn-python2.5/libsvn/ > _fs.so, 2): Symbol not found: _svn_mergeinfo__intersect2 Referenced > from: /opt/local/lib/libsvn_client-1.0.dylib Expected in: /opt/local/ > lib/libsvn_subr-1.0.dylib " ). Look in the Trac log for more > information. > I'm upgrading subversion. This stuff gets announced on IRC ahead of time, but I know you're not on there. -Bill From ryandesign at macports.org Tue Aug 11 18:41:56 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 11 Aug 2009 20:41:56 -0500 Subject: Trac can't synchronize with the repository In-Reply-To: <1310C532-7A4F-4EDF-BA82-D50C32454BDD@apple.com> References: <99F5D051-637E-433D-9C21-3D959D3AB749@macports.org> <1310C532-7A4F-4EDF-BA82-D50C32454BDD@apple.com> Message-ID: <6F0483AE-987B-4770-B46C-2149A7E5B86F@macports.org> On Aug 11, 2009, at 20:31, William Siegrist wrote: > On Aug 11, 2009, at 6:29 PM, Ryan Schmidt wrote: > >> Just tried to save a ticket note in Trac and it said: >> >> >> Warning: Can't synchronize with the repository (Unsupported >> version control system "svn": "dlopen(/opt/local/lib/svn-python2.5/ >> libsvn/_fs.so, 2): Symbol not found: _svn_mergeinfo__intersect2 >> Referenced from: /opt/local/lib/libsvn_client-1.0.dylib Expected >> in: /opt/local/lib/libsvn_subr-1.0.dylib " ). Look in the Trac log >> for more information. > > I'm upgrading subversion. This stuff gets announced on IRC ahead of > time, but I know you're not on there. Oh. Perhaps this could be announced on macports-dev? From wsiegrist at apple.com Tue Aug 11 18:45:30 2009 From: wsiegrist at apple.com (William Siegrist) Date: Tue, 11 Aug 2009 18:45:30 -0700 Subject: Trac can't synchronize with the repository In-Reply-To: <6F0483AE-987B-4770-B46C-2149A7E5B86F@macports.org> References: <99F5D051-637E-433D-9C21-3D959D3AB749@macports.org> <1310C532-7A4F-4EDF-BA82-D50C32454BDD@apple.com> <6F0483AE-987B-4770-B46C-2149A7E5B86F@macports.org> Message-ID: <0A10EC8F-76B0-482F-B1FE-39C8CF3F86A0@apple.com> On Aug 11, 2009, at 6:41 PM, Ryan Schmidt wrote: > > On Aug 11, 2009, at 20:31, William Siegrist wrote: > >> On Aug 11, 2009, at 6:29 PM, Ryan Schmidt wrote: >> >>> Just tried to save a ticket note in Trac and it said: >>> >>> >>> Warning: Can't synchronize with the repository (Unsupported >>> version control system "svn": "dlopen(/opt/local/lib/svn-python2.5/ >>> libsvn/_fs.so, 2): Symbol not found: _svn_mergeinfo__intersect2 >>> Referenced from: /opt/local/lib/libsvn_client-1.0.dylib Expected >>> in: /opt/local/lib/libsvn_subr-1.0.dylib " ). Look in the Trac log >>> for more information. >> >> I'm upgrading subversion. This stuff gets announced on IRC ahead of >> time, but I know you're not on there. > > Oh. Perhaps this could be announced on macports-dev? > It was just a warning (and lack of Trac browser) for all of 15m. We've always just used IRC for this stuff. -Bill From raimue at macports.org Wed Aug 12 07:00:34 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 12 Aug 2009 16:00:34 +0200 Subject: Trac can't synchronize with the repository In-Reply-To: <0A10EC8F-76B0-482F-B1FE-39C8CF3F86A0@apple.com> References: <99F5D051-637E-433D-9C21-3D959D3AB749@macports.org> <1310C532-7A4F-4EDF-BA82-D50C32454BDD@apple.com> <6F0483AE-987B-4770-B46C-2149A7E5B86F@macports.org> <0A10EC8F-76B0-482F-B1FE-39C8CF3F86A0@apple.com> Message-ID: <4A82CB02.1090800@macports.org> On 2009-08-12 03:45 , William Siegrist wrote: > On Aug 11, 2009, at 6:41 PM, Ryan Schmidt wrote: >> Oh. Perhaps this could be announced on macports-dev? >> > > It was just a warning (and lack of Trac browser) for all of 15m. > We've always just used IRC for this stuff. I don't think we need to announce such short downtimes on the mailing list if they will only last for a few minutes. Just generates unnecessary noise. Rainer From jeremy at lavergne.gotdns.org Wed Aug 12 07:49:35 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 12 Aug 2009 10:49:35 -0400 Subject: Fetching Message-ID: An anonymous user appeared on IRC today to discuss segmented downloading. While he had suggested we allow the user to pick a downloading client, we pressed our goal of staying with as much system- provided utilities for core operations as possible. To that end, I'd like to start up some discussion in our mailing list regarding a few aspects of the fetch phase. With the advent of 1.8.0, we will have a faster dependency search. This will allow us to quickly find all the ports associated with a build and begin downloading them. While we could perform all these downloads before we commence building, why not have them be done in parallel [1]? Similarly, taking the aspect of segmented downloading, would we be interested in having an even number of segments as there are mirrors for a port? That is, one instance of curl will download the first third of the file from the main site, a second third from the first mirror, and the final portion from the last mirror; hopefully all three finish in the same time as a third of the original download since you may be maximizing your download capacity [2]. I feel that the latter functionality should be an opt-in feature, as some users may not want to suck up their bandwidth. The former should definitely be implemented as there is no reason to wait for a build to finish before fetching more files. Your thoughts, gentlemen? [1] http://trac.macports.org/ticket/2421 [2] https://trac.macports.org/ticket/20652 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jmr at macports.org Wed Aug 12 07:57:01 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 13 Aug 2009 00:57:01 +1000 Subject: Fetching In-Reply-To: References: Message-ID: <4A82D83D.4060507@macports.org> On 2009-8-13 00:49, Jeremy Lavergne wrote: > With the advent of 1.8.0, we will have a faster dependency search. This > will allow us to quickly find all the ports associated with a build and > begin downloading them. While we could perform all these downloads > before we commence building, why not have them be done in parallel [1]? I'd take it further and do everything in parallel if possible. This would of course require expressing the dependency graph on a per-phase basis, and there would need to be limits on how many ports should be in a given phase at once (based on available bandwidth for fetch, available CPUs/RAM for build, etc). Something for MacPorts 2.0 perhaps. ;-) - Josh From jeremy at lavergne.gotdns.org Wed Aug 12 08:03:00 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 12 Aug 2009 11:03:00 -0400 Subject: Fetching In-Reply-To: <4A82D83D.4060507@macports.org> References: <4A82D83D.4060507@macports.org> Message-ID: <0B22A792-4E45-4D0C-889D-C908CCFA60EF@lavergne.gotdns.org> On Aug 12, 2009, at 10:57 AM, Joshua Root wrote: > On 2009-8-13 00:49, Jeremy Lavergne wrote: >> With the advent of 1.8.0, we will have a faster dependency search. >> This will allow us to quickly find all the ports associated with a >> build and begin downloading them. While we could perform all these >> downloads before we commence building, why not have them be done in >> parallel [1]? > > I'd take it further and do everything in parallel if possible. This > would of course require expressing the dependency graph on a per- > phase basis, and there would need to be limits on how many ports > should be in a given phase at once (based on available bandwidth for > fetch, available CPUs/RAM for build, etc). I thought we already had the dependencies separated by phase in 1.8.0? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jmr at macports.org Wed Aug 12 08:11:28 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 13 Aug 2009 01:11:28 +1000 Subject: Fetching In-Reply-To: <0B22A792-4E45-4D0C-889D-C908CCFA60EF@lavergne.gotdns.org> References: <4A82D83D.4060507@macports.org> <0B22A792-4E45-4D0C-889D-C908CCFA60EF@lavergne.gotdns.org> Message-ID: <4A82DBA0.5030208@macports.org> On 2009-8-13 01:03, Jeremy Lavergne wrote: > I thought we already had the dependencies separated by phase in 1.8.0? Not really. It installs everything that will be needed for whatever operation you're doing on the requested port, right at the start. - Josh From jeremy at lavergne.gotdns.org Wed Aug 12 08:14:19 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 12 Aug 2009 11:14:19 -0400 Subject: Fetching In-Reply-To: <4A82DBA0.5030208@macports.org> References: <4A82D83D.4060507@macports.org> <0B22A792-4E45-4D0C-889D-C908CCFA60EF@lavergne.gotdns.org> <4A82DBA0.5030208@macports.org> Message-ID: <06C6D2FF-BF04-42E6-964B-27CA54AA70BC@lavergne.gotdns.org> On Aug 12, 2009, at 11:11 AM, Joshua Root wrote: > On 2009-8-13 01:03, Jeremy Lavergne wrote: >> I thought we already had the dependencies separated by phase in >> 1.8.0? > > Not really. It installs everything that will be needed for whatever > operation you're doing on the requested port, right at the start. Oh, I misunderstood what you meant. I thought you meant we weren't discerning what was needed for build versus run versus library. My bad. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From talklists at newgeo.com Wed Aug 12 12:30:24 2009 From: talklists at newgeo.com (Scott Haneda) Date: Wed, 12 Aug 2009 12:30:24 -0700 Subject: port install traceroute Message-ID: sudo port -d install traceroute ---> Attempting to fetch libnet-1.1.2.1.tar.gz from ftp://ftp5.usa.openbsd.org/pub/OpenBSD/distfiles Just hangs there, any suggestions? $sudo port -d install tcptraceroute Password: DEBUG: Found port in file:///opt/local/var/macports/sources/rsync.macports.org/release/ports/net/tcptraceroute DEBUG: Changing to port directory: /opt/local/var/macports/sources/ rsync.macports.org/release/ports/net/tcptraceroute DEBUG: setting option os.universal_supported to yes DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided DEBUG: org.macports.distfiles registered provides 'distfiles', a pre- existing procedure. Target override will not be provided DEBUG: adding the default universal variant DEBUG: Requested variant darwin is not provided by port tcptraceroute. DEBUG: Requested variant i386 is not provided by port tcptraceroute. DEBUG: Requested variant macosx is not provided by port tcptraceroute. DEBUG: Found port in file:///opt/local/var/macports/sources/rsync.macports.org/release/ports/net/libnet11 DEBUG: Changing to port directory: /opt/local/var/macports/sources/ rsync.macports.org/release/ports/net/libnet11 DEBUG: setting option os.universal_supported to yes DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided DEBUG: org.macports.distfiles registered provides 'distfiles', a pre- existing procedure. Target override will not be provided DEBUG: adding the default universal variant DEBUG: Requested variant darwin is not provided by port libnet11. DEBUG: Requested variant i386 is not provided by port libnet11. DEBUG: Requested variant macosx is not provided by port libnet11. DEBUG: Searching for dependency: libnet11 DEBUG: Didn't find receipt, going to depspec regex for: libnet11 DEBUG: Found port in file:///opt/local/var/macports/sources/rsync.macports.org/release/ports/net/libpcap DEBUG: Changing to port directory: /opt/local/var/macports/sources/ rsync.macports.org/release/ports/net/libpcap DEBUG: setting option os.universal_supported to yes DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided DEBUG: org.macports.distfiles registered provides 'distfiles', a pre- existing procedure. Target override will not be provided DEBUG: 'universal_variant no' specified, so not adding the default universal variant DEBUG: Requested variant darwin is not provided by port libpcap. DEBUG: Requested variant i386 is not provided by port libpcap. DEBUG: Requested variant macosx is not provided by port libpcap. DEBUG: Searching for dependency: libpcap DEBUG: Didn't find receipt, going to depspec regex for: libpcap DEBUG: Executing org.macports.main (libnet11) ---> Fetching libnet11 DEBUG: Executing org.macports.fetch (libnet11) ---> libnet-1.1.2.1.tar.gz doesn't seem to exist in /opt/local/var/ macports/distfiles/libnet11 DEBUG: Pinging ftp5.freebsd.org... DEBUG: Pinging ftp.uk.FreeBSD.org... DEBUG: Pinging ftp.jp.FreeBSD.org... DEBUG: Pinging ftp.tw.FreeBSD.org... DEBUG: Pinging ftp.ru.FreeBSD.org... DEBUG: Pinging ftp.se.FreeBSD.org... DEBUG: Pinging mirror.aarnet.edu.au... DEBUG: Pinging www.mirrorservice.org... DEBUG: Pinging ftp.FreeBSD.org... DEBUG: Pinging mirror.roothell.org... DEBUG: Pinging ftp-stud.fht-esslingen.de... DEBUG: Pinging carroll.cac.psu.edu... DEBUG: Pinging openbsd.informatik.uni-erlangen.de... DEBUG: Pinging gd.tuwien.ac.at... DEBUG: Pinging ftp.stacken.kth.se... DEBUG: Pinging ftp3.usa.openbsd.org... DEBUG: Pinging ftp5.usa.openbsd.org... DEBUG: Pinging rt.fm... DEBUG: Pinging ftp.openbsd.md5.com.ar... DEBUG: Pinging ftp.jp.openbsd.org... DEBUG: Pinging mirror.internode.on.net... DEBUG: Pinging ftp.chg.ru... DEBUG: Pinging ftp.openbsd.org... DEBUG: Pinging distfiles.macports.org... DEBUG: Pinging arn.se.distfiles.macports.org... DEBUG: ftp5.freebsd.org ping time is 117.277 DEBUG: ftp.uk.FreeBSD.org ping time is 171.247 DEBUG: ftp.jp.FreeBSD.org ping time is 137.070 DEBUG: ftp.tw.FreeBSD.org ping time is 298.463 DEBUG: ftp.ru.FreeBSD.org ping time is 244.206 DEBUG: ftp.se.FreeBSD.org ping time is 195.071 DEBUG: mirror.aarnet.edu.au ping time is 292.123 DEBUG: www.mirrorservice.org ping time is 180.652 DEBUG: ftp.FreeBSD.org ping time is 213.770 DEBUG: mirror.roothell.org ping time is 200.636 DEBUG: ftp-stud.fht-esslingen.de ping time is 190.240 DEBUG: carroll.cac.psu.edu ping time is 109.974 DEBUG: openbsd.informatik.uni-erlangen.de ping time is 184.711 DEBUG: gd.tuwien.ac.at ping time is 215.688 DEBUG: ftp.stacken.kth.se ping time is 188.292 DEBUG: ftp3.usa.openbsd.org ping time is 86.614 DEBUG: ftp5.usa.openbsd.org ping time is 18.401 DEBUG: rt.fm ping time is 76.278 DEBUG: ftp.openbsd.md5.com.ar ping time is 10000 DEBUG: ftp.jp.openbsd.org ping time is 10000 DEBUG: mirror.internode.on.net ping time is 206.519 DEBUG: ftp.chg.ru ping time is 219.816 DEBUG: ftp.openbsd.org ping time is 130.608 DEBUG: distfiles.macports.org ping time is 30.876 DEBUG: arn.se.distfiles.macports.org ping time is 10000 ---> Attempting to fetch libnet-1.1.2.1.tar.gz from ftp://ftp5.usa.openbsd.org/pub/OpenBSD/distfiles -- Scott * If you contact me off list replace talklists@ with scott@ * From blair at orcaware.com Wed Aug 12 12:46:46 2009 From: blair at orcaware.com (Blair Zajac) Date: Wed, 12 Aug 2009 12:46:46 -0700 Subject: port install traceroute In-Reply-To: References: Message-ID: <4A831C26.2050903@orcaware.com> Scott Haneda wrote: > sudo port -d install traceroute Besides this fetch not working, have you tried mtr, the multi-traceroute it's much nicer. Regards, Blair From talklists at newgeo.com Wed Aug 12 12:49:25 2009 From: talklists at newgeo.com (Scott Haneda) Date: Wed, 12 Aug 2009 12:49:25 -0700 Subject: port install traceroute In-Reply-To: References: Message-ID: Got past the other issue, but it will not build, any ideas: $sudo port -d install traceroute Password: DEBUG: Found port in file:///opt/local/var/macports/sources/rsync.macports.org/release/ports/net/traceroute DEBUG: Changing to port directory: /opt/local/var/macports/sources/ rsync.macports.org/release/ports/net/traceroute DEBUG: setting option os.universal_supported to yes DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided DEBUG: org.macports.distfiles registered provides 'distfiles', a pre- existing procedure. Target override will not be provided DEBUG: adding the default universal variant DEBUG: Requested variant darwin is not provided by port traceroute. DEBUG: Requested variant i386 is not provided by port traceroute. DEBUG: Requested variant macosx is not provided by port traceroute. DEBUG: Found port in file:///opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/libtool DEBUG: Changing to port directory: /opt/local/var/macports/sources/ rsync.macports.org/release/ports/devel/libtool DEBUG: setting option os.universal_supported to yes DEBUG: org.macports.load registered provides 'load', a pre-existing procedure. Target override will not be provided DEBUG: org.macports.distfiles registered provides 'distfiles', a pre- existing procedure. Target override will not be provided DEBUG: adding the default universal variant DEBUG: Requested variant darwin is not provided by port libtool. DEBUG: Requested variant i386 is not provided by port libtool. DEBUG: Requested variant macosx is not provided by port libtool. DEBUG: Searching for dependency: libtool DEBUG: Found Dependency: receipt exists for libtool DEBUG: Executing org.macports.main (traceroute) ---> Fetching traceroute DEBUG: Executing org.macports.fetch (traceroute) ---> traceroute-1.4a12.tar.gz doesn't seem to exist in /opt/local/var/ macports/distfiles/traceroute DEBUG: Pinging ftp.ee.lbl.gov... DEBUG: Pinging distfiles.macports.org... DEBUG: Pinging arn.se.distfiles.macports.org... DEBUG: ftp.ee.lbl.gov ping time is 22.360 DEBUG: distfiles.macports.org ping time is 31.056 DEBUG: arn.se.distfiles.macports.org ping time is 10000 ---> Attempting to fetch traceroute-1.4a12.tar.gz from ftp://ftp.ee.lbl.gov/ % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 74917 100 74917 0 0 34109 0 0:00:02 0:00:02 --:--:-- 40539 ---> Verifying checksum(s) for traceroute DEBUG: Executing org.macports.checksum (traceroute) ---> Checksumming traceroute-1.4a12.tar.gz DEBUG: Correct (md5) checksum for traceroute-1.4a12.tar.gz ---> Extracting traceroute DEBUG: Executing org.macports.extract (traceroute) ---> Extracting traceroute-1.4a12.tar.gz DEBUG: setting option extract.args to /opt/local/var/macports/ distfiles/traceroute/traceroute-1.4a12.tar.gz DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.5' DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_net_traceroute/work" && gzip -dc /opt/ local/var/macports/distfiles/traceroute/traceroute-1.4a12.tar.gz | / usr/bin/gnutar --no-same-owner -xf -' DEBUG: Executing org.macports.patch (traceroute) ---> Configuring traceroute DEBUG: Using compiler 'Mac OS X gcc 4.0' DEBUG: Executing proc-pre-org.macports.configure-configure-0 DEBUG: Executing org.macports.configure (traceroute) DEBUG: Environment: CFLAGS='-O2' CPPFLAGS='-I/opt/local/include' CXXFLAGS='-O2' MACOSX_DEPLOYMENT_TARGET='10.5' CPP='/usr/bin/cpp-4.0' CXX='/usr/bin/g++-4.0' F90FLAGS='-O2' LDFLAGS='-L/opt/local/lib' FCFLAGS='-O2' OBJC='/usr/bin/gcc-4.0' INSTALL='/usr/bin/install -c' OBJCFLAGS='-O2' FFLAGS='-O2' CC='/usr/bin/gcc-4.0' DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_net_traceroute/work/traceroute-1.4a12" && ./configure --prefix=/opt/local' creating cache ./config.cache checking host system type... i386-apple-darwin9.8.0 checking target system type... i386-apple-darwin9.8.0 checking build system type... i386-apple-darwin9.8.0 checking for gcc... /usr/bin/gcc-4.0 checking whether the C compiler (/usr/bin/gcc-4.0 -O2 -L/opt/local/ lib) works... yes checking whether the C compiler (/usr/bin/gcc-4.0 -O2 -L/opt/local/ lib) is a cross-compiler... no checking whether we are using GNU C... yes checking whether /usr/bin/gcc-4.0 accepts -g... yes checking how to run the C preprocessor... /usr/bin/cpp-4.0 checking for malloc.h... no checking for sys/select.h... yes checking for sys/sockio.h... yes checking for net/route.h... yes checking for net/if_dl.h... yes checking for inet/mib2.h... no checking for strerror... yes checking for usleep... yes checking for setlinebuf... yes checking for gethostbyname... yes checking for socket... yes checking for putmsg in -lstr... no checking routing table type... socket checking for int32_t using /usr/bin/gcc-4.0... yes checking for u_int32_t using /usr/bin/gcc-4.0... yes checking if sockaddr struct has sa_len member... yes checking if struct icmp has icmp_nextmtu... yes checking for a BSD compatible install... /usr/bin/install -c updating cache ./config.cache creating ./config.status creating Makefile ---> Building traceroute DEBUG: Executing org.macports.build (traceroute) DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.5' DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_net_traceroute/work/traceroute-1.4a12" && make all' /usr/bin/gcc-4.0 -O -O2 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_SOCKIO_H=1 - DHAVE_NET_ROUTE_H=1 -DHAVE_NET_IF_DL_H=1 -DHAVE_STRERROR=1 - DHAVE_USLEEP=1 -DHAVE_SETLINEBUF=1 -DHAVE_SOCKADDR_SA_LEN=1 - DHAVE_ICMP_NEXTMTU=1 -I. -c ./traceroute.c ./traceroute.c: In function 'wait_for_reply': ./traceroute.c:909: warning: pointer targets in passing argument 6 of 'recvfrom' differ in signedness /usr/bin/gcc-4.0 -O -O2 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_SOCKIO_H=1 - DHAVE_NET_ROUTE_H=1 -DHAVE_NET_IF_DL_H=1 -DHAVE_STRERROR=1 - DHAVE_USLEEP=1 -DHAVE_SETLINEBUF=1 -DHAVE_SOCKADDR_SA_LEN=1 - DHAVE_ICMP_NEXTMTU=1 -I. -c ./ifaddrlist.c /usr/bin/gcc-4.0 -O -O2 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_SOCKIO_H=1 - DHAVE_NET_ROUTE_H=1 -DHAVE_NET_IF_DL_H=1 -DHAVE_STRERROR=1 - DHAVE_USLEEP=1 -DHAVE_SETLINEBUF=1 -DHAVE_SOCKADDR_SA_LEN=1 - DHAVE_ICMP_NEXTMTU=1 -I. -c ./findsaddr-socket.c ./findsaddr-socket.c: In function 'findsaddr': ./findsaddr-socket.c:193: error: label at end of compound statement make: *** [findsaddr-socket.o] Error 1 Error: Target org.macports.build returned: shell command " cd "/opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_net_traceroute/work/traceroute-1.4a12" && make all " returned error 2 Command output: /usr/bin/gcc-4.0 -O -O2 -DHAVE_SYS_SELECT_H=1 - DHAVE_SYS_SOCKIO_H=1 -DHAVE_NET_ROUTE_H=1 -DHAVE_NET_IF_DL_H=1 - DHAVE_STRERROR=1 -DHAVE_USLEEP=1 -DHAVE_SETLINEBUF=1 - DHAVE_SOCKADDR_SA_LEN=1 -DHAVE_ICMP_NEXTMTU=1 -I. -c ./traceroute.c ./traceroute.c: In function 'wait_for_reply': ./traceroute.c:909: warning: pointer targets in passing argument 6 of 'recvfrom' differ in signedness /usr/bin/gcc-4.0 -O -O2 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_SOCKIO_H=1 - DHAVE_NET_ROUTE_H=1 -DHAVE_NET_IF_DL_H=1 -DHAVE_STRERROR=1 - DHAVE_USLEEP=1 -DHAVE_SETLINEBUF=1 -DHAVE_SOCKADDR_SA_LEN=1 - DHAVE_ICMP_NEXTMTU=1 -I. -c ./ifaddrlist.c /usr/bin/gcc-4.0 -O -O2 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_SOCKIO_H=1 - DHAVE_NET_ROUTE_H=1 -DHAVE_NET_IF_DL_H=1 -DHAVE_STRERROR=1 - DHAVE_USLEEP=1 -DHAVE_SETLINEBUF=1 -DHAVE_SOCKADDR_SA_LEN=1 - DHAVE_ICMP_NEXTMTU=1 -I. -c ./findsaddr-socket.c ./findsaddr-socket.c: In function 'findsaddr': ./findsaddr-socket.c:193: error: label at end of compound statement make: *** [findsaddr-socket.o] Error 1 Warning: the following items did not execute (for traceroute): org.macports.activate org.macports.build org.macports.destroot org.macports.install Error: Status 1 encountered during processing. me at macbook ~ $ On Aug 12, 2009, at 12:30 PM, Scott me wrote: > sudo port -d install traceroute -- Scott * If you contact me off list replace talklists@ with scott@ * From talklists at newgeo.com Wed Aug 12 12:57:12 2009 From: talklists at newgeo.com (Scott Haneda) Date: Wed, 12 Aug 2009 12:57:12 -0700 Subject: port install traceroute In-Reply-To: <4A831C26.2050903@orcaware.com> References: <4A831C26.2050903@orcaware.com> Message-ID: <085DD5F0-AE3C-4E93-A240-B39275499930@newgeo.com> On Aug 12, 2009, at 12:46 PM, Blair Zajac wrote: > Scott Haneda wrote: >> sudo port -d install traceroute > > Besides this fetch not working, have you tried mtr, the multi- > traceroute it's much nicer. Yep, just started using it now, though I would like to find out why my local copy of traceroute on OS X * * * on a lot of places, that a concurrent trace on windows will pass by just fine, or mtr passes just fine for that matter. -- Scott * If you contact me off list replace talklists@ with scott@ * From giorgio_v at macports.org Wed Aug 12 23:23:00 2009 From: giorgio_v at macports.org (Giorgio Valoti) Date: Thu, 13 Aug 2009 08:23:00 +0200 Subject: MacPorts 1.8 beta1: warning messages Message-ID: <7A015DEB-C2C9-4426-92F4-8CFA0978F752@macports.org> Hi, while building a port, I got these warnings, never seen with with previous versions: > Warning: Skipping upgrade since readline 6.0.000_1 >= readline > 6.0.000_1, even though installed variants "" do not match "+darwin". > Use 'upgrade --enforce-variants' to switch to the requested variants. > Warning: Skipping upgrade since openssl 0.9.8k_0 >= openssl > 0.9.8k_0, even though installed variants "" do not match "+darwin". > Use 'upgrade --enforce-variants' to switch to the requested variants. Is it expected? Should I reinstall/upgrade ports cited in the warning messages? Thank you in advance -- Giorgio Valoti From ryandesign at macports.org Wed Aug 12 23:25:59 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 13 Aug 2009 01:25:59 -0500 Subject: [55528] trunk/dports/python In-Reply-To: <20090812225729.54888232C992@beta.macosforge.org> References: <20090812225729.54888232C992@beta.macosforge.org> Message-ID: <1383CFA4-79DC-437E-9664-5BD3A2EFC175@macports.org> On Aug 12, 2009, at 17:57, singingwolfboy at macports.org wrote: > Revision: 55528 > http://trac.macports.org/changeset/55528 > Author: singingwolfboy at macports.org > Date: 2009-08-12 15:57:28 -0700 (Wed, 12 Aug 2009) > Log Message: > ----------- > added portfile for py26-duplicity, based on duplicity portfile > > Added Paths: > ----------- > trunk/dports/python/py26-duplicity/ > trunk/dports/python/py26-duplicity/Portfile For future reference, when you create a new port based on another port, it's usually best to "svn cp" the old port directory to the new one and then make changes. That way it's easy to see what changes were made to get from the one to the other, and it makes "svn log" and "svn blame" work on the new port so that you can still see the reasons why the rest of the lines in the portfile were written the way they were. You also should set up your Subversion autoprops so that svn:keywords=Id and svn:eol-style=native are automatically added to Portfiles. These properties are missing on this Portfile. However, in this case, I don't believe you should have created a new port py26-duplicity. The old port was not py25-duplicity but duplicity, and was not in the python category but the sysutils category. Ports in the python category are Python modules and should ideally exist for multiple Python versions. But Duplicity is just a utility that happened to use Python. If your goal was to get Duplicity to use Python 2.6, then I think the correct course of action is to update the duplicity port, and delete py26-duplicity again. From ryandesign at macports.org Wed Aug 12 23:29:28 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 13 Aug 2009 01:29:28 -0500 Subject: port install traceroute In-Reply-To: References: Message-ID: <525970DF-17BE-4E1F-BCC5-704CADAED90B@macports.org> On Aug 12, 2009, at 14:30, Scott Haneda wrote: > sudo port -d install traceroute > > ---> Attempting to fetch libnet-1.1.2.1.tar.gz from ftp:// > ftp5.usa.openbsd.org/pub/OpenBSD/distfiles > > Just hangs there, any suggestions? That server responds to pings, but when I try to access its FTP URL in Firefox it hangs for me too. Joshua removed it from the mirror list in r55538. From jmr at macports.org Wed Aug 12 23:33:59 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 13 Aug 2009 16:33:59 +1000 Subject: MacPorts 1.8 beta1: warning messages In-Reply-To: <7A015DEB-C2C9-4426-92F4-8CFA0978F752@macports.org> References: <7A015DEB-C2C9-4426-92F4-8CFA0978F752@macports.org> Message-ID: <4A83B3D7.1060104@macports.org> On 2009-8-13 16:23, Giorgio Valoti wrote: > Hi, > while building a port, I got these warnings, never seen with with > previous versions: > >> Warning: Skipping upgrade since readline 6.0.000_1 >= readline >> 6.0.000_1, even though installed variants "" do not match "+darwin". >> Use 'upgrade --enforce-variants' to switch to the requested variants. >> Warning: Skipping upgrade since openssl 0.9.8k_0 >= openssl 0.9.8k_0, >> even though installed variants "" do not match "+darwin". Use 'upgrade >> --enforce-variants' to switch to the requested variants. > > Is it expected? Should I reinstall/upgrade ports cited in the warning > messages? Not only is the warning on non-matching variants new, but there was previously a seemingly misguided check, now removed, which prevented +darwin from being recorded in the registry. Use the --enforce-variants option like the message says if you don't want to see it in future, but in this specific case, it won't change anything about the installed software. - Josh From ryandesign at macports.org Wed Aug 12 23:44:05 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 13 Aug 2009 01:44:05 -0500 Subject: port install traceroute In-Reply-To: References: Message-ID: <3D35DDFB-4079-4AC6-8536-96E7B79F8CF2@macports.org> On Aug 12, 2009, at 14:49, Scott Haneda wrote: > Got past the other issue, but it will not build, any ideas: > > $sudo port -d install traceroute [snip] > ./findsaddr-socket.c: In function 'findsaddr': > ./findsaddr-socket.c:193: error: label at end of compound statement I see this too, and filed a ticket for it: http://trac.macports.org/ticket/20658 From ryandesign at macports.org Thu Aug 13 00:36:00 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 13 Aug 2009 02:36:00 -0500 Subject: port install traceroute In-Reply-To: <3D35DDFB-4079-4AC6-8536-96E7B79F8CF2@macports.org> References: <3D35DDFB-4079-4AC6-8536-96E7B79F8CF2@macports.org> Message-ID: <15D373BF-5214-43ED-94B3-216248BDE338@macports.org> On Aug 13, 2009, at 01:44, Ryan Schmidt wrote: > On Aug 12, 2009, at 14:49, Scott Haneda wrote: > >> Got past the other issue, but it will not build, any ideas: >> >> $sudo port -d install traceroute > > [snip] > >> ./findsaddr-socket.c: In function 'findsaddr': >> ./findsaddr-socket.c:193: error: label at end of compound statement > > I see this too, and filed a ticket for it: > > http://trac.macports.org/ticket/20658 Fixed! From ryandesign at macports.org Thu Aug 13 02:33:41 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 13 Aug 2009 04:33:41 -0500 Subject: How many mirrors is too many Message-ID: I was going to add a php fetch group to mirror_sites.tcl: http://trac.macports.org/ticket/20654 In those places where the list of php mirrors is currently hardcoded (php4, php5, php5extension) there are only 8 mirrors. The full list on the PHP web site shows 114 mirrors in 65 countries. I tried adding all of those to the new fetch group, but in testing it out, MacPorts tried to start 114 simultaneous pings to test the response times of every server. Not only did over half of the pings fail to spawn, none of those that did were answered. I think the attempt didn't go over so well with my wireless router which didn't exactly crash but network traffic slowed to a crawl until I rebooted it. I had wanted to have the php fetch group in mirror_sites.tcl updated automatically from the list on the PHP web site, and already wrote a script to do that. But now it looks like 114 is too many. How many could I reasonably have, and how should I narrow it down? Or should MacPorts base be updated to handle larger mirror groups more gracefully? Maybe it could pick a handful of servers at random and use the fastest of that subset, but the handful it picks at random might by chance be servers that are nowhere near you. Looks like the biggest existing mirror groups are debian (26) and savannah (29) to which you'd add the global MacPorts mirrors. -------------- next part -------------- A non-text attachment was scrubbed... Name: php-fetch-group.diff Type: application/octet-stream Size: 5648 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ping-spawn-fail.txt URL: From ryandesign at macports.org Sat Aug 15 03:06:36 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 15 Aug 2009 05:06:36 -0500 Subject: [55639] contrib/port_cutleaves/port_cutleaves In-Reply-To: <20090815083517.2AD122366F28@beta.macosforge.org> References: <20090815083517.2AD122366F28@beta.macosforge.org> Message-ID: On Aug 15, 2009, at 03:35, jmr at macports.org wrote: > Revision: 55639 > http://trac.macports.org/changeset/55639 > Author: jmr at macports.org > Date: 2009-08-15 01:35:14 -0700 (Sat, 15 Aug 2009) > Log Message: > ----------- > port_cutleaves: add option to keep build deps (info taken from > PortIndex) Cool -- I have that a lot where port_cutleaves says I can uninstall something, and then I have to build it again the next day when I install some port. While you're in there -- how hard would it be to add a flag to always answer "yes" to the "search for more leaves" question? I always want it to. From jeremy at lavergne.gotdns.org Sat Aug 15 07:15:36 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 15 Aug 2009 10:15:36 -0400 Subject: [55639] contrib/port_cutleaves/port_cutleaves In-Reply-To: References: <20090815083517.2AD122366F28@beta.macosforge.org> Message-ID: <9E8512F9-F086-4002-ACB8-9320BF432B16@lavergne.gotdns.org> Archive mode ftw. On Aug 15, 2009, at 6:06 AM, Ryan Schmidt wrote: > Cool -- I have that a lot where port_cutleaves says I can uninstall > something, and then I have to build it again the next day when I > install some port. From ryandesign at macports.org Sun Aug 16 12:42:40 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 16 Aug 2009 14:42:40 -0500 Subject: [55639] contrib/port_cutleaves/port_cutleaves In-Reply-To: <9E8512F9-F086-4002-ACB8-9320BF432B16@lavergne.gotdns.org> References: <20090815083517.2AD122366F28@beta.macosforge.org> <9E8512F9-F086-4002-ACB8-9320BF432B16@lavergne.gotdns.org> Message-ID: <44FC29DA-2516-4974-9046-CF1877F41CED@macports.org> On Aug 15, 2009, at 09:15, Jeremy Lavergne wrote: > On Aug 15, 2009, at 6:06 AM, Ryan Schmidt wrote: > >> Cool -- I have that a lot where port_cutleaves says I can >> uninstall something, and then I have to build it again the next >> day when I install some port. > > > Archive mode ftw. I don't follow... my purpose in uninstalling ports with port_cutleaves is to free up resources on my system by deleting things that are no longer needed. If I left archives of these ports around, I wouldn't be doing a very good job of freeing up resources. The feature Joshua added lets me avoid uninstalling ports that in fact will very likely be needed again soon. From jeremy at lavergne.gotdns.org Sun Aug 16 12:48:52 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sun, 16 Aug 2009 15:48:52 -0400 Subject: [55639] contrib/port_cutleaves/port_cutleaves In-Reply-To: <44FC29DA-2516-4974-9046-CF1877F41CED@macports.org> References: <20090815083517.2AD122366F28@beta.macosforge.org> <9E8512F9-F086-4002-ACB8-9320BF432B16@lavergne.gotdns.org> <44FC29DA-2516-4974-9046-CF1877F41CED@macports.org> Message-ID: <7EB00BA3-5BC8-4060-BCEB-2F521C5124C4@lavergne.gotdns.org> On Aug 16, 2009, at 3:42 PM, Ryan Schmidt wrote: > I don't follow... my purpose in uninstalling ports with > port_cutleaves is to free up resources on my system by deleting > things that are no longer needed. If I left archives of these ports > around, I wouldn't be doing a very good job of freeing up resources. > The feature Joshua added lets me avoid uninstalling ports that in > fact will very likely be needed again soon. Perhaps we can further add another feature: archiving build dependencies while completely removing other ports that are not needed. That would allow you to remove even more resources. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From ryandesign at macports.org Sun Aug 16 12:54:41 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 16 Aug 2009 14:54:41 -0500 Subject: [55651] trunk/dports/editors/sigil/Portfile In-Reply-To: <20090816073416.AB8A7236EF4B@beta.macosforge.org> References: <20090816073416.AB8A7236EF4B@beta.macosforge.org> Message-ID: <7CB74FB0-99D1-4781-B8DF-B7F399476793@macports.org> On Aug 16, 2009, at 02:34, krischik at macports.org wrote: > Revision: 55651 > http://trac.macports.org/changeset/55651 > Author: krischik at macports.org > Date: 2009-08-16 00:34:11 -0700 (Sun, 16 Aug 2009) > Log Message: > ----------- > new version - which is universal by default - hope I did id the > 'right' way. > +platform x86_64 { > + pre-configure { > + reinplace "s|ppc;i386|x86_64|g" ${worksrcpath}/CMakeLists.txt > + } > +} There isn't any platform x86_64. The only platforms MacPorts has are powerpc and i386. MacPorts 1.8 will have the build_arch variable which you may need to make use of, if available. There are several ports currently which show how to do this in a way that does not break for MacPorts 1.7. You should also ensure your changes don't prevent a universal build from happening when the user does select the +universal variant. From ryandesign at macports.org Sun Aug 16 12:54:50 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 16 Aug 2009 14:54:50 -0500 Subject: [55659] trunk/dports/devel/midgard2-core/Portfile In-Reply-To: <20090816140745.CDACE23706BE@beta.macosforge.org> References: <20090816140745.CDACE23706BE@beta.macosforge.org> Message-ID: On Aug 16, 2009, at 09:07, jwa at macports.org wrote: > Revision: 55659 > http://trac.macports.org/changeset/55659 > Author: jwa at macports.org > Date: 2009-08-16 07:07:42 -0700 (Sun, 16 Aug 2009) > Log Message: > ----------- > added two dependencies after a user tried to install and found out > > Modified Paths: > -------------- > trunk/dports/devel/midgard2-core/Portfile > > Modified: trunk/dports/devel/midgard2-core/Portfile > =================================================================== > --- trunk/dports/devel/midgard2-core/Portfile 2009-08-16 09:54:03 > UTC (rev 55658) > +++ trunk/dports/devel/midgard2-core/Portfile 2009-08-16 14:07:42 > UTC (rev 55659) > @@ -19,7 +19,9 @@ > sha1 > cd4cfb375cfe6e3722fce7509a3d8733f94f4fa6 \ > rmd160 d806dc6c3aa55e5fce5baae2ee19f86ca33b3e1f > > -depends_lib port:glib2 \ > +depends_lib port:pkgconfig \ > + port:gettext \ > + port:glib2 \ pkgconfig is unlikely to be a library dependency; it's only ever used at build time. From blb at macports.org Sun Aug 16 17:08:08 2009 From: blb at macports.org (Bryan Blackburn) Date: Sun, 16 Aug 2009 18:08:08 -0600 Subject: X11 and the guide Message-ID: <20090817000807.GN574@ninagal.withay.com> The guide still lists X11 as either a good thing to have (X11 itself) or a necessity (the X11 SDK); at this point, that should all be removed entirely, correct, since the xorg ports are always used instead? Bryan From ryandesign at macports.org Sun Aug 16 20:05:35 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 16 Aug 2009 22:05:35 -0500 Subject: X11 and the guide In-Reply-To: <20090817000807.GN574@ninagal.withay.com> References: <20090817000807.GN574@ninagal.withay.com> Message-ID: <73C70B41-6333-42E7-AA89-1AA7C40ECA8A@macports.org> On Aug 16, 2009, at 19:08, Bryan Blackburn wrote: > The guide still lists X11 as either a good thing to have (X11 > itself) or a > necessity (the X11 SDK); at this point, that should all be removed > entirely, > correct, since the xorg ports are always used instead? I think so, but I have not actually tried installing MacPorts on a Mac without Apple X11 to make sure it works right. Has anybody else tried this? From jmr at macports.org Sun Aug 16 23:28:06 2009 From: jmr at macports.org (Joshua Root) Date: Mon, 17 Aug 2009 16:28:06 +1000 Subject: X11 and the guide In-Reply-To: <20090817000807.GN574@ninagal.withay.com> References: <20090817000807.GN574@ninagal.withay.com> Message-ID: <4A88F876.4020702@macports.org> On 2009-8-17 10:08, Bryan Blackburn wrote: > The guide still lists X11 as either a good thing to have (X11 itself) or a > necessity (the X11 SDK); at this point, that should all be removed entirely, > correct, since the xorg ports are always used instead? I think base 1.7.1 might still want some of the stuff in x11prefix. We can remove the references to the X11 SDK once 1.8.0 is out. As for X11User, we should just say that you need either it or the xorg-server port in order to run X11 apps. - Josh From jeremyhu at macports.org Sun Aug 16 23:47:22 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sun, 16 Aug 2009 23:47:22 -0700 Subject: X11 and the guide In-Reply-To: <20090817000807.GN574@ninagal.withay.com> References: <20090817000807.GN574@ninagal.withay.com> Message-ID: It's still required for /usr/lib/libXplugin.dylib ... but I the guide still needs to be updated. On Aug 16, 2009, at 17:08, Bryan Blackburn wrote: > The guide still lists X11 as either a good thing to have (X11 > itself) or a > necessity (the X11 SDK); at this point, that should all be removed > entirely, > correct, since the xorg ports are always used instead? > > Bryan > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From devans at macports.org Tue Aug 18 07:12:04 2009 From: devans at macports.org (David Evans) Date: Tue, 18 Aug 2009 07:12:04 -0700 Subject: [55756] trunk/dports/devel/orbit2 In-Reply-To: <20090818125112.6C27523B024C@beta.macosforge.org> References: <20090818125112.6C27523B024C@beta.macosforge.org> Message-ID: <4A8AB6B4.9060806@macports.org> nox at macports.org wrote: > > Revision > 55756 > Author > nox at macports.org > Date > 2009-08-18 05:51:11 -0700 (Tue, 18 Aug 2009) > > > Log Message > > orbit2: Patch gtkdoc-rebase test instead of depending on gtk-doc, as in gtk2. > > > Modified Paths > Please revert this change. It results in the installation of HTML API documentation whose URLs are not properly adjusted (rebased) for the installed paths, breaking links, which affects the ability of devhelp to work properly. This is a standard pattern throughout the various GNOME ports and is there for a reason. (You should think about reverting it in gtk2 as well for the same reason.) I think it is a standard misconception that disabling gtk-doc processing in these ports results in no API documentation being installed. In fact, the documentation is just not regenerated from the source code, but a copy is included in the distribution which needs to be properly rebased to function properly. Thanks for your help Dave From ingmarstein at gmail.com Tue Aug 18 14:33:16 2009 From: ingmarstein at gmail.com (Ingmar J Stein) Date: Tue, 18 Aug 2009 23:33:16 +0200 Subject: tcl_platform in 1.8.99 Message-ID: <2FDD3154-0209-4AA6-B13C-7844F0CCD847@gmail.com> Hi all, I think a "global tcl_platform" is missing in proc macports::selfupdate: DEBUG: can't read "tcl_platform(user)": no such variable while executing "string equal $tcl_platform(user) $owner" (procedure "macports::selfupdate" line 63) invoked from within "macports::selfupdate [array get global_options]" Error: /opt/local/bin/port: port selfupdate failed: can't read "tcl_platform(user)": no such variable Cheers, Ingmar From jmr at macports.org Wed Aug 19 05:04:42 2009 From: jmr at macports.org (Joshua Root) Date: Wed, 19 Aug 2009 22:04:42 +1000 Subject: tcl_platform in 1.8.99 In-Reply-To: <2FDD3154-0209-4AA6-B13C-7844F0CCD847@gmail.com> References: <2FDD3154-0209-4AA6-B13C-7844F0CCD847@gmail.com> Message-ID: <4A8BEA5A.8040304@macports.org> On 2009-8-19 07:33, Ingmar J Stein wrote: > Hi all, > > I think a "global tcl_platform" is missing in proc macports::selfupdate: > > DEBUG: can't read "tcl_platform(user)": no such variable > while executing > "string equal $tcl_platform(user) $owner" > (procedure "macports::selfupdate" line 63) > invoked from within > "macports::selfupdate [array get global_options]" > Error: /opt/local/bin/port: port selfupdate failed: can't read > "tcl_platform(user)": no such variable Good catch. Fixed in svn (r55793/r55794). - Josh From ryandesign at macports.org Wed Aug 19 18:38:41 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 19 Aug 2009 20:38:41 -0500 Subject: [54581] trunk/dports/lang In-Reply-To: <20090802202937.GV634@ninagal.withay.com> References: <20090729200513.387392221F50@beta.macosforge.org> <20090802202937.GV634@ninagal.withay.com> Message-ID: On Aug 2, 2009, at 15:29, Bryan Blackburn wrote: > Should we add a php mirror group to mirror_sites.tcl, to reduce all > that > duplication? Yes, it's high time I did that. Thanks for the suggestion. Done in r55555, r55585. From ryandesign at macports.org Wed Aug 19 18:50:24 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 19 Aug 2009 20:50:24 -0500 Subject: [55811] trunk/dports/kde In-Reply-To: <20090819190821.F3F2423F7F96@beta.macosforge.org> References: <20090819190821.F3F2423F7F96@beta.macosforge.org> Message-ID: On Aug 19, 2009, at 14:08, snc at macports.org wrote: > Added: trunk/dports/kde/oxygen-icons/Portfile [snip] > +PortGroup kde4 1.0 [snip] > +configure.args-append ../${distname} It looks like all 28 ports in the kde4 portgroup currently do this thing with ../${distname} in the configure.args. Can this bit be moved into the portgroup then? Probably it would need to be configure.post_args-append ../${distname} so as to not get in the middle of any other args the port wants to add. From ryandesign at macports.org Wed Aug 19 19:22:24 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 19 Aug 2009 21:22:24 -0500 Subject: [55827] trunk/dports/science/sbsat In-Reply-To: <20090820020319.88A082402707@beta.macosforge.org> References: <20090820020319.88A082402707@beta.macosforge.org> Message-ID: <61BEE925-ADE6-47E8-8182-6408752A260B@macports.org> On Aug 19, 2009, at 21:03, snc at macports.org wrote: > Modified: trunk/dports/science/sbsat/Portfile > =================================================================== > --- trunk/dports/science/sbsat/Portfile 2009-08-20 01:52:53 UTC > (rev 55826) > +++ trunk/dports/science/sbsat/Portfile 2009-08-20 02:03:16 UTC > (rev 55827) > @@ -21,6 +21,19 @@ > sha1 08e9d0a447105fcd36518fab4653fcc8a0973ced \ > rmd160 0ef8e2ee04d54b71fe837407ba3f771cca381636 > > +variant jeremy description {Enable Jeremy's modifications} { > + patchfiles patch-src-generator-Makefile.am.diff \ > + patch-src-generator-gentest.cc.diff \ > + patch-configure.ac.diff > + post-patch { > + file copy ${filespath}/slider3_base.py ${worksrcpath}/src/ > generator/ > + reinplace s|@@PREFIX@@|${prefix}/bin| ${worksrcpath}/src/ > generator/gentest.cc > + } > + > + use_autoreconf yes > + > +} What do these modifications do? :) Why might a user want to use or not use this variant? The variant description isn't very forthcoming. From jeremy at lavergne.gotdns.org Wed Aug 19 19:28:54 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 19 Aug 2009 22:28:54 -0400 Subject: [55827] trunk/dports/science/sbsat In-Reply-To: <61BEE925-ADE6-47E8-8182-6408752A260B@macports.org> References: <20090820020319.88A082402707@beta.macosforge.org> <61BEE925-ADE6-47E8-8182-6408752A260B@macports.org> Message-ID: <5B6FDDCF-60D7-48E4-AF2C-7BC2C8E321A6@lavergne.gotdns.org> It'll entail more and more as the next year or two go on, but right now it's an addition of another slider generator. On Aug 19, 2009, at 10:22 PM, Ryan Schmidt wrote: > What do these modifications do? :) Why might a user want to use or > not use this variant? The variant description isn't very forthcoming. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jeremy at lavergne.gotdns.org Thu Aug 20 04:11:34 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 20 Aug 2009 07:11:34 -0400 Subject: [55848] trunk/dports/devel/autoconf In-Reply-To: <20090820110641.48E9F240AD6A@beta.macosforge.org> References: <20090820110641.48E9F240AD6A@beta.macosforge.org> Message-ID: <561655C6-62D8-4698-A710-129DB5155A9D@lavergne.gotdns.org> Doesn't the revision need to go higher, not lower? On Aug 20, 2009, at 7:06 AM, takanori at macports.org wrote: > Modified: trunk/dports/devel/autoconf/Portfile (55847 => 55848) > > --- trunk/dports/devel/autoconf/Portfile 2009-08-20 10:54:07 UTC > (rev 55847) > +++ trunk/dports/devel/autoconf/Portfile 2009-08-20 11:06:35 UTC > (rev 55848) > > @@ -4,7 +4,6 @@ > > > > name autoconf > version 2.64 > -revision 1 > categories devel > maintainers ram openmaintainer > platforms darwin > > @@ -23,8 +22,6 @@ > > master_sites gnu > use_bzip2 yes > -patchfiles patch-lib_autoconf_headers.m4.diff > - > checksums md5 ef400d672005e0be21e0d20648169074 \ > sha1 dfbcdbd7dd74a52130dda324e9d94ee0b8551466 \ > rmd160 cf498949b3cc0a6bc465a50114c98750871bcf49 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From ryandesign at macports.org Thu Aug 20 04:23:24 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 20 Aug 2009 06:23:24 -0500 Subject: [55848] trunk/dports/devel/autoconf In-Reply-To: <20090820110641.48E9F240AD6A@beta.macosforge.org> References: <20090820110641.48E9F240AD6A@beta.macosforge.org> Message-ID: <76025B32-C015-41B6-90A3-5B75E32010CF@macports.org> On Aug 20, 2009, at 06:06, takanori at macports.org wrote: > Revision: 55848 > http://trac.macports.org/changeset/55848 > Author: takanori at macports.org > Date: 2009-08-20 04:06:35 -0700 (Thu, 20 Aug 2009) > Log Message: > ----------- > autoconf: Revert to r54421. Seems that patch- > lib_autoconf_headers.m4.diff was not enough to build KDE 3.5.10.. ;-( [snip] > @@ -4,7 +4,6 @@ > > name autoconf > version 2.64 > -revision 1 > categories devel > maintainers ram openmaintainer > platforms darwin You can't decrease the revision unless you do so very soon after having increased it. Any backtracking of the revision (or version or epoch) would have to happen at the latest before the portindex is regenerated, which happens hourly. Since the port had been at revision 1 for 18 hours, I increased the revision to 2 in r55850. From ryandesign at macports.org Thu Aug 20 07:35:41 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 20 Aug 2009 09:35:41 -0500 Subject: [55865] trunk/dports/kde In-Reply-To: <20090820134155.420F1240BD1B@beta.macosforge.org> References: <20090820134155.420F1240BD1B@beta.macosforge.org> Message-ID: On Aug 20, 2009, at 08:41, takanori at macports.org wrote: > Revision: 55865 > http://trac.macports.org/changeset/55865 > Author: takanori at macports.org > Date: 2009-08-20 06:41:53 -0700 (Thu, 20 Aug 2009) > Log Message: > ----------- > KDE3: Force use of autoconf 2.63 instead of 2.64. (#20513) Thanks! I was dreading going through all the kde3 ports and you've saved me the trouble. :) But it would have been better if you had not also made lots of other unrelated changes in the same commit. In addition to the described switch to autoconf 2.63, you changed categories, distfile tags, and foreach variables, and removed overriding of the destroot and build phases. While these are good changes to make, each of them should be made in a separate commit, with a commit message that says what was done. If you must combine changes into a single commit, at least describe everything that's changed in the commit message; the message for r55865 gives no indication that these other changes took place. From jeremyhu at macports.org Thu Aug 20 13:55:51 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Thu, 20 Aug 2009 13:55:51 -0700 Subject: [55703] trunk/dports/x11/xorg-libXcomposite/Portfile In-Reply-To: <20090817113151.42297239AEFF@beta.macosforge.org> References: <20090817113151.42297239AEFF@beta.macosforge.org> Message-ID: <4643E234-2343-4FA8-ADB0-56557E02F93C@macports.org> I reverted this commit. What issue were you trying to fix with this commit? The protos were explicitly placed as lib dependencies in order to eliminate the need to put these protos as build dependencies in 30% of the tree. Further, xextproto is already pulled in by libXext. Additionally, XExtProto is 7.1.0, not 7.0.5 (and was at the time of your commit). On Aug 17, 2009, at 04:31, nox at macports.org wrote: > Revision: 55703 > http://trac.macports.org/changeset/55703 > Author: nox at macports.org > Date: 2009-08-17 04:31:47 -0700 (Mon, 17 Aug 2009) > Log Message: > ----------- > xorg-libXcomposite: > * Add xorg-xextproto as a build dependency: > Package 'FixesProto' requires 'xextproto >= 7.0.99.1' but > version of XExtProto is 7.0.5 > * Move xorg-compositeproto to build dependencies. > > Modified Paths: > -------------- > trunk/dports/x11/xorg-libXcomposite/Portfile > > Modified: trunk/dports/x11/xorg-libXcomposite/Portfile > =================================================================== > --- trunk/dports/x11/xorg-libXcomposite/Portfile 2009-08-17 09:54:13 > UTC (rev 55702) > +++ trunk/dports/x11/xorg-libXcomposite/Portfile 2009-08-17 11:31:47 > UTC (rev 55703) > @@ -21,11 +21,12 @@ > use_bzip2 yes > use_parallel_build yes > > -depends_build port:pkgconfig > +depends_build port:pkgconfig \ > + port:xorg-xextproto \ > + port:xorg-compositeproto > > depends_lib port:xorg-libXfixes \ > - port:xorg-libXext \ > - port:xorg-compositeproto > + port:xorg-libXext > > livecheck.check regex > livecheck.url [lindex ${master_sites} 0]?C=M&O=D > _______________________________________________ > macports-changes mailing list > macports-changes at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes From ryandesign at macports.org Thu Aug 20 15:18:25 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 20 Aug 2009 17:18:25 -0500 Subject: Variant name darwin_9-1 is not valid References: <20090820194519.A388B6EC9BA0@mail-out3.apple.com> Message-ID: Begin forwarded message: > From: noreply at macports.org > Date: August 20, 2009 14:45:19 CDT > To: ryandesign at macports.org, > Subject: [55880] akonadi Lint Report > > Change: http://trac.macports.org/changeset/55880 > Portfile: akonadi > > Error: Variant name darwin_9-1 is not valid; use [A-Za-z0-9_]+ only akonadi uses the kde4 portgroup. The kde4 portgroup defines a platform darwin 9 variant. So does akonadi. They do not play well with one another. Apparently one of them turns into the invalidly-named darwin_9-1. Do we think this is a base bug / missing feature? From jmr at macports.org Thu Aug 20 23:40:01 2009 From: jmr at macports.org (Joshua Root) Date: Fri, 21 Aug 2009 16:40:01 +1000 Subject: Variant name darwin_9-1 is not valid In-Reply-To: References: <20090820194519.A388B6EC9BA0@mail-out3.apple.com> Message-ID: <4A8E4141.3010301@macports.org> On 2009-8-21 08:18, Ryan Schmidt wrote: > Begin forwarded message: > >> From: noreply at macports.org >> Date: August 20, 2009 14:45:19 CDT >> To: ryandesign at macports.org, >> Subject: [55880] akonadi Lint Report >> >> Change: http://trac.macports.org/changeset/55880 >> Portfile: akonadi >> >> Error: Variant name darwin_9-1 is not valid; use [A-Za-z0-9_]+ only > > akonadi uses the kde4 portgroup. > The kde4 portgroup defines a platform darwin 9 variant. > So does akonadi. > They do not play well with one another. > Apparently one of them turns into the invalidly-named darwin_9-1. > Do we think this is a base bug / missing feature? Already fixed in 1.8. Should probably just use variant_isset in the portgroup for the time being. - Josh From raimue at macports.org Fri Aug 21 05:42:04 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 21 Aug 2009 14:42:04 +0200 Subject: [55848] trunk/dports/devel/autoconf In-Reply-To: <561655C6-62D8-4698-A710-129DB5155A9D@lavergne.gotdns.org> References: <20090820110641.48E9F240AD6A@beta.macosforge.org> <561655C6-62D8-4698-A710-129DB5155A9D@lavergne.gotdns.org> Message-ID: <4A8E961C.6030806@macports.org> On 2009-08-20 13:11 , Jeremy Lavergne wrote: > Doesn't the revision need to go higher, not lower? Revision got to 1 from 0 at adding the patch, now it is 2 after removing the patch, which is fine. This will cause unnecessary rebuilds for most people, but we do not have a better way to handle something like that. Rainer From ryandesign at macports.org Fri Aug 21 07:36:05 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 21 Aug 2009 09:36:05 -0500 Subject: Variant name darwin_9-1 is not valid In-Reply-To: <4A8E4141.3010301@macports.org> References: <20090820194519.A388B6EC9BA0@mail-out3.apple.com> <4A8E4141.3010301@macports.org> Message-ID: <85CE96A1-AC1D-4404-B16D-48848E8B4C83@macports.org> On Aug 21, 2009, at 01:40, Joshua Root wrote: > On 2009-8-21 08:18, Ryan Schmidt wrote: > >>> From: noreply at macports.org >>> Date: August 20, 2009 14:45:19 CDT >>> To: ryandesign at macports.org, >>> Subject: [55880] akonadi Lint Report >>> >>> Change: http://trac.macports.org/changeset/55880 >>> Portfile: akonadi >>> >>> Error: Variant name darwin_9-1 is not valid; use [A-Za-z0-9_]+ only >> >> akonadi uses the kde4 portgroup. >> The kde4 portgroup defines a platform darwin 9 variant. >> So does akonadi. >> They do not play well with one another. >> Apparently one of them turns into the invalidly-named darwin_9-1. >> Do we think this is a base bug / missing feature? > > Already fixed in 1.8. Should probably just use variant_isset in the > portgroup for the time being. > > > On Aug 21, 2009, at 01:48, jmr at macports.org wrote: > >> Revision: 55908 >> http://trac.macports.org/changeset/55908 >> Author: jmr at macports.org >> Date: 2009-08-20 23:47:57 -0700 (Thu, 20 Aug 2009) >> Log Message: >> ----------- >> kde4 portgroup: avoid declaring platform variants, which can't be >> multiply defined in MacPorts 1.7 Can they be multiply defined in 1.8? All that r52540 changed was that a duplicate platform variant will use an underscore to create a new variant name instead of a dash. So that removes the lint error I received, but would it actually make both platform darwin 9 variants in the same port function now? In 1.7.1 if I do "port info" for this port: PortSystem 1.0 name multiple version 1.0 platform darwin 8 { ui_msg "I am darwin 8" } platform darwin 8 { ui_msg "I am also darwin 8" } then I see: I am darwin 8 I am darwin 8 multiple @1.0 Variants: darwin_8, universal I never see "I am also darwin 8". And, really, I wouldn't expect that to work. If it still doesn't in trunk, then perhaps we just need to document the fact that portgroups may not define platform variants. Curiously, non-platform variants behave differently. I would have expected them to be the same but when I "port info +foo" this: PortSystem 1.0 name multiple version 1.0 variant foo { ui_msg "I am foo" } variant foo { ui_msg "I am also foo" } I get: I am also foo multiple @1.0 Variants: +foo, universal From jmr at macports.org Fri Aug 21 08:33:00 2009 From: jmr at macports.org (Joshua Root) Date: Sat, 22 Aug 2009 01:33:00 +1000 Subject: Variant name darwin_9-1 is not valid In-Reply-To: <85CE96A1-AC1D-4404-B16D-48848E8B4C83@macports.org> References: <20090820194519.A388B6EC9BA0@mail-out3.apple.com> <4A8E4141.3010301@macports.org> <85CE96A1-AC1D-4404-B16D-48848E8B4C83@macports.org> Message-ID: <4A8EBE2C.1030506@macports.org> On 2009-8-22 00:36, Ryan Schmidt wrote: >> On Aug 21, 2009, at 01:48, jmr at macports.org wrote: >> >>> Revision: 55908 >>> http://trac.macports.org/changeset/55908 >>> Author: jmr at macports.org >>> Date: 2009-08-20 23:47:57 -0700 (Thu, 20 Aug 2009) >>> Log Message: >>> ----------- >>> kde4 portgroup: avoid declaring platform variants, which can't be >>> multiply defined in MacPorts 1.7 > > Can they be multiply defined in 1.8? All that r52540 changed was that a > duplicate platform variant will use an underscore to create a new > variant name instead of a dash. True. Fixed now. > Curiously, non-platform variants behave differently. I would have > expected them to be the same Multiple definitions can only work for platform variants because they set themselves. You really shouldn't be defining any variants more than once. - Josh From blair at orcaware.com Fri Aug 21 08:57:05 2009 From: blair at orcaware.com (Blair Zajac) Date: Fri, 21 Aug 2009 08:57:05 -0700 Subject: Remove +with_default_names and use a specific path for unprefixed binaries Message-ID: <9AB7817D-EAD1-41DC-94B9-9550690A8AE5@orcaware.com> This ticket was opened https://trac.macports.org/ticket/20748 Does building a port modify PATH so it would ignore the gnubin directory? I'm happy with the current setup, don't mind tweaking the occasional Portfile which I do, so don't really want to move them into a new directory. Regards, Blair From raimue at macports.org Fri Aug 21 09:36:54 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 21 Aug 2009 18:36:54 +0200 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: <9AB7817D-EAD1-41DC-94B9-9550690A8AE5@orcaware.com> References: <9AB7817D-EAD1-41DC-94B9-9550690A8AE5@orcaware.com> Message-ID: <4A8ECD26.9070409@macports.org> On 2009-08-21 17:57 , Blair Zajac wrote: > This ticket was opened > > https://trac.macports.org/ticket/20748 > > Does building a port modify PATH so it would ignore the gnubin > directory? Yes. The environment variable PATH is by default set to ${prefix}/bin:${prefix}/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11/bin during the configure and build phases. > I'm happy with the current setup, don't mind tweaking the occasional > Portfile which I do, so don't really want to move them into a new > directory. You would only have to add ${prefix}/gnubin at the front of your PATH to use the GNU versions. Rainer From ryandesign at macports.org Fri Aug 21 10:13:48 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 21 Aug 2009 12:13:48 -0500 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: <4A8ECD26.9070409@macports.org> References: <9AB7817D-EAD1-41DC-94B9-9550690A8AE5@orcaware.com> <4A8ECD26.9070409@macports.org> Message-ID: <6974624E-6DAD-4D69-9AB3-DC627F905EA7@macports.org> On Aug 21, 2009, at 11:36, Rainer M?ller wrote: > On 2009-08-21 17:57 , Blair Zajac wrote: > >> This ticket was opened >> >> https://trac.macports.org/ticket/20748 >> >> Does building a port modify PATH so it would ignore the gnubin >> directory? > > Yes. The environment variable PATH is by default set to > ${prefix}/bin:${prefix}/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11/ > bin > during the configure and build phases. It can be changed by editing the binpath variable in macports.conf if you know what you're doing. >> I'm happy with the current setup, don't mind tweaking the occasional >> Portfile which I do, so don't really want to move them into a new >> directory. > > You would only have to add ${prefix}/gnubin at the front of your > PATH to > use the GNU versions. ${prefix}/gnubin would be an mtree violation, which we try to avoid, but ${prefix}/libexec/${name} could be reasonable, and has precedent. From ryandesign at macports.org Fri Aug 21 10:22:34 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 21 Aug 2009 12:22:34 -0500 Subject: [55929] trunk/dports/kde/kdepim4/Portfile In-Reply-To: <20090821152118.A2A0C2435354@beta.macosforge.org> References: <20090821152118.A2A0C2435354@beta.macosforge.org> Message-ID: <5502E86B-2E6E-40E6-B3DF-5DE508845F5E@macports.org> On Aug 21, 2009, at 10:21, snc at macports.org wrote: > Revision: 55929 > http://trac.macports.org/changeset/55929 > Author: snc at macports.org > Date: 2009-08-21 08:21:18 -0700 (Fri, 21 Aug 2009) > Log Message: > ----------- > take ownership with jeremy_laine Was the update to 4.3.0 intentional? If so you should note it in the commit message and in #20737. > Modified: trunk/dports/kde/kdepim4/Portfile > =================================================================== > --- trunk/dports/kde/kdepim4/Portfile 2009-08-21 15:20:46 UTC (rev > 55928) > +++ trunk/dports/kde/kdepim4/Portfile 2009-08-21 15:21:18 UTC (rev > 55929) > @@ -4,10 +4,9 @@ > PortGroup kde4 1.0 > > name kdepim4 > -version 4.2.4 > -revision 1 > +version 4.3.0 > categories kde kde4 > -maintainers nomaintainer > +maintainers snc m4x.org:jeremy_laine > description KDE4 groupware suite > long_description KDE4 groupware suite including a Mail client, \ > addressbook, organizer and groupware integration. > @@ -16,13 +15,12 @@ > master_sites kde:stable/${version}/src/ > use_bzip2 yes > distname kdepim-${version} > -checksums md5 e3b14bea173511628767475f0dbfb6ac > +checksums md5 ddc887f19ef9cd454f4f3226c955aaaf > > -#patchfiles patch-kleopatra-CMakeLists.diff \ > -patchfiles patch-kresources-CMakeLists.diff > patch.dir ${workpath}/${distname} > > depends_lib-append port:kdebase4-runtime \ > + port:kdelibs4-experimental \ > port:kdepimlibs4 port:glib2 \ > port:qca port:gnokii From jeremy at lavergne.gotdns.org Fri Aug 21 10:56:09 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 21 Aug 2009 13:56:09 -0400 Subject: [55929] trunk/dports/kde/kdepim4/Portfile In-Reply-To: <5502E86B-2E6E-40E6-B3DF-5DE508845F5E@macports.org> References: <20090821152118.A2A0C2435354@beta.macosforge.org> <5502E86B-2E6E-40E6-B3DF-5DE508845F5E@macports.org> Message-ID: Was in a rush to check in all the ownership changes that I missed I hadn't submitted the patch yet. Sent in a fix for the log. On Aug 21, 2009, at 1:22 PM, Ryan Schmidt wrote: > On Aug 21, 2009, at 10:21, snc at macports.org wrote: >> Revision: 55929 >> http://trac.macports.org/changeset/55929 >> Author: snc at macports.org >> Date: 2009-08-21 08:21:18 -0700 (Fri, 21 Aug 2009) >> Log Message: >> ----------- >> take ownership with jeremy_laine > > Was the update to 4.3.0 intentional? If so you should note it in the > commit message and in #20737. > > >> Modified: trunk/dports/kde/kdepim4/Portfile >> ... >> name kdepim4 >> -version 4.2.4 >> -revision 1 >> +version 4.3.0 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From raimue at macports.org Fri Aug 21 11:08:22 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 21 Aug 2009 20:08:22 +0200 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: <6974624E-6DAD-4D69-9AB3-DC627F905EA7@macports.org> References: <9AB7817D-EAD1-41DC-94B9-9550690A8AE5@orcaware.com> <4A8ECD26.9070409@macports.org> <6974624E-6DAD-4D69-9AB3-DC627F905EA7@macports.org> Message-ID: <4A8EE296.5050702@macports.org> On 2009-08-21 19:13 , Ryan Schmidt wrote: > On Aug 21, 2009, at 11:36, Rainer M?ller wrote: >> You would only have to add ${prefix}/gnubin at the front of your >> PATH to >> use the GNU versions. > > ${prefix}/gnubin would be an mtree violation, which we try to avoid, > but ${prefix}/libexec/${name} could be reasonable, and has precedent. I agree that we should avoid mtree violations. Actually the libexec path is meant for binaries to be run from other binaries but not by the user. These GNU tools are meant to be run by the user, so they do not really fit into libexec in my opinion. Rainer From jmr at macports.org Fri Aug 21 11:10:36 2009 From: jmr at macports.org (Joshua Root) Date: Sat, 22 Aug 2009 04:10:36 +1000 Subject: MacPorts 1.8.0 release candidate 1 available for testing Message-ID: <4A8EE31C.2090902@macports.org> See the announcement on -users: - Josh From kthenriksson at gmail.com Fri Aug 21 15:51:12 2009 From: kthenriksson at gmail.com (Kristofer Henriksson) Date: Fri, 21 Aug 2009 18:51:12 -0400 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: <4A8EE296.5050702@macports.org> References: <9AB7817D-EAD1-41DC-94B9-9550690A8AE5@orcaware.com> <4A8ECD26.9070409@macports.org> <6974624E-6DAD-4D69-9AB3-DC627F905EA7@macports.org> <4A8EE296.5050702@macports.org> Message-ID: <4809057c0908211551g3e0295a6r10c53738d5df4d9f@mail.gmail.com> I currently use the +with_default_names variant, and I do not think removing it will be a good idea. It sounds like from those bugs above, the main problem is just that those names cause issues with installing new ports that expect the names to be the built-in commands. Is there any way that those names could be ignored just for Macports builds? Since the issues only come up with people who actually use the variant, alternatively you could just put up a big warning saying that there could be problems when people install it. I really like having the +with_default_names variant and would rather not have to make extra changes to my path to accomodate certain particular ports. Thanks, Kris On Fri, Aug 21, 2009 at 2:08 PM, Rainer M?ller wrote: > On 2009-08-21 19:13 , Ryan Schmidt wrote: >> On Aug 21, 2009, at 11:36, Rainer M?ller wrote: >>> You would only have to add ${prefix}/gnubin at the front of your >>> PATH to >>> use the GNU versions. >> >> ${prefix}/gnubin would be an mtree violation, which we try to avoid, >> but ${prefix}/libexec/${name} could be reasonable, and has precedent. > > I agree that we should avoid mtree violations. Actually the libexec path > is meant for binaries to be run from other binaries but not by the user. > These GNU tools are meant to be run by the user, so they do not really > fit into libexec in my opinion. > > Rainer > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From ryandesign at macports.org Sat Aug 22 08:57:15 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 22 Aug 2009 10:57:15 -0500 Subject: [55961] trunk/dports/python In-Reply-To: <20090822114342.4F029244C01C@beta.macosforge.org> References: <20090822114342.4F029244C01C@beta.macosforge.org> Message-ID: On Aug 22, 2009, at 06:43, jonas at macports.org wrote: > > +maintainers fs.ei.tum.de:jonas openmaintainer You probably should use your MacPorts handle here. maintainers jonas openmaintainer > +depends_lib port:R > + > +variant custom_r description {Use a custom R installation instead > depending on macports' R} { > + depends_lib-delete port:R > +} Why this? Is there a good reason why someone could not use the MacPorts R and would need to install their own? MacPorts policy is generally to use MacPorts versions of things only. From raimue at macports.org Sat Aug 22 09:03:44 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 22 Aug 2009 18:03:44 +0200 Subject: [55961] trunk/dports/python In-Reply-To: References: <20090822114342.4F029244C01C@beta.macosforge.org> Message-ID: <4A9016E0.80007@macports.org> On 2009-08-22 17:57 , Ryan Schmidt wrote: > On Aug 22, 2009, at 06:43, jonas at macports.org wrote: >> +depends_lib port:R >> + >> +variant custom_r description {Use a custom R installation instead >> depending on macports' R} { >> + depends_lib-delete port:R >> +} > > Why this? Is there a good reason why someone could not use the > MacPorts R and would need to install their own? MacPorts policy is > generally to use MacPorts versions of things only. Especially if nothing else is changed, this would not find another installation of R as MacPorts does not search outside of the prefix. But if R is not even required for building, this should be depends_run instead. Rainer From ryandesign at macports.org Sat Aug 22 09:17:02 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 22 Aug 2009 11:17:02 -0500 Subject: [55964] trunk/dports/devel In-Reply-To: <20090822140341.9E995244C8E3@beta.macosforge.org> References: <20090822140341.9E995244C8E3@beta.macosforge.org> Message-ID: On Aug 22, 2009, at 09:03, snc at macports.org wrote: > +default_variants test If you want to use a default variant, it must be written default_variants +test (needs a "+" before the variant name) But, since default variants are difficult for the user to turn off, I suggest you either do not make this the default, or you remove the variant and enable its functionality in the main body of the portfile. In this case, is there any reason not to enable this functionality always? > +variant test description { Build Unit Tests } { > + configure.args-append -DENABLE_TESTS=ON > + test { > + system "cd ${worksrcpath} && ./util/run_tests.sh" > + } > +} From ryandesign at macports.org Sat Aug 22 09:25:29 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 22 Aug 2009 11:25:29 -0500 Subject: [55956] trunk/dports/security In-Reply-To: <20090821195652.A4EDE243DFDA@beta.macosforge.org> References: <20090821195652.A4EDE243DFDA@beta.macosforge.org> Message-ID: <3ACDBB34-8E7E-4945-81A5-86494CE315BF@macports.org> On Aug 21, 2009, at 14:56, snc at macports.org wrote: > Revision: 55956 > http://trac.macports.org/changeset/55956 > Author: snc at macports.org > Date: 2009-08-21 12:56:52 -0700 (Fri, 21 Aug 2009) > Log Message: > ----------- > moved from python/py25-denyhosts > > Modified Paths: > -------------- > trunk/dports/security/denyhosts/Portfile > > Added Paths: > ----------- > trunk/dports/security/denyhosts/ > > Modified: trunk/dports/security/denyhosts/Portfile > =================================================================== > --- trunk/dports/python/py25-denyhosts/Portfile 2009-08-11 01:53:38 > UTC (rev 55454) > +++ trunk/dports/security/denyhosts/Portfile 2009-08-21 19:56:52 > UTC (rev 55956) > @@ -4,9 +4,9 @@ > PortSystem 1.0 > PortGroup python25 1.0 > > -name py25-denyhosts > +name denyhosts But nobody who had py25-denyhosts installed will be informed that the port's name has changed. Can you leave a stub port called denyhosts with a higher version / revision than it had before that advises users of the port's new name? From jeremy at lavergne.gotdns.org Sat Aug 22 09:29:31 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 22 Aug 2009 12:29:31 -0400 Subject: [55956] trunk/dports/security In-Reply-To: <3ACDBB34-8E7E-4945-81A5-86494CE315BF@macports.org> References: <20090821195652.A4EDE243DFDA@beta.macosforge.org> <3ACDBB34-8E7E-4945-81A5-86494CE315BF@macports.org> Message-ID: I don't believe it's being used by more than one person; the startupitem failed to function and he was the only one to voice his concern. On Aug 22, 2009, at 12:25 PM, Ryan Schmidt wrote: > But nobody who had py25-denyhosts installed will be informed that > the port's name has changed. Can you leave a stub port called > denyhosts with a higher version / revision than it had before that > advises users of the port's new name? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From ryandesign at macports.org Sat Aug 22 10:37:14 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 22 Aug 2009 12:37:14 -0500 Subject: Automatic homepage for sourceforge, googlecode, etc. Message-ID: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> For projects hosted on SourceForge or Google Code or other common sites we have simple ways of expressing the master_sites: master_sites sourceforge master_sites googlecode This also automatically sets the livecheck. Wouldn't it be useful to be able to do that for the homepage as well? Currently ports have to manually specify homepage http://${name}.sourceforge.net/ homepage http://code.google.com/p/${name}/ Could we simplify it like this? homepage sourceforge homepage googlecode Or maybe the homepage would also automatically be set if master_sites uses one of those shortcuts? Now that I think about it, the way these shortcuts are working now is a little like portgroups. In fact all of it probably could be implemented as a portgroup. PortGroup sourceforge 1.0 PortGroup googlecode 1.0 Might that simplify base code a bit? From jeremy at lavergne.gotdns.org Sat Aug 22 11:15:45 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 22 Aug 2009 14:15:45 -0400 Subject: Automatic homepage for sourceforge, googlecode, etc. In-Reply-To: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> Message-ID: <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> On Aug 22, 2009, at 1:37 PM, Ryan Schmidt wrote: > Now that I think about it, the way these shortcuts are working now > is a little like portgroups. In fact all of it probably could be > implemented as a portgroup. > > PortGroup sourceforge 1.0 > > PortGroup googlecode 1.0 > > Might that simplify base code a bit? I'd suggest we do something akin to the extract options: use_sourceforge or use_googlecode. Are we able to use more than one PortGroup at a time (googlecode + cmake)? More importantly, I don't think we need the "versions" that PortGroup brings with it. We can achieve this same functionality without resorting to a PortGroup via use_sourceforge. Additionally, I find the use_googlecode option more readable. :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From talklists at newgeo.com Sat Aug 22 12:29:48 2009 From: talklists at newgeo.com (Scott Haneda) Date: Sat, 22 Aug 2009 12:29:48 -0700 Subject: Automatic homepage for sourceforge, googlecode, etc. In-Reply-To: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> Message-ID: Simplify the base code, or simplify the port files? The port files list a url, which I find highly readable, and also nice, because I can easily know what that url is, and ping, curl, or http request it. It seems to me the base MacPors code would only become more complex (trivially), as now you have to maintain a mapping of master_sites to names/url's. Yes, it is a trivial mapping. I would think it could not hurt, and may be useful to some, and there is always the option of simply hard coding the url in if you are so inclined. However, from a port maker perspective, I am somewhat partial to using real url's, as they are easier for me to debug and know at a glance, what is going on. My .02 On Aug 22, 2009, at 10:37 AM, Ryan Schmidt wrote: > For projects hosted on SourceForge or Google Code or other common > sites we have simple ways of expressing the master_sites: > > master_sites sourceforge > > master_sites googlecode > > > This also automatically sets the livecheck. > > > Wouldn't it be useful to be able to do that for the homepage as > well? Currently ports have to manually specify > > homepage http://${name}.sourceforge.net/ > > homepage http://code.google.com/p/${name}/ > > > Could we simplify it like this? > > homepage sourceforge > > homepage googlecode > > > Or maybe the homepage would also automatically be set if > master_sites uses one of those shortcuts? > > > > Now that I think about it, the way these shortcuts are working now > is a little like portgroups. In fact all of it probably could be > implemented as a portgroup. > > PortGroup sourceforge 1.0 > > PortGroup googlecode 1.0 > > Might that simplify base code a bit? -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Sat Aug 22 13:03:50 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 22 Aug 2009 15:03:50 -0500 Subject: Automatic homepage for sourceforge, googlecode, etc. In-Reply-To: <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> Message-ID: <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> On Aug 22, 2009, at 13:15, Jeremy Lavergne wrote: > On Aug 22, 2009, at 1:37 PM, Ryan Schmidt wrote: > >> Now that I think about it, the way these shortcuts are working now >> is a little like portgroups. In fact all of it probably could be >> implemented as a portgroup. >> >> PortGroup sourceforge 1.0 >> >> PortGroup googlecode 1.0 >> >> Might that simplify base code a bit? > > I'd suggest we do something akin to the extract options: > use_sourceforge or use_googlecode. That would be another option.... But perhaps another motivation to move the logic out of MacPorts base and into portgroups would be that it can be updated without requiring a new release of MacPorts base. > Are we able to use more than one PortGroup at a time (googlecode + > cmake)? Yes. The "PortGroup" command is really just an "include" command. You can include as many portgroups as you want/need. > More importantly, I don't think we need the "versions" that > PortGroup brings with it. To my knowledge the version feature that portgroup and portsystem have have never actually been used. Everything we have seems to be "1.0". But just be cause we don't happen to need that part of the portgroup infrastructure isn't an argument not to use it for this. > We can achieve this same functionality without resorting to a > PortGroup via use_sourceforge. > > Additionally, I find the use_googlecode option more readable. :-) I don't necessarily disagree with you on that point... From ryandesign at macports.org Sat Aug 22 13:09:44 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 22 Aug 2009 15:09:44 -0500 Subject: Automatic homepage for sourceforge, googlecode, etc. In-Reply-To: References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> Message-ID: <0DB56FFA-B64B-4CF1-B898-0699884734B7@macports.org> On Aug 22, 2009, at 14:29, Scott Haneda wrote: > Simplify the base code, or simplify the port files? Both. > The port files list a url, which I find highly readable, and also > nice, because I can easily know what that url is, and ping, curl, > or http request it. Portfiles already do not list a download URL or a livecheck URL when they use a master_sites group like sourceforge and googlecode. And it would be silly for every portfile to have to list the URL to a SourceForge or Google Code page because they all have the same format. If SourceForge or Google Code were to ever change that format, we would have to update tons of portfiles, instead of update only a single reference in MacPorts base, as it is currently. > It seems to me the base MacPors code would only become more complex > (trivially), as now you have to maintain a mapping of master_sites > to names/url's. Yes, it is a trivial mapping. The mapping already exists in MacPorts base. The "master_sites googlecode" and "master_sites sourceforge" examples I showed in my previous mails are valid portfile syntax. They are documented in the guide [1]. What is not yet valid syntax is "homepage googlecode" or "homepage sourceforge". My proposition was to extend the mapping feature to the homepage variable, and after writing that up, it occurred to me that it might be better to move the mapping out of MacPorts base and into portgroups, thus simplifying MacPorts base. [1] http://guide.macports.org/#reference.phases.fetch > I would think it could not hurt, and may be useful to some, and > there is always the option of simply hard coding the url in if you > are so inclined. However, from a port maker perspective, I am > somewhat partial to using real url's, as they are easier for me to > debug and know at a glance, what is going on. From raimue at macports.org Sat Aug 22 13:15:20 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 22 Aug 2009 22:15:20 +0200 Subject: Automatic homepage for sourceforge, googlecode, etc. In-Reply-To: References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> Message-ID: <4A9051D8.3090900@macports.org> On 2009-08-22 21:29 , Scott Haneda wrote: > Simplify the base code, or simplify the port files? The port files > list a url, which I find highly readable, and also nice, because I can > easily know what that url is, and ping, curl, or http request it. You would still be able to read the URL in 'port info' or use 'port gohome' and don't worry about the URL at all. > It seems to me the base MacPors code would only become more complex > (trivially), as now you have to maintain a mapping of master_sites to > names/url's. Yes, it is a trivial mapping. We already maintain such lists for fetch, so I don't think it would become any more complex. Rainer From raimue at macports.org Sat Aug 22 13:25:09 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 22 Aug 2009 22:25:09 +0200 Subject: Automatic homepage for sourceforge, googlecode, etc. In-Reply-To: <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> Message-ID: <4A905425.6040009@macports.org> On 2009-08-22 22:03 , Ryan Schmidt wrote: > On Aug 22, 2009, at 13:15, Jeremy Lavergne wrote: >> I'd suggest we do something akin to the extract options: >> use_sourceforge or use_googlecode. > > That would be another option.... But perhaps another motivation to > move the logic out of MacPorts base and into portgroups would be that > it can be updated without requiring a new release of MacPorts base. The use_* approach is possible, but actually I never liked that to be a yes/no decision. I would rather like to see a "use_site sourceforge" or "use_hosting sourceforge". I am aware that it is currently different for fetch, just making up my mind :-) >> Are we able to use more than one PortGroup at a time (googlecode + >> cmake)? > > Yes. The "PortGroup" command is really just an "include" command. You > can include as many portgroups as you want/need. The problem with PortGroups are that they are usually included at the top, even before the name of the port is set. That means that you cannot set homepage/master_sites/etc. at the time of inclusion and thus need another command in the Portfile. Rainer From ryandesign at macports.org Sat Aug 22 13:25:59 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 22 Aug 2009 15:25:59 -0500 Subject: [55961] trunk/dports/python In-Reply-To: <08168B8D-2A29-45EE-B453-91A69E5D351F@web.de> References: <20090822114342.4F029244C01C@beta.macosforge.org> <4A9016E0.80007@macports.org> <08168B8D-2A29-45EE-B453-91A69E5D351F@web.de> Message-ID: <65A7C6EE-0A6D-4CDF-9CB9-F0411D1BE943@macports.org> On Aug 22, 2009, at 14:13, Jonas B?hr wrote: > Am 22.08.2009 um 18:03 schrieb Rainer M?ller: > >> On 2009-08-22 17:57 , Ryan Schmidt wrote: >>> On Aug 22, 2009, at 06:43, jonas at macports.org wrote: >>>> +depends_lib port:R >>>> + >>>> +variant custom_r description {Use a custom R installation instead >>>> depending on macports' R} { >>>> + depends_lib-delete port:R >>>> +} >>> >>> Why this? Is there a good reason why someone could not use the >>> MacPorts R and would need to install their own? MacPorts policy is >>> generally to use MacPorts versions of things only. >> >> Especially if nothing else is changed, this would not find another >> installation of R as MacPorts does not search outside of the >> prefix. But >> if R is not even required for building, this should be depends_run >> instead. > > R is needed to build and run. The install script looks for "R" in > PATH, that's all. > > The rational behind the custom R is to lighten the dependencies for > the user. The R-Project provides very good customizable installer/ > binaries for Mac OS X. MacPorts's R port however can't be > customized at all and pulls in a complete gcc plus xorg. In my eyes > it's much more convenient for a user who already uses R to continue > to use his installation and install rpy2 within 5 minutes instead > of spending 6 hours compiling xorg, gcc, and an other bunch of > dependencies for nothing. If the user's R comes in PATH before > macports R, it won't be used anyway. MacPorts does not use your $PATH at build time. It uses the value of binpath in macports.conf. So for this to work a user would at least have to add the location of their binary installation of R to the binpath, and maybe also to their runtime PATH. The R port presumably requires a gcc port because it cannot be built with the gcc Apple provides. There are many many ports in MacPorts for software that needs xorg. They will all cause various xorg ports to be installed. That is not a reason not to use them. It is not the MacPorts way to use a user's software that was not installed with MacPorts. MacPorts is a package management system. It is supposed to manage your packages. But it cannot do that if you allow ports to use software that is outside of MacPorts. It would be best to remove the custom_r variant and make the port always use the MacPorts R port. If the R port does not provide all the options a user of R would expect, please file tickets requesting the R port be enhanced in whatever ways necessary. From jeremy at lavergne.gotdns.org Sat Aug 22 13:26:29 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 22 Aug 2009 16:26:29 -0400 Subject: Automatic homepage for sourceforge, googlecode, etc. In-Reply-To: <4A905425.6040009@macports.org> References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> <4A905425.6040009@macports.org> Message-ID: On Aug 22, 2009, at 4:25 PM, Rainer M?ller wrote: >>> I'd suggest we do something akin to the extract options: >>> use_sourceforge or use_googlecode. >> >> That would be another option.... But perhaps another motivation to >> move the logic out of MacPorts base and into portgroups would be that >> it can be updated without requiring a new release of MacPorts base. > > The use_* approach is possible, but actually I never liked that to > be a > yes/no decision. I would rather like to see a "use_site sourceforge" > or > "use_hosting sourceforge". > > I am aware that it is currently different for fetch, just making up my > mind :-) Huh, hadn't thought of using use_* that way; not a bad idea. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From ryandesign at macports.org Sat Aug 22 13:32:00 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 22 Aug 2009 15:32:00 -0500 Subject: Automatic homepage for sourceforge, googlecode, etc. In-Reply-To: <4A905425.6040009@macports.org> References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> <4A905425.6040009@macports.org> Message-ID: <2C821955-9ACA-4B29-982F-6590FBF1627A@macports.org> On Aug 22, 2009, at 15:25, Rainer M?ller wrote: > The use_* approach is possible, but actually I never liked that to > be a > yes/no decision. I would rather like to see a "use_site > sourceforge" or > "use_hosting sourceforge". That syntax looks nice. But all the existing use_ options are in MacPorts base code. Part of the motivation for my suggestion is to move this out of MacPorts base and into something inside the dports/ _resources directory, e.g. a portgroup. I wonder if maybe just renaming the "PortGroup" command would provide satisfaction. Instead of PortGroup sourceforge 1.0 it could be include sourceforge 1.0 or use sourceforge 1.0 > The problem with PortGroups are that they are usually included at the > top, even before the name of the port is set. That means that you > cannot > set homepage/master_sites/etc. at the time of inclusion and thus need > another command in the Portfile. Not so! We have a delayed expansion mechanism via the default / options infrastructure. e.g. default homepage {http://code.google.com/p/${name}/} The value will only be expanded at the time that the variable is read, not at the time when it is defined. ${name} might not be set at the point where the portgroup is included and when the default for homepage is set, but it will be by the time homepage gets used. It took me awhile to understand how this worked, but now that I do, it has been very helpful for the php5extension portgroup. From jkh at apple.com Sat Aug 22 13:35:25 2009 From: jkh at apple.com (Jordan K. Hubbard) Date: Sat, 22 Aug 2009 13:35:25 -0700 Subject: Time for a little Object-Oriented refactoring? [was Re: Automatic homepage for sourceforge, googlecode, etc.] In-Reply-To: <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> Message-ID: <3781B43B-2138-4904-A11F-55A00D91D81C@apple.com> I hate to get all OOPish on everyone here, but this seems like one of those problem spaces that would be well-served by something more closely approximating an class model with inheritance and mix-ins than the current matrix of options and control flags we have today. I'm also not suggesting that this should happen all at once, causing upheaval and discord in the project, but rather constitute more of a "recommended direction" for future knob setting mechanisms. To be more specific, rather than continue the proliferation of PortGroup foo and use_blah extensions, all of which basically cause "magic to happen" for the majority of Ports programmers rather than falling into some more coherent mental model for them, we could simply start fleshing out a class hierarchy for Ports and rolling the port- agnostic behavior into one or more classes, with a clearly defined mechanism for a Port to inherit from one or more classes or even other ports (that would certainly make the -devel ports a lot more concise). I can think of several ways in which this could work, and an equal number of ways that this could look, but before I start tossing out Tcl procedure names and hypothetical Portfiles, I thought I'd first ask whether or not anyone even likes the idea or merely thinks I'm trying to turn a mountain of Tcl code into C++ (ye gods, no!). Thoughts? - Jordan On Aug 22, 2009, at 1:03 PM, Ryan Schmidt wrote: > On Aug 22, 2009, at 13:15, Jeremy Lavergne wrote: > >> On Aug 22, 2009, at 1:37 PM, Ryan Schmidt wrote: >> >>> Now that I think about it, the way these shortcuts are working now >>> is a little like portgroups. In fact all of it probably could be >>> implemented as a portgroup. >>> >>> PortGroup sourceforge 1.0 >>> >>> PortGroup googlecode 1.0 >>> >>> Might that simplify base code a bit? >> >> I'd suggest we do something akin to the extract options: >> use_sourceforge or use_googlecode. > > That would be another option.... But perhaps another motivation to > move the logic out of MacPorts base and into portgroups would be > that it can be updated without requiring a new release of MacPorts > base. From jeremy at lavergne.gotdns.org Sat Aug 22 13:37:45 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 22 Aug 2009 16:37:45 -0400 Subject: Time for a little Object-Oriented refactoring? [was Re: Automatic homepage for sourceforge, googlecode, etc.] In-Reply-To: <3781B43B-2138-4904-A11F-55A00D91D81C@apple.com> References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> <3781B43B-2138-4904-A11F-55A00D91D81C@apple.com> Message-ID: <4331130D-8853-4195-8F40-1B482F98A649@lavergne.gotdns.org> Python before C++ On Aug 22, 2009, at 4:35 PM, Jordan K. Hubbard wrote: > I thought I'd first ask whether or not anyone even likes the idea or > merely thinks I'm trying to turn a mountain of Tcl code into C++ (ye > gods, no!). > > Thoughts? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jmr at macports.org Sat Aug 22 13:40:04 2009 From: jmr at macports.org (Joshua Root) Date: Sun, 23 Aug 2009 06:40:04 +1000 Subject: Automatic homepage for sourceforge, googlecode, etc. In-Reply-To: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> Message-ID: <4A9057A4.9030509@macports.org> On 2009-8-23 03:37, Ryan Schmidt wrote: > For projects hosted on SourceForge or Google Code or other common sites > we have simple ways of expressing the master_sites: > > master_sites sourceforge > > master_sites googlecode > Wouldn't it be useful to be able to do that for the homepage as well? > Could we simplify it like this? > > homepage sourceforge > > homepage googlecode Meh. Having a googlecode mirror group is already rather silly IMO given that it consists of exactly one URL. Getting a very slightly shorter portfile in exchange for requiring an extra step to find out the actual value of these fields seems like a poor tradeoff. - Josh From jmr at macports.org Sat Aug 22 13:46:50 2009 From: jmr at macports.org (Joshua Root) Date: Sun, 23 Aug 2009 06:46:50 +1000 Subject: Time for a little Object-Oriented refactoring? [was Re: Automatic homepage for sourceforge, googlecode, etc.] In-Reply-To: <3781B43B-2138-4904-A11F-55A00D91D81C@apple.com> References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> <3781B43B-2138-4904-A11F-55A00D91D81C@apple.com> Message-ID: <4A90593A.2020107@macports.org> On 2009-8-23 06:35, Jordan K. Hubbard wrote: > I hate to get all OOPish on everyone here, but this seems like one of > those problem spaces that would be well-served by something more closely > approximating an class model with inheritance and mix-ins than the > current matrix of options and control flags we have today. I'm also not > suggesting that this should happen all at once, causing upheaval and > discord in the project, but rather constitute more of a "recommended > direction" for future knob setting mechanisms. > > To be more specific, rather than continue the proliferation of PortGroup > foo and use_blah extensions, all of which basically cause "magic to > happen" for the majority of Ports programmers rather than falling into > some more coherent mental model for them, we could simply start fleshing > out a class hierarchy for Ports and rolling the port-agnostic behavior > into one or more classes, with a clearly defined mechanism for a Port to > inherit from one or more classes or even other ports (that would > certainly make the -devel ports a lot more concise). I can think of > several ways in which this could work, and an equal number of ways that > this could look, but before I start tossing out Tcl procedure names and > hypothetical Portfiles, I thought I'd first ask whether or not anyone > even likes the idea or merely thinks I'm trying to turn a mountain of > Tcl code into C++ (ye gods, no!). > > Thoughts? Sounds nice. Add it to the MacPorts 2.0 milestone! ;-) - Josh From jkh at apple.com Sat Aug 22 13:58:19 2009 From: jkh at apple.com (Jordan K. Hubbard) Date: Sat, 22 Aug 2009 13:58:19 -0700 Subject: Time for a little Object-Oriented refactoring? [was Re: Automatic homepage for sourceforge, googlecode, etc.] In-Reply-To: <4331130D-8853-4195-8F40-1B482F98A649@lavergne.gotdns.org> References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> <3781B43B-2138-4904-A11F-55A00D91D81C@apple.com> <4331130D-8853-4195-8F40-1B482F98A649@lavergne.gotdns.org> Message-ID: And [incr Tcl] before python. :) On Aug 22, 2009, at 1:37 PM, Jeremy Lavergne wrote: > Python before C++ > > On Aug 22, 2009, at 4:35 PM, Jordan K. Hubbard wrote: > >> I thought I'd first ask whether or not anyone even likes the idea >> or merely thinks I'm trying to turn a mountain of Tcl code into C++ >> (ye gods, no!). >> >> Thoughts? > From ryandesign at macports.org Sat Aug 22 14:00:00 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 22 Aug 2009 16:00:00 -0500 Subject: Automatic homepage for sourceforge, googlecode, etc. In-Reply-To: <4A9057A4.9030509@macports.org> References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <4A9057A4.9030509@macports.org> Message-ID: On Aug 22, 2009, at 15:40, Joshua Root wrote: > On 2009-8-23 03:37, Ryan Schmidt wrote: >> For projects hosted on SourceForge or Google Code or other common >> sites >> we have simple ways of expressing the master_sites: >> >> master_sites sourceforge >> >> master_sites googlecode > >> Wouldn't it be useful to be able to do that for the homepage as well? > >> Could we simplify it like this? >> >> homepage sourceforge >> >> homepage googlecode > > Meh. Having a googlecode mirror group is already rather silly IMO > given > that it consists of exactly one URL. > > Getting a very slightly shorter portfile in exchange for requiring an > extra step to find out the actual value of these fields seems like a > poor tradeoff. "master_sites googlecode" does not just cause master_sites to be set to the Google Code download URL for this project. It also causes the livecheck to be set. I'm wanting a way to have the homepage also set. Basically we are currently abusing "master_sites googlecode" as a way to say "This project is hosted by Google Code." Perhaps there is a better way to indicate that, for example using an include file like a portgroup, where it would be simpler for anyone to read the portgroup and see everything that happens, instead of having to figure out where all in MacPorts base and elsewhere decisions are made relating to this. For example, currently there is the mirror site definition in dports/_resources/port1.0/fetch/mirror_sites.tcl and stuff relating to the livecheck definition in base/src/port1.0/ portlivecheck.tcl and dports/_resources/port1.0/livecheck/ googlecode.tcl. From jkh at apple.com Sat Aug 22 14:02:00 2009 From: jkh at apple.com (Jordan K. Hubbard) Date: Sat, 22 Aug 2009 14:02:00 -0700 Subject: Time for a little Object-Oriented refactoring? [was Re: Automatic homepage for sourceforge, googlecode, etc.] In-Reply-To: <4A90593A.2020107@macports.org> References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> <3781B43B-2138-4904-A11F-55A00D91D81C@apple.com> <4A90593A.2020107@macports.org> Message-ID: <5DA125DC-656B-46E3-98AD-A1487F18FCBB@apple.com> Hmm. I'm not even seeing a future development page on the wiki... Am I just blind? - Jordan On Aug 22, 2009, at 1:46 PM, Joshua Root wrote: > Sounds nice. Add it to the MacPorts 2.0 milestone! ;-) From blair at orcaware.com Sat Aug 22 14:01:59 2009 From: blair at orcaware.com (Blair Zajac) Date: Sat, 22 Aug 2009 14:01:59 -0700 Subject: Time for a little Object-Oriented refactoring? [was Re: Automatic homepage for sourceforge, googlecode, etc.] In-Reply-To: References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> <3781B43B-2138-4904-A11F-55A00D91D81C@apple.com> <4331130D-8853-4195-8F40-1B482F98A649@lavergne.gotdns.org> Message-ID: If I had to guess there's more Python programmers than Tcl programmers so MacPorts could benefit from using a language that allow more developers to contribute. Using Tcl is a barrier that even I haven't taken on to see how to fix or improve things in MacPorts. Blair On Aug 22, 2009, at 1:58 PM, Jordan K. Hubbard wrote: > And [incr Tcl] before python. :) > > On Aug 22, 2009, at 1:37 PM, Jeremy Lavergne wrote: > >> Python before C++ >> >> On Aug 22, 2009, at 4:35 PM, Jordan K. Hubbard wrote: >> >>> I thought I'd first ask whether or not anyone even likes the idea >>> or merely thinks I'm trying to turn a mountain of Tcl code into C+ >>> + (ye gods, no!). >>> >>> Thoughts? From jmr at macports.org Sat Aug 22 14:11:05 2009 From: jmr at macports.org (Joshua Root) Date: Sun, 23 Aug 2009 07:11:05 +1000 Subject: Time for a little Object-Oriented refactoring? [was Re: Automatic homepage for sourceforge, googlecode, etc.] In-Reply-To: <5DA125DC-656B-46E3-98AD-A1487F18FCBB@apple.com> References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> <3781B43B-2138-4904-A11F-55A00D91D81C@apple.com> <4A90593A.2020107@macports.org> <5DA125DC-656B-46E3-98AD-A1487F18FCBB@apple.com> Message-ID: <4A905EE9.5030607@macports.org> There isn't actually a MacPorts 2.0 milestone, but if there was, it would be on the Trac Roadmap. - Josh On 2009-8-23 07:02, Jordan K. Hubbard wrote: > Hmm. I'm not even seeing a future development page on the wiki... Am I > just blind? > > - Jordan > > On Aug 22, 2009, at 1:46 PM, Joshua Root wrote: > >> Sounds nice. Add it to the MacPorts 2.0 milestone! ;-) From ryandesign at macports.org Sat Aug 22 14:12:52 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 22 Aug 2009 16:12:52 -0500 Subject: Time for a little Object-Oriented refactoring? [was Re: Automatic homepage for sourceforge, googlecode, etc.] In-Reply-To: References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> <3781B43B-2138-4904-A11F-55A00D91D81C@apple.com> <4331130D-8853-4195-8F40-1B482F98A649@lavergne.gotdns.org> Message-ID: On Aug 22, 2009, at 16:01, Blair Zajac wrote: > If I had to guess there's more Python programmers than Tcl > programmers so MacPorts could benefit from using a language that > allow more developers to contribute. Using Tcl is a barrier that > even I haven't taken on to see how to fix or improve things in > MacPorts. And there are also people who know existing MacPorts syntax well, and do not know Python. I understand Tcl was chosen for a reason, one of them being that it has a nice syntax that doesn't burden you with a lot of quoting and escaping when that isn't necessary in most cases. Having to write name = "foo"; instead of name foo may not look like a lot of extra characters but it would certainly add up. We have thousands of ports already. It's a little late to change the language now, I think. From jeremy at lavergne.gotdns.org Sat Aug 22 14:13:50 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 22 Aug 2009 17:13:50 -0400 Subject: Time for a little Object-Oriented refactoring? [was Re: Automatic homepage for sourceforge, googlecode, etc.] In-Reply-To: References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> <3781B43B-2138-4904-A11F-55A00D91D81C@apple.com> <4331130D-8853-4195-8F40-1B482F98A649@lavergne.gotdns.org> Message-ID: <6B552390-63A2-47E6-B9EE-F22603379C93@lavergne.gotdns.org> Such as bailing when you put a space after a \. On Aug 22, 2009, at 5:12 PM, Ryan Schmidt wrote: > one of them being that it has a nice syntax -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jeremy at lavergne.gotdns.org Sat Aug 22 14:15:17 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 22 Aug 2009 17:15:17 -0400 Subject: Time for a little Object-Oriented refactoring? [was Re: Automatic homepage for sourceforge, googlecode, etc.] In-Reply-To: References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> <3781B43B-2138-4904-A11F-55A00D91D81C@apple.com> <4331130D-8853-4195-8F40-1B482F98A649@lavergne.gotdns.org> Message-ID: Likely, a few sed scripts or a tcl script to rewrite the Portfiles could do it all for us. On Aug 22, 2009, at 5:12 PM, Ryan Schmidt wrote: > We have thousands of ports already. It's a little late to change the > language now, I think. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From ryandesign at macports.org Sat Aug 22 14:16:25 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 22 Aug 2009 16:16:25 -0500 Subject: Time for a little Object-Oriented refactoring? [was Re: Automatic homepage for sourceforge, googlecode, etc.] In-Reply-To: <6B552390-63A2-47E6-B9EE-F22603379C93@lavergne.gotdns.org> References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> <3781B43B-2138-4904-A11F-55A00D91D81C@apple.com> <4331130D-8853-4195-8F40-1B482F98A649@lavergne.gotdns.org> <6B552390-63A2-47E6-B9EE-F22603379C93@lavergne.gotdns.org> Message-ID: <2FA93CC2-6291-450A-8201-957952408776@macports.org> On Aug 22, 2009, at 16:13, Jeremy Lavergne wrote: > On Aug 22, 2009, at 5:12 PM, Ryan Schmidt wrote: > >> one of them being that it has a nice syntax > > Such as bailing when you put a space after a \. Well you can't claim for example that whitespace having significance in Python is an improvement.... From ryandesign at macports.org Sat Aug 22 14:18:13 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 22 Aug 2009 16:18:13 -0500 Subject: Time for a little Object-Oriented refactoring? [was Re: Automatic homepage for sourceforge, googlecode, etc.] In-Reply-To: References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> <3781B43B-2138-4904-A11F-55A00D91D81C@apple.com> <4331130D-8853-4195-8F40-1B482F98A649@lavergne.gotdns.org> Message-ID: <694B96B7-BC00-4D22-B545-BD77B3AB9B15@macports.org> On Aug 22, 2009, at 16:15, Jeremy Lavergne wrote: > On Aug 22, 2009, at 5:12 PM, Ryan Schmidt wrote: > >> We have thousands of ports already. It's a little late to change >> the language now, I think. > > Likely, a few sed scripts or a tcl script to rewrite the Portfiles > could do it all for us. Portfiles can, and many do, contain Tcl code -- program logic, procedures, etc. These would all have to be manually rewritten in whatever language we propose as a replacement. From jeremy at lavergne.gotdns.org Sat Aug 22 14:18:25 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 22 Aug 2009 17:18:25 -0400 Subject: Time for a little Object-Oriented refactoring? [was Re: Automatic homepage for sourceforge, googlecode, etc.] In-Reply-To: <2FA93CC2-6291-450A-8201-957952408776@macports.org> References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> <3781B43B-2138-4904-A11F-55A00D91D81C@apple.com> <4331130D-8853-4195-8F40-1B482F98A649@lavergne.gotdns.org> <6B552390-63A2-47E6-B9EE-F22603379C93@lavergne.gotdns.org> <2FA93CC2-6291-450A-8201-957952408776@macports.org> Message-ID: <12158D4D-227A-4936-AE49-2969325EE1F7@lavergne.gotdns.org> Other than it's used in a visible way, rather than hiding. :-) Also, it helps with readability! heh! On Aug 22, 2009, at 5:16 PM, Ryan Schmidt wrote: > Well you can't claim for example that whitespace having significance > in Python is an improvement.... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From blair at orcaware.com Sat Aug 22 14:19:27 2009 From: blair at orcaware.com (Blair Zajac) Date: Sat, 22 Aug 2009 14:19:27 -0700 Subject: Time for a little Object-Oriented refactoring? [was Re: Automatic homepage for sourceforge, googlecode, etc.] In-Reply-To: References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> <3781B43B-2138-4904-A11F-55A00D91D81C@apple.com> <4331130D-8853-4195-8F40-1B482F98A649@lavergne.gotdns.org> Message-ID: On Aug 22, 2009, at 2:12 PM, Ryan Schmidt wrote: > We have thousands of ports already. It's a little late to change the > language now, I think. Granted Tcl was probably the right choice at the time MacPorts was started, but it probably wouldn't be the right choice now. Also, there's a difference between rewriting all the Portfile's, which I'm not suggesting, and rewriting the MacPorts engine. One could write a parser for the simple Tcl used in Portfile's in Python. Blair From jmr at macports.org Sat Aug 22 14:20:17 2009 From: jmr at macports.org (Joshua Root) Date: Sun, 23 Aug 2009 07:20:17 +1000 Subject: Time for a little Object-Oriented refactoring? [was Re: Automatic homepage for sourceforge, googlecode, etc.] In-Reply-To: References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> <3781B43B-2138-4904-A11F-55A00D91D81C@apple.com> <4331130D-8853-4195-8F40-1B482F98A649@lavergne.gotdns.org> Message-ID: <4A906111.7090400@macports.org> Feel free to add more C to base! :-) Incorporating any other language is going to be at least somewhat tricky, since portfiles are effectively locked in to Tcl, and you thus need to use either Tcl or its C API (and in fact port currently just extends tclsh). And I really don't see anyone rewriting the lot in one go, so everything would have to peacefully coexist. - Josh On 2009-8-23 07:01, Blair Zajac wrote: > If I had to guess there's more Python programmers than Tcl programmers > so MacPorts could benefit from using a language that allow more > developers to contribute. Using Tcl is a barrier that even I haven't > taken on to see how to fix or improve things in MacPorts. > > Blair > > On Aug 22, 2009, at 1:58 PM, Jordan K. Hubbard wrote: > >> And [incr Tcl] before python. :) >> >> On Aug 22, 2009, at 1:37 PM, Jeremy Lavergne wrote: >> >>> Python before C++ >>> >>> On Aug 22, 2009, at 4:35 PM, Jordan K. Hubbard wrote: >>> >>>> I thought I'd first ask whether or not anyone even likes the idea or >>>> merely thinks I'm trying to turn a mountain of Tcl code into C++ (ye >>>> gods, no!). >>>> >>>> Thoughts? From jmr at macports.org Sat Aug 22 14:22:37 2009 From: jmr at macports.org (Joshua Root) Date: Sun, 23 Aug 2009 07:22:37 +1000 Subject: Time for a little Object-Oriented refactoring? [was Re: Automatic homepage for sourceforge, googlecode, etc.] In-Reply-To: References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> <3781B43B-2138-4904-A11F-55A00D91D81C@apple.com> <4331130D-8853-4195-8F40-1B482F98A649@lavergne.gotdns.org> Message-ID: <4A90619D.2010708@macports.org> We just need the greatest regex of aaaaaall tiiiiiiiime! On 2009-8-23 07:15, Jeremy Lavergne wrote: > Likely, a few sed scripts or a tcl script to rewrite the Portfiles could > do it all for us. > > On Aug 22, 2009, at 5:12 PM, Ryan Schmidt wrote: > >> We have thousands of ports already. It's a little late to change the >> language now, I think. From jkh at apple.com Sat Aug 22 19:09:17 2009 From: jkh at apple.com (Jordan K. Hubbard) Date: Sat, 22 Aug 2009 19:09:17 -0700 Subject: Time for a little Object-Oriented refactoring? [was Re: Automatic homepage for sourceforge, googlecode, etc.] In-Reply-To: References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> <3781B43B-2138-4904-A11F-55A00D91D81C@apple.com> <4331130D-8853-4195-8F40-1B482F98A649@lavergne.gotdns.org> Message-ID: <9A30E6AB-07CA-4ECA-B71B-CB950021240F@apple.com> That's it in a nutshell. None of us thought that Tcl was the most popular/best/cromulent scripting language around (all the accusations I get of being a Tcl fan-boy aside :), and if we'd wanted people to be exposed directly to the language on a daily basis we would probably have actually chosen Ruby as the implementation language and followed the newest hotness. Our primary goal, however, was to be able to express ports as simple key/value pairs for the majority case, the minority/complex cases involving hopefully only small snippets of actual "code". That said, there's no reason that a Portfile needs to written in the same language as the *implementation framework* and we've always known that. A portfile could just as easily be written in a DSL which base/ implements. I don't think we should be too constrained in our thinking for MacPorts 2.0, since we versioned the crap out of ports' individual modules from the beginning precisely in order to enable some sharp, incompatible departure(s) in the future. - Jordan On Aug 22, 2009, at 2:12 PM, Ryan Schmidt wrote: > And there are also people who know existing MacPorts syntax well, > and do not know Python. > > > I understand Tcl was chosen for a reason, one of them being that it > has a nice syntax that doesn't burden you with a lot of quoting and > escaping when that isn't necessary in most cases. Having to write > > name = "foo"; > > instead of > > name foo > > may not look like a lot of extra characters but it would certainly > add up. > > > We have thousands of ports already. It's a little late to change the > language now, I think. From ryandesign at macports.org Sun Aug 23 01:45:28 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 23 Aug 2009 03:45:28 -0500 Subject: [56009] trunk/dports/python In-Reply-To: <20090823045442.5BCD52453880@beta.macosforge.org> References: <20090823045442.5BCD52453880@beta.macosforge.org> Message-ID: On Aug 22, 2009, at 23:54, akitada at macports.org wrote: > Revision: 56009 > http://trac.macports.org/changeset/56009 > Author: akitada at macports.org > Date: 2009-08-22 21:54:41 -0700 (Sat, 22 Aug 2009) > Log Message: > ----------- > Added missing symlinks to sphinx-* commands. What about the changes to py26-werkzeug? > Modified Paths: > -------------- > trunk/dports/python/py26-sphinx/Portfile > trunk/dports/python/py26-werkzeug/Portfile > > Modified: trunk/dports/python/py26-sphinx/Portfile > =================================================================== > --- trunk/dports/python/py26-sphinx/Portfile 2009-08-23 02:53:36 > UTC (rev 56008) > +++ trunk/dports/python/py26-sphinx/Portfile 2009-08-23 04:54:41 > UTC (rev 56009) > @@ -1,3 +1,4 @@ > +# -*- 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 > @@ -5,6 +6,7 @@ > > name py26-sphinx > version 0.6.2 > +revision 1 > categories-append devel > maintainers jmr openmaintainer > description Python documentation generator > @@ -30,5 +32,11 @@ > port:py26-jinja2 \ > port:py26-setuptools > > +post-destroot { > + foreach bin [glob -tails -directory ${destroot}$ > {python.prefix}/bin *] { > + ln -s ${python.prefix}/bin/${bin} ${destroot}${prefix}/bin/ > ${bin}${python.branch} > + } > +} > + > livecheck.check regex > livecheck.regex {

Current version: ([0-9.]+)

} > > Modified: trunk/dports/python/py26-werkzeug/Portfile > =================================================================== > --- trunk/dports/python/py26-werkzeug/Portfile 2009-08-23 02:53:36 > UTC (rev 56008) > +++ trunk/dports/python/py26-werkzeug/Portfile 2009-08-23 04:54:41 > UTC (rev 56009) > @@ -6,6 +6,7 @@ > > name py26-werkzeug > version 0.5.1 > +revision 1 > categories-append www > maintainers openmaintainer akitada > description The Swiss Army knife of Python web development. > @@ -66,3 +67,13 @@ > use_zip yes > > depends_lib port:py26-setuptools > + > +post-destroot { > + xinstall -m 755 -d ${destroot}${prefix}/share/doc/${name}/ > examples > + foreach f [glob -directory ${worksrcpath}/docs *] { > + copy $f ${destroot}${prefix}/share/doc/${name}/[file tail $f] > + } > + foreach f [glob -directory ${worksrcpath}/examples *] { > + copy $f ${destroot}${prefix}/share/doc/${name}/examples/ > [file tail $f] > + } > +} From raimue at macports.org Sun Aug 23 01:51:46 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 23 Aug 2009 10:51:46 +0200 Subject: Automatic homepage for sourceforge, googlecode, etc. In-Reply-To: <2C821955-9ACA-4B29-982F-6590FBF1627A@macports.org> References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> <4A905425.6040009@macports.org> <2C821955-9ACA-4B29-982F-6590FBF1627A@macports.org> Message-ID: <4A910322.7060801@macports.org> On 2009-08-22 22:32 , Ryan Schmidt wrote: > That syntax looks nice. But all the existing use_ options are in > MacPorts base code. Part of the motivation for my suggestion is to > move this out of MacPorts base and into something inside the dports/ > _resources directory, e.g. a portgroup. Well, then a PortGroup would be the better option. > I wonder if maybe just renaming the "PortGroup" command would provide > satisfaction. Instead of > > PortGroup sourceforge 1.0 > > it could be > > include sourceforge 1.0 > > or > > use sourceforge 1.0 PortGroup is the keyword which matches best with PortSystem. Do we really need to change this? The meaning of "PortGroup sourceforge 1.0" should still be pretty clear. >> The problem with PortGroups are that they are usually included at the >> top, even before the name of the port is set. That means that you >> cannot >> set homepage/master_sites/etc. at the time of inclusion and thus need >> another command in the Portfile. > > Not so! We have a delayed expansion mechanism via the default / > options infrastructure. e.g. > [...] You are right, I forgot that default values can be overwritten and use late expansion. Please forget my concerns :-) Using this approach individual options can still be overwritten with different values in the Portfile, which is good in my opinion as it allows us to be very flexible. Rainer From ryandesign at macports.org Sun Aug 23 03:11:14 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 23 Aug 2009 05:11:14 -0500 Subject: Automatic homepage for sourceforge, googlecode, etc. In-Reply-To: <4A910322.7060801@macports.org> References: <9528A81E-9039-4397-8D8E-B64730F69601@macports.org> <70207216-234B-4B72-9D8F-656586E3C59E@lavergne.gotdns.org> <52F01D49-572E-4FCF-A990-E6A551D771A5@macports.org> <4A905425.6040009@macports.org> <2C821955-9ACA-4B29-982F-6590FBF1627A@macports.org> <4A910322.7060801@macports.org> Message-ID: <02A115B3-7ABF-493E-97AC-338E2082BF6B@macports.org> On Aug 23, 2009, at 03:51, Rainer M?ller wrote: > On 2009-08-22 22:32 , Ryan Schmidt wrote: >> That syntax looks nice. But all the existing use_ options are in >> MacPorts base code. Part of the motivation for my suggestion is to >> move this out of MacPorts base and into something inside the dports/ >> _resources directory, e.g. a portgroup. > > Well, then a PortGroup would be the better option. How to handle the colon part of the master_sites definition? e.g. port tightvnc says master_sites sourceforge:vnc-tight Would we have to do PortGroup sourceforge 1.0 sourceforge.name vnc-tight or is there a better idea? >> I wonder if maybe just renaming the "PortGroup" command would provide >> satisfaction. Instead of >> >> PortGroup sourceforge 1.0 >> >> it could be >> >> include sourceforge 1.0 >> >> or >> >> use sourceforge 1.0 > > PortGroup is the keyword which matches best with PortSystem. Do we > really need to change this? The meaning of "PortGroup sourceforge 1.0" > should still be pretty clear. I was already thinking further. We could look at ways of turning other flags (like the use_ flags) into "portgroups" too. The use_ flags we currently have in ports are: use_7z use_autoconf use_automake use_autoreconf use_bzip2 use_configure use_dmg use_lzma use_parallel_build use_test use_xmkmf use_zip I could easily see moving the different distfile compression / archiving types into "portgroups". Again this would let us support new compression types without a new MacPorts release. (e.g. xz was recently requested [1]). It would also help with types that don't fit neatly into the "one command (or unix pipeline) can decompress and extract an archive" mindset MacPorts base currently has. This would enable us to support, for example, .dmg.gz, .dmg.zip, etc. We could write "PortGroup bzip2 1.0" but if we switch the verb "PortGroup" to "use" then we could write "use bzip2 1.0" which might be a more natural change from "use_bzip2 yes". use_xmkmf should probably have been a portgroup all along; that fits right alongside the existing xcode portgroup. [1] http://lists.macosforge.org/pipermail/macports-dev/2009-August/ 009548.html From ryandesign at macports.org Sun Aug 23 13:39:29 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 23 Aug 2009 15:39:29 -0500 Subject: [56020] trunk/dports/_resources/port1.0/variant_descriptions.conf In-Reply-To: <20090823134649.93BAC24608F7@beta.macosforge.org> References: <20090823134649.93BAC24608F7@beta.macosforge.org> Message-ID: <14CEC89F-23FA-4124-98F1-969D0767E388@macports.org> On Aug 23, 2009, at 08:46, raimue at macports.org wrote: > Revision: 56020 > http://trac.macports.org/changeset/56020 > Author: raimue at macports.org > Date: 2009-08-23 06:46:48 -0700 (Sun, 23 Aug 2009) > Log Message: > ----------- > Add a global description for +quartz > > Modified Paths: > -------------- > trunk/dports/_resources/port1.0/variant_descriptions.conf > > Modified: trunk/dports/_resources/port1.0/variant_descriptions.conf > =================================================================== > --- trunk/dports/_resources/port1.0/variant_descriptions.conf > 2009-08-23 13:40:14 UTC (rev 56019) > +++ trunk/dports/_resources/port1.0/variant_descriptions.conf > 2009-08-23 13:46:48 UTC (rev 56020) > @@ -30,3 +30,4 @@ > solaris {Platform variant, do not select manually} > sunos {Platform variant, do not select manually} > universal {Build for multiple architectures} > +quartz {Support for native Mac OS X interface} Isn't Quartz more about using native Mac OS X graphics drawing routines? IMHO it has nothing to do with what user interface is provided. At least, that's what the +quartz variant means in e.g. the cairo and pango ports. I thought the variant name for providing a Mac OS X GUI interface was +aqua. http://en.wikipedia.org/wiki/Quartz_(graphics_layer) http://en.wikipedia.org/wiki/Aqua_(user_interface) I would say something like: quartz {Use Mac OS X Quartz graphics drawing routines} aqua {Provide native Mac OS X Aqua user interface} From ryandesign at macports.org Sun Aug 23 14:03:22 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 23 Aug 2009 16:03:22 -0500 Subject: [55961] trunk/dports/python In-Reply-To: References: <20090822114342.4F029244C01C@beta.macosforge.org> <4A9016E0.80007@macports.org> <08168B8D-2A29-45EE-B453-91A69E5D351F@web.de> <65A7C6EE-0A6D-4CDF-9CB9-F0411D1BE943@macports.org> Message-ID: <1120E9A4-F335-48EF-9E3D-99AC14046B7B@macports.org> On Aug 23, 2009, at 07:04, Jonas B?hr wrote: > Am 22.08.2009 um 22:25 schrieb Ryan Schmidt: > >> On Aug 22, 2009, at 14:13, Jonas B?hr wrote: >> >>> R is needed to build and run. The install script looks for "R" in >>> PATH, that's all. >>> >>> The rational behind the custom R is to lighten the dependencies >>> for the user. The R-Project provides very good customizable >>> installer/binaries for Mac OS X. MacPorts's R port however can't >>> be customized at all and pulls in a complete gcc plus xorg. In my >>> eyes it's much more convenient for a user who already uses R to >>> continue to use his installation and install rpy2 within 5 >>> minutes instead of spending 6 hours compiling xorg, gcc, and an >>> other bunch of dependencies for nothing. If the user's R comes in >>> PATH before macports R, it won't be used anyway. >> >> MacPorts does not use your $PATH at build time. It uses the value >> of binpath in macports.conf. So for this to work a user would at >> least have to add the location of their binary installation of R >> to the binpath, and maybe also to their runtime PATH. > > Hmm.. That's interesting, because it worked flawless here; my R is / > usr/bin/R. Ok, then that's why it worked. The default binpath does of course include /usr/bin, since /usr/bin includes tons of essential commands without which most software could not be built. It is pretty improper for a third-party tool to install itself into / usr/bin, though. That directory should be reserved for the OS vendor. > I've just checked my macports.conf and there is indeed no binpath > entry. When was this introduced in the default config? I've never > touched mine, and the header sais: > $Id: macports.conf.in 31197 2007-11-18 06:06:14Z jmpp at macports.org $ http://trac.macports.org/changeset/36127 If you do not specify binpath, the default (see below) is used. >> The R port presumably requires a gcc port because it cannot be >> built with the gcc Apple provides. > > indeed, apple's gcc does not provide a fortran77 compiler. I didn't > say these dependencies are useless, just that they are quite heavy; > and I assumed that the resulting R won't even be used if the custom > R comes first in PATH, like in my installation. Ah, but if you have not changed the binpath then the custom R path does not come first in your installation. :) The default binpath is: ${prefix}/bin:${prefix}/sbin:/bin:/sbin:/usr/bin:/usr/sbin:$ {x11prefix}/bin http://guide.macports.org/chunked/internals.configuration- files.html#internals.configuration-files.macports-conf (${x11prefix}/bin goes away with MacPorts 1.8.0.) >> There are many many ports in MacPorts for software that needs >> xorg. They will all cause various xorg ports to be installed. That >> is not a reason not to use them. > > I'll file a ticket for a noX11 variant for the R port. FYI the name we've standardized on for such a variant is "no_x11". >> It is not the MacPorts way to use a user's software that was not >> installed with MacPorts. MacPorts is a package management system. >> It is supposed to manage your packages. But it cannot do that if >> you allow ports to use software that is outside of MacPorts. >> >> It would be best to remove the custom_r variant and make the port >> always use the MacPorts R port. If the R port does not provide all >> the options a user of R would expect, please file tickets >> requesting the R port be enhanced in whatever ways necessary. > > Ok then, I'll replace the variant with a comment in the Portfile so > that people who know what they are doing can manipulate the > Portfile to continue using their R installation: > ---------8<---------8<--------- > # To continue using your custom R installation instead of MacPorts' R, > # you have to remove this dependency line and make sure that your R > # is in MacPorts' binpath, see your macports.conf for details. > ---------8<---------8<--------- > Is that a compromise everybody can live with? Perhaps.... But again what were the advantages of using the non-MacPorts R, aside from your concerns over the number of dependencies and the build time? You said it could be customized and the MacPorts R port could not. In what ways? From raimue at macports.org Sun Aug 23 15:42:43 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 24 Aug 2009 00:42:43 +0200 Subject: [56020] trunk/dports/_resources/port1.0/variant_descriptions.conf In-Reply-To: <14CEC89F-23FA-4124-98F1-969D0767E388@macports.org> References: <20090823134649.93BAC24608F7@beta.macosforge.org> <14CEC89F-23FA-4124-98F1-969D0767E388@macports.org> Message-ID: <4A91C5E3.6030807@macports.org> On 2009-08-23 22:39 , Ryan Schmidt wrote: > On Aug 23, 2009, at 08:46, raimue at macports.org wrote: >> Modified: trunk/dports/_resources/port1.0/variant_descriptions.conf >> =================================================================== >> --- trunk/dports/_resources/port1.0/variant_descriptions.conf >> 2009-08-23 13:40:14 UTC (rev 56019) >> +++ trunk/dports/_resources/port1.0/variant_descriptions.conf >> 2009-08-23 13:46:48 UTC (rev 56020) >> @@ -30,3 +30,4 @@ >> solaris {Platform variant, do not select manually} >> sunos {Platform variant, do not select manually} >> universal {Build for multiple architectures} >> +quartz {Support for native Mac OS X interface} > > Isn't Quartz more about using native Mac OS X graphics drawing > routines? IMHO it has nothing to do with what user interface is > provided. At least, that's what the +quartz variant means in e.g. the > cairo and pango ports. I thought the variant name for providing a Mac > OS X GUI interface was +aqua. Thinking about this again you are probably right. Although most people associate +quartz with the native Mac OS X environment in my opinion. As I added gmpc I noticed that many ports have a different description for +quartz and thought it would be good to have a single unique description for this variant. In this case, gmpc offers to use Mac OS X integration for the menu bar which requires gtk2 +quartz, therefore I also named this variant +quartz as it was most appropriate for me. So this cannot be only about the library used for drawin widgets, but it is more. The +aqua variant seemed inappropriate as it is still using gtk2 and not the native Cocoa framework. Rainer From ryandesign at macports.org Mon Aug 24 13:58:43 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 24 Aug 2009 15:58:43 -0500 Subject: Snow Leopard Message-ID: <9663FAF8-D9F5-459C-8D61-6160CC7AF774@macports.org> Apple marketing email in my inbox says Snow Leopard is out on Friday, August 28. So we should strive to have the final version of MacPorts 1.8.0 out before then. Has everybody tested 1.8.0-rc1 thoroughly? :) Please do! Can we get a Snow Leopard disk image of the MacPorts 1.8.0 installer made by somebody? From jeremy at lavergne.gotdns.org Mon Aug 24 14:41:14 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Mon, 24 Aug 2009 17:41:14 -0400 Subject: port snow leopard compatibility Message-ID: Feel free to make additions to the list (or send updates to me): http://trac.macports.org/wiki/snc/snowleopard If you want to, no obligations :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From jmr at macports.org Mon Aug 24 18:33:56 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 25 Aug 2009 11:33:56 +1000 Subject: Snow Leopard In-Reply-To: <9663FAF8-D9F5-459C-8D61-6160CC7AF774@macports.org> References: <9663FAF8-D9F5-459C-8D61-6160CC7AF774@macports.org> Message-ID: <4A933F84.10103@macports.org> On 2009-8-25 06:58, Ryan Schmidt wrote: > Apple marketing email in my inbox says Snow Leopard is out on Friday, > August 28. So we should strive to have the final version of MacPorts > 1.8.0 out before then. That was the plan. :-) - Josh From john_owens at yahoo.com Tue Aug 25 10:05:06 2009 From: john_owens at yahoo.com (John Owens) Date: Tue, 25 Aug 2009 17:05:06 +0000 (UTC) Subject: Post on Snow Leopard status? Message-ID: Millions of people will open an early Christmas present on Friday with the Snow Leopard release and I haven't seen anything recent on the macports user list that specifically targets what users should do (or anything on the macports home page). I'm watching dozens of checkins on a snowleopard page that mark what works / what doesn't work (?) but I think a lot of folks, me included, aren't sure what to expect when we upgrade to 10.6. It'd be nice, perhaps on the home page, to put a best-practices note (e.g. "your current install will work fine, the big changes that affect you will be X and Y, here's where to look to see if your favorite package is going to work when recompiled", etc.). (Sorry if I missed a post - I looked at all the post titles back through the beginning of July.) JDO From jmr at macports.org Tue Aug 25 10:37:38 2009 From: jmr at macports.org (Joshua Root) Date: Wed, 26 Aug 2009 03:37:38 +1000 Subject: Post on Snow Leopard status? In-Reply-To: References: Message-ID: <4A942162.40901@macports.org> On 2009-8-26 03:05, John Owens wrote: > Millions of people will open an early Christmas present on > Friday with the Snow Leopard release and I haven't seen > anything recent on the macports user list that specifically > targets what users should do (or anything on the macports > home page). I'm watching dozens of checkins on a snowleopard > page that mark what works / what doesn't work (?) but I think > a lot of folks, me included, aren't sure what to expect when > we upgrade to 10.6. It'd be nice, perhaps on the home page, to > put a best-practices note (e.g. "your current install will > work fine, the big changes that affect you will be X and Y, > here's where to look to see if your favorite package is going > to work when recompiled", etc.). It could probably be documented better, but the deal has always been that you need to reinstall MacPorts and all your ports when you change to a different major OS version (or architecture). For 10.6, you need MacPorts 1.8, which we're aiming to release on the same day. Finally, apart from the fact that you should always state your system configuration when filing tickets, it doesn't matter that it's a new OS version. If something is broken and there isn't an existing ticket, open one. - Josh From ryandesign at macports.org Tue Aug 25 13:43:11 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 25 Aug 2009 15:43:11 -0500 Subject: [56253] trunk/dports/python In-Reply-To: <20090825195150.9C0C1248D27A@beta.macosforge.org> References: <20090825195150.9C0C1248D27A@beta.macosforge.org> Message-ID: On Aug 25, 2009, at 14:51, jameskyle at macports.org wrote: > Revision: 56253 > http://trac.macports.org/changeset/56253 > Author: jameskyle at macports.org > Date: 2009-08-25 12:51:49 -0700 (Tue, 25 Aug 2009) > Log Message: > ----------- > Added python 2.6 version for pywavelets > > Added Paths: > ----------- > trunk/dports/python/py26-pywavelets/ > trunk/dports/python/py26-pywavelets/Portfile > +maintainers ucla.edu:jameskyle You should use your macports handle here. > +distfiles PyWavelets-${version}.tar.gz > +worksrcdir PyWavelets-${version} These two lines can be more simply expressed as distname PyWavelets-${version} From ryandesign at macports.org Tue Aug 25 13:43:09 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 25 Aug 2009 15:43:09 -0500 Subject: [56254] trunk/dports/python In-Reply-To: <20090825195153.77A57248D2E4@beta.macosforge.org> References: <20090825195153.77A57248D2E4@beta.macosforge.org> Message-ID: <9DA8A6E9-E1AC-493A-860D-24FDC7FFAC1D@macports.org> On Aug 25, 2009, at 14:51, jameskyle at macports.org wrote: > Revision: 56254 > http://trac.macports.org/changeset/56254 > Author: jameskyle at macports.org > Date: 2009-08-25 12:51:52 -0700 (Tue, 25 Aug 2009) > Log Message: > ----------- > Added python 2.6 version of pymvpa > > Added Paths: > ----------- > trunk/dports/python/py26-pymvpa/ > trunk/dports/python/py26-pymvpa/Portfile > trunk/dports/python/py26-pymvpa/files/ > trunk/dports/python/py26-pymvpa/files/patch-mvpa.diff > trunk/dports/python/py26-pymvpa/files/setup-py.diff > +default_variants +pywavelet +libsvm +hcluster +pynifti > +shogun +scipy Default variants are difficult for the user to turn off. If you want these features enabled by default, why not delete the variants and just make the port always build them? If there really is value in allowing the user to disable these features, make them "no_" variants, e.g. "no_pywavelet", "no_libsvm", etc. > +variant scipy description {Add support for scipy libraries} { > + depends_lib-append port:py26-scipy > +} > + > +variant pynifti description {Add support for the Nifti file format} { > + depends_lib-append port:py26-pynifti > +} > + > +variant hcluster description {perform cluster analysis and plot > dendograms of results} { > + depends_lib-append port:py26-hcluster > +} > +variant matplotlib description {include support for the matplotlib > library} { > + ui_msg "The default matplotlib build may fail to compile." > + ui_msg "If this is the case, please build with +wxpython > variant." > + depends_lib-append port:py26-matplotlib > +} > + > +variant pywavelet description {include support for pywavelet > module} { > + depends_lib-append port:py26-pywavelets > +} > + > +variant shogun description {compile support for the python shogun > classifiers} { > + depends_lib-append port:shogun > +} Variants must do more than just add a dependency. They must also inform the software it is ok to use that dependency -- like you did in this variant: > +variant libsvm description {compile the libsvm classifier > extension} { > + depends_lib-append port:libsvm \ > + port:swig > + configure.args-append --with-libsvm > +} From ryandesign at macports.org Tue Aug 25 13:47:10 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 25 Aug 2009 15:47:10 -0500 Subject: [56256] trunk/dports/science/xmedcon/Portfile In-Reply-To: <20090825202522.C4682248D983@beta.macosforge.org> References: <20090825202522.C4682248D983@beta.macosforge.org> Message-ID: <96551834-2F85-4A2F-BEA5-DC988E10CB09@macports.org> On Aug 25, 2009, at 15:25, jameskyle at macports.org wrote: > Revision: 56256 > http://trac.macports.org/changeset/56256 > Author: jameskyle at macports.org > Date: 2009-08-25 13:25:22 -0700 (Tue, 25 Aug 2009) > Log Message: > ----------- > Removed fortran variant, replaced with gcc43. #20596 > > Modified Paths: > -------------- > trunk/dports/science/xmedcon/Portfile > @@ -26,6 +26,7 @@ > --with-png-prefix=${prefix} > > > +default_variants +gcc43 > > variant gtk2 conflicts gtk1 description {Enable gtk2 gui front end} { > configure.args-delete --disable-gui > @@ -41,10 +42,9 @@ > configure.args-append --enable-gtk1 > } > > -variant fortran description {Enable fortran compiler support} { > +variant gcc43 description {Enable gcc43 compiler support} { > depends_lib-append port:gcc43 > > - configure.compiler ${prefix}/bin/gcc-mp-4.3 > - configure.f77 ${prefix}/bin/gfortran-mp-4.3 > + configure.compiler macports-gcc-4.3 > } Why might a user want or not want to use this variant? Again, the default variant makes it difficult for the user to indicate that they do not want to use it. From ryandesign at macports.org Tue Aug 25 14:27:47 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 25 Aug 2009 16:27:47 -0500 Subject: [56239] trunk/dports In-Reply-To: <20090825165105.EBD9A248B138@beta.macosforge.org> References: <20090825165105.EBD9A248B138@beta.macosforge.org> Message-ID: <8439A42F-CCD9-436F-863E-1AC39DFEA7EC@macports.org> On Aug 25, 2009, at 11:51, jameskyle at macports.org wrote: > Revision: 56239 > http://trac.macports.org/changeset/56239 > Author: jameskyle at macports.org > Date: 2009-08-25 09:51:00 -0700 (Tue, 25 Aug 2009) > Log Message: > ----------- > Incremental commit on python version detection ...in shogun, but did you also mean to update the version of x264? > Modified Paths: > -------------- > trunk/dports/math/shogun/Portfile > trunk/dports/multimedia/x264/Portfile > Modified: trunk/dports/multimedia/x264/Portfile > =================================================================== > --- trunk/dports/multimedia/x264/Portfile 2009-08-25 15:56:17 UTC > (rev 56238) > +++ trunk/dports/multimedia/x264/Portfile 2009-08-25 16:51:00 UTC > (rev 56239) > @@ -5,7 +5,7 @@ > PortGroup muniversal 1.0 > > name x264 > -version 20090408 > +version 20090810 > revision 1 > categories multimedia > platforms darwin > @@ -20,10 +20,11 @@ > master_sites ftp://ftp.videolan.org/pub/videolan/x264/snapshots/ > distname ${name}-snapshot-${version}-2245 > > -checksums md5 d1c7323a052740b1c16f4aea917cb561 \ > - sha1 9dae6f86da058dc0a96b49102ff0dedb33c5a5a8 \ > - rmd160 98e2e0089be071165363324946c0eb296a6f002e > +checksums md5 6671b66a0a83769c54ba9cd10ad598d8 \ > + sha1 > 26abd8c1dc05dae04f99b33a689e4ee7debd9126 \ > + rmd160 f8297dcb4a43207f5c03165a2320425a640ff4d7 > > + > use_bzip2 yes > > pre-extract { From jameskyle at macports.org Tue Aug 25 14:40:53 2009 From: jameskyle at macports.org (James Kyle) Date: Tue, 25 Aug 2009 14:40:53 -0700 Subject: [56239] trunk/dports In-Reply-To: <8439A42F-CCD9-436F-863E-1AC39DFEA7EC@macports.org> References: <20090825165105.EBD9A248B138@beta.macosforge.org> <8439A42F-CCD9-436F-863E-1AC39DFEA7EC@macports.org> Message-ID: <4B1EC5C9-63AD-47BD-A183-04C3AB163170@macports.org> Hm, that slipped in. I looked at it though. Looks like it's just an minor version update. No harm no foul? -james On Aug 25, 2009, at 2:27 PM, Ryan Schmidt wrote: > > On Aug 25, 2009, at 11:51, jameskyle at macports.org wrote: > >> Revision: 56239 >> http://trac.macports.org/changeset/56239 >> Author: jameskyle at macports.org >> Date: 2009-08-25 09:51:00 -0700 (Tue, 25 Aug 2009) >> Log Message: >> ----------- >> Incremental commit on python version detection > > ...in shogun, but did you also mean to update the version of x264? > > >> Modified Paths: >> -------------- >> trunk/dports/math/shogun/Portfile >> trunk/dports/multimedia/x264/Portfile > > >> Modified: trunk/dports/multimedia/x264/Portfile >> =================================================================== >> --- trunk/dports/multimedia/x264/Portfile 2009-08-25 15:56:17 UTC >> (rev 56238) >> +++ trunk/dports/multimedia/x264/Portfile 2009-08-25 16:51:00 UTC >> (rev 56239) >> @@ -5,7 +5,7 @@ >> PortGroup muniversal 1.0 >> >> name x264 >> -version 20090408 >> +version 20090810 >> revision 1 >> categories multimedia >> platforms darwin >> @@ -20,10 +20,11 @@ >> master_sites ftp://ftp.videolan.org/pub/videolan/x264/snapshots/ >> distname ${name}-snapshot-${version}-2245 >> >> -checksums md5 d1c7323a052740b1c16f4aea917cb561 \ >> - sha1 9dae6f86da058dc0a96b49102ff0dedb33c5a5a8 \ >> - rmd160 98e2e0089be071165363324946c0eb296a6f002e >> +checksums md5 6671b66a0a83769c54ba9cd10ad598d8 \ >> + sha1 >> 26abd8c1dc05dae04f99b33a689e4ee7debd9126 \ >> + rmd160 f8297dcb4a43207f5c03165a2320425a640ff4d7 >> >> + >> use_bzip2 yes >> >> pre-extract { > > From ryandesign at macports.org Tue Aug 25 15:32:30 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 25 Aug 2009 17:32:30 -0500 Subject: [56256] trunk/dports/science/xmedcon/Portfile In-Reply-To: <83885B11-4C74-43CC-98BE-3D2E30419D75@macports.org> References: <20090825202522.C4682248D983@beta.macosforge.org> <96551834-2F85-4A2F-BEA5-DC988E10CB09@macports.org> <83885B11-4C74-43CC-98BE-3D2E30419D75@macports.org> Message-ID: On Aug 25, 2009, at 16:46, James Kyle wrote: > I was going with ticket #20103 rcommendations of gcc43 for tickets. > Think it'd be better to just use gcc43 and add something like a gcc- > apple variant? I would either leave the variant called gcc43 and just not make it a default variant Or remove the gcc43 variant and make the port always build with gcc43, if there is an advantage to doing so Or remove the gcc43 variant and make the port always build with Apple gcc I still didn't understand what benefit is achieved by using gcc43 instead of Apple gcc for this port. From ryandesign at macports.org Tue Aug 25 15:33:45 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 25 Aug 2009 17:33:45 -0500 Subject: [56254] trunk/dports/python In-Reply-To: References: <20090825195153.77A57248D2E4@beta.macosforge.org> <9DA8A6E9-E1AC-493A-860D-24FDC7FFAC1D@macports.org> Message-ID: <4C725281-193E-4CE7-A8D3-FF18CA2BAA7D@macports.org> On Aug 25, 2009, at 17:08, James Kyle wrote: >> Default variants are difficult for the user to turn off. If you >> want these features enabled by default, why not delete the >> variants and just make the port always build them? >> >> If there really is value in allowing the user to disable these >> features, make them "no_" variants, e.g. "no_pywavelet", >> "no_libsvm", etc. > > Sounds good. > > >> Variants must do more than just add a dependency. They must also >> inform the software it is ok to use that dependency -- like you >> did in this variant: > > the package will use the above libraries if they are present, but > not if they are not. the variant allows the user to pull them into > the build process and so enable support. So the informing is > effectively done automatically as long as the library is installed. This means the port would use those libraries even if the corresponding variant was not selected. This is not ok. The port must tell the software it is not ok to use those libraries unless the variant is selected. From ryandesign at macports.org Tue Aug 25 15:36:39 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 25 Aug 2009 17:36:39 -0500 Subject: [56239] trunk/dports In-Reply-To: <4B1EC5C9-63AD-47BD-A183-04C3AB163170@macports.org> References: <20090825165105.EBD9A248B138@beta.macosforge.org> <8439A42F-CCD9-436F-863E-1AC39DFEA7EC@macports.org> <4B1EC5C9-63AD-47BD-A183-04C3AB163170@macports.org> Message-ID: <3C2EF277-EF4C-457D-BAE0-84384D9B38C1@macports.org> On Aug 25, 2009, at 16:40, James Kyle wrote: >> On Aug 25, 2009, at 11:51, jameskyle at macports.org wrote: >> >>> Revision: 56239 >>> http://trac.macports.org/changeset/56239 >>> Author: jameskyle at macports.org >>> Date: 2009-08-25 09:51:00 -0700 (Tue, 25 Aug 2009) >>> Log Message: >>> ----------- >>> Incremental commit on python version detection >> >> ...in shogun, but did you also mean to update the version of x264? > > Hm, that slipped in. I looked at it though. Looks like it's just an > minor version update. No harm no foul? Ok, then you should just amend the commit message to indicate: svn propedit --revprop -r56239 svn:log \ http://svn.macosforge.org/repository/macports/trunk From blair at orcaware.com Tue Aug 25 15:59:32 2009 From: blair at orcaware.com (Blair Zajac) Date: Tue, 25 Aug 2009 15:59:32 -0700 Subject: [56239] trunk/dports In-Reply-To: <3C2EF277-EF4C-457D-BAE0-84384D9B38C1@macports.org> References: <20090825165105.EBD9A248B138@beta.macosforge.org> <8439A42F-CCD9-436F-863E-1AC39DFEA7EC@macports.org> <4B1EC5C9-63AD-47BD-A183-04C3AB163170@macports.org> <3C2EF277-EF4C-457D-BAE0-84384D9B38C1@macports.org> Message-ID: <4A946CD4.50000@orcaware.com> Ryan Schmidt wrote: > > Ok, then you should just amend the commit message to indicate: > > svn propedit --revprop -r56239 svn:log \ > http://svn.macosforge.org/repository/macports/trunk For people who don't use svn much, I have a Bourne shell function for this to make it easier to correct log messages: # svn log edit: run it like # svnle 12345 svnle() { svn pe --revprop svn:log -r ${1+"$@"} } If you run it in a working copy, it'll use the URL from the working copy and you won't have to supply the URL. Blair From jameskyle at macports.org Tue Aug 25 18:09:39 2009 From: jameskyle at macports.org (James Kyle) Date: Tue, 25 Aug 2009 18:09:39 -0700 Subject: [56254] trunk/dports/python In-Reply-To: <4C725281-193E-4CE7-A8D3-FF18CA2BAA7D@macports.org> References: <20090825195153.77A57248D2E4@beta.macosforge.org> <9DA8A6E9-E1AC-493A-860D-24FDC7FFAC1D@macports.org> <4C725281-193E-4CE7-A8D3-FF18CA2BAA7D@macports.org> Message-ID: <10B8BB55-8710-4B87-A599-64389ECE2B32@macports.org> On Aug 25, 2009, at 3:33 PM, Ryan Schmidt wrote: > On Aug 25, 2009, at 17:08, James Kyle wrote: > >>> Default variants are difficult for the user to turn off. If you >>> want these features enabled by default, why not delete the >>> variants and just make the port always build them? >>> >>> If there really is value in allowing the user to disable these >>> features, make them "no_" variants, e.g. "no_pywavelet", >>> "no_libsvm", etc. >> >> Sounds good. >> >> >>> Variants must do more than just add a dependency. They must also >>> inform the software it is ok to use that dependency -- like you >>> did in this variant: >> >> the package will use the above libraries if they are present, but >> not if they are not. the variant allows the user to pull them into >> the build process and so enable support. So the informing is >> effectively done automatically as long as the library is installed. > > This means the port would use those libraries even if the > corresponding variant was not selected. This is not ok. The port > must tell the software it is not ok to use those libraries unless > the variant is selected. This is not how the software works. I would have to rewrite it. The rewrite would also break it's feature set. It's a python module. Basically when you call a method 'foo' that, say, performs a matrix convolution. If a c module exists for that method it will use that. If it does not, it does the calculation using its own pure python algorithm (usually much slower). This isn't a bad thing. And I'm not sure how realistic it is to want it to not do this. From blair at orcaware.com Tue Aug 25 18:20:58 2009 From: blair at orcaware.com (Blair Zajac) Date: Tue, 25 Aug 2009 18:20:58 -0700 Subject: [56254] trunk/dports/python In-Reply-To: <10B8BB55-8710-4B87-A599-64389ECE2B32@macports.org> References: <20090825195153.77A57248D2E4@beta.macosforge.org> <9DA8A6E9-E1AC-493A-860D-24FDC7FFAC1D@macports.org> <4C725281-193E-4CE7-A8D3-FF18CA2BAA7D@macports.org> <10B8BB55-8710-4B87-A599-64389ECE2B32@macports.org> Message-ID: <4A948DFA.8040207@orcaware.com> James Kyle wrote: > > On Aug 25, 2009, at 3:33 PM, Ryan Schmidt wrote: > >> On Aug 25, 2009, at 17:08, James Kyle wrote: >> >>>> Default variants are difficult for the user to turn off. If you want >>>> these features enabled by default, why not delete the variants and >>>> just make the port always build them? >>>> >>>> If there really is value in allowing the user to disable these >>>> features, make them "no_" variants, e.g. "no_pywavelet", >>>> "no_libsvm", etc. >>> >>> Sounds good. >>> >>> >>>> Variants must do more than just add a dependency. They must also >>>> inform the software it is ok to use that dependency -- like you did >>>> in this variant: >>> >>> the package will use the above libraries if they are present, but not >>> if they are not. the variant allows the user to pull them into the >>> build process and so enable support. So the informing is effectively >>> done automatically as long as the library is installed. >> >> This means the port would use those libraries even if the >> corresponding variant was not selected. This is not ok. The port must >> tell the software it is not ok to use those libraries unless the >> variant is selected. > > This is not how the software works. I would have to rewrite it. The > rewrite would also break it's feature set. > > It's a python module. Basically when you call a method 'foo' that, say, > performs a matrix convolution. If a c module exists for that method it > will use that. If it does not, it does the calculation using its own > pure python algorithm (usually much slower). You should have a way to disable the build from picking up that software if it's not requested then. > This isn't a bad thing. And I'm not sure how realistic it is to want it > to not do this. It is a bad thing. The problem is if you port uninstall one of the dependencies you picked up during the build, then MacPorts doesn't know about it. Blair From jameskyle at macports.org Tue Aug 25 18:29:09 2009 From: jameskyle at macports.org (James Kyle) Date: Tue, 25 Aug 2009 18:29:09 -0700 Subject: [56239] trunk/dports In-Reply-To: <3C2EF277-EF4C-457D-BAE0-84384D9B38C1@macports.org> References: <20090825165105.EBD9A248B138@beta.macosforge.org> <8439A42F-CCD9-436F-863E-1AC39DFEA7EC@macports.org> <4B1EC5C9-63AD-47BD-A183-04C3AB163170@macports.org> <3C2EF277-EF4C-457D-BAE0-84384D9B38C1@macports.org> Message-ID: <94ED6DAE-316E-4F48-A0CC-5BF1CAB6116C@macports.org> done. On Aug 25, 2009, at 3:36 PM, Ryan Schmidt wrote: > > On Aug 25, 2009, at 16:40, James Kyle wrote: > >>> On Aug 25, 2009, at 11:51, jameskyle at macports.org wrote: >>> >>>> Revision: 56239 >>>> http://trac.macports.org/changeset/56239 >>>> Author: jameskyle at macports.org >>>> Date: 2009-08-25 09:51:00 -0700 (Tue, 25 Aug 2009) >>>> Log Message: >>>> ----------- >>>> Incremental commit on python version detection >>> >>> ...in shogun, but did you also mean to update the version of x264? >> >> Hm, that slipped in. I looked at it though. Looks like it's just an >> minor version update. No harm no foul? > > Ok, then you should just amend the commit message to indicate: > > svn propedit --revprop -r56239 svn:log \ > http://svn.macosforge.org/repository/macports/trunk > > From jameskyle at macports.org Tue Aug 25 18:42:26 2009 From: jameskyle at macports.org (James Kyle) Date: Tue, 25 Aug 2009 18:42:26 -0700 Subject: [56254] trunk/dports/python In-Reply-To: <4A948DFA.8040207@orcaware.com> References: <20090825195153.77A57248D2E4@beta.macosforge.org> <9DA8A6E9-E1AC-493A-860D-24FDC7FFAC1D@macports.org> <4C725281-193E-4CE7-A8D3-FF18CA2BAA7D@macports.org> <10B8BB55-8710-4B87-A599-64389ECE2B32@macports.org> <4A948DFA.8040207@orcaware.com> Message-ID: On Aug 25, 2009, at 6:20 PM, Blair Zajac wrote: > James Kyle wrote: >> On Aug 25, 2009, at 3:33 PM, Ryan Schmidt wrote: >>> On Aug 25, 2009, at 17:08, James Kyle wrote: >>> >>>>> Default variants are difficult for the user to turn off. If you >>>>> want these features enabled by default, why not delete the >>>>> variants and just make the port always build them? >>>>> >>>>> If there really is value in allowing the user to disable these >>>>> features, make them "no_" variants, e.g. "no_pywavelet", >>>>> "no_libsvm", etc. >>>> >>>> Sounds good. >>>> >>>> >>>>> Variants must do more than just add a dependency. They must also >>>>> inform the software it is ok to use that dependency -- like you >>>>> did in this variant: >>>> >>>> the package will use the above libraries if they are present, but >>>> not if they are not. the variant allows the user to pull them >>>> into the build process and so enable support. So the informing is >>>> effectively done automatically as long as the library is installed. >>> >>> This means the port would use those libraries even if the >>> corresponding variant was not selected. This is not ok. The port >>> must tell the software it is not ok to use those libraries unless >>> the variant is selected. >> This is not how the software works. I would have to rewrite it. >> The rewrite would also break it's feature set. >> It's a python module. Basically when you call a method 'foo' that, >> say, performs a matrix convolution. If a c module exists for that >> method it will use that. If it does not, it does the calculation >> using its own pure python algorithm (usually much slower). > > You should have a way to disable the build from picking up that > software if it's not requested then. > >> This isn't a bad thing. And I'm not sure how realistic it is to >> want it to not do this. > > It is a bad thing. The problem is if you port uninstall one of the > dependencies you picked up during the build, then MacPorts doesn't > know about it. > > Blair > I'm confused here. Why would macports not know about a port uninstall? Let's take shogun as an example. If the shogun python library is available, some of the methods in pymvpa will use them. If not, it uses their own native code or (I think) displays an exception to the user if it doesn't have a built-in alternative. The psuedo check might be: if sg module found in path: use it elsif built in exists: use built in else: raise "functionality not enabled" The variant simply allows the user to declare "yes I want these functions available, so please pull these libraries in so that pymvpa can load them". There's nothing about it that slips files in or would remove them outside of the ports system. By all means if there is some breakage that could occur here I am eager to remedy it, but I don't see it. I wanted to give users a bit of flexibility in choosing which libraries they wanted support for in the pymvpa package. I suppose I could take an everything and the kitchen sink approach and just include them as dependencies and either no variants or no_* variants. But in practice this is really has no effect on the build process itself. -james From jameskyle at macports.org Tue Aug 25 18:45:41 2009 From: jameskyle at macports.org (James Kyle) Date: Tue, 25 Aug 2009 18:45:41 -0700 Subject: [56256] trunk/dports/science/xmedcon/Portfile In-Reply-To: References: <20090825202522.C4682248D983@beta.macosforge.org> <96551834-2F85-4A2F-BEA5-DC988E10CB09@macports.org> <83885B11-4C74-43CC-98BE-3D2E30419D75@macports.org> Message-ID: <331AF5E1-A62A-45B4-80D3-CC2E2107C397@macports.org> No significant advantage other than it falling in line with the other maintainer's of science oriented ports decision to consolidate our builds around a single compiler to prevent issues that can be caused by using different compiler versions. For example, if someone wanted to create a port that linked against both my port's image library and the blas/lapack library. It can ameliorate -james On Aug 25, 2009, at 3:32 PM, Ryan Schmidt wrote: > On Aug 25, 2009, at 16:46, James Kyle wrote: > >> I was going with ticket #20103 rcommendations of gcc43 for tickets. >> Think it'd be better to just use gcc43 and add something like a gcc- >> apple variant? > > I would either leave the variant called gcc43 and just not make it a > default variant > Or remove the gcc43 variant and make the port always build with > gcc43, if there is an advantage to doing so > Or remove the gcc43 variant and make the port always build with > Apple gcc > > I still didn't understand what benefit is achieved by using gcc43 > instead of Apple gcc for this port. > > From jameskyle at macports.org Tue Aug 25 18:58:28 2009 From: jameskyle at macports.org (James Kyle) Date: Tue, 25 Aug 2009 18:58:28 -0700 Subject: [56256] trunk/dports/science/xmedcon/Portfile In-Reply-To: <331AF5E1-A62A-45B4-80D3-CC2E2107C397@macports.org> References: <20090825202522.C4682248D983@beta.macosforge.org> <96551834-2F85-4A2F-BEA5-DC988E10CB09@macports.org> <83885B11-4C74-43CC-98BE-3D2E30419D75@macports.org> <331AF5E1-A62A-45B4-80D3-CC2E2107C397@macports.org> Message-ID: <9E2F801F-79B6-4620-A551-302927924D27@macports.org> On Aug 25, 2009, at 6:45 PM, James Kyle wrote: > No significant advantage other than it falling in line with the > other maintainer's of science oriented ports decision to consolidate > our builds around a single compiler to prevent issues that can be > caused by using different compiler versions. > > For example, if someone wanted to create a port that linked against > both my port's image library and the blas/lapack library. It can > ameliorate possible issues that pop up if one library is linked against apple gcc and the other against gcc43. *edit* sorry, send fail. From jameskyle at macports.org Tue Aug 25 19:02:32 2009 From: jameskyle at macports.org (James Kyle) Date: Tue, 25 Aug 2009 19:02:32 -0700 Subject: [56254] trunk/dports/python In-Reply-To: References: <20090825195153.77A57248D2E4@beta.macosforge.org> <9DA8A6E9-E1AC-493A-860D-24FDC7FFAC1D@macports.org> <4C725281-193E-4CE7-A8D3-FF18CA2BAA7D@macports.org> <10B8BB55-8710-4B87-A599-64389ECE2B32@macports.org> <4A948DFA.8040207@orcaware.com> Message-ID: <868CC50D-7E3A-4605-B19E-022CD6AF82E9@macports.org> I think I can clarify this shortly. There is no actual compile time linking done. When the variant packages are installed, the pymvpa port can use them by the mere fact that the module is present in python's path. You could safely remove any or all of the packages and pymvpa would gracfully fall back on default behavior. -james On Aug 25, 2009, at 6:42 PM, James Kyle wrote: > > On Aug 25, 2009, at 6:20 PM, Blair Zajac wrote: > >> James Kyle wrote: >>> On Aug 25, 2009, at 3:33 PM, Ryan Schmidt wrote: >>>> On Aug 25, 2009, at 17:08, James Kyle wrote: >>>> >>>>>> Default variants are difficult for the user to turn off. If you >>>>>> want these features enabled by default, why not delete the >>>>>> variants and just make the port always build them? >>>>>> >>>>>> If there really is value in allowing the user to disable these >>>>>> features, make them "no_" variants, e.g. "no_pywavelet", >>>>>> "no_libsvm", etc. >>>>> >>>>> Sounds good. >>>>> >>>>> >>>>>> Variants must do more than just add a dependency. They must >>>>>> also inform the software it is ok to use that dependency -- >>>>>> like you did in this variant: >>>>> >>>>> the package will use the above libraries if they are present, >>>>> but not if they are not. the variant allows the user to pull >>>>> them into the build process and so enable support. So the >>>>> informing is effectively done automatically as long as the >>>>> library is installed. >>>> >>>> This means the port would use those libraries even if the >>>> corresponding variant was not selected. This is not ok. The port >>>> must tell the software it is not ok to use those libraries unless >>>> the variant is selected. >>> This is not how the software works. I would have to rewrite it. >>> The rewrite would also break it's feature set. >>> It's a python module. Basically when you call a method 'foo' that, >>> say, performs a matrix convolution. If a c module exists for that >>> method it will use that. If it does not, it does the calculation >>> using its own pure python algorithm (usually much slower). >> >> You should have a way to disable the build from picking up that >> software if it's not requested then. >> >>> This isn't a bad thing. And I'm not sure how realistic it is to >>> want it to not do this. >> >> It is a bad thing. The problem is if you port uninstall one of the >> dependencies you picked up during the build, then MacPorts doesn't >> know about it. >> >> Blair >> > > > I'm confused here. Why would macports not know about a port uninstall? > > Let's take shogun as an example. If the shogun python library is > available, some of the methods in pymvpa will use them. If not, it > uses their own native code or (I think) displays an exception to the > user if it doesn't have a built-in alternative. > > The psuedo check might be: > > if sg module found in path: > use it > elsif built in exists: > use built in > else: > raise "functionality not enabled" > > The variant simply allows the user to declare "yes I want these > functions available, so please pull these libraries in so that > pymvpa can load them". There's nothing about it that slips files in > or would remove them outside of the ports system. > > By all means if there is some breakage that could occur here I am > eager to remedy it, but I don't see it. I wanted to give users a bit > of flexibility in choosing which libraries they wanted support for > in the pymvpa package. > > I suppose I could take an everything and the kitchen sink approach > and just include them as dependencies and either no variants or no_* > variants. But in practice this is really has no effect on the build > process itself. > > -james From blair at orcaware.com Wed Aug 26 10:15:52 2009 From: blair at orcaware.com (Blair Zajac) Date: Wed, 26 Aug 2009 10:15:52 -0700 Subject: [56254] trunk/dports/python In-Reply-To: <868CC50D-7E3A-4605-B19E-022CD6AF82E9@macports.org> References: <20090825195153.77A57248D2E4@beta.macosforge.org> <9DA8A6E9-E1AC-493A-860D-24FDC7FFAC1D@macports.org> <4C725281-193E-4CE7-A8D3-FF18CA2BAA7D@macports.org> <10B8BB55-8710-4B87-A599-64389ECE2B32@macports.org> <4A948DFA.8040207@orcaware.com> <868CC50D-7E3A-4605-B19E-022CD6AF82E9@macports.org> Message-ID: <4A956DC8.3080404@orcaware.com> James Kyle wrote: > I think I can clarify this shortly. > > There is no actual compile time linking done. When the variant packages > are installed, the pymvpa port can use them by the mere fact that the > module is present in python's path. > > You could safely remove any or all of the packages and pymvpa would > gracfully fall back on default behavior. Are the ports you pick up at run time only for use in this port, or do other ports and packages use them? Blair From ryandesign at macports.org Wed Aug 26 15:18:37 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 26 Aug 2009 17:18:37 -0500 Subject: [56356] trunk/dports/security/xmltooling/Portfile In-Reply-To: <20090826143159.6648F24AC7B6@beta.macosforge.org> References: <20090826143159.6648F24AC7B6@beta.macosforge.org> Message-ID: <60F522B0-310A-413F-AED8-BE2FD8B63CB9@macports.org> On Aug 26, 2009, at 09:31, scantor at macports.org wrote: > Revision: 56356 > http://trac.macports.org/changeset/56356 > Author: scantor at macports.org > Date: 2009-08-26 07:31:54 -0700 (Wed, 26 Aug 2009) > Log Message: > ----------- > Updated port to 1.2.2 You didn't update the checksums. The checksums in the port are correct for version 1.2.1. > Modified Paths: > -------------- > trunk/dports/security/xmltooling/Portfile > > Modified: trunk/dports/security/xmltooling/Portfile > =================================================================== > --- trunk/dports/security/xmltooling/Portfile 2009-08-26 13:59:28 > UTC (rev 56355) > +++ trunk/dports/security/xmltooling/Portfile 2009-08-26 14:31:54 > UTC (rev 56356) > @@ -4,7 +4,7 @@ > PortSystem 1.0 > > name xmltooling > -version 1.2.1 > +version 1.2.2 > categories security textproc xml shibboleth > #license Apachev2 > maintainers snc scantor From ryandesign at macports.org Thu Aug 27 17:00:54 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 27 Aug 2009 19:00:54 -0500 Subject: [56442] trunk/dports/sysutils/proctools/Portfile In-Reply-To: <20090827200819.C258A24D891D@beta.macosforge.org> References: <20090827200819.C258A24D891D@beta.macosforge.org> Message-ID: On Aug 27, 2009, at 15:08, toby at macports.org wrote: > Revision: 56442 > http://trac.macports.org/changeset/56442 > Author: toby at macports.org > Date: 2009-08-27 13:08:15 -0700 (Thu, 27 Aug 2009) > Log Message: > ----------- > These patches are not specific to darwin 9. This might break Tiger, > oh noes. Fixes #20843 FYI, still seems to build fine on Tiger. From jmr at macports.org Thu Aug 27 23:19:08 2009 From: jmr at macports.org (Joshua Root) Date: Fri, 28 Aug 2009 16:19:08 +1000 Subject: MacPorts 1.8.0 has been released Message-ID: <4A9776DC.3010707@macports.org> The MacPorts Project is happy to announce that the 1.8.0 version has now been released. It is available via the usual methods: - selfupdate if you already have it installed - package installers in DMGs for 10.4 [1], 10.5 [2], and 10.6 [3] (all universal builds, the first two i386/ppc and the latter i386/x86_64) - source tarballs, both .tar.bz2 [4] and .tar.gz [5] - subversion tag [6] The list of what's new in 1.8.0 is quite extensive (so I won't list it here), the details can be found in the NEWS [7] file or the somewhat more exhaustive ChangeLog [8]. A big thanks to the developers for their hard work with all of the various features and bug fixes in 1.8.0, and to everyone for your patience while waiting for this version. Detached PGP signatures for the DMGs and source tarballs have been made with my key, which is available on the keyservers and my MacPorts wiki page [9]. - Josh [1] - [2] - [3] - [4] - [5] - [6] - [7] - [8] - [9] - PS, my PGP key ID is B70C8867DCDBFF26, fingerprint B6D0 0D4B 209D 03FF 2BCE B77F B70C 8867 DCDB FF26 From ryandesign at macports.org Sun Aug 30 19:54:48 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 30 Aug 2009 21:54:48 -0500 Subject: [56618] trunk/dports/sysutils/duplicity/Portfile In-Reply-To: <20090831004644.B04DF25378FC@beta.macosforge.org> References: <20090831004644.B04DF25378FC@beta.macosforge.org> Message-ID: <737FFB5F-6291-4816-B074-AF07CDFD9049@macports.org> On Aug 30, 2009, at 19:46, singingwolfboy at macports.org wrote: > Revision: 56618 > http://trac.macports.org/changeset/56618 > Author: singingwolfboy at macports.org > Date: 2009-08-30 17:46:39 -0700 (Sun, 30 Aug 2009) > Log Message: > ----------- > added bugfix to make duplicity work with python26 framework Whenever you change the complement of files a port installs, remember to increase its revision so those who already had the port installed will be informed they need to upgrade. I increased the revision in r56621. > Modified: trunk/dports/sysutils/duplicity/Portfile > =================================================================== > --- trunk/dports/sysutils/duplicity/Portfile 2009-08-31 00:26:16 UTC > (rev 56617) > +++ trunk/dports/sysutils/duplicity/Portfile 2009-08-31 00:46:39 UTC > (rev 56618) > @@ -58,6 +58,11 @@ > categories sysutils > depends_lib-append port:librsync \ > port:gnupg > + # this is apparently required due to the way Python 2.6 > installs as > + # a framework > + post-destroot { > + ln -s ${python.prefix}/bin/duplicity ${destroot}${prefix}/ > bin/ > + } > } From ryandesign at macports.org Mon Aug 31 06:28:29 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 31 Aug 2009 08:28:29 -0500 Subject: Batch replace for livecheck.type and svn.revision In-Reply-To: <20090831112324.76FE3253EC2F@beta.macosforge.org> References: <20090831112324.76FE3253EC2F@beta.macosforge.org> Message-ID: On Aug 31, 2009, at 06:23, snc at macports.org wrote: > Revision: 56639 > http://trac.macports.org/changeset/56639 > Author: snc at macports.org > Date: 2009-08-31 04:23:23 -0700 (Mon, 31 Aug 2009) > Log Message: > ----------- > update version, ticket #20951. add modeline, update livecheck [snip] > -livecheck.check regex > +livecheck.type regex Rather than make everyone update this themselves, which will take forever, I propose I do a batch find and replace in all ports, changing livecheck.check to livecheck.type and svn.tag to svn.revision. This will make these ports incompatible with MacPorts 1.7.1 and earlier. Any objections? Any other batch changes I could be making now that MacPorts 1.8.0 is out? From devans at macports.org Mon Aug 31 07:55:13 2009 From: devans at macports.org (David Evans) Date: Mon, 31 Aug 2009 07:55:13 -0700 Subject: Batch replace for livecheck.type and svn.revision In-Reply-To: References: <20090831112324.76FE3253EC2F@beta.macosforge.org> Message-ID: <4A9BE451.3020700@macports.org> Ryan Schmidt wrote: > On Aug 31, 2009, at 06:23, snc at macports.org wrote: > >> Revision: 56639 >> http://trac.macports.org/changeset/56639 >> Author: snc at macports.org >> Date: 2009-08-31 04:23:23 -0700 (Mon, 31 Aug 2009) >> Log Message: >> ----------- >> update version, ticket #20951. add modeline, update livecheck > > [snip] > >> -livecheck.check regex >> +livecheck.type regex > > Rather than make everyone update this themselves, which will take > forever, I propose I do a batch find and replace in all ports, > changing livecheck.check to livecheck.type and svn.tag to > svn.revision. This will make these ports incompatible with MacPorts > 1.7.1 and earlier. Any objections? Any other batch changes I could be > making now that MacPorts 1.8.0 is out? > > +1 for the batch change but I suggest that a message be sent to macport-users and something appropriate added on the web site/wiki to explain the resultant error on 1.7.1 and the need to upgrade to 1.8.0 to try and head off the inevitable rash of bug reports that will arise. From jeremy at lavergne.gotdns.org Mon Aug 31 07:59:02 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Mon, 31 Aug 2009 10:59:02 -0400 Subject: Batch replace for livecheck.type and svn.revision In-Reply-To: <4A9BE451.3020700@macports.org> References: <20090831112324.76FE3253EC2F@beta.macosforge.org> <4A9BE451.3020700@macports.org> Message-ID: <209D610F-6FF2-4605-9E28-73732659E74B@lavergne.gotdns.org> Or we could just make 1.7.2 that includes changes for ONLY the portfile changes (livecheck.check, license) On Aug 31, 2009, at 10:55 AM, David Evans wrote: > +1 for the batch change but I suggest that a message be sent to > macport-users and something appropriate added on the web site/wiki > to explain the resultant error on 1.7.1 and the need to upgrade to > 1.8.0 > to try and head off the inevitable rash of bug reports that > will arise. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From devans at macports.org Mon Aug 31 08:10:10 2009 From: devans at macports.org (David Evans) Date: Mon, 31 Aug 2009 08:10:10 -0700 Subject: Batch replace for livecheck.type and svn.revision In-Reply-To: <209D610F-6FF2-4605-9E28-73732659E74B@lavergne.gotdns.org> References: <20090831112324.76FE3253EC2F@beta.macosforge.org> <4A9BE451.3020700@macports.org> <209D610F-6FF2-4605-9E28-73732659E74B@lavergne.gotdns.org> Message-ID: <4A9BE7D2.5080406@macports.org> Jeremy Lavergne wrote: > Or we could just make 1.7.2 that includes changes for ONLY the > portfile changes (livecheck.check, license) > > On Aug 31, 2009, at 10:55 AM, David Evans wrote: > >> +1 for the batch change but I suggest that a message be sent to >> macport-users and something appropriate added on the web site/wiki >> to explain the resultant error on 1.7.1 and the need to upgrade to 1.8.0 >> to try and head off the inevitable rash of bug reports that >> will arise. I don't think that helps as they still have to upgrade/install a new MacPorts version to eliminate the errors. Is there a way to determine the MacPorts version within the portfile? If so then you could do something like (pseudo code only) if {macports_version < 1.8.0} { livecheck.check regex } else { livecheck.type regex } From jeremy at lavergne.gotdns.org Mon Aug 31 08:11:53 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Mon, 31 Aug 2009 11:11:53 -0400 Subject: Batch replace for livecheck.type and svn.revision In-Reply-To: <4A9BE7D2.5080406@macports.org> References: <20090831112324.76FE3253EC2F@beta.macosforge.org> <4A9BE451.3020700@macports.org> <209D610F-6FF2-4605-9E28-73732659E74B@lavergne.gotdns.org> <4A9BE7D2.5080406@macports.org> Message-ID: <1A4BC916-A184-435D-B4CF-5ACECAAF92B0@lavergne.gotdns.org> > I don't think that helps as they still have to upgrade/install a > new MacPorts version to eliminate the errors. If they're not updating on that branch even then it's not our problem to cater to them. > Is there a way to determine the MacPorts version within the portfile? > > If so then you could do something like (pseudo code only) > > if {macports_version < 1.8.0} { > livecheck.check regex > } else { > livecheck.type regex > } Putting that in every single portfile seems very excessive. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2435 bytes Desc: not available URL: From devans at macports.org Mon Aug 31 08:20:17 2009 From: devans at macports.org (David Evans) Date: Mon, 31 Aug 2009 08:20:17 -0700 Subject: Batch replace for livecheck.type and svn.revision In-Reply-To: <1A4BC916-A184-435D-B4CF-5ACECAAF92B0@lavergne.gotdns.org> References: <20090831112324.76FE3253EC2F@beta.macosforge.org> <4A9BE451.3020700@macports.org> <209D610F-6FF2-4605-9E28-73732659E74B@lavergne.gotdns.org> <4A9BE7D2.5080406@macports.org> <1A4BC916-A184-435D-B4CF-5ACECAAF92B0@lavergne.gotdns.org> Message-ID: <4A9BEA31.4000104@macports.org> Jeremy Lavergne wrote: >> I don't think that helps as they still have to upgrade/install a new >> MacPorts version to eliminate the errors. > > If they're not updating on that branch even then it's not our problem > to cater to them. > >> Is there a way to determine the MacPorts version within the portfile? >> >> If so then you could do something like (pseudo code only) >> >> if {macports_version < 1.8.0} { >> livecheck.check regex >> } else { >> livecheck.type regex >> } > > Putting that in every single portfile seems very excessive. > Probably. So I'm back to make the change and promote everyone to update to 1.8.0 ASAP. From ryandesign at macports.org Mon Aug 31 09:08:58 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 31 Aug 2009 11:08:58 -0500 Subject: Batch replace for livecheck.type and svn.revision In-Reply-To: <4A9BEA31.4000104@macports.org> References: <20090831112324.76FE3253EC2F@beta.macosforge.org> <4A9BE451.3020700@macports.org> <209D610F-6FF2-4605-9E28-73732659E74B@lavergne.gotdns.org> <4A9BE7D2.5080406@macports.org> <1A4BC916-A184-435D-B4CF-5ACECAAF92B0@lavergne.gotdns.org> <4A9BEA31.4000104@macports.org> Message-ID: On Aug 31, 2009, at 10:20, David Evans wrote: > Jeremy Lavergne wrote: > >>> I don't think that helps as they still have to upgrade/install a >>> new >>> MacPorts version to eliminate the errors. >> >> If they're not updating on that branch even then it's not our problem >> to cater to them. >> >>> Is there a way to determine the MacPorts version within the >>> portfile? >>> >>> If so then you could do something like (pseudo code only) >>> >>> if {macports_version < 1.8.0} { >>> livecheck.check regex >>> } else { >>> livecheck.type regex >>> } >> >> Putting that in every single portfile seems very excessive. >> > > Probably. And there is no advantage to doing so, over keeping it at "livecheck.check regex", which we're not going to do, since the point of renaming this option was to make it more consistent with other similar options elsewhere in MacPorts. > So I'm back to make the change and promote everyone to update to > 1.8.0 ASAP. We always promote everyone to update to every release of MacPorts ASAP. We've always had a habit of updating portfiles very quickly after a MacPorts release to include features only that version of MacPorts understands (for better or for worse). MacPorts base is closely tied to the portfiles. If you want to keep using an old MacPorts base, you can do so, but must then also use old versions of portfiles, and we're probably not going to help you with it. From ryandesign at macports.org Mon Aug 31 09:12:10 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 31 Aug 2009 11:12:10 -0500 Subject: Post on Snow Leopard status? In-Reply-To: <4A942162.40901@macports.org> References: <4A942162.40901@macports.org> Message-ID: <8B18457A-3F06-4083-AFB7-1E9506288C84@macports.org> On Aug 25, 2009, at 12:37, Joshua Root wrote: > Finally, apart from the fact that you should always state your system > configuration when filing tickets, it doesn't matter that it's a new > OS > version. If something is broken and there isn't an existing ticket, > open > one. Exactly. While I appreciate the effort of testing ports on Snow Leopard, I don't know that it makes sense to have a wiki page with the goal of listing all ports' status with respect to Snow Leopard (or to 64-bit building or to universal building or to anything else). If something is broken, there should be an open ticket about it, not a note on a wiki page. From devans at macports.org Mon Aug 31 09:26:05 2009 From: devans at macports.org (David Evans) Date: Mon, 31 Aug 2009 09:26:05 -0700 Subject: Batch replace for livecheck.type and svn.revision In-Reply-To: References: <20090831112324.76FE3253EC2F@beta.macosforge.org> <4A9BE451.3020700@macports.org> <209D610F-6FF2-4605-9E28-73732659E74B@lavergne.gotdns.org> <4A9BE7D2.5080406@macports.org> <1A4BC916-A184-435D-B4CF-5ACECAAF92B0@lavergne.gotdns.org> <4A9BEA31.4000104@macports.org> Message-ID: <4A9BF99D.8010304@macports.org> >> >> Probably. > > And there is no advantage to doing so, over keeping it at > "livecheck.check regex", which we're not going to do, since the point > of renaming this option was to make it more consistent with other > similar options elsewhere in MacPorts. > >> So I'm back to make the change and promote everyone to update to >> 1.8.0 ASAP. > > We always promote everyone to update to every release of MacPorts > ASAP. We've always had a habit of updating portfiles very quickly > after a MacPorts release to include features only that version of > MacPorts understands (for better or for worse). MacPorts base is > closely tied to the portfiles. If you want to keep using an old > MacPorts base, you can do so, but must then also use old versions of > portfiles, and we're probably not going to help you with it. > > > What I would advocate would be to make an announcement that in Portfiles will be updated globally to use 1.8.0 key words that are incompatible with 1.7.1 and that users need to update to 1.8.0 before then to avoid problems. This is much more user friendly than just doing it and let them find out on their own (IMHO of course). Dave From devans at macports.org Mon Aug 31 09:29:27 2009 From: devans at macports.org (David Evans) Date: Mon, 31 Aug 2009 09:29:27 -0700 Subject: Batch replace for livecheck.type and svn.revision In-Reply-To: References: <20090831112324.76FE3253EC2F@beta.macosforge.org> <4A9BE451.3020700@macports.org> <209D610F-6FF2-4605-9E28-73732659E74B@lavergne.gotdns.org> <4A9BE7D2.5080406@macports.org> <1A4BC916-A184-435D-B4CF-5ACECAAF92B0@lavergne.gotdns.org> <4A9BEA31.4000104@macports.org> Message-ID: <4A9BFA67.4090804@macports.org> >> >> Probably. > > And there is no advantage to doing so, over keeping it at > "livecheck.check regex", which we're not going to do, since the point > of renaming this option was to make it more consistent with other > similar options elsewhere in MacPorts. > >> So I'm back to make the change and promote everyone to update to >> 1.8.0 ASAP. > > We always promote everyone to update to every release of MacPorts > ASAP. We've always had a habit of updating portfiles very quickly > after a MacPorts release to include features only that version of > MacPorts understands (for better or for worse). MacPorts base is > closely tied to the portfiles. If you want to keep using an old > MacPorts base, you can do so, but must then also use old versions of > portfiles, and we're probably not going to help you with it. > > > What I would advocate would be to make an announcement that in Portfiles will be updated globally to use 1.8.0 key words that are incompatible with 1.7.1 and that users need to update to 1.8.0 before then to avoid problems. This is much more user friendly than just doing it and let them find out on their own (IMHO of course). Dave From rowue at macports.org Mon Aug 31 09:47:30 2009 From: rowue at macports.org (=?ISO-8859-1?Q?Rolf_W=FCrdemann?=) Date: Mon, 31 Aug 2009 18:47:30 +0200 Subject: Ticket 20968 Message-ID: <0FBC40E5-61E7-4F19-82CC-A36150786728@macports.org> Hi everybody, Andrey Gruzdev from the gwyddion team has worked an patch (from the GTK+ OS X Group) to get the openGL extensions for gtk (gtkglext) working with quartz. Some of the examples doesn't work - at least "3D View" on gwyddion is working (10.4 and 10.5) however besides beeing not the maintainer of the port I'm also hesitat to commit this change because I don't know what else it can break. Any suggestions? Ticket is: 20968 (http://trac.macports.org/ticket/20968) Kind reg's, rowue -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: Signierter Teil der Nachricht URL: From ryandesign at macports.org Mon Aug 31 10:04:58 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 31 Aug 2009 12:04:58 -0500 Subject: Batch replace for livecheck.type and svn.revision In-Reply-To: <4A9BF99D.8010304@macports.org> References: <20090831112324.76FE3253EC2F@beta.macosforge.org> <4A9BE451.3020700@macports.org> <209D610F-6FF2-4605-9E28-73732659E74B@lavergne.gotdns.org> <4A9BE7D2.5080406@macports.org> <1A4BC916-A184-435D-B4CF-5ACECAAF92B0@lavergne.gotdns.org> <4A9BEA31.4000104@macports.org> <4A9BF99D.8010304@macports.org> Message-ID: On Aug 31, 2009, at 11:26, David Evans wrote: > What I would advocate would be to make an announcement that in your grace period> Portfiles will be updated globally to use 1.8.0 > key words > that are incompatible with 1.7.1 and that users need to update to > 1.8.0 > before then to avoid problems. > > This is much more user friendly than just doing it and let them find > out > on their own (IMHO of course). I agree a grace period would be most user-friendly. However people have already started updating ports with license keys and other MacPorts 1.7.1-incompatible changes. If we wanted there to be a grace period, we should have said so before 1.8.0 was released. Of course an announcement of the availability of MacPorts 1.8.0 was already made; users are expected, upon reading that, to upgrade. If users aren't on the mailing list, then they won't see an announcement of a grace period either. From jmr at macports.org Mon Aug 31 11:57:59 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 01 Sep 2009 04:57:59 +1000 Subject: Batch replace for livecheck.type and svn.revision In-Reply-To: References: <20090831112324.76FE3253EC2F@beta.macosforge.org> Message-ID: <4A9C1D37.7070207@macports.org> On 2009-8-31 23:28, Ryan Schmidt wrote: > Rather than make everyone update this themselves, which will take > forever, I propose I do a batch find and replace in all ports, changing > livecheck.check to livecheck.type and svn.tag to svn.revision. This will > make these ports incompatible with MacPorts 1.7.1 and earlier. Any > objections? Any other batch changes I could be making now that MacPorts > 1.8.0 is out? Personally I was going to wait a week or so after the 1.8.0 release before making 1.7.1-incompatible changes to my ports. - Josh From raimue at macports.org Mon Aug 31 17:09:53 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 01 Sep 2009 02:09:53 +0200 Subject: Batch replace for livecheck.type and svn.revision In-Reply-To: <4A9BE451.3020700@macports.org> References: <20090831112324.76FE3253EC2F@beta.macosforge.org> <4A9BE451.3020700@macports.org> Message-ID: <4A9C6651.7040807@macports.org> On 2009-08-31 16:55 , David Evans wrote: > Ryan Schmidt wrote: >> Rather than make everyone update this themselves, which will take >> forever, I propose I do a batch find and replace in all ports, >> changing livecheck.check to livecheck.type and svn.tag to >> svn.revision. This will make these ports incompatible with MacPorts >> 1.7.1 and earlier. Any objections? Any other batch changes I could be >> making now that MacPorts 1.8.0 is out? I am totally in favor of a batch change, but I would like to give users a few days of grace period for updating their MacPorts installations. Let's say a week is enough? That would be next friday. No other options have been deprecated, so these two would be the only candidates for the batch replace. > +1 for the batch change but I suggest that a message be sent to > macport-users and something appropriate added on the web site/wiki > to explain the resultant error on 1.7.1 and the need to upgrade to 1.8.0 > to try and head off the inevitable rash of bug reports that > will arise. That's exactly the reason why I want that delay of a few days :-) Other than that, we could of course also add a notice to ProblemHotlist (or FAQ) explaining why 1.7.1 does not understand 'livecheck.type'. Rainer