From ryandesign at macports.org Thu Oct 1 02:44:18 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 1 Oct 2009 04:44:18 -0500 Subject: [58577] trunk/dports/net/tuntaposx In-Reply-To: <20091001091839.332D628B5069@beta.macosforge.org> References: <20091001091839.332D628B5069@beta.macosforge.org> Message-ID: <307F478C-ED3A-4253-AE4D-4E4AF84F6056@macports.org> On Oct 1, 2009, at 04:18, raimue at macports.org wrote: > Revision: 58577 > http://trac.macports.org/changeset/58577 > Author: raimue at macports.org > Date: 2009-10-01 02:18:34 -0700 (Thu, 01 Oct 2009) > Log Message: > ----------- > net/tuntaposx: > Update to version 20090913, adapting patches. > For Snow Leopard, build both i386 and x86_64 as the kernel can be > run in 64-bit mode. > -# doesn't build 64-bit > -configure.universal_archs-delete x86_64 ppc64 > +configure { > + if {[variant_isset darwin_10] && ![variant_isset universal]} { > + # Kernel can be 32-bit or 64-bit, so build both > + configure.cflags-append -arch i386 -arch x86_64 > + } Is that different from what would happen if you selected the universal variant? Or would it make sense to just use "default_variants +universal" on Snow Leopard? From raimue at macports.org Thu Oct 1 02:52:40 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 01 Oct 2009 11:52:40 +0200 Subject: [58577] trunk/dports/net/tuntaposx In-Reply-To: <307F478C-ED3A-4253-AE4D-4E4AF84F6056@macports.org> References: <20091001091839.332D628B5069@beta.macosforge.org> <307F478C-ED3A-4253-AE4D-4E4AF84F6056@macports.org> Message-ID: <4AC47BE8.7020906@macports.org> On 2009-10-01 11:44 , Ryan Schmidt wrote: >> -# doesn't build 64-bit >> -configure.universal_archs-delete x86_64 ppc64 >> +configure { >> + if {[variant_isset darwin_10] && ![variant_isset universal]} { >> + # Kernel can be 32-bit or 64-bit, so build both >> + configure.cflags-append -arch i386 -arch x86_64 >> + } > > Is that different from what would happen if you selected the universal > variant? Or would it make sense to just use "default_variants > +universal" on Snow Leopard? A platform statement cannot modify default_variants as at the evaluation time the variants are already selected. I could have put that in a conditional block checking for os.major, but that would leave out any indication in the resulting installation that the build has been modified for SL. Rainer From ryandesign at macports.org Thu Oct 1 02:56:37 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 1 Oct 2009 04:56:37 -0500 Subject: [58577] trunk/dports/net/tuntaposx In-Reply-To: <4AC47BE8.7020906@macports.org> References: <20091001091839.332D628B5069@beta.macosforge.org> <307F478C-ED3A-4253-AE4D-4E4AF84F6056@macports.org> <4AC47BE8.7020906@macports.org> Message-ID: <169D7D24-5D3E-4720-AAFF-13F78435FECC@macports.org> On Oct 1, 2009, at 04:52, Rainer M?ller wrote: > On 2009-10-01 11:44 , Ryan Schmidt wrote: >>> -# doesn't build 64-bit >>> -configure.universal_archs-delete x86_64 ppc64 >>> +configure { >>> + if {[variant_isset darwin_10] && ![variant_isset universal]} { >>> + # Kernel can be 32-bit or 64-bit, so build both >>> + configure.cflags-append -arch i386 -arch x86_64 >>> + } >> >> Is that different from what would happen if you selected the >> universal >> variant? Or would it make sense to just use "default_variants >> +universal" on Snow Leopard? > > A platform statement cannot modify default_variants as at the > evaluation > time the variants are already selected. > > I could have put that in a conditional block checking for os.major, > but > that would leave out any indication in the resulting installation that > the build has been modified for SL. Whereas now, it looks like you're building a universal binary, but the universal variant is not selected. That's something I've typically filed bugs about in the past. Would you consider: platform darwin 10 {} if {[variant_isset darwin_10]} { default_variants +universal } Would that not have the same effect as what you do, but also indicate in the variants that this is a universal build? From raimue at macports.org Thu Oct 1 03:05:35 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 01 Oct 2009 12:05:35 +0200 Subject: [58577] trunk/dports/net/tuntaposx In-Reply-To: <169D7D24-5D3E-4720-AAFF-13F78435FECC@macports.org> References: <20091001091839.332D628B5069@beta.macosforge.org> <307F478C-ED3A-4253-AE4D-4E4AF84F6056@macports.org> <4AC47BE8.7020906@macports.org> <169D7D24-5D3E-4720-AAFF-13F78435FECC@macports.org> Message-ID: <4AC47EEF.4050101@macports.org> On 2009-10-01 11:56 , Ryan Schmidt wrote: > Would you consider: > > platform darwin 10 {} > if {[variant_isset darwin_10]} { > default_variants +universal > } > > Would that not have the same effect as what you do, but also indicate > in the variants that this is a universal build? But then that should also have configure.universal_archs i386 x86_64 because any other arch does not make sense. Rainer From ryandesign at macports.org Thu Oct 1 03:07:48 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 1 Oct 2009 05:07:48 -0500 Subject: [58577] trunk/dports/net/tuntaposx In-Reply-To: <4AC47EEF.4050101@macports.org> References: <20091001091839.332D628B5069@beta.macosforge.org> <307F478C-ED3A-4253-AE4D-4E4AF84F6056@macports.org> <4AC47BE8.7020906@macports.org> <169D7D24-5D3E-4720-AAFF-13F78435FECC@macports.org> <4AC47EEF.4050101@macports.org> Message-ID: On Oct 1, 2009, at 05:05, Rainer M?ller wrote: > On 2009-10-01 11:56 , Ryan Schmidt wrote: >> Would you consider: >> >> platform darwin 10 {} >> if {[variant_isset darwin_10]} { >> default_variants +universal >> } >> >> Would that not have the same effect as what you do, but also indicate >> in the variants that this is a universal build? > > But then that should also have > configure.universal_archs i386 x86_64 > because any other arch does not make sense. Ok, that would be fine. :) There's probably no reason why anyone on Snow Leopard would be changing the universal_archs but it doesn't hurt to make sure. From raimue at macports.org Thu Oct 1 03:18:35 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 01 Oct 2009 12:18:35 +0200 Subject: [58577] trunk/dports/net/tuntaposx In-Reply-To: References: <20091001091839.332D628B5069@beta.macosforge.org> <307F478C-ED3A-4253-AE4D-4E4AF84F6056@macports.org> <4AC47BE8.7020906@macports.org> <169D7D24-5D3E-4720-AAFF-13F78435FECC@macports.org> <4AC47EEF.4050101@macports.org> Message-ID: <4AC481FB.2020705@macports.org> On 2009-10-01 12:07 , Ryan Schmidt wrote: > > On Oct 1, 2009, at 05:05, Rainer M?ller wrote: > >> On 2009-10-01 11:56 , Ryan Schmidt wrote: >>> Would you consider: >>> >>> platform darwin 10 {} >>> if {[variant_isset darwin_10]} { >>> default_variants +universal >>> } >>> >>> Would that not have the same effect as what you do, but also indicate >>> in the variants that this is a universal build? >> >> But then that should also have >> configure.universal_archs i386 x86_64 >> because any other arch does not make sense. > > Ok, that would be fine. :) Committed changes in r58580. Rainer From ryandesign at macports.org Thu Oct 1 06:10:22 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 1 Oct 2009 08:10:22 -0500 Subject: php open_basedir bug In-Reply-To: References: <248388DF-F8AF-45FE-9980-42189EF89403@macports.org> Message-ID: On Sep 30, 2009, at 21:38, Scott Haneda wrote: > On Sep 30, 2009, at 7:34 PM, Ryan Schmidt wrote: > >> On Sep 30, 2009, at 19:39, Scott Haneda wrote: >> >>> Hi, I am hitting this one hard, just migrated a bunch of sites >>> from one serve to another: >>> http://bugs.php.net/bug.php?id=48880 >>> >>> Is there any way to get this patch into the php5 macports? It >>> exposes a good deal of directory data, and also makes random >>> failures occur on all sites. >> >> Thanks for bringing this issue to my attention. The patch looks >> simple enough. I'll see if I can add it to the current port. >> >> php 5.3.1 will of course include the fix. I thought 5.3.1 would >> have been out by now. Guess they're still testing things. > > Awesome. I was going to rebuild php, but if this is on the way, the > patch should very well make a rebuild happen anyway. Please let me > know if you need a tester, I need to get this fixed before too many > people notice :) php5 @5.3.0_3 contains this fix. I decided to just apply the upstream patch without testing it, since upstream has already put it in 5.3.1RC1 and the suhosin guys have already put it in their 5.3.0-0.9.8 patch too. From kjell.konis at epfl.ch Thu Oct 1 10:04:03 2009 From: kjell.konis at epfl.ch (Kjell Konis) Date: Thu, 1 Oct 2009 19:04:03 +0200 Subject: architecture wanted: ppc7400 Message-ID: Hello, I just upgraded to 1.8.1 and when it tried to upgrade freetype it borked. I am using a 1GHz pb G4 runnning OS X 10.4.11 (hey, it still points doesn't it!?) which I guess is now unsupported - still I thought this might be a bug someone is interested in. Cheers, Kjell ---> Computing dependencies for freetype. ---> Fetching freetype ---> Verifying checksum(s) for freetype ---> Checksumming freetype-2.3.9.tar.bz2 ---> Checksumming freetype-doc-2.3.9.tar.bz2 ---> Extracting freetype Error: You cannot install freetype for the architecture(s) ppc because /MacPorts/lib/libz.dylib does not contain the architecture ppc7400. Error: Target org.macports.extract returned: incompatible architectures in dependencies Warning: the following items did not execute (for freetype): org.macports.destroot org.macports.extract org.macports.patch org.macports.configure org.macports.build Error: Unable to upgrade port: 1 Error: Unable to execute port: upgrade pango failed pumkin:~/Documents/MacPorts admin$ lipo -info /MacPorts/lib/libz.dylib Non-fat file: /MacPorts/lib/libz.dylib is architecture: ppc From ryandesign at macports.org Thu Oct 1 13:24:21 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 1 Oct 2009 15:24:21 -0500 Subject: architecture wanted: ppc7400 In-Reply-To: References: Message-ID: <7F43248B-8803-4F00-BA8E-8206B43549F2@macports.org> On Oct 1, 2009, at 12:04, Kjell Konis wrote: > I just upgraded to 1.8.1 and when it tried to upgrade freetype it > borked. I am using a 1GHz pb G4 runnning OS X 10.4.11 (hey, it still > points doesn't it!?) which I guess is now unsupported My intention is to still support 10.4 and PowerPC. > still I thought this might be a bug someone is interested in. It is! > ---> Computing dependencies for freetype. > ---> Fetching freetype > ---> Verifying checksum(s) for freetype > ---> Checksumming freetype-2.3.9.tar.bz2 > ---> Checksumming freetype-doc-2.3.9.tar.bz2 > ---> Extracting freetype > Error: You cannot install freetype for the architecture(s) ppc > because /MacPorts/lib/libz.dylib does not contain the architecture > ppc7400. > Error: Target org.macports.extract returned: incompatible > architectures in dependencies > Warning: the following items did not execute (for freetype): > org.macports.destroot org.macports.extract org.macports.patch > org.macports.configure org.macports.build > Error: Unable to upgrade port: 1 It was my intention to have fixed this problem yesterday: http://trac.macports.org/ticket/21740 Please "sudo port selfupdate" and try again and let me know if you still see the problem. From brad at pixilla.com Thu Oct 1 14:04:08 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Thu, 1 Oct 2009 14:04:08 -0700 Subject: ImageMagic & Ghostscript Message-ID: <5FC77612-8242-448A-B327-6E96CD81EF1C@pixilla.com> I just spent an hour trying to figure out why I couldn't create a png thumbnail from a pdf using apache2/php5 exec(convert from to). Turns out convert uses gs "GhostScript" to work with pdf's and the path to gs was not found by convert. I found by editing the ImageMagick file "/opt/local/lib/ ImageMagick-6.5.5/config/delegates.xml" and changing: command=""gs" to command=""/opt/local/bin/gs" solved my problem. Maybe there is a better way. If not I'm wondering about the rest of the paths in the delgates file. If editing this file is the preferred way then maybe this should be done by MP at install. // Brad From talklists at newgeo.com Thu Oct 1 14:09:07 2009 From: talklists at newgeo.com (Scott Haneda) Date: Thu, 1 Oct 2009 14:09:07 -0700 Subject: php open_basedir bug In-Reply-To: References: <248388DF-F8AF-45FE-9980-42189EF89403@macports.org> Message-ID: <4C8A5DCC-2B9D-458D-9E89-ADB975CAE68E@newgeo.com> Something not right with upgrade: $sudo port upgrade php5 $sudo /opt/local/apache2/bin/apachectl graceful httpd: Syntax error on line 497 of /opt/local/apache2/conf/httpd.conf: Could not open configuration file /opt/local/apache2/conf/extras-conf/ mod_php.conf: No such file or directory $grep extras-conf /opt/local/apache2/conf/httpd.conf Include conf/extras-conf/mod_php.conf * Was my httpd.conf replaced in the upgrade? -rw-r--r-- 1 root admin 17239 Sep 30 15:09 httpd.conf -rw-r--r-- 1 root admin 16757 Sep 16 22:51 httpd.conf.bak The 16th is too old for that to be a .bk made today. Actually, httpd.conf is fine, I see some customizations I made in there. "extras-conf" is gone, which is where that mod_php.conf used to live. It is now in: /opt/local/apache2/conf/extra -rw-r--r-- 1 root admin 2845 Sep 16 22:11 httpd-autoindex.conf -rw-r--r-- 1 root admin 1718 Sep 16 22:11 httpd-dav.conf -rw-r--r-- 1 root admin 2344 Sep 16 22:11 httpd-default.conf -rw-r--r-- 1 root admin 1103 Sep 16 22:11 httpd-info.conf -rw-r--r-- 1 root admin 5078 Sep 16 22:11 httpd-languages.conf -rw-r--r-- 1 root admin 918 Sep 16 22:11 httpd-manual.conf -rw-r--r-- 1 root admin 3789 Sep 16 22:11 httpd-mpm.conf -rw-r--r-- 1 root admin 2186 Sep 16 22:11 httpd-multilang- errordoc.conf -rw-r--r-- 1 root admin 10283 Sep 16 22:11 httpd-ssl.conf -rw-r--r-- 1 root admin 806 Sep 16 22:11 httpd-userdir.conf -rw-r--r-- 1 root admin 398 Sep 18 17:40 httpd-vhosts.conf -rwxr-xr-x 2 root admin 129 Oct 1 13:52 mod_php.conf Why is the +x bit set on it? I think I know how to fix this, but I also think that this update process went awry. Suggestions on what happened? -- Scott * If you contact me off list replace talklists@ with scott@ * On Oct 1, 2009, at 6:10 AM, Ryan Schmidt wrote: > php5 @5.3.0_3 contains this fix. I decided to just apply the > upstream patch without testing it, since upstream has already put it > in 5.3.1RC1 and the suhosin guys have already put it in their > 5.3.0-0.9.8 patch too. From ryandesign at macports.org Thu Oct 1 14:33:21 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 1 Oct 2009 16:33:21 -0500 Subject: php open_basedir bug In-Reply-To: <4C8A5DCC-2B9D-458D-9E89-ADB975CAE68E@newgeo.com> References: <248388DF-F8AF-45FE-9980-42189EF89403@macports.org> <4C8A5DCC-2B9D-458D-9E89-ADB975CAE68E@newgeo.com> Message-ID: On Oct 1, 2009, at 16:09, Scott Haneda wrote: > Something not right with upgrade: > $sudo port upgrade php5 > > $sudo /opt/local/apache2/bin/apachectl graceful > httpd: Syntax error on line 497 of /opt/local/apache2/conf/ > httpd.conf: Could not open configuration file /opt/local/apache2/ > conf/extras-conf/mod_php.conf: No such file or directory > The config file moved from the directory "extras-conf" to the directory "extra". > $grep extras-conf /opt/local/apache2/conf/httpd.conf > Include conf/extras-conf/mod_php.conf > > * Was my httpd.conf replaced in the upgrade? > -rw-r--r-- 1 root admin 17239 Sep 30 15:09 httpd.conf > -rw-r--r-- 1 root admin 16757 Sep 16 22:51 httpd.conf.bak > > The 16th is too old for that to be a .bk made today. Actually, > httpd.conf is fine, I see some customizations I made in there. > > "extras-conf" is gone, which is where that mod_php.conf used to live. > > It is now in: > /opt/local/apache2/conf/extra > > -rw-r--r-- 1 root admin 2845 Sep 16 22:11 httpd-autoindex.conf > -rw-r--r-- 1 root admin 1718 Sep 16 22:11 httpd-dav.conf > -rw-r--r-- 1 root admin 2344 Sep 16 22:11 httpd-default.conf > -rw-r--r-- 1 root admin 1103 Sep 16 22:11 httpd-info.conf > -rw-r--r-- 1 root admin 5078 Sep 16 22:11 httpd-languages.conf > -rw-r--r-- 1 root admin 918 Sep 16 22:11 httpd-manual.conf > -rw-r--r-- 1 root admin 3789 Sep 16 22:11 httpd-mpm.conf > -rw-r--r-- 1 root admin 2186 Sep 16 22:11 httpd-multilang- > errordoc.conf > -rw-r--r-- 1 root admin 10283 Sep 16 22:11 httpd-ssl.conf > -rw-r--r-- 1 root admin 806 Sep 16 22:11 httpd-userdir.conf > -rw-r--r-- 1 root admin 398 Sep 18 17:40 httpd-vhosts.conf > -rwxr-xr-x 2 root admin 129 Oct 1 13:52 mod_php.conf > > Why is the +x bit set on it? It shouldn't cause any harm, but indeed is not intended. I'll look into it. > I think I know how to fix this, but I also think that this update > process went awry. Suggestions on what happened? From talklists at newgeo.com Thu Oct 1 14:44:19 2009 From: talklists at newgeo.com (Scott Haneda) Date: Thu, 1 Oct 2009 14:44:19 -0700 Subject: php open_basedir bug In-Reply-To: References: <248388DF-F8AF-45FE-9980-42189EF89403@macports.org> <4C8A5DCC-2B9D-458D-9E89-ADB975CAE68E@newgeo.com> Message-ID: <597E4DEF-93A8-429E-879E-F371A9247311@newgeo.com> On Oct 1, 2009, at 2:33 PM, Ryan Schmidt wrote: > On Oct 1, 2009, at 16:09, Scott Haneda wrote: > >> Something not right with upgrade: >> $sudo port upgrade php5 >> >> $sudo /opt/local/apache2/bin/apachectl graceful >> httpd: Syntax error on line 497 of /opt/local/apache2/conf/ >> httpd.conf: Could not open configuration file /opt/local/apache2/ >> conf/extras-conf/mod_php.conf: No such file or directory >> > > The config file moved from the directory "extras-conf" to the > directory "extra". Intentionally? Accidentally? A bug? What happened to the extras-conf directory? I know it used to be there as I ram my head into it every time I tab complete in that area. So the new location for mod_php.conf is to be in "extra"? Was there anything in there before? >> $grep extras-conf /opt/local/apache2/conf/httpd.conf >> Include conf/extras-conf/mod_php.conf >> >> * Was my httpd.conf replaced in the upgrade? >> -rw-r--r-- 1 root admin 17239 Sep 30 15:09 httpd.conf >> -rw-r--r-- 1 root admin 16757 Sep 16 22:51 httpd.conf.bak >> >> The 16th is too old for that to be a .bk made today. Actually, >> httpd.conf is fine, I see some customizations I made in there. >> >> "extras-conf" is gone, which is where that mod_php.conf used to live. >> >> It is now in: >> /opt/local/apache2/conf/extra >> >> [snip...] >> >> -rw-r--r-- 1 root admin 398 Sep 18 17:40 httpd-vhosts.conf >> -rwxr-xr-x 2 root admin 129 Oct 1 13:52 mod_php.conf >> >> Why is the +x bit set on it? > > It shouldn't cause any harm, but indeed is not intended. I'll look > into it. What are correct permissions? -- Scott * If you contact me off list replace talklists@ with scott@ * From talklists at newgeo.com Thu Oct 1 14:48:52 2009 From: talklists at newgeo.com (Scott Haneda) Date: Thu, 1 Oct 2009 14:48:52 -0700 Subject: php open_basedir bug In-Reply-To: References: <248388DF-F8AF-45FE-9980-42189EF89403@macports.org> Message-ID: <3FF48DBF-1AA4-4D0C-9B9D-9D9E90D3DEA6@newgeo.com> As an FYI, the new patched built you put out shows as core version 5.3.0, if you can tell me which value in phpInfo to look for to be sure I am running the patched version, I will confirm that is what I am running. I have refreshed a few sites that were being buggy with the open_basedir issue, and they seem to have been resoled, after I edited the path to mod_php.conf. Thank you for the patch, and I can conform one other person now has a successful working version. If you would like me to ping the ticket to report that it does work, I can do so. If you wold like me to note to the ticket the issue about the moving of mod_php.conf, I can also do so. I will look at the port file and see if I can see what is going on as well. Thank you again. -- Scott * If you contact me off list replace talklists@ with scott@ * On Oct 1, 2009, at 6:10 AM, Ryan Schmidt wrote: > php5 @5.3.0_3 contains this fix. I decided to just apply the > upstream patch without testing it, since upstream has already put it > in 5.3.1RC1 and the suhosin guys have already put it in their > 5.3.0-0.9.8 patch too. From ryandesign at macports.org Thu Oct 1 17:04:30 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 1 Oct 2009 19:04:30 -0500 Subject: php open_basedir bug In-Reply-To: <597E4DEF-93A8-429E-879E-F371A9247311@newgeo.com> References: <248388DF-F8AF-45FE-9980-42189EF89403@macports.org> <4C8A5DCC-2B9D-458D-9E89-ADB975CAE68E@newgeo.com> <597E4DEF-93A8-429E-879E-F371A9247311@newgeo.com> Message-ID: <09981E2E-A246-4434-8676-12FF475B7CE0@macports.org> On Oct 1, 2009, at 16:44, Scott Haneda wrote: > On Oct 1, 2009, at 2:33 PM, Ryan Schmidt wrote: > >> On Oct 1, 2009, at 16:09, Scott Haneda wrote: >> >>> Something not right with upgrade: >>> $sudo port upgrade php5 >>> >>> $sudo /opt/local/apache2/bin/apachectl graceful >>> httpd: Syntax error on line 497 of /opt/local/apache2/conf/ >>> httpd.conf: Could not open configuration file /opt/local/apache2/ >>> conf/extras-conf/mod_php.conf: No such file or directory >>> >> >> The config file moved from the directory "extras-conf" to the >> directory "extra". > > Intentionally? Accidentally? A bug? What happened to the extras- > conf directory? I know it used to be there as I ram my head into it > every time I tab complete in that area. > > So the new location for mod_php.conf is to be in "extra"? Was there > anything in there before? Apache used to distribute its extra conf files in a directory "extras- conf". To match this, php5 put its extra conf file there too. But a long time ago apache changed the name of that directory to "extra" and we never updated php5 to suit. Now I have. See #21217. http://trac.macports.org/ticket/21217 See r58589 for the full list of changes in the 5.3.0_3 update. http://trac.macports.org/changeset/58589 >>> $grep extras-conf /opt/local/apache2/conf/httpd.conf >>> Include conf/extras-conf/mod_php.conf >>> >>> * Was my httpd.conf replaced in the upgrade? >>> -rw-r--r-- 1 root admin 17239 Sep 30 15:09 httpd.conf >>> -rw-r--r-- 1 root admin 16757 Sep 16 22:51 httpd.conf.bak >>> >>> The 16th is too old for that to be a .bk made today. Actually, >>> httpd.conf is fine, I see some customizations I made in there. >>> >>> "extras-conf" is gone, which is where that mod_php.conf used to >>> live. >>> >>> It is now in: >>> /opt/local/apache2/conf/extra >>> >>> [snip...] >>> >>> -rw-r--r-- 1 root admin 398 Sep 18 17:40 httpd-vhosts.conf >>> -rwxr-xr-x 2 root admin 129 Oct 1 13:52 mod_php.conf >>> >>> Why is the +x bit set on it? >> >> It shouldn't cause any harm, but indeed is not intended. I'll look >> into it. > > What are correct permissions? 644 would be fine. Looks like the portfile explicitly installs the file with 755 permissions. I have no idea why. I'll change it to 644 with the next update. From ryandesign at macports.org Thu Oct 1 17:06:24 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 1 Oct 2009 19:06:24 -0500 Subject: php open_basedir bug In-Reply-To: <3FF48DBF-1AA4-4D0C-9B9D-9D9E90D3DEA6@newgeo.com> References: <248388DF-F8AF-45FE-9980-42189EF89403@macports.org> <3FF48DBF-1AA4-4D0C-9B9D-9D9E90D3DEA6@newgeo.com> Message-ID: <99632470-27EF-4A8B-B4BE-A5AB6EAC5154@macports.org> On Oct 1, 2009, at 16:48, Scott Haneda wrote: > As an FYI, the new patched built you put out shows as core version > 5.3.0, if you can tell me which value in phpInfo to look for to be > sure I am running the patched version, I will confirm that is what I > am running. There will be no particular indication in the phpinfo. I have removed DBA and ODBC support, though, coincidentally, so if you don't see DBA or ODBC support in your phpinfo then you're running the new version. > I have refreshed a few sites that were being buggy with the > open_basedir issue, and they seem to have been resoled, after I > edited the path to mod_php.conf. > > Thank you for the patch, and I can conform one other person now has > a successful working version. If you would like me to ping the > ticket to report that it does work, I can do so. Thanks for letting me know it worked. > If you wold like me to note to the ticket the issue about the moving > of mod_php.conf, I can also do so. I will look at the port file and > see if I can see what is going on as well. The conf file was moved intentionally, to resolve #21217. From ryandesign at macports.org Thu Oct 1 17:10:13 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 1 Oct 2009 19:10:13 -0500 Subject: ImageMagic & Ghostscript In-Reply-To: <5FC77612-8242-448A-B327-6E96CD81EF1C@pixilla.com> References: <5FC77612-8242-448A-B327-6E96CD81EF1C@pixilla.com> Message-ID: On Oct 1, 2009, at 16:04, Bradley Giesbrecht wrote: > I just spent an hour trying to figure out why I couldn't create a > png thumbnail from a pdf using apache2/php5 exec(convert from to). > > Turns out convert uses gs "GhostScript" to work with pdf's and the > path to gs was not found by convert. > > I found by editing the ImageMagick file "/opt/local/lib/ > ImageMagick-6.5.5/config/delegates.xml" and changing: > command=""gs" > to > command=""/opt/local/bin/gs" > > solved my problem. > > Maybe there is a better way. If not I'm wondering about the rest of > the paths in the delgates file. > > If editing this file is the preferred way then maybe this should be > done by MP at install. Do you not have /opt/local/bin in your $PATH? From nox at macports.org Thu Oct 1 23:22:57 2009 From: nox at macports.org (nox) Date: Fri, 2 Oct 2009 08:22:57 +0200 Subject: [58636] trunk/dports/x11/xorg-libX11/Portfile In-Reply-To: <20091002052030.B922D28C405A@beta.macosforge.org> References: <20091002052030.B922D28C405A@beta.macosforge.org> Message-ID: <552EDD5B-B0C4-4C26-8CDC-207A19497456@macports.org> You forgot to commit includes.patch Le 2 oct. 2009 ? 07:20, jeremyhu at macports.org a ?crit : > Revision > 58636 > Author > jeremyhu at macports.org > Date > 2009-10-01 22:20:26 -0700 (Thu, 01 Oct 2009) > Log Message > > xorg-libX11: Bump to 1.3 > Modified Paths > > ? trunk/dports/x11/xorg-libX11/Portfile > From jeremyhu at macports.org Thu Oct 1 23:44:28 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Thu, 1 Oct 2009 23:44:28 -0700 Subject: [58636] trunk/dports/x11/xorg-libX11/Portfile In-Reply-To: <552EDD5B-B0C4-4C26-8CDC-207A19497456@macports.org> References: <20091002052030.B922D28C405A@beta.macosforge.org> <552EDD5B-B0C4-4C26-8CDC-207A19497456@macports.org> Message-ID: <5407F756-6A06-4851-9CA1-09EB0BB71E4C@macports.org> >< On Oct 1, 2009, at 23:22, nox wrote: > You forgot to commit includes.patch > > Le 2 oct. 2009 ? 07:20, jeremyhu at macports.org a ?crit : > >> Revision >> 58636 >> Author >> jeremyhu at macports.org >> Date >> 2009-10-01 22:20:26 -0700 (Thu, 01 Oct 2009) >> Log Message >> >> xorg-libX11: Bump to 1.3 >> Modified Paths >> >> ? trunk/dports/x11/xorg-libX11/Portfile >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3333 bytes Desc: not available URL: From kjell.konis at epfl.ch Fri Oct 2 01:21:13 2009 From: kjell.konis at epfl.ch (Konis Kjell) Date: Fri, 2 Oct 2009 10:21:13 +0200 Subject: architecture wanted: ppc7400 In-Reply-To: <7F43248B-8803-4F00-BA8E-8206B43549F2@macports.org> References: <7F43248B-8803-4F00-BA8E-8206B43549F2@macports.org> Message-ID: <6EFE6A2E-79C0-46ED-A731-382A5CF0FBED@epfl.ch> Thanks, works fine now. Kjell On 1 oct. 2009, at 22:24, Ryan Schmidt wrote: > > On Oct 1, 2009, at 12:04, Kjell Konis wrote: > >> I just upgraded to 1.8.1 and when it tried to upgrade freetype it >> borked. I am using a 1GHz pb G4 runnning OS X 10.4.11 (hey, it still >> points doesn't it!?) which I guess is now unsupported > > My intention is to still support 10.4 and PowerPC. > > >> still I thought this might be a bug someone is interested in. > > It is! > >> ---> Computing dependencies for freetype. >> ---> Fetching freetype >> ---> Verifying checksum(s) for freetype >> ---> Checksumming freetype-2.3.9.tar.bz2 >> ---> Checksumming freetype-doc-2.3.9.tar.bz2 >> ---> Extracting freetype >> Error: You cannot install freetype for the architecture(s) ppc >> because /MacPorts/lib/libz.dylib does not contain the architecture >> ppc7400. >> Error: Target org.macports.extract returned: incompatible >> architectures in dependencies >> Warning: the following items did not execute (for freetype): >> org.macports.destroot org.macports.extract org.macports.patch >> org.macports.configure org.macports.build >> Error: Unable to upgrade port: 1 > > > It was my intention to have fixed this problem yesterday: > > http://trac.macports.org/ticket/21740 > > Please "sudo port selfupdate" and try again and let me know if you > still see the problem. > > > From raimue at macports.org Fri Oct 2 03:11:01 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 02 Oct 2009 12:11:01 +0200 Subject: architecture wanted: ppc7400 In-Reply-To: <7F43248B-8803-4F00-BA8E-8206B43549F2@macports.org> References: <7F43248B-8803-4F00-BA8E-8206B43549F2@macports.org> Message-ID: <4AC5D1B5.9010108@macports.org> On 2009-10-01 22:24 , Ryan Schmidt wrote: > > On Oct 1, 2009, at 12:04, Kjell Konis wrote: > >> I just upgraded to 1.8.1 and when it tried to upgrade freetype it >> borked. I am using a 1GHz pb G4 runnning OS X 10.4.11 (hey, it still >> points doesn't it!?) which I guess is now unsupported > > My intention is to still support 10.4 and PowerPC. In my opinion we should drop that now. If someone is still using Tiger on a PowerPC based Mac then they should get Leopard now because it is the last OS version they will ever get. And if someone is still using Tiger on Intel, Snow Leopard is cheap enough to make a argument because of the price more or less invalid. Why else wouldn't you want to upgrade? We should stick to our support plan which is that the two latest major Mac OS X releases are supported, namely Leopard and Snow Leopard. Rainer From jmr at macports.org Fri Oct 2 03:28:48 2009 From: jmr at macports.org (Joshua Root) Date: Fri, 02 Oct 2009 20:28:48 +1000 Subject: architecture wanted: ppc7400 In-Reply-To: <4AC5D1B5.9010108@macports.org> References: <7F43248B-8803-4F00-BA8E-8206B43549F2@macports.org> <4AC5D1B5.9010108@macports.org> Message-ID: <4AC5D5E0.9060608@macports.org> On 2009-10-2 20:11, Rainer M?ller wrote: > On 2009-10-01 22:24 , Ryan Schmidt wrote: >> My intention is to still support 10.4 and PowerPC. > > In my opinion we should drop that now. If someone is still using Tiger > on a PowerPC based Mac then they should get Leopard now because it is > the last OS version they will ever get. And if someone is still using > Tiger on Intel, Snow Leopard is cheap enough to make a argument because > of the price more or less invalid. Why else wouldn't you want to upgrade? > > We should stick to our support plan which is that the two latest major > Mac OS X releases are supported, namely Leopard and Snow Leopard. All the policy can really do is set expectations. If Ryan wants to exceed those expectations, that's his choice, and doesn't mean anyone else has to. - Josh From afb at macports.org Fri Oct 2 05:12:47 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Fri, 2 Oct 2009 14:12:47 +0200 Subject: architecture wanted: ppc7400 In-Reply-To: <4AC5D1B5.9010108@macports.org> References: <7F43248B-8803-4F00-BA8E-8206B43549F2@macports.org> <4AC5D1B5.9010108@macports.org> Message-ID: <81B450E7-FEC3-4201-A059-68E2E9F14121@macports.org> Rainer M?ller wrote: > On 2009-10-01 22:24 , Ryan Schmidt wrote: ... >> My intention is to still support 10.4 and PowerPC. > > In my opinion we should drop that now. If someone is still using Tiger > on a PowerPC based Mac then they should get Leopard now because it is > the last OS version they will ever get. And if someone is still using > Tiger on Intel, Snow Leopard is cheap enough to make a argument > because > of the price more or less invalid. Why else wouldn't you want to > upgrade? I'm running Tiger on my 64-bit PowerPC and Leopard on my 32-bit Intel, mostly since I couldn't see any reason to upgrade either a second time. Seemed the like biggest reason to upgrade to Snow Leopard was to get better support for your newer 64-bit Intel or newer graphics card... > We should stick to our support plan which is that the two latest major > Mac OS X releases are supported, namely Leopard and Snow Leopard. I thought the "support plan" (if there is such a thing as support) said "Snow Leopard, Leopard and Tiger as a legacy platform"... And then kill Tiger support for next major release, just like it said "Leopard, Tiger and Panther as a legacy platform" earlier ? --anders From deven.patel2 at gmail.com Fri Oct 2 05:43:44 2009 From: deven.patel2 at gmail.com (patel deven) Date: Fri, 2 Oct 2009 18:13:44 +0530 Subject: opencv -python In-Reply-To: <9d94cd490910020533o77bc29a6rf8e4cb0b87aa21d3@mail.gmail.com> References: <9d94cd490910020533o77bc29a6rf8e4cb0b87aa21d3@mail.gmail.com> Message-ID: <9d94cd490910020543v17ece5ccp6391796a333a6d6d@mail.gmail.com> i have just installed Opencv 2.0. but the python bindings are not working. this is what it looks like when i try to import modules Python 2.6 (r26:66714, Jun 8 2009, 16:07:29) [GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import cv Traceback (most recent call last): File "", line 1, in ImportError: No module named cv >>> from opencv import cv Traceback (most recent call last): File "", line 1, in ImportError: No module named opencv i checked the cd /usr/local/lib64/python2.6/site-packages/ directory and the "opencv" folder is existing there. Then why am i unable to import the modules?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnick at macports.org Fri Oct 2 06:26:49 2009 From: mnick at macports.org (Maximilian Nickel) Date: Fri, 2 Oct 2009 15:26:49 +0200 Subject: opencv -python In-Reply-To: <9d94cd490910020543v17ece5ccp6391796a333a6d6d@mail.gmail.com> References: <9d94cd490910020533o77bc29a6rf8e4cb0b87aa21d3@mail.gmail.com> <9d94cd490910020543v17ece5ccp6391796a333a6d6d@mail.gmail.com> Message-ID: <7bad5d350910020626r121168a1i855f280a4a0a4545@mail.gmail.com> Hi, On Fri, Oct 2, 2009 at 2:43 PM, patel deven wrote: > i have just installed Opencv 2.0. but the python bindings are not working. > this is what it looks like when i try to import modules Given that macports only provdies opencv 1.0 i guess you have installed opencv 2.0 manually? > i checked the ?cd /usr/local/lib64/python2.6/ > site-packages/ directory and > the "opencv" folder is existing there. ?Then why am i unable to import the > modules?? The reason you can't import it into python is that you have installed it in the wrong path. MacPorts never installs into /usr/local, furthermore Python 2.6 is built as a framework and therefore won't pick up modules from ${prefix}/lib/python2.6/site-packages, even if /usr/local would be a valid prefix. You have to tell the install script of opencv to install the python bindings in ${prefix}/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages From dluke at geeklair.net Fri Oct 2 08:14:55 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Fri, 2 Oct 2009 11:14:55 -0400 Subject: architecture wanted: ppc7400 In-Reply-To: <81B450E7-FEC3-4201-A059-68E2E9F14121@macports.org> References: <7F43248B-8803-4F00-BA8E-8206B43549F2@macports.org> <4AC5D1B5.9010108@macports.org> <81B450E7-FEC3-4201-A059-68E2E9F14121@macports.org> Message-ID: <65AFBEAD-27AC-4F5C-9126-C71CD3BA6E90@geeklair.net> On Oct 2, 2009, at 8:12 AM, Anders F Bj?rklund wrote: > I thought the "support plan" (if there is such a thing as support) > said "Snow Leopard, Leopard and Tiger as a legacy platform"... We had agreed a long while back to support the current and previous major release. > And then kill Tiger support for next major release, just like it > said "Leopard, Tiger and Panther as a legacy platform" earlier ? Both with the release of 10.5 and 10.6, Ryan has expressed desire to keep support for the older release. As a general rule, we don't discourage anyone from making things work on older releases, but eventually base/ changes tend to make things not work (or not work easily). Personally, I don't go out of my way to support anything other than the current/previous major releases, but am willing to incorporate fixes from other people into ports I maintain for older releases. -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ From afb at macports.org Fri Oct 2 09:10:31 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Fri, 2 Oct 2009 18:10:31 +0200 Subject: architecture wanted: ppc7400 In-Reply-To: <65AFBEAD-27AC-4F5C-9126-C71CD3BA6E90@geeklair.net> References: <7F43248B-8803-4F00-BA8E-8206B43549F2@macports.org> <4AC5D1B5.9010108@macports.org> <81B450E7-FEC3-4201-A059-68E2E9F14121@macports.org> <65AFBEAD-27AC-4F5C-9126-C71CD3BA6E90@geeklair.net> Message-ID: <751BDC9F-63E5-4723-974C-FF1DEC828008@macports.org> Daniel J. Luke wrote: >> I thought the "support plan" (if there is such a thing as support) >> said "Snow Leopard, Leopard and Tiger as a legacy platform"... > > We had agreed a long while back to support the current and previous > major release. No problem, it might be just the pages on the website that are out of sync... Specifically http://www.macports.org/install.php >> And then kill Tiger support for next major release, just like it >> said "Leopard, Tiger and Panther as a legacy platform" earlier ? > > Both with the release of 10.5 and 10.6, Ryan has expressed desire > to keep support for the older release. As a general rule, we don't > discourage anyone from making things work on older releases, but > eventually base/ changes tend to make things not work (or not work > easily). Okay, sounds pretty much like the general rule for Other Platforms then. "You can stay, if you promise to not get in the way". > Personally, I don't go out of my way to support anything other than > the current/previous major releases, but am willing to incorporate > fixes from other people into ports I maintain for older releases. Personally, I don't think I'll be upgrading to the current major release... At least not unless Santa has some nice surprises. :-) --anders From mark at mirell.org Fri Oct 2 18:54:21 2009 From: mark at mirell.org (Mark A. Miller) Date: Fri, 2 Oct 2009 20:54:21 -0500 Subject: Remove +with_default_names and use a specific path for unprefixed binaries In-Reply-To: References: <31014a580909171759i30948038pa4374f6dc4487669@mail.gmail.com> <31014a580909180758kc4b068brb6d2e61c7283732d@mail.gmail.com> <17D3ADD6-F154-4ED4-9417-0DFBA3A15A2C@macports.org> <31014a580909182020g656aa49xa1aeff6cf3bb83c5@mail.gmail.com> <6D6BA45C-221A-4D95-89D1-27F90058AB6E@macports.org> <31014a580909191306g46899b0dx2f5469fce2dfba11@mail.gmail.com> <4E9F2734-9363-4192-AB3A-45DC49E2AE55@macports.org> <4AB61C0E.4010603@macports.org> Message-ID: <31014a580910021854s9d0686cq2a885d78193379bd@mail.gmail.com> On Sun, Sep 20, 2009 at 8:07 AM, Ryan Schmidt wrote: > > We could provide such a script, but if we set MANPATH in it, it would have > the disadvantage of making MANPATH nonempty again and thus disabling the > automatic manpage finding feature which the user may have been relying on > for other manpages. The discussion was between having a directory under > ${prefix} which would behave like a prefix for GNU software -- would contain > bin and share directories -- or making GNU subdirectories within both the > ${prefix}/bin and ${prefix}/share directories; the automatic manpage finding > feature wouldn't be able to find the manpages given that layout. > Reviving this discussion again since it died out. From my viewpoint, as one of the types of people that already do something like this on their own system, but would like MacPorts to automagically handle it, man pages are not a big deal. I just want the unprefixed binaries for scripts and the like. -- Mark A. Miller mark at mirell.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jameskyle at macports.org Fri Oct 2 20:06:31 2009 From: jameskyle at macports.org (James Kyle) Date: Fri, 2 Oct 2009 20:06:31 -0700 Subject: py26-numpy, py26-scipy, and macports atlas/lapack/blas Message-ID: <680FC860-70E1-4E5F-8F6A-D4EBF4E25FA5@macports.org> I've been working on the numpy and scipy ports for python26. I've succeeded at accomplishing the following for both: - default build against gcc43 toolchain - default build links against macports atlas/lapack/blas libraries instead of the apple ones - gcc43 disabled with no_gcc43 variant -- macports atlas disabled with no_atlas variant (falls back to system atlas/lapack) I think these changes bring the numpy/scipy ports into line with the "macports way" of using ports as dependencies whenever possible. It also is in line with the request in ticket #20103 to settle on a common compiler for scientific oriented ports to reduce possible cross linking issues. A practical example of problems caused by cross linking is found in ticket #20491, where ipython segfaults when an exception is thrown by a module linked against macports atlas. Since this is a pretty significant change in default behavior, I thought I'd drop a line to the list for discussion. Both numpy and scipy tests pass 100% after this change. > >>> import numpy > >>> numpy.test() > > >>> import scipy > >>> scipy.test() > Cheers, -james -------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile Type: application/octet-stream Size: 2905 bytes Desc: not available URL: -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile Type: application/octet-stream Size: 4005 bytes Desc: not available URL: From howarth at bromo.med.uc.edu Fri Oct 2 22:01:21 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 3 Oct 2009 01:01:21 -0400 Subject: py26-numpy, py26-scipy, and macports atlas/lapack/blas In-Reply-To: <680FC860-70E1-4E5F-8F6A-D4EBF4E25FA5@macports.org> References: <680FC860-70E1-4E5F-8F6A-D4EBF4E25FA5@macports.org> Message-ID: <20091003050121.GA14320@bromo.med.uc.edu> On Fri, Oct 02, 2009 at 08:06:31PM -0700, James Kyle wrote: > I've been working on the numpy and scipy ports for python26. I've > succeeded at accomplishing the following for both: > > - default build against gcc43 toolchain > - default build links against macports atlas/lapack/blas libraries > instead of the apple ones > - gcc43 disabled with no_gcc43 variant > -- macports atlas disabled with no_atlas variant (falls back to system > atlas/lapack) > > > I think these changes bring the numpy/scipy ports into line with the > "macports way" of using ports as dependencies whenever possible. It also > is in line with the request in ticket #20103 to settle on a common > compiler for scientific oriented ports to reduce possible cross linking > issues. > > A practical example of problems caused by cross linking is found in > ticket #20491, where ipython segfaults when an exception is thrown by a > module linked against macports atlas. > > Since this is a pretty significant change in default behavior, I thought > I'd drop a line to the list for discussion. > > Both numpy and scipy tests pass 100% after this change. > >> >>> import numpy >> >>> numpy.test() >> > >> >>> import scipy >> >>> scipy.test() >> > > Cheers, > > -james > James, You'll want these packages to build against the gcc44 package rather than the gcc43 package. Only gcc 4.4.x and later builds on Snow Leopard. Jack > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From jeremyhu at macports.org Fri Oct 2 23:52:56 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Fri, 2 Oct 2009 23:52:56 -0700 Subject: py26-numpy, py26-scipy, and macports atlas/lapack/blas In-Reply-To: <20091003050121.GA14320@bromo.med.uc.edu> References: <680FC860-70E1-4E5F-8F6A-D4EBF4E25FA5@macports.org> <20091003050121.GA14320@bromo.med.uc.edu> Message-ID: <13A54C62-5C1A-4CBB-BAB8-34DDFC4283A2@macports.org> On Oct 2, 2009, at 22:01, Jack Howarth wrote: > James, > You'll want these packages to build against the gcc44 package > rather than the gcc43 package. Only gcc 4.4.x and later builds > on Snow Leopard. > Jack Uhm... I'm on SL, and I just installed gcc43. What problem do you have installing gcc43? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3333 bytes Desc: not available URL: From ryandesign at macports.org Sat Oct 3 00:35:58 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 3 Oct 2009 02:35:58 -0500 Subject: py26-numpy, py26-scipy, and macports atlas/lapack/blas In-Reply-To: <20091003050121.GA14320@bromo.med.uc.edu> References: <680FC860-70E1-4E5F-8F6A-D4EBF4E25FA5@macports.org> <20091003050121.GA14320@bromo.med.uc.edu> Message-ID: <40E2DB0F-329E-46CC-8B21-787B361A838C@macports.org> On Oct 3, 2009, at 00:01, Jack Howarth wrote: > You'll want these packages to build against the gcc44 package > rather than the gcc43 package. Only gcc 4.4.x and later builds > on Snow Leopard. gcc43 builds fine for me on Snow Leopard as well, but I too would recommend choosing gcc44, since it is the latest stable version available at this time. From ram at macports.org Sat Oct 3 09:05:28 2009 From: ram at macports.org (Adam Mercer) Date: Sat, 3 Oct 2009 11:05:28 -0500 Subject: py26-numpy, py26-scipy, and macports atlas/lapack/blas In-Reply-To: <680FC860-70E1-4E5F-8F6A-D4EBF4E25FA5@macports.org> References: <680FC860-70E1-4E5F-8F6A-D4EBF4E25FA5@macports.org> Message-ID: <799406d60910030905r29b8753bg5b4028e619460722@mail.gmail.com> On Fri, Oct 2, 2009 at 22:06, James Kyle wrote: > Both numpy and scipy tests pass 100% after this change. > >> >>> import numpy >> >>> numpy.test() >> > >> >>> import scipy >> >>> scipy.test() >> What platform is this on? Leopard, SL? I really like this idea, but the main thing that concerns me is that any port that depends on numpy will now also depend on gcc43, or gcc44 (which seems like a better idea), this is a big change as gcc takes a _long_ time to build. Cheers Adam From howarth at bromo.med.uc.edu Sat Oct 3 09:17:38 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 3 Oct 2009 12:17:38 -0400 Subject: py26-numpy, py26-scipy, and macports atlas/lapack/blas In-Reply-To: <799406d60910030905r29b8753bg5b4028e619460722@mail.gmail.com> References: <680FC860-70E1-4E5F-8F6A-D4EBF4E25FA5@macports.org> <799406d60910030905r29b8753bg5b4028e619460722@mail.gmail.com> Message-ID: <20091003161738.GA18944@bromo.med.uc.edu> On Sat, Oct 03, 2009 at 11:05:28AM -0500, Adam Mercer wrote: > On Fri, Oct 2, 2009 at 22:06, James Kyle wrote: > > > Both numpy and scipy tests pass 100% after this change. > > > >> >>> import numpy > >> >>> numpy.test() > >> > > > >> >>> import scipy > >> >>> scipy.test() > >> > > What platform is this on? Leopard, SL? > > I really like this idea, but the main thing that concerns me is that > any port that depends on numpy will now also depend on gcc43, or gcc44 > (which seems like a better idea), this is a big change as gcc takes a > _long_ time to build. If the MacPorts gcc44 maintainers would adopt the gcc44-disable-libjava.diff patch that is used in the fink gcc4x builds... http://trac.macports.org/attachment/ticket/21341/gcc44-disable-libjava.diff and pass --disable-libjava-multilib to configure, the time required for the gcc44 package to build would be significantly reduced. It is pretty absurd to waste time building the libjava multilib since no one will ever use it. This is why RedHat came up with that patch for their rpms. Jack > > Cheers > > Adam > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From mnick at macports.org Sat Oct 3 09:41:23 2009 From: mnick at macports.org (Maximilian Nickel) Date: Sat, 3 Oct 2009 18:41:23 +0200 Subject: py26-numpy, py26-scipy, and macports atlas/lapack/blas In-Reply-To: <799406d60910030905r29b8753bg5b4028e619460722@mail.gmail.com> References: <680FC860-70E1-4E5F-8F6A-D4EBF4E25FA5@macports.org> <799406d60910030905r29b8753bg5b4028e619460722@mail.gmail.com> Message-ID: <7bad5d350910030941h503d223ag1db7e83b2a229296@mail.gmail.com> On Sat, Oct 3, 2009 at 6:05 PM, Adam Mercer wrote: > I really like this idea, but the main thing that concerns me is that > any port that depends on numpy will now also depend on gcc43, or gcc44 > (which seems like a better idea), this is a big change as gcc takes a > _long_ time to build. ATLAS is no small compilation either. But i don't see a problem here since James' Portfile provides variants for gcc and altas, so one could turn these dependencies of. However i'd like to propose renaming the no_* variants into gcc43 and atlas and making them default variants. This way additional variants like gcc44 could easily be added Cheers Max From roederja at ethz.ch Sat Oct 3 09:58:07 2009 From: roederja at ethz.ch (=?UTF-8?B?SmFubiBSw7bCmmRlcg==?=) Date: Sat, 03 Oct 2009 18:58:07 +0200 Subject: Download sources from servers that don't respond to ping Message-ID: I noticed, that at the moment servers which do not respond to Pings are not considered as sources. This sounds reasonable, but unfortunately there are some servers out there that work just fine even though they do not respond to Ping messages. So I request that sources with a ping value of 10000 are still considered. Jann From dluke at geeklair.net Sat Oct 3 10:00:01 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Sat, 3 Oct 2009 13:00:01 -0400 Subject: py26-numpy, py26-scipy, and macports atlas/lapack/blas In-Reply-To: <7bad5d350910030941h503d223ag1db7e83b2a229296@mail.gmail.com> References: <680FC860-70E1-4E5F-8F6A-D4EBF4E25FA5@macports.org> <799406d60910030905r29b8753bg5b4028e619460722@mail.gmail.com> <7bad5d350910030941h503d223ag1db7e83b2a229296@mail.gmail.com> Message-ID: <4D11F3AF-72CB-4704-A7AA-A9E94F3A839F@geeklair.net> On Oct 3, 2009, at 12:41 PM, Maximilian Nickel wrote: > However i'd like > to propose renaming the no_* variants into gcc43 and atlas and making > them default variants. > This way additional variants like gcc44 could easily be added I believe negative variants are still not stored in the registry, so default variants can cause issues for people when upgrading a port (since they'll be automatically selected again). -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ From dluke at geeklair.net Sat Oct 3 10:02:27 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Sat, 3 Oct 2009 13:02:27 -0400 Subject: Download sources from servers that don't respond to ping In-Reply-To: References: Message-ID: <4B7FDBAC-6B25-443B-B01E-602596CF4D5A@geeklair.net> On Oct 3, 2009, at 12:58 PM, Jann R??der wrote: > I noticed, that at the moment servers which do not respond to Pings > are > not considered as sources. This sounds reasonable, but unfortunately > there are some servers out there that work just fine even though > they do > not respond to Ping messages. So I request that sources with a ping > value of 10000 are still considered. Servers which block all ICMP are broken (usually when ICMP echo is blocked, all ICMP is blocked) as they break path mtu discovery. -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ From roederja at ethz.ch Sat Oct 3 10:04:03 2009 From: roederja at ethz.ch (=?UTF-8?B?SmFubiBSw7bCmmRlcg==?=) Date: Sat, 03 Oct 2009 19:04:03 +0200 Subject: Download sources from servers that don't respond to ping In-Reply-To: <4B7FDBAC-6B25-443B-B01E-602596CF4D5A@geeklair.net> References: <4B7FDBAC-6B25-443B-B01E-602596CF4D5A@geeklair.net> Message-ID: Yes, but I still want to download stuff from them. Daniel J. Luke schrieb: > On Oct 3, 2009, at 12:58 PM, Jann R??der wrote: >> I noticed, that at the moment servers which do not respond to Pings are >> not considered as sources. This sounds reasonable, but unfortunately >> there are some servers out there that work just fine even though they do >> not respond to Ping messages. So I request that sources with a ping >> value of 10000 are still considered. > > Servers which block all ICMP are broken (usually when ICMP echo is > blocked, all ICMP is blocked) as they break path mtu discovery. > > -- > Daniel J. Luke > +========================================================+ > | *---------------- dluke at geeklair.net > ----------------* | > | *-------------- http://www.geeklair.net -------------* | > +========================================================+ > | Opinions expressed are mine and do not necessarily | > | reflect the opinions of my employer. | > +========================================================+ > > > From howarth at bromo.med.uc.edu Sat Oct 3 10:10:35 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 3 Oct 2009 13:10:35 -0400 Subject: [MacPorts] #21341: fixed packaging for gcc44 In-Reply-To: <069.69a4c33b1e18bab17af54f6387f7f830@macports.org> References: <060.9eecad56c9af798de289a04e96e16903@macports.org> <069.69a4c33b1e18bab17af54f6387f7f830@macports.org> Message-ID: <20091003171035.GA19278@bromo.med.uc.edu> On Sat, Oct 03, 2009 at 04:50:51PM -0000, MacPorts wrote: > #21341: fixed packaging for gcc44 > --------------------------------------+------------------------------------- > Reporter: howarth@? | Owner: mww@? > Type: enhancement | Status: new > Priority: Normal | Milestone: > Component: ports | Version: 1.8.0 > Keywords: | Port: gcc44 > --------------------------------------+------------------------------------- > > Comment(by ram@?): > > Markus, any objections to these changes? > > -- > Ticket URL: > MacPorts > Ports system for Mac OS Since an alternate approach was used to fix the gcc44 build. all that they need from this ticket to add the gcc44-disable-libjava.diff patch and as well as to add --disable-libjava-multilib to the configure options in the current gcc44 Portfile. Jack From talklists at newgeo.com Sat Oct 3 14:28:39 2009 From: talklists at newgeo.com (Scott Haneda) Date: Sat, 3 Oct 2009 14:28:39 -0700 Subject: Download sources from servers that don't respond to ping In-Reply-To: References: <4B7FDBAC-6B25-443B-B01E-602596CF4D5A@geeklair.net> Message-ID: <96DE7510-1B88-4E9C-858B-A8BA3E1337EC@newgeo.com> What is the hostname of one of these servers for example? -- Scott * If you contact me off list replace talklists@ with scott@ * On Oct 3, 2009, at 10:04 AM, Jann R??der wrote: > Yes, but I still want to download stuff from them. > > Daniel J. Luke schrieb: >> On Oct 3, 2009, at 12:58 PM, Jann R??der wrote: >>> I noticed, that at the moment servers which do not respond to >>> Pings are >>> not considered as sources. This sounds reasonable, but unfortunately >>> there are some servers out there that work just fine even though >>> they do >>> not respond to Ping messages. So I request that sources with a ping >>> value of 10000 are still considered. >> >> Servers which block all ICMP are broken (usually when ICMP echo is >> blocked, all ICMP is blocked) as they break path mtu discovery. From jameskyle at macports.org Sat Oct 3 14:54:30 2009 From: jameskyle at macports.org (James Kyle) Date: Sat, 3 Oct 2009 14:54:30 -0700 Subject: py26-numpy, py26-scipy, and macports atlas/lapack/blas In-Reply-To: <4D11F3AF-72CB-4704-A7AA-A9E94F3A839F@geeklair.net> References: <680FC860-70E1-4E5F-8F6A-D4EBF4E25FA5@macports.org> <799406d60910030905r29b8753bg5b4028e619460722@mail.gmail.com> <7bad5d350910030941h503d223ag1db7e83b2a229296@mail.gmail.com> <4D11F3AF-72CB-4704-A7AA-A9E94F3A839F@geeklair.net> Message-ID: <9DD26C23-CBB9-4651-A50F-D5E2AA4AC39E@macports.org> > I believe negative variants are still not stored in the registry, so > default variants can cause issues for people when upgrading a port > (since they'll be automatically selected again). This was my reasoning for going with the no_* nomenclature. > You'll want these packages to build against the gcc44 package > rather than the gcc43 package. As others have mentioned, the gcc43 (and previous) packages build fine for me on SL (late 2008 mac pro). > I really like this idea, but the main thing that concerns me is that > any port that depends on numpy will now also depend on gcc43, or gcc44 > (which seems like a better idea), this is a big change as gcc takes a > _long_ time to build. I understand that concern. As others mentioned, I tried to include a way for the deps to be disabled that would be upgrade friendly as well. The atlas port I put together conforms to the official optimization methods and so is quite a beast in its own right. I haven't benched, but I'd guess it takes almost as long as gcc. I went with 4.3 over 4.4 as it seemed to be the consensus for a common compiler in ticket #20103. I'm fine with using the 4.4. toolchain if the other packages follow suit. :) -james From ryandesign at macports.org Sat Oct 3 15:18:24 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 3 Oct 2009 17:18:24 -0500 Subject: Download sources from servers that don't respond to ping In-Reply-To: References: Message-ID: <165861EA-BEB7-46E3-81F5-8DAF1CF5B8BF@macports.org> On Oct 3, 2009, at 11:58, Jann R??der wrote: > I noticed, that at the moment servers which do not respond to Pings > are > not considered as sources. This sounds reasonable, but unfortunately > there are some servers out there that work just fine even though > they do > not respond to Ping messages. So I request that sources with a ping > value of 10000 are still considered. MacPorts used to download from servers in the order specified in the portfile. This was not optimal as slow servers listed first would always be tried before possibly faster servers listed later. MacPorts 1.7 changed this to ping all download servers and try them in ping order. If a server does not respond to ping or is offline, it will be at the bottom of the list and will be tried last. This is not perfect because as you say some servers might not respond to pings (though hopefully that's rare), and some servers that respond quickly to pings may not actually be fast at sending the file, but it was easy enough to implement and better than what we had. We're open to suggestions on further improvements for auto-selecting fast download locations. From roederja at ethz.ch Sat Oct 3 16:27:14 2009 From: roederja at ethz.ch (=?UTF-8?B?SmFubiBSw7bCmmRlcg==?=) Date: Sun, 04 Oct 2009 01:27:14 +0200 Subject: Download sources from servers that don't respond to ping In-Reply-To: <165861EA-BEB7-46E3-81F5-8DAF1CF5B8BF@macports.org> References: <165861EA-BEB7-46E3-81F5-8DAF1CF5B8BF@macports.org> Message-ID: > MacPorts 1.7 changed this to ping all download servers and try them in > ping order. If a server does not respond to ping or is offline, it > will be at the bottom of the list and will be tried last. I have seen an instance where the macports mirror servers were tried which did not have the file. The server specified in the port file was not tried at all. For some reason even though the macports mirror servers didn't have the file a file with size 0 was created, thus leading to a hash mismatch. Obviously this behavior is not good. From ryandesign at macports.org Sat Oct 3 16:34:24 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 3 Oct 2009 18:34:24 -0500 Subject: Download sources from servers that don't respond to ping In-Reply-To: References: <165861EA-BEB7-46E3-81F5-8DAF1CF5B8BF@macports.org> Message-ID: On Oct 3, 2009, at 18:27, Jann R??der wrote: > I have seen an instance where the macports mirror servers were tried > which did not have the file. The server specified in the port file was > not tried at all. For some reason even though the macports mirror > servers didn't have the file a file with size 0 was created, thus > leading to a hash mismatch. > > Obviously this behavior is not good I agree, that doesn't sound good. What port was this? From roederja at ethz.ch Sat Oct 3 16:51:08 2009 From: roederja at ethz.ch (=?UTF-8?B?SmFubiBSw7bCmmRlcg==?=) Date: Sun, 04 Oct 2009 01:51:08 +0200 Subject: Download sources from servers that don't respond to ping In-Reply-To: References: <165861EA-BEB7-46E3-81F5-8DAF1CF5B8BF@macports.org> Message-ID: It was the eiffelstudio65 port, I now added another source which does respond to ping requests - problem "solved". The n.ethz.ch server (which is not pingable) is still included in the source list. Ryan Schmidt schrieb: > > On Oct 3, 2009, at 18:27, Jann R??der wrote: > >> I have seen an instance where the macports mirror servers were tried >> which did not have the file. The server specified in the port file was >> not tried at all. For some reason even though the macports mirror >> servers didn't have the file a file with size 0 was created, thus >> leading to a hash mismatch. >> >> Obviously this behavior is not good > > I agree, that doesn't sound good. What port was this? > From ryandesign at macports.org Sat Oct 3 16:51:55 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 3 Oct 2009 18:51:55 -0500 Subject: Download sources from servers that don't respond to ping In-Reply-To: <4AC7E261.1020707@ethz.ch> References: <165861EA-BEB7-46E3-81F5-8DAF1CF5B8BF@macports.org> <4AC7E261.1020707@ethz.ch> Message-ID: On Oct 3, 2009, at 18:46, Jann R?der wrote: > Ryan Schmidt schrieb: >> > >> On Oct 3, 2009, at 18:27, Jann R??der wrote: >> >>> I have seen an instance where the macports mirror servers were tried >>> which did not have the file. The server specified in the port file >>> was >>> not tried at all. For some reason even though the macports mirror >>> servers didn't have the file a file with size 0 was created, thus >>> leading to a hash mismatch. >>> >>> Obviously this behavior is not good >> >> I agree, that doesn't sound good. What port was this? > > It was the eiffelstudio65 port, I now added another source which does > respond to ping requests - problem "solved". Ok. And the file has now been mirrored by the distfiles mirror, so that solves it as well. > The n.ethz.ch server (which > is not pingable) is still included in the source list. Perhaps you could speak with the owners of that server about making it pingable. I'm still not clear how you ended up with a 0-sized file with obviously mismatched checksums if no 0-sized file existed on any of the master_sites. If you can reproduce that problem, please send the debug output. From roederja at ethz.ch Sat Oct 3 17:01:27 2009 From: roederja at ethz.ch (=?UTF-8?B?SmFubiBSw7ZkZXI=?=) Date: Sun, 04 Oct 2009 02:01:27 +0200 Subject: Download sources from servers that don't respond to ping In-Reply-To: References: <165861EA-BEB7-46E3-81F5-8DAF1CF5B8BF@macports.org> <4AC7E261.1020707@ethz.ch> Message-ID: > I'm still not clear how you ended up with a 0-sized file with obviously > mismatched checksums if no 0-sized file existed on any of the > master_sites. If you can reproduce that problem, please send the debug > output. Ok I'll try, it happened when I updated the file on the n.ethz.ch server (with a different name). I used the debug output to get the new hash. Somehow I got the hash value for a 0 sized file, which I only noticed later when I discovered that the installation was incomplete. Anyway I'll try it again. From ram at macports.org Sat Oct 3 17:57:42 2009 From: ram at macports.org (Adam Mercer) Date: Sat, 3 Oct 2009 19:57:42 -0500 Subject: auto prop settings in ~/.subversion/config seem to be ignored Message-ID: <799406d60910031757o3fefc48ajf7e7fd2385606b39@mail.gmail.com> Hi As per the guidelines I have [miscellany] enable-auto-props = yes [auto-props] Portfile = svn:eol-style=native,svn:keywords=Id in my ~/.subversion/config file, but after committing r58737 I've noticed that the properties are not being set: $ svn proplist Portfile $ Does anyone know why the settings in ~/.subversion/config are being ignored? I'm using subversion @1.6.5_0. Cheers Adam From ryandesign at macports.org Sat Oct 3 18:00:02 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 3 Oct 2009 20:00:02 -0500 Subject: auto prop settings in ~/.subversion/config seem to be ignored In-Reply-To: <799406d60910031757o3fefc48ajf7e7fd2385606b39@mail.gmail.com> References: <799406d60910031757o3fefc48ajf7e7fd2385606b39@mail.gmail.com> Message-ID: On Oct 3, 2009, at 19:57, Adam Mercer wrote: > As per the guidelines I have > > [miscellany] > enable-auto-props = yes > > [auto-props] > Portfile = svn:eol-style=native,svn:keywords=Id > > in my ~/.subversion/config file, but after committing r58737 I've > noticed that the properties are not being set: > > $ svn proplist Portfile > $ > > Does anyone know why the settings in ~/.subversion/config are being > ignored? I'm using subversion @1.6.5_0. Hi Adam. The only difference to what I have in my config is that I'm using a semicolon separator instead of a comma. Try that. Portfile = svn:eol-style=native;svn:keywords=Id From ram at macports.org Sat Oct 3 18:02:33 2009 From: ram at macports.org (Adam Mercer) Date: Sat, 3 Oct 2009 20:02:33 -0500 Subject: auto prop settings in ~/.subversion/config seem to be ignored In-Reply-To: References: <799406d60910031757o3fefc48ajf7e7fd2385606b39@mail.gmail.com> Message-ID: <799406d60910031802h174783edxcbcefe2bbf158d99@mail.gmail.com> On Sat, Oct 3, 2009 at 20:00, Ryan Schmidt wrote: > Hi Adam. The only difference to what I have in my config is that I'm using a > semicolon separator instead of a comma. Try that. > > Portfile = svn:eol-style=native;svn:keywords=Id Thanks Ryan, I've made the change and reading the man page in more detail it looks like that was my problem. Cheers Adam From raimue at macports.org Sun Oct 4 06:40:28 2009 From: raimue at macports.org (=?UTF-8?B?UmFpbmVyIE3DvGxsZXI=?=) Date: Sun, 04 Oct 2009 15:40:28 +0200 Subject: [58749] trunk/dports/lang/oorexx In-Reply-To: <20091004104309.6817228EC005@beta.macosforge.org> References: <20091004104309.6817228EC005@beta.macosforge.org> Message-ID: <4AC8A5CC.2050208@macports.org> On 2009-10-04 12:43 , krischik at macports.org wrote: > Revision: 58749 > http://trac.macports.org/changeset/58749 > Author: krischik at macports.org > Date: 2009-10-04 03:43:04 -0700 (Sun, 04 Oct 2009) > Log Message: > ----------- > Update for Snow Leopard, backup 4.0 script, true 64 bit support maybe with 4.1 > > Modified Paths: > -------------- > trunk/dports/lang/oorexx/Portfile > > Added Paths: > ----------- > trunk/dports/lang/oorexx/Portfile.4 Wouldn't it be better to add a oorexx-devel port for that instead? You cannot use this Portfile currently. Rainer From talklists at newgeo.com Sun Oct 4 12:39:17 2009 From: talklists at newgeo.com (Scott Haneda) Date: Sun, 4 Oct 2009 12:39:17 -0700 Subject: Download sources from servers that don't respond to ping In-Reply-To: <165861EA-BEB7-46E3-81F5-8DAF1CF5B8BF@macports.org> References: <165861EA-BEB7-46E3-81F5-8DAF1CF5B8BF@macports.org> Message-ID: <8E8B5444-4992-4AD9-AE9C-029F4289B608@newgeo.com> I had the misfortune of some bad routes with my colocation provider a while back. Traceroute being the main tool I was using. This combined with Comcast doing strange things on their routers gave me a chance to learn a little more about checking hosts. Rather than ping, what about "curl --head example.com". Of course you can be as specific as you want and attach as deep a URI as you like. This may not work as I believe it's a port 80 based test and I'm not sure what ports need testing. Though if it's using ping, with as unreliable as that is, I can't see curl being anything but an improvement. I assume these are rsync servers, or are we talking about the actual servers that hold the distro? In the latter, curl would work perfect, in the former, there would be a requirement that http be active. Or perhaps curl could be told to hit another port. Where ping and traceroute fail me for basic up status testing, curl with a --head flag always gives me more data, in more detail. Any reasons this would not be a better approach? -- Scott Iphone says hello. On Oct 3, 2009, at 3:18 PM, Ryan Schmidt wrote: > This is not perfect because as you say some servers might not > respond to pings (though hopefully that's rare), and some servers > that respond quickly to pings may not actually be fast at sending > the file, but it was easy enough to implement and better than what > we had. We're open to suggestions on further improvements for auto- > selecting fast download locations. From howarth at bromo.med.uc.edu Sun Oct 4 15:14:08 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 4 Oct 2009 18:14:08 -0400 Subject: py26-numpy, py26-scipy, and macports atlas/lapack/blas In-Reply-To: References: <680FC860-70E1-4E5F-8F6A-D4EBF4E25FA5@macports.org> <20091003050121.GA14320@bromo.med.uc.edu> Message-ID: <20091004221408.GA20042@bromo.med.uc.edu> On Fri, Oct 02, 2009 at 11:11:39PM -0700, Jeremy Huddleston wrote: > > On Oct 2, 2009, at 22:01, Jack Howarth wrote: > >> James, >> You'll want these packages to build against the gcc44 package >> rather than the gcc43 package. Only gcc 4.4.x and later builds >> on Snow Leopard. >> Jack > > Huh? Really? I seem to be building and using gcc-4.0 and 4.2 just > fine... what's failing about pre-4.4 gccs for you? Jeremy, I am referring to packages that need the gcc43 or gcc44 packages in MacPorts to satisfy a requirement for gfortran. When I submitted patches to FSF gcc to solve darwin10 build issues, I only did so for the current gcc trunk (which became gcc 4.4.0). There was no attempt made to backport the changes to gcc 4.3.x. This means any package in MacPorts which needs gfortran will have to depend on gcc44 or later if it is to be buildable on Snow Leopard. Jack From howarth at bromo.med.uc.edu Sun Oct 4 15:22:32 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 4 Oct 2009 18:22:32 -0400 Subject: molmol 2k2.0 vs MacPorts Message-ID: <20091004222232.GA20113@bromo.med.uc.edu> Jeremy, I've uploaded the MacPorts molmol 2k2.0 packaging (which builds in an identical manner as on fink) as a MacPorts ticket... http://trac.macports.org/ticket/21835 The current X11 packages in MacPorts 1.8.1 still show breakage when running the molmol binary that this package (or a manual build of molmol in /usr/local) produces. The windows for molmol open but the user interface widgets never appear (as is show in the documentation for molmol here)... http://www.msg.ucsf.edu/local/programs/molmol/manual.html#ui_mainwin I don't really believe this is a openmotif or glw problem since I can build the fink package for molmol against the openmotif 2.3.2 release with essentially the same patches and it runs fine under fink. Also, the glw runs the opensolar.c demo program fine so it shouldn't be at fault. Could you make any suggestions for debugging this? I haven't tried installing the Xquartz alpha release for 2.4.1 yet but molmol should be able to run fine against the stock X11 in SL. Thanks in advance for any help on debugging this. Jack From ryandesign at macports.org Sun Oct 4 15:46:11 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 4 Oct 2009 17:46:11 -0500 Subject: py26-numpy, py26-scipy, and macports atlas/lapack/blas In-Reply-To: <20091004221408.GA20042@bromo.med.uc.edu> References: <680FC860-70E1-4E5F-8F6A-D4EBF4E25FA5@macports.org> <20091003050121.GA14320@bromo.med.uc.edu> <20091004221408.GA20042@bromo.med.uc.edu> Message-ID: On Oct 4, 2009, at 17:14, Jack Howarth wrote: > On Fri, Oct 02, 2009 at 11:11:39PM -0700, Jeremy Huddleston wrote: >> > >> On Oct 2, 2009, at 22:01, Jack Howarth wrote: >> >>> James, >>> You'll want these packages to build against the gcc44 package >>> rather than the gcc43 package. Only gcc 4.4.x and later builds >>> on Snow Leopard. >>> Jack >> >> Huh? Really? I seem to be building and using gcc-4.0 and 4.2 just >> fine... what's failing about pre-4.4 gccs for you? > > Jeremy, > I am referring to packages that need the gcc43 or gcc44 packages > in MacPorts to satisfy a requirement for gfortran. When I submitted > patches to FSF gcc to solve darwin10 build issues, I only did so > for the current gcc trunk (which became gcc 4.4.0). There was no > attempt made to backport the changes to gcc 4.3.x. This means any > package in MacPorts which needs gfortran will have to depend on > gcc44 or later if it is to be buildable on Snow Leopard. Then perhaps your fix was not used, because gcc43 is currently installed on my Snow Leopard system. r57658 may have been the fix we used. Last I checked gcc42 still wouldn't build, but perhaps r57804 fixed that. I will try again now. From jmr at macports.org Sun Oct 4 15:51:03 2009 From: jmr at macports.org (Joshua Root) Date: Mon, 05 Oct 2009 09:51:03 +1100 Subject: py26-numpy, py26-scipy, and macports atlas/lapack/blas In-Reply-To: <20091004221408.GA20042@bromo.med.uc.edu> References: <680FC860-70E1-4E5F-8F6A-D4EBF4E25FA5@macports.org> <20091003050121.GA14320@bromo.med.uc.edu> <20091004221408.GA20042@bromo.med.uc.edu> Message-ID: <4AC926D7.9050201@macports.org> On 2009-10-5 09:14, Jack Howarth wrote: > On Fri, Oct 02, 2009 at 11:11:39PM -0700, Jeremy Huddleston wrote: >> On Oct 2, 2009, at 22:01, Jack Howarth wrote: >> >>> James, >>> You'll want these packages to build against the gcc44 package >>> rather than the gcc43 package. Only gcc 4.4.x and later builds >>> on Snow Leopard. >>> Jack >> Huh? Really? I seem to be building and using gcc-4.0 and 4.2 just >> fine... what's failing about pre-4.4 gccs for you? > > Jeremy, > I am referring to packages that need the gcc43 or gcc44 packages > in MacPorts to satisfy a requirement for gfortran. When I submitted > patches to FSF gcc to solve darwin10 build issues, I only did so > for the current gcc trunk (which became gcc 4.4.0). There was no > attempt made to backport the changes to gcc 4.3.x. This means any > package in MacPorts which needs gfortran will have to depend on > gcc44 or later if it is to be buildable on Snow Leopard. Is that a private email from Jeremy you quoted? What he wrote on the list is: On 2009-10-3 16:52, Jeremy Huddleston wrote: > Uhm... I'm on SL, and I just installed gcc43. > > What problem do you have installing gcc43? Have you actually tried installing gcc43 on SL lately? - Josh From ryandesign at macports.org Sun Oct 4 15:57:35 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 4 Oct 2009 17:57:35 -0500 Subject: [58760] contrib/mpvim/syntax/portfile.vim In-Reply-To: <20091004215128.CF7B728F02C5@beta.macosforge.org> References: <20091004215128.CF7B728F02C5@beta.macosforge.org> Message-ID: On Oct 4, 2009, at 16:51, mnick at macports.org wrote: > Revision: 58760 > http://trac.macports.org/changeset/58760 > Author: mnick at macports.org > Date: 2009-10-04 14:51:28 -0700 (Sun, 04 Oct 2009) > Log Message: > ----------- > support 'path:' dependencies > > Modified Paths: > -------------- > contrib/mpvim/syntax/portfile.vim > > Modified: contrib/mpvim/syntax/portfile.vim > =================================================================== > --- contrib/mpvim/syntax/portfile.vim 2009-10-04 21:50:10 UTC (rev > 58759) > +++ contrib/mpvim/syntax/portfile.vim 2009-10-04 21:51:28 UTC (rev > 58760) > @@ -98,7 +98,7 @@ > " Dependencies > syn match PortfileDepends "depends_\(\(lib\|build\|run\|fetch\| > extract\)\(-\(append\|delete\)\)\?\)" > nextgroup=PortfileDependsEntries skipwhite > syn region PortfileDependsEntries matchgroup=Normal start="" skip="\\$ > " end="$" contains=PortfileDependsEntry contained > -syn match PortfileDependsEntry "\(port\|bin\):" contained > +syn match PortfileDependsEntry "\(port\|bin\|path\):" contained What about "lib:" dependencies? :) From ryandesign at macports.org Sun Oct 4 16:20:34 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 4 Oct 2009 18:20:34 -0500 Subject: Download sources from servers that don't respond to ping In-Reply-To: <8E8B5444-4992-4AD9-AE9C-029F4289B608@newgeo.com> References: <165861EA-BEB7-46E3-81F5-8DAF1CF5B8BF@macports.org> <8E8B5444-4992-4AD9-AE9C-029F4289B608@newgeo.com> Message-ID: <61BAB90E-0152-4231-BEC0-BFBFA81E188A@macports.org> On Oct 4, 2009, at 14:39, Scott Haneda wrote: > On Oct 3, 2009, at 3:18 PM, Ryan Schmidt wrote: > >> This is not perfect because as you say some servers might not >> respond to pings (though hopefully that's rare), and some servers >> that respond quickly to pings may not actually be fast at sending >> the file, but it was easy enough to implement and better than what >> we had. We're open to suggestions on further improvements for auto- >> selecting fast download locations. > > I had the misfortune of some bad routes with my colocation provider > a while back. Traceroute being the main tool I was using. This > combined with Comcast doing strange things on their routers gave me > a chance to learn a little more about checking hosts. > > Rather than ping, what about "curl --head example.com". Of course > you can be as specific as you want and attach as deep a URI as you > like. > > This may not work as I believe it's a port 80 based test and I'm not > sure what ports need testing. Though if it's using ping, with as > unreliable as that is, I can't see curl being anything but an > improvement. > > I assume these are rsync servers, or are we talking about the actual > servers that hold the distro? In the latter, curl would work > perfect, in the former, there would be a requirement that http be > active. Or perhaps curl could be told to hit another port. > > Where ping and traceroute fail me for basic up status testing, curl > with a --head flag always gives me more data, in more detail. > > Any reasons this would not be a better approach? We are talking about distfile servers (the servers portfiles specify in their master_sites line), which MacPorts currently automatically checks for quality using ping as I described. We are not talking about rsync servers which are used only to retrieve portfiles during "sudo port sync" and MacPorts base code during "sudo port selfupdate", and which the user must still manually select in sources.conf. "curl --head" could be used to determine whether we can connect to a server, but it doesn't give you a quality indication that could be used to rank multiple available servers. "ping" tells you how many milliseconds it took to reach the server, which is how we sort distfile servers today. You might be able to use "time" to time a curl command, but I have a feeling that would be less accurate because it would time the entire curl process, and not just the network access part like ping's internal timing does. I'm also fairly sure doing an HTTP or HTTPS or FTP request and response, like curl would do, would take a lot more time than a ping. This is not to say ping is the only solution we should use, but these are probably some of the reasons why it was selected in the first place, and some things to consider when thinking about if it should be replaced. If a server does not respond to pings, it will simply appear toward the end of the available servers, and other servers, if available, will be tried first. The 3 or 4 MacPorts distfile mirrors will almost certainly be available, so the file should be retrievable from one of those. And if no other server has the file (perhaps the distfiles mirrors haven't mirrored it yet), then the server that doesn't respond to pings will still be tried, albeit last. So at worst this should result in slightly slower downloads for users close to the unpingable server. I don't think that consequence is worth rewriting the MacPorts base code for. Note I am unable to explain the symptom Jann experienced, that of receiving a 0-byte file instead of a complete file or a failure response. That sounds like a misconfigured server and would have nothing to do with the nearby server selection mechanism. From ryandesign at macports.org Sun Oct 4 17:50:16 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 4 Oct 2009 19:50:16 -0500 Subject: py26-numpy, py26-scipy, and macports atlas/lapack/blas In-Reply-To: References: <680FC860-70E1-4E5F-8F6A-D4EBF4E25FA5@macports.org> <20091003050121.GA14320@bromo.med.uc.edu> <20091004221408.GA20042@bromo.med.uc.edu> Message-ID: <2BCA3646-61D4-4D6A-8DB3-C5988A7971FD@macports.org> On Oct 4, 2009, at 17:46, Ryan Schmidt wrote: > Last I checked gcc42 still wouldn't build, but perhaps r57804 fixed > that. I will try again now. Ok, gcc42 still doesn't build for me and at least one other person on Snow Leopard; see: http://trac.macports.org/ticket/21665 From howarth at bromo.med.uc.edu Sun Oct 4 18:10:19 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 4 Oct 2009 21:10:19 -0400 Subject: py26-numpy, py26-scipy, and macports atlas/lapack/blas In-Reply-To: <2BCA3646-61D4-4D6A-8DB3-C5988A7971FD@macports.org> References: <680FC860-70E1-4E5F-8F6A-D4EBF4E25FA5@macports.org> <20091003050121.GA14320@bromo.med.uc.edu> <20091004221408.GA20042@bromo.med.uc.edu> <2BCA3646-61D4-4D6A-8DB3-C5988A7971FD@macports.org> Message-ID: <20091005011019.GA20946@bromo.med.uc.edu> On Sun, Oct 04, 2009 at 07:50:16PM -0500, Ryan Schmidt wrote: > On Oct 4, 2009, at 17:46, Ryan Schmidt wrote: > >> Last I checked gcc42 still wouldn't build, but perhaps r57804 fixed >> that. I will try again now. > > > Ok, gcc42 still doesn't build for me and at least one other person on > Snow Leopard; see: > > http://trac.macports.org/ticket/21665 > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev It shouldn't come as a surprise as the patches I submitted for FSF gcc only went into gcc trunk for gcc 4.4 and later... http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00333.html http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00428.html http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00811.html http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01515.html http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01532.html http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00054.html http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00177.html Considering that gcc 4.2.x is currently depreciated and unmaintained by upstream, it is rather pointless to keep it when gcc44 works as well across all architectures. The only reason Apple is stuck at 4.2.1 is because of the GPLv3 licensing issues. Jack From ryandesign at macports.org Sun Oct 4 19:57:25 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 4 Oct 2009 21:57:25 -0500 Subject: py26-numpy, py26-scipy, and macports atlas/lapack/blas In-Reply-To: <20091005011019.GA20946@bromo.med.uc.edu> References: <680FC860-70E1-4E5F-8F6A-D4EBF4E25FA5@macports.org> <20091003050121.GA14320@bromo.med.uc.edu> <20091004221408.GA20042@bromo.med.uc.edu> <2BCA3646-61D4-4D6A-8DB3-C5988A7971FD@macports.org> <20091005011019.GA20946@bromo.med.uc.edu> Message-ID: <39200630-59A3-4054-B088-E0D7F3C5754F@macports.org> On Oct 4, 2009, at 20:10, Jack Howarth wrote: > On Sun, Oct 04, 2009 at 07:50:16PM -0500, Ryan Schmidt wrote: > >> On Oct 4, 2009, at 17:46, Ryan Schmidt wrote: >> >>> Last I checked gcc42 still wouldn't build, but perhaps r57804 fixed >>> that. I will try again now. >> >> Ok, gcc42 still doesn't build for me and at least one other person on >> Snow Leopard; see: >> >> http://trac.macports.org/ticket/21665 > > It shouldn't come as a surprise as the patches I submitted for > FSF gcc only went into gcc trunk for gcc 4.4 and later... > > http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00333.html > http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00428.html > http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00811.html > http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01515.html > http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01532.html > http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00054.html > http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00177.html I suggested in my previous message that perhaps your patches had not been used by MacPorts, since you already said your patches do not work for gcc43, yet gcc43 was modified to work on Snow Leopard. > Considering that gcc 4.2.x is currently depreciated and > unmaintained by upstream, it is rather pointless to keep > it when gcc44 works as well across all architectures. > The only reason Apple is stuck at 4.2.1 is because of > the GPLv3 licensing issues. My motivation for gcc42 at this moment is pdftk which does not compile with greater than gcc42. There are some patches for pdftk from other distributions, though, of which I have just been made aware, which are supposed to help with this, which I will attempt to look into and incorporate. http://trac.macports.org/ticket/15420 From opendarwin.org at darkart.com Sun Oct 4 21:09:34 2009 From: opendarwin.org at darkart.com (Eric Hall) Date: Mon, 5 Oct 2009 04:09:34 +0000 Subject: Download sources from servers that don't respond to ping In-Reply-To: References: <165861EA-BEB7-46E3-81F5-8DAF1CF5B8BF@macports.org> <4AC7E261.1020707@ethz.ch> Message-ID: <20091005040934.GK1215@darkart.com> On Sat, Oct 03, 2009 at 06:51:55PM -0500, Ryan Schmidt wrote: [snip] > > Perhaps you could speak with the owners of that server about making it > pingable. > I wouldn't bother, people who block ICMP echo usually do so for a reason and are unlikely to open it up just because somebody else's software uses it for timing information. I think at best you'd annoy some people, and may well wind up costing someone their distfile hosting because of it. -eric From opendarwin.org at darkart.com Sun Oct 4 21:16:19 2009 From: opendarwin.org at darkart.com (Eric Hall) Date: Mon, 5 Oct 2009 04:16:19 +0000 Subject: Download sources from servers that don't respond to ping In-Reply-To: <61BAB90E-0152-4231-BEC0-BFBFA81E188A@macports.org> References: <165861EA-BEB7-46E3-81F5-8DAF1CF5B8BF@macports.org> <8E8B5444-4992-4AD9-AE9C-029F4289B608@newgeo.com> <61BAB90E-0152-4231-BEC0-BFBFA81E188A@macports.org> Message-ID: <20091005041619.GL1215@darkart.com> On Sun, Oct 04, 2009 at 06:20:34PM -0500, Ryan Schmidt wrote: > On Oct 4, 2009, at 14:39, Scott Haneda wrote: > > >On Oct 3, 2009, at 3:18 PM, Ryan Schmidt wrote: > > > >>This is not perfect because as you say some servers might not > >>respond to pings (though hopefully that's rare), and some servers > >>that respond quickly to pings may not actually be fast at sending > >>the file, but it was easy enough to implement and better than what > >>we had. We're open to suggestions on further improvements for auto- > >>selecting fast download locations. > > [snip] > > > >Rather than ping, what about "curl --head example.com". Of course > >you can be as specific as you want and attach as deep a URI as you > >like. > > > >This may not work as I believe it's a port 80 based test and I'm not > >sure what ports need testing. Though if it's using ping, with as > >unreliable as that is, I can't see curl being anything but an > >improvement. [snip] > > We are talking about distfile servers (the servers portfiles specify > in their master_sites line), which MacPorts currently automatically > checks for quality using ping as I described. We are not talking about > rsync servers which are used only to retrieve portfiles during "sudo > port sync" and MacPorts base code during "sudo port selfupdate", and > which the user must still manually select in sources.conf. > > "curl --head" could be used to determine whether we can connect to a > server, but it doesn't give you a quality indication that could be > used to rank multiple available servers. "ping" tells you how many > milliseconds it took to reach the server, which is how we sort > distfile servers today. You might be able to use "time" to time a curl > command, but I have a feeling that would be less accurate because it > would time the entire curl process, and not just the network access > part like ping's internal timing does. I'm also fairly sure doing an > HTTP or HTTPS or FTP request and response, like curl would do, would > take a lot more time than a ping. This is not to say ping is the only > solution we should use, but these are probably some of the reasons why > it was selected in the first place, and some things to consider when > thinking about if it should be replaced. [snip] Instead of using curl, why not use an internal socket connection on "the right port(s)" for the service used to deliver distfiles? That will be tcp/80 for most ports, some will have different ports (svn or ftp for example). Start a tcp connection, once you get the socket completed, check the timing. That also lets you know if the service you want to use is available. In fact, if this was done "at the right place" (TM), the "fastest" connection could be the connection used for the actual download, and the other connections can be dropped. Note that I did not look at the code that implements the downloads, it may not be practical to insert timing checks and connection-drop logic there. -eric From ryandesign at macports.org Sun Oct 4 22:32:06 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 5 Oct 2009 00:32:06 -0500 Subject: Download sources from servers that don't respond to ping In-Reply-To: <20091005041619.GL1215@darkart.com> References: <165861EA-BEB7-46E3-81F5-8DAF1CF5B8BF@macports.org> <8E8B5444-4992-4AD9-AE9C-029F4289B608@newgeo.com> <61BAB90E-0152-4231-BEC0-BFBFA81E188A@macports.org> <20091005041619.GL1215@darkart.com> Message-ID: <4D86D97C-9483-49D2-AEEC-08EC31F78580@macports.org> On Oct 4, 2009, at 23:16, Eric Hall wrote: > Instead of using curl, why not use an internal socket > connection on "the right port(s)" for the service used to > deliver distfiles? That will be tcp/80 for most ports, > some will have different ports (svn or ftp for example). svn/git/cvs type connections need not be checked. Either the server exists and will work or it doesn't and the port will fail to fetch. There are no backup distfile servers for ports that check out from a repository and thus don't use distfiles. > Start a tcp connection, once you get the socket completed, > check the timing. That could be a possibility. I don't do this type of network programming so I don't know what would be involved. > That also lets you know if the service > you want to use is available. Additional checks to see if the service is available aren't strictly needed since we already fail gracefully in the fetch phase (proceeding to the next server in the list) if it isn't. Though detecting this earlier would allow us to exclude those servers from the list entirely. > In fact, if this was done "at the right place" (TM), > the "fastest" connection could be the connection used for > the actual download, and the other connections can be dropped. > Note that I did not look at the code that implements the > downloads, it may not be practical to insert timing checks > and connection-drop logic there. We use curl to actually download the distfile; if we wanted to re-use the timing check connection we would have to implement the downloading code ourselves which is probably nontrivial to get correct for all possible HTTP/HTTPS/FTP servers... From ryandesign at macports.org Mon Oct 5 03:54:53 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 5 Oct 2009 05:54:53 -0500 Subject: Make "startupitem.create" yes imply "install.asroot yes" Message-ID: Ever since 1.8.0 I have been having trouble with my non-root MacPorts installs. I used to be able to install normal ports with e.g. "port install zlib" and ports that required root with e.g. "sudo port install lighttpd". As of 1.8.0, I now get a permission error when trying to install such ports, even though I'm using sudo. This has got to be the new privilege-dropping code from the GSoC '08 privileges branch. I have tried to read the documentation on that branch in the wiki. It seems we're now supposed to add "install.asroot yes" to ports that need it. I did this for lighttpd but it seems silly to have to do this manually for every port that makes a startupitem; there are quite a few of them. Can we have MacPorts automatically set "install.asroot yes" when "startupitem.create yes" is set (and "startupitem.type" is not "none")? Or is there a reason why that's a bad idea? From howarth at bromo.med.uc.edu Mon Oct 5 06:10:50 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Mon, 5 Oct 2009 09:10:50 -0400 Subject: py26-numpy, py26-scipy, and macports atlas/lapack/blas In-Reply-To: <39200630-59A3-4054-B088-E0D7F3C5754F@macports.org> References: <680FC860-70E1-4E5F-8F6A-D4EBF4E25FA5@macports.org> <20091003050121.GA14320@bromo.med.uc.edu> <20091004221408.GA20042@bromo.med.uc.edu> <2BCA3646-61D4-4D6A-8DB3-C5988A7971FD@macports.org> <20091005011019.GA20946@bromo.med.uc.edu> <39200630-59A3-4054-B088-E0D7F3C5754F@macports.org> Message-ID: <20091005131050.GB25614@bromo.med.uc.edu> On Sun, Oct 04, 2009 at 09:57:25PM -0500, Ryan Schmidt wrote: > On Oct 4, 2009, at 20:10, Jack Howarth wrote: > >> On Sun, Oct 04, 2009 at 07:50:16PM -0500, Ryan Schmidt wrote: >> >>> On Oct 4, 2009, at 17:46, Ryan Schmidt wrote: >>> >>>> Last I checked gcc42 still wouldn't build, but perhaps r57804 fixed >>>> that. I will try again now. >>> >>> Ok, gcc42 still doesn't build for me and at least one other person on >>> Snow Leopard; see: >>> >>> http://trac.macports.org/ticket/21665 >> >> It shouldn't come as a surprise as the patches I submitted for >> FSF gcc only went into gcc trunk for gcc 4.4 and later... >> >> http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00333.html >> http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00428.html >> http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00811.html >> http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01515.html >> http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01532.html >> http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00054.html >> http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00177.html > > I suggested in my previous message that perhaps your patches had not > been used by MacPorts, since you already said your patches do not work > for gcc43, yet gcc43 was modified to work on Snow Leopard. > I didn't say that gcc 4.2 couldn't be made to work but that there wasn't much point of doing so (outside of pdftk which is broken because it incorrectly mixes c++ and java exceptions which is no longer permitted in FSF gcc). > >> Considering that gcc 4.2.x is currently depreciated and >> unmaintained by upstream, it is rather pointless to keep >> it when gcc44 works as well across all architectures. >> The only reason Apple is stuck at 4.2.1 is because of >> the GPLv3 licensing issues. > > My motivation for gcc42 at this moment is pdftk which does not compile > with greater than gcc42. > > There are some patches for pdftk from other distributions, though, of > which I have just been made aware, which are supposed to help with this, > which I will attempt to look into and incorporate. > > http://trac.macports.org/ticket/15420 > Yes, the Gentoo patches are more promising than what Fedora uses (which requires an openjdk package). From dweber at macports.org Mon Oct 5 10:51:47 2009 From: dweber at macports.org (Darren Weber) Date: Mon, 5 Oct 2009 10:51:47 -0700 Subject: tclsh testing - error on source for committers tips and tricks code Message-ID: At http://trac.macports.org/wiki/CommittersTipsAndTricks there is a section titled: Do Explorative Programming in tclsh with Readline SupportIt contains tcl code to source after starting tclsh (8.4?) under rlwrap, as follows: source /Library/Tcl/macports1.0/macports_fastload.tcl package require macports 1.0 set portarchivemode no package require port 1.0 package require Pextlib set prefix /opt/local In my bash aliases, there are: alias tclsh='rlwrap /opt/local/bin/tclsh' alias tclsh8.4='rlwrap /usr/bin/tclsh8.4' alias tclsh8.5='rlwrap /opt/local/bin/tclsh8.5' On loading the tcl script (using any of the above aliases), this is the error given: [ me at XXX ~ ]$ tclsh8.4 % source /Users/dweber/bin/macports_testing.tcl can't read "workpath": can't read "portbuildpath": no such variable % (Sorry I don't have time to track this down any further.) Can we get a fix for this? Should this be a ticket on port? Should the tips & tricks instructions get an update? Take care, Darren -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnick at macports.org Mon Oct 5 11:06:41 2009 From: mnick at macports.org (Maximilian Nickel) Date: Mon, 5 Oct 2009 20:06:41 +0200 Subject: tclsh testing - error on source for committers tips and tricks code In-Reply-To: References: Message-ID: <7bad5d350910051106p20367d33n77c08c5f58f71c48@mail.gmail.com> Hi, On Mon, Oct 5, 2009 at 7:51 PM, Darren Weber wrote: > % source /Users/dweber/bin/macports_testing.tcl > can't read "workpath": can't read "portbuildpath": no such variable > % > > (Sorry I don't have time to track this down any further.) > > Can we get a fix for this?? Should this be a ticket on port?? Should the > tips & tricks instructions get an update? > This has been previously discussed on this mailing list http://lists.macosforge.org/pipermail/macports-dev/2009-September/010132.html From dweber at macports.org Mon Oct 5 11:36:29 2009 From: dweber at macports.org (Darren Weber) Date: Mon, 5 Oct 2009 11:36:29 -0700 Subject: tclsh testing - error on source for committers tips and tricks code In-Reply-To: <7bad5d350910051106p20367d33n77c08c5f58f71c48@mail.gmail.com> References: <7bad5d350910051106p20367d33n77c08c5f58f71c48@mail.gmail.com> Message-ID: OK, updated the tips & tricks with a comment on the require package for port 1.0 and a reference to the prior email. Thanks, Darren On Mon, Oct 5, 2009 at 11:06 AM, Maximilian Nickel wrote: > Hi, > On Mon, Oct 5, 2009 at 7:51 PM, Darren Weber wrote: > > % source /Users/dweber/bin/macports_testing.tcl > > can't read "workpath": can't read "portbuildpath": no such variable > > % > > > > (Sorry I don't have time to track this down any further.) > > > > Can we get a fix for this? Should this be a ticket on port? Should the > > tips & tricks instructions get an update? > > > > This has been previously discussed on this mailing list > > http://lists.macosforge.org/pipermail/macports-dev/2009-September/010132.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dweber at macports.org Mon Oct 5 13:01:00 2009 From: dweber at macports.org (Darren Weber) Date: Mon, 5 Oct 2009 13:01:00 -0700 Subject: Updates to svn sandbox instructions Message-ID: See http://trac.macports.org/wiki/CommittersTipsAndTricks There are updated to the svn user guideliness, to include tips on merging changes back to the trunk. Please modify or advise me on any significant errors or omissions, easier methods, etc. Take care, Darren -------------- next part -------------- An HTML attachment was scrubbed... URL: From perry at macports.org Mon Oct 5 15:15:28 2009 From: perry at macports.org (Perry Lee) Date: Mon, 05 Oct 2009 15:15:28 -0700 Subject: Download sources from servers that don't respond to ping In-Reply-To: <61BAB90E-0152-4231-BEC0-BFBFA81E188A@macports.org> References: <165861EA-BEB7-46E3-81F5-8DAF1CF5B8BF@macports.org> <8E8B5444-4992-4AD9-AE9C-029F4289B608@newgeo.com> <61BAB90E-0152-4231-BEC0-BFBFA81E188A@macports.org> Message-ID: <4ACA7000.906@macports.org> Ryan Schmidt wrote: > "curl --head" could be used to determine whether we can connect to a > server, but it doesn't give you a quality indication that could be used > to rank multiple available servers. "ping" tells you how many > milliseconds it took to reach the server, which is how we sort distfile > servers today. You might be able to use "time" to time a curl command, > but I have a feeling that would be less accurate because it would time > the entire curl process, and not just the network access part like > ping's internal timing does. I'm also fairly sure doing an HTTP or HTTPS > or FTP request and response, like curl would do, would take a lot more > time than a ping. This is not to say ping is the only solution we should > use, but these are probably some of the reasons why it was selected in > the first place, and some things to consider when thinking about if it > should be replaced. How about using one of the time_ variables kept track of by curl? For example (from the man page): time_connect: The time, in seconds, it took from the start until the TCP connect to the remote host (or proxy) was completed. From raimue at macports.org Mon Oct 5 16:17:44 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Tue, 06 Oct 2009 01:17:44 +0200 Subject: Download sources from servers that don't respond to ping In-Reply-To: <4ACA7000.906@macports.org> References: <165861EA-BEB7-46E3-81F5-8DAF1CF5B8BF@macports.org> <8E8B5444-4992-4AD9-AE9C-029F4289B608@newgeo.com> <61BAB90E-0152-4231-BEC0-BFBFA81E188A@macports.org> <4ACA7000.906@macports.org> Message-ID: <4ACA7E98.5030803@macports.org> On 2009-10-06 00:15 , Perry Lee wrote: > How about using one of the time_ variables kept track of by curl? > > For example (from the man page): > > time_connect: The time, in seconds, it took from the start until the TCP > connect to the remote host (or proxy) was completed. Simultanously opening TCP connections to multiple hosts (and probably even a higher level protocol like HTTP) is not as lightweight as sending a few ICMP echo packets. If there is really someone interested to implement better alternative fetch methods, I would recommend to take a look at external tools already designed for this task before reinventing something new. For example see In my opinion our current ping based approach is fine enough, as it is now in use since 1.7.0 and we did not get major complaints about fetch failures due to this method until now. Servers which do not respond to the ping request after 3 seconds will be sorted between servers which responded and the fallback URLs. It should always work, only the sort order is influenced by ping. Rainer From ryandesign at macports.org Mon Oct 5 17:30:43 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 5 Oct 2009 19:30:43 -0500 Subject: [58794] trunk/dports/_resources/port1.0/group/archcheck-1.0.tcl In-Reply-To: <20091005141140.ECC9E28FB559@beta.macosforge.org> References: <20091005141140.ECC9E28FB559@beta.macosforge.org> Message-ID: On Oct 5, 2009, at 09:11, jmr at macports.org wrote: > Revision: 58794 > http://trac.macports.org/changeset/58794 > Author: jmr at macports.org > Date: 2009-10-05 07:11:40 -0700 (Mon, 05 Oct 2009) > Log Message: > ----------- > get the requested archs right > > Modified Paths: > -------------- > trunk/dports/_resources/port1.0/group/archcheck-1.0.tcl > > Modified: trunk/dports/_resources/port1.0/group/archcheck-1.0.tcl > =================================================================== > --- trunk/dports/_resources/port1.0/group/archcheck-1.0.tcl > 2009-10-05 12:53:54 UTC (rev 58793) > +++ trunk/dports/_resources/port1.0/group/archcheck-1.0.tcl > 2009-10-05 14:11:40 UTC (rev 58794) > @@ -45,10 +45,10 @@ > default archcheck.files {} > > pre-extract { > - if {[variant_isset universal]} { > - set requested_archs ${universal_archs} > + if {[variant_exists universal] && [variant_isset universal]} { > + set requested_archs ${configure.universal_archs} > } else { > - set requested_archs ${build_arch} > + set requested_archs ${configure.build_arch} > } > foreach file ${archcheck.files} { > # Prepend prefix if necessary. Mmm, yes, because the port might modify configure.build_arch or configure.universal_archs, right? But the port can't modify build_arch or universal_archs? What's the significance of checking [variant_exists universal]? If the variant doesn't exist, then [variant_isset universal] will be false, won't it? Or does it cause some kind of exception to check whether a nonexistent variant is set? From ryandesign at macports.org Mon Oct 5 17:32:20 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 5 Oct 2009 19:32:20 -0500 Subject: [58796] trunk/dports/ruby/rb-cocoa/Portfile In-Reply-To: <20091005143715.83C8328FBE96@beta.macosforge.org> References: <20091005143715.83C8328FBE96@beta.macosforge.org> Message-ID: <6454E195-1CDF-49C7-9408-E01729CC9AE5@macports.org> On Oct 5, 2009, at 09:37, kimuraw at macports.org wrote: > Revision: 58796 > http://trac.macports.org/changeset/58796 > Author: kimuraw at macports.org > Date: 2009-10-05 07:37:14 -0700 (Mon, 05 Oct 2009) > Log Message: > ----------- > ruby/rb-cocoa: fix #21764, > install fails with xargs from findutils+with_default_names FYI, the +with_default_names variants are on their way out. See discussion on the list: http://lists.macosforge.org/pipermail/macports-dev/2009-September/010109.html So this won't be a problem anymore soon. From jmr at macports.org Mon Oct 5 19:24:09 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 06 Oct 2009 13:24:09 +1100 Subject: [58794] trunk/dports/_resources/port1.0/group/archcheck-1.0.tcl In-Reply-To: References: <20091005141140.ECC9E28FB559@beta.macosforge.org> Message-ID: <4ACAAA49.9030507@macports.org> On 2009-10-6 11:30, Ryan Schmidt wrote: > Mmm, yes, because the port might modify configure.build_arch or > configure.universal_archs, right? But the port can't modify build_arch > or universal_archs? You can technically modify any variable with 'set', but you're not really meant to. The configure.* ones are actual options. > What's the significance of checking [variant_exists universal]? If the > variant doesn't exist, then [variant_isset universal] will be false, > won't it? Or does it cause some kind of exception to check whether a > nonexistent variant is set? [variant_isset foo] is true if +foo is on the command line or in variants.conf, independent of whether the port actually has a foo variant. [variant_exists foo] is only true if it is run after the foo variant is defined. Usually this means it should only be used inside a phase. Of course, you usually don't need to use it outside of portgroups and base code, since when you write a portfile you aren't really going to test whether variants are set unless you know the port has them. - Josh From talklists at newgeo.com Tue Oct 6 15:05:05 2009 From: talklists at newgeo.com (Scott Haneda) Date: Tue, 6 Oct 2009 15:05:05 -0700 Subject: php values Message-ID: <50DBBD21-D456-4BF2-8AEF-61C4F6CDEEAD@newgeo.com> Thought I would post this here first, if this is the wrong place, any ideas on the best place to get an answer... If I put this in a virtual host container in httpd.conf php will be off php_value engine off This will not turn it on, and the request for the file will download the file. php_value engine on Removing the setting turns on php. I would like to have a httpd.conf default, that has php off, and then over-ride it to "on" for specific sites. Does anyone remember if pre 5.3 an "on" setting worked, or is the idea. I can not seem to even find the docs on this setting with regard to 5.3 -- Scott * If you contact me off list replace talklists@ with scott@ * From brad at pixilla.com Tue Oct 6 15:14:29 2009 From: brad at pixilla.com (Bradley Giesbrecht) Date: Tue, 6 Oct 2009 15:14:29 -0700 Subject: php values In-Reply-To: <50DBBD21-D456-4BF2-8AEF-61C4F6CDEEAD@newgeo.com> References: <50DBBD21-D456-4BF2-8AEF-61C4F6CDEEAD@newgeo.com> Message-ID: <07DE617A-F4D5-4577-A8A9-2716BC6B8F80@pixilla.com> I haven't tried what you want to do but look at AllowOverride and php_admin_value. On Oct 6, 2009, at 3:05 PM, Scott Haneda wrote: > Thought I would post this here first, if this is the wrong place, > any ideas on the best place to get an answer... > > If I put this in a virtual host container in httpd.conf php will be > off > php_value engine off > > This will not turn it on, and the request for the file will download > the file. > php_value engine on > > Removing the setting turns on php. > > I would like to have a httpd.conf default, that has php off, and > then over-ride it to "on" for specific sites. Does anyone remember > if pre 5.3 an "on" setting worked, or is the idea. > > I can not seem to even find the docs on this setting with regard to > 5.3 > -- > Scott * If you contact me off list replace talklists@ with scott@ * > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From talklists at newgeo.com Tue Oct 6 17:40:59 2009 From: talklists at newgeo.com (Scott Haneda) Date: Tue, 6 Oct 2009 17:40:59 -0700 Subject: php values In-Reply-To: <07DE617A-F4D5-4577-A8A9-2716BC6B8F80@pixilla.com> References: <50DBBD21-D456-4BF2-8AEF-61C4F6CDEEAD@newgeo.com> <07DE617A-F4D5-4577-A8A9-2716BC6B8F80@pixilla.com> Message-ID: <9FBEEEBD-6CA8-4441-BF80-FF199EED2D67@newgeo.com> I am getting it to work, just not entirely. It seems it likes INT better, or checking for 1, or anything that is not 1. Setting a global to 0/off, where it is always off, that does not seem to work though. -- Scott * If you contact me off list replace talklists@ with scott@ * On Oct 6, 2009, at 3:14 PM, Bradley Giesbrecht wrote: > I haven't tried what you want to do but look at AllowOverride and > php_admin_value. > > On Oct 6, 2009, at 3:05 PM, Scott Haneda wrote: > >> Thought I would post this here first, if this is the wrong place, >> any ideas on the best place to get an answer... >> >> If I put this in a virtual host container in httpd.conf php will be >> off >> php_value engine off >> >> This will not turn it on, and the request for the file will >> download the file. >> php_value engine on >> >> Removing the setting turns on php. >> >> I would like to have a httpd.conf default, that has php off, and >> then over-ride it to "on" for specific sites. Does anyone remember >> if pre 5.3 an "on" setting worked, or is the idea. >> >> I can not seem to even find the docs on this setting with regard to >> 5.3 >> -- >> Scott * If you contact me off list replace talklists@ with scott@ * >> >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From akitada at macports.org Wed Oct 7 10:09:29 2009 From: akitada at macports.org (Akira Kitada) Date: Thu, 8 Oct 2009 02:09:29 +0900 Subject: Future of setuptools and distribute in MacPorts Message-ID: <90bb445a0910071009n6cd810e6gcb1ec9f25fae9749@mail.gmail.com> Hi, There has been a long discussion at Python-Dev mailing list about setuptools and distribute. setuptools is a Python package for building module and has been widely used in Python world. It's really popular but known as rather 'closed'; Only a few can work on the code and there're bug ports in the tracker. Tarek Ziad?, one of the Python committer thought this is not right and started his setuptools fork project, 'Distribute'. Distribute is compatible with setuptools, just better. The community is active and lots of bugs in setuptools are fixed and it even runs in Python 3.x. A few days ago, Python 2.6.3 was released and the found that it does not work well with setuptools, where as Distribute works file with it. Lots of reports have been submitted to Python list but setuptools hasn't updated still. So, I think it's clear that we need to have Distribute in MacPorts, but how? Gentoo, for example, provide Distribute under the name of 'setuptools'. Is this a right solution for MacPorts? I personally think that's the way, because Distribute is just another name of setuptools with bug fixes and the two cannot be installed at the same time and MacPorts's dependency system does not allow us to do that other than treating both in the same port name. Any suggestions would be appreciated. Thanks. From ryandesign at macports.org Wed Oct 7 13:19:03 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 7 Oct 2009 15:19:03 -0500 Subject: Future of setuptools and distribute in MacPorts In-Reply-To: <90bb445a0910071009n6cd810e6gcb1ec9f25fae9749@mail.gmail.com> References: <90bb445a0910071009n6cd810e6gcb1ec9f25fae9749@mail.gmail.com> Message-ID: On Oct 7, 2009, at 12:09, Akira Kitada wrote: > There has been a long discussion at Python-Dev mailing list about > setuptools and distribute. > > setuptools is a Python package for building module and has been widely > used in Python world. > It's really popular but known as rather 'closed'; Only a few can work > on the code and there're bug ports > in the tracker. Tarek Ziad?, one of the Python committer thought this > is not right and started > his setuptools fork project, 'Distribute'. > > Distribute is compatible with setuptools, just better. The community > is active and lots of bugs in > setuptools are fixed and it even runs in Python 3.x. > > A few days ago, Python 2.6.3 was released and the found that it does > not work well with setuptools, > where as Distribute works file with it. > Lots of reports have been submitted to Python list but setuptools > hasn't updated still. > > So, I think it's clear that we need to have Distribute in MacPorts, > but how? > Gentoo, for example, provide Distribute under the name of > 'setuptools'. > Is this a right solution for MacPorts? I personally think that's the > way, because > Distribute is just another name of setuptools with bug fixes and the > two cannot be > installed at the same time and MacPorts's dependency system does not > allow us > to do that other than treating both in the same port name. py26-distribute was recently added to MacPorts. Ports can declare conflicts with other ports now, as of MacPorts 1.8.0. py26-distribute does declare that it conflicts with py26- setuptools. We could modify all ports that currently depend on py26-setuptools so that they could work with either py26-setuptools or py26-distribute, by using a path:-style dependency instead of a port:-style one. Or is py26-distribute a superset of py26-setuptools, to be preferred in all cases? From blb at macports.org Wed Oct 7 13:21:31 2009 From: blb at macports.org (Bryan Blackburn) Date: Wed, 7 Oct 2009 14:21:31 -0600 Subject: Future of setuptools and distribute in MacPorts In-Reply-To: <90bb445a0910071009n6cd810e6gcb1ec9f25fae9749@mail.gmail.com> References: <90bb445a0910071009n6cd810e6gcb1ec9f25fae9749@mail.gmail.com> Message-ID: <20091007202131.GF480@ninagal.withay.com> On Thu, Oct 08, 2009 at 02:09:29AM +0900, Akira Kitada said: > Hi, > > There has been a long discussion at Python-Dev mailing list about > setuptools and distribute. > > setuptools is a Python package for building module and has been widely > used in Python world. > It's really popular but known as rather 'closed'; Only a few can work > on the code and there're bug ports > in the tracker. Tarek Ziad?, one of the Python committer thought this > is not right and started > his setuptools fork project, 'Distribute'. > > Distribute is compatible with setuptools, just better. The community > is active and lots of bugs in > setuptools are fixed and it even runs in Python 3.x. > > A few days ago, Python 2.6.3 was released and the found that it does > not work well with setuptools, > where as Distribute works file with it. > Lots of reports have been submitted to Python list but setuptools > hasn't updated still. I patched py26-setuptools in r58886 to deal with 2.6.3's changed distutils, so as long as you have 0.6c9_1 you should be fine. > > So, I think it's clear that we need to have Distribute in MacPorts, but how? > Gentoo, for example, provide Distribute under the name of 'setuptools'. > Is this a right solution for MacPorts? I personally think that's the > way, because > Distribute is just another name of setuptools with bug fixes and the > two cannot be > installed at the same time and MacPorts's dependency system does not allow us > to do that other than treating both in the same port name. Moving over to distribute is one possibility, but the discussion on (at least) distutils-sig seems like the python community hasn't quite decided on where things are going yet...at least with the patched setuptools things should still work as well as they have until we have a clearer overall idea of where things will be going. Note that I also added py26-distribute, but as you note it does conflict with py26-setuptools, so moving to it would be painful. Maybe it can be the preferred one for py27 ports? Bryan > > Any suggestions would be appreciated. > Thanks. From vince at macports.org Wed Oct 7 13:34:02 2009 From: vince at macports.org (vincent habchi) Date: Wed, 7 Oct 2009 22:34:02 +0200 Subject: Future of setuptools and distribute in MacPorts In-Reply-To: <20091007202131.GF480@ninagal.withay.com> References: <90bb445a0910071009n6cd810e6gcb1ec9f25fae9749@mail.gmail.com> <20091007202131.GF480@ninagal.withay.com> Message-ID: <62670FBA-A61E-4303-AF7B-3CEF143C16E6@macports.org> Le 7 oct. 2009 ? 22:21, Bryan Blackburn a ?crit : > preferred one for py27 ports? Are you sure there will be a python 2.7? I thought 2.6 was the last one in the 2 branch. Vincent From stechert at gmail.com Wed Oct 7 13:45:48 2009 From: stechert at gmail.com (Andre Stechert) Date: Wed, 7 Oct 2009 13:45:48 -0700 Subject: Future of setuptools and distribute in MacPorts In-Reply-To: <20091007202131.GF480@ninagal.withay.com> References: <90bb445a0910071009n6cd810e6gcb1ec9f25fae9749@mail.gmail.com> <20091007202131.GF480@ninagal.withay.com> Message-ID: <12a697af0910071345p507b4ba5r10296b2f7edf5291@mail.gmail.com> > Moving over to distribute is one possibility, but the discussion on (at > least) distutils-sig seems like the python community hasn't quite decided on > where things are going yet...at least with the patched setuptools things > should still work as well as they have until we have a clearer overall idea > of where things will be going. I think Guido just made things a lot clearer: "I think at this point the community should not be forced wait for you to get a new supply of round tuits. The wait has been too long already. You can stay on in an advisory role, but I don't think it's reasonable to block development or decisions until you have time." http://mail.python.org/pipermail/python-dev/2009-October/092674.html and: "I'm saying that I don't expect setuptools 0.7 to appear before Tarek's Distribute is mature and in widespread use. IOW I support Tarek's fork and suggest nobody hold their breath waiting for setuptools 0.7." http://mail.python.org/pipermail/python-dev/2009-October/092678.html Cheers, Andre From akitada at macports.org Wed Oct 7 16:11:43 2009 From: akitada at macports.org (Akira Kitada) Date: Thu, 8 Oct 2009 08:11:43 +0900 Subject: Future of setuptools and distribute in MacPorts In-Reply-To: <62670FBA-A61E-4303-AF7B-3CEF143C16E6@macports.org> References: <90bb445a0910071009n6cd810e6gcb1ec9f25fae9749@mail.gmail.com> <20091007202131.GF480@ninagal.withay.com> <62670FBA-A61E-4303-AF7B-3CEF143C16E6@macports.org> Message-ID: <90bb445a0910071611ib8da978x8f597a0871bc68c1@mail.gmail.com> It seems it's likely to happen. http://mail.python.org/pipermail/python-dev/2009-September/092005.html On Thu, Oct 8, 2009 at 5:34 AM, vincent habchi wrote: > Le 7 oct. 2009 ? 22:21, Bryan Blackburn a ?crit : > >> preferred one for py27 ports? > > Are you sure there will be a python 2.7? I thought 2.6 was the last one in > the 2 branch. > > Vincent > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From akitada at macports.org Wed Oct 7 16:22:59 2009 From: akitada at macports.org (Akira Kitada) Date: Thu, 8 Oct 2009 08:22:59 +0900 Subject: Future of setuptools and distribute in MacPorts In-Reply-To: References: <90bb445a0910071009n6cd810e6gcb1ec9f25fae9749@mail.gmail.com> Message-ID: <90bb445a0910071622s44cb7da2h9043ef6a227367e1@mail.gmail.com> On Thu, Oct 8, 2009 at 5:19 AM, Ryan Schmidt wrote: > > py26-distribute was recently added to MacPorts. > > Ports can declare conflicts with other ports now, as of MacPorts 1.8.0. > py26-distribute does declare that it conflicts with py26-setuptools. Thanks for the tip. I couldn't find it in MacPorts Guide so I thought it isn't. > We could modify all ports that currently depend on py26-setuptools so that > they could work with either py26-setuptools or py26-distribute, by using a > path:-style dependency instead of a port:-style one. Or is py26-distribute a > superset of py26-setuptools, to be preferred in all cases? Yes Distribute 0.6.x is better setuptools. If you find bugs in Distribute it will be fixed in upstream within a reasonable time. Guido also said he supports Distribute. From ryandesign at macports.org Wed Oct 7 16:27:47 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 7 Oct 2009 18:27:47 -0500 Subject: Future of setuptools and distribute in MacPorts In-Reply-To: <90bb445a0910071622s44cb7da2h9043ef6a227367e1@mail.gmail.com> References: <90bb445a0910071009n6cd810e6gcb1ec9f25fae9749@mail.gmail.com> <90bb445a0910071622s44cb7da2h9043ef6a227367e1@mail.gmail.com> Message-ID: On Oct 7, 2009, at 18:22, Akira Kitada wrote: > On Thu, Oct 8, 2009 at 5:19 AM, Ryan Schmidt wrote: > >> Ports can declare conflicts with other ports now, as of MacPorts >> 1.8.0. >> py26-distribute does declare that it conflicts with py26-setuptools. > > Thanks for the tip. I couldn't find it in MacPorts Guide so I > thought it isn't. The guide hasn't been updated in awhile. It's probably missing most of what went into MacPorts 1.8.0. Check the MacPorts ChangeLog or NEWS files to see what else is new. From jeremy at lavergne.gotdns.org Wed Oct 7 17:11:40 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 08 Oct 2009 00:11:40 -0000 Subject: confusion in base regarding [option os.arch] and ${os.arch} Message-ID: reading through base, it looks like os.arch is set to something based on its original value, while that original value is actually used as os_platform (and os.platform). if this is the case, those changes were never ported into port[un]archive.tcl. i don't understand how to reference platform correctly from there, as it seems that the values are different when they're pulled from [option os.arch] versus $ {os.arch} any care to shed light on this for a newbie tcl'er? what i essentially want to do is change archive.fulldestpath from [file join ${archive.destpath} [option os.platform] [option os.arch]] to [file join ${archive.destpath} [option os.platform] ${os.arch}] where os.arch is x86_64 or what have you, instead of option os.arch's i386 if i understood the transforms in portmain.tcl then that's what should be done here. incidentally, after this one change we can actually do binary distribution via archivemode From ryandesign at macports.org Wed Oct 7 17:34:57 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 7 Oct 2009 19:34:57 -0500 Subject: confusion in base regarding [option os.arch] and ${os.arch} In-Reply-To: References: Message-ID: <77306B2B-F562-433F-A7C6-FCD7D000B689@macports.org> On Oct 7, 2000, at 19:11, Jeremy Lavergne wrote: > reading through base, it looks like os.arch is set to something > based on > its original value, while that original value is actually used as > os_platform (and os.platform). if this is the case, those changes were > never ported into port[un]archive.tcl. i don't understand how to > reference platform correctly from there, as it seems that the > values are > different when they're pulled from [option os.arch] versus $ > {os.arch} > > any care to shed light on this for a newbie tcl'er? > > what i essentially want to do is change archive.fulldestpath from > [file > join ${archive.destpath} [option os.platform] [option os.arch]] to > [file > join ${archive.destpath} [option os.platform] ${os.arch}] where > os.arch > is x86_64 or what have you, instead of option os.arch's i386 > > if i understood the transforms in portmain.tcl then that's what should > be done here. incidentally, after this one change we can actually do > binary distribution via archivemode I would think ${os.arch} and [option os.arch] refer to the same variable, and that the syntax difference relates to where in the code you're accessing it from. When does os.arch seem to be x86_64? As far as I can tell, the only possible values for os.arch should be "i386" and "powerpc". I recently corrected this in the Guide: http://guide.macports.org/#reference.variables Perhaps you're thinking of configure.build_arch which could be "i386", "x86_64", "ppc" or "ppc64"? From jeremy at lavergne.gotdns.org Wed Oct 7 18:31:42 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 7 Oct 2009 21:31:42 -0400 Subject: confusion in base regarding [option os.arch] and ${os.arch} In-Reply-To: <77306B2B-F562-433F-A7C6-FCD7D000B689@macports.org> References: <77306B2B-F562-433F-A7C6-FCD7D000B689@macports.org> Message-ID: <4186E4A8-36CB-4E07-983D-A6B9787AC7AE@lavergne.gotdns.org> >> reading through base, it looks like os.arch is set to something >> based on >> its original value, while that original value is actually used as >> os_platform (and os.platform). if this is the case, those changes >> were >> never ported into port[un]archive.tcl. i don't understand how to >> reference platform correctly from there, as it seems that the >> values are >> different when they're pulled from [option os.arch] versus $ >> {os.arch} >> >> any care to shed light on this for a newbie tcl'er? >> >> what i essentially want to do is change archive.fulldestpath from >> [file >> join ${archive.destpath} [option os.platform] [option os.arch]] >> to [file >> join ${archive.destpath} [option os.platform] ${os.arch}] where >> os.arch >> is x86_64 or what have you, instead of option os.arch's i386 >> >> if i understood the transforms in portmain.tcl then that's what >> should >> be done here. incidentally, after this one change we can actually do >> binary distribution via archivemode > > I would think ${os.arch} and [option os.arch] refer to the same > variable, and that the syntax difference relates to where in the > code you're accessing it from. > > When does os.arch seem to be x86_64? As far as I can tell, the only > possible values for os.arch should be "i386" and "powerpc". I > recently corrected this in the Guide: > > http://guide.macports.org/#reference.variables > > Perhaps you're thinking of configure.build_arch which could be > "i386", "x86_64", "ppc" or "ppc64"? Seems I was confused. Does anyone care to check my changes? This patch enables the use of build_arch for the portarchive mode naming schemes. This includes the directory and the portion of the archive name involving the arch. It works for me, but I only have an x86_64 to test on. Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: use-arch-for-archivemode.patch Type: application/octet-stream Size: 3366 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4024 bytes Desc: not available URL: From ryandesign at macports.org Wed Oct 7 18:43:27 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 7 Oct 2009 20:43:27 -0500 Subject: confusion in base regarding [option os.arch] and ${os.arch} In-Reply-To: <4186E4A8-36CB-4E07-983D-A6B9787AC7AE@lavergne.gotdns.org> References: <77306B2B-F562-433F-A7C6-FCD7D000B689@macports.org> <4186E4A8-36CB-4E07-983D-A6B9787AC7AE@lavergne.gotdns.org> Message-ID: On Oct 7, 2009, at 20:31, Jeremy Lavergne wrote: > Does anyone care to check my changes? This patch enables the use of > build_arch for the portarchive mode naming schemes. This includes > the directory and the portion of the archive name involving the arch. It looks like a simple enough change to me. But I'm not familiar enough with base to understand why the [option os.arch] syntax was used to read the variable instead of ${os.arch} so I don't know whether perhaps that syntax might be needed now in some places to read configure.build_arch. > It works for me, but I only have an x86_64 to test on. You could create a second MacPorts installation in a different prefix, and set build_arch to i386 in macports.conf, and see if i386 works properly. From howarth at bromo.med.uc.edu Wed Oct 7 20:41:54 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Wed, 7 Oct 2009 23:41:54 -0400 Subject: change in system call in 1.8.1? Message-ID: <20091008034154.GA23661@bromo.med.uc.edu> I noticed tonight that my proposed packaging for pymol was broken under MacPorts 1.8.1. http://trac.macports.org/ticket/21376 In particular, the instances of... system "cd setup; cp Rules.osx-fink ../Rules.delsci" system "make -f Makefile.delsci" can no longer find the files Rules.osx-fink and Makefile.delsci. I now have to reformulate this as... system "cd ${worksrcpath}/setup; cp Rules.osx-fink ../Rules.delsci" system "cd ${worksrcpath}; make -f Makefile.delsci" Is this expected behavior in MacPorts 1.8.1? Jack From howarth at bromo.med.uc.edu Wed Oct 7 20:49:23 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Wed, 7 Oct 2009 23:49:23 -0400 Subject: python failures in MacPorts 1.8.1? Message-ID: <20091008034923.GA23690@bromo.med.uc.edu> I have found that pymol 1.2r1 as built with my proposed packaging... http://trac.macports.org/ticket/21376 no longer runs under current MacPorts 1.8.1. The pymol program now exits with the text... [Macintosh-2:~] howarth% pymol PyMOL(TM) Molecular Graphics System, Version 1.2r1. Copyright (C) 2009 by DeLano Scientific LLC. All Rights Reserved. Created by Warren L. DeLano, Ph.D. PyMOL is user-supported open-source software. Although some versions are freely available, PyMOL is not in the public domain. If PyMOL is helpful in your work or study, then please volunteer support for our ongoing efforts to create open and affordable scientific software by purchasing a PyMOL Maintenance and/or Support subscription. More information can be found at "http://www.pymol.org". Enter "help" for a list of commands. Enter "help " for information on a specific command. Hit ESC anytime to toggle between text and graphics. OpenGL graphics engine: GL_VENDOR: ATI Technologies Inc. GL_RENDERER: ATI Radeon X1600 OpenGL Engine GL_VERSION: 2.0 ATI-1.6.2 Detected 2 CPU cores. Enabled multithreaded rendering. OpenGL quad-buffer stereo 3D detected and enabled. Tcl_WaitForEvent: CFRunLoop finished Abort under Snow Leopard. This also produces an error alert titled "Problem Report for Python" with the text... Process: Python [3845] Path: /opt/local/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python Identifier: Python Version: ??? (???) Code Type: X86-64 (Native) Parent Process: tcsh [3841] Date/Time: 2009-10-07 23:39:58.207 -0400 OS Version: Mac OS X 10.6.1 (10B504) Report Version: 6 Interval Since Last Report: 868 sec Crashes Since Last Report: 1 Per-App Crashes Since Last Report: 1 Anonymous UUID: 4F72F3F8-36E0-4BF0-846B-6D9C98C422E1 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Crashed Thread: 2 Application Specific Information: abort() called Thread 0: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x00007fff819c09f2 select$DARWIN_EXTSN + 10 1 _cmd.so 0x0000000101082ef1 PSleepUnlocked + 65 2 _cmd.so 0x0000000101277662 MainBusyIdle + 818 3 libglut.3.dylib 0x00000001004c9c06 glutMainLoop + 242 4 _cmd.so 0x00000001012794ce was_main + 542 5 _cmd.so 0x000000010123fcee CmdRunPyMOL + 110 6 org.python.python 0x0000000100098cee PyEval_EvalFrameEx + 23390 7 org.python.python 0x0000000100099aff PyEval_EvalCodeEx + 1935 8 org.python.python 0x0000000100097bd0 PyEval_EvalFrameEx + 19008 9 org.python.python 0x0000000100099aff PyEval_EvalCodeEx + 1935 10 org.python.python 0x0000000100099c26 PyEval_EvalCode + 54 11 org.python.python 0x00000001000bdd60 PyRun_FileExFlags + 256 12 org.python.python 0x00000001000bdfe8 PyRun_SimpleFileExFlags + 440 13 org.python.python 0x00000001000cad2b Py_Main + 2747 14 org.python.python 0x0000000100000f14 0x100000000 + 3860 Thread 1: Dispatch queue: com.apple.libdispatch-manager 0 libSystem.B.dylib 0x00007fff81995b16 kevent + 10 1 libSystem.B.dylib 0x00007fff81997a19 _dispatch_mgr_invoke + 154 2 libSystem.B.dylib 0x00007fff819976d6 _dispatch_queue_invoke + 195 3 libSystem.B.dylib 0x00007fff819971f6 _dispatch_worker_thread2 + 244 4 libSystem.B.dylib 0x00007fff81996b28 _pthread_wqthread + 353 5 libSystem.B.dylib 0x00007fff819969c5 start_wqthread + 13 Thread 2 Crashed: 0 libSystem.B.dylib 0x00007fff819f01de __semwait_signal_nocancel + 10 1 libSystem.B.dylib 0x00007fff819f00e0 nanosleep$NOCANCEL + 129 2 libSystem.B.dylib 0x00007fff81a4cac6 usleep$NOCANCEL + 57 3 libSystem.B.dylib 0x00007fff81a6c07c abort + 93 4 libtcl8.5.dylib 0x0000000113b432fd Tcl_PanicVA + 573 5 libtcl8.5.dylib 0x0000000113b433a2 Tcl_Panic + 162 6 libtcl8.5.dylib 0x0000000113b768f5 Tcl_WaitForEvent + 501 7 libtcl8.5.dylib 0x0000000113b402cb Tcl_DoOneEvent + 251 8 libtk8.5.dylib 0x000000011398fe8d Tk_UpdateObjCmd + 125 9 libtcl8.5.dylib 0x0000000113accfe2 TclEvalObjvInternal + 1314 10 libtcl8.5.dylib 0x0000000113ace122 Tcl_EvalObjv + 66 11 _tkinter.so 0x0000000101bf39bc Tkapp_Call + 172 12 org.python.python 0x0000000100098cee PyEval_EvalFrameEx + 23390 13 org.python.python 0x000000010009886f PyEval_EvalFrameEx + 22239 14 org.python.python 0x0000000100099aff PyEval_EvalCodeEx + 1935 15 org.python.python 0x0000000100097bd0 PyEval_EvalFrameEx + 19008 16 org.python.python 0x0000000100099aff PyEval_EvalCodeEx + 1935 17 org.python.python 0x000000010002ee8e function_call + 334 18 org.python.python 0x000000010000b74b PyObject_Call + 27 19 org.python.python 0x0000000100096cf2 PyEval_EvalFrameEx + 15202 20 org.python.python 0x000000010009886f PyEval_EvalFrameEx + 22239 21 org.python.python 0x000000010009886f PyEval_EvalFrameEx + 22239 22 org.python.python 0x0000000100099aff PyEval_EvalCodeEx + 1935 23 org.python.python 0x000000010002eef6 function_call + 438 24 org.python.python 0x000000010000b74b PyObject_Call + 27 25 org.python.python 0x0000000100014e6d instancemethod_call + 365 26 org.python.python 0x000000010000b74b PyObject_Call + 27 27 org.python.python 0x0000000100091f5f PyEval_CallObjectWithKeywords + 111 28 org.python.python 0x00000001000ccf6e t_bootstrap + 46 29 libSystem.B.dylib 0x00007fff819b5f66 _pthread_start + 331 30 libSystem.B.dylib 0x00007fff819b5e19 thread_start + 13 Thread 3: 0 libSystem.B.dylib 0x00007fff819c09f2 select$DARWIN_EXTSN + 10 1 libtcl8.5.dylib 0x0000000113b772ac NotifierThreadProc + 556 2 libSystem.B.dylib 0x00007fff819b5f66 _pthread_start + 331 3 libSystem.B.dylib 0x00007fff819b5e19 thread_start + 13 Thread 2 crashed with X86 Thread State (64-bit): rax: 0x000000000000003c rbx: 0x00000001138bf4d0 rcx: 0x00000001138bf488 rdx: 0x0000000000000001 rdi: 0x000000000000030b rsi: 0x0000000000000000 rbp: 0x00000001138bf4c0 rsp: 0x00000001138bf488 r8: 0x0000000000000000 r9: 0x0000000000989680 r10: 0x0000000000000001 r11: 0x0000000000000246 r12: 0x0000000000000000 r13: 0x0000000114f36d40 r14: 0x0000000113b89fd8 r15: 0x0000000000000000 rip: 0x00007fff819f01de rfl: 0x0000000000000247 cr2: 0x0000000114e730f8 Binary Images: 0x100000000 - 0x100000fff +org.python.python 2.5a0 (2.5alpha0) <9A559F4C-FB4D-CCD9-B7D2-20C494DF82AE> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python 0x100003000 - 0x100120fe7 +org.python.python 2.5a0 (2.5) /opt/local/Library/Frameworks/Python.framework/Versions/2.5/Python 0x1001ea000 - 0x1001ebff7 +time.so ??? (???) <96D2E4DE-AE1D-8D31-0F8A-FCB383C464E9> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/time.so 0x1001f1000 - 0x1001f4fff +collections.so ??? (???) <82CCE2A6-E12E-6538-F2C1-B5B8F12A7EBE> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/collections.so 0x1001fa000 - 0x1001fbff7 +math.so ??? (???) <1BC92A5B-665A-6276-7782-BEA77384F9BE> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/math.so 0x100470000 - 0x100473ff7 +strop.so ??? (???) <5DF599B7-82D5-8562-0C89-CC52C144275D> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/strop.so 0x1004b8000 - 0x1004d6fef +libglut.3.dylib ??? (???) /opt/local/lib/libglut.3.dylib 0x100523000 - 0x100550fef +libGL.1.dylib ??? (???) <75A7A40D-2C80-1340-2C29-4E4777ED83FB> /opt/local/lib/libGL.1.dylib 0x100584000 - 0x1005e8fef +libGLU.1.dylib ??? (???) <0A7E4732-D2AA-30DD-9041-0262CC349AF0> /opt/local/lib/libGLU.1.dylib 0x10061e000 - 0x10063ffe7 +libpng12.0.dylib ??? (???) <6AEA3E7D-66BE-456D-8390-D6178A03ED0D> /opt/local/lib/libpng12.0.dylib 0x100646000 - 0x100658fe7 +libz.1.dylib ??? (???) <38470C78-F4F9-8278-23E6-5C9B35FE48F1> /opt/local/lib/libz.1.dylib 0x10065c000 - 0x10077ffff +libX11.6.dylib ??? (???) /opt/local/lib/libX11.6.dylib 0x1007a3000 - 0x1007b1fff +libXext.6.dylib ??? (???) <4850D888-0507-2E07-D8D6-92C57D39132A> /opt/local/lib/libXext.6.dylib 0x1007b7000 - 0x1007c9fff +libXmu.6.dylib ??? (???) <0102CF2E-560F-6437-2C41-2D5DFBEF5966> /opt/local/lib/libXmu.6.dylib 0x1007d2000 - 0x1007defff +libXi.6.dylib ??? (???) /opt/local/lib/libXi.6.dylib 0x1007e2000 - 0x1007effff libXplugin.1.dylib ??? (???) <10436E5D-C8AE-9861-9342-4B3F651F1094> /usr/lib/libXplugin.1.dylib 0x1007f9000 - 0x1007fafff +libXau.6.dylib ??? (???) <7553666F-7E62-1F16-7616-2568C9BD4148> /opt/local/lib/libXau.6.dylib 0x101000000 - 0x101382ff7 +_cmd.so ??? (???) <520DDC6D-6B91-683F-8725-FCC833EFCF82> /opt/local/lib/pymol/modules/pymol/_cmd.so 0x101429000 - 0x10142cfff +libXdmcp.6.dylib ??? (???) <74E41544-A87E-9757-4502-A18623E9850D> /opt/local/lib/libXdmcp.6.dylib 0x10142f000 - 0x10147cfe7 +libXt.6.dylib ??? (???) <630C9716-F11A-566B-96F1-7D53B8B80275> /opt/local/lib/libXt.6.dylib 0x101494000 - 0x101499ff7 +libSM.6.dylib ??? (???) <9CEEA346-4339-A296-1347-F11F1F1A7769> /opt/local/lib/libSM.6.dylib 0x10149d000 - 0x1014affff +libICE.6.dylib ??? (???) /opt/local/lib/libICE.6.dylib 0x101579000 - 0x10157dff7 +_struct.so ??? (???) <0C5ADDE5-5F2E-CCF7-5653-17991A4593CD> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_struct.so 0x101584000 - 0x101587ff7 +binascii.so ??? (???) /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/binascii.so 0x10158b000 - 0x10158cff7 +cStringIO.so ??? (???) /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/cStringIO.so 0x101591000 - 0x1015a0ff7 +cPickle.so ??? (???) <2E000BAA-BA80-E7C5-17F3-76BC50A25419> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/cPickle.so 0x1015e8000 - 0x1015e9fff +_random.so ??? (???) <8B521E26-7308-6C99-75DE-480A819B16A4> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_random.so 0x1015ed000 - 0x1015f0ff7 +operator.so ??? (???) <0F141405-CDA4-3F42-773F-0C0F32F9F19E> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/operator.so 0x101bed000 - 0x101bf5fff +_tkinter.so ??? (???) <90A0B545-5B46-51B7-821A-278F908BD33C> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_tkinter.so 0x101d11000 - 0x101d12ff7 +select.so ??? (???) <3B297682-5E60-ADCB-7FD9-386954FAA33E> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/select.so 0x101d16000 - 0x101d17ff7 +fcntl.so ??? (???) <5FEA49F1-A80A-BF4F-BC85-215BD135B17A> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/fcntl.so 0x101d1a000 - 0x101d1bff7 +icglue.so ??? (???) <06096509-B62F-5D93-5F38-3FC5BCF838B5> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/icglue.so 0x101d1f000 - 0x101d22ff7 +_Res.so ??? (???) <91C2D6D2-E682-3D5B-8F12-6BC2F55A38A2> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_Res.so 0x101d28000 - 0x101d2dfff +_File.so ??? (???) <176296CC-4196-F58C-AAAB-55304BC05182> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_File.so 0x101d40000 - 0x101d47fff +_socket.so ??? (???) <51118F86-39ED-72D5-7485-95ABF0102A74> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_socket.so 0x101d51000 - 0x101d53ff7 +_ssl.so ??? (???) <734D6095-0B5E-EF2F-1E3E-41E18409354D> /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/_ssl.so 0x101d83000 - 0x101da2fff GLRendererFloat ??? (???) /System/Library/Frameworks/OpenGL.framework/Resources/GLRendererFloat.bundle/GLRendererFloat 0x101dfa000 - 0x101dfbfff +libXss.1.dylib ??? (???) <8140C539-7DB3-910C-066A-E6DA00849002> /opt/local/lib/libXss.1.dylib 0x101fd1000 - 0x101fe1fef +libXft.2.dylib ??? (???) /opt/local/lib/libXft.2.dylib 0x101fe7000 - 0x101feefff +libXrender.1.dylib ??? (???) /opt/local/lib/libXrender.1.dylib 0x101ff2000 - 0x101ff3ff7 +MacOS.so ??? (???) /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/MacOS.so 0x112900000 - 0x112a8bff7 GLEngine ??? (???) <3E2DEFB1-190A-FBAD-C48F-E90B45EED8A4> /System/Library/Frameworks/OpenGL.framework/Resources/GLEngine.bundle/GLEngine 0x112abb000 - 0x112dc7ff7 com.apple.ATIRadeonX1000GLDriver 1.6.2 (6.0.2) <411F1412-ED0A-5F59-4A8E-2C644C8FF48D> /System/Library/Extensions/ATIRadeonX1000GLDriver.bundle/Contents/MacOS/ATIRadeonX1000GLDriver 0x113365000 - 0x113384fff +libexpat.1.dylib ??? (???) /opt/local/lib/libexpat.1.dylib 0x11338b000 - 0x1133cafff +libssl.0.9.8.dylib ??? (???) <1A83209C-99E9-7667-D4F4-BEE849FE324C> /opt/local/lib/libssl.0.9.8.dylib 0x1133e5000 - 0x113413ff7 +libfontconfig.1.dylib ??? (???) /opt/local/lib/libfontconfig.1.dylib 0x113700000 - 0x11377dfe7 +libfreetype.6.dylib ??? (???) <6E0A434A-BEC7-777E-3A33-9CE7435811D7> /opt/local/lib/libfreetype.6.dylib 0x113980000 - 0x113a80fe7 +libtk8.5.dylib ??? (???) <1EC4E75E-E956-CD59-9D0E-E0929CC1557F> /opt/local/lib/libtk8.5.dylib 0x113abb000 - 0x113ba9fef +libtcl8.5.dylib ??? (???) <0F8E6C91-26EA-89E7-14BC-B29BCC364096> /opt/local/lib/libtcl8.5.dylib 0x113bcd000 - 0x113cc9ff7 +libiconv.2.dylib ??? (???) /opt/local/lib/libiconv.2.dylib 0x113f00000 - 0x114014fe7 +libcrypto.0.9.8.dylib ??? (???) /opt/local/lib/libcrypto.0.9.8.dylib 0x7fff5fc00000 - 0x7fff5fc3bdef dyld 132.1 (???) /usr/lib/dyld 0x7fff80003000 - 0x7fff80038ff7 libcups.2.dylib ??? (???) <1FE99C26-B845-F508-815A-5B2CF2CA5337> /usr/lib/libcups.2.dylib 0x7fff80039000 - 0x7fff80039ff7 com.apple.Accelerate 1.5 (Accelerate 1.5) /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate 0x7fff8003a000 - 0x7fff8008ffef com.apple.framework.familycontrols 2.0 (2.0) <2520A455-5487-1964-C5D9-D284699D2537> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls 0x7fff80090000 - 0x7fff8009dfff libCSync.A.dylib ??? (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib 0x7fff800e9000 - 0x7fff801eefe7 libGLProgrammability.dylib ??? (???) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib 0x7fff801ef000 - 0x7fff80521fef com.apple.CoreServices.CarbonCore 859.1 (859.1) <5712C4C1-B18B-88EE-221F-DA04A8EDA029> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore 0x7fff80547000 - 0x7fff8058dfe7 libvDSP.dylib ??? (???) <2DAA1591-8AE8-B411-7D01-68DE99C63CEE> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib 0x7fff80fce000 - 0x7fff80fe7fff com.apple.CFOpenDirectory 10.6 (10.6) <0F46E102-8B8E-0995-BA85-3D9608F0A30C> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory 0x7fff80fe8000 - 0x7fff810a4ff7 com.apple.CoreServices.OSServices 352 (352) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices 0x7fff810a5000 - 0x7fff810ecff7 com.apple.coreui 0.2 (112) /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI 0x7fff812d9000 - 0x7fff812f4ff7 com.apple.openscripting 1.3 (???) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting 0x7fff812f5000 - 0x7fff81313ff7 libPng.dylib ??? (???) <6A0E35B8-2E33-7C64-2B53-6F47F628DE7A> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib 0x7fff81314000 - 0x7fff813f8ff7 com.apple.DesktopServices 1.5.1 (1.5.1) <65D7E707-DBCA-5752-78EC-351DC88F3AE8> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv 0x7fff81406000 - 0x7fff81419fff libGL.dylib ??? (???) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib 0x7fff81425000 - 0x7fff814dafff com.apple.ink.framework 1.3 (104) <9B552E27-7E3F-6767-058A-C998E8F78692> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink 0x7fff814db000 - 0x7fff814dbff7 com.apple.ApplicationServices 38 (38) <10A0B9E9-4988-03D4-FC56-DDE231A02C63> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices 0x7fff8152e000 - 0x7fff81540fe7 libsasl2.2.dylib ??? (???) <76B83C8D-8EFE-4467-0F75-275648AFED97> /usr/lib/libsasl2.2.dylib 0x7fff8155d000 - 0x7fff815aefe7 com.apple.HIServices 1.8.0 (???) <113EEB8A-8EC6-9F86-EF46-4BA5C2CBF77C> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices 0x7fff8167b000 - 0x7fff81792fef libxml2.2.dylib ??? (???) <6D4C196C-B061-CBCD-AAFD-A21736A8425C> /usr/lib/libxml2.2.dylib 0x7fff81793000 - 0x7fff8179eff7 com.apple.speech.recognition.framework 3.10.10 (3.10.10) <7E2A89FC-0F18-1CCC-472E-AD0E2BC2DD4C> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition 0x7fff8197c000 - 0x7fff81b3aff7 libSystem.B.dylib ??? (???) <66102D4E-6C8B-77D0-6766-2A1788B20C6F> /usr/lib/libSystem.B.dylib 0x7fff81c64000 - 0x7fff81ce1fef libstdc++.6.dylib ??? (???) <35ECA411-2C08-FD7D-11B1-1B7A04921A5C> /usr/lib/libstdc++.6.dylib 0x7fff81ce2000 - 0x7fff81ce5ff7 com.apple.securityhi 4.0 (36638) <77F40B57-2D97-7AE5-1331-8945C71DFB57> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI 0x7fff81d25000 - 0x7fff81d28fff com.apple.help 1.3.1 (41) <54B79BA2-B71B-268E-8752-5C8EE00E49E4> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help 0x7fff81d5b000 - 0x7fff81e16ff7 libFontParser.dylib ??? (???) <8926E1B0-6D1E-502A-5028-1DCC57F6D6FA> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib 0x7fff81e25000 - 0x7fff81e2afff libGIF.dylib ??? (???) <0C112067-95FE-B9BC-C70C-64A46A277F34> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib 0x7fff81e2b000 - 0x7fff81ee1fe7 libobjc.A.dylib ??? (???) <261D97A3-225B-8A00-56AA-F9F27973063F> /usr/lib/libobjc.A.dylib 0x7fff81ee2000 - 0x7fff81f7cfe7 com.apple.ApplicationServices.ATS 4.0 (???) <76009EB5-037B-8A08-5AB5-18DA59559509> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS 0x7fff82215000 - 0x7fff822a5fff com.apple.SearchKit 1.3.0 (1.3.0) <4175DC31-1506-228A-08FD-C704AC9DF642> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit 0x7fff822a6000 - 0x7fff822acff7 IOSurface ??? (???) <8E0EE904-59D1-9AA0-CE55-B1777F4BAEC1> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface 0x7fff822ad000 - 0x7fff822aeff7 com.apple.audio.units.AudioUnit 1.6 (1.6) <7A51FBCE-7907-28A0-B2D2-CAADA78F2913> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit 0x7fff822af000 - 0x7fff822c3ff7 com.apple.speech.synthesis.framework 3.10.35 (3.10.35) <621B7415-A0B9-07A7-F313-36BEEDD7B132> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis 0x7fff822c4000 - 0x7fff82311ff7 libauto.dylib ??? (???) <8658DB85-C611-1212-44E5-5B2539018FA0> /usr/lib/libauto.dylib 0x7fff8234e000 - 0x7fff8241afff com.apple.CFNetwork 454.4 (454.4) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork 0x7fff8241b000 - 0x7fff82499fef com.apple.audio.CoreAudio 3.2.0 (3.2) <51E4AA76-3A8A-2B78-95D2-582501421A4E> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio 0x7fff8249a000 - 0x7fff8253afff com.apple.LaunchServices 360.3 (360.3) <02FFE657-CC7A-5266-F06E-8732E28F70A9> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices 0x7fff82600000 - 0x7fff82631fff libGLImage.dylib ??? (???) <4F318A3E-20C1-D846-2B36-62451A3241F7> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib 0x7fff826cd000 - 0x7fff826e3fff com.apple.ImageCapture 6.0 (6.0) <5B5AF8FB-C12A-B51F-94FC-3EC4698E818E> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture 0x7fff8270d000 - 0x7fff82b50fef libLAPACK.dylib ??? (???) <0CC61C98-FF51-67B3-F3D8-C5E430C201A9> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib 0x7fff82b51000 - 0x7fff82b9bff7 com.apple.Metadata 10.6.0 (507.1) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata 0x7fff82b9c000 - 0x7fff82ba2ff7 com.apple.DiskArbitration 2.3 (2.3) <857F6E43-1EF4-7D53-351B-10DE0A8F992A> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration 0x7fff82e0d000 - 0x7fff82e0ffff com.apple.print.framework.Print 6.0 (237) <70DA9755-5DC1-716B-77E2-E42C5DAB85A2> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print 0x7fff82e10000 - 0x7fff82e10ff7 com.apple.Accelerate.vecLib 3.5 (vecLib 3.5) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib 0x7fff82e11000 - 0x7fff835035d7 com.apple.CoreGraphics 1.535.5 (???) <6599C41F-2D50-5E04-44E4-44FA90E022B5> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 0x7fff83504000 - 0x7fff83544fef com.apple.QD 3.31 (???) <0FA2713A-99BD-A96B-56AF-7DB0AB4927AD> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD 0x7fff8360d000 - 0x7fff83611ff7 libmathCommon.A.dylib ??? (???) <95718673-FEEE-B6ED-B127-BCDBDB60D4E5> /usr/lib/system/libmathCommon.A.dylib 0x7fff836b4000 - 0x7fff836c3fef com.apple.opengl 1.6.3 (1.6.3) <6318A188-B43D-E82F-C157-2E76331227BD> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL 0x7fff836c4000 - 0x7fff83713ff7 libTIFF.dylib ??? (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib 0x7fff837c9000 - 0x7fff83fd3fe7 libBLAS.dylib ??? (???) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 0x7fff84327000 - 0x7fff846bbff7 com.apple.QuartzCore 1.6.0 (226.0) <66E14771-C5F0-1415-0B7B-C45EE00C51A1> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore 0x7fff846bc000 - 0x7fff84719fef com.apple.framework.IOKit 2.0 (???) <65AA6170-12E3-BFB5-F982-E0C433610A1F> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x7fff8471a000 - 0x7fff84742fff com.apple.DictionaryServices 1.1 (1.1) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices 0x7fff84743000 - 0x7fff847cffef SecurityFoundation ??? (???) /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation 0x7fff847d0000 - 0x7fff847d7fff com.apple.OpenDirectory 10.6 (10.6) <72A65D76-7831-D31E-F1B3-9E48BF26A98B> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory 0x7fff847d8000 - 0x7fff847d8ff7 com.apple.vecLib 3.5 (vecLib 3.5) <5B072584-9579-F54F-180E-5D425B37E85C> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib 0x7fff84846000 - 0x7fff84848fff libRadiance.dylib ??? (???) <77F285E0-5D5E-A0B0-A89E-9332D6AB2867> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib 0x7fff84865000 - 0x7fff8487bfef libbsm.0.dylib ??? (???) <42D3023A-A1F7-4121-6417-FCC6B51B3E90> /usr/lib/libbsm.0.dylib 0x7fff84a01000 - 0x7fff84b10ff7 libcrypto.0.9.8.dylib ??? (???) /usr/lib/libcrypto.0.9.8.dylib 0x7fff84b11000 - 0x7fff84ccbfef com.apple.ImageIO.framework 3.0.0 (3.0.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO 0x7fff84ccc000 - 0x7fff84f4dfe7 com.apple.Foundation 6.6 (751) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 0x7fff84f4e000 - 0x7fff84f6ffff libresolv.9.dylib ??? (???) <01C7C750-7F6A-89B3-C586-5C50A839019E> /usr/lib/libresolv.9.dylib 0x7fff84fe4000 - 0x7fff84ff2ff7 libkxld.dylib ??? (???) <823B6BE6-E952-3B3C-3633-8F4D6C4606A8> /usr/lib/system/libkxld.dylib 0x7fff850fe000 - 0x7fff85122ff7 com.apple.CoreVideo 1.6.0 (43.0) /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo 0x7fff85153000 - 0x7fff853d7fff com.apple.security 6.0 (36910) /System/Library/Frameworks/Security.framework/Versions/A/Security 0x7fff85799000 - 0x7fff857daff7 com.apple.SystemConfiguration 1.10 (1.10) /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration 0x7fff857dd000 - 0x7fff857f2fff com.apple.LangAnalysis 1.6.5 (1.6.5) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis 0x7fff85ae1000 - 0x7fff85b3dfff libGLU.dylib ??? (???) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib 0x7fff85b3e000 - 0x7fff85b43ff7 com.apple.CommonPanels 1.2.4 (91) <4D84803B-BD06-D80E-15AE-EFBE43F93605> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels 0x7fff85b79000 - 0x7fff85bb4fef com.apple.AE 496 (496) <6AFD62E0-DD92-4F04-A73A-90224D80593D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE 0x7fff860ae000 - 0x7fff86188ff7 com.apple.vImage 4.0 (4.0) <354F34BF-B221-A3C9-2CA7-9BE5E14AD5AD> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage 0x7fff86189000 - 0x7fff86346fff libicucore.A.dylib ??? (???) <224721C0-EC21-94D0-6484-66C603C34CBE> /usr/lib/libicucore.A.dylib 0x7fff86991000 - 0x7fff86a45fef com.apple.ColorSync 4.6.0 (4.6.0) <080BEDDE-E7A4-F88D-928B-7501574A157B> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync 0x7fff86c53000 - 0x7fff86c73fef com.apple.DirectoryService.Framework 3.6 (621) <925EE208-03B2-B24A-3686-57EAFBDA5ADF> /System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService 0x7fff86e58000 - 0x7fff86ed5fe7 com.apple.CoreText 3.0.0 (???) <51175014-9F0C-7E96-FB6F-3DC5E446B92E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText 0x7fff87002000 - 0x7fff87005ff7 libCoreVMClient.dylib ??? (???) <3A41933A-5174-7516-37E0-8E06365BF3DA> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib 0x7fff87006000 - 0x7fff870b5fef edu.mit.Kerberos 6.5.8 (6.5.8) /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos 0x7fff870f5000 - 0x7fff8715ffe7 libvMisc.dylib ??? (???) <524DC30F-6A54-CCED-56D9-F57033B06E99> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib 0x7fff87160000 - 0x7fff87282ff7 com.apple.audio.toolbox.AudioToolbox 1.6 (1.6) <3CA3B481-9627-6F36-F2B8-C2763DEEB128> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox 0x7fff87283000 - 0x7fff872a4ff7 com.apple.opencl 11 (11) /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL 0x7fff876f7000 - 0x7fff877b0fff libsqlite3.dylib ??? (???) <5A15E12A-AE8F-1A36-BBC7-564E7D7AD0FB> /usr/lib/libsqlite3.dylib 0x7fff877b1000 - 0x7fff87924fef com.apple.CoreFoundation 6.6 (550) <04EC0CC2-6CE4-4EE0-03B9-6C5109398CB1> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff88487000 - 0x7fff88498fef libz.1.dylib ??? (???) <3A7A4C48-A4C8-A78A-8B87-C0DDF6601AC8> /usr/lib/libz.1.dylib 0x7fff88499000 - 0x7fff8849aff7 com.apple.TrustEvaluationAgent 1.0 (1) <4B6B7853-EDAC-08B7-3324-CA9A3802FAE2> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent 0x7fff8849b000 - 0x7fff884c6ff7 libxslt.1.dylib ??? (???) <87A0B228-B24A-C426-C3FB-B40D7258DD49> /usr/lib/libxslt.1.dylib 0x7fff884c7000 - 0x7fff884ccfff libGFXShared.dylib ??? (???) /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib 0x7fff8858f000 - 0x7fff8888cfef com.apple.HIToolbox 1.6.0 (???) <870B39B2-55BD-9C82-72EB-2E3470BD0E14> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox 0x7fff8888d000 - 0x7fff888dcff7 com.apple.DirectoryService.PasswordServerFramework 6.0 (6.0) <14FD0978-4BE0-336B-A19E-F388694583EB> /System/Library/PrivateFrameworks/PasswordServer.framework/Versions/A/PasswordServer 0x7fff888dd000 - 0x7fff88903fe7 libJPEG.dylib ??? (???) <52ACD177-F101-BEF5-E7CC-9131F8372D0A> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib 0x7fff88904000 - 0x7fff88913fff com.apple.NetFS 3.2 (3.2) <61E3D8BE-A529-20BF-1A11-026EC774820D> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS 0x7fff8893b000 - 0x7fff8893bff7 com.apple.CoreServices 44 (44) <210A4C56-BECB-E3E4-B6EE-7EC53E02265D> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 0x7fff88970000 - 0x7fff88970ff7 com.apple.Carbon 150 (152) <8D8CF535-90BE-691C-EC1B-63FBE2162C9B> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 0x7fff88971000 - 0x7fff889f5fff com.apple.print.framework.PrintCore 6.0 (312) <1F747E69-924D-8C5B-F318-C4828CC6E85D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore 0x7fff88b1e000 - 0x7fff88b34fff com.apple.MultitouchSupport.framework 200.20 (200.20) <96B8C66E-D84D-863B-CB1D-F7E005569706> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport 0x7fffffe00000 - 0x7fffffe01fff libSystem.B.dylib ??? (???) <66102D4E-6C8B-77D0-6766-2A1788B20C6F> /usr/lib/libSystem.B.dylib Model: MacBookPro2,1, BootROM MBP21.00A5.B08, 2 processors, Intel Core 2 Duo, 2.33 GHz, 3 GB, SMC 1.14f5 Graphics: ATI Radeon X1600, ATY,RadeonX1600, PCIe, 256 MB Memory Module: global_name AirPort: spairport_wireless_card_type_airport_extreme (0x168C, 0x87), Atheros 5416: 2.0.19.4 Bluetooth: Version 2.2.1f7, 2 service, 1 devices, 1 incoming serial ports Network Service: AirPort, AirPort, en1 Serial ATA Device: TOSHIBA MK2035GSS, 186.31 GB Parallel ATA Device: MATSHITADVD-R UJ-85J USB Device: Built-in iSight, 0x05ac (Apple Inc.), 0x8501, 0xfd400000 USB Device: IR Receiver, 0x05ac (Apple Inc.), 0x8240, 0x5d200000 USB Device: Bluetooth USB Host Controller, 0x05ac (Apple Inc.), 0x8205, 0x7d100000 USB Device: Apple Internal Keyboard / Trackpad, 0x05ac (Apple Inc.), 0x021a, 0x1d200000 USB Device: Apple Optical USB Mouse, 0x05ac (Apple Inc.), 0x0304, 0x1d100000 Is anyone else able to reproduce this? Jack From toby at macports.org Wed Oct 7 21:00:46 2009 From: toby at macports.org (Toby Peterson) Date: Wed, 7 Oct 2009 21:00:46 -0700 Subject: change in system call in 1.8.1? In-Reply-To: <20091008034154.GA23661@bromo.med.uc.edu> References: <20091008034154.GA23661@bromo.med.uc.edu> Message-ID: <74c219d30910072100k7a86e781l7fcb61ef4bbfa713@mail.gmail.com> Yes, r57784 - ports that make bad assumptions about working directory are now broken. Shouldn't be too many. - Toby On Wed, Oct 7, 2009 at 20:41, Jack Howarth wrote: > ? I noticed tonight that my proposed packaging for > pymol was broken under MacPorts 1.8.1. > > http://trac.macports.org/ticket/21376 > > In particular, the instances of... > > system "cd setup; cp Rules.osx-fink ../Rules.delsci" > system "make -f Makefile.delsci" > > can no longer find the files Rules.osx-fink and Makefile.delsci. > I now have to reformulate this as... > > system "cd ?${worksrcpath}/setup; cp Rules.osx-fink ../Rules.delsci" > system "cd ?${worksrcpath}; make -f Makefile.delsci" > > Is this expected behavior in MacPorts 1.8.1? > ? ? ? ? ? ?Jack > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From ryandesign at macports.org Wed Oct 7 21:02:23 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 7 Oct 2009 23:02:23 -0500 Subject: change in system call in 1.8.1? In-Reply-To: <20091008034154.GA23661@bromo.med.uc.edu> References: <20091008034154.GA23661@bromo.med.uc.edu> Message-ID: On Oct 7, 2009, at 22:41, Jack Howarth wrote: > I noticed tonight that my proposed packaging for > pymol was broken under MacPorts 1.8.1. > > http://trac.macports.org/ticket/21376 > > In particular, the instances of... > > system "cd setup; cp Rules.osx-fink ../Rules.delsci" > system "make -f Makefile.delsci" > > can no longer find the files Rules.osx-fink and Makefile.delsci. > I now have to reformulate this as... > > system "cd ${worksrcpath}/setup; cp Rules.osx-fink ../Rules.delsci" > system "cd ${worksrcpath}; make -f Makefile.delsci" > > Is this expected behavior in MacPorts 1.8.1? I'm not aware of changes relating to that in 1.8.1, but yes, it is true that you should not rely on the working directory being anything in particular when you call system, and should cd to whatever directory you need every time. Most ports use " && " instead of "; " as a separator but it doesn't matter much. From jeremy at lavergne.gotdns.org Wed Oct 7 21:35:55 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 8 Oct 2009 00:35:55 -0400 Subject: change in system call in 1.8.1? In-Reply-To: References: <20091008034154.GA23661@bromo.med.uc.edu> Message-ID: <00DFE2CD-3248-4E3C-8128-48656C18CB51@lavergne.gotdns.org> > Most ports use " && " instead of "; " as a separator but it doesn't > matter much. There is a very important difference. && will stop the chain of commands if one is found to be unsuccessful. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4024 bytes Desc: not available URL: From ryandesign at macports.org Wed Oct 7 21:38:29 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 7 Oct 2009 23:38:29 -0500 Subject: change in system call in 1.8.1? In-Reply-To: <00DFE2CD-3248-4E3C-8128-48656C18CB51@lavergne.gotdns.org> References: <20091008034154.GA23661@bromo.med.uc.edu> <00DFE2CD-3248-4E3C-8128-48656C18CB51@lavergne.gotdns.org> Message-ID: <07D4688C-427D-4D73-B724-82EE6838ED13@macports.org> On Oct 7, 2009, at 23:35, Jeremy Lavergne wrote: >> Most ports use " && " instead of "; " as a separator but it doesn't >> matter much. > > There is a very important difference. && will stop the chain of > commands if one is found to be unsuccessful. Yes, that's the difference. But presumably by the time a port author has produced a working port and committed it, it works, so there's not much difference anymore. From afb at macports.org Wed Oct 7 23:55:21 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 8 Oct 2009 08:55:21 +0200 Subject: confusion in base regarding [option os.arch] and ${os.arch} In-Reply-To: <4186E4A8-36CB-4E07-983D-A6B9787AC7AE@lavergne.gotdns.org> References: <77306B2B-F562-433F-A7C6-FCD7D000B689@macports.org> <4186E4A8-36CB-4E07-983D-A6B9787AC7AE@lavergne.gotdns.org> Message-ID: Jeremy Lavergne wrote: > Does anyone care to check my changes? This patch enables the use > of build_arch for the portarchive mode naming schemes. This > includes the directory and the portion of the archive name > involving the arch. > > It works for me, but I only have an x86_64 to test on. Regarding http://trac.macports.org/changeset/58977, While you are changing things, you might want to replace [option os.platform] with something that includes version, so that it'd look in e.g. "darwin/10" instead of in "darwin" ? http://lists.macosforge.org/pipermail/macports-dev/2007-July/002033.html This would not be so important for the local archives, but more for when retrieving remote archives - just that so far they have both been using the same directory structure... http://trac.macports.org/ticket/8571 --anders From jmr at macports.org Thu Oct 8 00:10:01 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 08 Oct 2009 18:10:01 +1100 Subject: confusion in base regarding [option os.arch] and ${os.arch} In-Reply-To: References: <77306B2B-F562-433F-A7C6-FCD7D000B689@macports.org> <4186E4A8-36CB-4E07-983D-A6B9787AC7AE@lavergne.gotdns.org> Message-ID: <4ACD9049.9060305@macports.org> On 2009-10-8 17:55, Anders F Bj?rklund wrote: > Jeremy Lavergne wrote: > >> Does anyone care to check my changes? This patch enables the use of >> build_arch for the portarchive mode naming schemes. This includes the >> directory and the portion of the archive name involving the arch. >> >> It works for me, but I only have an x86_64 to test on. > > Regarding http://trac.macports.org/changeset/58977, > > While you are changing things, you might want to replace > [option os.platform] with something that includes version, > so that it'd look in e.g. "darwin/10" instead of in "darwin" ? > > http://lists.macosforge.org/pipermail/macports-dev/2007-July/002033.html > > This would not be so important for the local archives, but > more for when retrieving remote archives - just that so far > they have both been using the same directory structure... > > http://trac.macports.org/ticket/8571 These are definitely changes that need to be made, but be aware that they need to fit in with the switch to registry2.0 (and subsequently actually recording all the relevant info in the registry) as well as the images-and-archives branch stuff (which I believe just needs code to migrate existing installations before it's ready to merge back to trunk). - Josh From afb at macports.org Thu Oct 8 01:34:34 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 8 Oct 2009 10:34:34 +0200 Subject: confusion in base regarding [option os.arch] and ${os.arch} In-Reply-To: <4ACD9049.9060305@macports.org> References: <77306B2B-F562-433F-A7C6-FCD7D000B689@macports.org> <4186E4A8-36CB-4E07-983D-A6B9787AC7AE@lavergne.gotdns.org> <4ACD9049.9060305@macports.org> Message-ID: Joshua Root wrote: >> While you are changing things, you might want to replace >> [option os.platform] with something that includes version, >> so that it'd look in e.g. "darwin/10" instead of in "darwin" ? > These are definitely changes that need to be made, but be aware that > they need to fit in with the switch to registry2.0 (and subsequently > actually recording all the relevant info in the registry) as well > as the > images-and-archives branch stuff (which I believe just needs code to > migrate existing installations before it's ready to merge back to > trunk). Just thought you might want to keep it in mind, for the change... (i.e. so that whoever is doing the switch and the merging is aware) Using ${os.platform} and ${os.arch} used to be enough information, but it probably needs more. Like the os release or the build arch. It needs to be fixed in the RPM packages as well, currently those are using "Requires: org.macports.darwin8" and no extra --target. It should probably set --target=x86_64 when doing the rpmbuild ? Otherwise it'll use %_build_platform, which is i386 (from uname). Still seems like a design flaw to have build_arch in the "configure" namespace, but that's another story. At least it's not "universal". --anders From jmr at macports.org Thu Oct 8 01:41:16 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 08 Oct 2009 19:41:16 +1100 Subject: confusion in base regarding [option os.arch] and ${os.arch} In-Reply-To: References: <77306B2B-F562-433F-A7C6-FCD7D000B689@macports.org> <4186E4A8-36CB-4E07-983D-A6B9787AC7AE@lavergne.gotdns.org> <4ACD9049.9060305@macports.org> Message-ID: <4ACDA5AC.2060008@macports.org> On 2009-10-8 19:34, Anders F Bj?rklund wrote: > Joshua Root wrote: > >>> While you are changing things, you might want to replace >>> [option os.platform] with something that includes version, >>> so that it'd look in e.g. "darwin/10" instead of in "darwin" ? > >> These are definitely changes that need to be made, but be aware that >> they need to fit in with the switch to registry2.0 (and subsequently >> actually recording all the relevant info in the registry) as well as the >> images-and-archives branch stuff (which I believe just needs code to >> migrate existing installations before it's ready to merge back to trunk). > > Just thought you might want to keep it in mind, for the change... > (i.e. so that whoever is doing the switch and the merging is aware) > Using ${os.platform} and ${os.arch} used to be enough information, > but it probably needs more. Like the os release or the build arch. Indeed. > It needs to be fixed in the RPM packages as well, currently those > are using "Requires: org.macports.darwin8" and no extra --target. > It should probably set --target=x86_64 when doing the rpmbuild ? > Otherwise it'll use %_build_platform, which is i386 (from uname). Right, probably --target=$build_arch. > Still seems like a design flaw to have build_arch in the "configure" > namespace, but that's another story. At least it's not "universal". That's another point; when a port is built universal, the archive needs to be tagged with the list of universal_archs instead of the build_arch. - Josh From ryandesign at macports.org Thu Oct 8 01:47:10 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 8 Oct 2009 03:47:10 -0500 Subject: confusion in base regarding [option os.arch] and ${os.arch} In-Reply-To: <4ACDA5AC.2060008@macports.org> References: <77306B2B-F562-433F-A7C6-FCD7D000B689@macports.org> <4186E4A8-36CB-4E07-983D-A6B9787AC7AE@lavergne.gotdns.org> <4ACD9049.9060305@macports.org> <4ACDA5AC.2060008@macports.org> Message-ID: <94FA2478-538A-449A-B806-A9890CDA2490@macports.org> On Oct 8, 2009, at 03:41, Joshua Root wrote: > On 2009-10-8 19:34, Anders F Bj?rklund wrote: > >> Still seems like a design flaw to have build_arch in the "configure" >> namespace, but that's another story. At least it's not "universal". > > That's another point; when a port is built universal, the archive > needs > to be tagged with the list of universal_archs instead of the > build_arch. I would tag it with both, just to be on the safe side. A poorly- written configure script could easily build a different universal binary on a PowerPC Mac than it would on an Intel Mac. It doesn't hurt to always record the arch of the machine that did the build, and might at some point prove useful. From jmr at macports.org Thu Oct 8 03:03:03 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 08 Oct 2009 21:03:03 +1100 Subject: confusion in base regarding [option os.arch] and ${os.arch} In-Reply-To: <94FA2478-538A-449A-B806-A9890CDA2490@macports.org> References: <77306B2B-F562-433F-A7C6-FCD7D000B689@macports.org> <4186E4A8-36CB-4E07-983D-A6B9787AC7AE@lavergne.gotdns.org> <4ACD9049.9060305@macports.org> <4ACDA5AC.2060008@macports.org> <94FA2478-538A-449A-B806-A9890CDA2490@macports.org> Message-ID: <4ACDB8D7.8060006@macports.org> On 2009-10-8 19:47, Ryan Schmidt wrote: > > On Oct 8, 2009, at 03:41, Joshua Root wrote: > >> On 2009-10-8 19:34, Anders F Bj?rklund wrote: >> >>> Still seems like a design flaw to have build_arch in the "configure" >>> namespace, but that's another story. At least it's not "universal". >> >> That's another point; when a port is built universal, the archive needs >> to be tagged with the list of universal_archs instead of the build_arch. > > I would tag it with both, just to be on the safe side. A poorly-written > configure script could easily build a different universal binary on a > PowerPC Mac than it would on an Intel Mac. It doesn't hurt to always > record the arch of the machine that did the build, and might at some > point prove useful. But the architecture of the machine that did the build has nothing to do with build_arch... - Josh From afb at macports.org Thu Oct 8 03:07:49 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 8 Oct 2009 12:07:49 +0200 Subject: confusion in base regarding [option os.arch] and ${os.arch} In-Reply-To: <94FA2478-538A-449A-B806-A9890CDA2490@macports.org> References: <77306B2B-F562-433F-A7C6-FCD7D000B689@macports.org> <4186E4A8-36CB-4E07-983D-A6B9787AC7AE@lavergne.gotdns.org> <4ACD9049.9060305@macports.org> <4ACDA5AC.2060008@macports.org> <94FA2478-538A-449A-B806-A9890CDA2490@macports.org> Message-ID: <0FB591BE-2419-4B72-988D-18FAB94121FB@macports.org> Ryan Schmidt wrote: > On Oct 8, 2009, at 03:41, Joshua Root wrote: > >> That's another point; when a port is built universal, the archive >> needs >> to be tagged with the list of universal_archs instead of the >> build_arch. > > I would tag it with both, just to be on the safe side. A poorly- > written configure script could easily build a different universal > binary on a PowerPC Mac than it would on an Intel Mac. It doesn't > hurt to always record the arch of the machine that did the build, > and might at some point prove useful. It currently builds the universal packages with `rpmbuild --target=fat`. But that's just a hack anyway (disables arch checking, much like noarch) set rpmbuildarch "" if {[variant_isset "universal"]} { set rpmbuildarch "--target fat" } if {false} { set rpmbuildarch "--target noarch" } It "works" for some trivial -arch ppc -arch i386 builds, but after that all bets are off. It would be better to build one package for each arch. As for the archives, it already records the +universal variant in the name of the archive so I don't think it has to do anything more than that. It would still sort under "ppc" if built on a PowerPC Mac and "i386" if built on an Intel Mac, so the arch of the build machine *is* kept. --anders From afb at macports.org Thu Oct 8 03:11:43 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 8 Oct 2009 12:11:43 +0200 Subject: confusion in base regarding [option os.arch] and ${os.arch} In-Reply-To: <4ACDB8D7.8060006@macports.org> References: <77306B2B-F562-433F-A7C6-FCD7D000B689@macports.org> <4186E4A8-36CB-4E07-983D-A6B9787AC7AE@lavergne.gotdns.org> <4ACD9049.9060305@macports.org> <4ACDA5AC.2060008@macports.org> <94FA2478-538A-449A-B806-A9890CDA2490@macports.org> <4ACDB8D7.8060006@macports.org> Message-ID: <3301B1E7-4FE1-4A5F-A6C9-CD061EEE4472@macports.org> Joshua Root wrote: >> I would tag it with both, just to be on the safe side. A poorly- >> written >> configure script could easily build a different universal binary on a >> PowerPC Mac than it would on an Intel Mac. It doesn't hurt to always >> record the arch of the machine that did the build, and might at some >> point prove useful. > > But the architecture of the machine that did the build has nothing > to do > with build_arch... It should have, otherwise it would be cross-compiling to another arch ? (which is interesting in itself, but not supported by MacPorts afaik) Not sure if it matters if the "extra" fat architecture is ppc or x86_64, when talking about +universal archives built on the regular i386 arch ? --anders From jmr at macports.org Thu Oct 8 03:34:18 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 08 Oct 2009 21:34:18 +1100 Subject: confusion in base regarding [option os.arch] and ${os.arch} In-Reply-To: <3301B1E7-4FE1-4A5F-A6C9-CD061EEE4472@macports.org> References: <77306B2B-F562-433F-A7C6-FCD7D000B689@macports.org> <4186E4A8-36CB-4E07-983D-A6B9787AC7AE@lavergne.gotdns.org> <4ACD9049.9060305@macports.org> <4ACDA5AC.2060008@macports.org> <94FA2478-538A-449A-B806-A9890CDA2490@macports.org> <4ACDB8D7.8060006@macports.org> <3301B1E7-4FE1-4A5F-A6C9-CD061EEE4472@macports.org> Message-ID: <4ACDC02A.1010602@macports.org> On 2009-10-8 21:11, Anders F Bj?rklund wrote: > Joshua Root wrote: >> But the architecture of the machine that did the build has nothing to do >> with build_arch... > > It should have, otherwise it would be cross-compiling to another arch ? > (which is interesting in itself, but not supported by MacPorts afaik) Building for ppc on an x86 machine should work fine AFAIK (thanks to Rosetta), building for x86 on ppc probably less so. - Josh From sixtus at gmail.com Thu Oct 8 04:04:46 2009 From: sixtus at gmail.com (Hagen) Date: Thu, 8 Oct 2009 13:04:46 +0200 Subject: [MacPorts] #19698: can not install rb-plruby In-Reply-To: <063.34b7c77663e8c9ef488ffa044feac456@macports.org> References: <054.3e7e6fbc3e2e10051321713f388a2f46@macports.org> <063.34b7c77663e8c9ef488ffa044feac456@macports.org> Message-ID: <42fe43e10910080404p3d0a7a80je402ab4bea148a9e@mail.gmail.com> Hi all, very sorry about this, but I am unable to maintain the pl-ruby package any longer. Regards, Hagen On Thu, Oct 8, 2009 at 6:56 AM, MacPorts wrote: > #19698: can not install rb-plruby > > ---------------------------------+------------------------------------------ > Reporter: traf@? | Owner: sixtus@? > Type: defect | Status: closed > Priority: Normal | Milestone: > Component: ports | Version: 1.7.1 > Resolution: fixed | Keywords: ruby > Port: rb-plruby | > > ---------------------------------+------------------------------------------ > Changes (by ryandesign@?): > > * status: new => closed > * resolution: => fixed > > > Comment: > > Fixed in r58981 by updating to 0.5.3. > > -- > Ticket URL: > MacPorts > Ports system for Mac OS > -- Dissertations are a successful walk through a minefield -- summarizing them is not. - Roy Fielding -------------- next part -------------- An HTML attachment was scrubbed... URL: From afb at macports.org Thu Oct 8 04:07:51 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 8 Oct 2009 13:07:51 +0200 Subject: confusion in base regarding [option os.arch] and ${os.arch} In-Reply-To: <4ACDC02A.1010602@macports.org> References: <77306B2B-F562-433F-A7C6-FCD7D000B689@macports.org> <4186E4A8-36CB-4E07-983D-A6B9787AC7AE@lavergne.gotdns.org> <4ACD9049.9060305@macports.org> <4ACDA5AC.2060008@macports.org> <94FA2478-538A-449A-B806-A9890CDA2490@macports.org> <4ACDB8D7.8060006@macports.org> <3301B1E7-4FE1-4A5F-A6C9-CD061EEE4472@macports.org> <4ACDC02A.1010602@macports.org> Message-ID: <94AB9ADE-2AC2-4D1A-958F-BAD33B42C743@macports.org> Joshua Root wrote: >> It should have, otherwise it would be cross-compiling to another >> arch ? >> (which is interesting in itself, but not supported by MacPorts afaik) > > Building for ppc on an x86 machine should work fine AFAIK (thanks to > Rosetta), building for x86 on ppc probably less so. Building for x86 on ppc also works if the software being built is careful about build vs. host programs and so and so forth (cross-compilation). But what I meant was that it is unsupported in MacPorts (not on Mac OS X), mostly due to all the +powerpc and similar target stuff being totally off... --anders From jmr at macports.org Thu Oct 8 04:12:13 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 08 Oct 2009 22:12:13 +1100 Subject: confusion in base regarding [option os.arch] and ${os.arch} In-Reply-To: <94AB9ADE-2AC2-4D1A-958F-BAD33B42C743@macports.org> References: <77306B2B-F562-433F-A7C6-FCD7D000B689@macports.org> <4186E4A8-36CB-4E07-983D-A6B9787AC7AE@lavergne.gotdns.org> <4ACD9049.9060305@macports.org> <4ACDA5AC.2060008@macports.org> <94FA2478-538A-449A-B806-A9890CDA2490@macports.org> <4ACDB8D7.8060006@macports.org> <3301B1E7-4FE1-4A5F-A6C9-CD061EEE4472@macports.org> <4ACDC02A.1010602@macports.org> <94AB9ADE-2AC2-4D1A-958F-BAD33B42C743@macports.org> Message-ID: <4ACDC90D.4090000@macports.org> On 2009-10-8 22:07, Anders F Bj?rklund wrote: > Joshua Root wrote: > >>> It should have, otherwise it would be cross-compiling to another arch ? >>> (which is interesting in itself, but not supported by MacPorts afaik) >> >> Building for ppc on an x86 machine should work fine AFAIK (thanks to >> Rosetta), building for x86 on ppc probably less so. > > Building for x86 on ppc also works if the software being built is careful > about build vs. host programs and so and so forth (cross-compilation). > > But what I meant was that it is unsupported in MacPorts (not on Mac OS X), > mostly due to all the +powerpc and similar target stuff being totally > off... Right, there are no target platform variants... - Josh From jmr at macports.org Thu Oct 8 04:13:33 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 08 Oct 2009 22:13:33 +1100 Subject: [MacPorts] #19698: can not install rb-plruby In-Reply-To: <42fe43e10910080404p3d0a7a80je402ab4bea148a9e@mail.gmail.com> References: <054.3e7e6fbc3e2e10051321713f388a2f46@macports.org> <063.34b7c77663e8c9ef488ffa044feac456@macports.org> <42fe43e10910080404p3d0a7a80je402ab4bea148a9e@mail.gmail.com> Message-ID: <4ACDC95D.1050905@macports.org> On 2009-10-8 22:04, Hagen wrote: > Hi all, > > > very sorry about this, but I am unable to maintain the pl-ruby package > any longer. I've removed you as maintainer. - Josh From macsforever2000 at macports.org Thu Oct 8 09:25:09 2009 From: macsforever2000 at macports.org (Frank Schima) Date: Thu, 8 Oct 2009 10:25:09 -0600 Subject: wxPython-devel fork? In-Reply-To: <09CA7862-FEB5-4DC2-ACAB-1B42921AB7A4@macports.org> References: <09CA7862-FEB5-4DC2-ACAB-1B42921AB7A4@macports.org> Message-ID: <6F8354EC-EBBD-4E7D-8403-7699659076BD@macports.org> Hi Vince, On Sep 23, 2009, at 5:04 AM, vincent habchi wrote: > I have ported the Grass (v. 6.4) GIS app to MacPorts in my private > tree. However, Grass relies on Wxpython. In order to get a universal > build, I had to use the svn version of Wxpython, the only one > compatible with the newest wxWidgets 2.9.0, which features the > osx_cocoa 32/64-build. > > The standard wxWidgets-devel Portfile, while up to date, lacks the > universal/cocoa option. I have a private version of the port called > wxWidgets29, that serves as a foundation for both my private "py26- > wxpython-devel" port and Grass. > > In order to commit Grass and py26-wxpython-devel, is it reasonable > to fork wxwindows-devel in wxwindows29 or shall I modify the > wxwindows-devel portfile? I proposed the patched version to the > owners, but got no response. I feel wxwindows-devel should follow > wxWindows development (even into 3.0) while wxwindows29 could be > used only for the 2.9 unstable branch. > > Opinion? Since there are no opinions on this, I'd say do what you think is best. I think your proposal makes sense. With regards to grass, I would update the current "grass" port to 6.4 and link to the wx*-devel ports, and make a new "grass63" port with the current grass portfile. Usually the ports with a version in the name are the old ones. Cheers! Frank From ryandesign at macports.org Thu Oct 8 09:43:23 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 8 Oct 2009 11:43:23 -0500 Subject: kde4 portgroup (was: [59018] trunk/dports/kde/kdeedu4) In-Reply-To: <20091008160804.C3EE529565E0@beta.macosforge.org> References: <20091008160804.C3EE529565E0@beta.macosforge.org> Message-ID: <1F9DA39C-243D-4967-984D-DF39237B92C4@macports.org> On Oct 8, 2009, at 11:08, sharky at macports.org wrote: > Revision: 59018 > http://trac.macports.org/changeset/59018 > Author: sharky at macports.org > Date: 2009-10-08 09:08:03 -0700 (Thu, 08 Oct 2009) > Log Message: > ----------- > update kdeedu4 to version 4.3.2 (#21912) > > Modified Paths: > -------------- > trunk/dports/kde/kdeedu4/Portfile > +patchfiles byteswap-osx.patch > +patch.dir ${workpath}/${distname} > +patch.pre_args -p1 I was all ready to explain how "${workpath}/${distname}" is more simply known as "${worksrcpath}", and that that's the default for patch.dir [1], but I see that's not the case for the kde4 portgroup because it sets worksrcdir to "build". That's probably never right for patching, as you're seeing. Maybe it would be smart to update the kde4 portgroup and either set the patch.dir there, or perhaps even better, don't override the worksrcdir in the first place, and instead, just override the configure.dir and build.dir. [1] http://guide.macports.org/#reference.phases.patch > configure.args-append ../${distname} I've found this a strange line before, and noted it's in every port using the kde4 portgroup. Therefore, I suggested before it should be moved to the kde4 portgroup as well (where it could use configure.post_args-append so as not to interfere with configure.args). Or perhaps all that's needed is to not override configure.dir, and just set build.dir, as suggested above. Any thoughts on whether that would work? From ryandesign at macports.org Thu Oct 8 12:40:10 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 8 Oct 2009 14:40:10 -0500 Subject: [59038] trunk/dports/java/groovy-devel/Portfile In-Reply-To: <20091008193439.2B02629595C7@beta.macosforge.org> References: <20091008193439.2B02629595C7@beta.macosforge.org> Message-ID: <4C6B70C7-A732-4608-9E90-FCA56E96CFF1@macports.org> On Oct 8, 2009, at 14:34, breskeby at macports.org wrote: > Revision: 59038 > http://trac.macports.org/changeset/59038 > Author: breskeby at macports.org > Date: 2009-10-08 12:34:38 -0700 (Thu, 08 Oct 2009) > Log Message: > ----------- > #21938 portfile for groovy 1.7-beta-1 > > Added Paths: > ----------- > trunk/dports/java/groovy-devel/Portfile You should add "dist_subdir groovy" so groovy-devel downloads to the same directory as groovy. -------------- next part -------------- A non-text attachment was scrubbed... Name: groovy-devel.diff Type: application/octet-stream Size: 498 bytes Desc: not available URL: -------------- next part -------------- > +extract.suffix .zip > +extract.cmd unzip > +extract.pre_args -qu > +extract.post_args "-d ${workpath}" > +#extract yes > +#use_zip yes What was the matter with "use_zip yes"? I notice you were able to use that in groovy. Why not in groovy-devel? From talklists at newgeo.com Thu Oct 8 17:38:29 2009 From: talklists at newgeo.com (Scott Haneda) Date: Thu, 8 Oct 2009 17:38:29 -0700 Subject: Apache crashes Message-ID: <2032B5FE-4930-4941-A97C-B7ECD044E872@newgeo.com> Just after I get a large group of sites migrated to apache2 on a new machine, I am seeing this happen in the error log: 36)Operation now in progress: initgroups: unable to set groups for User www and Group 70 Seems to be a bit of info in google about it, related to Mac OS X, and some in the macports archives about python. Here is the whole deal: $grep 'alert' error_log [Thu Oct 08 16:23:24 2009] [alert] (22)Invalid argument: initgroups: unable to set groups for User www and Group 70 [Thu Oct 08 16:23:24 2009] [alert] (22)Invalid argument: initgroups: unable to set groups for User www and Group 70 [Thu Oct 08 16:23:24 2009] [alert] (22)Invalid argument: initgroups: unable to set groups for User www and Group 70 [Thu Oct 08 16:23:24 2009] [alert] (22)Invalid argument: initgroups: unable to set groups for User www and Group 70 [Thu Oct 08 16:23:24 2009] [alert] (22)Invalid argument: initgroups: unable to set groups for User www and Group 70 [Thu Oct 08 16:23:25 2009] [alert] Child 13545 returned a Fatal error... Apache is exiting! [Thu Oct 08 17:29:48 2009] [alert] (36)Operation now in progress: initgroups: unable to set groups for User www and Group 70 [Thu Oct 08 17:29:49 2009] [alert] Child 13782 returned a Fatal error... Apache is exiting! I was fiddling with rotatelogs in a virtual host container, but since removed it, and am not using that feature at this time. Those alerts above came after I restarted apache with a graceful. Suggestions? -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Thu Oct 8 19:36:39 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 8 Oct 2009 21:36:39 -0500 Subject: Apache crashes In-Reply-To: <2032B5FE-4930-4941-A97C-B7ECD044E872@newgeo.com> References: <2032B5FE-4930-4941-A97C-B7ECD044E872@newgeo.com> Message-ID: <82C9FCD6-7A96-469D-907C-EA04F72043DA@macports.org> On Oct 8, 2009, at 19:38, Scott Haneda wrote: > Just after I get a large group of sites migrated to apache2 on a new > machine, I am seeing this happen in the error log: > > 36)Operation now in progress: initgroups: unable to set groups for > User www and Group 70 > > Seems to be a bit of info in google about it, related to Mac OS X, > and some in the macports archives about python. > > Here is the whole deal: > $grep 'alert' error_log > [Thu Oct 08 16:23:24 2009] [alert] (22)Invalid argument: initgroups: > unable to set groups for User www and Group 70 > [Thu Oct 08 16:23:24 2009] [alert] (22)Invalid argument: initgroups: > unable to set groups for User www and Group 70 > [Thu Oct 08 16:23:24 2009] [alert] (22)Invalid argument: initgroups: > unable to set groups for User www and Group 70 > [Thu Oct 08 16:23:24 2009] [alert] (22)Invalid argument: initgroups: > unable to set groups for User www and Group 70 > [Thu Oct 08 16:23:24 2009] [alert] (22)Invalid argument: initgroups: > unable to set groups for User www and Group 70 > [Thu Oct 08 16:23:25 2009] [alert] Child 13545 returned a Fatal > error... Apache is exiting! > [Thu Oct 08 17:29:48 2009] [alert] (36)Operation now in progress: > initgroups: unable to set groups for User www and Group 70 > [Thu Oct 08 17:29:49 2009] [alert] Child 13782 returned a Fatal > error... Apache is exiting! > > I was fiddling with rotatelogs in a virtual host container, but > since removed it, and am not using that feature at this time. Those > alerts above came after I restarted apache with a graceful. > > Suggestions? What OS is this? If 10.5 or later, the user should be "_www" not "www". Where does "group 70" come from? That should be "_www" too, shouldn't it? From talklists at newgeo.com Thu Oct 8 20:27:17 2009 From: talklists at newgeo.com (Scott Haneda) Date: Thu, 8 Oct 2009 20:27:17 -0700 Subject: Apache crashes In-Reply-To: <82C9FCD6-7A96-469D-907C-EA04F72043DA@macports.org> References: <2032B5FE-4930-4941-A97C-B7ECD044E872@newgeo.com> <82C9FCD6-7A96-469D-907C-EA04F72043DA@macports.org> Message-ID: On Oct 8, 2009, at 7:36 PM, Ryan Schmidt wrote: > On Oct 8, 2009, at 19:38, Scott Haneda wrote: > >> Just after I get a large group of sites migrated to apache2 on a >> new machine, I am seeing this happen in the error log: >> >> 36)Operation now in progress: initgroups: unable to set groups for >> User www and Group 70 >> >> Seems to be a bit of info in google about it, related to Mac OS X, >> and some in the macports archives about python. >> >> Here is the whole deal: >> $grep 'alert' error_log >> [Thu Oct 08 16:23:24 2009] [alert] (22)Invalid argument: >> initgroups: unable to set groups for User www and Group 70 >> [Thu Oct 08 16:23:24 2009] [alert] (22)Invalid argument: >> initgroups: unable to set groups for User www and Group 70 >> [Thu Oct 08 16:23:24 2009] [alert] (22)Invalid argument: >> initgroups: unable to set groups for User www and Group 70 >> [Thu Oct 08 16:23:24 2009] [alert] (22)Invalid argument: >> initgroups: unable to set groups for User www and Group 70 >> [Thu Oct 08 16:23:24 2009] [alert] (22)Invalid argument: >> initgroups: unable to set groups for User www and Group 70 >> [Thu Oct 08 16:23:25 2009] [alert] Child 13545 returned a Fatal >> error... Apache is exiting! >> [Thu Oct 08 17:29:48 2009] [alert] (36)Operation now in progress: >> initgroups: unable to set groups for User www and Group 70 >> [Thu Oct 08 17:29:49 2009] [alert] Child 13782 returned a Fatal >> error... Apache is exiting! >> >> I was fiddling with rotatelogs in a virtual host container, but >> since removed it, and am not using that feature at this time. >> Those alerts above came after I restarted apache with a graceful. >> >> Suggestions? > > What OS is this? If 10.5 or later, the user should be "_www" not > "www". > > Where does "group 70" come from? That should be "_www" too, > shouldn't it? This is 10.5, PPC As to www or _www, I was pretty sure the are synonymous... $touch foo -rw-r--r-- 1 me staff 0 Oct 8 20:06 foo $sudo chown www:www foo -rw-r--r-- 1 _www _www 0 Oct 8 20:06 foo $sudo chown _www:_www foo -rw-r--r-- 1 _www _www 0 Oct 8 20:06 foo No matter what, they always seem to be _www. Group 70 is: AppleMetaNodeLocation: /Local/Default GeneratedUID: ABCDEFAB-CDEF-ABCD-EFAB-CDEF00000046 Password: * PrimaryGroupID: 70 RealName: HTTP Users RecordName: _www www RecordType: dsRecTypeNative:groups SMBSID: S-1-5-21-170 That is built in, I did not make that. Where is apache deciding to set these values from, and why is it only an intermittent error? The default httpd.conf has: User www Group www This thread I just found sheds more light on it: http://mail-archives.apache.org/mod_mbox/httpd-users/200810.mbox/%3C5249c07e0810091021s77d4f603y50c3fbb20cd4c181 at mail.gmail.com%3E Google searches on this are pretty strongly pointing to 'initgroups', which I know nothing about. According to this: http://discussions.apple.com/thread.jspa?threadID=1495604 I should change the httpd.conf file to _www an _www u/g, though Apache should still not crash regardless. This is not all the time like in the above post, I only get it under a condition I can not repeat currently. I have never worked with bug reporting to Apache, do you think this is cofig on my end, or worth taking up the chain? -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Thu Oct 8 20:41:22 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 8 Oct 2009 22:41:22 -0500 Subject: Apache crashes In-Reply-To: References: <2032B5FE-4930-4941-A97C-B7ECD044E872@newgeo.com> <82C9FCD6-7A96-469D-907C-EA04F72043DA@macports.org> Message-ID: On Oct 8, 2009, at 22:27, Scott Haneda wrote: > On Oct 8, 2009, at 7:36 PM, Ryan Schmidt wrote: > >> What OS is this? If 10.5 or later, the user should be "_www" not >> "www". >> >> Where does "group 70" come from? That should be "_www" too, >> shouldn't it? > > This is 10.5, PPC > As to www or _www, I was pretty sure the are synonymous... > $touch foo > -rw-r--r-- 1 me staff 0 Oct 8 20:06 foo > $sudo chown www:www foo > -rw-r--r-- 1 _www _www 0 Oct 8 20:06 foo > $sudo chown _www:_www foo > -rw-r--r-- 1 _www _www 0 Oct 8 20:06 foo > > No matter what, they always seem to be _www. > > Group 70 is: > AppleMetaNodeLocation: /Local/Default > GeneratedUID: ABCDEFAB-CDEF-ABCD-EFAB-CDEF00000046 > Password: * > PrimaryGroupID: 70 > RealName: > HTTP Users > RecordName: _www www > RecordType: dsRecTypeNative:groups > SMBSID: S-1-5-21-170 > > That is built in, I did not make that. Where is apache deciding to > set these values from, and why is it only an intermittent error? > The default httpd.conf has: > User www > Group www Apache gets those values from the User and Group lines in the httpd.conf, as you pointed out. I don't know why the error you experience is intermittent. > This thread I just found sheds more light on it: > http://mail-archives.apache.org/mod_mbox/httpd-users/200810.mbox/%3C5249c07e0810091021s77d4f603y50c3fbb20cd4c181 at mail.gmail.com%3E > > Google searches on this are pretty strongly pointing to > 'initgroups', which I know nothing about. I see in that thread someone else reports this same problem a years ago, but I don't see a solution mentioned. If you are not able to resolve the issue, I recommend writing to that list again, referencing that old thread, and asking for more information. > According to this: > http://discussions.apple.com/thread.jspa?threadID=1495604 > I should change the httpd.conf file to _www an _www u/g, though > Apache should still not crash regardless. This is not all the time > like in the above post, I only get it under a condition I can not > repeat currently. I do see that thread advocates changing "www" to "_www", but as you've shown above, they are synonymous, so I don't know why that would make a difference. But by all means try it. Nobody else has reported problems related to this, that I'm aware of, and the apache2 portfile was never changed to put "_www" into the httpd.conf on Leopard, and Leopard was introduced years ago, so if there were a problem about this, I would have expected to hear about it long before now. > I have never worked with bug reporting to Apache, do you think this > is cofig on my end, or worth taking up the chain? I do not know. I have not experienced this problem before. From talklists at newgeo.com Thu Oct 8 23:07:04 2009 From: talklists at newgeo.com (Scott Haneda) Date: Thu, 8 Oct 2009 23:07:04 -0700 Subject: Apache crashes In-Reply-To: References: <2032B5FE-4930-4941-A97C-B7ECD044E872@newgeo.com> <82C9FCD6-7A96-469D-907C-EA04F72043DA@macports.org> Message-ID: <1DD2D096-24C4-499D-B799-3A1FE2B40DFC@newgeo.com> On Oct 8, 2009, at 8:41 PM, Ryan Schmidt wrote: >> This thread I just found sheds more light on it: >> http://mail-archives.apache.org/mod_mbox/httpd-users/200810.mbox/%3C5249c07e0810091021s77d4f603y50c3fbb20cd4c181 at mail.gmail.com%3E >> >> Google searches on this are pretty strongly pointing to >> 'initgroups', which I know nothing about. > > I see in that thread someone else reports this same problem a years > ago, but I don't see a solution mentioned. If you are not able to > resolve the issue, I recommend writing to that list again, > referencing that old thread, and asking for more information. I nuked my error_log earlier, so only have today forward. Looking much closer at time stamps, I see it went something like this: edit foo.conf add line for error document with a | to rotatelogs and set to use 300 seconds apachectl graceful http request a few pages in foo domain to generate some errors Note that they are showing up in the newly pointed error log file wait 300 seconds, notice the log was rotated strike the line from foo.conf apachectl graceful Get an email from client saying site was down... I can look in the logs and see more, since my OP just was grep'd for 'alert' lines, there seems to be a correlation with the time I was messing with rotatelogs. If I am brave, over the weekend I will see if I can not make it repeatable. I posted a outline of the issue to apache-users, and asked for advice on how to figure out the best next steps. I will update this thread if it is relevant to MacPorts maintaining a stable Apache on Mac OS X. Thanks. -- Scott * If you contact me off list replace talklists@ with scott@ * From blb at macports.org Thu Oct 8 23:12:09 2009 From: blb at macports.org (Bryan Blackburn) Date: Fri, 9 Oct 2009 00:12:09 -0600 Subject: The next MacPorts management Message-ID: <20091009061209.GB65456@ninagal.withay.com> It's been about a year since the new portmgr has been around, so I believe that means it's about time to start looking at the next year's portmgr. In the past, it was usually voted upon [1], and I figured that would be the same basic idea for this time as well. When it was done then, only committers were allowed to vote, but personally I think everyone involved in one way or another should be able to do so instead. The questions are, then, how do we want to do this, when, and after that's decided, who wants to run? Bryan [1] - From vince at macports.org Thu Oct 8 23:13:23 2009 From: vince at macports.org (vincent habchi) Date: Fri, 9 Oct 2009 08:13:23 +0200 Subject: wxPython-devel fork? In-Reply-To: <6F8354EC-EBBD-4E7D-8403-7699659076BD@macports.org> References: <09CA7862-FEB5-4DC2-ACAB-1B42921AB7A4@macports.org> <6F8354EC-EBBD-4E7D-8403-7699659076BD@macports.org> Message-ID: <2EE47C7F-1816-4193-AB95-2CA29FC0CF6D@macports.org> Hi Frank, > Since there are no opinions on this, I'd say do what you think is > best. I think your proposal makes sense. With regards to grass, I > would update the current "grass" port to 6.4 and link to the wx*- > devel ports, and make a new "grass63" port with the current grass > portfile. Usually the ports with a version in the name are the old > ones. Okay, thanks a lot for your answer. I'll wait till the week-end and then proceed. Cheers, have a nice end of week Vincent From and.damore at macports.org Thu Oct 8 23:22:00 2009 From: and.damore at macports.org (Andrea D'Amore) Date: Fri, 9 Oct 2009 08:22:00 +0200 Subject: php values In-Reply-To: <50DBBD21-D456-4BF2-8AEF-61C4F6CDEEAD@newgeo.com> References: <50DBBD21-D456-4BF2-8AEF-61C4F6CDEEAD@newgeo.com> Message-ID: <30FAA382-7563-4136-8B14-F670BA66AEC8@macports.org> On 07/ott/09, at 00:05, Scott Haneda wrote: > Thought I would post this here first, if this is the wrong place, > any ideas on the best place to get an answer... I'd say an apache httpd user mailing list or channel #httpd on Freenode Not that you can't find anyone willing to help here but this is a httpd config specific issue. -- Andrea From talklists at newgeo.com Thu Oct 8 23:24:57 2009 From: talklists at newgeo.com (Scott Haneda) Date: Thu, 8 Oct 2009 23:24:57 -0700 Subject: httpd.pid storage location Message-ID: This may be a strange question, but why is Apache2's pid file stored in the logs directory of Apache2? I am doing some basic background on this, and some put it in var/run, in this case prefix first of course, but I do not find any official suggestion on the layout. It does strike me as odd to store it in the logs folder, of all non MP installs, I do spend some time in logs directories, and have never met a pid on that side of town. -- Scott * If you contact me off list replace talklists@ with scott@ * From talklists at newgeo.com Thu Oct 8 23:38:25 2009 From: talklists at newgeo.com (Scott Haneda) Date: Thu, 8 Oct 2009 23:38:25 -0700 Subject: httpd.pid storage location In-Reply-To: References: Message-ID: <44FE8E96-C26E-40CA-81E8-9A36D7BD31C8@newgeo.com> Nevermind, as I was looking into log rotation of all things, I find it nestled here: http://httpd.apache.org/docs/1.3/logs.html#pidfile Sorry for the noise. -- Scott * If you contact me off list replace talklists@ with scott@ * On Oct 8, 2009, at 11:24 PM, Scott Haneda wrote: > This may be a strange question, but why is Apache2's pid file stored > in the logs directory of Apache2? I am doing some basic background > on this, and some put it in var/run, in this case prefix first of > course, but I do not find any official suggestion on the layout. > > It does strike me as odd to store it in the logs folder, of all non > MP installs, I do spend some time in logs directories, and have > never met a pid on that side of town. From ryandesign at macports.org Fri Oct 9 00:21:56 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 9 Oct 2009 02:21:56 -0500 Subject: httpd.pid storage location In-Reply-To: <44FE8E96-C26E-40CA-81E8-9A36D7BD31C8@newgeo.com> References: <44FE8E96-C26E-40CA-81E8-9A36D7BD31C8@newgeo.com> Message-ID: <6CF116DB-3229-43CC-8502-9AAAE8015FCC@macports.org> On Oct 9, 2009, at 01:38, Scott Haneda wrote: > On Oct 8, 2009, at 11:24 PM, Scott Haneda wrote: > >> This may be a strange question, but why is Apache2's pid file >> stored in the logs directory of Apache2? I am doing some basic >> background on this, and some put it in var/run, in this case prefix >> first of course, but I do not find any official suggestion on the >> layout. >> >> It does strike me as odd to store it in the logs folder, of all non >> MP installs, I do spend some time in logs directories, and have >> never met a pid on that side of town. > > Nevermind, as I was looking into log rotation of all things, I find > it nestled here: > http://httpd.apache.org/docs/1.3/logs.html#pidfile > Sorry for the noise. pidfile in the log directory does strike me as an odd choice too. It looks like it's how Apache likes it done, but you're right, most other ports put their pid files in ${prefix}/var/run or ${prefix}/var/run/$ {name}. P.S: Note there's newer Apache 2.2 documentation: http://httpd.apache.org/docs/2.2/mod/mpm_common.html#pidfile At least the example given there shows how to change it to /var/run. When we get around to fixing the apache2 layout (#21315), we can also patch the sample httpd.conf to use ${prefix}/var/run for the pid file. From talklists at newgeo.com Fri Oct 9 01:19:18 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 9 Oct 2009 01:19:18 -0700 Subject: httpd.pid storage location In-Reply-To: <6CF116DB-3229-43CC-8502-9AAAE8015FCC@macports.org> References: <44FE8E96-C26E-40CA-81E8-9A36D7BD31C8@newgeo.com> <6CF116DB-3229-43CC-8502-9AAAE8015FCC@macports.org> Message-ID: On Oct 9, 2009, at 12:21 AM, Ryan Schmidt wrote: > On Oct 9, 2009, at 01:38, Scott Haneda wrote: > >> On Oct 8, 2009, at 11:24 PM, Scott Haneda wrote: >> >>> This may be a strange question, but why is Apache2's pid file >>> stored in the logs directory of Apache2? I am doing some basic >>> background on this, and some put it in var/run, in this case >>> prefix first of course, but I do not find any official suggestion >>> on the layout. >>> >>> It does strike me as odd to store it in the logs folder, of all >>> non MP installs, I do spend some time in logs directories, and >>> have never met a pid on that side of town. >> >> Nevermind, as I was looking into log rotation of all things, I find >> it nestled here: >> http://httpd.apache.org/docs/1.3/logs.html#pidfile >> Sorry for the noise. > > pidfile in the log directory does strike me as an odd choice too. It > looks like it's how Apache likes it done, but you're right, most > other ports put their pid files in ${prefix}/var/run or ${prefix}/ > var/run/${name}. Sounds good to me, probably w/o the ${name} since that is what the docs are saying. > P.S: Note there's newer Apache 2.2 documentation: > > http://httpd.apache.org/docs/2.2/mod/mpm_common.html#pidfile Thank you! > At least the example given there shows how to change it to /var/run. > > When we get around to fixing the apache2 layout (#21315), we can > also patch the sample httpd.conf to use ${prefix}/var/run for the > pid file. Oh that old thing :) -- Scott * If you contact me off list replace talklists@ with scott@ * From talklists at newgeo.com Fri Oct 9 01:33:28 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 9 Oct 2009 01:33:28 -0700 Subject: pureftpd creates files outside of prefix Message-ID: <6B369ABA-540F-4CAD-94B2-E20EA397BD7A@newgeo.com> I am not sure if this violation is happening as a result of the portfile, my startup options, or a compile patch that would need to be applied. I wanted to start here, and then I can take this to the developer, if possible. So far, I have not had any luck with official support on their mailing list. http://trac.macports.org/browser/trunk/dports/net/pureftpd/Portfile I created my own launchd item, perhaps for basic sample inclusion some day, which starts pureftpd. For those who are not aware, pureftpd starts entirely via arguments, no config file required: /opt/local/sbin/pure-ftpd --chrooteveryone --displaydotfiles --noanonymous --createhomedir --maxdiskusagepct=80 --allowdotfiles --minuid=1 --umask=133:022 --maxclientsperip=5 --maxidletime=10 --altlog=stats:/opt/local/var/log/ftp/ftp_xfer.log --login=mysql:/opt/local/etc/pure-ftpd/pure-ftpd-mysql.conf --dontresolve --customerproof --tls=1 $file /var/run/pure-ftpd/ /var/run/pure-ftpd/: directory $ls -la /var/run/pure-ftpd | wc -l 98 I can not determine from the docs, or google, what these 98 files are. -rw------- 1 root daemon 1448 Oct 9 00:59 client-00014270 -rw------- 1 root daemon 1448 Oct 9 01:01 client-00014287 -rw------- 1 root daemon 1448 Oct 9 01:02 client-00014290 -rw------- 1 root daemon 1448 Oct 9 01:05 client-00014299 ... $file client-00014310 client-00014310: data There should also be a pure-ftpd.pid file in ${prefix}/var/run which is missing from both locations. From what I understand, pureftpd starts on demand, and is not always running, so I made sure to login via ftp and look for a pid file, none to be found. I am going to cross post parts of this sans the ${prefix} stuff to the pureftpd mailing list and will report back any findings. -- Scott * If you contact me off list replace talklists@ with scott@ * From talklists at newgeo.com Fri Oct 9 02:04:32 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 9 Oct 2009 02:04:32 -0700 Subject: pureftpd creates files outside of prefix In-Reply-To: <6B369ABA-540F-4CAD-94B2-E20EA397BD7A@newgeo.com> References: <6B369ABA-540F-4CAD-94B2-E20EA397BD7A@newgeo.com> Message-ID: These seem to be scoreboard files, which amount to live stats. I am really new to this territory, and trying to see what I can do to help, so be kind. grepping the source: ftpwho-update.h # ifdef NON_ROOT_FTP # define SCOREBOARD_PATH CONFDIR "/pure-ftpd-ftpwho" # else # define SCOREBOARD_PATH "/var/run/pure-ftpd" # endif #define SCOREBOARD_PREFIX "client-" I am assuming # is not a comment in C, or has special treatment. That path is hard coded, I believe there would need to be a patch made for the portfile to change that to that of ${prefix} in front of it? But this may just be the ftpwho command, and where it looks. I can not find solid reference to where the actual creation of the scoreboard directory happens at. The man pages, make multiple references to non ${prefix} based locations. I suppose those need cleaning as well? This is a strange one, as you can supply the path to the ftp.log and ftp.xfer.log as startup args, in which case I get to put them wherever I want. I chose to put them in ${prefix}. However, each of the defaults is in fact hard coded into the source, and I am guessing needs to be patched. Curious, is the correct procedure to have arbitrary paths that people may want to change be a configure option, Or is it unique to Mac Ports, and just reinplace the files carefully? I will do my best on this one, but it may be out of my league. It is currently nomaintainer, so I could take it over, but will need a little handholding I suspect. -- Scott * If you contact me off list replace talklists@ with scott@ * On Oct 9, 2009, at 1:33 AM, Scott Haneda wrote: > $file /var/run/pure-ftpd/ > /var/run/pure-ftpd/: directory > > $ls -la /var/run/pure-ftpd | wc -l > 98 > > I can not determine from the docs, or google, what these 98 files are. > -rw------- 1 root daemon 1448 Oct 9 00:59 client-00014270 > -rw------- 1 root daemon 1448 Oct 9 01:01 client-00014287 > -rw------- 1 root daemon 1448 Oct 9 01:02 client-00014290 > -rw------- 1 root daemon 1448 Oct 9 01:05 client-00014299 > ... > > $file client-00014310 > client-00014310: data > > There should also be a pure-ftpd.pid file in ${prefix}/var/run which > is missing from both locations. From what I understand, pureftpd > starts on demand, and is not always running, so I made sure to login > via ftp and look for a pid file, none to be found. > > I am going to cross post parts of this sans the ${prefix} stuff to > the pureftpd mailing list and will report back any findings. From dweber at macports.org Fri Oct 9 12:14:30 2009 From: dweber at macports.org (Darren Weber) Date: Fri, 9 Oct 2009 12:14:30 -0700 Subject: The next MacPorts management In-Reply-To: <20091009061209.GB65456@ninagal.withay.com> References: <20091009061209.GB65456@ninagal.withay.com> Message-ID: On Thu, Oct 8, 2009 at 11:12 PM, Bryan Blackburn wrote: > It's been about a year since the new portmgr has been around, so I believe > that means it's about time to start looking at the next year's portmgr. > > In the past, it was usually voted upon [1], and I figured that would be the > same basic idea for this time as well. When it was done then, only > committers were allowed to vote, but personally I think everyone involved > in > one way or another should be able to do so instead. > > The questions are, then, how do we want to do this, when, and after that's > decided, who wants to run? > > Sounds like MacPorts has no specific policy on the process, yet. Or is there a wiki page about this somewhere? Does a term correspond to a fixed calendar date or interval? Is it possible for current "office bearers" to nominate for another term? Are self nominations accepted? Take care, Darren -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy at lavergne.gotdns.org Fri Oct 9 12:39:04 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 9 Oct 2009 15:39:04 -0400 Subject: The next MacPorts management In-Reply-To: <20091009061209.GB65456@ninagal.withay.com> References: <20091009061209.GB65456@ninagal.withay.com> Message-ID: <44A4FA16-CE04-4490-9714-7AEDEF83A6D6@lavergne.gotdns.org> Also, are we sticking to the same number of people? On Oct 9, 2009, at 2:12 AM, Bryan Blackburn wrote: > The questions are, then, how do we want to do this, when, and after > that's > decided, who wants to run? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4024 bytes Desc: not available URL: From dluke at geeklair.net Fri Oct 9 15:09:33 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Fri, 9 Oct 2009 18:09:33 -0400 Subject: The next MacPorts management In-Reply-To: <44A4FA16-CE04-4490-9714-7AEDEF83A6D6@lavergne.gotdns.org> References: <20091009061209.GB65456@ninagal.withay.com> <44A4FA16-CE04-4490-9714-7AEDEF83A6D6@lavergne.gotdns.org> Message-ID: It might be a good idea to agree on a term and then also stage things so that we don't end up with the possibility of 100% turnover each election. On Oct 9, 2009, at 3:39 PM, Jeremy Lavergne wrote: > Also, are we sticking to the same number of people? > > On Oct 9, 2009, at 2:12 AM, Bryan Blackburn wrote: >> The questions are, then, how do we want to do this, when, and after >> that's >> decided, who wants to run? -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ From jeremy at lavergne.gotdns.org Fri Oct 9 15:10:32 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 9 Oct 2009 18:10:32 -0400 Subject: The next MacPorts management In-Reply-To: References: <20091009061209.GB65456@ninagal.withay.com> <44A4FA16-CE04-4490-9714-7AEDEF83A6D6@lavergne.gotdns.org> Message-ID: <8CB2FB35-F38C-411A-98AB-40F77C62A4B1@lavergne.gotdns.org> Very good idea. Having a historian of sorts to show the ropes, fix any messes, etc. On Oct 9, 2009, at 6:09 PM, Daniel J. Luke wrote: > It might be a good idea to agree on a term and then also stage > things so that we don't end up with the possibility of 100% turnover > each election. > > On Oct 9, 2009, at 3:39 PM, Jeremy Lavergne wrote: >> Also, are we sticking to the same number of people? >> >> On Oct 9, 2009, at 2:12 AM, Bryan Blackburn wrote: >>> The questions are, then, how do we want to do this, when, and >>> after that's >>> decided, who wants to run? > > -- > Daniel J. Luke > +========================================================+ > | *---------------- dluke at geeklair.net ----------------* | > | *-------------- http://www.geeklair.net -------------* | > +========================================================+ > | Opinions expressed are mine and do not necessarily | > | reflect the opinions of my employer. | > +========================================================+ > > > > From ryandesign at macports.org Fri Oct 9 15:44:22 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 9 Oct 2009 17:44:22 -0500 Subject: pureftpd creates files outside of prefix In-Reply-To: References: <6B369ABA-540F-4CAD-94B2-E20EA397BD7A@newgeo.com> Message-ID: <4C496A26-32A0-4885-97F5-8EE241D49ED5@macports.org> On Oct 9, 2009, at 04:04, Scott Haneda wrote: > These seem to be scoreboard files, which amount to live stats. I am > really new to this territory, and trying to see what I can do to > help, so be kind. > > grepping the source: > ftpwho-update.h > > # ifdef NON_ROOT_FTP > # define SCOREBOARD_PATH CONFDIR "/pure-ftpd-ftpwho" > # else > # define SCOREBOARD_PATH "/var/run/pure-ftpd" > # endif > #define SCOREBOARD_PREFIX "client-" > > I am assuming # is not a comment in C, or has special treatment. They're preprocessor directives. > That path is hard coded, I believe there would need to be a patch > made for the portfile to change that to that of ${prefix} in front > of it? Basically yes. I mean you may need to patch these to include @PREFIX@" where you want the prefix, and then later reinplace @PREFIX@ with the real value of ${prefix}. > But this may just be the ftpwho command, and where it looks. I can > not find solid reference to where the actual creation of the > scoreboard directory happens at. > > The man pages, make multiple references to non ${prefix} based > locations. I suppose those need cleaning as well? Good idea. > This is a strange one, as you can supply the path to the ftp.log and > ftp.xfer.log as startup args, in which case I get to put them > wherever I want. I chose to put them in ${prefix}. > > However, each of the defaults is in fact hard coded into the source, > and I am guessing needs to be patched. Probably so. > Curious, is the correct procedure to have arbitrary paths that > people may want to change be a configure option, Or is it unique to > Mac Ports, and just reinplace the files carefully? Hardcoded paths don't seem like a great development decision to have made, but it's up to the developers of the software. If that's what they decided, then we can just patch it to make those paths match what we want in MacPorts. > I will do my best on this one, but it may be out of my league. It > is currently nomaintainer, so I could take it over, but will need a > little handholding I suspect. From matt.cottrell at me.com Fri Oct 9 19:04:27 2009 From: matt.cottrell at me.com (Matthew Cottrell) Date: Fri, 09 Oct 2009 22:04:27 -0400 Subject: Please take a look at ticket 21807 (arb port update) Message-ID: I'm writing to ask if someone with commit privileges could take a look at my update ticket 21807 for the arb port (http://trac.macports.org/ticket/21807 ). This port update was submitted to keep MacPorts up-to-date with with a revision made by the upstream developer. The ticket has not yet received comment after six days. I'd be happy to revise if necessary. The arb port is used by scientists actively working in ecological and environmental microbiology research. Thanks -- Matthew Cottrell Lewes, DE 19958 http://www.mattcottrell.org From akitada at macports.org Fri Oct 9 19:56:07 2009 From: akitada at macports.org (Akira Kitada) Date: Sat, 10 Oct 2009 11:56:07 +0900 Subject: Future of setuptools and distribute in MacPorts In-Reply-To: <20091007202131.GF480@ninagal.withay.com> References: <90bb445a0910071009n6cd810e6gcb1ec9f25fae9749@mail.gmail.com> <20091007202131.GF480@ninagal.withay.com> Message-ID: <90bb445a0910091956p5118e478s882456678f5cec13@mail.gmail.com> On Thu, Oct 8, 2009 at 5:21 AM, Bryan Blackburn wrote: > Moving over to distribute is one possibility, but the discussion on (at > least) distutils-sig seems like the python community hasn't quite decided on > where things are going yet...at least with the patched setuptools things > should still work as well as they have until we have a clearer overall idea > of where things will be going. I think that's not what the Python community decides but the distributer, in this case, the MacPorts community. > Note that I also added py26-distribute, but as you note it does conflict > with py26-setuptools, so moving to it would be painful. ?Maybe it can be the > preferred one for py27 ports? How about starting it now? > > Bryan > >> >> Any suggestions would be appreciated. >> Thanks. > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > From macsforever2000 at macports.org Fri Oct 9 20:22:08 2009 From: macsforever2000 at macports.org (Frank Schima) Date: Fri, 9 Oct 2009 21:22:08 -0600 Subject: Please take a look at ticket 21807 (arb port update) In-Reply-To: References: Message-ID: <2939E102-1FB2-4C76-9141-18B3B3FDB723@macports.org> On Oct 9, 2009, at 8:04 PM, Matthew Cottrell wrote: > I'm writing to ask if someone with commit privileges could take a > look at my update ticket 21807 for the arb port (http://trac.macports.org/ticket/21807 > ). > > This port update was submitted to keep MacPorts up-to-date with with > a revision made by the upstream developer. > > The ticket has not yet received comment after six days. I'd be > happy to revise if necessary. > > The arb port is used by scientists actively working in ecological > and environmental microbiology research. I committed your update in r59128 [1]. [1] Cheers! Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From howarth at bromo.med.uc.edu Fri Oct 9 21:42:05 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 10 Oct 2009 00:42:05 -0400 Subject: tcl needs --disable-corefoundation Message-ID: <20091010044205.GA16463@bromo.med.uc.edu> I finally puzzled out why the transition from MacPorts 1.8.0 to 1.8.1 broke my proposed pymol package. The MacPorts packaging is not building tcl by passing --disable-corefoundation to configure. On fink, we found that the 8.5.7 release broke the core-foundation support and disabled it again. http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.4/unstable/main/finkinfo/languages/tcltk-x86_64.info?view=log I suspect there are bugs that can go latent at times and then reappear in a later release. Without the use of --disable-corefoundation in the tcl build, pymol crashes when built under either python26 or python25 with the error message... Tcl_WaitForEvent: CFRunLoop finished Abort I'll open a bug report for this as well. Jack ps We also seem to be missing the py26-pmw subdirectory. A straight adaption of the py25-pmw subdirectory works fine. From macsforever2000 at macports.org Fri Oct 9 21:59:23 2009 From: macsforever2000 at macports.org (Frank Schima) Date: Fri, 9 Oct 2009 22:59:23 -0600 Subject: tcl needs --disable-corefoundation In-Reply-To: <20091010044205.GA16463@bromo.med.uc.edu> References: <20091010044205.GA16463@bromo.med.uc.edu> Message-ID: <3BD69205-4F6E-41D4-9685-A9A67E1BFB75@macports.org> Hi Jack, On Oct 9, 2009, at 10:42 PM, Jack Howarth wrote: > ps We also seem to be missing the py26-pmw > subdirectory. A straight adaption of the > py25-pmw subdirectory works fine. Thanks for noticing that. I added the port r59133 [1]. [1] Cheers! Frank From talklists at newgeo.com Sat Oct 10 01:14:26 2009 From: talklists at newgeo.com (Scott Haneda) Date: Sat, 10 Oct 2009 01:14:26 -0700 Subject: pureftpd creates files outside of prefix In-Reply-To: <4C496A26-32A0-4885-97F5-8EE241D49ED5@macports.org> References: <6B369ABA-540F-4CAD-94B2-E20EA397BD7A@newgeo.com> <4C496A26-32A0-4885-97F5-8EE241D49ED5@macports.org> Message-ID: <0E2D38F4-1B9D-4891-AD88-8178225BFA00@newgeo.com> On Oct 9, 2009, at 3:44 PM, Ryan Schmidt wrote: > On Oct 9, 2009, at 04:04, Scott Haneda wrote: > >> That path is hard coded, I believe there would need to be a patch >> made for the portfile to change that to that of ${prefix} in front >> of it? > > Basically yes. I mean you may need to patch these to include > @PREFIX@" where you want the prefix, and then later reinplace > @PREFIX@ with the real value of ${prefix}. Why would I patch them and then reinplace, would the patch not suffice? Or is this is little of a chicken and an egg case? >> But this may just be the ftpwho command, and where it looks. I can >> not find solid reference to where the actual creation of the >> scoreboard directory happens at. >> >> The man pages, make multiple references to non ${prefix} based >> locations. I suppose those need cleaning as well? > > Good idea. Can you give me a little pointer on how man pages work, they seem to be 'compiled' to a degree as well, as the files are not entirely readable as they stand. I assume there is a more human readable format of the man page somewhere, but all I find is a a set of files that are in some machine format. I certainly can reinplace these, but if there is an ideal way, I would prefer to learn that. >> Curious, is the correct procedure to have arbitrary paths that >> people may want to change be a configure option, Or is it unique to >> Mac Ports, and just reinplace the files carefully? > > Hardcoded paths don't seem like a great development decision to have > made, but it's up to the developers of the software. If that's what > they decided, then we can just patch it to make those paths match > what we want in MacPorts. I am trying to reach out. I have found one developer on twitter, and gotten one reply, though it is not looking promising. I think my best bet may be to patch the source and submit it for suggested inclusion. That may gain their attention. If not, massaging it around in MP is fine, it just seems like there is so much potential for breakage on updates. >> I will do my best on this one, but it may be out of my league. It >> is currently nomaintainer, so I could take it over, but will need a >> little handholding I suspect. A few general questions, keeping in mind my newness to this. If a man page says "look for the pid file in /path/foo/app.pid and there is a configure argument for setting the pid path, in general, do most apps on build alter the man path to reflect that? In general, is the best approach to try to figure out what your paths are going to be, and provide them as configure arguments? What is the MP suggested method to deal with very well known libraries/ binaries etc to the OS. For example, pureftpd uses /dev/urandom, am I supposed to make a dependency to urandom, assuming there is a port for it, then alter the source to point to urandom within ${prefix}? Where do you draw the line in very well known things the OS provides. Maybe the app needs use of /tmp, I am not aware of MP supporting something like /tmp, so I assume it is safe to work outside of ${prefix} in those cases? If there is a doc on this, it will suffice, not looking to have you teach me too much, just point me along. I do not feel comfortable patching this app exclusively on my own. It does work now, and the issues I am bringing up do not seem to cause any harm it the app working. That being said, I would like to see it cleaned up. If I make the changes, can someone here offer to validate my work? I would love to put in the effort to fix these issues, however, if there is no one that can check my work, I can not in good faith submit it back to ports as I very well may be releasing a buggy piece of junk. I would take notes on the changes I did, and submit them with the portfile, so whoever is looking over my shoulder, would be able to pretty easily see what I was thinking. Thanks. -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Sat Oct 10 01:47:59 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 10 Oct 2009 03:47:59 -0500 Subject: pureftpd creates files outside of prefix In-Reply-To: <0E2D38F4-1B9D-4891-AD88-8178225BFA00@newgeo.com> References: <6B369ABA-540F-4CAD-94B2-E20EA397BD7A@newgeo.com> <4C496A26-32A0-4885-97F5-8EE241D49ED5@macports.org> <0E2D38F4-1B9D-4891-AD88-8178225BFA00@newgeo.com> Message-ID: <77E01C49-A01D-4674-AA2A-B62218E128F2@macports.org> On Oct 10, 2009, at 03:14, Scott Haneda wrote: > On Oct 9, 2009, at 3:44 PM, Ryan Schmidt wrote: > >> On Oct 9, 2009, at 04:04, Scott Haneda wrote: >> >>> That path is hard coded, I believe there would need to be a patch >>> made for the portfile to change that to that of ${prefix} in front >>> of it? >> >> Basically yes. I mean you may need to patch these to include >> @PREFIX@" where you want the prefix, and then later reinplace >> @PREFIX@ with the real value of ${prefix}. > > Why would I patch them and then reinplace, would the patch not > suffice? Or is this is little of a chicken and an egg case? The patch file is a static text file, but the user can use any prefix they like at installation time. Therefore, in your static patch file, you put a known marker (like "@PREFIX@") into the files where you want the prefix to be. Then you use reinplace in the portfile to replace that known marker with whatever the prefix is on the user's machine (the ${prefix} variable). >>> But this may just be the ftpwho command, and where it looks. I >>> can not find solid reference to where the actual creation of the >>> scoreboard directory happens at. >>> >>> The man pages, make multiple references to non ${prefix} based >>> locations. I suppose those need cleaning as well? >> >> Good idea. > > Can you give me a little pointer on how man pages work, they seem to > be 'compiled' to a degree as well, as the files are not entirely > readable as they stand. I assume there is a more human readable > format of the man page somewhere, but all I find is a a set of files > that are in some machine format. man pages are written in the "groff" syntax, and are usually gzip- compressed as well. (MacPorts automatically compresses all manpages after the destroot phase.) The "man" command decompresses manpages and compiles them into displayable form using the troff command on the fly. I have not particularly learned the groff syntax, but as long as all you're doing is changing one path to another, they're pretty easy to edit. > I certainly can reinplace these, but if there is an ideal way, I > would prefer to learn that. Patch the files to contain @PREFIX@, then reinplace that with $ {prefix}, as above. >>> Curious, is the correct procedure to have arbitrary paths that >>> people may want to change be a configure option, Or is it unique >>> to Mac Ports, and just reinplace the files carefully? >> >> Hardcoded paths don't seem like a great development decision to >> have made, but it's up to the developers of the software. If that's >> what they decided, then we can just patch it to make those paths >> match what we want in MacPorts. > > I am trying to reach out. I have found one developer on twitter, > and gotten one reply, though it is not looking promising. I think > my best bet may be to patch the source and submit it for suggested > inclusion. That may gain their attention. > > If not, massaging it around in MP is fine, it just seems like there > is so much potential for breakage on updates. If there is breakage on updates, you will immediately learn of it by virtue of the fact that the existing patch will fail to apply to the new source. You can then investigate how the source has changed so that you can update the patch so it works again. > If a man page says "look for the pid file in /path/foo/app.pid and > there is a configure argument for setting the pid path, in general, > do most apps on build alter the man path to reflect that? In general, man pages should probably describe the paths the software would use by default. (Users probably understand that if paths are configurable, then the documentation will not reflect such customizations.) It would be a good idea for ports to patch related man pages so that they describe any changes the portfile author has made in the port. I expect many ports do not do this out of laziness or forgetfulness, but ideally they should. > In general, is the best approach to try to figure out what your > paths are going to be, and provide them as configure arguments? You're talking about a best practice for software developers? I don't know, it probably depends on the software. Some paths are so common that they need no end user configuration. As you say below, /tmp is quite common. Conceivably an operating system could have its temporary directory in a different place. On Mac OS X for example, /tmp works, but it's really a symlink to /private/tmp, and for some reason there's a second temporary directory at /var/tmp, where /var is really a symlink to /private/var. If there exists another OS where there is no /tmp at all, then a program could add logic to its configure script to detect that OS and use an appropriate alternate temporary directory. There are other paths (like the installation prefix itself) which are useful for a packager (like a MacPorts maintainer) to set at compile time but which an end user probably doesn't need to be concerned with. Other kinds of paths might be very relevant to the end user and would be better configured in a config file, alterable after installation time. For example, in apache2, you can specify where your web files live by editing httpd.conf; it would be rather restrictive to only be able to set that kind of thing at compile time as a configure argument. For some software, the only way to change paths might be to edit the source code directly. This might be more likely in software that has not yet matured, or is small, or is developed by one or few individuals, etc. > What is the MP suggested method to deal with very well known > libraries/binaries etc to the OS. For example, pureftpd uses /dev/ > urandom, am I supposed to make a dependency to urandom, assuming > there is a port for it, then alter the source to point to urandom > within ${prefix}? /dev/urandom is not a software program; it is a device. Programs that want some quantity of random bytes obtain these by reading from /dev/ urandom. [1] http://en.wikipedia.org/wiki/Device_file_system Not all operating systems have /dev/urandom. (Some instead have only / dev/random, for example.) But you can rely on /dev/urandom existing on Mac OS X. > Where do you draw the line in very well known things the OS > provides. Maybe the app needs use of /tmp, I am not aware of MP > supporting something like /tmp, so I assume it is safe to work > outside of ${prefix} in those cases? If there is a doc on this, it > will suffice, not looking to have you teach me too much, just point > me along. You can rely on /tmp existing on Mac OS X. Software that needs to write temporary files should feel free to use /tmp. Attempting to create files there during any portfile phase might result in a warning if you use trace mode. But trace mode doesn't always work in all situations and can give false positives anyway. If you need to create a temporary file or directory in a portfile phase, the procedures mktemp and mkdtemp exist for this purpose. They are used in a few places in MacPorts base and by a few ports, so you can find examples of their use. > I do not feel comfortable patching this app exclusively on my own. > It does work now, and the issues I am bringing up do not seem to > cause any harm it the app working. That being said, I would like to > see it cleaned up. If I make the changes, can someone here offer to > validate my work? I would love to put in the effort to fix these > issues, however, if there is no one that can check my work, I can > not in good faith submit it back to ports as I very well may be > releasing a buggy piece of junk. > > I would take notes on the changes I did, and submit them with the > portfile, so whoever is looking over my shoulder, would be able to > pretty easily see what I was thinking. My reviews of portfiles often just consist of verifying they install, do not produce mtree warnings, do not link with libraries they don't declare dependencies on, that they're UsingTheRightCompiler, that livecheck works, that the universal variant works, etc. Usually just a subset of those unless I'm feeling particularly ambitious. But I seldom check that the software being ported works properly, because I would seldom have the expertise needed to do so. For example, I haven't ever set up an ftp server, so trying to figure out how to set up pureftpd and verify it works correctly would be much more effort than I would be willing to put in. Since you're interested in the software and presumably use it, you may be the best one to verify it works. And of course, if we commit it and it's broken in some way, I'm sure other users will notice and submit bug reports, and we can fix it then. This is not to say we shouldn't carefully test things before committing, but there's a limit to how thorough we need to be. :) From raimue at macports.org Sat Oct 10 04:37:19 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 10 Oct 2009 13:37:19 +0200 Subject: Future of setuptools and distribute in MacPorts In-Reply-To: <20091007202131.GF480@ninagal.withay.com> References: <90bb445a0910071009n6cd810e6gcb1ec9f25fae9749@mail.gmail.com> <20091007202131.GF480@ninagal.withay.com> Message-ID: <4AD071EF.40100@macports.org> On 2009-10-07 22:21 , Bryan Blackburn wrote: > Note that I also added py26-distribute, but as you note it does conflict > with py26-setuptools, so moving to it would be painful. Maybe it can be the > preferred one for py27 ports? We could use a replaced_by to get rid of py26-setuptools completely and avoid the conflict. Rainer From matt.cottrell at me.com Sat Oct 10 06:24:55 2009 From: matt.cottrell at me.com (Matthew Cottrell) Date: Sat, 10 Oct 2009 09:24:55 -0400 Subject: Please take a look at ticket 21807 (arb port update) In-Reply-To: <2939E102-1FB2-4C76-9141-18B3B3FDB723@macports.org> References: <2939E102-1FB2-4C76-9141-18B3B3FDB723@macports.org> Message-ID: <54E44C45-FBAF-4C69-8BA9-13E74840170F@me.com> Thanks for committing my port update. That helps a lot. On Oct 9, 2009, at 11:22 PM, Frank Schima wrote: > On Oct 9, 2009, at 8:04 PM, Matthew Cottrell wrote: > >> I'm writing to ask if someone with commit privileges could take a >> look at my update ticket 21807 for the arb port (http://trac.macports.org/ticket/21807 >> ). >> >> This port update was submitted to keep MacPorts up-to-date with >> with a revision made by the upstream developer. >> >> The ticket has not yet received comment after six days. I'd be >> happy to revise if necessary. >> >> The arb port is used by scientists actively working in ecological >> and environmental microbiology research. > > I committed your update in r59128 [1]. > > > [1] > > Cheers! > Frank > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev -- Matthew Cottrell Lewes, DE 19958 http://www.mattcottrell.org From jwa at macports.org Sat Oct 10 07:44:09 2009 From: jwa at macports.org (Jyrki Wahlstedt) Date: Sat, 10 Oct 2009 17:44:09 +0300 Subject: wxPython-devel fork? In-Reply-To: <6F8354EC-EBBD-4E7D-8403-7699659076BD@macports.org> References: <09CA7862-FEB5-4DC2-ACAB-1B42921AB7A4@macports.org> <6F8354EC-EBBD-4E7D-8403-7699659076BD@macports.org> Message-ID: On 8.10.2009, at 19.25, Frank Schima wrote: > Hi Vince, > > > On Sep 23, 2009, at 5:04 AM, vincent habchi wrote: > >> I have ported the Grass (v. 6.4) GIS app to MacPorts in my private >> tree. However, Grass relies on Wxpython. In order to get a >> universal build, I had to use the svn version of Wxpython, the only >> one compatible with the newest wxWidgets 2.9.0, which features the >> osx_cocoa 32/64-build. >> >> The standard wxWidgets-devel Portfile, while up to date, lacks the >> universal/cocoa option. I have a private version of the port called >> wxWidgets29, that serves as a foundation for both my private "py26- >> wxpython-devel" port and Grass. >> >> In order to commit Grass and py26-wxpython-devel, is it reasonable >> to fork wxwindows-devel in wxwindows29 or shall I modify the >> wxwindows-devel portfile? I proposed the patched version to the >> owners, but got no response. I feel wxwindows-devel should follow >> wxWindows development (even into 3.0) while wxwindows29 could be >> used only for the 2.9 unstable branch. >> >> Opinion? > > Since there are no opinions on this, I'd say do what you think is > best. I think your proposal makes sense. With regards to grass, I > would update the current "grass" port to 6.4 and link to the wx*- > devel ports, and make a new "grass63" port with the current grass > portfile. Usually the ports with a version in the name are the old > ones. > > Hi, I'd say it would be most reasonable to modify the current wxWidgets- devel (since it's a -devel port, one is free to experiment, or?). ! ! Jyrki Wahlstedt ! http://www.wahlstedt.fi/jyrki/ ! ! Our life is no dream; but it ought to become one and perhaps will. ! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0 A780 6366 EFD9 139C C386 From howarth at bromo.med.uc.edu Sat Oct 10 10:44:56 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 10 Oct 2009 13:44:56 -0400 Subject: tcl needs --disable-corefoundation In-Reply-To: <3BD69205-4F6E-41D4-9685-A9A67E1BFB75@macports.org> References: <20091010044205.GA16463@bromo.med.uc.edu> <3BD69205-4F6E-41D4-9685-A9A67E1BFB75@macports.org> Message-ID: <20091010174456.GA25704@bromo.med.uc.edu> On Fri, Oct 09, 2009 at 10:59:23PM -0600, Frank Schima wrote: > Hi Jack, > > > On Oct 9, 2009, at 10:42 PM, Jack Howarth wrote: > >> ps We also seem to be missing the py26-pmw >> subdirectory. A straight adaption of the >> py25-pmw subdirectory works fine. > > Thanks for noticing that. I added the port r59133 [1]. > > > [1] > > Cheers! > Frank Frank, I also noticed that we don't have a py26-tkinter stub package for python26. Why is that? Also, why do we build python26 and install it as a framework? Was there a specific reason for that change compared to how the python25 package is built? Jack From macsforever2000 at macports.org Sat Oct 10 11:24:55 2009 From: macsforever2000 at macports.org (Frank Schima) Date: Sat, 10 Oct 2009 12:24:55 -0600 Subject: tcl needs --disable-corefoundation In-Reply-To: <20091010174456.GA25704@bromo.med.uc.edu> References: <20091010044205.GA16463@bromo.med.uc.edu> <3BD69205-4F6E-41D4-9685-A9A67E1BFB75@macports.org> <20091010174456.GA25704@bromo.med.uc.edu> Message-ID: <3E6A2026-E9B7-4D29-BB03-8BAFF52F122A@macports.org> On Oct 10, 2009, at 11:44 AM, Jack Howarth wrote: > Frank, > I also noticed that we don't have a py26-tkinter stub > package for python26. Why is that? Also, why do we build > python26 and install it as a framework? Was there a specific > reason for that change compared to how the python25 package > is built? The tkinter module is built into python25 and python26. It used to be the case that it was a separate port for python25, but later versions of the python25 port have it built in so we turned py25-tkinter into a stub package for those that had it installed. I think that when the python26 port was made, tkinter was already built in, hence there was no need to make an empty stub package for it. The framework issue is a little more complex and someone will hopefully correct me if I'm wrong. The original python25 port was not a framework build. It was determined that a framework build was more desirable. I cannot remember the exact reasoning right now. There are a few tickets about this such as [1] and [2]. python25 was eventually made partially a framework build and we had to fix a few ports to work around that. When python26 (and above) was made, we decided to make it a framework build from the beginning. [1] [2] Cheers! Frank From ryandesign at macports.org Sat Oct 10 16:45:51 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 10 Oct 2009 18:45:51 -0500 Subject: [59162] trunk/dports/science/netcdf/Portfile In-Reply-To: <20091010195428.6CF792989FBD@beta.macosforge.org> References: <20091010195428.6CF792989FBD@beta.macosforge.org> Message-ID: On Oct 10, 2009, at 14:54, adfernandes at macports.org wrote: > Modified Paths: > -------------- > trunk/dports/science/netcdf/Portfile > + configure.env-append LDFLAGS=-L${prefix}/lib LIBS=-lhdf5 Note that you don't need to manually put LDFLAGS=-L${prefix}/lib into the configure environment. MacPorts automatically does this for you. If you ever need to change the LDFLAGS, you can do so by setting the variable configure.ldflags. From mark at dxradio.demon.co.uk Sat Oct 10 20:57:37 2009 From: mark at dxradio.demon.co.uk (Mark Hattam) Date: Sun, 11 Oct 2009 04:57:37 +0100 Subject: [59139] trunk/dports/mail/getmail/Portfile In-Reply-To: <20091010064439.2257A2980596@beta.macosforge.org> References: <20091010064439.2257A2980596@beta.macosforge.org> Message-ID: <5AF873C3-FD22-4C79-80F3-383D8FF9D6B6@dxradio.demon.co.uk> On 10 Oct 2009, at 07:44, blb at macports.org wrote: > Revision > 59139 > Author > blb at macports.org > Date > 2009-10-09 23:44:36 -0700 (Fri, 09 Oct 2009) > Log Message > > mail/getmail - switch to python 2.6, ticket #21192 (maintainer > timeout) > Modified Paths > > ? trunk/dports/mail/getmail/Portfile > Diff > > Modified: trunk/dports/mail/getmail/Portfile (59138 => 59139) > > --- trunk/dports/mail/getmail/Portfile 2009-10-10 06:18:33 UTC (rev > 59138) > +++ trunk/dports/mail/getmail/Portfile 2009-10-10 06:44:36 UTC (rev > 59139) > > @@ -1,10 +1,11 @@ > > # $Id$ > > > > PortSystem 1.0 > > -PortGroup python25 1.0 > > +PortGroup python26 1.0 > > > > name getmail > > version 4.11.0 > > +revision 1 > > categories mail python > > platforms darwin > > maintainers mww > > @@ -23,3 +24,17 @@ > > dist_subdir ${name} > > patchfiles patch-setup.py.diff > > > > +post-destroot { > + foreach binfile [glob -tails -directory ${destroot}$ > {python.prefix}/bin *] { > + ln -s ${python.prefix}/bin/${binfile} \ > + ${destroot}${prefix}/bin/${binfile} > + } > + foreach manfile [glob -tails -directory ${destroot}$ > {python.prefix}/share/man/man1 *] { > + ln -s ${python.prefix}/share/man/man1/${manfile} \ > + ${destroot}${prefix}/share/man/man1/${manfile} > + } > + delete ${destroot}${prefix}/share/doc/${name} > + move ${destroot}${python.prefix}/share/doc/${name} \ > + ${destroot}${prefix}/share/doc > +} > + > > _______________________________________________ > macports-changes mailing list > macports-changes at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-changes So does getmail now depend on both python25 and python26? I thought that after updating getmail [59139], which caused the installation of python26, although python25 got updated too due to [59156] in the same "sudo port upgrade outdated" run, that I'd be able to uninstall python25 since nothing else needs it. But it says getmail still depends on it. iMac:~ mark$ sudo port installed The following ports are currently installed: getmail @4.11.0_1 (active) python25 @2.5.4_8+darwin_10+macosx (active) python26 @2.6.3_0+darwin (active) python_select @0.3_0+darwin_10 (active) iMac:~ mark$ sudo port uninstall python25 ---> Unable to uninstall python25 2.5.4_8+darwin_10+macosx, the following ports depend on it: ---> getmail Error: port uninstall failed: Please uninstall the ports that depend on python25 first. iMac:~ mark$ sudo port uninstall python26 ---> Unable to uninstall python26 2.6.3_0+darwin, the following ports depend on it: ---> getmail Error: port uninstall failed: Please uninstall the ports that depend on python26 first. Mark From jeremy at lavergne.gotdns.org Sat Oct 10 23:26:45 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sun, 11 Oct 2009 02:26:45 -0400 Subject: port algae: remove? Message-ID: ya or nay? it has gcc34 as a dep. yup, 34, not 43. From blb at macports.org Sun Oct 11 00:13:28 2009 From: blb at macports.org (Bryan Blackburn) Date: Sun, 11 Oct 2009 01:13:28 -0600 Subject: [59139] trunk/dports/mail/getmail/Portfile In-Reply-To: <5AF873C3-FD22-4C79-80F3-383D8FF9D6B6@dxradio.demon.co.uk> References: <20091010064439.2257A2980596@beta.macosforge.org> <5AF873C3-FD22-4C79-80F3-383D8FF9D6B6@dxradio.demon.co.uk> Message-ID: <20091011071328.GA65456@ninagal.withay.com> On Sun, Oct 11, 2009 at 04:57:37AM +0100, Mark Hattam said: [...] > > So does getmail now depend on both python25 and python26? > > I thought that after updating getmail [59139], which caused the > installation of python26, although python25 got updated too due to > [59156] in the same "sudo port upgrade outdated" run, that I'd be > able to uninstall python25 since nothing else needs it. > But it says getmail still depends on it. > > iMac:~ mark$ sudo port installed > The following ports are currently installed: > getmail @4.11.0_1 (active) > python25 @2.5.4_8+darwin_10+macosx (active) > python26 @2.6.3_0+darwin (active) > python_select @0.3_0+darwin_10 (active) > > iMac:~ mark$ sudo port uninstall python25 > ---> Unable to uninstall python25 2.5.4_8+darwin_10+macosx, the > following ports depend on it: > ---> getmail > Error: port uninstall failed: Please uninstall the ports that depend > on python25 first. getmail does now depend on only python26, what you are seeing is ticket #13054: You should be able to safely force the uninstall of python25 since it uses 2.6. [...] > > Mark From jmr at macports.org Sun Oct 11 00:58:55 2009 From: jmr at macports.org (Joshua Root) Date: Sun, 11 Oct 2009 18:58:55 +1100 Subject: tcl needs --disable-corefoundation In-Reply-To: <20091010174456.GA25704@bromo.med.uc.edu> References: <20091010044205.GA16463@bromo.med.uc.edu> <3BD69205-4F6E-41D4-9685-A9A67E1BFB75@macports.org> <20091010174456.GA25704@bromo.med.uc.edu> Message-ID: <4AD1903F.9000404@macports.org> On 2009-10-11 04:44, Jack Howarth wrote: > Also, why do we build > python26 and install it as a framework? Was there a specific > reason for that change compared to how the python25 package > is built? Well, python25 is also installed as a framework, and the reason for that is that you don't get pythonw otherwise. - Josh From neric27 at wanadoo.fr Sun Oct 11 02:48:32 2009 From: neric27 at wanadoo.fr (Eric) Date: Sun, 11 Oct 2009 11:48:32 +0200 Subject: [59189] py26-eyed3 Lint Report In-Reply-To: <20091011091003.02D7E7B72822@mail-out4.apple.com> References: <20091011091003.02D7E7B72822@mail-out4.apple.com> Message-ID: <4AD1A9F0.7080007@wanadoo.fr> Maybe the guide should be updated, then... Because I just did a copy'n-paste from there. Cheers, noreply at macports.org a ?crit : > Change: http://trac.macports.org/changeset/59189 > Portfile: py26-eyed3 > > Warning: Using deprecated option 'livecheck.check', superseded by 'livecheck.type' > > > > > > From neric27 at wanadoo.fr Sun Oct 11 03:18:48 2009 From: neric27 at wanadoo.fr (Eric) Date: Sun, 11 Oct 2009 12:18:48 +0200 Subject: [59189] py26-eyed3 Lint Report In-Reply-To: <4AD1A9F0.7080007@wanadoo.fr> References: <20091011091003.02D7E7B72822@mail-out4.apple.com> <4AD1A9F0.7080007@wanadoo.fr> Message-ID: <4AD1B108.1020300@wanadoo.fr> Here is a patch http://trac.macports.org/ticket/21991 Eric a ?crit : > Maybe the guide should be updated, then... > Because I just did a copy'n-paste from there. > Cheers, > > noreply at macports.org a ?crit : > >> Change: http://trac.macports.org/changeset/59189 >> Portfile: py26-eyed3 >> >> Warning: Using deprecated option 'livecheck.check', superseded by 'livecheck.type' >> >> >> >> >> >> >> > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > > From raimue at macports.org Sun Oct 11 04:32:25 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 11 Oct 2009 13:32:25 +0200 Subject: [59189] py26-eyed3 Lint Report In-Reply-To: <4AD1B108.1020300@wanadoo.fr> References: <20091011091003.02D7E7B72822@mail-out4.apple.com> <4AD1A9F0.7080007@wanadoo.fr> <4AD1B108.1020300@wanadoo.fr> Message-ID: <4AD1C249.9050505@macports.org> On 2009-10-11 12:18 , Eric wrote: > Here is a patch http://trac.macports.org/ticket/21991 Thanks, committed in r59194. Rainer From howarth at bromo.med.uc.edu Sun Oct 11 10:21:51 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 11 Oct 2009 13:21:51 -0400 Subject: tcl needs --disable-corefoundation In-Reply-To: <4AD1903F.9000404@macports.org> References: <20091010044205.GA16463@bromo.med.uc.edu> <3BD69205-4F6E-41D4-9685-A9A67E1BFB75@macports.org> <20091010174456.GA25704@bromo.med.uc.edu> <4AD1903F.9000404@macports.org> Message-ID: <20091011172151.GA24093@bromo.med.uc.edu> On Sun, Oct 11, 2009 at 06:58:55PM +1100, Joshua Root wrote: > On 2009-10-11 04:44, Jack Howarth wrote: > > Also, why do we build > > python26 and install it as a framework? Was there a specific > > reason for that change compared to how the python25 package > > is built? > > Well, python25 is also installed as a framework, and the reason for that > is that you don't get pythonw otherwise. > > - Josh Josh, I am confused though as to why the python26 package doesn't provide the same access to its headers and development libraries as the python25 package. In the case of the of python25 for example, we have the headers included in /opt/local/include/python2.5 with a symlink in /opt/local/Library/Frameworks/Python.framework/Versions/2.5/include. In the case of python26, we don't have anything in /opt/local/include. This means that the pymol patch had to be changed to use... -PYTHON_INC_DIR = -I/sw/include/python2.3 \ - -I/sw/include/python2.3/Numeric +PYTHON_INC_DIR = -I at PREFIX@/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 \ + -I at PREFIX@/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/Numeric etc. Likewise, in python25, we have the actual subdirectory in /opt/local/lib/python2.5 with a symlink to that directory in /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib whereas with python26 there is nothing in /opt/local/lib. These seme like pretty radical changes in the packaging between python25 and python26. Jack From raimue at macports.org Sun Oct 11 10:48:37 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 11 Oct 2009 19:48:37 +0200 Subject: tcl needs --disable-corefoundation In-Reply-To: <20091011172151.GA24093@bromo.med.uc.edu> References: <20091010044205.GA16463@bromo.med.uc.edu> <3BD69205-4F6E-41D4-9685-A9A67E1BFB75@macports.org> <20091010174456.GA25704@bromo.med.uc.edu> <4AD1903F.9000404@macports.org> <20091011172151.GA24093@bromo.med.uc.edu> Message-ID: <4AD21A75.9000109@macports.org> On 2009-10-11 19:21 , Jack Howarth wrote: > I am confused though as to why the python26 package doesn't provide > the same access to its headers and development libraries as the python25 > package. In the case of the of python25 for example, we have the headers > included in /opt/local/include/python2.5 with a symlink in > /opt/local/Library/Frameworks/Python.framework/Versions/2.5/include. As I committed the transition of python25 I had to make a few drawbacks to keep it compatible with existing py25-* ports and thus I kept the directories in the original location. But later we discovered that this causes problems for some ports (infamous "Not a directory" issue). The problem appears when you have a symlink and a port then tries to use that as a regular directory. Therefore no symlinks anymore for python26 to avoid problems. > In > the case of python26, we don't have anything in /opt/local/include. This > means that the pymol patch had to be changed to use... > > -PYTHON_INC_DIR = -I/sw/include/python2.3 \ > - -I/sw/include/python2.3/Numeric Actually software should be asking python where it's headers are (by using python*-config or requesting the path to lib/python2.6/config/Makefile). The assumption of include/python* does just not always hold true. > +PYTHON_INC_DIR = -I at PREFIX@/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 \ > + -I at PREFIX@/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/Numeric > > etc. Likewise, in python25, we have the actual subdirectory in > /opt/local/lib/python2.5 with a symlink to that directory in > /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib > whereas with python26 there is nothing in /opt/local/lib. These > seme like pretty radical changes in the packaging between > python25 and python26. Yes, it's the way python wants it when being build as a framework. As a result python based ports have to symlink any important files installed in the python prefix (e.g. in bin/ or share/) back to the regular prefix. Rainer From raimue at macports.org Sun Oct 11 11:07:39 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 11 Oct 2009 20:07:39 +0200 Subject: port algae: remove? In-Reply-To: References: Message-ID: <4AD21EEB.1060204@macports.org> On 2009-10-11 08:26 , Jeremy Lavergne wrote: > ya or nay? > > it has gcc34 as a dep. yup, 34, not 43. Agreed, remove it. Last upstream release is from 2004. Rainer From howarth at bromo.med.uc.edu Sun Oct 11 11:10:50 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 11 Oct 2009 14:10:50 -0400 Subject: tcl needs --disable-corefoundation In-Reply-To: <4AD21A75.9000109@macports.org> References: <20091010044205.GA16463@bromo.med.uc.edu> <3BD69205-4F6E-41D4-9685-A9A67E1BFB75@macports.org> <20091010174456.GA25704@bromo.med.uc.edu> <4AD1903F.9000404@macports.org> <20091011172151.GA24093@bromo.med.uc.edu> <4AD21A75.9000109@macports.org> Message-ID: <20091011181050.GA24324@bromo.med.uc.edu> On Sun, Oct 11, 2009 at 07:48:37PM +0200, Rainer M?ller wrote: > > Actually software should be asking python where it's headers are (by > using python*-config or requesting the path to > lib/python2.6/config/Makefile). The assumption of include/python* does > just not always hold true. > Rainer, The configure in pymol is rather broken and creates dylibs for the python modules in the wrong location (hence all of the nasty hacks in the previously proposed package for pymol 1.1)... https://trac.macports.org/attachment/ticket/17419/Portfile It is much simplier to just avoid configure and use the unix based .delsci Makefiles to properly build pymol... http://trac.macports.org/ticket/21376 I could patch the Makefiles to execute python*-config within the Makefiles but since MacPorts doesn't support packages as -py variants like fink that seems rather pointless. I'll just change the patch to redirect towards the headers and shared libraries when I update the proposed packaging to build against python26. Jack From howarth at bromo.med.uc.edu Sun Oct 11 11:29:06 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 11 Oct 2009 14:29:06 -0400 Subject: getting pymol into ports/science? Message-ID: <20091011182906.GA24543@bromo.med.uc.edu> I have had pymol as an open ticket for several weeks now... http://trac.macports.org/ticket/21376 What exactly is the process for getting a package into the dports archive so that it is available to other users? The absence of scientific packages like pymol costs MacPorts a lot of potential users. It also is one if the most severe tests of the OpenGL support in X11 so it should be available for testing the Xquartz releases on MacPorts. Currently it works fine when built against a tcl which uses--disable-core-foundation... http://trac.macports.org/ticket/21968 FYI, if MacPorts had wider range of packages, the breakage in tcl (as of 8.5.7) would have been more easily noticed. Jack From jeremyhu at macports.org Sun Oct 11 12:50:04 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Sun, 11 Oct 2009 12:50:04 -0700 Subject: tcl needs --disable-corefoundation In-Reply-To: <20091011181050.GA24324@bromo.med.uc.edu> References: <20091010044205.GA16463@bromo.med.uc.edu> <3BD69205-4F6E-41D4-9685-A9A67E1BFB75@macports.org> <20091010174456.GA25704@bromo.med.uc.edu> <4AD1903F.9000404@macports.org> <20091011172151.GA24093@bromo.med.uc.edu> <4AD21A75.9000109@macports.org> <20091011181050.GA24324@bromo.med.uc.edu> Message-ID: <3745307C-670C-4F9C-B432-F5FDC1FA336A@macports.org> On Oct 11, 2009, at 11:10, Jack Howarth wrote: > On Sun, Oct 11, 2009 at 07:48:37PM +0200, Rainer M?ller wrote: >> >> Actually software should be asking python where it's headers are (by >> using python*-config or requesting the path to >> lib/python2.6/config/Makefile). The assumption of include/python* >> does >> just not always hold true. > > I could patch the Makefiles to execute python*-config within > the Makefiles but since MacPorts doesn't support packages as -py > variants like fink that seems rather pointless. I'll just change > the patch to redirect towards the headers and shared libraries > when I update the proposed packaging to build against python26. Why not just fix it "the right way" and query python-config? That way if something changes in the future, it will "just work" and you can push that patch upstream, so others will inherit it as well... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3333 bytes Desc: not available URL: From ryandesign at macports.org Sun Oct 11 13:32:17 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 11 Oct 2009 15:32:17 -0500 Subject: getting pymol into ports/science? In-Reply-To: <20091011182906.GA24543@bromo.med.uc.edu> References: <20091011182906.GA24543@bromo.med.uc.edu> Message-ID: On Oct 11, 2009, at 13:29, Jack Howarth wrote: > I have had pymol as an open ticket for several weeks > now... > > http://trac.macports.org/ticket/21376 > > What exactly is the process for getting a package > into the dports archive so that it is available to other > users? You file a ticket, and if nobody commits it after a few days, you ping the list, like you're doing now. > The absence of scientific packages like pymol > costs MacPorts a lot of potential users. It also is > one if the most severe tests of the OpenGL support > in X11 so it should be available for testing the > Xquartz releases on MacPorts. Currently it works fine > when built against a tcl which uses--disable-core-foundation... > > http://trac.macports.org/ticket/21968 I've assigned the ticket to tcl's maintainer for comment. But if he doesn't, we can feel free to commit it since the port is openmaintainer. > FYI, if MacPorts had wider range of packages, the breakage > in tcl (as of 8.5.7) would have been more easily noticed. That could be true. :) Thank you for contributing pymol and discovering this problem. From howarth at bromo.med.uc.edu Sun Oct 11 13:44:46 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 11 Oct 2009 16:44:46 -0400 Subject: tcl needs --disable-corefoundation In-Reply-To: <3745307C-670C-4F9C-B432-F5FDC1FA336A@macports.org> References: <20091010044205.GA16463@bromo.med.uc.edu> <3BD69205-4F6E-41D4-9685-A9A67E1BFB75@macports.org> <20091010174456.GA25704@bromo.med.uc.edu> <4AD1903F.9000404@macports.org> <20091011172151.GA24093@bromo.med.uc.edu> <4AD21A75.9000109@macports.org> <20091011181050.GA24324@bromo.med.uc.edu> <3745307C-670C-4F9C-B432-F5FDC1FA336A@macports.org> Message-ID: <20091011204446.GA25592@bromo.med.uc.edu> On Sun, Oct 11, 2009 at 12:50:04PM -0700, Jeremy Huddleston wrote: > > Why not just fix it "the right way" and query python-config? That way > if something changes in the future, it will "just work" and you can push > that patch upstream, so others will inherit it as well... > Jeremy, Using... -PYTHON_INC_DIR = -I/sw/include/python2.3 \ - -I/sw/include/python2.3/Numeric +PYTHON_INC_DIR = `python2.6-config --include`/Numeric seems to be sufficient. It really isn't worth the effort at this point to try to fix pymol's configure build but I will ping the pymol developer on that and see if he is willing to change it to not build dylibs. Am I correct in assuming that it is best practices to construct packaging that builds against python25 or python26 without requiring the associated python to be activated? I believe the current pymol packaging should now build regardless of the activation state of python26 with the above change. Jack From howarth at bromo.med.uc.edu Sun Oct 11 13:56:47 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 11 Oct 2009 16:56:47 -0400 Subject: getting pymol into ports/science? In-Reply-To: References: <20091011182906.GA24543@bromo.med.uc.edu> Message-ID: <20091011205647.GA25676@bromo.med.uc.edu> On Sun, Oct 11, 2009 at 03:32:17PM -0500, Ryan Schmidt wrote: > > >> FYI, if MacPorts had wider range of packages, the breakage >> in tcl (as of 8.5.7) would have been more easily noticed. > > That could be true. :) Thank you for contributing pymol and discovering > this problem. Ryan, If you want a quick demo of what pymol can do, after installing a tcl with --disable-core-foundation and the current pymol packaging on http://trac.macports.org/ticket/21376, you can test it with... 1) Execute 'pymol' on a terminal. 2) Select the 'Wizard->Demo->Representations' menu item from the pymol menu bar. 3) Click through on each of the buttons in the 'Demonstrations' panel in the Pymol Viewer window. This will show you each demo in turn. Jack ps I have several associated tickets for adding apbs/apbs-mpi packages for generating electrostatic surfaces in pymol as well as a pdb2pqr package to generate the required pqr files for apbs to use. Altogether this is a very useful set of programs. pps I have also pinged the tcl developer who submitted the core-foundation changes for 8.5.7. In fink, we have always had issues with core-foundation being unstable in tcl from release to release. It has tended to be broken more often than not. However this may be due to the lack of X11 testing that upstream gives tcl (compared to testing the native aqua tcl version). From raimue at macports.org Sun Oct 11 14:51:26 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sun, 11 Oct 2009 23:51:26 +0200 Subject: tcl needs --disable-corefoundation In-Reply-To: <20091011204446.GA25592@bromo.med.uc.edu> References: <20091010044205.GA16463@bromo.med.uc.edu> <3BD69205-4F6E-41D4-9685-A9A67E1BFB75@macports.org> <20091010174456.GA25704@bromo.med.uc.edu> <4AD1903F.9000404@macports.org> <20091011172151.GA24093@bromo.med.uc.edu> <4AD21A75.9000109@macports.org> <20091011181050.GA24324@bromo.med.uc.edu> <3745307C-670C-4F9C-B432-F5FDC1FA336A@macports.org> <20091011204446.GA25592@bromo.med.uc.edu> Message-ID: <4AD2535E.5080506@macports.org> On 2009-10-11 22:44 , Jack Howarth wrote: > Am I correct in assuming that it is best practices to > construct packaging that builds against python25 or python26 > without requiring the associated python to be activated? > I believe the current pymol packaging should now build > regardless of the activation state of python26 with the above > change. Any file in the prefix comes from an active port. Inactive ports are "invisible" and cannot be used from other ports. See Rainer From howarth at bromo.med.uc.edu Sun Oct 11 17:40:12 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 11 Oct 2009 20:40:12 -0400 Subject: tcl needs --disable-corefoundation In-Reply-To: <4AD2535E.5080506@macports.org> References: <20091010044205.GA16463@bromo.med.uc.edu> <3BD69205-4F6E-41D4-9685-A9A67E1BFB75@macports.org> <20091010174456.GA25704@bromo.med.uc.edu> <4AD1903F.9000404@macports.org> <20091011172151.GA24093@bromo.med.uc.edu> <4AD21A75.9000109@macports.org> <20091011181050.GA24324@bromo.med.uc.edu> <3745307C-670C-4F9C-B432-F5FDC1FA336A@macports.org> <20091011204446.GA25592@bromo.med.uc.edu> <4AD2535E.5080506@macports.org> Message-ID: <20091012004012.GA26704@bromo.med.uc.edu> On Sun, Oct 11, 2009 at 11:51:26PM +0200, Rainer M?ller wrote: > On 2009-10-11 22:44 , Jack Howarth wrote: > > Am I correct in assuming that it is best practices to > > construct packaging that builds against python25 or python26 > > without requiring the associated python to be activated? > > I believe the current pymol packaging should now build > > regardless of the activation state of python26 with the above > > change. > > Any file in the prefix comes from an active port. Inactive ports are > "invisible" and cannot be used from other ports. > > See > > Rainer Rainer, The current behavior seems really confused. For example, if I have python25 and python26 installed but only python26 activated, I can install py25-setuptools with out errors being reported. However, if I execute... sudo port install py25-pmw I get an error... DEBUG: Found Dependency: receipt exists for python26 ---> Activating py25-pmw @1.3.2_1 DEBUG: Image error: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/Pmw/__init__.py is being used by the active py26-pmw port. Please deactivate this port first, or use 'port -f activate py25-pmw' to force the activation. while executing "_activate_contents $name $imagefiles $imagedir" (procedure "portimage::activate" line 56) invoked from within "registry_activate $name ${version}_${revision}${portvariants} [array get user_options]" (procedure "eval_targets" line 21) invoked from within "eval_targets activate" invoked from within "$workername eval eval_targets $target" (procedure "mportexec" line 85) invoked from within "mportexec $workername $target" If I follow the recommendation and execute... sudo port -f activate py25-pmw I get errors... Warning: File /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/Pmw/__init__.py already exists. Moving to: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/Pmw/__init__.py.mp_1255307467. etc. The logic of maintaining multiple pythons seem horribly convoluted and very fragile (at least if you follow the recommendations in the error messages). Wouldn't it be better to just have any Portfile that needs access to python25 or python26, explicitly depend on it and, if not activated, allow port to request for and implement the activation in real time during the build? Jack From howarth at bromo.med.uc.edu Sun Oct 11 18:01:09 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 11 Oct 2009 21:01:09 -0400 Subject: tcl needs --disable-corefoundation In-Reply-To: <20091012004012.GA26704@bromo.med.uc.edu> References: <3BD69205-4F6E-41D4-9685-A9A67E1BFB75@macports.org> <20091010174456.GA25704@bromo.med.uc.edu> <4AD1903F.9000404@macports.org> <20091011172151.GA24093@bromo.med.uc.edu> <4AD21A75.9000109@macports.org> <20091011181050.GA24324@bromo.med.uc.edu> <3745307C-670C-4F9C-B432-F5FDC1FA336A@macports.org> <20091011204446.GA25592@bromo.med.uc.edu> <4AD2535E.5080506@macports.org> <20091012004012.GA26704@bromo.med.uc.edu> Message-ID: <20091012010109.GA26977@bromo.med.uc.edu> On Sun, Oct 11, 2009 at 08:40:12PM -0400, Jack Howarth wrote: > On Sun, Oct 11, 2009 at 11:51:26PM +0200, Rainer M?ller wrote: > > On 2009-10-11 22:44 , Jack Howarth wrote: > > > Am I correct in assuming that it is best practices to > > > construct packaging that builds against python25 or python26 > > > without requiring the associated python to be activated? > > > I believe the current pymol packaging should now build > > > regardless of the activation state of python26 with the above > > > change. > > > > Any file in the prefix comes from an active port. Inactive ports are > > "invisible" and cannot be used from other ports. > > > > See > > > > Rainer > > Rainer, > The current behavior seems really confused. For example, if I have > python25 and python26 installed but only python26 activated, I can > install py25-setuptools with out errors being reported. However, if > I execute... > > sudo port install py25-pmw > > I get an error... > > DEBUG: Found Dependency: receipt exists for python26 > ---> Activating py25-pmw @1.3.2_1 > DEBUG: Image error: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/Pmw/__init__.py is being used by the active py26-pmw port. Please deactivate this port first, or use 'port -f activate py25-pmw' to force the activation. > while executing > "_activate_contents $name $imagefiles $imagedir" > (procedure "portimage::activate" line 56) > invoked from within > "registry_activate $name ${version}_${revision}${portvariants} [array get user_options]" > (procedure "eval_targets" line 21) > invoked from within > "eval_targets activate" > invoked from within > "$workername eval eval_targets $target" > (procedure "mportexec" line 85) > invoked from within > "mportexec $workername $target" > > If I follow the recommendation and execute... > > sudo port -f activate py25-pmw > > I get errors... > > Warning: File /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/Pmw/__init__.py already exists. Moving to: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/Pmw/__init__.py.mp_1255307467. > etc. > > The logic of maintaining multiple pythons seem horribly convoluted and very > fragile (at least if you follow the recommendations in the error messages). > Wouldn't it be better to just have any Portfile that needs access to python25 > or python26, explicitly depend on it and, if not activated, allow port to request > for and implement the activation in real time during the build? > Jack > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev On reflection, it seems to me that port should attempt to make the activate/deactivate behavior mimic how Build-Depends are handled in fink/debian for *-dev packages. For example, if a package needs to be built against python25 in MacPorts and python26 is activated, port should temporarily activate python25 for the duration of the package build and then restore the previous activation state on exiting the installation. As far as I can see, the core files of python25 (for running programs that directly access /opt/local/bin/python2.5) are all present for packages built this way to continue to run despite python25 being deactivated after the build. Jack ps So the activatation state of python25 vs python26 could be considered to analogous to the Conflicts in python25 and python26 fink packages. There is no reason this situation shouldn't be automated in the same fashion so that when a package requires python25 to be activated, it is done automatically during the build but isn't a permanent change. From ryandesign at macports.org Sun Oct 11 18:59:48 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 11 Oct 2009 20:59:48 -0500 Subject: tcl needs --disable-corefoundation In-Reply-To: <20091012004012.GA26704@bromo.med.uc.edu> References: <20091010044205.GA16463@bromo.med.uc.edu> <3BD69205-4F6E-41D4-9685-A9A67E1BFB75@macports.org> <20091010174456.GA25704@bromo.med.uc.edu> <4AD1903F.9000404@macports.org> <20091011172151.GA24093@bromo.med.uc.edu> <4AD21A75.9000109@macports.org> <20091011181050.GA24324@bromo.med.uc.edu> <3745307C-670C-4F9C-B432-F5FDC1FA336A@macports.org> <20091011204446.GA25592@bromo.med.uc.edu> <4AD2535E.5080506@macports.org> <20091012004012.GA26704@bromo.med.uc.edu> Message-ID: <5B82750C-2D0D-4CEC-9DE9-84D55EF5C00C@macports.org> On Oct 11, 2009, at 19:40, Jack Howarth wrote: > The current behavior seems really confused. For example, if I have > python25 and python26 installed but only python26 activated, I can > install py25-setuptools with out errors being reported. I don't know how that would be possible, since py25-setuptools depends on python25, by virtue of using the python25 portgroup. $ port deps py25-setuptools Full Name: py25-setuptools @0.6c9 Library Dependencies: python25 This means if you try to install py25-setuptools, and python25 is not installed, it will be installed first. Or if it is installed but inactive, it will be activated first. It should not be possible for the configure phase of py25-setuptools to begin unless python25 is installed and active. > However, if I execute... > > sudo port install py25-pmw > > I get an error... > > DEBUG: Found Dependency: receipt exists for python26 > ---> Activating py25-pmw @1.3.2_1 > DEBUG: Image error: /opt/local/Library/Frameworks/Python.framework/ > Versions/2.6/lib/python2.6/site-packages/Pmw/__init__.py is being > used by the active py26-pmw port. Please deactivate this port > first, or use 'port -f activate py25-pmw' to force the activation. > while executing > "_activate_contents $name $imagefiles $imagedir" > (procedure "portimage::activate" line 56) > invoked from within > "registry_activate $name ${version}_${revision}${portvariants} > [array get user_options]" > (procedure "eval_targets" line 21) > invoked from within > "eval_targets activate" > invoked from within > "$workername eval eval_targets $target" > (procedure "mportexec" line 85) > invoked from within > "mportexec $workername $target" That sounds pretty bad. It sounds like py25-pmw somehow decided it should use python26, which of course it shouldn't. Do you have python_select installed? If so, which python is selected? This "select" business has always seemed problematic to me, because some ports (perhaps py*-pmw among them) may use "python" instead of using the correct versioned executable like "python26" and it might therefore lead to an error like this if you were installing a python26 module but python25 was "select"ed. > If I follow the recommendation and execute... > > sudo port -f activate py25-pmw It's not a recommendation! The "-f" flag should always only be used if you know what you're doing. Perhaps the message should be revised to read "Please deactivate this port first, or use 'port -f activate py25-pmw' to force the activation if you know what you're doing." The recommendation was to "deactivate this port first" but even that's not applicable here, since clearly a python25 module should not be installing anything into the python26 directories. > I get errors... > > Warning: File /opt/local/Library/Frameworks/Python.framework/ > Versions/2.6/lib/python2.6/site-packages/Pmw/__init__.py already > exists. Moving to: /opt/local/Library/Frameworks/Python.framework/ > Versions/2.6/lib/python2.6/site-packages/Pmw/ > __init__.py.mp_1255307467. > etc. That's a warning, not an error. It is informative to you, letting you know that because you requested the activation to be forced, the conflicting files were moved away. You may delete these moved files if you don't want them. They are now disconnected from any notion of having once belonged to any port, so MacPorts will not be cleaning them up for you. > The logic of maintaining multiple pythons seem horribly convoluted > and very > fragile (at least if you follow the recommendations in the error > messages). Perhaps the error messages need to be revised to clarify what is and what is not a recommendation. > Wouldn't it be better to just have any Portfile that needs access to > python25 > or python26, explicitly depend on it and, if not activated, allow > port to request > for and implement the activation in real time during the build? The current code should already be doing this. I cannot explain why it did not for you. From ryandesign at macports.org Sun Oct 11 19:01:32 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 11 Oct 2009 21:01:32 -0500 Subject: tcl needs --disable-corefoundation In-Reply-To: <20091012010109.GA26977@bromo.med.uc.edu> References: <3BD69205-4F6E-41D4-9685-A9A67E1BFB75@macports.org> <20091010174456.GA25704@bromo.med.uc.edu> <4AD1903F.9000404@macports.org> <20091011172151.GA24093@bromo.med.uc.edu> <4AD21A75.9000109@macports.org> <20091011181050.GA24324@bromo.med.uc.edu> <3745307C-670C-4F9C-B432-F5FDC1FA336A@macports.org> <20091011204446.GA25592@bromo.med.uc.edu> <4AD2535E.5080506@macports.org> <20091012004012.GA26704@bromo.med.uc.edu> <20091012010109.GA26977@bromo.med.uc.edu> Message-ID: On Oct 11, 2009, at 20:01, Jack Howarth wrote: > ps So the activatation state of python25 vs python26 could be > considered to analogous to the Conflicts in python25 and > python26 fink packages. There is no reason this situation > shouldn't be automated in the same fashion so that when > a package requires python25 to be activated, it is done > automatically during the build but isn't a permanent change. MacPorts doesn't currently have a notion of activating or installing something temporarily, then deactivating or uninstalling it automatically later. I don't see what that would get us either. MacPorts can just activate or install it if you need it, and leave it. That's what the dependency engine currently does. From raimue at macports.org Mon Oct 12 01:36:25 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 12 Oct 2009 10:36:25 +0200 Subject: tcl needs --disable-corefoundation In-Reply-To: <20091012004012.GA26704@bromo.med.uc.edu> References: <20091010044205.GA16463@bromo.med.uc.edu> <3BD69205-4F6E-41D4-9685-A9A67E1BFB75@macports.org> <20091010174456.GA25704@bromo.med.uc.edu> <4AD1903F.9000404@macports.org> <20091011172151.GA24093@bromo.med.uc.edu> <4AD21A75.9000109@macports.org> <20091011181050.GA24324@bromo.med.uc.edu> <3745307C-670C-4F9C-B432-F5FDC1FA336A@macports.org> <20091011204446.GA25592@bromo.med.uc.edu> <4AD2535E.5080506@macports.org> <20091012004012.GA26704@bromo.med.uc.edu> Message-ID: <4AD2EA89.1090408@macports.org> On 2009-10-12 02:40 , Jack Howarth wrote: > DEBUG: Found Dependency: receipt exists for python26 > ---> Activating py25-pmw @1.3.2_1 > DEBUG: Image error: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/Pmw/__init__.py is being used by the active py26-pmw port. Please deactivate this port first, or use 'port -f activate py25-pmw' to force the activation. That looks broken and I don't know how you manged to get to this point. Usually the port group takes care where to install the python module files. For you it is using python26 directories although the port is using the python25 group. It works correctly for me and I was unable to reproduce the problem. Do you have any local modifications on py25-pmw or the port group? Rainer From lyle at lylejohnson.name Mon Oct 12 09:02:24 2009 From: lyle at lylejohnson.name (Lyle Johnson) Date: Mon, 12 Oct 2009 11:02:24 -0500 Subject: Requesting commit of rb-fxruby port update Message-ID: <57cf8f720910120902y5b5a391av9698dbab105994ee@mail.gmail.com> Could someone with commit privileges please review and commit the port update for rb-fxruby 1.6.19? http://trac.macports.org/ticket/21986 Thanks in advance, Lyle From jeremyhu at macports.org Mon Oct 12 17:04:02 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Mon, 12 Oct 2009 17:04:02 -0700 Subject: [Xquartz-dev] 2.4.1_alpha2 In-Reply-To: <20091012234156.GA10375@bromo.med.uc.edu> References: <134BDEC9-356F-4F0B-BD17-FD356DC66D6F@apple.com> <20091012234156.GA10375@bromo.med.uc.edu> Message-ID: On Oct 12, 2009, at 16:41, Jack Howarth wrote: > Jeremy, > I haven't tested the 2.4.1 rc's yet, but on MacPorts 1.8.1, > while attempting to debug the widget problems in my proposed > molmol package, I just noticed that the xcalc program in MacPorts > is broken as well. The xcalc program in MacPorts opens up a reduced > window with the misdrawn buttons and fields. Perhaps this is related > to the problems that I am seeing with molmol not rendering its UI > widgets. > Jack Interesting... I don't see this issue with /usr/X11/bin/xcalc (SnowLeoaprd shipped) or /opt/X11/bin/xcalc (MacOSForge.org shipped), but I do see it with / opt/local/bin/xcalc (MacPorts shipped) ... I'm befuddled but will look into it... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3333 bytes Desc: not available URL: From jeremyhu at macports.org Mon Oct 12 17:58:37 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Mon, 12 Oct 2009 17:58:37 -0700 Subject: [Xquartz-dev] 2.4.1_alpha2 In-Reply-To: References: <134BDEC9-356F-4F0B-BD17-FD356DC66D6F@apple.com> <20091012234156.GA10375@bromo.med.uc.edu> Message-ID: On Oct 12, 2009, at 17:04, Jeremy Huddleston wrote: > On Oct 12, 2009, at 16:41, Jack Howarth wrote: >> Jeremy, >> I haven't tested the 2.4.1 rc's yet, but on MacPorts 1.8.1, >> while attempting to debug the widget problems in my proposed >> molmol package, I just noticed that the xcalc program in MacPorts >> is broken as well. The xcalc program in MacPorts opens up a reduced >> window with the misdrawn buttons and fields. Perhaps this is related >> to the problems that I am seeing with molmol not rendering its UI >> widgets. >> Jack > > Interesting... > > I don't see this issue with /usr/X11/bin/xcalc (SnowLeoaprd shipped) > or /opt/X11/bin/xcalc (MacOSForge.org shipped), but I do see it > with /opt/local/bin/xcalc (MacPorts shipped) ... I'm befuddled but > will look into it... Ahh... I see the problem. xcalc isn't finding its resource file. This issue was fixed a while back in our releases but it didn't make it into MacPorts. These apps will be getting upstream bumps in the next week or so, and we'll pull in the fixes at that time. This issue should have nothing to do with what you're seeing in molmol. --Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3333 bytes Desc: not available URL: From ryandesign at macports.org Tue Oct 13 04:03:16 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 13 Oct 2009 06:03:16 -0500 Subject: [59293] trunk/dports/lang/ccl/Portfile In-Reply-To: <20091013065928.9364829D9B0B@beta.macosforge.org> References: <20091013065928.9364829D9B0B@beta.macosforge.org> Message-ID: On Oct 13, 2009, at 01:59, gwright at macports.org wrote: > Revision: 59293 > http://trac.macports.org/changeset/59293 > Author: gwright at macports.org > Date: 2009-10-12 23:59:27 -0700 (Mon, 12 Oct 2009) > Log Message: > ----------- > Clean port lint warning; reenable 64 bit variants. > > Modified Paths: > -------------- > trunk/dports/lang/ccl/Portfile > +platform darwin x86_64 { > + svn.url http://svn.clozure.com/publicsvn/openmcl/release/${shortversion}/darwinx86/ccl > + global bootimg > + set bootimg dx86cl64 > > + global ccl_script > + set ccl_script ccl64 > +} > +platform darwin ppc64 { > + svn.url http://svn.clozure.com/publicsvn/openmcl/release/${shortversion}/darwinppc/ccl > + global bootimg > + set bootimg dppccl64 > > + global ccl_script > + set ccl_script ccl64 > +} Remember that there is no such thing as "platform x86_64" or "platform ppc64" and MacPorts will never select these variants for you. The only Mac platforms MacPorts recognizes are "powerpc" (any PowerPC processor, 32-bit or 64-bit) and "i386" (any Intel processor, 32-bit or 64-bit). If you want to differentiate between 32-bit and 64-bit architectures, examine the ${configure.build_arch} variable (if not building universal) or ${configure.universal_archs} (if building universal). From ryandesign at macports.org Tue Oct 13 06:52:46 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 13 Oct 2009 08:52:46 -0500 Subject: [59308] trunk/dports/devel In-Reply-To: <20091013131622.2091729E4F97@beta.macosforge.org> References: <20091013131622.2091729E4F97@beta.macosforge.org> Message-ID: On Oct 13, 2009, at 08:16, avsm at macports.org wrote: > Revision: 59308 > http://trac.macports.org/changeset/59308 > Author: avsm at macports.org > Date: 2009-10-13 06:16:15 -0700 (Tue, 13 Oct 2009) > Log Message: > ----------- > initial import of caml-react-0.9.0 > Added: trunk/dports/devel/caml-react/Portfile > +build.cmd "./build" > +build.target "" > + > +destroot.cmd "./build" > +destroot.target "install" > +destroot.env INSTALLDIR=${destroot}${prefix}/lib/ocaml/site- > lib/react > +destroot.destdir "" Note that you don't need quotes around these (though they're not doing any harm). Also, destroot.cmd defaults to the value of build.cmd, and destroot.target defaults to "install". So you can simplify this to: build.cmd ./build build.target destroot.env INSTALLDIR=${destroot}${prefix}/lib/ocaml/site-lib/ react destroot.destdir > +livecheck.regex \>react-(.*)\.tbz ">" is not a special character in regex or tcl syntax so you don't need to escape it. "." is a special character in regex syntax so you do need to escape it with a backslash. But "\" is a special character in tcl syntax. So you either need to escape it twice, or enclose the whole thing in curly braces so tcl special characters are ignored. So use either livecheck.regex >react-(.*)\\.tbz or livecheck.regex {>react-(.*)\.tbz} This comment applies to many of the commits you just made so you should make this correction in all those ports. From vince at macports.org Tue Oct 13 12:08:23 2009 From: vince at macports.org (vincent habchi) Date: Tue, 13 Oct 2009 21:08:23 +0200 Subject: Atlas universal Message-ID: <006C58CA-4C0C-4FD9-8E6A-A8ED9644826A@macports.org> The Atlas port is not universal. I would like to tweak that, but in order to do this, I need to know before if gfortran 4.3 can generated 32 or 64-bit binaries, in other words if it accepts -m32 or -m64 flags. Thanks Vincent From blb at macports.org Tue Oct 13 14:39:42 2009 From: blb at macports.org (Bryan Blackburn) Date: Tue, 13 Oct 2009 15:39:42 -0600 Subject: [59351] trunk/dports/python/py-omniORBpy/Portfile In-Reply-To: <20091013205056.2015329F0A30@beta.macosforge.org> References: <20091013205056.2015329F0A30@beta.macosforge.org> Message-ID: <20091013213942.GE567@ninagal.withay.com> On Tue, Oct 13, 2009 at 01:50:55PM -0700, stromnov at macports.org said: > Revision: 59351 > http://trac.macports.org/changeset/59351 > Author: stromnov at macports.org > Date: 2009-10-13 13:50:51 -0700 (Tue, 13 Oct 2009) > Log Message: > ----------- > update to version 3.4 (also closes #16763), take maintainership openmaintainer, ensure installation in python framework, add python25 and python26 variants > > Modified Paths: > -------------- > trunk/dports/python/py-omniORBpy/Portfile [...] > +if {![variant_isset python25] && ![variant_isset python26]} { > + default_variants +python25 > +} > + > +variant python25 description {Enable python support with python 2.5} { > + depends_lib-append port:python25 > + configure.python ${prefix}/bin/python2.5 > +} > + > +variant python26 description {Enable python support with python 2.6} { > + depends_lib-append port:python26 > + configure.python ${prefix}/bin/python2.6 > +} This isn't how the python module ports work currently, you'll need to use py25- and py26- for the 2.5 and 2.6 versions of python. Bryan From ryandesign at macports.org Wed Oct 14 02:46:54 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 14 Oct 2009 04:46:54 -0500 Subject: Atlas universal In-Reply-To: <006C58CA-4C0C-4FD9-8E6A-A8ED9644826A@macports.org> References: <006C58CA-4C0C-4FD9-8E6A-A8ED9644826A@macports.org> Message-ID: <2CAF7B2C-8F53-411B-8BB0-0108E54D2FB0@macports.org> On Oct 13, 2009, at 14:08, vincent habchi wrote: > The Atlas port is not universal. I would like to tweak that, but in > order to do this, I need to know before if gfortran 4.3 can > generated 32 or 64-bit binaries, in other words if it accepts -m32 > or -m64 flags. I'm not sure. Have you tried it, or asked the developers of gfortran? From ryandesign at macports.org Wed Oct 14 02:50:11 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 14 Oct 2009 04:50:11 -0500 Subject: [59364] trunk/dports/python In-Reply-To: <20091014004648.40C5029F97FA@beta.macosforge.org> References: <20091014004648.40C5029F97FA@beta.macosforge.org> Message-ID: <61814EA0-2723-474D-813C-8206B076EE9A@macports.org> On Oct 13, 2009, at 19:46, blair at macports.org wrote: > +livecheck.regex CouchDB (0\.\[0-9\]+(\.\[0-9\]+)?) Note that for proper escaping, you either need double backslashes in front of the periods... livecheck.regex CouchDB (0\\.\[0-9\]+(\\.\[0-9\]+)?) ...or you need to enclose the entire regex in curly quotes to disable tcl special characters... livecheck.regex {CouchDB (0\.[0-9]+(\.[0-9]+)?)} From ryandesign at macports.org Wed Oct 14 02:51:34 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 14 Oct 2009 04:51:34 -0500 Subject: [59380] trunk/dports/kde/kdelibs4 In-Reply-To: <20091014091804.A25392A0BB2D@beta.macosforge.org> References: <20091014091804.A25392A0BB2D@beta.macosforge.org> Message-ID: On Oct 14, 2009, at 04:18, sharky at macports.org wrote: > Revision: 59380 > http://trac.macports.org/changeset/59380 > Author: sharky at macports.org > Date: 2009-10-14 02:18:03 -0700 (Wed, 14 Oct 2009) > Log Message: > ----------- > kdelibs4: fix installation of bundle icons How was it broken before -- would the port installation fail with an error message, or would it succeed but not install some files correctly? From sharky at macports.org Wed Oct 14 02:55:54 2009 From: sharky at macports.org (=?iso-8859-1?Q?Jeremy_Lain=E9?=) Date: Wed, 14 Oct 2009 11:55:54 +0200 Subject: [59380] trunk/dports/kde/kdelibs4 In-Reply-To: References: <20091014091804.A25392A0BB2D@beta.macosforge.org> Message-ID: <7DA949BC-2491-4E13-BE7F-A912907C716E@macports.org> >> kdelibs4: fix installation of bundle icons > > How was it broken before -- would the port installation fail with an > error message, or would it succeed but not install some files > correctly? The files got installed to /opt/local/bin/FOO.app instead of / Applications/MacPorts/KDE4/FOO.app. I have reported the issue upstream: https://bugs.kde.org/show_bug.cgi?id=210521 I haven't bumped the Port version yet as it's a pretty heavy rebuild, and for the fix to actually take effect, you need to rebuild every single KDE4 port. Jeremy From ryandesign at macports.org Wed Oct 14 02:58:49 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 14 Oct 2009 04:58:49 -0500 Subject: [59380] trunk/dports/kde/kdelibs4 In-Reply-To: <7DA949BC-2491-4E13-BE7F-A912907C716E@macports.org> References: <20091014091804.A25392A0BB2D@beta.macosforge.org> <7DA949BC-2491-4E13-BE7F-A912907C716E@macports.org> Message-ID: <847FF9ED-110A-4CC3-B1A5-0819DC3B0C79@macports.org> On Oct 14, 2009, at 04:55, Jeremy Lain? wrote: >>> kdelibs4: fix installation of bundle icons >> >> How was it broken before -- would the port installation fail with >> an error message, or would it succeed but not install some files >> correctly? > > The files got installed to /opt/local/bin/FOO.app instead of / > Applications/MacPorts/KDE4/FOO.app. I have reported the issue > upstream: > > https://bugs.kde.org/show_bug.cgi?id=210521 Ok. > I haven't bumped the Port version yet as it's a pretty heavy > rebuild, and for the fix to actually take effect, you need to > rebuild every single KDE4 port. It does sound like the revision of kdelibs4, and perhaps every other kde4 port, should be bumped. Otherwise people who already had the port installed won't get your fix. Though if you have other planned changes to those ports that will also necessitate version or revision bumps, you could wait. From sharky at macports.org Wed Oct 14 03:02:56 2009 From: sharky at macports.org (=?iso-8859-1?Q?Jeremy_Lain=E9?=) Date: Wed, 14 Oct 2009 12:02:56 +0200 Subject: [59380] trunk/dports/kde/kdelibs4 In-Reply-To: <847FF9ED-110A-4CC3-B1A5-0819DC3B0C79@macports.org> References: <20091014091804.A25392A0BB2D@beta.macosforge.org> <7DA949BC-2491-4E13-BE7F-A912907C716E@macports.org> <847FF9ED-110A-4CC3-B1A5-0819DC3B0C79@macports.org> Message-ID: >> I haven't bumped the Port version yet as it's a pretty heavy >> rebuild, and for the fix to actually take effect, you need to >> rebuild every single KDE4 port. > > It does sound like the revision of kdelibs4, and perhaps every other > kde4 port, should be bumped. Otherwise people who already had the > port installed won't get your fix. Though if you have other planned > changes to those ports that will also necessitate version or > revision bumps, you could wait. You're absolutely right, there is another issue I'd like to fix before bumping all the versions, namely: http://trac.macports.org/ticket/21973 This bug is a nasty one and it's preventing most KDE apps from actually working on Snow Leopard. On a side note, I haven't forgotten about your request to clean up the kde4 portgroup, I just haven't got round to it. Cheers, Jeremy From ryandesign at macports.org Wed Oct 14 03:04:18 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 14 Oct 2009 05:04:18 -0500 Subject: [59380] trunk/dports/kde/kdelibs4 In-Reply-To: References: <20091014091804.A25392A0BB2D@beta.macosforge.org> <7DA949BC-2491-4E13-BE7F-A912907C716E@macports.org> <847FF9ED-110A-4CC3-B1A5-0819DC3B0C79@macports.org> Message-ID: On Oct 14, 2009, at 05:02, Jeremy Lain? wrote: >>> I haven't bumped the Port version yet as it's a pretty heavy >>> rebuild, and for the fix to actually take effect, you need to >>> rebuild every single KDE4 port. >> >> It does sound like the revision of kdelibs4, and perhaps every >> other kde4 port, should be bumped. Otherwise people who already had >> the port installed won't get your fix. Though if you have other >> planned changes to those ports that will also necessitate version >> or revision bumps, you could wait. > > You're absolutely right, there is another issue I'd like to fix > before bumping all the versions, namely: > > http://trac.macports.org/ticket/21973 > > This bug is a nasty one and it's preventing most KDE apps from > actually working on Snow Leopard. > > On a side note, I haven't forgotten about your request to clean up > the kde4 portgroup, I just haven't got round to it. No problem, there's a ton of stuff I haven't gotten around to yet either. :) From howarth at bromo.med.uc.edu Wed Oct 14 05:57:40 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Wed, 14 Oct 2009 08:57:40 -0400 Subject: [21376] pymol 1.2r2 packaging Message-ID: <20091014125740.GA3633@bromo.med.uc.edu> I believe that the pymol 1.2r2 packaging on... https://trac.macports.org/ticket/21376 has been fully reviewed now. Can we please get this into the dports for 1.8.1? Of course tcl will need to be fixed to build with --disable-core-foundation but adding pymol may nudge that process along. Thanks in advance. Jack From vince at macports.org Wed Oct 14 06:46:37 2009 From: vince at macports.org (vincent habchi) Date: Wed, 14 Oct 2009 15:46:37 +0200 Subject: Atlas universal In-Reply-To: <2CAF7B2C-8F53-411B-8BB0-0108E54D2FB0@macports.org> References: <006C58CA-4C0C-4FD9-8E6A-A8ED9644826A@macports.org> <2CAF7B2C-8F53-411B-8BB0-0108E54D2FB0@macports.org> Message-ID: <1351D164-BC8D-4626-8B49-4FEDC95909A3@macports.org> Le 14 oct. 2009 ? 11:46, Ryan Schmidt a ?crit : >> The Atlas port is not universal. I would like to tweak that, but in >> order to do this, I need to know before if gfortran 4.3 can >> generated 32 or 64-bit binaries, in other words if it accepts -m32 >> or -m64 flags. > > I'm not sure. Have you tried it, or asked the developers of gfortran? It does not. Well, it does, but since the various libs are compiled for the native architecture only, it does not work. But maybe there is a way for the libs to be compiled 32/64 ? Vincent From blair at orcaware.com Wed Oct 14 11:06:18 2009 From: blair at orcaware.com (Blair Zajac) Date: Wed, 14 Oct 2009 11:06:18 -0700 Subject: [59364] trunk/dports/python In-Reply-To: <61814EA0-2723-474D-813C-8206B076EE9A@macports.org> References: <20091014004648.40C5029F97FA@beta.macosforge.org> <61814EA0-2723-474D-813C-8206B076EE9A@macports.org> Message-ID: <4AD6131A.1050701@orcaware.com> Ryan Schmidt wrote: > > On Oct 13, 2009, at 19:46, blair at macports.org wrote: > >> +livecheck.regex CouchDB (0\.\[0-9\]+(\.\[0-9\]+)?) > > > Note that for proper escaping, you either need double backslashes in > front of the periods... > > livecheck.regex CouchDB (0\\.\[0-9\]+(\\.\[0-9\]+)?) > > ...or you need to enclose the entire regex in curly quotes to disable > tcl special characters... > > livecheck.regex {CouchDB (0\.[0-9]+(\.[0-9]+)?)} Thanks, I'll fix that. I just copied these from the py26-pyflakes port, so we should fix those also. This would be a good thing for port lint, as it's not obvious. Blair From talklists at newgeo.com Wed Oct 14 12:57:30 2009 From: talklists at newgeo.com (Scott Haneda) Date: Wed, 14 Oct 2009 12:57:30 -0700 Subject: The opendarwin .com debacle Message-ID: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> I've grown to truly appreciate the MacPorts project. I'm not as involved as I'd like to be, but my list of submitted ports is growing. I honestly have no idea how a few of you put so much dedicated time into this project. Thanks is not ever going to be enough. Two times now I've had someone tell me Fink was a better experience than Mac Ports to learn they had been to the .com site. Whether Fink is good or not is not the point I really care about, both Fink and MacPorts are viable projects. If two users were misinformed by the .com site, how many more are, have been, or will be? It appears the owner has turned to the dark side. Without getting into too much of a cat and mouse game, what about some very basic counter measures? He must be syncing the port tree from some machine on a schedule, why not block that machine? There are plenty of links on the .com that point to official MacPorts pages. Can we do a basic referrer check for those requests, and send them to a page that shorty explains the situation, quickly gives them links to get to official, and provides a detail link to the more verbose explanation? Isn't the site is violation of some aspect of some license of some form? If that is the case, make him release his source, or stop, or whatever we can find to make this go away. Not that a lot of people use my DNS, but I'm tempted to add a zone for his .com to point to nowhere. It's technicaly a phishing or malware site, perhaps a mass effort to report the domain to the in built browser phishing and malware lists is in order? Has anyone gone to the upstream ISP and explained this case? How many donations has he pilfered away from the team? Maybe this is really low on the problem scale these days, if so, ignore it I guess, but if I've personally hit two people who were confused, this must be more widespread. Anything I can do to help; I may not be able to patch as many ports as the next guy, but I can do gruntwork like this :) -- Scott Iphone says hello. From jeremy at lavergne.gotdns.org Wed Oct 14 13:16:06 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 14 Oct 2009 16:16:06 -0400 Subject: The opendarwin .com debacle In-Reply-To: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> Message-ID: <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> > Two times now I've had someone tell me Fink was a better experience > than Mac Ports to learn they had been to the .com site. > > If two users were misinformed by the .com site, how many more are, > have been, or will be? I've come across some users in IRC that were equally confused. He needs to know he is not helping. I recall in the past when reading his emails with the portmgrs that he thought it was helpful to visitors. We need to document that it's clearly not and inform him as such. Legal action can already be taken since macports.org is copywriter with all rights reserved. He is likely stealing content from us. > It appears the owner has turned to the dark side. Without getting > into too much of a cat and mouse game, what about some very basic > counter measures? Indeed, there is another domain suffix "protected" so you cannot tell who registered it. At least I didn't know about this additional one until today. > He must be syncing the port tree from some machine on a schedule, > why not block that machine? We can likely match the IP address up with the one that site is on. I can't imagine that he uses more than one machine to do this. > Isn't the site is violation of some aspect of some license of some > form? If that is the case, make him release his source, or stop, or > whatever we can find to make this go away. It is a violation: all rights for access to content on macports.org are RESERVED. We can technically already slap him with a takedown notice. > Not that a lot of people use my DNS, but I'm tempted to add a zone > for his .com to point to nowhere. It's technicaly a phishing or > malware site, perhaps a mass effort to report the domain to the in > built browser phishing and malware lists is in order? Eh ... get opendns to block him. That'd be a more noticeable step forward, then work with ISPs to block him. I'd like to front some money to portmgr (or backorder them myself) to prevent this guy from containing to masquerade. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4024 bytes Desc: not available URL: From jeremyhu at macports.org Wed Oct 14 13:17:51 2009 From: jeremyhu at macports.org (Jeremy Huddleston) Date: Wed, 14 Oct 2009 13:17:51 -0700 Subject: The opendarwin .com debacle In-Reply-To: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> Message-ID: For clarification, I believe you're talking about http://www.darwinports.com , not opendarwin.com ... On Oct 14, 2009, at 12:57, Scott Haneda wrote: > I've grown to truly appreciate the MacPorts project. I'm not as > involved as I'd like to be, but my list of submitted ports is growing. > > I honestly have no idea how a few of you put so much dedicated time > into this project. Thanks is not ever going to be enough. > > Two times now I've had someone tell me Fink was a better experience > than Mac Ports to learn they had been to the .com site. > > Whether Fink is good or not is not the point I really care about, > both Fink and MacPorts are viable projects. > > If two users were misinformed by the .com site, how many more are, > have been, or will be? > > It appears the owner has turned to the dark side. Without getting > into too much of a cat and mouse game, what about some very basic > counter measures? > > He must be syncing the port tree from some machine on a schedule, > why not block that machine? > > There are plenty of links on the .com that point to official > MacPorts pages. Can we do a basic referrer check for those requests, > and send them to a page that shorty explains the situation, quickly > gives them links to get to official, and provides a detail link to > the more verbose explanation? > > Isn't the site is violation of some aspect of some license of some > form? If that is the case, make him release his source, or stop, or > whatever we can find to make this go away. > > Not that a lot of people use my DNS, but I'm tempted to add a zone > for his .com to point to nowhere. It's technicaly a phishing or > malware site, perhaps a mass effort to report the domain to the in > built browser phishing and malware lists is in order? > > Has anyone gone to the upstream ISP and explained this case? How > many donations has he pilfered away from the team? > > Maybe this is really low on the problem scale these days, if so, > ignore it I guess, but if I've personally hit two people who were > confused, this must be more widespread. > > Anything I can do to help; I may not be able to patch as many ports > as the next guy, but I can do gruntwork like this :) > -- > Scott > Iphone says hello. > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5820 bytes Desc: not available URL: From talklists at newgeo.com Wed Oct 14 13:25:08 2009 From: talklists at newgeo.com (Scott Haneda) Date: Wed, 14 Oct 2009 13:25:08 -0700 Subject: The opendarwin .com debacle In-Reply-To: References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> Message-ID: <8351072B-6728-483F-BC4F-2D36D160AC29@newgeo.com> See, even I'm confused :) Sorry, when mobile I go on memory and slipped that one up bad. You are correct in that this is about / darwinports/.com -- Scott Iphone says hello. On Oct 14, 2009, at 1:17 PM, Jeremy Huddleston wrote: > For clarification, I believe you're talking about http://www.darwinports.com > , not opendarwin.com ... > > On Oct 14, 2009, at 12:57, Scott Haneda wrote: > >> I've grown to truly appreciate the MacPorts project. I'm not as >> involved as I'd like to be, but my list of submitted ports is >> growing. >> >> I honestly have no idea how a few of you put so much dedicated time >> into this project. Thanks is not ever going to be enough. >> >> Two times now I've had someone tell me Fink was a better experience >> than Mac Ports to learn they had been to the .com site. >> >> Whether Fink is good or not is not the point I really care about, >> both Fink and MacPorts are viable projects. >> >> If two users were misinformed by the .com site, how many more are, >> have been, or will be? >> >> It appears the owner has turned to the dark side. Without getting >> into too much of a cat and mouse game, what about some very basic >> counter measures? >> >> He must be syncing the port tree from some machine on a schedule, >> why not block that machine? >> >> There are plenty of links on the .com that point to official >> MacPorts pages. Can we do a basic referrer check for those >> requests, and send them to a page that shorty explains the >> situation, quickly gives them links to get to official, and >> provides a detail link to the more verbose explanation? >> >> Isn't the site is violation of some aspect of some license of some >> form? If that is the case, make him release his source, or stop, or >> whatever we can find to make this go away. >> >> Not that a lot of people use my DNS, but I'm tempted to add a zone >> for his .com to point to nowhere. It's technicaly a phishing or >> malware site, perhaps a mass effort to report the domain to the in >> built browser phishing and malware lists is in order? >> >> Has anyone gone to the upstream ISP and explained this case? How >> many donations has he pilfered away from the team? >> >> Maybe this is really low on the problem scale these days, if so, >> ignore it I guess, but if I've personally hit two people who were >> confused, this must be more widespread. >> >> Anything I can do to help; I may not be able to patch as many ports >> as the next guy, but I can do gruntwork like this :) >> -- >> Scott >> Iphone says hello. >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > From talklists at newgeo.com Wed Oct 14 15:55:14 2009 From: talklists at newgeo.com (Scott Haneda) Date: Wed, 14 Oct 2009 15:55:14 -0700 Subject: The opendarwin .com debacle In-Reply-To: <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> Message-ID: On Oct 14, 2009, at 1:16 PM, Jeremy Lavergne wrote: >> Two times now I've had someone tell me Fink was a better experience >> than Mac Ports to learn they had been to the .com site. >> >> If two users were misinformed by the .com site, how many more are, >> have been, or will be? > > I've come across some users in IRC that were equally confused. He > needs to know he is not helping. > > I recall in the past when reading his emails with the portmgrs that > he thought it was helpful to visitors. We need to document that > it's clearly not and inform him as such. Legal action can already > be taken since macports.org is copywriter with all rights reserved. > He is likely stealing content from us. What is the last communication that was had with Matt, and what is his position? Is there any point in opening dialogue with him again? >> It appears the owner has turned to the dark side. Without getting >> into too much of a cat and mouse game, what about some very basic >> counter measures? > > Indeed, there is another domain suffix "protected" so you cannot > tell who registered it. At least I didn't know about this > additional one until today. What is it, it is not .net as far as I can tell, which seems to be available. I would like to purchase this domain now, and donate it to macports, I can do the redirection or they can have the entire domain. How do I proceed? This is a concern, that site is beating the official source in ranking http://www.google.com/search?hl=en&source=hp&q=darwinports&aq=f&oq=&aqi=g10 >> He must be syncing the port tree from some machine on a schedule, >> why not block that machine? > > We can likely match the IP address up with the one that site is on. > I can't imagine that he uses more than one machine to do this. Is there any interest from the MP team to add a referrer check in Apache to display a page that explains some of this? I would be happy to create the page in the wiki. I know there is a page now, but it is too verbose, it needs to be a simple sentence or two that explains this situation and gets them to the correct site. >> Isn't the site is violation of some aspect of some license of some >> form? If that is the case, make him release his source, or stop, or >> whatever we can find to make this go away. > > It is a violation: all rights for access to content on macports.org > are RESERVED. We can technically already slap him with a takedown > notice. Can you find the ISP? I do not think there would be a lot of luck hitting up register.com, as domain take downs are a nasty road to go down. > I'd like to front some money to portmgr (or backorder them myself) > to prevent this guy from containing to masquerade. I am happy to do the same with the .net today, and can accept the transfer to whatever registrar they are using. Unless someone tells me it is a bad idea, I would like to send Matt a friendly email, telling him he is doing more harm than good, and ask him to shut the site down, or redirect it to an appropriate spot. Ideally he would give up the domain name. -- Scott * If you contact me off list replace talklists@ with scott@ * From jeremy at lavergne.gotdns.org Wed Oct 14 16:12:16 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Wed, 14 Oct 2009 19:12:16 -0400 Subject: The opendarwin .com debacle In-Reply-To: References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> Message-ID: >>> It appears the owner has turned to the dark side. Without getting >>> into too much of a cat and mouse game, what about some very basic >>> counter measures? >> >> Indeed, there is another domain suffix "protected" so you cannot >> tell who registered it. At least I didn't know about this >> additional one until today. > > What is it, it is not .net as far as I can tell, which seems to be > available. .info (72.52.206.10) >>> Isn't the site is violation of some aspect of some license of some >>> form? If that is the case, make him release his source, or stop, >>> or whatever we can find to make this go away. >> >> It is a violation: all rights for access to content on >> macports.org are RESERVED. We can technically already slap him >> with a takedown notice. > > Can you find the ISP? I do not think there would be a lot of luck > hitting up register.com, as domain take downs are a nasty road to go > down. 208.185.168.32.zipmath.com (208.185.168.32) Additionally, the .info trace ends here: vz223.liquidweb.com (72.52.206.76) > Unless someone tells me it is a bad idea, I would like to send Matt > a friendly email, telling him he is doing more harm than good, and > ask him to shut the site down, or redirect it to an appropriate > spot. Ideally he would give up the domain name. I'd suggest reviewing the pervious correspondence first. Does anyone have a link to the email archives? From opendarwin.org at darkart.com Wed Oct 14 16:23:39 2009 From: opendarwin.org at darkart.com (Eric Hall) Date: Wed, 14 Oct 2009 23:23:39 +0000 Subject: The opendarwin .com debacle In-Reply-To: References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> Message-ID: <20091014232339.GB62534@darkart.com> On Wed, Oct 14, 2009 at 03:55:14PM -0700, Scott Haneda wrote: [snip] > > Can you find the ISP? I do not think there would be a lot of luck > hitting up register.com, as domain take downs are a nasty road to go > down. DNS says the IP is '208.185.168.32', which is in space allocated to above.net. Reverse lookup of the IP returns: 208.185.168.32.zipmath.com and that appears to be hosted inside of Above.Net's SJC2 facility. zipmath.com appears to belong to someone who is in Cupertino, CA (see lookups for beffa.com). -eric From raimue at macports.org Wed Oct 14 18:23:36 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Thu, 15 Oct 2009 03:23:36 +0200 Subject: [59364] trunk/dports/python In-Reply-To: <4AD6131A.1050701@orcaware.com> References: <20091014004648.40C5029F97FA@beta.macosforge.org> <61814EA0-2723-474D-813C-8206B076EE9A@macports.org> <4AD6131A.1050701@orcaware.com> Message-ID: <4AD67998.7090406@macports.org> On 2009-10-14 20:06 , Blair Zajac wrote: > Ryan Schmidt wrote: >> Note that for proper escaping, you either need double backslashes in >> front of the periods... >> >> livecheck.regex CouchDB (0\\.\[0-9\]+(\\.\[0-9\]+)?) >> >> ...or you need to enclose the entire regex in curly quotes to disable >> tcl special characters... >> >> livecheck.regex {CouchDB (0\.[0-9]+(\.[0-9]+)?)} > > Thanks, I'll fix that. I just copied these from the py26-pyflakes port, so we > should fix those also. > > This would be a good thing for port lint, as it's not obvious. It's hard to detect if an backslash escape is meant for Tcl or the regex. Remember that you cannot use variables inside curly braces and therefore sometimes you want to have additional backslashes. What would be the rule to warn on port lint? Rainer From blb at macports.org Wed Oct 14 19:14:54 2009 From: blb at macports.org (Bryan Blackburn) Date: Wed, 14 Oct 2009 20:14:54 -0600 Subject: The opendarwin .com debacle In-Reply-To: References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> Message-ID: <20091015021454.GV567@ninagal.withay.com> On Wed, Oct 14, 2009 at 03:55:14PM -0700, Scott Haneda said: > On Oct 14, 2009, at 1:16 PM, Jeremy Lavergne wrote: [...] > >I recall in the past when reading his emails with the portmgrs that > >he thought it was helpful to visitors. We need to document that > >it's clearly not and inform him as such. Legal action can already > >be taken since macports.org is copywriter with all rights reserved. > >He is likely stealing content from us. > > What is the last communication that was had with Matt, and what is > his position? Is there any point in opening dialogue with him again? The last public communication, that I know of, is linked on our DarwinPorts page: [...] > What is it, it is not .net as far as I can tell, which seems to be > available. I would like to purchase this domain now, and donate it > to macports, I can do the redirection or they can have the entire > domain. How do I proceed? I used to own darwinports dot net and just had it forward to the right place; I didn't renew it a couple years ago because of the move to MacPorts in all things. At this point, it's been MacPorts for over three years now, so the real message these days is really, DarwinPorts is long dead. > > This is a concern, that site is beating the official source in ranking > http://www.google.com/search?hl=en&source=hp&q=darwinports&aq=f&oq=&aqi=g10 Yeah, I think that's mostly because of .domain being used. [...] > >It is a violation: all rights for access to content on > >macports.org are RESERVED. We can technically already slap him > >with a takedown notice. > > Can you find the ISP? I do not think there would be a lot of luck > hitting up register.com, as domain take downs are a nasty road to go > down. Note that there really isn't any kind of actionable violation, as MacPorts uses the BSD license, and the web page there looks to be his own creation... Bryan [...] From blair at orcaware.com Wed Oct 14 20:16:52 2009 From: blair at orcaware.com (Blair Zajac) Date: Wed, 14 Oct 2009 20:16:52 -0700 Subject: [59364] trunk/dports/python In-Reply-To: <4AD67998.7090406@macports.org> References: <20091014004648.40C5029F97FA@beta.macosforge.org> <61814EA0-2723-474D-813C-8206B076EE9A@macports.org> <4AD6131A.1050701@orcaware.com> <4AD67998.7090406@macports.org> Message-ID: <854A8CAB-0B3B-4F06-AF0D-EB3040ECD8BC@orcaware.com> On Oct 14, 2009, at 6:23 PM, Rainer M?ller wrote: > On 2009-10-14 20:06 , Blair Zajac wrote: >> Ryan Schmidt wrote: >>> Note that for proper escaping, you either need double backslashes in >>> front of the periods... >>> >>> livecheck.regex CouchDB (0\\.\[0-9\]+(\\.\[0-9\]+)?) >>> >>> ...or you need to enclose the entire regex in curly quotes to >>> disable >>> tcl special characters... >>> >>> livecheck.regex {CouchDB (0\.[0-9]+(\.[0-9]+)?)} >> >> Thanks, I'll fix that. I just copied these from the py26-pyflakes >> port, so we >> should fix those also. >> >> This would be a good thing for port lint, as it's not obvious. > > It's hard to detect if an backslash escape is meant for Tcl or the > regex. Remember that you cannot use variables inside curly braces and > therefore sometimes you want to have additional backslashes. What > would > be the rule to warn on port lint? I guess if it finds unescaped .'s. Blair From jberry at macports.org Wed Oct 14 20:25:26 2009 From: jberry at macports.org (James Berry) Date: Wed, 14 Oct 2009 20:25:26 -0700 Subject: The opendarwin .com debacle In-Reply-To: <20091015021454.GV567@ninagal.withay.com> References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> Message-ID: <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> Well, Mat Caughron , or caughron at gmail.com, who is the guy who runs the darwinports [dot] com site in question, and who makes money by confusing our users and soliciting donations for the work of the macports proejct, none of which ever get to the project, is a apparently a consultant who professes to specialize in OS and web security. Maybe we should just publicize all of the information about what a sleeze-ball he is about this, and see if it gets back to his clients? We could put a big banner on our page: "Mat Caughron is a sleezeball: read more". Maybe we can get some of the trade press to do an article on people who make money by unethically pretending to be open-source software projects? James On Oct 14, 2009, at 7:14 PM, Bryan Blackburn wrote: > On Wed, Oct 14, 2009 at 03:55:14PM -0700, Scott Haneda said: >> On Oct 14, 2009, at 1:16 PM, Jeremy Lavergne wrote: > [...] >>> I recall in the past when reading his emails with the portmgrs that >>> he thought it was helpful to visitors. We need to document that >>> it's clearly not and inform him as such. Legal action can already >>> be taken since macports.org is copywriter with all rights reserved. >>> He is likely stealing content from us. >> >> What is the last communication that was had with Matt, and what is >> his position? Is there any point in opening dialogue with him again? > > The last public communication, that I know of, is linked on our > DarwinPorts > page: > > > > [...] >> What is it, it is not .net as far as I can tell, which seems to be >> available. I would like to purchase this domain now, and donate it >> to macports, I can do the redirection or they can have the entire >> domain. How do I proceed? > > I used to own darwinports dot net and just had it forward to the right > place; I didn't renew it a couple years ago because of the move to > MacPorts > in all things. At this point, it's been MacPorts for over three > years now, > so the real message these days is really, DarwinPorts is long dead. > >> >> This is a concern, that site is beating the official source in >> ranking >> http://www.google.com/search?hl=en&source=hp&q=darwinports&aq=f&oq=&aqi=g10 > > Yeah, I think that's mostly because of .domain being used. > > [...] >>> It is a violation: all rights for access to content on >>> macports.org are RESERVED. We can technically already slap him >>> with a takedown notice. >> >> Can you find the ISP? I do not think there would be a lot of luck >> hitting up register.com, as domain take downs are a nasty road to go >> down. > > Note that there really isn't any kind of actionable violation, as > MacPorts > uses the BSD license, and the web page there looks to be his own > creation... > > Bryan > > [...] > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From talklists at newgeo.com Wed Oct 14 22:48:38 2009 From: talklists at newgeo.com (Scott Haneda) Date: Wed, 14 Oct 2009 22:48:38 -0700 Subject: The opendarwin .com debacle In-Reply-To: <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> Message-ID: Adding more... http://freebsdgirl.com/2006/11/i-love-california.html Clear evidence of confusion only a few years back. It's pretty simple to see the circles he travels in. I say give him one last chance to do the right thing, at which point, we can discuss the next step. -- Scott * If you contact me off list replace talklists@ with scott@ * On Oct 14, 2009, at 8:25 PM, James Berry wrote: > Well, Mat Caughron , or caughron at gmail.com, who is > the guy who runs the darwinports [dot] com site in question, and who > makes money by confusing our users and soliciting donations for the > work of the macports proejct, none of which ever get to the project, > is a apparently a consultant who professes to specialize in OS and > web security. > > Maybe we should just publicize all of the information about what a > sleeze-ball he is about this, and see if it gets back to his > clients? We could put a big banner on our page: "Mat Caughron is a > sleezeball: read more". Maybe we can get some of the trade press to > do an article on people who make money by unethically pretending to > be open-source software projects? > > James From ryandesign at macports.org Thu Oct 15 00:57:15 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 15 Oct 2009 02:57:15 -0500 Subject: [59446] trunk/dports/python/py25-pybtex/Portfile In-Reply-To: <20091015074308.1EECB2A1B5D0@beta.macosforge.org> References: <20091015074308.1EECB2A1B5D0@beta.macosforge.org> Message-ID: On Oct 15, 2009, at 02:43, lightnin at macports.org wrote: > Revision: 59446 > http://trac.macports.org/changeset/59446 > Author: lightnin at macports.org > Date: 2009-10-15 00:43:04 -0700 (Thu, 15 Oct 2009) > Log Message: > ----------- > Updated py25-pybtex to latest version 0.11 from september 7th 2009. > Modified Paths: > -------------- > trunk/dports/python/py25-pybtex/Portfile > > Modified: trunk/dports/python/py25-pybtex/Portfile > =================================================================== > --- trunk/dports/python/py25-pybtex/Portfile 2009-10-15 06:53:44 UTC > (rev 59445) > +++ trunk/dports/python/py25-pybtex/Portfile 2009-10-15 07:43:04 UTC > (rev 59446) > @@ -5,10 +5,10 @@ > PortGroup python25 1.0 > > name py25-pybtex > -version 20090402 > +version 0.11 MacPorts isn't going to know on its own that "0.11" is supposed to be considered newer than "20090402". It's going to compare the first dot- separated number of each, see that "0" is smaller than "20090402", and not show the port in "port outdated". To fix this, I increased the epoch from its default 0 to 1. Keep this in mind any time you upgrade the version in a way that the version numbers do not increase in the usual way. Note that the epoch line can never be removed from a portfile. The epoch can only ever increase. From vince at macports.org Thu Oct 15 02:39:39 2009 From: vince at macports.org (vincent habchi) Date: Thu, 15 Oct 2009 11:39:39 +0200 Subject: Metaport Message-ID: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> Is there a way to write a "meta-port", a Portfile that would call another Portfile? Thanks Vincent From jmr at macports.org Thu Oct 15 03:03:16 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 15 Oct 2009 21:03:16 +1100 Subject: Metaport In-Reply-To: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> References: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> Message-ID: <4AD6F364.1090508@macports.org> On 2009-10-15 20:39, vincent habchi wrote: > Is there a way to write a "meta-port", a Portfile that would call > another Portfile? With the aim of accomplishing what? - Josh From afb at macports.org Thu Oct 15 03:22:57 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 15 Oct 2009 12:22:57 +0200 Subject: Metaport In-Reply-To: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> References: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> Message-ID: vincent habchi wrote: > Is there a way to write a "meta-port", a Portfile that would call > another Portfile? Sure, here is one: http://trac.macports.org/browser/trunk/dports/xfce/ xfce/Portfile --anders From jmr at macports.org Thu Oct 15 04:14:14 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 15 Oct 2009 22:14:14 +1100 Subject: Metaport In-Reply-To: References: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> Message-ID: <4AD70406.4050501@macports.org> On 2009-10-15 21:22, Anders F Bj?rklund wrote: > vincent habchi wrote: > >> Is there a way to write a "meta-port", a Portfile that would call >> another Portfile? > > Sure, here is one: > http://trac.macports.org/browser/trunk/dports/xfce/xfce/Portfile Don't copy the adding of blank fetch, checksum and configure procedures though. Clearing distfiles makes the first two unnecessary, and 'use_configure no' is the preferred way of accomplishing the third. - Josh From afb at macports.org Thu Oct 15 04:27:25 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Thu, 15 Oct 2009 13:27:25 +0200 Subject: Metaport In-Reply-To: <4AD70406.4050501@macports.org> References: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> <4AD70406.4050501@macports.org> Message-ID: <48F40EB6-4CA9-4C93-BE56-CA4BFB89DCC8@macports.org> Joshua Root wrote: >> http://trac.macports.org/browser/trunk/dports/xfce/xfce/Portfile > > Don't copy the adding of blank fetch, checksum and configure > procedures > though. Clearing distfiles makes the first two unnecessary, and > 'use_configure no' is the preferred way of accomplishing the third. Fixed, http://trac.macports.org/changeset/59457 --anders From vince at macports.org Thu Oct 15 05:04:35 2009 From: vince at macports.org (vincent habchi) Date: Thu, 15 Oct 2009 14:04:35 +0200 Subject: Metaport In-Reply-To: <4AD6F364.1090508@macports.org> References: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> <4AD6F364.1090508@macports.org> Message-ID: Le 15 oct. 2009 ? 12:03, Joshua Root a ?crit : > On 2009-10-15 20:39, vincent habchi wrote: >> Is there a way to write a "meta-port", a Portfile that would call >> another Portfile? > > With the aim of accomplishing what? Universal variant for the Atlas port. It is not possible to rely on a traditional x-way build because the code compiles asm code to detect CPU type (it is strongly optimized). Muniversal won't work either, so the solution I was thinking of is to do a first build in 64-bit mode then another in 32-bit mode then lipo the results. But the Portfile is complex, so the most easy way to do that would be to call it twice, instead of modifying it. Vincent From jmr at macports.org Thu Oct 15 05:32:11 2009 From: jmr at macports.org (Joshua Root) Date: Thu, 15 Oct 2009 23:32:11 +1100 Subject: Metaport In-Reply-To: References: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> <4AD6F364.1090508@macports.org> Message-ID: <4AD7164B.20802@macports.org> On 2009-10-15 23:04, vincent habchi wrote: > Le 15 oct. 2009 ? 12:03, Joshua Root a ?crit : > >> On 2009-10-15 20:39, vincent habchi wrote: >>> Is there a way to write a "meta-port", a Portfile that would call >>> another Portfile? >> >> With the aim of accomplishing what? > > Universal variant for the Atlas port. It is not possible to rely on a > traditional x-way build because the code compiles asm code to detect CPU > type (it is strongly optimized). Muniversal won't work either, so the > solution I was thinking of is to do a first build in 64-bit mode then > another in 32-bit mode then lipo the results. That is, in theory at least, exactly what muniversal does. If it doesn't do what you need in this case, fixing it is a better idea than reinventing the wheel. - Josh From vince at macports.org Thu Oct 15 06:10:27 2009 From: vince at macports.org (vincent habchi) Date: Thu, 15 Oct 2009 15:10:27 +0200 Subject: Metaport In-Reply-To: References: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> <24426824-6B14-415B-960B-D3D2F5751734@macports.org> Message-ID: Anders, > Think you are looking for either "port groups", or "copy paste", > then instead... Could be. Can some point me to the code of muniversal? Thanks Vincent From jmr at macports.org Thu Oct 15 07:17:46 2009 From: jmr at macports.org (Joshua Root) Date: Fri, 16 Oct 2009 01:17:46 +1100 Subject: Metaport In-Reply-To: References: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> <24426824-6B14-415B-960B-D3D2F5751734@macports.org> Message-ID: <4AD72F0A.1030908@macports.org> On 2009-10-16 00:10, vincent habchi wrote: > Anders, > >> Think you are looking for either "port groups", or "copy paste", then >> instead... > > Could be. Can some point me to the code of muniversal? under dports/_resources/port1.0/group/ - Josh From vince at macports.org Thu Oct 15 08:26:20 2009 From: vince at macports.org (vincent habchi) Date: Thu, 15 Oct 2009 17:26:20 +0200 Subject: Metaport In-Reply-To: <4AD72F0A.1030908@macports.org> References: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> <24426824-6B14-415B-960B-D3D2F5751734@macports.org> <4AD72F0A.1030908@macports.org> Message-ID: Le 15 oct. 2009 ? 16:17, Joshua Root a ?crit : > under dports/_resources/port1.0/group/ Thanks. Is there any kind of doc? More specifically, does the Portfile of the muniversal group know of the variable values set by muniversal? Still more specifically, I need to alter a configuration switch according to whether the compilation is 32 or 64-bit. Is this possible through a test on ${os.arch}? Thanks, Vincent From ryandesign at macports.org Thu Oct 15 08:48:22 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 15 Oct 2009 10:48:22 -0500 Subject: [59465] trunk/dports/python/py26-flup/Portfile In-Reply-To: <20091015132804.7BEDD2A1EDC6@beta.macosforge.org> References: <20091015132804.7BEDD2A1EDC6@beta.macosforge.org> Message-ID: On Oct 15, 2009, at 08:28, lightnin at macports.org wrote: > Revision: 59465 > http://trac.macports.org/changeset/59465 > Author: lightnin at macports.org > Date: 2009-10-15 06:28:02 -0700 (Thu, 15 Oct 2009) > Log Message: > ----------- > Updated py26-flup to latest version 1.0.3.dev.20090716. Since this changes what files were installed, you must increase the port's revision so users who already had the port installed are alerted to this update via "port outdated". The same applies to py25- flup. > @@ -17,8 +17,9 @@ > > homepage http://www.saddi.com/software/flup > master_sites http://pypi.python.org/packages/source/f/flup/ > -distname flup-${version}.dev-20090612 > -checksums md5 ec3b6bbdfb697536274f605256cddb62 \ > - sha1 > 12da63a23d5e35178a1c2cd21ccb8b74d7d9db76 \ > - rmd160 9a1a90c64a21669b47f98737f1cb81aa40ecc261 > +distname flup-${version}.dev-20090716 > +checksums md5 087ddf678a921313b21b90570f54eb42 \ > + sha1 d8436e0a2a93ef43f61e571be3df69ca6fb74483 \ > + rmd160 9215835160e6a1c2a7fcf4a43ae4b673a06a6a12 > > +depends_lib port:py26-setuptools > \ No newline at end of file You should make sure that you always end your files with a newline. Some editors can be configured to automatically do this for you. (I use TextWrangler and have it configured this way.) From ryandesign at macports.org Thu Oct 15 08:50:51 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 15 Oct 2009 10:50:51 -0500 Subject: [59460] trunk/dports/sysutils/rpm/Portfile In-Reply-To: <20091015121637.DCE8B2A1DEC7@beta.macosforge.org> References: <20091015121637.DCE8B2A1DEC7@beta.macosforge.org> Message-ID: <8A905C9C-00B4-441C-B435-3B9A1B67CFB5@macports.org> On Oct 15, 2009, at 07:16, afb at macports.org wrote: > Revision: 59460 > http://trac.macports.org/changeset/59460 > Author: afb at macports.org > Date: 2009-10-15 05:16:34 -0700 (Thu, 15 Oct 2009) > Log Message: > ----------- > old zlib breaks for parallel builds > > Modified Paths: > -------------- > trunk/dports/sysutils/rpm/Portfile > > Modified: trunk/dports/sysutils/rpm/Portfile > =================================================================== > --- trunk/dports/sysutils/rpm/Portfile 2009-10-15 11:54:03 UTC (rev > 59459) > +++ trunk/dports/sysutils/rpm/Portfile 2009-10-15 12:16:34 UTC (rev > 59460) > @@ -33,6 +33,7 @@ > bin:unzip:unzip > > build.type gnu > +build.jobs 1 How is this different from setting "use_parallel_build no"? From ryandesign at macports.org Thu Oct 15 08:54:53 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 15 Oct 2009 10:54:53 -0500 Subject: [59475] trunk/dports/games/moria/Portfile In-Reply-To: <20091015154126.E10B72A210A4@beta.macosforge.org> References: <20091015154126.E10B72A210A4@beta.macosforge.org> Message-ID: <793E560D-2690-4C45-9075-91D79AE17F57@macports.org> On Oct 15, 2009, at 10:41, aschenke at macports.org wrote: > Revision: 59475 > http://trac.macports.org/changeset/59475 > Author: aschenke at macports.org > Date: 2009-10-15 08:41:25 -0700 (Thu, 15 Oct 2009) > Log Message: > ----------- > bumping revision > +revision 0 This does not bump the revision. "0" is the default for revision, so you just made it explicit, but this doesn't change anything. If you want to cause people to see this port in "port outdated" and thus be prompted to rebuild (which you do, since you just changed its dependencies and how it builds in the previous commit), you should increase the revision to 1. The same feedback applies to rogue. From ryandesign at macports.org Thu Oct 15 08:55:36 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 15 Oct 2009 10:55:36 -0500 Subject: [59473] trunk/dports/games/moria/Portfile In-Reply-To: <20091015153222.888B02A20E4C@beta.macosforge.org> References: <20091015153222.888B02A20E4C@beta.macosforge.org> Message-ID: <4599BCA0-7D0D-4945-9B4E-BF7A0FD94BE8@macports.org> On Oct 15, 2009, at 10:32, aschenke at macports.org wrote: > Revision: 59473 > http://trac.macports.org/changeset/59473 > Author: aschenke at macports.org > Date: 2009-10-15 08:32:21 -0700 (Thu, 15 Oct 2009) > Log Message: > ----------- > require and link to MacPort's ncurses library > - reinplace "s|CFLAGS = -O|CFLAGS = -O - > DNCURSES_OPAQUE=0|" ${build.dir}/Makefile > + reinplace "s|CFLAGS = -O|CFLAGS = -O -I$ > {prefix}/include -I${prefix}/include/ncurses|" ${build.dir}/Makefile > + reinplace "s|LFLAGS =|LFLAGS = -L/opt/local/ > lib|" ${build.dir}/Makefile > + reinplace "s|CURSES = -lcurses -ltermcap|CURSES > = -lncurses|" ${build.dir}/Makefile You must not hardcode "/opt/local" in portfiles; please use "$ {prefix}" instead. From ryandesign at macports.org Thu Oct 15 09:08:28 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 15 Oct 2009 11:08:28 -0500 Subject: Metaport In-Reply-To: References: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> <24426824-6B14-415B-960B-D3D2F5751734@macports.org> <4AD72F0A.1030908@macports.org> Message-ID: On Oct 15, 2009, at 10:26, vincent habchi wrote: > Le 15 oct. 2009 ? 16:17, Joshua Root a ?crit : > >> under dports/_resources/port1.0/group/ > > Thanks. Is there any kind of doc? Only the comments in the portgroup file, as far as I know, and looking at existing portfiles that use it. > More specifically, does the Portfile of the muniversal group know of > the variable values set by muniversal? Still more specifically, I > need to alter a configuration switch according to whether the > compilation is 32 or 64-bit. Is this possible through a test on $ > {os.arch}? This is possible without needing to do anything complicated. You can just set the merger_configure_args list with the desired values. There are some existing ports that use this, which you can look at for examples: nspr uses it to add "--enable-64bit" on 64-bit architectures. fontconfig uses it to specify the architecture in a "-- with-arch" flag. tiff uses it to ensure "--with-apple-opengl- framework" is not used on 64-bit architectures on Tiger. gtk2 adds "-- disable-cups" on 64-bit architectures on Tiger. fftw-3 adds "--enable- fma" on PowerPC systems and "--enable-sse2" on Intel systems. You probably won't need this, but aside from the muniversal portgroup, there is also the almost-forgotten "merge" procedure. This is useful if you already have multiple binaries and just want to lipo them together. I use it in the minivmac portfile, though to see it in action, you'll have to use the minivmac-devel portfile and build MacPorts trunk, since MacPorts 1.8.1's merge had some bugs which made it not work for my needs. I say you probably won't need the merge procedure for your task, because you also need to configure and build for each arch. So you're better off using muniversal which was designed exactly for this. From ryandesign at macports.org Thu Oct 15 09:28:27 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 15 Oct 2009 11:28:27 -0500 Subject: [59483] trunk/dports/games/larn/Portfile In-Reply-To: <20091015161141.A18B02A21775@beta.macosforge.org> References: <20091015161141.A18B02A21775@beta.macosforge.org> Message-ID: <1001D39A-922C-40E0-8D1C-C59003312DDA@macports.org> On Oct 15, 2009, at 11:11, aschenke at macports.org wrote: > Revision: 59483 > http://trac.macports.org/changeset/59483 > Author: aschenke at macports.org > Date: 2009-10-15 09:11:39 -0700 (Thu, 15 Oct 2009) > Log Message: > ----------- > append build environment settings rather than overwrite > > Modified Paths: > -------------- > trunk/dports/games/larn/Portfile > > Modified: trunk/dports/games/larn/Portfile > =================================================================== > --- trunk/dports/games/larn/Portfile 2009-10-15 16:07:02 UTC (rev > 59482) > +++ trunk/dports/games/larn/Portfile 2009-10-15 16:11:39 UTC (rev > 59483) > @@ -17,7 +17,7 @@ > checksums md5 cea96f48caa057793f6bcaf3394ca388 > build.type bsd > build.args CC=${configure.cc} > -build.env CFLAGS=-I${prefix}/include -I${prefix}/include/ncurses > +build.env-append CFLAGS=-I${prefix}/include -I${prefix}/include/ > ncurses Looking in the debug output, I don't believe this is having the desired effect: ---> Building larn DEBUG: Executing org.macports.build (larn) DEBUG: Environment: CFLAGS='-I/opt/local/include' MACOSX_DEPLOYMENT_TARGET='10.6' If you want to pass multiple values to CFLAGS, you will want to quote the value: build.env-append CFLAGS="-I${prefix}/include -I${prefix}/include/ ncurses" I am not sure why the port is succeeding in building against the MacPorts ncurses even though it never saw your -I${prefix}/include/ ncurses before. From jeremy at lavergne.gotdns.org Thu Oct 15 11:57:45 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 15 Oct 2009 14:57:45 -0400 Subject: users confusing selfupdate and sync Message-ID: <8ACCAE5C-0EF0-48F4-A4C4-2904B5EF5275@lavergne.gotdns.org> I've seen lots and lots of people suggesting the use of sync and never realizing that they weren't upgrading MacPorts. I've found it rather frustrating because it does not seem to be getting better. Is there a way we can better document this or perhaps change the functionality? We could slip an option into sync so that it does selfupdate unless you pass it an argument (e.g., sync --portsonly). This will not force users to be re-educated and it will provide the benefit of ensuring people are upgrading correctly. Thoughts? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4024 bytes Desc: not available URL: From alakazam at macports.org Thu Oct 15 14:46:07 2009 From: alakazam at macports.org (Olivier Le Floch) Date: Thu, 15 Oct 2009 23:46:07 +0200 Subject: users confusing selfupdate and sync In-Reply-To: <8ACCAE5C-0EF0-48F4-A4C4-2904B5EF5275@lavergne.gotdns.org> References: <8ACCAE5C-0EF0-48F4-A4C4-2904B5EF5275@lavergne.gotdns.org> Message-ID: <6EDE2ED6-C250-49D2-AFD6-39453E1EC2A8@macports.org> Hi ! On 15 oct. 09, at 20:57, Jeremy Lavergne wrote: > Is there a way we can better document this or perhaps change the > functionality? > > We could slip an option into sync so that it does selfupdate unless > you pass it an argument (e.g., sync --portsonly). This will not > force users to be re-educated and it will provide the benefit of > ensuring people are upgrading correctly. The best might be to remind users that call "port sync" that "port selfupdate" is the "usual" next step in updating ports. i.e. "port sync" would end by displaying something like > "Portfiles successfully updated. To upgrade installed ports to their > latest versions, please run port selfupdate." Regards, -- Olivier From jeremy at lavergne.gotdns.org Thu Oct 15 14:49:03 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 15 Oct 2009 17:49:03 -0400 Subject: users confusing selfupdate and sync In-Reply-To: <6EDE2ED6-C250-49D2-AFD6-39453E1EC2A8@macports.org> References: <8ACCAE5C-0EF0-48F4-A4C4-2904B5EF5275@lavergne.gotdns.org> <6EDE2ED6-C250-49D2-AFD6-39453E1EC2A8@macports.org> Message-ID: <94EE03BE-1754-4D37-AEBD-E54EE0BFF64D@lavergne.gotdns.org> >> Is there a way we can better document this or perhaps change the >> functionality? >> >> We could slip an option into sync so that it does selfupdate unless >> you pass it an argument (e.g., sync --portsonly). This will not >> force users to be re-educated and it will provide the benefit of >> ensuring people are upgrading correctly. > > The best might be to remind users that call "port sync" that "port > selfupdate" is the "usual" next step in updating ports. i.e. "port > sync" would end by displaying something like > >> "Portfiles successfully updated. To upgrade installed ports to >> their latest versions, please run port selfupdate." selfupdate doesn't update anything but update MacPorts itself and the ports tree. If I understood you correctly, they'd then be running `port upgrade outdated` which still leaves MacPorts itself not updated. However, you do bring up an interesting idea I hadn't considered: why don't we have a command to do a all-things upgrade? That is `selfupdate` + `upgrade outdated`? From alakazam at macports.org Thu Oct 15 15:07:20 2009 From: alakazam at macports.org (Olivier Le Floch) Date: Fri, 16 Oct 2009 00:07:20 +0200 Subject: users confusing selfupdate and sync In-Reply-To: <94EE03BE-1754-4D37-AEBD-E54EE0BFF64D@lavergne.gotdns.org> References: <8ACCAE5C-0EF0-48F4-A4C4-2904B5EF5275@lavergne.gotdns.org> <6EDE2ED6-C250-49D2-AFD6-39453E1EC2A8@macports.org> <94EE03BE-1754-4D37-AEBD-E54EE0BFF64D@lavergne.gotdns.org> Message-ID: <7210BEF0-1561-4403-BC45-3A8F186FB33D@macports.org> >> The best might be to remind users that call "port sync" that "port >> selfupdate" is the "usual" next step in updating ports. i.e. "port >> sync" would end by displaying something like >> >>> "Portfiles successfully updated. To upgrade installed ports to >>> their latest versions, please run port selfupdate." > > selfupdate doesn't update anything but update MacPorts itself and > the ports tree. If I understood you correctly, they'd then be > running `port upgrade outdated` which still leaves MacPorts itself > not updated. Oh -_- Right, having higher level scripts that call these commands automatically made me forget how things worked... People are calling sync ? I agree then that this isn't ideal, and your solution (sync works just as selfupdate, with a --portfiles_only option) seems adequate to me. If there isn't a consensus on this "merging", however, reminding users that the "port" command hasn't been upgraded would be a minimum (fix my end-of-sync sentence above to read "To upgrade the 'port' command, please run 'port selfupdate'." :) ). > However, you do bring up an interesting idea I hadn't considered: > why don't we have a command to do a all-things upgrade? That is > `selfupdate` + `upgrade outdated`? This has been discussed before (Ryan probably was the clearest on why we do things this way, iirc). One reason I think was that "port upgrade" warranted some caution, in particular as to which ports would be in fact, upgraded, so that many users do > port selfupdate > port outdated > port upgrade outdated (if "port outdated"'s output isn't scary, else > they upgrade only some ports) this would be the equivalent of other packaging system's "confirmation before upgrading" dialogs (apt-get, aptitude ask before upgrading installed software and list the changes that will be made). This would be a bit more development, and I guess discussion came to an end there. From mark at dxradio.demon.co.uk Thu Oct 15 15:28:54 2009 From: mark at dxradio.demon.co.uk (Mark Hattam) Date: Thu, 15 Oct 2009 23:28:54 +0100 Subject: users confusing selfupdate and sync In-Reply-To: <7210BEF0-1561-4403-BC45-3A8F186FB33D@macports.org> References: <8ACCAE5C-0EF0-48F4-A4C4-2904B5EF5275@lavergne.gotdns.org> <6EDE2ED6-C250-49D2-AFD6-39453E1EC2A8@macports.org> <94EE03BE-1754-4D37-AEBD-E54EE0BFF64D@lavergne.gotdns.org> <7210BEF0-1561-4403-BC45-3A8F186FB33D@macports.org> Message-ID: On 15 Oct 2009, at 23:07, Olivier Le Floch wrote: >>> The best might be to remind users that call "port sync" that "port >>> selfupdate" is the "usual" next step in updating ports. i.e. "port >>> sync" would end by displaying something like >>> >>>> "Portfiles successfully updated. To upgrade installed ports to >>>> their latest versions, please run port selfupdate." >> >> selfupdate doesn't update anything but update MacPorts itself and >> the ports tree. If I understood you correctly, they'd then be >> running `port upgrade outdated` which still leaves MacPorts itself >> not updated. > > Oh -_- Right, having higher level scripts that call these commands > automatically made me forget how things worked... People are calling > sync ? I agree then that this isn't ideal, and your solution (sync > works just as selfupdate, with a --portfiles_only option) seems > adequate to me. > > If there isn't a consensus on this "merging", however, reminding > users that the "port" command hasn't been upgraded would be a > minimum (fix my end-of-sync sentence above to read "To upgrade the > 'port' command, please run 'port selfupdate'." :) ). > >> However, you do bring up an interesting idea I hadn't considered: >> why don't we have a command to do a all-things upgrade? That is >> `selfupdate` + `upgrade outdated`? > > This has been discussed before (Ryan probably was the clearest on > why we do things this way, iirc). One reason I think was that "port > upgrade" warranted some caution, in particular as to which ports > would be in fact, upgraded, so that many users do > >> port selfupdate >> port outdated >> port upgrade outdated (if "port outdated"'s output isn't scary, >> else they upgrade only some ports) > > this would be the equivalent of other packaging system's > "confirmation before upgrading" dialogs (apt-get, aptitude ask > before upgrading installed software and list the changes that will > be made). This would be a bit more development, and I guess > discussion came to an end there. I have my own little shell script that does (amongst other things) sudo port -v selfupdate sudo port outdated #sudo port upgrade outdated #sudo port uninstall -f inactive echo All Done The commented lines are because a few versions of Macports ago, if you tried sudo port upgrade outdated and "outdated" was nothing, ie nothing needed upgrading, then there was a very confusing error message. But I've just tried it in 1.8.1 and although it could be slightly better it's not as bad as it once was. iMac:~ $ sudo port upgrade outdated Error: No ports matched the given expression "There are no upgrades available in MacPorts for your installed ports." is perhaps a clearer message for users in this case. Mark From jeremy at lavergne.gotdns.org Thu Oct 15 15:31:50 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 15 Oct 2009 18:31:50 -0400 Subject: users confusing selfupdate and sync In-Reply-To: References: <8ACCAE5C-0EF0-48F4-A4C4-2904B5EF5275@lavergne.gotdns.org> <6EDE2ED6-C250-49D2-AFD6-39453E1EC2A8@macports.org> <94EE03BE-1754-4D37-AEBD-E54EE0BFF64D@lavergne.gotdns.org> <7210BEF0-1561-4403-BC45-3A8F186FB33D@macports.org> Message-ID: <7FE23485-D9F4-4A19-B81D-974BCEB0DD6C@lavergne.gotdns.org> > I have my own little shell script that does (amongst other things) > > sudo port -v selfupdate > sudo port outdated > #sudo port upgrade outdated > #sudo port uninstall -f inactive > echo All Done > > The commented lines are because a few versions of Macports ago, if > you tried > sudo port upgrade outdated > and "outdated" was nothing, ie nothing needed upgrading, then there > was a very confusing error message. > > But I've just tried it in 1.8.1 and although it could be slightly > better it's not as bad as it once was. > > iMac:~ $ sudo port upgrade outdated > Error: No ports matched the given expression > > "There are no upgrades available in MacPorts for your installed > ports." > is perhaps a clearer message for users in this case. This happens because the expansion of commands is done right to left. We don't know that we're upgrading until after we've tried to match "outdated." -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4024 bytes Desc: not available URL: From howarth at bromo.med.uc.edu Thu Oct 15 15:41:33 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Thu, 15 Oct 2009 18:41:33 -0400 Subject: convention for compiling .py on MacPorts? Message-ID: <20091015224133.GA15440@bromo.med.uc.edu> One change that might be useful to the pymol package would be to compile the python scripts upon installation. In fink, we can do this with... PostInstScript: << update-alternatives --install %p/bin/pymol pymol %p/lib/pymol-py%type_pkg[python]/bin/pymol %type_pkg[python] %p/bin/python%type_raw[python] -O %p/lib/python%type_raw[python]/compileall.py -q %p/lib/%n/modules << PreRmScript: << if [ $1 != "upgrade" ]; then update-alternatives --remove pymol %p/lib/pymol-py%type_pkg[python]/bin/pymol fi PACKAGE=%N dpkg --listfiles $PACKAGE | /usr/bin/awk '$0~/\.py$/ {print $0"c\n" $0"o"}' | xargs rm -f >&2 << Do any MacPorts packages that use python compile their scripts and is there an accepted convention for doing this in MacPorts? Jack From howarth at bromo.med.uc.edu Thu Oct 15 16:03:09 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Thu, 15 Oct 2009 19:03:09 -0400 Subject: convention for compiling .py on MacPorts? In-Reply-To: <20091015224133.GA15440@bromo.med.uc.edu> References: <20091015224133.GA15440@bromo.med.uc.edu> Message-ID: <20091015230309.GA15569@bromo.med.uc.edu> On Thu, Oct 15, 2009 at 06:41:33PM -0400, Jack Howarth wrote: > One change that might be useful to the pymol package would be to > compile the python scripts upon installation. In fink, we can do > this with... > > PostInstScript: << > update-alternatives --install %p/bin/pymol pymol %p/lib/pymol-py%type_pkg[python]/bin/pymol %type_pkg[python] > %p/bin/python%type_raw[python] -O %p/lib/python%type_raw[python]/compileall.py -q %p/lib/%n/modules > << > PreRmScript: << > if [ $1 != "upgrade" ]; then > update-alternatives --remove pymol %p/lib/pymol-py%type_pkg[python]/bin/pymol > fi > PACKAGE=%N > dpkg --listfiles $PACKAGE | > /usr/bin/awk '$0~/\.py$/ {print $0"c\n" $0"o"}' | > xargs rm -f >&2 > << > > Do any MacPorts packages that use python compile their scripts and is > there an accepted convention for doing this in MacPorts? > Jack > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev I notice some MacPorts Portfile's are compiling the python scripts in post-destroot but I suspect this will result in the destroot path being in the compiled python code rather than the actual the actual installation directory. I suspect the --destdir option to compileall.py may solve this issue. If so, the MacPorts that are compiling python scripts in post-destroot should be using that option. Jack From mark at dxradio.demon.co.uk Thu Oct 15 16:04:09 2009 From: mark at dxradio.demon.co.uk (Mark Hattam) Date: Fri, 16 Oct 2009 00:04:09 +0100 Subject: users confusing selfupdate and sync In-Reply-To: <7FE23485-D9F4-4A19-B81D-974BCEB0DD6C@lavergne.gotdns.org> References: <8ACCAE5C-0EF0-48F4-A4C4-2904B5EF5275@lavergne.gotdns.org> <6EDE2ED6-C250-49D2-AFD6-39453E1EC2A8@macports.org> <94EE03BE-1754-4D37-AEBD-E54EE0BFF64D@lavergne.gotdns.org> <7210BEF0-1561-4403-BC45-3A8F186FB33D@macports.org> <7FE23485-D9F4-4A19-B81D-974BCEB0DD6C@lavergne.gotdns.org> Message-ID: <9CA07A24-E280-46AC-ADE7-5E717E37EB92@dxradio.demon.co.uk> On 15 Oct 2009, at 23:31, Jeremy Lavergne wrote: >> I have my own little shell script that does (amongst other things) >> >> sudo port -v selfupdate >> sudo port outdated >> #sudo port upgrade outdated >> #sudo port uninstall -f inactive >> echo All Done >> >> The commented lines are because a few versions of Macports ago, if >> you tried >> sudo port upgrade outdated >> and "outdated" was nothing, ie nothing needed upgrading, then there >> was a very confusing error message. >> >> But I've just tried it in 1.8.1 and although it could be slightly >> better it's not as bad as it once was. >> >> iMac:~ $ sudo port upgrade outdated >> Error: No ports matched the given expression >> >> "There are no upgrades available in MacPorts for your installed >> ports." >> is perhaps a clearer message for users in this case. > > This happens because the expansion of commands is done right to > left. We don't know that we're upgrading until after we've tried to > match "outdated." As I say, it's better now than the scenario a few versions back (1.7) Two previous threads on that were from late December 2008 inconsistent error mesgs (1.7) Error message when nothing to upgrade? At that time the error printed was Error: No ports found But it's still true that although Error: No ports matched the given expression is *technically* correct, it's still not entirely user friendly for the masses. Mark From jeremy at lavergne.gotdns.org Thu Oct 15 16:05:43 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 15 Oct 2009 19:05:43 -0400 Subject: users confusing selfupdate and sync In-Reply-To: <9CA07A24-E280-46AC-ADE7-5E717E37EB92@dxradio.demon.co.uk> References: <8ACCAE5C-0EF0-48F4-A4C4-2904B5EF5275@lavergne.gotdns.org> <6EDE2ED6-C250-49D2-AFD6-39453E1EC2A8@macports.org> <94EE03BE-1754-4D37-AEBD-E54EE0BFF64D@lavergne.gotdns.org> <7210BEF0-1561-4403-BC45-3A8F186FB33D@macports.org> <7FE23485-D9F4-4A19-B81D-974BCEB0DD6C@lavergne.gotdns.org> <9CA07A24-E280-46AC-ADE7-5E717E37EB92@dxradio.demon.co.uk> Message-ID: > As I say, it's better now than the scenario a few versions back (1.7) > > Two previous threads on that were from late December 2008 > inconsistent error mesgs (1.7) > Error message when nothing to upgrade? > > At that time the error printed was > Error: No ports found > > But it's still true that although > Error: No ports matched the given expression > is *technically* correct, it's still not entirely user friendly for > the masses. coaxing legacy code to work after a decade [1] can be fun ... [1] pull that out of my /dev/random -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4024 bytes Desc: not available URL: From blb at macports.org Thu Oct 15 16:28:08 2009 From: blb at macports.org (Bryan Blackburn) Date: Thu, 15 Oct 2009 17:28:08 -0600 Subject: New committers: adfernandes, lightnin, sharky, and stromnov Message-ID: <20091015232808.GB567@ninagal.withay.com> Please join us in welcoming the following new MacPorts committers: - Andrew Fernandes (adfernandes) - Christian Federmann (lightnin) - Jeremy Lain? (sharky) - Andrew Stromnov (stromnov) 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 talklists at newgeo.com Thu Oct 15 16:57:15 2009 From: talklists at newgeo.com (Scott Haneda) Date: Thu, 15 Oct 2009 16:57:15 -0700 Subject: New committers: adfernandes, lightnin, sharky, and stromnov In-Reply-To: <20091015232808.GB567@ninagal.withay.com> References: <20091015232808.GB567@ninagal.withay.com> Message-ID: <8AD12CE8-336E-42F8-B66F-DF0A9D3F2E8A@newgeo.com> Hi everyone, glad to have more committers, thanks for your efforts. -- Scott * If you contact me off list replace talklists@ with scott@ * On Oct 15, 2009, at 4:28 PM, Bryan Blackburn wrote: > Please join us in welcoming the following new MacPorts committers: > > - Andrew Fernandes (adfernandes) > - Christian Federmann (lightnin) > - Jeremy Lain? (sharky) > - Andrew Stromnov (stromnov) > > 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 howarth at bromo.med.uc.edu Thu Oct 15 19:17:02 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Thu, 15 Oct 2009 22:17:02 -0400 Subject: request for review of tickets 21468/22106 Message-ID: <20091016021702.GA16811@bromo.med.uc.edu> Now that pymol is in MacPorts, the apbs/apbs-mpi packages need to be added to allow pymol's APBS-tool to create electrostatic potential maps. The apbs and apbs-mpi packages are subimitted as... http://trac.macports.org/ticket/21468 http://trac.macports.org/ticket/22106 The apbs package provides the non-mpi version required by pymol and also provides the python support for apbs (which isn't compatible with the mpi build of apbs). The apbs-mpi package provides the openmpi version of apbs for parallel calculations of electrostatic potential maps. Thanks in advance for any reviews. Jack ps I have added instructions for running the APBS Tool in pymol to the apbs ticket to add in testing apbs. From milosh at macports.org Fri Oct 16 00:52:45 2009 From: milosh at macports.org (Emmanuel Hainry) Date: Fri, 16 Oct 2009 09:52:45 +0200 Subject: users confusing selfupdate and sync In-Reply-To: <8ACCAE5C-0EF0-48F4-A4C4-2904B5EF5275@lavergne.gotdns.org> References: <8ACCAE5C-0EF0-48F4-A4C4-2904B5EF5275@lavergne.gotdns.org> Message-ID: <20091016075245.GA20949@auxy> So, the present state is sync only does some synchronization. selfupdate updates port itself. It seems clear enough to me. Also, sync needs to be used far more often than selfupdate, so making sync do the same as selfupdate would be overkill 90% of the time. Finally, when people are advised to do "port sync", it is to solve a bug in the porttree and in this case, sync is the right thing to do. If you feel that users misunderstand sync for update, then a message as suggested earlier would be the sane way of helping them. Note that programs like firefox call "auto-update" the selfupdate feature, and call sync the synchronization of data (bookmarks for example). Emmanuel Citando Jeremy Lavergne : > I've seen lots and lots of people suggesting the use of sync and never > realizing that they weren't upgrading MacPorts. I've found it rather > frustrating because it does not seem to be getting better. > > Is there a way we can better document this or perhaps change the > functionality? > > We could slip an option into sync so that it does selfupdate unless you > pass it an argument (e.g., sync --portsonly). This will not force users > to be re-educated and it will provide the benefit of ensuring people are > upgrading correctly. > > Thoughts? > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From raimue at macports.org Fri Oct 16 01:11:05 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 16 Oct 2009 10:11:05 +0200 Subject: users confusing selfupdate and sync In-Reply-To: <20091016075245.GA20949@auxy> References: <8ACCAE5C-0EF0-48F4-A4C4-2904B5EF5275@lavergne.gotdns.org> <20091016075245.GA20949@auxy> Message-ID: <4AD82A99.5000608@macports.org> On 2009-10-16 09:52 , Emmanuel Hainry wrote: > So, the present state is > sync only does some synchronization. > selfupdate updates port itself. And selfupdate also does sync unless you use --nosync. > It seems clear enough to me. > Also, sync needs to be used far more often than selfupdate, so making > sync do the same as selfupdate would be overkill 90% of the time. Some people also can't do selfupdate because they are behind a rigid firewall which does not allows rsync access to MacOSforge servers. There are alternatives to sync the ports tree over HTTP, but none for the MacPorts source itself. Rainer From blb at macports.org Fri Oct 16 01:25:48 2009 From: blb at macports.org (Bryan Blackburn) Date: Fri, 16 Oct 2009 02:25:48 -0600 Subject: The next MacPorts management In-Reply-To: <8CB2FB35-F38C-411A-98AB-40F77C62A4B1@lavergne.gotdns.org> Message-ID: <20091016082547.GE567@ninagal.withay.com> On Fri, Oct 09, 2009 at 12:14:30PM -0700, Darren Weber said: [...] > Sounds like MacPorts has no specific policy on the process, yet. Or is > there a wiki page about this somewhere? > > Does a term correspond to a fixed calendar date or interval? The guide has some documentation on policy: However, nothing about term length or specifics on how things are to be carried out. Hence my email to try and get a discussion on how the community as a whole would like to see things go forward. > > Is it possible for current "office bearers" to nominate for another term? You mean a 'the current group is good' vote? I'd say a new group of potential people should be able to include any/all of the current portmgr and let the community vote as we will. The other reason for my email is that I'd like to step down, hence at least the need for one more (if four people continues to be preferred, see below); don't know how the others are feeling about staying on or not. > > Are self nominations accepted? In the past at least, anyone interested would step up and say a bit about why they'd be a good choice, so that definitely seems like a sane idea to me. > > Take care, > Darren On Fri, Oct 09, 2009 at 06:10:32PM -0400, Jeremy Lavergne said: > Very good idea. > > Having a historian of sorts to show the ropes, fix any messes, etc. When the current portmgr took over, James, Juan, and Marcus were kind enough to stick around to help us out with any initial issues that cropped up; I don't think we bugged them all that much, so having the outgoing people stay around for a bit on the portmgr list may be a good policy to have as well. > > On Oct 9, 2009, at 6:09 PM, Daniel J. Luke wrote: > > >It might be a good idea to agree on a term and then also stage > >things so that we don't end up with the possibility of 100% > >turnover each election. > > > >On Oct 9, 2009, at 3:39 PM, Jeremy Lavergne wrote: > >>Also, are we sticking to the same number of people? Good question; we went from three in the past to the current four, which mostly happened due to the four of us being chosen pretty quickly with the changeover. The only disadvantage to an even number is the possibility of a stalemate, though fortunately we haven't seen that. Is there any need for more people, fewer, or is four good? From my point of view, I'd say more is nice to a point since that many more people to respond to various issues, but going too big could risk design-by-committee issues... Bryan [...] > >-- > >Daniel J. Luke > >+========================================================+ > >| *---------------- dluke at geeklair.net ----------------* | > >| *-------------- http://www.geeklair.net -------------* | > >+========================================================+ > >| Opinions expressed are mine and do not necessarily | > >| reflect the opinions of my employer. | > >+========================================================+ From jtomshine at gmail.com Fri Oct 16 05:04:24 2009 From: jtomshine at gmail.com (Jonathan Tomshine) Date: Fri, 16 Oct 2009 05:04:24 -0700 Subject: alternate configuration step with cmake rather than ./configure Message-ID: I'm attempting to make a portfile for an application that uses cmake for its configuration step, as opposed to the standard ./configure. I'm running into a confusing error with regards to my alternate configure{} though. My configure stage is this: configure { exec cmake ${worksrcpath} \ -DWITH_CFITSIO=OFF \ -DWITH_FLI=OFF \ -DCMAKE_INSTALL_PREFIX=${destroot}${prefix} \ -DNOVA_INCLUDE_DIR=${prefix}/include \ -DNOVA_LIBRARIES=${prefix}/lib/libnova.a } (adding the ${worksrcpath} behind cmake shouldn't be necessary, but it delays failure from the configure to the build stage) For whatever reason, my alternate configuration step appears to be running in the directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/openssl (?!?) Based on the macports manual: http://guide.macports.org/#reference.phases , it appears that it should be running in ${worksrcpath}, which it certainly isn't. Since "cd" seems to have been specifically disabled, I'm at a loss as to how to fix this problem. Do I just need to copy all of the resulting configure files to ${worksrcpath} manually? Surely I can't be the first person to use cmake to write a Makefile, so this must have been addressed before... Any advice will be appreciated, -Jon From vince at macports.org Fri Oct 16 05:10:04 2009 From: vince at macports.org (vincent habchi) Date: Fri, 16 Oct 2009 14:10:04 +0200 Subject: alternate configuration step with cmake rather than ./configure In-Reply-To: References: Message-ID: <282D6D1E-1684-47FB-BB53-DFCE9828263A@macports.org> Jonathan, > I'm attempting to make a portfile for an application that uses cmake > for its configuration step, as opposed to the standard ./configure. > I'm running into a confusing error with regards to my alternate > configure{} though. My configure stage is this: > > configure { > exec cmake ${worksrcpath} \ > -DWITH_CFITSIO=OFF \ > -DWITH_FLI=OFF \ > -DCMAKE_INSTALL_PREFIX=${destroot}${prefix} \ > -DNOVA_INCLUDE_DIR=${prefix}/include \ > -DNOVA_LIBRARIES=${prefix}/lib/libnova.a > } > > (adding the ${worksrcpath} behind cmake shouldn't be necessary, but it > delays failure from the configure to the build stage) > > For whatever reason, my alternate configuration step appears to be > running in the directory: > > /opt/local/var/macports/sources/rsync.macports.org/release/ports/ > devel/openssl > (?!?) You can set configure.dir explicitly or try an alternative solution like the one I adopted in the gis/qgis port. Cheers, Vincent From jeremy at lavergne.gotdns.org Fri Oct 16 05:17:21 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 16 Oct 2009 08:17:21 -0400 Subject: alternate configuration step with cmake rather than ./configure In-Reply-To: <282D6D1E-1684-47FB-BB53-DFCE9828263A@macports.org> References: <282D6D1E-1684-47FB-BB53-DFCE9828263A@macports.org> Message-ID: >> I'm attempting to make a portfile for an application that uses cmake >> for its configuration step, as opposed to the standard ./configure. >> I'm running into a confusing error with regards to my alternate >> configure{} though. My configure stage is this: >> >> configure { >> exec cmake ${worksrcpath} \ >> -DWITH_CFITSIO=OFF \ >> -DWITH_FLI=OFF \ >> -DCMAKE_INSTALL_PREFIX=${destroot}${prefix} \ >> -DNOVA_INCLUDE_DIR=${prefix}/include \ >> -DNOVA_LIBRARIES=${prefix}/lib/libnova.a >> } >> >> (adding the ${worksrcpath} behind cmake shouldn't be necessary, but >> it >> delays failure from the configure to the build stage) >> >> For whatever reason, my alternate configuration step appears to be >> running in the directory: >> >> /opt/local/var/macports/sources/rsync.macports.org/release/ports/ >> devel/openssl >> (?!?) > > You can set configure.dir explicitly or try an alternative solution > like the one I adopted in the gis/qgis port. You might also consider the cmake PortGroup. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4024 bytes Desc: not available URL: From ryandesign at macports.org Fri Oct 16 07:29:16 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 16 Oct 2009 09:29:16 -0500 Subject: alternate configuration step with cmake rather than ./configure In-Reply-To: References: Message-ID: On Oct 16, 2009, at 07:04, Jonathan Tomshine wrote: > I'm attempting to make a portfile for an application that uses cmake > for its configuration step, as opposed to the standard ./configure. > I'm running into a confusing error with regards to my alternate > configure{} though. My configure stage is this: > > configure { > exec cmake ${worksrcpath} \ > -DWITH_CFITSIO=OFF \ > -DWITH_FLI=OFF \ > -DCMAKE_INSTALL_PREFIX=${destroot}${prefix} \ > -DNOVA_INCLUDE_DIR=${prefix}/include \ > -DNOVA_LIBRARIES=${prefix}/lib/libnova.a > } > > (adding the ${worksrcpath} behind cmake shouldn't be necessary, but it > delays failure from the configure to the build stage) > > For whatever reason, my alternate configuration step appears to be > running in the directory: > > /opt/local/var/macports/sources/rsync.macports.org/release/ports/ > devel/openssl > (?!?) > > Based on the macports manual: > http://guide.macports.org/#reference.phases , it appears that it > should be running in ${worksrcpath}, which it certainly isn't. Since > "cd" seems to have been specifically disabled, I'm at a loss as to how > to fix this problem. Do I just need to copy all of the resulting > configure files to ${worksrcpath} manually? Surely I can't be the > first person to use cmake to write a Makefile, so this must have been > addressed before... MacPorts does not guarantee what the current working directory will be when you "system" or "exec" any commands. You must go there yourself. For "exec" this isn't so easy, so most ports use "system", as in: system "cd ${worksrcpath} && cmake ........" However, please use the cmake portgroup instead of reinventing this particular wheel. :) From jtomshine at gmail.com Fri Oct 16 07:49:30 2009 From: jtomshine at gmail.com (Jonathan Tomshine) Date: Fri, 16 Oct 2009 07:49:30 -0700 Subject: alternate configuration step with cmake rather than ./configure In-Reply-To: References: Message-ID: Thanks to all who replied. I knew that this must have been addressed before, and you pointed me in the right direction. The port now configures, builds, and dest-roots okay. It is still having some strange problem activating, but that's a different issue that I'll deal with later. -Jon On Fri, Oct 16, 2009 at 5:04 AM, Jonathan Tomshine wrote: > I'm attempting to make a portfile for an application that uses cmake > for its configuration step, as opposed to the standard ./configure. > I'm running into a confusing error with regards to my alternate > configure{} though. ?My configure stage is this: > > configure { > ? ?exec cmake ${worksrcpath} \ > ? ?-DWITH_CFITSIO=OFF \ > ? ?-DWITH_FLI=OFF \ > ? ?-DCMAKE_INSTALL_PREFIX=${destroot}${prefix} \ > ? ?-DNOVA_INCLUDE_DIR=${prefix}/include \ > ? ?-DNOVA_LIBRARIES=${prefix}/lib/libnova.a > } > > (adding the ${worksrcpath} behind cmake shouldn't be necessary, but it > delays failure from the configure to the build stage) > > For whatever reason, my alternate configuration step appears to be > running in the directory: > > /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/openssl > (?!?) > > Based on the macports manual: > http://guide.macports.org/#reference.phases , it appears that it > should be running in ${worksrcpath}, which it certainly isn't. ?Since > "cd" seems to have been specifically disabled, I'm at a loss as to how > to fix this problem. ?Do I just need to copy all of the resulting > configure files to ${worksrcpath} manually? ?Surely I can't be the > first person to use cmake to write a Makefile, so this must have been > addressed before... > > Any advice will be appreciated, > -Jon > -- Jonathan Tomshine, PhD Postdoctoral Scientist University of California, San Francisco Genentech Hall 600 16th St. San Francisco, CA 94158-2140 jtomshine at gmail.com From talklists at newgeo.com Fri Oct 16 12:19:09 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 16 Oct 2009 12:19:09 -0700 Subject: pureftpd creates files outside of prefix In-Reply-To: <77E01C49-A01D-4674-AA2A-B62218E128F2@macports.org> References: <6B369ABA-540F-4CAD-94B2-E20EA397BD7A@newgeo.com> <4C496A26-32A0-4885-97F5-8EE241D49ED5@macports.org> <0E2D38F4-1B9D-4891-AD88-8178225BFA00@newgeo.com> <77E01C49-A01D-4674-AA2A-B62218E128F2@macports.org> Message-ID: <0ACCBD1D-DA92-4B40-A979-97E493751AC5@newgeo.com> Well, the good news is, I managed to get developer contact, and am working with him to get configure options in which the paths can accept a prefix at configure time. The also good news is the next release, do out very soon, should have these changes. Pureftpd starts with inetd in the launchd item I made, which the developer told me is a poor way to do so, and will be dropped from support. I did not want to distract from the other issues I brought up. Can anyone speculate as to why inetd would be a bad way to start any server, ftp or otherwise? -- Scott * If you contact me off list replace talklists@ with scott@ * On Oct 10, 2009, at 1:47 AM, Ryan Schmidt wrote: > My reviews of portfiles often just consist of verifying they > install, do not produce mtree warnings, do not link with libraries > they don't declare dependencies on, that they're > UsingTheRightCompiler, that livecheck works, that the universal > variant works, etc. Usually just a subset of those unless I'm > feeling particularly ambitious. But I seldom check that the software > being ported works properly, because I would seldom have the > expertise needed to do so. For example, I haven't ever set up an ftp > server, so trying to figure out how to set up pureftpd and verify it > works correctly would be much more effort than I would be willing to > put in. Since you're interested in the software and presumably use > it, you may be the best one to verify it works. And of course, if we > commit it and it's broken in some way, I'm sure other users will > notice and submit bug reports, and we can fix it then. This is not > to say we shouldn't carefully test things before committing, but > there's a limit to how thorough we need to be. :) From jtomshine at gmail.com Fri Oct 16 15:15:06 2009 From: jtomshine at gmail.com (Jonathan Tomshine) Date: Fri, 16 Oct 2009 15:15:06 -0700 Subject: new port with cmake: destroots okay, activation doesn't seem to work... Message-ID: I've been encountering some odd behavior when attempting to write a new port (only my 2nd portfile, so I'm quite new to this). I'm attaching the current portfile for completeness. While the port appears to build & install everything into destroot okay, it only installs and activates some symbolic links that are generated by the application's installer (and they aren't correct links really, but that's a separate issue) -- it doesn't install or activate any of the actual binary files that it built. For instance, here's the destroot directory directly after a "port install" (note the symlinks): udp009069uds:bin jshine$ pwd /Users/jshine/Documents/hobbies/astro/astro_software/indi_port/work/destroot/opt/local/bin udp009069uds:bin jshine$ ls -l total 2128 -rwxr-xr-x 2 root admin 82936 Oct 16 15:01 indi_celestron_gps -rwxr-xr-x 2 root admin 55072 Oct 16 15:01 indi_eval -rwxr-xr-x 2 root admin 50144 Oct 16 15:01 indi_getprop -rwxr-xr-x 2 root admin 73684 Oct 16 15:01 indi_intelliscope lrwxr-xr-x 1 root admin 138 Oct 16 15:02 indi_lx200_16 -> /opt/local/var/macports/build/_Users_jshine_Documents_hobbies_astro_astro_software_indi_port/work/destroot/opt/local/bin/indi_lx200generic lrwxr-xr-x 1 root admin 138 Oct 16 15:02 indi_lx200ap -> /opt/local/var/macports/build/_Users_jshine_Documents_hobbies_astro_astro_software_indi_port/work/destroot/opt/local/bin/indi_lx200generic lrwxr-xr-x 1 root admin 138 Oct 16 15:02 indi_lx200autostar -> /opt/local/var/macports/build/_Users_jshine_Documents_hobbies_astro_astro_software_indi_port/work/destroot/opt/local/bin/indi_lx200generic -rwxr-xr-x 2 root admin 96600 Oct 16 15:02 indi_lx200basic lrwxr-xr-x 1 root admin 138 Oct 16 15:02 indi_lx200classic -> /opt/local/var/macports/build/_Users_jshine_Documents_hobbies_astro_astro_software_indi_port/work/destroot/opt/local/bin/indi_lx200generic -rwxr-xr-x 2 root admin 196204 Oct 16 15:02 indi_lx200generic lrwxr-xr-x 1 root admin 138 Oct 16 15:02 indi_lx200gps -> /opt/local/var/macports/build/_Users_jshine_Documents_hobbies_astro_astro_software_indi_port/work/destroot/opt/local/bin/indi_lx200generic -rwxr-xr-x 2 root admin 87456 Oct 16 15:02 indi_orion_atlas -rwxr-xr-x 2 root admin 81712 Oct 16 15:02 indi_robofocus -rwxr-xr-x 2 root admin 45904 Oct 16 15:02 indi_setprop -rwxr-xr-x 2 root admin 73684 Oct 16 15:02 indi_skycommander -rwxr-xr-x 2 root admin 96088 Oct 16 15:02 indi_temma -rwxr-xr-x 2 root admin 64456 Oct 16 15:02 indi_trutech_wheel -rwxr-xr-x 2 root admin 44804 Oct 16 15:02 indiserver udp009069uds:bin jshine$ ---------- ...and here's the installation directory... ---------- udp009069uds:bin jshine$ pwd /opt/local/var/macports/software/indi/0.6_0/opt/local/bin udp009069uds:bin jshine$ ls -l total 40 lrwxr-xr-x 1 root admin 138 Oct 16 15:02 indi_lx200_16 -> /opt/local/var/macports/build/_Users_jshine_Documents_hobbies_astro_astro_software_indi_port/work/destroot/opt/local/bin/indi_lx200generic lrwxr-xr-x 1 root admin 138 Oct 16 15:02 indi_lx200ap -> /opt/local/var/macports/build/_Users_jshine_Documents_hobbies_astro_astro_software_indi_port/work/destroot/opt/local/bin/indi_lx200generic lrwxr-xr-x 1 root admin 138 Oct 16 15:02 indi_lx200autostar -> /opt/local/var/macports/build/_Users_jshine_Documents_hobbies_astro_astro_software_indi_port/work/destroot/opt/local/bin/indi_lx200generic lrwxr-xr-x 1 root admin 138 Oct 16 15:02 indi_lx200classic -> /opt/local/var/macports/build/_Users_jshine_Documents_hobbies_astro_astro_software_indi_port/work/destroot/opt/local/bin/indi_lx200generic lrwxr-xr-x 1 root admin 138 Oct 16 15:02 indi_lx200gps -> /opt/local/var/macports/build/_Users_jshine_Documents_hobbies_astro_astro_software_indi_port/work/destroot/opt/local/bin/indi_lx200generic udp009069uds:bin jshine$ ---------- ...now only the 5 symlinks remain. The actual /opt/local/bin directory looks similar. What's up? I've been scratching my head over this one, and just can't figure it out. Any suggestions would be greatly appreciated! Thanks, Jon From jtomshine at gmail.com Fri Oct 16 15:16:24 2009 From: jtomshine at gmail.com (Jonathan Tomshine) Date: Fri, 16 Oct 2009 15:16:24 -0700 Subject: new port with cmake: destroots okay, activation doesn't seem to work... In-Reply-To: References: Message-ID: P.S. -- Here's the portfile that generated that code -- I forgot to attach it on the prior post. On Fri, Oct 16, 2009 at 3:15 PM, Jonathan Tomshine wrote: > I've been encountering some odd behavior when attempting to write a > new port (only my 2nd portfile, so I'm quite new to this). ?I'm > attaching the current portfile for completeness. ?While the port > appears to build & install everything into destroot okay, it only > installs and activates some symbolic links that are generated by the > application's installer (and they aren't correct links really, but > that's a separate issue) -- it doesn't install or activate any of the > actual binary files that it built. > > For instance, here's the destroot directory directly after a "port > install" (note the symlinks): > > udp009069uds:bin jshine$ pwd > /Users/jshine/Documents/hobbies/astro/astro_software/indi_port/work/destroot/opt/local/bin > udp009069uds:bin jshine$ ls -l > total 2128 > -rwxr-xr-x ?2 root ?admin ? 82936 Oct 16 15:01 indi_celestron_gps > -rwxr-xr-x ?2 root ?admin ? 55072 Oct 16 15:01 indi_eval > -rwxr-xr-x ?2 root ?admin ? 50144 Oct 16 15:01 indi_getprop > -rwxr-xr-x ?2 root ?admin ? 73684 Oct 16 15:01 indi_intelliscope > lrwxr-xr-x ?1 root ?admin ? ? 138 Oct 16 15:02 indi_lx200_16 -> > /opt/local/var/macports/build/_Users_jshine_Documents_hobbies_astro_astro_software_indi_port/work/destroot/opt/local/bin/indi_lx200generic > lrwxr-xr-x ?1 root ?admin ? ? 138 Oct 16 15:02 indi_lx200ap -> > /opt/local/var/macports/build/_Users_jshine_Documents_hobbies_astro_astro_software_indi_port/work/destroot/opt/local/bin/indi_lx200generic > lrwxr-xr-x ?1 root ?admin ? ? 138 Oct 16 15:02 indi_lx200autostar -> > /opt/local/var/macports/build/_Users_jshine_Documents_hobbies_astro_astro_software_indi_port/work/destroot/opt/local/bin/indi_lx200generic > -rwxr-xr-x ?2 root ?admin ? 96600 Oct 16 15:02 indi_lx200basic > lrwxr-xr-x ?1 root ?admin ? ? 138 Oct 16 15:02 indi_lx200classic -> > /opt/local/var/macports/build/_Users_jshine_Documents_hobbies_astro_astro_software_indi_port/work/destroot/opt/local/bin/indi_lx200generic > -rwxr-xr-x ?2 root ?admin ?196204 Oct 16 15:02 indi_lx200generic > lrwxr-xr-x ?1 root ?admin ? ? 138 Oct 16 15:02 indi_lx200gps -> > /opt/local/var/macports/build/_Users_jshine_Documents_hobbies_astro_astro_software_indi_port/work/destroot/opt/local/bin/indi_lx200generic > -rwxr-xr-x ?2 root ?admin ? 87456 Oct 16 15:02 indi_orion_atlas > -rwxr-xr-x ?2 root ?admin ? 81712 Oct 16 15:02 indi_robofocus > -rwxr-xr-x ?2 root ?admin ? 45904 Oct 16 15:02 indi_setprop > -rwxr-xr-x ?2 root ?admin ? 73684 Oct 16 15:02 indi_skycommander > -rwxr-xr-x ?2 root ?admin ? 96088 Oct 16 15:02 indi_temma > -rwxr-xr-x ?2 root ?admin ? 64456 Oct 16 15:02 indi_trutech_wheel > -rwxr-xr-x ?2 root ?admin ? 44804 Oct 16 15:02 indiserver > udp009069uds:bin jshine$ > > > ---------- > ...and here's the installation directory... > ---------- > > > udp009069uds:bin jshine$ pwd > /opt/local/var/macports/software/indi/0.6_0/opt/local/bin > udp009069uds:bin jshine$ ls -l > total 40 > lrwxr-xr-x ?1 root ?admin ?138 Oct 16 15:02 indi_lx200_16 -> > /opt/local/var/macports/build/_Users_jshine_Documents_hobbies_astro_astro_software_indi_port/work/destroot/opt/local/bin/indi_lx200generic > lrwxr-xr-x ?1 root ?admin ?138 Oct 16 15:02 indi_lx200ap -> > /opt/local/var/macports/build/_Users_jshine_Documents_hobbies_astro_astro_software_indi_port/work/destroot/opt/local/bin/indi_lx200generic > lrwxr-xr-x ?1 root ?admin ?138 Oct 16 15:02 indi_lx200autostar -> > /opt/local/var/macports/build/_Users_jshine_Documents_hobbies_astro_astro_software_indi_port/work/destroot/opt/local/bin/indi_lx200generic > lrwxr-xr-x ?1 root ?admin ?138 Oct 16 15:02 indi_lx200classic -> > /opt/local/var/macports/build/_Users_jshine_Documents_hobbies_astro_astro_software_indi_port/work/destroot/opt/local/bin/indi_lx200generic > lrwxr-xr-x ?1 root ?admin ?138 Oct 16 15:02 indi_lx200gps -> > /opt/local/var/macports/build/_Users_jshine_Documents_hobbies_astro_astro_software_indi_port/work/destroot/opt/local/bin/indi_lx200generic > udp009069uds:bin jshine$ > > ---------- > ...now only the 5 symlinks remain. ?The actual /opt/local/bin > directory looks similar. ?What's up? ?I've been scratching my head > over this one, and just can't figure it out. ?Any suggestions would be > greatly appreciated! > > > Thanks, > Jon > -- Jonathan Tomshine, PhD Postdoctoral Scientist University of California, San Francisco Genentech Hall 600 16th St. San Francisco, CA 94158-2140 jtomshine at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: Portfile Type: application/octet-stream Size: 2592 bytes Desc: not available URL: From jtomshine at gmail.com Fri Oct 16 15:38:45 2009 From: jtomshine at gmail.com (Jonathan Tomshine) Date: Fri, 16 Oct 2009 15:38:45 -0700 Subject: new port with cmake: destroots okay, activation doesn't seem to work... In-Reply-To: References: Message-ID: Actually, I saw my typo & now this is working. Please ignore my prior post. :-) -Jon From howarth at bromo.med.uc.edu Fri Oct 16 16:24:55 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Fri, 16 Oct 2009 19:24:55 -0400 Subject: python.bin oddity? Message-ID: <20091016232455.GA28481@bromo.med.uc.edu> While testing the proposed apbs packaging with the PortGroup python26 option, I am finding that the build fails with... DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/_Users_howarth_ports_science_apbs/work/apbs-1.1.0-source" && /opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 setup.py --no-user-cfg build' /opt/local/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python: can't open file 'setup.py': [Errno 2] No such file or directory Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_Users_howarth_ports_science_apbs/work/apbs-1.1.0-source" && /opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 setup.py --no-user-cfg build " returned error 2 Command output: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python: can't open file 'setup.py': [Errno 2] No such file or directory Why exactly is python.bin resolving to /opt/local/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python instead of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/python or /opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6? Jack From raimue at macports.org Sat Oct 17 02:51:16 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Sat, 17 Oct 2009 11:51:16 +0200 Subject: python.bin oddity? In-Reply-To: <20091016232455.GA28481@bromo.med.uc.edu> References: <20091016232455.GA28481@bromo.med.uc.edu> Message-ID: <4AD99394.8080503@macports.org> On 2009-10-17 01:24 , Jack Howarth wrote: > Why exactly is python.bin resolving to /opt/local/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/Contents/MacOS/Python > instead of /opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/python or > /opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6? Because that is the location where python2.6 is installed with a framework build. If you expected /opt/local/bin/python2.6 that's just a symlink. Rainer From ryandesign at macports.org Sat Oct 17 08:27:19 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 17 Oct 2009 10:27:19 -0500 Subject: [59578] trunk/dports/python/py-vobject In-Reply-To: <20091017134122.CE5092A40E95@beta.macosforge.org> References: <20091017134122.CE5092A40E95@beta.macosforge.org> Message-ID: On Oct 17, 2009, at 08:41, lightnin at macports.org wrote: > Revision: 59578 > http://trac.macports.org/changeset/59578 > Author: lightnin at macports.org > Date: 2009-10-17 06:41:18 -0700 (Sat, 17 Oct 2009) > Log Message: > ----------- > Taking over maintainer role for py-vobject with Eric's permission. > Updating port to current version 0.8.1c instead of 0.4.1 In the future, please consider making whitespace-only changes separately from functional changes, in a separate commit. This will make it much easier to review your diffs. Thanks. > Modified Paths: > -------------- > trunk/dports/python/py-vobject/Portfile > > Removed Paths: > ------------- > trunk/dports/python/py-vobject/files/ > > Modified: trunk/dports/python/py-vobject/Portfile > =================================================================== > --- trunk/dports/python/py-vobject/Portfile 2009-10-17 09:54:37 UTC > (rev 59577) > +++ trunk/dports/python/py-vobject/Portfile 2009-10-17 13:41:18 UTC > (rev 59578) > @@ -1,36 +1,32 @@ > +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: > nil; c-basic-offset: 4 -*- > vim:fenc=utf-8:filetype=tcl:et:sw=4:ts=4:sts=4 > # $Id$ > > -PortSystem 1.0 > -PortGroup python24 1.0 > +PortSystem 1.0 > +PortGroup python24 1.0 > > -name py-vobject > -version 0.4.1 > -revision 0 > -categories python > -platforms darwin > -maintainers darkart.com:opendarwin.org > -description Python package for parsing and generating vCard and > vCalendar files. > -long_description vobject is intended to be a full featured Python > package for parsing \ > - and generating vCard and vCalendar files. It is being developed > in \ > - concert with the Open Source Application Foundation's Chandler > project. > +name py-vobject > +version 0.8.1c > +categories python > +platforms darwin > +maintainers lightnin > +description Python package for parsing and generating vCard > and \ > + vCalendar files. > +long_description vObject is intended to be a full featured > Python package \ > + for parsing and generating vCard and vCalendar > files. It \ > + is being developed in concert with the Open > Source \ > + Application Foundation's Chandler project. > > -homepage http://vobject.skyhouseconsulting.com/ > -master_sites http://vobject.skyhouseconsulting.com/ > -distname vobject-${version} > -checksums md5 b12fbec4abd87c826b4627364bd1474d > +homepage http://vobject.skyhouseconsulting.com/ > +master_sites http://vobject.skyhouseconsulting.com/ > +distname vobject-${version} > +checksums md5 c9686dd74d39fdae140890d9c694c076 \ > + sha1 97f1daf9d813a2b2128c2d39ca52bbbcc152fdfd \ > + rmd160 ca1b1f207b6b7d4418a401938656627e6404aacf > > -depends_lib port:py-dateutil \ > - port:py-setuptools > +depends_lib port:py-dateutil \ > + port:py-setuptools > > -test.run yes > -test.cmd ${python.bin} test.py > +test.run yes > +test.cmd ${python.bin} test_vobject.py > test.target > -test.env PYTHONPATH=${worksrcpath}/build/lib > - > -patchfiles patch-src-vobject-base.py \ > - patch-src-vobject-icalendar.py > - > -## post-destroot { > -## xinstall -m 644 -W ${worksrcpath} LICENSE README \ > -## ${destroot}${prefix}/share/doc/${name} > -## } > +test.env PYTHONPATH=${worksrcpath}/build/lib From ryandesign at macports.org Sat Oct 17 09:49:25 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 17 Oct 2009 11:49:25 -0500 Subject: Installing additional documentation files Message-ID: <7ABB7A9D-75CC-420C-A6E0-391CD007C7F0@macports.org> I added a portfile recipe for installing additional documentation files: https://trac.macports.org/wiki/PortfileRecipes#doc I recommended that documentation should go in ${prefix}/share/doc/$ {name}. This is where we always used to install additional documentation files. A year or two ago, Anthony started changing things to install those files in ${prefix}/share/doc/${name}-${version} instead, but I didn't really ever understand the reasoning. You can't ever have more than one version of a port active at the same time, so it's not like $ {prefix}/share/doc/${name} can cause a conflict. Does anybody have an objection to returning to the old recommendation? If not, then I would also like to have MacPorts base auto-create $ {prefix}/share/doc/${name} before the destroot phase, so each port doesn't have to "xinstall -d" it manually. MacPorts base already creates ${prefix}/share/${name} automatically so I think this fits. From jeremy at lavergne.gotdns.org Sat Oct 17 10:47:14 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 17 Oct 2009 13:47:14 -0400 Subject: ${prefix}/var/macports/software Message-ID: Question for anyone who happens to know the innards of MacPorts with regards to its software directory: is it suppose to be emptied out when you have uninstalled all ports? This is on a build box for me, and I have archivemode enabled and use `-f uninstall` exclusively for software removal. The software directory is a fat 2.6GB when nothing is installed. Note archives are not contained in the software folder (they're in ../ packages). Does some combination of my settings leave these files in there? Does using -f do this? Does archivemode cause them to be forgotten? Does the combination break the expected behavior? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4024 bytes Desc: not available URL: From mdcrawford at gmail.com Sat Oct 17 11:02:53 2009 From: mdcrawford at gmail.com (Michael Crawford) Date: Sat, 17 Oct 2009 11:02:53 -0700 Subject: Clues for the Clueless? Message-ID: I'd like to take a stab at building Ogg Frog as a MacPort. But I don't have the first clue as to how to create a port file from scratch. Is there a "Getting Started" tutorial somewhere? There are several dependencies, some of which might already be in MacPorts - the various audio codecs, libz, and image format libraries. I will need to make a new portfile for ZooLib, and then one for Ogg Frog itself that pulls all these pieces together. Given all those dependencies, my final port file may need to be rather advanced. I would also like to support it being built as both a Mac OS X Carbon application as well as an X11 application. ZooLib can be built both ways on the Mac, so I'm sure I could do so with Ogg Frog. (ZooLib is a C++ cross-platform application framework: http://www.zoolib.org/ It has the MIT License.) Ogg Frog is not yet released publicly, but when it is it will start out as an audio player, with new features added with each release until it could (hopefully) compete with iTunes, WinAmp and Windows Media Player. It will be licensed under the GPL. http://www.oggfrog.com/free-music-software/ Thanks! Mike -- Michael David Crawford mdcrawford at gmail dot com GoingWare's Bag of Programming Tricks http://www.goingware.com/tips/ From jeremy at lavergne.gotdns.org Sat Oct 17 11:04:14 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 17 Oct 2009 14:04:14 -0400 Subject: Clues for the Clueless? In-Reply-To: References: Message-ID: <7575C4B7-98F2-41CD-93A8-B4B6B3F21637@lavergne.gotdns.org> guide.macports.org On Oct 17, 2009, at 2:02 PM, Michael Crawford wrote: > I'd like to take a stab at building Ogg Frog as a MacPort. But I > don't have the first clue as to how to create a port file from > scratch. Is there a "Getting Started" tutorial somewhere? > > There are several dependencies, some of which might already be in > MacPorts - the various audio codecs, libz, and image format libraries. > I will need to make a new portfile for ZooLib, and then one for Ogg > Frog itself that pulls all these pieces together. > > Given all those dependencies, my final port file may need to be rather > advanced. I would also like to support it being built as both a Mac > OS X Carbon application as well as an X11 application. ZooLib can be > built both ways on the Mac, so I'm sure I could do so with Ogg Frog. > > (ZooLib is a C++ cross-platform application framework: > http://www.zoolib.org/ It has the MIT License.) > > Ogg Frog is not yet released publicly, but when it is it will start > out as an audio player, with new features added with each release > until it could (hopefully) compete with iTunes, WinAmp and Windows > Media Player. It will be licensed under the GPL. > > http://www.oggfrog.com/free-music-software/ > > Thanks! > > Mike > -- > Michael David Crawford > mdcrawford at gmail dot com > > GoingWare's Bag of Programming Tricks > http://www.goingware.com/tips/ > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4024 bytes Desc: not available URL: From jeremy at lavergne.gotdns.org Sat Oct 17 11:05:14 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sat, 17 Oct 2009 14:05:14 -0400 Subject: Clues for the Clueless? In-Reply-To: References: Message-ID: <8AF13EF2-79AA-464E-AA9B-BA442D3F713C@lavergne.gotdns.org> Incidentally, Carbon doesn't exist in Snow Leopard (10.6). You might be better off just going the X11 away until they update their code to Cocoa. On Oct 17, 2009, at 2:02 PM, Michael Crawford wrote: > Given all those dependencies, my final port file may need to be rather > advanced. I would also like to support it being built as both a Mac > OS X Carbon application as well as an X11 application. ZooLib can be > built both ways on the Mac, so I'm sure I could do so with Ogg Frog. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4024 bytes Desc: not available URL: From jmr at macports.org Sat Oct 17 11:30:51 2009 From: jmr at macports.org (Joshua Root) Date: Sun, 18 Oct 2009 05:30:51 +1100 Subject: Clues for the Clueless? In-Reply-To: <8AF13EF2-79AA-464E-AA9B-BA442D3F713C@lavergne.gotdns.org> References: <8AF13EF2-79AA-464E-AA9B-BA442D3F713C@lavergne.gotdns.org> Message-ID: <4ADA0D5B.8090805@macports.org> On 2009-10-18 05:05, Jeremy Lavergne wrote: > Incidentally, Carbon doesn't exist in Snow Leopard (10.6). Not so, it's still all there in 32-bit mode, and in fact it still exists in 64-bit mode, there's just a lot less of it compared to the 32-bit version (all the bits that were deprecated as of Tiger are gone). The situation is actually effectively the same as on Leopard, except that 64-bit is now the default. - Josh From mdcrawford at gmail.com Sat Oct 17 11:47:54 2009 From: mdcrawford at gmail.com (Michael Crawford) Date: Sat, 17 Oct 2009 11:47:54 -0700 Subject: Clues for the Clueless? In-Reply-To: <4ADA0D5B.8090805@macports.org> References: <8AF13EF2-79AA-464E-AA9B-BA442D3F713C@lavergne.gotdns.org> <4ADA0D5B.8090805@macports.org> Message-ID: On 10/17/09, Joshua Root wrote: > On 2009-10-18 05:05, Jeremy Lavergne wrote: >> Incidentally, Carbon doesn't exist in Snow Leopard (10.6). > > Not so, it's still all there in 32-bit mode, and in fact it still exists > in 64-bit mode, there's just a lot less of it compared to the 32-bit > version (all the bits that were deprecated as of Tiger are gone). The > situation is actually effectively the same as on Leopard, except that > 64-bit is now the default. One of the benefits of a cross-platform application like ZooLib is that the OS-specific layer can be reimplemented when the OS vendor removes or screws up APIs that you need. Work has been going on to add a Cocoa layer to ZooLib, in addition to the Carbon layer. That would enable 64-bit ZooLib apps with little or no change to the client code. It would also enable ZooLib apps to run on the iPhone, with client code written in pure C++. One could mix Objective-C into the client code, but one wouldn't have to. ZooLib's principle author wrote ZooLib at first to insulate himself from what he calls "Apple's API du Jour". Does anyone here remember Bedrock? It was Bedrock that inspired ZooLib. Mike -- Michael David Crawford mdcrawford at gmail dot com GoingWare's Bag of Programming Tricks http://www.goingware.com/tips/ From howarth at bromo.med.uc.edu Sat Oct 17 15:55:06 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sat, 17 Oct 2009 18:55:06 -0400 Subject: gcc4x packages shouldn't build in source directory Message-ID: <20091017225506.GA4134@bromo.med.uc.edu> I just noticed that MacPorts is building the FSF gcc releases within the source tree. The upstream FSF gcc developers frown upon this as poor technique. All of the gcc4X packages should be creating a separate build directory, eg darwin_objdir, outside of the source tree and then executing both configure and make from within this build directory. Jack From toby at macports.org Sat Oct 17 16:08:17 2009 From: toby at macports.org (Toby Peterson) Date: Sat, 17 Oct 2009 16:08:17 -0700 Subject: gcc4x packages shouldn't build in source directory In-Reply-To: <20091017225506.GA4134@bromo.med.uc.edu> References: <20091017225506.GA4134@bromo.med.uc.edu> Message-ID: <74c219d30910171608n7d69f1cbt811eade02b391638@mail.gmail.com> On Sat, Oct 17, 2009 at 15:55, Jack Howarth wrote: > ? I just noticed that MacPorts is building the FSF gcc > releases within the source tree. The upstream FSF gcc > developers frown upon this as poor technique. All of the > gcc4X packages should be creating a separate build directory, > eg darwin_objdir, outside of the source tree and then > executing both configure and make from within this > build directory. If only we had some sort of system that allowed people to report these types of issues. - Toby From talklists at newgeo.com Sat Oct 17 16:20:27 2009 From: talklists at newgeo.com (Scott Haneda) Date: Sat, 17 Oct 2009 16:20:27 -0700 Subject: Clues for the Clueless? In-Reply-To: References: Message-ID: <4687AE0F-E2C2-418B-9254-50E9A1218A3B@newgeo.com> On Oct 17, 2009, at 11:02 AM, Michael Crawford wrote: > I'd like to take a stab at building Ogg Frog as a MacPort. But I > don't have the first clue as to how to create a port file from > scratch. Is there a "Getting Started" tutorial somewhere? I was very much in the same boat as you. I needed a software, the port for it was old and outdated, to the point it needed to be redone, so I decided to give it a shot. > There are several dependencies, some of which might already be in > MacPorts - the various audio codecs, libz, and image format libraries. > I will need to make a new portfile for ZooLib, and then one for Ogg > Frog itself that pulls all these pieces together. > > Given all those dependencies, my final port file may need to be rather > advanced. I would also like to support it being built as both a Mac > OS X Carbon application as well as an X11 application. ZooLib can be > built both ways on the Mac, so I'm sure I could do so with Ogg Frog. I few people have said to me, I probably did not chose the best port to learn from. I suggest you not get into that same situation, as the alternative is 20 minutes to get up to speed, versus the method I chose, which was months to get up to speed in my spare time. I also spend a lot of time on the list asking questions. Questions were graciously answered, as usual, however, I could have done better to start simpler, and then the more complex port would have made more sense. Here is my suggestion, if I had to do it all over again. Set up your local port repo http://guide.macports.org/#development.local-repositories Learn that enough that you understand what it is, and how it works with regards to it's impact on the order in which ports take precedence against a local repo. Hit up CPAN and see if you can find a perl module that interests you in some way, or that you think would be of value to the community. Also look through the bug tracker, and see if there are any perl module requests. With a known perl module in mind, go copy an existing perl module portfile into your local repo, edit it, and see if you can get it to work. At this point, you should have made your first portfile. Look back to CPAN, or the docs of that module, to see if there are any unit tests you can run. Run what tests you can to make sure your module is working. Post it to trac so you can learn the procedure for submitting portfiles. This is all pretty good, as it is probably the simplest way to get into a result of making a working portfile, helping out the community, and learning the process. With that basic one out of the way, I would look to an interim port file. Something that compiles, something that has some options and perhaps some config files. Ideally, something you need or are curious about, that you know works on the Mac, but has never been added to MacPorts. See what you can do to get that up and running. This will teach you about the different phases of a portfile, something that most of the perl modules need not know. From there, you should have a basic enough grasp on how things work, that while you will probably struggle as I did with more complex ports, you will at least know the correct questions to ask. Hope these suggestions help, and are not too far off the mark from what others would agree with. -- Scott * If you contact me off list replace talklists@ with scott@ * From jameskyle at macports.org Sat Oct 17 17:42:58 2009 From: jameskyle at macports.org (James Kyle) Date: Sat, 17 Oct 2009 17:42:58 -0700 Subject: py26-numpy, py26-scipy, and macports atlas/lapack/blas In-Reply-To: References: <680FC860-70E1-4E5F-8F6A-D4EBF4E25FA5@macports.org> <20091003050121.GA14320@bromo.med.uc.edu> <20091004221408.GA20042@bromo.med.uc.edu> <2BCA3646-61D4-4D6A-8DB3-C5988A7971FD@macports.org> <20091005011019.GA20946@bromo.med.uc.edu> <39200630-59A3-4054-B088-E0D7F3C5754F@macports.org> <20091005131050.GB25614@bromo.med.uc.edu> Message-ID: I'm going ahead with the changes. They should be live in an hour. -james On Oct 5, 2009, at 6:10 AM, Jack Howarth wrote: > On Sun, Oct 04, 2009 at 09:57:25PM -0500, Ryan Schmidt wrote: >> On Oct 4, 2009, at 20:10, Jack Howarth wrote: >> >>> On Sun, Oct 04, 2009 at 07:50:16PM -0500, Ryan Schmidt wrote: >>> >>>> On Oct 4, 2009, at 17:46, Ryan Schmidt wrote: >>>> >>>>> Last I checked gcc42 still wouldn't build, but perhaps r57804 >>>>> fixed >>>>> that. I will try again now. >>>> >>>> Ok, gcc42 still doesn't build for me and at least one other >>>> person on >>>> Snow Leopard; see: >>>> >>>> http://trac.macports.org/ticket/21665 >>> >>> It shouldn't come as a surprise as the patches I submitted for >>> FSF gcc only went into gcc trunk for gcc 4.4 and later... >>> >>> http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00333.html >>> http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00428.html >>> http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00811.html >>> http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01515.html >>> http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01532.html >>> http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00054.html >>> http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00177.html >> >> I suggested in my previous message that perhaps your patches had not >> been used by MacPorts, since you already said your patches do not >> work >> for gcc43, yet gcc43 was modified to work on Snow Leopard. >> > > I didn't say that gcc 4.2 couldn't be made to work but that > there wasn't much point of doing so (outside of pdftk which > is broken because it incorrectly mixes c++ and java exceptions > which is no longer permitted in FSF gcc). >> >>> Considering that gcc 4.2.x is currently depreciated and >>> unmaintained by upstream, it is rather pointless to keep >>> it when gcc44 works as well across all architectures. >>> The only reason Apple is stuck at 4.2.1 is because of >>> the GPLv3 licensing issues. >> >> My motivation for gcc42 at this moment is pdftk which does not >> compile >> with greater than gcc42. >> >> There are some patches for pdftk from other distributions, though, of >> which I have just been made aware, which are supposed to help with >> this, >> which I will attempt to look into and incorporate. >> >> http://trac.macports.org/ticket/15420 >> > > Yes, the Gentoo patches are more promising than what Fedora uses > (which > requires an openjdk package). > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From talklists at newgeo.com Sun Oct 18 00:05:19 2009 From: talklists at newgeo.com (Scott Haneda) Date: Sun, 18 Oct 2009 00:05:19 -0700 Subject: caldav server Message-ID: <7D6EBCB9-F9FA-4B17-973D-D7859C70CDCE@newgeo.com> Off topic, but I am not sure where else to go. http://trac.calendarserver.org/ seems to have languished. Is this no longer a workable project? I need calendar sharing on Mac OS X. I know it is built in within OS X Server. What is my best route? Looking at things like BusySync, which look great, but to share a calendar with my G/F seems silly to drop any money on, let alone install a full blown OS X Server to do so. -- Scott * If you contact me off list replace talklists@ with scott@ * From jeremy at lavergne.gotdns.org Sun Oct 18 08:27:30 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sun, 18 Oct 2009 11:27:30 -0400 Subject: caldav server In-Reply-To: <7D6EBCB9-F9FA-4B17-973D-D7859C70CDCE@newgeo.com> References: <7D6EBCB9-F9FA-4B17-973D-D7859C70CDCE@newgeo.com> Message-ID: > Off topic, but I am not sure where else to go. http://trac.calendarserver.org/ > seems to have languished. Is this no longer a workable project? > > I need calendar sharing on Mac OS X. I know it is built in within > OS X Server. What is my best route? Looking at things like > BusySync, which look great, but to share a calendar with my G/F > seems silly to drop any money on, let alone install a full blown OS > X Server to do so. Google. Starting with Snow Leopard there is greatness in the syncing with Google area. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4024 bytes Desc: not available URL: From wsiegrist at apple.com Sun Oct 18 11:45:44 2009 From: wsiegrist at apple.com (William Siegrist) Date: Sun, 18 Oct 2009 11:45:44 -0700 Subject: caldav server In-Reply-To: <7D6EBCB9-F9FA-4B17-973D-D7859C70CDCE@newgeo.com> References: <7D6EBCB9-F9FA-4B17-973D-D7859C70CDCE@newgeo.com> Message-ID: <0DBA03C3-AE13-42FA-AA33-70A1A42FF902@apple.com> On Oct 18, 2009, at 12:05 AM, Scott Haneda wrote: > Off topic, but I am not sure where else to go. http://trac.calendarserver.org/ seems to have languished. Is this no longer a workable project? > They committed to their repo 2 days ago. I suggest you join #calendarserver or mail their list if you need a caldav server. -Bill From ryandesign at macports.org Sun Oct 18 11:52:51 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 18 Oct 2009 13:52:51 -0500 Subject: [59615] trunk/dports/devel/activewire/Portfile In-Reply-To: <20091017225616.91BDC2A492C1@beta.macosforge.org> References: <20091017225616.91BDC2A492C1@beta.macosforge.org> Message-ID: <67FE35E7-7001-46D2-9946-633DBBF13F26@macports.org> On Oct 17, 2009, at 17:56, jameskyle at macports.org wrote: > Revision: 59615 > http://trac.macports.org/changeset/59615 > Author: jameskyle at macports.org > Date: 2009-10-17 15:56:14 -0700 (Sat, 17 Oct 2009) > Log Message: > ----------- > Updated SDK target. > Modified: trunk/dports/devel/activewire/Portfile > =================================================================== > --- trunk/dports/devel/activewire/Portfile 2009-10-17 22:56:12 UTC > (rev 59614) > +++ trunk/dports/devel/activewire/Portfile 2009-10-17 22:56:14 UTC > (rev 59615) > # Doesn't build with 10.5 > -macosx_deployment_target 10.4 > +macosx_deployment_target 10.5 > variant awdriver description {Installs the ActiveWire driver} {} > variant awconfig description {Installs the awconfig utility} {} > variant doc description {Install documentation} {} > @@ -53,6 +53,7 @@ > reinplace "s|/usr/local|${prefix}|g" "${worksrcpath}/$i/ > $i.xcodeproj/project.pbxproj" > > reinplace "s|/usr/share/man/man1/|${prefix}/include|g" "$ > {worksrcpath}/$i/$i.xcodeproj/project.pbxproj" > + reinplace "s|MacOSX10.4u.sdk|MacOSX10.5.sdk|g" "${worksrcpath}/ > $i/$i.xcodeproj/project.pbxproj" > That's probably going to break on 10.4 now. I can test it later today. If you don't want to support 10.4 anymore, just add a pre-fetch message to bail out for 10.4 and earlier. See graphviz-gui for an example. From ryandesign at macports.org Sun Oct 18 13:25:28 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 18 Oct 2009 15:25:28 -0500 Subject: [59650] trunk/dports/net/gvpe/Portfile In-Reply-To: <20091018195502.2D7D52A55FDC@beta.macosforge.org> References: <20091018195502.2D7D52A55FDC@beta.macosforge.org> Message-ID: <68AC6602-0222-49EF-B8C9-89C23C0B787D@macports.org> On Oct 18, 2009, at 14:55, adfernandes at macports.org wrote: > Revision: 59650 > http://trac.macports.org/changeset/59650 > Author: adfernandes at macports.org > Date: 2009-10-18 12:55:00 -0700 (Sun, 18 Oct 2009) > Log Message: > ----------- > Closes #22149 It would be great if you could describe in your commit message what you did, in addition to listing any relevant ticket numbers. For example, in this case, I would have written "gvpe: updated to 2.22 and took maintainership with openmaintainer; closes #22149". This makes it much easier when scanning the svn log to get an understanding of what has been happening with a port. If only ticket numbers are listed in the log messages, that means I have to take a detour to the issue tracker to find out what changed, and it makes it a lot more tedious if I'm reading the log because I'm trying to find out when a particular change occurred in a port. You can retroactively change your commit messages if you'd like to add more detail or correct mistakes. For example, to change the above log message, you would type svn propedit --revprop svn:log -r 59650 . From ryandesign at macports.org Sun Oct 18 13:47:02 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 18 Oct 2009 15:47:02 -0500 Subject: [59650] trunk/dports/net/gvpe/Portfile In-Reply-To: <973ae5cd0910181344w6d51b178s11f692438d7e7ddd@mail.gmail.com> References: <20091018195502.2D7D52A55FDC@beta.macosforge.org> <68AC6602-0222-49EF-B8C9-89C23C0B787D@macports.org> <973ae5cd0910181344w6d51b178s11f692438d7e7ddd@mail.gmail.com> Message-ID: On Oct 18, 2009, at 15:44, Andrew Fernandes wrote: > On Sun, Oct 18, 2009 at 4:25 PM, Ryan Schmidt > wrote: > >> On Oct 18, 2009, at 14:55, adfernandes at macports.org wrote: >> >>> Revision: 59650 >>> http://trac.macports.org/changeset/59650 >>> Author: adfernandes at macports.org >>> Date: 2009-10-18 12:55:00 -0700 (Sun, 18 Oct 2009) >>> Log Message: >>> ----------- >>> Closes #22149 >>> >> It would be great if you could describe in your commit message what >> you did, in addition to listing any relevant ticket numbers. For >> example, in this case, I would have written "gvpe: updated to 2.22 >> and took maintainership with openmaintainer; closes #22149". This >> makes it much easier when scanning the svn log to get an >> understanding of what has been happening with a port. If only >> ticket numbers are listed in the log messages, that means I have to >> take a detour to the issue tracker to find out what changed, and it >> makes it a lot more tedious if I'm reading the log because I'm >> trying to find out when a particular change occurred in a port. >> >> >> You can retroactively change your commit messages if you'd like to >> add more detail or correct mistakes. For example, to change the >> above log message, you would type >> >> svn propedit --revprop svn:log -r 59650 . > > Oh - sorry! Not a problem, just wanted to let you know. > No problem - will fix the current message and do as suggested in the > future! Thanks! From talklists at newgeo.com Sun Oct 18 14:18:23 2009 From: talklists at newgeo.com (Scott Haneda) Date: Sun, 18 Oct 2009 14:18:23 -0700 Subject: caldav server In-Reply-To: References: <7D6EBCB9-F9FA-4B17-973D-D7859C70CDCE@newgeo.com> Message-ID: On Oct 18, 2009, at 8:27 AM, Jeremy Lavergne wrote: >> Off topic, but I am not sure where else to go. http://trac.calendarserver.org/ >> seems to have languished. Is this no longer a workable project? >> >> I need calendar sharing on Mac OS X. I know it is built in within >> OS X Server. What is my best route? Looking at things like >> BusySync, which look great, but to share a calendar with my G/F >> seems silly to drop any money on, let alone install a full blown OS >> X Server to do so. > > Google. > > Starting with Snow Leopard there is greatness in the syncing with > Google area. I will look into it again. Thanks. Can you have a multi user shared calendar that can be edited by both parties? -- Scott * If you contact me off list replace talklists@ with scott@ * From etiffany at alum.mit.edu Sun Oct 18 15:15:39 2009 From: etiffany at alum.mit.edu (Eric Tiffany) Date: Sun, 18 Oct 2009 18:15:39 -0400 Subject: caldav server In-Reply-To: References: <7D6EBCB9-F9FA-4B17-973D-D7859C70CDCE@newgeo.com> Message-ID: On Oct 18, 2009, at 5:18 PM, Scott Haneda wrote: >> >> Google. >> >> Starting with Snow Leopard there is greatness in the syncing with >> Google area. > > I will look into it again. Thanks. Can you have a multi user > shared calendar that can be edited by both parties? Sure. Though there are a few weird problems. ICS invitations accepted in gcal cannot be edited on ical unless you are the "owner", and events on gcal cannot be created with a specific timezone (they are always in whatever the calendar owner's timezone is -- not sure what happens if different people in different timezones add events to a shared calendar). Etc. But the integration with ical is pretty good. ET -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimue at macports.org Sun Oct 18 15:17:05 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 19 Oct 2009 00:17:05 +0200 Subject: Installing additional documentation files In-Reply-To: <7ABB7A9D-75CC-420C-A6E0-391CD007C7F0@macports.org> References: <7ABB7A9D-75CC-420C-A6E0-391CD007C7F0@macports.org> Message-ID: <4ADB93E1.7060507@macports.org> On 2009-10-17 18:49 , Ryan Schmidt wrote: > If not, then I would also like to have MacPorts base auto-create $ > {prefix}/share/doc/${name} before the destroot phase, so each port > doesn't have to "xinstall -d" it manually. MacPorts base already > creates ${prefix}/share/${name} automatically so I think this fits. Sounds like a good idea to me. Rainer From raimue at macports.org Sun Oct 18 15:19:02 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 19 Oct 2009 00:19:02 +0200 Subject: gcc4x packages shouldn't build in source directory In-Reply-To: <20091017225506.GA4134@bromo.med.uc.edu> References: <20091017225506.GA4134@bromo.med.uc.edu> Message-ID: <4ADB9456.1030609@macports.org> On 2009-10-18 00:55 , Jack Howarth wrote: > I just noticed that MacPorts is building the FSF gcc > releases within the source tree. The upstream FSF gcc > developers frown upon this as poor technique. All of the > gcc4X packages should be creating a separate build directory, > eg darwin_objdir, outside of the source tree and then > executing both configure and make from within this > build directory. What is the problem with a build inside the source? I don't understand the reason for an out-of-place build if you only do it once and delete the source directory afterwards anyway. Rainer From howarth at bromo.med.uc.edu Sun Oct 18 15:36:59 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Sun, 18 Oct 2009 18:36:59 -0400 Subject: gcc4x packages shouldn't build in source directory In-Reply-To: <4ADB9456.1030609@macports.org> References: <20091017225506.GA4134@bromo.med.uc.edu> <4ADB9456.1030609@macports.org> Message-ID: <20091018223659.GA583@bromo.med.uc.edu> On Mon, Oct 19, 2009 at 12:19:02AM +0200, Rainer M?ller wrote: > On 2009-10-18 00:55 , Jack Howarth wrote: > > I just noticed that MacPorts is building the FSF gcc > > releases within the source tree. The upstream FSF gcc > > developers frown upon this as poor technique. All of the > > gcc4X packages should be creating a separate build directory, > > eg darwin_objdir, outside of the source tree and then > > executing both configure and make from within this > > build directory. > > What is the problem with a build inside the source? I don't understand > the reason for an out-of-place build if you only do it once and delete > the source directory afterwards anyway. > > Rainer Rainer, Upstream doesn't really test building within the source directory. The gcc build is quite complex with its multistage bootstrap and multilib builds. This can result in the source tree being accidentally modified in unexpected ways. Read... http://gcc.gnu.org/install/configure.html in particular the section... First, we highly recommend that GCC be built into a separate directory from the sources which does not reside within the source tree. This is how we generally build GCC; building where srcdir == objdir should still work, but doesn't get extensive testing; building where objdir is a subdirectory of srcdir is unsupported. In any case, I finally tracked down that this was a problem at my end in a local copy of the gcc44 Portfile and that the gcc4X packages in dports all seem to properly have... worksrcdir build Sorry about the noise on the mailing list. Jack From raimue at macports.org Sun Oct 18 16:23:04 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Mon, 19 Oct 2009 01:23:04 +0200 Subject: ${prefix}/var/macports/software In-Reply-To: References: Message-ID: <4ADBA358.4040808@macports.org> On 2009-10-17 19:47 , Jeremy Lavergne wrote: > Question for anyone who happens to know the innards of MacPorts with > regards to its software directory: is it suppose to be emptied out > when you have uninstalled all ports? Yes, would say so. > This is on a build box for me, and I have archivemode enabled and use > `-f uninstall` exclusively for software removal. > > The software directory is a fat 2.6GB when nothing is installed. Note > archives are not contained in the software folder (they're in ../ > packages). > > Does some combination of my settings leave these files in there? Does > using -f do this? Does archivemode cause them to be forgotten? Does > the combination break the expected behavior? I was able to reproduce this with current trunk without archivemode even when using regular 'port uninstall'. The image in ${prefix}/var/macports/software has been kept and was not removed as supposed. 'port -f uninstall' shows the same behavior. What I did: $ ls /opt/local/var/macports/software/less/ $ sudo port install less ... ---> Installing less @436_0 ---> Activating less @436_0 ---> Cleaning less $ ls /opt/local/var/macports/software/less/ 436_0/ $ sudo port uninstall less ---> Deactivating less @436_0 ---> Uninstalling less @436_0 $ ls /opt/local/var/macports/software/less/ 436_0/ $ Definitely a bug we need to look into. Rainer From talklists at newgeo.com Sun Oct 18 18:20:24 2009 From: talklists at newgeo.com (Scott Haneda) Date: Sun, 18 Oct 2009 18:20:24 -0700 Subject: mysql_close within php causes bus error Message-ID: Does anyone have the time to validate a bug I am running into. The below, as it stands, if you change user, pass, and db name, will run fine. If you allow mysql_close($link), that will also work fine. However, if you allow mysql_close() it will immediately kill that thread in Apache, and you will see in the errro_log: [Sun Oct 18 18:16:14 2009] [notice] child pid 5280 exit signal Bus error (10) Other shared sites talking to MySql through php seem to be ok. I am not familiar with the reporting process on this. How do I determine if this is a php issue or a MySql issue, or possibly a ports issue? $link = mysql_connect('localhost', 'user', 'pass'); if (! $link) { die('Could not connect: ' . mysql_error()) . '
'; } if (! mysql_select_db('db-name', $link)) { die('Could not connect: ' . mysql_error()) . '
'; } $sql = 'SELECT count(*) FROM table'; $res = mysql_query($sql); if ($error_msg = mysql_error()) echo $error_msg .'
'; print_r(mysql_fetch_assoc($res)); //mysql_close(); // fails //mysql_close($link); // ok -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Sun Oct 18 18:25:28 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 18 Oct 2009 20:25:28 -0500 Subject: mysql_close within php causes bus error In-Reply-To: References: Message-ID: On Oct 18, 2009, at 20:20, Scott Haneda wrote: > If you allow mysql_close($link), that will also work fine. However, > if you allow mysql_close() it will immediately kill that thread in > Apache, and you will see in the errro_log: > [Sun Oct 18 18:16:14 2009] [notice] child pid 5280 exit signal Bus > error (10) Looks like this bug will be fixed in 5.3.1. http://bugs.php.net/bug.php?id=48754 From vince at macports.org Mon Oct 19 03:31:03 2009 From: vince at macports.org (vincent habchi) Date: Mon, 19 Oct 2009 12:31:03 +0200 Subject: Metaport In-Reply-To: References: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> <24426824-6B14-415B-960B-D3D2F5751734@macports.org> <4AD72F0A.1030908@macports.org> Message-ID: <35C7887A-B318-4719-94FC-D8E75135388C@macports.org> Le 15 oct. 2009 ? 18:08, Ryan Schmidt a ?crit : > This is possible without needing to do anything complicated. You can > just set the merger_configure_args list with the desired values. > There are some existing ports that use this, which you can look at > for examples: nspr uses it to add "--enable-64bit" on 64-bit > architectures. fontconfig uses it to specify the architecture in a > "--with-arch" flag. tiff uses it to ensure "--with-apple-opengl- > framework" is not used on 64-bit architectures on Tiger. gtk2 adds > "--disable-cups" on 64-bit architectures on Tiger. fftw-3 adds "-- > enable-fma" on PowerPC systems and "--enable-sse2" on Intel systems. Ok, I tried this but it does not work. Well, it works, but this is not what I need. I need to be able to access a variable in the pre- configure phase that is either 32 or 64 depending on what arch the code is being compiled for. And that variable is to be used in a replace statement, so I really must be able to access it, not to include it implicitly via merger_configure_args(XXX). Vincent From dluke at geeklair.net Mon Oct 19 07:37:42 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Mon, 19 Oct 2009 10:37:42 -0400 Subject: caldav server In-Reply-To: <0DBA03C3-AE13-42FA-AA33-70A1A42FF902@apple.com> References: <7D6EBCB9-F9FA-4B17-973D-D7859C70CDCE@newgeo.com> <0DBA03C3-AE13-42FA-AA33-70A1A42FF902@apple.com> Message-ID: <1859EEBE-D01D-43BA-9960-5B3D5F4786AD@geeklair.net> On Oct 18, 2009, at 2:45 PM, William Siegrist wrote: > On Oct 18, 2009, at 12:05 AM, Scott Haneda wrote: >> Off topic, but I am not sure where else to go. http://trac.calendarserver.org/ >> seems to have languished. Is this no longer a workable project? > > They committed to their repo 2 days ago. I suggest you join > #calendarserver or mail their list if you need a caldav server. The last time I looked at it, it was quite annoying to install (something that could be fixed by someone writing a good portfile for it ;-) ). I've had good luck with davical (http://rscds.sourceforge.net/) (which could probably also use a port) -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ From ryandesign at macports.org Mon Oct 19 10:16:29 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 19 Oct 2009 12:16:29 -0500 Subject: Metaport In-Reply-To: <35C7887A-B318-4719-94FC-D8E75135388C@macports.org> References: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> <24426824-6B14-415B-960B-D3D2F5751734@macports.org> <4AD72F0A.1030908@macports.org> <35C7887A-B318-4719-94FC-D8E75135388C@macports.org> Message-ID: <7C497B21-1536-41E5-8BC7-7232A872A546@macports.org> On Oct 19, 2009, at 05:31, vincent habchi wrote: > Le 15 oct. 2009 ? 18:08, Ryan Schmidt a ?crit : > >> This is possible without needing to do anything complicated. You >> can just set the merger_configure_args list with the desired >> values. There are some existing ports that use this, which you can >> look at for examples: nspr uses it to add "--enable-64bit" on 64- >> bit architectures. fontconfig uses it to specify the architecture >> in a "--with-arch" flag. tiff uses it to ensure "--with-apple- >> opengl-framework" is not used on 64-bit architectures on Tiger. >> gtk2 adds "--disable-cups" on 64-bit architectures on Tiger. fftw-3 >> adds "--enable-fma" on PowerPC systems and "--enable-sse2" on Intel >> systems. > > Ok, I tried this but it does not work. Well, it works, but this is > not what I need. I need to be able to access a variable in the pre- > configure phase that is either 32 or 64 depending on what arch the > code is being compiled for. And that variable is to be used in a > replace statement, so I really must be able to access it, not to > include it implicitly via merger_configure_args(XXX). I don't believe that will be possible with the way the muniversal portgroup is written today. Looking in muniversal-1.0.tcl, I see its configure phase runs a loop over all requested architectures, and in that loop, it copies the worksrcpath to a new worksrcpath with a name based on the arch, sets up variables and flags, and then calls configure_main from MacPorts base. The muniversal portgroup doesn't do anything to change how pre-configure or post-configure are handled, so MacPorts base continues to handle this, which means pre-configure and post-configure only run once, not once per architecture. Also, since the actual worksrcdirs that will be used by configure are not created until the configure phase, they don't exist yet in pre-configure, so you can't do anything to them there. Are these C source files you're patching? If so, is there maybe a way to achieve what you want by using a patch which uses the __LP64__ #define? #ifdef __LP64__ do something 64-bit #else do something 32-bit #endif From vince at macports.org Mon Oct 19 10:36:52 2009 From: vince at macports.org (vincent habchi) Date: Mon, 19 Oct 2009 19:36:52 +0200 Subject: Metaport In-Reply-To: <7C497B21-1536-41E5-8BC7-7232A872A546@macports.org> References: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> <24426824-6B14-415B-960B-D3D2F5751734@macports.org> <4AD72F0A.1030908@macports.org> <35C7887A-B318-4719-94FC-D8E75135388C@macports.org> <7C497B21-1536-41E5-8BC7-7232A872A546@macports.org> Message-ID: <96C5C33D-CC5E-4542-BD88-E46117D91DE3@macports.org> Ryan, > I don't believe that will be possible with the way the muniversal > portgroup is written today. Looking in muniversal-1.0.tcl, I see its > configure phase runs a loop over all requested architectures, and in > that loop, it copies the worksrcpath to a new worksrcpath with a > name based on the arch, sets up variables and flags, and then calls > configure_main from MacPorts base. The muniversal portgroup doesn't > do anything to change how pre-configure or post-configure are > handled, so MacPorts base continues to handle this, which means pre- > configure and post-configure only run once, not once per > architecture. Also, since the actual worksrcdirs that will be used > by configure are not created until the configure phase, they don't > exist yet in pre-configure, so you can't do anything to them there. That's about the same thing I saw. I tried to add a pre-configure phase in muniversal, but it seems it is not called by the main interface, contrarily to other phases. I had not thought about the configure phase creating directories, but that can easily be switch from configure to some earlier phase. > Are these C source files you're patching? If so, is there maybe a > way to achieve what you want by using a patch which uses the > __LP64__ #define? Have a look at the atlas portfile, you'll see. No, that's a Fortran configuration file. Vincent From ryandesign at macports.org Mon Oct 19 10:47:46 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 19 Oct 2009 12:47:46 -0500 Subject: Metaport In-Reply-To: <96C5C33D-CC5E-4542-BD88-E46117D91DE3@macports.org> References: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> <24426824-6B14-415B-960B-D3D2F5751734@macports.org> <4AD72F0A.1030908@macports.org> <35C7887A-B318-4719-94FC-D8E75135388C@macports.org> <7C497B21-1536-41E5-8BC7-7232A872A546@macports.org> <96C5C33D-CC5E-4542-BD88-E46117D91DE3@macports.org> Message-ID: <033E3B59-E48D-4D52-B286-B9D5FD7315E3@macports.org> On Oct 19, 2009, at 12:36, vincent habchi wrote: >> I don't believe that will be possible with the way the muniversal >> portgroup is written today. Looking in muniversal-1.0.tcl, I see >> its configure phase runs a loop over all requested architectures, >> and in that loop, it copies the worksrcpath to a new worksrcpath >> with a name based on the arch, sets up variables and flags, and >> then calls configure_main from MacPorts base. The muniversal >> portgroup doesn't do anything to change how pre-configure or post- >> configure are handled, so MacPorts base continues to handle this, >> which means pre-configure and post-configure only run once, not >> once per architecture. Also, since the actual worksrcdirs that will >> be used by configure are not created until the configure phase, >> they don't exist yet in pre-configure, so you can't do anything to >> them there. > > That's about the same thing I saw. I tried to add a pre-configure > phase in muniversal, but it seems it is not called by the main > interface, contrarily to other phases. I don't know about that, but the other thing is that pre- and post- blocks can be defined multiple times. They don't override one another. So if the portgroup defines a pre-configure phase, and the portfile defines a pre-configure phase, MacPorts would happily call both of them. > I had not thought about the configure phase creating directories, > but that can easily be switch from configure to some earlier phase. Perhaps muniversal could do this in a post-extract phase. That way, you could write a (single) pre-configure phase, and in it, you would loop over the list of requested architectures and do your reinplacing in each one. >> Are these C source files you're patching? If so, is there maybe a >> way to achieve what you want by using a patch which uses the >> __LP64__ #define? > > Have a look at the atlas portfile, you'll see. No, that's a Fortran > configuration file. I haven't used fortran. Does fortran not offer something equivalent to C's preprocessor directives? From vince at macports.org Mon Oct 19 12:20:00 2009 From: vince at macports.org (vincent habchi) Date: Mon, 19 Oct 2009 21:20:00 +0200 Subject: Metaport In-Reply-To: <033E3B59-E48D-4D52-B286-B9D5FD7315E3@macports.org> References: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> <24426824-6B14-415B-960B-D3D2F5751734@macports.org> <4AD72F0A.1030908@macports.org> <35C7887A-B318-4719-94FC-D8E75135388C@macports.org> <7C497B21-1536-41E5-8BC7-7232A872A546@macports.org> <96C5C33D-CC5E-4542-BD88-E46117D91DE3@macports.org> <033E3B59-E48D-4D52-B286-B9D5FD7315E3@macports.org> Message-ID: <373486B6-8FB8-40AA-8087-0272A6D101DD@macports.org> Ryan, > I don't know about that, but the other thing is that pre- and post- > blocks can be defined multiple times. They don't override one > another. So if the portgroup defines a pre-configure phase, and the > portfile defines a pre-configure phase, MacPorts would happily call > both of them. Ah, that's something I was not aware of. It might be a solution. Yet, I admit I have some difficulty to understand the current structure of muniversal. What is the benefit of running a small loop for each step rather than one big loop over all steps? > Perhaps muniversal could do this in a post-extract phase. That way, > you could write a (single) pre-configure phase, and in it, you would > loop over the list of requested architectures and do your > reinplacing in each one. Yes, I'll try this. > I haven't used fortran. Does fortran not offer something equivalent > to C's preprocessor directives? I am not a Fortran specialist. Basically, I am pretty much like you might be: I compile Fortran code, but I'm far to be able to write even the most basic program in Fortran. But I haven't encountered anything like a preprocessor in Fortran. I think that just does not exist. Vincent From jmr at macports.org Mon Oct 19 12:35:07 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 20 Oct 2009 06:35:07 +1100 Subject: Metaport In-Reply-To: <373486B6-8FB8-40AA-8087-0272A6D101DD@macports.org> References: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> <24426824-6B14-415B-960B-D3D2F5751734@macports.org> <4AD72F0A.1030908@macports.org> <35C7887A-B318-4719-94FC-D8E75135388C@macports.org> <7C497B21-1536-41E5-8BC7-7232A872A546@macports.org> <96C5C33D-CC5E-4542-BD88-E46117D91DE3@macports.org> <033E3B59-E48D-4D52-B286-B9D5FD7315E3@macports.org> <373486B6-8FB8-40AA-8087-0272A6D101DD@macports.org> Message-ID: <4ADCBF6B.7020907@macports.org> On 2009-10-20 06:20, vincent habchi wrote: > Ah, that's something I was not aware of. It might be a solution. Yet, I > admit I have some difficulty to understand the current structure of > muniversal. What is the benefit of running a small loop for each step > rather than one big loop over all steps? If it isn't already apparent, a portgroup is the wrong place to do what muniversal attempts. All the oddities in its implementation, and all the ways the rules for what you can and can't do in the portfile change, stem from this. - Josh From vince at macports.org Mon Oct 19 13:17:09 2009 From: vince at macports.org (vincent habchi) Date: Mon, 19 Oct 2009 22:17:09 +0200 Subject: Metaport In-Reply-To: <4ADCBF6B.7020907@macports.org> References: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> <24426824-6B14-415B-960B-D3D2F5751734@macports.org> <4AD72F0A.1030908@macports.org> <35C7887A-B318-4719-94FC-D8E75135388C@macports.org> <7C497B21-1536-41E5-8BC7-7232A872A546@macports.org> <96C5C33D-CC5E-4542-BD88-E46117D91DE3@macports.org> <033E3B59-E48D-4D52-B286-B9D5FD7315E3@macports.org> <373486B6-8FB8-40AA-8087-0272A6D101DD@macports.org> <4ADCBF6B.7020907@macports.org> Message-ID: Le 19 oct. 2009 ? 21:35, Joshua Root a ?crit : > If it isn't already apparent, a portgroup is the wrong place to do > what > muniversal attempts. All the oddities in its implementation, and all > the > ways the rules for what you can and can't do in the portfile change, > stem from this. What would you propose instead? Put that mechanism directly in base? V. From jmr at macports.org Mon Oct 19 13:24:43 2009 From: jmr at macports.org (Joshua Root) Date: Tue, 20 Oct 2009 07:24:43 +1100 Subject: Metaport In-Reply-To: References: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> <24426824-6B14-415B-960B-D3D2F5751734@macports.org> <4AD72F0A.1030908@macports.org> <35C7887A-B318-4719-94FC-D8E75135388C@macports.org> <7C497B21-1536-41E5-8BC7-7232A872A546@macports.org> <96C5C33D-CC5E-4542-BD88-E46117D91DE3@macports.org> <033E3B59-E48D-4D52-B286-B9D5FD7315E3@macports.org> <373486B6-8FB8-40AA-8087-0272A6D101DD@macports.org> <4ADCBF6B.7020907@macports.org> Message-ID: <4ADCCB0B.8040704@macports.org> On 2009-10-20 07:17, vincent habchi wrote: > Le 19 oct. 2009 ? 21:35, Joshua Root a ?crit : > >> If it isn't already apparent, a portgroup is the wrong place to do what >> muniversal attempts. All the oddities in its implementation, and all the >> ways the rules for what you can and can't do in the portfile change, >> stem from this. > > What would you propose instead? Put that mechanism directly in base? That or add a new mechanism that allows the right kind of extensibility. - Josh From talklists at newgeo.com Mon Oct 19 13:38:38 2009 From: talklists at newgeo.com (Scott Haneda) Date: Mon, 19 Oct 2009 13:38:38 -0700 Subject: caldav server In-Reply-To: <1859EEBE-D01D-43BA-9960-5B3D5F4786AD@geeklair.net> References: <7D6EBCB9-F9FA-4B17-973D-D7859C70CDCE@newgeo.com> <0DBA03C3-AE13-42FA-AA33-70A1A42FF902@apple.com> <1859EEBE-D01D-43BA-9960-5B3D5F4786AD@geeklair.net> Message-ID: <30EB6E4A-1441-4D4D-AF5B-2061AAF71A08@newgeo.com> On Oct 19, 2009, at 7:37 AM, "Daniel J. Luke" wrote: > On Oct 18, 2009, at 2:45 PM, William Siegrist wrote: >> On Oct 18, 2009, at 12:05 AM, Scott Haneda wrote: >>> Off topic, but I am not sure where else to go. http://trac.calendarserver.org/ >>> seems to have languished. Is this no longer a workable project? >> >> They committed to their repo 2 days ago. I suggest you join >> #calendarserver or mail their list if you need a caldav server. > > The last time I looked at it, it was quite annoying to install > (something that could be fixed by someone writing a good portfile > for it ;-) ). > > I've had good luck with davical (http://rscds.sourceforge.net/) > (which could probably also use a port) Annoying to install? That's being nice. It pooped out 12 directories of junk cause I didn't think to put it in an empty sub folder. The docs ref files and scripts that don't exist. This is the same cal server os x server uses? No way is that code base in parity. I can't even get it to work, it starts, no errors, but no connections aside from http web admin can be made. All the tutorials are at least 2 years old. I thought it was me. I also assumed I was not port searching right and was just missing the port file. I'll make a port, but so far, irc has never had more than 12 people in the channel, none of whom are even active. -- Scott Iphone says hello. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryandesign at macports.org Mon Oct 19 15:06:40 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Mon, 19 Oct 2009 17:06:40 -0500 Subject: Metaport In-Reply-To: <373486B6-8FB8-40AA-8087-0272A6D101DD@macports.org> References: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> <24426824-6B14-415B-960B-D3D2F5751734@macports.org> <4AD72F0A.1030908@macports.org> <35C7887A-B318-4719-94FC-D8E75135388C@macports.org> <7C497B21-1536-41E5-8BC7-7232A872A546@macports.org> <96C5C33D-CC5E-4542-BD88-E46117D91DE3@macports.org> <033E3B59-E48D-4D52-B286-B9D5FD7315E3@macports.org> <373486B6-8FB8-40AA-8087-0272A6D101DD@macports.org> Message-ID: <64CC85E3-6BD3-45A4-9654-90007ABCAFDC@macports.org> On Oct 19, 2009, at 14:20, vincent habchi wrote: >> I don't know about that, but the other thing is that pre- and post- >> blocks can be defined multiple times. They don't override one >> another. So if the portgroup defines a pre-configure phase, and the >> portfile defines a pre-configure phase, MacPorts would happily call >> both of them. > > Ah, that's something I was not aware of. It might be a solution. > Yet, I admit I have some difficulty to understand the current > structure of muniversal. What is the benefit of running a small loop > for each step rather than one big loop over all steps? MacPorts does things in phases. That's not something that can be changed by a port. In the usual case (user hasn't enabled archive mode in macports.conf) the phases are: fetch checksum extract patch configure build destroot install activate A port can override any phase, but there's little reason to override fetch and extract, and no reason to override checksum, install, and activate. That leaves patch, configure, build, and destroot, which is where ports typically do their distinctive work. muniversal overrides the default behavior of configure, build, and destroot, so that each phase iterates over each architecture. As Joshua said, this is convoluted partly because it's in a portgroup, and it might be better implemented in base. From vince at macports.org Mon Oct 19 22:44:37 2009 From: vince at macports.org (vincent habchi) Date: Tue, 20 Oct 2009 07:44:37 +0200 Subject: Metaport In-Reply-To: <64CC85E3-6BD3-45A4-9654-90007ABCAFDC@macports.org> References: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> <24426824-6B14-415B-960B-D3D2F5751734@macports.org> <4AD72F0A.1030908@macports.org> <35C7887A-B318-4719-94FC-D8E75135388C@macports.org> <7C497B21-1536-41E5-8BC7-7232A872A546@macports.org> <96C5C33D-CC5E-4542-BD88-E46117D91DE3@macports.org> <033E3B59-E48D-4D52-B286-B9D5FD7315E3@macports.org> <373486B6-8FB8-40AA-8087-0272A6D101DD@macports.org> <64CC85E3-6BD3-45A4-9654-90007ABCAFDC@macports.org> Message-ID: <973A2274-D0F1-4700-B457-6CF427813239@macports.org> Le 20 oct. 2009 ? 00:06, Ryan Schmidt a ?crit : > MacPorts does things in phases. [?] That leaves patch, configure, > build, and destroot, which is where ports typically do their > distinctive work. muniversal overrides the default behavior of > configure, build, and destroot, so that each phase iterates over > each architecture. Remembers me of a "Calvin & Hobbes" strip: "Moon does faces"; "Not faces, phases!" > As Joshua said, this is convoluted partly because it's in a > portgroup, and it might be better implemented in base. Nice projet to carry on. I might get a hand on it when I'll have more free time. Cheers, Vincent From ryandesign at macports.org Tue Oct 20 11:23:28 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 20 Oct 2009 13:23:28 -0500 Subject: Dependencies for taglib-devel in macports In-Reply-To: <20091020111344.GA12533@physik.fu-berlin.de> References: <20091020111344.GA12533@physik.fu-berlin.de> Message-ID: <3146022D-3E67-4EFD-8A67-8217E7A8F021@macports.org> On Oct 20, 2009, at 06:13, Adrian Glaubitz wrote: > Hello Ryan, > > We are using macports to build and run the software of our open source > project on MacOS >10.4. Now, recent versions of our software require > taglib-devel, so I was about to install it. Wondering why the whole > install process took so long, I realized that "taglib-devel" depends > on "qt4-mac", which is the *full* installation of Qt4 built from > source. > > However, on my Debian box, there is no dependency on Qt4 so I think > you are breaking a butterfly on a wheel here. I think, you should > consider chaning the code to get rid of that dependency, the whole > build process just takes way too long and, moreover, it conflicts when > there is another version of Qt installed. > > Dependency on Debian: > > glaubitz at z6:~> apt-cache showsrc libtag1-dev > Package: taglib > Binary: libtag1c2a, libtag1-vanilla, libtag1-rusxmms, libtag1-dev, > libtag1-doc, libtagc0, libtagc0-dev > Version: 1.6-3 > Priority: optional > Section: libs > Maintainer: Modestas Vainius > Build-Depends: cmake (>= 2.6.2), debhelper (>= 7.3), dpkg-dev (>= > 1.15.3), quilt (>= 0.46-7~), zlib1g-dev, librcc-dev > Build-Depends-Indep: doxygen, graphviz, gsfonts-x11 > Architecture: any > Standards-Version: 3.8.3 > Format: 1.0 > Directory: pool/main/t/taglib > Files: > a841200a6bd7a0113e6fa797b4a0bfbe 1372 taglib_1.6-3.dsc > 5ecad0816e586a954bd676a86237d054 1098674 taglib_1.6.orig.tar.gz > 7cd67239b0c063ad04d98471401f61f0 24535 taglib_1.6-3.diff.gz > Dm-Upload-Allowed: yes > Homepage: http://developer.kde.org/~wheeler/taglib.html > Vcs-Browser: > http://git.debian.org/?p=users/modax-guest/taglib.git;a=summary > Vcs-Git: git://git.debian.org/users/modax-guest/taglib.git > Checksums-Sha1: > 2cb5309fa658c695b4ee28a72f85b4d892b63045 1098674 > taglib_1.6.orig.tar.gz > decc3aa1aa2d05e686f23f0b25095ce2cf18978a 24535 taglib_1.6-3.diff.gz > Checksums-Sha256: > 9aa10e1544a7117d595103addacfdc4e29a055bfbfaa1666faa29990fb7fbd97 > 1098674 taglib_1.6.orig.tar.gz > 60d407f2fe79366295ac66925e278143bfe58c0d884e30556527341c4080010e > 24535 taglib_1.6-3.diff.gz I don't have anything to do with the taglib ports so I'm not the one to ask about this. Orville Bennett added the taglib-devel port, and is also responsible for the kde4 portgroup it uses, which is where the qt4-mac dependency comes from. Ryan Stonecipher-Fisher changed taglib in r59203 9 days ago to use the cmake portgroup instead of the kde4 portgroup "to remove superfluous dependencies". Perhaps the same change should be made to taglib-devel. From ryandesign at macports.org Tue Oct 20 13:00:04 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 20 Oct 2009 15:00:04 -0500 Subject: [59705] trunk/dports/audio In-Reply-To: <20091020195112.6D34C2ABC982@beta.macosforge.org> References: <20091020195112.6D34C2ABC982@beta.macosforge.org> Message-ID: <9D65013C-BE86-46AC-A284-C1AC2F401B9A@macports.org> On Oct 20, 2009, at 14:51, singingwolfboy at macports.org wrote: > Revision: 59705 > http://trac.macports.org/changeset/59705 > Author: singingwolfboy at macports.org > Date: 2009-10-20 12:51:10 -0700 (Tue, 20 Oct 2009) > Log Message: > ----------- > added port for MIDI Patchbay app > > Added Paths: > ----------- > trunk/dports/audio/midi_patchbay/ > trunk/dports/audio/midi_patchbay/Portfile > > Added: trunk/dports/audio/midi_patchbay/Portfile > =================================================================== > --- trunk/dports/audio/midi_patchbay/ > Portfile (rev 0) > +++ trunk/dports/audio/midi_patchbay/Portfile 2009-10-20 19:51:10 > UTC (rev 59705) > @@ -0,0 +1,20 @@ > +# $Id$ > + > +PortSystem 1.0 > +PortGroup xcode 1.0 > + > +name midi_patchbay > +version 1.0.3 > +categories audio > +maintainers singingwolfboy openmaintainer > +description Pass MIDI data between inputs/outputs and apply > filters. > + > +long_description ${description} > + > +platforms darwin > + > +homepage http://notahat.com/midi_patchbay > +master_sites http://github.com/notahat/midi_patchbay > +fetch.type git > +git.url git://github.com/notahat/midi_patchbay.git > +git.branch 21d9746946c113303923e46cf2b6ebc80f13ffc8 > \ No newline at end of file FYI, we prefer to use exclusively spaces for whitespace; don't use tabs. Any tabs you see in existing portfiles are because we have not yet updated those portfiles to use spaces. (This recommendation only came about a few years ago.) Also, ensure your files end with a newline. Many editors (such as TextWrangler which I use) can be configured to do this for you automatically. From jmr at macports.org Tue Oct 20 14:02:12 2009 From: jmr at macports.org (Joshua Root) Date: Wed, 21 Oct 2009 08:02:12 +1100 Subject: [59705] trunk/dports/audio In-Reply-To: <9D65013C-BE86-46AC-A284-C1AC2F401B9A@macports.org> References: <20091020195112.6D34C2ABC982@beta.macosforge.org> <9D65013C-BE86-46AC-A284-C1AC2F401B9A@macports.org> Message-ID: <4ADE2554.7030505@macports.org> On 2009-10-21 07:00, Ryan Schmidt wrote: > FYI, we prefer to use exclusively spaces for whitespace; don't use tabs. > Any tabs you see in existing portfiles are because we have not yet > updated those portfiles to use spaces. (This recommendation only came > about a few years ago.) We do seem to have a majority of space users, and obviously mixing tabs and spaces in the same file is frowned upon, but I thought the choice of tabs or spaces was up to the maintainer? - Josh From ryandesign at macports.org Tue Oct 20 14:11:03 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 20 Oct 2009 16:11:03 -0500 Subject: [59705] trunk/dports/audio In-Reply-To: <4ADE2554.7030505@macports.org> References: <20091020195112.6D34C2ABC982@beta.macosforge.org> <9D65013C-BE86-46AC-A284-C1AC2F401B9A@macports.org> <4ADE2554.7030505@macports.org> Message-ID: <7FEE49D8-2968-4BEC-9D03-5160F40E612A@macports.org> On Oct 20, 2009, at 16:02, Joshua Root wrote: > On 2009-10-21 07:00, Ryan Schmidt wrote: >> FYI, we prefer to use exclusively spaces for whitespace; don't use >> tabs. >> Any tabs you see in existing portfiles are because we have not yet >> updated those portfiles to use spaces. (This recommendation only came >> about a few years ago.) > > We do seem to have a majority of space users, and obviously mixing > tabs > and spaces in the same file is frowned upon, but I thought the > choice of > tabs or spaces was up to the maintainer? My recollection is that we had a long argument about it a few years ago on the list, and in the end we agreed to use spaces, not tabs. I realize the Guide is not up to date on all things, but on this point, it seems accurate: http://guide.macports.org/#development.practices.portstyle From ryandesign at macports.org Wed Oct 21 00:10:21 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 21 Oct 2009 02:10:21 -0500 Subject: Dependencies for taglib-devel in macports In-Reply-To: <200910202116.47037.Orville.Bennett@gmail.com> References: <20091020111344.GA12533@physik.fu-berlin.de> <3146022D-3E67-4EFD-8A67-8217E7A8F021@macports.org> <200910202116.47037.Orville.Bennett@gmail.com> Message-ID: <672E076B-BAA2-4E6E-93AC-99166E39FC44@macports.org> On Oct 20, 2009, at 20:16, Orville Bennett wrote: > taglib indeed does not have any qt4 dependency. That was an error on > my part > and the cmake portgroup is quite correct. As for taglib-devel, it is > currently > deprecated by taglib 1.6, as it's not quite so -devel anymore. > > @Adrian With the release of taglib 1.6 (in development for quite > literally, > years) the taglib-devel port, which I added, is currently obsolete. > At the time taglib-devel was added something more current than the > then > stable (but quite buggy) taglib 1.5 was needed . I added taglib- > devel to track > development in the more recent svn branch. > > taglib-devel, which _should_ continue tracking svn if necessary, is > currently > *less* recent than the taglib 1.6. I don't anticipate personally > touching > taglib-devel again as the taglib guys seem to be doing regular > releases again. > Hope this clears things up (in other words whatever port you have > that's using > taglib-devel switch it over to taglib proper) > > I'll probably remove taglib-devel soon unless interesting things start > happening in svn again. That would probably be a good idea, to avoid confusion. Or maybe better yet, you could leave it as a stub port, and use the "replaced_by" keyword to automatically upgrade users from taglib-devel to taglib. From ryandesign at macports.org Wed Oct 21 00:40:10 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 21 Oct 2009 02:40:10 -0500 Subject: Dependencies for taglib-devel in macports In-Reply-To: <20091021073131.GA16822@physik.fu-berlin.de> References: <20091020111344.GA12533@physik.fu-berlin.de> <3146022D-3E67-4EFD-8A67-8217E7A8F021@macports.org> <200910202116.47037.Orville.Bennett@gmail.com> <672E076B-BAA2-4E6E-93AC-99166E39FC44@macports.org> <20091021073131.GA16822@physik.fu-berlin.de> Message-ID: <4CBABD95-5C5B-4A64-80A0-2AE7206707C5@macports.org> On Oct 21, 2009, at 02:31, Adrian Glaubitz wrote: > I have to admit, that I am a bit confused now. How can the runtime > versions of a library (here: taglib) replace the development files > (headers and libraries for linking, here: taglib-devel) ? That is not the naming convention used in MacPorts. In MacPorts, "taglib" is the latest stable version (including all libraries and headers), and "taglib-devel" is a development version (including all libraries and headers), which may be later than the latest stable version, or not (as in this case here). This naming convention is not documented in the Guide yet, but there is at least a ticket requesting that documentation: http://trac.macports.org/ticket/14540 From dluke at geeklair.net Wed Oct 21 06:01:39 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Wed, 21 Oct 2009 09:01:39 -0400 Subject: [59705] trunk/dports/audio In-Reply-To: <7FEE49D8-2968-4BEC-9D03-5160F40E612A@macports.org> References: <20091020195112.6D34C2ABC982@beta.macosforge.org> <9D65013C-BE86-46AC-A284-C1AC2F401B9A@macports.org> <4ADE2554.7030505@macports.org> <7FEE49D8-2968-4BEC-9D03-5160F40E612A@macports.org> Message-ID: <810B1341-B993-45F5-811F-19478F684C53@geeklair.net> On Oct 20, 2009, at 5:11 PM, Ryan Schmidt wrote: > My recollection is that we had a long argument about it a few years > ago on the list, and in the end we agreed to use spaces, not tabs. Every 6 months or so there's a big 'discussion' of this on the list. Almost every discussion has ended with spaces for base/ and that the port maintainer should be consistent. I personally think it's a waste of time to try to force portfile maintainers to use specific whitespace conventions (also, I'm pretty sure all of my Portfiles use tabs ;-) ). It's possible that the last time it was discussed the four people who really cared about it said that everyone should use spaces (but again, I think it's kind of silly). -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ From raimue at macports.org Wed Oct 21 10:48:05 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 21 Oct 2009 19:48:05 +0200 Subject: [59705] trunk/dports/audio In-Reply-To: <810B1341-B993-45F5-811F-19478F684C53@geeklair.net> References: <20091020195112.6D34C2ABC982@beta.macosforge.org> <9D65013C-BE86-46AC-A284-C1AC2F401B9A@macports.org> <4ADE2554.7030505@macports.org> <7FEE49D8-2968-4BEC-9D03-5160F40E612A@macports.org> <810B1341-B993-45F5-811F-19478F684C53@geeklair.net> Message-ID: <4ADF4955.5000005@macports.org> Daniel J. Luke wrote: > I personally think it's a waste of time to try to force portfile > maintainers to use specific whitespace conventions (also, I'm pretty > sure all of my Portfiles use tabs ;-) ). > > It's possible that the last time it was discussed the four people who > really cared about it said that everyone should use spaces (but again, I > think it's kind of silly). It's okay for me when a maintainer prefers tabs if at least the Portfile itself is consistent and either uses tabs or spaces for indentation. Rainer From raimue at macports.org Wed Oct 21 10:49:14 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Wed, 21 Oct 2009 19:49:14 +0200 Subject: Metaport In-Reply-To: <64CC85E3-6BD3-45A4-9654-90007ABCAFDC@macports.org> References: <9184D122-17AA-487E-B619-2CE1F7C5D115@macports.org> <24426824-6B14-415B-960B-D3D2F5751734@macports.org> <4AD72F0A.1030908@macports.org> <35C7887A-B318-4719-94FC-D8E75135388C@macports.org> <7C497B21-1536-41E5-8BC7-7232A872A546@macports.org> <96C5C33D-CC5E-4542-BD88-E46117D91DE3@macports.org> <033E3B59-E48D-4D52-B286-B9D5FD7315E3@macports.org> <373486B6-8FB8-40AA-8087-0272A6D101DD@macports.org> <64CC85E3-6BD3-45A4-9654-90007ABCAFDC@macports.org> Message-ID: <4ADF499A.8000705@macports.org> Ryan Schmidt wrote: > A port can override any phase, but there's little reason to override > fetch and extract, and no reason to override checksum, install, and > activate. That leaves patch, configure, build, and destroot, which is > where ports typically do their distinctive work. muniversal overrides > the default behavior of configure, build, and destroot, so that each > phase iterates over each architecture. See also what we discussed earlier about the muniversal integration: http://lists.macosforge.org/pipermail/macports-dev/2009-April/008205.html Rainer From talklists at newgeo.com Wed Oct 21 13:30:52 2009 From: talklists at newgeo.com (Scott Haneda) Date: Wed, 21 Oct 2009 13:30:52 -0700 Subject: Test development of pre-release software Message-ID: I have been working with the pureftpd developer to get some source changes made. I can build the software by checking out from git. I would like to start the portfile redo, can someone tell me how to do a local dev of this with a source set that is not at an official url? Do I just point the url to file:///some/place ? There is capacity to do TLS, which means a SSL cert. In the portfile there is a variant of tls, which just adds the with-tls configure option. It is then up to me to copy the included certs in place. Is there any reason I should not copy those in place for the user if that variant is selected? They do not hurt anything to exist, they still need to be enabled with the launchd startup plist. Ie: they are benign, even if installed. In the next release, inetd will be deprecated. As I am finding, all the plist items for launchd that are on the interwebs are using a seuperserver. This means that a port upgrade in the next release is going to break everyone's pureftpd, since the entire functionality is removed. What is the best way to deal with this? My intention now is to remove inetd fro the compile options in this current release. Would a ui message pointing to a new template plist file I will be making suffice in this case? I am a little concerned, as there is clear case that there is going to be breakage on port upgrade, since source code functionality is planned for deprecation. I do not think making a newly named port is the correct way. Are there any provisions in Mac Ports that I am missing for gracefully dealing with this case? -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Wed Oct 21 14:29:14 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 21 Oct 2009 16:29:14 -0500 Subject: Test development of pre-release software In-Reply-To: References: Message-ID: <4076A88C-F1C3-402B-83DF-273A69FA9966@macports.org> On Oct 21, 2009, at 15:30, Scott Haneda wrote: > I have been working with the pureftpd developer to get some source > changes made. I can build the software by checking out from git. > > I would like to start the portfile redo, can someone tell me how to > do a local dev of this with a source set that is not at an official > url? Do I just point the url to file:///some/place ? If you have a tarball, just put it where MacPorts expects it (/opt/ local/var/macports/distfiles/pureftpd). If you want to fetch from git, you can do that with "fetch.type git". > There is capacity to do TLS, which means a SSL cert. In the > portfile there is a variant of tls, which just adds the with-tls > configure option. It is then up to me to copy the included certs in > place. Is there any reason I should not copy those in place for the > user if that variant is selected? They do not hurt anything to > exist, they still need to be enabled with the launchd startup > plist. Ie: they are benign, even if installed. Sounds reasonable. > In the next release, inetd will be deprecated. As I am finding, all > the plist items for launchd that are on the interwebs are using a > seuperserver. This means that a port upgrade in the next release is > going to break everyone's pureftpd, since the entire functionality > is removed. > > What is the best way to deal with this? My intention now is to > remove inetd fro the compile options in this current release. Would > a ui message pointing to a new template plist file I will be making > suffice in this case? > > I am a little concerned, as there is clear case that there is going > to be breakage on port upgrade, since source code functionality is > planned for deprecation. > > I do not think making a newly named port is the correct way. Are > there any provisions in Mac Ports that I am missing for gracefully > dealing with this case? We don't have any built-in functionality for ports doing different things on upgrade vs. initial install. I'm never quite sure how to handle this either. In php5, for example, I simply don't handle it, requiring the user to notice e.g. that some features that used to be built into php5 are now in separate ports. You could perhaps print a ui_msg all the time, wording it in a way that makes sense to both new and existing users, or do something clever, like read the user's config file (plist?) and output a message only if it exists and calls for the deprecated functionality. I do this in the php5extension portgroup so that if the user's php.ini contains a problematic line, a message is printed telling the user to remove it. (If the line was never there or has already been removed, no message is printed.) From ram at macports.org Thu Oct 22 08:38:46 2009 From: ram at macports.org (Adam Mercer) Date: Thu, 22 Oct 2009 10:38:46 -0500 Subject: The opendarwin .com debacle In-Reply-To: References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> Message-ID: <799406d60910220838h65d86c40nbe1e8826b3f1c21c@mail.gmail.com> On Thu, Oct 15, 2009 at 00:48, Scott Haneda wrote: > Adding more... > http://freebsdgirl.com/2006/11/i-love-california.html > Clear evidence of confusion only a few years back. > > It's pretty simple to see the circles he travels in. ?I say give him one > last chance to do the right thing, at which point, we can discuss the next > step. More confusion from #22165: Comment(by macports@?): Replying to [comment:19 jameskyle@?]: > The universal could be the issue since atlas is not currently universal capable. > > But the 64b vs. 32b should have been taking care of in this ticket and revision: > > http://trac.macports.org/ticket/21433 > > http://trac.macports.org/changeset/57851 It builds fine with numpy for me on SL with 64 bit. I'm sorry that I introduced confusion to this ticket. I'm afraid I was using the portfile from darwinports.com as a reference (where it's still hardcoded 32 bit), before I found out that this was not recommended/out of date. -- Cheers Adam From jkh at apple.com Thu Oct 22 10:54:50 2009 From: jkh at apple.com (Jordan K. Hubbard) Date: Thu, 22 Oct 2009 10:54:50 -0700 Subject: The opendarwin .com debacle In-Reply-To: <799406d60910220838h65d86c40nbe1e8826b3f1c21c@mail.gmail.com> References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> <799406d60910220838h65d86c40nbe1e8826b3f1c21c@mail.gmail.com> Message-ID: Ultimately, I don't think anyone is going to be able to "force" the darwinports.com folks from doing what they're doing (and I really wish the original poster had managed to keep the notion of opendarwin / darwinports separate in his head, since they're really not related issues, yet there's opendarwin in the subject on this whole thread). Those who were around back when macports was chosen as the new name will know that this was, in fact, one of the big reasons for doing so. This "problem" has been around for as long as MacPorts has been renamed. The real problem at this point, however, is not darwinports.com and all this chest-thumping and hand wringing is giving me nothing but feelings of deja-vu since we have done it all before. It didn't help then and it's utterly unlikely to accomplish anything now. The real problem here is one of branding. Why/where are users even hearing the name "darwinports" when it's been essentially dead for over 3 years? Projects rename themselves all the time and somehow manage to make the name change stick. What this project needs to ask itself is why the name change has not stuck as successfully here and then fix that problem rather than re-fighting old battles. - Jordan From jeremy at lavergne.gotdns.org Thu Oct 22 10:58:01 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Thu, 22 Oct 2009 13:58:01 -0400 Subject: The opendarwin .com debacle In-Reply-To: References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> <799406d60910220838h65d86c40nbe1e8826b3f1c21c@mail.gmail.com> Message-ID: <19E878EA-684E-445F-9A3F-029FB42F63C2@lavergne.gotdns.org> > The real problem here is one of branding. Why/where are users even > hearing the name "darwinports" when it's been essentially dead for > over 3 years? Projects rename themselves all the time and somehow > manage to make the name change stick. What this project needs to > ask itself is why the name change has not stuck as successfully here > and then fix that problem rather than re-fighting old battles. Search for "pspp mac" and you'll find dp.com sitting at #4 or #5. This demonstrates at least one way people are finding it: searching for the open source project they want and "mac". In my example, simply searching for "pspp" will not being up dp.com. Macports is nowhere to be found, btw. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4024 bytes Desc: not available URL: From mark at dxradio.demon.co.uk Thu Oct 22 11:21:51 2009 From: mark at dxradio.demon.co.uk (Mark Hattam) Date: Thu, 22 Oct 2009 19:21:51 +0100 Subject: The opendarwin .com debacle In-Reply-To: References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> <799406d60910220838h65d86c40nbe1e8826b3f1c21c@mail.gmail.com> Message-ID: On 22 Oct 2009, at 18:54, Jordan K. Hubbard wrote: > Ultimately, I don't think anyone is going to be able to "force" the darwinports.com > folks from doing what they're doing (and I really wish the original > poster had managed to keep the notion of opendarwin / darwinports > separate in his head, since they're really not related issues, yet > there's opendarwin in the subject on this whole thread). Those who > were around back when macports was chosen as the new name will know > that this was, in fact, one of the big reasons for doing so. This > "problem" has been around for as long as MacPorts has been renamed. > > The real problem at this point, however, is not darwinports.com and > all this chest-thumping and hand wringing is giving me nothing but > feelings of deja-vu since we have done it all before. It didn't > help then and it's utterly unlikely to accomplish anything now. The > real problem here is one of branding. Why/where are users even > hearing the name "darwinports" when it's been essentially dead for > over 3 years? Projects rename themselves all the time and somehow > manage to make the name change stick. What this project needs to > ask itself is why the name change has not stuck as successfully here > and then fix that problem rather than re-fighting old battles. > > - Jordan Go to Google ... enter something like ... mysql5 port macosx 1. mysql.com 2. out of date way to get php5, mysql5, apache2 using MacPorts ... what's gawk & nawk ??? 3. the "unwanted" site ... 8. again the "unwanted" site, with a sublist of lots more results ... further down some hits for the trac to with bugs ... nowhere in the first 100 hits is www.macports.org So it's little wonder that the "other" site keeps cropping up. Google does have a good number of pages ... search for ... site:www.macports.org In fact there are 328 hits for site:www.macports.org mysql5 but having found which of those is a relevant one ... most of them have the generic "The Macports Project - Available Ports" page title. Mark From jberry at macports.org Thu Oct 22 11:37:35 2009 From: jberry at macports.org (James Berry) Date: Thu, 22 Oct 2009 11:37:35 -0700 Subject: The opendarwin .com debacle In-Reply-To: References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> <799406d60910220838h65d86c40nbe1e8826b3f1c21c@mail.gmail.com> Message-ID: <396D5857-09D1-411E-8F1A-5EE41784CEE7@macports.org> So all of this comes down to page rank for our site vs that "other" site. I've got to believe we have better incoming links to our site, so if we better structured our site to do cross linking between categories (and perhaps stoop to the subdomain tricks he does), we could presumably improve this situation immensely. James On Oct 22, 2009, at 11:21 AM, Mark Hattam wrote: > On 22 Oct 2009, at 18:54, Jordan K. Hubbard wrote: > >> Ultimately, I don't think anyone is going to be able to "force" the darwinports.com >> folks from doing what they're doing (and I really wish the >> original poster had managed to keep the notion of opendarwin / >> darwinports separate in his head, since they're really not related >> issues, yet there's opendarwin in the subject on this whole >> thread). Those who were around back when macports was chosen as >> the new name will know that this was, in fact, one of the big >> reasons for doing so. This "problem" has been around for as long >> as MacPorts has been renamed. >> >> The real problem at this point, however, is not darwinports.com and >> all this chest-thumping and hand wringing is giving me nothing but >> feelings of deja-vu since we have done it all before. It didn't >> help then and it's utterly unlikely to accomplish anything now. >> The real problem here is one of branding. Why/where are users even >> hearing the name "darwinports" when it's been essentially dead for >> over 3 years? Projects rename themselves all the time and somehow >> manage to make the name change stick. What this project needs to >> ask itself is why the name change has not stuck as successfully >> here and then fix that problem rather than re-fighting old battles. >> >> - Jordan > > > Go to Google ... enter something like ... mysql5 port macosx > > 1. mysql.com > 2. out of date way to get php5, mysql5, apache2 using MacPorts ... > what's gawk & nawk ??? > 3. the "unwanted" site > ... > 8. again the "unwanted" site, with a sublist of lots more results > ... > further down some hits for the trac to with bugs > ... > nowhere in the first 100 hits is www.macports.org > > So it's little wonder that the "other" site keeps cropping up. > > Google does have a good number of pages ... search for ... > site:www.macports.org > > In fact there are 328 hits for > site:www.macports.org mysql5 > > but having found which of those is a relevant one ... most of them > have the generic "The Macports Project - Available Ports" page title. > > > Mark > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From jameskyle at macports.org Thu Oct 22 12:09:09 2009 From: jameskyle at macports.org (James Kyle) Date: Thu, 22 Oct 2009 12:09:09 -0700 Subject: The opendarwin .com debacle In-Reply-To: <396D5857-09D1-411E-8F1A-5EE41784CEE7@macports.org> References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> <799406d60910220838h65d86c40nbe1e8826b3f1c21c@mail.gmail.com> <396D5857-09D1-411E-8F1A-5EE41784CEE7@macports.org> Message-ID: Given the guy is unscrupulous, there's no telling what kind of current version of google bombing he might be using to boost his rankings. Are there any legal issues involved with just claiming authority on the domain on my dns servers and redirecting to a page that informs the user of its lack of affiliation with the macports project proper and then providing links to both or some such? My dns server could potentially have a rather far reaching impact. -james On Oct 22, 2009, at 11:37 AM, James Berry wrote: > So all of this comes down to page rank for our site vs that "other" > site. > > I've got to believe we have better incoming links to our site, so if > we better structured our site to do cross linking between categories > (and perhaps stoop to the subdomain tricks he does), we could > presumably improve this situation immensely. > > James From vince at macports.org Thu Oct 22 13:05:19 2009 From: vince at macports.org (vincent habchi) Date: Thu, 22 Oct 2009 22:05:19 +0200 Subject: Disabling link with already installed libraries In-Reply-To: <070.7cda350c5cf115b6415cc22aa2f8c999@macports.org> References: <061.64f8ff38a3930cf0039b1e240e62e4f1@macports.org> <070.7cda350c5cf115b6415cc22aa2f8c999@macports.org> Message-ID: <4031856A-C4BD-4937-AFE2-E862FF5BEEE8@macports.org> From #22200 : > thought it was worth noting that there is an additional problem. > no_atlas > variant has no effect if the atlas package is installed - numpy is > linked > against atlas regardless. This seemed to me a different issue than the > above, hence the two different tickets. That's something I experienced also with other ports, notably when they are using Cmake. They find libraries in ${prefix}, wherever the user has enabled or disabled the corresponding option. Being familiar with another build-from-source-framework, namely pkgsrc (wherefore I install my packages in /usr/pkg and not /opt) on NetBSD, it uses a more subtile process: all the dependencies are linked in a temporary repertory, and the traditional tools like gcc, g++, etc. are replaced by shell scripts that provide on the fly substitutions of library and include paths from standard directories to that temporary one. Therefore: 1. When a dependency is not present, the package does not compile; 2. If an option flag that pulls a library in is not set, the library is not symlinked and the configure script does not find it, thereby enforcing the lack of dependency. Is there any hope to get such a behavior in Macports? Vincent From talklists at newgeo.com Thu Oct 22 13:25:25 2009 From: talklists at newgeo.com (Scott Haneda) Date: Thu, 22 Oct 2009 13:25:25 -0700 Subject: The opendarwin .com debacle In-Reply-To: References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> <799406d60910220838h65d86c40nbe1e8826b3f1c21c@mail.gmail.com> Message-ID: Hi Jordan. Correct, I made a mistake on the subject of the email, one I certainly know better. I addressed this in a previous email, and it indeed is something I regret, as it only muddies this situation. While I do not want to take the liberty, if everyone sees fit, hijack the subject, and correct it. Do not even bother putting in a [was: previous subject], let's just correct it. My bad. Comments below... On Oct 22, 2009, at 10:54 AM, Jordan K. Hubbard wrote: > Ultimately, I don't think anyone is going to be able to "force" the > darwinports.com folks from doing what they're doing (and I really > wish the original poster had managed to keep the notion of > opendarwin / darwinports separate in his head, since they're really > not related issues, yet there's opendarwin in the subject on this > whole thread). Those who were around back when macports was chosen > as the new name will know that this was, in fact, one of the big > reasons for doing so. This "problem" has been around for as long as > MacPorts has been renamed. I do not think forcing him to give up the domain will happen, but I do think that presenting some other data I have found about the individual may make him willingly give it up. I outlines some of my ideas on in a thread I was CC'd in on the MP Managers list, but have not heard anything more. I am not on that list, so perhaps I was removed from the CC loop and am just unaware of the replies. At this point, I do not think it is good to be public with some of the findings. > The real problem at this point, however, is not darwinports.com and > all this chest-thumping and hand wringing is giving me nothing but > feelings of deja-vu since we have done it all before. It didn't > help then and it's utterly unlikely to accomplish anything now. The > real problem here is one of branding. Why/where are users even > hearing the name "darwinports" when it's been essentially dead for > over 3 years? Projects rename themselves all the time and somehow > manage to make the name change stick. What this project needs to > ask itself is why the name change has not stuck as successfully here > and then fix that problem rather than re-fighting old battles. I suppose in part because there is a reason companies spend millions on branding, and so rigorously defend their brand from confusion, to avoid this exact case. The only thing I do know, is I have first hand experience with users I try to get to look into MP's, only to be told they did, and it sucked. I dig deeper, and am right in the middle of this very confusion, they run into the wrong domain somehow. There is a lot that can be done to clean up and better position the MP website. I outlines those things in a previous email because I feel I am strong in those areas. Myself, and one other were willing to put forth a donation to deal with the protection of a few rather obvious domain names. The last thing I want is for those that work on the internal of MP to be bothered with web development of the site, and sorting out google ranking issues. That is certainly something I am able to do, if I was given someone to work with to hash out the details of how to best approach it. Thanks for your comments. -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Thu Oct 22 13:27:18 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 22 Oct 2009 15:27:18 -0500 Subject: [59800] trunk/dports/math/atlas/Portfile In-Reply-To: <20091022200524.811F72B04274@beta.macosforge.org> References: <20091022200524.811F72B04274@beta.macosforge.org> Message-ID: <249B8B6E-A16D-4D14-BDDE-459D3036B274@macports.org> On Oct 22, 2009, at 15:05, jameskyle at macports.org wrote: > Revision: 59800 > http://trac.macports.org/changeset/59800 > Author: jameskyle at macports.org > Date: 2009-10-22 13:05:20 -0700 (Thu, 22 Oct 2009) > Log Message: > ----------- > Re-enabled the universal variant then override it with a warning > that a universal binary is not built. Why? If you don't actually build a universal binary, then you should not have a universal variant. From talklists at newgeo.com Thu Oct 22 13:33:16 2009 From: talklists at newgeo.com (Scott Haneda) Date: Thu, 22 Oct 2009 13:33:16 -0700 Subject: The opendarwin .com debacle In-Reply-To: References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> <799406d60910220838h65d86c40nbe1e8826b3f1c21c@mail.gmail.com> Message-ID: On Oct 22, 2009, at 11:21 AM, Mark Hattam wrote: > Go to Google ... enter something like ... mysql5 port macosx > > 1. mysql.com > 2. out of date way to get php5, mysql5, apache2 using MacPorts ... > what's gawk & nawk ??? > 3. the "unwanted" site > ... > 8. again the "unwanted" site, with a sublist of lots more results > ... > further down some hits for the trac to with bugs > ... > nowhere in the first 100 hits is www.macports.org > > So it's little wonder that the "other" site keeps cropping up. > > Google does have a good number of pages ... search for ... site:www.macports.org > > In fact there are 328 hits for > site:www.macports.org mysql5 > > but having found which of those is a relevant one ... most of them > have the generic "The Macports Project - Available Ports" page title. Good points. The controlling factor of this, for the most part is, that the nefarious site maintains a better page rank. The good news is, his tactics are old, and largely irrelevant. To get ahead of him would not be that hard. Being really generic about this: site:darwinports.com 22,800 internally linked pages site:macports.org 45,100 internally linked pages MacPorrs doubles his pages in that search, that battle is won. Here is where MacPorts is failing: link:macports.org 1,240 link:darwinports.com 743 While MP beats him in raw numbers, the authority of those who link to him is higher, so he wins. It was preiously mentioned this is an issue of branding, which is true. Branding is going to take time and work. It is a long term goal. The brand could be cleaned immensely by just making the domain go away, then MP becomes the authoritative brand. It is a step 2 as far as I see it. The easiest way to deal with this. I wanted to make one last effort to contact the domain owner and present him the chance to do the right thing. As long as I have permission to do so on behalf of MP, I will be happy to get that ball rolling. -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Thu Oct 22 13:33:23 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 22 Oct 2009 15:33:23 -0500 Subject: [59801] trunk/base/src/port1.0/portutil.tcl In-Reply-To: <20091022202659.D07FE2B04911@beta.macosforge.org> References: <20091022202659.D07FE2B04911@beta.macosforge.org> Message-ID: <51F537F7-57EF-4EEC-8598-157253C63211@macports.org> On Oct 22, 2009, at 15:26, jmr at macports.org wrote: > Revision: 59801 > http://trac.macports.org/changeset/59801 > Author: jmr at macports.org > Date: 2009-10-22 13:26:56 -0700 (Thu, 22 Oct 2009) > Log Message: > ----------- > warn when using +universal on ports with no universal variant (can > move the check somewhere else if it ends up being too chatty) Why print this message? And why limit it to just the universal variant then? Why not print a message anytime someone selects any variant that doesn't exist? The easiest way to install wine on Snow Leopard is to type sudo port install wine-devel +universal in an empty MacPorts install. This installs all dependencies universal, but of course not wine-devel itself, since it doesn't have a universal variant. So I imagine this would trigger your message. From ryandesign at macports.org Thu Oct 22 13:38:18 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 22 Oct 2009 15:38:18 -0500 Subject: [59792] trunk/dports/science/gromacs In-Reply-To: <20091022131536.B9C692AF23E0@beta.macosforge.org> References: <20091022131536.B9C692AF23E0@beta.macosforge.org> Message-ID: On Oct 22, 2009, at 08:15, adfernandes at macports.org wrote: > Revision: 59792 > http://trac.macports.org/changeset/59792 > Author: adfernandes at macports.org > Date: 2009-10-22 06:15:33 -0700 (Thu, 22 Oct 2009) > Log Message: > ----------- > gromacs: add gcc44 variant and add patch two known forcefield bugs So you compile with gcc42 by default, and have variants for gcc43 and gcc44. You should add a variant for gcc42 also, make them all conflict with one another, and ensure at least one variant is selected. See the molden port for an example of how this can be done. For now, gcc42 should continue to be the default, since that's what you were using by default before. But the next time the port is updated to a new version, you should make the default gcc43 or gcc44, whatever is decided in #20103. http://trac.macports.org/ticket/20103 From talklists at newgeo.com Thu Oct 22 13:41:56 2009 From: talklists at newgeo.com (Scott Haneda) Date: Thu, 22 Oct 2009 13:41:56 -0700 Subject: The opendarwin .com debacle In-Reply-To: <396D5857-09D1-411E-8F1A-5EE41784CEE7@macports.org> References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> <799406d60910220838h65d86c40nbe1e8826b3f1c21c@mail.gmail.com> <396D5857-09D1-411E-8F1A-5EE41784CEE7@macports.org> Message-ID: On Oct 22, 2009, at 11:37 AM, James Berry wrote: > So all of this comes down to page rank for our site vs that "other" > site. Correct. And if you look at the rankings of the sites that link to him, you will see, they have stronger rankings than those that link in to Mac Ports. > I've got to believe we have better incoming links to our site, Unfortunately, no, in my research, that is not the case. One of the very best things that could be done, would be for MacPorts to have every maintainer of every port contact the developer of that software, and ask for al link. I have done this for every port I worked on. When I finish the ASSP port, there will be a link. I did the memtester port, ( http://pyropus.ca/software/memtester/ ) and went to him to get a link. I will be finishing the pureftpd port, and will also get the same linking. What anchor text we suggest to use should be talked about, I am not sure that "MacPorts" is the best. It would be a discussion worth having for sure. > so if we better structured our site to do cross linking between > categories (and perhaps stoop to the subdomain tricks he does), we > could presumably improve this situation immensely. We do not need to stoop to this level. See my more detailed email that was in the off list discussion in which I am pretty sure you were CCd'd on. Matt Cutts, Google Search guy, spoke about this at PubCon. While it used to matter, it no longer would apply in this case. It would be a waste of effort and using a tactic that even if it did work, could change at some time, and be wasted work. http://www.mattcutts.com/blog/subdomains-and-subdirectories/ ( There is a video that explains it as well, I believe in within this page http://www.mattcutts.com/blog/seo-answers-on-google-video/ ) It used to work, and since no site has come along to challenge the relevance of the DP site, he will still maintain the rankings from when that tactic did work. -- Scott * If you contact me off list replace talklists@ with scott@ * From talklists at newgeo.com Thu Oct 22 13:45:25 2009 From: talklists at newgeo.com (Scott Haneda) Date: Thu, 22 Oct 2009 13:45:25 -0700 Subject: The opendarwin .com debacle In-Reply-To: References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> <799406d60910220838h65d86c40nbe1e8826b3f1c21c@mail.gmail.com> <396D5857-09D1-411E-8F1A-5EE41784CEE7@macports.org> Message-ID: On Oct 22, 2009, at 12:09 PM, James Kyle wrote: > Given the guy is unscrupulous, there's no telling what kind of > current version of google bombing he might be using to boost his > rankings. I do not think much, I think he is riding the train of strong rankings from years ago, and no other site has challenged his ranking, so he just holds onto it. > Are there any legal issues involved with just claiming authority on > the domain on my dns servers and redirecting to a page that informs > the user of its lack of affiliation with the macports project proper > and then providing links to both or some such? Your DNS, do as you see fit. If you were a root server, then I suspect you would have an issue, as NetSol did with their NXDOMAIN thing a while back. > My dns server could potentially have a rather far reaching impact. I was going to do the same, though my DNS server does not have such far reaching impact, but more out of principle. Perhaps enough pokes at openDNS and and the malware url checking service Safari and FireFox use, could get his domain listed as a scam site, which is very much is as it asks for money. -- Scott * If you contact me off list replace talklists@ with scott@ * From blb at macports.org Thu Oct 22 14:49:57 2009 From: blb at macports.org (Bryan Blackburn) Date: Thu, 22 Oct 2009 15:49:57 -0600 Subject: Disabling link with already installed libraries In-Reply-To: <4031856A-C4BD-4937-AFE2-E862FF5BEEE8@macports.org> References: <061.64f8ff38a3930cf0039b1e240e62e4f1@macports.org> <070.7cda350c5cf115b6415cc22aa2f8c999@macports.org> <4031856A-C4BD-4937-AFE2-E862FF5BEEE8@macports.org> Message-ID: <20091022214957.GQ4719@ninagal.withay.com> On Thu, Oct 22, 2009 at 10:05:19PM +0200, vincent habchi said: > From #22200 : > > >thought it was worth noting that there is an additional problem. > >no_atlas > >variant has no effect if the atlas package is installed - numpy is > >linked > >against atlas regardless. This seemed to me a different issue than the > >above, hence the two different tickets. > > That's something I experienced also with other ports, notably when > they are using Cmake. They find libraries in ${prefix}, wherever the > user has enabled or disabled the corresponding option. > > Being familiar with another build-from-source-framework, namely > pkgsrc (wherefore I install my packages in /usr/pkg and not /opt) on > NetBSD, it uses a more subtile process: all the dependencies are > linked in a temporary repertory, and the traditional tools like gcc, > g++, etc. are replaced by shell scripts that provide on the fly > substitutions of library and include paths from standard directories > to that temporary one. Therefore: > > 1. When a dependency is not present, the package does not compile; > 2. If an option flag that pulls a library in is not set, the library > is not symlinked and the configure script does not find it, thereby > enforcing the lack of dependency. > > Is there any hope to get such a behavior in Macports? Only if someone implements it. Bryan > > Vincent From ryandesign at macports.org Thu Oct 22 15:20:25 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 22 Oct 2009 17:20:25 -0500 Subject: Disabling link with already installed libraries In-Reply-To: <4031856A-C4BD-4937-AFE2-E862FF5BEEE8@macports.org> References: <061.64f8ff38a3930cf0039b1e240e62e4f1@macports.org> <070.7cda350c5cf115b6415cc22aa2f8c999@macports.org> <4031856A-C4BD-4937-AFE2-E862FF5BEEE8@macports.org> Message-ID: <9DB37CCF-F16F-40C3-8A95-68E56D670E2B@macports.org> On Oct 22, 2009, at 15:05, vincent habchi wrote: > That's something I experienced also with other ports, notably when > they are using Cmake. They find libraries in ${prefix}, wherever the > user has enabled or disabled the corresponding option. That sounds like a pretty bad bug, in either cmake or whatever software is using it (I'm not sure). If you can figure out which, I recommend you file a bug report with them. From jkh at apple.com Thu Oct 22 16:17:38 2009 From: jkh at apple.com (Jordan K. Hubbard) Date: Thu, 22 Oct 2009 16:17:38 -0700 Subject: The opendarwin .com debacle In-Reply-To: <19E878EA-684E-445F-9A3F-029FB42F63C2@lavergne.gotdns.org> References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> <799406d60910220838h65d86c40nbe1e8826b3f1c21c@mail.gmail.com> <19E878EA-684E-445F-9A3F-029FB42F63C2@lavergne.gotdns.org> Message-ID: Maybe it's about putting up the appropriate keywords/tag data for google to find then? Someone here must know the magic to get MacPorts indexed ahead of dp.com... On Oct 22, 2009, at 10:58 AM, Jeremy Lavergne wrote: >> The real problem here is one of branding. Why/where are users even hearing the name "darwinports" when it's been essentially dead for over 3 years? Projects rename themselves all the time and somehow manage to make the name change stick. What this project needs to ask itself is why the name change has not stuck as successfully here and then fix that problem rather than re-fighting old battles. > > Search for "pspp mac" and you'll find dp.com sitting at #4 or #5. This demonstrates at least one way people are finding it: searching for the open source project they want and "mac". In my example, simply searching for "pspp" will not being up dp.com. > > Macports is nowhere to be found, btw. > From ryandesign at macports.org Thu Oct 22 16:38:24 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Thu, 22 Oct 2009 18:38:24 -0500 Subject: The opendarwin .com debacle In-Reply-To: References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> <799406d60910220838h65d86c40nbe1e8826b3f1c21c@mail.gmail.com> <19E878EA-684E-445F-9A3F-029FB42F63C2@lavergne.gotdns.org> Message-ID: <491F974F-52ED-44BE-829D-D4E6BE133E67@macports.org> On Oct 22, 2009, at 18:17, Jordan K. Hubbard wrote: > Maybe it's about putting up the appropriate keywords/tag data for > google to find then? Someone here must know the magic to get > MacPorts indexed ahead of dp.com... Yes. We need to improve our pagerank. Scott had several suggestions. I intend to work with him off list to implement some of them. From captsolo at gmail.com Fri Oct 23 04:49:19 2009 From: captsolo at gmail.com (Uldis Bojars) Date: Fri, 23 Oct 2009 12:49:19 +0100 Subject: swi-prolog: building 64-bit Message-ID: <64c81f720910230449v12daa473hbdedde5bec41c8ca@mail.gmail.com> Hi, Is it possible to build a 64-bit version of the swi-prolog (on Mac OS X 10.5)? If yes, could you please advise me how to do that? The problem I am trying to solve is related to JPL, included as a part of swi-prolog. When it comes to using SWI-Prolog from Java 6 (via jpl.jar), Leopard only has a 64-bit version of JVM and it is not possible to load 32-bit libjpl.dylib (built by default) into 64-bit Java. Thanks, Uldis From ryandesign at macports.org Fri Oct 23 04:59:58 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 23 Oct 2009 06:59:58 -0500 Subject: swi-prolog: building 64-bit In-Reply-To: <64c81f720910230449v12daa473hbdedde5bec41c8ca@mail.gmail.com> References: <64c81f720910230449v12daa473hbdedde5bec41c8ca@mail.gmail.com> Message-ID: <7C91FC09-6C59-4866-9F1D-14260F1B9663@macports.org> On Oct 23, 2009, at 06:49, Uldis Bojars wrote: > Is it possible to build a 64-bit version of the swi-prolog (on Mac > OS X 10.5)? > > If yes, could you please advise me how to do that? > > The problem I am trying to solve is related to JPL, included as a part > of swi-prolog. When it comes to using SWI-Prolog from Java 6 (via > jpl.jar), Leopard only has a 64-bit version of JVM and it is not > possible to load 32-bit libjpl.dylib (built by default) into 64-bit > Java. The general instructions for building any port 64-bit are to set build_arch to x86_64 in macports.conf (on Intel; on PowerPC, it would be ppc64). I do not know if swi-prolog supports building 64-bit on Leopard or at all. From milosh at macports.org Fri Oct 23 07:02:38 2009 From: milosh at macports.org (Emmanuel Hainry) Date: Fri, 23 Oct 2009 16:02:38 +0200 Subject: The opendarwin .com debacle In-Reply-To: References: <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> <799406d60910220838h65d86c40nbe1e8826b3f1c21c@mail.gmail.com> <396D5857-09D1-411E-8F1A-5EE41784CEE7@macports.org> Message-ID: <20091023140238.GB23063@weetamoe.loria.fr> Citando Scott Haneda : > > Unfortunately, no, in my research, that is not the case. One of the > very best things that could be done, would be for MacPorts to have > every maintainer of every port contact the developer of that > software, and ask for al link. > > I have done this for every port I worked on. When I finish the ASSP > port, there will be a link. I did the memtester port, ( > http://pyropus.ca/software/memtester/ ) and went to him to get a > link. > > I will be finishing the pureftpd port, and will also get the same > linking. What anchor text we suggest to use should be talked about, > I am not sure that "MacPorts" is the best. It would be a discussion > worth having for sure. > The anchor is one thing, the destination is another. Which is the page to link from upstream webpage? I see at least 3 possibilities: 1) www.macports.org: that's what I did for mpd. There is also a text explaining the command to install mpd from macports. 2) http://www.macports.org/ports.php and if possible the specific page for the port. But it is not informative in any way and you cannot get a link for some ports (mpd for example) 3) http://trac.macports.org/browser/trunk/dports/audio/mpd/Portfile None of those is both informative on the port and readable. Note that fink has beautiful pages for each port: http://pdb.finkproject.org/pdb/package.php/mpd. mpd_darwinports_com also has a page (not more interesting than the Portfile). So who will write a Portfile_to_webpage script to have a readable and informative page for each port? In a perfect world, this page would also feature a link to the bugs reported against this port. Doing better than http://packages.debian.org/sid/mpd could be a goal. Regards, Emmanuel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From juanger at macports.org Fri Oct 23 10:59:29 2009 From: juanger at macports.org (=?ISO-8859-1?Q?Juan_Germ=E1n_Casta=F1eda_Echevarria?=) Date: Fri, 23 Oct 2009 12:59:29 -0500 Subject: The opendarwin .com debacle In-Reply-To: <20091023140238.GB23063@weetamoe.loria.fr> References: <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> <799406d60910220838h65d86c40nbe1e8826b3f1c21c@mail.gmail.com> <396D5857-09D1-411E-8F1A-5EE41784CEE7@macports.org> <20091023140238.GB23063@weetamoe.loria.fr> Message-ID: <2bad8a110910231059w5b22c5fch9f683611ff751733@mail.gmail.com> 2009/10/23 Emmanuel Hainry > > The anchor is one thing, the destination is another. Which is the page > to link from upstream webpage? I see at least 3 possibilities: > 1) www.macports.org: that's what I did for mpd. There > is also a text explaining the command to install mpd from macports. > 2) http://www.macports.org/ports.php and if possible the specific page > for the port. But it is not informative in any way and you cannot get a > link for some ports (mpd for example) > 3) http://trac.macports.org/browser/trunk/dports/audio/mpd/Portfile > > None of those is both informative on the port and readable. Note that > fink has beautiful pages for each port: > http://pdb.finkproject.org/pdb/package.php/mpd. mpd_darwinports_com also > has a page (not more interesting than the Portfile). So > who will write a Portfile_to_webpage script to have a readable and > informative page for each port? In a perfect world, this page would also > feature a link to the bugs reported against this port. Doing better than > http://packages.debian.org/sid/mpd could be a goal. > Couldn't this be made by creating the MacPorts web application? I think James Berry was working on it and if I can help with its development, I'd be honoured. -- Ash Mac durbatul?k, ash Mac gimbatul, ash Mac thrakatul?k agh burzum-ishi krimpatul. Juanger. http://xocoruby.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryandesign at macports.org Fri Oct 23 12:04:58 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 23 Oct 2009 14:04:58 -0500 Subject: The opendarwin .com debacle In-Reply-To: <2bad8a110910231059w5b22c5fch9f683611ff751733@mail.gmail.com> References: <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> <799406d60910220838h65d86c40nbe1e8826b3f1c21c@mail.gmail.com> <396D5857-09D1-411E-8F1A-5EE41784CEE7@macports.org> <20091023140238.GB23063@weetamoe.loria.fr> <2bad8a110910231059w5b22c5fch9f683611ff751733@mail.gmail.com> Message-ID: On Oct 23, 2009, at 12:59, Juan Germ?n Casta?eda Echevarria wrote: >> Note that >> fink has beautiful pages for each port: >> http://pdb.finkproject.org/pdb/package.php/mpd. mpd_darwinports_com >> also >> has a page (not more interesting than the Portfile). So >> who will write a Portfile_to_webpage script to have a readable and >> informative page for each port? In a perfect world, this page would >> also >> feature a link to the bugs reported against this port. Doing better >> than >> http://packages.debian.org/sid/mpd could be a goal. > > Couldn't this be made by creating the MacPorts web application? > > I think James Berry was working on it and if I can help with its > development, I'd be honoured. I am doing this now, separate from the old MPWA. Please see: http://trac.macports.org/ticket/19300 From talklists at newgeo.com Fri Oct 23 12:18:48 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 23 Oct 2009 12:18:48 -0700 Subject: Dependency on developer tools Message-ID: Looking over the MP website install notes. I see dev tools is required. This bit me once, I stupidly set up a new machine and just forgot to install dev tools. Is there any good reason MP should not stop the installer if it does not detect a valid dev tool install? Seems to me a better end user experience. -- Scott Iphone says hello. From lee at dropio.com Fri Oct 23 12:25:20 2009 From: lee at dropio.com (Lee Azzarello) Date: Fri, 23 Oct 2009 15:25:20 -0400 Subject: Dependency on developer tools In-Reply-To: References: Message-ID: <16b031c0910231225j11c1d0f7r70076e70760b05da@mail.gmail.com> On Fri, Oct 23, 2009 at 3:18 PM, Scott Haneda wrote: > Looking over the MP website install notes. I see dev tools is required. > > This bit me once, I stupidly set up a new machine and just forgot to > install dev tools. > > Is there any good reason MP should not stop the installer if it does not > detect a valid dev tool install? > OS X does not come with a compiler by default and macports requires you to compile the software before installing it. The only to get a compiler is to install Xcode from the installation DVD. There is a possibility of not requiring developer tools to install open source software on OS X, but from what I can see there isn't that large community supporting binary packaging. The Fink project tried but their binary packages are very old. Macports does have the option of using the FreeBSD package format to install binaries, though I don't think macports offers that option. Correct me if I'm wrong as I'm new to macports. I'm a Debian GNU/Linux user who supports OS X at work for a development platform. -- _______________ Lee Azzarello drop.io staff hacker -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryandesign at macports.org Fri Oct 23 12:26:11 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 23 Oct 2009 14:26:11 -0500 Subject: Dependency on developer tools In-Reply-To: References: Message-ID: On Oct 23, 2009, at 14:18, Scott Haneda wrote: > Looking over the MP website install notes. I see dev tools is > required. > > This bit me once, I stupidly set up a new machine and just forgot to > install dev tools. > > Is there any good reason MP should not stop the installer if it does > not detect a valid dev tool install? > > Seems to me a better end user experience. I agree, and plan to do so. http://trac.macports.org/ticket/21685#comment:3 It's a pretty small thing to do, so if anybody else wants to tackle it, feel free. From mdcrawford at gmail.com Fri Oct 23 12:32:25 2009 From: mdcrawford at gmail.com (Michael Crawford) Date: Fri, 23 Oct 2009 12:32:25 -0700 Subject: Dependency on developer tools In-Reply-To: References: Message-ID: Apple's versions of the GNU toolchain are open source, and available from http://opensource.apple.com/ Suppose one were to build just enough of a toolchain to be able to build a MacPort, and provided just that as a binary download, that would get installed if Xcode wasn't installed. Mike -- Michael David Crawford mdcrawford at gmail dot com GoingWare's Bag of Programming Tricks http://www.goingware.com/tips/ From ryandesign at macports.org Fri Oct 23 12:39:38 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 23 Oct 2009 14:39:38 -0500 Subject: Dependency on developer tools In-Reply-To: References: Message-ID: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> On Oct 23, 2009, at 14:32, Michael Crawford wrote: > Apple's versions of the GNU toolchain are open source, and available > from http://opensource.apple.com/ > > Suppose one were to build just enough of a toolchain to be able to > build a MacPort, and provided just that as a binary download, that > would get installed if Xcode wasn't installed. I don't see the benefit. We have always required Xcode be installed. Let's continue to do so, and alert the user about this requirement in the installer if necessary. From jeremy at lavergne.gotdns.org Fri Oct 23 12:44:12 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 23 Oct 2009 15:44:12 -0400 Subject: Port Function to Handle OS Upgrades Message-ID: <1060F5D1-FCB0-4A87-958B-114B0CA7CC47@lavergne.gotdns.org> What are our thoughts on providing a new function to handle preparing for an OS upgrade (or run immediately following)? This procedure would need to: * remove all build directories * trash all irrelevant archives * dump a list of what is installed (either to be read in by another function or simply catted to port) * uninstall everything We can provide two separate functions, really. One, to dump the installed and their variants; another to remove all irrelevant files in the tree. There are many more instances where we can get irrelevant files in the tree, such as upgrades. Perhaps having this function be abstract enough we can use it in both instances would be to our coding advantage. Gentlemen? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4024 bytes Desc: not available URL: From lee at dropio.com Fri Oct 23 12:49:53 2009 From: lee at dropio.com (Lee Azzarello) Date: Fri, 23 Oct 2009 15:49:53 -0400 Subject: Dependency on developer tools In-Reply-To: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> References: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> Message-ID: <16b031c0910231249y178da36cxb57c3dbdc7f4735c@mail.gmail.com> On Fri, Oct 23, 2009 at 3:39 PM, Ryan Schmidt wrote: > > On Oct 23, 2009, at 14:32, Michael Crawford wrote: > > Apple's versions of the GNU toolchain are open source, and available >> from http://opensource.apple.com/ >> >> Suppose one were to build just enough of a toolchain to be able to >> build a MacPort, and provided just that as a binary download, that >> would get installed if Xcode wasn't installed. >> > > I don't see the benefit. We have always required Xcode be installed. Let's > continue to do so, and alert the user about this requirement in the > installer if necessary. > > That would definitely help new users. I do think it would be pretty cool to not require any Xcode stuff as a feature. Personally, I don't care about making OS X applications, I just want to be able to install the same stuff I use on Linux on OS X. -- _______________ Lee Azzarello drop.io staff hacker -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryandesign at macports.org Fri Oct 23 12:53:04 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 23 Oct 2009 14:53:04 -0500 Subject: Port Function to Handle OS Upgrades In-Reply-To: <1060F5D1-FCB0-4A87-958B-114B0CA7CC47@lavergne.gotdns.org> References: <1060F5D1-FCB0-4A87-958B-114B0CA7CC47@lavergne.gotdns.org> Message-ID: <1AB221F9-E2D7-4C38-AA60-797453444754@macports.org> On Oct 23, 2009, at 14:44, Jeremy Lavergne wrote: > What are our thoughts on providing a new function to handle > preparing for an OS upgrade (or run immediately following)? > > This procedure would need to: > * remove all build directories > * trash all irrelevant archives > * dump a list of what is installed (either to be read in by another > function or simply catted to port) > * uninstall everything > > We can provide two separate functions, really. One, to dump the > installed and their variants; another to remove all irrelevant files > in the tree. > > There are many more instances where we can get irrelevant files in > the tree, such as upgrades. Perhaps having this function be > abstract enough we can use it in both instances would be to our > coding advantage. I'm not sure how you define "irrelevant". When we've talked about this problem before, the strategy I wanted to take was: * sudo port install (and upgrade) should record in the registry more info than they currently do: store also the OS version, Xcode version, MacPorts version, build_arch, universal_archs, and any other relevant settings from macports.conf that would influence how the software is built. * sudo port outdated (and upgrade) should take into consideration more than just the epoch, version and revision that they do now: they should definitely consider the OS version, build_arch, and universal_archs (and possibly other variables), and present ports to the user for rebuilding if, e.g., the major OS version changes, or the build_arch changes and the port is not universal, or the universal_archs change and the port is universal. I believe there are already three tickets encompassing parts of the above. We haven't talked about build directories before, but old build directories can cause problems, especially if they were from an older OS. MacPorts has some criteria for when to auto-clean a port -- currently I think it's just if the portfile is newer than the build directory. We should add to that if the OS version, Xcode version, MacPorts version, build_arch, or universal_archs have changed since the build started. This means we would have to record the these variables in the build directory somewhere. Maybe not in the state file; maybe we need a new file to store this. I don't think we have a ticket for this part yet. From talklists at newgeo.com Fri Oct 23 12:53:51 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 23 Oct 2009 12:53:51 -0700 Subject: Port Function to Handle OS Upgrades In-Reply-To: <1060F5D1-FCB0-4A87-958B-114B0CA7CC47@lavergne.gotdns.org> References: <1060F5D1-FCB0-4A87-958B-114B0CA7CC47@lavergne.gotdns.org> Message-ID: Valuable regardless of preparing for an OS upgrade or not. I would see there being times I may want to do any of the below, at any given time, for some reason. Uninstall everything is also a nice one. -- Scott * If you contact me off list replace talklists@ with scott@ * On Oct 23, 2009, at 12:44 PM, Jeremy Lavergne wrote: > What are our thoughts on providing a new function to handle > preparing for an OS upgrade (or run immediately following)? > > This procedure would need to: > * remove all build directories > * trash all irrelevant archives > * dump a list of what is installed (either to be read in by another > function or simply catted to port) > * uninstall everything > > We can provide two separate functions, really. One, to dump the > installed and their variants; another to remove all irrelevant files > in the tree. > > There are many more instances where we can get irrelevant files in > the tree, such as upgrades. Perhaps having this function be > abstract enough we can use it in both instances would be to our > coding advantage. From talklists at newgeo.com Fri Oct 23 12:56:01 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 23 Oct 2009 12:56:01 -0700 Subject: Dependency on developer tools In-Reply-To: <16b031c0910231249y178da36cxb57c3dbdc7f4735c@mail.gmail.com> References: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> <16b031c0910231249y178da36cxb57c3dbdc7f4735c@mail.gmail.com> Message-ID: <9B057E0A-A5E5-4695-97C6-1A92DC1C44CB@newgeo.com> On Oct 23, 2009, at 12:49 PM, Lee Azzarello wrote: > On Fri, Oct 23, 2009 at 3:39 PM, Ryan Schmidt > wrote: > >> On Oct 23, 2009, at 14:32, Michael Crawford wrote: >> >> Apple's versions of the GNU toolchain are open source, and available >>> from http://opensource.apple.com/ >>> >>> Suppose one were to build just enough of a toolchain to be able to >>> build a MacPort, and provided just that as a binary download, that >>> would get installed if Xcode wasn't installed. >>> >> >> I don't see the benefit. We have always required Xcode be >> installed. Let's >> continue to do so, and alert the user about this requirement in the >> installer if necessary. >> >> That would definitely help new users. I do think it would be pretty >> cool to > > not require any Xcode stuff as a feature. Personally, I don't care > about > making OS X applications, I just want to be able to install the same > stuff I > use on Linux on OS X. And unless I am totally off my mark, you need Developer Tools to do so. Sure, you do not need all the "junk" they pass along with it, but you do at least, need a compiler, which you are not getting without dev tools installed. Am I mistaken on this interpretation? -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Fri Oct 23 12:56:55 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 23 Oct 2009 14:56:55 -0500 Subject: Dependency on developer tools In-Reply-To: <16b031c0910231249y178da36cxb57c3dbdc7f4735c@mail.gmail.com> References: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> <16b031c0910231249y178da36cxb57c3dbdc7f4735c@mail.gmail.com> Message-ID: <66F10C73-D800-4821-8E1C-C5AE2123DAD5@macports.org> On Oct 23, 2009, at 14:49, Lee Azzarello wrote: > On Fri, Oct 23, 2009 at 3:39 PM, Ryan Schmidt wrote: > >> On Oct 23, 2009, at 14:32, Michael Crawford wrote: >> >>> Apple's versions of the GNU toolchain are open source, and available >>> from http://opensource.apple.com/ FYI, we have ports for Apple's gcc versions, if you really want to build them yourself (apple-gcc33, apple-gcc40, apple-gcc42). >>> Suppose one were to build just enough of a toolchain to be able to >>> build a MacPort, and provided just that as a binary download, that >>> would get installed if Xcode wasn't installed. >> >> I don't see the benefit. We have always required Xcode be >> installed. Let's continue to do so, and alert the user about this >> requirement in the installer if necessary. > > That would definitely help new users. I do think it would be pretty > cool to not require any Xcode stuff as a feature. Personally, I > don't care about making OS X applications, I just want to be able to > install the same stuff I use on Linux on OS X. We don't have the manpower at this point to adequately support all the variations we already claim to support: most port maintainers have only one Mac, running either Snow Leopard or Leopard. Tiger users are technically unsupported, and this situation gets worse as fewer and fewer people test anything on Tiger anymore and port updates unintentionally break Tiger. PowerPC users are technically supported, but as more and more maintainers and developers use Intel Macs, more and more PowerPC bugs are slipping in unnoticed. The point is we don't want to introduce yet another variable into the testing matrix. We want users to build the same way maintainers tested. That means Xcode. From ryandesign at macports.org Fri Oct 23 12:58:49 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 23 Oct 2009 14:58:49 -0500 Subject: Port Function to Handle OS Upgrades In-Reply-To: References: <1060F5D1-FCB0-4A87-958B-114B0CA7CC47@lavergne.gotdns.org> Message-ID: <7F8078D6-71D1-4E8B-8CD2-56EDE5B879D7@macports.org> On Oct 23, 2009, at 14:53, Scott Haneda wrote: > Valuable regardless of preparing for an OS upgrade or not. I would > see there being times I may want to do any of the below, at any > given time, for some reason. > > Uninstall everything is also a nice one. Well, you already can. >> * remove all build directories sudo port clean all >> * trash all irrelevant archives Define irrelevant. >> * dump a list of what is installed (either to be read in by another >> function or simply catted to port) port installed > myports.txt >> * uninstall everything sudo port -f uninstall installed From talklists at newgeo.com Fri Oct 23 13:00:01 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 23 Oct 2009 13:00:01 -0700 Subject: Dependency on developer tools In-Reply-To: <66F10C73-D800-4821-8E1C-C5AE2123DAD5@macports.org> References: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> <16b031c0910231249y178da36cxb57c3dbdc7f4735c@mail.gmail.com> <66F10C73-D800-4821-8E1C-C5AE2123DAD5@macports.org> Message-ID: You just saddened me as I run multiple PPC servers :) Do you have stats? I would be willing to wager there is a disproportionate amount of users that are on PPC using MacPorts. I will bring this up also on the off list thread about Web site changes, as with a little plugging in of Analytics, or running the logs, we can find out exactly what the breakdown is, based on browser and OS. -- Scott * If you contact me off list replace talklists@ with scott@ * On Oct 23, 2009, at 12:56 PM, Ryan Schmidt wrote: > We don't have the manpower at this point to adequately support all > the variations we already claim to support: most port maintainers > have only one Mac, running either Snow Leopard or Leopard. Tiger > users are technically unsupported, and this situation gets worse as > fewer and fewer people test anything on Tiger anymore and port > updates unintentionally break Tiger. PowerPC users are technically > supported, but as more and more maintainers and developers use Intel > Macs, more and more PowerPC bugs are slipping in unnoticed. The > point is we don't want to introduce yet another variable into the > testing matrix. We want users to build the same way maintainers > tested. That means Xcode. From talklists at newgeo.com Fri Oct 23 13:01:59 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 23 Oct 2009 13:01:59 -0700 Subject: Port Function to Handle OS Upgrades In-Reply-To: <7F8078D6-71D1-4E8B-8CD2-56EDE5B879D7@macports.org> References: <1060F5D1-FCB0-4A87-958B-114B0CA7CC47@lavergne.gotdns.org> <7F8078D6-71D1-4E8B-8CD2-56EDE5B879D7@macports.org> Message-ID: <97E84048-38D8-4A5E-B139-19857F04D61E@newgeo.com> On Oct 23, 2009, at 12:58 PM, Ryan Schmidt wrote: > On Oct 23, 2009, at 14:53, Scott Haneda wrote: > >> Valuable regardless of preparing for an OS upgrade or not. I would >> see there being times I may want to do any of the below, at any >> given time, for some reason. >> >> Uninstall everything is also a nice one. > > Well, you already can. > >>> * remove all build directories > > sudo port clean all > >>> * trash all irrelevant archives > > Define irrelevant. > >>> * dump a list of what is installed (either to be read in by >>> another function or simply catted to port) > > port installed > myports.txt > >>> * uninstall everything > > sudo port -f uninstall installed Well, holy smokes. Am I blind, aside from immersing myself in a rather large man page, where would I have learned this commands? These are each FAQ lines in their own right as far as I can see. I very much think I represent the end user to a degree. Not afraid to read at all, but man pages often times lack examples, which are some of the best ways to learn for me. -- Scott * If you contact me off list replace talklists@ with scott@ * From vince at macports.org Fri Oct 23 13:10:08 2009 From: vince at macports.org (vincent habchi) Date: Fri, 23 Oct 2009 22:10:08 +0200 Subject: Dependency on developer tools In-Reply-To: References: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> <16b031c0910231249y178da36cxb57c3dbdc7f4735c@mail.gmail.com> <66F10C73-D800-4821-8E1C-C5AE2123DAD5@macports.org> Message-ID: Le 23 oct. 2009 ? 22:00, Scott Haneda a ?crit : > You just saddened me as I run multiple PPC servers :) > Do you have stats? I would be willing to wager there is a > disproportionate amount of users that are on PPC using MacPorts. I've seized an old G5 that will be used as a file/mail server at work. I'll probably install MacPorts on it and test some Ports with the ppc64 arch. Vincent From ryandesign at macports.org Fri Oct 23 13:11:35 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 23 Oct 2009 15:11:35 -0500 Subject: Dependency on developer tools In-Reply-To: References: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> <16b031c0910231249y178da36cxb57c3dbdc7f4735c@mail.gmail.com> <66F10C73-D800-4821-8E1C-C5AE2123DAD5@macports.org> Message-ID: <1F0E3B6F-806D-4EF0-9BDA-B830B175A4FB@macports.org> On Oct 23, 2009, at 15:00, Scott Haneda wrote: > You just saddened me as I run multiple PPC servers :) I understand, and I am on your side. I want to support older systems. But we appear to be in the minority. > Do you have stats? I have no stats. I am recalling the recent situation with glib2: as of MacPorts 1.8.0, the "-arch" flag is passed along to every port. But glib2's behavior was such that if any "-arch" flag appears -- even just one -- it assumes you're building universal. This is clearly a ludicrous assumption, but until now the developers apparently did not encounter a situation where it was not true. If you pass only a single "-arch" flag, as MacPorts now does when not building universal, this somehow had the effect of making glib2 assume it was on Intel, always, regardless of what arch you actually passed. glib2 would install successfully, but any port that needed glib2, like say gtk2, would fail to build, with a weird message. It took over a month and hundreds of lines of patches and scripts to fix glib2. Other ports may have similar as-yet-undiscovered issues. > I would be willing to wager there is a disproportionate amount of > users that are on PPC using MacPorts. I don't doubt that there are still Mac users with PowerPC Macs using MacPorts. But I am contending that the number of software developers and port maintainers with PowerPC Macs is decreasing, meaning developers and maintainers are more likely to introduce PowerPC-only bugs that go undetected. > I will bring this up also on the off list thread about Web site > changes, as with a little plugging in of Analytics, or running the > logs, we can find out exactly what the breakdown is, based on > browser and OS. Sure, web site analysis could be interesting. I also once suggested that MacPorts should send stats about what got installed up to our server so we can tell what ports are popular, and also what kinds of systems people are running them on. But this was seen as "phoning home" and an invasion of privacy. It could be an opt- in feature, but I thought this would make it less useful. From ryandesign at macports.org Fri Oct 23 13:13:29 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 23 Oct 2009 15:13:29 -0500 Subject: Port Function to Handle OS Upgrades In-Reply-To: <97E84048-38D8-4A5E-B139-19857F04D61E@newgeo.com> References: <1060F5D1-FCB0-4A87-958B-114B0CA7CC47@lavergne.gotdns.org> <7F8078D6-71D1-4E8B-8CD2-56EDE5B879D7@macports.org> <97E84048-38D8-4A5E-B139-19857F04D61E@newgeo.com> Message-ID: <187A2158-ACDD-4AFA-85EB-4928AD4D9DF9@macports.org> On Oct 23, 2009, at 15:01, Scott Haneda wrote: > On Oct 23, 2009, at 12:58 PM, Ryan Schmidt wrote: > >> On Oct 23, 2009, at 14:53, Scott Haneda wrote: >> >>> Valuable regardless of preparing for an OS upgrade or not. I >>> would see there being times I may want to do any of the below, at >>> any given time, for some reason. >>> >>> Uninstall everything is also a nice one. >> >> Well, you already can. >> >>>> * remove all build directories >> >> sudo port clean all >> >>>> * trash all irrelevant archives >> >> Define irrelevant. >> >>>> * dump a list of what is installed (either to be read in by >>>> another function or simply catted to port) >> >> port installed > myports.txt >> >>>> * uninstall everything >> >> sudo port -f uninstall installed > > Well, holy smokes. Am I blind, aside from immersing myself in a > rather large man page, where would I have learned this commands? > These are each FAQ lines in their own right as far as I can see. I > very much think I represent the end user to a degree. Not afraid to > read at all, but man pages often times lack examples, which are some > of the best ways to learn for me. The three examples above came from the Migration page. http://trac.macports.org/wiki/Migration It's often hard for us old-timers to see where documentation is lacking, since we already have it in our heads. You can of course write FAQ entries yourself, since it's in the wiki. If you have documentation or man page suggestions, please file tickets. From howarth at bromo.med.uc.edu Fri Oct 23 13:14:55 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Fri, 23 Oct 2009 16:14:55 -0400 Subject: Dependency on developer tools In-Reply-To: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> References: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> Message-ID: <20091023201455.GA14028@bromo.med.uc.edu> On Fri, Oct 23, 2009 at 02:39:38PM -0500, Ryan Schmidt wrote: > > On Oct 23, 2009, at 14:32, Michael Crawford wrote: > >> Apple's versions of the GNU toolchain are open source, and available >> from http://opensource.apple.com/ >> >> Suppose one were to build just enough of a toolchain to be able to >> build a MacPort, and provided just that as a binary download, that >> would get installed if Xcode wasn't installed. > > I don't see the benefit. We have always required Xcode be installed. > Let's continue to do so, and alert the user about this requirement in > the installer if necessary. > > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev I know in fink, if one does a clean install that blows away the Xcode installation, when the installed fink is executed it does a check for a system compiler and throws an error that Xcode needs to be installed if it doesn't find one. Something like that would be fine. Trying to maintain a separate toolchain using Apple's open source releases seems to be asking for trouble since it assumes that the open source tool chain releases are throughly tested in that configuration (outside of the Xcode installation). Jack From jeremy at lavergne.gotdns.org Fri Oct 23 13:14:43 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 23 Oct 2009 16:14:43 -0400 Subject: Port Function to Handle OS Upgrades In-Reply-To: <97E84048-38D8-4A5E-B139-19857F04D61E@newgeo.com> References: <1060F5D1-FCB0-4A87-958B-114B0CA7CC47@lavergne.gotdns.org> <7F8078D6-71D1-4E8B-8CD2-56EDE5B879D7@macports.org> <97E84048-38D8-4A5E-B139-19857F04D61E@newgeo.com> Message-ID: <78994C8A-B724-4B18-A7A3-C4B1A0F0AF97@lavergne.gotdns.org> >>>> * remove all build directories >> >> sudo port clean all Far inferior to sudo rm -rf ${prefix}/var/macports/build >>>> * trash all irrelevant archives >> >> Define irrelevant. Not supposed by this architecture or OS version or simply outdated/ replaced by a newer version. >>>> * dump a list of what is installed (either to be read in by >>>> another function or simply catted to port) >> >> port installed > myports.txt What's with all this "active" stuff listed after it getting in the way of ports parsing that? >_> >> >>>> * uninstall everything >> >> sudo port -f uninstall installed Again, sudo rm -rf $prefix is faster. Especially on a G4/G5. The point being one step to do all this, not "how do I do all this individually and have to tell every users to do this list of steps when they're upgrading" > Well, holy smokes. Am I blind, aside from immersing myself in a > rather large man page, where would I have learned this commands? Just irrelevant to the conversation. > These are each FAQ lines in their own right as far as I can see. I > very much think I represent the end user to a degree. Not afraid to > read at all, but man pages often times lack examples, which are some > of the best ways to learn for me. I'd disagree as I've had to help far too many and deal with far too many tickets that should have dealt with be a knowledgeable user. Most didn't even read the Migration page. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4024 bytes Desc: not available URL: From lee at dropio.com Fri Oct 23 13:17:44 2009 From: lee at dropio.com (Lee Azzarello) Date: Fri, 23 Oct 2009 16:17:44 -0400 Subject: Dependency on developer tools In-Reply-To: <1F0E3B6F-806D-4EF0-9BDA-B830B175A4FB@macports.org> References: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> <16b031c0910231249y178da36cxb57c3dbdc7f4735c@mail.gmail.com> <66F10C73-D800-4821-8E1C-C5AE2123DAD5@macports.org> <1F0E3B6F-806D-4EF0-9BDA-B830B175A4FB@macports.org> Message-ID: <16b031c0910231317u27ad381bwdcfa0ac3bba6c89c@mail.gmail.com> On Fri, Oct 23, 2009 at 4:11 PM, Ryan Schmidt wrote: > > I would be willing to wager there is a disproportionate amount of users >> that are on PPC using MacPorts. >> > > I don't doubt that there are still Mac users with PowerPC Macs using > MacPorts. But I am contending that the number of software developers and > port maintainers with PowerPC Macs is decreasing, meaning developers and > maintainers are more likely to introduce PowerPC-only bugs that go > undetected. If this process could be reliably automated, an old G4 in a basement that gets powered on every few months would work as a build box. It would also help to have a packaging policy and a reliable way to report errors. > I also once suggested that MacPorts should send stats about what got > installed up to our server so we can tell what ports are popular, and also > what kinds of systems people are running them on. But this was seen as > "phoning home" and an invasion of privacy. It could be an opt-in feature, > but I thought this would make it less useful. > How about a "popularity contest" port that a user can install optionally to gather stats about installed architectures? -- _______________ Lee Azzarello drop.io staff hacker -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmr at macports.org Fri Oct 23 13:19:24 2009 From: jmr at macports.org (Joshua Root) Date: Sat, 24 Oct 2009 07:19:24 +1100 Subject: Port Function to Handle OS Upgrades In-Reply-To: <1060F5D1-FCB0-4A87-958B-114B0CA7CC47@lavergne.gotdns.org> References: <1060F5D1-FCB0-4A87-958B-114B0CA7CC47@lavergne.gotdns.org> Message-ID: <4AE20FCC.7010805@macports.org> On 2009-10-24 06:44, Jeremy Lavergne wrote: > What are our thoughts on providing a new function to handle preparing > for an OS upgrade (or run immediately following)? > > This procedure would need to: > * remove all build directories > * trash all irrelevant archives > * dump a list of what is installed (either to be read in by another > function or simply catted to port) > * uninstall everything This is all possible already, as has been mentioned. But what is not currently provided is a way to reinstall the ports from the dumped list, in correct dependency order with the right variants. Someone wrote an external script to do this a while back; you should be able to find it in the list archives. - Josh From lee at dropio.com Fri Oct 23 13:20:08 2009 From: lee at dropio.com (Lee Azzarello) Date: Fri, 23 Oct 2009 16:20:08 -0400 Subject: Dependency on developer tools In-Reply-To: References: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> <16b031c0910231249y178da36cxb57c3dbdc7f4735c@mail.gmail.com> <66F10C73-D800-4821-8E1C-C5AE2123DAD5@macports.org> Message-ID: <16b031c0910231320i39fcacf3p18c87b36dbeccf29@mail.gmail.com> On Fri, Oct 23, 2009 at 4:00 PM, Scott Haneda wrote: > You just saddened me as I run multiple PPC servers :) > Do you have stats? I would be willing to wager there is a disproportionate > amount of users that are on PPC using MacPorts. > > I will bring this up also on the off list thread about Web site changes, as > with a little plugging in of Analytics, or running the logs, we can find out > exactly what the breakdown is, based on browser and OS. > -- > Scott * If you contact me off list replace talklists@ with scott@ * > > On Oct 23, 2009, at 12:56 PM, Ryan Schmidt wrote: > > We don't have the manpower at this point to adequately support all the >> variations we already claim to support: most port maintainers have only one >> Mac, running either Snow Leopard or Leopard. Tiger users are technically >> unsupported, and this situation gets worse as fewer and fewer people test >> anything on Tiger anymore and port updates unintentionally break Tiger. >> PowerPC users are technically supported, but as more and more maintainers >> and developers use Intel Macs, more and more PowerPC bugs are slipping in >> unnoticed. The point is we don't want to introduce yet another variable into >> the testing matrix. We want users to build the same way maintainers tested. >> That means Xcode. >> > > I just remembered that I have a PPC mac mini sitting on my desk. It's a paperweight right now :) -- _______________ Lee Azzarello drop.io staff hacker -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryandesign at macports.org Fri Oct 23 13:21:29 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 23 Oct 2009 15:21:29 -0500 Subject: Dependency on developer tools In-Reply-To: <16b031c0910231317u27ad381bwdcfa0ac3bba6c89c@mail.gmail.com> References: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> <16b031c0910231249y178da36cxb57c3dbdc7f4735c@mail.gmail.com> <66F10C73-D800-4821-8E1C-C5AE2123DAD5@macports.org> <1F0E3B6F-806D-4EF0-9BDA-B830B175A4FB@macports.org> <16b031c0910231317u27ad381bwdcfa0ac3bba6c89c@mail.gmail.com> Message-ID: On Oct 23, 2009, at 15:17, Lee Azzarello wrote: > On Fri, Oct 23, 2009 at 4:11 PM, Ryan Schmidt > wrote: > >> I don't doubt that there are still Mac users with PowerPC Macs >> using MacPorts. But I am contending that the number of software >> developers and port maintainers with PowerPC Macs is decreasing, >> meaning developers and maintainers are more likely to introduce >> PowerPC-only bugs that go undetected. > > If this process could be reliably automated, an old G4 in a basement > that gets powered on every few months would work as a build box. That's the somewhat unfinished MacPorts AutoBuild project. > It would also help to have a packaging policy and a reliable way to > report errors. Yes it would. These are goals we have had for a very long time. >> I also once suggested that MacPorts should send stats about what >> got installed up to our server so we can tell what ports are >> popular, and also what kinds of systems people are running them on. >> But this was seen as "phoning home" and an invasion of privacy. It >> could be an opt-in feature, but I thought this would make it less >> useful. > > How about a "popularity contest" port that a user can install > optionally to gather stats about installed architectures? That's funny. :) And I like it. It also solves the problem of how to ask the user if they want it. I was dreading adding interactivity to either the disk image installer or the selfupdate mechanism. Having it all encapsulated within a port is a great idea. From ryandesign at macports.org Fri Oct 23 13:22:16 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 23 Oct 2009 15:22:16 -0500 Subject: Dependency on developer tools In-Reply-To: <20091023201455.GA14028@bromo.med.uc.edu> References: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> <20091023201455.GA14028@bromo.med.uc.edu> Message-ID: <869F8CA2-4AA5-4639-AB66-F45666558C07@macports.org> On Oct 23, 2009, at 15:14, Jack Howarth wrote: > I know in fink, if one does a clean install that blows away the > Xcode installation, when the installed fink is executed it does > a check for a system compiler and throws an error that Xcode > needs to be installed if it doesn't find one. Something like that > would be fine. I agree that would be nice too. That's a variant of this request: http://trac.macports.org/ticket/12794 > Trying to maintain a separate toolchain using > Apple's open source releases seems to be asking for trouble > since it assumes that the open source tool chain releases are > throughly tested in that configuration (outside of the Xcode > installation). Right. From jmr at macports.org Fri Oct 23 13:24:13 2009 From: jmr at macports.org (Joshua Root) Date: Sat, 24 Oct 2009 07:24:13 +1100 Subject: Dependency on developer tools In-Reply-To: References: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> <16b031c0910231249y178da36cxb57c3dbdc7f4735c@mail.gmail.com> <66F10C73-D800-4821-8E1C-C5AE2123DAD5@macports.org> Message-ID: <4AE210ED.40403@macports.org> On 2009-10-24 07:00, Scott Haneda wrote: > You just saddened me as I run multiple PPC servers :) > Do you have stats? I would be willing to wager there is a > disproportionate amount of users that are on PPC using MacPorts. That has no effect on the fact that maintainers can only test on the hardware they have. - Josh From jmr at macports.org Fri Oct 23 13:25:43 2009 From: jmr at macports.org (Joshua Root) Date: Sat, 24 Oct 2009 07:25:43 +1100 Subject: Port Function to Handle OS Upgrades In-Reply-To: <97E84048-38D8-4A5E-B139-19857F04D61E@newgeo.com> References: <1060F5D1-FCB0-4A87-958B-114B0CA7CC47@lavergne.gotdns.org> <7F8078D6-71D1-4E8B-8CD2-56EDE5B879D7@macports.org> <97E84048-38D8-4A5E-B139-19857F04D61E@newgeo.com> Message-ID: <4AE21147.4030206@macports.org> On 2009-10-24 07:01, Scott Haneda wrote: > On Oct 23, 2009, at 12:58 PM, Ryan Schmidt wrote: >>>> * remove all build directories >> >> sudo port clean all >> >>>> * trash all irrelevant archives >> >> Define irrelevant. >> >>>> * dump a list of what is installed (either to be read in by another >>>> function or simply catted to port) >> >> port installed > myports.txt >> >>>> * uninstall everything >> >> sudo port -f uninstall installed > > > Well, holy smokes. Am I blind, aside from immersing myself in a rather > large man page, where would I have learned this commands? The Migration page on the wiki has all of these specific commands. - Josh From dluke at geeklair.net Fri Oct 23 13:29:24 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Fri, 23 Oct 2009 16:29:24 -0400 Subject: Dependency on developer tools In-Reply-To: <1F0E3B6F-806D-4EF0-9BDA-B830B175A4FB@macports.org> References: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> <16b031c0910231249y178da36cxb57c3dbdc7f4735c@mail.gmail.com> <66F10C73-D800-4821-8E1C-C5AE2123DAD5@macports.org> <1F0E3B6F-806D-4EF0-9BDA-B830B175A4FB@macports.org> Message-ID: <70C1DB05-D50D-4343-9CB4-C7D361B709E1@geeklair.net> On Oct 23, 2009, at 4:11 PM, Ryan Schmidt wrote: > On Oct 23, 2009, at 15:00, Scott Haneda wrote: >> You just saddened me as I run multiple PPC servers :) > > I understand, and I am on your side. I want to support older > systems. But we appear to be in the minority. so support them ... no one is stopping you (or anyone) from testing and generating patches for port maintainers... If there are people interested in it, they are the best ones to make it happen. > I also once suggested that MacPorts should send stats about what got > installed up to our server so we can tell what ports are popular, > and also what kinds of systems people are running them on. But this > was seen as "phoning home" and an invasion of privacy. It could be > an opt-in feature, but I thought this would make it less useful. Maybe it would be less useful, but it would be something to start with (and as opt-in it would hopefully avoid irritating users who for whatever reason did not want to share information about their setup). If we made archives a priority we could just track download stats for the pre-build archives ;-) -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ From ryandesign at macports.org Fri Oct 23 13:29:34 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 23 Oct 2009 15:29:34 -0500 Subject: Port Function to Handle OS Upgrades In-Reply-To: <78994C8A-B724-4B18-A7A3-C4B1A0F0AF97@lavergne.gotdns.org> References: <1060F5D1-FCB0-4A87-958B-114B0CA7CC47@lavergne.gotdns.org> <7F8078D6-71D1-4E8B-8CD2-56EDE5B879D7@macports.org> <97E84048-38D8-4A5E-B139-19857F04D61E@newgeo.com> <78994C8A-B724-4B18-A7A3-C4B1A0F0AF97@lavergne.gotdns.org> Message-ID: <188DE8ED-B4D0-4D00-A0C1-8FF05D63BE74@macports.org> On Oct 23, 2009, at 15:14, Jeremy Lavergne wrote: >>>>> * remove all build directories >>> >>> sudo port clean all > > Far inferior to sudo rm -rf ${prefix}/var/macports/build How is it inferior, aside from being slower? FYI, that wouldn't remove the "work" symlinks in the port directories. That might not be a big deal, but it is a difference. >>>>> * trash all irrelevant archives >>> >>> Define irrelevant. > > Not supposed by this architecture or OS version or simply outdated/ > replaced by a newer version. Ok. I don't know how to do that. I don't use archives. >>>>> * dump a list of what is installed (either to be read in by >>>>> another function or simply catted to port) >>> >>> port installed > myports.txt > > What's with all this "active" stuff listed after it getting in the > way of ports parsing that? >_> I agree, it's not made to be parsed; it's meant to be looked at. >>>>> * uninstall everything >>> >>> sudo port -f uninstall installed > > Again, sudo rm -rf $prefix is faster. Especially on a G4/G5. And totally not the same thing. "sudo port -f uninstall installed" uninstalls your installed ports, while leaving behind MacPorts base itself AND any configuration files or databases you may have created. This is the key difference. We don't want to advocate a command that would cause the user to lose data. Also, note ports are not necessarily contained within ${prefix}. Better let MacPorts uninstall the software correctly from wherever it's installed. > The point being one step to do all this, not "how do I do all this > individually and have to tell every users to do this list of steps > when they're upgrading" Scott asked how to do these steps individually, so I showed him how. >> Well, holy smokes. Am I blind, aside from immersing myself in a >> rather large man page, where would I have learned this commands? > > Just irrelevant to the conversation. > >> These are each FAQ lines in their own right as far as I can see. I >> very much think I represent the end user to a degree. Not afraid >> to read at all, but man pages often times lack examples, which are >> some of the best ways to learn for me. > > I'd disagree as I've had to help far too many and deal with far too > many tickets that should have dealt with be a knowledgeable user. > > Most didn't even read the Migration page. I'm not sure I understand your responses to Scott here. Scott's saying we don't have enough documentation on how to use MacPorts. You're saying users don't read the documentation we do have. Is that right? If that's true, then we either need to publicize the available documentation better, or simplify it so it's more understandable to end users. From talklists at newgeo.com Fri Oct 23 13:30:12 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 23 Oct 2009 13:30:12 -0700 Subject: Dependency on developer tools In-Reply-To: <1F0E3B6F-806D-4EF0-9BDA-B830B175A4FB@macports.org> References: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> <16b031c0910231249y178da36cxb57c3dbdc7f4735c@mail.gmail.com> <66F10C73-D800-4821-8E1C-C5AE2123DAD5@macports.org> <1F0E3B6F-806D-4EF0-9BDA-B830B175A4FB@macports.org> Message-ID: <83249EA2-5100-42E6-9FB1-1EF73674CBC9@newgeo.com> On Oct 23, 2009, at 1:11 PM, Ryan Schmidt wrote: > On Oct 23, 2009, at 15:00, Scott Haneda wrote: > >> You just saddened me as I run multiple PPC servers :) > > I understand, and I am on your side. I want to support older > systems. But we appear to be in the minority. I want to go out and buy all new Intel Xserves, but looking at those prices, and I am looking at Dell, blades, or build your own. Hopefully I can go FreeBSD and at least feel a little at home. I am not looking forward to hardware compatibility issues, that is why I like serving on the Mac, I know that whatever hardware I plug into it, so long as that raid card says it works with OS X, I know it is going to work. As long as we keep on top of the MAMP stack for MacPorts, I suspect at least I can get by. In the end, I feel that developers of the upstream source should still target PPC and make it work. Apple makes their tool chain in a way that it is possible, and I believe even desirable to support PPC. If I was said source developer, I would actually want to fix it, even if zero people ran on PPC, it seems like a bug to me. >> Do you have stats? > > I have no stats. I am recalling the recent situation with glib2: as > of MacPorts 1.8.0, the "-arch" flag is passed along to every port. > But glib2's behavior was such that if any "-arch" flag appears -- > even just one -- it assumes you're building universal. This is > clearly a ludicrous assumption, but until now the developers > apparently did not encounter a situation where it was not true. If > you pass only a single "-arch" flag, as MacPorts now does when not > building universal, this somehow had the effect of making glib2 > assume it was on Intel, always, regardless of what arch you actually > passed. glib2 would install successfully, but any port that needed > glib2, like say gtk2, would fail to build, with a weird message. It > took over a month and hundreds of lines of patches and scripts to > fix glib2. Other ports may have similar as-yet-undiscovered issues. I do not know too much about this, but I do know that glib2 is probably a very widely used C lib, is that not correct? How in the heck was this not noticed ages ago? glib2 probably is in the top 10% of installed dependencies I would imagine. >> I would be willing to wager there is a disproportionate amount of >> users that are on PPC using MacPorts. > > I don't doubt that there are still Mac users with PowerPC Macs using > MacPorts. But I am contending that the number of software developers > and port maintainers with PowerPC Macs is decreasing, meaning > developers and maintainers are more likely to introduce PowerPC-only > bugs that go undetected. Weird. If I ever get around to being a real developer :) I would just assume I had to have access to at least a few machines that I could use as a build farm, so to speak. A G4 on ebay is around 125.00 or so. >> I will bring this up also on the off list thread about Web site >> changes, as with a little plugging in of Analytics, or running the >> logs, we can find out exactly what the breakdown is, based on >> browser and OS. > > Sure, web site analysis could be interesting. More on this in the off list thread... > I also once suggested that MacPorts should send stats about what got > installed up to our server so we can tell what ports are popular, > and also what kinds of systems people are running them on. But this > was seen as "phoning home" and an invasion of privacy. It could be > an opt-in feature, but I thought this would make it less useful. Ok, I can understand that. I think we can get the birds eye view, since the stats will tell us which installer was downloaded. We at the very least, know that there are installers for Snow, Tiger, and Leopard. We know that Snow is all Intel, so the margin of error happens in the pre Snow downloads. Adding those stats in which the user agent of the browsers that hit the url, we should be able to tell it it is PPC or Intel. Would at the least be interesting. Again, I will get pretty deep into this on the other thread. I need to get an overview of what is running on the MP servers, and how it is all set up. Data like this is important, in order to know how to better position the Web site for users. Look forward to being able to help out in an area where I think I am well suited to help out. Have a good weekend. -- Scott * If you contact me off list replace talklists@ with scott@ * From jeremy at lavergne.gotdns.org Fri Oct 23 13:38:53 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 23 Oct 2009 16:38:53 -0400 Subject: Port Function to Handle OS Upgrades In-Reply-To: <188DE8ED-B4D0-4D00-A0C1-8FF05D63BE74@macports.org> References: <1060F5D1-FCB0-4A87-958B-114B0CA7CC47@lavergne.gotdns.org> <7F8078D6-71D1-4E8B-8CD2-56EDE5B879D7@macports.org> <97E84048-38D8-4A5E-B139-19857F04D61E@newgeo.com> <78994C8A-B724-4B18-A7A3-C4B1A0F0AF97@lavergne.gotdns.org> <188DE8ED-B4D0-4D00-A0C1-8FF05D63BE74@macports.org> Message-ID: <90AECFC4-ECA4-4141-AC00-6AF54DCBA642@lavergne.gotdns.org> >>> sudo port clean all >> >> Far inferior to sudo rm -rf ${prefix}/var/macports/build > > How is it inferior, aside from being slower? Well, ports that are removed or have their workdir changed are unaccounted for. They'll be perpetually left behind by any index-fed commands. >>> sudo port -f uninstall installed >> >> Again, sudo rm -rf $prefix is faster. Especially on a G4/G5. > > And totally not the same thing. "sudo port -f uninstall installed" > uninstalls your installed ports, while leaving behind MacPorts base > itself AND any configuration files or databases you may have > created. This is the key difference. We don't want to advocate a > command that would cause the user to lose data. That's a good point. So we need to mitigate files being lost forever during an upgrade ... lest they be left int he tree forever. > Also, note ports are not necessarily contained within ${prefix}. > Better let MacPorts uninstall the software correctly from wherever > it's installed. Yes, yes. Harped on the speed thing and ignored this whole aspect. >> The point being one step to do all this, not "how do I do all this >> individually and have to tell every users to do this list of steps >> when they're upgrading" > > Scott asked how to do these steps individually, so I showed him how. Rinse lather and repeat for a few thousand users. > Scott's saying we don't have enough documentation on how to use > MacPorts. You're saying users don't read the documentation we do > have. Is that right? If that's true, then we either need to > publicize the available documentation better, or simplify it so it's > more understandable to end users. I'm neutral on us having enough documentation, but I definitely know what we do have documented doesn't get read by the majority of the user base. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4024 bytes Desc: not available URL: From jeremy at lavergne.gotdns.org Fri Oct 23 13:41:12 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 23 Oct 2009 16:41:12 -0400 Subject: Port Function to Handle OS Upgrades In-Reply-To: <188DE8ED-B4D0-4D00-A0C1-8FF05D63BE74@macports.org> References: <1060F5D1-FCB0-4A87-958B-114B0CA7CC47@lavergne.gotdns.org> <7F8078D6-71D1-4E8B-8CD2-56EDE5B879D7@macports.org> <97E84048-38D8-4A5E-B139-19857F04D61E@newgeo.com> <78994C8A-B724-4B18-A7A3-C4B1A0F0AF97@lavergne.gotdns.org> <188DE8ED-B4D0-4D00-A0C1-8FF05D63BE74@macports.org> Message-ID: <409D9732-054D-4918-89DD-AAA93D72D7FC@lavergne.gotdns.org> My biggest beefs are: * everything has to be done in 5 steps * you have to know what those 5 steps are (we're STILL updating them to make them accurate, so clearly getting them from one place hasn't been an applicable answer) * files that are left behind between upgrades and archives built for other architectures become orphaned within the tree -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4024 bytes Desc: not available URL: From mdcrawford at gmail.com Fri Oct 23 13:48:51 2009 From: mdcrawford at gmail.com (Michael Crawford) Date: Fri, 23 Oct 2009 13:48:51 -0700 Subject: Dependency on developer tools In-Reply-To: <4AE210ED.40403@macports.org> References: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> <16b031c0910231249y178da36cxb57c3dbdc7f4735c@mail.gmail.com> <66F10C73-D800-4821-8E1C-C5AE2123DAD5@macports.org> <4AE210ED.40403@macports.org> Message-ID: On Fri, Oct 23, 2009 at 1:24 PM, Joshua Root wrote: > On 2009-10-24 07:00, Scott Haneda wrote: >> You just saddened me as I run multiple PPC servers :) >> Do you have stats? ?I would be willing to wager there is a >> disproportionate amount of users that are on PPC using MacPorts. > > That has no effect on the fact that maintainers can only test on the > hardware they have. A workaround for that is to test PPC under Rosetta. It's not a perfect test but it would be sufficient for most purposes. If one builds Universal, perhaps there could be some automated way to set up a test that would use Rosetta for everything. One solution would be to use the find command to run lipo on all the executables, to delete all the Intel code, leaving just PowerPC. Mike -- Michael David Crawford mdcrawford at gmail dot com GoingWare's Bag of Programming Tricks http://www.goingware.com/tips/ From ryandesign at macports.org Fri Oct 23 13:53:49 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 23 Oct 2009 15:53:49 -0500 Subject: Dependency on developer tools In-Reply-To: References: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> <16b031c0910231249y178da36cxb57c3dbdc7f4735c@mail.gmail.com> <66F10C73-D800-4821-8E1C-C5AE2123DAD5@macports.org> <4AE210ED.40403@macports.org> Message-ID: On Oct 23, 2009, at 15:48, Michael Crawford wrote: > On Fri, Oct 23, 2009 at 1:24 PM, Joshua Root wrote: >> On 2009-10-24 07:00, Scott Haneda wrote: >>> You just saddened me as I run multiple PPC servers :) >>> Do you have stats? I would be willing to wager there is a >>> disproportionate amount of users that are on PPC using MacPorts. >> >> That has no effect on the fact that maintainers can only test on the >> hardware they have. > > A workaround for that is to test PPC under Rosetta. It's not a > perfect test but it would be sufficient for most purposes. > > If one builds Universal, perhaps there could be some automated way to > set up a test that would use Rosetta for everything. One solution > would be to use the find command to run lipo on all the executables, > to delete all the Intel code, leaving just PowerPC. Building universal, or cross-compiling, is pretty different from compiling on the actual machine. I wouldn't advocate this as a way to test PowerPC. From talklists at newgeo.com Fri Oct 23 14:56:16 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 23 Oct 2009 14:56:16 -0700 Subject: Dependency on developer tools In-Reply-To: References: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> <16b031c0910231249y178da36cxb57c3dbdc7f4735c@mail.gmail.com> <66F10C73-D800-4821-8E1C-C5AE2123DAD5@macports.org> <1F0E3B6F-806D-4EF0-9BDA-B830B175A4FB@macports.org> <16b031c0910231317u27ad381bwdcfa0ac3bba6c89c@mail.gmail.com> Message-ID: <755A1659-C0FC-4164-BDBD-4F092317E970@newgeo.com> On Oct 23, 2009, at 1:21 PM, Ryan Schmidt wrote: > On Oct 23, 2009, at 15:17, Lee Azzarello wrote: > >> On Fri, Oct 23, 2009 at 4:11 PM, Ryan Schmidt > > wrote: >> >>> I also once suggested that MacPorts should send stats about what >>> got installed up to our server so we can tell what ports are >>> popular, and also what kinds of systems people are running them >>> on. But this was seen as "phoning home" and an invasion of >>> privacy. It could be an opt-in feature, but I thought this would >>> make it less useful. >> >> How about a "popularity contest" port that a user can install >> optionally to gather stats about installed architectures? > > That's funny. :) And I like it. It also solves the problem of how to > ask the user if they want it. I was dreading adding interactivity to > either the disk image installer or the selfupdate mechanism. Having > it all encapsulated within a port is a great idea. I love this, for just how amazingly simple it would be to support the backend of the data collection. If no one minds, I would like to open a ticket, or be pointed to one, that shows the data that would be desirable to collect. I am thinking, OS version, architecture, MP version, and installed ports along with their versions. I suppose inactive ports may be nice, but I am not sure, I have a lot hanging around from upgrades, that I have just been too lazy to remove, so to me, those are just noise. -- Scott * If you contact me off list replace talklists@ with scott@ * From mark at dxradio.demon.co.uk Fri Oct 23 16:43:32 2009 From: mark at dxradio.demon.co.uk (Mark Hattam) Date: Sat, 24 Oct 2009 00:43:32 +0100 Subject: Port Function to Handle OS Upgrades In-Reply-To: <188DE8ED-B4D0-4D00-A0C1-8FF05D63BE74@macports.org> References: <1060F5D1-FCB0-4A87-958B-114B0CA7CC47@lavergne.gotdns.org> <7F8078D6-71D1-4E8B-8CD2-56EDE5B879D7@macports.org> <97E84048-38D8-4A5E-B139-19857F04D61E@newgeo.com> <78994C8A-B724-4B18-A7A3-C4B1A0F0AF97@lavergne.gotdns.org> <188DE8ED-B4D0-4D00-A0C1-8FF05D63BE74@macports.org> Message-ID: <8FF6A57C-F9B8-47B0-8C9A-A337BF6FDC1D@dxradio.demon.co.uk> On 23 Oct 2009, at 21:29, Ryan Schmidt wrote: >> >>> These are each FAQ lines in their own right as far as I can see. >>> I very much think I represent the end user to a degree. Not >>> afraid to read at all, but man pages often times lack examples, >>> which are some of the best ways to learn for me. >> >> I'd disagree as I've had to help far too many and deal with far too >> many tickets that should have dealt with be a knowledgeable user. >> >> Most didn't even read the Migration page. > > > I'm not sure I understand your responses to Scott here. > > Scott's saying we don't have enough documentation on how to use > MacPorts. You're saying users don't read the documentation we do > have. Is that right? If that's true, then we either need to > publicise the available documentation better, or simplify it so it's > more understandable to end users. Goes back to the website issue ... start at http://www.macports.org try and find quickly the procedures involved in going from a working MacPorts on 10.5 to 10.6 There's no search facility. The "Home" page doesn't link directly to what is effectively a "hot issue" The "Installing MacPorts" deals with new installs and upgrading those installs The "Available Ports" doesn't deal (obvious really) The "Documentation" (which goes to guide.macports.org) doesn't deal with migrating The "Support and Development" (which goes to trac.macports.org) does have a "migration" link ... YIPPEE The "Contact Us" again isn't designed to deal ... but does a link to "Problems hotlist" ... but "migration" isn't covered there. The "News" page doesn't have a link to Migration, yet surely osx 10.6 release would have counted as some sort of news if only to give an opportunity for a "migration" link. Also, you tend to have to know that "migration" is the keyword to look out for. Googling something like macports 10.6 upgrade doesn't find any hits on macports.org apart from tickets for things that didn't work. Oh and while we're there ... what's the "Download" link do at the top right of the pages? When you're already on the http://www.macports.org/install.php page, it just sends you to the same page. Mark From jeremy at lavergne.gotdns.org Fri Oct 23 17:00:43 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Fri, 23 Oct 2009 20:00:43 -0400 Subject: Port Function to Handle OS Upgrades In-Reply-To: <8FF6A57C-F9B8-47B0-8C9A-A337BF6FDC1D@dxradio.demon.co.uk> References: <1060F5D1-FCB0-4A87-958B-114B0CA7CC47@lavergne.gotdns.org> <7F8078D6-71D1-4E8B-8CD2-56EDE5B879D7@macports.org> <97E84048-38D8-4A5E-B139-19857F04D61E@newgeo.com> <78994C8A-B724-4B18-A7A3-C4B1A0F0AF97@lavergne.gotdns.org> <188DE8ED-B4D0-4D00-A0C1-8FF05D63BE74@macports.org> <8FF6A57C-F9B8-47B0-8C9A-A337BF6FDC1D@dxradio.demon.co.uk> Message-ID: <362AF76A-82A9-48FE-B1A0-DB76DCDE543F@lavergne.gotdns.org> > Goes back to the website issue ... > start at http://www.macports.org > > try and find quickly the procedures involved in going from a working > MacPorts on 10.5 to 10.6 > > There's no search facility. > > The "Home" page doesn't link directly to what is effectively a "hot > issue" > The "Installing MacPorts" deals with new installs and upgrading > those installs > The "Available Ports" doesn't deal (obvious really) > The "Documentation" (which goes to guide.macports.org) doesn't deal > with migrating > The "Support and Development" (which goes to trac.macports.org) does > have a "migration" link ... YIPPEE > The "Contact Us" again isn't designed to deal ... but does a link to > "Problems hotlist" ... but "migration" isn't covered there. > The "News" page doesn't have a link to Migration, yet surely osx > 10.6 release would have counted as some sort of news if only to give > an opportunity for a "migration" link. > > Also, you tend to have to know that "migration" is the keyword to > look out for. We need to setup a good structure for our site: we know where we've been, and we know what we have to offer. Does our site reflect these or is it a dead skeleton that needs replaced? Just appoint a person or two to figure out how we want it organized and then others can throw in design ideas and more from there. > Googling something like macports 10.6 upgrade > doesn't find any hits on macports.org apart from tickets for things > that didn't work. As for the download, it would likely be handy to have a download page like so many open source projects: the download link goes to a page with a big download button. There's another link to the requirements. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4024 bytes Desc: not available URL: From ryandesign at macports.org Fri Oct 23 17:30:05 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 23 Oct 2009 19:30:05 -0500 Subject: Dependency on developer tools In-Reply-To: <755A1659-C0FC-4164-BDBD-4F092317E970@newgeo.com> References: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> <16b031c0910231249y178da36cxb57c3dbdc7f4735c@mail.gmail.com> <66F10C73-D800-4821-8E1C-C5AE2123DAD5@macports.org> <1F0E3B6F-806D-4EF0-9BDA-B830B175A4FB@macports.org> <16b031c0910231317u27ad381bwdcfa0ac3bba6c89c@mail.gmail.com> <755A1659-C0FC-4164-BDBD-4F092317E970@newgeo.com> Message-ID: On Oct 23, 2009, at 16:56, Scott Haneda wrote: > On Oct 23, 2009, at 1:21 PM, Ryan Schmidt wrote: > >> On Oct 23, 2009, at 15:17, Lee Azzarello wrote: >> >>> On Fri, Oct 23, 2009 at 4:11 PM, Ryan Schmidt wrote: >>> >>>> I also once suggested that MacPorts should send stats about what >>>> got installed up to our server so we can tell what ports are >>>> popular, and also what kinds of systems people are running them >>>> on. But this was seen as "phoning home" and an invasion of >>>> privacy. It could be an opt-in feature, but I thought this would >>>> make it less useful. >>> >>> How about a "popularity contest" port that a user can install >>> optionally to gather stats about installed architectures? >> >> That's funny. :) And I like it. It also solves the problem of how >> to ask the user if they want it. I was dreading adding >> interactivity to either the disk image installer or the selfupdate >> mechanism. Having it all encapsulated within a port is a great idea. > > I love this, for just how amazingly simple it would be to support > the backend of the data collection. If no one minds, I would like > to open a ticket, or be pointed to one, that shows the data that > would be desirable to collect. > > I am thinking, OS version, architecture, MP version, and installed > ports along with their versions. I suppose inactive ports may be > nice, but I am not sure, I have a lot hanging around from upgrades, > that I have just been too lazy to remove, so to me, those are just > noise. Actually maybe just a setting in macports.conf is more appropriate. After all this feature will probably need to be closely integrated into MacPorts base. Assuming we do it this way, and if the user has enabled the setting in macports.conf, I would want MacPorts to submit information about installed ports automatically anytime it changes (port install, port uninstall). There would have to be a unique MacPorts install ID assigned to each installation, so that we avoid duplicates being submitted. There would have to be accommodation for transmitting the whole list of installed ports, to initially seed the database, and to transmit just individual ports that have been installed or uninstalled, and to not lose track of changes made while the network is unavailable. I would want to track the user's current Mac OS X, Xcode and MacPorts versions, and for each installed port, its epoch, version, revision, variants, build_arch, universal_archs. Of course, we don't currently track build_arch and universal_archs for each installed port, though we really need to. From mdcrawford at gmail.com Fri Oct 23 17:44:36 2009 From: mdcrawford at gmail.com (Michael Crawford) Date: Fri, 23 Oct 2009 17:44:36 -0700 Subject: Dependency on developer tools In-Reply-To: References: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> <16b031c0910231249y178da36cxb57c3dbdc7f4735c@mail.gmail.com> <66F10C73-D800-4821-8E1C-C5AE2123DAD5@macports.org> <1F0E3B6F-806D-4EF0-9BDA-B830B175A4FB@macports.org> <16b031c0910231317u27ad381bwdcfa0ac3bba6c89c@mail.gmail.com> <755A1659-C0FC-4164-BDBD-4F092317E970@newgeo.com> Message-ID: On Fri, Oct 23, 2009 at 5:30 PM, Ryan Schmidt wrote: > I would want to track the user's current Mac OS X, Xcode and MacPorts > versions, and for each installed port, its epoch, version, revision, > variants, build_arch, universal_archs. Of course, we don't currently track > build_arch and universal_archs for each installed port, though we really > need to. Perhaps it would be useful to use an AppleScript to launch System Profiler, then generate and submit a System Profiler report. That would get you extremely detailed information. Some users might feel that it was excessively obtrusive though. Mike -- Michael David Crawford mdcrawford at gmail dot com GoingWare's Bag of Programming Tricks http://www.goingware.com/tips/ From ryandesign at macports.org Fri Oct 23 17:48:16 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Fri, 23 Oct 2009 19:48:16 -0500 Subject: Dependency on developer tools In-Reply-To: References: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> <16b031c0910231249y178da36cxb57c3dbdc7f4735c@mail.gmail.com> <66F10C73-D800-4821-8E1C-C5AE2123DAD5@macports.org> <1F0E3B6F-806D-4EF0-9BDA-B830B175A4FB@macports.org> <16b031c0910231317u27ad381bwdcfa0ac3bba6c89c@mail.gmail.com> <755A1659-C0FC-4164-BDBD-4F092317E970@newgeo.com> Message-ID: <7CC74422-B448-4417-88DD-DDDC7C95E2BE@macports.org> On Oct 23, 2009, at 19:44, Michael Crawford wrote: > On Fri, Oct 23, 2009 at 5:30 PM, Ryan Schmidt wrote: > >> I would want to track the user's current Mac OS X, Xcode and MacPorts >> versions, and for each installed port, its epoch, version, revision, >> variants, build_arch, universal_archs. Of course, we don't >> currently track >> build_arch and universal_archs for each installed port, though we >> really >> need to. > > Perhaps it would be useful to use an AppleScript to launch System > Profiler, then generate and submit a System Profiler report. > > That would get you extremely detailed information. > > Some users might feel that it was excessively obtrusive though. That's far more detail than we need. I just want the OS version, which is easily obtainable with "sw_vers -productVersion", and the Xcode version, which is easily obtainable by using "defaults read /Developer/ Applications/Xcode.app/Contents/Info CFBundleShortVersionString". FYI, System Profiler's information is also easily obtainable from the command line, using the "system_profiler" command; AppleScript is not necessary. From ryandesign at macports.org Sat Oct 24 19:02:54 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 24 Oct 2009 21:02:54 -0500 Subject: [59862] trunk/dports/archivers/zip/Portfile In-Reply-To: <20091025013224.3C6202B85B28@beta.macosforge.org> References: <20091025013224.3C6202B85B28@beta.macosforge.org> Message-ID: <13D661B4-283D-4B7E-AC8A-4BDD723E0C82@macports.org> On Oct 24, 2009, at 20:32, landonf at macports.org wrote: > Revision: 59862 > http://trac.macports.org/changeset/59862 > Author: landonf at macports.org > Date: 2009-10-24 18:32:20 -0700 (Sat, 24 Oct 2009) > Log Message: > ----------- > Fix +universal: > - Update the reinplace regexp to match the current sources > - Work-around base's automake-specific setting of --disable- > dependency-tracking In what way was the universal build broken? I've had zlib installed universal for ages, and rebuilt it again a few days ago, and "lipo - info" shows that libz.dylib is universal. Is what I've got not a proper universal build? If not, how would I know that, and shouldn't we then bump the revision so everyone else who already thought they had a proper universal build gets the real one? From landonf at macports.org Sat Oct 24 20:53:48 2009 From: landonf at macports.org (Landon Fuller) Date: Sat, 24 Oct 2009 20:53:48 -0700 Subject: [59862] trunk/dports/archivers/zip/Portfile In-Reply-To: <13D661B4-283D-4B7E-AC8A-4BDD723E0C82@macports.org> References: <20091025013224.3C6202B85B28@beta.macosforge.org> <13D661B4-283D-4B7E-AC8A-4BDD723E0C82@macports.org> Message-ID: <11B42136-DD20-4E5B-8C2F-D252B0236E31@macports.org> On Oct 24, 2009, at 7:02 PM, Ryan Schmidt wrote: > > On Oct 24, 2009, at 20:32, landonf at macports.org wrote: > >> Revision: 59862 >> http://trac.macports.org/changeset/59862 >> Author: landonf at macports.org >> Date: 2009-10-24 18:32:20 -0700 (Sat, 24 Oct 2009) >> Log Message: >> ----------- >> Fix +universal: >> - Update the reinplace regexp to match the current sources >> - Work-around base's automake-specific setting of --disable- >> dependency-tracking > > In what way was the universal build broken? In the ways I endeavored to list in the commit log. > I've had zlib installed universal for ages, and rebuilt it again a > few days ago, and "lipo -info" shows that libz.dylib is universal. > Is what I've got not a proper universal build? The port is zip, not zlib. -landonf -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From brooks at clarksonline.net Sat Oct 24 21:07:02 2009 From: brooks at clarksonline.net (M. Brooks Clark) Date: Sat, 24 Oct 2009 23:07:02 -0500 Subject: committing updated portfiles Message-ID: <0D670F4C-EFB7-44C4-9787-9A3CCCFD4CCE@clarksonline.net> I submitted updated portfiles for radlib (#22097) and wview (#22099) several days ago. How long does it typically take for them to be committed to the distribution? Is there anything I can do to expedite the process? Just curious as the current versions are hopelessly out of date. Thanks, Brooks http://www.clarkwx.net ________________________ From jeremy at lavergne.gotdns.org Sat Oct 24 21:07:35 2009 From: jeremy at lavergne.gotdns.org (Jeremy Lavergne) Date: Sun, 25 Oct 2009 00:07:35 -0400 Subject: committing updated portfiles In-Reply-To: <0D670F4C-EFB7-44C4-9787-9A3CCCFD4CCE@clarksonline.net> References: <0D670F4C-EFB7-44C4-9787-9A3CCCFD4CCE@clarksonline.net> Message-ID: <2465C388-4523-496F-8748-17EA587B5B28@lavergne.gotdns.org> Messaging here is the way to expedite it :-) On Oct 25, 2009, at 12:07 AM, M. Brooks Clark wrote: > I submitted updated portfiles for radlib (#22097) and wview (#22099) > several days ago. How long does it typically take for them to be > committed to the distribution? > > Is there anything I can do to expedite the process? Just curious as > the current versions are hopelessly out of date. > > > Thanks, > > Brooks > > http://www.clarkwx.net > ________________________ > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4024 bytes Desc: not available URL: From ryandesign at macports.org Sat Oct 24 21:53:45 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sat, 24 Oct 2009 23:53:45 -0500 Subject: [59862] trunk/dports/archivers/zip/Portfile In-Reply-To: <11B42136-DD20-4E5B-8C2F-D252B0236E31@macports.org> References: <20091025013224.3C6202B85B28@beta.macosforge.org> <13D661B4-283D-4B7E-AC8A-4BDD723E0C82@macports.org> <11B42136-DD20-4E5B-8C2F-D252B0236E31@macports.org> Message-ID: On Oct 24, 2009, at 22:53, Landon Fuller wrote: > On Oct 24, 2009, at 7:02 PM, Ryan Schmidt wrote: > >> On Oct 24, 2009, at 20:32, landonf at macports.org wrote: >> >>> Revision: 59862 >>> http://trac.macports.org/changeset/59862 >>> Author: landonf at macports.org >>> Date: 2009-10-24 18:32:20 -0700 (Sat, 24 Oct 2009) >>> Log Message: >>> ----------- >>> Fix +universal: >>> - Update the reinplace regexp to match the current sources >>> - Work-around base's automake-specific setting of --disable- >>> dependency-tracking >> >> In what way was the universal build broken? > > In the ways I endeavored to list in the commit log. > >> I've had zlib installed universal for ages, and rebuilt it again a >> few days ago, and "lipo -info" shows that libz.dylib is universal. >> Is what I've got not a proper universal build? > > The port is zip, not zlib. Thanks. That would be the crux of my misunderstanding. I withdraw the question. :) From afb at macports.org Sun Oct 25 02:02:13 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun, 25 Oct 2009 10:02:13 +0100 Subject: Dependency on developer tools In-Reply-To: References: Message-ID: Scott Haneda wrote: > Looking over the MP website install notes. I see dev tools is > required. > > This bit me once, I stupidly set up a new machine and just forgot > to install dev tools. > > Is there any good reason MP should not stop the installer if it > does not detect a valid dev tool install? > > Seems to me a better end user experience. Only building packages requires the Development Tools... e.g. viewing package information, downloading distfiles, installing archives does *not* require development tools. So it shouldn't be a hard requirement in order to use MP. However, one might want to have the MacPorts Installer (DMG) require Xcode Tools to be installed first - just like it will mangle your PATHs for you and run a "port selfupdate" for you. But it should not be a requirement for the manual base install. --anders From afb at macports.org Sun Oct 25 02:12:13 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun, 25 Oct 2009 10:12:13 +0100 Subject: Dependency on developer tools In-Reply-To: <16b031c0910231225j11c1d0f7r70076e70760b05da@mail.gmail.com> References: <16b031c0910231225j11c1d0f7r70076e70760b05da@mail.gmail.com> Message-ID: <41357C42-1629-47E7-9D41-90FE8B2380D4@macports.org> Lee Azzarello wrote: > Macports does have the option of using the FreeBSD package format > to install binaries, though I don't think macports offers that > option. Correct me if I'm wrong as I'm new to macports. I'm a > Debian GNU/Linux user who supports OS X at work for a development > platform. MacPorts offers similar archive formats to what FreeBSD has, and also with better compression (LZMA) and better metadata (XML). However, it does *not* offer any command to install those - without having to use the regular port(1) command (with the -b option) and having the entire ports tree information available. You can also build PKG or RPM for each port, but if you go that route you need to build such packages for *everything* you want to install - you can't mix source ports and binary packages with MacPorts, they wouldn't be aware of each-others existence and complain on missing deps and file conflicts and such. See http://guide.macports.org/#using.binaries --anders From afb at macports.org Sun Oct 25 02:39:12 2009 From: afb at macports.org (=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?=) Date: Sun, 25 Oct 2009 10:39:12 +0100 Subject: Dependency on developer tools In-Reply-To: <83249EA2-5100-42E6-9FB1-1EF73674CBC9@newgeo.com> References: <46BE937E-E199-4C74-A523-ED8F9C259C13@macports.org> <16b031c0910231249y178da36cxb57c3dbdc7f4735c@mail.gmail.com> <66F10C73-D800-4821-8E1C-C5AE2123DAD5@macports.org> <1F0E3B6F-806D-4EF0-9BDA-B830B175A4FB@macports.org> <83249EA2-5100-42E6-9FB1-1EF73674CBC9@newgeo.com> Message-ID: <497A7E98-C935-46A9-8590-274C59117327@macports.org> Scott Haneda wrote: > On Oct 23, 2009, at 1:11 PM, Ryan Schmidt wrote: > >> I have no stats. I am recalling the recent situation with glib2: >> as of MacPorts 1.8.0, the "-arch" flag is passed along to every >> port. But glib2's behavior was such that if any "-arch" flag >> appears -- even just one -- it assumes you're building universal. >> This is clearly a ludicrous assumption, but until now the >> developers apparently did not encounter a situation where it was >> not true. If you pass only a single "-arch" flag, as MacPorts now >> does when not building universal, this somehow had the effect of >> making glib2 assume it was on Intel, always, regardless of what >> arch you actually passed. glib2 would install successfully, but >> any port that needed glib2, like say gtk2, would fail to build, >> with a weird message. It took over a month and hundreds of lines >> of patches and scripts to fix glib2. Other ports may have similar >> as-yet-undiscovered issues. > > I do not know too much about this, but I do know that glib2 is > probably a very widely used C lib, is that not correct? How in the > heck was this not noticed ages ago? glib2 probably is in the top > 10% of installed dependencies I would imagine. There are a lot of ports failing with the new mandatory -arch flag (from MacPorts 1.8). Not all of them have been upgraded or rebuilt yet, so I don't think we've seen all the failures this caused yet. Similar issues occur with the new parallel build (make -j) default. Before both of these settings were optional, so didn't affect as many ports (and thus users) as now when they are the default. --anders From rmsfisher at macports.org Sun Oct 25 15:37:19 2009 From: rmsfisher at macports.org (Ryan Stonecipher-Fisher) Date: Sun, 25 Oct 2009 17:37:19 -0500 Subject: Port Upgrade vs Loaded Startupitems Message-ID: <6612b2e0910251537yf91190ia3b745c25714f3c3@mail.gmail.com> A port I co-maintain (mpd) includes a startupitem section which I keep loaded using 'launchctl load -w'. Upon updating the port, the old binary is still running in launchd limbo; 'launchctl unload -w' doesn't work properly, so in turn 'launchctl load -w' doesn't work properly either. Are startupitems unloaded during port deactivation? If not, could that step be added to deactivation for ports which do contain startupitems? Ryan Stonecipher-Fisher 573.489.2848 From jmr at macports.org Sun Oct 25 17:49:40 2009 From: jmr at macports.org (Joshua Root) Date: Mon, 26 Oct 2009 11:49:40 +1100 Subject: Port Upgrade vs Loaded Startupitems In-Reply-To: <6612b2e0910251537yf91190ia3b745c25714f3c3@mail.gmail.com> References: <6612b2e0910251537yf91190ia3b745c25714f3c3@mail.gmail.com> Message-ID: <4AE4F224.60300@macports.org> On 2009-10-26 09:37, Ryan Stonecipher-Fisher wrote: > A port I co-maintain (mpd) includes a startupitem section which I keep > loaded using 'launchctl load -w'. > Upon updating the port, the old binary is still running in launchd > limbo; 'launchctl unload -w' doesn't work properly, so in turn > 'launchctl load -w' doesn't work properly either. > Are startupitems unloaded during port deactivation? > If not, could that step be added to deactivation for ports which do > contain startupitems? Sure. As has been mentioned before, the startupitem code needs some love. For bonus points, record both the state of the plist (enabled/disabled) and whether the daemon is actually running (since these aren't necessarily the same), and restore both to their former state after the upgrade completes. - Josh From ryandesign at macports.org Sun Oct 25 20:31:11 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 25 Oct 2009 22:31:11 -0500 Subject: [59742] trunk/dports/devel/dbus/Portfile In-Reply-To: <20091021150143.99AC42ADF7CB@beta.macosforge.org> References: <20091021150143.99AC42ADF7CB@beta.macosforge.org> Message-ID: <69950B40-F960-4567-84AF-68234D7107F5@macports.org> On Oct 21, 2009, at 10:01, jmr at macports.org wrote: > Revision: 59742 > http://trac.macports.org/changeset/59742 > Author: jmr at macports.org > Date: 2009-10-21 08:01:41 -0700 (Wed, 21 Oct 2009) > Log Message: > ----------- > dbus: fix build dependencies (#21654) > > Modified Paths: > -------------- > trunk/dports/devel/dbus/Portfile > > Modified: trunk/dports/devel/dbus/Portfile > =================================================================== > --- trunk/dports/devel/dbus/Portfile 2009-10-21 14:54:49 UTC (rev > 59741) > +++ trunk/dports/devel/dbus/Portfile 2009-10-21 15:01:41 UTC (rev > 59742) > @@ -30,8 +30,6 @@ > 0005-dont-dup-closed-stdin.patch > patch.pre_args -p1 > > -use_autoreconf yes > - > depends_build \ > port:pkgconfig > > @@ -41,6 +39,8 @@ > > depends_lib port:expat > > +use_autoreconf yes > + > configure.args --disable-doxygen-docs \ > --disable-xml-docs \ > --without-x \ I don't understand this change -- it looks like you're justing moving "use_autoreconf yes" to earlier in the portfile, which shouldn't have any measurable effect on how the port functions. How does this fix build dependencies? From ryandesign at macports.org Sun Oct 25 20:34:40 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 25 Oct 2009 22:34:40 -0500 Subject: Port Upgrade vs Loaded Startupitems In-Reply-To: <4AE4F224.60300@macports.org> References: <6612b2e0910251537yf91190ia3b745c25714f3c3@mail.gmail.com> <4AE4F224.60300@macports.org> Message-ID: <224879BE-0242-4296-A6B0-F06123011AFD@macports.org> On Oct 25, 2009, at 19:49, Joshua Root wrote: > On 2009-10-26 09:37, Ryan Stonecipher-Fisher wrote: >> A port I co-maintain (mpd) includes a startupitem section which I >> keep >> loaded using 'launchctl load -w'. >> Upon updating the port, the old binary is still running in launchd >> limbo; 'launchctl unload -w' doesn't work properly, so in turn >> 'launchctl load -w' doesn't work properly either. >> Are startupitems unloaded during port deactivation? >> If not, could that step be added to deactivation for ports which do >> contain startupitems? > > Sure. As has been mentioned before, the startupitem code needs some > love. Would be a good idea. That was half of my motivation for introducing "port load" and "port unload" -- so that we could hook into them at activate and deactivate time. But we never did that. > For bonus points, record both the state of the plist (enabled/ > disabled) > and whether the daemon is actually running (since these aren't > necessarily the same), and restore both to their former state after > the > upgrade completes. Currently, we always install a plist that says the service is stopped. If you had the service running when you upgraded the port, this is now wrong. So we could either keep track of the state, and write the correct state into the new plist when we install it, or we could just ensure the service is always stopped when a port is deactivated -- either by automatically calling port unload, or by telling the user to do so. From jmr at macports.org Sun Oct 25 20:50:17 2009 From: jmr at macports.org (Joshua Root) Date: Mon, 26 Oct 2009 14:50:17 +1100 Subject: [59742] trunk/dports/devel/dbus/Portfile In-Reply-To: <69950B40-F960-4567-84AF-68234D7107F5@macports.org> References: <20091021150143.99AC42ADF7CB@beta.macosforge.org> <69950B40-F960-4567-84AF-68234D7107F5@macports.org> Message-ID: <4AE51C79.8030605@macports.org> On 2009-10-26 14:31, Ryan Schmidt wrote: > I don't understand this change -- it looks like you're justing moving > "use_autoreconf yes" to earlier in the portfile, which shouldn't have > any measurable effect on how the port functions. How does this fix build > dependencies? Later, not earlier. It's after the depends_build now. Changing that to a depends_build-append would also have worked. - Josh From ryandesign at macports.org Sun Oct 25 20:57:11 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Sun, 25 Oct 2009 22:57:11 -0500 Subject: [59742] trunk/dports/devel/dbus/Portfile In-Reply-To: <4AE51C79.8030605@macports.org> References: <20091021150143.99AC42ADF7CB@beta.macosforge.org> <69950B40-F960-4567-84AF-68234D7107F5@macports.org> <4AE51C79.8030605@macports.org> Message-ID: <8626CD7F-4D3C-48BD-9A94-60AD91EF9780@macports.org> On Oct 25, 2009, at 22:50, Joshua Root wrote: > On 2009-10-26 14:31, Ryan Schmidt wrote: >> I don't understand this change -- it looks like you're justing moving >> "use_autoreconf yes" to earlier in the portfile, which shouldn't have >> any measurable effect on how the port functions. How does this fix >> build >> dependencies? > > Later, not earlier. It's after the depends_build now. Changing that > to a > depends_build-append would also have worked. Oh! I totally didn't realize things like use_autoreconf were processed in the order in which they appeared in the portfile. Sometimes it's hard to know, with all the delayed variable expansion and phases and variants and things we have going on. From jkh at apple.com Mon Oct 26 14:29:52 2009 From: jkh at apple.com (Jordan K. Hubbard) Date: Mon, 26 Oct 2009 14:29:52 -0700 Subject: The opendarwin .com debacle In-Reply-To: <19E878EA-684E-445F-9A3F-029FB42F63C2@lavergne.gotdns.org> References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> <799406d60910220838h65d86c40nbe1e8826b3f1c21c@mail.gmail.com> <19E878EA-684E-445F-9A3F-029FB42F63C2@lavergne.gotdns.org> Message-ID: <2404DC4C-DBFC-4B91-A77C-8429B0531387@apple.com> Maybe it's about putting up the appropriate keywords for google to find then? Someone on this list ought to know the tricks... On Oct 22, 2009, at 10:58 AM, Jeremy Lavergne wrote: >> The real problem here is one of branding. Why/where are users even >> hearing the name "darwinports" when it's been essentially dead for >> over 3 years? Projects rename themselves all the time and somehow >> manage to make the name change stick. What this project needs to >> ask itself is why the name change has not stuck as successfully >> here and then fix that problem rather than re-fighting old battles. > > Search for "pspp mac" and you'll find dp.com sitting at #4 or #5. > This demonstrates at least one way people are finding it: searching > for the open source project they want and "mac". In my example, > simply searching for "pspp" will not being up dp.com. > > Macports is nowhere to be found, btw. > From talklists at newgeo.com Mon Oct 26 23:19:07 2009 From: talklists at newgeo.com (Scott Haneda) Date: Mon, 26 Oct 2009 23:19:07 -0700 Subject: Port review of pure-ftpd Message-ID: <1AD4D76E-4748-47E2-9F8C-C9A65944272A@newgeo.com> I ran into an issue with a new configure arg that the devloper added, aside from that, things are going well, and wanted a review of my work if anyone has time. Is there any way, or any desire, to pretty up the long description? for example, the below, I would rather it be: foo has the following features: 1) anti-warez system 2) throttling 3) ratios I suspect you get the idea. I have a hard time getting it to all line up. Is this not even something that the I should be caring about? use_bzip2 yes That was there before I took this portfile over, there is a tgz file, if I just remove that line, would I default to the tgz? distname pure-ftpd-${version} Do I need distname at all in this portfile? My second livecheck, how did I do? I am copying in a sample plist in the post-destroot, any comments on this? All the ui_msg in the port-install, is that the right place? The software only allows one language to be compiled in, but I suspect that MP would allow as many + variants as were listed, is there a way to solve this? Is there any way to order the variants as shown by `port info`, and if not, is it a bad idea to prefix the language variants with a "z" so they do not get in the way of letting people know there is myqsl and tls available for this? I guess I can remove the readme debian and windows files. Thanks for any suggestions. # $Id$ PortSystem 1.0 name pure-ftpd version 1.0.24 categories net platforms darwin maintainers hostwizard.com:scott license BSD homepage http://pureftpd.org/ description Pure-FTPd is a fast, production-quality, standard- conformant FTP (SSL/TLS) server, based upon Troll-FTPd. long_description ${name} has been designed to be secure in default configuration, it has no\ known vulnerabilities. Features Include: virtual domains, built-in 'ls', \ anti-warez system, configurable ports for passive downloads, FXP protocol, \ bandwidth throttling, ratios, LDAP / MySQL / PostgreSQL-based authentication,\ fortune files, Apache-like log files, text / HTML / XML real-time status report,\ virtual users, virtual quotas, privilege separation, SSL/TLS and more. master_sites ftp://ftp.pureftpd.org/pure-ftpd/releases/ \ ftp://ftp.fr.pureftpd.org/pure-ftpd/releases/ distname pure-ftpd-${version} use_bzip2 yes checksums md5 2f0869166ddb3a9cbe5e4887eae6e74d \ sha1 bf8d04d19a83d2bec214eaa38095a070d549d978 \ rmd160 a320048289f22161c370e12a9253f314877903ba livecheck.type regex livecheck.url http://download.pureftpd.org/pub/${name}/releases/ livecheck.regex ${name}-(${version})${extract.suffix} configure.args --with-cookie \ --with-everything \ --with-virtualchroot \ --with-paranoidmsg \ --without-inetd \ --without-capabilities \ --mandir=${prefix}/share/man \ --infodir=${prefix}/share/info \ --with-localstatedir=${prefix} destroot.destdir prefix=${destroot}${prefix} \ mandir=${destroot}${prefix}/share/man post-destroot { file mkdir ${prefix}/etc/${name}/ssl file mkdir ${prefix}/etc/${name}/mysql file mkdir ${prefix}/var/log/${name} file mkdir ${destroot}${prefix}/share/doc/${name} # Install the notes and readme files xinstall -m 644 -v -W ${worksrcpath} \ AUTHORS ChangeLog CONTACT COPYING FAQ HISTORY INSTALL NEWS README \ README.Authentication-Modules README.Windows README.Configuration-File \ README.Contrib README.Debian README.Donations README.LDAP README.MacOS-X \ README.MySQL README.PGSQL README.TLS README.Virtual-Users THANKS \ ${destroot}${prefix}/share/doc/${name} # Copy in the sample launchd plist item file copy ${filespath}/org.pure-ftpd.ftpd.plist.sample $ {destroot}${prefix}/share/doc/${name}/org.pure-ftpd.ftpd.plist.sample } # Notify the user how to launch the ftpd post-install { ui_msg "" ui_msg "PureFTPd documentation is located in: ${prefix}/share/ doc/${name}" ui_msg "" ui_msg "You can start PureFTPd from the command line with:" ui_msg " sudo ${prefix}/sbin/${name} &" ui_msg "" ui_msg "The next release of PureFTPd (1.0.25) will no longer support" ui_msg "xinetd, and has been removed from this version. If you" ui_msg "are using that method to start PureFTPd now, please switch" ui_msg "to using launcd(8)." ui_msg "" ui_msg "A sample launchd plist has been made to get your started," ui_msg "to enable it, issue the following commands:" ui_msg " sudo cp ${prefix}/share/doc/${name}/org.pure- ftpd.ftpd.plist.sample /Library/LaunchDaemons/org.pure-ftpd.ftpd.plist" ui_msg " sudo launchctl load -w /Library/LaunchDaemons/ org.pure-ftpd.ftpd.plist" } variant mysql5 description "Use native MySQL support for privelages database." { depends_lib-append path:bin/mysql_config5:mysql5 configure.args-append --with-mysql configure.cflags-append "-I${prefix}/include/mysql5/mysql" configure.ldflags-append "-L${prefix}/lib/mysql5/mysql" } variant tls description "Encryption of the control channel using SSL/ TLS" { depends_lib lib:libssl.dylib:openssl configure.args-append --with-tls \ --with-certfile=${prefix}/etc/${name}/ ssl/pure-ftpd.pem } # Langugage variants, should only be able to choose one. variant lang_brazilian description "Use Bazilian language for server messages" { configure.args-append --with-language=brazilian } variant lang_czech description "Use Czech language for server messages" { configure.args-append --with-language=czech } variant lang_danish description "Use Danish language for server messages" { configure.args-append --with-language=danish } variant lang_dutch description "Use Dutch language for server messages" { configure.args-append --with-language=dutch } variant lang_french description "Use French language for server messages" { configure.args-append --with-language=french } variant lang_french_funny description "Use French funny language for server messages" { configure.args-append --with-language=french- funny } variant lang_german description "Use German language for server messages" { configure.args-append --with-language=german } variant lang_italian description "Use Italian language for server messages" { configure.args-append --with-language=italian } variant lang_korean description "Use Korean language for server messages" { configure.args-append --with-language=korean } variant lang_norwegian description "Use Norwegian language for server messages" { configure.args-append --with-language=norwegian } variant lang_polish description "Use Polish language for server messages" { configure.args-append --with-language=polish } variant lang_romanian description "Use Romanian language for server messages" { configure.args-append --with-language=romanian } variant lang_russian description "Use Russian language for server messages" { configure.args-append --with-language=russian } variant lang_simpple_chinese description "Use simplified Chinese for server messages" { configure.args-append --with-language=simplified- chinese } variant lang_slovak description "Use Slovak language for server messages" { configure.args-append --with-language=slovak } variant lang_spanish description "Use Spanish language for server messages" { configure.args-append --with-language=spanish } variant lang_swedish description "Use Swedish language for server messages" { configure.args-append --with-language=swedish } variant lang_trad_chinese description "Use traditional Chinese language for server messages" { configure.args-append --with- language=traditional-chinese } -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Tue Oct 27 00:11:20 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 27 Oct 2009 02:11:20 -0500 Subject: [59915] trunk/www/install.php In-Reply-To: <20091027064847.E3FA22C02300@beta.macosforge.org> References: <20091027064847.E3FA22C02300@beta.macosforge.org> Message-ID: <99D8F979-ABA9-46A1-B411-E0CB85B688A1@macports.org> On Oct 27, 2009, at 01:48, toby at macports.org wrote: > Revision: 59915 > http://trac.macports.org/changeset/59915 > Author: toby at macports.org > Date: 2009-10-26 23:48:43 -0700 (Mon, 26 Oct 2009) > Log Message: > ----------- > update Xcode versions But we don't require 3.2.1 or 3.1.4; 3.2 or 3.1 should really be fine, shouldn't they? And on Tiger, 2.4.1 should have been fine too. > Modified Paths: > -------------- > trunk/www/install.php > > Modified: trunk/www/install.php > =================================================================== > --- trunk/www/install.php 2009-10-27 04:28:11 UTC (rev 59914) > +++ trunk/www/install.php 2009-10-27 06:48:43 UTC (rev 59915) > @@ -39,8 +39,8 @@ > components:

> >
    > -
  1. Apple's Xcode Developer Tools (version 3.2 or later for Snow Leopard, > - 3.1 or later for > +
  2. Apple's Xcode Developer Tools (version 3.2.1 or later for Snow Leopard, > + 3.1.4 or later for > Leopard, or 2.5 for Tiger), found at the Apple Developer Connection > site or on your Mac OS X installation CDs/DVD. Ensure > that the optional components for command line development are > installed > ("Unix Development" in the Xcode 3.x installer).
    3. From toby at macports.org Tue Oct 27 00:20:43 2009 From: toby at macports.org (Toby Peterson) Date: Tue, 27 Oct 2009 00:20:43 -0700 Subject: [59915] trunk/www/install.php In-Reply-To: <99D8F979-ABA9-46A1-B411-E0CB85B688A1@macports.org> References: <20091027064847.E3FA22C02300@beta.macosforge.org> <99D8F979-ABA9-46A1-B411-E0CB85B688A1@macports.org> Message-ID: <74c219d30910270020g37c4769fhb5ab3c7e8c65b66a@mail.gmail.com> There's no reason for people to use old version of Xcode, why should we even bother mentioning them? - Toby On Tue, Oct 27, 2009 at 00:11, Ryan Schmidt wrote: > > On Oct 27, 2009, at 01:48, toby at macports.org wrote: > >> Revision: 59915 >> ? ? ? ? http://trac.macports.org/changeset/59915 >> Author: ? toby at macports.org >> Date: ? ? 2009-10-26 23:48:43 -0700 (Mon, 26 Oct 2009) >> Log Message: >> ----------- >> update Xcode versions > > But we don't require 3.2.1 or 3.1.4; 3.2 or 3.1 should really be fine, > shouldn't they? > > And on Tiger, 2.4.1 should have been fine too. > > >> Modified Paths: >> -------------- >> ? trunk/www/install.php >> >> Modified: trunk/www/install.php >> =================================================================== >> --- trunk/www/install.php ? ? ? 2009-10-27 04:28:11 UTC (rev 59914) >> +++ trunk/www/install.php ? ? ? 2009-10-27 06:48:43 UTC (rev 59915) >> @@ -39,8 +39,8 @@ >> ? ? ? ?components:

    >> >> ? ? ? ?
      >> - ? ? ? ? ? ?
    1. Apple's > href="http://developer.apple.com/tools/xcode/">Xcode Developer Tools >> (version 3.2 or later for Snow Leopard, >> - ? ? ? ? ? ?3.1 or later for >> + ? ? ? ? ? ?
    2. Apple's > href="http://developer.apple.com/tools/xcode/">Xcode Developer Tools >> (version 3.2.1 or later for Snow Leopard, >> + ? ? ? ? ? ?3.1.4 or later for >> ? ? ? ? ? ?Leopard, or 2.5 for Tiger), found at the > href="http://connect.apple.com/">Apple Developer Connection >> ? ? ? ? ? ?site or on your Mac OS X installation CDs/DVD. Ensure that the >> optional components for command line development are installed >> ? ? ? ? ? ?("Unix Development" in the Xcode 3.x installer).
      3. > > > From ryandesign at macports.org Tue Oct 27 01:03:14 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 27 Oct 2009 03:03:14 -0500 Subject: Port review of pure-ftpd In-Reply-To: <1AD4D76E-4748-47E2-9F8C-C9A65944272A@newgeo.com> References: <1AD4D76E-4748-47E2-9F8C-C9A65944272A@newgeo.com> Message-ID: <60C202C1-4159-4CA2-A2C7-CDA1AA761140@macports.org> On Oct 27, 2009, at 01:19, Scott Haneda wrote: > I ran into an issue with a new configure arg that the devloper > added, aside from that, things are going well, and wanted a review > of my work if anyone has time. > > Is there any way, or any desire, to pretty up the long description? > for example, the below, I would rather it be: > > foo has the following features: > 1) anti-warez system > 2) throttling > 3) ratios > > I suspect you get the idea. I have a hard time getting it to all > line up. Is this not even something that the I should be caring > about? I am not aware of any way to insert newlines into the long description, or any other way for it to be anything other than a single long block of text. > use_bzip2 yes > That was there before I took this portfile over, there is a tgz > file, if I just remove that line, would I default to the tgz? Yes, the default extract settings assume the extension is ".tar.gz" and that the file should be treated as a gzipped tarball. Since there continues to be a bzip2 distfile available for pureftpd, though, you should prefer that to the tar.gz version, since the bzip2 is smaller. > distname pure-ftpd-${version} > Do I need distname at all in this portfile? The default is ${name}-${version}, so I don't think so. > My second livecheck, how did I do? You cannot use the variable ${version} in the livecheck.regex, otherwise the regex will only match the current version of the port, and will never inform you of newer versions. You want my standard livecheck.regex, which is ${name}-(\[0-9.\]+)\\.tar > I am copying in a sample plist in the post-destroot, any comments on > this? Looks ok. > All the ui_msg in the port-install, is that the right place? You might want the instructions to be post-activate. > The software only allows one language to be compiled in, but I > suspect that MP would allow as many + variants as were listed, is > there a way to solve this? MacPorts has been a bit English-centric so far. In my minivmac portfile, I didn't even attempt to offer options to compile for different languages. I could have offered variants, but nobody has requested it so far, so I haven't worried about it. > Is there any way to order the variants as shown by `port info`, and > if not, is it a bad idea to prefix the language variants with a "z" > so they do not get in the way of letting people know there is myqsl > and tls available for this? The variants used to be listed in the order specified in the portfile. MacPorts 1.8.0 changed this to alphabetical order. I would not recommend using a "z" prefix or anything like that. Prefixing them with "lang_" like you've done is what I would do. As your comment says, you still need to make them conflict with one another. You could construct the variants dynamically, like the swig port does. The below seems to work. Unfortunately it makes the output of "port variants" rather hard to read. # Language name Configure arg set languages { {Brazilian} brazilian {Czech} czech {Danish} danish {Dutch} dutch {French} french {funny French} french-funny {German} german {Italian} italian {Korean} korean {Norwegian} norwegian {Polish} polish {Romanian} romanian {Russian} russian {simplified Chinese} simplified-chinese {Slovak} slovak {Spanish} spanish {Swedish} swedish {traditional Chinese} traditional-chinese } # Add langugage variants foreach {language arg} ${languages} { set variant lang_[strsed ${arg} {g/-/_/}] set conflicts {} foreach {ignore conflicting_arg} ${languages} { if {${conflicting_arg} != ${arg}} { set conflicting_variant lang_[strsed ${conflicting_arg} {g/-/_/}] lappend conflicts ${conflicting_variant} } } eval [subst { variant ${variant} conflicts ${conflicts} description "Use $ {language} language for server messages" { configure.args-append --with-language=${arg} } }] } > I guess I can remove the readme debian and windows files. Please. :) > Thanks for any suggestions. > > # $Id$ > > PortSystem 1.0 > > name pure-ftpd > version 1.0.24 > categories net > platforms darwin > maintainers hostwizard.com:scott > license BSD > > homepage http://pureftpd.org/ > description Pure-FTPd is a fast, production-quality, > standard-conformant FTP (SSL/TLS) Missing backslash at end of the above line. > server, based upon Troll-FTPd. > > long_description ${name} has been designed to be secure in > default configuration, it has no\ > known vulnerabilities. Features Include: virtual > domains, built-in 'ls', \ > anti-warez system, configurable ports for passive > downloads, FXP protocol, \ > bandwidth throttling, ratios, LDAP / MySQL / > PostgreSQL-based authentication,\ > fortune files, Apache-like log files, text / > HTML / XML real-time status report,\ > virtual users, virtual quotas, privilege > separation, SSL/TLS and more. > > master_sites ftp://ftp.pureftpd.org/pure-ftpd/releases/ \ > ftp://ftp.fr.pureftpd.org/pure-ftpd/releases/ > > distname pure-ftpd-${version} > use_bzip2 yes > > checksums md5 2f0869166ddb3a9cbe5e4887eae6e74d \ > sha1 bf8d04d19a83d2bec214eaa38095a070d549d978 \ > rmd160 a320048289f22161c370e12a9253f314877903ba > > livecheck.type regex > livecheck.url http://download.pureftpd.org/pub/${name}/releases/ > livecheck.regex ${name}-(${version})${extract.suffix} > > configure.args --with-cookie \ > --with-everything \ > --with-virtualchroot \ > --with-paranoidmsg \ > --without-inetd \ > --without-capabilities \ > --mandir=${prefix}/share/man \ > --infodir=${prefix}/share/info \ > --with-localstatedir=${prefix} > > destroot.destdir prefix=${destroot}${prefix} \ > mandir=${destroot}${prefix}/share/man > > post-destroot { > file mkdir ${prefix}/etc/${name}/ssl > file mkdir ${prefix}/etc/${name}/mysql > file mkdir ${prefix}/var/log/${name} > file mkdir ${destroot}${prefix}/share/doc/${name} > > # Install the notes and readme files > xinstall -m 644 -v -W ${worksrcpath} \ > AUTHORS ChangeLog CONTACT COPYING FAQ HISTORY INSTALL NEWS > README \ > README.Authentication-Modules README.Windows > README.Configuration-File \ > README.Contrib README.Debian README.Donations README.LDAP > README.MacOS-X \ > README.MySQL README.PGSQL README.TLS README.Virtual-Users THANKS \ > ${destroot}${prefix}/share/doc/${name} > > # Copy in the sample launchd plist item > file copy ${filespath}/org.pure-ftpd.ftpd.plist.sample $ > {destroot}${prefix}/share/doc/${name}/org.pure-ftpd.ftpd.plist.sample > } > > # Notify the user how to launch the ftpd > post-install { > ui_msg "" > ui_msg "PureFTPd documentation is located in: ${prefix}/share/ > doc/${name}" > ui_msg "" > ui_msg "You can start PureFTPd from the command line with:" > ui_msg " sudo ${prefix}/sbin/${name} &" > ui_msg "" > ui_msg "The next release of PureFTPd (1.0.25) will no longer > support" > ui_msg "xinetd, and has been removed from this version. If you" > ui_msg "are using that method to start PureFTPd now, please > switch" > ui_msg "to using launcd(8)." > ui_msg "" > ui_msg "A sample launchd plist has been made to get your started," > ui_msg "to enable it, issue the following commands:" > ui_msg " sudo cp ${prefix}/share/doc/${name}/org.pure- > ftpd.ftpd.plist.sample /Library/LaunchDaemons/org.pure- > ftpd.ftpd.plist" > ui_msg " sudo launchctl load -w /Library/LaunchDaemons/ > org.pure-ftpd.ftpd.plist" > } > > variant mysql5 description "Use native MySQL support for privelages > database." { > depends_lib-append path:bin/mysql_config5:mysql5 > configure.args-append --with-mysql > configure.cflags-append "-I${prefix}/include/mysql5/mysql" > configure.ldflags-append "-L${prefix}/lib/mysql5/mysql" > } > > variant tls description "Encryption of the control channel using SSL/ > TLS" { > depends_lib lib:libssl.dylib:openssl > configure.args-append --with-tls \ > --with-certfile=${prefix}/etc/${name}/ > ssl/pure-ftpd.pem > } > > # Langugage variants, should only be able to choose one. > variant lang_brazilian description "Use Bazilian language for > server messages" { configure.args-append --with-language=brazilian } > variant lang_czech description "Use Czech language for > server messages" { configure.args-append --with-language=czech } > variant lang_danish description "Use Danish language for > server messages" { configure.args-append --with-language=danish } > variant lang_dutch description "Use Dutch language for > server messages" { configure.args-append --with-language=dutch } > variant lang_french description "Use French language for > server messages" { configure.args-append --with-language=french } > variant lang_french_funny description "Use French funny language > for server messages" { configure.args-append --with-language=french- > funny } > variant lang_german description "Use German language for > server messages" { configure.args-append --with-language=german } > variant lang_italian description "Use Italian language for > server messages" { configure.args-append --with-language=italian } > variant lang_korean description "Use Korean language for > server messages" { configure.args-append --with-language=korean } > variant lang_norwegian description "Use Norwegian language > for server messages" { configure.args-append --with- > language=norwegian } > variant lang_polish description "Use Polish language for > server messages" { configure.args-append --with-language=polish } > variant lang_romanian description "Use Romanian language for > server messages" { configure.args-append --with-language=romanian } > variant lang_russian description "Use Russian language for > server messages" { configure.args-append --with-language=russian } > variant lang_simpple_chinese description "Use simplified Chinese > for server messages" { configure.args-append --with- > language=simplified-chinese } > variant lang_slovak description "Use Slovak language for > server messages" { configure.args-append --with-language=slovak } > variant lang_spanish description "Use Spanish language for > server messages" { configure.args-append --with-language=spanish } > variant lang_swedish description "Use Swedish language for > server messages" { configure.args-append --with-language=swedish } > variant lang_trad_chinese description "Use traditional Chinese > language for server messages" { configure.args-append --with- > language=traditional-chinese } Some typos: privelages should be privileges Langugage should be Language Bazilian should be Brazilian simpple_chinese should be simplified_chinese From blb at macports.org Tue Oct 27 01:26:58 2009 From: blb at macports.org (Bryan Blackburn) Date: Tue, 27 Oct 2009 02:26:58 -0600 Subject: [59915] trunk/www/install.php In-Reply-To: <74c219d30910270020g37c4769fhb5ab3c7e8c65b66a@mail.gmail.com> References: <20091027064847.E3FA22C02300@beta.macosforge.org> <99D8F979-ABA9-46A1-B411-E0CB85B688A1@macports.org> <74c219d30910270020g37c4769fhb5ab3c7e8c65b66a@mail.gmail.com> Message-ID: <20091027082658.GD775@ninagal.withay.com> On Tue, Oct 27, 2009 at 12:20:43AM -0700, Toby Peterson said: > There's no reason for people to use old version of Xcode, why should > we even bother mentioning them? Not to mention, as you (Ryan) yourself found, 3.1 isn't always good enough: Bryan > > - Toby > > On Tue, Oct 27, 2009 at 00:11, Ryan Schmidt wrote: > > > > On Oct 27, 2009, at 01:48, toby at macports.org wrote: > > > >> Revision: 59915 > >> ? ? ? ? http://trac.macports.org/changeset/59915 > >> Author: ? toby at macports.org > >> Date: ? ? 2009-10-26 23:48:43 -0700 (Mon, 26 Oct 2009) > >> Log Message: > >> ----------- > >> update Xcode versions > > > > But we don't require 3.2.1 or 3.1.4; 3.2 or 3.1 should really be fine, > > shouldn't they? > > > > And on Tiger, 2.4.1 should have been fine too. > > > > > >> Modified Paths: > >> -------------- > >> ? trunk/www/install.php > >> > >> Modified: trunk/www/install.php > >> =================================================================== > >> --- trunk/www/install.php ? ? ? 2009-10-27 04:28:11 UTC (rev 59914) > >> +++ trunk/www/install.php ? ? ? 2009-10-27 06:48:43 UTC (rev 59915) > >> @@ -39,8 +39,8 @@ > >> ? ? ? ?components:

      > >> > >> ? ? ? ?
        > >> - ? ? ? ? ? ?
      1. Apple's >> href="http://developer.apple.com/tools/xcode/">Xcode Developer Tools > >> (version 3.2 or later for Snow Leopard, > >> - ? ? ? ? ? ?3.1 or later for > >> + ? ? ? ? ? ?
      2. Apple's >> href="http://developer.apple.com/tools/xcode/">Xcode Developer Tools > >> (version 3.2.1 or later for Snow Leopard, > >> + ? ? ? ? ? ?3.1.4 or later for > >> ? ? ? ? ? ?Leopard, or 2.5 for Tiger), found at the >> href="http://connect.apple.com/">Apple Developer Connection > >> ? ? ? ? ? ?site or on your Mac OS X installation CDs/DVD. Ensure that the > >> optional components for command line development are installed > >> ? ? ? ? ? ?("Unix Development" in the Xcode 3.x installer).
        3. From emer at emer.net Tue Oct 27 06:46:04 2009 From: emer at emer.net (Mark Anderson) Date: Tue, 27 Oct 2009 09:46:04 -0400 Subject: [MacPorts] #22226: gEDA Port Submission In-Reply-To: <049.8bcd73659f07f450e7580703cafdab79@macports.org> References: <049.8bcd73659f07f450e7580703cafdab79@macports.org> Message-ID: <2cf4100f0910270646r7aa6cee3qba9d28565d072090@mail.gmail.com> Ok, so I screwed this port file up a bit. I forgot to add the dependencies. Should I post a new Portfile, or a diff. Also, once I've done that can someone commit it? On Sat, Oct 24, 2009 at 4:52 PM, MacPorts wrote: > #22226: gEDA Port Submission > ---------------------------+------------------------------------------------ > ?Reporter: ?emer@? ? ? ? ? | ? ? ? Owner: ?macports-tickets@? > ? ? Type: ?submission ? ? | ? ? ?Status: ?new > ?Priority: ?Normal ? ? ? ? | ? Milestone: ?MacPorts 1.8.2 > Component: ?ports ? ? ? ? ?| ? ? Version: ?1.8.99 > ?Keywords: ?electronics ? ?| ? ? ? ?Port: > ---------------------------+------------------------------------------------ > ?Here is a Portfile to build the gEDA suite of tools. > > -- > Ticket URL: > MacPorts > Ports system for Mac OS > From dluke at geeklair.net Tue Oct 27 07:56:30 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Tue, 27 Oct 2009 10:56:30 -0400 Subject: Port review of pure-ftpd In-Reply-To: <60C202C1-4159-4CA2-A2C7-CDA1AA761140@macports.org> References: <1AD4D76E-4748-47E2-9F8C-C9A65944272A@newgeo.com> <60C202C1-4159-4CA2-A2C7-CDA1AA761140@macports.org> Message-ID: <5ED39015-5586-4C00-A199-47990F1694E3@geeklair.net> On Oct 27, 2009, at 4:03 AM, Ryan Schmidt wrote: >> All the ui_msg in the port-install, is that the right place? > > You might want the instructions to be post-activate. ... but any direct mode users won't see them then (and while there aren't many, I think there are still a few people who prefer it). -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ From macsforever2000 at macports.org Tue Oct 27 09:29:42 2009 From: macsforever2000 at macports.org (Frank Schima) Date: Tue, 27 Oct 2009 10:29:42 -0600 Subject: [MacPorts] #22226: gEDA Port Submission In-Reply-To: <2cf4100f0910270646r7aa6cee3qba9d28565d072090@mail.gmail.com> References: <049.8bcd73659f07f450e7580703cafdab79@macports.org> <2cf4100f0910270646r7aa6cee3qba9d28565d072090@mail.gmail.com> Message-ID: <629BB755-84CD-4227-AE57-9E50C8098D72@macports.org> Yes, post a new portfile, you should be able to overwrite the old one on the ticket. Cheers! Frank On Oct 27, 2009, at 7:46 AM, Mark Anderson wrote: > Ok, so I screwed this port file up a bit. I forgot to add the > dependencies. Should I post a new Portfile, or a diff. Also, once > I've done that can someone commit it? > > On Sat, Oct 24, 2009 at 4:52 PM, MacPorts > wrote: >> #22226: gEDA Port Submission >> --------------------------- >> +------------------------------------------------ >> Reporter: emer@? | Owner: macports-tickets@? >> Type: submission | Status: new >> Priority: Normal | Milestone: MacPorts 1.8.2 >> Component: ports | Version: 1.8.99 >> Keywords: electronics | Port: >> --------------------------- >> +------------------------------------------------ >> Here is a Portfile to build the gEDA suite of tools. >> >> -- >> Ticket URL: >> MacPorts >> Ports system for Mac OS >> > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From vincent-opdarw at vinc17.org Tue Oct 27 10:46:50 2009 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue, 27 Oct 2009 18:46:50 +0100 Subject: The opendarwin .com debacle In-Reply-To: <20091015021454.GV567@ninagal.withay.com> References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> Message-ID: <20091027174650.GF28296@prunille.vinc17.org> Hi, (I've been quite busy these times and still am.) On 2009-10-14 20:14:54 -0600, Bryan Blackburn wrote: > Note that there really isn't any kind of actionable violation, as MacPorts > uses the BSD license, and the web page there looks to be his own creation... But is DarwinPorts a trademark? In such a case, who owns it? AFAIK, some application names are protected by trademarks (e.g., Firefox). -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Ar?naire project (LIP, ENS-Lyon) From vincent-opdarw at vinc17.org Tue Oct 27 10:53:32 2009 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue, 27 Oct 2009 18:53:32 +0100 Subject: The opendarwin .com debacle In-Reply-To: <19E878EA-684E-445F-9A3F-029FB42F63C2@lavergne.gotdns.org> References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> <799406d60910220838h65d86c40nbe1e8826b3f1c21c@mail.gmail.com> <19E878EA-684E-445F-9A3F-029FB42F63C2@lavergne.gotdns.org> Message-ID: <20091027175332.GG28296@prunille.vinc17.org> On 2009-10-22 13:58:01 -0400, Jeremy Lavergne wrote: > Search for "pspp mac" and you'll find dp.com sitting at #4 or #5. > This demonstrates at least one way people are finding it: searching > for the open source project they want and "mac". In my example, > simply searching for "pspp" will not being up dp.com. > > Macports is nowhere to be found, btw. Ditto for "mpfr mac", even though the only reference from the MPFR web site () was:
      3. MacPorts MPFR port.
        4. I've just changed it to:
      4. MacPorts MPFR port (for Mac?OS?X).
        5. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Ar?naire project (LIP, ENS-Lyon) From jkh at apple.com Tue Oct 27 13:36:15 2009 From: jkh at apple.com (Jordan K. Hubbard) Date: Tue, 27 Oct 2009 13:36:15 -0700 Subject: The opendarwin .com debacle In-Reply-To: <396D5857-09D1-411E-8F1A-5EE41784CEE7@macports.org> References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> <799406d60910220838h65d86c40nbe1e8826b3f1c21c@mail.gmail.com> <396D5857-09D1-411E-8F1A-5EE41784CEE7@macports.org> Message-ID: <897DECAF-4801-499D-99DD-8D374F387DC1@apple.com> On Oct 22, 2009, at 11:37 AM, James Berry wrote: > I've got to believe we have better incoming links to our site, so if > we better structured our site to do cross linking between categories > (and perhaps stoop to the subdomain tricks he does), we could > presumably improve this situation immensely. I'm told by someone who does this for a living that it's all about the anchor tags, and also making sure that all the individual ports are promoted appropriately on their own page / sections. He mentioned that there was a guide on google itself which described how to best optimize one's site for the PageRank algorithm, but I'm not able to find it just now. What I did find were a number of other sites, from the rather mathematical (http://www.webworkshop.net/pagerank.html) to the more succinct: http://www.thesitewizard.com/archive/google.shtml Either way, if darwinports.com is out-ranking macports.com on individual port names then I can only suspect that they're following more of the principles espoused at those sites than MacPorts is, and that should be relatively easy to fix if anyone is really motivated. :) - Jordan From jkh at apple.com Tue Oct 27 13:41:07 2009 From: jkh at apple.com (Jordan K. Hubbard) Date: Tue, 27 Oct 2009 13:41:07 -0700 Subject: The opendarwin .com debacle In-Reply-To: <897DECAF-4801-499D-99DD-8D374F387DC1@apple.com> References: <25FAE432-0D41-4F1C-AA09-2616E7C0E42B@newgeo.com> <2D3A794A-5E78-4A77-A732-699151F64318@lavergne.gotdns.org> <20091015021454.GV567@ninagal.withay.com> <5F173AD8-9FD7-41FF-9420-A9255BF2510A@macports.org> <799406d60910220838h65d86c40nbe1e8826b3f1c21c@mail.gmail.com> <396D5857-09D1-411E-8F1A-5EE41784CEE7@macports.org> <897DECAF-4801-499D-99DD-8D374F387DC1@apple.com> Message-ID: <2DEC23B0-770B-4377-8DC0-8D5C56EAE9BD@apple.com> Sorry, this rather old email just went whooshing out when I woke a machine that had gone to sleep before sending. I see that everyone is already well-aware of the google ranking issues and have already taken some steps to address this - sorry to revive the discussion days after the fact! On Oct 27, 2009, at 1:36 PM, Jordan K. Hubbard wrote: > > On Oct 22, 2009, at 11:37 AM, James Berry wrote: > >> I've got to believe we have better incoming links to our site, so >> if we better structured our site to do cross linking between >> categories (and perhaps stoop to the subdomain tricks he does), we >> could presumably improve this situation immensely. > > I'm told by someone who does this for a living that it's all about > the anchor tags, and also making sure that all the individual ports > are promoted appropriately on their own page / sections. He > mentioned that there was a guide on google itself which described > how to best optimize one's site for the PageRank algorithm, but I'm > not able to find it just now. What I did find were a number of > other sites, from the rather mathematical (http://www.webworkshop.net/pagerank.html > ) to the more succinct: http://www.thesitewizard.com/archive/google.shtml > > Either way, if darwinports.com is out-ranking macports.com on > individual port names then I can only suspect that they're following > more of the principles espoused at those sites than MacPorts is, and > that should be relatively easy to fix if anyone is really > motivated. :) > > - Jordan > > _______________________________________________ > macports-dev mailing list > macports-dev at lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev From talklists at newgeo.com Tue Oct 27 13:47:32 2009 From: talklists at newgeo.com (Scott Haneda) Date: Tue, 27 Oct 2009 13:47:32 -0700 Subject: Port review of pure-ftpd In-Reply-To: <5ED39015-5586-4C00-A199-47990F1694E3@geeklair.net> References: <1AD4D76E-4748-47E2-9F8C-C9A65944272A@newgeo.com> <60C202C1-4159-4CA2-A2C7-CDA1AA761140@macports.org> <5ED39015-5586-4C00-A199-47990F1694E3@geeklair.net> Message-ID: On Oct 27, 2009, at 7:56 AM, "Daniel J. Luke" wrote: > On Oct 27, 2009, at 4:03 AM, Ryan Schmidt wrote: >>> All the ui_msg in the port-install, is that the right place? >> >> You might want the instructions to be post-activate. > > ... but any direct mode users won't see them then (and while there > aren't many, I think there are still a few people who prefer it). What is "direct mode"? -- Scott Iphone says hello. From dluke at geeklair.net Tue Oct 27 14:00:23 2009 From: dluke at geeklair.net (Daniel J. Luke) Date: Tue, 27 Oct 2009 17:00:23 -0400 Subject: Port review of pure-ftpd In-Reply-To: References: <1AD4D76E-4748-47E2-9F8C-C9A65944272A@newgeo.com> <60C202C1-4159-4CA2-A2C7-CDA1AA761140@macports.org> <5ED39015-5586-4C00-A199-47990F1694E3@geeklair.net> Message-ID: On Oct 27, 2009, at 4:47 PM, Scott Haneda wrote: >> ... but any direct mode users won't see them then (and while there >> aren't many, I think there are still a few people who prefer it). > > What is "direct mode"? the way things worked prior to 'image mode' being made the default. (files are installed directly into ${prefix} instead of being linked there). -- Daniel J. Luke +========================================================+ | *---------------- dluke at geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+ From vincent-opdarw at vinc17.org Tue Oct 27 14:21:23 2009 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue, 27 Oct 2009 22:21:23 +0100 Subject: MacPorts 1.8.1 has been released In-Reply-To: <4AC14BA8.8090807@macports.org> References: <4AC14BA8.8090807@macports.org> Message-ID: <20091027212123.GA17863@prunille.vinc17.org> On 2009-09-29 09:50:00 +1000, Joshua Root wrote: > If you already have MacPorts installed, the preferred method for > updating is to run: > > sudo port selfupdate On Tiger: [...] ===> making install in src/programs ===> making install in src/programs/daemondo mkdir -p build /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 couldn't execute "svn": no such file or directory while executing "while {[gets $sourcesConfChannel line] >= 0} { set addDefault false if {!$defaultSeen && ![regexp {^\s*#|^$} $line]} { if {[regexp {^([\w-..." (file "src/upgrade_sources_conf_default.tcl" line 34) make: *** [install] Error 1 zsh: exit 1 sudo port selfupdate -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Ar?naire project (LIP, ENS-Lyon) From jmr at macports.org Tue Oct 27 14:27:15 2009 From: jmr at macports.org (Joshua Root) Date: Wed, 28 Oct 2009 08:27:15 +1100 Subject: MacPorts 1.8.1 has been released In-Reply-To: <20091027212123.GA17863@prunille.vinc17.org> References: <4AC14BA8.8090807@macports.org> <20091027212123.GA17863@prunille.vinc17.org> Message-ID: <4AE765B3.2090102@macports.org> On 2009-10-28 08:21, Vincent Lefevre wrote: > On 2009-09-29 09:50:00 +1000, Joshua Root wrote: >> If you already have MacPorts installed, the preferred method for >> updating is to run: >> >> sudo port selfupdate > > On Tiger: > > [...] > ===> making install in src/programs > ===> making install in src/programs/daemondo > mkdir -p build > /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 > couldn't execute "svn": no such file or directory > while executing > "while {[gets $sourcesConfChannel line] >= 0} { > set addDefault false > if {!$defaultSeen && ![regexp {^\s*#|^$} $line]} { > if {[regexp {^([\w-..." > (file "src/upgrade_sources_conf_default.tcl" line 34) > make: *** [install] Error 1 > > zsh: exit 1 sudo port selfupdate > Yes, that's . - Josh From vincent-opdarw at vinc17.org Tue Oct 27 14:51:45 2009 From: vincent-opdarw at vinc17.org (Vincent Lefevre) Date: Tue, 27 Oct 2009 22:51:45 +0100 Subject: MacPorts 1.8.1 has been released In-Reply-To: <4AE765B3.2090102@macports.org> References: <4AC14BA8.8090807@macports.org> <20091027212123.GA17863@prunille.vinc17.org> <4AE765B3.2090102@macports.org> Message-ID: <20091027215145.GB17863@prunille.vinc17.org> On 2009-10-28 08:27:15 +1100, Joshua Root wrote: > Yes, that's . Thanks. If it is not fixed in the next version, I think that the upgrade instructions should mention this bug. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Ar?naire project (LIP, ENS-Lyon) From talklists at newgeo.com Tue Oct 27 16:00:15 2009 From: talklists at newgeo.com (Scott Haneda) Date: Tue, 27 Oct 2009 16:00:15 -0700 Subject: Port review of pure-ftpd In-Reply-To: <60C202C1-4159-4CA2-A2C7-CDA1AA761140@macports.org> References: <1AD4D76E-4748-47E2-9F8C-C9A65944272A@newgeo.com> <60C202C1-4159-4CA2-A2C7-CDA1AA761140@macports.org> Message-ID: <4D6E3553-D93D-42CA-A7ED-E0BB146573EB@newgeo.com> On Oct 27, 2009, at 1:03 AM, Ryan Schmidt wrote: > On Oct 27, 2009, at 01:19, Scott Haneda wrote: > >> All the ui_msg in the port-install, is that the right place? > > You might want the instructions to be post-activate. I will look into this. >> The software only allows one language to be compiled in, but I >> suspect that MP would allow as many + variants as were listed, is >> there a way to solve this? > > MacPorts has been a bit English-centric so far. In my minivmac > portfile, I didn't even attempt to offer options to compile for > different languages. I could have offered variants, but nobody has > requested it so far, so I haven't worried about it. for the sake of port simplicity, I am tempted to remove them. They only offer language of a few server messages. I suppose it best to leave them in though. >> Is there any way to order the variants as shown by `port info`, and >> if not, is it a bad idea to prefix the language variants with a "z" >> so they do not get in the way of letting people know there is myqsl >> and tls available for this? > > The variants used to be listed in the order specified in the > portfile. MacPorts 1.8.0 changed this to alphabetical order. I would > not recommend using a "z" prefix or anything like that. Prefixing > them with "lang_" like you've done is what I would do. It is still a bummer, as the tls and mysql variants get lost. I guess there is very little I can do about it. It says they are available in the description, so I will leave it at that. > As your comment says, you still need to make them conflict with one > another. You could construct the variants dynamically, like the swig > port does. The below seems to work. Unfortunately it makes the > output of "port variants" rather hard to read. Yeah, not a huge fan of that, and if I can not readily grok it, I certainly do not want to maintain it :) If one was to do this: port install +foo +bar +baz In any of the most initial of phases, which I am not sure that is, but before anything happens, how can I grab ahold of the variant names passed on the command line? Here is what I am thinking, and I also need help with how to abort out of a port install, but I think the php5 port should show me that well. Given this: port install +foo +bar +baz I actually will have port install +lang_foo +lang_bar +lang_baz repeat with aVariant in variantList if aVariant starts with lang_ then counter++ if counter > 1 then abort with message end repeat That seems short and to the point to me. > # Language name Configure arg > set languages { > {Brazilian} brazilian > {Czech} czech > {Danish} danish > {Dutch} dutch > {French} french > {funny French} french-funny > {German} german > {Italian} italian > {Korean} korean > {Norwegian} norwegian > {Polish} polish > {Romanian} romanian > {Russian} russian > {simplified Chinese} simplified-chinese > {Slovak} slovak > {Spanish} spanish > {Swedish} swedish > {traditional Chinese} traditional-chinese > } > > # Add langugage variants > foreach {language arg} ${languages} { > set variant lang_[strsed ${arg} {g/-/_/}] > set conflicts {} > foreach {ignore conflicting_arg} ${languages} { > if {${conflicting_arg} != ${arg}} { > set conflicting_variant lang_[strsed ${conflicting_arg} > {g/-/_/}] > lappend conflicts ${conflicting_variant} > } > } > eval [subst { > variant ${variant} conflicts ${conflicts} description "Use $ > {language} language for server messages" { > configure.args-append --with-language=${arg} > } > }] > } >> description Pure-FTPd is a fast, production-quality, >> standard-conformant FTP (SSL/TLS) > > Missing backslash at end of the above line. Do I need one after the last hash in the checksums also then? > Some typos: > privelages should be privileges > Langugage should be Language > Bazilian should be Brazilian > simpple_chinese should be simplified_chinese Thanks for those, good catches. -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Tue Oct 27 16:10:12 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 27 Oct 2009 18:10:12 -0500 Subject: Port review of pure-ftpd In-Reply-To: <4D6E3553-D93D-42CA-A7ED-E0BB146573EB@newgeo.com> References: <1AD4D76E-4748-47E2-9F8C-C9A65944272A@newgeo.com> <60C202C1-4159-4CA2-A2C7-CDA1AA761140@macports.org> <4D6E3553-D93D-42CA-A7ED-E0BB146573EB@newgeo.com> Message-ID: On Oct 27, 2009, at 18:00, Scott Haneda wrote: > If one was to do this: > port install +foo +bar +baz > > In any of the most initial of phases, which I am not sure that is, > but before anything happens, how can I grab ahold of the variant > names passed on the command line? I don't think you can do that, but you can use if {[variant_isset foo]} { ... } > Here is what I am thinking, and I also need help with how to abort > out of a port install, but I think the php5 port should show me that > well. To abort, use return -code error "some error message" > Given this: > port install +foo +bar +baz I actually will have port install > +lang_foo +lang_bar +lang_baz You're not suggesting that you have variant aliases now are you -- where +foo becomes a synonym for +lang_foo? > repeat with aVariant in variantList > if aVariant starts with lang_ then counter++ > if counter > 1 then abort with message > end repeat > > That seems short and to the point to me. It would work. This would basically be reimplementing the conflicts mechanism yourself, but hiding that fact in the output of "port variants". I'm not sure I agree with reimplementing existing MacPorts features in individual portfiles, but I will grant that the conflicts output from "port variants" is very ugly when there are many variants with many conflicts. Perhaps there is a way "port variants" could display this information in a more succinct and less cluttered way; that would solve the problem not just for you but all other ports that have many conflicting variants. (See "port variants minivmac".) >>> description Pure-FTPd is a fast, production-quality, >>> standard-conformant FTP (SSL/TLS) >> >> Missing backslash at end of the above line. > > Do I need one after the last hash in the checksums also then? No, you don't put a backslash after the last line. The above description line is the first line of a two-line description. "port" experienced a syntax error until I added the backslash here. From talklists at newgeo.com Tue Oct 27 16:17:55 2009 From: talklists at newgeo.com (Scott Haneda) Date: Tue, 27 Oct 2009 16:17:55 -0700 Subject: Port review of pure-ftpd In-Reply-To: <4D6E3553-D93D-42CA-A7ED-E0BB146573EB@newgeo.com> References: <1AD4D76E-4748-47E2-9F8C-C9A65944272A@newgeo.com> <60C202C1-4159-4CA2-A2C7-CDA1AA761140@macports.org> <4D6E3553-D93D-42CA-A7ED-E0BB146573EB@newgeo.com> Message-ID: <2D33426F-1C83-4613-B144-8887779B23D1@newgeo.com> I am seeing this on occasion when testing the pure-ftpd port I am working on: $sudo port install +mysql +tls 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. -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Tue Oct 27 16:42:09 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 27 Oct 2009 18:42:09 -0500 Subject: Port review of pure-ftpd In-Reply-To: <2D33426F-1C83-4613-B144-8887779B23D1@newgeo.com> References: <1AD4D76E-4748-47E2-9F8C-C9A65944272A@newgeo.com> <60C202C1-4159-4CA2-A2C7-CDA1AA761140@macports.org> <4D6E3553-D93D-42CA-A7ED-E0BB146573EB@newgeo.com> <2D33426F-1C83-4613-B144-8887779B23D1@newgeo.com> Message-ID: On Oct 27, 2009, at 18:17, Scott Haneda wrote: > I am seeing this on occasion when testing the pure-ftpd port I am > working on: > > $sudo port install +mysql +tls > 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. Right. openssl is recorded in your registry as having no variants selected, but if installed today, openssl's +darwin variant would be automatically selected. The warning did not exist before MacPorts 1.8.0. Also, MacPorts before 1.8.0 had a bug where specifically the +darwin variant would not be recorded in the registry, even if it was selected. You can ignore the warning, or use "sudo port upgrade -- enforce-variants openssl" to rebuild openssl and record the correct variants in the registry. From talklists at newgeo.com Tue Oct 27 19:58:40 2009 From: talklists at newgeo.com (Scott Haneda) Date: Tue, 27 Oct 2009 19:58:40 -0700 Subject: Port review of pure-ftpd In-Reply-To: References: <1AD4D76E-4748-47E2-9F8C-C9A65944272A@newgeo.com> <60C202C1-4159-4CA2-A2C7-CDA1AA761140@macports.org> <4D6E3553-D93D-42CA-A7ED-E0BB146573EB@newgeo.com> Message-ID: >> repeat with aVariant in variantList >> if aVariant starts with lang_ then counter++ >> if counter > 1 then abort with message >> end repeat >> >> That seems short and to the point to me. > > It would work. This would basically be reimplementing the conflicts > mechanism yourself, but hiding that fact in the output of "port > variants". I'm not sure I agree with reimplementing existing > MacPorts features in individual portfiles, but I will grant that the > conflicts output from "port variants" is very ugly when there are > many variants with many conflicts. Perhaps there is a way "port > variants" could display this information in a more succinct and less > cluttered way; that would solve the problem not just for you but all > other ports that have many conflicting variants. (See "port variants > minivmac".) I guess I am just going to leave it. The chances that someone installs more than one language are slim. If I use my method above, I have to maintain a list of language names, iterate them, and do other magic on them. In addition, I am braking a convention. I do not really understand the conflicting variants issue, and seem to be unable to find a lot of documentation on the matter. In this case, I know I can not append more than one language to the configure.args, and wanted to solve that. I suppose I am ok with this though. If someone has a nice and clean way to do it, I am all ears, but the previous example posted here, I have looked at it a few times, and to be honest, that seems like a lot of stuff to put in a port file just to have languages not collide. Thanks for all the advice on this one, I am going to submit it tonight I think. -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Tue Oct 27 20:37:29 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Tue, 27 Oct 2009 22:37:29 -0500 Subject: Port review of pure-ftpd In-Reply-To: References: <1AD4D76E-4748-47E2-9F8C-C9A65944272A@newgeo.com> <60C202C1-4159-4CA2-A2C7-CDA1AA761140@macports.org> <4D6E3553-D93D-42CA-A7ED-E0BB146573EB@newgeo.com> Message-ID: <5931D6B9-96BE-4F5B-BD40-8F384D420327@macports.org> On Oct 27, 2009, at 21:58, Scott Haneda wrote: > I do not really understand the conflicting variants issue, and seem > to be unable to find a lot of documentation on the matter. In this > case, I know I can not append more than one language to the > configure.args, and wanted to solve that. I suppose I am ok with > this though. What questions do you have about conflicting variants? I'll certainly try to answer them. > If someone has a nice and clean way to do it, I am all ears, but the > previous example posted here, I have looked at it a few times, and > to be honest, that seems like a lot of stuff to put in a port file > just to have languages not collide. The example I submitted not only allows you to specify conflicting variants, but also allows the variants to be constructed programmatically, so that you don't have to repeat stuff in each variant, like you were doing, such as the description. Admittedly the variants themselves, from your previous portfile, are pretty simple; you don't gain as much by constructing them programmatically as the swig port did by doing so. From talklists at newgeo.com Tue Oct 27 21:23:00 2009 From: talklists at newgeo.com (Scott Haneda) Date: Tue, 27 Oct 2009 21:23:00 -0700 Subject: Port review of pure-ftpd In-Reply-To: <5931D6B9-96BE-4F5B-BD40-8F384D420327@macports.org> References: <1AD4D76E-4748-47E2-9F8C-C9A65944272A@newgeo.com> <60C202C1-4159-4CA2-A2C7-CDA1AA761140@macports.org> <4D6E3553-D93D-42CA-A7ED-E0BB146573EB@newgeo.com> <5931D6B9-96BE-4F5B-BD40-8F384D420327@macports.org> Message-ID: <801A53D9-C4AC-4CED-B456-A349631B3F83@newgeo.com> On Oct 27, 2009, at 8:37 PM, Ryan Schmidt wrote: > On Oct 27, 2009, at 21:58, Scott Haneda wrote: > >> I do not really understand the conflicting variants issue, and seem >> to be unable to find a lot of documentation on the matter. In this >> case, I know I can not append more than one language to the >> configure.args, and wanted to solve that. I suppose I am ok with >> this though. > > What questions do you have about conflicting variants? I'll > certainly try to answer them. I get the impression there is a inbuilt mechanism for dealing with conflicting variants. This is why my simple repeat loops to count up how many language variants were added was a bad idea, replication of tools. The code you showed me for the swig port, is just barely something I can grok as to what it is up to, with the downside that `port variants swig` looks a little goofy. I am mostly just looking for the docs on how to gain a better understanding on what is going on in that swig portfile. >> If someone has a nice and clean way to do it, I am all ears, but >> the previous example posted here, I have looked at it a few times, >> and to be honest, that seems like a lot of stuff to put in a port >> file just to have languages not collide. > > The example I submitted not only allows you to specify conflicting > variants, but also allows the variants to be constructed > programmatically, so that you don't have to repeat stuff in each > variant, like you were doing, such as the description. Admittedly > the variants themselves, from your previous portfile, are pretty > simple; you don't gain as much by constructing them programmatically > as the swig port did by doing so. I would need to adapt the swig code to my case, and get it so that it is just adding in the languages, and alerting for conflicts, there seems to be a lot more going on there. If you have shove me in the right direction, that would be great. There is not a lot in the docs on "conflicts", all I really want to do is iterate a list to add them, and then look at how many are being requested to be installed, for the "lang*" ones, and abort if there is more than one. I found other issues in the pure-ftpd port, so I am stalled waiting on developer feedback on that, which gives me time to be more ideal about this language issue. Thanks -- Scott * If you contact me off list replace talklists@ with scott@ * From ryandesign at macports.org Wed Oct 28 15:17:17 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 28 Oct 2009 17:17:17 -0500 Subject: [59980] trunk/dports/devel/caml-batteries/Portfile In-Reply-To: <20091028145008.584592C5D934@beta.macosforge.org> References: <20091028145008.584592C5D934@beta.macosforge.org> Message-ID: <0435A5F5-731B-4C08-978D-D9804CEAC89B@macports.org> On Oct 28, 2009, at 09:50, avsm at macports.org wrote: > Revision: 59980 > http://trac.macports.org/changeset/59980 > Author: avsm at macports.org > Date: 2009-10-28 07:50:06 -0700 (Wed, 28 Oct 2009) > Log Message: > ----------- > disable parallel build to make it reliable Looks like another thing that could get added to a caml portgroup, if someone made one. From ryandesign at macports.org Wed Oct 28 15:44:08 2009 From: ryandesign at macports.org (Ryan Schmidt) Date: Wed, 28 Oct 2009 17:44:08 -0500 Subject: [59980] trunk/dports/devel/caml-batteries/Portfile In-Reply-To: <7129F803-B3B9-44A0-A924-733CA8E4C7C5@recoil.org> References: <20091028145008.584592C5D934@beta.macosforge.org> <0435A5F5-731B-4C08-978D-D9804CEAC89B@macports.org> <7129F803-B3B9-44A0-A924-733CA8E4C7C5@recoil.org> Message-ID: On Oct 28, 2009, at 17:33, Anil Madhavapeddy wrote: > On 28 Oct 2009, at 22:17, Ryan Schmidt wrote: > >> On Oct 28, 2009, at 09:50, avsm at macports.org wrote: >> >>> disable parallel build to make it reliable >> >> Looks like another thing that could get added to a caml portgroup, >> if someone made one. > > well, there are a lot of different build mechanisms for ocaml > unfortunately (most of which arent parallel safe, but some are). The portgroup is just for defaults, anyway. You could turn parallel build off in the portgroup, and then turn it back on in individual ports where it does work. > I took a quick look last week, but I'd rather import a few more > ports and then get the common stuff factored out instead of creating > a group too early. Understood. I've been adding features and changing things in the php5extension portgroup as I add new php5 extension ports, and I will admit it's tedious to have to then rebuild all the existing php5 extension ports to make sure my change doesn't break them. From emer at emer.net Wed Oct 28 19:13:47 2009 From: emer at emer.net (Mark Anderson) Date: Wed, 28 Oct 2009 22:13:47 -0400 Subject: [MacPorts] #22226: gEDA Port Submission In-Reply-To: <629BB755-84CD-4227-AE57-9E50C8098D72@macports.org> References: <049.8bcd73659f07f450e7580703cafdab79@macports.org> <2cf4100f0910270646r7aa6cee3qba9d28565d072090@mail.gmail.com> <629BB755-84CD-4227-AE57-9E50C8098D72@macports.org> Message-ID: <2cf4100f0910281913g5126b446vca16fbae2304a854@mail.gmail.com> Ok, well I fixed it and added all 3 checksums to boot. Can someone commit it? Also, let me know if there are troubles. Mark On Tue, Oct 27, 2009 at 12:29 PM, Frank Schima wrote: > Yes, post a new portfile, you should be able to overwrite the old one on the > ticket. > > > Cheers! > Frank > > On Oct 27, 2009, at 7:46 AM, Mark Anderson wrote: > >> Ok, so I screwed this port file up a bit. ?I forgot to add the >> dependencies. ? Should I post a new Portfile, or a diff. ?Also, once >> I've done that can someone commit it? >> >> On Sat, Oct 24, 2009 at 4:52 PM, MacPorts wrote: >>> >>> #22226: gEDA Port Submission >>> >>> ---------------------------+------------------------------------------------ >>> ?Reporter: ?emer@? ? ? ? ? | ? ? ? Owner: ?macports-tickets@? >>> ? ?Type: ?submission ? ? | ? ? ?Status: ?new >>> ?Priority: ?Normal ? ? ? ? | ? Milestone: ?MacPorts 1.8.2 >>> Component: ?ports ? ? ? ? ?| ? ? Version: ?1.8.99 >>> ?Keywords: ?electronics ? ?| ? ? ? ?Port: >>> >>> ---------------------------+------------------------------------------------ >>> ?Here is a Portfile to build the gEDA suite of tools. >>> >>> -- >>> Ticket URL: >>> MacPorts >>> Ports system for Mac OS >>> >> _______________________________________________ >> macports-dev mailing list >> macports-dev at lists.macosforge.org >> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev > > From ram at macports.org Wed Oct 28 20:41:55 2009 From: ram at macports.org (Adam Mercer) Date: Wed, 28 Oct 2009 22:41:55 -0500 Subject: [59616] trunk/dports/python/py26-numpy/Portfile In-Reply-To: <20091017225618.CB6EA2A492EF@beta.macosforge.org> References: <20091017225618.CB6EA2A492EF@beta.macosforge.org> Message-ID: <799406d60910282041w5f8da0fdt3a34ea906c92fac6@mail.gmail.com> On Sat, Oct 17, 2009 at 17:56, wrote: > Revision 59608 Author jameskyle at macports.org Date 2009-10-17 15:55:57 -0700 > (Sat, 17 Oct 2009) > > Log Message > > Added ATLAS, LAPACK, and BLAS build environment to point to macports libs. > > Modified Paths > > trunk/dports/python/py26-numpy/Portfile On Sat, Oct 17, 2009 at 17:56, wrote: > Revision 59616 > Author jameskyle at macports.org Date > 2009-10-17 15:56:16 -0700 (Sat, 17 Oct 2009) > > Log Message > > Added proper deletion of default opts for no_gcc43 and no_atlas variants. > > Modified Paths > > trunk/dports/python/py26-numpy/Portfile Shouldn't the revision have been bumped for these changes? Cheers Adam From ramercer at gmail.com Wed Oct 28 20:42:43 2009 From: ramercer at gmail.com (Adam Mercer) Date: Wed, 28 Oct 2009 22:42:43 -0500 Subject: [59617] trunk/dports/python/py26-scipy/Portfile In-Reply-To: <20091017225621.C7B432A4931B@beta.macosforge.org> References: <20091017225621.C7B432A4931B@beta.macosforge.org> Message-ID: <799406d60910282042h2c007ac4w2c875171ef6904bd@mail.gmail.com> On Sat, Oct 17, 2009 at 17:56, wrote: > Revision 59609 Author jameskyle at macports.org Date 2009-10-17 15:56:00 -0700 > (Sat, 17 Oct 2009) > > Log Message > > Added ATLAS, LAPACK, and BLAS build environment to build to macports > libraries. > Set the gcc/g++ compiler to the gcc-mp-4.3 for the gcc43 build. > > Modified Paths > > trunk/dports/python/py26-scipy/Portfile On Sat, Oct 17, 2009 at 17:56, wrote: > Revision 59617 > Author jameskyle at macports.org Date > 2009-10-17 15:56:19 -0700 (Sat, 17 Oct 2009) > > Log Message > > Added proper deletion of default opts for no_gcc43 and no_atlas variants. > > Modified Paths > > trunk/dports/python/py26-scipy/Portfile Shouldn't the revision have been bumped for these changes? Cheers Adam From blb at macports.org Thu Oct 29 01:05:27 2009 From: blb at macports.org (Bryan Blackburn) Date: Thu, 29 Oct 2009 02:05:27 -0600 Subject: [60013] trunk/dports/databases/db46/Portfile In-Reply-To: <20091029040259.EEE902C80747@beta.macosforge.org> References: <20091029040259.EEE902C80747@beta.macosforge.org> Message-ID: <20091029080527.GV775@ninagal.withay.com> On Wed, Oct 28, 2009 at 09:02:59PM -0700, blair at macports.org said: > Revision: 60013 > http://trac.macports.org/changeset/60013 > Author: blair at macports.org > Date: 2009-10-28 21:02:59 -0700 (Wed, 28 Oct 2009) > Log Message: > ----------- > Defend against people having stuff in /usr/local that prevents db46 > from properly building. If somebody wants to supply a patch to > prevent db46 from picking stuff up from /usr/local, then I'll gladly > accept it. Can this test be made a bit more specific, say /usr/local/include/db.h and/or /usr/local/lib/libdb.a for example? Otherwise, this is going to fail in many places where there is otherwise nothing bad in /usr/local. Note that the general issue with /usr/local is gcc and not db46-specific, and as far as I know, nobody's found a clean way to avoid it as yet. Bryan [...] From blair at orcaware.com Thu Oct 29 09:00:20 2009 From: blair at orcaware.com (Blair Zajac) Date: Thu, 29 Oct 2009 09:00:20 -0700 Subject: [60013] trunk/dports/databases/db46/Portfile In-Reply-To: <20091029080527.GV775@ninagal.withay.com> References: <20091029040259.EEE902C80747@beta.macosforge.org> <20091029080527.GV775@ninagal.withay.com> Message-ID: <23C01788-605D-4ED9-92CA-5279193487F8@orcaware.com> On Oct 29, 2009, at 1:05 AM, Bryan Blackburn wrote: > On Wed, Oct 28, 2009 at 09:02:59PM -0700, blair at macports.org said: >> Revision: 60013 >> http://trac.macports.org/changeset/60013 >> Author: blair at macports.org >> Date: 2009-10-28 21:02:59 -0700 (Wed, 28 Oct 2009) >> Log Message: >> ----------- >> Defend against people having stuff in /usr/local that prevents db46 >> from properly building. If somebody wants to supply a patch to >> prevent db46 from picking stuff up from /usr/local, then I'll gladly >> accept it. > > Can this test be made a bit more specific, say /usr/local/include/db.h > and/or /usr/local/lib/libdb.a for example? Otherwise, this is going > to fail > in many places where there is otherwise nothing bad in /usr/local. > > Note that the general issue with /usr/local is gcc and not db46- > specific, > and as far as I know, nobody's found a clean way to avoid it as yet. Of the ports I maintain, db46 seems to be the main one that stuff in / usr/local causes issues. But I haven't looked to see what stuff in there can cause a problem. I guess we could do a search for db*. Blair From mark at dxradio.demon.co.uk Thu Oct 29 13:45:52 2009 From: mark at dxradio.demon.co.uk (Mark Hattam) Date: Thu, 29 Oct 2009 20:45:52 +0000 Subject: [60013] trunk/dports/databases/db46/Portfile In-Reply-To: <20091029080527.GV775@ninagal.withay.com> References: <20091029040259.EEE902C80747@beta.macosforge.org> <20091029080527.GV775@ninagal.withay.com> Message-ID: <7ECC2F51-5C3D-4E22-AAEF-BCDF49F97AD8@dxradio.demon.co.uk> On 29 Oct 2009, at 08:05, Bryan Blackburn wrote: > On Wed, Oct 28, 2009 at 09:02:59PM -0700, blair at macports.org said: >> Revision: 60013 >> http://trac.macports.org/changeset/60013 >> Author: blair at macports.org >> Date: 2009-10-28 21:02:59 -0700 (Wed, 28 Oct 2009) >> Log Message: >> ----------- >> Defend against people having stuff in /usr/local that prevents db46 >> from properly building. If somebody wants to supply a patch to >> prevent db46 from picking stuff up from /usr/local, then I'll gladly >> accept it. > > Can this test be made a bit more specific, say /usr/local/include/db.h > and/or /usr/local/lib/libdb.a for example? Otherwise, this is going > to fail > in many places where there is otherwise nothing bad in /usr/local. > > Note that the general issue with /usr/local is gcc and not db46- > specific, > and as far as I know, nobody's found a clean way to avoid it as yet. > > Bryan er .. yes ... what fails in my instance? iMac:~ $ sudo port upgrade outdated ---> Computing dependencies for db46 ---> Fetching db46 ---> Attempting to fetch patch.4.6.21.1 from http://www.oracle.com/technology/products/berkeley-db/db/update/4.6.21/ ---> Attempting to fetch patch.4.6.21.2 from http://www.oracle.com/technology/products/berkeley-db/db/update/4.6.21/ ---> Attempting to fetch patch.4.6.21.3 from http://www.oracle.com/technology/products/berkeley-db/db/update/4.6.21/ ---> Attempting to fetch patch.4.6.21.4 from http://www.oracle.com/technology/products/berkeley-db/db/update/4.6.21/ ---> Attempting to fetch db-4.6.21.tar.gz from http://arn.se.distfiles.macports.org/db4/4.6.21_6 ---> Attempting to fetch db-4.6.21.tar.gz from http://distfiles.macports.org/db4/4.6.21_6 ---> Verifying checksum(s) for db46 ---> Extracting db46 Error: Move /usr/local out of the way then make this port. Error: Target org.macports.extract returned: /usr/local is in the way Error: Unable to upgrade port: 1 iMac:local $ ls -laR /usr/local/ total 0 drwxr-xr-x 5 root wheel 170 5 Sep 21:59 . drwxr-xr-x@ 12 root wheel 408 5 Sep 22:08 .. drwxr-xr-x 2 root wheel 68 11 Sep 23:43 bin drwxr-xr-x 3 root wheel 102 5 Sep 21:59 man drwxr-xr-x 2 root wheel 68 11 Sep 23:43 sbin /usr/local//bin: total 0 drwxr-xr-x 2 root wheel 68 11 Sep 23:43 . drwxr-xr-x 5 root wheel 170 5 Sep 21:59 .. /usr/local//man: total 0 drwxr-xr-x 3 root wheel 102 5 Sep 21:59 . drwxr-xr-x 5 root wheel 170 5 Sep 21:59 .. drwxr-xr-x 2 root 501 68 11 Sep 23:43 man8 /usr/local//man/man8: total 0 drwxr-xr-x 2 root 501 68 11 Sep 23:43 . drwxr-xr-x 3 root wheel 102 5 Sep 21:59 .. /usr/local//sbin: total 0 drwxr-xr-x 2 root wheel 68 11 Sep 23:43 . drwxr-xr-x 5 root wheel 170 5 Sep 21:59 .. Mark From blb at macports.org Thu Oct 29 13:55:49 2009 From: blb at macports.org (Bryan Blackburn) Date: Thu, 29 Oct 2009 14:55:49 -0600 Subject: [60013] trunk/dports/databases/db46/Portfile In-Reply-To: <7ECC2F51-5C3D-4E22-AAEF-BCDF49F97AD8@dxradio.demon.co.uk> References: <20091029040259.EEE902C80747@beta.macosforge.org> <20091029080527.GV775@ninagal.withay.com> <7ECC2F51-5C3D-4E22-AAEF-BCDF49F97AD8@dxradio.demon.co.uk> Message-ID: <20091029205549.GB775@ninagal.withay.com> On Thu, Oct 29, 2009 at 08:45:52PM +0000, Mark Hattam said: > > On 29 Oct 2009, at 08:05, Bryan Blackburn wrote: > > >On Wed, Oct 28, 2009 at 09:02:59PM -0700, blair at macports.org said: > >>Revision: 60013 > >> http://trac.macports.org/changeset/60013 > >>Author: blair at macports.org > >>Date: 2009-10-28 21:02:59 -0700 (Wed, 28 Oct 2009) > >>Log Message: > >>----------- > >>Defend against people having stuff in /usr/local that prevents db46 > >>from properly building. If somebody wants to supply a patch to > >>prevent db46 from picking stuff up from /usr/local, then I'll gladly > >>accept it. > > > >Can this test be made a bit more specific, say /usr/local/include/db.h > >and/or /usr/local/lib/libdb.a for example? Otherwise, this is > >going to fail > >in many places where there is otherwise nothing bad in /usr/local. > > > >Note that the general issue with /usr/local is gcc and not db46- > >specific, > >and as far as I know, nobody's found a clean way to avoid it as yet. > > > >Bryan > > > er .. yes ... what fails in my instance? I made the test more specific in r60031 so try again after a selfupdate in 30 minutes or so. See also ticket #22291: Bryan [...] > > > Mark From jmr at macports.org Thu Oct 29 20:46:31 2009 From: jmr at macports.org (Joshua Root) Date: Fri, 30 Oct 2009 14:46:31 +1100 Subject: [60041] trunk/dports/python/py25-opengl/Portfile Message-ID: <4AEA6197.4000105@macports.org> > Revision: 60041 > http://trac.macports.org/changeset/60041 > Author: alakazam at macports.org > Date: 2009-10-29 20:36:33 -0700 (Thu, 29 Oct 2009) > Log Message: > ----------- > Update py25-opengl to version 3.0.1a1 Is there a particular reason you need to update to an alpha version, but not the latest alpha version (3.0.1a3)? - Josh From alakazam at macports.org Thu Oct 29 21:03:24 2009 From: alakazam at macports.org (Olivier Le Floch) Date: Fri, 30 Oct 2009 05:03:24 +0100 Subject: [60041] trunk/dports/python/py25-opengl/Portfile In-Reply-To: <4AEA6197.4000105@macports.org> References: <4AEA6197.4000105@macports.org> Message-ID: <9724153F-C34C-4E95-A160-5AC399329883@macports.org> On 30 oct. 2009, at 04:46, Joshua Root wrote: >> Revision: 60041 >> http://trac.macports.org/changeset/60041 >> Author: alakazam at macports.org >> Date: 2009-10-29 20:36:33 -0700 (Thu, 29 Oct 2009) >> Log Message: >> ----------- >> Update py25-opengl to version 3.0.1a1 > > Is there a particular reason you need to update to an alpha version, > but > not the latest alpha version (3.0.1a3)? Nope, thanks for catching this, I just did a quick update and but too much faith in the livecheck regexp... Which obviously got things wrong. I'll be doing a more careful update now... :) From talklists at newgeo.com Fri Oct 30 02:32:46 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 30 Oct 2009 02:32:46 -0700 Subject: Three perl port submissions; p5-io, p5-io-socket-inet6, p5-lwp-attic Message-ID: I just went through all my local port repo's, and found which ones were not in MacPorts official, and which were local to only me. I have three it appears that are ready for submission. As far as I can tell, there are no dependencies within these. I needed them for a software I was using, and quickly put them together. That software appears to work, so I am assuming these work as well. https://trac.macports.org/ticket/22306 https://trac.macports.org/ticket/22307 https://trac.macports.org/ticket/22308 -- Scott * If you contact me off list replace talklists@ with scott@ * From talklists at newgeo.com Fri Oct 30 02:58:17 2009 From: talklists at newgeo.com (Scott Haneda) Date: Fri, 30 Oct 2009 02:58:17 -0700 Subject: Port review of pure-ftpd In-Reply-To: <5931D6B9-96BE-4F5B-BD40-8F384D420327@macports.org> References: <1AD4D76E-4748-47E2-9F8C-C9A65944272A@newgeo.com> <60C202C1-4159-4CA2-A2C7-CDA1AA761140@macports.org> <4D6E3553-D93D-42CA-A7ED-E0BB146573EB@newgeo.com> <5931D6B9-96BE-4F5B-BD40-8F384D420327@macports.org> Message-ID: <64644AFE-C70F-48BB-BF73-D1EE0190B857@newgeo.com> On Oct 27, 2009, at 8:37 PM, Ryan Schmidt wrote: > What questions do you have about conflicting variants? I'll > certainly try to answer them. I am running port install pure-ftpd +mysql + postgresql I see my error now, I missed the mysql5 in the variant, so the port went ahead and started installing pure-ftpd and postgresql. If I issue a `port install something +nonexistant` I would expect that to fail, is that not the case? # Variants variant mysql5 conflicts postgresql description "Use native MySQL support for privileges database." { depends_lib-append path:bin/mysql_config5:mysql5 configure.args-append --with-mysql configure.cflags-append "-I${prefix}/include/mysql5/mysql" configure.ldflags-append "-L${prefix}/lib/mysql5/mysql" } variant postgresql conflicts mysql5 description "Use native postgreSQL support for privileges database." { depends_lib-append port:postgresql83 configure.args-append --with-pgsql } -- Scott * If you contact me off list replace talklists@ with scott@ * From raimue at macports.org Fri Oct 30 06:37:29 2009 From: raimue at macports.org (=?ISO-8859-1?Q?Rainer_M=FCller?=) Date: Fri, 30 Oct 2009 14:37:29 +0100 Subject: Port review of pure-ftpd In-Reply-To: <64644AFE-C70F-48BB-BF73-D1EE0190B857@newgeo.com> References: <1AD4D76E-4748-47E2-9F8C-C9A65944272A@newgeo.com> <60C202C1-4159-4CA2-A2C7-CDA1AA761140@macports.org> <4D6E3553-D93D-42CA-A7ED-E0BB146573EB@newgeo.com> <5931D6B9-96BE-4F5B-BD40-8F384D420327@macports.org> <64644AFE-C70F-48BB-BF73-D1EE0190B857@newgeo.com> Message-ID: <4AEAEC19.4050601@macports.org> On 2009-10-30 10:58 , Scott Haneda wrote: > I am running port install pure-ftpd +mysql + postgresql > I see my error now, I missed the mysql5 in the variant, so the port > went ahead and started installing pure-ftpd and postgresql. > > If I issue a `port install something +nonexistant` I would expect that > to fail, is that not the case? No, you can specify non-existing variants without an error message. Note that given variants are passed down to dependencies if they are not installed yet. That way this variant could be meant for some other port in the dependency tree. Also, variants from variants.conf are always applied as if you had typed them on the command line. Rainer From dreamcat4 at gmail.com Fri Oct 30 09:45:25 2009 From: dreamcat4 at gmail.com (dreamcat four) Date: Fri, 30 Oct 2009 16:45:25 +0000 Subject: (ruby) For an http-server which is also a ruby-gem ? Message-ID: <99cf22520910300945k59c8eabbo598fe4b3ba248661@mail.gmail.com> Hello, For completion of this ticket: http://trac.macports.org/ticket/19342 It seems necessary to create a new "rb-passenger" gem to support compiling the +passenger variant ( which is an nginx C module provided by the gem). As such, this would be quite handy for many Ruby / Rails developers. But then realized that i didn't know enough to create a proper rubygem macport. a) Looking at other portfiles, I see a line like this: ruby.setup passenger 2.2.5 gem {} rubyforge_gem But man ruby gems as moving away from rubyforge to gemcutter repository "http://gemcutter.org". So is the existing macro rubyforge_gem sufficient for this? Can anyone affirm / deny this point? On a rubygems installation, the end user would usually add http://gemcutter.org to the top of the gem-sources list in ~/.gemrc. b) Is it necessary to make ports of a gem's gem dependencies explicitly as seperate portfiles? Ie, if this gem depends on 5 others, do i need to write those 5 other portfiles too? c) Another question i have is about persistent daemon service / launchd plist creation for the rubygem HTTP servers unicorn and rainbows. Effectively they superseed rb-mongrel. Such daemon service is not necessary for Passenger (above), but it does apply to all these mongrel like replacements. For example the existing rb-mongrel Portfile depends on rb-daemons. However there is no mention for any launchd plist for the mongrel portfile. This confuses me. In nginx port there is: startupitem.create yes startupitem.executable ${prefix}/sbin/nginx startupitem.pidfile auto ${nginx_pidfile} Which sorts out an appropriate launchd service. Is similar configuration forbidden for 'HTTP server' ruby gems such as rb-mongrel? Theres few evidence in the mongrel portfile that the alternative daemons service is any good compared to launchd. Any help would be much appreciated. Best regards, dreamcat4 dreamcat4 at gmail.com From dreamcat4 at gmail.com Fri Oct 30 13:59:16 2009 From: dreamcat4 at gmail.com (dreamcat four) Date: Fri, 30 Oct 2009 20:59:16 +0000 Subject: (ruby) For an http-server which is also a ruby-gem ? In-Reply-To: <99cf22520910300945k59c8eabbo598fe4b3ba248661@mail.gmail.com> References: <99cf22520910300945k59c8eabbo598fe4b3ba248661@mail.gmail.com> Message-ID: <99cf22520910301359u69514314hcfc350b5dacada7b@mail.gmail.com> On Fri, Oct 30, 2009 at 4:45 PM, dreamcat four wrote: > c) Another question i have is about persistent daemon service / Indeed rb-daemons doesn't provide the same function as a launchd plist file. The mongrel_cluster gem does provide an init.d script, which will read config from /etc/mongrel_cluster on boot. we don't have init.d on mac, but its a start. It suggest we should add startupitem... to rb-mongrel_cluster > > Best regards, > > dreamcat4 > dreamcat4 at gmail.com > From howarth at bromo.med.uc.edu Fri Oct 30 17:46:50 2009 From: howarth at bromo.med.uc.edu (Jack Howarth) Date: Fri, 30 Oct 2009 20:46:50 -0400 Subject: restricted swig package Message-ID: <20091031004650.GA14186@bromo.med.uc.edu> I am running into a problem with my proposed pynmr packaging... http://trac.macports.org/ticket/21642 and the latest swig 1.3.40-1 packaging in 1.8.1. Previously we built swig with python support and I leveraged that version since swig is apparently missing from Xcode in Tiger. Would it be possible to add variants to the swig package in macports to provide the missing python support again or is there a way in the Portfile to mark it as 10.5/10.6 only (which would be required if I resorted to using the system swig from Xcode)? Jack From jmr at macports.org Fri Oct 30 18:30:12 2009 From: jmr at macports.org (Joshua Root) Date: Sat, 31 Oct 2009 12:30:12 +1100 Subject: restricted swig package In-Reply-To: <20091031004650.GA14186@bromo.med.uc.edu> References: <20091031004650.GA14186@bromo.med.uc.edu> Message-ID: <4AEB9324.4010502@macports.org> On 2009-10-31 11:46, Jack Howarth wrote: > I am running into a problem with my proposed pynmr > packaging... > > http://trac.macports.org/ticket/21642 > > and the latest swig 1.3.40-1 packaging in 1.8.1. Previously > we built swig with python support and I leveraged that version > since swig is apparently missing from Xcode in Tiger. Would it > be possible to add variants to the swig package in macports to > provide the missing python support again or is there a way > in the Portfile to mark it as 10.5/10.6 only (which would be > required if I resorted to using the system swig from Xcode)? Depend on swig-python. - Josh